DeepSeek V4 記憶體少用 98%？證據指向 KV Cache 壓縮，不是總 VRAM

與「省記憶體」最直接相關的，是長上下文 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 。

換句話說，資料能直接支持的是：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」。這類內容可以作為傳聞來源追查，但不應直接視為 DeepSeek 官方規格。

較容易核對的第三方數字，是 10% KV cache。Wccftech 報道稱，相對 DeepSeek V3.2，DeepSeek V4 只需要 27% single-token inference FLOPs 和 10% key-value（KV）cache 。如果只按「10% KV cache」理解，意思是 KV cache 約減少 90%；但比較基準是 DeepSeek V3.2，也不等於所有 context 長度、batch 設定、硬件配置，或者整體 VRAM 都減少 90% 。

另有新聞標題把 DeepSeek V4 描述為 9.5x lower memory requirements 。即使用最直接的數學換算，1/9.5 約等於 10.5% 的剩餘需求，即約 89.5% 減少；這仍不是 98%，而且仍要確認它指的是 KV cache、特定長上下文場景，還是完整部署記憶體 。

為甚麼 KV cache 不等於整體 VRAM

KV cache 在長上下文推理中特別關鍵。Hugging Face 對 DeepSeek V4 的介紹指出，在長時間 agentic workload 中，工具結果會不斷追加到 context；後續 token 要面對更長的上下文，而 single-token inference FLOPs 和 KV cache size 都會隨 sequence length 增加 。Hugging Face 的 GitHub 版本亦把長任務常見失敗模式描述為 trace 超出 context budget、KV cache 填滿 GPU，或工具調用回合令任務變慢 。

但完整部署一個模型時，VRAM 不只用於 KV cache。即使是提出 98% 說法的 LinkedIn 文章，也把 shared weights、expert weights、activations、KV cache 和 framework overhead 分開列出 。這反而說明容量規劃要分開看：就算 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 和計算開銷 。

DeepSeek V4 技術報告亦提到推理與訓練基礎設施優化，例如為 MoE modules 設計 single fused kernel，以 overlap computation、communication 和 memory access 。這些都是有意義的效率工程；但它們仍不是「整體 VRAM 少用 98%」的直接證據。

實際評估 DeepSeek V4 時應該看甚麼

如果你正在評估 DeepSeek V4 是否適合長文件、長對話或 agent 工作流，重點不是追逐一個「98%」標題，而是確認你的瓶頸是否真的是 KV cache。公開資料足以支持 V4 在長上下文 KV cache 上有明顯優化，但不足以把「98% less memory」寫入採購規格、容量規劃或對外 marketing claim 。

較可靠的做法，是用自己的 context 長度、batch size、concurrency、serving engine 和硬件配置做 benchmark。若你的 workload 主要受 KV cache 限制，V4 的壓縮設計可能很有價值；若瓶頸在模型權重、activation、框架開銷或併發策略，KV cache 的減少就不會自動等於同幅度的總 VRAM 節省 。