MoEは計算を削り、PLEは表現力を補う　…　Gemma 4で整理する2つの「節約法」

AI Google コンピュータ

Gemma 4 の動作の実験をきっかけにMoEとPLEの違いを整理してみたノートです。自己理解を深めるために「何が違うのか」をつかむためのメモとして読んでもらえるといいかもしれません。私の理解も間違っているかもしれないですし🙄

最近、更新のあったGemma 4の資料を読んでいるなかで、理解が引っかかってしまったポイントの一つが MoE(Mixture of Experts) と PLE(Per-Layer Embeddings) という2つの単語でした。どちらも「総パラメータは大きいけど、実際に使う量は小さい」を実現する技術と説明されていて、ぱっと読みだと違いがほとんど分からないんですよね。

ただ、この2つは 何を節約しているかが異なる ので、この部分を押さえておかないと、後まで尾を引くことになりそうでした🤔 自分も最初は「MoE と PLE って結局同じなのでは?」と思っていました😅

今回は自分でわかりやすく整理するために、料理に例える → 用語 → 仕組み → サイズ × 戦略 → 実装 → 実環境、 という6段階くらいに分けて整理しています。

⚠️ 今回の情報は2026-05 時点を基にしています。最新情報は併せて公式情報も確認してみてください。

1. たとえて考えてみる

LLM は「35人のシェフのライン」

LLM はトークン(単語の切れ端)を、たくさんの加工ステージに順番に通します。Gemma 4 E4B なら35ステージあります。

食材(=トークン)が35人のシェフを順番に通る。 各シェフが少しずつ味を整えて、最後に完成料理(=次の単語の予測)が出てくる。

普通のモデル(dense)では、35人全員が超優秀である必要があります。だから人件費(=計算量)もキッチンの広さ(=メモリ)も巨大になってしまうんですよね。

MoE のアイデアは「専門家を集めて、料理ごとに必要な人だけ呼ぶ」

各シェフの後ろに 128人の専門家 を控えさせておきます。料理ごとに「この食材にはこの8人だけ呼ぶ」と振り分ける係(ルーター) を配置するイメージです。

  • 動くのは選ばれた8人だけ(残り120人は今回は出番なし) → 動く人件費(計算量)は安い
  • ただし、128人分の待機場所は必要 → メモリは消費する

PLE のアイデアは「シェフ全員に専用カンペを渡す」

こちらはMoEとは発想が違います。シェフは普通の人数のままです。その代わりに、各シェフに「この食材専用のカンペ」を渡します。

このカンペには「この食材を、第5シェフではこう扱え、第6シェフではこう扱え…」と35人ぶんの指示が書かれていて、巨大な掲示板(テーブル) に保管されているイメージです。

  • シェフ自体を大きくしなくても、カンペで表現力が補える → 重い計算を増やさずに済む
  • ただし掲示板は巨大になる → メモリは消費する

ここまでのまとめ

MoE PLE
たとえると… 料理ごとに必要な専門家だけ呼ぶ 料理ごとにシェフ全員に専用カンペを渡す
何を効果として狙うか 動く専門家を絞って 計算を減らす カンペで補強して 計算を増やさず表現力を上げる
それでも残るコスト 待機場所(メモリ) 掲示板(メモリ)

👉️ どちらも「たくさん用意して、毎回はその一部だけ使う」を狙う技術です。

  • MoE: 128人の専門家のうち、料理1つで動くのは8人だけ
  • PLE: 掲示板にぎっしり貯めたカンペのうち、料理1つで引くのは数枚だけ

違いは何を節約するかとなります。

2. 用語を揃える

先ほどの「たとえ」を技術用語に置き換えてみます。

たとえ 技術用語
シェフ decoder layer(デコーダ層)
シェフの脳みそ FFN(feed-forward network)
専門家 expert(エキスパート)
振り分け係 Router / gating network
カンペ per-layer embedding(層ごとの補助埋め込み)
掲示板 embedding table

なぜパラメータを増やしたいのか

スケーリングルール(scaling law)が示すとおり、パラメータが多いほど LLM は賢くなる 傾向があります。だから増やしたい、というのが基本の考え方ですね。

なぜ全部使うと困るのか

ただ、パラメータを増やすと推論時に2つのコストが上がってしまいます。

  1. 計算量(FLOPS)　…　1トークン処理するのに必要な掛け算の数
  2. メモリ(VRAM/RAM)　…　モデル全体を載せる場所

スマホ、Raspberry Pi、ノート PC といったエッジデバイスではこの両方が厳しい🙄 MoEとPLEは、このどちらを優先して削減するかで分かれている と考えると分かりやすいです。

👉️ 計算とメモリは独立したコストで、自分の環境でどちらの制限に引っかかるか によって、MoE寄りかPLE寄りかが決まってきます。

