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á. # Trabalhos em SageMaker HyperPod clusters Os tópicos a seguir fornecem procedimentos e exemplos de como acessar nós de computação e executar cargas de trabalho de ML em clusters SageMaker HyperPod provisionados. Dependendo de como você configurou o ambiente em seu HyperPod cluster, há muitas maneiras de executar cargas de trabalho de ML em HyperPod clusters. Exemplos de execução de cargas de trabalho de ML em HyperPod clusters também são fornecidos no repositório [Awsome Distributed Training GitHub ](https://github.com/aws-samples/awsome-distributed-training/). Os tópicos a seguir explicam como fazer login nos HyperPod clusters provisionados e começar a executar amostras de cargas de trabalho de ML. **dica** Para encontrar exemplos e soluções práticas, veja também o [SageMaker HyperPodworkshop](https://catalog.workshops.aws/sagemaker-hyperpod). **Topics** + [Acessando seus nós SageMaker HyperPod de cluster](sagemaker-hyperpod-run-jobs-slurm-access-nodes.md) + [Agendamento de um trabalho do Slurm em um cluster SageMaker HyperPod](sagemaker-hyperpod-run-jobs-slurm-schedule-slurm-job.md) + [Executando contêineres Docker em um nó de computação Slurm em HyperPod](sagemaker-hyperpod-run-jobs-slurm-docker.md) + [Executando cargas de trabalho de treinamento distribuídas com o Slurm on HyperPod](sagemaker-hyperpod-run-jobs-slurm-distributed-training-workload.md) # Acessando seus nós SageMaker HyperPod de cluster Você pode acessar seu **InService**cluster por meio de AWS Systems Manager (SSM) executando o AWS CLI comando `aws ssm start-session` com o nome do host do SageMaker HyperPod cluster no formato de`sagemaker-cluster:[cluster-id]_[instance-group-name]-[instance-id]`. Você pode recuperar o ID do cluster, o ID da instância e o nome do grupo de instâncias no [SageMaker HyperPod console](sagemaker-hyperpod-operate-slurm-console-ui.md#sagemaker-hyperpod-operate-slurm-console-ui-view-details-of-clusters) ou executando `describe-cluster` e `list-cluster-nodes` usando os [AWS CLI comandos para SageMaker HyperPod](sagemaker-hyperpod-operate-slurm-cli-command.md#sagemaker-hyperpod-operate-slurm-cli-command-list-cluster-nodes). Por exemplo, se o ID do cluster for `aa11bbbbb222`, o nome do nó do cluster for `controller-group` e o ID do nó do cluster for `i-111222333444555aa`, o comando SSM `start-session` deverá ser o seguinte: **nota** Conceder aos usuários acesso aos nós HyperPod do cluster permite que eles instalem e operem software gerenciado pelo usuário nos nós. Mantenha o princípio de permissões de privilégio mínimo para os usuários. Se você não tiver configurado AWS Systems Manager, siga as instruções fornecidas em[Configurando AWS Systems Manager e executando como para controle de acesso do usuário do cluster](sagemaker-hyperpod-prerequisites.md#sagemaker-hyperpod-prerequisites-ssm). ``` $ aws ssm start-session \ --target sagemaker-cluster:aa11bbbbb222_controller-group-i-111222333444555aa \ --region us-west-2 Starting session with SessionId: s0011223344aabbccdd root@ip-111-22-333-444:/usr/bin# ``` Observe que isso inicialmente conecta você como usuário-raiz. Antes de executar os trabalhos, alterne para o usuário `ubuntu` executando o seguinte comando: ``` root@ip-111-22-333-444:/usr/bin# sudo su - ubuntu ubuntu@ip-111-22-333-444:/usr/bin# ``` Para configurações avançadas para o uso prático de HyperPod clusters, consulte os tópicos a seguir. **Topics** + [Dicas adicionais para acessar seus nós SageMaker HyperPod de cluster](#sagemaker-hyperpod-run-jobs-slurm-access-nodes-tips) + [Configure um ambiente multiusuário por meio do espaço FSx compartilhado da Amazon](#sagemaker-hyperpod-run-jobs-slurm-access-nodes-multi-user-with-fxs-shared-space) + [Configure um ambiente multiusuário integrando HyperPod clusters com o Active Directory](#sagemaker-hyperpod-run-jobs-slurm-access-nodes-multi-user-with-active-directory) ## Dicas adicionais para acessar seus nós SageMaker HyperPod de cluster **Use o `easy-ssh.sh` script fornecido por HyperPod para simplificar o processo de conexão** Para transformar o processo anterior em uma única linha de comando, a HyperPod equipe fornece o [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/easy-ssh.sh](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/easy-ssh.sh)script que recupera as informações do cluster, as agrega ao comando SSM e se conecta ao nó de computação. Você não precisa procurar manualmente as informações necessárias do HyperPod cluster, pois esse script é executado `describe-cluster` e `list-cluster-nodes` comanda e analisa as informações necessárias para concluir o comando SSM. Os comandos de exemplo a seguir mostram como executar o script [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/easy-ssh.sh](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/easy-ssh.sh). Se for executado com êxito, você será conectado ao cluster como usuário-raiz. Ele também imprime um trecho de código para configurar o SSH adicionando o HyperPod cluster como um host remoto por meio de um proxy SSM. Ao configurar o SSH, você pode conectar seu ambiente de desenvolvimento local, como o Visual Studio Code, ao HyperPod cluster. ``` $ chmod +x easy-ssh.sh $ ./easy-ssh.sh -c Cluster id: Instance id: Node Group: Add the following to your ~/.ssh/config to easily connect: $ cat <> ~/.ssh/config Host User ubuntu ProxyCommand sh -c "aws ssm start-session --target sagemaker-cluster:_- --document-name AWS-StartSSHSession --parameters 'portNumber=%p'" EOF Add your ssh keypair and then you can do: $ ssh aws ssm start-session --target sagemaker-cluster:_- Starting session with SessionId: s0011223344aabbccdd root@ip-111-22-333-444:/usr/bin# ``` Observe que isso inicialmente conecta você como usuário-raiz. Antes de executar os trabalhos, alterne para o usuário `ubuntu` executando o seguinte comando: ``` root@ip-111-22-333-444:/usr/bin# sudo su - ubuntu ubuntu@ip-111-22-333-444:/usr/bin# ``` **Configure para facilitar o acesso com SSH usando o nó de HyperPod computação como um host remoto** Para simplificar ainda mais o acesso ao nó de computação usando SSH de uma máquina local, o `easy-ssh.sh` script gera um trecho de código da configuração do HyperPod cluster como um host remoto, conforme mostrado na seção anterior. O trecho de código é gerado automaticamente para ajudar você a adicioná-lo diretamente ao `~/.ssh/config` arquivo em seu dispositivo local. O procedimento a seguir mostra como configurar o acesso fácil usando SSH por meio do proxy SSM, para que você ou os usuários do cluster possam executar diretamente `ssh ` a conexão com o nó do HyperPod cluster. 1. Em seu dispositivo local, adicione o nó de HyperPod computação com um nome de usuário como host remoto ao `~/.ssh/config` arquivo. O comando a seguir mostra como anexar o trecho de código gerado automaticamente do script `easy-ssh.sh` ao arquivo`~/.ssh/config`. Verifique se você o copiou da saída gerada automaticamente do script `easy-ssh.sh` que tem as informações corretas do cluster. ``` $ cat <> ~/.ssh/config Host User ubuntu ProxyCommand sh -c "aws ssm start-session --target sagemaker-cluster:_- --document-name AWS-StartSSHSession --parameters 'portNumber=%p'" EOF ``` 1. No nó do HyperPod cluster, adicione a chave pública do seu dispositivo local ao `~/.ssh/authorized_keys` arquivo no nó do HyperPod cluster. 1. Imprima o arquivo de chave pública na sua máquina local. ``` $ cat ~/.ssh/id_rsa.pub ``` Ela retornará sua chave. Copie a saída desse comando. (Opcional) Se você ainda não tem uma chave pública, crie uma executando o seguinte comando: ``` $ ssh-keygen -t rsa -q -f "$HOME/.ssh/id_rsa" -N "" ``` 1. Conecte-se ao nó do cluster e alterne para o usuário para adicionar a chave. O comando a seguir é um exemplo de acesso como usuário `ubuntu`. Substitua `ubuntu` pelo nome de usuário para o qual você deseja configurar o acesso fácil com SSH. ``` $ ./easy-ssh.sh -c $ sudo su - ubuntu ubuntu@ip-111-22-333-444:/usr/bin# ``` 1. Abra o arquivo `~/.ssh/authorized_keys` e adicione a chave pública ao final desse arquivo. ``` ubuntu@ip-111-22-333-444:/usr/bin# vim ~/.ssh/authorized_keys ``` Depois de concluir a configuração, você pode se conectar ao nó do HyperPod cluster como usuário executando um comando SSH simplificado da seguinte forma. ``` $ ssh ubuntu@ip-111-22-333-444:/usr/bin# ``` Além disso, você pode usar o host para desenvolvimento remoto a partir de um IDE em seu dispositivo local, como [Visual Studio Code Remote - SSH](https://code.visualstudio.com/docs/remote/ssh). ## Configure um ambiente multiusuário por meio do espaço FSx compartilhado da Amazon Você pode usar o espaço FSx compartilhado da Amazon para gerenciar um ambiente multiusuário em um cluster do Slurm em. SageMaker HyperPod Se você configurou seu cluster Slurm com a Amazon FSx durante a criação do HyperPod cluster, essa é uma boa opção para configurar o espaço de trabalho para os usuários do seu cluster. Crie um novo usuário e configure o diretório inicial do usuário no sistema de arquivos FSx compartilhados da Amazon. **dica** Para permitir que os usuários acessem o cluster por meio de seus nomes de usuário e diretórios dedicados, você também deve associá-los aos usuários ou perfis do IAM, marcando-os conforme orientado na **Opção 2** da etapa 5, no procedimento **Ative o suporte a Executar como para nós gerenciados do Linux no macOS** fornecido em [Ative o suporte a Executar como para nós gerenciados do Linux no macOS](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-preferences-run-as.html) no Manual do usuário do AWS Systems Manager . Consulte também [Configurando AWS Systems Manager e executando como para controle de acesso do usuário do cluster](sagemaker-hyperpod-prerequisites.md#sagemaker-hyperpod-prerequisites-ssm). **Para configurar um ambiente multiusuário ao criar um cluster Slurm no SageMaker HyperPod** A equipe SageMaker HyperPod de serviço fornece um script [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/add_users.sh](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/add_users.sh)como parte dos exemplos básicos de scripts do ciclo de vida. 1. Prepare um arquivo de texto chamado `shared_users.txt` que você precisa criar no formato a seguir. A primeira coluna é para nomes de usuário, a segunda coluna é para usuário IDs único e a terceira coluna é para os diretórios de usuários no espaço FSx compartilhado da Amazon. ``` username1,uid1,/fsx/username1 username2,uid2,/fsx/username2 ... ``` 1. Certifique-se de carregar os [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/add_users.sh](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/add_users.sh)arquivos `shared_users.txt` e no bucket do S3 para scripts de HyperPod ciclo de vida. Enquanto a criação do cluster, a atualização do cluster ou a atualização do software do cluster está em andamento, o [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/add_users.sh](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/add_users.sh) lê em `shared_users.txt`e configura os diretórios de usuário corretamente. **Para criar novos usuários e adicionar a um cluster Slurm existente em execução no SageMaker HyperPod ** 1. No nó principal, execute o seguinte comando para salvar um script que ajuda a criar um usuário: Não se esqueça de executar isso com as permissões sudo. ``` $ cat > create-user.sh << EOL #!/bin/bash set -x # Prompt user to get the new user name. read -p "Enter the new user name, i.e. 'sean': " USER # create home directory as /fsx/ # Create the new user on the head node sudo useradd \$USER -m -d /fsx/\$USER --shell /bin/bash; user_id=\$(id -u \$USER) # add user to docker group sudo usermod -aG docker \${USER} # setup SSH Keypair sudo -u \$USER ssh-keygen -t rsa -q -f "/fsx/\$USER/.ssh/id_rsa" -N "" sudo -u \$USER cat /fsx/\$USER/.ssh/id_rsa.pub | sudo -u \$USER tee /fsx/\$USER/.ssh/authorized_keys # add user to compute nodes read -p "Number of compute nodes in your cluster, i.e. 8: " NUM_NODES srun -N \$NUM_NODES sudo useradd -u \$user_id \$USER -d /fsx/\$USER --shell /bin/bash; # add them as a sudoer read -p "Do you want this user to be a sudoer? (y/N): " SUDO if [ "\$SUDO" = "y" ]; then sudo usermod -aG sudo \$USER sudo srun -N \$NUM_NODES sudo usermod -aG sudo \$USER echo -e "If you haven't already you'll need to run:\n\nsudo visudo /etc/sudoers\n\nChange the line:\n\n%sudo ALL=(ALL:ALL) ALL\n\nTo\n\n%sudo ALL=(ALL:ALL) NOPASSWD: ALL\n\nOn each node." fi EOL ``` 1. Execute o script com o comando a seguir. Você será solicitado a adicionar o nome de um usuário e o número de nós de computação que você deseja permitir que o usuário acesse. ``` $ bash create-user.sh ``` 1. Teste o usuário executando os comandos a seguir. ``` $ sudo su - && ssh $(srun hostname) ``` 1. Adicione as informações do usuário ao arquivo `shared_users.txt` para que o usuário seja criado em qualquer novo nó de computação ou em novos clusters. ## Configure um ambiente multiusuário integrando HyperPod clusters com o Active Directory Em casos de uso prático, os HyperPod clusters são normalmente usados por vários usuários: pesquisadores de aprendizado de máquina (ML), engenheiros de software, cientistas de dados e administradores de clusters. Eles editam seus próprios arquivos e executam seus próprios trabalhos sem afetar o trabalho uns dos outros. Para configurar um ambiente multiusuário, use o mecanismo de usuários e grupos do Linux para criar estaticamente vários usuários em cada instância por meio de scripts de ciclo de vida. No entanto, a desvantagem dessa abordagem é que você precisa duplicar as configurações de usuário e grupo em várias instâncias no cluster para manter uma configuração consistente em todas as instâncias ao fazer atualizações, como adicionar, editar e remover usuários. Para resolver isso, você pode usar o [Lightweight Directory Access Protocol (LDAP)](https://en.wikipedia.org/wiki/Lightweight_Directory_Access_Protocol) e o [LDAP over TLS/SSL (LDAPS)](https://en.wikipedia.org/wiki/Lightweight_Directory_Access_Protocol) para se integrar a um serviço de diretório, como o Directory [AWS Service for](https://aws.amazon.com/directoryservice/) Microsoft Active Directory. Para saber mais sobre como configurar o Active Directory e um ambiente multiusuário em um HyperPod cluster, consulte a postagem do blog [Integrar HyperPod clusters com o Active Directory para um login de vários usuários sem interrupções](https://aws.amazon.com/blogs/machine-learning/integrate-hyperpod-clusters-with-active-directory-for-seamless-multi-user-login/). # Agendamento de um trabalho do Slurm em um cluster SageMaker HyperPod Você pode iniciar trabalhos de treinamento usando os comandos padrão Slurm `sbatch` ou `srun`. Por exemplo, para iniciar um trabalho de treinamento de 8 nós, você pode executar um treinamento de `srun -N 8 --exclusive train.sh` SageMaker HyperPod suporte em uma variedade de ambientes`conda`, incluindo`venv`,`docker`, e. `enroot` Você pode configurar um ambiente de ML executando scripts de ciclo de vida em seus SageMaker HyperPod clusters. Você também tem a opção de anexar um sistema de arquivos compartilhado, como o Amazon FSx, que também pode ser usado como um ambiente virtual. O exemplo a seguir mostra como executar um trabalho para treinar o Llama-2 com a técnica Fully Sharded Data Parallelism (FSDP) em um cluster com um sistema de arquivos compartilhado da Amazon. SageMaker HyperPod FSx Você também pode encontrar mais exemplos no [ GitHub repositório Awsome Distributed Training](https://github.com/aws-samples/awsome-distributed-training/). **dica** Todos os SageMaker HyperPod exemplos estão disponíveis na `3.test_cases` pasta do [ GitHub repositório do Awsome Distributed Training](https://github.com/aws-samples/awsome-distributed-training/). 1. Clone o [ GitHub repositório Awsome Distributed Training](https://github.com/aws-samples/awsome-distributed-training/) e copie os exemplos de trabalhos de treinamento para o seu sistema de arquivos da Amazon FSx . ``` $ TRAINING_DIR=/fsx/users/my-user/fsdp $ git clone https://github.com/aws-samples/awsome-distributed-training/ ``` 1. Execute o script [https://github.com/aws-samples/awsome-distributed-training/blob/main/3.test_cases/10.FSDP/0.create_conda_env.sh](https://github.com/aws-samples/awsome-distributed-training/blob/main/3.test_cases/10.FSDP/0.create_conda_env.sh). Isso cria um `conda` ambiente no seu sistema de FSx arquivos da Amazon. Verifique se o sistema de arquivos está acessível a todos os nós do cluster. 1. Crie o ambiente virtual Conda iniciando um trabalho de slurm de nó único da seguinte forma: ``` $ srun -N 1 /path_to/create_conda_env.sh ``` 1. Depois que o ambiente for criado, você poderá iniciar um trabalho de treinamento apontando para o caminho do ambiente no volume compartilhado. Você pode iniciar trabalhos de treinamento de nó único e de vários nós com a mesma configuração. Para iniciar uma tarefa, crie um script inicializador de tarefas (também chamado de script de ponto de entrada) da seguinte forma: ``` #!/usr/bin/env bash set -ex ENV_PATH=/fsx/users/my_user/pytorch_env TORCHRUN=$ENV_PATH/bin/torchrun TRAINING_SCRIPT=/fsx/users/my_user/pt_train.py WORLD_SIZE_JOB=$SLURM_NTASKS RANK_NODE=$SLURM_NODEID PROC_PER_NODE=8 MASTER_ADDR=(`scontrol show hostnames \$SLURM_JOB_NODELIST | head -n 1`) MASTER_PORT=$(expr 10000 + $(echo -n $SLURM_JOBID | tail -c 4)) DIST_ARGS="--nproc_per_node=$PROC_PER_NODE \ --nnodes=$WORLD_SIZE_JOB \ --node_rank=$RANK_NODE \ --master_addr=$MASTER_ADDR \ --master_port=$MASTER_PORT \ " $TORCHRUN $DIST_ARGS $TRAINING_SCRIPT ``` **dica** Se você quiser tornar seu trabalho de treinamento mais resiliente contra falhas de hardware usando o recurso de retomada automática do SageMaker HyperPod, você precisa configurar adequadamente a variável de ambiente `MASTER_ADDR` no script do ponto de entrada. Para saber mais, consulte [Recuperação automática de nós e retomada automática](sagemaker-hyperpod-resiliency-slurm-auto-resume.md). Este tutorial pressupõe que esse script seja salvo como `/fsx/users/my_user/train.sh`. 1. Com esse script no volume compartilhado em `/fsx/users/my_user/train.sh`, execute o comando `srun` a seguir para agendar o trabalho do Slurm. ``` $ cd /fsx/users/my_user/ $ srun -N 8 train.sh ``` # 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 conseguem detectar caminhos de NVMe armazenamento das instâncias em que são executados e configuram os caminhos raiz para o Docker e o Enroot. `/opt/dlami/nvme` O volume raiz padrão de qualquer instância nova é montado `/tmp` somente com um volume EBS de 100 GB, que se esgota se a carga de trabalho que você planeja executar envolver treinamento LLMs e, portanto, contêineres Docker de grande porte. Se você usa famílias de instâncias como P e G com NVMe armazenamento local, você precisa se certificar de usar o NVMe armazenamento anexado em`/opt/dlami/nvme`, e os scripts de instalação cuidam 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-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 | +-----------------------------------------------------------------------------+ ``` 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-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 | +-----------------------------------------------------------------------------+ ``` **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 treinamento paralelo do modelo Llama 2 com a biblioteca de paralelismo de modelos SageMaker AI (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) # Executando cargas de trabalho de treinamento distribuídas com o Slurm on HyperPod SageMaker HyperPod é especializada em cargas de trabalho de treinamento de grandes modelos de linguagem (LLMs) e modelos básicos (FMs). Essas workloads geralmente exigem o uso de várias técnicas de paralelismo e operações otimizadas para infraestrutura e recursos de ML. Usando SageMaker HyperPod, você pode usar as seguintes estruturas de treinamento distribuído de SageMaker IA: + A [biblioteca de paralelismo de dados distribuídos (SMDDP) de SageMaker IA](data-parallel.md) que oferece operações de comunicação coletiva otimizadas para. AWS + A [biblioteca de paralelismo de modelos de SageMaker IA (SMP)](model-parallel-v2.md) que implementa várias técnicas de paralelismo de modelos. **Topics** + [Usando SMDDP em um SageMaker HyperPod](#sagemaker-hyperpod-run-jobs-slurm-distributed-training-workload-smddp) + [Usando SMP em um cluster SageMaker HyperPod](#sagemaker-hyperpod-run-jobs-slurm-distributed-training-workload-smp) ## Usando SMDDP em um SageMaker HyperPod A [biblioteca SMDDP](data-parallel.md) é uma biblioteca de comunicação coletiva que melhora o desempenho computacional do treinamento paralelo de dados distribuídos. A biblioteca SMDDP funciona com as seguintes estruturas de treinamento distribuídas de código aberto: + [PyTorchdados distribuídos paralelos (DDP)](https://pytorch.org/docs/stable/notes/ddp.html) + [PyTorch paralelismo de dados totalmente fragmentado (FSDP)](https://pytorch.org/docs/stable/fsdp.html) + [DeepSpeed](https://github.com/microsoft/DeepSpeed) + [Megatron- DeepSpeed](https://github.com/microsoft/Megatron-DeepSpeed) A biblioteca SMDDP aborda a sobrecarga de comunicação das principais operações de comunicação coletiva, oferecendo o seguinte para. SageMaker HyperPod + A biblioteca oferece opções `AllGather` otimizadas para AWS. `AllGather`é uma operação chave usada no treinamento paralelo de dados fragmentados, que é uma técnica de paralelismo de dados com eficiência de memória oferecida por bibliotecas populares. Isso inclui a biblioteca de paralelismo de modelos de SageMaker IA (SMP), o Otimizador de Redundância Zero ( DeepSpeed Zero) e o Paralelismo de Dados PyTorch Totalmente Compartilhado (FSDP). + A biblioteca realiza uma node-to-node comunicação otimizada utilizando totalmente a infraestrutura de AWS rede e a topologia da instância de SageMaker AI ML. **Para executar exemplos de trabalhos de treinamento em paralelo com dados** Explore os seguintes exemplos de treinamento distribuído implementando técnicas de paralelismo de dados usando a biblioteca SMDDP: + [https://github.com/aws-samples/awsome-distributed-training/tree/main/3.test_cases/12.SM-dataparallel-FSDP](https://github.com/aws-samples/awsome-distributed-training/tree/main/3.test_cases/12.SM-dataparallel-FSDP) + [https://github.com/aws-samples/awsome-distributed-training/tree/main/3.test_cases/13.SM-dataparallel-deepspeed](https://github.com/aws-samples/awsome-distributed-training/tree/main/3.test_cases/13.SM-dataparallel-deepspeed) **Para configurar um ambiente para usar a biblioteca SMDDP em SageMaker HyperPod** A seguir estão os requisitos do ambiente de treinamento para usar a biblioteca SMDDP em. SageMaker HyperPod + PyTorch v2.0.1 e versões posteriores + CUDA v11.8 e versões posteriores + `libstdc++` versão de runtime maior do que 3 + Python v3.10.x e posterior + `ml.p4d.24xlarge` e `ml.p4de.24xlarge`, que são tipos de instância compatíveis com a biblioteca SMDDP + `imdsv2` ativado no host de treinamento Dependendo de como você deseja executar o trabalho de treinamento distribuído, há duas opções para instalar a biblioteca SMDDP: + Uma instalação direta usando o arquivo binário SMDDP. + Usando o SageMaker AI Deep Learning Containers (DLCs) pré-instalado com a biblioteca SMDDP. As imagens do Docker pré-instaladas com a biblioteca SMDDP ou os arquivos binários do URLs SMDDP estão listadas em [Estruturas suportadas](https://docs.aws.amazon.com/sagemaker/latest/dg/distributed-data-parallel-support.html#distributed-data-parallel-supported-frameworks) na documentação da biblioteca SMDDP. **Para instalar a biblioteca SMDDP no DLAMI SageMaker HyperPod** + `pip install --no-cache-dir https://smdataparallel.s3.amazonaws.com/binary/pytorch//cuXYZ/YYYY-MM-DD/smdistributed_dataparallel-X.Y.Z-cp310-cp310-linux_x86_64.whl` **nota** Se você trabalha em um ambiente Conda, certifique-se de instalar PyTorch usando `conda install` em vez de`pip`. ``` conda install pytorch==X.Y.Z torchvision==X.Y.Z torchaudio==X.Y.Z pytorch-cuda=X.Y.Z -c pytorch -c nvidia ``` **Para usar a biblioteca SMDDP em um contêiner do Docker** + A biblioteca SMDDP está pré-instalada nos SageMaker AI Deep Learning Containers (). DLCs Para encontrar a lista de estruturas de SageMaker IA DLCs para PyTorch a biblioteca SMDDP, consulte [Estruturas suportadas](https://docs.aws.amazon.com/sagemaker/latest/dg/distributed-data-parallel-support.html#distributed-data-parallel-supported-frameworks) na documentação da biblioteca SMDDP. Você também pode trazer seu próprio contêiner do Docker com as dependências necessárias instaladas para usar a biblioteca SMDDP. Para saber mais sobre como configurar um contêiner do Docker personalizado para usar a biblioteca SMDDP, consulte também [Crie seu próprio contêiner Docker com a biblioteca paralela de dados distribuídos de SageMaker IA](data-parallel-bring-your-own-container.md). **Importante** Para usar a biblioteca SMDDP em um contêiner do Docker, monte o diretório `/var/log` da máquina host em `/var/log` no contêiner. Isso pode ser feito adicionando a seguinte opção ao executar seu contêiner: ``` docker run -v /var/log:/var/log ... ``` Para saber como executar trabalhos de treinamento com dados paralelos com o SMDDP em geral, consulte [Treinamento distribuído com a biblioteca de SageMaker paralelismo de dados distribuídos de IA](data-parallel-modify-sdp.md). ## Usando SMP em um cluster SageMaker HyperPod A [biblioteca de paralelismo de modelos de SageMaker IA (SMP)](model-parallel-v2.md) oferece várias técnicas de [paralelismo de state-of-the-art modelos](model-parallel-core-features-v2.md), incluindo: + paralelismo de dados completamente compartilhados + paralelismo especializado + treinamento misto de precisão com FP16/BF16 e tipos de FP8 dados + paralelismo de tensores A biblioteca SMP também é compatível com estruturas de código aberto, como PyTorch FSDP, NVIDIA Megatron e NVIDIA Transformer Engine. **Para executar um exemplo de workload de treinamento paralelo ao modelo** As equipes de serviços de SageMaker IA fornecem exemplos de trabalhos de treinamento implementando o paralelismo de modelos com a biblioteca SMP em. [https://github.com/aws-samples/awsome-distributed-training/tree/main/3.test_cases/17.SM-modelparallelv2](https://github.com/aws-samples/awsome-distributed-training/tree/main/3.test_cases/17.SM-modelparallelv2)