Comment fonctionne réellement la tokenisation GPT (et pourquoi votre facture en dépend)

Chaque appel API à un grand modèle de langage est comptabilisé en tokens— ni en caractères ni en mots. Les tokens sont l’unité que le modèle consomme réellement après que le texte est encodé par un tokeniseurbyte-pair encoding(BPE). Comprendre comment fonctionne la tokenisation est important car (a) cela détermine votre facture, et (b) c’est pourquoi “un document de 1 000 mots” ne correspond pas proprement à “un coût estimé de 1 000 tokens”.

Comment fonctionnent les tokeniseurs BPE

L’algorithme en quelques lignes :

1. Commencer avec un vocabulaire d’octets individuels (256 entrées).
2. Trouver la paire adjacente la plus fréquente d’entrées de vocabulaire dans un grand corpus d’entraînement.
3. Ajouter cette paire comme nouvelle entrée de vocabulaire.
4. Répéter jusqu’à ce que le vocabulaire atteigne la taille cible (50k-100k entrées pour les modèles modernes).
5. Pour tokeniser un nouveau texte, remplacer avidement les paires de la correspondance la plus longue à la plus courte.

Résultat : les mots anglais courants comme “the”, “and”, “understanding” deviennent chacun un seul token. Les mots rares se divisent en 2-4 tokens. Les emojis et les caractères non anglais prennent souvent 2-6 tokens chacun.

Comptages de tokens pour du contenu courant

Comptages approximatifs de tokens pour GPT-4 (tokeniseur cl100k_base) :

Le chiffre de référence pour l’anglais est de ~750 mots par 1 000 tokens. Les scripts non latins coûtent significativement plus de tokens par caractère parce qu’ils n’étaient pas aussi densément représentés dans le corpus d’entraînement.

Pourquoi l’écart de coût est important

La tarification par token signifie que le contenu non anglais coûte 2-4× plus cher pour la même idée. Un document de 1 000 mots coûte :

• Anglais : ~1 300 tokens → 0,013 $ au prix d’entrée GPT-4o (~10 $/M tokens).
• Russe : ~3 500 tokens → 0,035 $ (2,7× plus pour le même contenu).
• Chinois : ~1 500 tokens (par caractère, les scripts denses compensent légèrement) → 0,015 $.

Pour une entreprise de traduction ou un système de support multilingue, l’asymétrie de coût par langue se compose rapidement. Anthropic, OpenAI et Google publient des coûts de tokens par modèle ; le coût réel du contenu dépend de la langue et du format pour lequel vous payez.

Différences de tokeniseurs entre les modèles

Chaque famille de modèles a son propre tokeniseur :

• OpenAI cl100k_base (GPT-3.5, GPT-4) : ~100 000 entrées de vocabulaire. Le tokeniseur anglais moderne de référence.
• OpenAI o200k_base (GPT-4o, série o) : 200 000 entrées de vocabulaire. Meilleur pour le non-anglais et le code. Un document donné nécessite ~10-15% moins de tokens que cl100k.
• Tokeniseur Anthropic Claude :propriétaire. Densité approximativement similaire à cl100k pour l’anglais ; diffère de manière mesurable pour le code et le non-anglais. Anthropic publie un point de terminaison de comptage de tokens pour estimer avant de soumettre.
• Google Gemini : utilise SentencePiece. Densité approximativement comparable à cl100k.

Implication : le même prompt envoyé à GPT-4o vs Claude vs Gemini ne produit pas des comptages de tokens identiques. La budgétisation entre fournisseurs nécessite une estimation de tokens par fournisseur, pas une règle universelle “1 mot ≈ 1,3 tokens”.

Où la tokenisation affecte la conception du prompt

