Facer barata a inferencia: KV cache, batching e cuantización

Para xerar un token, un transformer só-decoder toma toda a secuencia ata ese momento, pásaa por todas as capas e le a distribución de probabilidade na última posición. Despois engade o token escollido e volve facelo. Esa descrición é correcta, e é o que fai a execución lenta.

Tamén é enormemente malgastadora, e a razón é a máscara causal do capítulo 9. Os vectores key e value da posición 7 calcúlanse a partir da entrada da posición 7 e das posicións anteriores. Cando chega a posición 8, a posición 7 non pode vela —iso é o que significa causal—, así que os key e value da posición 7 son exactamente os mesmos números ca antes. A execución lenta recalculaos igualmente, en cada paso.

Así que gárdaos. Ese almacén é a key-value cache, a optimización máis determinante no serving de modelos de linguaxe:

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)

Mira o que se lle pasa ao modelo dentro do bucle: nxt, un token. Non a secuencia. A query do novo token fai attention contra todas as keys gardadas na cache, e esas keys nunca ían cambiar. Isto non é unha aproximación: a comprobación de saída idéntica de enriba é a clave. A cache non troca calidade por velocidade; elimina aritmética redundante.

Para ver a escala con limpeza, retira o transformer e mide unha soa cabeza de attention con $d = 64$, un paso de xeración calculado das dúas maneiras:

A columna da dereita é a causa. Recalcular constrúe a matriz de attention completa $n \times n$ en cada paso: o $O(n^2)$ do cadro de notación asintótica do capítulo 9, pagado unha vez por token. Coa cache constrúes unha fila $1 \times n$: con 4,096 tokens, 67 MB de puntuacións fronte a 16 KB.

Contar multiplicacións-acumulacións en vez de milisegundos elimina a máquina do argumento. Para xerar $T$ tokens desde un arranque frío:

Por paso, a versión con cache é lineal no context e a versión sen cache é cuadrática; sumado ao longo dunha xeración, $O(T^2)$ fronte a $O(T^3)$, cun ratio que medra sen límite. A diferenza de nove veces do inicio mediuse sobre 48 tokens: por debaixo da primeira fila desa táboa.

A cache tamén cambia o que ten que estar en memoria. Nunha GPU de portátil de 8 GB xerando 256 tokens en fp16, collendo o pico do asignador e restando os pesos residentes:

8,3 veces máis memoria, gastada para producir os mesmos tokens máis lentamente. Esta é a promesa feita no capítulo 5, chegando desde unha dirección inesperada: alí, o autodiff en modo inverso tiña que manter vivo cada intermedio para o paso cara atrás, e as activacións dominaban a memoria de adestramento. Na inferencia non hai paso cara atrás nin nada que reter para el; así que o que domina a memoria é a cache, e é unha elección deliberada máis ca un custo inevitable.

Mira de novo a execución rápida: o seu primeiro token comportouse de maneira distinta aos outros corenta e sete.

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

O prompt custou 25.6 ms por token e cada token xerado custou 166 ms. Mesmo modelo, mesmo hardware, mesmos pesos, unha diferenza de seis veces por token, e vai no sentido que a maioría da xente non espera. O prompt é a parte barata. A xeración divídese en dúas fases con física realmente distinta:

As dúas metades pódense medir. Prefill, unha pasada sobre $P$ tokens:

Decode, un token contra unha cache de $C$:

Le a segunda táboa dúas veces. Pasar de 16 tokens de context a 1,024 —sesenta e catro veces máis historia sobre a que facer attention— non cambiou o custo dun paso en nada medible. A attention contra a cache é traballo real, pero queda empequenecida polo custo fixo de arrastrar medio billón de pesos polo bus de memoria para producir un vector. Ese custo fixo é a razón de todo o que hai na seguinte sección.

Estas dúas fases son a orixe dos dous números que informa todo sistema de serving. Time to first token é esencialmente prefill, e medra co prompt, que é por iso que unha conversa longa tarda en arrancar. Tokens por segundo é $1/\text{decode step}$, e é aproximadamente constante, que é por iso que a resposta logo flúe de maneira uniforme. Un chat que comeza lento e despois fai streaming con suavidade non é un truco de renderizado. Son estas dúas táboas.

A cache cambia aritmética por memoria, e a memoria que quere non é pequena. Para cada token no context, cada capa mantén un vector key e un vector value por cabeza key-value:

O 2 é por keys e values; todo o demais é a arquitectura. Para o modelo medido ao longo deste capítulo —24 capas, 14 cabezas query, 2 cabezas key-value, dimensión de cabeza 64— en fp16 iso son $2 \times 24 \times 2 \times 64 \times 2 = 12{,}288$ bytes por token.

As fórmulas neste campo teñen o costume de desviarse por un factor de dous, así que compróbao contra o asignador en vez de crer nelas:

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

Exacto, e segue sendo exacto en todas as formas probadas:

As últimas tres filas merecen unha segunda mirada. Trinta e dous usuarios con 2,048 tokens cada un, sesenta e catro con 1,024, cento vinte e oito con 512: a cache é 768 MB en todos os casos, porque os tres conteñen 65,536 tokens. A cache depende só do número total de tokens residentes, non de como se distribúen entre usuarios. Ese feito é a base da sección de batching.

O capítulo 9 introduciu a attention multi-query e grouped-query e adiou a razón ata este capítulo. A razón é esa fórmula, e en concreto o $H_{kv}$ que hai nela.

A attention multi-head estándar dá a cada cabeza query as súas propias cabezas key e value. O modelo aquí ten 14 cabezas query; con attention multi-head completa, a súa cache sería de $2 \times 24 \times 14 \times 64 \times 2 = 86{,}016$ bytes por token: 84 KB en vez de 12 KB, exactamente sete veces máis, o ratio entre cabezas query e cabezas key-value.

A attention multi-query¹ leva isto ao límite: todas as cabezas query comparten unha única cabeza key-value. A attention grouped-query² é o compromiso que gañou: unhas poucas cabezas key-value, cada unha compartida por un grupo de cabezas query, porque a perda de calidade de MQA era real e a de GQA non. Ningunha compra aritmética. Existen para dividir esa fórmula por un enteiro, e espalláronse pola industria no momento en que os context longos fixeron da cache a restrición vinculante.

E faino axiña. Para un modelo da clase 7B con 32 capas e 8 cabezas key-value de dimensión 128, a cache é de 128 KB por token en fp16:

Os propios pesos dese modelo son 13.0 GB en fp16, a cifra da táboa ao final deste capítulo. Así que cun context de 128,000 tokens, a cache dun usuario é máis grande ca o modelo. Esta é a aritmética que o capítulo 16 converte en diñeiro, e é por iso que unha conversa longa non é só unha conversa lenta: ocupa unha porción fixa dunha máquina mentres a solicitude estea viva.

Decode está limitado pola memoria: os pesos arrástranse polo bus para producir un token, e as unidades aritméticas quedan ociosas. Así que mete máis traballo no mesmo paso. Executa varias solicitudes á vez, e os pesos, lidos unha vez, sérvenlles a todas. Medido no mesmo modelo, con cada solicitude mantendo unha cache de 64 tokens e facendo decode dun token:

Le as dúas columnas da dereita unha contra a outra, porque son todo o asunto. Pasar dunha solicitude a dezaseis multiplica o throughput por 6.0 e multiplica a espera de calquera solicitude individual por 2.67. O batch fixo mellor o servidor e peor a cada usuario.

Iso non é un bug que se poida axustar ata desaparecer; é o propio intercambio, e ten un nome en cada lado. A latencia é o que experimenta unha persoa agardando unha resposta. O throughput é aquilo polo que se divide a factura. Ningunha configuración mellora ambas as dúas cousas.

Fíxate tamén onde para. De 16 a 32, o throughput gaña un 9 % mentres a latencia case se duplica: o paso deixou de estar limitado pola memoria e pasou a estar limitado por cómputo, e máis aló dese xeonllo o batch non compra nada. Todo despregamento ten ese xeonllo; a súa localización hai que medila no teu, pero a súa existencia non.

A maneira inxenua de facer batching é recoller $B$ solicitudes, executalas xuntas e devolver cando todas rematen. Pero non rematan xuntas: algunhas respostas teñen vinte tokens e outras cincocentos. Un batch fixo execútase ata que remata o seu membro máis longo, e cada solicitude xa rematada segue ocupando a súa ranura, contribuíndo padding, ata entón.

Colle 64 solicitudes cun sesgo realista de lonxitudes de saída —mediana de 18 tokens, a máis longa 231, 1,874 en total— e simula as dúas políticas co custo por paso medido para oito ranuras:

O throughput mellora 1.6x. A latencia media mellora máis de dez veces, porque baixo batching estático unha solicitude que rematou en catro pasos segue agardando por un veciño de 231 tokens antes de que ninguén saiba nada dela.

Continuous batching³ é a solución, e é tan simple como soa: o batch non é un grupo senón un conxunto de ranuras, e unha ranura que queda libre admite a seguinte solicitude en cola no paso inmediatamente posterior. O scheduler traballa coa granularidade dun token, non dunha solicitude. Todos os stacks de serving en produción fan isto agora.

Ten unha segunda metade, que é a cache. As ranuras que entran e saen deixan a memoria da cache fragmentada, e reservar para cada ranura o seu máximo context posible malgasta a maior parte da reserva. PagedAttention⁴ toma prestada a resposta dos sistemas operativos: gardar a cache en bloques de tamaño fixo cunha táboa de bloques por secuencia, de modo que a cache dunha secuencia poida estar fisicamente dispersa mentres segue sendo loxicamente contigua, o que tamén permite que dúas secuencias cun prefixo compartido compartan os bloques que o conteñen. Iso é sobre o que está construído vLLM, e por iso un motor de serving é un asignador de memoria cun transformer pegado.

A outra metade da factura son os propios pesos. Medio billón de parámetros a catro bytes cada un son 1.98 GB; a dous bytes, 0.99 GB; a un byte, 0.49 GB. Menos bits por peso reducen o modelo no disco, redúceno na memoria e —como decode está limitado polo ancho de banda— fan que cada paso sexa máis rápido, porque hai menos bytes que mover.

O esquema máis simple é a cuantización simétrica por máximo absoluto, e cabe en tres liñas:

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

Escolle unha escala para que o maior peso se mapee ao maior enteiro, divide, redondea, garda os enteiros e a escala. Reconstrúe multiplicando de volta. Non ten nada de intelixente, e funciona, ata que deixa de facelo.

Medido sobre os pesos reais do modelo: as 168 matrices de proxección, 357.8 millóns de parámetros, erro relativo $\lVert W - \hat{W}\rVert / \lVert W \rVert$:

A cuarta fila é o colapso. Un erro relativo de 0.99 na peor matriz significa que a reconstrución non retén practicamente nada do orixinal: a matriz foi substituída por ruído de magnitude aproximadamente correcta. A causa vese no mesmo experimento cunha soa matriz:

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 peso de cada seis mil está máis aló de seis desviacións estándar, e o maior está a 24. Cunha única escala para toda a matriz, ese peso fixa o tamaño do paso para os 4.3 millóns de pesos. En 8 bits hai 256 pasos e o peso típico aínda cae nun significativo. En 4 bits hai 16, o máis externo reservado para un valor que case nada ten, e os pesos ordinarios —que son todos— redondéanse a dous ou tres niveis distintos.

Todo despois desa fila é a mesma reparación a distintas granularidades: dálle á escala un territorio máis pequeno. Por fila de saída divide o erro por 3.4; por grupo de 128 pesos consecutivos volve dividilo. O custo é contabilidade: unha escala de 16 bits por grupo de 128 son $4 + 16/128 = 4.125$ bits por peso en vez de 4, e con iso recupérase boa parte da diferenza.

NF4 abórdao polo outro lado.⁵ Os niveis non teñen por que estar igualmente espazados. Os pesos dentro dun bloque están distribuídos aproximadamente de maneira normal, así que escolle os dezaseis niveis como os cuantís dunha distribución normal: densos preto de cero, onde realmente están os pesos, espallados nas colas, onde non están. Os mesmos catro bits, a mesma escala por bloque, cun bloque máis pequeno —4.25 bits por peso fronte aos 4.125 do grupo-128—, e o erro medido baixa de 0.1323 a 0.0952, un 28 % menos. Parte diso é o bloque máis fino e o resto é poñer os niveis onde está a masa; separar ambas cousas precisaría unha terceira fila.

O cadro de coma flotante do capítulo 2 rematou cunha promesa: que este capítulo cuantizaría pesos a 8 e 4 bits e atoparía un feixe de outlier features negándose a ser apertadas. Aquí están, e explican por que «simplemente redondear os números» nunca ía funcionar nas activacións.

Os pesos de enriba portábanse mal. As activacións xogan noutra liga. Colle un prompt ordinario de 84 tokens, captura o residual stream en cada capa e mide a maior magnitude que alcanza cada unha das 896 dimensións:

A dimensión 62 alcanza 1,579.6 mentres a dimensión mediana nunca pasa de 1.6. Non é unha casualidade dun token nin dunha capa: a mesma dimensión está aí na capa 4 e segue aí na capa 20, case co mesmo valor. Estas son as outlier features,⁶ e son sistemáticas: unha propiedade do modelo adestrado, non da entrada.

O histograma deses 896 máximos por dimensión na capa 16 fai que a forma sexa inequívoca:

     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

Novecentas dimensións nunha morea ordenada por baixo de 8, absolutamente nada durante tres oitavas, e logo unha soa dimensión no extremo afastado. Agora cuantiza ese tensor a INT8 e conta o que pasa:

Catorce niveis de 256. A escala fixouna 1,579.6, así que cada paso ten 12.44 de ancho, e a activación típica —magnitude mediana 0.26, percentil noventa e nove 2.51— non ten onde caer. Por dimensión é máis extremo:

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. Toda a dimensión, cada token, cuantizada ao mesmo número. Asignáronse oito bits e empregáronse aproximadamente cero, e o modelo que le esas activacións recibe unha constante.

Esa medición é a xustificación de todas as técnicas que a xente usa de verdade:

Case todos os artigos sobre cuantización paran na sección anterior: explican o método, citan un ratio de compresión e afirman que a calidade queda «en boa medida preservada». O capítulo 4 trataba de non enganarte a ti mesmo, así que imos descubrilo.

Mesmo modelo, pesos cuantizados in situ con cada esquema, e logo tres medicións: perplexity sobre 2,048 tokens de prosa inglesa reservada —aquí, o borrador deste curso, que é por iso que o repositorio substitúe un libro fixo de dominio público e imprime unha táboa coa mesma forma e números distintos—, unha batería de 16 preguntas factuais curtas con respostas coñecidas baixo greedy decoding, e a fracción de tokens nos que o modelo cuantizado coincide co de precisión completa dado idéntico context.

Hai catro cousas nesa táboa que paga a pena dicir con claridade.

INT8 feito ben é gratis. INT8 por fila marca 22.96 fronte aos 23.08 da referencia: unha diferenza dunha parte en douscentos, que é ruído e debe lerse como «idéntico». Cara a onde apunta o ruído non é estable: no corpus de dominio público do repositorio, os mesmos dous esquemas saen 22.24 fronte a 22.18, a metade desa distancia e apuntando ao outro lado. Coincide co modelo de precisión completa en 142 dos 144 tokens xerados. Un cuarto da memoria fronte á referencia fp32, a metade fronte ao fp16 que realmente despregarías, e sen custo detectable. INT8 feito sen coidado tamén é case gratis: unha escala por matriz custa 0.5 puntos de perplexity e ningunha resposta da batería. Oito bits son tan tolerantes que a granularidade apenas importa, que é exactamente por iso que a xente xeneraliza de INT8 a INT4 e sae escaldada.

INT4 cunha escala por tensor destrúe o modelo. Perplexity 365 millóns: non degradado, aniquilado. A granularidade convértese en todo o xogo: por tensor 365,416,000, por fila 46.18, por grupo de 128 31.08, NF4 24.55. Os mesmos catro bits por peso, un factor de quince millóns entre o peor e o mellor.

Perplexity é un instrumento groso e a batería aínda máis. Entre NF4 e INT4 grupo-128 a diferenza de perplexity é de 6.5 puntos e a batería difire nunha pregunta, e o intervalo de confianza do capítulo 4 di que unha pregunta de dezaseis non distingue absolutamente nada. Hai unha demostración máis afiada ca o intervalo: executa a mesma batería coa penalización de repetición de serie do modelo desactivada, que é o que realmente significa greedy decoding, e esas dúas filas intercambian posicións. Unha pregunta de dezaseis non é un efecto pequeno: non é efecto. A advertencia do capítulo 8 tamén se aplica: perplexity só é comparable entre modelos que comparten tokenizer, así que un número dun artigo alleo non se pode comparar co teu.

A columna de coincidencia é a máis precisa das tres, e case gratis: executa o modelo de precisión completa con greedy decoding, e despois pregúntalle ao cuantizado, en cada posición, que tería escollido dado o mesmo prefixo. Ten 144 observacións independentes en vez de 16, non precisa ground truth e degrádase suavemente onde a batería se degrada a saltos. Tamén é exactamente a cantidade que precisa a seguinte sección.

Esta é a promesa que o capítulo 1 fixo sobre este capítulo, chegando puntual: as matemáticas din que un modelo de 4 bits é posible, e a enxeñaría decide se é usable.

O capítulo 12 anunciouno e deixou a factura aquí.

A idea sae directamente da división prefill/decode. Verificar unha secuencia proposta de $\gamma$ tokens custa unha pasada forward sobre $\gamma$ posicións: un produto matriz-matriz, apenas máis caro ca a pasada sobre unha. Así que:

A distribución de saída non cambia. Con greedy decoding iso é obvio: un token só se acepta se o target o tería producido. Con sampling require unha regra de aceptación modificada, e Leviathan et al. demostran que a distribución resultante é exactamente a do target.¹⁰ Esta é a segunda optimización exacta deste capítulo.

Polo tanto, todo depende da taxa de aceptación $\alpha$, que se pode medir: é a columna de coincidencia de enriba, que é por iso que se calculou alí. Usando cada modelo cuantizado como draft para o target de precisión completa, sobre 144 posicións xeradas:

Os tokens esperados aceptados por pasada de verificación, cunha lonxitude draft $\gamma$, son

e o speedup neto divide iso polo propio custo do draft, unha fracción $c$ do target por token:

A entrada en negra é a que hai que lembrar: speculative decoding pode facer a xeración máis lenta. Cunha aceptación do 30 % e un draft que custa unha quinta parte do target, pagas cinco pasadas forward e conservas 1.4 tokens. A última columna é a outra trampa: un draft máis longo só axuda cando a aceptación é alta, porque a cola dunha suposición de $\gamma$ tokens case nunca se alcanza. Cunha aceptación do 90 %, $\gamma = 8$ vale 3.40x, e cun 30 % vale 0.79x: a mesma configuración, unha vitoria ou unha perda segundo un número medido no teu tráfico.

A cuantización reduce un modelo gardando a mesma función en menos bits. A destilación redúceo adestrando un modelo máis pequeno para imitar un máis grande¹¹, unha idea anterior ao deep learning en case unha década.¹²

A parte sutil é de que aprende o estudante. Non da resposta correcta: podería terse adestrado directamente con iso. O que engade o profesor é a distribución completa. Pregúntalle ao modelo que segue a unha frase e mira máis aló do argmax:

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

A hard label di jug e nada máis. A soft label di jug, e tamén que cup era case igual de bo, bowl plausible, e large —un adxectivo, unha continuación gramatical completamente distinta— seguía viva. Ese é o argumento orixinal: isto é un 7, pero parécese bastante a un 1, e a semellanza é información que a hard label tira ao lixo.

Tamén é por iso que a destilación usa temperatura. Dividir os logits por $T$ antes da softmax achanda a distribución e aumenta o peso relativo dos segundos clasificados: nesta frase, o ratio entre o token principal e o terceiro baixa de 2.24 con $T = 1$ a 1.50 con $T = 2$, a raíz cadrada do primeiro, que é o que dividir os logits por dous lle fai a un ratio. Mesma orde, máis attention da perda nos case erros. O gradient do estudante leva a incerteza do profesor, non só o seu veredicto.

Todo neste capítulo é agora unha suma:

onde $T$ son os tokens totais residentes en todas as solicitudes concorrentes. Aplicándoo: as filas 7B e 70B asumen 8 cabezas key-value de dimensión 128; a fila 13B, attention multi-head completa con 40 cabezas, que é como se construíron esas xeracións de modelos, e nótase.

8 GB

16 GB

24 GB

Mira a fila 13B na táboa de 8 GB. Os pesos caben —6.2 GB de 8—, así que coa maneira habitual de falar, un modelo 13B «execútase nunha tarxeta de 8 GB». Ten 337 tokens de context, que non é unha conversa senón apenas un prompt. «Cabe?» é a pregunta equivocada. A correcta é «con canto context, e para cantos usuarios á vez».

Mira tamén as dúas filas int8 de 16 GB. O 7B obtén 65,378 tokens e o 13B obtén 3,136: unha diferenza de vinte veces a partir de 5.6 GB de pesos extra, porque este 13B ten attention multi-head e a súa cache custa 800 KB por token fronte aos 128 KB do 7B. Dous modelos de tamaño parecido, un inutilizable para context longo, por unha razón que non aparece no titular de ningunha model card.

Hai trece capítulos isto era un perceptrón con dous pesos e un bias. Agora é un transformer que foi deseñado, adestrado, aliñado, ensinado a gastar cómputo en preguntas difíciles e servido cun custo medido por token, sen que quede ningunha caixa sen abrir dentro del.

Isto remata aquí, e remata a propósito.

O capítulo 14 comeza co modelo noutro sitio. Non no teu proceso, non na túa memoria, non nunha variable que poidas imprimir: nunha máquina que non administras, detrás dunha API key, un porto e unha factura. Todo o medido aquí segue acontecendo: prefill segue executándose antes do primeiro token, a cache segue medrando coa conversa, o batch no que estás segue pertencendo a outra persoa e segue decidindo a túa latencia; pero a partir de agora obsérvalo a través dun fluxo de Server-Sent Events, un finish_reason e un HTTP 429 cunha cabeceira Retry-After. As preguntas cambian co punto de vista: non como se calcula este gradient, senón por que se triplicou a miña factura. Tamén cambia a linguaxe, e o capítulo 14 explica esa regra en vez de anunciala: ata aquí o código contiña pesos, gradients, logits e bytes de tokenizer; a partir de aí contén unha conexión, un reintento, unha cancelación e estado acumulado. Os trece capítulos que deixas atrás non se descartan ao cruzar. Son a descrición do que se executa ao outro lado do porto.

Dúas omisións son deliberadas. FlashAttention (Dao et al., arXiv:2205.14135) non é unha attention diferente: calcula a mesma función dividindo a operación en tiles para que a matriz de puntuacións $n \times n$ nunca se escriba en memoria, que é por iso que os 67 MB da segunda táboa deste capítulo son menores na práctica do que suxire a aritmética. E os propios kernels deléganse: a lección 10 do CS336 de Stanford cobre sistemas de inferencia coa profundidade que isto non intenta, e o repositorio llama.cpp e a especificación GGUF son as fontes primarias para o lado CPU.