PIVOT 把稀疏注意力最后一公里也优化了：Indexer 加速 4x，端到端省 1.6x

PIVOT：给 DSA 的 Indexer 补一刀

用过 DeepSeek 家的 Sparse Attention（DSA）做长上下文推理的人应该都有同感：下游 attention 确实省了，但跑起来的时候，Indexer 那一步卡得让人难受。

DSA 的工作方式是在 token 级别做稀疏注意力，每个 query 只跟 top-k 个 key 算 attention，避免了全局 attention 的 O(L²) 计算。但为了找到每个 query 的 top-k，Indexer 仍然得把前面所有 token 扫一遍、打一遍分，这个 prefilling 过程每层还得来一次。长上下文下，Indexer 本身就成了瓶颈。

新出的 PIVOT 论文（arXiv:2607.24593）就是在打这个点。

几位作者观察到一个现象：相邻位置的 query 在选择 top-k key 时，重叠度非常高。而且 Indexer 打出来的分数沿着 key 方向是长尾分布的——绝大多数 key 得分很低，只有少部分值得保留。那何必每个 query 都从头到尾扫一遍？

PIVOT 的做法是：把一组相邻 query 揉成一个代理 query（proxy query），用它做一次完整的全前缀扫描，拿回一个候选集，然后组内每个 query 再从这个候选集里挑自己的 top-k。一次扫描，全组共享。

论文给出了两个变体。PIVOT-Reuse 更激进——整个组直接用代理 query 的 top-k，跳过二次筛选，速度最快。PIVOT-Refine 则保守一些，每个 query 拿到候选集后再用自己的 Indexer 重新打分选 top-k，精度上可以对齐原始的密集 Indexer，只是多了点开销。作者还提到，这两个变体在预填充和解码阶段用的是同一套算法逻辑，区别只在于分组方式：预填充按固定大小的连续 query 分组，解码阶段则按一个 MTP（多 token 预测）step 中一起解码的 query 来分。

测试结果是在 DeepSeek-V3.2 和 GLM-5.1 两个模型上跑的，基准用了 LongBench 和 RULER。PIVOT 精度跟 DSA 的密集 Indexer 基本持平，Indexer 部分加速了 4x，端到端延迟降低约 1.6x。

这个优化思路在工程上不算反直觉。真正的价值在于它是个训练无关的 drop-in 替换——拿到手直接换掉 DSA 的 Indexer 组件就行，不需要重新训模型，不需要改推理框架的骨架。对已经在生产环境里跑 DSA 的团队来说，这意味着长上下文这块的算力账单能再压一压，而且改动风险很小。

不过有两点需要注意。4x 的 Indexer 加速是在长上下文场景下测出来的，短序列下分组扫描的收益会变薄。另外候选集的大小怎么设、分组大小怎么调，原文没有给出一套通用公式，实际落地时可能还得根据自己的 workload 摸一遍。

PIVOT 是个典型的"最后一公里"优化——当稀疏注意力已经把注意力计算本身的复杂度降下来了，回头发现 Indexer 成了新的瓶颈，再补一刀。这类取向在推理模型落地时越来越常见，也是值得留意的工作方向。