讓 Token 持續流動：從 16 個開源強化學習庫中學到的經驗

如果您想直接跳到精華部分，這裡有完整的對照表（無需閱讀，我們不會介意）。

但說真的，如果您留下來，可能會了解到為什麼您的 GPU 有 60% 的時間處於閒置狀態。

1. 動機：從同步 RL 訓練到非同步架構

非同步 RL 訓練已成為大規模後訓練（post-training）的主導範式。現代後訓練中的幾種趨勢使得同步訓練迴圈幾乎無法擴展：

開源生態系統已收斂出一種共同的架構對應方案：將推論與訓練解耦（disaggregate）到不同的 GPU 池中，透過 rollout 緩衝區連接它們，並讓兩端同時運行。

我們正在為 TRL 開發一個新的非同步訓練器，TRL 是最廣泛使用的模型後訓練函式庫之一。為了指導我們的設計，我們調查了 16 個從底層就圍繞非同步訓練構建的開源函式庫，並在七個維度上進行了比較：編排原語、緩衝區設計、權重同步協定、陳舊性管理、部分 rollout 處理、LoRA 支援以及分散式訓練後端。本文提煉了我們從該調查中提取的設計原則。

除了 RL 之外，對非同步基礎設施的需求也日益明顯。例如，在在線蒸餾（on-policy distillation）中，學生模型生成序列而老師模型對其評分，這鏡像了 GRPO，但將獎勵函數換成了老師的前向傳播。意識到這種結構相似性，本調查中的所有內容同樣適用於非同步蒸餾。我們將在第 5 節回到這個更廣泛的觀點。

1.1 TRL 目前如何進行 RL 訓練

TRL 目前的 GRPOTrainer 在單個同步的 training_step() 調用中實現了完整的 GRPO 迴圈（提示詞採樣、生成、獎勵評分、優勢計算、梯度更新和權重同步）。這種設計簡單且正確，但它無法將生成與訓練重疊，浪費了大量的 GPU 利用率。

觀察 GRPOTrainer，我們在每個訓練步驟中按順序執行以下階段：

每個階段都會阻塞直到完成，然後下一個階段才開始。時間線如下所示：

TRL 提供了 steps_per_generation 配置選項，以便在多個梯度步驟中重複使用一組 rollout（時間重用），從而分攤生成成本。但生成調用本身仍然是完全同步且阻塞的；在 Batch 中的每個完成（completion）結束之前，訓練器無法開始梯度計算。

該函式庫還支援以伺服器模式運行 vLLM 作為獨立進程。它在生成期間釋放訓練 GPU，但仍存在兩個硬同步屏障：HTTP 調用直到所有完成返回為止，以及權重同步在傳輸期間同時阻塞訓練器和 vLLM。

1.2 同步部署 vs. 解耦訓練

在討論非同步訓練之前，必須了解使用獨立推論引擎進行 RL 訓練的兩種部署拓撲：

解耦模式的最大優勢在於推論和訓練可以並行運行。當訓練器在 Batch N 上計算梯度時，推論池已經在為 Batch N+K 生成 rollout，從而實現非同步訓練。然而，這種好處是有代價的：需要額外的 GPU。

並行（Concurrency）、非同步（Asynchronicity）和平行（Parallelism）是經常被混淆的不同概念。在本文中，當我們說「非同步訓練」時，我們指的是特定的含義：生成和訓練並行運行，並具有有效的重疊；推論池在訓練池對當前 Batch 計算梯度時，正在生產下一個 Batch 的 rollout。這從根本上是解耦模式的能力。同地協作模式可以受益於睡眠/喚醒記憶體管理或快速就地重分片（resharding）等優化來加速推論，但它無法實現真正的同時重疊；推論和訓練仍然在相同的 GPU 上輪流進行。本調查中實現有意義非同步重疊的每個函式庫都以解耦模式為基礎。

1.3 生成瓶頸

在推理模型的 RL 訓練中，自回歸生成佔據了大部分的牆鐘時間（wall-clock time）。數學或編碼任務的單個 rollout 可能會產生 8K–64K token 的思維鏈推理（參見 QED-Nano 的 rollout 長度）。

具體來說，考慮在單個 H100 80GB GPU 上的 vLLM 基準測試（bf16，無量化，離線吞吐量模式）。7B 模型（DeepSeek-R1-Distill-Qwen-7B）實現了約 6,300 output tokens/s 的總吞吐量；32B 模型（DeepSeek-R1-Distill-Qwen-32B）下降到約 1,200 output tokens/s。這些是所有並行請求的總吞吐量，即推論引擎每秒可以處理的數量，無論有多少序列共享 GPU。

