Partager via

Guide de formation aux GPU distribués (SDK v1)

  • Article

S’APPLIQUE À :SDK Python azureml v1

Découvrez-en plus sur l’utilisation du code d’entraînement de GPU distribué dans Azure Machine Learning (ML). Cet article ne vous apprend pas l’entraînement distribué. Il vous aide à exécuter votre code d’entraînement distribué existant sur Azure Machine Learning. Il fournit des conseils et des exemples à suivre pour chaque framework :

  • Interface de passage de messages (MPI)
    • Horovod
    • DeepSpeed
    • Variables d’environnement à partir d’Open MPI
  • PyTorch
    • Initialisation du groupe de processus
    • Options de lancement
    • DistributedDataParallel (lancement par processus)
    • Utilisation de torch.distributed.launch (lancement par nœud)
    • PyTorch Lightning
    • Hugging Face Transformers
  • TensorFlow
    • Variables d’environnement pour TensorFlow (TF_CONFIG)
  • Entraînement de GPU accéléré avec InfiniBand

Prérequis

Passez en revue les concepts de base de l’entraînement de GPU distribué, comme le parallélisme des données, le parallélisme des données distribué et le parallélisme des modèles.

Conseil

Si vous ne connaissez pas le type de parallélisme à utiliser, plus de 90 % du temps, vous devez utiliser le parallélisme des données distribué.

MPI

Azure Machine Learning fournit un travail MPI qui permet de lancer un nombre donné de processus dans chaque nœud. Vous pouvez adopter cette approche pour exécuter un entraînement distribué en utilisant un lanceur par processus ou un lanceur par nœud, selon que process_count_per_node a la valeur 1 (valeur par défaut) pour le lanceur par nœud ou est égal au nombre d’appareils/GPU pour le lanceur par processus. Azure Machine Learning construit la commande de lancement MPI complète (mpirun) en arrière-plan. Vous ne pouvez pas fournir vos propres commandes de lanceur de nœud principal complètes, telles que mpirun ou DeepSpeed launcher.

Conseil

Une bibliothèque MPI doit être installée sur l’image Docker de base utilisée par un travail MPI Azure Machine Learning. Open MPI est inclus dans toutes les images de base de GPU Azure Machine Learning. Quand vous utilisez une image Docker personnalisée, vous devez vous assurer que l’image comprend une bibliothèque MPI. Open MPI est recommandé, mais vous pouvez également utiliser une autre implémentation MPI telle qu’Intel MPI. Azure Machine Learning fournit également des environnements organisés pour les frameworks populaires.

Pour exécuter un entraînement distribué avec MPI, procédez comme suit :

  1. Utilisez un environnement Azure Machine Learning avec le framework de Deep Learning par défaut et MPI. Azure Machine Learning fournit également un environnement organisé pour les frameworks populaires.
  2. Définissez MpiConfiguration avec process_count_per_node et node_count. process_count_per_node doit être égal au nombre de GPU par nœud pour le lancement par processus, ou défini sur 1 (valeur par défaut) pour le lancement par nœud si le script utilisateur est chargé de lancer les processus par nœud.
  3. Passez l’objet MpiConfiguration au paramètre distributed_job_config de 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

Utilisez la configuration du travail MPI quand vous utilisez Horovod pour un entraînement distribué avec le framework de Deep Learning.

Assurez-vous que votre code suit ces conseils :

  • Le code d’entraînement est correctement instrumenté avec Horovod avant l’ajout des composants Machine Learning Azure
  • Votre environnement Azure Machine Learning contient Horovod et MPI. Les environnements de GPU organisés PyTorch et TensorFlow sont préconfigurés avec Horovod et ses dépendances.
  • Créez une configuration MpiConfiguration avec la distribution souhaitée.

Exemple Horovod

DeepSpeed

N’utilisez pas le lanceur personnalisé de DeepSpeed pour exécuter un entraînement distribué avec la bibliothèque DeepSpeed sur Azure Machine Learning. Au lieu de cela, configurez un travail MPI pour lancer le travail d’entraînement avec MPI.

