Abaratir la inferència: KV cache, batching i quantization

Per generar un token, un transformer només decoder agafa tota la seqüència fins ara, la passa per cada capa i llegeix la distribució de probabilitat de l’última posició. Després hi afegeix el token triat i ho torna a fer. Aquesta descripció és correcta, i és el que fa l’execució lenta.

També és enormement malbaratadora, i el motiu és la màscara causal del Capítol 9. Els vectors key i value de la posició 7 es calculen a partir de l’entrada de la posició 7 i les posicions anteriors. Quan arriba la posició 8, la posició 7 no la pot veure —això és el que vol dir causal—, de manera que els key i value de la posició 7 són exactament els mateixos nombres que abans. L’execució lenta els recalcula igualment, a cada pas.

Per tant, guarda’ls. Aquest magatzem és la key-value cache, l’optimització més important en el serving de models de llenguatge:

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)

Fixa’t en què s’alimenta al model dins del bucle: nxt, un token. No la seqüència. La query del nou token fa attention contra cada key en caché, i les keys en caché no havien de canviar mai. Això no és una aproximació: la comprovació de sortida idèntica de més amunt és el punt. La caché no intercanvia qualitat per velocitat; elimina aritmètica redundant.

Per veure’n l’escalat netament, treu el transformer i mesura un sol cap d’attention amb $d = 64$, un pas de generació calculat de totes dues maneres:

La columna de la dreta n’és la causa. Recalcular construeix la matriu d’attention completa $n \times n$ a cada pas: el $O(n^2)$ del requadre de notació asimptòtica del Capítol 9, pagat una vegada per token. Amb la caché construeixes una fila $1 \times n$: a 4.096 tokens, 67 MB de puntuacions contra 16 KB.

Comptar multiplicacions-acumulacions en lloc de mil·lisegons treu la màquina de l’argument. Per generar $T$ tokens des d’un inici en fred:

Per pas, la versió amb caché és lineal en el context i la que no en té és quadràtica; sumat al llarg d’una generació, $O(T^2)$ contra $O(T^3)$, amb una ràtio que creix sense límit. La diferència de nou vegades de l’inici es va mesurar sobre 48 tokens: per sota de la primera fila d’aquella taula.

La caché també canvia què ha d’estar en memòria. En una GPU de portàtil de 8 GB generant 256 tokens en fp16, agafant el pic de l’assignador i restant-ne els pesos residents:

8,3 vegades més memòria, gastada per produir els mateixos tokens més lentament. Aquesta és la promesa feta al Capítol 5, arribant des d’una direcció inesperada: allà, l’autodiff en mode invers havia de mantenir viu cada intermedi per al backward pass, i les activations dominaven la memòria d’entrenament. A inference no hi ha backward pass ni res a retenir per a ell; així, el que domina la memòria és la caché, i és una tria deliberada més que no pas un cost inevitable.

Mira de nou l’execució ràpida: el seu primer token es va comportar de manera diferent dels altres quaranta-set.

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

El prompt va costar 25,6 ms per token i cada token generat va costar 166 ms. Mateix model, mateix maquinari, mateixos pesos, una diferència de sis vegades per token —i va en el sentit que la majoria no espera. El prompt és la part barata. La generació es divideix en dues fases amb física realment diferent:

Totes dues meitats són mesurables. Prefill, una passada sobre $P$ tokens:

Decode, un token contra una caché de $C$:

Llegeix la segona taula dues vegades. Passar de 16 tokens de context a 1.024 —seixanta-quatre vegades més historial per fer-hi attention— no va canviar el cost d’un pas de manera mesurable. L’attention contra la caché és feina real, però queda eclipsada pel cost fix d’arrossegar mig milió llarg de pesos pel bus de memòria per produir un vector. Aquest cost fix és el motiu de tot el que ve a la secció següent.

