我把 Codex 接到了本地 Gemma 4：离线写代码，成本降到几乎为零

最近我把 OpenAI Codex 的本地模型后端切到了 Gemma 4。体验下来，它不适合完全替代云端最强模型，但非常适合做一件事：把日常、低风险、高频的代码工作放到本地跑。

比如解释代码、改小 bug、生成脚手架、写测试、做简单重构。这些任务以前都会消耗云端额度，现在可以交给本地模型慢慢处理。

Codex CLI 本身就是一个可以在终端里运行的编码代理，能读取项目、修改文件、执行命令；而 Gemma 4 是 Google DeepMind 的开放模型系列，官方定位里包含本地运行、编码、推理和 agentic workflows 等场景。

为什么选 Gemma 4 27B 而不是 12B？

Gemma 4 27B 是 MoE（混合专家）架构，总参数 27B，但每次推理只激活约 4B 参数。这意味着：

推理速度接近小模型（活跃参数少）
能力接近大模型（总知识量大）
Q4_K_M 量化后约 17GB，Apple Silicon 统一内存 36GB 的设备完全够用

如果你的设备内存只有 16GB，可以选择 Gemma 4 12B。

为什么要这样接？

我不是为了"完全离线替代 GPT-5.5 / Codex 默认模型"。

真正的价值是分层使用：

复杂架构设计、跨文件大改、线上事故排查：继续用云端强模型。
代码解释、小范围修改、生成测试、批量清理：交给本地 Gemma 4。
敏感仓库初步阅读：先本地跑，确认需要再切云端。

分层使用：云端处理复杂任务，本地处理高频日常

这样做的好处很直接：便宜、私密、可控，而且没有每次提问都在心里计算额度的压力。

准备环境

最简单的链路是：

Codex CLI -> Ollama -> Gemma 4

Codex CLI 到 Ollama 到 Gemma 4 的调用链路

安装 Ollama

macOS 推荐用 Homebrew 安装：

brew install ollama

安装完成后启动服务：

brew services start ollama

注意：如果之前通过官网 DMG 安装过 Ollama 后来卸载了，/usr/local/bin/ollama 可能会变成断链的软链接。这时用 Homebrew 重新安装即可修复。

拉取 Gemma 4

如果你有 36GB 以上内存，推荐 27B 的 Q4 量化版本：

ollama pull gemma4:26b-a4b-it-q4_K_M

如果内存 16GB，选 12B 版本：

ollama pull gemma4:12b

拉取完成后可以验证：

ollama list | grep gemma4

安装或升级 Codex

如果还没有 Codex CLI：

curl -fsSL https://chatgpt.com/codex/install.sh | sh

然后在项目目录里启动：

codex

Codex CLI 支持通过 --oss 使用本地开源模型，内置了对 Ollama 的支持。

临时使用 Gemma 4

直接一行命令：

codex --oss --local-provider ollama -m gemma4:26b-a4b-it-q4_K_M

ollama 是 Codex 的内置 provider，不需要在 ~/.codex/config.toml 里手动定义。如果你在配置文件的 model_providers 中添加了 ollama，反而会报错：model_providers contains reserved built-in provider IDs: ollama。

进入之后可以让它做一个低风险任务：

阅读这个项目，告诉我启动入口、核心模块和测试命令。

或者：

给这个函数补一组单元测试，不要改业务逻辑。

设置为本地默认模型

如果希望每次都默认走本地模型，编辑 ~/.codex/config.toml：

model = "gemma4:26b-a4b-it-q4_K_M"
model_provider = "ollama"

注意：早期版本的 Codex 支持 wire_api = "chat"，但新版已移除该选项，必须使用 "responses"。由于 ollama 是内置 provider，通常不需要手动配置 wire_api，直接设置 model_provider = "ollama" 即可。

之后直接运行：

codex

就会默认走本地 Ollama 里的 Gemma 4。

踩坑记录

实际配置过程中遇到的几个问题：

