Quel LLM coûte le moins cher selon votre langue ? Le coût des tokenizers, mesuré

Il n’existe pas de LLM universellement le moins cher pour du 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 est le plus économe en chinois, et DeepSeek en japonais. Claude Fable 5, Opus 4.8 et Sonnet 5 partagent un seul tokenizer (comptes identiques sur tous les échantillons envoyés) et ne sont jamais les plus économes : le même paragraphe anglais facture 90 tokens bruts sur Claude contre 55 pour DeepSeek, et le surcoût net va de 1,3x en japonais à 2,2x en chinois. Le token est l’unité de facturation, donc deux facteurs qu’on voit rarement sur une grille tarifaire déterminent le coût en entrée : à quel point une langue condense du sens dans ses caractères, et à quel point le tokenizer de chaque modèle a bien compressé cette écriture. Les deux se multiplient, et le résultat ne correspond pas à ce que suggère la vue par caractère.

TL;DR

• Claude Fable 5, Opus 4.8 et Sonnet 5 partagent un seul tokenizer, jamais le plus économe : 1,2-2,3x le compte le plus bas, partout.
• Le tokenizer le moins cher change selon la langue : GPT-5.5 pour les langues européennes, l’hindi, le coréen ; Kimi pour le chinois ; DeepSeek pour le japonais.
• Par caractère, le CJK paraît 3x pire, mais par unité de sens le chinois est proche de la parité tandis que le japonais et le coréen tournent à 1,5-2,4x.
• Le coût, c’est la densité de l’écriture multipliée par la couverture du tokenizer ; une couverture manquante fait exploser la facture (GLM facture l’hindi à 4,9x son anglais).
• Localiser fait rarement économiser ; associez le modèle à la langue en fonction des tokens.

Les comptes ont été mesurés via la passerelle Synthorai le 2026-07-08, toujours avec le comptage propre à chaque fournisseur, jamais un tokenizer local. Chaque compte était identique d’une répétition à l’autre.

Le token est l’unité de facturation, pas le texte

La facturation se fait au token, mais un token n’est ni un caractère ni un mot. Chaque modèle embarque son propre tokenizer avec son propre vocabulaire, et une même phrase donne un nombre de tokens différent sur chacun. Ce nombre multiplie ensuite le prix au token : deux choses varient donc en même temps, le nombre de tokens produits par votre texte et le coût de chaque token.

La plupart des grilles tarifaires n’affichent que le second chiffre. Ce billet mesure le premier. 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) et relu ce que chacun facturait en entrée.

Un récit informel (une histoire de marché un samedi) existe en neuf langues ; une explication technique (retry avec backoff exponentiel) et une brève d’actualité (un vote sur le budget municipal) existent en anglais, chinois, japonais, coréen, allemand et hindi. Une fonction Python et un blob JSON d’appel d’outil complètent le lot. Les versions non anglaises sont des traductions automatiques produites sous une consigne fidèle et sans compression, vérifiées à la main par sondage ; la verbosité de traduction est un vrai facteur de confusion, et la section sur le registre plus bas la borne à environ 20 %.

Le comptage passe toujours par le fournisseur lui-même : la ligne Claude via un vrai appel Messages qui lit usage.input_tokens (la passerelle ne relaie pas count_tokens pour l’instant), les modèles compatibles OpenAI via un petit appel qui lit usage.prompt_tokens. Un tokenizer local en désaccord avec la facture, c’est précisément l’écueil que ça évite. Un contrôle compte : chaque requête embarque un cadre fixe (template de chat, marqueurs de rôle) valant une poignée de tokens, donc on mesure un échantillon de référence à deux caractères et on le soustrait. Chaque ratio de ce billet est net de cet enrobage et compare le texte, pas le cadre.

Le même texte, cinq tokenizers

Voici le nombre de tokens d’entrée bruts pour le passage narratif, par langue et par tokenizer. Les trois modèles Claude partagent une colonne parce qu’ils ont retourné des comptes identiques sur chaque échantillon (j’y reviens plus bas). Les deux autres passages suivent le même schéma, détaillé plus loin. La colonne des caractères correspond à la longueur de la version dans chaque langue : les écritures compactent le sens différemment, si bien que le chinois dit en 77 caractères ce qui en demande 254 en anglais.

