Gemma 4 12B UnifiedがVision Encoder 16層を行列積1回に置き換えたencoder-free設計

Gemma 4 12B Unifiedは、同ファミリーのE2B/E4B/31Bと違って、Vision EncoderもAudio Encoderも持っていない。
E4Bでは150Mパラメータ・16層Transformerだった画像処理が、12B Unifiedでは35Mの線形投影1回に変わっている。
画像パッチ間の特徴抽出は、LLM本体48層の双方向アテンションが吸収する構成になった。

Adept Fuyu（2023年）やEVE（NeurIPS 2024）で研究されてきたencoder-free VLMの設計だが、それぞれ別の問題を抱えていた。
Gemma 4 12B Unifiedがどこを残してどこを変えたのか、先行研究の知見を軸に追う。

E4Bの画像処理

E4Bは画像を専用のVision Encoderに通してからLLMへ渡す、CLIP/SigLIPと同じ2段構成。

// E4B Vision Encoder (config.json抜粋)
{
  "hidden_size": 768,
  "num_hidden_layers": 16,
  "num_attention_heads": 12,
  "num_key_value_heads": 12,
  "head_dim": 64,
  "patch_size": 16,
  "pooling_kernel_size": 3,
  "hidden_activation": "gelu_pytorch_tanh"
}

画像はまず16x16ピクセルのパッチに分割され、3x3のプーリングカーネルで間引かれる。
このパッチ列が16層Transformer（hidden_size 768）を通過する。

16層Transformerが担っているのは、パッチ間のセルフアテンションによる特徴抽出。
1層目では局所的なエッジやテクスチャを、後段の層ではパッチをまたいだ物体のパーツや空間関係を構築する。
CLIP ViT-L/14の研究でも確認されている通り、Vision Transformerは前段で低水準の視覚特徴を、後段で高水準の意味的特徴を階層的に積み上げる。
2D RoPEが各パッチにXY座標の位置情報を与え、パッチ同士が空間的な前後左右の関係を保てるようにしている。

この処理に150Mパラメータを使い、出力をprojector層でLLMのembedding空間（2,560次元）へ投影し、テキストトークンと連結してLLMの入力列に流す。
31B Denseだと同じ構成でVision Encoderが約550Mに膨らむ。

12B Unifiedの画像処理

12B Unifiedには16層Transformerがない。
アーキテクチャクラスもGemma4UnifiedForConditionalGenerationで、E4BのGemma4ForConditionalGenerationとは別物。

// 12B Unified Vision Embedder (config.json抜粋)
{
  "model_type": "gemma4_unified_vision",
  "mm_embed_dim": 3840,
  "output_proj_dims": 3840,
  "patch_size": 16,
  "pooling_kernel_size": 3,
  "mm_posemb_size": 1120,
  "num_soft_tokens": 280
}

画像の入口はE4Bと同じで、16x16パッチに分割して3x3プーリングをかけ、48x48ピクセルの実効スーパーパッチにする。
ここから先が違う。

各パッチは48x48x3 = 6,912次元のベクトルになる。
これを[6,912, 3,840]の重み行列1つで線形投影する。パラメータ数は約26.5M。
Transformer層もアテンションもない。各パッチは他のパッチと独立に、生のピクセル値からLLMのhidden space（3,840次元）へ射影される。

投影後にfactorized positional embedding（分離型位置エンコーディング）を加算する。
X軸[1,120, 3,840]とY軸[1,120, 3,840]の2つのルックアップテーブルで、各パッチのXY座標に対応するベクトルを取り出して足す。
パラメータは合計約8.6M。
Qwen2-VLが採用したfactorized RoPEと似た発想で、2D空間の位置情報をXとYに分解して効率よく表現する手法。

LayerNormをかけて、LLMの入力トークン列にそのまま混ぜる。
パラメータ総数は投影行列26.5M + 位置エンコーディング8.6M + LayerNormなどで約35M。
E4Bの150Mの4.3分の1、CLIP ViT-L/14（303M）の8.6分の1。

graph LR
    subgraph encoder["E4B / 31B Dense"]
        A1["16x16パッチ<br/>+ 3x3プーリング"] --> B1["Vision Encoder<br/>16層 Transformer<br/>150M params"]
        B1 --> C1["LLMへ投影"]
    end
    subgraph free["12B Unified"]
        A2["16x16パッチ<br/>+ 3x3プーリング"] --> B2["線形投影<br/>行列積1回<br/>35M params"]
        B2 --> C2["LLMへ直接入力"]
    end

