如果你看到“DeepSeek V4 少用 98% 内存”的说法,先别急着把 GPU 配置砍掉。这里最容易混淆的是:KV cache(键值缓存)被压缩,并不等于整个模型服务栈的 GPU 显存(VRAM)都下降 98%。
目前公开资料能支持的结论更窄: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 可能是长上下文大模型推理中的主要瓶颈之一,但它不是部署和服务一个模型时所有显存成本的总和。
官方资料到底确认了什么
DeepSeek 官方 API 新闻页列出 DeepSeek-V4 Preview 于 2026 年 4 月 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 更稀疏;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,也不代表所有上下文长度、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 不等于整体显存
KV cache 在长上下文推理里尤其关键。Hugging Face 对 DeepSeek V4 的介绍提到,在长时间智能体(agent)工作流中,工具返回结果会不断追加进 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 的技术方向值得关注,因为它瞄准的是百万 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 是否适合长文档、长对话或智能体工作流,重点不是追逐“98%”这个标题,而是确认你的瓶颈到底是不是 KV cache。公开资料足以支持 V4 在长上下文 KV cache 上有明显优化,但不足以把“98% less memory”写进采购规格、容量规划或对外 marketing claim [13][
20][
21][
22]。
更可靠的做法,是用自己的 context 长度、batch size、并发量、serving engine 和硬件配置做 benchmark。若你的 workload 主要受 KV cache 限制,V4 的压缩设计可能很有价值;若瓶颈在模型权重、activation、框架开销或并发策略,KV cache 的减少就不会自动等于同等比例的总 VRAM 节省 [13][
21][
22]。




