Gemma 4 把多模態收進一個 backbone——encoder-free 與 QAT 一起上桌

Google 釋出的 Gemma 4 12B 是一個 11.95B 參數、decoder-only 的密集模型，真正的結構新聞不是參數量，而是它把影像與音訊的處理路徑從「獨立 encoder + projector」改成 encoder-free——所有 modality 在很淺的一層就被 tokenize 成跟文字共用的 embedding，之後完全由同一個 backbone 處理。同時 Google 同步釋出了 QAT（quantization-aware training）版本，把這個 12B 模型壓到能在 16 GB 記憶體的筆電、甚至手機上跑本地 agentic workflow。這篇拆四件事：encoder-free 的 token 化怎麼做、它相對於傳統 vision-encoder 路線的取捨在哪、QAT 為什麼能在低位元下守住品質、以及這對本地部署實際意味著什麼。先看這個 12B 在各條評測軸上落在哪裡——因為「拆掉 encoder 會不會掉品質」是讀者第一個會問的問題。

click a bar to read what that axis measures · 6 axes

點任一長條讀那條軸測的是什麼——六條軸由高到低排，最右的 MRCR v2 是長文脈軸。

讀這張圖的方式不是看絕對高低，而是看軸與軸之間的落差。GPQA Diamond 78.8%、AIME 2026 77.5%、MMLU Pro 77.2% 這幾條 hard-reasoning 軸都在 77% 以上，對一個 12B 密集模型是相當前段的數字；LiveCodeBench v6 72.0% 的 coding 也站得住。關鍵在 MMMU Pro 69.1%——這是多模態（影像＋文字）的大學等級推理，如果 encoder-free 真的會傷害視覺理解，這條軸應該塌掉，但它只比純文字軸低 8 個百分點，落在「多模態本來就比純文字難」的合理範圍內。

唯一明顯偏低的 MRCR v2 43.4% 是 256K 長文脈的多目標檢索，那是 12B 量級在超長 context 上的已知天花板，跟 encoder-free 沒有因果關係。MRCR（Multi-Round Co-reference Resolution）這類測試刻意在很長的上下文裡塞入多個相互指涉的目標，逼模型在 needle-in-haystack 之上再做指代消解——12B 的 attention 容量在 256K token 的尺度上本來就會稀釋，這條軸對任何同量級模型都偏低。把它跟視覺軸混為一談會誤判 encoder-free 的代價。

還有一個容易忽略的對照點：AIME 2026 的 77.5% 是「no tools」的純推理數字——不准呼叫 code interpreter、不准外部計算。對一個能塞進筆電的 12B 模型，在不借工具的前提下解到接近八成競賽數學題，本身就說明 instruction-tuning 把 reasoning 收斂得相當紮實。換句話說，這張圖真正想講的不是「Gemma 4 多強」，而是「拆掉 vision encoder 沒有在任何一條軸上留下可歸因的傷口」。接下來看這個「拆掉」具體拆掉了什麼。

encoder-free：三種 modality 投影進同一個 backbone

傳統的 vision-language 模型走的是「encoder + projector」兩段式：影像先過一座獨立、通常凍結的 vision encoder（CLIP-style 的 ViT，幾億參數、幾十層 transformer），輸出一串視覺特徵，再經一個 projector（MLP 或 cross-attention）把特徵維度對齊到 LLM 的 hidden dimension，最後才餵進語言模型。Gemma 4 自家的中型版本就是這條路——27 層的 vision transformer；audio 版本（E2B / E4B）還另外掛了 12 層 conformer。這套設計的問題是：encoder 是獨立訓練、通常凍結的，跟 LLM backbone 之間隔著一道 projector，fine-tune 時你只能調 projector 或解凍部分 encoder，整個多模態的學習訊號被切成兩段。

