Comment concevoir des solutions de secours LLM sans rompre les contrats de latence, de coût ou de sortie

La solution de remplacement n'est pas simplement une liste de modèles de sauvegarde. Pour les équipes d'ingénierie utilisant plusieurs fournisseurs LLM, le repli est une politique de routage qui décide quand une requête peut passer d'un fournisseur ou d'un modèle à un autre, ce qui doit rester invariant et comment le système prouve que le chemin alternatif a rendu l'application plus fiable.

Le problème du lecteur est généralement simple : réduire les requêtes ayant échoué et réduire la latence finale sans modifier silencieusement la qualité de sortie, la validité du schéma, le comportement de sécurité ou le coût. La solution est plus spécifique que « essayer un autre fournisseur ». Une stratégie de secours LLM fiable nécessite une classification des erreurs, des délais de demande, des règles de compatibilité des modèles, des limites de coûts, des disjoncteurs et une observabilité au niveau du fournisseur et de l'itinéraire.

Commencez avec une politique de secours, ne réessayez pas le code

Les nouvelles tentatives et les solutions de secours résolvent différents problèmes. Une nouvelle tentative demande au même fournisseur de terminer la même demande après un échec passager. Une solution de secours demande à un autre modèle, fournisseur, région ou itinéraire d'effectuer le travail à la place. La combinaison de ces préoccupations crée des systèmes sur lesquels il est difficile de raisonner lors d'incidents.

Fait : Les conseils en matière de fiabilité des fournisseurs d'infrastructure cloud recommandent généralement un délai d'attente exponentiel limité, une gigue, des limites maximales de tentatives, des contrôles d'idempotence et d'éviter les tentatives sur plusieurs couches, car les tempêtes de nouvelles tentatives peuvent aggraver la surcharge. Les principaux fournisseurs LLM documentent également les erreurs transitoires, les limites de débit, les réponses de surcharge, les délais d'attente et le comportement des SDK nouvelles tentatives.

Recommandation : implémentez une couche de nouvelle tentative pour chaque chemin de requête. Si la passerelle d’application réessaye, les services en aval ne doivent pas non plus réessayer indépendamment, sauf si la propriété de la nouvelle tentative est explicite. Chaque nouvelle tentative doit respecter le même délai d'attente de l'appelant, et non créer un nouveau délai d'attente illimité.

Une politique minimale doit répondre à ces questions avant d'écrire du code :

• Quels échecs peuvent être réessayés sur le même fournisseur ?
• Quels échecs permettent de recourir à un autre fournisseur ou modèle ?
• Quels échecs ne doivent jamais se déclencher solution de secours ?
• Quel contrat de sortie doit rester identique ?
• Quelle est l'augmentation maximale des coûts autorisée ?
• Quelle part du délai de demande peut être dépensée avant que la solution de secours ne soit refusée ?
• Quelle télémétrie prouve si la solution de repli a aidé ou caché un défaut ?

Classer les erreurs avant de les acheminer Eux

Le repli est dangereux lorsque chaque non-200 réponse est traitée de la même manière. Un délai d'expiration du fournisseur n'est pas la même chose qu'une demande mal formée. Une limite de taux n’est pas la même chose qu’un refus de sécurité.Un échec de validation de sortie n'est pas la même chose qu'une panne de réseau.

Une taxonomie pratique devrait inclure au moins les classes suivantes :

• Échec de transport réessayable : réinitialisation de la connexion, problème DNS, panne de réseau temporaire ou expiration du délai de passerelle.
• Surcharge du fournisseur : surcharge documentée ou transitoire côté serveur échec.
• Limite de débit : limite de requête, de jeton, d'accélération ou de quota, en particulier lorsqu'une valeur de réessai après est fournie.
• Délai d'expiration du fournisseur : le fournisseur a accepté la demande mais n'a pas terminé sa fenêtre de service.
• Demande invalide : mal formée charge utile, paramètre non pris en charge, schéma invalide ou option incompatible avec le modèle.
• Erreur d'authentification ou de configuration : clé incorrecte, compte désactivé, droit manquant ou quota au niveau du compte épuisé.
• Refus ou blocage pour des raisons de sécurité : le fournisseur refuse ou bloque intentionnellement le contenu pour des raisons de sécurité Policy.
• Échec de validation de sortie : le modèle a répondu, mais la réponse ne satisfait pas au contrat d'application.

Recommandation : réessayez uniquement les échecs transitoires dans le budget de latence de l'appelant. Autorisez le remplacement uniquement pour les classes d’erreurs que les équipes produit et plateforme ont explicitement approuvées. Ne vous contentez pas d'erreurs d'authentification, de requêtes mal formées, d'erreurs de schéma déterministes ou de refus de sécurité, à moins que le produit ne définisse un autre comportement sûr spécifique.

