Gemma 4 12Bが示すマルチモーダルAIの新設計――エンコーダを捨てた理由と、発表当日に試した記録

マルチモーダルなLLMを設計するとき、画像や音声をどう扱うかという問いは長らく「専用エンコーダを別に用意する」という答えに収束してきた。テキストとは次元が違うデータを、まずドメイン専有のエンコーダで処理し、次元変換層（コネクタ）を挟んでLLM側の空間に押し込む。この構造はある意味で自然な分業だったが、同時に多くのコストを生んでいた。

2026年6月、GoogleはGemma 4 12Bを公開した。このモデルが注目に値するのは、テキスト・画像・音声の三モダリティを12Bパラメータで処理できる点だけではない。それら三つのうち画像とオーディオについて、専用エンコーダを完全に排除したアーキテクチャを採用している点にある（Google Blog, 2026）。

エンコーダを「捨てる」という判断の背景には、モダリティをトークンと同じ次元空間に直接投影できるなら、エンコーダという中間層は不要であるという発想がある。この設計がいかなる帰結をもたらすかを、技術的な仕組みから整理したうえで、RTX 5090を積んだローカル環境で当日に追試した実測結果も合わせて報告する。設計の合理性は買えるが、発表通りに動くかは別の問題だった、というのが結論である。

従来アーキテクチャが抱えていた重さ

マルチモーダルLLMの典型的な構造を振り返ると、テキスト以外のモダリティを処理するために少なくとも二段階の変換が介在している。

まず、ビジョンエンコーダがある。CLIPやSigLIPといったモデルを流用したもので、小型モデルでも1.5億パラメータ、大型では5.5億パラメータに達する。これに独立したオーディオエンコーダ（約3億パラメータ）が加わると、マルチモーダル対応のオーバーヘッドだけで実に8億パラメータを超えるケースが珍しくない（Grootendorst, 2026）。

次に、コネクタと呼ばれる次元変換層がある。エンコーダが出力する特徴ベクトルの次元は、LLMが期待する隠れ次元と一般に一致しない。そのためコネクタが変換を担うが、これは推論パスに余分なレイテンシーを加えるとともに、エンコーダ・コネクタ・LLM本体という三層の協調最適化を要求する。ファインチューニング時にこの三層をどう調整するかは、実用上の大きな負担になる（Google Developers Blog, 2026）。

この構造的な重さは、クラウド環境ではまだ隠蔽できる。しかしエッジやラップトップでのローカル推論を目指すとき、エンコーダが消費するVRAMと計算コストは致命的になりやすい。

ビジョン処理の抜本的な簡素化

Gemma 4 12Bでは、ビジョンエンコーダが35Mパラメータの軽量埋め込みモジュールに置き換わっている。従来比で約95%のパラメータ削減となる（Grootendorst, 2026）。

処理の流れはシンプルだ。入力画像は48×48ピクセル単位のパッチに分割され、各パッチは単一の線形投影によってLLMの隠れ次元に直接マッピングされる。位置情報はx座標とy座標それぞれに1,120×3,840次元の行列を用意し、パッチの格子位置に応じた埋め込みを加算することで与える。LayerNormによる正規化を経て、これらの特徴はテキストトークンと全く同じシーケンスとしてLLMに流れ込む。

ここで重要な点がある。エンコーダがないということは、パッチ間の意味的な関係——どのパッチが物体の一部で、どのパッチが背景か——を判断する責務が、LLM自身のアテンション機構へ移ったということだ。これは責務の再配分である。専用エンコーダに委ねていた視覚的意味解析を、LLMの汎用的な注意機構に任せる。それが成立するためには、LLMの表現能力が視覚的文脈を内包できるほど豊かである必要がある（Grootendorst, 2026）。

Gemma 4 12Bがこの判断を下せた背景には、デコーダアーキテクチャの工夫もある。ローカルアテンション（近傍トークン間の注意）とグローバルアテンション（全トークン間の注意）をインターリーブし、グローバルアテンション層を常にブロックの最後に配置する設計が採られている。局所的な詳細と大域的な文脈の両方を捕捉する能力を持つアーキテクチャが、エンコーダフリーのマルチモーダル処理を支えているとみられる（Grootendorst, 2026）。

