O que são Tokens e Como São Contabilizados: A Fundamentação Arquitetural na Era dos LLMs

A Anatomia Atômica: A Ponte Entre Linguagem Humana e Vetores

No centro de toda arquitetura de Modelos de Linguagem de Grande Escala (LLMs), reside um conceito fundamental e frequentemente mal compreendido pelos desenvolvedores: o token. Para compreender o funcionamento interno de redes neurais como GPT-4, Llama 3 ou Claude 3, precisamos primeiro aceitar que os modelos não leem palavras, caracteres ou frases completas da mesma forma que os humanos. Eles operam puramente no domínio matemático, manipulando matrizes de alta dimensionalidade. O token é a unidade atômica dessa tradução, agindo como a ponte essencial entre a semântica da linguagem humana e os vetores de embedding numéricos.

Quando enviamos uma string de texto para uma API de IA, ela passa por um processo de pré-processamento estrito antes de tocar nos pesos sinápticos do modelo. Se os computadores processassem texto caractere por caractere, o custo computacional e o consumo de memória explodiriam devido à complexidade quadrática dos mecanismos de atenção (Self-Attention). Por outro lado, se processassem palavras inteiras, o vocabulário necessário seria infinitamente grande, gerando o problema de out-of-vocabulary (OOV) para palavras raras, flexões gramaticais ou termos técnicos recém-criados. O token resolve esse dilema ao dividir o texto em subpalavras (subwords), equilibrando a granularidade semântica com a eficiência computacional.

Algoritmos de Tokenização por Dentro: BPE, WordPiece e SentencePiece

A conversão de texto bruto em uma sequência de IDs numéricos é governada por algoritmos sofisticados de tokenização. O estado da arte atual apoia-se principalmente em três abordagens: Byte Pair Encoding (BPE), WordPiece e SentencePiece. Cada um possui particularidades algorítmicas que impactam diretamente o tamanho do contexto e o desempenho do modelo em diferentes idiomas.

O Byte Pair Encoding (BPE), inicialmente um algoritmo de compressão de dados adaptado para o processamento de linguagem natural, começa tratando cada caractere como um token individual. Iterativamente, ele varre o corpus de treinamento para contar a frequência de todos os pares de tokens adjacentes, mesclando o par mais frequente em um novo token composto. Esse processo repete-se até atingir o tamanho de vocabulário desejado. O código abaixo demonstra uma implementação conceitual simplificada do conceito de contagem de pares em BPE:

def get_stats(vocab):
    pairs = {}
    for word, freq in vocab.items():
        symbols = word.split()
        for i in range(len(symbols) - 1):
            pair = (symbols[i], symbols[i+1])
            pairs[pair] = pairs.get(pair, 0) + freq
    return pairs

# Exemplo conceitual de mapeamento de frequências de subpalavras
initial_vocab = {"l o w": 5, "l o w e r": 2, "n e w e s t": 6}
print(get_stats(initial_vocab))

Por outro lado, o WordPiece (utilizado pelo BERT) opera de forma semelhante, mas em vez de selecionar o par mais frequente baseado puramente na contagem bruta, ele utiliza a probabilidade de máxima verossimilhança (Maximum Likelihood Estimation - MLE). O algoritmo avalia o quanto a fusão de dois tokens melhora a probabilidade do modelo linguístico global. Já o SentencePiece trata o fluxo de texto como uma sequência bruta de bytes, ignorando a necessidade de espaços em branco explícitos como delimitadores de palavras. Isso torna o SentencePiece agnóstico a idiomas, sendo amplamente adotado em modelos multilíngues modernos como o T5 e o Llama.

A Disparidade Multilíngue: Por Que o Português e o Código Consomem Mais Tokens

Um dos maiores gargalos arquiteturais e financeiros para empresas que operam na América Latina é a ineficiência de tokenização em idiomas diferentes do inglês. Os tokenizadores dos principais modelos comerciais foram treinados predominantemente em corpora em língua inglesa (geralmente acima de 70% ou 80% do total de dados). Como resultado, o vocabulário interno do tokenizador possui muito mais subpalavras otimizadas para o inglês do que para o português, espanhol ou código-fonte estruturado.

Na prática, isso significa que palavras comuns em português são fragmentadas em um número muito maior de tokens. O mesmo fenômeno ocorre ao processar blocos de código em linguagens como TypeScript, Python ou Rust, onde caracteres especiais, indentação e nomes compostos de variáveis geram quebras agressivas. A tabela abaixo ilustra essa disparidade gritante em cenários reais de engenharia:

Essa disparidade não afeta apenas o bolso do desenvolvedor via cobrança por token nas APIs; ela impacta diretamente a Context Window útil do modelo. Se um prompt em português consome o dobro de tokens para transmitir a mesma semântica que em inglês, o modelo esgotará sua janela de contexto muito mais rápido, limitando a quantidade de código ou documentação que pode ser injetada via RAG (Retrieval-Augmented Generation).

Matemática de Custos e Limites de Context Window

Na arquitetura de sistemas baseados em LLMs, a gestão do orçamento e da janela de contexto é uma disciplina crítica de engenharia de software. A janela de contexto (context window) — seja de 8k, 128k ou 1 milhão de tokens — representa o limite máximo de tokens que o mecanismo de atenção consegue processar simultaneamente em uma única inferência. No entanto, é vital entender que o custo computacional e de latência cresce de forma não linear (frequentemente quadrática em relação ao comprimento do prompt devido ao cálculo da matriz de atenção QKV).

Além disso, o modelo de precificação das APIs comerciais separa claramente o custo em duas frentes:

• Input Tokens (Prompt): Tokens enviados pelo cliente para contextualizar o modelo (instruções, histórico de chat, documentos recuperados). Geralmente possuem um custo menor por milhão de tokens.
• Output Tokens (Completion): Tokens gerados autoregressivamente pelo modelo token a token. O custo é consideravelmente mais alto (muitas vezes 3x a 4x o preço do input) devido à natureza sequencial da geração, onde a paralelização é severamente limitada.

Arquitetos de software devem projetar sistemas que evitem o envio redundante de contexto estático a cada requisição. Enviar um manual de 50 páginas de documentação técnica em todas as chamadas de API é um antipadrão financeiro e arquitetural severo.

Técnicas de Engenharia para Otimização, Caching e Compressão de Prompt

Para mitigar os altos custos e as restrições de latência impostas pela contagem de tokens, diversas estratégias de engenharia de software e otimização de prompts devem ser aplicadas em produção:

1. Prompt Caching: Provedores modernos como Anthropic (Claude) e OpenAI oferecem mecanismos de cache para prefixos de prompts longos. Se você envia sistematicamente um prompt de sistema volumoso (ex: 20k tokens de regras de negócio e documentação corporativa), o sistema armazena os estados de atenção em cache, reduzindo o custo de input em até 90% e diminuindo drasticamente o Time-to-First-Token (TTFT).
2. Compressão Semântica e Summarization: Antes de injetar históricos de chat longos no contexto, utilize modelos menores e mais baratos (ou algoritmos heurísticos) para resumir mensagens antigas, mantendo apenas entidades e intenções-chave.
3. Redução de Verbose e Minificação de Prompts: Evite preâmbulos educados excessivos ("Por favor, você poderia me ajudar com..."). Instruções diretas, imperativas e o uso de delimitadores estruturados (como tags XML ou JSON limpo) reduzem drasticamente o desperdício de tokens com