KVキャッシュ
KVキャッシュは、モデルが読んだトークンごとのKey/Value表現を保存しておく作業メモリです。これがあるから毎トークンの生成が高速に回るのですが、コンテキスト長に比例してVRAMを消費します。そして2025年以降、このキャッシュをどう圧縮するかがモデル設計の主戦場になっています — 同じ8Kトークンでも、設計次第でサイズが25倍違います。
基本形(GQA)の計算式
標準的なモデル(GQA=Grouped Query Attention)のKVキャッシュは次で決まります:
2 (KとV) × 層数 × KVヘッド数 × ヘッド次元 × トークン数 × 2バイト(FP16)例: Llama 3.3 70B(80層・KV8ヘッド・次元128)の8Kトークンは 2×80×8×128×8192×2B ≒ 2.7GB。当サイトの必要VRAMはこの式で計算しています。GQAはKVヘッド数を注意ヘッド数より減らす(64→8など)ことで、旧来型(MHA)の1/8に圧縮した、いわば第一世代の圧縮です。
第二世代の圧縮たち — 実在モデルの実数で
| 方式 | 仕組み | 実例(8Kトークン時・当サイト計算) |
|---|---|---|
| MLA (DeepSeek系) | KVをヘッドごとに持たず、層ごとに1本の圧縮潜在ベクトル(+共有RoPEキー)だけ保存 | Kimi K2.6: 0.58GB(GQA式なら14.3GB — 25分の1) GLM-4.7-Flash: 0.44GB(同3.15GB) |
| Sliding window (Gemma系・gpt-oss) | 大半の層は直近の窓(512〜1024トークン)しか見ない=キャッシュも窓分だけ | Gemma 4 12B(48層中フル注意8層): 0.87GB(全層フルなら3.2GB) |
| 線形注意ハイブリッド (Qwen3.5/3.6系) | 大半の層が固定サイズの状態しか持たず、文脈が伸びても増えない | Qwen3.5 9B(32層中フル8層): 0.27GB(全層フルなら1.1GB) |
当サイトはこれらの方式差をモデルごとに判定へ反映しています(config.jsonのkv_lora_rankやlayer_typesを実測)。「長文に強い設計かどうか」は、各モデルページの必要VRAMにすでに織り込み済みです。
実用面で知っておくと得なこと
- KVキャッシュ自体の量子化も可能です(llama.cppの
--cache-type-k q8_0など)。長文用途の最後の一絞りに - 「短い会話ならギリギリ動く」= 重みは載るがKVの余白が薄い状態。当サイトの△注記「2Kトークンまで絞れば動く」はまさにこれ
- MoEかどうかとKV方式は独立です(Kimi=MoE+MLA、Gemma=密+sliding、など組み合わせは自由)
関連用語
- コンテキスト長 — モデルが一度に覚えていられる会話・文書の長さ。長いほどKVキャッシュがVRAMを食う
- VRAM(ビデオメモリ) — GPUに載っている専用メモリ。ローカルLLMで動くモデルの大きさを決める最重要スペック
- Transformer — 現代のLLMほぼ全ての土台となるアーキテクチャ。注意機構(Attention)で文脈を読む
- MoE(Mixture of Experts) — 「総パラメータは大きいが、毎回動くのは一部だけ」という設計。容量は総量・速度は実効で決まる
参考資料(出典)
▶ あなたのPCで動くモデルを自動判定する(スペック送信なし・ブラウザ内完結)
上記はアフィリエイトリンクです。経由して課金された場合、当サイトに紹介料が入ります。