Coût des LLM : comment réduire votre facture d'API sans perdre en qualité

Le premier prototype d'IA est toujours bon marché. Puis il passe en production, le volume augmente, quelqu'un ajoute une boucle d'agent, et la facture mensuelle devient une ligne sur laquelle la direction financière pose des questions. L'essentiel de cette dépense est évitable, et il est rare de devoir sacrifier la qualité pour la réduire.

Voici la liste que je passe en revue quand un système à base de LLM coûte plus qu'il ne devrait. Rien ici ne dépend d'un fournisseur en particulier. Les prix et les fonctionnalités changent souvent : consultez la page tarifaire actuelle de votre fournisseur pour le détail.

D'où vient vraiment le coût d'un LLM

Vous payez des tokens : ceux que vous envoyez (entrée) et ceux que le modèle renvoie (sortie). Les tokens de sortie coûtent en général plus cher que ceux d'entrée. La facture dépend donc à peu près de :

• combien d'appels vous faites,
• combien de contexte vous envoyez à chaque appel,
• la longueur des réponses,
• et le modèle auquel vous les envoyez.

Chaque technique ci-dessous s'attaque à l'un de ces quatre facteurs.

1. Mesurer le coût par tâche avant d'optimiser

La plupart des équipes connaissent leur total mensuel et rien d'autre. Ça ne suffit pas pour agir. Pour chaque appel, enregistrez : quelle fonctionnalité ou quel processus l'a déclenché, le modèle, les tokens d'entrée et de sortie, et si le résultat a été utilisé.

Calculez ensuite le coût par tâche : par ticket traité, par document lu, par prospect qualifié. On découvre souvent qu'un ou deux processus concentrent l'essentiel de la dépense, et que certains appels produisent des résultats que personne n'utilise. Commencez par là.

2. Choisir le bon modèle pour chaque étape

Le levier le plus important : ne pas envoyer chaque requête au modèle le plus cher. La plupart des pipelines mélangent plusieurs types d'étapes :

• Les étapes faciles : classer un message, extraire des champs d'un formulaire, détecter la langue, aiguiller. Les petits modèles les font bien.
• Les étapes moyennes : rédiger des réponses dans un format connu, résumer un document. Un modèle de taille moyenne suffit en général.
• Les étapes difficiles : raisonnement en plusieurs étapes, cas tordus, écriture de code. C'est là que les plus gros modèles justifient leur prix.

Un simple routeur qui envoie chaque requête au modèle le moins cher capable de la traiter de façon fiable fait souvent nettement baisser la facture. Testez-le sur vos propres données : constituez un petit jeu d'évaluation et vérifiez que les réponses du modèle moins cher restent suffisantes pour cette étape.

3. Utiliser le cache de prompt

Beaucoup de requêtes commencent par le même long préfixe : instructions système, définitions d'outils, document de politique interne, catalogue produits. Plusieurs grands fournisseurs proposent un cache de prompt, qui facture moins cher un préfixe répété qu'une entrée nouvelle.

