Tokenisierung — der Vorverarbeitungsschritt, der Rohtext in die numerischen Token-Sequenzen umwandelt, die Sprachmodelle tatsächlich verarbeiten — bleibt eine der am seltensten profilierten Komponenten im ML-Stack. Während Trainingsdatensätze auf Terabyte- und Petabyte-Größen anwachsen, kann die für diese Umwandlung benötigte Zeit zu einem praktischen Engpass in Datenaufbereitungspipelines werden, dennoch steht sie nur selten im Fokus von Optimierungsbemühungen. Gigatoken, eine neue Bibliothek, die von Marcel Rød, einem PhD-Studenten an Stanford, unter einer MIT-Lizenz veröffentlicht wurde, macht geltend, dass dieses Versäumnis Kosten verursacht. Die Bibliothek erreicht Textkodierung mit Gigabytes pro Sekunde auf einer einzelnen Maschine und übertrifft Baselines, die bereits in multithreaded Rust implementiert sind.

Benchmark-Ergebnisse

Im Benchmark mit dem GPT-2-Tokenizer auf dem 11,9 GB großen Korpus owt_train.txt auf einem Dual-Socket-System mit 144-Kern AMD EPYC 9565 verarbeitet Gigatoken Daten mit 24,53 GB/s. Auf derselben Hardware erreicht OpenAIs tiktoken — die Bibliothek, die zur Kodierung von Text für GPT-Modelle verwendet wird — 36,0 MB/s, während HuggingFace tokenizers — der De-facto-Standard-Tokenizer im Open-Source-ML-Ökosystem — 24,8 MB/s erzielt. Das entspricht Leistungsvorteilen von 681x beziehungsweise 989x.

Die Beschleunigung ist über Architekturen hinweg konsistent. Auf einem Apple M4 Max mit 16 Kernen läuft derselbe GPT-2-Workload mit 8,79 GB/s — 1.268x schneller als HuggingFace tokenizers und 140x schneller als tiktoken. Auf einem Consumer-System mit AMD Ryzen 7 9800X3D erreicht Gigatoken 6,27 GB/s, was Beschleunigungen von 106x beziehungsweise 68x gegenüber den jeweiligen Baselines entspricht.

Was ist Gigatoken?

Gigatoken ist ein in Rust geschriebener Byte-Pair-Encoding-(BPE-)Tokenizer mit Python-Bindings. BPE ist der dominierende Subword-Tokenisierungsalgorithmus für moderne LLMs und wird unter anderem von den GPT-, Llama-, Qwen- und Mistral-Familien genutzt. Gigatoken ist auf PyPI als gigatoken verfügbar (Version 0.9.0, veröffentlicht am 21 July 2026) und kann über pip install gigatoken installiert werden. Die Codebasis besteht zu 66,2 % aus Rust und zu 33,3 % aus Python. Die veröffentlichten Benchmarks decken 23 verschiedene Tokenizer-Familien ab, darunter GPT-2, GPT-OSS, Llama 3 bis 4, Qwen 2 bis 3.6, DeepSeek V3/R1/V4, GLM 4 und 5, Kimi K2, Nemotron 3, Phi-4, OLMo 2/3, ModernBERT, Gemma und Mistral.

Gigatoken bietet zwei Nutzungsmodi. Der Kompatibilitätsmodus kapselt einen bestehenden HuggingFace- oder tiktoken-Tokenizer und bewahrt exakte Ausgabeparität, allerdings zulasten des Durchsatzes. Rød erklärte auf Hacker News, dass der Kompatibilitätsmodus je nach Nutzung ungefähr 200–300x Beschleunigung liefert, weil weiterhin Python-Overhead für die Listenerstellung und die Umwandlung von Strings in Bytes anfällt. Die native Gigatoken-API, die Rust das direkte Lesen von Dateien ermöglicht, ist die Grundlage der veröffentlichten Benchmark-Zahlen.

Technischer Ansatz

Die Leistungsgewinne stammen nicht aus einer schnelleren BPE-Merge-Schleife. Stattdessen ergeben sie sich aus zwei Bereichen, die die meisten Tokenizer bereits als gelöst behandeln.

Optimierung der Pretokenisierung

Die meisten Implementierungen delegieren die Pretokenisierung an eine Regex-Engine. Gigatoken schreibt den gesamten Pretokenizer von Hand. Das Optimierungsprotokoll des Pretokenizers verfolgt den Single-Thread-Durchsatz des GPT-2-Pretokenizers auf 100 MB OpenWebText und zeigt eine detaillierte Entwicklung:

• Eine fancy-regex-Baseline läuft mit etwa 47 MiB/s.
• Eine handgeschriebene Zustandsmaschine erreicht etwa 380 MiB/s.
• Eine winnow-Combinator-Implementierung mit NEON-SIMD-Intrinsics erreicht 462 MiB/s.

