在大型語言模型（LLM）的強化學習（RL）訓練過程中，推理引擎（Inference Engine）扮演著至關重要的角色。它不僅負責生成樣本（Rollout），還需要回傳每個 Token 的對數機率（Logprobs）。訓練器（Trainer）會利用這些 Logprobs 來計算策略比率（Policy Ratios）、KL 散度（KL Divergence）以及獎勵（Reward）等關鍵指標。
如果推理引擎計算 Logprobs 的方式與訓練器不一致，就會產生所謂的「訓練與推理不匹配」（Train-Inference Mismatch），直接導致訓練動態失效。本文將分享 ServiceNow 在將 vLLM 從 V0 版本遷移到 V1 版本時，如何排查並解決這類不匹配問題。
對初學者來說，最重要的一個觀念是：當你發現模型訓練效果下降時，不要急著去調整 RL 的目標函數（Objective），而應該先確認底層推理引擎回傳的數據是否正確。
推理引擎行為不一致的四個核心原因
在遷移過程中，團隊發現 V1 版本的初步運行結果與 V0 基準線（Baseline）完全脫節。經過分析，問題出在以下四個層面：
Logprobs 的語義定義（Semantic Mismatch）
在 vLLM V1 中，預設回傳的 Logprobs 是模型原始輸出（Raw Model Outputs），也就是尚未經過溫度縮放（Temperature Scaling）、懲罰項（Penalties）或 Top-k/Top-p 過濾之前的數值。然而，RL 訓練器需要的是經過處理後、實際用於採樣的機率分佈。
解決方案：將 logprobs-mode 設定為 processed_logprobs。如果忽略這一點，Logprobs 會存在明顯的平均值偏差，導致策略比率（Policy Ratio）無法維持在 1.0 附近。
運行時預設值的差異（Runtime Defaults）
V1 版本引入了許多新的效能優化預設值，例如前綴快取（Prefix Caching）和非同步調度（Async Scheduling）。在一般的推理場景中，前綴快取能加速生成，但在線上 RL（Online RL）中，模型權重會頻繁更新。如果快取策略沒有正確處理權重更新的邊界，推理引擎可能會使用舊權重計算出的快取狀態來生成新樣本，導致數據失效。
解決方案：在驗證正確性階段，明確關閉 enable-prefix-caching 和 async-scheduling，以消除 V1 獨有的變數，確保路徑與 V0 一致。
權重更新的同步機制（Inflight Weight Updates）
線上 RL 需要在生成樣本期間同步更新模型權重。如果同步方式不一致，會導致生成樣本時的模型版本與訓練器版本之間存在過大的滯後（Lag）。
解決方案：採取與 V0 類似的行為，在引擎邊界暫停生成（pause_generation），並設定 mode="keep" 與 clear_cache=False，在不強制清除所有快取的情況下載入新權重，確保權重更新的行為模式對齊。
數值精度的微小差異（fp32 lm_head）
即使上述邏輯全部對齊，訓練曲線仍有微小差距。這涉及到數值精度問題。模型最後一層的線性層（lm_head）如果使用 fp16 或 bf16，在計算 Logits 時會產生捨入誤差。由於 RL 更新對 Token 機率極其敏感，微小的 Logits 差異會被放大到策略比率和 KL 散度中。
解決方案：將 lm_head 強制設定為 fp32 精度進行計算。這也是許多大規模 RL 實作（如 MiniMax-M1 或 ScaleRL）中採用的標準做法。
工程實務建議：正確性優先於修正
在 RL 訓練中，工程師常會使用一些技巧來修正不匹配問題，例如截斷重要性採樣（Truncated Importance Sampling）或重新加權。但本文強調一個核心原則：先修復後端正確性，再處理算法修正。
如果你在推理引擎回傳錯誤 Logprobs 的情況下，嘗試透過調整目標函數來補救，你將無法分辨目前的訓練問題是因為「推理後端壞了」還是「算法需要優化」。這種混淆會讓調參過程變成一場噩夢。
正確的排查流程應為： 確認 Logprobs 的語義定義是否正確。 消除運行時預設值帶來的變數。 確保權重更新的同步邏輯一致。 對齊數值計算精度。 最後才考慮針對非同步或離策（Off-policy）特性加入算法修正。
來源：huggingface.co (vLLM V0 to V1: Correctness Before Corrections in RL)
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。