Un token est une unité de texte (mot, morceau de mot, ponctuation) que le modèle lit et facture ; avec la tokenisation BPE, une même phrase française se découpe souvent en plus de morceaux qu'en anglais, donc coûte plus cher à entrée égale. Pour estimer le coût, on multiplie le nombre de tokens d'entrée par le prix unitaire, puis on extrapole par requête, par jour et par mois. Voici comment le vérifier concrètement, chiffres à l'appui.
Qu'est-ce qu'un token et pourquoi le BPE découpe mal le français
Un token est l'unité atomique traitée par un grand modèle de langage (LLM) : le texte est d'abord découpé en tokens, puis chaque token est converti en identifiant numérique. Un token ne correspond pas forcément à un mot : il peut être un mot entier ("chat"), un fragment ("anti", "constitu"), une espace collée à un mot, ou un signe de ponctuation. La tokenisation BPE (Byte Pair Encoding, ou encodage par paires d'octets) est l'algorithme le plus répandu : il part des octets bruts et fusionne de façon répétée les paires de symboles les plus fréquentes dans un grand corpus d'entraînement, jusqu'à obtenir un vocabulaire de taille fixée (souvent quelques dizaines de milliers d'entrées).
Le problème du français vient de la composition de ce corpus et de la morphologie de la langue. Ces vocabulaires sont historiquement dominés par l'anglais, langue à mots courts et très fréquents ; les mots français, plus longs, avec accents (é, è, à, ç) et de nombreuses flexions (manger, mangera, mangeraient), ont moins de chances d'exister comme tokens entiers. Ils sont donc découpés en sous-mots, et une lettre accentuée peut même être encodée en plusieurs octets selon le jeu de caractères. Résultat : là où "understanding" peut tenir en un ou deux tokens, "compréhension" en réclame souvent davantage, et chaque fragment supplémentaire est facturé.
Autre effet peu intuitif : les espaces et la ponctuation font partie du découpage. En français, l'espace avant les deux-points, le point-virgule ou le point d'interrogation, ainsi que les apostrophes fréquentes ("l'", "d'", "qu'"), ajoutent des tokens isolés. Ce ne sont pas des détails : sur un prompt long, ces micro-fragments s'accumulent et gonflent la facture sans apporter de contenu utile au modèle.
Exemples chiffrés : ce que coûte une même phrase en français et en anglais
Prenons une phrase simple et son équivalent anglais : « Le chat dort sur le canapé du salon. » / "The cat sleeps on the living room sofa." En BPE, le français se découpe typiquement en davantage de fragments : les articles et prépositions courts ("Le", "sur", "le", "du") restent des tokens isolés, "canapé" se scinde souvent en "can" + "ap" + "é", et l'accent consomme un fragment de plus. L'anglais, mieux couvert, regroupe plus facilement "living", "room" et "sofa" en unités compactes.
Sans inventer de chiffres précis, on peut raisonner en ordre de grandeur, à titre d'estimation : sur un texte français courant, comptez grossièrement entre 1,2 et 1,6 token par mot, contre environ 1,1 à 1,3 pour l'anglais selon le tokenizer. Une phrase française de 9 mots peut ainsi peser 12 à 15 tokens, son équivalent anglais 10 à 12. L'écart paraît faible à l'échelle d'une phrase, mais il se répète à chaque requête.
Changeons d'échelle. Un prompt de 500 mots en français représente, avec l'hypothèse de 1,3 token par mot, environ 650 tokens ; le même contenu en anglais, à 1,15 token par mot, tombe autour de 575 tokens. Soit environ 13 % de tokens en plus côté français — un écart à vérifier avec le tokenizer exact du modèle utilisé, car chaque fournisseur a son propre vocabulaire. Sur une application qui envoie des milliers de requêtes, ce pourcentage se transforme directement en euros.
La formule du coût d'entrée : tokens × prix par token
Le coût d'entrée (ce que vous payez pour le texte envoyé au modèle, par opposition à sa réponse) se calcule simplement :
coût_entrée = nombre_de_tokens_entrée × prix_par_token_entrée
Deux points pratiques. D'abord, le prix est presque toujours affiché par million de tokens ; il faut donc diviser :
coût_entrée = (tokens_entrée / 1_000_000) × prix_pour_1M_tokens
Ensuite, le nombre de tokens d'entrée n'est pas seulement votre prompt : il inclut tout ce que le modèle reçoit à chaque appel — instructions système, historique de conversation renvoyé, documents collés dans le contexte. Un chat qui « se souvient » de tout renvoie l'historique à chaque tour : le coût d'entrée croît donc plus vite que le nombre de vos messages.
Exemple chiffré (hypothèses explicites). Prenons un prix d'entrée fictif de 0,50 $ par million de tokens (ordre de grandeur courant pour un petit modèle, à remplacer par le tarif réel). Un prompt de 1 200 tokens envoyé 5 000 fois par jour :
coût par requête = (1 200 / 1 000 000) × 0,50 = 0,0006 $ (0,06 cent)
coût par jour = 0,0006 × 5 000 = 3,00 $
coût par mois = 3,00 × 30 = 90,00 $
Vérification : 5 000 × 1 200 = 6 000 000 tokens/jour, soit 6 × 0,50 = 3 $/jour. Correct. Si le même prompt passe à 2 000 tokens (par exemple parce qu'on a traduit les instructions en français et ajouté un exemple), le coût mensuel devient 150 $ — soit +67 % pour un texte à peine plus long.
Estimer le coût à l'échelle : par requête, par jour et par mois
La démarche tient en quatre étapes, à appliquer avec vos propres chiffres :
- Mesurer les tokens d'entrée moyens d'une requête réelle (outil de tokenisation du fournisseur ou bibliothèque
tiktoken-like selon le modèle). - Multiplier par le prix unitaire d'entrée pour obtenir le coût par requête.
- Multiplier par le volume quotidien (requêtes/jour), en ajoutant les tokens de sortie si vous voulez le coût total, avec leur prix distinct.
- Projeter sur 30 jours, puis ajouter une marge (10–20 %) pour les pics, les retries et les prompts plus longs que la moyenne.
coût_mensuel ≈ tokens_entrée_moyens × prix_token_entrée × requêtes_par_jour × 30 × (1 + marge)
Checklist avant de valider un budget :
- Prix d'entrée et de sortie relevés séparément (ils diffèrent).
- Tokens système + historique comptés, pas seulement le message utilisateur.
- Volume basé sur des logs réels, pas sur une intuition.
- Test comparatif français/anglais sur le même contenu (le français coûte souvent plus cher à contenu égal).
- Marge de sécurité incluse et scénario « prompt doublé » simulé.
Une astuce concrète : instrumentez votre code pour logger tokens_entrée à chaque appel, puis agrégez. Vous obtenez une distribution réelle (moyenne, p95) bien plus fiable qu'une estimation au doigt mouillé — et vous voyez immédiatement l'effet d'un prompt raccourci ou d'un historique tronqué.
Questions fréquentes
Combien de tokens contient une page de texte en français ?
Il n'existe pas de chiffre universel, car cela dépend du tokenizer (l'outil qui découpe le texte en tokens) et de la densité du vocabulaire. En pratique, on observe souvent qu'un mot français représente en moyenne entre 1,5 et 2,5 tokens avec les tokenizers BPE classiques, contre environ 1,3 pour l'anglais. Une page de 500 mots français correspond donc grosso modo à une fourchette de 750 à 1 250 tokens : traitez-le comme une estimation, pas une mesure exacte. Pour un chiffre fiable sur votre cas, comptez avec le tokenizer du modèle que vous utilisez.
Pourquoi le français consomme-t-il plus de tokens que l'anglais avec le BPE ?
Le BPE (Byte Pair Encoding) construit son vocabulaire en fusionnant les paires de caractères les plus fréquentes dans les données d'entraînement, historiquement très anglophones. Les mots et tournures anglaises courantes finissent donc souvent en un seul token, alors que les mots français, moins représentés, sont découpés en plusieurs morceaux. S'ajoutent les accents (é, è, à, ç) et les apostrophes fréquentes (l'eau, d'accord), qui fragmentent davantage les séquences. Résultat : à contenu égal, le français coûte souvent plus cher en tokens d'entrée.
Comment calculer le coût d'entrée d'une requête LLM ?
La formule de base est simple : coût = nombre de tokens d'entrée × prix par token d'entrée. Concrètement, comptez les tokens de votre prompt (instructions + contexte + question) avec le tokenizer du modèle, puis multipliez par le tarif indiqué par le fournisseur. Exemple illustratif avec des valeurs hypothétiques : 1 000 tokens × 0,000003 unité par token = 0,003 unité par requête. Vérifiez toujours le prix réel sur la grille tarifaire du modèle concerné, car il varie selon le modèle et la période.
Le prix par token est-il le même pour l'entrée et la sortie ?
Non, dans la plupart des offres, le prix par token de sortie est plus élevé que celui de l'entrée, car générer du texte coûte plus de calcul que le lire. Il faut donc calculer séparément le coût d'entrée (tokens du prompt × prix entrée) et le coût de sortie (tokens générés × prix sortie), puis les additionner pour obtenir le coût total d'une requête. Ne mélangez jamais les deux tarifs dans un même calcul.
Comment réduire le nombre de tokens de mes prompts ?
Plusieurs leviers concrets : raccourcir les instructions redondantes, supprimer les exemples inutiles, résumer le contexte long avant de l'envoyer, et éviter de coller des documents entiers quand un extrait suffit. Regrouper les tâches similaires en une seule requête bien structurée réduit aussi la répétition du contexte. Enfin, mesurez : comparez le nombre de tokens avant et après réécriture avec le tokenizer du modèle pour vérifier le gain réel.