Esecuzione di contenitori Docker su un nodo di calcolo Slurm su HyperPod

Per eseguire contenitori Docker con Slurm attivo SageMaker HyperPod, devi usare Enroot e Pyxis. 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. Utilizza gli script del ciclo di vita di base 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 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 lifecycle_script.py, che chiama gli script install_docker.sh e install_enroot_pyxis.sh dalla cartella utils. Le installazioni effettive dei pacchetti avvengono negli script di installazione. Inoltre, gli script di installazione identificano se sono in grado di rilevare i percorsi di NVMe archiviazione dalle istanze su cui vengono eseguiti e configurano i percorsi root per Docker ed Enroot. /opt/dlami/nvme Il volume root predefinito di ogni nuova istanza viene montato /tmp solo su un volume EBS da 100 GB, che si esaurisce se il carico di lavoro che intendi eseguire prevede l'addestramento di contenitori Docker di LLMs grandi dimensioni. Se utilizzi famiglie di istanze come P e G con NVMe archiviazione locale, devi assicurarti di utilizzare lo NVMe storage allegato 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

Sul tuo nodo di calcolo, prova i comandi seguenti per verificare se Docker ed Enroot sono installati correttamente.
```
$ docker --help
$ enroot --help
```

Verifica se Pyxis ed Enroot sono installati correttamente eseguendo una delle immagini NVIDIA CUDA Ubuntu.


$ srun --container-image=nvidia/cuda:XX.Y.Z-base-ubuntuXX.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 <<EOF >> container-test.sh
#!/bin/bash
#SBATCH --container-image=nvidia/cuda:XX.Y.Z-base-ubuntuXX.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).

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 Se utilizzi un’immagine Docker personalizzata o open source, puoi saltare questa fase. Aggiungi le autorizzazioni seguenti al Ruolo IAM per SageMaker HyperPod. In questo tutorial, utilizziamo l’immagine Docker SMP 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": "*" } ] }

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

In questo tutorial, esegui lo script di esempio 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

Crea uno script batch per avviare un job di addestramento utilizzandosbatch. In questo tutorial, lo script di esempio fornito 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 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 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

Avvertimento JavaScript è disabilitato o non è disponibile nel tuo browser.

Per usare la documentazione AWS, JavaScript deve essere abilitato. Consulta le pagine della guida del browser per le istruzioni.

Convenzioni dei documenti

Pianificazione di processi Slurm

Esecuzione di carichi di lavoro di addestramento distribuito