Warum ist die GPU-Auslastung niedrig, und wie erkennen Sie, ob der Flaschenhals bei Compute, Netzwerk, Storage oder Data Loading liegt?

Niedrige GPU-Auslastung bedeutet meist, dass der Beschleuniger auf etwas wartet. Der Flaschenhals kann bei Compute, Netzwerkkommunikation, Storage-Durchsatz, CPU-seitiger Datenvorbereitung, Workload-Konfiguration oder Scheduling liegen. Der schnellste Weg, ihn zu finden, ist, diese Signale auf dieselbe Zeitachse zu legen und nach der Schicht zu suchen, die sich ändert, wenn die GPU-Aktivität sinkt.

Ein einzelnes GPU-Auslastungsdiagramm zu betrachten, reicht selten aus. Eine GPU kann völlig gesund sein, während ein Trainingsjob durch Data Loading oder kollektive Kommunikation blockiert ist. Die nützliche Frage lautet nicht einfach: "Warum steht die GPU bei 40 Prozent?" Sie lautet: "Worauf wartete die GPU während der übrigen 60 Prozent?"

Was bedeutet niedrige GPU-Auslastung eigentlich?

Niedrige GPU-Auslastung bedeutet, dass der Beschleuniger während des Messintervalls nicht durchgehend nützliche GPU-Arbeit ausgeführt hat.

Das heißt nicht automatisch, dass die GPU zu langsam, falsch konfiguriert oder defekt ist. Es sagt nur aus, dass das Gerät nicht die ganze Zeit beschäftigt war.

Ein Trainingsschritt hat meist mehrere Stufen. Die CPU bereitet vielleicht einen Batch vor. Storage liest Samples. Daten wandern in den Host-Speicher und dann in den Device-Speicher. Mehrere Worker synchronisieren sich. Die GPU führt Kernels aus. Der Vorgang wiederholt sich.

Wenn eine vorgelagerte Stufe den nächsten Batch nicht rechtzeitig bereitstellen kann, wartet die GPU.

Wenn verteilte Worker zu unterschiedlichen Zeitpunkten einen Synchronisationspunkt erreichen, warten die schnelleren Worker.

Wenn einem Job eine GPU zugewiesen wird, er aber nicht genug Arbeit hat, um sie auszulasten, wartet die GPU.

Deshalb sollte Auslastung als Ausgangssignal behandelt werden, nicht als Diagnose.

Der NVIDIA Data Center GPU Manager stellt Telemetriedaten bereit wie Auslastung, Taktraten, Leistung, speicherbezogene Felder, PCIe-Aktivität, ECC-Ereignisse und weitere Beschleuniger-Statistiken, abhängig von Hardware und Treiberunterstützung. Diese Metriken sind nützlich, werden aber deutlich wertvoller, wenn man sie mit dem Rest des Workload-Pfads korreliert.

Für die Seite der Ressourcenzuteilung erklärt GPU-Resource-Pooling und -Scheduling in Kubernetes, wie Queueing, Ressourcenklassen und Zuteilung Leerlaufkapazität erzeugen oder reduzieren können.

Wie erkennen Sie, ob der Flaschenhals bei Compute liegt?

Ein Compute-Flaschenhals ist wahrscheinlich, wenn die GPU beschäftigt bleibt und der Job trotzdem langsamer als erwartet läuft.

Das klingt offensichtlich, trennt aber ein ganz anderes Problem von niedriger Auslastung durch Warten.

Wenn die GPU-Auslastung hoch bleibt, der GPU-Speicher gut genutzt wird, die Taktraten normal laufen und die Workload durchgehend Kernels ausführt, ist der Beschleuniger möglicherweise schlicht die limitierende Ressource für die Workload.

Dann schauen Sie sich die Form der Workload an.

Ist das Modell zu groß für ein Gerät? Würden mehr Beschleuniger die Step-Zeit verkürzen? Nutzt die Workload den erwarteten Präzisionsmodus? Laufen die Kernels effizient? Wird die Karte durch Temperatur oder Leistung gedrosselt? Teilt sich der Job das Gerät mit einer anderen Workload?

