Inference کو سستا بنانا: KV cache، Batching اور Quantization

ایک token generate کرنے کے لیے decoder-only transformer اب تک کی پوری sequence لیتا ہے، اسے ہر layer سے گزارتا ہے، اور آخری position سے probability distribution پڑھتا ہے۔ پھر وہ منتخب token append کرتا ہے اور دوبارہ یہی کرتا ہے۔ یہ description درست ہے، اور slow run یہی کرتی ہے۔

یہ غیر معمولی حد تک wasteful بھی ہے، اور وجہ Chapter 9 کا causal mask ہے۔ position 7 کے key اور value vectors position 7 کے input اور اس سے پہلے والی positions سے compute ہوتے ہیں۔ جب position 8 آتی ہے، position 7 اسے دیکھ نہیں سکتی — causal کا یہی مطلب ہے — اس لیے position 7 کے key اور value بالکل وہی numbers رہتے ہیں جو پہلے تھے۔ slow run پھر بھی انہیں ہر step پر دوبارہ compute کرتی ہے۔

تو انہیں store کر لیں۔ یہ store key-value cache ہے، language model serving میں سب سے زیادہ consequential optimisation:

out = model(prompt_ids, use_cache=True)          # prefill: the whole prompt
past = out.past_key_values                        
nxt = out.logits[:, -1].argmax(-1, keepdim=True)

for _ in range(n - 1):
    out = model(nxt, past_key_values=past, use_cache=True)   
    past = out.past_key_values                                
    nxt = out.logits[:, -1].argmax(-1, keepdim=True)

دیکھیں loop کے اندر model کو کیا feed کیا جاتا ہے: nxt، ایک token۔ sequence نہیں۔ نئے token کا query ہر cached key کے خلاف attend کرتا ہے، اور cached keys بدلنے والی تھیں ہی نہیں۔ یہ approximation نہیں — اوپر identical-output check کا یہی مقصد ہے۔ cache quality کو speed کے بدلے trade نہیں کرتا؛ یہ redundant arithmetic حذف کرتا ہے۔

scaling صاف دیکھنے کے لیے transformer کو الگ کریں اور $d = 64$ کے ساتھ ایک single attention head کو time کریں، generation کا ایک step دونوں طریقوں سے compute کر کے:

دائیں طرف والا column وجہ ہے۔ recomputing ہر step پر مکمل $n \times n$ attention matrix بناتی ہے — Chapter 9 کے asymptotic-notation box کا $O(n^2)$، ہر token کے لیے ایک بار ادا کیا گیا۔ cache کے ساتھ آپ اس کے بجائے $1 \times n$ row بناتے ہیں: 4,096 tokens پر scores کے 67 MB کے مقابلے میں 16 KB۔

milliseconds کے بجائے multiply-accumulates گننے سے machine argument سے نکل جاتی ہے۔ cold start سے $T$ tokens generate کرنے کے لیے:

ہر step پر cached version context میں linear ہے اور uncached version quadratic؛ پوری generation پر جمع کریں تو $O(T^2)$ کے مقابلے میں $O(T^3)$، ratio بغیر حد کے بڑھتا ہے۔ opening میں نو گنا فرق 48 tokens پر measure کیا گیا تھا — اس table کی پہلی row سے بھی کم۔

cache یہ بھی بدلتا ہے کہ memory میں کیا ہونا ضروری ہے۔ 8 GB laptop GPU پر fp16 میں 256 tokens generate کرتے ہوئے، allocator کی peak سے resident weights subtract کرنے پر:

8.3 گنا زیادہ memory، انہی tokens کو زیادہ آہستہ produce کرنے کے لیے خرچ ہوئی۔ یہ Chapter 5 میں کیا گیا وعدہ ہے، مگر ایک unexpected direction سے آتا ہوا: وہاں reverse-mode autodiff کو backward pass کے لیے ہر intermediate کو alive رکھنا پڑتا تھا، اور activations training memory پر غالب تھیں۔ inference میں backward pass نہیں اور اس کے لیے retain کرنے کو کچھ نہیں — اس لیے memory پر غالب چیز cache ہے، اور یہ unavoidable cost کے بجائے deliberate choice ہے۔

