Temperatura, top-p e o determinismo que não tem

O Capítulo 4 apresentou o logit como uma pontuação real não normalizada, uma por classe. O Capítulo 8 fez um modelo de linguagem produzir uma por entrada do vocabulário. A softmax transforma esse vetor $\mathbf{z}$ em probabilidades:

A temperatura entra aqui — o nome é emprestado da física estatística, onde o mesmo parâmetro controla a nitidez com que uma distribuição de Boltzmann se concentra nos seus estados de baixa energia¹ — e divide os logits antes da exponencial:

Essa posição é todo o mecanismo, e vale duas linhas de álgebra para perceber porque não poderia estar em mais lado nenhum. Suponha que tentava aplicar a temperatura às probabilidades — escalá-las por $1/T$ e renormalizar. Obteria

A constante cancela. Escalar probabilidades não faz absolutamente nada; a distribuição volta inalterada. A temperatura só tem efeito porque atua sobre o expoente, onde dividir por $T$ antes de exponenciar é o mesmo que elevar cada probabilidade à potência $1/T$ — uma remodelação não linear que altera os rácios entre entradas, não a sua escala comum.

Dessa posição, ambos os limites seguem sem mais trabalho. Quando $T \to 0$, o maior logit afasta-se do resto e $p$ colapsa no único token com maior pontuação: greedy decoding. Quando $T$ cresce, cada $z_i/T$ tende para zero, cada exponencial tende para 1, e a distribuição achata-se em direção a uma uniforme sobre todo o vocabulário. Exatamente em $T = 0$, a fórmula divide por zero, por isso todas as implementações tratam esse caso à parte como o máximo aritmético — incluindo o widget abaixo, que muda para argmax em $T \le 0.001$.

Um aviso, porque a colisão de nomes causa confusão real. Há uma segunda coisa, não relacionada, chamada temperatura em machine learning: temperature scaling, um método de calibração que ajusta um valor num conjunto de validação para que a confiança de um classificador corresponda à sua precisão.² Mesma fórmula, nada a ver com geração. Artigos que dizem «temperatura» muitas vezes querem dizer essa; este capítulo nunca quer.

Eis essa distribuição, com a aritmética à sua frente. Os logits são fixos e plausíveis, por isso os números no texto abaixo podem ser verificados contra o que vê:

O número ␣banana é todo o argumento em miniatura: aumentar a temperatura não consegue dar a um modelo uma ideia que ele não teve. Os logits já estão calculados, a ordenação já está fixa, e a temperatura preserva-a exatamente — nenhum calor faz alguma vez um token com pontuação inferior passar acima de outro com pontuação superior. Tudo o que faz é redistribuir massa para baixo na ordenação que o próprio modelo produziu. Alta temperatura não torna um modelo mais inventivo; torna-o mais propenso a emitir os tokens que pontuou como maus.

Num vocabulário real, isto deixa de ser uma curiosidade e torna-se a razão pela qual output de alta temperatura é inutilizável. Medido em Qwen/Qwen2.5-0.5B-Instruct, uma forward pass, o prompt acima, contando quantos tokens são necessários para acumular uma dada fração da massa de probabilidade:

Leia a última linha devagar. Em $T = 2$, numa pergunta com exatamente uma resposta correta, 32.966 tokens diferentes partilham os 90 % superiores da massa de probabilidade. Isto não é um espaço criativo mais amplo. É um modelo a que a aritmética disse para tratar uma partícula coreana e um identificador C++ como opções vivas para a palavra depois de A:. O lixo no bloco de abertura é a consequência direta, e não é um bug no modelo nem na biblioteca — é o que o pedido pediu.

O intervalo útil é estreito e depende da tarefa, não do gosto. Numa pergunta factual, a resposta é um token e qualquer calor acima de cerca de 1,2 injeta erro sem benefício. Numa pergunta em aberto, há de facto mais do que uma boa continuação, e algum calor compra variedade que continua fluente:

"Write a two-sentence story about a lighthouse."

