Trois douleurs qui ressemblent à des régressions d'inférence après un changement de routage
1) Dérive silencieuse du modèle par défaut entre fournisseurs. OpenClaw peut accepter un surnom de modèle alors que chaque backend résout différemment. Les fournisseurs cloud exposent de longs identifiants avec suffixes de version. Ollama utilise des tags locaux comme latest qui bougent après un pull nocturne. Le processus passerelle reste sain, doctor réussit car les fichiers parsent, pourtant les complétions se tronquent car la chaîne effective ne correspond plus à une route API autorisée ou à des poids locaux. Corrigez avec un inventaire : identifiants canoniques par fournisseur, tags Ollama épinglés en production et journal des changements—même rigueur que pour les migrations de base.
2) Cécité aux quotas jusqu'à l'effondrement de qualité. Les limites de débit s'annoncent rarement poliment dans le chat. Certaines APIs renvoient des erreurs structurées avec retry-after ; d'autres dégradent d'abord la latence. Les équipes qui ne lisent que les logs applicatifs manquent les compteurs de tableau de bord déjà à quatre-vingt-dix pour cent. Le routage hybride sans repli répété transforme le premier quota en réunion d'architecture. Fixez des budgets de tokens par route, des alertes à soixante-quinze et quatre-vingt-dix pour cent des enveloppes mensuelles lorsque le fournisseur les expose, et décidez par écrit si l'inférence locale peut remplacer des modèles cloud premium.
3) Mauvaise lecture des signaux : doctor est statique, les pannes sont dynamiques. openclaw doctor valide la forme de configuration, les fichiers et des dépendances statiques. Il ne remplace pas une sonde live que votre endpoint cloud autorise encore la clé, ni ne prouve qu'Ollama garde un modèle résident sous charge. S'arrêter après doctor montre des coches vertes alors que la requête suivante échoue sur le transport ou des réponses vides. Associez doctor à curl sur le port HTTP de la passerelle, archivez health JSON selon un calendrier et corrélez les anomalies dans des journaux structurés. Sans instantané de santé propre, vous perdez du temps dans le bruit.
Ces points expliquent des comportements divergents sur la même version : chaînes de modèle, posture quota et ordre de diagnostic différents. Standardisez la documentation par rôle d'hôte, pas par portable individuel.
Ajoutez un protocole d'architecture par environnement : qui change les tags, qui approuve les clés cloud, quelles alertes vont à qui. Sans rôles, les expériences ad hoc heurtent la production. Documentez aussi quelles classes de données doivent rester locales—données personnelles qui ne doivent pas atterrir dans certaines régions—pour que le routage hybride ne viole pas la politique interne. Dans les secteurs réglementés, cette classification va dans le même tableau que les identifiants de modèle.
Enfin reliez les notes de version OpenClaw aux changements de routage : nouveaux ports par défaut, clés renommées ou validation renforcée peuvent ressembler à des problèmes de modèle mais ne sont que des mises à jour de schéma. Un court diff de la sortie doctor avant et après upgrade fait gagner des heures.
Matrice de décision : APIs cloud, Ollama, routage hybride
Utilisez cette matrice en revue de conception et en post-mortem. Les chiffres sont des ancres de planification pour petits et moyens gateways 2026 ; ajustez selon vos SKU et génération Apple silicon.
| Stratégie | Idéal pour | Risque principal | Contrôles minimum |
|---|---|---|---|
| APIs cloud seules | Modèles de pointe sans matériel local | Plafonds de quota, incidents fournisseur, politique | Runbooks de rotation de clés, alertes budget, listes blanches de modèles |
| Ollama local seul | Flux isolés, prompts sensibles, démos offline | Pression RAM, itération lente des poids, usure SSD | Au moins seize Go de marge RAM sur hôtes M pour classes 7B, SSD avec centaines de Go libres pour plusieurs tags |
| Hybride : cloud primaire, repli Ollama | Passerelles de production sous pics de quota | Complexité, double observabilité, écart de qualité au repli | Health checks automatisés, messages de déclassement documentés, budgets de latence par route |
| Hybride : Ollama primaire, burst cloud | Équipes sensibles au coût avec besoins premium ponctuels | Dépenses cloud accidentelles si le burst se trompe | Plafonds durs sur routes burst, clés API séparées à faibles limites, rapprochement mensuel |
À égalité, préférez des tables de routage explicites et du health JSON archivé aux éditions ad hoc pendant l'incident. Le hybride se rentabilise quand le failover est répété trimestriellement et que les opérateurs fixent les messages utilisateur lorsque des modèles locaux répondent à la place du cloud. Alignez la politique sur votre ligne de base d'installation : les conteneurs doivent injecter le même environnement pour la passerelle et tout sidecar Ollama ; les utilisateurs npm vérifient le PATH pour les binaires ollama sous launchd ou systemd.
Comparez les VM Linux et macOS : Ollama sur Apple silicon offre souvent de meilleures performances par watt pour une même classe de paramètres—si thermique et alimentation restent stables. Les portables en veille font de mauvais sites primaires car les cycles de réveil désynchronisent les health checks.
Pour plusieurs gateways, tenez une page de synthèse : quelle route dans quel datacenter, quels quotas budgétisés ensemble, quelle instance Ollama en secours chaud. Sans cette vue, le routage hybride fragmente les tags et la réponse incident devient une chasse au trésor. Automatisez l'export health JSON vers un dépôt objet central avec règles de cycle de vie pour permettre des comparaisons forensiques même après des semaines.
Prérequis : Node, Ollama, RAM, disque et inventaire de modèles versionné
Avant de déclarer le routage hybride prêt pour la production, capturez les prérequis dans un fichier court versionné dans le dépôt d'infra. Node : version majeure requise par votre ligne OpenClaw, CLI globale ou toolchain projet, sortie de which openclaw, lockfiles épinglés, pas de majeurs Node mélangés sur un même utilisateur passerelle. Ollama : canal d'installation, si ollama serve tourne en agent utilisateur ou service, variables d'environnement pour les écouteurs. Tirez les modèles avec ollama pull et notez les tags exacts dans l'inventaire, pas seulement latest.
RAM : prévoyez une marge au-delà des seuls poids. Les agents conservent contexte, sorties d'outils et tampons. Pour beaucoup de configurations 7B sur Apple silicon, huit à douze gigaoctets libres pour l'empreinte plus requêtes parallèles et cache OS restent un point de départ—mesurez avec de vrais prompts car le RAG gonfle la mémoire. Disque : les artefacts quantifiés consomment des dizaines de gigaoctets sur plusieurs tags ; réservez au moins deux cents gigaoctets sur SSD rapide pour éviter les pulls à moitié réussis.
Associez les baselines matérielles aux attentes réseau. Le routage hybride amplifie la sensibilité au DNS, à l'interception TLS et aux timeouts du proxy. Documentez les noms Ollama pour loopback, socket Unix ou LAN. Règles de pare-feu sortantes pour les APIs cloud, y compris les IP de sortie attendues par les listes autorisées. Terminaison TLS devant le port 18789 : notez l'URL publique et le chemin de sonde interne pour éviter que les orchestrateurs ne flappent.
Répétez le cold start : arrêtez Ollama, redémarrez la passerelle, vérifiez que la première requête après boot résout modèles et identifiants sans intervention manuelle. Les reboots de nuit sans test génèrent des pannes matinales. Croisez avec la FAQ déploiement cloud lorsque le plan de contrôle mélange macOS et Linux.
Archivez aussi la sortie de openclaw health --json après chaque gros patch OS ou pilote—les chemins accélérés GPU peuvent changer et dégrader la qualité apparente du modèle alors que seul l'environnement d'exécution dérive. Surveillez l'espace SSD libre : les disques pleines ralentissent les pulls et augmentent le risque de checkpoints corrompus lors de redémarrages imprévus. Pour les équipes soumises au RGPD, documentez quels journaux contiennent des données personnelles et combien de temps elles peuvent être conservées afin que le routage hybride ne devienne pas un problème d'export de données.
Changement de fournisseur, règles de routage et pièges qui cassent le hybride
Les changements de routage sont des changements d'infra avec fenêtre de maintenance, même si le rechargement semble instantané. Séparez d'abord les classes de trafic : chat interactif, résumé en arrière-plan, chaînes lourdes en outils, commandes administratives peuvent mériter des fournisseurs ou budgets de latence différents. Évitez les valeurs par défaut ambiguës à la racine qui héritent silencieusement de modèles différents par sous-système. Assurez-vous que les variables d'environnement portant les clés API atteignent le processus qui appelle en sortie ; les conteneurs montent souvent les secrets pour la passerelle mais oublient les sidecars qui hébergent les outils locaux.
Pièges fréquents : mélange de températures et de max tokens qu'un fournisseur rejette discrètement, URL de base obsolète après migration de région, Ollama distant sans keepalive pour de longs appels d'outils, double compression dans les reverse proxies qui corrompt le streaming. Testez explicitement les modes streaming et non streaming.
Sous pression, changez une seule variable à la fois : identifiant de modèle, clé API ou chemin réseau. Capturez health JSON avant et après chaque étape. En cas de retour arrière, restaurez l'artefact de configuration depuis le contrôle de version plutôt qu'à la main. Liez la documentation de routage à la même discipline que dans l'article passerelle pour que ponts et backends d'inférence restent alignés pendant les incidents.
Séquence de diagnostic pour la santé hybride
openclaw status
curl -sS -m 5 http://127.0.0.1:18789/health || echo "gateway health probe failed"
openclaw doctor
openclaw health --json > /tmp/openclaw-health-hybrid-$(date +%Y%m%d%H%M).json
ollama serve
ollama pull llama3.1:8b
Exécutez ollama serve uniquement sur l'hôte qui porte l'inférence locale ; adaptez les tags de modèle à la liste approuvée. Ordre logique : propriété du processus, santé HTTP, configuration statique, health JSON structuré, puis cycle de vie des modèles locaux.
Discipline de failover : doctor, journaux et tableaux fournisseur
Le failover n'est pas seulement changer de route ; c'est prouver que le basculement a réussi avant que les utilisateurs ne réessayent au hasard. Commencez par openclaw status pour confirmer quel processus possède les fichiers de configuration. Puis une sonde HTTP sur 127.0.0.1:18789 ou l'équivalent derrière proxy pour séparer échec d'écoute et échec d'inférence amont. Ensuite openclaw doctor pour attraper les erreurs statiques après édition. Enregistrez openclaw health --json avec horodatage pour comparer les champs entre incidents.
Seulement après cette échelle, plongez dans les journaux verbeux. Les journaux excellent à séquencer les événements mais sont bruyants sans baseline. Filtrez par sous-système : HTTP passerelle, client fournisseur, exécution d'outils, démon Ollama. Lorsque les APIs cloud limitent le débit, comparez journaux, tableau de bord fournisseur et facturation ; souvent la passerelle est saine mais le compte est à sec. Pour Ollama, vérifiez éviction mémoire ou saturation du contexte.
Modèle d'incident court : fenêtre temporelle, classe de route affectée, fournisseurs primaire et secondaire, identifiants de modèle exacts, pièces jointes health JSON, failover automatique ou manuel—accélère les post-mortems. À côté d'une promotion d'artefacts SFTP, planifiez des fenêtres de maintenance pour que transferts et tests d'inférence ne se disputent pas SSD et CPU.
Pour les sessions longues, surveillez les timeouts de lecture du proxy : les chaînes lourdes en outils dépassent souvent soixante secondes même si les modèles restent sains. Augmentez les timeouts délibérément et documentez le plafond pour les revues sécurité. Répétez trimestriellement l'épuisement de quota en staging.
Enrichissez le modèle d'incident avec des clés de corrélation anonymisées et une matrice d'escalade courte (code d'erreur → repli automatique ou appel support). Archivez des dumps JSON fournisseur lorsqu'ils portent des indices de quota restant.
FAQ, synthèse et quand un Mac distant hébergé convient
FAQ : Épingler les tags Ollama en production ? Oui, comme des versions de dépendances. Archiver health JSON quotidiennement en production et après chaque changement de config en staging. Conformité ? Le hybride peut faire sortir des données sur des routes cloud et les garder locales sur d'autres—documentez la classification par classe de trafic.
- Doctor propre mais complétions vides : vérifiez chaînes de modèle, portées de clé, résidence Ollama sous charge.
- 429 intermittentes : backoff exponentiel si possible, routage local des charges discrétionnaires si la politique le permet.
- Passerelle saine mais canaux silencieux : revenez à la configuration des ponts comme dans l'article passerelle ; l'inférence peut fonctionner pendant que le transport messager échoue.
Synthèse : un routage hybride fiable combine inventaires épinglés, conscience des quotas, échelle de diagnostic fixe et failover répété qui traite backends locaux et cloud comme pairs aux modes de défaillance différents.
Limite : le routage purement cloud vous expose aux quotas et incidents fournisseur que vous ne corrigez pas localement. Le routage purement local plafonne qualité et fraîcheur lorsque le budget matériel est fini et que vous avez besoin de raisonnement de pointe pour des tâches de niche.
Angle SFTPMAC : un Mac distant hébergé offre alimentation stable, disponibilité continue et colocation avec des chemins SFTP ou rsync que beaucoup d'équipes utilisent déjà pour les artefacts écosystème Apple. Lorsque votre passerelle OpenClaw doit rester en ligne à côté des mêmes points de dépôt audités que votre pipeline CI, quitter un portable en veille réduit les health checks désynchronisés et la dérive des permissions sans sacrifier les toolchains natives. Standardisez sur une infra 24/7 lorsque l'inférence hybride fait partie de la production.
Si vous utilisez déjà SFTPMAC pour les builds, ajouter une passerelle OpenClaw est souvent un rôle géré de plus sur la même plateforme.
Activer le hybride par défaut pour les nouvelles passerelles ?
Seulement après avoir documenté modèles de repli, comportement de déclassement visible et supervision—sinon la complexité l'emporte.
Quelle rétention des journaux ?
Au moins quatorze jours en stockage chaud pour corrélation ; plus longtemps si la conformité exige de reconstruire les décisions de routage.
Le cloud Linux remplace-t-il le Mac pour Ollama ?
Souvent oui pour l'inférence seule ; choisissez Mac lorsque la toolchain, la signature ou les chemins supposent macOS et la performance Apple silicon par watt.
Besoin d'un Mac stable pour le routage hybride OpenClaw à côté d'une livraison de fichiers gérée ? Comparez les offres SFTPMAC et déployez-y votre passerelle.