画像トークンの予算

画像トークンの数はnum_soft_tokensで制御される。
デフォルトは280トークンで、70/140/280/560/1,120の5段階を選べる。

ソフトトークン数	プーリング前パッチ数	おおよその画像面積
70	630	約161Kピクセル
140	1,260	約323Kピクセル
280（デフォルト）	2,520	約645Kピクセル
560	5,040	約1.3Mピクセル
1,120	10,080	約2.6Mピクセル

解像度を上げるとトークン消費も増える。
エンコーダを外しても画像入力が無料になるわけではなく、トークン数に応じたKV cacheと計算量はかかる。

線形投影が失うもの、双方向アテンションが補うもの

16層Transformerを線形投影1回に置き換えたとき、何が失われるか。

1つは、パッチ間のセルフアテンション。
E4Bのエンコーダでは16層にわたってパッチ同士が情報をやり取りし、「このパッチの右隣は目、その下は口」のような空間関係を構築する。
線形投影では各パッチが完全に独立で、6,912次元の生ピクセル値から3,840次元のLLM空間へ写像するだけ。
隣のパッチの情報は一切入らない。

もう1つは、視覚特徴の階層的な抽出。
Vision Transformerは層を重ねるごとにエッジ→テクスチャ→物体パーツ→オブジェクト全体と抽象度を上げていく。
線形投影は行列積1回の線形関数で、非線形性も残差接続もない。
生のピクセルパターンからLLMが理解できる表現への変換を、単一の線形写像で済ませている。

12B Unifiedがこの損失を補う仕組みが、use_bidirectional_attention: "vision"で有効化される双方向アテンション。

decoder-only Transformerは通常、因果的マスク（左→右の一方向）でアテンションを計算する。
テキスト生成ではこれが正しいが、画像パッチに因果関係はない。
ラスタスキャン順に並べると、左上のパッチは他のパッチを一切見えず、右下のパッチだけが全パッチを参照できる非対称な状態になる。