Hardware-Health spielt hier eine Rolle. Eine Karte kann hohe Auslastung melden und trotzdem unter der Erwartung liegen, wenn sie wiederholt die Taktraten drosselt oder Fehler auftreten.

Hier sollte Health auf Kartenebene Teil der Performance-Analyse sein. Das zugrunde liegende Betriebsmodell verknüpft Auslastung mit Temperatur, Leistung, ECC-Status und Taktverhalten, damit eine degradierte Karte nicht mit einem normalen Kapazitätslimit verwechselt wird.

Wenn Sie gemischte Beschleuniger betreiben, behandelt Wie man Multi-Vendor-GPUs und -NPUs verwaltet die Notwendigkeit, Health und Fähigkeiten zu normalisieren, bevor Geräte verglichen werden.

Wie identifizieren Sie einen Netzwerk-Flaschenhals?

Ein Netzwerk-Flaschenhals wird wahrscheinlich, wenn verteilte Worker mehr Zeit mit Warten auf Kommunikation verbringen und die GPU-Auslastung in denselben Zeiträumen sinkt.

Verteiltes Training erzeugt starke Kommunikation zwischen Workern. Das genaue Muster hängt vom Framework und Modell ab, aber die operativen Signale ähneln sich.

Beobachten Sie Netzwerkdurchsatz, Latenz, Paketverlust, Retransmission, Interface-Fehler, Stauungsindikatoren und das Timing kollektiver Operationen, sofern verfügbar.

Legen Sie diese Signale dann mit der GPU-Auslastung übereinander.

Wenn die GPU-Auslastung um 10:17 Uhr sinkt und die Netzwerk-Retransmission im selben Moment steigt, verdient dieser Zusammenhang Aufmerksamkeit.

Wenn ein Node durchgehend eine langsamere Verbindung zeigt, während die anderen Nodes gesund bleiben, kann dieser Node den gesamten Job ausbremsen.

Wenn alle Nodes ähnlichen Netzwerkdruck zeigen, ist möglicherweise die Fabric gesättigt.

Die stärkste Diagnose entsteht aus Zusammenhängen, nicht nur aus Diagrammen. Die Plattform sollte wissen, welche Netzwerk-Ports Traffic für welche Compute-Nodes tragen und welche Nodes zum betroffenen Job gehören.

Ohne diese Zuordnung sieht ein Netzwerkteam einen überlasteten Port, und ein KI-Team sieht einen langsamen Trainingsjob, aber keines von beiden kann beweisen, dass die beiden Ereignisse zusammenhängen.

Wie identifizieren Sie einen Storage-Flaschenhals?

Ein Storage-Flaschenhals wird wahrscheinlich, wenn der Beschleuniger auf Daten wartet, während die Storage-Latenz steigt, der Durchsatz sinkt oder die Input-Pipeline Batches nicht schnell genug liefern kann.

Überwachen Sie Storage-Durchsatz, IOPS, Latenz, Queue-Tiefe, sofern verfügbar, und das Lesemuster der Trainings-Workload.

Prüfen Sie Checkpoints getrennt von Dataset-Reads. Ein Job kann während der meisten Steps normal laufen und dann bei großen Checkpoint-Writes stocken.

Kapazität und Performance sollten ebenfalls getrennt betrachtet werden.

Ein Storage-Pool kann reichlich freie Kapazität haben und trotzdem zu langsam für die Workload sein.

Dasselbe gilt für Network Attached Storage. Das Storage-Array kann gesund sein, während der Netzwerkpfad zwischen Compute und Storage limitiert ist.

Deshalb sollte Storage als Teil der Daten-Versorgungskette betrachtet werden, nicht als isolierter Infrastruktur-Dienst.

