DeepSeek-V4 KV Cache 机制解析：为什么 1M 上下文更省显存

Mon, 18 May 2026 18:38:26 +0800

长上下文模型真正贵的地方，往往不是“能不能塞进 100 万 Token”，而是推理时 KV Cache 要占多少显存。

在 Transformer 解码过程中，每生成一个新 Token，模型都要保留历史 Token 对应的 Key 和 Value。上下文越长，KV Cache 越大；KV Cache 越大，显存、内存带宽、首字延迟和吞吐都会被拖慢。

DeepSeek-V4 的特别之处，是它没有只在注意力头数量上省缓存，而是把压缩进一步推进到序列长度维度。按照 Hugging Face 对 DeepSeek-V4 技术报告的解读，在 1M Token 场景下，DeepSeek-V4-Pro 的 KV Cache 约为 DeepSeek-V3.2 的 10%；如果和常见的 bf16 GQA 架构相比，约为其 2% 左右。

这就是 DeepSeek-V4 缓存机制最值得看的地方：它不是简单把 KV 存得更小，而是减少需要长期保存和检索的 KV 条目数量。

先看几代 KV Cache 优化路线

KV Cache 优化大致可以分成几条路线。

第一类是传统 MHA，也就是 Multi-Head Attention。每个 Query 头通常都有对应的 Key/Value 头。它结构直接，但长上下文下缓存随序列长度线性增长，显存压力最大。

第二类是 GQA，也就是 Grouped Query Attention。多个 Query 头共享较少的 Key/Value 头。LLaMA、Mistral、Qwen 等很多现代模型都采用类似思路。它能显著减少 KV 头数量，是当前主流长上下文模型的常见节省手段。

第三类是 MLA，也就是 Multi-head Latent Attention。DeepSeek-V2、DeepSeek-V3 使用这一路线，把 Key/Value 压缩成低秩潜在表示，从注意力头维度进一步降低缓存占用。

第四类就是 DeepSeek-V4 引入的混合压缩注意力。它把重点放到序列长度维度：不是只减少每个 Token 要存多少 KV，而是把多个历史 Token 压缩成更少的 KV 条目，再用稀疏或稠密方式检索。

可以粗略理解为：

MHA：每个头都认真记。
GQA：多个 Query 头共享一部分记忆。
MLA：把每个 Token 的 KV 表示压成潜在向量。
DeepSeek-V4：把很多历史 Token 聚合成更少的压缩记忆块。

DeepSeek-V4 的关键变化：从头维度压缩到序列维度压缩

GQA 和 MLA 主要是在“每个 Token 存多少 KV”上做优化。这个方向很有效，但当上下文长度来到 1M Token 时，问题会变得更极端：即使每个 Token 的缓存已经很小，Token 数量本身仍然太多。

DeepSeek-V4 选择把旧上下文压缩成块。也就是说，模型不一定要为每个很久以前的 Token 都保留完整 KV，而是让多个 Token 形成压缩条目。

这有点像读一本很长的书：刚读过的几页你会记得细节，前面几章则更多以摘要、主题和关键线索的形式保存。DeepSeek-V4 的注意力机制也有类似分工：近处保留细节，远处用压缩表示。

CSA：4 倍压缩加稀疏检索

CSA 全称是 Compressed Sparse Attention，可以理解为较细粒度的长程压缩机制。

在 CSA 中，模型会把序列中的若干相邻 Token 压缩成更少的 KV 条目。Hugging Face Transformers 文档里给出的默认压缩率是 m=4，也就是大致每 4 个 Token 形成一个压缩条目。

但它不是简单平均。CSA 使用带学习能力的压缩池，并结合重叠窗口，让模型在压缩时保留更有用的信息。压缩之后，查询并不会对所有历史压缩块都做完整注意力，而是先通过 Lightning Indexer 打分，挑出最相关的 top-k 压缩块，再进入核心注意力计算。

这个结构有两层收益：

历史 KV 条目数量先变少。
每次查询只看最相关的一部分压缩块。

所以 CSA 适合处理远距离但仍需要细节检索的上下文，比如代码库、长文档、工具调用历史里的关键信息。

HCA：128 倍压缩加稠密注意力

HCA 全称是 Heavily Compressed Attention，压缩更激进。

Transformers 文档里给出的默认压缩率是 m'=128。也就是说，HCA 会把更长的一段上下文压成一个压缩条目。压缩后的序列已经很短，因此它不需要像 CSA 那样再做稀疏 top-k 检索，而是让 Query 对所有压缩条目做稠密注意力。

HCA 的作用更像全局摘要。它不追求保留每个细节，而是用极低成本覆盖很长的历史范围，让模型对全局背景、长程主题和远处信息保持感知。

如果把 CSA 比作“可检索的压缩笔记”，HCA 更像“全局目录和摘要”。

滑动窗口：最近上下文仍保留细节

DeepSeek-V4 并不是把所有上下文都压缩掉。

在 CSA 和 HCA 之外，它还保留了滑动窗口分支，用来处理最近的一段未压缩上下文。Transformers 文档里提到，DeepSeek-V4 的 attention block 会把长程压缩分支与滑动窗口 K/V 拼接在一起。

