SageMaker HyperPod melhores práticas de configuração do ciclo de vida - Amazon SageMaker
Prepare scripts de ciclo de vida para configurar o Slurm on SageMaker HyperPod

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á.

SageMaker HyperPod melhores práticas de configuração do ciclo de vida

SageMaker HyperPod oferece sempre clusters de up-and-running computação, que são altamente personalizáveis, pois você pode escrever scripts de ciclo de vida para informar SageMaker HyperPod como configurar os recursos do cluster. Os tópicos a seguir são as melhores práticas para preparar scripts de ciclo de vida para configurar SageMaker HyperPod clusters com ferramentas de gerenciamento de carga de trabalho de código aberto.

Prepare scripts de ciclo de vida para configurar o Slurm on SageMaker HyperPod

Os tópicos a seguir discutem como preparar scripts de ciclo de vida para configurar o Slurm. SageMaker HyperPod

Visão geral de alto nível

O procedimento a seguir é o fluxo principal de provisionamento de um HyperPod cluster e sua configuração com o Slurm. As etapas são colocadas na ordem de uma abordagem de baixo para cima.

  1. Planeje como você deseja criar nós do Slurm em um HyperPod cluster. Por exemplo, se você quiser configurar dois nós do Slurm, precisará configurar dois grupos de instâncias em um HyperPod cluster.

  2. Prepare um provisioning_parameters.json arquivo, que é umFormulário de configuração para provisionamento de nós do Slurm em HyperPod. provisioning_parameters.jsondeve conter informações de configuração do nó Slurm a serem provisionadas no cluster. HyperPod Isso deve refletir o design dos nós do Slurm da Etapa 1.

  3. Prepare um conjunto de scripts de ciclo de vida para configurar o Slurm on HyperPod para instalar pacotes de software e configurar um ambiente no cluster para seu caso de uso. Você deve estruturar os scripts de ciclo de vida para serem executados coletivamente em um script Python central (lifecycle_script.py) e escrever um script de shell de ponto de entrada () on_create.sh para executar o script Python. O script de shell do ponto de entrada é o que você precisa fornecer para uma solicitação de criação de HyperPod cluster posteriormente na Etapa 5.

    Além disso, observe que você deve escrever os scripts para esperar resource_config.json que sejam gerados HyperPod durante a criação do cluster. resource_config.jsoncontém informações de recursos do HyperPod cluster, como endereços IP, tipos de instância e ARNs, e é o que você precisa usar para configurar o Slurm.

  4. Reúna todos os arquivos das etapas anteriores em uma pasta.

    └── lifecycle_files // your local folder
    ├── provisioning_parameters.json
    ├── on_create.sh
    ├── lifecycle_script.py
    └── ... // more setup scrips to be fed into lifecycle_script.py

  5. Faça upload de todos os arquivos em um bucket do S3. Copie e mantenha o caminho do bucket do S3. Observe que você deve criar um caminho de bucket do S3 começando com sagemaker- porque precisa escolher um Função do IAM para SageMaker HyperPod anexo com AmazonSageMakerClusterInstanceRolePolicy, que só permite caminhos do bucket do S3 começando com o prefixo. sagemaker- O comando a seguir é um exemplo de comando para carregar todos os arquivos em um bucket do S3.

    aws s3 cp --recursive ./lifecycle_files s3://sagemaker-hyperpod-lifecycle/src

  6. Prepare uma solicitação de criação de HyperPod cluster.

    • Opção 1: se você usar o AWS CLI, escreva uma solicitação de criação de cluster no formato JSON (create_cluster.json) seguindo as instruções emCrie um novo cluster.

    • Opção 2: Se você usa a interface do usuário do SageMaker console, preencha o formulário Criar uma solicitação de cluster na interface do usuário do HyperPod console seguindo as instruções emCrie um SageMaker HyperPod cluster.

    Nesse estágio, certifique-se de criar grupos de instâncias na mesma estrutura planejada nas etapas 1 e 2. Além disso, certifique-se de especificar o bucket do S3 da Etapa 5 nos formulários de solicitação.

  7. Envie a solicitação de criação do cluster. HyperPod provisiona um cluster com base na solicitação e, em seguida, cria um resource_config.json arquivo nas instâncias do HyperPod cluster e configura o Slurm no cluster que executa os scripts de ciclo de vida.

