設定したのに効いていない？〜KVキャッシュの圧縮が無視されていた話

2026年8月15日

ローカルでLLM（大規模言語モデル。文章を扱うAIの本体）を動かしていると、長い文章を読ませたときに急に遅くなることがあります。以前この現象を調べて、原因はKVキャッシュ（読んだ内容を覚えておくための領域）がグラフィックボードのメモリに収まらず、CPU側へあふれることだと突き止めました。

ならば、そのKVキャッシュを圧縮すれば解決するのではないか。Ollama（ローカルでLLMを動かす代表的なソフト）には、まさにそのための設定があります。試してみたところ、数値がまったく動きませんでした。設定が効いていなかったのです。

2026年7月時点の内容です。

目的：圧縮すれば長い文章を扱えるのか

きっかけは、海外の方の投稿でした。12GBのグラフィックボード1枚で、24万トークンという長大な文脈を扱いながら毎秒77トークンで動かしている、という報告です。

手元の測定とかけ離れています。同じ12GBのグラフィックボードで、文脈を32,768トークンまで伸ばすと毎秒9トークンまで落ちていました。桁が違います。

差はどこにあるのか。投稿ではKVキャッシュの圧縮に触れていました。こちらはそれを一度も試していません。ここが原因ではないかと考え、確かめることにしました。

実験内容：圧縮の有無を揃えて比べる

条件を1つだけ変えて比べます。KVキャッシュの精度を、既定のまま（f16）・8ビットに圧縮・4ビットに圧縮の3通りにし、それぞれで文脈の長さを変えて測りました。

結果：3つとも同じ数字だった

結果は拍子抜けするものでした。

単位は毎秒トークン数です。3つの条件が、どの文脈長でもほぼ同じ値になりました。測定のばらつきの範囲に収まっています。

それ以上に決定的なのが、右端のCPU側の負担です。3条件で1%も違いませんでした。KVキャッシュが本当に圧縮されていれば必要な容量が減り、CPUへあふれる量も減るはずです。まったく動かないということは、圧縮そのものが起きていないという証拠です。

なぜ効かなかったのか、ログを見て分かった

Ollamaが内部で起動しているプログラム（llama-server）のログを開いて、答えが出ました。

圧縮を指定したはずなのに、f16 と書かれています。既定のままです。

起動時のコマンドも確認しました。KVキャッシュの精度を指定する項目が、そもそも渡されていません。

環境変数で圧縮を指定しても、実際に動かすプログラムまで届いていなかったということです。エラーも警告も出ません。設定した側からは、効いているのか効いていないのか分かりません。

副産物：あふれの正体がログで確認できた

同じログに、こちらの推測を裏づける行もありました。

KVキャッシュ6.4GBのうち、2.4GBがCPU側に置かれています。以前「あふれの主因はKVキャッシュ」と書きましたが、推測ではなくログで確認できました。

もう1つ分かったこと：ある所から先は落ちない

今回は文脈を131,072トークンまで伸ばしました。以前は32,768までしか測っていません。

結果を見ると、32,768を超えたあたりから落ちなくなります。毎秒8トークン前後で横ばいになり、131,072でも同じでした。CPU側の負担も37%で止まっています。

以前は「文脈を伸ばすほど遅くなる」と書きましたが、正確には32,768あたりで底を打ち、それ以降は横ばいでした。遅いことに変わりはないものの、伸ばすほど際限なく悪化するわけではありません。

まとめ：確かめられなかった、が結論

• KVキャッシュを圧縮すれば長い文脈を扱えるのか、という問いには答えが出せませんでした
• 理由は、圧縮の設定が実際のプログラムまで届いていなかったから（Ollama 0.30.5・エラーも警告も出ない）
• 気づけたのはCPU側の負担が1%も動かなかったから。速度だけ見ていたら見逃していた
• 副産物として、あふれの正体がKVキャッシュであることをログで確認できた（6.4GB中2.4GBがCPU側）
• 文脈は32,768あたりで底を打ち、それ以降は横ばいだった

次は、Ollamaを介さずに llama.cpp を直接動かして測り直します。そちらなら精度を直接指定できるので、圧縮そのものの効果を確かめられるはずです。結果が出たら、あらためて記録します。

検証に使用した機材

[kimono_product id="16471″]

参考にしたサイト

確認日 2026年7月29日。バージョンが上がれば挙動は変わります。