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.
# Kernfunktionen der SageMaker Model Parallelism Library
Die Modellparallelismus-Bibliothek von Amazon SageMaker AI bietet Verteilungsstrategien und Techniken zur Speichereinsparung, wie z. B. Shard-Datenparallelität, Tensorparallelität, Modellpartitionierung nach Ebenen für die Pipeline-Planung und Checkpointing. Die Strategien und Techniken zur Modellparallelität helfen dabei, große Modelle auf mehrere Geräte zu verteilen und dabei das Trainingsgeschwindigkeit und die Speichernutzung zu optimieren. Die Bibliothek bietet auch Python-Hilfsfunktionen, Kontextmanager und Wrapper-Funktionen, mit denen Sie Ihr Trainingsskript für die automatisierte oder manuelle Partitionierung Ihres Modells anpassen können.
Wenn Sie Modellparallelität in Ihren Trainingsjob implementieren, behalten Sie denselben zweistufigen Arbeitsablauf bei, der im Abschnitt [Einen SageMaker verteilten Trainingsjob mit Modellparallelität ausführen](https://docs.aws.amazon.com/sagemaker/latest/dg/model-parallel-use-api.html) beschrieben ist. Um Ihr Trainingsskript anzupassen, fügen Sie zu Ihrem Trainingsskript keine oder nur wenige zusätzliche Zeilen Code hinzu. Um anhand des angepassten Trainingsskripts einen Trainingsauftrag zu starten, müssen Sie die Konfigurationsparameter für die Verteilung festlegen, um die speichersparenden Funktionen zu aktivieren oder um Werte für den Parallelitätsgrad zu übergeben.
Beispiele für den Einstieg finden Sie in den folgenden Jupyter-Notebooks, in denen die Verwendung der Modellparallelismus-Bibliothek veranschaulicht wird. SageMaker
+ [PyTorch Beispiel-Notebooks](https://github.com/aws/amazon-sagemaker-examples/tree/main/training/distributed_training/pytorch/model_parallel)
+ [TensorFlow Beispiel Notizbücher](https://github.com/aws/amazon-sagemaker-examples/tree/main/training/distributed_training/tensorflow/model_parallel/mnist)
Weitere Informationen zu den Kernfunktionen der Bibliothek finden Sie in den folgenden Themen.
**Anmerkung**
Die SageMaker verteilten Schulungsbibliotheken sind über die AWS Deep-Learning-Container für PyTorch Hugging Face und TensorFlow innerhalb der SageMaker Trainingsplattform verfügbar. Um die Funktionen der verteilten Trainingsbibliotheken nutzen zu können, empfehlen wir die Verwendung des SageMaker Python-SDK. Sie können die Konfiguration auch manuell in der JSON-Anforderungssyntax vornehmen, wenn SageMaker APIs Sie das SDK for Python (Boto3) oder verwenden. AWS Command Line Interface In der gesamten Dokumentation konzentrieren sich Anweisungen und Beispiele auf die Verwendung der verteilten Trainingsbibliotheken mit dem SageMaker Python-SDK.
**Wichtig**
Die SageMaker Modellparallelitätsbibliothek unterstützt alle Kernfunktionen von und unterstützt Pipeline-Parallelität für PyTorch. TensorFlow
**Topics**
+ [Parallelität fragmentierter Daten](model-parallel-extended-features-pytorch-sharded-data-parallelism.md)
+ [Modell-Pipelining](model-parallel-core-features-pipieline-parallelism.md)
+ [Tensor-Parallelität](model-parallel-extended-features-pytorch-tensor-parallelism.md)
+ [Optimizer-Zustandsfragmentierung](model-parallel-extended-features-pytorch-optimizer-state-sharding.md)
+ [Aktivierungs-Prüfpunkte](model-parallel-extended-features-pytorch-activation-checkpointing.md)
+ [Aktivierungs-Entladung](model-parallel-extended-features-pytorch-activation-offloading.md)
+ [FP16 Training mit Modellparallelität](model-parallel-extended-features-pytorch-fp16.md)
+ [Support für FlashAttention](model-parallel-attention-head-size-for-flash-attention.md)
# Parallelität fragmentierter Daten
*Sharded Data Parallelism* ist eine speichersparende verteilte Trainingstechnik, die den Status eines Modells (Modellparameter, Gradienten und Optimiererzustände) in einer datenparallelen Gruppe aufteilt. GPUs
**Anmerkung**
Sharded Data Parallelism ist in der Modellparallelismus-Bibliothek v1.11.0 und höher verfügbar. PyTorch SageMaker
Wenn Sie Ihren Trainingsjob auf einen großen GPU-Cluster skalieren, können Sie den Speicherbedarf des Modells pro GPU reduzieren, indem Sie den Trainingsstatus des Modells auf mehrere verteilen. GPUs Dies hat zwei Vorteile: Sie können größere Modelle einsetzen, denen sonst bei standardmäßiger Datenparallelität der Speicher ausgehen würde, oder Sie können mithilfe des freigewordenen GPU-Speichers die Batch-Größe erhöhen.
Die Standardtechnik für Datenparallelität repliziert die Trainingszustände GPUs in der Gruppe der Datenparallelen und führt auf der Grundlage der Operation eine Gradientenaggregation durch. `AllReduce` Die Parallelität fragmentierter Daten modifiziert das Standard-Trainingsverfahren mit verteilten, parallelen Daten, um der fragmentierten Natur der Optimierer-Zustände Rechnung zu tragen. Eine Gruppe von Rängen, über die die Zustände des Modells und des Optimierers fragmentiert werden, wird als *Fragmentierungsgruppe* bezeichnet. *Bei der Technik der Datenparallelität werden die trainierbaren Parameter eines Modells und die entsprechenden Gradienten und Optimierungszustände in der Sharding-Gruppe aufgeteilt. GPUs *
SageMaker [KI erreicht Sharded Data Parallelität durch die Implementierung von MICs, was im Blogbeitrag Near-linear scaling of gigantic-model training on behandelt wird. AWSAWS](https://www.amazon.science/blog/near-linear-scaling-of-gigantic-model-training-on-aws) In dieser Implementierung können Sie den Fragmentierungsgrad als konfigurierbaren Parameter festlegen, der geringer sein muss als Daten-Parallelitätsgrad. Bei jedem Vorwärts- und Rückwärtslauf kombiniert MICs die Modellparameter während des gesamten Vorgangs vorübergehend neu. GPUs `AllGather` Nach dem Vorwärts- oder Rückwärtsdurchlauf jeder Layer fragmentiert MICs die Parameter erneut, um GPU-Speicher zu sparen. Während des Rückwärtsdurchlaufs reduziert MICs die Gradienten und verteilt sie gleichzeitig während des gesamten Vorgangs. GPUs `ReduceScatter` Schließlich wendet MICs die lokalen reduzierten und fragmentierten Steigungen auf die entsprechenden lokalen Parameter-Fragmente an und verwendet dabei die lokalen Fragmente der Optimierer-Zustände. Um den Kommunikationsaufwand zu verringern, ruft die SageMaker Modellparallelitätsbibliothek die nächsten Schichten im Vorwärts- oder Rückwärtsgang vorab ab und überlagert die Netzwerkkommunikation mit der Berechnung.
Der Trainingszustand des Modells wird über alle Fragmentierungsgruppen repliziert. Das heißt, bevor auf die Parameter Steigungen angewendet werden, muss zusätzlich zu der `ReduceScatter` Operation, die innerhalb der Fragmentierungsgruppe stattfindet, in allen Fragmentierungsgruppen die `AllReduce` Operation erfolgen.
Tatsächlich führt die Parallelität fragmentierter Daten zu einem Kompromiss zwischen dem Kommunikationsaufwand und der GPU-Speichereffizienz. Die Verwendung paralleler fragmentierter Daten erhöht zwar die Kommunikationskosten, der Speicherbedarf je GPU (ohne die Speichernutzung aufgrund von Aktivierungen) wird aber durch den Grad der Parallelität der fragmentierten Daten fragmentiert, so dass größere Modelle in den GPU-Cluster passen.
**Wahl des Parallelitätsgrades fragmentierter Daten**
Wenn Sie einen Wert für den Daten-Parallelitätsgrad der fragmentierten Daten wählen, muss dieser Wert den Daten-Parallelitätsgrad gleichmäßig verteilen. Wählen Sie z. B. für einen Auftrag mit 8-Wege-Datenparallelität 2, 4 oder 8 als Parallelitätsgrad für die fragmentierten Daten aus. Wir empfehlen, bei der Auswahl des Parallelitätsgrades für die fragmentierten Daten mit einer kleinen Zahl zu beginnen und diese schrittweise zu erhöhen, bis das Modell zusammen mit der gewünschten Batch-Größe in den Speicher passt.
**Wahl der Batch-Größe**
Achten Sie nach der Einrichtung der Parallelität der fragmentierten Daten darauf, dass Sie die optimale Trainingskonfiguration finden, die auf dem GPU-Cluster erfolgreich laufen kann. Um Large Language Models (LLM) zu trainieren, beginnen Sie mit der Batchgröße 1 und erhöhen Sie diese schrittweise, bis Sie den Punkt erreichen, an dem der Fehler (OOM) angezeigt wird. out-of-memory Wenn der OOM-Fehler auch bei der kleinsten Batch-Größe auftritt, wenden Sie einen höheren Parallelitätsgrad der fragmentierten Daten oder eine Kombination aus der Parallelität der fragmentierten Daten und Tensor-Parallelität an.
**Topics**
+ [So können Sie die Parallelität fragmentierter Daten auf Ihren Trainingsauftrag anwenden](#model-parallel-extended-features-pytorch-sharded-data-parallelism-how-to-use)
+ [Referenzkonfigurationen](#model-parallel-extended-features-pytorch-sharded-data-parallelism-how-to-use-config-sample)
+ [Parallelität fragmentierter Daten mit SMDDP-Kollektiven](#model-parallel-extended-features-pytorch-sharded-data-parallelism-smddp-collectives)
+ [Gemischtes Präzisionstraining mit Parallelität fragmentierter Daten](#model-parallel-extended-features-pytorch-sharded-data-parallelism-16bits-training)
+ [Parallelität fragmentierter Daten mit Tensor-Parallelität](#model-parallel-extended-features-pytorch-sharded-data-parallelism-with-tensor-parallelism)
+ [Tipps und Überlegungen zur Verwendung der Parallelität fragmentierter Daten](#model-parallel-extended-features-pytorch-sharded-data-parallelism-considerations)
## So können Sie die Parallelität fragmentierter Daten auf Ihren Trainingsauftrag anwenden
Um mit Sharded Data Parallelism zu beginnen, nehmen Sie die erforderlichen Änderungen an Ihrem Trainingsskript vor und richten Sie den SageMaker PyTorch Schätzer mit den Parametern ein. sharded-data-parallelism-specific Erwägen Sie auch, Referenzwerte und Beispiel-Notebooks als Ausgangspunkt zu verwenden.
### Passen Sie Ihr Trainingsskript an PyTorch
Folgen Sie den Anweisungen unter [Schritt 1: Ein PyTorch Trainingsskript ändern](model-parallel-customize-training-script-pt.md), um die Modell- und Optimizer-Objekte mit den `smdistributed.modelparallel.torch` Wrappern der `torch.nn.parallel` Module und zu verbinden. `torch.distributed`
**(Optional) Zusätzliche Änderung zur Registrierung externer Modellparameter**
Wenn Ihr Modell mit `torch.nn.Module` erstellt wurde und Parameter verwendet, die innerhalb der Modulklasse nicht definiert sind, sollten Sie sie manuell im Modul registrieren, damit SMP die vollständigen Parameter erfassen kann, während . Verwenden Sie `smp.register_parameter(module, parameter)`, um Parameter für ein Modul zu registrieren.
```
class Module(torch.nn.Module):
def __init__(self, *args):
super().__init__(self, *args)
self.layer1 = Layer1()
self.layer2 = Layer2()
smp.register_parameter(self, self.layer1.weight)
def forward(self, input):
x = self.layer1(input)
# self.layer1.weight is required by self.layer2.forward
y = self.layer2(x, self.layer1.weight)
return y
```
### Richten Sie den Schätzer ein SageMaker PyTorch
Fügen Sie bei der Konfiguration eines SageMaker PyTorch Schätzers die Parameter für die Parallelität von Sharded Data hinzu. [Schritt 2: Starten Sie einen Trainingsjob mit dem SageMaker Python-SDK](model-parallel-sm-sdk.md)
Um die Sharded-Datenparallelität zu aktivieren, fügen Sie den Parameter zum Estimator hinzu. `sharded_data_parallel_degree` SageMaker PyTorch Dieser Parameter gibt die Zahl an, GPUs über die der Trainingsstatus aufgeteilt wird. Der Wert für `sharded_data_parallel_degree` muss eine Ganzzahl zwischen eins und dem Daten-Parallelitätsgrad sein und muss den Daten-Parallelitätsgrad gleichmäßig verteilen. Beachten Sie, dass die Bibliothek automatisch die Anzahl und GPUs somit den Grad der Datenparallelität erkennt. Für die Konfiguration der Parallelität der fragmentierten Daten stehen die folgenden zusätzlichen Parameter zur Verfügung.
+ `"sdp_reduce_bucket_size"`*(int, Standard: 5e8)* — Gibt die Größe von [PyTorch DDP-Gradienten-Buckets](https://pytorch.org/docs/stable/notes/ddp.html#internal-design) als Anzahl von Elementen mit dem Standard-Dtype an.
+ `"sdp_param_persistence_threshold"`*(int, Standard: 1e6)* – Gibt die Größe eines Parametertensors als Anzahl von Elementen an, die auf jeder GPU bestehen bleiben können. Sharded Data Parallelism teilt jeden Parametertensor auf eine Datenparallelgruppe auf GPUs . Wenn die Anzahl der Elemente im Parametertensor kleiner als dieser Schwellenwert ist, wird der Parametertensor nicht aufgeteilt. Dies trägt dazu bei, den Kommunikationsaufwand zu reduzieren, da der Parametertensor datenparallel repliziert wird. GPUs
+ `"sdp_max_live_parameters"`*(int, Standard: 1e9)* – Gibt die maximale Anzahl von Parametern an, die sich während des Vorwärts- und Rückwärtsdurchlaufs gleichzeitig in einem neu kombinierten Trainingszustand befinden können. Das Abrufen von Parametern mit dem `AllGather` Vorgang wird unterbrochen, wenn die Anzahl der aktiven Parameter den angegebenen Schwellenwert erreicht. Beachten Sie, dass eine Erhöhung dieses Parameters den Speicherbedarf erhöht.
+ `"sdp_hierarchical_allgather"`*(bool, Standard: True)* – Wenn dieser auf `True` gesetzt wird, wird der `AllGather` Vorgang hierarchisch ausgeführt: Er wird zuerst innerhalb jedes Knotens und dann knotenübergreifend ausgeführt. Bei verteilten Trainingsaufträgen mit mehreren Knoten wird die hierarchische `AllGather` Operation automatisch aktiviert.
+ `"sdp_gradient_clipping"`*(Gleitkomma, Standard: 1.0)* – Gibt einen Schwellenwert für die Gradientenbeschneidung der L2-Norm der Steigungen an, bevor sie durch die Modellparameter rückwärts verteilt werden. Wenn die Parallelität fragmentierter Daten aktiviert ist, ist auch die Gradientenbeschneidung aktiviert. Der Standardschwellenwert ist `1.0`. Passen Sie diesen Parameter an, wenn das Problem mit explodierenden Steigungen auftritt.
Der folgende Code zeigt ein Beispiel für die Konfiguration der Parallelität fragmentierter Daten.
```
import sagemaker
from sagemaker.pytorch import PyTorch
smp_options = {
"enabled": True,
"parameters": {
# "pipeline_parallel_degree": 1, # Optional, default is 1
# "tensor_parallel_degree": 1, # Optional, default is 1
"ddp": True,
# parameters for sharded data parallelism
"sharded_data_parallel_degree": 2, # Add this to activate sharded data parallelism
"sdp_reduce_bucket_size": int(5e8), # Optional
"sdp_param_persistence_threshold": int(1e6), # Optional
"sdp_max_live_parameters": int(1e9), # Optional
"sdp_hierarchical_allgather": True, # Optional
"sdp_gradient_clipping": 1.0 # Optional
}
}
mpi_options = {
"enabled" : True, # Required
"processes_per_host" : 8 # Required
}
smp_estimator = PyTorch(
entry_point="your_training_script.py", # Specify your train script
role=sagemaker.get_execution_role(),
instance_count=1,
instance_type='ml.p3.16xlarge',
framework_version='1.13.1',
py_version='py3',
distribution={
"smdistributed": {"modelparallel": smp_options},
"mpi": mpi_options
},
base_job_name="sharded-data-parallel-job"
)
smp_estimator.fit('s3://my_bucket/my_training_data/')
```
## Referenzkonfigurationen
Das SageMaker verteilte Schulungsteam stellt die folgenden Referenzkonfigurationen zur Verfügung, die Sie als Ausgangspunkt verwenden können. Sie können von den folgenden Konfigurationen extrapolieren, um zu experimentieren und die GPU-Speichernutzung für Ihre Modellkonfiguration abzuschätzen.
Parallelität fragmentierter Daten mit SMDDP-Kollektiven
| Modell/die Anzahl der Parameter | Num. Instances | Instance-Typ | Länge der Reihenfolge | Globale Batch-Größe | Mini-Batch-Größe | Parallelitätsgrad der fragmentierten Daten |
| --- | --- | --- | --- | --- | --- | --- |
| GPT-NEOX-20B | 2 | ml.p4d.24xlarge | 2048 | 64 | 4 | 16 |
| GPT-NEOX-20B | 8 | ml.p4d.24xlarge | 2048 | 768 | 12 | 32 |
Wenn Sie z. B. die Länge der Reihenfolge für ein Modell mit 20 Milliarden Parametern oder die Größe des Modells auf 65 Milliarden Parameter erhöhen, müssen Sie zunächst versuchen, die Batch-Größe zu reduzieren. Wenn das Modell dann immer noch nicht in die kleinste Batch-Größe (die Batch-Größe 1) passt, versuchen Sie, den Parallelitätsgrad des Modell zu erhöhen.
Parallelität fragmentierter Daten mit Tensor-Parallelität und NCCL-Kollektiven
| Modell/die Anzahl der Parameter | Num. Instances | Instance-Typ | Länge der Reihenfolge | Globale Batch-Größe | Mini-Batch-Größe | Parallelitätsgrad der fragmentierten Daten | Tensor-Parallelgrad | Aktivierung, Entladung |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| GPT-NEOX-65B | 64 | ml.p4d.24xlarge | 2048 | 512 | 8 | 16 | 8 | Y |
| GPT-NEOX-65B | 64 | ml.p4d.24xlarge | 4096 | 512 | 2 | 64 | 2 | Y |
Die kombinierte Verwendung von Datenparallelität und Tensorparallelität ist nützlich, wenn Sie ein großes Sprachmodell (LLM) in einen großen Cluster einpassen und gleichzeitig Textdaten mit einer längeren Sequenzlänge verwenden möchten, was zu einer geringeren Batchgröße führt, und folglich die GPU-Speicherauslastung für das Training mit längeren Textsequenzen bewältigen möchten. LLMs Weitere Informationen hierzu finden Sie unter [Parallelität fragmentierter Daten mit Tensor-Parallelität](#model-parallel-extended-features-pytorch-sharded-data-parallelism-with-tensor-parallelism).
Fallstudien, Benchmarks und weitere Konfigurationsbeispiele finden Sie im Blogbeitrag [Neue Leistungsverbesserungen in der Amazon SageMaker AI-Modellparallelbibliothek](https://aws.amazon.com/blogs/machine-learning/new-performance-improvements-in-amazon-sagemaker-model-parallel-library/).
## Parallelität fragmentierter Daten mit SMDDP-Kollektiven
Die SageMaker Datenparallelitätsbibliothek bietet kollektive Kommunikationsprimitive (SMDDP-Kollektive), die für die Infrastruktur optimiert sind. AWS Die Optimierung wird durch die Annahme eines all-to-all-type Kommunikationsmusters mithilfe des [Elastic Fabric Adapter (EFA) erreicht, was zu einem](https://aws.amazon.com/hpc/efa/) hohen Durchsatz und weniger latenzempfindlichen Kollektiven führt, die kommunikationsbezogene Verarbeitung auf die CPU auslagert und GPU-Zyklen für Berechnungen freigibt. In großen Clustern können SMDDP Kollektive die Leistung verteilter Trainings im Vergleich zu NCCL um bis zu 40 % verbessern. Fallstudien und Benchmark-Ergebnisse finden Sie im Blog [Neue Leistungsverbesserungen in der Amazon SageMaker AI-Modellparallelismus-Bibliothek](https://aws.amazon.com/blogs/machine-learning/new-performance-improvements-in-amazon-sagemaker-model-parallel-library/).
**Anmerkung**
Sharded Data Parallelism mit SMDDP Collectives ist in der SageMaker Modellparallelismus-Bibliothek v1.13.0 und höher sowie in der Datenparallelismus-Bibliothek v1.6.0 und höher verfügbar. SageMaker Weitere Informationen finden Sie unter So verwenden Sie Sharded Data [Supported configurations](#sharded-data-parallelism-smddp-collectives-supported-config) Parallelism mit SMDDP Kollektive.
Bei der Parallelität fragmentierter Daten, einer häufig verwendeten Technik für groß angelegtes verteiltes Training, wird das `AllGather` Kollektiv verwendet, um die Sharded-Layer-Parameter für Vorwärts- und Rückwärtspassberechnungen parallel zur GPU-Berechnung zu rekonstruieren. Bei großen Modellen ist eine effiziente Ausführung des `AllGather` Vorgangs entscheidend, um GPU-Engpässe und eine Verlangsamung der Trainingsgeschwindigkeit zu vermeiden. Wenn die Parallelität fragmentierter Daten aktiviert ist, wird SMDDP Kollektive in diese leistungskritischen `AllGather`-Kollektive fragmentiert, wodurch der Trainingsdurchsatz verbessert wird.
**Trainieren Sie mit SMDDP Kollektive**
Wenn in Ihrem Trainingsauftrag die Parallelität fragmentierter Daten aktiviert ist und die Anfrageen erfüllt sind[Supported configurations](#sharded-data-parallelism-smddp-collectives-supported-config), werden SMDDP Kollektive automatisch aktiviert. Intern optimieren SMDDP Collectives das Kollektiv so, dass es in der Infrastruktur performant ist, und greifen für alle anderen `AllGather` Kollektive auf NCCL zurück. AWS Darüber hinaus verwenden bei nicht unterstützten Konfigurationen alle Kollektive, einschließlich `AllGather`, automatisch das NCCL-Backend.
Seit Version 1.13.0 der SageMaker Modellparallelismus-Bibliothek wird der Parameter zu den Optionen hinzugefügt. `"ddp_dist_backend"` `modelparallel` Der Standardwert für diesen Konfigurationsparameter ist `"auto"`. Wann immer möglich verwendet dieser SMDDP-Kollektive. Andernfalls wird auf NCCL zurückgegriffen. Um zu erzwingen, dass die Bibliothek immer NCCL verwendet, geben Sie `"nccl"` im `"ddp_dist_backend"` Konfigurationsparameter an.
Das folgende Codebeispiel zeigt, wie ein PyTorch Schätzer unter Verwendung der Sharded-Datenparallelität mit dem `"ddp_dist_backend"` Parameter eingerichtet wird, der `"auto"` standardmäßig auf gesetzt ist und daher optional hinzugefügt werden kann.
```
import sagemaker
from sagemaker.pytorch import PyTorch
smp_options = {
"enabled":True,
"parameters": {
"partitions": 1,
"ddp": True,
"sharded_data_parallel_degree": 64
"bf16": True,
"ddp_dist_backend": "auto" # Specify "nccl" to force to use NCCL.
}
}
mpi_options = {
"enabled" : True, # Required
"processes_per_host" : 8 # Required
}
smd_mp_estimator = PyTorch(
entry_point="your_training_script.py", # Specify your train script
source_dir="location_to_your_script",
role=sagemaker.get_execution_role(),
instance_count=8,
instance_type='ml.p4d.24xlarge',
framework_version='1.13.1',
py_version='py3',
distribution={
"smdistributed": {"modelparallel": smp_options},
"mpi": mpi_options
},
base_job_name="sharded-data-parallel-demo",
)
smd_mp_estimator.fit('s3://my_bucket/my_training_data/')
```
**Unterstützte Konfigurationen**
Der `AllGather` Vorgang mit SMDDP-Kollektiven wird in Trainingsaufträgen aktiviert, wenn alle der folgenden Konfigurationsanforderungen erfüllt sind.
+ Der Parallelitätsgrad fragmentierter Daten ist größer als 1
+ `Instance_count` größer als 1
+ `Instance_type` gleich `ml.p4d.24xlarge`
+ SageMaker Trainingscontainer für v1.12.1 oder höher PyTorch
+ Die SageMaker Datenparallelitätsbibliothek v1.6.0 oder höher
+ Die SageMaker Modellparallelismus-Bibliothek v1.13.0 oder höher
**Leistungs- und Speicheroptimierung**
SMDDP-Kollektive nutzen zusätzlichen GPU-Speicher. Es gibt zwei Umgebungsvariablen zur Konfiguration der GPU-Speichernutzung in Abhängigkeit von verschiedenen Anwendungsfällen für das Modelltraining.
+ `SMDDP_AG_SCRATCH_BUFFER_SIZE_BYTES` – Während des SMDDP `AllGather`-Vorgangs wird der `AllGather` Eingabepuffer für die Kommunikation zwischen den Knoten in einen temporären Puffer kopiert. Die `SMDDP_AG_SCRATCH_BUFFER_SIZE_BYTES` Variable steuert die Größe dieses temporären Puffers (in Byte). Wenn die Größe des temporären Puffers kleiner ist als die Größe des `AllGather` Eingabepuffers, greift das `AllGather` Kollektiv auf NCCL zurück.
+ Standardwert: 16 \$1 1024 \$1 1024 (16 MB)
+ Zulässige Werte: alle Vielfachen von 8192
+ `SMDDP_AG_SORT_BUFFER_SIZE_BYTES` – Die `SMDDP_AG_SORT_BUFFER_SIZE_BYTES` Variable dient zur Anpassung der Größe des temporären Puffers (in Byte) für Daten, die bei der Kommunikation zwischen Knoten gesammelt wurden. Wenn die Größe dieses temporären Puffers kleiner ist als `1/8 * sharded_data_parallel_degree * AllGather input size`, greift das `AllGather` Kollektiv auf NCCL zurück.
+ Standardwert: 128 \$1 1024 \$1 1024 (128 MB)
+ Zulässige Werte: alle Vielfachen von 8192
**Optimierungsleitlinien zu den Variablen der Puffergröße**
Die Standardwerte für die Umgebungsvariablen sollten für die meisten Anwendungsfälle gut funktionieren. Wir empfehlen, diese Variablen nur zu optimieren, wenn beim Training der Fehler out-of-memory (OOM) auftritt.
In der folgenden Liste werden Tipps für die Optimierung beschrieben, um den GPU-Speicherbedarf von SMDDP-Kollektiven zu reduzieren und dabei den daraus resultierenden Leistungsgewinn beizubehalten.
+ Optimierung von `SMDDP_AG_SCRATCH_BUFFER_SIZE_BYTES`
+ Die Größe des `AllGather` Eingabepuffers ist bei kleineren Modellen kleiner. Daher kann die erforderliche Größe für `SMDDP_AG_SCRATCH_BUFFER_SIZE_BYTES` für Modelle mit weniger Parametern geringer sein.
+ Die Größe des `AllGather` Eingabepuffers nimmt mit `sharded_data_parallel_degree` zunehmender Größe ab, da das Modell stärker GPUs fragmentiert wird. Daher kann die erforderliche Größe für `SMDDP_AG_SCRATCH_BUFFER_SIZE_BYTES` bei Trainingsaufträgen mit großen Werten für `sharded_data_parallel_degree` kleiner sein.
+ Optimierung von `SMDDP_AG_SORT_BUFFER_SIZE_BYTES`
+ Bei Modellen mit weniger Parametern ist die Datenmenge, die bei der Kommunikation zwischen den Knoten gesammelt wird, geringer. Daher kann die erforderliche Größe für `SMDDP_AG_SORT_BUFFER_SIZE_BYTES` für solche Modelle mit weniger Parametern geringer sein.
Manche Kollektive greifen ggf. auf NCCL zurück. Daher erzielen Sie durch die optimierten SMDDP-Kollektive ggf. nicht die erwartete Leistungssteigerung. Wenn zusätzlicher GPU-Speicher zur Verfügung steht, können Sie erwägen, die Werte von `SMDDP_AG_SCRATCH_BUFFER_SIZE_BYTES` und `SMDDP_AG_SORT_BUFFER_SIZE_BYTES` zu erhöhen, um von der Leistungssteigerung zu profitieren.
Der folgende Code zeigt, wie Sie die Umgebungsvariablen konfigurieren können, indem Sie sie an `mpi_options` den Verteilungsparameter für den PyTorch Schätzer anhängen.
```
import sagemaker
from sagemaker.pytorch import PyTorch
smp_options = {
.... # All modelparallel configuration options go here
}
mpi_options = {
"enabled" : True, # Required
"processes_per_host" : 8 # Required
}
# Use the following two lines to tune values of the environment variables for buffer
mpioptions += " -x SMDDP_AG_SCRATCH_BUFFER_SIZE_BYTES=8192"
mpioptions += " -x SMDDP_AG_SORT_BUFFER_SIZE_BYTES=8192"
smd_mp_estimator = PyTorch(
entry_point="your_training_script.py", # Specify your train script
source_dir="location_to_your_script",
role=sagemaker.get_execution_role(),
instance_count=8,
instance_type='ml.p4d.24xlarge',
framework_version='1.13.1',
py_version='py3',
distribution={
"smdistributed": {"modelparallel": smp_options},
"mpi": mpi_options
},
base_job_name="sharded-data-parallel-demo-with-tuning",
)
smd_mp_estimator.fit('s3://my_bucket/my_training_data/')
```
## Gemischtes Präzisionstraining mit Parallelität fragmentierter Daten
Um GPU-Speicher mit halbpräzisen Fließkommazahlen und Shard-Datenparallelität weiter zu sparen, können Sie das 16-Bit-Fließkommaformat (FP16) oder das [Brain-Fließkommaformat](https://en.wikichip.org/wiki/brain_floating-point_format) () aktivieren, indem Sie der verteilten BF16 Trainingskonfiguration einen zusätzlichen Parameter hinzufügen.
**Anmerkung**
Das Training mit gemischter Präzision und Sharded-Datenparallelität ist in der Modellparallelismus-Bibliothek v1.11.0 und höher verfügbar. SageMaker
**Für FP16 das Training mit Sharded Data Parallelism**
Um ein FP16 Training mit Sharded Data Parallelism durchzuführen, fügen Sie es dem Konfigurationswörterbuch hinzu. `"fp16": True"` `smp_options` In Ihrem Trainingsskript können Sie mit Hilfe des `smp.DistributedOptimizer` Moduls zwischen den statischen und dynamischen Verlustskalierungsoptionen wählen. Weitere Informationen finden Sie unter [FP16 Training mit Modellparallelität](model-parallel-extended-features-pytorch-fp16.md).
```
smp_options = {
"enabled": True,
"parameters": {
"ddp": True,
"sharded_data_parallel_degree": 2,
"fp16": True
}
}
```
**Für das BF16 Training mit Sharded Data Parallelism**
Die SageMaker KI-Funktion zur Parallelität von Sharded Data unterstützt das Training nach Datentypen. BF16 Der BF16 Datentyp verwendet 8 Bit, um den Exponenten einer Fließkommazahl darzustellen, während der FP16 Datentyp 5 Bit verwendet. Wenn die 8 Bit für den Exponenten beibehalten werden, kann dieselbe Darstellung des Exponenten einer 32-Bit-Gleitkommazahl () FP32 mit einfacher Genauigkeit beibehalten werden. Dadurch wird die Konvertierung zwischen FP32 und BF16 einfacher und es ist deutlich weniger anfällig für Überlauf- und Unterlaufprobleme, die häufig beim Training auftreten, insbesondere beim FP16 Training größerer Modelle. Beide Datentypen verwenden zwar insgesamt 16 Bit, aber dieser vergrößerte Darstellungsbereich für den Exponenten im BF16 Format geht zu Lasten einer geringeren Genauigkeit. Beim Training großer Modelle wird diese geringere Genauigkeit oft als akzeptabler Kompromiss für den Bereich und die Stabilität des Trainings angesehen.
**Anmerkung**
Derzeit funktioniert das BF16 Training nur, wenn die Shard-Datenparallelität aktiviert ist.
Um ein BF16 Training mit Sharded-Datenparallelität durchzuführen, fügen Sie es dem Konfigurationswörterbuch hinzu. `"bf16": True` `smp_options`
```
smp_options = {
"enabled": True,
"parameters": {
"ddp": True,
"sharded_data_parallel_degree": 2,
"bf16": True
}
}
```
## Parallelität fragmentierter Daten mit Tensor-Parallelität
Wenn Sie die Parallelität fragmentierter Daten nutzen und außerdem die globale Batch-Größe reduzieren müssen, sollten Sie die Verwendung von [Tensor-Parallelität](https://docs.aws.amazon.com/sagemaker/latest/dg/model-parallel-extended-features-pytorch-tensor-parallelism.html) mit der Parallelität fragmentierter Daten in Betracht ziehen. Wenn Sie ein großes Modell mit Parallelität fragmentierter Daten auf einem sehr großen Datenverarbeitungscluster (typischerweise 128 Knoten oder mehr) trainieren, führt selbst eine kleine Batch-Größe pro GPU zu einer sehr großen globalen Batch-Größe. Dies kann zu Konvergenzproblemen oder Problemen mit geringer Datenverarbeitungsleistung führen. Die Batch-Größe pro GPU kann manchmal mit der Parallelität fragmentierter Daten allein nicht reduziert werden, wenn ein einzelnes Batch bereits sehr umfangreich ist und nicht weiter reduziert werden kann. In solchen Fällen trägt die Verwendung der Parallelität fragmentierter Daten in Kombination mit Tensor-Parallelität dazu bei, die globale Batch-Größe zu reduzieren.
Die Wahl des optimalen Grades für die Parallelität fragmentierter Daten und die Tensor-Parallelität hängt von der Größe des Modells, dem Instance-Typ und von der globalen Batch-Größe ab, die angemessen ist, damit das Modell konvergieren kann. Wir empfehlen, dass Sie mit einem niedrigen Tensorparallelgrad beginnen, um die globale Batchgröße an den Rechencluster anzupassen, um out-of-memory CUDA-Fehler zu beheben und die beste Leistung zu erzielen. In den folgenden beiden Beispielfällen erfahren Sie, wie die Kombination aus Tensorparallelität und Sharded-Datenparallelität Ihnen hilft, die globale Batchgröße durch Gruppierung GPUs nach Modellparallelität anzupassen, was zu einer geringeren Anzahl von Modellreplikaten und einer kleineren globalen Batchgröße führt.
**Anmerkung**
Diese Funktion ist in der Modellparallelismus-Bibliothek v1.15 verfügbar und unterstützt Version 1.13.1. SageMaker PyTorch
**Anmerkung**
Diese Funktion steht für die durch die Tensor-Parallelitätsfunktionalität der Bibliothek unterstützten Modelle zur Verfügung. Eine Liste der unterstützten Modelle finden Sie unter [Support für Hugging Face Transformator-Modelle](https://docs.aws.amazon.com/sagemaker/latest/dg/model-parallel-extended-features-pytorch-hugging-face.html). Beachten Sie auch, dass Sie bei der Änderung Ihres Trainingsskripts `tensor_parallelism=True` an das `smp.model_creation` Argument übergehen müssen. *Weitere Informationen finden Sie im Trainingsskript [https://github.com/aws/amazon-sagemaker-examples/blob/main/training/distributed_training/pytorch/model_parallel/gpt2/train_gpt_simple.py#L793](https://github.com/aws/amazon-sagemaker-examples/blob/main/training/distributed_training/pytorch/model_parallel/gpt2/train_gpt_simple.py#L793)im AI Examples Repository. SageMaker GitHub *
### Beispiel 1
Nehmen wir an, wir möchten ein Modell über einen Cluster von 1536 GPUs (192 Knoten mit jeweils 8 Knoten) trainieren und GPUs dabei den Grad der Sharded-Datenparallelität auf 32 (`sharded_data_parallel_degree=32`) und die Batchgröße pro GPU auf 1 setzen, wobei jeder Stapel eine Sequenzlänge von 4096 Token hat. In diesem Fall gibt es 1536 Modellrepliken, die globale Batch-Größe beträgt 1536 und jedes globale Batch enthält etwa 6 Millionen Token.
```
(1536 GPUs) * (1 batch per GPU) = (1536 global batches)
(1536 batches) * (4096 tokens per batch) = (6,291,456 tokens)
```
Durch Hinzufügen von Tensor-Parallelität kann die globale Batch-Größe verringert werden. Ein Konfigurationsbeispiel kann darin bestehen, den Grad der Tensor-Parallelität auf 8 und die Batch-Größe pro GPU auf 4 festzulegen. Dies bildet 192 parallel Tensorgruppen oder 192 Modellreplikate, wobei jedes Modellreplikat auf 8 verteilt ist. GPUs Die Batch-Größe von 4 ist die Menge an Trainingsdaten je Iteration und Tensorparallelgruppe, d. h. jede Modellreplik verbraucht 4 Batches pro Iteration. In diesem Fall beträgt die globale Batch-Größe 768, und jedes globale Batch enthält etwa 3 Millionen Token. Daher wird die globale Batch-Größe im Vergleich zum vorangehenden Fall um die Hälfte reduziert, wo nur die Parallelität fragmentierter Daten verwendet wurde.
```
(1536 GPUs) / (8 tensor parallel degree) = (192 tensor parallelism groups)
(192 tensor parallelism groups) * (4 batches per tensor parallelism group) = (768 global batches)
(768 batches) * (4096 tokens per batch) = (3,145,728 tokens)
```
### Beispiel 2
Wenn sowohl die Parallelität fragmentierter Daten als auch die Tensor-Parallelität aktiviert sind, wendet die Bibliothek zunächst die Tensor-Parallelität an und fragmentiert das Modell über diese Dimension. Für jeden Tensorparallelrang wird die Datenparallelität gem. `sharded_data_parallel_degree` angewendet.
Nehmen wir zum Beispiel an, dass wir 32 GPUs mit einem Tensorparallelgrad von 4 setzen möchten (wobei Gruppen von 4 gebildet werden GPUs), einem parallel Grad für zerteilte Daten von 4, was zu einem Replikationsgrad von 2 führt. Durch die Zuweisung werden anhand des Grades der Tensor-Parallelität acht GPU-Gruppen wie folgt erstellt: `(0,1,2,3)`, `(4,5,6,7)`, `(8,9,10,11)`, `(12,13,14,15)`, `(16,17,18,19)`, `(20,21,22,23)`, `(24,25,26,27)`, `(28,29,30,31)`. Das heißt, vier GPUs bilden eine tensorparallele Gruppe. In diesem Fall wäre die reduzierte Datenparallelgruppe für den 0. Rang GPUs der tensorparallelen Gruppen. `(0,4,8,12,16,20,24,28)` Die reduzierte Datenparallelgruppe wird auf der Grundlage des Parallelgrads von 4 aufgeteilt, was zu zwei Replikationsgruppen für Datenparallelität führt. GPUs`(0,4,8,12)`bilden eine Sharding-Gruppe, die zusammen eine vollständige Kopie aller Parameter für den 0ten tensorparallelen Rang enthält, und GPUs `(16,20,24,28)` bilden eine weitere solche Gruppe. Auch andere Tensorparallelränge haben ähnliche Fragmentierungs- und Replikationsgruppen.
![\[Abbildung 1: Tensorparallelitätsgruppen.\]](http://docs.aws.amazon.com/de_de/sagemaker/latest/dg/images/distributed/model-parallel/sdp_tp_group_tp.jpg)
Abbildung 1: Tensorparallelitätsgruppen für (Knoten, Parallelitätsgrad der fragmentierten Daten, Tensorparallelgrad) = (4, 4, 4), wobei jedes Rechteck eine GPU mit Indizes von 0 bis 31 darstellt. Sie GPUs bilden Tensorparallelitätsgruppen von TPG zu TPG. 0 7 Replikationsgruppen sind (\$1TPG0, TPG4\$1, \$1TPG1, TPG5\$1, \$1TPG2, TPG6\$1 und \$1TPG3, TPG7\$1); jedes Replikationsgruppenpaar hat dieselbe Farbe, ist aber unterschiedlich gefüllt.
![\[Abbildung 2: Parallelitätsgruppen fragmentierter Daten.\]](http://docs.aws.amazon.com/de_de/sagemaker/latest/dg/images/distributed/model-parallel/sdp_tp_group_sdp.jpg)
Abbildung 2: Parallelitätsgruppen fragmentierter Daten für (Knoten, Parallelitätsgrad der fragmentierten Daten, Tensorparallelgrad) = (4, 4, 4), wobei jedes Rechteck eine GPU mit Indizes von 0 bis 31 darstellt. Das GPUs Formular gruppiert Datenparallelitätsgruppen von SDPG bis SDPG. 0 7 Replikationsgruppen sind (\$1SDPG0, SDPG4\$1, \$1SDPG1, SDPG5\$1, \$1SDPG2, SDPG6\$1 und \$1SDPG3, SDPG7\$1). Jedes Replikationsgruppenpaar hat dieselbe Farbe, ist aber unterschiedlich gefüllt.
### So aktivieren Sie die Parallelität fragmentierter Daten mit Tensor-Parallelität
Um Sharded Data Parallelism mit Tensor Parallelism zu verwenden, müssen Sie sowohl als auch `tensor_parallel_degree` in der Konfiguration angeben, während Sie ein Objekt der `sharded_data_parallel_degree` Estimator-Klasse erstellen. `distribution` SageMaker PyTorch
Und Sie müssen auch `prescaled_batch` aktivieren. Das bedeutet, dass nicht jede GPU ihren eigenen Daten-Batch liest, sondern jede parallel Tensorparallelgruppe gemeinsam ein kombiniertes Batch der ausgewählten Batch-Größe liest. Anstatt den Datensatz in Teile zu unterteilen, die der Anzahl von GPUs (oder der parallel Datengröße`smp.dp_size()`) entsprechen, wird er in Teile aufgeteilt, die der Anzahl von GPUs geteilt durch `tensor_parallel_degree` (auch als reduzierte Datenparallelgröße bezeichnet`smp.rdp_size()`) entsprechen. *Weitere Informationen zu Prescaled Batch finden Sie unter [Prescaled Batch](https://sagemaker.readthedocs.io/en/v2.199.0/api/training/smd_model_parallel_general.html#prescaled-batch) in der SageMaker Python SDK-Dokumentation.* *Siehe auch das Beispiel-Trainingsskript [https://github.com/aws/amazon-sagemaker-examples/blob/main/training/distributed_training/pytorch/model_parallel/gpt2/train_gpt_simple.py#L164](https://github.com/aws/amazon-sagemaker-examples/blob/main/training/distributed_training/pytorch/model_parallel/gpt2/train_gpt_simple.py#L164)für GPT-2 im AI Examples Repository. SageMaker GitHub *
Der folgende Codeausschnitt zeigt ein Beispiel für die Erstellung eines PyTorch Schätzobjekts auf der Grundlage des oben genannten Szenarios in. [Beispiel 2](#model-parallel-extended-features-pytorch-sharded-data-parallelism-with-tensor-parallelism-ex2)
```
mpi_options = "-verbose --mca orte_base_help_aggregate 0 "
smp_parameters = {
"ddp": True,
"fp16": True,
"prescaled_batch": True,
"sharded_data_parallel_degree": 4,
"tensor_parallel_degree": 4
}
pytorch_estimator = PyTorch(
entry_point="your_training_script.py",
role=role,
instance_type="ml.p4d.24xlarge",
volume_size=200,
instance_count=4,
sagemaker_session=sagemaker_session,
py_version="py3",
framework_version="1.13.1",
distribution={
"smdistributed": {
"modelparallel": {
"enabled": True,
"parameters": smp_parameters,
}
},
"mpi": {
"enabled": True,
"processes_per_host": 8,
"custom_mpi_options": mpi_options,
},
},
source_dir="source_directory_of_your_code",
output_path=s3_output_location
)
```
## Tipps und Überlegungen zur Verwendung der Parallelität fragmentierter Daten
Beachten Sie Folgendes, wenn Sie die Sharded-Datenparallelität der SageMaker Modellparallelismus-Bibliothek verwenden.
+ Die Parallelität von Sharded Data ist mit Training kompatibel. FP16 Informationen zur Durchführung von FP16 Schulungen finden Sie im Abschnitt. [FP16 Training mit Modellparallelität](model-parallel-extended-features-pytorch-fp16.md)
+ Die Parallelität fragmentierter Daten ist mit der Tensor-Parallelität kompatibel. Sie müssen ggf. die folgenden Punkte berücksichtigen, wenn Sie die Parallelität fragmentierter Daten mit Tensor-Parallelität verwenden möchten.
+ Bei Verwendung der Parallelität fragmentierter Daten mit der Tensor-Parallelität werden auch die Einbettungs-Layers automatisch über die Tensorparallelgruppe verteilt. Mit anderen Worten, der `distribute_embedding` Parameter wird automatisch auf `True` gesetzt. Weitere Informationen zur Tensor-Parallelität finden Sie unter [Tensor-Parallelität](model-parallel-extended-features-pytorch-tensor-parallelism.md).
+ Beachten Sie, dass die Parallelität fragmentierter Daten und die Tensor-Parallelität derzeit die NCCL-Kollektive als Backend der verteilten Trainingsstrategie verwendet.
Weitere Informationen finden Sie im [Parallelität fragmentierter Daten mit Tensor-Parallelität](#model-parallel-extended-features-pytorch-sharded-data-parallelism-with-tensor-parallelism) Abschnitt.
+ Die Parallelität fragmentierter Daten ist derzeit nicht mit der [Pipeline-Parallelität](model-parallel-intro.md#model-parallel-intro-pp) oder der [Optimierer-Zustands-Fragmentierung](model-parallel-extended-features-pytorch-optimizer-state-sharding.md) kompatibel. Um die Parallelität fragmentierter Daten zu aktivieren, deaktivieren Sie die Optimierer-Zustands-Fragmentierung und setzen Sie den Grad der Pipeline-Parallelität auf 1.
+ Die Funktionen zur [Aktivierung von Prüfpunkten](model-parallel-extended-features-pytorch-activation-checkpointing.md) und zum [Entladen der Aktivierung](model-parallel-extended-features-pytorch-activation-offloading.md) sind mit der Parallelität fragmentierter Daten kompatibel.
+ Um die Parallelität fragmentierter Daten mit der Steigungsakkumulation zu verwenden, setzen Sie das `backward_passes_per_step` Argument auf die Anzahl der Akkumulationsschritte und wickeln Sie dabei Ihr Modell in das [https://sagemaker.readthedocs.io/en/v2.199.0/api/training/smp_versions/latest/smd_model_parallel_pytorch.html#smdistributed.modelparallel.torch.DistributedModel](https://sagemaker.readthedocs.io/en/v2.199.0/api/training/smp_versions/latest/smd_model_parallel_pytorch.html#smdistributed.modelparallel.torch.DistributedModel) Modul. Dadurch wird sichergestellt, dass die `AllReduce` Steigungsoperation zwischen den Modellreplikationsgruppen (Fragmentierungsgruppen) an der Grenze der Steigungsakkumulation stattfindet.
+ Sie können Ihre mit Sharded Data Parallelism trainierten Modelle überprüfen, indem Sie die Checkpoint-Funktion der Bibliothek verwenden, und. APIs `smp.save_checkpoint` `smp.resume_from_checkpoint` Weitere Informationen finden Sie unter [Checkpointing für ein verteiltes PyTorch Modell (für die SageMaker Modellparallelismus-Bibliothek v1.10.0 und höher)](distributed-model-parallel-checkpointing-and-finetuning.md#model-parallel-extended-features-pytorch-checkpoint).
+ Das Verhalten des [https://sagemaker.readthedocs.io/en/v2.199.0/api/training/smp_versions/latest/smd_model_parallel_pytorch.html#smdistributed.modelparallel.torch.delay_param_initialization](https://sagemaker.readthedocs.io/en/v2.199.0/api/training/smp_versions/latest/smd_model_parallel_pytorch.html#smdistributed.modelparallel.torch.delay_param_initialization) Konfigurationsparameters ändert sich bei Parallelität fragmentierter Daten. Wenn diese beiden Funktionen gleichzeitig aktiviert sind, werden die Parameter sofort nach der Modellerstellung fragmentiert initialisiert, anstatt die Parameterinitialisierung zu verzögern, damit jeder Rang seine eigenen fragmentierten Parameter initialisiert und speichert.
+ Wenn die Parallelität fragmentierter Daten aktiviert ist, beschneidet die Bibliothek bei der Ausführung des `optimizer.step()` Aufrufs intern die Steigungen. Sie müssen kein Hilfsprogramm APIs für Gradientenausschnitte verwenden, wie z. [https://pytorch.org/docs/stable/generated/torch.nn.utils.clip_grad_norm_.html](https://pytorch.org/docs/stable/generated/torch.nn.utils.clip_grad_norm_.html) Um den Schwellenwert für das Beschneiden von Farbverläufen anzupassen, können Sie ihn über den `sdp_gradient_clipping` Parameter für die Konfiguration der Verteilungsparameter festlegen, wenn Sie den SageMaker PyTorch Schätzer erstellen, wie im Abschnitt gezeigt. [So können Sie die Parallelität fragmentierter Daten auf Ihren Trainingsauftrag anwenden](#model-parallel-extended-features-pytorch-sharded-data-parallelism-how-to-use)
# Modell-Pipelining
Eines der Hauptmerkmale der SageMaker Modellparallelitätsbibliothek ist die *Pipeline-Parallelität*. Sie bestimmt die Reihenfolge, in der Berechnungen 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, indem die GPUs Berechnungen gleichzeitig auf verschiedenen Datenproben durchgeführt werden, und um den Leistungsverlust aufgrund sequentieller Berechnungen zu überwinden. Wenn Sie Pipeline-Parallelität verwenden, wird der Trainingsauftrag per Pipeline über Mikro-Batches ausgeführt, um die GPU-Auslastung zu maximieren.
**Anmerkung**
Pipeline-Parallelität, auch Modellpartitionierung genannt, ist sowohl für als auch verfügbar. PyTorch TensorFlow Die unterstützten Versionen der Frameworks finden Sie unter [Unterstützte Frameworks und AWS-Regionen](distributed-model-parallel-support.md).
## Zeitplan für die Pipeline-Ausführung
Pipelining basiert auf der Aufteilung eines Mini-Batches in Mikrobatches, die in die Trainingspipeline eingespeist werden one-by-one und einem durch die Bibliothekslaufzeit definierten Ausführungsplan folgen. Ein *Mikro-Batch* ist eine kleinere Teilmenge eines bestimmten Trainings-Minibatches. Der Pipeline-Zeitplan bestimmt für jedes Zeitfenster, welcher Mikro-Batch von welchem Gerät ausgeführt wird.
Je nach Pipeline-Zeitplan und Modellpartition `i` kann die GPU beispielsweise Berechnungen (vorwärts oder rückwärts) für Microbatch durchführen, `b` während die GPU Berechnungen für Microbatch `i+1` durchführt, wodurch beide gleichzeitig aktiv bleiben`b+1`. GPUs Während eines einzelnen Vorwärts- oder Rückwärtsdurchlaufs kann bei der Ausführung eines einzelnen Mikro-Batchs je nach Partitionierungsentscheidung dasselbe Gerät mehrmals aufgerufen werden. Eine Operation, die sich am Anfang des Modells befindet, kann z. B. auf demselben Gerät ausgeführt werden wie eine Operation am Ende des Modells, während die Operationen dazwischen auf verschiedenen Geräten ausgeführt werden. Das bedeutet, dass dieses Gerät zweimal aufgerufen wird.
Die Bibliothek bietet zwei verschiedene Pipeline-Zeitpläne, *Simple* und *Interleaved*, die mit dem `pipeline` Parameter im SageMaker Python-SDK konfiguriert werden können. In den meisten Fällen kann mit Interleaved-Pipelines eine bessere Leistung erzielt werden, wenn sie effizienter genutzt wird. GPUs
### Überlappende Pipeline
In einer überlappenden Pipeline wird der Rückwärtsausführung der Mikro-Batches nach Möglichkeit Priorität eingeräumt. Dies erlaubt eine schnellere Freigabe des für Aktivierungen verwendeten Speichers. So wird der Speicher effizienter genutzt. Es ermöglicht auch, die Anzahl der Mikrobatches höher zu skalieren und so die Leerlaufzeit von zu reduzieren. GPUs Im Steady-State wechselt jedes Gerät zwischen Vorwärts- und Rückwärtsläufen hin und her. Das bedeutet, dass der Rücklauf eines Mikro-Batches ausgeführt werden kann, bevor der Vorwärtsdurchlauf eines anderen Mikro-Batches abgeschlossen ist.
![\[Beispiel für einen Ausführungsplan für die verschachtelte Pipeline über 2. GPUs\]](http://docs.aws.amazon.com/de_de/sagemaker/latest/dg/images/distributed/model-parallel/interleaved-pipeline-execution.png)
Die vorherige Abbildung zeigt ein Beispiel für einen Ausführungsplan für die Interleaved-Pipeline über 2. GPUs In der Abbildung steht F0 für den Vorwärtsdurchlauf für Mikro-Batch 0 und B1 für den Rückwärtsdurchgang für Mikro-Batch 1. **Update** stellt das Optimizer-Update der Parameter dar. GPU0 priorisiert immer Rückwärtsdurchläufe, wann immer dies möglich ist (führt beispielsweise B0 vor F2 aus), wodurch der Speicher gelöscht werden kann, der für frühere Aktivierungen verwendet wurde.
### Einfache Pipeline
Eine einfache Pipeline beendet dagegen die Ausführung des Vorwärtsdurchlaufs für jedes Mikro-Batch, bevor der Rückwärtsdurchlauf gestartet wird. Das bedeutet, dass sie nur die Phasen des Vorwärtsdurchlaufs und des Rücklaufs in sich selbst weiterleitet. Die folgende Abbildung zeigt ein Beispiel dafür, wie das funktioniert (mehr als 2). GPUs
![\[Beispiel für eine Pipeline, die den Vorwärtsdurchlauf für jedes Mikro-Batch ausführt, bevor der Rückwärtsdurchlauf gestartet wird.\]](http://docs.aws.amazon.com/de_de/sagemaker/latest/dg/images/distributed/model-parallel/simple-pipeline-execution.png)
### Pipelining der Ausführung in bestimmten Frameworks
In den folgenden Abschnitten erfahren Sie mehr über die Framework-spezifischen Pipeline-Scheduling-Entscheidungen, die in SageMaker der Modellparallelitätsbibliothek für und vorgesehen sind. TensorFlow PyTorch
#### Pipeline-Ausführung mit TensorFlow
Die folgende Abbildung zeigt ein Beispiel TensorFlow für einen Graphen, der durch die Modellparallelitätsbibliothek partitioniert wurde. Dabei wird automatisiertes Modellsplitting verwendet. Wenn ein Diagramm geteilt wird, wird jeder resultierende Teilgraph B-mal repliziert (mit Ausnahme der Variablen). Dabei ist B die Anzahl der Mikro-Batches. In dieser Abbildung wird jeder Teilgraph zweimal repliziert (B=2). An jeder Eingabe eines Teilgraphen wird eine `SMPInput` Operation eingefügt und eine `SMPOutput` Operation wird an jedem Ausgang eingefügt. Diese Operationen kommunizieren mit dem Bibliotheks-Backend, um Tensoren zu und voneinander zu übertragen.
![\[Beispiel TensorFlow für einen Graphen, der durch die Modellparallelitätsbibliothek partitioniert wurde, wobei automatisiertes Modellsplitting verwendet wird.\]](http://docs.aws.amazon.com/de_de/sagemaker/latest/dg/images/distributed/model-parallel/interleaved-pipeline-tf.png)
Das folgende Bild ist ein Beispiel für zwei Teilgraphen, die mit B=2 geteilt wurden. Dabei wurden Steigungsoperationen hinzugefügt. Der Gradient einer `SMPInput` Operation ist eine `SMPOutput` Operation und umgekehrt. So können die Steigungen während der Rückwärtsverteilung rückwärts laufen.
![\[Beispiel für zwei Teilgraphen, die mit B=2 geteilt wurden. Dabei wurden Steigungsoperationen hinzugefügt.\]](http://docs.aws.amazon.com/de_de/sagemaker/latest/dg/images/distributed/model-parallel/interleaved-pipeline-tf.gif)
Dieses GIF zeigt ein Beispiel für einen Ausführungsplan für überlappende Pipelines mit B=2 Mikro-Batches und 2 Teilgraphen. Jedes Gerät führt nacheinander eines der replizierten Teilgraphen aus, um die GPU-Auslastung zu verbessern. Wenn B größer wird, geht der Anteil der Leerlaufzeitfenster gegen Null. Immer wenn es an der Zeit ist, Berechnungen (vorwärts oder rückwärts) für einen bestimmten replizierten Teilgraphen auszuführen, signalisiert die Pipeline-Layer den entsprechenden blauen `SMPInput` Operationen, das sie mit der Ausführung beginnen sollen.
Sobald die Steigungen aller Mikro-Batches in einem einzelnen Mini-Batch berechnet wurden, kombiniert die Bibliothek die Steigungen der einzelnen Mikro-Batches, die dann auf die Parameter angewendet werden können.
#### Pipeline-Ausführung mit PyTorch
Konzeptionell folgt das Pipelining einer ähnlichen Idee in. PyTorch Da PyTorch es sich jedoch nicht um statische Graphen handelt, verwendet die PyTorch Funktion der Modellparallelitätsbibliothek ein dynamischeres Pipelining-Paradigma.
Wie in TensorFlow, wird jeder Batch in eine Reihe von Mikrobatches aufgeteilt, die nacheinander auf jedem Gerät ausgeführt werden. Der Ausführungsplan wird jedoch über Ausführungsserver verwaltet, die auf jedem Gerät gestartet werden. Immer wenn die Ausgabe eines Submoduls, das sich auf einem anderen Gerät befindet, auf dem aktuellen Gerät gebraucht wird, wird zusammen mit den Eingangstensoren für das Submodul eine Ausführungsanfrage an den Ausführungsserver des entfernten Gerätes gesendet. Der Server führt dieses Modul dann mit den angegebenen Eingaben aus und gibt die Antwort an das aktuelle Gerät zurück.
Da sich das aktuelle Gerät während der Ausführung des Remote-Submoduls im Leerlauf befindet, wird die lokale Ausführung des aktuellen Mikro-Batches angehalten und die Bibliothekslaufzeit schaltet die Ausführung auf ein anderes Mikro-Batch um, an dem das aktuelle Gerät aktiv arbeiten kann. Die Priorisierung von Mikro-Batches wird durch den ausgewählten Pipeline-Zeitplan bestimmt. Bei einem überlappenden Pipeline-Zeitplan werden Mikro-Batches möglichst priorisiert, die sich in der Rückwärtsphase der Berechnung befinden.
# Tensor-Parallelität
*Tensor-Parallelität* ist eine Art von Modellparallelität, bei der bestimmte Modellgewichtungen, Steigungen und Optimierer-Zustände auf verschiedene Geräte aufgeteilt werden. Im Gegensatz zur Pipeline-Parallelität, bei der einzelne Gewichtungen intakt bleiben, die *Menge* der Gewichtungen jedoch fragmentiert wird, teilt die Tensor-Parallelität einzelne Gewichtungen auf. Dies beinhaltet in der Regel die verteilte Berechnung bestimmter Operationen, Module oder Layers des Modells.
Tensor-Parallelität ist dann erforderlich, wenn ein einzelner Parameter den größten Teil des GPU-Speichers beansprucht (z. B. große Einbettungstabellen mit großem Vokabular oder eine große Softmax-Layer mit einer großen Anzahl Klassen). In diesem Fall ist es ineffizient, diesen großen Tensor oder diese Operation als atomare Einheit zu behandeln und behindert die ausgeglichene Auslastung des Speichers.
Die Tensor-Parallelität ist auch für extrem große Modelle nützlich, bei denen ein reines Pipelining einfach nicht ausreicht. Bei Modellen in der Größe von GPT-3, die eine Partitionierung über Dutzende von Instances erfordern, ist ein reines Mikro-Batch-Pipelining z. B. ineffizient, da die Pipeline-Tiefe zu groß und der Overhead übermäßig groß wird.
**Anmerkung**
Die Tensorparallelität ist PyTorch in der SageMaker Modellparallelismus-Bibliothek v1.6.0 und höher verfügbar.
**Topics**
+ [So funktioniert die Tensor-Parallelität](model-parallel-extended-features-pytorch-tensor-parallelism-how-it-works.md)
+ [Führen Sie einen parallelen Trainingsjob für SageMaker verteilte Modelle mit Tensorparallelismus aus](model-parallel-extended-features-pytorch-tensor-parallelism-examples.md)
+ [Support für Hugging Face Transformator-Modelle](model-parallel-extended-features-pytorch-hugging-face.md)
+ [Rangfolgemechanismus bei Verwendung einer Kombination aus Pipeline-Parallelität und Tensor-Parallelität](model-parallel-extended-features-pytorch-ranking-mechanism.md)
# So funktioniert die Tensor-Parallelität
Die Tensor-Parallelität findet auf der Ebene von `nn.Modules` statt. Sie partitioniert bestimmte Module im Modell über tensorparallele Ränge hinweg. Dies erfolgt zusätzlich zur bestehenden Partition der *Module*, die bei der Pipeline-Parallelität verwendet werden.
Wenn ein Modul durch Tensor-Parallelität partitioniert wird, werden seine Vorwärts- und Rückwärtsverteilung verteilt. Die Bibliothek kümmert sich um die geräteübergreifende Kommunikation, um die verteilte Ausführung dieser Module zu implementieren. Die Module werden über mehrere datenparallele Ränge partitioniert. Im Gegensatz zur herkömmlichen Verteilung von Workloads verfügt **nicht** jeder datenparallele Rang über die vollständige Modellreplizierung, wenn die Tensor-Parallelität der Bibliothek verwendet wird. Stattdessen hat jeder datenparallele Rang ggf. nur eine Partition der verteilten Module, zusätzlich zu der Gesamtheit der nicht verteilten Module.
**Beispiel:** Stellen Sie sich die Tensor-Parallelität über datenparallele Ränge hinweg vor, wobei der Daten-Parallelitätsgrad 4 und der Grad der Tensor-Parallelität 2 beträgt. Gehen Sie davon aus, dass Sie nach der Partitionierung der Menge der Module eine datenparallele Gruppe haben, die den folgenden Modulbaum enthält.
```
A
├── B
| ├── E
| ├── F
├── C
└── D
├── G
└── H
```
Gehen Sie davon aus, dass die Tensor-Parallelität für die Module B, G und H unterstützt wird. Ein mögliches Ergebnis der tensorparallelen Partition dieses Modells könnte sein:
```
dp_rank 0 (tensor parallel rank 0): A, B:0, C, D, G:0, H
dp_rank 1 (tensor parallel rank 1): A, B:1, C, D, G:1, H
dp_rank 2 (tensor parallel rank 0): A, B:0, C, D, G:0, H
dp_rank 3 (tensor parallel rank 1): A, B:1, C, D, G:1, H
```
Jede Zeile steht für die Menge der in diesem `dp_rank` gespeicherten Module, und die Notation `X:y` steht für den `y`. Bruchteil des Moduls `X`. Beachten Sie Folgendes:
1. Die Partitionierung erfolgt über Teilmengen von datenparallelen Rängen hinweg, die wir `TP_GROUP` nennen, nicht über die gesamte `DP_GROUP`, so dass die genaue Modellpartition über `dp_rank` 0 und `dp_rank` 2 und in ähnlicher Weise über `dp_rank` 1 und `dp_rank` 3 repliziert wird.
1. Die Module `E` und `F` gehören nicht mehr zum Modell, da ihr übergeordnetes Modul `B` partitioniert ist, und jede Ausführung, die normalerweise zu `E` und `F` gehört, findet innerhalb des (partitionierten) `B` Moduls statt.
1. Obwohl `H` für die Tensor-Parallelität unterstützt wird, wird es in diesem Beispiel nicht partitioniert. Das verdeutlicht, dass es von Benutzereingaben abhängt, ob ein Modul partitioniert werden soll oder nicht. Die Tatsache, dass ein Modul für Tensor-Parallelität unterstützt wird, bedeutet nicht unbedingt, dass es partitioniert wird.
## Wie die Bibliothek die Tensorparallelität an das Modul anpasst PyTorch `nn.Linear`
Wenn die Tensor-Parallelität über datenparallele Ränge ausgeführt wird, wird eine Teilmenge der Parameter, Steigungen und Optimierer-Zustände über die tensorparallelen Geräte *für die partitionierten Module* hinweg partitioniert. Für die übrigen Module arbeiten die tensorparallelen Geräte in der regulär datenparallelen Weise. Um das partitionierte Modul auszuführen, sammelt ein Gerät zunächst die erforderlichen Teile *aller Datenstichproben* auf Peer-Geräten in derselben Tensor-Parallelitätsgruppe. Das Gerät führt dann den lokalen Teil des Moduls für all diese Datenproben aus, gefolgt von einer weiteren Synchronisationsrunde, bei der sowohl die Teile der Ausgabe für jede Datenprobe kombiniert als auch die kombinierten Datenproben an die zurückgegeben werden, GPUs aus der die Datenprobe zuerst stammt. Die folgende Abbildung zeigt ein Beispiel für diesen Prozess in einem partitionierten `nn.Linear` Modul.
![\[Zwei Abbildungen zeigen zwei Tensorparallelkonzepte.\]](http://docs.aws.amazon.com/de_de/sagemaker/latest/dg/images/distributed/model-parallel/tensor-parallel-concept.png)
Die erste Abbildung zeigt ein kleines Modell mit einem großen `nn.Linear` Modul mit Datenparallelität über die beiden Tensor-Parallelitätsränge. Das `nn.Linear` Modul wird in die beiden parallelen Ränge repliziert.
Die zweite Abbildung zeigt die Anwendung der Tensor-Parallelität auf ein größeres Modell bei der Aufteilung des `nn.Linear` Moduls. Jedes `tp_rank` enthält die Hälfte des linearen Moduls und die Gesamtheit der übrigen Operationen. Während das lineare Modul läuft, sammelt jedes `tp_rank` die entsprechende Hälfte aller Datenstichproben und übergibt sie an die jeweils andere Hälfte des `nn.Linear` Moduls. Das Ergebnis muss mit reduzierter Streuung (mit Summierung als Reduktionsvorgang) berechnet werden, so dass jeder Rang die endgültige lineare Ausgabe für seine eigenen Datenstichproben erhält. Der Rest des Modells läuft in der typischen datenparallelen Weise.
# Führen Sie einen parallelen Trainingsjob für SageMaker verteilte Modelle mit Tensorparallelismus aus
In diesem Abschnitt lernen Sie:
+ So konfigurieren Sie einen SageMaker PyTorch Schätzer und die Option SageMaker Modellparallelität, um Tensorparallelität zu verwenden.
+ Wie Sie Ihr Trainingsskript mithilfe der erweiterten `smdistributed.modelparallel` Module für Tensor-Parallelität anpassen.
Weitere Informationen zu den `smdistributed.modelparallel` Modulen finden Sie in der [SageMaker Modellparallele APIs](https://sagemaker.readthedocs.io/en/v2.199.0/api/training/smd_model_parallel.html) in der *SageMaker Python SDK-Dokumentation*.
**Topics**
+ [Tensor-Parallelität allein](#model-parallel-extended-features-pytorch-tensor-parallelism-alone)
+ [Tensor-Parallelität kombiniert mit Pipeline-Parallelität](#model-parallel-extended-features-pytorch-tensor-and-pipeline-parallelism)
## Tensor-Parallelität allein
Im Folgenden sehen Sie ein Beispiel für eine verteilte Trainingsoption zur Aktivierung der Tensor-Parallelität allein, ohne Pipeline-Parallelität. Konfigurieren Sie die `smp_options` Wörterbücher `mpi_options` und, um verteilte Trainingsoptionen für den SageMaker `PyTorch` Schätzer anzugeben.
**Anmerkung**
Erweiterte Funktionen zum Speichern von Speicherplatz sind über Deep Learning Containers for verfügbar PyTorch, das die SageMaker Modellparallelismusbibliothek v1.6.0 oder höher implementiert.
** SageMaker PyTorch Konfigurieren Sie einen Schätzer**
```
mpi_options = {
"enabled" : True,
"processes_per_host" : 8, # 8 processes
"custom_mpi_options" : "--mca btl_vader_single_copy_mechanism none "
}
smp_options = {
"enabled":True,
"parameters": {
"pipeline_parallel_degree": 1, # alias for "partitions"
"placement_strategy": "cluster",
"tensor_parallel_degree": 4, # tp over 4 devices
"ddp": True
}
}
smp_estimator = PyTorch(
entry_point='your_training_script.py', # Specify
role=role,
instance_type='ml.p3.16xlarge',
sagemaker_session=sagemaker_session,
framework_version='1.13.1',
py_version='py36',
instance_count=1,
distribution={
"smdistributed": {"modelparallel": smp_options},
"mpi": mpi_options
},
base_job_name="SMD-MP-demo",
)
smp_estimator.fit('s3://my_bucket/my_training_data/')
```
**Tipp**
Eine vollständige Liste der Parameter für `distribution` finden Sie unter [Konfigurationsparameter für Modellparallelismus](https://sagemaker.readthedocs.io/en/v2.199.0/api/training/smd_model_parallel_general.html) in der SageMaker Python SDK-Dokumentation.
**Passen Sie Ihr Trainingsskript PyTorch an**
Das folgende Beispiel-Trainingsskript zeigt, wie Sie die SageMaker Modellparallelitätsbibliothek an ein Trainingsskript anpassen. Bei diesem Beispiel wird davon ausgegangen, dass das Skript den Namen `your_training_script.py` trägt.
```
import torch
import torch.nn as nn
import torch.nn.functional as F
import torch.optim as optim
from torchnet.dataset import SplitDataset
from torchvision import datasets
import smdistributed.modelparallel.torch as smp
class Net(nn.Module):
def __init__(self):
super(Net, self).__init__()
self.conv1 = nn.Conv2d(1, 32, 3, 1)
self.conv2 = nn.Conv2d(32, 64, 3, 1)
self.fc1 = nn.Linear(9216, 128)
self.fc2 = nn.Linear(128, 10)
def forward(self, x):
x = self.conv1(x)
x = F.relu(x)
x = self.conv2(x)
x = F.relu(x)
x = F.max_pool2d(x, 2)
x = torch.flatten(x, 1)
x = self.fc1(x)
x = F.relu(x)
x = self.fc2(x)
return F.log_softmax(x, 1)
def train(model, device, train_loader, optimizer):
model.train()
for batch_idx, (data, target) in enumerate(train_loader):
# smdistributed: Move input tensors to the GPU ID used by
# the current process, based on the set_device call.
data, target = data.to(device), target.to(device)
optimizer.zero_grad()
output = model(data)
loss = F.nll_loss(output, target, reduction="mean")
loss.backward()
optimizer.step()
# smdistributed: Initialize the backend
smp.init()
# smdistributed: Set the device to the GPU ID used by the current process.
# Input tensors should be transferred to this device.
torch.cuda.set_device(smp.local_rank())
device = torch.device("cuda")
# smdistributed: Download only on a single process per instance.
# When this is not present, the file is corrupted by multiple processes trying
# to download and extract at the same time
if smp.local_rank() == 0:
dataset = datasets.MNIST("../data", train=True, download=False)
smp.barrier()
# smdistributed: Shard the dataset based on data parallel ranks
if smp.dp_size() > 1:
partitions_dict = {f"{i}": 1 / smp.dp_size() for i in range(smp.dp_size())}
dataset = SplitDataset(dataset, partitions=partitions_dict)
dataset.select(f"{smp.dp_rank()}")
train_loader = torch.utils.data.DataLoader(dataset, batch_size=64)
# smdistributed: Enable tensor parallelism for all supported modules in the model
# i.e., nn.Linear in this case. Alternatively, we can use
# smp.set_tensor_parallelism(model.fc1, True)
# to enable it only for model.fc1
with smp.tensor_parallelism():
model = Net()
# smdistributed: Use the DistributedModel wrapper to distribute the
# modules for which tensor parallelism is enabled
model = smp.DistributedModel(model)
optimizer = optim.AdaDelta(model.parameters(), lr=4.0)
optimizer = smp.DistributedOptimizer(optimizer)
train(model, device, train_loader, optimizer)
```
## Tensor-Parallelität kombiniert mit Pipeline-Parallelität
Das Folgende ist ein Beispiel für eine verteilte Trainingsoption, die Tensorparallelität in Kombination mit Pipeline-Parallelität ermöglicht. Richten Sie die `smp_options` Parameter `mpi_options` und ein, um Modellparalleloptionen mit Tensorparallelität zu spezifizieren, wenn Sie einen Schätzer konfigurieren. SageMaker `PyTorch`
**Anmerkung**
Erweiterte Funktionen zum Speichern von Speicherplatz sind über Deep Learning Containers for verfügbar PyTorch, das die SageMaker Modellparallelismusbibliothek v1.6.0 oder höher implementiert.
** SageMaker PyTorch Konfigurieren Sie einen Schätzer**
```
mpi_options = {
"enabled" : True,
"processes_per_host" : 8, # 8 processes
"custom_mpi_options" : "--mca btl_vader_single_copy_mechanism none "
}
smp_options = {
"enabled":True,
"parameters": {
"microbatches": 4,
"pipeline_parallel_degree": 2, # alias for "partitions"
"placement_strategy": "cluster",
"tensor_parallel_degree": 2, # tp over 2 devices
"ddp": True
}
}
smp_estimator = PyTorch(
entry_point='your_training_script.py', # Specify
role=role,
instance_type='ml.p3.16xlarge',
sagemaker_session=sagemaker_session,
framework_version='1.13.1',
py_version='py36',
instance_count=1,
distribution={
"smdistributed": {"modelparallel": smp_options},
"mpi": mpi_options
},
base_job_name="SMD-MP-demo",
)
smp_estimator.fit('s3://my_bucket/my_training_data/')
```
**Passen Sie Ihr PyTorch Trainingsskript an**
Das folgende Beispiel-Trainingsskript zeigt, wie Sie die SageMaker Modellparallelitätsbibliothek an ein Trainingsskript anpassen. Beachten Sie, dass das Trainingsskript jetzt den `smp.step` Decorator enthält:
```
import torch
import torch.nn as nn
import torch.nn.functional as F
import torch.optim as optim
from torchnet.dataset import SplitDataset
from torchvision import datasets
import smdistributed.modelparallel.torch as smp
class Net(nn.Module):
def __init__(self):
super(Net, self).__init__()
self.conv1 = nn.Conv2d(1, 32, 3, 1)
self.conv2 = nn.Conv2d(32, 64, 3, 1)
self.fc1 = nn.Linear(9216, 128)
self.fc2 = nn.Linear(128, 10)
def forward(self, x):
x = self.conv1(x)
x = F.relu(x)
x = self.conv2(x)
x = F.relu(x)
x = F.max_pool2d(x, 2)
x = torch.flatten(x, 1)
x = self.fc1(x)
x = F.relu(x)
x = self.fc2(x)
return F.log_softmax(x, 1)
# smdistributed: Define smp.step. Return any tensors needed outside.
@smp.step
def train_step(model, data, target):
output = model(data)
loss = F.nll_loss(output, target, reduction="mean")
model.backward(loss)
return output, loss
def train(model, device, train_loader, optimizer):
model.train()
for batch_idx, (data, target) in enumerate(train_loader):
# smdistributed: Move input tensors to the GPU ID used by
# the current process, based on the set_device call.
data, target = data.to(device), target.to(device)
optimizer.zero_grad()
# Return value, loss_mb is a StepOutput object
_, loss_mb = train_step(model, data, target)
# smdistributed: Average the loss across microbatches.
loss = loss_mb.reduce_mean()
optimizer.step()
# smdistributed: Initialize the backend
smp.init()
# smdistributed: Set the device to the GPU ID used by the current process.
# Input tensors should be transferred to this device.
torch.cuda.set_device(smp.local_rank())
device = torch.device("cuda")
# smdistributed: Download only on a single process per instance.
# When this is not present, the file is corrupted by multiple processes trying
# to download and extract at the same time
if smp.local_rank() == 0:
dataset = datasets.MNIST("../data", train=True, download=False)
smp.barrier()
# smdistributed: Shard the dataset based on data parallel ranks
if smp.dp_size() > 1:
partitions_dict = {f"{i}": 1 / smp.dp_size() for i in range(smp.dp_size())}
dataset = SplitDataset(dataset, partitions=partitions_dict)
dataset.select(f"{smp.dp_rank()}")
# smdistributed: Set drop_last=True to ensure that batch size is always divisible
# by the number of microbatches
train_loader = torch.utils.data.DataLoader(dataset, batch_size=64, drop_last=True)
model = Net()
# smdistributed: enable tensor parallelism only for model.fc1
smp.set_tensor_parallelism(model.fc1, True)
# smdistributed: Use the DistributedModel container to provide the model
# to be partitioned across different ranks. For the rest of the script,
# the returned DistributedModel object should be used in place of
# the model provided for DistributedModel class instantiation.
model = smp.DistributedModel(model)
optimizer = optim.AdaDelta(model.parameters(), lr=4.0)
optimizer = smp.DistributedOptimizer(optimizer)
train(model, device, train_loader, optimizer)
```
# Support für Hugging Face Transformator-Modelle
Die Tensorparallelität der SageMaker Modellparallelitätsbibliothek bietet out-of-the-box Unterstützung für die folgenden Hugging Face Transformer-Modelle:
+ GPT-2, BERT und Ro BERTa (verfügbar in der Modellparallelitätsbibliothek v1.7.0 und höher) SageMaker
+ GPT-J (Verfügbar in der Modellparallelismus-Bibliothek v1.8.0 und höher SageMaker )
+ GPT-Neo (Verfügbar in der Modellparallelismus-Bibliothek v1.10.0 und höher SageMaker )
**Anmerkung**
Für alle anderen Transformer-Modelle müssen Sie die API [smdistributed.modelparallel.torch.tp\$1register\$1with\$1module()](https://sagemaker.readthedocs.io/en/v2.199.0/api/training/smp_versions/latest/smd_model_parallel_pytorch_tensor_parallel.html#smdistributed.modelparallel.torch.tp_register_with_module) verwenden, um die Tensor-Parallelität anzuwenden.
**Anmerkung**
Um Tensorparallelität für das Training von Hugging Face Transformer-Modellen zu verwenden, stellen Sie sicher, dass Sie Hugging Face Deep Learning Containers verwenden, für die die Modellparallelismusbibliothek v1.7.0 und PyTorch höher verfügbar ist. SageMaker [Weitere Informationen finden Sie in den Versionshinweisen zur Modellparallelismus-Bibliothek. SageMaker ](https://sagemaker.readthedocs.io/en/v2.199.0/api/training/smd_model_parallel_release_notes/smd_model_parallel_change_log.html)
## Ab Werk unterstützte Modelle
Für die Hugging Face Face-Transformer-Modelle, die von der Bibliothek standardmäßig unterstützt werden, müssen Sie Hooks nicht manuell implementieren, um Transformer in Transformer-Ebenen APIs zu `smdistributed` übersetzen. [Sie können die Tensorparallelität aktivieren, indem Sie den Kontextmanager [smdistributed.modelparallel.torch.tensor\$1parallelism () verwenden und das Modell mit smdistributed.modelparallel.torch](https://sagemaker.readthedocs.io/en/v2.199.0/api/training/smp_versions/latest/smd_model_parallel_pytorch_tensor_parallel.html#smdistributed.modelparallel.torch.tensor_parallelism) umschließen. DistributedModel().](https://sagemaker.readthedocs.io/en/v2.199.0/api/training/smp_versions/latest/smd_model_parallel_pytorch.html#smdistributed.modelparallel.torch.DistributedModel) Sie brauchen für die Tensor-Parallelität keine Hooks mit Hilfe der `smp.tp_register` API manuell zu registrieren.
Die `state_dict` Übersetzung funktioniert zwischen Hugging Face Transformers und `smdistributed.modelparallel` kann wie folgt aufgerufen werden.
+ `smdistributed.modelparallel.torch.nn.huggingface.gpt2.translate_state_dict_to_hf_gpt2(state_dict, max_seq_len=None)`
+ `smdistributed.modelparallel.torch.nn.huggingface.gpt2.translate_hf_state_dict_to_smdistributed_gpt2(state_dict)`
+ `smdistributed.modelparallel.torch.nn.huggingface.bert.translate_state_dict_to_hf_bert(state_dict, max_seq_len=None)`
+ `smdistributed.modelparallel.torch.nn.huggingface.bert.translate_hf_state_dict_to_smdistributed_bert(state_dict)`
+ `smdistributed.modelparallel.torch.nn.huggingface.roberta.translate_state_dict_to_hf_roberta(state_dict, max_seq_len=None)`
+ `smdistributed.modelparallel.torch.nn.huggingface.roberta.translate_hf_state_dict_to_smdistributed_roberta(state_dict)`
+ `smdistributed.modelparallel.torch.nn.huggingface.gptj.translate_state_dict_to_hf_gptj(state_dict, max_seq_len=None)`(Verfügbar in der SageMaker Modellparallelismus-Bibliothek v1.8.0 und höher)
+ `smdistributed.modelparallel.torch.nn.huggingface.gptj.translate_hf_gptj_state_dict_to_smdistributed_gptj`(Verfügbar in der SageMaker Modellparallelismus-Bibliothek v1.8.0 und höher)
+ `smdistributed.modelparallel.torch.nn.huggingface.gptneo.translate_state_dict_to_hf_gptneo(state_dict, max_seq_len=None)`(Verfügbar in der SageMaker Modellparallelismus-Bibliothek v1.10.0 und höher)
+ `smdistributed.modelparallel.torch.nn.huggingface.gptneo.translate_hf_state_dict_to_smdistributed_gptneo(state_dict)`(Verfügbar in der SageMaker Modellparallelismus-Bibliothek v1.10.0 und höher)
**Beispiel für die Verwendung der GPT-2-Übersetzungsfunktion**
Beginnen Sie damit, das Modell wie im folgenden Code gezeigt zu umschließen:
```
from transformers import AutoModelForCausalLM
with smp.tensor_parallelism():
model = AutoModelForCausalLM.from_config(hf_gpt2_config)
model = smp.DistributedModel(model)
```
Ausgehend von `state_dict` von einem `DistributedModel` Objekt können Sie die Gewichtungen mithilfe der im folgenden Code gezeigten `translate_state_dict_to_hf_gpt2` Funktion in das ursprüngliche Hugging Face GPT-2-Modell laden.
```
from smdistributed.modelparallel.torch.nn.huggingface.gpt2 \
import translate_state_dict_to_hf_gpt2
max_seq_len = 1024
# [... code block for training ...]
if smp.rdp_rank() == 0:
state_dict = dist_model.state_dict()
hf_state_dict = translate_state_dict_to_hf_gpt2(state_dict, max_seq_len)
# can now call model.load_state_dict(hf_state_dict) to the original HF model
```
**Beispiel für die Verwendung der Ro-Übersetzungsfunktion BERTa **
In ähnlicher Weise können Sie bei einem unterstützten HuggingFace Modell die `translate_hf_state_dict_to_smdistributed` Funktion verwenden`state_dict`, um es in ein von lesbares Format zu konvertieren`smp.DistributedModel`. Dies kann bei Anwendungsfällen für Transfer Learning nützlich sein, wo ein vortrainiertes Modell zur parallelen Feinabstimmung des Modells in ein `smp.DistributedModel` geladen wird:
```
from smdistributed.modelparallel.torch.nn.huggingface.roberta \
import translate_state_dict_to_smdistributed
model = AutoModelForMaskedLM.from_config(roberta_config)
model = smp.DistributedModel(model)
pretrained_model = AutoModelForMaskedLM.from_pretrained("roberta-large")
translated_state_dict =
translate_state_dict_to_smdistributed(pretrained_model.state_dict())
# load the translated pretrained weights into the smp.DistributedModel
model.load_state_dict(translated_state_dict)
# start fine-tuning...
```
# Rangfolgemechanismus bei Verwendung einer Kombination aus Pipeline-Parallelität und Tensor-Parallelität
In diesem Abschnitt wird erklärt, wie der Rangfolgemechanismus der Modellparallelität mit der Tensor-Parallelität funktioniert. Dies ist die erweiterte Form der [Grundlagen der Rangfolge](https://sagemaker.readthedocs.io/en/v2.199.0/api/training/smd_model_parallel_general.html#ranking-basics) für [Kernfunktionen der SageMaker Model Parallelism Library](model-parallel-core-features.md). Mit der Tensorparallelität führt die Bibliothek drei Arten von Rangfolge und Prozessgruppe ein APIs: `smp.tp_rank()` für den parallelen Tensorrang, für den parallel Pipeline-Rang und `smp.pp_rank()` `smp.rdp_rank()` für den parallel Rang mit reduzierten Daten. Die entsprechenden Kommunikationsprozessgruppen sind die Tensor-Parallelgruppe (`TP_GROUP`), die Pipeline-Parallelgruppe (`PP_GROUP`) und die Parallelgruppe für reduzierte Daten (`RDP_GROUP`). Diese Gruppen sind wie folgt definiert:
+ Eine *Tensor-Parallelgruppe* (`TP_GROUP`) ist eine gleichmäßig teilbare Teilmenge der Daten-Parallelgruppe, über die die tensorparallele Verteilung von Modulen erfolgt. Wenn der Grad der Pipeline-Parallelität 1 ist, entspricht `TP_GROUP` der *Modell-Parallelgruppe* (`MP_GROUP`).
+ Eine *Pipeline-Parallelgruppe* (`PP_GROUP`) ist die Gruppe von Prozessen, über die die Pipeline-Parallelität erfolgt. Wenn der Grad der Tensor-Parallelität 1 ist, so ist `PP_GROUP` das Gleiche wie `MP_GROUP`.
+ Eine *Parallelgruppe für reduzierte Daten* (`RDP_GROUP`) ist eine Menge von Prozessen, die sowohl dieselben Pipeline-Parallelitätspartitionen als auch dieselben Tensor-Parallelitätspartitionen enthalten und untereinander Datenparallelität durchführen. Eine solche Gruppe wird als Parallelgruppe für reduzierte Daten bezeichnet, da es sich dabei um eine Teilmenge der gesamten Datenparallelitätsgruppe `DP_GROUP` handelt. Für die Modellparameter, die innerhalb der `TP_GROUP` verteilt sind, erfolgt die `allreduce` Steigungsoperation nur für die Parallelgruppe mit reduzierten Daten, während für die Parameter, die nicht verteilt sind, die Steigung `allreduce` über die gesamte `DP_GROUP` erfolgt.
+ Eine Modell-Parallelgruppe (`MP_GROUP`) bezieht sich auf eine Gruppe von Prozessen, die gemeinsam das gesamte Modell speichern. Sie besteht aus der Vereinigung der `PP_GROUP`s aller Ränge, die sich im `TP_GROUP` der aktuellen Prozess befinden. Wenn der Grad der Tensor-Parallelität 1 ist, entspricht `MP_GROUP` `PP_GROUP`. Sie entspricht auch der bestehenden Definition von `MP_GROUP` aus früheren `smdistributed` Versionen. Beachten Sie, dass die aktuelle `TP_GROUP` eine Teilmenge sowohl des aktuellen `DP_GROUP` als auch des aktuellen `MP_GROUP` ist.
Weitere Informationen zum Kommunikationsprozess APIs in der SageMaker Modellparallelismus-Bibliothek finden Sie unter [Common API](https://sagemaker.readthedocs.io/en/v2.199.0/api/training/smp_versions/latest/smd_model_parallel_common_api.html#) und [PyTorch-specific APIs](https://sagemaker.readthedocs.io/en/v2.199.0/api/training/smp_versions/latest/smd_model_parallel_pytorch.html) in der *SageMaker Python* SDK-Dokumentation.
![\[Ranking-Mechanismus, Parameterverteilung und damit verbundene AllReduce Operationen der Tensorparallelität.\]](http://docs.aws.amazon.com/de_de/sagemaker/latest/dg/images/distributed/model-parallel/tensor-parallel-ranking-mechanism.png)
Stellen Sie sich beispielsweise Prozessgruppen für einen einzelnen Knoten mit 8 vor GPUs, wobei der Grad der Tensorparallelität 2, der Grad der Pipeline-Parallelität 2 und der Grad der Datenparallelität 4 ist. Der obere mittlere Teil der Abbildung weiter oben zeigt ein Beispiel für ein Modell mit 4 Layers. Die unteren linken und unteren rechten Teile der Abbildung veranschaulichen das 4-Schichten-Modell, das auf 4 verteilt ist und sowohl Pipeline-Parallelität als auch Tensorparallelität GPUs verwendet, wobei Tensorparallelität für die beiden mittleren Schichten verwendet wird. Diese beiden unteren Abbildungen sind einfache Kopien zur Veranschaulichung der Grenzlinien zwischen den verschiedenen Gruppen. Das partitionierte Modell wird aus Gründen der Datenparallelität zwischen 0-3 und 4-7 repliziert. GPUs Die Abbildung unten links zeigt die Definitionen von `MP_GROUP`, `PP_GROUP` und `TP_GROUP`. Die Abbildung unten rechts zeigt `RDP_GROUP``DP_GROUP`, und `WORLD` über demselben Satz von. GPUs Die Steigungen für die Ebenen und Layer-Slices, die dieselbe Farbe haben, werden aus Gründen der Datenparallelität zusammengefasst`allreduce`. z. B. erhält die erste Layer (hellblau) die `allreduce` Operationen über `DP_GROUP`. Dagegen erhält die dunkelorangefarbene Layer in der zweiten Layer nur die `allreduce` Operationen innerhalb der `RDP_GROUP` ihres Prozesses. Die fetten dunkelroten Pfeile stehen für Tensoren mit dem Batch aus ihren gesamten `TP_GROUP`.
```
GPU0: pp_rank 0, tp_rank 0, rdp_rank 0, dp_rank 0, mp_rank 0
GPU1: pp_rank 1, tp_rank 0, rdp_rank 0, dp_rank 0, mp_rank 1
GPU2: pp_rank 0, tp_rank 1, rdp_rank 0, dp_rank 1, mp_rank 2
GPU3: pp_rank 1, tp_rank 1, rdp_rank 0, dp_rank 1, mp_rank 3
GPU4: pp_rank 0, tp_rank 0, rdp_rank 1, dp_rank 2, mp_rank 0
GPU5: pp_rank 1, tp_rank 0, rdp_rank 1, dp_rank 2, mp_rank 1
GPU6: pp_rank 0, tp_rank 1, rdp_rank 1, dp_rank 3, mp_rank 2
GPU7: pp_rank 1, tp_rank 1, rdp_rank 1, dp_rank 3, mp_rank 3
```
In diesem Beispiel tritt Pipeline-Parallelität zwischen den GPU-Paaren (0,1); (2,3); (4,5) und (6,7) auf. Darüber hinaus findet Datenparallelität (`allreduce`) über GPUs 0, 2, 4, 6 und unabhängig über GPUs 1, 3, 5, 7 statt. Tensor-Parallelität tritt über Teilmengen von `DP_GROUP`s auf, über die GPU-Paare (0,2); (1,3); (4,6) und (5,7).
Für eine hybride Pipeline- und Tensor-Parallelität dieser Art bleibt die mathematische Behandlung für `data_parallel_degree` wie bei `data_parallel_degree = number_of_GPUs / pipeline_parallel_degree`. Die Bibliothek berechnet außerdem den reduzierten Daten-Parallelitätsgrad anhand der folgenden Beziehung `reduced_data_parallel_degree * tensor_parallel_degree = data_parallel_degree`.
# Optimizer-Zustandsfragmentierung
Die *Optimizer-Zustandsfragmentierung* ist eine nützliche Technik zur Speichereinsparung, bei der der Optimizer-Zustand (die Menge der Gewichtungen, die den Zustand des Optimierers beschreiben) auf datenparallele Gerätegruppen fragmentiert wird. Sie können das State-Sharding des Optimizers immer dann verwenden, wenn Sie einen Stateful-Optimizer (wie Adam) oder einen FP16 Optimizer (der beide FP16 und Kopien der Parameter speichert) verwenden. FP32
**Anmerkung**
Das State-Sharding von Optimizer ist PyTorch in der Modellparallelismus-Bibliothek v1.6.0 und höher verfügbar. SageMaker
## So wird die Optimizer-Zustandsfragmentierung verwendet
Die *Optimizer-Zustandsfragmentierung* können Sie aktivieren, indem Sie in der `modelparallel` Konfiguration `"shard_optimizer_state": True` einstellen.
Wenn diese Funktion aktiviert ist, partitioniert die Bibliothek die Menge der Modellparameter anhand des Datenparallelitätsgrades. Die Steigungen, die `i`-ten Partition entsprechen, werden erst im `i`ten Datenparallelrang reduziert. Am Ende des ersten Aufrufs einer `smp.step` Decorator-Funktion definiert der mit `smp.DistributedOptimizer` umschlossene Optimizer seine Parameter neu, so dass sie auf diejenigen Parameter beschränkt sind, die der Partition des aktuellen Datenparallelrangs entsprechen. Die neu definierten Parameter werden als *virtuelle Parameter* bezeichnet und teilen sich den zugrunde liegenden Speicher mit den ursprünglichen Parametern. Beim ersten Aufruf von `optimizer.step` werden die Optimierer-Zustände anhand dieser neu definierten Parameter erstellt, die aufgrund der ursprünglichen Partition fragmentiert sind. Nach dem Optimierer-Update wird der AllGather Vorgang (als Teil des `optimizer.step` Aufrufs) über die parallel Datenränge hinweg ausgeführt, um konsistente Parameterstatus zu erreichen.
**Tipp**
Die Optimizer-Zustandsfragmentierung kann nützlich sein, wenn der Daten-Parallelitätsgrad größer ist als 1 und das Modell mehr als eine Milliarde Parameter hat.
Der Daten-Parallelitätsgrad wird nach `(processes_per_host * instance_count / pipeline_parallel_degree)` berechnet, und die `smp.dp_size()` Funktion übernimmt im Hintergrund die Größenanpassung.
**Konfigurieren Sie einen SageMaker PyTorch Schätzer**
```
mpi_options = {
"enabled" : True,
"processes_per_host" : 8, # 8 processes
"custom_mpi_options" : "--mca btl_vader_single_copy_mechanism none "
}
smp_options = {
"enabled":True,
"parameters": {
"microbatches": 4,
"pipeline_parallel_degree": 2, # alias for "partitions"
"placement_strategy": "cluster",
"tensor_parallel_degree": 2, # tp over 2 devices
"ddp": True,
"shard_optimizer_state": True
}
}
```
**Passen Sie Ihr PyTorch Trainingsskript an**
Weitere Informationen finden Sie unter [Anpassen Ihres PyTorch Trainingsskripts](model-parallel-extended-features-pytorch-tensor-parallelism-examples.md#model-parallel-extended-features-pytorch-tensor-and-pipeline-parallelism-script) im Abschnitt *Tensor-Parallelität kombiniert mit Pipeline-Parallelität*. Für das Skript sind keine weiteren Änderungen erforderlich.
# Aktivierungs-Prüfpunkte
Bei den *Aktivierungs-Prüfpunkten* (oder *Steigungs-Prüfpunkten*) handelt es sich um eine Technik zur Reduzierung der Speicherbelegung, indem Aktivierungen bestimmter Layers gelöscht und bei einem Rücklauf neu berechnet werden. Dadurch wird zusätzliche Datenverarbeitungszeit effektiv gegen eine geringere Speicherauslastung eingetauscht. Wenn ein Modul mit einem Prüfpunkt versehen wird, bleiben am Ende eines Vorwärtsdurchlaufs die Ein- und Ausgaben des Moduls im Speicher. Alle Tensoren, die zwischenzeitlich Teil der Berechnung innerhalb dieses Moduls gewesen wären, werden während des Vorwärtsdurchlaufs wieder freigegeben. Beim Rückwärtsdurchlauf von Modulen mit Prüfpunkten werden diese Tensoren neu berechnet. Zu diesem Zeitpunkt haben die Layers hinter diesem Prüfpunkt-Modul ihren Rückwärtsdurchlauf abgeschlossen, so dass die maximale Speichernutzung mit Prüfpunkten geringer sein kann.
**Anmerkung**
Diese Funktion ist PyTorch in der SageMaker Modellparallelitätsbibliothek v1.6.0 und höher verfügbar.
## So werden Aktivierungs-Prüfpunkte verwendet
Mit `smdistributed.modelparallel` können Sie Aktivierungs-Prüfpunkte bei der Granularität eines Moduls verwenden. Für alle `torch.nn` Module außer `torch.nn.Sequential` können Sie Prüfpunkte für einen Modulbaum nur verwenden, wenn er aus Sicht der Pipeline-Parallelität innerhalb einer Partition liegt. Im Fall des `torch.nn.Sequential` Moduls muss jeder Modulbaum innerhalb des sequentiellen Moduls vollständig innerhalb einer Partition liegen, damit die Aktivierungs-Prüfpunkte funktionieren. Diese Einschränkungen sollten Sie berücksichtigen, wenn Sie die manuelle Partitionierung verwenden.
Wenn Sie die [automatisierte Modellpartitionierung](https://docs.aws.amazon.com/sagemaker/latest/dg/model-parallel-core-features.html#model-parallel-automated-model-splitting) verwenden, finden Sie die Protokolle der Partitionierungszuweisungen, beginnend mit `Partition assignments:` in den Protokollen der Trainingsaufträge. Wenn ein Modul über mehrere Ränge partitioniert ist (z. B. mit einem abstammenden Element auf einem Rang und einem anderen auf einem anderen Rang), ignoriert die Bibliothek den Versuch, für das Modul einen Checkpoint zu setzen, und gibt eine Warnmeldung aus, dass für das Modul kein Prüfpunkt verwendet wird.
**Anmerkung**
Die SageMaker Modellparallelitätsbibliothek unterstützt sowohl überlappende als auch nicht `allreduce` überlappende Operationen in Kombination mit Checkpointing.
**Anmerkung**
PyTorchDie native Checkpointing-API ist nicht kompatibel mit. `smdistributed.modelparallel`
**Beispiel 1:** Der folgende Beispielcode zeigt, wie Sie Aktivierungsprüfpunkte verwenden, wenn Sie in Ihrem Skript eine Modelldefinition haben.
```
import torch.nn as nn
import torch.nn.functional as F
from smdistributed.modelparallel.torch.patches.checkpoint import checkpoint
class Net(nn.Module):
def __init__(self):
super(Net, self).__init__()
self.conv1 = nn.Conv2d(1, 32, 3, 1)
self.conv2 = nn.Conv2d(32, 64, 3, 1)
self.fc1 = nn.Linear(9216, 128)
self.fc2 = nn.Linear(128, 10)
def forward(self, x):
x = self.conv1(x)
x = self.conv2(x)
x = F.max_pool2d(x, 2)
x = torch.flatten(x, 1)
# This call of fc1 will be checkpointed
x = checkpoint(self.fc1, x)
x = self.fc2(x)
return F.log_softmax(x, 1)
```
**Beispiel 2:** Der folgende Beispielcode zeigt, wie Sie Aktivierungs-Prüfpunkte verwenden, wenn Ihr Skript ein sequentielles Modell enthält.
```
import torch.nn as nn
from smdistributed.modelparallel.torch.patches.checkpoint import checkpoint_sequential
class Net(nn.Module):
def __init__(self):
super(Net, self).__init__()
self.seq = nn.Sequential(
nn.Conv2d(1,20,5),
nn.ReLU(),
nn.Conv2d(20,64,5),
nn.ReLU()
)
def forward(self, x):
# This call of self.seq will be checkpointed
x = checkpoint_sequential(self.seq, x)
return F.log_softmax(x, 1)
```
**Beispiel 3:** Der folgende Beispielcode zeigt, wie Aktivierungsprüfpunkte verwendet werden, wenn Sie ein vorgefertigtes Modell aus einer Bibliothek importieren, z. B. Hugging PyTorch Face Transformers. Gehen Sie wie folgt vor, unabhängig davon, ob Sie sequentielle Module mit Prüfpunkten versehen oder nicht:
1. Umschließen Sie das Modell mit `smp.DistributedModel()`.
1. Definieren Sie ein Objekt für sequenzielle Ebenen.
1. Umschließen Sie das sequentielle Layer-Objekt mit `smp.set_activation_checkpointig()`.
```
import smdistributed.modelparallel.torch as smp
from transformers import AutoModelForCausalLM
smp.init()
model = AutoModelForCausalLM(*args, **kwargs)
model = smp.DistributedModel(model)
# Call set_activation_checkpointing API
transformer_layers = model.module.module.module.transformer.seq_layers
smp.set_activation_checkpointing(
transformer_layers, pack_args_as_tuple=True, strategy='each')
```
# Aktivierungs-Entladung
Wenn Aktivierungs-Prüfpunkte und Pipeline-Parallelität aktiviert sind und die Anzahl der Mikro-Batches größer als eins ist, ist das *Aktivierungs-Entladen* eine zusätzliche Funktion, mit der die Speichernutzung weiter reduziert werden kann. Beim Aktivierungs-Entladen werden die Prüfpunkt-Aktivierungen asynchron verschoben, entsprechend ihren Mikro-Batches, die aktuell nicht auf der CPU ausgeführt werden. Kurz bevor die GPU die Aktivierungen für den Rückwärtsdurchgang des Mikro-Batchs braucht, ruft diese Funktion die ausgelagerten Aktivierungen vorab von der CPU zurück.
**Anmerkung**
Diese Funktion ist PyTorch in der SageMaker Modellparallelismus-Bibliothek v1.6.0 und höher verfügbar.
## So wird die Aktivierungs-Entladung verwendet
Verwenden Sie das Aktivierungs-Entladen, um die Speichernutzung zu reduzieren, wenn **die Anzahl der Mikro-Batches größer als 1 ist und die Aktivierungs-Prüfpunkte aktiviert sind ** (siehe [Aktivierungs-Prüfpunkte](model-parallel-extended-features-pytorch-activation-checkpointing.md)). Wenn keine Aktivierungs-Prüfpunkte verwendet werden, hat das Aktivierungs-Entladen keine Wirkung. Wenn es mit nur einem Mikro-Batch verwendet wird, spart es keinen Speicherplatz.
Um Aktivierungs-Entladen zu verwenden, legen Sie `"offload_activations": True` in der `modelparallel` Konfiguration fest.
Beim Aktivierungs-Entladen werden die Prüfpunkt-Aktivierungen in `nn.Sequential` Modulen asynchron auf die CPU verschoben. Die Datenübertragung über die PCIe Verbindung überschneidet sich mit der GPU-Berechnung. Das Entladen erfolgt sofort, sobald der Vorwärtsdurchgang für eine bestimmte Prüfpunkt-Layer berechnet wurde. Die Aktivierungen werden wieder auf die GPU geladen, kurz bevor sie für den Rückwärtslauf eines bestimmten Mikro-Batches gebraucht werden. Der CPU-GPU-Transfer überschneidet sich in ähnlicher Weise mit der Berechnung.
Um einzustellen, wie früh die Aktivierungen wieder in die GPU geladen werden, können Sie den Konfigurationsparameter `"activation_loading_horizon"` verwenden (der Standardwert ist auf 4 gesetzt, und er muss `int` größer als 0 sein). Ein größerer Ladehorizont für die Aktivierung würde dazu führen, dass die Aktivierungen früher wieder auf die GPU geladen werden. Wenn der Horizont zu groß ist, kann sich die speichersparende Wirkung des Aktivierungs-Entladens verringern. Wenn der Horizont zu klein ist, können die Aktivierungen ggf. nicht rechtzeitig zurückgeladen werden. Dadurch wird der Umfang der Überschneidung verringert und die Leistung beeinträchtigt.
**Tipp**
Das Aktivierungs-Entladen kann für große Modelle mit über hundert Milliarden Parametern nützlich sein.
**Konfigurieren Sie einen Schätzer SageMaker PyTorch **
```
mpi_options = {
"enabled" : True,
"processes_per_host" : 8, # 8 processes
"custom_mpi_options" : "--mca btl_vader_single_copy_mechanism none "
}
smp_options = {
"enabled":True,
"parameters": {
"microbatches": 4,
"pipeline_parallel_degree": 2, # alias for "partitions"
"placement_strategy": "cluster",
"tensor_parallel_degree": 2, # tp over 2 devices
"ddp": True,
"offload_activations": True,
"activation_loading_horizon": 4 # optional. default is 4.
}
}
```
# FP16 Training mit Modellparallelität
Wenden Sie für das FP16 Training die folgenden Änderungen an Ihrem Trainingsskript und Ihrem Schätzer an.
**Anmerkung**
Diese Funktion ist PyTorch in der SageMaker Modellparallelismus-Bibliothek v1.10.0 und höher verfügbar.
**Passen Sie Ihr Trainingsskript an PyTorch **
1. Umschließen Sie Ihr Modell mit dem Kontextmanager [smdistributed.modelparallel.torch.model\$1creation()](https://sagemaker.readthedocs.io/en/v2.199.0/api/training/smp_versions/latest/smd_model_parallel_pytorch.html#smdistributed.modelparallel.torch.model_creation).
```
# fp16_training_script.py
import torch
import smdistributed.modelparallel.torch as smp
with smp.model_creation(
dtype=torch.float16 if args.fp16 else torch.get_default_dtype()
):
model = ...
```
**Tipp**
Wenn Sie Tensor-Parallelität verwenden, fügen Sie `tensor_parallelism=smp.tp_size() > 1` zum `smp.model_creation`Kontextmanager hinzu. Mit Hilfe dieser zusätzlichen Zeile kann auch automatisch erkannt werden, ob die Tensor-Parallelität aktiviert ist oder nicht.
```
with smp.model_creation(
... ,
tensor_parallelism=smp.tp_size() > 1
):
model = ...
```
1. Wenn Sie den Optimierer mit `smdistributed.modelparallel.torch.DistributedOptimizer` umschließen, setzen Sie entweder das Argument `static_loss_scaling` oder `dynamic_loss_scaling`. `static_loss_scaling` Ist standardmäßig auf `1.0` gesetzt und `dynamic_loss_scaling` ist auf `False` gesetzt. Wenn Sie `dynamic_loss_scale=True` einstellen, können Sie dynamische Verlustskalierungsoptionen als Wörterbuch über das Argument `dynamic_loss_args` einspeisen. In den meisten Fällen empfehlen wir die dynamische Verlustskalierung mit den Standardoptionen zu verwenden. [Weitere Informationen, Optionen und Beispiele für die Optimizer-Wrapper-Funktion finden Sie unter smdistributed.modelparallel.torch. DistributedOptimizer](https://sagemaker.readthedocs.io/en/v2.199.0/api/training/smp_versions/latest/smd_model_parallel_pytorch.html#smdistributed-modelparallel-torch-distributedoptimizer) API.
Der folgende Code ist ein Beispiel für das Umschließen eines `Adadelta` Optimiererobjekts mit dynamischer Verlustskalierung für das FP16 Training.
```
optimizer = torch.optim.Adadelta(...)
optimizer = smp.DistributedOptimizer(
optimizer,
static_loss_scale=None,
dynamic_loss_scale=True,
dynamic_loss_args={
"scale_window": 1000,
"min_scale": 1,
"delayed_shift": 2
}
)
```
**Konfigurieren Sie einen SageMaker PyTorch Schätzer**
Fügen Sie der Verteilungskonfiguration den FP16 Parameter (`"fp16"`) für Modellparallelität hinzu, wenn Sie ein SageMaker PyTorch Schätzerobjekt erstellen. Eine vollständige Liste der Konfigurationsparameter für Modellparallelität finden Sie unter [Parameter für `smdistributed`](https://sagemaker.readthedocs.io/en/v2.199.0/api/training/smd_model_parallel_general.html#parameters-for-smdistributed).
```
from sagemaker.pytorch import PyTorch
smp_options = {
"enabled": True,
"parameters": {
"microbatches": 4,
"pipeline_parallel_degree": 2,
"tensor_parallel_degree": 2,
...,
"fp16": True
}
}
fp16_estimator = PyTorch(
entry_point="fp16_training_script.py", # Specify your train script
...,
distribution={
"smdistributed": {"modelparallel": smp_options},
"mpi": {...}
}
)
fp16_estimator.fit(...)
```
[Wenn das FP16 Training beginnt, werden das Modell und der Optimizer von `FP16_Module``FP16_Optimizer` bzw. umschlossen. Dabei handelt es sich um modifizierte `smdistributed` Versionen der Apex-Utils.](https://nvidia.github.io/apex/fp16_utils.html#apex-fp16-utils) `FP16_Module`konvertiert das Modell in FP16 dtype und kümmert sich um die Weiterleitung. FP16
**Tipp**
Sie können die Steigungen beschneiden, indem Sie `clip_master_grads` vor `optimizer.step` aufrufen.
```
optimizer.clip_master_grads(max_norm) # max_norm(float or int): max norm of the gradients
```
**Tipp**
Bei der Verwendung `torch.optim.lr_scheduler` und beim FP16 Training müssen Sie sich `optimizer.optimizer` an den LR-Scheduler und nicht an den Optimizer wenden. Schauen Sie sich den folgenden Beispiel-Code an:
```
from torch.optim.lr_scheduler import StepLR
scheduler = StepLR(
optimizer.optimizer if smp.state.cfg.fp16 else optimizer,
step_size=1,
gamma=args.gamma
)
```
# Support für FlashAttention
Support für FlashAttention ist eine Funktion der Bibliothek, die nur für das *verteilte Transformer-Modell* gilt, bei dem es sich um ein Transformer-Modell handelt, das [https://sagemaker.readthedocs.io/en/v2.199.0/api/training/smp_versions/latest/smd_model_parallel_pytorch.html#smdistributed-modelparallel-torch-distributedmodel](https://sagemaker.readthedocs.io/en/v2.199.0/api/training/smp_versions/latest/smd_model_parallel_pytorch.html#smdistributed-modelparallel-torch-distributedmodel)für modellparalleles Training genutzt wird. Diese Funktion ist auch mit [Tensor-Parallelität](model-parallel-extended-features-pytorch-tensor-parallelism.md) kompatibel.
Die [FlashAttention](https://github.com/HazyResearch/flash-attention)Bibliothek unterstützt nur Modelle, wenn sie auf einen Wert gesetzt `attention_head_size` ist, der ein Vielfaches von 8 und kleiner als 128 ist. Wenn Sie also einen dezentralen Transformator trainieren und sicherstellen, dass er ordnungsgemäß FlashAttention funktioniert, sollten Sie die Parameter so anpassen, dass die Größe des Aufmerksamkeitskopfs den Anforderungen entspricht. Weitere Informationen finden Sie auch unter [Installation und Funktionen](https://github.com/HazyResearch/flash-attention#installation-and-features) im *FlashAttention GitHubRepository*.
Nehmen wir z. B. an, Sie konfigurieren ein Transformator-Modell mit `hidden_width=864` und `num_heads=48`. Die Kopfgröße von FlashAttention wird berechnet als`attention_head_size = hidden_width / num_heads = 864 / 48 = 18`. Um das zu aktivieren FlashAttention, müssen Sie den `num_heads` Parameter so einstellen `54``attention_head_size = hidden_width / num_heads = 864 / 54 = 16`, dass das ein Vielfaches von 8 ist.