Temperature, Top-p e il determinismo che non hai

Il Capitolo 4 ha introdotto il logit come punteggio reale non normalizzato, uno per classe. Il Capitolo 8 ha fatto produrre a un modello linguistico un logit per ogni voce del vocabolario. La softmax trasforma quel vettore $\mathbf{z}$ in probabilità:

La temperature entra qui — il nome è preso dalla fisica statistica, dove lo stesso parametro controlla quanto nettamente una distribuzione di Boltzmann si concentra sui suoi stati a bassa energia¹ — e divide i logits prima dell’esponenziale:

Questa posizione è l’intero meccanismo, e bastano due righe di algebra per vedere perché non potrebbe stare da nessun’altra parte. Supponi di provare ad applicare la temperature alle probabilità invece: scalarle di $1/T$ e rinormalizzare. Otterresti

La costante si cancella. Scalare le probabilità non fa assolutamente nulla; la distribuzione torna invariata. La temperature ha effetto solo perché agisce sull’esponente, dove dividere per $T$ prima di esponenziare equivale a elevare ogni probabilità alla potenza $1/T$: una rimodellazione non lineare che cambia i rapporti tra le voci, non la loro scala comune.

Da quella posizione, entrambi i limiti seguono senza altro lavoro. Quando $T \to 0$, il logit più grande si stacca dal resto e $p$ collassa sul singolo token con il punteggio più alto: greedy decoding. Quando $T$ cresce, ogni $z_i/T$ tende a zero, ogni esponenziale tende a 1 e la distribuzione si appiattisce verso l’uniforme sull’intero vocabolario. Esattamente a $T = 0$ la formula divide per zero, quindi ogni implementazione lo tratta come un caso speciale e usa il massimo aritmetico, incluso il widget qui sotto, che passa ad argmax a $T \le 0.001$.

Un avvertimento, perché la collisione dei nomi genera vera confusione. In machine learning esiste una seconda cosa, non correlata, chiamata temperature: temperature scaling, un metodo di calibrazione che adatta un valore su un validation set in modo che la confidenza di un classificatore corrisponda alla sua accuratezza.² Stessa formula, nulla a che vedere con la generazione. Quando i paper dicono «temperature», spesso intendono quella; questo capitolo mai.

Ecco quella distribuzione, con l’aritmetica davanti a te. I logits sono fissi e plausibili, quindi i numeri nel testo qui sotto possono essere verificati rispetto a ciò che vedi:

Il numero ␣banana è l’intero argomento in miniatura: alzare la temperature non può dare a un modello un’idea che non aveva. I logits sono già calcolati, il ranking è già fissato, e la temperature lo preserva esattamente: nessuna quantità di calore sposta mai un token con punteggio più basso sopra uno con punteggio più alto. Tutto ciò che fa è ridistribuire massa verso il basso nel ranking prodotto dal modello stesso. Una temperature alta non rende un modello più inventivo; lo rende più propenso a emettere i token che ha valutato come cattivi.

Su un vocabolario reale questo smette di essere una curiosità e diventa il motivo per cui l’output ad alta temperature è inutilizzabile. Misurato su Qwen/Qwen2.5-0.5B-Instruct, un forward pass, il prompt sopra, contando quanti token servono per accumulare una certa quota della massa di probabilità:

Leggi lentamente l’ultima riga. A $T = 2$, su una domanda con una sola risposta corretta, 32.966 token diversi condividono il primo 90 % della massa di probabilità. Non è uno spazio creativo più ampio. È un modello a cui l’aritmetica ha detto di trattare una particella coreana e un identificatore C++ come opzioni attive per la parola dopo A:. La spazzatura nel blocco iniziale è la conseguenza diretta, e non è un bug del modello o della libreria: è ciò che la richiesta ha chiesto.

L’intervallo utile è stretto e dipende dal task più che dal gusto. Su una domanda fattuale, la risposta è un token e qualunque calore sopra circa 1,2 inietta errore senza motivo. Su una domanda aperta esiste davvero più di una buona continuazione, e un po’ di calore compra varietà che resta fluida:

