NVIDIA Mission Control 2.5 ajoute une récupération autonome pour les charges de travail IA sur Kubernetes

NVIDIA a publié Mission Control 2.5, étendant son moteur de récupération autonome pour prendre en charge les charges de travail IA basées sur Kubernetes gérées par NVIDIA Run:ai. Auparavant limité aux environnements de calcul haute performance (HPC) basés sur Slurm, cette mise à jour permet aux usines d'IA de détecter, diagnostiquer et récupérer automatiquement des anomalies d'infrastructure sans intervention manuelle.

Ce qui s'est passé

Le développement central de cette version est l'intégration d'un cadre de récupération autonome directement dans la boucle de planification Kubernetes. Ce système est conçu pour répondre aux défis uniques de l'entraînement moderne de l'IA, où les travaux s'exécutent sur des centaines de nœuds pendant des jours ou des semaines. À cette échelle, la surveillance réactive traditionnelle et le dépannage manuel deviennent des goulets d'étranglement qui gaspillent une capacité d'accélérateur coûteuse.

Mission Control 2.5 introduit une boucle de contrôle à trois couches qui coordonne le planificateur Kubernetes, un service autonome de récupération de travaux et un service autonome de récupération matérielle. Cette architecture permet à la plateforme de distinguer différents types de défaillances. Elle peut redémarrer un travail dû à une erreur logicielle transitoire tout en mettant simultanément en quarantaine un nœud souffrant d'une dégradation matérielle, garantissant que les ressources défaillantes ne perturbent pas les charges de travail ultérieures.

Cette extension marque un passage des workflows d'incident spécifiques au planificateur vers un modèle opérationnel unifié et conscient du planificateur. Les équipes de plateforme gérant des environnements mixtes Kubernetes et Slurm peuvent désormais appliquer une stratégie de résilience cohérente. L'objectif est de minimiser le temps moyen de réparation et de maximiser l'utilisation des clusters GPU en gardant les charges de travail productives plutôt que bloquées dans l'ambiguïté.

Comment cela fonctionne

Le moteur de récupération autonome opère comme un système coordonné de trois composants distincts. Premièrement, le planificateur Kubernetes, alimenté par NVIDIA Run:ai, gère le placement des charges de travail, la mise en file d'attente et l'application des politiques. Il détermine où les travaux doivent s'exécuter en fonction de la capacité disponible et des exigences en ressources.

Deuxièmement, le service autonome de récupération de travaux agit comme couche de contexte. Il surveille les travaux en cours, suit leur emplacement d'exécution et analyse l'historique des défaillances ainsi que la topologie des travaux. Lorsqu'une défaillance se produit, ce service classe le problème pour déterminer la voie de récupération appropriée, telle qu'une nouvelle tentative, un redémarrage ou une remise en file d'attente. Il garantit que le système ne surestime pas les petits bugs logiciels transitoires en évitant les remédiations matérielles inutiles.

Troisièmement, le service autonome de récupération matérielle gère la santé de l'infrastructure. Il surveille les nœuds et les GPU pour détecter des signes de dégradation, tels que des erreurs ECC ou des délais de communication dépassés. Si une panne matérielle est détectée, ce service isole le nœud affecté du pool de planification et lance des diagnostics. Ce processus s'exécute en parallèle avec la récupération des travaux, permettant à la charge de travail de reprendre sur des nœuds sains tandis que le matériel défaillant est réparé ou validé.

Détails clés

• Architecture à trois couches : Le système intègre le planificateur Kubernetes, la récupération autonome des travaux et la récupération autonome du matériel dans une seule boucle de contrôle.
• Voies de récupération parallèles : Lors de pannes matérielles, le travail est redémarré ou replanifié immédiatement tandis que le nœud défaillant est mis en quarantaine et diagnostiqué en arrière-plan.
• Nouvelles tentatives conscientes du contexte : Le service de récupération des travaux utilise l'historique des défaillances pour distinguer les erreurs logicielles transitoires des problèmes matériels persistants, empêchant le retrait inutile de nœuds.
• Détection proactive de la dégradation : Le service de récupération matérielle peut identifier les nœuds risqués avant qu'ils ne causent des échecs de travaux, les retirant préventivement du pool de planification.
• Modèle unifié : La mise à jour fournit un cadre de récupération cohérent pour les environnements Kubernetes et Slurm, simplifiant les opérations pour les équipes d'infrastructure hybrides.
• Fonctionnalités supplémentaires : La version 2.5 inclut également une détection bêta des anomalies réseau assistée par IA, une authentification Keycloak améliorée et des mises à jour de durcissement de Kubernetes.

Pourquoi c'est important

Pour les équipes d'ingénierie développant des produits IA à grande échelle, la fiabilité de l'infrastructure contribue directement à la vélocité du développement et à l'efficacité des coûts. Lorsqu'un travail d'entraînement distribué échoue après plusieurs jours d'exécution, le temps de calcul perdu et les itérations de modèle retardées sont significatifs. En automatisant le processus de récupération, Mission Control 2.5 réduit la charge opérationnelle pesant sur les ingénieurs de plateforme qui devraient autrement investiguer manuellement les logs, isoler les nœuds et redémarrer les travaux.

La capacité à distinguer les défaillances logicielles des défaillances matérielles est particulièrement critique. Dans de nombreuses configurations traditionnelles, une seule panne de nœud pourrait déclencher une alerte générale ou nécessiter une inspection manuelle de l'ensemble du cluster. La retenue de ce système dans la gestion des erreurs logicielles transitoires signifie que le matériel sain reste dans le pool de planification, maintenant une utilisation globale plus élevée du cluster. Inversement, le retrait proactif des nœuds en dégradation empêche les défaillances en cascade qui pourraient perturber plusieurs entraînements concurrents.

Ce virage vers une infrastructure auto-réparatrice permet aux organisations de faire évoluer leurs usines d'IA avec plus de confiance. À mesure que le nombre de charges de travail multi-nœuds concurrentes augmente, la complexité de la gestion manuelle croît exponentiellement. La récupération automatisée garantit que l'infrastructure peut gérer cette échelle sans augmentation proportionnelle des effectifs opérationnels ni risque d'erreur humaine lors de la réponse aux incidents.

Ce que vous pouvez faire

• Consultez le hub de documentation officiel pour comprendre le chemin de mise à niveau pour les utilisateurs existants de Mission Control passant à la version 2.5.
• Évaluez vos politiques de planification Kubernetes actuelles pour vous assurer qu'elles s'alignent avec les capacités de nouvelle tentative et de redémarrage automatisés de NVIDIA Run:ai.
• Implémentez des stratégies de sauvegarde (checkpointing) robustes dans vos pipelines d'entraînement pour compléter le moteur de récupération autonome, minimisant la perte de données lors des redémarrages de travaux.
• Surveillez le nouveau service de détection des anomalies réseau assisté par IA en bêta pour identifier les potentiels problèmes de connectivité avant qu'ils n'affectent la stabilité de l'entraînement.
• Auditez vos workflows de maintenance matérielle pour les intégrer avec les diagnostics automatisés et les fonctionnalités de quarantaine fournis par le service de récupération matérielle.
• Testez le comportement du système avec des erreurs transitoires simulées pour vérifier que le service de récupération des travaux évite correctement les remédiations matérielles inutiles.