XTuner V1 を採用する前に読む: MoE 大規模学習エンジンの実装と制約

XTuner V1 が解こうとしている並列化のねじれ

大規模 MoE の学習では、expert ごとにパラメータを分散させる expert parallelism の次元をどこまで大きく取るかが調整点になる。次元を増やせばメモリは分散するが、token を expert の配置先へ送る通信が増え、dropless、つまり token を捨てずに全 expert へ振り分ける運用では負荷の偏りがそのまま通信の偏りになる。XTuner V1 はこの次元を従来の 3D 並列より小さく取る方向で設計されていると README は説明している。具体的には 200B 級の MoE を expert parallelism なしで学習でき、600B 級でもノード内 expert parallelism だけで足りるとしている。対象読者は、学術研究で使われる規模の MoE 事前学習を自前のクラスタで回そうとしているチームである。dense モデルの LoRA 的な微調整を手軽に済ませたい読者にとっては、関心の対象がずれている。

FSDP 系で 3D 並列のスループットを超えるという主張の位置づけ

README は、200B 規模を超える MoE において FSDP による学習スループットが従来の 3D 並列方式を上回ったと主張している。ここは読み方を分けておきたい。並列化の次元を減らすという設計判断は、通信量を削る代わりに各ランクが抱える状態を増やす方向に働く。したがってこの主張が成立する条件は、メモリ最適化によってその増加分を吸収できている場合に限られる。README が長系列の節で挙げている 64k シーケンス長・200B MoE を sequence parallelism なしで学習するという記述も、同じメモリ最適化の延長線上にある。ただし数値の内訳、比較に用いたクラスタ構成、ベースラインの実装は README からは読み取れない。導入検討の場でこの主張を根拠にするなら、自前の構成で再測定する必要がある。

対応モデルとハードウェアの表をどう読むか

README の対応表は、GPU(FP8)、GPU(BF16)、NPU(BF16) の三列でモデルごとの可否を示している。Intern S1、Intern VL、Qwen3 Dense、Qwen3 MoE は三列ともチェックが入っている。一方で GPT OSS、Deepseek V3、KIMI K2 は GPU の二列のみで、NPU(BF16) は工事中の記号になっている。README は Ascend NPU の最適化に特に注力すると書いており、Ascend A3 Supernode での学習効率が NVIDIA H800 を上回るとも述べている。だが同じ文書内の対応表では、NPU 側で未対応のモデルが三つ残っている。NPU を主軸に据えたい読者にとって、この表は注力方針と現状のギャップをそのまま示している。自分の使うモデルがどの列のどこに位置するかを最初に確認するのが、この表の実用的な使い方である。

長系列学習で expert の負荷偏りが問題になる理由

シーケンス長を伸ばすと、1 ステップあたりに含まれる token 数が増える。MoE では各 token が一部の expert にのみ割り当てられるため、長系列では特定の expert に割り当てが集中する局面が生じやすい。XTuner V1 は長系列学習中に expert の負荷が偏っても安定性を保つと README は述べている。これは dropless を掲げる以上避けて通れない論点で、token を捨てる設計なら偏りを切り落とせるが、捨てない設計では偏りをそのまま処理しきる必要がある。長系列対応として README が挙げる手段は二つある。メモリ最適化により 64k 長・200B MoE を sequence parallelism なしで扱う方法と、DeepSpeed Ulysses による sequence parallelism を使い、最大シーケンス長を線形に伸ばす方法である。前者は追加の並列次元を導入しない点で構成が単純になり、後者は長さを伸ばすほどプロセス数を増やせる。どちらを選ぶかは、手元のノード数とメモリ量で決まる。

学習以外に何が入っているか: アルゴリズムと推論連携

