Temperature، top-p اور وہ determinism جو آپ کے پاس نہیں

باب 4 نے logit کو ایک unnormalised حقیقی عددی score کے طور پر متعارف کرایا تھا، ہر class کے لیے ایک۔ باب 8 نے language model سے vocabulary کی ہر entry کے لیے ایک score پیدا کرایا۔ softmax اس vector $\mathbf{z}$ کو probabilities میں بدلتا ہے:

Temperature یہیں داخل ہوتی ہے — نام statistical physics سے لیا گیا ہے، جہاں یہی parameter control کرتا ہے کہ Boltzmann distribution اپنی low-energy states پر کتنی تیزی سے concentrate کرتی ہے¹ — اور یہ exponential سے پہلے logits کو divide کرتی ہے:

یہ placement ہی پورا mechanism ہے، اور دو لائنوں کی algebra سے دیکھنا قیمتی ہے کہ یہ کہیں اور ہو ہی نہیں سکتی تھی۔ فرض کریں آپ temperature کو probabilities پر apply کرنے کی کوشش کریں — انہیں $1/T$ سے scale کریں اور renormalise کریں۔ آپ کو ملے گا

constant cancel ہو جاتا ہے۔ Probabilities کو scale کرنے سے کچھ بھی نہیں ہوتا؛ distribution بغیر بدلے واپس آ جاتی ہے۔ Temperature صرف اس لیے اثر ڈالتی ہے کہ یہ exponent پر عمل کرتی ہے، جہاں exponentiate کرنے سے پہلے $T$ سے divide کرنا ہر probability کو $1/T$ کی power تک اٹھانے جیسا ہے — ایک nonlinear reshaping جو entries کے درمیان ratios بدلتی ہے، ان کا common scale نہیں۔

اس placement سے دونوں limits بغیر مزید محنت کے نکل آتے ہیں۔ جیسے $T \to 0$، سب سے بڑا logit باقی سب سے دور نکل جاتا ہے اور $p$ صرف single highest-scoring token پر collapse ہو جاتا ہے: greedy decoding۔ جیسے $T$ بڑھتا ہے، ہر $z_i/T$ صفر کی طرف جاتا ہے، ہر exponential 1 کی طرف جاتا ہے، اور distribution پوری vocabulary پر uniform کے قریب flatten ہو جاتی ہے۔ بالکل $T = 0$ پر formula zero سے divide کرتا ہے، اس لیے ہر implementation اسے arithmetic maximum کے طور پر special-case کرتی ہے — نیچے والا widget بھی، جو $T \le 0.001$ پر argmax پر switch کرتا ہے۔

ایک warning، کیونکہ ناموں کا ٹکراؤ واقعی confusion پیدا کرتا ہے۔ machine learning میں temperature نام کی ایک دوسری، unrelated چیز بھی ہے: temperature scaling، ایک calibration method جو validation set پر ایک value fit کرتی ہے تاکہ classifier کا confidence اس کی accuracy سے match کرے۔² formula وہی، generation سے کوئی تعلق نہیں۔ Papers جب "temperature" کہتے ہیں تو اکثر وہ والی مراد ہوتی ہے؛ یہ باب کبھی نہیں۔

یہ distribution ہے، arithmetic آپ کے سامنے۔ logits fixed اور plausible ہیں، اس لیے نیچے prose میں numbers کو آپ جو دیکھتے ہیں اس سے check کیا جا سکتا ہے:

␣banana عدد پوری دلیل کا miniature ہے: temperature بڑھانا model کو ایسا idea نہیں دے سکتا جو اس کے پاس تھا ہی نہیں۔ logits پہلے ہی computed ہیں، ranking پہلے ہی fixed ہے، اور temperature اسے بالکل preserve کرتی ہے — heat کی کوئی مقدار lower-scored token کو higher-scored token سے اوپر نہیں لے جاتی۔ یہ صرف mass کو اسی ranking میں نیچے redistribute کرتی ہے جو model نے خود پیدا کی۔ High temperature model کو زیادہ inventive نہیں بناتی؛ یہ اسے ان tokens کو emit کرنے کا زیادہ امکان دیتی ہے جنہیں اس نے bad score کیا تھا۔

Real vocabulary پر یہ curiosity نہیں رہتی بلکہ high-temperature output کے unusable ہونے کی وجہ بن جاتی ہے۔ Qwen/Qwen2.5-0.5B-Instruct پر measured، ایک forward pass، اوپر والا prompt، یہ count کرتے ہوئے کہ probability mass کے given share کو accumulate کرنے میں کتنے tokens لگتے ہیں:

نیچے والی row آہستہ پڑھیں۔ $T = 2$ پر، ایک ایسے سوال میں جس کا بالکل ایک درست جواب ہے، 32,966 مختلف tokens probability mass کے top 90 % کو share کرتے ہیں۔ یہ کوئی وسیع creative space نہیں۔ یہ ایک model ہے جسے arithmetic نے کہا ہے کہ A: کے بعد آنے والے word کے لیے Korean particle اور C++ identifier کو live options سمجھو۔ opening block کا garbage direct consequence ہے، اور یہ model یا library کا bug نہیں — request نے یہی مانگا تھا۔

Useful range تنگ ہے اور taste کے بجائے task پر depend کرتی ہے۔ factual question پر answer ایک token ہے اور تقریباً 1.2 سے اوپر کوئی بھی heat بلاوجہ error inject کرتی ہے۔ open-ended question پر واقعی ایک سے زیادہ اچھی continuation ہوتی ہے، اور کچھ heat ایسی variety خریدتی ہے جو fluent رہتی ہے:

"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 پر model نے proper name اور ایک ایسا sentence invent کیا ہے جو parse نہیں ہوتا۔ "ہر بار identical" اور "incoherent" کے درمیان band اس model پر اس task کے لیے تقریباً 0.6 سے 1.1 ہے، اور honest advice یہ ہے کہ اسے اپنے task پر measure کر کے تلاش کریں، blog post سے number copy کر کے نہیں۔

اس سب کے نیچے ایک obvious سوال چھپا ہے: اگر model کے پاس probability distribution ہے اور ایک token most likely ہے، تو ہمیشہ وہی کیوں نہ لیا جائے؟ Greedy decoding free ہے، reproducible ہے اور parameters نہیں مانگتی۔

کیونکہ result یہ ہے:

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 %

آٹھ sentences، ایک sentence۔ تقریباً دس میں سے نو four-token windows اسی output میں پہلے آ چکی تھیں۔ یہ neural text degeneration ہے، جسے Holtzman et al. نے اس paper میں name اور explain کیا جس نے top-p introduce کیا۔³ model broken نہیں؛ sequence probability کو maximise کرنا open-ended text کے لیے بس غلط objective ہے۔ Human writing words کی most likely sequence نہیں ہوتی — اس میں surprise ہوتا ہے، اس کی per-token probability بھٹکتی، گرتی اور recover کرتی ہے — جبکہ maximum-probability path ایک fixed point ہے جس میں داخل ہو کر نکلنے کی کوئی وجہ نہیں رہتی۔

اسی لیے sampling موجود ہے۔ اور، یہ وہ حصہ ہے جو اکثر چھوڑ دیا جاتا ہے، یہ universal law نہیں ہے۔ باب 12 نے plain greedy decoding کے ساتھ two-step word problems پر 24 میں سے 24 درست measure کیے، اور temperature 0.8 پر sampling نے اسے 81 % تک گرا دیا؛ self-consistency نے پھر چھ گنا tokens خرچ کیے تاکہ وہیں واپس آئے جہاں greedy پہلے ہی تھا۔ دونوں facts ایک ساتھ true ہیں:

زیادہ تر production prompts دوسری قسم کے ہوتے ہیں اور پہلی کی طرح configure ہوتے ہیں، کیونکہ temperature وہی رہ گئی جو example code نے استعمال کی تھی۔

Full distribution سے sampling وہ نہیں جو کوئی واقعی کرتا ہے، کیونکہ tail بہت بڑی ہے اور nonsense سے بھری ہے۔ کچھ نہ کچھ cut کرنا پڑتا ہے۔ دو classical جواب ہیں اور وہ ایک ایسے پہلو میں مختلف ہیں جو سب کچھ decide کرتا ہے۔

Top-k fixed number of candidates رکھتا ہے۔ probability کے حساب سے sort کریں، پہلے $k$ رکھیں، باقی discard کریں، renormalise کریں۔⁴ Top-p، جسے nucleus sampling بھی کہتے ہیں، mass کی fixed amount رکھتا ہے: tokens کو descending order میں لیتے جائیں جب تک ان کی cumulative probability $p$ تک نہ پہنچ جائے، پھر رک جائیں۔³ Formally، nucleus سب سے چھوٹا set $V_p$ ہے جس کے لیے

