AReaL 2.0のマイクロサービス化を読む：非同期RL基盤を採用前に確認すべき点
The RL Bridge for LLM-based Agent Applications. Made Simple & Flexible.
ひと目でわかる
- これは何？
- AReaLはエージェント型LLMアプリのための非同期強化学習基盤で、v2.0でtraining・inference・agent・weight-updateの4サービスに分割された。base_url差し替えでブラックボックスなエージェントをRLループに載せる設計と、その代償を整理する。
- 誰に向いている？
- 既存のエージェント実装を書き換えずにRLループへ載せたいチーム、特にOpenAI互換のbase_urlを設定ファイルで差し替えられる構成を持つチームには検討価値がある。逆に、単一プロセスで完結する小規模な学習スクリプトや、非同期化による方策のずれを許容できない用途には向かない。
- 商用利用できる？
- できます。Apache-2.0 は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 1 日前です。
- 何の言語で書かれている？
- 主に Python です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
AReaLが埋めようとしているのは「学習」と「エージェント実行」の間の溝
強化学習でLLMを鍛えるとき、報酬計算のためにモデル自身に何度も推論させ、その軌跡を集めて重みを更新する。この往復を逐次で回すと、推論が終わるまでGPUが遊び、学習が終わるまで推論が止まる。AReaLはこの待ち時間を非同期化で潰すことを主目的にした基盤である。READMEはAReaLを「reinforcement learning (RL) infrastructure designed to bridge foundation model training with modern agent-based applications」と説明し、対象を推論モデルとエージェントモデルの大規模学習に置いている。
想定読者は2種類いる。ひとつは数学やコーディングの推論モデルを自前で学習させたい研究・開発チーム。もうひとつは、すでに動いているエージェントアプリケーションの振る舞いをRLで改善したいチームである。後者に対してAReaLはかなり踏み込んだ提案をしている。エージェント側のコードを書き換えず、接続先のbase_urlをAReaLのRLサービスに向けるだけでオンラインRLのループに参加できる、という設計だ。READMEの表現を借りれば「simply replacing the base_url」であり、OpenClawの例ではbase_urlとapi_keyの差し替えだけで済むと書かれている。
v2.0で4サービスに分割された理由と、その代償
2026年7月1日のv2.0リリースで、AReaLはマイクロサービス構成へ作り替えられた。リポジトリ上ではareal/v2/training_service/、areal/v2/inference_service/、areal/v2/agent_service/、areal/v2/weight_update/の4つが独立したサービスとして並ぶ。推論を回すプロセスと重みを更新するプロセスを別プロセスに切り離すことで、生成が終わるのを待たずに次のバッチの学習を進められる。weight_updateサービスが独立しているのは、学習側の新しい重みを推論側へ渡す経路そのものを差し替え可能にするためだと読める。
この分割は運用コストと引き換えである。プロセスが増えれば、サービスの起動順序、重みの伝搬遅延、各サービスのログをまたいだ障害切り分けが利用者の仕事になる。v1系の単一構成から移る場合、学習スクリプトをそのまま流用するわけにはいかない。v1.0.4が2026年5月、v2.0.0が7月、v2.1.0が8月と、メジャー間の間隔は短い。追従する前提でバージョンを固定し、リリースノートを確認しながら上げる進め方が現実的である。
base_urlを差し替えるだけでエージェントがRLループに入る仕組み
AReaLの最も特徴的な部分は、エージェントの実行をRLのデータ収集そのものとして扱う点にある。エージェントは通常どおりOpenAI互換のAPIを叩く。その向き先をAReaLの推論サービスにすると、リクエストと応答のペアが軌跡として記録され、報酬計算と重み更新の対象になる。READMEはこれを「online RL training for black-box agent applications」と表現し、エージェントの内部実装に踏み込まないことを明示している。
black-boxであることは制約でもある。トークン単位の対数確率や注意の内部状態をエージェント側から取り出すことは前提にしていないため、学習に使える信号はAPI越しに観測できる入出力と、外部から与える報酬に限られる。トークン単位の重要度比を使うIcePopのような手法を適用するには、推論サービス側が生成時の情報を保持している必要がある。この境界をどこに引くかが、AReaLで扱えるアルゴリズムの範囲を決める。
KPopとIcePop：設定キーで切り替わるトークンマスキング
2026年6月17日のリリースで、KPopと呼ばれる双方向バイナリKLダイバージェンスによるトークンマスキングが導入された。READMEによればrejection_sampling.metric=binary_klを設定すると有効になり、examples/math/gsm8k_kpop.yamlが出発点として示されている。同じタイミングで、重要度比に基づくIcePopの設定examples/math/gsm8k_icepop.yamlも追加された。
注目すべきは、アルゴリズムの違いがYAMLのキー1つで切り替わる点である。学習ループのコードを書き換えずに、どのトークンを損失から除外するかを変えられる。ただし、この2つの手法がどういう条件で効くのか、READMEからは分からない。binary_klとimportance-ratioという指標の違いは説明されているが、収束速度や安定性の比較は示されていない。examples/math/配下の2つの設定を自分のデータで回し、どちらが安定するかを自分で確かめる以外に判断材料はない。
Scaffoldings連携とNPUブランチ：周辺の対応状況
2026年4月23日、NVIDIA TensorRT-LLMのScaffoldingsとの連携がexamples/scaffolding/に追加された。READMEはこの設計を「thorough decoupling of agent execution, reward calculation, and trajectory acquisition」と説明している。エージェント実行、報酬計算、軌跡取得を別モジュールに分けることで、既存のモジュールを再利用しながら自分の手法だけを差し込める。AReaL本体のマイクロサービス分割と同じ方向の設計である。
ハードウェア対応としては、2026年1月1日にAscend NPUでの学習サポートが告知された。コードはascendブランチで維持され、インストール手順はareal-project.github.io/AReaL/en/tutorial/installation_npu.htmlに置かれている。mainブランチとは別系統である点に注意したい。NPUで動かす場合はascendブランチを追うことになり、mainの変更がそのまま入るとは限らない。
AReaL-liteという逃げ道と、フルスタックとの使い分け
2025年7月31日にAReaL-liteが公開されている。READMEの説明では、アルゴリズム開発を優先したAPI設計を持ち、コード量は80%少なく、性能と主要機能の90%を維持するという。非同期のエージェントRLをネイティブにサポートするとされている。
数字の出所はプロジェクト自身の主張であり、独立した検証ではない。ただし、フルスタックのAReaLが4サービスの運用を要求するのに対し、AReaL-liteが単一の学習スクリプトに近い形で動くなら、用途の切り分けは明確である。新しい報酬設計やマスキング戦略を試す段階ではAReaL-lite、その戦略が固まって大規模なスループットが必要になった段階でv2のマイクロサービス構成へ移る、という順序が素直だ。逆に、最初からv2で入ると、アルゴリズムの試行錯誤とサービスの運用デバッグが同時に発生する。
採用前に確認すべき制約と、確認の手順
ライセンスはApache-2.0で、特許条項を含む一般的な許諾型ライセンスである。商用利用の可否や派生物の扱いは自組織の法務判断が必要で、ここで断定的なことは言えない。
技術面で最初に確認すべきは、自分のエージェントがOpenAI互換APIで完結しているかである。base_urlの差し替えという導入経路は、この前提が崩れると成立しない。独自プロトコルやローカル推論を直接呼んでいる場合、AReaLの推論サービスを経由させる改修が必要になる。次に、examples/hermesとexamples/sweのどちらが自分のワークロードに近いかを読む。HermesはオンラインRLループの例、SWEはエンドツーエンドのSWE RL学習の例としてREADMEに挙げられている。
非同期化そのものの限界も認識しておきたい。推論と学習が別プロセスで動く以上、学習に使う重みと推論に使う重みの間にずれが生じる。このずれをどう扱うかは手法依存であり、ずれに敏感なアルゴリズムを選んだ場合は非同期の利点が相殺される可能性がある。まずrejection_sampling.metric=binary_klを有効にした設定と無効の設定を同一データで回し、学習曲線がどう変わるかを自分の環境で確認するのが、最初の具体的な一歩になる。
編集部の結論
既存のエージェント実装を書き換えずにRLループへ載せたいチーム、特にOpenAI互換のbase_urlを設定ファイルで差し替えられる構成を持つチームには検討価値がある。逆に、単一プロセスで完結する小規模な学習スクリプトや、非同期化による方策のずれを許容できない用途には向かない。最初に確認すべきは、areal/v2/配下の4サービスをどう起動するか、examples/hermesとexamples/sweのどちらが自分のワークロードに近いか、そしてrejection_sampling.metric=binary_klを有効にしたときに学習が安定するかである。
コミュニティノート