マイクロソフトが「MAI-Base-2」の訓練レシピを公開：1万6000基のGPU、38日間で2.8兆パラメータモデルを訓練

マイクロソフトのAIチームが、次世代の最先端基盤モデルMAI-Base-2に関する事前訓練エンジニアリングの詳細を公開した。この混合エキスパート（MoE）モデルは、800億のアクティブパラメータ、総パラメータ2.8兆を備えている。1万6000基のNVIDIA GB200 GPUで構成されたクラスタ上で、チームは38日間をかけて50兆トークンの全量訓練を完了させ、ネイティブな視覚理解能力を基盤アーキテクチャに直接統合した。

総パラメータと訓練量は拡大したが、各トークンがアクティブ化するパラメータは依然として一部に抑えられている。また、視覚モダリティも事前訓練の段階から基盤に組み込まれている。

超大規模な訓練においては、小規模実験で選定された構成をスケールアップした際に過学習を起こすリスクがある。理論上は計算量を節約できるエキスパート構造であっても、VRAM割り当てやGPU間通信のボトルネックに直面することがある。マイクロソフトはこれらの一連の課題を包括的に処理した。まず小規模実験において大規模訓練のデータ反復パターンを再現し、その上でエキスパートのスケジューリング、オプティマイザ、データパイプラインを刷新した。レポートが明かしているのは単なるモデル規模にとどまらず、こうした選択が実際の訓練にどのように作用したかという点である。

事前訓練基盤と日常チャットAIのあいだには、どれほどの隔たりがあるのか？

日常的にAIを利用する人々の多くはChatGPTやCopilotとの対話に慣れ親しんでおり、「大規模モデルの発表」を「チャットボットのアップデート」と同義に捉えがちである。しかし、MAI-Base-2は事前訓練基盤モデル（Base Model）であり、膨大なコーパスの自己教師あり学習を通じて言語および世界知識の表現を獲得した段階であって、指示チューニング（SFT）や強化学習（RL）などの事後訓練（Post-training）プロセスはまだ経ていない。

両者の直感的な違いはインタラクションの形態にある。事前訓練基盤の核となるタスクは、先行する文脈に基づいて次のトークン（単語の構成要素）を予測することであり、入力された文章の流れに沿って続きを記述することを得意とする。これに対し、日常で用いられる対話モデルは、事後訓練によって指示を理解し、構造化された問答形式で回答するよう誘導されている。マイクロソフトの前世代モデルもその一例であり、MAI-Base-1は事後訓練を経てMAI-Thinking-1となった。

基盤モデルはダウンストリームタスクを通じて評価できるが、モデル間で交差エントロピー損失（Cross-Entropy Loss）を直接比較する場合、トークナイザ（Tokenizer）ごとのトークン分割粒度の違いによる影響を受ける。同一のテキストであってもトークナイザによって生成されるトークン数が異なるため、トークンあたりの損失を単純比較するのは公平ではない。

そのため、マイクロソフトは評価においてトークナイザに依存しない指標であるバイトあたりビット数（Bits-Per-Byte、略称BPB）を採用した。

（BPBは、モデルによるテキストの予測損失を元のバイト数で正規化し、未知のテキストを圧縮する際に1バイトあたり平均して必要となる理論的な情報ビット数を測定する指標である。BPBが低いほど、テストセットの確率分布をより正確に予測できていることを示す。）

コード（Code）、サードパーティ製カスタムQ&A（QA）、理工系科学技術（STEM）、数学（Math）を含む独立したホールドアウトテストセットにおいて、MAI-Base-2はそれぞれ0.2203、0.4162、0.3653、0.3561のBPBを記録し、比較対象となった他のベースラインモデルを上回る成績を収めた。

「効率が4〜12倍向上」はどのように算出されたのか？

マイクロソフトのレポートにある4.2倍〜12.3倍という数値は、DeepSeek-V4-Pro-Baseを比較基準とした訓練レシピの計算効率の向上幅である。

実際の訓練コストをFLOPsから直接換算することはできず、MAI-Base-2が最終的に実際に消費した訓練FLOPsもDeepSeek-V4-Pro-Baseを大幅に上回っている。「4.2〜12.3倍」というのは、マイクロソフトがフィッティング曲線に基づいて提示した同一BPBにおける計算効率（FLOPs-Efficiency）の比較である。

