Quel LLM est le moins cher par langue ? Coûts de tokenisation

Aucun LLM n’est systématiquement le moins cher pour un texte multilingue. Sur un même passage, GPT-5.5 facture le moins de tokens pour les langues européennes, l’hindi et le coréen, Kimi K2.5 pour le chinois, et DeepSeek pour le japonais. Claude Fable 5, Opus 4.8 et Sonnet 5 partagent le même tokenizer : tous nos échantillons ont produit des décomptes identiques. Aucun n’est jamais le plus économe. Le même paragraphe anglais représente 90 tokens bruts avec Claude, contre 55 avec DeepSeek, et le surcoût net varie de 1.3x en japonais à 2.2x en chinois. Comme la facturation repose sur les tokens, le coût d’entrée dépend de deux facteurs rarement indiqués dans les grilles tarifaires : la quantité de sens portée par chaque caractère d’une langue et l’efficacité avec laquelle le tokenizer de chaque modèle compresse son système d’écriture. Ces facteurs se multiplient, et leur produit ne correspond pas à ce que suggère une comparaison par caractère.

TL;DR

• Claude Fable 5, Opus 4.8 et Sonnet 5 partagent le même tokenizer et ne sont jamais les plus économes : leur décompte est partout 1.2-2.3x supérieur au minimum.
• Le tokenizer le moins cher dépend de la langue : GPT-5.5 pour les langues européennes, l’hindi et le coréen ; Kimi pour le chinois ; DeepSeek pour le japonais.
• Par caractère, les langues CJK semblent coûter 3x plus cher. À quantité de sens égale, le chinois reste proche de la parité, tandis que le japonais et le coréen coûtent 1.5-2.4x plus.
• Le coût correspond à la densité du système d’écriture multipliée par la couverture du tokenizer. Une mauvaise couverture amplifie l’écart : GLM facture l’hindi à 4.9x son anglais.
• Localiser réduit rarement les coûts. Il faut choisir le modèle en fonction du nombre de tokens dans chaque langue.

Les décomptes ont été mesurés le 2026-07-08 via la gateway Synthorai, en utilisant toujours le décompte fourni par chaque provider, jamais un tokenizer local. Toutes les répétitions ont donné des résultats identiques.

L’unité de facturation est le token, pas le texte

La facturation se fait au token, mais un token n’est ni un caractère ni un mot. Chaque modèle utilise son propre tokenizer et son propre vocabulaire. Une même phrase produit donc un nombre de tokens différent selon le modèle. Ce nombre est ensuite multiplié par le prix unitaire du token. Deux variables changent simultanément : le nombre de tokens issu du texte et le prix de chaque token.

La plupart des grilles tarifaires n’indiquent que la seconde. Cet article mesure la première. Nous avons envoyé trois passages sémantiquement alignés à sept modèles (claude-fable-5, claude-opus-4-8, claude-sonnet-5, deepseek-v4-flash, glm-5.2, gpt-5.5, kimi-k2.5), puis relevé le nombre de tokens d’entrée facturés par chacun.

Un récit informel, consacré à un marché du samedi, est disponible en neuf langues. Une explication technique sur les retries avec exponential backoff et une brève d’actualité sur le vote d’un budget municipal sont disponibles en anglais, chinois, japonais, coréen, allemand et hindi. L’ensemble comprend aussi une fonction Python et un bloc JSON correspondant à un appel d’outil. Les versions non anglophones sont des traductions automatiques générées avec pour consigne de rester fidèles sans condenser le texte, puis contrôlées manuellement. La verbosité propre à la traduction reste un facteur de confusion réel ; la section sur le registre ci-dessous en estime l’effet à environ 20%.

Le décompte provient toujours du provider. Pour Claude, nous effectuons un véritable appel Messages et lisons usage.input_tokens, car la gateway ne relaie pas encore count_tokens. Pour les modèles compatibles OpenAI, nous lançons un petit appel et lisons usage.prompt_tokens. Cette méthode évite précisément le problème d’un tokenizer local dont le résultat ne correspond pas à la facture. Il faut tenir compte d’un paramètre de contrôle : chaque requête contient un framing fixe de quelques tokens, notamment le chat template et les marqueurs de rôle. Nous mesurons donc un échantillon de référence de deux caractères et soustrayons son coût. Tous les ratios présentés ici excluent cette enveloppe et comparent uniquement le texte, pas le framing.

Un même texte, cinq tokenizers

