2026 OpenClaw 与 Ollama/vLLM 同机部署在远程 Mac 上：端口、健康检查、资源争用与启停顺序实操清单

约 16 分钟阅读 · MACCOME

在已租/自管远程 Mac上，你要同机跑 OpenClaw Gateway 与 Ollama 或本机 vLLM 时，问题通常不是「模型连没连上」，而是端口、探活顺序、统一内存/CPU 争用与启停叠在一起。本文与 离线模型分诊篇 分工：那篇管 API/上下文/无回复；本篇只给同机拓扑的 Runbook。读完你应能写出：默认监听怎么错开、healthz 之前先验哪一层、以及 Gateway 全速拉满时如何先降级模型再动 Gateway。

同机时最常见的五类「假故障」

  1. 端口撞车：Ollama 默认 11434、常见 vLLM 8000、OpenClaw Control UI 常见 18789；反代或本机再开一层时最容易二次占用。
  2. 探活顺序反了：Gateway 已 200 但 provider 指到未就绪的推理端点，表现成「能开 UI、对话无输出」而不是「进程挂了」。
  3. 统一内存被一头吃光：大模型权重 + Metal/ANE + Node 侧缓冲同时顶满，出现「CPU 看似不高但一切变慢」的体感。
  4. 同机 I/O 与温度策略：长时间推理把风扇与热节流拉满，Xcode/构建与 Agent 同机时表现成随机抖动。
  5. 升级竞态：先升级 Gateway 再换模型，或反过来，导致配置里 base URL 与 token 与真实监听不一致，排障绕圈。Docker 路径另见 官方 Docker 与 Control UI。

端口与责任边界：同机一表写进变更单

在评审/变更单里直接贴下表，避免「口头约定 8000」在第三周被别的服务借走。

组件 常见默认/约定 与 OpenClaw 的接口点
Ollama 服务 HTTP 默认 127.0.0.1:11434；若需 LAN 可见须显式放开并做防火墙 Provider 的 baseURL 指向 /v1 兼容端点；不要在 Gateway 前再套一层无健康检查的盲反代
vLLM（本机） 常见 8000 或你自定义；多实例必须错开端口与 GPU/线程池 同 Ollama：先保证 /v1/models 与一次最小 completion 真通，再让 Gateway 引用
OpenClaw Gateway Control UI 常见 18789；以你环境 openclaw 配置为准 先 healthz/readyz，再验 provider；详见 Gateway/模型分诊

落地 6 步：可签字的启停与验证顺序

  1. 写资源预算行：在表上写出「推理进程上限内存/并发请求」与「Gateway+Node 预留」；M4 级建议至少为系统与磁盘缓存留 10–20% 可写余量（按你们模型大小现场改数字）。
  2. 先起推理，再指 provider：Ollama/vLLM 进程监听稳定后，用 curl 做最小 chat/completions；再启动或 reload Gateway，避免把「未就绪」写进长期状态。
  3. 锁端口与回环策略：若只本机相调，优先 127.0.0.1；确需跨进程容器访问再打开 bridge，并记录防火墙规则责任方。
  4. 双探活清单：第一层推理健康（HTTP+最小生成），第二层 Gateway healthz，第三层才走「全链路对话探针」；任一层红则不上业务流量。
  5. 热更新纪律：升级推理镜像/权重时先 drain 对话，停 Gateway 入站或切只读模式（视你部署），再换模型，最后起 Gateway 并复跑双探活。
  6. 回滚：保留上一版权重路径与上一版 provider 块配置；一次变更多项时，按「推理 → Gateway」顺序按层回滚。更多 doctor 读法见 装后 doctor 分平台 中与本机相关段落。
bash
# 最小探针顺序示例（按你的端点改写）
curl -sS "http://127.0.0.1:11434/api/tags" > /dev/null   # Ollama 存活
# curl -sS "http://127.0.0.1:8000/v1/models" > /dev/null  # vLLM
curl -fsS "http://127.0.0.1:18789/healthz"                 # Gateway
# 再跑一条最短对话/一次 openclaw doctor 由你环境定

三条可进值班手册的硬参数（请用你机上的实测替换括号）

  • 首 token 时延与排队：记录「冷启动加载权重后」与「热」两次 P95；若热仍 > 数秒 而 CPU 低，先查是否统一内存触顶或磁盘换页，而不是先加并发。
  • 同机双负载：当 Xcode/大型构建 与 7×24 Agent 争用，常见现象是推理侧 OOM 或极慢 token；用时间片/队列或专用构建机拆职责，比单纯「加模型名」更省钱。
  • 保留连接与超时：对长流式回答，调大「到推理」与「Gateway 到客户端」两侧超时任一侧过小，会表现成**中途断流**；把两侧参数成对改，并记一次变更单号。

为什么「笔记本人肉扛」与「无治理共享机」常输在同机组合上

笔记本来回睡眠、家宽出口抖动、或共享机上的不可预期邻居，会把**可复现的启停与探活**变成概率问题；同机 Ollama+Gateway 恰恰需要稳定的热边界与可预计的 I/O。把 Agent 与推理放在**独占、可 7×24、内存与存储可写进合同**的远程环境，比反复调参更省 MTTR。需要把上述 Runbook 落在生产时，MACCOME 的 Mac 云主机在独占 Apple Silicon 与租期可折账上，通常比拼凑多台个人设备更容易满足「同机多进程**可审计**、可扩内存/盘」的约束——让 OpenClaw 与本地模型真正同机时，你争的是**资源表与变更单**，不是运气。

上线后第一周的「不做什么」

不要在未测通单请求 completion 时就把 Gateway 并发打满；也不要先改 Gateway 版本再回头发现推理端口早被其它服务占用。两刀切齐，比多写十页配置说明更能减少凌晨电话。

常见问题

和「离线 Ollama/vLLM 分诊」那篇怎么分工？

那篇管 API 桥接、上下文与无回复分诊；本文管 同机端口、探活、资源与启停。可对照 离线私有模型分诊 与 Gateway 分诊。

Docker 里跑 Gateway、宿主机跑 Ollama 算不算「同机」？

算逻辑同机、网络要显式通。除端口外，还要写清 host.docker.internal 或 bridge IP，并在防火墙层可验收；基线可先看 Docker 生产向部署 与官方 Docker 篇。