Temperatur, top-p och determinismen du inte har

Kapitel 4 introducerade logit som en onormaliserad realvärd poäng, en per klass. Kapitel 8 fick en språkmodell att producera en per post i vokabulären. softmax gör den vektorn $\mathbf{z}$ till sannolikheter:

Temperatur kommer in här — namnet är lånat från statistisk fysik, där samma parameter styr hur skarpt en Boltzmannfördelning koncentreras på sina lågenergitillstånd¹ — och den delar logits före exponentialen:

Den placeringen är hela mekanismen, och det räcker med två rader algebra för att se varför den inte kunde sitta någon annanstans. Anta att du försökte applicera temperatur på sannolikheterna i stället — skala dem med $1/T$ och normalisera om. Du skulle få

Konstanten försvinner. Att skala sannolikheter gör ingenting alls; fördelningen kommer tillbaka oförändrad. Temperatur har bara effekt eftersom den verkar på exponenten, där division med $T$ före exponentiering är detsamma som att upphöja varje sannolikhet till $1/T$ — en icke-linjär omformning som ändrar kvoterna mellan posterna snarare än deras gemensamma skala.

Från den placeringen följer båda gränsfallen utan mer arbete. När $T \to 0$ rusar den största logit ifrån resten och $p$ kollapsar till den enda högst rankade token: greedy decoding. När $T$ växer går varje $z_i/T$ mot noll, varje exponential går mot 1, och fördelningen plattas ut mot uniform över hela vokabulären. Vid exakt $T = 0$ delar formeln med noll, så varje implementation specialhanterar det till det aritmetiska maximumet — inklusive widgeten nedan, som växlar till argmax vid $T \le 0.001$.

En varning, eftersom namnkollisionen orsakar verklig förvirring. Det finns en annan, orelaterad sak som kallas temperatur i machine learning: temperature scaling, en kalibreringsmetod som passar in ett värde på en valideringsmängd så att en klassificerares säkerhet matchar dess träffsäkerhet.² Samma formel, inget med generering att göra. När papers säger ”temperature” menar de ofta den; det gör aldrig det här kapitlet.

Här är den fördelningen, med aritmetiken framför dig. logits är fasta och rimliga, så talen i texten nedan kan kontrolleras mot det du ser:

Siffran ␣banana är hela argumentet i miniatyr: att höja temperaturen kan inte ge en modell en idé den inte hade. logits är redan beräknade, rankningen är redan fast, och temperatur bevarar den exakt — ingen mängd värme flyttar någonsin en lägre rankad token över en högre rankad. Allt den gör är att omfördela massa nedåt i den rankning modellen själv producerade. Hög temperatur gör inte en modell mer uppfinningsrik; den gör det mer sannolikt att den avger tokens som den själv rankade som dåliga.

På ett verkligt vokabulär slutar det här vara en kuriositet och blir orsaken till att högtempererad output är oanvändbar. Mätt på Qwen/Qwen2.5-0.5B-Instruct, ett forward pass, prompten ovan, med räkning av hur många tokens som krävs för att samla en given andel av sannolikhetsmassan:

Läs den nedersta raden långsamt. Vid $T = 2$, på en fråga med exakt ett korrekt svar, delar 32 966 olika tokens på de översta 90 % av sannolikhetsmassan. Det är inte ett bredare kreativt utrymme. Det är en modell som, av aritmetiken, har fått instruktionen att behandla en koreansk partikel och en C++-identifierare som levande alternativ för ordet efter A:. Skräpet i öppningsblocket är den direkta konsekvensen, och det är inte en bugg i modellen eller biblioteket — det är vad begäran bad om.

Det användbara intervallet är smalt och beror på uppgiften snarare än smak. På en faktabaserad fråga är svaret en token och all värme över ungefär 1,2 injicerar fel utan nytta. På en öppen fråga finns det verkligen mer än en bra fortsättning, och lite värme köper variation som fortfarande är flytande:

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

