MoE（Mixture of Experts）とは？仕組みや主要モデル、選び方を徹底解説

MoE（Mixture of Experts、混合エキスパート）とは、Transformerの各層を「複数の小さな専門家サブネットワーク」に分割し、入力ごとに一部だけを活性化することで、同じ計算量のまま総パラメータを何倍にも拡張できるアーキテクチャです。
2024年のDeepSeekMoE論文と2025年のGPT-OSS公開を経て、2026年時点で大規模・フロンティア級のオープンLLMではMoE採用が急速に進んでいます（一方でQwen3・Gemma 4のようにDenseと併存させるファミリーも同時に公開されています）。

本記事では、MoEの定義と基本アーキテクチャ、Mixtral 8x7BからDeepSeekMoE・Auxiliary-Loss-Free Load Balancingまでの進化史、DeepSeek V4・Kimi K2・Qwen3・GPT-OSS・Mixtral・Mistral Large 3の主要モデル比較、推論効率とスケーラビリティのメリット、メモリ帯域幅や推論時負荷分散といったMoE特有の課題、企業がMoEモデルを選ぶ際の判断軸までを、2026年7月時点の最新情報で体系的に解説します。

MoE（Mixture of Experts）とは？LLMのFFN層をスパース化する仕組み

MoE（Mixture of Experts、混合エキスパート）とは、Transformerの各層のフィードフォワードネットワーク（FFN）を、複数の小さな「エキスパート」サブネットワークに分割し、入力トークンごとに一部だけを活性化させて計算するアーキテクチャです。

数学的には、単一の大きなFFNを N 個の並列FFNに分解し、ルーター（ゲーティングネットワーク）が各トークンについて上位 K 個だけを選ぶ「条件付き計算」の枠組みとして定義されます。

2026年7月現在、MoEは大規模言語モデル（LLM）の実験的な選択肢ではなく、大規模・フロンティア級のオープンモデルにおいて主要な設計選択肢の1つとして定着しつつあります。

一方でQwen3やGemma 4のようにDenseファミリーも並行して公開されており、「フロンティア級はMoE、小型・特化用途はDense」という使い分けの構図が生まれています。

---

MoEの基本アーキテクチャ——エキスパート・ルーター・スパース活性化

MoEの構造は「エキスパート」「ゲーティングネットワーク（ルーター）」「スパース活性化」という3つの要素で説明できます。

下図はDeepSeek-V3を例に、Transformer 1ブロック内でFFNがDeepSeekMoE（Routed Expert + Shared Expert + Router）に置き換えられ、Attention側はMulti-Head Latent Attention（MLA）でKVキャッシュを圧縮する構造を示しています。

RouterがInput Hiddenベクトルから Top-K_r 個のエキスパートを選択し、Shared Expert（緑色）は全トークンが必ず通過する固定経路になっている点が読み取れます。

DeepSeek-V3のTransformerブロックにおけるDeepSeekMoE（右上・Routed Expert + Shared Expert + Router + Top-K_r）とMulti-Head Latent Attention（右下）の詳細（出典：DeepSeek-V3 Technical Report）

本セクションでは、TransformerブロックのどこにMoEが組み込まれ、各要素がどう機能するのかを整理します。

エキスパート（Expert）——FFNを分割した専門家サブネットワーク

エキスパートは、Transformer層のFFN（フィードフォワードネットワーク）を N 個の並列した小型FFNに分割したもので、それぞれが独立した重みを持ちます。

各エキスパートは基本的に同じ構造（入力次元→中間次元→出力次元）ですが、訓練を通じて異なる入力パターンに対して異なる応答を出すように自己組織化的に専門化していきます。

DeepSeekMoE論文以降のトレンドは、より小さいエキスパートをより多く並べる、いわゆる「Fine-grained（細粒化）」設計です。
たとえばDeepSeek V3は256個のrouted expertを各MoE層に配置し、各エキスパートの中間次元は2048に抑えています。

エキスパートが小さく多数あることで、トークンごとの担当領域が細かく切り分けられ、Denseに近い柔軟性を維持できます。

ゲーティングネットワーク（ルーター）——どのエキスパートに送るかを決める門番

ゲーティングネットワークは、各入力トークンに対して「N 個のエキスパートのうち、どの上位 K 個に処理を任せるか」を決める小さなニューラルネットワークです。

一般的な実装では、次の3ステップで動作します。

• アフィニティスコアの計算
  トークンの隠れ表現と、各エキスパートに割り当てられた重心ベクトル（centroid）との内積を計算する。DeepSeek V3ではsigmoid関数、Mixtralではsoftmaxが使われる。
  
  

• Top-K選択
  アフィニティスコアの高い順に上位 K 個のエキスパートを選ぶ。DeepSeek V3・Kimi K2は K=8、GPT-OSSは K=4、Mixtral 8x7Bは K=2。
  
  

• ゲーティング値の付与
  選ばれた K 個のエキスパートに対して、正規化された重みを掛けて出力を加重合成する。

ルーターは訓練を通じて「どのトークンがどのエキスパートに向いているか」を学習しますが、この学習が失敗するとルーターが特定のエキスパートに集中してトークンを送る「routing collapse」が発生します。後述するAuxiliary-Loss-Free Load Balancingは、この失敗を防ぐための重要な仕組みです。