最終的な評価結果を直接比較してしまうと、訓練レシピ自体の効率と、消費された総計算量とを混同しやすくなる。レシピ単体の効率を切り分けて評価するため、研究チームは異なるモデル規模において独立したスケーリング則曲線をフィッティングし、DeepSeek-V4-Pro-Baseと同一のBPBに到達するために必要な理論計算量を推計した。その結果、コードタスクでは基準の約1/12.3、Q&Aタスクでは約1/4.2、理工および数学タスクではそれぞれ約1/8.3、約1/6.6の計算量で済むことが示された。前世代のMAI-Base-1と比較しても、レシピ効率は6.3倍〜12.7倍向上している。

このフィッティング曲線にはMAI-Base-2の最終実測値が含まれているため、基準となる比較点は既知モデルのフィッティング区間内に位置している（外挿ではなく内挿にあたる）。マイクロソフトは計算リソースの総支出を抑えたのではなく、より高効率なレシピを活用して、総パラメータ2.8兆に達するさらに巨大なモデルを訓練したのである。

小規模モデルにも求められる、大規模モデルの「反復学習」体験

超大規模な訓練に着手する前に、エンジニアリングチームはより小さなスケールのモデルでアーキテクチャやハイパーパラメータを探索する必要がある。そのためにマイクロソフトはマルチスケールの実験ラダーを構築し、各ステップにおいてTPP（Training Tokens per active Parameter、アクティブパラメータあたりの訓練トークン数）を一定に保つことで、モデルのパラメータ数と訓練データ量を連動させて比例的に調整した。

しかし、小規模な実験において全データをそのまま使用すると、データ反復エポック数の歪みという問題が生じる。

たとえば、ある特定のデータソースが50兆トークンの全量訓練において8回反復学習される設計であるのに対し、小規模実験には5兆トークンのバジェットしか割り当てられていないとする。ここで全量データをそのまま小規模モデルに投入すると、そのデータソースを1周すら読み切れなくなる可能性がある。これにより、小規模実験では複数回の反復学習が欠落するため、正則化が不十分なアーキテクチャやハイパーパラメータ設定が有利と判定されてしまい、大規模な多重反復訓練へとスケールアップした際に過学習を招く原因となる。

この歪みを解消するため、マイクロソフトはソースデータスケーリング（Source Scaling）機構を採用した。ラダーの小規模モデル実験において、独立したサンプル規模を人為的に比例縮小するのである。前述のデータソースを例にとれば、5兆トークンの小規模実験では独立サンプルのうち1/10のみをサンプリングし、同様に8回ループさせる。これにより、固定されたTPPのもとで独立データとパラメータの比率を安定して維持できるようにした。

データのスケールだけでなく、ハイパーパラメータの選定も同様に複雑である。大規模モデルの訓練では複数のハイパーパラメータが互いに影響を及ぼし合い、1つを変更すると別の最適な値が変動することが多い。学習率（LR）とウェイトディケイ（WD）を例にとると、前者はステップごとの更新幅を制御し、後者は重みの過剰な増大を抑えるが、マイクロソフトの実験系においてモデル性能は両者の積である LR × WD に対して最も敏感に反応した。この相互干渉により、良好な性能を示すハイパーパラメータの組み合わせは、(log LR, log WD) 平面上の狭く傾いた対角バンド領域に強く集中することになった。

もし一般的な矩形グリッド探索を (log LR, log WD) 平面上で直接行うと、多数の実験ポイントが狭いバンドの外側に落ちてしまい、計算資源を浪費するばかりか有望な組み合わせを密に探索することが困難になる。そこでチームは探索座標系を刷新し、(log LR, log (LR × WD)) 空間上にグリッドを配置することで、従来対角バンドに集中していた好適な組み合わせを効率的にカバーした。多様なモデルサイズおよびTPPのもとでモデルを訓練し、評価結果に対して2変数の2次曲面をフィッティングして解析的な極値を算出することで、最終的にMAI-Base-2のハイパーパラメータを決定する以下の経験式を導き出した。

LR* × WD* = 17.04 / steps

log LR* = −1.51 + 0.175 log TPP − 0.573 log steps

ここで steps は総訓練ステップ数、TPP はアクティブパラメータあたりの訓練トークン数である。数式において LR* × WD* が訓練ステップ数に反比例していることは、デカップルされたウェイトディケイの時間スケールが訓練ステップ数の固定比率に相当することを反映している。また、ステップ数に対する LR* の指数 -0.573 は -0.5 に近く、他の訓練条件が一定である場合にバッチサイズを2倍にすると学習率を √2 倍に調整するという一般的な経験則とも整合している。

パラメータのごく一部しか使わないのに、なぜ実行速度が落ちるのか？

MAI-Base-2は102層のネットワーク構成を持つ。各層は1つの常駐型共有エキスパート（Shared Expert）と、512個のルーティングエキスパートから動的にアクティブ化される7個のエキスパートで構成される。つまり、1つのトークンが1層を通過する際にアクティブになる計算ブランチはごく一部であり、ネットワーク全体の総パラメータ2.8兆のうち、単一トークンに対して実際にアクティブ化されるパラメータは約800億にとどまる。

アーキテクチャの選定にあたり、マイクロソフトは評価損失の目標値を同一に固定した上で、訓練計算量（FLOPs）と実際の所要時間をそれぞれ比較した。現状では主に実際の所要時間に基づいて構成が選定されている。それが既存クラスタ上で真に発揮される実行効率を反映しているためである。仮に計算量を節約できる設計であっても実効速度が遅くなる場合、その乖離こそが今後のインフラ最適化で取り組むべき課題を示すことになる。

疎（Sparse）なMoEは、ステップあたりの計算量を抑えつつ、より大きな総パラメータ数を保持することができる。これまでのモデリング実験から、全層にMoEを導入する方が密なFFNとMoEを交互に配置するよりも計算量を節約できることが判明していた。しかし実際のハードウェア実行においては、動的ルーティングがVRAMの断片化を引き起こし、細粒度なエキスパート構成はスケジューリングやGPU間通信のオーバーヘッドを増大させる。前世代のMAI-Base-1ではMoEの低レベル実装効率に制約があったため、1層おきにMoEと密なFFNを交互に配置する折衷案が、実際の所要時間の観点から最も優れていた。これに対しMAI-Base-2では、VRAM利用効率とエキスパートスケジューリングのボトルネックを改善したことで、MoE計算層のモデルFLOPs利用率（MFU）を24%から35%へと引き上げ、全102層へのMoE採用を実現した。38日間の全量訓練において、クラスタ全体の全期間平均MFUは21%（GB200の1基あたりBF16理論ピーク性能2.5 PFLOPSを基準とし、活性化の再計算やオプティマイザの演算は除外）、goodputは89%（訓練が有効に進行した時間の割合を測る指標）を記録した。これらはそれぞれ有効な計算効率と有効稼働時間に対応するものであり、単なるGPU使用率と混同してはならない。

MoE層の効率を向上させた重要な改良の1つが、マルチラウンド・ドロップレススケジューリング（Multi-round Dropless MoE）である。

MoEのルーティングネットワークはデータ駆動で学習されるため、エキスパート間の負荷は均等にはならない。特定のエキスパートに過剰なトークンが集中すると、VRAMの容量超過を招きやすい。従来の手法のように固定しきい値を設けて溢れたトークンをドロップすると、実験上モデルの訓練性能が低下することが示されている。一方で、極端な不均衡という最悪ケースを想定して各エキスパートに過剰なVRAMをあらかじめ確保しておくと、平常時のVRAMが遊休状態となり、活性化再計算（Activation Recomputation）の削減に充当できたはずのメモリ領域を圧迫してしまう。

マイクロソフトのアプローチは、各エキスパート並列ランク（Expert Parallel Rank）上のエキスパートを固定のエキスパートグループ（Expert Group）に分割し、1ラウンドあたりの固定トークン容量を割り当てるというものである。

1. グループ内容量の共有： グループ内の特定のエキスパートでトークンが溢れた場合、同一グループ内の他のエキスパートの空き容量を優先して融通する。
2. マルチラウンド・パイプラインによる救済： エキスパートグループの総容量でも全トークンを収容できない場合、溢れた分は追加ラウンドに送られて処理を継続し、トークンのドロップを回避する。追加ラウンドは余分な計算を発生させ、MFUを低下させる要因となる。
3. 通信と計算のパイプラインオーバーラップ： ディスパッチ（Dispatch）、計算（Compute）、収集（Collect）が各エキスパートグループおよびラウンド間でパイプライン状にオーバーラップして実行される。順伝播（Forward pass）では、第1ラウンドのディスパッチと最終ラウンドの収集に一部露出する所要時間が残るものの、通信は主にエキスパート計算および共有エキスパート計算と並行してオーバーラップする。逆伝播（Backward pass）では、入力のディスパッチが当該層の活性化再計算と重なり、勾配の収集が重み勾配の計算とオーバーラップする。

エキスパートのトークン容量自体が設定可能なトレードオフ項目である。バッファ容量を大きく割り当てるとより多くのVRAMを消費し、小さすぎると追加ラウンドと余剰計算が増大するリスクがある。実際の訓練では、定常状態において1ラウンドで処理が完結するよう調整されている。

さらにチームは、GPUから直接All-to-All通信を開始し、対称メモリ（Symmetric Memory）を活用してNVLink経由でトークンを直接交換するとともに、各層のロードバランシング損失をグローバルな1回のAll-Reduceに集約することで、細粒度エキスパートに起因する低レベルのスケジューリングオーバーヘッドを削減した。

パラメータの更新をより速く、より安定させるには？

大規模クラスタでの訓練において、オプティマイザの設計と数値的安定性は訓練を円滑に進める上で極めて重要である。

MAI-Base-2において、マイクロソフトは埋め込み層以外の2次元行列パラメータに対してMuonオプティマイザを採用し、AdamWも併用した（埋め込み層などのパラメータに使用）。この規模へと拡張する過程で、AdamWと比較してMuonがより安定した訓練ダイナミクスと顕著な効率向上をもたらすことをチームは見出した。Muonの核となるのは、Newton–Schulz反復アルゴリズムを用いて重み行列のモメンタムを直交化する処理であり、このアルゴリズムは複数ラウンドの行列積演算で構成されている。

しかし、これは大規模分散訓練において根本的な矛盾に直面した。VRAMを節約するためにZeROアーキテクチャはオプティマイザのモメンタムをシャード（断片）に分割して各GPUに分散配置するが、Newton–Schulzアルゴリズムは完全な2次元行列積に依存しており、孤立したシャード上で直接実行することはできない。そこでチームはオプティマイザのステップにおいてモメンタムのバッチ再構成（Resharding）を実施した。まず各GPUがローカルでFP32のモメンタムシャードを更新してBF16に変換し、バッチ化されたAll-to-All通信によって完全なモメンタム行列を復元して、各GPUが複数ある完全な行列のうち一部を担当して保持する。続いて各GPUがローカルで対称構造を意識したNewton–Schulzカーネルを呼び出して直交化計算を完了させる。最後に2回目のAll-to-All通信を通じて更新結果を元のシャードへと送り返し、FP32へと再変換した上で重みに適用する。

再構成メタデータのキャッシュやプリフェッチなどの最適化を経て、Muonフェーズの平均所要時間は165ミリ秒となり、訓練の1ステップあたりのイテレーション時間の2.1%を占めるにとどまった。通信ボトルネックに基づいて試算された理論限界値は約55ミリ秒であり、実測時間は理論値の約3倍となった（この主な差異は、各ノードの遅延（straggler）、カーネル起動オーバーヘッド、負荷の不均衡、メモリコピーなどに起因する）。

訓練を安定させるもう1つの手法が、活性化勾配クリッピング（Activation Gradient Clipping）である。 通常の事前訓練では、バッチ全体の重み勾配ノルム（Global Norm）に対してクリッピングを行うのが一般的である。しかし、バッチ内に少数の異常サンプルが含まれている場合、グローバルクリッピングはバッチ内の正常なサンプルの勾配までも一律に比例縮小してしまう。

この問題を緩和するため、マイクロソフトはネットワークの特定位置において、活性化値自体の出力ではなく、活性化値の勾配に対するクリッピングを適用した。このような局所的制限は、異常勾配がバッチ全体の勾配に及ぼす巻き添え的な縮小影響を軽減するのに役立つ。実際の訓練においてMuonなどの最適化レシピと組み合わせることで、MAI-Base-2の勾配ノルムの変動幅は前世代と比較して顕著に狭まった。ただし、勾配の中央値の絶対値が全行程にわたって低くなったわけではない。レポートに示された訓練損失曲線でも、第2世代は全訓練期間を通じて前世代よりも滑らかに推移していることが確認されており、これは複数のレシピ変更が複合的に作用した結果の観測である。

この技術がもたらす効率ゲインはモデル規模の拡大に伴って段階的に向上し、18層時点の約2%から42層時点では28%に達した。

