Gemma 4 QAT：如何在消費級顯卡與 1GB 手機上跑 31B 模型

完整的 Gemma 4 QAT 模型陣容

本次釋出的 QAT 適用於五種規模的模型核心，同時也包含相對應的草稿模型（drafter models），用以支援所謂的「推測性解碼」機制。每個規模皆提供多種部署格式（將在後續章節詳細介紹）；而從 BF16 到 QAT 4 位元版本，實際的記憶體佔用差距堪稱驚人 。

記憶體數據主要來自 Google 官方的模型總覽與 Unsloth 技術文件，其中 Q4_0 的數值代表當前 GGUF 生態系中最為通行的量化等級 。至於表格裡最引人注目的莫過於 E2B 行動版格式那約 1 GB 的驚人數值——Google 為達成此目標，特別設計了一套客製化壓縮綱要，其中包含了針對解碼層的針對性 2 位元量化，以及對 KV 快取的最佳化配置 。若是純文字模型，並移除逐層嵌入（Per-Layer Embeddings），據悉其記憶體佔用甚至能進一步壓到低於 1 GB 。

這裡特別值得一提的是 26B A4B 架構。它是一種「混合專家」設計，總參數量高達 260 億，但在進行推論時，每個 token 只會啟動其中約 38 億個參數。這意味著它的實際計算量接近一個 4B 的模型，卻能提供接近更大規模稠密模型的推論品質 。換句話說，在 4 位元格式下，這款模型能安穩地放進許多開發者手邊既有的 12–16 GB 顯示卡之中 。

部署格式：選擇時務必謹慎

Google 在釋出 QAT 檢查點時，提供了四種截然不同的包裝形式；它們各自對最終的模型品質都有直接影響，不可不察 ：

• Compressed-tensors (W4A16)： 官方主推的 vLLM 推論格式，採用 4 位元權重與 16 位元激活值，參數分組大小為 32。如果你想穩穩待在 Google 所測試過的品質保證範圍之內，這將是首選路線 。
• GGUF / Q4_0： 在 llama.cpp、Ollama 等生態系工具中最被普遍使用的格式。本次 QAT 釋出已為五種模型規模備妥立即可用的 GGUF 檔案 。
• 行動裝置最佳化格式： 一套混合多種量化位元寬度的客製化綱要，專為手機硬體從頭設計。此格式僅開放給 E2B 與 E4B 兩種規模，也正是實現 E2B 於 1 GB 記憶體環境下執行的關鍵技術 。
• 未量化的 QAT 檢查點 (Unquantized QAT checkpoints)： 從 QAT 訓練管線中擷取出來的半精度權重檔。主要提供給想自行套用客製化量化或編譯流程的研究者與開發者，作為下游工作的起點 。

關於整個釋出最重大的警示，莫過於「格式之間的粗心轉換」。根據 Unsloth 的技術文件，如果將 26B 模型的 QAT 權重「草率地」直接轉換為 Q4_0，其 top-1 準確率僅能達到約 70.2% 。該團隊所施加的 Dynamic 量化方法，能將此數字拉升到 85.6%，足見格式挑選與轉換方法的嚴謹度，對於守住 QAT 理應貢獻的品質，是極其關鍵的要素 。

對多數用戶來說，從官方的 compressed-tensors 或 GGUF 檢查點開始，會是最穩健的起手式。

什麼樣的硬體能真正跑動這些模型？

QAT 不只是在減少記憶體——它正在實質重塑本地端 AI 推論的硬體地貌。過去非得靠資料中心等級顯卡才能推動的模型，如今已能踏上消費級硬體、甚至智慧手機。

智慧手機與邊緣裝置： E2B 可以說是為手機而生。Google 的 LiteRT-LM 框架可在 1.5 GB 記憶體以內，以 2 位元與 4 位元量化來執行 E2B；使用者更可直接從 Play 商店下載 Google 自家的 AI Edge Gallery 應用程式，選擇 E2B 或 E4B 模型，完全在裝置端運行 。這兩款模型皆原生支援文字、圖像與音訊的輸入——也就是說，像是即時語音翻譯、視覺問答，甚至一個完全無須雲端連線的裝置端助理，都變得切實可行 。

8 GB 顯示卡： 這是 QAT 部署上最甜蜜的切入點。E2B（約 3.2 GB）、E4B（約 5 GB）以及 12B 模型（約 7 GB），經 Q4_0 量化後都可從容地放進 8 GB 的 VRAM 之中 。這意味著：一台搭載行動版 RTX 4060 的中階筆電，或一張老一點的 RTX 2070 桌上型顯卡，如今就能跑動一個具備 256K 上下文視窗的統一多模態模型——以 16 位元精度來跑，這類模型起碼需要 24 GB 以上的顯卡才應付得來。