Assurez-vous que votre code suit ces conseils :

  • Votre environnement Azure Machine Learning contient DeepSpeed et ses dépendances, Open MPI et mpi4py.
  • Créez une configuration MpiConfiguration avec votre distribution.

Exemple DeepSpeed

Variables d’environnement à partir d’Open MPI

Lors de l’exécution de travaux MPI avec des images Open MPI, les variables d’environnement suivantes sont lancées pour chaque processus :

  1. OMPI_COMM_WORLD_RANK : rang du processus
  2. OMPI_COMM_WORLD_SIZE : nombre total de processus (WORLD_SIZE)
  3. AZ_BATCH_MASTER_NODE : adresse principale avec port, MASTER_ADDR:MASTER_PORT
  4. OMPI_COMM_WORLD_LOCAL_RANK : rang local du processus sur le nœud
  5. OMPI_COMM_WORLD_LOCAL_SIZE : nombre de processus sur le nœud

Conseil

Malgré son nom, la variable d’environnement OMPI_COMM_WORLD_NODE_RANK ne correspond pas à NODE_RANK. Pour utiliser le lanceur par nœud, définissez process_count_per_node=1 et utilisez OMPI_COMM_WORLD_RANK comme NODE_RANK.

PyTorch

Azure Machine Learning prend en charge l’exécution de travaux distribués avec des fonctionnalités d’entraînement distribué natives de PyTorch (torch.distributed).

Conseil

Pour le parallélisme des données, l’aide officielle de PyTorch stipule d’utiliser DistributedDataParallel (DDP) plutôt que DataParallel pour l’entraînement distribué mononœud et multinœud. De plus, PyTorch recommande d’utiliser DistributedDataParallel plutôt que le package de multitraitement. La documentation et les exemples Azure Machine Learning se concentrent donc sur l’entraînement DistributedDataParallel.

Initialisation du groupe de processus

L’épine dorsale d’un entraînement distribué repose sur un groupe de processus qui se connaissent entre eux et peuvent communiquer entre eux avec un back-end. Pour PyTorch, le groupe de processus est créé en appelant torch.distributed.init_process_group dans tous les processus distribués pour former collectivement un groupe de processus.

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

Les back-ends de communication les plus couramment utilisés sont mpi, nccl et gloo. Pour l’entraînement basé sur le GPU, nccl est recommandé pour des performances optimales et doit être utilisé chaque fois que cela est possible.

