DSA 稀疏注意力是什么？DeepSeek 把长上下文成本打下来的第二把刀（2026入门）

作者

先说一个反常识的结论

DeepSeek 在 2025 年 9 月发的 V3.2-Exp 里，把自家招牌 MLA 注意力又改了一道。新的东西叫 DSA（DeepSeek Sparse Attention），思路一句话能说完：别让每个 token 都去翻整个 KV 缓存，先挑出真正有用的几十个再看。

你可能读过之前那篇 MLA 的文章，知道它是怎么把 KV 缓存压到原来百分之几的。这次的 DSA 不压显存了，它省的是计算量。两个是不同的刀口，这篇就把后者讲明白。

密集注意力的账：为什么长上下文越来越贵

标准注意力是这么工作的：生成第 N 个 token 的时候，模型让它和前面全部 N-1 个 token 两两算一遍相关性，然后按相关性加权取信息。这就是「密集注意力」，一个 token 都不落下。

问题出在账本上。序列翻一倍，注意力计算量翻的不止一倍，是平方级的增长。100K 上下文的注意力开销，差不多是 10K 的 100 倍。上下文越长，每一层、每一步都在为这种全量扫描付钱。

你可能有疑问：不是有 KV 缓存吗？缓存解决的是「别重复算 K 和 V」，它没解决「每个新 token 都要和全部历史交互」。钱还是照样花，只是花在了注意力计算本身。

不过这里有个被反复验证过的观察：真正跟当前 token 强相关的，往往就那么一小撮。检索当前问题、最近几轮对话，再加上零星几个关键名词的位置。绝大多数历史 token 的注意力权重接近零。钱花在了没人看的地方。

DSA 的做法：一个轻量索引器先挑，主力再细算

DSA 给架构加了一个新角色：闪电索引器（lightning indexer）。它的工作是在正式注意力之前，先快速给所有历史 token 打个分，估一下「这个 token 对当前生成的用处有多大」，然后选出得分最高的前 k 个 token。

接下来，主力注意力只看这 k 个被选中的 token，其余的直接跳过。这就是「细粒度稀疏注意力」：选择粒度细到 token 级，不是按段落或整块粗略丢弃。

打个比方。图书馆有几百万本书，密集注意力是每次提问都把馆里所有书翻一遍再回答；DSA 是先问管理员哪几本书最相关，然后只翻这几本。管理员自己的开销很小，但帮你省掉了翻全馆的时间。

这个「先粗筛再精算」的结构你其实见过。RAG 检索里召回之后加一层 rerank 重排序，是同样的分工：便宜的模型负责海选，贵的模型负责终审。DSA 把这个思路搬进了模型内部，每次生成都在做。

效果一：算力账，成本随长度长得慢了

DeepSeek 发布 V3.2-Exp 时给出过一条成本曲线：上下文越长，DSA 相对密集注意力的优势越大。长上下文场景下 API 成本明显下降，这正是稀疏化的目标场景。

数学上的原因不复杂。密集注意力每步要看 N 个历史 token，DSA 只看固定的 k 个，加上索引器那点额外开销。N 涨到几十万的时候，固定 k 和 N 之间差出几个数量级，省的就是这一大块。

效果二：质量账，分数几乎没掉

省算力的方案最怕掉分。DeepSeek 为了验证这一点，把 V3.2-Exp 的训练配置刻意对齐 V3.1-Terminus，然后跑同一套公开 benchmark。我挑几项数据：

  • MMLU-Pro：85.0 对 85.0，持平
  • GPQA-Diamond：80.7 对 79.9，差 0.8
  • AIME 2025：88.4 对 89.3，反而高了 0.9
  • SWE Verified：68.4 对 67.8，差 0.6
  • LiveCodeBench：74.9 对 74.1，差 0.8

官方的说法是「输出质量与 V3.1-Terminus 基本一致」。也有一项掉了 1.9 分（Humanity's Last Exam 21.7 对 19.8），整体在波动范围内。稀疏注意力历史上多次尝试过，多数败在质量这一关，这次的结果算站住了。

跟 MLA 是什么关系

容易混淆的一点要掰开：DSA 不是 MLA 的替代品，是叠加在其上的。

MLA 管存储：把每 token 的 KV 压进一个低秩潜向量，显存占用降一两个数量级，这是之前文章讲过的部分。DSA 管计算：决定每步注意力「读哪些」缓存条目。

V3.2-Exp 里两个同时在跑。一个把账单里的「内存」削掉，一个把「计算」削掉，各自管一段。

推理栈怎么跟上：FlashMLA 的新 kernel

模型发了，推理引擎得能跑。DeepSeek 的算子库 FlashMLA 跟着发了对应的稀疏注意力 kernel：prefill 最高跑到 640 TFlops，decode 410 TFlops（Hopper GPU）。

部署侧的消息也齐：SGLang 提供了 Docker 镜像，vLLM 在发布当天给了支持。想在本地或私有环境跑 V3.2 系列的话，这两条路都是现成的。

值得一提的是 FlashMLA 最近的动态：2026 年 9 月 30 日的版本移除了 Hopper 架构和 V3/V3.2/V4.0 旧模型的支持，转向 Blackwell（B200）和 V4.1，转向后 sparse prefill 最高 1350 TFlops。跑旧模型要用他们标注的旧 commit。开源项目跟最新硬件走，这很正常，部署前查一下版本兼容就行。

给你三个判断

第一，如果你在用 DeepSeek 的 API，长上下文任务（批量读文档、长代码库分析）的成本曲线从 V3.2 起变缓了，值得重新算一遍账。

第二，如果你在做长上下文的 RAG 系统应用，不必急着改架构。DSA 这类机制在模型内部做了和 rerank 类似的事，应用层按原来的方式接就行。

第三，如果你在自己部署推理，注意 FlashMLA 版本和模型代际的对应关系，别用新 kernel 跑旧模型。

稀疏注意力不是新概念，论文社区试了至少三四年。DSA 值得记住的点在于：它是第一个在主流开源旗舰模型上全量落地的细粒度 token 稀疏方案，而且质量对齐做得很硬。后面各家长上下文的玩法，大概率都会往这个方向靠。

延伸阅读

发表评论