Uso del operador de entrenamiento para ejecutar trabajos

Para usar kubectl para ejecutar el trabajo, debes crear un job.yaml para especificar las especificaciones del trabajo y ejecutar para enviarlo. kubectl apply -f job.yaml En este archivo YAML, puedes especificar configuraciones personalizadas en el logMonitoringConfiguration argumento para definir reglas de supervisión automatizadas que analicen los resultados del registro del trabajo de entrenamiento distribuido para detectar problemas y recuperarlos.

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
      

Si quieres usar las opciones de monitoreo de registros, asegúrate de enviar el registro de entrenamiento a. sys.stdout HyperPod El agente elástico supervisa los registros de entrenamiento en sys.stdout, que se guardan en. /tmp/hyperpod/ Puede usar el siguiente comando para emitir registros de entrenamiento.

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

En la siguiente tabla se describen todas las configuraciones posibles de supervisión de registros:

Parámetro	Uso
jobMaxRetryRecuento	Número máximo de reinicios a nivel de proceso.
Política de reinicio: numRestartBefore FullJobRestart	Número máximo de reinicios a nivel de proceso antes de que el operador reinicie a nivel de trabajo.
Política de reinicio: evalPeriodSeconds	El período de evaluación del límite de reinicio en segundos
Política de reinicio: se reinicia maxFullJob	El número máximo de tareas completas se reiniciarán antes de que se produzca un error en la tarea.
cleanPodPolicy	Especifica las cápsulas que el operador debe limpiar. Los valores aceptados son AllOnlyComplete, yNone.
logMonitoringConfiguration	Las reglas de monitoreo de registros para la detección de trabajos lentos y pendientes
expectedRecurringFrequencyInSeconds	Intervalo de tiempo entre dos LogPattern partidos consecutivos tras el cual la regla se evalúa como pendiente. Si no se especifica, no existe ninguna restricción de tiempo entre partidos consecutivos LogPattern .
expectedStartCutOffInSeconds	Tiempo hasta la primera LogPattern coincidencia, después de lo cual la regla se evalúa como pendiente. Si no se especifica, no existe ninguna restricción de tiempo para la primera LogPattern coincidencia.
LogPattern	Expresión regular que identifica las líneas de registro a las que se aplica la regla cuando la regla está activa
metricEvaluationDataPuntos	Número de veces consecutivas que una regla debe evaluarse como LENTO antes de marcar un trabajo como LENTO. Si no se especifica, el valor predeterminado es 1.
Umbral métrico	Umbral para el valor extraído LogPattern con un grupo de captura. Si no se especifica, no se realiza una evaluación métrica.
operador	La desigualdad que se debe aplicar a la configuración de supervisión. Los valores aceptados son gt gteqlt,lteq, yeq.
StopPattern	Expresión regular para identificar la línea de registro en la que se va a desactivar la regla. Si no se especifica, la regla siempre estará activa.

Para una mayor flexibilidad de entrenamiento, especifique los detalles de configuración del nodo de repuesto. Si tu trabajo no funciona, el operador trabaja con Kueue para usar los nodos reservados con antelación para seguir ejecutando el trabajo. Las configuraciones de nodos de repuesto requieren Kueue, por lo que si intentas enviar un trabajo con nodos de repuesto pero no tienes Kueue instalado, el trabajo fallará. El siguiente ejemplo es un job.yaml archivo de muestra que contiene configuraciones de nodos de repuesto.

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"
      

Monitorización

Amazon SageMaker HyperPod integra la observabilidad con Amazon Managed Grafana y Amazon Managed Service for Prometheus, por lo que puedes configurar la monitorización para recopilar e introducir métricas en estas herramientas de observabilidad.

Como alternativa, puedes recopilar las métricas a través de Amazon Managed Service for Prometheus sin observabilidad gestionada. Para ello, incluye en tu job.yaml archivo las métricas que quieres monitorizar cuando ejecutes trabajos. kubectl

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

Los siguientes son eventos que emite el operador de formación y que puedes incluir en Amazon Managed Service for Prometheus para supervisar tus trabajos de formación.

Evento	Descripción
hyperpod_training_operator_jobs_created_total	Número total de trabajos que ha realizado el operador de formación
hyperpod_training_operator_jobs_restart_latency	Latencia de reinicio del trabajo actual
hyperpod_training_operator_jobs_fault_detection_latency	Latencia de detección de fallos
hyperpod_training_operator_jobs_deleted_total	Número total de trabajos eliminados
hyperpod_training_operator_jobs_successful_total	Número total de trabajos finalizados
hyperpod_training_operator_jobs_failed_total	Número total de trabajos fallidos
hyperpod_training_operator_jobs_restarted_total	Número total de trabajos reiniciados automáticamente

Ejemplo de configuración de docker

El siguiente es un ejemplo de un archivo docker que puede ejecutar con el 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}

Ejemplos de configuraciones de monitoreo de registros

Detección de problemas en el trabajo

Para detectar los trabajos bloqueados, utilice las siguientes configuraciones. Utiliza los siguientes parámetros:

• expectedStartCutOffInSeconds — cuánto tiempo debe esperar el monitor antes de esperar los primeros registros

• expectedRecurringFrequencyInSeconds — el intervalo de tiempo necesario para esperar al siguiente lote de registros

Con esta configuración, el monitor de registros espera ver una línea de registro que coincida con el patrón de expresiones regulares .*Train Epoch.* dentro de los 60 segundos posteriores al inicio del trabajo de formación. Tras la primera aparición, el monitor espera ver líneas de registro coincidentes cada 10 segundos. Si los primeros registros no aparecen en 60 segundos o los registros siguientes no aparecen cada 10 segundos, el agente HyperPod elástico considera que el contenedor está atascado y coordina con el operador que está entrenando para reiniciar el trabajo.

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 de la pérdida de formación

La siguiente configuración de supervisión emite registros de entrenamiento con el patrón. xxx training_loss_step xx Utiliza el parámetrometricEvaluationDataPoints, que permite especificar un umbral de puntos de datos antes de que el operador reinicie el trabajo. Si el valor de la pérdida de entrenamiento es superior a 2,0, el operador reinicia el trabajo.

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

Detección baja TFLOPs

La siguiente configuración de supervisión emite registros de entrenamiento con el patrón xx TFLOPs xx cada cinco segundos. Si TFLOPs es inferior a 100 para 5 puntos de datos, el operador reinicia el trabajo de entrenamiento.

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