摘要

长上下文模型真正困难的，从来不只是计算量。

当上下文扩展到几十万甚至上百万 Token 后，每生成一个新 Token，模型都要读取大量历史 Key 和 Value。此时限制模型推理速度的，往往不再是 GPU 的计算能力，而是 KV Cache 容量、显存带宽以及数据搬运成本。

DeepSeek V3 的 MLA 已经大幅压缩了单条 KV 的宽度，但面对百万 Token 上下文，另一个问题仍然存在：KV 的数量依旧随着序列长度线性增长。

DeepSeek V4 的 Hybrid Attention 继续向前走了一步。

它不再只考虑“每条 KV 能不能变小”，而是开始解决“能不能不为每个 Token 都长期保存一条 KV”。

为此，DeepSeek V4 引入了 CSA、HCA 和 Sliding Window，构建出一套分层记忆系统：

• 最近的信息保留原始精度；
• 中远距离的信息经过压缩后按需检索；
• 超长距离的信息被高度压缩成全局摘要。

本文不逐行复述技术报告，而是从架构设计的角度，讲清楚 CSA、HCA、Lightning Indexer、Sliding Window、MQA 和 Attention Sink 为什么要这样组合，以及这套设计真正值得学习的地方。

关键词

DeepSeek V4、Hybrid Attention、CSA、HCA、KV Cache、稀疏注意力、长上下文、大模型架构

---

一、百万 Token 的真正瓶颈，不只是计算量

提到长上下文，很多人首先想到的是标准 Attention 的复杂度。

标准 Attention 的计算复杂度通常写成：

O(n²)

其中，n 是序列长度。

序列越长，Attention Matrix 越大，计算量增长得越快。这当然是一个问题，但在自回归生成阶段，真正限制大模型推理速度的，往往还有另一个更现实的因素：KV Cache。

Transformer 在处理每个 Token 时，会产生对应的 Key 和 Value。

这些 Key、Value 不会在计算完成后立即丢弃，而是会被存入 KV Cache。之后每生成一个新 Token，模型都要读取历史 KV，与当前 Query 进行 Attention 计算。

假设上下文长度已经达到 100 万 Token。

那么每生成一个新 Token，模型都需要从显存中读取大量历史 KV。

此时真正昂贵的，很多时候不是“乘法做不动”，而是“数据搬不动”。

现代 GPU 的矩阵计算能力很强，但显存带宽并没有以相同速度增长。如果大量计算单元一直在等待 KV 从显存搬到芯片内部，再高的理论算力也发挥不出来。

所以，百万 Token 上下文至少带来了三个问题：

1. KV Cache 占用的显存越来越大；
2. 每生成一个 Token，需要读取的历史数据越来越多；
3. Attention 逐渐从计算密集型任务变成内存带宽受限任务。

DeepSeek V4 的 Hybrid Attention，本质上就是围绕这三个问题设计的。

---

二、从 MLA 到 Hybrid Attention：压缩目标发生了变化

DeepSeek V3 使用了 MLA，也就是 Multi-head Latent Attention。

MLA 的核心思路，是把每个 Token 对应的 Key 和 Value 压缩到一个低维潜在向量中。

可以把 KV Cache 的规模粗略理解成：

KV Cache 规模 = Token 数量 × 每条 KV 的宽度

其中：

• Token 数量对应序列长度，也就是 n；
• 每条 KV 的宽度对应单条记录占用的空间，也就是 d。

MLA 主要压缩的是第二部分。

原本的 KV Cache 可以表示为：

n × d

经过 MLA 压缩后，变成：

n × d_latent

每条 KV 变窄了，显存占用自然会下降。

但这里还有一个没有解决的问题：

KV 的数量仍然是 n。

上下文中有 100 万个 Token，仍然要保存 100 万条压缩后的 KV。即使每条 KV 已经很小，累计起来仍然十分庞大。

因此，DeepSeek V4 的优化方向继续向前走了一步：

不仅要让每条 KV 变小，还要让 KV 的数量变少。

这就是 CSA 和 HCA 出现的根本原因。

