Tokenization — de preprocessingstap die ruwe tekst omzet in de numerieke tokenreeksen die taalmodellen daadwerkelijk gebruiken — blijft een van de minst geprofileerde onderdelen van de ML-stack. Naarmate trainingsdatasets groeien naar terabyte- en petabyte-schaal, kan de tijd die aan deze conversie wordt besteed een praktische bottleneck worden in datapreparatiepijplijnen, maar optimalisatie hiervan krijgt zelden prioriteit. Gigatoken, een nieuwe bibliotheek uitgebracht door Marcel Rød, promovendus aan Stanford, onder een MIT-licentie, stelt dat deze blinde vlek kosten met zich meebrengt. De bibliotheek codeert tekst met gigabytes per seconde op één machine en presteert beter dan baselines die al in multithreaded Rust zijn geïmplementeerd.

Benchmarkresultaten

Bij benchmarks met de GPT-2-tokenizer op het 11,9 GB grote owt_train.txt-corpus op een dual-socket AMD EPYC 9565-systeem met 144 cores verwerkt Gigatoken data met 24,53 GB/s. Op dezelfde hardware haalt OpenAI's tiktoken — de bibliotheek die wordt gebruikt om tekst voor GPT-modellen te coderen — 36,0 MB/s, terwijl HuggingFace tokenizers — de feitelijke standaardtokenizer in het open-source ML-ecosysteem — 24,8 MB/s registreert. Dat komt neer op prestatievoordelen van respectievelijk 681x en 989x.

De versnelling is consistent over architecturen heen. Op een Apple M4 Max met 16 cores draait dezelfde GPT-2-workload op 8,79 GB/s — 1.268x sneller dan HuggingFace tokenizers en 140x sneller dan tiktoken. Op een consumentenprocessor AMD Ryzen 7 9800X3D haalt Gigatoken 6,27 GB/s, goed voor versnellingen van 106x en 68x ten opzichte van de respectieve baselines.

Wat is Gigatoken

Gigatoken is een byte-pair encoding-tokenizer (BPE) geschreven in Rust met Python-bindings. BPE is het dominante subword-tokenizationalgoritme voor moderne LLM's en wordt onder meer gebruikt door de GPT-, Llama-, Qwen- en Mistral-families. De bibliotheek is beschikbaar op PyPI als gigatoken (versie 0.9.0, uitgebracht op 21 July 2026) en kan worden geïnstalleerd via pip install gigatoken. De codebase bestaat voor 66,2% uit Rust en voor 33,3% uit Python. De gepubliceerde benchmarks bestrijken 23 afzonderlijke tokenizerfamilies, waaronder GPT-2, GPT-OSS, Llama 3 tot en met 4, Qwen 2 tot en met 3.6, DeepSeek V3/R1/V4, GLM 4 en 5, Kimi K2, Nemotron 3, Phi-4, OLMo 2/3, ModernBERT, Gemma en Mistral.

Gigatoken biedt twee gebruiksmodi. De compatibiliteitsmodus verpakt een bestaande HuggingFace- of tiktoken-tokenizer en behoudt exact dezelfde output, maar dit gaat ten koste van de doorvoer. Rød verklaarde op Hacker News dat de compatibiliteitsmodus afhankelijk van het gebruik ongeveer 200–300x versnelling oplevert, omdat er nog steeds Python-overhead is voor het aanmaken van lijsten en conversie van strings naar bytes. De native Gigatoken-API, waarmee Rust bestanden rechtstreeks kan lezen, is de bron van de gepubliceerde benchmarkcijfers.

Technische aanpak

De prestatiewinst komt niet voort uit een snellere BPE-merge-loop. In plaats daarvan komt die uit twee gebieden die de meeste tokenizers als opgelost beschouwen.

Optimalisatie van pretokenization

De meeste implementaties besteden pretokenization uit aan een regex-engine. Gigatoken schrijft de volledige pretokenizer handmatig. Het optimalisatielogboek van de pretokenizer volgt de single-threaded GPT-2-pretokenizerdoorvoer op 100 MB OpenWebText en laat een gedetailleerde ontwikkeling zien:

• Een fancy-regex-baseline draait op ongeveer 47 MiB/s.
• Een handgeschreven state machine bereikt ongeveer 380 MiB/s.
• Een winnow-combinatorimplementatie met NEON SIMD-intrinsics haalt 462 MiB/s.

