Inference mai ieftin: KV cache, batching și quantization

Pentru a genera un token, un decoder-only transformer ia întreaga secvență de până atunci, o trece prin fiecare layer și citește distribuția de probabilitate din ultima poziție. Apoi adaugă token-ul ales și o face din nou. Descrierea este corectă și exact asta face rularea lentă.

Este și enorm de risipitoare, iar motivul este causal mask din Capitolul 9. Vectorii key și value ai poziției 7 sunt calculați din inputul poziției 7 și pozițiile de dinainte. Când apare poziția 8, poziția 7 nu o poate vedea — asta înseamnă causal — deci key și value ale poziției 7 sunt exact aceleași numere ca înainte. Rularea lentă le recalculează oricum, la fiecare pas.

Așa că stochează-le. Acea stocare este key-value cache, cea mai importantă optimizare din serving-ul modelelor lingvistice:

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)

Uită-te ce este dat modelului în interiorul buclei: nxt, un singur token. Nu secvența. Query-ul noului token attends against fiecare key din cache, iar key-urile din cache nu aveau cum să se schimbe. Aceasta nu este o aproximație — verificarea outputului identic de mai sus este ideea. Cache-ul nu schimbă calitatea pe viteză; șterge aritmetica redundantă.

Ca să vezi scalarea curat, scoate transformer-ul din ecuație și cronometrează un singur attention head cu $d = 64$, un pas de generation calculat în ambele feluri:

Coloana din dreapta este cauza. Recalcularea construiește matricea attention completă $n \times n$ la fiecare pas — $O(n^2)$ din caseta de notație asimptotică a Capitolului 9, plătită o dată per token. Cu cache-ul construiești în schimb un rând $1 \times n$: la 4.096 de token, 67 MB de scoruri față de 16 KB.

Numărarea operațiilor multiply-accumulate în loc de milisecunde scoate mașina din argument. Pentru a genera $T$ token dintr-un start rece:

Per pas, versiunea cu cache este liniară în context, iar cea fără cache este pătratică; însumate pe o generation, $O(T^2)$ față de $O(T^3)$, cu raportul crescând fără limită. Diferența de nouă ori din deschidere a fost măsurată pe 48 de token — sub primul rând al acelui tabel.

Cache-ul schimbă și ce trebuie să fie în memorie. Pe un GPU de laptop de 8 GB care generează 256 de token în fp16, luând vârful allocatorului și scăzând ponderile rezidente:

De 8,3 ori mai multă memorie, cheltuită pentru a produce aceiași token mai lent. Aceasta este promisiunea făcută în Capitolul 5, venind dintr-o direcție neașteptată: acolo, autodiff în reverse-mode trebuia să țină fiecare intermediar în viață pentru backward pass, iar activations dominau memoria de training. La inference nu există backward pass și nimic de păstrat pentru el — deci ce domină memoria este cache-ul, iar el este o alegere deliberată, nu un cost inevitabil.

Uită-te din nou la rularea rapidă: primul ei token s-a comportat diferit de ceilalți patruzeci și șapte.

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

Prompt-ul a costat 25,6 ms per token, iar fiecare token generat a costat 166 ms. Același model, același hardware, aceleași ponderi, o diferență de șase ori per token — și merge în direcția la care majoritatea oamenilor nu se așteaptă. Prompt-ul este partea ieftină. Generation se împarte în două faze cu fizici cu adevărat diferite:

Ambele jumătăți sunt măsurabile. Prefill, o singură trecere peste $P$ token:

Decode, un token față de un cache de $C$:

Citește al doilea tabel de două ori. Trecerea de la 16 token de context la 1.024 — de șaizeci și patru de ori mai mult istoric peste care să faci attention — nu a schimbat costul unui pas cu nimic măsurabil. Attention împotriva cache-ului este muncă reală, dar este eclipsată de costul fix al tragerii a jumătate de miliard de ponderi prin magistrala de memorie pentru a produce un vector. Acel cost fix este motivul pentru tot ce urmează în secțiunea următoare.

Aceste două faze sunt originea celor două numere raportate de orice sistem de serving. Time to first token este în esență prefill și crește cu prompt-ul, motiv pentru care o conversație lungă pare lentă la început. Tokens per second este $1/\text{decode step}$ și este aproximativ constant, motiv pentru care răspunsul curge apoi uniform. Un chat care pornește încet și apoi face streaming lin nu este un truc de randare. Sunt aceste două tabele.

