Gigatoken: Rust-Tokenizer mit zweistufigem API-Modell

Welches Problem Gigatoken adressiert

Tokenisierung ist in vielen Trainings- und Datenvorbereitungs-Pipelines der Schritt, der vor dem eigentlichen Modell läuft. Die README positioniert Gigatoken als Antwort auf genau diesen Engpass: Textdaten sollen mit GB/s in Token umgewandelt werden. Die Zielgruppe sind damit nicht Anwendungsentwickler, die gelegentlich einen Satz kodieren, sondern Teams, die große Korpora verarbeiten. Die README nennt als Referenzdatensatz owt_train.txt mit 11,9 GB. Gigatoken versteht sich als Drop-in-Ersatz für HuggingFace Tokenizers und tiktoken, was bedeutet, dass bestehender Code weitgehend unverändert bleiben kann. Der Nutzen liegt also nicht in einer neuen Tokenizer-Semantik, sondern in der Durchsatzsteigerung bei gleichbleibender Ausgabe. Die README räumt ein, dass sowohl HF Tokenizers als auch tiktoken bereits multithreaded in Rust laufen. Der Vergleich richtet sich folglich nicht gegen Python-Implementierungen, sondern gegen bereits optimierte Rust-Bibliotheken.

Zwei API-Modi mit unterschiedlichen Kosten

Gigatoken bietet zwei Wege, den Tokenizer zu verwenden. Im Kompatibilitätsmodus wird ein bestehendes Tokenizer-Objekt umhüllt: gt.Tokenizer(hf_tokenizer).as_hf() oder gt.Tokenizer(tiktokenizer).as_tiktoken(). Danach stehen Methoden wie encode_batch zur Verfügung, die laut README in denselben Kontexten funktionieren wie das Original. Die README betont, dass viel Aufwand in exakt übereinstimmende Ausgaben im Vergleich zu HuggingFace Tokenizers gesteckt wurde, dies aber mit nicht unerheblichen Leistungskosten verbunden ist. Der zweite Modus ist die Gigatoken-API selbst. Hier wird der Tokenizer direkt über einen Modellnamen erzeugt, etwa gt.Tokenizer("Qwen/Qwen3-8B"), und die Daten werden über eine Dateiquelle eingelesen. Der Unterschied ist architektonisch: Im Gigatoken-Modus liest die Rust-Implementierung die Daten direkt, wodurch Overhead reduziert und Parallelität erhöht wird. Die README formuliert die Grenze selbst: Werden Python-Datenstrukturen durch diese API geschleust, entsteht weiterhin Overhead durch die Übergabe aus Python. Der Leistungsvorteil hängt also nicht nur vom Tokenizer ab, sondern davon, wo die Daten herkommen.

Installation und erste Schritte

Die Installation erfolgt über pip install gigatoken. Ein Beispiel aus der README zeigt den Kompatibilitätsmodus mit HuggingFace: Zuerst wird ein vorhandener Tokenizer erzeugt, dann mit gt.Tokenizer(hf_tokenizer).as_hf() umhüllt. Anschließend ruft man tokenizer.encode_batch(["This is a test string", "And here is another"]) auf. Für tiktoken ist der Ablauf identisch, nur mit as_tiktoken(). Der Gigatoken-Modus sieht so aus: import gigatoken as gt, dann tokenizer = gt.Tokenizer("Qwen/Qwen3-8B"). Die README vermerkt, dass hier HF-Modellnamen akzeptiert werden. Danach folgt file_source = gt.TextFileSource(["owt_train.txt"], separator=b"<|endoftext|>") und schließlich tokens = tokenizer.encode_files(file_source). Der Parameter separator wird als Byte-String übergeben, was für Dokumentgrenzen in vorbereiteten Korpora relevant ist. Weitere Konfigurationsschlüssel oder Umgebungsvariablen nennt die README nicht. Wer den Kompatibilitätsmodus wählt, muss beachten, dass die README dort keine Aussage über die genaue Fehlerbehandlung bei nicht unterstützten Tokenizern macht.

Was die Benchmarks zeigen und was nicht

Die README enthält mehrere Tabellen mit Durchsatzwerten für owt_train.txt. Auf einem System mit zwei AMD EPYC 9565 (144 Kerne) erreicht GPT-2 laut Tabelle 24,53 GB/s gegenüber 24,8 MB/s bei HF Tokenizers und 36,0 MB/s bei tiktoken. Das sind die in der README genannten Faktoren von 989x und 681x. Die Werte variieren stark je nach Tokenizer: Gemma 4 liegt bei 4,82 GB/s, Mistral 7B v0.3 bei 3,57 GB/s. Auf einem Apple M4 Max sind die absoluten Zahlen niedriger, GPT-2 erreicht dort 8,79 GB/s. Auf einem AMD Ryzen 7 9800X3D sind es 6,27 GB/s. Die README erklärt, dass OWT gewählt wurde, weil es ungefähr repräsentativ für Text nach der Extraktion aus CommonCrawl-Dokumenten ist. Die Tabellen sind nach Tokenizer-Familien gruppiert, und einige Zeilen enthalten keine HF- oder tiktoken-Werte. Das bedeutet, dass für diese Tokenizer kein direkter Vergleich in der README vorliegt. Die Benchmarks wurden auf den genannten CPUs erstellt; ob sie auf anderen Architekturen oder mit anderen Datensätzen übertragbar sind, lässt sich aus dem Material nicht ableiten.

