KV Cache on KnightLiブログ

DeepSeek-V4のKV Cache解説：1MコンテキストでVRAMを節約できる理由

Mon, 18 May 2026 18:38:26 +0800

長文コンテキストモデルで本当に高くつくのは、100万Tokenを入力できるかどうかだけではない。推論時にKV CacheがどれだけVRAMを使うかだ。

Transformerのデコードでは、新しいTokenを1つ生成するたびに、過去Tokenに対応するKeyとValueを保持する必要がある。コンテキストが長くなるほどKV Cacheは大きくなり、VRAM、メモリ帯域、初回Token遅延、スループットを圧迫する。

DeepSeek-V4の特徴は、注意ヘッド数だけでキャッシュを節約するのではなく、圧縮をシーケンス長の次元へ進めたことにある。Hugging FaceによるDeepSeek-V4の解説では、1M Tokenの場面で、DeepSeek-V4-ProのKV CacheはDeepSeek-V3.2のおよそ10%、一般的なbf16 GQA構成のおよそ2%程度とされている。

ここがDeepSeek-V4のキャッシュ機構で最も注目すべき点だ。KVを単に小さく保存するだけではなく、長期保存・検索が必要なKVエントリ数そのものを減らしている。

KV Cache最適化の流れ

KV Cache最適化には、いくつかの代表的な流れがある。

第一は従来のMHA、つまりMulti-Head Attentionだ。各Queryヘッドが対応するKey/Valueヘッドを持つ。構造は直接的だが、長文コンテキストではキャッシュがシーケンス長に比例して増え、VRAM負荷が最大になる。

第二はGQA、Grouped Query Attentionだ。複数のQueryヘッドがより少ないKey/Valueヘッドを共有する。LLaMA、Mistral、Qwenなど多くの現代的なモデルが似た考え方を採用している。KVヘッド数を大きく減らせるため、長文コンテキストモデルの標準的な節約手法になっている。

第三はMLA、Multi-head Latent Attentionだ。DeepSeek-V2やDeepSeek-V3はこの方式を使い、Key/Valueを低ランクの潜在表現へ圧縮し、注意ヘッド次元でさらにキャッシュを削減する。

第四がDeepSeek-V4のハイブリッド圧縮注意機構だ。焦点はシーケンス長にある。各Tokenが保存するKVを小さくするだけでなく、複数の過去Tokenを少数のKVエントリへ圧縮し、疎または密な注意で検索する。

大まかに言えば：

MHA：各ヘッドが個別に記憶する。
GQA：複数のQueryヘッドが一部の記憶を共有する。
MLA：各TokenのKV表現を潜在ベクトルへ圧縮する。
DeepSeek-V4：多くの過去Tokenをより少ない圧縮記憶ブロックへ集約する。

重要な変化：ヘッド次元からシーケンス次元へ

GQAとMLAは主に「各TokenがどれだけKVを保存するか」を最適化する。この方向は有効だが、コンテキストが1M Tokenまで伸びると、Token数そのものが問題になる。

DeepSeek-V4は古いコンテキストをブロックへ圧縮する。つまり、遠い過去のすべてのTokenに完全なKVを保持するのではなく、複数Tokenを圧縮エントリにまとめる。

長い本を読むときに似ている。直近の数ページは細部まで覚えているが、前の章は要約、テーマ、重要な手がかりとして覚える。DeepSeek-V4の注意機構も同じように、近い場所では細部を残し、遠い場所では圧縮表現を使う。

CSA：4倍圧縮と疎検索

CSAはCompressed Sparse Attentionの略で、より細かい粒度の長距離圧縮機構だ。

CSAでは、隣接するTokenを少数のKVエントリへ圧縮する。Hugging Face Transformersドキュメントでは、デフォルト圧縮率は m=4 とされており、おおよそ4Tokenごとに1つの圧縮エントリが作られる。

