Réduire les coûts LLM avec Switchyard et un AI Gateway

August 13, 2026 · Automatisation IA · ~ 17 min de lecture

Les coûts d’API LLM augmentent rarement à cause du seul tarif unitaire d’un modèle. Ils sont souvent amplifiés par les contextes répétitifs, les mauvais choix de modèle, les nouvelles tentatives non contrôlées, les appels non attribués et l’absence de validation qualité. Cet article présente une méthode d’optimisation avec Switchyard pour expérimenter le routage, puis un AI Gateway pour centraliser les budgets, les journaux, les limites et la facturation interne.

Réduire les coûts LLM avec Switchyard et un AI Gateway ne consiste pas à remplacer tous les appels par le modèle au tarif le plus bas. La méthode fiable consiste à classer les requêtes, mesurer leur qualité, compresser les contextes répétitifs, réutiliser les réponses admissibles, limiter les nouvelles tentatives et attribuer chaque appel à un budget métier.

Cette approche s’adresse aux équipes de plateforme qui gèrent plusieurs modèles, aux responsables techniques chargés du coût des agents et aux développeurs qui préparent un environnement de routage contrôlé.

Dernière mise à jour : 13 août 2026. Les capacités de routage de Switchyard, les paramètres de cache et les règles de facturation doivent être revérifiés dans la documentation officielle avant chaque mise en production.

Commencer par mesurer la dépense réelle

Une baisse du tarif par jeton ne garantit pas une baisse de la facture finale. Une application peut appeler un modèle moins cher tout en envoyant deux fois plus de contexte, en relançant une requête après un délai d’attente ou en déclenchant plusieurs sous-agents pour produire une seule réponse visible.

Le premier travail consiste donc à reconstruire le coût d’une requête métier complète, et non celui d’un appel isolé. Le journal de l’AI Gateway devrait contenir au minimum :

l’identifiant de la requête métier et celui du locataire ;
le projet, l’environnement et la fonction concernée ;
le modèle demandé et le modèle réellement utilisé ;
les jetons d’entrée, les jetons de sortie et, lorsqu’ils existent, les jetons réutilisés ;
la durée d’attente, le code d’erreur et le nombre de nouvelles tentatives ;
la décision de routage et la raison d’une éventuelle escalade ;
le résultat du contrôle qualité ou de la validation structurée.

Cette granularité permet de distinguer cinq mécanismes d’amplification : le contexte inutile, le mauvais modèle, la répétition d’appels, l’absence de cache et la consommation non attribuée. Sans cette distinction, l’équipe risque de réduire le prix unitaire tout en laissant intacte la cause principale de la dérive.

Un AI Gateway joue ici le rôle de plan de contrôle. Il ne doit pas seulement transmettre une requête vers un fournisseur ; il doit centraliser l’authentification, les journaux, les limites, les budgets, les politiques de modèles et la ventilation des usages.

Définir des niveaux de modèle avant le routage

Le routage de modèles devient dangereux lorsqu’il est fondé uniquement sur un mot-clé ou sur une estimation intuitive de la difficulté. Une demande de résumé audio, une extraction de métadonnées vidéo et une analyse contractuelle peuvent contenir une longueur similaire, tout en exigeant des niveaux de fiabilité très différents.

Une segmentation plus utile combine trois dimensions :

la difficulté : classification, extraction, génération, raisonnement ou orchestration d’outils ;
le risque : brouillon interne, contenu destiné à un client, décision financière ou action irréversible ;
le seuil de qualité : format valide, exactitude minimale, absence d’omission critique ou validation humaine obligatoire.

Switchyard peut servir de laboratoire pour tester cette classification. Sa documentation décrit un proxy capable de recevoir des formats OpenAI et Anthropic, de normaliser les requêtes, d’appliquer une politique de routage, de choisir une cible puis de traduire la réponse vers le format attendu par le client. Il prend également en charge des stratégies fixes, aléatoires, par classificateur et par signaux de session. Documentation officielle de l’architecture de Switchyard

Dans un premier temps, la plateforme devrait définir trois catégories opérationnelles :

niveau économique : tâches répétitives, réversibles et faciles à contrôler ;
niveau standard : réponses qui exigent davantage de compréhension ou un format plus strict ;
niveau renforcé : raisonnement complexe, récupération après erreur, décisions sensibles ou appels d’outils à conséquences.