Aquestes dues fases són l’origen dels dos números que informa qualsevol sistema de serving. Time to first token és essencialment el prefill, i creix amb el prompt, per això una conversa llarga sembla lenta d’arrencar. Tokens per second és $1/\text{decode step}$, i és aproximadament constant, per això la resposta després flueix de manera uniforme. Un xat que comença lent i després fa streaming suaument no és un truc de renderització. Són aquestes dues taules.

La caché intercanvia aritmètica per memòria, i la memòria que demana no és petita. Per cada token del context, cada capa guarda un vector key i un vector value per cada cap key-value:

El 2 és per keys i values; tota la resta és l’arquitectura. Per al model mesurat al llarg d’aquest capítol —24 capes, 14 caps de query, 2 caps key-value, dimensió de cap 64— en fp16 això són $2 \times 24 \times 2 \times 64 \times 2 = 12{,}288$ bytes per token.

Les fórmules en aquest camp tenen el costum d’equivocar-se per un factor de dos, així que comprova-ho contra l’assignador en lloc de creure-t’ho:

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

Exacte, i es manté exacte en totes les formes provades:

Les tres últimes files mereixen una segona mirada. Trenta-dos usuaris amb 2.048 tokens cadascun, seixanta-quatre amb 1.024, cent vint-i-vuit amb 512: la caché és de 768 MB en tots els casos, perquè tots tres contenen 65.536 tokens. La caché depèn només del nombre total de tokens residents, no de com es distribueixen entre usuaris. Aquest fet és la base de la secció sobre batching.

El Capítol 9 va introduir multi-query i grouped-query attention i en va ajornar el motiu fins a aquest capítol. El motiu és aquella fórmula, i concretament el $H_{kv}$ que conté.

L’attention multi-head estàndard dona a cada cap de query els seus propis caps key i value. El model d’aquí té 14 caps de query; amb attention multi-head completa, la seva caché seria de $2 \times 24 \times 14 \times 64 \times 2 = 86{,}016$ bytes per token: 84 KB en lloc de 12 KB, exactament set vegades més, la ràtio entre caps de query i caps key-value.

Multi-query attention¹ ho porta al límit: tots els caps de query comparteixen un sol cap key-value. Grouped-query attention² és el compromís que va guanyar: uns quants caps key-value, cadascun compartit per un grup de caps de query, perquè la pèrdua de qualitat de MQA era real i la de GQA no. Cap de les dues compra aritmètica. Existeixen per dividir aquella fórmula per un enter, i es van estendre per la indústria en el moment que els contextos llargs van fer que la caché fos la restricció vinculant.

I ho fa, ràpid. Per a un model de classe 7B amb 32 capes i 8 caps key-value de dimensió 128, la caché és de 128 KB per token en fp16:

Els pesos propis d’aquest model són 13,0 GB en fp16, la xifra de la taula del final d’aquest capítol. Així que, amb un context de 128.000 tokens, la caché d’un sol usuari és més gran que el model. Aquesta és l’aritmètica que el Capítol 16 converteix en diners, i és per això que una conversa llarga no és només lenta: ocupa una porció fixa d’una màquina mentre la petició és viva.

El decode és memory-bound: els pesos s’arrosseguen pel bus per produir un token, i les unitats aritmètiques queden ocioses. Per tant, posa més feina al mateix pas. Executa diverses peticions alhora, i els pesos, llegits una vegada, serveixen totes elles. Mesurat al mateix model, cada petició mantenint una caché de 64 tokens i decodificant un token:

Llegeix les dues columnes de la dreta l’una contra l’altra, perquè són tot el punt. Passar d’una petició a setze multiplica el throughput per 6,0 i multiplica l’espera de cada petició individual per 2,67. El batch va fer millor el servidor i pitjor cada usuari.

Això no és un error que es pugui ajustar fins que desaparegui; és el trade-off mateix, i té un nom a cada costat. La latència és el que viu una persona que espera una resposta. El throughput és allò pel qual es divideix la factura. Cap configuració millora totes dues coses.

Fixa’t també on s’atura. De 16 a 32, el throughput guanya un 9 % mentre la latència gairebé es duplica: el pas ha deixat d’estar memory-bound i ha passat a estar compute-bound, i més enllà d’aquell genoll el batch no compra res. Cada deployment té un genoll així; la seva ubicació s’ha de mesurar en el teu, però la seva existència no.

