Temperatur, top-p og den determinisme, du ikke har

Kapitel 4 introducerede logit som en unormaliseret reel score, én pr. klasse. Kapitel 8 fik en sprogmodel til at producere én pr. element i ordforrådet. softmax gør den vektor $\mathbf{z}$ til sandsynligheder:

Temperatur kommer ind her — navnet er lånt fra statistisk fysik, hvor den samme parameter styrer, hvor skarpt en Boltzmann-fordeling koncentrerer sig om sine lavenergitilstande¹ — og den dividerer logits før eksponentialfunktionen:

Den placering er hele mekanismen, og det er to linjers algebra værd at se, hvorfor den ikke kunne være noget andet sted. Antag, at du i stedet prøvede at anvende temperatur på sandsynlighederne — skalere dem med $1/T$ og renormalisere. Du ville få

Konstanten går ud. At skalere sandsynligheder gør slet ingenting; fordelingen kommer tilbage uændret. Temperatur har kun en effekt, fordi den virker på eksponenten, hvor det at dividere med $T$ før eksponentiering er det samme som at opløfte hver sandsynlighed til potensen $1/T$ — en ikke-lineær omformning, der ændrer forholdene mellem elementer i stedet for deres fælles skala.

Fra den placering følger begge grænser uden mere arbejde. Når $T \to 0$, løber den største logit fra resten, og $p$ kollapser ned på den ene token med højest score: greedy decoding. Når $T$ vokser, går hver $z_i/T$ mod nul, hver eksponentialværdi går mod 1, og fordelingen flader ud mod uniform over hele ordforrådet. Præcis ved $T = 0$ dividerer formlen med nul, så hver implementation specialbehandler det til det aritmetiske maksimum — inklusive widgetten nedenfor, som skifter til argmax ved $T \le 0.001$.

Én advarsel, fordi navnesammenfaldet skaber reel forvirring. Der er en anden, urelateret ting i machine learning, der hedder temperatur: temperature scaling, en kalibreringsmetode, der fitter én værdi på et valideringssæt, så en klassifikators selvtillid matcher dens nøjagtighed.² Samme formel, intet at gøre med generering. Artikler, der siger "temperatur", mener ofte den; det gør dette kapitel aldrig.

Her er den fordeling, med aritmetikken foran dig. Logits er faste og plausible, så tallene i teksten nedenfor kan tjekkes mod det, du ser:

Tallet ␣banana er hele argumentet i miniature: at hæve temperaturen kan ikke give en model en idé, den ikke havde. Logits er allerede beregnet, rangordningen er allerede fast, og temperatur bevarer den præcist — ingen mængde varme flytter nogensinde en lavere scoret token over en højere scoret token. Det eneste, den gør, er at omfordele masse ned gennem den rangordning, modellen selv producerede. Høj temperatur gør ikke en model mere opfindsom; den gør det mere sandsynligt, at den udsender de tokens, den scorede som dårlige.

På et rigtigt ordforråd holder dette op med at være en kuriositet og bliver grunden til, at output ved høj temperatur er ubrugeligt. Målt på Qwen/Qwen2.5-0.5B-Instruct, ét forward pass, prompten ovenfor, hvor vi tæller, hvor mange tokens det kræver at akkumulere en given andel af sandsynlighedsmassen:

Læs den nederste række langsomt. Ved $T = 2$, på et spørgsmål med præcis ét korrekt svar, deler 32.966 forskellige tokens de øverste 90 % af sandsynlighedsmassen. Det er ikke et bredere kreativt rum. Det er en model, der af aritmetik er blevet bedt om at behandle en koreansk partikel og en C++-identifier som levende muligheder for ordet efter A:. Affaldet i åbningsblokken er den direkte konsekvens, og det er ikke en fejl i modellen eller biblioteket — det er det, anmodningen bad om.

Det nyttige interval er smalt og afhænger af opgaven frem for smag. På et faktuelt spørgsmål er svaret én token, og enhver varme over cirka 1,2 injicerer fejl uden gevinst. På et åbent spørgsmål findes der reelt mere end én god fortsættelse, og noget varme køber variation, der stadig er flydende:

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