A seção a seguir explica e detalha detalhadamente como organizar arquivos de configuração e scripts de ciclo de vida para que funcionem adequadamente durante HyperPod a criação do cluster.

Comece com scripts básicos de ciclo de vida fornecidos por HyperPod

Esta seção mostra cada componente do fluxo básico de configuração do Slurm on HyperPod em uma abordagem de cima para baixo. Ele começa com a preparação de uma solicitação de criação de HyperPod cluster para executar a CreateCluster API e se aprofunda na estrutura hierárquica até os scripts de ciclo de vida. Use os exemplos de scripts de ciclo de vida fornecidos no repositório do Awsome Distributed Training. GitHub Clone o repositório executando o comando a seguir.

git clone https://github.com/aws-samples/awsome-distributed-training/

Os scripts básicos do ciclo de vida para configurar um cluster do Slurm estão disponíveis em SageMaker HyperPod. 1.architectures/5.sagemaker_hyperpods/LifecycleScripts/base-config

cd awsome-distributed-training/1.architectures/5.sagemaker_hyperpods/LifecycleScripts/base-config

O fluxograma a seguir mostra uma visão geral detalhada de como você deve criar os scripts básicos do ciclo de vida. As descrições abaixo do diagrama e do guia de procedimentos explicam como eles funcionam durante a chamada da HyperPod CreateCluster API.

Figura: Um fluxograma detalhado da criação do HyperPod cluster e da estrutura dos scripts do ciclo de vida. (1) As setas tracejadas são direcionadas para onde as caixas são “chamadas” e mostram o fluxo dos arquivos de configuração e a preparação dos scripts do ciclo de vida. Tudo começa com a preparação provisioning_parameters.json e os scripts do ciclo de vida. Eles são então codificados lifecycle_script.py para uma execução coletiva em ordem. E a execução do lifecycle_script.py script é feita pelo script on_create.sh shell, que deve ser executado no terminal da HyperPod instância. (2) As setas sólidas mostram o fluxo principal de criação do HyperPod cluster e como as caixas são “chamadas para” ou “enviadas para”. on_create.shé necessário para a solicitação de criação de cluster, no formulário Criar uma solicitação de cluster create_cluster.json ou no formulário Criar uma solicitação de cluster na interface do console. Depois de enviar a solicitação, HyperPod executa a CreateCluster API com base nas informações de configuração fornecidas pela solicitação e nos scripts do ciclo de vida. (3) A seta pontilhada indica que a HyperPod plataforma cria resource_config.json nas instâncias do cluster durante o provisionamento de recursos do cluster. resource_config.jsoncontém informações sobre os recursos do HyperPod cluster, como o ARN do cluster, os tipos de instância e os endereços IP. É importante observar que você deve preparar os scripts de ciclo de vida para esperar o resource_config.json arquivo durante a criação do cluster. Para obter mais informações, consulte o guia de procedimentos abaixo.

O guia de procedimentos a seguir explica o que acontece durante a criação HyperPod do cluster e como os scripts básicos do ciclo de vida são projetados.

  1. create_cluster.json— Para enviar uma solicitação de criação de HyperPod cluster, você prepara um arquivo de CreateCluster solicitação no formato JSON. Neste exemplo de melhores práticas, presumimos que o arquivo de solicitação tenha um nomecreate_cluster.json. Escreva create_cluster.json para provisionar um HyperPod cluster com grupos de instâncias. A melhor prática é adicionar o mesmo número de grupos de instâncias que o número de nós do Slurm que você planeja configurar no HyperPod cluster. Certifique-se de dar nomes distintos aos grupos de instâncias que você atribuirá aos nós do Slurm que você planeja configurar.

    Além disso, é necessário especificar um caminho de bucket do S3 para armazenar todo o conjunto de arquivos de configuração e scripts de ciclo de vida no nome do campo InstanceGroups.LifeCycleConfig.SourceS3Uri no formulário de CreateCluster solicitação e especificar o nome do arquivo de um script de shell de ponto de entrada (suponha que ele tenha um nome) para. on_create.sh InstanceGroups.LifeCycleConfig.OnCreate

    nota

    Se você estiver usando o formulário de envio Criar um cluster na interface do HyperPod console, o console gerencia o preenchimento e o envio da CreateCluster solicitação em seu nome e executa a CreateCluster API no back-end. Nesse caso, você não precisa criarcreate_cluster.json; em vez disso, certifique-se de especificar as informações corretas de configuração do cluster no formulário de envio Criar um cluster.

  2. on_create.sh— Para cada grupo de instâncias, você precisa fornecer um script de shell de ponto de entrada, executar comandoson_create.sh, executar scripts para instalar pacotes de software e configurar o ambiente de HyperPod cluster com o Slurm. As duas coisas que você precisa preparar são uma provisioning_parameters.json exigência HyperPod para configurar o Slurm e um conjunto de scripts de ciclo de vida para instalar pacotes de software. Esse script deve ser escrito para localizar e executar os seguintes arquivos, conforme mostrado no script de amostra em on_create.sh.

    nota

    Certifique-se de carregar todo o conjunto de scripts de ciclo de vida no local do S3 especificado. create_cluster.json Você também deve colocar o seu provisioning_parameters.json no mesmo local.

    1. provisioning_parameters.json— Este é umFormulário de configuração para provisionamento de nós do Slurm em HyperPod. O on_create.sh script encontra esse arquivo JSON e define a variável de ambiente para identificar o caminho até ele. Por meio desse arquivo JSON, você pode configurar os nós do Slurm e as opções de armazenamento, como o Amazon FSx for Lustre for Slurm, com os quais se comunicar. Emprovisioning_parameters.json, certifique-se de atribuir os grupos de instâncias do HyperPod cluster usando os nomes que você especificou nos create_cluster.json nós do Slurm de forma adequada, com base em como você planeja configurá-los.

      O diagrama a seguir mostra um exemplo de como os dois arquivos de configuração JSON provisioning_parameters.json devem ser create_cluster.json gravados para atribuir grupos de HyperPod instâncias aos nós do Slurm. Neste exemplo, assumimos um caso de configuração de três nós do Slurm: nó controlador (gerenciamento), nó de login (que é opcional) e nó de computação (trabalhador).

      dica

      Para ajudá-lo a validar esses dois arquivos JSON, a equipe de HyperPod serviço fornece um script de validação,. validate-config.py Para saber mais, consulte Valide os arquivos de configuração JSON antes de criar um cluster Slurm no HyperPod.

      Figura: Comparação direta entre create_cluster.json a criação HyperPod do cluster e a configuração provisiong_params.json do Slurm. O número de grupos de instâncias em create_cluster.json deve corresponder ao número de nós que você deseja configurar como nós do Slurm. No caso do exemplo na figura, três nós do Slurm serão configurados em um HyperPod cluster de três grupos de instâncias. Você deve atribuir os grupos de instâncias do HyperPod cluster aos nós do Slurm especificando os nomes dos grupos de instâncias adequadamente.

    2. resource_config.json— Durante a criação do cluster, o lifecycle_script.py script é escrito para esperar um resource_config.json arquivo do HyperPod. Esse arquivo contém informações sobre o cluster, como tipos de instância e endereços IP.

      Quando você executa a CreateCluster API, HyperPod cria um arquivo de configuração de recursos /opt/ml/config/resource_config.json com base no create_cluster.json arquivo. O caminho do arquivo é salvo na variável de ambiente chamadaSAGEMAKER_RESOURCE_CONFIG_PATH.

      Importante

      O resource_config.json arquivo é gerado automaticamente pela HyperPod plataforma e você NÃO precisa criá-lo. O código a seguir é para mostrar um exemplo do resource_config.json que seria criado a partir da criação do cluster com base create_cluster.json na etapa anterior e para ajudar você a entender o que acontece no back-end e como resource_config.json seria a aparência de uma geração automática.

      {
    "ClusterConfig": {
        "ClusterArn": "arn:aws:sagemaker:us-west-2:111122223333:cluster/abcde01234yz",
        "ClusterName": "your-hyperpod-cluster"
    },
    "InstanceGroups": [
        {
            "Name": "controller-machine",
            "InstanceType": "ml.c5.xlarge",
            "Instances": [
                {
                    "InstanceName": "controller-machine-1",
                    "AgentIpAddress": "111.222.333.444",
                    "CustomerIpAddress": "111.222.333.444",
                    "InstanceId": "i-12345abcedfg67890"
                }
            ]
        },
        {
            "Name": "login-group",
            "InstanceType": "ml.m5.xlarge",
            "Instances": [
                {
                    "InstanceName": "login-group-1",
                    "AgentIpAddress": "111.222.333.444",
                    "CustomerIpAddress": "111.222.333.444",
                    "InstanceId": "i-12345abcedfg67890"
                }
            ]
        },
        {
            "Name": "compute-nodes",
            "InstanceType": "ml.trn1.32xlarge",
            "Instances": [
                {
                    "InstanceName": "compute-nodes-1",
                    "AgentIpAddress": "111.222.333.444",
                    "CustomerIpAddress": "111.222.333.444",
                    "InstanceId": "i-12345abcedfg67890"
                },
                {
                    "InstanceName": "compute-nodes-2",
                    "AgentIpAddress": "111.222.333.444",
                    "CustomerIpAddress": "111.222.333.444",
                    "InstanceId": "i-12345abcedfg67890"
                },
                {
                    "InstanceName": "compute-nodes-3",
                    "AgentIpAddress": "111.222.333.444",
                    "CustomerIpAddress": "111.222.333.444",
                    "InstanceId": "i-12345abcedfg67890"
                },
                {
                    "InstanceName": "compute-nodes-4",
                    "AgentIpAddress": "111.222.333.444",
                    "CustomerIpAddress": "111.222.333.444",
                    "InstanceId": "i-12345abcedfg67890"
                }
            ]
        }
    ]
}

    3. lifecycle_script.py— Esse é o script principal do Python que executa coletivamente scripts de ciclo de vida configurando o Slurm no cluster enquanto está sendo provisionado. HyperPod Esse script lê provisioning_parameters.json e resource_config.json recebe os caminhos especificados ou identificadoson_create.sh, passa as informações relevantes para cada script de ciclo de vida e, em seguida, executa os scripts de ciclo de vida em ordem.

      Os scripts de ciclo de vida são um conjunto de scripts que você tem total flexibilidade para personalizar para instalar pacotes de software e definir as configurações necessárias ou personalizadas durante a criação do cluster, como configurar o Slurm, criar usuários, instalar o Conda ou o Docker. O lifecycle_script.pyscript de amostra está preparado para executar outros scripts básicos de ciclo de vida no repositório, como iniciar o Slurm deamons (), montar o Amazon start_slurm.shFSx for Lustre () e configurar a contabilidade do MariaDB () mount_fsx.she a contabilidade do RDS (). setup_mariadb_accounting.shsetup_rds_accounting.sh Você também pode adicionar mais scripts, empacotá-los no mesmo diretório e adicionar linhas de código lifecycle_script.py para permitir a HyperPod execução dos scripts. Para obter mais informações sobre os scripts de ciclo de vida básicos, consulte também 3.1 Scripts de ciclo de vida no repositório Awsome Distributed Training. GitHub

      Além das configurações padrão, mais scripts para instalar o software a seguir estão disponíveis na utilspasta. O lifecycle_script.py arquivo já está preparado para incluir linhas de código para executar os scripts de instalação, portanto, consulte os itens a seguir para pesquisar essas linhas e descomentar para ativá-las.

      1. As linhas de código a seguir são para instalar o Docker, o Enroot e o Pyxis. Esses pacotes são necessários para executar contêineres Docker em um cluster Slurm.

        Para habilitar essa etapa de instalação, defina o enable_docker_enroot_pyxis parâmetro como True no config.pyarquivo.

        # Install Docker/Enroot/Pyxis
