Temperatura, top-p e o determinismo que non tes

O capítulo 4 presentou o logit como unha puntuación real non normalizada, unha por clase. O capítulo 8 fixo que un modelo de linguaxe producise unha por cada entrada do vocabulario. A softmax converte ese vector $\mathbf{z}$ en probabilidades:

A temperatura entra aquí —o nome vén da física estatística, onde o mesmo parámetro controla con que nitidez unha distribución de Boltzmann se concentra nos seus estados de baixa enerxía¹— e divide os logits antes da exponencial:

Esa colocación é todo o mecanismo, e paga a pena velo con dúas liñas de álxebra para entender por que non podería estar noutro sitio. Supón que tentases aplicar a temperatura ás probabilidades no seu lugar: escalalas por $1/T$ e renormalizar. Obterías

A constante cancélase. Escalar probabilidades non fai absolutamente nada; a distribución volve sen cambios. A temperatura só ten efecto porque actúa sobre o expoñente, onde dividir por $T$ antes de expoñenciar é o mesmo que elevar cada probabilidade á potencia $1/T$: unha remodelación non lineal que cambia as proporcións entre entradas, non a súa escala común.

A partir desa colocación, os dous límites saen sen máis traballo. Cando $T \to 0$, o maior logit afástase do resto e $p$ colapsa no único token coa puntuación máis alta: greedy decoding. Cando $T$ medra, cada $z_i/T$ tende a cero, cada exponencial tende a 1, e a distribución aplánase cara a unha uniforme sobre todo o vocabulario. Exactamente en $T = 0$ a fórmula divide por cero, así que toda implementación o trata como un caso especial e usa o máximo aritmético, incluído o widget de abaixo, que cambia a argmax en $T \le 0.001$.

Un aviso, porque a colisión de nomes causa confusión real. Hai unha segunda cousa, non relacionada, chamada temperatura en machine learning: temperature scaling, un método de calibración que axusta un valor nun conxunto de validación para que a confianza dun clasificador coincida coa súa exactitude.² Mesma fórmula, nada que ver coa xeración. Cando os papers din «temperature», moitas veces queren dicir iso; este capítulo nunca.

Aquí tes esa distribución, coa aritmética diante. Os logits son fixos e plausibles, así que os números da explicación de abaixo pódense comprobar contra o que ves:

O número de ␣banana é todo o argumento en miniatura: subir a temperatura non pode darlle a un modelo unha idea que non tiña. Os logits xa están calculados, o ranking xa está fixado, e a temperatura consérvao exactamente: ningunha cantidade de calor move un token con menor puntuación por riba doutro con maior puntuación. O único que fai é redistribuír masa cara abaixo no ranking que produciu o propio modelo. Unha temperatura alta non fai un modelo máis inventivo; fai máis probable que emita os tokens que puntuou como malos.

Nun vocabulario real isto deixa de ser unha curiosidade e convértese na razón pola que a saída con temperatura alta é inutilizable. Medido en Qwen/Qwen2.5-0.5B-Instruct, unha forward pass, o prompt anterior, contando cantos tokens fan falta para acumular unha determinada parte da masa de probabilidade:

Le a fila inferior con calma. En $T = 2$, nunha pregunta cunha única resposta correcta, 32.966 tokens diferentes comparten o 90 % superior da masa de probabilidade. Iso non é un espazo creativo máis amplo. Iso é un modelo ao que a aritmética lle dixo que trate unha partícula coreana e un identificador de C++ como opcións vivas para a palabra despois de A:. O lixo do bloque inicial é a consecuencia directa, e non é un bug do modelo nin da biblioteca: é o que pedía a solicitude.

O intervalo útil é estreito e depende da tarefa, non do gusto. Nunha pregunta factual a resposta é un token e calquera calor por riba de arredor de 1,2 inxecta erro a cambio de nada. Nunha aberta si hai máis dunha boa continuación, e algo de calor compra variedade que segue sendo fluída:

"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..."

En 1,3 o modelo inventou un nome propio e unha frase que non se analiza ben. A franxa entre «idéntico cada vez» e «incoherente» é aproximadamente de 0,6 a 1,1 para este modelo nesta tarefa, e o consello honesto é que a atopes medindo na túa tarefa, non copiando un número dun blog post.

Hai unha pregunta obvia agochada baixo todo isto: se o modelo ten unha distribución de probabilidade e un token é o máis probable, por que non collelo sempre? Greedy decoding é gratis, reproducible e non necesita 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, unha frase. Case nove de cada dez ventás de catro tokens xa apareceran antes na mesma saída. Isto é dexeneración de texto neural, nomeada e explicada por Holtzman et al. no paper que introduciu top-p.³ O modelo non está roto; maximizar a probabilidade da secuencia é simplemente o obxectivo equivocado para texto aberto. A escrita humana non é a secuencia de palabras máis probable: leva sorpresa, a súa probabilidade por token deambula, baixa e recupérase, mentres que a ruta de máxima probabilidade é un punto fixo que, unha vez dentro, non ten motivo para saír.

