Gemma 4 31B 本地部署實戰: Mac Studio 512GB 跑 OpenClaw 完整指南

Gemma 4 31B 在 2026 年 4 月 2 日正式發布，是 Google DeepMind 目前最強的開源模型，在 LMArena 文字排行榜拿到 1452 分、全球開源模型第三名。如果你手上有一台 Mac Studio M3 Ultra 512GB，這台機器的統一記憶體是 Gemma 4 31B 滿精度推論（BF16 約 62GB）的八倍以上，跑起來完全不是問題。真正要搞定的是怎麼把它接進 OpenClaw 當本地 AI agent 的推論引擎，同時守住安全底線。

這篇文章從硬體配置、模型選擇、推論堆疊、OpenClaw 整合設定到安全加固，一次講完。

史上最強開源 AI？Gemma 4 本地部署實戰：26B 模型變身私人管家

徹底告別雲端！手把手教你本地部署 Google Gemma 4 26B 開源模型。零延遲、完全隱私，讓頂級 AI 成為你電腦裡的專屬離線智能體，立即看完整實測！

Tenten AIEwan Mak

Gemma 4 31B 是什麼：架構和能力一覽

Gemma 4 家族有四個尺寸：E2B、E4B、26B A4B（MoE）和 31B（Dense）。31B 是品質最高的版本，用的是 Dense 架構，所有 310 億參數在推論時全部參與計算。

幾個值得注意的設計：

混合注意力機制交替使用局部滑動窗口（1024 tokens）和全局完整注意力，最後一層固定是全局注意力。全局層使用統一的 Key-Value 快取加上 Proportional RoPE（p-RoPE），壓低長上下文的記憶體消耗。上下文窗口 256K tokens，原生支援 function calling、可配置的思考模式（thinking mode）、多語言（140+ 語言）、圖片理解、影片理解。

跟前代 Gemma 3 比，31B 在 BigBench Extra Hard 的分數從 19.3% 跳到 74.4%，AIME 2026 從 20.8% 到 89.2%，Codeforces ELO 從 110 到 2150。授權從自訂條款換成 Apache 2.0，商用限制完全取消。

Mac Studio M3 Ultra 512GB：為什麼是本地推論的最佳選擇

Apple 在發表時就明確說了：Mac Studio 能在記憶體裡跑超過 600 億參數的 LLM。512GB 統一記憶體的意思是，你不只能跑 Gemma 4 31B 的 BF16 滿精度，還有大量剩餘空間給 KV cache（256K 上下文需要可觀的記憶體）、macOS 本身、以及 OpenClaw gateway 進程。

統一記憶體架構的關鍵優勢是 CPU 和 GPU 共用同一塊記憶體，不需要像 NVIDIA GPU 那樣在 CPU RAM 和 VRAM 之間搬資料。對 LLM 推論來說，這減少了一個主要的延遲瓶頸。800GB/s 以上的記憶體頻寬確保 token 生成速度維持在合理範圍。

量化等級怎麼選：512GB 不代表無腦 BF16

有 512GB 記憶體不代表一定要跑滿精度。選擇取決於你要拿 Gemma 4 31B 做什麼。

我的建議是在 512GB 的 Mac Studio 上跑 BF16 或 Q8_0。Unsloth 團隊在 Gemma 4 發布當天就提供了 GGUF 和 MLX 格式的量化版本，直接從 Hugging Face 下載就行。如果你計畫同時掛多個模型（例如 Gemma 4 31B 當主推論、另一個小模型處理簡單任務），Q4 量化可以省出空間。

推論堆疊：四種方案的選擇

在 Mac Studio 上跑 Gemma 4 31B，主要有四條路：

1. Ollama（最低摩擦）

Ollama v0.20.0 在 Gemma 4 發布當天就加了支援。兩行指令搞定：

ollama pull gemma4:31b
ollama run gemma4:31b

Ollama 自動偵測 Apple Silicon 並啟用 Metal 加速，暴露 OpenAI 相容的 API 在 http://127.0.0.1:11434/v1。這也是 OpenClaw 預設能偵測到的端點。缺點是量化選項比較少，客製化空間有限。

2. LM Studio（OpenClaw 官方推薦）

LM Studio 是 OpenClaw 官方文件裡「最佳本地堆疊」的首選。下載 Gemma 4 31B 的 GGUF 格式，啟用 MLX 硬體加速，打開本地伺服器（預設 http://127.0.0.1:1234）。LM Studio 支援 Responses API，可以把推理（thinking）和最終回應分開處理。

3. llama.cpp（最大控制權）

直接用 llama.cpp 編譯，在 macOS 上 Metal 支援是預設開啟的：

cmake llama.cpp -B llama.cpp/build -DBUILD_SHARED_LIBS=OFF -DGGML_CUDA=OFF
cmake --build llama.cpp/build --config Release -j

export LLAMA_CACHE="unsloth/gemma-4-31B-it-GGUF"
./llama.cpp/llama-server \
  -hf unsloth/gemma-4-31B-it-GGUF:UD-Q4_K_XL \
  --temp 1.0 --top-p 0.95 --top-k 64 \
  --host 127.0.0.1 --port 8080

