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 ist deshalb weniger "Warum steht die GPU bei 40 Prozent?" als "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 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, und der Vorgang wiederholt sich. Kann eine vorgelagerte Stufe den nächsten Batch nicht rechtzeitig bereitstellen, wartet die GPU. Erreichen verteilte Worker zu unterschiedlichen Zeitpunkten einen Synchronisationspunkt, warten die schnelleren Worker. Und wenn einem Job eine GPU zugewiesen wird, er aber nicht genug Arbeit hat, um sie auszulasten, wartet die GPU ebenfalls. Auslastung ist deshalb ein Ausgangssignal und noch keine 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, und würden mehr Beschleuniger die Step-Zeit verkürzen? Nutzt die Workload den erwarteten Präzisionsmodus, und laufen die Kernels effizient? Wird die Karte durch Temperatur oder Leistung gedrosselt, oder 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. Health auf Kartenebene sollte deshalb 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, und 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. Zeigt ein Node durchgehend eine langsamere Verbindung, während die anderen Nodes gesund bleiben, kann dieser Node den gesamten Job ausbremsen. Zeigen alle Nodes ähnlichen Netzwerkdruck, ist möglicherweise die Fabric gesättigt.

Die stärkste Diagnose entsteht, wenn man die Diagramme miteinander in Zusammenhang bringt. 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, denn ein Job kann während der meisten Steps normal laufen und dann bei großen Checkpoint-Writes stocken. Kapazität und Performance sollten Sie ebenfalls getrennt betrachten: 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, wo das Storage-Array gesund sein kann, während der Netzwerkpfad zwischen Compute und Storage limitiert ist. Storage sollte deshalb als Teil der Daten-Versorgungskette betrachtet werden und 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. Entscheidend ist, dass Sie messen: CPU-Auslastung, Per-Worker-CPU-Druck, Host-Speicher, Disk- oder Storage-Reads, Batch-Vorbereitungszeit und GPU-Leerlauflücken.

Ist die CPU-Nutzung gesättigt, während die GPU-Auslastung niedrig bleibt, könnte Preprocessing die limitierende Stufe sein. Ist Storage schnell, aber die Batch-Vorbereitung langsam, laufen möglicherweise teure Transformationen auf der CPU. Werden Batches schnell vorbereitet, aber der Transfer zur GPU ist verzögert, 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, die nutzbare Kapazität für diesen Job ist es nicht. Quotas können dasselbe Symptom erzeugen, wenn die Hardware frei ist, das Projekt aber sein Zuteilungslimit erreicht hat. Auch Fragmentierung spielt eine Rolle, weil kleine Workloads Teile mehrerer Geräte oder Nodes so belegen können, 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 ein Ressourcenzuteilungsproblem und kein Compute-Performance-Problem. 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. Steigt die Storage-Latenz 20 Sekunden früher, ist Storage ein starker Kandidat. Bleibt Storage normal, während die Netzwerk-Retransmission zur selben Zeit stark steigt, untersuchen Sie die Trainings-Fabric. Bleiben Netzwerk und Storage stabil, während die CPU-seitige Batch-Zeit steigt, untersuchen Sie Data Loading. Und 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, denn 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 sind das 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.