推理模型的"思考"是要付显存账单的。当模型用 test-time scaling 解难题时,它会生成很长的推理链,而主流架构通过 full attention 把整条推理轨迹都留在内存里——想得越久,KV 缓存越大,算力和显存成本跟着膨胀。难题恰恰需要长思考,于是最需要算力的场景就是最贵的场景。
核心洞察:中间 token 会"失活"
8 月 26 日上线 arXiv 的论文《Prefix Sliding for efficient test-time scaling》(编号 2608.26070)给出了一个反直觉的观察:随着模型继续推理,大多数中间推理 token 会逐渐失去重要性。既然这些 token 后面基本用不到了,一直留着它们还值得付出成本吗?这个洞察直接质疑了一个隐含假设——推理轨迹里每个 token 都同等重要、都必须全程参与注意力计算。
方法:前缀 + 滑动窗口
论文提出 Prefix Sliding:推理过程中只保留两类 token 的注意力——prefix(任务指令、可用工具等关键信息)和最近几千 token 组成的滑动窗口(模型当前正在进行的推理),其余中间 token 直接丢弃。这样无论模型推理多长,总内存需求都被封顶。
免训练直接用在现有模型上,论文报告可提速 3 倍且保持性能;配合强化学习训练,还能把推理轨迹扩展到十万 token 以上——这是 full attention 内存预算下很难触达的区间。消融实验显示,这个方案优于"把中间 token 摘要压缩"和"朴素滑动窗口"两个直觉替代品。
工程侧:落在 vLLM 和 flash-attn 上
方法不是纸上谈兵。GitHub 仓库(Muennighoff/prefix-sliding,Apache-2.0 许可证)给出了基于 vLLM 和 flash-attn 分支的实现,README 演示了在 Qwen3-1.7B 上开启 4096 滑窗做 32K 长度生成;评测覆盖 AIME、GPQA、MATH500、HealthBench 和 LiveCodeBench(后者跑到 262144 max tokens)。评测结果文件和 RL 训练数据集(prefixsliding/train_v6_filtered)都放在 HuggingFace 上,RL 部分对接 prime-rl 与 trl 两套框架。
作者阵容也值得注意:一作 Niklas Muennighoff 之外,还有 Percy Liang、Jason Wei、Andrew Y. Ng、Yejin Choi、Luke Zettlemoyer、Mike Lewis 等,论文署名共 18 人,全文 28 页(正文 9 页)。这种配置通常意味着方法会被社区快速跟进复现。
所以呢
test-time scaling 的主流叙事是"多想 = 多分",但成本曲线决定它能不能普及。Prefix Sliding 的意义在于把"想得久"的边际显存成本压成常数——这对推理 API 定价、端侧长推理、agent 长任务都是直接利好。更值得记住的是那个洞察本身:推理链里的中间步骤是易腐品,不是资产。下次看到模型"思考了十万 token",不妨想一想:其中有多少真的需要被记住?
论文:https://arxiv.org/abs/2608.26070
代码:https://github.com/Muennighoff/prefix-sliding