スパース活性化——1トークンあたり数%のパラメータしか動かない

スパース活性化とは、モデル全体では巨大なパラメータを持ちながら、1トークンの推論ではそのごく一部だけしか使わない設計を指します。

具体的な比率を代表例で比較すると、DeepSeek V3は671Bのうち37B（約5.5%）、Kimi K2は1.04Tのうち32B（約3.1%）、GPT-OSS 120bは117Bのうち5.1B（約4.4%）しかトークンあたり計算しません。

このスパース性が推論コストを直接押し下げる原理で、同じスループットのGPU上で、Denseなら不可能な規模のモデルが動くようになります。

一方で「モデル全体のパラメータはGPUメモリに載せておく必要がある」ため、メモリ消費量そのものは減りません。
この非対称性（計算量は減る／メモリは減らない）が、後述する推論コスト面の利点と課題を同時に生み出しています。

DenseモデルとMoEモデルの計算量とメモリの違い

以下の表で、DenseモデルとMoEモデルの「計算量」「メモリ」「実効パラメータ」の違いを整理しました。

観点	Denseモデル	MoEモデル
総パラメータ	すべて計算に関与	総パラメータの一部（Active）のみ計算
1トークンの計算量	総パラメータに比例	Activeパラメータに比例
GPUメモリ要件	総パラメータ分	総パラメータ分（Active分ではない）
訓練コスト	総パラメータに線形	Total ≒ Active FLOPSで圧縮可能
推論単価	総パラメータに比例	Activeパラメータに比例

この表が示すのは、MoEのコスト構造は「モデル選定時に見るべき指標をTotalからActiveに切り替える」ことを要求するという点です。1TのMoEモデルは、Activeが32BならAPI単価としては32B相当のDenseと近い水準になります。

---

MoEの進化史——Mixtral 8x7BからDeepSeekMoE・Auxiliary-Loss-Freeまで

MoE自体は1991年のJacobsらの「Adaptive Mixtures of Local Experts」まで遡れる古典的な発想ですが、現在のLLMに直結するトレンドは、2023年末のMixtral 8x7Bを起点として、2024〜2026年に3つの世代を経て進化してきました。

本セクションでは、その3世代を時系列で整理します。

Mixtral 8x7B（2023年12月）——少数の大エキスパート型でMoEを実用モデルに

MoEをオープンLLMの主流に持ち込んだのは、Mistral AIが2023年12月に発表したMixtral 8x7Bです。

• 総パラメータ: 46.7B
• Activeパラメータ: 12.9B（1トークンあたり）
• エキスパート数: 8個（全てrouted、shared expertなし）
• Top-K: 2
• ライセンス: Apache 2.0

Mistral公式が発表したブログでは「decoder-onlyモデルで、feedforwardブロックが8つの異なるパラメータグループから選ぶ」と説明しており、Llama 2 70Bを上回りながら6倍高速な推論を実現したと報告されています。

Mixtralの意義は「MoEが研究段階を出て、Apache 2.0でオープンに使える実用モデルになった」ことでした。ただし設計としては少数（8個）の大きいエキスパートから2個を選ぶタイプで、専門化の粒度が粗いという課題が残っていました。

Mixtral 8x7B（オレンジ）が推論予算13B相当の位置で、Llama 2 70Bと同等〜上回る品質を6タスク（MMLU/Knowledge/Reasoning/Comprehension/Math/Code）で達成することを示す（出典：Mistral AI）

グラフでは横軸が推論予算（Active parameters相当のB数）、縦軸が各タスクのスコア。Mixtral 8x7Bは12.9B相当の推論コストで、70BのDense LLaMA 2に匹敵ないし上回る品質を出しています。

特にMath・Codeでは差が大きく、Mixtral 51.1% vs LLaMA 2 41.7%、Mixtral 50.6% vs LLaMA 2 39.5% と、10ポイント前後の優位が出ています。

「同じ推論コストで、Denseの数倍のTotal容量にアクセスできる」というMoEのコスト効率を、Mistralが最初に実証した図といえます。

DeepSeekMoE（2024年1月）——Fine-grained + Shared Expertで専門化を極める

2024年1月に公開されたDeepSeekMoE論文（arxiv 2401.06066）は、Mixtral型のMoEに対して2つの構造的革新を提示しました。

• Fine-grained Expert Segmentation
  N 個のエキスパートを mN 個に細分化し、活性化数も K から mK に増やす設計。エキスパート1個あたりのパラメータを小さくし、より柔軟な組み合わせを可能にする。同じ計算量で \binom{N}{K} から \binom{mN}{mK} に組み合わせ数が指数的に増える。
  
  

• Shared Expert Isolation
  全トークンが常に通過する「共有エキスパート」を K_s 個分離する。共通知識を共有エキスパートに集約することで、routed expert側は本当に専門化すべき知識だけを担当できるようになる。
  
  

下図の3段構造では、(a)は従来型（N個のエキスパートから K=2 を選ぶMixtral型）、(b)はFine-grained（2N個に細分化して K=4 を選ぶ）、(c)はShared Expert Isolation（緑色の1個が全トークン共通・残りはFine-grainedで K=3 を選ぶ）と、進化の3段階が視覚化されています。