Cette distinction est importante, car le repli peut autrement masquer des bugs. Si un schéma n'est pas valide pour le fournisseur principal et est ignoré par un fournisseur de secours, le système peut sembler plus sain tout en renvoyant une sortie moins contrainte. Ce n’est pas la fiabilité ; il s'agit d'une dérive de contrat.

Utilisez des délais, pas seulement des délais d'attente

Les problèmes de latence de queue proviennent souvent de tentatives techniquement limitées mais pratiquement trop lentes. Une requête avec un budget destiné à l'utilisateur de 15 secondes ne doit pas échouer pendant 14 secondes sur la route principale, puis lancer une tentative de secours complète qui ne peut pas se terminer à temps.

Utilisez une date limite de requête qui est transmise à l'ensemble de la pile. Chaque décision de routage doit vérifier le temps restant avant de réessayer ou de revenir en arrière. Par exemple :

request_deadline_ms = 6000
primary_attempt_timeout_ms = 3500
retry_backoff_budget_ms = 500
minimum_fallback_budget_ms = 1800

if remaining_deadline_ms < minimum_fallback_budget_ms:
    return controlled_failure

Les chiffres exacts dépendent de la charge de travail. Un itinéraire de complétion de discussion peut réserver suffisamment de temps pour un autre modèle. Une tâche d'extraction en arrière-plan peut autoriser plusieurs tentatives. Un chemin de saisie semi-automatique en temps réel peut préférer un échec rapide à une réponse de secours tardive.

Recommandation : définissez les budgets de latence par classe de route, et non globalement. Une route d'interface utilisateur à faible latence, une route de classification par lots et une route d'analyse de contexte long ne doivent pas partager la même enveloppe de nouvelle tentative et de secours.

Définir les classes de modèle par charge de travail

Les noms de fournisseurs constituent une mauvaise abstraction pour la solution de secours. L'application se soucie des propriétés de la charge de travail : longueur du contexte, profondeur du raisonnement, prise en charge des outils, comportement de sortie structuré, latence, contraintes de gestion des données et coût.Les routes de secours doivent être organisées autour de ces propriétés.

Les classes de modèles utiles incluent :

• Brouillon rapide : réponses courtes, faible latence, tolérance de qualité modérée.
• Extraction structurée : sortie JSON stricte, validation de schéma, faible tolérance pour le format dérive.
• Raisonnement : analyse en plusieurs étapes, exigences de qualité plus élevées, latence acceptable plus élevée.
• Contexte long : documents volumineux, fenêtres de jetons élevées, règles de troncature soignées.
• Lot à faible coût : tâches asynchrones ou non urgentes optimisées pour l'unité économie.
• Augmentation des primes : modèles coûteux mais performants utilisés uniquement lorsque la politique le permet.

Pour chaque classe, répertoriez les modèles principaux autorisés, les modèles de secours autorisés et les chemins de rétrogradation interdits. Une requête à contexte long ne doit pas recourir à un modèle à contexte court qui tronque silencieusement l'invite. Une tâche d'extraction structurée ne doit pas recourir à un modèle qui ne peut pas satisfaire les contraintes du schéma. Une tâche de raisonnement premium peut permettre de revenir à un autre modèle premium, mais pas à un modèle de brouillon rapide, à moins que l'expérience utilisateur ne prenne explicitement en charge une réponse dégradée.

Pour les équipes qui créent un LLM d'entreprise API, ces classes doivent résider dans des données de configuration ou de stratégie plutôt que dispersées dans les services d'application. Cela permet de vérifier le comportement de routage et de le modifier plus facilement en cas d'incidents avec le fournisseur.

Protéger les contrats de sortie structurée

Le repli de sortie structuré est l'un des endroits les plus simples pour créer des bugs de production subtils. Les fournisseurs diffèrent dans la manière dont ils prennent en charge le mode JSON, le schéma JSON, les appels d'outils, les champs de refus, les commentaires de sécurité, les motifs de fin et les sous-ensembles de schéma. Il n'est pas garanti qu'un schéma qui fonctionne avec un modèle soit portable sur un autre.

Fait : Certaines documentations de fournisseurs décrivent le respect strict des schémas pour les modèles pris en charge, tandis que d'autres notes de documentation ne prennent en charge qu'un sous-ensemble de JSON schéma. Les réponses du fournisseur peuvent également inclure des champs de refus, des commentaires d'invite, des évaluations de sécurité, des raisons de fin ou aucun candidat lorsqu'une invite est bloquée ou invalide.

