實測 Google Gemma 4 QAT 模型：1GB 手機跑到、RTX 3090 直上 31B，記憶體點慳返嚟？

Gemma 4 QAT 模型完整陣容

五款模型尺寸都獲得了 QAT 檢查點，仲配埋用於推測解碼嘅 drafter 模型。每款都有多種格式可以揀（下文會詳解），而實際記憶體佔用由 BF16 到 QAT 4-bit 嘅變化非常戲劇性 。

記憶體數據嚟自 Google 官方模型概覽同 Unsloth 文件，Q4_0 數字代表常用嘅 GGUF 量化級別 。E2B 手機格式做到約 1GB 嘅數字係最震撼嘅——Google 專門設計咗一種自訂模式，透過針對性嘅 2-bit 解碼層同最佳化嘅 KV 快取嚟達到呢個效果 。至於唔包含「逐層嵌入」（Per-Layer Embeddings）嘅純文字模型，據報記憶體佔用仲可以再低過 1GB 。

26B A4B 模型值得特別留意。佢係一個混合專家（Mixture of Experts）架構，每個 token 只會啟動大約 38 億個參數，雖然總共有 260 億個參數。亦即係話，佢嘅運算行為接近一個 4B 模型，但推理質素就可以媲美規模大得多嘅稠密模型 。喺 4-bit 形式下，佢可以塞得落 12-16 GB 顯示卡——正正係好多開發者已經擁有嘅硬件 。

部署格式：小心揀，咪中伏

Google 以四種不同形式發布 QAT 檢查點，而揀邊種格式會直接影響最終質素 ：

• Compressed-tensors (W4A16)： 用於 vLLM 推論嘅官方格式，使用 4-bit 整數權重同 16-bit 激活值，group_size=32。如果你想留喺 Google 測試過嘅質素包絡線入面，呢個係首選方案 。
• GGUF / Q4_0： llama.cpp、Ollama 同類似生態工具最廣泛使用嘅格式。全部五款模型尺寸都有現成可用嘅 GGUF 檔案 。
• 手機最佳化格式： 一種混合咗多種量化寬度嘅自訂模式，專為手機硬件而設計。只有 E2B 同 E4B 提供，亦正係令 E2B 做到約 1GB 數字嘅格式 。
• 未量化 QAT 檢查點： 由 QAT 流程提取出嚟嘅半精度權重。適合想做自己嘅下游自訂量化或編譯流程嘅研究人員同開發者 。

成個發布入面最重要嘅警告，就係關於「天真轉換格式」嘅風險。將 QAT 權重直接轉換成 Q4_0 而冇做適當處理，有機會令準確度大幅下降。根據 Unsloth 嘅文件，將 26B QAT 模型天真咁轉做 Q4_0，只係得到大約 70.2% 嘅 Top-1 準確度 。佢哋自己嘅 Dynamic 量化方法就將個數字推到 85.6%，足足提升咗 15.4 個百分點——但重點係，格式選擇同轉換方法對於保持 QAT 應有嘅質素嚟講，係極之關鍵嘅 。

對大部分用家嚟講，官方嘅 compressed-tensors 或者 GGUF 檢查點係最安全嘅起點。

乜嘢硬件真係跑到呢啲模型？

QAT 唔單止減少記憶體用量——佢重寫咗本地 AI 推論嘅硬件地圖。以前需要數據中心級 GPU 先跑到嘅模型，而家可以喺消費級硬件甚至智能手機上行得郁。

智能手機同邊緣裝置： E2B 係專為手機而設嘅。Google 嘅 LiteRT-LM 框架可以喺 1.5 GB RAM 以下，用 2-bit 同 4-bit 量化嚟執行 E2B，而 Google 喺 Play Store 上嘅 AI Edge Gallery 應用程式，更可以畀用家選擇並完全喺裝置上執行 E2B 或 E4B 。兩款模型都支援文字、圖像同音頻輸入——即係話，即時語音翻譯、視覺問答同埋裝置上嘅 AI 助理，唔使連上雲端都變得可行 。

8 GB 顯示卡： 呢個係 QAT 部署嘅甜點位。E2B（~3.2 GB）、E4B（~5 GB）同 12B 模型（~7 GB）全部都可以喺 Q4_0 量化下，輕鬆塞入 8 GB VRAM 。換句話講，一部配備流動版 4060 嘅中階筆電，或者一張舊啲嘅桌面版 2070，而家都可以執行一個擁有 256K 上下文視窗嘅統一多模態模型——呢樣嘢喺 16-bit 精度下，本來要 24 GB 以上先做到。

