NVIDIA présente gds-diag pour diagnostiquer GPUDirect Storage ; l’agent facultatif explique sans corriger automatiquement

Published 2026-10-30 · AI Daily — AI-assisted deep research, methodology & disclosure

Un article NVIDIA du 30 octobre 2026 présente gds-diag, un utilitaire de diagnostic ouvert conçu par son équipe GPUDirect Storage. GPUDirect Storage (GDS) crée un chemin de données entre stockage et GPU dont l'adéquation dépend du matériel, des logiciels, du système de fichiers et de la charge. Le nouvel outil inspecte un environnement, classe ses constatations et suggère des mesures. Il ne modifie pas silencieusement la configuration GDS et ne prouve pas qu'une application a gagné en débit. Le billet décrit un outil déterministe en ligne de commande Python et une compétence d'agent facultative pour choisir et interpréter les contrôles.

Le script est distribué dans le répertoire gds-diag du dépôt NVIDIA Magnum IO. L'exécution de ce script de diagnostic lui-même demande Linux et Python 3.8 ou plus, sans autre dépendance d'installation indiquée pour l'outil. En revanche, un déploiement GDS opérationnel a des conditions plus fortes, notamment un GPU NVIDIA de classe centre de données et CUDA Toolkit 12.2 ou ultérieur. Ces conditions du déploiement ne sont pas les dépendances du simple script. L'utilisateur peut cloner le dépôt, entrer dans le répertoire, exécuter ./gds-diag.py --help et consulter l'aide d'une sous-commande avant de lancer un contrôle. Nous n'avons pas exécuté le script sur un système GPU et ne prétendons pas que notre plateforme réussit ces tests.

Les sous-commandes répondent à des questions différentes. `all /path/to/check` enchaîne les diagnostics pour un chemin choisi. Avant l'installation, `support-matrix` présente les combinaisons de stockage prises en charge et `pre-install` vérifie notamment le GPU et CUDA. Après l'installation, `post-install` examine l'état de GDS et les blocages, tandis que `config-audit` vérifie fichiers de configuration et variables d'environnement. Pour une enquête ciblée, `container-check` étudie Docker, containerd, Enroot ou Kubernetes, et `mount-check` regarde un répertoire ou point de montage précis. Planifier, installer et dépanner un chemin sont des étapes différentes ; un contrôle général réussi ne répond pas forcément à une question propre à chaque montage.

La plupart des résultats sont organisés en constatations avec des étiquettes. FAIL signifie un blocage dur, WARN un blocage possible et INFO une observation notable ; PASS n'apparaît qu'en mode verbose. Chaque constatation contient une explication et un plan de correction proposé, que l'administrateur peut décider d'appliquer ou non. L'option `--json` fournit une sortie structurée à archiver ou analyser. `support-matrix` produit plutôt un tableau avec notes : `--static` montre la prise en charge générale et `--live` ajoute la configuration courante. Une case verte du tableau, l'absence d'erreur de diagnostic et un benchmark d'application réussi ne sont pas des preuves équivalentes.

La compétence d'agent facultative est fournie dans le même dépôt. Dans un assistant de programmation compatible, elle comprend une demande en langage naturel, choisit des sous-commandes gds-diag, coordonne plusieurs contrôles et explique les résultats ou propose des remèdes. NVIDIA affirme l'avoir validée avec Claude et Codex, sans établir une compatibilité avec tous les assistants. La source déterministe des diagnostics reste le CLI. Un exemple interroge la prise en charge de GDS dans un conteneur et montre comment sélectionner les vérifications. Un agent peut suggérer une modification, mais l'outil de diagnostic n'applique pas lui-même les mesures. Une personne doit examiner tout changement avant son application au stockage de production.

L'intérêt opérationnel est une démarche progressive : déterminer l'éligibilité du matériel, l'installation de GDS, le sens d'un fichier de configuration et la possibilité d'utiliser le chemin depuis un montage ou un conteneur précis. Les constatations structurées peuvent également être comparées entre machines. Le billet ne donne pas de benchmark de performance de l'outil et ne promet aucune réparation automatique. La page du dépôt conservée avec l'article apporte le contexte du script et de la compétence ; le billet du 30 octobre établit la date et la procédure décrite. Chacun doit vérifier ses propres plateformes et charges avant de traiter une recommandation comme une intervention sûre.

Sources

FAQ

Comment choisir les sous-commandes gds-diag lors d’une première utilisation ?

Sous Linux, récupérez le dépôt Magnum IO, ouvrez gds-diag et consultez ./gds-diag.py --help. Avant l'installation, choisissez support-matrix et pre-install ; après, post-install et config-audit. container-check et mount-check répondent à des questions propres aux conteneurs et montages. all /path/to/check enchaîne les contrôles d'un chemin. Lisez aussi l'aide de chaque sous-commande.

Comment interpréter les états et la sortie de support-matrix ?

FAIL est un obstacle ferme, WARN un obstacle possible et INFO une observation ; PASS n'apparaît qu'en mode verbose. Les constatations expliquent les problèmes et proposent des mesures ; --json produit une sortie structurée. support-matrix fournit un tableau annoté, --static montrant le support général et --live la configuration courante. Une case verte ne prouve pas les performances de l'application.

La compétence d’agent corrige-t-elle automatiquement, et quelles sont les conditions du script et de GDS ?

Non. La compétence facultative choisit les contrôles CLI et explique les résultats ; le CLI effectue les diagnostics déterministes sans appliquer les remèdes. Le script demande Linux et Python 3.8 ou plus. Le fonctionnement réel de GDS nécessite séparément un GPU NVIDIA de classe centre de données et CUDA Toolkit 12.2 ou plus. NVIDIA ne cite des validations qu'avec Claude et Codex.