Si alguna vez has visto a un LLM generar una respuesta larga y te has preguntado por qué parece avanzar a paso de tortuga tras el destello inicial del prompt, estás observando un cuello de botella de hardware en tiempo real. La mayoría de los desarrolladores culpan a su código Python, al framework o al tamaño descomunal del modelo. Analizan funciones, cambian optimizadores y recortan milisegundos en el preprocesamiento. Nada de eso soluciona el problema real. El límite de velocidad no está en tu software. Está en el silicio.
Cada tarea de inferencia de un modelo de lenguaje extenso depende de dos rasgos físicos de la GPU que se encuentra en tu servidor: qué tan rápido puede procesar números y qué tan rápido puede mover esos números a la posición necesaria para ser procesados.
Las matemáticas son baratas. Mover datos no lo es
El marketing de las GPU adora hablar de cómputo. Billones de operaciones de punto flotante por segundo. Las cifras son asombrosas. Pero el cómputo es solo la mitad de la historia. La otra mitad es el ancho de banda de la memoria, la velocidad a la que los datos viajan desde la memoria de alto ancho de banda hacia los núcleos de cómputo donde ocurre la aritmética real.
Un LLM no puede funcionar más rápido que el eslabón más débil de estos dos. Imagina una cocina comercial con veinte chefs maestros. Los hornos están calientes, los cuchillos están afilados y cada cocinero está listo. Pero la entrega de productos llega en bicicleta, una cesta a la vez. La cocina se detiene. Añadir más chefs no lo solucionará. Comprar hornos más rápidos no lo solucionará. El cuello de botella es la carretera.
En las GPU modernas de centros de datos, las unidades aritméticas son tan potentes que a menudo terminan sus cálculos y luego se quedan inactivas, consumiendo ciclos mientras esperan que los pesos y las activaciones fluyan a través de la memoria. Este desequilibrio no es un error en tu código. Es la realidad física de cómo se construyen los chips. El ancho de banda de la memoria no ha seguido el ritmo del cómputo bruto, y los LLM son particularmente crueles con este desequilibrio porque sus pasadas hacia adelante (forward passes) requieren tocar cada uno de los parámetros por cada token de salida.
Por qué los prompts se sienten rápidos y la generación se siente lenta
La inferencia de los LLM se divide en dos fases distintas, y estresan el hardware de formas completamente diferentes.
Prefill ocurre cuando tu prompt llega al modelo por primera vez. Todos los tokens llegan juntos. La GPU puede procesarlos en paralelo utilizando grandes multiplicaciones de matriz por matriz. Miles de unidades aritméticas se activan a la vez y la carga de trabajo se mantiene densa. Esta fase está limitada por el cómputo (compute-bound). ¿Ese repentino estallido de velocidad que ves al principio? Es la GPU haciendo exactamente aquello para lo que fue diseñada.
Decode es donde las cosas se vuelven difíciles. Cuando el modelo genera el siguiente token, lo hace uno a la vez. Esta etapa depende de operaciones de matriz por vector, que utilizan solo una pequeña fracción de la capacidad paralela de la GPU. Peor aún, cada nuevo token obliga a la GPU a recargar todos los pesos del modelo desde la memoria. Las unidades aritméticas quieren trabajar; en su lugar, esperan. El decode está limitado por la memoria (memory-bound). La GPU actúa efectivamente como un costoso controlador de tráfico, transportando parámetros de un lado a otro a través del bus de memoria mientras los motores matemáticos se enfrían. Es por esto que una respuesta de cien palabras puede tardar diez segundos, a pesar de que el análisis inicial del prompt pareció instantáneo.
El KV cache hace que esto sea aún más interesante. Durante el decode, el modelo almacena tensores de clave (key) y valor (value) para cada token anterior para no tener que volver a calcular la atención desde cero. Ese caché crece con la longitud de la secuencia. También reside en la memoria. Así que ahora la GPU no solo está recargando pesos; está leyendo y escribiendo un caché en constante expansión en cada pasada hacia adelante. Los núcleos de cómputo apenas están sudando, mientras que el bus de memoria suda por ambos.
Luchando contra el muro de la memoria
Los ingenieros han desarrollado un pequeño arsenal de técnicas para reducir la cantidad de datos que deben moverse o, al menos, para repartir el coste de moverlos.
Batching es lo más directo. Si la solicitud de un usuario obliga a una carga completa de pesos desde la memoria, procesar ocho o dieciséis solicitudes a la vez permite que la GPU amortice esa carga entre todas ellas. Los pesos se leen una vez y se reutilizan para cada secuencia en el lote. En producción, sistemas de planificación sofisticados agrupan las solicitudes dinámicamente, algo que a veces se denomina continuous o in-flight batching, para que la GPU rara vez se detenga. Es la diferencia entre un autobús y dieciséis coches separados en la misma ruta.
La cuantización ataca directamente el problema del ancho de banda. Los pesos del modelo suelen almacenarse en formatos de punto flotante de dieciséis bits. Al comprimirlos a enteros de ocho bits o incluso de cuatro bits, literalmente reduces a la mitad o más la cantidad de datos que viajan a través del bus. El modelo aún necesita suficiente precisión para producir una salida coherente, pero los métodos modernos de cuantización post-entrenamiento pueden reducir drásticamente la huella de memoria de un modelo sin destruir la calidad. Menos datos en tránsito significan menos tiempo de espera en el controlador de memoria.
FlashAttention reestructura el mecanismo de atención para mantener los resultados intermedios dentro de la rápida memoria integrada (on-chip) de la GPU. La atención estándar tenía que escribir grandes matrices de atención en la memoria externa lenta y luego volver a leerlas. FlashAttention divide el cálculo en bloques más pequeños que caben en la SRAM, realiza los pasos de softmax y escalado en el chip, y solo escribe los resultados finales en la memoria de alto ancho de banda. Intercambia un poco de cómputo adicional por muchos menos viajes de ida y vuelta a la memoria principal, lo cual casi siempre es una apuesta ganadora.
PagedAttention resuelve un tipo diferente de desperdicio de memoria. Durante la decodificación, el caché KV crece de forma impredecible. Los sistemas tradicionales asignan bloques de memoria fijos y contiguos para cada secuencia, dejando grandes huecos a medida que algunas secuencias terminan temprano y otras se expanden. PagedAttention toma prestado el concepto de memoria virtual de los sistemas operativos. Almacena las entradas del caché KV en bloques de tamaño fijo que pueden asignarse de forma no contigua y mapearse a través de una tabla de indirección. Esto evita que la memoria permanezca inactiva dentro de buffers reservados pero medio vacíos y permite tamaños de lote más grandes, lo que a su vez mejora el rendimiento general al mantener el bus de memoria ocupado con trabajo útil en lugar de la sobrecarga por fragmentación.
Cambia la pregunta
Cuando la latencia tiene picos, demasiados equipos se preguntan si deberían cambiar a un modelo más pequeño o reescribir su servidor de inferencia. Esas preguntas importan, pero son secundarias. La primera pregunta debería ser sobre el hardware mismo. ¿Está tu GPU realmente ocupada computando, o está hambrienta de datos?
Observa tus métricas de utilización. Perfila la saturación del ancho de banda de la memoria junto con la ocupación de cómputo de la GPU. Si ves una alta contención de memoria y una baja intensidad aritmética durante la decodificación, no tienes un problema de arquitectura de modelo. Tienes un problema de física. La solución no vendrá de un código Python más limpio. Vendrá de realizar un batching más agresivo, cuantizar tus pesos para pasar más rápido por el conducto, reestructurar la atención para que permanezca en el chip y gestionar el caché KV para que puedas ajustar lotes más grandes sin quedarte sin espacio.
Una vez que ves la inferencia a través de este prisma, la optimización se vuelve mecánica. Dejas de perseguir mitos sobre cómo la inteligencia del modelo ralentiza las cosas y empiezas a tomar decisiones de ingeniería basadas en lo que el hardware realmente puede entregar. Ese es el cambio que separa a los sistemas de producción que escalan de aquellos que simplemente funcionan.