Deux choses sautent aux yeux. La colonne Claude ne contient qu’un chiffre pour trois modèles parce que Claude Fable 5, Opus 4.8 et Sonnet 5 ont retourné des comptes identiques sur chaque échantillon, langues, code et JSON confondus : les trois embarquent le tokenizer introduit avec Opus 4.7, donc un compte sur l’un vaut pour tous. Et cette colonne est la plus élevée sur chaque ligne, sauf en hindi, où les 192 de GLM font pire. En normalisant sur les comptes nets, de sorte que le modèle le plus économe dans chaque langue soit à 1,00 (l’enveloppe est soustraite d’abord, donc ces ratios ne correspondent pas à une simple division des cellules brutes ci-dessus) :

L’égalité à quatre sur la ligne anglaise n’est pas un effet d’arrondi : DeepSeek, GLM, GPT-5.5 et Kimi tombent tous exactement sur 50 tokens nets pour ce passage. Claude consomme entre 1,3x et 2,2x le tokenizer le plus économe sur ce passage, entre 1,2x et 2,3x sur les trois réunis, une propriété du vocabulaire qui s’applique à chaque appel pendant toute la durée de vie du modèle. Les passages technique et journalistique reproduisent le classement : en additionnant les deux, Claude facture le chinois à 212 tokens nets contre 114 pour Kimi (1,9x), et le hindi à 477 contre 210 pour GPT-5.5 (2,3x). Mais il n’y a pas de vainqueur unique en dessous. La colonne la plus économe change avec la langue :

• GPT-5.5 est le plus économe en allemand, français, espagnol, italien, hindi et coréen, et à égalité pour la première place en anglais (l’égalité et le fr/es/it ne tiennent que sur le passage narratif). Son vocabulaire est calé sur les écritures latines et il tient bon en devanagari et en hangeul.
• Kimi K2.5 est le plus économe en chinois et reste compétitif sur l’ensemble des langues CJK.
• DeepSeek-v4 est le plus économe en japonais et suit de près en chinois.
• GLM 5.2 se situe dans la moyenne sur la plupart des langues mais affiche les pires cellules de la matrice en hindi : 2,59x le plus économe sur le passage narratif (179 tokens nets là où GPT-5.5 en demande 69), pire encore sur les passages formels, et la seule colonne qui dépasse même Claude.

La pénalité ne se limite pas à la prose. Sur la fonction Python, Claude consomme 1,61x le plus économe, et sur l’appel d’outil en JSON, 1,29x. L’écart JSON est plus étroit parce que le texte structuré est fait surtout de ponctuation et de clés ASCII courtes que tous les tokenizers traitent de manière similaire. Pour un agent au long cours qui rejoue un gros schéma d’outils à chaque tour, cette taxe par tour s’accumule, et c’est là que le caching prend tout son sens. La série sur le prompt caching en détaille les mécanismes.

Le piège du par-caractère : le CJK a l’air pire qu’il ne facture

Les tableaux précédents comparaient des modèles. Fixons plutôt le modèle : la langue fait toujours bouger le compte, mais pas comme le laisse croire la vue brute par caractère. Le chiffre de tokenizer le plus cité est le nombre de tokens par caractère, et le CJK y domine : sur Claude, le chinois tourne autour de 114 tokens nets pour 100 caractères, le coréen 106, le japonais 94, contre 32 pour l’anglais. Si on ne regarde que cette colonne, le CJK ressemble à une taxe de 3x. Mais c’est la mauvaise colonne : on paie pour du sens, pas pour des caractères, et le passage aligné porte le même sens dans chaque langue. Voici les deux vues sur Claude, pour le passage narratif :