La manera ingènua de fer batch és recollir $B$ peticions, executar-les juntes i retornar quan totes hagin acabat. Però no acaben juntes: algunes respostes tenen vint tokens i algunes cinc-cents. Un batch fix s’executa fins que acaba el membre més llarg, i cada petició ja acabada continua ocupant la seva ranura, aportant padding, fins aleshores.

Agafa 64 peticions amb un biaix realista de longituds de sortida —mediana de 18 tokens, la més llarga 231, 1.874 en total— i simula les dues polítiques al cost per pas mesurat per a vuit ranures:

El throughput millora 1,6x. La latència mitjana millora més de deu vegades, perquè amb batching estàtic una petició que ha acabat en quatre passos encara espera un veí de 231 tokens abans que ningú en senti res.

Continuous batching³ és la solució, i és tan simple com sona: el batch no és un grup sinó un conjunt de ranures, i una ranura que s’allibera admet la següent petició en cua al pas immediatament següent. El planificador treballa a la granularitat d’un token en lloc d’una petició. Tota pila de serving en producció ja fa això.

Té una segona meitat, que és la caché. Les ranures que entren i surten deixen la memòria de caché fragmentada, i reservar per a cada ranura el seu context màxim possible malbarata la major part de la reserva. PagedAttention⁴ pren prestada la resposta dels sistemes operatius: emmagatzema la caché en blocs de mida fixa amb una taula de blocs per seqüència, de manera que la caché d’una seqüència pot estar dispersa físicament mentre continua sent lògicament contigua; això també permet que dues seqüències amb un prefix compartit comparteixin els blocs que el contenen. Això és la base de vLLM, i per això un motor de serving és un assignador de memòria amb un transformer enganxat.

L’altra meitat de la factura són els pesos mateixos. Mig milió llarg de paràmetres a quatre bytes cadascun són 1,98 GB; a dos bytes, 0,99 GB; a un byte, 0,49 GB. Menys bits per pes encongeixen el model al disc, l’encongeixen en memòria i —com que el decode és bandwidth-bound— fan que cada pas sigui més ràpid, perquè hi ha menys bytes per moure.

L’esquema més simple és la quantization simètrica de màxim absolut, i cap en tres línies:

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

Tria una escala perquè el pes més gran mapegi a l’enter més gran, divideix, arrodoneix, guarda els enters i l’escala. Reconstrueix multiplicant de tornada. No té res d’enginyós, i funciona —fins que deixa de funcionar.

Mesurat sobre els pesos reals del model: les 168 matrius de projecció, 357,8 milions de paràmetres, error relatiu $\lVert W - \hat{W}\rVert / \lVert W \rVert$:

La quarta fila és l’esfondrament. Un error relatiu de 0,99 a la pitjor matriu vol dir que la reconstrucció no reté pràcticament res de l’original: la matriu ha estat substituïda per soroll d’una magnitud més o menys correcta. La causa és visible en el mateix experiment sobre una sola matriu:

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

Un pes de cada sis mil queda més enllà de sis desviacions estàndard, i el més gran és a 24. Amb una sola escala per a tota la matriu, aquest únic pes fixa la mida del pas per als 4,3 milions restants. A 8 bits hi ha 256 passos i el pes típic encara cau en un de significatiu. A 4 bits n’hi ha 16, l’extrem queda reservat per a un valor que gairebé res no té, i els pesos ordinaris —que són tots— s’arrodoneixen a dos o tres nivells diferents.

Tot el que ve després d’aquella fila és la mateixa reparació a granularitats diferents: donar a l’escala un territori més petit. Per fila de sortida divideix l’error per 3,4; per grup de 128 pesos consecutius el torna a dividir. El cost és comptabilitat —una escala de 16 bits per grup de 128 són $4 + 16/128 = 4.125$ bits per pes en lloc de 4— i recupera la major part de la distància.

