SemiAnalysis：強化学習のトレーニング効率は計算資源の拡大ではなく、スループットの整合で決まる
オープンソースの強化学習フレームワークに関する実験が、モデル能力拡大の決定的なボトルネックを解明 - 2026年6月16日
強化学習（RL）を用いたポストトレーニングは、現在の高性能AIモデルを支える「秘伝のタレ」となっているが、RLのスケールアップには莫大なコストがかかる。SemiAnalysisは、RLトレーニングにおけるシステム効率を真に左右する要因を解明するため、オープンソースのRLフレームワークを用いて広範な実験を行った。その結果明らかになった驚くべき事実は、単に計算資源を投入すればよいというわけではなく、トレーニングデータを生成する「ジェネレーター」と、そこから学習する「トレーナー」という2つの主要コンポーネント間のスループットをいかに精密に整合させるかが鍵であるということだ。
研究チームは、Qwen3-235BやGLM-5といったモデルを用い、Prime RL、slime、verlなどの異なるRLフレームワークで実験を実施した。彼らが発見した事実は、RLインフラ設計に関する従来の考え方を根本から覆すものである。
誰も語らない「キューの健全性」問題
SemiAnalysisは、RLトレーニングの効率を洗練されたメンタルモデルで定義している。それは、ジェネレーターがロールアウト（試行結果）を生成し、トレーナーがそれを消費する「キュー（待ち行列）」である。ジェネレーターが遅ければトレーナーは飢えてアイドル状態になり、逆にジェネレーターが速すぎればサンプルがキュー内に滞留する。チームはこれを「ポリシーの陳腐化（policy staleness）」と呼び、旧バージョンのモデルが生成した出力で学習を行うことで学習品質が低下する現象を指摘している。
Qwen3-235B-Thinkingを用いた最初の主要実験では、トレーナーに64基、ジェネレーションに192基のH200 GPUを投入したが、システムは深刻な「ジェネレーション・バウンド（生成能力不足）」に陥った。トレーナーは毎秒2.75サンプルのペースで消費していたものの、壁時計時間（実経過時間）の30%を待機に費やし、モデルのFLOPs利用率はわずか10.5%にとどまった。ジェネレーターはトレーナーの3倍の計算資源を使用しながら、毎秒1.95サンプルしか供給できなかった。原因は、モデルが長大な推論過程を含む回答を生成するため、回答長のばらつきが深刻なテイルレイテンシ（遅延の末尾部分）を引き起こしていたことにある。
これに対処するため、チームは「オーバーサンプリング」という手法を用い、必要な数より多くのロールアウトを並行して実行し、未完了のものを破棄することで対応せざるを得なかった。この非効率なアプローチは、RLトレーニングにおいて推論効率がいかに重要であるかを浮き彫りにしている。これは現在のRLインフラ議論において過小評価されている点だ。
モデルの挙動変化が招く「動く標的」
GLM-5を128基のH200 GPUで用いた2回目の実験では、RLシステム設計を極めて困難にする別の側面が明らかになった。それは、トレーニング中にモデルの挙動が変化し、システムの制約条件がシフトすることだ。トレーニングが進むにつれ、1ターンあたりの平均回答長とツールコールの回数は20から51へと3倍に増加した。これによりシーケンス長が伸び、ワークロードがプリフィル（入力処理）主導型へとシフトしたため、トレーニング途中で最適なインフラ構成が根本から変わってしまった。
さらに悪いことに、カリキュラムがモデルにとって簡単すぎた。問題の55%で正解率が100%に達し、すべてのロールアウトが成功してしまったのだ。すべてのロールアウトが同じ報酬を受け取ると、アドバンテージ計算の結果はゼロになり、学習シグナルが得られない。SemiAnalysisが解説するように、「正解率が100%に近いか0%に近い」場合、タスクが簡単すぎるか難しすぎることを意味し、計算資源を投じても平均報酬は横ばいのままとなる。
これらの複合的な影響により、システムは深刻なジェネレーション・バウンドに陥り、トレーナーは壁時計時間の74%を待機に費やし、消費レートはジェネレーターの実際の生成レートの5倍に達した。学習シグナルを提供しないサンプルがフィルタリングされたことで、実質的なジェネレーターの生産能力は崩壊した。
サンドボックス・スケーリングの壁
GB300ハードウェアを用いた3回目の実験では、並行ロールアウト数を96から960まで引き上げたが、これまで十分に議論されてこなかった「サンドボックス・スケーリング」という深刻なインフラの壁に突き当たった。各ロールアウトには、コードを実行して報酬を算出するためのコンテナ化されたサンドボックスが少なくとも1つ必要となる。960の並行ロールアウトでは、「サンドボックス初期化のデッドエラー」や「1時間の起動遅延」が発生した。結局96まで並行数を減らさざるを得ず、今度はロールアウト効率が低下するという結果になった。
これは、現在6つの主要プレイヤーが参画し、年間経常収益（ARR）で300億ドルを超え、年末までに1,000億ドルを超えると見込まれるコーディング支援AIのRLトレーニングにおける根本的な制約を露呈している。サンドボックス・インフラは並行ロールアウト数に応じて線形に拡張する必要があり、Modalのようなサンドボックス・サービス企業は、起動遅延、変動する需要、そしてメモリを枯渇させるようなモデルの予期せぬ挙動への堅牢性といった特有の課題に直面している。
ポリシーの陳腐化：非同期トレーニングの隠れたコスト
古典的なポリシー勾配アルゴリズムは、グループ内のすべてのロールアウトが同一のモデル重みから生成されることを前提としている。これは同期実行を強制するため、ジェネレーターが現在のバッチを終えるまで重みを更新できず、巨大な非効率性を生む。業界は現在、ロールアウト生成中にも重みの更新を可能にする「PipelineRL」などの非同期手法へ移行している。
しかし、これによって「ポリシーの陳腐化」が生じる。サンプルが新旧のポリシーの混合物から生成されてしまうのだ。SemiAnalysisは、陳腐化を3つのレベルに分類する。ロールアウト開始時のポリシーと現在のバージョンの乖離（軌道レベル）、ロールアウト途中の重み更新によるトークンレベルの不一致、そしてステートフルな環境特有の環境状態レベルの陳腐化である。
フレームワーク「slime」は、遅延したロールアウトをバッファに保存して後続のバッチで再開する「部分ロールアウト」機能を実装し、テイルレイテンシを軽減している。しかし、これは極めて厄介な環境状態レベルの陳腐化を招く。チームが解説するように、「再開時のサンドボックスはクリーンな状態ではない。以前のポリシーが生成した編集内容やファイル、作業ディレクトリの状態が残っている。新しいポリシーは、自分が生成したわけではない状況から作業を継続せざるを得ない」。これがアドバンテージ帰属の際の学習シグナルを汚染する。
経済性が物語る過酷な現実
SemiAnalysisは、Thinking Machines Labのマネージド型RLトレーニングプラットフォーム「Tinker」と自らの実験を比較し、TCO（総保有コスト）分析を行った。H200インフラの場合、GPU1基あたりの1時間単価は1.59ドルで、資本コストが72.5%を占める。サーバーコストが支配的であり、1台あたり25万8,000ドル、総資本支出（Capex）の71%に相当する。
Qwen3-235Bの実験において、slimeを用いた場合のコストは100万トークンあたり16.23ドルとなり、Tinkerが公表する4.86ドルの4.86倍に達した。Prime RLでは6.90ドルで、Tinkerの3.43ドルに対して2.01倍まで縮まった。slimeとPrime RLのコスト差は、推論効率がいかに総コストを左右するかを如実に示している。
SemiAnalysisは、Tinkerがマルチテナンシーによってコスト優位性を実現していると推測する。TinkerはLoRA（Low-Rank Adaptation）トレーニングAPIを提供しており、複数のユーザーが重みを共有しながらモデルをトレーニングできる。「トレーナー側では、Tinkerはユーザー間でトレーニングリクエストをバッチ処理することで効率を大幅に向上できる。ジェネレーション側では、マルチテナンシーが特定の実行で遅延が発生した際に、他のテナントのロールアウトでアイドルスロットを埋めることで、ストラグラー（遅延者）の影響を緩和している」。
チームは、Thinking Machines Labがプリフィルとデコードの分離といった推論最適化を適用し、Hopperよりも推論性能が高いBlackwell GPUを運用している可能性も指摘する。マルチテナンシーの優位性がインフラやハードウェアの改善と組み合わさることで、劇的なコスト格差が生まれている。
Anthropicが賭けるRLスケーリング
このレポートは、なぜこの問題が重要なのかという背景も提供している。AnthropicのCEOであるDario Amodeiは、RLについて「かつての事前学習がそうであったように、トレーニング期間に応じて性能が対数線形に向上するスケーリングを示している」と述べている。しかし、そのスケーリングには莫大なコストがかかるため、RLシステム効率が、どれだけのRLを実行できるか、ひいてはモデルの能力がどこまで向上できるかを決定づけることになる。
具体的には、Claude Opus 4.8はSWE-bench Proで69.2%、Terminal-Bench 2.1で74.6%を記録しており、RLトレーニングが「スコア向上の主要な要因」とされている。これらのエージェント的なコーディング能力は事前学習だけでは得られず、RLを通じた広範かつ高コストなポストトレーニングを必要とする。
オープンソースコミュニティは目覚ましい進歩を遂げている。SemiAnalysisは、DeepSeek R1のリリース後に登場したOpenRLHFから、slimeやverlといった人気フレームワークに至る系譜を辿っている。OpenRLHFのメンテナーの多くが後にこれらのフレームワークを開発し、中国のRLトレーニングにおける活発なコミュニティを形成しており、チームはこれが「中国モデルの近年の進歩に大きく貢献した」と評価する。これらのフレームワークは学術研究者による新しいアルゴリズムの開発も可能にしており、RL研究をアカデミアの手の届く範囲に引き寄せている。
フレームワークのUXが予想以上に重要
チームは、テストしたフレームワークについて率直な評価を下している。Prime RLはユーザーエルゴノミクス（使い勝手）で高く評価されており、ほとんどのコマンドがuvを通じてtomlファイルで設定でき、AIエージェント統合を円滑にするスキルファイルも備えている。RL環境のハブ機能やプリフィル・デコード分離のサポートも強みだ。一方で、uvへの依存度が強すぎることが摩擦を生んでおり、「なぜかuvがアンインストールしてしまうFlash Attention 3のコンパイルと再インストールに多くの時間を費やした」と指摘する。
ベータ版のPrime Sandboxは、実行終盤で失敗するケースが多かった。「サンドボックスのクォータを使い果たす未終了のサンドボックスや、リソース不足エラーなど、実行前に検知可能なエラーが多かった」。
Slimeは「クリーンで最小限の抽象化」が高く評価されており、特にカスタマイズを容易にするフックの抽象化が優れている。開発チームの対応も迅速だ。主な批判点は、コローケーション（共存）モードに注力するあまり、非同期モードのドキュメントが不足しており、メカニズムを「試行錯誤で解明する」必要があったことだ。
ModalのサンドボックスAPIは、ドキュメントの品質と小規模環境での堅牢性が評価されている。高並行環境では初期化エラーや長大な遅延が発生したが、これはプラットフォームの限界ではなくアカウントのリソース制限が原因であり、Modalが制限を解除したことで高並行下での安定性が確認された。とはいえ、この経験はより優れたサンドボックスの可観測性ツールとスケーリングに関するドキュメントの必要性を浮き彫りにしている。
オープンソースツールの未完成な部分に対するこの容赦ない誠実さは、一般的なベンダーのマーケティングとは対照的だが、RLトレーニングインフラに資本を投じる前に、現実世界の導入課題を理解する必要がある組織的な読者にとって有益な情報となっている。