Combien de tokens compte mon prompt ?

Les modèles de langage ne lisent ni caractères ni mots. Ils lisent des tokens : des fragments obtenus en découpant le texte selon un vocabulaire fixe appris sur les données d'entraînement.

Les mots courants forment généralement un seul token. Les mots rares sont découpés en morceaux. Les espaces sont en général rattachés au début du token suivant, ce qui explique qu'un même mot puisse compter différemment selon qu'il ouvre ou non une phrase.

Mesuré avec le tokeniseur de GPT-4o, le mot unbelievable pris isolément compte trois tokens : un + bel + ievable. Écrit tel qu'il apparaît réellement dans une phrase, avec l'espace qui le précède, il n'en vaut plus qu'un seul : unbelievable. C'est la règle de l'espace initial qui joue : l'entrée apprise par le modèle est la forme précédée d'un espace, parce que c'est ainsi que le mot se présente presque toujours dans un texte suivi. the et international se comportent de la même façon, un token chacun avec l'espace attaché.

C'est pourquoi les comptages de tokens semblent imprévisibles. L'unité n'est pas linguistique, elle est statistique. C'est la fréquence dans le corpus d'entraînement qui décide si quelque chose vaut un token ou quatre.

Pour la prose anglaise, mesuré avec le tokeniseur de GPT-4o sur des registres allant de l'écrit conversationnel à la référence technique :

• 1 token ≈ 4,3 à 5,9 caractères
• 1 token ≈ 0,75 à 0,95 mot
• 1 000 mots ≈ 1 050 à 1 350 tokens
• Une page standard (~500 mots) ≈ 530 à 680 tokens

Le registre pèse plus lourd que ne l'admettent la plupart des ordres de grandeur. L'écrit familier, conversationnel, se situe près du bas de cette fourchette, autour de 1 060 tokens pour mille mots, parce qu'il réemploie un petit vocabulaire de mots courants qui tiennent chacun dans un seul token. La prose technique dense — y compris les guides de ce site — se situe près du haut, autour de 1 310, parce que les termes spécialisés sont découpés en morceaux. Le chiffre unique que tout le monde cite, 1 300 tokens pour mille mots, correspond à l'extrémité technique de la fourchette et non à son milieu : il surestime donc d'environ un cinquième un texte ordinaire. C'est le bon sens de l'erreur quand on dimensionne une fenêtre de contexte.

Ces repères s'effondrent vite hors de la prose ordinaire :

Type de contenu	Ordre de grandeur
Prose anglaise	0,75 à 0,95 mot par token, selon le registre
Code	Environ 1,2 fois plus de tokens que la prose à nombre de caractères égal, et environ 1,5 fois pour une même idée exprimée des deux façons
JSON avec de longues clés	Très élevé — ponctuation et guillemets sont des tokens séparés
Chinois, japonais, coréen	Environ 0,6 à 0,7 token par caractère — moins d'un token chacun, mais plusieurs fois ce que l'anglais dépense pour le même nombre de caractères
Cyrillique, devanagari, arabe	Environ 1,4 à 1,6 fois l'anglais pour un même texte
URL et empreintes de hachage	Extrêmement élevé — les chaînes aléatoires se tokenisent mal
Espaces répétés	Bon marché plutôt que coûteux — le byte-pair encoding fusionne les longues séries, si bien que quarante espaces consécutifs ne forment qu'un seul token

L'écart multilingue est réel, mais bien plus faible que ne le veut la légende. Mesuré sur les pages anglaises de ce site face à leurs traductions professionnelles, la version japonaise coûte environ 1,7 fois l'anglaise, la coréenne environ 1,5 fois, la chinoise environ 1,2 fois, la hindie environ 1,6 fois et l'arabe environ 1,4 fois. Avec l'ancien tokeniseur cl100k_base, les mêmes paires atteignaient 2,3, 2,3, 1,7, 4,7 et 2,9 fois — d'où le chiffre répété partout de « deux à trois fois l'anglais ». Il était exact à l'époque ; les vocabulaires récents ont largement comblé l'écart.

Chaque famille de modèles utilise son propre tokeniseur avec son propre vocabulaire : un même texte donne donc des comptages différents.

Les modèles GPT s'appuient sur des variantes du byte-pair encoding — cl100k_base pour les modèles de l'ère GPT-4, o200k_base pour les plus récents. Claude utilise un tokeniseur différent, avec un vocabulaire différent. Les modèles ouverts comme Llama et Mistral ont chacun le leur.

