Capítulo 1 — La mecánica de la generación de tokens

Primera entrega del recorrido capítulo por capítulo de LLM Primer VI: Scaling AI Systems. El capítulo que sostiene que casi toda pregunta difícil del serving de LLMs desciende de un único hecho — el bucle que produce cada token está limitado por el ancho de banda de memoria, y el cómputo caro por el que pagaste está inactivo el 99,7 por ciento del tiempo.

Por qué existe este capítulo

Un LLM, en funcionamiento, es un predictor de próximo token envuelto en un bucle. Entran tokens, sale una distribución de probabilidad sobre el siguiente, se elige uno, se añade y el bucle vuelve a ejecutarse. Toda propiedad interesante de un stack de inferencia — batching, cuantización, caché KV, decodificación especulativa, serving desagregado — desciende de una mirada de cerca al interior de ese bucle. El bucle esconde dos cargas de trabajo que comparten un mismo camino de código pero estresan el hardware en direcciones opuestas. Una está limitada por cómputo. La otra, por ancho de banda. En el mismo H100. En el mismo forward pass. Nombrar con precisión esa división es el primer movimiento del libro, y es el marco al que remite cada capítulo posterior.

1.1 El bucle autorregresivo es secuencial por fuerza

El token t+1 es función de todos los tokens hasta t inclusive. El modelo no puede predecir t+2 hasta que t+1 haya sido muestreado, porque la predicción de t+2 requiere que t+1 forme parte de la entrada. No hay ningún kernel ingenioso que paralelice la generación de dos tokens consecutivos para una única secuencia; el carácter secuencial lo impone la estructura de dependencias del cómputo. El coste de reloj de pared de una completación de N tokens es, por tanto, N veces el coste de un paso más un overhead fijo. Cada optimización que sigue en el libro — batches más grandes, especulación por delante de la trayectoria, aritmética por paso más barata — es una respuesta parcial a la pregunta "dado que el bucle tiene que caminar un token cada vez, ¿cómo hacemos cada paso más rápido o cada batch más grande?". El modelo tampoco tiene un cuaderno externo: piensa emitiendo tokens. El bucle es el único mecanismo por el que el modelo puede pensar durante más tiempo, y por eso el chain-of-thought y la decodificación especulativa viven ambos dentro de la misma contabilidad.

1.2 Prefill y decoding estresan el chip en direcciones opuestas

El bucle esconde dos fases. El prefill es el primer forward pass, que consume el prompt del usuario con forma [batch, sequence_length, hidden_dim]. Cada multiplicación de matrices opera a la vez sobre todas las posiciones de la secuencia; la aritmética escala con la longitud de la secuencia; los pesos se leen de HBM una vez y se aplican a muchas filas de trabajo. La intensidad aritmética es alta. El prefill está limitado por cómputo y llega a usar los 989 TFLOP/s BF16 del H100. El decoding es cada forward pass siguiente. La forma de la entrada colapsa a [batch, 1, hidden_dim]. Los pesos de cada capa siguen teniendo que salir de HBM en streaming, pero solo se ejecuta una fila de aritmética contra ellos. La intensidad aritmética se hunde tres órdenes de magnitud. El decoding está limitado por ancho de banda de memoria. En un modelo de 70B en BF16, el prefill sobre un prompt de 2.000 tokens roza el roofline de cómputo del chip; el siguiente forward pass — el primer paso de decode — se ejecuta contra los mismos 140 GB de pesos para producir un solo token. El chip no cambió. La carga sí.

1.3 Un único usuario deja el 99,7 por ciento del H100 inactivo

La consecuencia es que la generación de un único usuario en tiempo real es el peor caso para un acelerador de frontera. Un modelo de 70B en BF16 sobre un H100 SXM decodifica a unos 24 tokens por segundo — velocidad de lectura tranquila para el usuario — y el ancho de banda HBM3 de 3,35 TB/s del chip queda plenamente saturado moviendo 140 GB de pesos por token. Pero a ese ritmo las unidades de cómputo hacen solo unos 3,36 TFLOP/s de los 989 que son capaces. La utilización de cómputo es del 0,34 por ciento. El chip físico no está mal configurado; cada SM está leyendo y multiplicando a máxima velocidad, pero los tensor cores están diseñados para consumir baldosas de muchas filas contra cada baldosa de pesos, y un forward pass de un solo token les da una fila. La capacidad de cómputo está denominada en una unidad (operaciones por byte cargado) que la carga no produce. Alguien sigue pagando cuatro u ocho dólares por hora por todo el chip. La economía del serving de LLMs es, por tanto, la economía de encontrar trabajo para el cómputo aparcado — vía batching, vía ancho de banda por token más barato, vía especulación, vía hardware cuyo punto de equilibrio se ajuste a la carga.

Lo que prepara el Capítulo 1

El resto del libro es la respuesta a la asimetría que aquí se nombra. El Capítulo 2 desmonta la caché KV — la estructura de datos que permite al decoding evitar el recómputo cuadrático y, en el proceso, se convierte en el mayor consumidor único de VRAM en un cluster de serving. Los Capítulos 3 y 4 recorren el sustrato hardware con la lente ancho de banda-frente-a-cómputo. Los Capítulos 5 y 6 reducen la carga de ancho de banda por token reduciendo los pesos. El Capítulo 7 recorre el batching como la palanca a nivel de sistema que convierte el desperdicio limitado por ancho de banda en throughput. Los Capítulos 8 y 9 cambian la forma del trabajo con gestión paginada de KV y decodificación especulativa. Cada movimiento se lee como un intento de llenar el cómputo ocioso que este capítulo acaba de medir.

Próximamente — Capítulo 2: El desafío de la caché KV. El espacio de trabajo que hace asequible el decoding, y la fórmula de memoria que explica por qué los clusters de serving se quedan sin VRAM antes que sin cómputo.