gigatoken : la tokenisation BPE poussée au débit disque

Le goulot d'étranglement que gigatoken attaque

Avant d'entraîner un modèle, il faut convertir le texte brut en identifiants. Sur un corpus de la taille d'OpenWebText, soit 11,9 Go d'après les tableaux du README, cette étape peut prendre plusieurs minutes avec les implémentations usuelles. gigatoken cible précisément ce moment : la tokenisation hors ligne d'un gros volume de texte, en amont de l'entraînement. Le projet se présente comme un remplacement direct de HuggingFace tokenizers, avec un mode compatibilité qui reprend l'interface existante. La cible est donc l'ingénieur qui a déjà un pipeline de préparation de données et qui veut réduire le temps passé entre le téléchargement d'un corpus et le premier pas d'optimisation. Le README insiste sur un point qui mérite d'être répété : HuggingFace tokenizers et tiktoken exécutent déjà leur cœur en Rust multithreadé. Le gain annoncé ne vient donc pas d'un simple passage de Python à Rust, mais d'une réorganisation plus profonde de la lecture des données et de la parallélisation.

Deux API, deux régimes de performance

Le README décrit deux chemins d'utilisation. Le premier, dit de compatibilité, enveloppe un tokenizer existant : gt.Tokenizer(hf_tokenizer).as_hf() renvoie un objet utilisable comme le tokenizer HuggingFace d'origine, avec encode_batch. Une variante existe pour tiktoken via as_tiktoken(). Le second chemin est l'API native : gt.Tokenizer("Qwen/Qwen3-8B") accepte un nom de modèle HuggingFace, puis gt.TextFileSource(["owt_train.txt"], separator=b"<|endoftext|>") décrit une source de fichiers, et tokenizer.encode_files(file_source) renvoie les identifiants. La différence architecturale est explicite dans le README : dans le mode natif, l'implémentation Rust lit les données directement, alors que le mode compatibilité doit passer par des structures Python. Le README prévient lui-même que la compatibilité exacte avec HuggingFace a un coût de performance non négligeable, et que le facteur 1000 ne s'applique pas dans ce mode. C'est la distinction la plus importante du projet, et elle est facile à manquer si l'on ne lit que le slogan en haut de page.

Ce que disent les tableaux de débit

Les mesures publiées portent sur owt_train.txt, 11,9 Go, encodé en entier sans découpage, sur trois machines : deux AMD EPYC 9565 totalisant 144 cœurs, un Apple M4 Max 16 cœurs, et un AMD Ryzen 7 9800X3D 16 cœurs. Sur la machine EPYC, GPT-2 atteint 24,53 GB/s contre 24,8 MB/s pour HuggingFace tokenizers et 36,0 MB/s pour tiktoken, soit un rapport de 989 et 681 respectivement. Le détail est instructif : les tokenizers lents côté HuggingFace (GPT-2, Phi-4, OLMo, Qwen) sont ceux où l'écart dépasse 500 fois, tandis que les tokenizers déjà rapides côté HuggingFace (Mistral 7B v0.3 à 354,7 MB/s, CodeLlama à 347,4 MB/s, Gemma 3 à 357,2 MB/s) ne sont plus qu'à un facteur 10 environ. Autrement dit, gigatoken ne supprime pas seulement un surcoût Python : il égalise des familles de tokenizers dont les implémentations de référence ont des performances très inégales. Sur le Ryzen, les écarts tombent à un facteur 13 à 110, ce qui montre que le gain dépend fortement du nombre de cœurs disponibles. Le README ne publie pas de chiffres pour le mode compatibilité.

Le mode compatibilité et sa promesse d'équivalence

Le README affirme qu'un effort substantiel a été fait pour que les sorties du mode compatibilité correspondent exactement à celles de HuggingFace tokenizers. C'est une affirmation forte, et elle n'est accompagnée d'aucune procédure de vérification dans le matériel fourni. Pour un pipeline d'entraînement, l'enjeu est réel : un décalage d'un seul identifiant sur un token spécial, par exemple au niveau du séparateur <|endoftext|>, modifie les frontières de documents et donc les données vues par le modèle. Le README ne détaille pas non plus quels tokenizers sont couverts par cette équivalence exacte, ni comment les cas limites (texte vide, séquences très longues, caractères hors vocabulaire) sont traités. La liste des tokenizers dans les tableaux couvre GPT-2, Phi-4, GPT-OSS, OLMo 2 et 3, Nemotron 3, Qwen 2 à 3.6, Llama 3 à 4, GLM 4 et 5, DeepSeek V3, R1 et V4, Kimi K2, Gemma 1 à 4, ModernBERT, Mistral 7B v0.3, TinyLlama, Phi-3 et CodeLlama. C'est large, mais cela reste une liste de modèles, pas une garantie de comportement identique sur des entrées arbitraires.