3. 仕組みを図で見る

MoEのデータフロー

👉️Routerが動的に判断して、一部のExpertだけを動かしているところがポイントです。これが「条件付き計算(conditional computation)」と呼ばれる仕組みです。

PLEのデータフロー

👉️こちらでは判断する主体がいません。トークンIDが決まれば、引くベクトルは自動的に決まります。選んでいるのではなく、ただ配っているだけというところがMoEとの大きな違いですね。

「矢印の重さ」が全然違う

図だけ見るとPLEのほうが矢印が多くて処理が重そうに見えるのですが、1本あたりの計算量が大きく異なるんです。

矢印1本の中身 だいたいの重さ
MoE の Expert 1本 FFN を1回まるごと走らせる 数百万〜数十億 FLOPS
PLE の矢印1本 テーブルから 256 次元ベクトルを引く ほぼメモリアクセスだけ

なので PLEは矢印が多くても合計計算量はdenseの数％増し程度 で済みます。一方、MoEは1本止めるだけで処理を大きく削れるということになります。

👉️ 図上で矢印が多く見えても計算量が多いとは限らない。MoEの矢印は「重い」、PLEの矢印は「軽い」と覚えておくと混同しなくて済みます。

4. サイズが戦略を決める

ここまでで「MoE と PLE は何をしているか」がだいたい掴めたかと思います。ここからは俯瞰して、「なぜどのサイズにどの技術を使うのか」 を見てみます。これを押さえておくとGemma 4のモデルラインナップが読める ようになります😊

Gemma 4のラインナップが教えてくれること

リリースされた4モデルを並べてみると、サイズによってきれいに技術が分かれているのが分かります。

サイズ帯 モデル 戦略
小(2B〜4B 実効) E2B / E4B PLE のみ(MoE なし)
中(31B dense) 31B dense(何もしない)
大(26B 総 / 4B 活性) 26B A4B MoE のみ(PLE なし)

小型サイズにMoEは入っておらず、大型サイズにPLEは入っていない。これは偶々ではなく、「効果のあるサイズ帯」があるから、と自分は理解しています。

⚠️公式の説明というより設計意図の解釈だと思ってください。論文やモデルカードでそのまま明言されていませんが、こういった視点で見るとラインナップが整合的に読めるかなというレベルの話です。

なぜMoEは小型モデルに向かないのか？

おそらく以下の3つが効いていそうです。

①Routerのオーバーヘッドが相対的に重い 小さいFFNをexpertに分割しても、Routerの判定コスト+負荷分散コストが利得を食ってしまうのではと思います。たとえると「100円の作業をどの専門家に振るか会議に200円かける」状態に近そうですね😅

②専門化する余地がない モデルが2B規模では、各expertが「専門領域」を持てるほどの容量がない、というのも大きそうです。結果として「同じようなことをやる expert」が並ぶだけで、増やしてもあまり賢くならない。MoEの前提は「expert ごとに違う得意分野ができる」ことなので、その前提が成り立たないといけません。

③メモリを食う MoEは活性しないexpertもVRAMに常駐させる必要があります。エッジデバイスではVRAMが一番厳しい制約なので、MoE の利点(計算節約)とエッジの制約(メモリ)が噛み合わない わけです。

なぜPLEは大型モデルに向かないのか？

こちらも3つほど挙げられそうです。

①residual stream に既に余裕がある 大きいモデルはhidden sizeが広く(31B 級なら数千次元)、最初の埋め込みが層を通る間に必要な情報を運べる帯域が十分あります。各層に補助信号を注入してもありがたみが薄い、つまり「カンペがなくてもシェフが優秀すぎて困らない」という状態というわけです。

②テーブルが絶対サイズで巨大化する PLEテーブルは vocab_size × num_layers × ple_dim なので、31B 級のように層数が多いモデルだとテーブルが数十 GB 級になってしまいます。エッジで動かす前提が壊れる ので、大型モデルにPLEを組み込む意味が消えてしまうわけです。

③大型モデルが置かれる環境ではメモリより計算が制約になる サーバ環境ではVRAMは買い足せても、推論レイテンシは物理限界があります。メモリを多めに使うPLE より、計算を節約できるMoEのほうが価値が高い ということになります。

サイズ vs 戦略の鳥瞰図

👉️モデルサイズが変わると、何が一番痛い制約かが変わるという理由から、最適な技術も変わるという話なんですよね。これが「サイズと戦略の対応関係」の本質なのかなと思っています。

最初のたとえに戻すと

