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

對比 DeepSeek-V4 的 CSA/HCA 混合壓縮注意力與傳統 MHA、GQA、MLA 在 KV Cache 上的差異,解釋為什麼 DeepSeek-V4 能把 1M Token 長上下文的顯存占用壓到很低。

長上下文模型真正貴的地方,往往不是「能不能塞進 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 真正改變的,正是這一點。

參考資料

记录并分享
使用 Hugo 建立
主題 StackJimmy 設計