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

Provisionamento contínuo para operações de cluster aprimoradas com o Slurm

SageMaker HyperPod Os clusters da Amazon criados com a orquestração do Slurm agora oferecem suporte ao provisionamento contínuo, um recurso que permite maior flexibilidade e eficiência ao executar cargas de trabalho em grande escala. AI/ML O provisionamento contínuo permite que você comece a treinar rapidamente, escale sem problemas, realize a manutenção sem interromper as operações e tenha visibilidade granular das operações do cluster.

Como funciona

O sistema de provisionamento contínuo introduz uma arquitetura de estado desejado que substitui o modelo tradicional de escalabilidade de tudo ou nada. No modelo anterior, se algum grupo de instâncias não pudesse ser totalmente provisionado, toda a operação de criação ou atualização do cluster falhava e era revertida. Com o provisionamento contínuo, o sistema aceita capacidade parcial e continua a provisionar as instâncias restantes de forma assíncrona.

O sistema de provisionamento contínuo:

O provisionamento contínuo está desabilitado por padrão. Para usar esse recurso, NodeProvisioningMode defina como Continuous em sua CreateCluster solicitação.

Com o provisionamento contínuo habilitado, você pode iniciar várias operações de ajuste de escala simultaneamente, sem precisar esperar a conclusão das operações anteriores. Isso permite escalar diferentes grupos de instâncias no mesmo cluster simultaneamente e enviar várias solicitações de ajuste de escala ao mesmo grupo de instâncias.

Priority-based provisionamento

Os clusters do Slurm exigem que um nó controlador esteja operacional antes que os nós de trabalho possam registrar e aceitar trabalhos. O provisionamento contínuo lida com isso automaticamente por meio do provisionamento baseado em prioridades:

Tratamento de falhas no controlador

Durante a criação do cluster, se o nó do controlador falhar no provisionamento, o comportamento depende se o erro pode ser repetido ou não.

Erros que podem ser repetidos (por exemplo, instâncias não íntegras ou falhas transitórias):

Non-retryable erros (por exemplo, nenhuma capacidade disponível para o tipo de instância do controlador ou falha no script do ciclo de vida):

Pré-requisitos

O provisionamento contínuo exige que os parâmetros de provisionamento do Slurm (tipos de nós, nomes de partições) sejam fornecidos por meio da carga útil da API no campo de cada grupo de instâncias. SlurmConfig Os clusters que dependem do provisioning_parameters.json arquivo legado no Amazon S3 não são compatíveis com o provisionamento contínuo.

Medição do uso

HyperPod clusters com provisionamento contínuo usam a medição em nível de instância para fornecer um faturamento preciso que reflita o uso real dos recursos. Essa abordagem de medição difere do faturamento tradicional em nível de cluster, pois rastreia cada instância de forma independente.

Instance-level faturamento

Com o provisionamento contínuo, o faturamento começa e termina em nível de instância, em vez de esperar por mudanças de estado em nível de cluster. Isso oferece os seguintes benefícios:

Ciclo de vida do faturamento

Cada instância em seu HyperPod cluster segue esse ciclo de vida de faturamento:

Criar um cluster com o provisionamento contínuo habilitado

Prepare um arquivo de solicitação de CreateCluster API no formato JSON. Configure NodeProvisioningMode Continuous e forneça informações de topologia do Slurm no campo de cada grupo de instâncias. SlurmConfig

// create_cluster.json
{
    "ClusterName": "my-training-cluster",
    "NodeProvisioningMode": "Continuous",
    "Orchestrator": {
        "Slurm": {}
    },
    "InstanceGroups": [
        {
            "InstanceGroupName": "controller-group",
            "InstanceType": "ml.m5.xlarge",
            "InstanceCount": 1,
            "LifeCycleConfig": {
                "SourceS3Uri": "s3://amzn-s3-demo-bucket/lifecycle-scripts/src/",
                "OnCreate": "on_create.sh"
            },
            "ExecutionRole": "arn:aws:iam::111122223333:role/iam-role-for-cluster",
            "SlurmConfig": {
                "NodeType": "Controller"
            }
        },
        {
            "InstanceGroupName": "login-group",
            "InstanceType": "ml.m5.xlarge",
            "InstanceCount": 1,
            "LifeCycleConfig": {
                "SourceS3Uri": "s3://amzn-s3-demo-bucket/lifecycle-scripts/src/",
                "OnCreate": "on_create.sh"
            },
            "ExecutionRole": "arn:aws:iam::111122223333:role/iam-role-for-cluster",
            "SlurmConfig": {
                "NodeType": "Login"
            }
        },
        {
            "InstanceGroupName": "worker-gpu-a",
            "InstanceType": "ml.p5.48xlarge",
            "InstanceCount": 16,
            "LifeCycleConfig": {
                "SourceS3Uri": "s3://amzn-s3-demo-bucket/lifecycle-scripts/src/",
                "OnCreate": "on_create.sh"
            },
            "ExecutionRole": "arn:aws:iam::111122223333:role/iam-role-for-cluster",
            "SlurmConfig": {
                "NodeType": "Compute",
                "PartitionNames": ["gpu-training"]
            }
        }
    ],
    "VpcConfig": {
        "SecurityGroupIds": ["sg-12345678"],
        "Subnets": ["subnet-12345678"]
    }
}