fast run کو دوبارہ دیکھیں: اس کا پہلا token باقی سینتالیس سے مختلف behave کرتا ہے۔

prefill, 40 prompt tokens : 1.0224 s   ->  25.6 ms per token
decode,  47 steps         : 0.1665 s mean per step

prompt کی cost 25.6 ms per token تھی اور ہر generated token کی cost 166 ms۔ وہی model، وہی hardware، وہی weights، per token چھ گنا فرق — اور یہ اس سمت جاتا ہے جس کی اکثر لوگ توقع نہیں کرتے۔ prompt سستا حصہ ہے۔ Generation دو phases میں بٹتی ہے جن کی physics واقعی مختلف ہے:

دونوں halves measurable ہیں۔ Prefill، $P$ tokens پر ایک pass:

Decode، $C$ کے cache کے خلاف ایک token:

دوسری table کو دو بار پڑھیں۔ context کے 16 tokens سے 1,024 تک جانا — attend کرنے کے لیے چونسٹھ گنا زیادہ history — step کی cost کو کسی measurable حد تک نہیں بدلتا۔ cache کے خلاف attention حقیقی کام ہے، مگر ایک vector produce کرنے کے لیے نصف ارب weights کو memory bus سے گھسیٹنے کی fixed cost کے سامنے یہ بہت چھوٹا ہے۔ یہی fixed cost اگلے section میں ہر چیز کی وجہ ہے۔

یہ دو phases ہر serving system کے report کیے گئے دو numbers کی origin ہیں۔ Time to first token essentially prefill ہے، اور یہ prompt کے ساتھ بڑھتا ہے، اسی لیے long conversation شروع ہونے میں سست محسوس ہوتی ہے۔ Tokens per second $1/\text{decode step}$ ہے، اور یہ تقریباً constant ہے، اسی لیے reply پھر برابر flow کرتی ہے۔ ایسی chat جو آہستہ شروع ہو اور پھر smoothly stream کرے، rendering trick نہیں۔ یہ یہی دو tables ہیں۔

cache arithmetic کو memory کے بدلے trade کرتا ہے، اور جس memory کی اسے ضرورت ہے وہ چھوٹی نہیں۔ context میں ہر token کے لیے، ہر layer ہر key-value head پر ایک key vector اور ایک value vector رکھتی ہے:

2 keys اور values کے لیے ہے؛ باقی سب architecture ہے۔ اس chapter میں measured model کے لیے — 24 layers، 14 query heads، 2 key-value heads، head dimension 64 — fp16 میں یہ $2 \times 24 \times 2 \times 64 \times 2 = 12{,}288$ bytes per token ہے۔

اس field میں formulae اکثر factor of two سے غلط نکلتے ہیں، اس لیے اس پر یقین کرنے کے بجائے allocator کے خلاف check کریں:

KV cache tensors per layer: (1, 2, 295, 64) float16
measured: 3,624,960 bytes for 295 tokens = 12,288 bytes/token
formula : 2 * 24 * 2 * 64 * 2                = 12,288 bytes/token

Exact، اور tried ہر shape میں exact رہتا ہے:

آخری تین rows دوبارہ دیکھنے کے قابل ہیں۔ 2,048 tokens each کے ساتھ بتیس users، 1,024 کے ساتھ چونسٹھ، 512 کے ساتھ ایک سو اٹھائیس — cache ہر case میں 768 MB ہے، کیونکہ تینوں میں 65,536 tokens resident ہیں۔ cache صرف resident tokens کی total number پر depend کرتا ہے، اس پر نہیں کہ وہ users میں کیسے distributed ہیں۔ یہی fact batching section کی foundation ہے۔

Chapter 9 نے multi-query اور grouped-query attention introduce کیا اور وجہ اس chapter تک defer کی۔ وجہ وہ formula ہے، اور خاص طور پر اس میں $H_{kv}$۔

Standard multi-head attention ہر query head کو اپنے key اور value heads دیتا ہے۔ یہاں model کے 14 query heads ہیں؛ full multi-head attention کے ساتھ اس کا cache $2 \times 24 \times 14 \times 64 \times 2 = 86{,}016$ bytes per token ہوتا — 12 KB کے بجائے 84 KB، بالکل سات گنا زیادہ، query heads اور key-value heads کے ratio کے برابر۔

