Erwartungen erklären, bevor Sie eine leistungsstärkere GPU suchen.

Das Problem mit einem Ergebnis und einem Zeitfenster beschreiben

Ersetzen Sie „die GPU arbeitet nicht“ durch eine überprüfbare Beobachtung: Das erste Ergebnis kommt spät, die Schritte weisen Pausen auf oder die Anzahl akzeptierter Ausgaben sinkt. Geben Sie das Eingabeset, die Version der Anwendung, die Einstellungen und den beobachteten Zeitraum an. Ein erster Start kann andere Phasen als ein bereits vorbereiteter Durchlauf umfassen; vermischen Sie diese nicht, ohne es anzugeben.

Unterteilen Sie den Ablauf in Öffnen der Dateien, CPU-Vorbereitung, Übertragung, GPU-Berechnung, Schreiben und anschließende Validierung. Diese Phasen können sich überlappen: Die Darstellung ist eine Hypothese, die mit den Protokollen abgeglichen werden muss. Notieren Sie die Grenzen in derselben Zeitzone und mit ausreichender Genauigkeit. Ein Hardware-Diagramm, das nach der Pause aufgenommen wurde, erlaubt es nicht, die Pause zu erklären, auch wenn sein Wert ungewöhnlich erscheint.

Prozentsätze und Speicher richtig lesen

In NVIDIA SMI gibt die GPU-Auslastung den Anteil des Abtastintervalls an, während dem mindestens ein Kernel ausgeführt wurde. Das ist keine Leistungsnote aller Komponenten. Die Speicherauslastung beschreibt deren Lese- oder Schreibaktivität; sie darf nicht mit der belegten Speichermenge verwechselt werden. Die Dokumentation präzisiert zudem, dass bestimmte Felder je nach Umgebung nicht verfügbar sein können.

Behalten Sie daher den genauen Namen der Metrik und ihre Einheit bei. Eine hohe Speichermenge kann zwischengespeicherten Daten entsprechen; eine geringe Aktivität kann während einer normalen Vorbereitungsphase auftreten. Umgekehrt belegt eine hohe Aktivität nicht, dass das Programm nützliche Arbeit leistet. Man muss die Ausgaben und den Anwendungsfortschritt zugleich mit der Hardware betrachten.

Eine korrelierte und ausreichend kurze Messreihe erfassen

Wählen Sie eine repräsentative Sequenz und begrenzen Sie die Erfassung auf diese Sequenz. Erfassen Sie die Zeiten, die GPU-Kennung, die Aktivität, den belegten Speicher und die Phasen der Anwendung. Beobachten Sie parallel dazu mit den auf Ihrem System verfügbaren Werkzeugen den CPU-Prozess, seine Wartezeiten, seine Lese- und Schreibvorgänge. Ein Mittelwert über alle Kerne kann einen einzelnen gesättigten Thread verdecken; betrachten Sie auch die betroffenen Prozesse.

Der unten stehende Auslesebefehl ist für ein autorisiertes NVIDIA-Ziel gedacht, auf dem NVIDIA SMI bereits vorhanden ist. Er wurde für diesen Leitfaden nicht ausgeführt. Er behält die Einheiten in der CSV bei und zeigt bis zu seiner Unterbrechung eine Beobachtung pro Sekunde an. Prüfen Sie die von Ihrer Version unterstützten Felder und beenden Sie die Erfassung am Ende des Szenarios. Ein Feld N/A bleibt unbekannt: Wandeln Sie es nicht in null um.

Das Mindestprotokoll verbindet eine Vorgangskennung, eine Zeit mit Zeitzone, die aktuelle Phase, eine identifizierbare Eingabe oder Charge, den Fortschritt und den eventuellen Fehler. Es darf weder Geheimnisse noch für die Diagnose unnötigen fachlichen Inhalt enthalten. Wenn Telemetrie fehlt, prüfen Sie zuerst ihre Erfassungseinrichtung und den Anwendungsfortschritt: Eine leere Kurve beweist nicht, dass ein Prozess angehalten wurde. Kennzeichnen Sie den Zeitraum ohne Beobachtung, statt ihn aus dem Gedächtnis zu rekonstruieren.

nvidia-smi --version
nvidia-smi --query-gpu=timestamp,uuid,utilization.gpu,memory.used,memory.total --format=csv --loop=1

Zwischen einer Spur und einer Schlussfolgerung unterscheiden

Wenn die GPU-Aktivität sinkt, während die Anwendung auf ihre Eingaben wartet, untersuchen Sie den Dateipfad. Wenn sie während einer langen CPU-Vorbereitung sinkt, untersuchen Sie diese Phase und ihre tatsächliche Parallelität. Wenn die Geräte auf die übrigen Teilnehmer einer verteilten Arbeit warten, prüfen Sie die Lastverteilung und die Kommunikation. Mehrere Symptome können gleichzeitig auftreten; ihre Korrelation ist noch kein Beweis für Kausalität.

Formulieren Sie eine kurze Hypothese und eine Änderung, mit der sie sich entscheiden lässt. Beispielsweise kann der Vergleich derselben bereits vorbereiteten Eingaben mit ihrer üblichen Vorbereitung einen Schritt isolieren, sofern die Ergebnisse gleich bleiben. Ändern Sie nicht gleichzeitig Chargengröße, Genauigkeit, Anzahl der Prozesse und Dateispeicherort: Eine Verbesserung wäre dann schwer zuzuordnen.

