Contagem de Tokens em LLMs: Por que Todo Desenvolvedor Precisa Entender Isso

Quando desenvolvedores começam a trabalhar com APIs de grandes modelos de linguagem, uma pergunta surge quase imediatamente: "Qual é o limite máximo?" Eles pensam em palavras, parágrafos ou caracteres — mas o modelo pensa em tokens. Entender o que são tokens, como são contados e por que a contagem importa é uma das coisas mais praticamente úteis que você pode aprender antes de construir algo sério sobre um LLM.

Você pode usar o Contador de Tokens do BrowseryTools — gratuito, sem cadastro, tudo fica no seu navegador — para contar tokens de qualquer texto antes de enviá-lo a uma API.

O que É um Token? (Não é uma Palavra, Não é um Caractere)

Um token é a unidade fundamental de texto que um modelo de linguagem processa. Não é uma palavra. Não é um caractere. É um pedaço de texto que o tokenizador do modelo aprendeu a tratar como uma única unidade — e esse pedaço pode ser desde um único caractere até um fragmento de palavra com vários caracteres ou uma palavra comum inteira.

Aqui estão alguns exemplos de como uma frase pode ser dividida em tokens por um tokenizador da família GPT:

"Hello, world!"
→ ["Hello", ",", " world", "!"]  — 4 tokens

"unbelievable"
→ ["un", "believ", "able"]  — 3 tokens

"ChatGPT"
→ ["Chat", "G", "PT"]  — 3 tokens

"2026-03-22"
→ ["2026", "-", "03", "-", "22"]  — 5 tokens

Observe como palavras curtas comuns como "Hello" mapeiam para um único token, enquanto palavras mais longas ou incomuns são divididas em vários tokens. Pontuação, números e caracteres especiais frequentemente são seus próprios tokens. O tokenizador não simplesmente divide nos espaços ou na pontuação — usa um vocabulário aprendido de unidades de sub-palavras para alcançar o melhor equilíbrio entre tamanho do vocabulário e eficiência de representação.

Como os Tokenizadores Funcionam: Codificação por Par de Bytes

A maioria dos LLMs modernos — GPT-4, Claude, Gemini, Llama — usa uma variante da Codificação por Par de Bytes (BPE) ou um algoritmo intimamente relacionado chamado SentencePiece. O BPE foi originalmente desenvolvido para compressão de dados; foi adaptado para o processamento de linguagem natural porque resolve elegantemente o problema do vocabulário aberto.

O processo de treinamento do BPE começa com caracteres individuais (ou bytes) como vocabulário base. Ele então encontra repetidamente o par de símbolos que co-ocorre com mais frequência no corpus de treinamento e os mescla em um único novo símbolo. Após milhares dessas mesclagens, o vocabulário resultante contém palavras comuns como tokens únicos, prefixos e sufixos comuns como tokens, e palavras raras como sequências de tokens menores. O tamanho final do vocabulário é tipicamente de 32.000 a 100.000 tokens.

Isso significa que a tokenização de qualquer texto depende inteiramente do vocabulário específico com o qual o modelo foi treinado. GPT-4, Claude e Gemini usam tokenizadores diferentes — o mesmo texto pode se tokenizar em contagens diferentes em cada modelo. Nunca assuma que uma contagem de tokens que você mediu para um modelo se aplica a outro.

A Regra Prática de "750 Palavras por 1.000 Tokens"

Você frequentemente verá a aproximação "1.000 tokens ≈ 750 palavras" citada para texto em inglês. Esta é uma heurística razoável para prosa típica — posts de blog, artigos, documentação. Ela vem da observação de que em um corpus de inglês balanceado, o comprimento médio do token é de cerca de 4–5 caracteres, e a palavra média em inglês tem cerca de 5 caracteres mais um espaço. Portanto, uma palavra mapeia para aproximadamente 1,3 tokens em média.

Mas "regra prática" é o enquadramento certo — ela quebra rapidamente na prática:

• Código tokeniza mais densamente — Linguagens de programação usam muitas palavras-chave curtas, operadores e identificadores que são frequentemente tokens únicos. Um bloco de Python pode tokenizar com menos tokens por caractere do que prosa em inglês.
• URLs e strings técnicas são caras — Uma URL longa como https://api.example.com/v2/users/84219/preferences?include=notifications pode tokenizar em mais de 20 tokens, apesar de parecer curta na tela.
• Números são surpreendentemente custosos — Cada dígito em um número longo é frequentemente um token separado. O número "1738371600" pode se tornar 5–7 tokens.
• Espaços em branco repetidos e formatação — JSON com indentação pretty-print, tabelas Markdown e código com aninhamento profundo adicionam tokens de espaços em branco.

