NVIDIA、Codex、Claude Code、Qwen Code向けGRPOトレーニングのためのトークン忠実型ロールアウトフレームワーク「Polar」を公開

言語エージェント向けの強化学習はますます複雑化しています。エージェントは現在、マルチターンのツール使用、長時間実行コンテキスト、マルチエージェントオーケストレーションを管理する必要があります。主な工学的課題は、既存のエージェントソフトウェアをトレーニングパイプラインに接続し、それらのツールの動作を妨げないことです。

NVIDIAの研究チームが発表したPolarは、研究者がエージェントハーネスを変更することなく、任意のエージェントハーネスに対して強化学習を実行できるロールアウトフレームワークです。

Polarが解決する中核的問題

「エージェントハーネス」とは、Codex CLI、Claude Code、Qwen Code、Piなどのツールを指します。これらのハーネスは、システムプロンプト、ツール形式、コンテキストエンジニアリング、エージェントがパッチを送信する方法を管理します。これらの詳細は、評価時のエージェントの動作に直接影響します。

従来のRLインフラストラクチャでは、ハーネスロジックをフレームワーク所有の環境API（通常はOpenAI Gymスタイルのenv.init()、env.step()、env.reset()）の背後に書き直す必要がありました。新しいハーネスごとに新しい統合コードが必要になり、ネイティブハーネスパスに固有の実行詳細が失われる可能性もあります。

Polarの重要な洞察は、すべてのLLMベースのエージェントがモデルを呼び出さなければならないことです。そのモデルAPI境界は、エージェント外部の共通インターフェースです。Polarはハーネス内部で統合する代わりに、その境界にプロキシを配置します。

プロキシの動作

各着信モデル要求に対して、ゲートウェイプロキシは次の4つのステップを実行します。

1. プロバイダAPIの検出——要求パスとヘッダーを使用して、Anthropic Messages、OpenAI Chat Completions、OpenAI Responses、Google generateContentスタイルの呼び出しを区別します。
2. 要求の正規化——ロール、コンテンツ部分、ツール定義、生成パラメータをローカル推論サーバーが使用するOpenAI Chat Completions形式に変換します。
3. トークンレベルデータのキャプチャ——要求メッセージ、応答メッセージ、プロンプトトークンID、サンプリングされた応答トークンID、終了理由、対数確率を保存します。
4. プロバイダ形式の返却——応答をハーネスが期待するスキーマに変換します。

ストリーミング要求の場合、Polarは非ストリーミングの上流応答を取得し、合成プロバイダ形式のストリームを発行します。これにより、サーバー送信イベントを期待するハーネスとの互換性を維持しながら、完全なトークンキャプチャを保証します。

既存のハーネスに必要な唯一の変更は、モデルのベースURLをゲートウェイに指定することです。

アーキテクチャ：ロールアウトサーバーとゲートウェイノード

Polarには2つのコアコンポーネントがあります。

ロールアウトサーバーはTaskRequestを受け入れ、それをnum_samples個の独立したセッションに拡張します。各セッションは、セッションID、タスクID、タイムアウト予算、ランタイム仕様、エージェント仕様、軌跡ビルダー、評価者、コールバックURLを持ちます。サーバーはセッションをゲートウェイノードにディスパッチし、セッション完了時にコールバックを受け入れます。

ゲートウェイノードは各セッションのライフサイクル（ランタイムの開始、ハーネスの実行、軌跡の構築、出力の評価、後片付け）を担当します。ゲートウェイはまた、そのセッションのモデル呼び出し用のプロキシエンドポイントをホストし、完了キャプチャをセッションレジストリに結び付けます。

各ゲートウェイ内では、隔離されたワーカープールがINIT、RUNNING、POSTRUNステージを処理します。有界READYバッファは、実行スロットが利用可能になるまで初期化されたランタイムを保持します。CPU負荷の高いランタイム準備と評価者プリウォームは、アクティブなGPUバインドエージェント実行をブロックすることなく、クリティカルパスから外れて実行されます。モデル呼び出しがキャプチャされた後にハーネスがタイムアウトした場合でも、ゲートウェイはPOSTRUNに入り、部分的なトレースを回復できます。