Les deux colonnes de droite se contredisent, et le chinois est le cas le plus net : la densité par caractère la plus élevée du lot, mais une surcharge par sens de seulement 1.07x l’anglais sur ce passage. 77 caractères portent ce que l’anglais dépense en 254, donc un taux par caractère élevé multiplie un tout petit nombre de caractères et s’annule presque. Sur les trois passages, l’annulation tient mais n’a rien de magique : le chinois fait en moyenne 1.17x l’anglais de Claude, et de 0.95x à 1.32x selon le modèle, proche de la parité plutôt que des 3x que menace la colonne par caractère.

Le japonais et le coréen répondent à la question évidente qui suit : même illusion, annulation plus faible. Les deux partagent la densité par caractère élevée, parce que le hangul et les kana japonais épellent les sons à raison d’à peu près un glyphe par syllabe, au lieu de tasser un mot entier dans chaque caractère comme le font les hanzi chinois. Le coréen a donc besoin de 143 caractères et le japonais de 136 pour ce que le chinois dit en 77. Plus de caractères multipliés par un taux par caractère élevé, ça ne s’annule pas, ça se cumule : sur Claude, le coréen fait en moyenne 1.96x l’anglais par sens sur les trois passages et le japonais 1.56x, tous deux réellement coûteux, même si leur colonne par caractère ressemble beaucoup à celle du chinois.

L’allemand est l’image inverse du chinois : un taux par caractère faible (48, proche de l’anglais) mais le plus grand nombre de caractères de toutes les langues ici (289, à cause de ses mots composés), ce qui donne quand même un total de 1.68x. Le coût est le produit des deux axes, et lire l’un ou l’autre seul induit en erreur.

Pourquoi les chiffres bougent : deux facteurs, multipliés

Chaque tableau ci-dessus repose sur une seule équation :

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

Le premier facteur, c’est la densité du système d’écriture. C’est une propriété de la langue, pas du modèle. Et c’est un spectre, pas une exception chinoise. Le chinois logographique loge un morphème dans chaque caractère et se place à l’extrême dense du spectre. Les kana japonais et le hangul coréen épellent des sons, donc ils sont moins denses et demandent plus de caractères. Le devanagari et les alphabets latins sont encore moins denses. Le sens par caractère décroît régulièrement du chinois vers l’anglais.

Le second facteur, c’est le nombre de tokens que le vocabulaire du modèle dépense par caractère de cette écriture, et là c’est entièrement propre au modèle. Un tokenizer BPE apprend des fusions multi-caractères à partir de son corpus d’entraînement : les écritures qu’il a beaucoup vues obtiennent des tokens compacts, celles qu’il a peu vues retombent vers un encodage caractère par caractère, voire au niveau de l’octet, où un caractère peut devenir deux ou trois tokens. Les mêmes trois langues, tokens nets par caractère :

Ce tableau explique trois choses. Le chinois semble à part dans les totaux parce qu’il est extrême sur le premier facteur : même la faible compression du chinois par Claude (1.14 token par caractère, qui découpe encore certains hanzi en deux) ne peut pas gonfler le total quand il n’y a que 77 caractères, et les modèles entraînés en Chine le compressent assez bien (0.52 à 0.58) pour arriver à parité avec leur propre anglais. Le surcoût du hindi vient du second facteur, pas de la densité : GLM dépense 0.91 token par caractère devanagari, presque un token par caractère parce que son vocabulaire n’a quasiment aucune fusion multi-caractères en devanagari, alors que GPT-5.5 en dépense 0.35 en couvrant des groupes syllabiques entiers, un écart de couverture sur la même écriture. Et Claude est élevé partout parce que son taux par caractère est élevé même en anglais (0.32 contre 0.20 pour DeepSeek), une base au niveau du modèle qui s’ajoute à ce que fait la langue.