Por iso existe a mostraxe. Tamén, e esta é a parte que adoita quedar fóra, non é unha lei universal. O capítulo 12 mediu 24 de 24 correctas en problemas de palabras de dous pasos con greedy decoding simple, e a mostraxe a temperatura 0,8 baixou iso ao 81 %; self-consistency gastou logo seis veces máis tokens para volver subir ata onde greedy xa estaba. As dúas cousas son certas á vez:

A maioría dos prompts de produción son do segundo tipo e configúranse como os do primeiro, porque a temperatura quedou no que usaba o código de exemplo.

Mostrear desde a distribución completa non é o que fai ninguén na práctica, porque a cola é enorme e está chea de sen sentido. Hai que cortar algo. Hai dúas respostas clásicas e difiren nun aspecto que o decide todo.

Top-k conserva un número fixo de candidatos. Ordena por probabilidade, queda cos primeiros $k$, descarta o resto e renormaliza.⁴ Top-p, tamén chamado nucleus sampling, conserva unha cantidade fixa de masa: toma tokens en orde descendente ata que a súa probabilidade acumulada chega a $p$, e para.³ Formalmente, o núcleo é o conxunto máis pequeno $V_p$ con

A diferenza soa cosmética e non o é, porque os dous prompts que envías no mesmo minuto teñen formas de distribución completamente distintas. Estes dous son o mesmo modelo a temperatura 1:

Un $k$ fixo, dous fallos en direccións opostas. No prompt factual, $k = 40$ admite 39 tokens que entre todos valen 3,6 %: está deixando pasar lixo, incluído un candidato de nove milésimas por cento, porque a regra conta ocos e non evidencia. No prompt de historia, o mesmo $k = 40$ tira fóra o 21 % da masa que o modelo asignou de verdade, porque o núcleo real aí ten 467 tokens de ancho.

Top-p fai que exactamente un número faga os dous traballos. Define $p = 0.9$ e conserva 1 token no primeiro prompt e 467 no segundo, porque está facendo unha pregunta sobre a distribución en vez de imporlle un reconto. Mira esa adaptación directamente: mesmo corte, catro temperaturas:

Ese widget tamén resolve unha idea equivocada que convén nomear, porque lle custa diñeiro real á xente. Nunha distribución confiada, top_p = 0.9 non é «un pouco de variedade». É greedy. A temperatura 1, o token líder aquí contén o 96,90 %, que xa está por riba de 0,9, así que o núcleo ten un só token de ancho e nunca se pode extraer nada máis. Os equipos poñen top_p a 0,9 crendo que afrouxaron algo e logo pregúntanse por que cada resposta é idéntica.

Define top-k no seu lugar e o fallo contrario vese igual de claro:

Tres mecanismos diferentes viaxan baixo nomes parecidos, fan cousas distintas, e a diferenza é medible. Sexa $c_i$ o número de veces que o token $i$ xa apareceu.

A mesma continuación dexenerada de antes, con cada unha aplicada. «Pasos alterados» conta cantos dos 120 pasos de xeración escolleron un token diferente ao que escollería o modelo sen penalización. A execución aquí é de 120 pasos fronte aos 140 do bloque anterior, por iso a liña base sen penalización marca 85,5 % en vez de 87,6 %:

Saen tres cousas. Presence en 0,5 cambiou tres decisións de 120 e reduciu a repetición nun cuarto: o bucle estaba sostido por un pequeno feixe de tokens. Frequency en 0,5 cambiou catro veces máis decisións para un efecto moito maior, porque o multiplicador do reconto segue medrando e a constante de presence non. E a penalización CTRL no valor tan copiado de 1,2 reescribiu 35 de 120 decisións, o que non é un empurrón; é outro modelo.

Ese último número prepara o fallo do que ninguén avisa.

O código repite. As táboas repiten. As listas repiten. A saída estruturada repite por definición: iso é a estrutura. Unha penalización non pode distinguir entre un modelo atrapado nun bucle e un modelo emitindo correctamente a cuarta fila dunha táboa, porque ambas as dúas cousas parecen un token que aparece outra vez.

As mesmas tres tarefas, xeradas de tres maneiras:

A frequency penalty en 0,5 resultou ser inofensiva nas tres, que é un resultado útil e algo sorprendente, e di algo preciso: como non cambiou ningunha decisión, os tokens estruturais debían estar gañando as súas posicións por máis do que restaba a penalización, mesmo despois de aparecer cinco e seis veces. A penalización CTRL, que divide, si os despraza, e isto é o que produciu:

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

