KV Cache on KnightLi的博客

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 真正改變的，正是這一點。

參考資料

8G 顯存跑 llama.cpp 怎麼調：32K 更穩，64K 要開 KV Cache 量化

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

8G 顯存到底還能不能把本地大模型跑順，尤其是在長上下文場景下還能不能保住速度，這是很多人在折騰 llama.cpp 時都會遇到的問題。

核心結論可以先記住三條：

對 8G 顯存來說，32K 上下文通常是更穩的平衡點
如果一定要跑 64K，KV Cache 量化基本是必選項
在全顯卡運行場景裡，盲目拉高 CPU 執行緒數，反而可能讓速度明顯下降

一、先解釋清楚：32K、64K 和 KV Cache 是什麼

很多人第一次看這類調優文章，最容易卡住的就是這三個詞。

32K 和 64K 說的是上下文長度，也就是模型一次最多能處理多少 token。這裡的 K 就是千，32K 大約是 32000 token，64K 大約是 64000 token。上下文越長，模型一次能看到的歷史內容越多，適合長文件問答、長對話和多輪分析。

KV Cache 則是模型為了加速連續生成而保留的一份中間結果快取。你可以把它理解成：模型已經讀過、算過的一部分內容，不會每次都從頭重算，而是把關鍵結果先存起來，後面繼續接著用。這裡的 K 和 V，來自 Transformer 裡的 Key 和 Value。

為什麼這三個詞總是一起出現？因為：

32K、64K 決定你想讓模型一次記住多長內容
KV Cache 決定為了維持這段記憶，要額外占多少顯存
上下文越長，KV Cache 通常越大，顯存壓力也越高

所以很多長上下文變慢的問題，本質上並不是模型「不會算」，而是快取太大，把顯存擠到了臨界點。

二、為什麼 32K 和 64K 的速度會差這麼多

這裡用《三體》大約 3 萬字的文本做壓力測試，對比 32K 和 64K 兩種上下文設定。結果很誇張：在文件長度接近的情況下，64K 模式的速度顯著下降，總耗時也明顯拉長。

問題不在模型突然變笨，而在顯存邊界被撞到了。

當 32K 模式下，模型權重加快取還能基本塞進 8G 顯存裡，資料大多走顯卡顯存帶寬，速度還能維持在比較可用的區間。但一旦切到 64K，快取體積繼續上漲，總占用逼近甚至超過顯存上限，系統就會把部分資料擠到記憶體裡。

這時候真正掉下去的，不是算力，而是帶寬。

也就是說，很多人看到的是「上下文翻倍後速度暴跌」，本質上其實是資料路徑從顯存掉到了共享記憶體或系統記憶體，推理鏈路不再跑在高速通道上。

三、64K 還能不能跑，關鍵在 KV Cache 量化

第二個很關鍵的結論，是 KV Cache 量化對 8G 顯存使用者特別重要。

如果不改變模型本身，只針對快取做量化，長上下文下最直接的收益就是把快取占用壓縮下來，讓原本已經溢出的那部分重新回到顯存裡。這樣一來，64K 模式雖然依然比 32K 更吃資源，但至少不會直接跌進最慢的區間。

換句話說：

32K 更像是 8G 顯存的預設推薦區間
64K 不是完全不能跑
但如果不上快取量化，效能很容易從「能用」直接掉到「很難用」

如果你的目標是盡量穩定地跑長上下文，那優先順序通常應該是：

先確認顯存是否已經逼近上限
再決定是否開啟 KV Cache 量化
最後才去繼續嘗試更激進的吞吐量參數

四、GPU 占用不高，不代表顯卡沒幹活

這是一個很容易打破直覺的點。

很多人看到工作管理員裡 GPU 使用率只有二三十，就會懷疑：

是不是參數沒設對
是不是模型沒真正跑到顯卡上
是不是顯卡根本沒吃滿

但這組測試給出的判斷是，llama.cpp 這類推理很多時候首先卡的不是核心算力，而是顯存讀寫速度。

也就是說，顯卡核心可能很快就把一批計算做完了，但後面還得等下一批權重和快取資料搬過來。於是你看到的現象就會變成：

核心占用不算高
但整體速度還是上不去

這不是顯卡在偷懶，而是資料通路太窄。

所以看本地大模型速度時，不能只盯著 GPU Usage。顯存容量、顯存帶寬、快取是否溢出，往往更影響最終體驗。

五、調大吞吐量參數，確實可能再快一截

這裡還做了一個思路很清晰的測試：既然顯卡核心並沒有完全忙滿，那能不能透過調大吞吐量相關參數，讓顯卡一次處理更多資料，把並行能力進一步壓出來。

測試結果表明，這種做法確實有機會把速度再往上拉一段。

但這裡也有一個前提：顯存還得扛得住。

因為吞吐量相關參數調大之後，往往會帶來額外顯存占用。如果你本來就在 64K、高快取、顯存見底的狀態下繼續往上推，就很容易出現兩種情況：

直接崩潰
沒崩，但被迫進入更慢的共享記憶體模式

所以更穩妥的順序通常不是「先把參數拉滿」，而是：

先守住顯存邊界
再考慮吞吐量優化
每調一步都重新看速度和穩定性

六、CPU 執行緒不是越多越好

這也是整篇內容裡最值得記住的坑點之一。

很多人做本地推理調優時，容易下意識覺得執行緒越多越快，既然機器有那麼多執行緒，不用滿就像浪費。但實測給出的結果恰恰相反：在模型已經主要跑在顯卡上的情況下，強行把 CPU 執行緒拉高，效能反而會明顯變差。

原因不複雜。

在全顯卡運行時，CPU 更像是調度者和預處理協作者，而不是主力計算單元。這時候如果開太多執行緒，CPU 端的執行緒競爭、調度切換和上下文切換開銷都會變重，最終把本來應該更流暢的資料流打亂。

結果就是：

CPU 更忙了
但整體速度變慢了

所以在這種場景下，預設設定或者較低執行緒數，往往比一味拉滿更靠譜。

七、對 8G 顯存使用者更實用的一套思路

如果把上面的結論壓成一套更容易執行的思路，大概可以整理成這樣：

1. 先把 32K 當成預設目標

如果你用的是 8G 顯存顯卡，先別急著追 64K。32K 往往是速度、穩定性和顯存占用之間更現實的平衡點。

2. 想上 64K，先處理快取問題

不要先想「還能不能再榨一點速度」，而是先確認 KV Cache 有沒有量化、顯存是不是已經壓線。

3. 不要用 GPU 占用率判斷一切

低占用不一定代表設定錯了，也可能只是顯存帶寬在拖後腿。

4. 吞吐量優化可以做，但別越過顯存邊界

這類參數確實能帶來收益，但前提是顯存還有餘量。

5. CPU 執行緒先保守，再逐步測試

如果模型已經基本跑在顯卡上，CPU 執行緒並不是越高越好。先用預設值或低執行緒值測試，再看是否值得繼續調整。

結語

這組內容最有價值的地方，不只是給出幾個測試數字，而是把一個經常被忽略的事實講清楚了：

本地大模型調優，很多時候拼的不是「有沒有把所有參數開到最大」，而是你有沒有搞清楚瓶頸到底在算力、顯存容量、顯存帶寬，還是在 CPU 調度。

對 8G 顯存使用者來說，真正更穩的思路通常不是硬衝最長上下文，而是先守住顯存邊界，再決定要不要繼續往上加。

如果只記一句話，那就是：

32K 往往是 8G 顯存更穩的工作區間；64K 不是不能跑，但前提是你已經把 KV Cache 和顯存占用管住了。