15. Large Language Models

Um LLM é o decoder do capítulo 12, escalado até algo surpreendente acontecer: um modelo treinado só para prever o próximo token acabou conseguindo traduzir, escrever código, sustentar uma conversa e — depois de 2024 — sentar e pensar sobre um problema antes de responder.

Este capítulo trata das quatro coisas que transformam essa arquitetura num sistema utilizável, na ordem em que acontecem: pré-treino (o que a previsão do próximo token de fato compra), pós-treino (transformar um continuador de texto num assistente), compute na inferência (o eixo que se juntou à contagem de parâmetros como forma de comprar capacidade) e serviço (especialistas esparsos, decodificação e o cache de KV: por que tudo isso custa o que custa).

Slides

Clique nos slides e use as setas ← → para navegar; F abre em tela cheia e P abre a visão do apresentador, com as notas. Sete dos oito painéis desta página (as fusões do BPE, compute na inferência, MoE, amostragem, o código do próximo token, o cache de KV e a decodificação especulativa) rodam dentro dos slides; o episódio do agente fica só aqui. Abrir os slides numa aba nova

Pré-treino: um objetivo e o que ele obriga o modelo a aprender

Dado um texto \(x_1, \dots, x_T\) de \(T\) tokens, minimize

em que \(p_\theta(x_t \mid x_{<t})\) é a probabilidade que o modelo, com parâmetros \(\theta\), dá ao token que de fato vem depois dos anteriores. É todo o objetivo de pré-treino. Ele é auto-supervisionado — os rótulos são os próprios próximos tokens — de modo que o conjunto de treino é qualquer texto que exista. O log é natural, então a perda sai em nats (\(\log_2\) daria bits; 1 nat ≈ 1,44 bit). Divida \(\mathcal{L}\) por \(T\), tome a exponencial e você tem a perplexidade do capítulo 8.4: uma perda média de 3 nats por token é uma perplexidade de \(e^3 \approx 20\), tão indeciso quanto uma escolha uniforme entre 20 tokens. A perplexidade é por token, então muda com o tokenizador; dividir a perda total, em bits, pelo número de caracteres dá os bits por caractere, que não mudam.

Vale enunciar com cuidado a razão pela qual isso produz mais do que autocompletar: comprimir texto bem exige modelar aquilo que produziu o texto. Para prever o último token de "o assassino era o ___" você precisa da trama. Para prever o token depois de return você precisa do contrato da função. Previsão do próximo token é um objetivo de compressão e compressão nessa escala força estrutura.

Quão grande e com quanto texto

Como a perda cai quando se acrescentam parâmetros \(N\) e tokens \(D\) é o assunto das leis de escala do capítulo 12: o compute de treino é \(C \approx 6ND\), a receita ótima em compute é de cerca de 20 tokens por parâmetro e os modelos implantados são treinados muito além disso, porque cada token que eles servem é pago por \(N\). O SmolLM2-135M, o modelo do laboratório deste capítulo, viu 2 trilhões de tokens¹⁹ — cerca de 15 000 por parâmetro.

O laboratório mede o eixo \(N\) na família Pythia¹⁸, modelos de tamanhos diferentes treinados nos mesmos 300B de tokens na mesma ordem: de 70M a 1B de parâmetros, a perda no WikiText-2 (texto da Wikipédia, que está nos dados de treino de todos eles por igual) cai de 4,09 para 2,82 nats por token, perto de uma reta em eixos log–log (\(L \propto N^{-0{,}10}\), com \(L\) a perda e \(N\) contado sem as tabelas de embedding, como fizeram Kaplan et al.). Cada duplicação de \(N\) compra uma queda absoluta menor que a anterior e esse é todo o formato de uma lei de potência. Ao longo de \(D\) o laboratório acha a outra metade: o modelo de 70M para de melhorar depois de alguns milhares de tokens por parâmetro, porque dados só ajudam até o tamanho do modelo virar o limite.