Vid 1,3 har modellen hittat på ett egennamn och en mening som inte går att tolka. Bandet mellan ”identiskt varje gång” och ”osammanhängande” är ungefär 0,6 till 1,1 för den här modellen på den här uppgiften, och det ärligaste rådet är att du hittar det genom att mäta på din uppgift, inte genom att kopiera ett tal från ett blogginlägg.

Det finns en uppenbar fråga gömd under allt detta: om modellen har en sannolikhetsfördelning och en token är mest sannolik, varför inte alltid ta den? Greedy decoding är gratis, reproducerbart och behöver inga parametrar.

För att resultatet är det här:

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 %

Åtta meningar, en mening. Nästan nio av tio fyratokenfönster hade redan förekommit tidigare i samma output. Det här är neural text degeneration, namngivet och förklarat av Holtzman et al. i paperet som introducerade top-p.³ Modellen är inte trasig; att maximera sekvenssannolikhet är helt enkelt fel mål för öppen text. Mänskligt skrivande är inte den mest sannolika ordsekvensen — det bär överraskning, dess per-token-sannolikhet vandrar, faller och återhämtar sig — medan vägen med maximal sannolikhet är en fixpunkt som, när den väl har trätts in i, inte har någon anledning att lämna.

Det är därför sampling finns över huvud taget. Det är också, och det här är delen som ofta utelämnas, inte en universell lag. Kapitel 12 mätte 24 av 24 rätt på tvåstegs ordproblem med vanlig greedy decoding, och sampling vid temperatur 0,8 sänkte det till 81 %; self-consistency spenderade sedan sex gånger fler tokens för att klättra tillbaka till där greedy redan var. Båda sakerna är sanna samtidigt:

De flesta produktionsprompts är av den andra sorten och konfigureras som den första, eftersom temperaturen lämnades på vad exempelkoden råkade använda.

Sampling från hela fördelningen är inte vad någon faktiskt gör, eftersom svansen är enorm och full av nonsens. Något måste skäras bort. Det finns två klassiska svar och de skiljer sig åt på en punkt som avgör allt.

Top-k behåller ett fast antal kandidater. Sortera efter sannolikhet, behåll de första $k$, kasta resten, normalisera om.⁴ Top-p, också kallat nucleus sampling, behåller en fast mängd massa: ta tokens i fallande ordning tills deras kumulativa sannolikhet når $p$, och stanna.³ Formellt är kärnan den minsta mängden $V_p$ med

Skillnaden låter kosmetisk och är det inte, eftersom de två prompts du skickar under samma minut har helt olika fördelningsformer. Båda dessa är samma modell vid temperatur 1:

Ett fast $k$, två fel åt motsatta håll. På den faktabaserade prompten släpper $k = 40$ in 39 tokens som tillsammans är värda 3,6 % — den släpper igenom skräp, inklusive en kandidat på nio tusendels procent, eftersom regeln räknar platser och inte evidens. På berättelseprompten kastar samma $k = 40$ bort 21 % av massan som modellen verkligen tilldelade, eftersom den verkliga kärnan där är 467 tokens bred.

Top-p får exakt ett tal att göra båda jobben. Sätt $p = 0.9$ och det behåller 1 token på den första prompten och 467 på den andra, eftersom det ställer en fråga om fördelningen i stället för att påtvinga den ett antal. Se den anpassningen direkt — samma snitt, fyra temperaturer:

Den widgeten avgör också en missuppfattning som är värd att namnge, eftersom den kostar människor riktiga pengar. På en säker fördelning är top_p = 0.9 inte ”lite variation”. Det är greedy. Vid temperatur 1 håller den ledande token här 96,90 %, vilket redan är över 0,9, så kärnan är en token bred och inget annat kan någonsin dras. Team sätter top_p till 0,9 i tron att de har lossat något och undrar sedan varför varje svar är identiskt.

