La taxe de tokenisation LLM : Comment la langue change le coût et le contexte de l'IA

La taxe de tokenisation LLM est un coût mesurable et une pénalité de contexte. Deux invites peuvent avoir le même sens tout en consommant des nombres de tokens très différents parce qu'elles utilisent des langues différentes.

Une étude de juillet 2026 a testé 997 phrases alignées à travers six tokenizers. Avec l'encodage plus ancien `cl100k_base` d'OpenAI, dix langues indiennes avaient une taxe de fertilité des mots moyenne de 8,0 fois par rapport à l'anglais. Le malayalam a atteint 13,04 fois. Le nouveau `o200k_base` a réduit la moyenne à 2,1 fois. L'étude ne prouve pas que la tokenisation seule cause de pires réponses. Elle montre que le prix et le contexte utilisable peuvent diverger avant qu'un modèle commence à raisonner.

Public cible : Intermédiaire

Réponse directe : Ne pas estimer un produit IA multilingue à partir des comptes de tokens en anglais. Tester le tokenizer exact sur un texte de production aligné, mesurer l'ensemble de la demande, évaluer la qualité séparément, et relancer le test chaque fois que le modèle ou le tokenizer change.

Ce que mesure la taxe de tokenisation LLM

Les modèles de langue reçoivent des ID de tokens, pas des mots ou des caractères. Un tokenizer divise le texte en unités de tokens et les mappe à des ID ; certains tokenizers normalisent d'abord le texte. Des fragments communs peuvent tenir dans un token. Les scripts ou formes de mots moins représentés peuvent se diviser en plusieurs tokens ou octets.

La métrique principale du document est la fertilité des mots : tokens par mot délimité par des espaces. Sa taxe de tokenisation est la fertilité des mots d'une langue divisée par la fertilité des mots en anglais sous le même tokenizer.

Pour un écran de production, un ratio de compte de tokens alignés est souvent plus facile à utiliser :

text ratio de compte de tokens alignés pour la langue L = tokens pour le contenu aligné dans la langue L ÷ tokens pour la version anglaise

Ces métriques répondent à des questions connexes, mais elles ne sont pas interchangeables. Nommez la métrique que vous rapportez. Les deux comparaisons nécessitent un texte sémantiquement aligné. Compter des phrases non liées, ou une liste de mots communs, peut produire un chiffre attrayant qui en dit peu sur une application réelle.

Les chercheurs utilisent également la fertilité, souvent définie comme des tokens par mot. La fertilité des mots est intuitive, mais les frontières des mots ne sont pas également claires à travers les langues. Ajoutez la fertilité des caractères, les octets par token, et la part des octets non fusionnés lorsque vous devez diagnostiquer pourquoi un écart existe.

Cette distinction est importante car le compte de tokens a plusieurs conséquences différentes :

La dernière ligne est la plus facile à exagérer.

Ce que la recherche de 2026 a trouvé

La nouvelle étude sur la taxe de tokenisation a utilisé des phrases alignées de FLORES-200. Elle a comparé dix langues indiennes avec l'anglais, l'arabe, l'espagnol et le français à travers six tokenizers. Les auteurs ont mesuré la fertilité des mots et des caractères, les octets par token, les tokens à un octet non fusionnés, et la quantité de texte source qui a survécu à un budget de contexte fixe.

Trois résultats sont importants pour les décisions d'ingénierie :

Les langues à forte taxe ont produit des tokens à un octet non fusionnés pour 27 à 43 % de leurs tokens. À travers les langues échantillonnées avec des frontières de mots valides, ce taux était corrélé avec la taxe de fertilité des mots à `r = 0.89`. Les auteurs attribuent l'écart à une couverture de vocabulaire insuffisante pour ces scripts.

Un article de NeurIPS 2023 a trouvé des différences de longueur de tokenisation allant jusqu'à 15 fois entre les langues. Une étude EMNLP 2023 a mesuré le coût et l'utilité à travers 22 langues et a découvert que la tarification API basée sur les tokens peut facturer certaines communautés linguistiques plus pour un contenu comparable.

Des travaux récents montrent également que l'écart est un choix de conception, pas une propriété inévitable d'un script. L'encodage par paires d'octets conscient de la parité (BPE) change l'objectif de fusion pour aider la langue actuellement la moins compressée. Ses auteurs rapportent jusqu'à 89 % de réduction de l'inégalité des coûts de tokens, mesurée avec un coefficient de Gini interlangue, avec peu de changement dans la compression globale. Une étude contrôlée séparée à travers 11 langues d'Asie du Sud-Est a placé le BPE conscient de la parité sur le front de Pareto efficacité-équité pour des modèles de base comparables de 1,5 milliard de paramètres. Ce résultat n'établit pas le même compromis à l'échelle de pointe ou après alignement.

La revendication de précision nécessite de la retenue

L'étude de juillet a trouvé une corrélation brute de `r = -0.61` entre la fertilité et la précision de compréhension de lecture pour 13 points linguistiques. Après contrôle du niveau de ressources linguistiques, la corrélation partielle est devenue `r = 0.25`.