エキスパート数が同じ計算予算のまま増え、Shared Expert が汎用知識を分離することで、Routed Expert 側が真の専門化に集中できるというのがDeepSeekMoEの中心思想です。

DeepSeekMoE Figure 2：従来型MoE（左）から Fine-grained（中）へ、さらに Shared Expert Isolation（右・DeepSeekMoE）へと段階的に構造を進化させた比較図（出典：DeepSeekMoE論文）

DeepSeek論文の実験では、2Bパラメータのモデルで、1.5倍パラメータを持つ2.9Bモデルと同等の性能を達成しています。
「エキスパートの数と使い方を変えるだけで、モデルの実効性能が上がる」という結果は、以降のMoE設計の方向性を決めました。

また、Kimi K2（384 routed + 1 shared）、Qwen3-235B-A22B（128 experts）、GPT-OSS-120b（128 experts）といった2025〜2026年の大規模MoEモデルは、いずれもエキスパートを細かく分割するFine-grained側に寄っています。Mixtral型の「少数の大エキスパート」は大規模MoEの主流から外れ、Fine-grained型が大規模MoEの主流になりました。

Auxiliary-Loss-Free Load Balancing（2024年8月）——ロス項を使わない負荷分散

MoEの訓練で常に付きまとうのが「エキスパート間の負荷不均衡」問題です。ルーターが特定のエキスパートに偏ってトークンを送るようになると、他のエキスパートは訓練が進まず、モデル全体の実効容量が縮小します。

従来のMoEでは「Auxiliary Loss（補助損失）」と呼ばれる追加のロス項をつけて、ルーターに均等分配を強制していました。ただし補助損失が強すぎると本来の言語モデリングのロスに干渉し、モデル性能が劣化するというトレードオフがありました。

2024年8月に公開されたWang et al.のAuxiliary-Loss-Free Load Balancing論文（arxiv 2408.15664）は、このトレードオフを回避する新しい仕組みを提案しました。

• エキスパートごとに学習可能なバイアス項 b_i を導入
  アフィニティスコア s_i に b_i を加えた値でTop-K選択を行うが、ゲーティング値（実際にFFN出力に掛ける重み）は元の s_i から計算する。
  
  

• バイアスは訓練ステップごとに動的更新
  過負荷のエキスパートは b_i を γ だけ減らし、負荷不足のエキスパートは γ だけ増やす。DeepSeek V3では γ=0.001 を最初の14.3Tトークンに使用し、残り500Bトークンでは γ=0 に切り替えている。
  
  

• 勾配経由の干渉ゼロ
  バイアス更新はロス計算の外側で行われるため、言語モデリングのロス勾配を歪めない。

DeepSeek V3のablation実験では、Aux-Loss-Free方式は補助損失方式よりも各種ベンチマークで一貫して優れた性能を示しました。

バランスを取りながらも本来のロスに干渉しないというシンプルな設計は、DeepSeek V3の重要イノベーションとして定着しています。

---

主要MoEモデルのスペック比較（DeepSeek V3・Kimi K2・Qwen3・GPT-OSS・Mixtral）

2026年7月時点で商用利用可能な主要オープンMoEモデルを、公式ドキュメントベースのスペックで横並びに整理します。

読み解きのポイントは「TotalではなくActiveパラメータで実効コストを測ること」と「エキスパート数とTop-Kの比率で設計思想を把握すること」の2点です。

主要MoEモデルの構成一覧

以下の表で、代表的な主要MoEモデルのスペックを整理しました。

モデル	Totalパラメータ	Active/token	エキスパート構成	Top-K	ライセンス	出典
DeepSeek V4-Pro	1.6T	49B	Fine-grained + Shared系（V3系譜）	非公表	MIT	DeepSeek API Docs
DeepSeek V4-Flash	284B	13B	Fine-grained + Shared系	非公表	MIT	同上
DeepSeek V3（deepseek-chat/reasonerは2026-07-24廃止予定）	671B	37B	256 routed + 1 shared	8	Model License	arxiv 2412.19437
Kimi K2	1.04T	32B	384 routed + 1 shared	8	Modified MIT	arxiv 2507.20534
Qwen3-235B-A22B	235B	22B	128 experts	8	Apache 2.0	Qwen公式ブログ
Qwen3-30B-A3B	30B	3B	128 experts	8	Apache 2.0	同上
GPT-OSS 120b	117B	5.1B	128 experts	4	Apache 2.0	OpenAI公式
GPT-OSS 20b	21B	3.6B	32 experts	4	Apache 2.0	同上
Mistral Large 3	675B	41B	granular MoE	非公表	Apache 2.0	Mistral Docs
GLM-5.2	744B	40B	Fine-grained + Shared系	非公表	MIT	Hugging Face GLM-5.2
Mixtral 8x7B	46.7B	12.9B	8 experts	2	Apache 2.0	Mistral公式

この表から読み取れるのは、エキスパート数の設計思想が大きく2系統に分かれているという点です。Fine-grained系（DeepSeek 256 / Kimi 384 / Qwen 128）は多くの小さいエキスパートで専門化の粒度を上げる方向、少数系（Mixtral 8）はエキスパート数を抑えて実装をシンプルに保つ方向です。