現在考慮一個典型的 GRPO 訓練步驟：每個提示詞 G=8 個完成 × 64 個提示詞/Batch = 512 個 rollout。生成需要多長時間？

即使在短端（使用 7B 模型生成 2K token），僅生成一項在每個訓練步驟中就要消耗幾分鐘。在長端（前沿推理模型越來越多地在此運行），單個生成階段在一個 GPU 上可能需要數小時。擴展到 8 個推論 GPU 會將這些時間減少約 8 倍（假設吞吐量線性擴展），但即便如此，在 32B 模型上進行 32K token 的 rollout 每個步驟仍需約 28 分鐘。

掉隊者問題（straggler problem）進一步加劇了這種情況。在像 GRPO 這樣基於組的演算法中，您為每個提示詞採樣 G 個完成。在最慢的完成結束之前，Batch 無法繼續。思維鏈的輸出長度變化很大；單個提示詞可能會產生從 1K 到 32K token 不等的完成。Batch 被最長的完成所限制，而連續批處理（continuous batching）只能部分緩解這種情況：較短的序列釋放了插槽供新工作使用，但 GRPO 組中的最後一個序列仍然會阻塞該組的獎勵計算和訓練步驟。

1.4 核心見解

本調查中的每個函式庫都獨立地收斂到相同的架構原則：將推論 GPU 與訓練 GPU 物理分離，並非同步推送權重，使生成永不停止，訓練永不等待。

推論池持續運行，將完成的 rollout 餵入緩衝區。訓練池從緩衝區中提取數據，計算梯度更新，並定期將新權重推回推論池以保持同步。這兩個迴圈以各自的速度運行，由緩衝區解耦。

這種設置具有高度的可擴展性，但它引入了一類新問題：陳舊性（在舊策略下生成的 rollout）、權重同步開銷、部分 rollout 處理等。本文的其餘部分將詳細剖析當前的開源函式庫如何解決這些問題。

2. 調查的函式庫

3. 比較框架：七個維度

為了理清快速擴張的非同步 RL 函式庫生態系統，我們提出了七個正交的比較維度。每個維度都捕捉了一個塑造函式庫性能、複雜性和權衡的基本設計決策。

維度 1：編排與並行原語

系統如何協調其分散式組件？

編排框架的選擇決定了編程模型、失敗語義和擴展上限。與其列出每個函式庫的實現細節，景觀可以清晰地分解為四種編排類型，這些基本協調範式在抽象級別、失敗模型和部署要求上有所不同：

關於 Tunix 的說明：Tunix (Google) 使用 JAX 原生網格模型，配合 ThreadPoolExecutor 進行非同步重疊，並使用 jax.device_put 進行跨網格權重傳輸。它在架構上與 PyTorch 生態系統有足夠大的差異，因此在編排上進行直接比較沒有意義；它存在於 XLA/TPU 世界中，擁有自己的協調原語。

上表揭示了一個引人注目的模式：調查的 16 個函式庫中有 8 個使用 Ray 作為其編排骨幹。這並非巧合；它反映了 Actor 模型與 RL 訓練結構之間深層的架構契合。Anyscale（Ray 背後的公司）對 LLM 開源 RL 函式庫的一項調查證實了這種收斂。大規模的 RL 訓練涉及根本上異構的組件（推論引擎、訓練引擎、環境、獎勵模型），這些組件必須在集群中協調，通常在不同的硬體類型上，具有不同的擴展要求和失敗模式。Ray 的 Actor 模型直接映射到這一點：

Actor 隔離與異構資源。每個 RL 組件（vLLM 推論伺服器、FSDP 訓練器、獎勵模型、環境池）都成為一個具有自己資源要求（num_gpus, num_cpus, memory）的 Ray Actor。放置組（Placement groups）提供了對 GPU 親和性的細粒度控制，而無需手動進行 SSH/torchrun 編排。

調度與自動擴展。Ray 的調度器處理在集群中放置異構 Actor 的組合問題。當生成需要的 GPU 小時數比訓練多 8 倍時，您只需告訴 Ray 獨立擴展您的推論 Actor 即可。

