Verteiltes Training in Amazon SageMaker AI
SageMaker AI bietet verteilte Trainingsbibliotheken und unterstützt verschiedene verteilte Trainingsoptionen für Deep-Learning-Aufgaben wie Computer Vision (CV) und natürliche Sprachverarbeitung (NLP). Mit den verteilten Trainingsbibliotheken von SageMaker AI können Sie hochgradig skalierbare und kostengünstige benutzerdefinierte Daten parallel ausführen und parallele Deep-Learning-Trainingsjobs modellieren. Sie können auch andere verteilte Trainingsframeworks und Pakete wie PyTorch DistributedDataParallel (DDP)torchrun, MPI () und Parameterserver verwenden. mpirun Der folgende Abschnitt enthält Informationen über grundlegende Konzepte für verteiltes Training. In der gesamten Dokumentation konzentrieren sich Anweisungen und Beispiele darauf, wie die verteilten Trainingsoptionen für Deep-Learning-Aufgaben mithilfe des SageMaker Python-SDK eingerichtet werden.
Tipp
Bewährte Methoden für verteiltes Computing mit Trainings und Verarbeitung von Aufträgen für Machine Learning (ML) und Datenverarbeitung im Allgemeinen finden Sie unter Verteilte Datenverarbeitung mit den Best Practices von SageMaker AI.
Konzepte für verteiltes Training
Die verteilten Trainingsbibliotheken von SageMaker AI verwenden die folgenden Begriffe und Funktionen für verteiltes Training.
Datensätze und Batches
-
Trainingsdatensatz: Alle Daten, die Sie zum Trainieren des Modells verwenden.
-
Globale Batch-Größe: Die Anzahl der Datensätze, die in jeder Iteration aus dem Trainingsdatensatz ausgewählt werden, um sie an die GPUs im Cluster zu senden. Dies ist die Anzahl der Datensätze, über die die Steigung bei jeder Iteration berechnet wird. Wenn Datenparallelität verwendet wird, entspricht sie der Gesamtzahl der Modellreplikate multipliziert mit der Batch-Größe pro Replikat:
global batch size = (the number of model replicas) * (per-replica batch size). Eine einzelner Batch mit globaler Batch-Größe wird in der Fachliteratur zum Machine Learning oft als Mini-Batch bezeichnet. -
Batch-Größe pro Replikat: Wenn Datenparallelität verwendet wird, ist dies die Anzahl der Datensätze, die an jedes Modellreplikat gesendet werden. Jedes Modellreplikat führt mit diesem Batch einen Vorwärts- und Rückwärtsdurchlauf durch, um Gewichtungsaktualisierungen zu berechnen. Die resultierenden Gewichtungsaktualisierungen werden für alle Replikate synchronisiert (gemittelt), bevor der nächste Satz von Pro-Replikat-Batches verarbeitet wird.
-
Mikro-Batch: Eine Teilmenge des Mini-Batch oder, wenn Hybridmodell und Datenparallelität verwendet werden, eine Teilmenge des Batches mit Größe pro Replikat. Wenn Sie die Bibliothek für verteilte Modellparallelität von SageMaker AI verwenden, wird jeder Mikro-Batch nacheinander in das Trainingspipeline eingespeist und folgt einem Ausführungsplan, der durch die Laufzeit der Bibliothek definiert wird.
Training
-
Epoche: Ein Trainingszyklus durch den gesamten Datensatz. Es ist üblich, mehrere Iterationen pro Epoche durchzuführen. Die Anzahl der Epochen, die Sie beim Training verwenden, hängt von Ihrem Modell und Anwendungsfall ab.
-
Iteration: Ein einziger Vorwärts- und Rückwärtsdurchlauf, der mit einem globalen Batch (einem Mini-Batch) von Trainingsdaten durchgeführt wird. Die Anzahl der während des Trainings durchgeführten Iterationen wird durch die globale Batchgröße und die Anzahl der für das Training verwendeten Epochen bestimmt. Wenn ein Datensatz beispielsweise 5.000 Beispiel umfasst und Sie eine globale Batch-Größe von 500 verwenden, dauert es 10 Iterationen, bis eine einzelne Epoche abgeschlossen ist.
-
Lernrate: Eine Variable, die beeinflusst, wie stark Gewichtungen als Reaktion auf den berechneten Fehler des Modells geändert werden. Die Lernrate spielt eine wichtige Rolle bei der Konvergenzfähigkeit des Modells sowie der Geschwindigkeit und Optimalität der Konvergenz.
Instances und GPUs
-
Instances: Eine AWS Datenverarbeitungs-Instance für Machine Learning
. Diese werden auch als Knoten bezeichnet. -
Cluster-Größe: Bei Verwendung der verteilten Trainingsbibliothek von SageMaker AI ist dies die Anzahl der Instances multipliziert mit der Anzahl der GPUs in jeder Instance. Wenn Sie beispielsweise zwei ml.p3.8xlarge-Instances mit jeweils 4 GPUs in einem Trainingsauftrag verwenden, beträgt die Cluster-Größe 8. Eine Erhöhung der Cluster-Größe kann zwar zu schnelleren Trainingszeiten führen, die Kommunikation zwischen den Instances muss jedoch optimiert werden. Andernfalls kann die Kommunikation zwischen den Knoten einen zusätzlichen Aufwand verursachen und zu langsameren Trainingszeiten führen. Die verteilte Trainingsbibliothek von SageMaker AI wurde entwickelt, um die Kommunikation zwischen Amazon-EC2-ML-Datenverarbeitungs-Instances zu optimieren, was zu einer höheren Geräteauslastung und schnelleren Trainingszeiten führt.
Lösungen für verteilte Trainings
-
Datenparallelität: Eine Strategie für verteilte Trainings, bei der ein Trainingsdatensatz auf mehrere GPUs in einem Datenverarbeitungs-Cluster aufgeteilt wird, das aus mehreren Amazon-EC2-ML-Instances besteht. Jede GPU enthält ein Replikat des Modells, empfängt unterschiedliche Batches von Trainingsdaten, führt einen Vorwärts- und Rückwärtsdurchlauf durch und teilt Gewichtungsaktualisierungen zur Synchronisation mit den anderen Knoten, bevor sie zum nächsten Batch und letztendlich zu einer anderen Epoche übergeht.
-
Modellparallelität: Eine Strategie für verteilte Trainings, bei der das Modell auf mehrere GPUs in einem Datenverarbeitungs-Cluster partitioniert wird, das aus mehreren Amazon-EC2-ML-Instances besteht. Das Modell kann komplex sein und eine große Anzahl von versteckten Ebenen und Gewichtungen aufweisen, sodass es nicht in den Speicher einer einzelnen Instance passt. Jede GPU enthält eine Teilmenge des Modells, über die die Datenabläufe und Transformationen gemeinsam genutzt und kompiliert werden. Die Effizienz der Modellparallelität in Bezug auf die GPU-Auslastung und die Trainingszeit hängt stark davon ab, wie das Modell partitioniert ist und welcher Ausführungsplan die Vorwärts- und Rückwärtsdurchläufe verwendet wird.
-
Pipeline-Ausführungsplan (Pipelining): Der Pipeline-Ausführungsplan bestimmt die Reihenfolge, in der Berechnungen (Mikro-Batches) durchgeführt und Daten während des Modelltrainings geräteübergreifend verarbeitet werden. Pipelining ist eine Technik, mit der eine echte Parallelisierung der Modellparallelität erreicht und der Leistungsverlust aufgrund sequenzieller Berechnungen überwunden werden kann, indem die GPUs gleichzeitig verschiedene Datenstichproben verarbeiten. Weitere Informationen finden Sie unter Pipeline-Ausführungsplan.
Fortgeschrittene Konzepte
Experten für Machine Learning (ML) stehen beim Trainieren von Modellen häufig vor zwei Skalierungsherausforderungen: Skalierung der Modellgröße und Skalierung von Trainingsdaten. Modellgröße und Komplexität können zwar zu einer besseren Genauigkeit führen, die Modellgröße, die in eine einzelne CPU oder GPU passt, ist jedoch begrenzt. Darüber hinaus kann die Skalierung der Modellgröße zu mehr Berechnungen und längeren Trainingszeiten führen.
Nicht alle Modelle können mit der Skalierung von Trainingsdaten gleich gut umgehen, da sie für das Training alle Trainingsdaten im Speicher aufnehmen müssen. Sie skalieren nur vertikal und auf immer größere Instance-Typen. In den meisten Fällen führt die Skalierung von Trainingsdaten zu längeren Trainingszeiten.
Deep Learning (DL) ist eine spezielle Familie von ML-Algorithmen, die aus mehreren Ebenen künstlicher neuronaler Netze besteht. Die gängigste Trainingsmethode ist Stochastic Gradient Descent (SGD) im Mini-Batch-Modus. Beim Mini-Batch-SGD wird das Modell trainiert, indem kleine iterative Änderungen seiner Koeffizienten in die Richtung vorgenommen werden, die seinen Fehler reduziert. Diese Iterationen werden an gleich großen Teilproben des Trainingsdatensatzes durchgeführt, die als Mini-Batches bezeichnet werden. Für jeden Mini-Batch wird das Modell in jedem Datensatz des Mini-Batches ausgeführt, wobei der Fehler gemessen und die Steigung des Fehlers geschätzt wird. Anschließend wird die durchschnittliche Steigung in allen Datensätzen des Mini-Batches gemessen und gibt eine Aktualisierungsrichtung für jeden Modellkoeffizienten vor. Ein vollständiger Durchlauf des Trainingsdatensatzes wird als Epoche bezeichnet. Modelltrainings bestehen üblicherweise aus Dutzenden bis Hunderten von Epochen. Mini-Batch-SGD hat mehrere Vorteile: Erstens sorgt das iterative Design dafür, dass die Trainingszeit theoretisch linear zur Datensatzgröße verläuft. Zweitens wird in einem bestimmten Mini-Batch jeder Datensatz einzeln vom Modell verarbeitet, ohne dass außer dem endgültigen Steigungsdurchschnitt eine Kommunikation zwischen den Datensätzen erforderlich ist. Die Verarbeitung eines Mini-Batches eignet sich daher besonders für die Parallelisierung und Verteilung.
Die Parallelisierung des SGD-Trainings durch Verteilung der Datensätze eines Mini-Batches auf verschiedene Computergeräte wird als datenparalleles verteiltes Training bezeichnet und ist das am häufigsten verwendete DL-Verteilungsparadigma. Datenparalleles Training ist eine wichtige Verteilungsstrategie, um die Größe der Mini-Batches zu skalieren und jeden Mini-Batch schneller zu verarbeiten. Datenparalleles Training bringt jedoch die zusätzliche Komplexität mit sich, dass der Steigungsdurchschnitt für Mini-Batches mit Steigungen von allen Auftragnehmern berechnet und an alle Auftragnehmer weitergegeben werden muss. Dieser Schritt wird allreduce genannt und kann einen wachsenden Mehraufwand bedeuten, da der Trainingscluster skaliert wird, was auch die Trainingszeit drastisch beeinträchtigen kann, wenn er falsch implementiert oder über unsachgemäße Hardware-Subtraktionen implementiert wird.
Datenparalleles SGD erfordert zudem, dass Entwickler in der Lage sind, mindestens das Modell und einen einzelnen Datensatz in ein Computergerät zu integrieren, z. B. eine einzelne CPU oder GPU. Beim Training sehr großer Modelle, wie z. B. großer Transformatoren bei Modellen der natürlichen Sprachverarbeitung (NLP) oder bei Segmentierungsmodellen für hochauflösende Bilder, kann es Situationen geben, in denen dies nicht möglich ist. Eine alternative Möglichkeit, die Workload aufzuteilen, besteht darin, das Modell auf mehrere Computergeräte zu partitionieren. Dieser Ansatz wird als modellparalleles verteiltes Training bezeichnet.