CSA 每 4 个 Token 合成一条压缩 KV：

n → n ÷ 4

HCA 每 128 个 Token 合成一条压缩 KV：

n → n ÷ 128

如果说 MLA 是在压缩每条记录的宽度，那么 CSA 和 HCA 就是在减少记录本身的数量。

这是理解 DeepSeek V4 Attention 架构最重要的入口。

---

三、Hybrid Attention 不是两个模块的拼接，而是一套三级记忆系统

只看 CSA 和 HCA 的名称，很容易把 Hybrid Attention 理解成“两种 Attention 混合使用”。

但从系统架构的角度看，它更像一套三级记忆系统。

1. Sliding Window：短期精确记忆

DeepSeek V4 会保留最近 128 个 Token 的原始 KV。

这部分信息不会经过高比例压缩，主要负责保存：

• 当前句子的语法关系；
• 最近出现的人名和实体；
• 精确数字；
• 代码变量和符号；
• 拼写与标点；
• 最近几个推理步骤。

这些信息距离当前 Token 很近，而且往往要求精确访问。

例如，在代码生成中，一个变量名可能只差一个字符；在数学推理中，一个数字可能决定最终结果。如果把这些近期信息过度压缩，模型很容易丢失局部细节。

因此，Sliding Window 可以理解成模型的短期精确记忆。

2. CSA：可检索的中长期记忆

CSA 的全称是 Compressed Sparse Attention，也就是压缩稀疏注意力。

它先把每 4 个 Token 压缩成一条 KV，然后通过 Lightning Indexer，从大量压缩 KV 中选择最相关的 top-k。

CSA 保存的信息比 HCA 更细，适合处理：

• 远处出现过的具体实体；
• 某段代码中的变量定义；
• 文档前面提出的精确条件；
• 跨段落的细粒度关系；
• 需要回头查找的具体内容。

它的工作方式很像模型内部自带的一套搜索系统。

历史信息不会全部进入正式 Attention，而是先经过一次廉价检索，再把最相关的候选交给主 Attention。

3. HCA：长期全局摘要

HCA 的全称是 Heavily Compressed Attention，也就是高度压缩注意力。

它每 128 个 Token 才生成一条压缩 KV。

如果上下文长度是 100 万 Token，那么压缩后只剩：

1000000 ÷ 128 ≈ 7813

也就是大约 7813 条压缩 KV。

这个数量已经小到可以直接执行 Dense Attention，不再需要先做 top-k 检索。

HCA 更适合保存：

• 文档整体在讨论什么；
• 前面某一章节的大致主题；
• 超长对话的全局状态；
• 很远位置的背景信息；
• 粗粒度语义线索。

所以，DeepSeek V4 并不是用同一种方式保存全部历史 Token。

它采用的是：

近期信息保存原文，中远期信息建立索引，远期信息形成摘要。

这比单纯扩大上下文窗口，更接近真正的记忆系统。

---

四、CSA 的第一层漏斗：自适应压缩，而不是简单平均

CSA 可以分成两个阶段：

1. 把多个 Token 压缩成一条 KV；
2. 从压缩 KV 中检索最相关的 top-k。

先看第一阶段。

最简单的压缩方式，是对每 4 个 Token 的表示直接取平均值。

但平均池化有一个明显问题：不同 Token 的信息价值并不相同。

例如下面这句话：

“模型在 2026 年将上下文长度扩展到 100 万 Token。”

其中，“2026”和“100 万 Token”显然比“在”“将”“到”更加重要。

如果简单平均，每个 Token 的权重完全相同，重要信息就会被大量普通词稀释。

CSA 的做法不是平均，而是让模型自己学习压缩权重。

压缩过程可以简化理解为：

压缩后的 KV = 多个原始 KV 按动态权重加权求和

也就是说，模型会自己判断：

• 哪个 Token 应该被重点保留；
• 哪个 Token 可以被弱化；
• 哪些语义维度更重要；
• 哪些位置具有特殊作用。

更进一步，CSA 的权重不只是“每个 Token 一个标量”。

