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が変えたのは、まさにその点である。

LLM Inference on KnightLiブログ