【ITニュース解説】Stop Guessing Your Context Budget: Practical KV Cache Sizing for Local LLMs

大規模言語モデル（LLM）を自分のパソコンやサーバーで動かそうとするとき、しばしばメモリ不足の問題に直面する。多くの人は、その原因がモデルファイル自体の大きさにあると考えがちだが、実はほとんどの場合、真犯人は「KVキャッシュ」と呼ばれるものだ。このKVキャッシュの仕組みを理解し、適切に管理することは、システムエンジニアとしてLLMを効率的に扱う上で非常に重要になる。

KVキャッシュとは、LLMが文章を生成する過程で使われる、一時的なデータのことだ。LLMは次にどんな単語を生成するかを決定する際、入力された文章やこれまでに生成した単語の中から、どの情報に注目すべきかを判断する「Attention（アテンション）」という仕組みを利用する。このAttentionの処理では、入力された各単語から「Key（鍵）」と「Value（値）」という重要な情報が作られる。モデルは、これらKeyとValueの情報を「KVキャッシュ」として一時的にメモリに保存する。こうすることで、新しい単語を生成するたびに過去の単語のKeyとValueを毎回再計算する手間を省き、処理を高速化しているのだ。このKVキャッシュは、モデルが一度に処理できる文章の長さ、つまり「コンテキスト長」に比例してサイズが大きくなる。そして、モデルの起動時にVRAM（GPUのメモリ）上にまとめて確保されるため、VRAM容量が限られた環境では、コンテキスト長を長く設定しようとするとすぐにメモリ不足に陥ってしまう原因となる。

KVキャッシュがどれくらいのメモリを消費するかは、モデルの内部構造によって大きく異なる。おおよそのサイズは、次の計算式で把握できる。 1トークンあたりのキャッシュバイト数 = 2 * レイヤー数 * KVヘッド数 * ヘッド次元 * 1要素あたりのバイト数 ここで「2」はKeyとValueのペアがあることを示し、「レイヤー数」はモデルの内部にあるAttention層の数、「ヘッド次元」はAttentionメカニズムの一部であるヘッドの内部的なサイズだ。この式の中で特に重要な要素が「KVヘッド数」である。このKVヘッド数が多いモデルほど、同じコンテキスト長でもより多くのVRAMをKVキャッシュのために使うことになる。例えば、同じ「7B」（約70億個のパラメータを持つ）と呼ばれる規模のモデルでも、KVヘッド数が少ないモデル（例えば4）と多いモデル（例えば8）では、KVキャッシュの消費量が倍近く異なることがある。これは「GQA（Grouped Query Attention）」という技術によって、KVヘッド数を減らしてメモリ効率を高めているためだ。したがって、モデルのパラメータ数だけでなく、KVヘッド数とレイヤー数を確認することが、コンテキスト長を設定する上でのメモリコストを予測する上で非常に重要になる。

KVキャッシュのメモリ消費量を減らす一般的な方法として「量子化」がある。これは、モデルが内部で扱う数値の精度（表現の細かさ）を下げることで、メモリ使用量を削減する技術だ。例えば、通常2バイトの浮動小数点数（f16）で表現されるデータを、より少ないバイト数（例: q8_0なら約1バイト、q4_0なら約0.5バイト）で表現するように変換する。しかし、「メモリが半分になる」や「4分の1になる」といった単純な説明は、厳密には正しくない場合が多い。実際には、量子化されたキャッシュは、単に値を小さくするだけでなく、複数の値をまとめて処理するための「スケール」情報なども一緒に保存する。この付随する情報がわずかながらオーバーヘッドとなり、例えばq8_0はf16の約53.1%、q4_0はf16の約28.1%のメモリを消費するというのが現実の数値だ。この小さな差が、VRAM容量に余裕がない環境では、モデルが正常に動作するかどうかに大きく影響することがある。