2026年時点のフロンティア級はほぼFine-grained系に集約されました。

一例として、DeepSeek V4はProとFlashの2階層で提供され、いずれも1Mコンテキストと33T tokens級の事前訓練で共通しています。

DeepSeek-V4-Pro（1.6T total / 49B active / 33T tokens / 1M context）と V4-Flash（284B / 13B / 32T / 1M context）の公式スペック比較（出典：DeepSeek API Docs）

Proの49B activeはKimi K2の32B activeより重く、Flashの13B activeはMixtral 8x7B（12.9B active）と近い帯域です。APIとオープンソース公開の両方に対応し、Web/APPモードでもExpert Mode / Instant Modeとして使い分けられます。

Activeパラメータで見た実効コスト帯

TotalパラメータではなくActiveパラメータで見ると、実効的な推論コスト帯は次の3つに分かれます。

• 超小型帯（3〜5B active）
  GPT-OSS 20b（3.6B）、Qwen3-30B-A3B（3B）、GPT-OSS 120b（5.1B）。
  
  

• 中型帯（12〜22B active）
  DeepSeek V4-Flash（13B）、Mixtral 8x7B（12.9B）、Qwen3-235B-A22B（22B）。中規模GPU 1台〜数台で運用可能。
  
  

• 大型帯（32〜49B active）
  DeepSeek V4-Pro（49B active、1.6T total）、Mistral Large 3（41B active、675B total）、GLM-5.2（40B active、744B total）、DeepSeek V3（37B active、671B total）、Kimi K2（32B active、1.04T total）。大規模GPUクラスタが必要だが、Total容量は圧倒的に大きい。

ここで気をつけたいのが、Activeパラメータが軽い＝低スペックGPUで動く、ではないという点です。
自前ホスト時に必要なHBMはTotalパラメータで決まるため、同じ超小型帯でもGPT-OSS 20bは16GBメモリで動作可能（エッジデバイス向き）ですが、GPT-OSS 120bは80GBメモリ相当（H100 1台〜）が要ります（OpenAI公式）。

TotalとActiveで順位が入れ替わる点もMoE時代の特徴です。
Totalで見ればDeepSeek V4-Pro 1.6T > Kimi K2 1.04T > GLM-5.2 744B > Mistral Large 3 675Bの順ですが、Activeで見るとKimi K2 32B < GLM-5.2 40B < Mistral Large 3 41B < DeepSeek V4-Pro 49Bと順位が逆転します。

API単価もActiveパラメータの帯域にほぼ連動します。DeepSeek V4-FlashのAPI単価はGPT-5.5・Claude Opus 4.8/4.7クラスの1/10〜1/30という水準で、Total 284B・Active 13BのMoEモデルとしては破格です。

2026年7月時点のDeepSeek公式pricingによれば、V4-ProはInput cache miss $0.435・Output $0.87、V4-FlashはInput cache miss $0.14・Output $0.28です。

V4-ProはFlashのcache miss / outputで約3.1倍、cache hitで約1.3倍の単価にとどまり、フロンティア級Denseモデル（Claude Opus 4.8/4.7 / GPT-5.5）と比べればProでも依然として桁違いに安い水準です。

特にキャッシュヒット時の $0.0028〜$0.003625 という単価は、繰り返しコンテキストを使うRAGやエージェント運用で効いてきます。

なお、V3系列の旧モデル名（deepseek-chat / deepseek-reasoner）は2026年7月24日 15:59 UTCに廃止され、以降はV4-Flashのnon-thinking / thinkingモードに互換ルーティングされます。V4-Proは別モデル名（deepseek-v4-pro）で並行提供です。

補助モジュール——DeepSeek系はMLA、GPT-OSSはGQAで攻める

Fine-grained MoEと並行して、Attention側の効率化も進化しました。

DeepSeek V3・Kimi K2はいずれも**Multi-head Latent Attention（MLA）**を採用しています。DeepSeek V4系はさらに新機構「Token-wise compression + DSA（DeepSeek Sparse Attention）」に移行しました。

MLAはKVキャッシュを潜在空間に圧縮する仕組みで、長文コンテキストでのメモリ消費を大幅に削減します。DeepSeek V3ではKV compression dimension d_c=512、query compression dimension d_c'=1536という具体値が公表されています。

一方で、OpenAI GPT-OSSはgrouped multi-query attention（GQA、グループサイズ8）を採用し、Alternating dense and locally banded sparse attentionと組み合わせています。MLAではなくGQA側で効率化するアプローチです。

Qwen3もGrouped Query Attention（GQA）を採用しています（235BでQ64/KV4）。ライセンス公開状況もモデルごとに異なります。

MoE単体では計算量を減らせてもメモリは減りませんが、MoE + MLAの組み合わせにより「計算量もKVメモリも両方減らせる」設計が可能になります。

Fine-grained MoE + Aux-Loss-Free + MLA の組み合わせはDeepSeek V3で採用・検証されました。

その後DeepSeek V4系はToken-wise compression + DSA（DeepSeek Sparse Attention）など別系統のアップグレードに移行しています。Kimi K2はFine-grained + Shared + MLAを採用しています（負荷分散方式は公開情報が限定的）。