Cache-ul schimbă aritmetica pe memorie, iar memoria pe care o vrea nu este puțină. Pentru fiecare token din context, fiecare layer păstrează un vector key și un vector value per key-value head:

2-ul este pentru keys și values; restul ține de arhitectură. Pentru modelul măsurat în tot acest capitol — 24 de layers, 14 query heads, 2 key-value heads, head dimension 64 — în fp16 asta înseamnă $2 \times 24 \times 2 \times 64 \times 2 = 12{,}288$ bytes per token.

Formulae din acest domeniu au obiceiul să fie greșite cu un factor de doi, așa că verific-o cu allocatorul în loc să o crezi:

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, și rămâne exactă în toate formele încercate:

Ultimele trei rânduri merită privite încă o dată. Treizeci și doi de useri cu 2.048 de token fiecare, șaizeci și patru cu 1.024, o sută douăzeci și opt cu 512 — cache-ul este 768 MB în fiecare caz, pentru că toate trei țin 65.536 de token. Cache-ul depinde doar de numărul total de token rezidenți, nu de cum sunt distribuiți între useri. Acest fapt este fundația secțiunii despre batching.

Capitolul 9 a introdus multi-query și grouped-query attention și a amânat motivul pentru acest capitol. Motivul este acea formulă și, mai precis, $H_{kv}$ din ea.

Standard multi-head attention oferă fiecărui query head propriile key și value heads. Modelul de aici are 14 query heads; cu full multi-head attention, cache-ul lui ar fi $2 \times 24 \times 14 \times 64 \times 2 = 86{,}016$ bytes per token — 84 KB în loc de 12 KB, exact de șapte ori mai mult, raportul dintre query heads și key-value heads.

Multi-query attention¹ duce asta la limită: toate query heads împart un singur key-value head. Grouped-query attention² este compromisul care a câștigat — câteva key-value heads, fiecare împărțit de un grup de query heads — pentru că pierderea de calitate a MQA era reală, iar cea a GQA nu este. Niciuna nu cumpără aritmetică. Există ca să împartă acea formulă la un întreg și s-au răspândit în industrie în clipa în care contextele lungi au făcut din cache constrângerea principală.

Ceea ce se întâmplă repede. Pentru un model din clasa 7B cu 32 de layers și 8 key-value heads de dimension 128, cache-ul este 128 KB per token în fp16:

Ponderile proprii ale acelui model sunt 13,0 GB în fp16, cifra din tabelul de la finalul capitolului. Deci la un context de 128.000 de token, cache-ul unui singur user este mai mare decât modelul. Aceasta este aritmetica pe care Capitolul 16 o transformă în bani și motivul pentru care o conversație lungă nu este doar una lentă — ea ocupă o felie fixă dintr-o mașină cât timp request-ul este viu.

Decode este memory-bound: ponderile sunt trase prin magistrală pentru a produce un token, iar unitățile aritmetice stau degeaba. Așa că pune mai multă muncă în același pas. Rulează mai multe request-uri deodată, iar ponderile, citite o singură dată, le servesc pe toate. Măsurat pe același model, fiecare request ținând un cache de 64 de token și făcând decode pentru un token:

Citește cele două coloane din dreapta una în raport cu cealaltă, pentru că ele sunt toată ideea. Trecerea de la un request la șaisprezece multiplică throughput-ul cu 6,0 și multiplică așteptarea pentru fiecare request individual cu 2,67. Batch-ul a făcut serverul mai bun și fiecare user mai rău.

Nu este un bug care poate fi reglat până dispare; acesta este schimbul în sine și are câte un nume pe fiecare parte. Latența este ceea ce simte o persoană care așteaptă un răspuns. Throughput-ul este ceea ce împarte factura. Nicio setare nu le îmbunătățește pe amândouă.

Observă și unde se oprește. De la 16 la 32, throughput-ul câștigă 9 %, în timp ce latența aproape se dublează: pasul a încetat să mai fie memory-bound și a devenit compute-bound, iar după acel cot batch-ul nu mai cumpără nimic. Fiecare deployment are un astfel de cot; poziția lui trebuie măsurată pe al tău, dar existența lui nu.

