Coût des tokens LLM : comprendre et maîtriser la facture

Votre facture d'API LLM grimpe sans que vous compreniez exactement pourquoi. La réponse tient en un mot : les tokens. Vous payez chaque fragment de texte envoyé au modèle et chaque fragment qu'il génère, et quelques décisions structurantes font varier ce coût d'un facteur dix. Cet article explique la mécanique fine de la facturation au token et les leviers concrets pour rendre votre coût prévisible, sans rogner sur la qualité.

Le token, l'unité que vous payez vraiment

Un token n'est pas un mot. C'est un fragment de texte, souvent une syllabe, un mot court ou une terminaison, que le modèle découpe pour le traiter. Un mot fréquent compte pour un token, un mot rare ou technique peut en valoir trois ou quatre. En français, le découpage est en général plus fin qu'en anglais : à contenu égal, vous consommez un peu plus de tokens, donc vous payez un peu plus. Ce détail explique pourquoi un même prompt traduit coûte rarement le même prix d'une langue à l'autre.

Deux compteurs tournent en parallèle, et c'est la clé de tout :

Les tokens d'entrée : tout ce que vous envoyez au modèle. Votre instruction, le contexte fourni, les documents collés, l'historique de conversation, les exemples.
Les tokens de sortie : tout ce que le modèle génère en réponse.

Sur la quasi-totalité des modèles, le token de sortie coûte nettement plus cher que le token d'entrée, souvent plusieurs fois plus. La raison est technique : générer mobilise plus de calcul que lire. La conséquence est opérationnelle, et beaucoup d'équipes la manquent : pour réduire une facture, brider la longueur des réponses paie plus vite qu'élaguer le prompt d'entrée.

Pourquoi la facture dérape

Dans la plupart des cas, l'envolée d'une facture LLM ne vient pas d'un usage massif soudain, mais de fuites discrètes qui se cumulent appel après appel.

L'historique qui enfle. Dans un agent conversationnel, chaque tour rejoue souvent tout l'historique précédent en entrée. Le dixième message peut coûter dix fois le premier, sans que personne ne s'en aperçoive.
Le contexte surdimensionné. Coller un document entier alors que trois paragraphes suffisaient, c'est payer plein tarif d'entrée pour du bruit. C'est l'erreur la plus fréquente quand on raisonne sans surveiller la fenêtre de contexte et ses limites.
Les réponses non bornées. Sans consigne de longueur, un modèle peut produire trois paragraphes là où deux phrases répondaient. Multiplié par le tarif de sortie et par le volume, l'addition grimpe.
Le modèle trop puissant par défaut. Brancher le modèle le plus capable sur une tâche triviale revient à payer un tarif premium pour classer des e-mails.
Les boucles d'agent silencieuses. Un agent qui raisonne, appelle des outils et se relit consomme plusieurs appels par tâche. Sans plafond, une boucle mal cadrée peut générer des dizaines d'appels facturés pour un seul objectif.

Le point commun de ces fuites : elles sont invisibles à l'unité et douloureuses à l'échelle. D'où la première règle de discipline : instrumenter avant d'optimiser.

Les leviers qui font baisser le coût au token

Voici les leviers par ordre de rapport effort sur impact, du plus rentable au plus fin.

1. Choisir le bon modèle par tâche

C'est le levier numéro un. Les fournisseurs proposent en général une gamme : un modèle léger et bon marché, un modèle intermédiaire, un modèle haut de gamme. L'écart de prix au token entre le plus petit et le plus grand se compte souvent en multiples importants. Or beaucoup de tâches (classer, extraire, reformuler, router) n'exigent pas le modèle le plus puissant. Réservez ce dernier au raisonnement complexe et à la rédaction exigeante. Pour cadrer ce tri, notre guide pour choisir un modèle LLM selon l'usage business détaille la méthode.

2. Borner les sorties

Puisque la sortie est le token le plus cher, fixez systématiquement une limite de longueur et demandez explicitement la concision. Un format de réponse structuré et court (une liste, un objet, une phrase) coûte moins qu'un texte libre verbeux et reste plus facile à exploiter en aval.

3. Réduire et trier l'entrée

Avant d'envoyer du contexte, demandez-vous ce qui est strictement utile. Filtrer en amont, résumer un long document une fois pour le réutiliser ensuite, tronquer l'historique d'une conversation au-delà d'un certain nombre de tours : ces gestes simples retirent du poids inutile à chaque appel.

4. Activer le cache de prompt

Quand une partie de votre prompt ne change jamais (instructions système, base documentaire, exemples de référence), le cache de prompt permet de la facturer à tarif réduit sur les appels suivants au lieu du plein tarif d'entrée. Le gain est net sur les usages répétitifs qui rejouent le même socle. Il est nul sur des prompts uniques et toujours différents : inutile de complexifier votre code pour rien.