L’objectif n’est pas de forcer chaque requête dans une catégorie définitive. L’objectif est d’établir une hypothèse mesurable, puis de vérifier si la cible sélectionnée respecte les critères de qualité.

Le mode de routage par étapes de Switchyard est particulièrement intéressant pour les agents. Il peut utiliser l’historique des résultats d’outils pour reconnaître une phase d’exploration, une progression mécanique ou une récupération après erreur, puis orienter les tours vers une cible adaptée. La documentation indique également qu’un classificateur peut intervenir lorsque les signaux sont ambigus. Description officielle du routage par étapes

Dans une expérimentation sérieuse, le routage doit être comparé à une politique de référence. L’équipe peut conserver temporairement la sélection actuelle, enregistrer la décision proposée par Switchyard et vérifier, sur un jeu de validation, les erreurs de classement, les changements de qualité, la durée d’attente et le nombre d’appels supplémentaires.

Un classificateur est lui-même un appel de modèle. S’il est sollicité sur chaque requête, son coût, sa latence et ses erreurs doivent apparaître séparément dans les métriques. Le routage ne doit pas créer une nouvelle dépense invisible.

Réduire le contexte avant de changer de modèle

Le contexte transmis à une API LLM contient souvent plusieurs couches qui se répètent :

les instructions système ;
l’historique complet de la conversation ;
les résultats de recherche déjà résumés ;
les sorties d’outils conservées alors qu’elles ne sont plus nécessaires ;
les schémas, exemples et règles qui ne concernent pas la tâche courante.

La compression utile ne consiste pas à supprimer indistinctement des messages. Elle consiste à définir un budget de contexte par étape. Une équipe peut conserver l’historique complet dans un journal d’audit, mais n’envoyer au modèle qu’un résumé vérifié, les champs nécessaires et les références permettant de retrouver la source.

Pour les usages audio, vidéo et design, cette distinction est essentielle. Une analyse de storyboard peut nécessiter les scènes actuellement modifiées, tandis qu’un agent de montage n’a besoin que des timecodes, des contraintes de format et des décisions validées. Transmettre de nouveau tous les commentaires précédents augmente le volume sans améliorer nécessairement la sortie.

La compression doit être évaluée selon quatre contrôles :

le nombre de jetons avant et après réduction ;
les informations critiques conservées ;
le taux d’erreur ou d’omission ;
la possibilité de retrouver la source originale.

Un résumé de contexte doit également avoir une version. Si le prompt, le schéma de sortie ou la politique métier change, un ancien résumé ne doit pas être considéré comme équivalent au nouveau format. Cette version doit être inscrite dans les journaux afin de relier la qualité observée aux décisions d’optimisation.

Le cache de préfixe fourni par certains modèles peut compléter cette stratégie. La documentation officielle indique que le mécanisme concerné commence à partir de préfixes de 1 024 jetons et expose les jetons mis en cache dans les informations d’utilisation. Elle précise aussi que ces caches sont généralement supprimés après 5 à 10 minutes d’inactivité et au plus tard dans l’heure qui suit leur dernière utilisation. Informations officielles sur le cache de prompts

Ces conditions montrent pourquoi il est risqué de promettre une économie fixe. Le bénéfice dépend de la répétition réelle des préfixes, de la durée entre les appels, du modèle sélectionné et de la politique de facturation active au moment de l’exécution.

Encadrer le cache et la réutilisation

Un cache de réponse est pertinent lorsque trois conditions sont réunies : la demande est suffisamment déterministe, les données changent peu et la réutilisation est autorisée par le métier. Un cache intermédiaire peut également stocker un résumé, une extraction de métadonnées ou une étape de classification, même si la réponse finale ne peut pas être réutilisée telle quelle.

La clé de cache devrait intégrer au moins :

le nom et la version du modèle ;
la version du prompt ;
les paramètres qui modifient la sortie ;
l’identifiant du locataire ou du périmètre d’autorisation ;
la version des données utilisées ;
une date d’expiration adaptée au contenu.

Une clé basée uniquement sur le texte de la question est insuffisante. Deux utilisateurs peuvent poser la même question sur des documents différents, ou disposer de droits distincts. Dans ce cas, une réponse réutilisée sans contrôle d’autorisation crée un risque de confidentialité.

