MLI重构DeepSeek稀疏注意力：跨层复用索引免训提速

摘要：论文提出多层索引器 Multi-layer Indexer（MLI），利用相邻注意力层选择结果高度重叠这一特征，让当前层复用前一层的 Token 索引，从而解除索引扫描与稀疏注意力的串行依赖。方法无需重新训练或新增权重，默认实现可直接接入 SGLang 解码图，并与 IndexCache／IndexShare 组合。在 10K 至 195K 上下文实验中，同等索引保留率下，DeepSeek-V3.2 和 GLM-5 的解码吞吐最高分别提升 14.5% 和 9.8%；128K 上下文、1/4 保留率时，DeepSeek-V3.2 吞吐达到原始模型的 1.32 倍。LongBench、RULER 与 LongBench v2 精度与 IndexCache 基本持平。

---

核心思路：把跨层索引复用变成并行执行

DeepSeek Sparse Attention（DSA）在 DeepSeek-V3.2 与 GLM-5 系列中，为每个注意力层配置一个 lightning indexer。索引器扫描完整 KV Cache，对候选 Token 打分，并保留得分最高的 k=2048 个位置供本层稀疏注意力读取。长上下文解码时，主要瓶颈因此并非注意力矩阵本身，而是每层都要重复扫描完整 Cache 的索引过程。

MLI 的关键观察是：相邻层最终选择的 Token 集合高度重叠。于是，当前层可以直接使用前一层已经生成的索引，而不必重新计算自己的索引。原本严格串行的流程变为：

第 L-1 层索引扫描 → 第 L-1 层稀疏注意力

第 L 层索引扫描 → 第 L 层稀疏注意力

两条依赖链可以交错执行，各层索引器因而有机会与对应层的注意力计算并行，不再逐层等待。

这一方案不需要重新训练模型，也不引入新的模型权重。其关键前提是相邻层的索引具有足够高的重叠度和稳定性；如果特定任务或上下文中层间选择差异明显，跨层复用便可能削弱检索质量。

与 IndexCache／IndexShare 的组合

MLI 解决的是“保留索引器的层如何更快执行”，而 IndexCache 解决的是“哪些层可以完全省略索引器”。GLM-5.2 将类似机制称为 IndexShare：只让部分层保留索引器，其余层直接复用已有结果。

两者解决的是不同层次的问题：

• IndexCache：减少索引器数量，降低总扫描量。
• MLI：在必须保留索引器的层之间建立跨层重叠，用并行度隐藏剩余扫描延迟。

论文将两种方法组合。实验把保留索引器的层比例定义为 retention：例如 1/2 表示一半层保留索引器，1/4 表示四分之一层保留索引器。

在相同 retention 下，MLI 与 IndexCache 的组合比单独使用 IndexCache 更快：

| 模型与配置 | 吞吐提升 | |---|---:| | DeepSeek-V3.2，retention 1/2 | 最高 14.5% | | GLM-5，retention 1/2 | 最高 9.8% | | DeepSeek-V3.2，retention 1/4 | 最高 7.9% | | GLM-5，retention 1/4 | 最高 5.1% |

增益在 IndexCache 保留索引器较多时更明显，并随上下文增长而上升，符合“长上下文下索引扫描更昂贵”的成本结构。

吞吐、精度与系统成本

MLI 与 IndexCache 还可以采用不同 retention 配置进行交换。论文报告，在 1/r 保留率下，MLI 的吞吐仍高于 IndexCache 的 1/(2r) 配置，同时保留两倍的新鲜索引。

在 128K 上下文、retention 为 1/4 时，DeepSeek-V3.2 的解码吞吐达到未修改模型的 1.32 倍；作为对比，IndexCache 在 retention 1/8 下的吞吐为 1.28 倍。这意味着 MLI 不只是用较少索引器换取速度，也能在保留更多实时选择的条件下避免同等幅度的吞吐损失。

精度方面，LongBench、RULER 和 LongBench v2 的结果与 IndexCache 保持在数个百分点以内。论文没有披露完整逐项分数，因此仍无法判断不同任务类型上的损失分布，尤其是需要跨层区分证据权重的长上下文检索任务。

从系统角度看，默认实现无需修改注意力内核，可嵌入 SGLang 现有生产解码图；针对 DeepSeek-V3.2 还提供可选的融合解码内核。其工程优势是部署门槛低，主要新增成本来自跨层索引复用、调度同步与状态管理，而不是显存中的模型参数。

工程权衡：速度依赖层间索引相似性

MLI 的收益建立在结构假设上：相邻层应选择大体相同的 Token。若层间选择差异较大，复用旧索引可能遗漏本层认为更相关的内容。论文用多个长上下文基准证明总体退化有限，但这不能完全替代针对代码仓库分析、多轮工具调用、长文档问答等生产任务的专项验证。

另一项限制是收益上限。即便索引扫描被成功隐藏，稀疏注意力本身、KV Cache 带宽访问、批处理调度与通信开销仍然存在。随着模型进入更长的上下文，或者 attention kernel 无法充分重叠，MLI 的边际收益会下降。

默认的调度式实现更易维护，融合内核则可能进一步减少 launch overhead 和中间读写，但其收益依赖具体 GPU、批大小、序列长度与内核版本。生产部署不能只采用单一上下文长度下的峰值数字，而应按真实流量分布测量 P50／P95 延迟、每 Token 成本和吞吐。

开发者部署建议

1. 先验证索引重叠度：对目标模型和业务数据记录相邻层 Top-k 交集率。若重叠不足，不宜直接跨层复用。
2. 分 retention 压测：至少覆盖 1/2、1/4、1/8，比较 MLI、IndexCache、二者组合和原始 DSA，而不是只测最高吞吐点。
3. 同时观察质量与延迟：在 LongBench、RULER 之外加入代码检索、财报问答、多轮代理轨迹等业务集，验证数个百分点精度差是否可接受。
4. 利用默认路径降低改造成本：先在 SGLang 生产解码图中启用无内核改动版本，再根据实际瓶颈决定是否启用融合内核。
5. 关注批处理干扰：索引与注意力并行后，CUDA stream 调度、SM 占用和批请求之间的资源竞争可能改变最佳参数，不能只用单请求吞吐推断服务收益。

MLI 的意义不在于增加模型容量，而在于重新组织已有稀疏注意力系统的执行顺序。它利用 DSA 已有的层间冗余，将昂贵的索引扫描从关键串行路径中移出，为超长上下文解码提供了一条无需训练、改造范围较小的优化路径。

---

消息来源：Hugging Face Daily Papers (2026-11-02)

—— 完 ——

主题标签： #DeepSeek 关注 #稀疏注意力 关注 #SGLang 关注 #长上下文推理 关注 #推理优化 关注