Google DeepMind 今天發布了 Gemma 4 的 Quantization-Aware Training 檢查點,在標準 Q4_0 格式和新的行動優化格式中。具體的記憶體數字講述了故事:E2B 從 BF16 的 9.6 GB 下降到 Q4_0 的 3.2 GB 再到新行動格式的大約 1 GB,純文字變體放入 1 GB 以下。E4B 從 15 GB BF16 到 5 GB Q4_0(行動格式大小在發布時未揭露)。五種尺寸 ship 帶 QAT 檢查點:E2B、E4B、12B、26B A4B(active-4B Mixture-of-Experts 變體)和 31B。Q4_0 QAT 線開箱即用支援 llama.cpp、Ollama、LM Studio、vLLM 和 MLX;行動格式針對 LiteRT-LM 和 Transformers.js。HuggingFace 集合位於 google/gemma-4-qat-q4-0 和 google/gemma-4-qat-mobile。
行動格式是工程實質所在,這不是統一的低位量化。Google 的描述:在 token 生成層上有針對性的 2-bit 壓縮,推理層保持更高精度。靜態啟動縮放因子在訓練期間預計算,以便模型不在裝置上支付啟動縮放的開銷,channel-wise 量化是專門選擇的,因為它乾淨地映射到行動加速器硬體設計。這是一個與統一 Q3 或 Q2 量化(首先崩潰推理品質)截然不同的選擇。這個賭注是否存活取決於特定工作負載的評估,Google 在此發布中沒有發布 Gemma 4 QAT 基準數字。引用的歷史參考是 Gemma 3 QAT 將 Q4_0 困惑度下降減少了 54 個百分點對比 PTQ,這是先例而不是 Gemma 4 證據。值得注意:QAT 不會改變給定格式的大小。它在該大小下提高品質。從 9.6 GB 到 1 GB 以下的數量級記憶體下降來自格式,而不是訓練方法。
兩條值得停下來思考的生態線索。首先,這是四天內第三個 Gemma 4 發布,作為一個序列閱讀,這種速度告訴你一些東西。Google 在 6 月 3 日發布了基礎 12B encoder-free 多模態模型,6 月 5 日上午發布了帶原生 MTP drafter 支援和 2.2x 解碼聲明的 LiteRT-LM,6 月 5 日晚上發布了 QAT 行動格式。這就是「模型、加速器、部署器」不到七十二小時,部署器移動將最小變體放入中端 Android 手機的記憶體範圍內。兩天前 laptop-local 前沿是一個真實的故事;今天的公告悄然將其擴展到文字生成的 phone-local 前沿,這是一個不同類別的部署表面。以前需要雲往返才能進行任何有意義生成的應用現在有了進程內選項。其次,targeted-precision 模式是值得帶走的部分,即使你從未部署 Gemma 4。大多數量化工作一直是統一的,代價一直是 reasoning-heavy 基準比 generation-token 基準下降更快。將推理層保持在更高精度,同時將 token 生成層擠壓到 2-bit 是一個尊重不對稱品質成本的手術性舉措。其他具有類似部署野心的 open-weights 家族可以應用相同的分離。
週一早上,如果你一直想在行動應用程式中發布 LLM 功能而不需要雲往返:1 GB 以下的 E2B 變體現在是一個現實的候選者,在你的實際工作負載上執行它,然後再押注架構決策,並注意你的任務是 reasoning-heavy(2-bit 生成層仍然依賴於全精度推理來落地正確答案)還是 generation-heavy 帶瘦推理(格式將工作良好)。如果你通過 llama.cpp、MLX 或 Ollama 在筆記型電腦上執行 Gemma 4,在品質保留聲明給定的情況下,切換到 Q4_0 QAT 檢查點是無悔升級;在承諾之前在你的基準上驗證。如果你量化自己的 open-weights 模型,targeted-precision-by-layer-role 模式是要研究的工程教訓,你應該將所有內容量化到相同位寬的假設現在正在被積極挑戰。和總是與廠商發布的品質聲明和沒有特定模型基準一樣,負擔在獨立評估上;llama.cpp 和行動部署社區將在未來一兩週內產生比較數字,這就是重要的驗證。