Ermöglichen Sie schnelleres Training mit der parallelen Datenbibliothek von Amazon SageMaker | Amazon Web Services

Das Training großer Sprachmodelle (LLM) ist im letzten Jahr mit der Veröffentlichung mehrerer öffentlich verfügbarer Modelle wie Llama2, Falcon und StarCoder immer beliebter geworden. Kunden trainieren jetzt LLMs von beispielloser Größe mit einer Bandbreite von 1 Milliarde bis über 175 Milliarden Parametern. Das Training dieser LLMs erfordert erhebliche Rechenressourcen und Zeit, da Hunderte bis Tausende von Grafikprozessoren (GPUs) verwendet werden müssen, um die heutigen riesigen Trainingsdatensätze und Modellgrößen zu verarbeiten. Ein Engpass beim verteilten Training kann die GPU-Kommunikation sein, die von der NVIDIA Collective Communication Library (NCCL) verwaltet wird. Bei einigen großen verteilten Trainingsjobs kann mehr Zeit für die Kommunikation zwischen GPUs aufgewendet werden als für die eigentliche GPU-Berechnung. Um den GPU-Kommunikationsengpass zu lindern und ein schnelleres Training zu ermöglichen, Amazon Sage Maker freut sich, einen optimierten gemeinsamen AllGather-Betrieb als Teil der SageMaker Distributed Data Parallel Library (SMDDP) ankündigen zu können. AllGather ist die am häufigsten verwendete Sammeloperation in gängigen speichereffizienten Datenparallelitätslösungen wie DeepSpeed ​​Zero Redundancy Optimizer (ZeRO) und Vollständig geteilte Datenparallelität (FSDP)und ist der Hauptverursacher des GPU-Kommunikationsaufwands. In diesem Beitrag zeigen wir einen allgemeinen Überblick darüber, wie SMDDP funktioniert, wie Sie SMDDP in Ihren Amazon SageMaker-Schulungsskripten aktivieren können und welche Leistungsverbesserungen Sie erwarten können.

Lösungsüberblick

Traditionelle Datenparalleles Training beinhaltet die Replikation eines gesamten Modells über mehrere GPUs, wobei jedes Modell auf verschiedenen Datenfragmenten aus dem Datensatz trainiert. Während des Rückwärtsdurchlaufs werden die Gradienten zwischen den GPU-Workern gemittelt, sodass jedes Modellreplikat mit den gleichen Gradientenwerten aktualisiert wird, obwohl es mit unterschiedlichen Daten-Shards trainiert wird. Diese Technik ermöglicht ein viel schnelleres Training für große Datensätze, indem der Verbrauch von Trainingsdaten parallelisiert wird. Allerdings sind einige der heutigen großen Modelle (z. B. Llama2 70B) viel zu groß, um vollständig in den GPU-Speicher zu passen, was die herkömmliche Datenparallelität unbrauchbar macht. Um weiterhin von den Vorteilen der Datenparallelität zu profitieren und gleichzeitig den begrenzten GPU-Speicher zu überwinden, bieten Sharded-Data-Parallellösungen wie DeepSpeed ​​ZeRO, PyTorch FSDP und Amazon SageMaker-Modellparallelismusbibliothek erfreuen sich immer größerer Beliebtheit.

Bei der Shard-Datenparallelität wird das gesamte Modell nicht auf GPU-Workern repliziert, sondern die Modellparameter, Verläufe und Optimiererzustände werden aufgeteilt und auf die GPUs im Trainingsjob verteilt (d. h. fragmentiert). Um Vorwärts- und Rückwärtsdurchlaufberechnungen durchzuführen, werden Parameter von Shards auf anderen GPU-Workern gesammelt, um eine oder mehrere Modellschichten zu bilden. Nachdem die Berechnung durchgeführt wurde, werden diese Schichten aus dem Speicher freigegeben, damit der nächste Satz von Schichten zusammengestellt werden kann. Beachten Sie, dass es Varianten der Shard-Datenparallelität gibt, bei denen nur die Optimiererzustände und -verläufe geshardt werden, nicht jedoch die Modellparameter. AllGather wird bei dieser Art der Shard-Datenparallelität immer noch verwendet, jedoch nur vor der Vorwärtsdurchlaufberechnung, um Modellparameter zu sammeln, die durch verschiedene Gradienten- oder Optimierer-Zustands-Shards von anderen GPU-Workern aktualisiert wurden. Beziehen Sie sich auf die verschiedenen DeepSpeed ​​ZeRO-Stufen und für SHARD_GRAD_OP Weitere Einzelheiten finden Sie in der FSDP-Sharding-Strategie.

