# Mixture-of-Experts ## 定義 Mixture-of-Experts(MoE)は、FFN を疎に活性化する形に置き換える Transformer の変種アーキテクチャ。複数の expert network(異なる訓練データの部分集合を処理)と gate network(ルーティングアルゴリズムで token を expert に割り当てる)からなり、入力ごとに一部の expert のみを活性化する[[条件付き計算]]により、パラメータ数を大幅に増やしても計算コストの増加を抑える。これにより 1 兆規模超のパラメータの訓練が可能になる。([[@2026__Vicinagearth__Efficient Training of Large Language Models on Distributed Infrastructures - A Survey]] §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 等。 ## 横断的知見 - **スパースゲート 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]], [[@2024__TMLR__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 訓練インフラから時系列基盤モデルへ適用領域を広げている**: [[@2026__Vicinagearth__Efficient Training of Large Language Models on Distributed Infrastructures - A Survey]] が 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: [[@2026__Vicinagearth__Efficient Training of Large Language Models on Distributed Infrastructures - A Survey]], [[@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: [[@2026__Vicinagearth__Efficient Training of Large Language Models on Distributed Infrastructures - A Survey]], [[@2025__arXiv__Foundation Models for Time Series - A Survey]]) - **MoE の AllToAllv は訓練時間の 30–56% を占め「スケジューリング不可」という前提が崩れた**: [[@2026__Vicinagearth__Efficient Training of Large Language Models on Distributed Infrastructures - A Survey]] がコミュニケーション最適化を「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]], [[@2026__Vicinagearth__Efficient Training of Large Language Models on Distributed Infrastructures - A Survey]]) - **MoE の動的ルーティングは実行時計装でしか捉えられず、推論のボトルネックを観測すると訓練の想定と違う姿が見える**: 訓練系サーベイが MoE を「All-to-All 通信ボトルネック」「expert 負荷不均衡」として扱うのに対し、推論([[LLM推論]])を細粒度に観測する論文は別の律速を見つける。[[@2026__arXiv__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__arXiv__ProfInfer - An eBPF-based Fine-Grained LLM Inference Profiler]], [[@2025__eBPF__eInfer - Unlocking Fine-Grained Tracing for Distributed LLM Inference with eBPF]]) - **MoE ベース LLM はパラメータ効率と推論速度を両立するが、アルゴリズムとシステムの二重最適化を要する**: [[@2024__TMLR__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 倍）がそれぞれ独立に進む。分散訓練サーベイ [[@2026__Vicinagearth__Efficient Training of Large Language Models on Distributed Infrastructures - A Survey]] が通信/負荷分散を中心に扱うのに対し、Wan+ はアルゴリズム側（ルーティング戦略・安定性・タスク適応）とシステム側（トポロジ対応・エッジ推論・動的パイプライン）の両面を網羅しており、2 つのサーベイは相補的な粒度で MoE を描写する。(Source: [[@2024__TMLR__Efficient Large Language Models - A Survey]], [[@2026__Vicinagearth__Efficient Training of Large Language Models on Distributed Infrastructures - A Survey]]) - **MoE のスパーシティスケーリング則が実証され「固定 FLOPS でスパーシティを上げるだけで性能向上」が設計原則に昇格しつつある**: [[Kimi K2]] は Muon オプティマイザ下で固定活性化パラメータ(8 エキスパート活性化)のままエキスパート数を 8→64 まで変化させ、スパーシティ 48(384 エキスパート)がスパーシティ 8 比で 1.69× の FLOPS 節約を達成することを定量化した。DeepSeek-V3(256 エキスパート)からスパーシティを 50% 増(384 エキスパート)に引き上げつつアテンションヘッドは半減(128→64)し、推論 FLOPS 83% 削減と性能向上を両立する。[[@2026__Vicinagearth__Efficient Training of Large Language Models on Distributed Infrastructures - A Survey]] が MoE のスケーリングを「パラメータ ↑ / 計算コスト ≈」として概説するのに対し、Kimi K2 は**スパーシティ自体をスケーリング変数とする定量則**を Muon 下で初めて体系的に示した。(Source: [[@2025__arXiv__Kimi K2 - Open Agentic Intelligence]], [[@2026__Vicinagearth__Efficient Training of Large Language Models on Distributed Infrastructures - A Survey]]) - **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 にシグモイドゲーティング(ソフトマックスのゼロサム制約を排除)と学習可能なエキスパートバイアスを組み合わせ、補助損失への依存を大幅に削減した。サーベイ([[@2024__TMLR__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]], [[@2024__TMLR__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 以降のパイプラインに標準採用している。推論フレームワークと訓練フレームワークの実装差異がルーティングの不一致を引き起こし、アクティブパラメータ部分空間の急変で最適化が不安定化するという障害は、サーベイ([[@2026__Vicinagearth__Efficient Training of Large Language Models on Distributed Infrastructures - A Survey]])が 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]], [[@2026__Vicinagearth__Efficient Training of Large Language Models on Distributed Infrastructures - A Survey]]) - **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 訓練サーベイ([[@2026__Vicinagearth__Efficient Training of Large Language Models on Distributed Infrastructures - A Survey]])が 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]], [[@2026__Vicinagearth__Efficient Training of Large Language Models on Distributed Infrastructures - A Survey]]) - **共有エキスパート(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)へ拡大した。エキスパート数・活性化数がともに約 2.3 倍に増えており、Kimi K2 が実証した「スパーシティ自体をスケーリング変数とする」設計原則([[@2025__arXiv__Kimi K2 - Open Agentic Intelligence]])が継続していることを示唆する。ただし K3 発表時点(2026-07-17)ではブログ記事のみで技術レポート未公開のため、スパーシティ増加の定量的根拠(FLOPS 節約率等)は確認できていない。(Source: [[@2025__arXiv__Kimi K2 - Open Agentic Intelligence]], [[@2026__Moonshot AI__Kimi K3 - Open Frontier Intelligence]]) - **「LatentMoE」の名称が NVIDIA と Moonshot AI で独立に使われ、設計の異同が未確認**: [[@2025__arXiv__Nemotron 3 - Efficient and Open Intelligence]] の [[LatentMoE]](潜在次元 d/ℓ≈4 へ射影しエキスパート計算・通信を削減、エキスパート数 128→512)と、Kimi K3 の [[Stable LatentMoE]](896 エキスパート中 16 活性化)は名称が類似するが、Kimi K3 側の情報源(ブログ記事)は具体的機構を開示していない。両者が同一の潜在次元射影アイデアを指すのか、それとも偶然の命名重複かは技術レポート公開(2026-07-27 予定)後に要検証。(Source: [[@2025__arXiv__Nemotron 3 - Efficient and Open Intelligence]], [[@2026__Moonshot AI__Kimi K3 - Open Frontier Intelligence]]) - **MoE の負荷分散手法系譜に「ルータスコア分位数によるエキスパート割り当て」という第 5 の方向が加わる可能性**: サーベイが整理する auxiliary loss・システム層配置最適化・DeepSeek-V3 のバイアス動的調整・MiniMax-M2 のシグモイドゲーティングに加え、Kimi K3 は Quantile Balancing(ルータスコアの分位数からエキスパート割り当てを導出)を採用したと発表する。ただし記事は数式・アルゴリズムの詳細を開示しておらず、既存手法(バイアス調整・シグモイドゲーティング)との異同は未確認。(Source: [[@2026__Moonshot AI__Kimi K3 - Open Frontier Intelligence]]) ## 未解決の問い - 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 の訓練インフラ詳細に踏み込まない)。 - 推論で見えた「MoE のボトルネック = ディスク I/O / メモリ階層」([[@2026__arXiv__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/ℓ は 4 の 1 点しか報告されていない（[[@2025__arXiv__Nemotron 3 - Efficient and Open Intelligence]]）。d/ℓ を変えたときの精度/通信量/メモリ帯域のパレートカーブはどうなるか。また FAST のオンラインスケジューリングと LatentMoE のアーキテクチャ的通信削減を組み合わせた場合の効果は加算的か。 - Kimi K3 の Stable LatentMoE(896 エキスパート/活性化 16)は NVIDIA の LatentMoE と同一設計か。「Stable」が指す安定化機構は何か。技術レポート公開(2026-07-27 予定)後に確認が必要。 - Quantile Balancing(Kimi K3)の具体的アルゴリズムと、DeepSeek-V3 のバイアス動的調整・MiniMax-M2 のシグモイドゲーティングとの定量比較。 ## 関連 - ソース: [[@2024__arXiv__DeepSeek-VL2 - Mixture-of-Experts Vision-Language Models for Advanced Multimodal Understanding]] / [[@2024__TMLR__Efficient Large Language Models - A Survey]] / [[@2026__Vicinagearth__Efficient Training of Large Language Models on Distributed Infrastructures - A Survey]] / [[@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]] - 概念: [[LLM分散学習]] / [[並列化戦略]] / [[時系列基盤モデル]] / [[LLM推論]] / [[GPU観測性]] / [[動的計装]] / [[ストラグラー]] / [[耐障害LLM訓練]] / [[AIアクセラレータ]] / [[Prefill-Decode分離]] / [[負荷分散]] - エンティティ: [[llama.cpp]] / [[GGML]] / [[Guard]] / [[DeepSeek-AI]] / [[DeepSeek-VL2]] / [[SGLang]] / [[DeepEP]] / [[DeepGEMM]] / [[EPLB]] - 関連 MOC: [[分散深層学習 - MOC]] / [[時系列基盤モデル - MOC]] / [[AI Infra Telemetry - MOC]] / [[Systems for ML - MOC]] ## 出典 - [[@2017__ICLR__Outrageously Large Neural Networks The Sparsely-Gated Mixture-of-Experts Layer]](スパースゲート MoE の基盤論文。top-k ゲーティング・重要度損失・負荷損失。2048 エキスパート・137B パラメータで言語モデリング・機械翻訳 SOTA。ネットワーク帯域ボトルネックの最初の指摘) - [[@2026__Vicinagearth__Efficient Training of Large Language Models on Distributed Infrastructures - A Survey]](§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__arXiv__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× 向上) - [[@2024__TMLR__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。Quantile Balancing によるルータスコア分位数ベースのエキスパート割り当て。技術レポート未公開のため詳細は暫定)