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.
# Einführung in die Modell-Parallelität
Modellparallelität ist eine verteilte Trainingsmethode, bei der das Deep-Learning-Modell auf mehrere Geräte, innerhalb oder zwischen Instances, aufgeteilt wird. Diese Einführungsseite bietet einen allgemeinen Überblick über Modellparallelität, eine Beschreibung, wie sie helfen kann, Probleme zu lösen, die beim Training von DL-Modellen auftreten, die normalerweise sehr groß sind, und Beispiele dafür, was die SageMaker Modellparallel-Bibliothek bietet, um modellparallele Strategien sowie den Speicherverbrauch zu verwalten.
## Was ist Modellparallelität?
Eine Erhöhung der Größe von Deep-Learning-Modellen (Ebenen und Parameter) führt zu einer besseren Genauigkeit bei komplexen Aufgaben wie Computer Vision und Verarbeitung natürlicher Sprache. Die maximale Modellgröße, die Sie in den Speicher einer einzelnen GPU passen können, ist jedoch begrenzt. Beim Training von DL-Modellen können GPU-Speicherbeschränkungen auf folgende Weise zu Engpässen führen:
+ Sie begrenzen die Größe des Modells, das Sie trainieren können, da der Speicherbedarf eines Modells proportional zur Anzahl der Parameter skaliert.
+ Sie begrenzen die Batchgröße pro GPU während des Trainings und verringern so die GPU-Auslastung und die Trainingseffizienz.
Um die Einschränkungen zu überwinden, die mit dem Training eines Modells auf einer einzelnen GPU verbunden sind, SageMaker bietet die Modellparallelbibliothek, mit der DL-Modelle effizient auf mehreren Rechenknoten verteilt und trainiert werden können. Darüber hinaus können Sie mit der Bibliothek ein optimiertes verteiltes Training mit EFA-unterstützten Geräten erreichen, die die Leistung der Kommunikation zwischen den Knoten mit geringer Latenz, hohem Durchsatz und Betriebssystem-Bypass verbessern.
## Schätzen Sie den Speicherbedarf ab, bevor Sie Modellparallelismus verwenden
Bevor Sie die SageMaker Modellparallelbibliothek verwenden, sollten Sie Folgendes berücksichtigen, um sich ein Bild von den Speicheranforderungen beim Training großer DL-Modelle zu machen.
Für einen Trainingsjob, der AMP (FP16) - und Adam-Optimierer verwendet, beträgt der erforderliche GPU-Speicher pro Parameter etwa 20 Byte, die wir wie folgt aufschlüsseln können:
+ Ein FP16 Parameter \$1 2 Byte
+ Ein FP16 Gradient \$1 2 Byte
+ Ein FP32 Optimierungsstatus von \$1 8 Byte, der auf den Adam-Optimierern basiert
+ Eine FP32 Kopie des Parameters \$1 4 Byte (wird für den `optimizer apply` (OA-) Vorgang benötigt)
+ Eine FP32 Kopie von Gradient \$1 4 Byte (wird für die OA-Operation benötigt)
Selbst für ein relativ kleines DL-Modell mit 10 Milliarden Parametern kann es mindestens 200 GB Arbeitsspeicher benötigen, was viel größer ist als der typische GPU-Speicher (z. B. NVIDIA A100 mit 40 GB/80 GB Speicher und V100 mit 16/32 GB), der auf einer einzelnen GPU verfügbar ist. Beachten Sie, dass zusätzlich zu den Speicheranforderungen für Modell- und Optimiererstatus weitere Speicherverbraucher hinzukommen, wie z. B. Aktivierungen, die im Forward-Pass generiert werden. Der benötigte Speicher kann deutlich mehr als 200 GB betragen.
Für verteilte Schulungen empfehlen wir die Verwendung von Amazon EC2 P3- und P4-Instances mit NVIDIA V100 bzw. A100 Tensor Core. GPUs Weitere Informationen zu Spezifikationen wie CPU-Kernen, RAM, angeschlossenem Speichervolumen und Netzwerkbandbreite finden Sie im Abschnitt *Beschleunigtes Rechnen* auf der Seite [Amazon-EC2-Instance-Typen](https://aws.amazon.com/ec2/instance-types/).
Selbst bei den beschleunigte Computing-Instances ist es offensichtlich, dass Modelle mit etwa 10 Milliarden Parametern wie Megatron-LM und T5 und noch größere Modelle mit Hunderten von Milliarden von Parametern wie GPT-3 nicht in jedes GPU-Gerät passen können.
## Wie die Bibliothek Modellparallelität und Speicherspartechniken einsetzt
Die Bibliothek besteht aus verschiedenen Arten von Modellparallelitäts-Features und Features zur Speichereinsparung, z. B. Optimierungszustand-Sharding, Aktivierungsprüfpunkte und Aktivierungs-Offloading. All diese Techniken können kombiniert werden, um große Modelle, die aus Hunderten von Milliarden von Parametern bestehen, effizient zu trainieren.
**Topics**
+ [Sharded Data Parallelität (verfügbar für) PyTorch](#model-parallel-intro-sdp)
+ [PyTorch TensorFlowPipeline-Parallelität (verfügbar für und)](#model-parallel-intro-pp)
+ [Tensorparallelität (verfügbar für) PyTorch](#model-parallel-intro-tp)
+ [PyTorchState-Sharding im Optimizer (verfügbar für)](#model-parallel-intro-oss)
+ [Aktivierung, Offloading und Checkpointing (verfügbar für) PyTorch](#model-parallel-intro-activation-offloading-checkpointing)
+ [Auswahl der richtigen Techniken für Ihr Modell](#model-parallel-intro-choosing-techniques)
### Sharded Data Parallelität (verfügbar für) PyTorch
*Sharded Data Parallelism* ist eine speichersparende verteilte Trainingstechnik, die den Status eines Modells (Modellparameter, Gradienten und Optimiererzustände) innerhalb einer datenparallelen Gruppe aufteilt. GPUs
SageMaker **[KI implementiert Sharded Data Parallelität durch die Implementierung von MICs. Dabei handelt es sich um eine Bibliothek, die die Kommunikation im Maßstab minimiert und im Blogbeitrag Nahezu lineare **Skalierung** des Trainings mit **gigantischen** Modellen erörtert wird. AWS](https://www.amazon.science/blog/near-linear-scaling-of-gigantic-model-training-on-aws)**
Sie können die Parallelität von Sharded-Daten als eigenständige Strategie auf Ihr Modell anwenden. Wenn Sie die leistungsstärksten GPU-Instanzen verwenden, die mit NVIDIA A100 Tensor Core ausgestattet sind, können Sie außerdem die Vorteile der verbesserten Trainingsgeschwindigkeit nutzen GPUs`ml.p4d.24xlarge`, die sich aus dem von SMDDP Collectives angebotenen Betrieb ergibt. `AllGather`
Weitere Informationen zur Sharded-Datenparallelität und zu deren Einrichtung oder Verwendung einer Kombination aus Sharded-Datenparallelität und anderen Techniken wie Tensorparallelität und Training finden Sie unter. FP16 [Parallelität fragmentierter Daten](model-parallel-extended-features-pytorch-sharded-data-parallelism.md)
### PyTorch TensorFlowPipeline-Parallelität (verfügbar für und)
Die *Pipeline-Parallelität* partitioniert den Satz von Ebenen oder Operationen über die gesamte Gruppe von Geräten hinweg, sodass jeder Vorgang intakt bleibt. Wenn Sie einen Wert für die Anzahl der Modellpartitionen (`pipeline_parallel_degree`) angeben, muss die Gesamtzahl von GPUs (`processes_per_host`) durch die Anzahl der Modellpartitionen teilbar sein. Um dies richtig einzurichten, müssen Sie die richtigen Werte für die `pipeline_parallel_degree` und `processes_per_host` Parameter angeben. Die einfache Mathematik lautet wie folgt:
```
(pipeline_parallel_degree) x (data_parallel_degree) = processes_per_host
```
Die Bibliothek berechnet anhand der beiden von Ihnen angegebenen Eingabeparameter die Anzahl der Modellreplikate (auch `data_parallel_degree` genannt).
Wenn Sie beispielsweise eine ML-Instanz mit acht GPU-Workern einrichten `"pipeline_parallel_degree": 2` und `"processes_per_host": 8` verwenden`ml.p3.16xlarge`, richtet die Bibliothek automatisch das verteilte Modell über die Datenparallelität GPUs und die Vierwege-Datenparallelität ein. Die folgende Abbildung zeigt, wie ein Modell auf die acht Bereiche verteilt wird, wodurch eine vierseitige Datenparallelität und eine bidirektionale Pipeline-Parallelität GPUs erreicht wird. Jedes Modellreplikat, in dem wir es als *parallel Pipeline-Gruppe* definieren und es als bezeichnen`PP_GROUP`, ist zweigeteilt. GPUs Jede Partition des Modells ist vier Partitionen zugewiesen GPUs, wobei sich die vier Partitionsreplikate in einer *datenparallelen Gruppe* befinden und als `DP_GROUP` gekennzeichnet sind. Ohne Tensorparallelität ist die Pipeline-Parallelgruppe im Wesentlichen die Modellparallelgruppe.
![\[Wie ein Modell auf die acht Bereiche verteilt wird, sodass eine vierseitige Datenparallelität und eine bidirektionale Pipeline-Parallelität GPUs erreicht werden.\]](http://docs.aws.amazon.com/de_de/sagemaker/latest/dg/images/distributed/model-parallel/smdmp-pipeline-parallel-only.png)
Weitere Informationen zur Pipeline-Parallelität finden Sie unter [Kernfunktionen der SageMaker Model Parallelism Library](model-parallel-core-features.md).
Informationen zu den ersten Schritten beim Ausführen Ihres Modells mithilfe der Pipeline-Parallelität finden Sie unter [Ausführen eines SageMaker verteilten Trainingsjobs mit der SageMaker Model Parallel Library](https://docs.aws.amazon.com/sagemaker/latest/dg/model-parallel-use-api.html).
### Tensorparallelität (verfügbar für) PyTorch
Die *Tensorparallelität* teilt einzelne Schichten, oder `nn.Modules`, auf und kann geräteübergreifend parallel ausgeführt werden. Die folgende Abbildung zeigt das einfachste Beispiel dafür, wie die Bibliothek ein Modell in vier Schichten aufteilt, um eine bidirektionale Tensorparallelität zu erreichen (`"tensor_parallel_degree": 2`). Die Schichten jedes Modellreplikats werden halbiert und in zwei Teile aufgeteilt. GPUs In diesem Beispielfall umfasst die parallel Modellkonfiguration auch `"pipeline_parallel_degree": 1` und `"ddp": True` (verwendet das PyTorch DistributedDataParallel Paket im Hintergrund), sodass der Grad der Datenparallelität acht beträgt. Die Bibliothek verwaltet die Kommunikation zwischen den über Tensor verteilten Modellreplikaten.
![\[Das einfachste Beispiel dafür, wie die Bibliothek ein Modell in vier Schichten aufteilt, um eine bidirektionale Tensorparallelität zu erreichen ("tensor_parallel_degree": 2).\]](http://docs.aws.amazon.com/de_de/sagemaker/latest/dg/images/distributed/model-parallel/smdmp-tensor-parallel-only.png)
Der Nutzen dieser Feature besteht darin, dass Sie bestimmte Ebenen oder eine Teilmenge von Schichten auswählen können, um die Tensorparallelität anzuwenden. Einen tiefen Einblick in die Tensorparallelität und andere speichersparende Funktionen für und um zu erfahren PyTorch, wie man eine Kombination aus Pipeline- und Tensorparallelität einstellt, finden Sie unter. [Tensor-Parallelität](model-parallel-extended-features-pytorch-tensor-parallelism.md)
### PyTorchState-Sharding im Optimizer (verfügbar für)
Um zu verstehen, wie die Bibliothek das *Optimierungszustand-Sharding* durchführt, betrachten Sie ein einfaches Beispielmodell mit vier Ebenen. Die wichtigste Idee bei der Optimierung des State-Shardings besteht darin, dass Sie Ihren Optimizer-Status nicht in allen Ihren Versionen replizieren müssen. GPUs Stattdessen wird ein einzelnes Replikat des Optimisierungsstatus über datenparallele Ränge verteilt, ohne dass Redundanz zwischen Geräten besteht. Beispielsweise enthält GPU 0 den Optimisierungsstatus für Ebene 1, die nächste GPU 1 den Optimisierungsstatus für L2 und so weiter. Die folgende animierte Abbildung zeigt eine Rückwärtsausbreitung mit der Optimierungszustand-Sharding-Technik. Am Ende der Rückwärtsverbreitung stehen Rechen- und Netzwerkzeit für die Operation `optimizer apply` (OA) zur Aktualisierung der Optimisierungszustände und die Operation `all-gather` (AG) zur Aktualisierung der Modellparameter für die nächste Iteration zur Verfügung. Am wichtigsten ist, dass sich der `reduce` Vorgang mit der Berechnung auf GPU 0 überschneiden kann, was zu einer speichereffizienteren und schnelleren Rückwärtsübertragung führt. In der aktuellen Implementierung überschneiden sich AG- und OA-Operationen nicht mit `compute`. Dies kann zu einer längeren Berechnung während des AG-Vorgangs führen, sodass es zu einem Kompromiss kommen kann.
![\[Eine Rückwärtsausbreitung mit der Optimierungszustand-Sharding-Technik.\]](http://docs.aws.amazon.com/de_de/sagemaker/latest/dg/images/distributed/model-parallel/smdmp-optimizer-state-sharding.gif)
Weitere Informationen zur Verwendung dieser Funktion finden Sie unter [Optimierungszustand-Sharding](https://docs.aws.amazon.com/sagemaker/latest/dg/model-parallel-extended-features-pytorch-optimizer-state-sharding.html).
### Aktivierung, Offloading und Checkpointing (verfügbar für) PyTorch
Um GPU-Speicher zu sparen, unterstützt die Bibliothek Aktivierungsprüfpunkte, um zu verhindern, dass interne Aktivierungen für benutzerdefinierte Module während des Forward-Durchlaufs im GPU-Speicher gespeichert werden. Die Bibliothek berechnet diese Aktivierungen während des Rückwärtsdurchlaufs neu. Darüber hinaus verlagert die Feature zum Ablagern der Aktivierung die gespeicherten Aktivierungen auf den CPU-Speicher und lädt sie während des Rücklaufs zurück auf die GPU, um den Speicherbedarf für die Aktivierung weiter zu reduzieren. Weitere Informationen zur Verwendung dieser Features finden Sie unter [Aktivierungsprüfpunkte](https://docs.aws.amazon.com/sagemaker/latest/dg/model-parallel-extended-features-pytorch-activation-checkpointing.html) und [Aktivierungsabladung](https://docs.aws.amazon.com/sagemaker/latest/dg/model-parallel-extended-features-pytorch-activation-offloading.html).
### Auswahl der richtigen Techniken für Ihr Modell
Weitere Informationen zur Auswahl der richtigen Techniken und Konfigurationen finden Sie unter [Bewährte Methoden für SageMaker Distributed Model Parallel](https://docs.aws.amazon.com/sagemaker/latest/dg/model-parallel-best-practices.html) sowie [Tipps und Fallstricke zur Konfiguration](https://docs.aws.amazon.com/sagemaker/latest/dg/model-parallel-customize-tips-pitfalls.html).