Mixtral of Experts：スパースMoEによるオープンウェイト言語モデルの新基準

2020年代初頭に普及した大規模言語モデルの多くは、すべての構成要素を常に動かす「密なモデル」が主流であった。ここでいうトークンとは、文章を構成する単語や文字の断片であり、言語モデルが計算処理を行う最小単位である。密なモデルでは、文章中のトークンを1つ処理するたびに、モデル内に存在するすべての層や結合パラメータを通じた計算が実行される。モデルが蓄える知識や推論能力はパラメータの総数に大きく依存するため、7Bから13B、さらに70Bへとモデル規模そのものを拡大させることが性能向上の基本方針と見なされていた。

しかし、このアプローチには運用上の厳しいボトルネックが存在した。モデルの総容量を増やすと、推論時に1トークンを処理する計算量もそのまま比例して膨らむ点である。計算量の増大は、ユーザーへの応答遅延を招き、推論に必要な計算機資源と電気代を跳ね上げる。特に70Bクラスの巨大モデルを業務環境で運用しようとする場合、推論処理の重さが実用的な応答速度の確保を阻む大きな壁となっていた。

この「モデル容量の拡大」と「毎回の計算量の増大」が直結する制約を打破する手法として注目されたのが、Mixture of Experts（MoE）という設計思想である。ネットワーク内部を複数の専門的なサブブロック（エキスパート）に分割し、入力トークンに応じて必要な一部のみを選択して動かす「疎な活性化」を採用すれば、知識容量を維持したまま計算負担を抑えられるという理論的期待があった。

しかし、Mixtral登場前のオープンモデルにおいて、MoEの実用化は定着していなかった。入力をどのエキスパートへ割り振るかというルーティングの学習が難しく、特定のエキスパートだけに処理が偏る現象が生じやすかったためである。さらに複数GPUへの分散配置や効率的な並列処理パイプラインの実装も極めて複雑であった。プロプライエタリな巨大システムで使われているという推測はあっても、手元で検証可能な高品質のオープンウェイトモデルとしては、信頼できる決定版が存在しなかった。

この技術を理解する鍵は、モデルの規模を表す2つの尺度の区別にある。モデルが保持する重みの全体量である「総パラメータ数」と、1トークンの処理で実際に計算される「アクティブパラメータ数」である。従来の密なモデルでは両者が完全に一致していたが、疎なモデルでは両者を分離して設計できる。

ここで、本記事を通じて用いる現実的な業務の例えとして、「社内文書処理アシスタント業務」を考えよう。案件を案内する「受付窓口（ルーター）」と、奥に控える「8つの専門部署（エキスパート）」が存在するオフィスを想定してほしい。従来の密な運用では、文書内のあらゆる単語に対して8部署全員を呼び出し、全員で確認印を押させていた。これでは組織の専門性を高めるために部署を増やすほど、文書1枚の処理に全員の手が取られ、現場がパンクしてしまう。組織全体の知見を増やしつつ、個別の作業負荷をいかに抑えるか。これが当時のAI開発が直面していた課題であった。

2024年1月に発表されたMixtral 8x7Bは、この構造的課題に対して画期的な解決策を具現化した。MixtralはMistral 7Bのアーキテクチャをベースとしながら、各層のフィードフォワード層を再設計し、独立した8つのフィードフォワードブロック、すなわち「8つのエキスパート」を並列に配置した。

極めて重要な設計判断は、文脈全体を見渡す自己注意機構は全トークンで共有されており、疎に切り替えられるのはフィードフォワード層に限定されている点である。文脈関係の把握は共有の注意機構で一貫して行い、トークン内部の特徴変換のみを8つのエキスパートへと分岐させる。この構造により、モデル全体の総パラメータ数は46.7Bとなる。「8x7B」という名称から単純計算すると56Bを連想しがちだが、注意機構などの共通部分が共有されているため、実際の総容量は46.7Bとなる。

