TokenDagger – Un tokenizer plus rapide que Tiktoken d’OpenAI

• Tokenizer haute performance 100 % compatible avec TikToken d’OpenAI, offrant plus de 2 fois le débit et une tokenisation de code 4 fois plus rapide pour le traitement de grands volumes de texte
• Moteur d’analyse d’expressions régulières haute vitesse basé sur PCRE2 pour maximiser la rapidité de correspondance des motifs de tokens
• Algorithme BPE simplifié afin de minimiser la baisse de performance lors du traitement de grands volumes de special tokens
• Dans des benchmarks réels, la tokenisation de code est plus de 4 fois plus rapide, et il peut être utilisé en remplacement direct du code existant basé sur TikToken
• Compatible avec Python 3.8+, installation simple via PyPI avec pip install tokendagger, avec une dépendance à PCRE2

[GN⁺]

Avis Hacker News

• À court terme, il semble qu’il y ait encore beaucoup de marge d’optimisation dans l’infrastructure AI/ML en résolvant les goulots d’étranglement critiques en C++, sans pour autant tout réécrire en C++ ; des compromis d’ingénierie intelligents se traduisent souvent par de vrais gains de performance, et on a l’impression que les ingénieurs chinois sont particulièrement bons dans ce domaine
  • Mon mentor m’enseignait cette vision du développement logiciel : étape 1, faire en sorte que ça fonctionne ; étape 2, que ce soit rapide ; étape 3, que ce soit élégant. Les transformers et les LLM sont désormais arrivés à un stade où ils fonctionnent plutôt bien, donc on a l’impression qu’on est maintenant dans une période où les plus grands progrès se font sur la performance
  • À long terme, il semblerait utile de sortir d’une approche centrée sur Python ; si c’est utilisé simplement parce que les ingénieurs ML y sont habitués, ce n’est pas très tourné vers l’avenir
  • En pratique, TikToken est écrit en Rust, donc on peut se demander si cette amélioration vient vraiment du portage en C++
  • En réalité, la tokenisation n’est pas le principal goulot d’étranglement, et la plupart des calculs ont lieu lors de l’exécution des kernels CUDA ; l’overhead Python est très faible (VLLM aussi est majoritairement écrit en Python), et réécrire en C++ signifie presque toujours réécrire surtout les kernels CUDA de manière plus efficace
• Il y a quelque chose d’assez beau dans le fait de créer un remplacement drop-in d’un système existant avec de très gros gains de performance ; cela fait penser à ScyllaDB
  • En réalité, si ce n’était pas ce type de remplaçant, personne ne l’utiliserait
• Je me demande quelle est l’importance du tokenizer dans la performance globale des LLM ; je m’intéresse à l’optimisation des tokenizers mais je n’ai pas encore fait de mesures, je supposais que l’essentiel du coût venait des matmul, mais à voir les réactions dans les commentaires, le tokenizer semble avoir son importance
  • La tokenisation est généralement traitée sur CPU et devient rarement le goulot d’étranglement de l’entraînement ou de l’inférence ; la plupart du temps est passée dans les kernels GPU, sauf pour de très petits modèles, et la latence du tokenizer peut aussi être « masquée » par la manière dont le CPU prépare le batch suivant
  • La performance de la tokenisation est un sujet assez complexe, mais les organisations qui ont les vraies compétences et les ressources écrivent elles-mêmes des tokenizers très rapides ; SentencePiece et tiktoken sont représentatifs de ce choix malgré la complexité et la charge de déploiement supplémentaires. Les vrais experts examinent les goulots d’étranglement via des flame graphs, et pour les exécutions à grande échelle on fait parfois la tokenisation en amont. On sent aussi une certaine tension dans l’industrie autour du retour en grâce du C++, contrairement au narratif Rust, et on espère qu’il y ait de nouvelles raisons ou de nouveaux éclairages derrière cela
  • Comme dans d’autres commentaires, le tokenizer n’est pas réellement le goulot d’étranglement ; c’est simplement la première étape du pipeline d’inférence, donc c’est par là qu’ils ont commencé
  • La tokenisation de texte représente vraiment une part minime du calcul total ; cela dit, pour traiter des données à l’échelle du pétaoctet, être ne serait-ce qu’un peu plus rapide est toujours bénéfique