Les cas où gigatoken n'est pas le bon outil

Le projet optimise le débit sur de gros fichiers, pas la latence par appel. Une application qui tokenise une phrase à la fois, dans une boucle de service, ne verra probablement pas les facteurs annoncés : le coût de mise en place de la parallélisation et de la lecture directe ne s'amortit que sur de gros volumes. Le mode compatibilité, justement conçu pour les usages ponctuels, est décrit par le README comme nettement plus lent que le mode natif, sans que l'ampleur de l'écart soit publiée. Autre limite : l'API native attend des sources de fichiers, avec un séparateur en octets. Un flux qui n'est pas un fichier sur disque, par exemple des données générées en mémoire ou lues depuis un objet distant, ne rentre pas dans ce moule sans adaptation. Enfin, le README note que passer des structures Python à l'API native réintroduit une partie du surcoût d'interfaçage : la vitesse maximale suppose que les données restent côté Rust du début à la fin. Le projet n'a pas de release publiée au moment de la rédaction, ce qui signifie que l'installation se fait depuis la branche main ou depuis PyPI sans version épinglable.

Alternatives et différence d'approche

Face à gigatoken, deux références occupent le terrain. HuggingFace tokenizers est la bibliothèque de facto de l'écosystème transformers : elle couvre un très grand nombre de tokenizers, s'intègre nativement aux pipelines d'entraînement et de publication de modèles, et son API est stable. tiktoken, de son côté, est l'implémentation de référence pour les modèles OpenAI, avec une API minimale et une couverture volontairement restreinte. La différence d'approche de gigatoken tient à la lecture des données : là où les deux autres exposent principalement une fonction d'encodage appelée depuis Python sur des chaînes ou des listes de chaînes, gigatoken ajoute une couche qui lit les fichiers directement et répartit le travail sur les cœurs. C'est ce qui explique à la fois les débits élevés et la dépendance à une source de fichiers. Si votre pipeline tokenise déjà des lots en mémoire et que le goulot est ailleurs, par exemple dans le chargement du dataset, remplacer le tokenizer ne changera pas grand-chose. Le README ne propose pas de comparatif sur ce point.

Installation, licence et coût de suivi

L'installation se fait par pip install gigatoken. Le projet est publié sous licence MIT, ce qui autorise l'usage commercial, la modification et la redistribution, à condition de conserver l'avis de copyright et le texte de la licence. Le README ne mentionne aucune dépendance externe, aucun binaire précompilé ni aucune contrainte de plateforme au-delà des trois processeurs testés. Aucune release n'étant répertoriée, il n'existe pas de numéro de version à épingler dans un fichier de dépendances, ce qui complique la reproductibilité d'un environnement : un pip install aujourd'hui et dans six mois peut installer des états différents du code. Le coût de maintenance se concentre sur un point : chaque nouveau tokenizer ajouté à l'écosystème doit être intégré et vérifié pour l'équivalence exacte en mode compatibilité. C'est un travail récurrent, et le README ne décrit pas de procédure automatisée pour le faire. Pour une équipe qui dépend d'un tokenizer récent non listé dans les tableaux, la question de la couverture se pose avant celle de la performance.

Conclusion éditoriale

gigatoken convient aux équipes qui tokenisent des corpus de plusieurs dizaines de Go avant entraînement et qui peuvent accepter l'API native TextFileSource. Il ne convient pas à la tokenisation à la volée dans un serveur d'inférence, où la latence par requête et non le débit domine. Avant de l'adopter, vérifier sur votre propre tokenizer que le mode as_hf produit bien des identifiants identiques à HuggingFace, et mesurer le coût réel de ce mode sur votre matériel.

Sources officielles

1. Issues
2. License: MIT
3. marcelroed/gigatoken on GitHub
4. README