Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Verwenden Sie Elastic Training bei Amazon SageMaker HyperPod

Elastic Training ist eine neue SageMaker HyperPod Funktion von Amazon, die Schulungsaufträge automatisch auf der Grundlage der Verfügbarkeit von Rechenressourcen und der Workload-Priorität skaliert. Elastische Trainingsjobs können mit minimalen Rechenressourcen beginnen, die für das Modelltraining erforderlich sind, und durch automatisches Checkpointing und Wiederaufnahme über verschiedene Knotenkonfigurationen hinweg (Weltgröße) dynamisch nach oben oder unten skaliert werden. Die Skalierung wird erreicht, indem die Anzahl der datenparallelen Replikate automatisch angepasst wird. In Zeiten hoher Cluster-Auslastung können Elastic-Training-Jobs so konfiguriert werden, dass sie als Reaktion auf Ressourcenanforderungen von Jobs mit höherer Priorität automatisch herunterskaliert werden, sodass mehr Rechenleistung für kritische Workloads zur Verfügung steht. Wenn Ressourcen außerhalb der Spitzenzeiten frei werden, werden Elastic-Training-Jobs automatisch wieder hochskaliert, um das Training zu beschleunigen, und dann wieder herunterskalieren, wenn Workloads mit höherer Priorität erneut Ressourcen benötigen.

Elastic Training baut auf dem HyperPod Schulungsleiter auf und beinhaltet die folgenden Komponenten:

Unterstützte Frameworks

Voraussetzungen

SageMaker HyperPod EKS-Cluster

Sie müssen über einen laufenden SageMaker HyperPod Cluster mit Amazon EKS-Orchestrierung verfügen. Informationen zum Erstellen eines HyperPod EKS-Clusters finden Sie unter:

SageMaker HyperPod Schulung des Bedieners

Elastic Training wird in Training Operator Version 1.2 und höher unterstützt.

Informationen zur Installation des Training Operators als EKS-Add-on finden Sie unter: https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-eks-operator-install.html

(Empfohlen) Installieren und konfigurieren Sie Task Governance und Kueue

Wir empfehlen, Kueue über HyperPod Task Governance zu installieren und zu konfigurieren, um Workload-Prioritäten mit Elastic Training festzulegen. Kueue bietet ein effektiveres Workload-Management mit Warteschlangen, Priorisierung, Gruppenplanung, Ressourcenverfolgung und gezielter Abwehr, was für den Betrieb in Schulungsumgebungen mit mehreren Mandanten unerlässlich ist.

Wir empfehlen, die folgenden Kueue-Komponenten zu konfigurieren:

Für komplexere Setups können Sie auch Folgendes integrieren:

Bitte beziehen Sie sich auf:

(Empfohlen) Richten Sie Benutzernamespaces und Ressourcenkontingente ein

Bei der Bereitstellung dieser Funktion auf Amazon EKS empfehlen wir, eine Reihe grundlegender Konfigurationen auf Cluster-Ebene anzuwenden, um Isolation, Ressourcengerechtigkeit und betriebliche Konsistenz zwischen den Teams sicherzustellen.

Namespace- und Zugriffskonfiguration

Organisieren Sie Ihre Workloads mithilfe separater Namespaces für jedes Team oder Projekt. Auf diese Weise können Sie eine differenzierte Isolierung und Steuerung anwenden. Wir empfehlen außerdem, die RBAC-Zuordnung von AWS IAM zu Kubernetes so zu konfigurieren, dass einzelne IAM-Benutzer oder -Rollen ihren entsprechenden Namespaces zugeordnet werden.

Zu den wichtigsten Praktiken gehören:

Ressourcen- und Recheneinschränkungen

Wenden Sie Kontingente und Grenzwerte auf Namespace-Ebene an, um Ressourcenkonflikte zu vermeiden und eine faire Teamplanung zu gewährleisten:

Diese Einschränkungen tragen zur Aufrechterhaltung der Cluster-Stabilität bei und unterstützen eine vorhersehbare Planung für verteilte Schulungsworkloads.

Auto-scaling

SageMaker HyperPod on EKS unterstützt Cluster-Autoscaling über Karpenter. Wenn Karpenter oder ein ähnlicher Resource Provisioner zusammen mit Elastic Training verwendet wird, können sowohl der Cluster als auch der Elastic-Training-Job automatisch hochskaliert werden, nachdem ein Elastic-Training-Job einmal eingereicht wurde. Das liegt daran, dass der Elastic Training Operator einen gierigen Ansatz verfolgt und immer mehr als die verfügbaren Rechenressourcen abfragt, bis die vom Job festgelegte Höchstgrenze erreicht ist. Dies liegt daran, dass der Elastic Training Operator im Rahmen der Ausführung eines elastischen Jobs kontinuierlich zusätzliche Ressourcen anfordert, was eine Node-Bereitstellung auslösen kann. Continuous Resource Provisioner wie Karpenter bearbeiten die Anfragen, indem sie den Rechencluster hochskalieren.

Um diese Skalierungen vorhersehbar und unter Kontrolle zu halten, empfehlen wir, die Namespace-Ebene in den ResourceQuotas Namespaces zu konfigurieren, in denen elastische Trainingsjobs erstellt werden. ResourceQuotas helfen dabei, die maximale Anzahl an Ressourcen, die Jobs anfordern können, zu begrenzen und so ein unbegrenztes Clusterwachstum zu verhindern und gleichzeitig ein elastisches Verhalten innerhalb definierter Grenzen zu ermöglichen.

Eine Instanz ResourceQuota für 8 ml.p5.48xlarge hat beispielsweise das folgende Format:

apiVersion: v1
kind: ResourceQuota
metadata:
  name: <quota-name>
  namespace: <namespace-name>
spec:
  hard:
    nvidia.com/gpu: "64"
    vpc.amazonaws.com/efa: "256"
    requests.cpu: "1536"
    requests.memory: "5120Gi"
    limits.cpu: "1536"
    limits.memory: "5120Gi"
      

Schulungscontainer erstellen

