Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Utilizzo dell’operatore di addestramento per eseguire i processi

Per eseguire i processi con kubectl, devi creare un file job.yaml con le specifiche del processo ed eseguire kubectl apply -f job.yaml per inviare il processo. In questo file YAML, puoi specificare configurazioni personalizzate nell’argomento logMonitoringConfiguration per definire le regole di monitoraggio automatizzato che analizzano gli output dei log dei job di addestramento distribuito per rilevare problemi ed eseguire il ripristino.

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 desideri utilizzare le opzioni di monitoraggio dei log, assicurati di inviare il registro di allenamento a. sys.stdout HyperPod elastic agent monitora i registri di allenamento in sys.stdout, che vengono salvati in. /tmp/hyperpod/ Per emettere i log di addestramento, puoi utilizzare il comando seguente.

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

Nella tabella seguente sono descritte tutte le possibili configurazioni di monitoraggio dei log:

Per una maggiore resilienza dell’addestramento, specifica i dettagli di configurazione dei nodi di riserva. Se il processo non riesce, l’operatore ricorre a Kueue per utilizzare i nodi riservati in anticipo per continuare a eseguire il processo. Le configurazioni dei nodi di riserva richiedono Kueue. Di conseguenza, se provi a inviare un processo con nodi di riserva ma Kueue non è installato, il processo non riuscirà. L’esempio seguente è un file job.yaml di esempio che contiene le configurazioni dei nodi di riserva.

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"
      

Monitoraggio

Amazon SageMaker HyperPod è integrato con l'osservabilità con Amazon Managed Grafana e Amazon Managed Service for Prometheus, quindi puoi configurare il monitoraggio per raccogliere e inserire le metriche in questi strumenti di osservabilità.

In alternativa, puoi acquisire le metriche tramite Servizio gestito da Amazon per Prometheus senza la funzionalità di osservabilità gestita. A tale scopo, includi nel file job.yaml le metriche da monitorare quando esegui i processi 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

Di seguito sono riportati gli eventi emessi dall’operatore di addestramento che puoi inserire in Servizio gestito da Amazon per Prometheus per monitorare i job di addestramento.

Configurazione Docker di esempio

Di seguito è riportato un file Docker di esempio che puoi eseguire con il 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}

Configurazioni di esempio per il monitoraggio dei log

Rilevamento di processi bloccati

Per rilevare i processi bloccati, utilizza le configurazioni seguenti con questi parametri:

Con queste impostazioni, il monitoraggio dei log prevede di visualizzare una riga del log corrispondente al modello regex .*Train Epoch.* entro 60 secondi dall’inizio del job di addestramento. Dopo la prima occorrenza, il monitoraggio prevede di rilevare righe del log corrispondenti ogni 10 secondi. Se i primi log non vengono visualizzati entro 60 secondi o i log successivi non vengono visualizzati ogni 10 secondi, l'agente HyperPod elastico considera il contenitore come bloccato e si coordina con l'operatore addetto alla formazione per riavviare il lavoro.

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

Picco di perdita dell’addestramento

La configurazione del monitoraggio seguente emette log di addestramento con il modello xxx training_loss_step xx. Utilizza il parametro metricEvaluationDataPoints, che consente di specificare una soglia di punti dati prima che l’operatore riavvii il processo. Se il valore di perdita dell’addestramento è superiore a 2,0, l’operatore riavvia il processo.

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

Rilevamento di TFLOP bassi

La configurazione del monitoraggio seguente emette log di addestramento con il modello xx TFLOPs xx ogni cinque secondi. Se TFLOP è inferiore a 100 per 5 punti dati, l’operatore riavvia il job di addestramento.

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

Rilevamento del registro degli errori dello script di formazione

La seguente configurazione di monitoraggio rileva se il modello specificato in logPattern è presente nei registri di addestramento. Non appena l'operatore addetto alla formazione rileva il modello di errore, lo considera un errore e riavvia il lavoro.

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