Verwenden Sie den Trainingsoperator, um Jobs auszuführen

Um den Job mit kubectl auszuführen, müssen Sie die Datei job.yaml zur Angabe der Jobspezifikationen erstellen und ausführenkubectl apply -f job.yaml, um den Job zu senden. In dieser YAML-Datei können Sie benutzerdefinierte Konfigurationen im logMonitoringConfiguration Argument angeben, um automatisierte Überwachungsregeln zu definieren, die die Protokollausgaben des verteilten Trainingsjobs analysieren, um Probleme zu erkennen und diese zu beheben.

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
      

Wenn Sie die Optionen zur Protokollüberwachung verwenden möchten, stellen Sie sicher, dass Sie das Trainingsprotokoll an sys.stdout senden. HyperPod Elastic Agent überwacht die Trainingsprotokolle in sys.stdout, das unter gespeichert ist. /tmp/hyperpod/ Sie können den folgenden Befehl verwenden, um Trainingsprotokolle auszugeben.

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

In der folgenden Tabelle werden alle möglichen Konfigurationen für die Protokollüberwachung beschrieben:

Parameter	Verwendung
jobMaxRetryZählen	Maximale Anzahl von Neustarts auf Prozessebene.
Neustart-Richtlinie: numRestartBefore FullJobRestart	Maximale Anzahl von Neustarts auf Prozessebene, bevor der Operator auf Auftragsebene neu startet.
Neustart-Richtlinie: evalPeriodSeconds	Der Zeitraum für die Auswertung des Neustartlimits in Sekunden
RestartPolicy: Startet neu maxFullJob	Maximale Anzahl vollständiger Job-Neustarts, bevor der Job fehlschlägt.
cleanPodPolicy	Gibt die Pods an, die der Bediener reinigen soll. Zulässige Werte sind AllOnlyComplete, undNone.
logMonitoringConfiguration	Die Regeln zur Protokollüberwachung für die Erkennung langsamer und hängender Jobs
expectedRecurringFrequencyInSeconds	Zeitintervall zwischen zwei aufeinanderfolgenden LogPattern Treffern, nach dessen Ablauf die Regel als HÄNGEND ausgewertet wird. Wenn nicht angegeben, besteht keine Zeitbeschränkung zwischen aufeinanderfolgenden LogPattern Treffern.
expectedStartCutOffInSeconds	Zeit bis zum ersten LogPattern Treffer, nach deren Ablauf die Regel als HÄNGEND ausgewertet wird. Wenn nicht angegeben, gibt es keine Zeitbeschränkung für den ersten LogPattern Treffer.
LogPattern	Regulärer Ausdruck, der Protokollzeilen identifiziert, für die die Regel gilt, wenn die Regel aktiv ist
metricEvaluationDataPunkte	Anzahl der aufeinanderfolgenden Male, bei denen eine Regel als LANGSAM bewertet werden muss, bevor ein Job als LANGSAM markiert wird. Wenn nichts angegeben ist, ist der Standardwert 1.
Metrischer Schwellenwert	Schwellenwert für den Wert, der LogPattern mit einer aufnehmenden Gruppe extrahiert wurde. Wenn nicht angegeben, wird keine Metrikauswertung durchgeführt.
operator	Die Ungleichheit, die auf die Überwachungskonfiguration angewendet werden soll. Zulässige Werte sind gtgteq,lt,lteq, undeq.
StopPattern	Regulärer Ausdruck zur Identifizierung der Protokollzeile, in der die Regel deaktiviert werden soll. Wenn nicht angegeben, ist die Regel immer aktiv.

Geben Sie für mehr Trainingsstabilität die Konfigurationsdetails für Ersatzknoten an. Wenn Ihr Job fehlschlägt, verwendet der Operator gemeinsam mit Kueue die im Voraus reservierten Knoten, um den Job weiter auszuführen. Für Ersatzknotenkonfigurationen ist Kueue erforderlich. Wenn Sie also versuchen, einen Job mit Ersatzknoten einzureichen, Kueue aber nicht installiert haben, schlägt der Job fehl. Das folgende Beispiel ist eine job.yaml Beispieldatei, die Ersatzknotenkonfigurationen enthält.

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"
      

