Temperature, Top-p и детерминизмът, който нямате

Глава 4 въведе logit като ненормализирана реална оценка, по една за всеки клас. Глава 8 накара езиков модел да произведе по една такава за всеки запис в речника. softmax превръща този вектор $\mathbf{z}$ във вероятности:

Temperature влиза тук — името е заето от статистическата физика, където същият параметър контролира колко рязко едно разпределение на Болцман се концентрира върху нискоенергийните си състояния¹ — и той дели logits преди експонентата:

Това място е целият механизъм и си струва два реда алгебра, за да се види защо не би могло да бъде другаде. Да предположим, че се опитате да приложите temperature върху вероятностите вместо това — да ги мащабирате с $1/T$ и да нормализирате отново. Ще получите

Константата се съкращава. Мащабирането на вероятности не прави абсолютно нищо; разпределението се връща непроменено. Temperature има ефект само защото действа върху експонентата, където делението на $T$ преди експонентиране е същото като повдигане на всяка вероятност на степен $1/T$ — нелинейно преоформяне, което променя съотношенията между записите, а не общия им мащаб.

От това място и двете граници следват без допълнителна работа. Когато $T \to 0$ най-големият logit се откъсва от останалите и $p$ колабира върху единствения token с най-висока оценка: greedy decoding. Когато $T$ расте, всеки $z_i/T$ върви към нула, всяка експонента върви към 1 и разпределението се изравнява към uniform върху целия речник. При точно $T = 0$ формулата дели на нула, така че всяка имплементация го обработва като специален случай до аритметичния максимум — включително widget-ът по-долу, който превключва към argmax при $T \le 0.001$.

Едно предупреждение, защото сблъсъкът на имена причинява реално объркване. В machine learning има второ, несвързано нещо, наречено temperature: temperature scaling, метод за калибрация, който напасва една стойност върху validation set, така че увереността на класификатора да съответства на точността му.² Същата формула, нищо общо с генерирането. Когато статии казват „temperature“, често имат предвид това; тази глава никога няма предвид него.

Ето това разпределение, с аритметиката пред вас. logits са фиксирани и правдоподобни, така че числата в текста по-долу могат да се проверят спрямо това, което виждате:

Числото ␣banana е целият аргумент в миниатюра: повишаването на temperature не може да даде на модела идея, която той не е имал. logits вече са изчислени, подредбата вече е фиксирана и temperature я запазва точно — никаква топлина никога не премества по-ниско оценен token над по-високо оценен. Всичко, което прави, е да преразпределя маса надолу по подредбата, която самият модел е произвел. Висок temperature не прави модела по-изобретателен; прави го по-склонен да изведе tokens, които сам е оценил като лоши.

В реален речник това престава да бъде любопитен детайл и се превръща в причината output-ът при висок temperature да е неизползваем. Измерено върху Qwen/Qwen2.5-0.5B-Instruct, един forward pass, prompt-ът по-горе, с броене колко tokens са нужни, за да се натрупа даден дял от вероятностната маса:

Прочетете бавно последния ред. При $T = 2$, на въпрос с точно един верен отговор, 32 966 различни tokens споделят първите 90 % от вероятностната маса. Това не е по-широко творческо пространство. Това е модел, на който аритметиката е казала да третира корейска частица и C++ идентификатор като живи опции за думата след A:. Боклукът в началния блок е пряката последица и не е bug в модела или библиотеката — това е, което заявката е поискала.

Полезният диапазон е тесен и зависи от задачата, а не от вкуса. При фактологичен въпрос отговорът е един token и всяка топлина над около 1,2 инжектира грешка без полза. При отворена задача наистина има повече от едно добро продължение и малко топлина купува разнообразие, което остава плавно:

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

При 1,3 моделът е измислил собствено име и изречение, което не се парсва. Лентата между „идентично всеки път“ и „несвързано“ е приблизително от 0,6 до 1,1 за този модел върху тази задача, а честният съвет е да я намерите чрез измерване върху вашата задача, не чрез копиране на число от blog пост.

Под всичко това се крие очевиден въпрос: ако моделът има вероятностно разпределение и един token е най-вероятен, защо да не го взимаме винаги? Greedy decoding е безплатен, възпроизводим и не се нуждае от параметри.

Защото резултатът е това:

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 %

