Mission Control 2.5 étend la récupération aux tâches Kubernetes de Run:ai

Dans un article du 26 octobre, NVIDIA indique que Mission Control 2.5 étend son moteur de récupération autonome aux tâches Kubernetes gérées par NVIDIA Run:ai. Le service concernait auparavant les tâches de calcul de haute performance utilisant Slurm. Notre édition est datée du 28 octobre, deux jours après le texte d’origine. Celui-ci décrit une fonction et son architecture, sans fournir une réduction mesurée du temps moyen de réparation, une hausse chiffrée de disponibilité ou une comparaison contrôlée avec une exploitation manuelle. Le nom « récupération autonome » ne signifie pas qu’un entraînement quelconque redémarre sans perte et dans un délai garanti.

La boucle de contrôle répartit les responsabilités. L’ordonnanceur Kubernetes place les tâches sur des nœuds disponibles. Le service de récupération des tâches garde le contexte d’un échec et choisit entre nouvelle tentative, déplacement et remontée du problème. Le service de récupération matérielle surveille la santé des équipements, isole une machine suspecte et lance des diagnostics. En séparant ces actions, la tâche peut éventuellement reprendre sur une autre capacité pendant que la panne matérielle est encore analysée. Ce qui peut être restauré dépend aussi des points de contrôle et de la configuration de chaque application; l’article ne démontre pas une reprise universelle à n’importe quel instant.

Le premier scénario montre une panne GPU durant un entraînement distribué. Des erreurs mémoire, un processus bloqué ou un délai de communication peuvent être des symptômes. Le service des tâches collecte le contexte et l’ordonnanceur relance ou déplace le travail vers une ressource saine. En parallèle, le service matériel retire le nœud de la liste des machines utilisables, enregistre la raison et commence le diagnostic. Cette séparation évite de confier aussitôt un nouveau travail à un équipement suspect. Les figures décrivent toutefois un flux voulu, pas le nombre réel d’incidents rencontrés ni un taux de réussite constaté.

Une erreur logicielle temporaire appelle une autre réponse. Un processus peut s’arrêter ou perdre brièvement la coordination alors que le nœud est sain. Une nouvelle tentative suivant la politique de l’ordonnanceur peut suffire, sans bloquer inutilement le matériel. Un échec répété ou non récupérable doit sortir de ce chemin automatique pour être examiné. Enfin, la surveillance peut repérer une dégradation matérielle avant qu’elle n’arrête une tâche : un nœud présentant des avertissements répétés peut être retiré des futurs placements et diagnostiqué. Ces trois cas montrent pourquoi traiter tous les échecs comme une panne physique ou comme une fluctuation logicielle serait inadéquat.

Pour juger le produit dans un centre de calcul précis, un exploitant devrait provoquer des défaillances contrôlées et mesurer tâches terminées, travail perdu depuis le dernier point de contrôle, capacité immobilisée et délai de reprise. Isoler à tort une machine saine réduit la capacité utile; répéter à tort une tâche sur une machine défaillante prolonge la panne. NVIDIA renvoie aussi à des notes de version mentionnant la détection d’anomalies réseau assistée par IA, mais ce lien ne fournit pas dans le billet une mesure des gains de récupération. L’information nouvelle vérifiable est l’extension à Kubernetes avec Run:ai et la séparation des trois rôles. Les résultats opérationnels restent à établir dans chaque installation.