Gemma 4 在 2026 年 4 月 2 日正式發布，是 Google DeepMind 迄今為止最強的開源模型家族。 四款模型從手機到工作站全覆蓋，其中 26B MoE 變體在單張 RTX 3090 上就能跑出 64–119 tokens/sec 的生成速度，同時支援 256K token 上下文窗口。整個家族採用 Apache 2.0 授權，商用無限制。這篇文章拆解每款模型的硬體需求、量化選擇、PC 與 Mac 各自的最佳配置方案，以及如何搭配 OpenClaw agent 框架建立零成本的 agentic 工作流。
Gemma 4 家族四款模型：搞清楚你要跑哪一個
Gemma 4 從 Gemini 3 的研究基礎發展而來，分成四個尺寸。搞懂它們的差異是選硬體的前提。
| 模型 | 總參數量 | 推論活躍參數 | 架構 | 上下文窗口 | 最低 VRAM（Q4） | 適合場景 |
|---|---|---|---|---|---|---|
| E2B | 5.1B | 2.3B（有效） | Dense + PLE | 128K | ~4 GB | 手機、Raspberry Pi、極輕量測試 |
| E4B | ~9B | 4.5B（有效） | Dense + PLE | 128K | ~6 GB | 筆電、入門桌機、多數人的起手式 |
| 26B A4B | 26B | 3.8B（MoE） | MoE（128 專家，每 token 啟動 9 個） | 256K | ~18 GB | 24 GB GPU 甜蜜點、agentic 工作流 |
| 31B | 31B | 31B（全量） | Dense | 256K | ~20 GB | 最高品質、微調基礎 |
E 系列的「E」代表 Effective parameters。E2B 和 E4B 採用 Per-Layer Embeddings（PLE）技術，讓小模型擁有遠超參數量暗示的表達深度。26B A4B 是 Gemma 家族第一款 MoE 模型，128 個小型專家中每個 token 只啟動 8+1 個共享專家，實際推論時只有 3.8B 參數在跑。
這個設計的實際意義：26B A4B 在 Arena AI 文字排行榜 排名第六，打敗了多個參數量超過它 20 倍的模型。31B Dense 排名第三。
PC 配置指南：從 RTX 3090 到 RTX 5090
Reddit 上 r/openclaw 社群有用戶分享，在雙 RTX 3090 上跑 Gemma 4 MoE 模型達到約 120 tokens/sec。這個數字跟硬體評測站的實測區間吻合：根據 Avenchat 的硬體需求指南，26B MoE 在單張 RTX 3090（24 GB VRAM）上的生成速度落在 64–119 tokens/sec，31B Dense 則是 30–34 tokens/sec。
依預算選 GPU
| GPU | VRAM | 推薦模型 | 26B MoE 預估速度 | 備註 |
|---|---|---|---|---|
| RTX 3060 12GB | 12 GB | E4B（Q4）或 26B（激進量化） | 受限 | VRAM 偏緊，建議從 E4B 開始 |
| RTX 3090 / 4090 | 24 GB | 26B A4B（Q4，完整 256K 上下文） | 64–119 t/s | 性價比甜蜜點，雙卡可進一步加速 |
| RTX 5090 | 32 GB | 31B Dense（Q4，完整 256K） | ~60+ t/s | 額外 headroom，31B 更從容 |
| 雙 RTX 3090 | 48 GB | 26B A4B（Q8 或 BF16） | ~100–120+ t/s | 減少量化損失，推論更順暢 |
| AMD Ryzen AI Max+ Pro 395（128 GB 統一記憶體） | 最高 96 GB（VGM） | 31B BF16、甚至 70B–128B Q4 | 依模型而定 | x86 統一記憶體架構，可跑 Llama 4 Scout 109B，迷你 PC 形態（Framework Desktop 約 USD 2,566 / NTD 82,000） |
RTX 3090 到現在還是本地 LLM 推論最划算的選擇之一。二手市場價格約 USD 600–800（約 NTD 19,000–26,000），24 GB VRAM 足以讓 26B MoE 在 Q4 量化下跑完整 256K 上下文，而且 VRAM 還有餘裕。
一個容易忽略的細節：VRAM 需求不只看模型權重大小。上下文長度越長，KV cache 吃的記憶體越多。26B A4B 在 Q4 量化下，4K 上下文約需 18 GB，拉到 256K 約需 23 GB。得益於 MoE 架構和混合注意力機制，上下文擴展的 VRAM 增幅比上一代平緩許多，這是它適合 24 GB 卡的關鍵原因。
量化選擇
| 量化等級 | 記憶體節省（vs BF16） | 品質損失 | 適合情境 |
|---|---|---|---|
| Q4_K_M | ~60% | ~2–5%（多數任務感覺不到） | 多數用戶的預設起點 |
| Q8_0 | ~50% | <1% | VRAM 充裕時的升級選項 |
| BF16 | 0% | 0% | 需要 80 GB H100 或雙高階 GPU |
Unsloth 團隊提供的 Dynamic 4-bit（UD-Q4_K_XL）是目前推薦的量化格式，在關鍵層維持較高精度，非關鍵層壓縮更激進，比均勻 Q4 有更好的品質保留。
Mac 配置指南：Apple Silicon 的統一記憶體優勢
Apple Silicon 的統一記憶體架構天生適合本地 LLM 推論，CPU 和 GPU 共用同一塊記憶體，不需要在主記憶體和 VRAM 之間搬資料。Gemma 4 全系列支援 MLX 和 llama.cpp 的 Metal 加速。
2026 年 3 月底，Ollama 宣布在 Apple Silicon 上改用 MLX 作為底層引擎，推論速度大幅提升。在 M5 系列晶片上，Ollama 0.19 版本的預填充速度達到 1,851 tokens/sec，生成速度 134 tokens/sec（int4 量化，以 Qwen3.5-35B-A3B 測試）。
依機型選模型
| Mac 機型 | 統一記憶體 | 推薦模型 | 實際體驗 |
|---|---|---|---|
| MacBook Air M3/M4（8 GB） | 8 GB | E2B 或 E4B（Q4） | 夠用於日常問答，別期待深度推理 |
| MacBook Pro M4 Pro（18–36 GB） | 18–36 GB | E4B（Q8）或 26B A4B（Q4） | 26B 在 24 GB 以上機型可順跑 |
| Mac Mini M4（16–32 GB） | 16–32 GB | 26B A4B（Q4，約 9.6 GB） | 24 GB 版本是 CP 值最高的選擇 |
| Mac Studio M4 Max（128 GB） | 128 GB | 31B（Q8 或 BF16）+ 多模型並行 | 128 GB 統一記憶體跑 31B BF16 綽綽有餘，可同時載入多個模型做 sub-agent |
| Mac Studio M3 Ultra（192–512 GB） | 最高 512 GB | 70B+ 模型 BF16、多模型並行 | 819 GB/s 記憶體頻寬，本地推論站的天花板配置 |
根據 Avenchat 的實測，26B A4B 在 Mac Mini 24 GB 統一記憶體上用 Ollama Q4_K_M 量化（約 9.6 GB），運行順暢且留有充裕的記憶體空間。跑 26B 全尺寸會讓 24 GB 的 Mac 在併發請求下變得很卡，建議維持 Q4 並留記憶體餘裕。
Mac 用戶還有一個選項：透過 mlx-vlm 函式庫直接用 MLX 跑多模態推論，支援 TurboQuant 量化，記憶體需求可再降約 4 倍，適合在 Apple Silicon 上跑長上下文任務。
三種本地部署方式：Ollama、llama.cpp、vLLM
方式一：Ollama（最簡單，推薦新手）
安裝後一行指令就能跑：
# 安裝 Ollama
curl -fsSL https://ollama.com/install.sh | sh
# 跑預設的 E4B（多數人的起手式）
ollama run gemma4
# 或指定模型
ollama run gemma4:e2b # 最輕量
ollama run gemma4:e4b # 性價比最高
ollama run gemma4:26b # MoE 甜蜜點
ollama run gemma4:31b # 最高品質
Ollama 自動處理模型下載、量化、硬體偵測。啟動後會在 localhost:11434 暴露 OpenAI 相容 API，可以直接接入 OpenClaw 或其他 agent 框架。
方式二：llama.cpp（進階用戶，最佳 CPU 推論）
git clone https://github.com/ggml-org/llama.cpp
cmake llama.cpp -B llama.cpp/build \
-DBUILD_SHARED_LIBS=OFF -DGGML_CUDA=ON # Mac 用 -DGGML_CUDA=OFF
cmake --build llama.cpp/build --config Release -j
# 跑 26B MoE
./llama.cpp/llama-cli \
-hf unsloth/gemma-4-26B-A4B-it-GGUF:UD-Q4_K_XL \
--temp 1.0 --top-p 0.95 --top-k 64
Mac 用戶不需要額外設定，Metal 加速預設啟用。llama.cpp 也支援以 server 模式運行，暴露 API 供其他工具呼叫。
方式三：vLLM（生產環境，多併發）
適合需要同時服務多個請求的場景，例如在公司內部架設共用推論服務。支援 PagedAttention 高效記憶體管理和多 GPU 平行運算。
搭配 OpenClaw 建立 Agentic 工作流
OpenClaw（前身 Clawdbot / Moltbot）是 2026 年初竄升最快的開源 AI agent 框架之一，上線不到一週就拿到超過數萬 GitHub Stars。它的核心概念是「本地優先」：對話記憶、技能、設定都存成 Markdown 和 YAML 檔案在你的硬碟上，模型可以接雲端 API 也可以接本地 Ollama / LM Studio。
Gemma 4 跟 OpenClaw 的組合特別值得關注，原因有三：
第一，Gemma 4 的原生 function calling 能力大幅提升。26B MoE 在 τ2-bench（零售 agentic 工具使用測試）拿到 85.5%，31B Dense 拿到 86.4%。對比 Gemma 3 27B 的 6.6%，進步幅度很驚人。這代表 Gemma 4 能穩定地產出結構化 JSON 工具呼叫，OpenClaw 的 skill 系統才跑得動。
第二，MoE 架構的速度優勢讓 agentic loop 感覺近乎即時。Agent 的工作迴圈是「輸入 → 思考 → 決定用哪個工具 → 執行 → 把結果餵回模型 → 再思考」，每一步都需要模型推論。26B MoE 在 RTX 3090 上 64–119 tokens/sec 的速度，讓整個迴圈的延遲控制在用戶可接受的範圍內。
第三，Apache 2.0 授權移除了商用限制。過去 Gemma 系列用自訂授權，有使用限制和可被 Google 更改的條款，讓企業法務部門不太放心。現在跟 Qwen、Mistral 站在同一個授權條件上。
OpenClaw 配置範例
{
"agents": {
"defaults": {
"model": {
"primary": "ollama/gemma4:26b"
}
}
},
"models": {
"mode": "merge",
"providers": {
"ollama": {
"baseUrl": "http://localhost:11434",
"apiKey": "ollama"
}
}
}
}
OpenClaw 也支援混合架構：用雲端的 Claude 或 GPT-4 當主要協調者（orchestrator），把具體執行任務委派給本地 Gemma 4 sub-agent。這樣可以用最少的 API 費用獲得最大的產出。一個 DEV Community 上的開發者實測，M3 Pro 36 GB 的 MacBook Pro 上同時跑 2–3 個本地 sub-agent，電費大概 USD 0.004/小時。
跟其他本地模型比較：Gemma 4 vs Qwen 3.5 vs Llama 4
| 維度 | Gemma 4 26B MoE | Qwen 3.5（32B 級） | Llama 4 Scout |
|---|---|---|---|
| 授權 | Apache 2.0 | Apache 2.0 | Community License（有限制） |
| 推論活躍參數 | 3.8B | 全量 32B | MoE，活躍 ~17B |
| 上下文窗口 | 256K | 128K | 10M（理論值） |
| 多模態 | 文字 + 影像 + 影片 | 文字 + 影像 | 文字 + 影像 |
| Function Calling | 原生支援 | 原生支援 | 有限 |
| 24 GB GPU 適配 | 完整 256K 上下文 | Q4 可跑，上下文受限 | 需要更大 VRAM |
| Arena AI 排名 | #6（文字） | 競爭激烈 | 表現不一 |
| τ2-bench 工具使用 | 85.5% | 未公開 | 未公開 |
Gemma 4 的 26B MoE 在 24 GB 卡上的使用體驗明顯優於其他同級模型，因為活躍參數只有 3.8B，記憶體頻寬壓力小，上下文擴展也更平緩。如果你的應用場景需要長上下文加上穩定的工具呼叫，它目前是消費級硬體上最實用的選擇。
但如果你的場景以中文為主，Qwen 系列在中文任務上的表現通常更好。英文場景下 Gemma 4 和 Qwen 3.5 的差距不大，選擇主要取決於授權偏好和硬體適配。
要不要啟用 Thinking Mode？
Gemma 4 內建推理模式，類似 Claude 的 extended thinking 或 DeepSeek R1 的 chain-of-thought。在系統提示開頭加入 <|think|> 就能啟用，模型會先輸出內部推理過程，再給出最終答案。
實際使用建議：需要數學、程式碼、多步推理的任務開啟它；一般對話和簡單問答關掉，因為推理過程會消耗額外 token，拉長回應時間。如果跑 agentic 工作流，工具呼叫的部分不建議開 thinking mode，會增加不必要的延遲。
微調：消費級硬體也能做
Gemma 4 支援 QLoRA 微調。31B Dense 用 QLoRA 最低只需 16 GB VRAM，透過 Unsloth 或 TRL 操作。完整微調（full fine-tuning）需要至少 80 GB VRAM。
對多數應用場景來說，直接用 instruction-tuned 版本加上好的 system prompt 就夠了。微調值得投入的場景：企業內部特定領域的知識、特殊格式要求、或需要大幅改變模型行為的情況。
部署注意事項
幾個容易踩的坑：
Gemma 4 才發布三天（截至 2026 年 4 月 5 日），各框架的支援還在快速迭代中。Hacker News 上有開發者指出，部分 tokenizer 實現和量化可能存在問題，工具呼叫行為也可能不穩定。碰到異常結果時，先確認你用的是最新版本的 Ollama / llama.cpp / LM Studio。
OpenClaw 的文件也提醒：本地模型跳過了雲端服務商的安全過濾機制，需要把 agent 的權限範圍控制好，compaction（壓縮歷史對話）也要開著，限制 prompt injection 的影響範圍。在 agentic 場景裡，MoE 模型有迴圈（looping）的風險，如果發現 agent 反覆呼叫同一個工具，需要設定 timeout 和最大迭代次數。
常見問題
我的電腦有 8 GB 記憶體，能跑 Gemma 4 嗎？
可以。E2B 和 E4B 在 Q4 量化下分別需要約 4 GB 和 6 GB 記憶體，8 GB 機器跑 E2B 沒問題，E4B 會偏緊但也能用。別嘗試 26B 或 31B，記憶體完全不夠。
Gemma 4 的 26B MoE 跟 31B Dense 怎麼選？
如果你有 24 GB GPU 或 24 GB 以上 Apple Silicon：選 26B MoE。速度快 2–3 倍，品質只差約 3%，而且支援完整 256K 上下文不吃力。31B 適合有 32 GB 以上 VRAM 且追求最高品質的用戶，或者需要微調的場景。
跑 agentic 工作流用哪個模型最穩？
26B MoE 是目前社群共識的本地 agentic 首選。τ2-bench 85.5% 的工具使用準確率已經接近實用門檻。但如果任務特別重視工具呼叫的穩定性，OpenClaw 社群建議 Qwen3-Coder:32B 的失敗率更低。
Mac 跟 PC 哪個比較適合跑本地 LLM？
各有優勢。Mac 的統一記憶體架構在記憶體利用率上更好，不需要在 RAM 和 VRAM 之間搬資料，而且 Ollama 的 MLX 優化讓速度再提升一截。PC 的優勢在 GPU 的原始運算力更強，尤其是高階 NVIDIA 顯卡的 CUDA 生態成熟。AMD Ryzen AI Max+ Pro 395 則是 x86 陣營的統一記憶體方案，128 GB 配置最高可分配 96 GB 給 GPU，能跑 70B 以上的模型，Framework Desktop 售價約 USD 2,566（約 NTD 82,000），比同等記憶體容量的 Mac Studio 便宜不少。預算有限選二手 RTX 3090（約 NTD 19,000–26,000），追求統一記憶體大容量選 AMD Ryzen AI Max+ 或 Mac Studio。
Gemma 4 可以商用嗎？
可以。Apache 2.0 授權允許自由商用、微調、重新分發、修改，沒有月活躍用戶上限或使用場景限制。這是 Gemma 家族第一次採用這麼開放的授權，之前的版本用自訂授權，商用上有灰色地帶。
引用來源
- Google DeepMind — Gemma 4 Official Blog
- Gemma 4 Model Card — Google AI for Developers
- VentureBeat — Google releases Gemma 4 under Apache 2.0
- Hugging Face — Welcome Gemma 4
- Avenchat — Gemma 4 Hardware Requirements Guide
- Unsloth — Gemma 4 Local Deployment Guide
- AMD — Day Zero Support for Gemma 4
- Ollama Blog — MLX on Apple Silicon
Insight
我們團隊在內部部署 OpenClaw，最初用 Claude API 當 orchestrator，後來逐步把執行層的 sub-agent 遷移到本地模型。Gemma 4 發布後，我們第一時間在 Mac Studio M3 Ultra 和雙 RTX 3090 工作站上做了測試。26B MoE 在 agentic 場景下的 function calling 穩定度確實跟社群反映的一致，比 Gemma 3 有質的飛躍。
但我想提醒一件事：本地 LLM 跑 agent 不是裝好就完事了。模型選得再好，如果 system prompt 寫得鬆散、工具定義不清楚、沒有設 timeout 和錯誤處理，agent 一樣會出問題。我們在替客戶規劃 AI agent 架構時，花最多時間的反而不是模型選型，而是工具介面設計和安全邊界設定。
如果你正在評估本地 AI 部署方案，或想了解 OpenClaw + Gemma 4 在企業場景的可行性，歡迎跟 Tenten 團隊預約諮詢。