Voici le nombre brut de tokens d’entrée du récit, par langue et par tokenizer. Les trois modèles Claude partagent une colonne, car ils ont renvoyé exactement les mêmes décomptes sur tous les échantillons ; nous y reviendrons. Les deux autres passages présentent la même tendance et sont intégrés aux résultats plus loin. La colonne des caractères indique la longueur de chaque version. Les systèmes d’écriture n’ont pas la même densité sémantique : le chinois exprime en 77 caractères ce qui en demande 254 en anglais.

Deux constats ressortent. La colonne Claude ne contient qu’une valeur pour trois modèles, car Claude Fable 5, Opus 4.8 et Sonnet 5 ont donné des résultats identiques sur tous les échantillons, qu’il s’agisse de langues naturelles, de code ou de JSON. Tous les trois utilisent le tokenizer introduit avec Opus 4.7 : un décompte effectué sur l’un vaut donc pour les trois. Cette colonne est aussi la plus élevée de chaque ligne, sauf en hindi, où les 192 tokens de GLM font encore moins bien. Voici les décomptes nets normalisés, avec 1.00 pour le modèle le plus économe dans chaque langue. L’enveloppe étant soustraite avant le calcul, ces ratios ne correspondent pas à une simple division des valeurs brutes ci-dessus.

L’égalité à quatre sur la ligne anglaise ne vient pas d’un arrondi : DeepSeek, GLM, GPT-5.5 et Kimi arrivent tous exactement à 50 tokens nets pour ce passage. Sur cet échantillon, Claude consomme entre 1.3x et 2.2x plus de tokens que le tokenizer le plus économe, et entre 1.2x et 2.3x sur l’ensemble des trois passages. Cette propriété du vocabulaire s’applique à tous les appels pendant toute la durée de vie du modèle. Les passages technique et journalistique conservent le même classement. Cumulés, ils représentent 212 tokens nets en chinois avec Claude, contre 114 avec Kimi (1.9x), et 477 en hindi, contre 210 avec GPT-5.5 (2.3x). Aucun modèle ne domine cependant dans toutes les langues. La colonne la plus économe change selon la langue :

• GPT-5.5 est le plus économe en allemand, français, espagnol, italien, hindi et coréen, et arrive à égalité en anglais. L’égalité ainsi que les résultats fr/es/it ne valent que pour le récit. Son vocabulaire est optimisé pour les alphabets latins et reste efficace sur le devanagari et le hangul.
• Kimi K2.5 est le plus économe en chinois et reste compétitif sur l’ensemble CJK.
• DeepSeek-v4 est le plus économe en japonais et talonne Kimi en chinois.
• GLM 5.2 se situe généralement dans la moyenne, mais affiche les pires résultats de toute la matrice en hindi : 2.59x le minimum sur le récit, avec 179 tokens nets contre 69 pour GPT-5.5. L’écart se creuse encore sur les passages formels. C’est la seule colonne à dépasser même Claude.

Le surcoût ne concerne pas uniquement la prose. Sur la fonction Python, Claude consomme 1.61x plus de tokens que le modèle le plus économe, et 1.29x sur l’appel d’outil en JSON. L’écart est plus faible en JSON, car le texte structuré contient surtout de la ponctuation et des clés ASCII courtes, que tous les tokenizers gèrent de façon similaire. Pour un agent de longue durée qui renvoie un gros schéma d’outil à chaque tour, ce surcoût s’accumule. C’est précisément dans ce cas que le caching devient rentable. La série consacrée au prompt caching en détaille le fonctionnement.

Le piège du coût par caractère : les langues CJK semblent plus chères qu’elles ne le sont

Les tableaux précédents comparaient les modèles. Si l’on fixe le modèle, la langue fait toujours varier le décompte, mais pas comme le suggère une lecture brute par caractère. La métrique la plus souvent citée pour les tokenizers est le nombre de tokens par caractère, et les langues CJK y dominent largement. Avec Claude, le chinois atteint environ 114 tokens nets pour 100 caractères, le coréen 106 et le japonais 94, contre 32 pour l’anglais. Cette seule colonne donne l’impression que les langues CJK coûtent 3x plus cher. Ce n’est pas la bonne comparaison : la facture porte sur la quantité de sens, pas sur le nombre de caractères, et chaque version du passage transmet le même contenu. Voici les deux lectures pour le récit avec Claude :

