Utilizzo dell'operatore di formazione per eseguire i lavori

Per usare kubectl per eseguire il lavoro, devi creare un job.yaml per specificare le specifiche del lavoro ed eseguirlo per inviare il lavoro. kubectl apply -f job.yaml In questo file YAML, puoi specificare configurazioni personalizzate nell'logMonitoringConfigurationargomento per definire regole di monitoraggio automatizzato che analizzano gli output di log del processo di formazione distribuito per rilevare problemi e ripristinare.

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 del registro, assicurati di inviare il registro di allenamento a. sys.stdout HyperPod elastic agent monitora i log di allenamento in sys.stdout, che viene salvato in. /tmp/hyperpod/ È possibile utilizzare il seguente comando per emettere i registri di allenamento.

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

La tabella seguente descrive tutte le possibili configurazioni di monitoraggio dei registri:

Parametro	Utilizzo
jobMaxRetryConta	Numero massimo di riavvii a livello di processo.
Politica di riavvio: numRestartBefore FullJobRestart	Numero massimo di riavvii a livello di processo prima che l'operatore riavvii a livello di lavoro.
Politica di riavvio: evalPeriodSeconds	Il periodo di valutazione del limite di riavvio in secondi
Politica di riavvio: riavvia maxFullJob	Numero massimo di riavvii completi del processo prima che il processo abbia esito negativo.
cleanPodPolicy	Speciifica i pod che l'operatore deve pulire. I valori accettati sono AllOnlyComplete, e. None
logMonitoringConfiguration	Le regole di monitoraggio dei log per il rilevamento di lavori lenti e interrotti
expectedRecurringFrequencyInSeconds	Intervallo di tempo tra due LogPattern partite consecutive dopo il quale la regola viene restituita come HANGING. Se non specificato, non esiste alcun vincolo di tempo tra partite consecutive. LogPattern
expectedStartCutOffInSeconds	Tempo intercorso dalla prima LogPattern partita dopo il quale la regola restituisce HANGING. Se non specificato, non esiste alcun vincolo di tempo per la prima partita. LogPattern
Schema di registro	Espressione regolare che identifica le righe di registro a cui si applica la regola quando la regola è attiva
metricEvaluationDataPunti	Numero di volte consecutive che una regola deve valutare come SLOW prima di contrassegnare un lavoro come SLOW. Se il valore non viene specificato, viene usato il valore predefinito 1.
Soglia metrica	Soglia per il valore estratto da LogPattern con un gruppo di acquisizione. Se non specificato, la valutazione metrica non viene eseguita.
operatore	La disuguaglianza da applicare alla configurazione di monitoraggio. I valori accettati sono gtgteq,lt,lteq, eeq.
StopPattern	Espressione regolare per identificare la riga di registro in corrispondenza della quale disattivare la regola. Se non viene specificata, la regola sarà sempre attiva.

Per una maggiore resilienza dell'allenamento, specifica i dettagli di configurazione dei nodi di riserva. Se il processo fallisce, l'operatore collabora con Kueue per utilizzare i nodi prenotati in anticipo per continuare a eseguire il lavoro. Le configurazioni dei nodi di riserva richiedono Kueue, quindi se provi a inviare un lavoro con nodi di riserva ma non hai Kueue installato, il processo avrà esito negativo. L'esempio seguente è un job.yaml file di esempio che contiene configurazioni di 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 i parametri in questi strumenti di osservabilità.

In alternativa, puoi acquisire metriche tramite Amazon Managed Service for Prometheus senza osservabilità gestita. A tale scopo, includi nel file le metriche che desideri monitorare quando esegui job.yaml lavori 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 formazione che puoi inserire in Amazon Managed Service for Prometheus per monitorare i tuoi lavori di formazione.

Evento	Descrizione
hyperpod_training_operator_jobs_created_total	Numero totale di lavori eseguiti dall'operatore addetto alla formazione
hyperpod_training_operator_jobs_restart_latency	Latenza di riavvio del lavoro corrente
hyperpod_training_operator_jobs_fault_detection_latency	Latenza di rilevamento dei guasti
hyperpod_training_operator_jobs_deleted_total	Numero totale di lavori eliminati
hyperpod_training_operator_jobs_successful_total	Numero totale di lavori completati
hyperpod_training_operator_jobs_failed_total	Numero totale di lavori non riusciti
hyperpod_training_operator_jobs_restarted_total	Numero totale di lavori riavviati automaticamente

Esempio di configurazione docker

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

Esempi di configurazioni di monitoraggio dei log

Job hang detection

Per rilevare i lavori di blocco, utilizzare le seguenti configurazioni. Utilizza i seguenti parametri:

• expectedStartCutOffInSeconds — quanto tempo deve attendere il monitor prima di aspettarsi i primi log

• expectedRecurringFrequencyInSeconds — l'intervallo di tempo di attesa per il successivo lotto di log

Con queste impostazioni, il monitor dei log prevede di visualizzare una riga di registro corrispondente allo schema regex .*Train Epoch.* entro 60 secondi dall'inizio del processo di formazione. Dopo la prima apparizione, il monitor si aspetta di vedere le righe di registro corrispondenti ogni 10 secondi. Se i primi registri non vengono visualizzati entro 60 secondi o i registri successivi non vengono visualizzati ogni 10 secondi, l'agente HyperPod elastico considera il contenitore bloccato e si coordina con l'operatore addetto all'addestramento 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 in allenamento

La seguente configurazione di monitoraggio emette i registri di allenamento con lo schema. xxx training_loss_step xx Utilizza il parametrometricEvaluationDataPoints, che consente di specificare una soglia di punti dati prima che l'operatore riavvii il lavoro. Se il valore della perdita di formazione è superiore a 2,0, l'operatore riavvia il lavoro.

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 basso TFLOPs

La seguente configurazione di monitoraggio emette registri di allenamento con lo schema xx TFLOPs xx ogni cinque secondi. Se TFLOPs è inferiore a 100 per 5 punti dati, l'operatore riavvia il processo di formazione.

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