llama.cpp 提供最多的參數調整空間，適合需要精細控制上下文長度、批次大小、KV cache 策略的使用者。

4. MLX（Apple 原生框架）

MLX 是 Apple 專為 Apple Silicon 設計的機器學習框架，直接存取統一記憶體，零拷貝架構。Unsloth 提供了 Gemma 4 的 MLX 格式：

curl -fsSL https://raw.githubusercontent.com/unslothai/unsloth/refs/heads/main/install_gemma4_mlx.sh | sh
source ~/.unsloth/unsloth_gemma4

MLX 在 Apple Silicon 上理論效能最好，但生態系統比 llama.cpp 和 Ollama 小，工具鏈成熟度相對低。

OpenClaw 整合設定：把 Gemma 4 31B 接上去

OpenClaw 透過 OpenAI 相容 API 連接本地模型。核心設定檔是 .openclaw/config.json5（或 config.json）。

用 LM Studio 的設定（OpenClaw 官方推薦方式）：

{
  agents: {
    defaults: {
      model: {
        primary: "lmstudio/gemma-4-31b-it"
      },
      models: {
        "anthropic/claude-opus-4-6": { alias: "Opus" },
        "lmstudio/gemma-4-31b-it": { alias: "Gemma4" }
      }
    }
  },
  models: {
    mode: "merge",
    providers: {
      lmstudio: {
        baseUrl: "http://127.0.0.1:1234/v1",
        apiKey: "lmstudio",
        api: "openai-responses",
        models: [
          {
            id: "gemma-4-31b-it",
            name: "Gemma 4 31B IT",
            reasoning: true,
            input: ["text", "image"],
            cost: { input: 0, output: 0, cacheRead: 0, cacheWrite: 0 },
            contextWindow: 131072,
            maxTokens: 8192
          }
        ]
      }
    }
  }
}

幾個關鍵參數說明：

reasoning: true 是因為 Gemma 4 支援思考模式。OpenClaw 的 Responses API 整合會自動把 thinking 內容和最終回應分開。contextWindow 我設 131072（128K）而不是 Gemma 4 31B 的理論最大值 256K，因為 256K 上下文的 KV cache 在實際使用中會吃掉大量記憶體，128K 對多數 agent 任務已經綽綽有餘。cost 全部設 0，因為是本地推論。

用 Ollama 的設定：

Ollama 更簡單——OpenClaw 會自動偵測跑在 http://127.0.0.1:11434/v1 的 Ollama 服務。在 openclaw onboard 的過程中選 Ollama 就行。

混合架構（本地 + 雲端 fallback）：

OpenClaw 支援設定 fallback 模型。本地 Gemma 4 31B 當主力，雲端 Claude 當後備：

{
  agents: {
    defaults: {
      model: {
        primary: "lmstudio/gemma-4-31b-it",
        fallbacks: ["anthropic/claude-sonnet-4-6", "anthropic/claude-opus-4-6"]
      }
    }
  }
}

這樣當本地模型過載或重啟時，OpenClaw 自動切換到雲端，不中斷服務。

安全問題：比模型選擇更重要的事

OpenClaw 的安全狀況是 2026 年 AI 圈最大的話題之一。截至 2026 年 3 月底，公開紀錄的 CVE 已經超過 156 個，光是 3 月 18 日到 21 日四天內就披露了 9 個 CVE，其中一個 CVSS 評分 9.9。

除了 CVE，ClawHub 市場上有超過 824 個惡意 skill 被發現（占當時市場的約 20%），包含憑證外洩、後門、挖礦程式。Cisco 的 AI 安全團隊實測了第三方 skill，確認在使用者不知情的情況下進行資料外洩和 prompt injection。Microsoft 安全部落格在 2026 年 2 月直接說了：「OpenClaw 不適合在標準的個人或企業工作站上執行。」

跑本地模型時的安全加固清單：

1. 更新到最新版本（至少 2026.3.21 之後的版本）
2. gateway 綁定 127.0.0.1，不要開放外部存取。需要遠端存取就用 VPN 或 SSH tunnel
3. 不要用預設的認證 token，換成強密碼
4. 只從驗證過的發布者安裝 skill
5. 啟用 sandbox 模式，但注意 sandbox 的子進程逃逸問題（CVE 已修補，確認你的版本有這個 patch）
6. 本地模型不經過雲端提供商的安全過濾，prompt injection 的風險更高。OpenClaw 官方建議用最強的模型來降低風險，Gemma 4 31B 的能力在開源模型裡算頂級，但跟 Claude Opus 或 GPT-4 級別的 prompt injection 防禦力還是有差距
7. 開啟 compaction 來控制上下文膨脹
8. 定期檢查 SOUL.md 和 MEMORY.md 有沒有被注入惡意指令

Gemma 4 31B vs 26B A4B：哪個更適合 OpenClaw？

這是很多人會問的問題。26B A4B 是 MoE 架構，總參數 26B 但每次推論只啟動 3.8B，速度接近 4B 模型，LMArena 分數 1441，只比 31B 的 1452 低一點點。

