Mixed-Precision-Training: Autocasting, Loss Scaling und numerische Grenzen

Worum es geht

Mixed-Precision-Training kombiniert innerhalb eines Trainingslaufs mehrere Gleitkommaformate. Aufwendige Matrixoperationen können FP16 oder BF16 verwenden, während empfindliche Operationen in FP32 bleiben. Automatic Mixed Precision wählt die Formate anhand von Regeln für Operation und Gerät aus; es entspricht nicht der Umwandlung sämtlicher Tensoren in halbe Genauigkeit. Der Nutzen hängt von Modell, Hardware und Workload ab. [1][2]

Funktionsweise

Autocasting wählt die Genauigkeit pro Operation. Loss Scaling behebt ein davon getrenntes Problem: Sehr kleine FP16-Gradienten können zu null werden. Wird der Loss mit einem Skalierungsfaktor multipliziert, vergrössern sich die Gradienten im Backward-Pass; wird dieser Faktor vor dem Update des Optimizers wieder entfernt, bleibt ihre beabsichtigte Grössenordnung erhalten. Ein dynamischer Scaler erkennt nicht endliche Gradienten, überspringt die betroffenen Optimizer-Updates und passt seinen Skalierungsfaktor an. Er kann nicht jedes numerisch instabile Modell tauglich machen. [1][2]

Praktisches Vorgehen

Zuerst eine FP32-Referenz mit festen Daten und festen Evaluationsregeln erstellen. Beim gewöhnlichen Eager-Training in PyTorch den Forward-Pass und die Loss-Berechnung in torch.autocast einfassen und den Backward-Pass ausserhalb dieses Kontexts ausführen. Bei FP16 gegebenenfalls torch.amp.GradScaler verwenden. Das gesamte Modell nicht von Hand umwandeln, nur um Autocasting zu ermöglichen. [1]

Werden Gradienten begrenzt (Clipping), vorher ihre Skalierung rückgängig machen (Unscaling). Die Methoden step und update des Scalers in der dokumentierten Reihenfolge aufrufen und anschliessend die Gradienten für das nächste Update zurücksetzen. Den Zustand des Scalers zusammen mit Modell und Optimizer in Checkpoints sichern. [2] Bei Gradientenakkumulation einen einzigen Skalierungsfaktor über den gesamten effektiven Batch beibehalten. Kompilierte Ausführung und eigene Operationen erfordern eigene, versionsspezifische Prüfungen der Genauigkeit.

Veranschaulichendes Beispiel

Angenommen sei ein Klassifikator, dessen Laufzeit von Faltungen (Convolutions) dominiert wird, dessen abschliessender Loss aber einen grösseren numerischen Wertebereich benötigt. Autocasting kann geeignete Faltungen in niedrigerer Genauigkeit ausführen und einen unterstützten, empfindlichen Loss in FP32 berechnen. Liefert ein Schritt unendliche Gradienten, kann der Scaler dieses Update überspringen; das ist ein diagnostisches Ereignis und kein Beleg dafür, dass das Training konvergiert ist. Das Beispiel beschreibt Verhalten, keine gemessene Beschleunigung.

Grenzen und Überprüfung

FP16 und BF16 haben unterschiedliche numerische Wertebereiche. Ein für BF16 trainiertes Modell kann in FP16 überlaufen, dessen grösster endlicher Wert 65 504 beträgt. Ein höherer Skalierungsfaktor behebt keinen Überlauf in der Forward-Berechnung. BF16 kommt üblicherweise ohne Gradientenskalierung nach FP16-Art aus, führt aber dennoch Rundungsfehler ein und muss validiert werden. [1]

Validierungsmetriken und Loss-Verläufe mit der FP32-Referenz vergleichen, nicht endliche Werte und übersprungene Updates prüfen sowie Spitzenspeicherbedarf und Durchsatz nach dem Warm-up messen. Kleine oder eingabelimitierte Modelle profitieren möglicherweise kaum. [2] Genauigkeit, Hardware, Softwareversionen und beobachtete Abweichungen angeben. Dieser Artikel berichtet kein eigenes Experiment.

Quellen

[1] PyTorch: Automatic Mixed Precision package [2] PyTorch: Automatic Mixed Precision recipe