実際にLLMを動かすためのソフトウェアである「llama.cpp」や「Ollama」では、このKVキャッシュの設定を細かく制御できる。llama.cppでは、-cオプションでモデルが処理するコンテキスト長を明示的に指定することが非常に重要だ。この設定を怠ると、モデルによっては非常に長いコンテキスト長がデフォルトで適用され、すぐにVRAMを使い果たしてしまう可能性がある。KVキャッシュのデータ型は、-ctk（Keyキャッシュ）と-ctv（Valueキャッシュ）オプションを使って個別に設定でき、f16やq8_0、q4_0といった量子化タイプを選択できる。ただし、量子化されたVキャッシュ（例えば-ctv q8_0）を使用する場合は、「Flash Attention」という処理を高速化する技術を有効にする（-fa on）必要がある点に注意が必要だ。Flash Attentionが有効でない環境では、量子化されたVキャッシュは使えないことが多い。また、llama.cppには--fitという、利用可能なメモリに合わせてコンテキスト長などを自動調整するオプションがデフォルトで有効になっている場合があるが、意図しないコンテキスト長でモデルが動作することを避けるため、-cを明示的に指定し、自動調整に頼らない方が再現性のある運用には適している。VRAMが不足しているがシステムRAMには余裕がある場合は、--no-kv-offloadでKVキャッシュをシステムRAMに置くことで、VRAMを節約することも可能だが、その場合は処理速度が低下する可能性がある。

OllamaでもKVキャッシュの管理は同様に重要だ。Ollamaのデフォルトのコンテキスト長は4096トークンと短めに設定されているため、長い文章を扱いたい場合は、OLLAMA_CONTEXT_LENGTHという環境変数を使ってこれを長くする必要がある。さらにOllamaでは、OLLAMA_NUM_PARALLELで並列で処理するリクエスト数を増やすと、そのリクエスト数に応じてKVキャッシュもそれぞれ確保されるため、必要なVRAMが並列リクエスト数分だけ乗算されてしまう点に注意が必要だ。Ollamaで量子化キャッシュを使用する場合、OLLAMA_FLASH_ATTENTIONとOLLAMA_KV_CACHE_TYPEといった環境変数を設定ファイルに記述し、Ollamaサービス全体に適用する。設定変更後は必ずOllamaサービスを再起動し、実際に設定が適用されたかどうかを確認することが大切だ。

KVキャッシュの量子化によってメモリを節約できたとしても、それだけで安心はできない。最も重要なのは、モデルの出力品質が維持されているかを確認することだ。メモリ使用量だけを見て「モデルが動いたから問題ない」と判断するのは危険である。例えば、非常に長いプロンプトの中に特定のランダムな情報を埋め込み、モデルにその情報を正確に抽出させる「ニードルテスト」のような手法で、長文からの情報検索能力を評価できる。高精度なf16キャッシュの場合と、量子化したq8_0やq4_0キャッシュの場合で、モデルの回答がどれくらい変化するかを比較することで、品質の低下がないかを確認できる。また、実際の業務で想定される具体的なタスク、例えば特定のデータをJSON形式で抽出するようなタスクでテストを行うことも有効だ。このような正確な形式での出力が求められるタスクは、自由形式の文章生成よりも量子化による影響を受けやすいため、モデルの品質劣化を早期に発見するための敏感な指標となる。さらに、モデルの生成速度も重要な性能指標だ。量子化されたキャッシュはメモリを節約する一方で、データを読み出す際に「逆量子化」という追加の計算が必要になる場合があり、これが生成速度に影響を与える可能性があるため、実際に速度を計測し、自身の環境で最適なバランスを見つけることが重要である。

結局のところ、大規模言語モデルを安定して効率的に運用するためには、モデルのファイルサイズだけでなく、KVキャッシュがどれくらいのメモリを消費するのかを正確に理解し、適切に設定することが不可欠だ。KVキャッシュのサイズを計算する式、量子化による実際のメモリ削減率、そしてllama.cppやOllamaといったツールでこれらの設定を制御する方法を習得すれば、コンテキスト長を闇雲に推測するのではなく、具体的な数値を根拠に最適なリソース配分を行うことができる。これにより、限られたVRAM環境でも、より長く、より高品質なLLMの利用が可能になる。