Skip to content
MAMasterAI Now
Inference & Cost7 min de lecture

Calculer le coût d'un prompt en tokens : méthode simple

Découvrez comment convertir des mots en tokens avec le BPE puis estimer le coût d'une requête, d'une journée et d'un mois grâce à un exemple chiffré clair.

Par MasterAI Now Team

Pour estimer le coût d'un prompt, on convertit d'abord son texte en tokens (les unités atomiques que le modèle traite réellement), puis on multiplie le nombre de tokens d'entrée et de sortie par le prix unitaire correspondant. Exemple : un prompt de 300 mots français donne grossièrement 400 à 500 tokens ; à un tarif illustratif de 0,50 $ par million de tokens d'entrée, la requête coûte environ 0,0002 à 0,00025 $. On extrapole ensuite ce coût unitaire sur une journée (requêtes × coût) puis sur un mois (jours × coût journalier).

Comprendre la tokenisation BPE : des mots aux tokens

Un modèle de langage ne lit pas des caractères ni des mots : il lit des tokens, des fragments de texte issus d'un découpage statistique. La méthode la plus répandue est le BPE (Byte Pair Encoding, ou encodage par paires d'octets) : l'algorithme part des caractères individuels, puis fusionne de façon répétée les paires de symboles qui apparaissent le plus souvent dans un grand corpus d'entraînement. Chaque fusion crée un nouveau token. Le résultat est un vocabulaire figé — souvent quelques dizaines de milliers d'entrées — dans lequel chaque token est identifié par un identifiant numérique.

Conséquence pratique : un mot fréquent comme « le » ou « calcul » peut tenir en un seul token, tandis qu'un mot rare, un nom propre ou un terme technique est découpé en plusieurs morceaux. En français, les accents, les apostrophes et les terminaisons verbales variées poussent souvent le découpage à un niveau plus fin qu'en anglais : on observe couramment de l'ordre de 1,3 à 1,8 token par mot en français, contre environ 1,3 en anglais — ce sont des ordres de grandeur indicatifs, à vérifier avec le tokenizer exact du modèle visé.

Point crucial : le tokenizer dépend du modèle. Deux modèles peuvent produire des comptages différents pour le même texte. Il faut donc toujours mesurer avec l'outil qui correspond au modèle facturé.

Convertir un prompt en tokens : exemple pas-à-pas

Prenons un prompt concret de support client :

Rédige une réponse à ce client qui signale que sa commande est arrivée abîmée. Ton professionnel, propose un remplacement sous 48 heures et excuse-nous brièvement.

Étape 1 — compter les mots : environ 28 mots. Étape 2 — appliquer un ratio BPE estimé pour le français, par exemple 1,5 token/mot : 28 × 1,5 ≈ 42 tokens. Étape 3 — ajouter les tokens de structure (rôles, séparateurs de messages) : quelques unités selon le format d'API. Étape 4 — répéter l'opération pour la réponse attendue : une réponse de 80 mots ≈ 120 tokens de sortie. Étape 5 — vérifier : passez le texte dans le tokenizer officiel du modèle (bibliothèque de tokenisation ou endpoint de comptage) pour remplacer l'estimation par un chiffre exact.

Le calcul de coût s'écrit alors :

coût_requête = (tokens_entrée × prix_entrée) + (tokens_sortie × prix_sortie)
             = (42 × 0,50/1e6) + (120 × 1,50/1e6)
             ≈ 0,000021 + 0,00018 ≈ 0,00020 $

Les prix ci-dessus sont purement illustratifs : remplacez-les par la grille tarifaire du modèle que vous utilisez, en vérifiant l'unité (souvent le million de tokens) et la distinction entrée/sortie.

Calculer le coût d'une requête, d'une journée et d'un mois

Le coût d'un appel API se décompose en deux flux distincts : les tokens d'entrée (votre prompt : consigne système + question + contexte) et les tokens de sortie (la réponse générée). Chaque flux a son propre prix unitaire, exprimé en dollars par million de tokens (ou par 1 000 tokens selon le modèle). La formule de base :

coût_requête = (tokens_entrée / 1_000_000 × prix_entrée)
             + (tokens_sortie  / 1_000_000 × prix_sortie)

