オープンソースRLライブラリ16種から学ぶ：非同期強化学習トレーニングの現状と課題

 

はじめに：LLMとRLの交差点で何が起きているか

2025年から2026年にかけて、大規模言語モデル（LLM）の性能向上において強化学習（RL）が果たす役割はかつてないほど重要になっている。DeepSeekやQwQなどのモデルが推論能力を飛躍的に向上させた背景には、RLベースのポストトレーニングがある。しかし現実には、LLMに対するRL適用は計算効率の観点から深刻な課題を抱えている。

Hugging Faceのリサーチチームは、このエコシステムを包括的に調査した記事「Keep the Tokens Flowing: Lessons from 16 Open-Source RL Libraries」を公開した。[Source: https://huggingface.co/blog/async-rl-training-landscape] 本記事ではこの調査をベースに、非同期RLトレーニングの技術的実態と課題を解説する。

なぜ「トークンを流し続ける」ことが重要なのか

LLMのRLトレーニングにおける最大のボトルネックは、GPU稼働率の低さにある。教師あり微調整（SFT）では、データをバッチ処理してGPUをほぼ100%稼働させることができる。しかしRLでは、次のサイクルが繰り返される。

1. ロールアウト生成：現在のポリシー（モデル）がトークンを逐次生成する
2. 報酬計算：生成されたシーケンスに対してリワードモデルが評価を付ける
3. パラメータ更新：勾配を計算してモデルを更新する

同期型のRLでは、これら3ステップが順次実行されるため、ロールアウト中はトレーニングが停止し、更新中はロールアウトが止まる。この「デッドタイム」がGPU稼働率を著しく下げる原因だ。タイトル「トークンを流し続けろ」は、この非効率性を解消することの重要性を端的に表している。

16種のライブラリが示すアーキテクチャの多様性

調査対象となった16のオープンソースライブラリには、VERL、OpenRLHF、TRL（GRPOTrainer）、NeMo-Aligner、DeepSpeed-Chat、SkyRL、EasyR1、LLaMA-Factoryなどが含まれる。これらは大きく2つのアーキテクチャに分類できる。

同期型RLトレーニング

最もシンプルなアプローチで、ロールアウト→報酬→更新を直列実行する。実装が容易でデバッグしやすい反面、GPU稼働率は往々にして30〜50%程度にとどまる。TRLのGRPOTrainerやDeepSpeed-Chatはこのカテゴリに属する設計を持つ。

非同期型RLトレーニング

非同期型では、アクター（推論）とラーナー（重み更新）が並列動作する。ラーナーが更新を行っている間も、アクターはトークン生成を続けることができるため、スループットが向上する。ただし、ロールアウトの生成に使ったポリシーと、更新後のポリシーの間に乖離（オフポリシー問題）が生じ、学習の安定性が低下するリスクがある。

VERLはこの分野で特に注目されるライブラリで、vLLMとDeepSpeedを組み合わせた柔軟なアーキテクチャを持つ。SkyRLは非同期スケジューリングを積極的に採用し、大規模クラスタでの高スループットを目指している。

GRPO対PPO：アルゴリズム選択の実務

アルゴリズム面では、従来のPPO（Proximal Policy Optimization）に加え、GRPO（Group Relative Policy Optimization）が急速に普及している。GRPOの最大の利点はクリティックモデルを必要としない点で、メモリ消費をほぼ半減できる。DeepSeek-R1もGRPOを採用したことで広く知られるようになった。

一方、PPOは価値関数による分散削減効果があり、複雑なタスクでの学習安定性に優れるという見解もある。16ライブラリの調査では、GRPOを採用するライブラリが増加傾向にある一方で、両者の実務的な優劣は依然としてタスク依存であることも示されている。[Source: https://huggingface.co/blog/async-rl-training-landscape]

実装上の3大課題

1. デッドトークン問題

非同期設定では、生成されたトークンが更新後のポリシーと整合しない「古い」サンプルになりやすい。これらのデッドトークンをトレーニングに使うと、オフポリシーバイアスが蓄積する。インポータンスサンプリングによる補正は有効だが、クリップ範囲を超えた場合はサンプル棄却が必要となり、実効スループットが低下する。

2. 分散推論との統合

vLLMやSGLangなどの高速推論エンジンをRLループに組み込む際、重み同期のオーバーヘッドが問題になる。ロールアウト用とトレーニング用で別々のGPUプールを割り当てる設計（actor-learner分離）は効果的だが、GPU台数が倍近く必要になるというコストのトレードオフがある。

3. 報酬ハッキングとスケーラビリティ

リワードモデルのスコアを過剰最適化するリワードハッキングは、RL全般にわたる古典的な問題だ。LLMの文脈では、モデルがリワードモデルの弱点を突いた出力を生成することが報告されており、リワードの多様化やKLペナルティの適切な設定が不可欠となる。NeMoエージェントツールキットがDABStepベンチマークで首位を獲得した事例でも、再利用可能なツール生成という工夫によってこの問題を回避するアプローチが示されている。[Source: https://huggingface.co/blog/nvidia/nemo-agent-toolkit-data-explorer-dabstep-1st-place]

ライブラリ選択のガイドライン

実務でどのライブラリを選ぶかは、以下の観点から検討すると整理しやすい。

• 研究・プロトタイピング重視：TRLのGRPOTrainerやEasyR1のように実装がシンプルで改変しやすいものが適する
• 大規模クラスタでのスループット重視：VERLやSkyRLのように非同期アーキテクチャを採用し、vLLM統合が成熟しているものが有利
• 既存インフラとの互換性：DeepSpeed-ChatはDeepSpeedエコシステムとの親和性が高く、既存のSFTパイプラインからの移行コストが低い
• マルチモーダル・音声対応：IBMのGranite 4.0 Speechのようにエッジ向けコンパクトモデルを扱う場合は、軽量推論との組み合わせを考慮する必要がある [Source: https://huggingface.co/blog/ibm-granite/granite-4-speech]

今後の展望

16ライブラリの調査が示す最も重要な示唆は、「RLトレーニングの効率化はまだ発展途上である」という事実だ。GPUクラスタの規模が拡大し、モデルサイズが増大するにつれ、非同期化・分散化の重要性はさらに高まるだろう。一方で、アルゴリズムの安定性やオフポリシー問題の解決策については、まだコンセンサスが得られていない部分も多い。

エンジニアリング観点では、HuggingFace Hubに導入されたStorage Bucketsのような大容量データ管理インフラも、大規模RL実験のエコシステムを支える重要な基盤となっている。[Source: https://huggingface.co/blog/storage-buckets]

オープンソースコミュニティが16種もの多様なアプローチを試みていること自体、この分野の解決策がまだ確立されていないことの証左でもある。研究者・エンジニアにとって今こそ参入し、貢献できるフロンティアだと言える。