Lograr un escalado con tiempo de inactividad casi nulo en Elastic Expert Parallelism

Tradicionalmente, cambiar el número de GPUs en un servicio vLLM requería añadir o eliminar réplicas completas del modelo o reiniciar el motor con un número diferente de GPUs. A medida que los modelos crecen, cada réplica necesita más GPUs, por lo que escalar por réplica añade o elimina GPUs en incrementos cada vez mayores. Reiniciar vLLM para escalar DeepSeek V4 Pro de 16 a 20 GPUs GB200 detuvo el servicio durante 197 segundos (véase la sección de rendimiento para más detalles), dejando esas costosas GPUs asignadas sin generar tokens.

En nuestro primer artículo sobre Elastic EP, mostramos cómo vLLM podía añadir o eliminar GPUs de un despliegue DEP en ejecución (atención en paralelo de datos con MoE en paralelo de expertos) sin reiniciarlo. Aunque evitamos un reinicio, el servicio se detuvo durante toda la reconfiguración mientras inicializábamos nuevos workers, preparábamos los grupos de comunicación ampliados, cargábamos los pesos del modelo y repetíamos el warmup de kernels y la captura de CUDA graphs. En nuestro benchmark de DeepSeek V4 Pro, esta pausa duró 100 segundos al escalar de 16 a 20 GPUs y 56 segundos al volver a escalar a 16 GPUs (detalles completos en la sección de rendimiento).

En este artículo, describimos cómo la preparación asíncrona y NIXL EP permitieron la reconfiguración de Elastic EP con tiempo de inactividad casi nulo. En el mismo benchmark, redujimos el tiempo de inactividad a 0.82 segundos al escalar de 16 a 20 GPUs y 1.96 segundos al volver a escalar a 16 GPUs, lo que nos permitió escalar hacia arriba y hacia abajo con casi ningún impacto en el rendimiento del servicio.

Solapando la preparación de la topología con el servicio

Reorganizamos el flujo de reconfiguración de vLLM en dos fases: preparación en segundo plano y un commit breve. Los workers existentes usan hilos separados en segundo plano para preparar y calentar la comunicación objetivo, transferir los pesos del modelo y sincronizar información relacionada con la ejecución (como los resultados de autotuning) con los workers que se incorporan, mientras siguen atendiendo solicitudes con sus grupos de comunicación y CUDA graphs actuales. En paralelo, los workers que se incorporan se inicializan, reciben los pesos del modelo y preparan su comunicación y ejecución en GPU. Durante la fase de commit, vLLM pausa brevemente sus schedulers, activa la topología preparada y reanuda el servicio. Estos cambios se introdujeron en preparación asíncrona y optimizaciones de prepare/commit.

La preparación cubre cuatro tareas principales:

1. Inicializar los workers que se incorporan. Iniciar sus procesos y asignar almacenamiento para el modelo y la ejecución.
2. Preparar la comunicación. Configurar los grupos de comunicación objetivo y expandir el comunicador EP.
3. Transferir los pesos del modelo. Transferir los pesos necesarios de los trabajadores existentes a los trabajadores que se incorporan a través de NVLink o RDMA.
4. Preparar la ejecución. Completar la compilación necesaria, el calentamiento de kernels, la configuración de ajuste y la construcción de grafos CUDA en los trabajadores que se incorporan.

Después de la fase de commit, el balanceo de carga Expert Parallel Load Balancing (EPLB) asíncrono permite que los nuevos trabajadores comiencen a manejar la atención mientras los trabajadores existentes manejan el cálculo de expertos. Luego, EPLB redistribuye los expertos por el grupo expandido en segundo plano.

El principal desafío es preparar la comunicación y la ejecución en GPU sin involucrar ni interrumpir a los trabajadores que están atendiendo solicitudes.

Expandir la comunicación EP en el lugar

Antes de NIXL EP, los backends de comunicación EP disponibles en vLLM usaban una membresía fija: cada instancia se creaba para un conjunto específico de rangos. Agregar o eliminar rangos requiere una nueva instancia. Incluso cuando esa instancia puede crearse en segundo plano, permanecen dos problemas.

Primero, las instancias antigua y nueva necesitan buffers de comunicación y otros recursos separados, incluidos registros de memoria, manejadores IPC y pares de colas RDMA (QP). Mantener ambas instancias activas aumenta el uso de memoria de comunicación y requiere repetir la configuración en lugar de reutilizar los recursos existentes.

Segundo, cambiar de comunicador EP cambia los buffers y el estado de comunicación utilizados por los kernels de comunicación EP. Esto invalida los grafos CUDA capturados previamente, que deben recapturarse antes de que pueda reanudarse el servicio. Eso requiere repetir el calentamiento y la construcción de grafos para muchas formas de lote en todos los trabajadores retenidos. En nuestro benchmark de DeepSeek V4 Pro, incluso con preparación asíncrona, realizar el calentamiento y la recaptura de grafos durante la fase de commit resultó en pausas de servicio de 58 segundos durante el escalado hacia arriba y 44 segundos durante el escalado hacia abajo.

Para resolver estos problemas, diseñamos NIXL EP, una biblioteca de comunicación EP hecha a medida para Elastic EP. Agrega o elimina rangos en el lugar, reutilizando el mismo agente NIXL, los buffers y las conexiones. Los nuevos pares pueden conectarse mientras los trabajadores existentes continúan atendiendo, y solo los pares que se incorporan necesitan nuevas conexiones y registros. NIXL EP también mantiene válidas las entradas de dispatch y combine de EP capturadas durante la reconfiguración, lo que permite a los trabajadores retenidos reutilizar sus grafos CUDA existentes.

Durante la preparación, el hilo en segundo plano de vLLM conecta los pares que se incorporan sin activarlos. La fase de commit activa entonces los pares preparados sin reemplazar el comunicador.

Figura 1. Conexión y activación de nuevos pares EP. Los rangos verdes están activos; los rangos grises están conectados pero enmascarados. Durante la fase de commit, los nuevos pares se activan sin reemplazar el agente ni los búferes.

vLLM sigue creando nuevos grupos de coordinación DP y grupos EPLB para la topología de destino, pero su comunicación se ejecuta fuera del paso hacia adelante capturado del modelo, de modo que cambiar a ellos no invalida los CUDA graphs.

Preservar los CUDA graphs en los trabajadores existentes

Un CUDA graph registra las operaciones de GPU para que vLLM pueda reproducir un paso hacia adelante sin lanzar repetidamente cada operación desde la CPU. Un nodo de kernel capturado incluye su configuración de lanzamiento y los valores de sus argumentos, incluidos los punteros a los tensores de entrada y salida. El contenido de la memoria puede cambiar entre repeticiones, pero los punteros registrados deben permanecer válidos. Estos requisitos forman parte del contrato de ejecución de CUDA graphs.

vLLM captura gráficos separados para diferentes formas de lote y modos de ejecución y ejecuta pasos hacia adelante de calentamiento antes de cada captura.

Preservar los CUDA graphs capturados requiere más que mantener vivo el objeto comunicador. NIXL EP también mantiene estables las configuraciones de lanzamiento de kernel, los argumentos de comunicación visibles en el gráfico y las direcciones de los tensores de entrada y salida durante la reconfiguración. Sus kernels leen la membresía del grupo activo desde un estado del dispositivo que puede actualizarse in situ.

También modificamos vLLM para mantener estables los argumentos capturados, las configuraciones de lanzamiento y las direcciones de los tensores de entrada y salida de los kernels de cálculo circundantes durante la reconfiguración:

• Reutilizamos los objetos de ejecución fused-MoE de los trabajadores retenidos en lugar de reconstruirlos para un tamaño de EP activo diferente.
• Mantenemos estables las direcciones y los diseños de los espacios de trabajo visibles en el gráfico y de las salidas de dispatch durante la reconfiguración, de modo que los kernels de expertos capturados puedan seguir utilizándolos. Las salidas de dispatch también sirven como entradas para el cálculo de los expertos. Si sus direcciones o diseños cambiaran con el tamaño del EP, los kernels de expertos capturados seguirían usando los punteros y desplazamientos antiguos.
• Preservamos el almacenamiento de respaldo de los tensores de enrutamiento de expertos y actualizamos los mapeos in situ. Esto permite que EPLB cambie el contenido de los mapeos sin mover los tensores utilizados por los kernels capturados.

En conjunto, estos cambios permiten a los trabajadores retenidos reutilizar sus CUDA graphs existentes tanto después del escalado hacia arriba como del escalado hacia abajo.

Preparar los trabajadores entrantes de forma independiente

Los trabajadores existentes tienen gráficos que preservar. Los trabajadores entrantes no tienen ninguno.

Los trabajadores entrantes normalmente se preparan ejecutando pasos hacia adelante del modelo con dispatch y combine de EP, además de intercambiar información de lote con otros trabajadores. Estos pasos requieren que otros trabajadores participen, pero los trabajadores existentes ya están atendiendo solicitudes reales en la topología actual.

NIXL EP permite que cada trabajador entrante enmascare temporalmente todos los pares EP remotos durante el calentamiento y la preparación de gráficos. Solo el rango local de ese trabajador está activo para la comunicación EP. También modificamos vLLM para que estos pasos de preparación no esperen la información de lote DP de otros trabajadores. Esto permite que los trabajadores entrantes ejecuten sus lotes ficticios y capturen CUDA graphs sin requerir la participación de los trabajadores existentes.

Figura 2. Los rangos verdes están activos para la comunicación EP; los rangos grises están enmascarados. Los trabajadores existentes sirven juntos mientras cada trabajador entrante enmascara todos los pares EP remotos para la preparación.

Después de la captura, NIXL EP puede reactivar los pares sin invalidar los gráficos. Los trabajadores entrantes reutilizan sus gráficos capturados localmente cuando comienzan a servir como parte del grupo expandido.

Rendimiento en DeepSeek V4 Pro

Todos los experimentos de esta sección usaron DeepSeek V4 Pro en GPUs GB200, con TP=1 y tamaños de DP/EP de 16 y 20. Los pesos del modelo se descargaron previamente en formato safetensors en almacenamiento compartido Lustre y se cargaron usando el valor predeterminado --load-format auto. Las mediciones usaron cachés de compilación de kernels cálidos (Triton, TileLang y FlashInfer).

Tiempos de escalado hacia arriba y hacia abajo

La tabla muestra qué etapas se ejecutan mientras la prestación del servicio está en pausa y cuáles se ejecutan en segundo plano mientras los trabajadores existentes siguen prestando servicio.

La configuración C es compatible solo con NIXL EP.

• Tiempo de inactividad: la interrupción observada del servicio, cuando las solicitudes en curso dejan de progresar y no se admiten nuevas solicitudes.
• Tiempo total: la duración de toda la operación de escalado, incluida la preparación.

Las dos duraciones se miden por separado.

Todas las configuraciones pasaron las verificaciones de corrección numérica, incluidas verificaciones en cada worker que se incorpora.

Mantener el SLO al añadir GPUs

Servimos DeepSeek V4 Pro en 16 GPUs y luego aumentamos gradualmente la tasa de solicitudes entrantes de aproximadamente 8 a 16 solicitudes por segundo. Reprodujimos el mismo escenario de 11,391 solicitudes contra tres despliegues: uno se mantuvo en 16 GPUs, otro se reinició con 20 GPUs y otro escaló a 20 GPUs usando Elastic EP con NIXL EP. El objetivo de nivel de servicio (SLO) fue un p95 móvil de tiempo hasta el primer token por debajo de 5 segundos.

Figura 3. Servicio de extremo a extremo bajo una carga de solicitudes creciente. Las curvas muestran resultados de p95 móvil de 30 segundos, con las solicitudes fallidas asignadas a una penalización de 30 segundos en lugar de un TTFT medido.

• Elastic EP completó las 11,391 solicitudes y se mantuvo por debajo del SLO durante todo el escenario.
• Durante la preparación, Elastic EP igualó el rendimiento de servicio del despliegue estático de 16 GPUs, sin degradación visible por la preparación en segundo plano.
• Después del escalado, Elastic EP igualó el rendimiento del despliegue recuperado de 20 GPUs, sin degradación visible tras el escalado.

Prueba Elastic EP

La preparación en segundo plano, la reutilización de grafos CUDA y la captura independiente de grafos en los workers que se incorporan están disponibles hoy en las últimas versiones de vLLM y NIXL . Instálalas con pip y empieza a usar Elastic EP.

Para un ejemplo completo de uso, consulta el cuda_graphs_heavy_nixl_ep caso en la prueba de Elastic EP de vLLM. El ejemplo incluye la configuración del servidor y las llamadas a la API de escalado. Escala de dos GPUs a cuatro y de vuelta mientras envía solicitudes, verificando el servicio durante la preparación y la precisión del modelo alrededor de cada cambio de tamaño.

Qué viene después

Restaurar workers calientes con Dynamo Snapshot

Hemos resuelto eficazmente la larga interrupción del servicio. El próximo desafío es tener la nueva capacidad lista antes. Planeamos integrar Instantánea de Dynamo de modo que los workers que se incorporan pueden restaurar el proceso inicializado y el estado de CUDA en lugar de repetir la compilación, el calentamiento de kernels, la construcción de grafos y otros trabajos de arranque.

La comunicación para la topología objetivo debe prepararse por separado porque no se restaura desde la instantánea. Restaurar los pesos de un modelo grande desde el almacenamiento de checkpoints puede dominar el tiempo de restauración, por lo que planeamos conservar la transferencia de pesos de GPU a GPU de Elastic EP desde workers existentes en su lugar.

Lograr una comunicación EP de vanguardia con NIXL EP

Nuestro objetivo es lograr un rendimiento de dispatch y combine de vanguardia con NIXL EP manteniendo soporte completo para Elastic EP y tolerancia a fallos. Una próxima actualización de rendimiento de NIXL EP es el siguiente paso hacia ese objetivo (véase el RFC de la hoja de ruta de NIXL EP).

Conectar Elastic EP a la orquestación de Dynamo y llm-d

Con la capacidad a nivel de motor ya disponible, el siguiente paso es usar Elastic EP desde los autoscalers de los orquestadores. El trabajo hacia esta integración ya está en marcha en las comunidades de vLLM, Dynamo y llm-d.

Estos esfuerzos incluyen el trabajo de vLLM sobre balanceadores de carga externos y la propuesta de Elastic EP de Dynamo.

Si ejecutas inferencia a gran escala, te animamos a probar Elastic EP y compartir tus cargas de trabajo y requisitos operativos. Si desarrollas infraestructura de inferencia, agradecemos las contribuciones a vLLM Elastic EP y NIXL EP. Hagamos que Elastic EP funcione en producción.

Agradecimientos

• A Tyler Michael Smith y Sage Moore de Red Hat por sus invaluables comentarios y sus minuciosas revisiones a lo largo de este trabajo.
• A Linoy Geva (NVIDIA) por su trabajo en el rendimiento de servicio durante la preparación.
• A todo el equipo de NIXL por sus esfuerzos en NIXL EP.
• A Tzu-Ling Kan, Julien Mancuso y todo el equipo de Dynamo por sus esfuerzos para dar soporte a Elastic EP en Dynamo.