Eine gemeinsame AllGather-Operation wird jedes Mal ausgeführt, wenn die Parameter aufgehoben werden. NCCL stellt die standardmäßige Open-Source-Implementierung dieser Routine bereit. Wie im Folgenden gezeigt, beginnt jeder am AllGather beteiligte GPU-Worker mit einem Eingabepuffer und endet mit allen verketteten Eingabepuffern anderer Worker. Wenn AllGather in der Shard-Datenparallelität verwendet wird, enthalten die Eingabepuffer die Modellparameter-Shards und die großen Ausgabepuffer enthalten eine oder mehrere Modellebenen, die aus den anderen Shards materialisiert wurden.

Obwohl NCCL normalerweise für AllGather in verteilten Schulungen verwendet wird, ist die zugrunde liegende Low-Level-Implementierung nicht auf die Netzwerkinfrastruktur von Amazon Elastic Compute Cloud zugeschnitten (Amazon EC2) Instanzen, und daher kann ihre Leistung das End-to-End-Training verlangsamen. Die SMDDP-Bibliothek ist eine kollektive Kommunikationsbibliothek für NVIDIA-GPUs, die als direkter Ersatz für NCCL dient und eine bessere Leistung für verteilte Trainingsjobs mit PyTorch bietet. Insbesondere bietet SMDDP eine optimierte Implementierung von AllGather für p4d/p4de-Instanztypen.

Da kollektive Operationen wie AllGather Vorwärts- und Rückwärtsdurchlaufberechnungen blockieren, führt eine schnellere Ausführung dieser Operationen direkt zu einer kürzeren End-to-End-Trainingszeit ohne Nebenwirkungen auf die Konvergenz. Andere kollektive Vorgänge, die beim parallelen Training mit Sharded-Daten weniger häufig verwendet werden, werden durch einen Rückgriff auf NCCL abgewickelt.

Lösungsweg

AWS-optimiertes AllGather

AWS-optimiertes AllGather nutzt die folgenden Techniken, um im Vergleich zu NCCL eine bessere Leistung auf der AWS-Infrastruktur zu erzielen:

1. Wir verschieben Daten zwischen Instanzen über Elastischer Gewebeadapter (EFA) Netzwerk mit einem All-to-All-Kommunikationsmuster. EFA ist die Netzwerklösung von AWS mit geringer Latenz und hohem Durchsatz. Ein All-to-All-Muster für die Netzwerkkommunikation zwischen Knoten ist besser auf die Eigenschaften von EFA und der Netzwerkinfrastruktur von AWS zugeschnitten, da im Vergleich zum Ring- oder NCCL-Netzwerk weniger Paketsprünge erforderlich sind Baumkommunikationsmuster.
2. DDRKopie zur Koordinierung des lokalen NVLink- und EFA-Netzwerkverkehrs. GDRCopy ist eine Bibliothek, die eine Kommunikation mit geringer Latenz zwischen CPU-Prozessen und GPU-CUDA-Kerneln ermöglicht. Mit dieser Technologie sind wir in der Lage, die Datenbewegung innerhalb und zwischen Knoten zu kanalisieren.
3. Reduzierte Nutzung von GPU-Streaming-Multiprozessoren, um den Modellkernen mehr Rechenleistung zurückzugeben. AWS P4d/P4de-Instanzen sind mit NVIDIA A100-GPUs ausgestattet, von denen jede über 108 Streaming-Multiprozessoren verfügt. Während NCCL bis zu 24 Streaming-Multiprozessoren zur Ausführung von Kollektiven benötigt, nutzen SMDDP-Kollektive nur bis zu neun Streaming-Multiprozessoren. Die gespeicherten Streaming-Multiprozessoren können zur schnelleren Ausführung von Modell-Rechenkernen übernommen werden.