Attention側の選択もモデルごとにGQA・DSA・MLAと分岐しており、「唯一の標準構成」は未確立です。

---

MoEのメリット——推論効率・訓練コスト・スケーラビリティ

MoEが2026年のLLM設計における第一選択になった理由は、単に「新しい構造だから」ではなく、Denseモデルでは実現できなかったコスト構造の書き換えをもたらしたためです。

本セクションでは、MoEがDenseに対して優位性を持つ3つの側面を整理します。

推論効率——同じスループットで数倍の総容量

MoEの推論効率は、「同じGPUのFLOPS予算内で、Denseなら不可能な総パラメータ規模を動かせる」ことに集約されます。

たとえば1トークン13B活性化のDeepSeek V4-FlashのFLOPS計算量は、Dense 13Bモデルとほぼ同じです。しかしV4-Flashはその計算量で284Bの知識容量にアクセスでき、V4-Proに至っては49B activeで1.6Tの総容量を持ちます。同じ推論スループットで、Denseなら不可能な規模のモデルが動く計算になります。

DeepSeek V4シリーズのAPI単価がGPT-5.5クラスと比べて桁違いに安いのは、この推論効率が直接反映された結果です。

DeepSeek V4-Flashの入力単価は100万トークンあたり $0.14（キャッシュヒット時 $0.0028）、出力単価は $0.28。V4-Proは入力 $0.435（キャッシュヒット時 $0.003625）、出力 $0.87という水準で、フロンティア級Denseモデルの2桁下です（2026年7月時点・DeepSeek公式pricing より）。

DeepSeek-V4-Pro / V4-Flash が V3.2（灰破線）比で長文コンテキストの単token計算量と累計KVキャッシュを大幅に削減している（出典：DeepSeek API Docs）

グラフの左パネル（単token計算量）では、Token位置が1024Kに達してもV4-Flashは0.1TFLOPs前後を維持しているのに対し、V3.2は1.2TFLOPsまで直線的に増加します。

右パネル（累計KVキャッシュサイズ）では、V4系が5GB前後で頭打ちなのに対し、V3.2は50GBまで膨張しています。**Token-wise compression + DSA（DeepSeek Sparse Attention）**の効果で、長文コンテキストでも計算量とメモリ消費がほぼ横ばいに抑えられているのが読み取れます。

訓練コスト——同じGPU時間で総容量を数倍化

訓練コストの面でも、MoEはDenseに対して明確な優位性を持ちます。

DeepSeek V3は671Bという規模ながら、フル訓練で 2.788M H800 GPU時間しか要していません（うちpre-trainingは2.664M、後続のPost-training / RLHF段階が約0.1M）。

単純なActive/Total比からは、Dense同規模モデルでは十数倍規模の計算量になると見積もられます。フロンティア級モデルの訓練を「大手ハイパースケーラー以外にも現実的にする」効果があります。

• エキスパート並列（Expert Parallelism）
  各GPUに異なるエキスパートを配置し、通信は「トークンをエキスパートのある場所に送る」All-to-Allのみで済む。DeepSeek V3では64GPU×8ノード=512GPUにrouted expertを均等配置。
  
  

• Auxiliary-Loss-Freeによる訓練の安定化
  バイアス項による負荷分散でルーティング崩壊を防ぎつつ、本来の言語モデリングロスに干渉しない。DeepSeek V3は「訓練プロセス全体で復旧不能なロススパイクなし」と報告。
  
  

• FP8等の低精度訓練との相性
  MoEはエキスパート単位で並列化しやすく、FP8での訓練最適化が効きやすい。DeepSeek V3はFP8混合精度訓練を全面採用。

これらの工夫により、フロンティア級モデルの訓練コストが桁で下がったことで、DeepSeek・Moonshot AI・Alibaba・Zhipu AIといった非ハイパースケーラー系のプレイヤーが競争力を持てるようになりました。オープンLLM市場が2024〜2026年に急速に活性化した背景の1つはここにあります。

スケーラビリティ——モデル容量と推論コストの分離

Denseスケーリングでは「モデル容量」と「推論コスト」が線形にリンクしていました。パラメータを2倍にすれば単価も2倍になる、という制約です。

MoEはこの関係を分離します。エキスパートを増やしていけば総容量は無限に近く拡張できる一方、Top-Kを固定しておけば1トークンあたりの計算量は変わりません。

• 多言語・多ドメインの一体モデル化
  異なる言語・ドメインの知識を、それぞれ別のエキスパートに担当させることで、単一のモデルに詰め込める。Qwen3は119言語対応で36兆トークン訓練。
  
  

• 専門知識と汎用能力の共存
  Shared expertが汎用知識を、routed expertが専門知識を担当することで、汎用性と専門性の両立が可能になる。
  
  

• 将来の拡張余地
  エキスパートを追加してモデル容量を拡張しつつ、推論コストはActiveパラメータ帯に抑えられる。DeepSeek V4-ProはV3の37B activeからActive 49B・Total 1.6Tへ拡張し、Flash側はTotal 284B・Active 13Bの軽量帯を提供する二層構成に進化した。

