CSA/HCA 注意力：DeepSeek-V4 的混合压缩稀疏机制

CSA/HCA 试图把“压缩表示”和“减少历史访问”组合起来：不同层采用不同压缩比，CSA 用 Indexer 选择少量历史位置，HCA 则对高度压缩后的条目做全量访问。

通用的 MHA、GQA、MLA、稀疏与递推坐标见 Attention 架构演化；本页只解释 CSA/HCA 案例本身。

1. 三类层分别控制什么

摄入材料给出的 V4-Pro 案例包含三种层：

类型	案例 compress_ratio	访问方式	主要 cache 项
SWA	0	只访问最近窗口	window
CSA	4	窗口 + Indexer 选出的 top-k	window + seq/4 + indexer
HCA	128	窗口 + 全部高压缩条目	window + seq/128

材料描述的 61 个主干层约为 29 个 CSA、31 个 HCA 和 1 个 SWA；精确层序必须从实际模型 config 读取，不能用这组计数替代配置。

2. CSA：压缩后再筛选

KV stream
  -> compressor（案例 ratio=4）
  -> compressed entries
  -> Indexer score
  -> select top-k（案例 top-1024）
  -> sparse attention（window + selected entries）

CSA 的关键不是“只存四分之一就结束”，而是多出一个选择路径。容量账要计 compressed KV 与 Indexer cache；时延账还要计 Indexer 扫描、top-k 选择和稀疏 attention。

Indexer 能否成为瓶颈取决于它扫描的条目数、维度、精度、kernel 与 batch shape。top-1024 只约束后续 sparse attention 的候选数，不代表 Indexer 自己只看 1024 个位置。

3. HCA：更强压缩后全量访问

KV stream
  -> compressor（案例 ratio=128）
  -> compressed entries
  -> attention over window + all compressed entries

HCA 不需要 Indexer，但仍要访问全部压缩条目。若输入约 1M token，seq/128 仍有约 7.8K 个条目；它比 dense history 小很多，却不是固定大小状态。

压缩越强也不等于质量损失越小。哪些层使用 HCA、CSA 或 SWA 是模型训练合同的一部分，不能在 serving 时仅凭显存目标任意替换。

4. 异构精度如何进入 entry bytes

摄入材料给出的案例 entry 由两部分组成：

分支	案例维度与精度	payload
非 RoPE	448 dims，FP8	448 bytes
RoPE	64 dims，BF16	128 bytes
合计	512 dims	576 bytes/entry

Indexer cache 另按 FP4 payload 估算。576 bytes 只是 payload 口径；Scale、Hadamard/量化元数据、对齐、页尾浪费与 workspace 尚未计入，不能直接当 allocator 实测值。

5. 百万上下文估算怎么记

对层 $l$，窗口为 $W$、压缩比为 $r_l$、entry payload 为 $E$：

$$N_l= \begin{cases} W, & r_l=0\\ W+\left\lceil\frac{\max(S-W,0)}{r_l}\right\rceil, & r_l>0 \end{cases}$$ $$M_{\text{main}}=\sum_l N_l\times E$$

再单独加入 CSA Indexer cache。按摄入材料的近似口径，S=1,000,000、29 CSA、31 HCA、1 SWA、W=128、E=576 bytes：

项	近似结果
CSA 主 cache	4.18 GB
HCA 主 cache	0.14 GB
SWA 主 cache	0.00007 GB
Indexer FP4 payload	0.47 GB
合计	4.79 GB/request

这是未做 CP 分片的十进制 payload 估算，不含 allocator 碎片、Scale、graph pool、kernel workspace、通信 buffer，也未证明实际 runtime 采用相同 layout。

6. 容量之外还有哪些瓶颈

1. Indexer scan：CSA 每个 decode step 可能扫描随上下文增长的压缩条目。
2. Sparse kernel 效率：理论交互减少不保证不规则 gather 能吃满硬件。
3. Context Parallel 通信：per-rank cache 与全局可见历史可能需要额外交换。
4. Prefix load：远端或 Host cache 的字节下降后，带宽和首 token 延迟仍需实测。
5. Prefill activation：峰值可能受 kernel chunk 控制，不能只用完整 seq_len 推算。

这些是需要测量的候选瓶颈，不是由压缩比直接推出的因果结论。

7. 模拟器与验证合同

建模至少显式输入：

• 每层 compress_ratio 与 window_size；
• entry 的非 RoPE/RoPE 维度、dtype、Scale 与对齐；
• CSA 层数、Indexer 维度、dtype 和选择规模；
• CP/TP 下的 per-rank 分片方式；
• 是否计 allocator、workspace 与通信 buffer。

结果应标成“配置估算”，直到与 allocator bytes、kernel trace 和目标负载校准。缺失的 config 或 Indexer 信息应返回 missing / unavailable，不能填零后宣称可比较。

相关页面

• Attention 架构演化 — CSA/HCA 所在的表示压缩与访问稀疏坐标。
• KV Cache — 逻辑 payload、物理分配和生命周期。
• DeepSeek MLA — latent KV、RoPE 分支与矩阵吸收。
• 模拟器建模指南 — CSA/HCA 的逐层估算与作用域。
• FP4/FP8 量化 — dtype、Scale 与运行时合同。