Temperature, top-p i determinizm, którego nie masz

Rozdział 4 wprowadził logit jako nieznormalizowany wynik rzeczywisty, po jednym na klasę. Rozdział 8 sprawił, że model językowy wygenerował po jednym na każdą pozycję słownika. softmax zamienia ten wektor $\mathbf{z}$ na prawdopodobieństwa:

Temperature wchodzi tutaj — nazwa została zapożyczona z fizyki statystycznej, gdzie ten sam parametr kontroluje, jak ostro rozkład Boltzmanna koncentruje się na stanach o niskiej energii¹ — i dzieli logits przed funkcją wykładniczą:

To umiejscowienie jest całym mechanizmem i warto poświęcić dwie linie algebry, by zobaczyć, dlaczego nie mogłoby być gdzie indziej. Załóżmy, że próbujesz zastosować temperature do prawdopodobieństw — przeskalować je przez $1/T$ i zrenormalizować. Otrzymasz

Stała się skraca. Skalowanie prawdopodobieństw nie robi absolutnie nic; rozkład wraca bez zmian. Temperature działa tylko dlatego, że wpływa na wykładnik, gdzie dzielenie przez $T$ przed potęgowaniem jest tym samym, co podniesienie każdego prawdopodobieństwa do potęgi $1/T$ — nieliniowe przekształcenie, które zmienia stosunki między pozycjami, a nie ich wspólną skalę.

Z tego umiejscowienia wynikają oba graniczne przypadki bez żadnej dodatkowej pracy. Gdy $T \to 0$, największy logit ucieka reszcie i $p$ zapada się do pojedynczego najwyżej ocenionego token: greedy decoding. Gdy $T$ rośnie, każde $z_i/T$ zmierza do zera, każda wartość wykładnicza zmierza do 1, a rozkład spłaszcza się w stronę jednostajnego na całym słowniku. Dokładnie przy $T = 0$ wzór dzieli przez zero, więc każda implementacja obsługuje to specjalnym przypadkiem jako maksimum arytmetyczne — także widżet poniżej, który przy $T \le 0.001$ przełącza się na argmax.

Jedno ostrzeżenie, bo zderzenie nazw powoduje realne zamieszanie. W machine learning istnieje druga, niezwiązana rzecz nazywana temperature: temperature scaling, metoda kalibracji dopasowująca jedną wartość na zbiorze walidacyjnym tak, aby pewność klasyfikatora odpowiadała jego trafności.² Ten sam wzór, nic wspólnego z generowaniem. Artykuły mówiące „temperature” często mają na myśli właśnie to; ten rozdział nigdy.

Oto ten rozkład, z arytmetyką przed oczami. logits są stałe i wiarygodne, więc liczby w prozie poniżej można sprawdzić względem tego, co widzisz:

Liczba ␣banana to cały argument w miniaturze: podniesienie temperature nie może dać modelowi pomysłu, którego nie miał. logits są już obliczone, ranking jest już ustalony, a temperature zachowuje go dokładnie — żadna ilość ciepła nigdy nie przeniesie niżej ocenionego token ponad wyżej oceniony. Wszystko, co robi, to redystrybucja masy w dół rankingu, który model sam wyprodukował. Wysoka temperature nie czyni modelu bardziej pomysłowym; sprawia, że częściej emituje tokens, które sam ocenił jako złe.

Na prawdziwym słowniku przestaje to być ciekawostką i staje się powodem, dla którego wynik z wysoką temperature jest bezużyteczny. Pomiar na Qwen/Qwen2.5-0.5B-Instruct, jeden forward pass, powyższy prompt, zliczający, ile tokens potrzeba, aby zgromadzić daną część masy prawdopodobieństwa:

Przeczytaj ostatni wiersz powoli. Przy $T = 2$, w pytaniu z dokładnie jedną poprawną odpowiedzią, 32 966 różnych tokens dzieli górne 90 % masy prawdopodobieństwa. To nie jest szersza przestrzeń twórcza. To model, któremu arytmetyka kazała traktować koreańską partykułę i identyfikator C++ jako żywe opcje dla słowa po A:. Śmieci w bloku otwierającym są bezpośrednią konsekwencją i nie są błędem modelu ani biblioteki — to właśnie zamówiło żądanie.

Użyteczny zakres jest wąski i zależy od zadania, a nie od gustu. W pytaniu faktograficznym odpowiedzią jest jeden token i każde ciepło powyżej około 1.2 wstrzykuje błąd bez zysku. W zadaniu otwartym naprawdę istnieje więcej niż jedna dobra kontynuacja, a trochę ciepła kupuje różnorodność, która pozostaje płynna:

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

