Abaratar la inferencia: KV cache, batching y cuantización

Para generar un token, un transformer solo decoder toma toda la secuencia hasta el momento, la pasa por cada capa y lee la distribución de probabilidad de la última posición. Luego añade el token elegido y vuelve a hacerlo. Esa descripción es correcta, y es lo que hace la ejecución lenta.

También es enormemente derrochadora, y la razón es la máscara causal del capítulo 9. Los vectores key y value de la posición 7 se calculan a partir de la entrada de la posición 7 y de las posiciones anteriores. Cuando llega la posición 8, la posición 7 no puede verla —eso es lo que significa causal—, así que los key y value de la posición 7 son exactamente los mismos números que antes. La ejecución lenta los recalcula de todos modos, en cada paso.

Así que guárdalos. Ese almacén es la key-value cache, la optimización más importante en el servicio de modelos de lenguaje:

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 qué se alimenta al modelo dentro del bucle: nxt, un token. No la secuencia. La query del nuevo token atiende contra cada key cacheada, y las keys cacheadas nunca iban a cambiar. Esto no es una aproximación: la comprobación de salida idéntica de arriba es precisamente el punto. La cache no intercambia calidad por velocidad; elimina aritmética redundante.

Para ver el escalado con limpieza, quita el transformer y mide una sola cabeza de attention con $d = 64$, un paso de generación calculado de las dos formas:

La columna de la derecha es la causa. Recalcular construye toda la matriz de attention $n \times n$ en cada paso: el $O(n^2)$ del recuadro de notación asintótica del capítulo 9, pagado una vez por token. Con la cache construyes en su lugar una fila $1 \times n$: con 4,096 tokens, 67 MB de puntuaciones frente a 16 KB.

Contar multiplicaciones-acumulaciones en lugar de milisegundos saca la máquina del argumento. Para generar $T$ tokens desde un arranque en frío:

Por paso, la versión cacheada es lineal en el context y la no cacheada cuadrática; sumado a lo largo de una generación, $O(T^2)$ frente a $O(T^3)$, con una ratio que crece sin límite. La diferencia de nueve veces del inicio se midió sobre 48 tokens: menos que la primera fila de esa tabla.

La cache también cambia qué tiene que estar en memoria. En una GPU de portátil de 8 GB generando 256 tokens en fp16, tomando el pico del asignador y restando los pesos residentes:

8,3 veces más memoria, gastada para producir los mismos tokens más despacio. Esta es la promesa hecha en el capítulo 5, llegando desde una dirección inesperada: allí, la autodiferenciación en modo inverso tenía que mantener vivo cada intermedio para la pasada hacia atrás, y las activaciones dominaban la memoria de entrenamiento. En inferencia no hay pasada hacia atrás ni nada que retener para ella; así que lo que domina la memoria en su lugar es la cache, y es una elección deliberada más que un coste inevitable.

Mira de nuevo la ejecución rápida: su primer token se comportó de forma distinta a los otros cuarenta y siete.

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

El prompt costó 25,6 ms por token y cada token generado costó 166 ms. Mismo modelo, mismo hardware, mismos pesos, una diferencia de seis veces por token, y va en la dirección que la mayoría no espera. El prompt es la parte barata. La generación se divide en dos fases con físicas genuinamente distintas:

Ambas mitades son medibles. Prefill, una pasada sobre $P$ tokens:

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

Lee la segunda tabla dos veces. Pasar de 16 tokens de context a 1,024 —sesenta y cuatro veces más historial al que atender— cambió el coste de un paso en nada medible. La attention contra la cache es trabajo real, pero queda eclipsada por el coste fijo de arrastrar medio millardo de pesos por el bus de memoria para producir un vector. Ese coste fijo es la razón de todo en la siguiente sección.

Estas dos fases son el origen de los dos números que informa todo sistema de servicio. Tiempo hasta el primer token es esencialmente prefill, y crece con el prompt, por eso una conversación larga se siente lenta al empezar. Tokens por segundo es $1/\text{decode step}$, y es aproximadamente constante, por eso la respuesta luego fluye de forma uniforme. Un chat que empieza despacio y después transmite con suavidad no es un truco de renderizado. Son estas dos tablas.

La cache intercambia aritmética por memoria, y la memoria que quiere no es poca. Por cada token en el context, cada capa guarda un vector key y un vector value por cabeza key-value:

El 2 es por keys y values; todo lo demás es la arquitectura. Para el modelo medido a lo largo de este capítulo —24 capas, 14 query heads, 2 key-value heads, dimensión de cabeza 64—, en fp16 son $2 \times 24 \times 2 \times 64 \times 2 = 12{,}288$ bytes por token.

Las fórmulas en este campo tienen la costumbre de equivocarse por un factor de dos, así que compruébalo contra el asignador en lugar de creerlo:

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, y sigue siendo exacto en todas las formas probadas:

Las tres últimas filas merecen otra mirada. Treinta y dos usuarios con 2,048 tokens cada uno, sesenta y cuatro con 1,024, ciento veintiocho con 512: la cache es de 768 MB en todos los casos, porque las tres contienen 65,536 tokens. La cache depende solo del número total de tokens residentes, no de cómo se distribuyen entre usuarios. Ese hecho es la base de la sección sobre batching.

El capítulo 9 introdujo multi-query attention y grouped-query attention y pospuso la razón hasta este capítulo. La razón es esa fórmula, y en concreto el $H_{kv}$ que contiene.

La multi-head attention estándar da a cada query head sus propias cabezas key y value. El modelo de aquí tiene 14 query heads; con multi-head attention completa, su cache sería de $2 \times 24 \times 14 \times 64 \times 2 = 86{,}016$ bytes por token: 84 KB en lugar de 12 KB, exactamente siete veces más, la ratio entre query heads y key-value heads.

Multi-query attention¹ lleva esto al límite: todas las query heads comparten una sola key-value head. Grouped-query attention² es el compromiso que ganó: un puñado de key-value heads, cada una compartida por un grupo de query heads, porque la pérdida de calidad de MQA era real y la de GQA no lo es. Ninguna compra aritmética. Existen para dividir esa fórmula por un entero, y se extendieron por la industria en cuanto los context largos hicieron de la cache la restricción vinculante.

Y lo hace rápido. Para un modelo de clase 7B con 32 capas y 8 key-value heads de dimensión 128, la cache es de 128 KB por token en fp16:

Los propios pesos de ese modelo ocupan 13,0 GB en fp16, la cifra de la tabla al final de este capítulo. Así que con un context de 128,000 tokens, la cache de un usuario es mayor que el modelo. Esta es la aritmética que el capítulo 16 convierte en dinero, y por eso una conversación larga no es solo una conversación lenta: ocupa una porción fija de una máquina mientras la solicitud siga viva.

Decode está limitado por memoria: los pesos se arrastran por el bus para producir un token, y las unidades aritméticas quedan ociosas. Así que mete más trabajo en el mismo paso. Ejecuta varias solicitudes a la vez, y los pesos, leídos una vez, sirven a todas. Medido en el mismo modelo, con cada solicitud manteniendo una cache de 64 tokens y decodificando un token:

Lee las dos columnas de la derecha una contra la otra, porque son todo el asunto. Pasar de una solicitud a dieciséis multiplica el throughput por 6,0 y multiplica la espera de cualquier solicitud individual por 2,67. El batch hizo mejor al servidor y peor a cada usuario.

No es un bug que se pueda ajustar hasta que desaparezca; es el intercambio en sí, y tiene un nombre en cada lado. La latencia es lo que experimenta una persona que espera una respuesta. El throughput es aquello entre lo que se divide la factura. Ningún ajuste mejora ambos.

Fíjate también dónde se detiene. De 16 a 32, el throughput gana un 9 % mientras la latencia casi se duplica: el paso ha dejado de estar limitado por memoria y ha pasado a estar limitado por cómputo, y más allá de esa rodilla el batch no compra nada. Todo despliegue tiene una rodilla así; su ubicación hay que medirla en el tuyo, pero su existencia no.

La forma ingenua de hacer batching es reunir $B$ solicitudes, ejecutarlas juntas y devolver cuando todas hayan terminado. Pero no terminan juntas: algunas respuestas tienen veinte tokens y otras quinientos. Un batch fijo se ejecuta hasta que termina su miembro más largo, y cada solicitud ya terminada sigue ocupando su hueco, aportando padding, hasta entonces.

Toma 64 solicitudes con una asimetría realista de longitudes de salida —mediana de 18 tokens, la más larga de 231, 1,874 en total— y simula ambas políticas con el coste por paso medido para ocho huecos:

El throughput mejora 1,6x. La latencia media mejora más de diez veces, porque con batching estático una solicitud que terminó en cuatro pasos sigue esperando a un vecino de 231 tokens antes de que nadie oiga nada de ella.

Continuous batching³ es la solución, y es tan simple como suena: el batch no es un grupo sino un conjunto de huecos, y un hueco que se libera admite la siguiente solicitud en cola en el mismísimo paso siguiente. El planificador trabaja a la granularidad de un token en lugar de una solicitud. Todo stack de serving en producción lo hace ya.

Tiene una segunda mitad, que es la cache. Los huecos que aparecen y desaparecen dejan la memoria de cache fragmentada, y reservar para cada hueco su context máximo posible desperdicia la mayor parte de la reserva. PagedAttention⁴ toma prestada la respuesta de los sistemas operativos: almacenar la cache en bloques de tamaño fijo con una tabla de bloques por secuencia, para que la cache de una secuencia pueda estar físicamente dispersa mientras sigue siendo lógicamente contigua; lo que también permite que dos secuencias con un prefijo compartido compartan los bloques que lo contienen. Eso es sobre lo que se construye vLLM, y por eso un motor de serving es un asignador de memoria con un transformer acoplado.

La otra mitad de la factura son los propios pesos. Medio millardo de parámetros a cuatro bytes cada uno son 1,98 GB; a dos bytes, 0,99 GB; a un byte, 0,49 GB. Menos bits por peso reducen el modelo en disco, lo reducen en memoria y —como decode está limitado por ancho de banda— hacen que cada paso sea más rápido, porque hay menos bytes que mover.

El esquema más simple es la cuantización simétrica por máximo absoluto, y cabe en tres líneas:

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

Elige una escala para que el peso mayor se mapee al entero mayor, divide, redondea, guarda los enteros y la escala. Reconstruye multiplicando de vuelta. No tiene nada de ingenioso, y funciona, justo hasta que deja de hacerlo.

Medido sobre los pesos reales del modelo: las 168 matrices de proyección, 357,8 millones de parámetros, error relativo $\lVert W - \hat{W}\rVert / \lVert W \rVert$:

La cuarta fila es el colapso. Un error relativo de 0,99 en la peor matriz significa que la reconstrucción no conserva esencialmente nada del original: la matriz ha sido reemplazada por ruido de una magnitud más o menos adecuada. La causa se ve en el mismo experimento sobre una sola 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ás allá de seis desviaciones estándar, y el mayor está a 24. Con una sola escala para toda la matriz, ese peso fija el tamaño del paso para los 4,3 millones restantes. Con 8 bits hay 256 pasos y el peso típico aún cae en uno significativo. Con 4 bits hay 16, el más extremo reservado para un valor que casi nada tiene, y los pesos ordinarios —que son todos— redondean a dos o tres niveles distintos.

Todo después de esa fila es la misma reparación con distintas granularidades: da a la escala un territorio más pequeño. Por fila de salida divide el error por 3,4; por grupo de 128 pesos consecutivos lo vuelve a dividir. El coste es contabilidad: una escala de 16 bits por grupo de 128 son $4 + 16/128 = 4.125$ bits por peso en lugar de 4, y recupera la mayor parte de la brecha.

NF4 lo aborda desde el otro lado.⁵ Los niveles no tienen por qué estar espaciados por igual. Los pesos dentro de un bloque se distribuyen aproximadamente de forma normal, así que elige los dieciséis niveles como los cuantiles de una distribución normal: densos cerca de cero, donde están realmente los pesos, dispersos en las colas, donde no están. Los mismos cuatro bits, el mismo escalado por bloque, en un bloque más pequeño —4,25 bits por peso frente a los 4,125 del grupo de 128— y el error medido cae de 0,1323 a 0,0952, un 28 % menos. Parte de eso es el bloque más fino y el resto es poner los niveles donde está la masa; separarlos exigiría una tercera fila.

El recuadro de coma flotante del capítulo 2 terminó con una promesa: que este capítulo cuantizaría pesos a 8 y 4 bits y encontraría un puñado de características outlier que se negaban a comprimirse. Aquí están, y explican por qué «simplemente redondear los números» nunca iba a funcionar con activaciones.

Los pesos de arriba se comportaban mal. Las activaciones juegan en otra liga. Toma un prompt ordinario de 84 tokens, captura el flujo residual en cada capa y mide la mayor magnitud que alcanza cada una de las 896 dimensiones:

La dimensión 62 llega a 1,579,6 mientras la dimensión mediana nunca supera 1,6. No es una rareza de un token o una capa: la misma dimensión está ahí en la capa 4 y sigue ahí en la capa 20, con casi el mismo valor. Estas son las outlier features,⁶ y son sistemáticas: una propiedad del modelo entrenado, no de la entrada.

El histograma de esos 896 máximos por dimensión en la capa 16 hace que la forma sea inconfundible:

     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

Novecientas dimensiones en un montón ordenado por debajo de 8, nada en absoluto durante tres octavas, y luego una dimensión sola en el extremo lejano. Ahora cuantiza ese tensor a INT8 y cuenta qué ocurre:

Catorce niveles de 256. La escala la fijó 1,579,6, así que cada paso tiene anchura 12,44, y la activación típica —magnitud mediana 0,26, percentil noventa y nueve 2,51— no tiene dónde caer. Por dimensión es más crudo:

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 la dimensión, cada token, cuantizada al mismo número. Se asignaron ocho bits y se usaron aproximadamente cero, y el modelo que lee esas activaciones recibe una constante.

Esa medición es la justificación de todas las técnicas que la gente usa de verdad:

Casi todos los artículos sobre cuantización se detienen en la sección anterior: explican el método, citan una ratio de compresión y afirman que la calidad se «preserva en gran medida». El capítulo 4 iba de no engañarte a ti mismo, así que averigüémoslo.

El mismo modelo, pesos cuantizados in situ con cada esquema, y luego tres mediciones: perplejidad en 2,048 tokens de prosa inglesa retenida —aquí, el borrador de este curso, motivo por el cual el repositorio lo sustituye por un libro fijo de dominio público e imprime una tabla de la misma forma con números distintos—, una batería de 16 preguntas factuales cortas con respuestas conocidas bajo greedy decoding, y la fracción de tokens en la que el modelo cuantizado coincide con el de precisión completa dado un context idéntico.

Merece la pena decir claramente cuatro cosas de esa tabla.

INT8 bien hecho sale gratis. INT8 por fila puntúa 22,96 frente a los 23,08 de la referencia: una brecha de una parte en doscientas, que es ruido y debe leerse como «idéntico». Hacia qué lado apunta el ruido no es estable: en el corpus de dominio público del repositorio, los mismos dos esquemas salen 22,24 frente a 22,18: la mitad de esa distancia, y apuntando al otro lado. Coincide con el modelo de precisión completa en 142 de 144 tokens generados. Un cuarto de la memoria frente a la referencia fp32, la mitad frente al fp16 que desplegarías de verdad, y sin coste detectable. INT8 hecho sin cuidado también es casi gratis: una escala por matriz cuesta 0,5 puntos de perplejidad y ninguna respuesta de la batería. Ocho bits perdonan lo suficiente para que la granularidad apenas importe, que es exactamente por lo que la gente generaliza de INT8 a INT4 y se hace daño.

INT4 con una escala por tensor destruye el modelo. Perplejidad 365 millones: no degradado, aniquilado. La granularidad es entonces todo el juego: por tensor 365,416,000, por fila 46,18, por grupo de 128 31,08, NF4 24,55. Los mismos cuatro bits por peso, un factor de quince millones entre el peor y el mejor.

La perplejidad es un instrumento tosco y la batería uno más tosco aún. Entre NF4 e INT4 grupo 128 la brecha de perplejidad es de 6,5 puntos y la batería difiere en una pregunta; y el intervalo de confianza del capítulo 4 dice que una pregunta de dieciséis no distingue absolutamente nada. Hay una demostración más nítida que el intervalo: ejecuta la misma batería con la penalización de repetición por defecto del modelo desactivada, que es lo que realmente significa greedy decoding, y esas dos filas intercambian posiciones. Una pregunta de dieciséis no es un efecto pequeño, es ningún efecto. También aplica la advertencia del capítulo 8: la perplejidad solo es comparable entre modelos que comparten tokenizer, así que un número del artículo de otra persona no puede compararse con el tuyo.

La columna de coincidencia es la más afilada de las tres, y casi gratis: ejecuta el modelo de precisión completa de forma greedy, y luego pregunta al cuantizado, en cada posición, qué habría elegido dado el mismo prefijo. Tiene 144 observaciones independientes en lugar de 16, no necesita verdad de referencia y se degrada suavemente donde la batería se degrada a saltos. También es exactamente la cantidad que necesita la siguiente sección.

Esta es la promesa que hizo el capítulo 1 sobre este capítulo, llegando a tiempo: las matemáticas dicen que un modelo de 4 bits es posible, y la ingeniería decide si es utilizable.

El capítulo 12 anunció esto y dejó aquí la factura.

La idea sale directamente de la división prefill/decode. Verificar una secuencia propuesta de $\gamma$ tokens cuesta una pasada hacia delante sobre $\gamma$ posiciones: un producto matriz-matriz, apenas más caro que la pasada sobre una. Así que:

La distribución de salida no cambia. Con greedy decoding eso es obvio: un token se acepta solo si el objetivo lo habría producido. Con sampling requiere una regla de aceptación modificada, y Leviathan et al. demuestran que la distribución resultante es exactamente la del objetivo.¹⁰ Esta es la segunda optimización exacta de este capítulo.

Por tanto, todo depende de la tasa de aceptación $\alpha$, que es medible: es la columna de coincidencia de arriba, por eso se calculó allí. Usando cada modelo cuantizado como draft para el objetivo de precisión completa, sobre 144 posiciones generadas:

Los tokens aceptados esperados por pasada de verificación, con longitud de draft $\gamma$, son

y la aceleración neta divide eso por el propio coste del draft, una fracción $c$ del objetivo por token:

La entrada en negrita es la que hay que recordar: speculative decoding puede hacer que la generación sea más lenta. Con un 30 % de aceptación y un draft que cuesta una quinta parte del objetivo, pagas cinco pasadas hacia delante y conservas 1,4 tokens. La última columna es la otra trampa: un draft más largo solo ayuda cuando la aceptación es alta, porque la cola de una conjetura de $\gamma$ tokens casi nunca se alcanza. Con 90 % de aceptación, $\gamma = 8$ vale 3,40x; con 30 %, vale 0,79x: la misma configuración, una victoria o una pérdida según un número medido en tu tráfico.

La cuantización encoge un modelo almacenando la misma función en menos bits. La destilación lo encoge entrenando un modelo más pequeño para imitar a uno más grande¹¹, una idea anterior al deep learning en casi una década.¹²

La parte sutil es de qué aprende el estudiante. No de la respuesta correcta: podría haberse entrenado directamente con ella. Lo que añade el profesor es la distribución completa. Pregunta al modelo qué sigue a una frase y mira más allá del argmax:

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

La etiqueta hard dice jug y nada más. La etiqueta soft dice jug, y también que cup era casi igual de bueno, bowl plausible, y large —un adjetivo, una continuación gramatical completamente distinta— seguía vivo. Ese es el argumento original: esto es un 7, pero se parece bastante a un 1, y el parecido es información que la etiqueta hard tira a la basura.

También por eso la destilación usa una temperatura. Dividir los logits por $T$ antes de la softmax aplana la distribución y eleva el peso relativo de los segundos: en esta frase, la ratio entre el token superior y el tercero cae de 2,24 con $T = 1$ a 1,50 con $T = 2$, la raíz cuadrada de la primera, que es lo que dividir los logits por dos hace a una ratio. Mismo orden, más attention de la pérdida en los fallos cercanos. El gradient del estudiante lleva la incertidumbre del profesor y no solo su veredicto.

Todo en este capítulo es ahora una suma:

donde $T$ son los tokens totales residentes entre todas las solicitudes concurrentes. Al aplicarlo: las filas 7B y 70B suponen 8 key-value heads de dimensión 128; la fila 13B, multi-head attention completa con 40 cabezas, que es como se construyeron esas generaciones de modelos, y se nota.

8 GB

16 GB

24 GB

Mira la fila 13B de la tabla de 8 GB. Los pesos caben —6,2 GB de 8—, así que, según la forma habitual de hablar, un modelo 13B «funciona en una tarjeta de 8 GB». Tiene 337 tokens de context, que no es una conversación sino apenas un prompt. «¿Cabe?» es la pregunta equivocada. La correcta es «con cuánto context y para cuántos usuarios a la vez».

Mira también las dos filas int8 de 16 GB. El 7B consigue 65,378 tokens y el 13B consigue 3,136: una diferencia de veinte veces por 5,6 GB de pesos extra, porque este 13B tiene multi-head attention y su cache cuesta 800 KB por token frente a los 128 KB del 7B. Dos modelos de tamaño parecido, uno inutilizable para context largo, por una razón que no aparece en el titular de ninguna model card.

Hace trece capítulos esto era un perceptrón con dos pesos y un sesgo. Ahora es un transformer que ha sido diseñado, entrenado, alineado, enseñado a gastar cómputo en preguntas difíciles y servido a un coste medido por token, sin que quede ninguna caja sin abrir.

Esto termina aquí, y termina a propósito.

El capítulo 14 empieza con el modelo en otro lugar. No en tu proceso, no en tu memoria, no en una variable que puedas imprimir: en una máquina que no administras, detrás de una API key, un puerto y una factura. Todo lo medido aquí sigue ocurriendo: prefill sigue ejecutándose antes del primer token, la cache sigue creciendo con la conversación, el batch en el que estás sigue perteneciendo a otra persona y sigue decidiendo tu latencia; pero a partir de ahora lo observas a través de un flujo de Server-Sent Events, un finish_reason y un HTTP 429 con una cabecera Retry-After. Las preguntas cambian con el punto de vista: no cómo se calcula este gradient, sino por qué se ha triplicado mi factura. También cambia el lenguaje, y el capítulo 14 explica esa regla en lugar de anunciarla: hasta aquí el código contenía pesos, gradientes, logits y bytes de tokenizer; a partir de ahí contiene una conexión, un reintento, una cancelación y estado acumulado. Los trece capítulos que dejas atrás no se descartan al cruzar. Son la descripción de lo que se está ejecutando al otro lado del puerto.

Dos omisiones son deliberadas. FlashAttention (Dao et al., arXiv:2205.14135) no es una attention distinta: calcula la misma función dividiendo la operación en teselas para que la matriz de puntuaciones $n \times n$ nunca se escriba en memoria, por eso los 67 MB de la segunda tabla de este capítulo son menores en la práctica de lo que sugiere la aritmética. Y los propios kernels quedan delegados: la clase 10 del CS336 de Stanford cubre los sistemas de inferencia con una profundidad que esto no intenta, y el repositorio llama.cpp y la especificación GGUF son las fuentes primarias para el lado CPU.