Gemma 4 有四個版本，選對了用起來飛快，選錯了要麼卡得要死要麼大材小用。這篇幫你搞清楚每個版本的定位，選出最適合你的那個。
四個模型一覽
| 模型 | 總參數量 | 活躍參數量 | 架構 | 最低記憶體 | 推薦記憶體 |
|---|---|---|---|---|---|
| E2B | 20 億 | 20 億 | Dense | 4 GB | 6 GB |
| E4B | 40 億 | 40 億 | Dense | 6 GB | 8 GB |
| 26B A4B | 260 億 | 38 億 | MoE | 8 GB | 16-18 GB |
| 31B Dense | 310 億 | 310 億 | Dense | 20 GB | 24-32 GB |
重點關注 26B 模型——它用的是**混合專家（MoE）**架構。雖然總參數有 260 億，但每次推論只啟動大約 38 億參數。這代表你能用小模型的速度享受大模型的品質。想深入了解 MoE 架構的優劣，看看 26B 和 31B 詳細比較。
逐個拆解
E2B——口袋火箭
20 億參數，約 4 GB 記憶體
最小的 Gemma 4 模型，專門為資源受限的情境設計。手機、樹莓派、嵌入式裝置，或者你需要極快回應不需要深度推理的情境。
ollama run gemma4:e2b擅長：
- 快速文字產生和摘要
- 簡單問答
- 分類任務
- 在手機和邊緣裝置上執行
- 延遲敏感的情境
不足：
- 複雜多步推理會吃力
- 創意寫作不夠細膩
- 長對話可能遺失上下文
E4B——萬用首選（推薦大多數人用）
40 億參數，約 6 GB 記憶體
如果你不知道該選哪個，選這個。E4B 在任何現代筆電上都能順暢執行，品質好得超出預期。
ollama run gemma4:e4b擅長：
- 通用聊天和問答
- 程式碼產生和解釋
- 內容寫作和編輯
- 多模態任務（圖片+文字）
- 日常本機 AI 使用
為什麼推薦它：
- 最近 3-4 年的筆電基本都能跑
- Apple Silicon 上輕鬆 20+ tokens/s，聊天很順暢
- 品質真的不錯——遠超你對 4B 模型的預期
- 資源佔用低，跑著它還能正常用其他應用程式
26B A4B——效率之王
260 億總參數，僅 38 億活躍（MoE 架構），約 8-18 GB 記憶體
這是整個陣容裡最有意思的模型。Google 訓練了 260 億參數，但每次推論只啟動 38 億。你用小模型的算力，得到大模型的知識。
ollama run gemma4:26b擅長：
- 複雜推理和分析
- 多語言程式碼任務
- 長文產生
- 專業知識問答
- 整個系列中性價比最高
需要注意：
- 雖然活躍參數少，但全部 260 億參數都得載入記憶體
- GGUF Q4 量化後大概需要 8-16 GB，取決於上下文長度
- MoE 模型輸出品質可能略有波動（不同輸入啟動不同專家）
誰該用這個： 如果你有 16 GB 以上記憶體和一張還行的顯示卡（或者 Apple Silicon Mac），這可能是整個系列裡最值的選擇。接近 31B 的品質，E4B 的速度。
31B Dense——極限效能
310 億參數，全密集，最低約 20 GB 記憶體
最大、最強的 Gemma 4 模型。每個 token 都經過全部 310 億參數的處理。沒有捷徑，沒有路由——純粹的能力。
ollama run gemma4:31b擅長：
- 最有挑戰性的推理任務
- 最高品質的創意寫作
- 複雜程式碼產生和除錯
- 研究和分析
- 品質是唯一考量的情境
硬體需求：
- 最少 20 GB 記憶體（推薦 24-32 GB）
- 強烈建議有獨立顯示卡才能有可接受的速度
- Q4 量化後模型檔案約 18 GB
GPU 使用者：顯存需求
按具體機型（MacBook、電競 PC、雲端 GPU）看設定夠不夠，參考硬體設定需求詳解。
| 模型 | Q4_K_M | Q5_K_M | Q8_0 | FP16 |
|---|---|---|---|---|
| E2B | ~1.5 GB | ~1.8 GB | ~2.5 GB | ~4 GB |
| E4B | ~3 GB | ~3.5 GB | ~5 GB | ~8 GB |
| 26B A4B | ~8 GB | ~10 GB | ~14 GB | ~52 GB |
| 31B Dense | ~18 GB | ~21 GB | ~30 GB | ~62 GB |
小提醒： Q4_K_M 量化對大多數人來說是最佳選擇。品質損失微乎其微，記憶體節省巨大。
別忘了 KV Cache
很多人踩的坑：模型權重不是唯一吃記憶體的東西。KV cache（儲存對話上下文的快取）也很大，尤其是 Gemma 4 支援超長上下文視窗的情況下。
社群回饋 31B 模型在 262K 上下文視窗下，KV cache 單獨就要吃掉約 22 GB 額外記憶體。這還是模型權重之外的。
實用建議：
- 記憶體不夠就縮短上下文長度：
# 在 Ollama 裡設定較小的上下文視窗 ollama run gemma4:31b --ctx-size 8192 - 26B 和 31B 模型可以開啟 KV cache 量化（Q8 或 Q4）來大幅降低記憶體佔用
- E2B 和 E4B 就好得多——即使上下文較長，KV cache 也很可控
決策樹：看你有什麼硬體
「我就一支手機或樹莓派」 → E2B，其他的塞不下。
「我有 8 GB 記憶體的筆電」 → E4B，跑起來很順暢，還有餘裕給其他應用程式。
「我有 16 GB 記憶體的筆電/桌機」 → 追求速度選 E4B，追求品質選 26B（量化版），願意等一等的話。
「我有 24 GB 以上記憶體或 8 GB 以上顯存的顯示卡」 → 26B 是最佳選擇。說真的，性價比太高了。
「我有工作站，24 GB 以上顯存」 → 31B Dense，極致品質。算力夠就上。
「我想在伺服器/雲端上用」 → 26B 或 31B，看預算和延遲需求。
效能基準比較
| 基準測試 | E2B | E4B | 26B A4B | 31B Dense |
|---|---|---|---|---|
| MMLU | 良好 | 較好 | 一流水準 | 最佳 |
| HumanEval（程式碼） | 可用 | 良好 | 很好 | 優秀 |
| GSM8K（數學） | 基礎 | 良好 | 強 | 最強 |
| 多模態（視覺） | 基礎 | 良好 | 強 | 最佳 |
| 速度（M3 tok/s） | ~60 | ~35 | ~25 | ~8 |
26B MoE 是亮點——品質分接近 31B，速度快將近 3 倍。MoE 架構確實很有用。
量化怎麼選？
從 Hugging Face 下載 GGUF 檔案時你會看到 Q4_K_M、Q5_K_M、Q8_0 等選項：
| 量化等級 | 品質損失 | 體積縮小 | 建議 |
|---|---|---|---|
| Q4_K_M | 極小 | 約 75% | 預設首選 |
| Q5_K_M | 很小 | 約 65% | 空間夠就選這個 |
| Q8_0 | 幾乎無 | 約 50% | 追求品質 |
| FP16 | 無 | 原始大小 | 僅用於微調 |
我的建議： 從 Q4_K_M 開始。如果在你的使用情境中發現品質不夠，再換 Q5_K_M。說實話，大多數人真的分不出來。
模型下載方法看這裡：Gemma 4 下載安裝完整攻略。
下一步
- 準備下載？ → Gemma 4 下載安裝完整攻略
- 檢查硬體夠不夠 → Gemma 4 硬體需求
- 跑不起來？ → Gemma 4 常見問題排查
- 想和其他模型比較？ → Gemma 4 vs Llama 4 或 Gemma 4 vs Qwen 3
Stop reading. Start building.
~/gemma4 $ Get hands-on with the models discussed in this guide. No deployment, no friction, 100% free playground.
Launch Playground />