if Config.enable_docker_enroot_pyxis:
    ExecuteBashScript("./utils/install_docker.sh").run()
    ExecuteBashScript("./utils/install_enroot_pyxis.sh").run(node_type)

      2. Você pode integrar seu HyperPod cluster com o Amazon Managed Service for Prometheus e o Amazon Managed Grafana para exportar métricas HyperPod sobre o cluster e os nós do cluster para os painéis do Amazon Managed Grafana. Para exportar métricas e usar o painel Slurm, o painelNVIDIA DCGM Exporter e o painel EFA Metrics no Amazon Managed Grafana, você precisa instalar o exportador Slurm para Prometheus, o exportador NVIDIA DCGM e o exportador de nós EFA. Para obter mais informações sobre a instalação dos pacotes do exportador e o uso dos painéis do Grafana em um espaço de trabalho do Grafana gerenciado pela Amazon, consulte. Monitore os recursos SageMaker HyperPod do cluster

        Para habilitar essa etapa de instalação, defina o enable_observability parâmetro como True no config.pyarquivo.

        # Install metric exporting software and Prometheus for observability
if Config.enable_observability:
    if node_type == SlurmNodeType.COMPUTE_NODE:
        ExecuteBashScript("./utils/install_docker.sh").run()
        ExecuteBashScript("./utils/install_dcgm_exporter.sh").run()
        ExecuteBashScript("./utils/install_efa_node_exporter.sh").run()

    if node_type == SlurmNodeType.HEAD_NODE:
        wait_for_scontrol()
        ExecuteBashScript("./utils/install_docker.sh").run()
        ExecuteBashScript("./utils/install_slurm_exporter.sh").run()
        ExecuteBashScript("./utils/install_prometheus.sh").run()

  3. Certifique-se de carregar todos os arquivos e scripts de configuração da Etapa 2 para o bucket do S3 que você fornece na CreateCluster solicitação na Etapa 1. Por exemplo, suponha que você create_cluster.json tenha o seguinte.

    "LifeCycleConfig": { 
    "SourceS3URI": "s3://sagemaker-hyperpod-lifecycle/src",
    "OnCreate": "on_create.sh"
}

    Em seguida, você "s3://sagemaker-hyperpod-lifecycle/src" deve conteron_create.sh,lifecycle_script.py,provisioning_parameters.json, e todos os outros scripts de configuração. Suponha que você tenha preparado os arquivos em uma pasta local da seguinte maneira.

    └── lifecycle_files // your local folder
    ├── provisioning_parameters.json
    ├── on_create.sh
    ├── lifecycle_script.py
    └── ... // more setup scrips to be fed into lifecycle_script.py

    Para carregar os arquivos, use o comando S3 da seguinte maneira.

    aws s3 cp --recursive ./lifecycle_scripts s3://sagemaker-hyperpod-lifecycle/src