1. Coûts de contexte long.Une fenêtre de contexte de 100k tokens contenant toute votre documentation est excellente jusqu’à ce que vous réalisiez que le coût par appel est de 1 $+ pour une utilisation typique.
2. JSON vs langage naturel. Demander une sortie JSON coûte ~30-50% plus de tokens que demander une prose comparable. La ponctuation de JSON est tokenisée agressivement.
3. Tâches de code. Le code est environ 2× plus dense en tokens que la prose. Un fichier de 200 lignes peut représenter 2 000-3 000 tokens.
4. Langues non anglaises.2-4× plus de tokens par caractère. Pour les produits multilingues, c’est un coût de premier ordre.

Comment estimer les tokens avant de payer

1. Utiliser un outil de comptage de tokens. Notre compteur de tokens AI implémente plusieurs tokeniseurs et rapporte le compte exact pour votre entrée.
2. Utiliser la bibliothèque officielle de tokeniseurs. Le tiktokend’OpenAI (Python), l’API de tokeniseur d’Anthropic ou des compteurs de tokens hébergés. Ce sont les vérités de terrain pour la facturation.
3. Règle de base. Pour la prose en anglais : 1 mot ≈ 1,3 tokens. Pour le code : 1 ligne ≈ 8-15 tokens. Pour le chinois : 1 caractère ≈ 1,5 tokens.
4. Budgétiser aussi la sortie.De nombreux fournisseurs facturent plus pour la sortie que l’entrée (typiquement 3-5× par token). Une sortie de 2 000 tokens est plus coûteuse qu’une entrée de 2 000 tokens.

La raison structurelle profonde du BPE

Les LLM modernes voient des tokens, pas des caractères. Les embeddings, l’attention et la sortie du modèle sont tous définis sur un vocabulaire fini de tokens. Les modèles au niveau du caractère existent mais sont plus lents (chaque caractère est une position d’entrée) et plus difficiles à entraîner. Les modèles au niveau du mot ne peuvent pas gérer les mots non vus (problème hors vocabulaire). BPE est le compromis qui a gagné.

Pour plus de contexte, consultez notre entrée du glossaire token GPT et le guide sur le fonctionnement de la tarification des tokens.

Walkthrough : tokeniser une seule phrase

Phrase : “The rambunctious cat’s purr 😺 was unmistakable.”(9 mots, 49 caractères avec l’emoji.)

Sous cl100k_base (GPT-4) :

• The → 1 token.
• rambunctious → 3 tokens ( ram + bunct + ious).
• cat → 1 token.
• ’s → 1 token.
• purr → 1 token.
• 😺 → 3 tokens (les octets UTF-8 de l’emoji se divisent en plusieurs pièces BPE).
• was → 1 token.
• unmistakable → 2 tokens.
• . → 1 token.

Total : 14 tokens pour 9 mots — un ratio de 1,56 tokens par mot dopé par rambunctious(3 tokens) et l’emoji (3 tokens). Les remplacer par des alternatives courantes réduit le coût : “The loud cat’s purr was unmistakable” tourne à ~9 tokens pour la même idée. Pour une utilisation d’API à volume élevé, ce type d’ingénierie du vocabulaire se compose.

Erreurs courantes

• Estimer les tokens à partir du nombre de caractères.La règle de base “1 token ≈ 4 chars” est très inexacte pour le code, le JSON et le non-anglais. Un blob JSON de 1 000 chars peut être 400-800 tokens selon les noms de clés et l’imbrication.
• Oublier les tokens du prompt système.Un prompt système de 2 000 tokens est inclus dans chaque requête et facturé à chaque appel. Les agents multi-tours avec un historique de conversation croissant paient l’intégralité de la conversation précédente à chaque tour.
• Les avantages du cache dépendent de la stabilité du préfixe.La mise en cache du prompt (quand disponible) ne s’active que lorsque la séquence de tokens est identique au niveau des octets au préfixe. Mettre le contenu dynamique à la fin, pas au milieu.
• Utiliser le mauvais tokeniseur pour l’estimation des coûts. cl100k_base et o200k_base produisent ~10-15% de comptages de tokens différents pour la même entrée.
• Supprimer agressivement les espaces. De nombreux tokens commencent par un espace initial. Supprimer tous les espaces et concaténer les mots peut produireplus de tokens, pas moins.