如果只看標題,「DeepSeek V4 記憶體少用 98%」很吸睛;但真正要問的是:少用的是哪一種記憶體?
目前公開資料能支持的說法比較窄:DeepSeek V4 確實針對長上下文推論的 KV cache(Key-Value 快取) 與 attention 成本做了明確優化;但沒有看到 DeepSeek 官方 API 發布頁、模型卡或技術說明,把「整體 GPU 顯示記憶體(VRAM)少用 98%」列為正式規格 [5][
13][
14]。
最穩妥的說法
比較準確的表述應該是:
DeepSeek V4 透過 Hybrid Attention、Compressed Sparse Attention(CSA)與 Heavily Compressed Attention(HCA)等設計,大幅降低長上下文推論中的 KV cache 壓力;但目前公開證據不足以支持「整體 VRAM 少用 98%」這個結論 [
13][
14]。
這個差別不是文字遊戲。KV cache 可能是長文件、長對話與 agent 工作流中的主要瓶頸之一,但它不是部署一個大型語言模型時所有記憶體成本的總和。
官方資料到底確認了什麼?
DeepSeek 官方 API 新聞頁列出 DeepSeek-V4 Preview 於 2026/04/24 發布 [5]。DeepSeek V4 模型卡則寫明,系列包含 DeepSeek-V4-Pro 與 DeepSeek-V4-Flash;V4 是 Mixture-of-Experts(MoE)語言模型系列,保留 DeepSeekMoE framework 與 Multi-Token Prediction(MTP)strategy,並加入 Hybrid Attention Architecture 等架構改動 [
14]。
和「省記憶體」最直接相關的,是長上下文 attention 的處理。NVIDIA 技術文章指出,V4 的 Compressed Sparse Attention(CSA) 會利用 dynamic sequence compression 壓縮 KV entries,以降低 KV cache memory footprint,接著用 DeepSeek Sparse Attention(DSA)讓 attention matrices 更 sparse、減少計算開銷;Heavily Compressed Attention(HCA) 則會把多組 token 的 KV entries 合併成單一 compressed entry,進一步縮小 KV cache size [13]。
換句話說,公開資料直接支持的是:V4 在 KV cache size 與 attention 計算成本 上做了效率設計。這不等於官方承諾整個 serving stack 的 VRAM 都按同一比例下降。
98%、90%、9.5x:三個數字不要混為一談
目前資料中,最直接出現 98% 的,是一篇 LinkedIn 用戶生成文章,標題聲稱「DeepSeek Sparse Attention Shrinks KV Memory by 98 Percent in Real World Serving」[21]。這可以當作追查傳聞的線索,但不應直接視為 DeepSeek 官方規格。
較容易核對的第三方數字,是 10% KV cache。Wccftech 報導稱,相對 DeepSeek V3.2,DeepSeek V4 只需要 27% single-token inference FLOPs 與 10% key-value(KV)cache [20]。如果只按「10% KV cache」理解,意思接近 KV cache 約減少 90%;但比較基準是 DeepSeek V3.2,也不代表所有 context 長度、batch 設定、硬體配置,或整體 VRAM 都能減少 90% [
20]。
另有新聞標題把 DeepSeek V4 描述為 9.5x lower memory requirements [3]。即使用最直接的數學換算,1/9.5 約等於剩下 10.5% 的需求,也就是約 89.5% 的減少;這仍不是 98%,而且仍要確認它指的是 KV cache、特定長上下文場景,還是完整部署記憶體 [
3]。
| 說法 | 證據狀態 | 較準確解讀 |
|---|---|---|
| 整體 VRAM 少用 98% | 未見官方資料支持 | 不宜寫入採購、容量規劃或對外宣傳規格 [ |
| KV cache 大幅壓縮 | 有技術資料支持 | CSA/HCA 針對長上下文 KV entries 壓縮 [ |
| 10% KV cache | 第三方報導引述 | 可理解為相對 V3.2 約 90% KV cache 減少,但不是總 VRAM 減少 [ |
| 9.5x lower memory | 第三方新聞標題 | 約等於 89.5% 減少,仍需確認比較範圍 [ |
為什麼 KV cache 不等於整體 VRAM?
在長上下文推論中,KV cache 很關鍵。Hugging Face 對 DeepSeek V4 的介紹指出,在長時間 agentic workload 中,工具回傳結果會持續追加到 context;後續 token 要面對更長的上下文,而 single-token inference FLOPs 與 KV cache size 都會隨 sequence length 增加 [17]。Hugging Face 的 GitHub 版本也把長任務常見失敗模式描述為:trace 超出 context budget、KV cache 填滿 GPU,或工具呼叫來回讓任務變慢 [
22]。
但完整部署模型時,VRAM 不只拿來放 KV cache。即使是提出 98% 說法的 LinkedIn 文章,也把 shared weights、expert weights、activations、KV cache 與 framework overhead 分開列出 [21]。這反而說明容量規劃必須拆開看:就算 KV cache 在某個長上下文場景大幅縮小,也不能直接推論整體 VRAM 會用同一百分比下降。
CSA/HCA 是效率工程,不是魔法數字
DeepSeek V4 值得注意的地方,在於它瞄準百萬 token 上下文推論時最昂貴的部分之一:長序列下的 attention 與 KV cache。NVIDIA 對 CSA/HCA 的描述顯示,V4 透過壓縮 KV entries、稀疏化 attention matrices,以及合併多個 token set 的 KV entries,來降低 KV cache size 與計算開銷 [13]。
DeepSeek V4 技術報告也提到推論與訓練基礎設施優化,例如為 MoE modules 設計 single fused kernel,以 overlap computation、communication 與 memory access [2]。這些都是有意義的效率工程;但它們仍不是「整體 VRAM 少用 98%」的直接證據。
真要評估 DeepSeek V4,該看什麼?
如果你正在評估 DeepSeek V4 是否適合長文件、長對話或 agent 工作流,重點不是追逐「98%」標題,而是先確認自己的瓶頸是不是 KV cache。公開資料足以支持 V4 在長上下文 KV cache 上有明顯優化,但不足以把「98% less memory」寫進採購規格、容量規劃或對外 marketing claim [13][
20][
21][
22]。
較可靠的做法,是用自己的 context 長度、batch size、concurrency、serving engine 與硬體配置做 benchmark。若 workload 主要受 KV cache 限制,V4 的壓縮設計可能很有價值;若瓶頸在模型權重、activation、框架開銷或併發策略,KV cache 的減少就不會自動等於同幅度的總 VRAM 節省 [13][
21][
22]。