فرق cosmetic لگتا ہے مگر ہے نہیں، کیونکہ ایک ہی minute میں بھیجے گئے دو prompts کی distribution shapes مکمل طور پر مختلف ہو سکتی ہیں۔ یہ دونوں temperature 1 پر ایک ہی model ہیں:

ایک fixed $k$، opposite directions میں دو failures۔ factual prompt پر، $k = 40$ 39 tokens admit کرتا ہے جو مل کر 3.6 % کے قابل ہیں — یہ rubbish کو اندر آنے دے رہا ہے، بشمول ایک candidate جو percent کے نو ہزارویں حصے پر ہے، کیونکہ rule slots count کرتا ہے evidence نہیں۔ story prompt پر، وہی $k = 40$ اس mass کا 21 % پھینک دیتا ہے جو model نے واقعی assign کیا، کیونکہ وہاں real nucleus 467 tokens wide ہے۔

Top-p ایک number سے دونوں jobs کراتا ہے۔ $p = 0.9$ set کریں تو یہ first prompt پر 1 token اور second پر 467 رکھتا ہے، کیونکہ یہ distribution کے بارے میں سوال پوچھ رہا ہے، اس پر count impose نہیں کر رہا۔ اس adaptation کو براہ راست دیکھیں — same cut، چار temperatures:

یہ widget ایک misconception بھی settle کرتا ہے جس کا نام لینا ضروری ہے، کیونکہ یہ لوگوں کا حقیقی money cost کرتا ہے۔ confident distribution پر، top_p = 0.9 "ذرا سی variety" نہیں ہے۔ یہ greedy ہے۔ temperature 1 پر یہاں leading token 96.90 % رکھتا ہے، جو پہلے ہی 0.9 سے اوپر ہے، اس لیے nucleus ایک token wide ہے اور کچھ اور کبھی draw نہیں ہو سکتا۔ Teams top_p کو 0.9 set کرتی ہیں یہ سمجھ کر کہ انہوں نے کچھ loosen کیا ہے، پھر حیران ہوتی ہیں کہ ہر response identical کیوں ہے۔

اس کے بجائے top-k set کریں تو opposite failure اتنی ہی واضح ہے:

تین مختلف mechanisms ملتے جلتے ناموں کے تحت چلتے ہیں، وہ مختلف کام کرتے ہیں، اور فرق measurable ہے۔ فرض کریں $c_i$ وہ times ہے جتنی بار token $i$ پہلے آ چکا ہے۔

Earlier والی وہی degenerate continuation، ہر ایک applied کے ساتھ۔ "Steps altered" count کرتا ہے کہ 120 generation steps میں کتنی بار unpenalised model سے مختلف token pick ہوا۔ run یہاں 120 steps ہے، اوپر block میں 140 کے مقابلے میں، اسی لیے unpenalised baseline 87.6 % کے بجائے 85.5 % پڑھتا ہے:

تین چیزیں نکلتی ہیں۔ Presence 0.5 نے 120 میں سے تین decisions بدلے اور repetition کو ایک quarter کم کیا — loop چند tokens سے بندھا ہوا تھا۔ Frequency 0.5 نے چار گنا زیادہ decisions بدلے اور اثر کہیں بڑا تھا، کیونکہ count multiplier بڑھتا رہتا ہے جبکہ presence constant نہیں بڑھتا۔ اور widely-copied value 1.2 پر CTRL penalty نے 120 میں سے 35 decisions rewrite کیے، جو nudge نہیں؛ یہ different model ہے۔

یہ آخری number اس failure کی setup ہے جس کے بارے میں کوئی warn نہیں کرتا۔

Code repeat کرتا ہے۔ Tables repeat کرتی ہیں۔ Lists repeat کرتی ہیں۔ Structured output definition کے مطابق repeat کرتا ہے — structure یہی ہے۔ Penalty یہ فرق نہیں بتا سکتی کہ model loop میں stuck ہے یا table کی چوتھی row صحیح emit کر رہا ہے، کیونکہ دونوں میں token دوبارہ ظاہر ہوتا دکھتا ہے۔

وہی تین tasks، تین طریقوں سے generated:

Frequency penalty 0.5 تینوں پر harmless نکلی، جو useful اور قدرے surprising result ہے، اور یہ کچھ precise کہتی ہے: چونکہ کوئی decision نہیں بدلا، structural tokens اپنی positions penalty subtract ہونے کے بعد بھی، پانچ اور چھ بار آنے کے باوجود، اس سے زیادہ margin سے جیت رہے ہوں گے۔ CTRL penalty، جو اس کے بجائے divide کرتی ہے، انہیں dislodge کرتی ہے، اور اس نے یہ produce کیا:

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