組み込み評価者には、セッション完了報酬、設定可能な出力ベース評価者、SWE-Bench/SWE-Gymハーネス評価者が含まれます。カスタム評価者はレジストリインターフェースを通じて追加できます。

Polarは現在、Dockerおよびrootless Apptainerランタイムをサポートしています。組み込みハーネスショートカットには、codex、claude_code、gemini_cli、qwen_code、opencode、piが含まれます。

軌跡再構築：要求ごと vs. プレフィックスマージ

セッション完了後、Polarはキャプチャされたモデル呼び出しから訓練可能な軌跡を再構築します。

2つの戦略があります。

要求ごとビルダーは、各モデル呼び出しを1つの独立したトレースとして扱います。個々の呼び出しに対してはロスレスですが、マルチターンセッションを断片化します。単一のコーディング問題で数百の要求ごとトレースが生成される可能性があり、下流のトレーナーの負担が増加します。

プレフィックスマージビルダーは、ハーネスセッションが追加専用の会話履歴を保持する場合に、より長いトレースを再構築します。隣接する完了間の厳密なトークンプレフィックス関係を検証することで、完了を順序付けられたチェーンに分割します。サブエージェント、コンテキスト圧縮境界、並列エージェントブランチは自然に別々のチェーンを形成します。各マージトレース内では、サンプリングされたアシスタントトークンのみが訓練可能としてマークされます。標準的な間質トークンは損失マスクゼロを受け取ります。

アブレーション結果

研究チームは、同じモデル、ハードウェア、トポロジーで両方の戦略を3つのトレーニングステップにわたってベンチマークしました。

| メトリック | 要求ごと | プレフィックスマージ | |-----------|---------|-----------------| | トレーナー更新回数 | 1,185 | 218 | | ウォールクロック時間 | 189.5分 | 35.2分 | | 高速化 | — | 5.39倍 | | 平均ロールアウトGPU使用率 | 20.4% | 87.7% |

SWE-Bench Verified結果

トレーニングでは、標準GRPOをQwen3.5-4Bベースモデルに適用しました。データセットはSkyRL-v0-293-data SWE-Gym（293タスク、1エポック、ロールアウトバッチサイズ4、プロンプトあたり16サンプル）で、Slimeトレーナーを使用しました。すべての実験で軌跡構築にプレフィックスマージを使用しました。

トレーニングロールアウト報酬の進捗（pass@1）

| ハーネス | 最初の10ステップ | 最後の10ステップ | |---------|----------------|----------------| | Codex | 9.5% | 54.5% | | Claude Code | 28.8% | 67.0% | | Qwen Code | 61.6% | 66.0% | | Pi | 61.6% | 76.2% |

SWE-Bench Verified最終スコア

| ハーネス | ベース | Polar RL | ゲイン | |---------|------|----------|--------| | Codex | 3.8% | 26.4% | +22.6 pts | | Claude Code | 29.8% | 34.6% | +4.8 pts | | Qwen Code | 34.6% | 35.2% | +0.6 pts | | Pi | 34.2% | 40.4% | +6.2 pts |

最大のゲインはCodexで達成されました。Codexは、元々そのハーネスでトレーニングされていないQwenモデルに対して、なじみのないアクションプロトコルとパッチ送信スタイルを提示します。Polarは報酬信号をCodex実行パスを流れる実際のサンプリングトークンに付加するため、GRPOは評価時にモデルが使用する動作を最適化します。ネイティブのQwen Codeハーネスでは、ベースモデルがすでに良好に調整されているため、Polarはそれでも0.6ポイントのゲインをもたらしました。

オフラインSFTデータ生成

