Usando o operador de treinamento para executar trabalhos

Para usar o kubectl para executar o trabalho, você precisa criar um job.yaml para especificar as especificações do trabalho e executar kubectl apply -f job.yaml para enviar o trabalho. Nesse arquivo YAML, você pode especificar configurações personalizadas no logMonitoringConfiguration argumento para definir regras de monitoramento automatizadas que analisam as saídas de log do trabalho de treinamento distribuído para detectar problemas e se recuperar.

apiVersion: sagemaker.amazonaws.com/v1
kind: HyperPodPyTorchJob
metadata:
  labels:
    app.kubernetes.io/name: HyperPod
    app.kubernetes.io/managed-by: kustomize
  name: &jobname xxx
  annotations:
    XXX: XXX
    ......
spec:
  nprocPerNode: "X"
  replicaSpecs:
    - name: 'XXX'
      replicas: 16
      template:
        spec:
          nodeSelector:
            beta.kubernetes.io/instance-type: ml.p5.48xlarge
          containers:
            - name: XXX
              image: XXX
              imagePullPolicy: Always
              ports:
                - containerPort: 8080 # This is the port that HyperPodElasticAgent listens to
              resources:
                limits:
                  nvidia.com/gpu: 8
                  hugepages-2Mi: 5120Mi
                requests:
                  nvidia.com/gpu: 8
                  hugepages-2Mi: 5120Mi
                  memory: 32000Mi
          ......        
  runPolicy:
    jobMaxRetryCount: 50
    restartPolicy:
      numRestartBeforeFullJobRestart: 3 
      evalPeriodSeconds: 21600 
      maxFullJobRestarts: 1
    cleanPodPolicy: "All"
    logMonitoringConfiguration: 
      - name: "JobStart"
        logPattern: ".*Experiment configuration.*" # This is the start of the training script
        expectedStartCutOffInSeconds: 120 # Expected match in the first 2 minutes
      - name: "JobHangingDetection"
        logPattern: ".*\\[Epoch 0 Batch \\d+.*'training_loss_step': (\\d+(\\.\\d+)?).*"
        expectedRecurringFrequencyInSeconds: 300 # If next batch is not printed within 5 minute, consider it hangs. Or if loss is not decimal (e.g. nan) for 2 minutes, mark it hang as well.
        expectedStartCutOffInSeconds: 600 # Allow 10 minutes of job startup time
      - name: "NoS3CheckpointingDetection"
        logPattern: ".*The checkpoint is finalized. All shards is written.*"
        expectedRecurringFrequencyInSeconds: 600 # If next checkpoint s3 upload doesn't happen within 10 mins, mark it hang.
        expectedStartCutOffInSeconds: 1800 # Allow 30 minutes for first checkpoint upload
      - name: "LowThroughputDetection"
        logPattern: ".*\\[Epoch 0 Batch \\d+.*'samples\\/sec': (\\d+(\\.\\d+)?).*"
        metricThreshold: 80 # 80 samples/sec
        operator: "lteq"
        metricEvaluationDataPoints: 25 # if throughput lower than threshold for 25 datapoints, kill the job
      

Se você quiser usar as opções de monitoramento de registros, certifique-se de emitir o registro de treinamento para o. sys.stdout HyperPod O agente elástico monitora os registros de treinamento em sys.stdout, que são salvos em. /tmp/hyperpod/ Você pode usar o comando a seguir para emitir registros de treinamento.

logging.basicConfig(format="%(asctime)s [%(levelname)s] %(name)s: %(message)s", level=logging.INFO, stream=sys.stdout)

A tabela a seguir descreve todas as configurações possíveis de monitoramento de registros:

Parameter	Uso
jobMaxRetryContagem	Número máximo de reinicializações no nível do processo.
Política de reinicialização: numRestartBefore FullJobRestart	Número máximo de reinicializações no nível do processo antes que o operador reinicie no nível do trabalho.
Política de reinicialização: evalPeriodSeconds	O período de avaliação do limite de reinicialização em segundos
Política de reinicialização: reinicia maxFullJob	Número máximo de reinicializações completas do trabalho antes que o trabalho falhe.
cleanPodPolicy	Especifica os pods que o operador deve limpar. Os valores aceitos são AllOnlyComplete, None e.
logMonitoringConfiguration	As regras de monitoramento de registros para detecção de trabalhos lentos e interrompidos
expectedRecurringFrequencyInSeconds	Intervalo de tempo entre duas LogPattern partidas consecutivas após o qual a regra é avaliada como HANGING. Se não for especificado, não existe restrição de tempo entre LogPattern partidas consecutivas.
expectedStartCutOffInSeconds	Hora da primeira LogPattern partida, após a qual a regra é avaliada como HANGING. Se não for especificado, não existe restrição de tempo para a primeira LogPattern partida.
Padrão de registro	Expressão regular que identifica as linhas de registro às quais a regra se aplica quando a regra está ativa
metricEvaluationDataPontos	Número de vezes consecutivas que uma regra deve ser avaliada como LENTA antes de marcar uma tarefa como LENTA. Se não especificado, o padrão será 1.
Limite métrico	Limite para o valor extraído LogPattern com um grupo de captura. Se não for especificada, a avaliação métrica não será executada.
operador	A desigualdade a ser aplicada à configuração de monitoramento. Os valores aceitos são gt gteqlt,lteq,, eq e.
Padrão de parada	Expressão regular para identificar a linha de registro na qual desativar a regra. Se não for especificada, a regra estará sempre ativa.

Para obter mais resiliência de treinamento, especifique os detalhes da configuração do nó de reposição. Se seu trabalho falhar, o operador trabalha com o Kueue para usar nós reservados com antecedência para continuar executando o trabalho. As configurações de nós sobressalentes exigem o Kueue, portanto, se você tentar enviar um trabalho com nós sobressalentes, mas não tiver o Kueue instalado, o trabalho falhará. O exemplo a seguir é um job.yaml arquivo de amostra que contém configurações de nós sobressalentes.

apiVersion: sagemaker.amazonaws.com/v1
kind: HyperPodPyTorchJob
metadata:
  labels:
    kueue.x-k8s.io/queue-name: user-queue # Specify the queue to run the job.
  name: hyperpodpytorchjob-sample
spec:
  nprocPerNode: "1"
  runPolicy:
    cleanPodPolicy: "None"
  replicaSpecs: 
    - name: pods
      replicas: 1
      spares: 1 # Specify how many spare nodes to reserve.
      template:
        spec:
          containers:
            - name: XXX
              image: XXX
              
              imagePullPolicy: Always
              ports:
                - containerPort: 8080
              resources:
                requests:
                  nvidia.com/gpu: "0"
                limits:
                  nvidia.com/gpu: "0"
      

Monitoramento

A Amazon SageMaker HyperPod está integrada à observabilidade com o Amazon Managed Grafana e o Amazon Managed Service for Prometheus, para que você possa configurar o monitoramento para coletar e alimentar métricas nessas ferramentas de observabilidade.

Como alternativa, você pode coletar métricas por meio do Amazon Managed Service for Prometheus sem a observabilidade gerenciada. Para fazer isso, inclua as métricas que você deseja monitorar em seu job.yaml arquivo ao executar trabalhos comkubectl.

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: hyperpod-training-operator
  namespace: aws-hyperpod
spec:
  ......
  endpoints:
    - port: 8081
      path: /metrics
      interval: 15s

A seguir estão os eventos que o operador de treinamento emite e que você pode inserir no Amazon Managed Service for Prometheus para monitorar seus trabalhos de treinamento.

Event	Descrição
hyperpod_training_operator_jobs_created_total	Número total de trabalhos que o operador de treinamento executou
hyperpod_training_operator_jobs_restart_latency	Latência atual de reinicialização do trabalho
hyperpod_training_operator_jobs_fault_detection_latency	Latência de detecção de falhas
hyperpod_training_operator_jobs_deleted_total	Número total de trabalhos excluídos
hyperpod_training_operator_jobs_successful_total	Número total de trabalhos concluídos
hyperpod_training_operator_jobs_failed_total	Número total de trabalhos com falha
hyperpod_training_operator_jobs_restarted_total	Número total de trabalhos reiniciados automaticamente