12–16 GB 顯示卡： 26B A4B 的混合專家模型將在此區間大放異彩，其 Q4_0 格式佔用約 15 GB，能安穩落在 RTX 3080、4070 Ti 或 RTX 4080 等顯示卡之上 。由於其 MoE 架構的特性，每個 token 僅啟動一少部分參數，因此它的推論延遲也比一個佔用空間相似的稠密模型要來得低 。

20–24 GB 顯示卡： 31B 的稠密模型在 Q4_0 量化後需要約 17–18 GB，這使得 RTX 3090 與 RTX 4090 的持有者在保留一定 KV 快取與批次大小餘裕的條件下，得以觸及此級距 。要知道，若以完整的 16 位元精度執行，這款模型需要近 60 GB 的顯卡記憶體——對消費級顯卡而言根本是天方夜譚。QAT 讓 Gemma 4 家族中最大的模型，在單一張高階消費級顯卡上變得「務實可用」。

重要現實提醒： 上面討論的記憶體數字代表的是模型權重本身的大小，而非總體 VRAM 消耗。實際運作時的額外開銷——也就是為了支援長上下文視窗所配置的 KV 快取——往往會再往上增加數個 GB。以 31B 模型搭配 256K 上下文視窗為例，實際的記憶體需求將會顯著高於模型權重的基礎佔用量；據社群回報，在處理上下文密集的任務時，總需求極可能推升至略高於 20 GB 的區間 。因此，在規劃硬體時，永遠要為 Q4_0 權重清單以外的這些運作開銷，事先保留更多空間。

品質的保存與實務上的界線

QAT 的核心承諾，是在大幅削減記憶體的同時，保全近乎原始的效能——而各方基準測試的結果也大致呼應了這一點。Google 自家的技術文件形容其表現為「趨近原始效能」，並伴隨約 72% 的記憶體縮減；社群的基準測試則指出，相較於 BF16，Q4 量化後的品質衰減約落在 3–5% 的範圍之內 。

然而，魔鬼就藏在細節裡。Unsloth 所發出的「草率轉換」警示——同一個 26B 模型，粗劣的轉換只能達到 70.2% 的 top-1 準確率，經過他們 Dynamic 方法最佳化後則升至 85.6%——清楚說明了最終的品質，將大幅取決於你如何轉換與部署這些 QAT 權重 。如果你只是單純將 QAT 檢查點拿來，套進一個不會區分 QAT 特性的標準 GGUF 轉換器中，那你很可能得不到預期中的品質。

在正式生產環境中，最安全的途徑是採用 Google 官方的 QAT 檢查點，並直接沿用它們的 compressed-tensors 格式（搭配 vLLM 使用），或使用從 Hugging Face 取回的官方 GGUF 檔案 。如果你需要進一步套用 Google 現有方案以外的客製化量化，那麼請務必保留足夠的時間進行基準測試——QAT 權重對轉換方法學的敏感度，遠高於一般慣見的訓練後量化權重。

這次釋出到底開啟了哪些新可能？

回歸實務層次，這次的釋出，等於一舉改寫了「我能在我這台機器上跑這個模型嗎？」這個問題的預設答案。這是有史以來頭一遭，一個重要的開源權重模型家族，在出廠時就將 QAT 檢查點作為「一等公民」來提供，而不是放到事後才補上的選配項目。其漣漪效應，正向幾個領域迅速蔓延：

講求隱私的工作流： 舉凡醫療、法律以及個人助理等，過去非得上雲呼叫 API 才能實現的應用場景，如今都能在筆電或手機上完全離線執行。QAT 所保留的推論品質，已足以讓真正的本地推論變得實用且可靠 。

離線與邊緣佈署： 田野調查、災難應變、還有那些缺乏穩定網路連線的工業現場，現在都能靠著平價硬體部署功能強大的多模態模型。E2B 的音訊支援，再搭配其 1 GB 的手機量化規格，意味著能在中階手機上實現堪用的即時語音翻譯 。

開發者工具與 IDE： 無論是 12B 還是 26B 模型，都能落腳在開發者既有的硬體環境中，這讓程式碼補全、重構，以及文件自動生成等功能，皆可在不受延遲與連線成本困擾的情況下本機執行。Google 也明確將這些量化版本定位於「IDE、程式開發輔助，以及智能代理導向的工作流」之上 。

實驗與微調： 過去無力負擔 A100 或 H100 等級 GPU 叢集的小型研究團隊與獨立開發者，如今都可在消費級硬體上，對 12B 到 31B 級距的模型進行研究與實驗，大幅降低了進行模型客製化與特定領域微調的門檻。

這些檢查點與 Gemma 4 基礎模型同樣採用 Apache 2.0 授權，並已即刻上架於 Hugging Face，完整涵蓋前述五種模型規模 。