Hugging Face réécrit tokenizers en Rust avec du SIMD et encodage jusqu’à 30 fois plus vite
Le 21 septembre 2026, Hugging Face détaille la version 1 de sa bibliothèque tokenizers : même sortie que la v0.23, mais un encodage 3 à 30 fois plus rapide en monothread sur un Apple M4 Max grâce à un découpage par bitstream SIMD et un cache de mots. Les équipes qui servent du LLM ont une raison mesurée de regarder le tokenizer, devenu le nouveau goulot à mesure que les modèles accélèrent.
21 septembre 2026. Hugging Face publie sur son blog un long billet technique sur la future version 1 de sa bibliothèque tokenizers, signé par Arthur Zucker, Stas Bekman, Matthieu Futeral et Lysandre Debut. La v1 promet de produire exactement les mêmes identifiants de tokens que la v0.23, tout en encodant le texte 3 à 30 fois plus vite en monothread sur un Apple M4 Max. Pourquoi c’est important : le tokenizer n’a jamais été le goulot d’un pipeline de machine learning — jusqu’à ce que les modèles deviennent assez rapides pour que la CPU, et non la GPU, se mette à les affamer.
Le tokenizer, le goulot que personne ne regardait
La tokenisation est légère comparée au calcul lourd du modèle. Pourtant, à mesure que les modèles accélèrent et que les charges grossissent — entraînement sur des jeux massifs, service de nombreuses requêtes concurrentes, entrées longues traitées en boucle — l’équilibre se déplace. Un tokenizer trop lent finit par priver le modèle de données : la GPU attend que la CPU ait fini de convertir le texte.
C’est la raison d’être de la v1 : la tokenisation doit rester légère et suivre la charge. Un tokenizer convertit du texte en la liste d’entiers que lit un modèle, en quatre étapes — normalisation, pré-tokenisation, application du modèle, post-traitement. Huit des dix familles de modèles mesurées utilisent le byte pair encoding (BPE), qui part des octets d’un pré-token et fusionne de façon répétée la paire adjacente de rang le plus élevé. La boucle de fusion est le cœur du problème, et c’est là que la v1 concentre l’essentiel de son travail.
Cinq changements qui font la différence
Le billet documente cinq modifications structurantes, chacune réduisant le travail à un point différent du pipeline.
Le découpage en workspace. La crate unique devient un workspace : tk-encode est l’exécution requise, et tk-serialize, tk-convert et tk-train ne sont liés que lorsqu’une application en a besoin. Un service qui ne fait qu’encoder ne charge plus le code d’entraînement.
Le découpage par bitstream. Le BPE utilise une expression régulière pour découper le texte en pré-tokens. Cette regex est un paramètre fixe du modèle, jamais modifiée à l’exécution — inutile donc de faire tourner un moteur regex généraliste à chaque encodage. La v1 remplace cette regex par une fonction écrite à la main, nommée bitcannon, qui utilise les instructions SIMD du processeur : les octets de l’entrée sont vus comme des flux de bits parallèles, et les frontières tombent d’opérations booléennes sur des registres entiers, à raison de 64 octets par opération. La même idée anime Parabix pour le traitement de texte et simdjson pour le JSON.
Le cache de mots. Le texte réel contient des mots répétés. Comme le BPE produit toujours les mêmes identifiants pour un pré-token donné, la v1 mémorise le résultat après l’avoir traité une fois, dans un cache par thread. Les occurrences suivantes sautent la fusion entièrement — d’autant plus rentable que la part des mots répétés croît avec la taille de l’entrée.
La boucle de fusion sans allocation. L’implémentation précédente allouait de la mémoire à chaque appel et reconstruisait une file de priorité pour chaque pré-token. La v1 réutilise un tampon de travail appartenant à l’appelant, stocke les symboles dans un tableau plat, relie les symboles adjacents par leur position, et traite un lot de pré-tokens en un seul appel modèle. Chaque paire candidate est compactée dans un entier 64 bits, le rang de fusion dans les bits de poids fort : comparer deux candidats devient une simple comparaison d’entiers, et « pas de fusion ici » est la plus grande valeur possible, ce qui élimine une branche.
Le parallélisme natif. Un tokenizer partagé encode depuis plusieurs threads à la fois, chaque thread puisant son tampon et son cache dans son propre sous-pool, sans file d’attente sur un verrou unique.
Les chiffres : 3 à 30 fois plus vite, 76 % de passage à l’échelle
Sur les dix familles de modèles couvertes par le chemin d’encodage de la v1, le texte est encodé 3 à 30 fois plus vite que la v0.23 en monothread sur un Apple M4 Max — le bas de fourchette pour t5-base, le haut pour gpt2. La montée en charge atteint 76 % du passage à l’échelle linéaire sur huit cœurs physiques. Et tout au long de ces changements, la v1 produit exactement les mêmes identifiants de tokens que la bibliothèque publiée : la parité de sortie est vérifiée par un hachage FNV-1a sur les identifiants, qui doit correspondre à la ligne de base à l’identique.
La méthodologie est aussi stricte que les résultats : une seule boucle de mesure pour tous les moteurs, le chargement du vocabulaire exclu du chronométrage, les cœurs épinglés à huit cœurs physiques distincts, et des médianes calculées uniquement sur les cellules que chaque moteur a réellement exécutées. Le tout est reproductible via le dépôt tokbench, avec une commande pour relancer les benchmarks sur son propre matériel.
# Installation du candidat à la version 1 (crates.io)
cargo add tokenizers --pre
# Encodage sans la dépendance d'entraînement (C++), si on n'encode que :
cargo add tokenizers --pre --no-default-features --features httpCe que ça change pour ceux qui servent du modèle
Le point qui intéresse les intégrateurs : la v1 garde la même API et la même sortie. Le seul changement est la version qu’on installe. La bibliothèque remercie IBM, NVIDIA et l’équipe ExecuTorch pour les correctifs et les tests sur une large gamme de matériel — un signal sur l’ampleur de la base concernée, du poste de travail au mobile.
Les liaisons Python enveloppent le même code, mais ajoutent un surcoût par appel qui n’est pas inclus dans les mesures. Pour les équipes qui servent des modèles à forte concurrence, c’est une précision importante : le gain réel dépend de la langue qu’on appelle, et la version Rust reste la référence.
La feuille de route vers 1.0.0 et au-delà
La v1 n’est pas encore finale : c’est un candidat à la publication disponible sur crates.io. Le chemin vers 1.0.0 passe par une implémentation d’encodage unique, pour que l’entraînement et l’inférence ne puissent jamais produire des tokenisations différentes, des offsets et masques optionnels calculés seulement quand on les demande, une refonte des normalisateurs et des liaisons Python simplifiées. Des liaisons C et C++ dédiées à l’inférence sont prévues pour ExecuTorch et llama.cpp, avec de possibles liaisons JVM, Swift et Go à suivre.
Après la 1.0.0, le projet explorera l’encodage côté GPU : le vocabulaire serait chargé une fois sur la carte, les positions de sortie calculées en parallèle, et les octets correspondants rassemblés sur la GPU — un composant optionnel destiné aux grands lots, soumis à prototypage et mesure.
La migration est sans friction par construction : on installe le candidat avec cargo add tokenizers --pre, l’API reste celle qu’on appelle déjà, et l’encodage produit les mêmes identifiants. Seul le build installé change. Pour les équipes qui ont un pipeline Rust, le basculement se joue en une ligne de configuration.
Verdict
Si vous servez du LLM en production avec de fortes concurrences ou de longues entrées, mesurez votre tokenizer avant de le croire innocent : un encodage 3 à 30 fois plus rapide, à sortie strictement identique, est un gain de latence et de CPU gratuit qui se branche en changeant une ligne d’installation. Si vous entraînez sur de grands jeux, la même logique s’applique à votre pipeline de données — la GPU ne devrait jamais attendre la CPU. La leçon à retenir est générale : à mesure que les modèles accélèrent, le goulot migre vers les étapes qu’on considérait comme négligeables, et c’est là que se cachent les gains les moins chers.