この分離の意味は、フロンティア級モデルのコスト構造を書き換える点にあります。「大きくすると単価が上がる」というDenseの制約から解放されたことで、モデル提供者は「単価を下げながら容量を増やす」という戦略が取れるようになりました。

---

MoEの課題——メモリ帯域幅・推論時の負荷分散・Multi-deviceデプロイ

MoEはメリットが大きい一方で、Denseにはなかった固有の課題も抱えています。特に「訓練での均衡」ではなく「推論での運用」に絡む問題が、企業導入時に無視できない論点になります。

本セクションでは、MoE特有の課題を3つに整理します。

メモリ帯域幅ボトルネック——計算は減ってもメモリは残る

MoEの根本的なジレンマは、推論FLOPSはActiveパラメータに比例して減るが、GPUメモリにはTotalパラメータ全てを載せておく必要がある点です。

DeepSeek V4-Proを運用するには、1.6Tのパラメータ全てをGPUメモリに載せる必要があります。FP8換算で約1.6TB相当のGPU HBMが目安で、公開されるInstruct版はFP4 + FP8混合精度のケースがあるため、実必要HBMは量子化・実装で変動します。

H100（80GB）を20台以上のクラスタが最低ラインで、Kimi K2（1.04T）でも1TB相当が要ります。これは決してエッジフレンドリーな構成ではありません。

推論性能を律速するのは、計算量よりもメモリ帯域幅です。エキスパートごとの重みをHBMからSRAMに転送するI/Oが支配的になり、GPU間の通信（InfiniBand、NVLink）でも同様のボトルネックが発生します。

DeepSeek V3ではNVLink（160 GB/s）とInfiniBand（50 GB/s）を明示的に使い分ける通信最適化が公表されており、MoEの推論性能はメモリ帯域幅とネットワーク帯域幅を含めて設計しないと出ないことがわかります。

推論時の負荷分散——大バッチで疑似Dense化が起きる

訓練時にAux-Loss-Freeでバランスを取ったモデルでも、推論時は状況が変わります。

大バッチで推論すると、多数のトークンが同時にルーティングされるため、結果としてほぼ全エキスパートが同時に活性化する状態が起こりえます。この状態では、MoEのスパース性による計算削減効果が消え、実質的にDenseに近い計算量になってしまいます。

• 小バッチ推論
  1トークンあたり K 個のエキスパートしか使わないため、スパース性のメリットが最大化する。ただしGPU利用率は下がる。
  
  

• 大バッチ推論
  複数トークンが多様なエキスパートに散らばり、結果的にほぼ全エキスパートが活性化する「疑似Dense化」が発生。理論通りのコスト削減が得られない。

推論時の負荷不均衡は、単一トークン基準で見ると発生していなくても、バッチ集約後にはエキスパートごとのトークン数がばらつきます。少数の過負荷エキスパートが処理の最遅箇所（クリティカルパス）になり、全体スループットを引き下げます。

DeepSeek V3では、デコーディング時にshared expertを「常に選ばれるheavy-load expert」として扱う運用や、冗長エキスパートを別GPUに複製する仕組みで負荷不均衡に対処しています。ただしこれらは自前ホストで運用する場合の実装コストとして発生する要素で、API利用ならプロバイダ側が吸収してくれる領域です。

Multi-deviceデプロイの複雑さ——通信オーバーヘッドと実装難度

MoEの推論はほぼ確実にMulti-GPU・Multi-nodeのデプロイになるため、通信オーバーヘッドと実装難度がDenseと桁違いに増します。

DeepSeek V3の公式レポートでは、Multi-device運用の実装として cross-node all-to-all communication kernelをカスタム実装していること、各トークンを最大4ノードまでに制限してIB帯域を節約していること、decoding時は40ノード×320GPUを最小デプロイ単位とすることなどが公表されています。

これは「大手クラウド並みのインフラを自前で組めるチーム」でなければ再現困難な運用です。

• 通信オーバーヘッド
  All-to-All通信がボトルネックになりやすい。GPU間の帯域幅と遅延が支配的。
  
  

• エキスパート配置の最適化
  どのGPUにどのエキスパートを載せるか（EP: Expert Parallelism）と、tensor parallelism・pipeline parallelismとの組合せ設計が必要。
  
  

• 障害復旧の複雑化
  1つのエキスパートを持つGPUが落ちると、そのエキスパートを呼び出すトークンの推論が全体に影響。冗長構成の設計が要る。

この難度の高さから、企業側の実務判断としては「MoEモデルはAPIで使う」が第一選択になります。DeepSeek、Kimi、Moonshot、OpenAIなどが提供するAPIエンドポイントを使えば、Multi-deviceの複雑さはプロバイダ側に任せられます。

自前ホストが妥当なのは、社内で高スループット推論が継続的に必要で、かつインフラチームが最低20〜40 GPUを運用できる規模がある場合に限られます。

---

主要MoEモデル選定の判断軸——用途・導入形態・エコシステム成熟度

MoEモデルは選択肢が急増しているため、「どれが最強か」ではなく「自社の用途と運用体制に合うか」で選ぶ必要があります。

本セクションでは、AI総合研究所の支援現場で使っているMoEモデル選定の3つの判断軸を提示します。

