3行でいうと
- MoEは、層の中の一部（専門家）だけを、トークンごとに選んで動かします。計算量は「動いた分」に比例しますが、メモリは「全部の専門家を置く分」が必要です。Metaも、全パラメータはメモリに置かれ、動くのは一部だけ、と書いています。
- 公式の数字は、Mixtralが総47B・活性13B、DeepSeek-V3が総671B・活性37B、Llama 4 Scoutが総109B・活性17B、Maverickが総400B・活性17Bです。僕らの計算では、活性は総数の4〜28%です。
- 「専門家」は、分野ごとの担当者ではないようです。Mixtralの論文は、分野の違いで選ばれる専門家に明確な差は見えず、文の構文に沿った傾向がある、と報告しています。
この記事は、実際に使って確かめた記録ではありません。この記事は、公式の文書と論文を読んでまとめたもので、実際に使って確かめた記録ではありません。情報は2026年10月16日に確認しました。変わることがあります。
先に結論
- MoEで軽くなるのは、1トークンを作るときの計算です。重みを置く場所（メモリ）は、総パラメータに近い量が要ります。Hugging Faceの解説も、Mixtralを動かすには密な約47Bのモデル相当のVRAMが必要、と書いています。
- 速さの利点は、条件つきです。Mixtralの論文は、低いバッチサイズでは速く、高いバッチサイズでは処理量（スループット）が高い、ただしルーティングの負担と、複数の専門家を動かす際のメモリ読み込みがあるので、バッチ処理に向く、と書いています。
- 「安い」のは、学習の側でも書かれています。Switch Transformersの論文は、T5-Baseとの比較で、最大7倍の事前学習の速さを報告しています（本文では、T5-Largeとの比較は2.5倍です）。ただし、これは2021年のT5系との比較です。
仕組み：密なモデルとの違い
ふつうのTransformerは、各層のフィードフォワード部分（FFN）を、すべてのトークンが通ります。これを密（dense）なモデルと呼びます。
MoEは、そのFFNを「専門家」と呼ばれる複数のFFNに置き換え、小さなルーターがトークンごとに、使う専門家を選びます。Mixtralは、各層に専門家が8つあり、ルーターが1トークンにつき2つを選びます（各層で、トークンごと）。選ばれる組は、次のトークンで変わりえます。
ここで大事なのが、置き換わるのはFFNだけ、という点です。注意の部分（アテンション）などは共有されます。Hugging Faceの解説は、このためMixtral 8x7Bの総数が、7B×8=56Bではなく47Bになる、と説明しています。
「総パラメータ」は、全部の専門家を数えた総数です。「活性パラメータ」は、1トークンの処理で実際に使う数です。
| モデル | 総パラメータ | 活性パラメータ | 活性の割合（僕らの計算） | 専門家の構成（公式の記載） |
|---|---|---|---|---|
| Mixtral 8x7B | 47B | 13B | 約28% | 各層8つ、2つを選ぶ |
| DeepSeek-V3 | 671B | 37B | 約5.5% | DeepSeekMoE（構成の細部は未読） |
| Llama 4 Scout | 109B | 17B | 約16% | 16の専門家 |
| Llama 4 Maverick | 400B | 17B | 約4.3% | ルーティング128＋共有1。トークンは共有1つと、選ばれた1つへ |
Llama 4の記事は2025年4月5日の公開、Mixtralの論文は2024年1月、DeepSeek-V3は2024年12月です。新しいモデルの情報は読んでいません。
「安い・速い」の根拠は、どこにあるのか
Mixtralの論文は、活性パラメータの数が推論の計算コストに比例すると書いています。そのうえで、この数字は、メモリのコストとハードウェアの使われ方を考えていない、とも断っています。
学習の側では、Switch Transformersが、入力ごとに別のパラメータを選ぶことで、計算コストを一定に保ったまま、1兆パラメータまで拡大できたと報告しています。1兆パラメータのモデルは、T5-XXLに比べて4倍の速さで事前学習できたとされています。DeepSeek-V3の報告書は、14.8兆トークンでの事前学習を含む訓練全体に、278.8万H800 GPU時間を要したと書いています。
つまり、計算を節約できる根拠は、公式の資料にあります。ただし、節約できるのは計算で、メモリではありません。
メモリの落とし穴
全部を置く必要がある
どの専門家が選ばれるかは、トークンが来るまで分かりません。そのため、全部の専門家をメモリに置く必要があります。Hugging Faceの解説は、総パラメータ数が同じ密なモデルより推論は速いが、メモリ要件は高いと書き、スループットが高く複数マシンを使える環境では疎なMoEが向き、スループットが低くVRAMが限られる環境では密なモデルが向く、と整理しています。
僕らの概算で、重みだけを置くのに必要な量を計算しました。1パラメータを2バイト（BF16）、4ビット量子化なら0.5バイトとし、KVキャッシュや計算の途中の置き場は含めません。
| モデル | BF16（2バイト） | 4ビット（0.5バイト） | 比較：活性と同じ大きさの密なモデル（BF16） |
|---|---|---|---|
| Mixtral 8x7B（47B） | 約94GB | 約23.5GB | 13Bなら約26GB |
| Llama 4 Scout（109B） | 約218GB | 約54.5GB | 17Bなら約34GB |
| DeepSeek-V3（671B） | 約1.3TB | 約335GB | 37Bなら約74GB |
Mixtralのモデルカードは、約47B、BF16で配布されていると書き、メモリ量は書かず、半精度と4ビットでの読み込み例を示しています。MetaはScoutを、Int4量子化でH100 1枚に収まると書いています。これは、僕らの計算（109B×0.5バイト≒54.5GB）とも矛盾しません。
バッチが大きくなると、読む量も増えるはず
ここからは僕らの見立てです。公式が数字で示しているわけではありません。
1トークンだけを作るなら、読み込む専門家は、選ばれた一部で済みます。ところが、同時に複数のリクエストを処理すると、それぞれが別の専門家を選ぶので、触れる専門家の数が増えます。仮に、8つの専門家から2つずつ、均等に独立に選ばれるとすると、少なくとも1つのトークンに選ばれる専門家の割合は、僕らの計算で次のとおりです。
| 同時のトークン数 | 触れられる専門家の割合 |
|---|---|
| 1 | 25% |
| 2 | 約44% |
| 4 | 約68% |
| 8 | 90% |
| 16 | 約99% |
実際の選ばれ方は均等でも独立でもありません。Mixtralの論文は、連続するトークンで同じ専門家が選ばれる割合が、ランダムな場合（12.5%）より高い層があると報告しています（層15のArXivで27.9%など）。だから、この表は目安です。ただし方向としては、バッチが大きいほど、動く量が総パラメータに近づき、メモリの読み込み（メモリ帯域）が重くなるはずです。Mixtralの論文が、バッチ処理に向くと書いているのは、こうした事情と整合しますが、論文はこの計算を示していません。
複数のGPUに置く：専門家並列
専門家を別のGPUに分けて置く方法を、専門家並列（EP）と言います。vLLMの文書によると、--enable-expert-parallelで有効にし、EPのサイズは、テンソル並列とデータ並列の積になります。単一ノード8GPUの例は、--tensor-parallel-size 1 --data-parallel-size 8 --enable-expert-parallelと書かれています。この記事は、実際に使って確かめた記録ではありません。
Mixtralの論文は、専門家並列では負荷分散が重要で、偏ると一部のGPUが過負荷になり、全体の遅れになる、と述べています。vLLMには、負荷を均すEPLBがあり、そのために冗長な専門家をGPUメモリに置きます。文書は、メモリが限られる環境には向かず、KVキャッシュに回せる余地が減ると警告し、DeepSeek-V3では冗長な専門家1つが約2.4GBかかると書いています。大規模な利用では、冗長専門家の数を32にするよう勧めています（既定は0）。
つまり、MoEは、メモリを増やして、負荷を均す工夫まで必要になる設計です。
学習の側の難しさ
Hugging Faceの解説と、各論文によると、次の点が挙げられています。
- 偏り: ルーターが一部の専門家ばかり選ぶと、その専門家だけ学習が進み、さらに選ばれる悪循環になります。補助的な損失で均す方法があります。DeepSeek-V3は、補助損失を使わない負荷分散の方法を導入したと書いています。
- 容量: 1つの専門家が処理できるトークン数に上限があり、あふれたトークンは次の層へそのまま流れるか、捨てられます。
- 不安定さ: Hugging Faceの解説は、ルーターを完全精度で計算するなどの工夫で、学習を安定させると書いています。
- 微調整: 解説は、MoEは過学習しやすいと書いています。
Mixtral 8x7Bの公式の数字と、論文の観察
構成（論文の表1）: 次元4096、層数32、ヘッド数32、KVヘッド数8、文脈長32768、語彙32000、専門家8、選ぶ数2。ゲートはSoftmax(TopK(x・Wg))です。
GShardとの違い: 論文は、全層のFFNをMoE層にしている点を挙げています。GShardは1層おきです。
専門家は分野の担当ではなさそう: ArXiv、PubMed、PhilPapersで、専門家の選ばれ方の分布はよく似ていました。論文は、ルーターが分野より構文に沿って選んでいるようだと述べ、Pythonの「self」が同じ専門家に行く例、コードのインデントが一貫して同じ専門家に行く例を挙げています。
連続トークンの偏り: 第1選択の専門家が連続で同じになる割合は、ランダムなら12.5%ですが、層15と31ではそれより高くなります。第1か第2選択のどちらかが同じになる割合は、DM Mathematicsの層15で67.0%、ランダムなら約46%です。著者は、この局所性が、専門家並列では過負荷を招きうる一方、キャッシュに活かせるかもしれない、と書いています。
性能の主張: 論文は、基本モデルがLlama 2 70BとGPT-3.5に並ぶか上回ると書いています。ライセンスはApache 2.0です。この主張は論文の自己評価で、この記事では検証していません。
気をつけること
- この記事は、実際に使って確かめた記録ではありません。メモリの表と、触れられる専門家の割合の表は、僕らの概算です。重みだけの量で、KVキャッシュ、途中の計算の置き場、実装の余分は含みません。実際に必要な量は、もっと多くなります。
- 割合の表は、均等かつ独立に選ばれるという仮定を置いた計算です。実際は違うと論文が報告しています。
- Mixtralの活性パラメータは、論文が13B、Hugging Faceの解説が約12Bと書いていて、数字が違います。なぜ違うかは、読んだ範囲で確認できていません。この記事では論文の13Bを使いました。
- OpenAI、Anthropic、Googleの主力モデルがMoEかどうかは、公式資料で確認できていません。この記事は、公開されている論文とモデルの資料に限っています。
- DeepSeekMoEの構成の細部（専門家の数、共有専門家など）は、要旨ページしか読んでいないので、書いていません。
- 論文と公式のページは、WebFetchという取得の仕組みを通して読んでおり、これは要約を返します。数字の細部が欠けたり、混じったりする可能性があります。使う前に原文で確認してください。文章は引用せず、言い換えています。
- 「軽くなるのは計算で、メモリではない」という整理と、バッチが大きいほど読む量が増えるはずという説明は、公式の資料を読んだ僕らの理解で、すべてを論文が明示しているわけではありません。
- モデルの大きさの表記（8x7Bなど）は、総数とは違うことがあります。モデルを選ぶときは、総パラメータ、活性パラメータ、配布時の精度を、それぞれ確認してください。
出典
- Mixtral of Experts（arXiv、Jiang et al.、10月16日確認）
- Switch Transformers: Scaling to Trillion Parameter Models with Simple and Efficient Sparsity（arXiv、Fedus et al.、10月16日確認）
- DeepSeek-V3 Technical Report（arXiv、DeepSeek-AI、10月16日確認）
- The Llama 4 herd（Meta AI、10月16日確認。公開は2025年4月5日）
- Mixture of Experts Explained（Hugging Face、10月16日確認。公開は2023年12月11日）
- Expert Parallel Deployment（vLLM docs、10月16日確認）
- Mixtral-8x7B-v0.1 モデルカード（Mistral AI、Hugging Face、10月16日確認）
更新履歴
- 2026年10月25日 書き方を直しました。
- 前：運営者が使っていないと読める書き方 → いま：「この記事は、実際に使って確かめた記録ではありません」。公式の資料を読んでまとめた記事で、使い心地は書いていない、という意味に直した