摘要长上下文模型真正困难的从来不只是计算量。当上下文扩展到几十万甚至上百万 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 上下文至少带来了三个问题KV Cache 占用的显存越来越大每生成一个 Token需要读取的历史数据越来越多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 合成一条压缩 KVn → n ÷ 4HCA 每 128 个 Token 合成一条压缩 KVn → 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 可以分成两个阶段把多个 Token 压缩成一条 KV从压缩 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 0Token 0、1、2、3 Block 1Token 4、5、6、7 Block 2Token 8、9、10、11Data format: RDF-TurtleJSON-LDJSONCSVRDF/XMLMarkdownRSSAtomData format: RDF-TurtleJSON-LDJSONCSVRDF/XMLMarkdownRSSAtomToken 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/XMLMarkdownRSSAtomData 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 LatentDeepSeek V4 会先把当前隐藏状态下投影成一个低维 Query Latent。然后从同一个 Query Latent 分出两条路径Query Latent ├─ 生成 Indexer Query └─ 生成主 Attention QueryData format: RDF-TurtleJSON-LDJSONCSVRDF/XMLMarkdownRSSAtomData format: RDF-TurtleJSON-LDJSONCSVRDF/XMLMarkdownRSSAtom这样设计首先可以减少重复计算。但更重要的是它让检索模块和主 Attention 建立在同一个查询语义空间中。如果 Indexer 与主 Attention 使用完全不同的 Query 表示可能出现一种问题Indexer 认为某个压缩块非常相关主 Attention 拿到它以后却认为这条信息没有价值。共享 Query Latent相当于让粗排和精排使用同一个查询语义基础。这一点对 RAG 系统同样有启发。很多 RAG 效果不好并不一定是向量模型本身太弱而可能是检索模型和生成模型对“相关性”的理解并不一致。七、为什么 Indexer 要先对每个 Head 的得分执行 ReLUIndexer 会从多个 Head 的角度判断某个压缩块是否相关。假设两个 Head 给出的分数分别是Head 18 Head 2-7Data format: RDF-TurtleJSON-LDJSONCSVRDF/XMLMarkdownRSSAtomData format: RDF-TurtleJSON-LDJSONCSVRDF/XMLMarkdownRSSAtom如果直接相加最终结果只有 1。但这可能掩盖一个事实至少有一个 Head 认为这条信息非常重要。对于检索系统来说漏掉真正重要的信息通常比多召回一些次要信息更加危险。因此DeepSeek V4 会先使用 ReLU 处理每个 Head 的分数。ReLU 的规则非常简单ReLU(x) max(0, x)也就是正分保留负分归零。经过 ReLU 后上面的结果变成Head 18 Head 20 最终得分8Data format: RDF-TurtleJSON-LDJSONCSVRDF/XMLMarkdownRSSAtomData format: RDF-TurtleJSON-LDJSONCSVRDF/XMLMarkdownRSSAtom这相当于一种比较宽松的 OR 投票只要某一个语义视角强烈认为它相关就给它进入候选集合的机会。从搜索系统的角度看这是一种偏向召回率的设计。Indexer 宁可多保留一些候选也尽量不把真正关键的信息提前过滤掉。八、HCA 最反直觉的地方压缩足够狠以后Dense 反而更便宜很多人容易形成一种固定认知Sparse Attention 一定比 Dense Attention 更快。但在真实 GPU 系统中这并不一定成立。稀疏计算本身也有额外成本需要执行 Indexer需要计算 top-k需要排序需要保存离散下标需要根据不连续地址读取 KVGPU 对不规则内存访问的利用率通常更低。如果数据已经被压缩到很少再运行一整套稀疏检索流程反而可能得不偿失。HCA 每 128 个 Token 才生成一条压缩 KV。100 万 Token 最终只剩大约 7813 条。面对这个规模直接做 Dense Attention可能比下面这套流程更加高效Indexer top-k 排序 稀疏地址读取 Sparse AttentionData format: RDF-TurtleJSON-LDJSONCSVRDF/XMLMarkdownRSSAtomData 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/XMLMarkdownRSSAtomData format: RDF-TurtleJSON-LDJSONCSVRDF/XMLMarkdownRSSAtom一个 Token 穿过整个模型时会不断经历两种信息处理细粒度检索粗粒度全局建模。这和人类阅读长文档的方式很接近。有时我们需要回头寻找某一句原话有时只需要记住前面章节的大意。Hybrid Attention 的真正价值不是简单把两个 Attention 模块放在一起而是让模型同时拥有不同分辨率的记忆。十、Sliding Window 不只是保留细节还负责修复因果盲区压缩 Attention 会带来一个容易被忽略的问题Causality也就是因果性。假设每 4 个 Token 压缩成一个块Block 24Token 96、97、98、99Data format: RDF-TurtleJSON-LDJSONCSVRDF/XMLMarkdownRSSAtomData 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/XMLMarkdownRSSAtomData 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.85Data format: RDF-TurtleJSON-LDJSONCSVRDF/XMLMarkdownRSSAtomData format: RDF-TurtleJSON-LDJSONCSVRDF/XMLMarkdownRSSAtomSink 不对应任何实际内容只负责吸收多余的 Attention 权重。它让模型拥有了一个过去没有的选择当前这些历史信息都不值得看。Attention Sink 和 top-k 是互补关系。top-k 负责从大量历史 KV 中筛选出更可能相关的候选。Attention Sink 负责处理另一种情况即使已经选出了 top-k这些候选仍然可能没有真正值得关注的内容。这个思想不仅适用于 Attention也适用于推荐系统、MoE 路由和 Agent 工具选择。一个 Agent 不仅要能判断“应该使用哪个工具”还应该具备判断“当前不需要使用任何工具”的能力。十三、DeepSeek V4 的效率来自多层优化的乘法效应DeepSeek V4 的 Attention 效率并不是来自某一个单独模块。它同时从多个维度进行压缩。1. 压缩 KV 数量CSAn → n ÷ 4HCAn → n ÷ 1282. 压缩实际读取数量CSA 不会让主 Attention 读取全部压缩 KV而是通过 Indexer 选择 top-k。3. 共享 KV Head通过 MQA多组 Query Head 共享同一套 KV减少重复存储。4. 降低数值精度不同模块根据任务要求使用不同精度主体 KV 可以使用 FP8Indexer 的 QK 路径可以使用 FP4对位置信息更敏感的维度保留更高精度。5. 压缩输出投影参数Attention Head 的输出不会直接通过一次巨大的全连接层而是先分组降维再完成全局融合。这些优化不是简单相加而是接近乘法关系序列长度压缩 × KV Head 共享 × 低精度存储 × top-k 访问 × 分组输出投影Data format: RDF-TurtleJSON-LDJSONCSVRDF/XMLMarkdownRSSAtomData 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 WindowHCA 细节损失与 CSA 交错top-k 候选仍然不相关加入 Attention SinkAttention 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。它正在重新定义大模型应该如何记忆。
