MoE(Mixture of Experts)とは｜総パラメータと活性パラメータの違いを実務目線で

「総パラメータ数千億なのに、1トークンあたりの活性パラメータは数十億だけ」。近年の大規模モデルのスペック表で、こうした二つのパラメータ数を並べた表記を見かける機会が増えました。DeepSeekやKimi、GLMといったオープンウェイトの大型モデルの多くが採用しているMoE(Mixture of Experts、混合エキスパート)というアーキテクチャがその背景にあります。名前は聞くけれど、総パラメータと活性パラメータのどちらでモデルの重さを見ればいいのか、ローカルで動かせるのか、といったところが曖昧なままの方も多いはずです。この記事では、MoEを従来のdense(密)モデルとの違いから整理し、スペック表の読み方とモデル選定での勘所を、実務で判断できる粒度でまとめます。

dense(密)モデルとの違い#

まず土台として、標準的なTransformerの構造を思い出します。各層はおおまかに、トークン同士の関係を見るattention(自己注意)と、その後段でトークンごとに変換をかけるFFN(フィードフォワードネットワーク)から成ります。通常のdenseモデルでは、このFFNは一枚の大きなネットワークで、どのトークンが来ても必ず全体を通します。パラメータが増えるほど表現力は上がりますが、1トークンを処理するたびに全パラメータ分の計算が発生するため、計算コストとパラメータ数が正比例で膨らみます。

MoEはこのFFN層を、複数の小さなFFN(expert)の集まりに置き換えます。Hugging Faceの解説によると、MoE層は一定数のexpert(例えば8個)と、どのトークンをどのexpertへ送るかを決めるgate network(router)から構成されます。ポイントは、すべてのexpertを毎回動かすのではなく、トークンごとに一部のexpertだけを選んで通すことです。これによって、モデル全体としては多くのパラメータを抱えつつ、1トークンあたりに実際に働くパラメータは一部に抑えられます。これがスパース(疎)なMoEと呼ばれる理由です。

routerとtop-k routingの仕組み#

MoEの中心にあるのがrouter(gating network)です。IBMやNVIDIAの解説を総合すると、routerは各トークンの表現を入力に取り、全expertに対するスコア(logit)を出す小さな学習済みの層です。多くの実装では、このスコアにsoftmaxをかけて確率のように扱い、値が高い上位k個のexpertだけを選びます。これがtop-k routingです。

kの値はモデル設計によって異なります。Switch Transformerのようにk=1(トークンごとに1つのexpert)を採る例もあれば、k=2を採る例もあります。Mixtralの技術報告では、各層に8個のexpertを置き、routerがトークンごとにtop-2を選ぶ構成が示されています。選ばれたexpertの出力は、routerのスコアで重み付けして足し合わされ、その層の出力になります。選ばれなかったexpertは、そのトークンについては一切計算されません。ここが計算量を抑える要です。

総パラメータと活性パラメータの読み方#

MoEを実務で扱ううえで最も大事なのが、総パラメータ(total params)と活性パラメータ(active params)の区別です。

総パラメータは、全expertを含めたモデル全体の重みの数で、モデルの容量にあたります。活性パラメータは、1トークンを処理する際に実際に使われるパラメータの数です。MoEでは一部のexpertしか動かさないため、活性パラメータは総パラメータよりずっと小さくなります。Mixtral 8x7Bはこの違いを示す分かりやすい例で、Mistralの発表やarXivの技術報告によれば、総パラメータは約47B(単純な8×7Bの積にならないのは、attentionなど非expert部分がexpert間で共有されるため)である一方、top-2で動くため1トークンあたりの活性パラメータは約13Bにとどまります。

この区別が意味するのは、MoEは「denseの大型モデル並みの容量を持ちながら、推論の計算量は活性パラメータ相当の小型モデル並みに抑えられる」ことです。NVIDIAの解説でも、MoEは各トークンに必要な部分だけを動かすことで、総容量を増やしつつ計算コストをほぼ一定に保てる、と説明されています。スペック表で「総パラメータは巨大だが活性は小さい」と書かれていたら、それは容量と計算量を切り離して設計しているというサインです。