在 Mac Studio 512GB 上，記憶體完全不是限制。我的判斷是：如果 OpenClaw 是你的主要 AI 助手，需要處理複雜的多步驟任務、function calling 鏈和長上下文，用 31B。如果你需要快速回應、低延遲，或者同時跑多個 agent 子任務，26B A4B 是更聰明的選擇。混合架構也行——主 agent 用 31B，子 agent 用 26B A4B。

推論參數建議

Google 官方和 Unsloth 都建議 Gemma 4 使用以下推論參數：

temperature: 1.0
top_p: 0.95
top_k: 64
repetition_penalty: 1.0（不啟用）

注意 repetition_penalty 要保持 1.0（預設值），不要調高，否則 Gemma 4 容易出現品質下降或迴圈。Thinking mode 可以在 system prompt 裡透過 <|think|> token 控制開關。

效能預期：實際能跑多快？

目前 Gemma 4 31B 在 Mac Studio M3 Ultra 上的公開 benchmark 數據還很少（模型剛發布不到 24 小時）。根據相近架構模型（如 Llama 3.1 70B 的 Q4 在類似硬體上的表現）估算：

BF16 滿精度大概在 5-10 tokens/sec，Q8 大概 10-20 tokens/sec，Q4 可能到 20-35 tokens/sec。這些是粗略估計，實際數字取決於上下文長度、批次大小和具體的推論引擎。Gemma 4 31B 比 Llama 70B 小很多，記憶體頻寬壓力也小，token 生成速度應該會更好。

對 OpenClaw 的互動式使用來說，10 tokens/sec 以上就能提供流暢的對話體驗。如果你覺得慢，切到 26B A4B 會有明顯改善。

Gemma 4 31B 的 Apache 2.0 授權對企業意味著什麼？

Apache 2.0 沒有月活用戶限制、沒有可接受使用政策限制、不需要向 Google 回報使用方式。跟 Meta 的 Llama 4 社群授權相比，Apache 2.0 對企業自建 AI agent 友善得多。你可以在不通知 Google 的情況下把 Gemma 4 31B 嵌入商業產品。

512GB 記憶體有沒有可能不夠用？

在跑單一 Gemma 4 31B 的場景下，幾乎不可能。BF16 模型本身約 62GB，加上 128K 上下文的 KV cache 大概再吃 40-60GB，macOS 系統和 OpenClaw 進程加起來 20-30GB，總計 150GB 左右。你還有 350GB 以上的餘裕。會接近極限的情況是同時載入多個大模型、或者推到 256K 上下文。

OpenClaw 用本地模型安全嗎？

部分安全。本地模型的好處是你的對話資料不經過任何第三方 API，隱私性比雲端方案好。壞處是本地模型沒有雲端提供商的安全過濾層，prompt injection 攻擊更容易得手。OpenClaw 自己的安全文件也承認這是一個「產業層級的未解問題」。最安全的做法是把 OpenClaw 跑在隔離的虛擬機或專用硬體上，用最強的模型，啟用 sandbox，不要安裝未經驗證的 skill。

Mac Studio M4 Max 128GB 能跑 Gemma 4 31B 嗎？

可以，但上限比較緊。Q4 量化（~20GB 模型）加上短到中等長度的上下文完全沒問題。Q8（~34GB）也行，但長上下文場景記憶體會比較吃緊。BF16 滿精度不建議——62GB 模型加上 KV cache 會超過 128GB。如果你的 Mac Studio 是 M4 Max 128GB，建議跑 Q4 或 Q8 量化。

Gemma 4 31B 的 function calling 品質如何？

Gemma 4 全系列都原生支援結構化工具使用（function calling），不需要額外的 prompt engineering 技巧。模型會回傳符合 schema 定義的 JSON。在 OpenClaw 的 agent 循環裡，function calling 的可靠性直接影響任務完成率。根據目前的 benchmark 和早期使用者回饋，Gemma 4 31B 的 function calling 表現在開源模型裡是最好的之一，但跟 Claude Opus 級別的工具使用能力還有一段距離。

引用來源

• Google DeepMind — Gemma 4 Official Blog
• Hugging Face — Welcome Gemma 4 Blog Post
• OpenClaw — Local Models Documentation
• Microsoft Security Blog — Running OpenClaw Safely
• The Hacker News — OpenClaw CVE-2026-25253
• Unsloth — Gemma 4 How to Run Locally

關於作者

我們實測過 Mac Studio M3 Ultra 搭配 DeepSeek、Qwen、Llama 等多個開源模型。Gemma 4 31B 的 Apache 2.0 授權和原生 function calling 支援，讓它成為企業自建 AI agent 最乾淨的選擇之一。但安全加固的工作量不能低估——尤其是 OpenClaw 在 2026 年第一季暴露出來的那些漏洞，每一個都需要認真對待。

如果你正在評估本地 AI agent 部署方案，包括硬體選型、模型選擇、OpenClaw 安全配置和混合架構設計，歡迎跟 Tenten 團隊預約諮詢。

With over 20 years of experience in technology, and the startup industry, I am passionate about AI and driving innovation. Keeping the engine running

Loading...