Gemma 4 12B 的 encoder-free 路線把這道牆拆了。影像不再過 ViT——原始影像切成 48×48 的 pixel patch，每個 patch 用「一個 matmul」直接投影到 LLM 的 hidden dimension；負責這件事的 vision embedder 只有 35M 參數，相對於一座完整 ViT 是兩個數量級的縮減。一座 CLIP-style 的 ViT 動輒三億到十億參數、幾十層 self-attention，這裡換成的是一個單層線性投影加一張查表——這就是「embedder」與「encoder」的字面差別：embedder 只把輸入映射到向量空間，不在內部做多層特徵抽取。

空間位置資訊的處理也跟著簡化。傳統 ViT 用一整套 learned positional embedding 或 2D rotary 去編碼每個 patch 的位置；Gemma 4 用的是「factorized coordinate lookup」——X 與 Y 兩個獨立的座標矩陣，給每個 patch 各自查 row 座標與 column 座標再相加。好處是參數量隨「邊長」線性成長而非隨「patch 總數」平方成長：一張 32×32 patch 的圖只需要 32 個 X 向量加 32 個 Y 向量，而不是 1024 個獨立的 2D position 向量。這也讓變解析度變得自然——換一個解析度只是換一組座標索引範圍，不需要重新內插 position table。

Audio 更直接：16 kHz 的波形切成 40 ms 的 frame（每個 frame 640 個 float，正好是 16000 × 0.04），線性投影進 backbone，完全跳過那 12 層 conformer。Gemma 4 自家的 audio 版本 E2B / E4B 仍掛著 conformer 堆疊去做時序特徵抽取；12B 這版直接把「原始波形 → 線性層 → token」一步到位，把時序建模的責任也丟回 backbone 的 self-attention。三種 modality 投影完之後就是同一種東西——一串送進同一個 backbone 的 token，沒有任何 modality-specific 的多層子網路橫亙在中間。

把這串數字攤成一張表，對照就跳出來：負責全部視覺輸入的 embedder 只有 35M，相對於 11.95B 的 backbone 連 0.3% 都不到——這就是「embedder 不是 encoder」在帳面上的意思。點欄頭依「佔總參數」排序，看 encoder-free 把多模態前端壓得多薄：

click a column header to sort · 5 rows

結構元件	負責	參數量	佔總參數
LLM backbone	語言＋多模態推理	≈ 11.95B	≈ 99.7%
vision embedder	影像 48×48 patch 投影	35M	≈ 0.29%
audio 線性投影	40ms frame 投影	< 一層線性	微乎其微
傳統 ViT（對照）	被拆掉的視覺 encoder	300M–1B＋	不在 12B 內
傳統 conformer（對照）	被拆掉的音訊 encoder	12 層堆疊	不在 12B 內

把 encoder 拆掉的好處不只是省參數。Google 在 developer guide 裡點出的工程後果是：你「不再需要 co-tune 兩座凍結的 encoder」。在 encoder + projector 的世界裡，下游 fine-tune 是一件麻煩事——encoder 的權重該不該動、projector 要訓多久、語言模型那端能不能跟著調，每一個都是 hyperparameter。實務上多數團隊選擇凍結 encoder、只訓 projector，因為解凍 encoder 很容易在小資料集上 catastrophic forgetting，把 CLIP 預訓練的視覺先驗給洗掉；但凍結又意味著視覺特徵空間是固定的，無法為你的領域（醫療影像、衛星圖、UI 截圖）重新對齊。這是一個沒有好答案的取捨。

encoder-free 之後，這個取捨消失了。LoRA 或 full fine-tune 一次 backward pass 就更新了整條「投影 + backbone」的 token loop——影像怎麼被理解、文字怎麼接續、輸出怎麼生成，全部在同一個 gradient 裡共同優化。你不必再決定「解凍幾層 encoder」，因為根本沒有 encoder；視覺投影層跟語言層在同一個 optimizer step 裡一起被 loss 拉動。對要拿 Gemma 4 去 fine-tune 自家多模態任務的團隊，這是「兩個 optimizer、兩套 learning rate、一道 projector 的梯度斷層」變成「一條連續的 token loop」的差別。Gemma 4 走 Apache 2.0 授權，full fine-tune 與商用都沒有授權層面的阻礙，這個簡化才有實際意義。

