KVキャッシュとは？ 長いコンテキストでVRAMが増える理由

モデル本体はGPUに収まるのに、コンテキストを長くするとVRAM不足になることがある。その原因の一つがKVキャッシュだ。

LLMはモデルの重みだけで動いているわけではない。会話や文書を処理する途中で、過去トークンのattention計算に使ったKeyとValueを保持し、次のトークン生成で再利用する。この実行時メモリがKVキャッシュになる。

図を拡大して見る

図: 容量・設定値・段階差の判断軸を1枚に整理。数値の条件は本文を優先する。

KVキャッシュは何を保存しているのか

Transformer系のLLMは、新しいトークンを生成するときに過去のトークンとの関係を計算する。毎回すべての過去トークンについてKeyとValueを計算し直すのは非効率なため、すでに計算したK/Vを保存して再利用する。

Hugging Faceの説明でも、KVキャッシュは過去のK/V状態を保持し、生成時の再計算を避ける仕組みとして説明されている。

このキャッシュはモデルファイルそのものではない。モデルを読み込んだ後、入力や生成が進むにつれて必要になる実行時の領域だ。

コンテキストが長いほどKVキャッシュも増える

標準的なKVキャッシュでは、保持するトークン列が長くなるほどキャッシュも大きくなる。

短い会話なら保存するK/Vは少ない。長い文書や長時間の会話を一度に保持すれば、より多くのトークンについてK/Vを残す必要がある。

Ollamaも、コンテキスト長を大きくすると必要メモリが増えると案内している。そのため、モデルが128Kや256Kに対応していても、最大値を毎回設定する理由はない。

実際に32Kしか使わない用途なら、128Kの最大設定を維持するより必要な長さへ下げた方がメモリを節約できる。

「コンテキスト2倍＝VRAM2倍」とは固定できない

KVキャッシュはコンテキスト長に応じて増えるが、正確な必要容量はトークン数だけでは決まらない。

影響する主な条件には次のようなものがある。

• モデルの層数とattention構造
• Key/Valueのhead構成
• KVキャッシュのdtype
• batchや同時処理数
• キャッシュ実装
• GPUとCPUへの配置
• ランタイムとバージョン

そのため、「128KならKVキャッシュは○GB」「64Kから128KにするとVRAMが必ず正確に2倍」といった万能な表は作れない。

キャッシュの実装や量子化でも条件が変わる

Hugging Faceには複数のKVキャッシュ実装があり、メモリ使用量と速度のトレードオフが説明されている。ランタイムによってはキャッシュの精度を下げたり、配置方法を変更したりできる場合もある。

メモリを減らせる設定があっても、無条件に速度や品質を維持できるとは限らない。使うモデルとランタイムで対応状況を確認する必要がある。

また、モデルの一部をCPUとRAMへオフロードできるランタイムでも、起動できたからモデル全体とKVキャッシュがGPU内に収まったとは限らない。GPU使用量とシステムRAM、配置表示を合わせて見ることが重要だ。

OOMになったらコンテキストから見直す

長いコンテキストでOOMになった場合、最初にGPU交換を考える必要はない。

まず実際に必要な入力長を確認し、コンテキスト設定を小さくして動くかを見る。次にランタイムのKVキャッシュ設定や量子化、モデルのGPU配置を確認する。

それでも必要なコンテキストとモデルを収められない場合に、より大きなVRAMやRAMを持つ構成を検討すればよい。

短いコンテキストへ下げて問題なく使えるなら、それは性能を捨てた設定ではなく、自分の用途に必要なメモリだけを使っている状態だ。

最大生成長とは別の数字

コンテキスト長と、一度に生成できる最大出力トークン数も別に考える必要がある。

コンテキストは入力、会話履歴、生成部分を含む全体の枠に関わる。一方、最大生成長は新しく出力できるトークン数の制限だ。

Qwen2.5-7B-Instructのように、通常32K・条件付き128Kのコンテキストと8Kの生成上限を別に持つモデルもある。詳しくはQwen2.5-7B-Instructの32K・128K・8Kの違いで確認できる。

KVキャッシュを考えるときは、モデルファイルの容量だけでPCを選ばず、実際に使うコンテキスト長を決めてから実行時メモリを見るのが基本になる。GPU容量の選び方まで進む場合は、ローカルAI向けGPUは16GB・24GB・32GBのどれを選ぶ？も参考になる。