Qu’est-ce qu’un calculateur de coût par requête ? Guide des coûts d’API LLM

Un calculateur de coût par requête est un outil qui estime le coût d’API d’un appel unique à un grand modèle de langage (LLM). Vous indiquez le nombre de jetons d’entrée (votre invite, le contexte et les documents récupérés), le nombre attendu de jetons de sortie (la réponse du modèle) et le modèle visé. Le calculateur multiplie chaque valeur par le tarif par jeton publié du fournisseur et renvoie un coût par requête, ainsi qu’un total mensuel projeté selon le volume d’appels prévu.

Son objectif principal est de rendre les coûts d’IA prévisibles. Sans calculateur, il est facile de sous-estimer la vitesse à laquelle les coûts de jetons s’accumulent à l’échelle. Une requête à 0,012 $ paraît négligeable - mais à 10 000 appels par jour, cela représente 120 $ par jour, soit 3 600 $ par mois, depuis un seul point d’API. Les calculateurs de coût par requête révèlent cela avant le déploiement, et non après.

Ce qu’affiche un calculateur de coût par requête

• Coût par requête - le montant exact d’un appel d’API avec vos nombres de jetons et votre modèle.
• Projections journalières et mensuelles - applique le coût par requête à votre volume d’appels prévu.
• Répartition entrée / sortie - montre la part du coût venant de l’invite et celle venant de la réponse, les jetons de sortie étant plus chers.
• Comparaison de modèles - certains calculateurs comparent simultanément le coût de la même requête sur plusieurs modèles.

Les fournisseurs de LLM facturent au jeton, une unité de texte qui correspond à environ 0,75 mot en anglais (soit environ 4 caractères). Les tarifs sont exprimés par million de jetons ($/M), séparément pour l’entrée et la sortie. Les jetons d’entrée incluent tout ce que vous envoyez : l’invite système, l’historique de conversation, le message de l’utilisateur, les extraits de documents récupérés par les pipelines RAG et les schémas de fonctions ou d’outils. Les jetons de sortie correspondent à la réponse générée par le modèle.

Les jetons d’entrée et de sortie sont facturés séparément. Les jetons de sortie coûtent 3 à 5 fois plus cher que ceux d’entrée, car générer du texte coûte plus cher en calcul que traiter du contexte.

Pourquoi les jetons de sortie coûtent plus cher

Lors de l’inférence, traiter les jetons d’entrée nécessite une seule passe avant dans le modèle. Générer des jetons de sortie exige une boucle autorégressive : le modèle produit un jeton à la fois, chaque étape dépendant de la précédente. Ce processus séquentiel est bien plus gourmand en GPU par jeton, d’où le supplément notable facturé sur la sortie. Aux tarifs de GPT-4o, l’entrée coûte 2,50 $/M et la sortie 10,00 $/M, soit un facteur 4. Conséquence pratique directe : les réponses longues et verbeuses coûtent disproportionnellement plus cher que les réponses concises.

Comment les jetons se traduisent en longueurs d’invite réelles

• Invite courte + réponse courte (par ex. « Classe ce texte ») : ~50-200 jetons au total.
• Message système + requête avec contexte : ~500-2 000 jetons en entrée, 100-500 en sortie.
• Requête RAG avec extraits de documents : ~2 000-8 000 jetons en entrée, 300-1 000 en sortie.
• Flux agentique avec résultats d’outils et historique : ~8 000-32 000 jetons en entrée par appel.
• Génération longue (article, code) : ~1 000-4 000 jetons en entrée, 1 000-4 000 en sortie.

Estimer précisément ses coûts par requête suppose de connaître trois chiffres : le nombre moyen de jetons d’entrée par appel, le nombre moyen de jetons de sortie par appel et votre volume quotidien d’appels. Les deux premiers se mesurent de préférence empiriquement, avec le compteur de jetons du fournisseur ou le champ `usage` des réponses d’API, plutôt qu’en les estimant à partir du nombre de mots.

Étape 1 - Mesurer l’usage réel des jetons en développement

Chaque réponse d’API LLM contient un objet `usage` indiquant `prompt_tokens`, `completion_tokens` et `total_tokens`. Journalisez ces valeurs pendant le développement sur un échantillon représentatif de 50 à 100 requêtes réelles. Calculez la moyenne et le 95e centile pour l’entrée comme pour la sortie. Pour le dimensionnement des coûts, utilisez le 95e centile d’entrée et la moyenne de sortie : cela tient compte des contextes volumineux atypiques sans surestimer l’appel typique.

Étape 2 - Estimer le volume mensuel

Pour une application en production, estimez : utilisateurs actifs quotidiens × requêtes moyennes par session × appels d’API par requête. Un chatbot avec 1 000 utilisateurs quotidiens, 5 messages par session et 1 appel d’API par message génère 5 000 appels par jour. Multipliez votre coût par appel par le volume quotidien, puis par 30 pour la projection mensuelle. Prévoyez une marge de 30 à 50 % pour les pics de trafic et les itérations d’ingénierie d’invite.

Étape 3 - Comparer les niveaux de modèles

Passez les mêmes nombres de jetons dans plusieurs niveaux de modèles pour repérer les tâches où les exigences de qualité permettent un modèle moins cher. Beaucoup de tâches - classification, extraction d’entités, résumé simple, réponses de FAQ - atteignent une qualité acceptable avec un modèle plus petit et moins cher. Réserver les modèles de pointe (classe GPT-4, classe Claude 3.5 Sonnet) au sous-ensemble de tâches qui les exigent réellement et router les tâches simples vers des modèles moins chers est en général la réduction de coût la plus rentable.