容錯性。長期的 RL 訓練運行（數天到數週）容易受到 GPU 故障、OOM 終止和網絡分區的影響。Ray 的 Actor 重啟策略和對象存儲複製提供了彈性，而使用原始的 asyncio 和 multiprocessing 則需要大量的自定義基礎設施。容錯性的具體例子：例如 open-instruct 依賴 Ray 的 Actor 監督來從 rollout 中途的 vLLM 引擎崩潰中恢復。

用於零拷貝數據傳輸的對象存儲。Rollout 數據可能非常大，對於極長上下文的推理，每個 Batch 可能達到數十 GB。Ray 的共享內存對象存儲允許在同一節點上的 Actor 之間進行零拷貝傳輸，避免了通常隨 multiprocessing.Queue 方法而來的序列化開銷。

生態系統成熟度。Ray 自 2017 年以來已在大規模環境中經過戰鬥測試，並在數千個 GPU 上進行了生產部署。調試開銷是真實存在的（Ray Dashboard、分散式堆棧追蹤、放置組失敗），但在多節點規模下，從頭開始構建等效的協調方案會更糟。也就是說，Ray 是一個沉重的依賴項：它引入了自己的調度器、對象存儲和儀表板，增加了並非每個團隊都需要的操作複雜性。這正是為什麼像 PRIME-RL、PipelineRL 和 AReaL 這樣的函式庫選擇輕量級原生 Python 協調（asyncio、threading、Redis streams）的原因——當您控制整個堆棧且部署拓撲固定時，原生 Python 的簡單性和可調試性通常超過了 Ray 提供的便利。

代價是對一個非平凡運行時（non-trivial runtime）的硬性依賴。這種權衡可能是值得的，特別是對於生產規模的訓練（64+ GPU、多日運行、複雜的獎勵計算）。

雖然 Ray 的 Actor 模型是場上的主要參與者，但 Monarch 作為 Meta 推出的一種新的 PyTorch 原生分散式 Actor 框架脫穎而出，專為 GPU 工作負載打造。與 Ray 一樣，Monarch 基於 Actor 模型；組件是獨立的 Actor，帶有通過消息通信的信箱，但它是從底層為 PyTorch/CUDA 生態系統設計的，而不是通用分散式運行時。

Monarch 提供了幾種與非同步 RL 特別相關的能力。使用 Monarch 實現非同步 RL 的示例（來自 GPU Mode 講座系列）展示了該架構：生成器、重放緩衝區和訓練器被建模為 Monarch Actor，重放緩衝區吸收來自掉隊 rollout 的延遲變動，而 RDMA 權重同步將更新的參數推送到生成器，而不會阻塞訓練。該模式在結構上與基於 Ray 的設計（verl、SkyRL、open-instruct）相同，但使用純 PyTorch 原生原語實現。

維度 2：Rollout 緩衝區設計

生成的 rollout 如何從推論流向訓練，以及流水線有多深？

緩衝區是位於生成和訓練之間的數據結構。它的深度控制著非同步的最大程度，因此也控制著最大陳舊性。

雙緩衝模式是從同步訓練到非同步訓練最簡單的升級：它精確地將一個生成與一個訓練步驟重疊，並引入最多一個步驟的策略滯後！

另一方面，更深的隊列可以提高吞吐量，但需要陳舊性管理。

緩衝區控制著有多少數據在傳輸中。但數據只是方程式的一半。另一半是在這些 rollout 變得陳舊之前，將更新的權重傳回推論伺服器。這就是權重同步發揮作用的地方！

維度 3：權重同步協定

梯度更新後，新的模型權重如何到達推論伺服器？

範圍說明：此維度側重於解耦模式，即推論和訓練在獨立的 GPU 池上運行，因為這是非同步重疊（以及權重同步設計）真正發揮作用的部署拓撲。同地協作設置（相同 GPU 擔任兩種角色）本質上是同步的，不會面臨下面討論的傳輸/中斷權衡。

這是架構上最有影響的維度。該協定決定了同步延遲、中斷粒度以及是否可以進行部分 rollout。

這裡有一個關鍵的區別：傳輸機制和中斷模型。大多數函式庫在啟動權重傳輸之前，會在粗略的邊界（HTTP 請求、完整 Batch 甚至完整訓練步驟）暫停生成。PipelineRL 是一個例外：它根本不會停止生成。

傳輸機制：

在中斷模型中，生成何時暫停以接受新權重？

這是 PipelineRL 與所有其他函式庫根本分歧的地方。景觀可以塌縮為五個概念層級，按從最細到最粗的中斷粒度排序：

