vLLM V1への移行で直面する推論精度問題とその解決法
vLLM V1は大幅なアーキテクチャ刷新により、V0から移行する際に推論精度の不一致が発生する可能性があります。ServiceNow AI チームが PipelineRL での実際の移行経験から明らかにした4つの重要な修正点を解説します。
何が変わったか
vLLM V1はV0エンジンの完全な書き直しです。ServiceNow AI チームは vLLM 0.8.5 から 0.18.1 への移行で、強化学習（RL）システムにおいて深刻な推論不一致を経験しました。
PipelineRL では vLLM を推論エンジンとして使用し、トークンサンプリングとlogprob（対数確率）を取得します。トレーナーはこれらのlogprobを使ってポリシー比率、KL発散、クリップ率、エントロピー、報酬を計算します。logprobの計算方法に差異があると、訓練ダイナミクスが変化してしまいます。
初期のV1実行では、clamp_log_ratio_new_old_indicator、kl_new_old、entropy、reward の各メトリクスで明確な乖離が観測されました。これは PPO、GRPO、その他のオンライン RL システムでも発生し得る問題です。
（出典: vLLM V0 to V1: Correctness Before Corrections in RL）
V1バックエンドの4つの修正点
Logprob セマンティクスの統一
最初の問題はセマンティクスでした。vLLM V1 はデフォルトで生のモデル出力からlogprobを返しますが、これは温度スケーリング、ペナルティ、top-k/top-p フィルタリングなどの後処理前の値です。PipelineRL はサンプラーが使用する処理済み分布からのlogprobを期待していました。
必要な設定は以下です：
logprobs-mode=processed_logprobsこの設定により、ロールアウトlogprobの明らかな平均オフセットが除去されました。
ランタイムデフォルトの調整
V1固有のランタイムデフォルト設定も不一致の原因でした。V0とV1では異なるデフォルト値が設定されており、これが推論結果に影響を与えていました。
インフライト重み更新パスの修正
V1では重みの動的更新処理に変更があり、この部分の修正が必要でした。インフライト（実行中）での重み更新メカニズムがV0と異なる動作をしていたためです。
fp32 lm_head の適用
最終的な修正は、最終投影に使用される lm_head を fp32 精度で実行することでした。この精度の違いが推論結果の微細な差異を生んでいました。
これら4つの修正により、V1はV0リファレンスと一致する結果を得られるようになりました。
（出典: vLLM V0 to V1: Correctness Before Corrections in RL）
移行時の診断アプローチ
ServiceNow AI チームは問題を3つの層に分類して診断しました：
- バックエンド動作の問題: logprob計算、デフォルト設定、重み更新処理
- 統合レイヤーの問題: APIインターフェースや呼び出し方法の違い
- RLアルゴリズムの問題: 強化学習固有の実装差異
重要なのは、第3カテゴリを疑う前に、第1・第2カテゴリをバックエンド動作問題として扱い、これらを先に除外することでした。この順序立てた診断により、根本原因を特定できました。
まとめ
- vLLM V1移行時は
logprobs-mode=processed_logprobs設定でlogprob計算の一貫性を確保できる - V0とV1のランタイムデフォルト差異を特定し、明示的に設定することで推論結果の一致を実現できる
- インフライト重み更新とfp32 lm_head の適用により、強化学習システムでの訓練ダイナミクス一貫性を維持できる
- バックエンド動作問題を先に解決してからRLアルゴリズム層の調整に進むことで、効率的な移行が可能になる