Температура, top-p і детермінізм, якого у вас немає

Розділ 4 ввів logit як ненормалізовану дійснозначну оцінку, по одній на клас. Розділ 8 змусив мовну модель виробляти по одній такій оцінці на кожен елемент словника. softmax перетворює цей вектор $\mathbf{z}$ на ймовірності:

Температура входить саме тут — назву запозичено зі статистичної фізики, де той самий параметр керує тим, наскільки різко розподіл Больцмана концентрується на станах із низькою енергією¹ — і вона ділить logits перед експонентою:

Це розташування і є всім механізмом, і варто витратити два рядки алгебри, щоб побачити, чому вона не могла бути ніде більше. Припустімо, ви спробували застосувати температуру до ймовірностей — помножити їх на $1/T$ і перенормалізувати. Ви отримали б

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

З цього розташування без жодної додаткової роботи випливають обидві межі. Коли $T \to 0$, найбільший logit відривається від решти, і $p$ схлопується до одного token з найвищою оцінкою: greedy decoding. Коли $T$ зростає, кожне $z_i/T$ прямує до нуля, кожна експонента прямує до 1, а розподіл сплющується до рівномірного по всьому словнику. Рівно при $T = 0$ формула ділить на нуль, тому кожна реалізація обробляє це окремо як арифметичний максимум — зокрема віджет нижче, який при $T \le 0.001$ перемикається на argmax.

Одне попередження, бо зіткнення назв справді плутає людей. У машинному навчанні є друга, не пов’язана з цим річ під назвою температура: temperature scaling, метод калібрування, який підбирає одне значення на валідаційному наборі, щоб упевненість класифікатора відповідала його точності.² Формула та сама, але до генерації це не має стосунку. Коли в статтях пишуть «temperature», часто мають на увазі саме це; цей розділ — ніколи.

Ось цей розподіл, з арифметикою перед вами. logits зафіксовані й правдоподібні, тож числа в тексті нижче можна звірити з тим, що ви бачите:

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

На реальному словнику це перестає бути курйозом і стає причиною, чому результат із високою температурою непридатний. Виміряно на Qwen/Qwen2.5-0.5B-Instruct, один forward pass, prompt вище; підраховано, скільки tokens потрібно, щоб накопичити задану частку маси ймовірності:

Прочитайте нижній рядок повільно. При $T = 2$, у питанні з рівно однією правильною відповіддю, 32 966 різних tokens ділять верхні 90 % маси ймовірності. Це не ширший творчий простір. Це модель, якій арифметика сказала вважати корейську частку й ідентифікатор C++ живими варіантами для слова після A:. Сміття у вступному блоці — прямий наслідок, і це не баг у моделі чи бібліотеці: це саме те, що попросив запит.

Корисний діапазон вузький і залежить від задачі, а не від смаку. У фактичному питанні відповідь — один 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, і чесна порада така: знайдіть її вимірюванням на вашій задачі, а не копіюванням числа з блогу.

Під усім цим ховається очевидне питання: якщо модель має розподіл ймовірностей і один 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 вікон уже з’являлися раніше в тому самому виводі. Це нейронна дегенерація тексту, названа й пояснена Holtzman та співавт. у статті, що представила top-p.³ Модель не зламана; максимізація ймовірності послідовності просто є неправильним об’єктивом для відкритого тексту. Людське письмо — не найімовірніша послідовність слів: у ньому є несподіванка, його ймовірність на token блукає, падає й відновлюється; натомість шлях максимальної ймовірності — це фіксована точка, яка, щойно в неї потрапили, не має причини її залишати.

Саме тому sampling взагалі існує. І також — це частина, яку часто опускають — це не універсальний закон. Розділ 12 виміряв 24 правильні відповіді з 24 у двокрокових словесних задачах зі звичайним greedy decoding, а sampling при температурі 0,8 знизив це до 81 %; self-consistency потім витратила вшестеро більше tokens, щоб повернутися туди, де greedy вже був. Обидва факти істинні одночасно:

Більшість production prompts належать до другого типу, але налаштовані як перший, бо температуру залишили такою, як у прикладі коду.

Sampling із повного розподілу — не те, що насправді хтось робить, бо хвіст величезний і повний нісенітниці. Щось треба обрізати. Є дві класичні відповіді, і вони відрізняються однією рисою, яка вирішує все.

Top-k залишає фіксовану кількість кандидатів. Відсортуйте за ймовірністю, залиште перші $k$, відкиньте решту, перенормалізуйте.⁴ Top-p, також зване nucleus sampling, залишає фіксовану кількість маси: беріть tokens у спадному порядку, доки їхня кумулятивна ймовірність не досягне $p$, і зупиніться.³ Формально nucleus — це найменша множина $V_p$ з

