# CSA2：跨层共享的压缩稀疏注意力

> CSA2 给每层指定 Full、Reindex、Reuse 三种模式之一，40 层里只有 4 层自己产生全局 KV；解码器再用分层候选池限制索引范围，配合 FP4 把每 token 全局缓存压到 890 字节。

- 作者：David（道雾轩）
- 专栏：DeepSeek V4.1 Flash 深度解析（https://daiw.org/manual/deepseek-v4-flash.md）
- 最后更新：2026-09-19
- 原文：https://daiw.org/manual/deepseek-v4-flash/csa2
- 转载与引用：请注明出处并附原文链接（https://daiw.org/about/copyright）

V4 的全局注意力由 CSA 与 HCA 两种机制交替组成（见[前代那两章](https://daiw.org/manual/deepseek-v4-flash/csa)）。V4.1 把 HCA 整个拿掉，只保留一种改进过的机制，叫 **CSA2（Compressed Sparse Attention 2）**。报告写得很直接：不同于 V4 的 CSA–HCA 混合架构，V4.1-Flash 只用 CSA2 [1]。

## 保留了 CSA 的骨架

CSA2 的基本动作和 CSA 一样 [1]：

1. 把每 $m$ 个 token 的 KV 压成一条“主 KV”；
2. 一个轻量的**索引器**用自己的 Q 和 K 给这些主 KV 条目打分，为每个 query 选出分数最高的 512 条；
3. query 对这 512 条，加上本层最近 128 个 token 的滑动窗口 KV，一起做注意力。

在这副骨架上，CSA2 做了两处简化：一是**去掉压缩时的重叠和绝对位置编码**（CSA 的每条压缩条目取自 $2m$ 个原始条目，相邻条目的来源互相重叠）；二是**索引器的 K 直接从主 KV 投影出来**，不再像 CSA 那样从隐藏状态另走一条压缩路径。报告说两处都是为了实现更简单、训练更快 [1]。压缩率 $m=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。

<Callout type="info">
  **跨层复用并不新**，报告自己列了先例：跨层共享 KV 缓存的工作、跨层复用 top-k 索引的 IndexCache、全网只算一次稀疏路由的 YOIO、让稀疏层复用稠密层缓存的 HySparse。报告的判断是，单独复用索引省不了主 KV 的存储，全网共享一套路由会损失性能，混合方案仍保留稠密注意力层，而且**没有一种同时覆盖条目大小、序列、层数这三个维度**；CSA2 把三者一起用上，并把“共享缓存”和“复用索引”拆成两个独立的开关 [1]。这是厂商对自身工作的定位。
</Callout>

## 解码器里的分层索引

跨层复用减少了跑索引器的层数，但剩下的索引器每次仍要给全部可见位置打分；上下文到了百万级，这笔开销依旧可观。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 的格式细节放在[精度那一章](https://daiw.org/manual/deepseek-v4-flash/fp8-fp4)。

## 快在哪、险在哪

**快**：报告说，绝大多数层（即 CSA2 处于 Reuse 模式的层）整层在预填充时只需 15 个 kernel、解码时只需 11 个，靠的是把注意力前后的位置编码与类型转换、门控、mHC、MoE 等操作各自融合进少数几个大 kernel [1]。训练侧则要处理“共享的层可能分在不同流水线阶段”的问题，报告用影子索引器、扩展流水线间传递的数据、按微批次管理共享状态来解决 [1]。

**险**：稀疏注意力的老问题——**选错了不会报错**。某个关键位置没进 top-512，模型就看不到它，输出只是悄悄变差。CSA2 又叠了两层“替别人选”：Reuse 层用的是上游层选的索引，Reindex 层只能在第 20 层圈定的候选池里选。报告在局限性一节承认“CSA2 中潜在的选择错误”可能在未测试的边界情形下导致能力下降，并把“长上下文上的稀疏检索”列为后续压测重点 [1]。

<Callout type="warn">
  **目前查不到的数字**：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 没有。**对一个主打百万上下文、又大幅复用稀疏选择的模型，这是最该补上的一块**，在第三方测出来之前，用它做超长文档精确检索要自己先测。
</Callout>

下一章讲缓存的另一半：滑动窗口 KV 为什么可以不落盘。👉 [SWA 有界重放：SSD 上只剩八分之一](https://daiw.org/manual/deepseek-v4-flash/swa-bounded-replay)

## 参考文献

- [1] DeepSeek-AI. “DeepSeek-V4.1-Flash: Pushing the Limits of KV Cache Compression.” 2026-09. [arXiv:2609.19969](https://arxiv.org/abs/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](https://huggingface.co/deepseek-ai/DeepSeek-V4.1-Flash/blob/main/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](https://arxiv.org/abs/2606.19348) —— CSA 的重叠压缩、索引器与 MXFP4 格式，以及 V4 在 MRCR 1M、CorpusQA 1M 上的评测。