La passerelle LLM bascule. La panne disparaît des traces.

Dix requêtes ont atteint un modèle primaire hors service. Les dix ont reçu un statut 200 grâce au repli. Le journal de dépenses conserve dix succès et aucune trace des tentatives primaires en échec.

Une passerelle qui prend ces décisions dépasse le rôle de proxy. Elle choisit le modèle, décide si une clé peut encore dépenser, limite les modèles accessibles et redirige la requête quand le fournisseur préféré tombe. Elle gouverne les autres systèmes sans exécuter la tâche métier : c’est un plan de contrôle.

J’ai testé trois de ces décisions sur mon propre déploiement de référence Vauban, une passerelle LiteLLM 1.85.1 sous trafic dans mon laboratoire, et non un système client. Je n’ai modifié aucun fichier de configuration. L’expérience a créé des clés temporaires et un modèle volontairement injoignable, puis les a supprimés. Les chiffres décrivent ce déploiement à cet instant, pas LiteLLM ni toutes les passerelles.

Trois tests, trois surprises opérationnelles

La bascule maintient le service et efface la tentative en échec

Le test enregistre un modèle primaire temporaire pointant vers un port local fermé, sans nouvelle tentative. Chaque requête désigne un repli fonctionnel. Ce montage isole la bascule de la temporisation des reprises et du délai d’attente d’un fournisseur lent.

Les dix appels reviennent en HTTP 200 depuis le groupe de modèles de repli. La médiane de bout en bout atteint 1 140,1 ms. En soustrayant la durée du modèle servi, remontée par la passerelle, on obtient environ 49 ms de surcoût médian. Ce chiffre est un calcul, pas une mesure séparée de la tentative en échec.

L’appelant voit le changement de route dans deux en-têtes : x-litellm-attempted-fallbacks: 1 et x-litellm-model-group: chat-fast. Le corps de réponse ne nomme que le modèle qui a répondu.

Trente secondes plus tard, LiteLLM_SpendLogs contient dix lignes de succès pour les requêtes de repli et aucune pour les tentatives primaires en échec. En contrôle, dix appels vers le même primaire mort, sans repli, produisent bien dix lignes d’échec. La passerelle sait donc journaliser la panne, mais ce chemin ne la conserve pas dans la table de facturation.

La bascule préserve la disponibilité, pas une piste d’audit complète. Conservez les en-têtes ou produisez un événement par tentative ; sinon, la panne peut disparaître du système interrogé pendant l’incident. Assembled rapporte moins de 0,001 % de requêtes en échec pendant une panne fournisseur de plusieurs heures grâce au repli automatique. Cela montre le bénéfice de disponibilité. Pas la capacité de votre système à reconstruire chaque décision.

Un plafond budgétaire contrôle l’admission, pas la facture finale

Le deuxième test crée une clé virtuelle avec un max_budget d’un centime de dollar, puis envoie les requêtes une par une jusqu’au refus. Treize appels passent et consomment 71 726 jetons. Le quatorzième revient en HTTP 429 après 22,8 ms.

Le coût délivré et le compteur de la passerelle concordent à neuf décimales. Le compteur n’était pas en retard. La treizième requête a été admise alors que le cumul restait sous le plafond, puis son propre coût l’a fait franchir.

Dans cette exécution séquentielle, le dépassement atteint 0,000 524 64 USD, soit 5,25 % du minuscule plafond de test. Ce pourcentage ne prédit rien pour une autre charge. La règle réutilisable est structurelle : un budget contrôlé avant l’appel peut être dépassé par le coût d’une requête admise dont le nombre final de jetons n’est connu qu’après.

Avec plusieurs appels simultanés, plusieurs requêtes peuvent être admises contre le même état initial. Cette expérience ne mesure pas cette forme. Un budget sérieux combine donc plafond monétaire, limites de jetons en entrée et en sortie, concurrence maximale, accès aux modèles et alerte avant le refus dur.

Les actions de reprise évidentes réussissent sans restaurer le service

Une fois le plafond franchi, j’ai tenté les deux gestes qu’un exploitant choisirait naturellement. Les deux appels d’administration renvoient HTTP 200. Les deux font afficher une dépense nulle à /key/info. Aucun ne lève le refus sur ce déploiement.

Une valeur de clé réellement nouvelle rétablit l’accès. Cette opération perturbe davantage qu’une remise à zéro sur un tableau de bord ; elle doit donc figurer dans la procédure d’exploitation avant l’incident. L’expérience montre ce qui s’est produit, pas pourquoi : elle ne trace pas les composants internes de LiteLLM, ne teste pas un redémarrage du proxy et ne prétend pas qu’une autre version se comporte ainsi.