「永不停止」層級與所有其他層級有質的區別：例如 PipelineRL 鉤入推論引擎，以便每個 Transformer 前向傳播（一個序列的一個 token 步驟）獲取並釋放鎖。權重更新最多等待一個前向傳播（約幾毫秒），交換所有參數，然後生成立即恢復。所有其他函式庫都在更粗略的邊界停止生成，從一個 HTTP 請求（約數百毫秒）到一個完整的 Batch 邊界（約數秒）。

權重同步控制新權重何時到達。但非同步訓練意味著 rollout 總是在某個策略版本下生成，而該生成策略可能比訓練器落後幾個梯度步驟。函式庫如何處理這種策略滯後就是陳舊性管理。

維度 4：陳舊性管理

系統如何處理生成的 rollout 可能來自比正在訓練的策略更舊的策略這一事實？

一旦生成和訓練重疊，樣本就會變成離線策略（off-policy）。管理這種陳舊性出現了三種正交策略，大多數生產系統會結合使用多種策略：

策略 1：按樣本版本拒絕。每個樣本都標記有生成它的整數策略版本。在訓練時，版本落後於當前策略超過閾值的樣本會在進入損失計算之前被硬性丟棄。簡單且正確，但浪費了花在生成被丟棄樣本上的寶貴計算資源。

策略 2：深度限制。生成和訓練之間的隊列或緩衝區具有有限的容量（或明確的陳舊性門控），這在架構上限制了任何樣本可能落後多遠。範圍從深度=1（領先一步的雙緩衝，根據構造不可能出現陳舊性）到與版本差距掛鉤的明確容量公式。不需要按樣本進行版本追蹤；限制由系統的流水線深度強制執行。

策略 3：IS 加權損失修正。到達訓練器的陳舊樣本通過重要性採樣比率 $\frac{\pi_{\theta}(a \mid s)}{\pi_{\text{old}}(a \mid s)}$ 進行重新加權，通常會進行裁剪（Truncated IS）。一些函式庫還應用 OPSM（對具有負優勢的離線策略樣本將損失歸零）。這保持了吞吐量；沒有樣本被丟棄，但代價是來自 IS 比率的梯度方差。

這些策略是正交的：系統可以單獨使用版本拒絕、單獨使用深度限制、單獨使用 IS 修正，或它們的任何組合。同步系統通過從不重疊生成和訓練來完全避免這個問題。

✅ = 是, ❌ = 否, ⚠️ = 可選 / 可配置, — = 不適用 (同步)

生產系統（PRIME-RL、AReaL、open-instruct）的趨勢是採用混合方法，將深度限制與可選的 IS 修正相結合，獲得有限隊列的架構簡單性，以及用於穩定訓練的重要性採樣損失級安全網。

陳舊性管理處理在舊策略下生成的數據。但是，當權重更新到達時，仍在生成的數據該怎麼辦？

維度 5：部分 Rollout 處理

當權重更新到達時，正在進行的生成會發生什麼？

這對於單個 rollout 可能需要數分鐘的長上下文任務至關重要。四種策略：

到目前為止，每個維度都假設是全參數訓練。但在 LoRA 訓練中，您只訓練幾百萬個適配器參數而不是數十億個，權重同步問題幾乎消失了。讓我們看看這些函式庫如何支援 LoRA 訓練。

維度 6：LoRA 訓練支援

函式庫是否支援通過 LoRA 適配器進行參數高效訓練，以何種模式支援，以及是否利用了僅限適配器的權重同步？

對於 GPU 預算有限的團隊來說，LoRA 可能是最具實際影響的維度。它將可訓練參數數量減少了 99% 以上，將峰值激活記憶體減半，並且當推論伺服器感知 LoRA 時，可以實現僅限適配器的權重同步：與其廣播 7B+ 模型的每個參數（約 100–500ms NCCL），不如僅將適配器增量推送到 vLLM，在 rank 32 時這大約只有 50 MB，傳輸時間不到一毫秒。

• NeMo-RL：僅在 DTensor 後端支援 GRPO 和 DPO 的 LoRA；Megatron Core 後端僅支援 SFT（RL LoRA 列為「即將推出」）。使用自定義的 DTensor 相容 LoRA 模組（非 peft），可選用 Triton 核心。

† ROLL：官方僅支援 DeepSpeed 訓練後端的 LoRA。Megatron 後端的 LoRA 出現在 2026 年 2 月的變更日誌中，但仍處於實驗階段。