Verdere optimalisatie kwam door winnow te vervangen door een directe Iterator, een 256-byte class lookup table toe te voegen voor O(1) first-byte dispatch en over te stappen van NEON-intrinsics naar SWAR (SIMD Within A Register). SWAR laadt 8 bytes als een u64 en controleert alle 8 op de lettereigenschap met branchless arithmetic, zonder architectuurspecifieke intrinsics te vereisen. Dit bracht de doorvoer naar 830 MiB/s.

De laatste optimalisatiestap bestond uit het benutten van dual-cursor instruction-level parallelism (ILP), waarmee 1.049 MiB/s werd bereikt. Het belangrijkste inzicht was dat de bottleneck bij ongeveer 840 MiB/s latency was, geen doorvoer. De eindpositie van elk token hangt af van de vorige, waardoor een seriële keten van ongeveer 25–27 cycli ontstaat. Door twee onafhankelijke cursors vanaf een veilig splitspunt te laten lopen, kan de out-of-order execution engine beide streams verweven over inactieve execution ports.

Netto-effect alleen op de pretokenizer: 2,27x ten opzichte van de winnow + NEON-baseline en 22,3x ten opzichte van de regex-implementatie.

Pretoken-caching

Wanneer een woord al eerder is gezien, worden de gecodeerde tokens opgezocht in plaats van opnieuw berekend. Rød merkt op dat dit in de praktijk moeilijk is, omdat de cache snel groeit en pretokenverdelingen een long-tailpatroon volgen. Daarnaast worden interacties met Python geminimaliseerd en zijn threads zo ontworpen dat ze zo weinig mogelijk met elkaar interacteren.

Het optimalisatielogboek documenteert ook benaderingen die niet werkten. Een hot/cold-splitsing met #[cold] en #[inline(never)] viel terug naar 580 MiB/s en werd teruggedraaid, omdat de inline barrier LLVM verhinderde de gecombineerde ASCII- en unicode-loop te optimaliseren. Een two-pass classificatiebuffer met SWAR transition counting was algoritmisch correct, maar draaide op 354 MiB/s, omdat het extra geheugenverkeer zwaarder woog dan de besparing op branches. Profile-guided optimization had geen meetbaar effect, omdat de inner loop al branchless is en de word-boundary branch data-afhankelijk is.

Benchmarkmethodologie

De vergelijking is niet strikt appels met appels. Gigatoken codeert volledige, niet-gesplitste bestanden, vindt zelf documentgrenzen en paralleliseert automatisch. HuggingFace (encode_batch_fast) wordt geëvalueerd op de eerste 100 MB, terwijl tiktoken (encode_ordinary_batch) wordt geëvalueerd op de eerste 1 GB; beide zijn vooraf gesplitst op <|endoftext|>. Omdat de baselines geen caching implementeren, blijft hun doorvoer uniform. Alle metingen rapporteren de beste van drie verweven rondes met verse processen en ingeschakelde parallelisatie.

Ook het type vocabulary brengt beperkingen met zich mee. SentencePiece-tokenizers zijn slechts gedeeltelijk geoptimaliseerd. Op EPYC verwerkt Gemma 1 2,51 GB/s (7,3x versnelling), Gemma 3 3,43 GB/s (9,6x) en CodeLlama 3,47 GB/s (10,0x). Hoewel aanzienlijk, liggen deze winsten een orde van grootte lager dan de opvallendste BPE-prestatiecijfers.

Een onafhankelijke reproductie op KrabArena verifieerde de resultaten. Op een Intel Xeon-VM met 4 vCPU's (2,20 GHz) en een OpenWebText-slice van 174 MB behaalde Gigatoken 0.9.0 een mediaan van 277,8 MB/s, waarmee het tiktoken 0.13.0 (10,62 MB/s) met 26,2x en tokenizers 0.23.1 (3,33 MB/s) met 83,4x overtrof. Alle tests valideerden met succes 35.356 documenten, wat bevestigt dat de prestatietrend schaalt met het aantal cores.

Reikwijdte en beperkingen

De versnelling van Gigatoken houdt stand op zowel x86- als ARM-architecturen en over alle 23 ondersteunde tokenizerfamilies, in plaats van beperkt te zijn tot één specifiek getunede configuratie. Toch halen SentencePiece-vocabularies versnellingen van 7–22x in plaats van winsten in de orde van 1.000x, en WordPiece wordt niet ondersteund. De compatibiliteitsmodus behoudt exacte outputpariteit met HuggingFace op ongeveer 200–300x, in plaats van de volledige native versnelling.

De GitHub-repository en de benchmarkverkenner zijn openbaar beschikbaar.