Modul naiv de a face batch este să colectezi $B$ request-uri, să le rulezi împreună și să returnezi când toate sunt gata. Dar nu se termină împreună: unele răspunsuri au douăzeci de token, altele cinci sute. Un batch fix rulează până când cel mai lung membru se termină, iar fiecare request terminat continuă să-și ocupe slotul, contribuind padding, până atunci.

Ia 64 de request-uri cu o asimetrie realistă a lungimilor de output — mediană 18 token, cel mai lung 231, 1.874 în total — și simulează ambele politici la costul per pas măsurat pentru opt sloturi:

Throughput-ul se îmbunătățește de 1,6x. Latența medie se îmbunătățește de peste zece ori, pentru că sub static batching un request care s-a terminat în patru pași încă așteaptă un vecin de 231 de token înainte să audă cineva de el.

Continuous batching³ este soluția și este la fel de simplă cum sună: batch-ul nu este un grup, ci un set de sloturi, iar un slot care se eliberează admite următorul request din coadă chiar la pasul următor. Schedulerul lucrează la granularitatea unui token, nu a unui request. Orice stack de serving în producție face asta acum.

Are și o a doua jumătate, care este cache-ul. Sloturile care vin și pleacă lasă memoria cache fragmentată, iar rezervarea pentru fiecare slot a context-ului maxim posibil irosește cea mai mare parte a rezervării. PagedAttention⁴ împrumută răspunsul de la sistemele de operare: stochează cache-ul în blocuri de dimensiune fixă, cu un tabel de blocuri per secvență, astfel încât cache-ul unei secvențe să poată fi împrăștiat fizic, rămânând logic contiguu — ceea ce permite și ca două secvențe cu prefix comun să împartă blocurile care îl conțin. Pe asta este construit vLLM și de aceea un engine de serving este un allocator de memorie cu un transformer atașat.

Cealaltă jumătate a facturii sunt ponderile înseși. O jumătate de miliard de parametri la patru bytes fiecare înseamnă 1,98 GB; la doi bytes, 0,99 GB; la un byte, 0,49 GB. Mai puțini biți per pondere micșorează modelul pe disc, îl micșorează în memorie și — pentru că decode este bandwidth-bound — fac fiecare pas mai rapid, deoarece sunt mai puțini bytes de mutat.

Cea mai simplă schemă este quantization simetrică absolute-maximum și încape în trei linii:

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

Alege o scară astfel încât cea mai mare pondere să se mapeze la cel mai mare întreg, împarte, rotunjește, stochează întregii și scara. Reconstruiește înmulțind înapoi. Nu este nimic isteț în asta și funcționează — până când nu mai funcționează.

Măsurat pe ponderile reale ale modelului: toate cele 168 de matrice de proiecție, 357,8 milioane de parametri, eroare relativă $\lVert W - \hat{W}\rVert / \lVert W \rVert$:

Al patrulea rând este prăbușirea. O eroare relativă de 0,99 pe cea mai rea matrice înseamnă că reconstrucția nu păstrează practic nimic din original — matricea a fost înlocuită cu zgomot de magnitudine aproximativ corectă. Cauza se vede în același experiment pe o singură matrice:

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

O pondere din șase mii se află dincolo de șase deviații standard, iar cea mai mare este la 24. Cu o singură scară pentru întreaga matrice, acea pondere stabilește mărimea pasului pentru toate cele 4,3 milioane de ponderi. La 8 biți există 256 de pași, iar ponderea tipică tot ajunge pe unul semnificativ. La 4 biți există 16, cel mai exterior este rezervat pentru o valoare pe care aproape nimic nu o are, iar ponderile obișnuite — adică toate — se rotunjesc la două sau trei niveluri distincte.

Tot ce urmează după acel rând este aceeași reparație la granularități diferite: dă scării un teritoriu mai mic. Per rând de output împarte eroarea la 3,4; per grup de 128 de ponderi consecutive o împarte din nou. Costul este contabilitate — o scară pe 16 biți per grup de 128 înseamnă $4 + 16/128 = 4.125$ biți per pondere în loc de 4 — și recuperează cea mai mare parte din diferență.

