ローカルLLMのコンテキスト長とVRAM — KVキャッシュ計算式と早見表
ローカルLLMのVRAM不足の多くはモデル重みではなくKVキャッシュが原因です。KVキャッシュ量は2×レイヤ数×KVヘッド数×ヘッド次元×コンテキスト長×精度バイト数で概算でき、7B級のモデルでも128Kコンテキストで約17GBに達します。GQA/MQAと量子化による削減、OOM回避の実践設定を解説します。
KVキャッシュの消費VRAMは、2 × レイヤ数 × KVヘッド数 × ヘッド次元 × コンテキスト長 × 精度バイト数、という式で概算できる。同じモデルでも、コンテキスト長が8Kから128K、1Mへと伸びるほどKVキャッシュは線形に増え、7B級のモデルでも128Kコンテキストなら数GB、1Mコンテキストなら数十GB〜100GBを超えることも珍しくない。モデルの重みがVRAMに収まっていても、長い文章やチャット履歴を投入した瞬間にOOM（メモリ不足）になるのは、この式が示す通りKVキャッシュが別枠で膨張しているからだ。
KVキャッシュとは何か — なぜトークンが増えるほどメモリが増えるのか
Transformerの自己注意機構は、各トークンを生成するたびに、それ以前の全トークンのKey（K）とValue（V）ベクトルを参照する。これを毎回ゼロから計算し直すと大幅に遅くなるため、推論エンジンは一度計算したK・Vベクトルを「KVキャッシュ」としてVRAM上に保持し、次のトークン生成時に再利用する。モデルの重み（パラメータ）が起動時に確保される静的なVRAM消費であるのに対し、KVキャッシュはコンテキストに投入したトークン数（プロンプト＋生成済みトークン）に比例して動的に増え続ける点が決定的に違う。ローカルLLMで「モデルは正常にロードできたのに、長い文章を貼り付けたり会話が長引いたりすると急にOOMになる」現象の大半は、この動的なKVキャッシュの増大が原因である。
KVキャッシュのVRAM計算式
KVキャッシュ(バイト) = 2 × L × H_kv × D × S × P × B
L : レイヤ数（num_hidden_layers）
H_kv: KVヘッド数（num_key_value_heads。GQAではH_kvはクエリヘッド数より少ない）
D : ヘッド次元（head_dim。多くは64〜128）
S : コンテキスト長（シーケンス長、トークン数）
P : 1要素あたりのバイト数（fp16/bf16=2、fp32=4、int8=1、int4=0.5）
B : バッチサイズ（同時処理する会話数。通常は1）
2 : Key用とValue用の2セット分
例）Llama系7B級モデル（L=32, H_kv=8, D=128, fp16, B=1）でS=128,000の場合:
2 × 32 × 8 × 128 × 128,000 × 2 = 約17.2GB
※ L・H_kv・D の実際の値はモデルのconfig.json（num_hidden_layers / num_key_value_heads / head_dim）で確認できる。GQAを採用しないモデルはH_kvがクエリヘッド数と同じになり、この式のまま計算するとKVキャッシュはさらに大きくなる。コンテキスト長別 KVキャッシュ早見表（fp16基準・概算）
| コンテキスト長 | 7B級（L32/Hkv8/D128） | 14B級（L40/Hkv8/D128） | 30B級MoE（L48/Hkv8/D128） | 70B級（L80/Hkv8/D128） |
|---|---|---|---|---|
| 8K | 約1.1GB | 約1.3GB | 約1.6GB | 約2.7GB |
| 32K | 約4.3GB | 約5.4GB | 約6.4GB | 約10.7GB |
| 128K | 約17.2GB | 約21.5GB | 約25.8GB | 約43GB |
| 256K | 約34.4GB | 約43GB | 約51.5GB | 約86GB |
| 1M | 約137GB | 約172GB | 約206GB | 約344GB |
※いずれもfp16・バッチ1・上記のレイヤ数/KVヘッド数/ヘッド次元を仮定した概算値。実際のモデルはconfig.json上の数値によって上下する。GGUF量子化モデルの選び方はGGUF量子化の選び方で解説している。
GQA/MQAでKVキャッシュが激減する仕組み
初期のTransformerが採用していたMHA（Multi-Head Attention）では、クエリヘッドの数だけKVヘッドも存在し、ヘッド数が多いモデルほどKVキャッシュも比例して膨張した。これに対し、Llama 2以降の主流モデルが採用するGQA（Grouped Query Attention）は、複数のクエリヘッドで1組のKVヘッドを共有する方式で、たとえばクエリヘッド32本に対しKVヘッドを8本に間引けば、KVキャッシュは単純計算で4分の1になる。さらに踏み込んでKVヘッドを1本にまで減らすのがMQA（Multi Query Attention）で、削減効果は最大化されるが表現力の低下によるわずかな精度劣化とのトレードオフになる。2026年時点の主要なオープンウェイトモデルがこぞってGQAを採用しているのは、長コンテキスト化が進むほどKVキャッシュのコストが無視できなくなっているためだ。1Mコンテキストを謳うモデルの実例は1Mコンテキストモデルの解説でも紹介している。
KVキャッシュの量子化による削減効果（fp16 / q8 / q4）
| 精度 | 1要素あたりのバイト数 | fp16比の削減率 | 品質への影響の目安 |
|---|---|---|---|
| fp16 / bf16 | 2バイト | 基準（削減なし） | 劣化なし |
| q8（int8相当） | 1バイト | 約50%減 | ほぼ無視できる範囲（多くのベンチマークで誤差レベル） |
| q4（int4相当） | 0.5バイト | 約75%減 | 長文脈での参照精度がわずかに低下する場合がある。会話用途では許容範囲のことが多いが、コード生成や数値の正確な参照が必要な用途では検証を推奨 |
MoEモデルにおける注意点 — KVキャッシュは「アクティブパラメータ」では決まらない
MoE（Mixture of Experts）モデルは「総パラメータ300億のうちアクティブなのは30億だけ」のように、推論時に使う重みを一部の専門家（エキスパート）に絞ることで計算量を抑える方式である。ただし、この省略が効くのはFFN（フィードフォワード）層の重み計算だけであり、KVキャッシュを生み出す自己注意（Attention）層は基本的に全レイヤで通常どおり計算される。つまり、MoEモデルは重み自体のVRAM消費とアクティブ計算量は小さくできても、KVキャッシュのサイズは「総レイヤ数×KVヘッド数×ヘッド次元」という同じ式に従い、同程度のレイヤ構成を持つ密（dense）モデルとほぼ変わらない。「アクティブパラメータが小さいから省メモリ」という理解のまま長いコンテキストを投入すると、想定より早くVRAMを使い切ることになるため注意したい。
OOMを避けるための実践的な設定
- 実際に必要なコンテキスト長を見極め、上限を絞って起動する（1Mまで確保する必要がない用途がほとんど）
- llama.cppなどで --cache-type-k / --cache-type-v にq8_0やq4_0を指定し、KVキャッシュ自体を量子化する
- Flash Attention（またはPaged Attention）に対応した推論エンジンを使い、メモリの断片化と無駄な確保を防ぐ
- バッチサイズを1に固定し、複数リクエストの同時処理によるKVキャッシュの重複確保を避ける
- GPUオフロード層数（n-gpu-layers等）を調整し、KVキャッシュ分の余白をVRAMに残す
- GQA/MQA採用モデルを優先的に選び、同じパラメータ規模でもKVヘッド数の少ない構成にする
- VRAMに収まりきらない分のKVキャッシュをCPU RAMにオフロードできる推論エンジン・設定を検討する
- 会話が長く続くチャット用途では、古いターンを要約・破棄してコンテキストを定期的にリセットする
実運用でのVRAM見積り手順
ローカルLLMの必要VRAMを見積もる際は、(1)量子化後のモデル重みサイズ、(2)想定する最大コンテキスト長でのKVキャッシュ、(3)推論時の一時的なアクティベーション・バッファ（多くの場合数百MB〜1GB程度）、(4)OSのデスクトップ描画やディスプレイ出力に使われるオーバーヘッド（同じGPUを使う場合は0.5〜1.5GB程度）、の4項目を合算するのが基本である。モデル単体のVRAM要件はGemma 4 の必要スペック記事のような個別記事で確認できるが、そこに記載されている数値の多くは短いコンテキストでの計測値であり、実際に長文の資料を読み込ませたり長い会話を続けたりする場合は、本記事の式でKVキャッシュ分を上乗せして見積もる必要がある。
よくあるトラブルシューティング
「モデルは問題なくロードできたのに、長い文章を貼り付けた途端にOOMになる」というケースは、モデル重みのVRAMだけを基準にVRAM容量を選んでしまい、KVキャッシュの増分を見込んでいないことがほとんどである。同様に「会話を続けていると2回目・3回目の応答で急に落ちる」場合は、チャット履歴が毎ターン蓄積してコンテキスト長が伸び続け、KVキャッシュが右肩上がりに膨張していることが原因であることが多い。この場合は、コンテキスト長の上限設定を見直す、古い会話ターンを要約して破棄する、KVキャッシュの量子化を有効にする、といった対処が有効だ。推論エンジンの選び方によってもKVキャッシュの扱いやすさは変わるため推論エンジンの比較記事もあわせて参考にしてほしい。
KVキャッシュを量子化しても大丈夫か？
多くの推論エンジン（llama.cpp等）はKVキャッシュ専用の量子化オプション（q8_0/q4_0など）を提供しており、q8程度なら出力品質への影響はごく小さいとされる。q4まで踏み込むと長文脈での参照精度がわずかに低下する場合があるため、コード生成や数値を正確に扱う用途では品質を実際に検証してから採用するのが望ましい。
KVキャッシュをRAMにオフロードできるか？
一部の推論エンジンはKVキャッシュの全部または一部をCPU RAM側に置く設定を持つが、GPUとCPU間の転送がボトルネックになり生成速度は大きく低下する。VRAMが不足する場合の緊急回避策としては有効だが、常用する場合はVRAM容量の大きいGPUを選ぶか、コンテキスト長・量子化で調整する方が実用的である。
Apple SiliconのユニファイドメモリではKVキャッシュはどう扱われるか？
Apple SiliconはCPUとGPUが同じメモリプールを共有するため、専用VRAMのように別枠で確保する必要がなく、システムメモリの空き容量までKVキャッシュを伸ばせる点が利点になる。ただし総メモリ量自体は搭載RAMの上限で頭打ちになり、OSや他アプリも同じプールを使うため、計算式で見積もった量がそのまま使える保証はなく、実機での確認が推奨される。
コンテキストを伸ばすと生成が遅くなるのはなぜか？
KVキャッシュが大きくなるほど、新しいトークンを1つ生成するたびに参照するK・Vベクトルの量が増え、注意計算のコストがコンテキスト長にほぼ比例して増加するためである。加えてKVキャッシュ自体のメモリ帯域消費も増えるため、体感速度（トークン/秒）はコンテキストが伸びるほど低下していく。
1Mコンテキストを実用するにはどれくらいのVRAMが必要か？
本記事の早見表が示す通り、7B級モデルでも1Mコンテキストのフル活用にはfp16換算で100GBを超えるKVキャッシュが必要になり得る。q4量子化を適用しても数十GB規模は残るため、コンシューマー向けGPU1枚での運用は現実的ではなく、大容量VRAMを持つワークステーション用GPUの複数枚構成や、実際に使うコンテキスト長を数万〜十数万トークン程度に抑える設計が現実的な落としどころになる。
この記事に関連する無料ツール（登録不要・その場で結果）
お気軽にご相談ください
お問い合わせ