最初に「シェフ」のたとえを使いました。これをサイズ別に当てはめてみると、こんな感じになります。

  • 小さな店(エッジ)　…　シェフは少人数で、しかも全員若手。一人ひとりにベテランの助言メモ(=PLE)を渡すと、店全体の質が一気に上がる
  • 大きな店(サーバ)　…　シェフは大ベテラン揃い。助言メモは要らないが、料理ごとに「この料理にはこの専門家チームを呼ぶ」という分業(=MoE)で回転率を上げる
  • 中規模の店　…　普通に回せば足りる。余計な工夫はしない(=dense)

5. Gemma 4の実装を覗く

ここからは少し踏み込みます。実際のコードや論文を読むときに必要になりそうな細部の話です。

Gemma 4ファミリーの構成

2026年4月に Google からリリースされた Gemma 4 は、4つのバリエーションで戦略を使い分けています。

モデル 仕組み 適用の方向性
31B dense(普通) 高性能 GPU
26B A4B MoE(128 expert 中 8 個活性、実効 4B) サーバ
E4B PLE(実効 4B) エッジ
E2B PLE(実効 2B) モバイル/Raspberry Pi

E は "Effective"(実効)、A は "Active"(活性)の頭文字です。狙っている方向性が違うので、両者は同じモデル内で混ざっていない のがポイントとなっています(MoE モデルは PLE を使わない、その逆も同じ)。

PLEの実際の計算

PLEのベクトルは、実は 2つの成分の合成でできています。

  1. Token-identity 成分　…　トークン ID から直接引いてくる埋め込み(辞書ルックアップそのもの)
  2. Context-aware 成分　…　メインの埋め込みに小さな線形変換をかけて作る、文脈依存の信号

この2つを足して 1/√2 で正規化したものが、各層に注入されています。

PLE_vector(layer i, token t) =
    ( embed_table[t][i]           ← token-identity
    + linear(main_embed[t])[i] )  ← context-aware
    / √2

なぜ2つの成分に分けているかというと、「このトークンが何か」だけだと文脈無視で使い回しが効かないし、「文脈だけ」だとトークン固有の情報が薄まる。こういった状況から両方ブレンドしているところがポイントになっています。

なぜPLEは量子化に弱いのか

PLEで引いたベクトルは、その後 scalar倍 されて RMSNormを通ります。この経路は数値感度が非常に高く、量子化ノイズが乗ると後段で増幅されて、出力品質が壊滅的に下がってしまうそうです。

⚠️実装上は以下のような対策が紹介されています。

  • PLE 関連テンソル(per_layer_embed, per_layer_model_projection, per_layer_projection_norm)は bf16 / f16 のまま保持
  • 一般的な量子化(Q4_K_M など)は本体だけにかける、いわゆる 「PLE-Safe Quantization」 が推奨

👉️PLEは「2成分のブレンド」で、量子化に敏感に反応します。ランタイム選びを誤ると性能が出ない点が注意です。

6. 実環境で選ぶ

どちらを選ぶかの判断軸

⚠️ 「VRAM が厳しいなら PLE」と単純化していますが、PLE は テーブル自体を持っている ので、総パラメータが小さいわけではありません。Google のモデルカードによれば、E2B は effective 2.3B / embedding を含めると 5.1B、E4B は effective 4.5B / 8Bとされています。アクセラレータ側に常駐する active/effective ぶんは小さくできるんですが、総メモリ使用量はランタイム実装にかなり依存するので、最終的には実機で確認するのが確実そうです。

手元の環境別の見立ての例

自分が使えそうな環境で考えると、こんな感じになるのかなと思います。あくまで「想定 RAM」と「推奨モデル」の例なので、実際にはランタイムの実装や量子化の有無などによって変わってくると思います。

環境 想定 RAM 推奨
N100 PC 16GB 程度 E2B(余裕を持って)
Raspberry Pi 5 (8GB) 8GB E2B 一択
MacBook Air M1 (16GB) 16GB E2B または E4B
RTX 4070Ti (12GB VRAM) + 32GB RAM 12GB VRAM 26B A4B もしくは E4B

おわりに

長くなりましたが、最後にひとことだけ覚えておくとしたら…

MoE は「使う専門家を絞って計算を減らす」。PLE は「各層に軽い補助情報を渡して、少ない実効計算で表現力を補う」。

両者は対立技術ではなく、異なる制約への異なる回答 なんですよね。だから Gemma 4 のように、用途別に使い分けて1ファミリーを構成できるわけです。

自分自身は Raspberry Pi 5 や N100 PCで E2B あたりを動かしてみたいなと思っているので、実測編はまた別途まとめる予定です😊 体感として「PLE が効いてる/効いてない」が分かるかどうか、けっこう気になっているところです。

参考リンク

huggingface.co

newsletter.maartengrootendorst.com

datature.io

github.com

ai.google.dev