La desagregación de prefill y decode se ha consolidado como la arquitectura dominante para servir modelos de lenguaje a escala. Separar ambas fases permite optimizar cada una según sus patrones de ejecución y objetivos de latencia distintos. Sin embargo, los sistemas actuales —incluidos frameworks populares como SGLang— operan con ratios fijos de workers entre prefill y decode, lo que genera ineficiencias graves cuando la carga real fluctúa.
El problema es estructural: las cargas de producción exhiben tanto ráfagas cortas como cambios sostenidos en la proporción de demanda entre prefill y decode. Una configuración bien dimensionada en un momento dado puede volverse obsoleta en minutos, provocando violaciones de SLO aunque existan GPUs ociosas en el otro lado del clúster. El autoscaling tradicional reacciona tarde, requiere GPUs de reserva y no resuelve el desequilibrio a escala de segundos.
FluidPD, presentado en arXiv por un equipo de investigación, ataca esta raíz con dos mecanismos complementarios. FluidToken gestiona desequilibrios transitorios: cuando los workers de decode tienen holgura, descargan una porción acotada de cómputo de prefill sin mover el modelo. FluidRole aborda cambios sostenidos: reasigna workers enteros entre roles prefill y decode in-place, evitando la recarga de pesos y el reinicio del motor de inferencia. Ambos se guían por índices de presión ligeros que detectan saturación antes de que se manifieste como violación de SLO.
La evaluación sobre trazas de producción de Azure es el dato más contundente: FluidPD mejora el cumplimiento global de SLOs frente a SGLang estático hasta en 94,6 puntos porcentuales. No es una optimización marginal; es la diferencia entre un servicio que cumple sus contratos de latencia y uno que falla sistemáticamente en picos de demanda.
La implicación para la industria es inmediata. Los proveedores de inferencia —desde hyperscalers hasta startups de GPU cloud— pueden extraer más rendimiento de su hardware existente sin aprovisionar capacidad extra. En un mercado donde el coste por token y la disponibilidad de H100/B200 son cuellos de botella económicos, la elasticidad in-place cambia la ecuación de capacidad.
Quedan preguntas abiertas: la sobrecarga de coordinación entre workers, la aplicabilidad a modelos MoE con expert routing, y la integración con schedulers de clúster como Kubernetes o Slurm. Pero la dirección es clara: el serving de LLMs deja de ser estático para convertirse en un sistema de control en lazo cerrado que adapta su topología lógica al flujo de trabajo en tiempo real.
