Criação de um SageMaker HyperPod cluster - 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á.

Criação de um SageMaker HyperPod cluster

Saiba como criar SageMaker HyperPod clusters orquestrados pelo Amazon EKS usando o. AWS CLI

  1. Antes de criar um SageMaker HyperPod cluster:

    1. Certifique-se de ter um cluster existente do Amazon EKS instalado e em execução. Para obter instruções sobre como criar um novo cluster do Amazon EKS, consulte Criar um cluster do Amazon EKS no Guia do usuário do Amazon EKS.

    2. Instale o chart do Helm conforme as instruções em Instalar pacotes no cluster do Amazon EKS usando o Helm. Se você criar um Criação de um cluster HyperPod EKS com grupo de instâncias restritas (RIG), precisará de um chart do Helm distinto.

  2. Prepare um script de configuração de ciclo de vida e faça upload em um bucket do Amazon S3, como s3://amzn-s3-demo-bucket/Lifecycle-scripts/base-config/.

    Para começar rapidamente, baixe o script on_create.shde amostra do GitHub repositório de treinamento distribuído AWS ome e carregue-o no bucket do S3. Você também pode incluir instruções adicionais de configuração, uma série de scripts de configuração ou comandos a serem executados durante o estágio de provisionamento do HyperPod cluster.

    Importante

    Se você criar um Função do IAM para SageMaker HyperPod anexando somente a AmazonSageMakerClusterInstanceRolePolicy gerenciada, seu cluster terá acesso aos buckets do Amazon S3 com o prefixo específico sagemaker-.

    Se você criar um grupo de instâncias restrito, não será necessário fazer download e executar o script de ciclo de vida. Em vez disso, você precisará executar install_rig_dependencies.sh.

    Os pré-requisitos para executar o script install_rig_dependencies.sh são:

    • AWS O Node (CNI) e o CoreDNS devem estar habilitados. Esses são complementos EKS padrão que não são gerenciados pelo SageMaker HyperPod Helm padrão, mas podem ser facilmente ativados no console EKS em Complementos.

    • O gráfico padrão do SageMaker HyperPod Helm deve ser instalado antes da execução desse script.

    O script install_rig_dependencies.sh executa as ações a seguir.

    • aws-node (CNI): foi criado um Daemonset rig-aws-node. O aws-node existente foi corrigido para evitar nós RIG.

    • coredns: Convertido em Daemonset RIGs para suportar o uso de várias plataformas e evitar sobrecargas.

    • training-operators: atualizado com tolerâncias a taint e nodeAffinity no nó de processamento RIG para favorecer instâncias que não são RIG.

    • Elastic Fabric Adapter (EFA): atualizado para tolerar taint no nó de processamento RIG e usar imagens de contêiner corretas para cada região.

  3. Prepare um arquivo de solicitação de CreateClusterAPI no formato JSON. Para ExecutionRole, forneça o ARN do perfil do IAM que você criou com o AmazonSageMakerClusterInstanceRolePolicy gerenciado da seção Função do IAM para SageMaker HyperPod.

    nota

    Certifique-se de que seu SageMaker HyperPod cluster seja implantado na mesma Virtual Private Cloud (VPC) do seu cluster Amazon EKS. As sub-redes e os grupos de segurança especificados na configuração do SageMaker HyperPod cluster devem permitir conectividade de rede e comunicação com o endpoint do servidor de API do cluster Amazon EKS.

    // create_cluster.json { "ClusterName": "string", "InstanceGroups": [{ "InstanceGroupName": "string", "InstanceType": "string", "InstanceCount": number, "LifeCycleConfig": { "SourceS3Uri": "s3://amzn-s3-demo-bucket-sagemaker/lifecycle-script-directory/src/", "OnCreate": "on_create.sh" }, "ExecutionRole": "string", "ThreadsPerCore": number, "OnStartDeepHealthChecks": [ "InstanceStress", "InstanceConnectivity" ] }], "RestrictedInstanceGroups": [ { "EnvironmentConfig": { "FSxLustreConfig": { "PerUnitStorageThroughput": number, "SizeInGiB": number } }, "ExecutionRole": "string", "InstanceCount": number, "InstanceGroupName": "string", "InstanceStorageConfigs": [ { ... } ], "InstanceType": "string", "OnStartDeepHealthChecks": [ "string" ], "OverrideVpcConfig": { "SecurityGroupIds": [ "string" ], "Subnets": [ "string" ] }, "ScheduledUpdateConfig": { "DeploymentConfig": { "AutoRollbackConfiguration": [ { "AlarmName": "string" } ], "RollingUpdatePolicy": { "MaximumBatchSize": { "Type": "string", "Value": number }, "RollbackMaximumBatchSize": { "Type": "string", "Value": number } }, "WaitIntervalInSeconds": number }, "ScheduleExpression": "string" }, "ThreadsPerCore": number, "TrainingPlanArn": "string" } ], "VpcConfig": { "SecurityGroupIds": ["string"], "Subnets": ["string"] }, "Tags": [{ "Key": "string", "Value": "string" }], "Orchestrator": { "Eks": { "ClusterArn": "string", "KubernetesConfig": { "Labels": { "nvidia.com/mig.config": "all-3g.40gb" } } } }, "NodeRecovery": "Automatic" }

    Observe o seguinte ao configurar para criar um novo SageMaker HyperPod cluster associado a um cluster EKS.

    • Você pode configurar até 20 grupos de instâncias sob o InstanceGroups parâmetro.

    • Para Orchestator.Eks.ClusterArn, especifique o ARN do cluster do EKS que você deseja usar como orquestrador.

    • Para OnStartDeepHealthChecks, adicione InstanceStress e InstanceConnectivity para ativar Verificações de integridade profundas.

    • ParaNodeRecovery, especifique Automatic para ativar a recuperação automática de nós. SageMaker HyperPod substitui ou reinicializa instâncias (nós) quando problemas são encontrados pelo agente de monitoramento de integridade.

    • Para o Tags parâmetro, você pode adicionar tags personalizadas para gerenciar o SageMaker HyperPod cluster como um AWS recurso. Você pode adicionar tags ao seu cluster da mesma forma que as adiciona em outros serviços AWS que oferecem apoio à marcação. Para saber mais sobre a marcação de recursos da AWS em geral, consulte o Guia do usuário de AWS recursos de marcação.

    • Para o parâmetro VpcConfig, especifique as informações da VPC usada no cluster do EKS. As sub-redes devem ser privadas.

    • Para issoOrchestrator.Eks.KubernetesConfig.Labels, você pode especificar opcionalmente os rótulos do Kubernetes a serem aplicados aos nós. Para habilitar o particionamento de GPU com a GPU de várias instâncias (MIG), adicione o nvidia.com/mig.config rótulo com o perfil MIG desejado. Por exemplo, "nvidia.com/mig.config": "all-3g.40gb" configura tudo GPUs com o perfil de partição 3g.40gb. Para obter mais informações sobre particionamento de GPU e perfis disponíveis, consulte. Usando partições de GPU na Amazon SageMaker HyperPod

  4. Execute o comando create-cluster da seguinte maneira:

    Importante

    Ao executar o comando create-cluster com o parâmetro --cli-input-json, você deve incluir o prefixo file:// antes do caminho completo para o arquivo JSON. Esse prefixo é necessário para garantir que o AWS CLI reconheça a entrada como um caminho de arquivo. A omissão do prefixo file:// resulta em um erro de parâmetro de análise.

    aws sagemaker create-cluster \ --cli-input-json file://complete/path/to/create_cluster.json

    Isso deve retornar o ARN do novo cluster.

    Importante

    Você pode usar a operação update-cluster para remover um grupo de instâncias restritas (RIG). Quando um RIG é reduzido para 0, o sistema de arquivos FSx for Lustre não será excluído. Para remover completamente o sistema de arquivos FSx for Lustre, você deve remover completamente o RIG.

    A remoção de um RIG não excluirá nenhum artefato armazenado no bucket do Amazon S3 gerenciado pelo serviço. No entanto, você deve garantir que todos os artefatos no sistema de arquivos do FSx Lustre estejam totalmente sincronizados com o Amazon S3 antes da remoção. Recomendamos esperar pelo menos 30 minutos após a conclusão do trabalho para garantir a sincronização completa de todos os artefatos do sistema de arquivos FSx for Lustre com o bucket Amazon S3 gerenciado pelo serviço.

    Importante

    Ao usar uma reserva de capacidade sob demanda (ODCR) integrada, você deve mapear seu grupo de instâncias para a mesma ID de zona de disponibilidade (ID AZ) da ODCR configurando OverrideVpcConfig com uma sub-rede na ID AZ correspondente.

    CRÍTICO: verifique a OverrideVpcConfig configuração antes da implantação para evitar cobranças duplicadas tanto para o ODCR quanto para a capacidade sob demanda.