‡ open-instruct：模型配置公開了 LoRA 相關欄位（use_peft, lora_r, lora_alpha），且適配器保存處理在檢查點邏輯中。然而，截至 2026 年 3 月，peft 模型從未在 RL 訓練路徑中初始化；LoRA 仍是 RL 訓練器的 SFT/DPO 專屬功能。

三種 LoRA 實現家族：

HuggingFace peft (PipelineRL, SkyRL/FSDP, verifiers-rl, ROLL, OAT, Atropos)：最常見的選擇。標準檢查點格式（adapter_model.safetensors），與任何 HF Transformers 訓練迴圈相容。ZeRO-3 交互需要小心：例如 OAT 需要禁用融合 LM 頭；ROLL 必須完全禁用梯度檢查點。

Megatron-Bridge (verl/Megatron, SkyRL/Megatron, MILES)：3D 平行訓練（TP × PP × DP）所必需。支援多種 LoRA 類型：lora, canonical_lora（將合併的 QKV 拆分為獨立的 Q/K/V 適配器）, vlm_lora 和 dora。canonical_lora 變體避免了 QKV 合併，從而提高了訓練穩定性。MILES 以 HF peft 格式和 Megatron 原生 per-rank 格式保存檢查點。

自定義實現 (NeMo-RL, PRIME-RL, Tunix/qwix)：函式庫特定的 LoRA 模組，不與 peft 檢查點互操作。PRIME-RL 獨特地支援在單次運行中同時使用多個適配器，以實現多實驗並行。Tunix 使用 Google 的 qwix JAX 函式庫，該函式庫添加了內置的 QLoRA（NF4 量化）和 TPU 原生梯度路由。NeMo-RL 使用自定義的 DTensor 相容模組，帶有可選的 Triton 融合核心。

僅限適配器的權重同步機會（與維度 3 的交互）：

13 個函式庫中有 8 個支援僅將 LoRA 適配器增量推送到推論伺服器。這完全改變了權重同步問題（維度 3）的性質。使用全參數訓練時，中斷模型（每前向傳播鎖 vs. 每請求中止 vs. 每 Batch 暫停）決定了在 NCCL 廣播期間浪費了多少生成。當使用帶有僅限適配器同步的 LoRA 時，傳輸量如此之小，以至於幾乎任何中斷模型都能提供等效的吞吐量！甚至 Atropos 的暴力 HTTP 熱交換也變得可行。

維度 7：分散式訓練後端與平行化

函式庫在訓練中使用什麼平行化策略，以及這如何限制或啟用非同步架構？

這個維度橫跨所有其他維度。訓練後端的選擇決定了每個 GPU 可以容納多大的模型、在廣播到推論伺服器之前需要多少集體操作來收集權重，以及哪些模型架構可以被訓練。對於擴展到 30B 參數以上或從密集模型轉向混合專家（MoE）模型的團隊來說，這是最有影響力的決定。

訓練後端對非同步 RL 函式庫設計產生直接影響：

權重同步速度是訓練後端的直接函數，更快的同步意味著更少的陳舊性。

在解耦的非同步設置中，權重同步不一定會停滯推論。關鍵的設計決策是權重更新如何與傳輸中的生成交互；存在四種策略，按干擾程度從低到高排序：

但即使在推論繼續進行的函式庫中，較慢的同步也意味著推論在陳舊權重上運行的時間更長。訓練器和推論池之間的策略版本差距隨著同步持續時間而增長。這是需要考慮的一點。

隨著領域轉向稀疏模型，MoE 支援成為一個日益重要的區分因素。 趨勢很明顯：前沿模型是稀疏的（DeepSeek-V3, Qwen3-MoE, Mixtral, DBRX），而開源權重的 MoE 正在成為後訓練的預設起點。訓練這些模型需要專家平行（Expert Parallelism, EP），將不同的專家分配到不同的 Rank，大多數非同步 RL 函式庫不支援這一點。只有基於 Megatron 的函式庫（verl, SLIME, MILES, ROLL, NeMo-RL）和 PRIME-RL 的 FSDP2+EP 路徑能正確處理 EP。基於 ZeRO 的函式庫（PipelineRL, verifiers-rl, OAT, open-instruct）可以加載 MoE HuggingFace 模型類，但沒有 EP，每個專家都會跨所有 ZeRO-3 Rank 進行分片，而不是放置在專用 Rank 上；每次前向傳播都會 AllGather 每個專家，完全抵消了稀疏性優勢。EP 還使權重同步變得複雜：在廣播到 vLLM/SGLang（通常從單個 TP 組提供所有專家服務）之前，訓練器必須從每個 EP Rank AllGather 專家參數，這是一個 $O(N_{\text{experts}} \times E_{\text{size}})$ 的通信（其中 $E_{\text{size}}$ 是每個專家的參數數量），這在密集模型中是不存在的。對於具有 256 個專家的 235B MoE，這是一個巨大的同步成本。希望在下一代開源 MoE 模型後訓練中保持競爭力的函式庫需要具備感知 EP 的訓練 和 感知 EP 的權重同步。

