1. 普通电脑跑 OpenClaw 本地模型，到底卡在哪一步
很多人第一次听到「本地模型 + OpenClaw 离线部署」，脑子里冒出来的画面是机房、显卡阵列、运维面板。其实真正动手之后你会发现，拦住你的往往不是硬件，而是三个很具体的小问题：模型拉不下来、Ollama 服务只监听 127.0.0.1、OpenClaw 容器里访问不到宿主机的 11434 端口。这三个点任何一个没处理好，界面就会一直转圈或者直接报连接失败。
我自己在 8G 内存的办公本上完整走过一遍流程，从装 Ollama 到 OpenClaw 里跑通对话，中间断网测试也做了。结论先放这里：7B 的 4-bit 量化模型，核显 + 8G 内存确实能跑，日常问答和知识库检索的响应速度可以接受。真正需要提前想清楚的是——你打算让它一直离线，还是离线为主、偶尔切云端补能力。这两种用法在配置上差别不大，但 Key 的管理方式不一样。
这篇就按「先本地跑通，再用统一 Key 打通云端」的顺序来写。前半段是 Ollama 拉模型、暴露服务、OpenClaw 对接的完整命令和配置片段；后半段讲怎么用一套 Key 在本地 endpoint 和云端 endpoint 之间切换，不用每次改代码。适合手里只有一台普通电脑、想先把专属 AI 搭起来再考虑扩展的人。
需要提前说明的是，本地模型和云端模型不是替代关系。本地胜在数据不出机器、断网可用、没有调用费用；云端胜在参数大、知识新、复杂推理稳。OpenClaw 的好处是它把两者都当成 OpenAI 兼容的 endpoint 来对待，所以你可以在同一个界面里配多个模型，按任务切换。下面进入具体操作。
2. Ollama 拉取模型与 OpenClaw 本地 endpoint 配置要点
2.1 先确认你的机器能跑哪个档位
在敲命令之前，先花一分钟对一下硬件。不用记太细，看内存和显存两个数就够：
| 硬件档位 | 参考配置 | 建议模型 | 实际体验 |
|---|---|---|---|
| 入门办公本 | 8G 内存、核显 | qwen2:7b-instruct-q4_0 | 每秒 10-20 token，问答够用 |
| 家用游戏本 | 16G 内存、6G 以上显存 | qwen2:14b-instruct-q4_0 | 响应明显更快，长文更稳 |
| 迷你主机/树莓派 | 8G 内存、ARM | qwen2:2b-instruct-q4_0 | 轻量指令执行，别指望长文 |
| 工作站 | 32G 内存、大显存 | qwen2:72b 量化版 | 接近云端中等模型水平 |
中文场景优先选 Qwen2 系列，对中文的分词和指令跟随做得比较扎实，7B 的量化版在办公问答里很少出现答非所问。模型名后面的q4_0是量化等级，数字越小占用越低，精度损失在 4-bit 这个档位基本可以接受。
2.2 安装 Ollama 并让服务对外可见
装完之后先验证版本，再改监听地址。默认 Ollama 只绑127.0.0.1，容器里的 OpenClaw 是访问不到的，所以必须改成0.0.0.0。
Windows 在系统环境变量里加两项，改完重启终端：
OLLAMA_HOST=0.0.0.0 OLLAMA_MODELS=D:\ollama_modelsMac 或 Linux 直接写进 shell 配置：
export OLLAMA_HOST=0.0.0.0 export OLLAMA_MODELS=/data/ollama_models source ~/.bashrcOLLAMA_MODELS建议指到非系统盘，模型动辄几个 G，放 C 盘容易把空间吃满。改完执行ollama -v确认服务正常，再拉模型：
ollama pull qwen2:7b-instruct-q4_0 ollama run qwen2:7b-instruct-q4_0拉取完成后会直接进对话界面，随便问一句能回就说明模型侧没问题。此时 Ollama 的 API 已经在http://localhost:11434上跑着了，可以用 curl 快速确认：
curl http://localhost:11434/api/tags返回模型列表的 JSON，就说明服务暴露成功。这一步是整个离线部署的地基，后面 OpenClaw 能不能连上，全看这里通不通。
2.3 OpenClaw 侧添加本地模型
OpenClaw 部署好之后，进「模型管理」→「添加模型」，厂商选 Ollama。服务地址这里有个容易踩的坑：
- 如果 OpenClaw 是 Docker 跑的，填
http://host.docker.internal:11434，并且启动容器时要加--add-host=host.docker.internal:host-gateway，否则容器解析不到宿主机。 - 如果是本机直接安装的 OpenClaw，填
http://localhost:11434就行。
模型名称必须和ollama list里显示的完全一致，比如qwen2:7b-instruct-q4_0，少一个字符都会连不上。填完点「测试连接」，提示成功再保存，并设为默认模型。到这一步，断网状态下对话已经可以正常工作了。
3. 可复制的 OpenClaw 本地与云端双 endpoint 配置
3.1 一份 settings 片段管两个模型
OpenClaw 的模型配置本质上是 OpenAI 兼容的 endpoint 列表。下面这份 JSON 可以直接改路径后使用，本地和云端各一条，切换时只改默认项，不用动代码：
{ "models": [ { "name": "local-qwen2-7b", "provider": "openai-compatible", "base_url": "http://host.docker.internal:11434/v1", "api_key": "ollama", "model_id": "qwen2:7b-instruct-q4_0", "context_window": 2048, "is_default": true }, { "name": "cloud-fallback", "provider": "openai-compatible", "base_url": "https://taotoken.net/api/v1", "api_key": "sk-你的TaoTokenKey", "model_id": "claude-sonnet-4-5", "context_window": 8192, "is_default": false } ] }本地这条的api_key填什么都行，Ollama 不校验，写ollama只是占位。base_url注意要带/v1，因为 OpenClaw 走的是 OpenAI 兼容协议。云端这条的base_url用https://taotoken.net/api/v1，Key 在控制台的 API Keys 页面生成。
3.2 用环境变量隔离 Key，别写死在配置里
把 Key 直接写进 JSON 方便演示，但实际用的时候建议走环境变量，尤其是多人共用一台机器的情况：
export TAOTOKEN_API_KEY=sk-你的TaoTokenKey export OLLAMA_BASE_URL=http://host.docker.internal:11434/v1然后在配置里引用：
{ "api_key": "${TAOTOKEN_API_KEY}", "base_url": "${OLLAMA_BASE_URL}" }这样切换环境或者换 Key 的时候不用改配置文件，重启服务即可生效。本地模型和云端模型共用同一套 OpenClaw 界面，你在对话中心选哪个模型，请求就发到哪个 endpoint，互不干扰。
3.3 上下文窗口别照抄云端
本地模型那条我把context_window设成了 2048，不是随便写的。7B 量化模型在 8G 内存的机器上，上下文拉到 4096 会明显吃内存，长对话容易触发换页导致卡顿。2048 对日常问答和知识库检索完全够用，如果你机器内存宽裕，可以往上调，但建议先跑一轮压力测试再定。
4. 验证请求：从 curl 到 OpenClaw 对话的完整链路
4.1 先用 curl 打本地 endpoint
在配置 OpenClaw 之前，先用 curl 确认 Ollama 的 OpenAI 兼容接口能正常返回。这一步能帮你把「模型问题」和「OpenClaw 配置问题」分开：
curl http://localhost:11434/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "qwen2:7b-instruct-q4_0", "messages": [{"role": "user", "content": "用一句话介绍你自己"}], "stream": false }'正常会返回一段 JSON，choices[0].message.content里就是模型的回答。如果这里报model not found，说明模型名写错了；如果连接被拒绝，说明OLLAMA_HOST没生效或者服务没起来。
4.2 再验证云端 endpoint
同样的方式打云端，确认 Key 和网络都正常：
curl https://taotoken.net/api/v1/chat/completions \ -H "Authorization: Bearer $TAOTOKEN_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "model": "claude-sonnet-4-5", "messages": [{"role": "user", "content": "回复 ok"}], "stream": false }'两条都通之后，回到 OpenClaw 的对话中心，分别选本地模型和云端模型各问一句。本地那条可以顺手把网线拔了再问，能正常回复就说明离线链路完全打通。云端那条需要联网，用来处理本地模型搞不定的复杂任务。
4.3 切换策略：什么任务走本地，什么走云端
实测下来比较省心的分工是这样：涉及内部文档、合同、个人笔记的问答全部走本地，数据不出机器；需要最新信息、复杂代码生成、长文推理的时候切云端。OpenClaw 里切换模型就是下拉框选一下，不用重启服务。如果你想让某个数字员工固定用本地模型，在数字员工配置里绑定模型即可，这样即使默认模型改了，它也不会跟着变。
5. 本篇常见报错排查：401、连接失败与模型名不匹配
5.1 401 Unauthorized
云端那条报 401，九成是 Key 的问题。先确认环境变量有没有在当前 shell 生效，echo $TAOTOKEN_API_KEY看输出是否为空。如果是在 Docker 里跑 OpenClaw，环境变量要在docker run时用-e传进去，宿主机 export 的变量容器里读不到。另外检查 Key 有没有多余空格，复制的时候很容易带上换行。
5.2 connection refused / local proxy failed
本地这条报连接失败，按顺序查三件事：OLLAMA_HOST是不是0.0.0.0；防火墙有没有放行 11434；Docker 启动时有没有加--add-host=host.docker.internal:host-gateway。三个都对了还连不上，就在容器里执行curl http://host.docker.internal:11434/api/tags看能不能通，能通说明是 OpenClaw 配置里的地址写错了。
5.3 model not found 与 reading choices 报错
model not found基本都是模型名不一致，用ollama list复制完整名称，注意冒号和横杠。reading choices这类报错通常出现在返回体结构不符合预期的时候，常见原因是base_url少了/v1，请求打到了 Ollama 的原生接口而不是 OpenAI 兼容接口。补上/v1再试。
5.4 OAuth 与鉴权类报错
如果你在 OpenClaw 里配的是需要 OAuth 的云端服务，报鉴权失败时先确认回调地址和当前访问地址一致。用 TaoToken 的 Key 方式接入不涉及 OAuth 流程，直接填sk-开头的 Key 即可，遇到 OAuth 相关提示一般是选错了 provider 类型，改回 openai-compatible 就行。
5.5 三件套检查清单
不管哪条链路出问题，先核对这三项：Base URL 是否带/v1、Key 是否有效且无空格、Model ID 是否和实际模型完全一致。这三件套对了，绝大多数连接问题都能定位到具体环节。
6. 本地离线为主、云端按需补充的接入路径
把本地跑通之后，你会发现 OpenClaw 的模型列表其实就是一个 endpoint 池。本地那条负责隐私和离线可用，云端那条负责能力和知识更新。日常用的时候不需要来回改配置，在界面上切换就行。
如果你还没生成云端那条要用的 Key，可以去控制台的 API Keys 页面创建一个，然后参考接入文档把base_url和model_id填进上面那份 JSON。想先试试模型对话效果再决定要不要长期用，直接进模型对话页面发几条请求感受一下响应质量。长期做编码或者跑 Agent 任务的话，Coding Plan 那条路径在额度管理上会更省心一些。
本地这套搭好之后，建议做一件事：把常用的业务文档丢进 OpenClaw 的知识库，让本地模型基于文档回答。7B 模型单独对话偶尔会飘，但挂了知识库之后，回答会明显收敛到你的资料范围内。这个组合才是我觉得本地部署真正好用的地方——不是替代云端，而是把那些不方便上传的数据留在自己手里。
