Les tokens sont des fragments de mots : leur nombre ne correspond jamais au nombre de mots. En anglais courant, un token représente en moyenne quatre caractères ou trois quarts de mot, soit environ 1 300 tokens pour 1 000 mots. Le code, les écritures non latines et les mots rares consomment davantage de tokens par caractère, parfois plusieurs fois plus.
Ce qu'est réellement un token
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.
Le mot unbelievable n'est pas un seul token : il est probablement découpé en quelque chose comme Un + believ + able. À l'inverse, the est un token unique, tout comme international, apparu assez souvent à l'entraînement pour mériter sa propre entrée.
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.
37 caractères · 7 tokens · environ 5,3 caractères par token
Règle approximative en anglais : 1 token ≈ 4 caractères ≈ 0,75 mot.
Le code, les écritures non anglaises et les mots rares consomment plus de tokens par caractère.
Des ordres de grandeur fiables
Pour la prose anglaise :
- 1 token ≈ 4 caractères
- 1 token ≈ 0,75 mot
- 1 000 mots ≈ 1 300 tokens
- Une page standard (~500 mots) ≈ 650 tokens
Ces repères s'effondrent vite hors de la prose ordinaire :
| Type de contenu | Ordre de grandeur |
|---|---|
| Prose anglaise | 0,75 mot par token |
| Code | 2 à 3 fois plus de tokens qu'une prose équivalente |
| JSON avec de longues clés | Très élevé — ponctuation et guillemets sont des tokens séparés |
| Chinois, japonais, coréen | Souvent 1 à 2 tokens par caractère |
| Cyrillique, devanagari, arabe | En général 2 à 3 fois l'anglais à sens égal |
| URL et empreintes de hachage | Extrêmement élevé — les chaînes aléatoires se tokenisent mal |
| Espaces répétés | Chaque série peut former son propre token |
L'écart multilingue est important et sous-estimé : une même phrase en japonais peut coûter plusieurs fois son équivalent anglais, ce qui pèse à la fois sur le coût et sur ce qui tient dans la fenêtre de contexte.
Pourquoi le comptage varie d'un modèle à l'autre
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.
Des écarts de 10 à 20 % entre familles sur un même texte anglais sont normaux, et l'écart se creuse sur le code et les textes non anglais, là où les vocabulaires divergent le plus.
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, ce qui suffit en général à savoir si un prompt est confortablement sous la limite ou dangereusement proche.
Pourquoi ce chiffre compte
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. Pour diviser un long texte en morceaux exploitables, le Découpeur de texte coupe près des limites de paragraphes plutôt qu'au milieu des mots.
Réduire le comptage sans perdre le sens
Les réductions les plus efficaces, à peu près par ordre d'impact :
- 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.
- 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.
- É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, et une rangée de quarante traits d'union peut coûter plus cher que la phrase au-dessus. Supprimer les caractères invisibles nettoie ceux que vous ne voyez pas.
- Raccourcissez les clés JSON dans les prompts structurés.
{"n": ...}contre{"customer_full_name": ...}, multiplié par mille enregistrements, fait une grande différence. - 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.
Questions fréquentes
Combien de tokens représentent 1 000 mots ?
Environ 1 300 tokens pour de la prose anglaise ordinaire, sur la base de 0,75 mot par token. Le code, le JSON et les textes non anglais montent nettement plus haut — le chinois, le japonais et le coréen consomment souvent un à deux tokens par caractère.
Pourquoi le comptage diffère-t-il entre GPT et Claude ?
Chaque famille de modèles utilise son propre tokeniseur avec un vocabulaire appris différemment, donc le même texte se découpe autrement. Des écarts de 10 à 20 % sur la prose anglaise sont normaux, et plus marqués sur le code et les textes non anglais.
Qu'est-ce qu'un token dans un modèle d'IA ?
Un fragment de texte issu du vocabulaire fixe du modèle. Les mots courants forment généralement un seul token tandis que les mots rares se découpent en plusieurs morceaux : « unbelievable » peut devenir trois tokens alors qu'« international » n'en vaut qu'un.
Les espaces et la ponctuation comptent-ils comme des tokens ?
Oui. Les espaces sont normalement rattachés au début du token suivant, et la ponctuation est fréquemment un token à part entière. De longues séries d'espaces ou des lignes de séparation décoratives peuvent consommer un nombre surprenant de tokens.
Comment réduire ma consommation de tokens ?
Allégez d'abord l'historique accumulé — il domine tout le reste dans les longues conversations. Supprimez ensuite les instructions dupliquées, nettoyez les caractères invisibles et les espaces répétés, raccourcissez les clés JSON et n'envoyez que l'extrait pertinent d'un document plutôt que le document entier.