C'est sur le code et les textes non anglais que les vocabulaires divergent le plus : c'est donc là que les comptages divergent le plus, eux aussi.

Concrètement :

• Un comptage issu d'un tokeniseur est une estimation pour tout autre modèle.
• Seul le tokeniseur du fournisseur donne le chiffre exact utilisé pour sa facturation.
• Prévoyez une marge plutôt que de viser exactement la limite.

Notre Compteur de tokens affiche côte à côte un comptage GPT-4o et une estimation Claude. Le chiffre GPT-4o est un vrai comptage de tokeniseur. Le chiffre Claude, délibérément, n'en est pas un : Anthropic ne publie aucun tokeniseur exécutable dans votre navigateur, il s'agit donc d'une estimation fondée sur les caractères, à raison d'un token pour 3,5 caractères. Sur de la prose anglaise, cette estimation se situe 22 à 50 % au-dessus du comptage GPT-4o — environ un tiers pour un texte courant — lisez donc l'écart comme la marge d'une estimation, et non comme une différence mesurée entre les deux familles de modèles. Le duo suffit malgré tout à savoir si un prompt est confortablement sous la limite ou dangereusement proche ; quand le chiffre doit être exact, utilisez le compteur du fournisseur lui-même.

Le coût. La tarification des API se fait par token, entrée et sortie facturées séparément, la sortie coûtant généralement plusieurs fois plus cher. Doubler un prompt système double ce coût à chaque appel — le genre de détail invisible en test et très coûteux en volume.

Les limites de contexte. La fenêtre englobe tout : prompt système, historique de conversation, documents récupérés, message courant et espace réservé à la réponse. Les longues conversations échouent non parce qu'un message est long, mais parce que l'historique s'accumule.

La troncature. Quand l'entrée dépasse la limite, quelque chose est abandonné — souvent silencieusement, et souvent le contenu le plus ancien. Un modèle qui a « oublié » vos instructions les a fréquemment vues tronquées.

Le découpage pour la recherche. Le découpage de documents pour l'embedding se fait en tokens, pas en caractères. Des morceaux dimensionnés en caractères deviennent incohérents, et ceux coupés en pleine phrase se récupèrent mal : une chaîne de recherche a donc besoin d'un découpeur qui respecte la structure des phrases et des paragraphes. Notre Découpeur de texte n'est pas cet outil : il produit des morceaux de taille fixe d'au plus 2 000 caractères, coupés à l'espace le plus proche pour qu'aucun mot ne soit tranché en deux, ce qui implique qu'un morceau peut se terminer en pleine phrase. Utilisez-le pour faire tenir un long document dans une fenêtre de contexte ou sous une limite de collage — pas pour produire des morceaux d'embedding destinés à la recherche.

Les réductions les plus efficaces, à peu près par ordre d'impact :

1. Allégez l'historique de conversation. Dans une longue discussion, il écrase tout le reste. Résumez les anciens échanges plutôt que de les renvoyer tels quels.
2. Supprimez les instructions redondantes. Répéter une règle de trois façons ne la fait pas trois fois mieux respecter. Cela triple simplement son coût.
3. Éliminez les artefacts de mise en forme. Caractères invisibles, espaces répétés et lignes de séparation décoratives consomment des tokens. Pris isolément, ils coûtent moins cher qu'on ne le croit, car le byte-pair encoding fusionne les longues séries : quarante espaces consécutifs ne font qu'un seul token, et une ligne de séparation de quarante traits d'union en fait deux, contre treize pour la phrase au-dessus. Cela reste du pur surcoût, et dans un document où chaque section est précédée d'un filet, l'addition finit par se voir. Supprimer les caractères invisibles nettoie ceux que vous ne voyez pas.
4. Raccourcissez les clés JSON dans les prompts structurés. {"n": ...} contre {"customer_full_name": ...}, multiplié par mille enregistrements, fait une grande différence.
5. N'envoyez que les extraits pertinents. Récupérer trois paragraphes utiles vaut mieux que coller un document entier, et produit en général des réponses à la fois meilleures et moins chères.

Ce qui n'aide pas : retirer la ponctuation ordinaire, supprimer les articles ou écrire dans un style télégraphique haché. Les économies sont marginales et les dégâts sur la qualité des réponses ne le sont pas.