Polarは、ランタイムを変更することなく分散オフラインデータ生成サービスとしても機能します。研究チームはこれを、8×H100サーバー（TP=8、max_model_len=32,768）上のQwen3.5-122B-A10Bを使用し、piハーネスで7つのSWE-Gymリポジトリからの1,638インスタンスに対してデモンストレーションしました。

SWE-Bench評価ハーネスがエージェントのパッチがすべてのFAIL_TO_PASSテストを解決し、すべてのPASS_TO_PASSテストをグリーンのままにすることを確認した場合のみ、軌跡がSFTコーパスに受け入れられます。

| リポジトリ | 試行回数 | 受け入れ回数 | 受入率 | |-----------|---------|------------|-------| | getmoto/moto | 343 | 184 | 53.6% | | python/mypy | 257 | 101 | 39.3% | | conan-io/conan | 71 | 27 | 38.0% | | pydantic/pydantic | 81 | 24 | 29.6% | | iterative/dvc | 219 | 45 | 20.5% | | pandas-dev/pandas | 477 | 98 | 19.7% | | dask/dask | 141 | 25 | 17.7% | | 合計 | 1,638 | 504 | 30.8% |

実行コストは約64 GPU時間でした。受け入れられた軌跡の平均は、セッションあたり104メッセージ、51アシスタントターンでした。

フレームワーク比較

| システム | 非同期RL | 非同期ロールアウトステージング | ロールアウトサービス | ハーネス非依存 | |---------|---------|---------------------------|------------------|--------------| | Polar | ✓ | ✓ | ✓ | ✓ | | ProRL Agent | ✓ | ✓ | ✓ | ✗ | | SkyRL-Agent | ✓ | ✓ | ✗ | 一部 | | PRIME-RL | ✓ | ✗ | ✗ | ✗ | | Agent Lightning | 一部 | ✗ | 一部 | 一部 | | rLLM | 一部 | ✗ | ✗ | ✗ | | OpenClaw-RL | ✓ | ✗ | ✗ | 一部 |

Polarは、この比較において4つのプロパティすべてに対してファーストクラスのサポートを提供する唯一のシステムです。

強みと限界

強み：

• ハーネスコードの変更不要——プロキシがモデルAPI境界で傍受
• プロバイダ非依存：Anthropic、OpenAI Chat、OpenAI Responses、Google API形式をネイティブサポート
• プレフィックスマージによりトレーナー更新回数を1,185から218に削減、ウォールクロック時間を5.39倍短縮
• 同じランタイムでオンラインRLとオフラインSFTデータ生成の両方に使用可能
• ハーネスネイティブRLにより、なじみのない実行パスで大きなゲイン（Codexで22.6ポイント）
• ハーネスが途中でタイムアウトした場合でも部分トレースを回復可能
• NeMo Gymとしてオープンソース公開

限界：

• 報酬設計、評価者の品質、分布シフトは研究者の責任
• ハーネスが設定可能なモデルベースURLをサポートする必要がある
• トークンレベルキャプチャは、サービススタックが信頼性の高いトークンIDと対数確率を提供することに依存
• 要求ごと戦略では、セッションレベルのノイズによる報酬ハッキングが実験で発生。セッション正規化とPRMスタイルのクレジット割り当てがロードマップに含まれる

主なポイント

• PolarはモデルAPIプロキシを介してLLMエージェントを訓練——ハーネスコードの変更不要
• Anthropic Messages、OpenAI Chat Completions、OpenAI Responses、Google generateContent APIをサポート
• Qwen3.5-4BにGRPOを適用し、4つのコーディングハーネスでSWE-Bench Verifiedを最大22.6ポイント改善
• プレフィックスマージ軌跡再構築により、要求ごとと比較して5.39倍の高速化
• 約64 GPU時間で1,638回の試行から504の受け入れSFT軌跡（30.8%）を生成。Apache-2.0で公開
• ProRL Agentを書き換え、NeMo Gym環境として登録

論文とGitHubリポジトリを参照。