在配备 128 GB 内存的 M3 Max 上运行 OpenClaw 2026.9.7 和 Ollama 0.35.0 时,OpenClaw 自己的 Ollama 设置所推荐的模型 gemma4 在四项代理任务的全部 12 次评分运行中均通过;gpt-oss:20b 通过了 12 次中的 11 次,失败的工具调用次数几乎是 gemma4 的三倍;而通常作为编程首选的 qwen3-coder:30b 仅通过了 12 次中的 2 次,因为它的工具调用在 Ollama 解析器中不断失败。 我们在全新的工作区中对每个模型的每项任务分别运行三次,通过脚本对结果评分,并记录 OpenClaw 自己的工具和 token 计数以及 Ollama 的服务器日志。测量日期为 2026 年 10 月 1 日。
有关 OpenClaw 本身的费用,以及托管模型的替代成本,请参阅 OpenClaw 定价;有关使用 API 回退运行本地模型,请参阅 OpenClaw 中的多个代理和模型。
运行内容
| 机器 | Apple M3 Max,128 GB 统一内存 |
| OpenClaw | 从 npm 安装的 2026.9.7,Node 24.21.0,openclaw agent --local --json,每次运行一轮 |
| Ollama | v0.35.0 发布二进制文件,原生 API(无 /v1) |
| 模型 | gemma4:latest——7.5B,Q4_K_M,磁盘占用 6.6 GB;gpt-oss:20b——20.9B,MXFP4,13.8 GB;qwen3-coder:30b——30.5B 混合专家模型,Q4_K_M,18.6 GB |
| 上下文 | OpenClaw contextWindow 对三者均设置为 32,768;Ollama 以 131,072 加载 gemma4 和 gpt-oss,以 262,144 加载 qwen3-coder |
| 工具执行 | OpenClaw 的 Docker 沙盒,工作区以读写方式挂载 |
| 运行次数 | 4 项任务 × 3 次重复 × 3 个模型 = 36 次,每次都在全新的工作区并使用全新的 OpenClaw 状态 |
四项任务
| 任务 | 代理需要完成的任务 | 通过条件 |
|---|---|---|
| 读取 | 读取一份 301 行的服务日志,并说出其唯一 ERROR 行中的服务名称 | 回复中包含正确的服务名称 |
| 修复方法 | 运行一个单元测试文件,修复它所测试模块中的错误,然后重新运行——不要修改测试 | 测试以退出码 0 结束,且测试文件逐字节一致 |
| 统计 | 统计五个 CSV 文件中的数据行数,并将计数写入 counts.json | counts.json 等于预期对象 |
| 两个文件修复 | 两个模块中存在两个彼此独立的错误,导致三个测试失败;修复两者,但不要改动测试 | 所有测试均以 0 退出,且测试结果逐字节一致 |
结果
| 模型 | 任务 | 通过 | 中位用时 | 工具调用中位数 | 失败的工具调用(3 次运行) | 输入 / 输出 Token 中位数 |
|---|---|---|---|---|---|---|
gemma4:latest | t1-read | 3/3 | 50.2 秒 | 1 | 0 | 21,438 / 19 |
gemma4:latest | t2-fix | 3/3 | 47.5 秒 | 4 | 0 | 13,387 / 866 |
gemma4:latest | t3-count | 3/3 | 37.9 秒 | 7 | 1 | 13,073 / 513 |
gemma4:latest | t4-multi | 3/3 | 75.1 秒 | 10 | 6 | 16,417 / 2,441 |
gpt-oss:20b | t1-read | 3/3 | 38.7 秒 | 3 | 5 | 16,971 / 508 |
gpt-oss:20b | t2-fix | 3/3 | 54.2 秒 | 7 | 6 | 12,409 / 1,193 |
gpt-oss:20b | t3-count | 2/3 | 76.5 秒 | 10 | 5 | 13,247 / 1,713 |
gpt-oss:20b | t4-multi | 3/3 | 65.1 秒 | 11 | 3 | 13,065 / 1,380 |
qwen3-coder:30b | t1-read | 0/3 | 25.1 秒 | 0 | 0 | 8,915 / 38 |
qwen3-coder:30b | t2-fix | 0/3 | 34.8 秒 | 3 | 0 | 9,435 / 163 |
qwen3-coder:30b | t3-count | 2/3 | 36.9 秒 | 3 | 0 | 9,503 / 279 |
qwen3-coder:30b | t4-multi | 0/3 | 42.5 秒 | 5 | 0 | 9,992 / 243 |
时间是每次运行的实际墙上时钟时间,包括约五到七秒的 OpenClaw 启动时间。“输入 Token”是 OpenClaw 记录的未缓存输入;它重新从缓存发送的上下文还要额外计入,并在下方的成本部分计算。失败工具调用列统计的是 OpenClaw 记录的失败次数;qwen3-coder 的失败发生在调用到达 OpenClaw 之前,因此此处显示为零,详情如下。
数字说明了什么
- gemma4 和 gpt-oss:20b 都适合短代理任务。 24 次运行中有 23 次通过,包括两个文件修复任务;该任务需要读取多个模块、编辑其中两个模块并重新运行测试。
- gemma4 的工具使用更顺畅。 在读取任务中,它每次都恰好进行一次工具调用;gpt-oss 进行了三次,其中两次通常在读取文件前就失败了。在全部十二次运行中,gpt-oss 有 19 次失败的工具调用,而 gemma4 为 7;前者每项任务平均进行 9.1 次助手轮次,而 gemma4 为 6.8。
- 唯一一次失败发生在 gpt-oss 的计数任务中:进行十三次工具调用后,它写出了格式错误的 counts.json,并在没有回复的情况下结束了该轮次。
- 速度并不是这里的差异因素。 所有运行中 gemma4 的中位数为 53 秒,gpt-oss 为 54 秒;单次最慢运行是 gemma4 的两个文件修复任务,用时 133 秒,进行了十七次工具调用。qwen3-coder 的运行时间更短,只是因为它们很早就失败了。
- 更大的模型并没有在这些任务上带来更高准确率。gpt-oss:20b 的参数量几乎是 gemma4 的三倍,而专为代码构建的 qwen3-coder:30b 在三者中得分最低。
每个模型运行十二次,足以看出这些任务上的模式,但不足以对模型进行普遍排名。未测试长任务、更大的代码库和其他量化版本。
qwen3-coder:30b 为什么失败
不是因为编码。在它失败的十次运行中:
- 五次在 Ollama 的解析器中结束。 qwen3-coder 将工具调用写成 XML;当参数中包含代码时,它会用
</function>闭合<parameter>元素。Ollama 0.35.0 的服务器日志记录了“qwen tool call parsing failed … XML syntax error … element <parameter> closed by </function>”,而 OpenClaw 以“Agent run failed”结束了该轮次。 - 四次从未进行调用。 回复宣布了下一步,然后将一个单独的
</tool_call>打印为文本,没有任何 Ollama 可以解析为调用的内容;该轮次就此结束。这正是 OpenClaw 文档所关联的/v1URL 症状——但这里发生在原生 API 上。 - 一次是错误答案:它把 CSV 标题行统计为数据行。
解析器属于 Ollama,因此这是 Ollama 0.35.0 的结果,不是对模型的判定。如果你通过 OpenClaw 运行 qwen3-coder,在归咎于模型之前,请查看 ollama serve 的日志中是否有“qwen tool call parsing failed”,并在升级 Ollama 后重新测试。
起关键作用的设置
- 原生 Ollama URL。 OpenClaw 文档称,
/v1OpenAI 兼容 URL“会破坏工具调用,模型可能会将原始工具调用 JSON 作为纯文本输出”;运行使用了不带/v1的baseUrl,并搭配api: "ollama"。 - 在手写条目中固定
contextWindow。 在一次冒烟运行中,没有该设置的显式模型条目解析为 200,000 Token 上下文;OpenClaw 自己的 Ollama 设置会为本地模型写入 32,768,这正是这些运行使用的值。 - Ollama 的上下文是独立的。 Ollama 0.35.0 加载 gemma4 和 gpt-oss 时使用 131,072 Token,加载 qwen3-coder 时使用 262,144 Token——常驻内存为 45.3 GB——无论 OpenClaw 设置为 32,768 还是其他值;决定内存使用的是这个设置,而不是 OpenClaw 的预算。
- 将 Shell 放入沙箱。 在你的机器上运行 Shell 命令的本地模型才是这里的实际风险。使用
sandbox.mode: "all"时,exec 在 OpenClaw 的 Docker 镜像中运行,仅挂载工作区;该镜像使用 OpenClaw 沙箱文档中的docker build命令构建一次。
// ~/.openclaw/openclaw.json — the runs used one model per config; the
// fallbacks line shows the pattern and was not part of the measured runs
{
models: { providers: { ollama: {
apiKey: "ollama-local",
baseUrl: "http://127.0.0.1:11434", // native Ollama URL — no /v1
api: "ollama",
timeoutSeconds: 600,
models: [
{ id: "gemma4:latest", name: "gemma4:latest", contextWindow: 32768, maxTokens: 8192,
params: { keep_alive: "30m" } },
{ id: "gpt-oss:20b", name: "gpt-oss:20b", contextWindow: 32768, maxTokens: 8192,
params: { keep_alive: "30m" } },
],
} } },
agents: { defaults: {
model: { primary: "ollama/gemma4:latest", fallbacks: ["ollama/gpt-oss:20b"] },
sandbox: { mode: "all", workspaceAccess: "rw" }, // shell runs in Docker
} },
tools: { exec: { mode: "full" } },
}本地运行的成本
本地模型用时间、磁盘和电力成本替代按 Token 计费。每次运行中,OpenClaw 记录 gemma4 约有 16,415 个未缓存输入 Token、78,469 个重新发送的缓存上下文 Token 和 1,142 个输出 Token;gpt-oss 则分别为 13,761、88,688 和 1,192。粗略计算——不同模型的分词器有所不同——按 Claude Haiku 4.5 的 Kunavo 费率(每百万 Token 的输入 $0.70、缓存 $0.07、输出 $3.50)计算,每次运行约为 $0.021 和 $0.020。未测量功耗;每次运行的电费为瓦特 × 秒 ÷ 3,600,000 × 你的每千瓦时价格。
实际可行的模式是使用本地模型作为主要模型,并为本地模型失败的轮次配置托管回退。OpenClaw 为每个代理接受一个 fallbacks 列表;Kunavo 密钥可作为与 Ollama 并列的 OpenAI 兼容提供商使用,费用按预付余额中的 Token 计费。Kunavo 没有人使用其端点运行过 OpenClaw——这些运行完全在本地进行。
常见问题
OpenClaw 最佳本地模型是什么?
在我们测量的三个模型中,gemma4 表现最好——它也是 OpenClaw 自己推荐的 Ollama 模型。在配备 128 GB 内存的 M3 Max 上运行 OpenClaw 2026.9.7 和 Ollama 0.35.0 时,gemma4(7.5B,Q4_K_M)在四项任务的全部 12 次评分运行中均通过;gpt-oss:20b(20.9B,MXFP4)通过了 12 次中的 11 次,失败的工具调用为 19 次,而 gemma4 为 7 次;qwen3-coder:30b 仅通过了 12 次中的 2 次,因为它的工具调用在 Ollama 解析器中不断失败。这是针对短任务的三个模型结果,不是对所有本地模型的排名。
OpenClaw 可以配合 Ollama 完全离线运行吗?
模型调用可以:当提供商指向本地 Ollama 主机时,这些运行中的每一次模型请求都发送到了 127.0.0.1。请使用原生 URL http://127.0.0.1:11434,而不是 /v1 OpenAI 兼容 URL——OpenClaw 的 Ollama 文档指出,/v1 会破坏工具调用,并可能导致模型将原始工具调用 JSON 输出为文本。仍需访问互联网的技能或工具仍然需要网络,此外 OpenClaw 的 Docker 沙盒镜像必须构建一次(不会自动拉取)。
本地 OpenClaw 模型需要多少内存?
在磁盘上,gemma4 占用 6.6 GB,gpt-oss:20b 占用 13.8 GB,qwen3-coder:30b 占用 18.6 GB。加载后,Ollama 报告 gpt-oss 占用 13.7 GB、qwen3-coder 占用 45.3 GB,因为 Ollama 0.35.0 自行确定了上下文大小——gemma4 和 gpt-oss 为 131,072 个 token,qwen3-coder 为 262,144 个 token——不受 OpenClaw 被告知的 32,768 影响。在 128 GB Mac 上,这些都能装下;在 16 GB 或 32 GB 机器上,如果不使用更小的上下文则无法装下。未测试更小内存的机器。
与 API 相比,本地模型是免费的吗?
Not free, just billed differently: you pay in time, disk and electricity instead of per token. Each run here used about 95,000–105,000 tokens counting OpenClaw's re-sent context — on a metered API at Claude Haiku 4.5 rates that would be roughly $0.021 a run, as rough arithmetic across different tokenizers. A local run took about 54 seconds; power draw was not measured, so the electricity side is a formula: watts × seconds ÷ 3,600,000 × your price per kWh.
为什么 qwen3-coder 在使用 Ollama 的 OpenClaw 中会失败?
在我们的运行中,问题出在工具调用格式,而不是代码。qwen3-coder 以 XML 格式写入工具调用,在 Ollama 0.35.0 上,其 12 次运行中有 5 次最终在 Ollama 的服务日志中报告“qwen tool call parsing failed”——一个 XML 语法错误:<parameter> 元素却由 </function> 关闭;随后 OpenClaw 以“Agent run failed”停止。另有 4 次将单独的 </tool_call> 作为文本输出,没有任何 Ollama 能解析的调用,因此没有执行任何操作。在责怪模型之前,请检查服务日志中是否存在该警告,并在更新版本的 Ollama 上重新测试:解析器属于 Ollama,这一结果仅针对 0.35.0。
手动向 OpenClaw 添加 Ollama 模型时,为什么要设置 contextWindow?
因为在我们的冒烟测试中,不设置该字段的显式模型条目会解析为 200,000 个 token 的上下文,远超大多数本地模型的处理能力;而 OpenClaw 自己的 Ollama 设置会为本地模型写入 32,768。固定 contextWindow(以及 maxTokens)可以使 OpenClaw 的压缩预算保持合理。它不会改变 Ollama 自己的 num_ctx:在这里,Ollama 仍然以 131,072 加载了这些模型。
于 2026 年 10 月 1 日在 Apple M3 Max(128 GB)上运行:OpenClaw 2026.9.7(npm,Node 24.21.0)、Ollama v0.35.0(发布二进制文件)、从 Ollama 注册表拉取并通过 sha256 校验的 gemma4:latest、gpt-oss:20b 和 qwen3-coder:30b。36 次运行中的每一次都使用全新的工作区和全新的 OpenClaw 状态,在 OpenClaw 的 Docker 沙箱中使用 exec,并使用脚本评分器;工具调用和 Token 计数是 OpenClaw 自己的 JSON 输出。任务测试夹具、评分器和适配器脚本随本页面的证据一同发布。未测量:功耗、长任务、其他量化版本或更小的机器。