Zusätzliche Anleitungen für die Trainingspipeline

In diesem Abschnitt wird die Trainingspipeline beschrieben.

Eingabepipeline optimieren

Zusammenfassung: Die Ursachen und Maßnahmen für eingabegebundene Pipelines sind stark aufgabenabhängig. Verwenden Sie ein Profiler-Tool und achten Sie auf häufige Probleme.

Verwenden Sie ein geeignetes Profiler-Tool, z. B. eines der folgenden, um eingabebeschränkte Pipelines zu diagnostizieren:

• Perfetto für JAX
• TensorFlow-Profiler für TensorFlow.

Letztendlich hängen die spezifischen Ursachen und Maßnahmen stark von der jeweiligen Aufgabe ab. Allgemeine technische Überlegungen (z. B. Minimierung des Speicherplatzbedarfs) können die Leistung der Eingabepipeline beeinträchtigen.

Häufige Ursachen für eingabebeschränkte Pipelines:

• Die Daten befinden sich nicht am selben Ort wie der Trainingsprozess, was zu E/A-Latenz führt. Wenn Sie beispielsweise Trainingsdaten über ein Netzwerk lesen, kann dies zu E/A-Latenz führen.
• Aufwendige Online-Datenvorverarbeitung. Sie können die Vorverarbeitung einmal offline durchführen und die Ergebnisse speichern.
• Unbeabsichtigte Synchronisierungsbarrieren, die das Prefetching von Datenpipelines beeinträchtigen. Beispiel: Synchronisieren von Messwerten zwischen dem Gerät und dem Host in CommonLoopUtils.

Wir empfehlen die folgenden Maßnahmen für eingabegebundene Pipelines:

• Instrumentieren Sie die Eingabepipeline, um Beispiele vorab abzurufen (z. B. tf.data.Dataset.prefetch).
• Entfernen Sie nicht verwendete Funktionen und Metadaten so früh wie möglich aus jeder Pipeline.
• Erhöhen Sie die Replikation der Anzahl der Jobs, die Beispiele für die Eingabepipeline generieren, z. B. mit dem tf.data-Dienst.

Modellleistung bewerten

Zusammenfassung: Führen Sie die Auswertung mit größeren Batchgrößen als beim Training durch. Führen Sie Auswertungen in regelmäßigen Schrittintervallen und nicht in regelmäßigen Zeitintervallen durch.

Bewertungseinstellungen

Mit den folgenden Einstellungen können Sie die Leistung Ihrer Modelle bewerten:

• Onlinebewertung: Erfassen Sie Messwerte, wenn das Modell Vorhersagen in einer Produktionsumgebung bereitstellt. Die Online-Bewertung bietet in der Regel die realistischste Einschätzung der Modellqualität, da sie der Art und Weise entspricht, wie das Modell verwendet wird.
• Offline-Bewertung: Erfassen Sie Messwerte, wenn das Modell für das Offline-Training, die Validierung oder die Test-Sets ausgeführt wird, die repräsentativ für die Produktionsumgebung sind. Je nach Problem kann die Offline-Bewertung recht aufwendig und rechenintensiv sein.
• Regelmäßige Auswertungen: Erheben Sie während des Modelltrainings Messwerte, die möglicherweise als Proxy für die Offline-Auswertung dienen, und/oder für eine Teilmenge der Daten, die bei der Offline-Auswertung verwendet werden. Regelmäßige Auswertungen sind die praktischste und kostengünstigste Option, stellen die Produktionsumgebung aber möglicherweise nicht vollständig dar. Verwenden Sie einen geeigneten Proxy für die Offline-Bewertung, ohne die Zuverlässigkeit des Signals zu beeinträchtigen, das während des Trainings empfangen wird.

Regelmäßige Bewertungen einrichten

Wir empfehlen, während des Trainings regelmäßige Auswertungen durchzuführen, aus folgenden Gründen:

• Trainingsfortschritt in Echtzeit überwachen
• Um die nachträgliche Auswahl von Modellprüfpunkten zu erleichtern.
• Trainingskurven am Ende des Trainings ansehen

Die einfachste Konfiguration besteht darin, sowohl das Training als auch die regelmäßigen Bewertungen auf derselben Compute-Instanz durchzuführen und regelmäßig zwischen Training und Bewertung zu wechseln. In diesem Fall sollte die Batchgröße, die für die Auswertung verwendet wird, mindestens so groß sein wie die Batchgröße, die für das Training verwendet wird. Das liegt daran, dass Sie während der Evaluierung keine Modellaktivierungen aufrechterhalten müssen, was die Rechenanforderungen pro Beispiel senkt.