Les tarifs des modèles évoluent souvent : les fournisseurs les ont beaucoup réduits à mesure que la concurrence s’intensifie. Le tableau ci-dessous présente des niveaux tarifaires représentatifs de mi-2026 pour illustrer la structure des coûts. Vérifiez toujours les prix actuels sur la page tarifaire officielle de chaque fournisseur avant d’établir des projections de coût en production.

L’écart de coût entre le niveau le moins cher et le plus cher couvre deux ordres de grandeur. Une application à 10 000 requêtes par jour avec un modèle de classe o1 coûte environ 60 à 240 $ par jour ; la même application avec GPT-4o Mini coûte 1,50 à 20 $ par jour. Les décisions de routage fondées sur la complexité de la tâche - utiliser un classificateur de requêtes pour diriger chaque appel vers le niveau de modèle adapté - peuvent réduire la dépense d’API totale de 60 à 80 % dans les pipelines à complexité mixte.

Fenêtre de contexte et compromis de coût

Les grandes fenêtres de contexte permettent d’inclure plus d’informations par requête, mais plus de jetons dans l’invite signifie un coût d’entrée plus élevé. Une fenêtre de 100 000 jetons ne vaut la peine que si le contexte supplémentaire améliore réellement la qualité de la réponse pour la tâche visée. Pour la plupart des applications de génération augmentée par récupération (RAG), 2 000 à 4 000 jetons de contexte récupéré produisent des résultats presque aussi bons que 20 000 jetons, pour un coût d’entrée 5 à 10 fois inférieur. Comparez toujours qualité et longueur de contexte avant de figer de grandes invites en production.

L’optimisation des coûts par requête repose sur deux leviers : réduire les jetons par requête et réduire le prix par jeton. Les stratégies ci-dessous agissent sur les deux et sont classées approximativement par effort de mise en œuvre croissant.

• Compresser les données d’entrée avant injection - convertissez les payloads JSON, CSV ou YAML au format TOON avant de les inclure dans les invites. Le convertisseur JSON vers TOON réduit le nombre de jetons de 30 à 60 % sans perte d’information.
• Utiliser le modèle le moins cher conforme aux exigences - testez chaque type de tâche sur des niveaux de modèles plus petits avant de supposer qu’il faut un modèle de pointe. Beaucoup de tâches d’extraction, de classification et de résumé fonctionnent bien avec GPT-4o Mini ou Gemini Flash.
• Raccourcir et épurer les invites système - auditez votre invite système pour repérer les consignes redondantes, les exemples de formatage longs et les mises en garde répétées. Chaque jeton supprimé économise de l’argent sur tous les appels d’API.
• Limiter la longueur de sortie avec max_tokens - demandez des réponses concises et fixez un plafond strict de max_tokens. Les jetons de sortie coûtent 3 à 5 fois ceux d’entrée : réduire les réponses verbeuses coupe donc la part la plus chère de la facture.
• Activer le cache d’invite - utilisez la mise en cache native du fournisseur pour les invites système statiques et les exemples few-shot. Les jetons mis en cache coûtent 50 à 90 % de moins que les autres chez OpenAI et Anthropic.
• Mettre en cache les réponses fréquentes - pour les requêtes déterministes ou quasi déterministes, mettez la réponse du LLM en cache et servez-la pour les entrées identiques répétées sans appel d’API.

La compression de jetons : la voie la plus rapide vers l’économie

Pour les applications qui transmettent des données structurées aux LLM - catalogues produits, fiches utilisateurs, exports analytiques, réponses d’API -, la compression des jetons d’entrée offre la réduction de coût la plus rapide et la plus régulière. Convertir un payload JSON de 2 000 jetons au format TOON le ramène à environ 800-1 400 jetons. À 3,00 $/M de jetons d’entrée et 50 000 requêtes par jour, cette seule modification économise 0,09 à 0,18 $ par jour, soit environ 33 à 66 $ par mois sans impact sur la qualité. Pour les données CSV, le convertisseur CSV vers TOON atteint 40 à 60 % d’économie de jetons sur les jeux tabulaires, et le convertisseur YAML vers TOON traite la configuration et les données structurées au format YAML.

Pour un développeur solo ou un petit projet, les coûts de jetons restent rarement significatifs : 5 à 20 $ par mois pour l’expérimentation et le développement. Le problème apparaît quand une fonctionnalité monte en charge en production, quand les invites embarquent de gros payloads de contexte, ou quand un pipeline enchaîne plusieurs appels d’API par interaction utilisateur. Ce sont les scénarios où les calculs de coût par requête deviennent critiques.

Pipelines agentiques et multi-étapes

Les flux agentiques qui enchaînent plusieurs appels au LLM - planification, usage d’outils, réflexion, résumé - peuvent cumuler 10 000 à 100 000 jetons sur une seule requête utilisateur qui semble être une interaction unique. Chaque résultat d’outil et chaque tour de conversation est réinjecté comme contexte pour l’appel suivant, ce qui fait croître le nombre de jetons de façon quadratique avec le nombre d’étapes. Pour ces pipelines, l’estimation du coût par requête utilisateur suppose de multiplier le coût par requête par le nombre moyen d’appels LLM par exécution.

Applications RAG avec de gros extraits de documents

Les pipelines de génération augmentée par récupération injectent les extraits récupérés dans chaque invite. Si la stratégie de découpage produit de gros extraits (1 000 à 4 000 jetons chacun) et que trois à cinq extraits sont récupérés par requête, le nombre de jetons d’entrée peut atteindre 5 000 à 20 000 par appel avant même d’inclure la question de l’utilisateur. Compresser les extraits récupérés dans un format comme TOON - ou réduire leur taille dans le pipeline d’embeddings - abaisse directement le coût par requête sans changer la qualité de la récupération. Pour comprendre où se place la validation de sortie structurée dans ce type de pipeline, le guide Guardrails AI détaille la couche de validation en aval de la récupération.