Przy 1.3 model wymyślił nazwę własną i zdanie, którego nie da się sparsować. Pasmo między „za każdym razem identycznie” a „niespójnie” wynosi mniej więcej od 0.6 do 1.1 dla tego modelu na tym zadaniu, a uczciwa rada brzmi: znajdź je przez pomiar na swoim zadaniu, nie przez kopiowanie liczby z wpisu na blogu.

Pod tym wszystkim kryje się oczywiste pytanie: jeśli model ma rozkład prawdopodobieństwa i jeden token jest najbardziej prawdopodobny, dlaczego nie zawsze go brać? Greedy decoding jest darmowe, powtarzalne i nie wymaga parametrów.

Bo wynik wygląda tak:

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 %

Osiem zdań, jedno zdanie. Prawie dziewięć na dziesięć okien czterech tokens pojawiło się już wcześniej w tym samym wyniku. To neural text degeneration, nazwane i wyjaśnione przez Holtzmana i współautorów w pracy, która wprowadziła top-p.³ Model nie jest zepsuty; maksymalizacja prawdopodobieństwa sekwencji jest po prostu złym celem dla tekstu otwartego. Ludzkie pisanie nie jest najbardziej prawdopodobną sekwencją słów — niesie zaskoczenie, jego prawdopodobieństwo per-token wędruje, spada i się podnosi — podczas gdy ścieżka o maksymalnym prawdopodobieństwie jest punktem stałym, który po wejściu nie ma powodu, by go opuścić.

Dlatego sampling w ogóle istnieje. I dlatego — a to jest część, którą zwykle się pomija — nie jest prawem uniwersalnym. Rozdział 12 zmierzył 24 na 24 poprawne odpowiedzi w dwuetapowych zadaniach słownych przy zwykłym greedy decoding, a sampling przy temperature 0.8 zbił to do 81 %; self-consistency potem wydało sześć razy więcej tokens, by wrócić tam, gdzie greedy już było. Oba fakty są prawdziwe naraz:

Większość produkcyjnych prompts należy do drugiego rodzaju, a jest konfigurowana jak pierwszy, bo temperature zostało na tym, czego używał przykładowy kod.

Sampling z pełnego rozkładu nie jest tym, co ktokolwiek naprawdę robi, bo ogon jest ogromny i pełen nonsensu. Coś trzeba odciąć. Istnieją dwie klasyczne odpowiedzi i różnią się jedną rzeczą, która decyduje o wszystkim.

Top-k zachowuje stałą liczbę kandydatów. Posortuj według prawdopodobieństwa, zachowaj pierwsze $k$, odrzuć resztę, zrenormalizuj.⁴ Top-p, nazywane też nucleus sampling, zachowuje stałą ilość masy: bierz tokens w kolejności malejącej, aż ich skumulowane prawdopodobieństwo osiągnie $p$, i zatrzymaj się.³ Formalnie nucleus jest najmniejszym zbiorem $V_p$ takim, że

Różnica brzmi kosmetycznie, ale taka nie jest, bo dwa prompts wysłane w tej samej minucie mają zupełnie różne kształty rozkładu. Oba poniżej to ten sam model przy temperature 1:

Jedno stałe $k$, dwie porażki w przeciwnych kierunkach. Na faktograficznym prompt $k = 40$ wpuszcza 39 tokens, które razem są warte 3,6 % — przepuszcza śmieci, w tym kandydata o dziewięciu tysięcznych procenta, bo reguła liczy miejsca, a nie dowody. Na prompt z opowieścią to samo $k = 40$ odrzuca 21 % masy, którą model naprawdę przypisał, bo rzeczywisty nucleus ma tam szerokość 467 tokens.

Top-p sprawia, że dokładnie jedna liczba robi oba zadania. Ustaw $p = 0.9$, a zachowa 1 token na pierwszym prompt i 467 na drugim, bo zadaje pytanie o rozkład, zamiast narzucać na niego liczebność. Zobacz tę adaptację bezpośrednio — to samo cięcie, cztery temperatures:

Ten widżet rozstrzyga też nieporozumienie warte nazwania, bo kosztuje ludzi realne pieniądze. Na pewnym rozkładzie top_p = 0.9 to nie „trochę różnorodności”. To greedy. Przy temperature 1 wiodący token ma tutaj 96,90 %, czyli już ponad 0.9, więc nucleus ma szerokość jednego token i nic innego nigdy nie może zostać wylosowane. Zespoły ustawiają top_p na 0.9, wierząc, że coś poluzowały, a potem dziwią się, dlaczego każda odpowiedź jest identyczna.