A aliñación desfáise: a cantidade de recheo dentro de cada cela cambia de fila a fila, porque a serie de espazos antes do pipe de peche é exactamente o tipo de repetición que a penalización existe para romper. Cosmético, e custou seis tokens extra. O caso de Python non é 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 penalización sacou o modelo de total —xa usado na docstring— e levouno a total_sum, recheou a saída con comentarios inventados para gastar o seu orzamento en tokens non usados, e logo entrou nun range de tres argumentos cun stride. O comentario di incrementing by 2 each time, que é incorrecto para unha suma de cadrados de 1 a $n$. Unha repetition penalty produciu código incorrecto a partir dun prompt que se respondía correctamente sen ela.

A regra que segue é curta: as penalizacións son para prosa aberta, e deben estar desactivadas para código, saída estruturada, datos tabulares e calquera cousa cun esquema. O capítulo 18 trata exactamente desa segunda categoría.

Toda implementación real aplica isto nunha secuencia concreta:

penalizacións → temperatura → top-k → top-p → mostraxe

Non é contabilidade arbitraria, e intercambiar dúas etapas produce distribucións realmente distintas. Dúas medicións, ambas no prompt factual.

Cortar antes ou despois da temperatura. O núcleo calcúlase sobre a distribución que recibe, e a temperatura cambia esa distribución de forma radical:

En $T = 2$, a mesma configuración nominal dá un conxunto de candidatos de 32.966 ou de 1, só dependendo de que etapa se execute primeiro. Se algunha vez te preguntaches por que subir a temperatura «non fai nada» nun provider e destrúe a saída noutro cos mesmos dous números, esta táboa é unha resposta plausible.

Penalizar antes ou despois da temperatura. Restar unha penalización $\alpha$ e logo dividir por $T$ dá unha penalización efectiva de $\alpha/T$; dividir primeiro e logo restar dá $\alpha$. Cunha presence penalty de 1,0 aplicada ao token líder:

Idénticas en $T = 1$, como deben ser. Separadas por un factor de 1,58 en $T = 2$. «Presence penalty 1.0» non é unha cantidade de penalización ben definida salvo que tamén saibas onde se aplica a temperatura, e ningunha 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 provider acepta un subconxunto distinto destes controis, con rangos distintos, e ignora o resto en silencio. Isto non é unha queixa abstracta. Calquera aplicación que ofrece escolla de modelo ten que escribir nalgún sitio as diferenzas, e o ficheiro onde o fai é un mapa da incompatibilidade. Isto é o que un catálogo deste tipo declara para un único parámetro nas nove fontes de texto que admite:

A palabra é a mesma; a escala non. Unha «temperatura de 1» é a distribución sen modificar nun e a calor máxima permitida noutro, e metade do catálogo non pode expresar o valor que a outra metade trata como neutral-máis-un-pouco. O resto dos mandos son igual de desiguais: as entradas de OpenAI, DeepSeek e xAI aceptan presence e frequency penalties e ningún topK; as de Google, Meta, Cerebras e PaLM aceptan topK e ningunha penalización; Anthropic acepta topK, topP e secuencias de parada e ningunha penalización; e exactamente unha das nove —Mistral— acepta unha semente. Enviar un parámetro que un provider non implementa xeralmente non produce erro ningún: a solicitude ten éxito, o mando non fai nada, e ti conclúes que a configuración non ten efecto.

E observa que é un ficheiro así: unha afirmación sobre a API doutra persoa, escrita nun día concreto, que nada verifica despois. Un catálogo que di 0 a 1 para un provider que agora acepta 0 a 2 limitará silenciosamente cada solicitude.

Dous controis máis pertencen á mesma familia. logprobs, cando existe, devolve as log-probabilities do token escollido e a miúdo as poucas alternativas superiores: a única xanela que tes cara á distribución da que trata este capítulo, e a base de toda heurística de confianza construída sobre un modelo pechado. E maximum tokens máis secuencias de parada rematan a xeración sen referencia ningunha á probabilidade: un límite duro e unha coincidencia de cadea. Ambos aparecen como o finish_reason do capítulo 14, onde length significa que a túa resposta foi cortada a media frase por un orzamento, non rematada polo modelo.

Define unha semente e a mostraxe vólvese reproducible. Esa parte é real, e é doada 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énticas byte a byte dentro dunha semente, distintas entre sementes, exactamente como se anuncia. Así que o que fixa a semente é a extracción aleatoria na última liña desa función sample: que token se escolle dada unha distribución.

O que non fixa é a distribución. E aí está o problema, porque o vector de logits que produce o teu modelo non é un obxecto matemático; é a saída de miles de millóns de sumas en coma flotante, e esas sumas teñen unha orde.

O capítulo 2 deixou este experimento preparado. O mesmo millón de números float32, sumados con agrupacións distintas:

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

