ローカルLLM のコンテキスト長と VRAM の関係 2026年版：KVキャッシュが効く仕組みと 128K コンテキストに必要なメモリの計算

結論：「モデルが乗る最小VRAM」だけ見て買うと、128K コンテキストで KVキャッシュがあふれて落ちます。長文・エージェント運用なら、モデル重み + KVキャッシュ込みで 1.5〜2倍の余裕を見るのが正解です。 70B クラスを 128K で回すと、KVキャッシュだけで約40GB。これは Q4量子化したモデル重み(約40GB)に匹敵する量です。

ローカルLLMの必要VRAMは「パラメータ数 × bit数 ÷ 8」で重みぶんは計算できますが、それだけでは足りません。コンテキスト（入力＋生成済みトークン）を保持する KVキャッシュ が、コンテキスト長に正比例して増えていくからです。Claude Code のようなエージェント、長文RAG、コードベース全体の読み込みが主戦場になった今、ここを読み違える失敗が一番多くなっています。

VRAMの中身そのものの基礎は「VRAMとは何か。ローカルLLM推論で必要な量の決まり方 2026年版」で扱っています。本記事はその「コンテキスト長 × KVキャッシュ」軸を詳しく見ます。

KVキャッシュとは何か：なぜコンテキストでメモリが増えるのか

Transformer は各トークンについて Key と Value のベクトルを計算します。生成のたびに過去全トークンの K・V を再計算するのは無駄なので、一度計算した K・V をVRAMにキャッシュしておき、次のトークン生成で使い回します。これが KVキャッシュです。

このキャッシュはトークン1個ごとに積み上がるため、コンテキストが長くなるほど線形に増えます。8K の会話なら小さいですが、128K のコンテキスト（書籍数百ページ相当、巨大なコードベース）になると、モデル重みに匹敵する量に膨れ上がります。モデル重みは固定なのに対し、KVキャッシュは「いま何トークン抱えているか」で動的に変わるのがポイントです。

KVキャッシュの計算式

KVキャッシュのサイズ（バイト）は次の式で概算できます。

KVキャッシュ = 2(K,V) × layers × kv_heads × head_dim × seq_len × bytes_per_element

• 2：Key と Value の2つ
• layers：層数（Llama 3.3 70B なら 80）
• kv_heads：KVヘッド数。GQA(Grouped Query Attention) で圧縮されているのがミソ（後述）
• head_dim：ヘッド次元（多くのモデルで 128）
• seq_len：コンテキスト長（トークン数）
• bytes_per_element：FP16なら2バイト、Q8なら1、Q4なら0.5

Llama 3.3 70B を例に「1トークンあたり」を計算すると、2 × 80 × 8 × 128 × 2バイト = 327,680バイト ≒ 0.31MB/トークン。これにコンテキスト長を掛ければ総量が出ます。

モデル別 × コンテキスト長別 KVキャッシュ早見表（FP16）

モデル	1トークンあたり	8K	32K	128K
Llama 3.1 8B（32層, 8 KVヘッド）	約 0.13MB	約 1GB	約 4GB	約 16GB
Llama 3.3 70B（80層, 8 KVヘッド）	約 0.31MB	約 2.5GB	約 10GB	約 40GB

70B の 128K = 約40GB という数字が効いてきます。Llama 3.3 70B を Q4 で動かすとモデル重みは約40GB。つまり 128K まで使い切ると、重み40GB + KVキャッシュ40GB = 約80GB が必要で、32GB の RTX 5090 一枚はもちろん、48GB でもあふれます。「70B が乗るから大丈夫」と 48GB を買った人が、長文を投げた瞬間にOOMで落ちるのはこのためです。

逆に 8B クラスなら 128K でも 16GB 程度で、24GB のGPUに余裕で収まります。長文・大コンテキスト運用ほど、モデルサイズよりKVキャッシュが効くと覚えておくとよいです。

GQA：KVキャッシュを8倍圧縮している仕組み

上の式で kv_heads が 8 と小さいのは、現代のモデルが GQA（Grouped Query Attention） を使っているからです。Llama 3.3 70B は Queryヘッドが64ある一方、KVヘッドは8つに共有されています。KVキャッシュは KVヘッド数に比例するので、これだけで 64 ÷ 8 = 8倍 の圧縮が効いています。

もし GQA が無ければ（旧来の Multi-Head Attention）、同じ 70B の 128K コンテキストで KVキャッシュは 約320GB に達していました。GQA があるからこそ 40GB で済み、ローカルでの長文運用が成立しているわけです。最近のモデルが軒並み GQA を採用しているのは、この KVキャッシュ削減が目的のひとつです。

KVキャッシュを節約する：量子化KVキャッシュ

KVキャッシュも、モデル重みと同じように量子化できます。llama.cpp なら --cache-type-k / --cache-type-v で K・V のデータ型を指定できます。

KVキャッシュ精度	70B の 128K でのKVキャッシュ	メモリ削減	体感品質
FP16（既定）	約 40GB	—	基準
Q8	約 20GB	半減	ほぼ劣化なし
Q4	約 10GB	1/4	長文でやや劣化することあり

Q8 KVキャッシュは品質劣化がほとんど体感できず、長コンテキストを使うなら積極的に検討する価値があります。Q4 まで落とすとメモリは1/4になりますが、超長文での参照精度がわずかに落ちる場合があるため、用途で使い分けます。「128K使いたいがVRAMが足りない」ときの最初の一手が、このKVキャッシュ量子化です。

実用結論：余裕の見積もり方

長文・エージェント用途で機材を選ぶときの目安です。

• 短い対話（〜8K）中心：KVキャッシュは数GB。モデル重みが乗れば十分。最小VRAMでよい
• 32K前後の通常運用：重み + 数GB〜10GBを上乗せ。重みのせられるVRAM + 1〜2割の余裕
• 128K のエージェント・長文RAG：重み + KVキャッシュで 1.5〜2倍 を見る。70Bなら実質80GB級、もしくは Q8 KVキャッシュ + 大容量ユニファイドメモリ機
• VRAMが足りないなら：まず Q8 KVキャッシュ、次にモデルサイズを下げる、の順で検討

「VRAM容量 ＝ モデルが乗るか」だけで判断せず、自分が普段投げるコンテキスト長を掛け算してから機材を選ぶ。これが長文時代のローカルLLM機選びの肝です。コンテキストを伸ばすと生成だけでなく入力処理（prefill）も遅くなりますが、その速度面は「ローカルLLM のプロンプト処理（prefill）実測ベンチ 2026年版」で扱っています。メモリ帯域がトークン速度を決める仕組みは「メモリ帯域幅とローカルLLMのトークン/秒 2026年版」を参照してください。

---

あなたに合うPCを診断する

用途や予算をもう少し細かく入力すると、3つの候補構成を提案します。

→ 診断スタート

関連記事

• VRAMとは何か。ローカルLLM推論で必要な量の決まり方 2026年版 — VRAMの中身（重み軸）の基礎。本記事のKVキャッシュ軸と対になる
• メモリ帯域幅とローカルLLMのトークン/秒 2026年版 — 帯域がトークン速度を決める仕組み
• ローカルLLM のプロンプト処理（prefill）実測ベンチ 2026年版 — 長コンテキストで効く入力処理速度
• ローカルLLMを動かすPCの最低スペック 2026年版 — 重み + KVキャッシュ込みの最低ライン