ただし単純平均ではない。CSAは学習可能な圧縮プールと重なり窓を使い、圧縮時に有用な情報を残す。圧縮後、Queryはすべての圧縮ブロックへ直接注意を向けるのではなく、Lightning Indexerでスコアを付け、関連度の高いtop-k圧縮ブロックを選んでから主要な注意計算に入る。

この構造には2つの利点がある。

過去のKVエントリ数が少なくなる。
各Queryは関連する一部の圧縮ブロックだけを見る。

CSAは、コードベース、長文書、ツール呼び出し履歴のように、遠い情報でも細部検索が必要な場面に向いている。

HCA：128倍圧縮と密な注意

HCAはHeavily Compressed Attentionの略で、より強い圧縮を行う。

Transformersドキュメントでは、デフォルト圧縮率は m'=128 とされている。HCAは長いコンテキスト区間を1つの圧縮エントリへまとめる。圧縮後のシーケンスは非常に短いため、CSAのような疎なtop-k検索は不要で、すべてのHCA圧縮エントリに対して密な注意を計算できる。

HCAはグローバル要約に近い。すべての細部を保存するのではなく、非常に低コストで長い履歴範囲を覆い、モデルが全体背景、長期テーマ、遠方情報を把握し続けるために使われる。

CSAが「検索できる圧縮ノート」なら、HCAは「全体目次と要約」に近い。

スライディングウィンドウ：近い文脈は細部を残す

DeepSeek-V4はすべての文脈を圧縮するわけではない。

CSAとHCAに加えて、最近の未圧縮コンテキストを扱うスライディングウィンドウ分岐を残している。Transformersドキュメントでは、DeepSeek-V4のattention blockが長距離圧縮分岐とスライディングウィンドウのK/Vを結合すると説明している。

これは重要だ。次のTokenを生成するとき、直近の文脈が最も重要なことが多い。変数名、関数シグネチャ、書いている途中の文、直近のツール結果、最新のユーザー指示などだ。これらを過度に圧縮すると出力品質が落ちる。

DeepSeek-V4の考え方はこうだ。

近い文脈：未圧縮の細部を保持する。
中距離から長距離：CSAで検索可能な圧縮を行う。
さらに遠い文脈：HCAで強く圧縮した全体要約を使う。

ハイブリッド層スタック：層ごとに異なる注意

DeepSeek-V4は全層で同じ注意機構を使わない。

Hugging FaceのDeepSeek-V4記事では、V4-Proの61層構造で、最初の2層がHCA、その後の層がCSAとHCAを交互に使い、最後のMTP blockがスライディングウィンドウを使うと説明されている。Transformersドキュメントも、V4-Proは2層のHCA bootstrapと交互のCSA/HCA層を使うと説明している。

これはDeepSeek-V4が注意機構を階層システムとして設計していることを示す。層によって情報流の役割が異なり、ある層は全体圧縮を重視し、ある層は疎検索を重視し、ある部分は局所ウィンドウを保持する。

単一の注意機構を全層で使うより複雑だが、1M Tokenのような極端な長文コンテキストには適している。

FP8とFP4がさらにキャッシュコストを下げる

DeepSeek-V4の節約は圧縮率だけではない。

Hugging Faceの記事では、V4の多くのKVエントリはFP8で保存され、RoPE関連次元はBF16のまま、CSAのLightning IndexerはFP4を使うとされている。圧縮率、低精度保存、疎検索が組み合わさって、非常に低いKV Cache使用量になる。

これは重要な注意点でもある。宣伝文句としての「1Mコンテキスト長」だけを見るべきではない。実際にデプロイできるかどうかは、長文コンテキスト時のVRAM使用量、帯域圧力、推論遅延、実装品質で決まる。

他のモデルとの違い

従来のMHAと比べると、DeepSeek-V4は長い履歴のすべてのTokenに完全な注意記憶を保持しないため、キャッシュ圧力が大きく下がる。

GQAと比べると、DeepSeek-V4はKV head数を減らすだけではない。長い履歴に対するKVエントリ数も減らす。GQAは依然としてシーケンス長に比例してキャッシュが増えるが、V4は遠い文脈をブロックへ圧縮する。

