Temperature, Top-p și determinismul pe care nu îl ai

Capitolul 4 a introdus logit ca scor real nenormalizat, câte unul pentru fiecare clasă. Capitolul 8 a făcut un language model să producă unul pentru fiecare intrare din vocabular. softmax transformă vectorul $\mathbf{z}$ în probabilități:

Temperature intră aici — numele este împrumutat din fizica statistică, unde același parametru controlează cât de puternic se concentrează o distribuție Boltzmann pe stările sale cu energie mică¹ — și împarte logits înainte de exponențială:

Această poziționare este întregul mecanism și merită două rânduri de algebră ca să vezi de ce nu putea fi altundeva. Să presupunem că ai încerca să aplici temperature probabilităților — să le scalezi cu $1/T$ și să renormalizezi. Ai obține

Constanta se anulează. Scalarea probabilităților nu face absolut nimic; distribuția revine neschimbată. Temperature are efect doar pentru că acționează asupra exponentului, unde împărțirea la $T$ înainte de exponentiere este același lucru cu ridicarea fiecărei probabilități la puterea $1/T$ — o remodelare neliniară care schimbă rapoartele dintre intrări, nu scala lor comună.

Din această poziționare, ambele limite urmează fără efort suplimentar. Când $T \to 0$, cel mai mare logit se desprinde de restul, iar $p$ se prăbușește pe singurul token cu scorul cel mai mare: greedy decoding. Când $T$ crește, fiecare $z_i/T$ tinde spre zero, fiecare exponențială tinde spre 1, iar distribuția se aplatizează spre uniformă peste întregul vocabular. Exact la $T = 0$ formula împarte la zero, așa că fiecare implementare îl tratează ca un caz special și folosește maximul aritmetic — inclusiv widgetul de mai jos, care trece la argmax la $T \le 0.001$.

Un avertisment, pentru că suprapunerea de nume creează confuzie reală. Există un al doilea lucru, fără legătură, numit temperature în machine learning: temperature scaling, o metodă de calibrare care potrivește o valoare pe un set de validare astfel încât încrederea unui clasificator să se potrivească cu acuratețea lui.² Aceeași formulă, fără legătură cu generarea. Când lucrările spun „temperature”, adesea se referă la acela; capitolul acesta nu o face niciodată.

Iată distribuția, cu aritmetica în fața ta. logits sunt fixați și plauzibili, deci numerele din textul de mai jos pot fi verificate față de ce vezi:

Numărul ␣banana este tot argumentul în miniatură: creșterea temperature nu poate da unui model o idee pe care nu o avea. logits sunt deja calculați, ordinea este deja fixată, iar temperature o păstrează exact — nicio cantitate de căldură nu mută vreodată un token cu scor mai mic deasupra unuia cu scor mai mare. Tot ce face este să redistribuie masă în josul clasamentului produs chiar de model. Temperature mare nu face un model mai inventiv; îl face mai probabil să emită tokens pe care el însuși le-a cotat drept proaste.

Pe un vocabular real, asta încetează să mai fie o curiozitate și devine motivul pentru care ieșirea la temperature mare este inutilizabilă. Măsurat pe Qwen/Qwen2.5-0.5B-Instruct, un singur forward pass, promptul de mai sus, numărând câți tokens sunt necesari pentru a acumula o anumită parte din masa de probabilitate:

Citește încet ultimul rând. La $T = 2$, pe o întrebare cu exact un răspuns corect, 32.966 de tokens diferite împart primii 90 % din masa de probabilitate. Acesta nu este un spațiu creativ mai larg. Este un model căruia aritmetica i-a spus să trateze o particulă coreeană și un identificator C++ ca opțiuni active pentru cuvântul de după A:. Gunoiul din blocul de început este consecința directă și nu este un bug în model sau în bibliotecă — este ceea ce a cerut requestul.

Intervalul util este îngust și depinde de task, nu de gust. La o întrebare factuală, răspunsul este un singur token, iar orice căldură peste aproximativ 1,2 injectează eroare degeaba. La una deschisă există într-adevăr mai mult de o continuare bună, iar puțină căldură cumpără varietate care rămâne fluentă:

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

