はじめに#

以前書いたQwen3.6の記事で「Sparse MoE で総パラメータ 35B・アクティブ 3B」という設計を扱った。推論時は3B相当のFLOPsで動くMoE（Mixture of Experts）モデルだ。

ここで素朴な疑問が湧いた。

• 35Bのパラメータを持つとして、学習はどうやるんだろう？
• Dense（普通の）モデルと同じ学習ループが使えるのか？
• メモリだけ気をつければOK？

この記事ではその疑問を起点に、MoEモデルの学習を基礎から整理する。先に結論だけ言うと：

学習ループの骨格はDenseと同じだが、内部では複数のMoE固有の機構が動いている。

メモリだけでなく、勾配の流れ方・Load Balancing・分散学習の通信パターンなど、Denseとは異なる設計上の工夫が必要になる。

MoEの基本構造#

1
入力トークン x
2
    │
3
    ▼
4
┌──────────┐
5
│  Router   │  ← 各ExpertへのスコアをCompute。Top-K を選択
6
│ (Gate)    │
7
└──────────┘
8
    │ Top-K 選択
9
    ▼
10
┌──────┐ ┌──────┐ ┌──────┐     ┌──────┐
11
│ E_1  │ │ E_2  │ │ E_3  │ ... │ E_N  │   ← N個のExpert（FFN）
12
└──────┘ └──────┘ └──────┘     └──────┘
13
  活性化   活性化                 非活性化
14
    │        │
15
    ▼        ▼
16
  重み付き合算 → 出力

学習ループの骨格はDenseと同じ#

MoEモデルの学習ループ自体は、Denseと骨格は同じだ。

1
[データローダ] → [Forward] → [Loss計算] → [Backward] → [Optimizer更新]

PyTorch + HuggingFace等のフレームワークがRouter + Expertの計算グラフを構築してくれるため、ユーザーから見た学習コードは大きくは変わらない。

この意味では「普通のTransformerと同じように学習できるか？」という最初の疑問への答えは「おおむねYes、コードの見た目は変わらない」だ。

でも内部はかなり違う#

骨格は同じでも、中身はDenseとは別物だ。6つの観点で整理する。

勾配の流れが本質的に違う#

MoEとDenseの最大の違いはここだ。

メモリは推論と学習で大きく違う#

「35B-A3Bなら学習時も3B相当のメモリでOK？」という疑問にはNo が答えだ。

推論時は3B相当のFLOPsで済むが、学習時のメモリは35B分のDenseとほぼ同等になる。AdamWのOptimizer Stateまで含めると、FP32で35B×3倍近い領域が必要になる計算だ。

「メモリだけ注意すればOK？」という問いには、「メモリが最大の注意点であることは正しい。ただしそれだけではない」が正確な答えになる。

MoE最大の課題：Load Balancing#

MoE固有の課題として、Routing Collapse がある。RouterがあるExpertばかりを選び続けると：

• 一部のExpertだけが学習され、残りが死ぬ
• 分散学習時に特定ノードがボトルネックになる
• Expert間で似たような知識を持つようになり、MoEの利点が消える

この問題を解決するためのアプローチが複数ある。

1
Total Loss = LM Loss + α × (Importance Loss + Load Loss)

学習の不安定性と分散学習#

LoRAはMoEにそのまま使える？#

答えは「使える。ただし全Expert一律適用は非効率」だ^6。

各ExpertのFFN層にLoRAアダプタを挿入する形で使え、HuggingFaceのPEFTライブラリもMoEモデルへのLoRA適用をサポートしている。

まとめ#

「MoEモデルは普通に学習できるのか？」という最初の疑問への答えをまとめる。

Q. 学習ループはDenseと同じ？ 骨格は同じ。コードの見た目はほぼ変わらない。ただし内部ではRouterの勾配近似・Load Balancing・Expert Parallelismなど、Dense にはない機構が動作している。

Q. メモリだけ注意すればOK？ メモリが最大の注意点であることは正しい。推論時はアクティブパラメータ分で済んでも、学習時は総パラメータ分のDenseモデルと同等の扱いが必要だ。加えてLoad Balancing設定・Expert Parallelism設計・学習安定化のハイパーパラメータ調整も必要になる。

Q. LoRAはそのまま使える？ 使える。ただし全Expert一律適用は非効率で、MoE-Sieve（上位25%のみ）やDR-LoRA（Expertごとにランクを変える）のような特化手法を使うと、大幅にコストを下げながら同等の性能を出せる。

「骨格は同じ・中身は別物」がMoEの学習を一言で表す表現だと思う。

参考文献#

1. Mixture of Experts Explained (HuggingFace) https://huggingface.co/blog/moe
2. MoEs in Transformers (HuggingFace) https://huggingface.co/blog/moe-transformers
3. Auxiliary-Loss-Free Load Balancing Strategy for Mixture of Experts https://arxiv.org/abs/2408.15664
4. Expert-Router Coupling Loss https://arxiv.org/abs/2512.23447
5. Scalable Training of MoE with Megatron Core https://arxiv.org/abs/2603.07685
6. Training MoE Models (EngineersOfAI) https://engineersofai.com/docs/llms/mixture-of-experts/Training-MoE-Models
7. DR-LoRA: Dynamic Rank LoRA for MoE https://arxiv.org/html/2601.04823v4
8. MoE-Sieve: Routing-Guided LoRA https://arxiv.org/html/2603.24044v1
9. MIXLORA: Enhancing Large Language Models Fine-Tuning with LoRA-based Mixture of Experts https://arxiv.org/pdf/2404.15159
10. HILO: Hierarchical Low-Rank Adaptation https://arxiv.org/pdf/2502.03884