我在 Codex CLI 中將 Gemma 4 作為本地模型運行

背景

本文作者 Daniel Vaughan 分享了他在 Codex CLI 環境下，將 Google 最新發布的 Gemma 4 模型作為本地端 Agent 進行開發的實測經驗。他分別在搭載 M4 Pro 晶片的 MacBook Pro 以及配備 NVIDIA Blackwell 晶片的 Dell 工作站上運行 26B MoE 與 31B Dense 版本，旨在探討本地模型是否能在具備工具調用能力的前提下，取代昂貴且有隱私疑慮的雲端模型。

社群觀點

針對這場本地端模型的實戰測試，Hacker News 社群展開了熱烈討論。多數開發者對於 Gemma 4 在工具調用上的進步感到驚艷，認為這標誌著本地模型終於能實質參與開發流程。有使用者分享他在學習 Godot 遊戲引擎時，完全依賴本地運行的 Gemma 4 作為編程夥伴，不僅能處理代碼問題，還能協助篩選官方文件，其表現已足以讓人不再依賴 Claude 等雲端服務。這種「本地優先」的開發模式，對於追求隱私與降低 API 成本的開發者而言極具吸引力。

然而，硬體配置與模型架構的選擇成了討論的另一個焦點。雖然作者觀察到 MoE 架構在 Mac 上因參數激活量較少而擁有更快的生成速度，但社群成員提醒，模型品質與推理精度往往比單純的標記生成速度更為重要。有觀點指出，在進行編程任務時，過度的量化會導致模型邏輯出錯，建議至少維持在 Q6_K 以上的精度。此外，針對 Mac 用戶的硬體選擇，有討論提到記憶體容量是決定性的瓶頸，若要處理如 Codex CLI 般龐大的上下文，升級至更高容量的統一記憶體是不可避免的投資。

在效能優化方面，社群也貢獻了許多進階技巧。例如，有經驗的開發者建議利用「投機採樣」技術，將較小的 MoE 模型作為草稿模型，配合較大的 Dense 模型來提升整體推理速度，據稱在特定配置下可達到顯著的加速效果。同時，也有人針對 llama.cpp 與 Codex CLI 的相容性問題提出警示，建議固定在特定的穩定版本，並改用舊版的補全接口以避免工具調用失效。這些討論反映出，雖然本地 AI 代理已具備實用性，但在環境配置與效能調優上仍存在較高的技術門檻。

延伸閱讀

在討論串中，開發者們提到了幾個實用的工具與資源：

• LM Studio：用於在 Mac 上便捷運行本地模型的圖形化介面工具。
• OpenCode：一個常與本地模型搭配使用的開源編程輔助工具。
• Zed 編輯器：社群提到可透過 ACP 插件將本地運行的 Gemma 4 整合進開發環境。
• llama.cpp 的 GitHub Issue 討論：特別是關於 responses 接口支援不完全與工具調用模板的技術細節。