Mixture of Experts（MoE）とは？仕組みとパラメータ数の正しい読み方

Mixture of Experts（MoE）は、トークンごとの計算を減らせる一方、モデルの運用には依然として膨大な容量が必要になり得ます。Moonshot AIの言語モデルKimi K3.1 Proは、公式の発表投稿によると、総パラメータ数が2.8T、トークンごとに使うアクティブパラメータ数が104Bです。小さい方の数字は計算量を理解する手がかりになります。しかし、重みを保持するための容量を考えるときは、大きい方の数字が効いてきます。

パラメータ数と出典の記述は2026年10月24日に確認しました。以下のアクティブ比率は本記事で算出した値です。速度向上、メモリ削減率、品質スコアの実測値ではありません。

Mixture of Experts（MoE）とは？

Mixture of Experts、略してMoEは、モデル内部に多数の処理ネットワークを持たせ、入力ごとにその一部を選んで使う仕組みです。 パラメータとは、学習によって決まるモデル内の数値を指します。保存されたパラメータは、一般に「重み」と呼ばれます。トークンは入出力を構成する小さな単位で、多くの場合、単語の一部に相当します。

相談室がいくつもある建物を想像してください。受付は、訪問者をその用件に必要な部屋へ案内します。その訪問者のために働く部屋は一部だけですが、建物にはすべての部屋が残っています。MoE層では、ルーターが受付、エキスパートが各部屋に当たります。

ただし、このたとえをそのまま受け取ることはできません。エキスパートの実体は、学習された数値処理のネットワークです。人間の職種のように、法律、コーディング、会計の専門家がそれぞれ待機しているとは限りません。

MoEはどのように動くのでしょうか？

ルーターがモデル内部の処理経路を選び、その先で得られた結果を統合します。 Transformerはトークン間の文脈上の関係を処理します。一般的なMoE型Transformerでは、フィードフォワードブロックを複数のエキスパートネットワークに置き換えます。フィードフォワードブロックは、トークンの内部的な数値表現を変換する部分です。周囲の文脈を参照するためのアテンションとは、別の仕組みです。

処理は次のように進みます。

1. トークンの現在の内部表現がMoE層に届きます。
2. 学習されたルーターが各エキスパートにスコアを付けます。ルーターはゲートとも呼ばれます。
3. エキスパートの一部を選択します。多くの場合はスコア上位を選びます。これがtop-kルーティングで、kは選択する数です。
4. 選ばれたエキスパートがその表現を処理します。各出力を重み付けして統合し、次の処理へ進みます。

この選択はモデル内のMoE層で行われるため、トークンや層によって使われるエキスパートが変わります。重み付きの統合はPyTorchによるアーキテクチャの解説で、層ごとの選択の違いはMistralのモデル論文で説明されています。

スパースMoEとは何ですか？

スパースとは、あるトークンに対してエキスパートの一部だけが動くことです。 現在のモデルカードで総パラメータ数とアクティブパラメータ数を読み比べるときに関係するのは、この形式です。残りのエキスパートは、別のトークンで使われることがあります。同じバッチで処理中のトークンに使われる場合もあります。

デンス型のフィードフォワードブロックは、各トークンに対してネットワーク全体を適用します。スパースなエキスパート層なら、すべてのトークンをすべてのエキスパートに通すことなく、保存しておけるモデル容量を増やせます。ただし、本記事の例におけるアテンションなど、共有部分の計算は引き続き必要です。

MoEモデルも、あくまで一つのモデルです

MoEのルーティングは、APIで呼び出すモデルを選ぶことや、複数のチャットボットに多数決をさせることとは異なります。 ルーターとエキスパートは、一つのネットワークを構成する部品として学習されます。アプリケーションは通常、そのネットワークにリクエストを送ります。製品メニューから選ぶようにエキスパートを指定するわけではありません。

開発者にとって、この区別は設計上の誤解を防ぐうえで大切です。MoEモデルを選んでも、アプリケーションから自在に指揮できる専門エージェントのチームが手に入るわけではありません。

