Les modèles spécialisés pour un domaine ou une tâche par affinage de modèles open source généralistes, tels que Qwen et Gemma, héritent d'un vocabulaire conçu pour de nombreux domaines et applications générales.
Dans un correcteur d'essais que nous exploitons en production, ce vocabulaire découpait en une multitude de tokens le texte que le modèle écrit le plus. Cet article présente un avant-goût de certains résultats de l'article VocabX, que nous publierons bientôt : la manière dont nous avons spécialisé le vocabulaire autour du coût de chaque token plutôt que de sa fréquence, et réduit le coût d'inférence mesuré de 77 % sans modifier le modèle de base.
Le tokenizer est généralement traité comme une propriété fixe du modèle de base, héritée et laissée telle quelle. Pour un modèle spécialisé dans un seul domaine, il peut constituer l'un des plus grands leviers de coûts, et il est fixé avant toute étape d'entraînement.
L'un des systèmes que nous exploitons en production est un correcteur automatisé de dissertations en portugais, construit sur Qwen3-4B. Il reçoit la dissertation, le sujet et les textes d'appui, et renvoie une évaluation au format JSON avec une note et un commentaire pour chaque compétence.
Le modèle était déjà petit, avec 4 milliards de paramètres, et avait déjà été entraîné pour la tâche. Son tokenizer, en revanche, était toujours celui d'origine de Qwen3-4B, conçu pour de nombreuses langues et de nombreux types de textes. Dans le correcteur, il était utilisé pour une seule langue, le portugais, et un seul format de réponse. Cela avait deux coûts : le texte que le correcteur écrit à chaque requête prenait plus de tokens que nécessaire, et à chaque token généré, le modèle notait un vocabulaire de 151,669 entrées, dont beaucoup que cette tâche n'utilise presque jamais.
Nous avons reconstruit ce vocabulaire avec une méthode que nous appelons VocabX, en conservant le même modèle de base, les mêmes données et la même recette d'entraînement. Les chiffres de cet article proviennent de la version actuelle de l'article scientifique, encore en cours d'évaluation, et peuvent changer avant la publication.
Un vocabulaire conçu pour tous
Les grands modèles de langage lisent et écrivent en tokens, et le tokenizer décide de la manière dont le texte devient des tokens. Les tokenizers des grands modèles généralistes sont entraînés sur de vastes collections de textes issus de nombreux domaines et langues, du code source aux contrats en passant par le chinois. Pour un modèle généraliste, ce choix a du sens.
Pour un modèle utilisé dans un seul domaine, il crée deux types de gaspillage à la fois.
Le premier est la fragmentation. Le tokenizer découpe en de nombreux morceaux exactement ce que le domaine répète le plus. Dans le correcteur, chaque réponse commence par la même enveloppe JSON, les mêmes noms de compétences, les mêmes formules d'évaluation. Dans les contrats, ce sont les clauses types. Dans le code, ce sont les identifiants. Chacune de ces séquences coûte plusieurs tokens là où un seul suffirait, et le modèle en paie le prix à chaque requête.
Le second est l'excédent. Le vocabulaire contient des dizaines de milliers d'entrées que le domaine n'utilise jamais, et le modèle calcule un score pour toutes à chaque token qu'il génère. Un modèle entraîné à corriger des examens de biologie d'écoles américaines n'écrira presque jamais en chinois, et pourtant il calcule la probabilité de chaque token chinois à chaque étape. Le vocabulaire découpe en de nombreux morceaux ce que le domaine répète le plus, et contient des entrées que le domaine n'utilise jamais.
Lire coûte peu, écrire coûte cher
La réaction naturelle consiste à compter les tokens et à essayer d'en réduire le nombre. Mais le nombre ne fait pas la facture.
Pour comprendre pourquoi un token généré coûte plus cher, il faut voir comment fonctionne l'inférence. Elle comporte deux phases. Dans prefill, le modèle traite toute l'entrée en un seul passage dans le réseau : chaque poids lu dans la mémoire du GPU est réutilisé pour chaque token d'entrée, et la limite est la puissance de calcul. Dans decode, le modèle génère la réponse un token à la fois, et chaque token nécessite un passage complet. Chaque poids lu n'est utilisé que quelques fois, et le GPU passe l'essentiel de son temps à attendre l'arrivée des données depuis la mémoire : la limite devient la bande passante mémoire.
Cet effet est le plus fort précisément là où nous opérons : des petits modèles servis avec des lots de taille modérée. Le traitement par lots répartit les lectures de poids entre les requêtes et atténue le problème, mais ne le résout pas. À chaque étape de décodage, le modèle lit également le cache KV, la mémoire d'attention qui conserve le contexte déjà traité et croît avec lui. Dans le cas que nous avons mesuré, le correcteur, un token généré coûte 7.4 fois un token lu, mais le ratio varie selon le matériel, le problème, la taille du lot, la longueur du contexte et d'autres facteurs, et il peut être supérieur. En général, la tendance se confirme : générer coûte plus cher que lire.
Pensez à une entreprise de transport qui facture à la caisse, mais facture sept fois plus les caisses sortantes que les caisses entrantes. Réduire le nombre total de caisses aide. Réduire les caisses sortantes aide sept fois plus. Une méthode qui compresse l'entrée et la sortie de manière égale passe à côté de la plupart des économies possibles.
Le troisième élément de la facture est le vocabulaire lui-même. La dernière couche du modèle, la tête LM, transforme l'état interne en un score pour chaque token possible. Pour ce faire, elle contient une ligne de paramètres par entrée de vocabulaire. Dans un modèle de la taille de Qwen3-4B, cette matrice représente près de 10 % des paramètres. C'est une proportion que les grands modèles absorbent sans s'en apercevoir, mais qui pèse sur un petit modèle.
Et le coût n'est pas payé une seule fois. La couche d'entrée ne consulte que la ligne du token en cours de lecture, mais la tête de LM lit et multiplie toute la matrice pour chaque token généré. Comme le décodage est déjà limité par la mémoire, chaque ligne supplémentaire représente plus de données à déplacer à chaque étape. Une entrée que le domaine n'utilise jamais coûte exactement aussi cher qu'une entrée fréquente. C'est pourquoi ajouter des tokens peut à la fois réduire le nombre et augmenter la facture. VocabX n'inclut pas ce terme dans son critère de sélection, mais il contrôle la taille du vocabulaire en deux étapes : la fusion de sous-mots remplace le vocabulaire de base par un vocabulaire plus petit et spécifique au domaine, et les macros entrent selon un budget fixe. Dans le grader, la couche de sortie est passée d'environ 152,000 à environ 65,000 lignes.
Pourquoi les solutions existantes ont échoué
Adapter le vocabulaire d'un modèle n'est pas une idée nouvelle. Les méthodes de référence dans la littérature, telles que fast vocabulary transfer (FVT), multi-word tokenization (MWT) et l' in-place tokenizer expansion (in-place BPE) de Liquid AI, qui poursuit l'entraînement BPE à partir du vocabulaire original, réduisent déjà la fragmentation. Lorsque nous les avons testées sur notre problème, nous avons trouvé deux limitations.
Elles choisissent les tokens selon la fréquence, et non selon le coût. Une expression qui apparaît souvent dans l'entrée a plus de valeur pour elles qu'une expression qui apparaît moins souvent dans la réponse, même si la seconde est la plus coûteuse à servir.
Elles travaillent sur une seule couche. Elles ajustent soit la façon dont les mots sont découpés en morceaux, soit fusionnent des phrases entières en un seul token. Aucune de ces trois méthodes ne fait les deux sous le même critère. Et le plus grand gaspillage du grader se trouvait précisément dans les longues séquences répétées, comme l'enveloppe JSON, qu'une méthode de sous-mots n'atteint qu'après avoir fusionné chaque partie, une par une.
Comment nous l'avons résolu
VocabX répond aux deux limitations, plus un troisième problème qui apparaît sur la voie évidente pour résoudre le premier.
D'abord, nous avons changé la question. Au lieu de demander combien de tokens un candidat économise, nous demandons combien de coût et de temps il économise. Chaque token éliminé est multiplié par le prix du champ dans lequel il apparaît : prompt système, message utilisateur ou réponse du modèle. Dans le cas que nous avons mesuré, le grader, un token économisé dans la réponse vaut 7.4 fois un token économisé dans l'entrée, et le vocabulaire est construit en conséquence.
Ensuite, nous travaillons sur les deux couches à la fois. Revenons à la société de transport : on peut réduire les cartons en emballant mieux chaque article, ou en reconnaissant que le même kit de douze articles est expédié chaque semaine et en envoyant le kit dans un seul carton. VocabX fait les deux. Au niveau des sous-mots, il reconstruit la façon dont les mots du domaine sont découpés. Au niveau multi-mots, il recherche des séquences entières qui se répètent, des expressions courtes aux lignes complètes et aux enveloppes JSON, et transforme chacune en un token unique, que nous appelons token macro. Les deux couches sont choisies selon le même critère de coût, chacune avec son propre budget.
Pour trouver ces séquences, nous utilisons cinq mineurs, des recherches automatiques de séquences qui se répètent dans le corpus, chacun spécialisé dans un type de répétition : les mots longs, les lignes entières, les expressions, les phrases complètes et les structures avec ponctuation telles que JSON et les balises. En moyenne sur huit corpus, c'est le dernier qui a le plus contribué, et sur le code il a représenté à lui seul 17.5 points. Sans les cinq, la réduction de tokens sur le grader chuterait de 55.6 points.
Troisièmement, nous estimons ce que l'échantillon ne peut pas voir. Choisir les tokens selon le coût exige de savoir combien chaque candidat économise encore après ceux déjà choisis. Mesurer cela exactement nécessiterait de retraiter tout le corpus après chaque choix, des dizaines de milliers de fois. Une façon courante de procéder à grande échelle est de mesurer sur un échantillon de documents, et alors un candidat absent de l'échantillon obtient un gain nul.
Une expression qui apparaît 37 fois dans 50,000 documents n'apparaît dans un échantillon de 400 documents qu'environ 26% du temps. Dans un corpus de contrats, seuls 16.6% des candidats apparaissent dans un échantillon de 400 documents ; les autres ne sont jamais évalués.
Le gain d'un candidat comporte deux parties. L'une est combien il économise sur l'ensemble du corpus, ce qui peut être compté exactement, sans échantillon. L'autre est combien de cette économise n'est pas encore couvert par les tokens déjà choisis, et seule cette partie doit être estimée. Pour les candidats que l'échantillon ne peut pas voir, nous utilisons une estimation statistique fondée sur le comportement de ceux qu'il peut voir, au lieu de zéro. Un candidat rare dans l'échantillon mais fréquent dans le corpus revient dans la course.
Ce seul changement, avec le même échantillon et le même budget, a augmenté la réduction de tokens sur un corpus de contrats de 44.7% à 52.8%.
Ce qui a changé dans le grader
Pour mesurer l'effet réel, nous avons entraîné sept versions du grader avec le même modèle de base, les mêmes données, la même recette et la même graine. La seule différence entre elles est le tokenizer. Toutes ont exécuté les mêmes 500 requêtes sur la même machine de test, avec un GPU RTX 5090 et le serveur d'inférence vLLM, et le coût a été calculé à partir du temps d'exécution mesuré.
La réponse du modèle est passée de 350 à 101 tokens en moyenne. Le coût a baissé de 77.0%. La qualité, mesurée par le score bench, qui combine la précision de la notation et la précision de l'écartement des dissertations hors sujet ou non conformes aux règles, est passée de 0.703 à 0.810.
Y parvenir a exigé une correction de cap. La première version du vocabulaire fusionnait la note de chaque compétence avec le JSON environnant en un seul token macro. C'était l'option la plus compacte, mais la qualité a chuté : son score sur le banc d'essai était de 0.689, en dessous du 0.703 de l'évaluateur de production. Avec la note à l'intérieur de la macro, chaque combinaison de note et de structure devenait une variante différente du même token, et le modèle choisissait les deux en une seule étape. Donner à la note son propre token coûtait 2 tokens supplémentaires par réponse, portait le score du banc d'essai à 0.810 et, dans la mesure, était même moins cher : une réduction de 77.0 %, contre 73.3 % pour la version fusionnée.
La leçon s'applique au-delà de l'évaluateur. La compression a un coût lorsque la partie compressée porte précisément la décision que le modèle existe pour prendre. L'objectif n'est pas le vocabulaire le moins cher possible, mais le moins cher qui préserve les tokens qui comptent.
Au-delà de l'évaluateur
Pour savoir si le gain était propre à notre cas, nous avons comparé VocabX aux trois méthodes de référence sur cinq domaines publics (contrats, articles médicaux, articles scientifiques, actualités et code Python) et trois familles de modèles (Qwen3, Llama-3.1 et Gemma-3). Toutes les méthodes utilisaient les mêmes documents d'extraction et de test, ainsi que le même plafond de vocabulaire.
VocabX a compressé davantage que la méthode de référence la plus performante dans les quinze combinaisons, avec 1.2 à 9.3 points d'écart. En coût d'inférence estimé, la version élaguée de VocabX a également mené dans les quinze, avec des marges moyennes de 10.2 points sur Qwen3, 7.5 sur Llama-3.1 et 13.6 sur Gemma-3. Sur les contrats, la version élaguée a atteint une réduction de 62.6 % des tokens avec 113,426 entrées de vocabulaire, contre 61.8 % pour la meilleure configuration BPE in-place, qui en utilise 207,803.
Ne payer que pour les tokens qui comptent
VocabX ne rend pas le modèle plus intelligent. Il empêche le modèle de payer pour du texte qu'il n'a pas besoin d'écrire pièce par pièce, et de scorer un vocabulaire qu'il n'utilisera jamais. Dans notre évaluateur, cela a réduit le coût d'inférence mesuré de 77 %, avec le même modèle de base et la même recette d'entraînement.
La spécialisation commence généralement par les données et les poids. Elle peut aussi commencer une couche plus tôt, dans le vocabulaire.
La méthode complète, les tableaux de chaque expérience et les interventions écartées figureront dans l'article sur VocabX, que nous publierons bientôt.
Sources
- Dharma-AI. « VocabX : Cost-Weighted Vocabulary Adaptation for Domain-Specific Language Models. » En préparation (2026).
- Gee, Leonidas, et al. «Fast vocabulary transfer for language model compression. » EMNLP Industry Track (2022).
- Gee, Leonidas, et al. « Multi-word tokenization for sequence compression. » EMNLP Industry Track (2023).
- Smith, Jimmy T.H., et al. «In-Place Tokenizer Expansion for Pre-trained LLMs. » arXiv:2607.15232 (2026).
Pour aller plus loin
- Même cluster, 33 points d'utilisation en plus : ce qui a changé, c'est l'ordre
- Gestion des GPU : pourquoi les GPU inactifs sont les nouveaux avions cloués au sol
- Pourquoi la spécialisation est inévitable
- La spécialisation bat l'échelle : une variable stratégique que la plupart des décisions d'approvisionnement en IA négligent
- Dégénérescence du texte : un mode de défaillance en production que la plupart des benchmarks ne suivent pas
Explorer Dharma AI sur Hugging Face pour essayer nos démos, télécharger nos modèles open source et découvrir comment les systèmes d'IA spécialisés surpassent les modèles à usage général dans de vraies applications d'entreprise.