View a markdown version of this page

Personalização de SageMaker HyperPod clusters usando scripts de ciclo de vida - SageMaker IA da Amazon

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

Personalização de SageMaker HyperPod clusters usando scripts de 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.

Os tópicos a seguir discutem as melhores práticas detalhadas para preparar scripts de ciclo de vida para configurar as configurações do Slurm. SageMaker HyperPod

Uma 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 a configuração do Slurm. Escolha uma das seguintes abordagens:

    • Opção A: configuração orientada por API (recomendada) — defina os tipos de nós e partições do Slurm diretamente na carga da CreateCluster API usando dentro de cada grupo de instâncias. SlurmConfig Com essa abordagem:

      • Nenhum provisioning_parameters.json arquivo é necessário

      • A topologia do Slurm é definida na carga útil da API junto com as definições do grupo de instâncias

      • FSx os sistemas de arquivos são configurados via per-instance-group InstanceStorageConfigs

      • A estratégia de configuração é controlada via Orchestrator.Slurm.SlurmConfigStrategy

      Exemplo SlurmConfig em um grupo de instâncias:

      { "InstanceGroupName": "gpu-compute", "InstanceType": "ml.p4d.24xlarge", "InstanceCount": 8, "SlurmConfig": { "NodeType": "Compute", "PartitionNames": ["gpu-training"] } }
    • Opção B: Configuração legada — Prepare um provisioning_parameters.json arquivo, que é umFormulário de configuração para provisioning_parameters.json. 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. A estrutura da pasta depende da abordagem de configuração selecionada na Etapa 2.

    Se você selecionou a Opção A (configuração baseada em API):

    Sua pasta só precisa de scripts de ciclo de vida para tarefas de configuração personalizadas. A configuração e FSx montagem do Slurm são feitas automaticamente com HyperPod base na carga útil da API.

    └── lifecycle_files // your local folder ├── on_create.sh ├── lifecycle_script.py └── ... // more setup scripts to be fed into lifecycle_script.py
    nota

    O provisioning_parameters.json arquivo não é necessário ao usar a configuração orientada por API.

    Se você selecionou a Opção B (configuração antiga):

    Sua pasta deve incluir provisioning_parameters.json o conjunto completo de scripts de ciclo de vida.

    └── 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 emCriar um novo cluster.

    • Opção 2: se você usa a interface de usuário do console SageMaker AI, preencha o formulário de solicitação de criação de um 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, especifique 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.

Os tópicos a seguir explicam e aprofundam os detalhes sobre como organizar arquivos de configuração e scripts de ciclo de vida para que funcionem adequadamente durante a criação do HyperPod cluster.