Різниця звучить косметично, але такою не є, бо два prompts, які ви надсилаєте в одну хвилину, мають цілком різні форми розподілу. Обидва нижче — та сама модель при температурі 1:

Один фіксований $k$, дві протилежні помилки. На фактичному prompt $k = 40$ пропускає 39 tokens, які разом варті 3,6 % — він впускає сміття, включно з кандидатом на дев’ять тисячних відсотка, бо правило рахує слоти, а не докази. На сюжетному prompt той самий $k = 40$ відкидає 21 % маси, яку модель справді призначила, бо справжній nucleus там має ширину 467 tokens.

Top-p змушує одне число виконувати обидві роботи. Встановіть $p = 0.9$ — і воно залишить 1 token на першому prompt та 467 на другому, бо ставить запитання про розподіл, а не нав’язує йому кількість. Подивіться на цю адаптацію напряму — той самий зріз, чотири температури:

Цей віджет також закриває хибне уявлення, яке варто назвати, бо воно коштує людям реальних грошей. На впевненому розподілі top_p = 0.9 — це не «трохи різноманітності». Це greedy. При температурі 1 провідний token тут має 96,90 %, що вже більше за 0,9, тож nucleus має ширину один token, і нічого іншого ніколи не може бути витягнуто. Команди ставлять top_p на 0,9, вважаючи, що щось послабили, а потім дивуються, чому кожна відповідь ідентична.

Натомість встановіть top-k — і протилежна помилка так само помітна:

Три різні механізми ходять під схожими назвами, роблять різні речі, і різницю можна виміряти. Нехай $c_i$ — це кількість разів, коли token $i$ уже з’являвся.

Те саме дегенеративне продовження з попереднього прикладу, із застосуванням кожного штрафу. «Змінені кроки» рахує, скільки зі 120 кроків генерації вибрали інший token, ніж вибрала б модель без штрафу. Тут прогін має 120 кроків проти 140 у блоці вище, тому baseline без штрафу показує 85,5 %, а не 87,6 %:

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

Останнє число підводить до збою, про який ніхто не попереджає.

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

Ті самі три задачі, згенеровані трьома способами:

Frequency penalty на 0,5 виявився нешкідливим у всіх трьох випадках, що є корисним і трохи несподіваним результатом, і він означає щось точне: якщо жодне рішення не змінилося, структурні tokens мусили вигравати свої позиції більше, ніж віднімав штраф, навіть після п’яти й шести появ. CTRL penalty, який натомість ділить, їх таки вибиває, і ось що він створив:

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

Вирівнювання розсипається: кількість padding усередині кожної комірки змінюється від рядка до рядка, бо послідовність пробілів перед завершальною вертикальною рискою — саме той тип повторення, який штраф покликаний ламати. Косметика, і вона коштувала шість додаткових 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,

Штраф зіштовхнув модель із total — уже використаного в docstring — на total_sum, наповнив вивід вигаданими коментарями, щоб витратити бюджет на невикористані tokens, а потім зайшов у триаргументний range із кроком. Коментар каже incrementing by 2 each time, що неправильно для суми квадратів від 1 до $n$. Repetition penalty створив неправильний код із prompt, на який без нього було дано правильну відповідь.

Правило звідси коротке: штрафи — для відкритої прози, і їх треба вимикати для коду, структурованого виводу, табличних даних і всього, що має schema. Розділ 18 саме про цю другу категорію.

Кожна реальна реалізація застосовує це в певній послідовності:

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

Це не довільна бухгалтерія, і перестановка двох етапів дає справді інші розподіли. Два вимірювання, обидва на фактичному prompt.

Обрізання до або після температури. Nucleus обчислюється на тому розподілі, який йому передали, а температура радикально змінює цей розподіл:

При $T = 2$ те саме номінальне налаштування дає множину кандидатів із 32 966 або з 1 — залежно лише від того, який етап виконується першим. Якщо ви колись дивувалися, чому підвищення температури «нічого не робить» в одного provider і руйнує вивід в іншого з тими самими двома числами, ця таблиця — правдоподібна відповідь.

Штраф до або після температури. Віднімання штрафу $\alpha$ і потім ділення на $T$ дає ефективний штраф $\alpha/T$; спочатку ділення, а потім віднімання дає $\alpha$. З presence penalty 1,0, застосованим до провідного token:

Ідентично при $T = 1$, як і має бути. Різниця в 1,58 раза при $T = 2$. «Presence penalty 1,0» не є добре визначеною величиною штрафу, якщо ви також не знаєте, де застосовується температура, і жоден 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 приймає іншу підмножину цих регуляторів, з іншими діапазонами, і мовчки ігнорує решту. Це не абстрактна скарга. Будь-який застосунок, що пропонує вибір моделі, мусить десь записати відмінності, і файл, у якому він це робить, є картою несумісності. Ось що один такий каталог декларує для одного параметра в дев’яти текстових джерелах, які він підтримує:

Слово те саме; шкала — ні. «Температура 1» в одного — незмінений розподіл, а в іншого — максимально дозволене тепло, і половина каталогу не може виразити значення, яке інша половина вважає нейтральним-плюс-трохи. Решта ручок так само нерівні: записи OpenAI, DeepSeek і xAI приймають presence і frequency penalties та не приймають topK; записи Google, Meta, Cerebras і PaLM приймають topK і не приймають штрафів; Anthropic приймає topK, topP і stop sequences та не приймає штрафів; і рівно один із дев’яти — Mistral — приймає seed. Надсилання параметра, який provider не реалізує, зазвичай не дає жодної помилки: запит успішний, ручка нічого не робить, і ви робите висновок, що налаштування не має ефекту.

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

Ще два регулятори належать до тієї самої родини. logprobs, там, де він пропонується, повертає log-probabilities вибраного token і часто кілька top alternatives — єдине вікно в розподіл, про який цей розділ, і основу кожної евристики впевненості на закритій моделі. А 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, який виробляє ваша модель, не є математичним об’єктом; це результат мільярдів додавань із рухомою комою, а в них є порядок.

Розділ 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 розбиває редукцію між більшою чи меншою кількістю паралельних блоків, він робить саме це. А 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

Запущена сама, модель ідеально детермінована — двадцять проходів, ідентичні до біта. Помістіть той самий prompt у batch із нерелевантними запитами — і 97 % її logits змінюються. У вашому запиті нічого не змінилося. Прийшов чийсь інший запит.

Тепер чесна частина, бо це зазвичай подають так, ніби на цьому історія закінчується. Зміна на $2.5 \times 10^{-5}$ змінює вивід лише якщо два кандидати tokens були на відстані не більшій за це. За 717 кроків генерації на дванадцяти prompts найменший розрив між двома top logits був $2.5 \times 10^{-3}$ — у сто разів більший за збурення — і жоден крок не був достатньо близьким, щоб перекинутися. Отже, на цій моделі, у 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 біт мантиси, тому біля величини logit 16 представні значення стоять на відстані 0,125 — 16,0, потім 16,125, потім 16,25 — і округлення може зсунути logit на до 0,0625. Тим часом 4,7 % виміряних вище кроків генерації мали top-two gap нижче 0,1. Це вся різниця між двома експериментами: у float32 збурення було в сто разів меншим за найближче рішення, а в bfloat16 воно того самого масштабу. Production inference працює в 16-bit, на hardware з fused kernels і порядками редукції, які ніхто не обіцяє зберігати. Чи є «числовий шум незначним» — це питання точності й hardware, а не моделі.

Отже, чотири причини, каталогізовані, як обіцяв розділ 9:

Параметр OpenAI seed чесний щодо цього єдиним можливим способом: він поставляється поруч із полем system_fingerprint, яке ідентифікує конфігурацію backend, а документація каже, що детермінізм — best-effort і що змінений fingerprint означає, що результати можуть відрізнятися. Читайте це як те, чим воно є: provider каже вам, що він контролює всі чотири причини вище, що ви не контролюєте жодної, і що єдине, що він може запропонувати, — повідомити вам після факту, що щось зрушило.

Усе тут було про одну ручку та її наслідки. Відступіть на рівень вище — і з’явиться складніша проблема: об’єкт, який ми налаштовували, є розподілом імовірностей, а розподіли ймовірностей не мають інтерфейсу.

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

Міст між цими двома світами будується з матеріалу цього розділу, а не з parsing і retries. Якщо token зламає потрібну структуру, ви не семплюєте його з надією — ви встановлюєте його logit у $-\infty$ до того, як softmax взагалі його побачить. Constrained decoding — це mask над тим самим вектором, який ми весь розділ переформовували, і він перетворює «будь ласка, відповідай у JSON» із прохання на гарантію.

Розділ 18 — про цей контракт: tool calling, JSON Schema, structured outputs і що потрібно, щоб deterministic system було безпечно будувати поверх probabilistic one.

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