As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá. # Executando contêineres Docker em um nó de computação Slurm em HyperPod [Para executar contêineres do Docker com o Slurm ativado SageMaker HyperPod, você precisa usar o [Enroot](https://github.com/NVIDIA/enroot) e o Pyxis.](https://github.com/NVIDIA/pyxis) O pacote Enroot ajuda a converter imagens do Docker em um runtime que o Slurm possa entender, enquanto o Pyxis permite agendar o runtime como um trabalho do Slurm por meio de um comando `srun`, `srun --container-image={{docker/image:tag}}`. **dica** Os pacotes Docker, Enroot e Pyxis devem ser instalados durante a criação do cluster como parte da execução dos scripts de ciclo de vida, conforme orientado em [Scripts básicos de ciclo de vida fornecidos por HyperPod](sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-base-config.md). Use os [scripts básicos de ciclo de vida](https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config) fornecidos pela equipe HyperPod de serviço ao criar um HyperPod cluster. Esses scripts básicos são configurados para instalar os pacotes por padrão. No [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)script, há a classe `Config` com o parâmetro de tipo booleano para instalar os pacotes definidos como `True` (`enable_docker_enroot_pyxis=True`). Isso é chamado e analisado no [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)script, que chama os scripts `install_docker.sh` e `install_enroot_pyxis.sh` partir da pasta [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). Os scripts de instalação são onde as instalações reais dos pacotes ocorrem. Além disso, os scripts de instalação identificam se podem detectar caminhos de armazenamento NVMe das instâncias em que são executados e configuram os caminhos raiz para o Docker e o Enroot para `/opt/dlami/nvme`. O volume raiz padrão de qualquer instância nova é montado em `/tmp` somente com um volume EBS de 100 GB, que se esgota se a workload que você planeja executar envolver treinamento de LLMs e, portanto, de contêineres do Docker de grande porte. Se você usa famílias de instâncias, como P e G, com armazenamento NVMe local, precisa se certificar de usar o armazenamento NVMe anexado em `/opt/dlami/nvme`, e de que os scripts de instalação cuidem dos processos de configuração. **Para verificar se os caminhos raiz estão configurados corretamente** Em um nó de computação do seu cluster Slurm SageMaker HyperPod, execute os comandos a seguir para garantir que o script do ciclo de vida funcione corretamente e que o volume raiz de cada nó esteja definido como. `/opt/dlami/nvme/*` Os comandos a seguir mostram exemplos de verificação do caminho de runtime do Enroot e do caminho raiz de dados para 8 nós de computação de um 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 ``` Depois de confirmar que os caminhos de runtime estão configurados corretamente para `/opt/dlami/nvme/*`, você estará pronto para criar e executar contêineres do Docker com o Enroot e o Pyxis. **Para testar o Docker com o Slurm** 1. No seu nó de computação, tente os comandos a seguir para verificar se o Docker e o Enroot estão instalados corretamente. ``` $ docker --help $ enroot --help ``` 1. Teste se o Pyxis e o Enroot foram instalados corretamente executando uma das imagens [NVIDIA](https://catalog.ngc.nvidia.com/orgs/nvidia/containers/cuda) CUDA Ubuntu. ``` $ 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 | +-----------------------------------------------------------------------------+ ``` Você também pode testá-lo criando um script e executando um comando `sbatch` da seguinte maneira: ``` $ 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 | +-----------------------------------------------------------------------------+ ``` **Para executar um trabalho de teste do Slurm com o Docker** Depois de concluir a configuração do Slurm com o Docker, você pode trazer qualquer imagem pré-criada do Docker e executá-la usando o Slurm on. SageMaker HyperPod Veja a seguir um exemplo de caso de uso que mostra como executar um trabalho de treinamento usando o Docker e o Slurm on. SageMaker HyperPod Ele mostra um exemplo de trabalho de treinamento paralelo do modelo Llama 2 com a biblioteca de paralelismo de modelos de SageMaker IA (SMP). 1. Se você quiser usar uma das imagens ECR pré-criadas distribuídas por SageMaker AI ou DLC, certifique-se de dar ao seu HyperPod cluster as permissões para extrair imagens ECR por meio do. [Função do IAM para SageMaker HyperPod](sagemaker-hyperpod-prerequisites-iam.md#sagemaker-hyperpod-prerequisites-iam-role-for-hyperpod) Se você usar sua própria imagem do Docker ou de código aberto, você poderá ignorar esta etapa. Adicione as permissões a seguir ao arquivo [Função do IAM para SageMaker HyperPod](sagemaker-hyperpod-prerequisites-iam.md#sagemaker-hyperpod-prerequisites-iam-role-for-hyperpod). Neste tutorial, usamos a [imagem do Docker SMP](distributed-model-parallel-support-v2.md#distributed-model-parallel-supported-frameworks-v2) pré-empacotada com a biblioteca SMP. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ecr:BatchCheckLayerAvailability", "ecr:BatchGetImage", "ecr-public:*", "ecr:GetDownloadUrlForLayer", "ecr:GetAuthorizationToken", "sts:*" ], "Resource": "*" } ] } ``` ------ 1. No nó de computação, clone o repositório e acesse a pasta que fornece os exemplos de scripts de treinamento com SMP. ``` $ git clone https://github.com/aws-samples/awsome-distributed-training/ $ cd awsome-distributed-training/3.test_cases/17.SM-modelparallelv2 ``` 1. Neste tutorial, execute o script de amostra [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) que extrai a imagem do Docker SMP, cria o contêiner do Docker e o executa como um runtime do Enroot. Você pode modificar isso conforme desejar. ``` $ 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. Crie um script em lote para iniciar um trabalho de treinamento usando o `sbatch`. Neste tutorial, o exemplo de script fornecido [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) inicia um trabalho de treinamento paralelo ao modelo Llama 2 de 70 bilhões de parâmetros com um conjunto de dados sintético em 8 nós de computação. Um conjunto de scripts de treinamento é fornecido em [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` é usado `train_external.py` como script de ponto de entrada. **Importante** Para usar um contêiner do Docker SageMaker HyperPod, você deve montar o `/var/log` diretório da máquina host, que é o nó de HyperPod computação nesse caso, no `/var/log` diretório do contêiner. Você pode configurá-lo adicionando a seguinte variável para o 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}} ``` *Para encontrar os exemplos de código disponíveis para download, consulte [Executar um trabalho de treinamento paralelo ao modelo usando a biblioteca de paralelismo de modelos de SageMaker IA, Docker e Enroot with Slurm](https://github.com/aws-samples/awsome-distributed-training/tree/main/3.test_cases/17.SM-modelparallelv2#option-2----run-training-using-docker-and-enroot) no repositório Awsome Distributed Training. GitHub * Para obter mais informações sobre treinamento distribuído com um cluster Slurm ativado SageMaker HyperPod, vá para o próximo tópico em. [Executando cargas de trabalho de treinamento distribuídas com o Slurm on HyperPod](sagemaker-hyperpod-run-jobs-slurm-distributed-training-workload.md)