Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Usare la formazione elastica in Amazon SageMaker HyperPod

La formazione elastica è una nuova SageMaker HyperPod funzionalità di Amazon che ridimensiona automaticamente i lavori di formazione in base alla disponibilità delle risorse di calcolo e alla priorità del carico di lavoro. I lavori di formazione elastica possono iniziare con le risorse di calcolo minime necessarie per l'addestramento dei modelli e scalare dinamicamente verso l'alto o verso il basso attraverso il checkpoint e la ripresa automatici tra diverse configurazioni di nodi (di dimensioni mondiali). La scalabilità viene ottenuta regolando automaticamente il numero di repliche parallele dei dati. Durante i periodi di elevato utilizzo dei cluster, i job di training elastico possono essere configurati in modo da ridimensionarsi automaticamente in risposta alle richieste di risorse provenienti da processi con priorità più elevata, liberando così spazio di calcolo per i carichi di lavoro critici. Quando le risorse si liberano durante i periodi non di punta, i lavori di formazione elastica si ridimensionano automaticamente per accelerare la formazione, per poi ridurli quando i carichi di lavoro con priorità più alta necessitano nuovamente di risorse.

La formazione elastica si basa sull'operatore di HyperPod formazione e integra i seguenti componenti:

Framework supportati

Prerequisiti

SageMaker HyperPod Cluster EKS

È necessario disporre di un SageMaker HyperPod cluster in esecuzione con orchestrazione Amazon EKS. Per informazioni sulla creazione di un cluster HyperPod EKS, consulta:

SageMaker HyperPod Operatore di formazione

Elastic Training è supportato nella versione 1.2 e successive di Training Operator.

Per installare l'operatore di formazione come componente aggiuntivo EKS, consulta: https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-eks-operator-install.html

(Consigliato) Installa e configura Task Governance e Kueue

Consigliamo di installare e configurare Kueue tramite HyperPod Task Governance per specificare le priorità dei carichi di lavoro con la formazione elastica. Kueue offre una gestione più efficace del carico di lavoro con code, prioritizzazione, pianificazione dei gruppi, tracciamento delle risorse e prelazione semplificata, essenziali per operare in ambienti di formazione multi-tenant.

Consigliamo di configurare i seguenti componenti Kueue:

Per configurazioni più avanzate, puoi anche incorporare:

Si prega di fare riferimento a:

(Consigliato) Configura i namespace utente e le quote di risorse

Quando si implementa questa funzionalità su Amazon EKS, consigliamo di applicare una serie di configurazioni di base a livello di cluster per garantire l'isolamento, l'equità delle risorse e la coerenza operativa tra i team.

Configurazione dello spazio dei nomi e degli accessi

Organizza i carichi di lavoro utilizzando namespace separati per ogni team o progetto. Ciò consente di applicare un isolamento e una governance granulari. Consigliamo inoltre di configurare la mappatura RBAC da AWS IAM a Kubernetes per associare singoli utenti o ruoli IAM ai rispettivi namespace corrispondenti.

Le pratiche chiave includono:

Vincoli relativi alle risorse e all'elaborazione

Per evitare conflitti in termini di risorse e garantire una pianificazione equa tra i team, applica quote e limiti a livello di namespace:

Questi vincoli aiutano a mantenere la stabilità del cluster e supportano una pianificazione prevedibile per carichi di lavoro di formazione distribuiti.

Auto-scaling

SageMaker HyperPod on EKS supporta la scalabilità automatica del cluster tramite Karpenter. Quando Karpenter o un fornitore di risorse simile viene utilizzato insieme a Elastic Training, sia il cluster che il job di formazione elastica possono aumentare automaticamente dopo l'invio di un job di formazione elastica. Questo perché un operatore di formazione elastica adotta un approccio avido, chiede sempre più delle risorse di calcolo disponibili fino a raggiungere il limite massimo fissato dal lavoro. Ciò si verifica perché l'operatore di formazione elastica richiede continuamente risorse aggiuntive come parte dell'esecuzione elastica del lavoro, il che può attivare il provisioning dei nodi. I fornitori continui di risorse come Karpenter soddisferanno le richieste scalando il cluster di calcolo.

Per mantenere questi scale-up prevedibili e sotto controllo, consigliamo di configurare a livello di namespace nei ResourceQuotas namespace in cui vengono creati i job di formazione elastica. ResourceQuotas aiutano a limitare il numero massimo di risorse che i job possono richiedere, impedendo una crescita illimitata dei cluster e permettendo comunque un comportamento elastico entro limiti definiti.

Ad esempio, a ResourceQuota per 8 ml.p5.48xlarge istanze avrà il seguente formato:

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"
      