DeepSeek-V3のMLAと比べると、V4は「各Tokenの表現をよりコンパクトにする」だけでなく、「履歴Tokenの数も圧縮する」方向へ進んでいる。MLAは単TokenあたりのKVコストを大きく下げるが、百万Token級ではシーケンス長そのものが依然として圧力になる。

普通の疎注意と比べると、DeepSeek-V4のCSAは先に圧縮し、短くなった圧縮シーケンスに対して疎検索を行う。HCAはさらに進み、128倍圧縮によって全量の密な注意も安くする。

Agentと長時間タスクへの意味

Agentワークフローは長文コンテキストを大量に使う。ファイルを読み、ツールを呼び、ツール結果を受け取り、計画を作り、計画を修正し、さらにツールを呼ぶ。コンテキストが長くなるほど、KV Cacheはボトルネックになりやすい。

DeepSeek-V4のキャッシュ設計には次のような価値がある。

長いコードベース、長文書、多段のツール履歴を扱いやすい。
初回Token遅延とスループットがKV Cacheに引きずられにくい。
同じハードウェアでより長いコンテキストやより多い同時リクエストを扱える。
100万Tokenコンテキストが、単なるベンチマークではなく実運用に近づく。

ただし圧縮注意は無料ではない。履歴Tokenをブロックへ圧縮する以上、情報の取捨選択が起きる。モデルはVRAM節約と、検索可能な細部保持のバランスを取らなければならない。コード探索、法律文書、長文QA、Agentツールチェーンでは、細部をどれだけ思い出せるかの要求が異なる。

2%を全コスト2%と読んではいけない

「KV CacheがGQAの約2%」という表現は誤解されやすい。

これは主にKV Cacheのメモリサイズの話であり、総推論コストが2%になるという意味ではない。すべての場面で50倍速くなるわけでもない。推論にはモデル重みの読み出し、MoEルーティング、FFN、注意計算、スケジューリング、通信なども含まれる。

Hugging Faceの記事でも、1M Token文脈でDeepSeek-V4-Proの単Token推論FLOPsはDeepSeek-V3.2の27%、KV Cacheは10%と分けて説明されている。キャッシュと計算は別の次元だ。

より安全な言い方は、DeepSeek-V4は超長文コンテキストのKV Cache圧力を大きく下げ、百万Token級のデプロイ可能性を改善する、というものだ。実際のレイテンシとスループットは、実装、ハードウェア、バッチ処理、量子化、推論フレームワークに依存する。

まとめ

DeepSeek-V4のキャッシュ機構が他の大規模モデルと最も違う点は、KV Cache最適化を注意ヘッド次元からシーケンス長次元へ進めたことだ。

GQAはKVヘッドを少なく保存する。MLAは各TokenのKV表現をよりコンパクトにする。DeepSeek-V4はさらに、遠いTokenを圧縮ブロックへ集約し、CSA、HCA、スライディングウィンドウ、低精度保存を組み合わせ、百万TokenコンテキストがKV Cacheで簡単に詰まらないようにしている。

これは単一のテクニックではない。近くは細部を残し、遠くは圧縮し、必要な細部は疎検索し、全体は強い要約で見るという、長文コンテキスト推論のためのアーキテクチャだ。

開発者やAgentアプリケーションにとって意味は明確だ。長文コンテキストは、単に多く入力できるだけでは足りない。動き、安定し、コストが許容できなければならない。DeepSeek-V4が変えたのは、まさにその点である。

参考資料

8GB VRAM で llama.cpp をどう調整するか: 32K の方が安定しやすく、64K では KV Cache 量子化が重要

Thu, 23 Apr 2026 12:13:04 +0800

8GB の VRAM でローカル LLM をスムーズに動かせるのか、特に長いコンテキストで速度を維持できるのかは、llama.cpp を使う人がよく直面する問題です。

まず覚えておきたいポイントは 3 つあります。

