Compteur de Tokens

Le compteur de tokens estime comment les modèles d’IA découpent un texte en unités de traitement. Un token n’est pas toujours un mot ni un caractère: il peut être un mot entier, une partie de mot, un signe de ponctuation, un comportement d’espace ou parfois un caractère isolé selon la langue. Le décompte sert à gérer les limites de contexte, les coûts, la conception de prompts, le découpage RAG, l’historique de conversation et la taille d’une requête. Chaque famille de modèles utilise son propre tokenizer, donc le résultat dépend du modèle. L’outil aide à raccourcir, segmenter ou structurer un texte avant envoi.

Les tokeniseurs LLM modernes utilisent des algorithmes de sous-mots — principalement Byte Pair Encoding (BPE) et SentencePiece — plutôt que de découper sur les espaces. Le BPE part de octets individuels et fusionne itérativement la paire adjacente la plus fréquente, produisant un vocabulaire fixe de typiquement 32k à 200k symboles. Les mots courants deviennent un seul token, les mots rares se décomposent en plusieurs sous-mots, et les octets arbitraires (emoji, caractères de contrôle) s'encodent sans problème car l'alphabet couvre les 256 octets. SentencePiece (utilisé par les variantes de Llama, Mistral, Gemini) traite l'espace comme un caractère ordinaire via le marqueur `▁`, de sorte que les espaces en début de mot font partie du token suivant, ce qui explique que ` hello` et `hello` ont généralement des identifiants de token différents. OpenAI publie trois vocabulaires BPE principaux via la bibliothèque `tiktoken` : `p50k_base` (50 281 tokens, GPT-3 / Codex), `cl100k_base` (100 277 tokens, GPT-3.5 Turbo et GPT-4), et `o200k_base` (~200k tokens, GPT-4o et o1) qui ajoute une couverture non anglaise et réduit le nombre de tokens chinois/japonais d'environ 1,4 à 1,7×. Claude utilise un tokeniseur propriétaire apparenté à une échelle de vocabulaire similaire. En ratios approximatifs de travail, le texte anglais compte en moyenne ~4 caractères par token, le chinois ~1,5 à 2 caractères par token sur cl100k_base et ~2 sur o200k_base, et un seul emoji consomme souvent 2 à 5 tokens car il est encodé en plusieurs octets UTF-8. Le nombre de tokens détermine à la fois l'utilisation de la fenêtre de contexte et le coût. Les fenêtres actuelles incluent GPT-4o 128k, Claude 3.5 Sonnet 200k et Gemini 1.5 Pro 2M ; le coût est facturé comme `tokens × prix_par_1M`, avec l'entrée et la sortie tarifées séparément (par ex. GPT-4o à 2,50 $/10,00 $ par 1M, Claude 3.5 Sonnet à 3,00 $/15,00 $). Ce compteur utilise des coefficients heuristiques par famille car inclure le fichier de vocabulaire de chaque tokeniseur représenterait des mégaoctets de données, donc le résultat est une estimation de travail — le chiffre faisant autorité est le champ `usage` de la réponse API du modèle.

• Le BPE fusionne les paires d'octets fréquentes en un vocabulaire fixe ; les vocabulaires OpenAI sont `cl100k_base` (GPT-4/3.5), `o200k_base` (GPT-4o/o1), `p50k_base` (Codex).
• SentencePiece encode l'espace initial comme `▁`, de sorte que ` world` et `world` correspondent à des identifiants de token différents dans Llama/Mistral/Gemini.
• Heuristique anglaise ≈ 4 car./token ; CJK ≈ 1,5 à 2 car./token sur cl100k_base, ≈ 2 sur o200k_base ; emoji typiquement 2 à 5 tokens chacun.
• Formule de coût : `(tokens_entrée / 1 000 000) × prix_entrée + (tokens_sortie / 1 000 000) × prix_sortie`, avec l'entrée et la sortie tarifées séparément.
• Fenêtres de contexte en 2025 : GPT-4o 128k, GPT-4 Turbo 128k, Claude 3.5 Sonnet 200k, Gemini 1.5 Pro 2M, DeepSeek V3 128k.
• Le même texte donne des nombres de tokens différents selon les fournisseurs : le vocabulaire du tokeniseur, les règles de repli sur les octets et la gestion des espaces diffèrent tous.
• Le chiffre faisant autorité est le champ `usage.prompt_tokens` / `usage.completion_tokens` (OpenAI) ou `usage.input_tokens` / `usage.output_tokens` (Anthropic) de la réponse API.