MoEモデルの総パラメータ数とアクティブパラメータ数を読み解く

総パラメータ数は保存するモデルの規模、アクティブパラメータ数は公表されているトークンごとの計算経路の規模として捉えます。 どちらの数字だけでも、必要なハードウェア仕様は決まりません。Bは十億、Tは一兆を表します。

最後の列は、アクティブパラメータ数を総パラメータ数で割り、丸めた値です。開発元が公表した数値の関係を示しているだけで、モデル間の効率ランキングではありません。アーキテクチャも、パラメータをどう数えるかという基準も、モデルによって異なる場合があります。

Kimi K3.1 Pro：巨大なモデルのうち、動くのはごく一部

Kimi K3.1 Proを見ると、運用に必要なモデルサイズを「アクティブ」の数字で代用できない理由が分かります。 Moonshotが示す総パラメータ数を同じ単位にそろえると、2,800Bになります。したがって、丸めると**104 ÷ 2,800 × 100 = 3.7%**です。

これは、公表されているアクティブパラメータ数が全体のごく一部だという意味です。配信環境で残りの重みを捨ててよいという意味でも、APIのレイテンシがデンスモデルの同じ割合に縮むという意味でもありません。処理経路はトークンや層によって変わります。

Moonshotの公開時のブログ記事では、ProをK3に事後学習を施したモデルと説明し、丸めた表現の「3T級」を使っています。一方、公式の発表投稿では2.8T / 104Bと明記されています。モデルの規模を読み取るときは、この具体的な仕様値を使ってください。

APIを使う開発者にとっては、評価候補となるモデルです。自前で運用する担当者にとっては、必要なものが実際に入手できるかが別の判断条件になります。確認日時点で、Moonshotは2026年11月4日までに全重みを公開する予定と述べていました。公開予定があっても、デプロイに使えるファイルがすでにあるとは限りません。このリリース固有の判断材料は、Kimi K3.1 Proの解説で扱っています。

Qwen3-235B-A22B：アクティブ数だけでは総数の代わりになりません

Qwen3-235B-A22Bは、名前そのものにこの区別が表れています。 Qwenのオリジナルのモデルカードには、総パラメータ数235B、アクティブパラメータ数22B、さらにエキスパート数128、そのうちアクティブなエキスパート数8と記載されています。

パラメータ数から計算した比率は、丸めると**22 ÷ 235 × 100 = 9.4%**です。非公開文書を扱うアシスタントを作るなら、この数字はトークンごとの計算量をどう抑えているかの手がかりになります。それでもメモリ設計では、選んだチェックポイント全体と、処理するリクエストの状態を保持できる容量が必要です。

「22Bがアクティブ」を「22Bのデンスモデルと同じ容量に収まる」と読み替えてはいけません。また、数値は必ず対応するチェックポイントとひも付けて扱います。重みファイル、精度、配信設定を選ぶ際に、モデルファミリーの名前だけでは情報が足りません。

Mixtral 8x7B：モデル名を掛け算してはいけない理由

Mixtral 8x7Bには共有部分があるため、名前に含まれる数字をそのまま掛けても総パラメータ数にはなりません。 Mistralの公開時のブログ記事には、総パラメータ数46.7B、トークンごとに使用するパラメータ数12.9Bと記載されています。名前の数字を掛け合わせると、共有部分まで、それぞれ独立した完全なモデルに含まれているかのように数えてしまいます。

Mistralの論文では、各エキスパートのフィードフォワードネットワークと、共有されるアテンションが説明されています。ルーターは各層で、8個のエキスパートから2個を選びます。八つの独立した完全なモデルがあるわけではありません。

公表値を使った計算は、丸めると**12.9 ÷ 46.7 × 100 = 27.6%**です。一方、8個のうち2個を選ぶことは、**エキスパート数の25%**に当たり、分母が異なります。エキスパート数の比率とパラメータ数の比率が一致しない理由の一つが、共有部分の存在です。

デプロイを計画する際は、モデルカードにある総数と、実際のチェックポイントファイルを使って見積もります。製品名や選択されるエキスパート数だけでは、重み全体に必要な容量は分かりません。

