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

> 把 OpenAI Codex CLI 的模型后端切到本地 Gemma 4 27B，日常低风险编码任务离线处理，省钱、私密、无心理负担。附完整配置步骤和踩坑记录。

- 原文链接: https://laojin.blog/blog/20260625_codex_local_gemma4
- 作者: 老金
- 发布日期: 2026-06-25
- 标签: Codex, Gemma, 本地模型, AI 编程, Ollama

---

![我把 Codex 接到了本地 Gemma 4：离线写代码，成本降到几乎为零](https://pic-1258874139.cos.ap-hongkong.myqcloud.com/laojinblog/posts/20260625/00_cover.png)

最近我把 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。
- 敏感仓库初步阅读：先本地跑，确认需要再切云端。

![分层使用：云端处理复杂任务，本地处理高频日常](https://pic-1258874139.cos.ap-hongkong.myqcloud.com/laojinblog/posts/20260625/02_two_tier.png)

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

## 准备环境

最简单的链路是：

```bash
Codex CLI -> Ollama -> Gemma 4
```

![Codex CLI 到 Ollama 到 Gemma 4 的调用链路](https://pic-1258874139.cos.ap-hongkong.myqcloud.com/laojinblog/posts/20260625/01_pipeline.png)

### 安装 Ollama

macOS 推荐用 Homebrew 安装：

```bash
brew install ollama
```

安装完成后启动服务：

```bash
brew services start ollama
```

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

### 拉取 Gemma 4

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

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

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

```bash
ollama pull gemma4:12b
```

拉取完成后可以验证：

```bash
ollama list | grep gemma4
```

## 安装或升级 Codex

如果还没有 Codex CLI：

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

然后在项目目录里启动：

```bash
codex
```

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

## 临时使用 Gemma 4

直接一行命令：

```bash
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`。

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

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

或者：

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

## 设置为本地默认模型

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

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

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

之后直接运行：

```bash
codex
```

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

## 踩坑记录

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

1. **`wire_api = "chat"` 已废弃** — 新版 Codex 要求所有 provider 使用 `wire_api = "responses"`。如果你在配置自定义 provider 时用了 `"chat"`，会直接报错并提示修改。

2. **不能覆盖内置 provider** — `ollama` 和 `lmstudio` 是 Codex 内置的 provider ID。如果你在 `[model_providers.ollama]` 下写了自定义配置，会报 `Built-in providers cannot be overridden` 错误。解决方法：删掉自定义配置，直接用 `--local-provider ollama` 即可。

3. **Ollama 软链接失效** — 如果之前用过 Ollama.app（DMG 安装），卸载后 `/usr/local/bin/ollama` 变成断链。用 `brew install ollama` 重新安装会在 `/opt/homebrew/bin/ollama` 创建新的可执行文件。

4. **`codex resume` 会话与 provider 绑定** — 如果你用 `--oss` 创建了一个本地模型会话，之后在同一目录不带 `--oss` 直接 `codex resume <session-id>`，Codex 会尝试用默认云端 provider 去处理本地模型生成的会话内容，导致报错：`invalid_encrypted_content: Encrypted content could not be decrypted or parsed`。解决方法：resume 时必须带上相同的 provider 参数：

    ```bash
    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 交互页面。

**任务描述**：

```text
写一个很炫的3D html页面
```

**观察**：

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

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

## 我的使用建议

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

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

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

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

本地模型的优势是成本低、响应可控，但它仍然可能误判项目约定。让 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 读代码、解释代码、补测试、整理边角逻辑。真正重要的问题，再交给更强的云端模型。

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