La 1,3 modelul a inventat un nume propriu și o propoziție care nu se parsează. Banda dintre „identic de fiecare dată” și „incoerent” este cam 0,6–1,1 pentru acest model pe acest task, iar sfatul onest este să o găsești măsurând pe taskul tău, nu copiind un număr dintr-un articol de blog.

Există o întrebare evidentă ascunsă sub toate acestea: dacă modelul are o distribuție de probabilitate și un token este cel mai probabil, de ce să nu îl alegi mereu? Greedy decoding este gratuit, reproductibil și nu are nevoie de parametri.

Pentru că rezultatul este acesta:

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 %

Opt propoziții, o singură propoziție. Aproape nouă din zece ferestre de patru tokens apăruseră deja mai devreme în aceeași ieșire. Aceasta este neural text degeneration, numită și explicată de Holtzman et al. în lucrarea care a introdus top-p.³ Modelul nu este stricat; maximizarea probabilității secvenței este pur și simplu obiectivul greșit pentru text deschis. Scrisul uman nu este cea mai probabilă secvență de cuvinte — poartă surpriză, probabilitatea sa per-token rătăcește, coboară și își revine — în timp ce traseul de probabilitate maximă este un punct fix care, odată intrat, nu are niciun motiv să iasă.

De aceea există sampling. Este și — iar aceasta este partea care rămâne adesea nespusă — nu o lege universală. Capitolul 12 a măsurat 24 din 24 corecte pe probleme de cuvinte în doi pași cu greedy decoding simplu, iar sampling la temperature 0,8 a coborât rezultatul la 81 %; self-consistency a cheltuit apoi de șase ori mai mulți tokens ca să urce înapoi unde greedy era deja. Ambele lucruri sunt adevărate simultan:

Majoritatea prompts de producție sunt de al doilea fel și sunt configurate ca primul, pentru că temperature a rămas la valoarea folosită de codul de exemplu.

Sampling din distribuția completă nu este ceea ce face cineva în practică, pentru că coada este enormă și plină de nonsens. Ceva trebuie tăiat. Există două răspunsuri clasice și diferă într-un aspect care decide totul.

Top-k păstrează un număr fix de candidați. Sortează după probabilitate, păstrează primii $k$, aruncă restul, renormalizează.⁴ Top-p, numit și nucleus sampling, păstrează o cantitate fixă de masă: ia tokens în ordine descrescătoare până când probabilitatea lor cumulată ajunge la $p$, apoi se oprește.³ Formal, nucleul este cel mai mic set $V_p$ cu

Diferența sună cosmetic, dar nu este, pentru că cele două prompts pe care le trimiți în același minut au forme de distribuție complet diferite. Ambele sunt același model la temperature 1:

Un singur $k$ fix, două eșecuri în direcții opuse. Pe promptul factual, $k = 40$ admite 39 de tokens care împreună valorează 3,6 % — lasă să treacă mizerie, inclusiv un candidat la nouă miimi de procent, pentru că regula numără sloturi, nu dovezi. Pe promptul de poveste, același $k = 40$ aruncă 21 % din masa pe care modelul a atribuit-o cu adevărat, pentru că nucleul real acolo are 467 de tokens lățime.

Top-p face exact același număr să îndeplinească ambele roluri. Setează $p = 0.9$ și păstrează 1 token pe primul prompt și 467 pe al doilea, pentru că pune o întrebare despre distribuție în loc să-i impună un număr. Urmărește direct adaptarea — aceeași tăiere, patru temperature:

Widgetul acesta clarifică și o concepție greșită care merită numită, fiindcă îi costă pe oameni bani reali. Pe o distribuție sigură, top_p = 0.9 nu este „puțină varietate”. Este greedy. La temperature 1, tokenul principal de aici deține 96,90 %, deja peste 0,9, deci nucleul are lățimea de un token și nimic altceva nu poate fi extras. Echipele setează top_p la 0,9 crezând că au relaxat ceva și apoi se întreabă de ce fiecare răspuns este identic.

Setează top-k în schimb, iar eșecul opus este la fel de vizibil:

Trei mecanisme diferite circulă sub nume similare, fac lucruri diferite, iar diferența este măsurabilă. Fie $c_i$ numărul de ori de câte ori token $i$ a apărut deja.

Aceeași continuare degenerată de mai devreme, cu fiecare dintre ele aplicată. „Pași alterați” numără câți dintre cei 120 de pași de generare au ales un token diferit de cel pe care l-ar fi ales modelul nepenalizat. Rularea are aici 120 de pași față de 140 în blocul de mai sus, de aceea baselineul nepenalizat arată 85,5 % în loc de 87,6 %:

Trei lucruri ies la iveală. Presence la 0,5 a schimbat trei decizii din 120 și a redus repetiția cu un sfert — bucla era ținută laolaltă de o mână de tokens. Frequency la 0,5 a schimbat de patru ori mai multe decizii pentru un efect mult mai mare, pentru că multiplicatorul de număr continuă să crească, în timp ce constanta presence nu. Iar CTRL penalty la valoarea de 1,2 copiată peste tot a rescris 35 din 120 de decizii, ceea ce nu este un mic imbold; este un alt model.

Ultimul număr pregătește eșecul despre care nu te avertizează nimeni.

Codul se repetă. Tabelele se repetă. Listele se repetă. Ieșirea structurată se repetă prin definiție — asta este structura. Un penalty nu poate face diferența dintre un model blocat într-o buclă și un model care emite corect al patrulea rând al unui tabel, pentru că ambele arată ca un token care apare din nou.

Aceleași trei taskuri, generate în trei feluri:

Frequency penalty la 0,5 s-a dovedit inofensiv pe toate trei, ceea ce este un rezultat util și ușor surprinzător, și spune ceva precis: fiindcă nicio decizie nu s-a schimbat, tokens structurali trebuie să fi câștigat pozițiile lor cu mai mult decât a scăzut penalty-ul, chiar și după ce au apărut de cinci și șase ori. CTRL penalty, care împarte în schimb, le dislocă, iar iată ce a produs:

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

Alinierea se destramă: cantitatea de spațiere din interiorul fiecărei celule se schimbă de la rând la rând, pentru că șirul de spații înainte de pipe-ul de închidere este exact genul de repetiție pe care penalty-ul există ca să o rupă. Cosmetic, și a costat șase tokens în plus. Cazul Python nu este cosmetic:

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,

Penalty-ul a împins modelul de pe total — deja folosit în docstring — pe total_sum, a umplut ieșirea cu comentarii inventate ca să își cheltuiască bugetul pe tokens nefolosite, apoi a intrat într-un range cu trei argumente și pas. Comentariul spune incrementing by 2 each time, ceea ce este greșit pentru o sumă de pătrate de la 1 la $n$. Un repetition penalty a produs cod incorect dintr-un prompt la care se răspundea corect fără el.

Regula care urmează este scurtă: penalties sunt pentru proză deschisă și ar trebui să fie oprite pentru cod, ieșire structurată, date tabelare și orice are o schemă. Capitolul 18 este exact despre a doua categorie.

Fiecare implementare reală aplică acestea într-o secvență specifică:

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

Nu este contabilitate arbitrară, iar inversarea a două etape produce distribuții cu adevărat diferite. Două măsurători, ambele pe promptul factual.

Tăiere înainte sau după temperature. Nucleul este calculat pe distribuția care îi este dată, iar temperature schimbă radical acea distribuție:

La $T = 2$ aceeași setare nominală produce un set de candidați de 32.966 sau de 1, în funcție pur și simplu de etapa care rulează prima. Dacă te-ai întrebat vreodată de ce ridicarea temperature „nu face nimic” la un provider și distruge ieșirea la altul cu aceleași două numere, tabelul acesta este un răspuns plauzibil.

Penalizare înainte sau după temperature. A scădea un penalty $\alpha$ și apoi a împărți la $T$ dă un penalty efectiv de $\alpha/T$; a împărți mai întâi și apoi a scădea dă $\alpha$. Cu un presence penalty de 1,0 aplicat tokenului principal:

Identice la $T = 1$, așa cum trebuie să fie. La distanță de un factor de 1,58 la $T = 2$. „Presence penalty 1,0” nu este o cantitate bine definită de penalty dacă nu știi și unde se aplică temperature, iar nicio API nu documentează asta.

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

