vLLM V0 到 V1 遷移：強化學習訓練的正確性挑戰

PipelineRL 使用 vLLM 作為推論引擎來生成 rollout。推論引擎會取樣 token 並回傳 token 的 logprobs；訓練器則利用這些 logprobs 計算策略比率、KL 散度、裁剪率、熵和獎勵。這些 logprobs 的計算方式若有任何差異，都可能改變訓練動態。

這就是我們在 vLLM V0 到 V1 遷移過程中需要消除的「訓練-推論不匹配」問題。總結來說，在修正了四個問題後，vLLM V1 的表現與我們的 vLLM V0 參考基準一致：這些問題包括處理過的 rollout logprobs、V1 特定的運行時預設值、即時權重更新路徑，以及用於最終投影的 fp32 lm_head。

我們在改變強化學習目標之前，優先修正了後端行為。參考基準運行使用的是 vLLM 0.8.5；V1 運行使用的是 vLLM 0.18.1。圖 1 顯示了最終結果。紅色曲線是最初的 V1 嘗試，而綠色曲線則是在下方描述的修正之後的最終 V1 運行。

圖 1. vLLM V0 參考基準（藍色）、最初的 vLLM V1 嘗試（紅色）以及修正後的最終 vLLM V1 運行（綠色，包含 fp32 lm_head）的訓練器端指標。最終的 V1 運行在裁剪率、KL 散度、熵和獎勵方面，都接近 V0 的軌跡。

遷移目標 vLLM V1 是對 V0 引擎進行了大幅度的重寫。因此，我們的遷移目標刻意設定得非常明確：驗證 V1 回傳的 rollout logprobs 形式符合訓練器的預期；針對 V0 參考基準重新運行相同的工作負載；僅在後端一致性恢復後，才評估目標層面的變更。

最初的明顯症狀出現在：clamp_log_ratio_new_old_indicator、kl_new_old、熵、獎勵。這些指標來自於 GSPO 訓練運行，這是本次實驗使用的目標。同樣類型的失配問題也可能出現在 PPO、GRPO 或任何將 rollout 端 logprobs 視為優化目標一部分的線上強化學習系統中。

最初的 V1 運行清楚地顯示了這個問題。訓練器端的 logprobs 和獎勵在訓練初期就偏離了 V0 參考基準。圖 2. 訓練器在更新期間計算的當前策略 logprobs（左）和獎勵（右）。最初的 vLLM V1 運行（紅色）與 vLLM V0 參考基準（藍色）分離。

相同的模式也出現在訓練器指標中。在初步比較中，裁剪率是最容易判讀的訊號。圖 3. vLLM V0 參考基準（藍色）和最初的 vLLM V1 嘗試（紅色）的訓練器端指標。裁剪率追蹤 rollout/訓練器策略的差距；熵和獎勵顯示該差距如何傳播到訓練中。

失敗模式 我們將可能的原因分為三個層次：語義不匹配：後端回傳的 logprobs 相對於訓練器預期的含義不同。推論路徑不匹配：後端對快取、排程或請求處理使用了不同的運行時預設值，導致相同的提示詞遵循不同的執行路徑。目標不匹配：強化學習目標需要針對剩餘的過時程度或後端不匹配進行修正。

我們最初過早地懷疑第三類問題。有用的診斷來自於首先將前兩類視為後端行為問題並排除它們。V1 後端修正 Logprob 語義 第一個問題是語義上的。vLLM V1 預設從原始模型輸出回傳 logprobs，這是在 logits 後處理（例如溫度縮放、懲罰和 top-k/top-p 過濾）之前。

PipelineRL 預期從取樣器使用的已處理分佈中獲取 logprobs。所需的設定是：logprobs-mode=processed_logprobs。這消除了 rollout logprobs 中明顯的平均偏移。訓練曲線相對於已知良好的參考基準仍然顯示出差距，因此下一個問題必然出現在推論路徑中。

策略比率圖直接顯示了這一點。一旦 V1 啟用 processed_logprobs，所有三次運行的平均策略比率都極其接近 1.0。這確立了平均偏差的修正。剩餘的不匹配則體現在裁剪率、KL 散度、熵和下游訓練行為中。圖 4. vLLM V0 參考基準（藍色）、最初的 vLLM V1 運行（紅色）和修正後的 vLLM V1 運行（綠色）的 rollout/訓練器策略比率與 1.0 的每步偏差，放大 10,000 倍。

運行時預設值 早期的 V1 運行將引擎版本與 V1 運行時預設值混用：前綴快取 (prefix caching)，在早期運行中未設定，因此應用了 vLLM 0.18.1 的預設值；非同步排程 (async scheduling)，在早期運行中未設定，因此應用了 vLLM 0.18.1 的預設值；一個透過啟動時 kwarg 傳遞設定的臨時 disable-cascade-attn 覆寫，它位於已提交配置中的等效配方之外。

