In diesem Leitfaden wird beschrieben, wie Sie häufige Probleme mit Compute Engine-VMs mit angehängten GPUs diagnostizieren und beheben, einschließlich Hardwarefehler und Leistungsengpässe.
Fehlerbehebung bei GPU-VMs mit NVIDIA DCGM
NVIDIA Data Center GPU Manager (DCGM) ist eine Reihe von Tools zum Verwalten und Überwachen von NVIDIA-Rechenzentrum-GPUs in Clusterumgebungen.
So verwenden Sie DCGM zur Fehlerbehebung in Ihrer GPU-Umgebung:
- Achten Sie darauf, dass Sie den neuesten empfohlenen NVIDIA-Treiber für das GPU-Modell verwenden, das an Ihre VM angehängt ist. Informationen zu Treiberversionen finden Sie unter Empfohlene NVIDIA-Treiberversionen.
- Stellen Sie sicher, dass Sie die aktuelle Version von DCGM installiert haben. Informationen zur Installation der aktuellen Version finden Sie unter DCGM-Installation.
Probleme diagnostizieren
Wenn Sie einen dcgmi-Diagnosebefehl ausführen, enthalten die vom Diagnosetool gemeldeten Probleme die nächsten Schritte, die Sie unternehmen können, um das Problem zu beheben. Das folgende Beispiel zeigt die umsetzbare Ausgabe des Befehls dcgmi diag -r memory -j.
{
........
"category":"Hardware",
"tests":[
{
"name":"GPU Memory",
"results":[
{
"gpu_id":"0",
"info":"GPU 0 Allocated 23376170169
bytes (98.3%)",
"status":"Fail",
""warnings":[
{
"warning":"Pending page
retirements together with a DBE were detected on GPU 0. Drain the GPU and reset it or reboot the node to resolve this issue.",
"error_id":83,
"error_category":10,
"error_severity":6
}
]
}
.........
Im obigen Auszug sehen Sie, dass für GPU 0 ausstehende Seitenentfernungen aufgrund eines nicht behebaren Fehlers vorliegen. Die Ausgabe enthält die eindeutige error_id und Tipps zur Fehlerbehebung. Für diese Beispielausgabe empfehlen wir, die GPU zu entladen und die VM neu zu starten. In den meisten Fällen lässt sich das Problem beheben, wenn Sie der Anleitung in diesem Abschnitt der Ausgabe folgen.
Probleme mit der GPU-Leistung bei A3-VMs beheben
Die A3-Maschinenserie ist mit angehängten NVIDIA H200- oder H100-GPUs verfügbar. Diese Serie umfasst die Maschinentypen A3 Ultra (H200), A3 Mega (H100), A3 High (H100) und A3 Edge (H100).
Fehlerhaften Knoten identifizieren
Bei umfangreichen Trainings- oder Benchmark-Jobs in einem GPU-Cluster mit mehreren Knoten kann es vorkommen, dass das System nicht mehr reagiert oder die Leistung schlecht ist. Das liegt oft daran, dass ein oder mehrere Knoten eine schlechte Leistung erbringen und den gesamten Vorgang verlangsamen. In diesem Abschnitt wird beschrieben, wie Sie einen fehlerhaften Knoten oder Hostcomputer identifizieren, indem Sie entweder einen NCCL-Benchmarktest ausführen oder NCCL-Logs analysieren.
NCCL-Benchmarktest ausführen
Um die Gruppe von Knoten zu identifizieren, die den Fehler verursacht, testen Sie systematisch Teilmengen Ihres Clusters mit NCCL-Benchmarks wie all_reduce_perf.
- Um Ihre Knotensets zu identifizieren, gruppieren Sie Ihre Knoten in logischen Sets, z. B. Partitionen in Slurm.
- Erstellen Sie für jeden Knotensatz eine separate Hostdatei mit Hostnamen und der Anzahl der GPUs pro Knoten. Die Anzahl der Slots, die Sie angeben, hängt von der Anzahl der GPUs Ihres A3-VM-Typs ab.
a3-highgpu-8g-VMs haben beispielsweise 8 GPUs. Sie müssen alsoslots=8angeben. - Führen Sie zum Ausführen von Benchmarks die
all_reduce_perf-Benchmark für jeden Knoten einzeln aus.mpirun -x LD_LIBRARY_PATH --hostfile HOSTFILE_NAME -n TOTAL_PROCESSES \ ./build/all_reduce_perf -b 1G -e 8G -f 2 -g NUM_GPUS_PER_NODEErsetzen Sie Folgendes:
HOSTFILE_NAME: Der Name der Hostdatei, die die Liste der Knoten und die Anzahl der GPUs pro Knoten für den Knotensatz enthält.TOTAL_PROCESSES: Die Gesamtzahl der MPI-Prozesse, die auf allen Hosts im Nodeset gestartet werden sollen.NUM_GPUS_PER_NODEist die Anzahl der GPUs pro Knoten. Für alle A3-Maschinentypen ist dieser Wert8.
- Wenn ein Job hängen bleibt oder die Busbandbreite (
busbw) auf einem bestimmten Knotensatz deutlich niedriger ist, ist dieser Satz wahrscheinlich fehlerhaft. - Wenn ein Knotensatz fehlerhaft ist, teilen Sie die zugehörige Hostdatei in zwei Hälften und führen Sie den Test noch einmal aus, um die binäre Suche einzugrenzen, bis Sie den einzelnen fehlerhaften Knoten gefunden haben.
NCCL-Logs analysieren
Wenn mit der Benchmark-Methode kein Knoten ermittelt wird, analysieren Sie detaillierte NCCL-Logs.
- Um das Debug-Logging zu aktivieren, legen Sie die folgenden Umgebungsvariablen in der Shell-Sitzung fest, in der Sie Ihre Arbeitslast ausführen möchten:
export NCCL_DEBUG=INFO export NCCL_DEBUG_SUBSYS=INIT,NET,COLL export NCCL_DEBUG_FILE="LOG_DIRECTORY/nccl_log.%h.%p"Ersetzen Sie
Wenn SieLOG_DIRECTORYdurch das Verzeichnis, in dem Sie Ihre Logs speichern möchten.NCCL_DEBUG_FILEmit%hund%pfestlegen, werden für jeden Prozess eindeutige, nicht verschachtelte Logdateien erstellt.Wenn Sie eine Arbeitslast mit mehreren Knoten mit
mpirunausführen, können Sie diese Variablen mit dem Flag-xan alle Knoten weitergeben. Beispiel:mpirun -x NCCL_DEBUG -x NCCL_DEBUG_SUBSYS -x NCCL_DEBUG_FILE ... - Verwenden Sie den folgenden Befehl, um den ersten Fehler zu finden, d. h. die frühesten Zeitüberschreitungs- oder Fehlerereignisse in allen Logdateien:
grep "NCCL WARN.*NET/FasTrak" LOG_DIRECTORY/* | sed 's/.*NET\/FasTrak\(.*\)/\1/g' \ | sort | head -n 20Ersetzen Sie
LOG_DIRECTORYdurch das Verzeichnis, in dem Ihre Logs gespeichert sind. - Bei der Zählung kollektiver Vorgänge führt ein Straggler-Knoten weniger kollektive Vorgänge aus. Anzahl der Einträge für verdächtige Ränge:
"opCount"grep "opCount" LOG_DIRECTORY/nccl_log.HOSTNAME.PID | wc -lErsetzen Sie Folgendes:
LOG_DIRECTORY: das Verzeichnis, in dem Ihre Logs gespeichert sindHOSTNAME: der Hostname des KnotensPID: die Prozess-ID des NCCL-Prozesses
- Wenn Sie mehr Protokolldaten erfassen möchten, bevor ein Job abgebrochen wird, können Sie das Zeitlimit für die Datenübertragung vorübergehend erhöhen:
export NCCL_FASTRAK_DATA_TRANSFER_TIMEOUT_MS=3600000
GPU-Wärmedrosselung überwachen
Bei VMs der A3-Serie kann es zu Leistungseinbußen kommen, wenn sie unter Last dauerhaft Temperaturen über 87 °C erreichen. Verwenden Sie nvidia-smi oder dcgmi, um die thermische Drosselung der GPU auf allen Knoten in einem Cluster zu prüfen.
nvidia-smi verwenden
Führen Sie den folgenden Befehl aus, um die aktuelle Temperatur und den Drosselungsstatus aller GPUs auf einem Knoten zu prüfen:
nvidia-smi --query-gpu=timestamp,name,pci.bus_id,temperature.gpu,clocks_throttle_reasons.hw_slowdown --format=csv
In der Ausgabe gibt ein Wert von Active in der Spalte clocks_throttle_reasons.hw_slowdown an, dass die GPU aufgrund hoher Temperaturen gedrosselt wird.
dcgmi verwenden
Die NVIDIA Data Center GPU Manager (DCGM) Diagnostic Suite enthält Prüfungen auf thermische Überschreitungen. Führen Sie den folgenden Befehl aus, um eine Diagnose der Stufe 1 auszuführen:
dcgmi diag -r 1
Ein Ergebnis von Warn oder Fail im Abschnitt Thermal weist darauf hin, dass während des Tests ein thermischer Verstoß aufgetreten ist. Wenn eine thermische Überschreitung mit einer Taktfrequenzdrosselung einhergeht, überhitzt die GPU wahrscheinlich und muss weiter untersucht werden.
Xid-Fehler
Nachdem Sie eine VM mit angehängten GPUs erstellt haben, müssen Sie NVIDIA-Gerätetreiber auf Ihren GPU-VMs installieren, damit Ihre Anwendungen auf die GPUs zugreifen können. Manchmal geben diese Treiber jedoch Fehlermeldungen zurück.
Eine Xid-Meldung ist ein Fehlerbericht des NVIDIA-Treibers, der in das Kernel- oder Ereignisprotokoll des Betriebssystems Ihrer Linux-VM geschrieben wird. Diese Nachrichten werden in der Datei /var/log/messages platziert. Weitere Informationen zu Xid-Meldungen, einschließlich möglicher Ursachen, finden Sie in der NVIDIA-Dokumentation.
So geht Google mit Xid-Fehlern um
Google verwendet passive Systemdiagnosen, um GPU-Systeme zu bewerten. Wenn ein Hardwareaustausch erforderlich ist, leitet Google automatisch eine Notfallwartung ein. Google erkennt Xid-Fehler und sendet Geräte proaktiv zur Reparatur, wenn Fehlercodes wie Xid 74, 79 und 140 auf eine hohe Wahrscheinlichkeit eines Hardwarefehlers hinweisen. Bei einigen Xid-Codes, die durch Software- oder Hardwareprobleme verursacht werden können, verwendet Google Mustervergleich, um Reparaturen auszulösen. Daher führt nicht jedes Auftreten zu einer automatischen Reparatur.
Arten von Xid-Fehlern
In der folgenden Liste werden die drei Hauptkategorien von Xid-Fehlern und die empfohlenen Maßnahmen zur Fehlerbehebung beschrieben:
Anwendungsfehler:Diese weisen auf Probleme im Anwendungscode hin. Zu Anwendungsfehlern gehören XIDs wie 13, 31, 94, 95 und 137, die auf verschiedene Arten von Speicherzugriffsverletzungen hinweisen, ähnlich wie bei einem Segmentierungsfehler. Diese weisen nicht auf einen ECC-Fehler hin. Zur Behebung dieser Fehler empfiehlt NVIDIA einen der folgenden Debugging-Ansätze:
- Direktes Debugging:Führen Sie die Anwendung direkt in cuda-gdb aus oder führen Sie das Compute Sanitizer-Memcheck-Tool aus.
- Debugging nach Ausnahme: Führen Sie die Anwendung mit
CUDA_DEVICE_WAITS_ON_EXCEPTION=1aus. Wenn eine Ausnahme auftritt, friert der GPU-Treiber den Anwendungsstatus ein, ohne die Anwendung zu beenden. So können Sie später einen Debugger (cuda-gdb -p <PID>) anhängen, um den Live-Stacktrace zu untersuchen.
Treiberfehler:Diese weisen auf Probleme hin, die durch den NVIDIA-GPU-Treiber verursacht werden. Um diese Fehler zu beheben, müssen Sie die neueste NVIDIA-Treiberversion verwenden. Google behält diese Fehler im Auge und arbeitet mit NVIDIA an der Behebung von Treiberproblemen.
Durch Firmware oder Hardware behebbare Fehler:Diese weisen auf Firmware- oder Hardwarefehler hin, die ohne Hardwareaustausch behoben werden können. Um diese Fehler zu beheben, müssen Sie manuelle Wiederherstellungsmaßnahmen ergreifen, z. B. die GPU zurücksetzen oder die Instanz neu starten. Zu den durch Firmware oder Hardware behebbaren Fehlern gehören ECC-Fehler (Error Correcting Code, Fehlerkorrekturcode) (gilt für XIDs wie XID 48, 63 und 64), die verschiedene Phasen der Erkennung und Behebung von ECC-Fehlern angeben. Weitere Informationen zum Deaktivieren von Seiten und zur Behebung von ECC-Fehlern finden Sie in den häufig gestellten Fragen zur dynamischen Deaktivierung von Seiten von NVIDIA.
Xid-Meldungen prüfen
Wenn Sie schnell herausfinden möchten, warum eine GPU-Arbeitslast fehlgeschlagen ist, nicht mehr reagiert oder die Leistung nachgelassen hat, suchen Sie in den Kernellogs Ihrer Instanz (dmesg oder /var/log/kern.log) nach numerischen NVIDIA-Xid-Fehlercodes.
Die Tabellen mit Xid-Fehlern in den folgenden Unterabschnitten können Ihnen sofort helfen:
- Ursache ermitteln:Stellen Sie fest, ob der Fehler durch einen Anwendungsfehler (z. B. unzulässiger Speicherzugriff), einen Treiberkonflikt oder einen physischen Hardwarefehler (z. B. ECC-Speicherfehler mit zwei Bit) verursacht wird.
- Betriebliche Zuständigkeit ermitteln:Prüfen Sie, welche sofortigen manuellen Maßnahmen zur Fehlerbehebung Sie ergreifen müssen, z. B. GPUs zurücksetzen, VMs neu starten oder Debugger ausführen, und welche automatischen Reparatur- und Hardwareaustauschmaßnahmen Google aktiv auf dem Host verwaltet.
- Die richtigen Wiederherstellungsschritte ausführen:Vermeide unnötige Fehlerbehebungsverfahren und wisse genau, wann eine manuelle Wiederherstellung ausreicht und wann du den Host als fehlerhaft melden musst. Manchmal reicht die manuelle Wiederherstellung nicht aus, z. B. wenn sich die Fehlerquelle im GPU-Cache (SRAM) befindet, der nicht neu zugeordnet werden kann (angegeben durch
Xid 48mitSRAM Threshold Exceeded=Yes), oder wenn die GPU ihren Remap-Bank erschöpft hat (angegeben durchXid 64: All reserved rows for bank are remapped). In diesen Fällen erkennt Google, dass die GPU für einen Hardwareaustausch infrage kommt, und sendet die Maschine proaktiv zur Reparatur. Wenn bei Ihren Arbeitslasten wiederkehrende Fehler auftreten oder Sie wiederholt Speicherfehler feststellen, können Sie den fehlerhaften Host melden, um eine automatische Reparatur oder einen automatischen Austausch zu veranlassen. Informationen zu GKE finden Sie unter Fehlerhafte Hosts in GKE melden.
Xid-Verarbeitung
In den folgenden Abschnitten werden häufige Xid-Fehlermeldungen nach technischer Kategorie gruppiert. Außerdem werden die maßgeblichen Lösungen und Verantwortlichkeiten aufgeführt:
- GPU-Speicherfehler (XIDs
48,63,64,92,94,95) - GSP-Fehler (GPU System Processor) (XIDs
119,120) - Fehler bei illegalem Speicherzugriff (XIDs
13,31,137) - Weitere häufige Xid-Fehlermeldungen (Xids
74,79,109,149)
GPU-Arbeitsspeicherfehler
GPU-Arbeitsspeicher ist der Speicher, der auf einem GPU-Gerät verfügbar ist und zum temporären Speichern von Daten verwendet werden kann. Der GPU-Arbeitsspeicher ist durch den Fehlerkorrekturcode (Error Correction Code, ECC) geschützt, der Single-Bit-Fehler (SBE) erkennt und korrigiert und Double-Bit-Fehler (DBE) erkennt und meldet.
Diese Speicherfehler treten im Laufe der Lebensdauer einer GPU voraussichtlich auf. Vor der Veröffentlichung der NVIDIA A100-GPUs wurde die dynamische Seitendeaktivierung unterstützt. Für NVIDIA A100- und neuere GPU-Releases (z. B. NVIDIA H100) wird die Wiederherstellung nach Zeilenneuzuordnungsfehlern für HBM-Fehler (DRAM) eingeführt. ECC ist standardmäßig aktiviert und Google empfiehlt dringend, ECC aktiviert zu lassen.
In der folgenden Tabelle sind häufige GPU-Arbeitsspeicherfehler und ihre empfohlenen Lösungen aufgeführt:
| Xid-Fehlermeldung | Kundenaktion | Google-Aktion |
|---|---|---|
Xid 48: Double Bit ECC
Ein nicht korrigierbarer Speicherfehler mit zwei Bit wurde von ECC erkannt. Dieser Fehler unterbricht immer die laufende Arbeitslast und generiert die Xid 48. |
|
Google überwacht, wann die GPU für einen Hardwareaustausch infrage kommt, z. B. wenn der HBM-Remap-Bank erschöpft ist oder die GPU den SRAM-Fehlerschwellenwert für die Lebensdauer überschreitet. In diesem Fall wird die Maschine proaktiv zur Reparatur gesendet, um die GPU zu ersetzen. |
Xid 63: ECC page retirement or row remapping recording
event
Gibt an, dass aufgrund eines Speicherfehlers ein Ereignis zum Entfernen einer dynamischen Seite oder zum Neuzuordnen einer Zeile aufgezeichnet wurde. |
|
Google überwacht die Fehlerschwellenwerte und sendet die Maschine zur Reparatur, wenn die GPU physisch repariert oder ausgetauscht werden muss. |
Xid 64: ECC page retirement or row remapper recording
failure
Die Nachricht enthält die folgenden Informationen: Xid 64: All reserved rows for bank are remapped
|
|
Wenn der Remap-Speicher erschöpft ist ( |
Wenn Sie mindestens zwei der folgenden Xid-Meldungen zusammen erhalten:
Die Nachricht enthält die folgenden Informationen: Xid XX: row remap pending
|
|
Google sendet die Maschine zur Reparatur, wenn die Neuzuordnungsbank erschöpft ist oder die GPU physisch repariert oder ersetzt werden muss. |
Xid 92: High single-bit ECC error rate |
Diese Xid-Meldung wird zurückgegeben, nachdem der GPU-Treiber einen korrigierbaren Fehler behoben hat. Sie sollte sich nicht auf Ihre Arbeitslasten auswirken. Diese Xid-Mitteilung dient nur zu Informationszwecken. Sie müssen nichts tun. |
Keine |
Xid 94: Contained error
Gibt an, dass ein GPU-Fehler aufgetreten ist und ob der Fehler auf eine einzelne Anwendung beschränkt war. Allein gibt die Xid 94 nicht die Ursache des Fehlers an. Sie muss zusammen mit anderen gleichzeitig auftretenden Xid-Fehlern interpretiert werden, um die grundlegende Ursache zu ermitteln. |
|
Keine |
Xid 95: Uncontained error
Gibt an, dass ein GPU-Fehler aufgetreten ist, der nicht auf eine einzelne Anwendung beschränkt war. Allein gibt Xid 95 nicht die Ursache des Fehlers an. Es muss zusammen mit anderen gleichzeitig auftretenden Xid-Fehlern interpretiert werden, um die grundlegende Ursache zu ermitteln. |
|
Keine |
Fehler im GSP
Ein GPU-Systemprozessor (GPU System Processor, GSP) ist ein Mikrocontroller, der auf GPUs ausgeführt wird und einige der Hardwareverwaltungsfunktionen auf niedriger Ebene übernimmt.
| Xid-Fehlermeldung | Kundenaktion | Google-Aktion |
|---|---|---|
Xid 119: GSP RPC timeout |
|
Keine. Wenn der Fehler weiterhin auftritt und Sie eine Supportanfrage einreichen, untersucht Google im Rahmen des Supportverfahrens den Hardware- oder Treiberstatus. |
Xid 120: GSP error |
Ungültiger Arbeitsspeicherzugriff-Fehler
Die folgenden Xids werden zurückgegeben, wenn Anwendungen Fehler bei illegalem Arbeitsspeicherzugriff haben:
| Xid-Fehlermeldung | Kundenaktion | Google-Aktion |
|---|---|---|
|
Es wurde ein Verstoß gegen den Speicherzugriff erkannt, analog zu einem Segmentierungsfehler. Diese Fehler deuten in der Regel auf einen Anwendungsfehler hin, bei dem auf GPU-Arbeitsspeicher außerhalb des zulässigen Bereichs oder auf freigegebene Puffer zugegriffen wird, z. B. durch Dereferenzieren eines ungültigen Zeigers oder eines Arrays außerhalb des zulässigen Bereichs. Diese stellen keine ECC-Fehler dar, sofern nicht auch die Xid 48 vorhanden ist. |
Um dieses Problem zu beheben, müssen Sie die Speicherzugriffsfehler in Ihrer Anwendung debuggen. Sie können cuda-gdb, Compute Sanitizer oder cuda-memcheck verwenden. Weitere Informationen finden Sie in der NVIDIA Xid-Dokumentation. |
Keine. In seltenen Fällen, in denen Hardwarefehler fälschlicherweise zu illegalen Speicherzugriffsfehlern führen können, können Sie NVIDIA Data Center GPU Manager (DCGM) verwenden, um |
Weitere häufige Xid-Fehlermeldungen
| Xid-Fehlermeldung | Kundenaktion | Google-Aktion |
|---|---|---|
Xid 74: NVLINK error |
|
Keine |
Xid 79: GPU has fallen off the bus
Das bedeutet, dass der Treiber nicht mit der GPU kommunizieren kann, weil die GPU aufgrund eines Hardwareproblems vom PCI-Bus verschwunden ist. |
Verwenden Sie einen der folgenden Ansätze, um Ihre Arbeitslasten wiederherzustellen. Das hängt davon ab, ob Notfallwartung für Ihr Projekt aktiviert ist:
|
Google stellt fest, dass die GPU vom PCI-Bus getrennt wurde, und sendet das Gerät zur Reparatur. |
Xid 109: Context switch timeout
Xid 109 ist ein generischer Fehler, der vom NVIDIA-GPU-Treiber gemeldet wird. Er wird generiert, wenn eine GPU-Instanz Aufgaben nicht innerhalb des erwarteten Zeitlimits unterbrechen oder wechseln kann. Google hat Xid 109 schon oft mit NVIDIA untersucht. Bekannte Ursachen, die auf Treiberfehler zurückzuführen sind, wurden in den neuesten Treibern behoben. Xid 109 wird nicht durch ein Hardwareproblem verursacht. |
|
Keine |
Xid 149, in dem 0x02a erwähnt wird, z. B. im folgenden Beispiel:
Dies weist auf ein bekanntes Problem mit der Firmware für NVIDIA B200-GPUs hin. |
|
Keine |
Fehlerbehebung bei nvidia-smi-Fehlern nach dem Patchen des Betriebssystems oder dem Upgrade des Kernels
Wenn nvidia-smi nach einem Wartungsfenster, einem Betriebssystem-Patching-Lauf oder einem VM-Neustart mit NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver fehlschlägt, prüfen Sie die Kernelpaket-Holds. Paketsperren aus einer vorherigen Treiberinstallation im binary-Modus können die Installation passender Kernel-Header verhindern.
Wählen Sie Ihr Betriebssystem aus, um dieses Problem zu diagnostizieren und zu beheben:
Ubuntu
Prüfen Sie die ausgeführte Kernel-Version:
uname -rPrüfen Sie, ob durch eine frühere Treiberinstallation im Modus
binarydie Kernelpakete gesperrt wurden, z. B. wenn Sie--force-version-,--installation-branch=lts- oder NVIDIA RTX Virtual Workstation-Recheninstanzen (vWS) verwenden:apt-mark showholdPrüfen Sie, ob
linux-image-gcpoderlinux-headers-gcpaufgeführt ist.Prüfen Sie, ob Kernel-Header für den ausgeführten Kernel installiert sind:
dpkg -l | grep "linux-headers-$(uname -r)"Wenn die Kernel-Metapakete zurückgehalten werden, entfernen Sie die Paketsperren:
sudo apt-mark unhold linux-image-gcp linux-headers-gcpInstallieren Sie die Kernel-Header für den laufenden Kernel:
sudo apt-get update && sudo apt-get install -y linux-headers-$(uname -r)Erstellen Sie das NVIDIA-Kernelmodul neu und laden Sie es:
Wenn DKMS-Modulquellen registriert sind (siehe
sudo dkms status):sudo dkms autoinstall sudo modprobe nvidia nvidia-smiWenn
sudo dkms statuskein registriertes NVIDIA-Modul anzeigt (z. B. wenn der Treiber zuvor mit einem.run-Binärprogramm ohne--dkmsinstalliert wurde), führen Sie das Google Cloud GPU-Treiberinstallationsprogramm noch einmal aus:sudo python3 cuda_installer.pyz install_driver
Debian
Prüfen Sie die ausgeführte Kernel-Version:
uname -rPrüfen Sie, ob durch eine frühere Treiberinstallation im Modus
binarydie Kernelpakete gesperrt wurden, z. B. wenn Sie--force-version-,--installation-branch=lts- oder NVIDIA RTX Virtual Workstation-Recheninstanzen (vWS) verwenden:apt-mark showholdPrüfen Sie, ob
linux-image-cloud-amd64oderlinux-headers-cloud-amd64aufgeführt ist.Prüfen Sie, ob Kernel-Header für den ausgeführten Kernel installiert sind:
dpkg -l | grep "linux-headers-$(uname -r)"Wenn die Kernel-Metapakete zurückgehalten werden, entfernen Sie die Paketsperren:
sudo apt-mark unhold linux-image-cloud-amd64 linux-headers-cloud-amd64Installieren Sie die Kernel-Header für den laufenden Kernel:
sudo apt-get update && sudo apt-get install -y linux-headers-$(uname -r)Erstellen Sie das NVIDIA-Kernelmodul neu und laden Sie es:
Wenn DKMS-Modulquellen registriert sind (siehe
sudo dkms status):sudo dkms autoinstall sudo modprobe nvidia nvidia-smiWenn
sudo dkms statuskein registriertes NVIDIA-Modul anzeigt (z. B. wenn der Treiber zuvor mit einem.run-Binärprogramm ohne--dkmsinstalliert wurde), führen Sie das Google Cloud GPU-Treiberinstallationsprogramm noch einmal aus:sudo python3 cuda_installer.pyz install_driver
RHEL und Rocky Linux
Prüfen Sie die ausgeführte Kernel-Version:
uname -rPrüfen Sie, ob durch eine frühere Treiberinstallation im Modus
binarydie Kernelpakete gesperrt wurden, z. B. wenn Sie--force-version-,--installation-branch=lts- oder NVIDIA RTX Virtual Workstation-Recheninstanzen (vWS) verwenden:grep "^exclude=.*kernel" /etc/dnf/dnf.confPrüfen Sie, ob Kernel-Header für den ausgeführten Kernel installiert sind:
rpm -qa | grep "kernel-devel-$(uname -r)"Wenn Kernelpakete ausgeschlossen werden, entfernen Sie
kernel*aus der Zeileexclude=in/etc/dnf/dnf.conf.Installieren Sie die Kernel-Header für den laufenden Kernel:
sudo dnf install -y kernel-devel-$(uname -r) kernel-headers-$(uname -r)Erstellen Sie das NVIDIA-Kernelmodul neu und laden Sie es:
Wenn DKMS-Modulquellen registriert sind (siehe
sudo dkms status):sudo dkms autoinstall sudo modprobe nvidia nvidia-smiWenn
sudo dkms statuskein registriertes NVIDIA-Modul anzeigt (z. B. wenn der Treiber zuvor mit einem.run-Binärprogramm ohne--dkmsinstalliert wurde), führen Sie das Google Cloud GPU-Treiberinstallationsprogramm noch einmal aus:sudo python3 cuda_installer.pyz install_driver
GPUs zurücksetzen
Bei einigen Problemen müssen Sie möglicherweise Ihre GPUs zurücksetzen. So setzen Sie GPUs zurück:
- Starten Sie für N1-, G2-, A2- und G4-VMs mit einer oder mehreren angehängten GPUs die VM neu.
- Führen Sie für G4-VMs mit fraktionierten GPUs (weniger als eine angehängte GPU) die folgenden Schritte aus:
- Führen Sie für A3-, A4-, A4X- und A4X Max-Instanzen
sudo nvidia-smi --gpu-resetaus.- Bei den meisten Linux-VMs befindet sich die ausführbare Datei
nvidia-smiim Verzeichnis/var/lib/nvidia/bin. - Für GKE-Knoten befindet sich die ausführbare Datei
nvidia-smiim Verzeichnis/home/kubernetes/bin/nvidia.
- Bei den meisten Linux-VMs befindet sich die ausführbare Datei
- Für A3-, A4-, A4X- und A4X Max-Instanzen auf GKE-Knoten können Sie auch das gpu-reset-tool verwenden, um das Zurücksetzen aller GPUs auf einem Knoten zu automatisieren. Bei diesem Tool müssen Sie nur den Namen des Zielknotens angeben.
Alternativ werden GPUs auch zurückgesetzt, wenn Sie eine VM zurücksetzen oder eine VM beenden und neu starten. Weitere Informationen zu VM-Lebenszyklusstatus und den Unterschieden zwischen VM-Wiederherstellungsaktionen finden Sie unter Lebenszyklus von Compute Engine-Instanzen und Compute Engine-Instanzen sperren, anhalten oder zurücksetzen.
Supportfall eröffnen
Wenn Sie die Probleme mit den Informationen auf dieser Seite nicht beheben können, sammeln Sie die folgenden Informationen und erstellen Sie eine Supportanfrage:
- Projekt-ID des Projekts, in dem sich die betroffenen Instanzen befinden.
- Liste aller Instanznamen oder ‑IDs im Cluster.
- Liste der verdächtigen Knoten, die bei der Fehlerbehebung ermittelt wurden.
- Vollständige, nicht verschachtelte NCCL-Logs mit aktivierten Debug-Einstellungen.
- Ausgabe von Hardware-Systemdiagnosen (
dcgmi,nvidia-smi). - Genaue Benchmark- oder Arbeitslastbefehle, die fehlschlagen.
- Relevante Logdateien wie Host-Engine- und Diagnoselogs. Führen Sie
gather-dcgm-logs.shaus, um diese Informationen zu erfassen. Die Datei befindet sich in Standardinstallationen unter/usr/local/dcgm/scripts. - NVIDIA-Fehlerbericht. Führen Sie
nvidia-bug-report.shaus. Für Blackwell-GPUs folgen Sie der Anleitung unter NVIDIA-Fehlerbericht für Blackwell-GPUs erstellen. - Details zu allen kürzlich an Ihrer Umgebung vorgenommenen Änderungen, die dem Fehler vorausgingen.
Nächste Schritte
GPU-Maschinentypen ansehen