Un prototype d’agent bien conçu peut coûter 0,02 $ par tâche. Passez à 10 000 tâches par jour, ajoutez les nouvelles tentatives, le raisonnement en plusieurs étapes et quelques boucles d’appels d’outils, et vous vous retrouvez soudain face à une facture API mensuelle à cinq chiffres. Les coûts LLM en production sont maîtrisables, mais uniquement si vous les intégrez dans votre conception dès le départ.
Voici ce qui génère réellement les coûts et ce que nous faisons pour y remédier.
Comprendre les facteurs de coûts
Avant d’optimiser, vous devez savoir où va l’argent.
Volume de tokens
C’est le facteur évident. Chaque token en entrée et en sortie coûte de l’argent. Mais les véritables gouffres à tokens ne sont pas les entrées utilisateur — ce sont les prompts système, les fenêtres de contexte remplies de documents récupérés et les chaînes de raisonnement multi-tours où l’agent réfléchit à des décisions complexes. Une seule tâche d’agent nécessitant cinq étapes de raisonnement avec un prompt système de 4 000 tokens peut facilement consommer plus de 30 000 tokens.
Choix du modèle
La différence de prix entre les modèles est considérable. Les modèles de classe GPT-4 peuvent être 30 à 60 fois plus chers par token que les modèles plus légers comme GPT-4o-mini ou Claude Haiku. Si chaque tâche de votre pipeline sollicite le modèle le plus performant, vos coûts le refléteront.
Nouvelles tentatives et boucles d’erreur
Les agents échouent. Les appels d’outils renvoient des erreurs, les sorties échouent à la validation et l’agent réessaie. Chaque nouvelle tentative est un cycle complet supplémentaire de consommation de tokens. Une boucle d’erreur mal gérée où l’agent réessaie cinq fois la même action défaillante ne gaspille pas seulement du temps — elle gaspille de l’argent.
Stratégies qui fonctionnent réellement
Routage de modèles
C’est l’optimisation à plus fort levier. Toutes les tâches ne nécessitent pas le modèle le plus performant. Un système qui classifie les demandes entrantes, extrait des données structurées de formulaires propres ou génère des résumés simples peut fonctionner sur un modèle plus petit et moins cher sans perte de qualité significative.
Nous implémentons le routage de modèles au niveau de la tâche. Un classificateur léger (lui-même fonctionnant sur un modèle économique) évalue la tâche entrante et la dirige vers le niveau de modèle approprié. Les tâches d’extraction simples vont au modèle rapide. Le raisonnement complexe, les entrées ambiguës ou les décisions à fort enjeu vont au modèle performant. En pratique, 60 à 70 % des tâches dans un flux de travail d’entreprise typique peuvent être traitées par le niveau le moins cher.
L’élément clé : ne routez pas seulement sur le type de tâche — routez sur la difficulté de la tâche. Le même type de tâche peut être facile ou difficile selon l’entrée. Une facture avec des champs propres et structurés est un travail pour le modèle économique. Une facture scannée en PDF avec des notes manuscrites nécessite le modèle puissant.
Cache sémantique
Si votre agent traite des entrées similaires de manière répétée — et dans les flux de travail d’entreprise, c’est souvent le cas — la mise en cache permet des économies significatives. Nous mettons en cache au niveau sémantique, pas seulement en correspondance exacte. Lorsqu’une nouvelle entrée est suffisamment similaire à une entrée précédemment traitée (mesurée par la distance d’embedding), nous renvoyons le résultat en cache au lieu de faire un nouvel appel LLM.
Cela fonctionne exceptionnellement bien pour les tâches de classification, les requêtes de type FAQ et tout flux de travail où les entrées se regroupent autour de schémas communs. Nous avons observé des taux de cache de 30 à 40 % sur la classification de tickets de support, ce qui se traduit directement par une réduction de 30 à 40 % des coûts pour ce composant.
Optimisation des prompts
Des prompts plus courts coûtent moins cher. Mais il ne s’agit pas d’être laconique — il s’agit d’être efficace. Les gains courants :
- Supprimez les exemples superflus des prompts few-shot une fois que le modèle gère la tâche de manière fiable avec moins d’exemples
- Déplacez le contexte statique dans les prompts système où il est mis en cache par les fournisseurs qui prennent en charge le prompt caching
- Utilisez des formats de sortie structurés (schémas JSON) au lieu de longues instructions en langage naturel sur le format de sortie
- Supprimez les instructions redondantes qui se sont accumulées pendant le développement et n’ont jamais été nettoyées
Nous révisons et épurons les prompts chaque trimestre. Ce n’est pas un travail glamour, mais une réduction de 20 % des tokens de prompt sur l’ensemble des agents s’accumule rapidement à grande échelle.
Traitement par lots
Certaines tâches d’agents ne nécessitent pas de réponses en temps réel. Pour celles-ci, regrouper plusieurs éléments en un seul appel LLM réduit les coûts par élément. Au lieu de traiter dix factures en dix appels séparés, vous les traitez en un seul appel contenant dix éléments. Vous payez les tokens de toute façon, mais vous réduisez la surcharge par appel et pouvez souvent utiliser des structures de prompts plus efficaces.
Le traitement par lots fonctionne mieux pour les tâches homogènes — dix éléments du même type, traités de la même manière. Il fonctionne mal lorsque les éléments nécessitent un raisonnement individualisé ou lorsque l’échec d’un élément ne doit pas bloquer les autres.
Budgets de coûts par agent
Chaque agent dans nos systèmes dispose d’un budget de coûts : une dépense maximale par tâche et par période. Si un agent dépasse son budget par tâche — généralement parce qu’il est bloqué dans une boucle de nouvelles tentatives ou une chaîne de raisonnement qui ne converge pas — il s’arrête, journalise le problème et escalade. Cela empêche les coûts incontrôlés provenant d’une seule tâche défaillante.
Nous définissons les budgets sur la base des distributions de coûts observées pendant la période pilote. Le budget est généralement fixé à 3 fois le coût médian par tâche, ce qui détecte les véritables anomalies sans se déclencher sur la variance normale.
Assembler le tout
Aucune stratégie isolée ne résout le problème des coûts. C’est la combinaison qui compte. Un système qui achemine 65 % des tâches vers un modèle économique, met en cache 30 % de celles-ci, utilise des prompts optimisés et dispose de plafonds de coûts stricts dépensera une fraction de ce que coûte une implémentation naïve — tout en délivrant la même qualité.
Le plus important : instrumentez vos coûts dès le premier jour. Suivez les dépenses par agent, par type de tâche, par modèle et par période. Vous ne pouvez pas optimiser ce que vous ne mesurez pas. Nous avons constaté que les équipes qui ajoutent le suivi des coûts après le lancement dépensent systématiquement 3 à 5 fois plus que celles qui l’intègrent dès le départ.
L’alternative open source : coûts fixes versus tarification au token
Il existe un modèle de coûts fondamentalement différent qui mérite d’être considéré : les modèles open source auto-hébergés. Au lieu de payer au token auprès d’un fournisseur d’API, vous exécutez des modèles comme Llama, Mistral ou Qwen sur votre propre infrastructure (ou celle de votre prestataire). La structure de coûts bascule d’une tarification variable au token vers un coût d’infrastructure fixe — du calcul GPU, quel que soit le nombre de tokens que vous traitez.
Cela ne signifie pas automatiquement moins cher. À faible volume, la tarification API l’emporte. Mais à grande échelle, le calcul change. Une fois que l’utilisation de vos GPU est suffisamment élevée, le coût marginal par token descend bien en dessous des tarifs API, et vous cessez de vous soucier des boucles de nouvelles tentatives et des prompts verbeux qui gonflent votre facture.
Il y a un second avantage au-delà du coût : la souveraineté des données. Lorsque vous exécutez des modèles open source sur une infrastructure souveraine, vos données ne quittent jamais votre contrôle. Aucun token envoyé vers des endpoints d’API tiers, aucun accord de traitement de données externes à négocier, aucune ambiguïté sur la destination finale de vos données clients. Pour toute entreprise soucieuse de la résidence des données — que ce soit en raison du RGPD, de la directive NIS2 ou d’une politique interne — cela supprime une catégorie entière de complexité de conformité.
Le compromis est la complexité opérationnelle. Vous gérez l’infrastructure GPU, les mises à jour de modèles et l’optimisation de l’inférence vous-même — ou vous travaillez avec un prestataire qui le fait pour vous. Mais pour les charges de travail de production à fort volume où la prévisibilité des coûts et le contrôle des données comptent, c’est une voie qui mérite d’être évaluée.
L’essentiel
Les coûts LLM sont une contrainte réelle, mais c’est un problème d’ingénierie, pas une barrière fondamentale. Traitez-les comme vous traiteriez n’importe quel autre coût d’infrastructure : mesurez, optimisez, mettez en place des garde-fous et révisez régulièrement.