Les workflows IA les plus coûteux gaspillent souvent des tokens avant même que le prix du modèle soit le vrai problème. Voici 12 techniques concrètes pour réduire prompts, retrieval, outils et retries sans sacrifier la qualité.
L’optimisation du coût des LLM est souvent présentée comme un simple problème de prix par million de tokens. En pratique, beaucoup de workflows agentiques deviennent coûteux bien avant que le tarif du modèle soit le principal problème : prompts surdimensionnés, contexte répété, catalogue complet d’outils chargé à chaque tour, retrieval excessif, résultats d’outils trop volumineux, retries non bornés et réponses plus longues que nécessaire.
La bonne question n’est donc pas seulement « quel modèle coûte le moins cher ? », mais : quels tokens sont réellement nécessaires pour accomplir la tâche au niveau de qualité attendu ?
Voici douze techniques concrètes pour réduire la consommation de tokens des LLM et des agents IA sans réduire aveuglément le contexte ni dégrader les résultats.
D’où vient la consommation de tokens d’un agent IA ?
Un workflow multi-étapes peut consommer des tokens à plusieurs endroits :
instructions système et développeur ;
historique de conversation ;
définitions et schémas des outils ;
documents ou métadonnées récupérés par retrieval ;
résultats d’outils renvoyés au modèle ;
raisonnement et sortie générée ;
retries, boucles de correction et sous-agents.
C’est pourquoi une métrique « tokens par requête » prise seule peut être trompeuse. Deux runs peuvent résoudre la même question métier tout en suivant des chemins d’exécution très différents.
1. Mesurer avant d’optimiser
Commencez par suivre les tokens d’entrée, les tokens mis en cache, les tokens de sortie, les appels modèle et le coût au niveau du run. Pour un agent, ajoutez le nombre d’étapes, d’appels d’outils, de retries et de sous-agents.
L’objectif est d’identifier si le coût vient d’un prompt fixe trop long, de l’historique, du retrieval, d’une boucle, d’un modèle surdimensionné ou d’une sortie trop verbeuse.
C’est précisément là que l’observabilité des agents IA devient opérationnelle. thaink² AgentOps affiche consommation de tokens, coûts estimés et appels modèle dans le contexte des runs, afin de relier coût, comportement et qualité.
2. Stabiliser les préfixes de prompt réutilisables
Le prompt caching peut réutiliser le traitement lorsque plusieurs requêtes partagent le même préfixe. Les instructions stables, définitions d’outils et références communes doivent donc rester aussi constantes que possible.
Évitez d’injecter un timestamp, un identifiant aléatoire ou des données changeantes au début d’un long contexte autrement stable : une modification précoce peut réduire la réutilisation du cache.
3. Ne pas charger tous les outils à chaque requête
Un gros catalogue d’outils peut consommer beaucoup de contexte avant même que l’agent commence son travail.
Lorsque la stack le permet, chargez les définitions détaillées uniquement au moment où elles deviennent utiles. OpenAI Tool Search, par exemple, permet de différer le chargement des outils plutôt que d’envoyer tous leurs schémas dès le départ.
4. Récupérer moins de contexte, mais mieux
Un système RAG gaspille facilement des tokens en envoyant trop de chunks « au cas où ». Plus de contexte ne signifie pas automatiquement plus de fiabilité.
Travaillez d’abord la qualité du retrieval : métadonnées, recherche hybride, reranking, déduplication et décomposition de requête permettent souvent d’utiliser moins de passages sans perdre les preuves nécessaires.
5. Ne pas envoyer tout le schéma SQL au modèle
Les systèmes Text-to-SQL sont un exemple classique de contexte inutilement volumineux. Envoyer des milliers de tables, colonnes et descriptions est coûteux et peut diminuer la précision.
Utilisez du schema linking ou du schema retrieval afin d’identifier les tables, colonnes, relations et définitions métier pertinentes avant la génération SQL.
Notre guide Text-to-SQL avec LLM détaille cette architecture.
6. Réduire les résultats d’outils avant de les réinjecter
Une requête SQL peut renvoyer des milliers de lignes ; une recherche de logs, des centaines d’événements ; une API, un payload JSON massif. Le modèle n’a généralement pas besoin de tout recevoir mot pour mot.
Filtrez, agrégez ou réduisez de manière déterministe avant de réinjecter le résultat dans le contexte. Conservez hors prompt un identifiant vers la donnée complète lorsque l’auditabilité est nécessaire.
7. Stocker l’état du workflow comme des données structurées
Un agent relit souvent de longues conversations simplement parce que le système ne possède aucune représentation compacte des décisions déjà prises.
Conservez filtres, entités sélectionnées, étapes terminées, validations, résultats d’outils et statut d’exécution dans un état structuré. Le modèle reçoit alors les éléments utiles au lieu de relire un récit complet.
8. Borner les retries et les boucles de correction
Un workflow qui répète silencieusement la même requête ou le même tool call peut multiplier la consommation sans améliorer le résultat.
Fixez un nombre maximal de tentatives, classez les erreurs et imposez une stratégie différente avant un nouvel appel modèle.
9. Router les tâches simples et complexes différemment
Réduire les tokens et réduire le coût ne sont pas exactement la même chose. Un modèle moins cher peut consommer autant de tokens, tandis qu’un modèle plus puissant peut parfois éviter plusieurs retries.
Routez selon la complexité, le niveau de confiance ou l’étape du workflow. Les opérations déterministes doivent rester déterministes ; une classification simple ne nécessite pas forcément le même modèle qu’une analyse complexe.
10. Limiter la longueur de sortie au besoin réel
Si l’agent doit produire une catégorie, une requête SQL, un objet JSON ou un résumé opérationnel de cinq lignes, ne lui demandez pas un essai.
Les sorties structurées et les contrats de réponse explicites réduisent les tokens de sortie inutiles et facilitent le traitement aval.
11. Référencer les gros contenus plutôt que les répéter
Lorsqu’un document, une politique ou un résultat existe déjà dans un système de retrieval ou un stockage durable, récupérez seulement la section nécessaire. Réinjecter le document complet à chaque tour est rarement justifié.
12. Optimiser le coût par tâche réussie, pas le nombre de tokens seul
La chasse au token peut créer une fausse économie. Retirer trop de contexte peut augmenter hallucinations, retries ou reprise humaine.
La métrique utile se rapproche davantage du coût par tâche réussie et acceptable. Comparez consommation, qualité, taux de complétion, latence et travail humain résiduel.
Checklist d’optimisation des tokens
Source de gaspillage | Première action |
|---|---|
Instructions stables répétées | Préserver un préfixe cacheable |
Catalogue d’outils énorme | Charger les outils à la demande |
Trop de chunks RAG | Améliorer retrieval et reranking |
Schéma SQL complet | Faire du schema retrieval |
Résultats d’outils volumineux | Filtrer ou agréger avant réinjection |
Historique trop long | Persister un état structuré |
Échecs répétés | Borner les retries |
Modèle surdimensionné | Introduire du model routing |
Sortie trop longue | Définir un contrat de réponse |
Coût sans contexte | Relier usage et qualité |
Comment thaink² aide à comprendre où partent les tokens
L’optimisation devient difficile lorsque l’usage est séparé du workflow qui l’a produit. thaink² AgentOps place consommation de tokens, coûts estimés et appels modèle à côté des runs, logs, événements et signaux d’évaluation.
La question n’est alors plus simplement « combien a coûté le modèle ? », mais : quel agent, quelle mission et quel chemin d’exécution ont consommé ces ressources, et la qualité obtenue justifiait-elle le coût ?
Découvrez la page AI Agent Observability pour voir comment la visibilité usage/coût s’intègre à AgentOps.
Faq
Comment réduire la consommation de tokens d’un LLM ?
Réduisez le contexte inutile, récupérez seulement les preuves pertinentes, différez les outils inutilisés, compressez les résultats, persistez un état structuré et bornez les retries.
Le prompt caching réduit-il le nombre de tokens ?
Il ne réduit pas nécessairement le nombre logique de tokens, mais peut réduire coût et latence des préfixes réutilisés.
Le RAG réduit-il les coûts ?
Oui lorsqu’il remplace un gros contexte statique par un petit ensemble de preuves pertinentes ; un mauvais retrieval peut faire l’inverse.
Faut-il toujours utiliser le modèle le moins cher ?
Non. Il faut optimiser le coût par tâche réussie en tenant compte des retries et du travail humain.
Que suivre pour le coût d’un agent IA ?
Tokens d’entrée, cache, sortie, appels modèle, retries et coût du run, à relier à la qualité et au comportement.