Pour en profiter, structurez vos prompts avec la partie stable au début et la partie variable (le message de l'utilisateur) à la fin. Ne mettez pas d'horodatage ou d'identifiant de requête en tête du prompt, sinon le préfixe ne correspond jamais.

4. Envoyer moins de contexte

Un long contexte, c'est pratique et c'est cher. Les gaspillages classiques :

• Coller des documents entiers dans le prompt alors que seuls deux paragraphes sont utiles. Récupérez plutôt les passages pertinents (c'est le rôle du RAG ; voir construire un pipeline RAG qui tient en production).
• Renvoyer tout l'historique de la conversation à chaque tour. Résumez les anciens échanges ou ne gardez que l'utile.
• Des sorties d'outils versées brutes dans le contexte. Taillez les logs et les résultats de recherche avant que le modèle ne les voie.

Un contexte plus court est souvent plus juste aussi : les modèles se laissent distraire par le texte hors sujet.

5. Demander moins de sortie

Les tokens de sortie coûtent plus cher, alors demandez exactement ce qu'il vous faut. Si votre code a besoin de trois champs, demandez trois champs en JSON, pas un paragraphe aimable qui les contient. Les sorties structurées réduisent aussi les nouvelles tentatives : quand le modèle renvoie du premier coup des données valides et exploitables, vous ne payez pas un second appel pour corriger le format.

6. Traiter par lots ce qui n'est pas urgent

Tout n'a pas besoin d'une réponse en deux secondes. Rapports nocturnes, réétiquetage d'archives, enrichissement d'un CRM : les grands fournisseurs proposent un traitement par lots à prix réduit, en échange de résultats livrés plus tard. Si un processus peut attendre quelques heures, il n'a probablement pas à tourner au prix du temps réel.

7. Mettre en cache les résultats, pas seulement les prompts

Si beaucoup d'utilisateurs posent la même question, ou si un même document est traité deux fois, conservez la réponse. Un cache simple indexé sur l'entrée normalisée suffit souvent. Le trafic de type FAQ a tendance à se répéter.

8. Plafonner les agents

C'est dans les boucles d'agents que les coûts explosent en silence. Un agent qui relance un appel d'outil en échec, ou qui continue d'« explorer » avec un contexte qui grossit, peut consommer énormément de tokens sur une seule tâche. Fixez des limites strictes : un nombre maximal de tours, un budget de tokens par tâche et un délai. Journalisez chaque limite atteinte, car c'est souvent le signe d'un bug. (Dans Claude Code, par exemple, les subagents ont un réglage maxTurns ; j'en parle dans écrire des subagents Claude Code.)

9. Faire tourner en local le travail régulier à gros volume

Pour des charges qui tournent toute la journée à un volume prévisible, payer au token peut coûter plus cher que posséder ou louer le matériel. Un modèle ouvert sur votre propre GPU coûte la même chose que vous traitiez cent documents ou cent mille.

Mon propre exemple, c'est VidForge, un pipeline multi-agents autonome qui transforme un sujet choisi en vidéo YouTube terminée. Le gros du travail (narration, images générées, présentateur à l'écran, upscaling) tourne sur des modèles locaux, sur une seule carte graphique grand public de 16 Go, avec une file d'attente pour qu'un seul modèle tourne à la fois. C'est pour ça qu'une vidéo terminée ne coûte presque rien à produire.

Les modèles locaux gardent aussi les données en interne, ce qui compte pour la confidentialité et la protection des données. Je détaille les compromis dans IA privée et LLM on-premise.

10. Surveiller la langue

Le nombre de tokens dépend de la langue. Un texte en arabe, par exemple, demande souvent plus de tokens qu'en anglais pour le même sens : le même assistant peut donc coûter plus cher par message en arabe. Mesurez-le sur votre propre trafic et tenez-en compte dans le choix du modèle. J'en parle dans chatbot IA en arabe pour les entreprises.

Dans quel ordre s'y prendre

Si vous partez d'une grosse facture, cet ordre donne en général les gains les plus rapides :

1. Mesurer le coût par tâche et supprimer les appels inutiles.
2. Plafonner les boucles d'agents.
3. Envoyer les étapes faciles vers des modèles plus petits.
4. Restructurer les prompts pour le cache et alléger le contexte.
5. Passer les tâches non urgentes en traitement par lots.
6. Pour le travail régulier à gros volume, évaluer un modèle local.

Relancez votre jeu d'évaluation après chaque changement. Un système moins cher qui donne de moins bonnes réponses n'est pas moins cher une fois le rattrapage compté.

Travailler ensemble

Je suis Driss Briksine, ingénieur logiciel et ML. Je construis des systèmes d'IA de bout en bout et je fais tourner une grande partie de mon propre travail sur des modèles locaux : le coût est une contrainte de conception dès le premier jour, pas une réflexion après coup. Voyez mes réalisations, ou envoyez-moi un court descriptif si votre facture de LLM augmente plus vite que votre usage.