#gemma-4

LocalLLaMAがこの投稿を評価したのは、『Gemma 4は何となく弱い』で終わらなかったからだ。nullableなJSON Schemaが空のtypeに潰れるという具体的な壊れ方を切り出し、小さなJinja修正でtool callingが戻るところまで持っていった。

LocalLLaMAがこの投稿に反応したのは、q8_0 KV cacheはだいたい安全という前提が崩れたからだ。Gemma 4はQwen 3.6よりずっと早く劣化し、議論はすぐにSWA cacheと長文contextの影響へ向かった。

Quantizationはaccuracyが崩れると一気に価値を失う。Red Hat AIはquantized Gemma 4 31Bがメモリを半分に抑えつつtokens/secをほぼ2倍にし、baseline accuracyの99%+を維持すると書いた。

人気のr/LocalLLaMA threadは、Gemma 4の256k context windowで100k+ tokenの個人journalをローカル分析した事例を示し、privacyがon-device LLMを動かす実用的な理由になり得ることを示した。

Daniel VaughanのGemma 4検証は、local modelが本当にCodex CLIのagentとして使えるのかを、具体的な設定値と失敗パターンまで含めて示した。ポイントはApple SiliconではOllamaを避け、llama.cppと`--jinja`、KV cache quantization、`web_search = "disabled"`を組み合わせる必要があったことだ。

NVIDIA AI PCは2026年4月2日のXで、Gemma 4 モデル群が RTX GPU と DGX Spark 向けに最適化され、とくに 26B と 31B が local agentic AI に適していると述べた。NVIDIA の公式 blog では、この協業が RTX PC、workstation、DGX Spark、Jetson Orin Nano、data center 配備までをカバーし、native tool use、multimodal input、Ollama と llama.cpp による local runtime を支えると説明している。

r/LocalLLaMAの新しいベンチマークでは、Gemma 4 31BとE2B draftの組み合わせでspeculative decodingが平均29%、code生成では約50%の高速化を示した。

r/LocalLLaMAのstress testでは、Gemma 4 26B A4Bがllama.cpp上で262,144 context windowの約94%でも一貫性を保ったと主張されている。正式なbenchmarkではないが、failure modeとtuning値をあわせて公開している点が実務的だ。

NVIDIAは2026年4月2日、Google の最新 Gemma 4 model を RTX PC、DGX Spark、Jetson edge module 向けに最適化したと発表した。狙いは compact multimodal model を cloud の外にある実用的な local agent stack へ押し出すことにある。

LocalLLaMA の高スコア post は、llama.cpp PR #21534 の merge によって Gemma 4 の current master support が実用的な安定域に入ったと見た。ただし焦点は fix そのものより tokenizer correctness、chat template、memory flag、そして CUDA 13.2 を避けるべきだという運用条件にあった。

LocalLLaMAの投稿は、最近の llama.cpp 修正により Gemma 4 GGUF を再取得する価値があると指摘し、ローカル推論利用者が見るべき変更点をまとめている。

r/LocalLLaMA で広がった Unsloth の Gemma 4 ガイドは、Gemma-4-E2B と E4B を 8GB VRAM でローカル fine-tuning できると訴える。投稿では約 1.5 倍の training speed、FA2 比で約 60% 少ない VRAM、そして初期 Gemma 4 の training・inference bug fix を practical workflow としてまとめている。