Grenzen und Fälle, in denen Gigatoken das falsche Werkzeug ist

Die README benennt eine zentrale Einschränkung selbst: Im Kompatibilitätsmodus mit HuggingFace Tokenizers wird exakte Ausgabegleichheit angestrebt, was mit nicht unerheblichen Leistungskosten verbunden ist. Wer also die Kompatibilitätsschicht nutzt, erhält nicht die beworbenen 1000x, sondern laut README deutlich weniger. Ein weiterer Punkt betrifft den Datenpfad. Die Gigatoken-API ist am schnellsten, wenn die Rust-Implementierung die Dateien direkt liest. Sobald Python-Datenstrukturen übergeben werden, entsteht Overhead. Für Anwendungsfälle, in denen Texte ohnehin als Python-Listen vorliegen und nur einmalig kodiert werden, ist der Vorteil entsprechend geringer. Die README listet zudem Tokenizer wie Gemma 1 mit 2,51 GB/s auf der EPYC-Plattform, was im Vergleich zu GPT-2 mit 24,53 GB/s deutlich niedriger ausfällt. Das deutet darauf hin, dass der Durchsatz stark vom jeweiligen Tokenizer-Modell abhängt. Ob ein bestimmter Tokenizer in der eigenen Umgebung ähnlich skaliert, lässt sich aus der README nicht vorhersagen. Schließlich fehlen Angaben zu Releases, zur Versionshistorie und zu unterstützten Python-Versionen. Wer auf stabile Schnittstellen über mehrere Versionen angewiesen ist, findet im vorliegenden Material keine Grundlage für eine solche Zusage.

Alternative: HF Tokenizers und tiktoken

Die naheliegende Alternative sind die Bibliotheken, gegen die Gigatoken antritt: HuggingFace Tokenizers und tiktoken. Beide laufen laut README bereits multithreaded in Rust. Der Unterschied liegt im Ansatz. HF Tokenizers bietet eine breite Modellabdeckung und eine etablierte API, die in viele Frameworks integriert ist. tiktoken ist auf OpenAI-Modelle zugeschnitten und ebenfalls in Rust implementiert. Gigatoken setzt auf zwei Dinge: einen Kompatibilitätsmodus, der die bestehende API nachbildet, und einen eigenen Modus, der Dateien direkt in Rust liest und dadurch Parallelität besser ausnutzt. Wer bereits HF Tokenizers einsetzt und die Ausgabe nicht ändern will, kann Gigatoken als Hülle verwenden, muss aber den Leistungsverlust im Kompatibilitätsmodus einkalkulieren. Wer tiktoken nutzt, findet in der README für GPT-2 auf dem M4 Max einen Vergleich: 62,8 MB/s bei tiktoken gegenüber 8,79 GB/s bei Gigatoken. Diese Zahl stammt aus der Tabelle und nicht aus einem unabhängigen Test.

Wartung, Lizenz und Betrieb

Gigatoken steht unter der MIT-Lizenz. Das ist eine permissive Lizenz, die die Nutzung, Änderung und Weitergabe erlaubt, sofern der Urheberrechtshinweis und der Lizenztext beibehalten werden. Für Unternehmen bedeutet das in der Regel geringe rechtliche Hürden bei der Einbettung in eigene Produkte. Das Material enthält keine Angaben zu Lizenzpflichten für abgeleitete Werke oder zu Patentklauseln; eine rechtliche Prüfung ersetzt dieser Artikel nicht. Zur Wartung liefert die README keine Informationen über Release-Zyklen, unterstützte Versionen oder ein Änderungsprotokoll. Das Repository hat keine abgerufenen Releases. Der letzte Push stammt vom 2. September 2026. Ob und in welchem Umfang das Projekt weiterentwickelt wird, lässt sich daraus nicht ableiten. Wer Gigatoken produktiv einsetzt, sollte die eigene Tokenizer-Variante in der Benchmark-Tabelle wiederfinden und die Ausgaben im Kompatibilitätsmodus gegen die Referenzimplementierung prüfen. Ein Upgrade-Pfad ist im vorliegenden Material nicht dokumentiert.

Redaktionelles Fazit

Wer Tokenisierung als Engpass in einer Pipeline mit großen Textmengen hat, sollte den Gigatoken-API-Modus mit encode_files und TextFileSource prüfen. Wer exakte HuggingFace-Ausgaben ohne Leistungsverlust braucht, sollte den Kompatibilitätsmodus zuerst gegen die eigene Tokenizer-Konfiguration messen. Vor dem Einsatz ist zu verifizieren, ob die eigene Tokenizer-Variante in der Benchmark-Tabelle auftaucht und ob das Modell über den HF-Namen ladbar ist.

Offizielle Quellen

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