init_method indique comment chaque processus peut découvrir les autres processus et comment ils initialisent et vérifient le groupe de processus en utilisant le back-end de communication. Par défaut, si init_method n’est pas spécifié, PyTorch utilise la méthode d’initialisation par variable d’environnement (env://). init_method est la méthode d’initialisation recommandée à utiliser dans votre code d’entraînement pour exécuter un travail PyTorch distribué sur Azure Machine Learning. PyTorch va rechercher les variables d’environnement suivantes pour l’initialisation :

  • MASTER_ADDR – Adresse IP de la machine qui hébergera le processus avec le rang 0.
  • MASTER_PORT – Port libre sur la machine qui hébergera le processus avec le rang 0.
  • WORLD_SIZE – Nombre total de processus. Doit être égal au nombre total d’appareils (GPU) utilisés pour l’entraînement distribué.
  • RANK – Rang (mondial) du processus en cours. Les valeurs possibles sont comprises entre 0 et (l’échelle mondiale - 1).

Pour plus d’informations sur l’initialisation du groupe de processus, consultez la documentation PyTorch.

Au-delà de ces variables, de nombreuses applications ont également besoin des variables d’environnement suivantes :

  • LOCAL_RANK – Rang local (relatif) du processus dans le nœud. Les valeurs possibles sont comprises entre 0 et (le nombre de processus sur le nœud - 1). Ces informations sont utiles, car de nombreuses opérations, telles que la préparation des données, doivent être effectuées une fois par nœud, généralement avec local_rank = 0.
  • NODE_RANK – Rang du nœud dans l’entraînement sur plusieurs nœuds. Les valeurs possibles sont comprises entre 0 et (le nombre total de nœuds - 1).

Options de lancement de PyTorch

Le travail PyTorch Azure Machine Learning prend en charge deux types d’options pour lancer l’entraînement distribué :

  • Lanceur par processus : le système lance tous les processus distribués pour vous, avec toutes les informations pertinentes (telles que les variables d’environnement) pour configurer le groupe de processus.
  • Lanceur par nœud : vous fournissez à Azure Machine Learning le lanceur d’utilitaire qui doit s’exécuter sur chaque nœud. Le lanceur d’utilitaire gère le lancement de chacun des processus sur un nœud donné. Au sein même de chaque nœud,RANK et LOCAL_RANK sont configurés par le lanceur. L’utilitaire torch.distributed.launch et PyTorch Lightning appartiennent tous deux à cette catégorie.

Il n’existe aucune différence fondamentale entre ces options de lancement. Tout dépend plutôt de votre préférence ou des conventions des frameworks et des bibliothèques s’appuyant sur vanilla PyTorch (par exemple, Lightning ou Hugging Face).

Les sections suivantes décrivent plus en détail la configuration des travaux Azure Machine Learning PyTorch pour chacune des options de lancement.

DistributedDataParallel (lancement par processus)

Vous n’avez pas besoin de recourir à un utilitaire de lancement comme torch.distributed.launch. Pour exécuter un travail PyTorch distribué :

  1. Spécifiez le script et les arguments d’entraînement.
  2. Créez une configuration PyTorchConfiguration et spécifiez process_count et node_count. process_count correspond au nombre total de processus que vous souhaitez exécuter pour votre travail. process_count doit généralement être égal à # GPUs per node x # nodes. Si process_count n’est pas spécifié, Azure Machine Learning lance par défaut un processus par nœud.

Azure Machine Learning définit les variables d’environnement MASTER_ADDR, MASTER_PORT, WORLD_SIZE et NODE_RANK sur chaque nœud et définit les variables d’environnement RANK et LOCAL_RANK de niveau processus.

Pour utiliser cette option dans le cas d’un entraînement avec plusieurs processus par nœud, utilisez le SDK Azure Machine Learning Python >= 1.22.0. Process_count a été introduit dans la version 1.22.0.

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)

Conseil

Si votre script d’entraînement passe des informations, telles que le rang local ou le rang en tant qu’arguments de script, vous pouvez référencer la ou les variables d’environnement dans les arguments :

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

Exemple de lancement par processus Pytorch

Utilisation de torch.distributed.launch (per-node-launch)

PyTorch fournit un utilitaire de lancement dans torch.distributed.launch, dont vous pouvez vous servir pour lancer plusieurs processus par nœud. Le module torch.distributed.launch génère plusieurs processus d’entraînement sur chacun des nœuds.

Les étapes suivantes montrent comment configurer un travail PyTorch avec un lanceur par nœud sur Azure Machine Learning. Le travail revient à exécuter la commande suivante :

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. Fournissez la commande torch.distributed.launch au paramètre command du constructeur ScriptRunConfig. Azure Machine Learning exécute cette commande sur chaque nœud de votre cluster d’entraînement. --nproc_per_node doit être inférieur ou égal au nombre de GPU disponibles sur chaque nœud. MASTER_ADDR, MASTER_PORT et NODE_RANK étant tous définis par Azure Machine Learning, vous pouvez vous contenter de référencer les variables d’environnement dans la commande. Azure Machine Learning définit MASTER_PORT sur 6105, mais vous pouvez passer une valeur différente à l’argument --master_port de la commande torch.distributed.launch si vous le souhaitez. (L’utilitaire de lancement réinitialisera les variables d’environnement.)
  2. Créez une configuration PyTorchConfiguration et spécifiez node_count.
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)

Conseil

