Quel lien avec l’article de triage Ollama/vLLM hors ligne ?

L’article de triage hors ligne couvre ponts API, contexte et absence de réponse. Le présent texte traite ports, sondes, ressources et ordre démarrage/arrêt sur une seule machine. À lire en parallèle.

Gateway dans Docker et Ollama sur l’hôte—est-ce co-hébergé ?

Oui logiquement, mais le réseau doit être explicite : host.docker.internal ou IP de bridge, pare-feu vérifiable. Base : runbook Docker production et guide Docker/Control UI officiel.

2026 OpenClaw + Ollama/vLLM sur Mac distant : ports, health checks, contention, ordre démarrage-arrêt

Sur un Mac distant loué ou géré, co-héberger OpenClaw Gateway avec Ollama ou un vLLM local échoue rarement sur « le mauvais nom de modèle ». Ce qui coince, c’est les ports, l’ordre des sondes, la mémoire unifiée et la CPU, la discipline de démarrage/arrêt. Ce texte complète le guide de triage modèle privé hors ligne : là, ponts API, contexte, absence de réponse ; ici, seulement la topologie sur une seule machine. Vous devez sortir avec des listeners séparés, la couche à valider avant healthz, et l’idée qu’il faut réduire le modèle avant de bricoler Gateway sous charge.

Cinq « faux incidents » quand tout partage le Mac

Collisions de ports : Ollama par défaut 11434, vLLM souvent 8000, Control UI OpenClaw souvent 18789 ; un reverse proxy local ajoute vite une seconde occupation.
Sondes dans le désordre : Gateway 200 mais le provider pointe vers un endpoint d’inférence froid : l’UI s’ouvre, le chat reste vide.
Mémoire unifiée saturée : poids du modèle, Metal/ANE, tampons Node — tout paraît lent alors que le CPU semble calme.
I/O et thermique partagés : longues inférences à fond de ventilateur ; gros builds façon Xcode et agent 24/7 sur le même hôte donnent du jitter.
Courses de mise à niveau : monter Gateway avant le modèle, ou l’inverse — baseURL, jetons et vrais listeners divergent. Chemin Docker : Docker officiel et Control UI.

Ports et périmètres : collez le tableau dans le ticket

Mettez-le dans la revue pour éviter que « tout le monde visait 8000 » devienne « un autre service a pris 8000 en semaine trois ».

Composant	Défaut courant	Point d’accroche OpenClaw
Ollama	HTTP souvent `127.0.0.1:11434` ; ouvrir le LAN avec bind explicite et story pare-feu	`baseURL` provider vers la surface compatible OpenAI ; pas de proxy aveugle sans santé amont
vLLM (local)	Souvent `8000` ou perso ; plusieurs instances = ports et pools GPU/threads disjoints	Comme Ollama : valider `/v1/models` et une completion minimale avant que Gateway ne référence
OpenClaw Gateway	Control UI souvent `18789` ; suivre la vraie config `openclaw`	D’abord `healthz`/`readyz`, puis provider ; voir triage Gateway/modèle

Six étapes : un ordre que vous pouvez signer

Budget ressources : mémoire max et requêtes concurrentes côté inférence, réserve Gateway+Node ; sur du M4, laisser typiquement 10–20 % de RAM libre pour l’OS et le cache disque (ajuster au modèle).
Inférence d’abord, provider ensuite : une fois Ollama/vLLM stable, curl minimal sur chat/completions, puis démarrage ou reload Gateway — pas d’état figé « non prêt ».
Verrouiller ports et loopback : appels purement locaux ? 127.0.0.1 d’abord. Pont container ? documenter pare-feu et responsable.
Deux niveaux de sondes : couche 1 santé inférence (HTTP + mini-génération), couche 2 healthz, couche 3 sonde de dialogue ; un rouge = pas de prod.
Changements à chaud : lors d’un swap de poids/image, drainer les sessions, couper l’ingress Gateway ou passer en lecture seule si possible, échanger le modèle, remonter Gateway, refaire les sondes.
Rollback : garder le chemin de poids précédent et le bloc provider ; plusieurs changements — rollback par couches inférence puis Gateway. Doctor : post-install doctor, parties hôte macOS.

bash

# Ordre minimal de sondes (adapter hôte/port)
curl -sS "http://127.0.0.1:11434/api/tags" > /dev/null   # Ollama vivant
# curl -sS "http://127.0.0.1:8000/v1/models" > /dev/null  # vLLM
curl -fsS "http://127.0.0.1:18789/healthz"                 # Gateway
# Puis chat minimal ou openclaw doctor selon votre doc

Trois paramètres « durs » pour le guide astreinte (à mesurer)

Délai jusqu’au premier token et file : noter P95 à froid puis à chaud ; si chaud reste élevé (plusieurs secondes) avec CPU bas, inspecter mémoire unifiée et swap avant d’augmenter la concurrence.
Double charge quand gros builds Xcode/mono-repo et agent 24/7 cohabitent : OOM ou tokens très lents ; créneaux, files ou builder dédié coûtent moins que renommer des modèles au hasard.
Keep-alive et timeouts : sur les longs flux, un seul côté trop court entre inférence et Gateway→client donne des coupures en milieu de stream ; modifier par paires et tracer le change.

Pourquoi portable ad hoc et machine partagée non gérée perdent sur ce cas

Sommeil/veille, uplink résidentiel instable, voisins imprévisibles transforment démarrages et sondes reproductibles en loterie. Ollama+Gateway exige une enveloppe thermique stable et un I/O prévisible. Mettre agent et inférence sur un hôte dédié, 24/7, avec RAM et stockage écrits au contrat baisse souvent le MTTR mieux que des mois de réglages fins. Pour industrialiser le runbook, les Mac cloud MACCOME combinent Apple Silicon dédié et modèles locatifs parlant finance—vous débattez de tableaux ressources et changements, pas de chance.

Ce qu’il vaut mieux ne pas faire la première semaine

Ne montez pas la concurrence Gateway sans avoir prouvé un completion unique bout en bout. Ne bump pas Gateway avant d’avoir vérifié que le port d’inférence n’est pas déjà pris. Deux coupes nettes valent mieux que dix pages de folklore.