Mixtralの中核を担うのが、各層に配置されたルーターネットワークである。トークンの内部表現が層に入ると、ルーターは8つのエキスパートそれぞれに対して適合度を採点し、上位2つのエキスパートを選択する。選ばれた2つのエキスパートのみに入力トークンが渡され、変換処理が実行される。

数式を用いずに説明すると、ルーターは選ばれた2つのエキスパートの出力に対し、自身の採点に応じた比率で重み付けを行い、両者を足し合わせてその層の出力とする。選ばれなかった残り6つのエキスパートは一切の計算を行わない。全8つの出力を計算してから選ぶのではなく、最初に選ばれた2つだけを動かすため、1トークンの処理に動員されるアクティブパラメータ数は総容量46.7Bのうち12.9Bに抑えられる。

この設計により、異なるトークンがそれぞれ異なる2つのエキスパートを使えるため、モデル全体で8つ分の容量を蓄えつつ、トークンごとの計算負担は2つ分で済む。社内アシスタントの例えで言えば、受付窓口が各単語の内容を見て、8部署から最も適した2部署だけを選んで処理させ、その回答を比率に応じて合算して次の決裁へ回す形である。組織の知識を広げつつ、毎回の作業負荷を大幅に軽くできる。

ただし、この例えが実際の研究と一致しなくなる境界も理解しておく必要がある。第一に、人間の組織では法務や経理のように人間が理解できる業務分野で分かれるが、Mixtralのエキスパートは話題別に綺麗に分担されているわけではない。論文の分析によれば、選択傾向は意味的な分野というよりも、文法的な統語構造やトークンの位置といった形式的パターンと強く相関していた。第二に、人間のオフィスでは書類全体を特定の部署へ回すが、Mixtralでは文章全体ではなく「トークンごと」、かつ「層を通過するごと」に上位2エキスパートが選び直される。同じ文の中でも単語ごとに異なる部署の組み合わせが呼び出される点が、現実の業務フローとは大きく異なる。

著者らは、Mixtralの推論性能と計算効率を検証するため、幅広い学術ベンチマークで比較評価を行った。評価対象は、一般知識、推論、算数、コード生成、多言語理解、そして最大32,000トークンの文脈から特定情報を探索するパスキー検索など多岐にわたる。

主な比較対象（ベースライン）には、代表的なオープン密モデルである「Llama 2 70B」や「Mistral 7B」、商用モデルの基準であった「GPT-3.5」が据えられた。1トークンあたり12.9Bの計算量しか使わないMixtralが、各トークンで70Bをフル稼働させるモデルや商用モデルに対して同等以上の性能を維持できるかが検証の焦点であった。

論文で報告された結果は、スパースMoEの競争力を示した。多分野の知識を測る主要指標「MMLU」において、Mixtralは70.6%を記録し、Llama 2 70Bの69.8%を0.8パーセントポイント上回り、GPT-3.5の70.0%をも0.6パーセントポイント上回った。

算数文章題のGSM8Kでは、Llama 2 70Bの34.1%に対し、Mixtralは58.4%を記録し、24.3パーセントポイントの差をつけた。コード生成のHumanEvalでも、Llama 2 70Bの29.3%に対して40.2%を達成し、10.9パーセントポイント上回った。これらの差はいずれも相対的な変化率ではなく、得点率どうしの差である「パーセントポイント」として報告されている。推論速度についても、著者らは大半のベンチマークでLlama 2 70BやGPT-3.5を凌駕し、著者らの実験環境下でLlama 2 70Bより6倍高速であったと報告している。

原論文の評価が立証したのは、一部のエキスパートのみを選択的に動かすスパース構造であっても、主要な知識・推論タスクにおいて70Bクラスの密モデルと十分に対等以上の性能を発揮できるという事実である。

