NVIDIA stellt gds-diag zur GPUDirect-Storage-Diagnose vor; optionaler Agenten-Skill erläutert ohne automatische Reparatur
NVIDIA stellte am 30. Oktober 2026 gds-diag vor, ein quelloffenes Diagnosewerkzeug des GPUDirect-Storage-Teams. GPUDirect Storage (GDS) ist ein Datenpfad zwischen Speicher und GPU, dessen Eignung von Hardware, Software, Dateisystem und Last abhängt. Das neue Werkzeug untersucht die Umgebung, meldet Befunde und schlägt Gegenmaßnahmen vor.
NVIDIA stellte am 30. Oktober 2026 gds-diag vor, ein quelloffenes Diagnosewerkzeug des GPUDirect-Storage-Teams. GPUDirect Storage (GDS) ist ein Datenpfad zwischen Speicher und GPU, dessen Eignung von Hardware, Software, Dateisystem und Last abhängt. Das neue Werkzeug untersucht die Umgebung, meldet Befunde und schlägt Gegenmaßnahmen vor. Es ändert Einstellungen nicht heimlich und beweist auch keinen höheren Anwendungsdurchsatz. Der Beitrag beschreibt ein deterministisches Python-Kommandozeilenwerkzeug und einen optionalen Agenten-Skill, der bei der Wahl und Deutung seiner Befehle hilft.
Das Skript liegt im gds-diag-Verzeichnis des NVIDIA-Magnum-IO-Repositories. Für die Ausführung des Diagnosewerkzeugs selbst sind laut Artikel Linux und Python ab 3.8 nötig; weitere Installationsabhängigkeiten nennt er dafür nicht. Ein tatsächlich einsatzfähiges GPUDirect Storage stellt höhere Anforderungen, etwa eine NVIDIA-GPU der Rechenzentrumsklasse und CUDA Toolkit ab 12.2. Diese Betriebsbedingungen sind nicht mit den Abhängigkeiten des Diagnoseskripts gleichzusetzen. Nutzer können das Repository beziehen, das Verzeichnis öffnen, ./gds-diag.py --help ausführen und die Hilfe eines Unterbefehls lesen. Wir haben das Skript nicht auf einem GPU-System gestartet und behaupten nicht, dass unsere Plattform seine Prüfungen besteht.
Die Unterbefehle sind nach Zweck geordnet. `all /path/to/check` führt eine vollständige Folge von Diagnosen für den gewählten Pfad aus. Vor der Installation zeigt `support-matrix` unterstützte Speicherkombinationen und `pre-install` prüft GPU-Eignung und CUDA. Nach der Installation sucht `post-install` nach GDS und Blockaden, während `config-audit` Konfigurationsdateien und Umgebungsvariablen untersucht. Für spezielle Fälle analysiert `container-check` Umgebungen wie Docker, containerd, Enroot und Kubernetes; `mount-check` untersucht ein bestimmtes Verzeichnis oder einen Mountpunkt. Planung, Installation und Pfad-Fehlersuche stellen unterschiedliche Fragen. Eine allgemeine Prüfung beweist nicht automatisch die Eignung jeder einzelnen Speicherroute.
Meistens gruppiert das Werkzeug seine Ausgabe in Befunde mit Status. FAIL bezeichnet einen harten Blocker, WARN eine mögliche Blockade und INFO eine wichtige Beobachtung. PASS erscheint nur bei verbose-Ausgabe. Jeder Befund enthält eine Erklärung und einen vorgeschlagenen Maßnahmenplan; Administratoren entscheiden über tatsächliche Änderungen. `--json` gibt strukturierte Ergebnisse zum Archivieren oder Auswerten aus. `support-matrix` liefert stattdessen eine Tabelle mit Fußnoten. `--static` zeigt allgemeine Unterstützung, `--live` bezieht die aktuelle Konfiguration ein. Eine grüne Tabellenzelle, eine fehlerfreie Diagnose und ein guter Anwendungsbenchmark sind verschiedene Aussagen und nicht austauschbar.
Der optionale Agenten-Skill befindet sich mit dem Werkzeug im Repository. In einem unterstützten Coding-Assistenten versteht er natürlichsprachige Fragen, wählt passende gds-diag-Unterbefehle, verbindet mehrere Prüfschritte und erläutert Ergebnisse oder mögliche Lösungen. NVIDIA nennt Tests mit Claude und Codex; daraus folgt keine Kompatibilität mit jedem anderen Assistenten. Die eigentlichen reproduzierbaren Diagnosen führt weiterhin die CLI aus. Im Beispiel fragt ein Nutzer nach GDS in einem Container, worauf der Skill geeignete Prüfungen auswählt. Ein Agent kann nach Besprechung eines Befunds Änderungen vorschlagen, doch das Diagnosewerkzeug setzt die Maßnahmen nicht selbst um. Änderungen an Produktionsspeicher müssen von Menschen geprüft werden.
Der praktische Wert liegt in einem stufenweisen Vorgehen: Ist die Hardware geeignet, ist GDS installiert, was bedeuten Einstellungen, und kann ein bestimmter Mountpunkt oder Container den Datenpfad verwenden? Strukturierte Befunde lassen sich auch zwischen Maschinen vergleichen. Der Beitrag enthält keinen Leistungsbenchmark des Werkzeugs und verspricht keine automatische Reparatur. Die mit dem Artikel gesicherte Repository-Seite liefert Kontext zu Skript und Skill, während der Beitrag vom 30. Oktober Datum und Vorgehen belegt. Eine empfohlene Maßnahme sollte erst nach Prüfung auf der eigenen Plattform und mit der eigenen Last als sicher oder wirksam gelten.
Sources
FAQ
Wie wählt ein neuer Nutzer die gds-diag-Unterbefehle aus?
Unter Linux das Magnum-IO-Repository beziehen, im gds-diag-Verzeichnis ./gds-diag.py --help lesen und Unterbefehle prüfen. Vor der Installation eignen sich support-matrix und pre-install, danach post-install und config-audit. Für Container und Mountpunkte dienen container-check und mount-check. all /path/to/check führt eine komplette Abfolge für einen bestimmten Pfad aus. Die Hilfe des gewählten Unterbefehls erläutert Optionen.
Wie unterscheiden sich Statuslabels und die Ausgabe von support-matrix?
FAIL ist ein harter Blocker, WARN ein möglicher und INFO eine Beobachtung; PASS erscheint nur mit verbose. Befunde enthalten Erklärung und Maßnahmenvorschlag, --json liefert strukturierte Daten. support-matrix zeigt eine Tabelle mit Fußnoten; --static nennt allgemeine Unterstützung, --live berücksichtigt die aktuelle Konfiguration. Ein grünes Feld belegt keinen Anwendungsbenchmark.
Repariert der Agenten-Skill automatisch und welche Voraussetzungen gelten für Skript und GDS-Betrieb?
Nein. Der optionale Skill wählt CLI-Prüfungen und erklärt Befunde; die deterministische CLI diagnostiziert, setzt Maßnahmen aber nicht automatisch um. Das Skript selbst benötigt Linux und Python ab 3.8. Für GDS-Betrieb braucht man gesondert eine NVIDIA-GPU der Rechenzentrumsklasse und CUDA Toolkit ab 12.2. NVIDIA nennt Tests mit Claude und Codex, nicht mit allen Assistenten.