wire_api = "chat" 已废弃 — 新版 Codex 要求所有 provider 使用 wire_api = "responses"。如果你在配置自定义 provider 时用了 "chat"，会直接报错并提示修改。
不能覆盖内置 provider — ollama 和 lmstudio 是 Codex 内置的 provider ID。如果你在 [model_providers.ollama] 下写了自定义配置，会报 Built-in providers cannot be overridden 错误。解决方法：删掉自定义配置，直接用 --local-provider ollama 即可。
Ollama 软链接失效 — 如果之前用过 Ollama.app（DMG 安装），卸载后 /usr/local/bin/ollama 变成断链。用 brew install ollama 重新安装会在 /opt/homebrew/bin/ollama 创建新的可执行文件。
codex resume 会话与 provider 绑定 — 如果你用 --oss 创建了一个本地模型会话，之后在同一目录不带 --oss 直接 codex resume <session-id>，Codex 会尝试用默认云端 provider 去处理本地模型生成的会话内容，导致报错：invalid_encrypted_content: Encrypted content could not be decrypted or parsed。解决方法：resume 时必须带上相同的 provider 参数：
```
codex resume <session-id> --oss --local-provider ollama -m gemma4:26b-a4b-it-q4_K_M
```
或者直接开一个新会话，不要 resume 旧的本地模型会话。

实际体验：让 Gemma 4 写一个 3D 页面

为了测试 Gemma 4 27B 的实际编码能力，我让它完成了一个有一定复杂度的任务：用 Three.js 写一个带粒子特效的 3D 交互页面。

任务描述：

写一个很炫的3D html页面

观察：

Gemma 4 能正确选择技术栈（Three.js + Import Map + OrbitControls），说明它对前端生态有足够的认知。
它在思考过程中多次自我纠正代码中的 typo（如变量名拼错、十六进制值写错），说明推理能力在线，但一次性生成长代码的稳定性不如云端强模型。
最终输出了一个可运行的单文件 HTML，包含旋转的线框缠绕结 + 星空粒子背景 + 鼠标交互控制。
整体耗时比云端模型长，但对于这种"写完就用、不需要反复迭代"的任务，完全可以接受。

结论：Gemma 4 27B 适合生成自包含的代码片段（单文件组件、脚手架、demo 页面），对于需要跨文件协调、理解复杂项目上下文的任务，还是建议切回云端。

我的使用建议

不要一上来就让本地模型做大规模重构。更稳的方式是把任务拆小：

先只阅读代码，不要修改文件。

只修改这个文件，保持现有 API 不变。

改完后运行现有测试，如果测试失败，先解释原因，不要继续扩大改动。

本地模型的优势是成本低、响应可控，但它仍然可能误判项目约定。让 Codex 保持小步提交、小范围 diff、小任务验证，体验会好很多。

什么时候切回云端模型？

我现在的规则很简单：

要跨多个模块理解业务：切云端。
要处理安全、支付、权限、数据迁移：切云端。
要做代码审查或发布前检查：切云端。
只是生成测试、解释逻辑、改文案、补类型：本地 Gemma 4 足够。

这不是"本地模型赢了云端模型"，而是工作流变得更细了。

云端模型负责高价值判断，本地模型负责高频机械活。Codex 则把这两类模型统一到同一个开发入口里。

我的设备参考

项目	配置
芯片	Apple M3 Pro
内存	36 GB 统一内存
模型	gemma4:26b-a4b-it-q4_K_M (17GB)
量化	Q4_K_M
体验	流畅，推理速度可接受

结尾

把 Codex 接到本地 Gemma 4 后，我最大的感受不是"模型变强了"，而是"使用 AI 写代码的心理成本变低了"。

以前每个问题都像一次 API 调用。现在很多问题更像一次本地命令。

这会改变开发习惯：你会更愿意让 AI 读代码、解释代码、补测试、整理边角逻辑。真正重要的问题，再交给更强的云端模型。

本地模型不是终点，但它很适合成为日常开发的第一层助手。