0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

エキスパートが大活躍! LLM の最新トレンド MoE モデルってなんだ?

0
Posted at

はじめに

最近の LLM 界隈で「MoE (Mixture of Experts)」という単語をよく見かけるようになりました。
ただ、「専門家 LLM が分担して問題を解いているっぽい」というフワッとした理解のままだと

  • エキスパートって結局何なのか
  • どこが通常の Transformer と違うのか
  • 何がうれしくてわざわざ構造を複雑にしているのか

といったあたりで勘違いが起こりやすいモデルでもあります。

この記事では、MoE の大まかな理解を目指して以下の内容についてまとめてみます。

  • エキスパートの正体は一般的な線形層からなる FFN (Feed-Forward Network)
  • エキスパートは層ごとに存在する
  • トークンごとにどのエキスパートを使うか決める

🐣 一緒に MoE に萌えましょう!


まずは MoE のイメージ

とりあえず重要なポイントとして MoE は Transformer の FFN 部分を、たくさんのエキスパート FFN に置き換えて、その中から必要なものだけを計算する仕組みです。Transformer については昔書いた記事があるので、そちらも参考にしてください。

論文紹介:Attention Is All You Need

通常の Transformer ブロックは

  1. Self-Attention
  2. FFN (2 層程度の多層パーセプトロン(MLP))

の二段構成です。
このうちパラメータの大部分は FFN が持っています。
Transformer の動きは大きく分けると

  1. Attention で情報を集める
  2. FFN で知識に変換する

という役割分担になっています。Transformer では FFN に知識が集約されていると言われています。

MoE は従来では 1 個だった巨大な FFN を、「複数の FFN を並べておき、トークンごとに少数の FFN だけを通す」という処理に変えています。この個々の FFN のことをエキスパートと呼んでいるわけです。その結果以下のような特徴を持ちます。

  • モデル全体のパラメータは増える
  • でも 1 トークンごとに使うエキスパートは一部だけ
  • その結果、推論時の計算量はあまり増やさずにモデル容量だけ増やせる

どこが普通の Transformer と違うのか

通常の Transformer の FFN

まず、普通の FFN の処理を簡単に書いてみます。

\mathrm{FFN}(x) = W_2 \, \sigma(W_1 x)
  • $x$: トークンごとの隠れ表現
  • $W_1, W_2$: 学習される行列
  • $\sigma$: 活性化関数(ReLU や GELU など)

LLM の重みの多くはこの FFN が抱えています。

🐣 モデルの知識がここに詰まっているということです!

MoE では FFN が「エキスパートの集合」になる

MoE では、この FFN の代わりに

  • エキスパート $E_1, E_2, \dots, E_E$
  • それぞれは別々のパラメータを持つ FFN

を配置します。その結果、

  • 従来: 1 層につき 1 個の大きな FFN
  • MoE: 1 層につき $E$ 個の FFN(エキスパート)が並んでいる

という構造になります。

ただし「毎回全部を通す」と計算が爆発するので、後で説明するゲートがどのエキスパートをどれくらいの重みで使うかを決定します。

エキスパートは層ごとに存在する

ここは勘違いされやすいポイントです。
MoE ではモデル全体で共通の専門家集団がいて、そこから選ぶというよりは各 MoE 層ごとに、その層専用のエキスパート集合が存在しているという設計が主流です。

つまり

  • 層 3 のエキスパート集合
  • 層 7 のエキスパート集合

は別メンバーです。
一部の層だけ MoE 化しているモデルもあります。

🐣 層 3 のエキスパート 12 番と層 7 のエキスパート 12 番は全く別物なんです


ゲート / ルーターって何者?

エキスパートを活かす要の仕組みが、ゲート (router, gate) と呼ばれる小さなネットワークです。

数式で書くと以下のようになります。

\begin{aligned}
s &= W_g x \\
g &= \mathrm{softmax}(s) \\
\mathrm{TopK}(g) &= \{ i_1, \dots, i_k \} \\
y &= \sum_{i \in \mathrm{TopK}(g)} g_i \, E_i(x)
\end{aligned}
  • $x$: トークンの隠れ状態
  • $W_g$: ゲート用の行列
  • $g$: 各エキスパートのスコア
  • $\mathrm{TopK}(g)$: スコア上位 $k$ 個のエキスパート
  • $E_i(x)$: エキスパート $i$ の出力

難しそうに見えますが、処理内容は意外にシンプルで

  1. トークンごとに「どのエキスパートが良さそうか」をスコアリングする
  2. 上位 $k$ 個だけ選ぶ(上位 1 ~ 8 個くらいが多い)
  3. 選ばれたエキスパートの出力を重み付きで足し合わせる

