Tokenizers v1: Hugging Face acelera a tokenização em até dezenas de vezes

A tokenização deixou de ser coadjuvante no pipeline de ML

Durante anos, o tokenizador foi tratado como uma etapa leve — computacionalmente barata diante do peso do treinamento e da inferência dos grandes modelos. Mas, à medida que os modelos ficam mais rápidos e as cargas de trabalho escalam, essa equação começa a mudar. Servir muitas requisições simultâneas ou processar entradas muito longas pode pressionar o tokenizador a ponto de ele deixar a GPU ociosa esperando a CPU terminar a conversão de texto em IDs.

É exatamente esse gargalo que a Hugging Face decidiu atacar no tokenizers v1, cuja versão candidata já está disponível no crates.io. Segundo a equipe, a nova versão é frequentemente dezenas de vezes mais rápida que a v0.23 — preservando exatamente os mesmos tokens de saída, a mesma API, o vocabulário e os ranks de merge.

O que mudou por dentro

Um tokenizador converte texto em quatro estágios: normalização, pré-tokenização, o “modelo” (que transforma pré-tokens em tokens e IDs) e pós-processamento. A maior parte do ganho veio do estágio de modelo, onde oito das dez famílias medidas usam Byte Pair Encoding (BPE) — o algoritmo que junta repetidamente o par adjacente de maior rank até não restar nenhum par ranqueado.

As mudanças que mais importam:

• bitcannon: a divisão do texto em pré-tokens deixa de usar um motor de regex genérico e passa a usar operações booleanas sobre bitstreams com instruções SIMD — decidindo 64 bytes por operação de registrador.
• cache de palavras: como o BPE sempre produz os mesmos IDs para um mesmo pré-token, um memo por thread reaproveita o resultado de palavras repetidas, pulando o processo de merge.
• reescrita do loop de merge: os símbolos viram uma lista duplamente encadeada dentro de um buffer pré-alocado, então um merge atualiza dois índices em vez de mover dados.
• modelo sem alocação: o conjunto de trabalho do merge vive num buffer de rascunho do chamador — o loop nunca toca o alocador.
• paralelismo nativo: um tokenizador compartilhado codifica a partir de muitas threads ao mesmo tempo, cada uma com seu próprio buffer e cache, sem fila em um lock único.

Por que isso importa agora

No Brasil, o ecossistema de aplicações com LLMs — RAG, assistentes, agentes, inferência local com pesos abertos — cresce rápido. Em cenários de serving com muitas requisições concorrentes ou de janelas de contexto longas, a tokenização deixa de ser “gratuita” e vira o elo que trava o pipeline. O objetivo declarado da Hugging Face é claro: “suas GPUs nunca devem ficar ociosas esperando a CPU terminar a tokenização”.

Vale destacar o caráter colaborativo do trabalho: bibliotecas como gigatoken, tiktoken, kitoken e fastokens ajudaram a apontar o caminho, e IBM, NVIDIA e a equipe do ExecuTorch contribuíram com patches e testes em hardware variado. A v1 já traz bindings para Node.js, e a versão 1.0.0 deve incluir bindings C/C++ voltados a ExecuTorch e llama.cpp, além de um caminho futuro para codificação em GPU (tok-devices).

O detalhe que garante tranquilidade para quem atualiza: a v1 produz exatamente os mesmos token IDs da v0.23. Não há mudança de vocabulário nem de comportamento — só de desempenho e de arquitetura interna do código.