Entraînement multi-GPU mononœud : si vous recourez à l’utilitaire de lancement pour exécuter un entraînement PyTorch multi-GPU mononœud, vous n’avez pas besoin de spécifier le paramètre distributed_job_config de ScriptRunConfig.

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,
)

Exemple PyTorch de lancement par nœud

PyTorch Lightning

PyTorch Lightning est une bibliothèque open source légère qui fournit une interface de haut niveau pour PyTorch. Lightning fait abstraction de nombreuses configurations d’entraînement distribué de niveau inférieur nécessaires pour vanilla PyTorch. Lightning vous permet d’exécuter vos scripts d’entraînement dans des configurations mono-GPU, multi-GPU mononœud et multi-GPU multinœuds. En arrière-plan, il lance plusieurs processus pour vous similaires à torch.distributed.launch.

Dans le cas d’un entraînement mononœud (y compris multi-GPU mononœud), vous pouvez exécuter votre code sur Azure Machine Learning sans avoir à spécifier un paramètre distributed_job_config. Pour exécuter une expérience multinœud avec plusieurs GPU, il existe 2 options :

  • Utilisation de la configuration PyTorch (recommandé) : définissez PyTorchConfiguration et spécifiez communication_backend="Nccl", node_count et process_count (notez qu’il s’agit du nombre total de processus, par exemple, num_nodes * process_count_per_node). Dans le module Lightning Trainer, spécifiez les deux num_nodes et gpus pour être cohérents avec PyTorchConfiguration. Par exemple : num_nodes = node_count et gpus = process_count_per_node.

  • Utilisation de la configuration MPI :

    • Définissez MpiConfiguration et spécifiez les deux node_count et process_count_per_node. Dans Lightning Trainer, spécifiez les deux num_nodes et gpus doivent être respectivement les mêmes que node_count et process_count_per_node à partir de MpiConfiguration.

    • Dans le cas d’une formation multinœud avec MPI, Lightning nécessite que les variables d’environnement suivantes soient définies sur chaque nœud de votre cluster de formation :

      • MASTER_ADDR
      • MASTER_PORT
      • NODE_RANK
      • LOCAL_RANK

      Définissez manuellement ces variables d’environnement requises par Lightning dans les principaux scripts de formation :

    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 gère le calcul du nombre total de processus à partir des indicateurs Trainer --gpus et --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 fournit de nombreux exemples d’utilisation de sa bibliothèque Transformers avec torch.distributed.launch pour exécuter un entraînement distribué. Pour exécuter ces exemples et vos propres scripts d’entraînement personnalisés avec l’API du module d’entraînement de Transformers, suivez la section Utilisation de torch.distributed.launch.

Exemple de code de configuration de travail pour affiner le grand modèle BERT sur la tâche MNLI de classification de texte avec le script run_glue.py sur un nœud doté de 8 GPU :

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,
)

Vous pouvez également utiliser l’option de lancement par processus pour exécuter un entraînement distribué sans utiliser torch.distributed.launch. Gardez à l’esprit que si vous utilisez cette méthode, les transformateurs TrainingArguments s’attendent à ce que le rang local soit passé comme argument (--local_rank). torch.distributed.launch s’occupe de cela quand --use_env=False, mais si vous utilisez le lancement par processus, vous devez passer explicitement le rang local comme argument au script d’entraînement --local_rank=$LOCAL_RANK, car Azure Machine Learning définit uniquement la variable d’environnement LOCAL_RANK.

TensorFlow

Si vous utilisez l’entraînement TensorFlow distribué natif dans votre code d’entraînement, par exemple l’API tf.distribute.Strategy TensorFlow 2.x, vous pouvez lancer le travail distribué par le biais d’Azure Machine Learning en utilisant le TensorflowConfiguration.

Pour ce faire, spécifiez un objet TensorflowConfiguration comme paramètre distributed_job_config du constructeur ScriptRunConfig. Si vous utilisez tf.distribute.experimental.MultiWorkerMirroredStrategy, spécifiez le worker_count dans le TensorflowConfiguration correspondant au nombre de nœuds de votre travail d’entraînement.

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)