Il y a plus de raisons d'éviter un titre causal : les chiffres de fertilité et les scores de précision provenaient de paramètres de tokenizer/modèle différents, l'échantillon était petit, et les phrases de référence traduites ne constituent pas une charge de travail de production. Le document soutient des revendications fortes concernant les comptes de tokens, le contexte et les coûts basés sur les tokens. Il n'isole pas la fertilité du tokenizer comme cause de la qualité inférieure des réponses.

Mesurez votre propre coût de token multilingue

La recherche donne un avertissement, pas votre ratio de production. Un assistant de support, un système de récupération ou un agent de codage a son propre mélange de langues et structure d'invite.

Utilisez ce flux de travail avant le lancement et après chaque changement de modèle.

1. Construire un échantillon aligné

Pour un écran initial, collectez 100 à 1 000 exemples de la charge de travail que vous attendez :

Utilisez des traductions révisées du même sens. Conservez un ID qui relie chaque variante linguistique. Ne comparez pas du texte aléatoire extrait de corpus linguistiques séparés. Cette plage de filtrage n'est pas un minimum statistique : l'échantillon requis dépend du nombre de langues, de la variance de la charge de travail et de la précision avec laquelle vous devez estimer le comportement des queues.

Stockez l'échantillon sous forme de JSON Lines :

{"id":"support-001","language":"en","text":"Texte anglais révisé"} {"id":"support-001","language":"sv","text":"Traduction suédoise révisée"} {"id":"support-001","language":"tr","text":"Traduction turque révisée"}

2. Fixer le tokenizer

Le tokenizer appartient à une version de modèle. Enregistrez les deux. Le `dépôt tiktoken` officiel d'OpenAI expose `cl100k_base` et `o200k_base` ; sa cartographie de modèle montre également que les familles de modèles peuvent utiliser différents encodages. Pour un modèle fermé, préférez le compteur officiel du fournisseur lorsqu'il existe. L'API Gemini de Google, par exemple, expose une méthode `countTokens`. Pour un modèle ouvert, chargez l'artéfact exact avec le pipeline de tokenizer documenté du modèle, tel que celui décrit dans la documentation de l'API Tokenizers de Hugging Face.

Ne supposez pas que deux modèles du même fournisseur partagent un tokenizer. Ne supposez pas qu'une bibliothèque locale connaît déjà un modèle publié hier.

3. Calculer une distribution, pas un seul ratio

Installez et fixez le compteur :

bash python -m pip install "tiktoken==0.13.0"

Puis exécutez :

python import json from collections import defaultdict from math import ceil from statistics import mean, median

import tiktoken

BASELINE = "en" ENCODINGS = ("cl100k_base", "o200k_base")

groups = defaultdict(dict) with open("aligned-samples.jsonl", encoding="utf-8") as source: for line in source: row = json.loads(line) groups[row["id"]][row["language"]] = row["text"]

def percentile(values, probability): ordered = sorted(values) index = max(0, ceil(len(ordered) * probability) - 1) return ordered[index]

for encoding_name in ENCODINGS: encoding = tiktoken.get_encoding(encoding_name) counts = defaultdict(list) ratios = defaultdict(list)

for sample_id, variants in groups.items(): if BASELINE not in variants: raise ValueError(f"{sample_id} n'a pas de référence {BASELINE}")

baseline_tokens = len(encoding.encode(variants[BASELINE])) if baseline_tokens == 0: raise ValueError(f"{sample_id} a une référence vide")

for language, text in variants.items(): token_count = len(encoding.encode(text)) counts[language].append(token_count) ratios[language].append(token_count / baseline_tokens)

for language in sorted(counts): print( encoding_name, language, f"mean_tokens={mean(counts[language]):.1f}", f"mean_ratio={mean(ratios[language]):.2f}x", f"median_ratio={median(ratios[language]):.2f}x", f"p95_ratio={percentile(ratios[language], 0.95):.2f}x", f"max_ratio={max(ratios[language]):.2f}x", sep="\t", )

La moyenne peut cacher quelques longues demandes qui débordent la fenêtre de contexte. Inspectez p50 (la médiane), p95 (le 95e percentile), et le maximum avant d'utiliser le résultat dans un plan de capacité.

*Mesurez le texte de production aligné avec le tokenizer déployé, puis utilisez la distribution pour définir les limites de coût et de contexte. La qualité reste une évaluation séparée.*

4. Mesurer la demande complète

Le message utilisateur visible n'est qu'une partie d'un appel API. Incluez :

C'est particulièrement important pour les agents. Un grand schéma d'outil JSON peut dominer une courte demande utilisateur. Un passage RAG localisé peut dominer une invite système en anglais. Mesurez la demande finale sérialisée chaque fois que le fournisseur expose cette représentation.

5. Convertir les tokens en limites opérationnelles

Pour une API simple tarifée par token :

text coût d'entrée mensuel = appels mensuels × tokens d'entrée moyens × prix par million de tokens ÷ 1 000 000

Supposons qu'une API hypothétique facture 1 $ par million de tokens d'entrée. Un million de demandes à 1 000 tokens d'entrée coûtent 1 000 $. Si les demandes alignées dans une autre langue moyennent 2 500 tokens, la portion d'entrée devient 2 500 $ avant le cache ou les remises.

