vLLM V0 から V1：RL における修正前の正しさの重視

[記事一覧に戻る](https://huggingface.co/blog) - 移行の目的 - 失敗モード - V1 バックエンドの修正：対数尤度（logprob）の意味論 - ランタイムのデフォルト値 - 実行中の重み更新 - 残されたギャップ：fp32 lm_head - アブレーション実験 - なぜ最初にバックエンドの正しさを修正したのか [PipelineRL](https://huggingface.co/blog/ServiceNow-AI/github.com/ServiceNow/PipelineRL/) は、ロールアウト生成のための推論エンジンとして vLLM を使用しています。推論エンジンはトークンをサンプリングしてトークンの対数尤度（logprobs）を返しますが、トレーニング側はこれらの対数尤度を使用してポリシー比、KL 発散、クリップ率、エントロピー、および報酬を計算します。これらの対数尤度の計算方法に任何らかの不一致があると、トレーニングのダイナミクスが変化してしまいます。これが、vLLM V0 から V1 への移行中に排除する必要があった「トレーニングと推論の不整合」です。 **要約。** vLLM V1 は、以下の4つの点を修正したことで、私たちが参照していた vLLM V0 と一致しました：処理済みのロールアウト対数尤度、V1 固有のランタイムデフォルト値、実行中の重み更新パス、および最終的な射影に使用される fp32 lm_head です。私たちは RL の目的関数を変更する前に、バックエンドの動作を修正しました。 参照実験では vLLM 0.8.5 を使用し、V1 の実験では vLLM 0.18.1 を使用しました。図 1 に最終結果を示します。赤色のラインは初期の V1 試行であり、緑色のラインは後述する修正を施した後の最終的な V1 実行です。 ![image](https://cdn-uploads.huggingface.co/production/uploads/61f750055596aa721ce68efe/2Q2pkNtiYPrlLVLoH51dO.png) 図 1. vLLM V0 リファレンス（青）、初期の vLLM V1 試行（赤）、および修正後の最終的な vLLM V1 実行（緑）におけるトレーナー側のメトリクス。これには fp32 lm_head も含まれます。最終的な V1 実行は、クリップレート、KL 距離、エントロピー、報酬のすべての項目において V0 の軌道にほぼ戻っています。 ## マイグレーション目標 vLLM V1 は V0 エンジンの大規模な書き直しです。そのため、私たちのマイグレーション目標はあえて狭く設定しました： - V1 がトレーナーが期待する形式でロールアウトの対数尤度（logprobs）を返すことを確認する - 同じワークロードを V0 リファレンスに対して再実行する - バックエンドの整合性が回復した後にのみ、目的関数レベルの変化を評価する 最初の目に見える兆候は以下の項目で現れました： - clamp_log_ratio_new_old_indicator - kl_new_old - entropy - reward これらのメトリクスは、本実験で使用された GSPO 学習ランから得られたものです。ロールアウト側の対数尤度を最適化目標の一部として扱う PPO、GRPO、またはその他のオンライン RL システムでは、同様の不一致が表面化する可能性があります。 初期の V1 実行では問題が明確に示されました。トレーナー側の対数尤度と報酬は、学習の早い段階で V0 リファレンスから乖離し始めました。 ![image](https://cdn-uploads.huggingface.co/production/uploads/61f750055596aa721ce68efe/YhRfKIEKndf4LGG9g7Ck9.png) Figure 2. Current-policy logprobs computed by the trainer during updates (left) and reward (right). The initial vLLM V1 run (red) separates from the vLLM V0 reference (blue). 同じパターンがトレーナーのメトリクスにも現れています。クリップ率（clip rate）は、初期比較において最も読み取りやすいシグナルです。 ![image](https://cdn-uploads.huggingface.co/production/uploads/61f750055596aa721ce68efe/6fQ4PVHFb_bbYMzducj1o.png) Figure 3. Trainer-side metrics for the vLLM V0 reference (blue) and the initial vLLM V1 attempt (red). Clip rate tracks the rollout/trainer policy gap; entropy and reward show how that gap propagates into training. ## Failure Modes 考えられる原因を 3 つの層に分類しました。 - セマンティックの不整合：バックエンドが返す logprobs（対数確率）の意味が、トレーナーが想定しているものと異なる。 - 推論パスの不整合：バックエンドがキャッシュ、スケジューリング、またはリクエスト処理において異なるランタイムデフォルトを使用するため、同じプロンプトでも実行パスが異なる経路をたどる。 - オブジェクトive の不整合：残存する古さ（staleness）やバックエンドの不整合の量に応じて、強化学習（RL）の目的関数に修正が必要となる。 当初は第 3 のカテゴリを早すぎると疑いました。有用な診断結果は、最初の 2 つをバックエンドの動作問題として扱い、まずそれらを除外することから得られました。 ## V1 Backend Fixes ## Logprob Semantics 最初の問題は意味論的なものでした。vLLM V1 はデフォルトで、温度スケーリングやペナルティ、top-k/top-p フィルタリングなどのロジット後処理の前に、生のモデル出力からログ確率（logprobs）を返します。PipelineRL は、サンプラーが使用する処理済みの分布からのログ確率を期待していました。 必要な設定は以下の通りでした： - logprobs-mode=processed_logprobs これにより、ロールアウトのログ確率における明白な平均オフセットが解消されました。しかし、トレーニング曲線はまだ既知の良好な参照値とのギャップを示していたため、次の問題は推論パスにあるはずでした。 ポリシー比のプロットはこれを直接的に示しています。V1 で processed_logprobs を有効にした後、すべての 3 つの実行において平均ポリシー比が 1.0 の非常に近くに中心化されます。これが平均バイアスの修正确立了です。残りの不整合は、クリップ率（clip rate）、KL 発散、エントロピー、および下流のトレーニング挙動に現れます。 ![image](https://cdn-uploads.huggingface.co/production/uploads/61f750055596aa721ce68efe/K0PQyxwunQUipAXv9Iy1n.png) 図 4. vLLM V0 参照（青）、初期の vLLM V1 実行（赤）、修正された vLLM V1 実行（緑）における、ロールアウト/トレーナーのポリシー比が 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 プレフィックスキャッシングには別途注記が必要です。これは通常、固定されたモデル状態に対する正準性を保持する推論最適化です。今回のオンライン RL 設定では、V0 リファレンスパスとの比較において、キャッシュの寿命と再利用が V1 のみで異なる点となりました。また、アクターは繰り返されるプレフィックス、並行リクエスト、非同期スケジューリング、および実行中の重み更新も処理していました。 プレフィックスキャッシュヒットでは、キャッシュポリシーが重み更新の境界を無視する場合、更新前に計算された状態を再利用できます。プレフィックスキャッシングを無効化することで、比較対象から V1 固有の自由度の一つを排除しました。 ## Inflight Weight Updates (実行中の重み更新) 重みの同期も、オンライン RL の更新モデルに合わせる必要がありました。一つの選択肢は、V0 よりも厳格な V1 を実装し、すべての更新時にリクエストを排水してキャッシュをクリアすることです。これは別の問いに答えることになります。まず、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() 2 つの重要な詳細があります: - mode="keep" は、wait や abort に比べて、古いインフライト更新モデルにより密接に一致します。 - clear_cache=False は、V0 のラッパー動作に一致しており、これは更新時にキャッシュされた状態をそのまま残すものです。 ラグは有用なランタイム診断でした。初期の V1 パスは、修正された V1 実行よりもトレーニング後半においてより永続的なラグを示します。 ![image](https://cdn-uploads.huggingface.co/production/uploads/680ba1729f7688275d2ce0f4/XWXONkgJtznG09PVLFCAl.png) 図 5. ロールアウトサーバー内の重みがトレーナーポリシーより遅れているステップ数。vLLM V0 リファレンス（青）、初期の vLLM V1 実行（赤）、修正された vLLM V1 実行（緑）。 ## 残りのギャップ：fp32 lm_head 上記の V1 バックエンドの修正により明白な移行問題は解消されましたが、最終的な整合性を得るには、ロジットを計算するために使用される数値パスを一致させる必要がありました。トレーナーは最終的な投影に fp32 の lm_head（言語モデルヘッド）を使用していました。ロールアウトバックエンドもこの動作に合わせる必要がありました。 非常に類似した問題が [MiniMax-M1 技術報告書](https://arxiv.org/abs/2506.13585) に現れています：同社の RL 実行ではトレーニングと推論のトークン確率の不整合が見られ、これは LM 出力ヘッドに起因するものとして特定され、fp32 でヘッドを計算することで修正されました。 これは、RL（強化学習）更新がトークンの対数確率を直接消費するため重要です。ロジットの小さな変化は、ポリシー比、KL 散逸、クリッピングにおいて顕在化します。したがって、最終的な投影精度は、オンライン RL における正しさの範囲の一部となります。 [ScaleRL paper](https://arxiv.org/abs/2510.13786) では、後に fp32 ロジットおよびヘッド計算をその RL レシピの一部として含め、大規模 RL における有用な設計選択としてアブレーション（除去実験）を行っています。 fp32 の lm_head パスを含めることで、報酬は最終的なパリティ結果のコンパクトな視点を提供します。図 6 では、最終的な V1 ランが V0 リファレンスを追跡しており、初期の V1 試行では明確に異なる報酬曲線が生じています。 ![image](https://cdn-uploads.huggingface.co/production/uploads/680ba1729f7688275d2ce0f4/oCuXYiTLSl6-jPJLBzWoU.png) 図 6. vLLM V0 リファレンス（青）、初期の vLLM V1 試行（赤）、および fp32 lm_head パスを含む最終的な vLLM V1 ラン（緑）に対する報酬。fp32 ヘッドを含めることで、最終的な V1 ランは V0 リファレンスを追跡します。 ## アブレーション実験 否定的な結果は重要です。なぜなら、それらは一般的な説明を排除するからです。 - processed_logprobs 単独：意味論的な対数確率のバグは修正されましたが、トレーニングの不整合は残りました。 - バッチ不変性：別のテストでも不整合が残っており、ラグが増大し、クリップ率が上昇し、NCCL（NVIDIA Collective Communications Library）に複雑さが生じました。 - 最初の V1 ランを公平なベースラインとして扱うこと：最初の V1 ランでは複数の V1 固有のデフォルトが有効化されていたため、これは交絡した移行比較でした。 ## なぜ最初にバックエンドの正しさを修正したのか 目的関数側の補正、例えば截断された重要性サンプリングや、重要性比の重み付け、および関連する手法は有用なツールです。ロールアウトが意図的に古く設定されている場合、非同期で生成される場合、またはトレーナー側のポリシーとの等価性が保証されないバックエンドで生成される場合は、何らかの形の補正を追加することが適切な対応となることが多いです。 ここで最初の課題は推論の正確性でした。V1 へ移行した後、ロールアウトバックエンドが返すログ確率と実行時挙動が、トレーナー側の前提を崩壊させました。その時点で目的関数側の補正を追加すると、2 つの異なる問いが混同されてしまいます： - 推論バックエンドは正しいログ確率を生成しているか？ - 正しいログ確率が得られる場合でも、目的関数にはオフポリシーまたは非同期の補正が必要か？ これらの問いは分離する必要があります。そうでなければ、目的関数側の補正が破損した推論バックエンドの挙動を誤って補償してしまい、学習曲線の解釈が困難になります。 現在の目的関数はまだ改善の余地があります。推論の整合性が回復された後、次の改善は通常の非同期/オフポリシーの整理となります： - ロールアウト時点での明示的な行動ポリシーのログ確率を保持する - 最適化時点でトレーナー側の旧ポリシーのログ確率を再計算する - バックエンドの不整合に対する補正と、ポリシー更新比率を分離する - 補正項に対して ESS（有効サンプル数）などの診断指標を、集約されたトレーナーメトリクスと共に追跡する この移行から得られる主な教訓はより限定的です：まずバックエンドの正確性を修正し、その後残る不整合に対する補正を追加すること。

vLLM V0 から V1：RL における修正前の正しさの重視

背景や根拠まで確認しますか？

関連記事

調べる

選ぶ

サイト