Fiktives Beispiel: eine Schleife von hundert Sekunden analysieren

Das fiktive Team „Revue des maquettes“ beschreibt eine Schleife ohne Überlappung: sechzig Sekunden CPU-Vorbereitung, zwanzig Sekunden GPU-Berechnung, dann zwanzig Sekunden Export. Die Summe beträgt 100 Sekunden und der auf die GPU-Berechnung entfallende Zeitanteil beträgt 20/100, also 20 %. Diese didaktische Rechnung sagt nicht den Prozentsatz eines Sampling-Werkzeugs voraus und entspricht keiner Messung einer GPU des Katalogs.

Angenommen, die Vorbereitung ließe sich auf dreißig Sekunden verkürzen, ohne die Berechnung oder die Ausgaben zu ändern. Die Schleife würde dann 30 + 20 + 20 = 70 Sekunden dauern: dreißig Sekunden weniger, mit einem GPU-Anteil von 20/70, also etwa 28,6 %. Umgekehrt ergäbe eine hypothetische Halbierung allein der GPU-Berechnung 60 + 10 + 20 = 90 Sekunden. Das Szenario erklärt, warum die Beseitigung der längsten Wartezeit mehr bewirken kann als ein Kartenwechsel.

Eine Phase mit einem Profiler vertiefen

Wenn die allgemeine Beobachtung eine langsame Zone lokalisiert, ohne sie zu erklären, verwenden Sie den auf die Anwendung abgestimmten Profiler über ein kurzes Zeitfenster. Der PyTorch Profiler kann CPU- und CUDA-Ereignisse erfassen und Erfassungsfenster organisieren. Die Dokumentation weist auf einen zusätzlichen Aufwand hin, wenn die Aufzeichnung von Formen oder Stapeln aktiviert ist. Eine detaillierte Trace ist daher ein Diagnoseinstrument; ihre Gesamtzeit darf nicht ohne Vorbehalt als die normale Laufzeit des Programms dargestellt werden.

Halten Sie die Phasennamen aussagekräftig genug, um einen technischen Vorgang mit Ihrer Arbeit zu verknüpfen: Vorbereitung einer Dateigruppe, Übertragung, Anwendungsschritt oder Veröffentlichung der Ausgabe. Beginnen Sie mit dem Detaillierungsgrad, den die Hypothese erfordert. Nehmen Sie nach der Änderung eine vergleichbare Beobachtung und anschließend eine Ausführung ohne aufwendige Instrumentierung vor. Diese zweite Kontrolle zeigt, ob der Nutzen auch unter üblichen Bedingungen besteht.

Korrekturen vermeiden, die das Problem verschleiern

Eine höhere Parallelität kann die GPU auslasten und gleichzeitig den Datenträger, den Hostspeicher oder die Ausgaben überlasten. Eine größere Batch-Größe kann die Latenz und den benötigten Speicher verändern. Eine geringere Genauigkeit kann das Ergebnis verändern. Diese Entscheidungen sind nicht verboten, aber sie sollten am selben Geschäftsziel gemessen werden, einschließlich ihrer Nebenwirkungen, statt allein deshalb gewählt zu werden, weil der angezeigte Prozentsatz steigt.

Setzen Sie ein Gerät nicht zurück und ändern Sie seine Hardware-Parameter nicht, um einen bloßen Rückgang der Aktivität zu diagnostizieren. Beginnen Sie mit dem Auslesen und lassen Sie dann explizite Fehler von der zuständigen autorisierten Person prüfen. Vermeiden Sie es außerdem, Rohtraces zu veröffentlichen, die private Pfade, vertrauliche Parameter oder Eingabedaten enthalten. Bereiten Sie einen für die Diagnose nützlichen Auszug vor und bewahren Sie den vollständigen Nachweis im autorisierten Bereich des Teams auf.

Die Diagnose mit einem entscheidungsrelevanten Nachweis abschließen

Die abschließende Dokumentation muss das Symptom, die getroffene Annahme, die versuchte Änderung, ihre Bedingungen und das beobachtete Ergebnis angeben. Bewahren Sie mindestens einen Vorher-/Nachher-Vergleich mit demselben Eingabesatz, derselben Qualität und derselben Definition des Endes auf. Wenn das Ergebnis nicht schlüssig ist, halten Sie fest, was ausgeschlossen wurde und welche Beobachtung als Nächstes erforderlich ist. Eine dokumentierte verworfene Spur verhindert, dass eine andere Person planlos von vorn beginnt.

Eine geringe normale Aktivität erfordert nicht immer eine Korrektur. Wenn die Aufgabe ihre Frist, ihre Qualität und ihr Budget einhält, kann das Reduzieren einer Komplexität einer fragilen Optimierung vorzuziehen sein. Wenn eine neue Konfiguration in Betracht gezogen wird, übermitteln Sie die nachgewiesenen Einschränkungen an die Abnahmedokumentation. Keine einzelne Messung ordnet den Katalog ein, und kein Wert dieses Beispiels stellt eine zugesicherte Leistung dar.