Führen Sie regelmäßige Bewertungen in regelmäßigen Schrittintervallen und nicht in Zeitintervallen durch. Die Auswertung anhand von Zeitintervallen kann die Interpretation der Trainingskurven erschweren, insbesondere wenn das Training durch Unterbrechungen der Trainingsjobs, Probleme mit der Netzwerklatenz usw. beeinträchtigt wird.

Periodizität bei Validierungs- und Testmesswerten (bei Verwendung einer zufälligen Aufteilung in Trainings-, Validierungs- und Test-Dataset) kann auf Implementierungsfehler hinweisen, z. B.:

• Testdaten überschneiden sich mit Trainingsdaten.
• Die Trainingsdaten werden nicht richtig gemischt.

Wenn Sie die Leistung in regelmäßigen Abständen bewerten, lassen sich diese Probleme leichter erkennen.

Teilweise Batches können auftreten, wenn die Evaluierungssätze nicht durch die Batchgröße teilbar sind. Achten Sie darauf, dass die aufgefüllten Beispiele richtig gewichtet werden (wie beim gewichteten Durchschnitt über Beispiele zur Berechnung des durchschnittlichen Verlusts über den Batch hinweg), damit die Verlustfunktion nicht durch sie beeinflusst wird. Häufig können Sie diesen aufgefüllten Beispielen ein Gewicht von null zuweisen.

Speichern Sie genügend Informationen pro Auswertung, um Offlineanalysen zu ermöglichen. Speichern Sie Vorhersagen idealerweise für eine Auswahl einzelner Beispiele, da sie für das Debugging von unschätzbarem Wert sein können. Durch das Generieren von Artefakten wie SavedModels wird die Ad-hoc-Modellprüfung nach Abschluss von Bewertungsjobs vereinfacht.

Stichprobe für die regelmäßige Auswertung auswählen

Der regelmäßige Bewertungsjob wird möglicherweise nicht schnell genug ausgeführt, um Messwerte für den vollständigen Offline-Bewertungssatz in angemessener Zeit zu berechnen. Bei diesem Problem müssen häufig Daten für die regelmäßige Auswertung erhoben werden. Berücksichtigen Sie beim Erstellen eines Datasets mit Stichproben Probleme mit der Stichprobengröße und besondere Aspekte bei unausgewogenen Datasets.

Stichprobengröße

Prüfen Sie, ob die Leistung, die für das vom periodischen Job verwendete Stichprobendataset berechnet wurde, mit der Leistung für das gesamte Offline-Bewertungsset übereinstimmt. Das bedeutet, dass es keine Abweichung zwischen dem Stichprobendataset und dem vollständigen Dataset geben darf.

Das Dataset, das Sie für die regelmäßige Bewertung verwenden, sollte beides sein:

• Klein genug, um problemlos Modellvorhersagen für den gesamten Zeitraum zu generieren.
• Sie muss groß genug sein, um die folgenden beiden Anforderungen zu erfüllen:
  • Verbesserungen am Modell genau messen. Die Messungen sollten nicht durch Label-Rauschen beeinträchtigt werden.
  • Mehrere solcher Bewertungen in Folge in den Tests berücksichtigen und trotzdem genaue Schätzungen erstellen. Das heißt, groß genug, um zu vermeiden, dass das Modell im Laufe der Zeit adaptiv an das Validierungs-Dataset angepasst wird, sodass es nicht auf ein zurückgehaltenes Test-Dataset verallgemeinert werden kann. Diese Überlegung ist jedoch selten ein praktisches Problem.

Unausgeglichene Datasets

Bei unausgewogenen Datasets ist die Leistung bei seltenen Minderheitenklassen oft verrauscht. Bei Datasets mit nur einer kleinen Anzahl von Minderheitsbeispielen sollten Sie die Anzahl der korrekt vorhergesagten Beispiele protokollieren, um mehr Einblick in die Genauigkeitsverbesserungen zu erhalten. Eine Verbesserung der Sensitivität um 0,05 klingt vielversprechend, aber lag die Verbesserung nur daran, dass ein weiteres Beispiel richtig war?

Prüfpunkte speichern und nachträglich den besten Prüfpunkt auswählen

Zusammenfassung: Führen Sie das Training für eine feste Anzahl von Schritten aus und wählen Sie nachträglich den besten Checkpoint aus dem Lauf aus.

Die meisten Deep-Learning-Frameworks unterstützen Modell-Checkpoints. Das bedeutet, dass der aktuelle Status des Modells regelmäßig auf der Festplatte gespeichert wird. Durch das Erstellen von Prüfpunkten kann der Trainingsjob Unterbrechungen der Compute-Instanz überstehen. Der beste Prüfpunkt ist oft nicht der letzte, insbesondere wenn die Leistung des Validierungssatzes nicht weiter steigt, sondern um einen bestimmten Wert schwankt.

