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

Verificações de integridade profundas

SageMaker HyperPod realiza verificações detalhadas de integridade em instâncias de Slurm-orchestrated cluster para garantir a confiabilidade e a estabilidade do hardware e da infraestrutura subjacentes. As verificações de saúde detalhadas podem ser executadas automaticamente quando as instâncias são criadas ou adicionadas a um cluster (na inicialização), ou você pode acioná-las manualmente a qualquer momento (sob demanda) usando a StartClusterHealthCheckAPI. Essa abordagem proativa ajuda a identificar e mitigar possíveis problemas em todo o ciclo de vida do cluster.

Durante verificações de integridade detalhadas, os nós afetados são colocados em uma reserva de manutenção do Slurm para evitar que trabalhos sejam agendados neles. Depois que todas as verificações são aprovadas, os nós são liberados da reserva e ficam disponíveis para cargas de trabalho.

Tipos de verificação profunda de saúde

SageMaker HyperPod oferece suporte a duas categorias de verificações profundas de integridade para clusters do Slurm:

Lista de verificações de saúde detalhadas feitas por SageMaker HyperPod

SageMaker HyperPod executa as seguintes verificações de saúde detalhadas.

Instance-level verificações de saúde profundas (InstanceStress)

Cluster-level verificações de saúde profundas (InstanceConnectivity)

On-start verificações de saúde aprofundadas

On-start verificações profundas de integridade são executadas automaticamente quando as instâncias são provisionadas pela primeira vez — durante a criação do cluster ou quando novas instâncias são adicionadas via. UpdateCluster Isso garante que cada nó passe pela validação do hardware antes de aceitar cargas de trabalho.

Habilitando verificações de saúde detalhadas na inicialização

Para ativar verificações de saúde detalhadas na inicialização, especifique o OnStartDeepHealthChecks parâmetro na configuração do grupo de instâncias ao criar ou atualizar um cluster.

Exemplo: criar um cluster com verificações de saúde detalhadas no início

aws sagemaker create-cluster \
  --cluster-name my-slurm-cluster \
  --instance-groups '[
    {
      "InstanceGroupName": "controller-group",
      "InstanceType": "ml.m5.xlarge",
      "InstanceCount": 1,
      "LifeCycleConfig": {
        "SourceS3Uri": "s3://my-bucket/lifecycle-scripts/",
        "OnCreate": "on_create.sh"
      },
      "ExecutionRole": "arn:aws:iam::111122223333:role/my-role",
      "ThreadsPerCore": 1
    },
    {
      "InstanceGroupName": "worker-group",
      "InstanceType": "ml.p4d.24xlarge",
      "InstanceCount": 4,
      "LifeCycleConfig": {
        "SourceS3Uri": "s3://my-bucket/lifecycle-scripts/",
        "OnCreate": "on_create.sh"
      },
      "ExecutionRole": "arn:aws:iam::111122223333:role/my-role",
      "ThreadsPerCore": 1,
      "OnStartDeepHealthChecks": ["InstanceStress", "InstanceConnectivity"]
    }
  ]' \
  --vpc-config '{"SecurityGroupIds":["sg-12345678"],"Subnets":["subnet-12345678"]}'

O que acontece durante as verificações de saúde aprofundadas na inicialização

Quando as verificações profundas de integridade na inicialização estão habilitadas, ocorre o seguinte processo:

O cluster faz a transição para InService uma vez em que pelo menos o nó do controlador esteja em execução. Os nós de trabalho mostram DeepHealthCheckInProgress o status durante o teste e a transição para Running após a aprovação.

Monitorando verificações de saúde detalhadas no início

Você pode monitorar o status das verificações de saúde profundas no início usando a API Amazon SageMaker AI ou os comandos Slurm.

Verifique o status do nó usando o AWS Command Line Interface

aws sagemaker list-cluster-nodes \
  --cluster-name my-slurm-cluster

Os nós submetidos a verificações de integridade profundas são exibidos InstanceStatus.Status comoDeepHealthCheckInProgress.

Verifique o estado do Slurm via SSM no nó do controlador

# View node states
sinfo -a -N -l

# View maintenance reservation
scontrol show reservations

# View running DHC jobs
squeue -a

Os nós sob verificação profunda de integridade aparecem na hyperpod-deep-health-check reserva e na hyperpod-system-maintenance partição.

Adicionar nós a um cluster com verificações de saúde profundas na inicialização ativadas

Quando você expande um cluster OnStartDeepHealthChecks configurado, os novos nós passam automaticamente por verificações de integridade detalhadas antes de aceitar cargas de trabalho. Os nós existentes e os trabalhos em execução não são afetados.

aws sagemaker update-cluster \
  --cluster-name my-slurm-cluster \
  --instance-groups '[
    {
      "InstanceGroupName": "controller-group",
      "InstanceType": "ml.m5.xlarge",
      "InstanceCount": 1,
      "LifeCycleConfig": {
        "SourceS3Uri": "s3://my-bucket/lifecycle-scripts/",
        "OnCreate": "on_create.sh"
      },
      "ExecutionRole": "arn:aws:iam::111122223333:role/my-role",
      "ThreadsPerCore": 1
    },
    {
      "InstanceGroupName": "worker-group",
      "InstanceType": "ml.p4d.24xlarge",
      "InstanceCount": 8,
      "LifeCycleConfig": {
        "SourceS3Uri": "s3://my-bucket/lifecycle-scripts/",
        "OnCreate": "on_create.sh"
      },
      "ExecutionRole": "arn:aws:iam::111122223333:role/my-role",
      "ThreadsPerCore": 1,
      "OnStartDeepHealthChecks": ["InstanceStress", "InstanceConnectivity"]
    }
  ]'