Costruisci un contenitore di formazione

HyperPod l'operatore di formazione lavora con un PyTorch launcher personalizzato fornito tramite il pacchetto python di HyperPod Elastic Agent () https://www.piwheels.org/project/hyperpod-elastic-agent/. I clienti devono installare l'agente elastico e sostituire il torchrun comando con hyperpodrun per avviare il training. Per maggiori dettagli, consulta:

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

Un esempio di contenitore di formazione:

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
  

Modifica del codice di addestramento

SageMaker HyperPod fornisce una serie di ricette già configurate per l'esecuzione con Elastic Policy.

Per abilitare l'allenamento elastico per gli script di PyTorch allenamento personalizzati, dovrai apportare piccole modifiche al ciclo di allenamento. Questa guida illustra le modifiche necessarie per garantire che il lavoro di formazione risponda agli eventi di scalabilità elastica che si verificano quando la disponibilità delle risorse di calcolo cambia. Durante tutti gli eventi elastici (ad esempio, i nodi sono disponibili o i nodi vengono annullati), il processo di formazione riceve un segnale di evento elastico che viene utilizzato per coordinare un arresto regolare salvando un checkpoint e riprendendo l'addestramento riavviando da quel checkpoint salvato con una nuova configurazione mondiale. Per abilitare l'allenamento elastico con script di allenamento personalizzati, devi:

Rileva gli eventi di Elastic Scaling

Nel ciclo di allenamento, verifica la presenza di eventi elastici durante ogni iterazione:

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
    

Implementa Checkpoint Saving e Checkpoint Loading

Nota: consigliamo di utilizzare PyTorch Distributed Checkpoint (DCP) per salvare gli stati del modello e dell'ottimizzatore, poiché DCP supporta la ripresa da un checkpoint con dimensioni del mondo diverse. Altri formati di checkpoint potrebbero non supportare il caricamento dei checkpoint su mondi di dimensioni diverse, nel qual caso dovrai implementare una logica personalizzata per gestire le modifiche dinamiche delle dimensioni del mondo.

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
    

(Facoltativo) Utilizza dataloader stateful

Se ti stai allenando solo per una singola epoca (cioè, un singolo passaggio attraverso l'intero set di dati), il modello deve vedere ogni campione di dati esattamente una volta. Se il processo di formazione si interrompe a metà epoca e riprende con una dimensione mondiale diversa, i campioni di dati elaborati in precedenza verranno ripetuti se lo stato del dataloader non viene mantenuto. Un dataloader stateful previene questo problema salvando e ripristinando la posizione del dataloader, assicurando che le esecuzioni riprese continuino dall'evento di scalatura elastica senza rielaborare alcun campione. Consigliamo di utilizzare StatefulDataLoader, che sostituisce in modo diretto le aggiunte state_dict() e i metodi, che consentano il checkpoint intermedio del processo di torch.utils.data.DataLoader caricamento dei dati. load_state_dict()

Invio di lavori di formazione elastici

HyperPod l'operatore di formazione definisce un nuovo tipo di risorsa -hyperpodpytorchjob. La formazione elastica estende questo tipo di risorsa e aggiunge i campi evidenziati di seguito:

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)
      ...
  

Usare kubectl

Successivamente puoi avviare l'allenamento elastico con il seguente comando.

kubectl apply -f elastic-training-job.yaml

Usare SageMaker le ricette

I lavori di formazione elastica possono essere avviati tramite SageMaker HyperPod ricette.

Oltre alle ricette statiche, le ricette elastiche aggiungono i seguenti campi per definire i comportamenti elastici:

Politica elastica

Il elastic_policy campo definisce la configurazione a livello di lavoro per il job di formazione elastica, ha le seguenti configurazioni:

Di seguito è riportato un esempio di definizione di questo campo, che puoi trovare anche nel repository Hyperpod Recipe in recipe: 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
      

Scale Config

Il scale_config campo definisce le configurazioni prioritarie su ogni scala specifica. È un dizionario chiave-valore, in cui la chiave è un numero intero che rappresenta la scala di destinazione e il valore è un sottoinsieme della ricetta di base. Su <key> larga scala, utilizziamo il <value> per aggiornare le configurazioni specifiche nella ricetta. base/static Di seguito viene mostrato un esempio di questo campo:

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
 ...
      

La configurazione precedente definisce la configurazione di addestramento alle scale 2 e 3. In entrambi i casi, utilizziamo il tasso di apprendimento4e-4, la dimensione del batch di128. Ma nella scala 2, utilizziamo un valore micro_train_batch_size di 8, mentre nella scala 3, utilizziamo una dimensione del batch non uniforme poiché la dimensione del lotto del treno non può essere divisa equamente su 3 nodi.

