Reddit が見た Gemma 4 の llama.cpp 安定化、ただし運用上の注意は残る

何が起きたのか

高スコアの r/LocalLLaMA post は、llama.cpp の PR #21534 が 2026年4月9日に merge されたことで、Gemma 4 support がようやく安定域に入ったと主張した。ただし重要な caveat がある。ここでいう安定化は release binary ではなく、current master を source build した場合を指している。

PR の内容は具体的だ。Gemma 4 tokenizer test を追加し、src/llama-vocab.cpp を更新して、non-byte-encoded BPE tokenization の UTF-8 edge case を修正している。PR comment では、この変更で欠けていた Korean character の問題が直ったという報告があり、別の comment では一部の Japanese word が以前は正しく認識されなかったと説明されている。こうした bug は crash のように目立たず、multilingual prompting と output quality を静かに落とすため、むしろ厄介だ。

なぜ Reddit が注目したのか

LocalLLaMA はこれを単なる model release の話ではなく、運用の話として扱った。元の post には、実運用でしか見えにくい runtime hint がまとめて載っている。

Gemma 4 の chat behavior には interleaved --chat-template-file を使うこと

system RAM 問題を避けるため --cache-ram 2048 -ctxcp 2 を検討すること

fix が downstream に届くまで current source build と tagged release を分けて考えること

さらに CUDA 13.2 への強い警告も付いていた。元 post はこれを “confirmed broken” と表現し、follow-up comment でもその組み合わせで unstable behavior が出るという補強があった。つまり Reddit のメッセージは「Gemma 4 がどこでも自動的に直った」ではない。より正確には、llama.cpp upstream の tokenizer work が Gemma 4 support を大きく改善した一方で、正しい chat template、build target、runtime setting を揃えないと、みんなが言う結果には届かないという話だ。

この nuance こそが post の価値だった。open-weight model は benchmark headline より toolchain reality に左右される。local adoption は tokenization correctness、multilingual edge case、template behavior、そして memory を抑える地味な flag に依存する。そう考えると、今回の話は Gemma 4 hype というより、upstream fix と実務的な運用知見がようやく同じ地点で噛み合ったという記録に近い。原文: r/LocalLLaMA, llama.cpp PR #21534.