8GB VRAM では、32K コンテキストの方が安定したバランスになりやすい
どうしても 64K を使いたいなら、KV Cache の量子化がほぼ必須になる
フル GPU 推論では、CPU スレッド数をむやみに増やすとかえって遅くなることがある

1. まず、32K・64K・KV Cache とは何か

この手の調整記事で最初につまずきやすいのが、この 3 つの用語です。

32K と 64K はコンテキスト長を意味し、モデルが一度に処理できる token 数の上限を表します。ここでの K は千なので、32K は約 32000 token、64K は約 64000 token です。コンテキストが長いほど、モデルは一度により多くの過去情報を見られるため、長文読解、長い対話、複数段階の分析に向いています。

KV Cache は、連続生成を高速化するためにモデルが保持する中間結果のキャッシュです。すでに読んで計算済みの部分を毎回最初から計算し直すのではなく、重要な中間情報を保存して再利用する仕組みだと考えるとわかりやすいです。K と V は Transformer の Key と Value を指します。

この 3 つがいつも一緒に出てくるのは、次の関係があるからです。

32K と 64K は、一度にどれだけの内容を記憶させたいかを決める
KV Cache は、その記憶を維持するためにどれだけ追加の VRAM が必要かを決める
コンテキストが長くなるほど KV Cache は大きくなり、VRAM の負担も増える

そのため、長コンテキストで速度が落ちる原因は、モデルの計算能力不足というより、キャッシュが大きくなりすぎて VRAM が限界に近づくことにある場合が多いです。

2. なぜ 32K と 64K で速度差が大きくなるのか

たとえば《三体》の約 3 万字を使って負荷テストを行い、32K と 64K のコンテキストを比較すると、文章量が近くても 64K の方が大きく遅くなり、総処理時間もかなり長くなることがあります。

原因はモデルが急に遅くなったからではなく、VRAM の境界にぶつかったからです。

32K では、モデルの重みとキャッシュがまだ 8GB VRAM の中にほぼ収まり、データは主に GPU メモリ帯域の中で処理されます。ところが 64K にするとキャッシュがさらに増え、総使用量が VRAM 上限に近づくか超えてしまい、一部データが共有メモリやシステムメモリに押し出されます。

このとき落ちるのは演算性能そのものではなく、帯域です。

つまり、「コンテキストを倍にしたら急に遅くなった」という現象の本質は、データ経路が VRAM からより遅いメモリへ落ちたことにあります。

3. 64K を使うなら、KV Cache 量子化が重要

8GB VRAM 環境で特に重要なのが、KV Cache の量子化です。

モデル本体を変えず、キャッシュだけを量子化すると、長コンテキスト時のキャッシュ使用量を直接削減できます。すると、もともと VRAM からあふれていた一部のデータを 다시 VRAM 側に戻しやすくなります。その結果、64K は依然として 32K より重いものの、最も遅い領域に落ち込みにくくなります。

要するに、

32K は 8GB VRAM における実用的な標準レンジ
64K も不可能ではない
ただしキャッシュ量子化なしでは、「使える」から「かなり厳しい」へ一気に落ちやすい

長コンテキストを安定して使いたいなら、優先順位は次のようになります。

まず VRAM が上限に近づいていないか確認する
次に KV Cache 量子化を有効にするか判断する
その後で、より攻めたスループット設定を試す

4. GPU 使用率が低くても、GPU が遊んでいるとは限らない

これは直感に反しやすいポイントです。

タスクマネージャーで GPU 使用率が 20% や 30% しか見えないと、多くの人は次のように考えます。

パラメータ設定が間違っているのではないか
モデルが本当に GPU 上で動いていないのではないか
GPU を使い切れていないのではないか

しかし llama.cpp の推論では、ボトルネックがコア演算ではなくメモリ読み書きにあることがよくあります。

つまり、GPU コアはあるバッチの計算をすぐ終えても、次の重みやキャッシュデータが届くまで待たされる、という状態です。