Multi-query attention¹ اسے حد تک لے جاتا ہے: تمام query heads ایک single key-value head share کرتے ہیں۔ Grouped-query attention² وہ compromise ہے جو جیتا — کچھ key-value heads، جن میں ہر ایک query heads کے group سے shared — کیونکہ MQA کی quality loss real تھی اور GQA کی نہیں۔ دونوں arithmetic نہیں خریدتے۔ وہ اس formula کو integer سے divide کرنے کے لیے موجود ہیں، اور long contexts نے cache کو binding constraint بنایا تو یہ پوری industry میں پھیل گئے۔

اور یہ جلدی ہوتا ہے۔ 32 layers اور dimension 128 کے 8 key-value heads والے 7B-class model کے لیے، fp16 میں cache 128 KB per token ہے:

اس model کے اپنے weights fp16 میں 13.0 GB ہیں، chapter کے آخر کی table والا figure۔ تو 128,000-token context پر، ایک user کا cache model سے بڑا ہے۔ یہی arithmetic Chapter 16 money میں بدلتا ہے، اور یہی وجہ ہے کہ long conversation محض slow نہیں ہوتی — وہ request alive رہنے تک machine کا ایک fixed slice occupy کرتی ہے۔

Decode memory-bound ہے: weights bus سے گھسیٹے جاتے ہیں تاکہ ایک token produce ہو، اور arithmetic units idle رہتے ہیں۔ تو اسی step میں زیادہ work ڈالیں۔ کئی requests ایک ساتھ run کریں، اور weights، ایک بار read ہو کر، ان سب کو serve کریں۔ اسی model پر measured، ہر request 64-token cache رکھتی ہوئی اور ایک token decode کرتی ہوئی:

دائیں طرف کے دونوں columns کو ایک دوسرے کے مقابل پڑھیں، کیونکہ یہی اصل بات ہے۔ ایک request سے سولہ تک جانا throughput کو 6.0 سے multiply کرتا ہے اور کسی individual request کے wait کو 2.67 سے multiply کرتا ہے۔ batch نے server کو بہتر اور ہر user کو بدتر بنایا۔

یہ کوئی bug نہیں جسے tune کر کے ختم کیا جائے؛ یہی trade ہے، اور دونوں sides پر اس کے نام ہیں۔ Latency وہ ہے جو reply کا انتظار کرتا انسان experience کرتا ہے۔ Throughput وہ ہے جس سے invoice divide ہوتا ہے۔ کوئی setting دونوں کو بہتر نہیں کرتی۔

یہ بھی نوٹ کریں کہ یہ کہاں رک جاتا ہے۔ 16 سے 32 تک، throughput 9 % gain کرتا ہے جبکہ latency تقریباً double ہو جاتی ہے: step memory-bound رہنا چھوڑ کر compute-bound ہو چکا ہے، اور اس knee کے بعد batch کچھ نہیں خریدتا۔ ہر deployment میں ایسا knee ہوتا ہے؛ اس کی location آپ کے setup پر measure کرنی پڑتی ہے، مگر اس کا existence نہیں۔

batch کرنے کا naive طریقہ یہ ہے کہ $B$ requests collect کریں، انہیں together run کریں، اور جب سب done ہوں تو return کریں۔ مگر وہ together finish نہیں ہوتیں: کچھ replies بیس tokens کی ہیں اور کچھ پانچ سو کی۔ fixed batch اپنے longest member کے finish ہونے تک چلتا ہے، اور ہر finished request تب تک اپنی slot occupy کرتی رہتی ہے، padding contribute کرتی ہوئی۔

64 requests لیں جن کی output lengths میں realistic skew ہو — median 18 tokens، longest 231، total 1,874 — اور آٹھ slots کے measured per-step cost پر دونوں policies simulate کریں:

Throughput 1.6x بہتر ہوتا ہے۔ Mean latency دس گنا سے زیادہ بہتر ہوتی ہے، کیونکہ static batching کے تحت ایک request جو چار steps میں finish ہوئی تھی، پھر بھی 231-token neighbour کا انتظار کرتی ہے اس سے پہلے کہ کوئی اسے سن سکے۔