Ustaw zamiast tego top-k, a przeciwna porażka jest równie widoczna:

Trzy różne mechanizmy chodzą pod podobnymi nazwami, robią różne rzeczy, a różnica jest mierzalna. Niech $c_i$ będzie liczbą wystąpień token $i$ do tej pory.

Ta sama zdegenerowana kontynuacja co wcześniej, z zastosowaniem każdej kary. „Zmienione kroki” liczą, ile ze 120 kroków generowania wybrało inny token niż wybrałby model bez kary. Ten przebieg ma tutaj 120 kroków wobec 140 w bloku powyżej, dlatego baseline bez kary pokazuje 85,5 %, a nie 87,6 %:

Wynikają z tego trzy rzeczy. Presence przy 0.5 zmieniła trzy decyzje ze 120 i obcięła powtarzalność o jedną czwartą — pętlę trzymała garść tokens. Frequency przy 0.5 zmieniła cztery razy więcej decyzji i dała dużo większy efekt, bo mnożnik liczby wystąpień wciąż rośnie, a stała presence nie. A kara CTRL przy szeroko kopiowanej wartości 1.2 przepisała 35 ze 120 decyzji, co nie jest muśnięciem; to inny model.

Ta ostatnia liczba przygotowuje porażkę, przed którą nikt nie ostrzega.

Kod się powtarza. Tabele się powtarzają. Listy się powtarzają. Wynik strukturalny powtarza się z definicji — na tym polega struktura. Kara nie potrafi odróżnić modelu utkniętego w pętli od modelu poprawnie emitującego czwarty wiersz tabeli, bo oba wyglądają jak ponownie pojawiający się token.

Te same trzy zadania, wygenerowane trzema sposobami:

Frequency penalty przy 0.5 okazała się nieszkodliwa we wszystkich trzech, co jest użytecznym i lekko zaskakującym wynikiem, i mówi coś precyzyjnego: skoro żadna decyzja się nie zmieniła, strukturalne tokens musiały wygrywać swoje pozycje o więcej, niż kara odejmowała, nawet po pięciu i sześciu wystąpieniach. Kara CTRL, która zamiast tego dzieli, wypycha je z pozycji — oto co wyprodukowała:

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

Wyrównanie się rozpada: ilość wypełnienia wewnątrz każdej komórki zmienia się z wiersza na wiersz, bo seria spacji przed zamykającą kreską jest dokładnie tym rodzajem powtórzenia, które kara ma rozbijać. Kosmetyka, a kosztowała sześć dodatkowych tokens. Przypadek Python nie jest kosmetyczny:

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,

Kara zepchnęła model z total — już użytego w docstring — na total_sum, wypchała wynik wymyślonymi komentarzami, by wydać budżet na nieużyte tokens, a potem weszła w trzyargumentowe range z krokiem. Komentarz mówi incrementing by 2 each time, co jest błędne dla sumy kwadratów od 1 do $n$. Repetition penalty wyprodukowała niepoprawny kod z prompt, na który bez niej odpowiedź była poprawna.

Wynikająca z tego reguła jest krótka: kary są do otwartej prozy i powinny być wyłączone dla kodu, wyników strukturalnych, danych tabelarycznych i wszystkiego ze schematem. Rozdział 18 jest dokładnie o tej drugiej kategorii.

Każda realna implementacja stosuje te elementy w jednej konkretnej sekwencji:

kary → temperature → top-k → top-p → sample

To nie jest arbitralna księgowość, a zamiana dwóch etapów naprawdę produkuje inne rozkłady. Dwa pomiary, oba na faktograficznym prompt.

Cięcie przed albo po temperature. Nucleus jest liczony na tym rozkładzie, który dostaje, a temperature radykalnie zmienia ten rozkład:

Przy $T = 2$ to samo nominalne ustawienie daje zbiór kandydatów o rozmiarze 32 966 albo 1, wyłącznie w zależności od tego, który etap działa pierwszy. Jeśli kiedykolwiek zastanawiało cię, dlaczego podniesienie temperature „nic nie robi” u jednego dostawcy, a niszczy wynik u innego przy tych samych dwóch liczbach, ta tabela jest wiarygodną odpowiedzią.

Karanie przed albo po temperature. Odjęcie kary $\alpha$, a potem podzielenie przez $T$ daje efektywną karę $\alpha/T$; najpierw dzielenie, a potem odejmowanie daje $\alpha$. Przy presence penalty 1.0 zastosowanej do wiodącego token:

Identyczne przy $T = 1$, bo muszą takie być. Różnią się o czynnik 1,58 przy $T = 2$. „Presence penalty 1.0” nie jest dobrze zdefiniowaną ilością kary, jeśli nie wiesz też, gdzie stosowana jest temperature, a żadne API tego nie dokumentuje.

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

Każdy dostawca przyjmuje inny podzbiór tych kontrolek, z innymi zakresami, i resztę ignoruje po cichu. To nie jest abstrakcyjna skarga. Każda aplikacja oferująca wybór modelu musi gdzieś spisać różnice, a plik, w którym to robi, jest mapą niekompatybilności. Oto co jeden taki katalog deklaruje dla jednego parametru w dziewięciu obsługiwanych źródłach tekstu:

Słowo jest to samo; skala nie. „Temperature 1” jest niezmodyfikowanym rozkładem u jednego i maksymalnie dozwolonym ciepłem u innego, a połowa katalogu nie potrafi wyrazić wartości, którą druga połowa traktuje jako neutralną-plus-trochę. Reszta pokręteł jest równie nierówna: wpisy OpenAI, DeepSeek i xAI przyjmują presence i frequency penalties, ale nie topK; wpisy Google, Meta, Cerebras i PaLM przyjmują topK i żadnych kar; Anthropic przyjmuje topK, topP i sekwencje stop, ale żadnych kar; i dokładnie jeden z dziewięciu — Mistral — przyjmuje seed. Wysłanie parametru, którego dostawca nie implementuje, zwykle nie powoduje żadnego błędu: żądanie się udaje, pokrętło nic nie robi, a ty dochodzisz do wniosku, że ustawienie nie ma wpływu.

Zauważ też, czym jest taki plik: twierdzeniem o cudzym API, napisanym konkretnego dnia, którego później nic nie weryfikuje. Katalog mówiący 0 do 1 dla dostawcy, który teraz akceptuje 0 do 2, po cichu przytnie każde żądanie.

Do tej samej rodziny należą jeszcze dwie kontrolki. logprobs, tam gdzie jest oferowane, zwraca log-prawdopodobieństwa wybranego token i często kilka najlepszych alternatyw — jedyne okno na rozkład, o którym jest ten rozdział, oraz podstawę każdej heurystyki pewności zbudowanej na zamkniętym modelu. A maximum tokens plus sekwencje stop kończą generowanie bez żadnego odniesienia do prawdopodobieństwa: twardy limit i dopasowanie stringa. Oba wychodzą na powierzchnię jako finish_reason z rozdziału 14, gdzie length oznacza, że twoja odpowiedź została ucięta w połowie zdania przez budżet, a nie zakończona przez model.

Ustaw seed, a sampling staje się powtarzalny. Ta część jest prawdziwa i łatwo ją zweryfikować:

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

Bajtowo identyczne w ramach seed, różne między seeds, dokładnie jak obiecano. Więc seed naprawia losowanie w ostatniej linii funkcji sample — czyli który token zostanie wybrany przy danym rozkładzie.

Nie naprawia rozkładu. I tu zaczyna się problem, bo wektor logits produkowany przez twój model nie jest obiektem matematycznym; jest wynikiem miliardów dodawań zmiennoprzecinkowych, a one mają kolejność.

Rozdział 2 zostawił ten eksperyment gotowy. Ten sam milion liczb float32, sumowany w różnych grupowaniach:

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

Spójrz na ostatnią linię. Liczba chunks zmienia odpowiedź. To nie ciekawostka o numpy; to mechanizm, bo gdy serwer inferencji rozdziela redukcję na mniej lub więcej jednostek równoległych, robi dokładnie to. A serwer rozdziela w zależności od tego, ile żądań obsługuje.

Oto ten efekt na samym modelu. Ten sam prompt, ten sam forward pass, jedyna różnica to liczba innych żądań, które akurat znalazły się w 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

Uruchomiony sam model jest idealnie deterministyczny — dwadzieścia przebiegów, identyczne co do bitu. Umieść identyczny prompt w batch z niepowiązanymi żądaniami, a 97 % jego logits się zmienia. Nic w twoim żądaniu się nie zmieniło. Przyszło cudze żądanie.

Teraz uczciwa część, bo zwykle opowiada się to tak, jakby był to koniec historii. Zmiana $2.5 \times 10^{-5}$ zmienia wynik tylko wtedy, gdy dwa kandydackie tokens były od siebie w takiej odległości. W 717 krokach generowania przez dwanaście prompts najmniejsza luka między dwoma najwyższymi logits wyniosła $2.5 \times 10^{-3}$ — sto razy więcej niż perturbacja — i żaden krok nie był na tyle blisko, by się odwrócić. Zatem na tym modelu, w float32, na laptopie, batching poruszył każdy logit i nie zmienił żadnego token.