"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 il modello ha inventato un nome proprio e una frase che non si analizza correttamente. La fascia tra «identico ogni volta» e «incoerente» è circa da 0,6 a 1,1 per questo modello su questo task, e il consiglio onesto è trovarla misurando sul tuo task, non copiando un numero da un blog post.

Sotto tutto questo si nasconde una domanda ovvia: se il modello ha una distribuzione di probabilità e un token è il più probabile, perché non prenderlo sempre? Il greedy decoding è gratis, riproducibile e non richiede parametri.

Perché il risultato è questo:

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 %

Otto frasi, una sola frase. Quasi nove finestre da quattro token su dieci erano già apparse prima nello stesso output. Questa è neural text degeneration, nominata e spiegata da Holtzman et al. nel paper che ha introdotto top-p.³ Il modello non è rotto; massimizzare la probabilità della sequenza è semplicemente l’obiettivo sbagliato per il testo aperto. La scrittura umana non è la sequenza di parole più probabile: porta sorpresa, con la sua probabilità per-token che vaga, scende e risale, mentre il percorso di massima probabilità è un punto fisso che, una volta entrato, non ha motivo di uscire.

È per questo che il sampling esiste. Ed è anche, e questa è la parte che viene omessa, non una legge universale. Il Capitolo 12 ha misurato 24 corrette su 24 su problemi di parole a due passaggi con semplice greedy decoding, e il sampling a temperature 0,8 ha fatto scendere il risultato all’81 %; la self-consistency ha poi speso sei volte i token per risalire dove il greedy era già arrivato. Entrambi i fatti sono veri nello stesso momento:

La maggior parte dei prompt di produzione è del secondo tipo e viene configurata come il primo, perché la temperature è stata lasciata al valore usato dal codice di esempio.

Campionare dalla distribuzione completa non è ciò che fa davvero qualcuno, perché la coda è enorme e piena di nonsense. Qualcosa deve essere tagliato. Ci sono due risposte classiche e differiscono in un aspetto che decide tutto.

Top-k mantiene un numero fisso di candidati. Ordina per probabilità, mantiene i primi $k$, scarta il resto, rinormalizza.⁴ Top-p, chiamato anche nucleus sampling, mantiene una quantità fissa di massa: prende token in ordine decrescente finché la loro probabilità cumulativa raggiunge $p$, poi si ferma.³ Formalmente, il nucleus è l’insieme più piccolo $V_p$ con

La differenza sembra cosmetica e non lo è, perché i due prompt che invii nello stesso minuto hanno forme di distribuzione completamente diverse. Entrambi questi sono lo stesso modello a temperature 1:

Un unico $k$ fisso, due fallimenti in direzioni opposte. Sul prompt fattuale, $k = 40$ ammette 39 token che insieme valgono il 3,6 %: lascia passare spazzatura, incluso un candidato a nove millesimi di punto percentuale, perché la regola conta slot e non evidenza. Sul prompt narrativo, lo stesso $k = 40$ butta via il 21 % della massa che il modello aveva assegnato davvero, perché il vero nucleus lì è largo 467 token.

Top-p fa fare a un solo numero esattamente entrambi i lavori. Imposta $p = 0.9$ e mantiene 1 token sul primo prompt e 467 sul secondo, perché fa una domanda sulla distribuzione invece di imporle un conteggio. Guarda direttamente questo adattamento: stesso taglio, quattro temperature:

Quel widget chiude anche un fraintendimento che vale la pena nominare, perché costa soldi veri. Su una distribuzione sicura, top_p = 0.9 non è «un po’ di varietà». È greedy. A temperature 1, qui il token principale contiene il 96,90 %, che è già oltre 0,9, quindi il nucleus è largo un token e nient’altro potrà mai essere estratto. I team impostano top_p a 0,9 credendo di aver allentato qualcosa e poi si chiedono perché ogni risposta sia identica.

Imposta invece top-k e il fallimento opposto è altrettanto visibile:

Tre meccanismi diversi circolano con nomi simili, fanno cose diverse, e la differenza è misurabile. Sia $c_i$ il numero di volte in cui il token $i$ è già apparso.

La stessa continuazione degenerata di prima, con ciascuna applicata. «Passi alterati» conta quanti dei 120 passaggi di generazione hanno scelto un token diverso da quello che il modello non penalizzato avrebbe scelto. Qui la run è di 120 passaggi contro i 140 del blocco sopra, motivo per cui la baseline non penalizzata legge 85,5 % invece di 87,6 %:

Ne derivano tre cose. Presence a 0,5 ha cambiato tre decisioni su 120 e tagliato la ripetizione di un quarto: il loop era tenuto insieme da una manciata di token. Frequency a 0,5 ha cambiato quattro volte più decisioni per un effetto molto più grande, perché il moltiplicatore del conteggio continua a crescere mentre la costante di presence no. E la penalty CTRL al valore ampiamente copiato di 1,2 ha riscritto 35 decisioni su 120, che non è una spinta leggera: è un modello diverso.

Quel numero finale prepara il fallimento di cui nessuno avverte.

Il codice si ripete. Le tabelle si ripetono. Le liste si ripetono. L’output strutturato si ripete per definizione: è questo che lo rende struttura. Una penalty non può distinguere tra un modello bloccato in un loop e un modello che emette correttamente la quarta riga di una tabella, perché entrambi appaiono come un token che compare di nuovo.

Gli stessi tre task, generati in tre modi:

La frequency penalty a 0,5 si è rivelata innocua su tutti e tre, un risultato utile e leggermente sorprendente, e dice qualcosa di preciso: poiché nessuna decisione è cambiata, i token strutturali dovevano vincere le loro posizioni di più di quanto la penalty sottraesse, anche dopo essere apparsi cinque e sei volte. La penalty CTRL, che invece divide, li scalza, ed ecco cosa ha prodotto:

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

L’allineamento cade a pezzi: la quantità di padding dentro ogni cella cambia da riga a riga, perché la sequenza di spazi prima della pipe di chiusura è esattamente il tipo di ripetizione che la penalty esiste per rompere. Cosmetico, e costa sei token extra. Il caso Python non è cosmetico:

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,

La penalty ha spinto il modello fuori da total — già usato nella docstring — verso total_sum, ha imbottito l’output con commenti inventati per spendere il budget su token inutilizzati, e poi è entrato in un range a tre argomenti con uno stride. Il commento dice incrementing by 2 each time, che è sbagliato per una somma di quadrati da 1 a $n$. Una repetition penalty ha prodotto codice errato da un prompt a cui senza di essa era stata data una risposta corretta.

La regola che ne segue è breve: le penalties sono per prosa aperta, e dovrebbero essere spente per codice, output strutturato, dati tabellari e qualunque cosa abbia uno schema. Il Capitolo 18 parla esattamente di quella seconda categoria.

Ogni implementazione reale applica questi elementi in una sequenza specifica:

penalties → temperature → top-k → top-p → sample

Non è contabilità arbitraria, e scambiare due fasi produce distribuzioni davvero diverse. Due misure, entrambe sul prompt fattuale.

Tagliare prima o dopo la temperature. Il nucleus viene calcolato sulla distribuzione che riceve, e la temperature cambia radicalmente quella distribuzione:

A $T = 2$ la stessa impostazione nominale produce un insieme di candidati di 32.966 o di 1, solo in base a quale fase gira per prima. Se ti sei mai chiesto perché alzare la temperature «non fa nulla» su un provider e distrugge l’output su un altro con gli stessi due numeri, questa tabella è una risposta plausibile.

Penalizzare prima o dopo la temperature. Sottrarre una penalty $\alpha$ e poi dividere per $T$ dà una penalty effettiva di $\alpha/T$; dividere prima e poi sottrarre dà $\alpha$. Con una presence penalty di 1,0 applicata al token principale:

Identiche a $T = 1$, come devono essere. Separate da un fattore 1,58 a $T = 2$. «Presence penalty 1,0» non è una quantità di penalty ben definita a meno che tu non sappia anche dove viene applicata la temperature, e nessuna API lo documenta.

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)])