Осем изречения, едно изречение. Почти девет от десет четири-token прозореца вече са се появили по-рано в същия output. Това е neural text degeneration, назовано и обяснено от Holtzman et al. в статията, която въведе top-p.³ Моделът не е счупен; максимизирането на вероятността на последователността просто е грешна цел за отворен текст. Човешкото писане не е най-вероятната последователност от думи — то носи изненада, вероятността му на token се лута, спада и се възстановява — докато пътят с максимална вероятност е фиксирана точка, която, веднъж влязла, няма причина да излезе.

Затова sampling изобщо съществува. Това също така — и това е частта, която се пропуска — не е универсален закон. Глава 12 измери 24 от 24 верни отговора на двустъпкови текстови задачи с обикновен greedy decoding, а sampling при temperature 0,8 свали това до 81 %; после self-consistency похарчи шест пъти повече tokens, за да се изкачи обратно до мястото, където greedy вече беше. И двата факта са верни едновременно:

Повечето production prompts са от втория вид и се конфигурират като първия, защото temperature е оставен на каквото е използвал примерният код.

Sampling от пълното разпределение не е това, което някой реално прави, защото опашката е огромна и пълна с безсмислици. Нещо трябва да се отреже. Има два класически отговора и те се различават по един аспект, който решава всичко.

Top-k запазва фиксиран брой кандидати. Сортирате по вероятност, запазвате първите $k$, изхвърляте останалите, нормализирате отново.⁴ Top-p, наричан още nucleus sampling, запазва фиксирано количество маса: взимате tokens в низходящ ред, докато кумулативната им вероятност достигне $p$, и спирате.³ Формално nucleus е най-малкото множество $V_p$ с

Разликата звучи козметична, но не е, защото двата prompts, които изпращате в една и съща минута, имат напълно различни форми на разпределение. И двете са един и същ модел при temperature 1:

Едно фиксирано $k$, два провала в противоположни посоки. При фактологичния prompt $k = 40$ допуска 39 tokens, които заедно струват 3,6 % — пропуска боклук, включително кандидат с девет хилядни от процента, защото правилото брои слотове, а не доказателство. При story prompt същото $k = 40$ изхвърля 21 % от масата, която моделът наистина е присвоил, защото реалният nucleus там е широк 467 tokens.

Top-p кара точно едно число да върши и двете задачи. Задайте $p = 0.9$ и той запазва 1 token при първия prompt и 467 при втория, защото задава въпрос за разпределението, вместо да му налага брой. Вижте тази адаптация директно — същият cut, четири temperatures:

Този widget също изяснява едно погрешно схващане, което струва реални пари. При уверено разпределение top_p = 0.9 не е „малко разнообразие“. То е greedy. При temperature 1 водещият token тук държи 96,90 %, което вече е над 0,9, така че nucleus е широк един token и нищо друго никога не може да бъде изтеглено. Екипи задават top_p на 0,9, вярвайки, че са отпуснали нещо, и после се чудят защо всеки отговор е идентичен.

Задайте top-k вместо това и противоположният провал е също толкова видим:

Три различни механизма се движат под сходни имена, правят различни неща и разликата е измерима. Нека $c_i$ е броят пъти, в които token $i$ вече се е появил.

Същото дегенерирало продължение от по-рано, с приложен всеки един от тях. „Променени стъпки“ брои колко от 120-те стъпки на генериране са избрали различен token от този, който моделът без penalty би избрал. Run-ът тук е 120 стъпки срещу 140 в блока по-горе, затова базовата линия без penalty показва 85,5 %, а не 87,6 %:

Оттук следват три неща. Presence при 0,5 промени три решения от 120 и намали повторението с една четвърт — цикълът се държеше от шепа tokens. Frequency при 0,5 промени четири пъти повече решения за далеч по-голям ефект, защото множителят по брой продължава да расте, а presence константата — не. А CTRL penalty при широко копираната стойност 1,2 пренаписа 35 от 120 решения, което не е леко побутване; това е различен модел.

Това последно число подготвя провала, за който никой не предупреждава.

Кодът се повтаря. Таблиците се повтарят. Списъците се повтарят. Структурираният output се повтаря по дефиниция — това е структурата. Penalty не може да различи модел, заседнал в цикъл, от модел, който правилно извежда четвъртия ред на таблица, защото и двете изглеждат като token, който се появява отново.

Същите три задачи, генерирани по три начина:

Frequency penalty при 0,5 се оказа безвреден и при трите, което е полезен и леко изненадващ резултат, и казва нещо точно: щом нито едно решение не се е променило, структурните tokens трябва да са печелили позициите си с повече от изваденото от penalty, дори след като са се появили пет и шест пъти. CTRL penalty, който дели, вместо това ги измества, а ето какво произведе:

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

