🚀 Tokenizer spécialisé : -77% sur le coût d’inférence
Découvrez comment un tokenizer spécialisé et un vocabulaire des LLM réduisent de 77% le coût d’inférence d’un modèle compact, sans changer ses poids.
Un vocabulaire spécialisé peut réduire de 77 % le coût d'un LLM
Un modèle de langage spécialisé est souvent optimisé en retravaillant ses données d'entraînement, ses poids ou son infrastructure de déploiement. Mais il existe aussi un poste plus discret qui peut peser lourd sur la facture : le tokenizer. Il découpe le texte en unités appelées tokens. Et le tokenizer hérité d'un modèle généraliste n'est pas forcément bien calé sur le vocabulaire, la langue ou le format de sortie d'une application donnée.
Dharma-AI décrit une expérimentation sur un correcteur automatique de dissertations en portugais, basé sur Qwen3-4B. En remplaçant le vocabulaire d'origine par un vocabulaire spécialisé, l'équipe rapporte une baisse de 77 % du coût d'inférence. Tout le reste reste identique : pas de changement du modèle de base, ni de la recette d'entraînement. Dans leurs tests, la réponse moyenne passe de 350 à 101 tokens, et le score de qualité progresse dans leur évaluation.
C'est intéressant, mais il ne faut pas en tirer une règle du type « tous les modèles peuvent économiser 77 % ». L'expérience pointe surtout un levier souvent sous-estimé : savoir d'où vient le coût, adapter le vocabulaire aux usages réels, et vérifier que la compression ne nuit pas aux décisions du modèle.
Pourquoi le tokenizer compte dans un modèle spécialisé
Un tokenizer transforme le texte en tokens que le modèle peut traiter. Selon le vocabulaire appris pendant la préparation du modèle, un mot peut correspondre à un seul token ou être découpé en plusieurs morceaux.
Dans un modèle généraliste, ce vocabulaire doit couvrir un maximum de cas : plusieurs langues, différents domaines et des formats très variés (conversations, code, articles scientifiques, documents juridiques). C'est logique, parce que le modèle est censé s'adapter à tout.
Le problème arrive quand on réduit brutalement le champ d'usage. Un outil de rédaction juridique en français, un assistant qui classe des dossiers administratifs, ou un service qui renvoie systématiquement du JSON n'exploitent pas toute la diversité de tokens d'un modèle généraliste.
La fragmentation répétée a un coût opérationnel
Dans le correcteur décrit par Dharma-AI, les réponses ont une structure assez répétitive : une enveloppe JSON, des noms de compétences et des formulations d'évaluation. Le tokenizer d'origine découpait certaines séquences fréquentes en plusieurs tokens. Résultat : le modèle devait générer davantage d'unités pour produire le même contenu.
Ce genre de fragmentation peut aussi apparaître dans des contrats (clauses standard), dans des API (noms de champs) ou dans des expressions métier qu'on retrouve partout. En soi, une occurrence isolée ne pose pas grand-chose. Mais répétée sur des milliers de requêtes, elle augmente le nombre de tokens générés. Et donc le temps de décodage et les ressources consommées.
Il y a un autre point : chaque token généré consomme du calcul. En plus, la dernière couche (LM head) doit produire un score pour chaque entrée du vocabulaire. Donc un vocabulaire trop large peut coûter même si, en pratique, une partie de ses entrées n'est presque jamais utilisée dans l'application.
Dans l'étude, le vocabulaire initial compte environ 151 669 entrées, contre environ 64 767 pour le vocabulaire spécialisé. Attention toutefois : ce n'est pas "gratuit" de réduire. Si on coupe trop, on risque de mal représenter des éléments importants (noms propres, termes techniques, valeurs que le modèle doit distinguer).
Le bon niveau d'optimisation dépend de l'usage
Mieux vaut partir de la tâche, pas d'une règle de compression. Un modèle qui gère plusieurs langues, des sujets imprévisibles et des formats variés a intérêt à garder une couverture large. À l'inverse, un système qui travaille sur un corpus stable et produit des sorties très structurées a plus de marge.
La question à se poser est simple : quelles séquences le système lit le plus souvent, et surtout lesquelles écrit-il à répétition ? L'analyse des journaux de production (dans le respect des règles de confidentialité et du RGPD) peut aider à repérer les formats récurrents. Mais il faut anonymiser les données sensibles et ne pas confondre fréquence historique et usage futur : si le produit évolue, certaines formulations "rares" aujourd'hui peuvent devenir importantes demain.
Pourquoi générer un token coûte plus cher que le lire
Réduire le nombre de tokens d'entrée semble être une optimisation naturelle. Sauf que l'entrée et la sortie ne coûtent pas forcément pareil. Pour comprendre, il faut distinguer deux phases d'inférence : le prefill et le decode.
Pendant le prefill, le modèle traite toute la requête d'entrée. Pendant le decode, il génère la réponse token par token. Pour chaque nouveau token produit, il refait un pas de calcul et doit notamment consulter ses poids ainsi que l'état du contexte déjà traité (stocké dans le cache KV). Et comme le contexte grandit avec la longueur du prompt, ce coût suit.
Sur de petits modèles servis en lots de taille modérée, la génération peut aussi être limitée par la vitesse à laquelle les données transitent depuis la mémoire GPU. Dans ce cas, réduire la longueur de la réponse peut rapporter plus que réduire autant celle du prompt. Le batching (regrouper plusieurs requêtes) aide à amortir certains coûts, mais ne les supprime pas. Le résultat dépend aussi du matériel, de la taille des lots, du contexte et du serveur d'inférence.
Un coût marginal différent selon ce que vous économisez
Dans les tests rapportés par Dharma-AI, un token généré coûte 7,4 fois plus qu'un token "lu" (dans l'entrée). Ce ratio dépend de leur configuration de test et ne doit pas être pris comme une constante universelle. Mais l'idée est transférable : le coût marginal n'est pas le même selon l'endroit où le token apparaît, ni selon la façon dont le modèle est servi.
On peut résumer le calcul de manière volontairement simplifiée :
Gain estimé = tokens supprimés dans les entrées × coût de lecture + tokens supprimés dans les sorties × coût de génération.
Si un tokenizer est choisi uniquement parce qu'il réduit le nombre total de tokens, on peut rater l'objectif économique. Si votre système produit beaucoup de texte répétitif, il est souvent plus rentable de raccourcir la sortie que de "gratter" quelques tokens dans une longue consigne.
C'est exactement la logique utilisée par VocabX : attribuer une valeur différente aux tokens selon qu'ils se trouvent dans les instructions système, les messages utilisateur ou les réponses du modèle.
La taille du vocabulaire intervient à chaque génération
La tête de sortie transforme l'état interne du modèle en scores pour chaque token possible. Concrètement, elle contient une matrice de paramètres associée aux entrées du vocabulaire. Pour un modèle comme Qwen3-4B, cet ensemble représenterait près de 10 % des paramètres, selon l'article.
Conséquence : à chaque génération, le modèle doit calculer des scores pour les entrées disponibles, même si certaines sont très rarement utiles pour la tâche. Une entrée peu fréquente peut alors contribuer au coût de sortie autant qu'une entrée "utile".
Réduire la taille du vocabulaire peut donc aider, à condition de garder les unités nécessaires à la qualité. Et il faut garder deux mécanismes en tête : un tokenizer plus efficace peut réduire le nombre de tokens produits, mais l'ajout de nouveaux tokens peut augmenter la taille du vocabulaire et donc le coût dans la tête de sortie. Autrement dit, on peut diminuer le nombre de tokens tout en payant plus ailleurs. L'optimisation doit regarder ces effets ensemble, pas seulement le nombre d'unités économisées.
Ce que montrent les résultats, et leurs limites
Sur le correcteur portugais, Dharma-AI indique avoir entraîné sept versions à partir du même modèle de base, avec les mêmes données, la même recette et la même graine aléatoire. Seul le tokenizer changeait. Toutes les versions traitent les mêmes 500 requêtes sur une machine équipée d'un GPU RTX 5090, avec vLLM comme serveur d'inférence. Le coût est calculé à partir du temps d'exécution mesuré.
La réponse moyenne passe de 350 à 101 tokens. L'équipe annonce une baisse de 77,0 % du coût, tandis que le score de leur banc d'évaluation monte de 0,703 à 0,810. Ce score combine la précision de la notation et la détection des dissertations hors sujet ou contraires aux règles définies.
Ces chiffres ne prouvent pas que le tokenizer améliore généralement les capacités d'un modèle. Ils montrent plutôt que, dans cette configuration précise, une représentation plus adaptée à la tâche a réduit le travail nécessaire pour produire la sortie, sans dégrader la qualité mesurée. Et même si c'est encourageant, le score en hausse mériterait d'être vérifié sur d'autres jeux de données, avec des évaluations indépendantes.
Comparaisons sur plusieurs domaines
L'équipe compare aussi VocabX à trois méthodes de référence sur cinq domaines publics : contrats, articles médicaux, publications scientifiques, actualités et code Python. Les tests couvrent trois familles de modèles : Qwen3, Llama-3.1 et Gemma-3. Dans les quinze combinaisons annoncées, VocabX obtient une réduction de tokens supérieure à la meilleure méthode de référence, avec une marge de 1,2 à 9,3 points.
Pour le coût d'inférence estimé, la version "élaguée" de VocabX arrive également en tête dans les quinze comparaisons. Les marges moyennes annoncées sont de 10,2 points sur Qwen3, 7,5 sur Llama-3.1 et 13,6 sur Gemma-3. Sur le corpus de contrats, la méthode atteint 62,6 % de réduction avec 113 426 entrées de vocabulaire, contre 61,8 % pour la meilleure configuration de référence (207 803 entrées).
Le hic : ces résultats proviennent d'un travail encore en préparation au moment de la publication de l'article source. Entre-temps, les chiffres peuvent changer. Les tests restent aussi "cadrés" (corpus, configurations). Rien ne remplace un essai sur vos propres requêtes, votre matériel et vos contraintes de service.
Comment décider si le projet est pertinent
Avant de modifier un tokenizer en production, il faut vérifier que le bénéfice attendu compense les coûts d'adaptation, d'entraînement et de maintenance. Une démarche simple peut tenir en quatre étapes :
- Mesurer le profil réel des requêtes. Séparez tokens d'entrée et de sortie, longueur des contextes, formats récurrents et volumes par type de tâche.
- Identifier un domaine suffisamment stable. Un vocabulaire spécialisé colle mieux à un flux homogène qu'à un assistant généraliste utilisé de façon imprévisible.
- Évaluer les sorties et les erreurs métier. Ne vous contentez pas d'un score "de compression". Pour un correcteur, mesurez aussi la qualité des notes, la cohérence des commentaires et le traitement des cas atypiques.
- Comparer le coût complet. Le coût ne s'arrête pas à l'inférence : il faut aussi compter préparation, entraînement, maintenance et évolution des formats. Une économie d'inférence ne devient utile que si elle dépasse ces coûts dans la durée.
Pour une entreprise française ou européenne, cette analyse doit aussi intégrer la gouvernance des données. Les corpus utilisés pour extraire des expressions récurrentes peuvent contenir des données personnelles, des informations de santé ou des éléments contractuels. Le respect du RGPD et la minimisation des données ne sont pas "à côté du sujet" : ils conditionnent comment on peut constituer, conserver et traiter le corpus.
Conclusion : un levier Ă mesurer avant de l'adopter
L'expérience de Dharma-AI rappelle un point simple : dans beaucoup de systèmes, un modèle spécialisé hérite d'un tokenizer pensé pour un usage bien plus large. Dans certains cas, ça se traduit par des sorties plus longues que nécessaire et par une tête de sortie "surdimensionnée" pour la tâche.
Adapter le vocabulaire peut alors devenir un levier de coût concret, surtout sur des petits modèles qui génèrent des réponses répétitives.
Mais le chiffre de 77 % n'est pas une promesse universelle. Le gain dépend du profil des requêtes, du poids des tokens générés dans la facture, et de la capacité à préserver la qualité métier. La méthode doit donc être testée sur des données représentatives, avec des indicateurs de coût et de qualité suivis séparément.
La bonne décision, ce n'est donc pas "spécialiser par défaut". C'est de mesurer l'impact, au même titre que les données, le modèle et l'infrastructure. Pour aller plus loin sur les résultats et les choix méthodologiques, consultez l'article de Dharma-AI sur Hugging Face, puis testez l'approche sur un flux représentatif avant de la généraliser.
Comment VocabX adapte le vocabulaire au coût réel
VocabX (la méthode présentée par Dharma-AI) combine trois idées : pondérer les économies selon le coût des tokens, optimiser à la fois les sous-mots et les séquences répétées, puis estimer la valeur de candidats qui n'apparaissent pas dans l'échantillonnage.
Optimiser les sous-mots et les séquences complètes
Le premier niveau touche à la façon de découper les mots. Un vocabulaire généraliste peut représenter un terme "domaine" par plusieurs morceaux. VocabX cherche donc une segmentation mieux adaptée au corpus.
Le second niveau repère des séquences plus longues qui reviennent souvent : expressions, phrases, lignes entières, ou structures de données. L'idée est de pouvoir représenter ces morceaux sous forme d'un seul token, appelé macro-token. Dans le correcteur, cela s'applique notamment à l'enveloppe JSON et aux formulations récurrentes.
La méthode s'appuie sur cinq outils de recherche automatique, les miners, chacun spécialisé dans un type de répétition : mots longs, lignes, expressions, phrases, et structures avec ponctuation (comme le JSON ou des balises). Dans les résultats rapportés, la recherche de structures avec ponctuation apporte une contribution majeure : sur les corpus de code évalués, ce composant atteint à lui seul 17,5 points de réduction.
Le point important, ce n'est pas de transformer "tout ce qui revient" en token. C'est de sélectionner les séquences qui donnent un gain réel, tout en respectant un budget de vocabulaire. VocabX applique un critère de coût aux deux niveaux, mais avec des budgets distincts.
Corriger les biais de l'Ă©chantillonnage
Estimer précisément le gain de chaque candidat après chaque sélection coûterait trop cher : il faudrait retraiter tout le corpus des milliers de fois. Les approches à grande échelle utilisent donc souvent un échantillon de documents.
Sauf que ça crée un biais : un candidat absent de l'échantillon peut être considéré à tort comme inutile. L'exemple donné par l'équipe illustre bien le problème : une expression présente 37 fois sur 50 000 documents n'apparaît que dans environ 26 % des cas dans un échantillon de 400 documents. Dans un corpus de contrats, seuls 16,6 % des candidats apparaissaient dans un échantillon de cette taille.
VocabX traite ça en séparant le calcul. Le nombre d'occurrences dans le corpus complet est compté précisément. En revanche, la "part" du gain restant après sélection d'autres tokens doit être estimée. Pour les candidats non observés dans l'échantillon, la méthode utilise une estimation statistique plutôt que de leur attribuer un gain nul.
Sur le corpus de contrats, cette correction fait passer la réduction de tokens de 44,7 % à 52,8 %, avec le même échantillon et le même budget. Ce gain vient de l'évaluation des candidats, pas d'une amélioration automatique de la qualité du modèle.
Préserver les éléments qui portent la décision
La compression n'est pas toujours gagnante. Lors de la première itération, l'équipe a fusionné dans un même macro-token la note associée à une compétence et la structure JSON qui l'entoure. La réponse devenait plus compacte, mais le modèle devait choisir en une seule étape un token combinant structure et décision.
Le score d'évaluation descend alors à 0,689 (contre 0,703 auparavant). En séparant la note du reste de la structure, la réponse utilise en moyenne deux tokens de plus, mais le score remonte à 0,810. Dans les chiffres publiés, cette version séparée réduit aussi davantage le coût : 77,0 %, contre 73,3 % pour la version fusionnée.
C'est un compromis très concret. Si un token contient une décision centrale pour le produit, compresser "avec tout le contexte" peut rendre l'apprentissage ou la génération moins fiables. Le but n'est donc pas de minimiser le vocabulaire à tout prix : c'est de réduire le coût sans effacer les distinctions nécessaires à la tâche.