Prefix Sliding：长思考不必背着全部历史，但「忘掉中间」不是免费午餐
事件全貌：把推理历史拆成「不能忘」和「可以滑走」两部分
2026 年 8 月 26 日，斯坦福大学、加州大学圣塔芭芭拉分校、华盛顿大学和 Prime Intellect 的 18 位研究者提交论文《Prefix Sliding for efficient test-time scaling》并公开代码。它要解决的问题很直接：自回归模型每生成一个新 token，通常都要保留此前整条推理轨迹的 Key-Value Cache（KV Cache），并读取越来越长的历史。模型想得越久，显存占用和单步注意力成本越高。
Prefix Sliding 固定保留系统指令、用户问题和工具定义等任务前缀，同时只保留最近一段推理 token，更早的中间推理则退出 KV Cache。若前缀为 100 token、滑动窗口为 4096 token，无论模型累计生成四万还是四十万 token，后续注意力最多读取约 4196 token。它把旧推理视作可淘汰的工作草稿，但把任务是什么、允许使用什么工具以及当前正在处理什么留在缓存中。
以 Qwen3-1.7B 为主要实验模型时，4096-token 窗口在 AIME25、GPQA 和 MATH500 上的准确率分别为 33.9、37.0 和 91.5，完整注意力为 34.2、37.6 和 91.7。论文表 1 中，128K 序列的系统吞吐从 448 tok/s 提升到 5224 tok/s，约为 11.7 倍；完整注意力基线同样使用 vLLM 和 FlashAttention，并非未经优化的朴素实现。
但这些数字不能混为一谈。论文所称「最高约 3 倍更快」，是依据平均生成长度和相应批量吞吐推算的思考时间，不是逐请求端到端延迟实测；5224/448 也不能直接解释成单次回答快了 11.7 倍。速度实验在一张 80GB NVIDIA H100 上批量生成 1024 条序列，并由 vLLM 自动选择批大小，因此 tok/s 反映特定批处理条件下的系统吞吐，不等于单用户的单流生成速度。
公开材料之间还存在一处未解差异。截至 2026 年 8 月 31 日，官方 Hugging Face results.json 中，128K、4096 窗口的 Prefix Sliding（速度脚本标签 SW）为 5044.13 tok/s；5223.90 出现在普通滑动窗口 SWR 下。32K 的 Prefix Sliding 原始值 5479.25 则与论文表 1 的 5479 相符。按 5044 对 448 计算，特定环境下仍有约 11.3 倍吞吐提升，但 5224 目前只能准确称为论文表格数字，尚未与公开原始 artifact 完全对齐。
Prefix Sliding 还被用于强化学习：采样器可以生成超过 10 万 token 的完整轨迹，训练器借助截断反向传播，只接收末端窗口及必要上下文。例如，一条 10 万 token 轨迹配合 2048-token 窗口时，训练器可只接收最后 8192 token，并仅对最后 2048 token 计算强化学习损失。这避免了超长轨迹因显存不足而被截断、丢弃，却引入近似梯度和长轨迹信用分配风险。
这仍是一篇 arXiv v1 预印本。仓库公开了评测结果、训练数据入口以及定制的 vLLM、FlashAttention 和强化学习分支，但依赖版本较旧，作者预计构建自定义 FlashAttention 与 vLLM 约需 10 小时。仓库提交较少，也缺乏成熟的跨硬件独立复现。因此更准确的结论是：研究团队展示了一条代码公开、实验清晰且很有吸引力的工程路线，但尚未证明多数模型、任务和部署环境都能安全忘掉中间思考。
为什么长思考突然撞上了 KV Cache
Transformer 的 KV Cache 避免了每生成一个 token 就重新计算全部历史，却留下持续增长的内存账单：缓存随层数、KV 头数、向量维度、精度、序列长度和并发数扩张，每一步解码还要读取更长的历史。短回答中这不显眼，到了数万乃至数十万 token 的连续推理，显存容量和内存带宽就会成为系统上限。
FlashAttention 改善了注意力在 GPU 内存层级间的数据搬运，但没有改变每个新 token 都要面对不断增长历史的曲线。高效内核能降低常数，不能让无上限的历史变成固定工作集。
测试时计算则把问题进一步放大。2024 年的研究表明，在适当难度和计算分配策略下，小模型增加测试时计算可能胜过大 14 倍的模型，但收益依赖题目与策略，并非多算必然更好。2025 年的 s1 又通过 budget forcing 让模型在准备结束时继续检查，使 s1-32B 在 AIME24 上从 50% 提升到 57%。行业由此从「训练更大的模型」转向「让模型在一次回答中多想一会儿」，而长推理本身也开始成为显存和延迟的主角。
长输入和长输出即使都叫 128K，工程性质也不同。输入文档的预填充主要发生一次；连续推理却由一连串严格依赖前一步的解码组成。Prefix Sliding 针对后者，也不降低超长前缀的预填充成本。它更适合围绕较短题目持续推理，而不是把整本书作为固定前缀。
两个锚点：任务前缀与近期工作区
Prefix Sliding 并不假设所有旧 token 都无用。作者在一条 Qwen3-1.7B 的 AIME25 轨迹上观察到：最初几个 token、提示词和 <think> 分隔符获得较多注意力，近期推理也很重要，大段中间轨迹的平均权重较低。但这张图经过跨层、跨头平均和高斯平滑，只能作为方法动机；注意力权重不能直接等同于信息的重要性，更不能证明中间 token 没有因果作用。
开头位置可能只是 attention sink，完整任务前缀却包含持续有效的语义约束。某项工具定义可能数千步没有被调用，却在下一步突然变得关键。因此 Prefix Sliding 采用面向未来的规则：不根据历史注意力判断任务契约是否值得保留，而是默认完整保留。
窗口向前移动时，论文选择继续使用原始位置编码（Continue PE），避免重新计算已经编码的 KV 表示。定制 Hopper FlashAttention 内核把可见区域拆成两个不连续块：固定前缀和最近窗口；部分重叠的 tile 逐元素遮罩，完全落在中间禁区的 tile 直接跳过，使稳态速度接近普通滑动窗口。
真正重要的产品含义是，系统开始出现三类状态：长期不变的任务契约、滚动更新的短期工作区，以及需要另行保存的持久成果。如果模型在第 5000 步发现一条第 50000 步仍需使用的引理，滑动窗口无法保证它存活。模型必须把关键成果写入固定前缀、外部文件、结构化记忆或可检索状态。Prefix Sliding 解决了旧草稿不能全部常驻的问题，却把「哪些成果应晋升为长期记忆」推到了下一层。
同期路线：大家都在删缓存，但删除依据不同
| 路线 | 保留什么 | 训练或校准 | 成本最终有界 | 适用任务 | 主要风险 |
|---|---|---|---|---|---|
| 完整注意力 + FlashAttention | 全部历史 | 否 | 否 | 任意旧细节都可能再次被引用 | 显存和解码成本持续增长 |
| StreamingLLM | 少量开头 sink token + 最近窗口 | 否 | 是 | 连续文本流、对话流 | 未必保存完整任务与工具契约 |
| H2O / SnapKV | 历史高注意力 token、近期 token，或按头筛选的重要提示位置 | 通常无需微调 | 固定预算下是 | 长输入、通用 KV 压缩 | 过去的低注意力信息未来可能变得关键 |
| DuoAttention | 检索头保留全历史，流式头保留 sink 与近期窗口 | 需要识别注意力头 | 部分有界 | 需要长程检索能力的模型 | 并非纯即插即用，部分缓存仍持续增长 |
| 分段总结 / InftyThink | 周期性进度摘要 | 通常需要提示设计或训练 | 是 | 可压缩为阶段成果的推理 | 摘要错误和遗漏会累积 |
| Prefix Sliding | 完整任务前缀 + 最近推理窗口 | 推理可免训练；长程 RL 需配套训练 | 是 | 短前缀、超长连续推理、可验证任务 | 中间依赖被删除，难处理超长输入和巨量工具输出 |
StreamingLLM 是最直接的技术先例：它发现纯滑动窗口一旦移除最初 token，模型质量会崩；只保留约四个 attention sink，便能让有限窗口训练的模型稳定处理数百万 token 的流。Prefix Sliding 延续「开头加近期」的形状，却把开头扩展为完整任务前缀：前者主要保护注意力稳定性，后者还保护任务语义，代价是任务前缀越长，固定工作集越大。
H2O 根据累计注意力保留历史 heavy hitters 和近期 token；SnapKV 则按注意力头筛选、聚类提示中的重要位置，论文报告在 16K 输入下实现 3.6 倍生成加速和 8.2 倍内存效率。它们适合通用长输入压缩，但依据已经发生的注意力判断未来价值。一个尚未触发的安全约束可能长期表现为「轻度贡献者」。Prefix Sliding 宁可多占一些缓存，也不对任务前缀中的约束下注。
DuoAttention 将注意力头分为需要全历史的 retrieval heads 和只需近期窗口与 sink 的 streaming heads，报告 MHA 模型最高 2.55 倍内存缩减和 2.18 倍解码加速，GQA 模型收益较小。它更能保护随机回看历史的能力，但需要识别注意力头，且部分缓存仍随上下文增长。若任务要持续数天甚至数周，Prefix Sliding 的固定上限更清晰；若经常回看任意旧细节，DuoAttention 的折中更稳妥。
InftyThink 通过阶段摘要保存旧推理成果，理论上比机械保留近期窗口更聪明，但摘要需要额外生成和重新预填充，也会产生错误与遗漏。2026 年的 COMPINT 显示，现有上下文压缩器对持续会话约束平均只保留 17%，加入并行约束提取器后才提高到 90% 以上。Prefix Sliding 固定保留前缀，避开了总结时误删安全约束的问题，却无法自动把中间成果提炼为长期状态。
这些方法可以组合：固定保留经过权限审查的系统约束，以滑动窗口承载近期工作，中间成果显式写入结构化状态，再用按头检索或 KV 压缩处理超长输入。Prefix Sliding 更像分层状态系统的简单底座，而不是 KV Cache 研究的终点。
数字背后：它证明了什么，又没有证明什么
| 窗口 | AIME25 准确率 / 平均长度 | GPQA 准确率 / 平均长度 | MATH500 准确率 / 平均长度 | 32K 吞吐 | 128K 吞吐 |
|---|---|---|---|---|---|
| 2048 | 27.7 / 47,643 | 35.9 / 30,107 | 89.8 / 9,310 | 8,973 tok/s | 8,737 tok/s |
| 4096 | 33.9 / 29,943 | 37.0 / 16,707 | 91.5 / 7,069 | 5,479 tok/s | 5,224 tok/s* |
| 8192 | 35.8 / 19,373 | 38.0 / 13,605 | 91.4 / 6,229 | 3,291 tok/s | 2,788 tok/s |
| 16384 | 35.3 / 19,872 | 38.2 / 14,378 | 91.5 / 6,160 | 2,441 tok/s | 1,420 tok/s |
| 完整注意力 | 34.2 / 19,158 | 37.6 / 11,403 | 91.7 / 6,056 | 1,477 tok/s | 448 tok/s |
\* 表中 5224 照录论文表 1；公开 results.json 中 Prefix Sliding 对应值为 5044.13 tok/s，5223.90 位于普通滑动窗口标签，差异尚待解释。
4096 是有吸引力的折中，却不是普适常数。2048 吞吐更高，但 AIME25 准确率降至 27.7，平均输出反而膨胀到 47,643 token，显示模型可能因丢失局部状态而反复找路。8192 在 AIME25 和 GPQA 上略高于完整注意力，也不表示删除历史让每个 token 更聪明；作者明确将优势归因于同一时间预算内可以生成更多 token。窗口同时改变速度、记忆和行为分布，必须按任务选择。
代码任务提供了反例：LiveCodeBench 至少需要 16384 窗口才能追平完整注意力。模型可能先写部分函数，再用数千 token 注释思考；等它回到代码时，函数开头已经滑出窗口。数学推理常把旧步骤压缩为新结论，程序却要持续保留命名、接口和早期实现细节。只在数学基准上调好 4096 窗口便用于编程智能体，会把长距离依赖风险藏在平均分数中。
短任务的收益也有限。HealthBench 平均生成约 2086 token，使用 2048 窗口时，大部分生成仍处于窗口尚未真正滑动的预热区。对于常见的数百至两千 token 回答，定制内核、维护成本和行为变化可能超过节省的计算。
证据的模型和硬件覆盖同样有限。主要结论来自 1.7B 模型，7B 仅有一次规模较小的异步强化学习验证；论文没有提供 70B、大型 MoE 或闭源模型的同等级证据。内核专门面向 Hopper，AMD、消费级 GPU、其他 NVIDIA 架构和不同推理引擎上的收益仍未知。因而「无需训练」只能理解为算法层面不修改权重，而不是部署层面零成本。
关键判断：长程智能体会从「上下文窗口」转向「状态操作系统」
Prefix Sliding 最重要的贡献，不是再次证明旧 token 的价值不均，而是把这种不均与长链推理的任务结构对应起来：任务契约永久在线，近期草稿高速读写，中间过程允许淘汰。这一粗粒度划分很像真实工作系统。
它也改变了工程评价标准。竞争不应只围绕最大上下文和 tok/s，而应同时衡量单位正确答案的总计算成本、跨窗口关键约束保留率、长任务重复劳动率，以及遗忘造成的副作用。如果模型为找回丢失状态多生成三倍 token，即使瞬时吞吐更高，总账单和成功率也未必更好。
对智能体而言，最危险的遗忘不是丢掉一段无关推导，而是忘记「不要删除邮件」「只能读取不能提交」「部署前必须等待批准」等持续约束。把全部用户消息永久塞入前缀会使其无限增长；让多轮指令自然滑走又可能造成越权。系统需要在模型之外维护经过解析、冲突处理和版本化的契约状态，并持续映射回固定前缀。Prefix Sliding 没有解决权限系统，却迫使权限从散落的聊天记录中独立出来。
它最可能先用于三类场景：答案可验证的数学与科学推理、采样轨迹极长的强化学习，以及前缀较短且中间成果可写入文件的代码或研究智能体。它不适合直接处理整本书式前缀、频繁注入巨量网页或终端输出的工具智能体，也不适合必须随时回看任意早期细节的法律、审计和复杂协作记录。
最可能的发展是，主流推理框架把它做成一种可选缓存策略：固定前缀、滑动工作区与可晋升记忆协同工作，部署者按任务选择 4K、8K 或 16K 窗口，模型则学习把关键成果写入结构化状态。用户未必知道 Prefix Sliding 的存在，只会看到长任务成本和超时率下降。
最危险的发展是，团队受吞吐数字驱动而过早默认开启，将数学基准选出的 4096 窗口直接套到编程、网页操作和多轮业务流程。模型可能在长工具输出后忘记局部计划或最新限制；若评测只看最终答案，不检查误发邮件、错误提交和权限越界，稀有副作用会被平均成功率掩盖。
最乐观的发展是，模型不再把自然语言推理链当作唯一记忆，而是主动区分草稿、阶段结论、任务契约和外部证据；训练奖励不仅评价最终答案，也评价状态写入是否正确、约束是否持续，以及是否减少回头路。届时所谓「思考一百万 token」未必意味着保留一百万 token，而是让当前材料留在桌面、关键结论进入笔记、原始证据进入可检索档案。
Prefix Sliding 压平了长思考的资源曲线，却没有消除记忆问题。它只是把问题从「显存能否装下全部历史」改成「系统是否知道什么绝对不能忘」。后者更难，也更接近长程智能真正需要的工程闭环。
风险边界与后续验证清单
- 独立复现：解释论文表 1 与公开速度 JSON 的 5224/5044 标签差异，并在不同 GPU、软件版本、批大小和并发下分别测量吞吐、首 token 延迟与单流速度。
- 任务迁移：扩展到代码编辑、长文研究、浏览器操作、客服、金融和医疗约束任务，单独统计长距离依赖失败。
- 窗口自适应：不要把 4096 当作安全默认值；应依据任务、输出类型和依赖跨度动态扩缩窗口，并记录成本。
- 约束持久化：多轮新增指令、权限、撤销与冲突必须进入结构化、可审计、可回滚的契约层。
- 信息晋升机制：让模型把关键中间成果写入前缀、文件或外部记忆，并验证写入内容，而非依赖单次自动摘要。
- 训练稳定性：检查超长 RL 轨迹中的截断反向传播误差、稀疏奖励、信用分配、长度投机和重复循环。
- 有效成本：除 tok/s 外，同时报告每个正确答案的 token 数、墙钟时间、能耗、失败重试和人工接管成本。
信息来源
1. Niklas Muennighoff 等，《Prefix Sliding for efficient test-time scaling》，arXiv:2608.26070，2026-08-26。 2. Muennighoff 等，Prefix Sliding 官方代码与复现说明，GitHub，访问时间：2026-08-31。 3. Ashish Vaswani 等，《Attention Is All You Need》，arXiv:1706.03762，2017。 4. Tri Dao 等，《FlashAttention: Fast and Memory-Efficient Exact Attention with IO-Awareness》，arXiv:2205.14135，2022。 5. Charlie Snell 等，《Scaling LLM Test-Time Compute Optimally can be More Effective than Scaling Model Parameters》，arXiv:2408.03314，2024。 6. Niklas Muennighoff 等，《s1: Simple test-time scaling》，arXiv:2501.19393，2025。 7. Guangxuan Xiao 等，《Efficient Streaming Language Models with Attention Sinks》，arXiv:2309.17453，2023。 8. Zhenyu Zhang 等，《H2O: Heavy-Hitter Oracle for Efficient Generative Inference of Large Language Models》，arXiv:2306.14048，2023。 9. Yuhong Li 等，《SnapKV: LLM Knows What You are Looking for Before Generation》，arXiv:2404.14469，2024。 10. Guangxuan Xiao 等，《DuoAttention: Efficient Long-Context LLM Inference with Retrieval and Streaming Heads》，arXiv:2410.10819，2024。 11. Yuchen Yan 等，《InftyThink: Breaking the Length Limits of Long-Context Reasoning in Large Language Models》，arXiv:2503.06692，2025。 12. Zhiqi Wang 等，《Lost in Compaction: Evaluating Side-Constraint Loss under Context Compaction》，arXiv:2608.11242，2026。 13. An Yang 等，《Qwen3 Technical Report》，arXiv:2505.09388，2025。 14. Prefix Sliding 团队，官方评测原始结果 `results.json`，Hugging Face，访问时间：2026-08-31。 15. Prefix Sliding 团队，速度测试脚本 `run_single_config.py`，GitHub，访问时间：2026-08-31。