T = 0.0  "The lighthouse stood tall and proud, its beacon illuminating the
          night sky above. A lone sailor, his eyes fixed on the distant
          horizon..."

T = 0.7  "In the quiet, stormy waters of the sea, a lighthouse stood
          sentinel over the horizon, its golden dome casting a warm glow
          on the fog-shrouded streets below..."

T = 1.0  "In the quiet night, a lone lighthouse stood sentinel over the
          sea, its shining beacon a beacon of hope and solace for sailors
          and fishermen across the vast and endless ocean..."

T = 1.3  "In the gentle sunlight, now reflecting upon the opening of Jack's
          lighthouse, Jim Trahan, a small-time individual difficult to
          define in paperwork, wondered about a career where simplicity
          reigns..."

A 1,3, o modelo inventou um nome próprio e uma frase que não se analisa sintaticamente. A faixa entre «idêntico sempre» e «incoerente» fica aproximadamente entre 0,6 e 1,1 para este modelo nesta tarefa, e o conselho honesto é encontrá-la medindo na sua tarefa, não copiando um número de um artigo de blog.

Há uma pergunta óbvia escondida sob tudo isto: se o modelo tem uma distribuição de probabilidades e um token é o mais provável, porque não escolhê-lo sempre? Greedy decoding é grátis, reprodutível e não precisa de parâmetros.

Porque o resultado é isto:

prompt: "In a shocking finding, scientists discovered a herd of unicorns
         living in a remote valley."

greedy: " The unicorns were so rare that they were not even recognized by
         the local people. The unicorns were so rare that they were not
         even recognized by the local people. The unicorns were so rare
         that they were not even recognized by the local people. ..."

         repeated 4-grams: 87.6 %

Oito frases, uma frase. Quase nove em cada dez janelas de quatro tokens já tinham aparecido antes no mesmo output. Isto é degeneração de texto neural, nomeada e explicada por Holtzman et al. no artigo que introduziu top-p.³ O modelo não está estragado; maximizar a probabilidade da sequência é simplesmente o objetivo errado para texto em aberto. A escrita humana não é a sequência de palavras mais provável — carrega surpresa, com a sua probabilidade por token a vaguear, descer e recuperar — enquanto o caminho de probabilidade máxima é um ponto fixo que, uma vez alcançado, não tem razão para sair.

É por isso que a amostragem existe. É também, e esta é a parte que fica de fora, não uma lei universal. O Capítulo 12 mediu 24 de 24 respostas corretas em problemas de palavras de dois passos com greedy decoding simples, e a amostragem a temperatura 0,8 fez isso descer para 81 %; a self-consistency depois gastou seis vezes os tokens para regressar ao ponto onde o greedy já estava. Ambas as coisas são verdade ao mesmo tempo:

A maioria dos prompts de produção são do segundo tipo e são configurados como o primeiro, porque a temperatura ficou no valor que o código de exemplo usava.

Amostrar a partir da distribuição completa não é o que alguém faz realmente, porque a cauda é enorme e cheia de disparates. Alguma coisa tem de ser cortada. Há duas respostas clássicas e diferem num aspeto que decide tudo.

Top-k mantém um número fixo de candidatos. Ordene por probabilidade, mantenha os primeiros $k$, descarte o resto, renormalize.⁴ Top-p, também chamado nucleus sampling, mantém uma quantidade fixa de massa: pegue em tokens por ordem descendente até a sua probabilidade cumulativa atingir $p$, e pare.³ Formalmente, o núcleo é o menor conjunto $V_p$ com

A diferença parece cosmética e não é, porque os dois prompts que envia no mesmo minuto têm formas de distribuição completamente diferentes. Ambos são o mesmo modelo à temperatura 1:

Um $k$ fixo, duas falhas em direções opostas. No prompt factual, $k = 40$ admite 39 tokens que, juntos, valem 3,6 % — deixa passar lixo, incluindo um candidato a nove milésimos de um por cento, porque a regra conta lugares e não evidência. No prompt de história, o mesmo $k = 40$ deita fora 21 % da massa que o modelo atribuiu genuinamente, porque o núcleo real ali tem 467 tokens de largura.

