Como a tokenização do GPT realmente funciona (e por que sua conta depende disso)

Cada chamada de API para um modelo de linguagem grande é medida em tokens — nem caracteres nem palavras. Tokens são a unidade que o modelo realmente consome após o texto ser codificado por um tokenizador de codificação de par de bytes(BPE). Entender como a tokenização funciona importa porque (a) determina sua conta e (b) é por isso que “um documento de 1000 palavras” não mapeia claramente para “uma estimativa de custo de 1000 tokens.”

Como os tokenizadores BPE funcionam

O algoritmo em poucas linhas:

1. Comece com um vocabulário de bytes individuais (256 entradas).
2. Encontre o par adjacente mais frequente de entradas do vocabulário em um grande corpus de treinamento.
3. Adicione esse par como uma nova entrada do vocabulário.
4. Repita até o vocabulário atingir o tamanho alvo (50k-100k entradas para modelos modernos).
5. Para tokenizar novo texto, substitua pares de forma gananciosa do mais longo para o mais curto.

Resultado: palavras comuns em inglês como “the”, “and”, “understanding” se tornam um único token cada. Palavras raras como “rambunctious” são divididas em 2-4 tokens. Emojis e caracteres não ingleses frequentemente levam 2-6 tokens cada.

Contagem de tokens para conteúdo comum

Contagens aproximadas de tokens para GPT-4 (tokenizador cl100k_base):

A cifra de referência para inglês é ~750 palavras por 1.000 tokens. Scripts não latinos custam significativamente mais tokens por caractere porque não foram tão densamente representados no corpus de treinamento.

Por que a diferença de custo importa

O preço por token significa que o conteúdo em idiomas não ingleses custa 2-4 vezes mais pela mesma ideia. Um documento de 1.000 palavras custa:

• Inglês: ~1.300 tokens → US$0,013 ao preço de entrada GPT-4o (~US$10/M tokens).
• Russo: ~3.500 tokens → US$0,035 (2,7 vezes mais pelo mesmo conteúdo).
• Chinês: ~1.500 tokens (por caractere, scripts densos compensam ligeiramente) → US$0,015.

Para uma empresa de tradução ou um sistema de suporte multilíngue, a assimetria de custo por idioma se acumula rapidamente. Anthropic, OpenAI e Google publicam custos por token por modelo; o custo real de conteúdo depende de qual idioma e formato você está pagando.

Diferenças de tokenizador entre modelos

Cada família de modelos tem seu próprio tokenizador:

• OpenAI cl100k_base (GPT-3.5, GPT-4): vocabulário de ~100.000 tokens. O tokenizador moderno de referência para inglês.
• OpenAI o200k_base (GPT-4o, série o): vocabulário de 200.000 tokens. Melhor em idiomas não ingleses e código. Um determinado documento precisa de ~10-15% menos tokens do que com cl100k.
• Tokenizador do Anthropic Claude: proprietário. Aproximadamente densidade similar ao cl100k para inglês; difere de forma mensurável para código e idiomas não ingleses. O Anthropic publica um endpoint de contagem de tokens para estimar antes de enviar.
• Google Gemini: usa SentencePiece. Densidade aproximadamente comparável ao cl100k.

Implicação: o mesmo prompt enviado para GPT-4o vs Claude vs Gemini não produz contagens de tokens idênticas. Orçamentar entre provedores requer estimativa de tokens por provedor, não uma única regra de “1 palavra ≈ 1,3 tokens”.

Onde a tokenização afeta o design de prompts

1. Custos de contexto longo. Uma janela de contexto de 100k tokens contendo toda a sua documentação é ótima até você perceber que o custo por chamada é de US$1+ para uso típico. As contagens de tokens se acumulam em conversas de múltiplos turnos.
2. JSON vs linguagem natural. Pedir saída JSON custa ~30-50% mais tokens do que pedir prosa simples comparável. A pontuação do JSON é tokenizada de forma agressiva.
3. Tarefas de código. O código é aproximadamente 2 vezes mais denso em tokens do que a prosa. Um arquivo de 200 linhas pode ter 2.000-3.000 tokens. Ferramentas que incluem todo o repositório como contexto acumulam rapidamente.
4. Idiomas não ingleses. 2-4 vezes mais tokens por caractere. Para produtos multilíngues, este é um custo de primeira ordem.