Tokenização e os bugs que ela causa

O texto vira tokens antes de o modelo ver qualquer coisa, geralmente por BPE em nível de byte¹⁶: comece de bytes, funda repetidamente o par adjacente mais frequente num símbolo novo, pare num vocabulário de 32k–256k. No corpus de brinquedo aaabdaaabac, o par mais frequente aa vira Z (ZabdZabac), depois ab (empatado com Za) vira Y (ZYdZYac), depois ZY vira X (XdXac): de onze símbolos para cinco, com um vocabulário que agora contém X = aaab. É um algoritmo de compressão ajustado a um corpus e não é neutro. Percorra as três fusões passo a passo: a contagem dos pares, a fusão e o que ela faz com o texto e com o vocabulário.

Modelos em nível de byte, sem tokenizador, são uma linha de pesquisa ativa. Até um deles vencer, a área inteira roda sobre uma heurística de compressão trazida para o PLN em 2015 e ela é a primeira suspeita sempre que um modelo falha em algo que parece trivial.

Pós-treino: de continuação a assistente

O pipeline do capítulo 14 é o mesmo, visto do lado do modelo em vez do lado de quem o usa:

1. SFT (supervised fine-tuning, fine-tuning supervisionado) sobre demonstrações — ensina o formato de ser um assistente.
2. Otimização de preferências — ensina qual de duas respostas é melhor, algo que demonstrações não conseguem expressar. O RLHF (aprendizado por reforço com feedback humano³) treina um modelo de recompensa nas comparações feitas por pessoas e depois otimiza o modelo contra ele com PPO (proximal policy optimization); o DPO (direct preference optimization) treina direto nas comparações, sem modelo de recompensa.
3. RL a partir de um verificador — ensina o modelo a acertar, quando "acertar" é checável: aprendizado por reforço com recompensas verificáveis, o RLVR.

O laboratório põe o SmolLM2-135M ao lado da versão instruct dele, com a mesma pergunta. O modelo base continua o texto; o instruct, que vê a pergunta embrulhada num template de chat com tokens especiais em volta de cada turno, responde. O pós-treino também estreita a distribuição: ao longo da própria resposta de cada modelo a cinco perguntas, a distribuição do próximo token tem entropia média (\(H = -\sum p \log_2 p\), em bits) de 3,14 bits no modelo base e 1,21 no instruct.

O passo 3 é o que mudou mais recentemente e merece seção própria.

Compute na inferência: o segundo eixo de escala

Até 2024, "um modelo melhor" queria dizer "um modelo maior, treinado com mais dados". Então apareceu uma curva diferente: mantenha o modelo fixo e dê a ele mais compute na inferência — deixe-o escrever uma cadeia longa de raciocínio, amostrar várias tentativas, checá-las, escolher uma. Medido com os mesmos FLOPs, isso pode vencer um modelo muitas vezes maior em problemas que o pequeno resolve ao menos às vezes⁹.

O painel simula um benchmark: cada problema tem a própria chance de ser resolvido numa tentativa (o controle define a média) e as próprias respostas erradas favoritas.

Três linhas e a distância entre elas é o assunto inteiro:

• pass@k (tracejada), a chance de pelo menos uma de \(k\) tentativas acertar, é o que o modelo poderia atingir se alguma coisa lhe dissesse qual tentativa estava certa: \(1 - (1-p)^k\) num problema que ele resolve com probabilidade \(p\) por tentativa. Sobe rápido e é um limite superior, não uma nota.
• Voto majoritário não precisa de nada extra e satura. Em cada problema, converge para a resposta que o modelo dá com mais frequência — que é errada exatamente quando o modelo está confiantemente errado.
• Best-of-n com verificador embolsa a diferença. Quanto dela embolsa depende da taxa de falso positivo do verificador. Arraste o verificador de perfeito para fraco e veja o teto cair.

