FluidPD optimiza el servicio de LLM mediante elasticidad in-place y desagregación

Kartik Ramesh y un equipo de investigadores han desarrollado FluidPD, un sistema de servicio para modelos de lenguaje extensos (LLM) que implementa elasticidad in-place para optimizar la arquitectura de desagregación entre las fases de prefill y decode. Este sistema permite ajustar la capacidad de cómputo en tiempo real basándose en los objetivos de nivel de servicio (SLO), logrando una mejora en el cumplimiento de dichos objetivos de hasta 94,6 puntos porcentuales en comparación con configuraciones estáticas de SGLang, según pruebas realizadas con trazas de producción de Azure.

El despliegue de LLM a escala industrial enfrenta un problema técnico debido a que el procesamiento de solicitudes se divide en dos etapas con patrones de ejecución radicalmente opuestos. La fase de prefill procesa el prompt inicial del usuario de forma masiva, aprovechando el paralelismo de la GPU para analizar todo el contexto de entrada. Por el contrario, la fase de decode genera los tokens de respuesta de uno en uno, un proceso secuencial que depende fuertemente del ancho de banda de la memoria y no de la capacidad de cómputo bruto. Esta disparidad provoca que los recursos de hardware se utilicen de manera ineficiente si se procesan ambas fases en el mismo nodo.

Para mitigar este problema, la industria ha adoptado la arquitectura de desagregación, que separa el prefill y el decode en trabajadores distintos. Esta separación permite optimizar cada nodo para su tarea específica y gestionar los SLO de latencia de forma independiente. Sin embargo, la mayoría de las implementaciones actuales utilizan una proporción fija de trabajadores para cada fase. El enrutamiento de solicitudes distribuye la carga basándose en esta cuota predefinida, lo que resulta insuficiente ante la naturaleza volátil de las cargas de trabajo reales, que presentan tanto ráfagas cortas como cambios sostenidos en la demanda de prefill frente a la de decode.

Cuando la demanda de prefill aumenta bruscamente mientras la de decode disminuye, o viceversa, una configuración estática genera violaciones de los SLO. Esto ocurre incluso si el sistema tiene capacidad de cómputo disponible en el lado opuesto de la desagregación. Los mecanismos de autoescalado tradicionales, basados en la instanciación de nuevos nodos, no resuelven este desequilibrio a corto plazo. El tiempo necesario para desplegar nuevas instancias de GPU y cargar los pesos del modelo en la VRAM es significativamente superior a la duración de muchos picos de demanda, lo que hace que la respuesta del sistema llegue cuando el pico ya ha desaparecido.

FluidPD soluciona esta rigidez mediante la elasticidad in-place, que permite modificar la capacidad del sistema sin reiniciar los motores de inferencia ni recargar los modelos en la memoria de la GPU. El sistema implementa dos mecanismos complementarios para gestionar diferentes escalas de desequilibrio. El primero, FluidToken, está diseñado para desequilibrios transitorios. Cuando el sistema detecta capacidad disponible (slack) en los trabajadores de decode, FluidToken desvía una porción limitada del cómputo de prefill hacia esos nodos. Esto evita que las solicitudes de prefill se acumulen en colas mientras existen recursos de cómputo infrautilizados en la infraestructura de decode.

El segundo mecanismo, FluidRole, se activa ante desequilibrios sostenidos. A diferencia de FluidToken, que solo redistribuye una fracción del cómputo, FluidRole reasigna la función completa de un trabajador activo. Un nodo que operaba como trabajador de prefill puede transformarse en uno de decode, o viceversa, de manera inmediata. Esta capacidad de cambio de rol in-place elimina la latencia asociada al despliegue de nuevas máquinas y la carga del modelo, permitiendo que la infraestructura se adapte dinámicamente a la carga de trabajo sin interrupciones en el servicio.