用途で選ぶ——コーディング／推論／エージェント／汎用

MoEモデルは同じMoE構造でも、後訓練の方針で得意分野が大きく分かれます。

以下の表で、主要なMoEモデルの用途別の相性を整理しました。

用途	第一候補	補足
コーディング支援	Kimi K2、Qwen3-Coder、DeepSeek V4系	Kimi K2はagentic/coding性能に振り込んだMoEモデルで、Agent Swarm構造はK2.5で導入されK2.6で300 sub-agents / 4,000 stepsに拡張された流れ。Qwen3-Coderはagentic coding / tool use向けに公開・訓練されたバリアント
推論モデルとしての利用	DeepSeek V4-Pro（Thinkingモード）、GPT-OSS 120b、GLM-5.2	DeepSeek V4-ProはThinking/Non-Thinkingの両モード対応でMath/STEM/Codingで開放型SOTA。GPT-OSS 120bはo4-mini並とOpenAI自身が公表
エージェント運用	Kimi K2、Qwen3-235B-A22B	長時間のツール呼び出しループとJSON出力の安定性で優位
汎用チャット	DeepSeek V3系、Qwen3-235B-A22B、GLM-5	多言語・多ドメイン対応の広さで有利
エッジデプロイ	GPT-OSS 20b、Qwen3-30B-A3B、Gemma 4	GPT-OSS 20bは16GBメモリ級で動作（OpenAI公式）、Gemma 4 E2B/E4Bはモバイル・エッジ向き。Qwen3-30B-A3BやGemma 4 26Bクラスは量子化・実装により必要VRAMが変わる

この表から言えるのは、用途とActiveパラメータの帯域を先に決めてからモデルを選ぶという順序が有効だという点です。GPT-OSS 20bをコーディング用途に使おうとしてもKimi K2の代替にはならず、逆に汎用チャット目的でKimi K2をエッジに載せようとしてもインフラが破綻します。

導入形態で選ぶ——API・自前ホスト・BYO Cloud

MoEモデルの導入形態は、大きく3つに分かれます。それぞれに向くケースが明確に異なるので、自社の要件に合わせて選びます。

• API利用（第一候補）
  DeepSeek Platform・Moonshot API・Alibaba Cloud DashScope・OpenRouterなどから、モデルプロバイダーが運用するAPIを呼び出す。単価はActiveパラメータ相当に近く、Multi-device運用の複雑さをプロバイダ側が吸収してくれる。
  
  

• 自前ホスト（vLLM / SGLang）
  vLLMやSGLangを使って社内GPUクラスタで動かす。データレジデンシー要件や高スループット継続利用のケースに向くが、最低数十GPUのインフラ運用が必要。
  
  

• BYO Cloud（Bedrock / Vertex AI / Azure Foundry）
  AWSのAmazon Bedrock、Google CloudのVertex AI、MicrosoftのFoundryで提供されるMoEモデルを利用する。自社のクラウド契約内でデータを完結させたい企業向け。ただしすべてのMoEモデルが全クラウドで提供されているわけではない点は注意。

実務的な導線として、まずAPIでPoC → 継続利用が確定したらBYO Cloud → 特殊要件があれば自前ホストという三段階の進み方が失敗しにくい流れです。いきなり自前ホストで検証を始めると、モデル選定と運用設計を同時にやることになって身動きが取れなくなるパターンが頻発します。

エコシステム成熟度で選ぶ——ツール・ライブラリ・SLA

同じ性能のMoEモデルでも、周辺エコシステム（推論フレームワーク・ライブラリ対応・SLA）の成熟度で運用のしやすさが大きく変わります。

• 推論フレームワーク対応
  vLLM・SGLang・TensorRT-LLM・Ollama・llama.cpp等への対応状況。主要フレームワークで対応が進んでいるが、公式サポート範囲はモデル・フレームワークごとに異なる（例：Kimi K2はvLLM / SGLang / KTransformersを公式推奨、GPT-OSSはvLLM / Ollama / llama.cpp / LM Studio等の公式パートナー配備あり）。導入前に対象モデル×対象エンジンの組合せを個別確認するのが安全。
  
  

• 量子化サポート
  INT4・INT8・FP8のプリセット提供状況。Kimi K2ファミリー（K2 Thinking等）ではINT4量子化前提の訓練が採用されている、と一部のバリアントで公表されている。
  
  

• エージェント／ツール呼び出しの安定性
  JSON出力・function calling・structured outputsの実装成熟度。GPT-OSSはOpenAIのharmony chat schemaを標準採用しており、既存のOpenAI APIエコシステムから乗り換えやすい。
  
  

• 商用SLA
  公式APIの稼働率保証、レスポンスタイム、レートリミット。フロンティア級プロバイダ（Anthropic・OpenAI）と比べると、DeepSeek/Kimi/Alibabaは可用性面でまだ追いつく余地がある。

この観点で言えば、エンタープライズ本格運用ならBYO Cloud（Bedrock・Vertex AI・Azure Foundry）経由でMoEモデルを使うのが最も安全です。プロバイダ側のSLA・データ管理・監査ログがクラウドの標準サービスとして提供されるため、社内のITガバナンス要件と整合させやすくなります。