Les équipes doivent aussi mesurer le taux de succès du cache, le volume de réponses servies depuis le cache, les invalidations et les réponses refusées pour cause de données périmées. Le cache n’est donc pas un simple interrupteur technique ; c’est une politique de fraîcheur et d’accès.

Pour un assistant de création vidéo, par exemple, les informations de projet stables peuvent être réutilisées, tandis que les plans, fichiers ou droits récemment modifiés doivent provoquer une invalidation. Pour un outil de design, la bibliothèque de composants peut être mise en cache, mais la version active d’un fichier ou les commentaires privés doivent rester liés au périmètre de l’utilisateur.

Limiter les nouvelles tentatives et les retours arrière

Les erreurs de délai d’attente, de limitation de débit, de réseau ou de format de sortie n’ont pas le même traitement. Une nouvelle tentative immédiate peut être pertinente pour une erreur réseau transitoire, mais elle peut aggraver une limitation de débit. Une sortie JSON invalide peut nécessiter une correction ciblée, tandis qu’un contexte trop long doit déclencher une réduction ou une autre cible.

La politique doit préciser :

quelles erreurs peuvent être retentées ;
combien de tentatives sont autorisées ;
quel délai d’attente progressif appliquer ;
quand ouvrir un circuit de protection ;
quelle cible utiliser en repli ;
quand arrêter l’agent et demander une intervention.

Le compteur le plus important n’est pas seulement le nombre d’erreurs. Il s’agit du nombre d’appels de modèles déclenchés par une requête métier réussie ou échouée. Un agent qui produit une réponse après plusieurs appels peut sembler fonctionnel tout en multipliant le coût réel.

Switchyard documente des mécanismes de repli, notamment lorsqu’une cible rencontre un dépassement de fenêtre de contexte. Dans une architecture d’entreprise, ces replis doivent être journalisés comme des décisions de coût et de qualité, et non comme de simples détails d’infrastructure. Référence officielle sur la configuration des cibles et des replis

Une règle utile consiste à séparer la récupération technique de la récupération fonctionnelle. Une erreur réseau peut justifier une nouvelle tentative limitée ; une réponse incohérente ou une boucle d’outil devrait plutôt déclencher une validation, une réduction de périmètre ou une escalade. Cette distinction empêche le système de transformer une erreur de qualité en série d’appels identiques.

Attribuer chaque appel à un budget

Un budget global mensuel est trop vague pour piloter une plateforme multiéquipes. Il faut créer une hiérarchie d’imputation :

organisation ;
équipe ou centre de coûts ;
projet ;
environnement ;
agent ou fonctionnalité ;
type d’usage.

Cette structure permet de répondre à une question opérationnelle : quelle fonctionnalité consomme, avec quel niveau de qualité, et à la suite de quelle décision de routage ?

L’AI Gateway devrait appliquer au moins trois niveaux de contrôle :

Alerte : notification lorsque la consommation dépasse une tendance ou une enveloppe définie.
Limitation : réduction du débit, interdiction de certaines cibles ou passage vers une politique économique.
Blocage : arrêt des appels lorsque le budget ou le risque dépasse la limite acceptée.

Le coût doit rester associé à l’identifiant de la requête métier. Sans cette relation, une facture par modèle ne révèle pas qu’un outil de recherche, un agent de support ou une fonctionnalité de montage vidéo est responsable de la dépense.

Les règles de prix changent aussi selon le modèle, le fournisseur, le type de jeton, la mise en cache et le mode de traitement. La page officielle de tarification rappelle que les unités et les conditions peuvent varier selon les services utilisés. Les montants doivent donc être importés depuis les sources officielles et révisés avant chaque décision de routage. Page officielle des tarifs d’API

Pour éviter une gouvernance trop rigide, le budget peut être associé à une action graduelle. Un premier seuil déclenche une alerte, un second interdit les modèles renforcés pour les tâches non prioritaires, puis un troisième bloque les nouvelles exécutions. Les tâches critiques doivent disposer d’une exception documentée, avec propriétaire et justification.

Vérifier la qualité après une dégradation

Un modèle économique ne doit pas être validé parce qu’il est moins cher. Il doit être validé parce qu’il réussit une classe de tâches bien définie.

Le jeu de validation devrait contenir :

