SDPO（Self-Distilled Policy Optimization）を検討する：スカラー報酬の外側にあるテキストフィードバックをどう使うか

SDPO が埋めようとしているのは報酬の粒度の粗さである

コードや数学のような検証可能な領域で LLM をポストトレーニングするとき、RLVR は試行ごとにスカラー報酬を1つ与える。正解か不正解か、それだけである。README はこの状態を credit-assignment bottleneck と呼び、どのトークンが失敗の原因だったのかを特定できないことを問題視している。ところが現実の環境はもっと饒舌で、ランタイムエラーやジャッジの講評という形で「なぜ失敗したか」をテキストで返してくる。SDPO はこの設定を Reinforcement Learning with Rich Feedback（RLRF）と名付け、そのテキストを学習信号に変換する方法を提案する。対象読者は、RLVR の学習曲線が頭打ちになる理由を報酬設計ではなくフィードバックの使い方に求めたい研究者と、検証可能タスクのポストトレーニングを自前で回しているエンジニアである。

自己教師をどう作るか：フィードバック条件付きの次トークン予測

仕組みの中心は外部教師も明示的な報酬モデルも使わない点にある。README の説明では、SDPO は現在のモデルをフィードバック条件付きで動かしたものを self-teacher とみなし、そのフィードバックを踏まえた次トークン予測をポリシーへ蒸留し直す。モデルが文脈内で自分の誤りを後から特定できる能力に依存している、というのが著者らの主張である。興味深いのは、フィードバックが乏しい環境での振る舞いで、README は高報酬のロールアウトそのものを暗黙のフィードバックとして再利用し、密な監督信号を作ると述べている。つまり入力は「プロンプト、モデル自身の試行、そして環境が返したテキスト（あるいは高報酬の試行そのもの）」であり、出力はポリシーの更新である。学習信号の階層についても README は logit > token > sequence という3段階の粒度に触れており、系列単位のスカラー報酬より細かい場所に勾配を届ける設計だと読める。

推論時にも蒸留する：テスト時自己蒸留という使い方

SDPO は学習時だけで完結しない。README には test-time self-distillation という節があり、複数の候補解を生成し、その中から高品質な応答を選び、それを実演として再利用することで推論時に反復的に出力を洗練させる、と説明されている。追加の学習なしで難しい推論タスクの成績が上がるという主張である。ここは評価が分かれる部分で、候補生成の予算を増やせば解が見つかる確率が上がるのは、探索の効果なのか蒸留の効果なのか切り分けが難しい。README の図の説明でも「base model も multi-turn interaction も解けなかった問題を SDPO が解く」とだけ書かれ、どの程度が自己蒸留由来なのかは示されていない。この点は導入前に自分のタスクで確認すべき論点として残る。

GH200 クラスタ向けの Docker 経路と、ローカルに入れる経路

インストールは2通り用意されている。HPC 向けは Dockerfile.gh200 を使う経路で、NGC の vLLM コンテナをベースにしている。README のコマンドは podman build . -f Dockerfile.gh200 -t sdpo-gh200 でイメージを作り、enroot import -x mount -o sdpo-gh200.sqsh podman://localhost/sdpo-gh200:latest でクラスタ配布用の squashfs に変換する流れである。このとき requirements-gh200.txt が使われ、requirements-full.txt のピン留め版から torch、vllm、flash-attn、xformers、triton を除いた構成になる。これらはコンテナに既に入っているためである。ローカルに入れる場合は PyTorch を先に固定する。Ampere か Hopper（RTX 30/40、H100）なら pip install torch==2.5.1 torchvision torchaudio --index-url https://download.pytorch.org/whl/cu124、Blackwell（RTX 50、RTX PRO 2000 Blackwell）なら torch==2.7.0 と cu128 のインデックスを指定する。その後に SDPO 本体と依存を入れる。システム要件は Linux（SLES 15 SP5 と Ubuntu 22.04 で確認済みと記載）、NVIDIA GPU、Python 3.12（3.12.3 で確認）である。

README が答えを出していない部分：データ形式とハイパーパラメータ

ここは正直に書いておく。提供された README には、学習を実際に起動するコマンド、設定ファイルのパス、データセットのスキーマが含まれていない。フィードバックのテキストをどのキーで、どの形式で渡すのかは、Usage Documentation の節に委ねられている。つまり、この記事の材料だけでは学習ジョブを再現できない。また、README の実験記述は 4 基の NVIDIA GH200 を1ノードで使い、初期化と検証を含めて1回あたり約6時間かかると述べており、手元の GPU で気軽に試せる規模ではない。requirements-full.txt のピン留めがどのパッケージを固定しているかも、この抜粋からは分からない。導入を検討するなら、リポジトリの Usage Documentation と requirements ファイルを直接読むところから始める必要がある。

GRPO との違いは、報酬の外にある情報を捨てるか拾うかである

README が比較対象として繰り返し挙げるのは GRPO である。違いは明確で、GRPO は検証可能な報酬のスカラー値だけを学習信号にするのに対し、SDPO は環境が返すテキストや高報酬ロールアウトを self-teacher の条件付けに使う。実験設定も対照的で、README によれば SDPO と on-policy の GRPO は生成バッチあたり1回の勾配ステップを行うのに対し、GRPO はオフポリシーのミニバッチを4回回す。つまり SDPO は1バッチから得られる情報を蒸留で厚くする方向に寄り、GRPO は同じデータを複数回反復して使う方向に寄っている。どちらが優れているかはタスク次第で、フィードバックが正誤の1ビットしかない環境では SDPO の自己教師に与える条件がほぼ空になり、優位性は出にくいと考えられる。README 自身も、フィードバックが疎な場合については高報酬ロールアウトの再利用という代替経路を用意している点を踏まえて読みたい。

ライセンスと保守の見通し

ライセンスは Apache-2.0 で、特許条項を含む比較的緩やかな条件である。研究コードとして公開されており、リポジトリはアーカイブされていない。ただし取得できた範囲ではリリースが存在せず、バージョン番号で固定して追従する手段がない。依存は requirements-full.txt でピン留めされており、この固定を外すと NGC コンテナとの整合が崩れる可能性がある。PyTorch のバージョンも GPU 世代ごとに 2.5.1 と 2.7.0 に分かれているため、CUDA ドライバを更新すると torch の再選択が必要になる。研究実装としては、論文の再現を目的としたスナップショットとして扱い、プロダクションの学習基盤に組み込む前提で保守コストを見積もるのは避けたほうがよい。

編集部の結論

SDPO が向くのは、コードや数学のように検証可能で、かつ失敗理由のテキストが環境から返ってくるタスクを、GH200 級の GPU ノードで回せる研究チームである。逆に、フィードバックが正誤の1ビットしかない環境や、単一 GPU で手軽に試したい用途では、README が挙げる GRPO 系のベースラインのほうが素直だ。着手前に確認すべきは、requirements-full.txt のピン留めが自分の CUDA ドライバと噛み合うか、そして自分のデータセットが「なぜ失敗したか」をテキストで返せる形式かどうかの2点である。

公式情報源

1. Issues
2. lasgroup/SDPO on GitHub
3. License: Apache-2.0
4. Project website
5. README