El despliegue de modelos de lenguaje a gran escala enfrenta un problema técnico fundamental: las fases de prefill y decode requieren recursos de cómputo radicalmente distintos. El prefill procesa el prompt inicial en paralelo, exigiendo alta capacidad de GPU para analizar el contexto completo de entrada. En cambio, el decode genera tokens de forma secuencial, donde el factor limitante es el ancho de banda de memoria, no la potencia de cómputo bruto. Esta disparidad obliga a separar ambas etapas en nodos distintos, pero las soluciones actuales, como las implementaciones basadas en SGLang, asignan una proporción fija de trabajadores a cada fase, lo que introduce rigidez en el sistema.
La asignación estática de recursos funciona en escenarios predecibles, pero falla ante la volatilidad real de las cargas de trabajo. Cuando la demanda de prefill se dispara o el decode se satura, el sistema no puede reasignar recursos de forma ágil, aunque existan nodos inactivos en el lado opuesto. Los mecanismos de autoescalado tradicionales, basados en añadir nodos, son demasiado lentos para reaccionar a estos cambios bruscos, ya que el tiempo necesario para desplegar nuevas instancias de GPU y cargar los pesos del modelo en la VRAM supera la duración de muchos picos de demanda. Esto se traduce en violaciones de los SLO de latencia incluso con capacidad ociosa.
Kartik Ramesh y su equipo proponen FluidPD, un sistema que introduce la elasticidad in-place para resolver este cuello de botella. A diferencia de las arquitecturas estáticas, FluidPD permite ajustar la capacidad de cómputo entre prefill y decode en tiempo real, sin necesidad de reconfigurar la infraestructura física ni reiniciar los motores de inferencia. El sistema monitoriza los SLO en tiempo real y redistribuye los recursos dinámicamente, aprovechando la capacidad disponible donde sea necesario. Las pruebas con trazas de producción de Azure demuestran que este enfoque mejora el cumplimiento de los SLO hasta en 94,6 puntos porcentuales frente a configuraciones estáticas de SGLang.
FluidPD implementa dos mecanismos complementarios para gestionar diferentes escalas de desequilibrio. FluidToken actúa ante desequilibrios transitorios: cuando detecta capacidad disponible en los trabajadores de decode*, desvía una porción limitada del cómputo de *prefill hacia esos nodos, evitando la acumulación de solicitudes en colas. FluidRole, en cambio, se activa ante desequilibrios sostenidos y reasigna la función completa de un trabajador activo, transformando un nodo de prefill 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 que monitorean la saturación de recursos en tiempo real. FluidPD identifica la presión en el lado del prefill o el decode antes de que se produzca una violación efectiva de los SLO, actuando preventivamente para redistribuir la carga o cambiar los roles de los nodos. Esto optimiza el flujo de tokens y el Time to First Token (TTFT), manteniendo una calidad de servicio superior sin necesidad de provisionar trabajadores adicionales.
La validación de FluidPD con trazas de producción de Azure confirma que la elasticidad consciente de los SLO permite mantener una calidad de servicio superior sin sobreaprovisionar hardware. En comparación con SGLang en configuración estática, la mejora de hasta 94,6 puntos porcentuales en el cumplimiento de los SLO demuestra que el problema no es la falta de hardware, sino la rigidez en la asignación de roles. 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: en lugar de mantener un margen de seguridad de GPUs inactivas o sobreaprovisionar nodos, el hardware se adapta al ritmo real de las conversaciones, donde la longitud de los prompts y las respuestas varía drásticamente entre usuarios y aplicaciones.
Desde el punto de vista del desarrollo de sistemas, la 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, FluidPD cambia la función de un trabajador en milisegundos, permitiendo una respuesta casi instantánea. Esto es crítico en entornos de producción donde los SLO son estrictos y cualquier incremento en la latencia impacta directamente en la experiencia del usuario. Además, la capacidad de FluidPD para operar preventivamente, en lugar de reactivamente, evita que el usuario sufra degradaciones del servicio antes de que el sistema actúe.
En aplicaciones con prompts extremadamente largos, 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, optimizando el rendimiento por vatio al asegurar que la mayor cantidad de hardware posible esté realizando trabajo útil en cada instante.
Sin embargo, la adopción de FluidPD no está exenta de desafíos técnicos. No se han proporcionado benchmarks cuantitativos detallados frente a todas las arquitecturas de desagregación modernas, ni se ha especificado la latencia exacta del proceso de cambio de rol en FluidRole. La viabilidad del sistema a escala masiva depende de la gestión de las cachés KV (*Key-Value caches*) durante la transición de roles, ya que el estado de la conversación reside en estas cachés. El traslado o la gestión de esta memoria al cambiar un nodo de prefill a decode es un punto crítico de complejidad técnica. 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.
Otro desafío es 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. Además, la aplicación de FluidPD 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 técnico pendiente.
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, transformando la gestión de la inferencia de un modelo de planificación estática a uno de reacción dinámica. Esto reduce la complejidad de la planificación de capacidad para los desarrolladores de IA, que ya no necesitan predecir la proporción exacta de *prefill*/*decode para cada tipo de aplicación, sino que pueden confiar en un sistema que autoajusta los roles.
Para los usuarios finales, FluidPD 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.
El éxito de FluidPD dependerá de su capacidad para demostrar su valía más allá de los entornos controlados de Azure. Será crucial observar cómo se comporta el sistema en implementaciones reales, con cargas de trabajo diversas y en entornos multi-tenant*, donde múltiples modelos o clientes comparten la misma infraestructura. Otra señal importante será la respuesta de la industria: si los principales actores adoptan la elasticidad *in-place como estándar o si optan por soluciones alternativas. Además, habrá que prestar atención a la evolución de los SLO en el sector. Si FluidPD logra reducir significativamente las violaciones de latencia, podríamos ver un aumento en las expectativas de los clientes, que exigirán niveles de servicio más estrictos.
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. Este avance no solo mejora la eficiencia técnica, sino que también redefine el diseño de sistemas para LLM a gran escala, obligando a la industria a replantearse el enfoque tradicional basado en la especialización estática de los nodos.