Ved 1,3 har modellen opfundet et egennavn og en sætning, der ikke kan parses. Båndet mellem "identisk hver gang" og "usammenhængende" er omtrent 0,6 til 1,1 for denne model på denne opgave, og det ærlige råd er, at du finder det ved at måle på din opgave, ikke ved at kopiere et tal fra et blogindlæg.

Der gemmer sig et oplagt spørgsmål under det hele: hvis modellen har en sandsynlighedsfordeling, og én token er mest sandsynlig, hvorfor så ikke altid tage den? Greedy decoding er gratis, reproducerbart og kræver ingen parametre.

Fordi resultatet er dette:

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 %

Otte sætninger, én sætning. Næsten ni ud af ti fire-token-vinduer var allerede dukket op tidligere i samme output. Det er neural text degeneration, navngivet og forklaret af Holtzman et al. i artiklen, der introducerede top-p.³ Modellen er ikke i stykker; maksimering af sekvenssandsynlighed er simpelthen det forkerte mål for åben tekst. Menneskelig skrivning er ikke den mest sandsynlige sekvens af ord — den rummer overraskelse, dens per-token-sandsynlighed vandrer, dykker og kommer sig — mens maksimum-sandsynlighedsstien er et fikspunkt, der, når det først er nået, ikke har nogen grund til at forlade sig selv.

Det er derfor, sampling overhovedet findes. Det er også, og det er den del, der ofte udelades, ikke en universel lov. Kapitel 12 målte 24 ud af 24 korrekte på totrins ordproblemer med almindelig greedy decoding, og sampling ved temperatur 0,8 sænkede det til 81 %; self-consistency brugte derefter seks gange så mange tokens på at klatre tilbage til det sted, hvor greedy allerede var. Begge fakta er sande på én gang:

De fleste produktionsprompts er af den anden slags og bliver konfigureret som den første, fordi temperaturen blev efterladt på det tal, eksempelkoden brugte.

Sampling fra den fulde fordeling er ikke det, nogen faktisk gør, fordi halen er enorm og fuld af nonsens. Noget må skæres væk. Der er to klassiske svar, og de adskiller sig på ét punkt, der afgør alt.

Top-k beholder et fast antal kandidater. Sortér efter sandsynlighed, behold de første $k$, kassér resten, renormalisér.⁴ Top-p, også kaldet nucleus sampling, beholder en fast mængde masse: tag tokens i faldende rækkefølge, indtil deres kumulative sandsynlighed når $p$, og stop.³ Formelt er nucleus det mindste sæt $V_p$ med

Forskellen lyder kosmetisk, men er det ikke, fordi de to prompts, du sender i samme minut, har helt forskellige fordelingsformer. Begge disse er samme model ved temperatur 1:

Én fast $k$, to fejl i modsatte retninger. På den faktuelle prompt lukker $k = 40$ 39 tokens ind, der tilsammen er 3,6 % værd — den lader skrald slippe igennem, inklusive en kandidat på ni tusindedele procent, fordi reglen tæller pladser og ikke evidens. På historieprompten smider den samme $k = 40$ 21 % af den masse væk, som modellen faktisk tildelte, fordi den reelle nucleus dér er 467 tokens bred.

Top-p får præcis ét tal til at gøre begge job. Sæt $p = 0.9$, og den beholder 1 token på den første prompt og 467 på den anden, fordi den stiller et spørgsmål om fordelingen i stedet for at påtvinge den et antal. Se tilpasningen direkte — samme afskæring, fire temperaturer:

Den widget afgør også en misforståelse, der er værd at navngive, fordi den koster folk rigtige penge. På en sikker fordeling er top_p = 0.9 ikke "lidt variation". Det er greedy. Ved temperatur 1 holder den førende token her 96,90 %, hvilket allerede er over 0,9, så nucleus er én token bred, og intet andet kan nogensinde trækkes. Teams sætter top_p til 0,9 i den tro, at de har løsnet noget, og undrer sig så over, hvorfor hvert svar er identisk.

Sæt top-k i stedet, og den modsatte fejl er lige så synlig:

Tre forskellige mekanismer rejser under lignende navne, de gør forskellige ting, og forskellen kan måles. Lad $c_i$ være antallet af gange, token $i$ allerede er dukket op.

Den samme degenererede fortsættelse fra før, med hver af dem anvendt. "Ændrede trin" tæller, hvor mange af de 120 genereringstrin der valgte en anden token end den ustraffede model ville have gjort. Kørslen er 120 trin her mod 140 i blokken ovenfor, og derfor viser den ustraffede baseline 85,5 % i stedet for 87,6 %:

Tre ting falder ud. Presence ved 0,5 ændrede tre beslutninger ud af 120 og skar gentagelsen med en fjerdedel — loopet blev holdt sammen af en håndfuld tokens. Frequency ved 0,5 ændrede fire gange så mange beslutninger med langt større effekt, fordi count-multiplikatoren bliver ved med at vokse, mens presence-konstanten ikke gør. Og CTRL-straffen ved den ofte kopierede værdi 1,2 omskrev 35 af 120 beslutninger, hvilket ikke er et lille puf; det er en anden model.

Det sidste tal er oplægget til den fejl, ingen advarer om.

Kode gentager sig. Tabeller gentager sig. Lister gentager sig. Struktureret output gentager sig pr. definition — det er det, struktur er. En straf kan ikke kende forskel på en model, der sidder fast i et loop, og en model, der korrekt udsender fjerde række i en tabel, fordi begge dele ligner en token, der dukker op igen.

De samme tre opgaver, genereret på tre måder:

Frequency penalty ved 0,5 viste sig at være harmløs på alle tre, hvilket er et nyttigt og lidt overraskende resultat, og det siger noget præcist: eftersom ingen beslutning ændrede sig, må de strukturelle tokens have vundet deres positioner med mere end straffen trak fra, selv efter at være dukket op fem og seks gange. CTRL-straffen, som dividerer i stedet, løsriver dem, og her er hvad den producerede:

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

Justeringen falder fra hinanden: mængden af padding inde i hver celle ændrer sig fra række til række, fordi rækken af mellemrum før den afsluttende pipe præcis er den slags gentagelse, straffen findes for at bryde. Kosmetisk, og det kostede seks ekstra tokens. Python-tilfældet er ikke kosmetisk:

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,

Straffen skubbede modellen væk fra total — allerede brugt i docstringen — over på total_sum, polstrede outputtet med opfundne kommentarer for at bruge sit budget på ubrugte tokens og gik derefter ind i en tre-argumenters range med en stride. Kommentaren siger incrementing by 2 each time, hvilket er forkert for en sum af kvadrater fra 1 til $n$. En repetition penalty producerede forkert kode fra en prompt, der blev besvaret korrekt uden den.

Reglen, der følger, er kort: straffe er til åben prosa, og de bør være slået fra for kode, struktureret output, tabeldata og alt med et schema. Kapitel 18 handler præcis om den anden kategori.

Enhver reel implementation anvender disse i én bestemt sekvens:

straffe → temperatur → top-k → top-p → sample

Det er ikke vilkårlig bogføring, og at bytte om på to trin producerer reelt forskellige fordelinger. To målinger, begge på den faktuelle prompt.

Afskæring før eller efter temperaturen. Nucleus beregnes på den fordeling, den får, og temperatur ændrer den fordeling radikalt:

Ved $T = 2$ giver den samme nominelle indstilling et kandidatsæt på 32.966 eller på 1, alene afhængigt af hvilket trin der kører først. Hvis du nogensinde har undret dig over, hvorfor en højere temperatur "ikke gør noget" hos én udbyder og ødelægger outputtet hos en anden med de samme to tal, er denne tabel et plausibelt svar.

Straf før eller efter temperaturen. At trække en straf $\alpha$ fra og derefter dividere med $T$ giver en effektiv straf på $\alpha/T$; at dividere først og derefter trække fra giver $\alpha$. Med en presence penalty på 1,0 anvendt på den førende token:

Identiske ved $T = 1$, som de skal være. En faktor 1,58 fra hinanden ved $T = 2$. "Presence penalty 1,0" er ikke en veldefineret mængde straf, medmindre du også ved, hvor temperaturen anvendes, og ingen API dokumenterer det.

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

Hver udbyder tager et forskelligt udsnit af disse kontroller, med forskellige intervaller, og ignorerer resten i stilhed. Det er ikke en abstrakt klage. Enhver applikation, der tilbyder et valg af model, må skrive forskellene ned et sted, og filen, hvor den gør det, er et kort over inkompatibiliteten. Her er, hvad ét sådant katalog erklærer for én parameter på tværs af de ni tekstkilder, det understøtter:

Ordet er det samme; skalaen er det ikke. En "temperatur på 1" er den uændrede fordeling hos én og den maksimalt tilladte varme hos en anden, og halvdelen af kataloget kan ikke udtrykke den værdi, den anden halvdel behandler som neutral-plus-lidt. Resten af knapperne er lige så ujævne: OpenAI-, DeepSeek- og xAI-posterne tager presence og frequency penalties og ingen topK; Google-, Meta-, Cerebras- og PaLM-posterne tager topK og ingen straffe; Anthropic tager topK, topP og stopsekvenser og ingen straffe; og præcis én af de ni — Mistral — tager en seed. At sende en parameter, en udbyder ikke implementerer, giver typisk slet ingen fejl: anmodningen lykkes, knappen gør ingenting, og du konkluderer, at indstillingen ingen effekt har.

Og læg mærke til, hvad sådan en fil er: en påstand om en andens API, skrevet på én bestemt dag, som intet verificerer bagefter. Et katalog, der siger 0 til 1 for en udbyder, som nu accepterer 0 til 2, vil lydløst cappe hver anmodning.

To kontroller mere hører til samme familie. logprobs, hvor det tilbydes, returnerer log-sandsynlighederne for den valgte token og ofte de få bedste alternativer — det eneste vindue, du får ind til den fordeling, dette kapitel handler om, og grundlaget for enhver confidence-heuristik bygget på en lukket model. Og maximum tokens plus stopsekvenser afslutter generering helt uden reference til sandsynlighed: en hård grænse og et string-match. Begge dukker op som finish_reason fra Kapitel 14, hvor length betyder, at dit svar blev skåret midt i en sætning af et budget, ikke afsluttet af modellen.

Sæt en seed, og sampling bliver reproducerbar. Den del er reel, og den er nem at verificere:

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-identisk inden for en seed, forskellig på tværs af seeds, præcis som annonceret. Så det, seeden fastlåser, er det tilfældige træk i den sidste linje af sample-funktionen — hvilken token der bliver valgt, givet en fordeling.

Det, den ikke fastlåser, er fordelingen. Og det er dér, problemet ligger, fordi vektoren af logits, som din model producerer, ikke er et matematisk objekt; den er outputtet af milliarder af floating-point-additioner, og de har en rækkefølge.

Kapitel 2 efterlod dette eksperiment klar. De samme million float32-tal, summeret i forskellige grupperinger:

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

Se på den sidste linje. Antallet af chunks ændrer svaret. Det er ikke en kuriositet ved numpy; det er mekanismen, for når en inference-server splitter en reduktion over flere eller færre parallelle enheder, gør den præcis dette. Og en server splitter efter, hvor mange anmodninger den betjener.

Her er den effekt på selve modellen. Samme prompt, samme forward pass, den eneste forskel er, hvor mange andre anmodninger der tilfældigvis var i batchen:

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

Kørt alene er modellen perfekt deterministisk — tyve pass, identiske ned til bitten. Læg den identiske prompt i en batch med urelaterede anmodninger, og 97 % af dens logits ændrer sig. Intet ved din anmodning ændrede sig. En andens anmodning ankom.

Nu den ærlige del, fordi dette normalt fortælles, som om det var slutningen på historien. En ændring på $2.5 \times 10^{-5}$ ændrer kun outputtet, hvis to kandidat-tokens lå inden for den afstand af hinanden. Over 717 genereringstrin på tværs af tolv prompts var det mindste gab mellem de to øverste logits $2.5 \times 10^{-3}$ — hundrede gange større end perturbationen — og intet trin var tæt nok på at flippe. Så på denne model, i float32, på en laptop, flyttede batching hver logit og ændrede ingen token.

