FluidPD: reasignación de recursos en tiempo real para equilibrar prefill y decode en el servicio de LLMs

El desequilibrio entre prefill y decode

La arquitectura de servicio de modelos de lenguaje (LLM) ha evolucionado hacia la separación de las fases de prefill y decode. Esta disociación, conocida como prefill-decode disaggregation, permite optimizar cada fase de forma independiente, ya que presentan patrones de ejecución y objetivos de servicio (SLO) muy distintos.

Sin embargo, las cargas de trabajo reales no son estáticas. Experiencias cortas y cambios sostenidos en la proporción de demanda entre prefill y decode pueden desequilibrar rápidamente una configuración que inicialmente estaba bien dimensionada. Este desajuste provoca violaciones de SLO de latencia, incluso cuando existe capacidad ociosa en otras partes del sistema.

La separación de prefill y decode permite tratar de manera distinta dos fases con patrones de ejecución y objetivos de servicio diferentes, pero también hace que la distribución de recursos entre ellas cobre importancia. Una asignación adecuada al inicio no garantiza que siga ajustándose a la demanda: basta con que cambie la proporción de trabajo de cada fase para que una parte de la configuración quede bajo presión mientras otra conserva capacidad disponible.

El texto distingue dos escalas temporales del problema. Las variaciones breves pueden crear un desajuste momentáneo, mientras que los cambios sostenidos pueden mantenerlo durante más tiempo. En ambos casos, la capacidad ociosa en una fase no elimina por sí sola las violaciones de latencia: el reto es que esa capacidad pueda contribuir a atender la fase que está saturada sin esperar a que una respuesta lenta de escalado modifique la configuración.

Mecanismos de elasticidad in-place de FluidPD

FluidPD es un sistema de servicio P/D-disagregado que introduce dos mecanismos complementarios para gestionar este desequilibrio. El primero, FluidToken, aborda el desequilibrio transitorio al descargar una porción acotada de la computación de prefill hacia los trabajadores de decode cuando estos tienen capacidad ociosa.

El segundo mecanismo, FluidRole, gestiona el desequilibrio sostenido reasignando trabajadores en ejecución entre los roles de prefill y decode. Esta reasignación se realiza in-place, lo que evita la recarga del modelo y el reinicio del motor de inferencia, permitiendo una adaptación mucho más rápida a los cambios de carga.

FluidToken y FluidRole se diferencian tanto por el tipo de desequilibrio que atienden como por la intervención que realizan. FluidToken traslada una parte acotada de la computación de prefill a trabajadores de decode que disponen de capacidad ociosa; no supone, según la descripción, convertir de manera sostenida esos trabajadores en trabajadores de prefill. Su propósito es aliviar una presión transitoria aprovechando recursos ya presentes en el sistema.

FluidRole actúa sobre la asignación de funciones cuando el desequilibrio persiste. En lugar de incorporar nuevos nodos y cargar de nuevo el modelo, modifica in-place el rol de trabajadores que ya están en ejecución. Así, la elasticidad descrita no consiste únicamente en añadir o retirar capacidad total: también busca cambiar cómo se distribuye entre prefill y decode la capacidad existente. Los dos mecanismos son complementarios porque responden a duraciones y tipos de desajuste distintos.

La comparación con el autoscaling tradicional debe leerse en los términos acotados de la tabla: contrapone la descarga de cómputo de FluidToken, la reasignación de roles de FluidRole y la adición o retirada de GPUs mediante autoscaling. La tabla atribuye a los dos mecanismos de FluidPD la ausencia de GPUs de reserva y de recarga del modelo, mientras que señala esas dependencias para el enfoque tradicional descrito. No basta, por sí sola, para concluir que cualquier implementación o configuración tendrá el mismo comportamiento.

Métricas y condiciones de evaluación

Los autores del preprint reportan que FluidPD mejora el cumplimiento global de SLO en hasta 94,6 puntos porcentuales frente a SGLang estático. Esta mejora se evalúa utilizando trazas de trabajo de producción de Azure, lo que sugiere una relevancia práctica para entornos de gran escala.

Es importante destacar que estas métricas provienen del resumen del preprint y no han sido verificadas de forma independiente. La evaluación se centra en la capacidad del sistema para mantener los SLO sin aprovisionar trabajadores adicionales, un objetivo clave para la eficiencia operativa.

La cifra de hasta 94,6 puntos porcentuales expresa una diferencia en cumplimiento de SLO frente a una configuración estática de SGLang, tal como la presentan los autores del preprint. No debe confundirse con una reducción porcentual de la latencia ni interpretarse como una mejora idéntica en todas las condiciones: el dato se refiere a los escenarios evaluados y el texto no proporciona aquí el detalle necesario para generalizarlo a otras configuraciones.

El uso de trazas de trabajo de producción de Azure aporta una base ligada a cargas de trabajo concretas, pero no sustituye la evaluación con otros patrones ni una verificación independiente. Además, el objetivo de mantener los SLO sin aprovisionar trabajadores adicionales describe el criterio de eficiencia que se examina; no demuestra por sí mismo que se mantengan los mismos resultados ante cualquier variación de carga. Por ello, la cifra debe conservar su atribución y su alcance provisional.

Costes operativos y dependencias

La estrategia de FluidPD depende de la capacidad de los trabajadores de decode para absorber parte de la carga de prefill (FluidToken) y de la posibilidad de reasignar roles sin reiniciar el motor (FluidRole). Esto implica que la arquitectura del sistema de inferencia debe soportar estas operaciones de forma nativa.

Aunque el sistema evita la necesidad de GPUs de reserva, la rapidez de la reasignación y la eficiencia de la descarga de cómputo son factores críticos. Si la reasignación no es lo suficientemente rápida, el desequilibrio podría persistir y causar violaciones de SLO antes de que el sistema se estabilice.

La eficacia de FluidToken presupone que los trabajadores de decode tienen capacidad ociosa suficiente para absorber la porción de prefill que se les deriva. Si esa capacidad no está disponible, la descarga no puede ofrecer el mismo alivio descrito; y, dado que la operación es acotada, no debe entenderse como una transferencia ilimitada de trabajo. La utilidad práctica depende, por tanto, de que el desequilibrio y la capacidad disponible permitan aplicar el mecanismo sin trasladar simplemente la presión a los trabajadores que reciben la carga.

FluidRole, por su parte, depende de que el motor y la arquitectura de serving permitan cambiar el rol de un trabajador en ejecución sin reiniciarlo ni recargar el modelo. La descripción presenta esta operación como una ventaja de diseño, no como una propiedad que pueda darse por supuesta en cualquier infraestructura. Antes de considerar la estrategia, habría que comprobar que el sistema concreto soporta la reasignación y determinar si su rapidez basta para responder al desequilibrio observado.

El flujo de reasignación resume etapas diferentes: primero se identifica la presión sostenida; después se seleccionan trabajadores candidatos y se cambia su rol; por último, se reequilibra la carga entre los trabajadores implicados. Que el proceso incluya detección y selección importa porque no toda reasignación sería necesariamente adecuada. El texto no especifica umbrales ni tiempos para esas etapas, así que no permite asegurar cuánto tarda la estabilización ni qué límites operativos tiene.

Pruebas externas y despliegue en producción

Antes de recomendar el despliegue de FluidPD en producción, sería necesario evaluar su rendimiento con cargas de trabajo reales y diversas, no solo con trazas de Azure. Esto incluiría pruebas con diferentes modelos de lenguaje, tamaños de lote y patrones de tráfico.

Además, se debe verificar la disponibilidad de código y configuraciones para reproducir los resultados, así como los límites de elasticidad del sistema. La falta de una revisión por pares independiente y la naturaleza de preprint del trabajo requieren una cautela adicional al interpretar sus afirmaciones de rendimiento.

Las pruebas adicionales propuestas permitirían comprobar si el comportamiento observado se mantiene cuando varían los modelos, los tamaños de lote y los patrones de tráfico. Esas dimensiones son pertinentes porque el planteamiento depende de cómo se reparte la demanda entre prefill y decode y de la capacidad disponible para responder a ella. Sin resultados para esas condiciones, el desempeño descrito con las trazas mencionadas no debe extrapolarse sin reservas a cargas diferentes.

La reproducibilidad y los límites de elasticidad son cuestiones distintas y ambas siguen abiertas en la información aportada. Disponer de código y configuraciones facilitaría repetir la evaluación; conocer los límites ayudaría a establecer cuándo FluidToken puede absorber trabajo y cuándo FluidRole puede reasignar trabajadores con la rapidez necesaria. Como el trabajo es un preprint y sus métricas no cuentan con verificación independiente en el material disponible, la cifra reportada debe tratarse como provisional, no como garantía de rendimiento en producción.

Continúa explorando

Correcciones y transparencia

Si detectas un dato incorrecto o desactualizado, puedes enviarnos una corrección indicando la página y la fuente que debemos revisar.