Richten Sie die Pipeline so ein, dass die N besten Prüfpunkte, die bisher während des Trainings gesehen wurden, im Blick behalten werden. Am Ende des Trainings bedeutet die Modellauswahl einfach, den besten Prüfpunkt auszuwählen. Diesen Ansatz nennen wir retrospektive optimale Prüfpunktauswahl. Die Unterstützung für vorzeitiges Beenden ist in der Regel nicht erforderlich, da Sie ein Testbudget vorab festlegen und die N besten bisherigen Prüfpunkte beibehalten.

Test-Tracking einrichten

Zusammenfassung: Wenn Sie verschiedene Tests durchführen, sollten Sie einige wichtige Aspekte im Blick behalten, z. B. die beste Leistung eines Prüfpunkts in der Studie und eine kurze Beschreibung der Studie.

Wir empfehlen, die Testergebnisse in einer Tabelle zu erfassen. Unsere Tabellen enthalten häufig die folgenden Spalten:

• Name der Studie
• Ein Link zum Speicherort der Konfiguration für die Studie.
• Notizen oder eine kurze Beschreibung der Studie.
• Anzahl der durchgeführten Tests
• Leistung des besten Prüfpunkts in der Studie im Validierungs-Dataset.
• Spezifische Befehle zum Reproduzieren oder Hinweise dazu, welche nicht eingereichten Änderungen für den Start des Trainings erforderlich waren.

Suchen Sie nach einem geeigneten Tracking-System, das mindestens die oben aufgeführten Informationen erfasst. Nicht erfasste Tests sind praktisch nicht vorhanden.

Details zur Implementierung der Batchnormalisierung

Zusammenfassung: Heutzutage können Sie Batchnormierung oft durch LayerNorm ersetzen. Wenn das nicht möglich ist, müssen Sie beim Ändern der Batchgröße oder der Anzahl der Hosts einige wichtige Details beachten.

Bei der Batchnormalisierung werden Aktivierungen anhand ihres Mittelwerts und ihrer Varianz im aktuellen Batch normalisiert. Bei der Verwendung mehrerer Geräte unterscheiden sich diese Statistiken jedoch auf jedem Gerät, sofern sie nicht explizit synchronisiert werden. Anekdotische Berichte (hauptsächlich zu ImageNet) deuten darauf hin, dass die Berechnung dieser Normalisierungsstatistiken mit nur etwa 64 Beispielen in der Praxis tatsächlich besser funktioniert. (Siehe die Beschreibung der Ghost Batch Normalization in Train longer, generalize better: closing the generalization gap in large batch training of neural networks.) Die Entkopplung der Gesamtbatchgröße und der Anzahl der Beispiele, die zum Berechnen der Batchnorm-Statistiken verwendet werden, ist besonders nützlich für den Vergleich von Batchgrößen.

Ghost-Batch-Normalisierungsimplementierungen verarbeiten den Fall, in dem die Batchgröße pro Gerät größer als die virtuelle Batchgröße ist, nicht immer korrekt. In diesem Fall müssen Sie den Batch auf jedem Gerät unterteilen, um die richtige Anzahl von Beispielen für die Batchnorm-Statistik zu erhalten.

Die exponentiellen gleitenden Durchschnitte (EMAs), die in der Batch-Normalisierung im Testmodus verwendet werden, sind nur eine lineare Kombination von Trainingsstatistiken. Daher müssen Sie diese EMAs nur synchronisieren, bevor Sie sie in Checkpoints speichern. Bei einigen gängigen Implementierungen der Batchnormalisierung werden diese EMAs jedoch nicht synchronisiert und nur der EMA des ersten Geräts wird gespeichert.

Überlegungen zu Pipelines mit mehreren Hosts

Zusammenfassung: Beim Logging, bei der Auswertung, bei Zufallszahlengeneratoren, beim Checkpointing und beim Data Sharding kann es beim Training auf mehreren Hosts sehr leicht zu Fehlern kommen.

Führen Sie für Pipelines mit mehreren Hosts die folgenden Schritte aus:

• Achten Sie darauf, dass die Pipeline nur auf einem Host protokolliert und Prüfpunkte erstellt.
• Synchronisieren Sie Batch-Normalisierungsstatistiken auf allen Hosts vor der Auswertung oder dem Speichern von Checkpoints.
• Shard-Datendateien sollten auf mehrere Hosts verteilt werden, da dies in der Regel die Leistung verbessert.

Kritisch:Achten Sie darauf, dass Sie RNG-Seeds haben, die auf allen Hosts gleich sind (für die Modellinitialisierung), und Seeds, die auf allen Hosts unterschiedlich sind (für das Mischen/die Vorverarbeitung von Daten). Markieren Sie sie daher entsprechend.