Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Uso del operador de entrenamiento para ejecutar trabajos

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

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)

La tabla siguiente describe todas las configuraciones de supervisión de registros posibles:

Para una mayor resiliencia del entrenamiento, especifique los detalles de configuración del nodo de repuesto. Si su 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 intenta enviar un trabajo con nodos de repuesto pero no tiene Kueue instalado, el trabajo fallará. El siguiente ejemplo es un archivo job.yaml 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"
      

Supervisió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, puede recopilar las métricas a través de Amazon Managed Service para Prometheus sin observabilidad administrada. Para ello, incluya las métricas que quiere supervisar en su archivo job.yaml cuando ejecute tareas con 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 entrenamiento y que puede incluir en Amazon Managed Service para Prometheus para supervisar los trabajos de entrenamiento.

Configuración del docker de ejemplo

A continuación se muestra un ejemplo de un archivo docker que puede ejecutar con el comando hyperpod run.

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 supervisión de registros

Detección de trabajos pendientes

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

Con esta configuración, el monitor de registros espera ver una línea de registro que coincida con el patrón .*Train Epoch.* de expresiones regulares dentro de los 60 segundos posteriores al inicio del trabajo de entrenamiento. 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

Pico de pérdida de entrenamiento

La siguiente configuración de supervisión emite registros de entrenamiento con el patrón xxx training_loss_step xx. Utiliza el parámetro metricEvaluationDataPoints, que le 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

Baja TFLOPs detección

La siguiente configuración de supervisión emite registros de entrenamiento con el patrón xx TFLOPs xx cada 5 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

Detección del registro de errores en el script de entrenamiento

La siguiente configuración de supervisión detecta si el patrón especificado en logPattern está presente en los registros de entrenamiento. En cuanto el operador de formación detecta el patrón de error, lo considera un error y reinicia el trabajo.

runPolicy:
  jobMaxRetryCount: 10
  cleanPodPolicy: "None"
  logMonitoringConfiguration:
    - name: "GPU Error"
      logPattern: ".*RuntimeError.*out of memory.*"
      faultOnMatch: true