不同 Token 可以在向量的不同维度上承担不同作用。

某个 Token 可能在实体语义维度上权重很高，在位置信息维度上权重较低；另一个 Token 可能主要负责保存数字或者句法关系。

因此，CSA 的压缩并不是简单丢弃信息，而是把多个 Token 重新编码到一个固定容量的表示中。

---

五、为什么 CSA 要使用“两路投影加跨块重叠”

只要进行分块压缩，就一定会遇到块边界问题。

假设每 4 个 Token 划分成一块：

Block 0：Token 0、1、2、3
Block 1：Token 4、5、6、7
Block 2：Token 8、9、10、11

Data format: RDF-TurtleJSON-LDJSONCSVRDF/XMLMarkdownRSSAtom

Data format: RDF-TurtleJSON-LDJSONCSVRDF/XMLMarkdownRSSAtom

Token 3 和 Token 4 在原始序列中紧挨着，但经过分块以后，它们被放进了两个完全独立的压缩块。

如果 Token 3 和 Token 4 恰好组成一个完整实体、短语或者代码表达式，压缩块边界就可能破坏它们之间的联系。

DeepSeek V4 的处理方式不是让每个压缩块只读取当前 4 个 Token，而是引入两路表示，并让相邻压缩块共享部分原始信息。

可以把它简化理解为：

• 当前块的 Token 通过 A 路投影，作为本块的主体信息；
• 前一块的 Token 通过 B 路投影，作为跨块补充信息；
• 当前块和前一块的信息一起竞争压缩权重。

为什么要使用两套不同投影，而不是简单复制一份 KV？

因为同一个 Token 在两个位置上承担的角色并不相同。

作为当前块主体时，它需要表达自己的核心语义；作为下一块的历史边界时，它需要表达与后续内容的连接关系。

这种设计很像带重叠窗口的卷积，但它不是使用固定卷积核，而是让模型动态学习：

• 哪些信息应该留在当前块；
• 哪些信息应该跨块传递；
• 块边界两侧的 Token 应该如何重新组合。

这里体现了一个非常重要的架构思想：

压缩不可避免地会制造信息损失，优秀架构不会假装损失不存在，而是为损失设计补偿通道。

---

六、Lightning Indexer：模型内部的粗排系统

经过第一层压缩后，100 万 Token 会变成大约 25 万条压缩 KV。

数量虽然减少了 4 倍，但仍然非常大。

如果每个 Query 都和这 25 万条 KV 执行完整 Attention，再从结果中选择 top-k，那么前面的压缩基本失去了意义。

因此，CSA 又增加了一层 Lightning Indexer。

它的完整工作流程可以概括为：

大量压缩 KV
↓
低成本相关性打分
↓
选择 top-k 候选
↓
主 Attention 精确计算

Data format: RDF-TurtleJSON-LDJSONCSVRDF/XMLMarkdownRSSAtom

Data format: RDF-TurtleJSON-LDJSONCSVRDF/XMLMarkdownRSSAtom

这和搜索引擎中的“召回、粗排、精排”非常相似。

1. Indexer 不负责最终理解，只负责排序

Indexer 的任务非常单一：

找出哪些压缩块可能与当前 Query 相关。

它不负责完成真正的信息融合，也不需要输出绝对准确的相关度。

它只需要保证 top-k 的相对排序大体正确。

因此，Indexer 可以使用：

• 更少的 Head；
• 更小的 Head Dimension；
• 更低的计算精度；
• 更轻量的打分方式。

DeepSeek V4 的 Indexer QK 路径甚至可以使用 FP4。

FP4 的精度很低，但在这个任务中，Indexer 不需要精确判断某条信息的相关度究竟是 0.7318 还是 0.7321。

它只需要回答：

A 是否比 B 更值得进入 top-k？

这体现了一个非常成熟的工程原则：

模块需要多少精度，应该由它承担的任务决定，而不是所有模块统一追求最高精度。

2. 为什么 Indexer 和主 Attention 要共享 Query Latent

DeepSeek V4 会先把当前隐藏状态下投影成一个低维 Query Latent。