Les deux colonnes de droite racontent des histoires différentes. Le chinois constitue le cas le plus net : il affiche la plus forte densité de tokens par caractère, mais ne coûte que 1.07x plus que l’anglais à quantité de sens égale sur ce passage. Il transmet en 77 caractères ce que l’anglais exprime en 254. Le coût élevé par caractère est donc multiplié par un très faible nombre de caractères, et les deux effets s’annulent presque. Cette compensation se retrouve sur les trois passages, sans être absolue : le chinois représente en moyenne 1.17x l’anglais de Claude, et entre 0.95x et 1.32x selon le modèle. Il reste proche de la parité, loin du surcoût de 3x suggéré par la métrique par caractère.

Le japonais et le coréen montrent la limite de ce raisonnement. L’illusion est la même, mais la compensation est plus faible. Leur densité en tokens par caractère est élevée, car le hangul et les kana japonais transcrivent les sons à raison d’environ un glyphe par syllabe, contrairement aux hanzi chinois, où chaque caractère porte davantage de sens. Le coréen demande donc 143 caractères et le japonais 136 pour exprimer ce que le chinois dit en 77. Cette fois, le nombre élevé de caractères ne compense pas le coût par caractère : il l’amplifie. Avec Claude, le coréen représente en moyenne 1.96x l’anglais à quantité de sens égale sur les trois passages, et le japonais 1.56x. Les deux sont réellement coûteux, malgré une densité par caractère proche de celle du chinois.

L’allemand est le cas inverse du chinois : son coût par caractère est faible, 48 contre 32 en anglais, mais il utilise ici plus de caractères que toutes les autres langues, soit 289, notamment à cause de ses mots composés. Le total atteint donc tout de même 1.68x. Le coût est le produit de ces deux axes ; regarder l’un sans l’autre induit en erreur.

Pourquoi les chiffres varient : deux facteurs qui se multiplient

Tous les tableaux précédents reposent sur une même équation :

tokens pour un passage = (caractères nécessaires pour exprimer le sens) x (tokens par caractère)

Le premier facteur correspond à la densité du système d’écriture. Il dépend de la langue, pas du modèle. Il s’agit d’un continuum, pas d’une exception propre au chinois. À l’extrémité la plus dense, le chinois logographique encode un morphème par caractère. Les kana japonais et le hangul coréen transcrivent des sons ; ils sont donc moins denses et demandent davantage de caractères. Le devanagari et les alphabets latins sont encore moins denses. La quantité de sens par caractère décroît progressivement du chinois vers l’anglais.

Le second facteur correspond au nombre de tokens que le vocabulaire du modèle consacre à chaque caractère d’un système d’écriture. Il dépend entièrement du modèle. Un tokenizer BPE apprend des fusions de plusieurs caractères à partir de son corpus d’entraînement. Les systèmes d’écriture fréquents bénéficient de tokens compacts. Les plus rares se rapprochent d’un encodage caractère par caractère, voire byte par byte, où un seul caractère peut produire deux ou trois tokens. Voici le nombre de tokens nets par caractère pour les trois mêmes langues :

Ce tableau explique trois phénomènes. Si le chinois se distingue dans les totaux, c’est parce qu’il se situe à l’extrême du premier facteur. Même la faible compression du chinois par Claude, à 1.14 tokens par caractère, avec certains hanzi encore divisés en deux, ne produit pas un total élevé puisqu’il n’y a que 77 caractères. Les modèles entraînés en Chine le compressent suffisamment bien, entre 0.52 et 0.58, pour approcher leur propre résultat en anglais. Pour l’hindi, le surcoût vient du second facteur, pas de la densité. GLM consomme 0.91 token par caractère devanagari, soit presque un token par caractère, car son vocabulaire contient très peu de fusions couvrant plusieurs caractères devanagari. GPT-5.5 n’en consomme que 0.35 grâce à des tokens couvrant des groupes syllabiques complets. C’est un écart de couverture sur un même système d’écriture. Enfin, Claude est élevé partout, car son coût par caractère l’est déjà en anglais : 0.32 contre 0.20 pour DeepSeek. Ce niveau de base propre au modèle s’ajoute à l’effet de chaque langue.

