deep guide

コンテキスト長とKVキャッシュ｜メモリへの影響を理解する

「コンテキスト長を長くするとメモリが足りなくなる」と聞きますが、実際にどれくらい増えるのか、 仕組みから説明します。数値は理論的な目安であり、実測値ではありません。

読了後に判断できること：KVキャッシュがなぜコンテキスト長に比例するか、 4k/8k/32k でざっくりどれくらい増えるかの見積もり方、長くしすぎる前の確認事項。

コンテキスト長とは

コンテキスト長（context length）は、モデルが一度に「把握できる」トークン数の上限です。 入力した履歴とこれから生成する分を合わせた長さがこの上限を超えると、古い部分が切り捨てられたり、 エラーになったりします。LM Studio 等の既定値はモデルによって異なりますが、8k トークン程度が目安になることが多いです。

既定値はアプリ・モデルのバージョンで変わります。正確な値は使用するアプリの設定画面で確認してください。

KVキャッシュとは

Transformer は自己注意（self-attention）において、各トークンの Key（K）と Value（V）を計算し、 それをKVキャッシュとして保持します。これにより、毎回すべてのトークンを再計算せずに済みますが、 保持する分のメモリがコンテキスト長に比例して増大します。 

context tokens:  [t1][t2][t3] ... [tn]
                    │    │    │        │
                  K,V  K,V  K,V      K,V   ← 各トークン分を保持
                    └──────────────────┘
              KV cache サイズ ∝ n (コンテキスト長)

概念図。実際のサイズは層数・head数・head_dim・K/Vの精度に依存。

理論式（目安）

Transformer の標準的な構造では、KVキャッシュの理論バイト数は次の形で見積もれます。

KV bytes ≈ context_tokens × layers × kv_heads × head_dim × (bytes_K + bytes_V)
  • layers：モデルの層数（アーキテクチャ依存）
  • kv_heads：KV を計算する head 数（GQA では query head より少ない）
  • head_dim：各 head の次元数
  • bytes_K / bytes_V：K/V の1要素のバイト数（fp16 なら2、q8_0 等の量子化ならさらに小さい）
この式は「適用条件付きの目安」です。 実際のサイズは、モデル実装・padding・alignment・flash attention・KV量子化・sliding window 等で変わります。 アーキテクチャ情報（layers/kv_heads/head_dim）が分からなければ、正確な数値は出せません。 その場合は「情報不足」として、LM Studio の resource estimate や実測で確認してください。

4k / 8k / 32k のざっくり例

以下は仮のモデル（layers=32, kv_heads=8, head_dim=128, fp16）で計算した 理論的な目安です。実際のモデルでは layers/kv_heads/head_dim が異なるため、あくまで「増え方の傾向」をつかむための例です。

KVキャッシュの理論的目安（仮モデル・fp16）
コンテキスト長KVキャッシュ（目安）倍率
4,096 tokens約 0.50 GB1×
8,192 tokens約 1.00 GB2×
32,768 tokens約 4.00 GB8×

計算式：context × 32 × 8 × 128 × (2+2) bytes = context × 32,768 bytes。 例は fp16（1要素2バイト）の場合。KV量子化（q8_0 等）を使えばさらに小さくなりますが、品質への影響はモデル次第です。 重要なのは「コンテキスト長を4倍にするとKVキャッシュも約4倍」という比例関係です。

GQA / MHA の違い

GQA（Grouped Query Attention）は、複数の query head で KV head を共有する仕組みです。 KV head 数が query head 数より少なくなるため、KVキャッシュが小さく抑えられます。 一方 MHA（Multi-head Attention）は各 query に独立の KV があるため、同じ規模でも KVキャッシュが大きくなりやすいです。

多くの最近のモデル（Llama系など）は GQA を採用しており、これも「長いコンテキストを扱いやすくする」一因です。 ただし KV head 数はモデルごとに異なるため、数値は各モデルのアーキテクチャ情報で確認してください。

GPUオフロードとの関係

KVキャッシュが VRAM に乗るか RAM に乗るかは、GPUオフロードの設定に依存します。 全レイヤーを GPU に乗せる（full offload）なら KVキャッシュも VRAM 上、部分オフロードなら 配置先が分かれることがあります。ここでも「VRAM 使用量を精密に断定する」ことは、配置ルール・実装に依存するため避け、 LM Studio の resource estimate や実測で確認するのが確実です。

コンテキスト長を変える前に：① 自分の VRAM/RAM の空き、② モデルの規模・量子化、③ アプリの既定値を確認。 長くしすぎてメモリ不足になる場合は、まず既定値（多くは8k付近）から始めるのが無難です。

適用外と不確実性

  • 上記の数値は特定の仮モデル・fp16 での理論目安。実機では padding/alignment/flash attention/KV量子化/sliding window で変動。
  • MoE モデルでは active params が変わっても、KVキャッシュの構造（layers×kv_heads×head_dim）は Dense と同様のことが多いが、実装依存。
  • 「KVキャッシュが2倍になる」といった単純な倍数は、アーキテクチャ非依存ではないため使わない。
  • 実測は、使用するアプリの resource estimate 表示や、タスクマネージャーの観察で行ってください。
メモリ・VRAMの目安へ resource estimate コマンド作成ツールへ チェッカーで選ぶ

更新履歴：2026-07-18 新規 deep guide として追加。