À la mi-2026, l’erreur d’architecture que nous observons le plus souvent en production consiste à payer trop cher l’inférence. Les équipes déploient des fonctionnalités LLM, constatent qu’elles fonctionnent, puis reçoivent des factures mensuelles à cinq chiffres qui augmentent avec l’utilisation. Certaines fonctionnalités deviennent déficitaires. Certaines entreprises en suppriment alors qu’une meilleure discipline des coûts les aurait rendues viables.
La plupart des factures LLM sont nettement plus élevées que nécessaire. Les économies ne proviennent pas d’une technique miracle, mais d’un ensemble d’optimisations dont chacune produit à elle seule un gain modeste.
Cet article présente les techniques, les chiffres et la discipline nécessaires en production. Nous supposons que vous appliquez déjà un routage élémentaire des modèles (abordé dans un autre article) et allons ici plus loin.
La pile des coûts
Les coûts LLM proviennent de :
- Jetons d’entrée. Ce que vous envoyez au modèle : prompt système, contexte et requête utilisateur.
- Jetons de sortie. Ce que renvoie le modèle. Ils coûtent généralement 4 à 6 fois plus cher que les jetons d’entrée (5 fois chez Anthropic et environ 6 fois chez OpenAI selon les tarifs publics actuels — voir la référence des modèles et des tarifs, vérifiée le 7 juillet 2026).
- Jetons de raisonnement. Pour les modèles de raisonnement, il s’agit des jetons internes de “réflexion”. Ils coûtent souvent aussi cher que les jetons de sortie.
- Appels d’outils. Si vous utilisez des appels d’outils, chaque définition d’outil consomme des jetons d’entrée.
- Réessais. Les appels échoués coûtent quand même.
L’optimisation fonctionne à chaque couche.
Technique 1 : Mise en cache des prompts
Il s’agit du levier le plus important. La plupart des fournisseurs modernes mettent en cache les préfixes d’entrée répétés : vous payez le plein tarif la première fois, puis beaucoup moins pour les appels suivants qui utilisent le même préfixe.
Tarification habituelle :
- Anthropic : entrée mise en cache ~10 % du coût normal.
- OpenAI : mise en cache automatique lorsque les préfixes correspondent, environ 50 % du coût normal (selon le modèle).
- Google : contenu mis en cache explicitement, tarif variable.
Fonctionnement : le premier appel à un modèle avec un préfixe d’entrée donné est facturé au tarif normal. Les appels suivants effectués pendant la fenêtre de mise en cache (généralement 5 à 60 minutes selon le fournisseur) réutilisent la représentation mise en cache.
Implémentation pratique :
Structurez vos prompts de sorte que le contenu statique vienne en premier, le contenu dynamique en dernier :
[CACHED: 10K tokens]
- System prompt
- Tool descriptions
- User's static profile
- Knowledge base snippets unlikely to change per call
[NOT CACHED: 1K tokens]
- Conversation history (changes each turn)
- Current user query
Les 10K premiers jetons sont mis en cache après le premier appel. Les appels suivants n’en paient qu’environ 10 %, tandis que les 1K restants sont facturés au plein tarif.
Exemple d’économies :
Sans mise en cache :
- 11K jetons d’entrée × 3 €/million = 0,033 € par appel.
- 100K appels par jour = 3 300 € par jour.
Avec mise en cache (90 % de l’entrée mise en cache) :
- 1K au prix complet + 10K mis en cache à 10 % :
- 1K × 3 €/million + 10K × 0,30 €/million = 0,003 € + 0,003 € = 0,006 € par appel.
- 100K appels par jour = 600 € par jour.
Économie de 82 %. Des chiffres réels, des systèmes réels.
Discipline d’implémentation :
- Identifiez les parties statiques et dynamiques des prompts.
- Placez les parties statiques en premier.
- Utilisez des marqueurs de mise en cache lorsque le fournisseur les prend en charge (Anthropic) afin de disposer d’un contrôle explicite.
- Testez les accès réussis au cache : votre observabilité doit en afficher le taux. S’il est faible, la structure de vos prompts n’est pas adaptée.
C’est l’optimisation qui offre le meilleur retour sur investissement. Mettez-la en œuvre avant toute autre.
Technique 2 : Routage des modèles
Ce sujet est abordé en détail ailleurs. En bref : envoyez les requêtes à différents modèles selon leur complexité.
- 60 % des requêtes vers de petits modèles.
- 30 % vers des modèles intermédiaires.
- 10 % vers des modèles de premier plan.
Économies habituelles : 60 à 80 % par rapport à l’utilisation systématique du modèle phare.
Combiné à la mise en cache, ce routage permet d’économiser plus de 90 % par rapport à une référence naïve.
Technique 3 : Contrôle de la longueur de la sortie
Les jetons de sortie constituent le principal poste de coût dans la plupart des cas d’utilisation. Ils coûtent généralement 4 à 6 fois plus cher que les jetons d’entrée, dépendent du modèle et du prompt, et sont souvent plus nombreux que nécessaire.
Stratégies :
Instructions explicites de longueur.
Respond in at most 100 words.
Les modèles respectent assez bien ce type de consigne, ce qui réduit sensiblement les coûts de sortie.
Sortie structurée.
Lorsque la réponse visible par l’utilisateur se limite à de brèves données structurées (un JSON comportant des champs précis), la sortie est bornée. Elle ne risque pas de devenir inutilement verbeuse.
Paramètre max_tokens.
Définissez-le. Ne conservez pas la valeur par défaut. Si 200 jetons suffisent, fixez le maximum à 250 afin de garder une petite marge. Le modèle ne pourra pas la dépasser.
Contraintes de format.
“Uniquement des puces” ou “un seul paragraphe” produit des sorties plus courtes qu’un format libre.
Points plutôt que prose.
Les puces utilisent généralement deux fois moins de jetons qu’un texte suivi qui transmet la même information.
Pas de préambule.
“Omettez les phrases introductives. Allez directement à la réponse.” Les modèles commencent souvent par “Très bonne question…” ou “Je vais vous expliquer…” : autant de jetons gaspillés.
Exemple d’économies :
Prenons un processus de résumé. Sortie par défaut : 500 jetons. Sortie contrainte : 200 jetons.
- 500 jetons × 10 €/million = 0,005 € par appel.
- 200 jetons × 10 €/million = 0,002 € par appel.
L’économie sur la sortie atteint 60 %. C’est moins spectaculaire que les 90 % permis par la mise en cache, mais cela concerne le principal poste de coût.
Technique 4 : Échantillonnage de sortie et arrêt précoce
Pour certains cas d’utilisation, vous n’avez pas besoin de la sortie complète du LLM — vous avez besoin d’une décision ou d’une classification.
Logprobs pour la classification.
# Use a small NON-reasoning model here: reasoning-family models
# (GPT-5.x thinking tiers and similar) reject logprobs/logit_bias.
response = openai.chat.completions.create(
model=SMALL_NON_REASONING_MODEL,
messages=[{"role": "user", "content": prompt}],
logprobs=True,
top_logprobs=5,
max_tokens=1
)
# Read logprobs of first token to determine likely category
Vous demandez au modèle d’émettre un seul jeton (la catégorie). Le coût correspond à un passage en entrée et à un jeton en sortie. C’est plus rapide, moins cher et souvent aussi efficace qu’une réponse plus longue.
Biais des logits.
Pour les sorties connues, biaisez les logits vers les options valides.
import tiktoken
enc = tiktoken.encoding_for_model("gpt-4o-mini")
# logit_bias keys are token IDs (as strings), not words.
bias = {str(enc.encode(w)[0]): 100 for w in (" yes", " no", " maybe")}
response = openai.chat.completions.create(
model="gpt-4o-mini",
messages=[...],
logit_bias=bias,
max_tokens=1,
)
Cette technique incite le modèle à produire le bon type de sortie. Elle est peu coûteuse et fiable pour la classification.
Technique 5 : Traitement par lots
Lorsque vous traitez de nombreux éléments, regroupez-les.
Traitement asynchrone par lots au niveau de l’API.
La plupart des fournisseurs proposent des API asynchrones ou par lots qui traitent plusieurs requêtes à moindre coût.
- OpenAI Batch API : 50 % de réduction, SLA de 24 heures.
- Anthropic Message Batches : 50 % de réduction, SLA de 24 heures.
Si vous disposez d’un arriéré de tâches qui n’exigent pas de réponse en temps réel, traitez-les par lots. Le coût est divisé par deux.
Regroupement dans un même prompt.
Traitez plusieurs éléments en un seul appel LLM lorsque cela est possible.
Au lieu de :
[10 separate calls, each classifying one ticket]
Faites :
[1 call, classifying 10 tickets in one prompt]
L’appel unique contient davantage de données d’entrée (10 éléments), mais ne supporte qu’une seule fois les coûts fixes (prompt système, descriptions des outils). Le nombre total de jetons est inférieur à celui de 10 appels distincts.
Attention : la qualité peut diminuer si un prompt contient trop d’éléments. Testez le point d’équilibre adapté à votre cas d’utilisation. En général, 5 à 20 éléments par prompt conviennent.
Technique 6 : Modèles plus petits pour des tâches spécifiques
Au-delà du routage standard, demandez-vous si une tâche nécessite réellement un grand modèle.
Classification : un modèle d’entrée de gamme est souvent aussi performant qu’un modèle phare pour une classification simple. Selon les tarifs publics actuels (vérifiés le 7 juillet 2026), Claude Haiku 4.5 à 1 $/5 $ par million contre Claude Opus 4.8 à 5 $/25 $ représente une économie constante d’un facteur 5 ; l’écart entre la gamme légère d’OpenAI et GPT-5.5 est comparable.
Extraction : les modèles intermédiaires fonctionnent pour l’extraction structurée. Réservez le modèle de premier plan aux cas qui échouent.
Traduction : les modèles spécialisés de traduction ou les petits LLM gèrent la plupart des cas.
Embeddings : utilisez des modèles spécialisés dans les embeddings, et non des LLM généralistes.
Le principe : identifiez vos charges de travail “simples et ciblées”. Acheminez-les vers le plus petit modèle qui accomplit correctement la tâche. Réservez le modèle phare aux travaux complexes qui exigent du discernement.
Technique 7 : Petits modèles affinés
Pour des tâches ciblées à très fort volume, affinez un petit modèle.
Exemple : 100K demandes de classification par jour.
- GPT-5 non modifié : 30 €/jour en coûts API.
- Modèle 8B affiné sur une infrastructure d’inférence dédiée : 5 à 10 €/jour d’inférence, auxquels s’ajoute un coût d’affinage ponctuel.
À un volume suffisant, les petits modèles affinés sont rapidement rentabilisés. Le calcul dépend de votre volume.
Nous avons abordé ce sujet dans l’article sur l’affinage. Le principe : lorsque volume et spécialisation sont réunis, l’affinage devient un levier de réduction des coûts.
Technique 8 : Pré-filtrage
Dans les processus LLM à plusieurs étapes, un filtre peu coûteux intercepte les cas évidents avant le traitement onéreux.
Exemple : classification et réponse de l’assistance client.
Préfiltrage peu coûteux :
- “S’agit-il d’une véritable question adressée à l’assistance, ou de spam/bruit ?” (classification en un jeton sur un petit modèle.)
- “S’agit-il d’une FAQ connue ?” (recherche par embeddings, peu coûteuse.)
Seules les demandes passant le filtre atteignent la génération de réponse coûteuse.
Économies : si 30 % des demandes entrantes sont du bruit ou peuvent être traitées par une FAQ, vous éliminez 30 % des appels coûteux.
Le préfiltrage coûte peu (0,0001 € par appel) par rapport à la génération de la réponse (0,05 € par appel). Le retour sur investissement est immédiat.
Technique 9 : Mise en cache au-delà des prompts
Au-delà de la mise en cache des prompts proposée par le fournisseur, utilisez une mise en cache au niveau de l’application :
Mise en cache des réponses. Même requête, même contexte, même réponse. Mettez en cache et renvoyez sans appeler le modèle.
def cached_call(prompt, model, ttl=3600):
cache_key = hash(prompt + model)
cached = redis.get(cache_key)
if cached:
return cached
response = call_llm(prompt, model)
redis.set(cache_key, response, ttl=ttl)
return response
Pour les requêtes idempotentes, cette méthode élimine entièrement les appels en double.
Mise en cache des embeddings. Les embeddings calculés sont mis en cache.
Mise en cache des résultats de récupération. Les résultats de recherche associés à une requête sont mis en cache pendant une courte période.
Mise en cache des résultats des outils. Les résultats des appels d’outils sont mis en cache si les données sous-jacentes changent rarement.
Les niveaux de mise en cache se cumulent. Chacun permet d’éviter des appels.
Technique 10 : Exécution spéculative
Dans les processus sensibles à la latence où vous pouvez prévoir les étapes suivantes, lancez des appels anticipés de manière spéculative.
Exemple : un agent d’assistance client. Vous savez qu’après la description du problème par le client, l’étape suivante consiste généralement à le résumer. Lancez ce résumé en parallèle de l’affichage d’un accusé de réception à l’utilisateur.
Si la prédiction est correcte, la réponse est prête quand elle est nécessaire. Si elle est incorrecte, vous avez gaspillé un appel.
Cette technique optimise davantage la latence que le coût, mais améliore nettement l’expérience utilisateur dans certains processus.
Technique 11 : Arbitrage des fournisseurs
Les fournisseurs appliquent des tarifs différents à des modèles comparables. Profitez-en.
Modèles open source sur des fournisseurs d’inférence peu coûteux.
Llama 3.3 70B sur Together AI : 0,88 $/million de jetons d’entrée comme de sortie (tarif public vérifié le 7 juillet 2026). Le modèle fermé concurrent, Claude Sonnet 5 : 3 $/million en entrée et 15 $/million en sortie (tarif de lancement de 2 $/10 $ jusqu’au 31 août 2026).
Pour les tâches auxquelles un modèle ouvert 70B suffit, l’écart est d’environ 3,4 fois en entrée et 17 fois en sortie, soit 3 à 17 fois selon la répartition de vos jetons d’entrée et de sortie.
Même modèle sur différents fournisseurs.
Certains modèles open source sont hébergés par plusieurs fournisseurs à des tarifs différents. Comparez-les.
Auto-hébergement à grande échelle.
À un volume suffisant (par exemple, plus de 10 000 € par mois pour un modèle donné), l’autohébergement devient moins coûteux que les appels d’API. Il exige toutefois des capacités opérationnelles.
L’arbitrage entre fournisseurs ajoute de la complexité : routage multifournisseur avec solution de repli et tests de qualité sur la variante de chaque fournisseur. À grande échelle, l’investissement en vaut la peine.
Technique 12 : Accélération de l’inférence
Pour l’auto-hébergement : optimisation de la couche d’inférence elle-même.
vLLM, TGI, SGLang. Serveurs d’inférence optimisés. Débit 2 à 10 fois supérieur à celui des implémentations naïves.
Quantification. Exécutez les modèles avec une précision plus faible (4 bits, 8 bits). Le débit est multiplié par 2 à 4, au prix d’une légère baisse de qualité.
Flash Attention, paged attention. Optimisations architecturales activées dans les serveurs modernes.
Traitement continu par lots. Les serveurs regroupent les requêtes en cours afin de mieux utiliser le GPU.
Pour les équipes auto-hébergées à grande échelle, cela compte. Pour les équipes utilisant des API, le fournisseur s’en charge.
Technique 13 : Streaming
Le streaming ne réduit pas le nombre de jetons, mais améliore l’expérience utilisateur, ce qui influe sur la perception du rapport coût-efficacité.
Pour les sorties longues, les utilisateurs voient le contenu apparaître immédiatement. Ils peuvent lire pendant que la génération se termine. Cela semble beaucoup plus rapide que d’attendre la réponse complète.
Pour les agents, la diffusion des étapes intermédiaires donne aux utilisateurs une visibilité sur la progression.
Mise en œuvre : toutes les API modernes prennent en charge le streaming. Utilisez-le dans les processus destinés aux utilisateurs.
Technique 14 : Garde-fous budgétaires
Au-delà de l’optimisation, imposez des budgets stricts pour éviter les dérapages de coûts.
Budget par appel. Nombre maximal de jetons par appel. Arrêtez l’exécution en cas de dépassement.
Budget par utilisateur. Plafond quotidien ou mensuel par utilisateur. Limitez le débit à l’approche du plafond.
Budget par fonctionnalité. Chaque fonctionnalité a un budget. Arrêt automatique à 10 fois la moyenne quotidienne.
Budget global. Limite quotidienne ou mensuelle totale. À son approche, suspendez les tâches non essentielles.
Ces mesures ne réduisent pas directement les dépenses, mais évitent les catastrophes. Sans garde-fous, un seul défaut ou une seule attaque peut rapidement faire exploser les coûts.
Un exemple concret : une réduction de coût réelle
Une équipe qui exploitait une IA d’assistance client avait une facture de 12 000 € par mois. Six mois après l’application de ces techniques, elle n’était plus que de 1 800 € par mois, soit une réduction de 85 %.
Les changements :
-
Mise en cache des prompts. Restructuration des prompts afin de maximiser le préfixe statique. Environ 70 % des entrées sont désormais mises en cache. Économie : environ 30 %.
-
Routage des modèles. La classification et le triage des tickets sont passés de Claude Sonnet à Claude Haiku. Économie : environ 15 %.
-
Contrôle de la longueur des sorties. Réponses limitées à 250 mots au lieu de 800 à 1 500. Économie : environ 25 %.
-
Préfiltrage. Une classification peu coûteuse intercepte les tickets auxquels une FAQ peut répondre et les sert depuis le cache. Environ 20 % des tickets sont ainsi retirés du processus coûteux. Économie : environ 10 %.
-
Mise en cache des réponses aux FAQ. Les questions identiques reçoivent des réponses mises en cache. Économie : environ 5 %.
Les pourcentages indiqués représentent la part de chaque technique dans la réduction finale : leur somme correspond aux quelque 85 % d’économie globale. Chacun a été mesuré par rapport à la facture restante après le changement précédent ; ce ne sont pas des multiplicateurs indépendants que vous pourriez appliquer à votre propre facture.
Qualité : selon tous les indicateurs mesurés (satisfaction client, exactitude des réponses, taux de résolution), la qualité est restée inchangée ou s’est légèrement améliorée.
Coût opérationnel : environ 80 heures de travail d’ingénierie sur 3 mois. Retour sur investissement : 2 semaines.
Erreurs courantes
Voici quelques erreurs récurrentes :
Erreur 1 : Aucun suivi des coûts. L’équipe n’a aucune visibilité sur ce que chaque fonctionnalité, utilisateur ou appel coûte. L’optimisation est impossible sans mesure.
Erreur 2 : Optimiser le mauvais poste. Passer des semaines à réduire les jetons d’entrée de 5 % alors que les jetons de sortie représentent 80 % de la facture. Mesurez d’abord, puis optimisez les principaux postes.
Erreur 3 : Régressions de qualité. Déployer des réductions de coûts sans surveiller la qualité. L’argent économisé se paie en utilisateurs perdus. Associez toujours les travaux sur les coûts à des suites d’évaluation.
Erreur 4 : Routage excessif. Acheminer agressivement les requêtes vers de petits modèles pour des tâches qu’ils ne maîtrisent pas réellement. Ce sont de fausses économies.
Erreur 5 : Pollution du cache. Remplir le cache de requêtes rares. La plupart de ses entrées ne sont utilisées qu’une fois et les défauts de cache dominent. Une meilleure stratégie de mise en cache est nécessaire.
Erreur 6 : Négliger l’API par lots. Utiliser le temps réel alors qu’un traitement par lots suffirait. Une réduction de moitié était disponible.
Erreur 7 : Suringénierie. Construire des optimisations de coûts complexes pour des fonctionnalités qui ne sont de toute façon pas rentables. La bonne réponse consiste parfois à “supprimer la fonctionnalité”.
Erreur 8 : Aucun garde-fou budgétaire. Un seul défaut provoque un dérapage. Le résultat est une catastrophe plutôt qu’un désagrément mineur.
La partie culturelle
La discipline des coûts est partiellement culturelle. Les équipes qui réussissent :
- Traiter le coût comme un indicateur, et non comme une considération ajoutée a posteriori.
- Avoir quelqu’un qui en est responsable (souvent quelqu’un à l’interface ingénierie/finances).
- Examiner les coûts dans les indicateurs hebdomadaires.
- Analyser immédiatement les pics.
- Définir des budgets par fonctionnalité ; alerter sur les dépassements de seuil.
- Arbitrer explicitement entre coût, qualité et latence.
Les équipes qui ne le font pas :
- Traiter le coût comme le problème d’autrui.
- Découvrir la facture à la fin du mois.
- Réagir aux pics après coup.
- N’avoir aucune notion de budget.
- Éviter la discussion sur les arbitrages et optimiser une seule dimension à la fois.
Le changement culturel est plus difficile que le changement technique. Mais c’est lui qui ancre durablement les évolutions techniques.
Trajectoire des prix
Une note sur la tendance plus large.
Le coût par unité de capacité diminue fortement d’une année sur l’autre, principalement parce que les petits modèles atteignent les performances des modèles phares de la veille, et non parce que les tarifs publics des modèles phares s’effondrent. Traitez tout chiffre relatif au “prix dans un an” comme une hypothèse modélisée et vérifiez de nouveau la référence des modèles et des tarifs avant de le citer.
Cela signifie :
- Certaines optimisations perdent de leur importance avec le temps (le coût absolu diminue de toute façon).
- Certaines charges de travail actuellement non rentables deviendront rentables.
- Construisez pour le long terme : une architecture propre vaut mieux que chaque centime économisé aujourd’hui.
Cela dit, l’optimisation reste importante même lorsque les prix baissent. Les systèmes inefficaces gaspillent de l’argent à tous les niveaux tarifaires. L’avantage concurrentiel revient souvent aux équipes qui mènent des opérations efficaces à moindre coût.
Un plan d’optimisation des coûts sur 90 jours
Pour une équipe partant de “nous avons une fonctionnalité d’IA, les coûts sont plus élevés que prévu” :
Semaines 1-2 : Mesurer.
- Instrumenter les coûts de chaque appel.
- Construire des tableaux de bord par fonctionnalité et par utilisateur.
- Identifier les principaux postes de coût.
Semaines 3-4 : Gains rapides.
- Activer la mise en cache des prompts lorsqu’elle est prise en charge.
- Restructurer les 3 principaux prompts afin de maximiser le taux d’accès réussi au cache.
- Définir max_tokens pour tous les appels.
- Implémenter des alertes de budget.
Semaines 5-6 : Routage.
- Identifier les tâches simples actuellement confiées au modèle phare.
- Construire un routeur pour les 3 à 5 points de terminaison les plus sollicités.
- Tester les éventuelles régressions de qualité.
Semaines 7-8 : Sortie et mise en cache.
- Limiter la longueur des sorties qui ne sont pas visibles par l’utilisateur.
- Ajouter un cache de réponses au niveau de l’application pour les requêtes courantes.
- Ajouter des préfiltres aux processus les plus volumineux.
Semaines 9-10 : Avancé.
- Utiliser les API par lots pour les tâches qui ne sont pas en temps réel.
- Évaluer d’autres fournisseurs.
- Mettre en cache les embeddings et les résultats de récupération.
Semaines 11-12 : Renforcement.
- Mettre en place des garde-fous budgétaires pour chaque fonctionnalité.
- Intégrer les tableaux de bord des coûts aux revues régulières de l’équipe.
- Documenter les modèles applicables aux futures fonctionnalités.
Au terme des 90 jours, une réduction des coûts de 50 à 80 % est réaliste. La qualité est surveillée. La discipline est intégrée.
Mesurez d’abord, puis cumulez les économies
Les coûts des LLM peuvent généralement être réduits de 60 à 90 % sans perte de qualité. Les techniques sont bien connues : mise en cache, routage, contrôle des sorties, traitement par lots, préfiltrage, mise en cache des réponses, sélection des modèles et garde-fous budgétaires.
Appliquée isolément, chaque technique produit une économie modeste. Ensemble, elles se cumulent et produisent des économies spectaculaires.
Les équipes qui réussissent transforment les fonctionnalités d’IA déficitaires en fonctionnalités rentables. Les autres finissent par devoir supprimer des fonctionnalités qui auraient pu être viables.
Mesurez d’abord. Optimisez les principaux postes. Maintenez la surveillance de la qualité. Intégrez la discipline des coûts au travail courant de l’équipe.
Le résultat : des fonctionnalités d’IA qui passent à l’échelle sur le plan économique, et pas seulement technique. C’est ce qui fait de l’IA une composante durable d’un produit, plutôt qu’un simple argument de lancement.
