DeepSeek V4 的注意力机制设计：CSA 和 HCA
写 DeepSeek V4，注意力机制这一块其实很值得单独拿出来看。官方公开材料已经把重点说得比较清楚：这代模型在长上下文上最核心的结构升级，就是把Compressed Sparse Attention和Heavily Compressed Attention交替放进主干网络里。
这套设计解决的问题也很具体：当上下文真的拉到几十万、上百万 token 时，模型面对的不只是“能不能支持长上下文”，还有“推理时每生成一个 token，到底要付出多少 FLOPs、多少 KV cache、多少延迟”。
DeepSeek V4 的思路不复杂：历史信息不一定要用同一种分辨率保留下来，也不是每一层都要花同样的代价去读历史。于是它把这件事拆成了两种互补机制。
一、先看背景
V4 的注意力设计不是凭空冒出来的。它的前身是 V3.2 里的DeepSeek Sparse Attention。V3.2 那一代做的事情，大致可以概括成一句话：在一长串历史 token 里，先找出最值得看的那部分，再只对这部分做更细的注意力计算。
到了 V4，这个想法继续往前推，但形式变了。V4 不再直接对原始 KV 序列做稀疏选择，而是先做压缩，再决定用什么方式去读压缩后的历史。后面的CSA和HCA就是从这里出来的。
二、CSA：先压缩，再挑重点
CSA全称是Compressed Sparse Attention。它可以理解成 V3.2 那套稀疏检索思路的延伸版。
在官方说明里，CSA 的做法大致分两步：
- 先把历史 KV 沿着序列维压缩四倍。
- 再用一个轻量 indexer 去挑出 top-k 压缩块，只对这部分做稀疏注意力。
这样做的好处很直接。序列先被压短了一次，后面检索的对象就不再是原始 token，而是压缩块。索引空间更小，检索本身也更便宜。它保留的还是“先找重点，再细看重点”这件事。
从直觉上看，CSA 更像一个带放大镜的检索器。它并没有试图对整个百万 token 历史都保持同样精度，而是默认：历史里真正重要的部分只占一小部分，只要先把这部分定位出来，后面的注意力开销就能明显压下来。
下面这张图来自 DeepSeek V4 技术报告，对 CSA 的流程画得很直观：
图里更重要的是信息流方向。左边是完整的历史 KV，先经过一层压缩；中间是索引模块；右边才是被挑出来的压缩块进入稀疏注意力计算。顺着这条路看，CSA 做的事情比较清楚：先降采样，再检索，再精读。
三、HCA：压得更狠，直接看全局
如果说 CSA 还保留着“先找 top-k”这层选择动作，那HCA的思路就更激进一些。
HCA全称是Heavily Compressed Attention。它不是把序列压缩四倍，而是直接压到128x。压到这个程度之后，历史序列已经短到足够小，小到不一定非得再做稀疏选择。于是 V4 的处理方式变成了：对这个高度压缩后的历史，直接做 dense attention。
这听起来有点反直觉，因为大家一提长上下文，第一反应往往是“dense attention 太贵”。HCA 走的是另一条路：不是在原始长序列上做 dense attention，而是在一个非常粗粒度的历史摘要上做 dense attention。这样一来，模型虽然看到的是降分辨率的历史，但它看到的是一整段历史的全局轮廓，而不是若干被挑中的局部块。
可以把 HCA 理解成一种“低清全景图”。它不负责精确回忆远处某个细节，但会给当前层一个全局概览，让模型知道长历史里大概发生过什么。
技术报告里的 HCA 图也很直白：
这张图和 CSA 对比着看会更清楚。HCA 里最醒目的变化，是压缩率更高，后面也没有再接 top-k block selection，而是直接进入 dense attention。它不再强调“找哪几个块最重要”，而是强调“先把整条历史缩成一个便宜得多的全局上下文”。
四、为什么要把 CSA 和 HCA 混着用
如果只有 CSA，没有 HCA，模型会更擅长精确找局部，但全局信息更依赖索引器挑得准不准。要是只有 HCA，没有 CSA，模型会一直有全局轮廓，但遇到需要精准回忆远处细节的地方，分辨率可能不够。
V4 在这里没有押注单一机制，而是把两种机制交替堆叠。
DeepSeek 官方对这件事的说法比较克制，但意思并不难懂：不同层需要的历史分辨率不一样。有些层更适合用稀疏检索去精确抓关键片段，有些层更适合先拿到一张粗粒度全景图。CSA 和 HCA 的交替，本质上是在网络深度上做了一次“信息分工”。
换成更直白的话说，V4 没有假设每一层都要去翻档案，也没有假设每一层都只看摘要。它把这两种工作拆开，让一部分层负责“找重点”，另一部分层负责“看全局”。
五、这套设计换来了什么
官方 README 给出的数字很硬：在1M上下文设定下，DeepSeek-V4-Pro的单 token 推理 FLOPs 只有DeepSeek-V3.2的27%，KV cache 只有10%。
这组数字不只是说明“更省”。它也说明 V4 把长上下文问题从“理论上支持”推到了“成本可以往下谈”。Agent 任务里比较麻烦的事情，不是模型不支持几十万 token，而是上下文一长，推理速度和显存一起失控。CSA 和 HCA 这一套，就是在处理这个现实问题。
Hugging Face 那篇官方解读还补了一句更直观的话：如果和常见的8-head GQA + BF16 KV相比，V4 的 KV cache 大约只需要对方的2%。这也是为什么 V4 的长上下文能力看上去不像单纯“把窗口写大”那么简单，它后面确实有一套针对推理成本重做过的结构。
六、怎么理解这两种注意力的分工
如果只想留一个最简单的印象，可以这么记：
CSA像检索系统。 先压缩，再从压缩块里挑 top-k，适合“远处有个细节，我得把它捞出来看清楚”。HCA像全局摘要。 先极限压缩，再直接对压缩后的整段历史做 dense attention，适合“我不用看清每个细节，但我得知道整条历史的大体轮廓”。
两者混在一起之后，V4 处理长历史时就不只剩一个旋钮。它既可以保留对关键细节的回忆能力，也可以保留对全局结构的把握能力，而代价又比直接在原始长序列上算注意力小得多。
七、最后记住什么
V4 的注意力机制没有去追求一个“万能稀疏注意力公式”。它做的事情更像系统设计：承认长上下文里存在两种需求，一种是精确抓重点，一种是便宜看全局，然后分别给出一套结构，再把它们交替放进网络。
从这个角度看，CSA 和 HCA 不是两个孤立的小模块，而是 V4 对百万上下文的一种基本判断：长历史不该只用一种分辨率去读。
这也解释了为什么 V4 在注意力这一块看起来没有那么花哨，但又不太好用一句旧术语替代。它真正调整的不是某个算子细节，而是模型读长历史的方式。
参考资料
- DeepSeek-V4 技术报告
- DeepSeek-V4-Pro 官方 README
- Hugging Face: DeepSeek-V4: a million-token context that agents can actually use
- DeepSeek-V3.2-Exp 官方 README