計算量が減っても、応答が速くなるとは限らない理由

スパースなルーティングは、同程度の規模のデンスネットワーク全体を動かす場合に比べ、エキスパートの計算量を減らします。ただし、小さなデンスモデルと同じ応答時間を約束するものではありません。 MoEによって、大容量モデルのトークン当たりの配信コストを抑えられるのはこのためです。一方で、メモリや通信に関わる大きな負担は残ります。

学習済みモデルを動かす「推論」において、算術演算は処理の一部にすぎません。サーバーは重みを読み出し、共有部分を実行し、トークンの内部表現を振り分けます。デバイス間でその表現を転送する場合もあります。アクティブパラメータ数が小さくなっても、これらの処理はなくなりません。Shazeerらは、スパースMoEの原論文で、各エキスパートが処理するバッチの小ささとネットワーク帯域幅を、性能上の制約として挙げています。

スループットとレイテンシは、事業上の異なる問いに答える指標です。 スループットは一定時間にサービスが処理できる仕事の量、レイテンシは個々のリクエストの待ち時間です。夜間に文書をまとめて処理するキューなら、大きなバッチを効率よく処理する構成が有利になるかもしれません。対話型のサポートアシスタントでは、最初の役に立つ回答を素早く返す必要があります。

複数のトークンやリクエストをまとめて処理するバッチ処理は、ハードウェアの利用効率を高められます。ただし、トークンごとに異なるエキスパートが選ばれるため、バッチ全体では単一トークンよりもはるかに広い範囲のモデルを使うことがあります。アクティブパラメータ数は、バッチ全体を通じてサーバーがアクセスする重みの数ではありません。

プロンプトの処理とトークンの生成でも、システムにかかる負荷は異なります。Prefillは入力の処理、decodeはそれに続くトークンの生成です。言語モデル配信用ソフトウェアのvLLMでは、スループットを重視するprefillと低レイテンシを重視するdecodeについて、それぞれに対応したエキスパート間通信の選択肢を説明しています。これらの段階と分けて測るべき指標については、LLM推論ガイドで解説しています。

APIを選ぶ際は、自分たちのリクエストを実際に処理させた結果を比較してください。総数とアクティブ数の組み合わせだけでは、プロバイダーがトラフィックをどれほどまとめて処理しているか、キューがどれほど長いか、ハードウェアがモデルに適しているかは分かりません。

実運用で効いてくるMoEのトレードオフ

MoEは、インフラの負担の一部を、繰り返しの計算から大きなモデルの保持と処理の連携へ移します。 運用上の判断は、この交換条件が自分たちのワークロードに合うかどうかです。

メモリ：使わないエキスパートにも置き場所が必要です

そのトークンで使わないことと、配信環境から取り除けることは別です。 通常の、重みをメモリに常駐させる配信では、トークンごとに使うのが一部であっても、重み全体が配信システム内にロードされています。このメモリ要件はPyTorchの解説でも明示されています。

見積もりの出発点になるのは、重みの保存容量 ≈ 総パラメータ数 × 保存される各パラメータのバイト数という式です。ただし、あくまで出発点です。テンソルごとに精度が異なる場合があり、ファイルのメタデータ、パディング、複製、実行時のメモリ割り当ても必要容量に加わります。

メモリ予算に含めるのは重みだけではありません。KVキャッシュは、以前のトークンのアテンションのキーとバリューを保存し、再利用できるようにします。文書アシスタントで会話が長くなったり、同時リクエストが増えたりすれば、リクエストの状態を保持するメモリも追加で必要になります。この別の制約については、KVキャッシュの解説を参照してください。

重みを低い数値精度で保存する量子化は、重みの必要容量を減らせます。しかし、総パラメータ数をアクティブパラメータ数に置き換えるものではなく、出力品質の検証も引き続き必要です。形式や精度の選び方はLLM量子化ガイドで扱っています。仕組みについては、Hugging Faceの量子化の概要に説明があります。

スループット：モデルが載るだけでは十分ではありません

