Leitfaden zum verteilten GPU-Training SDK (v1)

  • Artikel

GILT FÜR:Python SDK azureml v1

Erfahren Sie mehr über die Verwendung von verteiltem GPU-Trainingscode in Azure Machine Learning (ML). Dieser Artikel vermittelt kein Basiswissen über verteiltes Training. Er soll Sie vielmehr beim Ausführen Ihres vorhandenen verteilten Trainingscodes auf Azure Machine Learning unterstützen. Dazu dienen Tipps und Beispiele, die Sie für jedes Framework befolgen können:

  • Message Passing Interface (MPI)
    • Horovod
    • DeepSpeed
    • Umgebungsvariablen aus Open MPI
  • PyTorch
    • Initialisierung von Prozessgruppen
    • Startoptionen
    • DistributedDataParallel (Start pro Prozess)
    • Verwendung von torch.distributed.launch (Start pro Knoten)
    • PyTorch Lightning
    • Hugging Face Transformers
  • TensorFlow
    • Umgebungsvariablen für TensorFlow (TF_CONFIG)
  • Beschleunigen des GPU-Trainings mit InfiniBand

Voraussetzungen

Lernen Sie diese grundlegenden Konzepte des verteilten GPU-Trainings wie Datenparallelität, verteilte Datenparallelität und Modellparallelität kennen.

Tipp

Wenn Sie nicht wissen, welche Art von Parallelität verwendet werden soll, sollten Sie in mehr als 90 % der Fälle Verteilte Datenparallelität verwenden.

MPI

Azure Machine Learning bietet einen MPI-Auftrag zum Starten einer bestimmten Anzahl von Prozessen in jedem Knoten. Sie können diesen Ansatz verwenden, um verteiltes Training entweder mit dem Pro-Prozess- oder Pro-Knoten-Startprogramm auszuführen. Dies hängt davon ab, ob process_count_per_node für das Pro-Knoten-Startprogramm auf 1 (Standard) oder für das Pro-Prozess-Startprogramm auf die Anzahl der Geräte/GPUs für das Pro-Prozess-Startprogramm festgelegt ist. Azure Machine Learning erstellt den vollständigen Befehl für den MPI-Start (mpirun) im Hintergrund. Sie können keine eigenen vollständigen Hauptknoten-Startprogramm-Befehle wie mpirun oder DeepSpeed launcher bereitstellen.

Tipp

Für das Docker-Basisimage, das von einem Azure Machine Learning-MPI-Auftrag verwendet wird, muss eine MPI-Bibliothek installiert sein. Open MPI ist in allen GPU-Basisimages für Azure Machine Learning enthalten. Wenn Sie ein benutzerdefiniertes Docker-Image verwenden, müssen Sie sicherstellen, dass das Image eine MPI-Bibliothek enthält. Open MPI wird empfohlen, aber Sie können auch eine andere MPI-Implementierung wie Intel MPI verwenden. Azure Machine Learning stellt auch kuratierte Umgebungen für beliebte Frameworks bereit.

Führen Sie die folgenden Schritte aus, um verteiltes Training mit MPI ausführen zu können:

  1. Verwenden Sie eine Azure Machine Learning-Umgebung mit dem bevorzugten Deep Learning-Framework und MPI. Azure Machine Learning stellt kuratierte Umgebungen für beliebte Frameworks bereit.
  2. Definieren Sie MpiConfiguration mit process_count_per_node und node_count. process_count_per_node sollte gleich der Anzahl von GPUs pro Knoten für den Start pro Prozess sein, oder auf 1 (Standard) für den Start pro Knoten festgelegt sein, wenn das Benutzerskript für das Starten der Prozesse pro Knoten verantwortlich ist.
  3. Übergeben Sie das MpiConfiguration-Objekt an den distributed_job_config-Parameter von ScriptRunConfig.
from azureml.core import Workspace, ScriptRunConfig, Environment, Experiment
from azureml.core.runconfig import MpiConfiguration

curated_env_name = 'AzureML-PyTorch-1.6-GPU'
pytorch_env = Environment.get(workspace=ws, name=curated_env_name)
distr_config = MpiConfiguration(process_count_per_node=4, node_count=2)