Weitere Optimierung entstand durch das Ersetzen von winnow durch einen direkten Iterator, das Hinzufügen einer 256-Byte-Klassen-Lookup-Tabelle für O(1)-Dispatch des ersten Bytes und den Wechsel von NEON-Intrinsics zu SWAR (SIMD Within A Register). SWAR lädt 8 Bytes als u64 und prüft alle 8 mithilfe verzweigungsfreier Arithmetik auf die Buchstabeneigenschaft, ohne architekturspezifische Intrinsics zu benötigen. Dadurch stieg der Durchsatz auf 830 MiB/s.

Der letzte Optimierungsschritt nutzte Dual-Cursor-Parallelismus auf Instruktionsebene (ILP) und erreichte 1.049 MiB/s. Die zentrale Erkenntnis war, dass der Engpass bei ungefähr 840 MiB/s in der Latenz lag, nicht im Durchsatz. Die Endposition jedes Tokens hängt vom vorherigen Token ab, wodurch eine serielle Kette von ungefähr 25–27 Zyklen entsteht. Durch das Ausführen zweier unabhängiger Cursor ab einem sicheren Split-Punkt kann die Out-of-Order-Execution-Engine beide Streams über ungenutzte Ausführungsports hinweg verschränken.

Nettoeffekt allein beim Pretokenizer: 2,27x gegenüber der winnow + NEON-Baseline und 22,3x gegenüber der Regex-Implementierung.

Pretoken-Caching

Wenn ein Wort bereits gesehen wurde, werden seine kodierten Tokens nachgeschlagen, statt neu berechnet zu werden. Rød weist darauf hin, dass dies in der Praxis schwierig ist, weil der Cache schnell wächst und Pretoken-Verteilungen einem Long-Tail-Muster folgen. Zusätzlich werden Interaktionen mit Python minimiert, und Threads sind so ausgelegt, dass sie möglichst wenig miteinander interagieren.

Das Optimierungsprotokoll dokumentiert außerdem Ansätze, die nicht funktioniert haben. Eine Hot/Cold-Aufteilung mit #[cold] und #[inline(never)] fiel auf 580 MiB/s zurück und wurde rückgängig gemacht, weil die Inline-Barriere LLVM daran hinderte, die kombinierte ASCII- und Unicode-Schleife zu optimieren. Ein zweiphasiger Klassifizierungspuffer mit SWAR-Transitionszählung war algorithmisch korrekt, lief aber mit 354 MiB/s, da der zusätzliche Speicherverkehr die Einsparungen bei Branches überwog. Profile-guided Optimization hatte keinen messbaren Effekt, weil die innere Schleife bereits verzweigungsfrei ist und der Wortgrenzen-Branch datenabhängig bleibt.

Benchmark-Methodik

Der Vergleich ist nicht vollständig gleichwertig. Gigatoken kodiert ganze, nicht vorab aufgeteilte Dateien, findet seine eigenen Dokumentgrenzen und parallelisiert automatisch. HuggingFace (encode_batch_fast) wird auf den ersten 100 MB evaluiert, während tiktoken (encode_ordinary_batch) auf dem ersten 1 GB evaluiert wird; beide sind vorab anhand von <|endoftext|> aufgeteilt. Da die Baselines kein Caching implementieren, bleibt ihr Durchsatz gleichmäßig. Alle Messungen berichten den besten Wert aus drei verschränkten Durchläufen mit frischen Prozessen und aktivierter Parallelität.

Auch der Vokabulartyp bringt Einschränkungen mit sich. SentencePiece-Tokenizer sind nur teilweise optimiert. Auf EPYC verarbeitet Gemma 1 Daten mit 2,51 GB/s (7,3x Beschleunigung), Gemma 3 mit 3,43 GB/s (9,6x) und CodeLlama mit 3,47 GB/s (10,0x). Obwohl diese Zugewinne erheblich sind, liegen sie um eine Größenordnung unter den hervorgehobenen BPE-Leistungswerten.

Eine unabhängige Reproduktion auf KrabArena bestätigte die Ergebnisse. Auf einer Intel-Xeon-VM mit 4 vCPUs (2,20 GHz) und einem 174 MB großen OpenWebText-Ausschnitt erreichte Gigatoken 0.9.0 einen Median von 277,8 MB/s und übertraf damit tiktoken 0.13.0 (10,62 MB/s) um 26,2x sowie tokenizers 0.23.1 (3,33 MB/s) um 83,4x. Alle Tests validierten erfolgreich 35.356 Dokumente und bestätigten damit, dass der Leistungstrend mit der Kernzahl skaliert.

Umfang und Einschränkungen

Gigatokens Beschleunigung gilt sowohl für x86- als auch ARM-Architekturen und für alle 23 unterstützten Tokenizer-Familien, statt auf eine einzelne abgestimmte Konfiguration beschränkt zu sein. Allerdings erzielen SentencePiece-Vokabulare Beschleunigungen von 7–22x statt Zugewinne im Bereich von 1.000x, und WordPiece wird nicht unterstützt. Der Kompatibilitätsmodus bewahrt exakte HuggingFace-Ausgabeparität bei ungefähr 200–300x statt der vollen nativen Beschleunigung.

Das GitHub-Repository und der Benchmark-Explorer sind öffentlich verfügbar.