同期RLの「壁」——GPUが60%の時間アイドル状態になる問題
LLM（大規模言語モデル）のポストトレーニングに強化学習（RL）を活用する手法が急速に普及しているが、従来の同期型RL訓練には深刻なボトルネックが存在する。
32Bパラメータのモデルで32Kトークンのロールアウト（モデルの出力生成）を1バッチ処理すると、推論だけで数時間かかることがある。その間、学習用GPUは完全にアイドル状態だ。日本語でいえば「データが来るのをひたすら待っている状態」である。
この非効率を解消するために生まれたのが非同期RLアーキテクチャだ。
解決策：推論と学習を分離する
非同期RLの核心的なアイデアはシンプルだ。
- 推論専用GPUプールと学習専用GPUプールを分離する
- 両者をロールアウトバッファ（モデル出力の一時保管領域）で接続する
- モデルの重みを非同期に転送することで、どちらの側も相手を待たないようにする
この設計により、推論と学習が並行して動き続け、GPU稼働率が大幅に改善される。
16ライブラリを7軸で徹底比較
Hugging Faceのチームは、この非同期RLパターンを実装した16のオープンソースライブラリを以下の7軸で調査・比較した。
| 比較軸 | 内容 |
|---|---|
| オーケストレーション | 分散処理の制御方式 |
| ロールアウトバッファ | 出力データの保管設計 |
| 重み同期プロトコル | モデルパラメータの転送方法 |
| ステールネス管理 | 古いデータサンプルの扱い方 |
| 部分ロールアウト対応 | 未完了出力の処理 |
| LoRAサポート | 軽量ファインチューニングへの対応 |
| 分散学習バックエンド | 並列化方式 |
主要な調査結果
オーケストレーションはRayが独占：調査した16ライブラリのうち8つがRayを採用。分散MLの事実上の標準となっている。
重み転送はNCCLブロードキャストが主流：NVIDIA Collective Communications Library（NCCL）のブロードキャスト方式がデフォルトとして広く使われている。
ステールネス管理の多様性：古いデータをシンプルに破棄するものから、重要度サンプリング補正（importance-sampling correction）という高度な手法まで、各ライブラリの対応はまちまちだ。
LoRAサポートはまだ限定的：LoRA（Low-Rank Adaptation）による効率的なファインチューニングへの対応は、現状では少数のライブラリにとどまる。
MoEサポートが次の差別化要因：Mixture of Experts（MoE）アーキテクチャの分散学習対応が、今後のライブラリ選定における重要な判断軸になりつつある。DeepSeek v3のようなMoEモデルの台頭がこのトレンドを加速している。
今後の課題：推論と学習のミスマッチ
報告書では今後の設計課題も挙げられている。特に注目されるのが訓練・推論ミスマッチ問題だ。MoEモデルでは、学習時に使うレイヤーと推論時に使うレイヤーが異なるため、重み同期の設計が複雑になる。
また、マルチエージェント協調進化やプロセス報酬モデル（推論の途中ステップに報酬を与える手法）の台頭により、同期のタイミング設計がさらに困難になっている。
TRL（Transformer Reinforcement Learning）の設計方針
Hugging FaceはTRLの非同期トレーナーに以下の原則を採用すると発表した。
- オーケストレーションの軽量化：複雑な依存関係を避けシンプルに保つ
- トークン単位のバージョン管理付き有界キュー：ダブルバッファリングなし
- NCCLパック転送による重み同期：転送効率を最大化
- エージェント型ワークロード向けの部分ロールアウトサポート
LLMの推論能力強化（いわゆる「思考するAI」）がトレンドとなる中、非同期RLアーキテクチャの設計は今後のAI開発の基盤技術として重要性を増している。フルの比較表は原文で公開されており、ライブラリ選定の参考になるだろう。