その結果、

コア使用率はそれほど高くない
それでも全体の速度は伸びない

という現象になります。

これは GPU が怠けているのではなく、データ経路が狭いだけです。

そのため、ローカル LLM の速度を見るときは GPU Usage だけで判断してはいけません。VRAM 容量、メモリ帯域、キャッシュのあふれ方の方が重要なことが多いです。

5. スループット関連パラメータは効くことがあるが、VRAM 余裕が前提

GPU コアが完全には埋まっていないなら、スループット関連の設定を上げて一度に処理するデータ量を増やし、GPU の並列性をもっと引き出せるのではないか、という考え方があります。

これは実際に速度向上につながることがあります。

ただし前提条件があります。VRAM にまだ余裕があることです。

スループット関連の設定を上げると、VRAM 使用量も増えることが多いからです。すでに 64K、大きなキャッシュ、VRAM ぎりぎりという状態でさらに押し上げると、次のような結果になりがちです。

そのままクラッシュする
クラッシュしなくても、より遅い共有メモリモードに落ちる

したがって、より安全な順番は「最初に全部最大化する」ことではなく、

まず VRAM の境界を守る
次にスループット最適化を試す
変更のたびに速度と安定性を確認する

という流れです。

6. CPU スレッドは多ければ多いほどよいわけではない

これも覚えておきやすい落とし穴です。

スレッドが多いほど速いはずだ、と考えるのは自然です。しかし、モデルがすでに主に GPU で動いている場合、CPU スレッド数を無理に増やすとかえって性能が落ちることがあります。

理由は単純です。

フル GPU 推論では、CPU は主力の計算機というより、スケジューラや前処理補助の役割に近くなります。この状態でスレッドを増やしすぎると、CPU 側のスレッド競合、スケジューリング負荷、コンテキストスイッチのコストが大きくなり、本来スムーズであるべきデータの流れを乱してしまいます。

結果として、

CPU はより忙しそうに見える
それでも全体は遅くなる

ということが起きます。

この種の構成では、デフォルト設定や低めのスレッド数の方が、全部を最大化するより安定しやすいです。

7. 8GB VRAM 向けの、より実用的な考え方

ここまでの結論を実行しやすい形にまとめると、だいたい次のようになります。

1. まず 32K を標準目標にする

8GB GPU なら、最初から 64K を狙いにいかない方が無難です。32K の方が、速度・安定性・メモリ使用量のバランスが取りやすいことが多いです。

2. 64K を使いたいなら、まずキャッシュを見る

「あと少し速くできるか」より先に、KV Cache が量子化されているか、VRAM がすでに限界付近ではないかを確認すべきです。

3. GPU 使用率だけで判断しない

使用率が低いからといって設定ミスとは限りません。単にメモリ帯域が本当のボトルネックかもしれません。

4. スループット最適化は有効だが、VRAM 境界を越えない

これらの設定は確かに効くことがありますが、前提は VRAM に余裕があることです。

5. CPU スレッドは保守的に始める

モデルがほぼ GPU 上で動いているなら、CPU スレッド数は高ければよいわけではありません。まずはデフォルトか低めで試し、必要なら少しずつ調整します。

結論

この話の価値は、いくつかのベンチマーク数字そのものより、ひとつの見落とされがちな事実をはっきりさせてくれる点にあります。

ローカル LLM の調整で本当に大事なのは、すべての設定を最大にすることではなく、ボトルネックが演算性能なのか、VRAM 容量なのか、メモリ帯域なのか、それとも CPU のスケジューリングなのかを見極めることです。

8GB VRAM ユーザーにとって、より安全な方針は「最長コンテキストを無理に追う」ことではなく、まず VRAM の境界を守り、そのうえでどこまで伸ばすかを判断することです。

ひとことでまとめるなら、こうです。

32K は 8GB VRAM でより安定しやすい作業レンジであり、64K も不可能ではないが、その前提として KV Cache と VRAM 使用量をしっかり管理できている必要がある。