NF4 ho aborda des de l’altre costat.⁵ Els nivells no han d’estar igualment espaiats. Els pesos dins d’un bloc es distribueixen aproximadament normalment, així que tria els setze nivells com els quantils d’una distribució normal: densos prop de zero, on realment són els pesos, escassos a les cues, on no ho són. Els mateixos quatre bits, la mateixa escala per bloc, en un bloc més petit —4,25 bits per pes contra els 4,125 del grup-128— i l’error mesurat baixa de 0,1323 a 0,0952, un 28 % menys. Una part és el bloc més fi i la resta és posar els nivells on hi ha la massa, i separar les dues coses necessitaria una tercera fila.

El requadre de punt flotant del Capítol 2 acabava amb una promesa: que aquest capítol quantitzaria pesos a 8 i 4 bits i trobaria un grapat de features outlier que es resistien a ser comprimides. Aquí són, i expliquen per què "simplement arrodoneix els nombres" no havia de funcionar mai sobre les activations.

Els pesos de dalt es comportaven malament. Les activations juguen en una altra lliga. Agafa un prompt ordinari de 84 tokens, captura el flux residual a cada capa i mesura la magnitud més gran que assoleix cadascuna de les 896 dimensions:

La dimensió 62 arriba a 1.579,6 mentre que la dimensió mediana no supera mai 1,6. No és una casualitat d’un token o d’una capa: la mateixa dimensió hi és a la capa 4 i encara hi és a la capa 20, amb gairebé el mateix valor. Aquestes són les features outlier,⁶ i són sistemàtiques: una propietat del model entrenat, no de l’entrada.

L’histograma d’aquests 896 màxims per dimensió a la capa 16 fa que la forma sigui inconfusible:

     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-centes dimensions en un pilot ordenat per sota de 8, absolutament res durant tres octaves, i després una sola dimensió a l’extrem llunyà. Ara quantitza aquest tensor a INT8 i compta què passa:

Catorze nivells de 256. L’escala la fixava 1.579,6, així que cada pas fa 12,44 d’ample, i l’activation típica —magnitud mediana 0,26, percentil noranta-nou 2,51— no té on aterrar. Per dimensió és encara més cru:

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 nivell. Tota la dimensió, cada token, quantitzada al mateix nombre. S’hi van assignar vuit bits i se’n van fer servir aproximadament zero, i el model que llegeix aquestes activations rep una constant.

Aquesta mesura és la justificació de totes les tècniques que la gent realment fa servir:

Gairebé tots els articles sobre quantization s’aturen a la secció anterior: expliquen el mètode, citen una ràtio de compressió i afirmen que la qualitat es conserva "en gran part". El Capítol 4 anava de no enganyar-se a un mateix, així que comprovem-ho.

Mateix model, pesos quantitzats in situ amb cada esquema, i després tres mesures: perplexity sobre 2.048 tokens de prosa anglesa reservada —aquí, l’esborrany d’aquest curs, per això el repositori substitueix un llibre fix de domini públic i imprimeix una taula de la mateixa forma amb nombres diferents—, una bateria de 16 preguntes factuals curtes amb respostes conegudes sota greedy decoding, i la fracció de tokens en què el model quantitzat coincideix amb el de precisió completa donat un context idèntic.

Hi ha quatre coses d’aquesta taula que val la pena dir clarament.

INT8 fet correctament surt gratis. L’INT8 per fila puntua 22,96 contra els 23,08 de la referència: una diferència d’una part entre dues-centes, que és soroll i s’ha de llegir com "idèntic". La direcció del soroll no és estable: al corpus de domini públic del repositori, els mateixos dos esquemes surten 22,24 contra 22,18, la meitat de la distància i apuntant cap a l’altra banda. Coincideix amb el model de precisió completa en 142 dels 144 tokens generats. Una quarta part de la memòria contra la referència fp32, la meitat contra l’fp16 que realment desplegaries, i cap cost detectable. INT8 fet descuidament també és gairebé gratis: una escala per matriu costa 0,5 punts de perplexity i cap resposta de la bateria. Vuit bits perdonen prou perquè la granularitat gairebé no importi, que és exactament per això que la gent generalitza d’INT8 a INT4 i pren mal.

