O gargalo invisível que ninguém perfilava
A tokenização é a única etapa do pipeline de LLMs que quase ninguém monitora. Enquanto a indústria debate arquiteturas de atenção, tamanhos de contexto e estratégias de fine-tuning, o processo de transformar texto bruto em tokens — que acontece antes de qualquer cálculo do modelo — raramente recebe atenção de engenharia. Gigatoken, lançado por Marcel Rød (doutorando em Stanford) sob licença MIT, argumenta que isso foi um erro.
A biblioteca codifica texto a gigabytes por segundo em uma única máquina, competindo contra baselines que já são implementações multithreaded em Rust — e vencendo por margens de 681× a 989×.
Os números que impressionam
No benchmark com o tokenizador GPT-2 sobre o corpus owt_train.txt de 11,9 GB em um AMD EPYC 9565 dual-socket de 144 núcleos, o Gigatoken atingiu 24,53 GB/s. Para comparação: o tiktoken da OpenAI fez 36,0 MB/s e os tokenizers do HuggingFace registraram 24,8 MB/s na mesma configuração de hardware — vantagens de 681× e 989×, respectivamente.
Em um Apple M4 Max com 16 núcleos, a mesma carga de trabalho GPT-2 roda a 8,79 GB/s (1.268× HuggingFace e 140× tiktoken). Em um AMD Ryzen 7 9800X3D — CPU de consumidor — roda a 6,27 GB/s (106× e 68×). A aceleração não é artefato de um único CPU ou vocabulário.
O que é o Gigatoken
Gigatoken é um tokenizador BPE (Byte-Pair Encoding) escrito em Rust com bindings para Python. Está no PyPI como gigatoken (versão 0.9.0, lançada em 21 de julho de 2026) e instala-se com pip install gigatoken. O repositório é 66,2% Rust e 33,3% Python. Suporta 23 famílias de tokenizadores: GPT-2, GPT-OSS, Llama 3 e 4, Qwen 2 a 3.6, DeepSeek V3/R1/V4, GLM 4 e 5, Kimi K2, Nemotron 3, Phi-4, OLMo 2/3, ModernBERT, Gemma e Mistral.
Há dois modos de uso. O modo compatibilidade encapsula um tokenizador HuggingFace ou tiktoken existente e preserva paridade exata de saída, com custo real de throughput (~200-300× conforme o uso). A API nativa do Gigatoken permite que o Rust leia arquivos diretamente, e é daí que vêm os números publicados.
Como se chega a essa velocidade
Os ganhos não vêm de um loop de merge BPE melhor. Vêm de dois lugares que a maioria dos tokenizadores trata como resolvidos:
(1) Pré-tokenização: a maioria das implementações delega isso a um motor de regex. O Gigatoken escreve à mão. A progressão documentada no log de otimização para o tokenizador GPT-2 (100 MB do OpenWebText, single-threaded) é instrutiva:
- Baseline com regex: ~47 MiB/s
- Máquina de estados manual: ~380 MiB/s
- Implementação com combinadores winnow + NEON SIMD: 462 MiB/s
- Iterator direto + tabela de classificação de 256 bytes + SWAR (SIMD Within A Register): 830 MiB/s. SWAR carrega 8 bytes como u64 e verifica todos os 8 com aritmética branchless, sem precisar de intrínsecos de arquitetura.
- Exploração de ILP com cursor duplo: 1.049 MiB/s. O gargalo a ~840 MiB/s era latência, não throughput: cada posição final de token depende da anterior, uma cadeia serial de 25-27 ciclos. Rodar dois cursores independentes permite ao motor out-of-order entrelaçar ambos.
Efeito líquido só na pré-tokenização: 22,3× sobre a implementação regex.
(2) Cache de pré-tokens: se uma palavra já foi vista, seus tokens codificados são consultados em vez de recalculados. O autor observa que isso é difícil na prática porque o cache cresce rapidamente e as distribuições de pré-tokens têm cauda longa. Além disso, as interações com Python são minimizadas e as threads são projetadas para interagir minimamente entre si.
O log de otimização é incomumente honesto sobre o que falhou. Uma divisão hot/cold com #[cold] regrediu para 580 MiB/s: a barreira de inline impediu o LLVM de otimizar o loop combinado ASCII+unicode. Um buffer de classificação em duas passagens com contagem de transições SWAR estava algoritmicamente correto, mas rodou a 354 MiB/s — o tráfego extra de memória anulou a economia de branches. Profile-guided optimization (PGO) não teve efeito mensurável: o loop interno já é branchless e o branch de fronteira de palavra é dependente de dados.
Nem todo vocabulário é igual
A comparação não é estritamente justa. O Gigatoken codifica arquivos inteiros sem divisão prévia, encontrando suas próprias fronteiras de documento e paralelizando automaticamente. Os baselines (HuggingFace encode_batch_fast e tiktoken encode_ordinary_batch) são avaliados em fatias pré-divididas, sem cache.
Vocabulários SentencePiece (Gemma, CodeLlama) são apenas parcialmente otimizados: no EPYC, o Gemma 1 processa a 2,51 GB/s (7,3×), o Gemma 3 a 3,43 GB/s (9,6×) e o CodeLlama a 3,47 GB/s (10,0×). Ganhos substanciais, mas uma ordem de grandeza abaixo do desempenho BPE do GPT-2. WordPiece não é suportado.
Uma reprodução independente no KrabArena (VM Intel Xeon de 4 vCPUs, fatia de 174 MB do OpenWebText) confirmou: Gigatoken 0.9.0 atingiu mediana de 277,8 MB/s contra 10,62 MB/s do tiktoken (26,2×) e 3,33 MB/s dos tokenizers do HuggingFace (83,4×).
Por que isso importa agora
Com conjuntos de dados de pré-treinamento medidos em dezenas de terabytes e pipelines de dados que precisam alimentar GPUs famintas em escala de datacenter, o custo da tokenização deixou de ser desprezível. Um tokenizador que entrega 24 GB/s em vez de 24 MB/s transforma o pré-processamento de um gargalo de horas em uma tarefa de minutos — e faz isso em hardware commodity, sem aceleradores especializados.
A biblioteca está disponível no GitHub e no PyPI sob licença MIT.
Descubra mais sobre noticiAI
Assine para receber nossas notícias mais recentes por e-mail.
