NVIDIA Attribution : outil open source pour le diagnostic des défaillances de l'IA distribuée

NVIDIA a publié NVIDIA Attribution en tant que projet open source pour aider les ingénieurs à diagnostiquer les défaillances dans les charges de travail d'IA distribuées. Publiée le 2 novembre 2026, cette solution répond à la complexité du débogage des clusters GPU à grande échelle en corrélant des sources de données disparates pour produire un diagnostic unique et structuré. Elle va au-delà du simple signalement d'erreurs pour expliquer pourquoi une charge de travail a échoué.

Ce qui s'est passé

Les tâches d'entraînement distribuées échouent souvent en raison d'erreurs en cascade, où un seul problème matériel ou réseau déclenche des milliers de symptômes en aval. Une défaillance sur un GPU peut se manifester par des délais de communication sur de nombreux autres rangs, rendant difficile la distinction entre la cause racine et le bruit résultant. Les outils de surveillance traditionnels indiquent généralement où la charge de travail s'est arrêtée, mais pas où la défaillance a pris origine, ce qui entraîne des temps d'investigation prolongés.

Pour résoudre ce problème, NVIDIA a ouvert le code de son système interne d'attribution de défaillance centré sur la charge de travail. Cet outil, utilisé en production depuis des années dans l'infrastructure IA de NVIDIA, analyse des millions de charges de travail chaque semaine sur des centaines de milliers de GPU. En corrélant les journaux, les métriques, la télémétrie et l'état du planificateur spécifiques à la charge de travail, il produit un diagnostic reproductible incluant le résultat, la cause racine, les nœuds affectés et une piste de preuves.

La version publiée comprend deux composants déployables principaux : le Service d'Attribution (Attribution Service) et le Blueprint d'Attribution (Attribution Blueprint). Le Service expose le moteur d'attribution central via une API REST, tandis que le Blueprint agit comme un orchestrateur de référence en Python. Le Blueprint connecte les planificateurs de cluster et les sources de télémétrie au Service, permettant aux équipes d'intégrer l'outil dans leur infrastructure existante sans reconstruire la logique centrale.

Comment cela fonctionne

Le processus d'attribution suit quatre étapes déterministes pour garantir la reproductibilité. Premièrement, le Blueprint délimite la portée de la charge de travail en identifiant la tentative spécifique à l'aide d'identifiants du planificateur ou de fenêtres d'exécution. Deuxièmement, il collecte des observations provenant de divers connecteurs, y compris les journaux d'application, les syslog, les messages du pilote GPU et les métriques réseau. Ces entrées sont normalisées en enregistrements d'observation structurés.

Ensuite, le Service extrait et corrèle les événements à l'aide d'un moteur de règles. Il identifie les événements significatifs tels que les XIDs GPU, les échecs NCCL et les transitions du planificateur. Des règles déterministes évaluent la chronologie et l'interaction de ces événements pour séparer les symptômes en aval de la cause principale. Par exemple, si un GPU signale un problème d'intégrité du signal et que d'autres rangs signalent des erreurs de communication, le système identifie la défaillance matérielle comme cause racine et les erreurs de communication comme symptômes secondaires.

Enfin, le système renvoie un résultat structuré contenant l'état terminal, le domaine attribué et les nœuds affectés. La sortie distingue les causes racines définitives des situations ambiguës où les preuves sont incomplètes. Ce format structuré permet aux systèmes en aval, tels que la gestion des incidents ou les outils de récupération automatisés, de consommer le diagnostic sans avoir à analyser des journaux bruts spécifiques aux produits.

Détails clés

• Le système fonctionne via deux composants : le Service d'Attribution pour l'analyse et le Blueprint d'Attribution pour l'orchestration et la collecte de données.
• Il prend en charge les connecteurs de contexte d'exécution pour Slurm, Kueue et les entrées statiques, ainsi que les connecteurs de journaux et de métriques pour Loki, les fichiers locaux, les journaux de pods Kubernetes et PromQL.
• En production, le système a identifié des modèles de défaillance de la structure de commutation autour de ports d'hôte et de switch spécifiques en corrélant les erreurs de port et les réinitialisations de connexion.
• Le moteur d'attribution utilise des règles déterministes pour évaluer la chronologie des événements, garantissant que les résultats sont reproductibles et personnalisables pour différents environnements.
• La sortie inclut un indicateur de qualité qui reflète l'incertitude lorsque plusieurs causes correspondent aux preuves, évitant ainsi une fausse confiance dans des diagnostics incomplets.
• Les développeurs peuvent étendre le système en ajoutant de nouvelles règles pour les modes de défaillance ou en implémentant des connecteurs pour des planificateurs et des backends de télémétrie personnalisés.

Pourquoi c'est important

Pour les ingénieurs logiciels et les responsables d'infrastructure ML, la réduction du temps moyen de résolution (MTTR) est cruciale pour maintenir une haute utilisation des ressources GPU coûteuses. Le débogage manuel des défaillances distribuées est long et sujet aux erreurs, nécessitant souvent que des experts passent en revue des gigaoctets de journaux. NVIDIA Attribution automatise cette corrélation, permettant aux équipes de se concentrer sur la correction des problèmes d'infrastructure plutôt que sur leur recherche. En fournissant une piste de preuves claire, il facilite également une meilleure communication entre les équipes logicielles et les opérations matérielles.

La nature open source du projet permet aux organisations d'adapter l'outil à leur stack spécifique. Puisque la logique centrale est séparée de la couche d'intégration, les équipes peuvent appliquer les mêmes règles d'attribution sur différents clusters tout en personnalisant la manière dont les données sont collectées et stockées. Cette flexibilité soutient des environnements divers, allant des petits clusters de recherche aux flottes de production massives, permettant des pratiques cohérentes d'analyse de défaillance au sein d'une organisation.

Ce que vous pouvez faire

• Clonez le dépôt NVIDIA Attribution depuis GitHub pour accéder au code source et aux exemples de charges de travail.
• Suivez le guide de démarrage rapide pour exécuter le workflow d'exemple à l'aide de Docker et du gestionnaire de paquets uv.
• Inspectez les diagnostics générés dans le tableau de bord local pour comprendre comment le système corrèle les événements et identifie les causes racines.
• Consultez la référence de configuration du Blueprint pour connecter vos propres planificateurs et backends de télémétrie, tels que Slurm ou Kubernetes.
• Examinez les règles déclaratives et Python incluses pour apprendre à encoder de nouveaux modèles de défaillance pour votre matériel ou votre stack logiciel spécifique.
• Intégrez le Résultat du Blueprint d'Attribution dans vos systèmes existants de gestion des incidents ou de récupération de flotte pour automatiser les réponses aux défaillances courantes.