Dimensione del lotto non uniforme

Questo è un campo per definire il comportamento di distribuzione dei batch quando la dimensione globale del batch non può essere divisa equamente per il numero di ranghi. Non è specifico per l'allenamento elastico, ma consente una maggiore granularità di scalabilità.

Monitora la formazione su MLFlow

I lavori relativi alle ricette di Hyperpod supportano l'osservabilità tramite MLFlow. Gli utenti possono specificare le configurazioni MLFlow nella ricetta:

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>"

      

Queste configurazioni sono mappate alla configurazione MLFlow corrispondente. https://mlflow.org/docs/latest/ml/tracking/tracking-api/#setup--configuration Di seguito è riportato un esempio di dashboard MLFlow per un lavoro di formazione elastico.

Dopo aver definito le ricette elastiche, possiamo utilizzare gli script di avvio, ad esempio launcher_scripts/llama/run_llmft_llama3_1_8b_instruct_seq4k_gpu_sft_lora.sh per avviare un lavoro di formazione elastica. È simile all'avvio di un lavoro statico utilizzando la ricetta Hyperpod.

Use-case esempi e limitazioni

Scale-up quando sono disponibili più risorse

Quando sono disponibili più risorse nel cluster (ad esempio, altri carichi di lavoro vengono completati). Durante questo evento, il responsabile della formazione aumenterà automaticamente il lavoro di formazione. Questo comportamento è spiegato di seguito.

Per simulare una situazione in cui saranno disponibili più risorse, possiamo inviare un lavoro ad alta priorità e quindi rilasciare le risorse eliminando il lavoro ad alta priorità.

# 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
    

Comportamento previsto:

Nota: quando Kueue non viene utilizzato, l'operatore addetto alla formazione salta i primi due passaggi. Tenta immediatamente di creare i pod aggiuntivi necessari per la nuova dimensione del mondo. Se nel cluster non sono disponibili risorse sufficienti, questi pod rimarranno in sospeso fino a quando non sarà disponibile la capacità.

Prelazione tramite lavoro ad alta priorità

I lavori elastici possono essere ridimensionati automaticamente quando un lavoro ad alta priorità richiede risorse. Per simulare questo comportamento è possibile inviare un lavoro di formazione elastica, che utilizza il numero massimo di risorse disponibili dall'inizio della formazione, quindi inviare un lavoro ad alta priorità e osservare un comportamento di prelazione.

# 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
    

Quando un lavoro ad alta priorità richiede risorse, Kueue può anticipare i carichi di lavoro di Elastic Training con priorità inferiore (potrebbe esserci più di un oggetto Workload associato al job di Elastic Training). Il processo di prelazione segue questa sequenza:

La prelazione può causare la sospensione dell'intero processo di formazione, il che potrebbe non essere auspicabile per tutti i flussi di lavoro. Per evitare la sospensione completa del lavoro pur consentendo la scalabilità elastica, i clienti possono configurare due diversi livelli di priorità all'interno dello stesso lavoro di formazione definendo due sezioni: replicaSpec

Questa configurazione consente una prelazione parziale, in cui viene recuperata solo la capacità elastica, mantenendo la continuità della formazione pur supportando un'equa condivisione delle risorse in ambienti multi-tenant. Esempio:

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
           ...
    

Gestione dello sfratto del pod, del crash del pod e del degrado dell'hardware:

L'operatore addetto alla HyperPod formazione include meccanismi integrati per ripristinare il processo di formazione in caso di interruzione inaspettata. Le interruzioni possono verificarsi per vari motivi, ad esempio errori nel codice di addestramento, rimozione dei pod, guasti ai nodi, degrado dell'hardware e altri problemi di runtime.

Quando ciò accade, l'operatore tenta automaticamente di ricreare i pod interessati e riprendere l'allenamento dall'ultimo checkpoint. Se il recupero non è immediatamente possibile, ad esempio a causa dell'insufficiente capacità inutilizzata, l'operatore può continuare a progredire riducendo temporaneamente le dimensioni del mondo e ridimensionando il lavoro di formazione elastica.

Quando un job di training elastico si blocca o perde le repliche, il sistema si comporta come segue:

Questo meccanismo garantisce che la formazione possa continuare con tempi di inattività minimi, anche in caso di pressione delle risorse o guasti parziali dell'infrastruttura, sfruttando comunque la scalabilità elastica.

Usa la formazione elastica con altre funzionalità HyperPod

La formazione elastica attualmente non supporta funzionalità di formazione senza checkpoint, checkpoint HyperPod gestiti su più livelli o istanze Spot.