NF4 atacă problema din cealaltă parte.⁵ Nivelurile nu trebuie să fie spațiate egal. Ponderile dintr-un bloc sunt aproximativ distribuite normal, așa că alege cele șaisprezece niveluri ca cuantile ale unei distribuții normale: dense aproape de zero, unde sunt de fapt ponderile, rare în cozi, unde nu sunt. Aceiași patru biți, aceeași scalare pe bloc, la un bloc mai mic — 4,25 biți per pondere față de 4,125 pentru group-128 — iar eroarea măsurată scade de la 0,1323 la 0,0952, cu 28 % mai jos. O parte vine din blocul mai fin, restul din plasarea nivelurilor acolo unde este masa, iar separarea celor două ar cere un al treilea rând.

Caseta despre floating-point din Capitolul 2 s-a încheiat cu o promisiune: că acest capitol va face quantize ponderilor la 8 și 4 biți și va găsi o mână de outlier features care refuză să fie comprimate. Iată-le, și ele explică de ce „doar rotunjește numerele” nu avea cum să funcționeze pe activations.

Ponderile de mai sus s-au comportat prost. Activations sunt într-o cu totul altă ligă. Ia un prompt obișnuit de 84 de token, capturează residual stream la fiecare layer și măsoară cea mai mare magnitudine pe care o atinge fiecare dintre cele 896 de dimensiuni:

Dimensiunea 62 ajunge la 1.579,6, în timp ce dimensiunea mediană nu trece niciodată de 1,6. Nu este o întâmplare a unui token sau a unui layer: aceeași dimensiune este acolo la layer 4 și încă acolo la layer 20, cu aproape aceeași valoare. Acestea sunt outlier features,⁶ și sunt sistematice — o proprietate a modelului trained, nu a inputului.

Histograma celor 896 de maxime per dimensiune la layer 16 face forma imposibil de confundat:

     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

Nouă sute de dimensiuni într-o grămadă ordonată sub 8, nimic pentru trei octave, apoi o singură dimensiune singură la capătul îndepărtat. Acum fă quantize acelui tensor la INT8 și numără ce se întâmplă:

Paisprezece niveluri din 256. Scara a fost setată de 1.579,6, deci fiecare pas are lățimea 12,44, iar activation-ul tipic — magnitudine mediană 0,26, percentila 99 la 2,51 — nu are unde să aterizeze. Per dimensiune este și mai dur:

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

Un nivel. Întreaga dimensiune, fiecare token, quantized la același număr. Au fost alocați opt biți și s-a folosit aproximativ zero, iar modelul care citește acele activations primește o constantă.

Acea măsurătoare este justificarea pentru fiecare tehnică pe care oamenii chiar o folosesc:

Aproape fiecare articol despre quantization se oprește la secțiunea anterioară: explică metoda, citează un raport de compresie și afirmă că „calitatea este în mare parte păstrată”. Capitolul 4 a fost despre a nu te păcăli singur, așa că hai să aflăm.

Același model, ponderi quantized in place cu fiecare schemă, apoi trei măsurători: perplexity pe 2.048 de token de proză engleză held-out — aici, ciorna acestui curs, motiv pentru care repository-ul substituie o carte fixă din domeniul public și tipărește un tabel cu aceeași formă, dar numere diferite — o baterie de 16 întrebări factuale scurte cu răspunsuri cunoscute sub greedy decoding și fracțiunea de token pentru care modelul quantized este de acord cu cel full-precision dat același context.

Patru lucruri din acel tabel merită spuse direct.

INT8 făcut corect este gratuit. INT8 per rând obține 22,96 față de 23,08 pentru referință — o diferență de o parte din două sute, adică zgomot și ar trebui citită ca „identic”. Direcția în care arată zgomotul nu este stabilă: pe corpusul public-domain al repository-ului, aceleași două scheme ies 22,24 față de 22,18: jumătate din acea distanță și în direcția opusă. Este de acord cu modelul full-precision pe 142 din 144 de token generați. Un sfert din memorie față de referința fp32, jumătate față de fp16-ul pe care l-ai deploya de fapt, și niciun cost detectabil. INT8 făcut neglijent este și el aproape gratuit: o scară per matrice costă 0,5 puncte de perplexity și niciun răspuns în baterie. Opt biți sunt destul de iertători încât granularitatea contează foarte puțin, exact motivul pentru care oamenii generalizează de la INT8 la INT4 și se lovesc.