INT4 amb una escala per tensor destrueix el model. Perplexity 365 milions: no degradat, aniquilat. La granularitat és aleshores tot el joc: per tensor 365.416.000, per fila 46,18, per grup de 128 31,08, NF4 24,55. Els mateixos quatre bits per pes, un factor de quinze milions entre el pitjor i el millor.

La perplexity és un instrument bast, i la bateria encara més. Entre NF4 i INT4 grup-128 la diferència de perplexity és de 6,5 punts i la bateria difereix en una pregunta; i l’interval de confiança del Capítol 4 diu que una pregunta de setze no distingeix absolutament res. Hi ha una demostració més esmolada que l’interval: executa la mateixa bateria amb la penalització de repetició de sèrie del model desactivada, que és el que realment vol dir greedy decoding, i aquestes dues files intercanvien posicions. Una pregunta de setze no és un efecte petit: no és cap efecte. L’advertiment del Capítol 8 també s’aplica: la perplexity només és comparable entre models que comparteixen tokenizer, així que un nombre d’un article d’algú altre no es pot comparar amb el teu.

La columna de coincidència és la més precisa de les tres, i gairebé gratuïta: executa el model de precisió completa amb greedy, i després pregunta al quantitzat, a cada posició, què hauria triat donat el mateix prefix. Té 144 observacions independents en lloc de 16, no necessita ground truth i es degrada suaument allà on la bateria es degrada a salts. També és exactament la quantitat que necessita la secció següent.

Aquesta és la promesa que el Capítol 1 va fer sobre aquest capítol, arribant puntual: les matemàtiques diuen que un model de 4 bits és possible, i l’enginyeria decideix si és usable.

El Capítol 12 ho va anunciar i va deixar la factura aquí.

La idea ve directament de la separació prefill/decode. Verificar una seqüència proposada de $\gamma$ tokens costa una forward pass sobre $\gamma$ posicions: un producte matriu-matriu, amb prou feines més car que la passada sobre una. Així:

La distribució de sortida no canvia. Amb greedy decoding això és obvi: un token només s’accepta si el target l’hauria produït. Amb sampling cal una regla d’acceptació modificada, i Leviathan et al. demostren que la distribució resultant és exactament la del target.¹⁰ Aquesta és la segona optimització exacta d’aquest capítol.

Per tant, tot depèn de la taxa d’acceptació $\alpha$, que és mesurable: és la columna de coincidència de dalt, que és per això que s’hi va calcular. Fent servir cada model quantitzat com a draft per al target de precisió completa, sobre 144 posicions generades:

Els tokens acceptats esperats per passada de verificació, amb longitud de draft $\gamma$, són

i l’acceleració neta ho divideix pel cost propi del draft, una fracció $c$ del target per token:

L’entrada en negreta és la que cal recordar: speculative decoding pot fer que la generació sigui més lenta. Amb un 30 % d’acceptació i un draft que costa una cinquena part del target, pagues cinc forward passes i et quedes 1,4 tokens. L’última columna és l’altra trampa: un draft més llarg només ajuda quan l’acceptació és alta, perquè la cua d’una conjectura de $\gamma$ tokens gairebé mai no s’arriba a tocar. Amb un 90 % d’acceptació, $\gamma = 8$ val 3,40x, i amb un 30 % val 0,79x: la mateixa configuració, una victòria o una pèrdua segons un nombre mesurat en el teu trànsit.

La quantization encongeix un model emmagatzemant la mateixa funció en menys bits. La distillation l’encongeix entrenant un model més petit perquè imiti un de més gran¹¹: una idea anterior al deep learning per gairebé una dècada.¹²

La part subtil és de què aprèn l’estudiant. No de la resposta correcta: s’hi hauria pogut entrenar directament. El que aporta el professor és la distribució completa. Pregunta al model què segueix una frase i mira més enllà de l’argmax:

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

L’etiqueta dura diu jug i res més. L’etiqueta suau diu jug, i també que cup era gairebé igual de bo, bowl plausible, i large —un adjectiu, una continuació gramatical completament diferent— encara viu. Aquest és l’argument original: això és un 7, però s’assembla força a un 1, i la semblança és informació que l’etiqueta dura llença.

També és per això que la distillation fa servir una temperatura. Dividir els logits per $T$ abans del softmax aplana la distribució i augmenta el pes relatiu dels finalistes: en aquesta frase, la ràtio entre el token superior i el tercer baixa de 2,24 a $T = 1$ a 1,50 a $T = 2$: l’arrel quadrada de la primera, que és el que fa dividir els logits per dos a una ràtio. Mateix ordre, més attention de la pèrdua sobre els gairebé encerts. El gradient de l’estudiant porta la incertesa del professor, no només el seu veredicte.

Tot aquest capítol ara és una suma:

on $T$ són els tokens totals residents entre totes les peticions concurrents. Aplicant-ho: les files 7B i 70B assumeixen 8 caps key-value de dimensió 128; la fila 13B, attention multi-head completa amb 40 caps, que és com es van construir aquelles generacions de models —i es nota.

8 GB

16 GB

24 GB

Mira la fila 13B de la taula de 8 GB. Els pesos hi caben —6,2 GB de 8—, així que, segons la manera habitual de parlar, un model 13B "funciona en una targeta de 8 GB". Té 337 tokens de context, que no és una conversa sinó amb prou feines un prompt. "Hi cap" és la pregunta equivocada. La correcta és "amb quant context, i per a quants usuaris alhora".

Mira també les dues files int8 de 16 GB. El 7B obté 65.378 tokens i el 13B en té 3.136: una diferència de vint vegades a partir de 5,6 GB de pesos extra, perquè aquest 13B té attention multi-head i la seva caché costa 800 KB per token contra els 128 KB del 7B. Dos models de mida semblant, un inutilitzable per a context llarg, per una raó que no apareix en cap titular de model card.

Fa tretze capítols això era un perceptró amb dos pesos i un bias. Ara és un transformer que ha estat dissenyat, entrenat, aligned, ensenyat a gastar compute en preguntes difícils i servit a un cost mesurat per token, sense cap capsa interna que hagi quedat tancada.

Això acaba aquí, i acaba expressament.

El Capítol 14 comença amb el model en un altre lloc. No en el teu procés, no a la teva memòria, no en una variable que puguis imprimir: en una màquina que no administres, darrere d’una API key, un port i una factura. Tot el que s’ha mesurat aquí continua passant —el prefill encara s’executa abans del primer token, la caché encara creix amb la conversa, el batch on ets encara pertany a algú altre i encara decideix la teva latència—, però a partir d’ara ho observes a través d’un stream de Server-Sent Events, un finish_reason i un HTTP 429 amb una capçalera Retry-After. Les preguntes canvien amb el punt de vista: no com es calcula aquest gradient sinó per què s’ha triplicat la meva factura. També ho fa el llenguatge, i el Capítol 14 explica aquesta regla en lloc d’anunciar-la: fins aquí el codi contenia pesos, gradients, logits i bytes de tokenizer; a partir d’allà conté una connexió, un reintent, una cancel·lació i estat acumulat. Els tretze capítols que deixes enrere no es descarten en creuar. Són la descripció del que s’executa a l’altre costat del port.

Dues omissions són deliberades. FlashAttention (Dao et al., arXiv:2205.14135) no és una attention diferent: calcula la mateixa funció dividint l’operació en tiles perquè la matriu de puntuacions $n \times n$ no s’escrigui mai a memòria, que és per això que els 67 MB de la segona taula d’aquest capítol són més petits a la pràctica del que suggereix l’aritmètica. I els kernels mateixos es deleguen: la classe 10 del CS336 de Stanford cobreix els sistemes d’inference amb una profunditat que això no intenta, i el repositori llama.cpp i l’especificació GGUF són les fonts principals per al costat CPU.