CSA + HCA 混合注意力机制
如何让万亿参数模型读完百万字还不炸显存？一套混合注意力机制的工程奇迹 | 预计阅读时间：30 分钟
一、引言
2026 年 4 月，DeepSeek V4 发布时，公告里有一句话被反复引用：
"从现在开始，1M（一百万）上下文将是 DeepSeek 所有官方服务的标配。"
这句话放在一年前会显得狂妄。1M token 的上下文窗口不是什么新鲜概念——Gemini 早就支持了，Claude 也在不断扩展上下文长度。问题是：成本。
一百万 token 的输入，如果用标准 Transformer 注意力机制，光是算一遍注意力就要做 1 万亿次点积。KV Cache 要存 1M 个 key-value 向量——每个向量是 128 维（以 V4 的配置计算），单层就要 3.2 GB 显存，V4-Pro 有 61 层，光注意力就得吃掉近 200 GB。
实际上没人会这么干。长上下文模型之所以能跑，靠的不是堆算力，而是各种优化技巧把 O(n^2) 的复杂度压下来。
DeepSeek V4 的答案是一套混合注意力架构，包含三个分支：
- CSA（Compressed Sparse Attention）——压缩稀疏注意力。把每 m 个 token 的 KV 压缩成一个条目，然后只选最相关的那些来做注意力。
- HCA（Heavily Compressed Attention）——重度压缩注意力。用更高的压缩比把序列压到几乎可以忽略的长度，然后做密集型注意力。
- SWA（Sliding Window Attention）——滑动窗口注意力。保留最近窗口内 token 的原始 KV，保证局部精度不丢失。
三个分支交替排列，加上一层全量注意力兜底。最终效果是：在 1M token 输入下，V4-Pro 的推理 FLOPs 只有 DeepSeek V3.2 的 27%，KV Cache 只有 10%。V4-Flash 更激进——FLOPs 仅 10%，KV Cache 7%。
百万上下文从一个"技术上能做但实际用不起"的演示功能，变成了真正可以日常跑的工作负载。
本文从传统注意力的痛点说起，依次拆解 CSA 和 HCA 的设计原理，最后回到数字本身——让你不仅知道它做了什么，还知道它为什么能省这么多。
二、传统注意力机制的瓶颈
2.1 O(n^2) 复杂度——一切问题的根源
Transformer 的核心是 Scaled Dot-Product Attention：
Attention(Q, K, V) = softmax(Q @ K^T / sqrt(d)) @ V对长度为 n 的序列，Q 和 K^T 的矩阵乘法产生 n × n 的注意力分数矩阵。这个操作的时空复杂度是 O(n^2)。
当 n=4096（V3 典型上下文），这个平方增长不明显——4096^2 = 1677 万，GPU 一眨眼就算完了。
当 n=1,000,000，结果是 1 万亿次操作。不仅是计算量，存这个 n×n 矩阵本身就需要约 4 TB 显存（BF16 格式）。
这是长上下文模型面临的第一道墙：无论序列多长，每生成一个新 token，都要和之前所有的 token 重新计算一遍注意力。
| 序列长度 | 注意力分数矩阵大小 | BF16 显存占用 | V4-Pro 推理时间（估算） |
|---|---|---|---|
| 4K | 16M 元素 | 32 MB | 毫秒级 |
| 32K | 1B 元素 | 2 GB | 秒级 |
| 128K | 16B 元素 | 32 GB | 不可接受 |
| 1M | 1T 元素 | 4 TB | 不可能 |
这个表格是理论值，实际不会有人直接算 1M × 1M 的注意力矩阵。但它说明了常识：暴力全量注意力在百万级别是不可能的。
2.2 KV Cache——推理的显存杀手
自回归推理时，每个 token 的 Key 和 Value 向量会被缓存下来供后续 token 使用，这就是 KV Cache。
KV Cache 的显存占用 = 序列长度 × 层数 × 头数 × 头维度 × 数据类型大小 × 2（K 和 V）
代入 V4-Pro 的参数：
- 序列长度：1,000,000
- 层数：61
- 头数 × 头维度：~128 × 128（简化）
- 数据类型：BF16（2 字节）
一层：1M × 128 × 2 × 2 ≈ 512 MB 61 层：512 MB × 61 ≈ 31 GB
这还只是 KV Cache 的原始存储。加上中间激活值、模型权重、优化器状态（训练时），显存需求会迅速突破单张 H100（80 GB）的容量。
而且 KV Cache 的瓶颈不只是容量——带宽才是很多场景的短板。每次生成一个新 token，需要把整个 KV Cache 从 HBM 读入计算单元。1M 序列的 KV Cache 如果完全未压缩，61 层的数据量数十 GB，每次预填充需要从 HBM 搬运一次，延迟会急剧上升。
这就是第二道墙：即便你能存下 KV Cache，IO 带宽也不够用。
2.3 从 Token 到注意力：一次完整的计算链路
为了理解后面的优化策略，有必要完整走一遍标准注意力在推理时的计算链路。
自回归生成中，每一步做的事：
输入: 前一步生成的 token
Step 1: 查 Embedding 表，得到 token 向量
Step 2: 通过 QKV 投影矩阵，得到当前 token 的 Q、K、V
Step 3: 把 K、V 追加到 KV Cache
Step 4: 从 KV Cache 读出所有之前的 K、V
Step 5: Q @ K^T ——计算当前 query 和历史所有 key 的点积
Step 6: softmax ——归一化注意力分数
Step 7: 加权求和——用 softmax 输出对 V 做加权平均
Step 8: 经过 FFN 层，生成输出 token对短序列，Step 5-7 的计算量很小。对 1M 序列，瓶颈在 Step 4（IO 密集）和 Step 5（计算密集）。
分阶段来看：
Prefill 阶段（处理输入 prompt）：一次性读入所有 token 的 K 和 V。KV Cache 从零开始构建。如果 prompt 有 1M token，这一阶段的计算量和 IO 开销是最大的。但 prefill 阶段只做一次。
Decode 阶段（逐个生成输出 token）：每步只增加一个 token 的 KV。IO 开销来自搬运整个 KV Cache（如果无优化）。Decode 阶段要走 1M 步（如果要生成 1M token），虽然每步的计算量小，但 IO 瓶颈在叠加。
KV Cache 在 decode 阶段成了"死重"——每次都要从头到尾搬一遍。这种"从 HBM 到计算单元"的数据搬运，延迟远高于计算本身的延迟。所以长上下文推理的真正瓶颈不是计算 FLOPs，而是内存带宽和容量。
理解了这个链路，才能理解 V4 的优化为什么这么有效：CSA 和 HCA 不是在加速"计算"，而是在减少"搬运"——压缩后的 KV Cache 更小，每次搬运的数据量显著降低。这直接缓解了 IO 瓶颈。
2.4 行业已有的解决方案
长上下文问题不是 DeepSeek 第一个碰到。每个做长上下文模型的团队都拿出了自己的方案。
| 方案 | 代表模型 | 核心思路 | 局限性 |
|---|---|---|---|
| 滑动窗口注意力 | Mistral, Gemma | 每个 token 只关注附近 w 个 token | 丢失远程依赖 |
| 稀疏注意力 | BigBird, Longformer | 固定稀疏模式 + 随机稀疏模式 | 稀疏模式固定，不灵活 |
| 线性注意力 | Linear Transformer, Mamba | 用核方法替代 softmax，O(n) 复杂度 | 表达能力受限，长文档效果下降 |
| 分段注意力 | GPT-4, Gemini | 把长序列切块，块内全量，块间压缩 | 工程复杂，信息在块边界截断 |
| 环形注意力 | YaRN, NTK-aware | 位置编码外推扩展到长序列 | 只解决位置编码，不解决复杂度 |
滑动窗口和稀疏注意力的问题是"视野受限"。你能做长上下文，但模型实际"看到"的上下文是有限的——远处的 token 在注意力分数矩阵中被忽略，模型无法利用它们。
线性注意力理论上能做到 O(n)，但在实践中，线性的核近似损失了 softmax 的对比度和选择能力。长文档任务中，效果退化明显。
这些方案的本质矛盾是：效率和质量之间的 trade-off。压得越狠，越容易丢失信息。
2.5 效率-精度权衡曲面
上面列出的所有方案，都可以放在同一个坐标系里衡量：
精度（信息保持）
↑
全量注意力 ● │
│
滑动窗口 ● │
│
稀疏注意力 ● │
│
线性注意力 ● │
│
└─────────────────→ 效率（FLOPs / 显存）没有一个方案站在右上角。每个方案都在向右下移动（效率更高但精度下降），只是下降的方式和斜率不同。
DeepSeek V4 的混合注意力策略不试图用一个方案站在右上角——它用了三个方案，分别覆盖坐标系的三个区域：
- CSA：精度中高、效率中高。适合需要精确注意力但可容忍少量压缩的场景。
- HCA：精度中等、效率极高。适合需要全局覆盖但不需要精细度的场景。
- SWA：精度极高、效率中等。适合局部细节需要无损保真的场景。
三者叠加，形成了一个覆盖精度-效率空间的"复合面"。任何一个单一方案都做不到这种覆盖。
这就是 V4 混合注意力的核心洞察：与其在单一方案上追求极限，不如用多个方案互补，让每个方案做自己最擅长的事。
2.6 DeepSeek 的前代基础
DeepSeek V3 使用 MLA（Multi-head Latent Attention），核心思路是降秩压缩 KV 维度，将 KV 的投影矩阵压缩到一个低秩空间中。MLA 在 KV 的头数维度上做压缩，节省的是"头的数量"。
DeepSeek V3.2 引入 DSA（DeepSeek Sparse Attention），首次在序列维度上做稀疏化。DSA 的出发点很简单：注意力矩阵是稀疏的——大部分 token 对当前 token 的贡献接近于零，模型完全可以只关注最相关的那一小部分。
V4 在 DSA 的基础上做了两件事：把"稀疏选择"和"KV 压缩"两个维度结合起来（CSA），再叠加一个更高压缩比的全局视角（HCA）。
从 MLA → DSA → CSA+HCA，这条演进路线有一个明确的趋势：注意力机制的优化维度在从"头数压缩"向"序列压缩"转移。因为上下文窗口在快速扩张，序列维度已经取代模型维度成为瓶颈。
三、DSA 基础——DeepSeek Sparse Attention
在进入 CSA 和 HCA 之前，有必要先理解它们的基础：DSA。
DSA 是 DeepSeek V3.2 引入的稀疏注意力机制，也是 V4 混合注意力的技术起点。
3.1 稀疏注意力的直觉
不是所有的 token 都值得同等的注意力。当你在处理一个 1M token 的文档时，"巴黎是法国的首都"这个事实在文档中出现过一次，99.9% 的 token 和它无关。
标准注意力的问题是：它算出了所有 token 对之间的分数，然后 softmax 把绝大多数分数压到接近零——但算力已经花掉了。
DSA 的思路是：提前判断哪些 token 值得关注，只算那些值得关注的。
3.2 注意力矩阵的稀疏性假设
DSA 的可行性建立在两个观察上：
注意力矩阵是近似稀疏的。 在一个典型的长文档中，大部分 token 对之间的注意力分数在 softmax 后趋近于零。对于当前 token 来说，真正有信息增益的上下文 token 占比很小。有研究（如《Efficient Transformers: A Survey》）指出，在多数自然语言任务中，一个 query 只需要关注 top 5-10% 的 key 就能保留 95% 以上的有效信息。
这种稀疏模式是可预测的。 虽然 token 之间的精确注意力分数需要全量计算才能得到，但哪些 token "可能重要"可以用一个轻量模型近似判断。这就是 Selector 的角色——它不是去精确计算注意力分数，而是做一个"快速筛子"，把明显不相关的 token 先过滤掉。
这两个观察在数学上不一定总是成立（有些任务需要精确的全局注意力），但在实际训练数据中，足够多的场景满足稀疏性假设，使 DSA 能够保持不错的效果。
3.3 DSA 的核心机制
DSA 在每个注意力层引入一个轻量的选择器（Selector），用低秩的 query 和 key 计算近似的注意力分数，选出 top-k 的 token 作为"候选项"。然后只对这些候选项做标准的注意力计算。
Selector 的设计有几个关键参数：
- 选择数量 k：控制有多少 token 进入最终注意力。k 越大，信息保留越多，计算量也越大。V3.2 中 k 的典型值在 2048-4096 之间，具体取决于层的位置和序列长度。
- 低秩比例 r：Selector 使用比标准注意力更低的 QK 维度。标准 QK 可能为 128 维，Selector 可能只有 16-32 维。这使得打分的计算量下降 4-8 倍。
- 选择策略：V3.2 的 Selector 支持多种选择策略，包括全局 top-k、局部 top-k（在滑动窗口内选）和混合策略。
DSA 工作流程（简化）
Q, K, V ← 当前 token 的 query/key/value
│
▼
┌─────────────┐
│ Selector │ 低秩近似，快速打分
│ 轻量排序 │ 选出 top-k 候选位置
└──────┬──────┘
│ top-k 索引
▼
┌─────────────┐
│ Full Attn │ 只对 k 个候选做标准注意力
│ on top-k │ 复杂度 O(n × k) 而非 O(n²)
└─────────────┘Selector 的 key 维度比标准 key 低很多（低秩压缩），所以打分的计算量小。本质上，它是在用一个小模型模拟大模型的注意力分数分布——不求完全精确，只求不遗漏真正重要的 token。
3.4 DSA 的成绩和局限
DSA 已经证明了"稀疏注意力 + 长上下文"的可行性。DeepSeek V3.2 通过 DSA 把上下文窗口扩展到了 128K，在长文档任务上效果不错。
但 DSA 有一个结构性的局限：稀疏选择意味着它只能看到"和当前 query 最相关"的 token。那些不太相关但宏观上重要的信息（比如文档的核心论点、整体结构），可能因为和每个局部 query 的相关性都不够高而被漏掉。
换句话说，DSA 擅长局部的、精确的注意力，但不擅长全局的、抽象的注意力。
这正是 V4 引入 HCA 的原因：让另一套机制专门负责全局视角，弥补 DSA 的盲区。
3.5 从 DSA 到 CSA——压缩的引入
DSA 在 token 级别做稀疏选择。随着序列继续拉长到 1M，即使是只处理 top-k 个 token，KV Cache 的存储也在线性增长——因为存的是原始 KV。
V4 在前面的基础上加了"压缩"：把 KV 先压缩再存。DSA 选的是 token，CSA 选的是压缩块。
这是从"稀疏"到"压缩稀疏"的关键一步。
四、CSA：压缩稀疏注意力
CSA（Compressed Sparse Attention）是 V4 混合注意力的第一个主力分支。它的设计目标很明确：在序列维度上压缩 KV Cache，同时保留局部细节的准确注意力。
4.1 粗到细：token 维度压缩原理
CSA 的核心操作是"组合压缩"——把连续的几个 token 打包成一个压缩条目。
CSA 序列压缩示意
原始 token 序列（1M tokens）:
[T1, T2, T3, T4] [T5, T6, T7, T8] [T9, T10, T11, T12] ...
↓ 压缩 ↓ 压缩 ↓ 压缩
压缩 KV 序列（250K entries）:
[C1] [C2] [C3] ...V4-Pro 中，CSA 的压缩因子 m=4，即每 4 个连续 token 合并成一个压缩 KV 条目。1M token → 250K 压缩条目。
压缩方式不是简单的平均池化。CSA 使用一个轻量的线性变换（类似平均池化但带学习参数），将 m 个 token 的 key 和 value 投影到同一个潜在空间。这样压缩条目能保留块内的代表性信息。
压缩函数的设计有一个关键权衡：压缩后的表示是"平均"还是"摘要"？
平均池化（简单求平均）的好处是无参数、速度快，但会抹平块内的差异性。如果块内有"重要的"和"不重要的" token，平均池化会让重要信息被稀释。
可学习压缩（线性变换 + 激活）的好处是模型可以学习如何从块内提取最相关的信号。但多了可学习参数，增加了训练开销。
CSA 在两者之间做了折中：使用一个轻量（极少参数）的线性映射，近似于"带权重的平均"。 这个权重是通过训练学到的，可以在推理时确定性执行。算力开销基本为零——就是一次小矩阵乘法。
4.1.1 压缩因子的选择
CSA 的压缩因子 m=4 不是随意定的，背后有一个权衡：
| 压缩因子 m | 压缩后条目数 | KV Cache 节省 | 块内细节保留 |
|---|---|---|---|
| 1（无压缩） | 1,000,000 | 0% | 100% |
| 2 | 500,000 | 50% | 中 |
| 4（V4-Pro 值） | 250,000 | 75% | 较高 |
| 8 | 125,000 | 87.5% | 较低 |
| 16 | 62,500 | 93.75% | 很差 |
m=4 在压缩比和精度之间取了比较合理的平衡。压缩后 250K 条目仍然较多，需要第二层的稀疏选择来进一步缩减。如果 m 更大（如 8 或 16），稀疏选择之后的精度损失可能不可控。
V4-Flash 的 CSA 压缩因子可能略有不同（没有官方披露细节，但推测会更大一些，因为 Flash 模型更小，对压缩的容忍度更高）。
4.2 Lightning Indexer——轻量选择器
压缩之后还有 250K 个条目。如果对这 250K 个条目做全量注意力，复杂度还是 O(n×250K)——比起 O(n×1M) 好一些，但还不够。
CSA 的第二层压缩来自稀疏选择。在每个注意力层，一个叫做 Lightning Indexer 的轻量模块对所有压缩条目打分，选出 top-k 个最相关的。
Lightning Indexer 的内部结构值得展开。它不是简单的线性打分器，而是一个低秩多查询注意力网络：
Lightning Indexer 的内部结构
输入: 压缩后的 KV 条目 [C1, C2, ..., CN] ← N=250K
+ 当前 query 的 Q 向量
1. 生成 indexer query:
Q_idx = Q @ W_q_idx ← W_q_idx 是低秩投影 (dim → r)
2. 准备 indexer key:
每个压缩条目 Ci 经过 K_idx = Ci @ W_k_idx 得到 indexer key
K_idx_mat = [K_idx_1, K_idx_2, ..., K_idx_N]
3. 多 query 打分:
对每个 indexer 头 h:
scores_h = Q_idx_h @ K_idx_mat^T ← 长度为 N 的分数向量
4. ReLU 加权:
final_score = Σ_h ReLU(scores_h) ← 多头聚合
5. Top-k 选择:
selected = argsort(final_score)[:1024]
输出: 1024 个选中的压缩条目索引这里有两个关键设计决定：
第一是多 query 头。 Indexer 使用多个 query 头（数量小于标准注意力的头数），每个头关注不同类型的信息。一个头可能关注"语义相似性"，另一个头关注"位置接近性"。通过 ReLU 聚合，只要任何一个头认为某个块重要，这个块就有可能进入 top-k。这种设计提高了选择的鲁棒性。
第二是 FP4 量化路径。 Indexer 的 QK 计算全程跑在 FP4 精度上。FP4 量化带来的精度损失在 Indexer 场景中是可接受的——因为这个阶段只需要"谁可能重要"的粗略判断，不需要精确的注意力分数。同时 FP4 将 Indexer 的显存占用和计算量降低了 4-16 倍（取决于量化策略）。
CSA 完整流程
输入：压缩 KV 序列（250K entries） + 当前 query
1. Lightning Indexer 用低秩 query/key 打分
2. 选出 top-k = 1024 个压缩条目
3. 只对这 1024 个条目做标准注意力
4. 输出加权聚合结果Lightning Indexer 的"轻"体现在两个地方：
- 低秩：Indexer 的 query 和 key 维度远小于标准注意力。它本质上是一个多 query attention（多个 query 头共用一个低秩投影），用极少的参数完成近似打分。
- 低精度：Indexer 的 QK 路径全程跑在 FP4 上。FP4 量化将索引过程的计算开销进一步降低，同时 top-k 召回率仍保持在 99.7%（以 BF16 为基准）。
V4-Pro 中 top-k = 1024。这意味着在注意力计算时，模型只需要处理 1024 个压缩条目而不是 250K 个。加上压缩的 4 倍，CSA 把核心注意力的复杂度从 O(1M^2) 降到了 O(1M × 1K)——大约三个数量级的差距。
4.3 局部细节的保护策略
压缩必然带来信息丢失。m=4 的压缩因子不算大（4 个 token 合并为一个条目），但如果每个压缩块内的 4 个 token 都同等重要、不分轻重，CSA 的粗略表示可能会丢掉关键细节。
为了弥补局部精度，DeepSeek 引入了 Sliding Window Attention（SWA） 作为补充分支。
SWA 做的事情很简单：保留最后 n_win 个 token 的原始未压缩 KV。在 CSA 做注意力计算时，这些原始 KV 和压缩 KV 一起参与注意力计算。
CSA + SWA 的混合计算
当前 query token 关注的 KV 来源：
1. 压缩 KV 条目（选中的 top-k 块）——远程上下文
2. 滑动窗口 KV（最近 n_win 个 token）——局部精度
3. 未压缩尾部 KV ——当前块内未达到压缩边界的 token
三者拼接后一起做核心注意力这种设计保证了：远方有压缩，近处有精度。 模型既能通过压缩 KV 获取长距离的信息，又能通过 SWA 和尾部 KV 保证当前位置附近的细粒度注意力不丢失。
V4-Pro 的滑动窗口大小 n_win 约为 4096（具体数值随配置微调），和传统模型的典型上下文长度相当。这意味着在局部范围内，CSA + SWA 的表现不输于全量注意力。
4.4 块稀疏模式图解
为了直观展示 CSA 如何组织计算，下面是用伪代码表示的块稀疏注意力模式：
序列: [b1] [b2] [b3] [b4] ... [bN] ← N = 250K 个压缩块
query: q
Step 1: Indexer 打分（对所有块）
scores[i] = indexer_query @ indexer_key[i] ← FP4 低秩
Step 2: ReLU 加权求和，输出每个块的最终分数
final_scores = ReLU(scores)
Step 3: 选 top-k
selected = argsort(final_scores)[:1024] ← 1024 个块
Step 4: 核心注意力
attn = softmax(q @ K_selected^T / sqrt(d))
output = attn @ V_selected关键细节是ReLU 加权求和。Indexer 不是用一个单头打分，而是用多个 indexer query 对压缩 key 打分，然后通过 ReLU 做加权。这给选择过程引入了非线性，比简单的线性打分更准确。同时 ReLU 保证了"负相关"的块不会被选择，进一步提升了选择质量。
五、HCA：重度压缩注意力
CSA 解决了"如何高效做稀疏注意力"的问题，但它有一个结构性的盲区：稀疏选择意味着绝大部分 token 根本没被考虑。 如果某个信息不突出但全局重要（比如文档的主旋律、反复出现的主题词），它可能在任何单次 query 中都不进入 top-k。
HCA（Heavily Compressed Attention）弥补的就是这个空白。
5.1 更激进的压缩
HCA 的压缩比 CSA 高得多。V4-Pro 中，HCA 的压缩因子 m' = 128，即每 128 个连续 token 压缩成一个条目。
1M tokens → ~7800 个 HCA 压缩条目。
7800 个条目是什么概念？比 CSA 的 250K 压缩条目少了 两个数量级。对 7800 个条目做密集型注意力（dense attention），计算量是完全可以接受的——这相当于一个常规 8K 上下文模型的全量注意力。
HCA 的压缩方式和 CSA 不同。CSA 的压缩目标是"保留可区分性"——相邻 4 个 token 压缩后，压缩条目之间的差异要足够大，方便后续的稀疏选择。HCA 没有这个要求——它不需要区分压缩条目的优先级（因为没有稀疏选择这一步），只需要压缩条目忠实地概括块内的内容。
因此 HCA 的压缩函数可以更激进。不是简单的加权平均，而是类似注意力池化（attention pooling） 的方式：用块内 token 自己算出一个注意力权重，然后加权平均得到压缩表示。这种方式比 CSA 的线性变换更复杂，但压缩比提高后的信息保留也更好。
5.1.1 HCA 压缩比的选择
HCA 的 m'=128 同样经过精心设计：
| 压缩因子 m' | 压缩后条目数（1M 序列） | 全量注意力 FLOPs | 覆盖粒度 |
|---|---|---|---|
| 32 | 31,250 | O(3.1e4^2) ≈ 9.8e8 | 约一个段落 |
| 64 | 15,625 | O(1.6e4^2) ≈ 2.4e8 | 约一个小节 |
| 128（V4-Pro 值） | ~7,813 | O(7.8e3^2) ≈ 6.1e7 | 约一个章节 |
| 256 | 3,906 | O(3.9e3^2) ≈ 1.5e7 | 约多个章节 |
m'=128 时，注意力的 FLOPs 约 6 千万次操作，大约是 8K 上下文模型的标准注意力水平。如果 m'=32，计算量上升到 O(3.1e4^2)，虽然仍然可以接受，但 HCA 层的计算不再是"几乎免费"的。
覆盖粒度方面，m'=128 大约覆盖一个"章节"级别的内容（假设一个章节 1000 词 ≈ 1300 token）。128 个 token 大致是一段中等长度的段落或一小节——在文档的宏观视角中，这是合适的粒度。比这更细（32 token）会丢失"全局"意义，比这更粗（256 token）则可能把多个独立主题混在一起。
5.1.2 位置信息的处理
HCA 128:1 的压缩会严重丢失 token 的精确位置信息。压缩后的条目只知道"我来自第 3 个压缩块"，但不知道块内的 128 个 token 谁先谁后。
V4 的解决方案是给 HCA 的 KV 加上位置编码——不是 token 级别的 RoPE 位置编码，而是块级别的位置编码。每个 HCA 压缩条目携带一个块位置标记（"我是第 5 个块"），这样 HCA 在做密集型注意力时，至少能知道不同块在序列中的全局顺序。
但块内 token 的精确位置信息确实丢失了。这就是为什么 HCA 不能完全替代 CSA 的原因——对于需要精确位置的任务（代码中的行号、法律条款的引用），HCA 的粒度不够。这些任务需要 CSA 的细粒度选择或者 SWA 的局部精度。
HCA vs CSA 压缩对比
CSA: 每 4 个原始 token → 1 个压缩条目 → 250K 条目 / 1M 序列
HCA: 每 128 个原始 token → 1 个压缩条目 → ~7,800 条目 / 1M 序列
HCA 条目数仅是 CSA 的 ~3%5.2 Dense over Blocks——在被压缩的序列上做全量注意力
HCA 的策略和 CSA 完全不同。CSA 是先压缩再稀疏选择，HCA 是先重度压缩，然后做密集型注意力。
HCA 工作流程
原始 token 序列（1M tokens）:
[T1, T2, ..., T128] [T129, T130, ..., T256] ...
↓ 压缩 ↓ 压缩
重度压缩 KV:
[H1] [H2] ... (约 7800 个)
密集型注意力:
query 对 [H1, H2, ..., H7800] 全量计算注意力
每个 query 看到所有压缩条目
没有稀疏选择，没有信息遗漏HCA 不做 top-k 筛选。它的"节省"全部来自压缩——7800 个条目对全量注意力的复杂度 O(7800^2) ≈ 6 千万次操作，对于 GPU 来说几乎是免费的计算。
HCA 的代价是精度。128:1 的压缩比意味着大量细节被丢弃。每个块内的 128 个 token 混合成一个向量，块内 token 的精确位置信息、语义差异都被平均掉了。
但 HCA 的目的本来就不是精度——是广度和覆盖。
5.3 全局上下文的撷取机制
HCA 的角色在 V4 的混合注意力中非常明确：提供一个粗粒度但覆盖全局的上下文视图。
它不是用来看细节的。详细的信息由 CSA 和 SWA 负责。HCA 看的是"全局概要"——文档的大致主题分布、内容的前后流转关系、以及哪些区域总体上和当前查询有关。
这种设计呼应了一个认知科学中的观察：人类处理长文本时也不是每个词都精读。我们会扫读获取大意，然后在关键段落精读。HCA 就是那个"扫读"的机制。
HCA 的压缩方式也不是简单的池化。它使用一个可学习的变换函数，将 128 个 token 的 key/value 投影到压缩表示中。这个投影参数在训练中和模型一起学习，意味着模型自己学会了什么信息适合压缩进全局视图、什么信息需要留给局部处理。
5.4 注意力下沉（Attention Sinks）的处理
实际操作中，HCA 面对 7800 个压缩条目时还会遇到一个问题：注意力下沉（Attention Sinks）。
标准注意力中，softmax 要求每个 query 对所有 key 的注意力分数之和为 1。当一个 query 跟前的大部分压缩块都关系不大时（比如处理文档末尾的 token 时），模型会把大量注意力分数分配给开头的少数几个 token，即使这些 token 的实际语义贡献有限。
V4 的方案是为 CSA 和 HCA 引入可学习下沉 logits（learnable sink logits）。简单说，在 softmax 前额外加入一个恒为负值的小 logit，允许 attention 层的总注意力质量小于 1。不是每个 query 都必须在上下文中找到某个 token 来分配注意力——当上下文不相关时，模型可以"放弃"一部分注意力。
这个小技巧在长上下文场景中非常有用。它让模型不必假装"每个 token 都和其他 token 有关"——很多 token 之间确实没什么关系，强行分配注意力只会引入噪声。
六、混合策略
CSA、HCA、SWA——三个分支各有分工。V4 的设计巧妙之处在于如何把它们组织成一个整体。
6.1 层间交错排列
V4 不在同一层内同时使用三种注意力（那样太复杂），而是按层交错排列。
CSA 和 HCA 在层间交替使用，具体分布比例不是 50:50。根据推测和技术文档的分析，V4-Pro 的 61 层中，HCA 层占比约 40-50%，CSA 层占比约 50-60%，加上固定的一层全量注意力和所有层都具备的 SWA 补丁。
6.1.1 为什么不是同一层内混合？
一个自然的疑问是：为什么不在一层内同时做 CSA 和 HCA？比如让每个注意力头一部分做稀疏选择、一部分做全局覆盖。
V4 没有这么做的原因：
计算效率——同一层内混合意味着每层都要同时维护两套 KV Cache（CSA 的细粒度压缩 KV + HCA 的重度压缩 KV）。这会增加 KV Cache 的管理复杂度，而且两套 KV 的生成路径不同，无法复用。
训练稳定性——如果一层内同时做两种注意力，梯度信号会在层内混合，难以区分"压缩精度不足"还是"稀疏选择不准确"导致的 loss。层间隔离让每个层的职责更加明确，调试和调参更容易。
硬件利用——一层内切换 CSA 和 HCA 的计算模式会破坏 kernel 的连续性。现代 GPU kernel launch 有固定开销，频繁切换注意力模式会导致 GPU 利用率下降。层间交替允许每层用一个高度优化的 kernel 完成一个注意力类型。
6.1.2 层排列的具体逻辑
V4 的层排列不是随机的，遵循三个设计原则：
V4 混合注意力层的排列模式（简化）
前 1/3 层（~20 层）:
HCA → HCA → CSA → HCA → HCA → CSA → ...
↑ 早期层以 HCA 为主，快速建立全局上下文
中间 1/3 层（~20 层）:
CSA → HCA → CSA → HCA → CSA → HCA → ...
↑ 交替排列，均衡的全局/局部视角
后 1/3 层（~20 层）:
CSA → CSA → CSA → CSA → CSA → ... → Full Attn
↑ 以 CSA 为主，最后一层全量注意力兜底在 V4-Pro 的 61 层中：
- 前 1/3（约 1-20 层）：以 HCA 为主，HCA 层约占 60-70%。这一阶段的表示尚浅，先建立全局视图比精确定位更合算。
- 中间 1/3（约 21-40 层）：HCA 和 CSA 均衡分布（约 50:50）。模型同时从全局和局部两个视角处理信息。
- 后 1/3（约 41-60 层）：以 CSA 为主，CSA 层约占 60-70%。表示逐步成型，需要的更多是精确的检索和定位，而非粗粒度的全局概览。
- 第 61 层：全量未压缩注意力。输出前的最后一层，也是信息精度最高的一层。
这个排布的意义：
- 早期层使用 HCA：底层的表示比较粗糙，适合先建立全局视野。HCA 在全量压缩条目上的密集型注意力，给模型提供了一个"文档地图"。
- 中间层交替使用 HCA 和 CSA：模型在深度上同时从全局概览和局部细节两个角度理解输入。HCA 告诉它"文档的主题是什么"，CSA 告诉它"具体的证据在哪"。
- 最后一层使用全量注意力：这一层没有压缩、没有稀疏选择。输出层不需要节省，它需要最高精度。
这个设计很聪明。大部分压缩发生在中间层，而模型生成最终输出时，有一个清晰、未压缩的视图可用。计算被集中在了最需要的地方。
6.2 训练的挑战：如何让混合注意力学会分工
混合注意力不是设计完就能用，它面临着几个训练层面的挑战。
挑战一：梯度不平衡。 HCA 的压缩程度高（128:1），在反向传播时，通过 HCA 传递的梯度信号比通过 CSA 的要"粗"很多。如果不做处理，模型会倾向于过度依赖 HCA（因为它的计算成本低）或过度依赖 CSA（因为它的信号更精确）。V4 的训练策略是给不同注意力的 loss 贡献加不同的权重，让两条分支的梯度量级保持平衡。
挑战二：从全量注意力到混合的平稳过渡。 V4 的训练不是从一开始就使用混合注意力的。序列长度是逐步增加的——4K → 16K（密集注意力）→ 64K（开启稀疏注意力路径）→ 逐步扩展到完整 1M。这个"课程学习"（curriculum learning）策略让模型先学会基本的注意力模式，再逐步适应压缩和稀疏化。
挑战三：Indexer 的冷启动问题。 Lightning Indexer 需要预测哪些压缩块和当前 query 相关——但在训练初期，Indexer 的权重是随机的，做出的 top-k 选择基本也是随机的。随机选择意味着核心注意力训练到的"相关片段"可能完全不相关，模型学不到东西。
V4 的解决方案是给 Indexer 一个"预热阶段"：在前几个训练步中，Indexer 的 top-k 选择被退化为随机采样（或使用全量注意力计算来校准 Indexer 的分数），等 Indexer 的权重有了一定量的更新后再切换到真正的 top-k 选择。
这些训练细节说明：混合注意力不仅在推理时复杂，在训练时也不简单。每层两个注意力的协调、梯度平衡、Indexer 的协同训练——这些都是"看不见"的工程工作，但正是它们让 1M 上下文从论文变成了产品。
6.3 CSA 处理局部——不遗漏
CSA 的角色是"信息检索"。给定当前 query，它需要从压缩的 KV 池中找到最相关的那些块。
CSA 擅长的事情：
- 精细匹配：需要在文档中找到特定事实或引文时，CSA 的 top-k 选择机制能精确定位
- 多跳推理：当推理路径涉及多个远距离 token 时，CSA 的稀疏注意力能用足够多的 top-k（1024）块覆盖
- 代码补全：代码的上下文依赖通常是局部的（变量定义在附近），CSA + SWA 的局部精度非常适合
CSA 不擅长的事情：
- 理解宏观主题分布
- 捕捉文档的整体叙事结构
- 跨大段的抽象推理（需要综合多个不相关段落才能得出结论的任务）
这些就是 HCA 的领域。
6.4 HCA 汇总全局——不钻牛角尖
HCA 的角色是"文档摘要"。它不看细节，看的是主题、趋势、宏观结构。
HCA 擅长的事情：
- 文档级理解：给出一篇论文的摘要或一本书的概要
- 跨段模式识别：发现文档不同部分的相似论点
- 全局问答："这篇文章的核心论点是什么？"——不需要定位到具体位置，HCA 的全局视图足够了
HCA 不擅长的事情：
- 精确引用："第三页第二段的具体数据是多少？"——HCA 的 128:1 压缩丢掉了定位精度
- 代码中变量的精确定义——需要逐 token 的精确信息
6.5 策略选择的平衡
6.5.1 适用场景矩阵
HCA 和 CSA 的分工不是僵化的。模型通过训练学会了在什么场景下更依赖哪条路径。
训练过程中，每层的注意力模式不是预设的。虽然层的类型（HCA/CSA）是固定的，但每个分支内部的具体行为（HCA 在哪些压缩块上分配更多权重、CSA 的 top-k 选中哪些块）是由数据驱动的。
这带来一个重要的性质：混合注意力不是模型的人为约束，而是模型的一种能力选择。
当任务需要精确引用时，模型可以更多地依赖 CSA 和 SWA 的输出，HCA 的贡献变小。当任务需要全局理解时，模型可以更多地依赖 HCA。不需要人为切换模式——模型自己学会了。
从工程角度看，这个混合策略解决了一个核心矛盾：长上下文模型必须在效率和精度之间做 trade-off，但"什么时候要效率、什么时候要精度"不应该由人来决定，应该交给模型自己判断。
三个分支 + 全量注意力兜底 + 最后一层全量注意力，这套设计给了模型足够的"选择权"。
七、效率数据深度解读
讲完了原理，回到最硬的数据：这套混合注意力到底省了多少？
7.1 Pro 版本：27% FLOPs + 10% KV Cache
| 指标 | DeepSeek V3.2 | DeepSeek V4-Pro | 节省比例 |
|---|---|---|---|
| 单 token 推理 FLOPs（1M 上下文，等效 FP8） | 100%（基线） | 27% | 减少 73% |
| KV Cache 大小 | 100%（基线） | 10% | 减少 90% |
| 上下文窗口 | 128K | 1M | 扩展 8 倍 |
FLOPs 减少 73% 来自三部分：
CSA 的压缩（m=4）+ 稀疏选择（top-k=1024）：核心注意力计算从 O(1M×1M) 降到 O(1M×1024)，减少了约 1000 倍。但实际节省没有 1000 倍，因为 Indexer 本身也有开销，而且不是所有层都用 CSA。综合下来 FLOPs 比 V3.2 净减一大块。
HCA 的重度压缩（m'=128）：把 1M token 的注意力降为 O(7800^2) ≈ O(6e7)——对一个 transformer 层来说几乎不消耗计算。HCA 层的 FLOPs 可以忽略不计。
层级别的稀疏性：61 层中，只有最后一层使用全量注意力，其余层都是 CSA 或 HCA。全量注意力只在最需要的地方出现一次。
KV Cache 从 100% 降到 10%，主要得益于压缩。CSA 的 KV 是压缩后的（1/4 大小），HCA 的 KV 是重度压缩的（1/128）。即使加上 Indexer 本身的 KV 和 SWA 的滑动窗口 KV，总存储也只有 V3.2 的十分之一。
7.2 Flash 版本：10% FLOPs + 7% KV Cache
V4-Flash 的压缩更加激进。
| 指标 | DeepSeek V3.2 | DeepSeek V4-Flash | 节省比例 |
|---|---|---|---|
| 单 token 推理 FLOPs | 100%（基线） | 10% | 减少 90% |
| KV Cache 大小 | 100%（基线） | 7% | 减少 93% |
Flash 的激活参数只有 13B，模型更小，注意力头更少。这使得：
- 压缩因子可以更大（同样质量约束下，小模型的重度压缩对精度的影响更小）
- 稀疏选择的 top-k 可以更少
- Indexer 的开销占比更小
这解释了为什么 Flash 的 FLOPs 能降到 10%。Flash 版本面向的是成本敏感的场景——0.14 美元 / 1M token 输入的价格，很大程度上是靠这套注意力省出来的。
7.3 KV Cache 的异构成分
V4 的 KV Cache 和传统模型不同——它不是单一类型的 KV，而是异构的。
| Cache 类型 | 存储内容 | 特点 |
|---|---|---|
| Classical KV Cache | CSA/HCA 的压缩 KV | 长生命周期，压缩后稳定易对齐，适合紧凑存储 |
| State Cache | SWA 窗口 KV + 尾部未压缩 token | 短生命周期，大小有上限，按请求预分配 |
Classical KV Cache 存的是压缩后的长程 KV。这些 KV 一旦生成，在整个推理过程中基本不变（除非有 cache 更新），适合存入专门的缓存区并按需检索。
State Cache 存的是"临时的"KV——滑动窗口内的原始 token、尚未达到压缩边界的尾部 token。这些 KV 生命周期短（窗口滑动后就淘汰），大小有上限（窗口大小 + 压缩粒度），按 request 预分配即可。
两种 cache 的管理策略参照了计算机体系结构中的层次化存储：冷热分离。长生命周期的压缩 KV 用稳定存储，短生命周期的窗口 KV 用快速临时存储。虽然都在显存上，但管理的逻辑不同。
7.4 和标准注意力在同一位置对比
为了让你对"省了多少"有个直观感受，这里把 V4 的混合注意力和标准完全注意力做一个对比：
标准注意力 @ 1M 上下文
Q @ K^T 矩阵大小: 1M × 1M = 1T 元素
KV Cache 大小 (61层): ~31 GB
单 token 推理 FLOPs: ~4e15
V4-Pro 混合注意力 @ 1M 上下文
CSA: 1M → 250K 压缩块 → 选 1024 → 作用于 ~1024 条目
HCA: 1M → 7,800 压缩块 → 全部使用
KV Cache 大小 (61层): ~3.1 GB
单 token 推理 FLOPs: ~1.1e15
差距: 3-4 个数量级的计算量缩减，10 倍的 KV Cache 节省这还没有算 Indexer 本身的开销。但 Indexer 运行在 FP4 低精度上，且是轻量低秩网络，其开销和核心注意力计算相比可以忽略。
7.5 不同序列长度下的效率曲线
混合注意力的效率优势不是均匀的。在不同序列长度下，节省比例差异很大：
| 上下文长度 | 标准注意力 FLOPs | V4-Pro 混合注意力 FLOPs | 节省比例 |
|---|---|---|---|
| 4K | O(1.6e7) | O(4e6) | ~75% |
| 32K | O(1e9) | O(8e7) | ~92% |
| 128K | O(1.6e10) | O(2e8) | ~98.7% |
| 1M | O(1e12) | O(2.7e11) | ~73% |
关键数据点：在 128K 上下文中，V4 的节省比例最高（98.7%）。 这是因为 CSA 的压缩 + 稀疏选择在这个长度下表现得最好——压缩后的条目数量（128K/4=32K）刚好是 Indexer 可以处理的规模，top-k=1024 的选择覆盖率足够高。
到了 1M 上下文，节省比例反而下降了（73%）。原因有二：
Indexer 的开销随序列长度线性增长。对 1M 序列打分的计算量虽然低秩，但仍然存在。当序列长度增长 8 倍，Indexer 的计算量也增长 8 倍，在全量注意力上省下来的部分被 Indexer 开销吃掉了一些。
最后一层全量注意力的占比上升。第 61 层的全量注意力是 O(1M^2) 的计算量，这个量级在短序列下可以忽略，但在 1M 下不可忽视。它的存在拉低了整体的节省比例。
但即使如此，73%（Pro）和 90%（Flash）的 FLOPs 节省，以及 90-93% 的 KV Cache 减少，仍然让 V4 成为目前长上下文效率最高的模型之一。
7.6 效率提升的实际意义：不只是省钱
FLOPs 减少 73% 和 KV Cache 减少 90% 不只是"省钱"这么简单，它们在工程上有三个直接影响：
更低的延迟。 KV Cache 减少 90% 意味着每次 decode 时从 HBM 搬运的数据量减少了 90%。对长序列来说，IO 延迟是主要瓶颈（计算只占总时间的 20-30%）。KV Cache 的缩减直接转化为更低的延迟。
更大的 batch size。 同样的显存预算下，V4 可以同时处理更多的并发请求。KV Cache 减少 90% 意味着显存中能容纳的并发请求数可以增加 5-10 倍——对 API 服务的吞吐量是质变。
更低的硬件门槛。 1M 上下文的推理不再需要多卡 H100 集群。V4-Flash 的 KV Cache 只有 V3.2 的 7%，意味着单张 H100 甚至单张消费级显卡（如 RTX 4090）可以运行百万上下文。这让长上下文从"只在云端可用"变成了"本地也能跑"。
这三个变化合在一起的效果是：长上下文从一个"特殊能力"变成了"默认能力"。
八、与竞品长上下文方案对比
8.1 行业竞品的长上下文方案
| 特性 | DeepSeek V4 | Gemini 2.5 Pro | Claude Opus 4.7 | GPT-5 |
|---|---|---|---|---|
| 最大上下文 | 1M | 2M（实验性） | 1M | 256K（Pro 版） |
| 核心方案 | CSA + HCA 混合 | MoE + 分片注意力 | 稀疏注意力 + SOTA 推理 | 分段注意力 + 压缩 |
| 1M 输入 FLOPs 减少 | 73-90% | 未公开 | 未公开 | 未公开 |
| KV Cache 减少 | 90-93% | 未公开 | 未公开 | 未公开 |
| 开源 | 是（MIT） | 否 | 否 | 否 |
| 长上下文成本（$/1M 输入） | 0.14-1.74 | 约 2-3 | 约 3-5 | 约 2-4 |
Gemini 2.5 Pro 在上下文长度上最激进（实验性 2M），但采用的是类似分片注意力的方案——把长序列切成片段，片段内全量注意力，片段间用压缩表示传递信息。这个方案的问题是：片段边界的信息可能被截断丢失。
Claude Opus 4.7 更注重推理质量而非上下文长度。它在 1M 上下文中做了充分的稀疏注意力优化，但具体的技术细节未公开。Claude 在长上下文检索（Needle-in-a-Haystack）上的表现确实优秀，但成本也最高。
GPT-5 的上下文限制在 256K（Pro 版本），采用了分段注意力加压缩的方案。OpenAI 的策略似乎是不追求极端的上下文长度，而是在 256K 内追求最优的性价比。
8.1.1 Benchmark 横评：长上下文检索
在长上下文的实际能力上，最常用的评测基准是 Needle-in-a-Haystack 类任务——在一段超长文本中放置一个特定信息，看模型能否准确找到。
DeepSeek V4 在 MRCR 1M 基准（百万级上下文检索）上达到了 90.2% 的准确率，超过了 Gemini 3.1 Pro。考虑到 V4 在检索过程中使用了压缩注意力（而不是全量注意力），这个成绩很有说服力——说明 CSA 的 Lightning Indexer + HCA 的全局覆盖没有因压缩而丢失"找针"的能力。
| 模型 | MRCR 1M 准确率 | 上下文长度 | 注意力类型 |
|---|---|---|---|
| DeepSeek V4-Pro | 90.2% | 1M | CSA + HCA |
| Gemini 3.1 Pro | 约 88% | 2M | 分片注意力 |
| Claude Opus 4.7 | 约 91% | 1M | 稀疏注意力（未公开） |
| GPT-5 | 未公开 1M 数据 | 256K | 分段注意力 |
Claude Opus 4.7 在检索任务上仍然略胜一筹，但价格差距巨大（3-5 美元 vs 0.14 美元每 1M 输入）。DeepSeek V4 的定位很清楚：不追求在所有指标上做第一，而是追求在"足够好"的前提下做到最便宜。
8.2 V4 的独特优势
DeepSeek V4 和这些竞品最大的区别不在于"上下文有多长"，而在于三个维度的综合表现：
第一，开源 + 低成本。 这是颠覆性的。V4-Flash 的 0.14 美元 / 1M token 输入意味着长上下文从"企业级成本"降到了"几乎免费"。Claude Opus 的 1M 上下文调用费用可能是 V4-Flash 的 20-50 倍。当一个模型在任何规模的任务中都更便宜时，它不一定要在所有 benchmark 上追平对手才有意义。
第二，精度和效率的非对称优势。 V4 在长上下文检索基准（MRCR 1M）上达到了 90.2%，甚至超过了 Gemini 3.1 Pro。这意味着 V4 的压缩注意力在"找针"这件事上做得足够好——没有因为压缩而丢失关键信息。
第三，完整的工程体系。 混合注意力只是 V4 技术栈中的一环。它和 MoE 稀疏激活、mHC 超连接、Muon 优化器一起构成了一个完整的系统。特别是 MoE 的 1.6T/49B 参数结构和混合注意力的叠加，让长上下文的高效推理成了可能——如果模型本身是 dense 的（所有参数都要激活），注意力的节省会被 MoE 的缺失所抵消。
8.3 为什么 Open AI 和 Google 没有这么做
一个合理的疑问是：如果 CSA+HCA 这么有效，为什么 GPT-5 和 Gemini 没有采用类似的方案？
第一研发路径不同。 Open AI 和 Google 的强项是 post-training（对齐、指令微调）和生态（插件、工具调用、多模态融合）。它们的长上下文优化更侧重"如何让模型在长上下文中不遗漏信息"，而不是"如何降低成本"。方向不同。
第二，闭源的优化压力不同。 闭源模型可以通过定价策略来管理成本——如果长上下文太贵，不降价就好了。开源模型需要考虑社区部署的硬件限制，成本优化是刚性需求。
第三，架构惯性。 GPT 系列从 2023 年就开始用分段注意力 + 局部窗口的方案，这套 pipeline 经过了多次迭代验证，迁移到全新的混合注意力架构需要巨大的工程投入。
但 V4 的开源意味着，如果这套方案被社区验证有效，其他模型会迅速跟进。这也是为什么有观点认为"序列维度压缩将成为下一代长上下文模型的标准配置"。
九、对开发者意味着什么
技术实现是一回事。对开发者来说，"能做什么"才是关键。
9.1 长上下文带来的实际体验提升
V4 的混合注意力不是在实验室里秀肌肉的东西——它实实在在地提升了使用体验。
第一次把整个代码库塞进提示词。 以前处理一个中型项目（~500K token），开发者需要做 RAG、分块、摘要——每一层都在增加系统复杂度。V4 的 1M 上下文可以一次性放入一个完整的代码库，模型可以直接理解项目的上下文、模块间的关系、以及编码风格的一致性。
Agent 的多轮记忆不再依赖外部存储。 Agent 在和用户的多轮对话中，之前的交互历史如果超过模型窗口就会被截断。1M 上下文意味着一个 Agent 可以运行数十轮甚至上百轮，而不会忘记对话开头的内容。这对复杂的 Agent 工作流（比如代码修改 + 测试 + 部署的多轮迭代）是质变。
长文档的原生处理。 一本书、一份几百页的法律合同、一套完整的 API 文档——不需要分片、不需要 RAG、不需要预处理。直接丢进去，模型就能直接回答问题和定位信息。
9.2 企业级应用场景
| 场景 | V4 之前的方案 | V4 之后 | 关键差异 |
|---|---|---|---|
| 代码仓库 Agent | 需要 RAG 分块 + 摘要索引 | 直接塞入 1M token 上下文 | 降低系统复杂度 50%+ |
| 文档问答 | 需要分块 + 向量检索 + 排序 | 长文档直接输入 | 省掉整个检索架构 |
| 多轮 Agent | 外挂记忆模块 + 压缩 history | 原生长上下文记忆 | 简化 Agent 链路 |
| 合规审查 | 文档分篇处理 + 人工拼接 | 一次处理整份合同 | 提升审查一致性 |
| 知识库咨询 | RAG 管线 + Embedding 模型 | 直接输入整篇知识库（中小型） | 1 个 API 替代 1 套系统 |
对企业的实际意义是：省去了大量长上下文中介基础设施。 以前做一个知识库问答系统，需要向量数据库、分块策略、检索排序、reranker——一个典型的 RAG 系统至少要 4-5 个组件。在 1M 原生上下文加持下，对于文档量在合理范围内的场景，一个模型 + 一次 API 调用 = 完整的问答体验。
当然不是说 RAG 不需要了。对于海量文档（百亿级 token），RAG 仍然是必需的。但 1M 上下文让"不需要 RAG"的场景从无到有，从"不可能"变成了"在大多数情况下够用"。
9.3 成本敏感场景的选型建议
V4 的两个版本对应不同的开发者需求：
V4-Flash（0.14 美元 / 1M 输入）：长上下文的首选。如果你需要频繁处理 100K-1M 的输入，Flash 的成本几乎和 V3.2 处理 128K 相当。日常开发中的代码仓库分析、文档问答、多轮 Agent，用 Flash 就够了。
V4-Pro（1.74 美元 / 1M 输入）：当质量优先时选用。复杂的推理任务、需要最大限度减少信息丢失的场景、或者前一层的 CSA/HCA 选择不够精确时，Pro 的更大模型容量和更低压缩比会更有优势。
一个实用的策略是：用 Flash 做粗筛或日常任务，用 Pro 做深度分析或敏感任务。 两者的 API 接口完全兼容，切换只需要改 model 名称。
开源（MIT 协议）意味着你也可以自己部署。V4-Flash 的 284B 总参 / 13B 激活，加上压缩后的 KV Cache（只需 V3.2 的 7%），可以用相对经济的硬件运行 1M 上下文。具体用什么硬件、怎么做量化，在指南的《本地部署方案》一文中详细讨论。
9.4 我是否还需要 RAG？
1M 上下文出现后，开发者问得最多的问题就是：RAG（检索增强生成）是不是不需要了？
答案分情况：
不需要 RAG 的场景：
- 单份文档在 1M token（约 75 万字）以内
- 需要模型在整份文件中进行跨段落推理（合同对比、代码审查）
- Agent 的多轮交互记忆中不需要外部知识库
仍然需要 RAG 的场景：
- 文档量超过 1M token（如企业知识库、技术文档大全）
- 需要精确的版本控制或权限管理（RAG 可以细粒度控制"哪些人看到哪些文档"）
- 高频更新的知识库（RAG 的检索索引可以低成本更新，而模型需要重新训练或微调才能更新知识）
- 成本敏感场景：即使 V4-Flash 已经很便宜，但如果你只需要在 100 万本书中检索 1 本书的某一页，RAG 仍然比一次性输入便宜得多
所以正确的问题不是"RAG 被淘汰了吗"，而是**"我的场景需不需要 RAG"。** 1M 上下文让 RAG 不再是长文档处理的唯一方案——但它和 RAG 是互补关系，不是替代关系。
一个实用的混合策略：用 RAG 做一级筛选（从海量文档中捞出 top-k 个片段），用 V4 的 1M 上下文做二级精读（对选中的长文档做一次性处理）。组合拳的效果通常比单纯用 RAG 或单纯用长上下文都好。
9.5 代码实操：如何利用好 1M 上下文
最后给几个具体的编码建议——当你真的开始用 V4 处理长上下文时，这些细节会影响实际体验。
1. 注意 prompt 的首段质量。 V4 和很多长上下文模型一样，对 prompt 开头部分有"注意力偏置"——开头的 token 被分配的注意力权重略高。重要指令放在 prompt 的前面，而非末尾。
2. 文档分隔清晰。 如果一次输入多份文档，用明确的 Markdown 分隔符（如 --- 或 # 标题）标记文档边界。CSA 的 Indexer 对语义边界敏感——清晰的文档分界有助于 top-k 选择命中正确的文档。
3. 充分利用 Thinking 模式。 V4 支持 Non-think、Think High、Think Max 三种推理模式。在长上下文任务中，Think High 模式通常会比 Non-think 模式在"找针"和"跨段落推理"上有明显提升。如果对结果质量有要求，打开 Thinking。
4. 注意上下文长度和成本的线性关系。 V4 的定价是 per token——上下文越长，输入成本越高。虽然 1M 上下文很便宜（Flash 仅 0.14 美元），但如果你只在 100K 序列上做简单问答，没必要真的填满 1M。按需控制输入长度，和按需分配注意力一样重要。
小结
V4 的混合注意力机制解决了大模型长上下文的核心矛盾：注意力就是理解，但注意力太贵了。
它的解法不是单一方案，而是三个分支各司其职：
- CSA（压缩稀疏注意力）：把 4 个 token 压缩成一个，然后 Lightweight Indexer 从 25 万个压缩块中选出 1024 个最相关的精密计算。局部精度靠 SWA 补充。
- HCA（重度压缩注意力）：把 128 个 token 压缩成一个，在约 7800 个压缩块上做全量注意力。牺牲精度，换取全局覆盖。
- SWA（滑动窗口注意力）：保留最近窗口的原始 KV，让压缩注意力不丢失局部细节。
- 最后一层全量注意力作为输出兜底，保证最终生成时的最大精度。
结果是冰冷但令人信服的数据：
在 1M token 输入下，V4-Pro 推理 FLOPs 降至 V3.2 的 27%，KV Cache 降至 10%。V4-Flash 更激进：FLOPs 10%、KV Cache 7%。
这套设计让 1M 上下文从一个"炫耀性质的规格参数"变成了一个"日常可用的工作负载"。开发者可以一次输入整本书、整个代码仓库、整个产品文档——不需要分片、不需要 RAG、不需要中间件。
而且它是开源的。MIT 协议意味着 CSA+HCA 的技术方案可以被社区检验、复用和改进。如果"序列维度压缩"真的是下一代长上下文模型的标准方案，V4 的混合注意力可能就是那个起点。
在下一篇《mHC 超连接与 Muon 优化器》中，我们会转向另一个同等关键的问题：如何让万亿参数模型的训练不崩溃。
检验标准
- [ ] 能用自然语言解释为什么标准注意力在 1M 上下文下不可行（O(n^2) 复杂度 + KV Cache 爆炸）
- [ ] 能区分 CSA 和 HCA 的核心差异：CSA = 压缩 + 稀疏选择，HCA = 重度压缩 + 密集注意力
- [ ] 能举出至少一个 CSA + SWA 互补的工程案例（远距离压缩 + 局部精度保留）
- [ ] 能口述 V4 混合注意力的层排列策略（早期 HCA / 中间交替 / 最终层全量注意力）