Exemple chiffré. Hypothèses de travail (prix fictifs mais plausibles, à remplacer par la grille tarifaire réelle de votre fournisseur) : entrée à 3 $ / million de tokens, sortie à 15 $ / million. Pour un prompt de 900 tokens d'entrée et une réponse de 300 tokens de sortie :

entrée : 900  / 1 000 000 × 3  = 0,0027 $
sortie : 300  / 1 000 000 × 15 = 0,0045 $
coût_requête = 0,0072 $  (≈ 0,7 centime)

À l'échelle d'une journée, multipliez par le nombre de requêtes. Avec 500 requêtes/jour de ce type :

coût_jour = 500 × 0,0072 = 3,60 $
coût_mois  = 3,60 × 30   = 108 $

Le mois est ici estimé sur 30 jours ; pour un mois calendaire réel, comptez entre 28 et 31 jours, ou utilisez le nombre de jours ouvrés si l'usage est professionnel. Point de vigilance : la moyenne des tokens de sortie est souvent le paramètre le plus incertain. Mesurez-la sur un échantillon de réponses réelles plutôt que de la deviner.

Checklist avant de valider une estimation :

  • Prix entrée et sortie relevés séparément pour le modèle exact utilisé.
  • Tokens du prompt système inclus dans l'entrée (ils sont facturés à chaque appel).
  • Tokens du contexte/historique inclus si vous envoyez une conversation complète.
  • max_tokens de sortie défini : il plafonne le pire cas, pas le coût moyen.
  • Marge de sécurité ajoutée (par exemple +20 %) pour absorber la variabilité des réponses.

Utiliser le calculateur de coût API pour vérifier vos estimations

Un calculateur de coût API prend en entrée un texte (ou un tokenizer) et une grille tarifaire, puis renvoie le nombre de tokens et le coût. Pour que la vérification soit fiable, procédez en trois temps : (1) tokenisez un échantillon représentatif de vos prompts réels avec le tokenizer du modèle visé, pas avec un compteur approximatif ; (2) comparez le total tokens calculé à votre estimation BPE ; (3) appliquez la grille tarifaire officielle du fournisseur au moment du test.

Un court script de contrôle résume la logique :

def cout(tok_in, tok_out, prix_in, prix_out):
    # prix en $ par million de tokens
    return (tok_in * prix_in + tok_out * prix_out) / 1_000_000

req = cout(900, 300, 3.0, 15.0)     # 0,0072 $
print(req, req * 500 * 30)          # coût requête puis coût mensuel

Vérifiez toujours trois choses dans un calculateur : la version du tokenizer (elle change le découpage), l'unité de prix (par token, par 1 000 ou par million) et la distinction entrée/sortie. Un écart de 5 à 15 % entre votre estimation et le calculateur est normal (ponctuation, accents, caractères spéciaux) ; au-delà, revoyez vos hypothèses de volume.

Questions fréquentes

Combien de tokens représente un mot en français avec le BPE ?

Il n'existe pas de ratio universel, mais on observe souvent une fourchette d'environ 1,3 à 2 tokens par mot en français, selon le modèle et le texte. Les mots courants et les formes fléchies régulières se découpent en peu de tokens, tandis que les mots rares, les accents isolés, les nombres ou les identifiants techniques explosent le compte. Pour un ordre de grandeur fiable, partez de 1,5 token par mot et vérifiez sur un échantillon réel de votre prompt avec le tokenizer du modèle visé.

Pourquoi le coût d'entrée diffère-t-il du coût de sortie ?

Les tokens d'entrée (votre prompt, y compris le prompt système et l'historique) sont traités en une seule passe, ce qui est mécaniquement moins coûteux que la génération. Les tokens de sortie sont produits un par un, chaque étape nécessitant un nouveau passage dans le modèle : le prix par token de sortie est donc généralement plus élevé, souvent plusieurs fois celui de l'entrée. Conséquence pratique : un prompt long mais une réponse courte coûte surtout en entrée, l'inverse coûte surtout en sortie.

Comment estimer le coût mensuel à partir d'un usage quotidien ?

Multipliez le coût moyen d'une requête par le nombre de requêtes par jour, puis par le nombre de jours d'activité dans le mois. La formule :

