Mixture-of-Experts の設計トレードオフ：疎活性化が運用にもたらす複雑性

大規模言語モデルの規模競争が続くなかで、総パラメータ数を増やしながら推論あたりの計算量を抑える設計として Mixture-of-Experts（MoE）が広く採用されるようになった。だが「安く大きくできる」という要約は、この方式が抱える運用上の負担を覆い隠している。本稿では、疎活性化がもたらす利点を認めたうえで、その利点がどのような別のコストと引き換えに得られるのかを、設計と運用の両面から検討する。

疎活性化は計算を減らすが、メモリは減らさない

MoE の基本的な発想は単純である。層の内部に複数の「エキスパート」（多くは順伝播ネットワーク）を並べ、入力トークンごとにルーターがそのうち少数だけを選んで活性化する。総パラメータ数が数千億に達しても、実際に計算に関与するのは一部にとどまるため、推論あたりの浮動小数点演算量は密なモデルより小さくなる。この構造は、Shazeer らが2017年に提示した疎ゲート型 MoE の考え方を、Transformer の層構成に組み込んだものと位置づけられる。

ここで見落とされやすいのは、計算量とメモリ占有量が別々に振る舞う点である。推論時に活性化されるエキスパートは少数でも、どのトークンがどのエキスパートを呼ぶかは事前に分からない。したがって、全エキスパートのパラメータを高速にアクセス可能な場所に常駐させておく必要がある。結果として、MoE は「計算は疎、メモリは密」という非対称な資源特性を持つ。GPU メモリの制約が支配的な環境では、この非対称性が想定より早く上限に達する要因になる。

ルーティングの偏りという構造的な問題

MoE の品質を左右する中心的な要素はルーターである。理想的には各エキスパートに負荷が均等に分散してほしいが、学習の初期に一部のエキスパートへトークンが集中すると、そのエキスパートだけが速く成長し、さらに多くのトークンを引き寄せるという正のフィードバックが生じる。この「勝者総取り」の傾向は、放置すると多くのエキスパートが実質的に未使用になる崩壊を招く。

この問題への対処として、補助的な負荷分散損失を加えてルーティングを均等化する手法が用いられる。Switch Transformer に関する研究（Fedus ら、2021年）は、エキスパートを一つだけ選ぶ簡素なルーティングでも、負荷分散の工夫と組み合わせれば大規模化が可能であることを示した。ただし、負荷分散損失は本来の学習目標とは別方向に勾配を引く。もっとも、この補助損失を強くしすぎると、ルーターが内容ではなく均等配分を優先しはじめ、専門化という MoE 本来の利点が薄れる。均衡点の調整は、公開された数式だけからは決まらない経験的な作業になりやすい。

本番運用で顕在化するレイテンシの分散

密なモデルであれば、あるバッチの推論時間はおおむね一定に見積もれる。MoE ではそうはいかない。トークンごとに呼び出すエキスパートが異なるため、複数の GPU にエキスパートを分散配置している場合、トークンの流れに応じてデバイス間通信の量が変動する。特定のエキスパートに負荷が偏ったバッチでは、そのデバイスがボトルネックになり、末尾のレイテンシ（テールレイテンシ）が跳ね上がる。

この挙動は、平均レイテンシだけを見ていると捉えられない。対話型のアプリケーションでは、平均が良好でも上位数パーセントの応答が極端に遅ければ、体感品質は損なわれる。推論の配置をオンデバイスとクラウドで分ける判断と同様に、MoE の運用でもテール分布を前提にした容量設計が求められる。一方で、バッチ内のトークンをエキスパート単位で再編成する最適化は実装が複雑で、フレームワークの成熟度に大きく依存するのが現状である。

密なモデルとの選択は規模だけで決まらない

MoE が常に有利というわけではない。総パラメータ数に対する品質の伸びは、学習データ量やタスクの性質に強く依存する。狭い領域に特化した用途では、同じ推論コストなら適切に設計された密なモデルのほうが扱いやすい場合がある。実際、小規模な特化型モデルが汎用の大規模モデルを上回る領域が広がりつつある事実は、パラメータ数の最大化が唯一の方向ではないことを示している。

とはいえ、汎用性と規模の両立が求められる基盤モデルの文脈では、MoE の資源効率は依然として魅力的である。判断の分かれ目は、期待するトラフィックのパターン、許容できるテールレイテンシ、そして運用チームが分散配置の複雑性をどこまで引き受けられるかにある。これらはモデルの理論性能とは別の、運用側の制約である。

結論：効率は移動するのであって消えるわけではない

MoE は推論あたりの計算量という一点では確かに効率的だが、その効率はメモリ常駐コスト、ルーティング調整の難しさ、レイテンシの分散という別の場所に負担を移すことで成り立っている。設計上の交換条件を理解せずに「大きくて安いモデル」として導入すると、本番でテールレイテンシとメモリ上限という形で想定外のコストに直面する。効率は消えるのではなく移動する——この視点を持つことが、MoE を現実の制約のなかで使いこなす前提になる。基盤モデルの内部構造がアプリケーションの挙動に直結する点は、長コンテキスト処理のスケーリングにも共通する論点である。