MoE（Mixture of Experts）

MoEとは：全員ではなく「呼ばれた人だけ」が働く

普通のモデル（密なモデル、dense model）は、どのトークンを処理するときも全部の重みを使います。8Bモデルなら、1トークンごとに80億個の重みすべてと掛け算をします。

MoEモデルでは、層の中にエキスパートと呼ばれる小さなFFNがたくさん並んでいて、その前にルーター（router、ゲートとも呼ぶ）が立っています。ルーターは入ってきたトークンを見て「このトークンは3番と17番に任せよう」と決め、選ばれたエキスパートだけが計算します。ほかのエキスパートはそのトークンについては休んでいます。

ただし、このたとえには落とし穴があります。本物の病院のように「数学の専門家」「法律の専門家」がきれいに分かれているわけではありません。これは後の「よくある誤解」で扱います。

ルーターとtop-k：誰を呼ぶかの決め方

ルーターの中身は意外と単純で、トークンのベクトルに小さな行列を掛けて「各エキスパートへの点数」を出すだけです。点数の高い上位k個のエキスパートを選ぶので、これを top-kルーティング と呼びます。

flowchart TD
  T["トークンのベクトル"] --> R["ルーター
各エキスパートに点数"]
  R -->|"上位k個を選ぶ"| E1["エキスパート3"]
  R -->|"上位k個を選ぶ"| E2["エキスパート17"]
  R -.->|"選ばれない"| E3["ほかの多数の
エキスパート"]
  E1 --> M["点数で重み付けして合算"]
  E2 --> M
  M --> N["次の層へ"]

選び直しはトークンごと、層ごとに行われます。同じ文の中でも単語ごとに違うエキスパートが呼ばれ、同じ単語でも1層目と20層目では別のエキスパートが担当します。「質問1つにつき1人の専門家」ではない点に注意してください。

kの値はモデルによって違います。初期の大規模MoE研究（2017年のShazeerらの論文）で現在の形が広まり、Switch Transformer（2021年）はk=1まで減らしても学習できることを示しました。最近のモデルでは、多数の細かいエキスパートから4〜10個程度を選ぶ構成がよく見られます。

総パラメータと有効パラメータ

MoEを理解するいちばんの鍵は、2種類のパラメータ数を区別することです。

モデル名にこの2つが書き込まれていることもあります。Qwen3-30B-A3Bは「総30.5B、有効3.3B」、Qwen3-235B-A22Bは「総235B、有効22B」です。名前の後半の「A3B」「A22B」が有効パラメータを表しています。

注意したいのは、パラメータ数だけで賢さは決まらないことです。MoEの売りは「使う計算量のわりに多くの知識をしまっておける」点ですが、同じ有効パラメータの密なモデルより賢いか、同じ総パラメータの密なモデルにどこまで迫るかは、モデルごとに評価してみないとわかりません（評価の考え方は第30章）。

なぜメモリは全員分必要なのか

病院のたとえでいえば、患者が来るまでどの科が必要かわからないので、全医師に出勤してもらっておく必要がある、ということです。Metaも Llama 4 の発表で、すべてのパラメータはメモリに保持されるが、推論時に活性化されるのはその一部だけ、と説明しています。

具体的な数字で見てみましょう。DeepSeek-V3は総671B・有効37Bです。計算量は37Bの密なモデルに近いのに、重みは671B分あります。4bitに量子化しても単純計算で約335GB（6710億 × 4bit ÷ 8）になり、家庭用GPU1枚には到底載りません。

下のウィジェットで、総パラメータと有効パラメータのそれぞれを入れてみてください。メモリ量を決めるのは総パラメータのほうです。

一方で、速度の面ではMoEに大きな利点があります。トークン生成（デコード）は「重みをメモリから読み出す速さ」が律速になりやすく、MoEでは1トークンごとに読む重みが有効パラメータ分だけで済みます。そのため、メモリにさえ載れば、同じ総サイズの密なモデルよりずっと速く文字が出てきます。

実例で見るMoE

主なMoEモデルの公開値を並べます。数字はいずれもモデルカードや公式発表で確認したものです 2026年10月時点。

「Mixtral 8x7B」という名前から「7B×8=56B」と考えがちですが、実際は46.7Bです。エキスパートになるのはFFN部分だけで、アテンションや埋め込みは全員で共有しているからです。名前の掛け算をそのまま信じないようにしましょう。

傾向としては、エキスパートを「少数・大きめ」から「多数・小さめ」にし、そこから数個を選ぶ方向へ進んでいます。細かく分けたほうが組み合わせの自由度が増え、役割分担が進みやすい、というのがDeepSeekMoE論文などの主張です。

負荷分散と共有エキスパート

MoEを学習させると、ルーターが一部の人気エキスパートばかりを選ぶ「えこひいき」が起きがちです。呼ばれないエキスパートは学習が進まず、ますます呼ばれなくなります。GPUを並べて分担している場合は、人気エキスパートを担当するGPUだけが渋滞します。

そこで 負荷分散（load balancing） の工夫が必要になります。代表的なのは次の2つです。

• 補助損失（auxiliary loss）: 「各エキスパートへの割り当てが均等なほど良い」という罰則項を学習の目的に足す方法。Switch Transformerなどで使われました。均等さを強く求めすぎると本来の性能が落ちるのが悩みどころです。
• 補助損失なしのバランス調整: DeepSeek-V3は、エキスパートごとのバイアス値をルーターの点数に足し、混みすぎたエキスパートは選ばれにくく、空いているエキスパートは選ばれやすくなるよう調整する方式を採用しました。

もうひとつの工夫が 共有エキスパート（shared expert） です。ルーターに関係なく、すべてのトークンが必ず通るエキスパートを1つ置きます。文法のような「誰にでも必要な共通知識」は共有エキスパートに任せ、ルーティング対象のエキスパートは個別の役割に集中しやすくする狙いです。病院でいえば「全員がまず通る総合診療科」です。DeepSeek-V3、Llama 4 Maverick、Qwen3.5などが採用しています。

ローカルで動かすときの勘所

MoEは、ローカル実行の世界でも存在感が大きくなっています。理由は「メモリは大量に必要、でも1トークンの計算は軽い」という性質が、GPUのVRAMは少ないがメインメモリはそこそこある、というパソコンの事情と相性がよいからです。

代表的なテクニックが、エキスパートだけをCPU側のメモリに置く 方法です。アテンションや共有部分のように毎トークン必ず使う重みはGPUに置き、トークンごとに一部しか使わないエキスパートの重みはメインメモリに置いてCPUで計算させます。llama.cpp（第7章）には、このためのオプションがあります。

# まず全部GPUに載せる指定をし、エキスパートだけをCPUへ逃がす例
llama-server -m model.gguf -ngl 99 --cpu-moe

# VRAMに余裕があれば、CPUへ逃がす層を減らしていく
llama-server -m model.gguf -ngl 99 --n-cpu-moe 20

オプション名は llama.cpp の server README で確認したものです 2026年10月時点。変わることがあるので、手元のバージョンで --help を確認してください。

量子化（第10章）との関係も重要です。MoEでは重みの大半がエキスパートなので、エキスパート部分をどれだけ小さくできるかが総メモリをほぼ決めます。gpt-oss はMoEの重みをMXFP4という4bit系の形式で後学習しており、その結果 gpt-oss-120b は80GBのGPU1枚、gpt-oss-20b は16GBのメモリに収まると公式に説明されています。