Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Utilisation de l’opérateur d’entraînement pour exécuter des tâches

Pour utiliser kubectl pour exécuter la tâche, vous devez créer un fichier job.yaml pour spécifier les spécifications de la tâche et exécuter kubectl apply -f job.yaml pour soumettre la tâche. Dans ce fichier YAML, vous pouvez spécifier des configurations personnalisées dans l’argument logMonitoringConfiguration afin de définir des règles de surveillance automatisées qui analysent les sorties de journal à partir de la tâche d’entraînement distribuée afin de détecter les problèmes et de les rétablir.

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 vous souhaitez utiliser les options de surveillance du journal, assurez-vous d'émettre le journal d'entraînement sursys.stdout. HyperPod Elastic Agent surveille les journaux d'entraînement dans sys.stdout, qui est enregistré à l'adresse. /tmp/hyperpod/ Vous pouvez utiliser la commande suivante pour émettre des journaux d’entraînement.

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

Le tableau suivant décrit toutes les configurations de surveillance des journaux possibles :

Pour une meilleure résilience de l’entraînement, spécifiez les détails de configuration des nœuds de rechange. Si votre tâche échoue, l’opérateur travaille avec Kueue pour utiliser les nœuds réservés à l’avance afin de continuer à exécuter la tâche. Les configurations de nœuds de rechange nécessitent Kueue. Par conséquent, si vous essayez de soumettre une tâche avec des nœuds de rechange mais que Kueue n’est pas installé, la tâche échouera. L’exemple suivant est un exemple de fichier job.yaml contenant des configurations de nœuds de rechange.

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"
      

Contrôle

Amazon SageMaker HyperPod est intégré à l'observabilité avec Amazon Managed Grafana et Amazon Managed Service for Prometheus. Vous pouvez donc configurer la surveillance pour collecter et intégrer des métriques à ces outils d'observabilité.

Vous pouvez également récupérer les métriques via le service géré Amazon pour Prometheus sans gestion de l’observabilité. Pour ce faire, incluez les métriques que vous souhaitez surveiller dans votre fichier job.yaml lorsque vous exécutez des tâches avec kubectl.

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

Les événements suivants sont émis par l’opérateur d’entraînement et vous pouvez les transmettre au service géré Amazon pour Prometheus afin de surveiller vos tâches d’entraînement.

Configuration avec un exemple de fichier docker

Voici un exemple de fichier docker que vous pouvez exécuter avec la commande 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}

Configurations de surveillance d’un exemple de journal

Détection des interruptions de tâche

Pour détecter les interruptions de tâche, utilisez les configurations suivantes. Elles utilisent les paramètres suivants :

Avec ces paramètres, le moniteur de journaux s’attend à voir une ligne de journal correspondant au modèle d’expression régulière .*Train Epoch.* dans les 60 secondes suivant le début de la tâche d’entraînement. Après la première occurrence, le moniteur s’attend à voir des lignes de journal correspondantes toutes les 10 secondes. Si les premiers journaux n'apparaissent pas dans les 60 secondes ou si les journaux suivants n'apparaissent pas toutes les 10 secondes, l'agent HyperPod élastique considère le contenant comme étant coincé et coordonne avec l'opérateur de formation pour recommencer le travail.

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

Pic de pertes d’entraînement

La configuration de surveillance suivante émet des journaux d’entraînement avec le modèle xxx training_loss_step xx. Elle utilise le paramètre metricEvaluationDataPoints, qui vous permet de spécifier un seuil de points de données avant que l’opérateur redémarre la tâche. Si la valeur de la perte d’entraînement est supérieure à 2.0, l’opérateur redémarre la tâche.

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

Faible TFLOPs détection

La configuration de surveillance suivante émet des journaux d’entraînement avec le modèle xx TFLOPs xx toutes les cinq secondes. S'il TFLOPs est inférieur à 100 pour 5 points de données, l'opérateur redémarre la tâche de formation.

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

Détection du journal des erreurs du script d'entraînement

La configuration de surveillance suivante détecte si le schéma spécifié dans logPattern est présent dans les journaux d'entraînement. Dès que l'opérateur de formation rencontre le schéma d'erreur, il le traite comme un défaut et redémarre le travail.

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