这个设计很重要。生成下一个 Token 时，最近几十到几百个 Token 往往最关键：变量名、函数签名、正在写的句子、刚返回的工具结果、最近用户要求。它们如果被过度压缩，输出质量会明显下降。

所以 DeepSeek-V4 的思路不是“全部压缩”，而是：

近处：保留未压缩细节。
中远处：用 CSA 做可检索压缩。
更远处：用 HCA 做重度全局压缩。

混合层栈：不同层做不同注意力

DeepSeek-V4 不是在所有层里使用同一种注意力。

Hugging Face 的 DeepSeek-V4 文章提到，V4-Pro 的 61 层结构中，前两层使用 HCA，之后的层在 CSA 和 HCA 之间交替，末尾的 MTP block 使用滑动窗口。Transformers 文档也说明，V4-Pro 默认是 2 层 HCA bootstrap 加交替 CSA/HCA。

这说明 DeepSeek-V4 把注意力机制当成分层系统来设计。不同层承担不同信息流角色：有的层更偏全局压缩，有的层更偏稀疏检索，有的部分保留局部窗口。

相比所有层统一使用一种注意力，这种混合结构更复杂，但也更适合 1M Token 这种极长上下文。

FP8 和 FP4 进一步降低缓存成本

DeepSeek-V4 的缓存节省不只来自压缩率。

Hugging Face 的文章提到，V4 的大部分 KV 条目使用 FP8 存储，RoPE 相关维度保留 BF16，而 CSA 里的 Lightning Indexer 使用 FP4。压缩比例、低精度存储、稀疏检索叠加在一起，才形成了非常低的 KV Cache 占用。

这也提醒我们：不要只看“上下文长度 1M”这个宣传数字。真正决定可部署性的，是长上下文下的显存占用、带宽压力、推理延迟和工程实现。

和其他模型的差异

与传统 MHA 相比，DeepSeek-V4 不再为长历史里每个 Token 保留完整注意力记忆，缓存压力下降非常明显。

与 GQA 相比，DeepSeek-V4 不只是减少 KV head 数量，还减少长历史的 KV 条目数量。GQA 仍然要随序列长度线性积累缓存，而 V4 会把远处上下文压成块。

与 DeepSeek-V3 的 MLA 相比，V4 的重点从“每个 Token 的表示更紧凑”进一步扩展到“历史 Token 数量也被压缩”。MLA 已经大幅降低单 Token KV 占用，但面对百万级上下文时，序列长度本身仍是压力来源。

与普通稀疏注意力相比，DeepSeek-V4 的 CSA 是先压缩再稀疏检索，索引器面对的是更短的压缩序列；HCA 则通过 128 倍压缩让全量稠密注意力也变得便宜。

对 Agent 和长任务有什么意义

Agent 工作流特别吃长上下文：它会读文件、调用工具、接收工具返回、生成计划、修正计划、继续调用工具。上下文越长，KV Cache 越容易成为瓶颈。

DeepSeek-V4 这种缓存机制的潜在价值在于：

更容易承载长代码库、长文档、多轮工具调用历史。
首字延迟和吞吐更不容易被 KV Cache 拖垮。
同等硬件上可以跑更长上下文或更多并发请求。
对百万 Token 场景，部署成本更接近实际可用，而不是只停留在论文指标。

不过也要注意，压缩注意力不是免费午餐。把历史 Token 压缩成块，必然涉及信息取舍。模型需要在“省显存”和“保留可检索细节”之间做平衡。真正效果还要看任务类型：代码定位、法律文档、长篇问答、Agent 工具链，对细节召回的要求并不一样。

不要把 2% 理解成所有成本都降到 2%

“KV Cache 约为 GQA 的 2%”很容易被误读。

它主要指 KV Cache 显存规模，不等于总推理成本只剩 2%，也不等于所有场景速度都会提升 50 倍。推理还包括模型权重读取、MoE 路由、前馈网络、注意力计算、调度开销、通信开销等。

Hugging Face 的文章里也把两个数字分开讲：在 1M Token 场景，DeepSeek-V4-Pro 相对 DeepSeek-V3.2 的单 Token 推理 FLOPs 是 27%，KV Cache 是 10%。这说明缓存和计算是两个不同维度。

所以更稳妥的说法是：DeepSeek-V4 让超长上下文的 KV Cache 压力显著降低，从而改善百万 Token 场景的部署可行性；但具体吞吐和延迟仍取决于实现、硬件、批处理、量化和推理框架。

小结

DeepSeek-V4 的缓存机制和其他大模型最大的不同，是它把 KV Cache 优化从注意力头维度推进到了序列维度。

GQA 是少存一些 KV 头，MLA 是把每个 Token 的 KV 表示压得更紧，DeepSeek-V4 则进一步把远处 Token 聚合成压缩块，并通过 CSA、HCA、滑动窗口和低精度存储组合起来，让百万 Token 上下文不再被 KV Cache 轻易卡死。

这不是单一技巧，而是一整套长上下文推理架构：近处保细节，远处做压缩，需要细节时稀疏检索，需要全局时重度摘要。

对开发者和 Agent 应用来说，它的意义很直接：长上下文不只是“能输入更多”，还要“跑得起、跑得稳、成本能接受”。DeepSeek-V4 真正改变的，正是这一点。

长上下文 on KnightLi的博客