本地部署大模型+openclaw

你大概已经能跑起本地模型了，但一接 openclaw 就卡住：模型起没起、地址填哪个、工具调用报错、换了机器又要重来一遍。这篇不聊哪个模型聪明，只讲链路怎么搭、每步该核对什么、出错按什么顺序排。看完你能自己判断卡在哪一环，而不是反复重装。具体数字和型号到站内页面查当时的口径。

你大概已经把本地模型跑起来了：命令行里能出一段话，网页界面也能聊两句。但一接 openclaw 就卡住——模型起没起、地址填哪个、工具调用报错、换了台机器又得从头折腾。这篇不聊哪个模型更聪明，只讲这条链路怎么搭、每一步该核对什么、出错按什么顺序排。

看完你能自己判断卡在第几环，而不是反复重装、反复换模型。具体型号、量化档位对应的占用、价格这些数字，一律以站内页面当时的口径为准，本文只给判断标准和可执行动作。

先把链路拆成四段，别一上来就装

很多人一上手就想着「装个 openclaw 把模型接进去」，结果一次改三处，报错了也不知道是谁的问题。把链路拆成四段看：本地推理服务、模型文件、openclaw 本体、工具与权限。四段各自独立，一段没通就别急着动下一段，不然排查范围只会越滚越大。

本地推理服务

负责加载模型、对外暴露接口的那一层，常见是各类本地推理框架

模型文件

权重文件本身，决定你能跑多大、出话质量大概什么水平

openclaw 本体

负责编排对话、挂工具、管会话的那层，它不直接读模型文件

工具与权限

让智能体真正能干活的部分，文件、终端、网络都算

每段都有各自的验收动作：服务能应答、模型能出话、openclaw 能列出模型、智能体能调通一次工具。这四步里哪一步过不去，就说明你卡在哪一段，再去翻对应的小节。先记住自己卡在第几段，比通读一遍全文有效得多。

硬件与量化档位：先算能跑多大，再决定跑哪个

选型顺序应该是先算账、再挑模型，而不是反着来。显存是硬约束：权重本身占一块，上下文长度要额外留一块，并发多了还要再留一块缓存。很多人只按权重算，结果模型能加载、一开对话就爆显存，这就是缓存没算进去。

• 先确定你能接受的最大占用，把上下文和并发缓存预留出来，剩下的才是给权重的预算
• 量化档位是质量与占用之间的取舍，不是越低越好：越低占用越小，但对指令跟随、长文理解、工具调用格式的稳定性影响越大
• 涉及工具调用和代码生成的场景，不建议压到很低的档位，容易在参数格式上出错
• 纯聊天、摘要这类容错高的场景，低档位通常够用
• 到站内部署测算页按你自己的卡算一遍，再回来看还能不能加并发

具体到某个档位占多少、你这张卡上限在哪，别凭感觉，到站内的部署测算页面核对当时的数据。那里会按你填的硬件给出可跑范围，比论坛上抄来的经验值靠谱。

推理服务这一层：接口通不通比跑得快不快更重要

服务层最常见的坑不是性能，而是「模型明明装了却连不上」。先确认监听地址和端口：只听本机回环地址时，局域网和容器里的 openclaw 都访问不到；只听内网地址时，你自己用命令行反而可能连不上。本机、局域网、容器三种调用路径的写法不一样，别拿一个地址到处填。

1. 确认进程真的起来了看日志里有没有加载完成的提示，而不是启动命令没报错就当成功。加载大模型时命令行卡住是正常的，要看日志而不是看有没有返回提示符。
2. 本机自测一次用 curl 或同类工具直接打接口，能返回一段正常文本说明服务层通了。这一步不要经过 openclaw，避免多一层干扰。
3. 再测非本机路径如果 openclaw 跑在容器或另一台机器上，用那个视角再打一次接口。这一步最容易暴露监听地址问题。
4. 确认接口协议优先选 OpenAI 兼容接口，能省掉大量适配工作。非兼容接口要提前确认 openclaw 是否认，不然配置写得再对也接不上。

# 本机自测思路（把地址和模型名换成你自己的）
curl -s http://127.0.0.1:PORT/v1/models
curl -s http://127.0.0.1:PORT/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model":"你的模型名","messages":[{"role":"user","content":"hi"}]}'

如果第一条能列出模型、第二条能出话，服务层就算过关。这时候再去看 openclaw，问题范围会小很多。端口被占用、被别的进程抢先监听，也是「怎么配都不通」的常见原因，自测时顺手确认一下。

