きっかけ：KVキャッシュも量子化できるらしい
OllamaにはOLLAMA_KV_CACHE_TYPEという環境変数があり、q8_0を指定するとKVキャッシュ(生成中に保持する内部状態)自体を8bit量子化してメモリを節約できる。今回はこれを検証しようとしたんだけど、想定外の展開になった。
検証中に、まさかの再現性のある大幅減速に遭遇
Gemma4-12B-Hereticでnum_ctx=16384を指定し、f16(既定)とq8_0を比較しようとしたところ、q8_0を指定した途端に応答が返ってこなくなった。最初は60秒でタイムアウト、リトライしたら120秒でもタイムアウト。「ハングしているのでは」と疑い、240秒までタイムアウトを延ばして3回目を試したところ、ようやく応答が返ってきた。
- f16(既定): 32.5 tok/s
- q8_0: 2.3 tok/s
約14倍の速度低下。しかもこれは1回のたまたまの不調ではなく、3回とも一貫して極端に遅い(タイムアウト→タイムアウト→2.3 tok/s)という結果だった。ちなみにこの計測の過程で、f16側でも一度だけ8.2 tok/sまで落ち込む瞬間があったんだけど、こちらはOllamaを再起動したら即座に32.5 tok/sへ回復した。以前の記事(「謎のGPUエラーを追いかけたら「クラッシュしないのに70倍遅くなる」競合を見つけた話」)で見つけた、一時的なGPU状態の悪化と同じ類の現象だったと思われる。
つまり今回は2種類の「遅さ」が同時に観測されたことになる。①f16側で一瞬だけ起きた、再起動で直る一時的な不調、②q8_0側で3回とも再現した、構造的な遅さ。この2つを混同しないよう、q8_0側は複数回試して確認している。
結論
- このVulkan/Intel Arc環境では、
OLLAMA_KV_CACHE_TYPE=q8_0は実用にならない — 3回の試行すべてで、f16比14倍以上の速度低下が再現した - f16(既定のまま)が安定して速い — 特別な理由がない限り、この環境ではKVキャッシュの量子化はしない方がいい
- 「遅い」には別の原因が混ざることがある — 今回はq8_0の構造的な遅さに加えて、f16側でも別種の一時的なGPU状態不調が偶然重なった。原因を混同しないよう、複数回の試行で切り分けることが大事だと再認識した
- VRAM削減はできても、速度との引き換えは割に合わない — 省メモリ目的でKVキャッシュ量子化を検討している場合、この環境では速度面の代償が大きすぎる
10回にわたるローカルAIベンチマークシリーズの最後が、まさかの「検証中に想定外の不具合に遭遇し、それ自体が記事になる」という展開になった。ある意味、実際に手を動かして検証することの意義を体現するような締めくくりになったと思う。