TokenDagger – Ein schnellerer Tokenizer als OpenAIs Tiktoken

• Ein Hochleistungs-Tokenizer, der zu 100 % mit OpenAIs TikToken kompatibel ist, und bei der Verarbeitung großer Textmengen mehr als doppelt so hohen Durchsatz sowie eine 4-mal schnellere Code-Tokenisierung bietet
• Maximiert die Geschwindigkeit beim Matching von Token-Mustern durch eine schnelle, auf PCRE2 basierende Parsing-Engine für reguläre Ausdrücke
• Ein vereinfachter BPE-Algorithmus minimiert Leistungseinbußen bei der Verarbeitung großer Mengen spezieller Token
• In realen Benchmarks ist die Code-Tokenisierung mehr als 4-mal schneller; bestehender Code, der TikToken nutzt, kann unverändert ersetzt und weiterverwendet werden
• Unterstützt Python 3.8+, lässt sich über PyPI mit pip install tokendagger einfach installieren und hat eine Abhängigkeit zu PCRE2

[GN⁺]

Hacker-News-Kommentare

• Kurzfristig scheint es in der AI/ML-Infrastruktur noch viel Spielraum für Performance-Optimierungen zu geben, indem man zentrale Engpässe so wie hier in C++ behebt; es geht nicht darum, alles in C++ neu zu schreiben, sondern darum, dass kluge Engineering-Trade-offs oft zu echten Leistungsgewinnen führen, besonders chinesische Ingenieur:innen scheinen in solchen Arbeiten stark zu sein
  • Mein Mentor hat mir einmal diese Sicht auf Softwareentwicklung beigebracht: Phase 1: erst einmal zum Laufen bringen, Phase 2: schnell machen, Phase 3: schön machen; Transformer und LLMs sind inzwischen an einem Punkt, an dem sie ziemlich gut funktionieren, daher fühlt es sich so an, als ob wir gerade in einer Phase leben, in der die größten Fortschritte bei der Performance erzielt werden
  • Langfristig halte ich es für sinnvoll, sich vom Python-Zentrum zu lösen; wenn ML-Ingenieur:innen Python nur deshalb nutzen, weil sie daran gewöhnt sind, ist das nicht wirklich zukunftsorientiert
  • Tatsächlich ist TikToken in Rust geschrieben, deshalb frage ich mich, ob diese Verbesserung wirklich auf die Portierung nach C++ zurückzuführen ist
  • In Wirklichkeit ist Tokenizing nicht der größte Engpass, der Großteil der Rechenarbeit fällt bei der eigentlichen Ausführung der CUDA-Kernels an; der Python-Overhead ist sehr gering (VLLM ist ebenfalls größtenteils in Python geschrieben), und „in C++ neu schreiben“ bedeutet fast immer, die CUDA-Kernels effizienter neu zu implementieren
• Es wirkt ziemlich elegant, ein bestehendes System als Drop-in-Ersatz mit deutlich besserer Performance zu bauen, erinnert mich an ScyllaDB
  • Ich denke, wenn es kein solcher Ersatz wäre, würde es niemand verwenden
• Ich frage mich, wie wichtig der Tokenizer für die Gesamtperformance von LLMs ist; ich interessiere mich für Tokenizer-Optimierung, habe aber noch keine echten Messungen gemacht; ich bin davon ausgegangen, dass der Großteil der Kosten durch Matmul entsteht, aber nach den Reaktionen in den Kommentaren scheint der Tokenizer doch relevant zu sein
  • Tokenizing läuft normalerweise auf der CPU und ist nur selten der Engpass beim Training oder bei der Inferenz; die meiste Zeit verbringt man in GPU-Kernels, nur sehr kleine Modelle sind eine Ausnahme; die Latenz des Tokenizers lässt sich außerdem „verstecken“, indem die CPU den nächsten Batch vorbereitet
  • Tokenizing-Performance ist etwas kompliziert, aber Organisationen mit echter Expertise und entsprechenden Ressourcen schreiben sehr schnelle Tokenizer selbst; SentencePiece und tiktoken sind typische Beispiele dafür, dass man zusätzliche Komplexität und Deployment-Aufwand bewusst in Kauf nimmt; echte Spezialist:innen schauen per Flame Graph nach den Engpässen, und bei groß angelegtem Training wird oft vorab tokenisiert; man spürt auch eine gewisse Nervosität in der Branche darüber, dass C++ wieder Aufwind bekommt, im Gegensatz zum bisherigen Rust-Narrativ; ich hoffe, dass es dafür neue Gründe oder Einsichten gibt
  • Wie auch andere Kommentare sagen: In der Praxis ist der Tokenizer nicht der Engpass, man hat dort nur zuerst angesetzt, weil es der erste Schritt in der Inferenz-Pipeline ist
  • Text-Tokenizing macht am gesamten Rechenaufwand wirklich nur einen winzigen Anteil aus, aber bei Datenverarbeitung im Petabyte-Maßstab ist selbst ein kleiner Geschwindigkeitsgewinn immer willkommen