オーディオ処理の直接投影

オーディオ処理はさらに単純化が徹底されている。従来は約3億パラメータのオーディオエンコーダが音声の特徴を抽出していたが、Gemma 4 12Bではこれが1層の線形投影に置き換わった。

音声は16kHz（毎秒16,000サンプル）でサンプリングされ、40ミリ秒単位（640値）のフレームに分割される。このとき各値は音波の振幅を表す生の浮動小数点数であり、特別な前処理は施されない。フレームごとに線形投影を適用するだけで、テキストや画像パッチと同じ次元空間への変換が完了する（Grootendorst, 2026）。

画像パッチには格子状の2次元位置を示す位置埋め込みが必要だったが、音声は本質的に時系列の1次元シーケンスであるため、追加の位置埋め込みは不要だ。この非対称性は設計の合理性を示している——画像と音声を均一に扱おうとするのではなく、それぞれのデータ構造に即した最小限の前処理を選んでいる。

Gemma 4 12Bが中規模モデルとして初めてオーディオネイティブに対応したことの意味は、この簡素化にある。3億パラメータのエンコーダを省いたからこそ、12Bという制約の中で音声対応を組み込む余地が生まれた（Google Developers Blog, 2026）。

統一ウェイトがもたらすもの

エンコーダフリー設計のもう一つの含意は、テキスト・画像・音声の三モダリティが完全に同一のウェイトを共有するという点にある。

従来のアーキテクチャでは、エンコーダはLLM本体と独立したモジュールとして存在するため、ファインチューニング時には「どの部分を更新するか」という判断が常に必要になる。エンコーダを凍結してLLMだけ更新するのか、端から端まで全体を更新するのか。それぞれにトレードオフがある。

Gemma 4 12Bではこの問題が原理的に存在しない。入力がテキストであれ画像パッチであれ音声フレームであれ、LLMに到達した後は全て同一の変換を受ける。ドメイン固有データでファインチューニングする際も、調整対象は一つのモデルだけでよい（Google Developers Blog, 2026）。Unslothなどの効率的ファインチューニングフレームワークへの対応がこのモデルで明示的に謳われているのは、この統一性があってこそ意味を持つ。

設計の合理性は買える、では実機ではどうか

ここまで紹介した設計思想は理にかなっている。問題は、ローカル環境でそれが約束通りに動くかどうかだ。RTX 5090 (Blackwell sm_120) + WSL2 + llama.cpp という、典型的なエッジ寄りの構成で同日に追試した。結果から先に言うと、テキストは部分的に動き、画像と音声は動かなかった。

テキスト推論——量子化二段で検証

ggml-org公式GGUFリポジトリから二種類の量子化版をダウンロードした。

• Q4_K_M（7.4 GB）：decode 110 t/s。標準的な実用解。

• Q8_0（12.7 GB）：decode 85 t/s。近似無損失の参考点。

decode速度はQwen3.6-35B-A3B（MoE 35B、MTPあり）の207 t/sと比較すると半分以下である。Gemma 4 12BはDenseモデルであり、毎トークン全パラメータを読み出すため、12Bという小規模にもかかわらず35BのMoE（実効A3B、トークンあたり3Bのみ活性）に対してメモリ帯域上不利になる。これはアーキテクチャ的に予期される結果だった。

問題はその先にあった。日本語での簡単な質問に対し、どちらの量子化でも一貫して誤答が発生する。

[Q] 日本の首都の名前を一語だけ答えて。
[A Q8_0] 佐渡
[A Q4_K_M] 淡島

「首都」が「島」に取り違えられている。一回限りのハルシネーションではない。Q4_K_Mで複数回試行しても「淡島」「離島」のように島の名前が返り、Q8_0で同じ問いを繰り返しても「佐渡」あるいは島嶼関連の単語に着地する。量子化ノイズが原因なら品質を上げれば改善するはずだが、近似無損失と言われるQ8_0でも同じ症状が出る以上、これはモデル自身が「日本の首都」というトークン列を島嶼の概念にマップしているとしか考えられない。