des demandes simples et représentatives ;
des cas ambigus ;
des entrées longues ;
des erreurs volontaires ;
des formats structurés à respecter ;
des exemples audio, vidéo ou design lorsque ces usages font partie du produit.

Les critères doivent combiner exactitude, complétude, conformité du format, refus appropriés, durée d’attente et nombre d’appels. Pour les tâches sensibles, un échantillon doit être relu manuellement. Pour les sorties structurées, un validateur automatique doit bloquer l’escalade silencieuse d’une réponse incorrecte.

L’escalade vers une cible renforcée peut être déclenchée par :

un score de confiance inférieur au seuil ;
une erreur de validation ;
une sortie incomplète ;
une répétition d’outil sans progression ;
une demande nécessitant une action à risque ;
un dépassement de contexte.

Le résultat attendu n’est pas le taux de passage le plus élevé d’un modèle isolé, mais le meilleur compromis entre coût, qualité, latence et fiabilité pour chaque catégorie.

Une dégradation doit également être réversible. Si la qualité d’une catégorie baisse après une modification de prompt ou de fournisseur, l’AI Gateway doit pouvoir revenir à la politique précédente sans redéployer toute l’application. Les versions de routage, les seuils et les jeux de validation doivent donc être traités comme des éléments de configuration contrôlés.

Déployer dans le bon ordre

La réduction des coûts LLM doit être livrée par étapes afin d’éviter une optimisation impossible à expliquer.

Étape 1 : établir la base

Exporter une période représentative de journaux et calculer les appels par requête, les jetons, les erreurs, les reprises et les modèles utilisés. Aucun changement de routage ne devrait précéder cette base.

Étape 2 : imposer l’imputation

Rendre obligatoires le projet, l’environnement, l’usage et l’identifiant métier. Les appels sans propriétaire doivent être refusés en environnement de production ou placés dans une file séparée.

Étape 3 : réduire le contexte

Identifier les instructions répétées, les historiques trop longs, les champs inutiles et les résultats d’outils obsolètes. Conserver les données d’audit en dehors du contexte transmis au modèle.

Étape 4 : contrôler les reprises

Classer les erreurs, appliquer une politique de nouvelles tentatives limitée et surveiller le nombre total d’appels par requête.

Étape 5 : activer le cache

Commencer par des résultats déterministes et non sensibles, puis ajouter les contraintes de version, de permission et de fraîcheur avant d’élargir le périmètre.

Étape 6 : tester le routage

Utiliser Switchyard en mode d’observation ou sur un trafic séparé, comparer les décisions à un jeu de validation et vérifier les erreurs de classement avant de rendre la politique obligatoire.

Étape 7 : appliquer les budgets

Configurer les alertes, les limites et les replis dans l’AI Gateway, puis tester les scénarios de dépassement, de panne fournisseur et de boucle d’agent.

Étape 8 : réévaluer régulièrement

Une modification de modèle, de tarif, de cache ou de fenêtre de contexte doit déclencher une nouvelle comparaison. Les chiffres historiques ne doivent pas être reconduits automatiquement.

Checklist de mise en production

[ ] Chaque appel possède un projet, un environnement et un identifiant de requête métier.
[ ] Les jetons d’entrée et de sortie sont enregistrés séparément.
[ ] Le modèle réellement utilisé est distingué du modèle demandé.
[ ] Le nombre total d’appels par requête est visible.
[ ] Les erreurs sont classées avant la définition des reprises.
[ ] Les clés de cache intègrent le modèle, le prompt, les droits et la fraîcheur.
[ ] Les sorties économiques passent par un jeu de validation.
[ ] Les règles d’escalade sont testées sur des cas ambigus.
[ ] Les budgets sont appliqués par projet ou équipe, et pas seulement au niveau de l’organisation.
[ ] Les changements de tarifs et de politiques de cache déclenchent une nouvelle estimation.
[ ] Un trafic de test séparé permet de vérifier Switchyard sans perturber la production.
[ ] Les journaux peuvent être rapprochés de la facturation et des résultats métier.

Questions fréquentes

Pourquoi la facture d’API LLM augmente-t-elle alors que le trafic reste stable ?

Une facture peut progresser sans hausse du nombre de requêtes si chaque appel transporte davantage de contexte, si un agent répète une étape après une erreur ou si un modèle plus coûteux est utilisé par défaut. Il faut donc suivre les jetons d’entrée et de sortie, les nouvelles tentatives, les appels par requête métier et la répartition par modèle, plutôt que le seul volume de demandes.

