RadixArk Milesがv0.1に到達、ただし本番規模RLにはなお実証が必要
- Martin Chen
- 1 時間前
- 読了時間: 20分
RadixArk Milesは、初の公開リリースから9か月後の2026年8月18日にバージョン0.1へ到達した。この節目により、若いリポジトリは強化学習、エージェント学習、分散モデル後学習のためのより包括的なシステムへと進化した。
この違いは重要だ。RL実験を始めることよりも、多数のマシンにまたがって正確に運用し続けることの方が難しい。ロールアウトエンジンが経験を生成し、トレーナーがモデルを更新し、新しい重みはプロセスを損なうことなく推論ワーカーへ戻さなければならない。
このプロジェクトは最近、GitHub Trendingのホットリストのスナップショットで14位に登場した。しかし、そのアグリゲーターは検証済みの掲載時刻を示していないため、ランキング自体が根本となる出来事ではない。確認できるニュースは、RadixArkのv0.1リリースと、そこに付随する詳細な本番運用上の主張である。
Milesは、そこから発展したslimeフレームワークを含む、オープンな学習システムがひしめく領域に参入する。したがって本当の競争は、あるリポジトリと別のリポジトリの対決ではない。高度なAIチームが今なお自前で構築しているカスタム内部スタックに対し、オープンで検証可能なインフラがどこまで対抗できるかという競争だ。
RadixArk Miles v0.1が確認済みの出来事
重要な変化は一時的なトレンド順位ではない。RadixArkはMilesに番号付きリリースと本番運用のストーリーを付与した。
RadixArkとそのエコシステムパートナーは、2026年8月18日にMiles v0.1リリースを公開した。彼らはこれを、フロンティアモデルの後学習向けフルスタックシステムと説明している。この説明は依然としてプロジェクト側の主張であり、独立した認証ではない。
この日付により、トレンドフィードの不確実性は解消される。リポジトリが9月に突然現れたわけではない。Milesは2025年11月19日に初めて発表され、その後公開開発を経てv0.1の節目に到達した。
初期のMilesリリースでは、このプロジェクトをslimeのエンタープライズ向け拡張として位置付けていた。Slimeは小規模で改変しやすいアーキテクチャを重視していた。Milesはその基盤を維持しつつ、より大規模なmixture-of-expertsモデルと本番ワークロード向けのインフラを追加した。
mixture-of-expertsモデル、すなわちMoEは、すべてのパラメーターを使うのではなく、各トークンに対して選択されたエキスパートコンポーネントを有効化する。この設計は計算効率を高められる一方、ルーティング、学習の一貫性、分散実行を複雑にする。
バージョン0.1は、後学習の完全なループをカバーしようとしている。SGLangが軌跡を生成し、NVIDIA Megatron-LMまたはPyTorch FSDPがポリシーを学習し、同期レイヤーが更新済みの重みをロールアウトワーカーへ戻す。
この対象範囲は、新しいアルゴリズム実装よりも重要である。組織はすでにPPO、GRPO、教師ありファインチューニング、関連手法のコードを見つけられる。難しい作業は、これらの手法が長時間のエージェントセッション、変化するポリシー、ハードウェア障害、不均一なワークロードに直面したときに始まる。
RadixArkによれば、Milesは同期型および完全非同期型の強化学習をサポートする。非同期パスでは、推論ワーカーがサンプル生成を続ける一方、トレーナーは完了したグループを消費してモデルを更新する。
このプロジェクトには、エージェント環境とサンドボックスプロバイダー向けの統合も含まれる。これらの接続により、学習ジョブはコーディングやコンピューター操作タスクを実行し、得られた軌跡を記録し、検証器のスコアを報酬として返すことができる。
公開されているMilesリポジトリには、これらの主張を支えるコード、レシピ、テスト、ドキュメント、Issue、開発履歴が含まれている。Apache 2.0ライセンスにより、チームは実装を検査し適応させるための幅広い権利を得られる。
このオープン性は技術的な検証を可能にする。ただし、同等のハードウェア、ネットワーク、運用上の専門知識がなければ、別の組織がRadixArkの最大規模の実行を再現できることを保証するものではない。
したがって、バージョン0.1は成熟度の指標として読むべきだ。RadixArkはアーキテクチャを統合し、参照ワークロードを文書化し、本番運用の目標を掲げた。より広範な導入の証拠が、次の試金石となる。
なぜエージェント型RLはシステム上の問題を生むのか
エージェント学習は、通常のモデル後学習を、推論、ツール、サンドボックス、報酬、継続的に変化する重みにまたがる協調の問題へと変える。
単純な言語モデルのロールアウトでは、1つのプロンプトに対して1つの回答を生成できる。エージェント型ロールアウトでは、ターミナルを開き、ファイルを調べ、ツールを呼び出し、エラーから回復し、多数のターンにわたって処理を続ける場合がある。
これらの軌跡が同時に完了することはほとんどない。あるコーディングタスクはすぐに失敗する一方、別のタスクはコマンド実行に数分を費やす可能性がある。同期型トレーナーは最も遅いメンバーを待ってから進むため、高価なハードウェアが遊休状態になる。
Milesはサンプルレベルのスケジューリングでこの不均衡に対処する。ある軌跡が終了すると、別の軌跡が直ちに空いたスロットを使える。完了した軌跡グループは、トレーナー用の上限付きバッファに入る。
この設計は、ロールアウトのペースとオプティマイザーのペースを分離する。同時に、難しい問いも生じる。更新済みポリシーによって不適切になる前に、経験サンプルはどこまで古くなり得るのか。
非同期強化学習では、ポリシーラグは、サンプルを生成するモデルが現在の学習ポリシーからどれだけ遅れているかを測る。並行性を高めればハードウェア使用率は向上し得るが、過度なラグはアルゴリズムのオンポリシー前提を弱める可能性がある。
Milesは、古いサンプルの受け入れ、再試行、破棄、拒否を制御する機能を公開している。この柔軟性は研究者が独自の境界を定義する助けになるが、重要な正確性の判断を運用者に委ねることにもなる。
エージェント型学習は別の不一致ももたらす。ツール呼び出しとチャットテンプレートは、ターン間でメッセージがトークンへ変換される方法を変え得る。その結果、トレーナーは推論時に使われた系列とはわずかに異なる系列を受け取る可能性がある。
MilesはこれをToken-In-Token-Out、すなわちTITOと呼ぶ。セッションサーバーは、生成済みトークンの識別子を保持しながら、新たに追加されたメッセージのみを加える。損失マスクは、モデルが生成していないトークンを除外する。
この仕組みは、微妙な失敗モードを対象にしている。ロールアウトと学習でトークン、確率、エキスパートルーティングに不一致がある場合、オプティマイザーは実際の経験ではなく、再構成されたインタラクションから学習することになる。
リポジトリの公開TITOロードマップも、現時点のサポートの限界を示している。指定されたモデルファミリーには明示的な設定が必要であり、システムがすべてのテンプレートを自動検出するわけではない。
この詳細は、活発に進むエンジニアリングプロジェクトの健全な証拠である。トークン忠実性がモデル固有の契約、テスト、統合に依存していることを示している。この機能は、あらゆる外部エージェントハーネスを正しくする万能スイッチではない。
Milesは、コーディングおよびコンピューター操作エピソード用の隔離環境もサポートする。各タスクには、それぞれ独自のファイル、プロセス、検証器を備えた新しいサンドボックスを割り当てられる。
ある失敗したエピソードが別のエピソードを汚染すべきではないため、隔離は重要である。また、特に数千の環境を起動し、実行し、報酬を報告し、予測可能な形で終了させる必要がある場合、オーケストレーション作業も増加する。
これらの問題が、v0.1リリースが今登場した理由を説明する。AI開発は、単一回答のチューニングから、より長い時間にわたり行動するエージェントへと移行している。学習インフラは、それらの行動を生んだ正確な文脈を失わずに捉えなければならない。
プロジェクトを評価する開発者は、このシステム層に注目すべきだ。アルゴリズムのサポートは必要だが、再現可能な軌跡、スケジューリングの挙動、障害からの復旧こそが、長時間の実行が有用な証拠を生むかどうかを決める。
自らの実験を記録するチームには、設定、失敗、評価結果を検索可能な形で残す仕組みも必要である。構造化されたエンジニアリングナレッジベースは、学習フレームワークの外でそうした運用上の文脈を保存できる。
中核の仕組みはロールアウト、学習、重み更新を結び付ける
RadixArk Milesは、連携した1つのループによって、分離された推論スタックと学習スタックが生む不一致を減らせると見込んでいる。
このループは、高スループットのモデルサービング向けに設計されたオープンな推論エンジン、SGLangから始まる。Milesはこれを用いて長い複数ターンの軌跡を生成し、エージェントセッション間でキャッシュ済みプレフィックスを再利用する。
プレフィックスキャッシュは、モデルがすでに処理したテキストについて再利用可能なアテンション状態を保存する。同じ適切なワーカーで後続ターンを処理すれば、共有された会話履歴を繰り返し計算することを避けられる。
Milesは、新しいセッションをより低負荷のワーカーへルーティングしつつ、このキャッシュの局所性を維持しようとする。このアプローチは、少数の長時間タスクが不釣り合いな容量を消費するロングテール問題を対象にしている。
続いてトレーナーは、Megatron-LMまたはFSDPを用いて完了したグループを処理する。Megatron-LMは複数のモデル並列化方式をサポートし、FSDPはデータ並列ワーカー間でモデル状態をシャーディングする。
両方のパスを提供することで、潜在的な利用者層は広がる。既存のMegatronデプロイメントを持つチームは、その分散制御を利用できる。Hugging Faceのモデル実装に近いチームは、同じ変換プロセスなしにFSDPを利用できる。
この抽象化によってバックエンド間の違いが消えるわけではない。Megatronのレシピでは、テンソル、パイプライン、コンテキスト、エキスパートの各次元に作業を分割できる。FSDPパスは異なる分散モデルを使用し、アーキテクチャの適応が必要になる場合がある。
学習後、Milesは変更された重みをロールアウトフリートへ戻さなければならない。モデルが多数のアクセラレーターにまたがり、推論が異なるシャーディングレイアウトを用いる場合、このステップが反復時間の大部分を占める可能性がある。
直接接続されたクラスター向けに、このプロジェクトはRDMAによるピアツーピア転送を提供する。リモートダイレクトメモリアクセスにより、マシンはCPUの関与を限定してリモートメモリにデータを書き込める。
RadixArkによれば、このパスにより、Kimi-K2の1兆パラメータの重み更新は53.3秒から7.2秒へ短縮された。この結果はプロジェクト独自の参照ワークロードによるものであり、別のネットワーク構成での再現が必要だ。
Milesは、直接のNCCLまたはRDMA接続が使えない場合に備え、ディスクデルタ更新も提供する。システムは、各ステップ後に完全なチェックポイントを送る代わりに、変更されたポリシー部分を公開する。
報告されたGLM-4.7-Flashの実行では、RadixArkは各ペイロードを62.4 GBから0.69 GB〜0.83 GBへ削減したとしている。関連する生成停止時間は3〜5秒に収まった。
これらの数値は、単一の普遍的な性能保証ではなく、異なるデプロイメントパスを示している。ピアツーピア転送は高速なネットワークと互換性のあるトポロジーに依存する。ディスクデルタは、ポリシーバージョン間で変更されるバイト数に依存する。
低精度計算は、さらに別の層を加える。Milesには、対応モデルでFP8、MXFP8、NVFP4、INT4の量子化対応学習を使用するレシピが含まれている。
量子化は、メモリ使用量を減らしスループットを高めるために、少ないビット数で値を表現する。しかし、推論側と学習側は互換性のある規則を適用しなければならず、そうでなければ数値差がポリシーの挙動を変える可能性がある。
この問題はMoEモデルでより深刻になる。わずかな数値変化によってトークンに対して異なるエキスパートが選択され、順方向計算と勾配を受け取るパラメーターの両方が変化し得る。
Milesは、R3と呼ばれるRollout Routing Replayでこれに対処する。これは推論中のエキスパートルーティング選択を記録し、トレーナーの順方向パス中に再生する。
これは、このプロジェクトの中核的な仕組みを最も明確に示した表現だ。フレームワークは単に独立したツールを接続するだけではない。RLループ全体で下された決定を保持しようとしている。
同じ原則は、オンポリシー蒸留とゼロKLアラインメントも支えている。オンポリシー蒸留では、生徒モデルの現在の挙動のもとで収集した教師モデルのシグナルを用いて学習させる。ゼロKLアラインメントは、ロールアウトと学習の数値的一致を目指す。
各機能は、それぞれ異なる乖離の形を抑えるものだ。これらを組み合わせることで、Milesは単なる学習スクリプトの集合を超える。一方で、モデルファミリーやハードウェア世代をまたいで正しさを維持すべき範囲も広がる。
オープンインフラがプライベートな学習スタックに挑む
Milesは、強力なモデルチームであれば誰もが再構築すべき社内優位性として強化学習インフラを捉え続ける組織に圧力をかける。
RadixArkの立場は明快だ。SGLangのような共有システムを通じてオープンな推論は進化してきたため、ポストトレーニングのインフラも同様の道を歩むべきだという。
同社は2026年5月5日、ポストマネー評価額4億ドルと公表した条件で、1億ドルのシード資金調達とともに正式ローンチした。このラウンドはAccelが主導し、Spark Capitalが共同リードを務めた。
同社のオープンインフラ戦略では、SGLangとMilesを二つの基盤として挙げている。SGLangは推論を担い、Milesは強化学習とモデルのポストトレーニングを担う。
この資金調達により、リポジトリを取り巻く文脈は変わる。Milesは単なる有志による実験ではない。オープンインフラを軸にマネージド製品の構築を目指す、資金を得た企業にとっての戦略的資産でもある。
したがって主な競合相手は、プライベートなRLスタックだ。フロンティア研究所は、ロールアウトサービス、トレーナー、データバッファ、評価器、チェックポイントシステムを社内で組み合わせて構築することが多い。
こうした社内プラットフォームには、長年の運用経験が反映されている可能性がある。公開リポジトリでは利用できない独自スケジューラ、最適化カーネル、特化した可観測性、復旧手順を備えていることもある。
Milesは、統合済みのベースラインをオープンにすることで、その差を縮めようとしている。スタートアップは、すべてのサブシステムをゼロから接続する代わりに、保守されたレシピと拡張ポイントから始められる。
これは統合作業を不要にするわけではない。チームは依然として、環境、報酬、データセット、モデルチェックポイント、ネットワーク、ストレージ、評価基準を準備する必要がある。
違いは、エンジニアリングをどこから始めるかにある。統合フレームワークがなければ、チームはまず基本ループを構築する。Milesがあれば、提供されたループが自分たちのワークロードに合うかを検証するところから始められる。
このプロジェクトは、よりシンプルな研究フレームワークとも間接的に競合する。MilesはSlimeの設計を起点としており、多くの変更が上流へ還元されるとしているため、Slimeは重要な参照点であり続ける。
この関係は、勝者と敗者という単純な物語を複雑にする。透明性と迅速な改変を重視する研究では、小規模なフレームワークが依然として望ましい場合がある。より大規模なシステムは、組み込みの運用制御をより必要とするチームに適している。
Milesがその立場を正当化するには、両方の特性を維持しなければならない。フレームワークがモジュラーであると説明していても、インフラが過剰になればデバッグは難しくなりうる。
同社は、ロールアウト、報酬、損失、フィルター、データソース向けの型付きインターフェースと置き換え可能なコンポーネントを強調している。これらの拡張ポイントが意味を持つのは、ユーザーが境界をまたぐ障害を理解できる場合に限られる。
商業的なインセンティブにも注意が必要だ。オープンプロジェクトが広く採用されれば、その周辺でマネージドインフラやサポートを拡大できるため、RadixArkには利益がある。
このモデルはオープンソースインフラでは一般的だ。保守やハードウェア検証の資金源になりうる一方で、どの機能を引き続き独立して容易に運用できるようにするかをめぐる緊張も生みうる。
Apache 2.0ライセンスにより、チームはコードをフォークして改変できるため、ロックインに関する懸念はいくらか軽減される。それでも、デプロイメントサービス、独自ツール、特化した専門知識を通じて、運用上の依存は形成されうる。
購入者にとって重要なのは、Milesがオープンかどうかではない。別の組織がRadixArkの非公開知識に依存せず、これを信頼性高く運用できるかどうかだ。
開発者にとって、このリポジトリはRLシステムの課題を読み解ける地図として、すぐに価値を提供する。そのアーキテクチャは、ロールアウトの忠実性、スケジューリング、精度、同期がどこで相互作用するかを示している。
AIプロダクトチームにとって、このインフラは実験速度に影響しうる。ループが高速化すれば、同じハードウェア予算の範囲で、より多くのエージェント環境、報酬設計、データ戦略を試せるようになる。
リファレンス実行が証明しないこと
RadixArkは異例なほど具体的なシステム上の主張を公表しているが、パフォーマンスに関する証拠の大半は依然としてフレームワークを構築したチーム自身によるものだ。
代表的なv0.1の例では、64基のNVIDIA GB300 GPUを用い、ターミナル操作タスクでGLM-5.2 744B-A40Bモデルを学習させた。RadixArkは32基のGPUをロールアウトに、残り32基を学習に割り当てた。
リファレンス構成では、最大シーケンス長を65,000トークン、バッチサイズを64とした。同社は、約4.5分の学習ステップで100回の安定したロールアウトステップを実行したと報告している。
また、平均ポリシーラグは1.7ステップ、プレフィックスキャッシュのヒット率は96%だったと報告した。このワークロードでは、メモリ最適化によりGPUあたり30GB超のHBMを節約できたという。
これらの数値は、評価者に具体的な目標を与える点で価値がある。ただし、単一のモデル、クラスター、ソフトウェアバージョン、タスク分布、チューニング構成から得られた測定値にとどまる。
100ステップの実行は、その構成下でシステムが動作できる証拠だ。しかし、数千回の更新、断続的な障害、変化する環境負荷にわたる長期間の信頼性を確立するものではない。
パフォーマンス特性は、より小規模なクラスターでは異なる可能性もある。多数の最新アクセラレータ向けに最適化された機能は、8基のGPUや混在ハードウェアでは同等の効果を生まず、複雑さだけを増すことがある。
プロジェクトの非同期設計には、避けられないトレードオフがある。ロールアウトと学習を稼働状態に保つことは利用率を高めるが、古い軌跡は現在のポリシーからさらに乖離しうる。
RadixArkはステイルネス制御を公開し、例ではラグを報告している。独立したユーザーは、それらの制御が自分たちのアルゴリズムや報酬分布において学習品質を維持するかを判断しなければならない。
低精度に関する主張にも同様の精査が必要だ。RadixArkは、ロールアウト時間を短縮しながら、報酬曲線がBF16ベースラインをほぼ追随するとしている。この結果を、すべてのモデル、オプティマイザ、タスクへ自動的に一般化することはできない。
量子化学習は、活性化分布や特定のレイヤーに左右される可能性がある。Milesでは選択したコンポーネントをBF16のままにできるが、どれを例外とするかはモデル固有の検証を必要とする。
モデルサポートも変化し続ける対象だ。リポジトリには、多数のDense、MoE、マルチモーダル、エージェント型のレシピが列挙されている。レシピが記載されていることは、バックエンドと精度のあらゆる組み合わせが同等にテストされていることを意味しない。
公開のissue trackerは、この不確実性を可視化している。公開報告には、同期動作、設定の意味論、LoRAの詳細、ルーティングの代替案、追加モダリティのサポートが含まれる。
こうした活動は、Milesが特別に欠陥の多いことを示す証拠ではない。分散学習プロジェクトでは通常、複雑な障害モードが表面化する。それでも、「本番対応」という表現は、各購入者の要件に照らして検証すべき理由を示している。
フォールトトレランスは特に重要だ。クラスタースケールの実行では、1つのワーカーが失敗したり、転送が停止したり、チェックポイントに不整合が生じたりすると、何時間もの作業が失われる可能性がある。
当初の2025年ロードマップでは、GPU障害に対するより優れた弾力性が将来の課題として明示されていた。バージョン0.1にはより多くの運用機構が含まれるものの、ユーザーは成功した実行から推測するのではなく、復旧を実際にテストすべきだ。
セキュリティはトレーナーの範囲を超える。エージェント環境では、シェルコマンドやネットワークリクエストを含む場合がある、モデル生成のアクションが実行される。
新しいサンドボックスはエピソード間の汚染を減らすが、運用者はイメージの来歴、認証情報、ネットワーク境界、ログ、保持されるアーティファクトを確認する必要がある。学習フレームワークが、すべての組織の脅威モデルを定義できるわけではない。
適切な結論は慎重なものだ。Milesは最小限のデモを超え、リファレンス実行には技術的な意味がある。幅広い本番成熟度を示すには、依然として独立した再現と、より長い運用実績が必要となる。
RadixArk Milesが定着するかを決める三つのシグナル
次の段階は、再現性、障害復旧、そしてRadixArkやSGLangと既につながりのあるチームを超えた採用にかかっている。
最初のシグナルは、大規模なリファレンスワークロードの独立した再現だ。研究者は同一の64-GPUクラスターを用意する必要はないが、比較可能な利用率、ポリシーラグ、収束結果を公表すべきである。
再現の成功は、調整機構が一般化するというRadixArkの主張を強める。説明できない大きな差が生じれば、公開されたパフォーマンスのより大きな部分を、非公開のチューニングや特殊なトポロジーが占めていることを示唆するだろう。
二つ目のシグナルは、長期間にわたる障害復旧の証拠だ。ユーザーは、中断されたワーカー、停止した推論エンジン、破損した環境、チェックポイント復元を扱う文書化されたテストに注目すべきである。
信頼性の高い復旧は、別のピークスループットのグラフよりも、本番対応という評価を強く裏付ける。同期や再開の失敗が繰り返されれば、高価で無人の実行にMilesを使う根拠は弱まる。
三つ目のシグナルは、フレームワークの構築や発表を支援していないチームによる採用だ。独立したケーススタディでは、モデル規模、ハードウェア、タスク種別、変更内容、遭遇した運用上の問題を説明すべきである。
ロゴや推薦コメントは有用な手がかりとなるが、詳細な報告のほうが重みを持つ。最も強い証拠は、Milesが何を置き換えたか、どのようなエンジニアリングが残ったか、チームがどれだけの時間を節約したかを示すものになる。
リポジトリの活動も、これら三つのシグナルすべてに文脈を与える。メンテナーは、新しいモデル、精度、ハードウェア、エージェント環境を支援しながら、正しさに関する問題を解決する必要がある。
この負荷は、オープンソースでよく知られた緊張を生む。迅速なサポートはユーザーを引き付ける一方、拡張が過剰になると、テストの難しい組み合わせ全体で回帰のリスクが高まる。
最も持続性のあるMilesの形は、テスト済みのコアを定義し、実験的な境界を明確に伝えるものだろう。そうすればユーザーは、サポート対象の本番パスと有望な拡張機能を区別できる。
RadixArkは、コミュニティの貢献がロードマップに影響を与えることも示す必要がある。1社の優先事項と強く結びついたリポジトリは、オープンなままであっても、外部の人々が方向付けるのは難しくなりうる。
小規模チームにとって、当面の判断ではすべてのスケール主張を受け入れる必要はない。サポート対象のモデル一つ、環境一つ、バックエンド一つを、既存のワークフローに対して試せばよい。
この評価では、トークン毎秒以上の指標を測定すべきだ。チームは、失敗したエピソード、古いサンプルの比率、報酬の再現性、チェックポイント復旧、問題診断に必要な工数を記録すべきである。
現時点での評価は、RadixArk Milesが本番規模のエージェント学習に向けた本格的なオープンな試みへ成長したというものだ。追うべきイベントは、日付のないトレンド順位ではなく、8月のv0.1リリースである。
次の証明はユーザーからもたらされる。独立したチームは、報告された挙動を再現し、失敗した実行を復旧し、隠れた運用知識なしにシステムを拡張できるだろうか。
RadixArk Milesを検討するチームは、まず対象を限定したワークロードから始め、得られた結果を公開すべきだ。同期実行と非同期実行を比較し、トークンの忠実性を確認したうえで、スケールアウト前にリカバリーをテストする。設定変更と誤っていた前提はすべて記録する必要がある。その証拠は、リポジトリの勢いだけよりも重要になる。こうした結果が異なるモデルやクラスターでも一致すれば、Milesはオープンなポストトレーニングの共通基盤になり得る。再現が依然として難しい場合でも、このプロジェクトは有用なシステム参照にはなるが、現時点ではプライベートインフラの代替とは言えない。