念のため対照実験として、英語で同じ質問をすると正常に答える。

[Q] What is the capital of Japan? Answer in Japanese, one word only.
[A] 東京

日本語そのものが壊れているわけではない。「日本で一番高い山は？」には「富士山」と正しく返るし、英文の和訳「The cat is sleeping on the table.」も「猫はテーブルの上で眠っています。」と自然な日本語で出力できる。特定の概念ペア（首都⇔島）に学習データ由来のバイアスが固着しているように見える。

12B Denseでメモリ効率が高く、英語の品質が高いことは確認できた。一方で日本語の事実関係は信用してはいけない、というのが実機での当面の結論である。これがGemma 4ファミリ共通の癖なのか、12Bだけの問題なのか、4 26B MoE版で改善するのかは現時点で確かめる手段がない。

画像と音声——llama.cppではロードできない

ここからが本題だ。Google Developers Blogでは「llama.cpp、MLX、SGLang、vLLM、Hugging Face Transformersに即日対応」と発表されている（Google Developers Blog, 2026）。しかし当日にllama.cppへ流し込もうとすると、SIGFPE（浮動小数点例外）で起動すらしない。

Thread 1 "llama-server" received signal SIGFPE
clip.cpp:250 d_head(n_embd / n_head)   ← n_head=0 で 0除算
clip_graph_gemma4uv::clip_graph_gemma4uv  ← 統合プロジェクタ初期化中

我々の環境固有の問題ではない。同じスタックトレースを伴うバグ報告がllama.cppリポジトリで既に立っており（Issue #24085）、コミット 166fe2949 時点で未修正のままだった。再現条件は単純で、ggml-orgが公開しているmmprojファイル `mmproj-gemma-4-12B-it-Q8_0.gguf` を一緒にロードしようとすると、その時点で死ぬ。テキストだけで起動すれば動くが、それでは画像も音声も使えない。

原因の見当はついている。Gemma 4 のmmprojは画像と音声を統合した新形式（プロジェクタ種別 `gemma4uv`）で配布されており、画像専用 `gemma4v` や音声専用 `gemma4a` の分離版はHugging Face上に存在しない。一方llama.cpp側は `gemma4uv` への対応コードが入ったばかりで、隠れ次元・ヘッド数といったハイパーパラメータの読み出しキーが揃っておらず、`n_head = 0` のまま `n_embd / n_head` を計算してしまう。

検証のため、Macで音声ファイル（16kHz mono WAV、Kyoko音声合成によるサンプル）を3本生成し、OpenAI互換の `input_audio` フィールドでサーバに投げる準備までは整えた。しかしロード段階で死ぬため、一文字も認識結果は得られていない。テキストだけのモデルとしてなら使えるが、その場合「Gemma 4」を選ぶ価値の大半は消える。

なぜ発表と実機の間に距離が生まれたか

公開直後のモデルで「主要フレームワーク即日対応」という文言が躍るのは珍しくない。だがそれが実機で何を意味するかは、毎回検証しないと判らない。

今回のケースで言えば、ggml-orgの推論フレームワーク側でPRがマージされコードパスが追加されたという事実と、利用者が実際にロードできるという事実の間にギャップがあった。新規プロジェクタ種別の登録は済んでいても、対応するハイパーパラメータをGGUFから読み出す部分が抜けている。発表時点でその不整合に気づける形のテストが、CIに組み込まれていなかったことになる。

別の角度からは、配布形式の選択も影響している。`gemma4uv` という「統合mmproj」のみを配布する戦略は、画像・音声を同じ抽象で扱うアーキテクチャ哲学と整合してはいるが、フレームワーク側に新しいプロジェクタ種別の完全実装を強いる。`gemma4v` と `gemma4a` を別ファイルとして並行提供していれば、画像だけ・音声だけでも先に動かす余地があったが、現状はオール・オア・ナッシングである。

