Mit einer Referenz beginnen, die den Bedarf erfüllt
Wählen Sie ein kurzes Set mit gewöhnlichen Eingaben, Grenzfällen und Entscheidungsgrenzen. Fixieren Sie Modell, Gewichte, Vorverarbeitung und den Modus train oder eval. Ein Vergleich zwischen zwei Modellen oder zwei Batches erlaubt es nicht, ihren Unterschied der Präzision zuzuschreiben.
Speichern Sie die für Ihre Anwendung nützliche Ausgabe, nicht nur den Verlust. Für einen Klassifikator kann das Scores und Entscheidungen umfassen; für eine Regression Fehler und Extremwerte. Prüfen Sie bereits in der Referenz, ob NaN oder inf vorhanden sind. Eine fehlerhafte FP32-Ausführung wird nicht dadurch zu einer zuverlässigen Grundlage, dass sie mehr Bits besitzt.
Legen Sie Toleranz, Mindestqualität und das Fehlen von Nicht-Endlichen-Werten vor dem Versuch fest. PyTorch weist darauf hin, dass Fließkommaberechnungen keine identischen Ergebnisse zwischen Geräten oder Ausführungspfaden garantieren.
autocast, Zahlenformat und GradScaler unterscheiden
autocast wählt den Typ bestimmter Operationen gemäß ihrer Rechenrichtlinie. Es wandelt nicht das gesamte Programm in ein einziges Format um. Bei dieser Verwendung sollten Sie vermeiden, das gesamte Modell manuell per half() zu konvertieren. Die aktuelle Dokumentation empfiehlt torch.autocast oder torch.amp.autocast; die alten Schnittstellen torch.cuda.amp sind veraltet.
GradScaler wirkt auf die Skalierung des Verlusts und der Gradienten während des Trainings. Er wird nicht als Beschleuniger der Inferenz eingesetzt, die kein Backward durchführt. FP16 hat einen kleineren numerischen Bereich als BF16; ein für BF16 konzipiertes Modell kann in FP16 überlaufen. Eine wiederholte Verringerung der Skalierung belegt daher nicht, dass das Problem gelöst ist.
Wählen Sie das Format anhand der Einschränkungen des Modells und der tatsächlich verwendeten Operationen und prüfen Sie dann die Unterstützung des Ziels. Der Handelsname einer Karte oder eine Vorliebe bei der PyTorch-Vorbereitung beweist nicht, dass Ihr benutzerdefinierter Operator den gewünschten Kernel besitzt.
Scrollen Sie durch die Tabelle, um alle Spalten zu lesen.| Auswahl | Rolle | Erforderliche Kontrolle |
|---|---|---|
| FP32-Referenz | Vergleichspunkt des Projekts | Endliche Ausgaben und erwartete Qualität |
| Autocast FP16 | Bestimmte Operationen in reduzierter Präzision | Numerischer Bereich und Gradienten |
| Autocast BF16 | Anderer Kompromiss zwischen Bereich und Präzision | Verfügbare Operatoren und Qualität |
| GradScaler | Umgang mit der Skalierung der Gradienten | Tatsächlich durchgeführte Aktualisierungen |
Die Schritte des Trainings in die richtige Reihenfolge bringen
Das vorgeschlagene Fragment setzt ein bereits konstruiertes Modell und einen bereits konstruierten Optimierer, eine Eingabe und ein Ziel auf derselben GPU sowie einen skalaren Verlust voraus. Es wurde nicht ausgeführt und stellt keine Validierung eines Angebots dar. Der autocast-Kontext umschließt den Forward und den Verlust; das Backward läuft nach dessen Schließung ab. Der Scaler wird einmal für die Trainingssitzung erstellt, nicht bei jedem Batch.
Um die Gradienten zu inspizieren oder zu beschneiden, entfernen Sie zunächst ihren Skalierungsfaktor mit unscale_. Die offiziellen AMP-Beispiele geben an, dies einmal pro Optimierer und nach der Akkumulation der für seine Aktualisierung bestimmten Gradienten zu tun. Der untenstehende Schwellenwert für das Clipping von 1.0 ist ein beispielhafter Wert, den Sie für Ihr Projekt wählen sollten, keine allgemeine Empfehlung.
Die Guards brechen hier die Diagnose ab, wenn Verlust, Gradienten oder Gesamtnorm nicht endlich sind. Diese CPU-Lesevorgänge sind intrusiv: Messen Sie die Zeit dieses Fragments nicht. Akkumulation, mehrere Optimierer und ein Scheduler erfordern ihre eigene Definition der Aktualisierung.
import torch
# Vorbedingungen: model, optimizer, loss_fn, inputs und targets existieren.
# Das Modell und die Eingaben befinden sich auf demselben CUDA/HIP-Gerät.
dtype = torch.float16 # Zu validierende Wahl; BF16 ist ein weiterer Versuch.
scaler = torch.amp.GradScaler("cuda", enabled=(dtype == torch.float16))
# In Ihre Schleife einzufügen, wobei scaler zwischen den Batches erhalten bleibt.
optimizer.zero_grad(set_to_none=True)
with torch.autocast(device_type="cuda", dtype=dtype):
prediction = model(inputs)
loss = loss_fn(prediction, targets)
if not bool(torch.isfinite(loss).item()):
raise FloatingPointError("Nicht endlicher Verlust: Diagnose abbrechen")
scaler.scale(loss).backward()
scaler.unscale_(optimizer)
if any(p.grad is not None and
not bool(torch.isfinite(p.grad).all().item())
for p in model.parameters()):
raise FloatingPointError("Nicht endlicher Gradient: Diagnose abbrechen")
torch.nn.utils.clip_grad_norm_(
model.parameters(), max_norm=1.0, error_if_nonfinite=True,
)
scaler.step(optimizer)
scaler.update()Ausgearbeitetes Beispiel: zwei ähnliche Entscheidungen sind nicht austauschbar
Nehmen wir einen Dienst an, der die Klasse mit dem höchsten Score auswählt. Bei einer Lehrbeispiel-Eingabe liefert die Referenz zwei sehr nahe beieinanderliegende Scores: 1,0000 und 1,0003. Ein anderer numerischer Pfad könnte ihre Reihenfolge ändern oder eine Gleichheit erzeugen. Diese Zahlen veranschaulichen eine Entscheidungsgrenze; sie sind keine gemessenen Ausgaben von FP16 oder BF16.
Die richtige Überprüfung erfolgt auf zwei Ebenen. Vergleichen Sie die Scores mit expliziten Toleranzen und vergleichen Sie dann die Entscheidung und die auf Gleichstände angewandte Regel. Ein geringer Unterschied im absoluten Wert kann die gewählte Aktion ändern. Umgekehrt kann ein sichtbarer numerischer Unterschied für eine Aufgabe folgenlos bleiben, deren Schwellenwert weit von den beobachteten Scores entfernt liegt.
Protokollieren Sie Identifikatoren, Referenzausgaben, den AMP-Test und die Auswirkung auf die Entscheidung. Legen Sie die Akzeptanzregel fest, bevor Sie die Ergebnisse lesen. Erweitern Sie nicht die Toleranz, um einen störenden Fall verschwinden zu lassen; Ausgaben unterschiedlicher Größenordnungen können unterschiedliche Kriterien erfordern.
Scrollen Sie durch die Tabelle, um alle Spalten zu lesen.| Kriterium | Referenz | AMP-Test | Entscheidung |
|---|---|---|---|
| Endgültige Ausgaben | Zu prüfen | Zu prüfen | Unerklärte Nicht-Endwerte ablehnen |
| Numerische Abweichung | Beibehaltene Werte | Abweichung zu berechnen | Toleranz vor dem Test festgelegt |
| Anwendungsentscheidung | Klasse oder Aktion | Klasse oder Aktion | Änderungen prüfen |
| Qualität auf dem festen Datensatz | Zu messen | Zu messen | Projektschwelle einhalten |
NaN und übersprungene Aktualisierungen interpretieren
Wenn Nicht-Endwerte auftreten, suchen Sie den ersten Schritt, der sie erzeugt: Eingabe, Zwischenausgabe, Verlust oder Gradient. Spielen Sie denselben Fall als Referenz erneut durch und deaktivieren Sie dann autocast lokal um die verdächtige Operation, wobei Sie auch den Typ ihrer Eingaben kontrollieren. Ein komplettes Training wieder in FP32 auszuführen, kann als Vergleich dienen, lokalisiert das Problem aber nicht automatisch.
Der Scaler kann eine Aktualisierung überspringen, wenn die Gradienten inf oder NaN enthalten. Eine Schleife, die weiterläuft, hat also nicht zwangsläufig so viele Aktualisierungen ausgeführt wie Iterationen. Protokollieren Sie dieses Verhalten während der Diagnose. Lassen Sie eine Lernpolitik, die angeblich den tatsächlichen Aktualisierungen folgt, nicht blind weiterlaufen.
Ein endlicher Verlust garantiert keine endlichen Gradienten. Umgekehrt reicht ein einmaliger Zwischenfall nicht aus, um ein Training als unbrauchbar zu erklären: Untersuchen Sie seine Häufigkeit, den Fortschritt und die Qualität. Das AMP-Rezept bietet eine Methode, um autocast und das Scaling getrennt zu isolieren, wenn eines von beiden verdächtig ist.
Einen reproduzierbaren Rollback vorbereiten
Bewahren Sie vor dem Test die Referenzkonfiguration, die Gewichte, den Zustand des Optimierers und einen konsistenten Checkpoint auf. Wenn Ihr Training einen Scaler verwendet, gehört auch sein Zustand zur Wiederaufnahme. Dokumentieren Sie den dtype und eventuelle Bereiche, die in FP32 belassen wurden. Mit einer anderen Politik fortzufahren, ist eine experimentelle Änderung, die identifiziert werden muss, keine implizit gleichwertige Fortsetzung.
Kehren Sie zur vorherigen Konfiguration zurück, wenn die Ausgaben nicht endlich werden, wenn die Qualität das festgelegte Kriterium verlässt oder wenn die Aktualisierungen nicht mehr nutzbar voranschreiten. Bewahren Sie den Fall auf, der diese Rückkehr veranlasst hat. Beginnen Sie nach einer Änderung den Vergleich erneut auf demselben Datensatz, bevor Sie die Dauer verlängern.
Die Kernodeck-Übung zu Checkpoints prüft eine CPU-Wiederaufnahme ohne AMP. Verwenden Sie ihre Vergleichsmethode erneut und fügen Sie die Zustände hinzu, die Ihre Schleife tatsächlich verbraucht.
Gewinne erst nach der numerischen Validierung messen
Messen Sie nach der Validierung Speicher und Zeit ohne die detaillierte Diagnose. Behalten Sie Formen, Batch, Modell und Qualität bei. Das Auslesen von Skalaren, Synchronisierungen und Profilern kann die Dauern verändern; entfernen Sie intrusive Kontrollen aus der endgültigen Messung.
Unter ROCm bleibt der PyTorch-Gerätename cuda und die entsprechenden Schnittstellen werden weiterverwendet. Das garantiert weder dieselben Kernel noch identische Ergebnisse wie bei NVIDIA. Überprüfen Sie das Backend und die Operatoren des Projekts auf dem Zielsystem. Durch diesen Leitfaden wird keine feste Speicherreduzierung, Geschwindigkeitsvervielfachung oder Kompatibilität der Kernodeck-Vorbereitung zugesagt.