KV cache量子化でGemma 4が先に崩れる理由　LocalLLaMAが注目

「q8_0ならほぼ無傷」という前提が揺れた

r/LocalLLaMAでこの投稿が伸びた理由は、単なる比較表ではない。多くのローカル推論ユーザーが半ば常識として扱っていた「q8_0 KV cacheは実質無損失に近い」という感覚を、数字で揺らしたからだ。リンク先のLocalBench記事は、Gemma 4とQwen 3.6でその前提が全く同じようには成立しないことを示した。

設定も分かりやすい。同じBF16 GGUFを同一マシンで3回ロードし、f16、q8_0、q4_0のKV cacheだけを変えている。評価は約250,000 tokens、6カテゴリ、top-40 log-probability分布のKL divergenceで行われた。記事によれば、q8_0はcacheメモリを半分に、q4_0は4分の1にする。その代償がモデルごとに大きく違った。Gemma 31Bはq8_0でKL 0.108、Gemma 4 26B A4Bはq8_0で 0.377、q4_0では 1.088まで上がる。一方でQwen 3.6系はq8_0で両方とも 0.04未満、q4_0でも 0.087-0.117に収まった。

コミュニティがすぐ掘った論点

上位コメントは結果をそのまま受け取るだけではなかった。最も支持された反応は、Gemma側の劣化がSWA cacheを量子化し続けた設計判断と関係しているのではないかと推測し、実タスクでどれほど効くのかを知りたいと書いた。別の読者は、30k前後のcontextでこうなら100k、200kではどうなるのかと問い、さらにtoken全体を測ったのかassistant turnだけを見たのかという方法論にも踏み込んだ。Gemmaはassistant turn外で分布がかなり荒れるという体感も共有されている。つまりこの投稿は、cache量子化を「何となく大丈夫」から「条件付きで評価すべき対象」へ変えた。

なぜ重要か

ローカルLLM運用では、cache precisionとcontext lengthをモデル横断の汎用ノブとして扱いがちだ。このベンチマークはそれにブレーキをかける。同じq8_0でも、あるモデルでは軽微な差で済み、別のモデルではかなり早く品質が崩れる。しかも損傷の出方はlong documentやtool callingなどカテゴリごとにも違う。結局、ローカル推論最適化は「ひたすら精度を下げる」話ではなく、モデルごとの感受性と実際のworkloadを合わせて見る作業だ。LocalLLaMAがこの投稿を高く評価したのは、その現実をきれいに数値化したからである。

出典: LocalBench原文 · r/LocalLLaMAスレッド