Fiecare provider acceptă un subset diferit al acestor controale, cu intervale diferite, și le ignoră pe restul în tăcere. Aceasta nu este o plângere abstractă. Orice aplicație care oferă alegere de model trebuie să noteze diferențele undeva, iar fișierul unde face asta este o hartă a incompatibilității. Iată ce declară un astfel de catalog pentru un singur parametru în cele nouă surse de text pe care le suportă:

Cuvântul este același; scala nu este. O „temperature de 1” este distribuția nemodificată la unul și căldura maximă permisă la altul, iar jumătate din catalog nu poate exprima valoarea pe care cealaltă jumătate o tratează ca neutră-plus-un-pic. Restul butoanelor sunt la fel de inegale: intrările OpenAI, DeepSeek și xAI acceptă presence și frequency penalties și niciun topK; intrările Google, Meta, Cerebras și PaLM acceptă topK și niciun penalty; Anthropic acceptă topK, topP și stop sequences și niciun penalty; iar exact una din cele nouă — Mistral — acceptă seed. Trimiterea unui parametru pe care un provider nu îl implementează nu produce, de regulă, nicio eroare: requestul reușește, butonul nu face nimic, iar tu concluzionezi că setarea nu are efect.

Și observă ce este un astfel de fișier: o afirmație despre API-ul altcuiva, scrisă într-o anumită zi, pe care nimic nu o verifică ulterior. Un catalog care spune 0–1 pentru un provider care acceptă acum 0–2 va limita în tăcere fiecare request.

Încă două controale aparțin aceleiași familii. logprobs, acolo unde este oferit, returnează log-probabilitățile tokenului ales și adesea primele câteva alternative — singura fereastră pe care o ai către distribuția despre care vorbește acest capitol și baza fiecărei euristici de încredere construită pe un model închis. Iar maximum tokens plus stop sequences încheie generarea fără nicio referire la probabilitate: o limită dură și o potrivire de șir. Ambele apar ca finish_reason din Capitolul 14, unde length înseamnă că răspunsul tău a fost tăiat la mijlocul propoziției de un buget, nu încheiat de model.

Setează un seed și sampling devine reproductibil. Partea aceasta este reală și ușor de verificat:

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

Identic byte cu byte în interiorul aceluiași seed, diferit între seeds, exact cum se promite. Deci ceea ce fixează seedul este extragerea aleatorie din ultima linie a acelei funcții sample — ce token este ales pentru o distribuție dată.

Ceea ce nu fixează este distribuția. Și acolo este problema, pentru că vectorul de logits pe care îl produce modelul tău nu este un obiect matematic; este rezultatul a miliarde de adunări floating-point, iar acestea au o ordine.

Capitolul 2 a lăsat pregătit acest experiment. Aceleași un milion de numere float32, însumate în grupări diferite:

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

Uită-te la ultima linie. Numărul de chunks schimbă răspunsul. Nu este o curiozitate despre numpy; este mecanismul, pentru că atunci când un server de inference împarte o reducere peste mai multe sau mai puține unități paralele, face exact asta. Iar un server împarte în funcție de câte requesturi servește.

Iată efectul asupra modelului însuși. Același prompt, același forward pass, singura diferență fiind câte alte requesturi s-au întâmplat să fie în 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

Rulat singur, modelul este perfect determinist — douăzeci de treceri, identice până la bit. Pune promptul identic într-un batch cu requesturi fără legătură și 97 % din logits se schimbă. Nimic din requestul tău nu s-a schimbat. A sosit requestul altcuiva.

Acum partea onestă, pentru că de obicei asta este povestită ca și cum ar fi sfârșitul discuției. O schimbare de $2.5 \times 10^{-5}$ modifică ieșirea doar dacă doi tokens candidați erau la distanță mai mică decât atât unul de celălalt. Pe 717 pași de generare în douăsprezece prompts, cel mai mic gap dintre primii doi logits a fost $2.5 \times 10^{-3}$ — de o sută de ori mai mare decât perturbația — și niciun pas nu a fost suficient de aproape ca să se inverseze. Deci pe acest model, în float32, pe un laptop, batching a mutat fiecare logit și nu a schimbat niciun token.

