Towards Resiliency in Large Language Model Serving with KevlarFlow

Résumé technique : Vers la résilience du service de modèles de langage de grande taille avec KevlarFlow

Énoncé du problème

Les systèmes de service de modèles de langage de grande taille (LLM) souffrent actuellement d'une fragilité fondamentale lorsqu'ils sont déployés dans des clusters hyperscale. Malgré l'ubiquité des LLM, l'infrastructure sous-jacente est sujette à des défaillances matérielles fréquentes (par exemple, des pannes de GPU), ce qui déclenche des interruptions de service disproportionnées. Les causes profondes de cette crise de fiabilité sont triples :

1. Instabilité matérielle : Les clusters de GPU en production subissent des défaillances de composants à haute fréquence.
2. Fragilité logicielle : Les frameworks de service modernes (par exemple, vLLM, TensorRT-LLM) reposent sur des bibliothèques de communication collective (MPI, NCCL) qui optimisent le débit plutôt que la tolérance aux pannes. Ces systèmes établissent des topologies de périphériques rigides et statiques au démarrage. Par conséquent, la défaillance d'un seul nœud rend l'ensemble du groupe de parallélisme de modèle (par exemple, un groupe de parallélisme de tenseur ou de pipeline) inutilisable, même si les autres nœuds restent sains.
3. Récupération lente : Restaurer une instance défaillante nécessite généralement de réinitialiser le nœud de service et de recharger des poids de modèle massifs depuis un stockage distant. Ce processus peut prendre jusqu'à 10 minutes, période durant laquelle le service reste sans réponse. De plus, les techniques de redondance traditionnelles comme la réplication de données sont difficiles à appliquer à l'inférence de LLM en raison de la nature gourmande en mémoire du cache KV et de l'état transitoire des requêtes d'inférence.

Les approches de tolérance aux pannes existantes dans l'entraînement (par exemple, le checkpointing) ne s'appliquent pas au service en raison de la nécessité de capturer les états transitoires du cache KV et d'exigences de latence plus strictes (par exemple, le temps jusqu'au premier jet ou TTFT). De même, les solutions de service existantes comme DejaVu ou AnchorTP nécessitent souvent le redémarrage de l'instance après un changement de topologie ou ne tolèrent que les défaillances intra-nœuds, échouant ainsi à traiter les défaillances de nœuds complets sans interruption de service.

Méthodologie : Architecture KevlarFlow

KevlarFlow est une architecture de service tolérante aux pannes conçue pour combler l'écart entre l'imprévisibilité du matériel et la disponibilité du service. Elle abandonne le paradigme traditionnel de « fail-stop » (arrêt sur panne) au profit d'un modèle de « fail-stutter » (hésitation sur panne), traitant le cluster comme un réservoir de ressources flexible plutôt que comme une collection d'instances rigides. Le système repose sur trois contributions de conception fondamentales :

1. Initialisation découplée du parallélisme de modèle

Contrairement aux frameworks standards qui effectuent le chargement des poids du modèle et l'initialisation du communicateur simultanément au démarrage, KevlarFlow découple ces processus.

• Mécanisme : Le système utilise une approche de construction progressive où les nœuds participants se connectent de manière autonome les uns aux autres. Le communicateur de communication est construit uniquement après que les nœuds ont été vérifiés comme sains.
• Avantage : Cela permet une reconfiguration dynamique de la topologie des périphériques au moment de l'exécution. Si un nœud échoue, le système peut rétablir la communication entre les nœuds restants sains et identifier un nœud de remplacement possédant les mêmes poids de modèle sans démanteler l'ensemble du cluster ou recharger les poids.

2. Reroutage dynamique du trafic

KevlarFlow introduit une stratégie de gestion du trafic pour gérer les défaillances partielles du parallélisme de modèle.

• Mécanisme : Au lieu de marquer une instance entière comme hors ligne lorsqu'un seul nœud dans un pipeline échoue, KevlarFlow reroute dynamiquement le trafic utilisateur autour du nœud défaillant vers d'autres instances saines au sein du groupe d'équilibrage de charge.
• Avantage : Cela maintient les parties saines du modèle endommagé en service. Cela empêche le gaspillage de ressources GPU fonctionnelles qui seraient autrement bloquées par des dépendances dans un scénario de panne standard, améliorant considérablement le débit dans des conditions de défaillance.

3. Réplication du cache KV en arrière-plan

Pour atténuer la pénalité de latence du redémarrage des requêtes, KevlarFlow implémente un mécanisme de réplication du cache Clé-Valeur (KV) en arrière-plan à faible surcharge.

• Mécanisme : Les états d'inférence intermédiaires (cache KV) sont répliqués dans la mémoire GPU d'autres nœuds du groupe d'équilibrage de charge pendant l'exécution en utilisant une représentation par blocs et un flux CUDA séparé pour superposer la communication et le calcul.
• Avantage : Si une défaillance survient, les requêtes partiellement servies peuvent être poursuivies presque instantanément sur un nœud actif (la cible de réplication) en utilisant l'état répliqué. Cela transforme une panne matérielle nécessitant un redémarrage en une migration transparente, préservant le contexte de session de l'utilisateur et évitant les tentatives de requête.

Le système utilise l'espace mémoire disponible existant (généralement 40 à 50 % non utilisé dans les charges de travail de production) pour gérer le trafic rerouté et les caches répliqués. Si la pression mémoire devient trop forte, les caches KV répliqués sont supprimés et recalculés si nécessaire.

Résultats clés

Les auteurs ont évalué KevlarFlow sur des clusters virtuels géo-distribués (configurations à 8 et 16 nœuds) en utilisant le modèle Llama-3.1-8B avec un parallélisme de pipeline à 4 étapes. Le système a été testé contre des comportements de panne standard (où la défaillance d'un seul nœud arrête l'ensemble du pipeline) sous divers scénarios de défaillance.

• Améliorations de la latence et du TTFT : Dans des conditions de défaillance partielle, KevlarFlow a démontré des améliorations massives par rapport aux systèmes de pointe :

  • Latence moyenne : amélioration de 3,1x.
  • Latence au 99e percentile (p99) : amélioration de 2,8x.
  • Temps moyen jusqu'au premier jet (TTFT) : amélioration de 378,9x.
  • p99 TTFT : amélioration de 574,6x.
  • Ces gains sont attribués à la capacité du système à maintenir la capacité et à prévenir les files d'attente de requêtes qui se produisent lorsque les systèmes standards interrompent l'intégralité des pipelines.

• Temps de récupération (MTTR) : KevlarFlow a réduit le temps moyen de récupération (MTTR) pour les défaillances de nœuds, passant des 10 minutes typiques à environ 30 secondes (une amélioration de 20x). Cela est rendu possible en superposant l'initialisation des nœuds de remplacement avec la poursuite de l'opération du pipeline dégradé.

• Surcharge d'exécution (Overhead) : Lors des opérations normales sans défaillance, la réplication du cache KV en arrière-plan induit une surcharge négligeable :

  • Surcharge de latence moyenne : 2,3 % (8 nœuds) et 4,0 % (16 nœuds).
  • Surcharge de latence p99 : 2,8 % (8 nœuds) et 3,6 % (16 nœuds).
  • Le système superpose efficacement les coûts de communication avec le calcul, confirmant sa viabilité en tant que solution « toujours active ».

Signification et revendications

L'article affirme que KevlarFlow est le premier framework de service de LLM capable de tolérer des défaillances de nœuds au moment de l'exécution tout en permettant une gestion des requêtes non interruptive pendant la récupération. Sa signification réside dans :

1. Résilience : Il transforme l'infrastructure de service de LLM en un tissu auto-réparateur qui se dégrade gracieusement plutôt que de faillir de manière catastrophique.
2. Efficacité : En utilisant le reroutage dynamique du trafic et la réplication en arrière-plan, il maximise l'utilisation des ressources sans nécessiter de nœuds « hot spare » (réserve chaude) inactifs, offrant une meilleure efficacité de coût par rapport aux approches de redondance traditionnelles.
3. Scalabilité : L'architecture maintient une tolérance aux pannes cohérente à travers diverses intensités de charge de travail et environnements géo-distribués, répondant à une lacune critique de fiabilité dans l'infrastructure IA moderne.

Les auteurs concluent que KevlarFlow masque efficacement les défaillances matérielles avec des pénalités de performance minimales, ce qui en fait une solution robuste pour la prochaine génération d'infrastructures d'IA.