那代價在哪？傳統 vision encoder 的存在不是冗餘——CLIP-style 的 ViT 是在數十億影像-文字對上對比學習出來的，它把「視覺語意」預先壓進一個很好的特徵空間，LLM 只要學會「讀」這個空間就好。encoder-free 等於要求 backbone 自己從 48×48 patch 的原始投影裡長出視覺理解，沒有預訓練好的視覺特徵當拐杖。這是一個真實的賭注，不是免費的午餐。

這條路能成立，靠的是兩個前提。其一，backbone 本身夠大——12B 的容量足以在預訓練裡同時長出語言能力與視覺理解，這在 1B、2B 量級可能就撐不住，這也是為什麼 encoder-free 的激進版本先出現在中大型模型上。其二，預訓練資料裡影像夠多：Gemma 4 的訓練資料明確包含影像，跨 140 多種語言的 web 文件、程式碼、數學，cutoff 2025 年 1 月。沒有足量的影像-文字共現，backbone 學不出 CLIP 那種視覺語意對齊。

換句話說，encoder-free 是「把視覺學習的負擔從專用 encoder 轉嫁到 backbone」的賭注——你用 backbone 的容量與預訓練資料，去換掉一座外掛 encoder 的參數與工程複雜度。MMMU Pro 69.1% 說明在 12B 這個量級，這個賭注付得起：視覺軸只比純文字軸低 8 個百分點，沒有出現「拆掉 encoder 就崩盤」的災難。下面把兩條路線並排，拖動分隔線看 encoder-free 到底刪掉了 pipeline 的哪幾段。

drag the divider · left = encoder+projector, right = encoder-free

變解析度 token 預算：一張圖值多少 token

encoder-free 還改變了一件容易被忽略的事——影像消耗多少 token，是可變的。model card 寫得很明確：image 採變解析度，token 預算落在 70 到 1120 之間；audio 最長 30 秒；video 最長 60 秒、以 1 fps 取樣。這幾個數字直接決定你的多模態 prompt 會吃掉多少 context。一段 60 秒的影片就是 60 個 frame，每個 frame 又按影像複雜度展開成 70–1120 個 token——最壞情況一段短片可以輕鬆吃掉幾萬個 token。好在 backbone 的 context window 是 256K，加上 1024 的 sliding window 機制，這個預算撐得住，但「丟一段影片進去」在 token 計費上絕不是免費的。

把三種 modality 的限制並排看更清楚——下表把每條路徑的輸入單位、token 預算、長度上限、以及 encoder-free 拆掉了多少「前端」攤開。點欄頭可依該欄排序：

click a column header to sort · 4 rows

modality	輸入單位	token / 單位	長度上限	傳統前端（已拆）
text	subword	1	256K context	tokenizer（保留）
image	48×48 patch	70–1120	變解析度	27 層 ViT → 35M embedder
audio	40 ms frame	1	≤ 30 s	12 層 conformer → 線性投影
video	frame @ 1 fps	70–1120 / frame	≤ 60 s（60 frame）	同 image 路徑

變解析度的設計呼應 encoder-free 的本質：既然影像只是「patch 投影成 token」，那一張資訊量低的圖（大片留白、單色背景）就該用少一點 patch、少一點 token；一張密集的圖（文件掃描、圖表）就值得多花 token。傳統 ViT 通常是固定 patch 數（一張圖固定 256 或 576 個 visual token），不管圖裡有沒有東西。encoder-free 把 token 預算變成一個可以隨內容調整的旋鈕。

