Gigatoken : un tokeniseur BPE en Rust qui encode le texte à 24,53 Go/s, jusqu'à 989 fois plus vite que HuggingFace Tokenizers
Marcel Rød, doctorant à Stanford, a publié Gigatoken, un tokenizer BPE (byte-pair encoding) écrit en Rust sous licence MIT, capable d'encoder du texte à 24,53 Go/s sur une seule machine. Le benchmark de référence, réalisé avec le tokenizer GPT-2 sur le corpus owt_train.txt de 11,9 Go et une machine bi-socket AMD EPYC 9565 à 144 cœurs, place Gigatoken loin devant ses concurrents : tiktoken d'OpenAI atteint 36,0 Mo/s et HuggingFace Tokenizers 24,8 Mo/s sur le même matériel, soit des écarts de 681 fois et 989 fois. Sur un Apple M4 Max à 16 cœurs, Gigatoken traite le même corpus à 8,79 Go/s (1268 fois plus vite que HuggingFace, 140 fois plus vite que tiktoken), et sur un AMD Ryzen 7 9800X3D grand public, 6,27 Go/s, soit 106 et 68 fois plus rapide. La bibliothèque, disponible sur PyPI en version 0.9.0 depuis le 21 juillet 2026 via pip install gigatoken, couvre 23 familles de tokenizers dont GPT-2, GPT-OSS, Llama 3 à 4, Qwen 2 à 3.6, DeepSeek V3/R1/V4, GLM 4 et 5, Kimi K2, Nemotron 3, Phi-4, OLMo 2/3, ModernBERT, Gemma et Mistral. Cette performance change la donne pour un maillon de la chaîne d'entraînement des modèles de langage rarement optimisé, alors même qu'il conditionne la vitesse de préparation des jeux de données massifs utilisés pour l'entraînement des LLM. Un tokenizer 989 fois plus rapide réduit drastiquement le temps et le coût de calcul nécessaires pour préparer des corpus de plusieurs téraoctets, une étape jusqu'ici considérée comme un goulot d'étranglement secondaire face à l'entraînement lui-même. Gigatoken propose deux modes d'utilisation : un mode de compatibilité qui encapsule un tokenizer HuggingFace ou tiktoken existant en préservant une parité exacte des résultats, mais avec un gain plus modeste de 200 à 300 fois selon Marcel Rød en raison du surcoût lié à Python, et une API native en Rust qui lit directement les fichiers et produit les chiffres records annoncés. Les gains ne proviennent pas d'une amélioration de la boucle de fusion BPE elle-même, mais de deux optimisations généralement négligées. La première concerne la prétokenisation : la plupart des implémentations délèguent cette étape à un moteur d'expressions régulières, quand Gigatoken utilise une machine à états écrite à la main. Le journal d'optimisation du projet détaille une progression méthodique, d'une base en fancy-regex à environ 47 Mio/s jusqu'à 1049 Mio/s en mono-thread, en passant par une table de correspondance de 256 octets pour un dispatch en temps constant, la technique SWAR (SIMD Within A Register) traitant huit octets à la fois sans intrinsèques spécifiques à une architecture, puis une exploitation du parallélisme d'instructions via deux curseurs indépendants qui exploite les ports d'exécution inactifs du processeur. Au total, cette seule optimisation de la prétokenisation représente un gain de 22,3 fois par rapport à l'implémentation par expressions régulières. La seconde optimisation repose sur la mise en cache des pré-tokens déjà rencontrés, une technique que Marcel Rød décrit comme délicate à implémenter en pratique en raison de la croissance rapide du cache et de la distribution à longue traîne des mots, le tout combiné à une minimisation des interactions entre Python et les threads.
![Une tour à 15 274 €, deux GPU AMD et aucun abonnement cloud : on a testé l’IA locale à son maximum [Sponso]](/_next/image?url=https%3A%2F%2Fapi.lefilia.fr%2Fapi%2Fv1%2Fimages%2Farticle_5164055.png&w=1920&q=75)
