Desagregación de Prefill y Decode en LLMs: Resolviendo la Latencia a Escala

La adopción masiva de flujos de trabajo basados en agentes autónomos y la Generación Aumentada por Recuperación (RAG) ha transformado radicalmente el perfil del tráfico de los grandes modelos de lenguaje. Las aplicaciones empresariales han pasado de procesar interacciones de chat cortas a ingerir contextos de cientos de miles de tokens en un solo bloque. Frente a este cambio de paradigma, la infraestructura de inferencia monolítica tradicional, donde todas las fases del procesamiento del modelo ocurren en el mismo hardware, comienza a colapsar bajo su propio peso.

El problema central reside en una asimetría de hardware fundamental: colocalizar el procesamiento inicial del prompt y la generación de la respuesta en la misma tarjeta gráfica destruye la previsibilidad del sistema y degrada severamente la latencia de cola. Para mantener Service Level Objectives (SLOs) estrictos en entornos interactivos sin sacrificar la utilización de los recursos, la ingeniería de software moderna exige adoptar la desagregacion de prefill y decode llm, dividiendo topológicamente el clúster para asignar cada carga de trabajo al hardware que mejor resuelva su cuello de botella específico.

La asimetría del silicio y la necesidad de la desagregacion de prefill y decode llm

La inferencia autorregresiva de un modelo de lenguaje se divide en dos fases con perfiles computacionales que son diametralmente opuestos. La fase de prefill es la encargada de procesar el contexto de entrada de manera paralela. Cuando un sistema ingiere miles de tokens simultáneamente, ejecuta multiplicaciones de matrices densas a gran escala (GEMM). Esta operación posee una intensidad aritmética altísima que logra saturar por completo los Tensor Cores de la GPU, convirtiéndola en una tarea estrictamente dominada por el cómputo (compute-bound).

Por el contrario, la fase de decode genera los tokens de salida de manera secuencial, produciendo exactamente un vector por cada paso hacia adelante. Para calcular un solo token, el motor de inferencia está obligado a cargar todos los pesos del modelo y el historial acumulado del KV cache desde la memoria de alto ancho de banda (HBM) hacia la memoria SRAM de la GPU. Al realizarse mediante operaciones de matriz-vector (GEMV), la capacidad de procesamiento de esta fase no está dictada por la potencia bruta de los procesadores, sino que se encuentra fundamentalmente limitada por el ancho de banda de la memoria (memory-bandwidth-bound).

Forzar a ambos procesos a compartir el mismo pipeline de ejecución genera una contención estructural. Cuando un sistema está decodificando múltiples secuencias de manera activa y de repente recibe una petición RAG con un contexto masivo, el prefill acapara los recursos del GPU. Los decodes activos se bloquean temporalmente, provocando latencias entre tokens (Inter-Token Latency o ITL) completamente erráticas, especialmente en el percentil p99. Este fenómeno de tartamudeo destruye la experiencia en aplicaciones interactivas y demuestra por qué la arquitectura monolítica es inviable a escala empresarial.

Mitigación por software: Los límites del Chunked Prefill

Antes de llegar a la separación física, la industria desarrolló mecanismos de mitigación a nivel de software. La técnica de chunked prefill aborda el problema dividiendo el procesamiento de un prompt largo en fragmentos más pequeños con un límite estricto de tokens. En lugar de ejecutar una pasada hacia adelante masiva que bloquee el sistema durante segundos, el scheduler procesa un fragmento y permite que los decodes de otras peticiones se ejecuten en los espacios intermedios.

Esta estrategia se ha estandarizado en los motores modernos de alto rendimiento. Por ejemplo, el scheduler V1 de vLLM habilita el chunked prefill por defecto para suavizar las métricas bajo alta concurrencia. Del mismo modo, el motor SGLang implementa esta función de fábrica, configurando un tamaño de chunk predeterminado de 8192 tokens. Estas implementaciones han demostrado ser críticas para estabilizar el Time-To-First-Token (TTFT) cuando un clúster recibe tráfico mixto de peticiones largas y cortas.

Sin embargo, la mitigación por software choca inevitablemente con las restricciones del silicio. Intercalar operaciones altamente dependientes de cómputo con operaciones dependientes de memoria fragmenta el flujo de trabajo de la GPU, impidiendo que alcance la saturación óptima en cualquiera de sus componentes. A medida que la longitud del contexto aumenta, el overhead sobre el scheduler crece exponencialmente. Llega un punto de inflexión operativo donde dividir los prompts ya no protege los SLOs de latencia, obligando a los arquitectos a mover el límite de la capa de software hacia la topología de la infraestructura física.

Arquitectura de desacoplamiento y el transporte del KV-Cache

La separación topológica resuelve la contención al dirigir las peticiones entrantes a un clúster de nodos dedicados exclusivamente al prefill, y luego transferir la generación de los tokens a un clúster secundario optimizado para el decode. El mayor desafío de ingeniería en este modelo es el estado intermedio: el KV cache generado durante el procesamiento inicial del contexto debe ser persistido y transferido a los nodos de decodificación.

Si la red subyacente es lenta, el tiempo que toma transferir gigabytes de estado de atención anulará cualquier ganancia de latencia obtenida por el desacoplamiento. El diseño del subsistema de transporte requiere el uso de redes de ultra baja latencia que eviten la serialización asociada a protocolos estándar como TCP. Las arquitecturas empresariales modernas exigen interconexiones como NVLink para transferencias dentro de un mismo nodo, o protocolos de acceso directo a memoria como RDMA (Remote Direct Memory Access) sobre RoCE v2 o infraestructuras nativas de nube como AWS EFA (Elastic Fabric Adapter) para mover los tensores sin bloquear el pipeline general.