Ce phénomène ne se limite pas à nos sept modèles. La littérature scientifique parle de token premium. Petrov et al. (NeurIPS 2023) l’ont mesuré sur des centaines de paires de langues et ont retrouvé les deux mêmes causes : le nombre de caractères nécessaire varie à quantité de sens égale, tout comme la couverture de chaque système d’écriture par le tokenizer. Ils ont observé des surcoûts allant jusqu’à 15x pour les langues disposant de peu de ressources. Les conséquences sont les mêmes : coûts et latence plus élevés, mais aussi fenêtre de contexte utile plus petite, puisqu’une langue à fort surcoût remplit le même budget de contexte avec moins de contenu. L’écart se réduit à mesure que les fournisseurs investissent. Des mesures indépendantes indiquent que le chinois produisait +182% de tokens par rapport à l’anglais avec les vocabulaires de l’époque de GPT-3, contre +24% avec celui de GPT-4o. Ces résultats sont proches des +32% mesurés ici avec GPT-5.5 et de la parité constatée sur les modèles entraînés en Chine. Les emplacements du vocabulaire permettent d’acheter de la couverture, et les fournisseurs continuent d’en ajouter.

La localisation réduit-elle parfois les coûts ?

On pourrait conclure de la section précédente que Claude a un coût stable entre les langues et qu’il n’y a donc pas lieu de tenir compte de la localisation, ou encore que les modèles chinois sont peu chers en chinois et que localiser réduit les coûts. Ces deux conclusions sont fausses. Le tableau suivant compare chaque langue à l’anglais du même modèle, en moyenne sur les trois passages, pour les cinq langues disponibles dans les trois registres :

Claude n’est pas stable entre les langues : le coréen coûte 1.96x son anglais et l’hindi 2.40x. Le fait que le chinois reste proche de 1.17x est propre à cette langue, pas au modèle. Quant aux modèles chinois, ils ne font pas vraiment mieux que l’anglais : ils atteignent surtout la parité. La meilleure valeur de tout le tableau est le 0.95x de Kimi, soit cinq pour cent de moins que son propre anglais. Toutes les autres langues coûtent autant ou davantage. En hindi, japonais et coréen, ces mêmes modèles subissent même un surcoût supérieur à celui de Claude, car ces systèmes d’écriture sont plus éloignés de leur corpus principal. Le bon constat n’est pas qu’un fournisseur donné coûte peu cher. Chaque modèle est surtout efficace, par rapport à son propre anglais, sur les langues les plus proches de ses données d’entraînement.

Le registre fait lui aussi varier ces chiffres. Le récit informel constitue le cas le plus favorable. Les passages technique et journalistique augmentent presque tous les multiplicateurs, car les terminologies spécialisées et les emprunts linguistiques sont précisément les éléments pour lesquels les vocabulaires non latins disposent de peu de fusions. Avec Claude, l’allemand passe de 1.68x dans le récit à 2.29x dans le passage technique. Sur la brève d’actualité, l’hindi de GLM atteint 5.98x son anglais. Un benchmark fondé sur un seul passage favorise la langue ayant reçu la traduction la plus simple. C’est pourquoi le récit seul place le chinois à 0.80x avec Kimi, alors que la moyenne sur trois passages atteint 0.95x.

La comparaison avec l’anglais du même modèle n’est de toute façon pas la bonne métrique. La facture dépend du nombre absolu de tokens. Sur ce plan, Claude est le plus cher dans huit des neuf langues ; seul l’hindi de GLM fait pire. Un contenu chinois « peu cher par rapport à l’anglais de Claude » représente tout de même 88 tokens nets avec Claude, contre 40 avec Kimi pour le récit. Il ne faut donc pas localiser pour économiser, mais choisir le modèle adapté à la langue : Kimi ou DeepSeek pour le chinois, GPT-5.5 pour l’hindi et le coréen, DeepSeek pour le japonais. Claude n’est jamais le moins cher en tokens, quelle que soit la langue, même s’il peut rester meilleur en qualité.

Le décompte ne représente que la moitié de la facture

Un multiplicateur de tokens n’a de sens qu’associé au prix unitaire, et les deux se composent. Claude Fable 5 est affiché à $10 par million de tokens d’entrée, Opus 4.8 à $5 et Sonnet 5 à $3 après la fin de son tarif de lancement. En chinois, leur tokenizer commun compte aussi 2.2x plus de tokens que le modèle le plus économe. Ce surcoût de décompte multiplie donc tout écart tarifaire déjà existant avec l’alternative vers laquelle on pourrait router la requête. L’inverse peut aussi se produire : un modèle peut produire peu de tokens tout en coûtant plus cher par appel à cause de son tarif élevé. Aucun des deux chiffres ne suffit à déterminer la facture. Nous n’indiquons pas ici les tarifs des autres providers, car ils changent plus vite que les tokenizers. Les décomptes ci-dessus constituent la partie durable du calcul.

