2026 OpenClaw : routage multi-modèles & failover fournisseurs
Chemins npm vs Docker, quotas et triage des journaux Gateway

Six familles de douleur pour les déploiements multi-modèles (à mettre dans le runbook d’astreinte)

Lorsque modèles par défaut et de repli et plafonds de débit de fournisseurs distincts se cachent derrière une même passerelle, les pannes semblent aléatoires. Cartographiez ces six classes sur les champs d’alerte—ne vous arrêtez pas au seul statut HTTP.

1. Dérive ID modèle vs table de routage : les libellés changent alors que les requêtes touchent encore d’anciens identifiants ; les caches CLI et Gateway divergent.
2. 429 et timeouts confondus : le throttling exige backoff et rotation de clés ; les timeouts exigent délais et correction d’egress—les mélanger amplifie les tempêtes de retry.
3. Rotation multi-clés sans bornes : clés primaires et de secours partagent un même budget d’échec et brûlent toutes deux.
4. Fourche npm global vs env Compose : export sur l’hôte sans injection conteneur, ou overrides Compose contraires à l’intention.
5. Healthchecks qui ne testent que la vivacité du processus : Gateway debout mais échec de handshake modèle—toujours vert.
6. Journaux sans dimensions : sans identifiant de requête, session, fournisseur et modèle, impossible de reconstruire une chaîne d’appels entre services.

Ces douleurs sont orthogonales aux sauvegardes d’upgrade et aux tags d’image : routage d’exécution vs contrôle des changements ; lisez les deux pour séparer release et astreinte.

Le multi-modèle implique souvent plusieurs comptes de facturation et périmètres de conformité. Sans portée explicite des sessions aux modèles, risque de surconsommation ou de violation de politique—traitez la table de routage comme un contrat coût et permissions revu avec la gouvernance des secrets.

« Endpoint joignable » n’est pas « chaîne saine » : proxys, pare-feu et DNS peuvent partager le succès par session—des journaux structurés et de l’échantillonnage battent un taux d’erreur global unique.

Tableau 1 : npm global vs Docker/Compose (édition revue)

Documentez l’ordre de chargement de configuration, la précedence des variables d’environnement et les frontières de redémarrage pour les deux chemins ou vous verrez « l’hôte a changé, pas le conteneur ».

Tableau 2 : symptôme → première action (exemple d’ordre de failover—à ajuster selon la politique)

Fixez des règles d’organisation sur quand permuter modèle vs clé vs egress et inscrivez-les dans le même document SLO. Les numéros plus petits sont des tentatives plus tôt.

Six étapes : figer la table de routage et boucler l’observabilité

1. Versionner la table de routage : défauts, replis par scénario, modèles interdits ; lier au SHA Git de config.
2. SLO par chaîne : latence P95, ratio 429, seuils de disjoncteur d’échecs consécutifs partagés avec l’astreinte.
3. Fumée double chemin : cas de chat minimaux sur npm et compose ; comparer les tuples de journaux.
4. Comptabilité des clés : compteurs d’échec et cooldowns séparés primaire/secours ; aligner la rotation sur Secrets avancé.
5. Santé après upgrade : du processus up au handshake modèle ou sonde équivalente.
6. Modèle d’incident : chaque incident inclut des échantillons de requêtes et la version de config pour recoupement avec les articles upgrade/migration.

Trois métriques solides pour tableaux de bord

1. Taux 429/timeouts ventilés par fournisseur et modèle : un succès agrégé masque une mauvaise route.
2. Compteurs d’échec par clé et hits de cooldown : alignés sur dépense multi-clés et cadence de rotation.
3. Déclenchements de downgrade vs interventions manuelles : un downgrade fréquent impose de revoir la capacité (ex. Mac distant dédié) avant d’ajouter des modèles.

En 2026, les catalogues fournisseurs continuent d’évoluer—la config comme documentation bat le savoir tribal ; stocker tables de routage et seuils d’alerte dans le même dépôt réduit les trous de passation.

Si la passerelle couvre APAC et l’Amérique du Nord, tracez une heatmap région × fournisseur : une dégradation régionale précède souvent le rouge global et informe les signaux de location de pic.

Décomposez chaque parcours utilisateur : auth → routage → appel modèle → effets de bord d’outils → réécriture de session. Chaque étape doit partager un requestId ; sinon ajoutez du tracing avant de régler les modèles.

Pour les configurations hybrides (portable, serveur nu, conteneur), exécutez un test de parité minimal hebdomadaire : même prompt et version de route sur les trois chemins ; figez les releases si l’écart latence/erreur dépasse le seuil.

Pourquoi portables et proxys ad hoc peinent sous la charge multi-modèle en production

Les appareils personnels ajoutent veille, WAN instable et variables d’environnement non auditées qui transforment les bogues de routage en fantômes intermittents. Quand CI, paging ou SLA clients s’appliquent, il faut du calcul dédié, un egress stable et des conditions de location contractuelles—pas des éditions infinies du fichier hosts.

Pour une passerelle 24/7, l’automatisation par lots ou une latence réduite à côté des hôtes de build/signature, placer l’exécution sur un cloud Mac multi-régions professionnel est en général plus simple à observer et à auditer. MACCOME propose des Mac Mini M4 / M4 Pro bare-metal multi-régions avec des conditions flexibles—à croiser avec le guide multi-régions et durées et les tarifs.

Pilotez dans une région jusqu’à stabiliser routes et champs de journaux, puis décidez si la passerelle co-localise les charges pour éviter inférence inter-régions et throttling.

Si vous utilisez aussi des canaux avancés depuis le runbook avancé, livrez les changements de routage modèle séparément des changements de config canal pour limiter le rayon d’explosion ; attachez la version de table de routage au ticket de changement pour échantillonnage des journaux et audits.