TotalではなくActiveで見るのが最大の落とし穴

AI総合研究所が企業のMoE導入を支援している中でよく出会うのが、「1TのMoEモデルを動かすのに何GPU要りますか？」という質問です。

この問いに対しては、1Tを動かすには全パラメータをGPUメモリに載せる必要があるが、単価はActiveパラメータで測るという2軸に分けて答えるのが実務的です。

• Kimi K2（Total 1T、Active 32B）はFP8換算でGPU HBM約1TB、DeepSeek V4-Pro（Total 1.6T、Active 49B）は約1.6TBが目安（Total基準・量子化と実装で変動）
• 一方、API単価はActiveパラメータ相当（DeepSeek V4-Flashの $0.14〜$0.28 / 1Mトークンと近い水準）
• 自前ホストなら「TotalでGPU予算」、API利用なら「Activeで単価予算」で見積もる

この二軸を分けて考えないと、モデル選定時に「単価が安いからKimi K2を自前で動かそう」→「FP8換算で1TB相当のHBMが必要でGPU予算が桁違い」というシナリオが起きます。TotalとActiveの読み方は、MoE時代の企業導入で最初に押さえるべき論点です。

---

MoEモデルを業務エージェント基盤に統合する

MoEモデルの登場でLLMの単価が桁違いに下がった結果、企業側のAI活用は「単発のチャット呼び出し」から「業務プロセス全体を動かすエージェント基盤」へと重心が移りつつあります。

DeepSeek V3系・Kimi K2・GPT-OSSといったMoEモデルを業務に組み込むうえで実務的な論点になるのは、モデル選定そのものよりも、業務ワークフローとの接続・権限統制・実行ログ管理といった周辺設計です。

AI総合研究所では、こうしたMoE時代のエージェント基盤を、モデル選定から社内展開までを一貫して設計する「AI Agent Hub」を提供しています。DeepSeekやKimi K2のような高性能かつ低単価なMoEモデルを、業務に安全に定着させたい企業は次のCTAからLPの詳細をご確認ください。

---

まとめ

本記事では、MoE（Mixture of Experts）について、定義と基本アーキテクチャ、Mixtral 8x7BからDeepSeekMoE・Auxiliary-Loss-Freeまでの進化史、主要MoEモデルのスペック比較、メリットと課題、企業がMoEモデルを選ぶ判断軸まで、2026年7月時点の最新情報で解説しました。要点を改めて整理します。

• MoEは同じアクティブ計算量で総パラメータを5〜30倍に拡張できる仕組みで、TransformerのFFN層を複数のエキスパートに分割し、ルーターがトークンごとに上位K個だけを選ぶスパース活性化で成立している
  
  

• 進化史は3世代——Mixtral 8x7Bの少数の大エキスパート型（2023）→ DeepSeekMoEのFine-grained + Shared Expert型（2024）→ Auxiliary-Loss-Free Load Balancingによる負荷分散（2024〜）。Kimi K2・Qwen3・GPT-OSSといった後続の大規模MoEもFine-grained側の設計に寄っている（Aux-Loss-FreeやMLA併用はモデルごとに公表状況が異なる）
  
  

• 主要モデルはActiveパラメータで実効コストを測る——DeepSeek V4-Pro（49B active）、Mistral Large 3（41B active）、GLM-5.2（40B active）、DeepSeek V4-Flash（13B active）、Kimi K2（32B active）、Qwen3-235B-A22B（22B）、GPT-OSS 120b（5.1B）、Mixtral 8x7B（12.9B）。TotalとActiveで順位が入れ替わることが多い
  
  

• メリットは推論効率・訓練コスト・スケーラビリティの3軸。フロンティア級モデルの単価がDense比で1/10〜1/30に下がり、非ハイパースケーラー系プレイヤーの競争力が上がった
  
  

• 課題はメモリ帯域幅・推論時の疑似Dense化・Multi-deviceデプロイ。自前ホストは実装コストが桁違いになるため、API利用（第一候補）→ BYO Cloud（第二候補）→ 自前ホスト（特殊要件のみ）の順で検討するのが安全
  
  

• 選び方は用途・導入形態・エコシステム成熟度の3軸で見る——コーディングならKimi K2/Qwen3-Coder、推論ならDeepSeek V4-Pro（Thinking）/GPT-OSS 120b、エッジならGPT-OSS 20b/Qwen3-30B-A3B。計算量・API単価はActive、GPUメモリ・自前ホスト予算はTotalの二軸で予算を分けて見積もることがMoE時代の最重要ポイント

MoEはもはや「新しい実験的アーキテクチャ」ではなく、大規模・フロンティア級オープンLLMの主要な選択肢として2026年時点で定着しました（一方でQwen3やGemma 4のようにDenseファミリーも同時公開されているため、単純に「全てMoEに移行した」わけではありません）。
企業側のAI活用が「単価が高いフロンティアモデルを高単価で使う」から「MoEで単価を下げて業務プロセス全体に組み込む」に移行するタイミングは、まさに今です。

DeepSeek V4やKimi K2のようなMoEモデルを検討する際は、モデルスペックだけでなく、業務ワークフローとの統合まで含めて設計することが、実務的な次の一歩になります。