Ogni provider accetta un sottoinsieme diverso di questi controlli, con intervalli diversi, e ignora il resto in silenzio. Non è una lamentela astratta. Qualunque applicazione che offra una scelta di modello deve scrivere le differenze da qualche parte, e il file in cui lo fa è una mappa dell’incompatibilità. Ecco che cosa dichiara un catalogo del genere per un singolo parametro sulle nove fonti di testo supportate:

La parola è la stessa; la scala no. Una «temperature di 1» è la distribuzione non modificata su uno e il calore massimo consentito su un altro, e metà del catalogo non può esprimere il valore che l’altra metà tratta come neutro-più-un-po’. Il resto delle manopole è altrettanto disomogeneo: le voci OpenAI, DeepSeek e xAI accettano presence e frequency penalties e nessun topK; le voci Google, Meta, Cerebras e PaLM accettano topK e nessuna penalty; Anthropic accetta topK, topP e stop sequences e nessuna penalty; e esattamente una su nove — Mistral — accetta un seed. Inviare un parametro che un provider non implementa in genere non produce alcun errore: la richiesta riesce, la manopola non fa nulla, e concludi che l’impostazione non ha effetto.

E nota che cosa sia un file del genere: una dichiarazione sull’API di qualcun altro, scritta in un giorno specifico, che poi nulla verifica. Un catalogo che dice da 0 a 1 per un provider che ora accetta da 0 a 2 limiterà silenziosamente ogni richiesta.

Altri due controlli appartengono alla stessa famiglia. logprobs, dove offerto, restituisce le log-probabilities del token scelto e spesso le prime alternative: l’unica finestra che hai sulla distribuzione di cui parla questo capitolo, e la base di ogni euristica di confidenza costruita su un modello chiuso. E maximum tokens più stop sequences terminano la generazione senza alcun riferimento alla probabilità: un limite rigido e una corrispondenza di stringa. Entrambi emergono come finish_reason dal Capitolo 14, dove length significa che la tua risposta è stata tagliata a metà frase da un budget, non conclusa dal modello.

Imposta un seed e il sampling diventa riproducibile. Questa parte è reale, ed è facile da verificare:

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

Byte-identiche dentro uno stesso seed, diverse tra seed, esattamente come pubblicizzato. Quindi ciò che il seed fissa è l’estrazione casuale nell’ultima riga di quella funzione sample: quale token viene scelto data una distribuzione.

Ciò che non fissa è la distribuzione. Ed è lì che sta il problema, perché il vettore di logits prodotto dal tuo modello non è un oggetto matematico: è l’output di miliardi di addizioni floating-point, e quelle hanno un ordine.

Il Capitolo 2 aveva lasciato pronto questo esperimento. Gli stessi milioni di numeri float32, sommati in raggruppamenti diversi:

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

Guarda l’ultima riga. Il numero di chunk cambia la risposta. Non è una curiosità su numpy; è il meccanismo, perché quando un inference server suddivide una riduzione su più o meno unità parallele, sta facendo precisamente questo. E un server suddivide in base a quante richieste sta servendo.

Ecco quell’effetto sul modello stesso. Stesso prompt, stesso forward pass, l’unica differenza è quante altre richieste si trovavano per caso nel 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

Eseguito da solo, il modello è perfettamente deterministico: venti passaggi, identici bit per bit. Metti il prompt identico in un batch con richieste non correlate e il 97 % dei suoi logits cambia. Nulla nella tua richiesta è cambiato. È arrivata la richiesta di qualcun altro.

Ora la parte onesta, perché di solito viene raccontata come se fosse la fine della storia. Una variazione di $2.5 \times 10^{-5}$ altera l’output solo se due token candidati erano entro quella distanza l’uno dall’altro. Su 717 passaggi di generazione in dodici prompt, il gap più piccolo tra i primi due logits è stato $2.5 \times 10^{-3}$ — cento volte più grande della perturbazione — e nessun passaggio era abbastanza vicino da ribaltarsi. Quindi su questo modello, in float32, su un laptop, il batching ha mosso ogni logit e non ha cambiato nessun token.

