2026 OpenClaw mit Ollama/vLLM auf einem Remote-Mac: Ports, Health Checks, Ressourcenkonflikte und Start-/Stopp-Runbook

ca. 16 Min. · MACCOME

Auf einem gemieteten oder selbst verwalteten Remote-Mac scheitert das Co-Hosting von OpenClaw Gateway mit Ollama oder lokalem vLLM selten an «falschem Modellnamen». Typisch sind Ports, Probenreihenfolge, Unified-Memory- und CPU-Wettbewerb sowie Start-/Stopp-Disziplin. Dieser Text ergänzt den Offline-Modell-Triage-Artikel: dort API-Brücken, Kontext, No-Reply—hier nur die Topologie auf einem Host. Ziel: Listener sauber trennen, wissen, welche Schicht vor healthz grün sein muss, und unter Last zuerst das Modell stutzen, nicht Gateway blind drehen.

Fünf «Schein-Ausfälle», wenn alles einen Mac teilt

  1. Portkollisionen: Ollama standardmäßig 11434, vLLM oft 8000, OpenClaw Control UI häufig 18789; ein zweiter lokaler Proxy besetzt schnell doppelt.
  2. Falsche Probenfolge: Gateway liefert 200, der Provider zeigt jedoch auf einen kalten Endpunkt—UI offen, Chat leer.
  3. Unified Memory voll: Gewichte plus Metal/ANE plus Node-Puffer fühlen sich langsam an, obwohl CPU ruhig wirkt.
  4. Gemeinsames I/O und Thermik: Lange Inferenz spannt Lüfter und Drossel; große Xcode-Builds plus Agent erzeugen Jitter.
  5. Upgrade-Rennen: Gateway vor dem Modell erhöhen oder umgekehrt—baseURL, Token und echte Listener divergieren. Docker: offizielles Docker und Control UI.

Ports und Verantwortung: Tabelle ins Change-Ticket

Die Tabelle ins Review packen, damit «wir meinen alle 8000» nicht in Woche drei scheitert.

Komponente Typischer Default Berührung mit OpenClaw
Ollama HTTP meist 127.0.0.1:11434; LAN nur mit explizitem Bind und Firewall-Konzept Provider-baseURL zur OpenAI-kompatiblen Fläche; kein blinder Proxy ohne Upstream-Health
vLLM (lokal) Oft 8000 oder frei; mehrere Instanzen brauchen getrennte Ports und GPU-Threads Wie Ollama: /v1/models und Minimal-Completion vor Gateway-Verweis verifizieren
OpenClaw Gateway Control UI oft 18789; echte openclaw-Config maßgeblich Zuerst healthz/readyz, dann Provider; siehe Gateway-/Modell-Triage

Sechs Schritte: eine Reihenfolge zum Unterschreiben

  1. Ressourcenbudget notieren: Obergrenze RAM/konkurrierende Inferenz und Gateway+Node-Reserve; auf M4-Klasse realistisch 10–20 % frei für OS und Pagecache lassen (modellabhängig).
  2. Erst Inferenz, dann Provider: Wenn Ollama/vLLM stabil lauscht, minimalen chat/completions-curl, danach Gateway starten oder reloaden—kein dauerhaftes «not ready».
  3. Ports und Loopback festnageln: Nur lokal sprechende Clients? 127.0.0.1. Containerbrücke? Firewall-Verantwortliche dokumentieren.
  4. Zweistufige Probes: Schicht 1 Inferenz (HTTP plus Mini-Generierung), Schicht 2 healthz, Schicht 3 Chat-E2E. Irgendwo rot—kein Produktivverkehr.
  5. Hot-Change-Regeln: Bei Gewichts-/Image-Wechsel Sessions drainen, Gateway-Eingang stoppen oder read-only, Modell tauschen, Gateway hoch, Probes wiederholen.
  6. Rollback: Vorheriger Gewichtspfad und Provider-Block aufheben; mehrere Änderungen—Schichtweise Inferenz dann Gateway. Doctor: Post-Install-Doctor, Abschnitte für macOS-Hosts.
bash
# Minimale Probenreihenfolge (Host/Port anpassen)
curl -sS "http://127.0.0.1:11434/api/tags" > /dev/null   # Ollama lebt
# curl -sS "http://127.0.0.1:8000/v1/models" > /dev/null  # vLLM
curl -fsS "http://127.0.0.1:18789/healthz"                 # Gateway
# Danach kürzester Chat oder openclaw doctor laut Doku

Drei harte Kennzahlen fürs Bereitschaftshandbuch (mit Messwerten füllen)

  • Zeit bis ersten Token und Warteschlange: P95 kalt nach Laden und warm trennen; warm weiterhin mehrere Sekunden bei niedriger CPU—zuerst Unified Memory und Paging, nicht mehr Parallelität.
  • Doppellast auf einem Mac: Große Xcode-/Mono-Repo-Builds gegen 24/7-Agent liefern typisch OOM oder extrem langsame Tokens; Zeitscheiben, Queues oder dedizierter Builder schlagen reines Modell-Raten.
  • Keep-Alive und Timeouts: Lange Streams—wenn nur eine Seite (Inferenz oder Gateway→Client) zu knapp ist, wirkt es wie Mittelabbruch; Paare gemeinsam ändern und Change-ID hinterlegen.

Warum Ad-hoc-Notebooks und unmanaged Shared Hosts dieses Setup oft verlieren

Sleep/Wake, Consumer-Uplink und unberechenbare Nachbarn machen reproducible Probes zur Lotterie. Ollama plus Gateway braucht stabile thermische Grenzen und planbares I/O. Agent und Inferenz in eine dedizierte, 24/7-fähige Umgebung mit vertraglich fassbarem RAM und Storage zu legen, senkt MTTR oft schneller als endloses Tuning. Für produktionsreife Runbooks liefern MACCOME Cloud-Macs dediziertes Apple Silicon und FinOps-taugliche Mietmodelle—Sie streiten über Ressourcentabellen und Change-Tickets, nicht über Glück. Klare Runbooks verbessern zugleich die Nachvollziehbarkeit unter DSGVO und allgemeinem Datenschutz gegenüber improvisierten Einzelgeräten.

Was Sie in Woche eins besser unterlassen

Gateway-Parallelität nicht hochdrehen, bevor ein einzelner Completion-Pfad bewiesen ist. Gateway-Version nicht heben, bevor klar ist, dass der Inferenz-Port frei bleibt. Zwei saubere Schnitte schlagen zehn Seiten Tribal Knowledge.

FAQ

Abgrenzung zum Offline-Ollama/vLLM-Artikel?

Dort API, Kontext, No-Reply. Hier Ports, Proben, Ressourcen, Startfolge auf einem Host. Offline-Triage plus Gateway-Triage.

Gateway in Docker, Ollama nativ—co-hosted?

Logisch ja, Netz explizit: host.docker.internal oder Bridge-IP, firewall-seitig abnahmefähig. Start bei Docker-Produktions-Runbook und offiziellem Docker-Guide.