coût_mensuel ≈ coût_requête × requêtes_par_jour × jours_par_mois

Ajoutez une marge pour la variabilité : les requêtes ne font pas toutes la même longueur, et les réponses générées varient. Une marge de 20 à 30 % sur l'estimation est raisonnable si vous ne mesurez pas les longueurs réelles ; sinon, calculez sur un échantillon de requêtes représentatives plutôt que sur une seule.

Faut-il compter les tokens du prompt système dans le coût ?

Oui, systématiquement : le prompt système est envoyé à chaque appel et ses tokens sont facturés comme des tokens d'entrée. C'est un poste souvent sous-estimé, car un prompt système de quelques centaines de tokens répété sur des milliers de requêtes pèse lourd dans la facture. Si vous utilisez aussi un historique de conversation, celui-ci s'ajoute également à chaque tour : comptez l'ensemble (système + historique + message utilisateur) comme entrée.

Comment réduire le coût d'un prompt sans perdre en qualité ?

Trois leviers concrets : raccourcir le prompt système en supprimant les instructions redondantes ou décoratives, limiter la longueur de sortie demandée (consigne explicite, format contraint), et tronquer ou résumer l'historique plutôt que de le renvoyer intégralement. Vous pouvez aussi réserver les modèles les plus chers aux requêtes complexes et router les tâches simples vers un modèle moins coûteux. Mesurez l'effet de chaque changement sur un échantillon : réduisez, puis vérifiez que la qualité perçue reste stable.

Questions fréquentes

Combien de tokens représente un mot en français avec le BPE ?

Il n'existe pas de ratio universel, mais on observe souvent une fourchette d'environ 1,3 à 2 tokens par mot en français, selon le modèle et le texte. Les mots courants et les formes fléchies régulières se découpent en peu de tokens, tandis que les mots rares, les accents isolés, les nombres ou les identifiants techniques explosent le compte. Pour un ordre de grandeur fiable, partez de 1,5 token par mot et vérifiez sur un échantillon réel de votre prompt avec le tokenizer du modèle visé.

Pourquoi le coût d'entrée diffère-t-il du coût de sortie ?

Les tokens d'entrée (votre prompt, y compris le prompt système et l'historique) sont traités en une seule passe, ce qui est mécaniquement moins coûteux que la génération. Les tokens de sortie sont produits un par un, chaque étape nécessitant un nouveau passage dans le modèle : le prix par token de sortie est donc généralement plus élevé, souvent plusieurs fois celui de l'entrée. Conséquence pratique : un prompt long mais une réponse courte coûte surtout en entrée, l'inverse coûte surtout en sortie.

Comment estimer le coût mensuel à partir d'un usage quotidien ?

Multipliez le coût moyen d'une requête par le nombre de requêtes par jour, puis par le nombre de jours d'activité dans le mois. La formule : Ajoutez une marge pour la variabilité : les requêtes ne font pas toutes la même longueur, et les réponses générées varient. Une marge de 20 à 30 % sur l'estimation est raisonnable si vous ne mesurez pas les longueurs réelles ; sinon, calculez sur un échantillon de requêtes représentatives plutôt que sur une seule.

Faut-il compter les tokens du prompt système dans le coût ?

Oui, systématiquement : le prompt système est envoyé à chaque appel et ses tokens sont facturés comme des tokens d'entrée. C'est un poste souvent sous-estimé, car un prompt système de quelques centaines de tokens répété sur des milliers de requêtes pèse lourd dans la facture. Si vous utilisez aussi un historique de conversation, celui-ci s'ajoute également à chaque tour : comptez l'ensemble (système + historique + message utilisateur) comme entrée.

Comment réduire le coût d'un prompt sans perdre en qualité ?

Trois leviers concrets : raccourcir le prompt système en supprimant les instructions redondantes ou décoratives, limiter la longueur de sortie demandée (consigne explicite, format contraint), et tronquer ou résumer l'historique plutôt que de le renvoyer intégralement. Vous pouvez aussi réserver les modèles les plus chers aux requêtes complexes et router les tâches simples vers un modèle moins coûteux. Mesurez l'effet de chaque changement sur un échantillon : réduisez, puis vérifiez que la qualité perçue reste stable.