Rien de tout cela n’est une bizarrerie de nos sept modèles. La littérature de recherche appelle ce phénomène le token premium, et Petrov et al. (NeurIPS 2023) l’ont mesuré sur des centaines de paires de langues. Ils retrouvent les deux mêmes causes profondes (le nombre de caractères diffère selon le sens, et la couverture du tokenizer diffère selon l’écriture) et des surcoûts allant jusqu’à 15x pour les langues peu dotées, avec les mêmes conséquences : coût plus élevé, latence plus élevée et fenêtre de contexte moins utile, puisqu’une langue à fort surcoût remplit le même budget de contexte avec moins de sens. L’écart se resserre aussi à mesure que les fournisseurs investissent : des mesures indépendantes situent le chinois à +182 % de tokens par rapport à l’anglais sur les vocabulaires de l’ère GPT-3 et à +24 % sur celui de GPT-4o, proche des +32 % que nous mesurons sur GPT-5.5 et de la parité que nous mesurons sur les modèles entraînés en Chine. La couverture s’achète avec des emplacements de vocabulaire, et les fournisseurs continuent d’en acheter.

La localisation permet-elle vraiment d’économiser ?

On est tenté de lire la section sur le piège comme « Claude est constant d’une langue à l’autre, donc oublions la localisation » et « les modèles chinois sont bon marché sur le chinois, donc localiser fait économiser ». Les deux conclusions sont fausses. Voici chaque langue comparée à l’anglais du même modèle, moyenné sur les trois passages, pour les cinq langues qui disposent des trois :

Claude n’est pas constant : le coréen coûte 1,96x son anglais, le hindi 2,40x. Le chinois à 1,17x est une coïncidence propre à une seule langue, pas une propriété du modèle. Quant aux modèles chinois, ils n’écrasent pas la parité sur le chinois, ils l’atteignent tout juste : la meilleure case du tableau est le 0,95x de Kimi, cinq pour cent sous son propre anglais, et toutes les autres cases coûtent autant ou plus. Sur le hindi, le japonais et le coréen, ces mêmes modèles subissent une pénalité plus forte que Claude, pas plus faible, parce que ces écritures sont plus éloignées de leur focus d’entraînement. Le schéma n’est pas « le fournisseur X est bon marché » : chaque modèle est le plus économe, par rapport à son propre anglais, sur les langues les plus proches de ses données d’entraînement.

Le registre fait bouger ces chiffres aussi. La narration informelle est le cas le plus favorable ; les passages technique et journalistique augmentent presque tous les multiplicateurs, parce que la terminologie et les emprunts sont exactement ce pour quoi les vocabulaires non latins n’ont pas de merges. En allemand, Claude passe de 1,68x (informel) à 2,29x (technique), et le hindi de GLM atteint 5,98x son anglais sur le passage journalistique. Un benchmark à un seul passage flatte la langue qui a hérité de la traduction la plus favorable : c’est pour ça que la narration seule donnait 0,80x au chinois sur Kimi alors que les trois passages le placent à 0,95x.

De toute façon, le rapport à l’anglais du modèle est le mauvais angle. Ce que vous payez, ce sont des tokens absolus, et là Claude est le plus cher dans huit des neuf langues, la seule colonne pire étant le hindi de GLM. Un contenu chinois « bon marché par rapport à l’anglais de Claude » reste à 88 tokens nets sur Claude contre 40 sur Kimi pour la narration. La bonne démarche n’est donc pas de localiser pour économiser, mais d’associer le modèle à la langue : le chinois à Kimi ou DeepSeek, le hindi et le coréen à GPT-5.5, le japonais à DeepSeek. Claude ne remporte jamais le coût en tokens, quelle que soit la langue, même s’il peut encore gagner sur la qualité.

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

Un multiplicateur de tokens ne veut rien dire sans le prix au token, et les deux se cumulent. Claude Fable 5 est facturé 10 $ par million de tokens en entrée, Opus 4.8 à 5 $, et Sonnet 5 à 3 $ une fois son tarif de lancement terminé ; en chinois, leur tokenizer commun compte aussi le texte à 2,2x le modèle le plus économe. La prime au décompte vient donc multiplier l’écart de tarif que le modèle a déjà par rapport à l’alternative vers laquelle vous auriez routé. L’inverse arrive aussi : un modèle peut compter peu de tokens et coûter plus cher par appel parce que son tarif est élevé. Aucun des deux chiffres pris seul ne vous donne la facture. On ne reporte pas ici les tarifs des autres fournisseurs, car ils changent plus vite que les tokenizers ; les décomptes ci-dessus sont la moitié durable du calcul.

