Atteindre une mise à l'échelle à temps d'arrêt quasi nul dans Elastic Expert Parallelism

Traditionnellement, modifier le nombre de GPU dans un service vLLM nécessitait d'ajouter ou de retirer des réplicas entiers du modèle ou de redémarrer le moteur avec un nombre différent de GPU. À mesure que les modèles grossissent, chaque réplica nécessite davantage de GPU, de sorte que la mise à l'échelle par réplica ajoute ou retire des GPU par incréments de plus en plus importants. Redémarrer vLLM pour faire passer DeepSeek V4 Pro de 16 à 20 GPU GB200 interrompait le service pendant 197 secondes (voir la section sur les performances pour plus de détails), laissant ces GPU coûteux alloués sans générer de tokens.

Dans notre premier article sur Elastic EP, nous avons montré comment vLLM pouvait ajouter ou retirer des GPU d'un déploiement DEP en cours d'exécution (attention en parallélisme de données avec MoE en parallélisme d'experts) sans le redémarrer. Bien que nous ayons évité un redémarrage, le service s'interrompait quand même pendant toute la reconfiguration, lorsque nous initialisions les nouveaux workers, préparions les groupes de communication étendus, chargions les poids du modèle et répétions l'échauffement des kernels et la capture des graphes CUDA. Dans notre benchmark DeepSeek V4 Pro, cette pause durait 100 secondes lors du passage de 16 à 20 GPU et 56 secondes lors du retour à 16 GPU (tous les détails dans la section sur les performances).

). Dans cet article, nous décrivons comment la préparation asynchrone et NIXL EP ont permis une reconfiguration d'Elastic EP avec un temps d'arrêt quasi nul. Dans le même benchmark, nous avons réduit le temps d'arrêt à 0,82 seconde lors du passage de 16 à 20 GPU et 1,96 seconde lors du retour à 16 GPU, ce qui nous a permis de monter et descendre en charge avec presque aucun impact sur les performances de service.

Recouvrir la préparation de la topologie avec le service

Nous avons réorganisé le flux de reconfiguration de vLLM en deux phases : une préparation en arrière-plan et un commit court. Les workers existants utilisent des threads d'arrière-plan distincts pour préparer et échauffer la communication cible, transférer les poids du modèle et synchroniser les informations liées à l'exécution (telles que les résultats d'autotuning) avec les workers entrants, tout en continuant à traiter les requêtes avec leurs groupes de communication et graphes CUDA actuels. En parallèle, les workers entrants s'initialisent, reçoivent les poids du modèle et préparent leur communication et leur exécution GPU. Pendant la phase de commit, vLLM suspend brièvement ses ordonnanceurs, active la topologie préparée et reprend le service. Ces changements ont été introduits dans la préparation asynchrone et les optimisations prepare/commit.

La préparation couvre quatre tâches principales :

1. Initialiser les workers entrants. Démarrer leurs processus et allouer le stockage pour le modèle et l'exécution.
2. Préparer la communication. Configurez les groupes de communication cibles et développez le communicateur EP.
3. Transférer les poids du modèle. Transférer les poids requis des workers existants vers les workers entrants via NVLink ou RDMA.
4. Préparer l'exécution. Effectuer la compilation requise, le warmup des kernels, la configuration du tuning et la construction des CUDA graphs sur les workers entrants.

Après la phase de commit, l'équilibrage de charge Expert Parallel asynchrone (EPLB) permet aux nouveaux workers de commencer à traiter l'attention tandis que les workers existants gèrent le calcul des experts. EPLB redistribue ensuite les experts dans le groupe étendu en arrière-plan.

Le principal défi consiste à préparer la communication et l'exécution GPU sans impliquer ni perturber les workers qui servent des requêtes.

Étendre la communication EP en place

Avant NIXL EP, les backends de communication EP disponibles dans vLLM utilisaient une appartenance fixe : chaque instance était créée pour un ensemble spécifique de ranks. L'ajout ou la suppression de ranks nécessite une nouvelle instance. Même lorsque cette instance peut être créée en arrière-plan, deux problèmes demeurent.

Premièrement, les anciennes et nouvelles instances nécessitent des tampons de communication et d'autres ressources distincts, notamment les enregistrements mémoire, les IPC handles et les RDMA Queue Pairs (QPs). Maintenir les deux instances actives augmente l'utilisation mémoire de la communication et nécessite de répéter la configuration au lieu de réutiliser les ressources existantes.

Deuxièmement, le changement de communicateur EP modifie les tampons et l'état de communication utilisés par les kernels de communication EP. Cela invalide les CUDA graphs capturés précédemment, qui doivent être recapturés avant de pouvoir reprendre le service. Cela nécessite de répéter le warmup et la construction de graphes pour de nombreuses formes de batchs sur tous les workers conservés. Dans notre benchmark DeepSeek V4 Pro, même avec une préparation asynchrone, l'exécution du warmup et de la recapture des graphes pendant la phase de commit a entraîné des pauses de service de 58 secondes lors du scale-up et 44 secondes lors du scale-down.

Pour résoudre ces problèmes, nous avons conçu NIXL EP, une bibliothèque de communication EP conçue sur mesure pour Elastic EP. Elle ajoute ou supprime des ranks en place, en réutilisant le même agent NIXL, les mêmes tampons et les mêmes connexions. De nouveaux pairs peuvent être connectés pendant que les workers existants continuent de servir, et seuls les pairs entrants ont besoin de nouvelles connexions et d'enregistrements. NIXL EP maintient également les entrées EP dispatch et combine capturées valides entre les reconfigurations, permettant aux workers conservés de réutiliser leurs CUDA graphs existants.

Pendant la préparation, le thread d'arrière-plan de vLLM connecte les pairs qui rejoignent sans les activer. La phase de commit active ensuite les pairs préparés sans remplacer le communicateur.

Figure 1. Connexion et activation de nouveaux pairs EP. Les rangs verts sont actifs ; les rangs gris sont connectés mais masqués. Pendant la phase de commit, les nouveaux pairs sont activés sans remplacer l'agent ni les tampons.

vLLM crée toujours de nouveaux groupes de coordination DP et groupes EPLB pour la topologie cible, mais leur communication s'exécute en dehors de la passe forward capturée du modèle, de sorte que le basculement vers eux n'invalide pas les graphes CUDA.

Préserver les graphes CUDA sur les workers existants

Un graphe CUDA enregistre les opérations GPU afin que vLLM puisse rejouer une passe forward sans relancer chaque opération depuis le CPU à répétition. Un nœud de kernel capturé inclut sa configuration de lancement et ses valeurs d'arguments, y compris les pointeurs vers les tenseurs d'entrée et de sortie. Le contenu de la mémoire peut changer entre les rejeux, mais les pointeurs enregistrés doivent rester valides. Ces exigences font partie du contrat d'exécution des graphes CUDA.

vLLM capture des graphes séparés pour différentes formes de batch et modes d'exécution et exécute des passes forward d'échauffement avant chaque capture.

Préserver les graphes CUDA capturés exige plus que maintenir l'objet communicateur en vie. NIXL EP maintient également stables les configurations de lancement des kernels, les arguments de communication visibles dans les graphes et les adresses des tenseurs d'entrée et de sortie lors des reconfigurations. Ses kernels lisent l'appartenance au groupe actif à partir d'un état de périphérique qui peut être mis à jour en place.

Nous avons également modifié vLLM pour maintenir stables les arguments capturés, les configurations de lancement et les adresses des tenseurs d'entrée et de sortie des kernels de calcul environnants lors des reconfigurations :

• Nous réutilisons les objets d'exécution fused-MoE conservés des workers retenus au lieu de les reconstruire pour une taille EP active différente.
• Nous maintenons les adresses et dispositions des espaces de travail visibles dans les graphes et des sorties de dispatch stables lors des reconfigurations, afin que les kernels d'experts capturés puissent continuer à les utiliser. Les sorties de dispatch servent également d'entrées au calcul des experts. Si leurs adresses ou dispositions changeaient avec la taille EP, les kernels d'experts capturés continueraient d'utiliser les anciens pointeurs et décalages.
• Nous préservons le stockage sous-jacent des tenseurs de routage d'experts et mettons à jour les correspondances en place. Cela permet à EPLB de modifier le contenu des correspondances sans déplacer les tenseurs utilisés par les kernels capturés.

Ensemble, ces changements permettent aux workers retenus de réutiliser leurs graphes CUDA existants après un passage à l'échelle supérieure comme inférieure.

Préparer indépendamment les workers qui rejoignent

Les workers existants ont des graphes à préserver. Les workers qui rejoignent n'en ont aucun.

Les workers qui rejoignent se préparent normalement en exécutant des passes forward du modèle avec le dispatch et le combine EP, ainsi qu'en échangeant des informations de batch avec d'autres workers. Ces étapes exigent la participation d'autres workers, mais les workers existants servent déjà de vraies requêtes sur la topologie actuelle.

NIXL EP permet à chaque worker qui rejoint de masquer temporairement tous les pairs EP distants pendant l'échauffement et la préparation des graphes. Seul le rang local de ce worker est actif pour la communication EP. Nous avons également modifié vLLM afin que ces passes de préparation n'attendent pas les informations de batch DP d'autres workers. Cela permet aux workers qui rejoignent d'exécuter leurs batches factices et de capturer les graphes CUDA sans exiger la participation des workers existants.

Figure 2. Les rangs verts sont actifs pour la communication EP ; les rangs gris sont masqués. Les workers existants servent ensemble tandis que chaque worker qui rejoint masque tous les pairs EP distants pour la préparation.

Après la capture, NIXL EP peut réactiver les pairs sans invalider les graphes. Les workers qui rejoignent réutilisent leurs graphes capturés localement lorsqu'ils commencent à servir au sein du groupe élargi.

Performances sur DeepSeek V4 Pro

Toutes les expériences de cette section ont utilisé DeepSeek V4 Pro sur des GPU GB200, avec TP=1 et des tailles DP/EP de 16 et 20. Les poids du modèle ont été pré-téléchargés au format safetensors sur un stockage Lustre partagé et chargés à l'aide du --load-format autopar défaut. Les mesures ont utilisé des caches de compilation de kernels échauffés (Triton, TileLang et FlashInfer).

Temps de montée et de réduction en charge

Le tableau montre quelles étapes s'exécutent pendant que le service est en pause et lesquelles s'exécutent en arrière-plan pendant que les workers existants continuent de servir.

La configuration C est prise en charge uniquement par NIXL EP.

• Temps d'indisponibilité : l'interruption de service observée, lorsque les requêtes en cours cessent de progresser et que les nouvelles requêtes ne sont pas admises.
• Durée totale : la durée de l'opération complète de mise à l'échelle, y compris la préparation.

Les deux durées sont mesurées séparément.

Toutes les configurations ont passé les vérifications d'exactitude numérique, y compris des vérifications sur chaque worker en cours de connexion.

Maintenir le SLO tout en ajoutant des GPU

Nous avons servi DeepSeek V4 Pro sur 16 GPU, puis augmenté progressivement le taux de requêtes entrantes d'environ 8 à 16 requêtes par seconde. Nous avons rejoué le même scénario de 11,391 requêtes sur trois déploiements : l'un est resté à 16 GPU, l'un a redémarré avec 20 GPU, et l'un est passé à 20 GPU à l'aide d'Elastic EP avec NIXL EP. L'objectif de niveau de service (SLO) était un p95 glissant du temps jusqu'au premier token inférieur à 5 secondes.

Figure 3. Service de bout en bout sous une charge de requêtes croissante. Les courbes montrent les résultats p95 glissants sur 30 secondes, les requêtes échouées se voyant attribuer une pénalité de 30 secondes plutôt qu'un TTFT mesuré.

• Elastic EP a traité les 11,391 requêtes et est resté en dessous du SLO tout au long du scénario.
• Pendant la préparation, Elastic EP a égalé les performances de service du déploiement statique de 16 GPU, sans dégradation visible due à la préparation en arrière-plan.
• Après la mise à l'échelle, Elastic EP a égalé les performances du déploiement récupéré de 20 GPU, sans dégradation visible après la mise à l'échelle.

Essayez Elastic EP

La préparation en arrière-plan, la réutilisation des graphes CUDA et la capture indépendante des graphes sur les workers en cours de connexion sont toutes disponibles aujourd'hui dans les dernières versions de vLLM et NIXL . Installez-les avec pip et commencez à utiliser Elastic EP.

Pour un exemple d'utilisation complet, voir le cuda_graphs_heavy_nixl_ep cas dans le test Elastic EP de vLLM. L'exemple inclut la configuration du serveur et les appels d'API de mise à l'échelle. Il passe de deux GPU à quatre puis revient en arrière tout en envoyant des requêtes, en vérifiant le service pendant la préparation et l'exactitude du modèle autour de chaque redimensionnement.

Et ensuite

Restaurer les workers à chaud avec Dynamo Snapshot

Nous avons résolument résolu la longue interruption de service. Le prochain défi est de rendre la nouvelle capacité prête plus rapidement. Nous prévoyons d'intégrer Instantané Dynamo afin que les workers qui rejoignent puissent restaurer un état de processus et CUDA initialisé au lieu de répéter la compilation, le préchauffage des kernels, la construction du graphe et autres travaux de démarrage.

La communication pour la topologie cible doit être préparée séparément, car elle n'est pas restaurée depuis l'instantané. La restauration des poids de grands modèles depuis le stockage des checkpoints peut dominer le temps de restauration ; nous prévoyons donc de conserver le transfert de poids GPU-à-GPU d'Elastic EP depuis les workers existants.

Atteindre une communication EP à la pointe de l'état de l'art avec NIXL EP

Nous visons des performances de dispatch et combine à l'état de l'art avec NIXL EP tout en maintenant une prise en charge complète d'Elastic EP et de la tolérance aux pannes. Une prochaine mise à jour de performance de NIXL EP constitue l'étape suivante vers cet objectif (voir le RFC de la feuille de route NIXL EP).

Connecter Elastic EP à l'orchestration Dynamo et llm-d

Une fois la capacité au niveau du moteur en place, l'étape suivante consiste à utiliser Elastic EP depuis les autoscalers de l'orchestrateur. Le travail vers cette intégration est déjà en cours au sein des communautés vLLM, Dynamo et llm-d.

Ces efforts incluent les travaux de vLLM sur l'équilibreur de charge externe et la proposition d'Elastic EP de Dynamo.

Si vous exécutez l'inférence à grande échelle, nous vous encourageons à essayer Elastic EP et à partager vos charges de travail et vos exigences opérationnelles. Si vous construisez une infrastructure d'inférence, nous accueillons les contributions à vLLM Elastic EP et NIXL EP. Faisons fonctionner Elastic EP en production.

Remerciements

• Tyler Michael Smith et Sage Moore de Red Hat pour leurs retours inestimables et leurs relectures approfondies tout au long de ce travail.
• Linoy Geva (NVIDIA) pour son travail sur les performances de service pendant la préparation.
• Toute l'équipe NIXL pour ses efforts sur NIXL EP.
• Tzu-Ling Kan, Julien Mancuso, et toute l'équipe Dynamo pour leurs efforts visant à prendre en charge Elastic EP dans Dynamo.