O teto tem fórmula. Num problema que o modelo resolve com probabilidade \(p\), um verificador que aceita uma resposta certa com probabilidade \(\text{TPR}\) (a taxa de verdadeiro positivo) e uma errada com probabilidade \(\text{FPR}\) (a taxa de falso positivo) escolhe uma resposta certa, à medida que \(k\) cresce, com probabilidade

Com \(p = 0{,}25\) e o verificador fraco do painel (\(\text{TPR} = 0{,}80\), \(\text{FPR} = 0{,}35\)): \(0{,}20 / (0{,}20 + 0{,}26) \approx 0{,}43\), não importa quantas amostras você tire. Com \(\text{FPR} = 0\), dá 1.

Isso é coerente com onde os modelos de raciocínio ficaram bons primeiro: código (rode os testes) e matemática (cheque a resposta). Os dois têm um verificador barato e quase sem falsos positivos. Qualidade de redação não tem e a melhora ali foi mais modesta.

Como os modelos aprenderam a usar isso

Não se obtém raciocínio longo e útil pedindo com educação e imitar cadeias de raciocínio escritas por humanos limita você ao teto dos humanos. O DeepSeek-R1⁶ mostrou a alternativa: deixe o modelo descobrir. Amostre muitas tentativas de problemas com resposta checável, recompense as que passam e otimize — com GRPO¹², que descarta a rede de valor (a segunda rede que o PPO treina para prever a recompensa esperada) e normaliza as recompensas dentro de cada grupo de \(G\) tentativas do mesmo problema. A tentativa \(i\) recebe a recompensa \(r_i\) (1 se passa na verificação, 0 se não) e a vantagem \(\hat{A}_i\), o quanto os tokens dela são empurrados para cima ou para baixo:

No R1-Zero, treinado assim direto a partir do modelo base, nenhuma cadeia de raciocínio foi fornecida. As cadeias ficaram mais longas sozinhas porque cadeias mais longas passavam na verificação com mais frequência e surgiram comportamentos que ninguém escreveu — voltar atrás, conferir o trabalho, notar um erro no meio da solução. O R1 publicado acrescentou um pequeno conjunto de exemplos resolvidos longos antes da etapa de RL, principalmente para tornar as cadeias legíveis; o raciocínio em si veio do verificador.

Mixture of Experts: mais parâmetros, mesmo custo

O outro jeito de acrescentar capacidade sem acrescentar custo por token é tornar o modelo esparso⁴. Substitua cada MLP por um conjunto de especialistas independentes \(E_1, E_2, \dots\) (cada um, um MLP) e um roteador que ativa apenas \(k\) deles para cada token \(x\):

O roteador é uma matriz, \(W_g\), que dá uma nota a cada especialista; \(g(x)\) transforma as notas em probabilidades, o Top-\(k\) guarda os índices das \(k\) maiores e a saída é a soma das saídas desses especialistas, ponderadas pelas probabilidades.

Lembre do capítulo 12 que cerca de dois terços dos parâmetros de um bloco estão no MLP. Substituí-lo é onde está a alavanca.

Coloque o roteamento em sem balanceamento primeiro. O roteador colapsa sobre alguns especialistas e o resto vira peso morto que você continua pagando para armazenar. Roteamento é um laço de realimentação positiva — um especialista que recebe mais tokens treina mais rápido e por isso é escolhido mais — então o difícil na MoE é o balanceamento, não o roteamento. Soluções clássicas acrescentam uma perda auxiliar; a preferência atual é o balanceamento sem perda auxiliar, que ajusta um viés por especialista no roteador em vez de somar um segundo objetivo para brigar com o primeiro.

Dois movimentos de projeto da geração atual⁵, ambos visíveis no painel:

• Especialistas de granularidade fina — muitos especialistas pequenos em vez de poucos grandes. Com a mesma contagem de parâmetros ativos, top-8-de-256 oferece muito mais combinações que top-2-de-8.
• Um especialista compartilhado, sempre ativo, que absorve o comportamento de uso geral para que os especialistas roteados possam de fato se especializar em vez de cada um reaprender o básico.

