Google DeepMind、エンコーダーを廃した軽量マルチモーダルモデル「Gemma 4 12B」の構造を解説

何が発表されたのか

Google DeepMindは、オープンソースのマルチモーダル大規模言語モデル（LLM）「Gemma 4」ファミリーにおいて、パラメータ数120億のモデル「Gemma 4 12B」のアーキテクチャ詳細を公開しました。解説はGoogle DeepMindのMaarten Grootendorst氏が担当しています。本モデルは既存のマルチモーダルモデルとは一線を画し、画像や音声の入力を処理するための「専用エンコーダー」を搭載しない「エンコーダーフリー（Encoder-Free）」構造を採用している点が最大の特徴です。研究段階の発表ではなく、すでにHugging FaceやGitHub等を通じて一般提供（GA）およびオープンソース公開が開始されています。

発表された機能・アップデートの全容

従来のマルチモーダルモデルが抱える「エンコーダー」のボトルネック

従来のマルチモーダルAIモデルは、テキスト以外の入力情報を理解するために、専用のエンコーダーと呼ばれるニューラルネットワークを前段に配置していました。例えば、画像入力に対しては「ビジョンエンコーダー（Vision Encoder）」と呼ばれるトランスフォーマーベースのモデルが使用されます。また、音声入力に対しては「Conformer（コンフォーマー）」などのオーディオエンコーダーが使用されてきました。これらのエンコーダーは、入力データの意味を抽出し、LLMが理解できる「埋め込み（embeddings）」に変換する役割を担っています。しかし、これらのエンコーダー自体が非常に巨大なパラメータを抱えていることが課題となっていました。動画内のスライド資料によると、ビジョンエンコーダーのパラメータ数は最大で5億5000万（550M）に達し、オーディオエンコーダーのConformerも約3億（300M）のパラメータを持っています。これらは単独でも軽量なLLMに匹敵する規模であり、計算リソースを大量に消費します。さらに、LLM（デコーダー）が推論を開始する前に、まずこれらのエンコーダーが入力データを完全に処理し終える必要があります。このため、システム全体の「最初のトークンを出力するまでの時間（Time to First Token: TTFT）」が物理的に長くなってしまうという構造的なボトルネックが存在していました。

音声処理からエンコーダーを排除する「40msセグメント分割と直接投影」

Gemma 4 12Bでは、このボトルネックを解消するために、音声処理におけるオーディオエンコーダー（Conformer）を完全に廃止しました。その代わりに、入力された音声データを「40ミリ秒（40ms）」という非常に短いセグメントに機械的に分割する手法を採用しています。分割された各セグメントからは、音波の「振幅値（amplitude values）」のセットが直接抽出されます。この振幅値のセットは、軽量な「線形投影（Linear Projection）」レイヤーを通過するだけで、LLM（デコーダー）に直接入力可能なテンソルへと変換されます。この手法が成立する理由は、音声データが本質的に「時系列のシーケンシャルな情報」だからです。LLMは本来、テキストなどの時系列データを処理することに極めて長けています。そのため、専用のエンコーダーで高度な意味抽出を行わなくても、時系列の数値データとして直接LLMに入力すれば、LLM自身がその文脈や意味を処理できるという設計思想に基づいています。これにより、3億パラメータのConformerの処理を丸ごとスキップすることが可能になり、音声入力時のTTFTを大幅に短縮することに成功しました。

画像処理における「軽量Embedder（35M）」と位置情報の付与

画像データの処理からエンコーダーを排除するアプローチは、音声データに比べて複雑です。画像は音声のような単純な1次元の時系列データではなく、幅、高さ、そしてRGBチャンネルという「3次元の情報（3Dピクセル）」で構成されているためです。Gemma 4 12Bでは、従来の5億5000万パラメータを持つビジョンエンコーダーを使用する代わりに、わずか3500万（35M）パラメータの極めて小さな「Embedder（エンベッダー）」を1層だけ配置する構成を採用しました。この軽量Embedderの役割は、画像の「意味を理解すること」ではなく、単に画像をパッチ（断片）に分割し、それらをLLMが受け入れられる次元の埋め込みベクトルに変換することだけに特化しています。このプロセスにおいて最も重要なのが「位置情報（Positional Embedding）」の追加です。エンコーダーを介さない場合、LLMは入力された画像の各パッチが画像のどの場所（X座標、Y座標）に対応しているのかを認識できません。そのため、軽量Embedderの内部で、各パッチに対して明示的に2次元の位置エンコーディングを付加します。これにより、LLMは画像全体の幾何学的な構造を保持したまま、データを処理できるようになります。

なぜ軽量Embedderに3500万ものパラメータが必要なのか

一見すると、単に画像をパッチに分割してLLMに送るだけのEmbedderに、なぜ3500万ものパラメータが必要なのかという疑問が生じます。動画内では、Maarten Grootendorst氏がその数式と技術的背景をスライドで詳しく解説しています。画像データはピクセル数が非常に多いため、これをLLMの隠れ層の次元数（モデル次元）にマッピングする「線形投影（Linear Projection）」の行列がどうしても巨大になります。例えば、48×48ピクセルのRGB画像（48×48×3 = 6,912ピクセル）を処理する場合を考えます。この入力次元数をモデルの次元数と掛け合わせることで、線形投影レイヤーの重み（weights）が決定されます。動画のスライドに示された計算式では、この線形投影部分だけで約2654万パラメータ（26,545,920 params）を占めています。これにレイヤー正規化（LayerNorm）や位置埋め込み（Positional Embedding）のパラメータが加わることで、最終的にEmbedder全体のパラメータ数が約3517万（35,176,704 params）に達します。つまり、この35Mという数値は、ニューラルネットワークによる高度な特徴量抽出（意味理解）を行っているからではなく、高次元の画像ピクセルデータをLLMの入力空間へ変換するための物理的な接続部分（投影レイヤー）のサイズを意味しています。

意味理解をLLM（デコーダー）に一元化するメリット

Gemma 4 12Bの設計思想の根幹は、「マルチモーダルデータの意味理解（Semantic Processing）を、すべてLLM（デコーダー）側に一元化する」という点にあります。従来のモデルでは、ビジョンエンコーダーやオーディオエンコーダーが前段で「これは赤い鳥の画像である」「これは『こんにちは』という音声である」といったある程度の意味理解を行っていました。しかし、Gemma 4 12Bの軽量Embedderや音声投影レイヤーは、そうした意味的な解釈を一切行いません。単に生の入力データをLLMが処理できる形式に変換して渡すだけです。画像や音声の「意味」や「文脈」を解釈する重い処理は、すべて120億パラメータを持つLLM本体が担当します。これにより、モデル全体のアーキテクチャが極めてシンプルになります。また、エンコーダーとデコーダーの間で発生していた情報の損失や、個別のエンコーダーの学習コスト、さらには推論時のオーバーヘッドが排除されます。結果として、リソースの限られた環境でも高速かつ効率的にマルチモーダル推論を実行できる、洗練されたオープンソースモデルが実現しました。