本地大模型部署+openclaw

你可能已经看过一堆部署教程，照着敲到一半卡在显存不够、端口连不上、OpenClaw 里填了地址却没反应。这篇不重复「该不该自建」的判断，只走流程：先按显卡定量化档位，再把本地服务起成可被外部调用的形式，最后接进 OpenClaw 并逐项排查。走完你能得到一个本机可用的对话入口，也知道哪一步出问题该去哪查。

你可能已经看过一堆部署教程，照着敲到一半卡在显存不够、端口连不上、OpenClaw 里填了地址却没反应。这篇不重复「该不该自建」的判断，只走流程：先按显卡定量化档位，再把本地服务起成可被外部调用的形式，最后接进 OpenClaw 并逐项排查。走完你能得到一个本机可用的对话入口，也知道哪一步出问题该去哪查。

整条链路其实是四层：硬件与量化档位、推理后端、网络暴露、客户端对接。任何一层没对齐，现象都长得像「连不上」，所以下面每一节都给一个明确的「做完这步怎么验证」，别等最后一起试。

动手前先把三件事确认掉

这三件事花不了十分钟，但能省掉后面一两个小时的反复卸载重装。顺序上先算显存，再定服务形态，最后清场，因为显存不够的话后面怎么配都是白搭。

• 确认显卡显存与可用的推理后端：先到 /models/deploy 的部署测算里，按你手上的卡和想跑的参数量过一遍，得出可选的量化档位，而不是先下载再发现装不下；量化档位取舍的通用逻辑看 /ai-dict/category/tech，别凭感觉选。
• 确认你要的是「能聊天」还是「能被程序调用」：两者对服务形态的要求不同，OpenClaw 属于后者，需要一个持续监听、暴露 HTTP 接口的常驻服务，不是跑完一次命令就退出的脚本。
• 确认系统里没有别的程序占着显存：浏览器硬件加速、另一个已经开着的推理工具、残留进程都会让第一次加载直接 OOM，先在任务管理器或 nvidia-smi 里看一眼再启动。

推理后端与量化档位怎么定

后端选型和量化档位是同一道题的两面：后端决定你能开多少并发，量化档位决定你塞得进多大的模型。两个都定下来之前，不要开始下载权重文件。

开箱即用型后端

自带模型下载与对话界面，单人自用最省事，适合只想要一个本机对话入口的场景。

服务化推理框架

面向多路并发请求，吞吐和批处理更强，适合要被程序持续调用的场景。

量化档位

用更低的数值精度换更小的显存占用，档位越低越省显存，但通常也越容易掉质量。

上下文缓存

对话历史越长占的显存越多，这部分要在权重之外单独留白，不能压到零。

量化档位怎么定，按「显存留白」反推而不是按权重体积卡死：把卡的总显存减去系统与驱动的固定占用，再留一块给上下文缓存，剩下的才拿去放权重。上下文开得越大，留白越要加，具体倍率去 /quantization-tier-choice 对照。后端怎么选，/vllm-vs-ollama-selection 里已经拆过，这里只取结论用。

一个提醒：低档位不一定不能用作开发调试，很多场景下它足够验证链路，只是用来做正式输出时质量会打折。判断标准是你拿它干什么，而不是分数。真要横向比较，去 /rankings 看当时的评测数字。

把本地服务起成 OpenClaw 能连的样子

这一步的核心是：让服务以「常驻 + 可被外部访问」的形式活着。很多教程默认你就在本机自己用，所以只绑回环地址，这在 OpenClaw 场景下是最常见的坑。

1. 改监听地址把服务的监听地址从只绑 127.0.0.1 改成绑所有网卡；改完确认防火墙对目标端口放行，容器或另一台机器场景下尤其要确认。
2. 固定端口与模型名把端口写死在配置文件里，别每次启动都变；同时记下服务对外暴露的模型标识，OpenClaw 那一侧要填的通常正是这个标识，而不是模型文件夹名。
3. 本地直连自测用命令行工具向本地地址发一次最简请求，拿到返回再往下走。
4. 确认返回结构用接口调试工具看返回是不是标准对话格式。不是的话先在这层改，别去客户端折腾。
5. 最后才填进 OpenClaw前面四步都过了再填地址。跳步会让两边的错误混在一起，很难定位。

服务起来后如果一请求就爆显存或极慢，回到上一节重新砍上下文长度和量化档位，而不是先在客户端那边调参数。客户端那侧的参数调整解决不了容量问题，只会把排查方向带偏。

# 起服务后先用本机命令行确认一次；把地址和端口换成你自己配的
curl http://127.0.0.1:<端口>/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model":"<模型标识>","messages":[{"role":"user","content":"ping"}]}'

接进 OpenClaw 后的连通性排查顺序

到这一步「没反应」的概率最高，但它几乎总能被拆成四层里的一层。按下面的顺序走，在哪一步断掉，问题就在那一层，不要来回改配置。

接好之后用 /tools/speed-test 量一次延迟和首字时间，作为以后的对照基线。之后如果变慢，有这个基线就能立刻分辨是模型换大了还是环境变差了，否则只能凭感觉猜。模型与后端的能力差异也可以顺手到 /models 对照当时的资料。

什么情况下这套做法不适用：如果 OpenClaw 与服务之间隔着公网，或者你要多人同时用，本机直连会撞上端口暴露与并发瓶颈，应该转成反向代理加鉴权，或者干脆走托管推理，别硬在本机堆配置。判断标准是「这一个服务是不是只服务这一台机器上的少数人」，不是的话就别走直连。

• 把服务设成随开机启动，确认断电重启后不用手动敲命令。
• 把配置里的地址、端口、模型名抄一份单独存档，换机器时直接照抄。
• 确认客户端侧没有多余的代理设置把请求劫持走。
• 过一段时间回 /price-watch 看一眼托管推理与自建的成本对比，判断还值不值得继续自建。