Chapitre 14 — Économie du token et tarification des API

Quatorzième billet de la tournée chapitre par chapitre de LLM Primer VI : Mettre à l'échelle les systèmes IA. Le chapitre qui relie la physique du Chapitre 1 aux lignes de la facture — et qui explique pourquoi la facture du premier mois ressemble rarement à ce que l'équipe avait modélisé.

Pourquoi ce chapitre existe

Les chapitres précédents ont traité le coût de l'inférence comme un fait physique — octets déplacés sur la HBM, FLOPs dépensés dans un matmul, secondes-GPU consommées par une requête. Ce cadre est juste pour l'équipe qui possède le silicium. Pour la population bien plus large des équipes qui achètent l'inférence à une API, la surface de coût est remodelée par l'unité pour laquelle le fournisseur facture : le token. Le Chapitre 14 traite de la raison pour laquelle le token est tarifé comme il l'est, pourquoi les côtés entrée et sortie du même appel ont des prix si différents, et comment silencieusement l'historique conversationnel d'un chatbot et la pensée invisible d'un modèle de raisonnement finissent sur la facture.

14.1 La sortie coûte 4–8× l'entrée parce que le décodage est la phase liée à la bande passante

Un token d'entrée emprunte le chemin de préremplissage — dense, limité par le calcul, parallèle sur toutes les positions du prompt, exactement la charge pour laquelle les GPU sont conçus. Sur un modèle 70B, un H100 avale des dizaines de milliers de tokens d'entrée par seconde, car l'opération est un large matmul à haute intensité arithmétique. Un token de sortie emprunte le chemin de décodage — séquentiel, limité par la bande passante mémoire, un token par passe avant, chaque pas lisant l'intégralité du cache KV depuis la HBM. Le même H100 produit 50–100 tokens de sortie par seconde par requête. Le rapport entre ces deux débits est celui que reflète la grille tarifaire. Les modèles frontières en 2025 facturent deux à cinq dollars par million de tokens d'entrée et dix à trente dollars par million de sortie — une asymétrie 4:1 à 8:1 qui n'est pas un choix de marge mais un report direct de l'asymétrie du calcul sous-jacent. L'entrée cachée coûte encore moins cher, car le fournisseur a déjà payé le préremplissage sur une requête précédente. Les API batch sont à moitié prix, car le fournisseur peut ordonnancer le travail dans des fenêtres de capacité inactive. Les tokens de raisonnement sont des tokens de sortie parce que c'est ce qu'ils sont à l'intérieur du moteur.

14.2 Le levier d'optimisation dépend de la forme entrée/sortie

L'erreur est de modéliser le coût avec un seul nombre mental — « les tokens coûtent X » — au lieu de décomposer entrée et sortie séparément. Un triage service client dominé par la récupération, envoyant 8 500 tokens d'entrée et recevant une réponse de 600 tokens, est dominé par le coût d'entrée aux tarifs frontière (environ 255 $ d'entrée contre 90 $ de sortie pour 10 000 requêtes par jour). Un système de rédaction long-format au même volume — 2 200 tokens d'entrée, 3 000 tokens de sortie — est dominé par la sortie (66 $ d'entrée contre 450 $ de sortie). Le conseil d'optimisation est inverse dans les deux cas : raccourcir le prompt pour le premier, raccourcir la réponse pour le second, et router vers un modèle dont le profil tarifaire favorise l'axe dominant. Une seconde décomposition à faire tourner est par locataire ou par charge. Les systèmes multi-tenant montrent presque toujours un biais en loi de puissance où les 10 pour cent supérieurs représentent la moitié ou plus des dépenses, et un travail d'optimisation ciblé sur ces locataires paye plusieurs fois plus qu'un travail uniforme réparti sur la longue queue.

14.3 L'accumulation de contexte et les tokens de raisonnement invisibles composent la facture

Le token le plus cher est celui que l'équipe a oublié d'envoyer. Les API sont sans état ; chaque requête embarque l'historique complet de la conversation en entrée à chaque appel. Le coût cumulatif d'entrée sur une conversation à N tours croît quadratiquement en N, moins le crédit de cache de préfixe. Une équipe qui a tarifé son système sur une référence à un seul tour découvre, six mois plus tard, que sa conversation moyenne s'étale sur huit tours et que le coût d'entrée par conversation a été multiplié à peu près comme le carré. Le second multiplicateur silencieux est constitué par les tokens de raisonnement. Les modèles comme o1/o3, l'extended thinking d'Anthropic, DeepSeek R1 et les variantes de raisonnement de Google produisent un large volume de pensée interne avant la réponse visible — souvent 4 000–8 000 tokens derrière une réponse visible de 500 tokens. Ces tokens empruntent la même boucle de décodage et sont facturés comme sortie ; ils ne sont pas renvoyés à l'appelant à moins que le code ne le demande. La parade est d'instrumenter correctement l'objet usage de la réponse d'API — prompt_tokens, cached_prompt_tokens, completion_tokens, reasoning_tokens, et toute catégorie spécifique au fournisseur — et de signaler les catégories inconnues plutôt que de les laisser tomber silencieusement. Chaque nouvelle dimension facturée par le fournisseur doit apparaître dans le schéma d'usage de l'équipe, ou la facture suivante sera une surprise.

Ce que prépare le Chapitre 14

Une fois que l'équipe sait lire sa propre facture avec la décomposition entrée/sortie, par locataire et par catégorie, la question suivante — celle que la finance posera — est de savoir si l'équipe devrait payer au token du tout. Le Chapitre 15 parcourt l'alternative : rapatrier l'inférence en interne, louer ou acheter des GPU, et payer par GPU-heure. Le calcul du seuil de rentabilité est propre. Ce qui est moins propre, et que la plupart des équipes sous-estiment, c'est tout ce qui figure du côté dédié du grand livre et qui n'est pas sur la facture GPU : l'ingénierie plateforme, les correctifs de sécurité, la chorégraphie de mise à niveau des modèles, la rotation d'astreinte qui répond quand un nœud tombe du parc.

Prochaine étape — Chapitre 15 : API serverless vs infrastructure dédiée. La formule du seuil de rentabilité, la ligne cachée, et les postures hybrides où « les deux » est la bonne réponse.