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 und 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, bietet SageMaker 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 beachten, um sich ein Bild von den Speicheranforderungen beim Training großer DL-Modelle zu machen.

Für einen Trainingsauftrag, der AMP (FP16)- und Adam-Optimierer verwendet, beträgt der erforderliche GPU-Speicher pro Parameter etwa 20 Byte, den wir wie folgt aufschlüsseln können:

• Ein FP16-Parameter ~ 2 Byte

• Ein FP16-Gradient ~ 2 Byte

• Ein FP32-Optimierer-Status ~ 8 Byte, der auf den Adam-Optimierern basiert

• Eine FP32-Kopie des Parameters ~ 4 Byte (wird für den optimizer apply (OA-) Vorgang benötigt)

• Eine FP32-Kopie des Gradienten ~ 4 Byte (wird für den OA-Vorgang 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 Trainings 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.

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.

Sharded-Datenparallelität (verfügbar für PyTorch)

Sharded-Datenparallelität ist eine speichersparende verteilte Trainingstechnik, die den Status eines Modells (Modellparameter, Gradienten und Optimiererzustände) auf GPUs innerhalb einer datenparallelen Gruppe aufteilt.

SageMaker implementiert Sharded-Datenparallelität durch die Implementierung von MICs. Dabei handelt es sich um eine Bibliothek, die die Kommunikation der Skala minimiert und im Blogbeitrag Nahezu lineare Skalierung von gigantischen Modellen beim Training auf AWS erörtert wurde.

Sie können die Parallelität von Sharded-Daten als eigenständige Strategie auf Ihr Modell anwenden. Wenn Sie die leistungsstärksten GPU-Instances verwenden, die mit NVIDIA A100 Tensor Core-GPUs ausgestattet sind, ml.p4d.24xlarge, können Sie außerdem die Vorteile der verbesserten Trainingsgeschwindigkeit nutzen, die sich aus dem von SMDP Collectives angebotenen AllGather Betrieb ergibt.

Weitere Informationen zur Sharded-Datenparallelität und zu deren Einrichtung oder Verwendung einer Kombination aus Sharded-Datenparallelität und anderen Techniken wie Tensorparallelismus und FP16-Training finden Sie unter Parallelität fragmentierter Daten.

Pipeline-Parallelität (verfügbar für PyTorch und TensorFlow)

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 der 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-Instance mit acht GPU-Workern einrichten "pipeline_parallel_degree": 2 und "processes_per_host": 8 zu verwenden, wie z. B. ml.p3.16xlarge, richtet die Bibliothek automatisch das verteilte Modell über die GPUs und die vierfache Datenparallelität ein. Die folgende Abbildung zeigt, wie ein Modell auf die acht GPUs verteilt ist, wodurch eine vierseitige Datenparallelität und eine bidirektionale Pipeline-Parallelität erreicht wird. Jedes Modellreplikat, in dem wir es als Pipeline-Parallelgruppe definieren und als PP_GROUP beschriften, ist auf zwei GPUs partitioniert. Jede Partition des Modells ist vier GPUs zugewiesen, wobei sich die vier Partitionsreplikate in einer Paralleldaten-Gruppe befinden und als DP_GROUP gekennzeichnet sind. Ohne Tensorparallelität ist die Pipeline-Parallelgruppe im Wesentlichen die Modellparallelgruppe.

Weitere Informationen zur Pipeline-Parallelität finden Sie unter Kernfunktionen der SageMaker Model Parallelism Library.

Informationen zu den ersten Schritten beim Ausführen Ihres Modells mithilfe der Pipeline-Parallelität finden Sie unter Ausführen eines verteilten SageMaker-Trainingsauftrags mit der SageMaker Parallelitätsmodel Bibliothek.

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 auf zwei GPUs verteilt. In diesem Beispielfall beinhaltet 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.

Der Nutzen dieser Feature besteht darin, dass Sie bestimmte Ebenen oder eine Teilmenge von Schichten auswählen können, um die Tensorparallelität anzuwenden. Weitere Informationen zur Tensorparallelität und anderen speichersparenden Features für PyTorch sowie zum Einstellen einer Kombination aus Pipeline- und Tensorparallelität finden Sie unter Tensor-Parallelität.

Optimierungszustand-Sharding (verfügbar für PyTorch)

Um zu verstehen, wie die Bibliothek das Optimierungszustand-Sharding durchführt, betrachten Sie ein einfaches Beispielmodell mit vier Ebenen. Die wichtigste Idee bei dem Optimierungszustand-Sharding ist, dass Sie Ihren Optimisierungsstatus nicht in allen Ihren GPUs replizieren müssen. 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.

Weitere Informationen zur Verwendung dieser Funktion finden Sie unter Optimierungszustand-Sharding.

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 und Aktivierungsabladung.

Auswahl der richtigen Techniken für Ihr Modell

Weitere Informationen zur Auswahl der richtigen Techniken und Konfigurationen finden Sie unter SageMaker verteiltes Parallelmodel Best Practices und Konfigurationstipps und Fallstricke.