En amharique, une requête dans GPT-5 coûte 6 fois plus cher qu'en anglais : 78 tokens contre 13

Imaginez que vous lanciez un chatbot de support et que vous calculiez d'abord votre budget sur des textes anglais. Vous arrivez ensuite sur le marché éthiopien, et la même réponse à un client coûte soudain six fois plus cher. La cause : le tokenizer.

Il découpe le texte en morceaux (les tokens), et les fournisseurs de modèles facturent précisément les tokens, pas le sens. La coalition Coalition for Language Equity in AI Research (CLEAR) a publié la première étude qui mesure cet écart et l'appelle la « taxe du tokenizer ». Dans le tokenizer de GPT-5, une même phrase occupe 13 tokens en anglais, 26 en malayalam et 78 en amharique.

Les modèles ont reçu des notes de A à F, et GPT-5 a obtenu la pire : F. Si vous développez un produit qui ne s'adresse pas qu'à des utilisateurs anglophones, ces chiffres pèsent directement sur votre facture.

D'où vient la taxe

Les tokenizers ont été entraînés principalement sur l'anglais et une dizaine de langues bien dotées. Les mots anglais restent donc souvent des tokens entiers, tandis que le texte dans les langues moins représentées s'éparpille en petits fragments. Le sens est le même, mais il y a plus de tokens, et chacun se paie.

L'amharique souffre d'une cause supplémentaire : chaque caractère de l'écriture éthiopienne est découpé en deux tokens d'un octet chacun. Résultat, une requête en amharique revient environ six fois plus cher qu'en anglais, pour un contenu identique et un nombre de caractères quasi identique.

Les mesures ont été réalisées sur le jeu de phrases FLORES-200, et l'analyse couvre 203 paires langue-écriture. La métrique principale est le rapport entre le nombre de tokens de la langue la plus coûteuse et celui de la langue la moins chère. Les auteurs ont aussi calculé le coefficient de Gini, une mesure d'inégalité issue de l'économie, qui sert habituellement à décrire la répartition des revenus. L'échelle CLEAR est la suivante : jusqu'à 3 fois, A ; jusqu'à 6, B ; jusqu'à 9, C ; jusqu'à 12, D ; au-delà, F.

Qui obtient quelle note

Sur les vingt langues les plus représentées sur Internet, les modèles se distinguent à peine : l'écart va de 1,5 à 3,1 fois. Le problème apparaît sur l'ensemble des 200 langues. La note maximale A n'y est décrochée que par le modèle de traduction NLLB-200, conçu dès l'origine pour plus de 200 langues. Gemini et Gemma obtiennent un B. La pile chinoise (Qwen 3, DeepSeek V4.1 Flash et Kimi K3), ainsi que Fable 5, Opus 4.8 et Llama 4 Scout, reçoivent un D. GPT-5 écope d'un F.

L'écriture pèse plus lourd que le nombre de locuteurs. Les langues en alphabet latin sont plus économes, même quand elles sont peu répandues : l'asturien est absent des données de Common Crawl, mais il profite de l'alphabet latin et de sa parenté avec les langues romanes. Le birman, le tibétain, le tifinagh, le khmer, le lao et l'ol chiki sont les plus mal lotis. De grandes langues paient aussi cette taxe : l'ourdou (288 millions de locuteurs), le bengali (266 millions) et le pendjabi (200 millions).

Pas seulement une question de prix

Les auteurs relèvent deux autres conséquences de ce même gonflement du nombre de tokens. La première est la latence : pour un même texte, le modèle traite plus de tokens et la réponse arrive plus tard. La seconde est le contexte utile : dans les mêmes 128 mille tokens nominaux, une langue peu répandue ne laisse entrer qu'une partie du texte qui tiendrait en entier en anglais.

En transposant grossièrement le rapport de 78 à 13, la fenêtre d'un modèle ne contiendrait en amharique qu'environ un sixième du volume anglais. Il s'agit de notre propre estimation arithmétique : le rapport ne contient pas ce chiffre. Pour le RAG et les longs documents, cela signifie qu'il faudra les découper plus tôt et que davantage de contexte sera perdu.

Que faire en pratique

CLEAR demande trois choses aux éditeurs : publier les deux métriques dans les fiches de leurs modèles, intégrer la part des langues dans le vocabulaire de la prochaine génération de tokenizers et, puisqu'on ne peut pas changer de tokenizer avant l'entraînement d'un nouveau modèle de base, normaliser dès maintenant les prix par caractère.

Pour les développeurs et les product managers, les conseils sont plus simples :

• ne calculez pas votre budget sur un prototype anglais : passez vos textes réels dans le tokenizer du modèle visé et regardez le multiplicateur ;
• comparez les fournisseurs non seulement sur le prix par million de tokens, mais aussi sur le nombre de tokens que consomme votre langue ;
• prévoyez une marge de latence et de fenêtre de contexte pour les langues au découpage inefficace ;
• le code du test est disponible dans le dépôt ouvert du projet et peut être exécuté sur d'autres modèles.

Ce n'est que la première partie du travail : elle mesure le nombre de tokens sur de courtes phrases, pas la qualité des réponses. CLEAR promet de publier plus tard la suite, consacrée à l'égalité de qualité entre les langues.