La révocation est rapide sur un processus ; le périmètre modèle échoue clairement

Lors de cinq répétitions, le test authentifie une nouvelle clé, la supprime, puis interroge la passerelle toutes les 0,25 seconde. Chaque clé est refusée dès le premier sondage et aucune requête ne passe après la suppression. Le résultat borne la fenêtre observée sous l’intervalle de sondage plus un aller-retour. Il ne démontre pas un délai nul.

Une passerelle répliquée pose un autre problème : chaque instance peut conserver son propre cache d’authentification. La fenêtre visible par l’exploitant dépend alors de la réplique la plus lente, absente de ce test sur un seul processus.

Le périmètre modèle est plus simple : une clé autorisée sur chat-fast demande chat-deep. Les trois tentatives sont refusées en HTTP 403, autour de 16 ms, tandis que trois appels de contrôle valides réussissent. L’erreur nomme le modèle autorisé, celui demandé et key_model_access_denied. L’exploitant peut résoudre la demande sans accès à la passerelle.

Les paliers de repli forment aussi une politique de résidence des données

L’expérience utilise un seul repli valide dans le périmètre. Elle ne teste aucun routage interrégional. La conséquence architecturale reste importante : le mécanisme qui contourne un fournisseur en panne peut aussi franchir une frontière géopolitique.

Microsoft recommande de traiter chaque frontière géopolitique comme un déploiement isolé. Les clients ne doivent atteindre que leur point d’entrée régional autorisé, et la passerelle ne doit pas effectuer à leur place une requête transgéographique. Si aucun repli conforme ne subsiste, une erreur peut être préférable à une réponse silencieusement servie ailleurs.

Encodez la région ou la juridiction comme une contrainte exécutable sur chaque primaire et chaque repli, avec les mécanismes pris en charge par votre version. Testez ensuite l’ensemble vide : retirez tous les serveurs de la région et vérifiez que le routage refuse la requête. Un primaire européen assorti d’un repli américain n’est pas une stratégie de résidence ; c’est un chemin d’exception non testé.

Là où s’arrêtent ces mesures

Ces résultats sont utiles parce que leurs limites sont visibles :

• Un proxy LiteLLM 1.85.1, une instance Postgres et des caches en mémoire ont été testés à un instant donné.
• Le primaire hors service refusait immédiatement la connexion TCP. Un délai d’attente, une limitation de débit ou une réponse lente produirait un autre résultat.
• Le test budgétaire utilise un appelant séquentiel, un modèle, un plafond et une forme de requête. Il ne caractérise pas la concurrence.
• La révocation teste la suppression d’une clé sur un seul proxy, pas un parc répliqué ni une requête déjà en vol.
• La partie sur la juridiction est une conséquence architecturale appuyée par une source externe, pas une quatrième mesure.

Le test d’acceptation du plan de contrôle

Lorsque le routage, l’argent et l’autorité partagent un point d’entrée, j’exige cinq choses :

• Journaliser chaque tentative, pas seulement la réponse. Conservez modèle demandé, primaire en échec, repli choisi, fournisseur, région, latence et motif sous un même identifiant de corrélation.
• Borner le coût d’une requête autant que la dépense du compte. Combinez budget, jetons, concurrence et accès modèle ; alertez avant l’arrêt dur.
• Tester le chemin de reprise. Dépassez volontairement un budget en préproduction et suivez la procédure exacte, rotation de la clé et déploiement côté clients compris.
• Intégrer la juridiction à l’éligibilité du routage. Un repli qui viole la résidence n’est pas sain. Sans candidat conforme, échouez fermé.
• Protéger la passerelle elle-même. Elle simplifie les clients, mais concentre aussi le risque de panne. Répliquez-la, testez la propagation des caches et évitez qu’un contournement devienne le plan de secours officieux.

La configuration montre que la bascule, les budgets et la révocation existent. Un plan de contrôle doit laisser assez de preuves pour que l’exploitant explique ce que chacun a fait après la requête.

Sources et reproductibilité

1. Résultats EXP-04 : bascule, budget et contrôles de clés
2. Documentation LiteLLM : bascule fournisseur
3. Documentation LiteLLM : clés virtuelles et budgets
4. Microsoft Architecture Center : passerelles, souveraineté et bascule
5. Grab Engineering : pourquoi centraliser l’accès aux modèles
6. Assembled : automatiser le repli pendant une panne fournisseur