Un nouvel ensemble d’outils permet désormais de décortiquer les défaillances complexes qui surviennent dans les charges de travail d’intelligence artificielle distribuées. NVIDIA Attribution, annoncé via des exemples de démarrage sur github.com, est conçu pour corréler les logs applicatifs, les métriques et les états de planificateur afin de fournir un diagnostic structuré sur l’origine d’une panne. Si une erreur de GPU peut déclencher une cascade de messages sur d’autres nœuds, cet outil vise à identifier le point de départ réel du dysfonctionnement.

Le système se déploie en deux parties : le Service NVIDIA Attribution et le Blueprint Attribution. Le Service expose la logique d’attribution via une interface REST, tandis que le Blueprint est chargé de collecter le contexte de la charge de travail et les observations depuis l’infrastructure, puis de renvoyer le verdict structuré. En substance, il passe de l’événement isolé à la compréhension globale du travail effectué.

Le processus suit un chemin bien défini. D’abord, le Blueprint délimite la charge de travail concernée. Ensuite, il agrège les observations – qu’il s’agisse de lignes de journal, de données Prometheus ou d’événements de fournisseur cloud. C’est au Service que l’attribution commence : il utilise un moteur de règles déterministes pour extraire et corréler ces événements. Il distingue, par exemple, un symptôme stable d’un simple bruit de fond.

L’un des mécanismes clés réside dans les règles d’extracteur. Ces règles initiales analysent les données brutes et produisent des événements structurés. Si, par exemple, un log applicatif indique un échec de sauvegarde de checkpoint dû à « Permission denied », l’extracteur peut générer un événement de type bad-node avec le symptôme correspondant. Les étapes suivantes ne font qu’affiner ce diagnostic, en combinant ce symptôme avec d’autres preuves.

Il est intéressant de noter que ce processus respecte une chaîne de provenance complète. Les informations qui soutiennent le verdict final sont conservées, permettant d’inspecter pourquoi certains événements, comme des erreurs NCCL sur différents nœuds, sont classés comme de simples « symptômes intéressants » plutôt que comme la cause racine.

Comment les règles sont-elles implémentées

L’élaboration de règles n’est pas un exercice ponctuel. Selon la documentation, pour ajouter une nouvelle règle d’extracteur, il faut modifier le catalogue de règles intégré et livrer cette modification avec le Service d’Attribution. Il ne s’agit pas d’une fonctionnalité téléchargeable en direct via une API. Le moteur est structuré en plusieurs phases : les extracteurs reconnaissent l’évidence, les filtres corrèlent ou suppriment les événements, et les affineurs ajustent l’état avant et après la sélection du résultat final.

Ce workflow permet d’adapter le système à des signatures d’erreurs inédites. Si une nouvelle version de pilote signale un défaut avec une signature de log jamais vue, on doit étendre le catalogue d’extracteur. Il faut cependant faire attention, car si l’évidence n’atteint pas le Service, le problème pourrait être au niveau du connecteur qui collecte les données.

Mise en œuvre pratique

Pour faire tourner un exemple, les instructions de démarrage prévoient l’utilisation de Docker pour lancer le service et l’interface web en parallèle. L’utilisateur clone le dépôt, définit les variables d’environnement spécifiques pour les ports et les chemins de base de données, puis utilise docker build pour compiler l’image. Une fois le service en cours d’exécution, la commande uv run lance l’attribution sur un jeu de données statique, utilisant les configurations prévues.

En suivant cette procédure, on peut observer les résultats finaux via l’interface web accessible sur http://127.0.0.1:8080. Ce mécanisme de test permet de vérifier que le pipeline complet, de la collecte des observations à l’attribution finale, fonctionne correctement. Ce type de granularité est ce qui permet de distinguer une défaillance matérielle pure d’une simple erreur de communication résiduelle.

Sources

• attribution/blueprint/docs/quickstart.md at main · dsx-ai-factory/attribution, github.com
• attribution/service/attribution-lib/docs/adding-a-rule.md at main · dsx-ai-factory/attribution, github.com
• Diagnose Distributed AI Workload Failures with NVIDIA Attribution, NVIDIA, 2 novembre 2026
• Netflix Treats GPU Reliability as a Distributed Systems Problem, InfoQ, 30 octobre 2026