Como funciona um LLM: tokens, temperatura e top-p na prática

Um colega abriu um chamado com o título "LLM não determinístico em produção": mesmo prompt, mesmo modelo, duas respostas diferentes com cinco minutos de intervalo. Ele já tinha colocado temperature: 0 e esperava resultado idêntico. Não é bug — é o jeito como um LLM gera texto, e entender essa mecânica resolve metade das dúvidas que aparecem quando você coloca um modelo de linguagem numa aplicação.

A resposta curta: um LLM prevê o próximo token, um de cada vez, a partir de uma distribuição de probabilidade sobre todo o seu vocabulário. Ele sorteia (ou escolhe) um token dessa distribuição, anexa ao texto e repete até parar. Temperatura, top-k e top-p são só formas de mexer nesse sorteio; a janela de contexto é o limite de quanto texto entra em cada passo.

Este é o mergulho técnico. Se você quer o panorama — o que é IA generativa, onde ela entra e onde não entra — comece por O que é IA generativa e volte aqui para ver o motor por dentro.

Tokenização: o modelo não lê palavras, lê pedaços

Antes de qualquer previsão, o texto vira uma lista de números. O tokenizador quebra a entrada em tokens — palavras inteiras, pedaços de palavras ou bytes — e cada token tem um ID no vocabulário. A família mais comum é o BPE (Byte Pair Encoding), que monta o vocabulário juntando os pares de bytes mais frequentes no corpus de treino. Cada empresa treina o seu: a OpenAI publica os dela na biblioteca tiktoken; a Anthropic não publica o tokenizador do Claude, mas expõe um endpoint de contagem de tokens.

Rodei a tiktoken com dois tokenizadores públicos da OpenAI para ver o efeito na prática:

Com o vocabulário maior, " Brasília" virou um token só. Isso tem consequências diretas:

• O mesmo texto custa um número diferente de tokens em cada modelo — e você paga por token.
• Uma janela de "1M tokens" não é 1M de palavras. A Anthropic estima cerca de 555 mil palavras em 1M de tokens no tokenizador atual do Claude, introduzido com o Claude Opus 4.7 (visão geral de modelos, consultada em novembro de 2026).
• Português costuma gastar mais tokens que inglês. Nas quatro frases que medi (pt e a tradução en), o cl100k_base gastou 1,46× mais tokens em português; o o200k_base, 1,19×. É uma amostra pequena — o número exato depende do tokenizador e do texto —, mas a direção é consistente.

A previsão do próximo token: o loop central

Com a entrada tokenizada, o modelo faz uma passada pela rede e devolve um número (logit) para cada token do vocabulário. O softmax transforma esses números em probabilidades que somam 1. Um token é escolhido, anexado à sequência, e a sequência inteira volta para a próxima passada. Isso é geração autorregressiva: cada token de saída custa uma passada pelo modelo, então uma resposta de 300 tokens são 300 passadas.

Entrada (o200k_base): ["A", " capital", " do", " Brasil", " é"]
Passada 1 → distribuição: { " Brasília": 0.74, " Rio": 0.17, " São": 0.06, ... }
Token escolhido: " Brasília"
Nova entrada: ["A", " capital", " do", " Brasil", " é", " Brasília"]
Passada 2 → distribuição: { ".": 0.81, ",": 0.12, ... }

Os números da primeira passada são os do exemplo de temperatura mais abaixo; os da segunda são ilustrativos. Num tokenizador antigo como o cl100k_base, a mesma resposta precisaria de duas passadas: primeiro " Bras", depois "ília".

O modelo não tem uma resposta "guardada". Ele tem bilhões de pesos ajustados para que a distribuição de probabilidade do próximo token se pareça com o texto que viu no treino.

Como o modelo aprende: pré-treino, ajuste fino e RLHF

O treino de um LLM moderno tem, grosso modo, três etapas:

1. Pré-treino. O modelo lê um corpus enorme e aprende a prever o próximo token, minimizando a entropia cruzada (cross-entropy) entre a distribuição que ele prevê e o token que realmente veio. É aqui que entram gramática, fatos, padrões de código — tudo como estatística de sequência.
2. Ajuste por instrução (SFT). O modelo pré-treinado completa texto, mas não segue pedidos. Ele é ajustado com exemplos de pergunta e resposta bem escritos para se comportar como assistente.
3. Ajuste por preferência (RLHF/RLAIF). Pessoas comparam pares de respostas e indicam a melhor; um modelo de recompensa aprende essas preferências e o LLM é otimizado contra ele. Esse é o método do InstructGPT. Na variante RLAIF, parte do julgamento vem de outro modelo guiado por princípios escritos, como no Constitutional AI da Anthropic.