Quais configurações específicas HyperPod gerenciam nos arquivos de configuração do Slurm

Quando você cria um cluster do Slurm no HyperPod, o HyperPod agente configura os gres.confarquivos slurm.confe em /opt/slurm/etc/ para gerenciar o cluster do Slurm com base na solicitação de criação do cluster e nos scripts HyperPod do ciclo de vida. A lista a seguir mostra quais parâmetros específicos o HyperPod agente manipula e substitui.

Importante

É altamente recomendável que você não altere esses parâmetros gerenciados pelo HyperPod.

  • Em slurm.conf, HyperPod configura os seguintes parâmetros básicos: ClusterName SlurmctldHostPartitionName,, NodeName e.

    Além disso, para habilitar a Retoma automático funcionalidade, é HyperPod necessário definir SchedulerParameters os parâmetros TaskPlugin e da seguinte forma. O HyperPod agente configura esses dois parâmetros com os valores necessários por padrão.

    TaskPlugin=task/none
SchedulerParameters=permit_job_expansion

  • Em gres.conf, HyperPod gerencia NodeName os nós da GPU.

Monte o Amazon FSx for HyperPod Lustre em seu cluster

Para montar um sistema HyperPod de arquivos compartilhado Amazon FSx for Lustre em seu cluster, configure o seguinte.

  1. Use sua Amazon VPC.

    1. Para que as instâncias de HyperPod cluster se comuniquem com sua VPC, certifique-se de anexá-las (Opcional) Permissões adicionais para uso SageMaker HyperPod com a Amazon Virtual Private Cloud à função do IAM para. SageMaker HyperPod

    2. Emcreate_cluster.json, inclua as seguintes informações de VPC.

      "VpcConfig": { 
    "SecurityGroupIds": [ "string" ],
    "Subnets": [ "string" ]
}

      Para obter mais dicas sobre como configurar a Amazon VPC, consulte. (Opcional) Configure SageMaker HyperPod com sua Amazon VPC

  2. Para concluir a configuração do Slurm com o Amazon FSx for Lustre, especifique o nome DNS do Amazon FSx e o nome da montagem do Amazon FSx, conforme mostrado na figura na seção. provisioning_parameters.json Comece com scripts básicos de ciclo de vida fornecidos por HyperPod Você pode encontrar as informações do Amazon FSx no console do Amazon FSx for Lustre em sua conta ou executando o seguinte comando,. AWS CLI aws fsx describe-file-systems

    "fsx_dns_name": "fs-12345678a90b01cde.fsx.us-west-2.amazonaws.com",
"fsx_mountname": "1abcdefg"

Valide os arquivos de configuração JSON antes de criar um cluster Slurm no HyperPod