alignment ٹوٹ جاتی ہے: ہر cell کے اندر padding کی amount row سے row بدلتی ہے، کیونکہ closing pipe سے پہلے spaces کی run بالکل وہی repetition ہے جسے penalty break کرنے کے لیے ہے۔ Cosmetic، اور اس نے چھ extra tokens cost کیے۔ Python case cosmetic نہیں:

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 نے model کو total سے — جو docstring میں already used تھا — total_sum پر دھکیل دیا، output کو invented comments سے pad کیا تاکہ اپنا budget unused tokens پر خرچ کرے، اور پھر stride کے ساتھ three-argument range میں چلا گیا۔ comment کہتا ہے incrementing by 2 each time، جو 1 سے $n$ تک squares کے sum کے لیے غلط ہے۔ ایک repetition penalty نے ایسے prompt سے incorrect code پیدا کیا جس کا answer اس کے بغیر correct تھا۔

اس سے نکلنے والا rule مختصر ہے: penalties open-ended prose کے لیے ہیں، اور code، structured output، tabular data اور schema والی ہر چیز کے لیے off ہونی چاہئیں۔ باب 18 اسی دوسری category کے بارے میں ہے۔

ہر real implementation یہ سب ایک specific sequence میں apply کرتی ہے:

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

یہ arbitrary bookkeeping نہیں، اور دو stages swap کرنے سے واقعی مختلف distributions بنتی ہیں۔ دو measurements، دونوں factual prompt پر۔

Temperature سے پہلے یا بعد cut کرنا۔ Nucleus اسی distribution پر compute ہوتا ہے جو اسے دی جاتی ہے، اور temperature اس distribution کو radically بدل دیتی ہے:

$T = 2$ پر وہی nominal setting candidate set کو 32,966 یا 1 بنا دیتی ہے، صرف اس بات پر depend کرتے ہوئے کہ کون سا stage پہلے run ہوتا ہے۔ اگر آپ نے کبھی سوچا کہ ایک provider پر temperature raise کرنا "کچھ نہیں کرتا" اور دوسرے پر انہی دو numbers کے ساتھ output destroy کر دیتا ہے، تو یہ table plausible answer ہے۔

Temperature سے پہلے یا بعد penalise کرنا۔ penalty $\alpha$ subtract کر کے پھر $T$ سے divide کرنے سے effective penalty $\alpha/T$ بنتی ہے؛ پہلے divide کر کے پھر subtract کرنے سے $\alpha$ بنتی ہے۔ leading token پر presence penalty 1.0 applied کے ساتھ:

$T = 1$ پر identical، جیسا ہونا چاہیے۔ $T = 2$ پر 1.58 کا factor apart۔ "Presence penalty 1.0" penalty کی well-defined amount نہیں جب تک آپ یہ بھی نہ جانتے ہوں کہ temperature کہاں apply ہوتی ہے، اور کوئی API اسے document نہیں کرتی۔

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 ان controls کا مختلف subset لیتا ہے، مختلف ranges کے ساتھ، اور باقی کو خاموشی سے ignore کرتا ہے۔ یہ abstract complaint نہیں۔ کوئی بھی application جو model کا choice offer کرتی ہے اسے differences کہیں لکھنے پڑتے ہیں، اور جس file میں یہ ہوتا ہے وہ incompatibility کا map ہے۔ یہ ہے وہ جو ایسا ہی ایک catalogue اپنے نو supported text sources کے across ایک single parameter کے لیے declare کرتا ہے:

لفظ وہی ہے؛ scale نہیں۔ ایک جگہ "temperature of 1" unmodified distribution ہے اور دوسری جگہ maximum permitted heat، اور catalogue کا آدھا حصہ وہ value express نہیں کر سکتا جسے دوسرا آدھا neutral-plus-a-bit سمجھتا ہے۔ باقی knobs بھی اتنے ہی uneven ہیں: OpenAI، DeepSeek اور xAI entries presence اور frequency penalties لیتے ہیں اور کوئی topK نہیں؛ Google، Meta، Cerebras اور PaLM entries topK لیتے ہیں اور penalties نہیں؛ Anthropic topK، topP اور stop sequences لیتا ہے اور penalties نہیں؛ اور نو میں سے بالکل ایک — Mistral — seed لیتا ہے۔ ایسا parameter بھیجنا جسے provider implement نہیں کرتا عموماً کوئی error پیدا نہیں کرتا: request succeed ہو جاتی ہے، knob کچھ نہیں کرتا، اور آپ conclude کرتے ہیں کہ setting کا کوئی effect نہیں۔

