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；本機再加反查或 sidecar 時最易二次占用。
  2. 探測順序錯置：Gateway 已 200 但 provider 仍指向未就緒的推理端點，呈現「UI 能開、對話無輸出」而非「程序掛了」。
  3. 統一記憶體被吃滿：大型權重＋ Metal／ANE＋ Node 端緩衝同時壓線，會出現「CPU 看似不高但整體變慢」的體感。
  4. 同機 I／O 與溫控：長時間推理拉滿風扇與熱節流；Xcode／大型建置與 Agent 同機時易見隨機抖動。
  5. 升版競態：先升 Gateway 再換模型或相反，導致設定內 base URL、權杖與實際監聽不一致。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／模型分診

落地六步：可簽核的啟停與驗證順序

  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. 熱更新紀律：升推理映像／權重時先排空對話，停 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 篇。