Gemma 4 現在主要有四個本地部署尺寸：E2B、E4B、26B A4B 和 31B。 其中 E2B、E4B 面向輕量和邊緣裝置，26B A4B 是 MoE 架構，31B 是更大的稠密模型。

本地執行時，最容易混淆的是兩個數字：

• GGUF 檔案體積：模型權重檔案本身有多大。
• 實際顯存占用：模型權重、KV cache、執行時開銷、上下文長度、是否載入多模態投影檔共同決定。

下面的表格按 GGUF 檔案體積估算顯存需求。 預設假設是 llama.cpp、LM Studio、Ollama 這類本地推理場景，主要跑文字，使用中短上下文。 如果要開長上下文、視覺/音訊輸入、並發請求，顯存要繼續往上留餘量。

先看結論

如果只是想本地可用，優先從 E4B Q4_K_M 或 E2B Q4_K_M 開始。 如果有 24GB 顯存，26B A4B Q4_K_M 和 31B Q4_K_M 才開始進入比較舒服的範圍。

Gemma 4 E2B 顯存表

E2B 是最輕量的版本，適合筆電、迷你主機、行動端和低顯存測試。 它的優勢是容易跑，缺點是複雜推理、程式碼和長任務穩定性有限。

E2B 的 Q4_K_M 已經夠日常體驗。 如果只有 4GB 顯存，可以嘗試 2-bit 或 3-bit，但輸出品質會更容易波動。

Gemma 4 E4B 顯存表

E4B 是更實用的輕量版本。 它比 E2B 更適合日常寫作、資料總結、輕量程式碼輔助和本地助手。

如果你的顯卡是 8GB，E4B Q4_K_M 是很現實的起點。 如果是 12GB 或 16GB，E4B Q8_0 也可以考慮。

Gemma 4 26B A4B 顯存表

26B A4B 是 MoE 版本，參數規模更大，但每次推理只啟用其中一部分專家。 它適合更複雜的問答、程式碼、工具呼叫和 Agent 工作流。

24GB 顯存是 26B A4B 比較舒服的分界線。 16GB 顯卡可以嘗試低位元版本，但上下文長度、並發和多模態都要收斂。

Gemma 4 31B 顯存表

31B 是更大的稠密模型。 它的優點是綜合能力更強，缺點是顯存壓力比 26B A4B 更直接。

31B 的低位元版本可以在 16GB 顯卡上做實驗，但如果想日常使用，最好從 24GB 顯存起步。 Q4_K_M 是比較平衡的選擇，Q5_K_M 往上更適合 32GB 以上顯存。

為什麼實際占用會比檔案體積更高

GGUF 檔案體積只是權重大小。 真正執行時還會增加這些開銷：

• KV cache：上下文越長，占用越高。
• 批次大小和並發：一次處理更多 token 或多使用者並發，會增加顯存。
• 多模態組件：圖片、音訊、影片輸入通常還要載入 mmproj 或額外處理模組。
• 執行時後端：CUDA、Metal、ROCm、CPU/GPU 分層載入的占用不同。
• KV cache 量化：開啟 q8_0、q4_0 等 KV cache 量化可以省顯存，但可能影響細節。

所以表格裡的「最低顯存」只能理解為「能啟動並短上下文執行」的門檻。 如果你要 32K、64K、128K 甚至 256K 上下文，顯存需求會明顯增加。

怎麼選

如果只是想在本地體驗 Gemma 4：

• 4GB 到 6GB 顯存：選 E2B Q3_K_M 或 E2B Q4_K_M。
• 8GB 顯存：優先選 E4B Q4_K_M，也可以跑 E2B Q8_0。
• 12GB 顯存：選 E4B Q8_0，或者嘗試 26B/31B 的低位元版本。
• 16GB 顯存：可以嘗試 26B A4B UD-Q3_K_M 或 31B Q3_K_S，但不要期待長上下文很舒服。
• 24GB 顯存：26B A4B UD-Q4_K_M 和 31B Q4_K_M 是重點選擇。
• 32GB 以上：可以考慮 Q5_K_M、Q6_K，或者更長上下文。

一般使用者不需要追 BF16。 本地部署的重點不是檔案越大越好，而是在顯存、速度、上下文和輸出品質之間找到平衡。

參考來源

• google/gemma-4-E2B-it - Hugging Face
• google/gemma-4-E4B-it - Hugging Face
• ggml-org/gemma-4-26B-A4B-it-GGUF - Hugging Face
• unsloth/gemma-4-E2B-it-GGUF - Hugging Face
• unsloth/gemma-4-E4B-it-GGUF - Hugging Face
• unsloth/gemma-4-26B-A4B-it-GGUF - Hugging Face
• unsloth/gemma-4-31B-it-GGUF - Hugging Face