「DeepSeek V4 少用 98% 記憶體」這句話最容易誤導的地方,是把 KV cache 壓縮 寫成 整個模型部署的 VRAM 需求下降。目前公開資料支持的結論較窄:DeepSeek V4 針對長上下文推理的 KV cache 和 attention 成本做了明確優化;但未見官方 API 發布、模型卡或技術說明把「整體 VRAM 少用 98%」列為正式規格 [5][
13][
14]。
最安全的結論
如果要準確描述 DeepSeek V4,較穩妥的說法是:
DeepSeek V4 透過 Hybrid Attention、Compressed Sparse Attention(CSA)和 Heavily Compressed Attention(HCA)等設計,大幅降低長上下文推理中的 KV cache 壓力;但現有資料不足以支持「整體 VRAM 少用 98%」這個說法 [
13][
14]。
這個分別很重要。KV cache 可以是長上下文 LLM 推理的主要瓶頸之一,但它不是部署和服務一個模型時所有記憶體成本的總和。
官方資料真正確認了甚麼
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 計算開銷 有設計上的優化。這不等於官方承諾所有 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 在某個長上下文場景下大幅減少,也不能直接推論整個 serving stack 的 VRAM 會按同一百分比下降。
CSA/HCA 是效率工程,不是魔法數字
DeepSeek V4 的技術方向值得關注,因為它針對的是 million-token context 推理時最昂貴的部分之一:長序列下的 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]。




