推理鏈越來越長，模型未必需要記住全部歷史。Prefix Sliding 只保留任務前綴和最近窗口，讓長思考不再背著整條推理鏈前進。
一條推理鏈越來越長之後，模型究竟需要記住多少？
按照標準全注意力的做法，答案幾乎是全部。
先前完成的計算、中間步驟、不斷累積的推理歷史，都會繼續留在後續注意力範圍裡。推理越長，每生成一個新 token 的成本也隨之上漲。
問題在於，模型真的還需要反覆回看這些已經過去的中間步驟嗎？
最近，史丹佛大學、華盛頓大學等機構的一項聯合研究從這裡切入，吳恩達（Andrew Ng）、Yejin Choi、Percy Liang 等參與其中。
團隊提出 Prefix Sliding，只長期保留任務前綴和最近的推理窗口，讓更早的中間 token 逐步退出後續注意力計算。
最終，現有模型無需重新訓練，長思考最高約 3 倍提速。用於強化學習後，單條推理軌跡還能擴展到 10 萬 token 以上。
論文標題：
Prefix Sliding for efficient test-time scaling
論文地址：
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，還承擔 attention sink 的作用。最近生成的 token 則對應模型當前正在處理的問題。
論文用一個簡單算式 ((42 + 84) × 4) - 5 為例：完成 42 + 84 後，後續計算可能只需要這個結果，不再需要保留先前完整的推理過程。
這也構成了 Prefix Sliding 的直接動機：後續計算未必需要始終攜帶完整的推理歷史。
Prefix Sliding 如何丟掉中間 Token？
Prefix Sliding 固定保留任務前綴，最近 W 個推理 token 構成滑動窗口。隨著生成繼續，更早的中間 token 會逐步從後續注意力計算所使用的 KV Cache 中移除。
假設 Prefix 有 100 token、窗口為 4096，即使完整推理已經達到 10 萬 token，後續注意力計算最多只需保留約 4196 token。
窗口填滿後，單步成本不再隨著完整推理鏈增長。
〓 Prefix 固定保留，最近的推理 token 隨窗口向前移動
普通滑動窗口會讓最開始的任務資訊逐步移出窗口，Prefix Sliding 則始終保留 Prefix。
團隊最終採用 Continue PE。附錄在 AIME25 上的實驗顯示，它與 Reset PE 表現相近，同時無需反覆套用新的位置編碼，可以直接複用已有快取表示，計算更高效。
團隊還針對 NVIDIA Hopper 實作了專用 FlashAttention 核心。
對完全位於 Prefix 和滑動窗口之外的 tile 直接跳過，對與有效區域部分重疊的 tile 做元素級 Mask，從而減少無效載入和計算，實際速度也接近普通滑動窗口的實作。
〓 窗口填滿後，Prefix Sliding 的生成吞吐趨於穩定
無需訓練最高提速 3 倍，RL 擴展到 10 萬 Token
在無需額外訓練的設定下，作者以 Qwen3-1.7B 為主模型，在 AIME25、GPQA 和 MATH500 上進行評測。
Prefix Sliding 的優勢來自同樣思考時間內可以生成更多 token，並非單個 token 本身品質變高。
以 4096 token 窗口為例，Prefix Sliding 在 AIME25、GPQA 和 MATH500 上與全注意力表現接近，但在長序列下吞吐明顯更高，128K 時達到 5224 tok/s，而全注意力只有 448 tok/s。
〓 相同思考時間下，Prefix Sliding 可以生成更多推理 token
這裡的「3 倍」比較的是相近任務表現下的思考時間，並非直接比較上述吞吐數字。
〓 相同思考時間下，Prefix Sliding 可以生成更多推理 token
強化學習階段，Prefix Sliding 還能將 rollout 擴展到10 萬 token 以上。為避免對整條超長軌跡做完整反向傳播，作者採用截斷反向傳播。
滑動窗口跨多層的理論感受野可達 W×L，不過作者援引已有分析指出，受資訊瓶頸影響，實際有效感受野更接近約 1.5×W，因此對最後一個窗口進行反向傳播時，只需提供先前有限的上下文。
〓 超長推理軌跡可以採用分塊或截斷反向傳播
例如一條 10 萬 token 的軌跡，窗口為 2048 時，訓練端只接收最後 8192 token，前 6144 token 作為上下文，最後 2048 token 計算 RL loss。
實驗顯示，只保留 1 倍窗口會導致較大的 KL 偏差，擴大到 2 倍後明顯下降，4 倍已經與 8 倍基本接近，因此主實驗採用 4 倍窗口。
〓 傳入更多歷史 token 後，截斷反向傳播的 KL 偏差迅速下降
附錄還在 DeepSeek-R1-Distill-Qwen-7B 上進行了一次規模較小的非同步 RL 實驗。
結果顯示，在訓練端輸入 32768 token、Prefix Sliding 只對最後 8192 token 反向傳播的設定下，訓練獎勵和 AIME24 表現與全注意力相當。
〓 7B 模型上，截斷反向傳播與全注意力表現相當
作者也明確指出，更大規模、更長推理鏈上的表現仍需進一步驗證。
在相近的記憶體預算下，全注意力最大長度為 8192 token，Prefix Sliding 則將最大生成長度逐步提高到 104K，並獲得更高的訓練獎勵。
〓 相近記憶體預算下，Prefix Sliding 支撐更長的強化學習軌跡
中間 Token 並非都能丟
與 Last-k、Summary 和普通滑動窗口相比，Prefix Sliding 的性能與效率綜合表現最好。
Last-k 會重複處理保留 token，普通滑動窗口則會逐漸丟掉任務前綴。Summary 還需要額外生成摘要並引入更多超參數，真實樣例中，模型看起來甚至會忽略摘要裡的已有推導，重新開始求解。
〓 Prefix Sliding 與 Last-k、Summary 和普通滑動窗口的性能—效率對比
在無需訓練的 LiveCodeBench 實驗中，模型可能先寫程式碼，再用數千 token 的註解繼續思考，等回到程式碼時，早先內容已經滑出窗口。
至少需要 16384 token 窗口，才能匹配全注意力。
作者也指出，如果使用 Prefix Sliding 進行強化學習，模型可能學會調整這類註解推理行為，從而允許更短的窗口。
〓 LiveCodeBench 至少需要 16384 token 窗口才能匹配全注意力
短任務也未必受益。HealthBench 平均只生成約 2086 token，而窗口為 2048，很多樣本還沒真正進入滑動階段，因此可獲得的加速空間很有限。
在 Agent 場景中，一次過長的網頁或檔案輸出可能直接填滿有限窗口，甚至讓模型無法同時讀取完整內容。
多輪互動也帶來新的上下文管理難題：後續使用者指令究竟應該併入 Prefix 長期保留，還是允許它們隨後滑出窗口，論文目前沒有給出定論。
Prefix Sliding 也沒有降低超長 Prefix 在 Prefill 階段帶來的 KV Cache 開銷。
論文的直接實證比較還主要限定在能夠直接用於現有預訓練 Transformer、同時滿足單步生成成本有界的方法，並沒有涵蓋其他模型架構、亞二次複雜度方法和混合滑動窗口模型。
結語
Prefix Sliding 把長推理的效率問題進一步具體化為一個上下文管理問題：已經生成的歷史資訊，到底需要保留多久。
哪些資訊應該長期保留在 Prefix 中，哪些可以隨窗口移出，仍然需要更細緻的上下文管理策略。在程式碼任務、Agent 場景中的大體量工具輸出以及多輪互動中，是否還需要額外的記憶機制，也沒有定論。
現有結果表明，固定前綴加滑動窗口能夠顯著降低超長推理成本，但它在更大模型、更複雜的長期任務上的適用範圍仍需後續驗證。