Continuous batching³ fix ہے، اور یہ اتنی ہی simple ہے جتنی سنائی دیتی ہے: batch کوئی group نہیں بلکہ slots کا set ہے، اور جو slot free ہو وہ اگلے ہی step پر next queued request admit کر لیتی ہے۔ scheduler ایک request کے بجائے ایک token کی granularity پر کام کرتا ہے۔ production میں ہر serving stack اب یہی کرتا ہے۔

اس کا دوسرا half cache ہے۔ آتی جاتی slots cache memory کو fragmented چھوڑتی ہیں، اور ہر slot کے maximum possible context کو reserve کرنا reservation کا زیادہ تر حصہ waste کرتا ہے۔ PagedAttention⁴ operating systems سے جواب ادھار لیتا ہے: cache کو fixed-size blocks میں store کریں، ہر sequence کے لیے block table کے ساتھ، تاکہ sequence کا cache physically scattered ہو سکتا ہے مگر logically contiguous رہے — جس سے shared prefix والی دو sequences اسے hold کرنے والے blocks بھی share کر سکتی ہیں۔ vLLM اسی پر built ہے، اور اسی لیے serving engine دراصل transformer attached ایک memory allocator ہے۔

bill کا دوسرا half weights themselves ہیں۔ نصف ارب parameters چار bytes each پر 1.98 GB ہیں؛ دو bytes پر 0.99 GB؛ ایک byte پر 0.49 GB۔ ہر weight کے fewer bits model کو disk پر چھوٹا کرتے ہیں، memory میں چھوٹا کرتے ہیں، اور — چونکہ decode bandwidth-bound ہے — ہر step کو faster بناتے ہیں، کیونکہ move کرنے کے لیے bytes کم ہیں۔

سب سے simple scheme symmetric absolute-maximum quantization ہے، اور یہ تین lines میں fit ہوتی ہے:

qmax  = 2 ** (bits - 1) - 1
scale = W.abs().max() / qmax                        
Wq    = torch.round(W / scale).clamp(-qmax - 1, qmax)
W_hat = Wq * scale                                  # dequantized

scale چنیں تاکہ largest weight largest integer پر map ہو، divide کریں، round کریں، integers اور scale store کریں۔ reconstruct multiplying back سے کریں۔ اس میں clever کچھ نہیں، اور یہ کام کرتا ہے — عین اس وقت تک جب نہیں کرتا۔

model کے real weights پر measured: تمام 168 projection matrices، 357.8 million parameters، relative error $\lVert W - \hat{W}\rVert / \lVert W \rVert$:

چوتھی row collapse ہے۔ worst matrix پر 0.99 کا relative error یعنی reconstruction اصل کا تقریباً کچھ بھی retain نہیں کرتی — matrix تقریباً right magnitude کے noise سے replace ہو گئی ہے۔ cause ایک single matrix پر اسی experiment میں visible ہے:

model.layers.12.mlp.down_proj.weight   (896 x 4864)
mean |w| 0.01386   std 0.01822   max |w| 0.43945   max/std 24.1
weights beyond 6 sigma: 692 of 4,358,144   (0.016 %)

چھ ہزار میں ایک weight چھ standard deviations سے باہر بیٹھا ہے، اور largest 24 out ہے۔ پوری matrix کے لیے single scale کے ساتھ، وہ ایک weight ان تمام 4.3 million weights کے لیے step size set کرتا ہے۔ 8 bits پر 256 steps ہیں اور typical weight پھر بھی meaningful step پر land کرتا ہے۔ 4 bits پر 16 ہیں، outermost ایک ایسی value کے لیے reserved ہے جو تقریباً کسی کے پاس نہیں، اور ordinary weights — یعنی تقریباً سب — دو یا تین distinct levels پر round ہو جاتے ہیں۔

اس row کے بعد ہر چیز مختلف granularities پر یہی repair ہے: scale کو چھوٹا territory دیں۔ per output row error کو 3.4 سے divide کرتی ہے؛ 128 consecutive weights کے per group اسے دوبارہ divide کرتا ہے۔ cost bookkeeping ہے — 128 کے ہر group کے لیے 16-bit scale $4 + 16/128 = 4.125$ bits per weight کے بجائے 4 — اور یہ gap کا زیادہ تر حصہ واپس خرید لیتا ہے۔