Si votre script d’entraînement utilise la stratégie de serveur de paramètres pour l’entraînement distribué, par exemple, pour la version de TensorFlow 1.x héritée, vous devez également spécifier le nombre de serveurs de paramètres à utiliser dans le travail, par exemple tf_config = TensorflowConfiguration(worker_count=2, parameter_server_count=1).

TF_CONFIG

Dans TensorFlow, la variable d’environnement TF_CONFIG est requise pour l’entraînement sur plusieurs machines. Pour les travaux TensorFlow, Azure Machine Learning configure et définit la variable TF_CONFIG de manière appropriée pour chaque Worker avant d’exécuter votre script d’entraînement.

Si nécessaire, vous pouvez accéder à TF_CONFIG à partir de votre script d’entraînement : os.environ['TF_CONFIG'].

Exemple TF_CONFIG défini sur un nœud Worker principal :

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

Exemple TensorFlow

Accélération de l’entraînement de GPU distribué avec InfiniBand

Le temps nécessaire à l’entraînement d’un modèle doit diminuer à mesure que le nombre de machines virtuelles utilisées à cet effet augmente. Idéalement, cette durée doit diminuer de façon linéaire proportionnellement au nombre de machines virtuelles participant à l’entraînement. Par exemple, si l’entraînement d’un modèle sur une machine virtuelle prend 100 secondes, l’entraînement du même modèle sur deux machines virtuelles doit dans l’idéal prendre 50 secondes. L’entraînement du modèle sur quatre machines virtuelles doit prendre 25 secondes, et ainsi de suite.

InfiniBand peut être un facteur important pour parvenir à cette mise à l’échelle linéaire. InfiniBand autorise une communication à faible latence, de GPU à GPU, entre les nœuds d’un cluster. InfiniBand nécessite un matériel spécialisé pour fonctionner. Certaines séries de machines virtuelles Azure, en particulier les séries NC, ND et H, offrent désormais des machines virtuelles compatibles RDMA avec prise en charge de SR-IOV et d’InfiniBand. Ces machines virtuelles communiquent via le réseau InfiniBand à faible latence et à large bande passante, qui est beaucoup plus performant que la connectivité Ethernet. SR-IOV pour InfiniBand offre des performances quasi-complètes pour toute bibliothèque MPI (MPI est utilisé par de nombreux frameworks et outils d’entraînement distribué, y compris le logiciel NCCL de NVIDIA). Ces références SKU sont destinées à répondre aux besoins des charges de travail de Machine Learning gourmandes en ressources et avec accélération GPU. Pour plus d’informations, consultez Accélération de l’entraînement distribué dans Azure Machine Learning avec SR-IOV.

En règle générale, les références SKU de machines virtuelles dont le nom contient « r » intègrent le matériel InfiniBand nécessaire, ce qui n’est généralement pas le cas de celles qui ne contiennent pas « r ». (« r » fait référence à RDMA, ce qui signifie « accès direct à la mémoire à distance ».) Par exemple, la référence SKU de machine virtuelle Standard_NC24rs_v3 est compatible InfiniBand, mais la référence Standard_NC24s_v3 ne l’est pas. En dehors des capacités d’InfiniBand, les spécifications entre ces deux références SKU sont en grande partie les mêmes : elles disposent toutes deux de 24 cœurs, de 448 Go de RAM, de 4 GPU de la même référence SKU, etc. Découvrez plus en détail les références SKU de machines compatibles RDMA et InfiniBand.

Avertissement

La référence SKU de machine d’ancienne génération Standard_NC24r est compatible RDMA, mais elle n’intègre pas le matériel SR-IOV nécessaire à InfiniBand.

Si vous créez un cluster AmlCompute avec l’une de ces tailles compatibles InfiniBand et prenant en charge RDMA, l’image du système d’exploitation est fournie avec le pilote Mellanox OFED nécessaire pour activer InfiniBand préinstallé et préconfiguré.

Étapes suivantes