Eine nützliche Diagnose-Zeitachse enthält GPU-Auslastung, Storage-Durchsatz, Storage-Latenz und Trainings-Step-Zeit. Wenn die Storage-Latenz zuerst ausschlägt und die GPU-Auslastung unmittelbar danach sinkt, haben Sie eine deutlich stärkere Hypothese als "die GPUs sehen untätig aus".

Wie identifizieren Sie einen Data-Loading-Flaschenhals?

Ein Data-Loading-Flaschenhals wird wahrscheinlich, wenn die CPU-seitige Input-Pipeline Batches nicht so schnell vorbereiten und übertragen kann, wie die GPU sie verbraucht.

PyTorch dokumentiert, dass DataLoader mehrere Worker-Prozesse nutzen kann und Optionen wie num_workers und Pinned Memory bietet, um den Data-Loading-Durchsatz zu verbessern. Die genauen Einstellungen hängen von Workload, Storage-System, CPU-Kapazität, Batch-Größe und Transformationslogik ab.

Der wichtige Teil ist die Messung.

Beobachten Sie CPU-Auslastung, Per-Worker-CPU-Druck, Host-Speicher, Disk- oder Storage-Reads, Batch-Vorbereitungszeit und GPU-Leerlauflücken.

Wenn die CPU-Nutzung gesättigt ist, während die GPU-Auslastung niedrig ist, könnte Preprocessing die limitierende Stufe sein.

Wenn Storage schnell ist, aber die Batch-Vorbereitung langsam, laufen möglicherweise teure Transformationen auf der CPU.

Wenn Batches schnell vorbereitet werden, aber der Transfer zur GPU verzögert ist, prüfen Sie das Host-zu-Device-Transferverhalten.

Data-Loading-Probleme sind häufig, weil sie von der Beschleuniger-Seite aus genau wie unzureichende GPU-Arbeit aussehen können.

Ein nützlicher Test besteht darin, die Komplexität der Input-Pipeline vorübergehend zu reduzieren. Wenn die GPU-Auslastung mit synthetischen oder vorgeladenen Daten deutlich steigt, liegt der Flaschenhals wahrscheinlich vor der GPU.

Wie erkennen Sie, ob es sich um ein Scheduling- statt um ein Performance-Problem handelt?

Ein Scheduling-Problem ist wahrscheinlich, wenn GPUs insgesamt verfügbar sind, Workloads aber nicht die richtige Ressourcenform zur richtigen Zeit erhalten können.

Stellen Sie sich einen Cluster mit acht freien GPUs über mehrere Nodes verteilt vor. Ein verteilter Job braucht vielleicht acht GPUs auf Nodes, die eine bestimmte Topologie- oder Speicheranforderung erfüllen. Die freie Gesamtkapazität sieht ausreichend aus, aber die nutzbare Kapazität für diesen Job ist es nicht.

Quotas können dasselbe Symptom erzeugen. Die Hardware ist frei, aber das Projekt hat sein Zuteilungslimit erreicht.

Auch Fragmentierung kann eine Rolle spielen. Kleine Workloads können Teile mehrerer Geräte oder Nodes so belegen, dass ein großer Job nicht mehr hineinpasst.

In diesen Fällen kann die GPU-Auslastung im gesamten Rechenzentrum niedrig sein, obwohl Jobs in der Queue warten.

Das ist kein Compute-Performance-Problem. Es ist ein Ressourcenzuteilungsproblem.

Die Queue sollte daher den Grund zeigen, warum ein Job wartet, etwa Quota ausgeschöpft, keine passende Beschleunigerklasse, unzureichende zusammenhängende Topologie, Health-Ausschluss oder Ressourcenfragmentierung.

Warum sollten Compute, Netzwerk und Storage auf derselben Zeitachse dargestellt werden?

Eine gemeinsame Zeitachse zeigt Ihnen, welche Schicht sich zuerst geändert hat.

Angenommen, die GPU-Auslastung fällt von 85 Prozent auf 30 Prozent.

Wenn die Storage-Latenz 20 Sekunden früher steigt, ist Storage ein starker Kandidat.

