Optimización de la inferencia de LLM: prefill, decodificación y LLMOps empresarial
Cuellos de botella en el prellenado previo vs. la decodificación, procesamiento por lotes continuo, FlashAttention, cuantización, PagedAttention, decodificación especulativa, prellenado previo por bloques y servicio desagregado.
Diseñar un sistema de servicio para LLM de alto rendimiento y bajo costo implica planificar teniendo en cuenta las limitaciones reales del hardware, en lugar de simplemente envolver una API con la esperanza de que las GPUs permanezcan ocupadas.
Los presupuestos iniciales de las empresas para la IA generativa se centraron en el entrenamiento y el ajuste fino. Una vez que las aplicaciones salen del laboratorio, el costo cambia: inferencias continuas limitadas por las GPUs y picos de latencia que no permiten predecir su comportamiento.
La escala obliga a hacer compromisos tanto físicos como financieros. Los sistemas rápidos y económicos van más allá de las capas externas para analizar cómo realmente se ejecutan las inferencias en el silicio.
1. Dos fases, dos cuellos de botella
Cada solicitud de inferencia se divide en fase de prellenado y fase de decodificación. Cada una de estas fases se topa con un tipo diferente de limitación del hardware.
Prefill (generalmente limitado por el procesamiento)
Prefill procesa todos los tokens de la instrucción de una sola vez y genera activaciones de tipo clave-valor en paralelo. Las instrucciones demasiado largas hacen que las multiplicaciones matriciales de gran tamaño saturen los recursos de cómputo, por lo que esta fase está limitada por el cálculo. Las instrucciones cortas o lotes pequeños pueden invertir esta situación: no hay suficiente operación aritmética para ocultar el tráfico de memoria, por lo que Prefill queda limitado por la memoria. El tiempo de Prefill representa la primera espera del usuario.
Decodificación (generalmente limitada por el ancho de banda de la memoria)
Una vez que la instrucción está procesada, los tokens llegan uno por uno. En cada paso se cargan los pesos completos del modelo y el historial de clave-valor en constante crecimiento desde la Memoria de Ancho de Banda Alto (HBM) hacia la SRAM de la GPU. Con tamaños de lote bajos, esta transferencia se repite con tanta frecuencia que la GPU espera por el ancho de banda en lugar de por capacidad de cómputo.
Una nuanza determina el resto del diseño. Un tamaño de lote creciente permite distribuir de manera uniforme la carga de obtención de pesos entre muchas secuencias, y el proceso de decodificación vuelve a estar limitado por los recursos de cómputo. Ese punto de transición es la razón por la que existe el loteo continuo: permite que la decodificación se realice en un régimen en el que las unidades aritméticas permanezcan ocupadas.
Ecuación de latencia
La latencia total de la solicitud se divide en las partes de prellenado y decodificación:
T_total = TTFT + (N_tokens − 1) × TPOT
- TTFT (tiempo hasta el primer token) abarca todo el proceso de prellenado del prompt más el primer token de salida; representa la percepción del usuario sobre la respuesta inicial.
- TPOT (tiempo por token de salida), o latencia entre tokens, es el costo constante de cada paso posterior de decodificación.
- N_tokens indica la longitud total del resultado.
El factor (N − 1) es intencional: el primer token ya se encuentra dentro de TTFT, por lo que solo el resto se multiplica por TPOT. Mezclar el cálculo de prefill en bruto con TTFT es un error común. TTFT está orientado al usuario y debe incluir ese primer paso de decodificación.
2. Entrada antes de que las GPUs vean el tráfico
El tráfico pico agotará las GPUs a menos que la entrada sane, evalúe y filtre primero. Un camino típico: gateway API → caché semántica de múltiples capas → en caso de fallo, un router inteligente que evalúa la complejidad y envía el trabajo a una cola de modelo genérico o a una cola de modelo avanzado.
Elementos clave:
- Caché semántica de múltiples capas: clave-valor de coincidencia exacta más similitud vectorial con cos θ ≥ τ. Las repeticiones nunca afectan al modelo; el costo y la latencia disminuyen al mismo tiempo.
3. Motor de ejecución: lotes continuos y flujo de memoria
Después del enrutamiento, el trabajo pasa al motor de ejecución. El loteo estático desperdicia capacidad: todo el lote espera a la secuencia más larga. Las plataformas de producción utilizan lotes continuos (programación a nivel de iteración) para mantener los espacios ocupados y que las secuencias terminadas se liberen tan pronto como emitan la señal de finalización.
El loteo continuo no se refiere solo al rendimiento. También permite pasar del régimen limitado por la memoria al régimen limitado por el procesamiento, de modo que la GPU realiza cálculos en lugar de esperar a la HBM.
4. Abordar directamente los cuellos de botella en cada fase
El caché, el enrutamiento y el agrupamiento gestionan el tráfico. Las siguientes estrategias transforman las fases en sí mismas.
Prefill: FlashAttention
El costo del prefill aumenta con el cuadrado de la longitud del prompt cuando la atención clásica genera una matriz de puntuaciones completa N×N en HBM. FlashAttention es un núcleo modular consciente de las operaciones de E/S que calcula la atención con precisión mientras transmite los datos por medio de SRAM integrada en el chip, reduciendo así el tráfico hacia HBM sin necesidad de aproximar los cálculos matemáticos. Se obtiene una salida exacta y un tiempo de procesamiento más corto en prompts largos. Es la opción predeterminada en la mayoría de las plataformas de servicio y se combina con prefill por bloques y desagregación posterior.
Cuantización
La decodificación implica costos para transferir los pesos de HBM a SRAM. La cuantización reduce el tamaño de los pesos —de FP16 a FP8, INT8 o 4 bits (AWQ, GPTQ)— de modo que cada token ocupa menos bytes. Esto aumenta el ancho de banda efectivo y permite almacenar más secuencias en la memoria. Se espera un ligero deterioro en la precisión, algo que debe comprobarse mediante pruebas propias.
Caché KV paginado (PagedAttention)
Las claves y valores históricos expanden los tokens uno por uno, lo que domina el uso de la memoria en tiempo real. La asignación contigua genera fragmentos y obliga a un provisionamiento excesivo. PagedAttention almacena los datos KV en bloques de tamaño fijo, al igual que la memoria virtual del sistema operativo, lo que elimina la fragmentación y permite tamaños de lote más grandes en el mismo hardware. Úselo junto con el agrupamiento continuo para lograr una alta concurrencia.
Decodificación especulativa
La decodificación secuencial, limitada por la memoria, deja el procesamiento inactivo entre las consultas. La decodificación especulativa aprovecha ese tiempo ocioso: un pequeño propuesto crea una secuencia breve de tokens; la red principal verifica esa secuencia en un solo paso forward conjunto. Los tokens aceptados requieren aproximadamente un paso del modelo de gran tamaño.
Se mantiene la corrección: los prefijos que coinciden se conservan; la primera discrepancia provoca un truncamiento y el destino vuelve a muestrear desde una distribución corregida. Bajo la decodificación codiciosa, los tokens coinciden exactamente con el modelo de destino; bajo el muestreo, la distribución coincide estadísticamente. La aceleración está relacionada con la tasa de aceptación de los borradores, por lo que la calidad de estos es importante.
5. Programación de ambas fases: prellenado por bloques y desagregación
El prellenado y la decodificación requieren arquitecturas de silicio opuestas. Compartir un conjunto de GPUs permite que un largo proceso de prellenado monopolice los recursos de cómputo y aumente la latencia entre tokens en todas las demás solicitudes. A continuación se presentan dos soluciones complementarias.
Preenllenado por bloques
En lugar de un único proceso masivo de llenado previo, divida la solicitud en segmentos e intégrelos de forma intercalada (“piggyback”) con pasos de decodificación en el mismo lote (Sarathi / Sarathi-Serve). Esto atenúa los picos de TTFT en las solicitudes vecinas y combina tareas limitadas por cálculos con aquellas limitadas por memoria. El loteo continuo decide cuáles solicitudes comparten un paso; el llenado previo por bloques determina cómo se realiza un llenado previo intensivo sin afectar negativamente la decodificación.
Servicio desagregado
El llenado previo por bloques reduce las interferencias; la desagregación las elimina al asignar diferentes fases a hardware distintos (DistServe, Splitwise). El llenado previo se realiza en grupos optimizados para cálculos, mientras que la decodificación lo hace en grupos optimizados para ancho de banda, con los datos KV transmitidos a través de la conexión interconectada. Cada fase se escala en el silicio adecuado según su cuello de botella.
Existen verdaderos compromisos: la transferencia de KV se convierte en un nuevo cuello de botella, y los pesos deben almacenarse en ambos conjuntos. A gran escala se demuestra que la provisión específica para cada fase supera ese costo adicional. Las instalaciones más pequeñas suelen limitarse únicamente al prellenado por bloques.
6. Impacto sistémico y compromisos
Los patrones de producción sacrifican el rendimiento por el riesgo operativo y los costos de infraestructura. Las cifras varían según el hardware, el modelo, el tráfico y la configuración; realice pruebas con su propio trabajo de carga en lugar de copiar porcentajes genéricos.
Caché semántica multicapa — KV exacto además de similitud vectorial. Los aciertos evitan por completo el uso del modelo. Costo: búsqueda vectorial (de uno a pocos decenios de milisegundos) y respuestas obsoletas o cercanas al error si τ es demasiado bajo.
Enrutamiento inteligente — un clasificador de complejidad dirige las tareas simples a modelos pequeños. Esto reduce el costo promedio por token; un enrutamiento incorrecto afecta la calidad.
Batching continuo — unión a nivel de iteración durante la generación. Mayor utilización y rendimiento bajo concurrencia; las solicitudes individuales pueden quedar en cola durante el ensamblaje. El batching estático sigue siendo adecuado para tareas de alto rendimiento sin conexión.
Cuantización — los pesos de menor precisión reducen las transferencias de HBM a SRAM. Mayor concurrencia por GPU; se debe validar la precisión; el soporte de kernels varía.
KV paginado — los bloques fijos eliminan la fragmentación. Tamaños de lote más grandes; se requiere gestión de bloques y un kernel de atención compatible.
Decodificación especulativa — un proponente pequeño hace una sugerencia; el modelo grande verifica conjuntamente. Varios tokens por paso grande; sensibilidad al segundo modelo y a la tasa de aceptación.
Cuando se necesita una latencia exacta o cifras de costo precisas, hay que obtenerlas a partir de pruebas reproductibles del trabajo de carga objetivo (estudios de rendimiento publicados o pruebas de carga internas), y no de porcentajes fijos utilizados en marketing.
7. Cerrar el ciclo
Pasar de un prototipo a la producción implica diseñar teniendo en cuenta el hardware. Separe la operación de prellenado de la de decodificación, observe cómo el tamaño del lote afecta la decodificación entre regímenes limitados por la memoria y por el procesamiento, almacene en caché las consultas predecibles, dirija tareas sencillas a modelos pequeños y agrupe tokens mediante procesamiento por lotes continuo. Luego, enfrente el problema de la decodificación con cuantización, estructuras KV paginadas y decodificación especulativa, y reduzca la interferencia entre fases mediante prellenado por bloques y desagregación. Juntos, estos elementos permiten absorber picos de carga sin agotar las GPUs.
Lista de verificación para la planificación de capacidad
Cuando TTFT aumenta, se debe examinar la distribución de la longitud de los prompts, la tasa de acierto del caché semántico, la disponibilidad de FlashAttention y si los prompts largos siguen monopolizando la GPU en un único proceso de prellenado. Cuando TPOT aumenta debido a la concurrencia, es necesario analizar el tamaño efectivo del lote, la residencia de KV, el nivel de cuantización y si la decodificación vuelve a operar bajo limitaciones de memoria.
Una revisión semanal práctica plantea tres preguntas: ¿Estamos almacenando en caché las consultas predecibles? ¿Estamos dirigiendo el trabajo trivial lejos de los modelos avanzados? ¿Estamos optimizando la decodificación para que las GPUs realicen cálculos en lugar de esperar a HBM? Las respuestas afirmativas suelen ser mejores que comprar otro rack antes de ajustar la infraestructura de servicio.
La desagregación solo debe incluirse en el plan de desarrollo una vez que el relleno previo por bloques y el agrupamiento continuo hayan demostrado su eficacia. El tráfico interconectado y los pesos duplicados representan costos reales; hay que tener en cuenta estos costos cuando los grupos específicos para cada fase superen claramente a una flota compartida en su combinación actual.
Documente el tamaño del lote de cruce medido en el que la decodificación se vuelve limitada por los cálculos en su hardware. Ese único número sirve como referencia más precisa para establecer objetivos de agrupamiento continuo que cualquier gráfico genérico de un blog.
Notas del operador
Los cachés semánticos requieren revisiones de TTL y τ; un valor demasiado bajo de τ genera respuestas cercanas a la correcta pero erróneas. Los enrutadores necesitan datos de complejidad etiquetados, de lo contrario envían prompts complejos a modelos pequeños. El agrupamiento continuo necesita objetivos de rendimiento en cuanto a latencia de colas, para que un “mayor rendimiento” no oculte problemas interactivos. La decodificación especulativa necesita paneles de control para la aceptación preliminar: si la tasa de aceptación disminuye, estará pagando por un segundo modelo sin obtener ninguna mejora en velocidad.
Trate los artículos científicos como pruebas de mecanismos, no como promesas de porcentajes portátiles. Reproduzca los resultados en sus GPUs, con las longitudes de prompts que utilice y bajo su nivel de concurrencia antes de afirmar que hay ahorros para financiar algo.
Referencias
Artículos principales detrás de estos mecanismos (los números corresponden a ellos, no a usted):
- Orca distributed transformer serving — Yu et al., OSDI 2022 (USENIX).
- PagedAttention memory management — Kwon et al., SOSP 2023 (arXiv:2309.06180).
- GPTQ post-training quantization — Frantar et al., 2022 (arXiv:2210.17323).
- AWQ activation-aware weight quantization — Lin et al., 2023 (arXiv:2306.00978).
- FlashAttention IO-aware exact attention — Dao et al., NeurIPS 2022 (arXiv:2205.14135).
- Speculative decoding for fast transformer inference — Leviathan, Kalman, Matias, ICML 2023 (arXiv:2211.17192).