2026年 OpenClaw 对接本地/内网 LLM（Ollama 与 vLLM）：端点映射、超时与并发切片、doctor/status 验收示意

把 Ollama（默认 11434）与 vLLM（默认 8000）放在内网，再让 OpenClaw 的网关把它们统一映射到 /v1/chat/completions、/v1/models，是 2026 年最常见的「自托管 LLM + Agent」落地形态。本文不谈选型，只给一份可复现的实操：端点怎么映射、超时与并发怎么按模型切片、openclaw doctor 与 openclaw gateway status --require-rpc 怎样交叉验收，最后用远程高内存 Mac承接长上下文推理外溢，避免本地小机被一两条长请求拖死。守护进程稳定性可并读 OpenClaw 网关 launchd 排错手册，远程 Mac 原生安装与 doctor 报错见 远程 Mac 安装与 doctor FAQ。

一、端点映射：一张「上游 → 网关 → OpenAI 兼容」表

把上游与对外面板钉到同一坐标系，是后面所有验收的前提。常见映射如下：Ollama 上游 http://10.0.0.10:11434，原生 /api/chat 与 /api/tags；vLLM 上游 http://10.0.0.11:8000，已经原生暴露 /v1/chat/completions 与 /v1/models。OpenClaw 网关对外只暴露同一基址：https://gw.lan/v1/chat/completions、https://gw.lan/v1/models，并在路由层把模型名当作分发键——例如 qwen2.5:14b 路由到 Ollama，llama3.1-70b-awq 路由到 vLLM。

口诀：对外只有一组 /v1，对内按模型名分发；上游 health 走原生路径，对外 health 走 /v1/models。

二、超时与并发：按上下文与模型切片，而不是统一阈值

统一一个 30 秒超时是事故温床。建议按上下文长度与模型类切三档：短任务（< 4K tokens）—— request 60s、首字节 5s、SSE idle 30s、并发 8；中任务（4K–32K）—— request 300s、idle 60s、并发 4；长上下文（> 32K）—— request 1800s、idle 120s、并发 1–2。Ollama 与 vLLM 各开独立队列，长任务不抢短任务的 worker。三处 idle（客户端、网关、上游）务必取最小值再统一，否则 SSE 在最严格那一处被掐断，前端只看见半截 JSON。

三、可复现校验：一段 curl 把端到端跑通

顺序固定：先 models 后 chat、先非流后流式。models 返回空或 404，多半是路径前缀或反代剥头，别先在 chat 上猜模型名。

curl -fsS https://gw.lan/v1/models -H "Authorization: Bearer $TOKEN" | jq '.data[].id'

curl -N https://gw.lan/v1/chat/completions \
  -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
  -d '{"model":"qwen2.5:14b","stream":true,"messages":[{"role":"user","content":"ping"}]}'

四、doctor 与 gateway status --require-rpc：把「进程在」与「RPC 真通」分开

openclaw doctor 检查本机依赖、端口占用、配置一致性；openclaw gateway status 不加参数时只反映本地注册态，加上 --require-rpc 才会强制走一轮 RPC 健康探测，与 HTTP 面的真实依赖对齐。Runbook：改完上游地址或鉴权后，冷启 → doctor → status（普通）→ status --require-rpc → /v1/models → /v1/chat/completions（流式），任一步失败就停在该层缩域，不要跳级。

提示：把这五行写进 CI smoke test，回归速度比看监控曲线快。

五、内网鉴权：Bearer 与策略不要靠「同机免验」

常见 401 三类：缺 Authorization: Bearer …、token 对但 audience/issuer 不匹配、反代剥头。即便上游 Ollama/vLLM 在内网，OpenClaw 网关侧也建议显式鉴权，并把每个上游单独配 token，让审计日志能追到调用方，而不是看见一片 system。

六、外溢案例：远程高内存 Mac 承接长上下文

本地小机（16/32GB）跑 7B–14B 量化模型很轻松，但一旦客户上传 80K 上下文或要求 70B 模型，KV cache 直接顶满。做法：把长上下文模型固定部署在云上独占高内存 Mac（如 64GB/128GB Apple Silicon），网关按模型名外溢路由——短链路依旧本地、长链路走远端。配合第二节的并发切片，长任务独占小队列，不挤占本地短任务通路；远端节点按 LaunchDaemon 常驻，崩溃自动重启，日志卷与推理卷分离。结合 企业 Mac 资源池选型方法可一并评估自建与租用的 TCO。

  • 长上下文模型是否已固定到高内存节点，并设置并发 1–2？
  • 三处 idle（客户端、网关、上游）是否取最小值后显式上调？
  • doctor 与 status --require-rpc 是否都进 CI smoke？
  • 每个上游是否独立 token，审计日志可追到调用方？

把网关与长上下文 LLM，跑在 Mac mini / macOS 上更省心

本文链路里，本地常驻网关与远端长上下文承接都更适合 Mac：Apple Silicon 统一内存让 KV cache 不必再走 PCIe，M4 Pro / Max 64GB/128GB 机型能稳定吃下 70B 量化与超长上下文；macOS 上 LaunchDaemon、统一日志与电源管理对无人值守极友好；整机待机约 4W、无风扇可 7×24 静默在线；Gatekeeper、SIP、FileVault 把内网暴露面收得很紧；同等推理性能下总拥有成本常优于同价位 Windows/Linux GPU 主机。

如果你想把本文这套端点映射 + 并发切片 + doctor/status 验收跑在最顺手的硬件上，Mac mini M4 / M4 Pro 仍是 2026 年最具性价比的起点；打开 Macstripe 首页 选合适机型即可。