メモリと計算のねじれ(VRAMは総規模、計算は活性規模)#

ここが実務で最も誤解されやすいところです。活性パラメータが小さいと「軽いモデル」と受け取りがちですが、メモリの話は別です。

推論のとき、どのexpertが選ばれるかはトークンごとに変わります。つまり事前にどれが使われるか分からないため、全expertの重みをメモリに載せておく必要があります。Hugging Faceの解説でも、MoEはすべてのパラメータをメモリに読み込む必要があり、メモリ要件は高いと明記されています。結果として、必要なVRAM(メモリ)は総パラメータ規模で効き、計算量(FLOPs)だけが活性パラメータ規模で軽くなる、というねじれが生じます。

このねじれは、ローカルやオンプレでモデルを動かすときに直接効いてきます。活性が小さいから手元のGPUで動く、とは限りません。総パラメータが大きければ、それを載せるVRAMかシステムメモリが必要です。量子化で重みのビット幅を下げてメモリを圧縮したり、使わないexpertの重みをGPUの外(CPUメモリやディスク)へ退避するオフロードで凌ぐ手もありますが、オフロードは重みの読み出しがボトルネックになり速度が落ちやすい点に注意が要ります。

MoEはむしろ、多数のGPUに分散させて高スループットで捌く大規模サービングと相性が良いアーキテクチャです。expertを複数GPUに分けて配置するexpert parallelismという分散手法もあり、NVIDIAはこうした構成でMoEを効率よく提供する取り組みを紹介しています。裏を返せば、単機・低VRAM環境ではdenseの中型モデルの方が扱いやすい場面もあります。ローカル運用の現実的な線引きは、ランタイム比較の記事もあわせて確認すると掴みやすくなります。

学習と推論、それぞれの難しさ#

MoEは良いことずくめではなく、denseにはない固有の難しさがあります。

学習面で代表的なのがロードバランシングです。routerを素直に学習させると、特定のexpertにトークンが偏り、一部だけが使われて残りが育たない状態に陥りやすいことが知られています。Hugging FaceやIBMの解説では、gating networkが同じ少数のexpertばかりを選ぶように収束してしまう現象が指摘され、これを避けるために全expertへ均等にトークンが流れるよう促す補助損失(auxiliary loss)を加えるのが一般的だと説明されています。この、一部のexpertに偏って他が機能しなくなる状態はexpert崩壊(expert collapse)などと呼ばれ、MoE学習の安定化における中心的な課題の一つです。

推論・サービング面では、トークンごとに動くexpertが変わるため、バッチ内のトークンが多様なexpertに散らばると処理効率が読みにくくなります。expertを複数GPUに分散する構成では、トークンを担当GPUへ送るための通信も発生します。さらにMoEはファインチューニングで下流タスクへの汎化が難しかった歴史があり、Hugging Faceは近年の研究で、MoEはむしろ複数タスクでのinstruction tuningから恩恵を受けやすいという報告も紹介しています。いずれにせよ、MoEは「denseの置き換えとして無条件に楽」なわけではありません。

モデル選定でどう見るか#

スペック表を前にしたとき、MoEかどうかで見るべき点が変わります。実務での読み方を整理します。

MoEを採用したオープンウェイトの大型モデルは選択肢として存在感を増していますが、個々のexpert数や活性パラメータはモデルごとに異なり、更新も頻繁です。具体的な構成を前提に検討するときは、各モデルの公式技術資料で現行の数値を確認するのが確実です。

よくある質問#

まとめ#

MoEは、容量と計算量を切り離すことで、大きなモデルを現実的なコストで動かすための工夫です。総パラメータで容量を稼ぎ、活性パラメータで計算を抑える。この分業が理解できると、スペック表の二つの数字が急に読めるようになります。一方で、メモリは総規模で効くというねじれや、学習側の難しさは見落とされがちです。「活性が小さい=軽い」と早合点せず、自分の環境と用途に照らして、メモリ・スループット・品質を並べて判断する姿勢が、MoE時代のモデル選定では効いてきます。