Mixture of Experts（MoE）とルーティングの内部

なぜ「Mixture of Experts」なのか

スケーリング則 が示すとおり、モデルの性能は概ねパラメータ数とデータ量に従って伸びます。しかし密（dense）なモデルでパラメータを増やすと、1トークンを処理する計算量も比例して増え、学習も推論も重くなります。容量と計算コストが密結合しているのが密モデルの宿命です。

Mixture of Experts（MoE） は、この結びつきをほどく仕組みです。発想は単純で、巨大な順伝播層（FFN）を 多数の小さな「エキスパート」に分割し、各トークンに対しては そのうち少数だけを起動します。総パラメータは膨大でも、1トークンが実際に通る経路は一部だけ――この**疎な活性化（sparse activation）**が MoE の心臓です。

疎な活性化：容量と計算量を切り離す

密な FFN では、全トークンが同じ巨大な重み行列を通ります。MoE では FFN を E 個のエキスパート（それぞれが独立した小さな FFN）に分け、各トークンは ルーター（gating network） が選んだ k 個だけを通ります。典型的には k は 1 か 2 です。

密な FFN:   x ──▶ [巨大な FFN] ──▶ y     （全パラメータが毎回働く）

MoE FFN:    x ──▶ [ルーター] ──▶ Top-k 個のエキスパートだけ起動
                                   ├─▶ Expert_3 ─┐
                                   └─▶ Expert_7 ─┴─▶ 加重和 ──▶ y

ここで「総パラメータ」と「活性パラメータ」を区別するのが決定的です。

• 総パラメータ: 全エキスパートを足し合わせた量。モデルの**容量（記憶・表現力）**を決める。
• 活性パラメータ: 1トークンが実際に通る量。**計算コスト（FLOPs）**を決める。

エキスパートを E=64 個用意し k=2 だけ起動するなら、総パラメータは密モデルの数十倍でも、1トークンの計算量はおよそ2エキスパート分に留まります。これが「パラメータを増やしても計算量を増やさない」と言われる正体です。

Top-k ゲーティング：ルーターはどう選ぶか

ルーターの実体は小さな線形層1枚です。入力トークンのベクトル x を受け取り、各エキスパートへのスコア（ロジット）を出します。

logits = x · W_router          # W_router は [隠れ次元 × エキスパート数 E]
gate    = softmax(logits)       # E 個のエキスパートへの重み（合計1）

このうちスコア上位 k 個だけを選び、その重みで各エキスパートの出力を加重和します。k 個に絞るのが Top-k ゲーティングです。

ステップ:
  1. logits = x · W_router        # E 個のスコア
  2. top_idx = argtopk(logits, k) # 上位 k 個のエキスパート番号
  3. w = softmax(logits[top_idx]) # 選ばれた k 個だけで正規化
  4. y = Σ_{i in top_idx} w_i · Expert_i(x)   # 加重和

ここで本質的な難しさがあります。「上位 k 個を選ぶ」という argtopk は微分不可能な離散操作です。ではなぜルーターが学習できるのか。答えは、選ばれたエキスパートに掛かる重み w を経由して勾配が流れるからです。あるエキスパートの出力が損失を下げる方向に効けば、その w を大きくするよう（＝そのトークンに対するロジットを上げるよう）W_router が更新されます。選択そのものは離散だが、選択後の連続的な重み付けが学習信号になる――この設計が MoE を訓練可能にしています。

負荷分散：放置すると一部のエキスパートに偏る

MoE には固有の病があります。学習初期にたまたま良く選ばれたエキスパートはさらに更新が進んで賢くなり、ますます選ばれる――という自己強化のループで、ルーターが一部のエキスパートばかり使うようになるのです。これを ルーティングの崩壊（routing collapse） と呼びます。

崩壊すると、多くのエキスパートが事実上未使用になり容量を無駄にします。さらに、人気エキスパートにトークンが殺到すると後述の容量を超えてあふれ、計算の偏りで分散学習の効率も落ちます。

これを防ぐのが 負荷分散損失（load balancing loss / auxiliary loss） です。本来の言語モデル損失（交差エントロピー）に、エキスパート利用の偏りを罰する補助項を足します。直感的には次の量を小さくします。

aux_loss = E × Σ_i ( f_i × P_i )

  f_i : エキスパート i に実際に振り分けられたトークンの割合
  P_i : エキスパート i へのルーター確率（gate）の平均
  E   : エキスパート総数（スケール合わせの係数）

f_i × P_i の総和は、全エキスパートに均等（各 1/E）のとき最小になります。特定のエキスパートに f と P が集中するほどこの積の和が大きくなり、損失が増えます。つまりこの補助項は「みんなを均等に使え」という圧力をルーターに掛けます。本損失との重み付けは小さめの係数で調整し、強すぎると品質を損ない、弱すぎると崩壊を許す、という綱引きになります。

容量係数とトークンの drop

負荷分散損失は「平均的に」均すものの、個々のバッチでは依然として割り当てに偏りが出ます。分散学習では各エキスパートを別デバイスに置くため、1エキスパートが処理できるトークン数に固定の上限を設けて実装します。この上限を決めるのが 容量係数（capacity factor） です。

エキスパート容量 = capacity_factor × (バッチのトークン数 / エキスパート数 E)

capacity_factor が 1.0 なら「均等配分ぴったり」で余裕ゼロ、1.25 なら各エキスパートに25%の余裕を持たせる、という意味です。問題は容量を超えたトークンの扱いです。

• drop（あふれ落とし）: 容量を超えたトークンはそのエキスパートでは処理されず、FFN をスキップして残差接続だけで次へ流れる。計算は守れるが、そのトークンはエキスパート処理を受け損ねる。
• 容量係数を上げる: drop を減らせるが、確保メモリと計算が増え、未使用の容量も生まれる。

drop は品質低下に直結しうるため、負荷分散損失でそもそも偏らせないのが本筋で、容量係数は安全弁という位置づけです。推論時はバッチ構成が学習時と変わるため drop の挙動も変わり、ここがサービング設計の注意点になります。

推論コストとモデル容量のトレードオフ

MoE の利点と弱点は表裏一体です。容量（総パラメータ）と計算量（活性パラメータ）を分離できるのが利点ですが、その分離が新しいコストを生みます。

最大の現実問題は メモリです。1トークンが通るのは k 個でも、どのエキスパートが選ばれるか事前に分からないため、推論時は全エキスパートをメモリに常駐させておく必要があります。つまり、

• 計算（FLOPs）は活性パラメータ基準で軽い。
• メモリ占有は総パラメータ基準で重い。

という非対称が生じます。KV キャッシュと推論最適化 で見た Decode がメモリ帯域律速だったのと同じ問題圏で、MoE はさらにエキスパート重みの読み出しと、トークンを正しいデバイスへ運ぶ通信が乗ります。

まとめ：MoE は「容量」と「計算」を分けて設計する道具

MoE を一言でいえば、容量と計算量を独立に動かせるようにする構造です。密モデルでは一蓮托生だった2つを切り離し、「計算は据え置きで容量だけ伸ばす」設計を可能にします。

この見立てがあると、「総パラメータは巨大なのに推論が速い」「でも GPU メモリは大量に要る」「学習でエキスパートが遊んでいる」といった MoE 特有の現象が、疎活性化・負荷分散・容量の言葉で説明できます。LLM と Transformer の FFN を「分割して一部だけ使う」と置き換えるだけで、最新の巨大モデルがなぜ安く動くのかが線でつながります。