Comment Switchyard choisit-il le modèle adapté à une requête ?

Switchyard peut appliquer un routage fixe, aléatoire, fondé sur un classificateur ou piloté par les signaux d’une session. Dans une stratégie par niveaux, les tâches simples sont dirigées vers une cible plus économique tandis que les erreurs, l’exploration ou les situations ambiguës peuvent déclencher une cible plus capable. Cette décision doit être comparée à un jeu de validation avant toute généralisation.

Comment définir un budget de projet dans un AI Gateway ?

Chaque appel doit être associé à un projet, une équipe, un environnement et un usage métier. Le gateway peut ensuite appliquer des plafonds, des alertes, des limites de débit et une règle de blocage ou de dégradation. Le budget doit être relié à l’identifiant de la requête métier afin de distinguer une consommation légitime d’une boucle d’agent ou d’une intégration mal configurée.

Le cache peut-il réellement diminuer l’utilisation d’une API de modèle ?

Oui, lorsque les requêtes ou les préfixes sont suffisamment répétitifs et que les données peuvent être réutilisées sans risque. Le cache doit toutefois intégrer le modèle, la version du prompt, les droits d’accès et la fraîcheur des données. Un cache partagé entre locataires ou basé sur une clé trop courte peut créer une fuite de données, même si la facture diminue.

Comment préserver la qualité après une dégradation vers un modèle moins coûteux ?

La dégradation doit être limitée aux tâches dont le niveau de qualité est mesuré. Il faut créer un jeu de validation représentatif, définir des critères d’escalade et vérifier les sorties structurées, les erreurs fonctionnelles et les refus inappropriés. Le modèle économique ne doit pas remplacer automatiquement le modèle avancé ; il doit prendre en charge uniquement les cas qui passent les contrôles prévus.

Pour les questions d’exploitation, les équipes peuvent également consulter le centre d’aide de nuvcloud afin de préparer un environnement isolé de test, de rejeu et de validation.

La documentation officielle de Switchyard reste la référence pour les paramètres de routage, les formats pris en charge et les limites d’intégration. Les équipes doivent notamment vérifier les versions utilisées, les options de repli et les statistiques exposées par le proxy. Dépôt officiel et documentation de Switchyard

Pour les projets qui doivent comparer plusieurs configurations d’agents, de modèles ou de flux de travail, une machine Mac distante peut servir d’environnement temporaire de rejeu sans modifier immédiatement la production. Les contraintes d’accès, de sécurité et de durée doivent toutefois être vérifiées dans les informations de présentation de nuvcloud.

Le choix entre l’environnement actuel et une infrastructure Mac dédiée dépend du besoin. Une machine locale déjà occupée crée souvent des conflits de dépendances, une capacité difficile à réserver et une séparation imparfaite entre expérimentation et production. Une instance cloud généraliste peut ajouter des limites de réseau, de contrôle des secrets ou de disponibilité pour les tests interactifs. Pour une campagne courte de rejeu, de validation de routage ou d’intégration d’outils audio, vidéo et design, louer un Mac via nuvcloud peut offrir un environnement isolé plus simple à remettre à zéro, sans transformer un test ponctuel en achat matériel durable. Ce choix ne remplace pas une infrastructure stable pour une charge continue ni une architecture conforme aux exigences de production ; il convient surtout lorsque l’équipe doit mesurer avant de généraliser.

FAQ

Pourquoi la facture d’API LLM augmente-t-elle alors que le trafic reste stable ?

Comment Switchyard choisit-il le modèle adapté à une requête ?

Comment définir un budget de projet dans un AI Gateway ?

Le cache peut-il réellement diminuer l’utilisation d’une API de modèle ?

Comment préserver la qualité après une dégradation vers un modèle moins coûteux ?

La dégradation doit être limitée aux tâches dont le niveau de qualité est mesuré. Il faut créer un jeu de validation représentatif, définir des critères d’escalade et vérifier les sorties structurées, les erreurs fonctionnelles et les refus inappropriés. Le modèle économique ne doit pas remplacer automatiquement le modèle avancé : il doit prendre en charge uniquement les cas qui passent les contrôles prévus.