اور notice کریں کہ ایسی file کیا ہے: کسی اور کی API کے بارے میں ایک claim، ایک خاص دن لکھا گیا، جسے بعد میں کچھ verify نہیں کرتا۔ ایسا catalogue جو کسی provider کے لیے 0 to 1 کہتا ہے جبکہ وہ اب 0 to 2 accept کرتا ہے، ہر request کو خاموشی سے cap کرے گا۔

دو اور controls اسی family سے تعلق رکھتے ہیں۔ logprobs، جہاں offered ہو، chosen token کی log-probabilities اور اکثر top چند alternatives واپس کرتا ہے — اس distribution پر آپ کو ملنے والی واحد window جس کے بارے میں یہ chapter ہے، اور closed model پر بنے ہر confidence heuristic کی basis۔ اور maximum tokens plus stop sequences probability کے reference کے بغیر generation end کرتے ہیں: hard cap اور string match۔ دونوں باب 14 کے finish_reason کے طور پر surface ہوتے ہیں، جہاں length کا مطلب ہے کہ آپ کا answer budget سے mid-sentence cut ہوا، model نے finish نہیں کیا۔

Seed set کریں تو sampling reproducible ہو جاتی ہے۔ یہ part real ہے، اور verify کرنا آسان ہے:

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 کے اندر byte-identical، seeds کے across different، بالکل advertised۔ تو seed جس چیز کو fix کرتا ہے وہ اس sample function کی last line میں random draw ہے — distribution given ہو تو کون سا token pick ہوتا ہے۔

جسے یہ fix نہیں کرتا وہ distribution ہے۔ اور مسئلہ وہیں ہے، کیونکہ logits کا vector جو آپ کا model produce کرتا ہے mathematical object نہیں؛ یہ billions of floating-point additions کا output ہے، اور ان additions کا ایک order ہوتا ہے۔

باب 2 نے یہ experiment ready چھوڑا تھا۔ وہی million float32 numbers، different groupings میں summed:

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

last line دیکھیں۔ chunks کی تعداد answer بدل دیتی ہے۔ یہ numpy کے بارے میں curiosity نہیں؛ یہی mechanism ہے، کیونکہ جب inference server reduction کو زیادہ یا کم parallel units پر split کرتا ہے، وہ یہی کر رہا ہوتا ہے۔ اور server split اس کے مطابق کرتا ہے کہ وہ کتنی requests serve کر رہا ہے۔

model itself پر یہ effect دیکھیں۔ وہی prompt، وہی forward pass، صرف difference یہ کہ batch میں کتنی دوسری requests اتفاقاً موجود تھیں:

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

اکیلا run ہو تو model perfectly deterministic ہے — بیس passes، bit تک identical۔ identical prompt کو unrelated requests کے ساتھ batch میں رکھیں تو اس کے 97 % logits change ہوتے ہیں۔ آپ کی request میں کچھ نہیں بدلا۔ کسی اور کی request آ گئی۔

اب honest حصہ، کیونکہ اسے عموماً یوں بتایا جاتا ہے جیسے story یہیں ختم ہو۔ $2.5 \times 10^{-5}$ کی change output کو صرف تب بدلتی ہے جب دو candidate tokens ایک دوسرے سے اسی range میں ہوں۔ بارہ prompts کے across 717 generation steps میں، top two logits کے درمیان smallest gap $2.5 \times 10^{-3}$ تھا — perturbation سے سو گنا بڑا — اور کوئی step flip ہونے کے لیے enough close نہیں تھا۔ سو اس model پر، float32 میں، laptop پر، batching نے ہر logit move کیا اور کوئی token نہیں بدلا۔

یہ favourable conditions کی description ہے، reassurance نہیں، اور ان conditions میں ایک change کافی ہے:

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