Top-p faz um único número cumprir ambas as funções. Defina $p = 0.9$ e ele mantém 1 token no primeiro prompt e 467 no segundo, porque faz uma pergunta sobre a distribuição em vez de lhe impor uma contagem. Veja essa adaptação diretamente — mesmo corte, quatro temperaturas:

Esse widget também resolve uma ideia errada que vale a pena nomear, porque custa dinheiro real. Numa distribuição confiante, top_p = 0.9 não é «um pouco de variedade». É greedy. À temperatura 1, o token líder aqui detém 96,90 %, que já está acima de 0,9, por isso o núcleo tem um token de largura e nada mais pode alguma vez ser extraído. Equipas definem top_p como 0,9 acreditando que afrouxaram alguma coisa e depois perguntam-se porque todas as respostas são idênticas.

Defina top-k em vez disso e a falha oposta é igualmente visível:

Três mecanismos diferentes circulam com nomes semelhantes, fazem coisas diferentes, e a diferença é mensurável. Seja $c_i$ o número de vezes que o token $i$ já apareceu.

A mesma continuação degenerada de antes, com cada uma aplicada. «Passos alterados» conta quantos dos 120 passos de geração escolheram um token diferente daquele que o modelo sem penalização teria escolhido. A execução tem aqui 120 passos contra 140 no bloco acima, razão pela qual a baseline sem penalização lê 85,5 % em vez de 87,6 %:

Três coisas emergem. Presence a 0,5 mudou três decisões em 120 e cortou a repetição em um quarto — o loop era mantido por um punhado de tokens. Frequency a 0,5 mudou quatro vezes mais decisões para um efeito muito maior, porque o multiplicador da contagem continua a crescer enquanto a constante de presence não cresce. E a penalização CTRL no valor muito copiado de 1,2 reescreveu 35 de 120 decisões, o que não é um empurrão; é um modelo diferente.

Esse último número prepara a falha de que ninguém avisa.

Código repete. Tabelas repetem. Listas repetem. Output estruturado repete por definição — é isso que é estrutura. Uma penalização não consegue distinguir um modelo preso num loop de um modelo que emite corretamente a quarta linha de uma tabela, porque ambos parecem um token a aparecer outra vez.

As mesmas três tarefas, geradas de três formas:

A frequency penalty a 0,5 acabou por ser inofensiva nas três, o que é um resultado útil e ligeiramente surpreendente, e diz algo preciso: como nenhuma decisão mudou, os tokens estruturais devem ter ganho as suas posições por mais do que a penalização subtraiu, mesmo depois de aparecerem cinco e seis vezes. A penalização CTRL, que divide, desloca-os, e eis o que produziu:

repetition 1.2, markdown table:
  | n | 2^n |
  | --- | --- |
  | 0 | 1      |
  | 1 | 2       |
  | 2 | 4       |

O alinhamento desfaz-se: a quantidade de preenchimento dentro de cada célula muda de linha para linha, porque a sequência de espaços antes da barra vertical de fecho é exatamente o tipo de repetição que a penalização existe para quebrar. Cosmético, e custou seis tokens extra. O caso Python não é cosmético:

nothing / frequency 0.5:
      total = 0
      for i in range(1, n + 1):
          total += i ** 2
      return total

