LongStraw:在固定 GPU 預算下,把 RL 訓練的上下文推向 200 萬 token
LongStraw: Long-Context RL Beyond 2M Tokens under a Fixed GPU Budget
背景
近年推論(inference)系統的上下文長度突飛猛進,不少商用模型已經能處理百萬 token 等級的輸入。但用來打磨模型行為的 RL post-training(強化學習後訓練)卻遠遠跟不上——訓練工作負載大多還停留在 256K token 甚至更短,實務上只能依賴「長度泛化」(length generalization),也就是希望模型在訓練時只看短序列,部署時卻能自動適應更長的輸入。
這個落差對 AI agent 特別致命。Agent 在執行任務時,觀察(observation)、工具呼叫的回傳結果、參考文件、以及過去的決策紀錄會不斷疊加,整條軌跡(trajectory)動輒累積到數十萬甚至上百萬 token。如果 RL 訓練端沒辦法在這種長度下運作,模型就只能「假裝」自己會處理長上下文,實際訓練時從沒真正見過這種規模的資料,行為與部署環境自然脫節。LongStraw 這篇論文,就是想在有限的 GPU 資源下,把 RL 訓練的可用上下文長度真正推到百萬 token 等級,而不是靠外推蒙混過去。
方法
LongStraw 是一套「架構感知」(architecture-aware)的執行棧(execution stack),以 Group Relative Policy Optimization(GRPO)作為 RL 演算法的具體實作載體。GRPO 的做法是對同一個 prompt 產生一組(group)不同的回覆,再用組內相對分數計算優勢(advantage),省去額外的價值網路(value model)。
問題在於:當 prompt 長達百萬 token、且每個 prompt 要配上多條回覆分支時,傳統做法會為每一條分支都保留完整的計算圖(computation graph)與梯度資訊,記憶體需求隨組大小(group size)線性暴增。LongStraw 的核心優化有三步:
- 共享 prompt 不掛 autograd:因為同一組內所有回覆共用同一段 prompt,LongStraw 先用不需要梯度追蹤的方式跑過這段共享 prompt,避免重複建立計算圖。
- 只保留模型專屬的必要狀態:針對後續 token 生成真正需要的模型內部狀態(如遞迴狀態、KV 相關資訊)才保留,其餘捨棄。
- 短回覆分支逐一重播(replay):各條較短的回覆分支不是同時攤開在記憶體中,而是一條一條重新計算(replay),用「多花一點運算時間」換取「大幅降低同時佔用的顯存」。
這套方法被實作在兩種截然不同的模型架構上,驗證其通用性:一是 Qwen3.6-27B,採用混合式的遞迴(recurrent)與全注意力(full-attention)架構;二是 GLM-5.2,是採用壓縮注意力(compressed-attention)機制的 mixture-of-experts(MoE)模型,共有 78 層。
實驗結果
在 8 張 H20 GPU 上,LongStraw 完成了 Qwen 模型的分組打分(scoring)與回覆反向傳播(backward),達到 210 萬(2.1M)個 token 位置的處理規模。更關鍵的是記憶體效率:把 group size 從 2 提高到 8,尖峰配置記憶體(peak allocated memory)只增加了 0.21 GB——幾乎可以說是「群組愈大、邊際成本愈低」。另外在單獨的壓力測試(stress test)中,系統極限甚至衝到了 446 萬(4.46M)個 token 位置。
在更大規模的 32 張 H20 GPU 環境下,研究團隊針對 GLM-5.2 完整的 78 層架構,驗證了 LongStraw 端到端(end-to-end)執行路徑在 210 萬 token 長度 prompt 下確實可行。
不過作者相當坦誠地標註了限制:這些數字驗證的是「執行容量」(execution capacity),而非「完整訓練正確性」——因為目前捕捉的 prompt 狀態是被 detach(去除梯度追蹤)處理的,部分分散式(distributed)前向傳播與梯度組合路徑尚未完全打通。換句話說,LongStraw 目前證明的是「跑得動、記憶體撐得住」,而非「訓練出來的模型品質已完全驗證」。
意義
LongStraw 的價值不在於刷新某個 benchmark 分數,而在於補上了 agent 訓練管線裡長期被忽視的一塊拼圖:讓 RL 後訓練的上下文長度真正貼近推論端的能力。如果 agent 的觀察與工具輸出可以在訓練時就以百萬 token 規模真實出現,模型學到的策略會更貼近部署時的實際情境,而不是靠長度泛化去「賭」模型能撐住。
當然,這個方向也有值得留意的侷限。社群討論中就有使用者(@O96a)指出,現實中許多 agent 迴圈的工具輸出是「邊跑邊回傳」(streaming),上下文成長並非線性、可預測,這與 LongStraw 目前「共享 prompt」的假設有落差——也就是說,論文驗證的更像是靜態長 prompt 的極限情境,離真正動態、交錯式的 agent 軌跡訓練還有距離。
整體而言,LongStraw 提供的是一套可以在 8 張到 32 張 H20 這種相對「平民」規模的 GPU 叢集上,把 RL 訓練上下文推向 200 萬 token 等級的具體工程路徑,並誠實地劃出了目前「執行可行」與「訓練完備」之間的界線。對於正在打造長軌跡 agent 的團隊來說,這是一份很實用的工程參考,也預告了下一階段需要補齊分散式梯度組合的方向。