آٹھ میں سے چھ answers diverge کرتے ہیں، اور ایک badly degrade ہوتا ہے۔ باب 2 کی table وجہ بتاتی ہے: bfloat16 mantissa کے 7 bits رکھتا ہے، اس لیے logit magnitude 16 کے قریب representable values 0.125 apart ہیں — 16.0، پھر 16.125، پھر 16.25 — اور rounding ایک logit کو 0.0625 تک move کر سکتی ہے۔ meanwhile اوپر measured generation steps میں 4.7 % کا top-two gap 0.1 سے کم تھا۔ دونوں experiments کے درمیان پورا فرق یہی ہے: float32 میں perturbation closest decision سے سو گنا چھوٹا تھا، اور bfloat16 میں وہ اسی size کا ہے۔ Production inference 16-bit میں چلتا ہے، ایسے hardware پر fused kernels اور reduction orders کے ساتھ جنہیں maintain کرنے کا کوئی وعدہ نہیں کرتا۔ آیا "numerical noise negligible ہے" precision اور hardware کے بارے میں سوال ہے، model کے بارے میں نہیں۔

تو، چار causes، جیسا باب 9 نے وعدہ کیا تھا:

OpenAI کا seed parameter اس بارے میں جتنا honest ہو سکتا ہے اتنا ہے: یہ system_fingerprint field کے ساتھ آتا ہے جو backend configuration identify کرتا ہے، اور documentation کہتی ہے کہ determinism best-effort ہے اور changed fingerprint کا مطلب ہے results differ ہو سکتے ہیں۔ اسے اسی طرح پڑھیں — provider آپ کو بتا رہا ہے کہ اوپر کی چاروں causes وہ control کرتا ہے، آپ ان میں سے کوئی control نہیں کرتے، اور جو ایک چیز وہ offer کر سکتا ہے وہ یہ ہے کہ after the fact بتا دے کہ کچھ move ہوا۔

یہاں سب کچھ ایک knob اور اس کے consequences کے بارے میں تھا۔ ایک level پیچھے ہٹیں تو harder problem ظاہر ہوتی ہے: جس object کو ہم tune کر رہے تھے وہ probability distribution ہے، اور probability distributions کا interface نہیں ہوتا۔

Function call کا interface ہوتا ہے۔ Database row کا interface ہوتا ہے۔ POST handler جو تین required fields والی JSON body expect کرتا ہے، اس کا interface ہوتا ہے، اور وہ باقی ہر چیز reject کر دے گا۔ model اور آپ کے system کے ہر دوسرے component کے درمیان ایک contract بیٹھا ہے جس کے ایک side promises نہیں کر سکتی: model کچھ produce کرے گا، ایک ایسی distribution سے draw کیا ہوا جسے آپ نے shape تو کیا ہے fix نہیں کیا، اور دوسری side کا code known type کی value چاہتا ہے ورنہ throw کرتا ہے۔

ان دو worlds کے درمیان bridge اس chapter کے material سے بنتا ہے، parsing اور retries سے نہیں۔ اگر کوئی token required structure کو break کرے گا، تو آپ اسے sample کر کے hope نہیں کرتے — آپ softmax کے دیکھنے سے پہلے اس کا logit $-\infty$ set کرتے ہیں۔ Constrained decoding اسی vector پر mask ہے جسے ہم نے پورا chapter reshape کیا ہے، اور یہ "please reply in JSON" کو request سے guarantee میں بدل دیتی ہے۔

باب 18 وہ contract ہے: tool calling، JSON Schema، structured outputs، اور ایک probabilistic system کے اوپر deterministic system کو safe بنانے کے لیے کیا چاہیے۔

اس chapter کی تمام measurements Qwen/Qwen2.5-0.5B-Instruct سے CPU پر آتی ہیں، stated کے علاوہ float32 میں، sampling کو optional section میں لکھے گئے طریقے سے implement کر کے، library کو delegate کر کے نہیں۔ وہ small model ہیں، اور specific values اسی کی ہیں؛ mechanisms نہیں۔ Von Platen کا How to generate text with different decoding methods (Hugging Face, 2020) وہ article ہے جس کے against یہ measured ہے اور اسی material کا اب بھی best short introduction ہے۔ determinism section کے لیے: PyTorch کے reproducibility notes describe کرتے ہیں کہ single machine پر seed کیا fix کرتا ہے اور کیا نہیں، OpenAI کی seed اور system_fingerprint کی documentation describe کرتی ہے کہ provider کیا promise کر سکتا ہے اور کیا نہیں، اور Thinking Machines کی 2025 discussion of batch-invariant kernels اس بات کا سب سے صاف public account ہے کہ inference-server level پر اسے fix کرنا possible ہے مگر free نہیں۔