INT4 cu o scară per tensor distruge modelul. Perplexity 365 de milioane: nu degradat, anihilat. Granularitatea devine apoi tot jocul — per-tensor 365.416.000, per-rând 46,18, per-grup-de-128 31,08, NF4 24,55. Aceiași patru biți per pondere, un factor de cincisprezece milioane între cel mai rău și cel mai bun.

Perplexity este un instrument grosier, iar bateria unul și mai grosier. Între NF4 și group-128 INT4 diferența de perplexity este 6,5 puncte, iar bateria diferă printr-o întrebare — iar intervalul de încredere din Capitolul 4 spune că o întrebare din șaisprezece nu distinge absolut nimic. Există o demonstrație mai tăioasă decât intervalul: rulează aceeași baterie cu repetition penalty-ul stock al modelului dezactivat, adică ceea ce înseamnă de fapt greedy decoding, iar cele două rânduri își schimbă locurile. O întrebare din șaisprezece nu este un efect mic, este niciun efect. Avertismentul din Capitolul 8 se aplică și el: perplexity este comparabilă doar între modele care împart un tokenizer, deci un număr din articolul altcuiva nu poate fi comparat cu al tău.

Coloana de acord este cea mai precisă dintre cele trei, și aproape gratuită: rulează modelul full-precision greedy, apoi întreabă modelul quantized, la fiecare poziție, ce ar fi ales dat același prefix. Are 144 de observații independente în loc de 16, nu are nevoie de ground truth și se degradează lin acolo unde bateria se degradează în salturi. Este și exact cantitatea de care are nevoie secțiunea următoare.

Aceasta este promisiunea făcută de Capitolul 1 despre acest capitol, sosind la timp: matematica spune că un model pe 4 biți este posibil, iar ingineria decide dacă este utilizabil.

Capitolul 12 a anunțat asta și a lăsat factura aici.

Ideea vine direct din împărțirea prefill/decode. Verificarea unei secvențe propuse de $\gamma$ token costă un forward pass peste $\gamma$ poziții — un produs matrice-matrice, abia mai scump decât trecerea peste una singură. Deci:

Distribuția de output este neschimbată. Cu greedy decoding este evident — un token este acceptat doar dacă ținta l-ar fi produs. Cu sampling cere o regulă de acceptare modificată, iar Leviathan et al. demonstrează că distribuția rezultată este exact cea a țintei.¹⁰ Aceasta este a doua optimizare exactă din acest capitol.

Prin urmare, totul depinde de rata de acceptare $\alpha$, care este măsurabilă — este coloana de acord de mai sus, motiv pentru care a fost calculată acolo. Folosind fiecare model quantized ca draft pentru ținta full-precision, pe 144 de poziții generate:

Numărul așteptat de token acceptați per verification pass, la draft length $\gamma$, este

iar accelerarea netă împarte asta la costul propriu al draft-ului, o fracțiune $c$ din țintă per token:

Intrarea bold este cea de reținut: speculative decoding poate face generation mai lentă. La 30 % acceptare cu un draft care costă o cincime din țintă, plătești pentru cinci forward passes și păstrezi 1,4 token. Ultima coloană este cealaltă capcană — un draft mai lung ajută doar când acceptarea este mare, pentru că coada unei presupuneri de $\gamma$ token este aproape niciodată atinsă. La 90 % acceptare, $\gamma = 8$ valorează 3,40x, iar la 30 % valorează 0,79x: aceeași configurație, câștig sau pierdere în funcție de un număr măsurat pe traficul tău.

Quantization micșorează un model stocând aceeași funcție în mai puțini biți. Distillation îl micșorează antrenând un model mai mic să imite unul mai mare¹¹ — o idee care precedă deep learning cu aproape un deceniu.¹²

Partea subtilă este din ce învață studentul. Nu răspunsul corect: ar fi putut fi antrenat direct pe acesta. Ce adaugă profesorul este întreaga distribuție. Întreabă modelul ce urmează după o frază și privește dincolo de argmax:

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

