Futures
Accédez à des centaines de contrats perpétuels
TradFi
Or
Une plateforme pour les actifs mondiaux
Options
Hot
Tradez des options classiques de style européen
Compte unifié
Maximiser l'efficacité de votre capital
Trading démo
Introduction au trading futures
Préparez-vous à trader des contrats futurs
Événements futures
Participez aux événements et gagnez
Demo Trading
Utiliser des fonds virtuels pour faire l'expérience du trading sans risque
Lancer
CandyDrop
Collecte des candies pour obtenir des airdrops
Launchpool
Staking rapide, Gagnez de potentiels nouveaux jetons
HODLer Airdrop
Conservez des GT et recevez d'énormes airdrops gratuitement
Pre-IPOs
Accédez à l'intégralité des introductions en bourse mondiales
Points Alpha
Tradez on-chain et gagnez des airdrops
Points Futures
Gagnez des points Futures et réclamez vos récompenses d’airdrop.
Investissement
Simple Earn
Gagner des intérêts avec des jetons inutilisés
Investissement automatique
Auto-invest régulier
Double investissement
Profitez de la volatilité du marché
Staking souple
Gagnez des récompenses grâce au staking flexible
Prêt Crypto
0 Fees
Mettre en gage un crypto pour en emprunter une autre
Centre de prêts
Centre de prêts intégré
Promotions
Centre d'activités
Participez et gagnez des récompenses
Parrainage
20 USDT
Invitez des amis et gagnez des récompenses
Programme d'affiliation
Obtenez des commissions exclusives
Gate Booster
Développez votre influence et gagnez des airdrops
Annoncement
Mises à jour en temps réel
Blog Gate
Articles sur le secteur de la crypto
AI
Gate AI
Votre assistant IA polyvalent pour toutes vos conversations
Gate AI Bot
Utilisez Gate AI directement dans votre application sociale
GateClaw
Gate Blue Lobster, prêt à l’emploi
Gate for AI Agent
Infrastructure IA, Gate MCP, Skills et CLI
Gate Skills Hub
+10K compétences
De la bureautique au trading, une bibliothèque de compétences tout-en-un pour exploiter pleinement l’IA
GateRouter
Choisissez intelligemment parmi plus de 40 modèles d’IA, avec 0 % de frais supplémentaires
Modèle d'IA « taxe en chinois » : pourquoi le chinois consomme-t-il plus de tokens que l'anglais ?
Auteur : Tang Yitao, source : Geek Park
Lorsque la version 4.7 d’Opus a été récemment publiée, il y a eu beaucoup de plaintes sur X. Certains disaient qu’une seule conversation avait épuisé leur quota de session, d’autres que le coût pour faire fonctionner le même code avait plus que doublé par rapport à la semaine précédente ; et certains ont partagé des captures d’écran montrant que leur abonnement Max à 200 dollars atteignait la limite en moins de deux heures.
Le développeur indépendant BridgeMind admet que Claude est le meilleur modèle au monde, mais aussi le plus cher. Son abonnement Max était épuisé en moins de deux heures, mais heureusement — il en a acheté deux. | Source de l’image : X@bridgemindai
Les prix officiels d’Anthropic n’ont pas changé : 5 dollars par million de tokens d’entrée, 25 dollars pour la sortie. Mais cette version a introduit un nouveau tokenizer, et Claude Code a porté l’effort par défaut de high à xhigh. Avec ces deux changements, la consommation de tokens pour le même travail est devenue 2 à 2,7 fois plus élevée qu’auparavant.
Dans ces discussions, j’ai repéré deux affirmations liées au chinois. La première : sous le nouveau tokenizer, le coût du chinois n’a presque pas augmenté, les utilisateurs chinois ont évité cette hausse. La seconde, plus intéressante : le texte classique (古文) consomme moins de tokens que le chinois moderne, converser en style littéraire peut réduire les coûts.
La première affirme que Claude aurait optimisé le traitement du chinois, mais dans la documentation officielle d’Anthropic, aucune modification spécifique au chinois n’est mentionnée.
La seconde est plus difficile à expliquer. Le texte classique est manifestement plus difficile à comprendre pour un humain que le chinois moderne, alors comment un texte plus complexe pourrait-il être plus facile pour l’IA ?
J’ai donc réalisé un test avec 22 segments de textes parallèles (incluant des actualités commerciales, des documents techniques, du chinois classique, des dialogues quotidiens, etc.), en les soumettant simultanément à 5 tokenizer (Claude 4.6 et 4.7, GPT-4o, Qwen 3.6, DeepSeek-V3), puis en comptant le nombre de tokens dans chaque modèle pour chaque segment, pour faire une comparaison horizontale.
Textes de test :
Conversations quotidiennes en anglais et chinois (voyages, forums, demandes d’écriture)
Documents techniques en anglais et chinois (documentation Python, documentation d’Anthropic)
Actualités en anglais et chinois (NYT politique, NYT économique, déclarations officielles d’Apple)
Extraits littéraires en chinois classique et moderne (《出师表》, 《道德经》)
Après analyse, les deux affirmations ont été partiellement vérifiées, mais la réalité est plus complexe que les rumeurs.
I. La « taxe » sur le chinois
———
Conclusion :
Sur Claude et GPT, le chinois a toujours été plus coûteux que l’anglais
Sur Qwen et DeepSeek, le chinois est en fait moins cher que l’anglais
La mise à niveau du tokenizer dans Opus 4.7, qui a provoqué la turbulence, a presque uniquement entraîné une inflation pour l’anglais, le chinois restant stable
Voyons les chiffres précis. Avant Opus 4.7, tous les modèles de la série Claude (y compris Opus 4.6, Sonnet, Haiku) utilisaient le même tokenizer. Avec ce tokenizer, le chinois consommait systématiquement plus de tokens que l’anglais pour un contenu équivalent, avec un ratio cn/en allant de 1,11× à 1,64×.
Le scénario le plus extrême apparaît dans des actualités de style NYT : pour le même contenu, la version chinoise consomme 64 % de tokens en plus, ce qui revient à payer 64 % de plus.
Les modèles Claude d’Opus 4.6 et antérieurs (dans le cadre rouge) montrent une consommation de tokens chinois nettement plus élevée que les autres modèles.
Le scénario extrême dans les actualités NYT (dans le cadre vert) montre que la version chinoise consomme 64 % de tokens en plus.
Le tokenizer o200k de GPT-4o est un peu meilleur : le ratio cn/en se situe majoritairement entre 1,0 et 1,35×, certains cas étant même en dessous de 1. Le coût global du chinois reste plus élevé, mais l’écart avec Claude est beaucoup plus réduit.
Les modèles nationaux Qwen 3.6 et DeepSeek-V3 montrent une tendance inverse : leur ratio cn/en est largement inférieur à 1, ce qui signifie que pour le même contenu, la version chinoise consomme moins de tokens que l’anglais. DeepSeek atteint même un ratio de 0,65×, ce qui signifie que la version chinoise est un tiers moins coûteuse que l’anglais.
La nouvelle tokenizer d’Opus 4.7, en termes d’inflation, a presque uniquement affecté l’anglais : le nombre de tokens anglais a augmenté de 1,24× à 1,63×, tandis que le chinois est resté majoritairement à 1,000×, avec peu ou pas de changement. La turbulence dans la facture des développeurs anglophones n’a pas été ressentie par les utilisateurs chinois. La raison pourrait être que, dans l’ancienne version, le chinois était déjà découpé au niveau des caractères, laissant peu d’espace pour la segmentation supplémentaire.
———
Opus 4.7 versus 4.6 : plus de tokens pour l’anglais, stabilité pour le chinois
Pendant le test, j’ai aussi remarqué une chose : la différence de consommation de tokens n’est pas seulement une question de facture, elle influence directement la taille de l’espace de travail. Avec la même fenêtre de contexte d’environ 200k, en utilisant l’ancien tokenizer pour le chinois, on peut y insérer 40 à 70 % de contenu en moins par rapport à l’anglais.
Pour des tâches similaires — analyser un long document ou résumer une réunion —, les utilisateurs chinois peuvent fournir moins de matériel au modèle, ce qui limite la longueur du contexte que le modèle peut prendre en compte. Résultat : ils paient plus cher pour un espace de travail plus petit.
En regroupant ces quatre jeux de données, une question claire apparaît :
Pourquoi le même contenu en différentes langues nécessite-t-il un nombre de tokens différent ? Pourquoi le chinois coûte plus cher avec Claude et GPT, alors qu’il est moins cher avec Qwen et DeepSeek ?
La réponse réside dans le concept de tokenizer (segmentateur).
II. Combien de morceaux peut contenir un caractère chinois ?
———
Avant de traiter un texte, le modèle le découpe en tokens via le tokenizer. On peut imaginer le tokenizer comme une « machine à découper en blocs » pour l’IA. On lui donne une phrase, il la divise en blocs standardisés (tokens). Le modèle ne voit pas le texte, mais uniquement les numéros de ces blocs. Plus il y a de blocs, plus le coût est élevé.
Pour l’anglais, la segmentation est intuitive : par exemple, « intelligence » est très probablement un seul token, tout comme « information ». Un mot = une unité de facturation.
Mais en chinois, cela devient problématique. Si l’on soumet la même phrase « 人工智能正在重塑全球的信息基础设施 » à GPT-4 avec le tokenizer cl100k, ou à Qwen 2.5, les résultats sont complètement différents.
GPT-4 découpe chaque caractère chinois en un token ; Qwen, lui, reconnaît des mots entiers comme un seul token, par exemple « 人工智能 » ne compte que pour un token.
———
Pour une phrase de 16 caractères chinois, GPT-4 en produit 19 tokens, Qwen seulement 6.
Pourquoi cette différence ? La réponse réside dans l’algorithme BPE (Byte Pair Encoding).
BPE fonctionne en analysant la fréquence des combinaisons de caractères dans le corpus d’entraînement, puis en fusionnant les plus fréquentes en un seul token, qui est ajouté au vocabulaire.
À l’époque de GPT-2, la majorité du corpus était en anglais. Les séquences comme « th », « ing », « tion » apparaissaient fréquemment, et étaient rapidement fusionnées en tokens. Les caractères chinois, en revanche, apparaissaient très peu dans le corpus, ils ne pouvaient pas être intégrés dans le vocabulaire, et étaient traités comme des octets bruts : un caractère chinois occupe 3 octets, donc 3 tokens.
Le BPE fusionne selon la fréquence des caractères dans le corpus. Sous domination de l’anglais, les octets UTF-8 chinois ne peuvent pas être fusionnés en caractères entiers.
Plus tard, GPT-4 a élargi son vocabulaire (cl100k), intégrant certains caractères chinois courants, réduisant la taille d’un caractère à 1 ou 2 tokens, mais l’efficacité reste inférieure à celle de l’anglais.
Avec le vocabulaire o200k de GPT-4o, l’efficacité du chinois s’est encore améliorée. C’est aussi la raison pour laquelle, dans les premiers résultats, le ratio cn/en de GPT-4o est inférieur à celui de Claude.
Les modèles nationaux Qwen 3.6 et DeepSeek-V3, dès le départ, ont intégré de nombreux caractères chinois courants et expressions fréquentes comme des tokens entiers. Un caractère = un token, ce qui double ou plus leur efficacité.
Schéma illustrant la segmentation différente d’une même phrase selon le tokenizer
C’est pourquoi leur ratio cn/en peut être inférieur à 1 : la densité d’information dans un caractère chinois est naturellement plus élevée que dans un mot anglais, et lorsque le tokenizer ne décompose plus le caractère, cet avantage devient évident.
La différence dans les résultats des quatre jeux de données précédents provient donc non pas des capacités du modèle, mais de la taille du vocabulaire allouée au chinois dans le tokenizer.
Les premiers vocabulaire de Claude et GPT étaient construits principalement pour l’anglais, le chinois étant ajouté par la suite ; Qwen et DeepSeek, dès leur conception, considèrent le chinois comme langue par défaut. Cette différence de départ influence le nombre de tokens, la facture, et la taille de la fenêtre de contexte.
———
III. Le texte classique est-il vraiment moins coûteux ?
———
Revenons à la seconde rumeur : le chinois classique consomme moins de tokens que le chinois moderne.
Les données confirment cette affirmation. Dans le test, le ratio cn/en du chinois classique est systématiquement inférieur à 1, sur tous les tokenizer. La même phrase en style classique nécessite moins de tokens que sa traduction moderne.
Dans tous les modèles, le chinois classique consomme moins de tokens que le chinois moderne, et même moins que l’anglais.
La raison est simple : le chinois classique utilise un vocabulaire très concis. Par exemple, « 学而不思则罔,思而不学则殆 » ne fait que 12 caractères. En traduction moderne, cela devient « 只学习而不思考就会迷惑,只思考而不学习就会陷入困境 », soit le double en nombre de caractères, et donc en tokens.
De plus, les caractères courants du chinois classique (之、也、者、而、不) sont des caractères à haute fréquence, présents dans tous les vocabulaire, et ne sont pas décomposés en octets. Le chinois classique est donc très efficace en termes d’encodage.
Mais il y a un piège.
Les tokens du chinois classique sont économisés au niveau de l’encodage, mais la charge de raisonnement du modèle n’est pas allégée. Par exemple, le caractère « 罔 » doit être interprété dans son contexte : «迷惑», «被蒙蔽» ou «没有» ? En chinois moderne, on peut exprimer cette nuance en 26 caractères ; en chinois classique, on doit tout condenser, ce qui transfère la complexité vers le modèle. C’est comme un fichier zip : plus il est compressé, plus il est petit, mais le décompresser demande plus de calcul.
Moins de tokens, mais plus de calcul pour la compréhension, et une baisse de précision. Ce calcul est difficile à faire précisément.
Ce cas du chinois classique montre que le nombre de tokens seul ne suffit pas à tout expliquer. En poursuivant cette réflexion, une autre dimension que j’avais négligée apparaît.
Comme mentionné, le tokenizer de GPT-2 décomposait le caractère « 人 » en trois octets UTF-8, alors que le vocabulaire de GPT-4 a été élargi pour faire de nombreux caractères chinois un seul token, et Qwen a encore avancé en fusionnant « 人工智能 » en un seul token.
Intuitivement, cela semble une amélioration continue : plus on fusionne, plus l’efficacité est grande, et mieux le modèle comprend.
Mais est-ce vraiment le cas ? Rappelons comment nous percevons les caractères chinois.
Les caractères chinois sont des logogrammes, plus de 80 % étant des caractères idéogrammes phonétiques (形声字), composés d’un radical (indiquant le sens) et d’un composant phonétique. Par exemple, « 氵 » dans « 河 » et « 海 » indique l’eau ; « 木 » dans « 林 » indique les arbres ; « 火 » dans « 炎 » indique la chaleur.
Les radicales sont des indices sémantiques fondamentaux pour la reconnaissance des caractères. Même si on ne connaît pas « 焱 », on peut deviner qu’il est lié au feu en voyant ses composants.
Les humains utilisent ces indices pour déduire le sens, en combinant la structure et le contexte.
———
« 火花 », « 火焰 », « 光焰 » évoquent la lumière et la chaleur, souvent dans la littérature ou les noms propres.
Mais dans le vocabulaire du tokenizer, « 焱 » correspond à un numéro. Supposons qu’il soit 38721, cela représente une position dans le vocabulaire. Le modèle, via cette position, retrouve un vecteur numérique représentant ce caractère.
Ce numéro ne contient aucune information sur la structure interne du caractère. La relation entre 38721 et 38722, ou entre 1 et 10 000, est identique pour le modèle. La « structure » du caractère, en tant qu’indice sémantique, est donc encapsulée dans ce numéro.
Le modèle peut apprendre indirectement, via beaucoup de données, que « 焱 », « 炎 », « 灼 » apparaissent souvent dans des contextes similaires. Mais cette voie est plus indirecte que d’utiliser directement les indices de radicale.
Peut-il, à partir des octets décomposés, « voir » des indices similaires aux radicales, puis les recombiner dans ses couches internes ? Bien que coûteux en tokens, cette approche pourrait, en théorie, améliorer la compréhension sémantique, en conservant des traces de radicale dans la séquence de bytes.
Une étude publiée en 2025 dans Computational Linguistics par MIT Press, intitulée « Tokenization Changes Meaning in Large Language Models: Evidence from Chinese », a examiné cette question.
———
IV. Fragmentation et radicales
———
L’auteur, David Haslett, a noté une coïncidence historique.
Dans les années 1990, l’Unicode a classé les caractères chinois par radical dans l’ordre de leur codage UTF-8. Les caractères partageant un même radical ont des codes proches. Par exemple, « 茶 » et « 茎 » contiennent tous deux le radical « 艹 » (tête d’herbe), et leurs séquences UTF-8 commencent par les mêmes octets. De même, « 河 » et « 海 » partagent le radical « 氵 ».
———
L’UTF-8 ordonne les caractères chinois par radical, et ceux partageant un radical ont des codes proches | Source : Github
Cela signifie que, lorsque le tokenizer décompose un caractère en trois octets, les caractères partageant un radical commun partageront le premier token. Lors de l’entraînement, le modèle voit ces séquences d’octets communes, et peut apprendre que le premier token partagé indique une appartenance à une même famille sémantique, ce qui ressemble à la déduction humaine par radical.
Haslett a conçu trois expériences pour tester cette hypothèse :
Demander à GPT-4, GPT-4o et Llama 3 si « 茶 » et « 茎 » partagent le même radical.
Demander au modèle d’évaluer la similarité sémantique de deux caractères.
Demander au modèle de faire une tâche d’élimination pour identifier l’intrus.
Chaque expérience contrôle deux variables : si les caractères partagent réellement le radical, et si, dans le tokenizer, ils partagent le premier token. La conception 2×2 permet d’isoler l’effet du radical et celui de la segmentation.
Les résultats sont cohérents : lorsque les caractères sont découpés en plusieurs tokens (par exemple, 89 % des caractères chinois dans l’ancien tokenizer de GPT-4), le modèle reconnaît mieux le partage de radical. Lorsqu’ils sont codés en un seul token (avec le nouveau tokenizer GPT-4o, seulement 57 % des caractères sont en plusieurs tokens), la précision diminue.
En résumé, cette hypothèse est confirmée : découper les caractères chinois en plusieurs tokens augmente le coût, mais permet au modèle de percevoir des indices de radicale dans la séquence de bytes. En revanche, en codant chaque caractère entier en un seul token, on réduit le coût, mais on perd cette information sémantique implicite.
Il faut préciser que cette conclusion concerne uniquement des tâches liées à la reconnaissance de la structure graphique des caractères, et ne signifie pas que la compréhension globale ou la capacité de raisonnement du modèle en chinois en pâtit nécessairement. De plus, la comparaison entre GPT-4 et GPT-4o, en dehors de la segmentation, implique aussi des différences d’architecture, de corpus d’entraînement et de paramètres, rendant difficile une attribution unique à la granularité de segmentation.
Ce phénomène a aussi été confirmé par des expérimentations industrielles : en 2024, une étude sur GPT-4o a montré que, lorsque le tokenizer fusionne certains caractères chinois en un seul token long, la compréhension du modèle se dégrade. En utilisant un tokenizer chinois spécialisé, en décomposant ces tokens longs, la précision revient.
Le consensus actuel dans l’industrie des grands modèles est que des tokenizer optimisés pour la langue cible — en particulier, des segmentation en caractères ou mots entiers — améliorent significativement la performance globale. Ces méthodes réduisent le coût en tokens, augmentent la quantité d’informations dans la contexte, raccourcissent la longueur des séquences, et améliorent la stabilité pour le traitement de longs textes. Les avantages observés dans ces études ne couvrent pas tous les scénarios NLP en chinois.
Mais cette question met en lumière un problème fondamental : on peut optimiser la partie que l’on a conçue, mais pas celle que l’on ignore. La classification Unicode par radical, conçue pour la recherche humaine, et la segmentation BPE, dictée par la fréquence dans le corpus, ont créé par hasard une voie sémantique non planifiée dans le réseau neuronal. Lorsqu’un ingénieur décide d’améliorer le tokenizer en fusionnant des caractères, il ferme aussi cette voie insoupçonnée, qui pourrait avoir un rôle dans la compréhension.
En somme, l’efficacité accrue et la réduction des coûts masquent parfois la disparition silencieuse de certains chemins sémantiques, sans message d’erreur.
Ce qui complique la gestion des systèmes complexes, c’est que l’on peut optimiser ce que l’on a prévu, mais pas ce que l’on ne sait pas.
———
V. Lin Yutang
———
L’adaptation du chinois aux infrastructures occidentales n’est pas une problématique nouvelle.
En janvier 2025, Nelson Felix, résident de New York, a publié sur Facebook des photos d’une machine à écrire chinoise trouvée dans les reliques de sa femme, sans connaître son origine. Rapidement, des centaines de commentaires ont afflué.
———
Le sinologue de Stanford, Thomas S. Mullaney, a reconnu immédiatement qu’il s’agissait du prototype de la « machine à écrire lumineuse » inventée par Lin Yutang en 1947, disparue depuis près de 80 ans. En avril de la même année, Felix et sa femme ont vendu la machine à la bibliothèque de Stanford.
Ce que la machine à écrire lumineuse tentait de résoudre, c’est la même problématique que le tokenizer aujourd’hui : comment intégrer efficacement le chinois dans une infrastructure conçue pour les langues occidentales.
Dans les années 1940, la machine à écrire anglaise comportait 26 touches, une lettre par touche. Le chinois, avec ses milliers de caractères, ne pouvait pas fonctionner ainsi. La machine chinoise de l’époque était un énorme disque de plomb avec des milliers de caractères, que le typographe devait sélectionner manuellement, ce qui limitait la vitesse à une dizaine de caractères par minute.
L’invention de Sheffield en 1899, la première machine à écrire chinoise, utilisait un système de sélection par composants. Elle comportait 72 touches, permettant de décomposer un caractère en composants supérieurs et inférieurs, puis de sélectionner via un « œil magique » (petre display). En appuyant sur un chiffre, on choisissait le caractère parmi 8000.
(Gauche) : fenêtre en verre transparent, « œil magique » ; (Droite) : structure interne de la machine lumineuse | Source : Facebook
Lin Yutang a investi 120 000 dollars pour développer cette machine, presque à sec, en confiant la fabrication à la société Carl E. Krum de New York. La machine comportait 72 touches, permettant de décomposer le caractère en composants, puis de sélectionner via un affichage. La vitesse était de 40 à 50 caractères par minute, supportant plus de 8000 caractères courants.
(Gauche) : fenêtre en verre transparent, « œil magique » ; (Droite) : structure interne de la machine lumineuse | Source : Facebook
Zhao Yuanren a commenté : « Que ce soit chinois ou américain, avec un peu d’apprentissage, on peut se familiariser avec ce clavier. Je pense que c’est la machine à écrire qu’il nous faut. »
Techniquement, la machine lumineuse était une avancée, mais commercialement, elle a échoué.
Lors d’une démonstration à Remington, la machine a rencontré un problème, ce qui a fait perdre l’intérêt des investisseurs. Son coût élevé, combiné à la rupture financière de Lin Yutang, a empêché la production en série. En 1948, Lin Yutang a vendu le prototype et les droits à Mergenthaler Linotype. La société a abandonné la production, et le prototype a disparu lors du déménagement dans les années 1950, pour réapparaître en 2025.
Dans Chinese Typewriters, le sinologue Thomas S. Mullaney estime que la machine lumineuse « n’a pas échoué » : en tant que produit des années 1940, elle a échoué, mais en tant que paradigme d’interaction homme-machine, elle a réussi.
Lin Yutang a transformé la frappe chinoise en une opération de « recherche et sélection ». Trois rangées de touches pour localiser les composants, puis sélection parmi des candidats. C’est la logique de tous les systèmes modernes d’entrée en chinois, de Cangjie, Wubi, à Sogou Pinyin.
Cette machine, qui a traversé près de huit décennies, et le débat actuel sur les tokenizer, partagent une même leçon historique : le chinois doit toujours s’intégrer dans une infrastructure basée sur l’alphabet romain.
Ce processus est rempli de coïncidences non planifiées. L’ordre de classement Unicode, basé sur les radicaux, et la segmentation BPE, dictée par la fréquence, ont créé par hasard une voie sémantique dans le réseau neuronal. Lorsqu’un ingénieur cherche à « améliorer » le tokenizer en fusionnant des caractères, il ferme aussi cette voie insoupçonnée.
L’histoire n’est pas une évolution linéaire, mais un flux en constante transformation sous contraintes.
Certaines capacités sont conçues, d’autres sont simplement le fruit du hasard, et n’ont pas été supprimées.
Fin de la traduction.