一方で、この評価が示せていない範囲もある。第一に、MMLUやHumanEvalのスコアは、個別企業の実務文書の読解精度や、ハルシネーションの抑制を直接保証するものではない。長文検索で特定キーを見つけられたとしても、長文の文脈を正しく理解して矛盾なく要約できることと同義ではない。第二に、提供された記録には、各要素の寄与度を個別に切り分ける厳密なアブレーション実験が含まれていない。したがって、向上分のうちどれだけが上位2エキスパートのルーティング機構そのものによるもので、どれだけが学習データや基本設計の組み合わせによるものかを厳密に因果分離することはできない。

Mixtral 8x7Bが残した明確な影響は、オープンウェイトモデルにおけるスパースMoEの実用的な定着である。それ以前は、MoEは分散環境での実装や学習が難しい実験的構造と見なされていたが、高品質な重みがオープンに公開されたことで、コミュニティの開発意識を大きく変えた。

この影響は客観的な記録にも裏付けられている。Hugging Face上で680件のUpvotesを獲得し、Google Scholarでの引用数は2,000件を超えている。巨大なGPUクラスタを持たずとも、実効13B級の計算コストで高度な知能をローカルで動かせるという実績は、オープンソースLLMの開発動向に極めて強い刺激を与えた。

設計思想の面では、性能向上を図る際に「密なモデルを巨大化させる」だけでなく、「パラメータ総数とアクティブパラメータ数を切り離す」という選択肢を標準的な開発視野に定着させた。

ただし、歴史的影響を評価する上では、記録に支えられた境界線を厳格に意識する必要がある。提供された記録には、Mixtralのルーティング設計を直接継承した具体的な後継モデル名や、業界全体での統一標準化の合意までは記載されていない。2,000件以上の引用やコミュニティの反響は高い注目度を示すが、それ自体が後続のあらゆるモデルへの直接的な継承関係を証明するわけではない。本研究が示したのはオープンなスパースMoEの実現可能性であり、記録にない広範な影響を推論で付け加えることは避けるべきである。

現代の実務的な視点から見直した際、最も留意すべき制約は「アクティブパラメータ数と必要メモリの根本的な乖離」である。

Mixtralは1トークンの計算量を12.9B相当に抑えるが、推論時には全46.7Bパラメータの重みをメモリ上に保持しなければならない。ルーターがどのトークンでどのエキスパートを選ぶか事前には決まらないためである。一般的な16ビット精度で換算すれば、モデルの保持だけで90GB前後のメモリ容量が要求される。社内アシスタントの例えで言えば、日々の窓口業務を2部署で回すとしても、社屋には全8部署の部屋と座席を常に確保しておかなければならないのと同じである。13B級の計算量という言葉から、13B用の小型ハードウェアで動かせると誤認してはならず、メモリ容量としては46.7B分が必須となる。

第二の制約は、ルーターの負荷偏りと分散環境での通信コストである。入力文書の性質によっては、特定のエキスパートに処理が偏り、待ち時間が発生して並列処理の恩恵が薄れる懸念がある。

また、46.7Bの重みを複数デバイスに分散配置する場合、トークンをどのデバイスのエキスパートへ送り、結果をどう集めるかというデバイス間通信が層ごとに発生する。通信帯域が不十分な環境では、計算量の削減効果が通信待ちによって相殺されかねない。著者らが報告した「6倍の推論速度」は特定の実験条件下の結果であり、あらゆるインフラ環境で常に6倍の速度が得られるわけではない。

こうした制約を踏まえてもなお残る普遍的な教訓は、モデルの「容量（知識の蓄積）」と「演算（毎回の計算）」を切り離すという設計思想の有効性である。

実務者がモデル選定において確認すべき証拠は、公開ベンチマークの順位や名目上のパラメータ数だけではない。対象業務データにおける精度、モデルを展開するための必要メモリ、そして実環境での通信オーバーヘッドと推論遅延を総合的に評価することである。Mixtralが提示したのは計算効率を再考するための有力な選択肢であり、その真価を発揮させるには運用環境との整合性を冷静に見極める必要がある。