MoE LoRA 是一個新興需求，而且很棘手。 密集模型上的 LoRA 已被充分理解（維度 6）：將適配器附加到注意力投影，訓練它們，僅同步適配器增量。MoE LoRA 更難，因為自然目標是專家 FFN 層，這意味著每個專家都有自己的適配器。對於一個擁有 64 個專家且在每個專家的 gate/up/down 投影上都有 rank-32 LoRA 的模型，適配器數量從約 20 個（密集）跳升到 200 多個（MoE），且適配器分佈在 EP Rank 中。權重同步必須在推送到推論伺服器之前從每個 EP Rank 收集適配器，這是一個在密集 LoRA 中不存在的協調問題。在調查的函式庫中，只有 ART 明確實現了 MoE 專家 LoRA 層（帶有每專家 LoRA 和手動 allreduce 的 Megatron EP 路徑），而 MILES 通過 Megatron-Bridge 支援 LoRA，可以針對專家層。verl 的 Megatron-Bridge 路徑支援包括 vlm_lora 在內的 LoRA 類型，但未記錄 MoE 特定的專家 LoRA。vLLM 的 LoRA 服務原生不支援每專家適配器；它加載統一應用的單個適配器，因此 MoE LoRA 的僅限適配器同步目前需要自定義推論端邏輯。隨著 MoE 模型成為後訓練的預設選擇，具有高效僅限適配器同步的 MoE LoRA 將是一個需要彌補的關鍵能力差距。

這涵蓋了七個維度，每個維度都捕捉了同一個底層問題的不同側面。它們共同為我們提供了一個比較函式庫的完整視角。是時候把它們放在同一個頁面上了。

4. 全球概覽：16 個函式庫一覽

注意：此概覽反映了截至 2026 年 3 月這些函式庫的狀態。生態系統正在迅速演變；特定功能、後端和集成可能會在不久的將來發生變化。

這就是目前的競爭格局。但該領域發展迅速，幾種新興趨勢即將對這些架構進行壓力測試，其方式可能是設計者未曾預料到的。

5. 下一波浪潮：設計影響

以下趨勢並非新技術清單；每一項都對當今的基礎設施和演算法選擇產生了具體壓力。問題不在於「前沿是什麼？」，而在於「如果這種趨勢勝出，我目前的技術棧中會有什麼崩潰？」

5.1 無評論家演算法：釋放記憶體，但權重同步壓力增加

PPO 的價值網絡使任何訓練節點的記憶體佔用翻倍。該領域正收斂於無評論家（critic-free）變體（GRPO, REINFORCE++, Online DPO），正是因為長 CoT 推理使得這種開銷在 8K–64K 上下文長度下變得令人望而卻步。

這解鎖了什麼：消除評論家釋放了約 50% 的訓練 GPU 記憶體。這部分餘裕可以重新分配給：(a) 更大的 rollout Batch，直接減輕掉隊者方差問題，或 (b) 在相同的 GPU 上同地協作推論和訓練，這完全消除了對獨立 NCCL 權重同步進程組的需求。

這沒有解決什麼：無評論家方法仍然需要頻繁向推論伺服器推送權重。事實上，它們可能會增加同步壓力：沒有價值網絡來提供穩定的基準，GRPO 風格的演算法需要更大的組規模（G=8–32）來獲得低方差的優勢估計，這意味著每步有更多的 rollout 和更快的策略漂移。僅在粗略邊界（每訓練步驟或每 K 步）同步的函式庫在無評論家訓練下會看到陳舊性增長得更快。