Anwendungsbereich

SMDDP-Kollektive lassen sich nativ in PyTorch integrieren Prozessgruppe Abstraktion in der torch.distributed Modul. Eine Prozessgruppe definiert die Schnittstellen für allgemeine Sammeloperationen wie AllGather, ReduceScatter, AllReduce usw. Benutzer können generischen verteilten Code schreiben und dann den zugrunde liegenden Code auswählen backend, das die Implementierung für diese Vorgänge basierend auf dem verwendeten Rechengerät bereitstellt. CPU-Trainingsjobs verwenden häufig die gloo or mpi Backend, während NVIDIA-GPUs das verwenden nccl Backend.

Die SMDDP-Bibliothek kommt ins Spiel, indem sie sich als benutzerdefiniertes Backend in der Prozessgruppenabstraktion registriert. Dies erfolgt durch die Importanweisung, die in den folgenden Codeausschnitten dargestellt wird. Wenn Sie dann das Backend für Ihren GPU-basierten verteilten Trainingsjob auswählen, ersetzen Sie es einfach nccl mit smddpdem „Vermischten Geschmack“. Seine smddp Das Backend folgt der gleichen Semantik wie das nccl Backend und unterstützt die gleichen Trainingsszenarien.

Tiefgeschwindigkeit

import smdistributed.dataparallel.torch.torch_smddp
deepspeed.init_distributed(dist_backend="smddp") # replacing "nccl"

FSDP

import smdistributed.dataparallel.torch.torch_smddp
dist.init_process_group(backend="smddp")  # replacing "nccl"

Benchmarks

Wir haben die Leistung des eigenständigen AllGather-Geräts verglichen, bei dem der gemeinsame Betrieb isoliert und ohne Modellschulung ausgeführt wird. Unten finden Sie ein Beispielergebnis für 32 p4d-Instanzen, bei denen NCCL und SMDDP AllGather verglichen werden. Die X-Achse stellt die Ausgabegröße von AllGather dar und die Y-Achse stellt die Netzwerkauslastung des 4-Gbit/s-EFA-Netzwerks von p400d dar. Die 4 Unterdiagramme stellen die allgemeinen Kommunikationsgruppenmuster dar, wobei wir jeweils 1, 2, 4 und 8 Ränge pro p4d-Instanz haben, die an der AllGather-Operation teilnimmt.

Diese Mikrobenchmarks zeigen, dass SMDDP NCCL mit zwei Schlüsselmerkmalen übertrifft:

1. Die Spitzenleistung von SMDDP (ca. 90 % Bandbreitenauslastung) ist in allen Konfigurationen höher als die von NCCL (ca. 80 % Bandbreitenauslastung).
2. SMDDP erreicht die Spitzenleistung bei viel kleineren Puffergrößen als NCCL. Dies verbessert insbesondere die Trainingsgeschwindigkeit für kleinere Modelle oder wenn der Benutzer in DeepSpeed ​​​​eine kleine AllGather-Puffergröße festlegt (wobei die AllGather-Größe nicht gleich der Layer-Größe sein muss).

Modelltrainings-Benchmarks

Bei umfangreichen Trainingsaufgaben, bei denen die GPU-Kommunikation einen erheblichen Engpass darstellt, kann SMDDP die Trainingsgeschwindigkeit, gemessen am Modell TFLOPS/GPU, deutlich verbessern.

