2026 OpenClaw и Ollama/vLLM на удалённом Mac: порты, проверки здоровья, конкуренция за ресурсы и runbook запуска

~16 мин · MACCOME

На арендованном или самоуправляемом удалённом Mac сбой при совместной работе OpenClaw Gateway и Ollama или локального vLLM редко сводится к «не тот model id». Чаще виноваты порты, порядок проб, unified memory и CPU, дисциплина запуска/остановки. Текст дополняет руководство по офлайн-моделям: там мосты API, контекст и отсутствие ответа; здесь — только топология на одном хосте. В итоге вы должны уметь развести слушатели, знать, какой уровень проверять до healthz, и почему под нагрузкой сначала режем модель, а не крутим Gateway вслепую.

Пять «ложных аварий», когда всё на одном Mac

  1. Коллизии портов: Ollama по умолчанию 11434, vLLM часто 8000, Control UI OpenClaw обычно 18789; второй локальный прокси легко занимает порт повторно.
  2. Обратный порядок проб: Gateway даёт 200, но provider смотрит на холодный inference — UI открыт, диалог пуст.
  3. Забитая unified memory: веса, Metal/ANE, буферы Node — система «тормозит», а CPU выглядит спокойным.
  4. Общий I/O и тепло: длинный inference держит вентилятор и throttling; крупные сборки Xcode и круглосуточный агент на одном хосте дают джиттер.
  5. Гонки обновлений: сначала подняли Gateway или наоборот модель — baseURL, токены и реальные listener расходятся. Docker: официальный Docker и Control UI.

Порты и зоны ответственности — таблица в тикет

Вставьте в ревью, чтобы «договорились про 8000» не превратилось в «на третьей неделе порт занят другим сервисом».

Компонент Типичный дефолт Точка контакта с OpenClaw
Ollama HTTP обычно 127.0.0.1:11434; LAN только с явным bind и фаерволом baseURL провайдера к OpenAI-совместимому /v1; без слепого reverse proxy без health upstream
vLLM (локально) Часто 8000 или свой порт; несколько инстансов — разные порты и пулы GPU/потоков Как Ollama: проверить /v1/models и минимальный completion до ссылки из Gateway
OpenClaw Gateway Control UI нередко 18789; ориентир — ваша openclaw-конфигурация Сначала healthz/readyz, затем provider; см. триаж Gateway/модели

Шесть шагов — порядок, который можно подписать

  1. Бюджет ресурсов: верх памяти и параллельных запросов для inference, запас для Gateway+Node; на классе M4 разумно оставлять 10–20% RAM под ОС и кэш диска (подстройка под модель).
  2. Сначала inference, потом provider: стабильный listen Ollama/vLLM, curl на минимальный chat/completions, затем старт или reload Gateway — без застывшего «не готов».
  3. Зафиксировать порты и loopback: только локальные вызовы — 127.0.0.1; мост контейнера — задокументировать правила и владельца фаервола.
  4. Двухуровневые пробы: уровень 1 — здоровье inference (HTTP + крошечная генерация), уровень 2 — healthz, уровень 3 — сквозной чат; любой красный — без прод-трафика.
  5. Горячие изменения: при смене весов/образа опустошить диалоги, при необходимости убрать ingress Gateway или read-only, поменять модель, поднять Gateway, повторить пробы.
  6. Откат: сохранить предыдущий путь весов и блок provider; несколько изменений — откат по слоям inference, затем Gateway. Doctor: post-install doctor, разделы про macOS-хост.
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 по вашей доке

Три «жёстких» параметра для дежурного гида (замените измерениями)

  • Задержка до первого токена и очередь: P95 после холодной загрузки и в горячем режиме; если горячий режим всё ещё несколько секунд при низком CPU — сначала unified memory и своп, не повышение параллелизма.
  • Двойная нагрузка: крупные сборки Xcode/монорепо и 24/7-агент — типичны OOM или крайне медленные токены; смены окон, очереди или отдельный билдер дешевле, чем гадать именами моделей.
  • Keep-alive и таймауты: на длинных стримах узкий таймаут с одной стороны (до inference или Gateway→клиент) выглядит как обрыв посередине; меняйте парно и фиксируйте номер изменения.

Почему ноутбук «на коленке» и бесконтрольный shared-хост часто проигрывают

Сон/пробуждение, нестабильный домашний uplink, непредсказуемые соседи превращают воспроизводимые запуски и пробы в лотерею. Ollama+Gateway требуют стабильного теплового контура и предсказуемого I/O. Перенос агента и inference в выделенную среду 24/7 с RAM и диском в договоре часто сильнее снижает MTTR, чем бесконечный тюнинг. Для промышленного runbook облачные Mac MACCOME дают выделенный Apple Silicon и арендные модели под FinOps — вы спорите о таблицах ресурсов и изменениях, а не об удаче.

Чего не стоит делать на первой неделе

Не крутить конкурентность Gateway, пока не доказан один целостный completion. Не обновлять Gateway, пока не ясно, что порт inference свободен. Два чистых разреза лучше десяти страниц устных легенд.

Вопросы

Как это сочетается с офлайн-статьёй про Ollama/vLLM?

Там мосты API, контекст, отсутствие ответа. Здесь порты, пробы, ресурсы, порядок запуска на одной машине. См. офлайн-триаж и триаж Gateway.

Gateway в Docker, Ollama на хосте — это «совместно»?

Логически один хост, но сеть должна быть явной: host.docker.internal или bridge IP, проверяемый фаервол. База — прод-развёртывание Docker и официальный Docker-гайд.