5. Basculer en traitement par lot ce qui n'est pas urgent

La plupart des fournisseurs proposent un mode de traitement asynchrone, ou par batch, avec une remise significative en échange d'un délai. Enrichir une base, classer des milliers de fiches, générer du contenu en arrière-plan : tout ce qui n'a pas besoin d'une réponse immédiate est candidat. Vous payez le même travail moins cher, simplement en acceptant d'attendre.

Estimer le coût avant de construire

Avant tout développement, une estimation grossière suffit à savoir si un cas d'usage est rentable. La logique est simple et tient en trois multiplications :

Estimez le nombre de tokens d'entrée d'un appel type, puis le nombre de tokens de sortie attendu.
Multipliez chacun par son tarif respectif (entrée et sortie sont tarifés séparément), puis additionnez : vous obtenez le coût d'un appel.
Multipliez par le nombre d'appels mensuels attendu, et ajoutez une marge de prudence, car les sorties varient d'un appel à l'autre.

Prenons un ordre de grandeur prudent. Une tâche qui envoie un contexte modeste et produit une réponse courte coûte une fraction de centime par appel sur un modèle léger. Anodine à l'unité, elle devient un poste à surveiller dès qu'elle tourne des centaines de milliers de fois par mois. Ce calcul de coin de table évite de découvrir le problème sur la facture. Pour relier ce coût au retour qu'il génère, raisonnez ensuite en projet avec notre analyse du coût et du ROI de l'IA, qui prend le sujet par l'autre bout : la valeur, pas l'unité.

Mettre la facture sous contrôle, durablement

Les leviers ci-dessus ne tiennent que si vous les ancrez dans un système, pas dans un coup d'éclat ponctuel.

Suivez la dépense par cas d'usage, pas seulement le total. Tagguez vos appels (fonctionnalité, équipe, environnement) pour savoir où part l'argent et arbitrer en connaissance de cause.
Posez des plafonds. Un budget mensuel par projet et une limite d'appels par tâche d'agent transforment une dérive silencieuse en alerte visible.
Mesurez la qualité, pas seulement le coût. Un modèle moins cher qui produit des réponses inexploitables coûte en réalité plus cher : retouches, reprises, perte de confiance. L'objectif n'est pas le coût minimal, mais le meilleur coût pour une qualité donnée.

La prochaine étape concrète

Ne cherchez pas à tout optimiser d'un coup. Ouvrez votre tableau de bord de consommation, identifiez le cas d'usage le plus coûteux, et appliquez-lui les deux leviers les plus rentables : vérifiez qu'il tourne sur le bon modèle, et bornez ses sorties. Mesurez l'effet sur une semaine. Vous y gagnerez, dans la plupart des cas, une baisse immédiate sans rien sacrifier à la qualité, et surtout une méthode reproductible pour les cas suivants. Le coût au token devient prévisible le jour où vous le pilotez par cas d'usage, pas par facture globale.

Questions fréquentes

Qu'est-ce qu'un token et comment est-il facturé ?

Un token est un fragment de texte, souvent un mot court ou une partie de mot, que le modèle traite comme unité de base. Vous payez au token, séparément pour l'entrée (ce que vous envoyez : prompt, contexte, historique) et la sortie (ce que le modèle génère). En français, comptez en général un peu plus de tokens que de mots, car la langue se découpe en fragments plus fins que l'anglais.

Pourquoi les tokens de sortie coûtent-ils plus cher que ceux d'entrée ?

Sur la plupart des modèles, le token de sortie est facturé nettement plus cher que le token d'entrée, parfois plusieurs fois plus. La génération mobilise davantage de calcul que la simple lecture du prompt. Conséquence pratique : demander des réponses concises et bornées réduit la facture plus vite qu'optimiser le prompt d'entrée.

Le cache de prompt réduit-il vraiment la facture ?

Oui, quand une partie stable du prompt (instructions système, documentation, exemples) est réutilisée sur de nombreux appels. La portion mise en cache est ensuite facturée à un tarif réduit au lieu du plein tarif d'entrée. Le gain est réel sur les usages répétitifs à long contexte, négligeable sur des prompts uniques et changeants.

Comment estimer le coût d'un cas d'usage avant de le lancer ?

Estimez le nombre de tokens d'entrée et de sortie d'un appel type, multipliez chacun par son tarif respectif, puis par le volume d'appels mensuel attendu. Ajoutez une marge de prudence, car les sorties varient. Cette estimation grossière suffit à trier les cas d'usage rentables avant tout développement.

Le traitement par batch fait-il baisser le coût ?

Oui, pour les traitements non urgents. Les modes de traitement asynchrone ou par lot proposés par la plupart des fournisseurs appliquent une remise significative en échange d'un délai de réponse plus long. C'est idéal pour enrichir une base, classer des milliers de documents ou générer du contenu en arrière-plan, pas pour une réponse en temps réel.