Verteilte Schulungen bei Amazon SageMaker - Amazon SageMaker

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Verteilte Schulungen bei Amazon SageMaker

SageMaker bietet verteilte Schulungsbibliotheken und unterstützt verschiedene verteilte Schulungsoptionen für Deep-Learning-Aufgaben wie Computer Vision (CV) und Verarbeitung natürlicher Sprache (NLP). Mit SageMaker den verteilten Trainingsbibliotheken 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 (mpirun) und Parameterserver verwenden. In der gesamten Dokumentation konzentrieren sich Anleitungen und Beispiele darauf, wie die verteilten Trainingsoptionen für Deep-Learning-Aufgaben mithilfe von SageMaker Python eingerichtet SDK 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 SageMaker bewährten Methoden.

Bevor Sie beginnen:

SageMaker Training unterstützt verteilte Schulungen sowohl auf einer einzelnen Instanz als auch auf mehreren Instanzen, sodass Sie Schulungen jeder Größe in großem Umfang durchführen können. Wir empfehlen Ihnen, die Framework-Estimator-Klassen wie PyTorchund TensorFlowin SageMaker Python SDK zu verwenden. Dabei handelt es sich um die Trainingsjob-Starter mit verschiedenen verteilten Trainingsoptionen. Wenn Sie ein Estimator-Objekt erstellen, richtet das Objekt eine verteilte Trainingsinfrastruktur ein, führt die CreateTrainingJob API im Backend aus, sucht nach der Region, in der Ihre aktuelle Sitzung läuft, und ruft einen der vorgefertigten AWS Deep-Learning-Container ab, der mit einer Reihe von Bibliotheken wie Deep-Learning-Frameworks, verteilten Trainingsframeworks und dem Treiber vorkonfiguriert ist. EFA Wenn Sie ein FSx Dateisystem in die Trainingsinstanzen einbinden möchten, müssen Sie Ihr VPC Subnetz und Ihre Sicherheitsgruppen-ID an den Estimator übergeben. Bevor Sie Ihren verteilten Trainingsjob in ausführen SageMaker, lesen Sie die folgenden allgemeinen Hinweise zur grundlegenden Einrichtung der Infrastruktur.

Availability Zones und Netzwerk-Backplane

Wenn Sie mehrere Instanzen (auch Knoten genannt) verwenden, ist es wichtig, das Netzwerk zu verstehen, das die Instanzen verbindet, wie sie die Trainingsdaten lesen und wie sie Informationen untereinander austauschen. Wenn Sie beispielsweise einen verteilten datenparallelen Trainingsjob ausführen, spielen eine Reihe von Faktoren, wie die Kommunikation zwischen den Knoten eines Rechenclusters zur Ausführung des AllReduce Vorgangs und die Datenübertragung zwischen den Knoten und die Datenspeicherung in Amazon Simple Storage Service oder Amazon FSx for Lustre, eine entscheidende Rolle, um eine optimale Nutzung der Rechenressourcen und eine schnellere Trainingsgeschwindigkeit zu erreichen. Um den Kommunikationsaufwand zu reduzieren, stellen Sie sicher, dass Sie Instanzen, VPC Subnetz und Datenspeicher in derselben Availability Zone AWS-Region und in derselben Availability Zone konfigurieren.

GPUInstanzen mit schnellerem Netzwerk und Speicher mit hohem Durchsatz

Sie können technisch gesehen beliebiges Instances für verteilte Trainings verwenden. Für Fälle, in denen Sie verteilte Trainingsjobs mit mehreren Knoten ausführen müssen, um große Modelle wie große Sprachmodelle (LLMs) und Diffusionsmodelle zu trainieren, die eine schnellere Kommutierung zwischen den Knoten erfordern, empfehlen wir EFAGPU-fähige Instances, die von unterstützt werden. SageMaker Insbesondere um die leistungsstärkste verteilte Trainingsaufgabe zu erzielen, empfehlen wir P4d- und SageMaker P4de-Instances, die mit A100 ausgestattet sind. NVIDIA GPUs Diese sind außerdem mit lokalem Instance-Speicher mit hohem Durchsatz und niedriger Latenz sowie schnellerem Knotennetzwerk ausgestattet. Für die Datenspeicherung empfehlen wir Amazon FSx for Lustre, das einen hohen Durchsatz für die Speicherung von Trainingsdatensätzen und Modell-Checkpoints bietet.