という計算を実行しています。

これにより

  • パラメータは大量に持ちながら
  • 実際に計算するのは、トークンごとにごく一部のエキスパートだけ

という状態を作っています。


勘違いしやすいポイント

勘違い 1: 「エキスパート = 分野ごとの巨大モデル」

ありがちなイメージは

翻訳が得意なモデル
プログラミングが得意なモデル
文章生成が得意なモデル
を束ねてゲートで切り替える

というものですが、実際にはそうではありません。エキスパートの正体は「その層の中にある 1 個の FFN」であって、Attention は基本的に全トークン共通であることに注意してください。

学習の結果として

  • 数字に強いエキスパート
  • 長文に強いエキスパート

のような「得意分野」が偶然生まれることはあるかもしれませんが、ほとんどのエキスパートは単一のドメインに特化しているわけではなく複数の分野を担っています。

勘違い 2: 「プロンプトごとにエキスパートを選んでいる」

もう一つよくある誤解は

プロンプト全体を見て「このプロンプトはエキスパート 3 で対応」と切り替えている

というイメージです。

実際にはルーティングは トークンごと に適用されるため、同一入力の中でも、トークンによって使うエキスパートが異なります。逆に、同じトークンでも異なる文脈で使われた場合、他のトークンからの Attention の影響によって形が変わっていくため異なるエキスパートが用いられている可能性があります。この「細かい単位で専門性を使い分ける」感じが、MoE の面白いところの一つです。


MoE の具体的なメリット

メリット 1: 計算量はほぼ据え置きで、モデル容量だけ増やせる

MoE の一番おいしいところはここです。

  • エキスパート数を 8 倍にすると、パラメータ数も約 8 倍
  • でも 1 トークンにつき Top-2 しか使わないなら、FFN 部分の計算は約 2 倍程度
  • 設計を工夫すると、実効的な計算コストは「同サイズの密な FFN」と近い水準にできる

つまり

  • FLOPs を大きく増やさずに
  • 「パラメータだけ巨大にする」というスケーリングが可能

というのが MoE の強みです。

メリット 2: 分散と相性が良い

もう一つの実務的なメリットは

  • 各エキスパートを別々の GPU やノードに配置できる
  • ゲートが「このトークンはエキスパート 3 と 7」と決めてそこに投げる
  • 結果だけ集めて合成する

という「エキスパート並列 (expert parallel)」が自然にできる点です。

巨大クラスタで「限られた計算資源からできるだけ性能を引き出したい」ときに使いやすい構造になっています。


もちろんいいことだけではない

課題 1: ルーティングの偏り

ゲートが賢くなりすぎると

  • 特定のエキスパートにトークンが集中する
  • 他のエキスパートはほとんど使われない

という問題が起きます。

そのため

  • ロードバランス用の補助損失を入れる
  • エキスパートごとの受け入れ容量に上限を持たせる
  • 少しランダム性を入れて偏りを緩和する

といった工夫が必要になります。

課題 2: システム実装が難しくなる

理論としてのアイデアはシンプルですが、実装は一気に複雑になります。

  • トークンをエキスパートに振り分ける all-to-all 通信
  • バッチごとにエキスパートに流れるトークン数が変動する
  • 推論時は「一番遅いエキスパート待ち」になりやすい

など、分散システムとしての課題が増えます。
MoE は「推論時の計算効率の良さ」と「複数のエキスパートの学習という複雑さ」のトレードオフの上に成り立っていると考えることができそうです。


MoE は「LLM の最終形」なのか?

MoE の現在の立ち位置をまとめると

  • 巨大なパラメータを効率良く使いたい、というニーズにはかなりハマる
  • ただし実装コストや学習の難しさは無視できない
  • 密なモデルも依然として強く、MoE と密モデルのハイブリッドなども模索されている

という状況です。なので今のところ LLM を作るときの有力オプションの一つくらいの位置づけで見るのが現実的だと感じています。

🐣 とりあえず全部 MoE にすれば最強、という話ではなさそうですね


おわりに

この記事では、MoE について初心者向けに解説してみました。得意分野を持つ小さなエキスパートの連携というよりはトークンごとに最適な表現を割り当てて推論時の負荷を軽くする手法ということですね。結構な数の最新モデルがMoE を採用しているみたいなので、なにか本質的な利点がありそうです。
ではまた次の記事で。

🐣 私も何かのエキスパートになりたいなー

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?