--- title: 2026 年 OpenClaw 最佳本地大模型：7 款 Ollama 模型排名 description: >- 在 OpenClaw 中实测了 Qwen3.6 27B、Gemma 4 8B、Llama 3.3 70B 及另外 4 款模型，涵盖显存占用、token/秒、SWE-Bench 得分，以及 M5 Max 与 RTX 5090 各自该选哪款。 date: 2026-03-12T00:00:00.000Z updatedDate: 2026-07-23T00:00:00.000Z location: 加利福尼亚州旧金山 – 2026 年 3 月 12 日 image: /images/best-local-models-for-openclaw-hero.jpg keywords: >- openclaw 最佳 ollama 模型, openclaw 最佳本地模型, openclaw ollama, 本地大模型编程智能体, 本地运行 openclaw, ollama 配置 openclaw, qwen 3.6 openclaw, m5 max 大模型 faq: - question: OpenClaw 能使用本地模型吗？ answer: >- 可以。在 ~/.openclaw/openclaw.json 中将 Ollama 或 LM Studio 添加为提供商，把 baseUrl 指向 localhost 即可。OpenClaw 对本地模型和云端 API 一视同仁，工具调用与工作流完全相同。 - question: 使用 OpenClaw 运行本地模型需要什么硬件？ answer: >- Qwen3.6 9B 或 35B-A3B MoE：8-16GB 显存或 16GB 统一内存。Qwen3.6 27B（推荐）：18-24GB 显存（RTX 5090）或 36GB 以上统一内存（M5 Pro/Max）。Qwen3 Coder Plus 或 Llama 3.3 70B：双 RTX 5090 或 96GB 以上统一内存（M5 Max）。 - question: OpenClaw 编程的最佳本地模型是哪款？ answer: >- Qwen3.6 27B 是质量与硬件需求最均衡的选择。它在 SWE-bench Verified 上得分 77.2%，在 Terminal-Bench 2.0 上与 Claude Opus 4.5 持平，仅需 18GB 显存便可运行，并且在编程任务上超过了一个 397B 的 MoE 模型。硬件更轻量的话，Qwen3.6 35B-A3B MoE 每次前向传播只激活 3B 参数，在 16GB 显存上就能快速运行。 locale: zh-cn translationKey: best-local-models-for-openclaw --- 在本地跑模型的好处是：不需要 API 密钥，没有用量账单，也不必将私有代码发到别人的服务器上。但代价是响应更慢，遇到难题时效果也会打折扣。这个取舍是否划算，要看你的具体用途。 如果你搜"openclaw local model"或"openclaw local llm"找到这篇文章，建议从简单方案开始：16GB 内存的机器选 **Gemma 4 8B** 或 **Qwen3.6 9B**；24GB 以上显存的 GPU（单张 RTX 5090 或 M5 Pro）选 **Qwen3.6 27B**；同时保留一个云端回退，处理本地模型卡住的任务。本地 OpenClaw 现在已经很好用，但并非万能。 2026 年有两件事改变了这一局面。**4 月 22 日发布的 Qwen3.6** 带来了 27B 稠密编程模型，在 SWE-bench 上超过了 397B 的 MoE；**Apple M5 Max**（2026 年 3 月发布）则提供 128GB 统一内存，并在每个 GPU 核心中集成 Neural Accelerator，使 70B 级模型如今也能在笔记本上运行。再加上 Ollama 成为 [OpenClaw 官方提供商](https://docs.openclaw.ai)，配置流程比以往任何时候都简单。 ## 模型排名 以下是当前本地模型在 OpenClaw 编码工作中的排名，依据 SWE-bench Verified 得分、工具调用可靠性和真实智能体表现： | 模型 | 参数量 | 激活参数 | 所需显存 | SWE-bench | 速度（RTX 5090） | 最适合场景 | |---|---|---|---|---|---|---| | **Qwen3.6 27B** | 27B | 27B（稠密） | 18GB+ | 77.2% | ~70 t/s | 编程任务中性能与规模的最佳平衡 | | **Qwen3 Coder Plus** | 72B | 72B（稠密） | 48GB+ | 70.6% | ~30 t/s | 最难的编程任务、完整智能体循环 | | **Qwen3.6 35B-A3B** | 35B | 3B（MoE） | 16GB+ | — | ~180 t/s | 对速度敏感的工作、高吞吐场景 | | **Qwen3.6 9B** | 9B | 9B（稠密） | 8GB+ | — | ~186 t/s | 入门级硬件、简单任务 | | **Llama 3.3 70B** | 70B | 70B（稠密） | 双卡 | — | ~27 t/s（2x 5090） | 通用编程，指令遵循能力好 | | **gpt-oss 20B** | 21B | 3.6B（MoE） | 16GB | — | ~160 t/s | 16GB 显存首选，可调推理强度 | | **Laguna XS 2.1** | 33B | 3B（MoE） | 24GB+ | — | 快（MoE） | 智能体式编程，工具调用循环 | | **Gemma 4 8B** | 8B | 8B（稠密） | 8GB+ | — | ~150 t/s | 隐私优先，轻量部署 | | **Qwen3 32B** | 32B | 32B（稠密） | 24GB+ | — | ~60 t/s | 稳健的全能选手，经过广泛测试 | **Qwen3.6 27B 是新的主角。** SWE-bench Verified 77.2%，Terminal-Bench 2.0 59.3%（与 Claude Opus 4.5 完全持平），而且只需 18GB 显存就能运行。一个 27B 的稠密模型能在编程任务上击败 397B MoE，靠的是 3.6 版本中的架构变化——Gated Delta Networks，加上基于真实 PR 的定向后训练。 35B-A3B MoE 更像一个变数。它每次前向传播只激活 3B 参数，所以在单张 RTX 5090 上可以达到约 180 t/s。在难题上质量不如 27B 稠密模型，但在读文件、生成样板代码和简单改动上，体验接近云端 API。 还有三款新模型值得留意。**gpt-oss 20B** 已成为社区公认的 16GB 机器首选，一款支持可调推理强度的小型 MoE。**Laguna XS 2.1**（Poolside 出品）是 33B/3B 激活的 MoE，专为智能体编码循环而设计。**Kimi K2.7 Code** 则把 Moonshot 接近前沿水平的 K2 系列带到 Ollama，适合 48GB 以上显存的用户；若运行服务器级硬件，完整开源权重的 Kimi K3 将于七月底发布。 ## 硬件需求 本地模型的质量随模型规模提升，而模型规模又取决于硬件条件。以下分级基于 2026 年硬件：NVIDIA 侧为 RTX 50 系列，Apple 侧为 M5。 #### 8–16GB 显存（入门级） RTX 5060 / 5070，或 16GB 统一内存（M5 基础版、M5 Pro 入门版）。足以运行 Qwen3.6 9B 和 35B-A3B MoE。9B 在 5090 上处理简单任务和代码摘要时可达约 186 t/s；在 5070 上预计约 120 t/s。35B-A3B 的实际内存占用远低于按参数量推算的水平，因为每次前向传播只激活 3B 参数。 适用模型：Qwen3.6 9B、Qwen3.6 35B-A3B、Gemma 4 8B #### 18–32GB 显存（推荐） **单张 RTX 5090（32GB GDDR7，1,792 GB/s）**，或 36–64GB 统一内存（M5 Pro / M5 Max 基础版）。到了这一级，本地模型才真正可用于实际工作。Qwen3.6 27B 在 18GB 显存上运行得很从容，其 SWE-bench 得分（77.2%）能匹敌那些按 token 收费的云端模型。 RTX 5090 相比 4090 的带宽提升（1,792 GB/s 对 1,008 GB/s，提高 78%）对推理才是关键，而非原始 FLOPS。Token 生成受内存带宽约束，单张 5090 在 Qwen 8B 上约能生成 186 t/s，在 14B 级模型上约 124 t/s。 适用模型：Qwen3.6 27B、Qwen3 32B、Qwen3.6 Plus（内存充足时） #### 48GB+ 可用内存（高端） **双 RTX 5090**（合计 64GB），或 **96–128GB M5 Max 统一内存**。Qwen3 Coder Plus 和 Llama 3.3 70B 属于这一档。 两条路线： - **双 5090 主机**：在 Llama 70B Q4_K_M 上使用 vLLM 张量并行可达 27 t/s，接近 H100 的水平，成本仅为 H100 的零头。适合能装下两张卡的台式机。 - **M5 Max 128GB MacBook Pro**：70B Q4_K_M 模型（磁盘上约 40GB）可完全载入统一内存，还有充足空间留给上下文。Apple 嵌入每个 GPU 核心的 [Neural Accelerator](https://machinelearning.apple.com/research/exploring-llms-mlx-m5) 让 prompt 处理速度比 M4 Max 快 3.3–4 倍，稳态生成速度约 18–25 t/s。它换来的则是便携性：这是唯一能装进背包的方案。 适用模型：Qwen3 Coder Plus、Llama 3.3 70B、Qwen3.6 Plus 全精度 配备 128GB 统一内存的 M5 Max，是在笔记本上认真做本地开发的新一代最佳平衡点。Apple 的 MLX 框架现已原生支持 Neural Accelerator，这意味着 GPU 和 Neural Engine 会在每次前向传播中协同工作，而非二选一。

手头的硬件达不到这些档位？haimaker 为 OpenClaw 提供一个统一的云端路由端点，让本地模型胜任的任务在本地跑，处理不了的场景自动回退到云端。

试用 HAIMAKER 云端路由
## 配置 Ollama Ollama 是运行本地模型最简单的方式。安装后拉取一个模型，就能在 localhost 上获得一个 OpenAI 兼容 API。 ```bash # Install curl -fsSL https://ollama.com/install.sh | sh # Pull a model (pick one based on your hardware) ollama pull qwen3.6:27b # Best quality, needs 18GB+ VRAM ollama pull qwen3.6:35b-a3b # Fast MoE model, runs on 16GB ollama pull qwen3.6:9b # Lightweight, runs on 8GB ollama pull qwen3-coder-plus # Premium, needs 48GB+ or 96GB unified ``` Ollama 默认通过 `http://localhost:11434` 提供 API 服务。 **来自 r/LocalLLaMA 的建议：** 多位用户反馈，对于 27B 及更大的模型，从 Ollama 换到 llama.cpp 可以获得更好性能。Ollama 胜在方便，但 llama.cpp 在量化和内存分配上提供了更多控制权。建议先以 Ollama 起步，遇到性能瓶颈再切换到 llama.cpp。 ## OpenClaw 配置 既然 Ollama 已是官方提供商，配置就很简单。运行配置引导向导： ```bash openclaw onboard --auth-choice ollama ``` 或者手动在 `~/.openclaw/openclaw.json` 中添加 Ollama： ```json5 { models: { providers: { ollama: { baseUrl: "http://localhost:11434/v1", api: "openai-completions", models: [ { id: "qwen3.6:27b", name: "Qwen3.6 27B", reasoning: false, contextWindow: 131072, maxTokens: 8192 } ] } } }, agents: { defaults: { model: { primary: "ollama/qwen3.6:27b" }, models: { "ollama/qwen3.6:27b": { alias: "qwen-local" } } } } } ``` 切换到本地模型： ``` /model qwen-local ``` ## 本地模型擅长什么 本地运行 Qwen3.6 27B 几周后，这些表现比较稳： - **阅读和总结代码。** 问它某函数做了什么，它会给出靠谱的回答。虽然不如 Sonnet 4.6 那么细致，但应对不熟悉的代码库已经足够。 - **常见代码模式的生成。** 样板代码、CRUD 操作、配置文件、测试脚手架，大多数情况下第一次就能写出能用的代码。3.6 版本基于真实合并的 PR 做了后训练，这一点在 diff 质量上体现得很明显。 - **文件操作和简单重构。** 列文件、搜索模式、在单个文件内重命名变量。这些机械任务不需要深度推理。 - **智能体工具调用。** Qwen3.6 将函数调用可靠性提升到新高度——Terminal-Bench 2.0 的 59.3% 与 Claude Opus 4.5 完全持平。对 OpenClaw 的工具循环来说，这意味着"模型用错误参数调用了错误函数"这类错误更少出现。 ## 本地模型的短板 - **多文件重构。** 任何需要跨 5 个以上文件维护上下文的工作都会变得不稳定；模型要么丢失上下文，要么改动不一致。拥有 200K+ 上下文窗口的云端模型仍有优势，不过 Qwen3.6 已缩小差距。 - **复杂调试。** 如果 bug 需要跨多个抽象层进行推理，本地模型通常只给出表面修复，而问题其实在更深处。Claude Opus 4.8 在 SWE-bench Verified 上仍领先 Qwen3.6 27B 约 11 分，Claude Fable 5 领先约 18 分。 - **旧硬件上稠密模型的速度。** 27B 模型在单张 RTX 5090 上约 70 token/秒，在 M5 Max 上约 22 t/s；若你还在用 3090 或 4090，预期大致是 30-40 t/s。（例外是 35B-A3B MoE，可达 180+ t/s。） - **超长上下文。** Qwen3.6 理论上最高支持 256K token，但在消费级硬件上超过 32K 后推理质量会下降。配置中请给 `contextWindow` 设置一个符合实际的值。 ## 混合方案 大多数尝试本地模型的人最终都会走向混合方案：便宜的活儿交给本地，难题交给云端。 ```json5 { agents: { defaults: { model: { primary: "ollama/qwen3.6:27b", thinking: "anthropic/claude-sonnet-4-6-20260514" } } } } ``` 本地模型负责读文件、简单编辑和样板代码，大约占一次典型编码会话的 60-70%。Sonnet 负责调试、架构决策和多文件工作。这样每天 API 费用会从 20-50 美元降到几美元。 当你明确知道某任务需要更强能力时，手动切换： ``` /model sonnet ``` 或者使用 [Haimaker 的自动路由](/blog/openclaw-auto-router-setup/) 帮你处理路由。自动路由会识别任务复杂度，把难题自动交给云端模型，你无需考虑何时切换。 ## 故障排除 **模型加载慢或崩溃。** 很可能是内存不足。试试更小的量化版本：`ollama pull qwen3.6:27b-q4_K_M`，以少量质量损失换更低的内存占用。Q4_K_M 对多数人都是最佳平衡点——质量损失很小，内存节省明显。 **工具调用失败。** 在模型配置中设置 `"reasoning": false`，并坚持使用 Qwen3.6 系列模型；它们对 OpenClaw 工具调用格式的处理比 Mistral 或旧版 Llama 更可靠。如果仍然出错，请将 Ollama 更新到最新版本。官方提供商集成修复了不少边界情况。 **上下文窗口错误。** 在配置中准确设置 `contextWindow`。对于 Qwen3.6 系列，在 24GB 以上显存硬件（单张 RTX 5090 足够）上，131072（128K）是安全默认值；16GB 显存建议设为 32768，以避免质量下降。 **生成速度慢。** 如果在 5090 上跑 27B 模型低于 40 t/s，或在 M5 Max 上低于 18 t/s，请检查是否有其他进程占用 GPU。关闭运行 WebGL 或视频的浏览器标签页。在 Mac 上可打开"活动监视器 → GPU 历史记录"，查看谁在抢占统一内存。M5 用户还应确认 Ollama 使用的是 MLX 后端（v0.21+）；纯 Metal 路径与 MLX 路径在 prompt 处理上的速度差距约为 2 倍。 试用 HAIMAKER 云端路由 --- *关于模型价格对比，请参阅 [OpenClaw 最便宜的模型](/blog/cheapest-models-openclaws)；关于降低云端模型 token 成本，请参阅 [用 QMD 削减 96% 成本](/blog/cutting-ai-agent-token-costs-qmd)。*