MoE（Mixture of Experts）とは？疎活性化とルーターの仕組み・VRAM要件と採用判断を実装者向けに解説

2025年から2026年にかけて公開された大規模なオープンウェイトモデルは、そのほとんどがMoE（Mixture of Experts）という構造を採っています。パラメータ総数は数千億から兆の桁まで伸びる一方、1トークンあたりに動く計算量は数十億パラメータ相当に抑えられる。この「大きいのに軽い」という性質が、自社基盤へ載せる段になると独特の落とし穴につながる要因です。本記事では、MoEの内部で何が起きているかを処理単位まで分解し、VRAM見積もりとエキスパート並列の起動設定、そして採用してよい条件までを2026年7月時点の一次情報で整理します。モデル全体の骨格であるTransformerの自己注意の仕組みは別記事で扱っているため、本記事はFFN層の置き換えに絞ります。

まとめ：MoEの仕組みとVRAM要件・採用判断の結論

MoE（Mixture of Experts、エキスパート混合）は、ニューラルネットワークのFFN層を複数の小さなサブネットワーク（エキスパート）に分割し、入力トークンごとに一部だけを動かす構造です。全部を動かす従来型を「密（Dense）モデル」と呼ぶのに対し、MoEは「疎（Sparse）モデル」に分類されます。

効き方は単純です。エキスパートを128基置いて上位8基だけ動かせば、パラメータ総数は増やしながら1トークンあたりの計算量は総数の一部で済む。DeepSeek-V3なら総671Bに対して活性37B、gpt-oss-120bなら総120Bに対して活性5.1Bという比率になります。学習と推論の計算コストを抑えたまま、モデルの知識容量だけを伸ばせる仕掛けです。

ただし、自社基盤へ載せるときの制約は計算量ではなくメモリ側に出ます。どのエキスパートが選ばれるかはトークンごとに変わるため、使われない重みもGPU上に置いておく必要がある。つまりVRAMは活性37Bではなく総671B分を要求します。「活性パラメータが小さいから小さいGPUで動く」という読み違えが、MoE導入で最も多い失敗です。

判断の起点は、GPU台数と負荷の常時性の2つ。複数GPUを確保でき、エキスパート並列で分散配置でき、かつバッチをある程度まとめて流せる負荷があるならMoEが効きます。単一GPUに収めたい、同時実行が数本しかない、レイテンシのばらつきを嫌う——このいずれかに当てはまるなら、同程度の性能を持つ密モデルか小規模モデルに留めるほうが総コストで有利です。

MoEが解く問題と疎活性化の仕組み｜ルーターとエキスパートの役割

まず、この構造が何を解こうとしているのかを確定させます。

密（Dense）モデルとの違いは総パラメータと活性パラメータの分離

従来のTransformerでは、各層のFFN（フィードフォワード層）が1つの大きな行列演算として置かれ、どのトークンが来ても全パラメータが計算に参加します。パラメータを2倍にすれば、推論の計算量もほぼ2倍。性能を伸ばすほど1トークンあたりのコストが線形に膨らむ構造でした。

MoEはこのFFN層を、同じ形の小さなFFN（エキスパート）の集合に置き換えます。そのうえで、トークンごとに少数のエキスパートだけを選んで通す。ここで「総パラメータ数」と「1トークンあたりに動く活性パラメータ数」が分離します。Qwen3-30B-A3Bという名前の「A3B」は Active 3B の意味で、総30.5Bのうち実際に動くのが3.3Bであることを型番自体が示しています。

この分離が学習側でも効きます。同じ計算予算でパラメータ総数を増やせるため、知識容量を伸ばしながら学習時間を抑えられる。DeepSeek-V3は671Bという規模を、14.8兆トークンの事前学習で2.788M H800 GPU時間に収めたと技術報告で公表しました。密モデルで同じ規模を回した場合と比べ、計算量の桁が変わります。

ルーター（ゲートネットワーク）がトークンごとにエキスパートを選ぶ

選択を担うのがルーター（ゲートネットワーク）です。実体は小さな線形層で、トークンの隠れ状態を受け取ってエキスパート数ぶんのスコアを出します。そこから上位k個を取り、選ばれた分だけを正規化して重みにする。各エキスパートの出力をその重みで足し合わせたものが、その層の出力になります。

logits = router(x)                  # 形状 [トークン数, エキスパート数]
topk_val, topk_idx = topk(logits, k=8)
w = softmax(topk_val)               # 選ばれた8基分だけ正規化
y = sum(w[i] * expert[topk_idx[i]](x) for i in range(8))

ここで押さえるべきは、選択の粒度がトークン単位である点です。「日本語は3番のエキスパート、コードは7番」といった人間が読める分業にはなりません。学習の過程で自動的に定まる分担であり、何を担当しているかを事後に解釈するのは難しい。エキスパートという名前から想像される専門分野の割り当てとは別物として扱ってください。