• Pour être aligné sur tiktoken, il faut convertir le format du vocab, et ce serait un remplacement drop-in totalement compatible encore plus agréable à utiliser si cette contrainte disparaissait aussi ; ce serait bien également d’avoir un exemple bidirectionnel où l’on initialise tiktoken puis tokendagger pour vérifier que les résultats sont identiques
  • À partir de la version 0.1.1, c’est devenu un vrai remplacement drop-in, et il est prévu d’ajouter bientôt un exemple
  • Très bonne remarque, la mise à jour a été faite immédiatement
• Je me demande aussi comment ce projet se compare au crate BPE, dont l’atout est de pouvoir re-tokeniser du texte de manière incrémentale tout en étant plus rapide que tiktoken
  • La prochaine étape sera d’ajouter une fonction de re-tokenisation incrémentale et de faire aussi des benchmarks avec ce crate
• Je me demande comment obtenir des tokenizers locaux pour d’autres LLM ; par exemple, Gemini ne publie qu’une API distante. Je me demande si c’est propriétaire ou s’il existe un moyen d’estimer la correspondance des tokens en appelant massivement l’API
  • Gemini utilise SentencePiece et partage le même vocabulary de tokenizer que Gemma (réf. 1, réf. 2, réf. 3) ; parmi les grands labos, seul Anthropic, pour Claude 3 et au-delà, ne propose pas de tokenizer local
  • Les tokenizers spécifiques à chaque modèle partagent pour la plupart des algorithmes de base comme SentencePiece ou Byte-pair encoding (BPE), et ne diffèrent souvent qu’au niveau des wrappers, par exemple pour la gestion des tokens spéciaux. tiktoken et TokenDagger sont aussi des implémentations BPE. Si la bibliothèque prend en charge les particularités par modèle, on peut obtenir de légers gains de performance et une intégration plus simple ; ce n’est pas un gros chantier, donc s’adapter à de nouveaux modèles n’est pas très coûteux. Exemples de référence : tokenizer.py de llama, tokenizer Mistral
  • Je savais que Gemini utilisait SentencePiece : SentencePiece
• J’ai déjà essayé quelque chose de similaire par le passé : tokie. En pratique, la majeure partie du coût d’exécution d’un tokenizer vient du pré-tokenizing (regex). Il semble qu’ils aient trouvé une méthode regex plus rapide, mais je me demande s’ils ont aussi comparé les performances en ne changeant que le moteur regex tout en gardant le BPE de tiktoken tel quel ; si oui, cela pourrait peut-être même faire l’objet d’une contribution upstream
  • Très beau projet, le mainteneur de tiktoken a été contacté
• Il serait bien aussi d’avoir une comparaison de performance avec les Huggingface tokenizers ; d’après le readme de tiktoken, le benchmark repose sur des informations trop anciennes
  • Personnellement, tiktoken m’a toujours semblé plus lent que huggingface tokenizers. Je n’ai pas encore creusé tiktoken en profondeur pour comprendre pourquoi, mais c’est l’impression que j’ai comme utilisateur des tokenizers Rust de HF
• J’aimerais aussi voir des bindings WASM pour tiktoken, ou savoir si les gains de performance obtenus dans « b » pourraient aussi être appliqués à une implémentation pure JS
• Vraiment un super projet ; nous utilisons aussi tiktoken, et si on peut obtenir un gain de performance tout en restant compatible drop-in, j’aimerais beaucoup voir l’impact. Le choix de l’approche drop-in est excellent