Il faut cesser de comparer uniquement les tarifs affichés et calculer le coût d’entrée effectif : compter le trafic réel sur chaque modèle candidat, puis multiplier le résultat par son tarif d’entrée. Pour un produit principalement utilisé en chinois ou en coréen, ce calcul peut inverser le classement des modèles les moins chers. L’écart durable atteint 1.5x à 2x ; ce n’est pas une erreur d’arrondi. Pour le caching, la métrique pertinente est elle aussi le coût effectif pondéré par le hit rate, pas le tarif affiché. La comparaison des providers détaille ce calcul. La comparaison des tokenizers de Sonnet 5 explique quant à elle pourquoi Sonnet 5 compte 41% de tokens en plus que Sonnet 4.6 sur le même texte anglais.

Conclusion

• Le coût en tokens correspond à la densité du système d’écriture multipliée par la couverture du tokenizer. La langue détermine le premier facteur, le modèle le second. Considérer un seul des deux induit en erreur.
• Claude Fable 5, Opus 4.8 et Sonnet 5 consomment 1.2x à 2.3x plus de tokens que le modèle le plus économe dans chaque langue, car leur coût par caractère est élevé même en anglais.
• Le modèle le plus économe dépend de la langue : GPT-5.5 pour les langues européennes, l’hindi et le coréen ; Kimi pour le chinois ; DeepSeek pour le japonais. GLM est le moins performant en hindi, avec près d’un token par caractère.
• Les registres formel et technique augmentent le multiplicateur dans presque toutes les langues. Les benchmarks doivent utiliser le même registre que les prompts en production.
• Ne localisez pas pour réduire les coûts. Choisissez le modèle en fonction du nombre absolu de tokens dans chaque langue, puis multipliez ce nombre par son tarif pour comparer le coût effectif.

FAQ

Quel tokenizer de LLM coûte le moins cher ? Cela dépend de la langue. Sur les mêmes passages alignés et parmi sept modèles, GPT-5.5 est le plus économe pour les langues européennes, l’hindi et le coréen, avec une égalité en anglais. Kimi K2.5 l’emporte en chinois et DeepSeek-v4 en japonais. La famille Claude, composée de Fable 5, Opus 4.8 et Sonnet 5, n’est jamais la plus économe : son décompte est 1.2x à 2.3x supérieur au minimum dans toutes les langues et tous les registres.

Claude Fable 5, Opus 4.8 et Sonnet 5 utilisent-ils le même tokenizer ? Oui. Les trois ont produit exactement les mêmes décomptes sur tous les échantillons, dans toutes les langues, ainsi que pour le code et le JSON. Ils utilisent le tokenizer introduit avec Opus 4.7. Un décompte effectué sur l’un vaut donc pour les autres, et la facture plus élevée de Fable 5 vient entièrement de son prix par token.

Le chinois coûte-t-il plus cher que l’anglais avec Claude ? Légèrement : 1.17x à quantité de sens égale, en moyenne sur trois passages. Sur les modèles entraînés en Chine, il reste proche de la parité. Par caractère, l’écart semble bien plus élevé, avec environ 114 tokens nets pour 100 caractères chinois contre 32 en anglais. Mais le chinois transmet le même contenu avec environ trois fois moins de caractères, ce qui compense presque entièrement la différence.

Le japonais et le coréen se comportent-ils comme le chinois ? Seulement en partie. Leur densité en tokens par caractère est aussi élevée que celle du chinois, mais le hangul et les kana transcrivent les sons. Ils nécessitent donc beaucoup plus de caractères pour le même passage : 136 en japonais et 143 en coréen, contre 77 en chinois. Le coût élevé par caractère n’est plus compensé. À quantité de sens égale, le japonais représente environ 1.6x l’anglais avec Claude et le coréen environ 2x, avec une plage de 1.5x à 2.4x sur les sept modèles.

Comment mesurer ce coût sur mes propres prompts ? Envoyez plusieurs prompts réels, dans le registre utilisé en production, à chaque modèle candidat. Lisez ensuite le nombre de tokens d’entrée fourni par le provider dans les champs d’usage, plutôt que de vous fier à un tokenizer local. Un seul passage favorable peut avantager une langue d’environ 20%, d’où l’intérêt d’en tester plusieurs. Multipliez enfin chaque décompte par le prix d’entrée du modèle pour obtenir le coût effectif sur votre trafic.

← Retour au blog