Mixture-of-Expertsモデルを、シンプルに解説する

巨大なパラメータ数を持つと説明されながら、なぜか比較的安価で高速に動くモデルを見たことがあるかもしれません。一見すると矛盾しています――パラメータが多いほど、通常は計算量も増えるからです。その解決策がmixture-of-experts、すなわちMoEと呼ばれるアーキテクチャで、大規模モデルの構築のされ方において最も重要な考え方の一つになりました。概念は名前が示すよりシンプルで、それを理解すると本物の謎が解けます。モデルがどうして「巨大」かつ「効率的」を同時に成り立たせられるのか、という謎です。本稿はそれを平易な言葉で解説します。

MoEが解く問題

基本的な緊張から始めましょう。モデルをより高性能にするには、通常はより大きくすること――より多くのパラメータ、より多くの学習容量――を意味します。しかしモデルが使うすべてのパラメータは、実行のたびに計算とメモリを消費します。通常のモデルでは、すべての入力に対してすべてのパラメータが関与します。だから性能をスケールアップすると、一つひとつのリクエストのコストが歩調を合わせてスケールアップします。ある点を超えると、それは法外に高価になります。

MoEが問う問いはこうです。すべての入力に対して、本当にモデル全体が稼働している必要があるのか。ほとんどの入力は、モデルが知っていることの一部しか呼び出しません。詩についての質問と化学についての質問が、まったく同じ機構を必要とするのは明らかではありません。もしモデルが、全体としては巨大で、大量の専門的な容量を保持しつつ、特定の入力ごとに関連する部分だけをオンにできたら、どうでしょう。

それがすべての考え方です。MoEはモデルの総サイズを、リクエストごとに使われる量から切り離します。

中核の考え方：多くのエキスパート、一度に使うのは数個

mixture-of-expertsモデルでは、特定の層がエキスパートと呼ばれる多数の並列なサブネットワークに分割されます。すべての入力を処理する一つの大きなブロックの代わりに、横並びに座る小さなブロックの集合があります。任意の入力片に対して、これらのエキスパートのうち数個だけが起動され、残りはその入力に対して休眠します。

つまりモデルは、たとえば多数のエキスパートを合計で含んでおり――そこから大きな総パラメータ数が生まれます――特定のトークンに対して仕事をするのはほんの一握りだけです。総容量は巨大で、入力ごとのアクティブな容量はささやかです。これこそ、そうしたモデルが非常に大きなパラメータ数を掲げつつ、はるかに小さな密モデルに近いコストで動ける理由です。

「エキスパート」という言葉について一言。それぞれをきちんとした専門家――これは数学担当、あれはフランス語担当――と想像しやすいのですが、現実はもっと雑然としています。エキスパートは学習から生まれる仕方で専門化し、きれいな人間のカテゴリーに対応することはまれです。ラベル付けされた部署ではなく、モデルが経路を選べる、学習された異なる経路と考える方が適切です。

ルーター：誰が何を扱うかを決める

入力ごとに数個のエキスパートしか稼働しないなら、どの数個かを決める何かが必要です。その何かが、通常ルーターまたはゲーティングネットワークと呼ばれる小さな構成要素です。各入力片に対し、ルーターはそれを見て、扱うのに最も適したエキスパートを選び、入力をそれらへ送り、残りを飛ばします。

ルーター自体も、他のすべてと並んで学習時に学習されます。誰も入力をエキスパートへ手で割り当てません。モデルは学習の過程で、仕事を分ける有用な方法――どのエキスパートがどんな種類の入力を扱うべきか――を発見し、ルーターはその学習されたルーティング判断を符号化します。リクエストを送ると、ルーターはトークンごとに静かにこれらの選択を下し、それぞれを選ばれたエキスパートへ導いています。

このルーティングは設計の心臓部であり、正しく仕上げるのが最も厄介な部分でもあります。それが以下のトレードオフへつながります。

なぜこれだけの手間をかける価値があるのか

MoEの見返りは、モデル構築の中心的なトレードオフ――性能対コスト――におけるより良い取引です。

総容量と入力ごとの計算量が切り離されているので、MoEモデルは、同等の実行コストの密モデルよりはるかに多くの知識と技能を保持できます。非常に大きなモデルの性能に近いものを、はるかに小さなモデルの実行コストに近いもので手に入れられるのです。モデルを大規模に動かす費用が本物の制約となる世界では、それは強力なてこです。それが、高性能で効率的なモデルにMoE設計が一般的になった大きな理由です――すべてのリクエストのコストを釣り合わせてスケールさせることなく、容量をスケールし続ける方法を提供するからです。

トレードオフと難しさ

MoEはタダの効率ではありません。それ自身の複雑さを持ち込み、それらを理解することが、あなたのメンタルモデルを誠実に保ちます。

• ルーティングはバランスが取れていなければならない。 ルーターが人気の数個のエキスパートを過度に贔屓するよう学習すると、残りは使われず――容量の無駄――忙しいものはボトルネックになります。学習は、エキスパート全体に健全な仕事の分散を積極的に促さなければならず、このバランスを正しく取るのは本当に難しいのです。
• 計算量が下がってもメモリコストは高いまま。 入力ごとに稼働するのは数個のエキスパートだけなので、リクエストあたりの計算量はささやかです。しかしそれらのエキスパートはすべてロードされ利用可能でなければならないので、メモリフットプリントは大きなモデル全体を反映します。MoEは、モデルをホストするのに必要なリソースよりも、計算量で節約するのです。
• 学習がより複雑。 多くのエキスパートとルーターを協調させ、ルーティングのバランスを保ち、各部品を滑らかに連携させることは、単一の密モデルを学習させるより難しいのです。実行時の効率は、構築時の複雑さの増加で買われます。

つまりMoEは、洗練された取引であって、単なるアップグレードではありません。より厄介な学習と大きなメモリ要件を代償に、より安価な推論とより大きな容量を買うのです。

これがユーザーとしてのあなたにどう影響するか

これらの大半は、実際にモデルを使うとき見えません――テキストを送ってテキストが返り、ルーティングは水面下で静かに起きています。しかしアーキテクチャは、認識する価値のあることをいくつか説明します。モデルが目を見張る総パラメータ数を掲げつつ、驚くほど安価に動ける理由であり、それはモデルをサイズとコストで比較するとき重要になります。同じモデルについて、掲げられた「総パラメータ」の数字と「入力ごとのアクティブパラメータ」の数字が劇的に異なり得る理由――そしてなぜアクティブな数字の方が実行コストのより誠実な目安であることが多いか――の説明でもあります。そして、見出しのサイズの数字には文脈が必要だという戒めでもあります。MoEが絡むと、同じ総パラメータ数の二つのモデルが、現実世界では非常に異なる経済性を持ち得るのです。

まとめ

mixture-of-expertsは、単純な問いへの答えです。すべての入力に対してモデル全体が稼働しなければならないのか。モデルの一部を多数の並列なエキスパートに分割し、学習されたルーターを使って入力ごとに数個だけを起動することで、MoEはモデルの総サイズを、それを使うコストから切り離します。それにより、モデルは容量において巨大でありながら、比較的安価に動けます。だからこそ、これほど多くの高性能で効率的なモデルがこの方式で作られているのです。落とし穴は、エキスパートを均等に使い続けなければならず、モデル全体が依然としてメモリに収まらなければならず、学習がより込み入っていることです。これらに直接触れることはまれですが、それは「巨大」と「手頃」という、さもなくば不可解な組み合わせを説明し、総パラメータ数だけが誤解を招きかねない理由なのです。