Beginnen Sie mit verteilten Schulungen in Amazon SageMaker

Wenn Sie bereits mit verteilten Trainings vertraut sind, wählen Sie zunächst eine der folgenden Optionen, die Ihrer bevorzugten Strategie oder Ihrem bevorzugten Framework entspricht. Weitere Informationen zu verteilten Trainings im Allgemeinen finden Sie unter Grundlegende Konzepte für verteilte Trainings.

Die SageMaker verteilten Schulungsbibliotheken sind für die SageMaker Schulungsumgebung optimiert, helfen Ihnen dabei, Ihre verteilten Schulungsaufgaben an diese SageMaker anzupassen und verbessern die Geschwindigkeit und den Durchsatz der Schulungen. Die Bibliotheken bieten sowohl datenparallele als auch modellparallele Trainingsstrategien. Sie kombinieren Software- und Hardwaretechnologien, um die Kommunikation zwischen GPU und zwischen den Knoten zu verbessern, und erweitern SageMaker die Schulungsmöglichkeiten um integrierte Optionen, die nur minimale Codeänderungen an Ihren Schulungsskripten erfordern. 

Verwenden Sie die Bibliothek für SageMaker verteilte Datenparallelität () SMDDP

Die SMDDP Bibliothek verbessert die Kommunikation zwischen Knoten durch Implementierungen AllReduce und AllGather kollektive Kommunikationsoperationen, die für die AWS Netzwerkinfrastruktur und die Amazon SageMaker ML-Instance-Topologie optimiert sind. Sie können die SMDDPBibliothek als Backend für PyTorch basierte verteilte Trainingspakete verwenden: PyTorch Distributed Data Parallel (DDP), PyTorch Fully Sharded Data Parallelism (FSDP) und Megatron DeepSpeed-. DeepSpeed Das folgende Codebeispiel zeigt, wie Sie einen PyTorch Schätzwert für das Starten eines verteilten Trainingsjobs auf zwei Instanzen einrichten. ml.p4d.24xlarge

