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.

Elastisches Training in Amazon verwenden SageMaker HyperPod

Elastic Training ist eine neue SageMaker HyperPod Amazon-Funktion, die Trainingsjobs automatisch auf der Grundlage der Verfügbarkeit von Rechenressourcen und der Priorität der Arbeitslast skaliert. Elastic Training Jobs können mit minimalen Rechenressourcen beginnen, die für das Modelltraining erforderlich sind, und dynamisch nach oben oder unten skaliert werden, indem automatische Checkpoints und Wiederaufnahme über verschiedene Knotenkonfigurationen hinweg (Weltgröße) durchgeführt werden. Die Skalierung wird erreicht, indem die Anzahl der datenparallelen Replikate automatisch angepasst wird. In Zeiten hoher Clusterauslastung 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 Rechenleistung für kritische Workloads zur Verfügung steht. Wenn in Zeiten mit geringer Auslastung Ressourcen frei werden, werden Elastic Training Jobs automatisch wieder hochskaliert, um das Training zu beschleunigen, und dann wieder herunterskaliert, wenn Workloads mit höherer Priorität wieder Ressourcen benötigen.

Elastic Training baut auf dem HyperPod Training des Operators auf und umfasst 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 Warteschlange

Wir empfehlen, Kueue über HyperPod Task Governance zu installieren und zu konfigurieren, um Workload-Prioritäten mit elastischem Training festzulegen. Kueue bietet ein leistungsfähigeres Workload-Management mit Warteschlangen, Priorisierung, Gruppenplanung, Ressourcenverfolgung und automatischer Abwehr, die für den Betrieb in Trainingsumgebungen mit mehreren Mandanten unerlässlich sind.

Wir empfehlen, die folgenden Kueue-Komponenten zu konfigurieren:

Für fortgeschrittenere 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 Clusterebene 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 fein abgestufte Isolierung und Steuerung anwenden. Wir empfehlen außerdem, die RBAC-Zuordnung von AWS IAM zu Kubernetes zu konfigurieren, um einzelne IAM-Benutzer oder -Rollen ihren entsprechenden Namespaces zuzuordnen.

Zu den wichtigsten Praktiken gehören:

Ressourcen- und Recheneinschränkungen

Um Ressourcenkonflikte zu vermeiden und eine faire Planung zwischen den Teams zu gewährleisten, sollten Sie Kontingente und Limits auf Namespace-Ebene einrichten:

Diese Einschränkungen tragen zur Aufrechterhaltung der Clusterstabilität bei und unterstützen eine vorhersehbare Planung verteilter Trainingsworkloads.

Auto Scaling

SageMaker HyperPod on EKS unterstützt die automatische Clusterskalierung über Karpenter. Wenn Karpenter oder ein ähnlicher Resource Provisioner zusammen mit elastischem Training verwendet wird, können sowohl der Cluster als auch der elastische Trainingsjob automatisch skaliert werden, nachdem ein elastischer Trainingsjob 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 von Elastic Jobs kontinuierlich zusätzliche Ressourcen anfordert, was die Bereitstellung von Knoten auslösen kann. Continuous Resource Provisioner wie Karpenter bearbeiten die Anfragen, indem sie den Rechencluster skalieren.

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 zu begrenzen, die Jobs anfordern können, wodurch ein unbegrenztes Clusterwachstum verhindert und dennoch elastisches Verhalten innerhalb definierter Grenzen ermöglicht wird.

Ein Beispiel ResourceQuota für 8 ml.p5.48xlarge-Instances hat 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"
      

Trainingscontainer erstellen

HyperPod Training Operator arbeitet mit einem benutzerdefinierten PyTorch Launcher, der über das Python-Paket HyperPod Elastic Agent bereitgestellt wird (https://www.piwheels). org/project/hyperpod-elastic-agent/). Kunden müssen den Elastic Agent installieren und den torchrun Befehl durch to launch training ersetzen. hyperpodrun Weitere Informationen finden Sie unter:

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

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 stellt eine Reihe von Rezepten bereit, die bereits für die Ausführung mit Elastic Policy konfiguriert wurden.

Um Elastic Training für benutzerdefinierte PyTorch Trainingsskripte zu aktivieren, müssen Sie kleinere Änderungen an Ihrer Trainingsschleife 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 Event-Signal, das verwendet wird, um ein ordnungsgemäßes Herunterfahren zu koordinieren, indem ein Checkpoint gespeichert wird, und das Training wieder aufgenommen, indem es von diesem gespeicherten Checkpoint aus mit einer neuen Weltkonfiguration neu gestartet wird. Um Elastic Training mit benutzerdefinierten Trainingsskripten zu aktivieren, müssen Sie:

Elastic Scaling-Ereignisse erkennen

Suchen Sie in Ihrer Trainingsschleife bei jeder Iteration nach elastischen Ereignissen:

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 die Verwendung von PyTorch Distributed Checkpoint (DCP) zum Speichern von Modell- und Optimiererstatus, da DCP die Wiederaufnahme von einem Checkpoint mit unterschiedlichen Weltgrößen unterstützt. Andere Checkpoint-Formate unterstützen möglicherweise das Laden von Checkpoints auf verschiedenen Weltgrößen nicht. In diesem Fall müssen Sie eine benutzerdefinierte Logik implementieren, um dynamische Änderungen der Weltgröße zu handhaben.

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 Stateful-Dataloader

Wenn Sie nur für eine einzelne Epoche trainieren (d. h. einen einzigen Durchgang durch den gesamten Datensatz), muss das Modell jede Datenprobe genau einmal betrachten. Wenn der Trainingsjob in der Mitte der Epoche beendet und mit einer anderen Weltgröße wieder aufgenommen wird, werden zuvor verarbeitete Datenproben wiederholt, sofern der Dataloader-Status nicht dauerhaft ist. Ein Stateful-Dataloader verhindert dies, indem er die Position des Dataloaders speichert und wiederherstellt und so sicherstellt, dass wieder aufgenommene Läufe ab dem Elastic Scaling-Ereignis fortgesetzt werden, ohne dass Stichproben erneut verarbeitet werden. Wir empfehlen die Verwendung eines Systems StatefulDataLoader, das als Ersatz für torch.utils.data.DataLoader diese Erweiterungen state_dict() und load_state_dict() Methoden dient und das Checkpoint des Datenladevorgangs mitten in der Entwicklungsphase ermöglicht.

Elastic Training-Jobs einreichen

HyperPod Der Trainingsoperator 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)
      ...
  