run_config = ScriptRunConfig(
  source_directory= './src',
  script='train.py',
  compute_target=compute_target,
  environment=pytorch_env,
  distributed_job_config=distr_config,
)

# submit the run configuration to start the job
run = Experiment(ws, "experiment_name").submit(run_config)

Horovod

Verwenden Sie die MPI-Auftragskonfiguration, wenn Sie Horovod für verteiltes Training mit dem Deep Learning-Framework verwenden.

Stellen Sie sicher, dass Ihr Code den folgenden Tipps entspricht:

  • Der Trainingscode wird ordnungsgemäß mit Horovod instrumentiert, bevor die Azure Machine Learning-Bestandteile hinzugefügt werden.
  • Ihre Azure Machine Learning-Umgebung enthält Horovod und MPI. Die kuratierten GPU-Umgebungen PyTorch und TensorFlow sind mit Horovod und seinen Abhängigkeiten vorkonfiguriert.
  • Erstellen Sie eine MpiConfiguration mit der gewünschten Verteilung.

Horovod-Beispiel

DeepSpeed

Verwenden Sie nicht das benutzerdefinierte Startprogramm von DeepSpeed, um verteiltes Training mit der DeepSpeed-Bibliothek in Azure Machine Learning auszuführen. Konfigurieren Sie stattdessen einen MPI-Auftrag, um den Trainingsauftrag mit MPI zu starten.

Stellen Sie sicher, dass Ihr Code den folgenden Tipps entspricht:

  • Ihre Azure Machine Learning-Umgebung enthält DeepSpeed und seine Abhängigkeiten, Open MPI und mpi4py.
  • Erstellen Sie eine MpiConfiguration mit der gewünschten Verteilung.

DeepSpeed-Beispiel

Umgebungsvariablen aus Open MPI

Beim Ausführen von MPI-Aufträgen mit Open MPI-Images werden die folgenden Umgebungsvariablen für jeden Prozess gestartet:

  1. OMPI_COMM_WORLD_RANK – der Rang des Prozesses
  2. OMPI_COMM_WORLD_SIZE – die Weltgröße
  3. AZ_BATCH_MASTER_NODE – primäre Adresse mit Port, MASTER_ADDR:MASTER_PORT
  4. OMPI_COMM_WORLD_LOCAL_RANK – der lokale Rang des Prozesses auf dem Knoten
  5. OMPI_COMM_WORLD_LOCAL_SIZE – Anzahl der Prozesse auf dem Knoten

Tipp

Trotz des Namens entspricht die Umgebungsvariable OMPI_COMM_WORLD_NODE_RANK nicht dem NODE_RANK. Um das Pro-Knoten-Startprogramm zu verwenden, legen Sie process_count_per_node=1 fest, und verwenden Sie OMPI_COMM_WORLD_RANK als NODE_RANK.

PyTorch

Azure Machine Learning unterstützt die Ausführung verteilter Aufträge mithilfe der nativen verteilten Trainingsfunktionen von PyTorch (torch.distributed).

Tipp

Für Datenparallelität ist die offizielle PyTorch-Anleitung die Verwendung von DistributedDataParallel (DDP) über DataParallel für verteiltes Training sowohl mit einem einzelnen als auch mehreren Knoten. PyTorch empfiehlt auch die Verwendung von DistributedDataParallel über das Multiprozessorpaket. Azure Machine Learning-Dokumentation und -Beispiele konzentrieren sich daher auf das DistributedDataParallel-Training.

Initialisierung von Prozessgruppen

Eine Gruppe von Prozessen, die sich gegenseitig kennen und über ein Back-End miteinander kommunizieren können, bilden das Rückgrat eines verteilten Trainings. Für PyTorch wird die Prozessgruppe erstellt, indem torch.distributed.init_process_group in allen verteilten Prozessen aufgerufen wird, um zusammen eine Prozessgruppe zu bilden.

torch.distributed.init_process_group(backend='nccl', init_method='env://', ...)

Die am häufigsten verwendeten Kommunikations-Back-Ends sind mpi, nccl und gloo. Für GPU-basiertes Training wird nccl empfohlen, um die beste Leistung zu erzielen, und sollte nach Möglichkeit verwendet werden.