Konfiguration			Leistung
Modell/Training	Cluster	Sharded-Data-Parallelitätslösung	Modell TFLOPS/GPU mit NCCL	Modell TFLOPS/GPU mit SMDDP	% beschleunigen
13B Lama2 Seq-Länge: 4096 Globale Stapelgröße: 4 Millionen Token	64 p4d.24xlarge-Knoten (512 NVIDIA A100-GPUs)	PyTorch FSDP	97.89	121.85	24.40%
65B GPT-NeoX Seq-Länge: 2048 Globale Stapelgröße: 4 Millionen Token	64 p4d.24xlarge-Knoten (512 NVIDIA A100-GPUs)	DeepSpeed ​​ZeRO Stage 3*	99.23	108.66	9.50%

*EleutherAIs Megatron-DeepSpeed Repository verwendet wurde. Tensorparallelität wurde auch mit einem tensorparallelen Grad von acht ermöglicht.

Hinweis: Das Modell TFLOPS/GPU basiert auf der im Dokument definierten Modell-FLOPS-Nutzungsberechnung hier und Benchmark-Zahlen an anderer Stelle nennen möglicherweise Hardware-TFLOPS/GPU als Leistungsmetrik. Hardware-TFLOPS/GPU kann als 4/3 x Modell-TFLOPS/GPU angenähert werden.

Zusammenfassung

In diesem Beitrag haben wir Ihnen gezeigt, wie Sie parallele Trainingsjobs mit Shard-Daten auf Amazon SageMaker mit nur zwei Codezeilen erheblich beschleunigen können. Groß angelegte, verteilte Schulungen werden mit dem Aufkommen von LLMs immer allgegenwärtiger, doch dieser Umfang bringt hohe Kosten mit sich. Durch die Reduzierung des Kommunikationsengpasses zwischen GPUs hilft Ihnen SMDDP dabei, schneller und skalierbarer zu trainieren und Rechenressourcen einzusparen. Weitere SMDDP-Beispiele mit Sharded-Data-Paralleltraining finden Sie im Amazon SageMaker-Beispiele GitHub-Repository.

---

Über die Autoren

Apoorv Gupta ist Softwareentwicklungsingenieur bei AWS und konzentriert sich auf den Aufbau optimaler Deep-Learning-Systeme für AWS-Infrastruktur und -Hardware. Er interessiert sich für verteiltes Rechnen, Deep-Learning-Systeme und ML-Beschleuniger. Außerhalb der Arbeit reist Apoorv gerne, wandert und spielt gerne Videospiele.

Karan Diman ist Softwareentwicklungsingenieur bei AWS mit Sitz in Toronto, Kanada. Er hat eine große Leidenschaft für den Bereich des maschinellen Lernens und die Entwicklung von Lösungen zur Beschleunigung verteilter Rechenarbeitslasten.

Ruhan Prasad ist ein Softwareentwicklungsingenieur bei AWS, der daran arbeitet, verteiltes Deep-Learning-Training schneller, kostengünstiger und benutzerfreundlicher auf SageMaker zu machen. Außerhalb der Arbeit spielt Ruhan gerne Tennis, reist und kocht.

Zhaoqi Zhu ist Senior Software Development Engineer bei AWS und hat eine Leidenschaft für verteilte Systeme und Low-Level-Optimierungen. Er genießt es, Fußballspiele zu schauen und dabei Limonade (ohne Diät) zu trinken.

• SEO-gestützte Content- und PR-Distribution. Holen Sie sich noch heute Verstärkung.
• PlatoData.Network Vertikale generative KI. Motiviere dich selbst. Hier zugreifen.
• PlatoAiStream. Web3-Intelligenz. Wissen verstärkt. Hier zugreifen.
• PlatoESG. Kohlenstoff, CleanTech, Energie, Umwelt, Solar, Abfallwirtschaft. Hier zugreifen.
• PlatoHealth. Informationen zu Biotechnologie und klinischen Studien. Hier zugreifen.
• Quelle: https://aws.amazon.com/blogs/machine-learning/enable-faster-training-with-amazon-sagemaker-data-parallel-library/