Sparse Attention 同时提出两类主张: 模型可以在较少连接下保留能力, 系统可以因此减少计算或访存。两类主张互相关联, 却不能互相代替。困惑度接近稠密模型, 不代表数万 token 以前的约束仍能被可靠取回; needle 测试命中, 也不代表多段证据组合与开放式生成稳定。类似地, 配置里写着 90% 稀疏, 不代表 GPU 跳过了 90% 的时间; 单个 attention kernel 加速, 也不代表加上路由、重排和通信后的请求时延下降。
Sparse Attention 不能由一张准确率表或一张吞吐表定案。评测需要同时观察语言建模质量、长程能力、路由行为和系统成本, 并让这些结果共享同一份模型配置。有效结论必须形成「选择了什么、能力保留多少、机器少做多少工作」的对应关系。 缺少其中一层, 收益便无法在稀疏机制、额外训练数据、模型容量差异和硬件或基线设置之间归因。
1. 质量不能压成一个平均分
1.1. 从训练分布内走到长度边界
最基础的比较是验证集 loss 或 perplexity, 它检查稀疏模型能否完成 next-token prediction。这个指标应在相同词表、模型规模、训练 token 和数据混合下与稠密模型比较。若稀疏模型额外训练了更多 token, 或通过增加层数补偿每层连接减少, 参数量相近也不是等预算比较。训练曲线比最终一个点更有信息: 它能显示稀疏结构是始终落后、后期追平, 还是只在短上下文样本上接近。
长度评测至少覆盖训练长度以内、训练边界附近和超出训练长度三个区间。每个区间还要控制有效证据距 query 的距离, 因为「上下文总长」和「依赖跨度」不是同一变量。一段 128K 上下文若答案就在末尾附近, 并未检验跨越 128K 的信息传递。报告应给出不同距离桶的曲线, 而不是只汇总所有样本的平均值。
检索成功之后还有推理与生成。 单 needle 测试适合确认某个位置是否完全不可达, 但它的证据唯一、答案短、干扰弱。更强的测试会改变 needle 数量, 加入语义相近的干扰段, 要求从多处证据做合取、排序或时间关系判断。固定局部窗口需要经过多层传播远距离信息, 动态路由则可能因候选相似而把关键块挤出 top-k。两者失效方式不同, 不能只比较最终准确率。
开放式长文任务还应观察引用一致性、跨段约束遵守和前后矛盾。自动指标可以检查答案是否覆盖目标事实, 但长文本生成常有多个合理表述, 需要结合可复核的规则或人工抽样。检索召回是长程能力的必要条件, 不是充分条件。 被取回的 value 还要穿过后续层, 与当前表示正确组合, 最终影响输出分布。
1.2. 路由评测解释质量变化
召回率需要一个可比较的目标。 动态稀疏方法会为每个 query 选出 top-k token、block 或 page。只画选择热力图无法判断选择是否正确。若模型或任务允许得到稠密 attention 分数, 可以把稠密版本的高权重位置当作诊断参照, 计算稀疏候选覆盖了多少 attention mass; 但稠密 attention 权重本身不是因果解释, 也不必等于唯一正确路由。另一种做法是利用带证据位置标注的任务, 直接计算目标证据块召回率。
路由诊断要按层、head、query 位置和距离分桶。平均召回可能掩盖少数关键层持续失败, 也可能由大量容易的局部 query 抬高。还应报告候选集合的稳定性: 对输入做不改变语义的小扰动, top-k 是否剧烈变化; 增加相似干扰块后, 原有证据是否仍被选中。这些观察能够解释质量曲线为何在某个长度或干扰强度后突然下降。
稀疏预算不只看平均值。 固定每个 query 选择相同数量的 block, 便于 kernel 调度, 但不同样本需要的上下文量并不相同。阈值路由允许候选数变化, 质量可能更稳, 系统却要承受 ragged workload。评测应同时给出平均、分位数和最大候选数, 并记录不同 batch 内的负载差异。只给平均 sparsity 会隐藏少数 query 访问大量 KV 的情况, 而这些 query 可能决定尾延迟。
还要区分逻辑选择和物理执行。路由器可能选择 37 个 token, kernel 为对齐而执行包含它们的 8 个 block, 实际读取 128 个 token。若报告只使用路由器输出计算稀疏率, 系统收益会被高估。路由预算必须同时给出 token 级候选、执行块数和实际 KV 读取量, 三者共同连接模型决策与设备成本。
2. 系统收益分层测量
2.1. Microbenchmark 回答 kernel 做得怎样
Kernel microbenchmark 应固定硬件型号、软件版本、数据类型、head 数、head 维度、序列长度、batch 和稀疏布局。预热后重复测量, 报告中位数和高分位时延, 同时给出有效吞吐、实际显存带宽与峰值显存。对于动态模式, 输入不能只有均匀候选数; 至少要加入候选长度变化和随机位置, 否则测到的是最适合规则块的情况。
基线需要包含当前优化良好的稠密 attention, 而不只是显式生成 logits 的朴素实现。比较时还要统一是否包含 QKV 投影、RoPE、mask 生成和输出投影。若 sparse kernel 的计时包含 gather, 稠密基线却不包含对应的数据准备, 或反过来, 加速比就缺少一致口径。microbenchmark 最适合定位性能交叉点: 序列多长、稀疏到什么程度以后, 被删除的工作才超过索引和调度成本。
端到端测试回答用户实际得到什么。 训练测试应报告 tokens/s、每步时间、峰值显存和达到相同验证 loss 所需的总算力。单步更快而收敛需要更多 token, 最终训练成本未必下降。分布式训练还需拆出通信时间, 因为稀疏路由可能引入 all-to-all、负载均衡或额外同步。不同稀疏方法改变激活保存与 backward 路径, 仅报告 forward kernel 无法代表训练收益。
推理必须分开报告 prefill 与 decode。Prefill 适合大矩阵并行, decode 更多受 KV cache 读取影响; 两者的加速来源和最佳块大小可能不同。在线服务还应给出 time to first token、inter-token latency、请求吞吐、显存占用以及 P95、P99 尾延迟, 并在多种并发和输入长度分布下测试。路由若占据关键路径, kernel 的节省会在 time to first token 中被部分抵消。
2.2. 公平比较与失败定位
控制预算才能归因。 架构比较至少要对齐参数量、训练 token、上下文长度分布、优化器、精度和硬件。若稀疏模型使用更长训练上下文或额外长文数据, 长程任务提升不能全部归给 attention 拓扑。若动态路由增加独立参数和辅助损失, 也应报告这些成本。更严格的实验会提供两组对照: 等训练计算量观察最终质量, 以及等最终质量观察总训练与推理成本。
长度外推还依赖位置编码与训练策略。Sparse Attention 在 128K 上工作, 可能同时受益于 RoPE 调整、长上下文继续训练或数据构造。消融要逐项保持其余条件不变, 才能分辨稀疏连接负责哪部分结果。报告中的数字也要注明任务版本、prompt、生成设置和评判器, 防止同名 benchmark 的不同口径被直接横比。
从结果反查失效发生在哪一层。 当质量下降时, 先检查目标证据是否进入候选集合; 若没有, 问题在路由或固定拓扑可达性。候选已覆盖证据但输出仍错误, 再检查 attention mass、层间传播和任务推理。若质量正常而系统不快, 则查看物理执行块、gather 带宽、occupancy 和路由占比。这样的分层定位比笼统归因于「稀疏率不够」更可操作。
当平均时延下降但 P99 上升时, 常见原因是候选数长尾、请求间负载不均或动态编译触发。显存下降不明显时, 需要区分 attention 临时张量、KV cache、模型参数和路由元数据。评测记录必须保留足够的分项, 才能让一个异常数字对应到具体执行阶段。
3. 这一章在整座知识库中的位置
有效上下文把“模型支持多长”拆成可测的长度—复杂度曲线。RULER沿单/多needle、变量追踪、集合交集与词频聚合逐级增加难度,并为Sparse Attention加入full、oracle、真实路由三路配对、证据覆盖和预算—质量前沿。它与评测协议互补:前者确定能力边界,后者把能力与kernel、服务成本合并验收。
「静态拓扑」与「动态路由」给出候选集合如何产生, 「训练」讨论这些连接如何被学到, 「内核」解释逻辑选择如何转成设备执行。评测用同一组观测量连接四部分:质量任务检查输出, 路由指标检查被保留的连接, microbenchmark 检查 kernel, 端到端基准检查完整训练或服务。缺少任意一层, 都难以说明稀疏机制的收益来源。
评测协议规定样本、长度、回退基线、硬件和统计口径;质量与系统联合评测进一步把任务分数、候选召回、attention mass、TTFT、TPOT、HBM 字节与索引成本落到同一条请求记录中。验收要检查基线是否公平、逻辑稀疏率与物理工作量是否混淆、prefill 和 decode 是否分开,以及质量损失能否沿路由、传播和输出逐层定位。联合结果需要同时可复现、可归因并暴露代价, 孤立加速比无法满足这些要求。
3.1. 有效上下文是一条曲线
标称上下文长度只表示接口接受输入,不表示模型在整个范围内稳定利用证据。令任务难度为 ,上下文长度为 ,准确率写成 。给定短上下文基准 和容许下降 ,可以定义
这里是实际测试的长度集合,要求截至的所有已测长度都达标,避免将中间已经失效、后来偶然回升的点算作稳定长度;集合为空时记为未达到阈值。不同任务难度会得到不同的有效长度。单个needle可能在128K仍然稳定,多needle聚合、变量追踪或跨文档推理却可能在32K已明显下降。把它们压成一个「支持128K」会丢掉主要差异。RULER将NIAH扩展到多种检索、追踪与聚合任务,适合画出而非只测一个端点。
长度扫描还应固定有效信息量。若上下文越长同时加入更多证据和干扰,长度与复杂度纠缠;若只重复无关文本,又可能产生容易识别的分布。比较 Sparse Attention 时,可以保持证据数量不变、仅移动距离,再固定距离增加相似干扰项,随后增加所需推理跳数。三组实验分别测传播距离、选择精度和组合推理。
4. 位置偏差必须二维扫描
Lost in the Middle 表明证据位于开头或结尾时表现常常更好。Sparse Attention 还可能引入窗口和块边界偏差。单证据位置 可归一化为 ,但相同 在不同 下对应不同绝对距离。评测矩阵应同时扫描绝对距离与相对位置,才能分辨模型受位置编码、窗口可达性还是首尾偏好影响。
多跳任务还要扫描证据间距。两个证据分别容易检索,不代表模型能在有限层数内把它们合并。令证据位置为 ,query 位置为 ,至少记录 、 与 。后一个距离会改变证据之间能否先发生交互。多跳版 Lost in the Middle 的结果也说明,证据间距离本身会带来额外退化。
4.1. Full、oracle 与真实路由三路配对
对动态稀疏方法,单独比较 full 与真实路由只能看到总差距。加入 oracle sparse 可以拆开预算损失与选择器损失:
- full 使用全部合法 KV;
- oracle 在相同 下依据 full attention 分数选候选;
- routed 使用实际索引器产生候选。
full与oracle的差距表示按教师分数选择后,当前预算下仍出现输出或任务质量变化;它不能单独证明所有同预算候选都无法完成任务。oracle与routed的差距可用于诊断教师选择与实际选择的差异。若oracle也很差,可扫描预算并比较证据覆盖、输出误差和其他候选规则,再判断需要扩大预算、增加全局通道还是改变表示。若oracle接近full而真实路由明显落后,索引近似和训练信号就成为优先检查项。
oracle 定义仍要谨慎。按单层 full attention top- 选择,是局部教师;它没有考虑某条低权重边对以后多层传播的影响。更强的功能 oracle 可以按遮蔽后最终损失变化排序,但计算昂贵。报告中应说明 oracle 使用 attention mass、输出误差还是任务损失,三者不能直接横比。
5. 路由误差需要条件统计
平均召回率无法显示错误集中在哪里。可按教师分布熵 、第 与 名的 logit 间隔、证据距离、head 和层分别统计。低熵且间隔大的 query 若仍漏选,说明索引器存在明显表示误差;高熵、边界接近时集合不稳定,概率质量和输出误差更值得观察。
候选召回还要与恢复通道联动。第一次漏选后,下一层或下一 decode step 重新选回,影响可能有限;整个层组复用错误候选,损失会累积;KV 已驱逐时则无法恢复。可以报告连续漏选长度分布和永久不可恢复比例。相同平均召回下,独立小错误与长串相关错误对长任务的影响不同。
5.1. 预算—质量—成本构成三维前沿
令逻辑预算为 ,质量为 ,端到端成本为 。方法比较不应只取一个 ,而应扫描预算得到 Pareto 前沿。某方法在固定稀疏率质量更高,却因块化放大和索引开销更慢;另一方法逻辑召回较低,但连续读取使端到端成本更小。最终有效点必须同时满足没有其他设置在质量不低的情况下更快,或在成本不高的情况下质量更好。
物理预算至少包含实际执行 tile 数、读取 KV 字节、路由 FLOPs 和索引字节。逻辑 token 数只能解释模型连接。对 GQA,多个 query head 的候选并集决定共享 KV 的物理读取;把每头 相加会高估复用,把单头 当总量又会低估并集。
5.2. 置信区间与尾部样本
长上下文基准通常样本较少,平均分的微小差异可能来自样本组成。对离散准确率可用 bootstrap 给置信区间,并对同一题在 full 与 sparse 下做配对重采样。系统指标应报告多个独立运行的中位数与尾分位,预热、编译和缓存建立要单独标记。
质量尾部同样重要。将失败样本按证据距离、候选质量和答案类型分组,检查是否存在某类问题近乎全灭。平均下降一个百分点,可能是所有样本轻微变差,也可能是少量远距精确引用完全不可用;这两种行为对知识库问答和代码代理的风险差别很大。
6. 参考资料
- Liu et al. (2023), Lost in the Middle: How Language Models Use Long Contexts
- Hsieh et al. (2024), RULER: What's the Real Context Size of Your Long-Context Language Models?
- Bai et al. (2024), LongBench v2: Towards Deeper Understanding and Reasoning on Realistic Long-context Multitasks
- Baker et al. (2024), Lost in the Middle, and In-Between