在 Codex CLI 中本地運行 Gemma 4 的實戰經驗與硬體踩坑

原始來源與檔名：在Codex-CLI中本地運行Gemma4.md

來源：Daniel Vaughan on Medium — 2026-04-13

NAPKIN | 餐巾纸

餐巾紙公式

本地 Agent 效能 = 模型原生工具呼叫能力 (86.4%) + 硬體記憶體頻寬 (MB/s) + 錯誤重試次數

一句話

作者實測將 Gemma 4 (具備 86.4% 工具呼叫成功率) 部署於本地端，作為 Codex CLI 的底層模型以取代付費的雲端 API。測試比較了 M4 Pro Mac (26B MoE 透過 llama.cpp) 與 NVIDIA Blackwell GB10 (31B Dense 透過 Ollama)。結果發現：雖然 Mac 因為 MoE 架構在 Token 生成速度上快了 5.1 倍，但由於量化與模型架構差異，其邏輯準確度較低，導致反覆重試修 Bug 浪費時間；反而是較慢的 31B Dense 模型在 GB10 上一次成功，凸顯了在 Agentic 工作流中「一次寫對」遠比「生成速度」重要。

餐巾紙草图

[ Local Agent Evaluation ]
Task: Write CSV parser, add tests, run them.

[ MacBook Pro (M4 Pro, 24GB) ]
  - Engine: llama.cpp (Q4_K_M)
  - Model: Gemma 4 26B MoE
  - Speed: 52 tok/s (Fast! Due to sparse activation)
  - Result: 10 tool calls, left dead code, 5 failed test writes. Total 4m42s.

[ Dell Pro Max GB10 (NVIDIA Blackwell 128GB) ]
  - Engine: Ollama v0.20.5
  - Model: Gemma 4 31B Dense
  - Speed: 10 tok/s (Slower)
  - Result: 3 tool calls, correct on first try. Total 6m59s.

Insight: First-pass reliability beats raw generation speed for Agent workflows.

ROUND 1: SKELETON | 骨架掃描

• 核心問題: 使用 Codex CLI 這類 Agentic 開發工具若完全依賴雲端模型 (如 GPT-5.4)，會面臨高昂的 API 成本、企業隱私考量以及依賴外部網路連線的問題。但過去的本地模型 (如 Gemma 3 工具呼叫成功率僅 6.6%) 根本無法承擔 Agent 工作。
• 核心答案: 測試 Gemma 4 (工具呼叫成功率達 86.4%) 在本地端的實戰表現。作者分別在 Apple Silicon (MacBook Pro) 與 NVIDIA Blackwell (GB10 伺服器) 上進行硬體、推論引擎與實作任務的壓力測試。

ROUND 2: DISSECTION | 血肉解剖

• 硬體踩坑與參數調教:
  • Mac (Apple Silicon): Ollama v0.20.3 有串流 Bug 與長上下文當機問題。必須改用 llama.cpp，並且精確設定參數：-np 1 (限制 Slot 節省記憶體)、-ctk q8_0 -ctv q8_0 (KV Cache 量化)、--jinja (確保工具呼叫模板正確)。
  • NVIDIA (GB10): vLLM 遭遇 PyTorch 依賴版本問題。改用 Ollama v0.20.5 則一次成功。
• 生成速度的物理學 (MoE vs Dense):
  • 兩台機器的記憶體頻寬都是 273 GB/s。
  • Mac (26B MoE) 速度快達 5.1 倍 (52 tok/s)。因為 MoE (混合專家) 架構每次生成 Token 時只需載入活躍的 3.8B 參數 (約 1.9GB)，頻寬消耗極小。
  • NVIDIA (31B Dense) 速度較慢 (10 tok/s)。因為每次都要載入完整的 31B 參數 (約 17.4GB)，受到頻寬瓶頸限制。
• 準確率大於速度:
  • Mac 的 26B MoE 在實作程式碼時留下了死代碼 (Dead code) 並經歷了多次測試失敗與重試 (10 次工具呼叫)。
  • NVIDIA 的 31B Dense 一次寫對 (3 次工具呼叫)。
  • 結論：在 Agentic 開發中，模型「做對決策」的品質遠比「生成字串」的速度重要，因為每一次修正錯誤 (跑測試、讀 Log) 都要耗費大量的系統時間。

ROUND 3: SOUL | 靈魂提取

• 深層洞見: 「Memory Bandwidth as the Ultimate Bottleneck (記憶體頻寬即最終瓶頸)。」 這篇文章精彩地揭示了 LLM 推論的底層物理學：生成速度受限於記憶體頻寬，這推動了 MoE 架構的發展。同時也指出，未來開發者在配置本地 AI 開發環境時，混合策略 (Hybrid Approach) 才是王道——日常迭代與隱私代碼使用本地端 Gemma 4，遇到高難度邏輯時才切換至雲端 API。

Hardware Constraints & Agent Reliability (Architectural Deep Dive)

Inference Engine 的生態碎片化 (Fragmentation)

這篇文章展示了在本地端部署最新模型時，推論引擎 (Ollama vs llama.cpp vs vLLM) 面臨嚴重的生態碎片化問題。

• Ollama 在 Mac 上有 Streaming Parser Bug (錯把 tool_calls 塞進 reasoning 中)。
• vLLM 面臨 CUDA 與 PyTorch 版本的 ABI 不相容。
• llama.cpp 需要手動微調 KV Cache 的量化參數才能避免 OOM (Out Of Memory)。 對系統架構師而言，這意味著本地 Agent 系統仍處於「需要高度領域知識」的階段。我們必須理解底層模板引擎 (Jinja) 如何組裝 JSON，才能保證 Function Calling 的穩定性。這也是為何未來像 Ollama Cloud 這種提供標準化 API 的服務極具價值。

First-Pass Reliability (首輪可靠性) 決定 Agent 的總耗時

在傳統的 Chatbot 體驗中，Token 生成速度 (tok/s) 是唯一指標。但在 Agentic System 中，錯誤修正成本 (Cost of Correction) 極高。 當模型寫錯代碼時，它必須經歷：

1. 等待測試框架執行失敗
2. 讀取 Error Log
3. 將 Error Log 送回 Context Window
4. 重新進行 Prompt Processing (動輒消耗數萬 Token 計算) 因此，雖然 Mac 在 Token 生成上快了 5 倍，但因為重試了 10 次，最終只比 NVIDIA 慢模型快了 30% 且留下了髒代碼。這在架構設計上的啟示是：如果模型沒有達到某個臨界的推理能力 (Reasoning Threshold)，給它再快的硬體也沒有意義，因為它只會更快速地陷入錯誤迴圈 (Failure Loops)。