Recommandation : traitez la validation de sortie comme faisant partie de l'itinéraire, et non comme une préoccupation facultative de l'appelant. La passerelle doit valider la réponse finale avant de la renvoyer à l'application. Si la validation échoue, la route doit classer l'échec et décider si une tentative de secours est autorisée.

Il existe deux modèles réalisables :

Utiliser un sous-ensemble de schéma portable

Conserver les schémas à l'intersection des fonctionnalités prises en charge par les fournisseurs de secours approuvés. Cela améliore la portabilité et réduit la complexité opérationnelle. Le compromis est que vous risquez de perdre des contraintes spécifiques au fournisseur plus riches.

Utiliser des adaptateurs de schéma spécifiques au fournisseur

Maintenir des adaptateurs qui traduisent le contrat d'application dans le format de schéma pris en charge par chaque fournisseur. Cela préserve la capacité mais augmente la charge de test et de maintenance.Cela nécessite également une matrice de compatibilité afin que les ingénieurs sachent quelles routes peuvent être utilisées en toute sécurité.

Un enregistrement de compatibilité de base pourrait ressembler à ceci :

{
  "route": "invoice_extraction_v3",
  "contract": "invoice_json_schema_v3",
  "primary": "provider_a.structured_model",
  "fallbacks": ["provider_b.extraction_model"],
  "disallowed": ["provider_c.fast_model"],
  "requires": ["json_schema", "enum", "required_fields"],
  "validation": "strict_before_return"
}

Recommandation : ne renvoie jamais de sortie de secours simplement parce qu'il s'agit d'un texte bien formé. Renvoyez-le uniquement après avoir satisfait au même contrat au niveau de l'application attendu de la route principale.

Contrôlez les coûts avant qu'un incident ne se produise

Le repli déplace souvent le trafic vers des modèles plus coûteux, exactement au moment où le trafic est élevé ou où un fournisseur est dégradé. Sans contrôle des coûts, un mécanisme de fiabilité peut devenir un incident de dépenses.

Définissez des règles de secours qui incluent :

• Multiplicateur de prix de secours maximum par itinéraire.
• Niveaux de modèle autorisés par organisation, espace de travail ou environnement.
• Budgets de dépenses de secours quotidiens ou horaires.
• Politique distincte pour les dépenses interactives et par lots. charges de travail.
• Règles indiquant si la solution de secours peut traverser les limites du fournisseur, de la région ou de la famille de modèles.

Recommandation : mesurez le coût par réponse réussie, et pas seulement le coût brut de la requête. Une solution de repli plus coûteuse peut être justifiée si elle évite une défaillance visible par l'utilisateur sur un itinéraire critique. La même solution de repli peut s'avérer inacceptable pour le travail par lots de faible priorité.

La politique de coûts doit également être visible pour les organisations utilisant la plate-forme. Les équipes peuvent souhaiter autoriser une solution de secours premium pour les flux de travail de support client de production tout en la bloquant pour le développement, les tests ou l'expérimentation interne. Il s'agit d'une décision de gouvernance, pas seulement d'une décision de routage.

Ajouter des disjoncteurs par fournisseur, modèle, région et classe d'erreur

Une solution de secours naïve peut marteler un fournisseur dégradé. Chaque échec de requête principale déclenche une autre tentative principale, puis une autre tentative de secours, tandis que d'autres services font de même. Les disjoncteurs réduisent les pressions répétées et rendent le comportement de routage plus prévisible.

Un disjoncteur doit être suffisamment spécifique pour éviter une réaction excessive. Ne marquez pas un fournisseur entier comme défectueux, car un modèle dans une région renvoie des échecs de sortie structurés. Suivez l'état par fournisseur, modèle, région, itinéraire et classe d'erreur lorsque cela est possible.

Une simple machine à états de disjoncteur suffit pour de nombreuses équipes :

• Fermé : le trafic normal circule vers l'itinéraire.
• Ouvert : l'itinéraire est temporairement évité une fois les seuils d'erreur atteints. dépassé.
• Semi-ouverture : le trafic par sonde limitée teste la récupération avant la reprise complète du trafic.

Les seuils doivent tenir compte du volume. Dix échecs en une minute peuvent être significatifs pour une route à faible volume, mais peu pertinents pour une route traitant des milliers de requêtes par minute. Utilisez des tailles d'échantillon minimales, des fenêtres glissantes et des filtres de classe d'erreur.

Recommandation : disjoncteurs ne doivent pas seulement compter HTTP défaillances. Ils doivent également suivre séparément les échecs de validation des sorties, les taux de délai d’attente, les taux de limitation de débit et les modèles de refus ou de blocage. Ces classes impliquent des réponses opérationnelles différentes.

Enregistrer la décision de routage, pas seulement l'erreur finale

