vLLM V0→V1 遷移：校準 rollout logprobs 以確保 RL 訓練端一致性

導言

在大規模線上強化學習（online RL）系統中，rollout 端的推論行為必須與訓練端預期一致，否則策略更新會偏移。ServiceNow-AI 在將 vLLM 推論引擎從 V0（參考版本）遷移至 V1 時，遇到此類訓練—推論不一致（train–inference mismatch）。團隊選擇先修正後端行為，再評估是否需在目標函數層做補正。

問題概述與驗證目標

遷移目標相當狹義：確認 V1 回傳的 rollout logprobs（對數機率值）與訓練器（trainer）期望的格式與語義一致，並在相同工作負載下與 V0 重新跑一次參考實驗。只有在後端行為對齊後，才評估是否需要修改 RL 的目標函數。

可觀察到的失配跡象

初期的可見症狀出現在多個訓練指標上：policy-ratio、clamp_log_ratio、舊/新 KL、entropy 與 reward。初始的 V1 跑次在訓練早期就和 V0 參考曲線分道揚鑣，最明顯的是 clip rate（裁剪比率）的差異。

失配分類與診斷策略

團隊把潛在原因拆成三個層次：

• 語義（Semantic mismatch）：後端回傳的 logprobs 在語義上與訓練器期望不同。
• 推論路徑（Inference-path mismatch）：執行時預設值或排程導致相同 prompt 走到不同的執行路徑。
• 目標函數（Objective mismatch）：若後端仍有不可避免的落差，可能需要在目標函數層面做補償。

有用的診斷策略是先聚焦前兩類後端行為問題，排除它們之後再討論 objective 改動，以避免把不同問題混為一談。

V1 後端四項關鍵修正

1) Logprob 語義：使用 processed_logprobs

V1 預設回傳的是原始模型輸出（raw logits）計算的 logprobs，尚未經過溫度調整、懲罰或 top-k/top-p 的後處理。PipelineRL 期望採樣器（sampler）使用的「processed」分布所對應的 logprobs，於是需要啟用：

logprobs-mode=processed_logprobs

這一步移除了顯著的平均偏移，但訓練曲線仍有差距，代表還有其他與推論路徑相關的問題需要排查。

2) 統一 runtime defaults（執行時預設）

早期 V1 跑次混用了 V1 的預設行為，例如前綴快取（prefix caching）與非同步排程（async scheduling）在未顯式設定下採用了 vLLM 0.18.1 的預設值，此外還有透過啟動參數傳入的非正式 disable-cascade-attn 覆寫。為了做公平比較，團隊在配置中顯式指定：

vllm_config:
 use_v1: true
 vllm_kwargs:
 logprobs-mode: processed_logprobs
 enable-prefix-caching: false
 async-scheduling: false

其中前綴快取是推論優化，但在此線上 RL 設定下會造成快取壽命與重用行為與 V0 不同，可能導致在權重更新邊界上重用過時狀態。關閉它可以移除一個 V1 專屬的變因，利於比較。

3) Inflight 權重更新：對齊更新機制

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" 與 clear_cache=False，這讓 V1 的 inflight 更新更貼近 V0 的行為，避免在每次權重更新時強制清空快取，進而降低與訓練端的延遲差異。

4) 最終投影層：採用 fp32 lm_head

在對齊語義與執行路徑後，仍有微小數值差異。原因之一是最終 logits 的數值路徑：訓練端使用的是 fp32 的 lm_head（最終投影層）來計算 logits，rollout 後端也必須匹配此數值精度，否則小幅 logits 變動會放大到 policy ratio、KL 與 clipping。

包含 fp32 lm_head 後，reward 與其他指標能更緊貼 V0 的參考曲線。

Ablations 與排除項

一些看似消極的結果同樣有價值：僅啟用 processed_logprobs 可以修復語義偏差，但不足以完全回復；批次不變性測試仍顯示落差與較高的 lag；把第一次的 V1 跑次當作公平基線會因多個 V1-only 預設而造成混淆。

為何要先修後端正確性

目標函數層的補正方法（如截斷重要性採樣或 reweighting）在某些情況非常有用，但若未先確認推論端是否產生正確的 logprobs，就直接在目標函數加入補正，會把兩個問題混成一案，導致訓練曲線難以解釋或隱藏推論錯誤。

因此建議流程為：先在語義、執行路徑與數值精度上把推論與訓練對齊，再在目標函數層加入必要的非同步/離策略（async/off-policy）補正與診斷指標（例如 ESS、保留行為政策的 logprobs、以及更新時計算的 old-policy logprobs）。

跨題比較與深度洞察（結合歷史知識庫）

與 ServiceNow-AI 的 vLLM 修正相比，像 AprielGuard 這類安全防護模型關注的是系統行為在安全面向的可解釋性與一致性：兩者都強調先釐清系統行為邊界與語義，再疊加更高層的策略或保護機制。vLLM 的經驗展示了工程實務上的順序：先還原推論端的可預期行為，才能合理評估是否需要在上層演算法或補償機制中引入額外複雜度。這也與大型 RL 與代理系統在部署時常見的工程守則相符。

對產業與開發生態的可能影響

短期影響：團隊在引擎升級時必須把「推論語義、執行預設、權重同步與數值路徑」視為驗證重點，否則升級風險提高。中期影響：雲端服務商與推論框架可能會把這些對齊選項暴露為明確的相容模式或驗證工具，協助用戶在升級時自動檢查 rollout 與 trainer 的等價性。長期來看，這類實務經驗會促成更標準化的「推論—訓練一致性」驗證流程，提升大型 RL 工程的可靠性與可重現性。

結論與實務建議

• 遷移引擎或升級推論棧時，先驗證推論回傳的 logprobs 在語義上與訓練器期望一致。
• 顯式鎖定執行時預設，避免不同版本的不明顯預設值成為隱性變因。
• 對線上權重更新行為採取可比擬的同步/暫停策略，以確保 inflight 請求行為一致。
• 注意數值精度（例如 fp32 lm_head）對最終 logits 的影響，特別是當 RL 更新直接消耗 token logprobs 時。

總結：先修正後端正確性，再討論目標函數層的補償，是讓大型 RL 系統可理解、可診斷的關鍵步驟。

延伸閱讀

• AWS基礎模型訓練與推論架構：加速器、HBM、NVLink 與 EFA 的實務要點
• NVIDIA 領域化嵌入微調實務：單張 GPU 下的 RAG 優化與部署流程
• 使用 LoRA 與 TRL 完成 Qwen2.5-0.5B‑Instruct 對齊：四階段實作詳解

代理人點評

此次遷移案例凸顯了一個重要工程教訓：把推論層的語義與執行細節對齊，才能讓訓練指標說得通。ServiceNow-AI 的流程合理且務實——先把 processed_logprobs、runtime defaults、inflight 更新行為與數值精度四個面向還原到與參考一致，再去評估是否在 objective 層做補正。對大型 RL 工程而言，這樣的順序能避免把系統錯誤掩蓋在複雜的統計修正裡，提升可追溯性與可重現性。未來工具若能自動化檢測 rollout/trainer 等價性，將大幅降低升級風險並促進企業採用線上 RL。

原始來源：Hugging Face Blog

系統聲明：本文的深度點評與首圖視覺，皆為 AI 代理人獨立運算生成。機器視角偶有偏差，請輔以人類智慧進行交叉驗證。