然后从同一个 Query Latent 分出两条路径：

Query Latent
├─ 生成 Indexer Query
└─ 生成主 Attention Query

Data format: RDF-TurtleJSON-LDJSONCSVRDF/XMLMarkdownRSSAtom

Data format: RDF-TurtleJSON-LDJSONCSVRDF/XMLMarkdownRSSAtom

这样设计首先可以减少重复计算。

但更重要的是，它让检索模块和主 Attention 建立在同一个查询语义空间中。

如果 Indexer 与主 Attention 使用完全不同的 Query 表示，可能出现一种问题：

• Indexer 认为某个压缩块非常相关；
• 主 Attention 拿到它以后，却认为这条信息没有价值。

共享 Query Latent，相当于让粗排和精排使用同一个查询语义基础。

这一点对 RAG 系统同样有启发。

很多 RAG 效果不好，并不一定是向量模型本身太弱，而可能是检索模型和生成模型对“相关性”的理解并不一致。

---

七、为什么 Indexer 要先对每个 Head 的得分执行 ReLU

Indexer 会从多个 Head 的角度，判断某个压缩块是否相关。

假设两个 Head 给出的分数分别是：

Head 1：8
Head 2：-7

Data format: RDF-TurtleJSON-LDJSONCSVRDF/XMLMarkdownRSSAtom

Data format: RDF-TurtleJSON-LDJSONCSVRDF/XMLMarkdownRSSAtom

如果直接相加，最终结果只有 1。

但这可能掩盖一个事实：

至少有一个 Head 认为这条信息非常重要。

对于检索系统来说，漏掉真正重要的信息，通常比多召回一些次要信息更加危险。

因此，DeepSeek V4 会先使用 ReLU 处理每个 Head 的分数。

ReLU 的规则非常简单：

ReLU(x) = max(0, x)

也就是：

• 正分保留；
• 负分归零。

经过 ReLU 后，上面的结果变成：

Head 1：8
Head 2：0
最终得分：8

Data format: RDF-TurtleJSON-LDJSONCSVRDF/XMLMarkdownRSSAtom

Data format: RDF-TurtleJSON-LDJSONCSVRDF/XMLMarkdownRSSAtom

这相当于一种比较宽松的 OR 投票：

只要某一个语义视角强烈认为它相关，就给它进入候选集合的机会。

从搜索系统的角度看，这是一种偏向召回率的设计。

Indexer 宁可多保留一些候选，也尽量不把真正关键的信息提前过滤掉。

---

八、HCA 最反直觉的地方：压缩足够狠以后，Dense 反而更便宜

很多人容易形成一种固定认知：

Sparse Attention 一定比 Dense Attention 更快。

但在真实 GPU 系统中，这并不一定成立。

稀疏计算本身也有额外成本：

• 需要执行 Indexer；
• 需要计算 top-k；
• 需要排序；
• 需要保存离散下标；
• 需要根据不连续地址读取 KV；
• GPU 对不规则内存访问的利用率通常更低。

如果数据已经被压缩到很少，再运行一整套稀疏检索流程，反而可能得不偿失。

HCA 每 128 个 Token 才生成一条压缩 KV。

100 万 Token 最终只剩大约 7813 条。

面对这个规模，直接做 Dense Attention，可能比下面这套流程更加高效：

Indexer
+ top-k 排序
+ 稀疏地址读取
+ Sparse Attention

Data format: RDF-TurtleJSON-LDJSONCSVRDF/XMLMarkdownRSSAtom

Data format: RDF-TurtleJSON-LDJSONCSVRDF/XMLMarkdownRSSAtom

所以，HCA 的设计哲学非常直接：

既然已经把数据压缩到足够小，就不要为了稀疏而稀疏，直接全部读取。

这说明判断一个算法是否高效，不能只看理论复杂度。

真实系统还必须考虑：

• GPU Kernel 是否规则；
• 内存访问是否连续；
• 排序成本；
• Cache 命中率；
• SIMD 和并行计算利用率。

理论上的稀疏，不一定等于硬件上的高效。