La coordinación de estos mecanismos se basa en índices de presión ligeros. Estos indicadores monitorean la saturación de recursos en tiempo real, permitiendo que FluidPD identifique la presión en el lado del prefill o del decode antes de que se produzca una violación efectiva de los SLO. Al actuar preventivamente, el sistema redistribuye la carga o cambia los roles de los nodos antes de que el usuario final experimente un aumento en la latencia de respuesta, optimizando el flujo de tokens y el tiempo de primera respuesta (Time to First Token).

La validación de FluidPD utilizando trazas de producción de Azure demuestra que la elasticidad consciente de los SLO permite mantener una calidad de servicio superior sin necesidad de provisionar trabajadores adicionales. Al comparar el rendimiento con SGLang en configuración estática, la mejora de hasta 94,6 puntos porcentuales en el cumplimiento de los SLO evidencia que el problema no es la falta de hardware, sino la rigidez en la asignación de roles de ese hardware. Esto reduce la necesidad de mantener GPUs de reserva inactivas, optimizando el coste operativo de la infraestructura de inferencia.

Para las empresas que operan clústeres de GPUs, la implementación de FluidPD implica un cambio en la gestión de recursos. Tradicionalmente, para evitar picos de latencia, los administradores mantenían un margen de seguridad de GPUs inactivas o sobreaprovisionaban nodos de prefill y decode. Este enfoque resultaba en un desperdicio significativo de potencia de cálculo. La fluidez entre fases permite que el hardware se adapte al ritmo real de las conversaciones, donde la longitud de los prompts y las respuestas varía drásticamente entre usuarios y aplicaciones.

Desde la perspectiva del desarrollo de sistemas, este modelo de elasticidad in-place ofrece una alternativa a la orquestación compleja basada en Kubernetes. Mientras que las soluciones de orquestación estándar pueden tardar minutos en reaccionar y escalar la infraestructura, la capacidad de FluidPD para cambiar la función de un trabajador en milisegundos permite una respuesta casi instantánea. Esto es crítico en entornos de producción donde los acuerdos de nivel de servicio son estrictos y cualquier incremento en la latencia impacta directamente en la experiencia del usuario.

A pesar de los resultados positivos, existen vacíos técnicos en la documentación pública del sistema. No se han proporcionado benchmarks cuantitativos detallados frente a todas las arquitecturas de desagregación modernas, ni se ha especificado la latencia exacta que conlleva el proceso de cambio de rol en FluidRole. La viabilidad del sistema a escala masiva depende fundamentalmente de la gestión de las cachés KV (Key-Value caches) durante la transición de roles. Dado que el estado de la conversación reside en estas cachés, el traslado o la gestión de dicha memoria al cambiar un nodo de prefill a decode es un punto crítico de complejidad técnica.

La aplicación de FluidPD también requiere que los motores de inferencia soporten la transición de roles sin pérdida de estado crítica. Aunque el sistema resuelve la carga del modelo, la sincronización de los datos de contexto entre nodos desagregados sigue siendo un desafío. Si la transferencia de la caché KV es lenta, la ventaja de la elasticidad in-place podría verse mitigada por la latencia de movimiento de datos entre GPUs.

En comparación con el estado anterior del sector, donde la desagregación se implementaba como una división estática de recursos, FluidPD introduce el concepto de hardware fluido. Anteriormente, el optimizador de rutas decidía a qué nodo enviar la solicitud, pero no podía cambiar la naturaleza del nodo receptor. Ahora, el sistema puede alterar la arquitectura misma del clúster en tiempo real para alinearse con la demanda. Esto transforma la gestión de la inferencia de un modelo de planificación estática a uno de reacción dinámica.

Las consecuencias para los desarrolladores de IA son directas: se reduce la complejidad de la planificación de capacidad. En lugar de intentar predecir la proporción exacta de prefill/decode para cada tipo de aplicación, pueden confiar en un sistema que autoajusta los roles. Para los usuarios finales, esto se traduce en una latencia más estable y consistente, eliminando los retardos esporádicos que ocurren cuando un sistema estático se satura durante un pico de solicitudes de prefill.

El impacto económico es relevante para los proveedores de nube y empresas con infraestructura propia. La reducción del sobreaprovisionamiento de GPUs permite ejecutar más modelos o atender a más usuarios con la misma cantidad de hardware. Al maximizar la utilización de cada núcleo CUDA y cada GB de VRAM mediante la elasticidad in-place, el coste por token generado disminuye, haciendo que el despliegue de LLM sea más sostenible financieramente.

Para profundizar en la arquitectura, es necesario analizar la diferencia entre el escalado reactivo y el escalado preventivo. Los sistemas convencionales actúan una vez que la CPU o la GPU han alcanzado un umbral de saturación, lo que implica que el usuario ya está sufriendo una degradación del servicio. FluidPD, mediante sus índices de presión, opera en una capa de monitorización más sensible que detecta la tendencia de saturación antes de que se convierta en una violación del SLO. Esto permite que FluidToken actúe como una válvula de escape inmediata, moviendo cargas ligeras de prefill a nodos de decode que tienen ciclos de reloj libres, sin alterar la estructura global del clúster.

Cuando la presión es sostenida, la transición a FluidRole representa un cambio de paradigma en el despliegue de modelos. En un entorno estándar, cambiar el rol de un servidor implicaría drenar las conexiones activas, detener el proceso del motor de inferencia, cambiar la configuración de despliegue y reiniciar el servicio para cargar el modelo en la memoria de video. FluidPD evita este ciclo completo. Al mantener el modelo cargado en la VRAM y solo alterar la lógica de procesamiento y el enrutamiento de solicitudes, el tiempo de transición se reduce de minutos a milisegundos.

Esta capacidad es especialmente crítica en aplicaciones de LLM con prompts extremadamente largos, donde la fase de prefill es costosa y puede bloquear el sistema si no hay suficientes nodos dedicados. En escenarios de uso empresarial, como el análisis de documentos legales o técnicos, los picos de prefill son frecuentes y agresivos. FluidPD permite que el clúster se convierta temporalmente en una máquina de prefill masivo y luego regrese a una configuración equilibrada una vez que las respuestas comienzan a generarse en la fase de decode.

Desde el punto de vista de la eficiencia energética, la elasticidad in-place reduce el tiempo de inactividad de los núcleos de procesamiento. En las configuraciones estáticas, es común que los nodos de decode permanezcan infrautilizados mientras los de prefill están saturados, o viceversa. Esta asimetría no solo afecta a la latencia, sino que representa un desperdicio de energía eléctrica y capacidad térmica en los centros de datos. FluidPD optimiza el rendimiento por vatio al asegurar que la mayor cantidad de hardware posible esté realizando trabajo útil en cada instante del tiempo.

La implementación de este sistema también plantea interrogantes sobre la interoperabilidad con diferentes tipos de hardware. Aunque las pruebas se realizaron con trazas de Azure, la eficacia de la elasticidad in-place depende de la velocidad de acceso a la memoria y la capacidad de interconexión entre GPUs (como NVLink). En clústeres donde la interconexión es más lenta, el movimiento de los estados de la caché KV podría convertirse en el cuello de botella principal, limitando la agilidad de FluidRole.

La distinción entre hechos confirmados e incertidumbres es clara en el presente desarrollo. Está confirmado que FluidPD mejora el cumplimiento de los SLO en un 94,6% frente a SGLang estático y que utiliza dos mecanismos (FluidToken y FluidRole) basados en índices de presión. Sin embargo, permanece en el terreno de la incertidumbre la escalabilidad exacta del sistema en clústeres de miles de GPUs y la latencia precisa de la transferencia de memoria durante el cambio de roles.

En resumen, FluidPD resuelve la rigidez de las arquitecturas de servicio desagregadas al transformar la asignación de recursos en un proceso dinámico. Al integrar índices de presión y mecanismos de ajuste rápido como FluidToken y FluidRole, el sistema asegura que los tiempos de respuesta se mantengan dentro de los límites acordados sin incrementar el gasto en hardware, marcando una evolución en la eficiencia de la inferencia de modelos de lenguaje extensos.