推理链越来越长，模型未必需要记住全部历史。PrefixSliding只保留任务前缀和最近窗口，让长思考不再背着整条推理链前进。

一条推理链越来越长之后，模型究竟需要记住多少？

按照标准全注意力的做法，答案几乎是全部。

此前完成的计算、中间步骤、不断累积的推理历史，都会继续留在后续注意力范围里。推理越长，每生成一个新token的成本也随之上涨。

问题在于，模型真的还需要反复回看这些已经过去的中间步骤吗？

最近，斯坦福、华盛顿大学等机构的一项联合研究从这里切入，吴恩达、YejinChoi、PercyLiang等参与其中。

团队提出PrefixSliding，只长期保留任务前缀和最近的推理窗口，让更早的中间token逐步退出后续注意力计算。

最终，现有模型无需重新训练，长思考最高约3倍提速。用于强化学习后，单条推理轨迹还能扩展到10万token以上。

论文标题：

PrefixSlidingforefficienttest-timescaling

论文地址：

https://arxiv.org/abs/2608.26070

代码地址：

https://github.com/Muennighoff/prefix-sliding

注意力为何集中在推理两端

全注意力的代价会随着推理链长度持续上升，但模型对这些历史token的使用并不均匀。

团队分析Qwen3-1.7B在AIME25上的一条推理轨迹后发现，注意力呈现出明显的“两头高、中间低”。

最前面的Prefix和最近生成的一段token获得更多关注，中间大量推理token的注意力则整体处于低位。

〓长推理中的注意力主要集中在前缀和最近生成的token

Prefix中保存着系统指令、任务描述和工具信息，其中最前面的几个token，尤其前4个token，还承担attentionsink的作用。最近生成的token则对应模型当前正在处理的问题。

论文用一个简单算式((42+84)×4)-5为例：完成42+84后，后续计算可能只需要这个结果，不再需要保留此前完整的推理过程。

这也构成了PrefixSliding的直接动机：后续计算未必需要始终携带完整的推理历史。

PrefixSliding如何丢掉中间Token？

PrefixSliding固定保留任务前缀，最近W个推理token构成滑动窗口。随着生成继续，更早的中间token会逐步从后续注意力计算所使用的KVCache中移除。

假设Prefix有100token、窗口为4096，即使完整推理已经达到10万token，后续注意力计算最多只需保留约4196token。

窗口填满后，单步成本不再随着完整推理链增长。

〓Prefix固定保留，最近的推理token随窗口向前移动

普通滑动窗口会让最开始的任务信息逐步移出窗口，PrefixSliding则始终保留Prefix。

团队最终采用ContinuePE。附录在AIME25上的实验显示，它与ResetPE表现相近，同时无需反复应用新的位置编码，可以直接复用已有缓存表示，计算更高效。

团队还针对NVIDIAHopper实现了专用FlashAttention内核。

对完全位于Prefix和滑动窗口之外的tile直接跳过，对与有效区域部分重叠的tile做元素级Mask，从而减少无效加载和计算，实际速度也接近普通滑动窗口的实现。

〓窗口填满后，PrefixSliding的生成吞吐趋于稳定

无需训练最高提速3倍，RL扩展到10万Token

在无需额外训练的设置下，作者以Qwen3-1.7B为主模型，在AIME25、GPQA和MATH500上进行评测。

PrefixSliding的优势来自同样思考时间内可以生成更多token，并非单个token本身质量变高。

以4096token窗口为例，PrefixSliding在AIME25、GPQA和MATH500上与全注意力表现接近，但在长序列下吞吐明显更高，128K时达到5224tok/s，而全注意力只有448tok/s。

〓相同思考时间下，PrefixSliding可以生成更多推理token

这里的“3倍”比较的是相近任务表现下的思考时间，并非直接比较上述吞吐数字。

〓相同思考时间下，PrefixSliding可以生成更多推理token

强化学习阶段，PrefixSliding还能将rollout扩展到10万token以上。为避免对整条超长轨迹做完整反向传播，作者采用截断反向传播。

滑动窗口跨多层的理论感受野可达W×L，不过作者援引已有分析指出，受信息瓶颈影响，实际有效感受野更接近约1.5×W，因此对最后一个窗口进行反向传播时，只需提供此前有限的上下文。

〓超长推理轨迹可以采用分块或截断反向传播

例如一条10万token的轨迹，窗口为2048时，训练端只接收最后8192token，前6144token作为上下文，最后2048token计算RLloss。

实验显示，只保留1倍窗口会导致较大的KL偏差，扩大到2倍后明显下降，4倍已经与8倍基本接近，因此主实验采用4倍窗口。

〓传入更多历史token后，截断反向传播的KL偏差迅速下降

附录还在DeepSeek-R1-Distill-Qwen-7B上进行了一次规模较小的异步RL实验。

结果显示，在训练端输入32768token、PrefixSliding只对最后8192token反向传播的设置下，训练奖励和AIME24表现与全注意力相当。

〓7B模型上，截断反向传播与全注意力表现相当

作者也明确指出，更大规模、更长推理链上的表现仍需进一步验证。

在相近的内存预算下，全注意力最大长度为8192token，PrefixSliding则将最大生成长度逐步提高到104K，并获得更高的训练奖励。

〓相近内存预算下，PrefixSliding支撑更长的强化学习轨迹

中间Token并非都能丢

与Last-k、Summary和普通滑动窗口相比，PrefixSliding的性能与效率综合表现最好。

Last-k会重复处理保留token，普通滑动窗口则会逐渐丢掉任务前缀。Summary还需要额外生成摘要并引入更多超参数，真实样例中，模型看起来甚至会忽略摘要里的已有推导，重新开始求解。

〓PrefixSliding与Last-k、Summary和普通滑动窗口的性能—效率对比

在无需训练的LiveCodeBench实验中，模型可能先写代码，再用数千token的注释继续思考，等回到代码时，早先内容已经滑出窗口。

至少需要16384token窗口，才能匹配全注意力。

作者也指出，如果使用PrefixSliding进行强化学习，模型可能学会调整这类注释推理行为，从而允许更短的窗口。

〓LiveCodeBench至少需要16384token窗口才能匹配全注意力

短任务也未必受益。HealthBench平均只生成约2086token，而窗口为2048，很多样本还没真正进入滑动阶段，因此可获得的加速空间很有限。

在Agent场景中，一次过长的网页或文件输出可能直接填满有限窗口，甚至让模型无法同时读取完整内容。

多轮交互也带来新的上下文管理难题：后续用户指令究竟应该并入Prefix长期保留，还是允许它们随后滑出窗口，论文目前没有给出定论。

PrefixSliding也没有降低超长Prefix在Prefill阶段带来的KVCache开销。

论文的直接实证比较还主要限定在能够直接用于现有预训练Transformer、同时满足单步生成成本有界的方法，并没有覆盖其他模型架构、亚二次复杂度方法和混合滑动窗口模型。

结语

PrefixSliding把长推理的效率问题进一步具体化为一个上下文管理问题：已经生成的历史信息，到底需要保留多久。

哪些信息应该长期保留在Prefix中，哪些可以随窗口移出，仍然需要更细致的上下文管理策略。在代码任务、Agent场景中的大体量工具输出以及多轮交互中，是否还需要额外的记忆机制，也没有定论。

现有结果表明，固定前缀加滑动窗口能够显著降低超长推理成本，但它在更大模型、更复杂的长期任务上的适用范围仍需后续验证。