Tokenization III: SentencePiece, byte-level e por que a contagem de tokens morde

01 · Conceito

Conceito

Você publica um assistente de suporte em dois idiomas. Mesmo produto, mesmo system prompt, mesmo modelo, tradução fiel. Um mês depois, o relatório financeiro mostra a implantação em português custando visivelmente mais por conversa que a em inglês. Ninguém escreveu código diferente. A diferença foi decidida anos antes, por qualquer que tenha sido o corpus sobre o qual os merges do tokenizer foram contados.

A pergunta quantos tokens tem este texto não tem resposta enquanto um tokenizer não for nomeado. Um token não é uma unidade linguística estável; é uma entrada no vocabulário fixo de um modelo, produzida sob uma política de normalização e uma lista ordenada de merges, como a lição 1.3 estabeleceu. Dois modelos podem exibir texto decodificado idêntico e ocupar números diferentes de posições para fazê-lo.

Trabalhe o exemplo de forma concreta, com o passo de medição explicitado, porque é o passo que as pessoas pulam. Pegue uma frase em inglês e sua tradução em português, passe as duas pelo tokenizer que acompanha o Qwen3.8-27B e registre as contagens. Suponha que sua medição devolva 18 tokens para o inglês e 26 para o português — um par de números ilustrativo, não um fato publicado, e exatamente o tipo de coisa que você precisa medir em vez de citar. A razão é de cerca de 1,44, ou seja, o texto em português consome quarenta e quatro por cento mais tokens de input cobrados e posições de contexto neste exemplo. Isso não prova exatamente quarenta e quatro por cento mais compute ou latência de prefill: esses valores dependem da arquitetura, do comprimento da sequência, do batching, dos kernels e do hardware, portanto meça o runtime em produção.

Agora converta posições em dinheiro. Em agosto de 2026, a Cloudflare Workers AI listava o Qwen3.8-27B a USD 0,45 por milhão de tokens de input e USD 3,20 por milhão de tokens de output. Um milhão de requisições a 18 tokens de input cada são 18 milhões de tokens:

Uma diferença de USD 3,60 por milhão de requisições. Por requisição é invisível, três décimos de milésimo de centavo, e é justamente por isso que nunca é pego numa revisão. Em volume, é um imposto estrutural cobrado de uma das suas duas populações de usuários, e cresce com cada system prompt, cada documento recuperado e cada turno de conversa que é reinjetado no contexto.

Aqui está o erro de caminho, e ele é quase universal. Alguém estima tokens como caracteres divididos por quatro, ou palavras divididas por 0,75. Essas razões foram calibradas em prosa inglesa e desabam em qualquer outro lugar. A flexão e os caracteres acentuados do português segmentam diferente. Chinês e japonês não têm espaços para ancorar os pedaços. Código-fonte, números longos, URLs, tabelas e emojis fragmentam de formas que nenhuma constante derivada de prosa antecipa. Pior, a regra falha de forma assimétrica, então subestima exatamente os idiomas que já pagam mais, o que transforma um erro de orçamento num problema de justiça. A correção não é uma constante melhor. É parar de estimar: o tokenizer está a poucas linhas de distância e devolve a verdade em milissegundos.

As famílias de tokenizer diferem em como chegam a essa verdade. Muitos pipelines primeiro dividem por espaço ou pontuação e só depois aprendem subpalavras dentro dos pedaços, o que embute silenciosamente suposições específicas de idioma no pré-processamento. O SentencePiece foi projetado para treinar direto de frases cruas, representando o espaço em branco como um símbolo explícito para que tokenization e detokenization formem um processo fechado e reversível. É um kit de ferramentas e não um algoritmo único, suportando merges no estilo BPE assim como o modelo Unigram, que parte de um vocabulário candidato, atribui probabilidades aos pedaços e poda iterativamente rumo a um vocabulário que dê alta verossimilhança ao corpus. O Unigram admite várias segmentações de uma string e pode amostrar entre elas, o que os merges ordenados do BPE não fazem.

Abordagens byte-level, que é a família à qual o Qwen3.8-27B pertence, resolvem a cobertura por baixo. O pré-tokenizador ByteLevel do Qwen fornece unidades derivadas de bytes para todo byte UTF-8 de texto Unicode válido após normalização NFC, então escritas nunca vistas não precisam de um símbolo desconhecido. Seu tokenizer público continua sendo uma interface de texto, não um decoder de binário arbitrário, e o modelo BPE publicado define byte fallback como falso. A eficiência não decorre disso: um fragmento familiar do inglês pode ser um token só enquanto um grafema incomum se expande em vários pedaços de byte, e essa assimetria é o mecanismo por trás da fatura acima.

A normalização mexe nas contagens antes de qualquer uma dessas etapas. Strings Unicode canonicamente equivalentes podem diferir em code points, enquanto o normalizador NFC do Qwen colapsa as duas grafias de café examinadas na lição 1.1 antes do BPE. Passar tudo para minúsculas, aplicar normalização de compatibilidade, limpar espaços e tratar acentos — cada uma dessas operações funde distinções de que alguma tarefa em algum lugar precisa. Depois, os tokens especiais acrescentam uma camada inteiramente invisível na caixa de texto: marcadores de início e fim, separadores de papel, delimitadores de chamada de ferramenta e todo o andaime do chat template ocupam posições e são todos cobrados. Num modelo com modos de raciocínio e sem raciocínio, o próprio template difere entre eles, o que a lição 6.2 desenvolve.

Ao comparar tokenizers a sério, use corpora representativos por idioma e domínio e reporte distribuições em vez de uma anedota: comprimentos de sequência na mediana e na cauda, a proporção de fragmentos derivados de bytes e com que gravidade os termos importantes do seu domínio fragmentam. Verifique a decodificação contra o contrato de normalização declarado pelo tokenizer e se tokens especiais não podem ser forjados a partir de texto do usuário.

A conclusão é firme e um pouco desconfortável. Tokens são embalagem específica de cada modelo. SentencePiece, BPE, Unigram e tokenization byte-level são escolhas de engenharia que trocam tamanho de vocabulário por cobertura, comprimento de sequência e viés indutivo, e nenhuma delas entrega uma unidade natural neutra em relação ao idioma. As consequências recaem de forma desigual sobre usuários reais, e a única prática defensável é medir a requisição exata contra o tokenizer exato em produção e então precificá-la a uma tarifa que você consiga datar.