これは設計の良し悪しではなく、リリースに対するQAの粒度の話だ。「主要フレームワークで動く」と言うときに、テキスト推論だけを指すのか、それとも本来のセールスポイントであるマルチモーダル経路まで含むのか。Google側が前者で済ませているとは思いたくないが、実機で確認できるのは前者だけだった、というのが今日時点の状況である。

開発者が使えるまでの距離

公開されたモデルはApache 2.0ライセンスで提供され、Hugging FaceとKaggleからウェイトを取得できる。LM StudioやOllama、LiteRT-LMなど代替の経路を選べばマルチモーダル機能の一部は動く可能性があるが、llama.cpp直結のローカルサーバ運用を主軸にしている環境では、当面はテキスト推論のみが現実的な使い道になる。

実用シナリオの例として、Gemma 4 12B自体がllama.cpp経由でローカル実行され、Gemma Skillsリポジトリを用いてGradioアプリを生成するというデモも公開されている（Google Developers Blog, 2026）。エージェント的な利用様式は魅力的だが、画像と音声のロードが通らない以上、当該デモはマルチモーダル抜きの構成でしか試せない。Issue #24085がクローズされ、修正版を含むllama.cppリリースが出るまで、本番採用は留保するのが安全である。

我々の運用方針も変わらなかった。日常の対話・コード編集・長文要約はQwen3.6-35B-A3B（MoE、MTPあり、Q4_K_XL量子化）でカバーし、Gemma 4 12Bは「画像・音声経路がllama.cppで通るようになった時点で再評価する」という棚上げ状態に置く。20GB弱のディスクは消費するが、Issue #24085 を定期的に確認するためにモデルファイルは残してある。

設計選択が示す方向性

Gemmaシリーズはすでに累計1.5億回以上ダウンロードされている（Google Blog, 2026）。その上で4 12Bが選んだのは、規模の拡大よりも構造の簡素化という方向だった。

エンコーダを削ることの意義は、性能向上だけにとどまらない。モダリティの追加コストが下がるという点が大きい。従来は新しいモダリティへの対応ごとに専用エンコーダの設計・学習・統合が必要だったが、線形投影一層で接続できるなら、そのコストは大幅に下がる。テキスト・画像・音声を同一の抽象レイヤーで扱う設計は、将来的なモダリティ追加への構造的な備えともなる。

もう一つの軸は、ローカル推論の現実性だ。クラウドAPIへのアクセスを前提としない、エッジで動くマルチモーダルエージェントの実現は、プライバシー保護やオフライン動作が求められる用途において意味を持つ。Gemma 4 12Bのアーキテクチャは、そのためにエンコーダを削る合理性があると判断したものとみられる。

ただし、ここまでの実測が示すのは、設計の合理性が即座に「使える」につながるわけではないということでもある。エンコーダを捨てたことで何を得たか——処理の一貫性、ファインチューニングの簡潔さ、メモリ効率、そしてラップトップで動く可能性。失ったものとしては、ドメイン特化の視覚・音声表現が挙げられるが、それをLLMの汎用表現能力がどこまで補えるかは、まずロードが通ってから議論できる話だ。

「動くようになったら触り直す価値はある」。それが、公開当日に試した側からの率直な結論である。

検証環境

• GPU: NVIDIA RTX 5090 (Blackwell sm_120, VRAM 32GB)

• OS: WSL2 (Ubuntu) on Windows 11

• 推論エンジン: llama.cpp commit 166fe2949（upstream master、本記事の検証時点）

• モデル: `ggml-org/gemma-4-12B-it-GGUF` Q4_K_M / Q8_0、`mmproj-gemma-4-12B-it-Q8_0.gguf`

• 比較基準: `Qwen3.6-35B-A3B-UD-Q4_K_XL.gguf`（MoE、MTPドラフタあり）

参考

• Google Blog (2026)「Gemma 4 12B 公開アナウンス」

• Google Developers Blog (2026)「Gemma 4 12B: The Developer Guide」

• Maarten Grootendorst (2026)「Gemma 4 12B Architecture Deep Dive」

• llama.cpp Issue #24085「Eval bug: gemma-4-12B-it-GGUF crashes with Floating point exception」