Amostragem: o modelo te dá uma distribuição, não um token

Uma passagem direta produz uma distribuição de probabilidade sobre o vocabulário. Transformá-la em texto é um algoritmo separado, com parâmetros próprios, que afeta a qualidade da saída tanto quanto algumas trocas de modelo. As duas distribuições do painel são ilustrações; o laboratório lê distribuições reais do SmolLM2-135M.

A temperatura divide os logits antes do softmax: abaixo de 1 ela afia, acima de 1 ela achata. Ela não acrescenta aleatoriedade — redistribui a que já existe. Puxe para 0,05 e você tem, na prática, decodificação gulosa, que é determinística e propensa a laços, porque a continuação mais provável de uma frase repetida é repeti-la de novo.

O truncamento é a outra metade e é o que impede a cauda longa de absurdo de ser sorteada:

• top-k — mantém os \(k\) mais prováveis. Grosseiro: \(k = 40\) é demais para uma previsão confiante e de menos para uma aberta. No laboratório, o núcleo de 90% depois de "The Eiffel Tower is located in the city of" tem 3 tokens; depois de "My favourite food is", tem 1 550.
• top-p (núcleo)⁷ — mantém o menor conjunto cuja massa alcança \(p\). Adapta-se ao formato da distribuição. O padrão de longa data.
• min-p¹³ — mantém tokens acima de uma fração da probabilidade máxima. Adapta-se ainda melhor e aguenta temperatura alta onde o top-p já começa a admitir lixo.

O laboratório mede o laço numa continuação gulosa de 100 tokens: 42% dos 4-gramas dela são repetições, contra 11% em média nas amostras com temperatura 0,7 e top-p 0,9.

Os mesmos logits servem ao treino e à geração e o painel abaixo roda os dois como o laboratório os escreve: a perda por token e a perplexidade de uma sequência de quatro tokens (2,01 aqui, contra 5 de um chute uniforme no vocabulário de cinco tokens), depois o deformar e um sorteio de multinomial na última linha. A última linha do código conta o que o cache de KV economiza.

Serviço: por que um token custa o que custa

A geração tem duas fases. O prefill lê o prompt inteiro numa passagem direta: todas as posições são calculadas em paralelo e a GPU fica ocupada fazendo aritmética. A decodificação produz então um token por passagem e cada passagem precisa ler da memória todos os pesos do modelo para fazer muito pouca aritmética com eles. Decodificar é limitado pela banda de memória, não pelos FLOPs.

Um número trabalhado: um modelo de 8B em 16 bits tem 16 GB de pesos. Uma GPU que lê 3,35 TB/s (uma H100) precisa de cerca de 5 ms só para percorrê-los uma vez, então uma conversa sozinha não decodifica muito mais rápido que uns 200 tokens por segundo, quaisquer que sejam os FLOPs. Os sistemas de serviço recuperam o desperdício com batching: uma leitura dos pesos serve a todas as requisições do lote.

O que a decodificação não pode fazer é recalcular o passado. As chaves e os valores dos tokens anteriores nunca mudam, então são calculados uma vez e guardados: o cache de KV do capítulo 11. Sem ele, o passo \(t\) reprocessa os \(t\) tokens e gerar \(n\) tokens custa \(O(n^2)\) cálculos de token em vez de \(O(n)\). O laboratório o desliga: para 400 tokens novos a rede processa 403 tokens com o cache e 81 400 sem (202× o trabalho) e numa CPU isso levou 6,7 s contra 43,1 s (6,4×; custos fixos por passo deixam a razão de tempo abaixo da de trabalho). A diferença cresce a cada token a mais. O cache é pago em memória — no SmolLM2-135M, uma chave e um valor em cada uma das 30 camadas, para cada uma das 3 cabeças de chave/valor de 64 números: \(2 \times 30 \times 3 \times 64 = 11\,520\) números por token.

O painel roda seis passos desse laço com o prompt do laboratório, sem e com o cache. Com ele, a primeira linha é o prefill e cada linha seguinte é um passo de decodificação:

Mais dois truques decorrem de a decodificação ser limitada por memória:

• Quantização guarda os pesos em 8 ou 4 bits. Menos bytes para ler por token significa decodificar mais rápido, em geral com uma pequena perda de qualidade.
• Decodificação especulativa¹⁰. Um modelo rascunho pequeno propõe vários tokens e o modelo grande confere todos numa única passagem paralela. Eles são aceitos da esquerda para a direita, cada um com probabilidade \(\min(1, p/q)\), em que \(q\) é a probabilidade que o rascunho deu ao token e \(p\) a que o modelo grande dá; o primeiro token rejeitado é trocado por um sorteado do modelo grande e essa regra mantém a distribuição amostrada exatamente igual à do modelo grande. Como uma passagem custa o mesmo tráfego de memória para conferir um token ou cinco, o artigo original relata decodificação 2–3× mais rápida, com a mesma distribuição de saída.

Uma rodada de decodificação especulativa, passo a passo: o que o rascunho propõe, o que a única passagem do modelo grande devolve e a regra que decide o que fica.

Emergência, com honestidade

A história padrão é que capacidades aparecem abruptamente ao cruzar um limiar de escala² — plano, plano, plano e então competência súbita. É uma afirmação marcante e é, ao menos em parte, um artefato.

Schaeffer et al.⁸ mostraram que muitas curvas "emergentes" vêm de métricas descontínuas. Meça aritmética de vários dígitos por casamento exato e você obtém uma função degrau; meça a log-probabilidade por token que o mesmo modelo dá à resposta certa e obtém uma curva suave. A capacidade subjacente estava melhorando o tempo todo; a medição é que tinha um penhasco.

O que sobrevive à crítica ainda é importante:

• A melhora é suave na perda e frequentemente abrupta no que dá para usar. Um modelo com 40% de casamento exato numa tarefa não é 40% útil; ele pode ser inutilizável e o mesmo modelo a 85% é um produto. Essa descontinuidade é real mesmo que a curva subjacente seja suave.
• Aprendizado em contexto — resolver uma tarefa a partir de exemplos no prompt, sem atualizar pesos¹ — melhora fortemente com a escala e é o que fez do prompting uma disciplina.

A lição prática é sobre avaliação, não sobre metafísica: se sua métrica é um limiar, seu progresso vai parecer um penhasco e você não conseguirá distinguir melhora de ruído até cair dele.

De onde as falhas realmente vêm

De chat para agentes

O padrão de implantação mudou e é a mudança mais relevante para o que vão pedir que você construa. Um chat devolve texto. Um agente roda um laço: leia o objetivo, chame uma ferramenta, leia o resultado, decida, repita, pare.

O painel percorre um episódio concreto: uma pergunta sobre um arquivo de dados que leva três chamadas de ferramenta, uma delas com falha. Observe a janela de contexto: ela só cresce.

Quase nada nesse laço é capacidade do modelo. É engenharia: quais ferramentas existem, o que elas devolvem, como os erros aparecem, quanto histórico é mantido, quando parar. O Model Context Protocol (MCP) padroniza o lado do servidor de ferramentas, de modo que uma ferramenta escrita uma vez funcione em vários clientes.

Duas propriedades do laço merecem ser internalizadas:

• Erros se acumulam. Um passo 95% confiável é 60% confiável depois de dez. Agentes que funcionam são construídos com passos checáveis e reexecutáveis, não com uma única inferência longa.
• A janela de contexto é um orçamento. Cada resultado de ferramenta compete com o objetivo por espaço. Resumir, descartar e rebuscar é o trabalho real de projeto.

O panorama e como lê-lo

Qualquer tabela de modelos específicos está desatualizada antes de ser impressa. O que é estável é o formato do mercado:

As tendências duráveis por trás da rotatividade: os preços caem uma ordem de grandeza ou mais por ano para uma capacidade fixa (entre 9× e 900× por ano conforme a tarefa, numa medição de 2025¹⁵); pesos abertos ficam meses, não anos, atrás da fronteira; raciocínio e multimodalidade estão virando recursos padrão em vez de produtos separados; e a capacidade por parâmetro ativo continua melhorando, de modo que os modelos abertos de ~30B de hoje superam o GPT-4 original na maioria dos benchmarks públicos.

Laboratório: a distribuição, medida

As afirmações desta página sobre tokens, distribuições e decodificação são medidas num notebook no Colab com modelos abertos pequenos, que baixam sem login: o SmolLM2-135M e a versão instruct dele e a família Pythia. Ele roda em CPU; uma GPU T4 (Ambiente de execução → Alterar o tipo de ambiente de execução) só acelera a seção 7. São oito seções, cada uma terminando num checkpoint com valor de verificação:

1. tokenização: strawberry, dígitos e o preço do português em três tokenizadores;
2. a distribuição do próximo token e o que um espaço no final faz com ela;
3. temperatura, top-k e top-p escritos à mão e o laço guloso medido;
4. perplexidade e bits por caractere, em texto normal, embaralhado e em português;
5. o cache de KV: o tamanho pela fórmula e pelos tensores e o ganho de velocidade de guardá-lo;
6. base contra instruct na mesma pergunta e o que o template de chat acrescenta;
7. uma lei de escala medida no Pythia, ao longo de \(N\) e de \(D\);
8. uma tarefa aberta: configurações de decodificação contra repetição e verossimilhança, numa tabela que você preenche.

O lado do fine-tuning (LoRA, SFT nos seus dados) fica com o exercício de LLM da disciplina; este laboratório não treina nada.

Abrir o laboratório no Colab — salve uma cópia no seu Drive (Arquivo → Salvar uma cópia no Drive) para rodar e editar.

Pontos principais

1. Previsão do próximo token é um objetivo de compressão. Comprimir texto bem exige modelar o que o produziu e é por isso que a capacidade generaliza.
2. Tokenização é uma heurística ajustada com consequências reais — falhas em nível de caractere, esquisitices aritméticas e o português custando 1,8× os tokens do inglês num tokenizador centrado no inglês.
3. Um modelo base continua texto. Tudo que é conversacional é pós-treino: SFT, depois otimização de preferências, depois RL a partir de um verificador.
4. Compute na inferência é o segundo eixo de escala. pass@k é um limite superior; convertê-lo em acurácia exige um verificador e a taxa de falso positivo dele define o teto.
5. GRPO com um verificador ensinou modelos a raciocinar sem lhes mostrar raciocínio. Funciona onde verificar é grátis — código e matemática — e reward hacking é o risco permanente.
6. MoE compra capacidade a FLOPs constantes e custa memória. O difícil é o balanceamento de carga, não o roteamento; especialistas de granularidade fina mais um compartilhado é a receita atual.
7. Decodificação é um algoritmo separado. A temperatura reescala logits; top-p e min-p truncam a cauda. A decodificação gulosa entra em laço.
8. Decodificar um token é limitado por memória. O cache de KV transforma \(O(n^2)\) em \(O(n)\) e é pago em memória; batching, quantização e decodificação especulativa (2–3×, mesma distribuição de saída) têm todos o mesmo alvo: os bytes lidos por token.
9. Emergência é em parte um artefato de métrica, mas efeitos de limiar na utilidade são reais. Não deixe uma métrica em degrau esconder progresso suave.
10. Alucinação é treinada por corrigir só por acurácia. Injeção de prompt não tem correção robusta e precisa ser tratada arquiteturalmente.
11. Agentes são laços e erros se acumulam. A maior parte do trabalho é ferramentas, contexto e condições de parada — não o modelo.