grpo-rlvr-training

GRPO & RLVR トレーニング

このスキルは、対象の振る舞いに検証可能な合否シグナルがあるために、finetuning-method-selection がすでにここへルーティングしてきたことを前提としています。デモンストレーション（lora-qlora-recipes）や選好ペア（preference-optimization）ではありません。以下では、RL が適切なツールとなるのはどのような場合か、リファレンスレシピ、必須の報酬検査ゲート、そしてベースレシピが期待どおりに動作しない場合に GRPO のバリアントをどのように選ぶかを説明します。

入力: ルーティングの判断（GRPO による RLVR）と、対象タスクのための検証器（コード実行環境、テストスイート、スキーマチェッカー、またはグレーダー）。 出力形式: 検証済みの GRPO 設定 — references/grpo-memory.md の kwarg 値と references/reward-functions.md の報酬関数であり、自由形式のアドバイスではありません — を llm-finetuning-training-engineer が直接利用します。

RL が適用される場合

GRPO+RLVR が成果を生むのは、タスクの成功がアルゴリズム的に検査可能である場合だけです — ユニットテストが通る、パーサーが出力を受け入れる、ツール呼び出しが期待されるスキーマに一致する、数学の解答が正解と一致する、といった場合です。出力の採点に人間の判断や主観的なルーブリックが必要なら、それはまず eval ハーネスとジャッジ調整の問題です — eval-harness-first を参照してください — RL にすぐ進む理由にはなりません。

GRPO の実行を始める前に、モデルが対象タスクですでに時々成功できることを確認してください。RL は、すでに機能しているサンプルへと重み付けを変えることで既存の能力を鋭くするものであり、能力をゼロからインストールするものではありません。

• モデルが多くのサンプルで低温度でも一切成功しない場合: そのギャップはフォーマットかタスク理解であり、方針の洗練ではありません。まず SFT（lora-qlora-recipes）に戻り、ベースの成功率がゼロでなくなってから、このスキルに戻ってきてください。
• モデルが時々、一貫せずに成功する場合: これが GRPO のスイートスポットです — 以下の「レシピ」に進んでください。

プラグイン全体に共通するルール: 好みには DPO、推論には GRPO。 シグナルが 2 つの許容可能な出力の間の選好であるなら、それはこのスキルではなく preference-optimization です。

レシピ

リファレンスレシピは、vLLM による生成を利用する TRL の GRPOTrainer です:

from trl import GRPOConfig, GRPOTrainer

grpo_args = GRPOConfig(
    output_dir="./outputs-grpo",
    use_vllm=True,
    vllm_mode="colocate",       # single GPU; "server" for multi-GPU
    num_generations=8,          # floor — fewer starves the group-relative baseline
    learning_rate=5e-7,         # settled range for GRPO
    beta=0.01,                  # KL coefficient vs the reference policy
    per_device_train_batch_size=8,
    gradient_accumulation_steps=4,
    bf16=True,
    logging_steps=10,
    seed=3407,
)

trainer = GRPOTrainer(
    model=SFT_CHECKPOINT,
    args=grpo_args,
    reward_funcs=[format_reward, correctness_reward],   # references/reward-functions.md
    train_dataset=prompts,       # prompt-only — GRPO generates its own completions
    processing_class=tokenizer,
)

trainer.train()

• vllm_mode="colocate" は生成とトレーニングを同じ GPU 上で実行します — シングル GPU マシンでのデフォルトです。
• vllm_mode="server" は別個の vLLM サーバープロセスを指定するもので、マルチ GPU のための経路です — 生成とトレーニングが同じデバイスを奪い合いません。
• num_generations ≥ 8 は下限であり、提案ではありません。GRPO のアドバンテージ推定はグループ平均に対する相対値であり、プロンプトあたり 8 サンプル未満ではベースラインがノイズを含みます。
• 報酬は複合的です — フォーマット報酬（出力がパースできたか、または必要な構造に一致したか）と正しさ報酬（解答が検証できたか）を組み合わせます。整形されているが誤った解答と、整形されていない解答は同じスコアになるべきではありません。正しさだけではそのシグナルが失われます。
• learning_rate=5e-7 と beta=0.01 が落ち着いた出発点です。逸脱するのは、ベース実行が安定し報酬検査（後述）を済ませてからにしてください。

