論文解説: Miles v0.1 — 「本番で回るポストトレーニング基盤」を解剖する

巨大MoEをエージェント的RLで後追い学習させるための全部入りシステムMilesを、論文本文から解説。生成側と学習側の「数値のズレ」をどう潰すか、744Bモデルを64GPUで回した実測はどうだったかまで。

Miles v0.1: Production-Level Post-Training

この論文は何を言っているか

原題は "Miles v0.1: Production-Level Post-Training"（RadixArk、arXiv:2609.08368、2026年9月8日公開）。

概要（abstract）を要約すると、こうなります。Milesは、フロンティア規模のポストトレーニング（事前学習済みモデルを実用的なモデルに仕上げる工程）のための、フルスタックで本番投入可能なシステムである。先行するslimeの設計を土台に、強化学習（RL）の各段を「検証済みで、読みやすく、差し替え可能」という一つの原則で組み直した。精度・効率・信頼性・スケーラビリティを第一級の目標に据え、SGLangの上に載せたロールアウトエンジン、Megatron-LMとPyTorch FSDPの2つから選べるトレーナー、配置トポロジ別に3種類ある重み同期経路を持つ。全パラメータRLだけでなく、LoRA RL、オンポリシー蒸留、教師ありファインチューニング、真のオンポリシー整合をサポートし、同じ設計を拡散モデルにも広げている。最後に、GLM-5.2（744B-A40B）をターミナル操作コーディングタスクで完全非同期エージェントRLにかけ、NVIDIA GB300を64枚使って最初の30ステップの中央値263秒という実測を示す——というものです。

平たく言えば、これはアルゴリズムの論文ではなくインフラの技術報告です。読みどころは、フロンティア規模のRLが実際に何で壊れるのかを、著者たちが手を動かした結果として並べている点にあります。

比喩: 同じ譜面を二つの楽団が演奏している

RLのポストトレーニングは、乱暴に言えば「モデルに答えを書かせて、良し悪しを採点して、その採点を重みに反映する」だけです。ところが答えを書く側（推論エンジン）と、重みを直す側（トレーナー）は別のソフトウェアです。

同じ譜面（重み）を渡されても、二つの楽団は微妙に違う音を出します。使うカーネルが違い、精度が違い、バッチの組み方が違うからです。演奏そのものはどちらも正しいのに、採点係が「Aさんはこの音をこれくらいの確率で出すはずだ」と見積もった数字が、実際にAさんが出した音の確率と食い違う。この食い違いを論文は train-rollout mismatch と呼び、システム全体をこれを潰すために設計しています（§1）。厄介なのは、これがエラーを出さずに勾配だけを腐らせることです（§2）。

ループは3段、ただし同期させると待ちが出る

Milesのループは3段です（§1.1）。

1. ロールアウト: SGLangエンジンが軌跡（trajectory）を生成する。エージェント的RLでは、1本の軌跡は複数ターンにわたる一つのエピソード全体で、各セッションが隔離された環境（サンドボックス）とやり取りし、そこから報酬が返る。
2. 学習: Megatron-LMまたはFSDPが、完成した軌跡グループを消費してRL損失を計算し、方策を更新する。
3. 重み更新: 更新後の重みをロールアウトエンジンに同期する。

用語を一つだけ押さえてください。グループとは、同じプロンプトから生成された軌跡の集まりです。GRPOのような目的関数は、ある軌跡の良し悪しを「同じプロンプトの他の試行と比べて」決めるため、同じプロンプトの軌跡はまとめて生成し、まとめて消費する必要があります。だからMilesは1本単位ではなくグループ単位でスケジュールし、捨てます（§2）。

この3段を順番に回すと、ハードウェアが両側で遊びます。トレーナーはバッチ中いちばん遅い軌跡が返るまで待ち、そのあいだエンジンは今度はオプティマイザの完了を待つ。長文脈やツール使用のタスクでは、この待ち時間がバッチの大部分を占めます。そこでMilesは完全非同期モードを持ちます。エンジンは生成し続け、トレーナーはその時点で完成しているものを取ってバッチを組む（§2.2）。ただしこれは両方が同時にGPUを必要とするので、生成用と学習用でGPUプールを分ける配置（disaggregated）が前提です。同一GPUを共有する配置で完全非同期を指定すると、Milesは起動を拒否します。