不對稱軌跡過濾（GRPO-RoC：過採樣 rollout，嚴格過濾正樣本，均勻下採樣負樣本；DeepSeek-V3.2 和 MiniMax-M1 中的 CISPO/DAPO 風格不對稱裁剪）對陳舊性有更細微的影響。問題不在於 Batch 縮小本身，而在於倖存 Batch 的組成。正向軌跡（簡單提示詞的正確解法）收斂更快且被優先保留；較難的提示詞產生的大多是負向軌跡並被丟棄。結果是：倖存於過濾的樣本系統性地比緩衝區中的平均 rollout 更舊，因為它們解決的簡單提示詞是在訓練早期發出的。一個充滿名義上「新鮮」rollout 的緩衝區可能包含跨越廣泛策略版本的倖存正樣本。在這種體制下，按批次級別追蹤陳舊性的准入控制（例如 SkyRL 的 max_staleness_steps 容量門控、Atropos 的 max_batches_offpolicy）無法檢測到這種批次內版本擴散。按樣本版本標記（維度 4）在這種情況下不是可選項；訓練器必須能夠拒絕或對策略版本偏離太遠的單個樣本進行 IS 修正，即使它們所屬的 Batch 是最近准入的。

無評論家方法簡化了訓練端。但評分端即將變得更加昂貴：過程獎勵模型（PRM）對中間推理步驟評分，而不僅僅是最終答案，這引入了一個全新的同步瓶頸。

5.2 過程獎勵：新的同步屏障

結果獎勵是標量且廉價的，在 rollout 結束時調用一次驗證器即可。過程獎勵模型（PRM）對中間步驟評分，這需要 (a) 對完整推理軌跡進行獨立的 PRM 前向傳播，或 (b) 在生成期間逐 token 計算在線效用函數。

PRPO（帶有每段 PRM 評分的熵峰值分割）和 DEEP-GRPO（通過在線效用進行樞軸識別）都在生成和訓練之間增加了計算開銷。在目前的函式庫景觀中，這一階段尷尬地映射到預處理器池（PipelineRL）或需要額外的 Ray Actor（verl, NeMo-RL）。兩者都不是為此設計的。

關鍵影響：基於 PRM 的信用分配打破了獎勵計算廉價的假設。對來自 7B 模型的 32K token 推理軌跡進行 PRM 前向傳播可能非常昂貴。在每個提示詞 G=8 個完成的情況下，獎勵計算可能會消耗相對於生成本身而言不可忽視的牆鐘時間。兩個後果：

DEEP-GRPO 的樞軸重採樣（pivot resampling）在標準 rollout 和部分 rollout 恢復之外引入了第三種生成模式：從序列中間狀態進行局部重採樣。這需要在樞軸點保存 KV 快取狀態，目前沒有非同步函式庫開箱即用支援這一點。樞軸邊界的權重同步可能是一個新的正確性要求：如果權重在樞軸生成和局部重採樣之間發生變化，優勢估計就會被破壞。當然，我們可以在單次預填充中重新計算 KV 快取，但這可能會在我們的訓練中浪費寶貴的計算資源。

5.3 多智能體協同演化：掉隊者問題加劇

單智能體 GRPO 訓練一個為每個提示詞生成 G 個完成的策略。新興的多智能體自我博弈意味著有效的「組」跨越多個順序鏈接的模型調用。獎勵僅在鏈中的所有模型完成後才可用。

掉隊者動態發生了質的變化。在單智能體 GRPO 中，掉隊者是組中最長的完成，是單峰長度分佈中的尾部事件。在多智能體流水線中，掉隊者是兩個或多個長度分佈的乘積。在提議者/求解者（Proposer/Solver）多智能體架構中，如果每個都有 90 百分位的完成時間（中位數的 5 倍），則聯合 90 百分位大約是中位數的 25 倍。

智能體群上的 RL 意味著一個新的工作單元。今天，每個函式庫中的原子單元都是單個（提示詞、完成、獎勵）三元組。在多智能體訓練中，原子單元變成了一個情節（episode），即由輪次、工具調用和智能體間消息組成的有向圖。緩衝區設計、陳舊性追蹤和優勢計算都需要在情節上運行。重放或分叉情節也可能成為需求。

當模型至少內部一致時，跨智能體的掉隊者問題已經夠糟了。對於 MoE 架構，甚至單個模型在推論和訓練框架之間都可能產生分歧，這在 RL 訓練中引發了一系列新興問題。

5.4 訓練-推論不匹配：DeepSeek v3.2 MoE 案例研究

訓練-推論不匹配問題在非同步 RL 中很普遍；只要 rollout 數據是在策略 $\pi_{\text{old}}$ 下生成的，而梯度更新是在 $\pi_{\theta}$ 下計算的，這兩個策略就會發生偏離。大多數函式庫通過 IS 修正或硬性版本拒絕來解決這個問題。但 DeepSeek-V3.2 的生產經驗揭示了 IS 修正無法修復的兩個結構性不匹配來源。

