Réduire le coût d'un agent sans le dégrader
Quand une facture de tokens surprend, le réflexe est de passer partout à un modèle bon marché en acceptant la perte de qualité. C'est rarement nécessaire. Dans les systèmes que nous avons audités, l'essentiel de la dépense venait de contexte qui n'avait pas à être là et d'étapes qui n'avaient pas besoin du modèle cher.
La méthode ci-dessous est ennuyeuse et efficace : mesurer d'abord, appliquer quatre changements par ordre de rendement, puis décider s'il reste un problème. La plupart des équipes s'arrêtent après le deuxième.
Mesurez par exécution avant tout changement#
La dépense mensuelle agrégée n'apprend rien d'actionnable. Consignez par exécution : tokens d'entrée et de sortie, nombre d'appels, modèle par appel et type de tâche. Regardez ensuite le coût par tâche terminée, par type. Presque toujours, un ou deux types dominent, et dans ceux-ci une étape. Optimiser ailleurs, c'est dépenser de l'effort là où l'argent n'est pas.
Comptez aussi les exécutions échouées au dénominateur. Une boucle de reprises qui brûle trois tentatives est un problème de coût déguisé en problème de qualité.
Les quatre changements, par rendement#
| Changement | Économie typique | Risque |
|---|---|---|
| Élaguer le contexte : jeter les documents utilisés, compresser l'historique | 20–40 % | Faible si l'objectif reste épinglé |
| Router les étapes bon marché vers un modèle plus petit | 20–40 % | Faible, avec évaluation par étape |
| Mettre en cache le préfixe stable | 10–30 % sur trafic répétitif | Faible |
| Réduire les étapes : meilleurs outils, moins de reprises | 10–25 % | Moyen : travail d'outillage |
La facture, c'est le contexte#
Chaque tour renvoie le contexte accumulé : une exécution de huit étapes peut payer huit fois le même document. Trois habitudes règlent l'essentiel : jeter les passages récupérés quand leur étape est finie ; compresser les anciens tours en notes factuelles ; réduire les résultats d'outil aux champs utilisés. Aucune ne diminue la capacité : elles retirent du texte que le modèle n'utilisait pas.
Routez par étape, pas par goût#
Extraction, classification et mise en forme ont rarement besoin de votre modèle le plus fort ; la planification et la prose destinée à l'utilisateur, souvent oui. Descendez le premier groupe d'un cran, lancez le jeu d'évaluation et gardez le changement seulement si les chiffres tiennent. C'est ce découpage qui permet de retirer un tiers de la facture sans que personne ne voie de différence.
- Commencez par l'étape à plus fort volume et moindre jugement.
- Changez une étape à la fois et rejouez l'évaluation.
- Consignez quel modèle a produit chaque décision.
- Fixez un plafond de dépense par exécution.
Ce qu'il ne faut pas faire#
Ne coupez pas la recherche qui ancre vos réponses : une hallucination coûte bien plus que des tokens quand quelqu'un doit la corriger. Ne supprimez pas la passe critique devant les actions irréversibles pour économiser un appel. Et ne poursuivez pas de micro-optimisations de formulation : le gain est du bruit à côté de l'élagage du contexte.
Questions fréquentes
Le cache vaut-il la peine ?
Si vos exécutions partagent un long préfixe stable — consignes système, définitions d'outils, texte de politique — oui, et c'est l'un des gains les moins chers. Structurez le prompt avec le stable devant.
Faut-il affiner pour économiser ?
Seulement pour une étape à fort volume, étroite et stable où un petit modèle affiné égale un grand. L'affinage ajoute une obligation de maintenance ; à faible volume, routage et élagage gagnent.
Comment éviter une exécution ruineuse ?
Plafonds d'étapes et de dépense, détection des appels identiques répétés et arrêt avec résultat partiel. Alertez sur les exécutions au plafond : c'est souvent un bug.
coût des agents iaoptimisation des coûts llmréduire le coût des tokenscache de promptroutage de modèles
