DeepSeek-V4 KV Cache 機制解析：為什麼 1M 上下文更省顯存

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

長上下文模型真正貴的地方，往往不是「能不能塞進 100 萬 Token」，而是推理時 KV Cache 要占多少顯存。

在 Transformer 解碼過程中，每生成一個新 Token，模型都要保留歷史 Token 對應的 Key 和 Value。上下文越長，KV Cache 越大；KV Cache 越大，顯存、記憶體頻寬、首字延遲和吞吐都會被拖慢。

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 頭。它結構直接，但長上下文下快取隨序列長度線性成長，顯存壓力最大。

第二類是 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 聚合成更少的壓縮記憶塊。

DeepSeek-V4 的關鍵變化：從頭維度壓縮到序列維度壓縮

GQA 和 MLA 主要是在「每個 Token 存多少 KV」上做優化。這個方向很有效，但當上下文長度來到 1M Token 時，問題會變得更極端：即使每個 Token 的快取已經很小，Token 數量本身仍然太多。

DeepSeek-V4 選擇把舊上下文壓縮成塊。也就是說，模型不一定要為每個很久以前的 Token 都保留完整 KV，而是讓多個 Token 形成壓縮條目。

這有點像讀一本很長的書：剛讀過的幾頁你會記得細節，前面幾章則更多以摘要、主題和關鍵線索的形式保存。DeepSeek-V4 的注意力機制也有類似分工：近處保留細節，遠處用壓縮表示。

CSA：4 倍壓縮加稀疏檢索

CSA 全稱是 Compressed Sparse Attention，可以理解為較細粒度的長程壓縮機制。

在 CSA 中，模型會把序列中的若干相鄰 Token 壓縮成更少的 KV 條目。Hugging Face Transformers 文件裡給出的預設壓縮率是 m=4，也就是大致每 4 個 Token 形成一個壓縮條目。

但它不是簡單平均。CSA 使用帶學習能力的壓縮池，並結合重疊窗口，讓模型在壓縮時保留更有用的資訊。壓縮之後，查詢並不會對所有歷史壓縮塊都做完整注意力，而是先透過 Lightning Indexer 打分，挑出最相關的 top-k 壓縮塊，再進入核心注意力計算。

這個結構有兩層收益：

歷史 KV 條目數量先變少。
每次查詢只看最相關的一部分壓縮塊。

所以 CSA 適合處理遠距離但仍需要細節檢索的上下文，比如程式碼庫、長文件、工具呼叫歷史裡的關鍵資訊。

HCA：128 倍壓縮加稠密注意力

HCA 全稱是 Heavily Compressed Attention，壓縮更激進。

Transformers 文件裡給出的預設壓縮率是 m'=128。也就是說，HCA 會把更長的一段上下文壓成一個壓縮條目。壓縮後的序列已經很短，因此它不需要像 CSA 那樣再做稀疏 top-k 檢索，而是讓 Query 對所有 HCA 壓縮條目做稠密注意力。

HCA 的作用更像全局摘要。它不追求保留每個細節，而是用極低成本覆蓋很長的歷史範圍，讓模型對全局背景、長程主題和遠處資訊保持感知。

如果把 CSA 比作「可檢索的壓縮筆記」，HCA 更像「全局目錄和摘要」。

滑動窗口：最近上下文仍保留細節

DeepSeek-V4 並不是把所有上下文都壓縮掉。

在 CSA 和 HCA 之外，它還保留了滑動窗口分支，用來處理最近的一段未壓縮上下文。Transformers 文件裡提到，DeepSeek-V4 的 attention block 會把長程壓縮分支與滑動窗口 K/V 拼接在一起。

這個設計很重要。生成下一個 Token 時，最近幾十到幾百個 Token 往往最關鍵：變數名、函式簽名、正在寫的句子、剛返回的工具結果、最近使用者要求。它們如果被過度壓縮，輸出品質會明顯下降。

所以 DeepSeek-V4 的思路不是「全部壓縮」，而是：

近處：保留未壓縮細節。
中遠處：用 CSA 做可檢索壓縮。
更遠處：用 HCA 做重度全局壓縮。

混合層棧：不同層做不同注意力

DeepSeek-V4 不是在所有層裡使用同一種注意力。

Hugging Face 的 DeepSeek-V4 文章提到，V4-Pro 的 61 層結構中，前兩層使用 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」這個宣傳數字。真正決定可部署性的，是長上下文下的顯存占用、頻寬壓力、推理延遲和工程實現。

和其他模型的差異

與傳統 MHA 相比，DeepSeek-V4 不再為長歷史裡每個 Token 保留完整注意力記憶，快取壓力下降非常明顯。

與 GQA 相比，DeepSeek-V4 不只是減少 KV head 數量，還減少長歷史的 KV 條目數量。GQA 仍然要隨序列長度線性累積快取，而 V4 會把遠處上下文壓成塊。

與 DeepSeek-V3 的 MLA 相比，V4 的重點從「每個 Token 的表示更緊湊」進一步擴展到「歷史 Token 數量也被壓縮」。MLA 已經大幅降低單 Token KV 占用，但面對百萬級上下文時，序列長度本身仍是壓力來源。

與普通稀疏注意力相比，DeepSeek-V4 的 CSA 是先壓縮再稀疏檢索，索引器面對的是更短的壓縮序列；HCA 則透過 128 倍壓縮讓全量稠密注意力也變得便宜。

對 Agent 和長任務有什麼意義

Agent 工作流特別吃長上下文：它會讀文件、呼叫工具、接收工具返回、生成計畫、修正計畫、繼續呼叫工具。上下文越長，KV Cache 越容易成為瓶頸。

DeepSeek-V4 這種快取機制的潛在價值在於：

更容易承載長程式碼庫、長文件、多輪工具呼叫歷史。
首字延遲和吞吐更不容易被 KV Cache 拖垮。
同等硬體上可以跑更長上下文或更多並發請求。
對百萬 Token 場景，部署成本更接近實際可用，而不是只停留在論文指標。

不過也要注意，壓縮注意力不是免費午餐。把歷史 Token 壓縮成塊，必然涉及資訊取捨。模型需要在「省顯存」和「保留可檢索細節」之間做平衡。真正效果還要看任務類型：程式碼定位、法律文件、長篇問答、Agent 工具鏈，對細節召回的要求並不一樣。

不要把 2% 理解成所有成本都降到 2%

「KV Cache 約為 GQA 的 2%」很容易被誤讀。

它主要指 KV Cache 顯存規模，不等於總推理成本只剩 2%，也不等於所有場景速度都會提升 50 倍。推理還包括模型權重讀取、MoE 路由、前饋網路、注意力計算、調度開銷、通訊開銷等。

Hugging Face 的文章裡也把兩個數字分開講：在 1M Token 場景，DeepSeek-V4-Pro 相對 DeepSeek-V3.2 的單 Token 推理 FLOPs 是 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 真正改變的，正是這一點。

長上下文 on KnightLi的博客