Dharma-AI réduit le vocabulaire de Qwen3-4B et abaisse de 77% le coût d'inférence

L'équipe brésilienne Dharma-AI montre ce que l'on peut économiser en touchant à un élément que l'on considère d'ordinaire comme immuable dans un modèle : le tokenizer. Dans un système de production qui corrige des rédactions en portugais sur la base de Qwen3-4B, le nouveau vocabulaire a ramené la réponse moyenne de 350 à 101 tokens. Le coût d'inférence mesuré a chuté de 77,0%, tandis que le score au benchmark est passé de 0,703 à 0,810. Le modèle de base, les données et la recette d'entraînement sont restés identiques. La méthode a été baptisée VocabX. L'article complet n'est pas encore publié, et les chiffres proviennent de la version actuelle du preprint, qui est en cours de relecture par les pairs.

Où le modèle correcteur payait trop cher

Le grader reçoit une rédaction, un sujet et des textes d'appui, puis renvoie un JSON contenant une note et un commentaire pour chaque compétence. Son tokenizer était resté celui d'origine de Qwen3-4B, c'est-à-dire un tokenizer conçu pour de nombreuses langues et de nombreux types de textes. Il découpait en dizaines de fragments précisément ce que le modèle écrit dans chaque réponse : la même enveloppe JSON, les noms des compétences, les formulations types des évaluations. En outre, à chaque étape de génération, le modèle calculait des probabilités pour 151 669 entrées de vocabulaire, dont la plupart n'apparaissent presque jamais dans cette tâche.

Le coût est ici asymétrique. Lors du prefill, le modèle traite toute l'entrée en une seule passe, et le facteur limitant est le calcul. Lors du decode, chaque token exige une passe complète, le GPU attend surtout des données en provenance de la mémoire, et la lecture du KV-cache s'ajoute à celle des poids.

Dans le cas mesuré, un token généré coûte 7,4 fois plus cher qu'un token lu. Ce rapport dépend du matériel, de la taille du batch et de la longueur du contexte, et il peut être plus élevé. Sur un modèle de la taille de Qwen3-4B, la matrice de la LM head représente près de 10% des paramètres, et elle est lue intégralement à chaque token généré.

Une ligne de vocabulaire superflue coûte donc autant qu'une ligne fréquente.

Des tokens choisis selon leur coût, pas leur fréquence

Les méthodes existantes, comme le fast vocabulary transfer (FVT), la multi-word tokenization (MWT) et l'in-place BPE de Liquid AI, sélectionnent leurs candidats selon la fréquence et n'opèrent que sur un seul niveau. VocabX change de critère : chaque token économisé est multiplié par le coût du champ où il apparaît (prompt système, message de l'utilisateur ou réponse du modèle). Dans ce cas d'usage, un token économisé dans la réponse pèse 7,4 fois plus qu'un token économisé dans l'entrée. La méthode travaille simultanément sur deux couches : celle des sous-mots et celle des multi-mots, où les fragments répétitifs sont fusionnés en un seul macro-token. Cinq mineurs servent à repérer ces fragments :

• les mots longs ;
• les lignes entières ;
• les expressions ;
• les phrases complètes ;
• les structures avec ponctuation, comme le JSON et les balises.

Le dernier mineur apporte la plus forte contribution : en moyenne sur huit corpus, et à lui seul 17,5 points sur le code. Sans ces cinq mineurs, la réduction du nombre de tokens sur le grader reculerait de 55,6 points.

L'estimation du gain à partir d'un échantillon de documents pose un problème distinct. Une expression qui apparaît 37 fois dans 50 000 documents n'entre dans un échantillon de 400 documents que dans 26% des cas. Dans un corpus de contrats, seuls 16,6% des candidats entrent dans un tel échantillon, et tous les autres se voient attribuer un gain nul. L'équipe calcule exactement la part du gain qui peut être calculée sur l'ensemble du corpus, et estime statistiquement la part non couverte. Sur les contrats, cela a fait passer la réduction du nombre de tokens de 44,7% à 52,8%, avec le même échantillon et le même budget.

La macro qui a avalé la décision du modèle

Pour la mesure, sept versions du grader ont été entraînées sur la même base, avec les mêmes données, la même recette et le même seed. Seul le tokenizer différait. Toutes ont traité les mêmes 500 requêtes sur une RTX 5090 avec vLLM, et le coût a été calculé d'après le temps mesuré.

La première version fusionnait la note de chaque compétence avec le JSON environnant en un seul macro-token. C'était la plus compacte (moins 73,3% de coût), mais la qualité est tombée à 0,689, contre 0,703 pour la version de production. À l'intérieur de la macro, chaque combinaison de note et de structure devenait une variante de token distincte, et le modèle devait tout choisir en une seule étape.

Un token dédié à la note a coûté deux tokens supplémentaires par réponse, mais il a fait remonter le score à 0,810, et la baisse du coût a atteint 77,0%.

La vérification sur un matériau plus large donne le tableau suivant : cinq domaines (contrats, articles médicaux, articles scientifiques, actualités, code Python) et trois familles de modèles (Qwen3, Llama-3.1, Gemma-3). VocabX compresse plus fortement que la meilleure référence dans les 15 combinaisons, avec un écart de 1,2 à 9,3 points. Sur l'estimation du coût d'inférence, la version à vocabulaire réduit l'emporte aussi partout : en moyenne de 10,2 points sur Qwen3, de 7,5 sur Llama-3.1 et de 13,6 sur Gemma-3. Sur les contrats, elle obtient 62,6% de réduction avec 113 426 entrées de vocabulaire, tandis que la meilleure variante d'in-place BPE atteint 61,8% avec 207 803 entrées.

Quand toucher au tokenizer

Cette approche convient aux modèles de production étroits dont les réponses ont une structure répétitive : évaluateurs, extracteurs, générateurs de JSON, assistants juridiques et assistants de code. Plus la réponse contient de gabarit et plus le decode est limité par la mémoire, plus l'effet est marqué. Le gain se décompose en trois parts : une réponse plus courte, une matrice de LM head plus petite et moins de lectures à chaque étape.

Une mise en garde s'impose toutefois. Si le fragment compressé contient la décision pour laquelle le modèle existe (ici, la note), il ne faut pas l'enfouir dans un macro-token. L'objectif est d'obtenir le vocabulaire le moins cher qui conserve les tokens significatifs. Sans cela, on peut économiser sur le coût et perdre en qualité.