Le contexte nécessite un calcul séparé :

text budget d'entrée utilisable = w fenêtre de contexte

Appliquez le ratio de langue observé à la portion de contenu, pas aveuglément à l'ensemble de la demande.

Le guide des coûts de tokens de raisonnement IA explique pourquoi les budgets de tokens ont besoin d'une limite produit, pas seulement d'une limite modèle. Pour les systèmes RAG et de codage, la conception de contexte inter-référentiels montre pourquoi envoyer plus de contexte n'est pas automatiquement utile. Si le choix de l'API est encore ouvert, l'étude de cas sur les API IA gratuites fournit un cadre de comparaison plus large.

Définir une porte d'acceptation multilingue

Un ratio de tokens plus bas n'est utile que si le modèle répond toujours à l'exigence du produit. Utilisez quatre portes séparées :

Pour un système RAG multilingue, segmentez par le tokenizer déployé plutôt que par un compte de caractères partagé. Pour un agent, mesurez les traces d'outils et les nouvelles tentatives ainsi que la première demande. Pour un produit de support, suivez le coût par cas résolu, pas le coût par appel. Ces choix empêchent la métrique de tokens de devenir un benchmark de vanité.

Utilisez une route spécifique à la langue uniquement lorsque cela améliore le tableau de bord complet. Un tokenizer moins cher associé à un modèle plus faible peut économiser des tokens d'entrée et augmenter les nouvelles tentatives. Une fenêtre de contexte plus grande peut cacher un mauvais fractionnement jusqu'à ce que la facture augmente. L'unité correcte est la tâche utilisateur complétée.

Ce que les équipes peuvent changer

Les équipes d'application ne peuvent pas réentraîner le tokenizer d'un modèle commercial, mais elles ont toujours des options :

Les équipes qui forment leurs propres modèles ont un choix plus profond. Les résultats du BPE conscient de la parité suggèrent qu'un objectif de tokenizer peut réduire l'inégalité interlangue sans sacrifier beaucoup de compression globale. L'étude sur l'Asie du Sud-Est ajoute des preuves contrôlées que l'équité et l'efficacité ne doivent pas nécessairement évoluer dans des directions opposées.

Traitez le tokenizer comme une partie du contrat du modèle. Versionnez-le, évaluez-le et incluez-le dans les examens de migration.

Limites des preuves

La plus récente étude est un préprint. Elle utilise des phrases traduites de FLORES-200, un ensemble modeste de langues, et une métrique de mots basée sur des espaces qui ne s'adapte pas également bien à chaque système d'écriture. Sa méthode de détection d'octets est spécifique au tokenizer.

La conclusion la plus forte est indépendante du modèle : lorsque une langue alignée produit plus de tokens, elle obtient moins de texte dans une fenêtre de tokens fixe. La conclusion sur le coût tient lorsque un fournisseur facture ces tokens supplémentaires au même prix unitaire. Les politiques de cache et les remises de volume peuvent changer la facture finale.

La précision nécessite son propre test. La couverture des données d'entraînement, l'architecture du modèle, la conception de l'évaluation après entraînement et le contexte culturel affectent tous les résultats. La fertilité des tokens peut contribuer à un écart, mais le document de juillet n'isole pas cet effet causal.

Liste de contrôle du tokenizer multilingue

Questions fréquentes

Pourquoi certaines langues utilisent-elles plus de tokens LLM ?

Les vocabulaires de sous-mots reflètent leurs données d'entraînement et les règles de fusion. Les fragments anglais courants sont souvent représentés efficacement, tandis que les scripts moins représentés peuvent être divisés en morceaux plus petits ou en octets. La taille de l'écart dépend du tokenizer exact et du texte.

Un nombre de tokens plus élevé signifie-t-il une réponse pire ?

Non. Cela affecte directement le coût basé sur les tokens et la quantité de texte qui tient dans une fenêtre de tokens. Cela ne prouve pas une qualité de réponse inférieure. Testez la qualité séparément sur des exemples révisés dans chaque langue.

Comment puis-je compter les tokens avant un appel API ?

Utilisez le point de terminaison de comptage officiel du fournisseur lorsqu'il est disponible. Pour les encodages OpenAI, `tiktoken` peut compter localement. Pour les modèles ouverts, chargez l'artéfact exact du tokenizer expédié avec le modèle. Fixez les versions afin qu'une mise à jour ultérieure ne change pas silencieusement la mesure.

Changer de modèle peut-il supprimer la taxe de tokenisation ?

Cela peut réduire l'écart. L'étude de juillet a trouvé une grande amélioration entre `cl100k_base` et `o200k_base`. Un changement de modèle modifie également la qualité, le coût de sortie, le cache, la latence et le comportement opérationnel, donc comparez la charge de travail complète plutôt que les comptes de tokens seuls.

Sources

Vérifications des revendications

| Une taxe de tokenizer plus élevée cause une précision de réponse inférieure | Non établi | L'analyse ajustée du document de juillet n'a pas soutenu une lecture causale simple.