quicktok: a faster tokenizer (exact and byte-identical with tiktoken) [P]

## quicktok : anatomie d'un gain de vitesse 4–11× sur la tokenisation BPE

### 1. Ce qui se passe concrètement

quicktok est un tokeniseur BPE en C++ qui produit des sorties byte-identiques à tiktoken tout en tournant 4 à 11× plus vite que ce dernier et 2 à 3,6× plus vite que bpe-openai, jusqu'ici la référence de performance sur ce segment. Les chiffres sont mesurés sur Apple M1, single-thread, en MB/s, avec vérification token-for-token avant chaque run de benchmark — ce qui élimine l'objection habituelle « plus rapide mais approximatif ».

Sur cl100k_base, les débits natifs sont : quicktok 121,7 MB/s (The Pile), 139,2 MB/s (Code), 71,3 MB/s (Common Crawl). bpe-openai plafonne à 36,6 / 38,7 / 28,9 MB/s sur les mêmes corpus. tiktoken Python tourne à 13,6 / 12,8 / 12,3 MB/s. L'écart entre quicktok natif et tiktoken Python atteint donc ~11× sur The Pile et ~10,9× sur Code.

### 2. Pourquoi ces gains sont structurels, pas cosmétiques

L'algorithme de fond reste le même : BPE exact avec backtracking, identique à bpe-openai. Les gains viennent exclusivement d'ingénierie des structures de données, ce qui les rend robustes et reproductibles :

**Trie 2-byte pour le longest-match walk.** Au lieu de parcourir un trie caractère par caractère, quicktok indexe directement sur des paires d'octets. Cela réduit la profondeur de traversée et améliore la localité cache sur les séquences ASCII courantes — qui constituent l'essentiel du texte anglais et du code source.

**Caches denses à clé exacte pour les vérifications de merge-validity.** La validation de chaque fusion BPE implique des lookups répétés dans le vocabulaire. Remplacer des hash maps génériques par des caches denses taillés exactement pour le vocabulaire cible (cl100k = 100 277 tokens, o200k = 200 019 tokens) élimine les collisions et réduit les accès mémoire indirects.

**Pretokenizer compilé à la main.** tiktoken utilise un moteur regex générique (le pattern GPT-2/GPT-4 est une regex à 5 alternatives). quicktok remplace ce moteur par du code C++ compilé statiquement pour chaque vocabulaire. Le coût de dispatch regex disparaît entièrement.

Ces trois optimisations s'adressent aux trois goulots d'étranglement classiques d'un tokeniseur BPE haute fréquence : traversée de structure, validation de merge, segmentation initiale.

### 3. Périmètre et limites à date

quicktok supporte cl100k_base (GPT-3.5/4), o200k_base (GPT-4o), GPT-OSS, Llama-3 et Qwen2.5/3. C'est une couverture sérieuse des vocabulaires les plus déployés en production aujourd'hui. L'installation se fait via `pip install quicktok-v1` avec un binding Python qui atteint 77,9–83,6 MB/s — soit encore 5,7–6,5× au-dessus de tiktoken Python.

Limites identifiées : single-thread uniquement dans les benchmarks publiés (pas de données sur la parallélisation), pas de support SentencePiece/Unigram (ce qui exclut les vocabulaires Gemma, Mistral v1, T5), et le projet est au stade `v1` d'un développeur individuel — la maintenance long terme reste une inconnue.

### 4. Qui perd, qui gagne

**Perdants directs :** tiktoken (OpenAI) et bpe-openai perdent leur statut de référence de performance sur leur propre algorithme. TokenDagger, qui pointait à 11,1 MB/s sur The Pile, est relégué à ~11× en dessous de quicktok natif. rs-bpe (Rust) à 30,9 MB/s se retrouve à 4× en dessous.

**Gagnants immédiats :** les pipelines de preprocessing à grande échelle — ingestion de corpus pour fine-tuning, data filtering, calcul de token counts sur des téraoctets de texte. À 121 MB/s single-thread, tokeniser 1 TB de texte prend ~2,3 heures contre ~21 heures avec tiktoken Python. Pour les équipes qui tournent ces pipelines quotidiennement, c'est un changement d'ordre de grandeur sur les coûts de compute CPU.

**Cas d'usage secondaire :** les serveurs d'inférence qui calculent les token counts côté serveur avant dispatch (pour le routing, la facturation, les context windows) peuvent absorber cette charge avec moins de CPU — ou la déporter du GPU vers un thread CPU sans créer de bottleneck.

**Signal structurel :** le fait qu'un développeur individuel puisse surpasser de 4–11× l'implémentation officielle d'OpenAI sur leur propre algorithme, en open source, indique que tiktoken n'a jamais été optimisé pour la performance brute — il a été optimisé pour la correctness et la maintenabilité. C'est un choix légitime, mais il laisse de la place sur la table pour quiconque priorise le débit.