openclaw 侧配置：地址、模型名、超时三个字段先对齐

openclaw 侧的配置项很多，但真正挡住大多数人的就三个字段：服务地址、模型名、超时。先把这三个对齐，再往上加工具和知识库。顺序反了的话，工具报错你根本分不清是模型不行还是地址填错。

模型名这一项特别容易踩：大小写、标签后缀、带不带版本标记都算不同名字。最稳的办法是从服务侧列出的模型列表里原样复制，不要凭记忆手打。地址同理，别在两个配置项之间来回猜。

超时值得单独说一句：本地的首 token 延迟普遍比云端高，这是架构决定的，不是故障。把超时设得太短，会让你误以为模型挂了，其实是还在算。设得太长，真出错时又要等很久才看到报错。按你实测的出字速度留出余量就行。

工具调用与权限：智能体能不能干活的关键一步

链路主干通了之后，智能体能不能干活取决于工具调用。这里的排查原则很简单：每个工具先单独验证一遍，再交给智能体用。命令行能跑通的工具，进了智能体却报错，问题就在参数封装或权限；连命令行都跑不通，那就跟 openclaw 没关系。

• 文件、终端、网络三类权限分开给，按最小必要开，不要一次全放开
• 先给只读能力，确认行为可控之后再考虑写操作
• 工具返回格式不固定会让模型反复重试，需在工具侧做统一封装，返回结构尽量稳定
• 给工具的说明写清楚输入输出格式，模型对格式的依赖比你想的重
• 先在一两个工具上跑顺，再批量接入，一次挂十个工具很难定位问题

什么情况下这套最小权限思路不适用？如果你是在完全隔离的沙箱环境里做实验，本来就没有真实数据风险，权限可以放松一些，把重点放在快速验证工具链路。但只要涉及真实文件、真实网络请求，就回到最小必要原则。

网络与离线：国内环境最容易翻车的一段

这一段跟模型本身没关系，但最容易把人卡住。要拉的东西分三条链路：模型文件、组件安装、运行时更新。这三条能不能走通是独立的，一条通不代表另外两条也通，要分别确认。

1. 先确认模型文件来源能不能直接从你用的源拉到，还是需要提前下载好再搬进去。这一步不通，后面都白搭。
2. 再确认依赖安装推理框架和 openclaw 各自的依赖能不能装。装到一半失败，先看是哪条链路断了，别整包重装。
3. 最后处理运行时更新有些组件会在启动时检查更新，纯离线环境下这一步可能卡住，需要提前关掉或配好本地源。
4. 代理只给需要的进程别全局挂代理，否则本机服务之间互访容易绕进代理，出现「明明在同一台机器上却连不上」。

纯离线环境要提前把模型文件和依赖搬进来，具体搬法到站内模型迁移相关页面看，那里讲得比本文细。判断标准是：断网状态下，从启动服务到 openclaw 完成一次对话，全程不需要外网请求。

出错按这个顺序排，别乱试

出错的时候最忌讳东改一下西改一下。按固定顺序走一遍，比反复重装省时间：服务在不在 → 接口通不通 → 模型名对不对 → 单轮对话成不成 → 工具调不调得动。每一步只解决一个问题，过了再走下一步。

另外建议随手记一笔：改了什么、报什么错、什么时候改的。本地部署的坑往往不是难，而是隔几天忘了自己动过哪里。有记录的话，下次同样的问题几分钟就能定位。

跑通之后：怎么换机器、换模型不重来

链路跑通之后，真正的价值在于能不能复用。做法很简单：把服务地址、模型名、超时这些抽成配置文件或环境变量，别写死在代码或界面里。这样换模型只改模型名和量化档位，链路其余部分保持不动，不用重新理解一遍整个架构。

• 配置文件和环境变量分开管：敏感项走环境变量，结构项走配置文件
• 换模型前先确认新模型的量化档位和显存占用能不能对上
• 换机器前先确认新机器的显存和量化档位能不能对上，再搬配置
• 把当时跑通的配置存一份版本，写清楚对应哪套硬件和哪个模型
• 链路分层别混：服务地址属于环境，模型名属于任务，分开改

什么情况下不适合照搬？硬件档次差太多的时候。新机器显存明显更小，就得回头重算量化档位和上下文预算，硬搬配置只会得到一堆加载失败。这种情况下从硬件与量化那一节重新走一遍更省事。