Les solutions de repli qui améliorent l'expérience utilisateur peuvent encore rendre les incidents plus difficiles à diagnostiquer.Si les journaux n'affichent que le fournisseur final retenu, les ingénieurs perdent la preuve de l'échec du fournisseur principal.

Chaque requête doit enregistrer :

• Fournisseur, modèle et itinéraire d'origine.
• Fournisseur, modèle et itinéraire de secours lorsqu'ils sont utilisés.
• Classe d'erreur qui a déclenché une nouvelle tentative ou un repli.
• ID de demande du fournisseur lorsque disponible.
• Nombre de tentatives et durée d'attente.
• Délai consommé avant chaque tentative.
• Résultat de la validation de sortie.
• Coût estimé pour chaque tentative et coût final.
• Que la réponse finale provienne de la réponse principale ou de secours.
• Organisation, espace de travail, environnement et application métadonnées lorsque la politique le permet.

Cette télémétrie prend en charge à la fois l'ingénierie et la gouvernance commerciale. Il relie également le comportement de repli au contrôle des coûts de l'IA API lorsque différentes équipes, produits ou clients ont des politiques de fiabilité et de budget différentes.

Mesurer si le repli a réellement aidé

Le taux de réussite brut n'est pas suffisant. Une stratégie de secours peut augmenter les 200 réponses finales tout en aggravant la latence p99, en doublant le coût ou en renvoyant une sortie structurée moins valide.

Mesurez au moins ces métriques par route :

• Taux de réussite principal.
• Taux de réussite final après nouvelle tentative et repli.
• p50, Latence p95 et p99 avant et après le repli.
• Taux d'appel de secours.
• Coût par réponse réussie.
• Taux de réponse valide pour le contrat.
• Taux de refus ou de blocage pour des raisons de sécurité par fournisseur.
• Signaux de régression de qualité spécifiques à l'application évaluation.

Prédiction : À mesure que de plus en plus d'entreprises utilisent une infrastructure LLM multi-fournisseurs, les politiques de secours s'apparenteront davantage à une ingénierie du trafic qu'à une gestion ad hoc des exceptions.Les équipes s'attendront à des contrôles de stratégie par espace de travail, environnement et classe de charge de travail, avec des journaux d'audit expliquant pourquoi un modèle a été sélectionné.

Liste de contrôle de mise en œuvre

Utilisez cette liste de contrôle avant d'activer le repli sur une route de production :

• Définissez le budget de latence de la route et la date limite de demande.
• Classez les erreurs du fournisseur en réessayables, éligibles au repli et terminales. classes.
• Document indiquant quels échecs ne doivent pas déclencher une solution de secours.
• Répertoriez les modèles principaux et de secours approuvés par classe de charge de travail.
• Vérifiez la longueur du contexte, la prise en charge des outils, la prise en charge des schémas et le comportement de sécurité pour chaque solution de secours.
• Validez chaque réponse finale par rapport au contrat d'application.
• Définissez le nombre maximal de tentatives, gestion des interruptions, de l'instabilité et des nouvelles tentatives.
• Configurez les disjoncteurs par fournisseur, modèle, région et classe d'erreur.
• Définissez des multiplicateurs de coûts et des limites de dépenses de secours.
• Consignez les ID de demande, les classes d'erreur, les tentatives, les résultats de validation, la latence et le coût.
• Examinez la latence p95 et p99 après le déploiement, et pas seulement la moyenne. latence.
• Panne du fournisseur de test, limite de débit, schéma invalide, refus de sécurité et scénarios d'échec de validation de sortie.

Conclusion exploitable

Une bonne stratégie de secours LLM est une politique de routage gouvernée. Il sépare les nouvelles tentatives des solutions de secours, classe les échecs avec précision, préserve les contrats de sortie, respecte les délais de latence et rend les coûts visibles avant que les incidents ne surviennent.

Le principe clé de conception est l'invariance. Décidez de ce qui doit rester vrai lorsque le trafic passe du modèle principal à un modèle de secours : validité du schéma, comportement de sécurité, gestion du contexte, prise en charge des outils, limites de coûts et observabilité. Autorisez ensuite le repli uniquement lorsque ces invariants peuvent être préservés.

Commencez avec une route de grande valeur plutôt qu'un commutateur de secours global. Définissez sa taxonomie d'erreurs, ses modèles de secours compatibles, ses règles de validation, ses disjoncteurs et ses métriques. Exécutez des exercices d’échec sur cette route. Si le taux de réussite final s'améliore sans latence p99 inacceptable, perte de réponse valide au contrat ou augmentation des coûts, étendez la stratégie à la classe de charge de travail suivante.

Lecture connexe

• allocation des dépenses LLM par équipe et application