ロードに成功しても、サービスの目標を満たせないモデルはあります。 エキスパート並列化は、エキスパートを複数のデバイスに分散させ、単一デバイスのメモリより大きなモデルを保持できるようにします。その一方で、選ばれたエキスパートを持つデバイスへトークンの内部表現を送り、結果を統合する必要があります。

この転送があるため、デバイス間の接続であるインターコネクトも配信設計の一部になります。接続の弱いマシン群に容量を分散させても、十分な接続性能を持つシステム上の同じ容量と同等には扱えません。これは、PyTorchのエキスパート並列化の実装で説明されている通信パターンから直接導かれる点です。

利用の少ない社内アシスタントでは、確保した容量が十分に使われないままになることが実務上の懸念です。大量の処理を行うバッチサービスでは、エキスパートの計算が途切れないよう、処理対象を供給し続けることが課題になるかもしれません。どちらも、アクティブパラメータ数だけでは決まりません。

ルーティングの偏り：処理が集中するエキスパートがボトルネックになります

学習されたルーターでも、ハードウェアの利用が完全に均等になる保証はありません。 NVIDIAによるMixtralのルーティング分析では、特定の話題にトラフィックが集中すると、エキスパート間で負荷が偏る場合があると分かりました。早く処理を終えるワーカーがある一方で、動き続けるワーカーが残ります。

だからこそ、主に契約書やコードを処理するサービスを、さまざまな話題を混ぜたデモ用ワークロードだけで評価するのは不十分です。平均値だけに頼らず、遅いリクエストも含めて、実際に想定される話題の集中を評価してください。

配信ソフトウェアで偏りを補うことはできますが、その対策にも容量が必要です。vLLMは、エキスパートの複製を使った負荷分散を説明し、追加のコピーが、本来ならKVキャッシュに使えたGPUメモリを消費すると注意しています。モデルの重みがメモリにぴったり収まる構成では、良好な配信に必要な設定を組む余地が足りないことがあります。

MoEのLLMを選ぶ：API利用とセルフホスティングの判断基準

APIを使う開発者は提供されるサービスを評価し、自前で運用する担当者は配信環境全体も評価する必要があります。 どちらにも要求を満たす出力は必要ですが、エキスパートをどこに配置するかを直接管理するのは後者です。

APIを使って開発する場合、アーキテクチャは参考情報にはなりますが、それ自体が切り替えの理由にはなりません。代表的なタスク、指示への追従、必要に応じたツール利用、想定される同時実行数での最初のトークンまでの時間と完了時間を評価します。失敗した試行やリトライも記録してください。プロバイダー側の配信効率だけで、請求額や、満足できる結果を得るまでに必要な仕事量が決まるわけではありません。

セルフホスティングで運用する場合、まず実際にダウンロードできるチェックポイント、そのライセンス、対応する配信実装を確認します。そのうえで、重みの精度、モデル全体のメモリ容量、キャッシュ用の余裕、デバイス間接続、負荷をかけたときの性能を評価します。オープンウェイトモデルのガイドでは、ファイルを入手できることと、運用に伴う権利や責任を分けて説明しています。

サービス水準への責任を負って選定する場合、計画中のインフラで、要件を満たす処理を目標応答時間内に完了できるかを確認してください。「総数は兆単位、アクティブは十億単位」はアーキテクチャの説明であり、サービス水準の保証ではありません。

1. 1

   モデルを比べる前にワークロードを定義する

   合格基準を明確にした、代表的なリクエストを使います。対話型の処理とキューに入れて処理する仕事を分け、実際のアプリケーションで扱う長い入力や、特定の話題への集中も含めてください。

2. 2

   実際に使う提供経路で評価する

   APIなら、利用予定のプロバイダーとエンドポイントをテストします。セルフホスティングなら、使用するチェックポイント、精度、ランタイム、ハードウェアを正確に記録します。提供経路が変われば、運用結果も変わります。

3. 3

   処理能力と品質を同時に確かめる

   同時に処理する仕事を増やしながら、メモリ使用量、待ち時間、出力品質、失敗を確認します。単発の応答が速くても、実用的なスループットが得られるとは限りません。スループットが高くても、対話に十分な低レイテンシとは限りません。