Eticheta hard spune jug și nimic altceva. Eticheta soft spune jug, și mai spune că cup era aproape la fel de bun, bowl plauzibil, iar large — un adjectiv, o continuare gramaticală complet diferită — încă viu. Acesta este argumentul original: acesta este un 7, dar seamănă destul de mult cu un 1, iar asemănarea este informație pe care eticheta hard o aruncă.

Tot de aceea distillation folosește o temperatură. Împărțirea logits la $T$ înainte de softmax aplatizează distribuția și crește greutatea relativă a clasatelor următoare: pe această frază, raportul dintre top token și al treilea scade de la 2,24 la $T = 1$ la 1,50 la $T = 2$ — rădăcina pătrată a primului, exact ce face împărțirea logits la doi asupra unui raport. Aceeași ordine, mai mult din attention-ul loss-ului pe ratările apropiate. Gradient-ul studentului poartă incertitudinea profesorului, nu doar verdictul lui.

Totul în acest capitol este acum o singură sumă:

unde $T$ este numărul total de token rezidenți peste toate request-urile concurente. Aplicând-o: rândurile 7B și 70B presupun 8 key-value heads de dimension 128, rândul 13B full multi-head attention cu 40 de heads, așa cum au fost construite acele generații de model — și se vede.

8 GB

16 GB

24 GB

Uită-te la rândul 13B din tabelul de 8 GB. Ponderile încap — 6,2 GB din 8 — deci, în modul obișnuit de a vorbi, un model 13B „rulează pe o placă de 8 GB”. Are 337 de token de context, ceea ce nu este o conversație, ci abia un prompt. „Încape?” este întrebarea greșită. Întrebarea corectă este „cu cât context și pentru câți useri deodată”.

Uită-te și la cele două rânduri int8 din tabelul de 16 GB. 7B primește 65.378 de token, iar 13B primește 3.136 — o diferență de douăzeci de ori din 5,6 GB de ponderi în plus, pentru că 13B aici are multi-head attention și cache-ul lui costă 800 KB per token față de 128 KB pentru 7B. Două modele de dimensiune similară, unul inutilizabil pentru context lung, dintr-un motiv care nu apare în titlul niciunui model card.

Acum treisprezece capitole, acesta era un perceptron cu două ponderi și un bias. Acum este un transformer care a fost proiectat, trained, aligned, învățat să cheltuiască compute pe întrebări grele și served la un cost măsurat per token — fără nicio cutie rămasă nedeschisă în el.

Aici se termină, și se termină intenționat.

Capitolul 14 începe cu modelul altundeva. Nu în procesul tău, nu în memoria ta, nu într-o variabilă pe care o poți printa: pe o mașină pe care nu o administrezi, în spatele unei chei API, al unui port și al unei facturi. Tot ce s-a măsurat aici se întâmplă încă — prefill rulează încă înainte de primul token, cache-ul încă crește odată cu conversația, batch-ul în care ești încă aparține altcuiva și încă îți decide latența — dar de acum îl observi printr-un stream de Server-Sent Events, un finish_reason și un HTTP 429 cu un header Retry-After. Întrebările se schimbă odată cu punctul de observație: nu cum se calculează acest gradient, ci de ce mi s-a triplat factura. Se schimbă și limbajul, iar Capitolul 14 explică această regulă în loc să o anunțe — până aici codul ținea ponderi, gradients, logits și bytes de tokenizer; de acolo încolo ține o conexiune, un retry, o anulare și state acumulat. Cele treisprezece capitole din spate nu sunt aruncate la trecere. Ele sunt descrierea a ceea ce rulează de cealaltă parte a portului.

Două omisiuni sunt deliberate. FlashAttention (Dao et al., arXiv:2205.14135) nu este o attention diferită — calculează aceeași funcție prin tiling-ul operației astfel încât matricea de scoruri $n \times n$ să nu fie niciodată scrisă în memorie, motiv pentru care cei 67 MB din al doilea tabel al acestui capitol sunt mai mici în practică decât sugerează aritmetica. Iar kernels înșiși sunt delegați: cursul 10 din CS336 de la Stanford acoperă sistemele de inference în profunzimea pe care acesta nu o încearcă, iar repository-ul llama.cpp și specificația GGUF sunt sursele primare pentru partea de CPU.