多模態瓶頸不在參數量：Gemma 4 12B 的 encoder-free 路線訊號

過去兩年，多模態模型的標準做法是：用獨立的視覺與音訊 encoder 先把圖像或聲音轉成 embedding，再餵給語言模型主幹。這套架構能力有了，但代價清楚：兩套模型同時佔記憶體，延遲疊加，端側部署的門檻壓不下來。

Gemma 4 12B 直接拿掉了這個假設。

視覺端不再用獨立 encoder，而是換成由單次矩陣乘法加位置嵌入組成的輕量模組，讓視覺輸入直接流入 LLM backbone；音訊同樣繞過獨立編碼器。官方說明這是 Gemma 系列中型規格首次加入原生音訊輸入。整個處理路徑少了一個完整的神經網路，記憶體佔用與推理延遲都跟著降下來。

結果是：12B 參數跑在 16GB VRAM 的筆電上，基準測試效能逼近 26B 的 MoE（Mixture of Experts，混合專家）版本，並附上 MTP（Multi-Token Prediction，多符號預測）drafter，可在推理時進一步降低延遲。授權是 Apache 2.0，商用無限制。

encoder-free 的關鍵取捨值得細想：拿掉專用感知模組，是把理解原始感知輸入的責任全壓到語言模型主幹。這意味著模型必須在訓練期就學會從輕量 embedding 中提取語義，而不是依賴 encoder 預先整理好的特徵空間。Gemma 4 12B 的基準數字說它做到了，但遷移到特定垂直場景時，感知品質是否打折，仍值得實測確認。

對在跑端側 agentic 應用的工程師，這個架構選擇是一個明確的路線訊號：多模態的部署瓶頸，比較可能卡在架構設計，而不是純粹的參數規模。如果你的 pipeline 還帶著獨立的視覺或音訊 encoder，值得評估它是否真的必要，還是慣性保留。16GB 能跑的多模態 agent，代表普通開發筆電就能本地測試完整 pipeline，省掉雲端推理費用，也降低資料外送的合規風險。

Apache 2.0 加上內建 MTP drafter，意味著你能自由 fine-tune、商用部署，並在 speculative decoding 框架下直接壓推理延遲，不需要額外搭一個小模型。這些是省掉整合工時的實際工程紅利，不是加分項。