To opis sprzyjających warunków, nie uspokojenie, a wystarczy jedna zmiana tych warunków:

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

Sześć z ośmiu odpowiedzi się rozjeżdża, a jedna mocno się pogarsza. Tabela z rozdziału 2 mówi dlaczego: bfloat16 zachowuje 7 bitów mantysy, więc przy wielkości logit około 16 reprezentowalne wartości są oddalone o 0.125 — 16.0, potem 16.125, potem 16.25 — a zaokrąglenie może przesunąć logit nawet o 0.0625. Tymczasem 4,7 % zmierzonych wyżej kroków generowania miało lukę top-two poniżej 0.1. To cała różnica między dwoma eksperymentami: w float32 perturbacja była sto razy mniejsza niż najbliższa decyzja, a w bfloat16 jest tego samego rozmiaru. Produkcyjna inferencja działa w 16 bitach, na sprzęcie z fused kernels i kolejnościami redukcji, których nikt nie obiecuje utrzymać. To, czy „szum numeryczny jest pomijalny”, jest pytaniem o precyzję i sprzęt, nie o model.

Zatem cztery przyczyny, skatalogowane zgodnie z obietnicą z rozdziału 9:

Parametr seed OpenAI jest co do tego uczciwy w jedyny możliwy sposób: przychodzi razem z polem system_fingerprint identyfikującym konfigurację backendu, a dokumentacja stwierdza, że determinizm jest best-effort i że zmieniony fingerprint oznacza, iż wyniki mogą się różnić. Czytaj to jako to, czym jest — dostawca mówi ci, że kontroluje wszystkie cztery powyższe przyczyny, że ty nie kontrolujesz żadnej, i że jedyne, co może zaoferować, to powiedzieć ci po fakcie, że coś się ruszyło.

Wszystko tutaj dotyczyło pokrętła i jego konsekwencji. Cofnij się o poziom, a pojawi się trudniejszy problem: obiekt, który stroiliśmy, jest rozkładem prawdopodobieństwa, a rozkłady prawdopodobieństwa nie mają interfejsu.

Function call go ma. Wiersz bazy danych go ma. Handler POST oczekujący ciała JSON z trzema wymaganymi polami go ma i odrzuci wszystko inne. Między modelem a każdym innym komponentem twojego systemu siedzi kontrakt, o którym jedna strona nie może składać obietnic: model wyprodukuje coś, wylosowane z rozkładu, który ukształtowałeś, ale którego nie ustaliłeś, a kod po drugiej stronie potrzebuje wartości znanego typu albo rzuca wyjątek.

Most między tymi dwoma światami buduje się z materiału tego rozdziału, a nie z parsowania i ponawiania prób. Jeśli token złamałby wymaganą strukturę, nie samplujesz go z nadzieją — ustawiasz jego logit na $-\infty$, zanim softmax w ogóle go zobaczy. Constrained decoding jest maską na tym samym wektorze, który przez cały rozdział przekształcaliśmy, i zamienia „odpowiedz proszę w JSON” z prośby w gwarancję.

Rozdział 18 jest tym kontraktem: tool calling, JSON Schema, structured outputs i to, czego potrzeba, by deterministyczny system dało się bezpiecznie zbudować na probabilistycznym.

Wszystkie pomiary w tym rozdziale pochodzą z Qwen/Qwen2.5-0.5B-Instruct na CPU, float32 jeśli nie zaznaczono inaczej, z sampling zaimplementowanym tak, jak w sekcji opcjonalnej, a nie delegowanym do biblioteki. To mały model i konkretne wartości są jego; mechanizmy nie. Artykuł von Platena How to generate text with different decoding methods (Hugging Face, 2020) jest tekstem, względem którego mierzony jest ten rozdział, i nadal najlepszym krótkim wprowadzeniem do tego samego materiału. Dla sekcji o determinizmie: notatki PyTorch o reprodukowalności opisują, co seed naprawia, a czego nie naprawia na jednej maszynie; dokumentacja OpenAI dla seed i system_fingerprint opisuje, co dostawca może, a czego nie może obiecać; a dyskusja Thinking Machines z 2025 roku o batch-invariant kernels jest najklarowniejszym publicznym opisem tego, dlaczego naprawienie tego na poziomie serwera inferencji jest możliwe, ale nie darmowe.