NF4 دوسری طرف سے حملہ کرتا ہے۔⁵ levels کا equally spaced ہونا ضروری نہیں۔ block کے اندر weights تقریباً normally distributed ہوتے ہیں، اس لیے سولہ levels کو normal distribution کے quantiles کے طور پر choose کریں: zero کے قریب dense جہاں weights واقعی ہیں، tails میں sparse جہاں وہ نہیں۔ وہی four bits، وہی block scaling، چھوٹے block پر — group-128 کے 4.125 کے مقابلے میں 4.25 bits per weight — اور measured error 0.1323 سے 0.0952 تک گر جاتا ہے، 28 % lower۔ اس کا کچھ حصہ finer block ہے اور باقی mass جہاں ہے وہاں levels رکھنے سے ہے، اور دونوں کو separate کرنے کے لیے third row چاہیے ہو گی۔

Chapter 2 کا floating-point box ایک وعدے پر ختم ہوا تھا: کہ یہ chapter weights کو 8 اور 4 bits پر quantize کرے گا اور چند outlier features پائے گا جو squeezed ہونے سے انکار کریں گے۔ یہ رہے، اور یہ بتاتے ہیں کہ activations پر “بس numbers round کر دو” کبھی کام کیوں نہیں کرنے والا تھا۔

اوپر والے weights badly behaved تھے۔ activations ایک مختلف league میں ہیں۔ ایک ordinary 84-token prompt لیں، ہر layer پر residual stream capture کریں، اور 896 dimensions میں سے ہر dimension کی reached largest magnitude measure کریں:

Dimension 62 1,579.6 تک پہنچتا ہے جبکہ median dimension کبھی 1.6 سے اوپر نہیں جاتا۔ یہ ایک token یا ایک layer کا fluke نہیں: یہی dimension layer 4 پر موجود ہے اور layer 20 پر بھی تقریباً اسی value کے ساتھ موجود ہے۔ یہ outlier features ہیں،⁶ اور یہ systematic ہیں — trained model کی property، input کی نہیں۔

layer 16 پر ان 896 per-dimension maxima کا histogram shape کو unmistakable بنا دیتا ہے:

     0 -      1 | ######################################## 254
     1 -      2 | ######################################## 283
     2 -      4 | ######################################## 226
     4 -      8 | ######################################## 93
     8 -     16 | ##################                       18
    16 -     32 | #########                                9
    32 -     64 | #######                                  7
    64 -    128 | #####                                    5
   128 -    256 |                                          0
   256 -    512 |                                          0
   512 -   1024 |                                          0
  1024 -   4096 | #                                        1

نو سو dimensions 8 سے نیچے ایک tidy pile میں، تین octaves تک کچھ بھی نہیں، پھر far end پر اکیلی ایک dimension۔ اب اس tensor کو INT8 میں quantize کریں اور گنیں کیا ہوتا ہے:

256 میں سے چودہ levels۔ scale 1,579.6 نے set کیا تھا، اس لیے ہر step 12.44 wide ہے، اور typical activation — median magnitude 0.26، ninety-ninth percentile 2.51 — کے land کرنے کی جگہ نہیں۔ per dimension یہ اور شدید ہے:

single tensor-wide scale = 12.4378
  dim 826 (max |h| = 4.77):  1 distinct level out of 256
  dim 336 (max |h| = 1.62):  1 distinct level out of 256
  dim  96 (max |h| = 0.69):  1 distinct level out of 256

after excluding the top 4 dimensions, scale = 0.5749  (22x smaller)
  dim 826: 8 levels    dim 336: 4 levels    dim  96: 3 levels

ایک level۔ پوری dimension، ہر token، ایک ہی number میں quantize ہو گئی۔ آٹھ bits allocate کیے گئے اور تقریباً zero استعمال ہوئے، اور ان activations کو پڑھنے والے model کو constant دیا گیا۔

یہ measurement ہر technique کا justification ہے جو لوگ واقعی استعمال کرتے ہیں:

quantization پر تقریباً ہر article پچھلے section پر رک جاتا ہے: method explain کرتا ہے، compression ratio quote کرتا ہے، اور assert کرتا ہے کہ quality “largely preserved” ہے۔ Chapter 4 اپنے آپ کو دھوکا نہ دینے کے بارے میں تھا، تو آئیے معلوم کرتے ہیں۔

وہی model، weights ہر scheme کے ساتھ in place quantized، پھر تین measurements: held-out English prose کے 2,048 tokens پر perplexity — یہاں، اس course کا draft، اسی لیے repository ایک fixed public-domain book substitute کرتی ہے اور اسی shape کی table different numbers کے ساتھ print کرتی ہے — known answers والے 16 short factual questions کی battery under greedy decoding، اور وہ fraction of tokens جس پر quantized model identical context given full-precision model سے agree کرتا ہے۔

اس table میں چار چیزیں صاف کہنا ضروری ہے۔

INT8 properly کیا جائے تو free ہے۔ Per-row INT8 reference کے 23.08 کے مقابلے میں 22.96 score کرتا ہے — دو سو میں ایک part کا gap، جو noise ہے اور “identical” پڑھا جانا چاہیے۔ noise کس طرف point کرتی ہے stable نہیں: repository کے public-domain corpus پر یہی دونوں schemes 22.18 کے مقابلے میں 22.24 آتی ہیں: آدھی distance، اور دوسری طرف point کرتی ہوئی۔ یہ 144 generated tokens میں سے 142 پر full-precision model سے agree کرتا ہے۔ fp32 reference کے مقابلے میں memory کا quarter، fp16 کے مقابلے میں half جسے آپ واقعی deploy کریں گے، اور no detectable cost۔ INT8 carelessly کیا جائے تو بھی nearly free ہے: فی matrix ایک scale 0.5 perplexity points اور no battery answers cost کرتا ہے۔ Eight bits اتنے forgiving ہیں کہ granularity barely matter کرتی ہے، یہی وجہ ہے کہ لوگ INT8 سے INT4 پر generalise کرتے ہیں اور hurt ہوتے ہیں۔

INT4 with one scale per tensor model کو destroy کر دیتا ہے۔ Perplexity 365 million: degraded نہیں، annihilated۔ پھر granularity ہی پوری game ہے — per-tensor 365,416,000، per-row 46.18، per-group-of-128 31.08، NF4 24.55۔ وہی four bits per weight، worst اور best کے درمیان پندرہ million کا factor۔

Perplexity ایک coarse instrument ہے اور battery اس سے بھی coarse۔ NF4 اور group-128 INT4 کے درمیان perplexity gap 6.5 points ہے اور battery ایک question سے differ کرتی ہے — اور Chapter 4 کا confidence interval کہتا ہے کہ sixteen میں ایک question کچھ بھی distinguish نہیں کرتا۔ interval سے بھی sharper demonstration ہے: یہی battery model کی stock repetition penalty switched off کے ساتھ run کریں، یعنی greedy decoding حقیقت میں کیا معنی رکھتا ہے، اور وہ دو rows places swap کر لیتے ہیں۔ sixteen میں ایک question small effect نہیں، no effect ہے۔ Chapter 8 کی warning بھی apply ہوتی ہے: perplexity صرف ان models کے درمیان comparable ہے جو tokenizer share کرتے ہیں، اس لیے کسی اور کے write-up کا number آپ کے number سے compare نہیں کیا جا سکتا۔

agreement column تینوں میں سب سے sharp ہے، اور تقریباً free: full-precision model کو greedily run کریں، پھر quantized model سے ہر position پر پوچھیں کہ given same prefix وہ کیا choose کرتا۔ اس کے پاس 16 کے بجائے 144 independent observations ہیں، ground truth نہیں چاہیے، اور جہاں battery jumps میں degrade ہوتی ہے وہاں یہ smoothly degrade ہوتا ہے۔ یہ بالکل وہ quantity بھی ہے جس کی next section کو ضرورت ہے۔

یہ وہ وعدہ ہے جو Chapter 1 نے اس chapter کے بارے میں کیا تھا، وقت پر پہنچتا ہوا: mathematics کہتی ہے 4-bit model possible ہے، اور engineering decide کرتی ہے کہ آیا یہ usable ہے۔