Execute o create-cluster comando para enviar a solicitação.

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

Isso retorna o ARN do novo cluster.

{
    "ClusterArn": "arn:aws:sagemaker:us-west-2:111122223333:cluster/abcde12345"
}

Gerenciamento de configuração do Slurm

O provisionamento contínuo opera exclusivamente no modo de mesclagem para slurm.conf gerenciamento de partições. No modo de mesclagem, HyperPod aplica suas alterações de configuração de partição de forma aditiva sobre o que você modificou. slurm.conf HyperPod atualiza somente as seções relacionadas à partição slurm.conf (como entradas de nome da partição e nome do nó); outros parâmetros de configuração do Slurm não são modificados. Isso significa que:

O SlurmConfigStrategy parâmetro (Managed,Merge,Overwrite) não é compatível com o provisionamento contínuo. A transmissão de qualquer SlurmConfigStrategy valor resulta em um erro de API.

Requisitos mínimos de capacidade (MinCount)

O MinCount recurso permite que você especifique o número mínimo de instâncias que devem ser provisionadas com sucesso antes que um grupo de instâncias faça a transição para o status. InService Esse recurso fornece melhor controle sobre as operações de escalabilidade e ajuda a evitar cenários em que grupos de instâncias parcialmente provisionados não possam ser usados de forma eficaz para treinar cargas de trabalho.

Como MinCount funciona

Quando você cria ou atualiza um grupo de instâncias com MinCount enabled, ocorre o seguinte comportamento:

Status do grupo de instâncias durante MinCount as operações

Grupos de instâncias com MinCount configurado apresentam o seguinte comportamento de status:

Durante Creating nosso Updating status, as seguintes restrições se aplicam:

Comportamento de reversão automática

Se um grupo de instâncias não conseguir alcançá-lo MinCount em 3 horas, o sistema iniciará automaticamente uma reversão para evitar a espera indefinida:

O tempo limite de 3 horas é redefinido sempre MinCount que é atualizado. Por exemplo, se você atualizar MinCount várias vezes, o período de tempo limite começa novamente a partir da atualização mais recente.

MinCount eventos

O sistema emite eventos específicos para ajudar você a monitorar MinCount as operações:

Você pode monitorar esses eventos usando ListClusterEventspara acompanhar o progresso de suas MinCount operações.

Uso da API

MinCount é especificado usando o MinInstanceCount parâmetro nas configurações do grupo de instâncias:

aws sagemaker create-cluster \
--cluster-name $HP_CLUSTER_NAME \
--instance-groups '[
    {
      "InstanceGroupName": "controller-machine",
      "InstanceType": "ml.c5.xlarge",
      "InstanceCount": 1,
      "SlurmConfig": {"NodeType": "Controller"},
      "LifeCycleConfig": {
        "SourceS3Uri": "s3://'$BUCKET_NAME'",
        "OnCreate": "on_create.sh"
      },
      "ExecutionRole": "'$EXECUTION_ROLE'",
      "ThreadsPerCore": 2
    },
    {
      "InstanceGroupName": "my-login-group",
      "InstanceType": "ml.c5.xlarge",
      "InstanceCount": 1,
      "SlurmConfig": {"NodeType": "Login"},
      "LifeCycleConfig": {
        "SourceS3Uri": "s3://'$BUCKET_NAME'",
        "OnCreate": "on_create.sh"
      },
      "ExecutionRole": "'$EXECUTION_ROLE'",
      "ThreadsPerCore": 1
    },
    {
      "InstanceGroupName": "worker-group-1",
      "InstanceType": "ml.c5.xlarge",
      "MinInstanceCount": 1,
      "InstanceCount": 2,
      "SlurmConfig": {
        "NodeType": "Compute",
        "PartitionNames": ["p1"]
      },
      "LifeCycleConfig": {
        "SourceS3Uri": "s3://'$BUCKET_NAME'",
        "OnCreate": "on_create.sh"
      },
      "ExecutionRole": "'$EXECUTION_ROLE'",
      "ThreadsPerCore": 1
    }
  ]' \
  --vpc-config '{
    "SecurityGroupIds": ["'$SECURITY_GROUP'"],
    "Subnets": ["'$SUBNET'"]
  }' \
  --node-provisioning-mode Continuous

Principais considerações sobre o MinCount uso: