MoEの学習はなぜ通信で遅くなる？Olmo-core 3が変えたGPUの使い方｜2026年10月6日版
巨大なAIモデルを効率よく学習させるには、計算量を減らすだけでは足りません。GPUの間で何を動かすかが、学習速度を左右します。
Ai2が2026年10月1日に発表した「Olmo-core 3」は、MoE（Mixture-of-Experts）向けの学習基盤を刷新しました。核心は、専門家ネットワークの重みをGPUに置いたまま、処理するデータをそこへ送る設計です。従来の自社実装で繰り返していた重みの収集を避け、通信の負担を減らします。
2026年10月6日、日本時間時点で確認できる公式情報をもとに、この変更が何を解決し、どこまで実証されているかを整理します。
- MoEは入力ごとに一部のネットワークを選び、計算量を抑える仕組みです。
- 使わない部分もGPUメモリには保存する必要があり、分散配置すると通信が発生します。
- Olmo-core 3の進展は、モデルの大きさだけでなく、重みと入力データの動かし方にあります。
MoEは「一部だけ使う」からこそ、データの配送が難しい
MoEは、複数の専門家ネットワークから入力に応じて使うものを選びます。ここでいう「専門家」は人ではなく、モデル内部の計算を担当するネットワークです。
すべてのパラメータを毎回使う方式と違い、専門家を増やしても、入力ごとに選ぶ数を一定にすれば計算量の増加を抑えられます。ただし、モデル全体を保存するためのメモリは必要です。
そこで専門家を複数のGPUに分けて配置します。すると今度は、入力を担当するGPUと、選ばれた専門家を持つGPUが異なる場面が生まれます。入力の表現を送り、計算結果を戻す作業が必要になるわけです。
計算を省いた効果が、通信待ちで失われることがある。 これが大規模MoEの難しさです。Ai2の公式発表も、専門家へのデータ配送と調整のコストが、MoEの効率を損なう問題を挙げています。
Olmo-core 3は重みを置き、データを動かす
今回の変更は、計算に必要なものをどのタイミングで集めるかにあります。
Ai2の以前のMoE実装では、FSDPという分散学習方式を使い、小さな学習バッチごとにモデルの重みを集め、再び分割する構成を採っていました。Olmo-core 3はDDPを基礎とする構成へ切り替え、専門家をGPUに常駐させます。
処理の流れを単純化すると、次の違いです。
- 以前の構成： 計算のために必要な重みを繰り返し集める。
- 新しい構成： 専門家の重みを配置したGPUへ、対応する入力データを送る。
これはFSDP全般がMoEに使えないという意味ではありません。Ai2が自社の従来構成で発生していた通信を見直した、という変更です。
また、専門家をGPUに常駐させても、GPU間通信がなくなるわけではありません。データを送る先の決定、配送、結果の回収は残ります。改善の焦点は、必要な通信を整理し、重みを繰り返し集める負担を避けることです。
分散する対象は専門家だけではない
学習では重み以外にもメモリを使います。Olmo-core 3は、次の仕組みを組み合わせます。
- 専門家並列： 専門家をGPU間で分けて保持する。
- パイプライン並列： モデルの層をGPUのグループに分ける。
- 分散オプティマイザー： 学習更新に必要な追加データをGPU間で分担する。
それぞれが異なるメモリ負担を受け持ちます。専門家の数だけを増やせばよいわけではなく、層の配置や更新用データまで含めて設計する必要があります。
「約2.7倍」は何を測った数字か
Ai2は、NVIDIA B300を8基使った予備的な試験で、470億パラメータのMoEを比較しました。
- 以前の実装：GPUあたり毎秒19,400トークン。
- 新しい実装：GPUあたり毎秒52,000トークン。
- 学習処理量の差：約2.7倍。
この比較が示すのは、指定された構成での学習スループットの改善です。回答の正確さが2.7倍になった数字でも、チャットの応答速度を測った数字でもありません。比較対象も、Ai2の以前の実装です。
別の実験では、入力ごとに選ぶ専門家を4つに保ちながら、専門家の総数を8から128へ増やしています。総パラメータ数は46億から470億へ増えた一方、学習スループットの低下は5％未満でした。
ここから読み取れるのは、使う部分の規模をほぼ固定したまま、保存するモデルの容量を増やせたということです。追加した専門家が実際にどれほど能力を高めるかは、学習後の評価で確かめる別の問題です。
公開コードを使う開発者が確認すべきこと
日本の研究室や企業の学習基盤担当者にとって、今回の公開は、MoEを分散学習させる実装を調べ、手元の設備に合わせて検証できる材料になります。
公式GitHubでは、PyTorchを基礎にしたライブラリと学習スクリプトが公開されています。ただし、導入時には本体だけでなく、使う機能に応じた追加依存関係も確認が必要です。
READMEには、MoE向けのgrouped_gemmなどの依存関係が記載されています。公開Dockerイメージについても、GPUやドライバー、CUDAの違いによって自分のクラスタでは動かない場合があると説明しています。
実務では、まず次の順で確かめるのが合理的です。
- 使用するGPUとソフトウェアの組み合わせで動くか。
- 想定するモデルがGPUメモリに収まるか。
- 実際の入力データで学習処理量が改善するか。
- 保存と再開を含め、必要な学習時間で安定して運用できるか。
これは導入判断のための確認項目です。公開された速度差を、そのまま自社設備の費用削減率に置き換えることはできません。
一般の生成AI利用者については、この発表だけで利用中のサービスが高速化するわけではありません。今回公開された中心は、モデルを作る側の学習基盤です。
継続ウォッチ：通信の改善が長い学習でも効くか
次に見るべきなのは、短い測定で出た速度が、実際の学習で維持されるかです。
- 専門家への負荷の偏り： 一部のGPUだけが忙しくなり、ほかが待つ状態を抑えられるか。
- 設備による差： GPU間の接続やクラスタ構成が変わっても、改善が再現するか。
- 学習後の能力： 専門家を増やしたモデルが、必要なタスクで品質を上げられるか。
MoEを評価するときは、「総パラメータ数」と「入力ごとに使うパラメータ数」に加え、データを運ぶ時間も見る必要があります。手元で比較するなら、まず同じGPU、同じ入力、同じモデル条件をそろえる。Olmo-core 3の速度差を実務の判断材料にする出発点は、そこにあります。