repetition 1.2:
      # Initialize total_sum with 0
      total_sum = 0
      # Loop through numbers from 1 to n, incrementing by 2 each time
      for i in range(1, n + 1,

A penalização empurrou o modelo para fora de total — já usado na docstring — para total_sum, preencheu o output com comentários inventados para gastar o seu orçamento em tokens não usados, e depois entrou num range de três argumentos com um passo. O comentário diz incrementing by 2 each time, o que é errado para uma soma de quadrados de 1 a $n$. Uma repetition penalty produziu código incorreto a partir de um prompt que foi respondido corretamente sem ela.

A regra que se segue é curta: as penalizações são para prosa em aberto, e devem estar desligadas para código, output estruturado, dados tabulares e tudo o que tenha um schema. O Capítulo 18 trata exatamente dessa segunda categoria.

Todas as implementações reais aplicam isto numa sequência específica:

penalizações → temperatura → top-k → top-p → amostrar

Isto não é contabilidade arbitrária, e trocar duas etapas produz distribuições genuinamente diferentes. Duas medições, ambas no prompt factual.

Cortar antes ou depois da temperatura. O núcleo é calculado sobre a distribuição que lhe é entregue, e a temperatura altera radicalmente essa distribuição:

Em $T = 2$, a mesma configuração nominal produz um conjunto candidato de 32.966 ou de 1, dependendo apenas de que etapa corre primeiro. Se alguma vez se perguntou porque aumentar a temperatura «não faz nada» num fornecedor e destrói o output noutro com os mesmos dois números, esta tabela é uma resposta plausível.

Penalizar antes ou depois da temperatura. Subtrair uma penalização $\alpha$ e depois dividir por $T$ dá uma penalização efetiva de $\alpha/T$; dividir primeiro e depois subtrair dá $\alpha$. Com uma presence penalty de 1,0 aplicada ao token líder:

Idênticas em $T = 1$, como têm de ser. Separadas por um fator de 1,58 em $T = 2$. «Presence penalty 1.0» não é uma quantidade de penalização bem definida a menos que também saiba onde a temperatura é aplicada, e nenhuma API documenta isto.

def sample(logits, counts, presence=0.0, frequency=0.0,
           temperature=1.0, top_k=0, top_p=1.0, generator=None):
    z = logits.clone()

    idx = torch.tensor(list(counts))                       # 1. penalties
    if len(idx):
        z[idx] -= presence
        z[idx] -= frequency * torch.tensor([float(c) for c in counts.values()])

    if temperature <= 0:                                   # 2. temperature
        return int(z.argmax())                             #    T=0 is argmax
    p = torch.softmax(z / temperature, -1)

    p, order = p.sort(descending=True)
    if top_k:                                              # 3. top-k
        p[top_k:] = 0
    p = p * ((p.cumsum(0) - p) < top_p)                     # 4. top-p

    p = p / p.sum()                                        # 5. renormalise
    return int(order[torch.multinomial(p, 1, generator=generator)])

Cada fornecedor aceita um subconjunto diferente destes controlos, com intervalos diferentes, e ignora o resto em silêncio. Isto não é uma queixa abstrata. Qualquer aplicação que ofereça uma escolha de modelo tem de escrever as diferenças algures, e o ficheiro onde o faz é um mapa da incompatibilidade. Eis o que um desses catálogos declara para um único parâmetro nas nove fontes de texto que suporta:

A palavra é a mesma; a escala não é. Uma «temperatura de 1» é a distribuição não modificada num caso e o calor máximo permitido noutro, e metade do catálogo não consegue expressar o valor que a outra metade trata como neutro-mais-um-pouco. O resto dos controlos é igualmente desigual: as entradas OpenAI, DeepSeek e xAI aceitam presence e frequency penalties e nenhum topK; as entradas Google, Meta, Cerebras e PaLM aceitam topK e nenhuma penalização; a Anthropic aceita topK, topP e sequências de paragem e nenhuma penalização; e exatamente uma das nove — Mistral — aceita uma seed. Enviar um parâmetro que um fornecedor não implementa geralmente não produz erro nenhum: o pedido tem sucesso, o botão não faz nada, e conclui que a configuração não tem efeito.

E repare no que tal ficheiro é: uma alegação sobre a API de outra pessoa, escrita num dia específico, que nada verifica depois. Um catálogo que diz 0 a 1 para um fornecedor que agora aceita 0 a 2 limitará silenciosamente todos os pedidos.

Mais dois controlos pertencem à mesma família. logprobs, quando disponibilizado, devolve as log-probabilidades do token escolhido e muitas vezes as principais alternativas — a única janela que obtém para a distribuição de que este capítulo trata, e a base de todas as heurísticas de confiança construídas sobre um modelo fechado. E máximo de tokens mais sequências de paragem terminam a geração sem referência nenhuma à probabilidade: um limite rígido e uma correspondência de string. Ambos aparecem como o finish_reason do Capítulo 14, onde length significa que a sua resposta foi cortada a meio de uma frase por um orçamento, não terminada pelo modelo.

Defina uma seed e a amostragem torna-se reprodutível. Essa parte é real, e é fácil de verificar:

seed = 1234  " Paris\nWhat is a good geographical qualifier for describing
               Paris concerning its location?\nA: Near the Mediterranean Sea"
seed = 1234  " Paris\nWhat is a good geographical qualifier for describing
               Paris concerning its location?\nA: Near the Mediterranean Sea"
seed = 7     " Paris is the capital of France. The appellation of Paris is
               \"Île de Paris\"."
seed = 7     " Paris is the capital of France. The appellation of Paris is
               \"Île de Paris\"."

Idêntico byte a byte dentro de uma seed, diferente entre seeds, exatamente como anunciado. Portanto, o que a seed fixa é o sorteio aleatório na última linha dessa função sample — que token é escolhido dada uma distribuição.

O que ela não fixa é a distribuição. E é aí que está o problema, porque o vetor de logits que o seu modelo produz não é um objeto matemático; é o output de milhares de milhões de somas de vírgula flutuante, e essas têm uma ordem.

O Capítulo 2 deixou esta experiência pronta. O mesmo milhão de números float32, somados em agrupamentos diferentes:

sequential          998.564270020    error vs float64: 6.393e-03
pairwise (numpy)    998.570556641    error vs float64: 1.061e-04
in 4 chunks         998.570495605    error vs float64: 1.672e-04
in 8 chunks         998.570556641    error vs float64: 1.061e-04
in 16 chunks        998.570678711    error vs float64: 1.594e-05

sequential == pairwise?  False
4 chunks == 8 chunks?    False

Olhe para a última linha. O número de chunks muda a resposta. Isto não é uma curiosidade sobre numpy; é o mecanismo, porque quando um servidor de inferência divide uma redução por mais ou menos unidades paralelas, está a fazer precisamente isto. E um servidor divide de acordo com quantos pedidos está a servir.

Eis esse efeito no próprio modelo. O mesmo prompt, a mesma forward pass, sendo a única diferença quantos outros pedidos por acaso estavam no batch:

20 identical forward passes, batch of 1:  20 / 20 bit-for-bit identical

the same prompt inside a batch of  2:  147,321 of 151,936 logits differ
the same prompt inside a batch of  4:  146,515 of 151,936 logits differ
the same prompt inside a batch of  8:  146,515 of 151,936 logits differ
the same prompt inside a batch of 16:  147,321 of 151,936 logits differ

largest change to any logit: 2.5e-05

A correr sozinho, o modelo é perfeitamente determinístico — vinte passagens, idênticas bit a bit. Coloque o prompt idêntico num batch com pedidos não relacionados e 97 % dos seus logits mudam. Nada no seu pedido mudou. Chegou o pedido de outra pessoa.

Agora a parte honesta, porque isto costuma ser contado como se fosse o fim da história. Uma alteração de $2.5 \times 10^{-5}$ só altera o output se dois tokens candidatos estiverem a essa distância um do outro. Ao longo de 717 passos de geração em doze prompts, o menor intervalo entre os dois logits superiores foi $2.5 \times 10^{-3}$ — cem vezes maior do que a perturbação — e nenhum passo esteve perto o suficiente para virar. Portanto, neste modelo, em float32, num portátil, o batching moveu todos os logits e não mudou nenhum token.

Isto é uma descrição de condições favoráveis, não uma garantia, e uma alteração a essas condições basta:

same weights, same prompts, greedy decoding, no seed involved
float32 vs bfloat16:   6 of 8 answers diverge
                       first divergence at step 23, on average

  float32: "...it is scattered and dispersed into different colors,
            including blue. The blue light is scattered more than other
            colors, so it appears to come from the sky."

  bfloat16: "...it is scattered and scattered, causing the colors of the
             sun to be scattered and scattered, creating the appearance
             of a blue color."

Seis de oito respostas divergem, e uma degrada-se bastante. A tabela do Capítulo 2 diz porquê: bfloat16 mantém 7 bits de mantissa, por isso, perto de uma magnitude de logit de 16, os valores representáveis estão separados por 0,125 — 16,0, depois 16,125, depois 16,25 — e o arredondamento pode mover um logit até 0,0625. Entretanto, 4,7 % dos passos de geração medidos acima tinham um intervalo top-two inferior a 0,1. Essa é toda a diferença entre as duas experiências: em float32 a perturbação era cem vezes menor do que a decisão mais próxima, e em bfloat16 tem o mesmo tamanho. A inferência de produção corre em 16 bits, em hardware com kernels fundidos e ordens de redução que ninguém promete manter. Se «o ruído numérico é negligenciável» é uma pergunta sobre precisão e hardware, não sobre o modelo.

Portanto, as quatro causas, catalogadas como o Capítulo 9 prometeu:

O parâmetro seed da OpenAI é honesto sobre isto da única forma que pode ser: vem acompanhado de um campo system_fingerprint que identifica a configuração de backend, e a documentação afirma que o determinismo é best-effort e que uma fingerprint alterada significa que os resultados podem diferir. Leia isso pelo que é — um fornecedor a dizer-lhe que controla todas as quatro causas acima, que o utilizador não controla nenhuma, e que a única coisa que pode oferecer é dizer-lhe depois do facto que algo mudou.

Tudo aqui foi sobre um botão e as suas consequências. Recuando um nível, aparece o problema mais difícil: o objeto que estivemos a afinar é uma distribuição de probabilidades, e distribuições de probabilidades não têm interface.

Uma function call tem. Uma linha de base de dados tem. Um handler POST que espera um corpo JSON com três campos obrigatórios tem, e rejeitará tudo o resto. Entre o modelo e todos os outros componentes do seu sistema há um contrato sobre o qual um dos lados não consegue fazer promessas: o modelo produzirá algo, extraído de uma distribuição que moldou mas não fixou, e o código do outro lado precisa de um valor de tipo conhecido ou lança erro.

A ponte entre esses dois mundos é construída com o material deste capítulo, não com parsing e retentativas. Se um token quebraria a estrutura necessária, não o amostra e espera — define o seu logit como $-\infty$ antes de a softmax sequer o ver. Constrained decoding é uma máscara sobre o mesmo vetor que passámos este capítulo a remodelar, e transforma «responda em JSON, por favor» de um pedido numa garantia.

O Capítulo 18 é esse contrato: tool calling, JSON Schema, outputs estruturados, e o que é preciso para tornar um sistema determinístico seguro para construir sobre um sistema probabilístico.

Todas as medições neste capítulo vêm de Qwen/Qwen2.5-0.5B-Instruct em CPU, float32 salvo indicação em contrário, com a amostragem implementada como escrito na secção opcional, em vez de delegada a uma biblioteca. São de um modelo pequeno, e os valores específicos são dele; os mecanismos não são. How to generate text with different decoding methods, de Von Platen (Hugging Face, 2020), é o artigo contra o qual este é medido e continua a ser a melhor introdução curta ao mesmo material. Para a secção sobre determinismo: as notas de reprodutibilidade do PyTorch descrevem o que uma seed fixa e não fixa numa única máquina, a documentação da OpenAI sobre seed e system_fingerprint descreve o que um fornecedor pode e não pode prometer, e a discussão de 2025 da Thinking Machines sobre kernels invariantes ao batch é o relato público mais claro de porque corrigir isto ao nível do servidor de inferência é possível, mas não é gratuito.