Подравняването се разпада: количеството padding във всяка клетка се променя от ред на ред, защото поредицата от интервали преди затварящата вертикална черта е точно видът повторение, което penalty е създаден да разбие. Козметично е, и струва шест допълнителни tokens. Случаят с Python не е козметичен:

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 избута модела от total — вече използвано в docstring — към total_sum, напълни output-а с измислени коментари, за да похарчи бюджета си за неизползвани tokens, и после влезе в триаргументен range със stride. Коментарът казва incrementing by 2 each time, което е грешно за сума от квадрати от 1 до $n$. Repetition penalty произведе неправилен код от prompt, на който без него беше отговорено правилно.

Правилото, което следва, е кратко: penalties са за отворена проза и трябва да са изключени за код, структуриран output, таблични данни и всичко със schema. Глава 18 е точно за тази втора категория.

Всяка реална имплементация прилага тези неща в една конкретна последователност:

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

Това не е произволно счетоводство и размяната на два етапа произвежда наистина различни разпределения. Две измервания, и двете върху фактологичния prompt.

Cut преди или след temperature. Nucleus се изчислява върху разпределението, което му е подадено, а temperature променя това разпределение радикално:

При $T = 2$ същата номинална настройка дава кандидатно множество от 32 966 или от 1, само според това кой етап върви първи. Ако някога сте се чудили защо повишаването на temperature „не прави нищо“ при един provider и унищожава output-а при друг със същите две числа, тази таблица е правдоподобен отговор.

Penalizing преди или след temperature. Да извадите penalty $\alpha$ и после да разделите на $T$ дава ефективен penalty $\alpha/T$; да разделите първо и после да извадите дава $\alpha$. С presence penalty 1,0, приложен към водещия token:

Идентични при $T = 1$, както трябва да бъдат. Различни с фактор 1,58 при $T = 2$. „Presence penalty 1,0“ не е добре дефинирано количество penalty, освен ако не знаете и къде се прилага temperature, а никое API не документира това.

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

Всеки provider приема различно подмножество от тези контроли, с различни диапазони, и игнорира останалите мълчаливо. Това не е абстрактно оплакване. Всяко приложение, което предлага избор на модел, трябва да запише разликите някъде, а файлът, в който го прави, е карта на несъвместимостта. Ето какво декларира един такъв каталог за един параметър при деветте text sources, които поддържа:

Думата е същата; скалата не е. „Temperature 1“ е непромененото разпределение при един и максимално позволената топлина при друг, а половината каталог не може да изрази стойността, която другата половина третира като неутрално-плюс-малко. Останалите копчета са също толкова неравни: записите за OpenAI, DeepSeek и xAI приемат presence и frequency penalties и никакъв topK; записите за Google, Meta, Cerebras и PaLM приемат topK и никакви penalties; Anthropic приема topK, topP и stop sequences и никакви penalties; и точно един от деветте — Mistral — приема seed. Изпращането на параметър, който provider не имплементира, обикновено не произвежда никаква грешка: заявката успява, копчето не прави нищо и вие заключавате, че настройката няма ефект.

И забележете какво е такъв файл: твърдение за чуждо API, написано в един конкретен ден, което после не се проверява от нищо. Каталог, който казва 0 до 1 за provider, който вече приема 0 до 2, тихо ще ограничава всяка заявка.

Още два контрола принадлежат към същото семейство. logprobs, когато се предлага, връща log-probabilities на избрания token и често първите няколко алтернативи — единственият прозорец, който получавате към разпределението, за което е тази глава, и основата на всяка confidence heuristic, изградена върху затворен модел. А maximum tokens плюс stop sequences прекратяват генерирането без никаква връзка с вероятността: твърд лимит и съвпадение на низ. И двете се появяват като finish_reason от Глава 14, където length означава, че отговорът ви е отрязан по средата на изречение от бюджет, не завършен от модела.

Задайте seed и sampling става възпроизводим. Тази част е реална и е лесна за проверка:

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

Идентични байт по байт в рамките на seed, различни между seed-ове, точно както е рекламирано. Значи seed фиксира случайното теглене в последния ред на функцията sample — кой token се избира при дадено разпределение.

Това, което не фиксира, е разпределението. И там е проблемът, защото векторът logits, който моделът ви произвежда, не е математически обект; той е output от милиарди floating-point събирания, а те имат ред.

Глава 2 остави този експеримент готов. Същият милион float32 числа, сумирани в различни групирания:

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

