Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà. # Esecuzione di contenitori Docker su un nodo di calcolo Slurm su HyperPod [https://github.com/NVIDIA/enroot](https://github.com/NVIDIA/enroot) Il pacchetto Enroot aiuta a convertire le immagini Docker in un runtime comprensibile da Slurm, mentre Pyxis consente di pianificare il runtime come processo Slurm tramite un comando `srun`, `srun --container-image={{docker/image:tag}}`. **Suggerimento** I pacchetti Docker, Enroot e Pyxis devono essere installati durante la creazione del cluster come parte dell’esecuzione degli script del ciclo di vita come indicato in [Script del ciclo di vita di base forniti da HyperPod](sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-base-config.md). Utilizza gli [script del ciclo di vita di base](https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config) forniti dal team di assistenza durante la creazione di un cluster. HyperPod HyperPod Questi script di base sono configurati per installare i pacchetti per impostazione predefinita. Nello script [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/config.py](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/config.py) è presente la classe `Config` con il parametro di tipo booleano per l’installazione dei pacchetti impostato su `True` (`enable_docker_enroot_pyxis=True`). Questo viene richiamato e analizzato nello script [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/lifecycle_script.py](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/lifecycle_script.py), che chiama gli script `install_docker.sh` e `install_enroot_pyxis.sh` dalla cartella [https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/utils](https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/utils). Le installazioni effettive dei pacchetti avvengono negli script di installazione. Inoltre, gli script di installazione determinano se sono in grado di rilevare i percorsi di archiviazione NVMe dalle istanze su cui vengono eseguiti e configurano i percorsi root per Docker ed Enroot in `/opt/dlami/nvme`. Il volume root predefinito di ogni nuova istanza viene montato in `/tmp` solo con un volume EBS da 100 GB, che si esaurisce se il carico di lavoro che intendi eseguire prevede l’addestramento di LLM e, di conseguenza, di container Docker di grandi dimensioni. Se lavori con famiglie di istanze come P e G con archiviazione NVMe locale, devi assicurarti che venga utilizzata l’archiviazione NVMe collegata a `/opt/dlami/nvme` e che gli script di installazione si occupino dei processi di configurazione. **Per verificare se i percorsi root sono configurati correttamente** Su un nodo di calcolo del tuo cluster Slurm SageMaker HyperPod, esegui i seguenti comandi per assicurarti che lo script del ciclo di vita funzioni correttamente e che il volume principale di ogni nodo sia impostato su. `/opt/dlami/nvme/*` I comandi seguenti mostrano esempi di come controllare il percorso di runtime di Enroot e del percorso root dei dati per 8 nodi di calcolo di un cluster Slurm. ``` $ srun -N {{8}} cat /etc/enroot/enroot.conf | grep "ENROOT_RUNTIME_PATH" ENROOT_RUNTIME_PATH /opt/dlami/nvme/tmp/enroot/user-$(id -u) ... // The same or similar lines repeat 7 times ``` ``` $ srun -N {{8}} cat /etc/docker/daemon.json { "data-root": "/opt/dlami/nvme/docker/data-root" } ... // The same or similar lines repeat 7 times ``` Dopo aver verificato che i percorsi di runtime sono impostati correttamente su `/opt/dlami/nvme/*`, puoi iniziare a creare ed eseguire i container Docker con Enroot e Pyxis. **Per testare Docker con Slurm** 1. Sul tuo nodo di calcolo, prova i comandi seguenti per verificare se Docker ed Enroot sono installati correttamente. ``` $ docker --help $ enroot --help ``` 1. Verifica se Pyxis ed Enroot sono installati correttamente eseguendo una delle immagini [NVIDIA CUDA Ubuntu](https://catalog.ngc.nvidia.com/orgs/nvidia/containers/cuda). ``` $ srun --container-image=nvidia/cuda:{{XX.Y.Z}}-base-ubuntu{{XX.YY}} nvidia-smi pyxis: importing docker image: nvidia/cuda:XX.Y.Z-base-ubuntuXX.YY pyxis: imported docker image: nvidia/cuda:XX.Y.Z-base-ubuntuXX.YY DAY MMM DD HH:MM:SS YYYY +-----------------------------------------------------------------------------+ | NVIDIA-SMI 470.141.03 Driver Version: 470.141.03 CUDA Version: XX.YY | |-------------------------------+----------------------+----------------------+ | GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC | | Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. | | | | MIG M. | |===============================+======================+======================| | 0 Tesla T4 Off | 00000000:00:1E.0 Off | 0 | | N/A 40C P0 27W / 70W | 0MiB / 15109MiB | 0% Default | | | | N/A | +-------------------------------+----------------------+----------------------+ +-----------------------------------------------------------------------------+ | Processes: | | GPU GI CI PID Type Process name GPU Memory | | ID ID Usage | |=============================================================================| | No running processes found | +-----------------------------------------------------------------------------+ ``` Puoi verificarlo anche creando uno script ed eseguendo un comando `sbatch`, come descritto di seguito. ``` $ cat <> container-test.sh #!/bin/bash #SBATCH --container-image=nvidia/cuda:{{XX.Y.Z}}-base-ubuntu{{XX.YY}} nvidia-smi EOF $ sbatch container-test.sh pyxis: importing docker image: nvidia/cuda:XX.Y.Z-base-ubuntuXX.YY pyxis: imported docker image: nvidia/cuda:XX.Y.Z-base-ubuntuXX.YY DAY MMM DD HH:MM:SS YYYY +-----------------------------------------------------------------------------+ | NVIDIA-SMI 470.141.03 Driver Version: 470.141.03 CUDA Version: XX.YY | |-------------------------------+----------------------+----------------------+ | GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC | | Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. | | | | MIG M. | |===============================+======================+======================| | 0 Tesla T4 Off | 00000000:00:1E.0 Off | 0 | | N/A 40C P0 27W / 70W | 0MiB / 15109MiB | 0% Default | | | | N/A | +-------------------------------+----------------------+----------------------+ +-----------------------------------------------------------------------------+ | Processes: | | GPU GI CI PID Type Process name GPU Memory | | ID ID Usage | |=============================================================================| | No running processes found | +-----------------------------------------------------------------------------+ ``` **Per eseguire un processo Slurm di prova con Docker** Dopo aver completato la configurazione di Slurm con Docker, puoi portare qualsiasi immagine Docker preconfigurata ed eseguirla utilizzando Slurm on. SageMaker HyperPod Di seguito è riportato un esempio di caso d'uso che illustra come eseguire un processo di formazione utilizzando Docker e Slurm on. SageMaker HyperPod Mostra un esempio di lavoro di addestramento parallelo al modello Llama 2 con la libreria SageMaker AI model parallelism (SMP). 1. Se desideri utilizzare una delle immagini ECR predefinite distribuite da SageMaker AI o DLC, assicurati di concedere al HyperPod cluster le autorizzazioni per estrarre le immagini ECR da. [Ruolo IAM per SageMaker HyperPod](sagemaker-hyperpod-prerequisites-iam.md#sagemaker-hyperpod-prerequisites-iam-role-for-hyperpod) Se utilizzi un’immagine Docker personalizzata o open source, puoi saltare questa fase. Aggiungi le autorizzazioni seguenti al [Ruolo IAM per SageMaker HyperPod](sagemaker-hyperpod-prerequisites-iam.md#sagemaker-hyperpod-prerequisites-iam-role-for-hyperpod). In questo tutorial, utilizziamo l’[immagine Docker SMP](distributed-model-parallel-support-v2.md#distributed-model-parallel-supported-frameworks-v2) preconfezionata con la libreria SMP. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ecr:BatchCheckLayerAvailability", "ecr:BatchGetImage", "ecr-public:*", "ecr:GetDownloadUrlForLayer", "ecr:GetAuthorizationToken", "sts:*" ], "Resource": "*" } ] } ``` ------ 1. Sul nodo di calcolo, clona il repository e vai alla cartella che fornisce gli script di esempio per l’addestramento con SMP. ``` $ git clone https://github.com/aws-samples/awsome-distributed-training/ $ cd awsome-distributed-training/3.test_cases/17.SM-modelparallelv2 ``` 1. In questo tutorial, esegui lo script di esempio [https://github.com/aws-samples/awsome-distributed-training/blob/main/3.test_cases/17.SM-modelparallelv2/docker_build.sh](https://github.com/aws-samples/awsome-distributed-training/blob/main/3.test_cases/17.SM-modelparallelv2/docker_build.sh) che estrae l’immagine Docker SMP, crea il container Docker e lo esegue come runtime Enroot. Puoi modificare lo script in base alle tue esigenze. ``` $ cat docker_build.sh #!/usr/bin/env bash region={{us-west-2}} dlc_account_id={{658645717510}} aws ecr get-login-password --region $region | docker login --username AWS --password-stdin $dlc_account_id.dkr.ecr.$region.amazonaws.com docker build -t smpv2 . enroot import -o smpv2.sqsh dockerd://smpv2:latest ``` ``` $ bash docker_build.sh ``` 1. Crea uno script batch per avviare un job di addestramento utilizzando`sbatch`. In questo tutorial, lo script di esempio fornito [https://github.com/aws-samples/awsome-distributed-training/blob/main/3.test_cases/17.SM-modelparallelv2/launch_training_enroot.sh](https://github.com/aws-samples/awsome-distributed-training/blob/main/3.test_cases/17.SM-modelparallelv2/launch_training_enroot.sh) avvia un job di addestramento con parallelizzazione del modello Llama 2 da 70 miliardi di parametri con un set di dati sintetico su 8 nodi di calcolo. Un set di script di addestramento viene fornito a [https://github.com/aws-samples/awsome-distributed-training/tree/main/3.test_cases/17.SM-modelparallelv2/scripts](https://github.com/aws-samples/awsome-distributed-training/tree/main/3.test_cases/17.SM-modelparallelv2/scripts) e `launch_training_enroot.sh` utilizza `train_external.py` come script del punto di ingresso. **Importante** Per utilizzare un contenitore Docker SageMaker HyperPod, devi montare la `/var/log` directory dalla macchina host, che in questo caso è il nodo di HyperPod elaborazione, sulla directory del contenitore. `/var/log` Puoi configurarlo aggiungendo la seguente variabile per Enroot. ``` "${HYPERPOD_PATH:="{{/var/log/aws/clusters}}":"{{/var/log/aws/clusters}}"}" ``` ``` $ cat {{launch_training_enroot.sh}} #!/bin/bash # Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved. # SPDX-License-Identifier: MIT-0 #SBATCH --nodes={{8}} # number of nodes to use, 2 p4d(e) = 16 A100 GPUs #SBATCH --job-name={{smpv2_llama}} # name of your job #SBATCH --exclusive # job has exclusive use of the resource, no sharing #SBATCH --wait-all-nodes=1 set -ex; ########################### ###### User Variables ##### ########################### ######################### model_type={{llama_v2}} model_size={{70b}} # Toggle this to use synthetic data use_synthetic_data=1 # To run training on your own data set Training/Test Data path -> Change this to the tokenized dataset path in Fsx. Acceptable formats are huggingface (arrow) and Jsonlines. # Also change the use_synthetic_data to 0 export TRAINING_DIR={{/fsx/path_to_data}} export TEST_DIR={{/fsx/path_to_data}} export CHECKPOINT_DIR=$(pwd)/checkpoints # Variables for Enroot : "${IMAGE:=$(pwd){{/smpv2.sqsh}}}" : "${HYPERPOD_PATH:="{{/var/log/aws/clusters}}":"{{/var/log/aws/clusters}}"}" # This is needed for validating its hyperpod cluster : "${TRAIN_DATA_PATH:=$TRAINING_DIR:$TRAINING_DIR}" : "${TEST_DATA_PATH:=$TEST_DIR:$TEST_DIR}" : "${CHECKPOINT_PATH:=$CHECKPOINT_DIR:$CHECKPOINT_DIR}" ########################### ## Environment Variables ## ########################### #export NCCL_SOCKET_IFNAME=en export NCCL_ASYNC_ERROR_HANDLING=1 export NCCL_PROTO="simple" export NCCL_SOCKET_IFNAME="^lo,docker" export RDMAV_FORK_SAFE=1 export FI_EFA_USE_DEVICE_RDMA=1 export NCCL_DEBUG_SUBSYS=off export NCCL_DEBUG="INFO" export SM_NUM_GPUS=8 export GPU_NUM_DEVICES=8 export FI_EFA_SET_CUDA_SYNC_MEMOPS=0 # async runtime error ... export CUDA_DEVICE_MAX_CONNECTIONS=1 ######################### ## Command and Options ## ######################### if [ "$model_size" == "7b" ]; then HIDDEN_WIDTH=4096 NUM_LAYERS=32 NUM_HEADS=32 LLAMA_INTERMEDIATE_SIZE=11008 DEFAULT_SHARD_DEGREE=8 # More Llama model size options elif [ "$model_size" == "70b" ]; then HIDDEN_WIDTH=8192 NUM_LAYERS=80 NUM_HEADS=64 LLAMA_INTERMEDIATE_SIZE=28672 # Reduce for better perf on p4de DEFAULT_SHARD_DEGREE=64 fi if [ -z "$shard_degree" ]; then SHARD_DEGREE=$DEFAULT_SHARD_DEGREE else SHARD_DEGREE=$shard_degree fi if [ -z "$LLAMA_INTERMEDIATE_SIZE" ]; then LLAMA_ARGS="" else LLAMA_ARGS="--llama_intermediate_size $LLAMA_INTERMEDIATE_SIZE " fi if [ $use_synthetic_data == 1 ]; then echo "using synthetic data" declare -a ARGS=( --container-image $IMAGE --container-mounts $HYPERPOD_PATH,$CHECKPOINT_PATH ) else echo "using real data...." declare -a ARGS=( --container-image $IMAGE --container-mounts $HYPERPOD_PATH,$TRAIN_DATA_PATH,$TEST_DATA_PATH,$CHECKPOINT_PATH ) fi declare -a TORCHRUN_ARGS=( # change this to match the number of gpus per node: --nproc_per_node={{8}} \ --nnodes=$SLURM_JOB_NUM_NODES \ --rdzv_id=$SLURM_JOB_ID \ --rdzv_backend={{c10d}} \ --rdzv_endpoint=$(hostname) \ ) srun -l "${ARGS[@]}" torchrun "${TORCHRUN_ARGS[@]}" {{/path_to/train_external.py}} \ --train_batch_size {{4}} \ --max_steps {{100}} \ --hidden_width $HIDDEN_WIDTH \ --num_layers $NUM_LAYERS \ --num_heads $NUM_HEADS \ ${LLAMA_ARGS} \ --shard_degree $SHARD_DEGREE \ --model_type $model_type \ --profile_nsys {{1}} \ --use_smp_implementation {{1}} \ --max_context_width {{4096}} \ --tensor_parallel_degree {{1}} \ --use_synthetic_data $use_synthetic_data \ --training_dir $TRAINING_DIR \ --test_dir $TEST_DIR \ --dataset_type {{hf}} \ --checkpoint_dir $CHECKPOINT_DIR \ --checkpoint_freq {{100}} \ $ sbatch {{launch_training_enroot.sh}} ``` *Per trovare gli esempi di codice scaricabili, consulta [Esegui un processo di formazione parallelo ai modelli utilizzando la libreria di parallelismo dei modelli SageMaker AI, Docker ed Enroot con](https://github.com/aws-samples/awsome-distributed-training/tree/main/3.test_cases/17.SM-modelparallelv2#option-2----run-training-using-docker-and-enroot) Slurm nell'archivio Awsome Distributed Training. GitHub * Per ulteriori informazioni sulla formazione distribuita con un cluster Slurm su, passa all'argomento successivo all'indirizzo. SageMaker HyperPod [Esecuzione di carichi di lavoro di formazione distribuiti con Slurm on HyperPod](sagemaker-hyperpod-run-jobs-slurm-distributed-training-workload.md)