4. 4

   実際の仕事で改善が確認できたら切り替える

   要件を満たして完了できる仕事と、運用要件の両方が改善したときに候補を採用します。改善が見られなければ、現在のモデルを維持します。必要な重みファイルや、対応するデプロイ方法がまだ利用できない場合は、セルフホスティングを待ってください。

現在のAPIが品質と応答時間の要件を満たしている開発者にとって、アーキテクチャの呼び名だけで判断を変える必要はありません。一方、アクティブパラメータ数を基に配信環境の容量を決めた運用担当者は、その計画を今すぐ見直すべきです。

MoEでは、どんな期待が過大評価なのでしょうか？

過大な主張は、スパース化すれば巨大モデルの利点をすべて得られ、しかも小さなモデルと同じ条件で運用できる、というものです。 MoEはモデル容量と計算量を切り離す有用な仕組みですが、そこには条件があります。

エキスパートが分野別の専門家になる保証はありません。 MistralによるMixtralの分析では、ルーティングのパターンが学問分野ごとに明確に分かれているわけではないと分かりました。学習されたエキスパートは、資格を持つ専門家ではありません。また、ルーターがどれを選んだかは、回答が正しい理由の説明にもなりません。

総パラメータ数が多いだけでは、回答の質が高いとは言えません。 アクティブ比率が小さいだけでも、優れたモデルの証明にはなりません。学習、アーキテクチャ、タスクのすべてが関わります。上の表は公表されている規模を説明するためのものであり、品質ランキングではありません。

アクティブ比率が小さくても、料金や処理時間が同じ割合で下がるとは限りません。 その比率だけでは、プロバイダーの料金、キューでの待ち時間、ネットワーク転送、タスクに必要な生成トークン数は何も分かりません。

MoEの仕組みを理解するための原論文

Shazeerらの2017年の論文は、計算量を比例して増やすことなくモデル容量を拡大する、影響力の大きなスパースゲート型MoE層を定式化しました。 この仕組みの一次資料が、Outrageously Large Neural Networks: The Sparsely-Gated Mixture-of-Experts Layerです。負荷分散と分散処理の性能に関する議論からは、運用上のトレードオフが当初からこの考え方に含まれていたことも分かります。

MoEについて開発者が知りたいこと

LLMにおけるMoEとは何ですか？

モデル内部に複数のエキスパートネットワークと、学習されたルーターを持たせる、大規模言語モデルの構成方法です。スパースMoEでは、各トークンは各MoE層で選ばれたエキスパートだけを使います。アプリケーションが呼び出すのは、あくまで一つのモデルです。

GPT-4はMoEモデルですか？

GPT-4の技術報告書では、モデルサイズを含む詳細なアーキテクチャ情報は非公開とされています。開発元が確認したMoEのパラメータ内訳は示されていないため、うわさの数値をデプロイの前提として使うべきではありません。

MoEモデルのファインチューニングでは何に注意しますか？

ファインチューニングは、学習済みモデルの振る舞いを調整するものです。重み全体を保持するための運用要件がなくなるわけではありません。調整後のモデルについて、代表的なトラフィックを使い、タスクの品質とルーティングの挙動を評価してください。Hugging FaceのMoEガイドでは、関連する過学習や負荷の均衡に関する固有の注意点を説明しています。

次のモデル選定で、まず記録しておくこと

月曜日に、候補モデルごとの配信メモを作成してください。 開発元が示す総パラメータ数とアクティブパラメータ数、その出典、使用するチェックポイントまたはAPIエンドポイントを正確に記録します。ホスティングされたサービスを使うなら、自分たちのタスクでの結果とレイテンシの測定値を加えます。セルフホスティングなら、重み全体の必要容量、キャッシュの割り当て、想定トラフィックでの性能も加えてください。宣伝で最も大きく見える数字を比べるよりも、そのメモの方が選定に役立ちます。

AIプロダクトを支えるインフラの実践的な解説は、ニュースレターに登録してお読みください。