Idiomas Não Ingleses: Árabe, Chinês e a Diferença no Custo de Tokens

A heurística de 750 palavras por 1.000 tokens é uma heurística do inglês. Para outros idiomas, a proporção pode ser dramaticamente diferente — e isso tem implicações reais de custo para aplicações multilíngues.

O árabe e o hebraico usam morfologia de raiz e padrão, onde uma única raiz gera dezenas de formas derivadas através de prefixos, sufixos e mudanças de vogais internas. Palavras como "وسيستخدمونها" (eles vão usá-la) são palavras ortográficas únicas, mas podem tokenizar em 5–8 tokens porque o vocabulário BPE foi treinado predominantemente em dados em inglês e não tem essas formas árabes como tokens únicos.

O chinês e o japonês têm um desafio diferente. Os caracteres são logográficos — cada caractere é uma unidade significativa — mas o vocabulário de tokens cobre caracteres únicos comuns e algumas palavras multi-caracteres comuns. O texto chinês tipicamente gera 1,5–2x mais tokens por "equivalente de palavra" do que o inglês. O japonês, com sua mistura de hiragana, katakana e kanji, pode gerar ainda mais.

Uma implicação prática: se você está construindo uma aplicação para árabe, chinês ou outras línguas com escrita não-latina, suas estimativas de custo derivadas de testes em inglês vão subestimar significativamente os custos reais da API. Sempre meça as contagens de tokens com seu conteúdo real usando o Contador de Tokens do BrowseryTools ou uma biblioteca de tokenização antes de fazer projeções de orçamento.

Limites da Janela de Contexto: Por que Ultrapassá-los Quebra Tudo

Todo LLM tem uma janela de contexto — o número máximo de tokens que ele pode processar em uma única requisição, contando tanto sua entrada quanto a saída do modelo. No início de 2026:

• GPT-4o — 128.000 tokens
• Claude 3.5 Sonnet — 200.000 tokens
• Gemini 1.5 Pro — 1.000.000 tokens
• Llama 3.1 70B — 128.000 tokens

Se sua entrada exceder o limite da janela de contexto, a API retornará um erro — a requisição simplesmente falha. Não há degradação graciosa por padrão; você precisa lidar com isso na lógica da sua aplicação. Mais sutilmente, mesmo dentro da janela de contexto, há um fenômeno chamado problema do "perdido no meio": modelos tendem a recordar informações no início e no final do contexto melhor do que informações enterradas no meio. Uma janela de contexto de 200K não significa que cada token nela é igualmente bem atendido.

Para aplicações de chat, a janela de contexto se preenche conforme as conversas crescem. Após turnos suficientes, você deve truncar mensagens antigas, resumi-las ou atingir o limite e falhar. Saber sua contagem de tokens em cada etapa é o que permite tomar essa decisão proativamente.

Implicações para o Design de Prompts

A consciência de tokens muda como você escreve prompts. Algumas implicações concretas:

• Prompts de sistema se acumulam em cada requisição — Um prompt de sistema de 500 tokens custa 500 × suas requisições × seu preço de entrada. Em 10.000 requisições diárias, reduzir seu prompt de sistema de 500 para 300 tokens economiza dinheiro real todo mês.
• Exemplos few-shot são caros, mas eficazes — Incluir 3 exemplos no seu prompt pode adicionar 300–500 tokens. Meça se essa melhoria de qualidade vale o custo versus fazer ajuste fino do modelo uma vez.
• O comprimento da saída é controlável — Use max_tokens para limitar a saída do modelo. Adicione instruções explícitas no seu prompt: "Responda em menos de 100 palavras." Os modelos geralmente seguem bem as instruções de comprimento de saída, o que reduz diretamente os custos de tokens de saída.
• Formatação JSON adiciona overhead — Se você está usando saída estruturada (modo JSON), as aspas, colchetes e nomes de chaves adicionam tokens além dos seus valores de dados reais. Uma resposta com 5 campos curtos pode facilmente ter 40% de overhead em tokens de formatação.

Conte Tokens Antes de Enviar

O melhor hábito a construir ao trabalhar com APIs de LLM é contar seus tokens antes de se comprometer com uma arquitetura ou ir para produção. Cole seu prompt de sistema, uma mensagem de usuário representativa e qualquer contexto que você planeja incluir no Contador de Tokens do BrowseryTools. Você verá imediatamente se seu design está bem dentro da janela de contexto ou perigosamente perto do limite — e terá os números necessários para estimar custos com precisão.