Gemma

引言：12B 的參數，26B 的野心 2026 年 6 月 3 日，Google DeepMind 在官方部落格發表了一篇看似平淡卻暗藏殺機的聲明——Gemma 4 12B 正式開源。 這聽起來只是一個數字遊戲：12B 參數、Apache 2.0 授權、16GB VRAM 就能跑。但如果你仔細看它的架構設計和基準測試數據，會發現 Google 在這款「中型」模型上塞進了不少過去只有大模型才有的黑科技。 這篇文章結合 Google 官方技術部落格與社群實測影片，來一次完整拆解：Gemma 4 12B 到底強在哪裡？值得你從 Qwen 2.5 7B 跳槽嗎？ 一、架構革命：去編碼器（Encoder-free）的多模態設計 傳統多模態模型的痛點 大多數多模態大模型（比如早期的 GPT-4V、Claude Vision）都採用「編碼器 + LLM」的雙段式架構： 視覺編碼器（Vision Encoder）先把圖片轉成向量表示 音訊編碼器（Audio Encoder）再把聲音轉成特徵 最後把這些向量餵給語言模型做理解 這個流程的問題很明顯：編碼器佔記憶體、增加延遲、而且每個模態都要單獨訓練一套編碼器。 Gemma 4 的解法：直接丟進 LLM Gemma 4 12B 做了兩件大事： 視覺處理： 用一個極輕量的嵌入模組取代了傳統視覺編碼器——只有一個矩陣乘法、位置嵌入（positional embedding）和正規化。換句話說，圖片被直接投影到跟文字相同的向量空間，然後由 LLM 主幹直接處理視覺資訊。 音訊處理： 更徹底。直接把原始音訊訊號投影到文字 token 的維度空間，完全省掉了音訊編碼器。這也是 Gemma 4 系列第一個內建原生音訊輸入的中型模型。 這種 encoder-free 架構的好處是： 更低的延遲：少了一次編碼器的轉換 更小的記憶體佔用：不用額外儲存編碼器權重 更統一的訓練：所有模態在同一個 LLM 上 jointly train 用 Google 的原話說：「我們讓 LLM backbone 自己接管視覺處理。」 ...

引言：一台「不該跑 AI」的機器 這篇文章是 point.free 上一篇 Gemma 4 系列的最後一篇——前面兩篇講了怎麼把 Gemma 4 的 MTP drafter 量化、怎麼跟 verifier 配對，而這一篇要回答一個更刁鑽的問題： 「把這些成果丟到一台根本沒有資格跑 AI 的機器上，會怎樣？」 作者的硬體規格聽起來像是一台從墳墓裡挖出來的古董： CPU：Intel Xeon E5-2620 v4（2016 年產，約為當前筆電 CPU 的五分之一慢） 記憶體：128 GB DDR3（頻寬只有最新筆電 RAM 的五分之一到六分之一） GPU：無（連內顯都沒有） 換作一般工具，比如 ollama，直接放棄。但這篇文章的作者說：「等等，聽我說完……」 核心問題：記憶体牆（Memory Wall） 要理解這篇文章的精髓，先搞懂一個概念——LLM 推理的瓶頸不在運算能力，而在記憶體頻寬。 當你使用 ChatGPT 看著文字逐字流出時，你看到的是「decoder pass」。在這個階段，處理器要不斷把龐大的模型權重從記憶體拉進 CPU cache 才能計算下一個 token。處理器的運算速度其實很快，但它大部分時間都在等記憶體傳輸——這就叫「記憶體受限」（memory-bound），而非「運算受限」（compute-bound）。 這就是著名的「記憶体牆」問題。不管你用的是 2016 年的 Xeon 還是最新的 H100，這堵牆都在那裡。 所以，直接拿預設參數跑 llama-cli 在 DDR3 機器上會慢到令人發指。解法是什麼？把 ik_llama.cpp 能用的優化選項全部拉滿。 那串「魔法咒語」 作者甩出了一長串 llama-cli 參數，看起來像中世紀巫師的咒語： llama-cli \ --model gemma-4-26B-A4B-it-Q8_0.gguf \ --model-draft wikitext-2-raw_ik-llama-mtp_drafter-conservative/gemma-4-26B-A4B-it-assistant-Q8_0.gguf \ --spec-type mtp --draft-max 3 --draft-p-min 0.0 --spec-autotune \ -cnv --color --jinja --special \ -sm graph -smgs -sas -mea 256 --split-mode-f32 \ --temp 0.7 -t 8 --parallel 8 \ --cpu-moe --merge-up-gate-experts \ --flash-attn on --mla-use 3 \ --mlock --run-time-repack --no-kv-offload 25 個參數，一半沒有文件說明，四分之一會靜默失敗。這就是作者所說的「可用性的護城河」（usability moat）——黑盒工具讓你看不見這些，但也讓你無法優化。 ...