Sätt top-k i stället och det motsatta felet är lika synligt:

Tre olika mekanismer färdas under liknande namn, de gör olika saker, och skillnaden är mätbar. Låt $c_i$ vara antalet gånger token $i$ redan har förekommit.

Samma degenererade fortsättning från tidigare, med var och en applicerad. ”Ändrade steg” räknar hur många av de 120 genereringsstegen som valde en annan token än den ostraffade modellen skulle ha gjort. Körningen är 120 steg här mot 140 i blocket ovan, vilket är varför den ostraffade baslinjen visar 85,5 % snarare än 87,6 %:

Tre saker faller ut. Presence vid 0,5 ändrade tre beslut av 120 och minskade repetitionen med en fjärdedel — loopen hölls ihop av en handfull tokens. Frequency vid 0,5 ändrade fyra gånger så många beslut med en mycket större effekt, eftersom antalsmultiplikatorn fortsätter växa medan presence-konstanten inte gör det. Och CTRL-straffet vid det ofta kopierade värdet 1,2 skrev om 35 av 120 beslut, vilket inte är en knuff; det är en annan modell.

Det sista talet är upplägget för felet ingen varnar för.

Kod upprepar. Tabeller upprepar. Listor upprepar. Strukturerad output upprepar per definition — det är vad struktur är. Ett straff kan inte se skillnad på en modell som fastnat i en loop och en modell som korrekt avger den fjärde raden i en tabell, eftersom båda ser ut som en token som förekommer igen.

Samma tre uppgifter, genererade på tre sätt:

Frequency-straffet vid 0,5 visade sig vara ofarligt på alla tre, vilket är ett användbart och lite överraskande resultat, och det säger något precist: eftersom inget beslut ändrades måste de strukturella tokens ha vunnit sina positioner med mer än straffet drog av, även efter att ha förekommit fem och sex gånger. CTRL-straffet, som delar i stället, rubbar dem, och här är vad det producerade:

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

Justeringen faller isär: mängden utfyllnad i varje cell ändras från rad till rad, eftersom raden av mellanslag före den avslutande pipen är exakt den sorts repetition som straffet finns för att bryta. Kosmetiskt, och det kostade sex extra tokens. Python-fallet är inte kosmetiskt:

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,

Straffet knuffade modellen bort från total — redan använt i docstringen — till total_sum, fyllde ut output med påhittade kommentarer för att spendera sin budget på oanvända tokens, och gick sedan in i ett trearguments range med ett steg. Kommentaren säger incrementing by 2 each time, vilket är fel för en summa av kvadrater från 1 till $n$. Ett repetition penalty producerade felaktig kod från en prompt som besvarades korrekt utan det.

Regeln som följer är kort: straff är för öppen prosa, och de bör vara avstängda för kod, strukturerad output, tabelldata och allt med ett schema. Kapitel 18 handlar om exakt den andra kategorin.

Varje verklig implementation applicerar dessa i en specifik sekvens:

straff → temperatur → top-k → top-p → sample

Det här är inte godtycklig bokföring, och att byta plats på två steg producerar genuint olika fördelningar. Två mätningar, båda på den faktabaserade prompten.

Att skära före eller efter temperaturen. Kärnan beräknas på den fördelning den får, och temperatur ändrar den fördelningen radikalt:

Vid $T = 2$ ger samma nominella inställning en kandidatuppsättning på 32 966 eller 1, helt beroende på vilket steg som körs först. Om du någon gång undrat varför höjd temperatur ”inte gör något” hos en provider och förstör output hos en annan med samma två tal, är den här tabellen ett rimligt svar.

Att straffa före eller efter temperaturen. Att subtrahera ett straff $\alpha$ och sedan dela med $T$ ger ett effektivt straff på $\alpha/T$; att dela först och sedan subtrahera ger $\alpha$. Med ett presence penalty på 1,0 applicerat på den ledande token:

Identiska vid $T = 1$, som de måste vara. En faktor 1,58 isär vid $T = 2$. ”Presence penalty 1,0” är inte en väldefinierad mängd straff om du inte också vet var temperaturen appliceras, och ingen API dokumenterar detta.

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

Varje provider tar en annan delmängd av dessa kontroller, med olika intervall, och ignorerar resten i tystnad. Det här är inget abstrakt klagomål. Varje applikation som erbjuder ett val av modell måste skriva ned skillnaderna någonstans, och filen där den gör det är en karta över inkompatibiliteten. Här är vad en sådan katalog deklarerar för en enda parameter över de nio textkällor den stöder:

Ordet är detsamma; skalan är det inte. En ”temperatur på 1” är den omodifierade fördelningen hos en och högsta tillåtna värme hos en annan, och halva katalogen kan inte uttrycka värdet som den andra halvan behandlar som neutralt-plus-lite. Resten av reglagen är lika ojämna: posterna för OpenAI, DeepSeek och xAI tar presence och frequency penalties och ingen topK; posterna för Google, Meta, Cerebras och PaLM tar topK och inga straff; Anthropic tar topK, topP och stop sequences och inga straff; och exakt en av de nio — Mistral — tar en seed. Att skicka en parameter som en provider inte implementerar ger i allmänhet inget fel alls: begäran lyckas, reglaget gör ingenting, och du drar slutsatsen att inställningen saknar effekt.

Och lägg märke till vad en sådan fil är: ett påstående om någon annans API, skrivet en viss dag, som ingenting verifierar efteråt. En katalog som säger 0 till 1 för en provider som nu accepterar 0 till 2 kommer tyst att kapa varje begäran.

Två kontroller till hör till samma familj. logprobs, där det erbjuds, returnerar log-sannolikheterna för vald token och ofta de främsta alternativen — det enda fönstret du får mot fördelningen det här kapitlet handlar om, och grunden för varje confidence heuristic byggd på en sluten modell. Och maximum tokens plus stop sequences avslutar generering utan hänsyn till sannolikhet alls: ett hårt tak och en strängmatchning. Båda syns som finish_reason från kapitel 14, där length betyder att ditt svar kapades mitt i meningen av en budget, inte avslutades av modellen.

Sätt en seed och sampling blir reproducerbart. Den delen är verklig, och den är lätt att verifiera:

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-identiskt inom en seed, olika mellan seeds, precis som utlovat. Så det seed fixerar är slumpdragningen i den sista raden av sample-funktionen — vilken token som väljs givet en fördelning.

Det den inte fixerar är fördelningen. Och det är där problemet finns, eftersom vektorn av logits som din modell producerar inte är ett matematiskt objekt; den är resultatet av miljarder flyttalsadditioner, och de har en ordning.

Kapitel 2 lämnade det här experimentet redo. Samma miljon float32-tal, summerade i olika grupperingar:

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

Titta på sista raden. Antalet chunks ändrar svaret. Det är inte en kuriositet om numpy; det är mekanismen, för när en inference server delar en reduktion över fler eller färre parallella enheter gör den precis detta. Och en server delar upp utifrån hur många begäranden den hanterar.

Här är den effekten på själva modellen. Samma prompt, samma forward pass, enda skillnaden är hur många andra begäranden som råkade finnas 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örd ensam är modellen perfekt deterministisk — tjugo pass, identiska bit för bit. Lägg samma prompt i en batch med orelaterade begäranden och 97 % av dess logits ändras. Ingenting i din begäran ändrades. Någon annans begäran kom in.

Nu den ärliga delen, eftersom detta vanligtvis berättas som om det vore slutet på historien. En ändring på $2.5 \times 10^{-5}$ ändrar bara output om två kandidat-tokens låg inom det avståndet från varandra. Över 717 genereringssteg över tolv prompts var det minsta gapet mellan de två högsta logits $2.5 \times 10^{-3}$ — hundra gånger större än perturbationen — och inget steg var tillräckligt nära för att flippa. Så på den här modellen, i float32, på en laptop, flyttade batching varje logit och ändrade ingen token.

