Concevoir le routing et le failover LLM multi-provider avant une panne

Pourquoi les pannes de provider ne sont pas le seul mode d’échec

Les problèmes de fiabilité LLM se présentent rarement comme une panne provider nette. Le provider peut encore répondre, mais la latency passe de deux secondes à trente. Un model peut renvoyer davantage de refus après une mise à jour de sécurité. Une région peut atteindre sa capacité tandis qu’une autre reste saine. Une carte de coûts peut changer au point que la meilleure route par défaut pour un workload ne soit plus la meilleure pour un autre.

Si l’application sait seulement appeler un provider, chacun de ces événements devient un incident applicatif. Les équipes se précipitent pour patcher des appels SDK, modifier des variables d’environnement ou déployer des branches d’urgence. C’est une façon fragile d’exploiter des fonctionnalités IA dont les clients dépendent.

• La latency peut se dégrader avant que la disponibilité n’échoue.
• Les rate limits peuvent bloquer un tenant alors que d’autres tenants ont encore de la marge.
• Le comportement d’un model peut changer sans panne réseau.
• Un provider peut rester sain pour les chat completions, mais échouer pour les embeddings, la vision ou les tool calls.
• Un model de fallback peut être techniquement joignable, mais inadapté au workload.

Ce qu’une politique de routage doit considérer

Un bon routing commence par le workload, pas par le vendor. Un assistant de support client, un agent de code interne, un pipeline d’embeddings et une surface de chat temps réel n’ont pas la même tolérance à la latency, au coût, à la longueur de contexte et à la variation des sorties.

Cela signifie que les politiques de routing doivent être explicites. Quels models sont autorisés pour cette virtual key ? Quel fallback est acceptable si le model préféré est lent ? Le gateway doit-il prioriser le coût, la vitesse, la disponibilité ou la qualité ? Les tenants régulés doivent-ils rester sur un provider privé ou régional même lorsqu’un autre provider est moins cher ?

• Capacité du model : longueur de contexte, modalité, tool calling, sortie structurée et qualité linguistique
• Santé : statut du provider, erreurs récentes, taux de timeout et disponibilité régionale
• Latency : comportement p95 et p99, pas seulement le temps de réponse moyen
• Coût : prix des tokens, volume de requêtes, état du budget et allocation tenant
• Policy : restrictions tenant, résidence des données, contrôles de sécurité et listes de models approuvés

Pourquoi les pools de fallback sont meilleurs qu’un backup global

Une erreur fréquente consiste à choisir un seul model de fallback universel. Cela paraît simple, mais masque un problème de fiabilité. Un fallback qui fonctionne pour une tâche de synthèse peut être inacceptable pour un workflow de génération de code. Un model moins cher peut convenir pour des suggestions de brouillon, mais être risqué pour une extraction sensible à la conformité.

Les pools de fallback doivent être regroupés par cas d’usage. Chaque pool doit définir la route préférée, les alternatives acceptables, le comportement de timeout et les règles de dégradation. Certains workloads doivent échouer fermement plutôt que se dégrader silencieusement. D’autres peuvent basculer sans risque vers un model plus petit ou moins cher lorsque le provider principal est lent.

Le gateway est l’endroit naturel pour stocker ces règles, car il réunit déjà l’identité de la requête, les permissions de clé et l’état de santé des providers.

Comment Odock garde le code applicatif stable

Odock est conçu pour se placer entre les applications et les model providers comme un point de contrôle unique. Les équipes produit appellent un endpoint. Les équipes plateforme gèrent les routes providers, les permissions de model, les workflows de plugins, les guardrails de sécurité et les budgets derrière cet endpoint.

Cette séparation compte pendant les incidents. Si un provider ralentit, la politique de routing peut changer sans demander à chaque équipe applicative de redéployer. Si un nouveau model devient disponible, il peut être testé derrière le gateway avant que le code produit n’en dépende. Si un client a des exigences strictes en matière de providers, ces règles peuvent être attachées à la virtual key plutôt que vivre dans des conditionnels dispersés.

Que mesurer avant de faire confiance au failover

Le failover doit être testé avant d’être nécessaire. Le premier test n’est pas de savoir si le provider de backup répond. Le vrai test est de vérifier que tout le chemin de requête respecte encore les limites de coût, les contrôles de sécurité, le logging et la policy tenant.

• Le gateway enregistre-t-il quel provider a traité la requête finale ?
• Les décomptes de tokens et les dépenses sont-ils attribués à la bonne virtual key ?
• Les règles contre le prompt injection et la fuite de données s’exécutent-elles encore avant le fallback ?
• Les formats de réponse sont-ils suffisamment compatibles avec l’application ?
• Le système alerte-t-il sur un routing dégradé au lieu de le masquer ?

Une infrastructure IA fiable ne se construit pas seulement en ajoutant davantage de providers. Elle se construit en faisant du choix de provider une policy opérationnelle observable, testable et modifiable en toute sécurité.