O ponto que muita gente erra: o RLHF alinha o modelo a preferências humanas — respostas úteis, educadas, no formato certo —, não a uma base de fatos verificados. Ele reduz certos erros, mas não transforma o modelo num banco de dados.

Atenção: por que contexto longo custa caro

O mecanismo de self-attention é o que deixa o modelo usar o contexto inteiro em cada passada. Para cada token, ele calcula vetores de query, key e value e decide quanto cada token anterior pesa na previsão atual — é assim que "ela" numa frase é ligado ao sujeito certo duas frases antes, coisa que um modelo de n-gramas, que só olha os últimos N tokens, não consegue.

Na atenção padrão do Transformer original, o custo cresce com o quadrado do tamanho da sequência: dobrar o contexto quadruplica o trabalho da atenção. Provedores usam várias otimizações para viabilizar janelas de 1M de tokens, mas a regra prática continua valendo: contexto grande é mais lento e mais caro, e a própria Anthropic avisa que precisão e recall caem conforme o contexto cresce ("context rot", na documentação de janelas de contexto).

Temperatura, top-k e top-p: um exemplo com números que fecham

A distribuição que sai do softmax raramente é usada crua. Três controles mexem nela antes do sorteio:

• Temperatura (T) divide os logits antes do softmax. T menor que 1 concentra a probabilidade no favorito; T maior que 1 achata a distribuição. T = 0 é tratado como escolha gulosa (greedy): sempre o token mais provável.
• Top-k mantém só os k tokens mais prováveis e renormaliza.
• Top-p (nucleus sampling, do artigo de Holtzman et al.) mantém o menor conjunto de tokens cuja probabilidade acumulada chega a p, e renormaliza.

Calculei com um script Python os cinco candidatos para continuar "A capital do Brasil é", com logits [4.0, 2.5, 1.5, 0.5, 0.0]:

(Valores arredondados para três casas; cada coluna soma 1.)

Agora aplique top_p = 0.9:

• Com T = 1,0: " Brasília" (0,739) + " Rio" (0,165) = 0,904 ≥ 0,9. Ficam dois tokens, renormalizados para 0,818 e 0,182.
• Com T = 1,5: " Brasília" + " Rio" = 0,793, ainda abaixo; somando " São", 0,903. Ficam três tokens: 0,642, 0,236 e 0,121.

É por isso que top-p é chamado de adaptativo: quando o modelo está confiante, o núcleo é pequeno; quando está em dúvida, o núcleo cresce. Um top_k = 2 cortaria nos mesmos dois tokens em qualquer temperatura.

A referência da API de Responses da OpenAI documenta temperature de 0 a 2 com padrão 1, top_p com padrão 1, e recomenda alterar um ou outro, não os dois (referência da API, consultada em novembro de 2026). Dois outros controles completam o quadro: o limite de tokens de saída (max_tokens na Anthropic, max_output_tokens na Responses API da OpenAI), que corta a geração quando é atingido, e as stop sequences, strings que encerram a geração quando aparecem.

Em 2026, nem sempre você pode mexer nisso

Com modelos de raciocínio, os provedores começaram a travar a amostragem. Na Anthropic, os modelos a partir do Claude 4.7 só aceitam os valores padrão, e na versão de API 2026-10-21 qualquer requisição que envie temperature, top_p ou top_k recebe erro 400, mesmo com o valor padrão (guia de migração 2026-10-21). O controle que sobra é o esforço de raciocínio (effort), não a aleatoriedade. Se o seu código ainda manda temperature: 0.2 "para ficar mais consistente", confira a documentação do modelo que você usa antes de atualizar o SDK.

E sobre o chamado do começo: temperatura 0 não garante saída idêntica em servidores de inferência. A explicação mais sólida hoje é a da Thinking Machines (setembro de 2025): os kernels não são invariantes ao tamanho do batch, e o tamanho do batch depende da carga do servidor naquele instante. A mesma requisição cai em batches diferentes e as contas de ponto flutuante saem diferentes.

Janela de contexto: memória de trabalho, com limite duro

Tudo o que o modelo "lembra" numa requisição está no contexto: system prompt, histórico, documentos, definições de ferramentas e a própria resposta sendo gerada (incluindo tokens de raciocínio). O modelo não guarda nada entre uma passada e outra além desse contexto: na API de Mensagens da Anthropic, por exemplo, você reenvia o histórico inteiro a cada chamada, e mesmo quando o provedor armazena a conversa para você, ela volta para dentro da janela a cada requisição.

Tamanhos atuais, conferidos nas páginas oficiais em novembro de 2026:

Fontes: Anthropic, OpenAI, Google. Esses números mudam a cada lançamento — trate a tabela como foto do mês.

O que acontece quando estoura? A API não descarta tokens antigos por conta própria. Na Anthropic, se a entrada sozinha passa da janela, a API devolve 400 ("prompt is too long"); se a entrada cabe mas entrada + max_tokens não cabe, os modelos 4.5 em diante aceitam a requisição e param com stop_reason: "model_context_window_exceeded" quando a geração bate no limite. Na OpenAI, o padrão (truncation: "disabled") é falhar com 400; a opção "auto", que cortava itens do começo da conversa, está marcada como deprecada. Quem corta, resume ou compacta o histórico é a aplicação — o chat que você usa, o seu agente, ou um recurso de compactação no servidor que você ativa explicitamente. E o limite não é "falta de hardware": vem da arquitetura, de até onde o modelo foi treinado para usar contexto e do custo.

Por que o modelo alucina com tanta confiança

Alucinação é o modelo gerar informação falsa com o mesmo tom de quando acerta. É consequência direta do loop: o objetivo é produzir a continuação plausível, não a verdadeira. E como cada token depende dos anteriores, um token ruim contamina o resto. Se a amostragem escolher "To" depois de "A capital do Canadá é", a continuação mais provável passa a ser "ronto" — e o modelo vai defender Toronto com fluência, porque agora isso é o contexto.

Plausibilidade e veracidade são objetivos diferentes, e o RLHF, como vimos, otimiza preferência. Para reduzir o problema em produção, o caminho é dar ao modelo os fatos no contexto e pedir que ele se apoie neles: é o que faz o RAG. Prompts com instruções explícitas também ajudam — tem um guia prático em como escrever prompts claros e uma visão menos receita de bolo em prompt engineering sem fórmulas. Quando o modelo passa a chamar ferramentas e tomar ações, o custo de uma alucinação sobe; falei disso em onde agentes de IA ajudam de verdade.

Perguntas frequentes

O modelo "pensa" antes de responder?

Modelos de raciocínio geram tokens intermediários antes da resposta final: o Claude com thinking adaptativo, os modelos da OpenAI com reasoning.effort, entre outros. Mecanicamente, continua sendo previsão de próximo token — o ganho vem de o modelo escrever passos intermediários que entram no contexto e guiam o resto. Esses tokens ocupam a janela de contexto e são cobrados como tokens de saída.

Por que um texto em português gasta mais tokens que em inglês?

Porque os tokenizadores são treinados em corpus dominados por inglês, então palavras inglesas comuns viram um token só e palavras em português com flexões e acentos se quebram mais. Nas frases que medi, a diferença foi de 1,46× no cl100k_base (GPT-4) e 1,19× no o200k_base (GPT-4o). Vocabulários maiores reduzem a diferença, mas não a eliminam.

Qual a diferença entre top-k e top-p?

Top-k corta sempre no mesmo número de candidatos; top-p corta pela massa de probabilidade acumulada. No exemplo deste post, top_p = 0.9 manteve dois tokens com T = 1,0 e três com T = 1,5, enquanto top_k = 2 manteria dois nos dois casos. A recomendação dos provedores é ajustar temperatura ou top-p, não os dois.

Por que temperatura 0 não dá sempre a mesma resposta?

Porque a conta em si varia no servidor. Os kernels de inferência não são invariantes ao tamanho do batch, e o batch muda conforme a carga, então os logits saem levemente diferentes e, num empate apertado, o token escolhido muda. Em vários modelos atuais nem dá mais para enviar temperatura: o determinismo tem de vir do seu sistema (cache de respostas, validação de saída), não do parâmetro.

Um LLM é um sorteio bem calibrado, repetido token a token

Tokenização, previsão autorregressiva e amostragem explicam quase tudo que parece estranho num LLM: por que o custo depende do idioma, por que contexto longo é lento, por que a mesma pergunta gera respostas diferentes e por que um erro no meio da frase vira uma alucinação convicta. O modelo não consulta fatos nem verifica o que escreve; ele estima a continuação mais plausível e sorteia dentro dela.

Na prática: meça tokens em vez de palavras, não confie em temperatura para ter determinismo, trate a janela de contexto como limite que a sua aplicação precisa gerenciar e coloque os fatos no prompt quando a resposta precisa estar certa. Para ter uma ordem de grandeza do tamanho de um prompt antes de mandar, eu colo o texto no contador de palavras e caracteres — não é contagem de tokens, que só o tokenizador do modelo dá, mas avisa quando aquele "contexto pequeno" já tem 40 mil palavras.