Gemma 4 の早計な評価は危険？ LocalLLaMA で llama.cpp 修正をめぐる議論

LocalLLaMA で広がっている このスレッドは、Gemma 4 の初期評価をそのまま model quality と見なすのは危険だと指摘している。論点はシンプルだ。多くの user は model を評価しているつもりでも、実際にはまだ安定化していない llama.cpp runtime 越しに Gemma 4 を見ている。local model の launch では、weights だけでなく parser、tokenizer、attention handling、quantization、memory behavior まで含めた inference stack 全体が揃わないと、公正な判断が難しい。

元投稿は Gemma 4 対応に関する複数の llama.cpp pull request を直接挙げている。例えば PR #21418、PR #21390、PR #21406 などだ。投稿者は chat では looping problem を見たが、OpenCode では問題が出なかったと書き、overthinking や looping は prompt や runtime fix の影響も受けるのではないかと示唆している。要するに、「Gemma 4 はもう完全に解決した」という話ではなく、release 直後の悪印象のかなりの部分が model より tooling lag から来ている可能性がある、という問題提起だ。

comments もその見方を補強している。ある user は「llama.cpp を update すべきだ」と断言し、4B model を RTX 3070 で毎秒 60 tokens 前後で動かしていると報告した。別の comment は、この pattern はほぼ every model release で繰り返されるとまとめる。最初は model が悪く見え、tokenizer や inference bugs が直った後で本来の挙動が見えてくる、というわけだ。community build と fork が先行しやすい local LLM ecosystem では、こうした operational detail が benchmark headline と同じくらい重要になっている。

このスレッドの価値は、評価対象を model 単体から system 全体へ広げているところにある。local inference では、どこか一層でも壊れていれば launch quality は大きく歪む。だから LocalLLaMA の user たちは Gemma 4 を「良い model か悪い model か」で片付けるのではなく、「今見えている failure はどの layer から来ているのか」という問いに置き換えて議論している。より deployment に近い視点だ。