來源 1：MoE 專家路由不一致。混合專家模型每個 token 激活專家的稀疏子集。推論框架（vLLM, SGLang）和訓練框架（Megatron, FSDP）獨立實現路由器，門控函數中浮點捨入的差異可能導致對相同輸入選擇不同的專家。當專家路由發生分歧時，激活的參數子空間會發生不連續位移；假設專家 A 激活而計算的梯度步驟，被應用到了在專家 B 下激活的權重上。DeepSeek-V3.2 發現這「引發了激活參數子空間的突然轉移，這會使優化不穩定並加劇離線策略問題。」

他們的解決方案 Keep Routing 保留了採樣（推論）期間使用的確切專家路由路徑，並在訓練前向傳播期間強制執行這些路徑。這要求推論框架記錄並返回路由決策以及 token logprobs，並要求訓練框架接受並強制執行它們。目前沒有開源非同步 RL 函式庫實現這一點。對於任何訓練 MoE 模型（DeepSeek-V3 類, Mixtral, 未來的開源 MoE）的團隊來說，這是一個正確性問題，而非性能問題。

來源 2：採樣截斷掩碼不匹配。Top-p 和 top-k 採樣在生成時截斷詞彙表，將低機率 token 排除在採樣分佈之外。在訓練期間，全詞彙表對 $\pi_{\theta}$ 是可見的。這違反了重要性採樣恆等式：$\pi_{\text{old}}$（截斷）和 $\pi_{\theta}$（完整）的動作空間不同，因此對於採樣期間被掩蓋的 token，IS 比率 $\pi_{\theta}(o^*t) / \pi{\text{old}}(o_t)$ 是未定義的。

DeepSeek-V3.2 的 Keep Sampling Mask 解決方案：在採樣期間記錄截斷掩碼，並在訓練前向傳播期間將其應用於 $\pi_{\theta}$，使兩個策略都在相同的詞彙子集上運行。這需要將掩碼從推論伺服器傳回訓練器，這同樣是目前任何函式庫基礎設施都不支援的。

對函式庫設計的影響：Keep Routing 和 Keep Sampling Mask 都要求推論伺服器在返回 token logprobs 的同時返回額外的元數據：路由決策和採樣掩碼。目前推論伺服器（vLLM, SGLang）與訓練器之間的 API 契約是 (token_ids, logprobs, finish_reason)。將其擴展為 (token_ids, logprobs, finish_reason, expert_routing, sampling_mask) 對每個函式庫的數據流來說都是一項破壞性變更。

5.5 蒸餾：換了名字的同一個非同步問題

在線蒸餾（On-policy distillation）中，學生模型生成序列，老師模型用 token 級 logprobs 對其評分，這在結構上與 GRPO 中的非同步協調問題相同。

本調查中的每個設計維度——rollout 緩衝區、權重同步協定、陳舊性管理和部分 rollout 處理——都同樣適用於蒸餾。生成池產生學生 rollout，老師對其評分（取代驗證器），訓練器使用優勢修正的 GRPO 損失或獨立的 KL 目標計算反向傳播。自我蒸餾（Self-distillation）增加了一項協調要求：老師是來自步驟 N-k 的學生凍結快照，因此系統必須定期保存策略檢查點並熱交換老師伺服器而不中斷流水線，這是一項目前沒有函式庫完全自動化的原語。

對函式庫設計的實際影響是，非同步 RL 基礎設施不應被構建為 GRPO 專用系統。生成-評分-訓練流水線是一個通用模式，涵蓋了帶有結果獎勵的 RL、帶有過程獎勵的 RL、在線蒸餾和自我蒸餾。像 SLIME、MILES、PRIME-RL、AReaL 和 NeMo-RL 這樣的函式庫之所以已經支援 GRPO 和在線蒸餾，正是因為它們的非同步腳手架將獎勵/評分階段視為可插拔組件，而不是硬編碼的驗證器調用。任何追求通用性的非同步訓練器都應該這樣做：將評分階段定義為一個介面（一個 HTTP 端點、一個 Ray Actor 或一個同地協作的前向傳播），並讓緩衝區、陳舊性和權重同步機制無論填充內容為何都以相同方式運行。

6. TRL 非同步訓練器的設計選擇

在調查了完整景觀——編排模型、緩衝區設計、權重同步協定、陳舊性策略和部分 rollout 處理——之後，我們現在可以為 TRL 中的非同步訓練器列出具體的設計選擇，以及我們打算探索的面向未來的方向。