README のロードマップは、事前学習だけでなく指示微調整と強化学習までを対象に含めている。実装済みとして挙がっているのはマルチモーダル事前学習、マルチモーダル教師あり微調整、GRPO の三つである。MPO、DAPO、マルチターンの agentic RL はこれから来るものとして印が付けられている。推論エンジン連携では LMDeploy にチェックが入り、vLLM と SGLang は未チェックのままだ。強化学習の実装にあたっては veRL、SLIME、AReaL、OpenRLHF から知見を取り入れたと謝辞に記されている。ここで注意したいのは、ロードマップ上の未チェック項目は約束であって現在の機能ではないという点である。agentic RL や DAPO を前提に導入計画を立てるなら、実装状況をリポジトリ側で直接確認する必要がある。

導入時に確認する配布形態とバージョンの選び方

公開されているリリースは v1.0.1、v1.0.0rc0、v0.2.0 の三つである。最新の v1.0.1 には bk main というタグが付いており、v1.0.0rc0 はリリース候補の段階を示す rc を含む。V1 系が正式な安定版の系譜にまだ乗り切っていない可能性を示す情報なので、依存を固定する際はこの点を踏まえてバージョンを選ぶことになる。ライセンスは Apache-2.0 で、特許条項と変更点の明示を含む条項が付く。派生物を配布する場合の表示義務など、具体的な条件の解釈は法務の確認事項であり、ここで断定はしない。データ準備については GraphGen を使って微調整用の合成データを作れると README は案内している。学習用データの生成元を外部ツールに委ねる構成になる点は、再現性の観点で把握しておきたい。

Megatron 系や DeepSpeed 系と何が違うのか

比較対象として素直なのは、謝辞にも挙がっている Megatron と DeepSpeed である。Megatron 系の 3D 並列は、tensor、pipeline、expert の三次元を明示的に切り、それぞれの次元をクラスタ構成に合わせて設計する。柔軟だが、次元の組み合わせごとに設定と検証の負担が増える。DeepSpeed は ZeRO 系のメモリ分割を軸に据え、並列化の次元を明示的に切らずに状態を分割する。XTuner V1 は後者に近い側から出発しつつ、expert parallelism の次元を小さく取ることで MoE の dropless 運用に寄せている。つまり違いは、並列次元を設計変数として前面に出すか、メモリ最適化で次元そのものを減らすかである。どちらが優れているかではなく、クラスタの形状と運用チームの習熟度で決まる。既存の Megatron 資産と設定群をすでに運用しているチームにとって、乗り換えは並列化の考え方そのものを入れ替える作業になる。

どのチームが採用し、どのチームが待つべきか

採用が妥当なのは、200B 級以上の MoE を dropless で回す必要があり、expert parallelism の次元設計にコストを払いたくないチームである。長系列を sequence parallelism なしで扱いたい場合も、README が示すメモリ最適化の対象範囲に入る。逆に待つべきなのは、dense モデルの小規模な微調整だけが目的のチームと、NPU 上で Deepseek V3、KIMI K2、GPT OSS を動かしたいチームである。後者は対応表で工事中の記号が付いており、README 自身がそれを示している。導入前に確認する項目は三つある。第一に、対応表で自分のモデルとハードウェアの交点にチェックがあるか。第二に、v1.0.1 が bk main として公開されている配布形態が、自チームのバージョン固定運用に収まるか。第三に、FSDP が 3D 並列を上回るという主張を、自前のクラスタとベースライン実装で再測定できるか。この三つ目が測れないなら、README のスループット記述は判断材料から外しておくのが安全である。

編集部の結論

200B 級以上の MoE を dropless で回したい、かつ自前のクラスタで FSDP 系の並列化を試したいチームに向く。dense モデルの小規模ファインチューニングや、NPU で Deepseek V3 / KIMI K2 / GPT OSS を動かしたい場合には現時点で向かない。導入前に確認すべきは、README の対応表で自分のモデルとハードウェアの交点にチェックが入っているか、そして v1.0.1 が bk main ブランチとして公開されているという配布形態が自チームの依存管理に合うかである。

公式情報源

1. InternLM/xtuner on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases