Diagnostic des pannes des charges de travail d’IA distribuée avec NVIDIA Attribution

Diagnostic des pannes de charges de travail d’IA distribuée avec NVIDIA Attribution

Dans le domaine de l’intelligence artificielle distribuée, une seule panne matérielle peut déclencher une cascade de symptômes qui obscurcissent l’origine réelle d’une panne. Lorsqu’une GPU rencontre une panne grave, les nœuds suivants peuvent signaler des erreurs de communication, les états du planificateur peuvent changer, et des milliers de messages de journal peuvent apparaître dans tout le cluster. L’exception signalée indique souvent où la charge de travail s’est arrêtée, mais pas où la panne a commencé. NVIDIA Attribution gère cette complexité en corrélant les journaux, les métriques, la télémétrie et les états du planificateur propres à chaque charge de travail afin d’obtenir un diagnostic structuré.

Selon NVIDIA, cet outil open source permet aux équipes d’infrastructure de transformer des données brutes relatives aux charges de travail en un diagnostic reproductible sur leurs propres clusters. Le système fonctionne grâce à deux composants déployables : le Attribution Service, qui expose une API REST pour le moteur principal d’attribution, et l’Attribution Blueprint, un orchestrateur de référence en Python qui relie les planificateurs de cluster et les sources de télémétrie au Service.

Architecture et composants principaux

L’architecture de NVIDIA Attribution est conçue pour séparer la logique principale de l’intégration spécifique à chaque environnement. Le Attribution Service analyse une tentative de charge de travail à la fois, rendant l’attribution disponible via une API REST. L’Attribution Blueprint, quant à lui, s’occupe de l’intégration propre à chaque cluster. Il découvre les charges de travail, résout le contexte d’exécution, exécute des collecteurs, appelle le Service, enrichit le résultat et écrit celui-ci dans des destinations prévues, y compris un tableau de bord en lecture seule.

Cette séparation permet aux équipes d’appliquer la même logique d’attribution sur différents clusters tout en adaptant les planificateurs, les sources de télémétrie et les connecteurs de sortie à chaque environnement. Le Blueprint inclut des connecteurs pour le contexte d’exécution destinés à Slurm, Kueue et aux entrées statiques. De plus, il comprend des connecteurs pour les journaux et les métriques provenant de Loki, de fichiers locaux, des journaux des pods Kubernetes et des métriques PromQL.

NVIDIA indique que ce système est utilisé en production au sein de l’infrastructure AI d’NVIDIA depuis des années. Dans un grand cluster prenant en charge RDMA, il a permis de corrélater les erreurs de port, les réinitialisations de connexion et les événements du planificateur afin d’identifier des schémas liés à des ports hôtes et de commutateurs spécifiques. Cette capacité aide les équipes à effectuer des réparations ciblées sur le réseau et à ajuster efficacement la congestion.

Le processus d’attribution en quatre étapes

Le processus d’attribution suit un flux de travail déterministe en quatre étapes conçu pour séparer les symptômes ultérieurs de l’événement ayant causé la panne.

1. Définir le périmètre de la charge de travail : Le Blueprint identifie la tentative de traitement de la charge de travail à partir d’identifiants du planificateur ou d’une fenêtre d’exécution explicite ainsi que d’une allocation de nœuds.
2. Collecter des observations : Les connecteurs de journaux et de métriques génèrent des enregistrements d’observations liés à la charge de travail, à partir des journaux d’application, des syslogs, des messages du pilote GPU et du Fabric Manager, de l’historique du planificateur, ainsi que des métriques des nœuds et du réseau.
3. Extraiter et corrélater les événements : Le service invoque le moteur d’attribution pour identifier des événements importants tels que les XIDs GPU, les pannes NCCL, les transitions du planificateur et les conditions des métriques. Des règles déterministes évaluent leur chronologie et leurs interactions.
4. Fournir un résultat structuré : Le Blueprint combine le verdict avec le résultat de la charge de travail (terminalstate), le domaine attribué (subdomain), les symptômes, les nœuds affectés, ainsi qu’un enregistrement de la couverture du collecteur et des erreurs.

Ce processus garantit que les résultats sont reproductibles et personnalisables. La sortie structurée permet une intégration avec les systèmes existants de suivi de l’état et de récupération, permettant aux systèmes ultérieurs d’utiliser terminalstate et subdomain au lieu de parser des journaux spécifiques au produit.

Interpréter les preuves : un exemple concret

Pour illustrer le fonctionnement du système, considérons une charge de travail d’entraînement multi-rang synthétique dans laquelle une GPU rencontre une panne matérielle. Dans ce scénario, les journaux d’application contiennent trois erreurs NCCL différentes, tandis que les journaux système sur node-02 contiennent un XID 149 dont les mots d’erreur indiquent un problème d’intégrité du signal NVLink.

La phase d’extraction s’effectue d’abord sur les journaux d’entrée bruts, en produisant des événements structurés à traiter par les étapes suivantes. Comme indiqué dans la documentation de NVIDIA, la règle EARLY-stage HandleXidBurstEvents lit les preuves liées aux séquences XID, décode les mots d’erreur et émet un événement d’attribution pour un problème d’intégrité du signal à node-02.. Au cours de cette étape, les trois événements NCCL restent inchangés.

Le framework transforme ensuite ces événements en symptômes par nœud et effectue un nettoyage par nœud. Dans l’exemple fourni, la règle Xid149AndNvlinkFiltering conserve le symptôme d’intégrité du signal et dégrade le statut des autres symptômes de nœud. La règle Gb200PriorityRootCause réduit davantage l’ensemble des symptômes actifs au niveau de tout le job. Enfin, la cartographie des résultats produit l’attribution de la panne matérielle.

Il est essentiel que le système conserve les rapports NCCL en tant que preuves « intéressantes ». Bien qu’ils soient dégradés pour soutenir le diagnostic principal, leurs sources originales sont préservées afin de pouvoir être examinées. Cette approche garantit que le diagnostic reflète l’ensemble de la situation : la cause racine est la panne matérielle à node-02, tandis que les erreurs NCCL sont conservées en tant que symptômes complémentaires expliquant la nature distribuée de la panne.

Gestion de l’incertitude et de la qualité

Lorsque plusieurs causes correspondent aux preuves, le sous-domaine peut être ambigu. NVIDIA Attribution reflète correctement cette incertitude au lieu de transformer des preuves incomplètes en un diagnostic définitif. La qualité de l’attribution dépend de la qualité et de l’exhaustivité de la télémétrie sous-jacente.

Le système distingue implicitement les contextes de préentraînement et d’affinement en analysant les événements et journaux spécifiques associés à la charge de travail. Cependant, il est important de noter qu’une démonstration de modèle n’est pas une mesure vérifiée de manière indépendante. Le diagnostic enregistre cette distinction, permettant aux équipes de comprendre le niveau de confiance de l’attribution.

Extension de l’attribution à l’infrastructure

Le code source d’NVIDIA Attribution permet aux équipes d’infrastructure d’enregistrer un modèle de défaillance une seule fois et de l’appliquer à diverses charges de travail et clusters. Les développeurs peuvent ajouter des règles pour de nouveaux modes de défaillance et mettre en place des connecteurs pour leurs planificateurs et systèmes de télémétrie. Comme les extensions utilisent les mêmes contrats ExecutionContext, Observation et résultat, les nouvelles intégrations alimentent le même processus de diagnostic.

Le Blueprint d’Attribution est conçu comme une implémentation de référence permettant aux professionnels de personnaliser la solution à leur environnement. Les Blueprints peuvent fonctionner près des sources de données de chaque cluster, soit avec un service d’Attribution dédié à chaque Blueprint, soit avec un service partagé pour plusieurs Blueprints. Il existe une grande flexibilité quant à la manière dont les équipes souhaitent personnaliser leur déploiement, par exemple en choisissant une configuration un-à-un ou un-à-plusieurs.

Conclusion

NVIDIA Attribution offre un cadre solide pour diagnostiquer les défaillances des charges de travail d’IA distribuées, en allant au-delà des événements isolés sur les nœuds pour adopter une analyse axée sur la charge de travail. En corrélant les journaux, les métriques et l’état du planificateur à l’aide de règles déterministes, le système identifie les causes racines telles que les pannes matérielles tout en conservant les symptômes ultérieurs comme preuves.

Les équipes peuvent utiliser le service d’Attribution et les Blueprints pour obtenir une visibilité sur les modèles de défaillance, cibler les réparations nécessaires et améliorer la résilience de leur infrastructure d’IA. Que ce soit pour analyser des erreurs NCCL ou des problèmes d’intégrité du signal NVLink, l’outil propose une approche structurée allant des preuves brutes jusqu’à un diagnostic utile.

Source : https://developer.nvidia.com/blog/diagnose-distributed-ai-workload-failures-with-nvidia-attribution