さらに、活性化勾配クリッピングはチームによるデータ異常の特定にも寄与した。たとえばコードコーパスにおいてクリッピングを発火させたある異常サンプルでは、Apacheオープンソースライセンスのテキストが distributed under の箇所で不自然に途切れた直後に、プルリクエストのタイトル # PR Title が結合されていた。チームはこれを手がかりに、前処理パイプラインにおけるトークン分割の欠陥を特定し、修正を施すことができた。

データ基盤：50兆トークンはいかにして調合されたのか？

データの構築に関して、マイクロソフトのレポートは独自構築のデータパイプラインとデータトレーサビリティ（Data Provenance）を強調しており、訓練データはすべて自社によるネイティブ収集と社内クリーニングによるもので、他モデルからの蒸留データは使用していないと表明している。

ウェブページの収集量を増やしても、モデルがそれに比例して多くの新たな情報を学べるわけではない。たとえば、類似した複数のウェブページが同一の事象を繰り返し記述している場合、ページ数が増えても新規に獲得できる情報は極めて限られる。マイクロソフトはウェブページのパース、品質分類、トピック別の分類、重複排除の手法を改良した。すなわちウェブコンテンツをクレンジングし、品質と該当トピックを判定した上で、重複した素材を削減した。これに加えてチームは、ベクトル埋め込み（Embedding）に基づく多様性サンプリングを採用し、コンテンツの意味的特徴に基づいて新規性の高いデータを優先的に選択することで、類似コンテンツの重複を一段と削減した。

MAI-Base-1と比較して、MAI-Base-2のコーパスにおけるユニークトークン（Unique Tokens）の規模は約36%拡張され、全量訓練で処理されたトークン総量は50兆に達した（複数ラウンドの反復学習を含む）。

コードは依然として最大のソースである。訓練ミックスに占めるシェアは55%から45%へと低下したものの、ユニークトークン量は34%増加しており、シェアの低下がコンテンツの減少を意味するわけではない。50兆の訓練トークンからなる全体の混合プールにおいて、各データソースの構成比は、コード系45%、ウェブコンテンツ12%、純粋な視覚（Vision-only）14%、理工系科学技術9%、PDF 9%、書籍5%、数学4%、その他2%となっている。

ここで図表に示されている14%は純粋な視覚（Vision-only）トークンであり、レポートが指摘するVLM（ビジョン・ランゲージ・マルチモーダル）コーパスは50兆の訓練総量のうち18%（反復を含め換算すると約9兆の訓練トークン）を占め、その中に4.5兆のユニークVLMトークンが含まれている。両者は集計基準が異なっており、画像とテキストが混在するドキュメントなどのデータは分類集計時に他のソースにも併せて計上されている可能性がある。

前世代MAI-Base-1のテキスト専用アーキテクチャとは異なり、MAI-Base-2は独立したビジョンエンコーダを持たない（Encoder-free）ネイティブな画像・テキスト事前訓練アーキテクチャへと移行し、基盤モデル内で視覚トークンを直接処理する。訓練の入力には画像とテキストのペアに加え、テキストと画像が混在したドキュメントが含まれる。コーパスはチャート理解、空間推論、コンピュータ操作、楽譜の読解などのタスクを網羅している。（これらは訓練コーパスが網羅するタスクであり、レポートではそれらの個別の評価成績は公表されていない。）

データ、モデル、システムを一体で掌握するマイクロソフト

MAI-Base-2の事前訓練の実践は、ハードウェアとソフトウェアのフルスタックな協調最適化の価値を示している。

データパイプライン、モデルアーキテクチャ、クラスタインフラの統合的なチューニングを通じて、エンジニアリングチームは与えられた計算バジェット内でより高効率な学習を実現し、小規模実験ラダーを通じて大規模訓練に対する比較的信頼性の高い指針を得ることができた。

ビジネスおよび応用の観点において、マイクロソフトは全プロセスの自社データ構築とトレーサビリティの確保について、将来的にFoundryプラットフォームを通じて信頼できるパートナー向けにモデル重みのライセンス提供を行うことを想定したものであるとしている。現時点でMAI-Base-2は依然として事後訓練段階にあり、一般向けには提供されておらず、関連するAPIや価格情報も公開されていない。一方で、次世代となるMAI-Base-3の準備作業もすでに始動している。