HyperPod Der Trainingsoperator arbeitet mit einem benutzerdefinierten PyTorch Launcher, der über das HyperPod Elastic Agent Python Package (https://www.piwheels.org/project/hyperpod-elastic-agent/) bereitgestellt wird. Kunden müssen den Elastic Agent installieren und den Befehl durch den torchrun Befehl ersetzenhyperpodrun, um das Training zu starten. Weitere Einzelheiten finden Sie unter:

https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-eks-operator-install.html#sagemaker -eks-operator-elastic-agent

Ein Beispiel für einen Trainingscontainer:

FROM ...

...

RUN pip install hyperpod-elastic-agent
ENTRYPOINT ["entrypoint.sh"]

# entrypoint.sh ...
hyperpodrun --nnodes=node_count --nproc-per-node=proc_count \
  --rdzv-backend hyperpod \
 # Optional ...
 # Other torchrun args
 # pre-traing arg_group
 --pre-train-script pre.sh --pre-train-args "pre_1 pre_2 pre_3" \
 # post-train arg_group
 --post-train-script post.sh --post-train-args "post_1 post_2 post_3" \
 training.py --script-args
  

Änderung des Trainingscodes

SageMaker HyperPod bietet eine Reihe von Rezepten, die bereits für die Ausführung mit Elastic Policy konfiguriert sind.

Um Elastic Training für benutzerdefinierte PyTorch Trainingsskripte zu aktivieren, müssen Sie geringfügige Änderungen an Ihrem Trainingsablauf vornehmen. Dieser Leitfaden führt Sie durch die notwendigen Änderungen, die erforderlich sind, um sicherzustellen, dass Ihr Trainingsjob auf elastische Skalierungsereignisse reagiert, die auftreten, wenn sich die Verfügbarkeit von Rechenressourcen ändert. Bei allen elastischen Ereignissen (z. B. wenn Knoten verfügbar sind oder Knoten gesperrt werden) empfängt der Trainingsjob ein elastisches Ereignissignal, das verwendet wird, um ein ordnungsgemäßes Herunterfahren zu koordinieren, indem ein Checkpoint gespeichert wird, und das Training wieder aufgenommen wird, indem von diesem gespeicherten Checkpoint aus mit einer neuen Weltkonfiguration neu gestartet wird. Um elastisches Training mit benutzerdefinierten Trainingsskripten zu aktivieren, müssen Sie:

Elastic Scaling-Ereignisse erkennen

Achte in deiner Trainingsschleife bei jeder Iteration auf elastische Ereignisse:

from hyperpod_elastic_agent.elastic_event_handler import elastic_event_detected

def train_epoch(model, dataloader, optimizer, args):
    for batch_idx, batch_data in enumerate(dataloader):
        # Forward and backward pass
        loss = model(batch_data).loss
        loss.backward()
        optimizer.step()
        optimizer.zero_grad()

        # Handle checkpointing and elastic scaling
        should_checkpoint = (batch_idx + 1) % args.checkpoint_freq == 0
        elastic_event = elastic_event_detected()
        
        # Save checkpoint if scaling-up or scaling down job
        if should_checkpoint or elastic_event:
            save_checkpoint(model, optimizer, scheduler, 
                            checkpoint_dir=args.checkpoint_dir, 
                            step=global_step)
              
            if elastic_event:
                print("Elastic scaling event detected. Checkpoint saved.")
                return
    

Implementieren Sie Checkpoint Saving und Checkpoint Loading

Hinweis: Wir empfehlen, PyTorch Distributed Checkpoint (DCP) zum Speichern von Modell- und Optimiererstatus zu verwenden, da DCP das Wiederaufnehmen von Checkpoints mit unterschiedlichen Weltgrößen unterstützt. Andere Checkpointing-Formate unterstützen das Laden von Checkpoints bei unterschiedlichen Weltgrößen möglicherweise nicht. In diesem Fall müssen Sie eine benutzerdefinierte Logik implementieren, um dynamische Änderungen der Weltgröße zu verarbeiten.

import torch.distributed.checkpoint as dcp
from torch.distributed.checkpoint.state_dict import get_state_dict, set_state_dict

def save_checkpoint(model, optimizer, lr_scheduler, user_content, checkpoint_path):
    """Save checkpoint using DCP for elastic training."""
    state_dict = {
        "model": model,
        "optimizer": optimizer,
        "lr_scheduler": lr_scheduler,
        **user_content
    }
      
    dcp.save(
        state_dict=state_dict,
        storage_writer=dcp.FileSystemWriter(checkpoint_path)
    )

def load_checkpoint(model, optimizer, lr_scheduler, checkpoint_path):
    """Load checkpoint using DCP with automatic resharding."""
    state_dict = {
        "model": model,
        "optimizer": optimizer,
        "lr_scheduler": lr_scheduler
    }
      
    dcp.load(
        state_dict=state_dict,
        storage_reader=dcp.FileSystemReader(checkpoint_path)
    )
      
    return model, optimizer, lr_scheduler
    

(Optional) Verwenden Sie statusbehaftete Datenlader

Wenn Sie nur für eine einzelne Epoche trainieren (d. h. einen einzigen Durchlauf durch den gesamten Datensatz), muss das Modell jede Datenprobe genau einmal sehen. Wenn der Trainingsjob mitten in der Epoche unterbrochen und mit einer anderen Weltgröße fortgesetzt wird, werden zuvor verarbeitete Datenproben wiederholt, sofern der Dataloader-Status nicht beibehalten wird. Ein statusbehafteter Dataloader verhindert dies, indem er die Position des Dataloaders speichert und wiederherstellt und so sicherstellt, dass die wiederaufgenommenen Läufe vom Elastic Scaling-Ereignis aus fortgesetzt werden, ohne dass Proben erneut verarbeitet werden müssen. Wir empfehlen, diese Add-Ons und Methoden zu verwenden StatefulDataLoader, die als Ersatz für torch.utils.data.DataLoader diese Add-Ons state_dict() und load_state_dict() Methoden dienen und das Checkpoint des Datenladevorgangs in der Mitte der Zeit ermöglichen.

Einreichung von Stellenangeboten im Bereich Elastic Training

HyperPod Der Schulungsoperator definiert einen neuen Ressourcentyp -hyperpodpytorchjob. Elastic Training erweitert diesen Ressourcentyp und fügt die unten hervorgehobenen Felder hinzu:

apiVersion: sagemaker.amazonaws.com/v1
kind: HyperPodPyTorchJob
metadata:
  name: elastic-training-job
spec:
  elasticPolicy:
    minReplicas: 1
    maxReplicas: 4
    # Increment amount of pods in fixed-size groups
    # Amount of pods will be equal to minReplicas + N * replicaIncrementStep
    replicaIncrementStep: 1           
    # ... or Provide an exact amount of pods that required for training
    replicaDiscreteValues: [2,4,8]     

    # How long traing operator wait job to save checkpoint and exit during
    # scaling events. Job will be force-stopped after this period of time
    gracefulShutdownTimeoutInSeconds: 600

    # When scaling event is detected:   
    # how long job controller waits before initiate scale-up.
    # Some delay can prevent from frequent scale-ups and scale-downs
    scalingTimeoutInSeconds: 60

    # In case of faults, specify how long elastic training should wait for
    # recovery, before triggering a scale-down
    faultyScaleDownTimeoutInSeconds: 30
  ...
  replicaSpecs:
    - name: pods
      replicas: 4           # Initial replica count
      maxReplicas: 8        # Max for this replica spec (should match elasticPolicy.maxReplicas)
      ...
  

Mit kubectl

Anschließend können Sie Elastic Training mit dem folgenden Befehl starten.

kubectl apply -f elastic-training-job.yaml

SageMaker Rezepte verwenden

Elastische Trainingsjobs können mithilfe von SageMaker HyperPod Rezepten gestartet werden.

Zusätzlich zu den statischen Rezepten fügen elastische Rezepte die folgenden Felder hinzu, um das elastische Verhalten zu definieren:

Elastische Richtlinie

Das elastic_policy Feld definiert die Konfiguration auf Jobebene für den Elastic-Training-Job. Es hat die folgenden Konfigurationen:

Im Folgenden finden Sie eine Beispieldefinition dieses Felds. Sie finden sie auch im Hyperpod-Rezept-Repo unter Rezept: recipes_collection/recipes/fine-tuning/llama/llmft_llama3_1_8b_instruct_seq4k_gpu_sft_lora.yaml

<static recipe>
...
elastic_policy:
  is_elastic: true
  min_nodes: 1
  max_nodes: 16
  use_graceful_shutdown: true
  scaling_timeout: 600
  graceful_shutdown_timeout: 600
      

Konfiguration skalieren

Das scale_config Feld definiert übergeordnete Konfigurationen auf jeder spezifischen Skala. Es ist ein Schlüssel-Wert-Wörterbuch, wobei Schlüssel eine Ganzzahl ist, die die Zielskala darstellt, und Wert eine Teilmenge des Basisrezepts ist. Bei der <key> Skalierung verwenden wir das, <value> um die spezifischen Konfigurationen im Rezept zu aktualisieren. base/static Das Folgende zeigt ein Beispiel für dieses Feld:

scale_config:   
...
  2:
    trainer:
      num_nodes: 2
    training_config:
      training_args:
        train_batch_size: 128
        micro_train_batch_size: 8
        learning_rate: 0.0004
  3:
    trainer:
      num_nodes: 3
    training_config:
      training_args:
        train_batch_size: 128
        learning_rate: 0.0004
        uneven_batch:
          use_uneven_batch: true
          num_dp_groups_with_small_batch_size: 16
          small_local_batch_size: 5
          large_local_batch_size: 6
 ...
      

Die obige Konfiguration definiert die Trainingskonfiguration auf Skala 2 und 3. In beiden Fällen verwenden wir die Lernrate4e-4, Chargengröße von128. Aber auf Skala 2 verwenden wir einen Wert micro_train_batch_size von 8, während wir bei Skala 3 eine ungleichmäßige Chargengröße verwenden, da die Chargengröße der Züge nicht gleichmäßig auf 3 Knoten aufgeteilt werden kann.

Ungleiche Chargengröße

In diesem Feld wird das Verhalten der Stapelverteilung definiert, wenn die globale Stapelgröße nicht gleichmäßig durch die Anzahl der Ränge geteilt werden kann. Es ist nicht spezifisch für elastisches Training, aber es ermöglicht eine feinere Skalierung und Granularität.

Überwachen Sie das Training auf MLflow

Hyperpod-Rezeptjobs unterstützen die Beobachtbarkeit durch MLflow. Benutzer können MLflow-Konfigurationen im Rezept angeben:

training_config:
  mlflow:
    tracking_uri: "<local_file_path or MLflow server URL>"
    run_id: "<MLflow run ID>"
    experiment_name: "<MLflow experiment name, e.g. llama_exps>"
    run_name: "<run name, e.g. llama3.1_8b>"

      

Diese Konfigurationen werden dem entsprechenden MLFlow-Setup zugeordnet. Im Folgenden finden Sie ein Beispiel für ein MLflow-Dashboard für einen Elastic-Training-Job.

Nachdem wir die elastischen Rezepte definiert haben, können wir die Launcher-Skripte verwenden, launcher_scripts/llama/run_llmft_llama3_1_8b_instruct_seq4k_gpu_sft_lora.sh um beispielsweise einen elastischen Trainingsjob zu starten. Dies ist vergleichbar mit dem Starten eines statischen Jobs mithilfe des Hyperpod-Rezepts.

Use-case Beispiele und Einschränkungen

Scale-up wenn mehr Ressourcen verfügbar sind

Wenn mehr Ressourcen auf dem Cluster verfügbar werden (z. B. wenn andere Workloads abgeschlossen sind). Während dieser Veranstaltung skaliert der Trainingscontroller den Trainingsjob automatisch nach oben. Dieses Verhalten wird unten erklärt.

Um eine Situation zu simulieren, in der mehr Ressourcen verfügbar werden, können wir einen Job mit hoher Priorität einreichen und dann Ressourcen wieder freigeben, indem wir den Job mit hoher Priorität löschen.

# Submit a high-priority job on your cluster. As a result of this command
# resources will not be available for elastic training
kubectl apply -f high_prioriy_job.yaml

# Submit an elastic job with normal priority
kubectl apply -f hyperpod_job_with_elasticity.yaml

# Wait for training to start....

# Delete high priority job. This command will make additional resources available for
# elastic training
kubectl delete -f high_prioriy_job.yaml

# Observe the scale-up of elastic job
    

Erwartetes Verhalten:

Hinweis: Wenn Kueue nicht verwendet wird, überspringt der trainierende Operator die ersten beiden Schritte. Es versucht sofort, die zusätzlichen Pods zu erstellen, die für die neue Weltgröße erforderlich sind. Wenn im Cluster nicht genügend Ressourcen verfügbar sind, bleiben diese Pods im Status Ausstehend, bis Kapazität verfügbar wird.

Verhinderung durch einen Job mit hoher Priorität

Elastische Jobs können automatisch herunterskaliert werden, wenn für einen Job mit hoher Priorität Ressourcen benötigt werden. Um dieses Verhalten zu simulieren, können Sie einen Elastic-Training-Job einreichen, der von Beginn des Trainings an die maximale Anzahl verfügbarer Ressourcen nutzt, dann einen Job mit hoher Priorität weiterleiten und ein präemptives Verhalten beobachten.

# Submit an elastic job with normal priority
kubectl apply -f hyperpod_job_with_elasticity.yaml

# Submit a high-priority job on your cluster. As a result of this command
# some amount of resources will be   
kubectl apply -f high_prioriy_job.yaml

# Observe scale-down behaviour
    

Wenn für einen Job mit hoher Priorität Ressourcen benötigt werden, kann Kueue Elastic Training-Workloads mit niedrigerer Priorität verhindern (dem Elastic Training-Job könnte mehr als ein Workload-Objekt zugeordnet sein). Der Präemptionsprozess folgt dieser Reihenfolge:

Eine Präemption kann dazu führen, dass der gesamte Trainingsjob unterbrochen wird, was möglicherweise nicht für alle Arbeitsabläufe wünschenswert ist. Um zu verhindern, dass der gesamte Job unterbrochen wird und trotzdem eine elastische Skalierung möglich ist, können Kunden innerhalb desselben Schulungsauftrags zwei verschiedene Prioritätsstufen konfigurieren, indem sie zwei Abschnitte definieren: replicaSpec

Diese Konfiguration ermöglicht eine teilweise Präventivmaßnahme, bei der nur die elastische Kapazität zurückgewonnen wird. So wird die Kontinuität des Trainings gewahrt und gleichzeitig eine faire gemeinsame Nutzung der Ressourcen in Umgebungen mit mehreren Mandanten unterstützt. Beispiel:

apiVersion: sagemaker.amazonaws.com/v1
kind: HyperPodPyTorchJob
metadata:
  name: elastic-training-job
spec:
  elasticPolicy:
    minReplicas: 2
    maxReplicas: 8
    replicaIncrementStep: 2
  ...
  replicaSpecs:
    - name: base
      replicas: 2
      template:
        spec:
          priorityClassName: high-priority # set high-priority to avoid evictions
           ...
    - name: elastic
      replicas: 0
      maxReplicas: 6
      template:
        spec:
          priorityClassName: low-priority. # Set low-priority for elastic part
           ...
    

Umgang mit Pod-Räumungen, Pod-Abstürzen und Hardwareproblemen:

Der HyperPod Schulungsleiter verfügt über integrierte Mechanismen, um den Trainingsprozess wiederherzustellen, wenn er unerwartet unterbrochen wird. Unterbrechungen können aus verschiedenen Gründen auftreten, z. B. aufgrund von Trainingscodefehlern, Pod-Räumungen, Knotenausfällen, Beeinträchtigung der Hardware und anderen Laufzeitproblemen.

In diesem Fall versucht der Operator automatisch, die betroffenen Pods neu zu erstellen und das Training vom letzten Checkpoint aus fortzusetzen. Wenn die Wiederherstellung nicht sofort möglich ist, z. B. aufgrund unzureichender Reservekapazität, kann der Bediener das Training fortsetzen, indem er die Gesamtgröße vorübergehend verkleinert und die elastische Trainingsaufgabe herunterskaliert.

Wenn ein Elastic-Training-Job abstürzt oder Replikate verloren gehen, verhält sich das System wie folgt:

Dieser Mechanismus stellt sicher, dass die Schulung mit minimalen Ausfallzeiten fortgesetzt werden kann, selbst wenn die Ressourcen knapp sind oder die Infrastruktur teilweise ausfällt, und gleichzeitig die Vorteile der elastischen Skalierung genutzt werden.

Verwenden Sie Elastic Training zusammen mit anderen HyperPod Funktionen

Elastic Training unterstützt derzeit keine Checkpointless-Trainingsfunktionen, HyperPod verwaltetes mehrstufiges Checkpointing oder Spot-Instances.