12–16 GB 顯示卡： 26B A4B MoE 模型大約需要 15 GB（Q4_0 形式），可以塞得落 RTX 3080、4070 Ti 或 4080 呢類顯示卡 。佢嘅 MoE 架構亦代表住，推論延遲比同等佔用空間嘅稠密模型更低，因為每個 token 只會啟動一小部分參數 。

20–24 GB 顯示卡： 31B 稠密模型喺 Q4_0 量化下需要約 17–18 GB，令佢落入 RTX 3090 同 4090 用家嘅可及範圍，仲有啲空間留畀 KV 快取同批次大小 。如果用完整 16-bit 精度，呢個模型需要接近 60 GB——對消費級 GPU 嚟講完全係冇可能嘅事。QAT 令到最大嘅 Gemma 4 模型，可以真正務實咁喺單一張高階消費級顯示卡上執行。

重要現實檢查： 上面討論嘅記憶體數字，代表嘅係模型權重嘅大小，而唔係總 VRAM 消耗量。執行時嘅額外開銷——特別係長上下文視窗嘅 KV 快取——可以喺權重之上再加多幾 GB。31B 模型配 256K 上下文，實際記憶體消耗會明顯高過基本權重大小，社群報告亦指出，上下文密集嘅工作負載可能會將需求推到 20 GB 以上 。記得要喺列出嘅 Q4_0 權重佔用空間之外，預留多啲空間。

質素保留同實際限制

QAT 嘅核心承諾係大幅減少記憶體嘅同時保持接近原版嘅表現——而基準測試大致上支持呢一點。Google 自己嘅文件描述表現為喺約 72% 記憶體減少下「接近原版」，而社群基準測試就指出，Q4 量化嘅質素損失大約喺 3–5% 範圍內，同 BF16 相比 。

但魔鬼喺細節度。Unsloth 對天真轉換嘅警告——26B 模型天真轉換得 70.2% Top-1 準確度，而經過佢哋嘅 Dynamic 最佳化後可以去到 85.6%——示範咗你最終得到嘅質素，好大程度上取決於你點樣轉換同部署 QAT 權重 。如果你就咁攞一個 QAT 檢查點，然後用標準 GGUF 轉換器去轉，而冇做 QAT 感知嘅處理，你好可能得唔到你期望嘅質素。

對於生產環境，最安全嘅做法係直接使用 Google 官方嘅 QAT 檢查點，用佢哋嘅 compressed-tensors 格式（畀 vLLM 用），或者用 Hugging Face 上面嘅官方 GGUF 檔案 。如果你需要 Google 提供範圍以外嘅自訂量化，就要預留時間做基準測試——QAT 權重對轉換方法嘅敏感度，比標準嘅訓練後量化權重高好多。

呢次發布解鎖咗啲乜？

喺實際層面，呢次發布改變咗「我可唔可以本地行呢個模型？」呢條問題嘅預設答案。首次有主要嘅開放權重模型家族，將 QAT 檢查點當做一等公民咁推出，而唔係附帶品。呢個影響波及幾個應用類別：

私隱敏感嘅工作負載： 醫療、法律同個人助理應用程式，以前一定要靠雲端 API，而家可以完全喺筆電或手機嘅裝置上執行，QAT 保留到嘅質素足以令本地推論真正有用 。

離線同邊緣部署： 田野研究、災難應變同冇可靠網絡連線嘅工業環境，可以喺商品硬件上部署功能強大嘅多模態模型。E2B 嘅音頻支援加上約 1GB 嘅手機量化，令到中階手機上嘅即時語音翻譯，變成一個實際上可行嘅現實 。

開發者工具同 IDE： 12B 同 26B 模型可以塞入開發者本身已經擁有嘅硬件，令到程式碼自動完成、重構同文檔生成等功能可以本地執行，唔受延遲同成本限制。Google 特別將量化版本定位為適用於「IDE、程式編寫助手同智能代理工作流程」。

實驗同微調： 規模較細嘅研究團隊同獨立開發者，以前負擔唔起 A100 或 H100 叢集，而家可以喺消費級硬件上處理 12B–31B 範圍嘅模型，大大降低咗模型自訂同特定領域微調嘅入場門檻。

Google 以同基礎版 Gemma 4 模型一樣嘅 Apache 2.0 授權發布呢啲檢查點，而且全部五款模型尺寸都已經可以喺 Hugging Face 上即時下載 。