翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

トレーニングオペレーターを使用してジョブを実行する

kubectl を使用してジョブを実行するには、job.yaml を作成してジョブ仕様を指定し、kubectl apply -f job.yaml を実行してジョブを送信する必要があります。この YAML ファイルでは、logMonitoringConfiguration 引数でカスタム設定を指定して、分散トレーニングジョブからのログ出力を分析し、問題を検出して復旧する自動モニタリングルールを定義できます。

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
      

ログモニタリングオプションを使用する場合は、トレーニングログを sys.stdout に出力していることを確認してください。HyperPod Elastic Agent は、/tmp/hyperpod/ に保存されている sys.stdout のトレーニングログをモニタリングします。次のコマンドを使用して、トレーニングログを出力できます。

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

想定可能なすべてのログモニタリング設定は、次の表のとおりです。

トレーニングの耐障害性を向上するには、予備のノード設定の詳細を指定します。ジョブが失敗した場合、オペレーターは Kueue と連携して、事前に予約されたノードを使用してジョブの実行を続行します。スペアノード設定には Kueue が必要なため、スペアノードを持つジョブを送信しようとしても Kueue がインストールされていない場合、ジョブは失敗します。次の例は、予備のノード設定を含むサンプル job.yaml ファイルです。

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"
      

モニタリング

Amazon SageMaker HyperPod は、Amazon Managed Grafana および Amazon Managed Service for Prometheus とのオブザーバビリティと統合されているため、これらのオブザーバビリティツールにメトリクスを収集して供給するためのモニタリングを設定できます。

または、マネージドオブザーバビリティを使用せずに、Amazon Managed Service for Prometheus を介してメトリクスをスクレイプすることもできます。これを行うには、kubectl でジョブを実行する際に、モニタリングするメトリクスを job.yaml ファイルに含めます。

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

以下は、トレーニングオペレーターが Amazon Managed Service for Prometheus にフィードしてトレーニングジョブをモニタリングできるイベントです。

サンプル Docker 設定

以下は、hyperpod run コマンドで実行できるサンプル docker ファイルです。

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}

ログモニタリング設定例

ジョブのハング検出

ハングしたジョブを検出するには、次の設定を使用します。以下のパラメータを使用します。

これらの設定の場合、ログモニターはトレーニングジョブの開始から 60 秒以内に正規表現パターン .*Train Epoch.* に一致するログ行を認識することを期待します。最初の表示後、モニターは 10 秒ごとに一致するログ行を認識することを期待します。最初のログが 60 秒以内に現れない場合、または後続のログが 10 秒ごとに現れない場合、HyperPod Elastic Agent はコンテナをスタックとして扱い、トレーニングオペレーターと連携してジョブを再開します。

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

トレーニングロスのスパイク

次のモニタリング設定は、パターン xxx training_loss_step xx を使用してトレーニングログを出力します。パラメータ metricEvaluationDataPoints を使用します。これにより、オペレータがジョブを再起動する前にデータポイントのしきい値を指定できます。トレーニング損失値が 2.0 を超える場合、オペレーターはジョブを再起動します。

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

低 TFLOP 検出

次のモニタリング設定は、パターン xx TFLOPs xx を使用して、5 秒ごとにトレーニングログを出力します。5 つのデータポイントで TFLOP が 100 未満の場合、オペレーターはトレーニングジョブを再起動します。

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

トレーニングスクリプトのエラーログ検出

次のモニタリング設定は、 で指定されたパターンlogPatternがトレーニングログに存在するかどうかを検出します。トレーニングオペレーターがエラーパターンに遭遇するとすぐに、トレーニングオペレーターはそれを障害として扱い、ジョブを再起動します。

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