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承接長上下文外溢。Compose／Tailscale 節奏見 零公網暴露教學；遠端 Mac 常駐見 遠端 Mac 部署實操。

一、端點映射：一張「上游 → 閘道 → 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 會被最嚴格那一層掐斷。

三、可複現校驗：一段 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 常駐，崩潰自動重啟，日誌卷與推理卷分離。評估自建與租用的 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 首頁 選合適機型即可。