En pratique, arrêtez de comparer les prix affichés et comparez le coût d’entrée effectif : votre mix de trafic réel, compté sur chaque modèle candidat, multiplié par le tarif d’entrée de ce modèle. Sur un produit à forte proportion de chinois ou de coréen, ce réordonnancement peut changer le modèle le moins cher, et l’écart est durablement de 1,5x à 2x, pas une erreur d’arrondi. C’est la même raison pour laquelle, avec du cache, le chiffre qui compte est le coût effectif pondéré par le taux de hit, et non le tarif affiché — ce que détaille la comparaison des fournisseurs. Le versant version-à-version de cette histoire, pourquoi Sonnet 5 compte 41 % de tokens en plus que Sonnet 4.6 sur le même anglais, est traité dans le post sur le tokenizer de Sonnet 5.

L’essentiel

• Le coût en tokens, c’est la densité du script multipliée par la couverture du tokenizer. La langue fixe le premier facteur, le modèle le second, et lire l’un sans l’autre induit en erreur.
• Claude Fable 5, Opus 4.8 et Sonnet 5 sont à 1,2x–2,3x du modèle le plus économe dans toutes les langues, parce que leur tarif au 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 plus faible sur l’hindi, à près d’un token par caractère.
• Le registre formel et technique augmente le multiplicateur dans presque toutes les langues ; faites vos benchmarks dans le registre que vous livrez vraiment.
• Ne localisez pas pour économiser ; choisissez le modèle en fonction de la langue sur le nombre de tokens absolu, puis multipliez par le tarif de chaque modèle pour comparer le coût effectif.

FAQ

Quel tokenizer LLM est le moins cher ? Ça dépend de la langue. Sur sept modèles testés avec les mêmes passages alignés, GPT-5.5 est le plus économe sur les langues européennes, le hindi et le coréen (à égalité sur l’anglais), Kimi K2.5 sur le chinois, et DeepSeek-v4 sur le japonais. La famille Claude (Fable 5, Opus 4.8, Sonnet 5) n’est jamais la plus économe : elle compte 1,2x à 2,3x plus de tokens que le meilleur, 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 produisent exactement le même nombre de tokens sur chaque échantillon, dans toutes les langues, le code et le JSON. Ils embarquent le tokenizer introduit avec Opus 4.7 : un décompte sur l’un vaut pour les autres, et la facture plus élevée de Fable 5 vient uniquement de son prix par token.

Le chinois coûte-t-il plus cher que l’anglais sur Claude ? Un peu : 1,17x par sens, en moyenne sur trois passages (et à peu près à parité sur les modèles entraînés en Chine). Par caractère, le résultat semble bien pire (environ 114 tokens nets pour 100 caractères chinois, contre 32 pour l’anglais), mais le chinois transmet le même sens en environ un tiers des caractères, si bien que les totaux s’annulent presque.

Le japonais et le coréen se comportent-ils comme le chinois ? Seulement à moitié. Ils partagent la forte densité par caractère du chinois, mais le hangul et les kana transcrivent des sons, donc il faut bien plus de caractères pour le même passage (136 pour le japonais, 143 pour le coréen, contre 77 pour le chinois). Le taux élevé par caractère ne s’annule plus : par sens, le japonais tourne à environ 1,6x l’anglais sur Claude et le coréen à environ 2x, et de 1,5x à 2,4x sur les sept modèles.

Comment mesurer tout ça pour mes propres prompts ? Envoyez quelques vrais prompts, dans le registre que vous utilisez réellement en production, à chaque modèle candidat et lisez le nombre de tokens d’entrée renvoyé par le fournisseur dans les champs d’usage, plutôt que de faire confiance à un tokenizer local. Un seul passage bien choisi peut avantager une langue d’environ 20 %, donc utilisez-en plusieurs. Multipliez ensuite chaque décompte par le prix d’entrée du modèle pour obtenir le coût effectif sur votre trafic.

← Retour au blog