Para validar os arquivos de configuração JSON antes de enviar uma solicitação de criação de cluster, use o script de validação de configuração. validate-config.py Esse script analisa e compara o arquivo JSON de configuração do HyperPod cluster e o arquivo JSON de configuração do Slurm e identifica se há alguma configuração incorreta de recursos entre os dois arquivos e também entre os recursos do Amazon EC2, Amazon VPC e Amazon FSx. Por exemplo, para validar os provisioning_parameters.json arquivos create_cluster.json e da Comece com scripts básicos de ciclo de vida fornecidos por HyperPod seção, execute o script de validação da seguinte maneira.

python3 validate-config.py --cluster-config create_cluster.json --provisioning-parameters provisioning_parameters.json

Veja a seguir um exemplo de saída de uma validação bem-sucedida.

✔️  Validated instance group name worker-group-1 is correct ...
✔️  Validated subnet subnet-012345abcdef67890 ...
✔️  Validated security group sg-012345abcdef67890 ingress rules ...
✔️  Validated security group sg-012345abcdef67890 egress rules ...
✔️  Validated FSx Lustre DNS name fs-012345abcdef67890.fsx.us-east-1.amazonaws.com
✔️  Validated FSx Lustre mount name abcdefgh
✅ Cluster Validation succeeded

Valide o tempo de execução antes de executar cargas de trabalho de produção em um cluster Slurm no HyperPod

Para verificar o tempo de execução antes de executar qualquer carga de trabalho de produção em um cluster do Slurm HyperPod, use o script de validação do tempo de execução. hyperpod-precheck.py Esse script verifica se o cluster Slurm tem todos os pacotes instalados para executar o Docker, se o cluster tem um sistema de arquivos FSx for Lustre montado corretamente e um diretório de usuário compartilhando o sistema de arquivos, e se o deamon do Slurm está sendo executado em todos os nós de computação.

Para executar o script em vários nós ao mesmo tempo, use, srun conforme mostrado no exemplo a seguir, o comando de execução do script em um cluster do Slurm de 8 nós.

# The following command runs on 8 nodes
srun -N 8 python3 hyperpod-precheck.py
nota

Para saber mais sobre o script de validação, como quais funções de validação em tempo de execução o script fornece e diretrizes para resolver problemas que não passam nas validações, consulte Validação em tempo de execução antes de executar cargas de trabalho no repositório do Awsome Distributed Training. GitHub

Desenvolva scripts de ciclo de vida interativamente em um nó de cluster

Esta seção explica como você pode desenvolver scripts de ciclo de vida interativamente sem criar e excluir repetidamente um cluster. HyperPod

  1. Crie um HyperPod cluster com os scripts básicos do ciclo de vida.

  2. Faça login em um nó do cluster.

  3. Desenvolva um script (configure_xyz.sh) editando-o e executando-o repetidamente no nó.

    1. HyperPod executa os scripts de ciclo de vida como usuário raiz, portanto, recomendamos que você execute o configure_xyz.sh como usuário raiz durante o desenvolvimento para garantir que o script seja testado sob as mesmas condições durante a execução do. HyperPod

  4. Integre o script lifecycle_script.py adicionando uma linha de código semelhante à seguinte.

    ExecuteBashScript("./utils/configure_xyz.sh").run()

  5. Faça upload dos scripts de ciclo de vida atualizados para o bucket do S3 que você usou inicialmente para carregar os scripts de ciclo de vida básicos.

  6. Teste a versão integrada do lifecycle_script.py criando um novo HyperPod cluster.

Atualize um cluster com scripts de ciclo de vida novos ou atualizados

Há três maneiras de atualizar o HyperPod software.

  • A UpdateClusterSoftware API para corrigir o HyperPod software executa novamente os scripts do ciclo de vida em todo o grupo de instâncias.

  • A UpdateCluster API só executa os scripts de ciclo de vida para novos grupos de instâncias.

  • Você também pode executar scripts de ciclo de vida diretamente nas instâncias. HyperPod

Considerações

Considere o seguinte ao usar SageMaker HyperPod.

  • HyperPod é executado SageMaker HyperPod DLAMI em cada instância de um cluster, e a AMI tem pacotes de software pré-instalados que atendem às compatibilidades e funcionalidades entre eles. HyperPod Observe que, se você reinstalar qualquer um dos pacotes pré-instalados, você será responsável pela instalação de pacotes compatíveis e observe que algumas HyperPod funcionalidades podem não funcionar conforme o esperado.