Det är en beskrivning av gynnsamma förhållanden, inte ett lugnande besked, och en enda ändring av de förhållandena räcker:

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

Sex av åtta svar divergerar, och ett av dem försämras rejält. Kapitel 2:s tabell säger varför: bfloat16 behåller 7 mantissabitar, så nära en logit-storlek på 16 ligger de representerbara värdena 0,125 isär — 16,0, sedan 16,125, sedan 16,25 — och avrundning kan flytta en logit med upp till 0,0625. Samtidigt hade 4,7 % av genereringsstegen ovan ett topp-två-gap under 0,1. Det är hela skillnaden mellan de två experimenten: i float32 var perturbationen hundra gånger mindre än det närmaste beslutet, och i bfloat16 är den av samma storlek. Produktionens inference körs i 16-bit, på hårdvara med fused kernels och reduktionsordningar som ingen lovar att behålla. Om ”det numeriska bruset är försumbart” är en fråga om precision och hårdvara, inte om modellen.

Alltså, de fyra orsakerna, katalogiserade som kapitel 9 lovade:

OpenAI:s seed-parameter är ärlig om detta på det enda sätt den kan vara: den levereras tillsammans med ett system_fingerprint-fält som identifierar backendkonfigurationen, och dokumentationen säger att determinism är best-effort och att ett ändrat fingerprint betyder att resultaten kan skilja sig. Läs det för vad det är — en provider som säger att den kontrollerar alla fyra orsakerna ovan, att du inte kontrollerar någon av dem, och att det enda den kan erbjuda är att säga i efterhand att något flyttade sig.

Allt här har handlat om ett reglage och dess konsekvenser. Ta ett steg tillbaka och det svårare problemet framträder: objektet vi har stämt in är en sannolikhetsfördelning, och sannolikhetsfördelningar har inget interface.

Ett function call har ett. En databasrad har ett. En POST-handler som förväntar sig en JSON body med tre obligatoriska fält har ett, och den avvisar allt annat. Mellan modellen och varje annan komponent i ditt system sitter ett kontrakt som ena sidan inte kan ge löften om: modellen kommer att producera något, draget från en fördelning som du har format men inte fixerat, och koden på andra sidan behöver ett värde av en känd typ, annars kastar den.

Bron mellan de två världarna byggs av materialet i det här kapitlet snarare än av parsing och retries. Om en token skulle bryta den krävda strukturen samplar du den inte och hoppas — du sätter dess logit till $-\infty$ innan softmax någonsin ser den. Constrained decoding är en mask över samma vektor som vi har ägnat kapitlet åt att forma om, och den gör ”svara i JSON, tack” från en begäran till en garanti.

Kapitel 18 är det kontraktet: tool calling, JSON Schema, structured outputs, och vad som krävs för att göra ett deterministiskt system säkert att bygga ovanpå ett probabilistiskt.

Alla mätningar i det här kapitlet kommer från Qwen/Qwen2.5-0.5B-Instruct på CPU, float32 om inget annat anges, med sampling implementerad som skrivet i det valfria avsnittet snarare än delegerad till ett bibliotek. De är en liten modell, och de specifika värdena är dess; mekanismerna är det inte. Von Platens How to generate text with different decoding methods (Hugging Face, 2020) är artikeln som den här mäts mot och är fortfarande den bästa korta introduktionen till samma material. För determinismavsnittet: PyTorchs reproducibility notes beskriver vad en seed gör och inte fixerar på en enda maskin, OpenAI:s dokumentation av seed och system_fingerprint beskriver vad en provider kan och inte kan lova, och Thinking Machines diskussion från 2025 om batch-invariant kernels är den tydligaste offentliga redogörelsen för varför det är möjligt men inte gratis att fixa detta på inference-servernivå.