12B Unifiedでは、LLM本体48層のアテンション計算で画像トークンの因果マスクを外し、全パッチが全パッチを参照可能にしている。
テキストトークンは通常の因果的マスクのまま。
HuggingFace Transformersの実装では、use_bidirectional_attention: "vision"のとき画像トークンだけ因果マスクが除去され、テキストトークンは左→右の因果マスクを保持する。
"all"に設定すると全トークンが双方向になり、sliding_windowも(sliding_window // 2) + 1に変わる。

Vision Encoderが専用の16層で処理していたパッチ間アテンションを、LLM本体の48層に肩代わりさせている形。
ただしLLMのアテンション層は言語タスクで学習された重みを画像パッチにも使い回すため、専用のVision Encoderと完全に等価ではない。
後述するEVEv2はこの問題に対してQ/K/V投影行列をモダリティごとに分離したが、Gemma 4 12B Unifiedはそこまでの分離をしていない。

ベンチマークでの影響はMMMU Proで確認できる。
12B Unifiedは69.1%で、エンコーダ付きの31B Denseは76.9%。差は約8ポイント。
テキスト側のMMLU Proでも77.2% vs 85.2%で同じく約8ポイント差なので、encoder-free固有のビジョン性能劣化というよりはパラメータ規模の差が支配的に見える。

VLMの空間推論全般については、2025年の「Spatial Blindspot of VLMs」（arXiv:2601.09954）がアーキテクチャを問わず50〜60%程度の正答率にとどまることを報告しており、encoder-freeだけの問題ではない。

音声も同じencoder-free設計

E4Bの音声処理は、12層のconformerエンコーダ（hidden_size 1,024、8ヘッド）で約300Mパラメータ。
128次元のメルスペクトログラムを抽出し、conformer層で処理し、サブサンプリング畳み込みで時間軸を4分の1に圧縮してからLLMへ渡す。

12B Unifiedでは、16kHzの生波形を40ミリ秒フレーム（640サンプル）に切って線形投影する。

// 12B Unified Audio Embedder (config.json抜粋)
{
  "model_type": "gemma4_unified_audio",
  "audio_embed_dim": 640,
  "audio_samples_per_token": 640,
  "hidden_size": 640,
  "output_proj_dims": 640
}

メルスペクトログラム抽出もconformer層もなく、生の振幅値をそのまま投影する。
対応する最大音声長は30秒。
位置情報はLLM本体のRoPEで処理される（1次元の時系列なので、画像のような2軸分離型は不要）。

31B Denseは音声に対応していないので、テキスト+画像+音声の3モダリティを全部扱えるGemma 4は12B Unifiedだけ。

encoder-free VLMの系譜

encoder-free VLMの設計はGemma 4が初ではない。
2023年から複数の研究で試みられ、それぞれ異なる問題にぶつかり、異なる解法を出してきた。

Fuyu-8B（Adept、2023年10月）

最初の実用的なencoder-free VLM。
Persimmon-8B（36層のdecoder-only Transformer）をベースに、30x30ピクセルのパッチをフラット化し、[2,700, 4,096]の線形投影1つでLLMのembedding spaceへ射影する。
投影層のパラメータは約11M。

Fuyuの特徴は、任意の解像度をそのまま扱えたこと。
パッチをラスタスキャン順に並べ、各行の末尾に特殊なimage-newlineトークンを挿入して行の区切りを示す。
画像固有の位置エンコーディングは持たず、LLMの標準的なテキスト位置エンコーディングをそのまま使った。
パッチ間のアテンションも因果的（左→右の一方向）のまま。

ベンチマークではVQA-v2が74.2%と健闘したが、複合推論のMMBenchは10.7%で壊滅している（同時期のLLaVA-1.5は64.3%）。
位置情報をテキスト位置埋め込みに頼り、パッチ間の因果的アテンションしか持たない設計では、空間的な視覚推論に限界があった。

EVE（NeurIPS 2024）と学習の崩壊問題

Fuyuの路線を改良し、encoder-freeの学習を安定させる方法を示した研究。
Vicuna-7Bベースで、PEL（Patch Embedding Layer）とPAL（Patch Aligning Layer）の2つのコンポーネントを追加している。

PELは、stride 14の畳み込み→stride 2の平均プーリング→2段のクロスアテンション（局所受容野 + グローバルCLSトークン）→2層FFNの構成。
各行末に学習可能な<SPL>トークンを挿入して2Dレイアウトを保持する、Fuyuのimage-newlineと同系統の手法。

EVEの中核的な発見は、encoder-freeの学習が段階を踏まないと崩壊すること。

ランダム初期化された投影層は、画像パッチをほぼノイズとしてLLMに送り込む。
LLMのパラメータはテキスト処理用に調整済みなので、ノイズが混入すると画像損失の勾配がテキスト性能を壊し、テキスト損失の勾配が画像適応を妨げる。
この勾配干渉が学習ステップごとに蓄積し、モデル全体が崩壊する。

Stage 1のLLM-guided pre-alignmentでは、LLMの重みを凍結した状態でPELとPALだけを16Mの画像テキストペアで事前学習する。
学習率4e-4、バッチサイズ512、A100x16で約2日。
投影層がLLMのembedding空間にある程度合致してから、Stage 2で初めてLLM本体の重みを解凍する。

このステージを省略した実験がEVE論文のアブレーションにある。
学習データを4Mから8Mに増やしてStage 1を飛ばすと、VQA-v2が64.6%から50.2%へ崩壊した。
データ量を倍にしたのに精度が14ポイント下がっている。
データが増えると勾配ステップも増え、勾配干渉の蓄積が大きくなる。
学習率を2e-5〜1e-3で振っても、凍結ステージなしではどの設定でも安定しなかった。

もう1つの知見がPAL（Patch Aligning Layer）による蒸留。
PALは、投影層の出力を凍結したCLIP ViT-L/14の出力に近づけるMSE損失を学習時にかける。
EVEのTransformer内部からL/4層ごとに特徴を取り出し、CLSやパディングトークンを除去して2D空間配置に整形してから、CLIP出力との距離を最小化する。
推論時にはCLIP ViT-L/14を使わない。学習過程でだけエンコーダの視覚知識を間接的に取り込む構成。
VQA-v2が約3%向上した。

学習は全3ステージ。
Stage 1（pre-alignment、16M、PEL+PALのみ、LLM凍結）→ Stage 2（generative pre-training、33M、全パラメータ）→ Stage 3（SFT、665K〜1.8M、全パラメータ）。
2x 8-A100（40GB）ノードで合計約9日。

最終結果はVQA-v2で75.4%（LLaVA-1.5は78.5%）、MMBenchで49.5%（LLaVA-1.5は64.3%）。
Fuyuの10.7%からは大幅に改善したが、エンコーダ付きとの差はまだ15ポイント残っていた。

EVEv2（ICCV 2025 Highlight）

EVEv2は、LLMのTransformer層内部をモダリティごとに分離するDivide-and-Conquer構成を導入した。

Q/K/V投影行列、出力射影行列、LayerNorm、FFNのすべてについて、視覚トークン用とテキストトークン用の重みを別々に持つ。
計算式で書くと、トークン $x_i$ のモダリティ $u_i \in \{v, t\}$ に応じて $Q_i = x_i W_Q^{(u_i)}$ 、 $K_i = x_i W_K^{(u_i)}$ 、 $V_i = x_i W_V^{(u_i)}$ と射影する。
アテンション計算自体は視覚とテキストが同じ行列を共有するので、クロスモーダルな情報のやり取りは保たれる。
MoEのようなルーティング学習は不要で、モダリティの種類で静的に分岐する。

パッチ埋め込みはstride 16の畳み込み→GELU→stride 2の畳み込みの2段構成で、最大250万ピクセル（約2,500パッチトークン）を処理できる。
蒸留のアプローチもEVEv1から変わり、CLIPからのMSE蒸留を外して、DenseFusion++による高品質な合成キャプションを学習データに使う形に移行した。

学習は4ステージに拡張されている。
Stage 1（パッチ埋め込みのみ、EVE-recap-10M）→ Stage 2.1（パッチ埋め込み+視覚専用層、77M）→ Stage 2.2（全層、5M）→ Stage 3（SFT、7M）。
LLMの凍結期間がEVEv1より長くなっており、Stage 2.1まで視覚系のパラメータだけを動かす。
合計データ量は約1億枚。

7BサイズでMMBench 66.3%、OCRBench 702。
エンコーダ付きのLLaVA-1.6がMMBench 67.4%、OCRBench 532なので、MMBenchでは差が1.1ポイントまで縮まり、OCRではエンコーダ付きを大幅に超えた。

Mono-InternVL（CVPR 2025）

Mono-InternVLは、Transformer層内部に視覚専用のFFNエキスパートを埋め込むアプローチ。
視覚トークンはFFN_v、テキストトークンはFFN_tに静的にルーティングされる。
EVEv2のDivide-and-Conquer構成と発想は近いが、Mono-InternVLはFFNだけを分離し、アテンション側は共有のまま。

学習のスケールが桁違いで、EViP（Endogenous Visual Pre-training）という3段階の事前学習で合計約13億枚の画像を使い、256台のA100で16日間学習している。
EVEの合計約5,000万枚と比べると25倍のデータ量。
事前学習の全フェーズでLLM本体を凍結し、投影層とモダリティ専用FFNだけを鍛え、SFTで初めて全パラメータを解凍する。
実験では、LLMの全パラメータを最初から学習させた設定が最も性能が低かった。
凍結＋デルタチューニングの方がSQA-Iで+18.8%、AI2Dで+16.1%の大差がつき、大量データでもLLMの早期解凍は崩壊するというEVEの知見を裏付けている。

1.8Bサイズでもエンコーダ付きInternVL-1.5-2Bと同等の精度が出ており、encoder-freeが同規模のエンコーダ付きに精度で並んだ最初の実例になった。

12B Unifiedが採った構成

Gemma 4 12B Unifiedの設計は、Fuyuの線形投影をベースに、双方向アテンションとfactorized positional embeddingで補強した形。

E4Bが42層でhidden_size 2,560なのに対し、12B Unifiedは48層でhidden_size 3,840に拡大している。
Vision Encoderが担っていた視覚特徴の抽出をLLM本体に吸収するために、Transformer側を大きくしている。
EVEv2とMono-InternVLが示したように、encoder-freeでエンコーダ付きと同等の精度を出すにはLLM側の容量が要る。

一方で、EVEv2のDivide-and-Conquer（モダリティ別Q/K/V分離）やMono-InternVLの視覚専用FFNエキスパートは採用していない。
LLMの既存の層をそのまま共有し、双方向アテンションだけで補う。
構成としてはFuyu寄りのシンプルさを保っている。

学習パイプラインについては未公開。
Googleは2026年6月時点でGemma 4のTechnical Reportを出しておらず、学習データ、事前整合の有無、エンコーダからの蒸留の有無、アブレーション結果のいずれも不明。
Gemma 3にはarXiv:2503.19786の報告書があり、Gemini 2からの知識蒸留（256ロジットをトークンごとにサンプリング、教師確率で重み付けして交差エントロピー損失）で学習したと記載されていたが、Gemma 4にはそれすらない。
エンコーダ付きバリアント（E4B、31B）が同時にリリースされている以上、Google内部にVision Encoderの学習済み重みがあるのは確実で、EVEのPALと同じ構図で投影層の教師に使える状態にはある。

TTFTとメモリ

encoder-freeにすると、モデルのロード時サイズが小さくなる。
E4BのVision Encoder 150M + Audio Encoder 300M = 450Mパラメータが消え、代わりに35M程度の投影層だけになる。
bfloat16で約800MB、4bit量子化でも約200MBの差。

LLM本体が12Bあるのでロードサイズ全体に対するインパクトは数%だが、Raspberry PiやJetson Nanoのようなメモリの厳しいエッジデバイスでは800MBが無視できない。

TTFT（Time-to-First-Token）への影響は、EVEの論文が実測データを出している。

モデル	Vision FLOPs	Vision処理時間	総推論時間
LLaVA-1.5（CLIP ViT-L）	372G	0.033秒	0.48秒
EVE-7B（encoder-free）	42G	0.003秒	0.48秒
LLaVA-1.6 HD	1,860G	0.13秒	2.07秒
EVE-7B HD	170G	0.013秒	1.52秒

標準解像度ではVision FLOPsが9分の1になっても、総推論時間は両方とも0.48秒で変わらない。
LLM本体のフォワードパスが支配的で、Vision Encoderの0.033秒→0.003秒の差は全体に対して誤差。

差が出るのは高解像度入力。
HD解像度ではLLaVA-1.6のVision FLOPsが1,860Gに膨らみ、EVE-7B HDの170Gと11倍の差になる。
パッチ数が増えるほどVision Encoderの処理コストが非線形に上がるので、高解像度でencoder-freeの優位が出る。
総推論時間も2.07秒→1.52秒と27%短縮。

Mono-InternVLでは、1.8BサイズでTTFTが0.45秒→0.15秒と67%改善した。
小型モデルほどEncoder部分のオーバーヘッドが相対的に大きいため、エッジ向けの小型encoder-freeモデルで最も恩恵がある。

Google公式は12B Unifiedで「最大40%のTTFT改善」としているが、解像度条件やバッチサイズの詳細は公開されていない。

GGUF/llama.cppの対応状況

12B Unifiedは2026年6月2〜3日のリリースから日が浅い。
GGUFファイルはunslothが公開済みで、2-bitの4.21GBからBF16の23.8GBまで19段階の量子化レベルが揃っている。
Q4_K_Mで7.12GB（8GB RAM）、Q8_0で12.7GB（14GB RAM）で動く。

テキスト推論と画像入力は動作している。
画像入力はmmproj-BF16.gguf（946MB）を別途読み込み、llama-mtmd-cli経由で処理する。
音声入力はまだ安定していない。

Gemma4UnifiedForConditionalGenerationはE4BのGemma4ForConditionalGenerationと別のアーキテクチャクラスで、バックエンドごとの対応が必要。
画像トークンの双方向アテンション、生波形の音声入力、可変トークン予算の3点は、バックエンド側で個別に実装しないと通らない。
Gemma 4本体の記事で扱ったE2B/E4B/26B A4B/31Bとはマルチモーダル入力の通し方が根本的に違うので、E4Bが動くからといって12B Unifiedも動くとは限らない。
FastAPI・Chroma・Open WebUIでローカルRAGを組む記事で書いた通り、モデルが画像理解できることと手元のローカルUIで画像を投げて結果が返ることは別の話で、encoder-freeでエンコーダファイルの管理は不要になるが、パッチ化・プーリング・投影・双方向アテンションの処理はバックエンドに組み込まれている必要がある。