阿里巴巴推出QwenGyre,一套強化學習框架,專為該公司研究團隊所稱的「XLong-horizon」代理訓練而設計:在這類任務中,單次rollout可能執行數小時,涉及模型與環境之間數百次互動,並消耗接近一百萬個token。

該框架回應了LLM代理部署方式的轉變。當代理從解決單一儲存庫問題進階到建構完整程式碼庫時,傳統的線上RL管線會遭遇兩大障礙:rollout持續時間差異過大,導致GPU在少數未完成的執行結束前閒置;而分支執行路徑則產生大量冗餘訓練資料。在以數小時與數十萬token計算的horizon下,這兩個障礙都直接轉化為運算浪費:rollout尾端的閒置硬體與重複的token推高了每次訓練的成本。

彈性排程器針對GPU低利用率

第一個元件「彈性排程器」(Elastic Scheduler)解決GPU利用率不足的問題。現有框架通常採取兩種做法之一:讓整個GPU池在rollout與訓練之間交替使用(colocate),導致硬體在漫長的rollout尾端閒置;或在兩個階段之間靜態分割GPU(async),使任何一方都無法借用另一方的閒置算力。每種設計都是以一種閒置換取另一種閒置——colocate方式在rollout尾端使整個池閒置,而async方式則將閒置算力鎖在無法使用它的一側。

QwenGyre改而將硬體組織成可獨立切換的「cell」,並隨著未完成rollout工作量的變化,在推論與訓練之間重新分配。執行中的harness任務絕不中斷:模型請求會在執行途中被重新導向至剩餘的rollout引擎,KV取透過RDMA(遠端直接記憶體存取)遷移,因此無需重複計算。釋出的cell隨後以額外資料平行副本的形式加入進行中的訓練步驟,從核心cell取得權威權重,同時串流訓練依各群組進度分配微批次,使所有cell同步完成。

角色切換速度很快。平均而言,從rollout切換到訓練需要8.5秒,切換回來需要3.5秒——相對於持續數小時的rollout執行而言微不足道。

馴服分支軌跡

第二個元件「軌跡處理器」(Trajectory Processor)負責處理訓練資料本身。在XLong horizon下,代理harness會壓縮飽和的上下文、將子任務委派給子代理,並重試失敗的路徑,因此單次執行會產生一棵分歧上下文路徑的分支樹,而非線性軌跡。天真地展開每條路徑會重複共用前綴並推高訓練成本——這一負擔隨著這些運行產生的近百萬token上下文而不斷增長。

QwenGyre改為將執行重構為前綴共用的軌跡樹,保留每個模型輸出確切原始條件上下文。只有由策略實際生成的token會被訓練,共用目標則透過樹上遮罩僅計算一次。

部分進度也會被評分:觸及逾時的執行仍會根據其保留的工作區狀態進行評估,因此部分嘗試能帶來有意義的獎勵,而非被直接丟棄。考量到單次執行可能佔用硬體數小時,這種回收保留了原本會被丟棄的訊號。在訓練准入階段,每次執行會選取有限數量的軌跡——按角色優先級設上限,主代理優先,其次是子代理,再來是摘要路徑——並在每次執行內對token損失取平均,使路徑數量無法扭曲權重。

基準測試結果

應用於阿里巴巴旗艦Qwen 3.8-2.4T模型、每次rollout約70萬token時,QwenGyre在48個訓練步驟內將NL2RepoBench通過率從52.5%提升至58.5%,完成時間為75.4小時,而async基準為134.6小時、colocate基準為91.5小時——分別實現最高1.78倍與1.85倍的加速,同時達到與基準相同的訓練分數。在相同GPU預算下,該增益在所有三個受測工作負載——NL2RepoBench、DeepSWE與TerminalBench——中均保持一致。

相較基準節省的近60小時凸顯了排程在此規模下的重要性:在分數相同的情況下縮短實際運行時間,可降低每個訓練週期的時間成本。對於評估類似基礎設施宣稱的讀者,需注意這些數字所附帶的兩個條件——訓練分數相同且GPU預算相等——以及所有數據均來自約70萬token的rollout,即該框架所針對的XLong場景。

來源:Alibaba's QwenGyre Tackles The Million-Token Problem With Elastic GPU Scheduling For XLong RL via Metaverse Post.