Der Diagnoseverlauf in vier Entscheidungen
Das Ziel ist, die erste fehlschlagende Ebene zu finden, nicht mehrere Installationen nacheinander auszuprobieren. Bewahren Sie den ausgeführten Befehl, die erste Fehlermeldung und das Ergebnis jeder Kontrolle auf. Wenn Sie gleichzeitig Python, das PyTorch-Paket und die Batch-Größe ändern, wissen Sie nicht mehr, welche Änderung das Problem gelöst hat.
Das herunterladbare Skript wendet diese Abfolge an und erzeugt einen begrenzten technischen Bericht. Es startet Ihr Modell nicht und verändert Ihre Installation nicht. Verwenden Sie es in derselben Umgebung wie Ihr Projekt, sonst prüfen Sie einen anderen Interpreter als den des gestörten Programms.
Scrollen Sie durch die Tabelle, um alle Spalten zu lesen.| Kontrolle | Wenn die Kontrolle fehlschlägt | Was ihr Gelingen ermöglicht |
|---|---|---|
| 1. Interpreter und Import | Das verwendete Python oder dessen PyTorch-Installation korrigieren. | Version und Backend des tatsächlich importierten Pakets ablesen. |
| 2. Backend und Gerät | Paket, Treiber, GPU-Bereitstellung und Berechtigungen prüfen. | Eine Zuweisung auf der angestrebten GPU anfordern. |
| 3. Kleine GPU-Berechnung | Den Zuweisungs-, Berechnungs- oder Synchronisierungsfehler aufbewahren. | Zu einer reduzierten Eingabe der Anwendung übergehen. |
| 4. Repräsentative Anwendung | Gewichte, Erweiterung, Format, Speicher oder fehlerhafte Ausgabe isolieren. | Die tatsächliche Arbeit schrittweise erhöhen. |
1. Das tatsächlich ausgeführte Python identifizieren
Ein Terminal, ein Notebook und ein Dienst können unterschiedliche Interpreter verwenden. Zeigen Sie sys.executable im Kontext an, der das Projekt startet, und prüfen Sie dann die Version. Der Pfad hilft, eine vergessene virtuelle Umgebung oder ein Notebook auf einem anderen Kernel zu erkennen. Prüfen Sie ihn auf Ihrer Maschine; es ist nicht nötig, Ihre persönliche Verzeichnisstruktur in einem Bericht zu veröffentlichen.
Verwenden Sie anschließend denselben Interpreter, um die Pakete abzufragen. Der Befehl python -m pip show torch liefert die Informationen zu dem PyTorch, das mit diesem Python verknüpft ist. Wenn import torch fehlschlägt, besteht der nächste Schritt darin, diese Installation zu korrigieren: Die Batch-Größe zu reduzieren oder die Gewichte des Modells zu ändern, löst kein fehlendes Modul.
python -c "import sys; print(sys.executable); print(sys.version)"
python -m pip show torch2. CUDA, ROCm und ein Paket ohne GPU-Beschleunigung unterscheiden
Erfassen Sie torch.__version__, torch.version.cuda und torch.version.hip getrennt. Schließen Sie nicht allein aus dem Wert None von torch.version.cuda auf ein „CPU-Paket“: PyTorch für ROCm verwendet HIP, nutzt torch.cuda weiter und erwartet ebenfalls ein Gerät namens cuda. Diesen Namen durch rocm oder hip zu ersetzen, ist nicht die anzuwendende Korrektur.
Prüfen Sie anschließend torch.cuda.is_available() und torch.cuda.device_count(). Diese Ergebnisse beschreiben, was diese Python-Umgebung zu diesem Zeitpunkt nutzen kann. Sie ersetzen nicht die minimale Berechnung. Ein Systemwerkzeug kann eine Karte sehen, während das Paket, der für den Prozess zugängliche Treiber oder dessen Umgebung PyTorch daran hindern, sie zu verwenden.
python -c "import torch; print(torch.__version__); print(torch.version.cuda); print(torch.version.hip); print(torch.cuda.is_available()); print(torch.cuda.device_count())"3. Bericht mit dem Kernodeck-Skript erstellen
Legen Sie die heruntergeladene Datei nach dem Download in einen Arbeitsordner und starten Sie sie mit dem Python des Projekts. Standardmäßig verlangt es eine GPU. Der CPU-Modus muss ausdrücklich angefordert werden: Sein Erfolg überprüft den CPU-Zweig der Diagnose und verwandelt niemals eine nicht verfügbare GPU in eine bestätigte GPU. Der Bericht wird im Terminal und mit --output in eine neue JSON-Datei geschrieben. Eine vorhandene Datei wird nie überschrieben: Wählen Sie für Ihren nächsten Versuch einen anderen Namen.
Das Skript allokiert zwei 2 × 2-Matrizen in float32, prüft ihr Produkt, dann einen Gradienten, und synchronisiert das GPU-Gerät. Der erwartete Verlust beträgt 196 für diese feste Berechnung. Diese sehr kurze Prüfung lädt keine Modellgewichte und misst keinen Durchsatz. Sie verlangt vom Backend eine kleine echte Berechnung, die über eine bloße Geräteerkennung hinausgeht.
Die optionale Systemprüfung verwendet nvidia-smi, sofern vorhanden. Sie meldet ausschließlich die Version des NVIDIA-Treibers und den für dieses Werkzeug sichtbaren Gesamtspeicher; sie ist keine gleichwertige Systemprüfung für ROCm. Das Zeitlimit der Berechnung beträgt standardmäßig 30 Sekunden und kann zwischen 5 und 120 Sekunden liegen. Die Systemprüfung hat ihr eigenes maximales Zeitlimit von 3 Sekunden.
python kernodeck-diagnostic-v1.py --device-index 0 --timeout 30 --output diagnostic-gpu.jsonpython kernodeck-diagnostic-v1.py --device cpu --output diagnostic-cpu.jsonpython kernodeck-diagnostic-v1.py --host-check --output diagnostic-gpu-systeme.json4. Bericht lesen und den nächsten Schritt wählen
Beginnen Sie mit status, code, exit_code und stage. Der Block runtime identifiziert die Python-Version und die Systemfamilie. Der Block pytorch unterscheidet das importierte Paket, seine CUDA/HIP-Kompilierungsversionen, das deklarierte Backend und die sichtbaren Geräte. Der Block execution gibt an, wo die Berechnung tatsächlich stattgefunden hat und ob das Produkt sowie der Gradient überprüft wurden.
Im CPU-Modus bleiben gpu_available und visible_device_count auf null: Das Skript fragt den Status des GPU-Treibers nicht ab. Das ist weder eine Null noch eine Störung. Lesen Sie auch execution.device: Ein für CUDA kompiliertes Paket kann diese Prüfung durchaus auf der CPU ausführen, wenn dies ausdrücklich verlangt wird.
Der Bericht enthält eine Auswahl technischer Daten. Er umfasst keine Umgebungsvariablen, keine Pfade des Rechners, keine Sitzungskennungen, keine vollständige Paketliste und keinen rohen Ausnahme-Stacktrace. Das Skript sendet keinen Bericht an Kernodeck. Bewahren Sie für einen detaillierten Fehler Ihrer Anwendung deren Stacktrace in Ihrem Arbeitsbereich auf und entfernen Sie Geheimnisse, bevor Sie ihn teilen.
Scrollen Sie durch die Tabelle, um alle Spalten zu lesen.| Ergebnis | Bedeutung | Nächste Aktion |
|---|---|---|
| GPU_CHECK_PASSED · 0 | Produkt und Gradient auf der gewählten GPU überprüft. | Mit einer kleinen Eingabe Ihrer Anwendung fortfahren. |
| CPU_CHECK_PASSED · 0 | Produkt und Gradient nur auf der CPU überprüft. | Keine Schlussfolgerung zu CUDA oder ROCm ziehen. |
| TORCH_MISSING · 3 / TORCH_IMPORT_FAILED · 4 | PyTorch fehlt in diesem Python, oder der Import schlägt fehl. | Interpreter, Paket und dessen Abhängigkeiten überprüfen. |
| GPU_BACKEND_ABSENT · 5 | Das Paket deklariert weder CUDA noch HIP. | Das zu Ihrer Umgebung passende Paket installieren. |
| GPU_UNAVAILABLE · 6 / DEVICE_INDEX_INVALID · 7 | GPU in diesem Prozess nicht nutzbar, oder Index außerhalb der sichtbaren Geräte. | Bereitstellung der Karten, Treiber und angeforderten Index überprüfen. |
| CHECK_FAILED · 8 / OUT_OF_MEMORY oder RUNTIME_ERROR · 9 | Fehler bei der festen Berechnung, der Allokation oder einer Backend-Operation. | Die gemeldete Stufe lesen, bevor das vollständige Modell gestartet wird. |
| TIMEOUT · 10 / WORKER_FAILED · 11 | Prüfung durch das Zeitlimit abgebrochen, oder kein verwertbarer Bericht. | Den Kontrolllauf als Fehler behandeln; die Umgebung untersuchen. |
| OUTPUT_WRITE_FAILED · 12 | Der Bericht wurde nicht am angegebenen Zielort gespeichert. | Verwenden Sie einen neuen, zugänglichen Dateinamen. |
5. Von der kleinen Berechnung zu Ihrer Anwendung
Halten Sie vor dem Start einen reproduzierbaren Befehl, ein identifiziertes Modell, einen kleinen Datensatz und ein zugängliches Ausgabeverzeichnis bereit. Wählen Sie eine Eingabe, die die wichtigen Merkmale der endgültigen Arbeit bewahrt: Textlänge, Bildabmessungen, Audioformat oder Pflichtfelder. Eine künstlich kurze Eingabe kann das Problem verdecken, das Sie beobachten möchten.
Formulieren Sie ein konkretes Erfolgskriterium. Bei einer Embedding-Berechnung muss jede Eingabe-ID einen Vektor der erwarteten Dimension mit endlichen Werten liefern. Beim Training muss ein Schritt einen verwertbaren Loss erzeugen, die vorgesehenen Parameter aktualisieren und eine Speicherung ermöglichen. Der Exit-Code des Prozesses ergänzt diese Kontrollen; er ersetzt sie nicht.
Fügen Sie Markierungen vor und nach dem Lesen der Parameter, dem Import der Bibliotheken, dem Laden der Gewichte, der Vorbereitung der Daten, deren Übertragung, der Berechnung und dem Schreiben hinzu. Geben Sie jedem Versuch eine Kennung und bewahren Sie die zugehörigen Parameter auf. Eine Meldung „Modell geladen“ muss einem abgeschlossenen Ereignis entsprechen, nicht bloß einer Ladeabsicht.
Protokollieren Sie Formen, Typen und Geräte der relevanten Tensoren, ohne den gesamten Datensatz zu kopieren. Eine Zusammenfassung wie „Eingabe: 8 Sequenzen, maximale Länge 512, Gerät cuda:0“ hilft, zwei Versuche zu vergleichen. Diese Zahlen beschreiben hier ein Beispielprotokoll, keine allgemeingültige Konfiguration. Vermeiden Sie es, Zugriffstoken oder sensible Eingabeinhalte in diese Meldungen aufzunehmen.
6. Den Fehler in der richtigen Schicht beheben
Wenn die kleine Berechnung läuft, aber die Gewichte nicht auffindbar sind, prüfen Sie deren Pfad, Format und Zugriffsrechte. Wenn eine Erweiterung beim Import fehlschlägt, prüfen Sie ihre Kompatibilität mit dem PyTorch-Paket und dem Backend des Projekts. Eine erfolgreiche Diagnose qualifiziert nicht alle Erweiterungen der Anwendung. Nehmen Sie den ersten Schritt wieder auf, der fehlschlägt, statt mehrere Abhängigkeiten gleichzeitig zu ändern.
Ein Gerätefehler kann von einer Eingabe stammen, die auf der CPU geblieben ist, während das Modell auf der GPU liegt. Ein Typfehler kann von einer teilweisen Konvertierung oder einem mit der gewählten Präzision inkompatiblen Operator stammen. Bewahren Sie die erste vollständige Meldung und ihren Stacktrace auf. Ändern Sie jeweils nur eine Annahme und starten Sie dann die minimale Eingabe erneut, bevor Sie den endgültigen Umfang wieder einführen.
7. Wenn das Modell startet und dann den Speicher überschreitet
Stellen Sie fest, ob die Überschreitung beim Laden der Gewichte, bei der ersten Berechnung oder nach mehreren Iterationen auftritt. Diese Zeitpunkte deuten auf unterschiedliche Ursachen hin: zu großes Modell, umfangreiche Aktivierungen oder Generierungscache, Anhäufung beibehaltener Tensoren. Erfassen Sie torch.cuda.memory_allocated() und torch.cuda.memory_reserved() an denselben Stellen. Ersteres folgt den Allokationen der Tensoren; Letzteres umfasst den vom Allocator verwalteten Speicher.
torch.cuda.empty_cache() kann ungenutzten Cache freigeben, entfernt aber keine Tensoren, auf die noch verwiesen wird. Untersuchen Sie daher die Ausgabelisten, die Loss-Verläufe und die Objekte, die einen Berechnungsgraphen behalten. Verringern Sie anschließend die Batch-Größe oder die Eingabelänge, um den entscheidenden Faktor zu isolieren. Der Wechsel der Karte wird zu einer fundierten Entscheidung, wenn Sie die Phase kennen, die den Speicher überschreitet, und den tatsächlich benötigten Spielraum.
8. Die Berechnung messen, ohne die Asynchronität zu vergessen
GPU-Operationen können relativ zum Python-Programm asynchron sein. Eine um einen Aufruf gelegte Zeitmessung kann daher vor allem das Absenden der Arbeit messen. Für eine Diagnosemessung synchronisieren Sie die GPU an den Grenzen des beobachteten Abschnitts oder verwenden Sie geeignete Events. Diese Synchronisierung verändert den Ablauf: Halten Sie diese Instrumentierung getrennt vom normalen Betrieb Ihrer Anwendung.
Erstellen Sie ein einfaches Beispiel mit drei Segmenten: Vorbereitung der Eingabe, Berechnung, Schreiben der Ausgabe. Rufen Sie für das GPU-Segment torch.cuda.synchronize() auf, erfassen Sie time.perf_counter(), führen Sie die Berechnung aus, synchronisieren Sie erneut und berechnen Sie dann die Differenz. Behalten Sie den ersten Durchlauf und die folgenden getrennt. Ein Laden oder eine Initialisierung darf nicht in einem Mittelwert verschwinden, der als vollständige Antwortzeit dargestellt wird.
9. Ausgaben kontrollieren und eine wiederverwendbare Diagnose behalten
Für eine klassische Inferenz regelt model.eval() das Verhalten der betroffenen Module, während torch.inference_mode() die für Gradienten notwendige Verfolgung deaktiviert. Diese beiden Einstellungen haben unterschiedliche Funktionen. Verwenden Sie die zweite, wenn die erzeugten Tensoren anschließend nicht an einer Berechnung mit Gradienten teilnehmen sollen. Eine Modellbewertung während des Trainings erfordert, vor der Fortsetzung explizit wieder den richtigen Modus zu setzen.
Vergleichen Sie nun die Ausgaben mit dem vorbereiteten Vertrag: Anzahl der Ergebnisse, Übereinstimmung der Identifikatoren, Dimensionen, endliche Werte und geeignete Fachmetrik. Wenn Sie den Batch erhöhen, prüfen Sie diese Übereinstimmung erneut. Wenn Sie GPUs hinzufügen, kontrollieren Sie die Verteilung der Eingaben und die Erfassung der Ausgaben. Mietlose bezeichnen bestellte Karten; Batch bezeichnet Beispiele, die Ihr Programm gemeinsam verarbeitet.
Das Ergebnis dieser Methode ist ein kleines Dossier: Befehl, Versionen, Parameter, minimale Eingabe, letzter erfolgreicher Schritt, erster Fehler, Beobachtungen zum Speicher und erzielte Ausgabe. Wenn der Start funktioniert, behalten Sie dieses Dossier als Vergleichspunkt, bevor Sie die Last erhöhen. Wenn der Start fehlschlägt, ermöglicht es, das Problem zu reproduzieren, ohne die gesamte Untersuchung von vorn zu beginnen.
Führen Sie vor einer langen Verarbeitung außerdem einen sauberen Abbruch und eine Wiederaufnahme mit diesem kleinen Eingabesatz durch. Prüfen Sie, dass bereits geschriebene Ausgaben weder verloren gehen noch doppelt gezählt werden. Sobald diese Kontrollen bestanden sind, erhöhen Sie schrittweise eine einzige Achse – Batch, Länge, Nebenläufigkeit oder Anzahl der Prozesse – und halten Sie die beobachtete Grenze fest. So erhalten Sie einen gemessenen Betriebsbereich für Ihre Anwendung statt einer Vermutung aufgrund des GPU-Namens.
Der erbrachte Nachweis und seine Grenzen
Die herunterladbaren Beispiele stammen aus realen Kontrollen vom 24. September 2026. Die beiden Ausführungen mit PyTorch verwenden Windows, Python 3.14.6 und PyTorch 2.11.0+cu128. Die GPU-Kontrolle nutzt CUDA auf einer NVIDIA GeForce RTX 5070; die CPU-Kontrolle verlangt explizit die CPU. Diese Kontrollhardware wird nicht als Kernodeck-Angebot dargestellt. Für diesen Nachweis wurde keine ROCm-Berechnung ausgeführt.
Eine erfolgreiche kleine Berechnung zeigt, dass ein Pfad für Allokation und Berechnung auf dem gewählten Gerät funktioniert. Sie misst weder die Geschwindigkeit Ihres Modells noch den für seine größten Eingaben benötigten Speicher noch seine Kompatibilität mit einer bestimmten Erweiterung. Der Bericht zertifiziert auch keine Multikarten-Topologie. Gehen Sie zum repräsentativen Test über, bevor Sie entscheiden, die Last oder die Miete zu erhöhen.
Vergleichen Sie für eine CUDA-Anwendung ein NVIDIA-Datenblatt mit Ihrem Speicher- und Bibliotheksbedarf; prüfen Sie für eine ROCm-Kette die Bedingungen des MI300X. Die verlinkten Datenblätter sind Optionen, die für Ihr Projekt zu qualifizieren sind, nicht die Liste der im Nachweis verwendeten Hardware. Rechnen Sie die anfängliche Kontroll- und Exportzeit in Ihre Periode von 3, 7 oder 30 Tagen ein.
Scrollen Sie durch die Tabelle, um alle Spalten zu lesen.| Reale Kontrolle | Beobachtetes Ergebnis | Umfang |
|---|---|---|
| Explizite CPU · Python 3.14.6 / PyTorch 2.11.0+cu128 | CPU_CHECK_PASSED; Produkt und Gradient exakt; Verlust 196. | Die feste Berechnung funktioniert auf CPU. |
| CUDA · RTX 5070 / CUDA-Paket 12.8 | GPU_CHECK_PASSED; Produkt und Gradient exakt; Verlust 196. | Die feste Berechnung funktioniert auf dieser Karte in dieser Umgebung. |
| PyTorch nicht vorhanden · Python 3.12.14 | TORCH_MISSING; Exit-Code 3. | Das Fehlen des Moduls führt zu einem expliziten Fehlschlag. |
| GPU für den Kontrollprozess unsichtbar gemacht | GPU_UNAVAILABLE; Exit-Code 6. | Das Skript ersetzt die GPU nicht stillschweigend durch die CPU. |