Det er en beskrivelse af gunstige forhold, ikke en beroligelse, og én ændring af de forhold er nok:

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

Seks af otte svar divergerer, og ét af dem forringes voldsomt. Kapitel 2s tabel siger hvorfor: bfloat16 beholder 7 mantissebits, så nær en logit-størrelse på 16 ligger de repræsenterbare værdier 0,125 fra hinanden — 16,0, så 16,125, så 16,25 — og afrunding kan flytte en logit med op til 0,0625. Imens havde 4,7 % af genereringstrinnene målt ovenfor et top-to-gab under 0,1. Det er hele forskellen mellem de to eksperimenter: i float32 var perturbationen hundrede gange mindre end den nærmeste beslutning, og i bfloat16 er den samme størrelse. Produktions-inference kører i 16-bit, på hardware med fused kernels og reduktionsrækkefølger, ingen lover at holde stabile. Om "den numeriske støj er ubetydelig", er et spørgsmål om præcision og hardware, ikke om modellen.

Så her er de fire årsager, katalogiseret som Kapitel 9 lovede:

OpenAIs seed-parameter er ærlig om dette på den eneste måde, den kan være: den sendes sammen med et system_fingerprint-felt, der identificerer backend-konfigurationen, og dokumentationen siger, at determinisme er best-effort, og at et ændret fingerprint betyder, at resultater kan afvige. Læs det som det, det er — en udbyder, der fortæller dig, at den kontrollerer alle fire årsager ovenfor, at du ikke kontrollerer nogen af dem, og at det eneste, den kan tilbyde, er at fortælle dig bagefter, at noget flyttede sig.

Alt her har handlet om en knap og dens konsekvenser. Træd ét niveau tilbage, og det sværere problem viser sig: objektet, vi har tunet, er en sandsynlighedsfordeling, og sandsynlighedsfordelinger har ikke et interface.

Et function call har ét. En databaserække har ét. En POST-handler, der forventer en JSON-body med tre påkrævede felter, har ét, og den afviser alt andet. Mellem modellen og hver anden komponent i dit system sidder en kontrakt, som den ene side ikke kan give løfter om: modellen vil producere noget, trukket fra en fordeling, du har formet, men ikke fastlåst, og koden på den anden side kræver en værdi af en kendt type, ellers fejler den.

Broen mellem de to verdener bygges af dette kapitels materiale snarere end af parsing og retries. Hvis en token ville bryde den krævede struktur, sampler du den ikke og håber — du sætter dens logit til $-\infty$, før softmax nogensinde ser den. Constrained decoding er en maske over den samme vektor, vi har brugt dette kapitel på at omforme, og den gør "svar venligst i JSON" fra en anmodning til en garanti.

Kapitel 18 er den kontrakt: tool calling, JSON Schema, strukturerede outputs, og hvad der skal til for at gøre et deterministisk system sikkert at bygge oven på et probabilistisk.

Alle målinger i dette kapitel kommer fra Qwen/Qwen2.5-0.5B-Instruct på CPU, float32 medmindre andet er angivet, med sampling implementeret som skrevet i det valgfrie afsnit i stedet for delegeret til et bibliotek. Det er en lille model, og de konkrete værdier er dens; mekanismerne er ikke. Von Platens How to generate text with different decoding methods (Hugging Face, 2020) er artiklen, denne måles op imod, og er stadig den bedste korte introduktion til det samme materiale. For afsnittet om determinisme: PyTorchs noter om reproducerbarhed beskriver, hvad en seed gør og ikke gør på én maskine, OpenAIs dokumentation af seed og system_fingerprint beskriver, hvad en udbyder kan og ikke kan love, og Thinking Machines' diskussion fra 2025 af batch-invariant kernels er den klareste offentlige forklaring på, hvorfor det er muligt, men ikke gratis, at fikse dette på inference-serverniveau.