Aceasta este o descriere a unor condiții favorabile, nu o reasigurare, iar o singură schimbare a acelor condiții este suficientă:

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

Șase din opt răspunsuri diverg, iar unul dintre ele se degradează grav. Tabelul din Capitolul 2 spune de ce: bfloat16 păstrează 7 biți de mantisă, deci lângă o magnitudine de logit de 16 valorile reprezentabile sunt la 0,125 distanță — 16,0, apoi 16,125, apoi 16,25 — iar rotunjirea poate muta un logit cu până la 0,0625. Între timp, 4,7 % dintre pașii de generare măsurați mai sus au avut un gap top-two sub 0,1. Aceasta este întreaga diferență dintre cele două experimente: în float32 perturbația era de o sută de ori mai mică decât cea mai apropiată decizie, iar în bfloat16 este de aceeași dimensiune. Inference de producție rulează în 16-bit, pe hardware cu kernels fuzionate și ordine de reducere pe care nimeni nu promite să le păstreze. Dacă „zgomotul numeric este neglijabil” este o întrebare despre precizie și hardware, nu despre model.

Așadar, cele patru cauze, catalogate așa cum a promis Capitolul 9:

Parametrul seed de la OpenAI este onest despre asta în singurul fel în care poate fi: vine împreună cu un câmp system_fingerprint care identifică configurația backendului, iar documentația spune că determinismul este best-effort și că un fingerprint schimbat înseamnă că rezultatele pot diferi. Citește asta drept ceea ce este — un provider care îți spune că el controlează toate cele patru cauze de mai sus, că tu nu controlezi niciuna și că singurul lucru pe care îl poate oferi este să îți spună după fapt că ceva s-a mișcat.

Tot ce am discutat aici a fost despre un buton și consecințele lui. Fă un pas înapoi și apare problema mai grea: obiectul pe care l-am ajustat este o distribuție de probabilitate, iar distribuțiile de probabilitate nu au interfață.

Un function call are. Un rând de bază de date are. Un handler POST care așteaptă un corp JSON cu trei câmpuri obligatorii are una și va respinge orice altceva. Între model și fiecare altă componentă din sistemul tău stă un contract despre care una dintre părți nu poate face promisiuni: modelul va produce ceva, extras dintr-o distribuție pe care ai modelat-o, dar nu ai fixat-o, iar codul de cealaltă parte are nevoie de o valoare de un tip cunoscut, altfel aruncă eroare.

Puntea dintre aceste două lumi este construită din materialul acestui capitol, nu din parsing și retry. Dacă un token ar rupe structura cerută, nu îl samplezi și speri — îi setezi logit la $-\infty$ înainte ca softmax să îl vadă. Constrained decoding este o mască peste același vector pe care l-am remodelat tot capitolul, și transformă „te rog răspunde în JSON” dintr-o cerere într-o garanție.

Capitolul 18 este acel contract: tool calling, JSON Schema, structured outputs și ce îți trebuie ca să construiești în siguranță un sistem determinist deasupra unuia probabilistic.

Toate măsurătorile din acest capitol vin din Qwen/Qwen2.5-0.5B-Instruct pe CPU, float32 dacă nu se precizează altfel, cu sampling implementat exact cum este scris în secțiunea opțională, nu delegat unei biblioteci. Este un model mic, iar valorile specifice sunt ale lui; mecanismele nu sunt. How to generate text with different decoding methods de Von Platen (Hugging Face, 2020) este articolul față de care este măsurat acesta și rămâne cea mai bună introducere scurtă la același material. Pentru secțiunea despre determinism: notele PyTorch despre reproductibilitate descriu ce fixează și ce nu fixează un seed pe o singură mașină, documentația OpenAI pentru seed și system_fingerprint descrie ce poate și ce nu poate promite un provider, iar discuția Thinking Machines din 2025 despre batch-invariant kernels este cea mai clară explicație publică despre de ce remedierea acestui lucru la nivelul serverului de inference este posibilă, dar nu gratuită.