為了實現等效運行，我們明確了這些選擇：vllm_config: use_v1: true vllm_kwargs: logprobs-mode: processed_logprobs enable-prefix-caching: false async-scheduling: false。

前綴快取值得單獨說明。它通常是一種針對固定模型狀態的、保持正確性的推論優化。在這種線上強化學習設定中，相對於 V0 參考路徑，它是 V1 獨有的快取生命週期和重用差異。執行器還處理重複的前綴、並行請求、非同步排程和即時權重更新。當快取策略忽略權重更新邊界時，前綴快取命中可能會重用在權重更新之前計算的狀態。

禁用前綴快取消除了等效比較中一個 V1 獨有的自由度。即時權重更新 權重同步也必須符合線上強化學習的更新模型。一種選擇是讓 V1 比 V0 更嚴格，在每次更新時清空請求並清除快取。這將回答一個獨立的問題。我們首先需要驗證 V1 是否能匹配現有的 V0 行為。

V0 實際上的做法更接近於：在引擎邊界處阻塞執行；載入新權重；在沒有明確快取狀態失效的情況下恢復。最接近的 V1 對應做法是：await engine.pause_generation(mode="keep", clear_cache=False) await engine_client.collective_rpc_async("receive_weight_update", args=(request.model_dump_json(),),) await engine.resume_generation() 有兩個細節很重要：mode="keep" 比 wait 或 abort 更接近舊的即時更新模型；clear_cache=False 匹配 V0 包裝器的行為，即在更新時保持快取狀態不變。

延遲是一個有用的運行時診斷指標。最初的 V1 路徑在訓練後期比修正後的 V1 運行帶有更持久的延遲。圖 5. rollout 伺服器中的權重落後訓練器策略的步數，適用於 vLLM V0 參考基準（藍色）、最初的 vLLM V1 運行（紅色）和修正後的 vLLM V1 運行（綠色）。

剩餘的差距：fp32 lm_head 上述 V1 後端修正解決了明顯的遷移問題，但最終的一致性仍需要匹配用於計算 logits 的數值路徑。訓練器使用 fp32 lm_head 進行最終投影。rollout 後端必須匹配該行為。MiniMax-M1 技術報告中出現了一個密切相關的問題：他們的強化學習運行顯示訓練/推論 token 機率不匹配，他們將其追溯到語言模型輸出頭，並透過以 fp32 精度計算該頭來解決。

這很重要，因為強化學習更新直接消耗 token logprobs。logits 中的微小變化可能會在策略比率、KL 散度及裁剪中變得明顯。因此，最終投影的精度是線上強化學習正確性表面的一部分。ScaleRL 論文後來將 fp32 logits/頭計算納入其強化學習配方中，並將其作為大規模強化學習的一個有用設計選擇進行消融研究。

包含 fp32 lm_head 路徑後，獎勵提供了一個最終一致性結果的簡潔視圖。在圖 6 中，最終的 V1 運行追蹤 V0 參考基準；最初的 V1 嘗試產生了明顯不同的獎勵曲線。圖 6. vLLM V0 參考基準（藍色）、最初的 vLLM V1 嘗試（紅色）以及包含 fp32 lm_head 路徑的最終 vLLM V1 運行（綠色）的獎勵。

包含 fp32 頭後，最終的 V1 運行追蹤 V0 參考基準。消融研究 這些負面結果很重要，因為它們排除了常見的解釋。僅處理 processed_logprobs：修正了語義 logprob 錯誤；訓練不匹配仍然存在。批次不變性：在單獨的測試中，不匹配仍然存在，且伴隨更高的延遲、更高的裁剪率和 NCCL 複雜性。

將首次 V1 運行視為公平基準：首次 V1 運行啟用了多個僅限 V1 的預設值，因此這是一個混淆的遷移比較。為何我們優先修正後端正確性 諸如截斷重要性取樣、重要性比率重新加權及相關方法等目標層面的修正都是有用的工具。如果 rollout 是有意過時的、非同步生成的，或者由一個無法與訓練器端策略等效的後端產生，那麼某種形式的修正通常是正確的做法。

這裡的首要問題是推論的正確性。遷移到 V1 後，rollout 後端回傳的 logprobs 和運行時行為打破了訓練器的假設。此時添加目標層面的修正將會混淆兩個問題：推論後端是否產生了正確的 logprobs？在 logprobs 正確的情況下，目標是否仍需要離策略或非同步修正？

這些問題需要分開處理。否則，目標層面的修正可能會彌補損壞的推論後端行為，這會使訓練曲線更難以解釋。目前的目標仍有改進空間。在推論一致性恢復後，下一步的改進是常見的非同步/離策略清理：保留 rollout 時的明確行為策略 logprobs；在優化時重新計算訓練器端的舊策略 logprobs；將後端不匹配修正與策略更新比率分開；追蹤修正項的 ESS 等診斷指標以及總體訓練器指標。

這次遷移的主要教訓更為明確：首先修正後端正確性，然後再針對剩餘的不匹配添加修正。