DeepSeek V4 真的显存少用 98% 吗？先分清 KV Cache 和总 VRAM

如果你看到“DeepSeek V4 少用 98% 内存”的说法，先别急着把 GPU 配置砍掉。这里最容易混淆的是：KV cache（键值缓存）被压缩，并不等于整个模型服务栈的 GPU 显存（VRAM）都下降 98%。

目前公开资料能支持的结论更窄：DeepSeek V4 确实围绕长上下文推理降低 KV cache 和 attention 开销；但在官方 API 新闻页、模型卡和相关技术介绍中，没有看到“整体 VRAM 少用 98%”被列为正式规格 。

最稳妥的说法

如果要准确描述 DeepSeek V4，可以这样写：

DeepSeek V4 通过 Hybrid Attention、Compressed Sparse Attention（CSA）和 Heavily Compressed Attention（HCA）等设计，显著降低长上下文推理中的 KV cache 压力；但现有公开资料不足以支持“整体 VRAM 少用 98%”这一说法 。

这个区别很关键。KV cache 可能是长上下文大模型推理中的主要瓶颈之一，但它不是部署和服务一个模型时所有显存成本的总和。

官方资料到底确认了什么

DeepSeek 官方 API 新闻页列出 DeepSeek-V4 Preview 于 2026 年 4 月 24 日发布 。DeepSeek V4 模型卡则写明，该系列包括 DeepSeek-V4-Pro 和 DeepSeek-V4-Flash；V4 是 Mixture-of-Experts（MoE，混合专家）语言模型系列，保留 DeepSeekMoE framework 和 Multi-Token Prediction（MTP）strategy，并加入 Hybrid Attention Architecture 等架构变化 。

和“省显存”最直接相关的，是长上下文 attention 的处理方式。NVIDIA 的技术文章称，V4 的 Compressed Sparse Attention（CSA） 会用 dynamic sequence compression 压缩 KV entries，以降低 KV cache memory footprint，再用 DeepSeek Sparse Attention（DSA）让 attention matrices 更稀疏；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，也不代表所有上下文长度、batch 设置、硬件配置，或者整体 VRAM 都减少 90% 。

还有新闻标题把 DeepSeek V4 描述为 9.5x lower memory requirements 。即使用最直接的数学换算，1/9.5 约等于剩余 10.5%，也就是约减少 89.5%；这仍不是 98%，而且还要确认它说的是 KV cache、特定长上下文场景，还是完整部署显存 。

说法	证据状态	更准确的解读
整体 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 不等于整体显存

KV cache 在长上下文推理里尤其关键。Hugging Face 对 DeepSeek V4 的介绍提到，在长时间智能体（agent）工作流中，工具返回结果会不断追加进 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 的技术方向值得关注，因为它瞄准的是百万 token 长上下文推理中最昂贵的部分之一：长序列下的 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 是否适合长文档、长对话或智能体工作流，重点不是追逐“98%”这个标题，而是确认你的瓶颈到底是不是 KV cache。公开资料足以支持 V4 在长上下文 KV cache 上有明显优化，但不足以把“98% less memory”写进采购规格、容量规划或对外 marketing claim 。

更可靠的做法，是用自己的 context 长度、batch size、并发量、serving engine 和硬件配置做 benchmark。若你的 workload 主要受 KV cache 限制，V4 的压缩设计可能很有价值；若瓶颈在模型权重、activation、框架开销或并发策略，KV cache 的减少就不会自动等于同等比例的总 VRAM 节省 。