• Um mit tiktoken kompatibel zu sein, ist eine Konvertierung des Vocab-Formats nötig; wenn auch diese Anforderung wegfallen könnte, wäre das ein noch besserer vollständig kompatibler Drop-in-Ersatz; außerdem wäre ein bidirektionales Beispiel hilfreich, das nach der Initialisierung von tiktoken auch tokendagger initialisiert und prüft, ob die Ergebnisse identisch sind
  • Seit Version 0.1.1 ist es ein echter Drop-in-Ersatz, und wir planen, bald auch ein Beispiel hinzuzufügen
  • Guter Hinweis, ich habe direkt ein Update dazu gemacht
• Mich würde auch interessieren, wie sich dieses Projekt mit dem BPE crate vergleicht; dessen Stärke ist die inkrementelle Re-Tokenisierung von Text, und es ist schneller als tiktoken
  • Als Nächstes wollen wir inkrementelle Re-Tokenisierung hinzufügen und auch Benchmarks gegen dieses crate durchführen
• Ich frage mich, wie man an lokale Tokenizer für andere LLMs kommt; Gemini veröffentlicht zum Beispiel nur eine Remote-API; ich frage mich, ob das proprietär ist oder ob man per massenhaftem API-Aufruf das Token-Mapping rekonstruieren könnte
  • Gemini nutzt SentencePiece und teilt sich dasselbe Tokenizer-Vokabular mit Gemma (Referenz 1, Referenz 2, Referenz 3); unter den großen Labs hat nur Anthropic für Claude 3 und neuer keinen lokalen Tokenizer
  • Modellspezifische Tokenizer teilen sich meist Kernalgorithmen wie SentencePiece oder Byte-pair encoding (BPE), während sich auf Wrapper-Ebene nur Dinge wie die Behandlung spezieller Tokens unterscheiden; tiktoken und TokenDagger sind ebenfalls BPE-Implementierungen; wenn die Bibliothek solche Modellspezifika berücksichtigt, erleichtert das die Integration und bringt einen kleinen Performance-Vorteil; das ist keine große Sache und daher auch für neue Modelle kein großer Aufwand; als Referenzbeispiele siehe llamas tokenizer.py, Mistral-Tokenizer
  • Ich wusste, dass Gemini SentencePiece verwendet SentencePiece
• Ich habe früher einmal etwas Ähnliches ausprobiert: tokie; tatsächlich entfällt der Großteil der Tokenizer-Laufzeitkosten auf das Pre-Tokenizing (Regex); es sieht so aus, als hättet ihr eine schnellere Regex-Methode gefunden, deshalb würde mich interessieren, ob ihr auch verglichen habt, wie sich die Performance ändert, wenn man nur die Regex-Engine austauscht und BPE aus tiktoken unverändert lässt; falls ja, wäre vielleicht sogar ein Upstream-Beitrag möglich
  • Cooles Projekt, ich habe der Person, die tiktoken betreut, bereits geschrieben
• Ich würde auch gern einen Performance-Vergleich mit Huggingface tokenizers sehen; die Benchmarks im tiktoken-Readme basieren auf viel zu alten Informationen
  • Meiner persönlichen Erfahrung nach war tiktoken immer langsamer als Huggingface tokenizers; ich habe mich zwar noch nicht tief genug in tiktoken eingearbeitet, um das Warum zu verstehen, aber als Nutzer der HF-Rust-Tokenizer fühlt es sich so an
• Ich würde auch gern WASM-Bindings für tiktoken sehen, oder wissen, ob sich die Performance-Verbesserungen aus „b“ auch auf eine reine JS-Implementierung übertragen lassen
• Wirklich ein großartiges Projekt; wir verwenden ebenfalls tiktoken, und wenn es Drop-in-kompatibel ist und zugleich schneller läuft, würde mich der Effekt sehr interessieren; die Entscheidung für den Drop-in-Ansatz ist hervorragend