from sagemaker.pytorch import PyTorch estimator = PyTorch( ..., instance_count=2, instance_type="ml.p4d.24xlarge", # Activate distributed training with SMDDP distribution={ "pytorchddp": { "enabled": True } } # mpirun, activates SMDDP AllReduce OR AllGather # distribution={ "torch_distributed": { "enabled": True } } # torchrun, activates SMDDP AllGather # distribution={ "smdistributed": { "dataparallel": { "enabled": True } } } # mpirun, activates SMDDP AllReduce OR AllGather )

Informationen zur Vorbereitung Ihres Trainingsskripts und zum Starten einer verteilten datenparallelen Trainingsaufgabe finden Sie SageMaker unterFühren Sie verteilte Schulungen mit der Bibliothek für SageMaker verteilte Datenparallelität durch.

Verwenden Sie die SageMaker Modellparallelitätsbibliothek () SMP

SageMaker stellt die SMP Bibliothek bereit und unterstützt verschiedene verteilte Trainingstechniken wie Sharded Data Parallelism, Pipelining, Tensorparallelismus, Optimizer-State-Sharding und mehr. Weitere Informationen über das Angebot der Bibliothek finden Sie unter. SMP Kernfunktionen der SageMaker Model Parallelism Library

Um die Modellparallelitätsbibliothek zu verwenden SageMaker, konfigurieren Sie die distribution Parameter der SageMaker Framework-Schätzer. Unterstützte Framework-Schätzer sind und. PyTorchTensorFlow Das folgende Codebeispiel zeigt, wie Sie eine Framework-Schätzfunktion für verteilte Trainings mit der Modellparallelitätsbibliothek auf zwei ml.p4d.24xlarge-Instances erstellen.

from sagemaker.framework import Framework distribution={ "smdistributed": { "modelparallel": { "enabled":True, "parameters": { ... # enter parameter key-value pairs here } }, }, "mpi": { "enabled" : True, ... # enter parameter key-value pairs here } } estimator = Framework( ..., instance_count=2, instance_type="ml.p4d.24xlarge", distribution=distribution )

Informationen zum Anpassen Ihres Trainingsskripts, zur Konfiguration von Verteilungsparametern in der estimator Klasse und zum Starten eines verteilten Trainingsjobs finden Sie in SageMakerder Modellparallelismus-Bibliothek (siehe auch Distributed Training APIs in der SageMaker SDKPython-Dokumentation).

Verwenden verteilter Open-Source-Trainingsframeworks

SageMaker unterstützt auch die folgenden Optionen für den Betrieb mpirun und torchrun im Backend.

Grundlegende Konzepte für verteilte Trainings

SageMakerDie verteilten Schulungsbibliotheken verwenden die folgenden Begriffe und Funktionen für verteilte Schulungen.

Datensätze und Batches

  • Trainingsdatensatz: Alle Daten, die Sie zum Trainieren des Modells verwenden.

  • Globale Batchgröße: Die Anzahl der Datensätze, die in jeder Iteration aus dem Trainingsdatensatz ausgewählt wurden, um sie an den 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 verwenden SageMaker, wird jeder Mikrobatch in die Trainingspipeline eingespeist one-by-one 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.

Instanzen und GPUs

  • Instanzen: Eine Recheninstanz für AWS maschinelles Lernen. Diese werden auch als Knoten bezeichnet.

  • Clustergröße: Bei Verwendung SageMaker der verteilten Trainingsbibliothek ist dies die Anzahl der Instanzen multipliziert mit der Anzahl der Instanzen GPUs in jeder Instanz. Wenn Sie beispielsweise zwei ml.p3.8xlarge-Instances in einem Trainingsjob verwenden, die GPUs jeweils 4 haben, beträgt die Clustergröß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 SageMaker verteilte Trainingsbibliothek wurde entwickelt, um die Kommunikation zwischen Amazon EC2 ML-Recheninstanzen zu optimieren, was zu einer höheren Gerätenutzung und schnelleren Trainingszeiten führt.

Lösungen für verteilte Trainings

  • Datenparallelität: Eine Strategie für verteiltes Training, bei der ein Trainingsdatensatz auf mehrere GPUs in einem Rechencluster, der aus mehreren Amazon EC2 ML-Instances besteht, aufgeteilt wird. Jedes Modell GPU enthält ein Replikat des Modells, empfängt unterschiedliche Stapel von Trainingsdaten, führt einen Vorwärts- und Rückwärtslauf durch und teilt Gewichtsupdates zur Synchronisation mit den anderen Knoten, bevor zum nächsten Stapel und letztendlich zu einer anderen Epoche übergegangen wird.

  • Modellparallelität: Eine Strategie für verteiltes Training, bei der das Modell auf mehrere GPUs in einem Rechencluster aufgeteilt ist, der 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. Jedes Modell GPU enthält eine Teilmenge des Modells, über die die Datenflüsse und Transformationen gemeinsam genutzt und kompiliert werden. Die Effizienz der Modellparallelität in Bezug auf GPU Nutzung und Trainingszeit hängt stark davon ab, wie das Modell partitioniert ist und welcher Ausführungsplan für die Durchführung von Vorwärts- und Rückwärtsdurchläufen 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, um eine echte Parallelisierung der Modellparallelität zu erreichen und den Leistungsverlust aufgrund sequentieller Berechnungen zu überwinden, indem die Berechnungen gleichzeitig für verschiedene Datenproben durchgeführt werden. GPUs Weitere Informationen finden Sie unter Pipeline-Ausführungsplan.

Fortgeschrittene Konzepte

Praktiker des 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, es gibt jedoch eine Grenze für die Modellgröße, die Sie in ein einzelnes CPU oder einfügen könnenGPU. 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 () im Mini-Batch-Modus. SGD Beim SGD Mini-Batch-Verfahren 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 sein iteratives 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. 

Datenparallele Daten erfordern SGD immer noch, dass Entwickler in der Lage sind, mindestens das Modell und einen einzelnen Datensatz in ein Computergerät einzupassen, z. B. ein einzelnes CPU oderGPU. Beim Training sehr großer Modelle, wie z. B. großer Transformatoren in der Verarbeitung natürlicher Sprache (NLP) oder Segmentierungsmodellen für Bilder mit hoher Auflösung, 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.

Strategien

Verteilte Trainings werden normalerweise nach zwei Ansätzen aufgeteilt: datenparallel und modellparallel. Datenparallelität ist der gängigste Ansatz für verteiltes Training: Sie haben eine Menge Daten, stapeln sie und senden Datenblöcke an mehrere CPUs oder GPUs (Knoten), um sie vom neuronalen Netzwerk oder dem ML-Algorithmus zu verarbeiten, und kombinieren dann die Ergebnisse. Das neuronale Netzwerk ist auf jedem Knoten dasselbe. Ein modellparalleler Ansatz wird bei großen Modellen verwendet, die nicht in einem Stück in den Speicher eines Knotens passen. Das Modell wird zerlegt, und verschiedene Teile werden auf verschiedenen Knoten platziert. In diesem Fall müssen Sie Ihre Daten-Batches an jeden Knoten senden, damit die Daten in allen Teilen des Modells verarbeitet werden.

Die Begriffe Netzwerk und Modell werden oft synonym verwendet: Ein großes Modell ist in Wirklichkeit ein großes Netzwerk mit vielen Ebenen und Parametern. Beim Training mit einem großen Netzwerk entsteht ein großes Modell, und wenn Sie das Modell mit all Ihren vorab trainierten Parametern und deren Gewichtungen wieder in das Netzwerk laden, wird ein großes Modell in den Speicher geladen. Wenn Sie ein Modell zerlegen, um es auf mehrere Knoten aufzuteilen, zerlegen Sie auch das zugrunde liegende Netzwerk. Ein Netzwerk besteht aus Ebenen, und um das Netzwerk aufzuteilen, platzieren Sie Ebenen auf verschiedenen Datenverarbeitungsgeräten.

Ein häufiger Fallstrick bei der naiven Aufteilung von Schichten auf mehrere Geräte ist die starke Unterauslastung. GPU Das Training ist von Natur aus sequentiell, sowohl in Vorwärts- als auch in Rückwärtsdurchgängen, und zu einem bestimmten Zeitpunkt GPU kann nur einer aktiv rechnen, während die anderen warten, bis die Aktivierungen gesendet werden. Moderne modellparallele Bibliotheken lösen dieses Problem, indem sie Pipeline-Ausführungspläne verwenden, um die Geräteauslastung zu verbessern. Allerdings beinhaltet nur die verteilte Modellparallelbibliothek SageMaker von Amazon die automatische Modellteilung. Die beiden Kernfunktionen der Bibliothek, die automatische Modellaufteilung und die Planung der Pipeline-Ausführung, vereinfachen den Prozess der Implementierung der Modellparallelität, indem automatisierte Entscheidungen getroffen werden, die zu einer effizienten Geräteauslastung führen.

Training mit Datenparallelität und Modellparallelität

Wenn Sie mit einem großen Datensatz trainieren, beginnen Sie mit einem datenparallelen Ansatz. Wenn Ihnen während des Trainings der Speicherplatz ausgeht, sollten Sie zu einem modellparallelen Ansatz wechseln oder eine hybride Modell- und Datenparallelität ausprobieren. Sie können auch Folgendes versuchen, um die Leistung mit Datenparallelität zu verbessern:

  • Ändern Sie die Hyperparameter Ihres Modells.

  • Verringern Sie die Batch-Größe.

  • Verringern Sie die Batch-Größe so lange, bis sie passt. Wenn Sie die Batch-Größe auf 1 verringern und immer noch nicht genügend Arbeitsspeicher zur Verfügung steht, sollten Sie es mit modellparallelem Training versuchen.

Versuchen Sie es mit Gradientenkomprimierung (FP16,INT8):

Versuchen Sie, die Eingabegröße zu reduzieren:

  • Reduzieren Sie die NLP Sequenzlänge, wenn Sie den Sequenz-Link vergrößern, die Stapelgröße nach unten oder nach GPUs oben anpassen müssen, um den Stapel zu verteilen.

  • Verringern der Bildauflösung.

Prüfen Sie, ob Sie die Batch-Normalisierung verwenden, da dies die Konvergenz beeinträchtigen kann. Wenn Sie verteiltes Training verwenden, wird Ihr Stapel aufgeteilt, GPUs und eine viel geringere Batchgröße kann zu einer höheren Fehlerquote führen, wodurch die Konvergenz des Modells gestört wird. Wenn Sie beispielsweise den Prototyp Ihres Netzwerks auf einem einzigen System GPU mit einer Batchgröße von 64 erstellt und dann auf vier p3dn.24xlarge hochskaliert haben, haben Sie jetzt 32 GPUs und Ihre Größe pro Batch sinkt von 64 auf 2. GPU Dadurch wird die Konvergenz, die Sie mit einem einzelnen Knoten hatten, wahrscheinlich durchbrochen.

Beginnen Sie mit dem modellparallelen Training, wenn:

  • Ihr Modell nicht auf ein einzelnes Gerät passt.

  • Aufgrund Ihrer Modellgröße stoßen Sie bei der Auswahl größerer Chargengrößen auf Einschränkungen, z. B. wenn Ihre Modellgewichte den größten Teil Ihres GPU Speichers beanspruchen und Sie gezwungen sind, eine kleinere, suboptimale Chargengröße zu wählen. 

Weitere Informationen zu den SageMaker verteilten Bibliotheken finden Sie im Folgenden:

Optimieren von verteilten Trainings

Passen Sie Hyperparameter an Ihren Anwendungsfall und Ihre Daten an, um die beste Skalierungseffizienz zu erzielen. In der folgenden Diskussion stellen wir einige der wichtigsten Trainingsvariablen vor und stellen Verweise auf state-of-the-art Implementierungen bereit, sodass Sie mehr über Ihre Optionen erfahren können. Wir empfehlen Ihnen außerdem, sich das Trainingsdokumentation Ihres bevorzugten Frameworks anzusehen.

Batch-Größe

SageMaker Mit verteilten Toolkits können Sie in der Regel an größeren Chargen trainieren. Wenn ein Modell beispielsweise in ein einzelnes Gerät passt, aber nur mit einer kleinen Batch-Größe trainiert werden kann, können Sie entweder modellparallele Trainings oder datenparallele Trainings verwenden, um mit größeren Batch-Größen zu experimentieren.

Beachten Sie, dass die Batch-Größe die Modellgenauigkeit direkt beeinflusst, indem sie bei jeder Iteration das Rauschen bei der Modellaktualisierung kontrolliert. Durch eine Erhöhung der Batch-Größe wird das Rauschen bei der Steigungsschätzung reduziert. Dies kann vorteilhaft sein, wenn von sehr kleinen Batch-Größen ausgegangen wird, es kann jedoch zu einer Verschlechterung der Modellgenauigkeit führen, wenn die Batch-Größe auf große Werte ansteigt. 

Tipp

Passen Sie Ihre Hyperparameter an, um sicherzustellen, dass Ihr Modell bei der Erhöhung der Batch-Größe auf eine zufriedenstellende Konvergenz trainiert wird.

Es wurden eine Reihe von Techniken entwickelt, um eine gute Modellkonvergenz aufrechtzuerhalten, wenn der Batch erhöht wird.

Mini-Batch-Größe

Bei SGD dieser Methode quantifiziert die Größe der Mini-Batches das Ausmaß des Rauschens, das bei der Gradientenschätzung vorhanden ist. Ein kleiner Mini-Batch führt zu einer sehr verrauschten Mini-Batch-Steigung, die nicht repräsentativ für die tatsächliche Steigung über den Datensatz hinweg ist. Ein großer Mini-Batch führt zu einer Mini-Batch-Steigung, die der wahren Steigung über den Datensatz hinweg nahe kommt und deren Rauschen möglicherweise nicht stark genug ist – es ist wahrscheinlich, dass sie in irrelevanten Minima verharrt.

Weitere Informationen zu diesen Techniken finden Sie in den folgenden Dokumenten:

Szenarien

In den folgenden Abschnitten werden Szenarien behandelt, in denen Sie das Training möglicherweise erweitern möchten, und wie Sie dies mithilfe von Ressourcen tun können. AWS

Skalierung von einem einzelnen GPU auf viele GPUs

Die Datenmenge oder die Größe des Modells, das beim Machine Learning verwendet wird, können zu Situationen führen, in denen das Training eines Modells länger dauert als Sie warten möchten. Manchmal funktioniert das Training überhaupt nicht, weil das Modell oder die Trainingsdaten zu groß sind. Eine Lösung besteht darin, die Anzahl der Geräte zu erhöhen, die GPUs Sie für Schulungen verwenden. Bei einer Instanz mit mehrerenGPUs, z. B. einer p3.16xlarge Instanz mit achtGPUs, werden die Daten und die Verarbeitung auf die acht aufgeteiltGPUs. Wenn Sie verteilte Trainingsbibliotheken verwenden, kann dies zu einer nahezu linearen Beschleunigung der Zeit führen, die für das Trainieren Ihres Modells benötigt wird. Es dauert etwas mehr als 1/8 der Zeit, die es p3.2xlarge mit einer einzigen GPU Person gedauert hätte.

Instance-Typ GPUs
p3.2xgroß 1
p3.8xgroß 4
p3.16xgroß 8
p3dn.24xgroß 8
Anmerkung

Die beim SageMaker Training verwendeten ML-Instanztypen haben dieselbe Anzahl GPUs wie die entsprechenden p3-Instanztypen. ml.p3.8xlargeHat zum Beispiel dieselbe Anzahl von GPUs wie p3.8xlarge - 4.

Skalieren von einer einzelnen Instance auf mehrere Instances

Wenn Sie Ihr Training noch weiter skalieren möchten, können Sie mehr Instances verwenden. Sie sollten jedoch einen größeren Instance-Typ wählen, bevor Sie weitere Instances hinzufügen. Sehen Sie sich die vorherige Tabelle an, um zu sehen, wie GPUs viele es in jedem p3-Instance-Typ gibt.

Wenn Sie den Sprung von einer auf eine GPU GPUs auf vier bei a p3.2xlarge geschafft habenp3.8xlarge, aber entscheiden, dass Sie mehr Rechenleistung benötigen, können Sie eine bessere Leistung und geringere Kosten erzielen, wenn Sie a wählen, p3.16xlarge bevor Sie versuchen, die Anzahl der Instanzen zu erhöhen. Je nachdem, welche Bibliotheken Sie verwenden, sind die Leistung besser und die Kosten niedriger als bei einem Szenario, in dem Sie mehrere Instances verwenden, wenn Sie das Training auf einer einzelnen Instance fortsetzen.

Wenn Sie bereit sind, die Anzahl der Instanzen zu skalieren, können Sie dies mit der SageMaker SDK estimator Python-Funktion tun, indem Sie Ihre einstelleninstance_count. Sie können beispielsweise instance_type = p3.16xlarge und instance_count = 2 festlegen. Statt der acht GPUs bei einer einzigen stehen p3.16xlarge Ihnen 16 GPUs für zwei identische Instanzen zur Verfügung. Das folgende Diagramm zeigt Skalierung und Durchsatz, angefangen bei acht GPUs auf einer einzelnen Instance bis hin zu 64 Instances, also insgesamt 256GPUs.

Chart showing how throughput increases and time to train decreases with more GPUs.

Benutzerdefinierte Trainingsskripte

SageMaker Das macht es zwar einfach, die Anzahl der Instanzen bereitzustellen und zu skalierenGPUs, und je nach verwendetem Framework kann die Verwaltung der Daten und Ergebnisse sehr schwierig sein, weshalb häufig externe unterstützende Bibliotheken verwendet werden. Diese einfachste Form des verteilten Trainings erfordert eine Änderung Ihres Trainingsskripts, um die Datenverteilung zu verwalten.

SageMaker unterstützt auch Horovod und Implementierungen von verteiltem Training, die für jedes wichtige Deep-Learning-Framework systemspezifisch sind. Wenn Sie sich dafür entscheiden, Beispiele aus diesen Frameworks zu verwenden, können Sie dem Container-Leitfaden für Deep Learning SageMaker Containers und verschiedenen Beispielnotizbüchern folgen, die Implementierungen demonstrieren.