CSA2：跨层共享的压缩稀疏注意力
CSA2 给每层指定 Full、Reindex、Reuse 三种模式之一，40 层里只有 4 层自己产生全局 KV；解码器再用分层候选池限制索引范围，配合 FP4 把每 token 全局缓存压到 890 字节。
V4 的全局注意力由 CSA 与 HCA 两种机制交替组成（见前代那两章）。V4.1 把 HCA 整个拿掉，只保留一种改进过的机制，叫 CSA2（Compressed Sparse Attention 2）。报告写得很直接：不同于 V4 的 CSA–HCA 混合架构，V4.1-Flash 只用 CSA2 [1]。
保留了 CSA 的骨架
CSA2 的基本动作和 CSA 一样 [1]：
- 把每 个 token 的 KV 压成一条“主 KV”；
- 一个轻量的索引器用自己的 Q 和 K 给这些主 KV 条目打分，为每个 query 选出分数最高的 512 条；
- query 对这 512 条，加上本层最近 128 个 token 的滑动窗口 KV，一起做注意力。
在这副骨架上，CSA2 做了两处简化：一是去掉压缩时的重叠和绝对位置编码（CSA 的每条压缩条目取自 个原始条目，相邻条目的来源互相重叠）；二是索引器的 K 直接从主 KV 投影出来，不再像 CSA 那样从隐藏状态另走一条压缩路径。报告说两处都是为了实现更简单、训练更快 [1]。压缩率 也被当作特例支持，即主 KV 不压缩。
三种模式：谁算、谁复用
CSA2 真正的新东西是跨层复用。每个 CSA2 层被静态地指定为三种模式之一 [1]：
| 模式 | 主 KV 与索引器 K | top-512 索引 | 相当于 |
|---|---|---|---|
| Full | 自己算 | 自己的索引器打分、自己选 | 一个完整的 CSA 层 |
| Reindex | 复用最近一个 Full 层的 | 用自己的索引器 Q 给共享的 K 重新打分，选出新的 top-512 | 缓存共享，选择可以变 |
| Reuse | 复用 | 直接沿用最近一个 Full 或 Reindex 层选好的索引 | 不跑索引器，直接做稀疏注意力 |
三种模式都各自计算本层的 query 和滑动窗口 KV，所以每层的注意力输出仍然不同；共享的只是“全局记忆存在哪、挑哪几条”。
具体到 V4.1-Flash 的 40 层（层号从 0 数）[1][2]：
| 位置 | 层 | 压缩率 | 模式安排 |
|---|---|---|---|
| 编码器开头 | 0–1 | —— | 只有滑动窗口注意力 |
| 编码器 | 2–19，分 3 组，每组 6 层 | 2 | 每组第一层 Full（第 2、8、14 层），其余 5 层 Reuse |
| 解码器第 1 组 | 20–23 | 1 | 第 20 层 Full（主 KV 投影自编码器最后一层的输出），其余 Reuse |
| 解码器第 2–5 组 | 24–39，每组 4 层 | 1 | 每组第一层 Reindex（第 24、28、32、36 层），其余 3 层 Reuse |
数一下：只有 4 层自己产生全局 KV，8 层运行索引器，其余 30 层是 Reuse。V4-Flash 的 43 层里，除了开头两层，41 层都各存一份自己的压缩 KV。
跨层复用并不新，报告自己列了先例：跨层共享 KV 缓存的工作、跨层复用 top-k 索引的 IndexCache、全网只算一次稀疏路由的 YOIO、让稀疏层复用稠密层缓存的 HySparse。报告的判断是，单独复用索引省不了主 KV 的存储，全网共享一套路由会损失性能，混合方案仍保留稠密注意力层，而且没有一种同时覆盖条目大小、序列、层数这三个维度；CSA2 把三者一起用上，并把“共享缓存”和“复用索引”拆成两个独立的开关 [1]。这是厂商对自身工作的定位。
解码器里的分层索引
跨层复用减少了跑索引器的层数，但剩下的索引器每次仍要给全部可见位置打分；上下文到了百万级，这笔开销依旧可观。V4.1 在解码器里加了一个分层稀疏索引器（Hierarchical Sparse Indexer）[1]：
- 第 20 层（解码器的 Full 层）照常扫描全部可见位置，为自己选出 top-512；同时按块挑候选：每 8 个位置一块，以块内最高分作为块分数，选出分数最高的 2,048 块，得到 16,384 个候选位置。
- 之后的 Reindex 层只在这 16,384 个候选里打分，再各自选 top-512；Reuse 层不打分。
这样，候选池大小固定时，深层索引器每个 query 的开销与上下文长度无关；只有第一层还要扫全程。报告特别说明这一机制在后训练阶段引入，训练与推理用的是同一个受限搜索范围 [1]。
890 字节是怎么来的
报告只给了总数。按报告与 config.json 里的格式，可以把它拆出来（本专栏推算）[1][2]：
- 主 KV 每条 512 个通道，FP4 存储：512 × 0.5 = 256 字节，再加每 16 个通道一个 1 字节的 E4M3 缩放，共 32 字节，合计 288 字节。
- 索引器 K 每条 128 维，用 MXFP4（每 32 个数共享一个 1 字节缩放）：64 + 4 = 68 字节。
| 产生全局 KV 的层 | 压缩率 | 每 token 的主 KV | 每 token 的索引器 K | 小计 |
|---|---|---|---|---|
| 第 2、8、14 层（编码器） | 2 | 288 ÷ 2 = 144 | 68 ÷ 2 = 34 | 178 × 3 = 534 |
| 第 20 层（解码器） | 1 | 288 | 68 | 356 |
| 合计 | 890 字节 |
和官方数字严丝合缝。它也把前一章那张因子表落到了实处：序列维只压了 2 倍甚至不压，省下来的主要是“只有 4 层存缓存”和“存成 4 bit”。FP4 的格式细节放在精度那一章。
快在哪、险在哪
快：报告说，绝大多数层（即 CSA2 处于 Reuse 模式的层）整层在预填充时只需 15 个 kernel、解码时只需 11 个，靠的是把注意力前后的位置编码与类型转换、门控、mHC、MoE 等操作各自融合进少数几个大 kernel [1]。训练侧则要处理“共享的层可能分在不同流水线阶段”的问题，报告用影子索引器、扩展流水线间传递的数据、按微批次管理共享状态来解决 [1]。
险：稀疏注意力的老问题——选错了不会报错。某个关键位置没进 top-512，模型就看不到它，输出只是悄悄变差。CSA2 又叠了两层“替别人选”：Reuse 层用的是上游层选的索引，Reindex 层只能在第 20 层圈定的候选池里选。报告在局限性一节承认“CSA2 中潜在的选择错误”可能在未测试的边界情形下导致能力下降，并把“长上下文上的稀疏检索”列为后续压测重点 [1]。
目前查不到的数字：V4.1 报告里唯一的长上下文基准是基座模型的 LongBench-V2（V4.1-Flash-Base 45.2，V4-Flash-Base 44.7，V4-Pro-Base 51.5）[1]。V4 报告给过指令模型在 MRCR 1M、CorpusQA 1M 这类百万级检索任务上的分数 [3]，V4.1 没有。对一个主打百万上下文、又大幅复用稀疏选择的模型，这是最该补上的一块，在第三方测出来之前，用它做超长文档精确检索要自己先测。
下一章讲缓存的另一半：滑动窗口 KV 为什么可以不落盘。👉 SWA 有界重放：SSD 上只剩八分之一
参考文献
- [1] DeepSeek-AI. “DeepSeek-V4.1-Flash: Pushing the Limits of KV Cache Compression.” 2026-09. arXiv:2609.19969 —— 第 2.3 节（CSA2 的简化、三种模式、分层稀疏索引器、相关工作的定位）、第 2.4.4 节（FP4 主 KV 格式）、第 3.1.2 与 3.2 节（训练与推理实现）、第 4.2.1 节（逐层模式安排）、表 1（LongBench-V2）、第 6 节（局限性）。
- [2] Hugging Face：deepseek-ai/DeepSeek-V4.1-Flash 的 config.json ——
compress_ratios、kv_source_layer_ids、index_source_layer_ids、候选池参数、head_dim与index_head_dim。 - [3] DeepSeek-AI. “DeepSeek-V4: Towards Highly Efficient Million-Token Context Intelligence.” 2026-04. arXiv:2606.19348 —— CSA 的重叠压缩、索引器与 MXFP4 格式，以及 V4 在 MRCR 1M、CorpusQA 1M 上的评测。