Verwenden von kubectl

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

kubectl apply -f elastic-training-job.yaml

SageMaker Rezepte verwenden

Elastische Trainingsjobs können über SageMaker HyperPod Rezepte 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 für dieses Feld. Sie finden sie auch im Hyperpod Recipe Repo im 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
      

Config skalieren

Das scale_config Feld definiert übergeordnete Konfigurationen für jede spezifische Skala. Es handelt sich um ein Schlüssel-Werte-Wörterbuch, wobei Schlüssel eine Ganzzahl ist, die die Zielskala darstellt, und Wert eine Teilmenge des Basisrezepts ist. Bei <key> Scale verwenden wir das, <value> um die spezifischen Konfigurationen im Rezept zu aktualisieren. base/static Im Folgenden wird ein Beispiel für dieses Feld gezeigt:

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, die 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 des Zuges nicht gleichmäßig auf 3 Knoten aufgeteilt werden kann.

Ungleichmäßige Chargengröße

In diesem Feld wird das Verhalten bei der Stapelverteilung definiert, wenn die globale Stapelgröße nicht gleichmäßig durch die Anzahl der Ränge aufgeteilt werden kann. Es ist nicht spezifisch für elastisches Training, ermöglicht aber eine feinere Skalierungsgranularitä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 sind dem entsprechenden MLFlow Setup zugeordnet. Im Folgenden finden Sie ein MLflow Beispiel-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 Elastic-Training-Job zu starten. Dies ähnelt dem Starten eines statischen Jobs mit dem Hyperpod-Rezept.

Anwendungsbeispiele und Einschränkungen

Skalieren Sie, 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. Dieses Verhalten wird im Folgenden 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, verbleiben diese Pods im Status Ausstehend, bis Kapazität verfügbar ist.

Präemption durch Aufgabe mit hoher Priorität

Elastic Jobs können automatisch herunterskaliert werden, wenn ein Job mit hoher Priorität Ressourcen benötigt. Um dieses Verhalten zu simulieren, können Sie einen Elastic Training-Job einreichen, der zu Beginn des Trainings die maximale Anzahl verfügbarer Ressourcen nutzt, anschließend einen Job mit hoher Priorität weiterleiten und das Preemption-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 ein Job mit hoher Priorität Ressourcen benötigt, kann Kueue Elastic Training-Workloads mit niedrigerer Priorität zuvorkommen (dem Elastic Training-Job kann mehr als ein Workload-Objekt zugeordnet sein). Der Präemptionsvorgang folgt der folgenden Reihenfolge:

Eine Präemption kann dazu führen, dass der gesamte Trainingsjob unterbrochen wird, was möglicherweise nicht für alle Workflows wünschenswert ist. Um zu verhindern, dass die gesamte Arbeit unterbrochen wird, und gleichzeitig 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äemption, bei der nur die elastische Kapazität zurückgewonnen wird. Dadurch wird die Kontinuität des Trainings aufrechterhalten und gleichzeitig eine faire Aufteilung 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
           ...
    

Umgehung von Pods, Pod-Abstürze und Hardwareverlust:

Der HyperPod trainierende Operator verfügt über integrierte Mechanismen, mit denen der Trainingsprozess wiederhergestellt werden kann, wenn er unerwartet unterbrochen wird. Unterbrechungen können aus verschiedenen Gründen auftreten, z. B. aufgrund von Fehlern im Trainingscode, aufgrund von Pod-Räumungen, Knotenausfällen, Hardwareabbau und anderen Laufzeitproblemen.

In diesem Fall versucht der Operator automatisch, die betroffenen Pods neu zu erstellen und das Training am letzten Checkpoint fortzusetzen. Wenn eine Wiederherstellung nicht sofort möglich ist, z. B. aufgrund unzureichender Reservekapazitäten, kann der Bediener seine Fortschritte fortsetzen, indem er die Weltgröße vorübergehend reduziert und die elastische Trainingseinheit herunterskaliert.

Wenn ein elastischer Trainingsjob 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, auch wenn Ressourcen knapp sind oder die Infrastruktur teilweise ausfällt, und gleichzeitig die Vorteile der elastischen Skalierung genutzt werden.

Verwenden Sie elastisches Training mit anderen HyperPod Funktionen

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