vLLM 原生 RL API 發布

vLLM 已發布原生強化學習（RL） API，旨在標準化訓練與推理之間的權重同步，並穩定異步 RL 工作負載。這些更新解決了常見問題：權重同步在各框架中以臨時、重複的方式實作，以及異步 RL 設置在大規模時變得脆弱，特別是在 P/D 和 DPEP 部署中。

原生權重同步 API

為確保線上 RL 的 rollout 來自最新的模型權重，vLLM 現在提供了一個標準化的權重傳輸介面，取代了對特定框架工作器擴展的需求。

權重傳輸生命週期

權重傳輸過程分為四個不同的階段，並具有可插拔的後端：

1. 初始化 (init_weight_transfer_engine): 在訓練迴圈開始之前，建立訓練器與推理工作器之間的通訊通道。
2. 開始權重更新 (start_weight_update): 準備 vLLM 工作器接收權重，通常在每個訓練步驟後呼叫。
3. 更新權重 (update_weights): 將訓練器的全部或部分權重傳輸到推理引擎，支援分塊傳輸。
4. 完成權重更新 (finish_weight_update): 執行必要的後處理，例如量化。

支援的後端與自訂

vLLM 目前支援兩個主要的權重傳輸後端，兩者都使用經過優化的封裝實作來減少序列化開銷：

• NCCL: 用於透過廣播操作在不同 GPU 的訓練與推理工作器之間進行權重傳輸。
• IPC: 透過共享記憶體控制柄使用 CUDA IPC 進行同一設備的權重傳輸。

開發者可以透過註冊自訂的 WeightTransferEngine 抽象來實作自己的傳輸邏輯，將傳輸機制與工作器實作分離。

改進的異步 RL 支援

異步 RL 需要在推理請求仍在處理期間更新權重。vLLM 引入了新機制來處理此過程，而不會中斷客戶端請求或導致系統死鎖。

「保持模式」介紹

vLLM 已將 保持模式 加入 pause_generation 和 resume_generation 方法（以及對應的 /pause 和 /resume HTTP API）。這使得引擎能在保持狀態的同時暫停進行中的請求並停止排程器，確保客戶端不需要重試請求。

模式	說明	客戶端影響	是否支援異步 RL?
abort	中止所有進行中的請求	客戶端必須處理重試	是
wait	等待所有進行中的請求	客戶端無需重試	否
keep	暫停進行中的請求	客戶端無需重試	是

解決 DPEP 設置中的死鎖

在資料平行（DP）部署中，當某些引擎收到暫停訊號而其他引擎正在處理請求並等待同步時，先前會發生死鎖。vLLM 透過兩項主要變更來解決此問題：

1. EngineCore 整合：暫停邏輯已從 AsyncLLM 入口層移動到 EngineCore 內的排程器，以減少競爭條件。
2. 兩階段暫停/恢復協議：
   • 第一階段（本地暫停）：引擎暫停排程，但繼續回應 START_DP_WAVE 請求以參與必要的前向傳遞。
   • 第二階段（全域暫停）：引擎執行定期的 all-reduce（每 32 步驟一次），以驗證所有排名是否處於「本地暫停」狀態。達到共識後，它們會一起轉變為全域暫停。

驗證與效能

框架整合

新 API 已整合到 SkyRL，啟用使用 DAPO 配方的 Qwen3-1.7B 異步訓練。

大規模部署

Prime-RL 團隊在 P/D 分離設置中使用 zai-org/GLM-5.1-FP8 模型驗證了該 API。該部署跨越 16 個 8xH200 節點（2 個副本，每個副本為 4P+4D，並使用 DPEP32 進行預填充和解碼），並利用 CPU KV 快取卸載（每節點 1TB）。該設置在 100+ 個訓練步驟中保持穩定，權重更新一致且評估效能提升。