Utilisation de l'opérateur de formation 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'logMonitoringConfigurationargument afin de définir des règles de surveillance automatisées qui analysent les résultats du journal de la tâche de formation 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 possibles de surveillance des journaux :

Paramètre	Utilisation
jobMaxRetryCompter	Nombre maximal de redémarrages au niveau du processus.
Politique de redémarrage : numRestartBefore FullJobRestart	Nombre maximal de redémarrages au niveau du processus avant que l'opérateur ne redémarre au niveau de la tâche.
Politique de redémarrage : evalPeriodSeconds	Période d'évaluation de la limite de redémarrage en secondes
Politique de redémarrage : redémarrages maxFullJob	Nombre maximum de redémarrages complets d'une tâche avant son échec.
cleanPodPolicy	Spécifie les capsules que l'opérateur doit nettoyer. Les valeurs acceptées sont AllOnlyComplete, etNone.
logMonitoringConfiguration	Les règles de surveillance des journaux pour la détection des tâches lentes et en suspens
expectedRecurringFrequencyInSeconds	Intervalle de temps entre deux LogPattern matchs consécutifs après lequel la règle prend la valeur HANGING. Si ce n'est pas spécifié, aucune contrainte de temps n'existe entre les LogPattern matchs consécutifs.
expectedStartCutOffInSeconds	Délai avant la première LogPattern correspondance, après quoi la règle passe à HANGING. Si ce n'est pas spécifié, aucune contrainte de temps n'existe pour le premier LogPattern match.
Modèle de journal	Expression régulière qui identifie les lignes de journal auxquelles la règle s'applique lorsque la règle est active
metricEvaluationDataPoints	Nombre de fois consécutives qu'une règle doit être évaluée à SLOW avant de marquer une tâche comme SLOW. Si la valeur n'est pas spécifiée, la valeur par défaut est 1.
Seuil métrique	Seuil de valeur extraite LogPattern par un groupe de capture. Si ce n'est pas spécifié, l'évaluation des métriques n'est pas effectuée.
opérateur	Inégalité à appliquer à la configuration de surveillance. Les valeurs acceptées sont gtgteq,lt,lteq, eteq.
Schéma d'arrêt	Expression régulière pour identifier la ligne de journal sur laquelle la règle doit être désactivée. Si elle n'est pas spécifiée, la règle sera toujours active.

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 job.yaml fichier 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"
      

Surveillance

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 extraire les métriques via Amazon Managed Service for Prometheus sans gestion de l'observabilité. Pour ce faire, incluez les métriques que vous souhaitez surveiller dans votre job.yaml fichier lorsque vous exécutez des tâches aveckubectl.

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 de formation et vous pouvez les transmettre à Amazon Managed Service for Prometheus afin de suivre vos tâches de formation.

Événement	Description
hyperpod_training_operator_jobs_created_total	Nombre total de tâches exécutées par l'opérateur de formation
hyperpod_training_operator_jobs_restart_latency	Latence de redémarrage de la tâche actuelle
hyperpod_training_operator_jobs_fault_detection_latency	Latence de détection des défauts
hyperpod_training_operator_jobs_deleted_total	Nombre total de tâches supprimées
hyperpod_training_operator_jobs_successful_total	Nombre total de tâches terminées
hyperpod_training_operator_jobs_failed_total	Nombre total d'emplois ratés
hyperpod_training_operator_jobs_restarted_total	Nombre total de tâches redémarrées automatiquement

Exemple de configuration de docker

Voici un exemple de fichier docker que vous pouvez exécuter avec la hyperpod run commande.

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}

Exemples de configurations de surveillance des journaux

Détection des blocages au travail

Pour détecter les problèmes de blocage, utilisez les configurations suivantes. Il utilise les paramètres suivants :

• expectedStartCutOffInSeconds — combien de temps le moniteur doit attendre avant d'attendre les premiers logs

• expectedRecurringFrequencyInSeconds — l'intervalle de temps pendant lequel il faut attendre le prochain lot de logs

Avec ces paramètres, le moniteur de journal s'attend à voir une ligne de journal correspondant au modèle regex dans les 60 secondes .*Train Epoch.* suivant le début de la tâche de formation. Après la première apparition, 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 à l'entraînement

La configuration de surveillance suivante émet des journaux d'entraînement avec le modèle. xxx training_loss_step xx Il utilise le paramètremetricEvaluationDataPoints, qui vous permet de spécifier un seuil de points de données avant que l'opérateur ne redémarre le travail. Si la valeur de la perte d'entraînement est supérieure à 2,0, l'opérateur redémarre le travail.

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 niveau TFLOPs de détection

La configuration de surveillance suivante émet des journaux d'entraînement avec le schéma 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