--- title: OpenClaw 2026 最佳本機 LLM：7 款 Ollama 模型實測排名 description: >- 在 OpenClaw 中實測 Qwen3.6 27B、Gemma 4 8B、Llama 3.3 70B 及其他 4 款模型。涵蓋 VRAM、tokens/s、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 最佳本機 LLM, openclaw ollama, 本機 LLM coding agent, 本機執行 openclaw, ollama 設定 openclaw, qwen 3.6 openclaw, m5 max llm faq: - question: OpenClaw 可以使用本機模型嗎？ answer: >- 可以。在 ~/.openclaw/openclaw.json 中新增 Ollama 或 LM Studio 作為 provider，並將 baseUrl 指向 localhost。OpenClaw 會把本機模型視同雲端 API；工具呼叫和工作流程都完全一樣。 - question: 用 OpenClaw 跑本機模型需要什麼硬體？ answer: >- Qwen3.6 9B 或 35B-A3B MoE：8–16GB VRAM 或 16GB 統一記憶體。Qwen3.6 27B（建議）：18–24GB VRAM（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 VRAM，寫程式能力還贏過 397B MoE。硬體較輕量的人可選 Qwen3.6 35B-A3B MoE：每個前向傳遞只啟動 3B 參數，在 16GB 記憶體上就能跑得很快。 locale: zh-tw translationKey: best-local-models-for-openclaw --- 在本機跑模型，代表不用 API key、沒有用量帳單，也不用把專有程式碼送到別人的伺服器。代價是回應比較慢，困難問題上的品質也較低。這個取捨值不值得，取決於你實際做的任務。 如果你是因為搜尋「openclaw local model」或「openclaw local llm」才找到這篇，建議先從簡單的開始：16GB 機器用 **Gemma 4 8B** 或 **Qwen3.6 9B**；24GB 以上 GPU（單張 RTX 5090 或 M5 Pro）用 **Qwen3.6 27B**；另外保留一個雲端備援，接手本機模型卡住的任務。現在的本機 OpenClaw 已經夠好用，但還不是萬能。 2026 年有兩件事改變了局面。**Qwen3.6 在 4 月 22 日發布**，推出 27B dense 寫程式模型，在 SWE-bench 上打敗 397B MoE。**Apple 的 M5 Max**（2026 年 3 月發表）最高配備 128GB 統一記憶體，而且每個 GPU 核心都有 Neural Accelerator——70B 級模型現在可以在筆電上跑。加上 Ollama 成為 [OpenClaw 官方 provider](https://docs.openclaw.ai)，設定流程變得前所未有的簡單。 ## 模型排行 目前本機模型在 OpenClaw 寫程式任務上的排名，依 SWE-bench Verified 分數、工具呼叫可靠性，以及實際 agent 表現排序： | 模型 | 參數量 | 啟動參數 | 所需 VRAM | SWE-bench | 速度（RTX 5090） | 最適合 | |---|---|---|---|---|---|---| | **Qwen3.6 27B** | 27B | 27B（dense） | 18GB+ | 77.2% | ~70 t/s | 品質／規模比最佳的寫程式模型 | | **Qwen3 Coder Plus** | 72B | 72B（dense） | 48GB+ | 70.6% | ~30 t/s | 最難的寫程式任務、完整 agent loop | | **Qwen3.6 35B-A3B** | 35B | 3B（MoE） | 16GB+ | — | ~180 t/s | 速度優先、高吞吐量 | | **Qwen3.6 9B** | 9B | 9B（dense） | 8GB+ | — | ~186 t/s | 入門硬體、簡單任務 | | **Llama 3.3 70B** | 70B | 70B（dense） | 雙 GPU | — | ~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） | 代理式 coding、工具呼叫迴圈 | | **Gemma 4 8B** | 8B | 8B（dense） | 8GB+ | — | ~150 t/s | 隱私優先、輕量配置 | | **Qwen3 32B** | 32B | 32B（dense） | 24GB+ | — | ~60 t/s | 穩健的全方位選擇、測試案例多 | **Qwen3.6 27B 是新一代的頭號選擇。** SWE-bench Verified 77.2%、Terminal-Bench 2.0 59.3%（與 Claude Opus 4.5 完全打平），而且只要 18GB VRAM 就能跑。27B dense 模型能在寫程式上打敗 397B MoE，靠的是 3.6 版的架構改動——Gated Delta Networks，再加上針對真實 PR 的定向後訓練。 35B-A3B MoE 是最大的變數。每個前向傳遞只啟動 3B 參數，因此在單張 RTX 5090 可以跑到 ~180 t/s。遇到困難問題，品質不如 27B dense；但在讀檔、產生樣板程式碼、簡單編輯上，體感已經接近雲端 API。 新面孔裡有三個值得認識。**gpt-oss 20B** 已成為 16GB 機器上的社群共識——一個小型 MoE，推理強度可調。**Laguna XS 2.1**（Poolside）是 33B/3B 啟動的 MoE，專為代理式（agentic）coding loop 打造。**Kimi K2.7 Code** 則把 Moonshot 接近前沿的 K2 血統帶進 Ollama，適合 48GB 以上配置；完整的開放權重 Kimi K3 會在七月底推出，瞄準有伺服器級硬體的人。 ## 硬體需求 本機模型的品質隨規模提升，而規模又取決於硬體需求。以下分級以 2026 年硬體為準——NVIDIA 方面是 RTX 50 系列，Apple 方面是 M5。 #### 8–16GB VRAM（入門級） 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 VRAM（建議） **單張 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 vs 1,008 GB/s，增加 78%）才是推論的關鍵，不是 raw 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 tensor parallelism 跑出 27 t/s——表現接近 H100，但成本只要零頭。最適合可以裝兩張卡的桌機。 - **M5 Max 128GB MacBook Pro**：70B Q4_K_M 模型（磁碟上約 40GB）可以完整載入統一記憶體，而且還有餘裕放 context。Apple 在每個 GPU 核心內建的 [Neural Accelerators](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 現在是官方 provider，設定流程非常直接。執行首次設定精靈： ```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 那麼細膩，但拿來摸索陌生 codebase 已經夠用。 - **常見模式的程式碼生成。** 樣板程式碼、CRUD、設定檔、測試骨架。多數時候第一次就能寫出能跑的程式。3.6 版是拿真實已合併 PR 做後訓練的，從 diff 品質就看得出來。 - **檔案操作與簡單重構。** 列出檔案、搜尋模式、跨檔案重新命名變數。這類不需要深度推理的機械性工作很穩。 - **代理式工具呼叫。** Qwen3.6 把 function calling 的可靠性拉高一截——Terminal-Bench 2.0 的 59.3% 與 Claude Opus 4.5 打平。對 OpenClaw 的工具迴圈來說，這代表「模型呼叫錯函式或參數不正確」的狀況變少了。 ## 本機模型的不足之處 - **跨檔案重構。** 只要是需要同時掌握 5 個以上檔案的任務，就會變得不穩；模型不是搞丟上下文，就是前後改法不一致。200K+ context window 的雲端模型在這裡仍有優勢，不過 Qwen3.6 已把差距縮小。 - **複雜除錯。** 如果 bug 需要跨多層抽象去推理，本機模型常會給你表面修法，但問題其實更深。Claude Opus 4.8 在 SWE-bench Verified 上仍比 Qwen3.6 27B 高約 11 分，Claude Fable 5 則高約 18 分。 - **舊硬體上的 dense 模型速度。** 27B 模型在單張 RTX 5090 上約 70 tokens/s，在 M5 Max 上約 22 t/s。如果你還在用 3090 或 4090，預期大概 30–40 t/s。（35B-A3B MoE 的 180+ t/s 是例外。） - **超長 context。** Qwen3.6 理論上支援到 256K tokens，但在消費級硬體上超過 32K 之後，推論品質會下滑。請在設定中把 `contextWindow` 設成實際可用的值。 ## 混合方案 多數嘗試本機模型的人，最後都會走向混合配置：瑣碎任務交給本機，難題交給雲端。 ```json5 { agents: { defaults: { model: { primary: "ollama/qwen3.6:27b", thinking: "anthropic/claude-sonnet-4-6-20260514" } } } } ``` 本機模型負責讀檔、簡單編輯和樣板——大約佔一般寫程式 session 的 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 對多數人來說是最佳平衡點——品質幾乎沒差，記憶體省很多。 **Tool calls 失敗。** 在模型設定中把 `"reasoning": false` 設為 false，並優先使用 Qwen3.6 系列——它們處理 OpenClaw 的 tool-calling 格式比 Mistral 或舊 Llama 更可靠。若仍失敗，請更新 Ollama 到最新版；官方 provider 整合修掉了幾個邊界案例。 **Context window 錯誤。** 在設定中給出正確的 `contextWindow`。Qwen3.6 系列在 24GB+ VRAM 硬體上（單張 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)。*