O que é LLM: o fundamento para quem vai construir com IA

Você não precisa entender transformer pra usar um LLM. Precisa entender três coisas — e nenhuma delas é transformer.

A maior parte do conteúdo sobre o que é LLM para no papagaio estocástico, na analogia do autocomplete turbinado e num diagrama de attention que ninguém consegue usar pra decidir nada. É explicação para quem vai postar sobre IA. Se você vai construir com IA, o que você precisa saber é outra coisa: o que o modelo faz mecanicamente a cada passo, o que ele não faz por você, e qual pedaço da conta sobra pro seu sistema.

Este post é o fundamento operacional. Quatro conceitos — token, estado, janela e amostragem — e, em cada um, a consequência de arquitetura que ele te obriga a aceitar. Sem analogia de papagaio. Com a doc oficial na mão.

O que é um LLM, em resumo (TL;DR)

O que é: LLM é a sigla de large language model, modelo de linguagem de larga escala. Na prática, um modelo que, dado tudo que está na entrada, estima a probabilidade do próximo token e escolhe um. Depois repete. Isso é a operação inteira.
Os três fundamentos que importam: previsão token a token, ausência total de estado entre chamadas, janela de contexto finita e degradável.
O que ele NÃO é: memória, banco de dados, função determinística ou API com garantia de formato.
Consequência de arquitetura: estado, recuperação, validação e avaliação são responsabilidade do seu código. O modelo não vai fazer nada disso por você.
Doc de referência: glossário oficial da Anthropic e o guia de janela de contexto.

O que o modelo realmente faz a cada token

Comece pela definição sem enfeite. A própria Anthropic descreve o pré-treino assim: modelos autoregressivos são treinados "para prever a próxima palavra, dado o contexto anterior do texto no documento" (glossário oficial).

É isso. A cada passo, o modelo recebe a sequência inteira que existe até ali, produz uma distribuição de probabilidade sobre todo o vocabulário, escolhe um token, cola no fim da sequência e roda de novo. Não existe um plano guardado em algum lugar. Não existe rascunho interno persistente. Cada token é uma decisão local, condicionada em tudo que já saiu.

E "token" não é palavra. Token é a unidade que o tokenizador do modelo definiu — pode ser palavra, subpalavra, caractere ou byte. Para o Claude, a doc oficial dá a régua: um token representa aproximadamente 3,5 caracteres em inglês, "embora o número exato varie dependendo da língua usada".

Esse "dependendo da língua" é a parte que custa dinheiro no Brasil. Um estudo apresentado no NeurIPS 2023 mediu o mesmo texto traduzido para várias línguas e achou diferenças de tokenização de até 15 vezes entre pares de idiomas. Português não é o pior caso, mas paga a taxa: em prosa realista com o tokenizador cl100k_base, o português consome cerca de 1,46x os tokens do inglês equivalente, e com o o200k_base a diferença fica em torno de +38% (benchmark reprodutível).

Traduzindo pra decisão real: se o seu system prompt tem 3.000 tokens em português e é reenviado em toda requisição, ele custaria uns 2.000 em inglês. Num produto com volume, isso é uma linha de planilha, não curiosidade.

A consequência de arquitetura: o modelo gera da esquerda para a direita, um token por vez, sem olhar pra frente. Ele não sabe a resposta antes de começar a escrever. Por isso "peça JSON no prompt" nunca foi garantia — é probabilidade. É exatamente por isso que existem structured output e tool calling com schema estrito: eles restringem o espaço de amostragem no servidor em vez de torcer pra distribuição colaborar. Você não controla a saída. Você controla a entrada e as restrições.

É desse fundamento que saem as decisões de arquitetura que a gente vai construir ao vivo no AI Engineering Lab 3ª Edição, nos dias 19 e 20 de setembro: tool calling, structured output, roteamento, memória, grounding, tracing, evals e custo. São dois dias das 9h às 13h, online no Meet, com código na tela e erro sendo debugado na hora.