El modelo de hiper-escala: Arquitecturas centradas en el KV Cache

El diseño óptimo para este paradigma se aleja del ruteo tradicional y posiciona al caché como el elemento central del sistema. La arquitectura Mooncake, desarrollada para dar soporte al servicio LLM Kimi, ilustra esta evolución al implementar un clúster completamente desagregado centrado en la persistencia inteligente del KV cache.

Para sostener la transferencia de estados masivos sin saturar la red principal, este modelo aprovecha la memoria DRAM, los procesadores y los discos SSD del clúster que normalmente permanecen subutilizados en instancias pesadas en GPU, creando una jerarquía de caché desagregada. Además, al operar en escenarios con niveles extremos de sobrecarga y concurrencia impredecible, la plataforma implementa una política de rechazo temprano basada en predicciones de carga, asegurando que solo se admitan los requests que el clúster puede servir respetando el SLO de latencia. En entornos de simulación, estas innovaciones arquitectónicas han reportado aumentos de rendimiento de hasta un 525%, y han permitido manejar un 75% más de peticiones simultáneas en las cargas de producción del servicio Kimi.

Implicaciones técnicas para el diseño de sistemas LLM

Transicionar hacia clústeres desacoplados cambia profundamente las reglas del dimensionamiento de infraestructura. En el modelo monolítico tradicional, los ingenieros están obligados a desplegar hardware homogéneo, lo que invariablemente resulta en una sobre-provisión ineficiente: las GPUs con alta capacidad de cómputo desperdician ciclos de reloj durante la decodificación, y las GPUs con amplia memoria HBM se subutilizan durante la ingesta del prompt.

Al implementar una separación estricta, los equipos pueden orquestar paralelismo heterogéneo. El clúster de prefill puede aprovisionarse con hardware de muy alta densidad computacional, utilizando niveles agresivos de Tensor Parallelism para procesar prompts masivos en fracciones de segundo. De manera independiente, el clúster de decode se optimiza buscando instancias que maximicen la capacidad bruta y la velocidad de su memoria HBM, con el objetivo de alojar la mayor cantidad posible de secuencias concurrentes sin llegar a la saturación.

Esta asimetría en el diseño permite a los equipos de ingeniería dejar de perseguir la métrica cruda de throughput máximo teórico, y comenzar a optimizar el goodput del sistema: la cantidad real de trabajo útil y sostenido que el clúster logra despachar sin romper el p99 del Inter-Token Latency. Para aplicaciones de inferencia interactiva impulsadas por agentes que consumen y analizan documentos enteros antes de responder, garantizar esta previsibilidad en la latencia de la respuesta es un mandato arquitectónico innegociable.

Recomendaciones para orquestar un clúster desagregado

La decisión de separar físicamente los workloads depende directamente del perfil del tráfico, la infraestructura de red disponible y la madurez de las capas de orquestación. Para los arquitectos y líderes técnicos que buscan estabilizar la latencia de sus aplicaciones de lenguaje, los pasos a seguir deben ser sistemáticos:

• Desacoplamiento de las métricas de observabilidad: Abandonar la medición de latencia promedio. Es mandatorio instrumentar las métricas de Time-To-First-Token (TTFT) enfocándose exclusivamente en la fase de prefill, y monitorear el Inter-Token Latency (ITL) de manera aislada en la fase de decode. Se debe introducir una tercera métrica crítica: la latencia de transferencia del bloque de KV cache entre los nodos.
• Evaluación rigurosa de la red subyacente (Fabric Layer): No se debe intentar la desagregación sobre redes Ethernet convencionales. Antes de desplegar proxies de separación, es necesario verificar que la infraestructura soporte arquitecturas de cero copia como RDMA o AWS EFA. Sin enlaces de al menos 400 Gb/s (como InfiniBand NDR), el overhead de transferencia será superior al tiempo ahorrado por la especialización del hardware.
• Implementación inmediata del Chunked Prefill: En clústeres monolíticos existentes que aún no justifican una separación física, actualizar de inmediato los motores de inferencia (a vLLM V1 o SGLang) para forzar la segmentación del prompt. Afinar la variable del tamaño del chunk para priorizar la fluidez de las sesiones de decode activas frente a la velocidad pura de ingesta de nuevos requests.
• Alineación del paralelismo al cuello de botella: En una topología separada, configurar esquemas de escalabilidad diferentes. Aplicar un alto nivel de Tensor Parallelism a los nodos de prefill para distribuir las cargas de matriz pesada, mientras se prioriza el Pipeline Parallelism o el ruteo por capacidad de memoria en el clúster encargado de las operaciones autorregresivas.
• Adopción de proxies de ruteo semántico: Integrar balanceadores de carga inteligentes que dirijan las secuencias de generación a aquellos nodos de decodificación específicos que ya mantengan la mayor proporción de los bloques del KV cache en su memoria RAM local, minimizando los requerimientos de transferencia a través de la red en tiempo real.

El diseño de sistemas para inteligencia artificial generativa ha dejado de ser un problema de abstracción algorítmica para convertirse en un desafío profundo de ingeniería de sistemas distribuidos y arquitectura de silicio. Abordar la contención de recursos a través de un diseño desagregado no es simplemente una optimización marginal de rendimiento; es la evolución necesaria de la infraestructura para sostener aplicaciones empresariales deterministas, resilientes y preparadas para soportar la próxima generación de modelos de contexto largo sin sacrificar la estabilidad del entorno interactivo.