# 前代 · HCA：128 倍压缩后再做稠密注意力

> 前代 V4-Flash 的重压缩注意力：把每 128 个 token 压成一条，再在压缩序列上老老实实全看一遍——用“看得粗但看得全”补稀疏注意力可能漏看的风险。V4.1 已整个拿掉 HCA。

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

<Callout type="info">
  **本篇描述的是前代 DeepSeek V4-Flash 的设计。** V4.1-Flash **不再使用 HCA**：报告写明“不同于 V4 的 CSA–HCA 混合架构，V4.1-Flash 只用 CSA2”[3]。本篇保留初版要点，并按 V4 论文更正了关于压缩方式与层分布的说法。
</Callout>

**HCA**（Heavily Compressed Attention，重压缩注意力）是 V4 的另一半答案。它的做法乍看很反直觉：

> **把序列沿时间维压掉 128 倍，然后在压缩后的序列上做完整的、稠密的注意力。**

## 128 倍是什么概念

1M token 压 128 倍，剩下约 **8,000 条**。8,000 条的稠密注意力是完全算得起的。所以 HCA 的逻辑很清楚：

> **既然全长序列的稠密注意力算不起，那就把序列压到算得起为止，然后全算一遍。**

## 怎么压

初版这里写的是“论文与模型卡对 HCA 的压缩方式披露有限”，**这不对**。V4 论文第 2.3.2 节给了完整做法：总体和 CSA 类似——先算出原始 KV 与压缩权重，每 128 个条目按“softmax 权重加可学习位置偏置”的方式加权合成一条——区别有两处：压缩率大得多（128），而且**相邻块之间不重叠** [1]。压完之后**不做稀疏选择**，每个 query 对全部压缩条目做注意力，同样采用所有查询头共享一份 KV 的 MQA 方式和分组输出投影；和 CSA 一样，它也带一条最近 128 个 token 的滑动窗口分支 [1]。

## 它补的正是 CSA 的短板

回想[上一篇](https://daiw.net/manual/deepseek-v4-flash/csa)提到的风险：CSA 靠闪电索引器挑 top-k，**可能漏选**，而且是静默的。HCA 没有这个问题——**它看全部**。

代价换了个方向：**看得全，但看得粗**。128 倍压缩意味着每条表示概括了约 128 个原始 token 的信息，让它复述某个具体字符串是不可能的；但让它知道“大约在文档的哪个位置讨论过某个话题”，是可以的。

| | **CSA** | **HCA** |
| --- | --- | --- |
| 压缩率 | 4 倍 | **128 倍** |
| 注意力形态 | **稀疏**（top-k） | **稠密**（全看） |
| 强项 | 细节保真 | **全局覆盖，不漏** |
| 风险 | 静默漏选 | 细节被抹平 |
| 一句话 | “看得细，但可能没看到” | “一定看到了，但看得糊” |

**这是一对互补的失败模式。** 两者叠在同一个模型里，粗粒度的全局感知和细粒度的局部检索都有了着落。

<Callout type="info">
  用人的阅读打个比方：**HCA 像是先把整本书快速翻一遍，记住每一章大概讲什么；CSA 像是翻回相关的那几页仔细读。** 这只是理解上的类比——模型里两者是交替排列的层，不是先后的两步。
</Callout>

## 它在网络里的位置

初版说“HCA 集中在网络深度的后 2/3”，并据此讲了一番“浅层保细节、深层压狠点”的道理。**这个前提是错的**，来源是一篇第三方拆解。V4 论文与 `config.json` 显示：V4-Flash 前 2 层只用滑动窗口，此后 **CSA 与 HCA 一层隔一层交替**，HCA 共 20 层，从第 3 层（从 0 数）一直分布到第 41 层 [1][2]。V4-Pro 则是前 2 层就用 HCA，之后同样交替 [1]。具体排布放在[下一篇](https://daiw.net/manual/deepseek-v4-flash/hybrid-ratio)。

## V4.1 为什么不要它了

报告没有给出“去掉 HCA”这一项的单独消融。它给的视角是：V4 可以看成“以滑动窗口处理局部、再用压缩的全局上下文做补充”的结构，所以 V4.1 专注于**简化全局分支**，同时基本保留局部注意力 [3]。落到结构上，就是把两种压缩档位并存的全局分支，换成一种档位（编码器压 2 倍、解码器不压）加上跨层共享。

从账面看，这一换并没有让缓存变大：V4.1-Flash 每 token 的全局 KV 从 3,514 字节降到 890 字节 [3][4]。但要看清少了什么：**V4.1 里不再有“全看一遍”的稠密全局分支**，每个 query 看到的全局信息都经过 top-512 的稀疏选择，外加 128 个 token 的滑动窗口（见 [CSA2](https://daiw.net/manual/deepseek-v4-flash/csa2)）。HCA 那种“一定看到、只是看得糊”的兜底没有了。**这是一次路线上的调整，得失如何，还要看长上下文检索类的独立评测。**

下一篇看这两种注意力到底怎么排。👉 [前代 · CSA 与 HCA 怎么排](https://daiw.net/manual/deepseek-v4-flash/hybrid-ratio)

## 参考文献

- [1] DeepSeek-AI. “DeepSeek-V4: Towards Highly Efficient Million-Token Context Intelligence.” 2026-04. [arXiv:2606.19348](https://arxiv.org/abs/2606.19348) —— 第 2.3.2 节（HCA 的压缩方式、稠密 MQA、滑动窗口分支）、第 4.2.1 节（V4-Flash 与 V4-Pro 的交替排布）。
- [2] Hugging Face：[deepseek-ai/DeepSeek-V4-Flash 的 config.json](https://huggingface.co/deepseek-ai/DeepSeek-V4-Flash/blob/main/config.json) —— `compress_ratios`：HCA（128）所在的层。
- [3] DeepSeek-AI. “DeepSeek-V4.1-Flash: Pushing the Limits of KV Cache Compression.” 2026-09. [arXiv:2609.19969](https://arxiv.org/abs/2609.19969) —— “只用 CSA2”的原话、“简化全局分支”的视角、每 token 全局 KV 的对比。
- [4] Hugging Face 模型卡：[deepseek-ai/DeepSeek-V4.1-Flash](https://huggingface.co/deepseek-ai/DeepSeek-V4.1-Flash) —— 各代每 token 全局 KV 对比图。