---

九、为什么 CSA 和 HCA 必须交错，而不是二选一

CSA 和 HCA 并不是竞争关系，而是互补关系。

1. 只使用 CSA 的问题

CSA 每 4 个 Token 压缩一次。

面对 100 万 Token，压缩后仍然有大约 25 万条 KV。

虽然主 Attention 最终只读取 top-k，但 Lightning Indexer 仍然需要扫描这 25 万条候选。

所以 CSA 的优势是细节保存得更好，但全局扫描成本仍然较高。

2. 只使用 HCA 的问题

HCA 每 128 个 Token 压缩成一个向量。

这种压缩一定是有损的。

模型可能丢失：

• 精确数字；
• Token 的具体顺序；
• 罕见字符；
• 代码符号；
• 局部句法结构；
• 跨块的细粒度关系。

HCA 很适合回答“前面大概讲了什么”，但不适合回答“前面具体写了哪个数字”。

3. 两者交错后的效果

DeepSeek V4 将 CSA 和 HCA 在不同层中交错放置。

可以把它理解成：

CSA 层：精确检索远处的具体信息
HCA 层：快速获得全局背景
CSA 层：再次查找细粒度证据
HCA 层：再次融合整体状态

Data format: RDF-TurtleJSON-LDJSONCSVRDF/XMLMarkdownRSSAtom

Data format: RDF-TurtleJSON-LDJSONCSVRDF/XMLMarkdownRSSAtom

一个 Token 穿过整个模型时，会不断经历两种信息处理：

• 细粒度检索；
• 粗粒度全局建模。

这和人类阅读长文档的方式很接近。

有时我们需要回头寻找某一句原话，有时只需要记住前面章节的大意。

Hybrid Attention 的真正价值，不是简单把两个 Attention 模块放在一起，而是让模型同时拥有不同分辨率的记忆。

---

十、Sliding Window 不只是保留细节，还负责修复因果盲区

压缩 Attention 会带来一个容易被忽略的问题：Causality，也就是因果性。

假设每 4 个 Token 压缩成一个块：

Block 24：Token 96、97、98、99

Data format: RDF-TurtleJSON-LDJSONCSVRDF/XMLMarkdownRSSAtom

Data format: RDF-TurtleJSON-LDJSONCSVRDF/XMLMarkdownRSSAtom

当模型正在处理 Token 98 时，它不能读取整个 Block 24。

因为 Block 24 中包含 Token 99，而 Token 99 对当前时刻来说属于未来信息。

为了避免未来信息泄漏，当前 Query 只能读取严格位于自己之前、并且已经完整结束的压缩块。

这会产生一个副作用：

Token 96 和 Token 97 明明已经出现，但由于它们和 Token 98 位于同一个压缩块中，Token 98 仍然不能通过压缩 KV 访问它们。

这就是压缩 Attention 的同块历史盲区。

Sliding Window 正好补上了这一部分：

• 远处信息通过已经完成的压缩 KV 访问；
• 最近信息通过原始未压缩 KV 访问。

所以，Sliding Window 不只是为了保留局部语法和精确数字。

它还承担了一个更基础的职责：

在不破坏因果性的前提下，让当前 Token 能够访问同一个压缩块中已经出现的历史信息。

---

十一、MQA：历史信息只保存一份，查询可以拥有多个视角

DeepSeek V4 的核心 Attention 使用 MQA，也就是 Multi-Query Attention。

它允许 Query 拥有多个 Head，但所有 Query Head 共享同一套 KV。

可以把它理解成：

Query Head 1 ─┐
Query Head 2 ─┤
Query Head 3 ─┼─ 共同读取同一套压缩 KV
...           │
Query Head N ─┘

Data format: RDF-TurtleJSON-LDJSONCSVRDF/XMLMarkdownRSSAtom

Data format: RDF-TurtleJSON-LDJSONCSVRDF/XMLMarkdownRSSAtom

传统 MHA 会为不同 Head 保存不同的 Key 和 Value，因此 KV Cache 会随着 Head 数量增加。