Chapter 12 نے اسے announce کیا تھا اور bill یہاں چھوڑا تھا۔

idea prefill/decode split سے سیدھا آتا ہے۔ $\gamma$ tokens کی proposed sequence verify کرنے کی cost $\gamma$ positions پر ایک forward pass ہے — matrix-matrix product، ایک position کے pass سے barely زیادہ expensive۔ تو:

output distribution unchanged ہے۔ greedy decoding کے ساتھ یہ obvious ہے — token صرف تب accept ہوتا ہے جب target نے اسے produce کیا ہوتا۔ sampling کے ساتھ modified acceptance rule چاہیے، اور Leviathan et al. prove کرتے ہیں کہ resulting distribution exactly target کی ہے۔¹⁰ یہ اس chapter کی دوسری exact optimisation ہے۔

اس لیے سب کچھ acceptance rate $\alpha$ پر depend کرتا ہے، جو measurable ہے — یہ اوپر والا agreement column ہے، اسی لیے وہاں compute کیا گیا۔ ہر quantized model کو full-precision target کے draft کے طور پر استعمال کرتے ہوئے، 144 generated positions پر:

draft length $\gamma$ پر، expected tokens accepted per verification pass ہے

اور net speedup اسے draft کی اپنی cost سے divide کرتا ہے، target per token کا fraction $c$:

bold entry یاد رکھنے والی ہے: speculative decoding generation کو slower بنا سکتی ہے۔ 30 % acceptance پر، ایسے draft کے ساتھ جو target کا fifth cost کرتا ہے، آپ پانچ forward passes کی قیمت دیتے ہیں اور 1.4 tokens رکھتے ہیں۔ last column دوسری trap ہے — longer draft صرف تب help کرتا ہے جب acceptance high ہو، کیونکہ $\gamma$-token guess کی tail تقریباً کبھی reached نہیں ہوتی۔ 90 % acceptance پر $\gamma = 8$ 3.40x worth ہے اور 30 % پر 0.79x: وہی configuration، win یا loss، آپ کی traffic پر measured number کے مطابق۔

Quantization model کو اسی function کو fewer bits میں store کر کے shrink کرتی ہے۔ Distillation اسے smaller model کو larger one کی imitation train کر کے shrink کرتی ہے¹¹ — ایک idea جو deep learning سے تقریباً ایک decade پہلے کا ہے۔¹²

subtle حصہ یہ ہے کہ student کس چیز سے learns کرتا ہے۔ correct answer نہیں: اس پر direct train کیا جا سکتا تھا۔ teacher جو add کرتا ہے وہ whole distribution ہے۔ model سے پوچھیں کہ phrase کے بعد کیا آتا ہے اور argmax سے آگے دیکھیں:

"She poured the milk into the"
  ' jug' 0.1355   ' cup' 0.1051   ' bowl' 0.0605   ' large' 0.0380   ' milk' 0.0360

hard label کہتا ہے jug اور کچھ نہیں۔ soft label کہتا ہے jug، اور یہ بھی کہ cup تقریباً اتنا ہی اچھا تھا، bowl plausible، اور large — ایک adjective، بالکل مختلف grammatical continuation — ابھی بھی live تھا۔ یہی original argument ہے: یہ 7 ہے، مگر یہ 1 جیسا کافی لگتا ہے، اور resemblance وہ information ہے جسے hard label throw away کر دیتا ہے۔

اسی لیے distillation temperature استعمال کرتی ہے۔ softmax سے پہلے logits کو $T$ سے divide کرنا distribution کو flatten کرتا ہے اور runners-up کا relative weight raise کرتا ہے: اس phrase پر، top token اور third کے درمیان ratio $T = 1$ پر 2.24 سے $T = 2$ پر 1.50 تک گر جاتا ہے — first کا square root، جو logits کو two سے divide کرنے سے ratio کے ساتھ ہوتا ہے۔ same ordering، loss کی attention کا زیادہ حصہ near misses پر۔ student کا gradient teacher کی uncertainty carry کرتا ہے، صرف verdict نہیں۔