Questa è una descrizione di condizioni favorevoli, non una rassicurazione, e basta un cambiamento a quelle condizioni:

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

Sei risposte su otto divergono, e una peggiora molto. La tabella del Capitolo 2 dice perché: bfloat16 conserva 7 bit di mantissa, quindi vicino a una magnitudine di logit di 16 i valori rappresentabili sono separati da 0,125: 16,0, poi 16,125, poi 16,25; e l’arrotondamento può spostare un logit fino a 0,0625. Nel frattempo, il 4,7 % dei passaggi di generazione misurati sopra aveva un gap top-two sotto 0,1. Questa è l’intera differenza tra i due esperimenti: in float32 la perturbazione era cento volte più piccola della decisione più vicina, e in bfloat16 è della stessa dimensione. L’inferenza di produzione gira in 16 bit, su hardware con kernel fusi e ordini di riduzione che nessuno promette di mantenere. Che «il rumore numerico sia trascurabile» è una domanda su precisione e hardware, non sul modello.

Quindi, le quattro cause, catalogate come promesso dal Capitolo 9:

Il parametro seed di OpenAI è onesto su questo nell’unico modo possibile: viene fornito insieme a un campo system_fingerprint che identifica la configurazione del backend, e la documentazione afferma che il determinismo è best-effort e che un fingerprint cambiato significa che i risultati possono differire. Leggilo per ciò che è: un provider che ti dice che controlla tutte e quattro le cause sopra, che tu non ne controlli nessuna, e che l’unica cosa che può offrirti è dirti a posteriori che qualcosa si è mosso.

Tutto qui ha riguardato una manopola e le sue conseguenze. Fai un passo indietro e appare il problema più difficile: l’oggetto che abbiamo regolato è una distribuzione di probabilità, e le distribuzioni di probabilità non hanno un’interfaccia.

Una function call ce l’ha. Una riga di database ce l’ha. Un handler POST che si aspetta un body JSON con tre campi obbligatori ce l’ha, e rifiuterà qualunque altra cosa. Tra il modello e ogni altro componente del tuo sistema c’è un contratto su cui una delle due parti non può fare promesse: il modello produrrà qualcosa, estratto da una distribuzione che hai modellato ma non fissato, e il codice dall’altra parte ha bisogno di un valore di tipo noto o va in errore.

Il ponte tra questi due mondi è costruito con il materiale di questo capitolo, non con parsing e retry. Se un token romperebbe la struttura richiesta, non lo campioni sperando bene: imposti il suo logit a $-\infty$ prima ancora che la softmax lo veda. Il constrained decoding è una maschera sullo stesso vettore che abbiamo rimodellato per tutto il capitolo, e trasforma «per favore rispondi in JSON» da richiesta a garanzia.

Il Capitolo 18 è quel contratto: tool calling, JSON Schema, output strutturati, e ciò che serve per rendere un sistema deterministico sicuro da costruire sopra uno probabilistico.

Tutte le misure in questo capitolo arrivano da Qwen/Qwen2.5-0.5B-Instruct su CPU, float32 salvo diversa indicazione, con il sampling implementato come scritto nella sezione facoltativa invece che delegato a una libreria. Sono un modello piccolo, e i valori specifici sono suoi; i meccanismi no. How to generate text with different decoding methods di Von Platen (Hugging Face, 2020) è l’articolo rispetto a cui questo è misurato ed è ancora la migliore introduzione breve allo stesso materiale. Per la sezione sul determinismo: le note di riproducibilità di PyTorch descrivono che cosa un seed fissa e non fissa su una singola macchina, la documentazione OpenAI di seed e system_fingerprint descrive che cosa un provider può e non può promettere, e la discussione del 2025 di Thinking Machines sui kernel batch-invariant è il resoconto pubblico più chiaro del perché risolvere questo problema a livello di inference server sia possibile ma non gratuito.