MQA 则把历史信息只保存一份。

不同 Head 的多样性主要放在 Query 端：

• 有的 Head 关注实体；
• 有的 Head 关注位置；
• 有的 Head 关注因果关系；
• 有的 Head 关注格式；
• 有的 Head 关注代码依赖。

它们使用不同的查询视角，读取同一个历史记忆库。

这种设计体现了一个非常实用的原则：

历史状态尽可能共享，当前查询保持足够多样性。

---

十二、Attention Sink：允许模型合法地“什么都不看”

普通 Softmax 有一个隐含要求：

所有 Attention 权重之和必须等于 1

也就是说，无论历史 KV 是否真的相关，模型都必须把全部注意力分配出去。

假设当前 Query 根本不需要任何远程信息，普通 Softmax 仍然会强迫模型关注某些历史内容。

这可能引入不必要的噪声。

Attention Sink 相当于在真实 KV 之外，额外增加一个虚拟位置。

模型可以把不需要的注意力分配给 Sink。

例如：

真实 KV 获得的总权重：0.15
Attention Sink 获得的权重：0.85

Data format: RDF-TurtleJSON-LDJSONCSVRDF/XMLMarkdownRSSAtom

Data format: RDF-TurtleJSON-LDJSONCSVRDF/XMLMarkdownRSSAtom

Sink 不对应任何实际内容，只负责吸收多余的 Attention 权重。

它让模型拥有了一个过去没有的选择：

当前这些历史信息都不值得看。

Attention Sink 和 top-k 是互补关系。

top-k 负责从大量历史 KV 中筛选出更可能相关的候选。

Attention Sink 负责处理另一种情况：

即使已经选出了 top-k，这些候选仍然可能没有真正值得关注的内容。

这个思想不仅适用于 Attention，也适用于推荐系统、MoE 路由和 Agent 工具选择。

一个 Agent 不仅要能判断“应该使用哪个工具”，还应该具备判断“当前不需要使用任何工具”的能力。

---

十三、DeepSeek V4 的效率来自多层优化的乘法效应

DeepSeek V4 的 Attention 效率，并不是来自某一个单独模块。

它同时从多个维度进行压缩。

1. 压缩 KV 数量

CSA：

n → n ÷ 4

HCA：

n → n ÷ 128

2. 压缩实际读取数量

CSA 不会让主 Attention 读取全部压缩 KV，而是通过 Indexer 选择 top-k。

3. 共享 KV Head

通过 MQA，多组 Query Head 共享同一套 KV，减少重复存储。

4. 降低数值精度

不同模块根据任务要求使用不同精度：

• 主体 KV 可以使用 FP8；
• Indexer 的 QK 路径可以使用 FP4；
• 对位置信息更敏感的维度保留更高精度。

5. 压缩输出投影参数

Attention Head 的输出不会直接通过一次巨大的全连接层，而是先分组降维，再完成全局融合。

这些优化不是简单相加，而是接近乘法关系：

序列长度压缩
× KV Head 共享
× 低精度存储
× top-k 访问
× 分组输出投影

Data format: RDF-TurtleJSON-LDJSONCSVRDF/XMLMarkdownRSSAtom

Data format: RDF-TurtleJSON-LDJSONCSVRDF/XMLMarkdownRSSAtom

这也是为什么只做量化、只做 Sparse Attention，或者只压缩单条 KV 的宽度，都很难获得同等级别的收益。

真正的大模型架构优化，通常不是依靠某一个“神奇模块”，而是让多个机制围绕同一个目标协同工作。

---

十四、这套架构真正值得学习的五个设计原则

我认为，DeepSeek V4 Hybrid Attention 最值得学习的，并不是 CSA 等于 4、HCA 等于 128 这些具体参数，而是背后的系统设计方法。

1. 不同距离的信息，不应该使用相同精度保存

最近的信息需要保存原始细节，远处的信息可以逐渐压缩成摘要。

这和人类记忆很相似。

我们通常能准确记住刚刚听到的一句话，但几个月前发生的事情，往往只剩下大致轮廓。