اس chapter کی ہر چیز اب ایک sum ہے:

جہاں $T$ تمام concurrent requests کے across resident total tokens ہیں۔ اسے apply کرتے ہوئے: 7B اور 70B rows dimension 128 کے 8 key-value heads assume کرتی ہیں، 13B row 40 heads کے ساتھ full multi-head attention، کیونکہ ان generations کے model اسی طرح built تھے — اور یہ ظاہر ہوتا ہے۔

8 GB

16 GB

24 GB

8 GB table میں 13B row دیکھیں۔ weights fit ہیں — 8 میں سے 6.2 GB — اس لیے usual way of talking کے مطابق، 13B model “8 GB card پر run کرتا ہے”۔ اس کے پاس 337 tokens of context ہیں، جو conversation نہیں بلکہ barely prompt ہے۔ “کیا یہ fit ہوتا ہے” غلط سوال ہے۔ درست سوال ہے “کتنے context کے ساتھ، اور ایک ساتھ کتنے users کے لیے”۔

16 GB کی دونوں int8 rows بھی دیکھیں۔ 7B کو 65,378 tokens ملتے ہیں اور 13B کو 3,136 — extra weights کے 5.6 GB سے twenty-fold difference، کیونکہ یہاں 13B میں multi-head attention ہے اور اس کا cache 7B کے 128 KB کے مقابلے میں 800 KB per token cost کرتا ہے۔ similar size کے دو models، ایک long context کے لیے unusable، ایسی وجہ سے جو کسی model card کی headline میں ظاہر نہیں ہوتی۔

تیرہ chapters پہلے یہ دو weights اور ایک bias والا perceptron تھا۔ اب یہ transformer ہے جسے design، train، align کیا گیا، hard questions پر compute spend کرنا سکھایا گیا، اور measured cost per token پر serve کیا گیا — اس کے اندر کوئی box unopened نہیں بچا۔

یہ یہاں ختم ہوتا ہے، اور intentional طور پر ختم ہوتا ہے۔

Chapter 14 model کو کہیں اور سے شروع کرتا ہے۔ آپ کے process میں نہیں، آپ کی memory میں نہیں، کسی variable میں نہیں جسے آپ print کر سکیں: ایک ایسی machine پر جسے آپ administer نہیں کرتے، API key، port اور bill کے پیچھے۔ یہاں measured ہر چیز پھر بھی ہو رہی ہے — پہلے token سے پہلے prefill پھر بھی run کرتا ہے، cache conversation کے ساتھ پھر بھی grow کرتا ہے، جس batch میں آپ ہیں وہ پھر بھی کسی اور کا ہے اور پھر بھی آپ کی latency decide کرتا ہے — مگر اب سے آپ اسے Server-Sent Events کی stream، ایک finish_reason، اور Retry-After header کے ساتھ HTTP 429 کے ذریعے observe کرتے ہیں۔ vantage point کے ساتھ questions بدلتے ہیں: یہ gradient کیسے compute ہوتا ہے نہیں بلکہ میرا invoice triple کیوں ہوا۔ language بھی بدلتی ہے، اور Chapter 14 اس rule کو announce کرنے کے بجائے explain کرتا ہے — یہاں تک code نے weights، gradients، logits اور tokenizer bytes hold کیے؛ وہاں سے آگے یہ connection، retry، cancellation اور accumulated state hold کرتا ہے۔ آپ کے پیچھے تیرہ chapters crossing سے discard نہیں ہوتے۔ وہ port کے دوسری طرف running چیز کی description ہیں۔

دو omissions deliberate ہیں۔ FlashAttention (Dao et al., arXiv:2205.14135) different attention نہیں — یہ اسی function کو operation tile کر کے compute کرتا ہے تاکہ $n \times n$ score matrix کبھی memory میں written نہ ہو، اسی لیے اس chapter کی second table کا 67 MB practice میں arithmetic کے suggest کرنے سے چھوٹا ہے۔ اور kernels themselves delegated ہیں: Stanford کے CS336 کا lecture 10 inference systems کو اس depth میں cover کرتا ہے جس کی یہ کوشش نہیں کرتا، اور llama.cpp repository اور GGUF specification CPU side کے primary sources ہیں۔