前代 · CSA：4 倍压缩 + 闪电索引器
前代 V4-Flash 的压缩稀疏注意力：先把每 4 个 token 的 KV 压成一条，再用 FP4 的闪电索引器挑出 top-512——省两次，省的是不同的东西。V4.1 已改用 CSA2。
本篇描述的是前代 DeepSeek V4-Flash（2026 年 4 月发布）的设计。 V4.1-Flash 已把它换成 CSA2：去掉了压缩时的重叠与绝对位置编码，索引器的 K 改为从主 KV 投影，并加入跨层复用。本篇保留初版要点，并按 V4 论文与 config.json 做了更正（见文中注明处）。
CSA（Compressed Sparse Attention，压缩稀疏注意力）是 V4 两种全局注意力之一。V4-Flash 的 43 层里，它占 21 层，与另一种机制 HCA 逐层交替 [1][2]。名字里的两个词各对应一次节省。
更正：初版这里写的是“约 4/5 的注意力层用 CSA”，来自第三方拆解。V4 论文写明 CSA 与 HCA 是交替使用的，config.json 显示 V4-Flash 为前 2 层纯滑动窗口、之后 21 层 CSA 与 20 层 HCA 一层隔一层 [1][2]。排布细节见CSA 与 HCA 怎么排。
第一次省：压缩
沿序列维度做 4 倍压缩：把每 4 个 token 的 KV 归并成一条“压缩条目”，之后的注意力在压缩条目的层面上进行 [1]。
V4 论文给出了具体做法：先算出两组 KV 和对应的压缩权重，再按“权重做 softmax、加上可学习的位置偏置”的方式加权求和，得到压缩条目。每条压缩条目其实取自 8 个原始条目，相邻条目的来源互相重叠，所以序列实际被压到约 1/4 [1]。这是一种学出来的加权池化。
1M token 压 4 倍，变成约 25 万条。缓存需求随之降到约 1/4。
代价当然存在：块内的细节被抹平了。4 倍是个相对保守的压缩率，正是为了把这种损失控制在可接受范围——对比 HCA 的 128 倍，这已经算温和。
第二次省：稀疏
压完还不算完。25 万条如果每个 query 都全算一遍，仍然贵。所以 CSA 的第二步是只挑其中一部分来算，这就是 Sparse。V4 论文说，这一步直接沿用 V3.2 的 DeepSeek 稀疏注意力（DSA）[1][3]。
闪电索引器
挑哪些，由一个专门的模块决定：Lightning Indexer（闪电索引器）。它用自己的一组低维 query 和压缩后的 key 打分，为每个 query 选出分数最高的 k 条；V4-Flash 的索引器有 64 个头、每头 128 维，k = 512（V4-Pro 为 1024）[1]。
拆开看这个设计的三层考虑：
一、为什么要专门的索引器？ “哪些条目相关”，理论上算一遍完整注意力就知道了——但那正是要避免的开销。所以需要一个便宜得多的近似打分器：它不需要精确，只需要排序大致对。
二、为什么用 FP4？ 因为它只做排序。V4 在后训练阶段对索引器的 QK 路径做了 FP4（MXFP4）量化感知训练，缓存、读取和乘法都在 FP4 下进行；索引分数再从 FP32 降到 BF16，top-k 选择提速 2 倍，召回率保持在 99.7% [1]。把精度花在需要精度的地方。
三、代价是什么？ 索引器可能选错。某个关键条目被漏掉，模型就看不到它，而且不会报错——输出只是悄悄地差一点。这类失败是静默的，也是稀疏注意力这条路线的根本风险。
静默失败是稀疏注意力最难评估的地方。标准基准很难测出“模型漏看了上下文里的第 43 万个 token”，除非基准专门为此设计（比如大海捞针或多轮指代检索）。看到“支持 1M 上下文”时，要额外关心它在长上下文检索类基准上的表现，而不只是看通用分数。
还有一条滑动窗口分支
初版没有提到的一点：CSA 的每个 query 只能看之前的压缩块，看不到自己所在块里的其他 token；而最近的 token 往往又最相关。所以 V4 给 CSA（和 HCA）都加了一条滑动窗口分支：每个 query 额外看最近 128 个未压缩 token 的 KV，和选出的压缩条目放在一起做注意力 [1]。另外，核心注意力采用所有查询头共享一份 KV 的 MQA 方式，还用了注意力汇（attention sink）和只作用于最后 64 维的部分旋转位置编码 [1]。
这条滑动窗口分支在 V4.1 里原样保留，还成了有界重放的主角。
两次节省是正交的
| 省什么 | 损失什么 | |
|---|---|---|
| 压缩（4 倍） | 缓存容量——要存的东西少了 | 块内细节被抹平 |
| 稀疏（top-k） | 计算与带宽——每步要读、要算的少了 | 可能漏选相关条目 |
压缩不能替代稀疏：压完的 25 万条还是得存着，每步仍要决定读哪些。稀疏也不能替代压缩：只算 top-k 不代表可以不存其余的，下一个 query 可能要选到别的条目。
更正：初版把“压缩主攻 10% 的缓存、稀疏主攻 27% 的 FLOPs”挂在 V4-Flash 名下。这两个百分比是 V4 论文给 V4-Pro 的；V4-Flash 在 1M 上下文下相对 V3.2 是 10% 的单 token FLOPs 与 7% 的 KV 缓存 [1]。
CSA 与 DSA 的关系
DeepSeek 在 V3.2 时期就有 DeepSeek 稀疏注意力（DSA） 这条线 [3]。CSA 可以看作它的下一步：DSA 在原始序列上做稀疏，CSA 先压缩再稀疏。 多出来的这层压缩，把稀疏选择的搜索空间也缩小了 4 倍——索引器要排序的候选从 100 万降到 25 万，它自己的开销也跟着降。
到了 V4.1，这条线又往前走了一步：CSA2 让大部分层不再各自选，而是复用前面某一层选好的结果（见 CSA2）。
下一篇讲另一种机制——它走的是完全相反的极端。👉 前代 · HCA：128 倍压缩后再做稠密注意力
参考文献
- [1] DeepSeek-AI. “DeepSeek-V4: Towards Highly Efficient Million-Token Context Intelligence.” 2026-04. arXiv:2606.19348 —— 第 1 节（V4-Pro 与 V4-Flash 各自的效率数字）、第 2.3 节（CSA 的重叠压缩、闪电索引器、滑动窗口分支、注意力汇、部分 RoPE）、第 4.2.1 节（V4-Flash 与 V4-Pro 的注意力设置）、第 5.2.1 节（索引器的 FP4 量化感知训练）。
- [2] Hugging Face：deepseek-ai/DeepSeek-V4-Flash 的 config.json ——
compress_ratios：逐层的 4 与 128 交替。 - [3] DeepSeek-AI. “DeepSeek-V3.2: Pushing the Frontier of Open Large Language Models.” 2025-12. arXiv:2512.02556 —— DeepSeek 稀疏注意力（DSA）。