DeepSeek V4の「メモリ98％削減」は総VRAMの話ではない

DeepSeek V4について語られる「メモリを98％削減」という見出しは、かなり注意して読む必要があります。現時点で公開情報から強く言えるのは、長文コンテキスト推論におけるKV cacheの圧縮とattention計算の削減です。これをそのまま「モデルを動かすための総VRAM、つまりGPUメモリ全体が98％減る」と読むのは飛躍があります 。

まず結論：安全な言い方は「KV cacheの圧力を大きく下げる」

DeepSeek V4を正確に説明するなら、次のように言うのが無難です。

DeepSeek V4はHybrid Attention、Compressed Sparse Attention（CSA）、Heavily Compressed Attention（HCA）などにより、長文推論で問題になりやすいKV cacheとattentionコストを大幅に抑える設計を採用している。ただし、公開情報だけでは「総VRAMが98％削減される」とは確認できない 。

この違いは、導入検討やGPU台数の見積もりでは非常に重要です。KV cacheは、長い文書や長時間のエージェント処理で大きなボトルネックになり得ます。しかし、LLMを実際に動かすときのメモリ消費は、KV cacheだけで決まるわけではありません。

公式・技術資料で確認できること

DeepSeekのAPIニュースページでは、DeepSeek-V4 Previewが2026年4月24日にリリースされたとされています 。モデルカードでは、DeepSeek V4シリーズにDeepSeek-V4-ProとDeepSeek-V4-Flashが含まれ、DeepSeekMoE frameworkとMulti-Token Prediction（MTP）strategyを引き継ぎつつ、Hybrid Attention Architectureなどの変更を加えたMoE、つまりMixture-of-Experts型の言語モデル系列だと説明されています 。

メモリ効率に直接関係するのは、長文コンテキストでのattention処理です。NVIDIAの技術記事によると、V4の**Compressed Sparse Attention（CSA）はdynamic sequence compressionでKV entriesを圧縮し、KV cache memory footprintを減らしたうえで、DeepSeek Sparse Attention（DSA）によってattention matricesをより疎にします。さらにHeavily Compressed Attention（HCA）**は、複数トークン群にまたがるKV entriesを単一のcompressed entryにまとめ、KV cache sizeをさらに小さくする設計です 。

つまり、資料から直接読み取れるのは「KV cache sizeとattention計算の削減」であり、「GPUメモリ全体が同じ割合で減る」という話ではありません。

98％、90％、9.5倍を混同しない

数字が一人歩きしている原因は、異なる主張が同じ「省メモリ」という言葉で語られている点にあります。

言い方	根拠の状態	読み方
総VRAMが98％減る	公式資料では確認しにくい	調達仕様や対外説明にそのまま使うのは危険
KV cacheを大きく圧縮	技術資料で確認できる	CSA/HCAが長文コンテキストのKV entriesを圧縮する
KV cacheが10％	第三者報道で確認できる	V3.2比で約90％のKV cache削減と読めるが、総VRAM削減ではない
メモリ要件が9.5倍低い	第三者ニュースの見出し	単純計算では約89.5％削減だが、対象範囲の確認が必要

最も直接的に「98％」が出てくるのは、LinkedInのユーザー生成記事のタイトルです。その記事は「DeepSeek Sparse Attention Shrinks KV Memory by 98 Percent in Real World Serving」とうたっていますが、これはDeepSeekの公式スペックとして扱うべき資料ではありません 。

一方、比較的確認しやすい数字としては、Wccftechが報じた「DeepSeek V3.2比でsingle-token inference FLOPsが27％、key-value（KV）cacheが10％」というものがあります 。仮にKV cacheが10％なら、KV cacheについては約90％削減と読めます。ただし、比較対象はV3.2であり、すべてのコンテキスト長、バッチサイズ、同時接続数、サービング構成、ハードウェアで同じ結果になるとは限りません 。

また、別のニュースでは「9.5x lower memory requirements」という見出しもあります 。1÷9.5は約10.5％なので、単純計算では約89.5％削減です。これも98％ではなく、さらにそれがKV cacheを指すのか、特定の長文推論条件なのか、完全なデプロイ時のメモリなのかを確認する必要があります 。

なぜKV cache削減は、総VRAM削減と同じではないのか

KV cacheは、生成済み・入力済みトークンのkey/value情報を保持し、次のトークン生成で再利用するための領域です。長い会話、長文書、ツール呼び出しを続けるエージェント処理では、コンテキストがどんどん伸びるため、KV cacheがGPUメモリを圧迫しやすくなります。

Hugging FaceのDeepSeek V4紹介では、長時間のagentic workloadではツールの結果がcontextに追加され続け、後続トークンはより長い履歴に対して計算することになると説明されています。そこで重要になる指標が、single-token inference FLOPsとKV cache sizeであり、どちらもsequence lengthに伴って増えます 。Hugging FaceのGitHub版でも、長いタスクで起きやすい失敗として、traceがcontext budgetを超える、KV cacheがGPUを埋める、ツール呼び出しの往復で処理が遅くなる、といった点が挙げられています 。

ただし、実際のVRAM使用量には、モデル重み、MoEのexpert weights、activations、KV cache、フレームワークのオーバーヘッドなどが含まれます。興味深いことに、98％という表現を掲げたLinkedIn記事自体も、shared weights、expert weights、activations、KV cache、framework overheadを分けて記載しています 。これはむしろ、容量設計ではメモリ項目を分けて見るべきだということを示しています。

CSA/HCAは重要な効率化だが、魔法の数字ではない

DeepSeek V4の方向性が注目に値するのは、100万トークン級の長文コンテキストで高くつくattentionとKV cacheに正面から取り組んでいるからです。NVIDIAの説明では、CSAはKV entriesの圧縮とattention matricesの疎化により、HCAは複数トークンのKV entriesを単一のcompressed entryに統合することで、KV cache sizeと計算コストを下げます 。

DeepSeek V4の技術報告でも、MoE modules向けのsingle fused kernelを設計し、computation、communication、memory accessを重ね合わせるなど、学習・推論基盤の最適化が説明されています 。こうした工夫は実用上大きな意味を持ちますが、それでも「総VRAM98％削減」の直接証拠ではありません。

導入判断では、自社のボトルネックを測るべき

DeepSeek V4を長文書処理、長い対話、エージェント型ワークロードで検討するなら、「98％」という見出しよりも、自分たちの負荷で何がボトルネックなのかを見るべきです。公開情報からは、V4が長文推論時のKV cacheに対して明確な最適化を持つことは言えます。しかし、その事実を「総VRAMが98％減る」として調達仕様、容量計画、マーケティング文言に書くには根拠が足りません 。

実務では、想定するcontext長、batch size、concurrency、serving engine、GPU構成でベンチマークを取るのが安全です。もし制約がKV cacheにあるなら、DeepSeek V4の圧縮設計は大きな価値を持つ可能性があります。反対に、ボトルネックがモデル重み、activation、フレームワークのオーバーヘッド、同時実行戦略にあるなら、KV cacheが減っても総VRAMが同じ割合で減るとは限りません 。