Wenn Storage normal bleibt, aber die Netzwerk-Retransmission zur selben Zeit stark steigt, untersuchen Sie die Trainings-Fabric.

Wenn sowohl Netzwerk als auch Storage stabil bleiben, während die CPU-seitige Batch-Zeit steigt, untersuchen Sie Data Loading.

Wenn alle Infrastruktur-Metriken normal bleiben, die GPU aber Takt-Drosselung oder ECC-Ereignisse zeigt, untersuchen Sie die Compute-Health.

Diese Methode beweist keine Kausalität wie von Zauberhand, aber sie reduziert Rätselraten und liefert Ihnen eine Beweiskette.

Das Ausgangsmaterial nutzt wiederholt dieses Prinzip: Compute, Netzwerk und Storage auf einer Zeitachse ausrichten, dann die wahrscheinliche Flaschenhals-Domäne annotieren und den Effekt nach einer Änderung verifizieren.

Dieser letzte Schritt zählt. Eine Diagnose ist stärker, wenn sich die Metrik verbessert, nachdem die vermutete Einschränkung entfernt wurde.

Welche Metriken sollten Sie zuerst sammeln?

Beginnen Sie mit der kleinsten Menge, die Warten von Arbeiten unterscheiden kann.

Für die GPU: Auslastung, Speichernutzung, Temperatur, Leistung, Taktzustand und Hardware-Fehler, sofern unterstützt.

Für das Netzwerk: Durchsatz, Latenz, Verlust, Retransmission, Interface-Fehler und Link-Status.

Für Storage: Durchsatz, IOPS, Latenz und Kapazitätsdruck.

Für Data Loading: CPU-Auslastung, Worker-Aktivität, Batch-Vorbereitungszeit und Input-Durchsatz.

Für den Scheduler: zugeteilte gegenüber verfügbaren Beschleunigern, Queue-Zeit, Queue-Grund, Quota-Status und Fragmentierungsindikatoren.

Für die Workload: Step-Zeit, Job-Status, Checkpoint-Dauer und Fehlerereignisse.

Stellen Sie dann sicher, dass alle diese Datenquellen konsistente Zeitstempel verwenden.

Ein Plattformbeispiel, das diese Schichten verbindet, ist Sensaka. Der Produktname zählt weniger als das Betriebsprinzip: Performance-Diagnose sollte der Workload folgen, von der Datenversorgung über Netzwerk, Compute, Scheduling bis zum Service-Output.

Was ist die beste Reihenfolge für die Fehlersuche?

Beginnen Sie mit dem Symptom und schließen Sie dann Schichten in der Reihenfolge aus, die sich am schnellsten verifizieren lässt.

Bestätigen Sie zunächst, dass die Auslastung für den Workload-Zeitraum, der Sie interessiert, tatsächlich niedrig ist.

Prüfen Sie zweitens die Karten-Health, damit Sie nicht eine Stunde damit verbringen, Software um ein degradiertes Gerät herum zu tunen.

Prüfen Sie drittens, ob der Job tatsächlich durchgehend läuft oder Zeit in der Queue, pausiert oder synchronisierend verbringt.

Legen Sie viertens Netzwerk- und Storage-Metriken mit dem Auslastungsrückgang übereinander.

Untersuchen Sie fünftens das CPU-seitige Data Loading.

Erst nach diesen Prüfungen sollten Sie anfangen, Modellcode zu ändern oder GPUs hinzuzufügen.

Wenn die GPUs auf Storage warten, macht mehr GPUs die Verschwendung nur größer. Wenn der Job durch Quota blockiert ist, hilft Kernel-Tuning nicht. Wenn eine Karte degradiert ist, behebt eine Änderung am DataLoader das Problem nicht.

Das nützlichste Urteil ist daher einfach: Behandeln Sie niedrige GPU-Auslastung als domänenübergreifendes Betriebsproblem, bis Beweise zeigen, dass die GPU selbst die limitierende Ressource ist.