2. 昂贵计算不应该扫描全部候选

CSA 先使用低成本 Indexer 找候选，再让主 Attention 精确处理。

这一思路可以迁移到：

• RAG 检索；
• 搜索引擎；
• 推荐系统；
• MoE 专家路由；
• Agent 工具选择；
• 多模型协作系统。

3. 压缩不是免费午餐，必须设计补偿机制

DeepSeek V4 中，每一种信息损失都有对应的补偿手段：

• 块边界损失：使用跨块重叠；
• 近期精度损失：增加 Sliding Window；
• HCA 细节损失：与 CSA 交错；
• top-k 候选仍然不相关：加入 Attention Sink；
• Attention Logit 可能爆炸：对 Query 和 KV 做 RMSNorm；
• 当前压缩块不能安全访问：使用原始窗口补回。

优秀架构不是没有缺点。

优秀架构是清楚每项优化会损失什么，并提前为这些损失设计补偿路径。

4. 低精度应该用在允许不精确的地方

Indexer 只负责排序，所以可以使用 FP4。

主 Attention 负责真正的信息融合，因此需要更高精度。

这比所有模块统一使用某一种精度更加合理。

5. 算法设计必须考虑真实硬件

HCA 不使用 Sparse Attention，不是因为稀疏思想不好，而是因为压缩到大约 8K 条 KV 后，Dense Kernel 可能更加规则和高效。

现代大模型架构不能只看数学复杂度，还必须考虑：

• 显存带宽；
• KV Cache 布局；
• GPU Kernel 效率；
• 排序和稀疏读取成本；
• 跨 GPU 通信；
• Prefix Cache；
• 推理服务中的并发请求。

---

十五、这套思路对 RAG 系统有什么启发

Hybrid Attention 的三级记忆结构，可以直接映射到企业 RAG 系统。

第一层：最近对话原文

对应 Sliding Window。

保存当前问题、最近几轮对话和当前任务状态，不做过度压缩，保证指令与局部语义准确。

第二层：精确知识块检索

对应 CSA。

把文档切分成较细的 Chunk，建立向量索引，针对当前问题召回 top-k。

它主要负责找出：

• 精确条款；
• 具体数字；
• 接口定义；
• 操作步骤；
• 相关代码；
• 原始证据。

第三层：文档级和项目级摘要

对应 HCA。

为每份文档、每个项目甚至整个知识域建立高级摘要。

这一层不负责回答具体细节，而是帮助模型理解：

• 这份文档属于哪个业务；
• 当前项目的目标是什么；
• 不同文件之间有什么关系；
• 当前问题应该优先检索哪个知识域；
• 整个对话当前处于什么阶段。

很多 RAG 系统效果不稳定，就是因为它们只有第二层。

它们只做 Chunk top-k，却没有近期精确上下文，也没有文档级和项目级的全局背景。

一个更完整的 RAG 系统应该同时具备：

近期原文 + 精确知识块 + 全局摘要

这正是 Hybrid Attention 最值得迁移到应用层的思想。

---

十六、总结

DeepSeek V4 的 Hybrid Attention，不是简单地把 Dense Attention 换成 Sparse Attention。

它真正完成的事情，是把 Transformer 的历史上下文重构成了一套分层记忆系统。

Sliding Window 保存近期精确信息。

CSA 保存可检索的中长期细节。

HCA 保存超长距离的全局摘要。

Lightning Indexer 负责低成本筛选候选。

MQA 减少 KV 的重复存储。

FP4 和 FP8 根据不同模块的任务分配不同精度。

跨块重叠与 Sliding Window 负责补偿压缩带来的信息损失。

Attention Sink 则允许模型拒绝无关的历史内容。

这套架构最重要的启发，可以归纳成一句话：

不要让所有信息以相同精度、相同成本和相同方式被保存与读取。

真正高效的长上下文系统，应该根据距离、重要性和用途，对历史信息进行分层压缩、分级存储和按需访问。

从这个角度看，DeepSeek V4 优化的不只是 Attention。

它正在重新定义，大模型应该如何记忆。