Prefix Sliding for efficient test-time scaling
测试时扩展（test-time scaling）通过增加推理时的计算量来提升模型性能，例如让语言模型在解决问题时进行更长的思考。然而，模型通过全注意力（full attention）将整个推理轨迹保存在内存中，导致需要长思考的困难任务代价高昂。我们发现，随着模型持续推理，大多数中间推理 token 的重要性逐渐降低，这让人质疑保留它们是否值得。 基于这一洞察，我们提出 Prefix Sliding 方法，在推理过程中丢弃不属于前缀或最近几千 token 窗口的 token。前缀保留模型可用的关键指令和工具，而最近的 token 则是模型当前正在进行的推理。这限制了总内存需求，与模型推理长度无关，从而实现高效的长时程测试时扩展。 无需训练，Prefix Sliding 即可让现有模型在保持性能的同时速度提升 3 倍。结合强化学习（reinforcement learning）进行训练，Prefix Sliding 能够扩展到超过十万 token 的推理轨迹，获得更好的性能。消融实验表明，Prefix Sliding 优于对中间 token 做摘要或使用普通滑动窗口（vanilla sliding window）的方法。 代码已开源：https://github.com/Muennighoff/prefix-sliding
论文精读
TL;DR Prefix Sliding 通过丢弃中间不重要的 token，只保留前缀与最近窗口，使长推理任务提速 3 倍，并支持扩展到十万 token 以上。
问题
问题背景
Test-time scaling 通过增加测试时计算（如更长推理链）提升模型在复杂任务上的表现，已成为当前大模型能力扩展的重要方向。
现有方法局限
主流实现依赖 full attention 保留完整推理轨迹，导致显存占用与序列长度呈二次增长。对于需要数万甚至十万以上 token 的长推理任务，显存和计算成本过高。虽然已有滑动窗口、摘要压缩等近似方法，但 vanilla sliding window 会直接丢失前缀中的指令、工具定义等关键信息；摘要方法则引入额外计算开销且可能损失重要细节。同时，论文观察到大多数中间推理 token 的重要性随推理推进显著下降，但现有系统仍无差别保留它们，造成资源浪费。
为什么这个问题难/重要
核心难点在于动态衡量 token 重要性 并在线丢弃，同时不影响模型后续推理的连贯性和正确性。这需要在保持模型原始权重不变（zero-shot）或通过 RL 训练适应新注意力模式之间找到平衡。业界对 长推理模型 的关注持续升温，高效支撑超长推理成为硬件成本和服务延迟的关键瓶颈，直接影响 test-time scaling 的实际落地。
行业类比
类似在资源受限的边缘设备上部署长上下文推理服务：既要控制 KV cache 规模，又不能牺牲工具调用和指令遵循能力。
核心洞察
- Prefix Sliding 揭示推理 token 重要性随时间衰减，直接丢弃中间 token 而非压缩或摘要，与 full attention 和滑动窗口方法形成关键差异。这种激进的内存管理策略挑战了“保留所有历史 token 有利于推理”的假设，其有效性源于指令前缀和最近推理窗口承载了绝大部分信息，中间步骤可视为可丢弃的中间产物。
- Prefix Sliding 同时提供无训练和有训练两种路径，无训练仅靠丢弃中间 token 即可实现 3 倍加速且性能不降，而有训练结合 RL 可突破 10 万 token 推理轨迹，为长时程 test-time scaling 提供了可扩展的工程方案。与依赖训练或摘要的已有方法相比，它无需额外模型或架构改动，部署成本低，且通过自定义 kernel 优化了滑动窗口的内存访问效率。
方法
输入与总体思路
Prefix Sliding 面向 test-time scaling 下的长推理场景。输入为固定 prefix, 包括系统指令、工具说明与 few-shot 示例, 以及逐 token 生成的推理序列。
关键模块：prefix + 滑动窗口
模型在每一步只对两类 token 保持注意力：
- prefix 区域：始终保留全部 KV, 保证指令、工具与任务约束不丢失。
- 最近窗口：保留最后
k个 token (论文默认几千) 的 KV, 承载当前推理上下文。
超出窗口的中间 token 会被直接丢弃, 不进入后续 attention。因此 KV cache 大小上界为 O(prefix_len + k), 与总推理长度无关。
输出与训练
每步仍用 prefix + 窗口注意力生成 next token, 推理正确性依赖“大部分中间 token 已失去重要性”这一观察。无需训练即可对现有模型使用, 作者报告在维持性能下提速 3x。若进一步用 reinforcement learning 训练, 模型能学会在丢弃状态下继续长程推理, 支持超过 100k token 的 trace。
与同类方法的差异
相比 vanilla sliding window, 保留 prefix 避免丢失初始指令/工具信息；相比 summarizing intermediate tokens, 不引入额外压缩模型或文本摘要误差, 实现与计算都更简单。
实验
实验设计
Prefix Sliding 在两种设置下评估：无训练 直接应用于现有模型，以及使用 RL 训练 使模型适应丢弃策略。基线包括 full attention（保留全部 token）、vanilla sliding window、summarizing intermediate tokens。评估指标为推理速度、性能保持/提升、可扩展的推理轨迹长度。
关键发现
- 无训练 时，Prefix Sliding 使现有模型推理速度提升约 3 倍，同时性能与 full attention 持平。
- RL 训练 后，模型可有效利用超过 100k tokens 的推理轨迹，取得优于基线的性能。
- 消融实验显示 Prefix Sliding 优于中间 token 摘要和 vanilla sliding window。
与基线对比的深度解读
- 对比 full attention，Prefix Sliding 将显存需求从
O(n²)降至O(nC)（C为固定窗口大小），突破长推理瓶颈，适合测试时扩展。 - 对比 vanilla sliding window，保留 prefix 中的指令与工具信息对任务性能至关重要，避免上下文丢失。
- 对比摘要方法，直接丢弃中间 token 开销更低、无摘要偏差，更适合 RL 在线训练。
行业影响
落地场景
Prefix Sliding 适用于需要超长推理且内存敏感的产品：复杂代码生成与调试(仓库级 agent)、多轮工具调用(客服/运维 agent)、数学与科学推理、金融合规分析。例如，代码托管平台的 Copilot 在长会话中处理跨文件依赖时，中间推理 tokens 可被丢弃，只保留系统指令与最近窗口，使单卡支持更长会话；电商智能客服在订单纠纷处理中需回溯多个步骤，同样可用该策略保持低显存。
商业价值
核心收益在降本：推理显存与推理长度解耦，未训练即可加速约 3 倍，同等 GPU 吞吐提升；长任务不再因 KV cache 爆显存而截断，任务成功率上升，减少人工兜底。训练结合 RL 可支持 100k+ 推理 trace，解锁更复杂问题，增强产品差异化。
与现有产品/工作流接口
可在推理引擎层集成，类似 sliding window 或 H2O 的 cache 策略，但保留关键 prefix。对存量模型可作为 serving 配置开关，无需重新训练；强化学习训练流程可将其作为模型前向的一部分。代码见 Prefix Sliding。
局限
- Prefix Sliding 丢弃中间 token 可能导致长程信息丢失，尤其在需要回溯早期中间步骤的任务中，如复杂数学证明或多步规划。论文 Ablations 显示其优于 summarizing 和 vanilla sliding window，但并未证明信息损失可忽略；对于需要全局一致性的任务，丢弃 token 可能引入不可恢复的推理中断。实际部署时，应针对任务类型设定窗口大小或动态保留策略，否则准确性可能下降。
- 该方法主要针对长 horizon 推理设计，对于短生成或简单任务，固定窗口与 prefix 的保留可能带来额外内存开销甚至轻微性能损失。论文也明确指出 limited benefit for short generations。这意味着在通用推理服务中，如果不做自适应切换，短请求可能无法享受加速收益，反而增加系统复杂度。需要引入基于生成长度的动态机制，才会在混合负载中保持整体效率。
- 论文对比的 baseline 范围较窄，仅与 summarizing 和 vanilla sliding window 等基础方法比较，缺乏与最新长上下文 KV cache 压缩技术（如 H2O、StreamingLLM 等）的系统性对比。此外，未充分验证多轮对话与系统输出场景下 prefix 累积的影响，可能让系统消息与早期对话 token 干扰滑动窗口。这些限制使该方法在真实多轮 agent 或工具调用场景中的适用性存疑，需进一步实证。