這對本地部署特別有意義，因為 KV cache 的大小直接正比於 token 數。一段多模態 prompt 在筆電上要跟 12B 的權重、加上整段對話歷史的 KV cache 共擠 16 GB 記憶體——每張圖多花的幾百個 token，都會在 KV cache 上等比例放大。在資料中心，這只是 token 計費的差別；在筆電上，這直接決定你能不能在記憶體用罄之前跑完一個多輪 agent。一張省下來的圖等於省下來的 GB。256K 的 context window 與 1024 的 sliding window 在這裡互補：sliding window 讓注意力的計算成本不隨 context 線性爆炸，256K 的上限則給長對話與長文件留出空間。

token 預算的另一個含義是計費可預測性差。固定 patch 數的模型，你可以事先算出「一張圖 = N token」；變解析度模型的 70–1120 區間意味著同一張圖在不同解析度設定下成本可以差到 16 倍。要做容量規劃的團隊得實測自己的影像分佈落在這個區間的哪裡，不能用單一常數估算。下面這個旋鈕讓你直接感受這件事——拖動「每張圖 token」與「張數／影格數」，看一個多模態 prompt 在 256K context 上吃掉多少：

採樣設定上 Gemma 4 12B-it 給的預設是 temperature 1.0、top_p 0.95、top_k 64，跨所有用途統一——這跟很多模型「不同任務調不同溫度」的習慣不一樣，也是 instruction-tuned 模型已經把行為收斂得夠好的訊號。prompt 格式延續 Gemma 系列的 turn 標記慣例，tokenizer 是 262K 詞表的大 vocab（涵蓋 140 多種語言所需的 subword 覆蓋）。多模態 token 直接內嵌在文字 turn 裡，不需要另一條 API 通道——這又是 encoder-free 的副產品：影像跟文字本來就是同一串 token，自然就在同一個 turn 裡。在 Transformers 裡這代表你用同一個 processor 把圖跟字一起餵，不必再維護一條獨立的 image preprocessing pipeline。

QAT：把量化放進訓練 loop，而不是事後

第二條新聞線是 QAT。一個 11.95B、BF16 的模型權重大約 24 GB（每參數 2 bytes），要塞進 16 GB 記憶體的筆電必須量化。最常見的做法是 PTQ（post-training quantization）——模型訓練完成後，把 FP16 權重事後映射到 int4 / int8 的低位元表示。PTQ 快、不需要重訓，但它的問題是模型在訓練時從不知道自己將被量化，低位元帶來的 rounding error 是訓練後才硬塞進去的擾動，位元數越低（特別是到 4-bit 以下）品質掉得越明顯。

位元數與權重足跡之間是一條乾淨的正比線：11.95B 參數乘每參數 bit 數、除以 8 就是純權重的 byte 數。BF16 的 2 bytes 給出約 24 GB，正好塞不進 16 GB。拖這個旋鈕，看足跡怎麼隨位元數縮放、在哪個位元數才跌進 16 GB 的筆電包絡：

這條正比線解釋了 QAT 為什麼非做不可：4-bit 把 24 GB 砍到約 6 GB，是把 12B 搬上筆電的唯一辦法，但 4-bit 以下的 PTQ 會崩。掉品質的機制具體是這樣：權重分佈裡有少數 outlier，把整個 quantization range 撐大，於是大多數靠近零的權重被擠進很粗的網格格子裡，rounding error 累積起來在多層之後放大成可見的 perplexity 上升。PTQ 只能事後用 per-channel scale、outlier 隔離這類技巧補救，但補救的空間有限——因為模型的權重分佈是在「以為自己是 FP16」的前提下訓出來的，本來就沒有為量化做任何讓步。