Überwachen

Amazon SageMaker HyperPod ist in Observability mit Amazon Managed Grafana und Amazon Managed Service for Prometheus integriert, sodass Sie die Überwachung einrichten können, um Metriken zu sammeln und in diese Observability-Tools einzuspeisen.

Alternativ können Sie Metriken über Amazon Managed Service for Prometheus ohne verwaltete Observability abrufen. Nehmen Sie dazu die Metriken, die Sie überwachen möchten, in Ihre job.yaml Datei auf, wenn Sie Jobs mit ausführen. kubectl

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

Im Folgenden finden Sie Ereignisse, die der Schulungsleiter ausgibt und die Sie in Amazon Managed Service for Prometheus einspeisen können, um Ihre Schulungsjobs zu überwachen.

Ereignis	Beschreibung
hyperpod_training_operator_jobs_created_total	Gesamtzahl der Jobs, die der Schulungsoperator ausgeführt hat
hyperpod_training_operator_jobs_restart_latency	Aktuelle Latenz beim Neustart des Jobs
hyperpod_training_operator_jobs_fault_detection_latency	Latenz bei der Fehlererkennung
hyperpod_training_operator_jobs_deleted_total	Gesamtzahl der gelöschten Jobs
hyperpod_training_operator_jobs_successful_total	Gesamtzahl der abgeschlossenen Jobs
hyperpod_training_operator_jobs_failed_total	Gesamtzahl der fehlgeschlagenen Jobs
hyperpod_training_operator_jobs_restarted_total	Gesamtzahl der automatisch neu gestarteten Jobs

Beispiel für eine Docker-Konfiguration

Im Folgenden finden Sie ein Beispiel für eine Docker-Datei, die Sie mit dem hyperpod run Befehl ausführen können.

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}

Beispielkonfigurationen für die Protokollüberwachung

Erkennung von Auftragsabstürzen

Verwenden Sie die folgenden Konfigurationen, um hängende Jobs zu erkennen. Es verwendet die folgenden Parameter:

• expectedStartCutOffInSeconds — wie lange sollte der Monitor warten, bevor er die ersten Logs erwartet

• expectedRecurringFrequencyInSeconds — das Zeitintervall, in dem auf den nächsten Protokollstapel gewartet werden soll

Bei diesen Einstellungen geht der Protokollmonitor davon aus, dass .*Train Epoch.* innerhalb von 60 Sekunden nach dem Start des Trainingsjobs eine Protokollzeile angezeigt wird, die dem Regex-Muster entspricht. Nach dem ersten Erscheinen erwartet der Monitor, dass alle 10 Sekunden übereinstimmende Protokollzeilen angezeigt werden. Wenn die ersten Protokolle nicht innerhalb von 60 Sekunden oder die nachfolgenden Protokolle nicht alle 10 Sekunden erscheinen, behandelt das HyperPod elastische Mittel den Behälter als steckengeblieben und stimmt sich mit dem geschulten Bediener ab, um den Job neu zu starten.

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

Anstieg der Trainingsverluste

Die folgende Überwachungskonfiguration gibt Trainingsprotokolle mit dem Muster aus. xxx training_loss_step xx Sie verwendet den ParametermetricEvaluationDataPoints, mit dem Sie einen Schwellenwert für Datenpunkte angeben können, bevor der Anwender den Job neu startet. Wenn der Wert für den Trainingsverlust mehr als 2,0 beträgt, startet der Bediener den Job neu.

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

Niedriger Erkennungsgrad TFLOPs

Die folgende Überwachungskonfiguration gibt xx TFLOPs xx alle fünf Sekunden Trainingsprotokolle mit dem Muster aus. TFLOPs Liegt der Wert für 5 Datenpunkte unter 100, startet der Bediener den Trainingsjob erneut.

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