Como estimar tokens antes de pagar

1. Use uma ferramenta de contagem de tokens. Nosso contador de tokens de IA implementa múltiplos tokenizadores e relata a contagem exata para sua entrada.
2. Use a biblioteca oficial de tokenizadores. O tiktoken da OpenAI (Python), a API de tokenizadores do Anthropic ou contadores de tokens hospedados. Esses são a verdade para faturamento.
3. Regra prática. Para prosa em inglês: 1 palavra ≈ 1,3 tokens. Para código: 1 linha ≈ 8-15 tokens. Para chinês: 1 caractere ≈ 1,5 tokens.
4. Orçamente também a saída. Muitos provedores cobram mais pela saída do que pela entrada (tipicamente 3-5× por token). Uma saída de 2.000 tokens é mais cara do que uma entrada de 2.000 tokens.

A razão estrutural mais profunda para o BPE

Os LLMs modernos veem tokens, não caracteres. Os embeddings, a atenção e a saída do modelo são todos definidos sobre um vocabulário de tokens finito. Modelos em nível de caractere existem, mas são mais lentos (cada caractere é uma posição de entrada) e mais difíceis de treinar. Modelos em nível de palavra não conseguem lidar com palavras não vistas (problema de fora do vocabulário). O BPE é o compromisso que venceu.

Para mais detalhes, veja nossa entrada do glossário de token GPT e o guia sobre como funciona o preço por token.

Passo a passo: tokenizando uma única frase

Frase: “The rambunctious cat’s purr 😺 was unmistakable.” (9 palavras, 49 caracteres com o emoji.)

No cl100k_base (GPT-4):

• The → 1 token (palavra muito comum com variante de espaço inicial).
• rambunctious → 3 tokens ( ram + bunct + ious).
• cat → 1 token.
• ’s → 1 token (a contração apóstrofe-s é uma única mesclagem).
• purr → 1 token.
• 😺 → 3 tokens (os bytes UTF-8 do emoji divididos em múltiplas peças BPE).
• was → 1 token.
• unmistakable → 2 tokens ( unm + istakable).
• . → 1 token.

Total: 14 tokens para 9 palavras — uma proporção de 1,56 tokens por palavra elevada por rambunctious(3 tokens) e o emoji (3 tokens). Substituir ambos por alternativas comuns reduz o custo: “The loud cat’s purr was unmistakable” roda com ~9 tokens para a mesma ideia. Para uso de API em alto volume, esse tipo de engenharia de vocabulário se acumula.

Erros comuns

• Estimar tokens a partir da contagem de caracteres. A regra prática de “1 token ≈ 4 chars” é muito imprecisa para código, JSON e idiomas não ingleses. Um blob JSON de 1.000 chars pode ser 400-800 tokens dependendo dos nomes de chave e aninhamento.
• Esquecer os tokens do prompt do sistema. Um prompt de sistema de 2.000 tokens é incluído em cada solicitação e cobrado a cada chamada. Agentes de múltiplos turnos com histórico de chat crescente pagam por toda a conversa anterior em cada rodada, não apenas pela mensagem mais recente.
• Os benefícios de cache dependem da estabilidade do prefixo. O cache de prompt (quando disponível) só funciona quando a sequência de tokens é byte-idêntica no prefixo. Um timestamp inserido dinamicamente na posição 50 invalida o cache para todos os tokens seguintes. Coloque o conteúdo dinâmico no final, não no meio.
• Usar o tokenizador errado para estimativa de custo. cl100k_base e o200k_base produzem ~10-15% de contagens de tokens diferentes para a mesma entrada. Se você estiver modelando custos para GPT-4o usando cl100k, a estimativa é alta; para modelos da série o também é alta. Use o tokenizador que corresponde ao modelo alvo.
• Remover espaços em branco de forma agressiva. Muitos tokens começam com um espaço inicial. Remover todos os espaços e concatenar palavras pode produzir maistokens, não menos, porque o tokenizador não consegue usar suas mesclagens comuns de “ palavra” e volta para divisões em nível de byte.