非同期にすると「古いデータ」が生まれる

生成と学習を切り離すと、軌跡が作られた時点の重みと、それを学習する時点の重みがずれます。この古さを論文は staleness と定義しています。Milesの定義は「現在のトレーナーの重みバージョン − そのグループのどこかに現れる最も古い重みバージョン」です（§2.2.2）。マルチターンの軌跡は生成中に何度も重み更新をまたぐので、グループ内でトークンごとに世代が違います。Milesはあえて最も古いトークンに合わせる、悲観的な定義を採っています。

生成と学習のあいだには容量上限つきのバッファが置かれ、完成したグループはここに入ります。バッファはグループを3つの理由で捨てます（§2.2.2、Table 1）。

前2つはグループ自身の性質なので到着時に判定できますが、stalenessは「どれだけ待たされたか」に依存するので、トレーナーが取り出す瞬間にしか判定できない——この非対称性が設計に効いています。

論文が観測性（observability）に一節を割いているのも同じ理由です（§2.2.3）。非同期では生成側と学習側が別々の速度で進むため、片方が片方を追い越してもクラッシュせずに黙ってGPUを浪費します。Milesは毎ステップ queue_size / avg_staleness / max_staleness などを出力します。キューが0に張り付いていれば生成が足りず、容量上限に張り付いていればトレーナーが律速で、待機中グループのstalenessが一緒に上がっていく、という読み方です。

ズレを潰す(1): トークンを一字一句そろえる（TITO）

ここからが論文の芯です。ズレの原因を、Milesは構造的なものと数値的なものに分けて、3段構えで別々に潰します。まずトークンそのものが変わってしまう問題から（§2.4）。普通のマルチターン実装では、モデルの出力がメッセージのパース→ツール実行→チャットテンプレートの再レンダリングを通ってから次のターンに入ります。この過程でトークナイズが変わったり、思考部分が刈られたり、ツール呼び出しが再シリアライズされたりする。するとトレーナーは、実際には一度も起きなかった軌跡に対して更新をかけます。Milesはトークナイズの所有権をハーネスからサーバ側（session server）に移し、各ターンで確定したトークンID・対数確率・選ばれたエキスパートをチェックポイントとして保存し、次のターンは追記された差分だけをトークナイズします。エージェントがトークンを自前で渡してきても上書きします。

セッションの伸ばし方は2種類あります（§2.4.1）。linearは末尾しか伸ばせず、1セッション＝1本の学習系列。branchingは履歴を追記専用の木として保持し、枝ごとに学習系列が生まれます。Claude Codeのように走行中に自分の文脈を折りたたむ／分岐するハーネスは、事前に何本の軌跡になるか分からないので、linearでは扱えない——という指摘が具体的で良いところです。

この仕掛けは、正しいチャットテンプレートとツール呼び出しパーサの組み合わせに依存します。そのためMilesはチェックポイントから種類を自動判定しません。ユーザーが起動時に「モデルファミリー」を名指しし、その名前が、メンテナが検証済みの登録に解決される方式です（§2.4.3）。登録にはCPU上で「レンダリング結果がターンをまたいで追記のみか」を確認する検査と、GPU上で実モデルを動かして同じ不変条件が停止トークンやパーサを通しても保たれるかを確認する検査の2つが要ります。CPU側だけでは足りない——テンプレート単体では追記のみに見えても、実際のパーサが出力を食った瞬間に崩れることがあるから、というのがその理由です。

ズレを潰す(2): エキスパートの割り当てを再生する（R3）

MoEでは、ルータがエキスパートを点数付けして上位 $k$ 個を選びます。生成側と学習側で数値がわずかに違えば、選ばれるエキスパートが層ごと・トークンごとに独立に入れ替わりうる。論文の例では、生成時に $\{2,7\}$ が選ばれたトークンに対し、学習側が $\{2,8\}$ を選ぶ。すると寄与していないエキスパートが更新を受け、寄与したエキスパートは更新されません。Rollout Routing Replay（R3）は、選ばれたエキスパートの割り当てをロールアウトデータの一部として持ち回り、学習時に再計算せずそのまま再生します。

ただしコストは正直に書かれています。ルーティングのテンソルは