# Mixture-of-Experts ## 定義 Mixture-of-Experts(MoE)は、FFN を疎に活性化する形に置き換える Transformer の変種アーキテクチャ。複数の expert network(異なる訓練データの部分集合を処理)と gate network(ルーティングアルゴリズムで token を expert に割り当てる)からなり、入力ごとに一部の expert のみを活性化する[[条件付き計算]]により、パラメータ数を大幅に増やしても計算コストの増加を抑える。これにより 1 兆規模超のパラメータの訓練が可能になる。([[Efficient Training of Large Language Models on Distributed Infrastructures]] §2.1, §4.1.5) 本サーベイは Mixtral 8x7B・DeepSeek2 を使用例として挙げる。 MoE の原型は Jacobs et al. (1991) による Mixture of Experts に遡るが、現代的なスパースゲート MoE の基盤を確立したのは [[@2017__ICLR__Outrageously Large Neural Networks The Sparsely-Gated Mixture-of-Experts Layer]](Shazeer et al., Google Brain, 2017) である。同論文は LSTM スタック間に MoE 層を挿入し、top-k 個のエキスパートのみを活性化するスパースゲーティングにより計算量を抑えつつ容量を最大 1000 倍にスケールできることを示した。2048 エキスパート・最大 137B パラメータで言語モデリング(1 Billion Word Benchmark)と機械翻訳のベンチマーク双方で当時の最高性能を達成した。[[負荷分散]] 課題(特定エキスパートへのトークン集中)に対して重要度損失(importance loss)と負荷損失(load loss)の補助損失を導入した点は、後続モデルが解決策を更新し続ける中心問題となっている。 分散訓練では **Expert Parallelism**(expert を worker 間に分散)として実現され、3 つの技術課題を持つ: - **Sparse Activation**: GShard(All-to-All で expert を協調)、Switch Transformer(top-1 routing)、Megablocks(Block Sparse MatMul で token dropping を回避)等。 - **Communication Optimization**: expert 間の **All-to-All がボトルネック**。Tutel/FasterMoE(計算と通信のオーバーラップ)、Lina(All-to-All を AllReduce より優先)、Janus(データ中心に expert を移動)等。 - **Load Balance**: 人気のある expert への token 集中による不均衡。FasterMoE(shadowing experts)、SmartMoE/FlexMoE(動的な expert 配置)、Prophet 等。 ## 子概念 - [[AIデータセンタートポロジ]] - [[LLM分散学習]] - [[LLM推論設計空間探索]] - [[Prefill-Decode分離]] - [[エージェントネイティブ RL]] - [[マルチトークン予測]] - [[メガカーネル]] - [[モデル圧縮]] - [[条件付き計算]] - [[負荷分散]] ## 横断的知見 - **スパースゲート MoE の 2017 年論文は「容量 1000 倍・計算増は小規模」という設計原則を最初に定量実証した**: [[@2017__ICLR__Outrageously Large Neural Networks The Sparsely-Gated Mixture-of-Experts Layer]] は LSTM 語言モデルにおいて 1B → 137B パラメータへのスケールアップを、訓練/推論計算量を一定に保ちながら達成した。重要なのは同論文が top-1 でなく top-k(k=2–4)のゲーティングで訓練安定性を確保しつつ、ゲートの出力が 0 の場合はバックプロパゲーションが発生しないことを利用してスパース性を計算効率に転換した点である。後続の GShard(top-2)・Switch Transformer(top-1)・DeepSeek-V3(細粒度 256 エキスパート/top-8)はいずれもこの top-k スパースゲーティングを継承しつつ、k の選択・エキスパート粒度・補助損失の設計を更新している。(Source: [[@2017__ICLR__Outrageously Large Neural Networks The Sparsely-Gated Mixture-of-Experts Layer]], [[Efficient Large Language Models - A Survey]]) - **2017 年の負荷分散手法(重要度損失 + 負荷損失)から、2024–2026 年のゲーティングバイアス動的調整・シグモイドゲーティングへの系譜**: Shazeer et al. 2017 は全エキスパートへの累積ソフトマックス重みの分散(重要度損失)と、スムージングされた負荷推定の分散(負荷損失)を組み合わせた補助損失で負荷分散を行った。DeepSeek-V3 はこの補助損失に依存せず、バッチ単位の負荷監視でゲーティングバイアスをヒューリスティックに更新する第 4 の方向を提示し([[@2024__arXiv__DeepSeek-V3 Technical Report]])、MiniMax-M2 はシグモイドゲーティング + 学習可能バイアスで負荷分散を暗黙的に達成した([[@2026__arXiv__The MiniMax-M2 Series - Mini Activations Unleashing Max Real-World Intelligence]])。2017 年の課題設定は変わらないが、解法はモデル層・システム層・アーキテクチャ層に分散している。(Source: [[@2017__ICLR__Outrageously Large Neural Networks The Sparsely-Gated Mixture-of-Experts Layer]], [[@2024__arXiv__DeepSeek-V3 Technical Report]], [[@2026__arXiv__The MiniMax-M2 Series - Mini Activations Unleashing Max Real-World Intelligence]]) - **2017 年の「ネットワーク帯域がボトルネック」という予言は、2024–2026 年のシステム研究が複数の角度から追認した**: Shazeer et al. 2017 はデータ並列の場合でもエキスパートへのトークンディスパッチ通信が支配的になることを指摘した。この予言は FAST([[@2026__NSDI__FAST - An Efficient Scheduler for All-to-All GPU Communication]]、AllToAllv が訓練時間の 30–56% を占める)・Guard([[@2026__MLSys2026__Guard - Scalable Straggler Detection and Node Health Management for Large-Scale Training]]、MoE の 2 同期点による影響増幅)・DualPipe([[@2024__arXiv__DeepSeek-V3 Technical Report]]、All-to-All 完全隠蔽)が実測で追認した。2017 年は単一マシン 8 GPU 実験での観察だったが、現代の分散実装ではクロスノード Expert Parallelism が通信ボトルネックをさらに深刻化させている。(Source: [[@2017__ICLR__Outrageously Large Neural Networks The Sparsely-Gated Mixture-of-Experts Layer]], [[@2026__NSDI__FAST - An Efficient Scheduler for All-to-All GPU Communication]], [[@2024__arXiv__DeepSeek-V3 Technical Report]]) - **MoE は LLM 訓練インフラから時系列基盤モデルへ適用領域を広げている**: [[Efficient Training of Large Language Models on Distributed Infrastructures]] が MoE を「1 兆規模超のパラメータ訓練を可能にする条件付き計算」(Mixtral 8x7B・DeepSeek2)として LLM 文脈で扱うのに対し、TSFM サーベイ [[@2025__arXiv__Foundation Models for Time Series - A Survey]] は **Time-MOE**(decoder-only・2.4B パラメータ・309B 点)を MoE ベースの[[時系列基盤モデル]]として紹介する。Time-MOE は FFN を MoE 層に置換し入力ごとに expert の部分集合を活性化することで、時系列でも billion-scale を計算コストを抑えつつ実現する——MoE の「パラメータを増やしても計算を抑える」性質がドメインを越えて TSFM のスケール手段に転用された例。(Source: [[Efficient Training of Large Language Models on Distributed Infrastructures]], [[@2025__arXiv__Foundation Models for Time Series - A Survey]]) - **routing collapse / expert imbalance はレイヤを問わず MoE の中心課題で、対処法が分かれる**: 分散訓練サーベイは人気 expert への token 集中による負荷不均衡を **load balance** 技術(FasterMoE の shadowing・SmartMoE/FlexMoE の動的配置)で扱う。Time-MOE は同じ expert 偏りを訓練目的関数の **auxiliary loss**(expert 使用を均衡させる補助損失)で抑え、最終損失を多解像度の自己回帰予測誤差 + auxiliary balance loss で構成する([[@2025__arXiv__Foundation Models for Time Series - A Survey]] §4.3.2)。同一問題に対しシステム層(配置の最適化)とモデル層(損失設計)の異なる解が立つ。(Source: [[Efficient Training of Large Language Models on Distributed Infrastructures]], [[@2025__arXiv__Foundation Models for Time Series - A Survey]]) - **MoE の AllToAllv は訓練時間の 30–56% を占め「スケジューリング不可」という前提が崩れた**: [[Efficient Training of Large Language Models on Distributed Infrastructures]] がコミュニケーション最適化を「Tutel/Lina による計算と通信のオーバーラップ」として整理するのに対し、[[@2026__NSDI__FAST - An Efficient Scheduler for All-to-All GPU Communication]] は MoE AllToAllv がゲーティング関数により数百ミリ秒ごとにパターンが変化する動的ワークロードであり、かつ GPU 対間の転送量が最大 12× ばらつく歪みを持つという 2 点を実測で示す。そのうえで Birkhoff 分解と 2 フェーズ設計でオンライン・スケジューリングが現実的に可能なことを示した。AllToAllv の 30–56% という訓練時間占有率と、RCCL 比最大 4.48× のスループット向上は、MoE の通信ボトルネックがスケジューリング対象として成立することを補強する。(Source: [[@2026__NSDI__FAST - An Efficient Scheduler for All-to-All GPU Communication]], [[Efficient Training of Large Language Models on Distributed Infrastructures]]) - **MoE の動的ルーティングは実行時計装でしか捉えられず、推論のボトルネックを観測すると訓練の想定と違う姿が見える**: 訓練系サーベイが MoE を「All-to-All 通信ボトルネック」「expert 負荷不均衡」として扱うのに対し、推論([[LLM推論]])を細粒度に観測する論文は別の律速を見つける。[[@2026__MLSys2026__ProfInfer - An eBPF-based Fine-Grained LLM Inference Profiler]] はエッジ推論で活性化エキスパート ID と「距離」(前回活性化からのトークン距離)を eBPF で追跡し、long-distance なエキスパートがメインメモリから evict されるため **MoE のボトルネックはメモリ帯域でなくディスク I/O** だと結論する(Qwen1.5-MoE-A2.7B-Q4 は 4-bit でも 8.9GB で mmap でしか動かない)。[[@2025__eBPF__eInfer - Unlocking Fine-Grained Tracing for Distributed LLM Inference with eBPF]] も MoE ルーティング挙動を観測対象に挙げる。動的に選ばれる expert は静的グラフ解析では捉えられず([[動的計装]])、訓練の「通信/負荷」像と推論の「メモリ階層/IO」像という観測面の違いが立つ。(Source: [[@2026__MLSys2026__ProfInfer - An eBPF-based Fine-Grained LLM Inference Profiler]], [[@2025__eBPF__eInfer - Unlocking Fine-Grained Tracing for Distributed LLM Inference with eBPF]]) - **MoE ベース LLM はパラメータ効率と推論速度を両立するが、アルゴリズムとシステムの二重最適化を要する**: [[Efficient Large Language Models - A Survey]] は MoE ベース LLM のタクソノミーを体系化し、GShard（600B 以上のスパースゲート MoE）、Switch Transformer（2,048 エキスパート・1 兆パラメータ）、Mixtral 8x7B（46.7B 総パラメータだが推論時は 12.9B のみ活性化し LLaMA-2 70B を MMLU・MBPP・GSM-8K で凌駕しつつ 6 倍高速推論）を位置づける。アルゴリズムレベルでは Expert Choice（トークンでなくエキスパートが top-k を選択）、StableMoE（2 段学習でルーティング安定化）、Lifelong-MoE（エキスパート層追加による継続事前学習）が、システムレベルでは FasterMoE（1.37–17.87 倍高速化）、MegaBlocks（ドロップレス MoE でブロックスパース演算、Tutel 比 40% 短縮）、SmartMoE（ハイブリッド並列戦略の自動探索で FasterMoE 比 1.88 倍）がそれぞれ独立に進む。分散訓練サーベイ [[Efficient Training of Large Language Models on Distributed Infrastructures]] が通信/負荷分散を中心に扱うのに対し、Wan+ はアルゴリズム側（ルーティング戦略・安定性・タスク適応）とシステム側（トポロジ対応・エッジ推論・動的パイプライン）の両面を網羅しており、2 つのサーベイは相補的な粒度で MoE を描写する。(Source: [[Efficient Large Language Models - A Survey]], [[Efficient Training of Large Language Models on Distributed Infrastructures]]) - **MoE のスパーシティスケーリング則が実証され「固定 FLOPS でスパーシティを上げるだけで性能向上」が設計原則に昇格しつつある**: [[Kimi K2]] は Muon オプティマイザ下で固定活性化パラメータ(8 エキスパート活性化)のままエキスパート数を 8→64 まで変化させ、スパーシティ 48(384 エキスパート)がスパーシティ 8 比で 1.69× の FLOPS 節約を達成することを定量化した。DeepSeek-V3(256 エキスパート)からスパーシティを 50% 増(384 エキスパート)に引き上げつつアテンションヘッドは半減(128→64)し、推論 FLOPS 83% 削減と性能向上を両立する。[[Efficient Training of Large Language Models on Distributed Infrastructures]] が MoE のスケーリングを「パラメータ ↑ / 計算コスト ≈」として概説するのに対し、Kimi K2 は**スパーシティ自体をスケーリング変数とする定量則**を Muon 下で初めて体系的に示した。(Source: [[@2025__arXiv__Kimi K2 - Open Agentic Intelligence]], [[Efficient Training of Large Language Models on Distributed Infrastructures]]) - **MoE の All-to-All ボトルネックに対しアーキテクチャ側とスケジューリング側の 2 つの回答が立つ**: [[@2026__NSDI__FAST - An Efficient Scheduler for All-to-All GPU Communication]] は MoE AllToAllv の動的歪みを**スケジューリング層**（Birkhoff 分解）で解き RCCL 比最大 4.48× のスループット向上を達成したのに対し、[[@2025__arXiv__Nemotron 3 - Efficient and Open Intelligence]] の [[LatentMoE]] は**アーキテクチャ層**でルーティング対象を潜在次元 ℓ（d/ℓ ≈ 4）に射影することでエキスパートごとの通信量を d/ℓ 倍削減し、浮いた帯域予算をエキスパート数の 4 倍増加（128→512）と活性化エキスパート数の 4 倍増加（6→22）に再投資して精度を向上させた。FAST が「既存アーキテクチャの通信を最適化する」のに対し、LatentMoE は「通信量そのものをアーキテクチャ変更で構造的に減らす」という相補的方向を取る。(Source: [[@2026__NSDI__FAST - An Efficient Scheduler for All-to-All GPU Communication]], [[@2025__arXiv__Nemotron 3 - Efficient and Open Intelligence]]) - **細粒度 MoE + シグモイドゲーティングが補助損失依存を構造的に排除しつつフロンティア性能を達成**: [[MiniMax-M2]] は 256 エキスパート・トークンあたり 8 活性化の細粒度 MoE にシグモイドゲーティング(ソフトマックスのゼロサム制約を排除)と学習可能なエキスパートバイアスを組み合わせ、補助損失への依存を大幅に削減した。サーベイ([[Efficient Large Language Models - A Survey]])が Expert Choice や StableMoE のルーティング安定化をアルゴリズム側の課題として整理するのに対し、M2 はゲーティング関数の構造変更(softmax → sigmoid + bias)で load balance を暗黙的に達成するという第 3 の方向を提示する。229.9B/9.8B という高スパーシティ(約 23×)での本番検証は、Kimi K2 のスパーシティスケーリング則と合わせ「固定 FLOPS でスパーシティを上げるだけで性能向上」の設計原則をさらに補強する。(Source: [[@2026__arXiv__The MiniMax-M2 Series - Mini Activations Unleashing Max Real-World Intelligence]], [[Efficient Large Language Models - A Survey]]) - **MoE の RL 訓練安定化には推論/訓練間のルーティング一致が必須であることが産業規模で実証された**: [[@2025__arXiv__DeepSeek-V3.2 - Pushing the Frontier of Open Large Language Models]] は **Keep Routing**（サンプリング時のエキスパートルーティングパスを訓練時に強制し同一のアクティブパラメータ部分空間を最適化する）を MoE モデルの RL 訓練安定化に「不可欠」と位置づけ、DeepSeek-V3-0324 以降のパイプラインに標準採用している。推論フレームワークと訓練フレームワークの実装差異がルーティングの不一致を引き起こし、アクティブパラメータ部分空間の急変で最適化が不安定化するという障害は、サーベイ([[Efficient Training of Large Language Models on Distributed Infrastructures]])が MoE の課題として挙げる「通信最適化」「負荷分散」とは別の第 3 の運用課題——推論/訓練間のルーティング一致——を指す。FAST([[@2026__NSDI__FAST - An Efficient Scheduler for All-to-All GPU Communication]])がルーティングパターンの動的性を通信スケジューリングの入力として扱うのに対し、Keep Routing は同じ動的性を RL の勾配更新の正しさの前提条件として扱う。(Source: [[@2025__arXiv__DeepSeek-V3.2 - Pushing the Frontier of Open Large Language Models]], [[Efficient Training of Large Language Models on Distributed Infrastructures]]) - **DeepSeek-V3 の補助損失なし負荷分散は MoE の load balance 手法系譜に「ゲーティングバイアスの動的調整」という第 4 の方向を加える**: サーベイが auxiliary loss（Switch Transformer 等）とシステム層の配置最適化（FasterMoE/SmartMoE）を整理し、[[MiniMax-M2]] がシグモイドゲーティング + 学習可能バイアスで補助損失依存を構造的に排除したのに対し、[[@2024__arXiv__DeepSeek-V3 Technical Report]] はバイアス項をルーティング決定のみに使い（ゲーティング値は元のアフィニティスコアから算出）、バッチ単位の負荷監視で動的に調整する。M2 のバイアスが学習可能パラメータとして勾配で更新されるのに対し、DeepSeek-V3 のバイアスはヒューリスティックな符号反転で更新される。アブレーション（検証損失: シーケンス単位補助損失 2.258、補助損失なし 2.253、バッチ単位補助損失 2.253）は、負荷分散の粒度（バッチ対シーケンス）が性能を左右することを示す。(Source: [[@2024__arXiv__DeepSeek-V3 Technical Report]], [[@2026__arXiv__The MiniMax-M2 Series - Mini Activations Unleashing Max Real-World Intelligence]]) - **DeepSeek-V3 の DualPipe は MoE の All-to-All 通信を「パイプライン内完全隠蔽」で解く第 3 のアプローチ**: FAST がスケジューリング層で、LatentMoE がアーキテクチャ層で MoE 通信を最適化するのに対し、[[@2024__arXiv__DeepSeek-V3 Technical Report]] の [[DualPipe]] はフォワードとバックワードの計算チャンクを再配置し、All-to-All と PP 通信を計算中に完全に隠蔽する。計算対通信比率が 1:1 でも通信オーバーヘッドがほぼゼロになり、モデルスケーリング時に計算対通信比を一定に保てば細粒度エキスパートのクロスノード利用を維持できる。3 者は相補的な層で動作する。(Source: [[@2024__arXiv__DeepSeek-V3 Technical Report]], [[@2026__NSDI__FAST - An Efficient Scheduler for All-to-All GPU Communication]], [[@2025__arXiv__Nemotron 3 - Efficient and Open Intelligence]]) - **MoE の追加同期点が、グレーノード/fail-slow に対する障害影響を増幅する**: MoE の expert parallelism は通信・load balance の効率という観点で語られがちだが、[[Guard]] は運用信頼性の観点から別の脆弱性を指摘する。MoE は密モデルにない 2 つの同期点(All-to-All によるトークンディスパッチと結果結合)を持ち、1 ノードのネットワークアダプタ障害で帯域が実質半減すると、その影響がエキスパート並列グループの 32 層分にわたって累積し、ジョブ全体を律速する。さらに MoE は密モデルより多くの CPU コアを要し、CPU 周波数・コア割り当ての不整合(ステップ時間に最大 20% 差)というグレーノード根因の影響も受けやすい。すなわち MoE の疎な活性化は計算効率を稼ぐ一方で、フェイルスローなノードに対する影響増幅源として作用する。(Source: [[@2026__MLSys2026__Guard - Scalable Straggler Detection and Node Health Management for Large-Scale Training]]) - **MoE の All-to-All 通信が訓練時間の 30〜56% を占め、スキューが最大 12×**: [[@2026__NSDI__FAST - An Efficient Scheduler for All-to-All GPU Communication]] は MoE AllToAllv の動的歪みを実測で定量化し、Birkhoff 分解ベースのオンラインスケジューリングで RCCL 比最大 4.48× のエンドツーエンド訓練スループット改善を達成する。従来「スケジューリング不可能」とされていた MoE の動的 All-to-All が、問題の単純化(スケール外に集中しスケール内で吸収)で現実的に解けることを示した。(Source: [[@2026__NSDI__FAST - An Efficient Scheduler for All-to-All GPU Communication]]) - **MoE の通信ボトルネックに対する第 4 の回答「カーネル融合によるウェーブベース完全隠蔽」が 1.6T 規模で実証された**: FAST がスケジューリング層、LatentMoE がアーキテクチャ層、DualPipe がパイプライン層で All-to-All ボトルネックに対処するのに対し、[[@2025__DeepSeek__DeepSeek-V4 - Towards Highly Efficient Million-Token Context Intelligence]] の [[MegaMoE]] は Dispatch / Linear-1 / Activation / Linear-2 / Combine を**単一融合カーネル**に統合し、エキスパートをウェーブに分割して計算と通信を完全にオーバーラップさせる。DeepSeek-V4-Pro（384 エキスパート/6 活性化）で計算通信比 6,144 FLOPS/Byte を達成し、通信が計算の律速にならないことを 1.6T パラメータ規模で示した。非融合ベースライン比 1.50〜1.73 倍（一般推論）、最大 1.96 倍（RL ロールアウト）の高速化は、Kimi K2 のインターリーブド 1F1B + EP16 とも DualPipe とも異なる「カーネル内パイプライン」による通信隠蔽。(Source: [[@2025__DeepSeek__DeepSeek-V4 - Towards Highly Efficient Million-Token Context Intelligence]], [[@2026__NSDI__FAST - An Efficient Scheduler for All-to-All GPU Communication]], [[@2025__arXiv__Nemotron 3 - Efficient and Open Intelligence]]) - **MoE のゲーティング関数設計はソフトマックス→シグモイド→√Softplus と第 3 世代に到達し、訓練安定性への影響が複合化している**: [[@2025__DeepSeek__DeepSeek-V4 - Towards Highly Efficient Million-Token Context Intelligence]] は DeepSeek-V3 のシグモイドから $\sqrt{\text{Softplus}(\cdot)}$ に変更した。同論文はロススパイクの根因を「MoE 層の異常値 + ルーティング機構による増幅」と特定し、Anticipatory Routing（ルーティングインデックスの先取り計算、壁時間オーバーヘッド約 20%）と SwiGLU Clamping で安定化した。Kimi K2 の [[MuonClip]] がアテンション層の安定化であるのに対し、Anticipatory Routing は MoE ルーティング層の安定化であり、1 兆パラメータ級 MoE の安定訓練にはアテンションと MoE の両方に安定化機構が必要であることを示す。(Source: [[@2025__DeepSeek__DeepSeek-V4 - Towards Highly Efficient Million-Token Context Intelligence]], [[@2025__arXiv__Kimi K2 - Open Agentic Intelligence]], [[@2026__arXiv__The MiniMax-M2 Series - Mini Activations Unleashing Max Real-World Intelligence]]) - **MoE の適用領域が LLM・時系列に加えビジョン言語モデル(VLM)にも拡大し、ルーティング関数の選択が世代ごとに変化している**: [[@2024__arXiv__DeepSeek-VL2 - Mixture-of-Experts Vision-Language Models for Advanced Multimodal Understanding]] は LLaVA スタイルの VLM に DeepSeekMoE を統合し、活性化パラメータ 4.5B(総 27B)で密モデル 8B 級(InternVL2-8B・Qwen2-VL-7B)に匹敵する性能を達成した。注目すべきは、3 バリアント間でルーティング関数が異なる点である: Tiny(3B)と Small(16B)は softmax ルーティング + 補助損失(weight 0.001)を使用するのに対し、最大バリアント(27B)はシグモイドルーティング + エキスパート補正バイアスに切り替え補助損失への依存を低減する。これは [[MiniMax-M2]] が「sigmoid + bias で load balance を暗黙的に達成」する設計と共通するが、VL2 ではモデル規模に応じて softmax/sigmoid を使い分ける過渡的設計が見える。LLM 訓練サーベイ([[Efficient Training of Large Language Models on Distributed Infrastructures]])が MoE を言語モデル訓練の文脈で、TSFM サーベイが時系列で扱うのに対し、VL2 は「視覚トークンとテキストトークンが混在する入力で MoE ルーティングがどう振る舞うか」という新しい問いを提起する。(Source: [[@2024__arXiv__DeepSeek-VL2 - Mixture-of-Experts Vision-Language Models for Advanced Multimodal Understanding]], [[@2026__arXiv__The MiniMax-M2 Series - Mini Activations Unleashing Max Real-World Intelligence]], [[Efficient Training of Large Language Models on Distributed Infrastructures]]) - **共有エキスパート(shared expert)の採否はモデルごとに分かれ設計上の未解決問題**: DeepSeek V3・GLM-4.5/5・Grok 2.5・Kimi K2・Nemotron 3・Mistral 3・Arcee AI Trinity Large が採用。Qwen3 が「有意な改善が見られなかった」として廃止したが、Qwen3-Next で再導入。[[The-Big-LLM-Architecture-Comparison|The Big LLM Architecture Comparison]] の分析では採否がエキスパート総数の変化と同時に起きているため純粋な寄与の分離が困難。共有エキスパートが「汎用パターンを専担し他エキスパートが専門化できる」という DeepSpeedMoE からの動機付けは理論的に説得力があるが、Qwen3 の廃止経験は設定依存性が大きいことを示唆する。(Source: [[The-Big-LLM-Architecture-Comparison|The Big LLM Architecture Comparison]]) - **細粒度(多数小型)vs 粗粒度(少数大型)エキスパートの設計分岐**: 2025 年の主要モデルは細粒度(DeepSeek V3: 256 エキスパート、Qwen3: 128 エキスパート)と粗粒度(GPT-OSS: 32 エキスパート、Grok 2.5: 8 エキスパート)の 2 派に分かれる。DeepSeekMoE 論文は「固定パラメータで細粒度化するほど性能向上」を示したが、GPT-OSS と Grok 2.5 はあえて粗粒化を選んだ。推論スループット(並列化効率)と知識の専門分化の間のトレードオフが背景にある。Mistral 3 Large は DeepSeek V3 アーキテクチャを採用しつつエキスパート数を半減・サイズを 2 倍に粗粒化したことで NVIDIA Blackwell での推論最適化を実現した。(Source: [[The-Big-LLM-Architecture-Comparison|The Big LLM Architecture Comparison]]) - **SWA + MoE の組み合わせが普及してきた**: [[スライディングウィンドウアテンション]] と MoE の組み合わせは以前は少数だったが、Xiaomi MiMo-V2-Flash(SWA 5:1 + MoE 309B)・Arcee AI Trinity Large(SWA 3:1 + MoE 400B)・Gemma 4 MoE(26B-A4B)が採用を広げた。KV キャッシュ削減(SWA)と計算量削減(MoE)の組み合わせは相補的だが、推論カーネルの最適化の難しさは MoE と SWA それぞれの最適化の乗算的な複雑さをもたらす可能性がある。(Source: [[The-Big-LLM-Architecture-Comparison|The Big LLM Architecture Comparison]]) - **推論では MoE は同パラメータ数の密モデルより高スループットを示すが改善は 1 tok/s 未満でモデル依存が大きい**: [[@2026__IPDPS__Beyond Throughput - Performance and Energy Insights of LLM Inference Across AI Accelerators]] の ALCF 実測では、Llama 3.1 70B (dense) と Llama 3.1 70B (相当の MoE) を比較した場合、MoE が微小なスループット優位を示すもののその差は実環境での有効性の差とは言えない水準にとどまる。MoE の計算量削減効果は訓練時に顕著だが、推論時は KV キャッシュ・メモリ帯域・バッチサイズが支配的でスパース性の恩恵が出づらい。([[@2026__IPDPS__Beyond Throughput - Performance and Energy Insights of LLM Inference Across AI Accelerators]]) - **MoE 推論ではエキスパート並列 (EP) よりテンソル並列 (TP) が一般に高スループットを達成するが、DeepSeek R1 (256 エキスパート) は例外**: 同論文では Llama 3.1 70B MoE・Mixtral 等のほとんどの MoE モデルで TP が EP よりスループット・エネルギー効率ともに優勢。しかし DeepSeek R1 (671B、256 エキスパート) は EP が TP を上回るケースがあり、超多数エキスパートでは EP によるエキスパート配置効率が TP の通信削減効果を超える可能性がある。([[@2026__IPDPS__Beyond Throughput - Performance and Energy Insights of LLM Inference Across AI Accelerators]]) - **本番規模の EP 展開では、層の種類ごとに異なる並列化方式を割り当てる非一様設計が、通信ボトルネックとハードウェア制約の両方に応答して現れる**: [[@2026__IPDPS__Beyond Throughput - Performance and Energy Insights of LLM Inference Across AI Accelerators]] は EP vs TP を単一の二択として比較するが、[[SGLang]] の 96 H100 GPU 展開([[@2025__LMSYS Blog__Deploying DeepSeek with PD Disaggregation and Large-Scale Expert Parallelism on 96 H100 GPUs]])は同一モデル内でも層ごとに異なる並列化を割り当てる——Attention 層と密な FFN 層は DP(密 FFN の中間次元 18,432 が TP32 で 576 単位に細分化され 128B アラインメントへ非対応なため)、疎な FFN(MoE)層のみ Expert Parallelism を採用する。これは TP/EP の二択という粒度ではなく、モデルアーキテクチャの次元数とハードウェアのアラインメント制約が並列化方式の選択を層単位で規定することを示す。さらに [[EPLB]](DeepSeek 開発の負荷均衡器)は冗長エキスパートの配置によりスループットを Prefill 1.49 倍・Decode 2.54 倍向上させ、[[負荷分散]] の「システム配置最適化」系譜(FasterMoE・SmartMoE 等)に、本番運用規模での定量実証を加える。(Source: [[@2025__LMSYS Blog__Deploying DeepSeek with PD Disaggregation and Large-Scale Expert Parallelism on 96 H100 GPUs]], [[@2026__IPDPS__Beyond Throughput - Performance and Energy Insights of LLM Inference Across AI Accelerators]]) - **推論時の MoE 通信最適化は、訓練時の All-to-All オーバーラップ設計を継承しつつ、Prefill/Decode で異なる通信プリミティブを要求する**: FAST・LatentMoE・DualPipe・MegaMoE は訓練時の All-to-All 隠蔽を扱うが、[[DeepEP]] は推論の Prefill(長入力、CUDA Graph 非対応の Normal Dispatch)と Decode(低遅延、CUDA Graph 対応の Low-Latency Dispatch)で異なるディスパッチモードを提供し、[[Prefill-Decode分離]] と組み合わせて両モードを同時使用する。訓練時の通信最適化が「1 つの計算パターンにどう通信を隠すか」を扱うのに対し、推論時は「フェーズごとに異なる通信プリミティブをどう切り替えるか」という別の設計問題になる。(Source: [[@2025__LMSYS Blog__Deploying DeepSeek with PD Disaggregation and Large-Scale Expert Parallelism on 96 H100 GPUs]]) - **エキスパート総数・活性化数の拡大が Kimi 系列で継続し、スパーシティ 56 まで到達——ただし極端なスパース性は新たな不安定化モードを誘発する**: [[Kimi K2]](384 エキスパート/活性化 8、スパーシティ 48)から [[Kimi K3]] は 896 エキスパート/活性化 16([[Stable LatentMoE]]、スパーシティ 56)へ拡大した。技術レポート公開(2026-07-27)により、この拡大が単純な外挿ではなく新たな安定化機構を要したことが判明した: 896 という規模は (1) routed パスのほぼ4連続行列積による活性化爆発、(2) 既存の補助損失なしバイアス更新(固定ステップ)が破綻する規模の負荷分散、という2つの失敗モードを増幅させ、RMSNorm 挿入・SiTU-GLU(有界活性化関数)・Quantile Balancing(下記)という3つの追加安定化要素が必要になった。「スパーシティを上げるほど性能向上」という Kimi K2 の設計原則(§ [[@2025__arXiv__Kimi K2 - Open Agentic Intelligence]])は継続する一方、スパーシティの上限は安定化コストとのトレードオフで規定されることを示唆する。(Source: [[@2025__arXiv__Kimi K2 - Open Agentic Intelligence]], [[@2026__Moonshot AI__Kimi K3 - Open Frontier Intelligence]]) - **Quantile Balancing は負荷分散手法系譜に「ルータスコアのバッチ分位数マッチング」という第5の方向を確立した**: DeepSeek-V3 の固定ステップ符号更新($b^{(t+1)}_j = b^{(t)}_j + \gamma\,\mathrm{sign}(\bar\ell - \ell_j)$)は、896 エキスパートのような大規模プールでは γ の緩やかな適応と負荷振動のトレードオフが悪化する。Kimi K3 の Quantile Balancing は各エキスパートのバイアスを「目標負荷 q=mk/n に対応するルータスコアの分位数」から直接導出する(Top-(k+1) ルーティングのカットオフからマージンを計算し、次ステップにのみ適用して自己参照を回避)。真の分位数計算は全バッチ規模で非現実的なため、実運用ではエキスパートごとのマージンをヒストグラム化し all-reduce で集約する近似推定を用いる。これは DeepSeek-V3 のヒューリスティックな符号反転、MiniMax-M2 のシグモイド+学習可能バイアスとも異なる、分位数統計に基づく第5の負荷分散設計である。(Source: [[@2026__Moonshot AI__Kimi K3 - Open Frontier Intelligence]], [[@2024__arXiv__DeepSeek-V3 Technical Report]], [[@2026__arXiv__The MiniMax-M2 Series - Mini Activations Unleashing Max Real-World Intelligence]]) - **MoonEP は EP の負荷不均衡問題に「完全均衡+有界冗長エキスパート」という構造的解を与え、DeepEP 比で通信バッファを R 分の1に縮小する**: FAST がスケジューリング層で AllToAllv の動的歪みを解くのに対し、[[MoonEP]](Kimi K3 の事前訓練インフラ)は全ランクが正確に S×K トークンを処理するよう動的冗長エキスパートをオンライン計画・移行し、そもそも歪みを発生させない設計を取る。冗長エキスパートの上限が E/R(E=エキスパート数、R=EP サイズ)でタイトであることを証明し、ECHO・UltraEP のような固定冗長数・per-rank キャップに伴う「実行可能プランが存在せず訓練が停止する」リスクを排除する。完全均衡ゆえに DeepEP が同じコピーフリー経路に S×K×R サイズのバッファを要するのに対し MoonEP は固定 S×K で済み、全層の計算形状が静的に既知になることで従来 MoE 実装のホスト同期も不要になる。FAST が「歪みが生じた後にスケジューリングで吸収する」のに対し、MoonEP は「歪みを構造的に発生させない」という異なるレイヤーの回答であり、両者は相補的である可能性がある。(Source: [[@2026__Moonshot AI__Kimi K3 - Open Frontier Intelligence]], [[@2026__NSDI__FAST - An Efficient Scheduler for All-to-All GPU Communication]]) - **ソフトウェア側が繰り返し指摘してきた「MoE の重み・トークン移動オーバーヘッド」に対し、Rubin はハードウェア co-design で応答する**: FAST(スケジューリング層)・LatentMoE(アーキテクチャ層)・DualPipe/MegaMoE(パイプライン/カーネル融合層)はいずれもソフトウェア側から MoE の All-to-All 通信・expert 重み移動のボトルネックを解いてきたが、[[NVIDIA Rubin GPU]] は同じ「expert 数が増えるほど重みの位置特定・移動が支配的になる」という課題に、TMA(Tensor Memory Accelerator)のインライン・ディスクリプタ更新というハードウェア機構で応答する。Blackwell が expert ごとに個別ディスクリプタを持つのに対し、Rubin は全 expert で共有ディスクリプタを保持しレイアウトの共通性を利用してメタデータ管理オーバーヘッドを削減する。これは、MoE のスケーリング(エキスパート数 8→64→384→896 という Kimi K2/K3 の系譜)がソフトウェア層の通信最適化だけでなく、GPU アーキテクチャ側の記述子処理そのものの再設計を要求する段階に入ったことを示す。(Source: [[@2026__NVIDIA Developer Blog__Inside NVIDIA Rubin GPU Architecture Powering the Era of Agentic AI]], [[@2026__NSDI__FAST - An Efficient Scheduler for All-to-All GPU Communication]]) - **「LatentMoE」の名称が NVIDIA と Moonshot AI で独立命名ではなく、同一設計の継承であることが確定した**: Kimi K3 技術レポートは Elango et al. の LatentMoE 論文(arXiv:2601.18089、[[@2025__arXiv__Nemotron 3 - Efficient and Open Intelligence]] が [[Nemotron 3]] で採用した設計と同一の原著論文)を参照[32]として明示的に引用し、「LatentMoE はモデル全幅と routed-expert 幅を分離することでこの拡張を可能にする」と述べる。すなわち [[Stable LatentMoE]] は独立設計ではなく **LatentMoE(Elango et al.)を継承した上での安定化拡張**であり、DeepSeekMoE の shared/routed expert 構成に接続した点も共通する。潜在次元比は Kimi K3 が ℓ=3,584/d=7,168=0.5(d/ℓ=2)、Nemotron 3 の LatentMoE が d/ℓ≈4 と報告値が異なり、同一設計の異なるハイパーパラメータ選択として位置づけられる。(Source: [[@2026__Moonshot AI__Kimi K3 - Open Frontier Intelligence]], [[@2025__arXiv__Nemotron 3 - Efficient and Open Intelligence]]) - **本番規模の実測が「EP は TP よりスケールアウトで有利」を iso-parameter 比較とスケールアウト/スケールアップ横断で定量化した**: [[@2026__MLSys2026__Optimizing Deployment Configurations for LLM Inference]](Meta)は405B Dense と iso-parameter MoE(125Bベース×4エキスパート、Top-2)を同一 TP8 構成で比較し、Decode で TP8→TP16 に上げると Dense は QPS 210→84(-60%、AllReduce コスト増による)と悪化する一方、MoE は EP を併用した TP8DP2-TP8EP2 で QPS 344→400(+16%)と向上することを示した。産業規模の Llama 4 Maverick(128エキスパート)でも同傾向が確認され、TP8DP2-TP8EP2 は608(-2%)、TP4DP4-TP4EP4 は899(TP8比+45%)を達成した。[[@2026__IPDPS__Beyond Throughput - Performance and Energy Insights of LLM Inference Across AI Accelerators]] が「ほとんどの MoE モデルで TP が EP よりスループット優勢、DeepSeek R1(256エキスパート)のみ例外」と報告するのに対し、Meta の実測は同一モデルサイズでの TP16 vs EP 併用比較という異なる切り口で「TP のスケールアウトは AllReduce に律速され、EP併用が優位に転じる」ことを示しており、両者は「TP対EPどちらが速いか」ではなく「どの並列化次数まではTPが有利で、どこからEPが必要になるか」という遷移点の存在を示唆する点で補完的である。(Source: [[@2026__MLSys2026__Optimizing Deployment Configurations for LLM Inference]], [[@2026__IPDPS__Beyond Throughput - Performance and Energy Insights of LLM Inference Across AI Accelerators]]) - **密モデルはスケールアップ基盤が必須になるが MoE はスケールアウトでも良好にスケールすることが、1.8T 規模の仮想モデルで実証された**: 同論文はハードウェア世代を横断し、Dense モデルがスケールアウト(host間帯域50GB/s)で TP をホストをまたいで使うと AllReduce コストにより QPS がほぼゼロ(QPS 3)まで崩壊する一方、スケールアップ(pod内帯域900GB/s)では限定的な劣化(QPS 14)にとどまることを示した。MoE はスケールアウトでも EP により QPS 488(スケールアップは655)を達成し、スケールアップに対しスケールアウトが約2/3のQPS比を維持する。この結果は「EP が MoE のスケールアウト活用を可能にする」という定性的知見に、Dense との対比という具体的な定量的裏付けを与える。(Source: [[@2026__MLSys2026__Optimizing Deployment Configurations for LLM Inference]]) - **エキスパート負荷の予測モデルはPrefill/Decodeで異なる律速要因を反映し、予測手法間で最大3.5倍のコスト差が生じる**: 同論文は、Prefillでは多数のトークンがほぼ全エキスパートを活性化するため load-balanced 仮定がコストの下限を与えるのに対し、Decodeはトークン数が少なくメモリ帯域律速となるため活性化エキスパート数(≒重み読み出し量)の予測が支配的になると整理する。活性化エキスパート数の予測に load balanced・uniform random・log-linear の3モデルを比較し、本番トラフィックに最も一致するのは log-linear(較正されたモデル)で、予測モデル間の選択がコスト見積もりに最大3.5倍の差をもたらすと定量化した。これは負荷分散研究の系譜(FasterMoE のシャドーイング、DeepSeek-V3のバイアス動的調整等)が「訓練時の負荷分散をどう実現するか」を扱うのに対し、「推論時の負荷分布をどう予測してキャパシティプランニングに使うか」という、性能シミュレーション特有の観点を追加する。(Source: [[@2026__MLSys2026__Optimizing Deployment Configurations for LLM Inference]]) - **時系列基盤モデル Moirai-MoE が「事前学習済み表現のクラスタ重心でゲーティングする」という、LLM MoE のゲーティング系譜に無い設計を提示した**: 本ページが整理してきた LLM MoE のゲーティング系譜(Shazeer+ のランダム初期化線形射影 → DeepSeek-V3 のバイアス動的調整 → MiniMax-M2 のシグモイド+学習可能バイアス → Kimi K3 の Quantile Balancing)はいずれも**ゲート自体を勾配またはヒューリスティックで学習・調整する**という共通点を持つ。[[@2024__arXiv__Moirai-MoE - Empowering Time Series Foundation Models with Sparse Mixture of Experts]] の Token Clusters ゲーティングは、事前学習済みモデル(Moirai)の自己注意出力表現に k-means クラスタリングを適用して得たクラスタ重心とのユークリッド距離をアフィニティスコアとして使う——**ゲート自体を学習せず、既存の事前学習済み表現を流用する**という第 6 の方向であり、[[@2025__arXiv__Foundation Models for Time Series - A Survey]] が Time-MOE の文脈で言及した「MoE の時系列適用」に、ゲーティング設計という新しい軸を加える。アブレーション(Figure 4 右・Figure 9)では Token Clusters が全エキスパート数構成で線形射影ゲーティング(ロードバランスあり/なし共に)を一貫して上回りつつ、選択の多様性はむしろ最も低い——的を絞った専門化が多様性より性能に効くという、負荷分散研究の「多様性 = 良い分散」という暗黙の前提に反する観察でもある。(Source: [[@2024__arXiv__Moirai-MoE - Empowering Time Series Foundation Models with Sparse Mixture of Experts]], [[@2025__arXiv__Foundation Models for Time Series - A Survey]]) - **時系列 MoE に「スケール志向」と「specialization 志向」という 2 系統が並立し、時系列基盤モデルへの MoE 適用は Time-MOE 単独の事例ではなくなった**: 既存の横断的知見は MoE の時系列適用例として Time-MOE(FFN を MoE 層に置換した billion-scale decoder-only モデル)のみを挙げていたが、Moirai-MoE は同じ「FFN→MoE 層」というアーキテクチャ変更を、Time-MoE とは異なる動機(頻度レベル specialization の限界の克服)から独立に導入する。Moirai-MoES は同等の活性化パラメータを持つ密モデル Moirai を最大 17% 上回り、Moirai の後継として明確な性能向上を示した——LLM MoE がスケーリング(GShard・Switch Transformer)から出発したのに対し、時系列 MoE は「スケーリング」(Time-MoE)と「specialization の粒度」(Moirai-MoE)という 2 つの異なる出発点から収斂している。(Source: [[@2024__arXiv__Moirai-MoE - Empowering Time Series Foundation Models with Sparse Mixture of Experts]], [[@2025__arXiv__Foundation Models for Time Series - A Survey]]) - **MoE の All-to-All ボトルネックに対し、スケジューリング(FAST)・アーキテクチャ(LatentMoE)・パイプライン(DualPipe)に続く第 5 の回答として「データセンターネットワークトポロジそのものを均等化する」層が加わった**: [[@2026__ICS__Closing the Efficiency Gap - AI Datacenter Co-design Roadmap for Scalable Training of LLMs]] の [[Calculon-MoE]] は、EP 通信を運ぶスケールアウト(SO)帯域幅とスケールアップ(SU)帯域幅を均等化する FullFlat 光配線(CPO)トポロジを提案し、上位 5,000 パラメータ構成間の性能ギャップを TwoTier ネットワークの最大 70% から 13% 以下へ縮小することを示した。FAST・LatentMoE・DualPipe・MegaMoE がいずれもソフトウェア/アーキテクチャ側から通信を「隠す・減らす・スケジューリングする」のに対し、本研究は物理ネットワーク層で SU/SO の帯域差そのものを解消し、EP 通信がどのドメインを通っても性能ペナルティを生まないようにする点で異なるレイヤーの回答である。これにより「ソフトウェア最適化への感度が下がる」という副次効果(=チューニング労力の削減)も定量化された。(Source: [[@2026__ICS__Closing the Efficiency Gap - AI Datacenter Co-design Roadmap for Scalable Training of LLMs]], [[@2026__NSDI__FAST - An Efficient Scheduler for All-to-All GPU Communication]], [[@2024__arXiv__DeepSeek-V3 Technical Report]]) - **EP=#Experts・ES=TP という「1 GPU に 1 エキスパート」のデフォルト運用は、MoE の並列化次元系譜において最適でないことが定量実証された**: [[@2026__ICS__Closing the Efficiency Gap - AI Datacenter Co-design Roadmap for Scalable Training of LLMs]] は、NeMo・DeepSpeed が標準採用する EP=#Experts かつ ES=TP という制約を GPT4-1.8T で緩め、EP を #Experts より小さくする、または ES を TP から独立させる構成の方がシステム効率(MFU)を最大 7.7 ポイント改善する(75.96%→83.66%)ことを示した。これは MoonEP・FAST のようなランタイム/スケジューリング層の最適化とは別に、**並列化次元の割り当てそのもの**という設計選択がまだ最適化の余地を残していることを示す第 6 の観点である。(Source: [[@2026__ICS__Closing the Efficiency Gap - AI Datacenter Co-design Roadmap for Scalable Training of LLMs]]) - **MoE の通信計算融合は「単一モデルのカーネル最適化」から「汎用オープンソースメガカーネル」へ抽象度が一段上がった**: [[MegaMoE]](DeepSeek-V4 内製、Dispatch/Linear-1/Activation/Linear-2/Combine を単一融合カーネルに統合)がモデル専用の垂直統合最適化であったのに対し、[[Mixture-of-Kittens]]([[Cursor Research]]、[[NVIDIA GB300 NVL72]] 向け)は Kimi・GLM・Qwen・DeepSeek 複数系列のモデル形状に対応する OSS メガカーネルとして公開された。両者とも「MoE 層の通信と計算を単一カーネルに融合する」という同じ設計思想([[メガカーネル]])を採るが、通信方向の選択(MoK は pull-based dispatch を明示的に採用し push-based 比で最大29%高い NVLink 帯域利用率を報告)というより下位の設計判断まで具体化した点は MoK が初めて公開した知見である。MegaMoE がウェーブ分割による計算通信オーバーラップを扱うのに対し、MoK はさらに CPU-GPU 同期排除(リングトークンバッファ)という GB300 の統合 Grace CPU 固有の制約への対処を加えている。(Source: [[@2025__DeepSeek__DeepSeek-V4 - Towards Highly Efficient Million-Token Context Intelligence]], [[@2026__Cursor__Mixture-of-Kittens - our open-source MoE megakernel for NVL72s]]) - **実務教科書は capacity factor・エキスパート併置・butterflyスケジュールを、研究システム(FAST・MoonEP・DeepEP)が解く All-to-All 歪みの「基礎的な緩和策の集合」として先んじて提示する**: 『AI Systems Performance Engineering』第15章は、capacity factor(実務では1.2程度)による overflow 処理、頻繁に対になるエキスパートの併置(collocation)、butterfly/shifted all-to-allスケジュール、FP8/NVFP4への通信圧縮という4つの緩和策を推論時の一般的な設計指針として整理する。これは[[@2026__NSDI__FAST - An Efficient Scheduler for All-to-All GPU Communication]]がBirkhoff分解でスケジューリング層から、[[MoonEP]]が完全均衡設計で構造的にAll-to-Allの歪みを解くのと同じ問題(トークン負荷の不均衡・通信オーバーヘッド)に対する、教科書レベルでの汎用的な出発点を示す。研究システムがこれらの基礎技法をさらに定式化・自動化・保証付き化した関係にあると位置づけられる。(Source: [[@2025__OReilly__AI Systems Performance Engineering - Chapter 15 Multinode Inference, Parallelism, Decoding, and Routing Optimizations]], [[@2026__NSDI__FAST - An Efficient Scheduler for All-to-All GPU Communication]], [[@2026__Moonshot AI__Kimi K3 - Open Frontier Intelligence]]) - **エキスパート複製(hot expert replication)は、実務教科書とEPLBの本番実測の双方で独立に到達した負荷分散パターンだが、複製の同期範囲に関する記述粒度が異なる**: 第15章はホットエキスパートを別GPUに複製しゲーティングスコアに応じてクローンへトークンを振り分けるアプリケーション層最適化として説明し、複製は同一チェックポイントから読み込み独立更新しないことを強調する。これは[[EPLB]](DeepSeek開発の負荷均衡器、Prefill 1.49倍・Decode 2.54倍のスループット向上)が実装する冗長エキスパート配置と同じ思想だが、EPLBが具体的な配置アルゴリズムとスループット数値を示すのに対し、教科書は「なぜ複製が有効か」という設計原理(同一重みの維持・ゲーティングは複製を知らない)を一般化して説明する。(Source: [[@2025__OReilly__AI Systems Performance Engineering - Chapter 15 Multinode Inference, Parallelism, Decoding, and Routing Optimizations]], [[@2025__LMSYS Blog__Deploying DeepSeek with PD Disaggregation and Large-Scale Expert Parallelism on 96 H100 GPUs]]) - **本番 LLM 事前学習の全並列化スキーム横断で見ると、EP の AlltoAllv は「小メッセージ・小プロセスグループに構造的に閉じた」通信として、HSDP/PP/CP/TP の大メッセージ・大グループ通信から明確に分離する**: [[@2026__SIGCOMM__Connecting 100K+ GPUs - Building the Communication Stack for Large-Scale LLM Training]](Meta)は本番 LLM 事前学習ジョブの集合通信を並列化スキーム別・メッセージサイズ別・プロセスグループサイズ別に集計し、EP はほぼ全てが AlltoAllv かつメッセージサイズ ≤10^4 要素に集中し、プロセスグループサイズも 8 GPU 未満に構造的に閉じることを定量化した(一方 HSDP/TP の AllReduce・AllGather は ≥10^7 要素の大メッセージ・数千 GPU 規模のグループに偏る)。これは FAST([[@2026__NSDI__FAST - An Efficient Scheduler for All-to-All GPU Communication]])が実測した「AllToAllv が訓練時間の 30–56% を占め転送量が最大 12× 歪む」という知見に、「EP の通信は規模の面でも他の並列化次元から質的に分離した現象である」という補完的な観測を加える——AllToAllv 最適化(FAST・MoonEP・LatentMoE)が対象とすべき通信は、そもそも大域スケールの問題ではなく局所的な小規模プロセスグループ内の現象である。(Source: [[@2026__SIGCOMM__Connecting 100K+ GPUs - Building the Communication Stack for Large-Scale LLM Training]], [[@2026__NSDI__FAST - An Efficient Scheduler for All-to-All GPU Communication]]) - [通信ボトルネック] MoEのエキスパート並列all-to-all通信(シーケンス並列all-gather、テンソル並列all-reduceと並ぶ)は、電気配線ベースのスケールアップpod境界を越える際に急増する通信ペナルティの主因となる。[[フォトニックインターコネクト]]は帯域(4倍)とradix(8倍、pod規模1152 GPUまで)を同時に拡張することでこれを緩和する(Source: [[@2026__HOTI__Scaling Inference Prefill with High-Radix Photonic Interconnects]])。 - DeepSeek-V4.1-Flash は auxiliary-loss-free load balancing(Wang et al., 2024a)を拡張し、画像トークンとテキストトークンで別々のエキスパート補正バイアスを維持するモダリティ別負荷分散を導入した。各トークンは自身のモダリティに対応する補正バイアスでエキスパート選択を行い、元のルーティングスコアは重み付けにそのまま使う設計である(Source: [[@2026__TechReport__DeepSeek-V4.1-Flash - Pushing the Limits of KV Cache Compression]])。 ## 未解決の問い - **1T級でのrouting collapseの発生条件**: 約30Bでは機能した学習型Routerが1Tで特定エキスパートへ崩壊し、load balancing lossの係数調整でも改善しなかった。モデル深度とエキスパート当たりの容量が閾値を決めるかは未解明である。(Source: [[@2024__Preferred Networks__1兆 (1T) パラメータ規模のLLMの事前学習検証]]) - **Hash Layersという非学習ルーティング**: 学習型Routerの崩壊を避けるためハッシュ関数で割り当てる方式へ移行し、記事の条件ではtrain loss約1.57を得た。Expert Choice Routingや補助損失方式との同一条件比較が必要である。(Source: [[@2024__Preferred Networks__1兆 (1T) パラメータ規模のLLMの事前学習検証]], [[Hash Layers]], [[Expert Choice Routing]]) - Mixture-of-Kittens の pull-based dispatch(受信側主導、総バイト数増でも帯域利用率が向上)という知見は、MegaMoE・DualPipe・FAST 等の既存 All-to-All 最適化のいずれとも直接比較されていない。プッシュ/プル方向の選択は他の MoE 通信最適化(スケジューリング層・アーキテクチャ層)と独立した軸として一般化できるか。 - 『AI Systems Performance Engineering』が紹介する capacity factor によるオーバーフロー処理(fallback expert への転送・2パス処理)は、MoonEP の「完全均衡+有界冗長エキスパート」設計と比べてどの程度のスループット差があるか。教科書レベルの汎用的な capacity factor 運用と、研究システムの構造的解法の定量比較は行われていない。 - Shazeer et al. 2017 は top-k で k=2–4 を実験したが、k=1(Switch Transformer)が後にデフォルトになった理由を「通信量削減」で説明できる一方、DeepSeek-V3 の top-8 は精度と通信のトレードオフでより多くの k が有利な場合を示す。k の最適値はエキスパート数・モデル規模・ハードウェアトポロジの何で決まるのか。 - 2017 年の補助損失(重要度損失 + 負荷損失)はノイズゲーティング(ノイズ付きソフトマックス)と組み合わせて負荷を分散した。現代のモデルがノイズゲーティングを廃止しシグモイドやバイアス調整に移行したのはなぜか。ノイズゲーティングの訓練安定性への影響は系統的に評価されていない。 - Shazeer et al. 2017 はエキスパートの「専門化」(特定ドメインのトークンを特定エキスパートが担う)を観察したが、この専門化パターンはモデル規模・エキスパート数・訓練データ分布によってどう変化するか。DeepSeek-V3 の 256 エキスパート・top-8 の場合、専門化は 2017 年の 2048 エキスパート・top-4 と性質が異なるか。 - DeepSeek-V4 の Anticipatory Routing はルーティングインデックスの非同期計算で安定化を達成するが、理論的メカニズムは未解明。ルーティングとバックボーンの同時更新がなぜ不安定を引き起こすのか、MoE 固有の勾配景観の構造的理解が必要。 - MegaMoE のウェーブベースカーネル融合は「通信が計算に隠蔽できる」前提で成立するが、将来のハードウェアで FP4×FP8 演算がさらに高速化すると計算時間が縮小し通信が再び露出する可能性がある。計算通信比のハードウェア依存性をどう吸収するか。 - Kimi K2 はスパーシティ 48(384 エキスパート)で DualPipe を不採用としインターリーブド 1F1B + EP16 で通信をオーバーラップしたが、さらなるスパーシティ増(64, 128 等)では EP サイズ拡大が不可避になり DualPipe 的設計が再浮上するか。スパーシティスケーリング則の上限はインフラ制約(EP 通信量)で規定されるのか。 - All-to-All 通信の最適化(Tutel/Lina/ScheMoe 等)と負荷分散(FlexMoE/Prophet 等)は独立に研究されているが、両者を同時最適化する設計は成立するか。 - FAST は各 alltoallv 呼び出しのトラフィック行列を既存の All-Gather(Megatron-LM の `num_global_tokens_per_expert`)から得るが、ゲーティング関数のルーティング偏りを事前に予測してスケジュールを先取りする設計は有効か。動的性とオンライン合成のトレードオフはどこにあるか。 - FAST の均等・1 対 1 転送は segment parallelism や Sequence Parallelism との組み合わせでどう変わるか。3D parallelism の全次元が絡む場合の AllToAllv スケジューリングの一般化は未検討。 - expert からデバイスへの割り当ては短期では大きく変化しない(FlexMoE の観察)。この性質はどの程度のモデル規模・データ分布まで成り立つか。 - MoE の疎な活性化は [[並列化戦略]] の他の次元(tensor/pipeline)とどう組み合わせるのが効率的か(DeepSpeed-TED の data+tensor+expert のハイブリッド等)。 - 時系列基盤モデルの MoE(Time-MOE)は、LLM 訓練で確立した expert parallelism の通信最適化(All-to-All)・負荷分散技術をそのまま流用できるか。それとも time-series の point-wise tokenization・multi-resolution 特有のルーティング課題があるか([[@2025__arXiv__Foundation Models for Time Series - A Survey]] は Time-MOE の訓練インフラ詳細に踏み込まない)。 - Moirai-MoE の Token Clusters ゲーティング(事前学習済み表現の k-means クラスタ重心をルーティングに使う)は、DeepSeek-V3 のバイアス動的調整・MiniMax-M2 のシグモイドゲーティング・Kimi K3 の Quantile Balancing のような LLM MoE のゲーティング系譜に対しても有効か。時系列は連続値・低次元の表現空間だからこそ事前学習済みクラスタリングが機能する可能性があり、離散トークンを扱う言語 MoE でも「ゲートを学習せず事前学習済み表現を流用する」設計が成立するかは未検証。(Source: [[@2024__arXiv__Moirai-MoE - Empowering Time Series Foundation Models with Sparse Mixture of Experts]]) - Token Clusters ゲーティングが「選択の多様性が最も低いのに性能が最も高い」(Moirai-MoE Figure 9)という観察は、本ページが整理した load balance 系譜(FasterMoE のシャドーイング・DeepSeek-V3 のバイアス調整等、いずれも多様性の確保を志向)の設計原則と緊張関係にある。多様性より的を絞ったルーティングが優先されるべき条件(データ分布が明確なクラスタ構造を持つ場合等)はどう特徴づけられるか。(Source: [[@2024__arXiv__Moirai-MoE - Empowering Time Series Foundation Models with Sparse Mixture of Experts]]) - 推論で見えた「MoE のボトルネック = ディスク I/O / メモリ階層」([[@2026__MLSys2026__ProfInfer - An eBPF-based Fine-Grained LLM Inference Profiler]])は、訓練側の通信/負荷分散最適化とは別レイヤーの課題か。エキスパートの「距離」(再利用性)に基づくキャッシュ/プリフェッチは、訓練時の expert 配置最適化(FlexMoE 等)と統合できるか。 - グレーノード/fail-slow 検知([[Guard]] のピアベース異常スコアリング)は、MoE 固有の All-to-All 負荷(ディスパッチ/結合の 2 同期点)を明示的に考慮すべきか。密モデル前提のステップ時間ベース検知は、MoE で層方向に累積する通信劣化の根因(どの同期点・どの層か)を箇所特定できるか([[@2026__MLSys2026__Guard - Scalable Straggler Detection and Node Health Management for Large-Scale Training]] は MoE を影響増幅源として挙げるが MoE 専用の異常スコアリングには踏み込まない)。 - Keep Routing([[@2025__arXiv__DeepSeek-V3.2 - Pushing the Frontier of Open Large Language Models]])は推論/訓練間のルーティング不一致を「パスの強制」で解消するが、推論フレームワークの最適化（カーネル融合・量子化）がルーティング判定に影響する場合のロバスト性は未検証。ルーティング判定を推論/訓練で構造的に共有するアーキテクチャ設計（例: ルーティングロジックの分離モジュール化）は有効か。 - VLM で MoE を使う場合、視覚トークン(動的タイリングにより数が変動)とテキストトークンが同一のゲーティング関数でルーティングされるが、モダリティ間でエキスパートの専門化パターンは異なるか。視覚専用/テキスト専用のエキスパートが自然に出現するのか、それともモダリティ非依存に使われるのか。DeepSeek-VL2 はこの点に踏み込んでいない。 - [[LatentMoE]] の潜在次元比 d/ℓ は Nemotron 3 で 4、Kimi K3(Stable LatentMoE)で 2 の2点が報告された。d/ℓ を変えたときの精度/通信量/メモリ帯域のパレートカーブはどうなるか。また FAST のオンラインスケジューリングと LatentMoE のアーキテクチャ的通信削減、[[MoonEP]] の完全均衡設計を組み合わせた場合の効果は加算的か。 - Quantile Balancing のヒストグラム近似分位数と真の分位数の誤差が、DeepSeek-V3 のバイアス動的調整・MiniMax-M2 のシグモイドゲーティングと比べたダウンストリーム性能にどの程度影響するか。3手法の定量比較は Kimi K3 技術レポート単体では確認できない。 - Rubin の TMA インライン・ディスクリプタ更新は expert 数が数百〜千規模(Kimi K3 の 896 エキスパート等)までスケールしても、共有ディスクリプタの前提(同一レイアウト)が崩れないか。エキスパートごとにサイズ・レイアウトが異なる異種 MoE(将来のアーキテクチャ)ではこの機構はどう再設計されるか。 - MoonEP の「冗長エキスパート上限 E/R」証明はオフライン ILP 参照解との比較で近似最適性を主張するが、超大規模(数千エキスパート)でこの上限がボトルネックに転化する規模はどこか。FAST のスケジューリング層最適化と MoonEP の構造的均衡は同一システムで併用可能か、それとも設計思想が競合するか。 - Calculon-MoE の FullFlat CPO トポロジ(物理層での SU/SO 帯域均等化)と、FAST(スケジューリング層)・LatentMoE(アーキテクチャ層)・MoonEP(構造的均衡層)を同一システムに組み合わせた場合、通信ボトルネック緩和効果は単純加算的か、それとも一部が重複して頭打ちになるか。物理層の解が十分であればソフトウェア層の複雑な最適化(動的スケジューリング等)は不要になるのか。 - Calculon-MoE の decoupled parallelism(EP≠#Experts、ES≠TP)は GPT4-1.8T の 1 モデルでのみ実証された。Kimi K3(896 エキスパート)や DeepSeek-V4(384 エキスパート)のような超多エキスパートモデルでも同様に、デフォルト設定から乖離した EP/ES 割り当てが MFU を改善するか。エキスパート数・モデル規模と最適な EP/ES 比の関係は未解明。 ## 関連 - ソース: [[@2026__SIGCOMM__Connecting 100K+ GPUs - Building the Communication Stack for Large-Scale LLM Training]] / [[@2024__arXiv__DeepSeek-VL2 - Mixture-of-Experts Vision-Language Models for Advanced Multimodal Understanding]] / [[Efficient Large Language Models - A Survey]] / [[Efficient Training of Large Language Models on Distributed Infrastructures]] / [[@2025__arXiv__Foundation Models for Time Series - A Survey]] / [[@2026__MLSys2026__Guard - Scalable Straggler Detection and Node Health Management for Large-Scale Training]] / [[@2026__NSDI__FAST - An Efficient Scheduler for All-to-All GPU Communication]] / [[@2026__IPDPS__Beyond Throughput - Performance and Energy Insights of LLM Inference Across AI Accelerators]] / [[@2026__ICS__Closing the Efficiency Gap - AI Datacenter Co-design Roadmap for Scalable Training of LLMs]] / [[@2026__Cursor__Mixture-of-Kittens - our open-source MoE megakernel for NVL72s]] / [[@2024__arXiv__Moirai-MoE - Empowering Time Series Foundation Models with Sparse Mixture of Experts]] / [[@2025__ICLR__Time-MoE - Billion-Scale Time Series Foundation Models with Mixture of Experts]] - 概念: [[LLM分散学習]] / [[並列化戦略]] / [[時系列基盤モデル]] / [[LLM推論]] / [[GPU観測性]] / [[動的計装]] / [[ストラグラー]] / [[耐障害LLM訓練]] / [[AIアクセラレータ]] / [[Prefill-Decode分離]] / [[負荷分散]] / [[LLM推論設計空間探索]] / [[AIデータセンタートポロジ]] / [[集合通信]] / [[メガカーネル]] - エンティティ: [[llama.cpp]] / [[GGML]] / [[Guard]] / [[DeepSeek-AI]] / [[DeepSeek-VL2]] / [[SGLang]] / [[DeepEP]] / [[DeepGEMM]] / [[EPLB]] / [[Calculon-MoE]] / [[Mixture-of-Kittens]] / [[Cursor Research]] - 関連 MOC: [[分散深層学習 - MOC]] / [[時系列基盤モデル - MOC]] / [[AI Infra Telemetry - MOC]] / [[Systems for ML - MOC]] - コンセプト: [[フォトニックインターコネクト]] ## 出典 - [[@2026__SIGCOMM__Connecting 100K+ GPUs - Building the Communication Stack for Large-Scale LLM Training]](本番 LLM 事前学習の集合通信を並列化スキーム/メッセージサイズ/プロセスグループサイズ別に集計。EP=ほぼ全て AlltoAllv・小メッセージ・8GPU未満のグループに構造的に閉じることを定量化) - [[@2017__ICLR__Outrageously Large Neural Networks The Sparsely-Gated Mixture-of-Experts Layer]](スパースゲート MoE の基盤論文。top-k ゲーティング・重要度損失・負荷損失。2048 エキスパート・137B パラメータで言語モデリング・機械翻訳 SOTA。ネットワーク帯域ボトルネックの最初の指摘) - [[Efficient Training of Large Language Models on Distributed Infrastructures]](§2.1 MoE, §4.1.5 Expert Parallelism) - [[@2025__arXiv__Foundation Models for Time Series - A Survey]](§4.1.4 Time-MOE, §4.3.2 Huber + Auxiliary Loss) - [[@2026__MLSys2026__ProfInfer - An eBPF-based Fine-Grained LLM Inference Profiler]](MoE エキスパート距離の追跡・ボトルネック = ディスク I/O) - [[@2025__eBPF__eInfer - Unlocking Fine-Grained Tracing for Distributed LLM Inference with eBPF]](MoE ルーティング挙動の観測) - [[@2026__MLSys2026__Guard - Scalable Straggler Detection and Node Health Management for Large-Scale Training]](MoE の 2 同期点による通信劣化の層方向累積・CPU コア需要) - [[@2026__NSDI__FAST - An Efficient Scheduler for All-to-All GPU Communication]](MoE AllToAllv の動的性・歪みの実測、Birkhoff 分解による 2 フェーズ動的スケジューリング、AMD Megatron-LM 統合で RCCL 比最大 4.48× 向上) - [[Efficient Large Language Models - A Survey]](§2.5.2 MoE ベース LLM タクソノミー: GShard/Switch Transformer/Mixtral 8x7B、アルゴリズムレベル/システムレベル最適化の二面整理) - [[@2025__arXiv__Kimi K2 - Open Agentic Intelligence]](スパーシティスケーリング則、384 エキスパート/スパーシティ 48、アテンションヘッド半減、DualPipe 不採用、インターリーブド 1F1B + EP16) - [[@2025__arXiv__Nemotron 3 - Efficient and Open Intelligence]](LatentMoE: 潜在次元 ℓ < d でエキスパート計算・All-to-All 通信を d/ℓ 倍削減、エキスパート数 128→512・活性化 6→22 で精度向上) - [[@2026__arXiv__The MiniMax-M2 Series - Mini Activations Unleashing Max Real-World Intelligence]](§2 MoE アーキテクチャ、シグモイドゲーティング + エキスパートバイアスによる負荷分散) - [[@2025__DeepSeek__DeepSeek-V4 - Towards Highly Efficient Million-Token Context Intelligence]](§2.1 DeepSeekMoE 継承と √Softplus ゲーティング、§3.1 MegaMoE ウェーブベース EP 融合カーネル、§4.2.3 Anticipatory Routing・SwiGLU Clamping による訓練安定化) - [[@2025__arXiv__DeepSeek-V3.2 - Pushing the Frontier of Open Large Language Models]](Keep Routing: MoE の RL 訓練安定化のため推論/訓練間のエキスパートルーティングパスを強制一致。DeepSeek-V3-0324 以降採用) - [[@2024__arXiv__DeepSeek-V3 Technical Report]](§2.1.2 DeepSeekMoE + 補助損失なし負荷分散、§3.2.1 DualPipe、671B/37B MoE の訓練安定性) - [[@2024__arXiv__DeepSeek-VL2 - Mixture-of-Experts Vision-Language Models for Advanced Multimodal Understanding]](VLM への MoE 適用、動的タイリング + DeepSeekMoE、Tiny/Small は softmax、最大は sigmoid ルーティング + エキスパート補正バイアス) - [[@2026__IPDPS__Beyond Throughput - Performance and Energy Insights of LLM Inference Across AI Accelerators]](MoE 推論: 同パラメータ密モデル比でスループット優位小さい; EP vs TP では TP 優勢・DeepSeek R1 (256 エキスパート) は EP が逆転) - [[@2025__LMSYS Blog__Deploying DeepSeek with PD Disaggregation and Large-Scale Expert Parallelism on 96 H100 GPUs]](96 H100 GPU での DeepSeek-V3 級モデルの大規模 EP 展開。層別並列化(Attention/密FFN=DP、疎FFN=EP)、DeepEP Normal/Low-Latency Dispatch、EPLB によるスループット向上 Prefill 1.49x・Decode 2.54x) - [[@2026__Moonshot AI__Kimi K3 - Open Frontier Intelligence]](Stable LatentMoE: 896 エキスパート中 16 活性化・スパーシティ 56。RMSNorm・SiTU-GLU・Quantile Balancing による3要素安定化。LatentMoE(Elango et al.)を継承した設計であることを確認。MoonEP による完全均衡型 Expert Parallelism。技術レポート全文、2026-07-27 公開) - [[@2026__NVIDIA Developer Blog__Inside NVIDIA Rubin GPU Architecture Powering the Era of Agentic AI]](Rubin GPU の TMA インライン・ディスクリプタ更新による MoE 重み・トークン移動のハードウェア co-design) - [[@2026__MLSys2026__Optimizing Deployment Configurations for LLM Inference]](Meta、月間10億ユーザー規模の本番運用実測。iso-parameter Dense/MoE 比較で EP がスケールアウト時の Decode QPS を+16%改善(Dense は-60%悪化)、1.8T規模でDenseはスケールアップ必須・MoEはスケールアウトでも良好にスケール、エキスパート負荷予測モデル間で最大3.5倍のコスト差、MLSys 2026 Industry Track) - [[@2026__Cursor__Mixture-of-Kittens - our open-source MoE megakernel for NVL72s]](Cursor Research の OSS MoE 訓練メガカーネル。pull-based dispatch・ミニバッチ単位オーバーラップ・リングトークンバッファで NVIDIA GB300 NVL72 向けに最適化。単一 MoE 層 MXFP8 順伝播最大2.37倍・本番エンドツーエンド1.41倍) - [[@2026__ICS__Closing the Efficiency Gap - AI Datacenter Co-design Roadmap for Scalable Training of LLMs]]([[Calculon-MoE]]: MoE 対応データセンター co-design 解析ツール。FullFlat CPO トポロジによる SU/SO 帯域均等化で上位 5,000 構成間の性能ギャップを 70%→13% に縮小。EP≠#Experts・ES≠TP の decoupled parallelism で MFU を最大 7.7 ポイント改善。HBD=1024・HBM 1.3TB/GPU を co-design 目標として提示) - [[@2025__OReilly__AI Systems Performance Engineering - Chapter 15 Multinode Inference, Parallelism, Decoding, and Routing Optimizations]](実務教科書によるエキスパート並列・動的ルーティングの整理。階層的ルーティング・butterflyスケジュール・エキスパート併置・FP8/NVFP4圧縮によるAll-to-All緩和、capacity factor(1.2程度)によるオーバーフロー処理、ホットエキスパート複製、リアルタイム負荷監視による適応的ルーティング) - [[@2024__arXiv__Moirai-MoE - Empowering Time Series Foundation Models with Sparse Mixture of Experts]](時系列基盤モデル Moirai の FFN を単一射影層 + MoE に置換。事前学習済み表現の k-means クラスタ重心でゲーティングする Token Clusters 手法を提案し、線形射影ゲーティングを一貫して上回る。39 データセットで Moirai比最大17%改善) - [[@2025__ICLR__Time-MoE - Billion-Scale Time Series Foundation Models with Mixture of Experts]](時系列基盤モデルへの MoE 適用のもう一つの系統。decoder-only + Huber 損失 + 多解像度予測ヘッドで 2.4B パラメータへのスケーリングを主眼とする)