このレシピの対象サイズクラス別のメモリ見積もり: references/grpo-memory.md。

検査ルール

実際のトレーニング実行を開始する前に、50〜100 件のサンプル出力に対して報酬関数を実行し、その結果を手作業で読んでください。 これはゲートであり、一度きりの健全性チェックではありません。

報酬関数の判断がそのサンプルに対する人間の読み取りと一致しない場合は、まず報酬関数を修正してください。検査されていない報酬に対してトレーニングしたり、黙って誤った対象をスコアリングしている報酬を補償するためにハイパーパラメータを調整したりすることは、実行が報酬ハッキングに至る道です。モデルは誤ったターゲットに向かってきれいに最適化し、それはトレーニングループのバグとしては表面化しません。

この検査は /finetune のフェーズ 1 ゲート入力です。ここで壊れた報酬関数を捉えるのと同じ 50〜100 件の読み取りが、そのコマンドが GRPO ブリーフを進める前にチェックする内容です。

検査対象となる完全な報酬関数の実装 — 完全一致、スキーマ検証、ユニットテスト実行、長さペナルティのラッパー、および報酬としてのルーブリック判定パターン: references/reward-functions.md。

バリアントの選択

上記の基本レシピがデフォルトです。バリアントに手を伸ばすのは、特定の失敗モードが現れたときだけであり、予防的に行うものではありません:

失敗モード	バリアント	理由
エントロピー崩壊 / 長い思考連鎖の退化	DAPO	クリップ境界を分離し、長い推論トレースでの探索を過度に正則化する KL ペナルティを緩和します
品質に関係なく報酬または出力長が増加する傾向	Dr.GRPO	GRPO の長さ正規化バイアスを取り除き、報酬が完了長ではなく正しさを追跡するようにします
混合エキスパートモデルのトレーニング	GSPO	重要度サンプリング比をトークン単位ではなくシーケンスレベルに移動します — トークン単位の比は MoE ルーティングで不安定なため、ここでは GSPO が必須であり、オプションではありません

まずプレーンな GRPO から始めてください。特定の症状 — 長い CoT でのエントロピー崩壊、長さと報酬の相関、または MoE の不安定性 — を監視し、それから初めて上記の一致するバリアントに差し替えてください。基本レシピが実際にその失敗モードを示す前に、バリアントを事前選択しないでください。

VLM RL は参照専用です

ビジョン言語 RL は v1 ではこのプラグインによって実行されません — ここでは実行可能なパスとしてではなく、文脈のために文書化されています。ツールは ms-swift と EasyR1 派生のフォークにまたがって断片化されており、ワンラインの TRL コマンドはまだありません。そして VLM に適用された素朴なテキストのみの GRPO は、画像を無視してテキスト推論トレースを最適化することで報酬ハッキングに至る傾向があります — モデルは入力を眺めることなく、もっともらしく聞こえることを学びます。VLM RL の実行は、このスキルのサポート対象レシピの外にあるリサーチスパイクであり、上記のレシピのバリアントではありません。

参照

• references/reward-functions.md — 完全な Python 報酬関数（完全一致の正しさ、スキーマ検証、ユニットテスト実行、長さペナルティのラッパー、および報酬としてのルーブリック判定パターン）。トレーニング実行の前に検査ルールの下で検査するためのものです。
• references/grpo-memory.md — ターゲットサイズクラス別のメモリサイジング、vLLM スリープモードとオプティマイザ状態の戦術、Unsloth の長文脈 RL チャンキング、およびデコード中心のロールアウトに対する DGX Spark の帯域幅の注意点。

関連スキル: finetuning-method-selection は、検証可能な合否シグナルが存在するとここにルーティングします。preference-optimization は、検証可能な報酬ではなく選好ペアのための兄弟スキルです。eval-harness-first は、純粋にコードでチェックできないあらゆる報酬に対する判定キャリブレーションを扱います。DGX Spark では、このスキルのメモリ表が扱わないメモリ/熱の修復ラダーについて、インストールされている場合は dgx-spark-ops プラグインのスキルに従ってください。