Exemplo de configuração do docker

Veja a seguir um exemplo de arquivo docker que você pode executar com o hyperpod run comando.

export AGENT_CMD="--backend=nccl"
exec hyperpodrun --server-host=${AGENT_HOST} --server-port=${AGENT_PORT} \
    --tee=3 --log_dir=/tmp/hyperpod \
    --nnodes=${NNODES} --nproc-per-node=${NPROC_PER_NODE} \
    --pre-train-script=/workspace/echo.sh --pre-train-args='Pre-training script' \
    --post-train-script=/workspace/echo.sh --post-train-args='Post-training script' \
    /workspace/mnist.py --epochs=1000 ${AGENT_CMD}

Exemplos de configurações de monitoramento de registros

Detecção de interrupções de trabalho

Para detectar trabalhos suspensos, use as configurações a seguir. Ele usa os seguintes parâmetros:

• expectedStartCutOffInSeconds — quanto tempo o monitor deve esperar antes de esperar os primeiros registros

• expectedRecurringFrequencyInSeconds — o intervalo de tempo de espera pelo próximo lote de registros

Com essas configurações, o monitor de registro espera ver uma linha de registro correspondente ao padrão regex .*Train Epoch.* dentro de 60 segundos após o início do trabalho de treinamento. Após a primeira aparição, o monitor espera ver linhas de registro correspondentes a cada 10 segundos. Se os primeiros registros não aparecerem em 60 segundos ou os registros subsequentes não aparecerem a cada 10 segundos, o agente HyperPod elástico tratará o contêiner como preso e coordenará com o operador de treinamento a reinicialização do trabalho.

runPolicy:
    jobMaxRetryCount: 10
    cleanPodPolicy: "None"
    logMonitoringConfiguration:
      - name: "JobStartGracePeriod"
        # Sample log line: [default0]:2025-06-17 05:51:29,300 [INFO] __main__: Train Epoch: 5 [0/60000 (0%)]       loss=0.8470
        logPattern: ".*Train Epoch.*"  
        expectedStartCutOffInSeconds: 60 
      - name: "JobHangingDetection"
        logPattern: ".*Train Epoch.*"
        expectedRecurringFrequencyInSeconds: 10 # if the next batch is not printed within 10 seconds

Aumento da perda de treinamento

A configuração de monitoramento a seguir emite registros de treinamento com o padrãoxxx training_loss_step xx. Ele usa o parâmetrometricEvaluationDataPoints, que permite especificar um limite de pontos de dados antes que o operador reinicie o trabalho. Se o valor da perda de treinamento for maior que 2,0, o operador reinicia o trabalho.

runPolicy:
  jobMaxRetryCount: 10
  cleanPodPolicy: "None"
  logMonitoringConfiguration:
    - name: "LossSpikeDetection"
      logPattern: ".*training_loss_step (\\d+(?:\\.\\d+)?).*"   # training_loss_step 5.0
      metricThreshold: 2.0
      operator: "gt"
      metricEvaluationDataPoints: 5 # if loss higher than threshold for 5 data points, restart the job

TFLOPs Detecção baixa

A configuração de monitoramento a seguir emite registros de treinamento com o padrão a xx TFLOPs xx cada cinco segundos. Se TFLOPs for menor que 100 para 5 pontos de dados, o operador reinicia o trabalho de treinamento.

runPolicy:
  jobMaxRetryCount: 10
  cleanPodPolicy: "None"
  logMonitoringConfiguration:
    - name: "TFLOPs"
      logPattern: ".* (.+)TFLOPs.*"    # Training model, speed: X TFLOPs...
      expectedRecurringFrequencyInSeconds: 5        
      metricThreshold: 100       # if Tflops is less than 100 for 5 data points, restart the job       
      operator: "lt"
      metricEvaluationDataPoints: 5