周传炽OpenClaw 的模型服务是否支持边缘端实时推理与云端协同？这个问题我在社区里看到过很多次，自己也花了小半个月才彻底搞清楚。起因很朴素：我把 OpenClaw 接进微信当个人助理用，云端大模型聪明归聪明，可每次对话都要转圈两秒起步，聊多了账单也涨得快；换成纯本地模型后延迟确实下来了，但让它写长文或者做复杂分析，又明显不够用。后来我把 OpenClaw 的模型服务层从头到尾翻了一遍，才意识到它本来就不打算让你“单选一个模型”，而是让你同时挂多个模型、按场景自由编排。这篇文章我会先拆解 OpenClaw 的模型服务机制，再分别讲边缘端实时推理要满足的硬指标、云端协同的几种架构，最后给一份我实测的“本地+云端”混合配置和排错经验。如果你正准备做 IM 机器人、智能体二次开发，或者单纯想让 OpenClaw 又快又聪明还省钱，这篇应该能帮上忙。
1. OpenClaw 的模型服务层，本质是一个模型编排网关
1.1 它不绑定任何具体模型，只认 OpenAI 兼容协议
先回答最基础的问题：OpenClaw 的模型服务到底是怎么设计的？我翻配置文件的时候第一感受是，它有点像那种多卡手机——不绑定单一运营商，而是把多家 provider 都收在配置里，需要谁就切谁。OpenClaw 对模型服务的使用，核心是通过一个“模型网关”层实现的，这个网关定义了两件事：一是模型从哪来（provider），二是当前对话用什么模型（model 选择）。
这里的关键在于，OpenClaw 对 provider 的接入几乎全部走 OpenAI 兼容的 /v1/chat/completions 接口。这意味着你不需要为某个模型服务商写专门的适配代码。Ollama 自带 OpenAI 兼容端点，vLLM 启动后也会暴露 OpenAI 兼容端点，NVIDIA NIM、智谱、DeepSeek、OpenAI 本身就更不用说了。所以，本地模型和云端模型在 OpenClaw 眼里其实是同一类东西，只是 base_url 和模型名不同。这一点是整个“边缘+云协同”成立的根基。
我用一个生活化的类比：OpenClaw 的模型服务层就像外卖平台的聚合入口，底下的商家（Ollama、vLLM、云端 API）都支持同一种点餐协议。只要你把每家店的地址和菜单加进平台，用户下单时就完全不用关心这顿饭是隔壁小馆子做的还是五星级酒店做的。
1.2 主模型、辅助模型、skill 模型，各管一段
OpenClaw 里并不是所有事情都由同一个模型干。它内部会区分“驱动智能体决策的主模型”和承担特定任务的辅助模型。比如 active memory（长期记忆）要提取关键信息、生成记忆摘要，通常会调用 embedding 模型或一个更便宜的小模型；再比如 skill 机制，每个 skill 可以在定义时指定自己使用的模型，写小说用大模型、查天气用小模型、做分类用便宜模型，完全可以分开配。
这个设计让“边缘端实时推理与云端协同”从一句口号变成了实际可操作的架构：你完全可以让主对话模型跑在本地边缘端，保证基础回复的实时性；把“写小说”“深度分析”“长文档总结”这些重活，通过 skill 或模型切换交给云端大模型。反过来也行——主模型在云端，本地模型只用于记忆向量化和敏感信息过滤。关键在于 OpenClaw 的模型层不限制 provider，也不限制模型数量，甚至同一个实例里可以随时切换。
1.3 为什么这套设计天然适合混合部署
我见过很多人把“边缘端”和“云端”当成对立选项，其实在 OpenClaw 这里它们是同一份配置文件里的两个条目。你只需要在 providers 里同时声明一个本地 Ollama provider 和一个云端 API provider，再通过模型名指定当前会话用哪个。切换是配置级的，不是代码级的，更不需要重新部署实例。
这一点对“边缘端实时推理 + 云端协同”的落地很关键。你可以把它理解为：OpenClaw 的模型服务层已经帮你把路由做完了，剩下要你自己决定的，只是“什么任务走哪条路”。这也是为什么我建议每个用 OpenClaw 接 IM 平台的人，都尽早把本地模型配上——哪怕平时不常用，至少有个断网也能跑的兜底方案。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 边缘端实时推理，先过这三道硬指标
2.1 “边缘端”不是抬杠的伪概念，一台小主机就算
很多朋友一听到“边缘端”就以为要搞树莓派集群或者专业推理卡，其实在 OpenClaw 的使用场景里，边缘端就是“你手边这台能 7x24 小时开机的机器”。一台 Mac mini、一台 NUC、一台淘汰下来的笔记本，甚至一台普通迷你主机，都可以作为边缘推理节点。热搜里很多人问“mac mini 使用 docker 本地部署 openclaw”，其实就是这个思路：OpenClaw 本体跑在边缘小主机上，模型服务也用同一台机器上的 Ollama 容器，外部通过 IM 平台交互。
边缘端在这里承担的是“实时”任务，它要满足的不是数据中心那种万级并发，而是“一个人或一个小团队日常对话不卡顿”。按我的标准，从用户发出消息到 OpenClaw 开始回话，首 token 延迟在 2 秒以内就算及格；如果整个回复能在 5 秒内完整输出，体验就很舒服了。微信群聊问答、私聊助理这类场景，这个门槛其实不高。
2.2 首 token 延迟、吞吐、可靠性，一个都不能少
影响边缘端实时推理体验的，主要是三个指标。
第一是首 token 延迟（TTFT）。它取决于模型加载后的 prefill 阶段速度和请求排队情况。在 Ollama 里，模型第一次被调用时需要把权重加载进内存，冷启动可能要好几秒；但如果你设置为 keep_alive 一直驻留内存，后续请求的 TTFT 就能降到很低。这一点在实际使用中差异巨大，很多人的“本地模型好慢”其实是从没做过热启动优化。
第二是生成吞吐，单位是 tokens/s。对话场景中，7B 量化模型在苹果统一内存或者普通显卡上通常能跑到 20-50 tokens/s，足够流畅阅读；14B 模型如果量化得当也能有 15-30 tokens/s。如果跑 32B 以上模型，就需要更充裕的内存带宽或更强的显卡，否则实时感会明显下降。
第三是长时间运行的可靠性。边缘端机器往往不是专用服务器，可能还跑着其他服务，内存占用、CPU 调度、温度降频都会影响推理。我实测下来，一个比较稳妥的组合是：OpenClaw 用 Docker 跑，Ollama 也容器化，两者之间走宿主机端口通信，设置好内存上限，避免模型自动换入换出。
我整理了一个表，方便你直观对比：
| 模型规模 | 量化级别 | 内存占用 | 实测对话感受 |
|---|---|---|---|
| 7B | Q4_K_M | 约 5-6GB | 非常流畅，群聊秒回 |
| 14B | Q4_K_M | 约 10-12GB | 流畅，复杂任务略吃力 |
| 32B | Q4_K_M | 约 20-24GB | 可接受，建议有统一内存或大显存 |
2.3 本地模型的选型：7B 能用，14B 更稳，32B 看财力
选型上我的建议是分场景。日常 IM 问答、意图识别、记忆提取，7B 量化模型足够；需要一定推理能力的工具调用、代码辅助，14B 更稳；真要本地跑长文创作，32B 也不是不行，但你要愿意接受硬件投入。
还有一类容易被忽略的模型：embedding 模型和 reranker 模型。OpenClaw 的 active memory 要检索历史记忆，就需要 embedding 模型把文本向量化。这类模型参数量很小（几百 MB 到 1-2GB），在边缘端跑毫无压力，而且很值得放在本地——因为记忆检索往往是高频操作，走云端 API 又慢又贵。我在本地同时挂了对话模型和 embedding 模型，一个负责思考，一个负责记忆，资源占用并不大。这一点到后面讲实际配置时再展开。
3. 云端协同的三种可行架构，实测下来都有价值
3.1 主模型在云，边缘模型只做记忆与过滤
第一种架构是把主对话模型放在云上，比如 DeepSeek、智谱 GLM、OpenAI 这类大模型 API，边缘端跑的都是“配角”模型：embedding 做记忆向量化，小模型做敏感信息过滤、意图分类，甚至把历史对话先做一次摘要再喂给云端大模型。
这种架构的好处是对话质量最高，因为主模型永远是各家最强的那批开源或闭源模型。代价是每次交互都有网络往返，TTFT 至少 1-2 秒，而且如果请求量大，API 成本会直线上升。它适合对回复质量要求高、不能接受本地小模型“胡说八道”的场景，比如正式的工作汇报助手、知识库问答。
3.2 主模型在边缘，云端模型只做兜底
第二种反过来：日常对话由本地模型直接回复，只有本地模型判断“这个问题我搞不定”时才把请求转给云端大模型。怎么判断搞不定？最简单的方式是让本地模型先输出一个“是否需要帮助”的结构化标记，或者你在 skill 层面写好触发条件，比如“用户要求写 2000 字以上的小说”“用户引用了很长一段文档要总结”时，直接走云端。
这种架构我用得最多。本地 7B/14B 模型处理“在不在”“帮我记一下 XX”“今天天气如何”这类高频轻量请求绰绰有余，回复快、不花钱；一旦遇到长文写作或复杂代码分析，再交给云端模型，质量和成本都得到控制。它适合个人助理、群聊机器人这类交互频繁但大部分请求不复杂的场景。
3.3 混合路由：按平台、按 skill、按上下文动态分发
第三种是我最推荐的形态，OpenClaw 的配置结构也让这种方式特别好落地。你可以按三个维度做路由：
- 按平台：微信入口走本地模型（高频、日常），飞书/钉钉入口走云端模型（工作、正式）；
- 按 skill：触发“写小说”“深度分析”这类 skill 时指定云端大模型，普通对话走本地；
- 按上下文长度：检测到当前会话已经是长对话或贴入了超长文本时，自动切到上下文窗口更大的云端模型。
其实 OpenClaw 本身已经有模型切换和多 provider 能力，你只需要把不同平台、不同 skill 的模型预配好，剩下就是策略设计问题。热搜里“openclaw 接入微信”“openclaw 接入飞书”“openclaw 接入钉钉”这些词条都很热，说明很多人都在做 IM 机器人，而 IM 机器人恰恰是最能从“混合路由”中受益的场景：微信里你希望回复快、成本低，飞书里你可能希望更正式、更聪明，同一套 OpenClaw 完全可以同时满足。
4. 一份可复现的“本地+云端”混合配置实测
4.1 我的部署拓扑
先交代一下我的硬件和软件环境，方便你对照。我用的是一台 16GB 统一内存的 Mac mini，Docker 里跑了 OpenClaw 和 Ollama 两个容器；云端配了 DeepSeek 和智谱 GLM 的 API 作为可切换 provider。OpenClaw 通过 IM 平台接入微信，日常入口是本地模型，复杂任务按 skill 路由到云端。
这个“小主机+两个容器+云 API”的组合，我觉得是目前个人玩 OpenClaw 性价比最高的形态。机器功耗低，一年电费也就一两百块；云端 API 只在需要时调用，每月花费可以控制在几十块以内。相比全程用云端 API，省下来的费用还是很明显的。
4.2 一份接近实战的配置示例
下面这个配置是我实测过的结构，但 OpenClaw 的配置字段在不同版本里可能有微调，重点看思路，不要逐字照抄。核心就是：在 providers 里声明本地 Ollama 和云端服务商，在模型策略里把不同用途的模型分开。
yaml复制# 示意配置，字段以你安装版本的官方示例为准
providers:
- id: ollama
type: openai_compatible
base_url: http://127.0.0.1:11434/v1
api_key: ollama
- id: deepseek
type: openai_compatible
base_url: https://api.deepseek.com/v1
api_key: ${DEEPSEEK_API_KEY}
- id: zhipu
type: openai_compatible
base_url: https://open.bigmodel.cn/api/paas/v4
api_key: ${ZHIPU_API_KEY}
models:
fast:
provider: ollama
name: qwen2.5:7b-instruct-q4_K_M
smart:
provider: deepseek
name: deepseek-chat
creative:
provider: zhipu
name: glm-4-plus
skills:
novel:
model: creative
summary:
model: smart
我把 fast 作为默认对话模型，smart 用于文档总结和中等难度任务，creative 用于写小说和长篇创作。在 OpenClaw 里，默认对话走 fast，挂到特定 skill 上的任务自动走对应模型。这样配置完之后，你几乎感觉不到“切换模型”这个动作，因为路由已经替你做了。
4.3 实测效果：延迟、质量、费用三维对比
我记录了一组典型场景的数据。群聊场景下，本地 7B 模型首 token 延迟基本维持在 0.5-1.5 秒（模型已驻留内存），生成速度约 25-35 tokens/s，做到了“随问随答”；同样的问题走云端 DeepSeek，首 token 普遍在 1.5-3 秒，质量确实更好，但日常高频问答里这个差异不明显。写小说场景下，本地 7B 写 2000 字就会跑到质量明显下滑的临界点，而智谱 GLM 或云端 DeepSeek 可以稳定输出更长、情节更连贯的内容，这个钱花得值。
费用方面，纯云端跑一个高频微信群，一天可能消耗几百万 token，按 API 价格算少则几十块、多则上百块；混合模式把 80% 的请求留在本地，只有 20% 的重活走云端，月度成本直接降了一个数量级。这不是夸张，是实际测试下来的结果。
4.4 换模型报错的根因：模型名和 provider 不匹配
热搜里有一条很典型：安装后 agent failed before reply，报错 unknown model: deepsee（deepseek 拼写或标识不一致）。这类问题十有八九不是 OpenClaw 的 bug，而是配置里的模型名和 provider 实际暴露的模型名对不上。云端 API 有一个公开的模型 ID，本地 Ollama 跑起来的模型也有自己的 tag，比如 qwen2.5:7b-instruct-q4_K_M，少写一个冒号后缀或大小写写错，OpenClaw 就会报 unknown model。
排查方法很简单：先直接 curl 一下对应 provider 的 /v1/models 接口，看返回的模型列表里到底有哪些 ID，再回配置里逐个核对。本地 Ollama 可以用 ollama list 查看，云端服务商一般都有文档列出模型 ID。把这一步做好，能省掉大量“看起来莫名其妙”的报错排查时间。
5. 从热搜问题看边缘云协同的真实痛点
5.1 昇腾这类加速卡跑 embedding/reranker 失败，问题多半不在模型
热搜里有一条很具体：昇腾 910B 服务器上不能通过 vLLM 启动 embedding 向量和 reranker 模型。这个问题的本质不一定是模型本身有问题，而是 vLLM 对不同加速卡的适配深度不一样。vLLM 对 CUDA 生态的支持最成熟，对非 NVIDIA 加速卡往往需要指定分支或特定镜像；而 embedding 和 reranker 这类模型，很多时候也不是非要用 vLLM，用专门的 embedding 服务（比如 TEI、sentence-transformers 或者 Ollama 自带的 embeddings 接口）反而更省事。
如果你在边缘端用的是非 NVIDIA 加速卡，我的建议是：对话模型可以继续用 vLLM 或兼容框架，embedding/reranker 单独起一个服务，再让 OpenClaw 走 OpenAI 兼容接口对接。不要把鸡蛋全放在一个篮子里，推理框架兼容性这件事，往往比模型本身更磨人。
5.2 Windows 下报 node runtime not found 和 eBUSY 文件锁
很多人在 Windows 上安装 OpenClaw 时遇到 oneclaw node runtime not found，这通常是 Node.js 运行时路径没被识别，或者是 OpenClaw 使用内置或独立 Node 运行时但安装过程中没有正确解压。我建议先确认系统 Node 版本，再检查 OpenClaw 是否依赖独立运行时，必要时把运行时路径手动写入环境变量。
还有一条常见报错：failed to remove ~\.openclaw: error: ebusy: resource busy or locked, unlink。这是 Windows 文件占用问题，多半是有进程还在使用 .openclaw 目录下的文件，比如正在运行的 OpenClaw 进程、日志服务或者杀毒软件扫描。解决方法是先完全退出 OpenClaw，关掉相关终端窗口，必要时在任务管理器里确认没有残留进程，再执行清理。这个问题看起来跟模型服务无关，但部署不顺利确实会卡住后续所有边缘端配置，值得单独提一下。
5.3 不要把 Docker 端口映射忽略掉
用 Docker 部署 OpenClaw 和 Ollama 时，最常见的坑是容器内模型服务没映射到宿主机端口。OpenClaw 容器里配置的 127.0.0.1:11434，如果只是容器内部地址，而 Ollama 容器没有加 -p 11434:11434 映射，两边根本通信不上。排查的时候先在宿主机上执行 curl http://127.0.0.1:11434/v1/models，能通再查 OpenClaw 侧的配置。
这个问题的隐蔽之处在于，很多人改了配置后立刻重启 OpenClaw 容器，但 Ollama 容器可能早就在跑、却没暴露端口，所以错误信息时有时无，非常容易误导排查方向。
5.4 一条通用的排查链路
把上面这些坑汇总一下，我总结了一条排查链路，按顺序执行能覆盖大部分模型服务相关问题：
- 先确认模型服务本身可用：本地 Ollama 用
ollama list，云端 API 用 curl 请求/v1/models； - 再确认 OpenClaw 能访问到模型服务：检查
base_url是否从容器内可达，端口映射是否正常； - 然后核对配置里的模型名和 provider ID 是否与实际一致；
- 最后看 OpenClaw 日志里的具体报错，是网络层、认证层还是模型不存在。
这个顺序是有讲究的：从下往上排查，每一层都有明确验证手段，避免反复试错。
6. 什么场景适合边缘+云协同，什么场景别硬凑
6.1 适合：IM 高频回复、隐私数据、成本敏感、开发调试
最适合边缘+云协同的，首先是高频 IM 回复。群聊机器人、个人助理这类场景，一天有大量“在不在”“帮我查一下”“提醒我明天开会”这种轻量请求，本地模型完全能覆盖，响应快、零边际成本。其次是隐私敏感数据，比如本地文档问答、企业内部的纪要整理，把内容留在边缘端处理，只把必要的脱敏信息发给云端，能减少数据暴露面。再次是开发调试阶段，先在本地模型上跑通流程，再切换云端模型做质量验证，能省不少 API 试错成本。
6.2 不适合：超长复杂创作、最强模型能力依赖、统一审计要求
反过来，如果你的核心需求就是让模型输出 5000 字以上的高质量长文，或者对推理能力要求极高，那就别指望本地 7B/14B 模型硬扛，直接上云端最强模型更省心。再比如团队场景，如果要求所有请求都有审计日志、统一留痕，边缘端分散部署会让审计变得很麻烦，这时候集中走云端 API 反而是更好的选择。
6.3 一条适合大多数人的演进路径
如果你刚接触 OpenClaw，我的建议是从纯云端开始，先把流程跑通；然后加一个本地 Ollama，把简单对话切到本地，验证延迟和整体体验；再逐步把写小说、总结、知识库问答这些重活通过 skill 路由回云端；最后再考虑用 active memory 和 embedding 模型，把记忆检索也下沉到边缘端。这套路径每一步都有明确收益，不会一上来就被混合配置的复杂度劝退。
我在实际操作中的体会是：边缘端实时推理和云端协同不是二选一，而是两条腿走路。本地模型负责“快”和“省”，云端模型负责“强”和“稳”，OpenClaw 的模型服务层恰好把两者缝在了一起。最后再分享一个小技巧：无论你怎么配置，一定要给本地模型设置好 keep_alive 驻留内存，并确保至少有一个不依赖外网的模型可用。这样哪怕云端 API 出问题，你的 OpenClaw 依然能正常回话，这一点在实战中比任何花哨的路由策略都重要。