Os novos nós são isolados na reserva de manutenção durante a execução de verificações detalhadas de integridade. Os trabalhos que exigem a capacidade adicional dos novos nós aguardam até que esses nós passem por verificações de integridade detalhadas e estejam disponíveis. Os trabalhos que podem ser satisfeitos pelos nós disponíveis existentes não são afetados.

On-demand verificações de saúde aprofundadas

On-demand verificações profundas de integridade permitem que você acione a validação de hardware nos nós de cluster existentes a qualquer momento usando a StartClusterHealthCheckAPI. Isso é útil para validação periódica de integridade ou após suspeitas de problemas de hardware.

Executando verificações de integridade detalhadas sob demanda a partir do console

Você pode executar verificações de saúde detalhadas em instâncias de HyperPod cluster diretamente do console de SageMaker IA.

Um banner de sucesso confirma que as verificações foram iniciadas. As instâncias não estão disponíveis para cargas de trabalho durante as verificações, que podem levar mais de uma hora. Monitore o status da instância na tabela Instâncias — ela mostra uma verificação profunda de integridade em andamento durante a execução. Quando problemas são encontrados e a recuperação automática é ativada, reinicializa ou substitui SageMaker HyperPod automaticamente as instâncias com defeito.

Acionando verificações de saúde profundas sob demanda usando o AWS Command Line Interface

Você pode especificar quais grupos de instâncias e quais verificações executar. Somente uma solicitação de verificação profunda de integridade sob demanda pode estar ativa por cluster por vez.

aws sagemaker start-cluster-health-check \
  --cluster-name my-slurm-cluster \
  --deep-health-check-configurations '[
    {
      "InstanceGroupName": "worker-group",
      "DeepHealthChecks": ["InstanceStress", "InstanceConnectivity"]
    }
  ]'

Comportamento com cargas de trabalho em execução

Quando verificações de integridade profundas sob demanda são acionadas em nós que estão executando trabalhos:

Logs das verificações de integridade profundas

Veja a seguir exemplos de registros das verificações de saúde SageMaker HyperPod detalhadas.

Cluster-level logs

Os registros de verificação profunda de integridade em nível de cluster são armazenados em seu CloudWatch grupo de registros em. /aws/sagemaker/Clusters/<cluster_name>/<cluster_id>

Os fluxos de log estão registrados em DeepHealthCheckResults/<log_stream_id>.

Instance-level logs

Em cada nó, registros de verificação profunda de integridade são armazenados em/var/log/aws/clusters/sagemaker-deep-health-check.log.

Você pode acessar o registro via SSM:

aws ssm start-session \
  --target "sagemaker-cluster:<cluster_id>_<instance_group>-<instance_id>"

Em seguida, veja o registro:

cat /var/log/aws/clusters/sagemaker-deep-health-check.log

Exemplo de saída HARDWARE_CHECK

2026-03-29T18:03:14Z  info  Executing Hardware stress check with command: stress-ng
2026-03-29T18:04:20Z  info  stress-ng success
2026-03-29T18:04:20Z  info  GpuPci Count check success

Exemplo de saída DCGM

2026-03-29T18:35:02Z  info  DCGM diagnostic health summary: dcgmCheckLevel: 4
  dcgmVersion: 3.3.7 gpuDriverVersion: 535.183.01
  gpuDeviceIds: [2237] replacementRequired: false rebootRequired: false

Exemplo de saída EFA

2026-03-29T18:36:28Z  info  EFA Loopback check passed for device: rdmap0s29
  MaxBw: 58.59, AvgBw: 32.42, MaxTypicalLat: 30.87, AvgLat: 21.63

Exemplo de saída de falha de verificação profunda de integridade

{
    "level": "error",
    "ts": "2026-03-29T19:15:22Z",
    "msg": "Encountered FaultyInstance. Replace the Instance. Region: us-west-2, InstanceType: ml.g5.8xlarge. ERROR: Bandwidth has less than threshold: Expected minimum threshold: 80, NCCL Test output Bw: 30"
}

Auto-resume comportamento com verificações de saúde aprofundadas

Sem a ativação de verificações de integridade aprofundadas, quando um nó é substituído durante a retomada automática, o nó substituto é imediatamente adicionado ao cluster e o trabalho retomado automaticamente pode ser agendado nele imediatamente.

Com as verificações de saúde profundas ativadas, o nó substituto deve passar por todas as verificações de saúde profundas configuradas antes de ficar disponível. No entanto, o trabalho retomado automaticamente não precisa esperar pelo nó de substituição — ele pode ser agendado em qualquer outro nó disponível no cluster. O trabalho só espera se nenhum outro nó estiver disponível.

Considerações adicionais