もう1点、選択がトークンごとに切り替わるということは、同じ文の中でも層ごと・トークンごとに参照される重みが飛び回るということでもあります。この動きが、後述するメモリ要件と通信量の話に直結します。

エキスパートの負荷の偏りを抑える補助損失と補助損失なし方式の違い

ルーターを素直に学習させると、特定のエキスパートばかりが選ばれる偏りが起きます。選ばれるほど学習が進み、学習が進むほど選ばれやすくなる正のループが働くためです。使われないエキスパートはパラメータの無駄になり、選ばれ過ぎたエキスパートは処理容量の上限（容量係数）を超えてトークンが捨てられる「トークン落ち」を招きます。

古典的な対処が補助損失（auxiliary loss）です。エキスパートごとの割り当て比率が均等から離れるほど罰則を与える項を、本来の損失に足す。分散は取れますが、本来の学習目標とは別方向の圧力が掛かるため、精度が落ちる副作用がありました。

DeepSeek-V3が採ったのは補助損失なし（auxiliary-loss-free）の方式です。損失項ではなく、エキスパートごとのバイアス値を負荷の実績に応じて動的に上下させることで選択確率を均します。学習目標そのものを歪めずに分散を取る設計で、技術報告では補助損失に伴う性能劣化を避ける狙いが明示されました。自前で学習する場合、どちらの方式かは再現性と精度の両面に影響します。

主要MoEモデルのエキスパート数と活性パラメータの構成を数値で読む

抽象論だけでは判断材料になりません。公表仕様を並べます。

主要オープンウェイトモデルのエキスパート構成を数値で読み比べる

いずれも2026年7月時点の各モデルの公表仕様です。エキスパート数と選択数の組み合わせが、そのモデルの「軽さ」を決めます。

読み取れる傾向は2つ。1つは、世代が新しいほどエキスパートを細かく多数に割る方向へ動いていること。Mixtralの8基から、Qwen3やgpt-ossの128基、DeepSeek-V3の256基へと粒度が上がっています。もう1つは、活性比率が下がり続けていること。Mixtralの約28%（12.9÷46.7）に対し、gpt-oss-120bは約4%、Qwen3-30B-A3Bは約11%です。

この比率は、そのままGPU効率の設計思想を表します。活性比率が低いほど1トークンの計算は軽くなりますが、重みを置くメモリは総パラメータ側で効いたまま。つまり「計算は安く、メモリは高い」方向へ振っている設計だと読めます。

共有エキスパートと細粒度分割でDeepSeekMoEが変えた設計

DeepSeek-V3の構成には、単なる数の増加とは別の工夫が2つ入っています。1つは共有エキスパート（shared expert）で、これは全トークンが必ず通る固定のエキスパートです。どのトークンにも共通して要る一般的な処理を1基に集約し、ルーティング対象のエキスパートは差分だけを担う分担にします。

もう1つが細粒度分割です。エキスパート1基あたりの中間次元を小さく取り、その分だけ基数を増やす。256基から8基を選ぶ組み合わせは、8基から2基を選ぶ場合よりはるかに多く、トークンごとの表現の組み合わせが増えます。同じ活性パラメータ量でも、担当の切り分けを細かくできる設計です。

実装上の含意もあります。共有エキスパートは全トークンが通るため、分散配置では全ノードに複製を置くのが自然。一方、経路エキスパートは分散して置けます。この非対称性が、次章のエキスパート並列の配置設計に効いてきます。

MoEモデルを自社GPUで動かす｜VRAM要件とエキスパート並列の実装

ここからは実装です。MoE特有の制約は、ほぼこの章に集まります。

MoEのVRAM要件は活性パラメータでなく総パラメータ側で決まる

最初に潰しておくべき誤解がこれです。活性パラメータが3.3Bだからといって、3.3B相当のVRAMで動くわけではありません。次にどのエキスパートが選ばれるかは事前に分からないため、全エキスパートの重みをGPU上に常駐させる前提になります。

Qwen3-30B-A3B を BF16 で載せる場合
  総パラメータ 30.5B × 2バイト = 約61GB（重みのみ）
  ＋ KVキャッシュ ＋ アクティベーション余白
  → 80GB GPU 1枚では余白が薄く、2枚構成か量子化が現実的

DeepSeek-V3のような671Bクラスなら、BF16の重みだけで1.3TB超。80GB級のGPUを十数枚まとめ、ノードをまたいで配置する構成が前提になります。「活性37Bだから中規模のGPUで足りる」という見積もりは、この段階で破綻します。

現実的な緩和策は3つ。ビット幅を落とす量子化、使わないエキスパートをCPUメモリへ退避するオフロード、そして複数GPUへの分散配置です。1つ目についてはLLM量子化の仕組みとGPTQ・AWQ・GGUFの違いで手法ごとの前提を整理しています。2つ目のオフロードは、選択が外れるたびにPCIe経由の転送が挟まるため、生成速度が桁で落ちる点に注意してください。3つ目が次のエキスパート並列です。

エキスパート並列（EP）でGPUをまたいで配置するときの起動設定

エキスパート並列（Expert Parallelism、EP）は、エキスパートを複数GPUへ分けて置く並列化です。テンソル並列が1つの行列演算を切って配るのに対し、EPはエキスパートという自然な単位で分けるため、通信の粒度が粗く済みます。vLLMでは--enable-expert-parallelで有効になり、データ並列との併用が推奨構成です。

vllm serve Qwen/Qwen3-30B-A3B \
  --tensor-parallel-size 1 \
  --data-parallel-size 4 \
  --enable-expert-parallel \
  --all2all-backend deepep_low_latency

効いてくるのが--all2all-backendの選び分けです。既定のallgather_reducescatterは汎用ですが、公式ドキュメントは処理段階ごとに使い分けを示しています。プリフィル（プロンプト読み込み）主体ならdeepep_high_throughput、デコード（1トークンずつの生成）主体ならdeepep_low_latency。マルチノードのNVLink構成ではflashinfer_nvlink_one_sided系も選べます。

前提となる依存も確認が要ります。DeepEPカーネルとDeepGEMMの導入が必要で、deepep_v2バックエンドはNCCL 2.30.4以上、プリフィルとデコードを別インスタンスへ分ける分離配置ではgdrcopyが要ります。複数ノードでは--headlessと--data-parallel-addressでワーカー側を構成する形。推論エンジン側の全体像と他のオプションはvLLMの仕組みと使い方・起動オプションの決め方を参照してください。

バッチサイズと全対全通信がMoEの実効スループットを左右する理由

EPを入れると、各層で「トークンを担当GPUへ送り、結果を戻す」全対全（all-to-all）通信が2回発生します。この通信量が実効性能を決める変数になります。密モデルにはない要素で、ここを見落とすとGPUを増やしても速くなりません。

バッチサイズの効き方も密モデルとは違います。同時に流すトークンが少ないと、各GPUに割り当たるトークンが数個しかない状態でカーネルが起動し、GPUの演算器が埋まりません。逆にバッチをまとめるほど、1回の全対全通信でまとめて運べる量が増え、演算効率も上がる。MoEが「小さな負荷では割に合わず、大きな負荷で化ける」と言われる理由がここにあります。

ハードウェア側もこの通信を前提に設計が動いています。NVIDIAはGB200 NVL72について、MoEモデルでH200比10倍、広域エキスパート並列で1GPUあたりの処理量1.8倍という数値を公表しました。いずれもベンダー公表値であり、自社ワークロードでの再現は別途の実測が要りますが、GPU間の帯域がMoEの律速になるという方向性は読み取れます。

MoEモデルを採用すべき3つの条件と、密モデルに留めるべき場面

ここまでの制約を踏まえ、判断を条件付きで言い切ります。

MoEモデルを採用してよい3つの条件をVRAMと負荷から言い切る

第一に、総パラメータ分の重みを載せきるGPUメモリを確保できること。80GB級を複数枚、あるいは量子化を前提に単一枚へ収まる規模のモデルを選ぶ、のどちらかが要ります。ここが満たせない構成でMoEを選ぶ理由はありません。

第二に、GPUを埋められる同時実行の負荷が常時あること。目安として、同時リクエストが常に十数本以上あり、バッチをまとめて流せる社内サービスやAPI基盤なら、活性パラメータの小ささが処理量として返ってきます。逆に日中の数十リクエスト程度なら、投資したGPUの多くが遊びます。

第三に、モデルの知識量・多言語対応・コード生成の質を、活性パラメータ相当の密モデルより明確に上げたい要件があること。gpt-oss-120bは活性5.1Bですが、性能は5.1Bの密モデルとは別物です。この「同じ推論コストで上の性能帯に届く」点にこそMoEの価値があり、性能要件が緩いならわざわざ複雑な構成を組む必要はありません。

MoEの採用を見送って密モデルや小規模モデルに留めるべき3場面

1つ目は、単一GPUや単一ノードに収めたい制約があるとき。エッジ寄りの配置や、GPUを1枚しか確保できない案件では、総パラメータ側のメモリ要求が壁になります。この場合はSLM（小規模言語モデル）の仕組みとLLMとの違いで扱う方向、つまりモデルサイズ自体を落とす選択のほうが素直に収まります。

2つ目は、レイテンシの一貫性を厳密に求められるとき。MoEは選ばれるエキスパートの分布によってGPU間の負荷が揺れ、応答時間のばらつきが密モデルより大きくなりやすい。P99レイテンシをSLAで縛る用途では、この揺れが運用上の負債になります。

3つ目は、自前で追加学習を掛ける前提があるとき。MoEのファインチューニングは、ルーターの挙動と負荷分散を壊さないよう扱う必要があり、密モデルほど手順が確立していません。学習側の工数を見込めないなら、追加学習は密モデルで進め、MoEは推論のみで使う切り分けが安全です。

MoE推論基盤の構築を外部へ委託するとき見積書で確認する5項目

委託時に見積もりの精度を左右するのは、次の5点です。第一に、対象モデルの総パラメータとGPU構成（枚数・VRAM容量・ノード間接続）が明記されているか。活性パラメータだけが書かれた見積書は、メモリ要件を読み違えている可能性があります。

第二に、並列化の方式（テンソル並列・データ並列・エキスパート並列の組み合わせ）と、その根拠となる負荷想定。第三に、量子化を前提にする場合の手法と、精度検証の実施範囲。第四に、プリフィルとデコードを分離配置するか否かと、その場合のネットワーク要件。第五に、負荷試験の条件（同時実行数・入出力トークン長・測定するのは平均かP99か）です。

この5点が曖昧なまま進むと、構築後に「GPUは足りているのに想定の処理量が出ない」という形で表面化します。委託先を選ぶ際は、機械学習モデル開発のようにモデル構造の選定と基盤実装を一体で扱える体制かを確認してください。

よくある質問

MoEの検討時に問い合わせが多い論点を5つ挙げます。

MoEモデルは密モデルより本当に速いのですか？

1トークンあたりの計算量という意味では確かに軽くなりますが、体感速度がそのまま比例するわけではありません。全対全通信のオーバーヘッドと、バッチが小さいときのGPU利用率の低さが差し引かれるためです。同時実行が多くバッチをまとめられる本番環境では計算量の差が素直に効き、リクエストが1本ずつ来る検証環境では期待ほど速くならない、という現れ方をします。

エキスパートは分野ごとに専門化しているのですか？

人間が読める分野分担にはなっていません。ルーターの割り当ては学習の過程で自動的に定まり、トークン単位で切り替わります。「数学担当」「日本語担当」といった解釈ができるケースは限定的で、実際には表層的な特徴で分かれている報告もあります。エキスパートという呼称から専門分野の分業を想像すると設計を読み違えるため、あくまで計算の分割単位として扱ってください。

MoEモデルを量子化してもエキスパート構造は保たれますか？

保たれます。GPTQやAWQ、GGUFといった手法は重みのビット幅を落とすもので、ルーティングの仕組み自体には手を入れません。ただし精度の落ち方には固有の注意があります。エキスパートごとに重みの分布が異なるため、一律のビット幅では特定のエキスパートだけ劣化する場合があり、ルーターの層は量子化対象から外す実装も一般的です。導入前に対象モデルの量子化済み配布物で挙動を確かめるのが確実です。

MoEモデルをファインチューニングするときの注意点は何ですか？

ルーターと負荷分散を壊さないことが第一です。特定ドメインのデータだけで学習を進めると、ルーティングが少数のエキスパートに偏り、他のエキスパートが実質的に遊ぶ状態を招きます。対処としては、エキスパート本体を凍結してLoRAをアテンション側に当てる、学習率を密モデルより下げる、負荷分散の指標を学習中に監視する、といった手順が代表的です。工数は密モデルより確実に増えます。

自社でMoEモデルを動かすには何GPUから始められますか？

モデル規模によります。Qwen3-30B-A3Bクラス（総30.5B）なら、量子化を前提に80GB級1枚から検証を始められ、BF16なら2枚が目安。gpt-oss-120bクラスなら量子化前提で複数枚、DeepSeek-V3クラスの671Bになると十数枚とノード間の高速接続が前提になります。まず総パラメータ×ビット幅でメモリ量を出し、そこにKVキャッシュの余白を足すところから見積もってください。

関連記事

• LLM推論とは？仕組みと高速化の手法・推論基盤の選び方を実装視点で解説【2026年】：MoEを載せる推論基盤側の全体像
• KVキャッシュとは？LLM推論を高速化する仕組みとメモリ削減・実装判断を実装者向けに解説【2026年版】：重みとは別に要るメモリの見積もり
• Kimi K3とは？Moonshot AIの2.8兆パラメータMoEの性能・料金・K2系からの進化を実装者向けに解説【2026年7月版】：兆パラメータ級MoEの実例
• Qwen3.6-35B-A3Bの仕様詳細とMoE活性パラメータの全体構成：活性パラメータ設計の具体例
• ニューラルネットワークとは？仕組み・種類・学習方法を実装目線で解説：エキスパートの中身であるFFNの基礎