QAT 反過來：把量化這件事直接放進訓練 loop。前向傳播時模擬低位元的 rounding（fake quantization）——權重先被 round 到目標網格、再 round 回 FP 去算 loss，所以 loss 看到的就是「量化後的權重」會犯的錯。反向傳播則用 straight-through estimator 繞過量化算子不可微的問題：round 這個操作的梯度幾乎處處為零，STE 直接假裝它是 identity、讓梯度照常穿過去更新 FP 主權重。結果是模型在訓練過程中就學會「在量化網格上也要表現好」——它會主動把權重分佈往對量化友善的方向擠，壓掉那些會撐大 range 的 outlier。

Google 的說法是 QAT 的整體品質甚至高過標準 PTQ baseline——這個「高過」不是廢話：它意味著 QAT 4-bit 模型不只是「比 PTQ 4-bit 好」，而是在某些評測上接近原始 FP16 的水準，等於把 4-bit 的記憶體紅利幾乎免費拿到。對 Gemma 4 這代，QAT checkpoint 涵蓋 E2B、E4B、12B 與 26B MoE 全系列——不是只給最小的 edge 模型，連 26B 的 MoE 都有 QAT 版。下面三個分頁拆開 QAT 釋出的三種量化 schema——它們不是同一種 4-bit，而是按部署目標分裂的。

三種 schema 的共同邏輯是「不是所有東西都該用同一個位元數」。Q4_0 是統一網格的省事版；mobile 的混合精度承認「生成層耐壓、推理層敏感」，把 2-bit 留給扛得住的層、把精度留給扛不住的層；記憶體足跡那一面則說明這一切的終點——把 12B 壓進 16 GB、把 E2B 壓進 1 GB 以下。

mobile schema 的「按層分配」值得多看一眼，因為它跟 QAT 是相互依存的。你不可能對一個 PTQ 模型做 2-bit 的生成層——2-bit 只有四個量化階，事後硬壓必然崩。但 QAT 在訓練裡就讓那些層適應 2-bit 網格，配合 static activation 預計算（把 activation 的量化 scale 預先固定，避免 runtime 動態求 range）與 channel-wise 量化（每個輸出通道一組獨立 scale，吸收通道間的數值差異），2-bit 才有機會站住。embedding 與 KV cache 也一起被優化，因為在手機上這兩者佔的記憶體比例不容忽視——一個大 vocab 的 embedding table 本身就是好幾 GB。

QAT 之所以能撐住這種激進的位元分配，正是因為「量化網格在訓練時就在 loss 裡」——模型不是被動接受量化，而是主動學會在量化下生存。這也是為什麼 Google 願意把 2-bit 這種在 PTQ 世界近乎禁忌的位元數，放進正式釋出的 mobile checkpoint。

本地 agentic：LiteRT-LM 與 drop-in server

QAT 把 12B 壓進 16 GB 之後，真正的應用面是本地 agentic workflow。Google 這一側的入口是 Google AI Edge 與 LiteRT-LM。LiteRT-LM 被描述成一個「lightweight、zero-code」的本地語言模型執行工具——你不寫推論程式碼，直接跑 CLI 把模型起起來。模型以 litert-community/gemma-4-12B-it-litert-lm 的形式發布，針對 LiteRT runtime 做了優化。配套的還有 Google AI Edge Gallery（本地 AI 展示 app，現已上 macOS）與 Eloquent（100% 端上跑的語音聽寫與編輯 app）。

除了 LiteRT 這條 Google 自家路線，Gemma 4 在開放生態裡的入口也鋪得很齊：inference 與 fine-tune 支援 Hugging Face Transformers、llama.cpp、MLX、SGLang、vLLM 與 Unsloth。這份清單本身就是訊號——llama.cpp 與 MLX 是筆電本地推論的兩大主力（前者跨平台、後者吃 Apple Silicon 的 unified memory），SGLang 與 vLLM 是資料中心 serving，Unsloth 則是低資源 fine-tune。同一個 Apache 2.0 模型在這六個 runtime 上都能跑，意味著「筆電原型 → 資料中心量產」可以是同一份權重的不同載入路徑。