Mira a última liña. O número de chunks cambia a resposta. Non é unha curiosidade de numpy; é o mecanismo, porque cando un servidor de inferencia divide unha redución entre máis ou menos unidades paralelas está facendo exactamente isto. E un servidor divide segundo cantas solicitudes estea atendendo.

Aquí está ese efecto no propio modelo. O mesmo prompt, a mesma forward pass, coa única diferenza de cantas outras solicitudes cadraron 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

Executado só, o modelo é perfectamente determinista: vinte pasadas, idénticas ata o bit. Pon o prompt idéntico nun batch con solicitudes alleas e cambian o 97 % dos seus logits. Nada da túa solicitude cambiou. Chegou a solicitude doutra persoa.

Agora a parte honesta, porque isto adoita contarse coma se fose o final da historia. Un cambio de $2.5 \times 10^{-5}$ só altera a saída se dous tokens candidatos estaban a esa distancia entre si. En 717 pasos de xeración ao longo de doce prompts, a menor separación entre os dous logits superiores foi $2.5 \times 10^{-3}$ —cen veces maior ca a perturbación— e ningún paso estivo o bastante preto para virar. Así que neste modelo, en float32, nun portátil, o batching moveu todos os logit e non cambiou ningún token.

Iso é unha descrición de condicións favorables, non unha tranquilización, e abonda con cambiar unha desas condicións:

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 diverxen, e unha delas degrádase moito. A táboa do capítulo 2 di por que: bfloat16 conserva 7 bits de mantisa, así que preto dunha magnitude de logit de 16 os valores representables están separados por 0,125: 16,0, logo 16,125, logo 16,25, e o redondeo pode mover un logit ata 0,0625. Mentres tanto, o 4,7 % dos pasos de xeración medidos arriba tiñan unha separación top-two por baixo de 0,1. Esa é toda a diferenza entre os dous experimentos: en float32 a perturbación era cen veces menor ca a decisión máis próxima, e en bfloat16 ten o mesmo tamaño. A inferencia de produción execútase en 16 bits, en hardware con kernels fusionados e ordes de redución que ninguén promete conservar. Que «o ruído numérico é desprezable» é unha pregunta sobre precisión e hardware, non sobre o modelo.

Así que, as catro causas, catalogadas como prometeu o capítulo 9:

O parámetro seed de OpenAI é honesto sobre isto do único xeito que pode: envíase xunto cun campo system_fingerprint que identifica a configuración do backend, e a documentación afirma que o determinismo é best-effort e que unha fingerprint cambiada significa que os resultados poden diferir. Le iso como o que é: un provider dicíndoche que controla as catro causas anteriores, que ti non controlas ningunha, e que o único que pode ofrecer é dicirche despois do feito que algo se moveu.

Todo isto tratou dun mando e das súas consecuencias. Retrocede un nivel e aparece o problema máis difícil: o obxecto que estivemos axustando é unha distribución de probabilidade, e as distribucións de probabilidade non teñen interface.

Unha function call tena. Unha fila de base de datos tena. Un handler POST que espera un corpo JSON con tres campos obrigatorios tena, e rexeitará calquera outra cousa. Entre o modelo e cada outro compoñente do teu sistema hai un contrato sobre o que unha das partes non pode facer promesas: o modelo producirá algo, extraído dunha distribución que moldeaches pero non fixaches, e o código do outro lado necesita un valor dun tipo coñecido ou lanza un erro.

A ponte entre eses dous mundos constrúese co material deste capítulo, non con parsing e reintentos. Se un token rompería a estrutura requirida, non o mostreas e esperas: poñes o seu logit en $-\infty$ antes de que a softmax chegue a velo. Constrained decoding é unha máscara sobre o mesmo vector que pasamos todo este capítulo remodelando, e converte «responde en JSON, por favor» dunha petición nunha garantía.

O capítulo 18 é ese contrato: tool calling, JSON Schema, structured outputs, e o que fai falta para que un sistema determinista sexa seguro de construír enriba dun probabilístico.

Todas as medicións deste capítulo veñen de Qwen/Qwen2.5-0.5B-Instruct en CPU, float32 salvo indicación contraria, coa mostraxe implementada como se escribiu na sección opcional en vez de delegada nunha biblioteca. É un modelo pequeno, e os valores concretos son seus; os mecanismos non. O artigo de Von Platen How to generate text with different decoding methods (Hugging Face, 2020) é o texto contra o que se mide este, e segue sendo a mellor introdución curta ao mesmo material. Para a sección de determinismo: as notas de reproducibilidade de PyTorch describen que fixa e que non fixa unha semente nunha soa máquina, a documentación de OpenAI sobre seed e system_fingerprint describe que pode e non pode prometer un provider, e a discusión de Thinking Machines de 2025 sobre kernels invariantes ao batch é a explicación pública máis clara de por que arranxar isto no nivel do servidor de inferencia é posible pero non gratis.