init_method gibt an, wie die einzelnen Prozesse sich gegenseitig entdecken und wie sie die Prozessgruppe mithilfe des Kommunikations-Back-Ends initialisieren und überprüfen. Wenn init_method nicht angegeben ist, verwendet PyTorch standardmäßig die Methode zum Initialisieren der Umgebungsvariablen (env://). init_method ist die empfohlene Initialisierungsmethode in Ihrem Trainingscode zum Ausführen verteilter PyTorch-Aufträge in Azure Machine Learning. PyTorch sucht für die Initialisierung nach den folgenden Umgebungsvariablen:

  • MASTER_ADDR: IP-Adresse des Computers, auf dem der Prozess mit dem Rang 0 gehostet wird.
  • MASTER_PORT: Ein freier Port auf dem Computer, auf dem der Prozess mit dem Rang 0 gehostet wird.
  • WORLD_SIZE: Gesamtzahl von Prozessen. Dieser Wert sollte der Gesamtzahl von Geräten (GPU) entsprechen, die für das verteilte Training verwendet werden.
  • RANK: Der (globale) Rang des aktuellen Prozesses. Die möglichen Werte sind 0 bis „WORLD_SIZE - 1“.

Weitere Informationen zur Initialisierung von Prozessgruppen finden Sie in der PyTorch-Dokumentation.

Darüber hinaus benötigen viele Anwendungen auch die folgenden Umgebungsvariablen:

  • LOCAL_RANK: Der lokale (relative) Rang des Prozesses auf dem Knoten. Die möglichen Werte sind 0 bis „Anzahl von Prozessen auf dem Knoten - 1“. Diese Informationen sind nützlich, da viele Vorgänge wie die Datenvorbereitung nur einmal pro Knoten ausgeführt werden sollten – und in der Regel auf local_rank = 0.
  • NODE_RANK: Der Rang des Knotens in Bezug auf das Training mit mehreren Knoten. Die möglichen Werte sind 0 bis „Gesamtknotenzahl - 1“.

PyTorch-Startoptionen

Der PyTorch-Auftrag in Azure Machine Learning unterstützt zwei Arten von Optionen zum Starten verteilter Trainings:

  • Pro-Prozess-Startprogramm: Das System startet alle verteilten Prozesse für Sie mit allen relevanten Informationen (z. B. Umgebungsvariablen), um die Prozessgruppe einzurichten.
  • Pro-Knoten-Startprogramm: Sie stellen das Starthilfsprogramm für Azure Machine Learning zur Verfügung, das auf jedem Knoten ausgeführt wird. Das Starthilfsprogramm startet die jeweiligen Prozesse auf einem bestimmten Knoten. Innerhalb jedes Knotens werden RANK und LOCAL_RANK lokal vom Startprogramm eingerichtet. Sowohl das Hilfsprogramm torch.distributed.launch als auch PyTorch Lightning gehört zu dieser Kategorie.

Es gibt keine grundlegenden Unterschiede zwischen diesen Startoptionen. Die Wahl hängt größtenteils von Ihren Vorlieben oder den Konventionen der Frameworks/Bibliotheken ab, die basierend auf Vanilla PyTorch erstellt wurden (z. B. Lightning oder Hugging Face).

In den folgenden Abschnitten wird ausführlicher erläutert, wie Sie PyTorch-Aufträge in Azure Machine Learning für die einzelnen Startoptionen konfigurieren.

DistributedDataParallel (Start pro Prozess)

Sie müssen kein Starthilfsprogramm wie torch.distributed.launch verwenden. So führen Sie einen verteilten PyTorch-Auftrag aus:

  1. Geben Sie das Trainingsskript und die Argumente an.
  2. Erstellen Sie eine PyTorchConfiguration, und geben Sie den Wert für process_count und node_count an. process_count steht für die Gesamtzahl von Prozessen, die Sie für Ihren Auftrag ausführen möchten. process_count sollte in der Regel gleich # GPUs per node x # nodes sein. Wenn process_count nicht angegeben ist, startet Azure Machine Learning standardmäßig einen Prozess pro Knoten.

Azure Machine Learning legt die Umgebungsvariablen MASTER_ADDR, MASTER_PORT, WORLD_SIZE und NODE_RANK auf jedem Knoten sowie die Umgebungsvariablen RANK und LOCAL_RANK auf Prozessebene fest.

Verwenden Sie das Azure Machine Learning Python SDK >= 1.22.0, um diese Option für das Training mit mehreren Prozessen pro Knoten zu verwenden. Process_count wurde in 1.22.0 eingeführt.

from azureml.core import ScriptRunConfig, Environment, Experiment
from azureml.core.runconfig import PyTorchConfiguration

curated_env_name = 'AzureML-PyTorch-1.6-GPU'
pytorch_env = Environment.get(workspace=ws, name=curated_env_name)
distr_config = PyTorchConfiguration(process_count=8, node_count=2)

run_config = ScriptRunConfig(
  source_directory='./src',
  script='train.py',
  arguments=['--epochs', 50],
  compute_target=compute_target,
  environment=pytorch_env,
  distributed_job_config=distr_config,
)

run = Experiment(ws, 'experiment_name').submit(run_config)

Tipp

Wenn mit Ihrem Trainingsskript Informationen wie lokaler Rang oder Rang als Skriptargumente übergeben werden, können Sie in den Argumenten auf die Umgebungsvariable(n) verweisen:

arguments=['--epochs', 50, '--local_rank', $LOCAL_RANK]

Pytorch-Beispiel für Start pro Prozess

Verwenden von torch.distributed.launch (Start pro Knoten)

Für PyTorch wird unter torch.distributed.launch ein Hilfsprogramm für das Starten bereitgestellt, mit dem Sie mehrere Prozesse pro Knoten starten können. Mit dem Modul torch.distributed.launch werden auf den einzelnen Knoten jeweils mehrere Trainingsprozesse erzeugt.

Die folgenden Schritte zeigen, wie ein PyTorch-Auftrag mit einem Pro-Knoten-Startprogramm in Azure Machine Learning konfiguriert wird. Der Auftrag entspricht dem Ausführen des folgenden Befehls:

python -m torch.distributed.launch --nproc_per_node <num processes per node> \
  --nnodes <num nodes> --node_rank $NODE_RANK --master_addr $MASTER_ADDR \
  --master_port $MASTER_PORT --use_env \
  <your training script> <your script arguments>
  1. Geben Sie den Befehl torch.distributed.launch für den Parameter command des Konstruktors ScriptRunConfig an. Azure Machine Learning führt diesen Befehl auf jedem Knoten Ihres Trainingsclusters aus. Der Wert --nproc_per_node sollte kleiner oder gleich der Anzahl von GPUs sein, die auf einem Knoten verfügbar sind. Da MASTER_ADDR, MASTER_PORT und NODE_RANK von Azure Machine Learning festgelegt werden, können Sie im Befehl einfach auf die Umgebungsvariablen verweisen. Azure Machine Learning legt MASTER_PORT auf 6105 fest, aber wenn Sie möchten, können Sie auch einen anderen Wert an das --master_port-Argument des torch.distributed.launch-Befehls übergeben. (Mit dem Hilfsprogramm für das Starten werden die Umgebungsvariablen zurückgesetzt.)
  2. Erstellen Sie ein PyTorchConfiguration-Element, und geben Sie den Wert für node_count an.
from azureml.core import ScriptRunConfig, Environment, Experiment
from azureml.core.runconfig import PyTorchConfiguration

curated_env_name = 'AzureML-PyTorch-1.6-GPU'
pytorch_env = Environment.get(workspace=ws, name=curated_env_name)
distr_config = PyTorchConfiguration(node_count=2)
launch_cmd = "python -m torch.distributed.launch --nproc_per_node 4 --nnodes 2 --node_rank $NODE_RANK --master_addr $MASTER_ADDR --master_port $MASTER_PORT --use_env train.py --epochs 50".split()

run_config = ScriptRunConfig(
  source_directory='./src',
  command=launch_cmd,
  compute_target=compute_target,
  environment=pytorch_env,
  distributed_job_config=distr_config,
)

run = Experiment(ws, 'experiment_name').submit(run_config)

Tipp

Training mit mehreren GPUs mit einem Knoten: Wenn Sie das Starthilfsprogramm zum Ausführen des PyTorch-Trainings mit mehreren GPUs mit einem Knoten verwenden, müssen Sie den distributed_job_config-Parameter von ScriptRunConfig nicht angeben.

launch_cmd = "python -m torch.distributed.launch --nproc_per_node 4 --use_env train.py --epochs 50".split()

run_config = ScriptRunConfig(
 source_directory='./src',
 command=launch_cmd,
 compute_target=compute_target,
 environment=pytorch_env,
)

PyTorch-Beispiel für Start pro Knoten

PyTorch Lightning

PyTorch Lightning ist eine einfache Open-Source-Bibliothek, die eine allgemeine Schnittstelle für PyTorch bereitstellt. Lightning abstrahiert viele der detaillierteren Konfigurationen für verteiltes Training, die für Vanilla PyTorch erforderlich sind. Mit Lightning können Sie Ihre Trainingsskripts in Einstellungen mit einer einzelnen GPU, mehreren GPUs mit einem einzelnen Knoten und mehreren GPUs mit mehreren Knoten ausführen. Im Hintergrund werden mehrere Prozesse ähnlich wie torch.distributed.launch für Sie gestartet.

Für das Training mit einem einzelnen Knoten (einschließlich mehrerer GPUs auf einem einzelnen Knoten) können Sie Ihren Code in Azure Machine Learning ausführen, ohne eine distributed_job_config angeben zu müssen. Es gibt zwei Optionen zum Ausführen eines Experiments mit mehreren Knoten mit mehreren GPUs:

  • Verwenden der PyTorch-Konfiguration (empfohlen): Definieren SiePyTorchConfiguration, und geben Sie communication_backend="Nccl"node_count sowie process_count an (beachten Sie, dass dies die Gesamtzahl der Prozesse ist, also z. B. num_nodes * process_count_per_node). Geben Sie im Lightning Trainer-Modul an, dass sowohl num_nodes als auch gpus mit PyTorchConfiguration konsistent sein müssen. Beispiel: num_nodes = node_count und gpus = process_count_per_node.

  • Verwenden der MPI-Konfiguration:

    • Definieren Sie MpiConfiguration, und geben Sie node_count und process_count_per_node an. Geben Sie in Lightning Trainer sowohl num_nodes und gpus an, die mit node_count und process_count_per_node von MpiConfiguration übereinstimmen müssen.

    • Für das Training mit MPI mit mehreren Knoten erfordert Lightning, dass die folgenden Umgebungsvariablen auf jedem Knoten Ihres Trainingsclusters festgelegt werden:

      • MASTER_ADDR
      • MASTER_PORT
      • NODE_RANK
      • LOCAL_RANK

      Legen Sie diese Umgebungsvariablen, die Lightning in den Hauptschulungsskripts benötigt, manuell fest:

    import os
from argparse import ArgumentParser

def set_environment_variables_for_mpi(num_nodes, gpus_per_node, master_port=54965):
     if num_nodes > 1:
         os.environ["MASTER_ADDR"], os.environ["MASTER_PORT"] = os.environ["AZ_BATCH_MASTER_NODE"].split(":")
     else:
         os.environ["MASTER_ADDR"] = os.environ["AZ_BATCHAI_MPI_MASTER_NODE"]
         os.environ["MASTER_PORT"] = str(master_port)

     try:
         os.environ["NODE_RANK"] = str(int(os.environ.get("OMPI_COMM_WORLD_RANK")) // gpus_per_node)
         # additional variables
         os.environ["MASTER_ADDRESS"] = os.environ["MASTER_ADDR"]
         os.environ["LOCAL_RANK"] = os.environ["OMPI_COMM_WORLD_LOCAL_RANK"]
         os.environ["WORLD_SIZE"] = os.environ["OMPI_COMM_WORLD_SIZE"]
     except:
         # fails when used with pytorch configuration instead of mpi
         pass

if __name__ == "__main__":
     parser = ArgumentParser()
     parser.add_argument("--num_nodes", type=int, required=True)
     parser.add_argument("--gpus_per_node", type=int, required=True)
     args = parser.parse_args()
     set_environment_variables_for_mpi(args.num_nodes, args.gpus_per_node)

     trainer = Trainer(
      num_nodes=args.num_nodes,
      gpus=args.gpus_per_node
  )

    Lightning verarbeitet die Berechnung der Weltgröße aus den Trainer-Flags --gpus und --num_nodes.

    from azureml.core import ScriptRunConfig, Experiment
from azureml.core.runconfig import MpiConfiguration

nnodes = 2
gpus_per_node = 4
args = ['--max_epochs', 50, '--gpus_per_node', gpus_per_node, '--accelerator', 'ddp', '--num_nodes', nnodes]
distr_config = MpiConfiguration(node_count=nnodes, process_count_per_node=gpus_per_node)

run_config = ScriptRunConfig(
   source_directory='./src',
   script='train.py',
   arguments=args,
   compute_target=compute_target,
   environment=pytorch_env,
   distributed_job_config=distr_config,
)

run = Experiment(ws, 'experiment_name').submit(run_config)

Hugging Face Transformers

Hugging Face enthält viele Beispiele für die Verwendung der Transformers-Bibliothek mit torch.distributed.launch, um verteiltes Training auszuführen. Um diese Beispiele und Ihre eigenen benutzerdefinierten Trainingsskripts mithilfe der Transformers-Trainer-API auszuführen, folgen Sie dem Abschnitt Verwenden von torch.distributed.launch (Start pro Knoten).

Beispielcode für die Auftragskonfiguration zum Optimieren des umfangreichen BERT-Modells für die MNLI-Aufgabe zur Textklassifizierung mithilfe des run_glue.py-Skripts auf einem Knoten mit 8 GPUs:

from azureml.core import ScriptRunConfig
from azureml.core.runconfig import PyTorchConfiguration

distr_config = PyTorchConfiguration() # node_count defaults to 1
launch_cmd = "python -m torch.distributed.launch --nproc_per_node 8 text-classification/run_glue.py --model_name_or_path bert-large-uncased-whole-word-masking --task_name mnli --do_train --do_eval --max_seq_length 128 --per_device_train_batch_size 8 --learning_rate 2e-5 --num_train_epochs 3.0 --output_dir /tmp/mnli_output".split()

run_config = ScriptRunConfig(
  source_directory='./src',
  command=launch_cmd,
  compute_target=compute_target,
  environment=pytorch_env,
  distributed_job_config=distr_config,
)

Sie können auch die Option Start pro Prozess verwenden, um verteiltes Training ohne Verwendung von torch.distributed.launch auszuführen. Beachten Sie bei Verwendung dieser Methode, dass die Transformers-TrainingArguments erwarten, dass der lokale Rang als Argument (--local_rank) übergeben wird. torch.distributed.launch übernimmt dies im Fall von --use_env=False, aber wenn Sie die Option „Start pro Prozess“ verwenden, müssen Sie den lokalen Rang explizit als Argument an das Trainingsskript --local_rank=$LOCAL_RANK übergeben, da Azure Machine Learning nur die LOCAL_RANK-Umgebungsvariable festlegt.

TensorFlow

Wenn Sie natives verteiltes TensorFlow in Ihrem Trainingscode verwenden, z. B. die tf.distribute.Strategy-API von TensorFlow 2.x, können Sie den verteilten Auftrag über Azure Machine Learning mit der TensorflowConfiguration starten.

Geben Sie dazu ein TensorflowConfiguration-Objekt für den distributed_job_config-Parameter des ScriptRunConfig-Konstruktors an. Wenn Sie tf.distribute.experimental.MultiWorkerMirroredStrategy verwenden, geben Sie den worker_count-Wert in der TensorflowConfiguration an, der der Anzahl der Knoten für den Trainingsauftrag entspricht.

from azureml.core import ScriptRunConfig, Environment, Experiment
from azureml.core.runconfig import TensorflowConfiguration

curated_env_name = 'AzureML-TensorFlow-2.3-GPU'
tf_env = Environment.get(workspace=ws, name=curated_env_name)
distr_config = TensorflowConfiguration(worker_count=2, parameter_server_count=0)

run_config = ScriptRunConfig(
  source_directory='./src',
  script='train.py',
  compute_target=compute_target,
  environment=tf_env,
  distributed_job_config=distr_config,
)

# submit the run configuration to start the job
run = Experiment(ws, "experiment_name").submit(run_config)

Wenn Ihr Trainingsskript die Parameterserverstrategie für verteiltes Training wie für Legacy-TensorFlow 1.x verwendet, müssen Sie auch die Anzahl der Parameterserver angeben, die im Auftrag verwendet werden sollen, z. B. tf_config = TensorflowConfiguration(worker_count=2, parameter_server_count=1).

TF_CONFIG

In TensorFlow ist die TF_CONFIG-Umgebungsvariable für das Training auf mehreren Computern erforderlich. Für TensorFlow-Aufträge konfiguriert und bestimmt Azure Machine Learning die TF_CONFIG-Variable individuell für jeden Worker, bevor das Trainingsskript ausgeführt wird.

Sie können aus Ihrem Trainingsskript auf TF_CONFIG zugreifen, falls dies erforderlich ist: os.environ['TF_CONFIG'].

Beispiel für das Festlegen von TF_CONFIG auf einem Chief-Workerknoten:

TF_CONFIG='{
    "cluster": {
        "worker": ["host0:2222", "host1:2222"]
    },
    "task": {"type": "worker", "index": 0},
    "environment": "cloud"
}'

TensorFlow-Beispiel

Beschleunigen des verteilten GPU-Trainings mit InfiniBand

Je mehr VMs ein Modell trainieren, desto weniger Zeit sollte zum Trainieren dieses Modells benötigt werden. Die Zeit sollte im Idealfall linear und proportional zur Anzahl der Trainings-VMs abnehmen. Wenn das Trainieren eines Modells auf einer VM beispielsweise 100 Sekunden dauert, sollte das Training desselben Modells auf zwei VMs idealerweise 50 Sekunden dauern. Das Trainieren des Modells auf vier VMs sollte 25 Sekunden dauern usw.

InfiniBand kann ein wichtiger Faktor zur Erreichung dieser linearen Skalierung sein. InfiniBand ermöglicht eine latenzarme GPU-zu-GPU-Kommunikation über mehrere Knoten in einem Cluster hinweg. Für den Betrieb von InfiniBand ist spezielle Hardware erforderlich. Bestimmte Azure-VM-Serien, insbesondere die NC-, ND- und H-Serie, verfügen jetzt über VMs mit RDMA-Unterstützung mit SR-IOV- und InfiniBand-Unterstützung. Diese VMs kommunizieren über das InfiniBand-Netzwerk mit geringer Latenz und hoher Bandbreite, was deutlich leistungsfähiger ist als ethernetbasierte Konnektivität. SR-IOV für InfiniBand ermöglicht für jede MPI-Bibliothek nahezu Bare-Metal-Leistung (MPI wird von vielen Frameworks und Tools einschließlich NCCL-Software von NVIDIA für verteiltes Training verwendet). Diese SKUs sollen die Anforderungen rechenintensiver, GPU-gestützter Machine Learning-Workloads erfüllen. Weitere Informationen finden Sie unter Beschleunigen des verteilten Trainings in Azure Machine Learning mit SR-IOV.

In der Regel enthalten VM-SKUs mit einem „r“ im Namen die erforderliche InfiniBand-Hardware, und solche ohne „r“ in der Regel nicht. (Das „r“ ist ein Verweis auf das Akronym „RDMA“, das wiederum für „Remote Direct Memory Access“ steht.) Die VM-SKU Standard_NC24rs_v3 ist beispielsweise InfiniBand-fähig, die SKU Standard_NC24s_v3 jedoch nicht. Abgesehen von den InfiniBand-Funktionen sind die Spezifikationen zwischen diesen beiden SKUs größtenteils identisch – beide verfügen über 24 Kerne, 448 GB RAM, 4 GPUs derselben SKU usw. Erfahren Sie mehr über RDMA- und InfiniBand-fähige Computer-SKUs.

Warnung

Die Computer-SKU Standard_NC24r der älteren Generation ist RDMA-fähig, enthält jedoch keine SR-IOV-Hardware, die für InfiniBand erforderlich ist.

Wenn Sie einen AmlCompute-Cluster mit einer dieser Größen mit RDMA- und InfiniBand-Unterstützung erstellen, wird das Betriebssystemimage mit dem Mellanox OFED-Treiber bereitgestellt, der erforderlich ist, um InfiniBand vorinstalliert und vorkonfiguriert zu aktivieren.

Nächste Schritte