對工程上最有意思的是 LiteRT-LM 的 serve 模式——它把本地模型包成一個 drop-in 的本地 LLM server，講 OpenAI 相容的 chat completions 協定。換句話說，你既有的工具鏈（Continue、Aider 這類編輯器外掛，或任何打 /v1/chat/completions 的 SDK）只要把 endpoint 指到 localhost 就能換成本地 Gemma 4，不用改程式碼。「zero-code」在這裡是字面意思：你不寫一行 Python，CLI 起 server、client 照舊打 HTTP。

# LiteRT-LM 起一個本地 OpenAI 相容 server
litert-lm serve litert-community/gemma-4-12B-it-litert-lm \
          --port 9379

# 任何 OpenAI 相容 client 直接打 localhost——包含多模態 turn
curl http://localhost:9379/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
        "model": "gemma-4-12B-it",
        "messages": [
          {"role": "user", "content": "把這張截圖裡的表格轉成 CSV"}
        ]
      }'

把這幾件事接起來看，本地 agentic 的價值就清楚了：encoder-free 讓影像、音訊跟文字共用同一串 token、同一個 turn，所以一個本地 agent 可以「看截圖、聽語音命令、讀文件、寫程式」全在一個模型裡，不需要再串接一座外部 vision API；QAT 讓這個 12B 在筆電的 16 GB 包絡裡跑得動，所以這些 token 完全不離開本機；drop-in server 讓既有的 agent 框架（程式碼裡寫的還是 OpenAI client）一行 endpoint 就切過來。能力清單裡列的 automatic speech recognition、diarization、video understanding、agentic reasoning、coding——全部是同一個 backbone 的輸出口，不是五個拼接的子系統。

當然有現實的邊界要記住。MRCR v2 的 43.4% 提醒：12B 在 256K 長文脈的多目標檢索上不強，本地 agent 如果要在超長上下文裡精準翻找（例如讓 agent 讀完整個 codebase 再回答跨檔案問題），這條軸會是瓶頸——你可能還是得靠 retrieval 把相關片段先撈出來，而不是把全部塞進 context。

混合精度的 mobile schema 也意味著手機版跟筆電的 Q4_0 版不是同一份權重，行為會有差異——那 2-bit 的生成層在某些任務上會比 4-bit 版更容易在邊角案例失準。做端上部署前要實測自己的任務，不能假設 benchmark 數字（那是在 BF16 上跑的）直接搬得到量化版上，更不能假設 4-bit 版的數字搬得到 2-bit mobile 版上。每降一個位元都要重新量一次自己的關鍵指標。

還有 encoder-free 自身的尾巴：把視覺學習負擔轉嫁給 backbone，代價是這個能力跟 backbone 的規模綁死。你不能像換 vision encoder 那樣，獨立升級視覺前端而不動語言模型——視覺與語言在同一個 token loop 裡，要強化視覺就得重訓整個 backbone。對想針對特定視覺領域深度客製的團隊，這是 encoder-free 真正的 trade-off：簡化了 fine-tune 的工程，但拿走了「模組化替換視覺前端」的彈性。

但這些都是 deployment 的調校問題，不動搖核心：Gemma 4 12B 把「多模態理解」這件事從「LLM 外掛一座 encoder」收回成「LLM 自己的一層淺投影」，再用 QAT 把整包搬上筆電。這兩件事在同一次釋出裡出現不是巧合——encoder-free 讓模型結構足夠精簡到值得做 QAT，QAT 又讓這個精簡後的多模態模型真的進得了 16 GB 的記憶體包絡。

What this enables：把 vision／audio 的理解收進 backbone 自身的 token loop、再用 QAT 壓進 16 GB，意味著一個能看截圖、聽語音、讀文件、寫程式的多模態 agent 可以完全跑在你的筆電上、講 OpenAI 相容協定、token 一個都不離開本機。