Вижте последния ред. Броят chunks променя отговора. Това не е любопитен детайл за numpy; това е механизмът, защото когато inference server разделя reduction върху повече или по-малко паралелни единици, той прави точно това. А server-ът разделя според това колко заявки обслужва.

Ето този ефект върху самия модел. Същият prompt, същият forward pass, единствената разлика е колко други заявки случайно са били в 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

Пуснат сам, моделът е напълно детерминистичен — двадесет pass-а, идентични до bit. Поставете идентичния prompt в batch с несвързани заявки и 97 % от неговите logits се променят. Нищо във вашата заявка не се промени. Пристигна чужда заявка.

Сега честната част, защото това обикновено се разказва сякаш е краят на историята. Промяна от $2.5 \times 10^{-5}$ променя output-а само ако два кандидат-tokens са били на такова разстояние един от друг. В 717 стъпки на генериране върху дванадесет prompts най-малката разлика между първите два logits беше $2.5 \times 10^{-3}$ — сто пъти по-голяма от perturbation — и нито една стъпка не беше достатъчно близо, за да се обърне. Така че при този модел, във float32, на лаптоп, batching премести всеки logit и не промени нито един token.

Това е описание на благоприятни условия, не успокоение, и една промяна в тези условия е достатъчна:

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

Шест от осем отговора се разминават, а един от тях деградира сериозно. Таблицата от Глава 2 казва защо: bfloat16 пази 7 mantissa bits, така че близо до logit magnitude 16 представимите стойности са на 0,125 една от друга — 16,0, после 16,125, после 16,25 — и rounding може да премести logit с до 0,0625. Междувременно 4,7 % от измерените по-горе стъпки на генериране имаха top-two gap под 0,1. Това е цялата разлика между двата експеримента: във float32 perturbation беше сто пъти по-малка от най-близкото решение, а в bfloat16 е със същия размер. Production inference върви в 16-bit, на хардуер с fused kernels и reduction orders, които никой не обещава да запази. Дали „численият шум е пренебрежим“ е въпрос за precision и hardware, не за модела.

И така, четирите причини, каталогизирани както обеща Глава 9:

Параметърът seed на OpenAI е честен за това по единствения възможен начин: идва заедно с поле system_fingerprint, което идентифицира backend configuration, а документацията казва, че детерминизмът е best-effort и че променен fingerprint означава, че резултатите може да се различават. Прочетете това като каквото е — provider ви казва, че контролира и четирите причини по-горе, че вие не контролирате нито една от тях и че единственото, което може да предложи, е да ви каже след факта, че нещо се е преместило.

Всичко тук беше за едно копче и последствията му. Отстъпете едно ниво назад и се появява по-трудният проблем: обектът, който настройвахме, е вероятностно разпределение, а вероятностните разпределения нямат интерфейс.

Function call има такъв. Ред в база данни има такъв. Handler POST, който очаква JSON body с три задължителни полета, има такъв и ще отхвърли всичко друго. Между модела и всеки друг компонент във вашата система стои договор, за който едната страна не може да дава обещания: моделът ще произведе нещо, изтеглено от разпределение, което сте оформили, но не сте фиксирали, а кодът от другата страна се нуждае от стойност с познат тип или хвърля грешка.

Мостът между тези два свята се строи от материала на тази глава, не от parsing и retries. Ако даден token би счупил изискваната структура, не го sample-вате с надежда — задавате logit му на $-\infty$, преди softmax изобщо да го види. Constrained decoding е маска върху същия вектор, който цяла глава преоформяхме, и превръща „моля, отговори в JSON“ от заявка в гаранция.

Глава 18 е този договор: tool calling, JSON Schema, structured outputs и какво е нужно, за да направите детерминистична система безопасна за изграждане върху вероятностна.

Всички измервания в тази глава идват от Qwen/Qwen2.5-0.5B-Instruct на CPU, float32 освен ако не е посочено друго, със sampling, имплементиран както е написан в секцията по избор, вместо делегиран на библиотека. Това е малък модел и конкретните стойности са негови; механизмите не са. How to generate text with different decoding methods на Von Platen (Hugging Face, 2020) е статията, спрямо която тази е измерена, и все още е най-доброто кратко въведение в същия материал. За секцията за детерминизъм: бележките на PyTorch за reproducibility описват какво seed фиксира и не фиксира на една машина, документацията на OpenAI за seed и system_fingerprint описва какво provider може и не може да обещае, а дискусията на Thinking Machines от 2025 г. за batch-invariant kernels е най-ясният публичен разказ защо поправянето на това на ниво inference server е възможно, но не е безплатно.