Por que ele é stateless (e o que isso te obriga a construir)

Esse é o ponto onde mais gente se engana, porque a interface de chat mente muito bem.

A doc da OpenAI é literal: "cada requisição de geração de texto é independente e stateless" — e para fazer conversa multi-turno "você inclui a resposta anterior do modelo como entrada, e anexa essa entrada na próxima requisição" (guia de conversation state).

Não existe sessão do lado do modelo. Não existe "ele lembrou". O que existe é o seu cliente remontando a conversa inteira e reenviando tudo, do zero, a cada turno:

# turno 3: você não "continua" nada. Você reenvia a conversa inteira.
messages = [
    {"role": "user",      "content": "qual o prazo do pedido 4471?"},
    {"role": "assistant", "content": "O pedido 4471 sai dia 12."},
    {"role": "user",      "content": "e o 4472?"},
    {"role": "assistant", "content": "O 4472 sai dia 15."},
    {"role": "user",      "content": "manda os dois pro meu email"},  # <- só isso é novo
]

O modelo só sabe do pedido 4471 porque aquele texto está fisicamente na requisição número 3. Tire a linha e ele não faz ideia do que você está falando.

Agora a conta, que é a parte que ninguém mostra. Numa conversa de 20 turnos com ~500 tokens por turno, o processamento não é 20 × 500 = 10.000 tokens de entrada. É a soma acumulada: 500 × (20 × 21 / 2) = 105.000 tokens. Dez vezes e meia mais. O custo de uma conversa cresce quadraticamente com o número de turnos, não linearmente.

É por isso que prompt caching existe e não é otimização opcional em produção: reaproveitar o prefixo já processado derruba o custo de leitura para uma fração do input base. Se você nunca olhou essa conta de perto, escrevemos sobre como parar de quebrar o cache.

A consequência de arquitetura: memória é feature do seu sistema, não do modelo. Toda vez que um agente "lembrou" de algo entre execuções, alguém escreveu código que persistiu aquilo e reidratou o contexto na chamada seguinte. Não tem mágica — tem escrita em disco, ou tabela, ou vetor. A gente já destrinchou isso em um agente deixou bilhete pro próximo. Se o seu desenho de solução não tem uma resposta explícita para "onde o estado mora", você não tem desenho de solução.

Janela de contexto: o recurso que você administra

Se o modelo não tem estado e você reenvia tudo, existe um teto. Esse teto é a janela de contexto — descrita na doc da Anthropic como a "memória de trabalho" do modelo.

Primeiro, o que conta pra ela. Tudo: o system prompt, cada mensagem do array, resultados de tool, imagens, documentos, as definições das suas tools e a saída que o modelo gera, incluindo os tokens de thinking. Se está na requisição, ocupa espaço.

Os números atuais, da doc oficial: Claude Opus 5, Opus 4.8, 4.7, 4.6, Sonnet 5, Sonnet 4.6 e Fable 5 têm janela de 1 milhão de tokens, com até 128 mil tokens de saída por requisição. Modelos anteriores, como Sonnet 4.5 e Haiku 4.5, ficam em 200 mil.

E quando estoura? Se só a entrada já ultrapassa a janela, você toma um 400 invalid_request_error com "prompt is too long". Se entrada + max_tokens ultrapassa, os modelos 4.5 pra cima aceitam a requisição e param a geração com stop_reason: "model_context_window_exceeded" — que é um erro silencioso e bem mais perigoso, porque ele parece uma resposta.

Agora o ponto que separa quem leu a doc de quem leu o número de marketing: o limite técnico não é o limite útil.

A própria Anthropic nomeia o fenômeno na documentação: "conforme a contagem de tokens cresce, acurácia e recall degradam, um fenômeno conhecido como context rot. Isso torna curar o que está no contexto tão importante quanto o quanto de espaço está disponível."

Isso não é opinião de vendor. Tem literatura:

Lost in the Middle (Liu et al., TACL 2024): a performance desenha uma curva em U. O modelo usa bem o que está no começo e no fim da entrada, e degrada significativamente quando a informação relevante está no meio — "mesmo para modelos explicitamente de contexto longo".
Context Rot (Chroma, julho de 2025): 18 modelos de fronteira testados — GPT-4.1, Claude 4, Gemini 2.5, Qwen3 entre eles — e todos pioram conforme a entrada cresce, de forma não uniforme e muito antes do limite da janela (relatório).

Ou seja: encher 900 mil tokens de uma janela de 1 milhão é tecnicamente válido e operacionalmente burro.

A consequência de arquitetura: janela é orçamento, não armário. Cada token que você coloca compete por atenção com todos os outros. É por isso que RAG e recuperação não existem para "fazer caber" — existem para colocar pouca coisa e certa na janela. E é por isso que engenharia de prompt virou engenharia de contexto: o trabalho deixou de ser escrever a frase mágica e virou decidir, a cada chamada, o que merece ocupar espaço.

▪ Clã Beer and Code

Não só acompanhe as novidades — domine. Engenharia de IA na prática, ao vivo, toda semana, na maior comunidade do Brasil.

Entrar no Clã

Temperatura, top-p e a ilusão de controle

Todo tutorial de LLM tem a seção "ajuste a temperatura". Quase nenhum conta o que ela não faz.

O básico, direto da referência da API da OpenAI: temperature vai de 0 a 2 e controla o quanto a distribuição de probabilidade é achatada antes da escolha — valores altos deixam a saída mais aleatória, baixos mais concentrada. top_p é nucleus sampling: em vez de mexer na forma da distribuição, ele corta a cauda e só considera os tokens que somam aquela massa de probabilidade. E a recomendação da própria doc: "geralmente recomendamos alterar este ou top_p, mas não ambos" — porque os dois atuam sobre a mesma distribuição e o efeito conjunto é difícil de prever.

Até aí, é o que todo mundo repete. Agora as duas coisas que quase ninguém fala.

Primeira: temperature=0 não é determinístico. Isso está na doc da Anthropic, com todas as letras: "Mesmo com a temperatura definida como 0, os resultados não serão totalmente determinísticos e entradas idênticas podem produzir saídas diferentes entre chamadas de API."

E dá pra medir. A Thinking Machines Lab publicou em setembro de 2025 um experimento limpo: 1.000 completions do mesmo prompt, no mesmo modelo (Qwen3-235B-A22B-Instruct-2507), com temperatura 0. Resultado: 80 respostas únicas. As mil completions eram idênticas até o token 102 e divergiam no 103 — 992 escreveram "Queens, New York" e 8 escreveram "New York City". A causa raiz não é o modelo ser "criativo": é falta de invariância de batch nos kernels de inferência. O tamanho do lote em que a sua requisição caiu no servidor muda a ordem das reduções em ponto flutuante, e isso muda o resultado.

Você não controla o tamanho do batch. Ninguém que consome API controla.

Segunda: nos modelos de fronteira, esses parâmetros deixaram de existir. Na doc da Anthropic sobre thinking: em Claude Fable 5, Mythos 5, Opus 5, Opus 4.8, Opus 4.7 e Sonnet 5, valores não-default de temperature, top_p ou top_k "retornam erro 400 em toda requisição, independentemente de thinking ser usado ou não". O botão que metade dos tutoriais ensina a girar simplesmente não está mais no painel dos modelos mais capazes.

A consequência de arquitetura: se a corretude do seu sistema depende de temperature=0, você não tem garantia — você tem uma sorte estatisticamente boa que vai falhar em produção num horário de pico, quando o batch do servidor for diferente. Determinismo, quando você precisa dele, se constrói do lado de fora do modelo: schema validado no seu código, retry com verificação, idempotência na escrita, e eval rodando contra um conjunto de casos. Não em um parâmetro de amostragem.

O que isso significa na hora de arquitetar

Junta tudo e o desenho fica óbvio. Cada fundamento vira uma obrigação:

O modelo é assim	Você é obrigado a construir
Prevê um token por vez, sem plano prévio	Restrição de formato no servidor (structured output, schema estrito), nunca só instrução em prosa
Não tem estado entre chamadas	Uma camada de memória explícita: onde o estado mora, quem escreve, quem reidrata
Tem janela finita e degrada muito antes dela	Recuperação com curadoria — pouca coisa e certa — e não "joga tudo que a janela aguenta"
Amostra probabilisticamente, mesmo em temperatura 0	Validação, retry e eval fora do modelo

Repare no padrão: as quatro linhas da direita são código seu. Nenhuma delas vem de graça com a API.

É por isso que "engenheiro de IA" não é uma pessoa que escreve prompts bonitos. É uma pessoa que sabe qual pedaço do problema o modelo resolve e monta a engenharia em volta do pedaço que ele não resolve. O modelo é um componente probabilístico dentro de um sistema que precisa ser determinístico o suficiente pra cliente confiar.

E tem um efeito colateral bom em entender isso: você para de comprar hype. Quando sai um modelo novo com janela maior, você não pergunta "quantos tokens?", pergunta "degrada a partir de quanto?". Quando alguém te vende um agente com "memória infinita", você pergunta onde o estado é persistido. Quando um framework promete saída estruturada, você pergunta se é schema no servidor ou instrução no prompt.

Fundamento não é o assunto chato antes do assunto legal. Fundamento é o que faz você fazer a pergunta certa.

FAQ rápido

Como funciona um LLM, sem entrar em transformer? Em loop. Ele recebe toda a sequência de entrada, calcula uma distribuição de probabilidade sobre o vocabulário inteiro, escolhe um token, cola no fim da sequência e repete o processo do zero. Não existe plano prévio nem rascunho interno guardado entre um token e o próximo.

LLM e IA generativa são a mesma coisa? Não. IA generativa é o guarda-chuva (imagem, áudio, vídeo, texto). LLM é a família de modelos de linguagem treinados em texto para prever o próximo token. Todo LLM é IA generativa; nem toda IA generativa é LLM.

O modelo aprende com o que eu mando na API? Não por padrão. Treino e inferência são processos separados: a sua requisição não altera os pesos do modelo. O que parece "aprendizado" numa conversa é só a informação estar dentro da janela de contexto daquela requisição — e ela some quando você não reenviar. Mudar o comportamento de forma persistente exige fine-tuning ou uma camada de memória sua.

Janela de 1 milhão de tokens significa que posso mandar o repositório inteiro? Pode, e provavelmente não deve. O limite é técnico, não útil: Lost in the Middle e o Context Rot mostram degradação bem antes do teto, em todos os modelos testados. Recuperar os 20 arquivos certos costuma bater mandar os 2.000.

Como eu deixo a saída do modelo previsível, então? Você não deixa o modelo previsível — você torna o sistema tolerante. Structured output com schema estrito para restringir o formato, validação no seu código, retry quando a validação falhar, e um conjunto de evals com casos reais para detectar regressão. Temperatura é o último e mais fraco dos controles, quando existe.

O próximo passo

Um LLM é um estimador de probabilidade do próximo token, sem estado, com um orçamento finito de atenção e uma amostragem que você não controla por completo. Todo o resto — memória, formato, verdade, consistência — é engenharia que sobra pra você.

Esse é o piso. Em cima dele é que fazem sentido as coisas que a gente escreve aqui: recuperação, tool calling, avaliação, custo, roteamento. Se algum termo desses ainda soa nebuloso, o glossário do AI Engineer com 30 termos resolve o vocabulário rápido.

E a provocação pra fechar: em 2026 a discussão sobre modelo virou commodity — todo mundo tem janela grande, todo mundo tem tool calling, os preços caem todo mês. O que continua diferenciando produto de demo é exatamente o que este post inteiro descreveu: o que você constrói em volta do pedaço probabilístico.