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à.
# Amazon SageMaker HyperPod
SageMaker HyperPod ti aiuta a fornire cluster resilienti per l'esecuzione di carichi di lavoro di machine learning (ML) e lo sviluppo di state-of-the-art modelli come modelli di linguaggio di grandi dimensioni (LLMs), modelli di diffusione e modelli di base (). FMs Accelera lo sviluppo FMs eliminando gli oneri indifferenziati legati alla creazione e alla manutenzione di cluster di elaborazione su larga scala alimentati da migliaia di acceleratori come Trainium e NVIDIA A100 e H100 Graphical Processing Unit (). AWS GPUs In caso di guasto degli acceleratori, le funzionalità di resilienza delle istanze di SageMaker HyperPod Monitor the Cluster rilevano e sostituiscono automaticamente l'hardware difettoso in modo che tu possa concentrarti sull'esecuzione di carichi di lavoro ML.
Per iniziare, controlla[Prerequisiti per l'utilizzo SageMaker HyperPod](sagemaker-hyperpod-prerequisites.md), configura [AWS Identity and Access Management per SageMaker HyperPod](sagemaker-hyperpod-prerequisites-iam.md) e scegli una delle seguenti opzioni di orchestrazione supportate da. SageMaker HyperPod
**Supporto Slurm in SageMaker HyperPod**
SageMaker HyperPod fornisce supporto per l'esecuzione di carichi di lavoro di machine learning su cluster resilienti mediante l'integrazione con Slurm, un gestore di carichi di lavoro open source. Il supporto di Slurm SageMaker HyperPod consente una perfetta orchestrazione del cluster tramite la configurazione del cluster Slurm, consentendo di configurare nodi head, login e worker sui SageMaker HyperPod cluster. Questa integrazione facilita anche la pianificazione dei processi basata su Slurm per l'esecuzione di carichi di lavoro ML sul cluster, nonché l'accesso diretto ai nodi del cluster per la pianificazione dei processi. Con il supporto per la configurazione HyperPod del ciclo di vita, puoi personalizzare l'ambiente di elaborazione dei cluster per soddisfare i tuoi requisiti specifici. Inoltre, sfruttando le librerie di formazione distribuite di Amazon SageMaker AI, puoi ottimizzare le prestazioni dei cluster sulle AWS risorse di elaborazione e di rete. Per ulteriori informazioni, consulta [Orchestrazione SageMaker HyperPod dei cluster con Slurm](sagemaker-hyperpod-slurm.md).
**Supporto Amazon EKS in SageMaker HyperPod**
SageMaker HyperPod si integra inoltre con Amazon EKS per consentire la formazione su larga scala di modelli di base su cluster di elaborazione resilienti e di lunga durata. Ciò consente agli utenti amministratori del cluster di effettuare il provisioning dei HyperPod cluster e collegarli a un piano di controllo EKS, abilitando la gestione dinamica della capacità, l'accesso diretto alle istanze del cluster e le funzionalità di resilienza. Per i data scientist, il supporto di Amazon EKS HyperPod consente di eseguire carichi di lavoro containerizzati per la formazione dei modelli di base, l'inferenza sul cluster EKS e lo sfruttamento della funzionalità di ripristino automatico del lavoro per la formazione Kubeflow. PyTorch L'architettura prevede una mappatura 1 a 1 tra un cluster EKS (piano di controllo) e un HyperPod cluster (nodi di lavoro) all'interno di un VPC, fornendo una soluzione strettamente integrata per l'esecuzione di carichi di lavoro ML su larga scala. Per ulteriori informazioni, consulta [Orchestrazione di SageMaker HyperPod cluster con Amazon EKS](sagemaker-hyperpod-eks.md).
**UltraServers con HyperPod**
HyperPod UltraServers offre potenza di calcolo AI integrando i superchip NVIDIA in un'infrastruttura coesa e ad alte prestazioni. Ciascuna NVL72 UltraServer combina 18 istanze con 72 istanze NVIDIA Blackwell GPUs interconnesse NVLink, consentendo inferenze più rapide e prestazioni di formazione più rapide rispetto alle istanze della generazione precedente. Questa architettura è particolarmente utile per le organizzazioni che lavorano con modelli di base composti da trilioni di parametri, poiché la memoria GPU unificata consente a interi modelli di rimanere all'interno di un unico dominio, eliminando i colli di bottiglia della rete tra nodi. NVLink HyperPod migliora questo vantaggio hardware con una pianificazione intelligente basata sulla topologia che ottimizza il posizionamento dei carichi di lavoro, la sostituzione automatica delle istanze per ridurre al minimo le interruzioni e opzioni di implementazione flessibili che supportano configurazioni di risorse dedicate e condivise. Per i team che si spingono oltre i limiti delle dimensioni e delle prestazioni dei modelli, questa integrazione fornisce la base computazionale necessaria per addestrare e implementare i modelli di IA più avanzati con un’efficienza senza precedenti.
SageMaker HyperPod ottimizza automaticamente il posizionamento delle istanze su. UltraServers Per impostazione predefinita, HyperPod assegna la priorità a tutte le istanze in una UltraServer prima di utilizzarne un'altra. Ad esempio, se desideri 14 istanze e ne hai 2 UltraServers nel tuo piano, l' SageMaker IA utilizza tutte le istanze della prima. UltraServer Se desideri 20 istanze, l' SageMaker IA utilizza tutte le 18 istanze nella prima UltraServer e poi ne utilizza altre 2 nella seconda.
## Regioni AWS supportato da SageMaker HyperPod
SageMaker HyperPod è disponibile nelle seguenti versioni Regioni AWS.
+ us-east-1
+ us-east-2
+ us-west-1
+ us-west-2
+ eu-central-1
+ eu-north-1
+ eu-west-1
+ eu-west-2
+ eu-south-2
+ ap-south-1
+ ap-southeast-1
+ ap-southeast-2
+ ap-southeast-3
+ ap-southeast-4
+ ap-northeast-1
+ sa-east-1
**Topics**
+ [Regioni AWS supportato da SageMaker HyperPod](#sagemaker-hyperpod-available-regions)
+ [SageMaker HyperPod Guida introduttiva di Amazon](sagemaker-hyperpod-quickstart.md)
+ [Prerequisiti per l'utilizzo SageMaker HyperPod](sagemaker-hyperpod-prerequisites.md)
+ [AWS Identity and Access Management per SageMaker HyperPod](sagemaker-hyperpod-prerequisites-iam.md)
+ [AWS KMS key Crittografia gestita dal cliente per SageMaker HyperPod](smcluster-cmk.md)
+ [SageMaker HyperPod ricette](sagemaker-hyperpod-recipes.md)
+ [Orchestrazione SageMaker HyperPod dei cluster con Slurm](sagemaker-hyperpod-slurm.md)
+ [Orchestrazione di SageMaker HyperPod cluster con Amazon EKS](sagemaker-hyperpod-eks.md)
+ [Utilizzo della pianificazione basata sulla topologia in Amazon SageMaker HyperPod](sagemaker-hyperpod-topology.md)
+ [Implementazione di modelli su Amazon SageMaker HyperPod](sagemaker-hyperpod-model-deployment.md)
+ [HyperPod in Studio](sagemaker-hyperpod-studio.md)
+ [SageMaker HyperPod riferimenti](sagemaker-hyperpod-ref.md)
+ [Note di SageMaker HyperPod rilascio di Amazon](sagemaker-hyperpod-release-notes.md)
+ [SageMaker HyperPod AMI Amazon](sagemaker-hyperpod-release-ami.md)
# SageMaker HyperPod Guida introduttiva di Amazon
Questa guida rapida ti guida nella creazione del tuo primo HyperPod cluster con orchestrazioni Slurm e Amazon EKS (EKS). Scegli l'orchestrazione più adatta alle esigenze della tua infrastruttura per iniziare. SageMaker HyperPod
**Topics**
+ [Crea un cluster orchestrato da SLURM SageMaker HyperPod](#sagemaker-hyperpod-quickstart-slurm)
+ [Crea un cluster orchestrato da EKS SageMaker HyperPod](#sagemaker-hyperpod-quickstart-eks)
+ [Invio di carichi di lavoro](#sagemaker-hyperpod-quickstart-workload)
## Crea un cluster orchestrato da SLURM SageMaker HyperPod
Segui questi passaggi per creare il tuo primo SageMaker HyperPod cluster con l'orchestrazione Slurm.
1. Apri la console Amazon SageMaker AI all'indirizzo [https://console.aws.amazon.com/sagemaker/](https://console.aws.amazon.com/sagemaker/).
1. Scegli **HyperPod Clusters** nel riquadro di navigazione a sinistra, quindi **Cluster Management**.
1. Nella pagina **SageMaker HyperPod Cluster, scegli **Crea HyperPod ** cluster**.
1. Nel menu a discesa **Crea HyperPod cluster**, scegli **Orchestrated** by Slurm.
1. Nella pagina di creazione del cluster, scegli **Configurazione rapida**. Con questa opzione, puoi iniziare immediatamente con le impostazioni predefinite. SageMaker L'intelligenza artificiale creerà nuove risorse come VPC, sottoreti, gruppi di sicurezza, bucket Amazon S3, ruolo IAM e FSx for Lustre nel processo di creazione del cluster.
1. In **Impostazioni generali**, specifica un nome per il nuovo cluster. Dopo la creazione del cluster, non è più possibile modificarne il nome.
1. In **Gruppi di istanze**, scegli **Aggiungi gruppo**. Ogni gruppo di istanze può essere configurato in modo diverso ed è possibile creare un cluster eterogeneo composto da più gruppi di istanze con vari tipi di istanze. Per implementare un cluster, devi aggiungere almeno un gruppo di istanze. Puoi aggiungere un gruppo di istanze alla volta. Per creare più gruppi di istanze, ripeti il processo per ogni gruppo.
Segui questa procedura per aggiungere un gruppo di istanze.
1. In **Tipo di gruppo di istanze**, scegli un tipo per il tuo gruppo di istanze. Per questo avvio rapido, scegli **Controller (head)** per `my-controller-group`, **Login** per `my-login-group` e **Calcolo (worker)** per `worker-group-1`.
1. In **Nome**, specifica un nome per il gruppo di istanze. Per questo avvio rapido, crea tre gruppi di istanze denominati `my-controller-group`, `my-login-group` e `worker-group-1`.
1. In **Capacità dell’istanza**, scegli la capacità on demand o un piano di addestramento per riservare le tue risorse di calcolo.
1. Per **Tipo di istanza**, scegli l’istanza per il gruppo di istanze. Per questo avvio rapido, seleziona `ml.c5.xlarge` per `my-controller-group`, `ml.m5.4xlarge` per `my-login-group` e `ml.trn1.32xlarge` per `worker-group-1`.
Assicurati di scegliere il tipo di istanza con quote sufficienti nel tuo account oppure richiedi quote aggiuntive seguendo le istruzioni riportate in [SageMaker HyperPod quote](sagemaker-hyperpod-prerequisites.md#sagemaker-hyperpod-prerequisites-quotas).
1. In **Quantità istanze**. specifica un numero intero che non sia maggiore della quota dell’istanza per l’utilizzo del cluster. Per questo avvio rapido, inserisci **1** in tutti e tre i gruppi.
1. In **Zona di disponibilità di destinazione**, scegli la zona di disponibilità in cui allocare le istanze. La zona di disponibilità deve corrispondere alla posizione della capacità di calcolo accelerata.
1. Per **Volume di archiviazione aggiuntivo per istanza (GB) (facoltativo)**, specifica un numero intero compreso tra 1 e 16.384 per impostare la dimensione di un volume Elastic Block Store (EBS) aggiuntivo in gigabyte (GB). Il volume EBS è collegato a ciascuna istanza del gruppo di istanze. Il percorso di montaggio predefinito per il volume EBS aggiuntivo è `/opt/sagemaker`. Dopo aver creato correttamente il cluster, è possibile accedere tramite SSH alle istanze del cluster (nodi) e verificare che il volume EBS sia montato correttamente eseguendo il comando `df -h`. Il collegamento di un volume EBS aggiuntivo fornisce un’archiviazione stabile, fuori istanza e con persistenza indipendente, come descritto nella sezione [Amazon EBS volumes](https://docs.aws.amazon.com//ebs/latest/userguide/ebs-volumes.html) in *Amazon Elastic Block Store User Guide*.
1. Scegli **Aggiungi gruppo di istanze**.
1. In **Impostazioni predefinite di configurazione rapida**, rivedi le impostazioni predefinite. Questa sezione elenca tutte le impostazioni predefinite per la creazione del cluster, incluse tutte le nuove AWS risorse che verranno create durante il processo di creazione del cluster.
1. Seleziona **Invia**.
Per ulteriori informazioni, consulta [Guida introduttiva all' SageMaker HyperPod utilizzo della console SageMaker AI](smcluster-getting-started-slurm-console.md).
## Crea un cluster orchestrato da EKS SageMaker HyperPod
Segui questi passaggi per creare il tuo primo SageMaker HyperPod cluster con l'orchestrazione di Amazon EKS.
1. Apri la console Amazon SageMaker AI all'indirizzo [https://console.aws.amazon.com/sagemaker/](https://console.aws.amazon.com/sagemaker/).
1. Scegli **HyperPod Clusters** nel riquadro di navigazione a sinistra, quindi **Cluster Management**.
1. Nella pagina **SageMaker HyperPod Cluster, scegli **Crea HyperPod ** cluster**.
1. Nel menu a discesa **Crea HyperPod cluster**, scegli **Orchestrated by** Amazon EKS.
1. Nella pagina di creazione del cluster, scegli **Configurazione rapida**. Con questa opzione, puoi iniziare immediatamente con le impostazioni predefinite. SageMaker L'intelligenza artificiale creerà nuove risorse come VPC, sottoreti, gruppi di sicurezza, bucket Amazon S3, ruolo IAM e FSx for Lustre nel processo di creazione del cluster.
1. In **Impostazioni generali**, specifica un nome per il nuovo cluster. Dopo la creazione del cluster, non è più possibile modificarne il nome.
1. In **Gruppi di istanze**, scegli **Aggiungi gruppo**. Ogni gruppo di istanze può essere configurato in modo diverso ed è possibile creare un cluster eterogeneo composto da più gruppi di istanze con vari tipi di istanze. Per implementare un cluster, devi aggiungere almeno un gruppo di istanze. Puoi aggiungere un gruppo di istanze alla volta. Per creare più gruppi di istanze, ripeti il processo per ogni gruppo.
Segui questa procedura per aggiungere un gruppo di istanze.
1. In **Tipo di gruppo di istanze**, scegli **Standard** o **Gruppo di istanze limitato (RIG)**. Di solito si sceglie **Standard** perché fornisce un ambiente di calcolo generico senza limitazioni di sicurezza aggiuntive. **Gruppo di istanze limitato (RIG)** è un ambiente specializzato per la personalizzazione di modelli di fondazione come Amazon Nova. Per ulteriori informazioni sulla configurazione di RIG per la personalizzazione del modello Amazon Nova, consulta la personalizzazione di Amazon Nova nella guida per SageMaker HyperPod l'utente di [Amazon Nova 1.0 o nella guida per l'utente](https://docs.aws.amazon.com//nova/latest/userguide/nova-hp.html) di [Amazon Nova 2.0](https://docs.aws.amazon.com//nova/latest/nova2-userguide/nova-hp.html).
1. In **Nome**, specifica un nome per il gruppo di istanze.
1. In **Capacità dell’istanza**, scegli la capacità on demand o un piano di addestramento per riservare le tue risorse di calcolo.
1. Per **Tipo di istanza**, scegli l’istanza per il gruppo di istanze. Assicurati di scegliere il tipo di istanza con quote sufficienti nel tuo account oppure richiedi quote aggiuntive seguendo le istruzioni riportate in [SageMaker HyperPod quote](sagemaker-hyperpod-prerequisites.md#sagemaker-hyperpod-prerequisites-quotas).
1. In **Quantità istanze**. specifica un numero intero che non sia maggiore della quota dell’istanza per l’utilizzo del cluster. Per questo avvio rapido, inserisci **1** in tutti e tre i gruppi.
1. In **Zona di disponibilità di destinazione**, scegli la zona di disponibilità in cui allocare le istanze. La zona di disponibilità deve corrispondere alla posizione della capacità di calcolo accelerata.
1. Per **Volume di archiviazione aggiuntivo per istanza (GB) (facoltativo)**, specifica un numero intero compreso tra 1 e 16.384 per impostare la dimensione di un volume Elastic Block Store (EBS) aggiuntivo in gigabyte (GB). Il volume EBS è collegato a ciascuna istanza del gruppo di istanze. Il percorso di montaggio predefinito per il volume EBS aggiuntivo è `/opt/sagemaker`. Dopo aver creato correttamente il cluster, è possibile accedere tramite SSH alle istanze del cluster (nodi) e verificare che il volume EBS sia montato correttamente eseguendo il comando `df -h`. Il collegamento di un volume EBS aggiuntivo fornisce un’archiviazione stabile, fuori istanza e con persistenza indipendente, come descritto nella sezione [Amazon EBS volumes](https://docs.aws.amazon.com//ebs/latest/userguide/ebs-volumes.html) in *Amazon Elastic Block Store User Guide*.
1. Per **Controlli approfonditi dell’integrità delle istanze**, scegli un’opzione. I controlli dell’integrità approfonditi monitorano l’integrità dell’istanza durante la creazione e dopo gli aggiornamenti software, ripristinando automaticamente le istanze difettose con riavvii o sostituzioni, se abilitati.
1. Scegli **Aggiungi gruppo di istanze**.
1. In **Impostazioni predefinite di configurazione rapida**, rivedi le impostazioni predefinite. Questa sezione elenca tutte le impostazioni predefinite per la creazione del cluster, incluse tutte le nuove AWS risorse che verranno create durante il processo di creazione del cluster.
1. Seleziona **Invia**.
Per ulteriori informazioni, consulta [Creazione di un SageMaker HyperPod cluster con l'orchestrazione di Amazon EKS](sagemaker-hyperpod-eks-operate-console-ui-create-cluster.md).
## Invio di carichi di lavoro
Segui questi tutorial del workshop per inviare carichi di lavoro di esempio.
+ [Amazon SageMaker HyperPod per Slurm](https://catalog.workshops.aws/sagemaker-hyperpod/en-US)
+ [Amazon SageMaker HyperPod per Amazon EKS](https://catalog.workshops.aws/sagemaker-hyperpod-eks/en-US)
# Prerequisiti per l'utilizzo SageMaker HyperPod
Le seguenti sezioni illustrano i prerequisiti prima di iniziare. SageMaker HyperPod
**Topics**
+ [SageMaker HyperPod quote](#sagemaker-hyperpod-prerequisites-quotas)
+ [Configurazione SageMaker HyperPod con un Amazon VPC personalizzato](#sagemaker-hyperpod-prerequisites-optional-vpc)
+ [Configurazione di cluster su più cluster SageMaker HyperPod AZs](#sagemaker-hyperpod-prerequisites-multiple-availability-zones)
+ [Configurazione AWS Systems Manager ed esecuzione come per il controllo degli accessi degli utenti del cluster](#sagemaker-hyperpod-prerequisites-ssm)
+ [(Facoltativo) Configurazione SageMaker HyperPod con Amazon FSx for Lustre](#sagemaker-hyperpod-prerequisites-optional-fsx)
## SageMaker HyperPod quote
Puoi creare SageMaker HyperPod cluster in base alle quote di *utilizzo dei cluster* nel tuo account. AWS
**Importante**
Per ulteriori informazioni sui SageMaker HyperPod prezzi, consulta la pagina [SageMaker HyperPod prezzi](sagemaker-hyperpod-ref.md#sagemaker-hyperpod-ref-pricing) e [ SageMaker i prezzi di Amazon](https://aws.amazon.com/sagemaker/pricing/).
### Visualizza le SageMaker HyperPod quote Amazon utilizzando il Console di gestione AWS
Cerca i valori predefiniti e applicati di una *quota*, nota anche come *limite*, per *l'utilizzo del cluster*, utilizzata per SageMaker HyperPod.
1. Apri la [Quote di servizio console](https://console.aws.amazon.com/servicequotas/).
1. Nel pannello di navigazione a sinistra, scegli **Servizi AWS **.
1. Dall'elenco dei **AWS servizi**, cerca e seleziona **Amazon SageMaker AI**.
1. Nell'elenco delle **quote di servizio**, puoi vedere il nome della quota di servizio, il valore applicato (se disponibile), la quota AWS predefinita e se il valore della quota è regolabile.
1. Nella barra di ricerca, digita **utilizzo del cluster**. Vengono mostrate le quote per l’utilizzo del cluster, le quote applicate e le quote predefinite.
**Elenco delle quote di servizio comuni per creare un HyperPod cluster e dei relativi prerequisiti**
Potresti voler verificare se hai richiesto aumenti del limite delle quote di servizio per le seguenti quote per creare un nuovo HyperPod cluster insieme ai prerequisiti nella console AI. SageMaker Vai alla console **Service Quota** e cerca i seguenti termini.
****
| No | Nome della quota | Termine di ricerca | Description |
| --- | --- | --- | --- |
| 1 | Numero massimo di istanze consentite per cluster SageMaker HyperPod | In SageMaker AI cerca «Numero massimo di istanze consentite per SageMaker HyperPod cluster» | Il valore della quota a livello di account deve essere superiore al numero di istanze che desideri aggiungere al cluster |
| 2 | Dimensione massima del volume EBS in GB per un'istanza di cluster SageMaker HyperPod | In SageMaker AI cerca «Dimensione massima del volume EBS in GB per un'istanza HyperPod cluster» | Il valore della quota a livello di account deve essere superiore al volume EBS che desideri aggiungere al cluster |
| 3 | Numero totale di istanze consentite tra i cluster SageMaker HyperPod | In SageMaker AI cerca «Numero totale di istanze consentite tra i cluster» SageMaker HyperPod | Il valore della quota a livello di account deve essere superiore al totale delle istanze che desideri aggiungere in tutti i cluster del tuo account in forma aggregata |
| 4 | Quote di istanze | In SageMaker AI, cerca «ml». «per l'utilizzo del cluster», ad esempio: ml.p5.48xlarge per l'utilizzo del cluster | Il valore della quota a livello di account per il particolare tipo di istanza (ad esempio: ml.p5.48xlarge) deve essere maggiore del numero di istanze da aggiungere a tutti i cluster dell'account in forma aggregata. |
| 5 | VPCs per regione | In Amazon Virtual Private Cloud (Amazon VPC) cerca «VPCsper regione» | Il valore della quota a livello di account deve essere sufficiente per creare un nuovo VPC nell'account durante la configurazione del cluster. HyperPod Verifica se hai già esaurito questo limite di quota controllando la console VPC. Questo aumento della quota è necessario solo se intendi creare un nuovo VPC tramite l'opzione di configurazione del cluster rapida o personalizzata nella SageMaker HyperPod console. |
| 6 | Gateway Internet per regione | In Amazon Virtual Private Cloud (Amazon VPC) cerca «Gateway Internet per regione» | Il valore della quota a livello di account deve essere sufficiente per creare un gateway Internet aggiuntivo nell'account durante la configurazione del cluster. SageMaker HyperPod Questo aumento della quota è necessario solo se intendi creare un nuovo VPC tramite l'opzione di configurazione del cluster rapida o personalizzata nella SageMaker HyperPod console. |
| 7 | Interfacce di rete per regione | In Amazon Virtual Private Cloud (Amazon VPC) cerca «Interfacce di rete per regione» | Il valore della quota a livello di account deve contenere un numero sufficiente di interfacce di rete nell'account al momento della configurazione del cluster. HyperPod |
| 8 | Elastico EC2-VPC IPs | In Amazon Elastic Compute Cloud (Amazon EC2), cerca «EC2-VPC Elastic» IPs | Il valore della quota a livello di account deve essere sufficiente per creare un nuovo VPC nell'account durante la configurazione del cluster. HyperPod Verifica se hai già esaurito questo limite di quota controllando la console VPC. Questo aumento della quota è necessario solo se intendi creare un nuovo VPC tramite l'opzione di configurazione del cluster rapida o personalizzata nella SageMaker HyperPod console. |
### Richiedi un aumento della SageMaker HyperPod quota Amazon utilizzando il Console di gestione AWS
Aumenta le quote a livello di account o di risorsa.
1. Per aumentare la quota delle istanze per *l’utilizzo del cluster*, seleziona la quota da aumentare.
1. Se la quota è regolabile, puoi richiedere un aumento della quota a livello di account o di risorsa in base al valore elencato nella colonna **Regolabilità**.
1. In **Aumenta il valore della quota**, inserisci il nuovo valore. Questo valore deve essere maggiore di quello corrente.
1. Scegli **Richiedi**.
1. Per visualizzare eventuali richieste in sospeso o risolte di recente nella console, vai alla scheda **Cronologia richieste** dalla pagina dei dettagli del servizio o scegli **Dashboard** dal riquadro di navigazione. Per le richieste in sospeso, scegliere lo stato della richiesta per aprire la ricevuta della richiesta. Lo stato iniziale di una richiesta è **Pending** (In attesa). Dopo la modifica dello stato in **Quota richiesta**, vedrai il numero del caso con Supporto AWS. Scegli il numero del caso per aprire il ticket della tua richiesta.
Per ulteriori informazioni generali su come richiedere un aumento della quota, consulta [Requesting a Quota Increase](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html) in *AWS Service Quotas User Guide*.
## Configurazione SageMaker HyperPod con un Amazon VPC personalizzato
Per configurare un SageMaker HyperPod cluster con un Amazon VPC personalizzato, esamina i seguenti prerequisiti.
**Nota**
La configurazione VPC è obbligatoria per l’orchestrazione Amazon EKS. Per l’orchestrazione Slurm, la configurazione VPC è facoltativa.
+ Convalida la capacità dell'[Elastic Network Interface](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html) (ENI) Account AWS prima di creare un SageMaker HyperPod cluster con un VPC personalizzato. Il limite ENI è controllato da Amazon EC2 e varia a seconda. Regione AWS SageMaker HyperPod non può richiedere automaticamente aumenti delle quote.
**Per verificare la tua attuale quota ENI:**
1. Apri la [Quote di servizio console](https://console.aws.amazon.com/servicequotas/).
1. **Nella sezione **Gestisci quote**, utilizza l'elenco a discesa ** AWS Servizi** per cercare VPC.**
1. Scegli di visualizzare le quote di **Amazon Virtual Private Cloud (Amazon VPC)**.
1. Cerca la Service Quota **Interfacce di rete per Regione** o il **Codice di quota** `L-DF5E4CA3`.
Se l'attuale limite ENI non è sufficiente per le esigenze del SageMaker HyperPod cluster, richiedi un aumento della quota. Assicurarsi preventivamente una capacità ENI adeguata aiuta a prevenire gli errori di implementazione dei cluster.
+ Quando utilizzi un VPC personalizzato per connettere un SageMaker HyperPod cluster con AWS risorse, fornisci il nome, l'ID Regione AWS, la sottorete e il gruppo di sicurezza VPC durante la IDs creazione del cluster. IDs
**Nota**
Quando Amazon VPC e sottoreti sono supportati IPv6 nel cluster o a livello di gruppo [https://docs.aws.amazon.com//sagemaker/latest/APIReference/API_CreateCluster.html#sagemaker-CreateCluster-request-VpcConfig](https://docs.aws.amazon.com//sagemaker/latest/APIReference/API_CreateCluster.html#sagemaker-CreateCluster-request-VpcConfig)di istanze utilizzando l'`OverrideVPCConfig`attributo of [https://docs.aws.amazon.com//sagemaker/latest/APIReference/API_ClusterInstanceGroupSpecification.html](https://docs.aws.amazon.com//sagemaker/latest/APIReference/API_ClusterInstanceGroupSpecification.html), le comunicazioni di rete differiscono in base alla piattaforma di orchestrazione del cluster:
I cluster orchestrati da SLURM configurano automaticamente i nodi con due indirizzi e, permettendo comunicazioni di rete immediate. IPv6 IPv4 IPv6 Non è richiesta alcuna configurazione aggiuntiva oltre alle impostazioni. `VPCConfig` IPv6
Nei cluster orchestrati da EKS, i nodi ricevono l'indirizzamento dual-stack, ma i pod possono essere utilizzati solo quando IPv6 il cluster Amazon EKS è abilitato in modo esplicito. IPv6 È necessario creare un nuovo cluster IPv6 Amazon EKS: i cluster IPv4 Amazon EKS esistenti non possono essere convertiti in IPv6. Per informazioni sulla distribuzione di un cluster IPv6 Amazon EKS, consulta [Amazon EKS IPv6 Cluster Deployment](https://docs.aws.amazon.com/eks/latest/userguide/deploy-ipv6-cluster.html#_deploy_an_ipv6_cluster_with_eksctl).
Risorse aggiuntive per la IPv6 configurazione:
Per informazioni sull'aggiunta del IPv6 supporto al tuo VPC, consulta [IPv6 Support for VPC](https://docs.aws.amazon.com//vpc/latest/userguide/vpc-migrate-ipv6.html).
Per informazioni sulla creazione di un nuovo VPC IPv6 compatibile, [Amazon VPC consulta](https://docs.aws.amazon.com//vpc/latest/userguide/create-vpc.html) la Guida alla creazione.
Per configurare SageMaker HyperPod con un Amazon VPC personalizzato, consulta Configurazione [Amazon VPC](https://docs.aws.amazon.com//sagemaker/latest/dg/sagemaker-hyperpod-prerequisites.html#sagemaker-hyperpod-prerequisites-optional-vpc) personalizzata per. SageMaker HyperPod
+ Assicurati che tutte le risorse siano distribuite nello stesso ambiente del cluster Regione AWS . SageMaker HyperPod Configura le regole dei gruppi di sicurezza per consentire la comunicazione tra le risorse all’interno del VPC. Ad esempio, quando crei un VPC in `us-west-2`, alloca le sottoreti su una o più zone di disponibilità (ad esempio `us-west-2a` o `us-west-2b`) e crea un gruppo di sicurezza che consenta il traffico tra i gruppi.
**Nota**
SageMaker HyperPod supporta l'implementazione di zone di disponibilità multiple. Per ulteriori informazioni, consulta [Configurazione di cluster su più cluster SageMaker HyperPod AZs](#sagemaker-hyperpod-prerequisites-multiple-availability-zones).
+ Stabilisci la connettività Amazon Simple Storage Service (Amazon S3) per i SageMaker HyperPod gruppi di istanze distribuiti tramite VPC creando un endpoint VPC. Senza accesso a Internet, i gruppi di istanze non possono archiviare o recuperare gli script del ciclo di vita, i dati di addestramento o gli artefatti del modello. Ti consigliamo di creare una policy IAM personalizzata che limiti l’accesso dei bucket Amazon S3 al VPC privato. Per ulteriori informazioni, consulta [Endpoints for Amazon S3](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-endpoints-s3.html) in *AWS PrivateLink Guide*.
+ Per HyperPod i cluster che utilizzano istanze abilitate per Elastic Fabric Adapter (EFA), configura il gruppo di sicurezza per consentire tutto il traffico in entrata e in uscita da e verso il gruppo di sicurezza stesso. In particolare, evita di utilizzare `0.0.0.0/0` per le regole in uscita, perché potrebbe causare errori nei controlli dell’integrità EFA. Per ulteriori informazioni sulle linee guida per la preparazione dei gruppi di sicurezza EFA, consulta [Step 1: Prepare an EFA-enabled security group](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa-start.html#efa-start-security) in *Amazon EC2 User Guide*.
+ Valuta attentamente la dimensione del blocco CIDR (Classless Inter-Domain Routing) della sottorete prima di creare cluster. HyperPod
+ La dimensione dell’intervallo CIDR della sottorete non può essere modificata dopo la creazione. Questo aspetto è particolarmente importante quando utilizzi istanze accelerate di grandi dimensioni come P5. Senza una dimensione del blocco sufficiente, in caso di aumento verticale dovrai ricreare i cluster.
+ Quando scegli la dimensione dell’intervallo CIDR della sottorete appropriata, considera questi fattori: i tipi di istanze, il numero previsto di istanze e il numero di indirizzi IP utilizzati da ciascuna istanza.
+ Per i cluster orchestrati da Slurm, ogni istanza P5 può creare 32 indirizzi IP (uno per ogni scheda di rete). Per i cluster orchestrati da EKS, ogni istanza P5 può creare 81 indirizzi IP (50 dalla scheda primaria più uno da ciascuna delle restanti 31 schede). Per specifiche dettagliate, consulta [Network specifications ](https://docs.aws.amazon.com/ec2/latest/instancetypes/ac.html#ac_network) in *Amazon EC2 Instance Types Developer Guide*.
+ [Per esempi di CloudFormation modelli che specificano la dimensione del blocco CIDR della sottorete, consulta il modello [HyperPod Slurm e il modello HyperPod ](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/sagemaker-hyperpod.yaml)[Amazon EKS](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/7.sagemaker-hyperpod-eks/cfn-templates/nested-stacks/private-subnet-stack.yaml) nel repository. awsome-distributed-training ](https://github.com/aws-samples/awsome-distributed-training/tree/main)
## Configurazione di cluster su più cluster SageMaker HyperPod AZs
È possibile configurare SageMaker HyperPod i cluster su più zone di disponibilità (AZs) per migliorare l'affidabilità e la disponibilità.
**Nota**
Il traffico Elastic Fabric Adapter (EFA) non può attraversare o. AZs VPCs Questo non si applica al normale traffico IP dal dispositivo ENA di un'interfaccia EFA. Per ulteriori informazioni, consulta [EFA limitations](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa.html).
+ **Comportamento predefinito**
HyperPod distribuisce tutte le istanze del cluster in un'unica zona di disponibilità. La configurazione VPC determina l’AZ di implementazione:
+ Per i cluster orchestrati da Slurm, la configurazione VPC è facoltativa. Quando non viene fornita alcuna configurazione VPC, l' HyperPod impostazione predefinita è una sottorete dal VPC della piattaforma.
+ Per i cluster orchestrati da EKS, la configurazione VPC è obbligatoria.
+ Sia per gli orchestratori Slurm che EKS, quando [https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_VpcConfig.html](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_VpcConfig.html)viene fornita, seleziona una sottorete dall'elenco delle sottoreti del fornitore. HyperPod `VpcConfig` Tutti i gruppi di istanze ereditano la AZ della sottorete.
**Nota**
Una volta creato un cluster, non è possibile modificarne le impostazioni `VpcConfig`.
Per ulteriori informazioni sulla configurazione VPCs per i cluster, vedere la sezione precedente,. HyperPod [Configurazione SageMaker HyperPod con un Amazon VPC personalizzato](#sagemaker-hyperpod-prerequisites-optional-vpc)
+ **Configurazione Multi-AZ**
È possibile configurare il HyperPod cluster su più gruppi AZs durante la creazione di un cluster o l'aggiunta di un nuovo gruppo di istanze a un cluster esistente. Per configurare le implementazioni Multi-AZ, puoi sostituire le impostazioni VPC predefinite del cluster specificando sottoreti e gruppi di sicurezza diversi, possibilmente in diverse zone di disponibilità, per singoli gruppi di istanze all’interno del cluster.
SageMaker HyperPod Gli utenti dell'API possono utilizzare la `OverrideVpcConfig` proprietà all'interno di [ClusterInstanceGroupSpecification](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_ClusterInstanceGroupSpecification.html)quando lavorano con [https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_CreateCluster.html](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_CreateCluster.html)o [https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_UpdateCluster.html](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_UpdateCluster.html) APIs.
Il campo `OverrideVpcConfig`:
+ Non può essere modificato dopo la creazione del gruppo di istanze.
+ È facoltativo. Se non è specificato, viene utilizzato il livello del cluster [https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_VpcConfig.html](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_VpcConfig.html) come impostazione predefinita.
+ Per i cluster orchestrati da Slurm, può essere specificato solo quando viene fornito il livello del cluster `VpcConfig`. Se non è specificato alcun valore `VpcConfig` a livello del cluster, `OverrideVpcConfig` non può essere utilizzato per alcun gruppo di istanze.
+ Contiene due campi obbligatori:
+ `Subnets`- accetta tra 1 e 16 sottoreti IDs
+ `SecurityGroupIds`- accetta tra 1 e 5 gruppi di sicurezza IDs
Per ulteriori informazioni sulla creazione o l'aggiornamento di un SageMaker HyperPod cluster utilizzando l'interfaccia utente della SageMaker HyperPod console o il AWS CLI:
+ [Orchestrazione Slurm: vedere Operazione dei cluster orchestrati da Slurm. HyperPod](sagemaker-hyperpod-operate-slurm.md)
+ Orchestrazione EKS. [ HyperPodVedi Cluster operativi orchestrati](sagemaker-hyperpod-eks-operate.md) da EKS.
**Nota**
Quando esegui carichi di lavoro su più carichi di lavoro AZs, tieni presente che la comunicazione di rete tra di loro introduce una latenza aggiuntiva. AZs Considera questo fattore quando progetti applicazioni sensibili alla latenza.
## Configurazione AWS Systems Manager ed esecuzione come per il controllo degli accessi degli utenti del cluster
[SageMaker HyperPod DLAMI](sagemaker-hyperpod-ref.md#sagemaker-hyperpod-ref-hyperpod-ami)viene fornito con [AWS Systems Manager](https://aws.amazon.com/systems-manager/)(SSM) pronto all'uso per aiutarti a gestire l'accesso ai gruppi di istanze SageMaker HyperPod del cluster. Questa sezione descrive come creare utenti del sistema operativo (OS) nei SageMaker HyperPod cluster e associarli a utenti e ruoli IAM. Questa opzione è utile per autenticare le sessioni SSM utilizzando le credenziali dell’account utente del sistema operativo.
**Nota**
La concessione agli utenti dell'accesso ai nodi HyperPod del cluster consente loro di installare e utilizzare software gestito dagli utenti sui nodi. Assicurati di rispettare il principio delle autorizzazioni con privilegio minimo per gli utenti.
### Attivazione di RunAs nel tuo account AWS
In qualità di amministratore AWS dell'account o amministratore del cloud, puoi gestire l'accesso ai SageMaker HyperPod cluster a livello di ruolo o utente IAM utilizzando la [funzionalità Run As di SSM](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-preferences-run-as.html). Con questa funzionalità puoi avviare ogni sessione SSM utilizzando l’utente del sistema operativo associato al ruolo o all’utente IAM.
Per abilitare RunAs nel tuo AWS account, segui la procedura descritta in [Attivare il supporto RunAs per i nodi gestiti Linux e macOS](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-preferences-run-as.html). Se hai già creato utenti del sistema operativo nel tuo cluster, assicurati di associarli a ruoli o utenti IAM taggandoli come indicato nell’**Opzione 2** della Fase 5 in **To turn on Run As support for Linux and macOS managed nodes**.
## (Facoltativo) Configurazione SageMaker HyperPod con Amazon FSx for Lustre
Per iniziare a utilizzare SageMaker HyperPod e mappare i percorsi di dati tra il cluster e il tuo file system FSx for Lustre, seleziona uno dei formati supportati da. Regioni AWS SageMaker HyperPod Dopo aver scelto quella Regione AWS che preferite, dovreste anche determinare quale zona di disponibilità (AZ) utilizzare.
Se si utilizzano nodi di SageMaker HyperPod elaborazione AZs diversi da quelli in AZs cui è configurato il sistema file FSx for Lustre all'interno dello stesso Regione AWS, è possibile che si verifichino problemi di comunicazione e di rete. Ti consigliamo di utilizzare la stessa AZ fisica utilizzata per l'account di SageMaker HyperPod servizio per evitare qualsiasi traffico inter-AZ tra SageMaker HyperPod i cluster e il tuo sistema file for Lustre. FSx Inoltre, assicurati che sia configurato il tuo VPC. Se desideri utilizzare Amazon FSx come file system principale per lo storage, devi configurare SageMaker HyperPod i cluster con il tuo VPC.
# AWS Identity and Access Management per SageMaker HyperPod
AWS Identity and Access Management (IAM) è un AWS servizio che aiuta un amministratore a controllare in modo sicuro l'accesso alle AWS risorse. Gli amministratori IAM controllano chi è *autenticato* (accesso effettuato) e *autorizzato* (dispone di autorizzazioni) a utilizzare risorse Amazon EKS. IAM è un AWS servizio che puoi utilizzare senza costi aggiuntivi.
**Importante**
Le politiche IAM personalizzate che consentono ad Amazon SageMaker Studio o Amazon SageMaker Studio Classic di creare SageMaker risorse Amazon devono inoltre concedere le autorizzazioni per aggiungere tag a tali risorse. L’autorizzazione per aggiungere tag alle risorse è necessaria perché Studio e Studio Classic applicano automaticamente tag a tutte le risorse che creano. Se una policy IAM consente a Studio e Studio Classic di creare risorse ma non consente l'etichettatura, possono verificarsi errori AccessDenied "" durante il tentativo di creare risorse. Per ulteriori informazioni, consulta [Fornisci le autorizzazioni per etichettare SageMaker le risorse AI](security_iam_id-based-policy-examples.md#grant-tagging-permissions).
[AWS politiche gestite per Amazon SageMaker AI](security-iam-awsmanpol.md)che danno i permessi per creare SageMaker risorse includono già le autorizzazioni per aggiungere tag durante la creazione di tali risorse.
Supponiamo che vi siano due livelli principali di SageMaker HyperPod utenti: utenti *amministratori del cluster e utenti* di *data scientist*.
+ **Utenti amministratori del cluster**: sono responsabili della creazione e della gestione dei SageMaker HyperPod cluster. Ciò include la configurazione dei HyperPod cluster e la gestione dell'accesso degli utenti ad essi.
+ Crea e configura SageMaker HyperPod cluster con Slurm o Amazon EKS.
+ Crea e configura ruoli IAM per gli utenti dei data scientist e HyperPod le risorse del cluster.
+ Per l' SageMaker HyperPod orchestrazione con Amazon EKS, crea e configura [voci di accesso EKS](https://docs.aws.amazon.com/eks/latest/userguide/access-entries.html), [controllo degli accessi basato sui ruoli (RBAC)](sagemaker-hyperpod-eks-setup-rbac.md) e Pod Identity per soddisfare i casi d'uso della scienza dei dati.
+ **Utenti Data Scientist**: si occupano dell’addestramento dei modelli di ML. Usano l'orchestrator open source o la CLI per inviare e gestire SageMaker HyperPod i lavori di formazione.
+ Assumi e utilizza il ruolo IAM fornito dagli utenti amministratori del cluster.
+ Interagisci con l'orchestrator open source CLIs supportato da SageMaker HyperPod (Slurm o Kubernetes) o la SageMaker HyperPod CLI per verificare la capacità dei cluster, connetterti al cluster e inviare carichi di lavoro.
Configura i ruoli IAM per gli amministratori dei cluster associando le autorizzazioni o le politiche corrette per gestire i cluster. SageMaker HyperPod Gli amministratori dei cluster devono inoltre creare ruoli IAM per fornire SageMaker HyperPod le risorse necessarie all'esecuzione e alla comunicazione con AWS le risorse necessarie, come Amazon S3 AWS Systems Manager , CloudWatch Amazon e (SSM). Infine, l'amministratore dell' AWS account o gli amministratori del cluster devono concedere agli scienziati le autorizzazioni per accedere ai cluster ed eseguire carichi di lavoro ML. SageMaker HyperPod
A seconda dell’orchestratore scelto, le autorizzazioni necessarie per l’amministratore del cluster e i Data Scientist possono variare. Puoi anche controllare l’ambito delle autorizzazioni per varie azioni nei ruoli utilizzando le chiavi di condizione per ogni servizio. Utilizza i seguenti riferimenti di autorizzazione ai servizi per aggiungere un ambito dettagliato per i servizi correlati a. SageMaker HyperPod
+ [Amazon Elastic Compute Cloud](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonec2.html)
+ [Amazon Elastic Container Registry](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelasticcontainerregistry.html) (per l'orchestrazione dei SageMaker HyperPod cluster con Amazon EKS)
+ [Amazon Elastic Kubernetes](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html) Service (per l'orchestrazione dei SageMaker HyperPod cluster con Amazon EKS)
+ [Amazon FSx](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonfsx.html)
+ [AWS IAM Identity Center (successore di Single Sign-On) AWS](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsiamidentitycentersuccessortoawssinglesign-on.html)
+ [AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsidentityandaccessmanagementiam.html)
+ [Amazon Simple Storage Service](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazons3.html)
+ [Amazon SageMaker AI](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonsagemaker.html)
+ [AWS Systems Manager](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awssystemsmanager.html)
**Topics**
+ [Autorizzazioni IAM per la creazione di cluster](#sagemaker-hyperpod-prerequisites-iam-cluster-creation)
+ [Utenti IAM per l’amministratore del cluster](#sagemaker-hyperpod-prerequisites-iam-cluster-admin)
+ [Utenti IAM per Data Scientist](#sagemaker-hyperpod-prerequisites-iam-cluster-user)
+ [Ruolo IAM per SageMaker HyperPod](#sagemaker-hyperpod-prerequisites-iam-role-for-hyperpod)
## Autorizzazioni IAM per la creazione di cluster
La creazione di HyperPod cluster richiede le autorizzazioni IAM descritte nel seguente esempio di policy. Se Account AWS disponi [https://docs.aws.amazon.com//aws-managed-policy/latest/reference/AdministratorAccess.html](https://docs.aws.amazon.com//aws-managed-policy/latest/reference/AdministratorAccess.html)delle autorizzazioni, queste vengono concesse per impostazione predefinita.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"sagemaker:CreateCluster",
"sagemaker:DeleteCluster",
"sagemaker:UpdateCluster"
],
"Resource": "arn:aws:sagemaker:*:*:cluster/*"
},
{
"Effect": "Allow",
"Action": [
"sagemaker:AddTags"
],
"Resource": "arn:aws:sagemaker:*:*:cluster/*"
},
{
"Effect": "Allow",
"Action": [
"sagemaker:ListTags",
"sagemaker:ListClusters",
"sagemaker:ListClusterNodes",
"sagemaker:ListComputeQuotas",
"sagemaker:ListTrainingPlans",
"sagemaker:DescribeCluster",
"sagemaker:DescribeClusterNode"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"cloudformation:CreateStack",
"cloudformation:UpdateStack",
"cloudformation:DeleteStack",
"cloudformation:ContinueUpdateRollback",
"cloudformation:SetStackPolicy",
"cloudformation:ValidateTemplate",
"cloudformation:DescribeStacks",
"cloudformation:DescribeStackEvents",
"cloudformation:Get*",
"cloudformation:List*"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "arn:aws:iam::*:role/sagemaker-*",
"Condition": {
"StringEquals": {
"iam:PassedToService": [
"sagemaker.amazonaws.com",
"eks.amazonaws.com",
"lambda.amazonaws.com"
]
}
}
},
{
"Effect": "Allow",
"Action": [
"iam:PassRole",
"iam:GetRole"
],
"Resource": "arn:aws:iam::*:role/*",
"Condition": {
"StringEquals": {
"iam:PassedToService": [
"sagemaker.amazonaws.com",
"eks.amazonaws.com",
"lambda.amazonaws.com",
"cloudformation.amazonaws.com"
]
}
}
},
{
"Sid": "AmazonVPCFullAccess",
"Effect": "Allow",
"Action": [
"ec2:AcceptVpcPeeringConnection",
"ec2:AcceptVpcEndpointConnections",
"ec2:AllocateAddress",
"ec2:AssignIpv6Addresses",
"ec2:AssignPrivateIpAddresses",
"ec2:AssociateAddress",
"ec2:AssociateDhcpOptions",
"ec2:AssociateRouteTable",
"ec2:AssociateSecurityGroupVpc",
"ec2:AssociateSubnetCidrBlock",
"ec2:AssociateVpcCidrBlock",
"ec2:AttachClassicLinkVpc",
"ec2:AttachInternetGateway",
"ec2:AttachNetworkInterface",
"ec2:AttachVpnGateway",
"ec2:AuthorizeSecurityGroupEgress",
"ec2:AuthorizeSecurityGroupIngress",
"ec2:CreateCarrierGateway",
"ec2:CreateCustomerGateway",
"ec2:CreateDefaultSubnet",
"ec2:CreateDefaultVpc",
"ec2:CreateDhcpOptions",
"ec2:CreateEgressOnlyInternetGateway",
"ec2:CreateFlowLogs",
"ec2:CreateInternetGateway",
"ec2:CreateLocalGatewayRouteTableVpcAssociation",
"ec2:CreateNatGateway",
"ec2:CreateNetworkAcl",
"ec2:CreateNetworkAclEntry",
"ec2:CreateNetworkInterface",
"ec2:CreateNetworkInterfacePermission",
"ec2:CreateRoute",
"ec2:CreateRouteTable",
"ec2:CreateSecurityGroup",
"ec2:CreateSubnet",
"ec2:CreateTags",
"ec2:CreateVpc",
"ec2:CreateVpcEndpoint",
"ec2:CreateVpcEndpointConnectionNotification",
"ec2:CreateVpcEndpointServiceConfiguration",
"ec2:CreateVpcPeeringConnection",
"ec2:CreateVpnConnection",
"ec2:CreateVpnConnectionRoute",
"ec2:CreateVpnGateway",
"ec2:DeleteCarrierGateway",
"ec2:DeleteCustomerGateway",
"ec2:DeleteDhcpOptions",
"ec2:DeleteEgressOnlyInternetGateway",
"ec2:DeleteFlowLogs",
"ec2:DeleteInternetGateway",
"ec2:DeleteLocalGatewayRouteTableVpcAssociation",
"ec2:DeleteNatGateway",
"ec2:DeleteNetworkAcl",
"ec2:DeleteNetworkAclEntry",
"ec2:DeleteNetworkInterface",
"ec2:DeleteNetworkInterfacePermission",
"ec2:DeleteRoute",
"ec2:DeleteRouteTable",
"ec2:DeleteSecurityGroup",
"ec2:DeleteSubnet",
"ec2:DeleteTags",
"ec2:DeleteVpc",
"ec2:DeleteVpcEndpoints",
"ec2:DeleteVpcEndpointConnectionNotifications",
"ec2:DeleteVpcEndpointServiceConfigurations",
"ec2:DeleteVpcPeeringConnection",
"ec2:DeleteVpnConnection",
"ec2:DeleteVpnConnectionRoute",
"ec2:DeleteVpnGateway",
"ec2:DescribeAccountAttributes",
"ec2:DescribeAddresses",
"ec2:DescribeAvailabilityZones",
"ec2:DescribeCarrierGateways",
"ec2:DescribeClassicLinkInstances",
"ec2:DescribeCustomerGateways",
"ec2:DescribeDhcpOptions",
"ec2:DescribeEgressOnlyInternetGateways",
"ec2:DescribeFlowLogs",
"ec2:DescribeInstances",
"ec2:DescribeInternetGateways",
"ec2:DescribeIpv6Pools",
"ec2:DescribeLocalGatewayRouteTables",
"ec2:DescribeLocalGatewayRouteTableVpcAssociations",
"ec2:DescribeKeyPairs",
"ec2:DescribeMovingAddresses",
"ec2:DescribeNatGateways",
"ec2:DescribeNetworkAcls",
"ec2:DescribeNetworkInterfaceAttribute",
"ec2:DescribeNetworkInterfacePermissions",
"ec2:DescribeNetworkInterfaces",
"ec2:DescribePrefixLists",
"ec2:DescribeRouteTables",
"ec2:DescribeSecurityGroupReferences",
"ec2:DescribeSecurityGroupRules",
"ec2:DescribeSecurityGroups",
"ec2:DescribeSecurityGroupVpcAssociations",
"ec2:DescribeStaleSecurityGroups",
"ec2:DescribeSubnets",
"ec2:DescribeTags",
"ec2:DescribeVpcAttribute",
"ec2:DescribeVpcClassicLink",
"ec2:DescribeVpcClassicLinkDnsSupport",
"ec2:DescribeVpcEndpointConnectionNotifications",
"ec2:DescribeVpcEndpointConnections",
"ec2:DescribeVpcEndpoints",
"ec2:DescribeVpcEndpointServiceConfigurations",
"ec2:DescribeVpcEndpointServicePermissions",
"ec2:DescribeVpcEndpointServices",
"ec2:DescribeVpcPeeringConnections",
"ec2:DescribeVpcs",
"ec2:DescribeVpnConnections",
"ec2:DescribeVpnGateways",
"ec2:DetachClassicLinkVpc",
"ec2:DetachInternetGateway",
"ec2:DetachNetworkInterface",
"ec2:DetachVpnGateway",
"ec2:DisableVgwRoutePropagation",
"ec2:DisableVpcClassicLink",
"ec2:DisableVpcClassicLinkDnsSupport",
"ec2:DisassociateAddress",
"ec2:DisassociateRouteTable",
"ec2:DisassociateSecurityGroupVpc",
"ec2:DisassociateSubnetCidrBlock",
"ec2:DisassociateVpcCidrBlock",
"ec2:EnableVgwRoutePropagation",
"ec2:EnableVpcClassicLink",
"ec2:EnableVpcClassicLinkDnsSupport",
"ec2:GetSecurityGroupsForVpc",
"ec2:ModifyNetworkInterfaceAttribute",
"ec2:ModifySecurityGroupRules",
"ec2:ModifySubnetAttribute",
"ec2:ModifyVpcAttribute",
"ec2:ModifyVpcEndpoint",
"ec2:ModifyVpcEndpointConnectionNotification",
"ec2:ModifyVpcEndpointServiceConfiguration",
"ec2:ModifyVpcEndpointServicePermissions",
"ec2:ModifyVpcPeeringConnectionOptions",
"ec2:ModifyVpcTenancy",
"ec2:MoveAddressToVpc",
"ec2:RejectVpcEndpointConnections",
"ec2:RejectVpcPeeringConnection",
"ec2:ReleaseAddress",
"ec2:ReplaceNetworkAclAssociation",
"ec2:ReplaceNetworkAclEntry",
"ec2:ReplaceRoute",
"ec2:ReplaceRouteTableAssociation",
"ec2:ResetNetworkInterfaceAttribute",
"ec2:RestoreAddressToClassic",
"ec2:RevokeSecurityGroupEgress",
"ec2:RevokeSecurityGroupIngress",
"ec2:UnassignIpv6Addresses",
"ec2:UnassignPrivateIpAddresses",
"ec2:UpdateSecurityGroupRuleDescriptionsEgress",
"ec2:UpdateSecurityGroupRuleDescriptionsIngress"
],
"Resource": "*"
},
{
"Sid": "CloudWatchPermissions",
"Effect": "Allow",
"Action": [
"cloudwatch:*",
"logs:*",
"sns:CreateTopic",
"sns:ListSubscriptions",
"sns:ListSubscriptionsByTopic",
"sns:ListTopics",
"sns:Subscribe",
"iam:GetPolicy",
"iam:GetPolicyVersion",
"iam:GetRole",
"oam:ListSinks",
"rum:*",
"synthetics:*",
"xray:*"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"s3:CreateBucket",
"s3:DeleteBucket",
"s3:PutBucketPolicy",
"s3:PutBucketTagging",
"s3:PutBucketPublicAccessBlock",
"s3:PutBucketLogging",
"s3:DeleteBucketPolicy",
"s3:PutObject",
"s3:DeleteObject",
"s3:PutEncryptionConfiguration",
"s3:AbortMultipartUpload",
"s3:Get*",
"s3:List*"
],
"Resource": [
"arn:aws:s3:::*",
"arn:aws:s3:::*/*"
]
},
{
"Effect": "Allow",
"Action": [
"eks:CreateCluster",
"eks:DeleteCluster",
"eks:CreateNodegroup",
"eks:DeleteNodegroup",
"eks:UpdateNodegroupConfig",
"eks:UpdateNodegroupVersion",
"eks:UpdateClusterConfig",
"eks:UpdateClusterVersion",
"eks:CreateFargateProfile",
"eks:DeleteFargateProfile",
"eks:CreateAddon",
"eks:DeleteAddon",
"eks:UpdateAddon",
"eks:CreateAccessEntry",
"eks:DeleteAccessEntry",
"eks:UpdateAccessEntry",
"eks:AssociateAccessPolicy",
"eks:AssociateIdentityProviderConfig",
"eks:DisassociateIdentityProviderConfig",
"eks:TagResource",
"eks:UntagResource",
"eks:AccessKubernetesApi",
"eks:Describe*",
"eks:List*"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ssm:GetParameter",
"ssm:PutParameter",
"ssm:DeleteParameter",
"ssm:DescribeParameters"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"kms:Decrypt",
"kms:GenerateDataKey"
],
"Resource": "*",
"Condition": {
"StringLike": {
"kms:ViaService": [
"sagemaker.*.amazonaws.com",
"ec2.*.amazonaws.com",
"s3.*.amazonaws.com",
"eks.*.amazonaws.com"
]
}
}
},
{
"Effect": "Allow",
"Action": [
"lambda:CreateFunction",
"lambda:DeleteFunction",
"lambda:GetFunction",
"lambda:UpdateFunctionCode",
"lambda:UpdateFunctionConfiguration",
"lambda:AddPermission",
"lambda:RemovePermission",
"lambda:PublishLayerVersion",
"lambda:DeleteLayerVersion",
"lambda:InvokeFunction",
"lambda:Get*",
"lambda:List*",
"lambda:TagResource"
],
"Resource": [
"arn:aws:lambda:*:*:function:*",
"arn:aws:lambda:*:*:layer:*"
]
},
{
"Effect": "Allow",
"Action": [
"iam:DeleteRole",
"iam:DeleteRolePolicy"
],
"Resource": [
"arn:aws:iam::*:role/*sagemaker*",
"arn:aws:iam::*:role/*eks*",
"arn:aws:iam::*:role/*hyperpod*",
"arn:aws:iam::*:policy/*sagemaker*",
"arn:aws:iam::*:policy/*hyperpod*",
"arn:aws:iam::*:role/*LifeCycleScriptStack*",
"arn:aws:iam::*:role/*LifeCycleScript*"
]
},
{
"Effect": "Allow",
"Action": [
"iam:CreateRole",
"iam:TagRole",
"iam:PutRolePolicy",
"iam:Get*",
"iam:List*",
"iam:AttachRolePolicy",
"iam:DetachRolePolicy"
],
"Resource": [
"arn:aws:iam::*:role/*",
"arn:aws:iam::*:policy/*"
]
},
{
"Sid": "FullAccessToFSx",
"Effect": "Allow",
"Action": [
"fsx:AssociateFileGateway",
"fsx:AssociateFileSystemAliases",
"fsx:CancelDataRepositoryTask",
"fsx:CopyBackup",
"fsx:CopySnapshotAndUpdateVolume",
"fsx:CreateAndAttachS3AccessPoint",
"fsx:CreateBackup",
"fsx:CreateDataRepositoryAssociation",
"fsx:CreateDataRepositoryTask",
"fsx:CreateFileCache",
"fsx:CreateFileSystem",
"fsx:CreateFileSystemFromBackup",
"fsx:CreateSnapshot",
"fsx:CreateStorageVirtualMachine",
"fsx:CreateVolume",
"fsx:CreateVolumeFromBackup",
"fsx:DetachAndDeleteS3AccessPoint",
"fsx:DeleteBackup",
"fsx:DeleteDataRepositoryAssociation",
"fsx:DeleteFileCache",
"fsx:DeleteFileSystem",
"fsx:DeleteSnapshot",
"fsx:DeleteStorageVirtualMachine",
"fsx:DeleteVolume",
"fsx:DescribeAssociatedFileGateways",
"fsx:DescribeBackups",
"fsx:DescribeDataRepositoryAssociations",
"fsx:DescribeDataRepositoryTasks",
"fsx:DescribeFileCaches",
"fsx:DescribeFileSystemAliases",
"fsx:DescribeFileSystems",
"fsx:DescribeS3AccessPointAttachments",
"fsx:DescribeSharedVpcConfiguration",
"fsx:DescribeSnapshots",
"fsx:DescribeStorageVirtualMachines",
"fsx:DescribeVolumes",
"fsx:DisassociateFileGateway",
"fsx:DisassociateFileSystemAliases",
"fsx:ListTagsForResource",
"fsx:ManageBackupPrincipalAssociations",
"fsx:ReleaseFileSystemNfsV3Locks",
"fsx:RestoreVolumeFromSnapshot",
"fsx:TagResource",
"fsx:UntagResource",
"fsx:UpdateDataRepositoryAssociation",
"fsx:UpdateFileCache",
"fsx:UpdateFileSystem",
"fsx:UpdateSharedVpcConfiguration",
"fsx:UpdateSnapshot",
"fsx:UpdateStorageVirtualMachine",
"fsx:UpdateVolume"
],
"Resource": "*"
}
]
}
```
------
## Utenti IAM per l’amministratore del cluster
Gli amministratori dei cluster (amministratori) gestiscono e configurano i SageMaker HyperPod cluster, eseguendo le attività in essi contenute. [SageMaker HyperPod Operazioni del cluster Slurm](sagemaker-hyperpod-operate-slurm.md) Il seguente esempio di policy include il set minimo di autorizzazioni per gli amministratori del cluster per eseguire il SageMaker HyperPod core APIs e gestire i cluster all'interno dell'account. SageMaker HyperPod AWS
**Nota**
Gli utenti IAM con ruoli di amministratore del cluster possono utilizzare le chiavi di condizione per fornire un controllo granulare degli accessi durante la gestione delle risorse SageMaker HyperPod del cluster specificamente per le azioni e. `CreateCluster` `UpdateCluster` Per trovare le chiavi di condizione supportate per queste azioni, cerca `CreateCluster` o `UpdateCluster` nelle [Azioni definite dall' SageMaker IA](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonsagemaker.html#amazonsagemaker-actions-as-permissions).
------
#### [ Slurm ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"sagemaker:CreateCluster",
"sagemaker:ListClusters"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"sagemaker:DeleteCluster",
"sagemaker:DescribeCluster",
"sagemaker:DescribeClusterNode",
"sagemaker:ListClusterNodes",
"sagemaker:UpdateCluster",
"sagemaker:UpdateClusterSoftware",
"sagemaker:BatchDeleteClusterNodes"
],
"Resource": "arn:aws:sagemaker:us-east-1:111122223333:cluster/*"
}
]
}
```
------
#### [ Amazon EKS ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "arn:aws:iam::111122223333:role/execution-role-name"
},
{
"Effect": "Allow",
"Action": [
"sagemaker:CreateCluster",
"sagemaker:DeleteCluster",
"sagemaker:DescribeCluster",
"sagemaker:DescribeClusterNode",
"sagemaker:ListClusterNodes",
"sagemaker:ListClusters",
"sagemaker:UpdateCluster",
"sagemaker:UpdateClusterSoftware",
"sagemaker:BatchAddClusterNodes",
"sagemaker:BatchDeleteClusterNodes",
"sagemaker:ListComputeQuotas",
"sagemaker:ListClusterSchedulerConfigs",
"sagemaker:DeleteClusterSchedulerConfig",
"sagemaker:DeleteComputeQuota",
"eks:DescribeCluster",
"eks:CreateAccessEntry",
"eks:DescribeAccessEntry",
"eks:DeleteAccessEntry",
"eks:AssociateAccessPolicy",
"iam:CreateServiceLinkedRole"
],
"Resource": "*"
}
]
}
```
------
Per concedere le autorizzazioni di accesso alla console di SageMaker intelligenza artificiale, utilizza la policy di esempio fornita in [Autorizzazioni necessarie per utilizzare la console Amazon SageMaker AI](https://docs.aws.amazon.com/sagemaker/latest/dg/security_iam_id-based-policy-examples.html#console-permissions).
*Per concedere le autorizzazioni di accesso alla console Amazon EC2 Systems Manager, utilizza la policy di esempio fornita [in Uso AWS Systems Manager della console nella AWS Systems Manager Guida per l'](https://docs.aws.amazon.com/systems-manager/latest/userguide/security_iam_id-based-policy-examples.html#security_iam_id-based-policy-examples-console)utente.*
Potresti anche considerare di associare la [`AmazonSageMakerFullAccess`](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonSageMakerFullAccess)policy al ruolo; tuttavia, tieni presente che la `AmazonSageMakerFullAccess` policy concede le autorizzazioni per tutte le chiamate, le funzionalità e le SageMaker risorse dell'API.
Per indicazioni generali sugli utenti IAM, consulta [IAM users](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html) in *AWS Identity and Access Management User Guide*.
## Utenti IAM per Data Scientist
Gli scienziati accedono ed eseguono carichi di lavoro ML su nodi del cluster forniti dagli SageMaker HyperPod amministratori del cluster. Agli scienziati del tuo AWS account, devi concedere l'autorizzazione `"ssm:StartSession"` a eseguire il comando SSM. `start-session` Di seguito è riportata una policy di esempio per gli utenti IAM.
------
#### [ Slurm ]
Aggiungi la policy seguente per concedere a un utente IAM le autorizzazioni di sessione SSM per connettersi a una destinazione SSM. Ciò consente di accedere ai HyperPod cluster.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:StartSession",
"ssm:TerminateSession"
],
"Resource": "*"
}
]
}
```
------
------
#### [ Amazon EKS ]
Concedi le seguenti autorizzazioni di ruolo IAM ai data scientist per l'esecuzione `hyperpod list-clusters` e `hyperpod connect-cluster` i comandi tra i comandi HyperPod CLI. Per ulteriori informazioni sulla HyperPod CLI, consulta. [Esecuzione di processi su SageMaker HyperPod cluster orchestrati da Amazon EKS](sagemaker-hyperpod-eks-run-jobs.md) Include anche le autorizzazioni di sessione SSM per la connessione a una destinazione SSM per tutte le risorse. Ciò consente di accedere ai HyperPod cluster.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DescribeHyerpodClusterPermissions",
"Effect": "Allow",
"Action": [
"sagemaker:DescribeCluster"
],
"Resource": "arn:aws:sagemaker:us-east-2:111122223333:cluster/hyperpod-cluster-name"
},
{
"Sid": "UseEksClusterPermissions",
"Effect": "Allow",
"Action": [
"eks:DescribeCluster"
],
"Resource": "arn:aws:sagemaker:us-east-2:111122223333:cluster/eks-cluster-name"
},
{
"Sid": "ListClustersPermission",
"Effect": "Allow",
"Action": [
"sagemaker:ListClusters"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ssm:StartSession",
"ssm:TerminateSession"
],
"Resource": "*"
}
]
}
```
------
*Per concedere ai data scientist l'accesso a utenti o ruoli IAM a Kubernetes APIs nel cluster, consulta anche [Concedere a utenti e ruoli IAM l'accesso a Kubernetes APIs](https://docs.aws.amazon.com/eks/latest/userguide/grant-k8s-access.html) nella Amazon EKS User Guide.*
------
## Ruolo IAM per SageMaker HyperPod
SageMaker HyperPod Affinché i cluster possano funzionare e comunicare con AWS le risorse necessarie, è necessario creare un ruolo IAM da far assumere al HyperPod cluster.
Inizia collegando la [AWS politica gestita: AmazonSageMakerHyperPodServiceRolePolicy](security-iam-awsmanpol-AmazonSageMakerHyperPodServiceRolePolicy.md) del ruolo gestito. In base AWS a questa politica gestita, i gruppi di istanze del SageMaker HyperPod cluster assumono il ruolo di comunicare con Amazon CloudWatch, Amazon S3 e AWS Systems Manager Agent (agente SSM). Questa policy gestita è il requisito minimo per il corretto funzionamento SageMaker HyperPod delle risorse, quindi è necessario fornire un ruolo IAM con questa policy a tutti i gruppi di istanze.
**Suggerimento**
A seconda delle preferenze in merito alla progettazione del livello di autorizzazioni per più gruppi di istanze, puoi anche configurare più ruoli IAM e collegarli a diversi gruppi di istanze. Quando configuri l'accesso utente del cluster a nodi specifici del SageMaker HyperPod cluster, i nodi assumono il ruolo con le autorizzazioni selettive assegnate manualmente.
Quando configuri l’accesso per i Data Scientist a nodi specifici del cluster con [AWS Systems Manager](https://aws.amazon.com/systems-manager/) (vedi anche [Configurazione AWS Systems Manager ed esecuzione come per il controllo degli accessi degli utenti del cluster](sagemaker-hyperpod-prerequisites.md#sagemaker-hyperpod-prerequisites-ssm)), i nodi del cluster assumono il ruolo con le autorizzazioni selettive assegnate manualmente.
Dopo aver creato i ruoli IAM, prendi nota dei loro nomi e. ARNs I ruoli vengono utilizzati durante la creazione di un SageMaker HyperPod cluster, concedendo le autorizzazioni corrette richieste a ciascun gruppo di istanze per comunicare con le risorse necessarie AWS .
------
#### [ Slurm ]
In caso di HyperPod orchestrazione con Slurm, è necessario allegare la seguente policy gestita al ruolo IAM. SageMaker HyperPod
+ [AmazonSageMakerClusterInstanceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonSageMakerClusterInstanceRolePolicy.html)
**(Facoltativo) Autorizzazioni aggiuntive per l'utilizzo SageMaker HyperPod con Amazon Virtual Private Cloud**
Se desideri utilizzare il tuo Amazon Virtual Private Cloud (VPC) al posto del tuo SageMaker VPC AI predefinito, devi aggiungere le seguenti autorizzazioni aggiuntive al ruolo IAM per. SageMaker HyperPod
```
{
"Effect": "Allow",
"Action": [
"ec2:CreateNetworkInterface",
"ec2:CreateNetworkInterfacePermission",
"ec2:DeleteNetworkInterface",
"ec2:DeleteNetworkInterfacePermission",
"ec2:DescribeNetworkInterfaces",
"ec2:DescribeVpcs",
"ec2:DescribeDhcpOptions",
"ec2:DescribeSubnets",
"ec2:DescribeSecurityGroups",
"ec2:DetachNetworkInterface"
],
"Resource": "*"
}
{
"Effect": "Allow",
"Action": "ec2:CreateTags",
"Resource": [
"arn:aws:ec2:*:*:network-interface/*"
]
}
```
L'elenco seguente riporta le autorizzazioni necessarie per abilitare le funzionalità SageMaker HyperPod del cluster quando configuri il cluster con il tuo Amazon VPC personale.
+ Le seguenti `ec2` autorizzazioni sono necessarie per abilitare la configurazione di un SageMaker HyperPod cluster con il tuo VPC.
```
{
"Effect": "Allow",
"Action": [
"ec2:CreateNetworkInterface",
"ec2:CreateNetworkInterfacePermission",
"ec2:DeleteNetworkInterface",
"ec2:DeleteNetworkInterfacePermission",
"ec2:DescribeNetworkInterfaces",
"ec2:DescribeVpcs",
"ec2:DescribeDhcpOptions",
"ec2:DescribeSubnets",
"ec2:DescribeSecurityGroups"
],
"Resource": "*"
}
```
+ È necessaria la seguente `ec2` autorizzazione per abilitare la [SageMaker HyperPod funzionalità di ripristino automatico](sagemaker-hyperpod-resiliency-slurm-auto-resume.md).
```
{
"Effect": "Allow",
"Action": [
"ec2:DetachNetworkInterface"
],
"Resource": "*"
}
```
+ La seguente `ec2` autorizzazione consente di SageMaker HyperPod creare tag sulle interfacce di rete all'interno del tuo account.
```
{
"Effect": "Allow",
"Action": "ec2:CreateTags",
"Resource": [
"arn:aws:ec2:*:*:network-interface/*"
]
}
```
------
#### [ Amazon EKS ]
Per l' HyperPod orchestrazione con Amazon EKS, è necessario collegare le seguenti politiche gestite al ruolo SageMaker HyperPod IAM.
+ [AmazonSageMakerClusterInstanceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonSageMakerClusterInstanceRolePolicy.html)
Oltre alle policy gestite, collega la policy di autorizzazione seguente al ruolo.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:AssignPrivateIpAddresses",
"ec2:AttachNetworkInterface",
"ec2:CreateNetworkInterface",
"ec2:CreateNetworkInterfacePermission",
"ec2:DeleteNetworkInterface",
"ec2:DeleteNetworkInterfacePermission",
"ec2:DescribeInstances",
"ec2:DescribeInstanceTypes",
"ec2:DescribeNetworkInterfaces",
"ec2:DescribeTags",
"ec2:DescribeVpcs",
"ec2:DescribeDhcpOptions",
"ec2:DescribeSubnets",
"ec2:DescribeSecurityGroups",
"ec2:DetachNetworkInterface",
"ec2:ModifyNetworkInterfaceAttribute",
"ec2:UnassignPrivateIpAddresses",
"ecr:BatchCheckLayerAvailability",
"ecr:BatchGetImage",
"ecr:GetAuthorizationToken",
"ecr:GetDownloadUrlForLayer",
"eks-auth:AssumeRoleForPodIdentity"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ec2:CreateTags"
],
"Resource": [
"arn:aws:ec2:*:*:network-interface/*"
]
}
]
}
```
------
**Nota**
L’autorizzazione `"eks-auth:AssumeRoleForPodIdentity"` è facoltativa. È necessaria se prevedi di utilizzare EKS Pod Identity.
**SageMaker HyperPod ruolo collegato al servizio**
Per il supporto di Amazon EKS in SageMaker HyperPod, HyperPod crea un ruolo collegato ai servizi [AWS politica gestita: AmazonSageMakerHyperPodServiceRolePolicy](security-iam-awsmanpol-AmazonSageMakerHyperPodServiceRolePolicy.md) per monitorare e supportare la resilienza sul cluster EKS, ad esempio la sostituzione dei nodi e il riavvio dei lavori.
**Policy IAM aggiuntive per i cluster Amazon EKS con Gruppo di istanze limitato (RIG)**
I carichi di lavoro eseguiti in gruppi di istanze limitati si basano sul ruolo di esecuzione per caricare i dati da Amazon S3. Devi aggiungere le altre autorizzazioni Amazon S3 al ruolo di esecuzione in modo che i processi di personalizzazione in esecuzione nei gruppi di istanze limitati possano recuperare correttamente i dati di input.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket"
]
},
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject",
"s3:DeleteObject"
],
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket/*"
]
}
]
}
```
------
------
# AWS KMS key Crittografia gestita dal cliente per SageMaker HyperPod
Per impostazione predefinita, il volume root Amazon EBS collegato al SageMaker HyperPod cluster viene crittografato utilizzando un file AWS KMS key di proprietà di AWS. Ora hai la possibilità di crittografare sia il volume root Amazon EBS che il volume secondario con le chiavi KMS gestite dal cliente. L'argomento seguente descrive come funzionano le chiavi gestite dai clienti (CMKs) con i volumi nei HyperPod cluster.
**Nota**
Le seguenti esclusioni si applicano all'utilizzo di chiavi gestite dal cliente per i SageMaker HyperPod cluster:
La crittografia con chiave gestita dal cliente è supportata solo per i cluster che utilizzano la modalità di provisioning continuo dei nodi. I gruppi di istanze limitati non supportano le chiavi gestite dal cliente.
HyperPod i cluster attualmente non supportano il passaggio del contesto di crittografia nelle richieste di AWS KMS crittografia a chiave gestite dal cliente. Pertanto, assicurati che la policy della chiave KMS non sia limitata da condizioni basate sul contesto di crittografia, perché ciò impedirebbe al cluster di utilizzare la chiave.
La transizione delle chiavi KMS non è attualmente supportata, quindi non puoi modificare la chiave KMS specificata nella tua configurazione. Per utilizzare una chiave diversa, crea un nuovo gruppo di istanze con la chiave desiderata ed elimina quello precedente.
La specificazione delle chiavi gestite dal cliente per HyperPod i cluster tramite la console non è attualmente supportata.
## Permissions
Prima di poter utilizzare la chiave gestita dal cliente con HyperPod, è necessario completare i seguenti prerequisiti:
+ Assicurati che al ruolo di esecuzione AWS IAM che stai utilizzando per l' SageMaker IA siano aggiunte le seguenti autorizzazioni. AWS KMS L'`[ kms:CreateGrant](https://docs.aws.amazon.com/kms/latest/APIReference/API_CreateGrant.html)`autorizzazione consente di HyperPod eseguire le seguenti azioni utilizzando le autorizzazioni per la tua chiave KMS:
+ Ridimensionamento del numero di istanze (operazioni) UpdateCluster
+ Aggiungere nodi del cluster (BatchAddClusterNodes operazioni)
+ Software di applicazione di patch (UpdateClusterSoftware operazioni)
Per ulteriori informazioni sull’aggiornamento delle autorizzazioni per il ruolo IAM, consulta [Adding and removing IAM identity permissions](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html) nella *Guida per l’utente di IAM*.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"kms:CreateGrant",
"kms:DescribeKey"
],
"Resource": "*"
}
]
}
```
------
+ Aggiungi le autorizzazioni seguenti alla tua policy della chiave KMS. Per ulteriori informazioni, consulta [Change a key policy](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-modifying.html) in *AWS KMS Developer Guide*.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Id": "hyperpod-key-policy",
"Statement": [
{
"Sid": "Enable IAM User Permissions",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:root"
},
"Action": "kms:*",
"Resource": "*"
},
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:role/"
},
"Action": "kms:CreateGrant",
"Resource": "arn:aws:kms:us-east-1:111122223333:key/key-id",
"Condition": {
"StringEquals": {
"kms:ViaService": "sagemaker.us-east-1.amazonaws.com"
},
"Bool": {
"kms:GrantIsForAWSResource": "true"
}
}
},
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:role/"
},
"Action": "kms:DescribeKey",
"Resource": "arn:aws:kms:us-east-1:111122223333:key/key-id",
"Condition": {
"StringEquals": {
"kms:ViaService": "sagemaker.us-east-1.amazonaws.com"
}
}
}
]
}
```
------
## Come utilizzare la chiave KMS
È possibile specificare le chiavi gestite dal cliente durante la creazione o l'aggiornamento di un cluster utilizzando le operazioni [CreateCluster](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_CreateCluster.html)e le [UpdateCluster](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_UpdateCluster.html)API. La struttura `InstanceStorageConfigs` consente fino a due configurazioni `EbsVolumeConfig`, in cui è possibile configurare il volume root Amazon EBS e, facoltativamente, un volume secondario. Puoi utilizzare la stessa chiave KMS o una chiave KMS diversa per ogni volume, a seconda delle esigenze.
Puoi scegliere di specificare una chiave gestita dal cliente per nessuno, entrambi o uno solo dei volumi. Tuttavia, non puoi specificare due volumi root o due volumi secondari.
Durante la configurazione del volume root, si applicano i seguenti requisiti:
+ `RootVolume` deve essere impostato su `True`. Il valore predefinito è `False`, che configura il volume secondario.
+ Il campo `VolumeKmsKeyId` è obbligatorio ed è necessario specificare la chiave gestita dal cliente. Questo perché il volume root deve essere sempre crittografato con una chiave AWS proprietaria o una chiave gestita dal cliente (se non si specifica la propria, viene utilizzata una chiave AWS proprietaria).
+ Non è possibile specificare il `VolumeSizeInGB` campo per i volumi root poiché HyperPod determina automaticamente la dimensione del volume principale.
Durante la configurazione del volume secondario, si applicano i seguenti requisiti:
+ `RootVolume` deve essere `False` (il valore predefinito di questo campo è `False`).
+ Il campo `VolumeKmsKeyId` è facoltativo. Puoi utilizzare la stessa chiave gestita dal cliente specificata per il volume root oppure una chiave diversa.
+ Il campo `VolumeSizeInGB` è obbligatorio perché è necessario specificare la dimensione desiderata per il volume secondario.
**Importante**
Quando utilizzi le chiavi gestite dal cliente, ti consigliamo vivamente di utilizzare chiavi KMS diverse per ogni gruppo di istanze del cluster. L’utilizzo della stessa chiave gestita dal cliente in più gruppi di istanze potrebbe concedere autorizzazioni continuative involontarie anche se provi a revocare una concessione. Ad esempio, se revocate una AWS KMS concessione per i volumi di un gruppo di istanze, quel gruppo di istanze potrebbe comunque consentire operazioni di ridimensionamento e applicazione di patch a causa delle concessioni esistenti su altri gruppi di istanze che utilizzano la stessa chiave. Per evitare questo problema, assicurati di assegnare chiavi KMS univoche a ciascun gruppo di istanze del cluster. Se devi limitare le autorizzazioni sui gruppi di istanze, prova una delle seguenti opzioni:
Disabilita la chiave KMS.
Applica le policy di rifiuto alla policy della chiave KMS.
Revoca tutte le concessioni del gruppo di istanze per la chiave (invece di revocare una sola concessione).
Elimina il gruppo di istanze.
Elimina il cluster.
Gli esempi seguenti mostrano come specificare le chiavi gestite dal cliente per i volumi root e secondari utilizzando and. CreateCluster UpdateCluster APIs Questi esempi mostrano solo i campi obbligatori per l’integrazione delle chiavi gestite dal cliente. Per configurare una chiave gestita dal cliente per un solo volume, specifica solo una `EbsVolumeConfig`.
Per ulteriori informazioni sulla configurazione delle richieste di creazione e aggiornamento dei cluster, consulta [Creazione di un cluster SageMaker HyperPod](sagemaker-hyperpod-eks-operate-cli-command-create-cluster.md) e [Aggiornamento SageMaker HyperPod della configurazione del cluster](sagemaker-hyperpod-eks-operate-cli-command-update-cluster.md).
------
#### [ CreateCluster ]
L'esempio seguente mostra una AWS CLI richiesta di [creazione di cluster](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/create-cluster.html) con crittografia a chiave gestita dal cliente.
```
aws sagemaker create-cluster \
--cluster-name \
--instance-groups '[{
"ExecutionRole": "arn:aws:iam::111122223333:role/",
"InstanceCount": 2,
"InstanceGroupName": "",
"InstanceStorageConfigs": [
{
"EbsVolumeConfig": {
"RootVolume": True,
"VolumeKmsKeyId": "arn:aws:kms:us-east-1:111122223333:key/root-volume-key-id"
}
},
{
"EbsVolumeConfig": {
"VolumeSizeInGB": 100,
"VolumeKmsKeyId": "arn:aws:kms:us-east-1:111122223333:key/secondary-volume-key-id"
}
}
],
"InstanceType": ""
}]' \
--vpc-config '{
"SecurityGroupIds": [""],
"Subnets": [""]
}'
```
------
#### [ UpdateCluster ]
L'esempio seguente mostra una AWS CLI richiesta di [aggiornamento del cluster con crittografia a chiave](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/update-cluster.html) gestita dal cliente.
```
aws sagemaker update-cluster \
--cluster-name \
--instance-groups '[{
"InstanceGroupName": "",
"InstanceStorageConfigs": [
{
"EbsVolumeConfig": {
"RootVolume": true,
"VolumeKmsKeyId": "arn:aws:kms:us-east-1:111122223333:key/root-volume-key-id"
}
},
{
"EbsVolumeConfig": {
"VolumeSizeInGB": 100,
"VolumeKmsKeyId": "arn:aws:kms:us-east-1:111122223333:key/secondary-volume-key-id"
}
}
]
}]'
```
------
# SageMaker HyperPod ricette
SageMaker HyperPod Le ricette Amazon sono stack di formazione preconfigurati forniti da AWS per aiutarti a iniziare rapidamente ad addestrare e perfezionare i modelli di base disponibili al pubblico (FMs) di varie famiglie di modelli come Llama, Mistral, Mixtral o. DeepSeek Le ricette automatizzano il ciclo di end-to-end formazione, incluso il caricamento di set di dati, l'applicazione di tecniche di addestramento distribuite e la gestione dei checkpoint per un recupero più rapido dai guasti.
SageMaker HyperPod le ricette sono particolarmente utili per gli utenti che potrebbero non avere competenze approfondite nell'apprendimento automatico, in quanto riducono gran parte della complessità associata all'addestramento di modelli di grandi dimensioni.
È possibile eseguire le ricette all'interno SageMaker HyperPod o come SageMaker attività di formazione.
Le tabelle seguenti sono conservate nel SageMaker HyperPod GitHub repository e forniscono la maggior parte delle up-to-date informazioni sui modelli supportati per il pre-addestramento e la messa a punto, le rispettive ricette e script di avvio, i tipi di istanze supportati e altro ancora.
+ Per l’elenco più aggiornato dei modelli, delle ricette e degli script di avvio supportati per il preaddestramento, consulta la [tabella di preaddestramento](https://github.com/aws/sagemaker-hyperpod-recipes?tab=readme-ov-file#pre-training).
+ Per l’elenco più aggiornato dei modelli, delle ricette e degli script di avvio supportati per il fine-tuning, consulta la [tabella di fine-tuning](https://github.com/aws/sagemaker-hyperpod-recipes?tab=readme-ov-file#fine-tuning).
Per SageMaker HyperPod gli utenti, l'automazione dei flussi di lavoro di end-to-end formazione deriva dall'integrazione dell'adattatore di formazione con le ricette. SageMaker HyperPod L'adattatore di formazione è basato sul [ NeMo framework NVIDIA](https://docs.nvidia.com/nemo-framework/user-guide/latest/overview.html) e sul pacchetto [Neuronx](https://awsdocs-neuron.readthedocs-hosted.com/en/latest/libraries/neuronx-distributed/index.html) Distributed Training. Se hai familiarità con l'utilizzo NeMo, il processo di utilizzo del training adapter è lo stesso. L’adattatore di addestramento esegue la ricetta sul cluster.
![\[Diagramma che mostra il flusso di lavoro delle SageMaker HyperPod ricette. L'icona «Ricetta» in alto si inserisce nella casella «lanciatore di HyperPod ricette». Questa casella si collega a una sezione più ampia denominata “Cluster: slurm, K8s,...” che contiene tre icone GPU con i file delle ricette associati. La parte inferiore della sezione del cluster è denominata «Train with HyperPod Training Adapter».\]](http://docs.aws.amazon.com/it_it/sagemaker/latest/dg/images/sagemaker-hyperpod-recipes-overview.png)
Puoi anche addestrare un tuo modello definendo una ricetta personalizzata.
Per iniziare con un tutorial, consulta [Esercitazioni](sagemaker-hyperpod-recipes-tutorials.md).
**Topics**
+ [Esercitazioni](sagemaker-hyperpod-recipes-tutorials.md)
+ [Configurazioni predefinite](default-configurations.md)
+ [Configurazioni specifiche dei cluster](cluster-specific-configurations.md)
+ [Considerazioni](cluster-specific-configurations-special-considerations.md)
+ [Impostazioni avanzate](cluster-specific-configurations-advanced-settings.md)
+ [Appendice](appendix.md)
# Esercitazioni
I tutorial rapidi seguenti ti aiutano a iniziare a utilizzare le ricette per l’addestramento:
+ SageMaker HyperPod con Slurm Orchestration
+ Preaddestramento
+ [HyperPod tutorial di pre-formazione sul cluster Slurm (GPU)](hyperpod-gpu-slurm-pretrain-tutorial.md)
+ [Tutorial di preaddestramento sul cluster Trainium Slurm](hyperpod-trainium-slurm-cluster-pretrain-tutorial.md)
+ Fine-tuning
+ [HyperPod Tutorial Slurm Cluster Left-LoRa (GPU)](hyperpod-gpu-slurm-peft-lora-tutorial.md)
+ [HyperPod Tutorial Slurm Cluster DPO (GPU)](hyperpod-gpu-slurm-dpo-tutorial.md)
+ SageMaker HyperPod con K8s Orchestration
+ Preaddestramento
+ [Tutorial di preaddestramento sul cluster Kubernetes (GPU)](sagemaker-hyperpod-gpu-kubernetes-cluster-pretrain-tutorial.md)
+ [Tutorial di pre-formazione sui lavori SageMaker di formazione Trainium](sagemaker-hyperpod-trainium-sagemaker-training-jobs-pretrain-tutorial.md)
+ SageMaker lavori di formazione
+ Preaddestramento
+ [SageMaker lavori di formazione tutorial di pre-formazione (GPU)](sagemaker-hyperpod-gpu-sagemaker-training-jobs-pretrain-tutorial.md)
+ [Tutorial di pre-formazione sui lavori SageMaker di formazione Trainium](sagemaker-hyperpod-trainium-sagemaker-training-jobs-pretrain-tutorial.md)
# HyperPod tutorial di pre-formazione sul cluster Slurm (GPU)
Il tutorial seguente configura l’ambiente Slurm e avvia un job di addestramento su un modello Llama da 8 miliardi di parametri.
**Prerequisiti**
Prima di iniziare a configurare l’ambiente per eseguire la ricetta, assicurati di avere:
Configura un cluster GPU Slurm HyperPod .
Il tuo cluster HyperPod Slurm deve avere Nvidia Enroot e Pyxis abilitati (questi sono abilitati di default).
Una posizione di archiviazione condivisa. Può essere un FSx file system Amazon o un sistema NFS accessibile dai nodi del cluster.
I dati in uno dei seguenti formati:
JSON
JSONGZ (JSON compresso)
ARROW
(Facoltativo) È necessario ottenere un HuggingFace token se si utilizzano i pesi del modello HuggingFace per il pre-allenamento o la messa a punto. Per ulteriori informazioni su come ottenere il token, consulta [User access tokens](https://huggingface.co/docs/hub/en/security-tokens).
## HyperPod Configurazione dell'ambiente GPU Slurm
Per avviare un processo di formazione su un cluster HyperPod GPU Slurm, procedi come segue:
1. SSH nel nodo head del cluster Slurm.
1. Dopo aver effettuato l’accesso, configura l’ambiente virtuale. Assicurati di utilizzare Python 3.9 o versioni successive.
```
#set up a virtual environment
python3 -m venv ${PWD}/venv
source venv/bin/activate
```
1. Clona le SageMaker HyperPod ricette e gli archivi degli SageMaker HyperPod adattatori in una posizione di archiviazione condivisa.
```
git clone https://github.com/aws/sagemaker-hyperpod-training-adapter-for-nemo.git
git clone --recursive https://github.com/aws/sagemaker-hyperpod-recipes.git
cd sagemaker-hyperpod-recipes
pip3 install -r requirements.txt
```
1. Crea un file squash utilizzando Enroot. Per trovare il rilascio più recente del container SMP, consulta [Note di rilascio per la libreria di parallelismo dei SageMaker modelli](model-parallel-release-notes.md). Per una comprensione più approfondita di come utilizzare il file Enroot, consulta l'immagine [AWS Nemo-Launcher ottimizzata per Build](https://github.com/aws-samples/awsome-distributed-training/tree/main/3.test_cases/2.nemo-launcher#2-build-aws-optimized-nemo-launcher-image).
```
REGION=""
IMAGE="658645717510.dkr.ecr.${REGION}.amazonaws.com/smdistributed-modelparallel:2.4.1-gpu-py311-cu121"
aws ecr get-login-password --region ${REGION} | docker login --username AWS --password-stdin 658645717510.dkr.ecr.${REGION}.amazonaws.com
enroot import -o $PWD/smdistributed-modelparallel.sqsh dockerd://${IMAGE}
mv $PWD/smdistributed-modelparallel.sqsh "/fsx/"
```
1. Per utilizzare il file squash Enroot per iniziare l’addestramento, consulta l’esempio seguente per modificare il file `recipes_collection/config.yaml`.
```
container: /fsx/path/to/your/smdistributed-modelparallel.sqsh
```
## Avvio del job di addestramento
Dopo aver installato le dipendenze, avvia un job di addestramento dalla directory `sagemaker-hyperpod-recipes/launcher_scripts`. [Ottieni le dipendenze clonando l'archivio delle ricette: SageMaker HyperPod ](https://github.com/aws/sagemaker-hyperpod-recipes)
Prima di tutto, scegli la tua ricetta di addestramento da GitHub. Il nome del modello viene specificato come parte della ricetta. Nell’esempio seguente utilizziamo lo script `launcher_scripts/llama/run_hf_llama3_8b_seq16k_gpu_p5x16_pretrain.sh` per avviare `llama/hf_llama3_8b_seq16k_gpu_p5x16_pretrain`, una ricetta di preaddestramento Llama 8b con lunghezza della sequenza 8192.
+ `IMAGE`: il container della sezione di configurazione dell’ambiente.
+ (Facoltativo) Se hai bisogno di pesi già addestrati, puoi fornire il HuggingFace token HuggingFace impostando la seguente coppia chiave-valore:
```
recipes.model.hf_access_token=
```
```
#!/bin/bash
IMAGE="${YOUR_IMAGE}"
SAGEMAKER_TRAINING_LAUNCHER_DIR="${SAGEMAKER_TRAINING_LAUNCHER_DIR:-${PWD}}"
TRAIN_DIR="${YOUR_TRAIN_DIR}" # Location of training dataset
VAL_DIR="${YOUR_VAL_DIR}" # Location of validation dataset
# experiment ouput directory
EXP_DIR="${YOUR_EXP_DIR}"
HYDRA_FULL_ERROR=1 python3 "${SAGEMAKER_TRAINING_LAUNCHER_DIR}/main.py" \
recipes=training/llama/hf_llama3_8b_seq16k_gpu_p5x16_pretrain \
base_results_dir="${SAGEMAKER_TRAINING_LAUNCHER_DIR}/results" \
recipes.run.name="hf_llama3_8b" \
recipes.exp_manager.exp_dir="$EXP_DIR" \
recipes.model.data.train_dir="$TRAIN_DIR" \
recipes.model.data.val_dir="$VAL_DIR" \
container="${IMAGE}" \
+cluster.container_mounts.0="/fsx:/fsx"
```
Dopo aver configurato tutti i parametri richiesti nello script di avvio, puoi eseguire lo script con questo comando.
```
bash launcher_scripts/llama/run_hf_llama3_8b_seq16k_gpu_p5x16_pretrain.sh
```
Per ulteriori informazioni sulla configurazione del cluster Slurm, consulta [Esecuzione di un lavoro di formazione su HyperPod Slurm](cluster-specific-configurations-run-training-job-hyperpod-slurm.md).
# Tutorial di preaddestramento sul cluster Trainium Slurm
Il tutorial seguente configura un ambiente Trainium su un cluster Slurm e avvia un job di addestramento su un modello Llama da 8 miliardi di parametri.
**Prerequisiti**
Prima di iniziare a configurare l’ambiente, assicurati di avere:
Configura un cluster Trainium Slurm SageMaker HyperPod .
Una posizione di archiviazione condivisa. Può essere un FSx file system Amazon o un sistema NFS accessibile dai nodi del cluster.
I dati in uno dei seguenti formati:
JSON
JSONGZ (JSON compresso)
ARROW
(Facoltativo) È necessario ottenere un HuggingFace token se si utilizzano i pesi del modello HuggingFace per il pre-allenamento o la messa a punto. Per ulteriori informazioni su come ottenere il token, consulta [User access tokens](https://huggingface.co/docs/hub/en/security-tokens).
## Configurazione dell’ambiente Trainium sul cluster Slurm
Per avviare un job di addestramento su un cluster Slurm, procedi come descritto di seguito:
+ SSH nel nodo head del cluster Slurm.
+ Dopo aver effettuato l’accesso, configura l’ambiente Neuron. Per informazioni sulla configurazione di Neuron, consulta [Neuron setup steps](https://awsdocs-neuron.readthedocs-hosted.com/en/latest/libraries/nxd-training/tutorials/hf_llama3_8B_SFT.html#setting-up-the-environment). Ti consigliamo di fare affidamento sulle AMI di deep learning preinstallate con i driver di Neuron, come [Ubuntu 20 con DLAMI PyTorch](https://awsdocs-neuron.readthedocs-hosted.com/en/latest/general/setup/neuron-setup/pytorch/neuronx/ubuntu/torch-neuronx-ubuntu20-pytorch-dlami.html#setup-torch-neuronx-ubuntu20-dlami-pytorch).
+ Clona l'archivio delle SageMaker HyperPod ricette in una posizione di archiviazione condivisa nel cluster. La posizione di archiviazione condivisa può essere un FSx file system Amazon o un sistema NFS accessibile dai nodi del cluster.
```
git clone --recursive https://github.com/aws/sagemaker-hyperpod-recipes.git
cd sagemaker-hyperpod-recipes
pip3 install -r requirements.txt
```
+ Segui il seguente tutorial: [HuggingFace Llama3-8B](https://awsdocs-neuron.readthedocs-hosted.com/en/latest/libraries/nxd-training/tutorials/hf_llama3_8B_pretraining.html#) Pretraining
+ Prepara una configurazione del modello. Le configurazioni del modello disponibili nel repository Neuron. Per la configurazione del modello utilizzata in questo tutorial, consulta la [configurazione del modello llama3 8b](https://github.com/aws-neuron/neuronx-distributed/blob/main/examples/training/llama/tp_zero1_llama_hf_pretrain/8B_config_llama3/config.json).
## Avvio del job di addestramento in Trainium
Per avviare un job di addestramento in Trainium, specifica una configurazione del cluster e una ricetta Neuron. Ad esempio, per avviare un job di preaddestramento di llama3 8b in Trainium, imposta lo script di avvio `launcher_scripts/llama/run_hf_llama3_8b_seq8k_trn1x4_pretrain.sh` su quanto segue:
+ `MODEL_CONFIG`: la configurazione del modello dalla sezione di configurazione dell’ambiente
+ (Facoltativo) Se hai bisogno di pesi già addestrati, puoi fornire il HuggingFace token impostando la seguente coppia chiave-valore: HuggingFace
```
recipes.model.hf_access_token=
```
```
#!/bin/bash
#Users should set up their cluster type in /recipes_collection/config.yaml
SAGEMAKER_TRAINING_LAUNCHER_DIR=${SAGEMAKER_TRAINING_LAUNCHER_DIR:-"$(pwd)"}
COMPILE=0
TRAIN_DIR="${TRAIN_DIR}" # Location of training dataset
MODEL_CONFIG="${MODEL_CONFIG}" # Location of config.json for the model
HYDRA_FULL_ERROR=1 python3 "${SAGEMAKER_TRAINING_LAUNCHER_DIR}/main.py" \
base_results_dir="${SAGEMAKER_TRAINING_LAUNCHER_DIR}/results" \
instance_type="trn1.32xlarge" \
recipes.run.compile="$COMPILE" \
recipes.run.name="hf-llama3-8b" \
recipes.trainer.num_nodes=4 \
recipes=training/llama/hf_llama3_8b_seq8k_trn1x4_pretrain \
recipes.data.train_dir="$TRAIN_DIR" \
recipes.model.model_config="$MODEL_CONFIG"
```
Per avviare il job di addestramento, utilizza il comando seguente:
```
bash launcher_scripts/llama/run_hf_llama3_8b_seq8k_trn1x4_pretrain.sh
```
Per ulteriori informazioni sulla configurazione del cluster Slurm, consulta [Esecuzione di un lavoro di formazione su HyperPod Slurm](cluster-specific-configurations-run-training-job-hyperpod-slurm.md).
# HyperPod Tutorial Slurm Cluster DPO (GPU)
Il tutorial seguente configura un ambiente Slurm e avvia un processo di ottimizzazione diretta delle preferenze (DPO) su un modello Llama da otto miliardi di parametri.
**Prerequisiti**
Prima di iniziare a configurare l’ambiente, assicurati di avere:
Configura il cluster GPU Slurm HyperPod
Il tuo cluster HyperPod Slurm deve avere Nvidia Enroot e Pyxis abilitati (questi sono abilitati di default).
Una posizione di archiviazione condivisa. Può essere un FSx file system Amazon o un sistema NFS accessibile dai nodi del cluster.
Un set di dati di preferenze binarie tokenizzato in uno dei formati seguenti:
JSON
JSONGZ (JSON compresso)
ARROW
(Facoltativo) Se ti servono i pesi preallenati di HuggingFace o se stai allenando un modello Llama 3.2, devi procurarti il HuggingFace token prima di iniziare l'allenamento. Per ulteriori informazioni su come ottenere il token, consulta [User access tokens](https://huggingface.co/docs/hub/en/security-tokens).
## Configura l'ambiente GPU Slurm HyperPod
Per avviare un job di addestramento su un cluster Slurm, procedi come descritto di seguito:
+ SSH nel nodo head del cluster Slurm.
+ Dopo aver effettuato l’accesso, configura l’ambiente virtuale. Assicurati di utilizzare Python 3.9 o versioni successive.
```
#set up a virtual environment
python3 -m venv ${PWD}/venv
source venv/bin/activate
```
+ Clona le SageMaker HyperPod ricette e gli archivi degli SageMaker HyperPod adattatori in una posizione di archiviazione condivisa. La posizione di archiviazione condivisa può essere un FSx file system Amazon o un sistema NFS accessibile dai nodi del cluster.
```
git clone https://github.com/aws/sagemaker-hyperpod-training-adapter-for-nemo.git
git clone --recursive https://github.com/aws/sagemaker-hyperpod-recipes.git
cd sagemaker-hyperpod-recipes
pip3 install -r requirements.txt
```
+ Crea un file squash utilizzando Enroot. Per trovare il rilascio più recente del container SMP, consulta [Note di rilascio per la libreria di parallelismo dei SageMaker modelli](model-parallel-release-notes.md). Per ulteriori informazioni sull'utilizzo del file Enroot, consulta l'immagine [AWS Nemo-Launcher ottimizzata per Build](https://github.com/aws-samples/awsome-distributed-training/tree/main/3.test_cases/2.nemo-launcher#2-build-aws-optimized-nemo-launcher-image).
```
REGION=""
IMAGE="658645717510.dkr.ecr.${REGION}.amazonaws.com/smdistributed-modelparallel:2.4.1-gpu-py311-cu121"
aws ecr get-login-password --region ${REGION} | docker login --username AWS --password-stdin 658645717510.dkr.ecr.${REGION}.amazonaws.com
enroot import -o $PWD/smdistributed-modelparallel.sqsh dockerd://${IMAGE}
mv $PWD/smdistributed-modelparallel.sqsh "/fsx/"
```
+ Per utilizzare il file squash Enroot per iniziare l’addestramento, consulta l’esempio seguente per modificare il file `recipes_collection/config.yaml`.
```
container: /fsx/path/to/your/smdistributed-modelparallel.sqsh
```
## Avvio del job di addestramento
Per avviare un processo DPO per il modello Llama da 8 miliardi di parametri con una lunghezza di sequenza di 8192 su un singolo nodo di calcolo Slurm, imposta lo script di avvio `launcher_scripts/llama/run_hf_llama3_8b_seq8k_gpu_dpo.sh` su quanto segue:
+ `IMAGE`: il container della sezione di configurazione dell’ambiente.
+ `HF_MODEL_NAME_OR_PATH`: definisci il nome o il percorso dei pesi preaddestrati nel parametro hf\$1model\$1name\$1or\$1path della ricetta.
+ (Facoltativo) Se hai bisogno di pesi già addestrati, puoi fornire il HuggingFace token impostando la seguente coppia chiave-valore: HuggingFace
```
recipes.model.hf_access_token=${HF_ACCESS_TOKEN}
```
**Nota**
Il modello di riferimento utilizzato per il DPO in questa configurazione deriva automaticamente dal modello di base in fase di addestramento (non viene definito in modo esplicito alcun modello di riferimento separato). Gli iperparametri specifici del DPO sono preconfigurati con i valori predefiniti seguenti:
`beta`: 0.1 (controlla l’intensità della regolarizzazione della divergenza KL)
`label_smoothing`: 0.0 (nessun livellamento applicato alle etichette delle preferenze)
```
recipes.dpo.beta=${BETA}
recipes.dpo.label_smoothing=${LABEL_SMOOTHING}
```
```
#!/bin/bash
IMAGE="${YOUR_IMAGE}"
SAGEMAKER_TRAINING_LAUNCHER_DIR="${SAGEMAKER_TRAINING_LAUNCHER_DIR:-${PWD}}"
TRAIN_DIR="${YOUR_TRAIN_DIR}" # Location of training dataset
VAL_DIR="${YOUR_VAL_DIR}" # Location of validation dataset
# experiment output directory
EXP_DIR="${YOUR_EXP_DIR}"
HF_ACCESS_TOKEN="${YOUR_HF_TOKEN}"
HF_MODEL_NAME_OR_PATH="${HF_MODEL_NAME_OR_PATH}"
BETA="${BETA}"
LABEL_SMOOTHING="${LABEL_SMOOTHING}"
# Add hf_model_name_or_path and turn off synthetic_data
HYDRA_FULL_ERROR=1 python3 ${SAGEMAKER_TRAINING_LAUNCHER_DIR}/main.py \
recipes=fine-tuning/llama/hf_llama3_8b_seq8k_gpu_dpo \
base_results_dir=${SAGEMAKER_TRAINING_LAUNCHER_DIR}/results \
recipes.run.name="hf_llama3_dpo" \
recipes.exp_manager.exp_dir="$EXP_DIR" \
recipes.model.data.train_dir="$TRAIN_DIR" \
recipes.model.data.val_dir="$VAL_DIR" \
recipes.model.hf_model_name_or_path="$HF_MODEL_NAME_OR_PATH" \
container="${IMAGE}" \
+cluster.container_mounts.0="/fsx:/fsx" \
recipes.model.hf_access_token="${HF_ACCESS_TOKEN}" \
recipes.dpo.enabled=true \
recipes.dpo.beta="${BETA}" \
recipes.dpo.label_smoothing="${LABEL_SMOOTHING}$" \
```
Dopo aver configurato tutti i parametri richiesti nello script precedente, puoi eseguire il job di addestramento.
```
bash launcher_scripts/llama/run_hf_llama3_8b_seq8k_gpu_dpo.sh
```
Per ulteriori informazioni sulla configurazione del cluster Slurm, consulta [Esecuzione di un lavoro di formazione su HyperPod Slurm](cluster-specific-configurations-run-training-job-hyperpod-slurm.md).
# HyperPod Tutorial Slurm Cluster Left-LoRa (GPU)
Il tutorial seguente configura l’ambiente Slurm e avvia un processo di fine-tuning efficiente in termini di parametri (PEFT) su un modello Llama da 8 miliardi di parametri.
**Prerequisiti**
Prima di iniziare a configurare l’ambiente, assicurati di avere:
Configura il HyperPod cluster GPU Slurm
Il tuo cluster HyperPod Slurm deve avere Nvidia Enroot e Pyxis abilitati (questi sono abilitati di default).
Una posizione di archiviazione condivisa. Può essere un FSx file system Amazon o un sistema NFS accessibile dai nodi del cluster.
I dati in uno dei seguenti formati:
JSON
JSONGZ (JSON compresso)
ARROW
(Facoltativo) Se ti servono i pesi preallenati di HuggingFace o se stai allenando un modello Llama 3.2, devi procurarti il HuggingFace token prima di iniziare l'allenamento. Per ulteriori informazioni su come ottenere il token, consulta [User access tokens](https://huggingface.co/docs/hub/en/security-tokens).
## Configura l'ambiente GPU Slurm HyperPod
Per avviare un job di addestramento su un cluster Slurm, procedi come descritto di seguito:
+ SSH nel nodo head del cluster Slurm.
+ Dopo aver effettuato l’accesso, configura l’ambiente virtuale. Assicurati di utilizzare Python 3.9 o versioni successive.
```
#set up a virtual environment
python3 -m venv ${PWD}/venv
source venv/bin/activate
```
+ Clona le SageMaker HyperPod ricette e gli archivi degli SageMaker HyperPod adattatori in una posizione di archiviazione condivisa. La posizione di archiviazione condivisa può essere un FSx file system Amazon o un sistema NFS accessibile dai nodi del cluster.
```
git clone https://github.com/aws/sagemaker-hyperpod-training-adapter-for-nemo.git
git clone --recursive https://github.com/aws/sagemaker-hyperpod-recipes.git
cd sagemaker-hyperpod-recipes
pip3 install -r requirements.txt
```
+ Crea un file squash utilizzando Enroot. Per trovare il rilascio più recente del container SMP, consulta [Note di rilascio per la libreria di parallelismo dei SageMaker modelli](model-parallel-release-notes.md). Per ulteriori informazioni sull'utilizzo del file Enroot, consulta l'immagine [AWS Nemo-Launcher ottimizzata per Build](https://github.com/aws-samples/awsome-distributed-training/tree/main/3.test_cases/2.nemo-launcher#2-build-aws-optimized-nemo-launcher-image).
```
REGION=""
IMAGE="658645717510.dkr.ecr.${REGION}.amazonaws.com/smdistributed-modelparallel:2.4.1-gpu-py311-cu121"
aws ecr get-login-password --region ${REGION} | docker login --username AWS --password-stdin 658645717510.dkr.ecr.${REGION}.amazonaws.com
enroot import -o $PWD/smdistributed-modelparallel.sqsh dockerd://${IMAGE}
mv $PWD/smdistributed-modelparallel.sqsh "/fsx/"
```
+ Per utilizzare il file squash Enroot per iniziare l’addestramento, consulta l’esempio seguente per modificare il file `recipes_collection/config.yaml`.
```
container: /fsx/path/to/your/smdistributed-modelparallel.sqsh
```
## Avvio del job di addestramento
Per avviare un processo PEFT per il modello Llama da 8 miliardi di parametri con una lunghezza di sequenza di 8192 su un singolo nodo di calcolo Slurm, imposta lo script di avvio `launcher_scripts/llama/run_hf_llama3_8b_seq8k_gpu_lora.sh` su quanto segue:
+ `IMAGE`: il container della sezione di configurazione dell’ambiente.
+ `HF_MODEL_NAME_OR_PATH`: definisci il nome o il percorso dei pesi preaddestrati nel parametro hf\$1model\$1name\$1or\$1path della ricetta.
+ (Facoltativo) Se hai bisogno di pesi già addestrati, puoi fornire il HuggingFace token impostando la seguente coppia chiave-valore: HuggingFace
```
recipes.model.hf_access_token=${HF_ACCESS_TOKEN}
```
```
#!/bin/bash
IMAGE="${YOUR_IMAGE}"
SAGEMAKER_TRAINING_LAUNCHER_DIR="${SAGEMAKER_TRAINING_LAUNCHER_DIR:-${PWD}}"
TRAIN_DIR="${YOUR_TRAIN_DIR}" # Location of training dataset
VAL_DIR="${YOUR_VAL_DIR}" # Location of validation dataset
# experiment output directory
EXP_DIR="${YOUR_EXP_DIR}"
HF_ACCESS_TOKEN="${YOUR_HF_TOKEN}"
HF_MODEL_NAME_OR_PATH="${YOUR_HF_MODEL_NAME_OR_PATH}"
# Add hf_model_name_or_path and turn off synthetic_data
HYDRA_FULL_ERROR=1 python3 ${SAGEMAKER_TRAINING_LAUNCHER_DIR}/main.py \
recipes=fine-tuning/llama/hf_llama3_8b_seq8k_gpu_lora \
base_results_dir=${SAGEMAKER_TRAINING_LAUNCHER_DIR}/results \
recipes.run.name="hf_llama3_lora" \
recipes.exp_manager.exp_dir="$EXP_DIR" \
recipes.model.data.train_dir="$TRAIN_DIR" \
recipes.model.data.val_dir="$VAL_DIR" \
recipes.model.hf_model_name_or_path="$HF_MODEL_NAME_OR_PATH" \
container="${IMAGE}" \
+cluster.container_mounts.0="/fsx:/fsx" \
recipes.model.hf_access_token="${HF_ACCESS_TOKEN}"
```
Dopo aver configurato tutti i parametri richiesti nello script precedente, puoi eseguire il job di addestramento.
```
bash launcher_scripts/llama/run_hf_llama3_8b_seq8k_gpu_lora.sh
```
Per ulteriori informazioni sulla configurazione del cluster Slurm, consulta [Esecuzione di un lavoro di formazione su HyperPod Slurm](cluster-specific-configurations-run-training-job-hyperpod-slurm.md).
# Tutorial di preaddestramento sul cluster Kubernetes (GPU)
Esistono due modi per avviare un job di addestramento in un cluster GPU Kubernetes:
+ [Strumento da riga di comando (consigliato) HyperPod ](https://github.com/aws/sagemaker-hyperpod-cli)
+ Il programma di avvio degli stili NeMo
**Prerequisiti**
Prima di iniziare a configurare l’ambiente, assicurati di avere:
Un cluster HyperPod GPU Kubernetes è configurato correttamente.
Una posizione di archiviazione condivisa. Può essere un FSx file system Amazon o un sistema NFS accessibile dai nodi del cluster.
I dati in uno dei seguenti formati:
JSON
JSONGZ (JSON compresso)
ARROW
(Facoltativo) È necessario ottenere un HuggingFace token se si utilizzano i pesi del modello HuggingFace per il pre-allenamento o la messa a punto. Per ulteriori informazioni su come ottenere il token, consulta [User access tokens](https://huggingface.co/docs/hub/en/security-tokens).
## Configurazione dell’ambiente GPU Kubernetes
Per configurare un ambiente GPU Kubernetes, procedi come descritto di seguito:
+ Configura l’ambiente virtuale. Assicurati di utilizzare Python 3.9 o versioni successive.
```
python3 -m venv ${PWD}/venv
source venv/bin/activate
```
+ Installa le dipendenze utilizzando uno dei metodi seguenti:
+ [(Consigliato): metodo dello strumento a riga di comando: HyperPod ](https://github.com/aws/sagemaker-hyperpod-cli)
```
# install HyperPod command line tools
git clone https://github.com/aws/sagemaker-hyperpod-cli
cd sagemaker-hyperpod-cli
pip3 install .
```
+ SageMaker HyperPod metodo delle ricette:
```
# install SageMaker HyperPod Recipes.
git clone --recursive git@github.com:aws/sagemaker-hyperpod-recipes.git
cd sagemaker-hyperpod-recipes
pip3 install -r requirements.txt
```
+ [Configura kubectl ed eksctl](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html).
+ [Installa Helm](https://helm.sh/docs/intro/install/).
+ Connettiti al cluster Kubernetes.
```
aws eks update-kubeconfig --region "CLUSTER_REGION" --name "CLUSTER_NAME"
hyperpod connect-cluster --cluster-name "CLUSTER_NAME" [--region "CLUSTER_REGION"] [--namespace ]
```
## Avvia il processo di formazione con la SageMaker HyperPod CLI
Ti consigliamo di utilizzare lo strumento dell'interfaccia SageMaker HyperPod a riga di comando (CLI) per inviare il tuo lavoro di formazione con le tue configurazioni. L’esempio seguente invia un job di addestramento per il modello `hf_llama3_8b_seq16k_gpu_p5x16_pretrain`.
+ `your_training_container`: un container per il Deep Learning. Per trovare il rilascio più recente del container SMP, consulta [Note di rilascio per la libreria di parallelismo dei SageMaker modelli](model-parallel-release-notes.md).
+ (Facoltativo) Se hai bisogno di pesi già addestrati, puoi fornire il HuggingFace token HuggingFace impostando la seguente coppia chiave-valore:
```
"recipes.model.hf_access_token": ""
```
```
hyperpod start-job --recipe training/llama/hf_llama3_8b_seq16k_gpu_p5x16_pretrain \
--persistent-volume-claims fsx-claim:data \
--override-parameters \
'{
"recipes.run.name": "hf-llama3-8b",
"recipes.exp_manager.exp_dir": "/data/",
"container": "658645717510.dkr.ecr..amazonaws.com/smdistributed-modelparallel:2.4.1-gpu-py311-cu121",
"recipes.model.data.train_dir": "",
"recipes.model.data.val_dir": "",
"cluster": "k8s",
"cluster_type": "k8s"
}'
```
Dopo aver inviato un job di addestramento, puoi utilizzare il comando seguente per verificare se l’invio è riuscito.
```
kubectl get pods
NAME READY STATUS RESTARTS AGE
hf-llama3--worker-0 0/1 running 0 36s
```
Se `STATUS` è `PENDING` o `ContainerCreating`, utilizza il comando seguente per ottenere maggiori dettagli.
```
kubectl describe pod name_of_pod
```
Quando lo `STATUS` del processo diventa `Running`, puoi esaminare il log utilizzando il comando seguente.
```
kubectl logs name_of_pod
```
`STATUS` diventa `Completed` quando esegui `kubectl get pods`.
## Avvio del job di addestramento con l’utilità di avvio delle ricette
In alternativa, puoi utilizzare le SageMaker HyperPod ricette per inviare il tuo lavoro di formazione. Per utilizzare le ricette, devi aggiornare `k8s.yaml` e `config.yaml` ed eseguire lo script di avvio.
+ In `k8s.yaml`, aggiorna `persistent_volume_claims`. Monta il FSx claim Amazon `/data` nella directory di ogni pod di elaborazione
```
persistent_volume_claims:
- claimName: fsx-claim
mountPath: data
```
+ In `config.yaml`, aggiorna `repo_url_or_path` sotto `git`.
```
git:
repo_url_or_path:
branch: null
commit: null
entry_script: null
token: null
```
+ Aggiornamento di `launcher_scripts/llama/run_hf_llama3_8b_seq16k_gpu_p5x16_pretrain.sh`
+ `your_contrainer`: un container per il Deep Learning. Per trovare il rilascio più recente del container SMP, consulta [Note di rilascio per la libreria di parallelismo dei SageMaker modelli](model-parallel-release-notes.md).
+ (Facoltativo) Se hai bisogno di pesi già addestrati, puoi fornire il HuggingFace token HuggingFace impostando la seguente coppia chiave-valore:
```
recipes.model.hf_access_token=
```
```
#!/bin/bash
#Users should setup their cluster type in /recipes_collection/config.yaml
REGION=""
IMAGE="658645717510.dkr.ecr.${REGION}.amazonaws.com/smdistributed-modelparallel:2.4.1-gpu-py311-cu121"
SAGEMAKER_TRAINING_LAUNCHER_DIR=${SAGEMAKER_TRAINING_LAUNCHER_DIR:-"$(pwd)"}
EXP_DIR="" # Location to save experiment info including logging, checkpoints, ect
TRAIN_DIR="" # Location of training dataset
VAL_DIR="" # Location of talidation dataset
HYDRA_FULL_ERROR=1 python3 "${SAGEMAKER_TRAINING_LAUNCHER_DIR}/main.py" \
recipes=training/llama/hf_llama3_8b_seq8k_gpu_p5x16_pretrain \
base_results_dir="${SAGEMAKER_TRAINING_LAUNCHER_DIR}/results" \
recipes.run.name="hf-llama3" \
recipes.exp_manager.exp_dir="$EXP_DIR" \
cluster=k8s \
cluster_type=k8s \
container="${IMAGE}" \
recipes.model.data.train_dir=$TRAIN_DIR \
recipes.model.data.val_dir=$VAL_DIR
```
+ Avvio del job di addestramento
```
bash launcher_scripts/llama/run_hf_llama3_8b_seq16k_gpu_p5x16_pretrain.sh
```
Dopo aver inviato il job di addestramento, puoi utilizzare il comando seguente per verificare se l’invio è riuscito.
```
kubectl get pods
```
```
NAME READY STATUS RESTARTS AGE
hf-llama3--worker-0 0/1 running 0 36s
```
Se `STATUS` è `PENDING` o `ContainerCreating`, utilizza il comando seguente per ottenere maggiori dettagli.
```
kubectl describe pod
```
Quando lo `STATUS` del processo diventa `Running`, puoi esaminare il log utilizzando il comando seguente.
```
kubectl logs name_of_pod
```
`STATUS` diventa `Completed` quando esegui `kubectl get pods`.
Per ulteriori informazioni sulla connessione al cluster k8s, consulta [Esecuzione di un processo di formazione su k8s HyperPod](cluster-specific-configurations-run-training-job-hyperpod-k8s.md).
# Tutorial di preaddestramento sul cluster Trainium Kubernetes
Puoi utilizzare uno dei metodi seguenti per avviare un job di addestramento in un cluster Trainium Kubernetes.
+ [Strumento da riga di comando (consigliato) HyperPod ](https://github.com/aws/sagemaker-hyperpod-cli)
+ Il programma di avvio degli stili NeMo
**Prerequisiti**
Prima di iniziare a configurare l’ambiente, assicurati di avere:
Configura un cluster HyperPod Trainium Kubernetes
Una posizione di archiviazione condivisa che può essere un FSx file system Amazon o un sistema NFS accessibile dai nodi del cluster.
I dati in uno dei seguenti formati:
JSON
JSONGZ (JSON compresso)
ARROW
(Facoltativo) È necessario ottenere un HuggingFace token se si utilizzano i pesi del modello HuggingFace per il pre-allenamento o la messa a punto. Per ulteriori informazioni su come ottenere il token, consulta [User access tokens](https://huggingface.co/docs/hub/en/security-tokens).
## Configurazione dell’ambiente Trainium Kubernetes
Per configurare l’ambiente Trainium Kubernetes, procedi come descritto di seguito:
1. **Completa i passaggi del seguente tutorial: [HuggingFace Llama3-8B](https://awsdocs-neuron.readthedocs-hosted.com/en/latest/libraries/nxd-training/tutorials/hf_llama3_8B_pretraining.html#download-the-dataset) Pretraining a partire da Scarica il set di dati.**
1. Prepara una configurazione del modello. Sono disponibili nel repository Neuron. Per questo tutorial, puoi utilizzare la configurazione del modello llama3 8b.
1. Configura l’ambiente virtuale. Assicurati di utilizzare Python 3.9 o versioni successive.
```
python3 -m venv ${PWD}/venv
source venv/bin/activate
```
1. Installazione delle dipendenze
+ (Consigliato) Utilizza il seguente strumento da riga di comando HyperPod
```
# install HyperPod command line tools
git clone https://github.com/aws/sagemaker-hyperpod-cli
cd sagemaker-hyperpod-cli
pip3 install .
```
+ Se utilizzi SageMaker HyperPod ricette, specifica quanto segue
```
# install SageMaker HyperPod Recipes.
git clone --recursive git@github.com:aws/sagemaker-hyperpod-recipes.git
cd sagemaker-hyperpod-recipes
pip3 install -r requirements.txt
```
1. [Configura kubectl ed eksctl](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html).
1. [Installa Helm](https://helm.sh/docs/intro/install/).
1. Connettiti al cluster Kubernetes.
```
aws eks update-kubeconfig --region "${CLUSTER_REGION}" --name "${CLUSTER_NAME}"
hyperpod connect-cluster --cluster-name "${CLUSTER_NAME}" [--region "${CLUSTER_REGION}"] [--namespace ]
```
1. Container: il [container Neuron](https://github.com/aws-neuron/deep-learning-containers?tab=readme-ov-file#pytorch-training-neuronx)
## Avvia il processo di formazione con la SageMaker HyperPod CLI
Ti consigliamo di utilizzare lo strumento dell'interfaccia SageMaker HyperPod a riga di comando (CLI) per inviare il tuo lavoro di formazione con le tue configurazioni. L’esempio seguente invia un job di addestramento per il modello Trainium `hf_llama3_8b_seq8k_trn1x4_pretrain`.
+ `your_neuron_container`: il [container Neuron](https://github.com/aws-neuron/deep-learning-containers?tab=readme-ov-file#pytorch-training-neuronx).
+ `your_model_config`: la configurazione del modello dalla sezione di configurazione dell’ambiente.
+ (Facoltativo) Se hai bisogno di pesi già addestrati, puoi fornire il HuggingFace token HuggingFace impostando la seguente coppia chiave-valore:
```
"recipes.model.hf_access_token": ""
```
```
hyperpod start-job --recipe training/llama/hf_llama3_8b_seq8k_trn1x4_pretrain \
--persistent-volume-claims fsx-claim:data \
--override-parameters \
'{
"cluster": "k8s",
"cluster_type": "k8s",
"container": "",
"recipes.run.name": "hf-llama3",
"recipes.run.compile": 0,
"recipes.model.model_config": "",
"instance_type": "trn1.32xlarge",
"recipes.data.train_dir": ""
}'
```
Dopo aver inviato un job di addestramento, puoi utilizzare il comando seguente per verificare se l’invio è riuscito.
```
kubectl get pods
NAME READY STATUS RESTARTS AGE
hf-llama3--worker-0 0/1 running 0 36s
```
Se `STATUS` è `PENDING` o `ContainerCreating`, utilizza il comando seguente per ottenere maggiori dettagli.
```
kubectl describe pod name_of_pod
```
Quando lo `STATUS` del processo diventa `Running`, puoi esaminare il log utilizzando il comando seguente.
```
kubectl logs name_of_pod
```
`STATUS` diventa `Completed` quando esegui `kubectl get pods`.
## Avvio del job di addestramento con l’utilità di avvio delle ricette
In alternativa, utilizza le SageMaker HyperPod ricette per inviare il tuo lavoro di formazione. Per inviare il job di addestramento utilizzando una ricetta, aggiorna `k8s.yaml` e `config.yaml`. Esegui lo script bash per il modello per avviarlo.
+ In`k8s.yaml`, aggiorna persistent\$1volume\$1claims per montare il claim FSx Amazon nella directory /data nei nodi di calcolo
```
persistent_volume_claims:
- claimName: fsx-claim
mountPath: data
```
+ scripts/llama/runAggiorna launcher\$1 \$1hf\$1llama3\$18b\$1seq8k\$1trn1x4\$1pretrain.sh
+ `your_neuron_contrainer`: il container della sezione di configurazione dell’ambiente
+ `your_model_config`: la configurazione del modello dalla sezione di configurazione dell’ambiente
(Facoltativo) Se hai bisogno di pesi già addestrati, puoi fornire il HuggingFace token HuggingFace impostando la seguente coppia chiave-valore:
```
recipes.model.hf_access_token=
```
```
#!/bin/bash
#Users should set up their cluster type in /recipes_collection/config.yaml
IMAGE=""
MODEL_CONFIG=""
SAGEMAKER_TRAINING_LAUNCHER_DIR=${SAGEMAKER_TRAINING_LAUNCHER_DIR:-"$(pwd)"}
TRAIN_DIR="" # Location of training dataset
VAL_DIR="" # Location of talidation dataset
HYDRA_FULL_ERROR=1 python3 "${SAGEMAKER_TRAINING_LAUNCHER_DIR}/main.py" \
recipes=training/llama/hf_llama3_8b_seq8k_trn1x4_pretrain \
base_results_dir="${SAGEMAKER_TRAINING_LAUNCHER_DIR}/results" \
recipes.run.name="hf-llama3-8b" \
instance_type=trn1.32xlarge \
recipes.model.model_config="$MODEL_CONFIG" \
cluster=k8s \
cluster_type=k8s \
container="${IMAGE}" \
recipes.data.train_dir=$TRAIN_DIR \
recipes.data.val_dir=$VAL_DIR
```
+ Avvia il processo.
```
bash launcher_scripts/llama/run_hf_llama3_8b_seq8k_trn1x4_pretrain.sh
```
Dopo aver inviato un job di addestramento, puoi utilizzare il comando seguente per verificare se l’invio è riuscito.
```
kubectl get pods
NAME READY STATUS RESTARTS AGE
hf-llama3--worker-0 0/1 running 0 36s
```
Se lo `STATUS` è `PENDING` o`ContainerCreating`, utilizza il comando seguente per ottenere maggiori dettagli.
```
kubectl describe pod name_of_pod
```
Quando lo STATUS del processo diventa Running, puoi esaminare il log utilizzando il comando seguente.
```
kubectl logs name_of_pod
```
`STATUS` diventa `Completed` quando esegui `kubectl get pods`.
Per ulteriori informazioni sulla connessione al cluster k8s, consulta [Tutorial di preaddestramento sul cluster Trainium Kubernetes](#sagemaker-hyperpod-trainium-kubernetes-cluster-pretrain-tutorial).
# SageMaker lavori di formazione tutorial di pre-formazione (GPU)
Questo tutorial ti guida attraverso il processo di configurazione ed esecuzione di un processo di pre-formazione utilizzando processi di formazione con SageMaker istanze GPU.
+ Configurare l'ambiente
+ Avvia un processo di formazione utilizzando le ricette SageMaker HyperPod
Prima di cominciare, assicurati che i requisiti seguenti siano soddisfatti.
**Prerequisiti**
Prima di iniziare a configurare l’ambiente, assicurati di avere:
FSx File system Amazon o un bucket Amazon S3 in cui caricare i dati e generare gli artefatti di addestramento.
È stata richiesta una quota di servizio per 1x ml.p4d.24xlarge e 1x ml.p5.48xlarge su Amazon AI. SageMaker Per richiedere un aumento delle Service Quotas, procedi come descritto di seguito:
Nella console AWS Service Quotas, accedi ai AWS servizi,
Scegli **Amazon SageMaker AI**.
Scegli un’istanza ml.p4d.24xlarge e un’istanza ml.p5.48xlarge.
Crea un ruolo AWS Identity and Access Management(IAM) con le seguenti politiche gestite per concedere all' SageMaker IA le autorizzazioni per eseguire gli esempi.
AmazonSageMakerFullAccess
Amazon EC2 FullAccess
I dati in uno dei seguenti formati:
JSON
JSONGZ (JSON compresso)
ARROW
(Facoltativo) Se utilizzi i pesi modello di cui disponi HuggingFace per il pre-allenamento o la messa a punto, devi ricevere un HuggingFace token. Per ulteriori informazioni su come ottenere il token, consulta [User access tokens](https://huggingface.co/docs/hub/en/security-tokens).
## Configurazione dell'ambiente di lavoro di formazione su GPU SageMaker
Prima di eseguire un processo di SageMaker formazione, configura le AWS credenziali e la regione preferita eseguendo il `aws configure` comando. In alternativa al comando configure, puoi fornire le tue credenziali tramite variabili di ambiente come`AWS_ACCESS_KEY_ID`, e `AWS_SESSION_TOKEN.` Per ulteriori informazioni`AWS_SECRET_ACCESS_KEY`, consulta [SageMaker AI Python SDK](https://github.com/aws/sagemaker-python-sdk).
Consigliamo vivamente di utilizzare un notebook SageMaker AI Jupyter in SageMaker AI JupyterLab per avviare un processo di formazione. SageMaker Per ulteriori informazioni, consulta [SageMaker JupyterLab](studio-updated-jl.md).
+ (Facoltativo) Configura l’ambiente virtuale e le dipendenze. Se utilizzi un notebook Jupyter in Amazon SageMaker Studio, puoi saltare questo passaggio. Assicurati di utilizzare Python 3.9 o versioni successive.
```
# set up a virtual environment
python3 -m venv ${PWD}/venv
source venv/bin/activate
# install dependencies after git clone.
git clone --recursive git@github.com:aws/sagemaker-hyperpod-recipes.git
cd sagemaker-hyperpod-recipes
pip3 install -r requirements.txt
# Set the aws region.
aws configure set
```
+ Installa SageMaker AI Python SDK
```
pip3 install --upgrade sagemaker
```
+ `Container`: Il contenitore GPU viene impostato automaticamente dall'SDK SageMaker AI Python. Puoi anche fornire un tuo container.
**Nota**
Se stai eseguendo un job di addestramento multimodale Llama 3.2, la versione di `transformers` deve essere `4.45.2 `o superiore.
Aggiungi `transformers==4.45.2` `requirements.txt` a `source_dir` solo quando usi SageMaker AI Python SDK. Ad esempio, aggiungilo se lo usi in un notebook in AI. SageMaker JupyterLab
Se utilizzi HyperPod ricette per l'avvio utilizzando il tipo di cluster`sm_jobs`, ciò verrà eseguito automaticamente.
## Avvio del job di addestramento con un notebook Jupyter
Puoi usare il seguente codice Python per eseguire un processo di SageMaker formazione con la tua ricetta. Sfrutta lo PyTorch stimatore dell'[SDK AI SageMaker Python](https://sagemaker.readthedocs.io/en/stable/) per inviare la ricetta. L'esempio seguente avvia la ricetta llama3-8b sulla piattaforma AI Training. SageMaker
```
import os
import sagemaker,boto3
from sagemaker.debugger import TensorBoardOutputConfig
from sagemaker.pytorch import PyTorch
sagemaker_session = sagemaker.Session()
role = sagemaker.get_execution_role()
bucket = sagemaker_session.default_bucket()
output = os.path.join(f"s3://{bucket}", "output")
output_path = ""
overrides = {
"run": {
"results_dir": "/opt/ml/model",
},
"exp_manager": {
"exp_dir": "",
"explicit_log_dir": "/opt/ml/output/tensorboard",
"checkpoint_dir": "/opt/ml/checkpoints",
},
"model": {
"data": {
"train_dir": "/opt/ml/input/data/train",
"val_dir": "/opt/ml/input/data/val",
},
},
}
tensorboard_output_config = TensorBoardOutputConfig(
s3_output_path=os.path.join(output, 'tensorboard'),
container_local_output_path=overrides["exp_manager"]["explicit_log_dir"]
)
estimator = PyTorch(
output_path=output_path,
base_job_name=f"llama-recipe",
role=role,
instance_type="ml.p5.48xlarge",
training_recipe="training/llama/hf_llama3_8b_seq8k_gpu_p5x16_pretrain",
recipe_overrides=recipe_overrides,
sagemaker_session=sagemaker_session,
tensorboard_output_config=tensorboard_output_config,
)
estimator.fit(inputs={"train": "s3 or fsx input", "val": "s3 or fsx input"}, wait=True)
```
Il codice precedente crea un oggetto PyTorch estimatore con la ricetta di addestramento e quindi adatta il modello utilizzando il metodo. `fit()` Utilizza il parametro training\$1recipe per specificare la ricetta da utilizzare per l’addestramento.
**Nota**
Se stai eseguendo un job di addestramento multimodale Llama 3.2, la versione di transformers deve essere 4.45.2 o superiore.
Aggiungi `transformers==4.45.2` `requirements.txt` a `source_dir` solo quando utilizzi direttamente SageMaker AI Python SDK. Ad esempio, devi aggiungere la versione al file di testo quando utilizzi un notebook Jupyter.
Quando distribuisci l'endpoint per un lavoro di SageMaker formazione, devi specificare l'URI dell'immagine che stai utilizzando. Se non lo fornisci, lo strumento di stima utilizza l’immagine di addestramento per l’implementazione. Le immagini di formazione SageMaker HyperPod fornite non contengono le dipendenze necessarie per l'inferenza e la distribuzione. Di seguito è riportato un esempio di come utilizzare un’immagine di inferenza per l’implementazione:
```
from sagemaker import image_uris
container=image_uris.retrieve(framework='pytorch',region='us-west-2',version='2.0',py_version='py310',image_scope='inference', instance_type='ml.p4d.24xlarge')
predictor = estimator.deploy(initial_instance_count=1,instance_type='ml.p4d.24xlarge',image_uri=container)
```
**Nota**
L'esecuzione del codice precedente sull'istanza del notebook Sagemaker potrebbe richiedere più dei 5 GB di spazio di archiviazione predefiniti forniti dall'intelligenza artificiale. SageMaker JupyterLab Se riscontri problemi relativi allo spazio non disponibile, crea una nuova istanza del notebook di tipo diverso e aumenta lo spazio di archiviazione del notebook.
## Avvio del job di addestramento con l’utilità di avvio delle ricette
Aggiorna il file `./recipes_collection/cluster/sm_jobs.yaml` in modo che abbia il seguente aspetto:
```
sm_jobs_config:
output_path:
tensorboard_config:
output_path:
container_logs_path: /opt/ml/output/tensorboard # Path to logs on the container
wait: True # Whether to wait for training job to finish
inputs: # Inputs to call fit with. Set either s3 or file_system, not both.
s3: # Dictionary of channel names and s3 URIs. For GPUs, use channels for train and validation.
train:
val: null
additional_estimator_kwargs: # All other additional args to pass to estimator. Must be int, float or string.
max_run: 180000
enable_remote_debug: True
recipe_overrides:
exp_manager:
explicit_log_dir: /opt/ml/output/tensorboard
data:
train_dir: /opt/ml/input/data/train
model:
model_config: /opt/ml/input/data/train/config.json
compiler_cache_url: ""
```
Aggiorna `./recipes_collection/config.yaml` per specificare `sm_jobs` in `cluster` e `cluster_type`.
```
defaults:
- _self_
- cluster: sm_jobs # set to `slurm`, `k8s` or `sm_jobs`, depending on the desired cluster
- recipes: training/llama/hf_llama3_8b_seq8k_trn1x4_pretrain
cluster_type: sm_jobs # bcm, bcp, k8s or sm_jobs. If bcm, k8s or sm_jobs, it must match - cluster above.
```
Avvia il processo con il comando seguente.
```
python3 main.py --config-path recipes_collection --config-name config
```
Per ulteriori informazioni sulla configurazione dei lavori di SageMaker formazione, consulta Esegui un lavoro di formazione sui lavori di formazione. SageMaker
# Tutorial di pre-formazione sui lavori SageMaker di formazione Trainium
Questo tutorial ti guida attraverso il processo di configurazione ed esecuzione di un lavoro di pre-formazione utilizzando lavori di formazione con SageMaker AWS istanze Trainium.
+ Configurare l'ambiente
+ Avvio di un job di addestramento
Prima di cominciare, assicurati che i requisiti seguenti siano soddisfatti.
**Prerequisiti**
Prima di iniziare a configurare l’ambiente, assicurati di avere:
FSx File system Amazon o bucket S3 in cui è possibile caricare i dati e generare gli artefatti di addestramento.
Richiedi una quota di servizio per l'`ml.trn1.32xlarge`istanza su Amazon SageMaker AI. Per richiedere un aumento delle Service Quotas, procedi come descritto di seguito:
Vai alla console AWS Service Quotas.
Scegli i AWS servizi.
Seleziona JupyterLab.
Specifica un’istanza per `ml.trn1.32xlarge`.
Crea un ruolo AWS Identity and Access Management (IAM) con `AmazonSageMakerFullAccess` le policy `AmazonEC2FullAccess` gestite. Queste politiche forniscono ad Amazon SageMaker AI le autorizzazioni per eseguire gli esempi.
I dati in uno dei seguenti formati:
JSON
JSONGZ (JSON compresso)
ARROW
(Facoltativo) Se ti servono i pesi preallenati di HuggingFace o se stai allenando un modello Llama 3.2, devi ottenere il HuggingFace token prima di iniziare l'allenamento. Per ulteriori informazioni su come ottenere il token, consulta [User access tokens](https://huggingface.co/docs/hub/en/security-tokens).
## Configura il tuo ambiente per i lavori di formazione Trainium SageMaker
Prima di eseguire un processo di SageMaker formazione, utilizza il `aws configure` comando per configurare AWS le credenziali e la regione preferita. In alternativa, puoi fornire le tue credenziali anche tramite variabili di ambiente come `AWS_ACCESS_KEY_ID`, `AWS_SECRET_ACCESS_KEY` e `AWS_SESSION_TOKEN`. Per ulteriori informazioni, consulta [SageMaker AI Python SDK](https://github.com/aws/sagemaker-python-sdk).
Consigliamo vivamente di utilizzare un notebook SageMaker AI Jupyter in SageMaker AI JupyterLab per avviare un processo di formazione. SageMaker Per ulteriori informazioni, consulta [SageMaker JupyterLab](studio-updated-jl.md).
+ (Facoltativo) Se utilizzi il notebook Jupyter in Amazon SageMaker Studio, puoi saltare l'esecuzione del comando seguente. Assicurati di utilizzare una versione uguale o superiore a Python 3.9.
```
# set up a virtual environment
python3 -m venv ${PWD}/venv
source venv/bin/activate
# install dependencies after git clone.
git clone --recursive git@github.com:aws/sagemaker-hyperpod-recipes.git
cd sagemaker-hyperpod-recipes
pip3 install -r requirements.txt
```
+ Installa SageMaker AI Python SDK
```
pip3 install --upgrade sagemaker
```
+
+ Se stai eseguendo un job di addestramento multimodale Llama 3.2, la versione di `transformers` deve essere `4.45.2` o superiore.
+ Aggiungi `transformers==4.45.2` a `requirements.txt` in source\$1dir solo quando utilizzi l'SDK AI Python. SageMaker
+ Se si utilizzano HyperPod ricette da avviare utilizzandole `sm_jobs` come tipo di cluster, non è necessario specificare la versione dei transformers.
+ `Container`: Il contenitore Neuron viene impostato automaticamente da SageMaker AI Python SDK.
## Avvio del job di addestramento con un notebook Jupyter
Puoi usare il seguente codice Python per eseguire un processo di SageMaker formazione utilizzando la tua ricetta. Sfrutta lo PyTorch stimatore dell'[SDK AI SageMaker Python](https://sagemaker.readthedocs.io/en/stable/) per inviare la ricetta. L'esempio seguente avvia la ricetta llama3-8b come AI Training Job. SageMaker
+ `compiler_cache_url`: cache da utilizzare per salvare gli artefatti compilati, ad esempio un artefatto Amazon S3.
```
import os
import sagemaker,boto3
from sagemaker.debugger import TensorBoardOutputConfig
from sagemaker.pytorch import PyTorch
sagemaker_session = sagemaker.Session()
role = sagemaker.get_execution_role()
recipe_overrides = {
"run": {
"results_dir": "/opt/ml/model",
},
"exp_manager": {
"explicit_log_dir": "/opt/ml/output/tensorboard",
},
"data": {
"train_dir": "/opt/ml/input/data/train",
},
"model": {
"model_config": "/opt/ml/input/data/train/config.json",
},
"compiler_cache_url": ""
}
tensorboard_output_config = TensorBoardOutputConfig(
s3_output_path=os.path.join(output, 'tensorboard'),
container_local_output_path=overrides["exp_manager"]["explicit_log_dir"]
)
estimator = PyTorch(
output_path=output_path,
base_job_name=f"llama-trn",
role=role,
instance_type="ml.trn1.32xlarge",
sagemaker_session=sagemaker_session,
training_recipe="training/llama/hf_llama3_70b_seq8k_trn1x16_pretrain",
recipe_overrides=recipe_overrides,
)
estimator.fit(inputs={"train": "your-inputs"}, wait=True)
```
Il codice precedente crea un oggetto PyTorch estimatore con la ricetta di addestramento e quindi adatta il modello utilizzando il metodo. `fit()` Utilizza il parametro `training_recipe` per specificare la ricetta da utilizzare per l’addestramento.
## Avvio del job di addestramento con l’utilità di avvio delle ricette
+ Aggiornamento di `./recipes_collection/cluster/sm_jobs.yaml`
+ compiler\$1cache\$1url: l’URL utilizzato per salvare gli artefatti. Può essere un URL di Amazon S3.
```
sm_jobs_config:
output_path:
wait: True
tensorboard_config:
output_path:
container_logs_path: /opt/ml/output/tensorboard # Path to logs on the container
wait: True # Whether to wait for training job to finish
inputs: # Inputs to call fit with. Set either s3 or file_system, not both.
s3: # Dictionary of channel names and s3 URIs. For GPUs, use channels for train and validation.
train:
val: null
additional_estimator_kwargs: # All other additional args to pass to estimator. Must be int, float or string.
max_run: 180000
image_uri:
enable_remote_debug: True
py_version: py39
recipe_overrides:
model:
exp_manager:
exp_dir:
data:
train_dir: /opt/ml/input/data/train
val_dir: /opt/ml/input/data/val
```
+ Aggiornamento di `./recipes_collection/config.yaml`
```
defaults:
- _self_
- cluster: sm_jobs
- recipes: training/llama/hf_llama3_8b_seq8k_trn1x4_pretrain
cluster_type: sm_jobs # bcm, bcp, k8s or sm_jobs. If bcm, k8s or sm_jobs, it must match - cluster above.
instance_type: ml.trn1.32xlarge
base_results_dir: ~/sm_job/hf_llama3_8B # Location to store the results, checkpoints and logs.
```
+ Avvia il processo con `main.py`.
```
python3 main.py --config-path recipes_collection --config-name config
```
Per ulteriori informazioni sulla configurazione dei lavori di SageMaker formazione, vedere. [SageMaker lavori di formazione tutorial di pre-formazione (GPU)](sagemaker-hyperpod-gpu-sagemaker-training-jobs-pretrain-tutorial.md)
# Configurazioni predefinite
Questa sezione descrive i componenti e le impostazioni essenziali necessari per avviare e personalizzare i processi di formazione utilizzando il Large Language Model (LLM). SageMaker HyperPod Questa sezione descrive i repository chiave, i file di configurazione e le strutture delle ricette che costituiscono la base dei job di addestramento. La comprensione di queste configurazioni predefinite è fondamentale per impostare e gestire in modo efficace i flussi di lavoro di addestramento LLM, sia quando utilizzi le ricette predefinite sia quando le personalizzi in base alle tue esigenze.
**Topics**
+ [GitHub archivi](github-repositories.md)
+ [Configurazione generale](sagemaker-hyperpod-recipes-general-configuration.md)
# GitHub archivi
Per avviare un processo di formazione, si utilizzano file provenienti da due archivi distinti GitHub:
+ [SageMaker HyperPod ricette](https://github.com/aws/sagemaker-hyperpod-recipes)
+ [SageMaker HyperPod adattatore da allenamento per NeMo](https://github.com/aws/sagemaker-hyperpod-training-adapter-for-nemo)
Questi repository contengono componenti essenziali per l’avvio, la gestione e la personalizzazione dei job di addestramento dei modelli linguistici di grandi dimensioni (LLM). Utilizzate gli script dei repository per configurare ed eseguire i lavori di formazione per i vostri. LLMs
## HyperPod archivio di ricette
Usa l'archivio delle [SageMaker HyperPod ricette](https://github.com/aws/sagemaker-hyperpod-recipes) per ottenere una ricetta.
1. `main.py`: Questo file funge da punto di ingresso principale per l'avvio del processo di invio di un lavoro di formazione a un cluster o a un processo di formazione. SageMaker
1. `launcher_scripts`: Questa directory contiene una raccolta di script di uso comune progettati per facilitare il processo di formazione per vari Large Language Models (). LLMs
1. `recipes_collection`: questa cartella contiene una raccolta di ricette LLM predefinite fornite dagli sviluppatori. Gli utenti possono sfruttare queste ricette insieme ai propri dati personalizzati per addestrare modelli LLM personalizzati in base alle loro esigenze specifiche.
Le SageMaker HyperPod ricette vengono utilizzate per avviare attività di formazione o perfezionamento. Indipendentemente dal cluster che stai utilizzando, il processo di invio del processo è lo stesso. Ad esempio, puoi utilizzare lo stesso script per inviare un processo a un cluster Slurm o Kubernetes. L’utilità di avvio invia un job di addestramento in base a tre file di configurazione:
1. Configurazione generale (`config.yaml`): include impostazioni comuni come i parametri predefiniti o le variabili di ambiente utilizzate nel job di addestramento.
1. Configurazione del cluster (cluster): per i job di addestramento che utilizzano solo i cluster. Se stai inviando un job di addestramento a un cluster Kubernetes, potresti dover specificare informazioni come volume, etichetta o policy di riavvio. Per i cluster Slurm, potrebbe essere necessario specificare il nome del processo Slurm. Tutti i parametri sono correlati al cluster specifico che stai utilizzando.
1. Ricetta (ricette): le ricette contengono le impostazioni per il job di addestramento, come i tipi di modello, il grado di sharding o i percorsi dei set di dati. Ad esempio, puoi specificare Llama come modello di addestramento e addestrarlo utilizzando tecniche di parallelizzazione del modello o dei dati come Fully Sharded Distributed Parallel (FSDP) su otto computer. Puoi anche specificare frequenze o percorsi di checkpoint diversi per il tuo job di addestramento.
Dopo aver specificato una ricetta, esegui lo script di avvio per specificare un processo di end-to-end formazione su un cluster in base alle configurazioni tramite il punto di ingresso. `main.py` Per ogni ricetta che utilizzi, sono disponibili script shell di accompagnamento nella cartella launch\$1scripts. Questi esempi ti guidano nelle procedure di invio e avvio dei job di addestramento. La figura seguente illustra come un lanciatore di SageMaker HyperPod ricette invia un processo di formazione a un cluster in base a quanto sopra. Attualmente, il lanciatore di SageMaker HyperPod ricette è basato su Nvidia Framework Launcher. NeMo [Per ulteriori informazioni, consulta NeMo Launcher Guide.](https://docs.nvidia.com/nemo-framework/user-guide/latest/overview.html)
![\[Diagramma che illustra il flusso di lavoro del programma di avvio delle HyperPod ricette. Sulla sinistra, all’interno di una casella tratteggiata, ci sono tre icone di file denominate “Ricetta”, “config.yaml” e “slurm.yaml o k8s.yaml o sm_job.yaml (configurazione cluster)”. Una freccia punta da questo riquadro verso una casella centrale denominata "Recipe Launcher»HyperPod . Da questa casella centrale, un’altra freccia punta a destra verso “Job di addestramento”, con “main.py” scritto sopra la freccia.\]](http://docs.aws.amazon.com/it_it/sagemaker/latest/dg/images/sagemaker-hyperpod-recipe-launcher.png)
## HyperPod archivio di adattatori per ricette
L'adattatore SageMaker HyperPod di formazione è un framework di formazione. Puoi utilizzarlo per gestire l’intero ciclo di vita dei tuoi job di addestramento. Utilizza l’adattatore per implementare il preaddestramento o il fine-tuning dei modelli in più computer. L’adattatore utilizza diverse tecniche di parallelizzazione per distribuire l’addestramento. Gestisce anche l’implementazione e la gestione del salvataggio dei checkpoint. Per ulteriori dettagli, consultare [Impostazioni avanzate](cluster-specific-configurations-advanced-settings.md).
Usa il [repository degli adattatori per SageMaker HyperPod ricette](https://github.com/aws/sagemaker-hyperpod-training-adapter-for-nemo) per utilizzare l'adattatore per ricette.
1. `src`: questa directory contiene l’implementazione dell’addestramento dei modelli linguistici di grandi dimensioni (LLM), che comprende varie funzionalità come la parallelizzazione del modello, l’addestramento di precisione misto e la gestione dei checkpoint.
1. `examples`: questa cartella fornisce una raccolta di esempi che mostrano come creare un punto di ingresso per l’addestramento di un modello LLM e funge da guida pratica per gli utenti.
# Configurazione generale
Il file config.yaml specifica la ricetta di addestramento e il cluster. Include anche configurazioni di runtime come le variabili di ambiente per il job di addestramento.
```
defaults:
- _self_
- cluster: slurm
- recipes: training/llama/hf_llama3_8b_seq8192_gpu
instance_type: p5.48xlarge
git:
repo_url_or_path: null
branch: null
commit: null
entry_script: null
token: null
env_vars:
NCCL_DEBUG: WARN
```
Puoi modificare i parametri seguenti in `config.yaml`:
1. `defaults`: specifica le impostazioni predefinite, ad esempio il cluster predefinito o le ricette predefinite.
1. `instance_type`: modifica il tipo di istanza Amazon EC2 in modo che corrisponda al tipo di istanza che stai utilizzando.
1. `git`: Specificate la posizione dell'archivio degli adattatori di SageMaker HyperPod ricette per il processo di formazione.
1. `env_vars`: puoi specificare le variabili di ambiente da passare al job di addestramento al runtime. Ad esempio, puoi regolare il livello di registrazione di log di NCCL specificando la variabile di ambiente NCCL\$1DEBUG.
La ricetta è la configurazione principale che definisce l’architettura del job di addestramento. Questo file include molte informazioni importanti per il tuo job di addestramento, come le seguenti:
+ Se utilizzare la parallelizzazione del modello
+ L’origine dei tuoi set di dati
+ Addestramento di precisione misto
+ Configurazioni relative ai checkpoint
Puoi utilizzare le ricette così come sono. Oppure, puoi utilizzare le informazioni seguenti per modificarle.
## run
Di seguito sono riportate le informazioni di base per l’esecuzione del job di addestramento.
```
run:
name: llama-8b
results_dir: ${base_results_dir}/${.name}
time_limit: "6-00:00:00"
model_type: hf
```
1. `name`: specifica il nome del job di addestramento nel file di configurazione.
1. `results_dir`: puoi specificare la directory in cui vengono archiviati i risultati del job di addestramento.
1. `time_limit`: puoi impostare un tempo massimo di addestramento per il job di addestramento per evitare che occupi troppo a lungo le risorse hardware.
1. `model_type`: puoi specificare il tipo di modello che stai utilizzando. Ad esempio, è possibile specificare `hf` se il modello proviene da HuggingFace.
## exp\$1manager
exp\$1manager configura l’esperimento. Con exp\$1manager, puoi specificare campi come la directory di output o le impostazioni del checkpoint. Di seguito è riportato un esempio su come configurare exp\$1manager.
```
exp_manager:
exp_dir: null
name: experiment
create_tensorboard_logger: True
```
1. `exp_dir`: la directory degli esperimenti include l’output standard e i file di errore standard per il job di addestramento. Per impostazione predefinita, utilizza la directory corrente.
1. `name`: il nome dell’esperimento utilizzato per identificare l’esperimento in exp\$1dir.
1. `create_tensorboard_logger`: `False` Specificare `True` o abilitare o disabilitare il TensorBoard logger.
## Checkpoint
Ecco i tre tipi di checkpoint supportati:
+ Checkpoint automatici
+ Checkpoint manuali
+ Checkpoint completo
### Checkpoint automatici
Se stai salvando o caricando checkpoint gestiti automaticamente dall'adattatore per SageMaker HyperPod ricette, puoi abilitarli. `auto_checkpoint` Per abilitare `auto_checkpoint`, imposta `enabled` su `True`. Puoi utilizzare i checkpoint automatici sia per l’addestramento che per il fine-tuning. Puoi utilizzare i checkpoint automatici sia per i file system condivisi che per Amazon S3.
```
exp_manager
checkpoint_dir: ${recipes.exp_manager.exp_dir}/checkpoints/
auto_checkpoint:
enabled: True
```
Il checkpoint automatico sta salvando local\$1state\$1dict in modo asincrono con un intervallo di salvataggio ottimale calcolato automaticamente.
**Nota**
Con questa modalità, i checkpoint salvati automaticamente non supportano il re-sharding tra le esecuzioni di addestramento. Per riprendere dall’ultimo checkpoint salvato automaticamente, è necessario mantenere gli stessi gradi di sharding. Non è necessario specificare informazioni aggiuntive per la ripresa automatica.
### Checkpoint manuali
Puoi modificare `checkpoint_callback_params` per salvare in modo asincrono un checkpoint intermedio in shared\$1state\$1dict. Ad esempio, puoi specificare la configurazione seguente per abilitare i checkpoint con shard dopo ogni dieci fasi e mantenere gli ultimi tre checkpoint.
I checkpoint con shard consentono di modificare i gradi di sharding tra le esecuzioni di addestramento e di caricare il checkpoint impostando `resume_from_checkpoint`.
**Nota**
Se si tratta di un fine-tuning PEFT, i checkpoint con shard non supportano Amazon S3.
I checkpoint automatici e manuali si escludono a vicenda.
Sono consentite solo modifiche ai gradi di sharding e di replica FSDP.
```
exp_manager:
checkpoint_callback_params:
# Set save_top_k = 0 to disable sharded checkpointing
save_top_k: 3
every_n_train_steps: 10
monitor: "step"
mode: "max"
save_last: False
resume_from_checkpoint: ${recipes.exp_manager.exp_dir}/checkpoints/
```
Per ulteriori informazioni sui checkpoint, consulta [Checkpointing con SMP](model-parallel-core-features-v2-checkpoints.md).
### Checkpoint completo
Il checkpoint full\$1state\$1dict esportato può essere utilizzato per l’inferenza o il fine-tuning. Puoi caricare un checkpoint completo con hf\$1model\$1name\$1or\$1path. In questa modalità, vengono salvati solo i pesi del modello.
Per esportare il modello full\$1state\$1dict, puoi impostare i parametri seguenti.
**Nota**
Attualmente, i checkpoint completi non sono supportati per Amazon S3. Non puoi impostare il percorso S3 per `exp_manager.checkpoint_dir` se stai abilitando i checkpoint completi. Tuttavia, puoi impostare `exp_manager.export_full_model.final_export_dir` su una directory specifica nel tuo file system locale e `exp_manager.checkpoint_dir` su un percorso Amazon S3.
```
exp_manager:
export_full_model:
# Set every_n_train_steps = 0 to disable full checkpointing
every_n_train_steps: 0
save_last: True
final_export_dir : null
```
## modello
Definisci i vari aspetti dell’architettura del modello e del job di addestramento. Sono incluse le impostazioni per la parallelizzazione del modello, la precisione e la gestione dei dati. Di seguito sono riportati i componenti chiave che puoi configurare nella sezione del modello:
### parallelizzazione del modello
Dopo aver specificato la ricetta, definisci il modello che stai addestrando. Puoi anche definire la parallelizzazione del modello. Ad esempio, puoi definire tensor\$1model\$1parallel\$1degree. Puoi abilitare altre funzionalità come l'allenamento con FP8 precisione. Ad esempio, puoi addestrare un modello con la parallelizzazione tensoriale e la parallelizzazione contestuale:
```
model:
model_type: llama_v3
# Base configs
train_batch_size: 4
val_batch_size: 1
seed: 12345
grad_clip: 1.0
# Model parallelism
tensor_model_parallel_degree: 4
expert_model_parallel_degree: 1
context_parallel_degree: 2
```
Per comprendere meglio le diverse tecniche di parallelizzazione del modello, puoi fare riferimento ai seguenti approcci:
1. [Parallelizzazione tensoriale](model-parallel-core-features-v2-tensor-parallelism.md)
1. [Parallelizzazione degli esperti](model-parallel-core-features-v2-expert-parallelism.md)
1. [Parallelizzazione del contesto](model-parallel-core-features-v2-context-parallelism.md)
1. [Parallelizzazione dei dati sottoposti a sharding](model-parallel-core-features-v2-sharded-data-parallelism.md)
### FP8
Per abilitare FP8 (precisione a virgola mobile a 8 bit), puoi specificare la configurazione FP8 relativa nell'esempio seguente:
```
model:
# FP8 config
fp8: True
fp8_amax_history_len: 1024
fp8_amax_compute_algo: max
```
È importante notare che il formato FP8 dei dati è attualmente supportato solo sul tipo di istanza P5. Se utilizzi un tipo di istanza precedente, come P4, disabilita la FP8 funzionalità per il processo di addestramento del modello. Per ulteriori informazioni su FP8, consulta[Addestramento di precisione misto](model-parallel-core-features-v2-mixed-precision.md).
### data
Puoi specificare i set di dati personalizzati per il job di addestramento aggiungendo i percorsi dei dati nei dati. Il modulo dati del nostro sistema supporta i seguenti formati dei dati:
1. JSON
1. JSONGZ (JSON compresso)
1. ARROW
Tuttavia, la preparazione del set di dati pretokenizzato è una tua responsabilità. Se sei un utente esperto e hai requisiti specifici, puoi anche implementare e integrare un modulo dati personalizzato. Per ulteriori informazioni sui HuggingFace set di dati, vedere [Datasets](https://huggingface.co/docs/datasets/v3.1.0/en/index).
```
model:
data:
train_dir: /path/to/your/train/data
val_dir: /path/to/your/val/data
dataset_type: hf
use_synthetic_data: False
```
Puoi specificare come stai addestrando il modello. Per impostazione predefinita, la ricetta utilizza il preaddestramento anziché il fine-tuning. L’esempio seguente configura la ricetta per eseguire un processo di fine-tuning con LoRA (Low-Rank Adaptation).
```
model:
# Fine tuning config
do_finetune: True
# The path to resume from, needs to be HF compatible
hf_model_name_or_path: null
hf_access_token: null
# PEFT config
peft:
peft_type: lora
rank: 32
alpha: 16
dropout: 0.1
```
[Per informazioni sulle ricette, vedi SageMaker HyperPod ricette.](https://github.com/aws/sagemaker-hyperpod-recipes)
# Configurazioni specifiche dei cluster
SageMaker HyperPod offre flessibilità nell'esecuzione di lavori di formazione in diversi ambienti di cluster. Ogni ambiente ha requisiti e processi di configurazione specifici. Questa sezione descrive i passaggi e le configurazioni necessarie per eseguire i lavori di formazione in SageMaker HyperPod Slurm, SageMaker HyperPod k8s e i lavori di formazione. SageMaker La comprensione di queste configurazioni è fondamentale per sfruttare efficacemente la potenza dell’addestramento distribuito nell’ambiente prescelto.
Puoi utilizzare una ricetta negli ambienti cluster seguenti:
+ SageMaker HyperPod Orchestrazione Slurm
+ SageMaker HyperPod Orchestrazione di servizi Amazon Elastic Kubernetes
+ SageMaker lavori di formazione
Per avviare un job di addestramento in un cluster, imposta e installa la configurazione e l’ambiente del cluster corrispondenti.
**Topics**
+ [Esecuzione di un lavoro di formazione su HyperPod Slurm](cluster-specific-configurations-run-training-job-hyperpod-slurm.md)
+ [Esecuzione di un processo di formazione su k8s HyperPod](cluster-specific-configurations-run-training-job-hyperpod-k8s.md)
+ [SageMaker Esecuzione di un processo di formazione](cluster-specific-configurations-run-sagemaker-training-job.md)
# Esecuzione di un lavoro di formazione su HyperPod Slurm
SageMaker HyperPod Recipes supporta l'invio di un lavoro di formazione a un GPU/Trainium cluster slurm. Prima di inviare il job di addestramento, aggiorna la configurazione del cluster. Utilizza uno dei metodi seguenti per aggiornare la configurazione del cluster:
+ Modificare le `slurm.yaml`
+ Sovrascrivila tramite la riga di comando
Dopo aver aggiornato la configurazione del cluster, installa l’ambiente.
## Configurazione del cluster
Per inviare un job di addestramento a un cluster Slurm, imposta la configurazione specifica per Slurm. Modifica `slurm.yaml` per configurare il cluster Slurm. Di seguito è riportato un esempio di configurazione del cluster Slurm. Puoi modificare questo file in base alle tue esigenze di addestramento:
```
job_name_prefix: 'sagemaker-'
slurm_create_submission_file_only: False
stderr_to_stdout: True
srun_args:
# - "--no-container-mount-home"
slurm_docker_cfg:
docker_args:
# - "--runtime=nvidia"
post_launch_commands:
container_mounts:
- "/fsx:/fsx"
```
1. `job_name_prefix`: specifica un prefisso per il nome del processo per identificare facilmente i tue invii al cluster Slurm.
1. `slurm_create_submission_file_only`: imposta questa configurazione su True per un’esecuzione di prova che faciliti il debug.
1. `stderr_to_stdout`: specifica se stai reindirizzando l’errore standard (stderr) all’output standard (stdout).
1. `srun_args`: personalizza le configurazioni srun aggiuntive, ad esempio escludendo nodi di calcolo specifici. Per ulteriori informazioni, consulta la documentazione relativa a srun.
1. `slurm_docker_cfg`: Il programma di avvio delle SageMaker HyperPod ricette avvia un contenitore Docker per eseguire il processo di formazione. Puoi specificare argomenti Docker aggiuntivi all’interno di questo parametro.
1. `container_mounts`: specifica i volumi che stai montando nel container nell’utilità di avvio delle ricette per consentire ai job di addestramento di accedere ai file in quei volumi.
# Esecuzione di un processo di formazione su k8s HyperPod
SageMaker HyperPod Recipes supporta l'invio di un lavoro di formazione a un cluster GPU/Trainium Kubernetes. Prima di inviare il job di addestramento, completa una delle operazioni seguenti:
+ Modifica il file di configurazione del cluster `k8s.yaml`
+ Sovrascrivi la configurazione del cluster tramite la riga di comando
Dopo aver eseguito una delle fasi precedenti, installa l’ambiente corrispondente.
## Configurazione del cluster con `k8s.yaml`
Per inviare un job di addestramento a un cluster Kubernetes, devi impostare le configurazioni specifiche per Kubernetes. Le configurazioni includono il namespace del cluster o la posizione del volume persistente.
```
pullPolicy: Always
restartPolicy: Never
namespace: default
persistent_volume_claims:
- null
```
1. `pullPolicy`: puoi specificare la policy pull quando invii un job di addestramento. Se specifichi “Sempre”, il cluster Kubernetes estrae sempre l’immagine dal repository. Per ulteriori informazioni, consulta [Image pull policy](https://kubernetes.io/docs/concepts/containers/images/#image-pull-policy).
1. `restartPolicy`: specifica se riavviare il job di addestramento se non riesce.
1. `namespace`: puoi specificare il namespace Kubernetes a cui viene inviato il job di addestramento.
1. `persistent_volume_claims`: puoi specificare un volume condiviso per il tuo job di addestramento per consentire a tutti i processi di addestramento di accedere ai file nel volume.
# SageMaker Esecuzione di un processo di formazione
SageMaker HyperPod Recipes supporta l'invio di un lavoro SageMaker di formazione. Prima di inviare il job di addestramento, devi aggiornare la configurazione del cluster, `sm_job.yaml`, e installare l’ambiente corrispondente.
## Usa la tua ricetta come lavoro SageMaker formativo
Puoi usare la tua ricetta come lavoro di SageMaker formazione se non gestisci un cluster. È necessario modificare il file di configurazione del processo di SageMaker formazione per eseguire la ricetta. `sm_job.yaml`
```
sm_jobs_config:
output_path: null
tensorboard_config:
output_path: null
container_logs_path: null
wait: True
inputs:
s3:
train: null
val: null
file_system:
directory_path: null
additional_estimator_kwargs:
max_run: 1800
```
1. `output_path`: puoi specificare dove salvare il modello in un URL Amazon S3.
1. `tensorboard_config`: È possibile specificare una configurazione TensorBoard correlata, ad esempio il percorso di output o il percorso TensorBoard dei registri.
1. `wait`: puoi specificare se stai aspettando il completamento del processo quando invii il tuo job di addestramento.
1. `inputs`: puoi specificare i percorsi per i dati di addestramento e convalida. L'origine dati può provenire da un file system condiviso come Amazon FSx o un URL Amazon S3.
1. `additional_estimator_kwargs`: Argomenti di valutazione aggiuntivi per l'invio di un lavoro di formazione alla piattaforma Training Job. SageMaker Per ulteriori informazioni, consulta [Algorithm Estimator](https://sagemaker.readthedocs.io/en/stable/api/training/algorithm.html).
# Considerazioni
Quando utilizzi una SageMaker HyperPod ricetta Amazon, ci sono alcuni fattori che possono influire sul processo di formazione dei modelli.
+ La versione di `transformers` deve essere uguale o superiore a `4.45.2` per Llama 3.2. Se utilizzi un flusso di lavoro Slurm o K8s, la versione viene aggiornata automaticamente.
+ Mixtral non supporta la precisione in virgola mobile a 8 bit () FP8
+ L'istanza Amazon EC2 p4 non supporta FP8
# Impostazioni avanzate
L'adattatore per SageMaker HyperPod ricette è basato sui framework Nvidia Nemo e PyTorch-Lightning. Se hai già utilizzato questi framework, l'integrazione di modelli o funzionalità personalizzati nell'adattatore per ricette è un processo simile. SageMaker HyperPod Oltre a modificare l’adattatore delle ricette, puoi modificare il tuo script di preaddestramento o di fine-tuning. Per indicazioni su come scrivere uno script di addestramento personalizzato, consulta gli [esempi](https://github.com/aws/sagemaker-hyperpod-training-adapter-for-nemo/tree/main/examples).
## Usa l' SageMaker HyperPod adattatore per creare il tuo modello
All’interno dell’adattatore delle ricette, puoi personalizzare i file seguenti nelle posizioni specificate:
1. `collections/data`: contiene un modulo responsabile del caricamento dei set di dati. Attualmente supporta solo set di dati provenienti da HuggingFace. Se hai requisiti più avanzati, la struttura del codice ti consente di aggiungere moduli dati personalizzati all’interno della stessa cartella.
1. `collections/model`: include le definizioni di vari modelli linguistici. Al momento, supporta i modelli linguistici di grandi dimensioni più diffusi, come Llama, Mixtral e Mistral. Questa opzione ti offre la flessibilità di introdurre le tue definizioni del modello all’interno di questa cartella.
1. `collections/parts`: questa cartella contiene strategie per addestrare i modelli in modo distribuito. Un esempio è la strategia Fully Sharded Data Parallel (FSDP), che consente lo sharding di un modello linguistico di grandi dimensioni su più acceleratori. Inoltre, le strategie supportano varie forme di parallelizzazione del modello. Puoi anche introdurre strategie di addestramento personalizzate per l’addestramento dei modelli.
1. `utils`: contiene varie utilità volte a facilitare la gestione di un job di addestramento. Funge da repository dove conservare i propri strumenti. Puoi utilizzare i tuoi strumenti per attività come la risoluzione dei problemi o il benchmarking. Puoi anche aggiungere i tuoi callback PyTorch Lightning personalizzati all'interno di questa cartella. Puoi utilizzare i callback PyTorch Lightning per integrare senza problemi funzionalità o operazioni specifiche nel ciclo di vita della formazione.
1. `conf`: contiene le definizioni dello schema di configurazione utilizzate per convalidare parametri specifici in un job di addestramento. Se introduci nuovi parametri o configurazioni, puoi aggiungere lo schema personalizzato a questa cartella. Puoi utilizzare lo schema personalizzato per definire le regole di convalida. Puoi convalidare tipi di dati, intervalli o qualsiasi altro vincolo di parametro. Puoi anche definire uno schema personalizzato per convalidare i parametri.
# Appendice
Consulta la sezione seguente per ottenere informazioni sul monitoraggio e l’analisi dei risultati dell’addestramento.
## Monitoraggio dei risultati dell’addestramento
Il monitoraggio e l'analisi dei risultati della formazione sono essenziali per gli sviluppatori per valutare la convergenza e risolvere i problemi. SageMaker HyperPod le ricette offrono l'integrazione con Tensorboard per analizzare il comportamento di allenamento. Per affrontare le sfide legate alla profilazione di lavori di formazione distribuiti su larga scala, queste ricette includono anche. VizTracer VizTracerè uno strumento a basso costo per tracciare e visualizzare l'esecuzione del codice Python. Per ulteriori informazioni su, vedere. VizTracer [VizTracer](https://viztracer.readthedocs.io/en/latest/installation.html)
Le seguenti sezioni ti guidano nel processo di implementazione di queste funzionalità nelle tue SageMaker HyperPod ricette.
### TensorBoard
TensorBoard è un potente strumento per visualizzare e analizzare il processo di addestramento. Per abilitare TensorBoard, modifica la ricetta impostando il parametro seguente:
```
exp_manager:
exp_dir: null
name: experiment
create_tensorboard_logger: True
```
Dopo aver abilitato il logger TensorBoard, i log di addestramento vengono generati e archiviati nella directory degli esperimenti. L’esperimento è definito in exp\$1manager.exp\$1dir. Per accedere ai log e analizzarli in locale, procedi come indicato di seguito:
**Per accedere ai log e analizzarli**
1. Scarica la cartella degli esperimenti TensorBoard dal tuo ambiente di addestramento al computer locale.
1. Apri un prompt del terminale o di comando sul tuo computer locale.
1. Passa alla directory che contiene la cartella degli esperimenti scaricata.
1. Avvia TensorBoard con il comando seguente.
```
tensorboard --port= --bind_all --logdir experiment.
```
1. Apri il browser web e vai a http://localhost:8008.
Ora puoi vedere lo stato e le visualizzazioni dei tuoi job di addestramento all’interno dell’interfaccia TensorBoard. L’accesso allo stato e alle visualizzazioni consente di monitorare e analizzare il processo di addestramento. Il monitoraggio e l’analisi del processo di addestramento consentono di ottenere informazioni approfondite sul comportamento e sulle prestazioni dei modelli. Per ulteriori informazioni su come monitorare e analizzare la formazione con Tensorboard, consulta la Guida per l'utente di [NVIDIA Framework NeMo ](https://docs.nvidia.com/nemo-framework/user-guide/latest/llms/index.html).
### VizTracer
Per abilitarlo VizTracer, puoi modificare la tua ricetta impostando il parametro model.viztracer.enabled su true. Ad esempio, puoi aggiornare la ricetta del lama per VizTracer abilitarla aggiungendo la seguente configurazione:
```
model:
viztracer:
enabled: true
```
Una volta completata la formazione, il tuo VizTracer profilo si trova nella cartella degli esperimenti exp\$1dir/result.json. Per analizzare il tuo profilo, puoi scaricarlo e aprirlo utilizzando lo strumento vizviewer:
```
vizviewer --port result.json
```
Questo comando avvia vizviewer sulla porta 9001. Puoi visualizzarlo VizTracer specificando http://localhost: nel tuo browser. Dopo l'apertura VizTracer, iniziate ad analizzare l'allenamento. Per ulteriori informazioni sull'utilizzo VizTracer, consultate VizTracer la documentazione.
## SageMaker JumpStart contro SageMaker HyperPod
Sebbene SageMaker JumpStart forniscano funzionalità di ottimizzazione, le SageMaker HyperPod ricette forniscono quanto segue:
+ Controllo granulare aggiuntivo sul ciclo di addestramento
+ Personalizzazione delle ricette per i tuoi modelli e dati
+ Supporto per la parallelizzazione del modello
Utilizza le SageMaker HyperPod ricette quando hai bisogno di accedere agli iperparametri del modello, all'addestramento multinodo e alle opzioni di personalizzazione per il ciclo di allenamento.
Per ulteriori informazioni sulla messa a punto dei modelli, consulta SageMaker JumpStart [Fine-tuning dei modelli di fondazione disponibili al pubblico con la classe `JumpStartEstimator`](jumpstart-foundation-models-use-python-sdk-estimator-class.md)
# Orchestrazione SageMaker HyperPod dei cluster con Slurm
Il supporto di Slurm SageMaker HyperPod consente di fornire cluster resilienti per l'esecuzione di carichi di lavoro di machine learning (ML) e lo sviluppo di state-of-the-art modelli come modelli di linguaggio di grandi dimensioni (), modelli di diffusione e modelli di base (LLMs). FMs Accelera lo sviluppo FMs eliminando gli oneri indifferenziati legati alla creazione e alla manutenzione di cluster di elaborazione su larga scala alimentati da migliaia di acceleratori come Trainium e NVIDIA A100 e H100 Graphical Processing Units (). AWS GPUs In caso di guasto degli acceleratori, le funzionalità di resilienza dei SageMaker HyperPod monitor e delle istanze cluster rilevano e sostituiscono automaticamente l'hardware difettoso in modo che tu possa concentrarti sull'esecuzione di carichi di lavoro ML. Inoltre, con il supporto per la configurazione del ciclo di vita SageMaker HyperPod, puoi personalizzare il tuo ambiente di elaborazione per adattarlo al meglio alle tue esigenze e configurarlo con le librerie di formazione distribuite di Amazon SageMaker AI per ottenere prestazioni ottimali su. AWS
**Gestione dei cluster**
È possibile creare, configurare e gestire SageMaker HyperPod i cluster graficamente tramite l'interfaccia utente della console (UI) e programmaticamente tramite l'interfaccia a AWS riga di comando (CLI) oppure. AWS SDK per Python (Boto3) Con Amazon VPC, puoi proteggere la rete del cluster e anche trarre vantaggio dalla configurazione del cluster con risorse nel tuo VPC, come Amazon FSx for Lustre, che offre il throughput più veloce. Puoi anche assegnare diversi ruoli IAM ai gruppi di istanze del cluster e limitare le azioni che le risorse e gli utenti del cluster possono eseguire. Per ulteriori informazioni, consulta [SageMaker HyperPod Operazioni del cluster Slurm](sagemaker-hyperpod-operate-slurm.md).
**Configurazione dell’ambiente di ML**
SageMaker HyperPod viene eseguito[SageMaker HyperPod DLAMI](sagemaker-hyperpod-ref.md#sagemaker-hyperpod-ref-hyperpod-ami), che configura un ambiente ML sui cluster. HyperPod Puoi configurare personalizzazioni aggiuntive per DLAMI fornendo script del ciclo di vita per supportare il tuo caso d’uso. Per ulteriori informazioni su come configurare gli script del ciclo di vita, consulta [Iniziare con SageMaker HyperPod](smcluster-getting-started-slurm.md) e [Personalizzazione dei SageMaker HyperPod cluster utilizzando script del ciclo di vita](sagemaker-hyperpod-lifecycle-best-practices-slurm.md).
**Pianificazione dei processi**
Dopo aver creato correttamente un HyperPod cluster, gli utenti del cluster possono accedere ai nodi del cluster (come il nodo principale o controller, il nodo di accesso e il nodo di lavoro) e pianificare i lavori per l'esecuzione di carichi di lavoro di machine learning. Per ulteriori informazioni, consulta [Lavori su cluster SageMaker HyperPod](sagemaker-hyperpod-run-jobs-slurm.md).
**Resilienza contro i guasti hardware**
SageMaker HyperPod esegue controlli di integrità sui nodi del cluster e fornisce una funzionalità di ripristino automatico del carico di lavoro. Con le funzionalità di resilienza del cluster di HyperPod, puoi riprendere il carico di lavoro dall'ultimo checkpoint salvato, dopo che i nodi difettosi sono stati sostituiti con nodi integri in cluster con più di 16 nodi. Per ulteriori informazioni, consulta [SageMaker HyperPod resilienza del cluster](sagemaker-hyperpod-resiliency-slurm.md).
**Registrazione di log e gestione dei cluster**
Puoi trovare i parametri di utilizzo SageMaker HyperPod delle risorse e i log del ciclo di vita in Amazon e gestire le SageMaker HyperPod risorse CloudWatch taggandole. Ogni esecuzione dell’API `CreateCluster` crea un flusso di log distinto, denominato in base al formato `-`. Nel flusso di log, puoi controllare i nomi degli host, il nome degli script del ciclo di vita non riusciti e gli output degli script non riusciti, ad esempio `stdout` e `stderr`. Per ulteriori informazioni, consulta [SageMaker HyperPod gestione dei cluster](sagemaker-hyperpod-cluster-management-slurm.md).
** SageMaker Compatibile con gli strumenti di intelligenza artificiale**
Utilizzando SageMaker HyperPod, puoi configurare i cluster con librerie di comunicazioni collettive AWS ottimizzate offerte dall' SageMaker IA, come la libreria [SageMaker AI Distributed Data Parallelism (SMDDP](data-parallel.md)). La libreria SMDDP implementa il `AllGather` funzionamento ottimizzato per l'infrastruttura di AWS calcolo e di rete per le istanze di machine learning AI più performanti SageMaker basate su NVIDIA A100. GPUs Per ulteriori informazioni, consulta [Esecuzione di carichi di lavoro di formazione distribuiti con Slurm on HyperPod](sagemaker-hyperpod-run-jobs-slurm-distributed-training-workload.md).
**Posizionamento delle istanze con UltraServers**
SageMaker L'intelligenza artificiale alloca automaticamente i lavori alle istanze interne all'azienda sulla UltraServer base di una strategia che prevede al massimo l'utilizzo di tutte le istanze di una UltraServer prima di utilizzarne un'altra. Ad esempio, se richiedi 14 istanze e ne hai 2 UltraServers nel tuo piano di allenamento, l' SageMaker IA utilizza tutte le istanze della prima. UltraServer Se hai richiesto 20 istanze e ne hai 2 UltraServers nel tuo piano di allenamento, l' SageMaker IA utilizzerà tutte le 17 istanze nella prima UltraServer e poi ne utilizzerà 3 nella seconda. UltraServer
**Topics**
+ [Iniziare con SageMaker HyperPod](smcluster-getting-started-slurm.md)
+ [SageMaker HyperPod Operazioni del cluster Slurm](sagemaker-hyperpod-operate-slurm.md)
+ [Personalizzazione dei SageMaker HyperPod cluster utilizzando script del ciclo di vita](sagemaker-hyperpod-lifecycle-best-practices-slurm.md)
+ [SageMaker HyperPod supporto per nodi multitesta](sagemaker-hyperpod-multihead-slurm.md)
+ [Lavori su cluster SageMaker HyperPod](sagemaker-hyperpod-run-jobs-slurm.md)
+ [SageMaker HyperPod monitoraggio delle risorse del cluster](sagemaker-hyperpod-cluster-observability-slurm.md)
+ [SageMaker HyperPod resilienza del cluster](sagemaker-hyperpod-resiliency-slurm.md)
+ [Provisioning continuo per operazioni avanzate del cluster con Slurm](sagemaker-hyperpod-scaling-slurm.md)
+ [SageMaker HyperPod gestione dei cluster](sagemaker-hyperpod-cluster-management-slurm.md)
+ [SageMaker HyperPod FAQs](sagemaker-hyperpod-faq-slurm.md)
# Iniziare con SageMaker HyperPod
Inizia a creare il tuo primo SageMaker HyperPod cluster e scopri le funzionalità operative del cluster di. SageMaker HyperPod Puoi creare un SageMaker HyperPod cluster tramite l'interfaccia utente della console SageMaker AI o i AWS CLI comandi. Questo tutorial mostra come creare un nuovo SageMaker HyperPod cluster con Slurm, un popolare software di pianificazione del carico di lavoro. Dopo aver seguito questo tutorial, saprai come accedere ai nodi del cluster usando i AWS Systems Manager comandi (). `aws ssm` Dopo aver completato questo tutorial, consulta anche [SageMaker HyperPod Operazioni del cluster Slurm](sagemaker-hyperpod-operate-slurm.md) per saperne di più sulle operazioni SageMaker HyperPod di base e [Lavori su cluster SageMaker HyperPod](sagemaker-hyperpod-run-jobs-slurm.md) per imparare a pianificare i lavori sul cluster predisposto.
**Suggerimento**
[Per trovare esempi e soluzioni pratiche, vedi anche il SageMaker HyperPod workshop.](https://catalog.workshops.aws/sagemaker-hyperpod)
**Topics**
+ [Guida introduttiva all' SageMaker HyperPod utilizzo della console SageMaker AI](smcluster-getting-started-slurm-console.md)
+ [Creazione di cluster utilizzando modelli SageMaker HyperPod CloudFormation](smcluster-getting-started-slurm-console-create-cluster-cfn.md)
+ [Guida introduttiva all'utilizzo di SageMaker HyperPod AWS CLI](smcluster-getting-started-slurm-cli.md)
# Guida introduttiva all' SageMaker HyperPod utilizzo della console SageMaker AI
Il seguente tutorial mostra come creare un nuovo SageMaker HyperPod cluster e configurarlo con Slurm tramite l'interfaccia utente della console SageMaker AI. Seguendo il tutorial, creerai un HyperPod cluster con tre nodi Slurm,, e. `my-controller-group` `my-login-group` `worker-group-1`
**Topics**
+ [Crea un cluster](#smcluster-getting-started-slurm-console-create-cluster-page)
+ [Distribuire le risorse](#smcluster-getting-started-slurm-console-create-cluster-deploy)
+ [Eliminazione del cluster e pulizia delle risorse](#smcluster-getting-started-slurm-console-delete-cluster-and-clean)
## Crea un cluster
Per accedere alla pagina **SageMaker HyperPod Clusters** e scegliere **Slurm** orchestration, segui questi passaggi.
1. Apri la console Amazon SageMaker AI all'indirizzo [https://console.aws.amazon.com/sagemaker/](https://console.aws.amazon.com/sagemaker/).
1. Scegli **HyperPod Clusters** nel riquadro di navigazione a sinistra, quindi **Cluster Management**.
1. Nella pagina **SageMaker HyperPod Cluster, scegli **Crea HyperPod ** cluster**.
1. Nel menu a discesa **Crea HyperPod cluster**, scegli **Orchestrated** by Slurm.
1. Nella pagina di creazione del cluster Slurm sono disponibili due opzioni. Scegli quella più adatta alle tue esigenze.
1. **Configurazione rapida**: per iniziare subito con le impostazioni predefinite, scegli **Configurazione rapida**. Con questa opzione, l' SageMaker intelligenza artificiale creerà nuove risorse come VPC, sottoreti, gruppi di sicurezza, bucket Amazon S3, ruolo IAM e FSx for Lustre nel processo di creazione del cluster.
1. **Configurazione personalizzata**: per l’integrazione con le risorse AWS esistenti o per soddisfare requisiti di rete, sicurezza o archiviazione specifici, scegli **Configurazione personalizzata**. Con questa opzione, puoi scegliere di utilizzare le risorse esistenti o crearne di nuove e puoi personalizzare la configurazione in base alle tue esigenze.
## Configurazione rapida
Nella sezione **Configurazione rapida**, segui questi passaggi per creare il tuo cluster con l'orchestrazione Slurm. HyperPod
### Impostazioni generali
Specifica un nome per il nuovo cluster. Dopo la creazione del cluster, non è più possibile modificarne il nome.
### Gruppi di istanze
Per aggiungere un gruppo di istanze, scegli **Aggiungi gruppo**. Ogni gruppo di istanze può essere configurato in modo diverso ed è possibile creare un cluster eterogeneo composto da più gruppi di istanze con vari tipi di istanze. Per implementare un cluster, devi aggiungere almeno un gruppo di istanze per i tipi di gruppo Controller e Calcolo.
**Importante**
Puoi aggiungere un gruppo di istanze alla volta. Per creare più gruppi di istanze, ripeti il processo per ogni gruppo.
Segui questa procedura per aggiungere un gruppo di istanze.
1. In **Tipo di gruppo di istanze**, scegli un tipo per il tuo gruppo di istanze. Per questo tutorial, scegli **Controller (head)** per `my-controller-group`, **Login** per `my-login-group` e **Calcolo (worker)** per `worker-group-1`.
1. In **Nome**, specifica un nome per il gruppo di istanze. Per questo tutorial, crea tre gruppi di istanze denominati `my-controller-group`, `my-login-group` e `worker-group-1`.
1. In **Capacità dell’istanza**, scegli la capacità on demand o un piano di addestramento per riservare le tue risorse di calcolo.
1. Per **Tipo di istanza**, scegli l’istanza per il gruppo di istanze. Per questo tutorial, seleziona `ml.c5.xlarge` per `my-controller-group`, `ml.m5.4xlarge` per `my-login-group` e `ml.trn1.32xlarge` per `worker-group-1`.
**Importante**
Assicurati di selezionare un tipo di istanza con quote sufficienti e un numero adeguato di indirizzi IP non assegnati per il tuo account. Per visualizzare o richiedere quote aggiuntive, consulta [SageMaker HyperPod quote](sagemaker-hyperpod-prerequisites.md#sagemaker-hyperpod-prerequisites-quotas).
1. In **Quantità istanze**. specifica un numero intero che non sia maggiore della quota dell’istanza per l’utilizzo del cluster. Per questo tutorial, inserisci **1** per tutti e tre i gruppi.
1. In **Zona di disponibilità di destinazione**, scegli la zona di disponibilità in cui allocare le istanze. La zona di disponibilità deve corrispondere alla posizione della capacità di calcolo accelerata.
1. Per **Volume di archiviazione aggiuntivo per istanza (GB) (facoltativo)**, specifica un numero intero compreso tra 1 e 16.384 per impostare la dimensione di un volume Elastic Block Store (EBS) aggiuntivo in gigabyte (GB). Il volume EBS è collegato a ciascuna istanza del gruppo di istanze. Il percorso di montaggio predefinito per il volume EBS aggiuntivo è `/opt/sagemaker`. Dopo aver creato correttamente il cluster, è possibile accedere tramite SSH alle istanze del cluster (nodi) e verificare che il volume EBS sia montato correttamente eseguendo il comando `df -h`. Il collegamento di un volume EBS aggiuntivo fornisce un’archiviazione stabile, fuori istanza e con persistenza indipendente, come descritto nella sezione [Amazon EBS volumes](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-volumes.html) in *Amazon Elastic Block Store User Guide*.
1. Scegli **Aggiungi gruppo di istanze**.
### Impostazioni predefinite della configurazione rapida
Questa sezione elenca tutte le impostazioni predefinite per la creazione del cluster, incluse tutte le nuove AWS risorse che verranno create durante il processo di creazione del cluster. Verificare le impostazioni predefinite.
## Configurazione personalizzata
Nella sezione **Configurazione personalizzata**, segui questi passaggi per creare il tuo HyperPod cluster con l'orchestrazione Slurm.
### Impostazioni generali
Specifica un nome per il nuovo cluster. Dopo la creazione del cluster, non è più possibile modificarne il nome.
In **Ripristino dell’istanza**, scegli **Automatico *(consigliato)*** o **Nessuno**.
### Rete
Configura le impostazioni di rete per la creazione del cluster. Queste impostazioni non possono essere modificate dopo la creazione del cluster.
1. Per quanto riguarda il **VPC**, scegli il tuo VPC se ne hai già uno che consente all' SageMaker IA di accedere al tuo VPC. Per creare un nuovo VPC, segui le istruzioni in [Create a VPC](https://docs.aws.amazon.com/vpc/latest/userguide/create-vpc.html) in *Amazon Virtual Private Cloud User Guide*. Puoi lasciarlo su **Nessuno** per utilizzare il VPC SageMaker AI predefinito.
1. Per il **blocco VPC IPv4 CIDR**, inserisci l'IP iniziale del tuo VPC.
1. Per le **zone di disponibilità**, scegli le zone di disponibilità (AZ) in cui HyperPod verranno create le sottoreti per il tuo cluster. Scegli AZs quella che corrisponde alla posizione della tua capacità di elaborazione accelerata.
1. In **Gruppi di sicurezza**, crea un gruppo di sicurezza o scegli fino a cinque gruppi di sicurezza configurati con regole per consentire la comunicazione tra risorse all’interno del VPC.
### Gruppi di istanze
Per aggiungere un gruppo di istanze, scegli **Aggiungi gruppo**. Ogni gruppo di istanze può essere configurato in modo diverso ed è possibile creare un cluster eterogeneo composto da più gruppi di istanze con vari tipi di istanze. Per implementare un cluster, devi aggiungere almeno un gruppo di istanze.
**Importante**
Puoi aggiungere un gruppo di istanze alla volta. Per creare più gruppi di istanze, ripeti il processo per ogni gruppo.
Segui questa procedura per aggiungere un gruppo di istanze.
1. In **Tipo di gruppo di istanze**, scegli un tipo per il tuo gruppo di istanze. Per questo tutorial, scegli **Controller (head)** per `my-controller-group`, **Login** per `my-login-group` e **Calcolo (worker)** per `worker-group-1`.
1. In **Nome**, specifica un nome per il gruppo di istanze. Per questo tutorial, crea tre gruppi di istanze denominati `my-controller-group`, `my-login-group` e `worker-group-1`.
1. In **Capacità dell’istanza**, scegli la capacità on demand o un piano di addestramento per riservare le tue risorse di calcolo.
1. Per **Tipo di istanza**, scegli l’istanza per il gruppo di istanze. Per questo tutorial, seleziona `ml.c5.xlarge` per `my-controller-group`, `ml.m5.4xlarge` per `my-login-group` e `ml.trn1.32xlarge` per `worker-group-1`.
**Importante**
Assicurati di selezionare un tipo di istanza con quote sufficienti e un numero adeguato di indirizzi IP non assegnati per il tuo account. Per visualizzare o richiedere quote aggiuntive, consulta [SageMaker HyperPod quote](sagemaker-hyperpod-prerequisites.md#sagemaker-hyperpod-prerequisites-quotas).
1. In **Quantità istanze**. specifica un numero intero che non sia maggiore della quota dell’istanza per l’utilizzo del cluster. Per questo tutorial, inserisci **1** per tutti e tre i gruppi.
1. In **Zona di disponibilità di destinazione**, scegli la zona di disponibilità in cui allocare le istanze. La zona di disponibilità deve corrispondere alla posizione della capacità di calcolo accelerata.
1. Per **Volume di archiviazione aggiuntivo per istanza (GB) (facoltativo)**, specifica un numero intero compreso tra 1 e 16.384 per impostare la dimensione di un volume Elastic Block Store (EBS) aggiuntivo in gigabyte (GB). Il volume EBS è collegato a ciascuna istanza del gruppo di istanze. Il percorso di montaggio predefinito per il volume EBS aggiuntivo è `/opt/sagemaker`. Dopo aver creato correttamente il cluster, è possibile accedere tramite SSH alle istanze del cluster (nodi) e verificare che il volume EBS sia montato correttamente eseguendo il comando `df -h`. Il collegamento di un volume EBS aggiuntivo fornisce un’archiviazione stabile, fuori istanza e con persistenza indipendente, come descritto nella sezione [Amazon EBS volumes](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-volumes.html) in *Amazon Elastic Block Store User Guide*.
1. Scegli **Aggiungi gruppo di istanze**.
### Script del ciclo di vita
Puoi scegliere di utilizzare gli script del ciclo di vita predefiniti o quelli personalizzati, che verranno archiviati nel tuo bucket Amazon S3. [Puoi visualizzare gli script del ciclo di vita predefiniti nell'archivio Awesome Distributed Training. GitHub ](https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/7.sagemaker-hyperpod-eks/LifecycleScripts) Per ulteriori informazioni sugli script del ciclo di vita, consulta [Personalizzazione dei SageMaker HyperPod cluster utilizzando script del ciclo di vita](sagemaker-hyperpod-lifecycle-best-practices-slurm.md).
1. In **Script del ciclo di vita**, scegli tra script del ciclo di vita predefiniti o personalizzati.
1. In **Bucket S3 per gli script del ciclo di vita**, scegli se creare un nuovo bucket o utilizzare un bucket esistente per archiviare gli script del ciclo di vita.
### Permissions
Scegli o crea un ruolo IAM che HyperPod consenta di eseguire e accedere alle AWS risorse necessarie per tuo conto.
### Archiviazione
Configura il file system FSx for Lustre da fornire sul HyperPod cluster.
1. Per **File system**, scegliete un file system FSx for Lustre esistente, FSx per crearne uno nuovo, oppure non installatene uno FSx per Lustre.
1. In **Throughput per unità di archiviazione**, scegli il throughput che sarà disponibile per ogni TiB di archiviazione allocata.
1. In **Capacità di archiviazione**, inserisci un valore di capacità in TB.
1. Per **Tipo di compressione dei dati**, scegliete di **LZ4**abilitare la compressione dei dati.
1. In **Versione Lustre**, visualizza il valore consigliato per i nuovi file system.
### Tag (facoltativo)
Per i **tag: *facoltativo***, aggiungi coppie di chiavi e valori al nuovo cluster e gestisci il cluster come AWS risorsa. Per ulteriori informazioni, consulta [Tagging delle risorse AWS](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html).
## Distribuire le risorse
Dopo aver completato le configurazioni del cluster utilizzando **Configurazione rapida** o **Configurazione personalizzata**, scegli l’opzione seguente per avviare il provisioning delle risorse e la creazione del cluster.
+ **Invia**: l' SageMaker IA inizierà a fornire le risorse di configurazione predefinite e a creare il cluster.
+ **Scarica i parametri del CloudFormation modello**: scaricherai il file JSON dei parametri di configurazione ed eseguirai il AWS CLI comando per distribuire lo CloudFormation stack per fornire le risorse di configurazione e creare il cluster. Se necessario, puoi modificare il file JSON dei parametri scaricato. Se scegli questa opzione, consulta [Creazione di cluster utilizzando modelli SageMaker HyperPod CloudFormation](smcluster-getting-started-slurm-console-create-cluster-cfn.md) per ulteriori informazioni.
## Eliminazione del cluster e pulizia delle risorse
Dopo aver testato con successo la creazione di un SageMaker HyperPod cluster, questo continua a funzionare nello `InService` stato fino a quando non lo elimini. Ti consigliamo di eliminare tutti i cluster creati utilizzando istanze SageMaker AI su richiesta quando non sono in uso per evitare di incorrere in costi di servizio continui in base ai prezzi su richiesta. In questo tutorial hai creato un cluster costituito da due gruppi di istanze. Uno di essi utilizza un’istanza C5, quindi assicurati di eliminare il cluster seguendo le istruzioni riportate in [Eliminare un SageMaker HyperPod cluster](sagemaker-hyperpod-operate-slurm-console-ui.md#sagemaker-hyperpod-operate-slurm-console-ui-delete-cluster).
Tuttavia, se hai creato un cluster con capacità di calcolo riservata, lo stato dei cluster non influisce sulla fatturazione del servizio.
Per pulire gli script del ciclo di vita dal bucket S3 utilizzato per questo tutorial, vai al bucket S3 che hai utilizzato durante la creazione del cluster e rimuovi completamente i file.
Se hai testato l'esecuzione di carichi di lavoro sul cluster, assicurati di aver caricato dati o di aver salvato artefatti in diversi bucket S3 o servizi di file system come Amazon FSx for Lustre e Amazon Elastic File System. Per evitare addebiti, elimina tutti gli artefatti e i dati dall’archiviazione o dal file system.
# Creazione di cluster utilizzando modelli SageMaker HyperPod CloudFormation
È possibile creare SageMaker HyperPod cluster utilizzando i CloudFormation modelli per. HyperPod È necessario eseguire l'installazione AWS CLI per procedere.
**Topics**
+ [Configura le risorse nella console e distribuiscile utilizzando CloudFormation](#smcluster-getting-started-slurm-console-create-cluster-deploy-console)
+ [Configura le risorse e distribuiscile utilizzando CloudFormation](#smcluster-getting-started-slurm-console-create-cluster-deploy-cfn)
## Configura le risorse nella console e distribuiscile utilizzando CloudFormation
È possibile configurare le risorse utilizzando Console di gestione AWS e distribuire utilizzando i CloudFormation modelli.
Segui questa procedura.
1. *Invece di scegliere **Invia***, scegli **Scarica i parametri del CloudFormation modello** alla fine del tutorial in[Guida introduttiva all' SageMaker HyperPod utilizzo della console SageMaker AI](smcluster-getting-started-slurm-console.md). Il tutorial contiene importanti informazioni di configurazione, necessarie per creare correttamente il cluster.
**Importante**
Se scegli **Invia**, non sarai in grado di implementare un cluster con lo stesso nome finché non elimini il cluster.
Dopo aver scelto **Scarica i parametri del CloudFormation modello**, **la finestra Utilizzo del file di configurazione per creare il cluster tramite** la AWS CLI finestra apparirà sul lato destro della pagina.
1. Nella finestra **Utilizzo del file di configurazione per creare il cluster con la AWS CLI**, scegli **Scarica il file dei parametri di configurazione**. Il file verrà scaricato sul tuo computer. Puoi modificare il file JSON di configurazione in base alle tue esigenze o lasciarlo così com’è, se non sono necessarie modifiche.
1. In un terminale, vai alla posizione del file dei parametri `file://params.json`.
1. Esegui il AWS CLI comando [create-stack](https://docs.aws.amazon.com//cli/latest/reference/cloudformation/create-stack.html) per distribuire lo CloudFormation stack che fornirà le risorse configurate e creerà il cluster. HyperPod
```
aws cloudformation create-stack
--stack-name my-stack
--template-url https://aws-sagemaker-hyperpod-cluster-setup.amazonaws.com/templates-slurm/main-stack-slurm-based-template.yaml
--parameters file://params.json
--capabilities CAPABILITY_IAM CAPABILITY_NAMED_IAM
```
1. [Per visualizzare lo stato del provisioning delle risorse, accedi alla console. CloudFormation ](https://console.aws.amazon.com/cloudformation)
**Una volta completata la creazione del cluster, visualizza il nuovo cluster in Cluster nel riquadro principale della console.** SageMaker HyperPod Puoi anche controllarne lo stato nella colonna **Stato**.
1. Quando lo stato del cluster diventa `InService`, puoi iniziare ad accedere ai nodi del cluster. Per accedere ai nodi del cluster e iniziare a eseguire carichi di lavoro di ML, consulta [Lavori su cluster SageMaker HyperPod](sagemaker-hyperpod-run-jobs-slurm.md).
## Configura le risorse e distribuiscile utilizzando CloudFormation
È possibile configurare le risorse e distribuirle utilizzando i CloudFormation modelli per. SageMaker HyperPod
Segui questa procedura.
1. Scarica un CloudFormation modello per SageMaker HyperPod dal [sagemaker-hyperpod-cluster-setup](https://github.com/aws/sagemaker-hyperpod-cluster-setup) GitHub repository.
1. Esegui il AWS CLI comando [create-stack](https://docs.aws.amazon.com//cli/latest/reference/cloudformation/create-stack.html) per distribuire lo CloudFormation stack che fornirà le risorse configurate e creerà il cluster. HyperPod
```
aws cloudformation create-stack
--stack-name my-stack
--template-url URL_of_the_file_that_contains_the_template_body
--parameters file://params.json
--capabilities CAPABILITY_IAM CAPABILITY_NAMED_IAM
```
1. Per visualizzare lo stato del provisioning delle risorse, accedere alla console CloudFormation .
Una volta completata la creazione del cluster, visualizza il nuovo cluster in **Clusters nel riquadro principale** della console. SageMaker HyperPod Puoi anche controllarne lo stato nella colonna **Stato**.
1. Quando lo stato del cluster diventa `InService`, puoi iniziare ad accedere ai nodi del cluster. Per accedere ai nodi del cluster e iniziare a eseguire carichi di lavoro di ML, consulta [Lavori su cluster SageMaker HyperPod](sagemaker-hyperpod-run-jobs-slurm.md).
# Guida introduttiva all'utilizzo di SageMaker HyperPod AWS CLI
Crea il tuo primo SageMaker HyperPod cluster utilizzando i AWS CLI comandi per HyperPod.
## Crea il tuo primo SageMaker HyperPod cluster con Slurm
[Il seguente tutorial mostra come creare un nuovo SageMaker HyperPod cluster e configurarlo con Slurm tramite i comandi per.AWS CLI SageMaker HyperPod](sagemaker-hyperpod-ref.md#sagemaker-hyperpod-ref-cli) Seguendo il tutorial, creerai un HyperPod cluster con tre nodi Slurm:,, e. `my-controller-group` `my-login-group` `worker-group-1`
Con l'approccio di configurazione basato sull'API, definisci i tipi di nodi Slurm e le assegnazioni delle partizioni direttamente nella richiesta API utilizzando. CreateCluster `SlurmConfig` Ciò elimina la necessità di un `provisioning_parameters.json` file separato e fornisce funzionalità integrate di convalida, rilevamento delle deviazioni e configurazione. per-instance-group FSx
1. Prima di tutto, prepara e carica gli script del ciclo di vita su un bucket Amazon S3. Durante la creazione del cluster, li HyperPod esegue in ogni gruppo di istanze. Carica gli script del ciclo di vita su Amazon S3 utilizzando il comando seguente.
```
aws s3 sync \
~/local-dir-to-lifecycle-scripts/* \
s3://sagemaker-//src
```
**Nota**
Il percorso del bucket S3 deve iniziare con un prefisso`sagemaker-`, poiché il [ruolo IAM for SageMaker HyperPod](sagemaker-hyperpod-prerequisites-iam.md#sagemaker-hyperpod-prerequisites-iam-role-for-hyperpod) with consente l'accesso `AmazonSageMakerClusterInstanceRolePolicy` solo ai bucket Amazon S3 che iniziano con il prefisso specifico.
[Se parti da zero, usa gli script del ciclo di vita di esempio forniti nell'archivio Awsome Distributed Training. GitHub ](https://github.com/aws-samples/awsome-distributed-training/) I seguenti passaggi secondari mostrano come scaricare e caricare gli script del ciclo di vita di esempio in un bucket Amazon S3.
1. Scarica una copia degli script del ciclo di vita di esempio in una directory sul computer locale.
```
git clone https://github.com/aws-samples/awsome-distributed-training/
```
1. Accedi alla directory [https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config](https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config), dove puoi trovare un set di script del ciclo di vita.
```
cd awsome-distributed-training/1.architectures/5.sagemaker_hyperpods/LifecycleScripts/base-config
```
Per ulteriori informazioni sugli esempi di script del ciclo di vita, consulta [Personalizzazione dei SageMaker HyperPod cluster utilizzando script del ciclo di vita](sagemaker-hyperpod-lifecycle-best-practices-slurm.md).
1. Carica gli script su `s3://sagemaker-//src`. Puoi eseguire questa operazione con la console di Amazon S3 o con il comando della AWS CLI Amazon S3 seguente.
```
aws s3 sync \
~/local-dir-to-lifecycle-scripts/* \
s3://sagemaker-//src
```
**Nota**
Con la configurazione basata su API, non è necessario creare o caricare un file. `provisioning_parameters.json` La configurazione Slurm viene definita direttamente nella richiesta CreateCluster API nel passaggio successivo.
1. Prepara un file di [CreateCluster](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_CreateCluster.html)richiesta in formato JSON e salvalo con nome. `create_cluster.json`
Con la configurazione basata su API, è possibile specificare il tipo di nodo Slurm e l'assegnazione della partizione per ciascun gruppo di istanze utilizzando il campo. `SlurmConfig` È inoltre possibile configurare le impostazioni Slurm a livello di cluster utilizzando. `Orchestrator.Slurm`
Per `ExecutionRole`, fornisci l’ARN del ruolo IAM che hai creato con la policy gestita `AmazonSageMakerClusterInstanceRolePolicy` in [Prerequisiti per l'utilizzo SageMaker HyperPod](sagemaker-hyperpod-prerequisites.md).
```
{
"ClusterName": "my-hyperpod-cluster",
"InstanceGroups": [
{
"InstanceGroupName": "my-controller-group",
"InstanceType": "ml.c5.xlarge",
"InstanceCount": 1,
"SlurmConfig": {
"NodeType": "Controller"
},
"LifeCycleConfig": {
"SourceS3Uri": "s3://sagemaker-//src",
"OnCreate": "on_create.sh"
},
"ExecutionRole": "arn:aws:iam:::role/HyperPodExecutionRole",
"InstanceStorageConfigs": [
{
"EbsVolumeConfig": {
"VolumeSizeInGB": 500
}
}
]
},
{
"InstanceGroupName": "my-login-group",
"InstanceType": "ml.m5.4xlarge",
"InstanceCount": 1,
"SlurmConfig": {
"NodeType": "Login"
},
"LifeCycleConfig": {
"SourceS3Uri": "s3://sagemaker-//src",
"OnCreate": "on_create.sh"
},
"ExecutionRole": "arn:aws:iam:::role/HyperPodExecutionRole"
},
{
"InstanceGroupName": "worker-group-1",
"InstanceType": "ml.trn1.32xlarge",
"InstanceCount": 1,
"SlurmConfig": {
"NodeType": "Compute",
"PartitionNames": ["partition-1"]
},
"LifeCycleConfig": {
"SourceS3Uri": "s3://sagemaker-//src",
"OnCreate": "on_create.sh"
},
"ExecutionRole": "arn:aws:iam:::role/HyperPodExecutionRole"
}
],
"Orchestrator": {
"Slurm": {
"SlurmConfigStrategy": "Managed"
}
}
}
```
**SlurmConfig campi**:
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/sagemaker/latest/dg/smcluster-getting-started-slurm-cli.html)
**Campi Orchestrator.Slurm:**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/sagemaker/latest/dg/smcluster-getting-started-slurm-cli.html)
**SlurmConfigStrategy opzioni:**
+ `Managed`(consigliato): gestisce `slurm.conf` e rileva HyperPod completamente le modifiche non autorizzate (rilevamento della deriva). Gli aggiornamenti falliscono se viene rilevata una deriva.
+ `Overwrite`: HyperPod `slurm.conf` sovrascrive gli aggiornamenti, ignorando eventuali modifiche manuali.
+ `Merge`: HyperPod conserva le modifiche manuali e le unisce alla configurazione dell'API.
**Aggiunta FSx per Lustre (opzionale):**
Per montare un filesystem FSx for Lustre sui tuoi nodi di calcolo, aggiungilo `FsxLustreConfig` al gruppo for the instance. `InstanceStorageConfigs` Ciò richiede una configurazione VPC personalizzata.
```
{
"InstanceGroupName": "worker-group-1",
"InstanceType": "ml.trn1.32xlarge",
"InstanceCount": 1,
"SlurmConfig": {
"NodeType": "Compute",
"PartitionNames": ["partition-1"]
},
"InstanceStorageConfigs": [
{
"FsxLustreConfig": {
"DnsName": "fs-0abc123def456789.fsx.us-west-2.amazonaws.com",
"MountPath": "/fsx",
"MountName": "abcdefgh"
}
}
],
"LifeCycleConfig": {
"SourceS3Uri": "s3://sagemaker-//src",
"OnCreate": "on_create.sh"
},
"ExecutionRole": "arn:aws:iam:::role/HyperPodExecutionRole"
}
```
**Aggiunta FSx per OpenZFS (opzionale):**
Puoi anche montarlo FSx per i filesystem OpenZFS:
```
"InstanceStorageConfigs": [
{
"FsxOpenZfsConfig": {
"DnsName": "fs-0xyz789abc123456.fsx.us-west-2.amazonaws.com",
"MountPath": "/shared"
}
}
]
```
**Nota**
Ogni gruppo di istanze può avere al massimo uno FSx per la configurazione di Lustre e uno per OpenZFS. FSx Gruppi di istanze diversi possono montare diversi filesystem.
**Aggiungere la configurazione VPC (richiesta per FSx):**
Se si utilizza FSx, è necessario specificare una configurazione VPC personalizzata:
```
{
"ClusterName": "my-hyperpod-cluster",
"InstanceGroups": [
{
"InstanceGroupName": "my-controller-group",
"InstanceType": "ml.c5.xlarge",
"InstanceCount": 1,
"SlurmConfig": {
"NodeType": "Controller"
},
"LifeCycleConfig": {
"SourceS3Uri": "s3://sagemaker-//src",
"OnCreate": "on_create.sh"
},
"ExecutionRole": "arn:aws:iam:::role/HyperPodExecutionRole"
},
],
"Orchestrator": {
"Slurm": {
"SlurmConfigStrategy": "Managed"
}
},
"VpcConfig": {
"SecurityGroupIds": ["sg-0abc123def456789a"],
"Subnets": ["subnet-0abc123def456789a"]
}
}
```
1. Utilizza il comando seguente per creare il cluster.
```
aws sagemaker create-cluster --cli-input-json file://complete/path/to/create_cluster.json
```
Questo dovrebbe restituire l’ARN del cluster creato.
```
{
"ClusterArn": "arn:aws:sagemaker:us-west-2:111122223333:cluster/my-hyperpod-cluster"
}
```
Se ricevi un errore dovuto ai limiti delle risorse, assicurati di sostituire il tipo di istanza con uno che disponga di quote sufficienti nel tuo account oppure richiedi quote aggiuntive seguendo la procedura in [SageMaker HyperPod quote](sagemaker-hyperpod-prerequisites.md#sagemaker-hyperpod-prerequisites-quotas).
**Errori di convalida comuni:**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/sagemaker/latest/dg/smcluster-getting-started-slurm-cli.html)
1. Esegui `describe-cluster` per verificare lo stato del cluster.
```
aws sagemaker describe-cluster --cluster-name my-hyperpod-cluster
```
Risposta di esempio:
```
{
"ClusterArn": "arn:aws:sagemaker:us-west-2:111122223333:cluster/my-hyperpod-cluster",
"ClusterName": "my-hyperpod-cluster",
"ClusterStatus": "Creating",
"InstanceGroups": [
{
"InstanceGroupName": "my-controller-group",
"InstanceType": "ml.c5.xlarge",
"InstanceCount": 1,
"CurrentCount": 0,
"TargetCount": 1,
"SlurmConfig": {
"NodeType": "Controller"
},
"LifeCycleConfig": {
"SourceS3Uri": "s3://sagemaker-/src",
"OnCreate": "on_create.sh"
},
"ExecutionRole": "arn:aws:iam::111122223333:role/HyperPodExecutionRole"
},
{
"InstanceGroupName": "my-login-group",
"InstanceType": "ml.m5.4xlarge",
"InstanceCount": 1,
"CurrentCount": 0,
"TargetCount": 1,
"SlurmConfig": {
"NodeType": "Login"
},
"LifeCycleConfig": {
"SourceS3Uri": "s3://sagemaker-/src",
"OnCreate": "on_create.sh"
},
"ExecutionRole": "arn:aws:iam::111122223333:role/HyperPodExecutionRole"
},
{
"InstanceGroupName": "worker-group-1",
"InstanceType": "ml.trn1.32xlarge",
"InstanceCount": 1,
"CurrentCount": 0,
"TargetCount": 1,
"SlurmConfig": {
"NodeType": "Compute",
"PartitionNames": ["partition-1"]
},
"LifeCycleConfig": {
"SourceS3Uri": "s3://sagemaker-/src",
"OnCreate": "on_create.sh"
},
"ExecutionRole": "arn:aws:iam::111122223333:role/HyperPodExecutionRole"
}
],
"Orchestrator": {
"Slurm": {
"SlurmConfigStrategy": "Managed"
}
},
"CreationTime": "2024-01-15T10:30:00Z"
}
```
Quando lo stato del cluster diventa **InService**, procedi con la fase successiva. La creazione del cluster richiede in genere 10-15 minuti.
1. Esegui `list-cluster-nodes` per controllare i dettagli dei nodi del cluster.
```
aws sagemaker list-cluster-nodes --cluster-name my-hyperpod-cluster
```
Risposta di esempio:
```
{
"ClusterNodeSummaries": [
{
"InstanceGroupName": "my-controller-group",
"InstanceId": "i-0abc123def456789a",
"InstanceType": "ml.c5.xlarge",
"InstanceStatus": {
"Status": "Running",
"Message": ""
},
"LaunchTime": "2024-01-15T10:35:00Z"
},
{
"InstanceGroupName": "my-login-group",
"InstanceId": "i-0abc123def456789b",
"InstanceType": "ml.m5.4xlarge",
"InstanceStatus": {
"Status": "Running",
"Message": ""
},
"LaunchTime": "2024-01-15T10:35:00Z"
},
{
"InstanceGroupName": "worker-group-1",
"InstanceId": "i-0abc123def456789c",
"InstanceType": "ml.trn1.32xlarge",
"InstanceStatus": {
"Status": "Running",
"Message": ""
},
"LaunchTime": "2024-01-15T10:36:00Z"
}
]
}
```
`InstanceId`Questo è ciò di cui gli utenti del cluster hanno bisogno per accedere (`aws ssm`) al loro interno. Per ulteriori informazioni sull’accesso ai nodi del cluster e sull’esecuzione di carichi di lavoro di ML, consulta [Lavori su cluster SageMaker HyperPod](sagemaker-hyperpod-run-jobs-slurm.md).
1. Connect al cluster utilizzando AWS Systems Manager Session Manager.
```
aws ssm start-session \
--target sagemaker-cluster:my-hyperpod-cluster_my-login-group-i-0abc123def456789b \
--region us-west-2
```
Una volta connesso, verifica che Slurm sia configurato correttamente:
```
# Check Slurm nodes
sinfo
# Check Slurm partitions
sinfo -p partition-1
# Submit a test job
srun -p partition-1 --nodes=1 hostname
```
## Eliminazione del cluster e pulizia delle risorse
Dopo aver testato con successo la creazione di un SageMaker HyperPod cluster, questo continua a funzionare nello `InService` stato fino a quando non lo elimini. Ti consigliamo di eliminare tutti i cluster creati utilizzando la capacità di SageMaker intelligenza artificiale su richiesta quando non sono in uso per evitare di incorrere in costi di servizio continui in base ai prezzi su richiesta. In questo tutorial, hai creato un cluster composto da tre gruppi di istanze. Assicurati di eliminare il cluster eseguendo il comando seguente.
```
aws sagemaker delete-cluster --cluster-name my-hyperpod-cluster
```
Per pulire gli script del ciclo di vita dal bucket Amazon S3 utilizzato per questo tutorial, vai al bucket Amazon S3 che hai utilizzato durante la creazione del cluster e rimuovi completamente i file.
```
aws s3 rm s3://sagemaker-//src --recursive
```
Se hai testato l'esecuzione di carichi di lavoro di training su modelli sul cluster, controlla anche se hai caricato dati o se il tuo processo ha salvato artefatti in diversi bucket Amazon S3 o servizi di file system come Amazon FSx for Lustre e Amazon Elastic File System. Per evitare addebiti, elimina tutti gli artefatti e i dati dall’archiviazione o dal file system.
## Argomenti correlati
+ [SageMaker HyperPod Configurazione Slurm](sagemaker-hyperpod-ref.md#sagemaker-hyperpod-ref-slurm-configuration)
+ [Personalizzazione dei SageMaker HyperPod cluster utilizzando script del ciclo di vita](sagemaker-hyperpod-lifecycle-best-practices-slurm.md)
+ [FSx configurazione tramite InstanceStorageConfigs](sagemaker-hyperpod-ref.md#sagemaker-hyperpod-ref-slurm-fsx-config)
+ [SageMaker HyperPod Operazioni del cluster Slurm](sagemaker-hyperpod-operate-slurm.md)
# SageMaker HyperPod Operazioni del cluster Slurm
Questa sezione fornisce indicazioni sulla gestione SageMaker HyperPod tramite l'interfaccia utente della console SageMaker AI o AWS Command Line Interface (CLI). Imparerai come eseguire varie attività correlate a SageMaker HyperPod, sia che tu preferisca un'interfaccia visiva o l'utilizzo dei comandi.
**Topics**
+ [Gestione dei cluster SageMaker HyperPod Slurm tramite la console SageMaker](sagemaker-hyperpod-operate-slurm-console-ui.md)
+ [Gestione dei cluster SageMaker HyperPod Slurm utilizzando il AWS CLI](sagemaker-hyperpod-operate-slurm-cli-command.md)
# Gestione dei cluster SageMaker HyperPod Slurm tramite la console SageMaker
I seguenti argomenti forniscono indicazioni su come gestire SageMaker HyperPod tramite l'interfaccia utente della console.
**Topics**
+ [Crea un SageMaker HyperPod cluster](#sagemaker-hyperpod-operate-slurm-console-ui-create-cluster)
+ [Esplora i tuoi SageMaker HyperPod cluster](#sagemaker-hyperpod-operate-slurm-console-ui-browse-clusters)
+ [Visualizza i dettagli di ogni cluster SageMaker HyperPod](#sagemaker-hyperpod-operate-slurm-console-ui-view-details-of-clusters)
+ [Modifica un SageMaker HyperPod cluster](#sagemaker-hyperpod-operate-slurm-console-ui-edit-clusters)
+ [Eliminare un SageMaker HyperPod cluster](#sagemaker-hyperpod-operate-slurm-console-ui-delete-cluster)
## Crea un SageMaker HyperPod cluster
Consulta le istruzioni [Guida introduttiva all' SageMaker HyperPod utilizzo della console SageMaker AI](smcluster-getting-started-slurm-console.md) per creare un nuovo SageMaker HyperPod cluster tramite l'interfaccia utente della SageMaker HyperPod console.
## Esplora i tuoi SageMaker HyperPod cluster
In **Cluster** nel riquadro principale della SageMaker HyperPod console nella pagina principale della SageMaker HyperPod console, tutti i cluster creati dovrebbero apparire elencati nella sezione **Cluster**, che fornisce una visualizzazione riepilogativa dei cluster, del loro ARNs stato e dell'ora di creazione.
## Visualizza i dettagli di ogni cluster SageMaker HyperPod
In **Cluster** nella pagina principale della console, i **nomi** dei cluster sono attivati come link. Scegli il link del nome del cluster per visualizzare i dettagli di ogni cluster.
## Modifica un SageMaker HyperPod cluster
1. In **Cluster** nel riquadro principale della SageMaker HyperPod console, scegli il cluster che desideri aggiornare.
1. Seleziona il cluster e scegli **Modifica**.
1. Nella pagina **Modifica **, puoi modificare le configurazioni dei gruppi di istanze esistenti, aggiungere altri gruppi di istanze, eliminare i gruppi di istanze e modificare i tag per il cluster. Dopo aver apportato le modifiche, scegli **Invia**.
1. Nella sezione **Configura gruppi di istanze**, puoi aggiungere altri gruppi di istanze scegliendo **Crea gruppo di istanze**.
1. Nella sezione **Configura gruppi di istanze**, puoi scegliere **Modifica** per modificarne la configurazione o **Elimina** per rimuovere definitivamente il gruppo di istanze.
**Importante**
Durante l’eliminazione di un gruppo di istanze, considera i seguenti punti:
Il SageMaker HyperPod cluster deve sempre mantenere almeno un gruppo di istanze.
Assicurati che venga eseguito il backup di tutti i dati critici prima della rimozione.
Il processo di rimozione non può essere annullato.
**Nota**
L’eliminazione di un gruppo di istanze comporterà la terminazione di tutte le risorse di calcolo associate a quel gruppo.
1. Nella sezione **Tag**, puoi aggiornare i tag per il cluster.
## Eliminare un SageMaker HyperPod cluster
1. In **Cluster** nel riquadro principale della SageMaker HyperPod console, scegli il cluster che desideri eliminare.
1. Seleziona il cluster e scegli **Elimina**.
1. Nella finestra pop-up per l’eliminazione del cluster, esamina attentamente le informazioni sul cluster per verificare che il cluster sia quello desiderato.
1. Dopo aver esaminato le informazioni sul cluster, scegli **Sì, elimina il cluster**.
1. Digita **delete** nel campo di testo per confermare l’eliminazione.
1. Scegli **Elimina** nell’angolo in basso a destra della finestra pop-up per completare l’invio della richiesta di eliminazione del cluster.
# Gestione dei cluster SageMaker HyperPod Slurm utilizzando il AWS CLI
I seguenti argomenti forniscono indicazioni sulla scrittura di file di richiesta SageMaker HyperPod API in formato JSON e sulla loro esecuzione utilizzando i AWS CLI comandi.
**Topics**
+ [Creazione di un nuovo cluster](#sagemaker-hyperpod-operate-slurm-cli-command-create-cluster)
+ [Descrizione di un cluster](#sagemaker-hyperpod-operate-slurm-cli-command-describe-cluster)
+ [Elenco dei dettagli dei nodi del cluster](#sagemaker-hyperpod-operate-slurm-cli-command-list-cluster-nodes)
+ [Descrizione dei dettagli di un nodo del cluster](#sagemaker-hyperpod-operate-slurm-cli-command-describe-cluster-node)
+ [Elenco dei cluster](#sagemaker-hyperpod-operate-slurm-cli-command-list-clusters)
+ [Aggiornamento della configurazione del cluster](#sagemaker-hyperpod-operate-slurm-cli-command-update-cluster)
+ [Aggiorna il software della SageMaker HyperPod piattaforma di un cluster](#sagemaker-hyperpod-operate-slurm-cli-command-update-cluster-software)
+ [Riduzione verticale di un cluster](#sagemaker-hyperpod-operate-slurm-cli-command-scale-down)
+ [Eliminazione di un cluster](#sagemaker-hyperpod-operate-slurm-cli-command-delete-cluster)
## Creazione di un nuovo cluster
1. Prepara gli script di configurazione del ciclo di vita e caricali in un bucket S3, ad esempio `s3://sagemaker-amzn-s3-demo-bucket/lifecycle-script-directory/src/`. La fase 2 seguente presuppone che esista uno script del punto di ingresso denominato `on_create.sh` nel bucket S3 specificato.
**Importante**
Assicurati di impostare il percorso S3 in modo che inizi con `s3://sagemaker-`. Al [Ruolo IAM per SageMaker HyperPod](sagemaker-hyperpod-prerequisites-iam.md#sagemaker-hyperpod-prerequisites-iam-role-for-hyperpod) è collegata la policy gestita [https://docs.aws.amazon.com/sagemaker/latest/dg/security-iam-awsmanpol-cluster.html](https://docs.aws.amazon.com/sagemaker/latest/dg/security-iam-awsmanpol-cluster.html), che consente l’accesso ai bucket S3 con il prefisso specifico `sagemaker-`.
1. Preparare un file di richiesta [CreateCluster](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_CreateCluster.html)API in formato JSON. Devi configurare i gruppi di istanze in modo che corrispondano al cluster Slurm progettato nel file `provisioning_parameters.json` che verrà utilizzato durante la creazione del cluster nell’ambito dell’esecuzione di un set di script del ciclo di vita. Per ulteriori informazioni, consulta [Personalizzazione dei SageMaker HyperPod cluster utilizzando script del ciclo di vita](sagemaker-hyperpod-lifecycle-best-practices-slurm.md). Il modello seguente ha due gruppi di istanze per soddisfare i requisiti minimi per un cluster Slurm: un nodo controller (head) e un nodo di calcolo (worker). Per `ExecutionRole`, fornisci l’ARN del ruolo IAM che hai creato con la policy gestita `AmazonSageMakerClusterInstanceRolePolicy` nella sezione [Ruolo IAM per SageMaker HyperPod](sagemaker-hyperpod-prerequisites-iam.md#sagemaker-hyperpod-prerequisites-iam-role-for-hyperpod).
```
// create_cluster.json
{
"ClusterName": "your-hyperpod-cluster",
"InstanceGroups": [
{
"InstanceGroupName": "controller-group",
"InstanceType": "ml.m5.xlarge",
"InstanceCount": 1,
"LifeCycleConfig": {
"SourceS3Uri": "s3://amzn-s3-demo-bucket-sagemaker/lifecycle-script-directory/src/",
"OnCreate": "on_create.sh"
},
"ExecutionRole": "arn:aws:iam::111122223333:role/iam-role-for-cluster",
// Optional: Configure an additional storage per instance group.
"InstanceStorageConfigs": [
{
// Attach an additional EBS volume to each instance within the instance group.
// The default mount path for the additional EBS volume is /opt/sagemaker.
"EbsVolumeConfig":{
// Specify an integer between 1 and 16384 in gigabytes (GB).
"VolumeSizeInGB": integer,
}
}
]
},
{
"InstanceGroupName": "worker-group-1",
"InstanceType": "ml.p4d.xlarge",
"InstanceCount": 1,
"LifeCycleConfig": {
"SourceS3Uri": "s3://amzn-s3-demo-bucket-sagemaker/lifecycle-script-directory/src/",
"OnCreate": "on_create.sh"
},
"ExecutionRole": "arn:aws:iam::111122223333:role/iam-role-for-cluster"
}
],
// Optional
"Tags": [
{
"Key": "string",
"Value": "string"
}
],
// Optional
"VpcConfig": {
"SecurityGroupIds": [ "string" ],
"Subnets": [ "string" ]
}
}
```
A seconda di come progetti la struttura del cluster con gli script del ciclo di vita, puoi configurare fino a 20 gruppi di istanze nel parametro `InstanceGroups`.
Per il parametro di `Tags` richiesta, puoi aggiungere tag personalizzati per la gestione del SageMaker HyperPod cluster come AWS risorsa. Puoi aggiungere tag al tuo cluster nello stesso modo in cui li aggiungi in altri AWS servizi che supportano i tag. Per ulteriori informazioni sull'etichettatura AWS delle risorse in generale, consulta la Guida per l'utente di [Tagging AWS Resources](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html).
Per il parametro di richiesta `VpcConfig`, specifica le informazioni del VPC da utilizzare. Per ulteriori informazioni, consulta [Configurazione SageMaker HyperPod con un Amazon VPC personalizzato](sagemaker-hyperpod-prerequisites.md#sagemaker-hyperpod-prerequisites-optional-vpc).
1. Utilizza il comando [create-cluster](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/create-cluster.html) come segue.
```
aws sagemaker create-cluster \
--cli-input-json file://complete/path/to/create_cluster.json
```
Questo dovrebbe restituire l’ARN del nuovo cluster.
## Descrizione di un cluster
Esegui [describe-cluster](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/describe-cluster.html) per verificare lo stato del cluster. Puoi specificare il nome o l’ARN del cluster.
```
aws sagemaker describe-cluster --cluster-name your-hyperpod-cluster
```
Quando lo stato del cluster diventa **InService**, procedi con la fase successiva. Utilizzando questa API, puoi anche recuperare i messaggi di errore dall'esecuzione di altre HyperPod operazioni API.
## Elenco dei dettagli dei nodi del cluster
Esegui [list-cluster-nodes](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/list-cluster-nodes.html)per controllare le informazioni chiave dei nodi del cluster.
```
aws sagemaker list-cluster-nodes --cluster-name your-hyperpod-cluster
```
Questo restituisce una risposta e `InstanceId` è ciò che ti serve per l’accesso (con `aws ssm`).
## Descrizione dei dettagli di un nodo del cluster
Esegui [describe-cluster-node](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/describe-cluster-node.html)per recuperare i dettagli di un nodo del cluster. È possibile ottenere l'ID del nodo del cluster dall' list-cluster-nodesoutput. Puoi specificare il nome o l’ARN del cluster.
```
aws sagemaker describe-cluster-node \
--cluster-name your-hyperpod-cluster \
--node-id i-111222333444555aa
```
## Elenco dei cluster
Esegui [list-clusters](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/list-clusters.html) per elencare tutti i cluster del tuo account.
```
aws sagemaker list-clusters
```
Puoi anche aggiungere ulteriori flag per filtrare l’elenco dei cluster. Per ulteriori informazioni su cosa viene eseguito questo comando a basso livello e sui flag aggiuntivi per il filtraggio, consulta il riferimento all'[ListClusters](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_ListClusters.html)API.
## Aggiornamento della configurazione del cluster
Esegui [update-cluster](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/update-cluster.html) per aggiornare la configurazione di un cluster.
**Nota**
Puoi utilizzare l'`UpdateCluster`API per ridimensionare o rimuovere interi gruppi di istanze dal cluster SageMaker HyperPod . Per ulteriori istruzioni su come ridurre verticalmente o eliminare i gruppi di istanze, consulta [Riduzione verticale di un cluster](#sagemaker-hyperpod-operate-slurm-cli-command-scale-down).
1. Crea un file di richiesta `UpdateCluster` in formato JSON. Assicurati di specificare correttamente il nome del cluster e il nome del gruppo di istanze da aggiornare. Puoi modificare il tipo di istanza, il numero di istanze, lo script del punto di ingresso della configurazione del ciclo di vita e il percorso dello script.
1. Per `ClusterName`, specifica il nome del cluster da aggiornare.
1. Per `InstanceGroupName`
1. Per aggiornare un gruppo di istanze esistente, specifica il nome del gruppo di istanze da aggiornare.
1. Per aggiungere un nuovo gruppo di istanze, specifica un nuovo nome non presente nel cluster.
1. Per `InstanceType`
1. Per aggiornare un gruppo di istanze esistente, è necessario che il tipo di istanza specificato all’inizio corrisponda al gruppo.
1. Per aggiungere un nuovo gruppo di istanze, specifica il tipo di istanza con cui configurare il gruppo.
1. Per `InstanceCount`
1. Per aggiornare un gruppo di istanze esistente, specifica un numero intero corrispondente al numero di istanze desiderato. Puoi fornire un valore più alto o più basso (fino a 0) per aumentare o ridurre verticalmente il gruppo di istanze.
1. Per aggiungere un nuovo gruppo di istanze, specifica un numero intero maggiore o uguale a 1.
1. Per `LifeCycleConfig`, puoi modificare entrambi i valori `SourceS3Uri` e `OnCreate` per aggiornare il gruppo di istanze.
1. Per `ExecutionRole`
1. Per aggiornare un gruppo di istanze esistente, continua a utilizzare lo stesso ruolo IAM collegato durante la creazione del cluster.
1. Per aggiungere un nuovo gruppo di istanze, specifica un ruolo IAM da collegare.
1. Per `ThreadsPerCore`
1. Per aggiornare un gruppo di istanze esistente, continua a utilizzare lo stesso valore specificato durante la creazione del cluster.
1. Per aggiungere un nuovo gruppo di istanze, puoi scegliere qualsiasi valore tra le opzioni consentite dal tipo di istanza. Per ulteriori informazioni, cerca il tipo di istanza e consulta la colonna **Thread validi per core** nella tabella di riferimento in [CPU cores and threads per CPU core per instance type](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/cpu-options-supported-instances-values.html) in *Amazon EC2 User Guide*.
Puoi utilizzare il frammento di codice seguente, che corrisponde a un modello di file di richiesta JSON. Per ulteriori informazioni sulla sintassi della richiesta e sui parametri di questa API, consulta il riferimento all'[UpdateCluster](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_UpdateCluster.html)API.
```
// update_cluster.json
{
// Required
"ClusterName": "name-of-cluster-to-update",
// Required
"InstanceGroups": [
{
"InstanceGroupName": "name-of-instance-group-to-update",
"InstanceType": "ml.m5.xlarge",
"InstanceCount": 1,
"LifeCycleConfig": {
"SourceS3Uri": "s3://amzn-s3-demo-bucket-sagemaker/lifecycle-script-directory/src/",
"OnCreate": "on_create.sh"
},
"ExecutionRole": "arn:aws:iam::111122223333:role/iam-role-for-cluster",
// Optional: Configure an additional storage per instance group.
"InstanceStorageConfigs": [
{
// Attach an additional EBS volume to each instance within the instance group.
// The default mount path for the additional EBS volume is /opt/sagemaker.
"EbsVolumeConfig":{
// Specify an integer between 1 and 16384 in gigabytes (GB).
"VolumeSizeInGB": integer,
}
}
]
},
// add more blocks of instance groups as needed
{ ... }
]
}
```
1. Esegui il comando `update-cluster` per inviare la richiesta.
```
aws sagemaker update-cluster \
--cli-input-json file://complete/path/to/update_cluster.json
```
## Aggiorna il software della SageMaker HyperPod piattaforma di un cluster
Esegui [update-cluster-software](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/update-cluster-software.html)per aggiornare i cluster esistenti con software e patch di sicurezza fornite dal SageMaker HyperPod servizio. Per `--cluster-name`, specifica il nome o l’ARN del cluster da aggiornare.
**Importante**
Ricorda di eseguire il backup del tuo lavoro prima di applicare questa API. Il processo di applicazione delle patch sostituisce il volume root con l’AMI aggiornata, il che significa che i dati precedenti archiviati nel volume root dell’istanza andranno persi. Assicurati di eseguire il backup dei dati dal volume root dell'istanza su Amazon S3 o Amazon FSx for Lustre. Per ulteriori informazioni, consulta [Utilizza lo script di backup fornito da SageMaker HyperPod](#sagemaker-hyperpod-operate-slurm-cli-command-update-cluster-software-backup).
```
aws sagemaker update-cluster-software --cluster-name your-hyperpod-cluster
```
Questo comando richiama l'API. [UpdateClusterSoftware](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_UpdateClusterSoftware.html) Dopo la chiamata all'API, SageMaker HyperPod verifica se è disponibile un DLAMI più recente per le istanze del cluster. Se è necessario un aggiornamento DLAMI, SageMaker HyperPod aggiornerà le istanze del cluster per utilizzare le più recenti [SageMaker HyperPod DLAMI](sagemaker-hyperpod-ref.md#sagemaker-hyperpod-ref-hyperpod-ami) ed eseguirà gli script del ciclo di vita nel bucket Amazon S3 specificato durante la creazione o l'aggiornamento del cluster. Se il cluster utilizza già il DLAMI più recente, non SageMaker HyperPod apporterà alcuna modifica al cluster né eseguirà nuovamente gli script del ciclo di vita. Il team SageMaker HyperPod di assistenza lancia regolarmente nuovi strumenti per migliorare la sicurezza e migliorare l'esperienza [SageMaker HyperPod DLAMI](sagemaker-hyperpod-ref.md#sagemaker-hyperpod-ref-hyperpod-ami) degli utenti. Ti consigliamo di continuare ad aggiornare sempre alla versione più recente di SageMaker HyperPod DLAMI. Per i futuri aggiornamenti SageMaker HyperPod DLAMI per le patch di sicurezza, segui con. [Note di SageMaker HyperPod rilascio di Amazon](sagemaker-hyperpod-release-notes.md)
**Suggerimento**
Se la patch di sicurezza non riesce, è possibile recuperare i messaggi di errore eseguendo l’API [https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_DescribeCluster.html](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_DescribeCluster.html) come indicato in [Descrizione di un cluster](#sagemaker-hyperpod-operate-slurm-cli-command-describe-cluster).
**Nota**
Puoi eseguire questa API solo in modo programmatico. La funzionalità di patching non è implementata nell'interfaccia utente della SageMaker HyperPod console.
### Utilizza lo script di backup fornito da SageMaker HyperPod
SageMaker HyperPod fornisce uno script per il backup e il ripristino dei dati [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/patching-backup.sh](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/patching-backup.sh)nel * GitHub repository Awsome Distributed Training*. Lo script fornisce le funzioni seguenti.
**Per eseguire il backup dei dati su un bucket S3 prima dell’applicazione delle patch**
```
sudo bash patching-backup.sh --create
```
Dopo aver eseguito il comando, lo script verifica `squeue` per rilevare se ci sono processi in coda, arresta Slurm se non c’è alcun processo in coda, esegue il backup di `mariadb` e copia gli elementi locali sul disco definito in `LOCAL_ITEMS`. Puoi aggiungere altri file e directory a `LOCAL_ITEMS`.
```
# Define files and directories to back up.
LOCAL_ITEMS=(
"/var/spool/slurmd"
"/var/spool/slurmctld"
"/etc/systemd/system/slurmctld.service"
"/home/ubuntu/backup_slurm_acct_db.sql"
# ... Add more items as needed
)
```
Inoltre, puoi aggiungere codice personalizzato allo script fornito per eseguire il backup di qualsiasi applicazione collegata al tuo caso d’uso.
**Per ripristinare i dati da un bucket S3 dopo l’applicazione delle patch**
```
sudo bash patching-backup.sh --restore
```
## Riduzione verticale di un cluster
È possibile ridurre il numero di istanze o eliminare i gruppi di istanze nel SageMaker HyperPod cluster per ottimizzare l'allocazione delle risorse o ridurre i costi.
Puoi ridurre verticalmente le istanze con l’operazione API `UpdateCluster` per terminare in modo casuale le istanze dal gruppo di istanze fino a un numero specificato oppure puoi terminare istanze specifiche utilizzando l’operazione API `BatchDeleteClusterNodes`. Puoi anche rimuovere completamente interi gruppi di istanze utilizzando l’API `UpdateCluster`. Per ulteriori informazioni su come ridurre verticalmente le istanze con questi metodi, consulta [Ridimensionamento di un cluster SageMaker HyperPod](smcluster-scale-down.md).
**Nota**
Non è possibile rimuovere le istanze configurate come nodi controller Slurm. Il tentativo di eliminare un nodo controller Slurm genera un errore di convalida con il codice di errore `NODE_ID_IN_USE`.
## Eliminazione di un cluster
Esegui [delete-cluster](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/delete-cluster.html) per eliminare un cluster. Puoi specificare il nome o l’ARN del cluster.
```
aws sagemaker delete-cluster --cluster-name your-hyperpod-cluster
```
# Personalizzazione dei SageMaker HyperPod cluster utilizzando script del ciclo di vita
SageMaker HyperPod offre sempre cluster di up-and-running calcolo, che sono altamente personalizzabili in quanto è possibile scrivere script del ciclo di vita per indicare come configurare le risorse del cluster. SageMaker HyperPod Gli argomenti seguenti sono le best practice per preparare gli script del ciclo di vita per configurare SageMaker HyperPod i cluster con strumenti open source per la gestione del carico di lavoro.
Negli argomenti seguenti vengono illustrate le best practice approfondite per la preparazione degli script del ciclo di vita su cui configurare le configurazioni Slurm. SageMaker HyperPod
## Panoramica generale
La procedura seguente è il flusso principale per il provisioning di un HyperPod cluster e la sua configurazione con Slurm. Le fasi sono in ordine, in base a un approccio dal ***basso verso l’alto***.
1. Pianifica come vuoi creare i nodi Slurm su un cluster. HyperPod Ad esempio, se desideri configurare due nodi Slurm, dovrai configurare due gruppi di istanze in un cluster. HyperPod
1. Prepara la configurazione di Slurm. Scegliete uno dei seguenti approcci:
+ **Opzione A: configurazione basata su API (consigliata)**: definisci i tipi di nodi e le partizioni Slurm direttamente nel payload dell'`CreateCluster`API utilizzando all'interno di ciascun gruppo di istanze. `SlurmConfig` Con questo approccio:
+ Non è necessario alcun `provisioning_parameters.json` file
+ La topologia Slurm è definita nel payload dell'API insieme alle definizioni dei gruppi di istanze
+ FSx i filesystem sono configurati tramite per-instance-group `InstanceStorageConfigs`
+ La strategia di configurazione è controllata tramite `Orchestrator.Slurm.SlurmConfigStrategy`
Esempio `SlurmConfig` in un gruppo di istanze:
```
{
"InstanceGroupName": "gpu-compute",
"InstanceType": "ml.p4d.24xlarge",
"InstanceCount": 8,
"SlurmConfig": {
"NodeType": "Compute",
"PartitionNames": ["gpu-training"]
}
}
```
+ **Opzione B: configurazione precedente:** prepara un `provisioning_parameters.json` file, che è un[Modulo di configurazione per provisioning\$1parameters.json](sagemaker-hyperpod-ref.md#sagemaker-hyperpod-ref-provisioning-forms-slurm). `provisioning_parameters.json`deve contenere informazioni sulla configurazione del nodo Slurm da fornire sul cluster. HyperPod Questo file dovrebbe riflettere la progettazione dei nodi Slurm della Fase 1.
1. Prepara un set di script del ciclo di vita su cui configurare Slurm per installare pacchetti software e configurare un ambiente nel cluster adatto HyperPod al tuo caso d'uso. È necessario strutturare gli script del ciclo di vita in modo che vengano eseguiti collettivamente in ordine in uno script Python centrale (`lifecycle_script.py`), oltre a scrivere uno script shell del punto di ingresso (`on_create.sh`) per eseguire lo script Python. Lo script di shell entrypoint è ciò che devi fornire a una richiesta di creazione di HyperPod cluster più avanti nel Passaggio 5.
Inoltre, si noti che è necessario scrivere gli script in modo da aspettarsi `resource_config.json` che vengano generati HyperPod durante la creazione del cluster. `resource_config.json`contiene informazioni sulle risorse del HyperPod cluster come indirizzi IP, tipi di istanze e ARNs, ed è ciò che è necessario utilizzare per configurare Slurm.
1. Raccogli tutti i file delle fasi precedenti in una cartella. La struttura delle cartelle dipende dall'approccio di configurazione selezionato nel passaggio 2.
Se hai selezionato l'opzione A (configurazione basata su API):
La cartella necessita solo di script del ciclo di vita per attività di configurazione personalizzate. La configurazione e il FSx montaggio di Slurm vengono gestiti HyperPod automaticamente in base al payload dell'API.
```
└── lifecycle_files // your local folder
├── on_create.sh
├── lifecycle_script.py
└── ... // more setup scripts to be fed into lifecycle_script.py
```
**Nota**
Il `provisioning_parameters.json` file non è necessario quando si utilizza la configurazione basata su API.
Se hai selezionato l'opzione B (configurazione precedente):
La cartella deve includere `provisioning_parameters.json` e il set completo di script del ciclo di vita.
```
└── lifecycle_files // your local folder
├── provisioning_parameters.json
├── on_create.sh
├── lifecycle_script.py
└── ... // more setup scrips to be fed into lifecycle_script.py
```
1. Carica tutti i file in un bucket S3. Copia e annota il percorso del bucket S3. Ricorda di creare un percorso del bucket S3 che inizi con `sagemaker-`, perché dovrai scegliere un percorso del [Ruolo IAM per SageMaker HyperPod](sagemaker-hyperpod-prerequisites-iam.md#sagemaker-hyperpod-prerequisites-iam-role-for-hyperpod) collegato a [`AmazonSageMakerClusterInstanceRolePolicy`](security-iam-awsmanpol-AmazonSageMakerClusterInstanceRolePolicy.md), che consente solo i percorsi dei bucket S3 che iniziano con il prefisso `sagemaker-`. Di seguito è riportato un comando di esempio per caricare tutti i file in un bucket S3.
```
aws s3 cp --recursive ./lifecycle_files s3://sagemaker-hyperpod-lifecycle/src
```
1. Prepara una richiesta di creazione HyperPod del cluster.
+ Opzione 1: se utilizzi il AWS CLI, scrivi una richiesta di creazione del cluster in formato JSON (`create_cluster.json`) seguendo le istruzioni all'indirizzo[Creazione di un nuovo cluster](sagemaker-hyperpod-operate-slurm-cli-command.md#sagemaker-hyperpod-operate-slurm-cli-command-create-cluster).
+ Opzione 2: se utilizzi l'interfaccia utente della console SageMaker AI, compila il modulo di richiesta **Crea un cluster** nell'interfaccia utente della HyperPod console seguendo le istruzioni riportate all'indirizzo[Crea un SageMaker HyperPod cluster](sagemaker-hyperpod-operate-slurm-console-ui.md#sagemaker-hyperpod-operate-slurm-console-ui-create-cluster).
In questa fase, assicurati di creare gruppi di istanze nella stessa struttura pianificata nelle Fasi 1 e 2. Inoltre, assicurati di specificare il bucket S3 della Fase 5 nei moduli di richiesta.
1. Invia la richiesta di creazione del cluster. HyperPod esegue il provisioning di un cluster in base alla richiesta, quindi crea un `resource_config.json` file nelle istanze del HyperPod cluster e configura Slurm sul cluster che esegue gli script del ciclo di vita.
I seguenti argomenti illustrano e approfondiscono i dettagli su come organizzare i file di configurazione e gli script del ciclo di vita in modo che funzionino correttamente durante la creazione del cluster. HyperPod
**Topics**
+ [Panoramica generale](#sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-highlevel-overview)
+ [Script del ciclo di vita di base forniti da HyperPod](sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-base-config.md)
+ [Quali configurazioni particolari gestisce nei file di configurazione Slurm HyperPod](sagemaker-hyperpod-lifecycle-best-practices-slurm-what-hyperpod-overrides-in-slurm-conf.md)
+ [Slurm registra le rotazioni](sagemaker-hyperpod-slurm-log-rotation.md)
+ [Montaggio di Amazon FSx for Lustre e Amazon FSx for OpenZFS su un cluster HyperPod](sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-setup-with-fsx.md)
+ [Convalida dei file di configurazione JSON prima di creare un cluster Slurm su HyperPod](sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-validate-json-files.md)
+ [Convalida del runtime prima di eseguire carichi di lavoro di produzione su un cluster Slurm HyperPod](sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-validate-runtime.md)
+ [Sviluppo interattivo di script del ciclo di vita su un nodo del cluster HyperPod](sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-develop-lifecycle-scripts.md)
# Script del ciclo di vita di base forniti da HyperPod
Questa sezione illustra ogni componente del flusso di base di configurazione di Slurm on HyperPod con un approccio ***dall'alto*** verso il basso. Inizia dalla preparazione di una richiesta di creazione HyperPod del cluster per eseguire l'`CreateCluster`API e approfondisce la struttura gerarchica fino agli script del ciclo di vita. [Utilizza gli script di esempio relativi al ciclo di vita forniti nell'archivio Awsome Distributed Training. GitHub ](https://github.com/aws-samples/awsome-distributed-training/) Clona il repository con il comando seguente.
```
git clone https://github.com/aws-samples/awsome-distributed-training/
```
Gli script del ciclo di vita di base per la configurazione di un cluster Slurm sono disponibili all'indirizzo. SageMaker HyperPod [https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config](https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config)
```
cd awsome-distributed-training/1.architectures/5.sagemaker_hyperpods/LifecycleScripts/base-config
```
Il diagramma di flusso seguente mostra una panoramica dettagliata di come progettare gli script del ciclo di vita di base. Le descrizioni sotto il diagramma e la guida procedurale spiegano come funzionano durante la chiamata API. HyperPod `CreateCluster`
![\[Un diagramma di flusso dettagliato della creazione dei HyperPod cluster e della struttura degli script del ciclo di vita.\]](http://docs.aws.amazon.com/it_it/sagemaker/latest/dg/images/hyperpod-lifecycle-structure.png)
***Figura:** Un diagramma di flusso dettagliato della creazione dei HyperPod cluster e della struttura degli script del ciclo di vita. (1) Le frecce tratteggiate indicano il punto in cui vengono “richiamate” le caselle e mostrano il flusso dei file di configurazione e la preparazione degli script del ciclo di vita. Il processo inizia dalla preparazione del file `provisioning_parameters.json` e degli script del ciclo di vita. Questi vengono quindi codificati in `lifecycle_script.py` per essere eseguiti in ordine collettivamente. E l'esecuzione dello `lifecycle_script.py` script viene eseguita dallo script di `on_create.sh` shell, che deve essere eseguito nel terminale dell' HyperPodistanza. (2) Le frecce piene mostrano il flusso principale di creazione del HyperPod cluster e il modo in cui le caselle vengono «richiamate» o «inviate a». `on_create.sh`è necessario per la richiesta di creazione del cluster, nel modulo Crea una richiesta di cluster `create_cluster.json` o nel modulo **Crea una richiesta di cluster** nell'interfaccia utente della console. Dopo aver inviato la richiesta, HyperPod esegue l'`CreateCluster`API in base alle informazioni di configurazione fornite dalla richiesta e dagli script del ciclo di vita. (3) La freccia punteggiata indica che la HyperPod piattaforma crea istanze `resource_config.json` nel cluster durante il provisioning delle risorse del cluster. `resource_config.json`contiene informazioni sulle risorse del HyperPod cluster come l'ARN del cluster, i tipi di istanza e gli indirizzi IP. È importante notare che gli script del ciclo di vita vanno preparati in modo che prevedano il file `resource_config.json` durante la creazione del cluster. Per ulteriori informazioni, consulta la guida con le procedure di seguito.*
La seguente guida procedurale spiega cosa succede durante la creazione del HyperPod cluster e come sono progettati gli script del ciclo di vita di base.
1. `create_cluster.json`— Per inviare una richiesta di creazione di un HyperPod cluster, si prepara un file di `CreateCluster` richiesta in formato JSON. In questo esempio di best practice, supponiamo che il file di richiesta si chiami `create_cluster.json`. Scrivi `create_cluster.json` per fornire gruppi di istanze a un HyperPod cluster. La best practice consiste nell'aggiungere lo stesso numero di gruppi di istanze del numero di nodi Slurm che intendi configurare sul HyperPod cluster. Assicurati di assegnare nomi distintivi ai gruppi di istanze che assegnerai ai nodi Slurm che intendi configurare.
Inoltre, devi specificare un percorso al bucket S3 per archiviare l’intero set di file di configurazione e script del ciclo di vita nel campo `InstanceGroups.LifeCycleConfig.SourceS3Uri` del modulo di richiesta `CreateCluster`. Inoltre, devi specificare il nome del file di uno script shell del punto di ingresso (chiamato, supponiamo, `on_create.sh`) in `InstanceGroups.LifeCycleConfig.OnCreate`.
**Nota**
Se utilizzi il modulo di invio **Crea un cluster** nell'interfaccia utente della console, la HyperPod console gestisce la compilazione e l'invio della `CreateCluster` richiesta per tuo conto ed esegue l'`CreateCluster`API nel backend. In questo caso, non è necessario creare`create_cluster.json`, ma assicurati di specificare le informazioni corrette sulla configurazione del cluster nel modulo di invio **Crea un cluster**.
1. `on_create.sh`— Per ogni gruppo di istanze, è necessario fornire uno script di shell entrypoint per eseguire comandi`on_create.sh`, eseguire script per installare pacchetti software e configurare l'ambiente cluster con Slurm. HyperPod Le due cose da preparare sono una `provisioning_parameters.json` necessaria per configurare Slurm e un set di script del ciclo di vita HyperPod per l'installazione dei pacchetti software. Questo script deve essere scritto per trovare ed eseguire i file seguenti, come mostrato nello script di esempio in [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/on_create.sh](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/on_create.sh).
**Nota**
Assicurati di caricare l’intero set di script del ciclo di vita nella posizione S3 specificata in `create_cluster.json`. Anche il file `provisioning_parameters.json` deve trovarsi nella stessa posizione.
1. `provisioning_parameters.json`: questo è un [Modulo di configurazione per provisioning\$1parameters.json](sagemaker-hyperpod-ref.md#sagemaker-hyperpod-ref-provisioning-forms-slurm). Lo script `on_create.sh` trova questo file JSON e definisce la variabile di ambiente per identificarne il percorso. Tramite questo file JSON, puoi configurare nodi Slurm e opzioni di storage come Amazon FSx for Lustre for Slurm con cui comunicare. Inoltre`provisioning_parameters.json`, assicurati di assegnare i gruppi di istanze del HyperPod cluster utilizzando i nomi specificati ai nodi Slurm in modo appropriato in base `create_cluster.json` a come intendi configurarli.
Il diagramma seguente mostra un esempio di come i due file di configurazione JSON `provisioning_parameters.json` devono essere scritti per HyperPod assegnare i gruppi di `create_cluster.json` istanze ai nodi Slurm. In questo esempio, supponiamo di dover configurare tre nodi Slurm: il nodo controller (gestione), il nodo login (facoltativo) e il nodo di calcolo (worker).
**Suggerimento**
Per aiutarti a convalidare questi due file JSON, il team di HyperPod assistenza fornisce uno script di convalida,. [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/validate-config.py](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/validate-config.py) Per ulteriori informazioni, consulta [Convalida dei file di configurazione JSON prima di creare un cluster Slurm su HyperPod](sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-validate-json-files.md).
![\[Confronto diretto tra file .json.\]](http://docs.aws.amazon.com/it_it/sagemaker/latest/dg/images/hyperpod-lifecycle-slurm-config.png)
***Figura:** Confronto diretto tra la configurazione per la creazione di HyperPod cluster e quella `create_cluster.json` per `provisiong_params.json` Slurm. Il numero di gruppi di istanze in `create_cluster.json` deve corrispondere al numero di nodi che intendi configurare come nodi Slurm. Nel caso dell'esempio in figura, tre nodi Slurm verranno configurati su un HyperPod cluster di tre gruppi di istanze. È necessario assegnare i gruppi di istanze del HyperPod cluster ai nodi Slurm specificando di conseguenza i nomi dei gruppi di istanze.*
1. `resource_config.json`— Durante la creazione del cluster, lo `lifecycle_script.py` script viene scritto in modo da aspettarsi un file da. `resource_config.json` HyperPod Questo file contiene informazioni sul cluster, ad esempio i tipi di istanze e gli indirizzi IP.
Quando esegui l'`CreateCluster`API, HyperPod crea un file di configurazione delle risorse in `/opt/ml/config/resource_config.json` base al `create_cluster.json` file. Il percorso del file viene salvato nella variabile di ambiente denominata `SAGEMAKER_RESOURCE_CONFIG_PATH`.
**Importante**
Il `resource_config.json` file viene generato automaticamente dalla HyperPod piattaforma e NON è necessario crearlo. Il codice seguente, che mostra un esempio del file `resource_config.json` generato dalla creazione del cluster in base al file `create_cluster.json` della fase precedente, ti aiuta a capire cosa succede nel backend e come è fatto un file `resource_config.json` generato automaticamente.
```
{
"ClusterConfig": {
"ClusterArn": "arn:aws:sagemaker:us-west-2:111122223333:cluster/abcde01234yz",
"ClusterName": "your-hyperpod-cluster"
},
"InstanceGroups": [
{
"Name": "controller-machine",
"InstanceType": "ml.c5.xlarge",
"Instances": [
{
"InstanceName": "controller-machine-1",
"AgentIpAddress": "111.222.333.444",
"CustomerIpAddress": "111.222.333.444",
"InstanceId": "i-12345abcedfg67890"
}
]
},
{
"Name": "login-group",
"InstanceType": "ml.m5.xlarge",
"Instances": [
{
"InstanceName": "login-group-1",
"AgentIpAddress": "111.222.333.444",
"CustomerIpAddress": "111.222.333.444",
"InstanceId": "i-12345abcedfg67890"
}
]
},
{
"Name": "compute-nodes",
"InstanceType": "ml.trn1.32xlarge",
"Instances": [
{
"InstanceName": "compute-nodes-1",
"AgentIpAddress": "111.222.333.444",
"CustomerIpAddress": "111.222.333.444",
"InstanceId": "i-12345abcedfg67890"
},
{
"InstanceName": "compute-nodes-2",
"AgentIpAddress": "111.222.333.444",
"CustomerIpAddress": "111.222.333.444",
"InstanceId": "i-12345abcedfg67890"
},
{
"InstanceName": "compute-nodes-3",
"AgentIpAddress": "111.222.333.444",
"CustomerIpAddress": "111.222.333.444",
"InstanceId": "i-12345abcedfg67890"
},
{
"InstanceName": "compute-nodes-4",
"AgentIpAddress": "111.222.333.444",
"CustomerIpAddress": "111.222.333.444",
"InstanceId": "i-12345abcedfg67890"
}
]
}
]
}
```
1. `lifecycle_script.py`— Questo è lo script Python principale che esegue collettivamente gli script del ciclo di vita configurando Slurm sul cluster durante il provisioning. HyperPod Questo script legge `provisioning_parameters.json` e `resource_config.json` nei percorsi specificati o identificati in `on_create.sh`, passa le informazioni pertinenti a ogni script del ciclo di vita e quindi esegue in ordine gli script del ciclo di vita.
Gli script del ciclo di vita sono un set di script che offre la massima flessibilità di personalizzazione e consente di installare pacchetti software e impostare le configurazioni necessarie o personalizzate durante la creazione di cluster, ad esempio la configurazione di Slurm, la creazione di utenti e l’installazione di Conda o Docker. [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/lifecycle_script.py](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/lifecycle_script.py)Lo script di esempio è pronto per eseguire altri script del ciclo di vita di base nel repository, come l'avvio di Slurm deamons () [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/start_slurm.sh](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/start_slurm.sh), il montaggio di Amazon FSx for Lustre () e la configurazione di MariaDB accounting () [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/mount_fsx.sh](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/mount_fsx.sh)e RDS accounting (). [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/setup_mariadb_accounting.sh](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/setup_mariadb_accounting.sh) Puoi anche aggiungere altri script, impacchettarli nella stessa directory e aggiungere righe di codice per consentire l'esecuzione degli script. `lifecycle_script.py` HyperPod *Per ulteriori informazioni sugli script del ciclo di vita di base, consulta anche gli script del ciclo di [vita 3.1 nell'archivio Awsome Distributed Training](https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod#31-lifecycle-scripts). GitHub *
**Nota**
HyperPod viene eseguito [SageMaker HyperPod DLAMI](sagemaker-hyperpod-ref.md#sagemaker-hyperpod-ref-hyperpod-ami) su ogni istanza di un cluster e l'AMI dispone di pacchetti software preinstallati che rispettano le compatibilità tra essi e le funzionalità. HyperPod Tieni presente che se reinstalli uno qualsiasi dei pacchetti preinstallati, sei responsabile dell'installazione dei pacchetti compatibili e tieni presente che alcune HyperPod funzionalità potrebbero non funzionare come previsto.
Oltre alle configurazioni predefinite, nella cartella [https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/utils](https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/utils) sono disponibili altri script per l’installazione dei software seguenti. Il file `lifecycle_script.py` è già pronto per includere righe di codice per l’esecuzione degli script di installazione, quindi consulta le indicazioni seguenti per cercare tali righe e rimuovi i commenti per attivarle.
1. Le righe di codice seguenti servono per l’installazione di [Docker](https://www.docker.com/), [Enroot](https://github.com/NVIDIA/enroot) e [Pyxis](https://github.com/NVIDIA/pyxis). Questi pacchetti sono necessari per eseguire i container Docker su un cluster Slurm.
Per abilitare questa fase di installazione, imposta il parametro `enable_docker_enroot_pyxis` su `True` nel file [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/config.py](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/config.py).
```
# Install Docker/Enroot/Pyxis
if Config.enable_docker_enroot_pyxis:
ExecuteBashScript("./utils/install_docker.sh").run()
ExecuteBashScript("./utils/install_enroot_pyxis.sh").run(node_type)
```
1. Puoi integrare il tuo HyperPod cluster con [Amazon Managed Service for Prometheus](https://docs.aws.amazon.com/prometheus/latest/userguide/what-is-Amazon-Managed-Service-Prometheus.html) e [Amazon Managed](https://docs.aws.amazon.com/grafana/latest/userguide/what-is-Amazon-Managed-Service-Grafana.html) Grafana per esportare i parametri relativi al cluster e ai nodi HyperPod del cluster nelle dashboard di Amazon Managed Grafana. Per esportare le metriche e utilizzare la [dashboard Slurm](https://grafana.com/grafana/dashboards/4323-slurm-dashboard/), la [dashboard NVIDIA DCGM Exporter](https://grafana.com/grafana/dashboards/12239-nvidia-dcgm-exporter-dashboard/) e la [dashboard delle metriche EFA](https://grafana.com/grafana/dashboards/20579-efa-metrics-dev/) su Grafana gestito da Amazon, devi installare lo [strumento di esportazione Slurm per Prometheus](https://github.com/vpenso/prometheus-slurm-exporter), lo [strumento di esportazione NVIDIA DCGM](https://github.com/NVIDIA/dcgm-exporter) e lo [strumento di esportazione di nodi EFA](https://github.com/aws-samples/awsome-distributed-training/blob/main/4.validation_and_observability/3.efa-node-exporter/README.md). Per ulteriori informazioni sull’installazione dei pacchetti di esportazione e sull’utilizzo delle dashboard Grafana in uno spazio di lavoro Grafana gestito da Amazon, consulta [SageMaker HyperPod monitoraggio delle risorse del cluster](sagemaker-hyperpod-cluster-observability-slurm.md).
Per abilitare questa fase di installazione, imposta il parametro `enable_observability` su `True` nel file [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/config.py](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/config.py).
```
# Install metric exporting software and Prometheus for observability
if Config.enable_observability:
if node_type == SlurmNodeType.COMPUTE_NODE:
ExecuteBashScript("./utils/install_docker.sh").run()
ExecuteBashScript("./utils/install_dcgm_exporter.sh").run()
ExecuteBashScript("./utils/install_efa_node_exporter.sh").run()
if node_type == SlurmNodeType.HEAD_NODE:
wait_for_scontrol()
ExecuteBashScript("./utils/install_docker.sh").run()
ExecuteBashScript("./utils/install_slurm_exporter.sh").run()
ExecuteBashScript("./utils/install_prometheus.sh").run()
```
1. Assicurati di caricare tutti i file e gli script di configurazione della **Fase 2** nel bucket S3 fornito nella richiesta `CreateCluster` della **Fase 1**. Ad esempio, presupponi che `create_cluster.json` contenga quanto segue:
```
"LifeCycleConfig": {
"SourceS3URI": "s3://sagemaker-hyperpod-lifecycle/src",
"OnCreate": "on_create.sh"
}
```
Di conseguenza, `"s3://sagemaker-hyperpod-lifecycle/src"` dovrebbe contenere `on_create.sh`, `lifecycle_script.py`, `provisioning_parameters.json` e tutti gli altri script di configurazione. Supponi di aver preparato i file in una cartella locale come segue.
```
└── lifecycle_files // your local folder
├── provisioning_parameters.json
├── on_create.sh
├── lifecycle_script.py
└── ... // more setup scrips to be fed into lifecycle_script.py
```
Per caricare i file, utilizza il comando S3 come segue.
```
aws s3 cp --recursive ./lifecycle_scripts s3://sagemaker-hyperpod-lifecycle/src
```
# Quali configurazioni particolari gestisce nei file di configurazione Slurm HyperPod
Quando crei un cluster Slurm su HyperPod, l' HyperPod agente configura [https://slurm.schedmd.com/gres.conf.html](https://slurm.schedmd.com/gres.conf.html)i file [https://slurm.schedmd.com/slurm.conf.html](https://slurm.schedmd.com/slurm.conf.html)and `/opt/slurm/etc/` per gestire il cluster Slurm in base alla richiesta di creazione del cluster e agli script HyperPod del ciclo di vita. L'elenco seguente mostra quali parametri specifici l'agente gestisce e sovrascrive. HyperPod
**Importante**
Si consiglia vivamente di **non** modificare questi parametri gestiti da HyperPod.
+ In [https://slurm.schedmd.com/slurm.conf.html](https://slurm.schedmd.com/slurm.conf.html), HyperPod imposta i seguenti parametri di base: `ClusterName``SlurmctldHost`,`PartitionName`, e`NodeName`.
Inoltre, per abilitare la [Ripristino automatico dei nodi e ripristino automatico](sagemaker-hyperpod-resiliency-slurm-auto-resume.md) funzionalità, HyperPod richiede i `SchedulerParameters` parametri `TaskPlugin` e impostati come segue. Per impostazione predefinita, l' HyperPod agente imposta questi due parametri con i valori richiesti.
```
TaskPlugin=task/none
SchedulerParameters=permit_job_expansion
```
+ In [https://slurm.schedmd.com/gres.conf.html](https://slurm.schedmd.com/gres.conf.html), HyperPod gestisce `NodeName` i nodi GPU.
# Slurm registra le rotazioni
SageMaker HyperPod fornisce la rotazione automatica dei log dei daemon Slurm per aiutare a gestire l'utilizzo dello spazio su disco e mantenere le prestazioni del sistema. La rotazione dei log è fondamentale per evitare che i log consumino uno spazio eccessivo su disco e garantire un funzionamento ottimale del sistema archiviando e rimuovendo automaticamente i vecchi file di registro mantenendo al contempo le informazioni di registrazione recenti. Le rotazioni dei log di Slurm sono abilitate per impostazione predefinita quando si crea un cluster.
## Come funziona la rotazione dei log
Se abilitata, la configurazione di rotazione dei log:
+ Monitora tutti i file di registro Slurm con l'estensione `.log` situata nella `/var/log/slurm/` cartella sui nodi controller, login e calcolo.
+ Ruota i log quando raggiungono una dimensione di 50 MB.
+ Mantiene fino a due file di registro ruotati prima di eliminarli.
+ Invia SIGUSR2 il segnale ai demoni Slurm (`slurmctld`, `slurmd` e) dopo la rotazione. `slurmdbd`
## Elenco dei file di registro ruotati
I log di Slurm si trovano nella directory. `/var/log/slurm/` La rotazione dei log è abilitata per tutti i file corrispondenti. `/var/log/slurm/*.log` Quando si verifica una rotazione, i file ruotati hanno suffissi numerici (ad esempio). `slurmd.log.1` L'elenco seguente non è esaustivo ma mostra alcuni dei file di registro critici che ruotano automaticamente:
+ `/var/log/slurm/slurmctld.log`
+ `/var/log/slurm/slurmd.log`
+ `/var/log/slurm/slurmdb.log`
+ `/var/log/slurm/slurmrestd.log`
## Abilita o disabilita la rotazione dei log
È possibile controllare la funzionalità di rotazione dei log utilizzando il `enable_slurm_log_rotation` parametro nello `config.py` script degli script del ciclo di vita del cluster, come illustrato nell'esempio seguente:
```
class Config:
# Set false if you want to disable log rotation of Slurm daemon logs
enable_slurm_log_rotation = True # Default value
```
Per disabilitare la rotazione dei log, imposta il parametro su`False`, come mostrato nell'esempio seguente:
```
enable_slurm_log_rotation = False
```
**Nota**
Gli script del ciclo di vita vengono eseguiti su tutti i nodi Slurm (controller, login e nodi di calcolo) durante la creazione del cluster. Vengono eseguiti anche su nuovi nodi quando vengono aggiunti al cluster. L'aggiornamento delle configurazioni di rotazione dei log deve essere eseguito manualmente dopo la creazione del cluster. La configurazione della rotazione dei log è memorizzata in`/etc/logrotate.d/sagemaker-hyperpod-slurm`. Si consiglia di mantenere abilitata la rotazione dei log per evitare che i file di registro consumino troppo spazio su disco. Per disabilitare la rotazione dei log, elimina il `sagemaker-hyperpod-slurm` file o commentane il contenuto aggiungendolo `#` all'inizio di ogni riga del `sagemaker-hyperpod-slurm` file.
## Impostazioni predefinite di rotazione dei registri
Le seguenti impostazioni vengono configurate automaticamente per ogni file di registro ruotato:
| Impostazione | Valore | Description |
| --- | --- | --- |
| rotate | 2 | Numero di file di registro ruotati da conservare |
| size | 50 MB | Dimensione massima prima della rotazione |
| copytruncate | abilitato | Copia e tronca il file di registro originale |
| compress | disabled | I log ruotati non vengono compressi |
| missingok | abilitato | Nessun errore se manca il file di registro |
| notifempty | abilitato | Non ruota i file vuoti |
| noolddir | abilitato | I file ruotati rimangono nella stessa directory |
# Montaggio di Amazon FSx for Lustre e Amazon FSx for OpenZFS su un cluster HyperPod
Per montare un file system condiviso Amazon FSx for Lustre sul tuo HyperPod cluster, configura quanto segue.
1. Utilizza il tuo Amazon VPC.
1. Affinché le istanze del HyperPod cluster comunichino all'interno del tuo VPC, assicurati di associarle [Configurazione SageMaker HyperPod con un Amazon VPC personalizzato](sagemaker-hyperpod-prerequisites.md#sagemaker-hyperpod-prerequisites-optional-vpc) al ruolo IAM per. SageMaker HyperPod
1. In `create_cluster.json`, includi le informazioni sul VPC seguenti.
```
"VpcConfig": {
"SecurityGroupIds": [ "string" ],
"Subnets": [ "string" ]
}
```
Per ulteriori suggerimenti sulla configurazione di Amazon VPC, consulta [Prerequisiti per l'utilizzo SageMaker HyperPod](sagemaker-hyperpod-prerequisites.md).
1. Per completare la configurazione di Slurm con Amazon FSx for Lustre, puoi utilizzare uno dei seguenti approcci. Puoi trovare le FSx informazioni di Amazon dalla console Amazon FSx for Lustre nel tuo account o eseguendo il seguente AWS CLI comando,`aws fsx describe-file-systems`.
**Opzione A: configurazione basata su API (consigliata)**
Specificate la FSx configurazione Amazon direttamente nel payload dell' CreateCluster API utilizzando `InstanceStorageConfigs` all'interno di ogni gruppo di istanze. Questo approccio supporta sia FSx Lustre che OpenZFS e consente FSx la configurazione. per-instance-group FSx
```
"InstanceStorageConfigs": [
{
"FsxLustreConfig": {
"DnsName": "fs-12345678a90b01cde.fsx.us-west-2.amazonaws.com",
"MountPath": "/fsx",
"MountName": "1abcdefg"
}
}
]
```
FSx Per OpenZFS, usa invece: `FsxOpenZfsConfig`
```
"InstanceStorageConfigs": [
{
"FsxOpenZfsConfig": {
"DnsName": "fs-12345678a90b01cde.fsx.us-west-2.amazonaws.com",
"MountPath": "/fsx-openzfs"
}
}
]
```
Per ulteriori dettagli, consulta [Guida introduttiva all' SageMaker HyperPod uso della AWS CLI](sagemaker-hyperpod-quickstart.md).
**Opzione B: configurazione precedente**
Specificare il nome Amazon FSx DNS e il nome di FSx montaggio Amazon `provisioning_parameters.json` come mostrato nella figura nella [Script del ciclo di vita di base forniti da HyperPod](sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-base-config.md) sezione.
```
"fsx_dns_name": "fs-12345678a90b01cde.fsx.us-west-2.amazonaws.com",
"fsx_mountname": "1abcdefg"
```
# Convalida dei file di configurazione JSON prima di creare un cluster Slurm su HyperPod
Per convalidare i file di configurazione JSON prima di inviare una richiesta di creazione del cluster, utilizza lo script di convalida della configurazione [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/validate-config.py](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/validate-config.py). Questo script analizza e confronta il file JSON di configurazione del HyperPod cluster e il file JSON di configurazione Slurm e identifica eventuali errori di configurazione delle risorse tra i due file e anche tra le risorse Amazon EC2, Amazon VPC e Amazon. FSx Ad esempio, per convalidare i file `create_cluster.json` e `provisioning_parameters.json` della sezione [Script del ciclo di vita di base forniti da HyperPod](sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-base-config.md), esegui lo script di convalida come segue.
```
python3 validate-config.py --cluster-config create_cluster.json --provisioning-parameters provisioning_parameters.json
```
Di seguito è riportato un esempio di output di una convalida eseguita correttamente.
```
✔️ Validated instance group name worker-group-1 is correct ...
✔️ Validated subnet subnet-012345abcdef67890 ...
✔️ Validated security group sg-012345abcdef67890 ingress rules ...
✔️ Validated security group sg-012345abcdef67890 egress rules ...
✔️ Validated FSx Lustre DNS name fs-012345abcdef67890.fsx.us-east-1.amazonaws.com
✔️ Validated FSx Lustre mount name abcdefgh
✅ Cluster Validation succeeded
```
# Convalida del runtime prima di eseguire carichi di lavoro di produzione su un cluster Slurm HyperPod
Per controllare il runtime prima di eseguire qualsiasi carico di lavoro di produzione su un cluster Slurm HyperPod, usa lo script di convalida del runtime. [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/hyperpod-precheck.py](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/hyperpod-precheck.py) Questo script verifica se il cluster Slurm ha tutti i pacchetti installati per l'esecuzione di Docker, se il cluster ha un file system montato correttamente FSx per Lustre e una directory utente che condivide il file system e se il demone Slurm è in esecuzione su tutti i nodi di calcolo.
Per eseguire lo script su più nodi contemporaneamente, utilizza `srun` come mostrato nel comando di esempio seguente per eseguire lo script su un cluster Slurm di 8 nodi.
```
# The following command runs on 8 nodes
srun -N 8 python3 hyperpod-precheck.py
```
**Nota**
Per ulteriori informazioni sullo script di convalida, ad esempio sulle funzioni di convalida del runtime fornite dallo script e sulle linee guida per risolvere i problemi che non superano le convalide, consulta [Convalida del runtime prima di eseguire carichi](https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod#35-runtime-validation-before-running-workloads) di lavoro nell'* GitHub archivio Awsome Distributed Training*.
# Sviluppo interattivo di script del ciclo di vita su un nodo del cluster HyperPod
Questa sezione spiega come sviluppare in modo interattivo script del ciclo di vita senza creare ed eliminare ripetutamente un cluster. HyperPod
1. Crea un HyperPod cluster con gli script del ciclo di vita di base.
1. Accedi a un nodo del cluster.
1. Sviluppa uno script (`configure_xyz.sh`) modificandolo ed eseguendolo ripetutamente sul nodo.
1. HyperPod esegue gli script del ciclo di vita come utente root, quindi si consiglia di eseguirli `configure_xyz.sh` come utente root durante lo sviluppo per assicurarsi che lo script venga testato nelle stesse condizioni durante l'esecuzione da. HyperPod
1. Integra lo script in `lifecycle_script.py` aggiungendo una riga di codice simile alla seguente.
```
ExecuteBashScript("./utils/configure_xyz.sh").run()
```
1. Carica gli script del ciclo di vita aggiornati nel bucket S3 utilizzato all’inizio per caricare gli script del ciclo di vita di base.
1. Prova la versione integrata di `lifecycle_script.py` creando un nuovo cluster. HyperPod Puoi anche utilizzare la sostituzione manuale delle istanze per testare gli script del ciclo di vita aggiornati creando nuove istanze. Per istruzioni dettagliate, consulta Sostituire [manualmente](https://docs.aws.amazon.com//sagemaker/latest/dg/sagemaker-hyperpod-resiliency-slurm-replace-faulty-instance.html#sagemaker-hyperpod-resiliency-slurm-replace-faulty-instance-replace) un nodo. Nota che solo i nodi di lavoro sono sostituibili.
# SageMaker HyperPod supporto per nodi multitesta
È possibile creare più nodi controller (head) in un singolo cluster SageMaker HyperPod Slurm, uno dei quali funge da nodo di controller principale e gli altri da nodi di controller di backup. Il nodo controller primario è responsabile del controllo dei nodi di calcolo (worker) e della gestione delle operazioni Slurm. I nodi controller di backup monitorano costantemente il nodo controller primario. Se il nodo controller primario non riesce o non risponde, uno dei nodi controller di backup lo sostituisce automaticamente diventando il nuovo nodo controller primario.
La configurazione di più nodi controller nei cluster SageMaker HyperPod Slurm offre diversi vantaggi chiave. Elimina il rischio legato al malfunzionamento di un singolo nodo controller fornendo nodi head del controller, consente il failover automatico sui nodi controller di backup con un ripristino più rapido e consente di gestire l’accounting dei database e la configurazione Slurm in modo indipendente.
## Concetti chiave
Di seguito vengono forniti dettagli sui concetti relativi al supporto di SageMaker HyperPod più nodi controller (principali) per i cluster Slurm.
**Nodi controller**
Un nodo controller è un’istanza Amazon EC2 all’interno di un cluster che esegue servizi Slurm critici per la gestione e il coordinamento delle operazioni del cluster. In particolare, ospita il [daemon del controller Slurm (slurmctld)](https://slurm.schedmd.com/slurmctld.html) e il [daemon del database Slurm (slurmdbd)](https://slurm.schedmd.com/slurmdbd.html). Un nodo controller è anche noto come nodo head.
**Nodo controller primario**
Un nodo controller primario è il nodo controller attivo e attualmente responsabile del controllo in un cluster Slurm. Viene considerato da Slurm come il nodo controller primario responsabile della gestione del cluster. Il nodo controller primario riceve i comandi dagli utenti e li esegue per controllare e allocare risorse sui nodi di calcolo per l’esecuzione dei processi.
**Nodo controller di backup**
Un nodo controller di backup è un nodo controller inattivo e in standby in un cluster Slurm. Viene considerato da Slurm come un nodo controller di backup che attualmente non gestisce il cluster. Il nodo controller di backup esegue il [daemon del controller Slurm (slurmctld)](https://slurm.schedmd.com/slurmctld.html) in modalità standby. Tutti i comandi del controller eseguiti sui nodi controller di backup verranno propagati al nodo controller primario per l’esecuzione. Il suo scopo principale è monitorare continuamente il nodo controller primario e assumersene le responsabilità in caso di errore o di mancata risposta.
**Nodo di calcolo**
Un nodo di calcolo è un’istanza Amazon EC2 all’interno di un cluster che ospita [il daemon worker Slurm (slurmd)](https://slurm.schedmd.com/slurmd.html). La funzione primaria del nodo di calcolo consiste nell’eseguire i processi assegnati dal [daemon del controller Slurm (slurmctld)](https://slurm.schedmd.com/slurmctld.html) in esecuzione sul nodo controller primario. Quando viene pianificato un processo, il nodo di calcolo riceve istruzioni dal [daemon del controller Slurm (slurmctld)](https://slurm.schedmd.com/slurmctld.html) per eseguire le attività e i calcoli necessari per tale processo all’interno del nodo stesso. Un calcolo è anche noto come nodo worker.
## Come funziona
Il diagramma seguente illustra come diversi AWS servizi interagiscono per supportare l'architettura dei nodi a più controller (principali) per i cluster Slurm. SageMaker HyperPod
![\[SageMaker HyperPod diagramma di architettura dei nodi a più teste\]](http://docs.aws.amazon.com/it_it/sagemaker/latest/dg/images/hyperpod/hyperpod-multihead-architecture.png)
I AWS servizi che interagiscono per supportare l'architettura dei nodi con controller SageMaker HyperPod multipli (principali) includono quanto segue.
**AWS servizi che interagiscono per supportare l'architettura con SageMaker HyperPod più nodi di controller**
| Servizio | Description |
| --- | --- |
| IAM (AWS Identity and Access Management) | Definisce due ruoli IAM per controllare le autorizzazioni di accesso: un ruolo per il gruppo di istanze del nodo di calcolo e l’altro per il gruppo di istanze del nodo controller. |
| Amazon RDS per MariaDB | Archivia i dati di accounting per Slurm, che contengono i record dei processi e i dati di misurazione. |
| Gestione dei segreti AWS | Archivia e gestisce le credenziali a cui può accedere Amazon FSx for Lustre. |
| Amazon FSx per Lustre | Archivia le configurazioni e lo stato di runtime di Slurm. |
| Amazon VPC | Fornisce un ambiente di rete isolato in cui vengono distribuiti il HyperPod cluster e le relative risorse. |
| Amazon SNS | Invia notifiche agli amministratori in caso di modifiche dello stato (il controller Slurm è ON o OFF) relative al nodo controller primario (head). |
Il HyperPod cluster stesso è costituito da nodi di controller (primari e di backup) e nodi di elaborazione. I nodi controller eseguono i componenti Slurm controller (SlurmCtld) e database (SlurmDBd), che gestiscono e monitorano il carico di lavoro tra i nodi di elaborazione.
I nodi del controller accedono alle configurazioni Slurm e allo stato di runtime archiviati nel file system Amazon FSx for Lustre. I dati di contabilità Slurm sono archiviati nel database Amazon RDS for MariaDB. Gestione dei segreti AWS fornisce un accesso sicuro alle credenziali del database per i nodi del controller.
In caso di modifica dello stato (il controller Slurm è `ON` o `OFF`) nei nodi controller Slurm, Amazon SNS invia notifiche all’amministratore per ulteriori azioni.
Questa architettura con più nodi controller elimina il singolo punto di errore di un singolo nodo controller (head), consente un ripristino rapido e automatico del failover e offre il controllo sulle configurazioni e il database di accounting di Slurm.
# Configurazione di più nodi controller per un cluster SageMaker HyperPod Slurm
Questo argomento spiega come configurare più nodi controller (head) in un cluster SageMaker HyperPod Slurm utilizzando script del ciclo di vita. Prima di iniziare, esamina i prerequisiti elencati in [Prerequisiti per l'utilizzo SageMaker HyperPod](sagemaker-hyperpod-prerequisites.md) e impara a conoscere gli script del ciclo di vita in [Personalizzazione dei SageMaker HyperPod cluster utilizzando script del ciclo di vita](sagemaker-hyperpod-lifecycle-best-practices-slurm.md). Le istruzioni in questo argomento utilizzano AWS CLI i comandi in ambiente Amazon Linux. Tieni presente che le variabili di ambiente utilizzate in questi comandi sono disponibili nella sessione corrente a meno che non vengano esplicitamente mantenute.
**Topics**
+ [Fornitura di risorse tramite stack CloudFormation](sagemaker-hyperpod-multihead-slurm-cfn.md)
+ [Creazione e collegamento di una policy IAM](sagemaker-hyperpod-multihead-slurm-iam.md)
+ [Preparazione e caricamento degli script del ciclo di vita](sagemaker-hyperpod-multihead-slurm-scripts.md)
+ [Creazione di un cluster SageMaker HyperPod](sagemaker-hyperpod-multihead-slurm-create.md)
+ [Note importanti](sagemaker-hyperpod-multihead-slurm-notes.md)
+ [Revisione dei riferimenti alle variabili di ambiente](sagemaker-hyperpod-multihead-slurm-variables-reference.md)
# Fornitura di risorse tramite stack CloudFormation
Per configurare più nodi controller in un cluster HyperPod Slurm, fornisci AWS le risorse tramite due CloudFormation stack: e. [Allocazione di risorse di base](#sagemaker-hyperpod-multihead-slurm-cfn-basic) [Allocazione di risorse aggiuntive per supportare più nodi controller](#sagemaker-hyperpod-multihead-slurm-cfn-multihead)
## Allocazione di risorse di base
Segui questi passaggi per fornire risorse di base per il tuo cluster Amazon SageMaker HyperPod Slurm.
1. Scarica il file del modello [sagemaker-hyperpod.yaml](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/sagemaker-hyperpod.yaml) sul tuo computer. Questo file YAML è un CloudFormation modello che definisce le seguenti risorse da creare per il tuo cluster Slurm.
+ Un ruolo IAM di esecuzione per il gruppo di istanze del nodo di calcolo
+ Un bucket Amazon S3 per archiviare gli script del ciclo di vita
+ Sottoreti pubbliche e private (le sottoreti private hanno accesso a Internet tramite gateway NAT)
+ Gateway/NAT Gateway Internet
+ Due gruppi di sicurezza Amazon EC2
+ Un FSx volume Amazon per archiviare i file di configurazione
1. Esegui il seguente comando CLI per creare uno CloudFormation stack denominato. `sagemaker-hyperpod` Definisci la zona di disponibilità (AZ) IDs per il tuo cluster in `PrimarySubnetAZ` and. `BackupSubnetAZ` Ad esempio, *use1-az4* è un ID AZ per una zona di disponibilità nella `us-east-1` regione. Per ulteriori informazioni, vedere [Zona di disponibilità IDs](https://docs.aws.amazon.com//ram/latest/userguide/working-with-az-ids.html) e[Configurazione di cluster su più cluster SageMaker HyperPod AZs](sagemaker-hyperpod-prerequisites.md#sagemaker-hyperpod-prerequisites-multiple-availability-zones).
```
aws cloudformation deploy \
--template-file /path_to_template/sagemaker-hyperpod.yaml \
--stack-name sagemaker-hyperpod \
--parameter-overrides PrimarySubnetAZ=use1-az4 BackupSubnetAZ=use1-az1 \
--capabilities CAPABILITY_IAM
```
Per ulteriori informazioni, consulta [deploy](https://docs.aws.amazon.com//cli/latest/reference/cloudformation/deploy/) from the AWS Command Line Interface Reference. La creazione dello stack può richiedere alcuni minuti. Al termine, vedrai quanto segue nell’interfaccia a riga di comando.
```
Waiting for changeset to be created..
Waiting for stack create/update to complete
Successfully created/updated stack - sagemaker-hyperpod
```
1. (Facoltativo) Verifica lo stack nella [console CloudFormation](https://console.aws.amazon.com/cloudformation/home).
+ Seleziona **Stack** dalla barra di navigazione a sinistra.
+ Nella pagina **Stack**, trova e scegli **sagemaker-hyperpod**.
+ Scegli le schede **Risorse** e **Output** per esaminare le risorse e gli output.
1. Crea variabili di ambiente dagli output dello stack (`sagemaker-hyperpod`). Utilizzerai i valori di queste variabili per [Allocazione di risorse aggiuntive per supportare più nodi controller](#sagemaker-hyperpod-multihead-slurm-cfn-multihead).
```
source .env
PRIMARY_SUBNET=$(aws --region $REGION cloudformation describe-stacks --stack-name $SAGEMAKER_STACK_NAME --query 'Stacks[0].Outputs[?OutputKey==`PrimaryPrivateSubnet`].OutputValue' --output text)
BACKUP_SUBNET=$(aws --region $REGION cloudformation describe-stacks --stack-name $SAGEMAKER_STACK_NAME --query 'Stacks[0].Outputs[?OutputKey==`BackupPrivateSubnet`].OutputValue' --output text)
EMAIL=$(bash -c 'read -p "INPUT YOUR SNSSubEmailAddress HERE: " && echo $REPLY')
DB_USER_NAME=$(bash -c 'read -p "INPUT YOUR DB_USER_NAME HERE: " && echo $REPLY')
SECURITY_GROUP=$(aws --region $REGION cloudformation describe-stacks --stack-name $SAGEMAKER_STACK_NAME --query 'Stacks[0].Outputs[?OutputKey==`SecurityGroup`].OutputValue' --output text)
ROOT_BUCKET_NAME=$(aws --region $REGION cloudformation describe-stacks --stack-name $SAGEMAKER_STACK_NAME --query 'Stacks[0].Outputs[?OutputKey==`AmazonS3BucketName`].OutputValue' --output text)
SLURM_FSX_DNS_NAME=$(aws --region $REGION cloudformation describe-stacks --stack-name $SAGEMAKER_STACK_NAME --query 'Stacks[0].Outputs[?OutputKey==`FSxLustreFilesystemDNSname`].OutputValue' --output text)
SLURM_FSX_MOUNT_NAME=$(aws --region $REGION cloudformation describe-stacks --stack-name $SAGEMAKER_STACK_NAME --query 'Stacks[0].Outputs[?OutputKey==`FSxLustreFilesystemMountname`].OutputValue' --output text)
COMPUTE_NODE_ROLE=$(aws --region $REGION cloudformation describe-stacks --stack-name $SAGEMAKER_STACK_NAME --query 'Stacks[0].Outputs[?OutputKey==`AmazonSagemakerClusterExecutionRoleArn`].OutputValue' --output text)
```
Quando vedi prompt che richiedono il tuo indirizzo e-mail e il nome utente del database, inserisci valori come i seguenti.
```
INPUT YOUR SNSSubEmailAddress HERE: Email_address_to_receive_SNS_notifications
INPUT YOUR DB_USER_NAME HERE: Database_user_name_you_define
```
Per verificare i valori delle variabili, utilizza il comando `print $variable`.
```
print $REGION
us-east-1
```
## Allocazione di risorse aggiuntive per supportare più nodi controller
Segui questi passaggi per fornire risorse aggiuntive per il tuo cluster Amazon SageMaker HyperPod Slurm con più nodi controller.
1. Scarica il file modello [sagemaker-hyperpod-slurm-multi-headnode.yaml](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/sagemaker-hyperpod-slurm-multi-headnode.yaml) sul tuo computer. Questo secondo file YAML è un CloudFormation modello che definisce le risorse aggiuntive da creare per il supporto di più nodi di controller nel cluster Slurm.
+ Un ruolo IAM di esecuzione per il gruppo di istanze del nodo controller
+ Un’istanza Amazon RDS per MariaDB
+ Un argomento e l’abbonamento Amazon SNS
+ Gestione dei segreti AWS credenziali per Amazon RDS for MariaDB
1. Esegui il seguente comando CLI per creare uno CloudFormation stack denominato. `sagemaker-hyperpod-mh` Questo secondo stack utilizza il CloudFormation modello per creare AWS risorse aggiuntive per supportare l'architettura a più nodi di controller.
```
aws cloudformation deploy \
--template-file /path_to_template/slurm-multi-headnode.yaml \
--stack-name sagemaker-hyperpod-mh \
--parameter-overrides \
SlurmDBSecurityGroupId=$SECURITY_GROUP \
SlurmDBSubnetGroupId1=$PRIMARY_SUBNET \
SlurmDBSubnetGroupId2=$BACKUP_SUBNET \
SNSSubEmailAddress=$EMAIL \
SlurmDBUsername=$DB_USER_NAME \
--capabilities CAPABILITY_NAMED_IAM
```
Per ulteriori informazioni, consulta [deploy](https://docs.aws.amazon.com//cli/latest/reference/cloudformation/deploy/) from the AWS Command Line Interface Reference. La creazione dello stack può richiedere alcuni minuti. Al termine, vedrai quanto segue nell’interfaccia a riga di comando.
```
Waiting for changeset to be created..
Waiting for stack create/update to complete
Successfully created/updated stack - sagemaker-hyperpod-mh
```
1. (Facoltativo) Verifica lo stack nella [console AWS Cloud Formation](https://console.aws.amazon.com/cloudformation/home).
+ Seleziona **Stack** dalla barra di navigazione a sinistra.
+ Nella pagina **Stack**, trova e scegli. **sagemaker-hyperpod-mh**
+ Scegli le schede **Risorse** e **Output** per esaminare le risorse e gli output.
1. Crea variabili di ambiente dagli output dello stack (`sagemaker-hyperpod-mh`). Utilizzerai i valori di queste variabili per aggiornare il file di configurazione (`provisioning_parameters.json`) in [Preparazione e caricamento degli script del ciclo di vita](sagemaker-hyperpod-multihead-slurm-scripts.md).
```
source .env
SLURM_DB_ENDPOINT_ADDRESS=$(aws --region us-east-1 cloudformation describe-stacks --stack-name $MULTI_HEAD_SLURM_STACK --query 'Stacks[0].Outputs[?OutputKey==`SlurmDBEndpointAddress`].OutputValue' --output text)
SLURM_DB_SECRET_ARN=$(aws --region us-east-1 cloudformation describe-stacks --stack-name $MULTI_HEAD_SLURM_STACK --query 'Stacks[0].Outputs[?OutputKey==`SlurmDBSecretArn`].OutputValue' --output text)
SLURM_EXECUTION_ROLE_ARN=$(aws --region us-east-1 cloudformation describe-stacks --stack-name $MULTI_HEAD_SLURM_STACK --query 'Stacks[0].Outputs[?OutputKey==`SlurmExecutionRoleArn`].OutputValue' --output text)
SLURM_SNS_FAILOVER_TOPIC_ARN=$(aws --region us-east-1 cloudformation describe-stacks --stack-name $MULTI_HEAD_SLURM_STACK --query 'Stacks[0].Outputs[?OutputKey==`SlurmFailOverSNSTopicArn`].OutputValue' --output text)
```
# Creazione e collegamento di una policy IAM
Questa sezione spiega come creare una policy IAM e collegarla al ruolo di esecuzione creato in [Allocazione di risorse aggiuntive per supportare più nodi controller](sagemaker-hyperpod-multihead-slurm-cfn.md#sagemaker-hyperpod-multihead-slurm-cfn-multihead).
1. Scarica l'[esempio di policy IAM sulla](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/1.AmazonSageMakerClustersExecutionRolePolicy.json) tua macchina dal GitHub repository.
1. Crea una policy IAM con l’esempio scaricato utilizzando il comando della CLI [create-policy](https://docs.aws.amazon.com//cli/latest/reference/iam/create-policy.html).
```
aws --region us-east-1 iam create-policy \
--policy-name AmazonSagemakerExecutionPolicy \
--policy-document file://1.AmazonSageMakerClustersExecutionRolePolicy.json
```
Esempio di output del comando.
```
{
"Policy": {
"PolicyName": "AmazonSagemakerExecutionPolicy",
"PolicyId": "ANPAXISIWY5UYZM7WJR4W",
"Arn": "arn:aws:iam::111122223333:policy/AmazonSagemakerExecutionPolicy",
"Path": "/",
"DefaultVersionId": "v1",
"AttachmentCount": 0,
"PermissionsBoundaryUsageCount": 0,
"IsAttachable": true,
"CreateDate": "2025-01-22T20:01:21+00:00",
"UpdateDate": "2025-01-22T20:01:21+00:00"
}
}
```
1. Allega la policy `AmazonSagemakerExecutionPolicy` al ruolo di esecuzione Slurm in cui hai creato[Allocazione di risorse aggiuntive per supportare più nodi controller](sagemaker-hyperpod-multihead-slurm-cfn.md#sagemaker-hyperpod-multihead-slurm-cfn-multihead), utilizzando il comando CLI [attach-role-policy](https://docs.aws.amazon.com//cli/latest/reference/iam/attach-role-policy.html).
```
aws --region us-east-1 iam attach-role-policy \
--role-name AmazonSagemakerExecutionRole \
--policy-arn arn:aws:iam::111122223333:policy/AmazonSagemakerExecutionPolicy
```
Il comando non produce output.
(Facoltativo) Se utilizzi le variabili di ambiente, ecco i comandi di esempio.
+ Per ottenere il nome del ruolo e il nome della policy
```
POLICY=$(aws --region $REGION iam list-policies --query 'Policies[?PolicyName==AmazonSagemakerExecutionPolicy].Arn' --output text)
ROLENAME=$(aws --region $REGION iam list-roles --query "Roles[?Arn=='${SLURM_EXECUTION_ROLE_ARN}'].RoleName" —output text)
```
+ Per collegare la policy
```
aws --region us-east-1 iam attach-role-policy \
--role-name $ROLENAME --policy-arn $POLICY
```
Per ulteriori informazioni, consulta [Ruolo IAM per SageMaker HyperPod](sagemaker-hyperpod-prerequisites-iam.md#sagemaker-hyperpod-prerequisites-iam-role-for-hyperpod).
# Preparazione e caricamento degli script del ciclo di vita
Dopo aver creato tutte le risorse richieste, dovrai configurare gli script del [ciclo](https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts) di vita per il tuo cluster. SageMaker HyperPod Questi [script del ciclo](https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts) di vita forniscono una [configurazione di base che puoi utilizzare per creare](https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config) un cluster Slurm di base. HyperPod
## Preparazione degli script del ciclo di vita
Segui questa procedura per ottenere gli script del ciclo di vita.
1. Scarica gli [script del ciclo di vita](https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts) dal repository sul tuo computer. GitHub
1. Carica gli [script del ciclo di vita](https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts) nel bucket Amazon S3 creato in [Allocazione di risorse di base](sagemaker-hyperpod-multihead-slurm-cfn.md#sagemaker-hyperpod-multihead-slurm-cfn-basic) utilizzando il comando della CLI [cp](https://docs.aws.amazon.com//cli/latest/reference/s3/cp.html).
```
aws s3 cp --recursive LifeCycleScripts/base-config s3://${ROOT_BUCKET_NAME}/LifeCycleScripts/base-config
```
## Creazione di un file di configurazione
Segui questa procedura per creare il file di configurazione e caricarlo nello stesso bucket Amazon S3 in cui archivi gli script del ciclo di vita.
1. Crea un file di configurazione denominato `provisioning_parameters.json` con la configurazione seguente. Ricorda che `slurm_sns_arn` è opzionale. Se non fornito, non HyperPod configurerà le notifiche di Amazon SNS.
```
cat < /tmp/provisioning_parameters.json
{
"version": "1.0.0",
"workload_manager": "slurm",
"controller_group": "$CONTOLLER_IG_NAME",
"login_group": "my-login-group",
"worker_groups": [
{
"instance_group_name": "$COMPUTE_IG_NAME",
"partition_name": "dev"
}
],
"fsx_dns_name": "$SLURM_FSX_DNS_NAME",
"fsx_mountname": "$SLURM_FSX_MOUNT_NAME",
"slurm_configurations": {
"slurm_database_secret_arn": "$SLURM_DB_SECRET_ARN",
"slurm_database_endpoint": "$SLURM_DB_ENDPOINT_ADDRESS",
"slurm_shared_directory": "/fsx",
"slurm_database_user": "$DB_USER_NAME",
"slurm_sns_arn": "$SLURM_SNS_FAILOVER_TOPIC_ARN"
}
}
EOF
```
1. Carica il file `provisioning_parameters.json` nello stesso bucket Amazon S3 in cui archivi gli script del ciclo di vita.
```
aws s3 cp /tmp/provisioning_parameters.json s3://${ROOT_BUCKET_NAME}/LifeCycleScripts/base-config/provisioning_parameters.json
```
**Nota**
Se utilizzi una configurazione basata su API, il `provisioning_parameters.json` file non è necessario. Con la configurazione basata su API, puoi definire i tipi di nodi Slurm, le partizioni e FSx il montaggio direttamente nel payload dell'API. CreateCluster [Per i dettagli, consulta Guida introduttiva all'utilizzo di. SageMaker HyperPod AWS CLI](smcluster-getting-started-slurm-cli.md)
## Verifica dei file nel bucket Amazon S3
Dopo aver caricato tutti gli script del ciclo di vita e il file `provisioning_parameters.json`, il bucket Amazon S3 dovrebbe avere il seguente aspetto.
![\[Immagine che mostra tutti gli script del ciclo di vita caricati nel bucket Amazon S3 nella console di Amazon Simple Storage Service.\]](http://docs.aws.amazon.com/it_it/sagemaker/latest/dg/images/hyperpod/hyperpod-lifecycle-scripts-s3.png)
Per ulteriori informazioni, consulta [Inizia con gli script del ciclo di vita di base](https://docs.aws.amazon.com//sagemaker/latest/dg/sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-base-config.html) forniti da. HyperPod
# Creazione di un cluster SageMaker HyperPod
Dopo aver configurato tutte le risorse richieste e caricato gli script nel bucket Amazon S3, puoi creare un cluster.
1. Per creare un cluster, esegui il [https://docs.aws.amazon.com//cli/latest/reference/sagemaker/create-cluster.html](https://docs.aws.amazon.com//cli/latest/reference/sagemaker/create-cluster.html) AWS CLI comando. Il completamento del processo può richiedere fino a 15 minuti.
```
aws --region $REGION sagemaker create-cluster \
--cluster-name $HP_CLUSTER_NAME \
--vpc-config '{
"SecurityGroupIds":["'$SECURITY_GROUP'"],
"Subnets":["'$PRIMARY_SUBNET'", "'$BACKUP_SUBNET'"]
}' \
--instance-groups '[{
"InstanceGroupName": "'$CONTOLLER_IG_NAME'",
"InstanceType": "ml.t3.medium",
"InstanceCount": 2,
"LifeCycleConfig": {
"SourceS3Uri": "s3://'$BUCKET_NAME'",
"OnCreate": "on_create.sh"
},
"ExecutionRole": "'$SLURM_EXECUTION_ROLE_ARN'",
"ThreadsPerCore": 1
},
{
"InstanceGroupName": "'$COMPUTE_IG_NAME'",
"InstanceType": "ml.c5.xlarge",
"InstanceCount": 2,
"LifeCycleConfig": {
"SourceS3Uri": "s3://'$BUCKET_NAME'",
"OnCreate": "on_create.sh"
},
"ExecutionRole": "'$COMPUTE_NODE_ROLE'",
"ThreadsPerCore": 1
}]'
```
Al termine, il comando restituisce l’ARN del cluster come mostrato di seguito.
```
{
"ClusterArn": "arn:aws:sagemaker:us-east-1:111122223333:cluster/cluster_id"
}
```
1. (Facoltativo) Per verificare lo stato del cluster, puoi utilizzare la console SageMaker AI ([https://console.aws.amazon.com/sagemaker/](https://console.aws.amazon.com/sagemaker/)). Dalla barra di navigazione a sinistra, scegli **HyperPod Cluster**, quindi scegli **Gestione cluster**. Scegli il nome del cluster per aprire la relativa pagina dei dettagli. Se il cluster è stato creato correttamente, vedrai che lo stato del cluster è **InService**.
![\[Immagine che mostra un cluster HyperPod Slurm con più nodi controller nella console Amazon SageMaker AI.\]](http://docs.aws.amazon.com/it_it/sagemaker/latest/dg/images/hyperpod/hyperpod-lifecycle-multihead-cluster.png)
# Note importanti
Questa sezione fornisce diverse note importanti che potrebbero esserti utili.
1. Per eseguire la migrazione a un cluster Slurm multi-controller, completa queste fasi.
1. Segui le istruzioni in [Fornitura di risorse tramite stack CloudFormation](sagemaker-hyperpod-multihead-slurm-cfn.md) per allocare tutte le risorse richieste.
1. Segui le istruzioni in [Preparazione e caricamento degli script del ciclo di vita](sagemaker-hyperpod-multihead-slurm-scripts.md) per caricare gli script del ciclo di vita aggiornati. Quando aggiorni il file `provisioning_parameters.json`, sposta il gruppo di controller esistente nella sezione `worker_groups` e aggiungi un nuovo nome per il gruppo di controller nella sezione `controller_group`.
1. Esegui la chiamata API [update-cluster](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/update-cluster.html) per creare un nuovo gruppo di controller e mantenere i gruppi di istanze di calcolo e il gruppo di controller originali.
1. Per ridurre verticalmente il numero di nodi controller, utilizza il comando della CLI [update-cluster](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/update-cluster.html). Per ogni gruppo di istanze del controller, il numero minimo di nodi controller che possono essere ridotti verticalmente è 1. Ciò significa che non è possibile ridurre verticalmente a 0 il numero di nodi controller.
**Importante**
Per i cluster creati prima del 24 gennaio 2025, è necessario aggiornare il software del cluster utilizzando l'[UpdateClusterSoftware](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_UpdateClusterSoftware.html)API prima di eseguire il comando CLI [update-cluster](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/update-cluster.html).
Di seguito è riportato un comando della CLI di esempio per ridurre verticalmente il numero di nodi controller.
```
aws sagemaker update-cluster \
--cluster-name my_cluster \
--instance-groups '[{
"InstanceGroupName": "controller_ig_name",
"InstanceType": "ml.t3.medium",
"InstanceCount": 3,
"LifeCycleConfig": {
"SourceS3Uri": "s3://amzn-s3-demo-bucket1",
"OnCreate": "on_create.sh"
},
"ExecutionRole": "slurm_execution_role_arn",
"ThreadsPerCore": 1
},
{
"InstanceGroupName": "compute-ig_name",
"InstanceType": "ml.c5.xlarge",
"InstanceCount": 2,
"LifeCycleConfig": {
"SourceS3Uri": "s3://amzn-s3-demo-bucket1",
"OnCreate": "on_create.sh"
},
"ExecutionRole": "compute_node_role_arn",
"ThreadsPerCore": 1
}]'
```
1. Per eliminare in batch i nodi del controller, usa il comando [batch-delete-cluster-nodes](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/batch-delete-cluster-nodes.html)CLI. Per ogni gruppo di istanze del controller, è necessario mantenere almeno un nodo controller. Per eliminare in batch tutti i nodi controller non può essere utilizzata l’operazione API.
**Importante**
Per i cluster creati prima del 24 gennaio 2025, è necessario aggiornare il software del cluster utilizzando l'[UpdateClusterSoftware](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_UpdateClusterSoftware.html)API prima di eseguire il comando CLI [batch-delete-cluster-nodes](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/batch-delete-cluster-nodes.html).
Di seguito è riportato un comando della CLI di esempio per eliminare in batch i nodi controller.
```
aws sagemaker batch-delete-cluster-nodes --cluster-name my_cluster --node-ids instance_ids_to_delete
```
1. Per risolvere i problemi di creazione del cluster, controlla il messaggio di errore nella pagina dei dettagli del cluster nella tua console AI. SageMaker Puoi anche utilizzare CloudWatch i log per risolvere i problemi di creazione dei cluster. **Dalla CloudWatch console, scegli Gruppi di log.** Quindi, cerca `clusters` per visualizzare l’elenco dei gruppi di log relativi alla creazione del cluster.
![\[Immagine che mostra i gruppi di log del SageMaker HyperPod cluster Amazon nella CloudWatch console.\]](http://docs.aws.amazon.com/it_it/sagemaker/latest/dg/images/hyperpod/hyperpod-lifecycle-multihead-logs.png)
# Revisione dei riferimenti alle variabili di ambiente
Le seguenti variabili di ambiente sono definite e utilizzate nel tutorial di [Configurazione di più nodi controller per un cluster SageMaker HyperPod Slurm](sagemaker-hyperpod-multihead-slurm-setup.md). Queste variabili di ambiente sono disponibili solo nella sessione corrente a meno che non vengano esplicitamente mantenute. Sono definite utilizzando la sintassi `$variable_name`. Le variabili con key/value coppie rappresentano risorse AWS create, mentre le variabili senza chiavi sono definite dall'utente.
**Riferimenti alle variabili di ambiente**
| Variabile | Description |
| --- | --- |
| \$1BACKUP\$1SUBNET | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/sagemaker/latest/dg/sagemaker-hyperpod-multihead-slurm-variables-reference.html) |
| \$1COMPUTE\$1IG\$1NAME | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/sagemaker/latest/dg/sagemaker-hyperpod-multihead-slurm-variables-reference.html) |
| \$1COMPUTE\$1NODE\$1ROLE | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/sagemaker/latest/dg/sagemaker-hyperpod-multihead-slurm-variables-reference.html) |
| \$1CONTOLLER\$1IG\$1NAME | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/sagemaker/latest/dg/sagemaker-hyperpod-multihead-slurm-variables-reference.html) |
| \$1DB\$1USER\$1NAME | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/sagemaker/latest/dg/sagemaker-hyperpod-multihead-slurm-variables-reference.html) |
| \$1EMAIL | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/sagemaker/latest/dg/sagemaker-hyperpod-multihead-slurm-variables-reference.html) |
| \$1PRIMARY\$1SUBNET | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/sagemaker/latest/dg/sagemaker-hyperpod-multihead-slurm-variables-reference.html) |
| \$1POLICY | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/sagemaker/latest/dg/sagemaker-hyperpod-multihead-slurm-variables-reference.html) |
| \$1REGION | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/sagemaker/latest/dg/sagemaker-hyperpod-multihead-slurm-variables-reference.html) |
| \$1ROOT\$1BUCKET\$1NAME | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/sagemaker/latest/dg/sagemaker-hyperpod-multihead-slurm-variables-reference.html) |
| \$1SECURITY\$1GROUP | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/sagemaker/latest/dg/sagemaker-hyperpod-multihead-slurm-variables-reference.html) |
| \$1SLURM\$1DB\$1ENDPOINT\$1ADDRESS | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/sagemaker/latest/dg/sagemaker-hyperpod-multihead-slurm-variables-reference.html) |
| \$1SLURM\$1DB\$1SECRET\$1ARN | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/sagemaker/latest/dg/sagemaker-hyperpod-multihead-slurm-variables-reference.html) |
| \$1SLURM\$1EXECUTION\$1ROLE\$1ARN | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/sagemaker/latest/dg/sagemaker-hyperpod-multihead-slurm-variables-reference.html) |
| \$1SLURM\$1FSX\$1DNS\$1NAME | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/sagemaker/latest/dg/sagemaker-hyperpod-multihead-slurm-variables-reference.html) |
| \$1SLURM\$1FSX\$1MOUNT\$1NAME | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/sagemaker/latest/dg/sagemaker-hyperpod-multihead-slurm-variables-reference.html) |
| \$1SLURM\$1SNS\$1FAILOVER\$1TOPIC\$1ARN | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/sagemaker/latest/dg/sagemaker-hyperpod-multihead-slurm-variables-reference.html) |
# Lavori su cluster SageMaker HyperPod
I seguenti argomenti forniscono procedure ed esempi di accesso ai nodi di calcolo e di esecuzione di carichi di lavoro ML su cluster assegnati. SageMaker HyperPod A seconda di come è stato configurato l'ambiente sul HyperPod cluster, esistono molti modi per eseguire carichi di lavoro ML sui cluster. HyperPod Esempi di esecuzione di carichi di lavoro ML su HyperPod cluster sono disponibili anche nell'archivio Awsome [Distributed](https://github.com/aws-samples/awsome-distributed-training/) Training. GitHub I seguenti argomenti illustrano come accedere ai HyperPod cluster predisposti e come iniziare a eseguire esempi di carichi di lavoro ML.
**Suggerimento**
[Per trovare esempi e soluzioni pratiche, consulta anche il workshop. SageMaker HyperPod](https://catalog.workshops.aws/sagemaker-hyperpod)
**Topics**
+ [Accesso ai nodi SageMaker HyperPod del cluster](sagemaker-hyperpod-run-jobs-slurm-access-nodes.md)
+ [Pianificazione di un job Slurm su un cluster SageMaker HyperPod](sagemaker-hyperpod-run-jobs-slurm-schedule-slurm-job.md)
+ [Esecuzione di contenitori Docker su un nodo di calcolo Slurm su HyperPod](sagemaker-hyperpod-run-jobs-slurm-docker.md)
+ [Esecuzione di carichi di lavoro di formazione distribuiti con Slurm on HyperPod](sagemaker-hyperpod-run-jobs-slurm-distributed-training-workload.md)
# Accesso ai nodi SageMaker HyperPod del cluster
È possibile accedere al **InService**cluster tramite AWS Systems Manager (SSM) eseguendo il AWS CLI comando `aws ssm start-session` con il nome host del SageMaker HyperPod cluster nel formato di`sagemaker-cluster:[cluster-id]_[instance-group-name]-[instance-id]`. È possibile recuperare l'ID del cluster, l'ID dell'istanza e il nome del gruppo di istanze dalla [SageMaker HyperPod console](sagemaker-hyperpod-operate-slurm-console-ui.md#sagemaker-hyperpod-operate-slurm-console-ui-view-details-of-clusters) o eseguendo `describe-cluster` e `list-cluster-nodes` dai [AWS CLI comandi](sagemaker-hyperpod-operate-slurm-cli-command.md#sagemaker-hyperpod-operate-slurm-cli-command-list-cluster-nodes) di. SageMaker HyperPod Ad esempio, se l’ID del cluster è `aa11bbbbb222`, il nome del nodo del cluster è `controller-group` e l’ID del nodo del cluster è `i-111222333444555aa`, il comando `start-session` di SSM dovrebbe essere il seguente.
**Nota**
La concessione agli utenti dell'accesso ai nodi HyperPod del cluster consente loro di installare e utilizzare software gestito dagli utenti sui nodi. Assicurati di rispettare il principio delle autorizzazioni con privilegio minimo per gli utenti.
Se non l'hai ancora configurato AWS Systems Manager, segui le istruzioni fornite all'indirizzo. [Configurazione AWS Systems Manager ed esecuzione come per il controllo degli accessi degli utenti del cluster](sagemaker-hyperpod-prerequisites.md#sagemaker-hyperpod-prerequisites-ssm)
```
$ aws ssm start-session \
--target sagemaker-cluster:aa11bbbbb222_controller-group-i-111222333444555aa \
--region us-west-2
Starting session with SessionId: s0011223344aabbccdd
root@ip-111-22-333-444:/usr/bin#
```
Tieni presente che questa operazione esegue una connessione iniziale come utente root. Prima di eseguire i processi, passa all’utente `ubuntu` con il comando seguente.
```
root@ip-111-22-333-444:/usr/bin# sudo su - ubuntu
ubuntu@ip-111-22-333-444:/usr/bin#
```
Per le impostazioni avanzate per l'uso pratico dei HyperPod cluster, consulta i seguenti argomenti.
**Topics**
+ [Suggerimenti aggiuntivi per accedere ai SageMaker HyperPod nodi del cluster](#sagemaker-hyperpod-run-jobs-slurm-access-nodes-tips)
+ [Configura un ambiente multiutente tramite lo spazio FSx condiviso di Amazon](#sagemaker-hyperpod-run-jobs-slurm-access-nodes-multi-user-with-fxs-shared-space)
+ [Configura un ambiente multiutente integrando HyperPod i cluster con Active Directory](#sagemaker-hyperpod-run-jobs-slurm-access-nodes-multi-user-with-active-directory)
## Suggerimenti aggiuntivi per accedere ai SageMaker HyperPod nodi del cluster
**Utilizza lo `easy-ssh.sh` script fornito da HyperPod per semplificare il processo di connessione**
Per trasformare il processo precedente in un comando a riga singola, il HyperPod team fornisce [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/easy-ssh.sh](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/easy-ssh.sh)lo script che recupera le informazioni sul cluster, le aggrega nel comando SSM e si connette al nodo di calcolo. Non è necessario cercare manualmente le informazioni richieste sul HyperPod cluster poiché questo script viene eseguito, `list-cluster-nodes` comanda `describe-cluster` e analizza le informazioni necessarie per completare il comando SSM. I comandi di esempio seguenti mostrano come eseguire lo script [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/easy-ssh.sh](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/easy-ssh.sh). Se lo script viene eseguito correttamente, viene stabilita una connessione al cluster come utente root. Stampa anche un frammento di codice per configurare SSH aggiungendo il HyperPod cluster come host remoto tramite un proxy SSM. Configurando SSH, puoi connettere il tuo ambiente di sviluppo locale, ad esempio Visual Studio Code, con il cluster. HyperPod
```
$ chmod +x easy-ssh.sh
$ ./easy-ssh.sh -c
Cluster id:
Instance id:
Node Group:
Add the following to your ~/.ssh/config to easily connect:
$ cat <> ~/.ssh/config
Host
User ubuntu
ProxyCommand sh -c "aws ssm start-session --target sagemaker-cluster:_- --document-name AWS-StartSSHSession --parameters 'portNumber=%p'"
EOF
Add your ssh keypair and then you can do:
$ ssh
aws ssm start-session --target sagemaker-cluster:_-
Starting session with SessionId: s0011223344aabbccdd
root@ip-111-22-333-444:/usr/bin#
```
Tieni presente che questa operazione esegue una connessione iniziale come utente root. Prima di eseguire i processi, passa all’utente `ubuntu` con il comando seguente.
```
root@ip-111-22-333-444:/usr/bin# sudo su - ubuntu
ubuntu@ip-111-22-333-444:/usr/bin#
```
**Configura per un facile accesso con SSH utilizzando il nodo di HyperPod calcolo come host remoto**
Per semplificare ulteriormente l'accesso al nodo di calcolo tramite SSH da un computer locale, lo `easy-ssh.sh` script genera un frammento di codice relativo alla configurazione del HyperPod cluster come host remoto, come mostrato nella sezione precedente. Lo snippet di codice viene generato automaticamente per aiutarti ad aggiungere direttamente lo script al file `~/.ssh/config` sul tuo dispositivo locale. La procedura seguente mostra come configurare un accesso semplificato tramite SSH tramite il proxy SSM, in modo che tu o gli utenti del cluster possiate `ssh ` collegarvi direttamente al nodo del cluster. HyperPod
1. Sul dispositivo locale, aggiungi al file il nodo di HyperPod elaborazione con un nome utente come host remoto. `~/.ssh/config` Il comando seguente mostra come aggiungere il frammento di codice generato automaticamente dallo script `easy-ssh.sh` al file `~/.ssh/config`. Assicurati di copiarlo dall’output generato automaticamente dello script `easy-ssh.sh` che contiene le informazioni corrette sul cluster.
```
$ cat <> ~/.ssh/config
Host
User ubuntu
ProxyCommand sh -c "aws ssm start-session --target sagemaker-cluster:_- --document-name AWS-StartSSHSession --parameters 'portNumber=%p'"
EOF
```
1. Sul nodo del HyperPod cluster, aggiungi la chiave pubblica sul dispositivo locale al `~/.ssh/authorized_keys` file sul nodo del HyperPod cluster.
1. Stampa il file della chiave pubblica sul computer locale.
```
$ cat ~/.ssh/id_rsa.pub
```
Questa operazione dovrebbe restituire la tua chiave. Copia l’output di questo comando.
(Facoltativo) Se non disponi di una chiave pubblica, creane una con il comando seguente.
```
$ ssh-keygen -t rsa -q -f "$HOME/.ssh/id_rsa" -N ""
```
1. Connettiti al nodo del cluster e passa all’utente per aggiungere la chiave. Il comando seguente è un esempio di accesso come utente `ubuntu`. Sostituisci `ubuntu` con il nome utente per il quale impostare l’accesso semplificato con SSH.
```
$ ./easy-ssh.sh -c
$ sudo su - ubuntu
ubuntu@ip-111-22-333-444:/usr/bin#
```
1. Apri il file `~/.ssh/authorized_keys` e aggiungi la chiave pubblica alla fine del file.
```
ubuntu@ip-111-22-333-444:/usr/bin# vim ~/.ssh/authorized_keys
```
Al termine della configurazione, puoi connetterti al nodo del HyperPod cluster come utente eseguendo un comando SSH semplificato come segue.
```
$ ssh
ubuntu@ip-111-22-333-444:/usr/bin#
```
Inoltre, puoi utilizzare l’host per lo sviluppo remoto da un IDE sul tuo dispositivo locale, ad esempio [Visual Studio Code Remote - SSH](https://code.visualstudio.com/docs/remote/ssh).
## Configura un ambiente multiutente tramite lo spazio FSx condiviso di Amazon
Puoi utilizzare lo spazio FSx condiviso di Amazon per gestire un ambiente multiutente in un cluster Slurm su. SageMaker HyperPod Se hai configurato il tuo cluster Slurm con Amazon FSx durante la creazione del HyperPod cluster, questa è una buona opzione per configurare lo spazio di lavoro per gli utenti del cluster. Crea un nuovo utente e configura la directory home per l'utente sul file system FSx condiviso di Amazon.
**Suggerimento**
Per consentire agli utenti di accedere al cluster con il proprio nome utente e le directory dedicate, devi anche associarli a ruoli o utenti IAM taggandoli come indicato nell’**opzione 2** della fase 5 della procedura **To turn on Run As support for Linux and macOS managed nodes** disponibile in [Turn on Run As support for Linux and macOS managed nodes](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-preferences-run-as.html) in AWS Systems Manager User Guide. Consulta anche [Configurazione AWS Systems Manager ed esecuzione come per il controllo degli accessi degli utenti del cluster](sagemaker-hyperpod-prerequisites.md#sagemaker-hyperpod-prerequisites-ssm).
**Per configurare un ambiente multiutente durante la creazione di un cluster Slurm su SageMaker HyperPod**
Il team SageMaker HyperPod di assistenza fornisce uno script [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/add_users.sh](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/add_users.sh)come parte degli esempi di script del ciclo di vita di base.
1. Prepara un file di testo denominato `shared_users.txt` che abbia il seguente formato. La prima colonna è per i nomi utente, la seconda per gli utenti IDs unici e la terza per le directory degli utenti nello spazio FSx condiviso di Amazon.
```
username1,uid1,/fsx/username1
username2,uid2,/fsx/username2
...
```
1. Assicurati di caricare [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/add_users.sh](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/add_users.sh)i file `shared_users.txt` and nel bucket S3 per gli script del ciclo di vita. HyperPod Durante la creazione del cluster oppure l’aggiornamento del cluster o del software del cluster, [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/add_users.sh](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/add_users.sh) legge `shared_users.txt` e configura correttamente le directory degli utenti.
**Per creare nuovi utenti e aggiungerli a un cluster Slurm esistente in esecuzione su SageMaker HyperPod **
1. Sul nodo head, utilizza il comando seguente per salvare uno script che consente di creare un utente. Assicurati di eseguirlo con le autorizzazioni sudo.
```
$ cat > create-user.sh << EOL
#!/bin/bash
set -x
# Prompt user to get the new user name.
read -p "Enter the new user name, i.e. 'sean':
" USER
# create home directory as /fsx/
# Create the new user on the head node
sudo useradd \$USER -m -d /fsx/\$USER --shell /bin/bash;
user_id=\$(id -u \$USER)
# add user to docker group
sudo usermod -aG docker \${USER}
# setup SSH Keypair
sudo -u \$USER ssh-keygen -t rsa -q -f "/fsx/\$USER/.ssh/id_rsa" -N ""
sudo -u \$USER cat /fsx/\$USER/.ssh/id_rsa.pub | sudo -u \$USER tee /fsx/\$USER/.ssh/authorized_keys
# add user to compute nodes
read -p "Number of compute nodes in your cluster, i.e. 8:
" NUM_NODES
srun -N \$NUM_NODES sudo useradd -u \$user_id \$USER -d /fsx/\$USER --shell /bin/bash;
# add them as a sudoer
read -p "Do you want this user to be a sudoer? (y/N):
" SUDO
if [ "\$SUDO" = "y" ]; then
sudo usermod -aG sudo \$USER
sudo srun -N \$NUM_NODES sudo usermod -aG sudo \$USER
echo -e "If you haven't already you'll need to run:\n\nsudo visudo /etc/sudoers\n\nChange the line:\n\n%sudo ALL=(ALL:ALL) ALL\n\nTo\n\n%sudo ALL=(ALL:ALL) NOPASSWD: ALL\n\nOn each node."
fi
EOL
```
1. Esegui lo script con il comando seguente. Ti verrà richiesto di aggiungere il nome di un utente e il numero di nodi di calcolo a cui desideri che l’utente abbia accesso.
```
$ bash create-user.sh
```
1. Testa l’utente utilizzando i comandi seguenti.
```
$ sudo su - && ssh $(srun hostname)
```
1. Aggiungi le informazioni sull’utente al file `shared_users.txt`, in modo che l’utente venga creato su qualsiasi nuovo nodo di calcolo o nuovo cluster.
## Configura un ambiente multiutente integrando HyperPod i cluster con Active Directory
Nei casi d'uso pratici, HyperPod i cluster vengono in genere utilizzati da più utenti: ricercatori di machine learning (ML), ingegneri del software, data scientist e amministratori di cluster. Questi utenti modificano i propri file ed eseguono i processi senza influire sul lavoro degli altri. Per configurare un ambiente multiutente, utilizza il meccanismo di utenti e gruppi Linux per creare staticamente più utenti su ogni istanza con gli script del ciclo di vita. Lo svantaggio di questo approccio, tuttavia, è che è necessario duplicare le impostazioni di utenti e gruppi su più istanze del cluster per mantenere una configurazione coerente in tutte le istanze quando si apportano aggiornamenti come l’aggiunta, la modifica e la rimozione di utenti.
Per risolvere questo problema, è possibile utilizzare [Lightweight Directory Access Protocol (LDAP)](https://en.wikipedia.org/wiki/Lightweight_Directory_Access_Protocol) e [LDAP over TLS/SSL (LDAPS)](https://en.wikipedia.org/wiki/Lightweight_Directory_Access_Protocol) per l'integrazione con un servizio di directory come Directory Service [for Microsoft AWS Active](https://aws.amazon.com/directoryservice/) Directory. Per ulteriori informazioni sulla configurazione di Active Directory e di un ambiente multiutente in un HyperPod cluster, consulta il post sul blog [Integrare HyperPod i cluster con Active Directory](https://aws.amazon.com/blogs/machine-learning/integrate-hyperpod-clusters-with-active-directory-for-seamless-multi-user-login/) per un accesso multiutente senza interruzioni.
# Pianificazione di un job Slurm su un cluster SageMaker HyperPod
Puoi avviare job di addestramento utilizzando i comandi standard `sbatch` o `srun` di Slurm. Ad esempio, per avviare un processo di formazione a 8 nodi, è possibile eseguire la formazione dei `srun -N 8 --exclusive train.sh` SageMaker HyperPod supporti in una serie di ambienti, tra cui`conda`, `venv``docker`, e`enroot`. È possibile configurare un ambiente ML eseguendo script del ciclo di vita sui cluster. SageMaker HyperPod Hai anche la possibilità di allegare un file system condiviso come Amazon FSx, che può essere utilizzato anche come ambiente virtuale.
L'esempio seguente mostra come eseguire un job per addestrare Llama-2 con la tecnica Fully Sharded Data Parallelism (FSDP) su un cluster SageMaker HyperPod con un file system condiviso Amazon. FSx [Puoi anche trovare altri esempi dal repository Awsome Distributed Training. GitHub ](https://github.com/aws-samples/awsome-distributed-training/)
**Suggerimento**
Tutti gli SageMaker HyperPod esempi sono disponibili nella `3.test_cases` cartella del repository [Awsome Distributed Training](https://github.com/aws-samples/awsome-distributed-training/). GitHub
1. Clona l'[ GitHub archivio Awsome Distributed Training](https://github.com/aws-samples/awsome-distributed-training/) e copia gli esempi di lavori di formazione sul tuo file system Amazon FSx .
```
$ TRAINING_DIR=/fsx/users/my-user/fsdp
$ git clone https://github.com/aws-samples/awsome-distributed-training/
```
1. Eseguire lo script [https://github.com/aws-samples/awsome-distributed-training/blob/main/3.test_cases/10.FSDP/0.create_conda_env.sh](https://github.com/aws-samples/awsome-distributed-training/blob/main/3.test_cases/10.FSDP/0.create_conda_env.sh). Questo crea un `conda` ambiente sul tuo FSx file system Amazon. Verifica che il file system sia accessibile a tutti i nodi del cluster.
1. Crea l’ambiente virtuale Conda avviando un processo Slurm a nodo singolo come descritto di seguito.
```
$ srun -N 1 /path_to/create_conda_env.sh
```
1. Dopo aver creato l’ambiente, puoi avviare un job di addestramento indicando il percorso dell’ambiente sul volume condiviso. Puoi avviare job di addestramento sia a nodo singolo che multinodo con la stessa configurazione. Per avviare un processo, crea uno script di avvio dei processi (chiamato anche script del punto di ingresso) come segue.
```
#!/usr/bin/env bash
set -ex
ENV_PATH=/fsx/users/my_user/pytorch_env
TORCHRUN=$ENV_PATH/bin/torchrun
TRAINING_SCRIPT=/fsx/users/my_user/pt_train.py
WORLD_SIZE_JOB=$SLURM_NTASKS
RANK_NODE=$SLURM_NODEID
PROC_PER_NODE=8
MASTER_ADDR=(`scontrol show hostnames \$SLURM_JOB_NODELIST | head -n 1`)
MASTER_PORT=$(expr 10000 + $(echo -n $SLURM_JOBID | tail -c 4))
DIST_ARGS="--nproc_per_node=$PROC_PER_NODE \
--nnodes=$WORLD_SIZE_JOB \
--node_rank=$RANK_NODE \
--master_addr=$MASTER_ADDR \
--master_port=$MASTER_PORT \
"
$TORCHRUN $DIST_ARGS $TRAINING_SCRIPT
```
**Suggerimento**
Se si desidera rendere il processo di formazione più resistente ai guasti hardware utilizzando la funzionalità di ripristino automatico di SageMaker HyperPod, è necessario impostare correttamente la variabile di ambiente `MASTER_ADDR` nello script entrypoint. Per ulteriori informazioni, consulta [Ripristino automatico dei nodi e ripristino automatico](sagemaker-hyperpod-resiliency-slurm-auto-resume.md).
Questo tutorial presuppone che questo script sia salvato come `/fsx/users/my_user/train.sh`.
1. Con questo script nel volume condiviso in `/fsx/users/my_user/train.sh`, esegui il comando `srun` seguente per pianificare il processo Slurm.
```
$ cd /fsx/users/my_user/
$ srun -N 8 train.sh
```
# Esecuzione di contenitori Docker su un nodo di calcolo Slurm su HyperPod
[https://github.com/NVIDIA/enroot](https://github.com/NVIDIA/enroot) Il pacchetto Enroot aiuta a convertire le immagini Docker in un runtime comprensibile da Slurm, mentre Pyxis consente di pianificare il runtime come processo Slurm tramite un comando `srun`, `srun --container-image=docker/image:tag`.
**Suggerimento**
I pacchetti Docker, Enroot e Pyxis devono essere installati durante la creazione del cluster come parte dell’esecuzione degli script del ciclo di vita come indicato in [Script del ciclo di vita di base forniti da HyperPod](sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-base-config.md). Utilizza gli [script del ciclo di vita di base](https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config) forniti dal team di assistenza durante la creazione di un cluster. HyperPod HyperPod Questi script di base sono configurati per installare i pacchetti per impostazione predefinita. Nello script [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/config.py](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/config.py) è presente la classe `Config` con il parametro di tipo booleano per l’installazione dei pacchetti impostato su `True` (`enable_docker_enroot_pyxis=True`). Questo viene richiamato e analizzato nello script [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/lifecycle_script.py](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/lifecycle_script.py), che chiama gli script `install_docker.sh` e `install_enroot_pyxis.sh` dalla cartella [https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/utils](https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/utils). Le installazioni effettive dei pacchetti avvengono negli script di installazione. Inoltre, gli script di installazione identificano se sono in grado di rilevare i percorsi di NVMe archiviazione dalle istanze su cui vengono eseguiti e configurano i percorsi root per Docker ed Enroot. `/opt/dlami/nvme` Il volume root predefinito di ogni nuova istanza viene montato `/tmp` solo su un volume EBS da 100 GB, che si esaurisce se il carico di lavoro che intendi eseguire prevede l'addestramento di contenitori Docker di LLMs grandi dimensioni. Se utilizzi famiglie di istanze come P e G con NVMe archiviazione locale, devi assicurarti di utilizzare lo NVMe storage allegato a `/opt/dlami/nvme` e che gli script di installazione si occupino dei processi di configurazione.
**Per verificare se i percorsi root sono configurati correttamente**
Su un nodo di calcolo del tuo cluster Slurm SageMaker HyperPod, esegui i seguenti comandi per assicurarti che lo script del ciclo di vita funzioni correttamente e che il volume principale di ogni nodo sia impostato su. `/opt/dlami/nvme/*` I comandi seguenti mostrano esempi di come controllare il percorso di runtime di Enroot e del percorso root dei dati per 8 nodi di calcolo di un cluster Slurm.
```
$ srun -N 8 cat /etc/enroot/enroot.conf | grep "ENROOT_RUNTIME_PATH"
ENROOT_RUNTIME_PATH /opt/dlami/nvme/tmp/enroot/user-$(id -u)
... // The same or similar lines repeat 7 times
```
```
$ srun -N 8 cat /etc/docker/daemon.json
{
"data-root": "/opt/dlami/nvme/docker/data-root"
}
... // The same or similar lines repeat 7 times
```
Dopo aver verificato che i percorsi di runtime sono impostati correttamente su `/opt/dlami/nvme/*`, puoi iniziare a creare ed eseguire i container Docker con Enroot e Pyxis.
**Per testare Docker con Slurm**
1. Sul tuo nodo di calcolo, prova i comandi seguenti per verificare se Docker ed Enroot sono installati correttamente.
```
$ docker --help
$ enroot --help
```
1. Verifica se Pyxis ed Enroot sono installati correttamente eseguendo una delle immagini [NVIDIA CUDA Ubuntu](https://catalog.ngc.nvidia.com/orgs/nvidia/containers/cuda).
```
$ srun --container-image=nvidia/cuda:XX.Y.Z-base-ubuntuXX.YY nvidia-smi
pyxis: importing docker image: nvidia/cuda:XX.Y.Z-base-ubuntuXX.YY
pyxis: imported docker image: nvidia/cuda:XX.Y.Z-base-ubuntuXX.YY
DAY MMM DD HH:MM:SS YYYY
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 470.141.03 Driver Version: 470.141.03 CUDA Version: XX.YY |
|-------------------------------+----------------------+----------------------+
| GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. |
| | | MIG M. |
|===============================+======================+======================|
| 0 Tesla T4 Off | 00000000:00:1E.0 Off | 0 |
| N/A 40C P0 27W / 70W | 0MiB / 15109MiB | 0% Default |
| | | N/A |
+-------------------------------+----------------------+----------------------+
+-----------------------------------------------------------------------------+
| Processes: |
| GPU GI CI PID Type Process name GPU Memory |
| ID ID Usage |
|=============================================================================|
| No running processes found |
+-----------------------------------------------------------------------------+
```
Puoi verificarlo anche creando uno script ed eseguendo un comando `sbatch`, come descritto di seguito.
```
$ cat <> container-test.sh
#!/bin/bash
#SBATCH --container-image=nvidia/cuda:XX.Y.Z-base-ubuntuXX.YY
nvidia-smi
EOF
$ sbatch container-test.sh
pyxis: importing docker image: nvidia/cuda:XX.Y.Z-base-ubuntuXX.YY
pyxis: imported docker image: nvidia/cuda:XX.Y.Z-base-ubuntuXX.YY
DAY MMM DD HH:MM:SS YYYY
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 470.141.03 Driver Version: 470.141.03 CUDA Version: XX.YY |
|-------------------------------+----------------------+----------------------+
| GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. |
| | | MIG M. |
|===============================+======================+======================|
| 0 Tesla T4 Off | 00000000:00:1E.0 Off | 0 |
| N/A 40C P0 27W / 70W | 0MiB / 15109MiB | 0% Default |
| | | N/A |
+-------------------------------+----------------------+----------------------+
+-----------------------------------------------------------------------------+
| Processes: |
| GPU GI CI PID Type Process name GPU Memory |
| ID ID Usage |
|=============================================================================|
| No running processes found |
+-----------------------------------------------------------------------------+
```
**Per eseguire un processo Slurm di prova con Docker**
Dopo aver completato la configurazione di Slurm con Docker, puoi portare qualsiasi immagine Docker preconfigurata ed eseguirla utilizzando Slurm on. SageMaker HyperPod Di seguito è riportato un esempio di caso d'uso che illustra come eseguire un processo di formazione utilizzando Docker e Slurm on. SageMaker HyperPod Mostra un esempio di lavoro di addestramento parallelo al modello Llama 2 con la libreria SageMaker AI model parallelism (SMP).
1. Se desideri utilizzare una delle immagini ECR predefinite distribuite da SageMaker AI o DLC, assicurati di concedere al HyperPod cluster le autorizzazioni per estrarre le immagini ECR da. [Ruolo IAM per SageMaker HyperPod](sagemaker-hyperpod-prerequisites-iam.md#sagemaker-hyperpod-prerequisites-iam-role-for-hyperpod) Se utilizzi un’immagine Docker personalizzata o open source, puoi saltare questa fase. Aggiungi le autorizzazioni seguenti al [Ruolo IAM per SageMaker HyperPod](sagemaker-hyperpod-prerequisites-iam.md#sagemaker-hyperpod-prerequisites-iam-role-for-hyperpod). In questo tutorial, utilizziamo l’[immagine Docker SMP](distributed-model-parallel-support-v2.md#distributed-model-parallel-supported-frameworks-v2) preconfezionata con la libreria SMP.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ecr:BatchCheckLayerAvailability",
"ecr:BatchGetImage",
"ecr-public:*",
"ecr:GetDownloadUrlForLayer",
"ecr:GetAuthorizationToken",
"sts:*"
],
"Resource": "*"
}
]
}
```
------
1. Sul nodo di calcolo, clona il repository e vai alla cartella che fornisce gli script di esempio per l’addestramento con SMP.
```
$ git clone https://github.com/aws-samples/awsome-distributed-training/
$ cd awsome-distributed-training/3.test_cases/17.SM-modelparallelv2
```
1. In questo tutorial, esegui lo script di esempio [https://github.com/aws-samples/awsome-distributed-training/blob/main/3.test_cases/17.SM-modelparallelv2/docker_build.sh](https://github.com/aws-samples/awsome-distributed-training/blob/main/3.test_cases/17.SM-modelparallelv2/docker_build.sh) che estrae l’immagine Docker SMP, crea il container Docker e lo esegue come runtime Enroot. Puoi modificare lo script in base alle tue esigenze.
```
$ cat docker_build.sh
#!/usr/bin/env bash
region=us-west-2
dlc_account_id=658645717510
aws ecr get-login-password --region $region | docker login --username AWS --password-stdin $dlc_account_id.dkr.ecr.$region.amazonaws.com
docker build -t smpv2 .
enroot import -o smpv2.sqsh dockerd://smpv2:latest
```
```
$ bash docker_build.sh
```
1. Crea uno script batch per avviare un job di addestramento utilizzando`sbatch`. In questo tutorial, lo script di esempio fornito [https://github.com/aws-samples/awsome-distributed-training/blob/main/3.test_cases/17.SM-modelparallelv2/launch_training_enroot.sh](https://github.com/aws-samples/awsome-distributed-training/blob/main/3.test_cases/17.SM-modelparallelv2/launch_training_enroot.sh) avvia un job di addestramento con parallelizzazione del modello Llama 2 da 70 miliardi di parametri con un set di dati sintetico su 8 nodi di calcolo. Un set di script di addestramento viene fornito a [https://github.com/aws-samples/awsome-distributed-training/tree/main/3.test_cases/17.SM-modelparallelv2/scripts](https://github.com/aws-samples/awsome-distributed-training/tree/main/3.test_cases/17.SM-modelparallelv2/scripts) e `launch_training_enroot.sh` utilizza `train_external.py` come script del punto di ingresso.
**Importante**
Per utilizzare un contenitore Docker SageMaker HyperPod, devi montare la `/var/log` directory dalla macchina host, che in questo caso è il nodo di HyperPod elaborazione, sulla directory del contenitore. `/var/log` Puoi configurarlo aggiungendo la seguente variabile per Enroot.
```
"${HYPERPOD_PATH:="/var/log/aws/clusters":"/var/log/aws/clusters"}"
```
```
$ cat launch_training_enroot.sh
#!/bin/bash
# Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
# SPDX-License-Identifier: MIT-0
#SBATCH --nodes=8 # number of nodes to use, 2 p4d(e) = 16 A100 GPUs
#SBATCH --job-name=smpv2_llama # name of your job
#SBATCH --exclusive # job has exclusive use of the resource, no sharing
#SBATCH --wait-all-nodes=1
set -ex;
###########################
###### User Variables #####
###########################
#########################
model_type=llama_v2
model_size=70b
# Toggle this to use synthetic data
use_synthetic_data=1
# To run training on your own data set Training/Test Data path -> Change this to the tokenized dataset path in Fsx. Acceptable formats are huggingface (arrow) and Jsonlines.
# Also change the use_synthetic_data to 0
export TRAINING_DIR=/fsx/path_to_data
export TEST_DIR=/fsx/path_to_data
export CHECKPOINT_DIR=$(pwd)/checkpoints
# Variables for Enroot
: "${IMAGE:=$(pwd)/smpv2.sqsh}"
: "${HYPERPOD_PATH:="/var/log/aws/clusters":"/var/log/aws/clusters"}" # This is needed for validating its hyperpod cluster
: "${TRAIN_DATA_PATH:=$TRAINING_DIR:$TRAINING_DIR}"
: "${TEST_DATA_PATH:=$TEST_DIR:$TEST_DIR}"
: "${CHECKPOINT_PATH:=$CHECKPOINT_DIR:$CHECKPOINT_DIR}"
###########################
## Environment Variables ##
###########################
#export NCCL_SOCKET_IFNAME=en
export NCCL_ASYNC_ERROR_HANDLING=1
export NCCL_PROTO="simple"
export NCCL_SOCKET_IFNAME="^lo,docker"
export RDMAV_FORK_SAFE=1
export FI_EFA_USE_DEVICE_RDMA=1
export NCCL_DEBUG_SUBSYS=off
export NCCL_DEBUG="INFO"
export SM_NUM_GPUS=8
export GPU_NUM_DEVICES=8
export FI_EFA_SET_CUDA_SYNC_MEMOPS=0
# async runtime error ...
export CUDA_DEVICE_MAX_CONNECTIONS=1
#########################
## Command and Options ##
#########################
if [ "$model_size" == "7b" ]; then
HIDDEN_WIDTH=4096
NUM_LAYERS=32
NUM_HEADS=32
LLAMA_INTERMEDIATE_SIZE=11008
DEFAULT_SHARD_DEGREE=8
# More Llama model size options
elif [ "$model_size" == "70b" ]; then
HIDDEN_WIDTH=8192
NUM_LAYERS=80
NUM_HEADS=64
LLAMA_INTERMEDIATE_SIZE=28672
# Reduce for better perf on p4de
DEFAULT_SHARD_DEGREE=64
fi
if [ -z "$shard_degree" ]; then
SHARD_DEGREE=$DEFAULT_SHARD_DEGREE
else
SHARD_DEGREE=$shard_degree
fi
if [ -z "$LLAMA_INTERMEDIATE_SIZE" ]; then
LLAMA_ARGS=""
else
LLAMA_ARGS="--llama_intermediate_size $LLAMA_INTERMEDIATE_SIZE "
fi
if [ $use_synthetic_data == 1 ]; then
echo "using synthetic data"
declare -a ARGS=(
--container-image $IMAGE
--container-mounts $HYPERPOD_PATH,$CHECKPOINT_PATH
)
else
echo "using real data...."
declare -a ARGS=(
--container-image $IMAGE
--container-mounts $HYPERPOD_PATH,$TRAIN_DATA_PATH,$TEST_DATA_PATH,$CHECKPOINT_PATH
)
fi
declare -a TORCHRUN_ARGS=(
# change this to match the number of gpus per node:
--nproc_per_node=8 \
--nnodes=$SLURM_JOB_NUM_NODES \
--rdzv_id=$SLURM_JOB_ID \
--rdzv_backend=c10d \
--rdzv_endpoint=$(hostname) \
)
srun -l "${ARGS[@]}" torchrun "${TORCHRUN_ARGS[@]}" /path_to/train_external.py \
--train_batch_size 4 \
--max_steps 100 \
--hidden_width $HIDDEN_WIDTH \
--num_layers $NUM_LAYERS \
--num_heads $NUM_HEADS \
${LLAMA_ARGS} \
--shard_degree $SHARD_DEGREE \
--model_type $model_type \
--profile_nsys 1 \
--use_smp_implementation 1 \
--max_context_width 4096 \
--tensor_parallel_degree 1 \
--use_synthetic_data $use_synthetic_data \
--training_dir $TRAINING_DIR \
--test_dir $TEST_DIR \
--dataset_type hf \
--checkpoint_dir $CHECKPOINT_DIR \
--checkpoint_freq 100 \
$ sbatch launch_training_enroot.sh
```
*Per trovare gli esempi di codice scaricabili, consulta [Esegui un processo di formazione parallelo ai modelli utilizzando la libreria di parallelismo dei modelli SageMaker AI, Docker ed Enroot con](https://github.com/aws-samples/awsome-distributed-training/tree/main/3.test_cases/17.SM-modelparallelv2#option-2----run-training-using-docker-and-enroot) Slurm nell'archivio Awsome Distributed Training. GitHub * Per ulteriori informazioni sulla formazione distribuita con un cluster Slurm su, passa all'argomento successivo all'indirizzo. SageMaker HyperPod [Esecuzione di carichi di lavoro di formazione distribuiti con Slurm on HyperPod](sagemaker-hyperpod-run-jobs-slurm-distributed-training-workload.md)
# Esecuzione di carichi di lavoro di formazione distribuiti con Slurm on HyperPod
SageMaker HyperPod è specializzato per carichi di lavoro di formazione di modelli linguistici di grandi dimensioni (LLMs) e modelli di base (). FMs Questi carichi di lavoro richiedono spesso l’utilizzo di più tecniche di parallelizzazione e operazioni ottimizzate per l’infrastruttura e le risorse di ML. Utilizzando SageMaker HyperPod, puoi utilizzare i seguenti framework di formazione distribuiti SageMaker basati sull'intelligenza artificiale:
+ La [libreria SageMaker AI Distributed Data Parallelism (SMDDP)](data-parallel.md) che offre operazioni di comunicazione collettiva ottimizzate per. AWS
+ La [libreria di parallelismo dei modelli SageMaker AI (SMP)](model-parallel-v2.md) che implementa varie tecniche di parallelismo dei modelli.
**Topics**
+ [Utilizzo di SMDDP su un SageMaker HyperPod](#sagemaker-hyperpod-run-jobs-slurm-distributed-training-workload-smddp)
+ [Utilizzo SageMaker HyperPod di SMP su un cluster](#sagemaker-hyperpod-run-jobs-slurm-distributed-training-workload-smp)
## Utilizzo di SMDDP su un SageMaker HyperPod
La [libreria SMDDP](data-parallel.md) è una libreria di comunicazione collettiva che migliora le prestazioni di calcolo dell’addestramento parallelo di dati distribuiti. La libreria SMDDP funziona con i seguenti framework di addestramento distribuito open source:
+ [PyTorchdati distribuiti in parallelo (DDP)](https://pytorch.org/docs/stable/notes/ddp.html)
+ [PyTorch parallelismo dei dati completamente condiviso (FSDP)](https://pytorch.org/docs/stable/fsdp.html)
+ [DeepSpeed](https://github.com/microsoft/DeepSpeed)
+ [Megatron- DeepSpeed](https://github.com/microsoft/Megatron-DeepSpeed)
La libreria SMDDP affronta il sovraccarico di comunicazione delle principali operazioni di comunicazione collettiva offrendo quanto segue per. SageMaker HyperPod
+ La libreria offre offerte `AllGather` ottimizzate per. AWS`AllGather`è un'operazione chiave utilizzata nell'addestramento parallelo dei dati condivisi, una tecnica di parallelismo dei dati efficiente in termini di memoria offerta dalle librerie più diffuse. Queste includono la libreria SageMaker AI Model Parallelism (SMP), DeepSpeed Zero Redundancy Optimizer (Zero) e Fully Sharded Data Parallelism (FSDP). PyTorch
+ La libreria esegue node-to-node comunicazioni ottimizzate utilizzando appieno l'infrastruttura di rete e la topologia dell'istanza AI ML. AWS SageMaker
**Per eseguire job di addestramento di esempio con parallelizzazione dei dati**
Esplora gli esempi seguenti di addestramento distribuito che implementano tecniche di parallelizzazione dei dati utilizzando la libreria SMDDP.
+ [https://github.com/aws-samples/awsome-distributed-training/tree/main/3.test_cases/12.SM-dataparallel-FSDP](https://github.com/aws-samples/awsome-distributed-training/tree/main/3.test_cases/12.SM-dataparallel-FSDP)
+ [https://github.com/aws-samples/awsome-distributed-training/tree/main/3.test_cases/13.SM-dataparallel-deepspeed](https://github.com/aws-samples/awsome-distributed-training/tree/main/3.test_cases/13.SM-dataparallel-deepspeed)
**Per configurare un ambiente per l'utilizzo della libreria SMDDP su SageMaker HyperPod**
Di seguito sono riportati i requisiti dell'ambiente di formazione per l'utilizzo della libreria SMDDP su. SageMaker HyperPod
+ PyTorch v2.0.1 e versioni successive
+ CUDA v11.8 e versioni successive
+ `libstdc++` versione di runtime superiore a 3
+ Python v3.10.x e versioni successive
+ `ml.p4d.24xlarge` e `ml.p4de.24xlarge`, ovvero i tipi di istanze supportati dalla libreria SMDDP
+ `imdsv2` abilitato sull’host di addestramento
A seconda di come si desidera eseguire il job di addestramento distribuito, sono disponibili due opzioni per installare la libreria SMDDP:
+ Un’installazione diretta che utilizza il file binario SMDDP.
+ Utilizzo dell' SageMaker AI Deep Learning Containers (DLCs) preinstallato con la libreria SMDDP.
[Le immagini Docker preinstallate con la libreria SMDDP o i file binari SMDDP sono elencate URLs in Supported Frameworks nella documentazione della libreria SMDDP.](https://docs.aws.amazon.com/sagemaker/latest/dg/distributed-data-parallel-support.html#distributed-data-parallel-supported-frameworks)
**Per installare la libreria SMDDP su DLAMI SageMaker HyperPod**
+ `pip install --no-cache-dir https://smdataparallel.s3.amazonaws.com/binary/pytorch//cuXYZ/YYYY-MM-DD/smdistributed_dataparallel-X.Y.Z-cp310-cp310-linux_x86_64.whl`
**Nota**
Se lavori in un ambiente Conda, assicurati di installare PyTorch using instead of. `conda install` `pip`
```
conda install pytorch==X.Y.Z torchvision==X.Y.Z torchaudio==X.Y.Z pytorch-cuda=X.Y.Z -c pytorch -c nvidia
```
**Per utilizzare la libreria SMDDP su un container Docker**
+ La libreria SMDDP è preinstallata su SageMaker AI Deep Learning Containers (). DLCs Per trovare l'elenco dei framework SageMaker DLCs AI compatibili PyTorch con la libreria SMDDP, consulta [Supported Frameworks](https://docs.aws.amazon.com/sagemaker/latest/dg/distributed-data-parallel-support.html#distributed-data-parallel-supported-frameworks) nella documentazione della libreria SMDDP. Puoi anche utilizzare il tuo container Docker su cui sono installate le dipendenze richieste per la libreria SMDDP. Per ulteriori informazioni sulla configurazione di un container Docker personalizzato per l’utilizzo della libreria SMDDP, consulta anche [Crea il tuo contenitore Docker con la libreria parallela di dati distribuiti SageMaker AI](data-parallel-bring-your-own-container.md).
**Importante**
Per utilizzare la libreria SMDDP in un container Docker, monta la directory `/var/log` dal computer host a `/var/log` nel container. Per farlo, aggiungi l’opzione seguente durante l’esecuzione del container.
```
docker run -v /var/log:/var/log ...
```
Per informazioni generali su come eseguire job di addestramento con parallelizzazione dei dati con SMDDP, consulta [Formazione distribuita con la libreria di parallelismo dei dati distribuiti SageMaker AI](data-parallel-modify-sdp.md).
## Utilizzo SageMaker HyperPod di SMP su un cluster
La [libreria SageMaker AI model parallelism (SMP)](model-parallel-v2.md) offre varie tecniche di [parallelismo dei state-of-the-art modelli](model-parallel-core-features-v2.md), tra cui:
+ fully sharded data parallelism
+ parallelizzazione degli esperti
+ addestramento di precisione misto con/e tipi di dati FP16 BF16 FP8
+ parallelizzazione tensoriale
La libreria SMP è anche compatibile con framework open source come PyTorch FSDP, NVIDIA Megatron e NVIDIA Transformer Engine.
**Per eseguire un esempio di carico di lavoro di addestramento con parallelizzazione del modello**
I team di assistenza SageMaker AI forniscono esempi di lavori di formazione che implementano il parallelismo dei modelli con la libreria SMP all'indirizzo. [https://github.com/aws-samples/awsome-distributed-training/tree/main/3.test_cases/17.SM-modelparallelv2](https://github.com/aws-samples/awsome-distributed-training/tree/main/3.test_cases/17.SM-modelparallelv2)
# SageMaker HyperPod monitoraggio delle risorse del cluster
[Per ottenere un'osservabilità completa nelle risorse del SageMaker HyperPod cluster e nei componenti software, integra il cluster con [Amazon Managed Service for Prometheus](https://docs.aws.amazon.com/prometheus/latest/userguide/what-is-Amazon-Managed-Service-Prometheus.html) e Amazon Managed Grafana.](https://docs.aws.amazon.com/grafana/latest/userguide/what-is-Amazon-Managed-Service-Grafana.html) L'integrazione con Amazon Managed Service for Prometheus consente l'esportazione di metriche relative alle HyperPod risorse del cluster, fornendo informazioni sulle loro prestazioni, utilizzo e integrità. L’integrazione con Grafana gestito da Amazon consente la visualizzazione di queste metriche attraverso varie dashboard Grafana che offrono un’interfaccia intuitiva per il monitoraggio e l’analisi del comportamento del cluster. Sfruttando questi servizi, ottieni una visione centralizzata e unificata del HyperPod cluster, facilitando il monitoraggio proattivo, la risoluzione dei problemi e l'ottimizzazione dei carichi di lavoro di formazione distribuiti.
**Suggerimento**
[Per trovare esempi e soluzioni pratiche, consulta anche il workshop. SageMaker HyperPod](https://catalog.workshops.aws/sagemaker-hyperpod)
![\[Una panoramica della configurazione SageMaker HyperPod con Amazon Managed Service for Prometheus e Amazon Managed Grafana.\]](http://docs.aws.amazon.com/it_it/sagemaker/latest/dg/images/hyperpod-observability-architecture.png)
Figura: questo diagramma di architettura mostra una panoramica della configurazione con SageMaker HyperPod Amazon Managed Service for Prometheus e Amazon Managed Grafana.
Passa ai seguenti argomenti per configurare l'osservabilità del cluster. SageMaker HyperPod
**Topics**
+ [Prerequisiti per SageMaker HyperPod l'osservabilità dei cluster](sagemaker-hyperpod-cluster-observability-slurm-prerequisites.md)
+ [Installazione HyperPod dei pacchetti Metrics Exporter sul tuo cluster](sagemaker-hyperpod-cluster-observability-slurm-install-exporters.md)
+ [Convalida della configurazione di Prometheus sul nodo principale di un cluster HyperPod](sagemaker-hyperpod-cluster-observability-slurm-validate-prometheus-setup.md)
+ [Configurazione di uno spazio di lavoro Grafana gestito da Amazon](sagemaker-hyperpod-cluster-observability-slurm-managed-grafana-ws.md)
+ [Riferimento delle metriche esportate](sagemaker-hyperpod-cluster-observability-slurm-exported-metrics-reference.md)
+ [Metriche di Amazon SageMaker HyperPod Slurm](smcluster-slurm-metrics.md)
# Prerequisiti per SageMaker HyperPod l'osservabilità dei cluster
Prima di procedere con la procedura descritta in [Installazione HyperPod dei pacchetti Metrics Exporter sul tuo cluster](sagemaker-hyperpod-cluster-observability-slurm-install-exporters.md), verifica che siano soddisfatti i seguenti prerequisiti.
## Abilita IAM Identity Center
Per abilitare l'osservabilità per il SageMaker HyperPod cluster, devi prima abilitare IAM Identity Center. Questo è un prerequisito per la distribuzione di uno CloudFormation stack che configuri l'area di lavoro Amazon Managed Grafana e Amazon Managed Service for Prometheus. Entrambi i servizi richiedono il Centro identità IAM anche per l’autenticazione e le autorizzazioni, per garantire un accesso sicuro agli utenti e la gestione dell’infrastruttura di monitoraggio.
Per una guida dettagliata sull’abilitazione del Centro identità IAM, consulta la sezione [Enabling IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/get-set-up-for-idc.html) nella guida *AWS IAM Identity Center User Guide*.
Dopo aver abilitato correttamente il Centro identità IAM, configura un account utente che fungerà da utente amministratore nelle procedure di configurazione seguenti.
## Crea e CloudFormation distribuisci SageMaker HyperPod uno stack per l'osservabilità
Crea e distribuisci uno CloudFormation stack per l' SageMaker HyperPod osservabilità per monitorare i parametri del HyperPod cluster in tempo reale utilizzando Amazon Managed Service for Prometheus e Amazon Managed Grafana. Per implementare lo stack, tieni presente che devi abilitare prima il [Centro identità IAM](https://console.aws.amazon.com/singlesignon).
Usa lo CloudFormation script di esempio [https://github.com/aws-samples/awsome-distributed-training/blob/main/4.validation_and_observability/4.prometheus-grafana/cluster-observability.yaml](https://github.com/aws-samples/awsome-distributed-training/blob/main/4.validation_and_observability/4.prometheus-grafana/cluster-observability.yaml)che ti aiuta a configurare le sottoreti Amazon VPC, i file system FSx Amazon for Lustre, i bucket Amazon S3 e i ruoli IAM necessari per creare uno stack di osservabilità del cluster. HyperPod
# Installazione HyperPod dei pacchetti Metrics Exporter sul tuo cluster
Nella [configurazione di base, gli script del ciclo](sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-base-config.md) di vita forniti dal SageMaker HyperPod team includono anche l'installazione di vari pacchetti Metric Exporter. Per attivare la fase di installazione, devi semplicemente impostare il parametro `enable_observability=True` nel file [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/config.py](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/config.py). Gli script del ciclo di vita sono progettati per il bootstrap del cluster con i seguenti pacchetti di esportazione di metriche open source.
| | | |
| --- |--- |--- |
| Nome | Nodo di destinazione per l’implementazione degli script | Descrizione dello strumento di esportazione |
| [Strumento di esportazione Slurm per Prometheus](https://github.com/vpenso/prometheus-slurm-exporter) | Nodo head (controller) | Esporta le metriche di accounting Slurm. |
| [Esportazione di nodi Elastic Fabric Adapter (EFA)](https://github.com/aws-samples/awsome-distributed-training/tree/main/4.validation_and_observability/3.efa-node-exporter) | Nodo di calcolo | Esporta le metriche dai nodi del cluster e da EFA. Il pacchetto è un fork dello [strumento di esportazione di nodi Prometheus](https://github.com/prometheus/node_exporter). |
| [Strumento di esportazione di NVIDIA Data Center GPU Management (DCGM)](https://github.com/NVIDIA/dcgm-exporter) | Nodo di calcolo | Esporta i parametri NVIDIA DCGM sullo stato e le prestazioni di NVIDIA. GPUs |
Con `enable_observability=True` nel file [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/config.py](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/config.py), nello script viene attivata la fase di installazione seguente [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/lifecycle_script.py](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/lifecycle_script.py).
```
# Install metric exporting software and Prometheus for observability
if Config.enable_observability:
if node_type == SlurmNodeType.COMPUTE_NODE:
ExecuteBashScript("./utils/install_docker.sh").run()
ExecuteBashScript("./utils/install_dcgm_exporter.sh").run()
ExecuteBashScript("./utils/install_efa_node_exporter.sh").run()
if node_type == SlurmNodeType.HEAD_NODE:
wait_for_scontrol()
ExecuteBashScript("./utils/install_docker.sh").run()
ExecuteBashScript("./utils/install_slurm_exporter.sh").run()
ExecuteBashScript("./utils/install_prometheus.sh").run()
```
Sui nodi di calcolo, lo script installa lo strumento di esportazione di nodi NVIDIA Data Center GPU Management (DCGM) e lo strumento di esportazione di nodi Elastic Fabric Adapter (EFA). L'esportatore DCGM è un esportatore per Prometheus che raccoglie metriche da GPUs NVIDIA, abilitando il monitoraggio dell'utilizzo, delle prestazioni e dello stato della GPU. Lo strumento di esportazione di nodi EFA, invece, raccoglie metriche relative all’interfaccia di rete EFA, essenziale per comunicazioni a bassa latenza e larghezza di banda elevata nei cluster HPC.
Sul nodo head, lo script installa lo strumento di esportazione Slurm per Prometheus e il [software open source Prometheus](https://prometheus.io/docs/introduction/overview/). Lo strumento di esportazione Slurm fornisce a Prometheus le metriche relative ai processi, alle partizioni e agli stati dei nodi Slurm.
Nota che gli script del ciclo di vita sono progettati per installare tutti i pacchetti di esportazione come container Docker, quindi il pacchetto Docker deve essere installato anche sui nodi head e di calcolo. *Gli script per questi componenti sono comodamente disponibili nella cartella del repository Awsome Distributed Training. [https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/utils](https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/utils) GitHub *
Dopo aver configurato correttamente il HyperPod cluster installato con i pacchetti di esportazione, passa all'argomento successivo per completare la configurazione di Amazon Managed Service for Prometheus e Amazon Managed Grafana.
# Convalida della configurazione di Prometheus sul nodo principale di un cluster HyperPod
Dopo aver configurato correttamente il HyperPod cluster installato con i pacchetti exporter, controlla se Prometheus è configurato correttamente sul nodo principale del cluster. HyperPod
1. Connettiti al nodo head del cluster. Per istruzioni su come accedere a un nodo, consulta [Accesso ai nodi SageMaker HyperPod del cluster](sagemaker-hyperpod-run-jobs-slurm-access-nodes.md).
1. Utilizza il comando seguente per verificare che il file di configurazione e servizio di Prometheus creato dallo script del ciclo di vita `install_prometheus.sh` sia in esecuzione sul nodo controller. L’output dovrebbe mostrare lo stato Attivo **active (running)**.
```
$ sudo systemctl status prometheus
• prometheus service - Prometheus Exporter
Loaded: loaded (/etc/systemd/system/prometheus.service; enabled; preset:disabled)
Active: active (running) since DAY YYYY-MM-DD HH:MM:SS UTC; Ss ago
Main PID: 12345 (prometheus)
Tasks: 7 (limit: 9281)
Memory: 35M
CPU: 234ms
CGroup: /system.slice/prometheus.service
-12345 /usr/bin/prometheus--config.file=/etc/prometheus/prometheus.yml
```
1. Convalida il file di configurazione di Prometheus come segue. L’output deve essere simile al seguente, con tre strumenti di esportazione configurati con gli indirizzi IP dei nodi di calcolo corretti.
```
$ cat /etc/prometheus/prometheus.yml
global:
scrape_interval: 15s
evaluation_interval: 15s
scrape_timeout: 15s
scrape_configs:
- job_name: 'slurm_exporter'
static_configs:
- targets:
- 'localhost:8080'
- job_name: 'dcgm_exporter'
static_configs:
- targets:
- ':9400'
- ':9400'
- job_name: 'efa_node_exporter'
static_configs:
- targets:
- ':9100'
- ':9100'
remote_write:
- url:
queue_config:
max_samples_per_send: 1000
max_shards: 200
capacity: 2500
sigv4:
region:
```
1. Per verificare se Prometheus sta esportando correttamente le metriche Slurm, DCGM ed EFA, esegui questo comando `curl` per Prometheus sulla porta `:9090` sul nodo head.
```
$ curl -s http://localhost:9090/metrics | grep -E 'slurm|dcgm|efa'
```
Con le metriche esportate nello spazio di lavoro Servizio gestito da Amazon per Prometheus tramite la configurazione della scrittura remota di Prometheus dal nodo controller, puoi passare all’argomento successivo per configurare le dashboard di Grafana gestito da Amazon per visualizzare le metriche.
# Configurazione di uno spazio di lavoro Grafana gestito da Amazon
Crea un nuovo spazio di lavoro Grafana gestito da Amazon o aggiornane uno esistente con Servizio gestito da Amazon per Prometheus come origine dati.
**Topics**
+ [Creazione di uno spazio di lavoro Grafana e impostazione del Servizio gestito da Amazon per Prometheus come origine dati](#sagemaker-hyperpod-cluster-observability-slurm-managed-grafana-ws-create)
+ [Apertura dello spazio di lavoro Grafana e completamento della configurazione dell’origine dati](#sagemaker-hyperpod-cluster-observability-slurm-managed-grafana-ws-connect-data-source)
+ [Importazione di dashboard Grafana open source](#sagemaker-hyperpod-cluster-observability-slurm-managed-grafana-ws-import-dashboards)
## Creazione di uno spazio di lavoro Grafana e impostazione del Servizio gestito da Amazon per Prometheus come origine dati
Per visualizzare le metriche di Servizio gestito da Amazon per Prometheus, crea uno spazio di lavoro Grafana gestito da Amazon e configuralo per utilizzare il Servizio gestito da Amazon per Prometheus come origine dati.
1. Per creare uno spazio di lavoro Grafana, segui le istruzioni in [Creating a workspace](https://docs.aws.amazon.com/grafana/latest/userguide/AMG-create-workspace.html#creating-workspace) in *Amazon Managed Service for Prometheus User Guide*.
1. Nella Fase 13, seleziona Servizio gestito da Amazon per Prometheus come origine dati.
1. Nella Fase 17, puoi aggiungere l’utente amministratore e anche altri utenti nel tuo Centro identità IAM.
Per ulteriori informazioni, consulta le risorse seguenti.
+ [Set up Amazon Managed Grafana for use with Amazon Managed Service for Prometheus](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-amg.html) in *Amazon Managed Service for Prometheus User Guide*
+ [Usa la configurazione dell'origine AWS dati per aggiungere Amazon Managed Service for Prometheus come origine dati](https://docs.aws.amazon.com/grafana/latest/userguide/AMP-adding-AWS-config.html) *nella Amazon Managed Grafana User Guide*
## Apertura dello spazio di lavoro Grafana e completamento della configurazione dell’origine dati
Dopo aver creato o aggiornato correttamente uno spazio di lavoro Grafana gestito da Amazon, apri lo spazio di lavoro selezionando il relativo URL. Questo richiede di inserire un nome utente e la password dell’utente che hai configurato nel Centro identità IAM. Devi accedere con l’utente amministratore per completare la configurazione dello spazio di lavoro.
1. Nella **home page** dello spazio di lavoro, scegli **App**, **Origini dati AWS ** e **Origini dati**.
1. Nella pagina **Origini dati**, scegli la scheda **Origini dati**.
1. In **Servizio**, scegli Servizio gestito da Amazon per Prometheus.
1. Nella sezione **Sfoglia e fornisci fonti di dati**, scegli la AWS regione in cui hai effettuato il provisioning di uno spazio di lavoro Amazon Managed Service for Prometheus.
1. Dall’elenco delle origini dati nella Regione selezionata, scegli quella per Servizio gestito da Amazon per Prometheus. Assicurati di controllare l'ID della risorsa e l'alias della risorsa dell'area di lavoro Amazon Managed Service for Prometheus che hai configurato per lo stack di osservabilità. HyperPod
## Importazione di dashboard Grafana open source
Dopo aver configurato correttamente il tuo spazio di lavoro Grafana gestito da Amazon con Servizio gestito da Amazon per Prometheus come origine dati, inizi a raccogliere metriche per Prometheus, quindi dovresti vedere le varie dashboard che mostrano grafici, informazioni e altro ancora. Il software open source Grafana offre diverse dashboard che puoi importare in Grafana gestito da Amazon.
**Per importare dashboard Grafana open source in Grafana gestito da Amazon**
1. Nella **home** page del tuo spazio di lavoro Grafana gestito da Amazon, scegli **Dashboard**.
1. Scegli il pulsante del menu a discesa con il testo dell’interfaccia utente **Nuovo** e seleziona **Importa**.
1. Incolla l’URL nella [dashboard di Slurm](https://grafana.com/grafana/dashboards/4323-slurm-dashboard/).
```
https://grafana.com/grafana/dashboards/4323-slurm-dashboard/
```
1. Seleziona **Carica**.
1. Ripeti le fasi precedenti per importare le dashboard seguenti.
1. [Dashboard completa per l’esportazione di nodi](https://grafana.com/grafana/dashboards/1860-node-exporter-full/)
```
https://grafana.com/grafana/dashboards/1860-node-exporter-full/
```
1. [Dashboard di esportazione NVIDIA DCGM](https://grafana.com/grafana/dashboards/12239-nvidia-dcgm-exporter-dashboard/)
```
https://grafana.com/grafana/dashboards/12239-nvidia-dcgm-exporter-dashboard/
```
1. [Dashboard delle metriche EFA](https://grafana.com/grafana/dashboards/20579-efa-metrics-dev/)
```
https://grafana.com/grafana/dashboards/20579-efa-metrics-dev/
```
1. [FSx per Lustre Metrics Dashboard](https://grafana.com/grafana/dashboards/20906-fsx-lustre/)
```
https://grafana.com/grafana/dashboards/20906-fsx-lustre/
```
# Riferimento delle metriche esportate
Le seguenti sezioni presentano elenchi completi di metriche esportate da SageMaker HyperPod Amazon Managed Service for Prometheus dopo la corretta configurazione dello stack per l'osservabilità. CloudFormation SageMaker HyperPod Puoi iniziare a monitorare le metriche visualizzate nelle dashboard di Grafana gestito da Amazon.
## Dashboard di esportazione Slurm
Fornisce informazioni visualizzate sui cluster Slurm su. SageMaker HyperPod
**Tipi di metriche**
+ **Panoramica del cluster:** visualizzazione del numero totale di nodi, processi e relativi stati.
+ **Metriche dei processi:** visualizzazione del numero e dello stato dei processi nel tempo.
+ **Metriche dei nodi:** visualizzazione degli stati, dell’allocazione e delle risorse disponibili dei nodi.
+ **Metriche delle partizioni:** monitoraggio di metriche specifiche della partizione come l’utilizzo di CPU, memoria e GPU.
+ **Efficienza dei processi:** calcolo dell’efficienza dei processi in base alle risorse utilizzate.
**Elenco delle metriche**
| Nome parametro | Description |
| --- | --- |
| slurm\$1job\$1count | Numero totale di processi nel cluster Slurm |
| slurm\$1job\$1state\$1count | Numero di processi in ogni stato (ad esempio, in esecuzione, in sospeso, completati) |
| slurm\$1node\$1count | Numero totale di nodi nel cluster Slurm |
| slurm\$1node\$1state\$1count | Numero di nodi in ogni stato (ad esempio, inattivo, allocato, misto) |
| slurm\$1partition\$1node\$1count | Numero di nodi in ogni partizione |
| slurm\$1partition\$1job\$1count | Numero di processi in ogni partizione |
| slurm\$1partition\$1alloc\$1cpus | Numero totale di elementi allocati in ogni partizione CPUs |
| slurm\$1partition\$1free\$1cpus | Numero totale di elementi disponibili CPUs in ogni partizione |
| slurm\$1partition\$1alloc\$1memory | Memoria totale allocata in ogni partizione |
| slurm\$1partition\$1free\$1memory | Memoria totale disponibile in ogni partizione |
| slurm\$1partition\$1alloc\$1gpus | Totale allocato GPUs in ogni partizione |
| slurm\$1partition\$1free\$1gpus | Totale disponibile GPUs in ogni partizione |
## Dashboard di esportazione di nodi
Fornisce informazioni visualizzate sulle metriche di sistema raccolte dall'esportatore di nodi Prometheus dai [nodi del cluster](https://github.com/prometheus/node_exporter). HyperPod
**Tipi di metriche**
+ **Panoramica del sistema:** visualizzazione delle medie di carico della CPU e dell’utilizzo della memoria.
+ **Metriche della memoria:** visualizzazione dell’utilizzo della memoria, tra cui memoria totale, memoria libera e spazio di swap.
+ **Utilizzo del disco:** monitoraggio dell’utilizzo e della disponibilità dello spazio su disco.
+ **Traffico di rete:** visualizzazione dei byte di rete ricevuti e trasmessi nel tempo.
+ **Metriche del file system:** analisi dell’utilizzo e della disponibilità del file system.
+ ** I/O Metriche del disco:** visualizzazione dell'attività di lettura e scrittura su disco.
**Elenco delle metriche**
[Per un elenco completo delle metriche esportate, consultate i repository [Node](https://github.com/prometheus/node_exporter?tab=readme-ov-file#enabled-by-default) exporter e procfs.](https://github.com/prometheus/procfs?tab=readme-ov-file) GitHub La tabella seguente mostra un sottoinsieme di metriche che fornisce informazioni approfondite sull’utilizzo delle risorse di sistema, come il carico della CPU, l’utilizzo della memoria, lo spazio su disco e l’attività di rete.
| Nome parametro | Description |
| --- | --- |
| node\$1load1 | Carico medio ogni minuto |
| node\$1load5 | Carico medio ogni 5 minuti |
| node\$1load15 | Carico medio ogni 15 minuti |
| node\$1memory\$1MemTotal | Memoria totale di sistema |
| node\$1memory\$1MemFree | Memoria di sistema libera |
| node\$1memory\$1MemAvailable | Memoria disponibile per l’allocazione dei processi |
| node\$1memory\$1Buffers | Memoria utilizzata dal kernel per il buffering |
| node\$1memory\$1Cached | Memoria utilizzata dal kernel per il caching dei dati del file system |
| node\$1memory\$1SwapTotal | Spazio di swap totale disponibile |
| node\$1memory\$1SwapFree | Spazio di swap libero |
| node\$1memory\$1SwapCached | Memoria precedentemente sottoposta a swap, che viene reinserita ma resta in modalità swap |
| node\$1filesystem\$1avail\$1bytes | Spazio disponibile su disco in byte |
| node\$1filesystem\$1size\$1bytes | Spazio totale su disco in byte |
| node\$1filesystem\$1free\$1bytes | Spazio libero su disco in byte |
| node\$1network\$1receive\$1bytes | Byte di rete ricevuti |
| node\$1network\$1transmit\$1bytes | Byte di rete trasmessi |
| node\$1disk\$1read\$1bytes | Byte del disco letti |
| node\$1disk\$1written\$1bytes | Byte del disco scritti |
## Dashboard di esportazione NVIDIA DCGM
Fornisce informazioni visive sulle metriche delle GPU NVIDIA raccolte dallo [strumento di esportazione NVIDIA DCGM](https://github.com/NVIDIA/dcgm-exporter).
**Tipi di metriche**
+ **Panoramica della GPU:** visualizzazione dell’utilizzo della GPU, delle temperature, del consumo energetico e della memoria.
+ **Metriche di temperatura:** visualizzazione delle temperature della GPU nel tempo.
+ **Consumo energetico:** monitoraggio dell’assorbimento energetico della GPU e delle tendenze del consumo energetico.
+ **Utilizzo della memoria:** analisi dell’utilizzo della memoria della GPU, che include la memoria utilizzata, quella libera e quella totale.
+ **Velocità della ventola:** visualizzazione delle velocità e delle variazioni delle ventole della GPU.
+ **Errori ECC:** tracciamento degli errori ECC della memoria GPU e degli errori in sospeso.
**Elenco delle metriche**
La tabella seguente mostra un elenco di metriche che fornisce informazioni approfondite sull’integrità e sulle prestazioni della GPU NVIDIA, tra cui frequenze di clock, temperature, consumo energetico, utilizzo della memoria, velocità delle ventole e metriche di errore.
| Nome parametro | Description |
| --- | --- |
| DCGM\$1FI\$1DEV\$1SM\$1CLOCK | Frequenza di clock SM (in) MHz |
| DCGM\$1FI\$1DEV\$1MEM\$1CLOCK | Frequenza di clock della memoria (in MHz) |
| DCGM\$1FI\$1DEV\$1MEMORY\$1TEMP | Temperatura della memoria (in °C) |
| DCGM\$1FI\$1DEV\$1GPU\$1TEMP | Temperatura della GPU (in °C) |
| DCGM\$1FI\$1DEV\$1POWER\$1USAGE | Potenza assorbita (in W) |
| DCGM\$1FI\$1DEV\$1TOTAL\$1ENERGY\$1CONSUMPTION | Consumo energetico totale dall’avvio (in mJ) |
| DCGM\$1FI\$1DEV\$1PCIE\$1REPLAY\$1COUNTER | Numero totale di PCIe tentativi |
| DCGM\$1FI\$1DEV\$1MEM\$1COPY\$1UTIL | Utilizzo della memoria (in %) |
| DCGM\$1FI\$1DEV\$1ENC\$1UTIL | Utilizzo dell’encoder (in %) |
| DCGM\$1FI\$1DEV\$1DEC\$1UTIL | Utilizzo del decoder (in %) |
| DCGM\$1FI\$1DEV\$1XID\$1ERRORS | Valore dell’ultimo errore XID rilevato |
| DCGM\$1FI\$1DEV\$1FB\$1FREE | Memoria libera del frame buffer (in MiB) |
| DCGM\$1FI\$1DEV\$1FB\$1USED | Memoria utilizzata del frame buffer (in MiB) |
| DCGM\$1FI\$1DEV\$1NVLINK\$1BANDWIDTH\$1TOTAL | Numero totale di contatori della NVLink larghezza di banda per tutte le corsie |
| DCGM\$1FI\$1DEV\$1VGPU\$1LICENSE\$1STATUS | Stato della licenza vGPU |
| DCGM\$1FI\$1DEV\$1UNCORRECTABLE\$1REMAPPED\$1ROWS | Numero di righe rimappate per errori non correggibili |
| DCGM\$1FI\$1DEV\$1CORRECTABLE\$1REMAPPED\$1ROWS | Numero di righe rimappate per errori correggibili |
| DCGM\$1FI\$1DEV\$1ROW\$1REMAP\$1FAILURE | Esito negativo della rimappatura delle righe |
## Dashboard delle metriche EFA
Fornisce informazioni visive sulle metriche raccolte tramite lo [strumento di esportazione di nodi EFA](https://github.com/aws-samples/awsome-distributed-training/blob/main/4.validation_and_observability/3.efa-node-exporter/README.md) con [Amazon Elastic Fabric Adapter (EFA)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa.html) installato nelle istanze P.
**Tipi di metriche**
+ **Metriche di errore EFA:** visualizzazione di errori quali quelli di allocazione, dei comandi e della mappa di memoria.
+ **Traffico di rete EFA:** monitoraggio di byte, pacchetti e richieste di processi ricevuti e trasmessi.
+ **Prestazioni RDMA EFA:** analisi delle operazioni di lettura e scrittura RDMA, inclusi i byte trasferiti e i tassi di errore.
+ **Durata delle porte EFA:** visualizzazione della durata delle porte EFA nel tempo.
+ **Pacchetti keep-alive EFA:** tracciamento del numero di pacchetti keep-alive ricevuti.
**Elenco delle metriche**
La tabella seguente mostra un elenco di metriche che fornisce informazioni approfondite su vari aspetti del funzionamento di EFA, tra cui errori, comandi completati, traffico di rete e utilizzo delle risorse.
| Nome parametro | Description |
| --- | --- |
| node\$1amazonefa\$1info | Dati non numerici provenienti da/sys/class/infiniband/, il valore è sempre 1. |
| node\$1amazonefa\$1lifespan | Durata della porta |
| node\$1amazonefa\$1rdma\$1read\$1bytes | Numero di byte letti con RDMA |
| node\$1amazonefa\$1rdma\$1read\$1resp\$1bytes | Numero di byte di risposta letti con RDMA |
| node\$1amazonefa\$1rdma\$1read\$1wr\$1err | Numero di errori di scrittura letti con RDMA |
| node\$1amazonefa\$1rdma\$1read\$1wrs | Numero di scritture lette con RDMA |
| node\$1amazonefa\$1rdma\$1write\$1bytes | Numero di byte scritti con RDMA |
| node\$1amazonefa\$1rdma\$1write\$1recv\$1bytes | Numero di byte scritti e ricevuti con RDMA |
| node\$1amazonefa\$1rdma\$1write\$1wr\$1err | Numero di byte scritti con errore RDMA |
| node\$1amazonefa\$1rdma\$1write\$1wrs | Numero di byte di scritture scritti con RDMA |
| node\$1amazonefa\$1recv\$1bytes | Numero di byte ricevuti |
| node\$1amazonefa\$1recv\$1wrs | Numero di byte di scritture ricevuti |
| node\$1amazonefa\$1rx\$1bytes | Numero di byte ricevuti |
| node\$1amazonefa\$1rx\$1drops | Numero di pacchetti annullati |
| node\$1amazonefa\$1rx\$1pkts | Numero di pacchetti ricevuti |
| node\$1amazonefa\$1send\$1bytes | Numero di byte inviati |
| node\$1amazonefa\$1send\$1wrs | Numero di scritture inviate |
| node\$1amazonefa\$1tx\$1bytes | Numero di byte trasmessi |
| node\$1amazonefa\$1tx\$1pkts | Numero di pacchetti trasmessi |
## FSx per la dashboard delle metriche di Lustre
[Fornisce informazioni visualizzate sulle [metriche del file system Amazon FSx for Lustre](https://docs.aws.amazon.com/fsx/latest/LustreGuide/monitoring-cloudwatch.html) raccolte da Amazon. CloudWatch](https://docs.aws.amazon.com/fsx/latest/LustreGuide/monitoring-cloudwatch.html)
**Nota**
La dashboard Grafana FSx for Lustre utilizza Amazon CloudWatch come fonte di dati, che si differenzia dalle altre dashboard configurate per utilizzare Amazon Managed Service for Prometheus. Per garantire un monitoraggio e una visualizzazione accurati delle metriche relative al file system FSx for Lustre, configura la dashboard FSx for Lustre per utilizzare Amazon CloudWatch come fonte di dati, specificando lo stesso Regione AWS luogo in cui viene distribuito il file system FSx for Lustre.
**Tipi di metriche**
+ **DataReadBytes:** Il numero di byte per le operazioni di lettura del file system.
+ **DataWriteBytes:** il numero di byte per le operazioni di scrittura del file system.
+ **DataReadOperations:** Il numero di operazioni di lettura.
+ **DataWriteOperations:** Il numero di operazioni di scrittura.
+ **MetadataOperations:** Il numero di operazioni sui metadati.
+ **FreeDataStorageCapacity:** La quantità di capacità di archiviazione disponibile.
# Metriche di Amazon SageMaker HyperPod Slurm
Amazon SageMaker HyperPod fornisce una serie di CloudWatch parametri Amazon che puoi utilizzare per monitorare lo stato e le prestazioni dei tuoi HyperPod cluster. Queste metriche vengono raccolte dal gestore del carico di lavoro Slurm in esecuzione sui tuoi HyperPod cluster e sono disponibili nel namespace. `/aws/sagemaker/Clusters` CloudWatch
## Metriche a livello di cluster
Le seguenti metriche a livello di cluster sono disponibili per. HyperPod Queste metriche utilizzano la `ClusterId` dimensione per identificare il cluster specifico. HyperPod
| CloudWatch nome della metrica | Note | Nome della metrica di Amazon ECS Container Insights |
| --- | --- | --- |
| cluster\$1node\$1count | Numero totale di nodi nel cluster | cluster\$1node\$1count |
| cluster\$1idle\$1node\$1count | Numero di nodi inattivi nel cluster | N/D |
| cluster\$1failed\$1node\$1count | Numero di nodi non riusciti nel cluster | cluster\$1failed\$1node\$1count |
| cluster\$1cpu\$1count | Numero totale di core CPU nel cluster | node\$1cpu\$1limit |
| cluster\$1idle\$1cpu\$1count | Numero di core CPU inattivi nel cluster | N/D |
| cluster\$1gpu\$1count | Totale GPUs nel cluster | node\$1gpu\$1limit |
| cluster\$1idle\$1gpu\$1count | Numero di inattività GPUs nel cluster | N/D |
| cluster\$1running\$1task\$1count | Numero di processi Slurm in esecuzione nel cluster | N/D |
| cluster\$1pending\$1task\$1count | Numero di processi Slurm in sospeso nel cluster | N/D |
| cluster\$1preempted\$1task\$1count | Numero di processi Slurm prerilasciati nel cluster | N/D |
| cluster\$1avg\$1task\$1wait\$1time | Tempo di attesa medio per i processi Slurm nel cluster | N/D |
| cluster\$1max\$1task\$1wait\$1time | Tempo di attesa massimo per i processi Slurm nel cluster | N/D |
## Metriche a livello di istanza
Le seguenti metriche a livello di istanza sono disponibili per. HyperPod Queste metriche utilizzano la `ClusterId` dimensione anche per identificare il cluster specifico. HyperPod
| CloudWatch nome della metrica | Note | Nome della metrica di Amazon ECS Container Insights |
| --- | --- | --- |
| node\$1gpu\$1utilization | Utilizzo medio della GPU in tutte le istanze | node\$1gpu\$1utilization |
| node\$1gpu\$1memory\$1utilization | Utilizzo medio della memoria GPU in tutte le istanze | node\$1gpu\$1memory\$1utilization |
| node\$1cpu\$1utilization | Utilizzo medio della CPU in tutte le istanze | node\$1cpu\$1utilization |
| node\$1memory\$1utilization | Utilizzo medio della memoria in tutte le istanze | node\$1memory\$1utilization |
# SageMaker HyperPod resilienza del cluster
SageMaker HyperPod tramite l'orchestrazione Slurm fornisce le seguenti funzionalità di resilienza del cluster.
**Topics**
+ [Agente di monitoraggio della salute](sagemaker-hyperpod-resiliency-slurm-cluster-health-check.md)
+ [Ripristino automatico dei nodi e ripristino automatico](sagemaker-hyperpod-resiliency-slurm-auto-resume.md)
+ [Sostituisci o riavvia manualmente un nodo usando Slurm](sagemaker-hyperpod-resiliency-slurm-replace-faulty-instance.md)
# Agente di monitoraggio della salute
Questa sezione descrive l'insieme di controlli di integrità SageMaker HyperPod utilizzati per monitorare regolarmente lo stato delle istanze del cluster per individuare problemi relativi a dispositivi come acceleratori (core GPU e Trainium) e rete (EFA). SageMaker HyperPod Health-Monitoring Agent (HMA) monitora continuamente lo stato di salute di ogni istanza basata su GPU o Trainium. Quando rileva un errore dell’istanza o della GPU, l’agente contrassegna l’istanza come non integra.
SageMaker HyperPod HMA esegue gli stessi controlli di integrità per gli orchestratori EKS e Slurm. Per ulteriori informazioni su HMA, vedere. [Sistema di monitoraggio della salute](sagemaker-hyperpod-eks-resiliency-health-monitoring-agent.md)
# Ripristino automatico dei nodi e ripristino automatico
**Nota**
A partire dall'11 settembre 2025, HyperPod con Slurm orchestration ora supporta gli agenti di monitoraggio dello stato di salute. Esegui [UpdateClusterSoftware](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_UpdateClusterSoftware.html)e aggiorna l'AMI alla versione più recente per utilizzare questa funzionalità.
Questa sezione parla delle due funzionalità SageMaker HyperPod di resilienza complementari di Amazon: il ripristino automatico dei nodi che sostituisce l'infrastruttura difettosa senza l'intervento manuale e la funzionalità di ripristino automatico che riavvia i lavori di formazione dall'ultimo checkpoint dopo i guasti hardware.
## Come funziona il ripristino automatico dei nodi
Durante la creazione o l’aggiornamento del cluster, gli utenti amministratori del cluster possono selezionare l’opzione di ripristino del nodo (istanza) scegliendo tra `Automatic` (consigliato) e `None` a livello di cluster. Se impostato su`Automatic`, SageMaker HyperPod riavvia o sostituisce automaticamente i nodi difettosi.
**Importante**
Consigliamo di impostare l’opzione `Automatic`. Per impostazione predefinita, i cluster sono configurati con il ripristino automatico dei nodi.
Il ripristino automatico dei nodi viene eseguito quando vengono rilevati problemi dall’agente di monitoraggio dell’integrità, dai controlli dell’integrità di base e dai controlli dell’integrità approfonditi. Se è impostato `None`, l’agente di monitoraggio dell’integrità etichetta le istanze in cui viene rilevato un guasto, ma non avvia automaticamente alcuna azione di correzione o ripristino sui nodi interessati. Questa opzione non è consigliata.
## Esecuzione di un processo di formazione con la funzionalità di SageMaker HyperPod ripristino automatico di Amazon
Questa sezione descrive come eseguire un processo di formazione con la funzionalità di SageMaker HyperPod ripristino automatico, che fornisce un'infrastruttura di resilienza zero-touch per ripristinare automaticamente un processo di formazione dall'ultimo checkpoint salvato in caso di guasto hardware.
Con la funzionalità di ripristino automatico, se un processo fallisce a causa di un guasto hardware o di problemi transitori tra un training e l'altro, la ripresa SageMaker HyperPod automatica avvia il flusso di lavoro di sostituzione dei nodi e riavvia il lavoro dopo la sostituzione dei nodi difettosi. I seguenti controlli hardware vengono eseguiti ogni volta che un processo fallisce durante l'utilizzo della ripresa automatica:
| Categoria | Nome dell’utilità | Compatibilità del tipo di istanza | Description |
| --- | --- | --- | --- |
| Accelerator | NVIDIA SMI | GPU | [L'utilità nvidia-smi](https://developer.nvidia.com/nvidia-system-management-interface) è una nota CLI per la gestione e il monitoraggio. GPUs Lo strumento integrato di controllo dell’integrità analizza l’output da nvidia-smi per determinare l’integrità dell’istanza. |
| Accelerator | Neuron Sysfs | Trainium | Per le istanze basate su Trainium, l’integrità dei dispositivi Neuron viene determinato dalla lettura dei contatori di [Neuron Sysfs](https://awsdocs-neuron.readthedocs-hosted.com/en/latest/tools/neuron-sys-tools/neuron-sysfs-user-guide.html) propagati direttamente dal driver Neuron. |
| Rete | EFA | GPU e Trainium | Per facilitare la diagnostica dei dispositivi Elastic Fabric Adaptor (EFA), lo strumento di controllo dell’integrità di EFA esegue una serie di test di connettività utilizzando tutte le schede EFA disponibili all’interno dell’istanza. |
**Nota**
Quando le [Generic RESources (GRES)](https://slurm.schedmd.com/gres.html) sono collegate a un nodo Slurm, Slurm in genere non consente modifiche all’allocazione dei nodi, ad esempio la sostituzione dei nodi, e quindi non consente di riprendere un processo non riuscito. A meno che non sia esplicitamente vietato, la funzionalità di ripristino HyperPod automatico rimette automaticamente in coda qualsiasi lavoro difettoso associato ai nodi abilitati per GRES. Questa procedura prevede l’arresto del processo, il suo reinserimento nella coda dei processi e il suo riavvio dall’inizio.
**Utilizzo della funzionalità di SageMaker HyperPod ripristino automatico con Slurm**
Quando si utilizza il SageMaker HyperPod ripristino automatico con Slurm, è necessario eseguire il lavoro all'interno di un'allocazione esclusiva acquisita utilizzando o. `salloc` `sbatch` In ogni caso, devi modificare lo script del punto di ingresso per assicurarti che tutte le fasi della configurazione vengano eseguite in un unico comando `srun` quando riprendi il processo. Utilizzando lo script del punto di ingresso, è importante configurare l’ambiente sul nodo sostituito in modo che sia coerente con l’ambiente in cui era in esecuzione la fase del processo prima che venisse interrotta. La procedura seguente mostra come preparare uno script entrypoint per mantenere l'ambiente coerente ed eseguirlo come un singolo comando. `srun`
**Suggerimento**
Se utilizzi `sbatch`, puoi semplificare lo script batch creando uno script separato per la configurazione dell’ambiente e l’uso di un singolo comando `srun`.
1. Crea uno script utilizzando l’esempio di codice seguente e salvalo come `train_auto_resume.sh`. Questo script implementa le configurazioni dell’ambiente di addestramento presupponendo che non sia stata precedentemente effettuata alcuna configurazione manuale sul nodo sostituito. Questo garantisce che l’ambiente sia indipendente dal nodo in modo che, quando un nodo viene sostituito, lo stesso ambiente venga allocato sul nodo prima di riprendere il processo.
**Nota**
L’esempio di codice seguente mostra come rilevare l’elenco dei nodi Slurm associati al processo. Non utilizzare la variabile di `$SLURM_JOB_NODELIST` ambiente fornita da Slurm, poiché il suo valore potrebbe essere obsoleto dopo la ripresa SageMaker HyperPod automatica del lavoro. L’esempio di codice seguente mostra come definire una nuova variabile `NODE_LIST` per sostituire `SLURM_JOB_NODELIST` e quindi impostare le variabili `MASTER_NODE` e `MASTER_ADDR` al di fuori della variabile `NODE_LIST`.
```
#!/bin/bash
# Filename: train_auto_resume.sh
# Sample containerized script to launch a training job with a single srun which can be auto-resumed.
# Place your training environment setup here.
# Example: Install conda, docker, activate virtual env, etc.
# Get the list of nodes for a given job
NODE_LIST=$(scontrol show jobid=$SLURM_JOBID | \ # Show details of the SLURM job
awk -F= '/NodeList=/{print $2}' | \ # Extract NodeList field
grep -v Exc) # Exclude nodes marked as excluded
# Determine the master node from the node list
MASTER_NODE=$(scontrol show hostname $NODE_LIST | \ # Convert node list to hostnames
head -n 1) # Select the first hostname as master node
# Get the master node address
MASTER_ADDR=$(scontrol show node=$MASTER_NODE | \ # Show node information
awk -F= '/NodeAddr=/{print $2}' | \ # Extract NodeAddr
awk '{print $1}') # Print the first part of NodeAddr
# Torchrun command to launch the training job
torchrun_cmd="torchrun --nnodes=$SLURM_NNODES \
--nproc_per_node=1 \
--node_rank=$SLURM_NODE \
--master-addr=$MASTER_ADDR \
--master_port=1234 \
"
# Execute the torchrun command in the 'pytorch' Conda environment,
# streaming output live
/opt/conda/bin/conda run --live-stream -n pytorch $torchrun_cmd
```
**Suggerimento**
Puoi utilizzare lo script precedente per aggiungere altri comandi per l’installazione di eventuali dipendenze aggiuntive per il processo. Tuttavia, consigliamo di mantenere gli script di installazione delle dipendenze nel [set di script del ciclo di vita](sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-base-config.md) utilizzati durante la creazione del cluster. Se utilizzi un ambiente virtuale ospitato in una directory condivisa, puoi utilizzare questo script anche per attivare l’ambiente virtuale.
1. Avvia il processo con la SageMaker HyperPod ripresa automatica abilitata aggiungendo il flag `--auto-resume=1` per indicare che il `srun` comando deve essere riprovato automaticamente in caso di guasto hardware.
**Nota**
Se è stata impostata un’allocazione di risorse con `sbatch` o `salloc`, puoi eseguire più comandi `srun` all’interno dell’allocazione. In caso di errore, la funzionalità di SageMaker HyperPod ripristino automatico funziona solo nella [fase di lavoro](https://slurm.schedmd.com/job_launch.html#step_allocation) corrente del `srun` comando con il flag. `--auto-resume=1` In altre parole, l’attivazione della ripresa automatica in un comando `srun` non si applica agli altri comandi `srun` avviati all’interno di una sessione di allocazione delle risorse.
Di seguito sono riportati esempi del comando `srun` con `auto-resume` abilitato.
**Utilizzo di sbatch**
Poiché la maggior parte della logica per la configurazione dell’ambiente è già presente in `train_auto_resume.sh`, lo script batch dovrebbe essere semplice e simile al codice di esempio seguente. Supponiamo che il seguente script batch venga salvato come `batch.sh`.
```
#!/bin/bash
#SBATCH --nodes 2
#SBATCH --exclusive
srun --auto-resume=1 train_auto_resume.sh
```
Esegui lo script batch utilizzando il comando seguente.
```
sbatch batch.sh
```
**Utilizzo di salloc**
Inizia acquisendo un’allocazione esclusiva ed esegui il comando `srun` con il flag `--auto-resume` e lo script del punto di ingresso.
```
salloc -N 2 --exclusive
srun --auto-resume=1 train_auto_resume.sh
```
## Come interagiscono il ripristino automatico dei nodi e il ripristino automatico
Quando i sistemi di ripristino automatico dei nodi e di ripristino automatico sono attivi, seguono un approccio coordinato alla gestione dei guasti. Se l'HMA rileva un guasto hardware, il nodo viene contrassegnato per il drenaggio indipendentemente dallo stato a livello di processo. Con il ripristino automatico dei nodi abilitato, i nodi vengono sostituiti automaticamente una volta terminati tutti i processi in esecuzione nei nodi. In questo scenario, per i lavori con ripristino automatico abilitato, se nella fase è presente uno stato di uscita diverso da zero, viene attivata la ripresa automatica (i lavori riprendono una volta sostituiti i nodi). I lavori senza il ripristino automatico verranno semplicemente chiusi e richiederanno un nuovo invio manuale da parte degli amministratori o degli utenti.
**Nota**
Se si utilizza la ripresa automatica, i nodi vengono sempre sostituiti (nessun riavvio) quando vengono rilevati guasti hardware.
# Sostituisci o riavvia manualmente un nodo usando Slurm
Questa sezione spiega quando è necessario riavviare o sostituire manualmente un nodo, con istruzioni su come eseguire entrambe le operazioni.
## Quando riavviare o sostituire manualmente un nodo
La funzionalità di HyperPod ripristino automatico monitora se lo stato dei nodi Slurm diventa o. `fail` `down` Puoi controllare lo stato dei nodi Slurm eseguendo `sinfo`.
Se un nodo rimane bloccato o non risponde e il processo di ripristino automatico non lo ripristina, puoi avviare il ripristino manualmente. La scelta tra il riavvio e la sostituzione di un nodo dipende dalla natura del problema. Prendi in considerazione la possibilità di riavviare il sistema in caso di problemi temporanei o legati al software, come blocchi del sistema, perdite di memoria, problemi relativi ai driver della GPU, aggiornamenti del kernel o blocchi dei processi. Tuttavia, se si verificano problemi persistenti o legati all'hardware come guasti, errori di memoria o di rete GPUs, ripetuti errori nei controlli di integrità o nodi che non rispondono dopo più tentativi di riavvio, la sostituzione dei nodi è la soluzione più appropriata.
## Metodi per riavviare o sostituire manualmente i nodi
SageMaker HyperPod offre due metodi per il ripristino manuale dei nodi. L'approccio preferito consiste nell'utilizzare SageMaker HyperPod Reboot and Replace APIs, che fornisce un processo di ripristino più rapido e trasparente che funziona con tutti gli orchestratori. In alternativa, è possibile utilizzare i comandi Slurm tradizionali come`scontrol update`, sebbene questo metodo legacy richieda l'accesso diretto al nodo controller di Slurm. Entrambi i metodi attivano gli stessi processi di ripristino. SageMaker HyperPod
## Riavvia manualmente un nodo utilizzando l'API di riavvio
È possibile utilizzare il **BatchRebootClusterNodes**per riavviare manualmente un nodo difettoso nel cluster. SageMaker HyperPod
Ecco un esempio di esecuzione dell'operazione di riavvio su due istanze di un cluster utilizzando: AWS Command Line Interface
```
aws sagemaker batch-reboot-cluster-nodes \
--cluster-name arn:aws:sagemaker:ap-northeast-1:123456789:cluster/test-cluster \
--node-ids i-0123456789abcdef0 i-0fedcba9876543210
```
## Sostituisci manualmente un nodo utilizzando l'API di sostituzione
È possibile utilizzare il **BatchReplaceClusterNodes**per sostituire manualmente un nodo difettoso nel SageMaker HyperPod cluster.
Ecco un esempio di esecuzione dell'operazione di sostituzione su due istanze di un cluster utilizzando: AWS Command Line Interface
```
aws sagemaker batch-replace-cluster-nodes \
--cluster-name arn:aws:sagemaker:ap-northeast-1:123456789:cluster/test-cluster \
--node-ids i-0123456789abcdef0 i-0fedcba9876543210
```
## Riavviare manualmente un nodo utilizzando Slurm
Puoi anche usare i comandi scontrol Slurm per attivare il ripristino del nodo. Questi comandi interagiscono direttamente con il piano di controllo Slurm e richiamano gli stessi meccanismi di ripristino sottostanti. SageMaker HyperPod
Nel comando seguente, sostituite con il nome del nodo Slurm (nome host) dell'istanza difettosa che desiderate riavviare.
```
scontrol update node= state=fail reason="Action:Reboot"
```
Questo contrassegna il nodo come FAIL per il motivo specificato. SageMaker HyperPod lo rileva e riavvia l'istanza. Evita di modificare lo stato del nodo o di riavviare il controller Slurm durante l'operazione.
## Sostituisci manualmente un nodo usando Slurm
È possibile utilizzare il comando scontrol update come segue per sostituire un nodo.
Nel comando seguente, sostituisci `` con il nome del nodo Slurm (nome host) dell'istanza difettosa che desideri sostituire.
```
scontrol update node= state=fail reason="Action:Replace"
```
Dopo aver eseguito questo comando, il nodo entrerà `fail` nello stato, attenderà il completamento dei processi attualmente in esecuzione, verrà sostituito con un'istanza integra e verrà ripristinato con lo stesso nome host. Questo processo richiede tempo e dipende dalle istanze disponibili nella zona di disponibilità e dal tempo necessario per eseguire gli script del ciclo di vita. Durante i processi di aggiornamento e sostituzione, evita nuove modifiche manuali allo stato del nodo o il riavvio del controller Slurm, perché queste operazioni potrebbero comportare errori di sostituzione. Se il nodo non viene ripristinato o non torna allo stato `idle` dopo molto tempo, contatta il [Supporto AWS](https://console.aws.amazon.com/support/).
## Forza la modifica manuale di un nodo
Se il nodo difettoso resta sempre bloccato in stato `fail`, l’ultima soluzione che potresti provare è forzare manualmente la modifica dello stato del nodo su `down`. Questa operazione richiede privilegi di amministratore (autorizzazioni sudo).
**avvertimento**
Procedi con cautela prima di utilizzare il comando seguente, perché impone l’interruzione di tutti i processi che potrebbe comportare la perdita di tutto il lavoro non salvato.
```
scontrol update node= state=down reason="Action:Replace"
```
# Provisioning continuo per operazioni avanzate del cluster con Slurm
SageMaker HyperPod I cluster Amazon creati con l'orchestrazione Slurm ora supportano il provisioning continuo, una funzionalità che consente maggiore flessibilità ed efficienza durante l'esecuzione di carichi di lavoro su larga scala. AI/ML Il provisioning continuo consente di iniziare rapidamente l’addestramento, scalare senza problemi, eseguire la manutenzione senza interrompere le operazioni e avere una visibilità granulare sulle operazioni del cluster.
**Nota**
Il provisioning continuo è disponibile come configurazione opzionale per i nuovi cluster creati con l'orchestrazione Slurm. HyperPod Al momento, i cluster esistenti che utilizzano il modello di scalabilità precedente non possono essere migrati al provisioning continuo.
## Come funziona
Il sistema di provisioning continuo introduce un'architettura dello stato desiderato che sostituisce il modello di scalabilità tradizionale. all-or-nothing Nel modello precedente, se non era possibile effettuare il provisioning completo di un gruppo di istanze, l'intera operazione di creazione o aggiornamento del cluster non funzionava e veniva ripristinata. Con il provisioning continuo, il sistema accetta una capacità parziale e continua a fornire le istanze rimanenti in modo asincrono.
Il sistema di provisioning continuo:
+ **Accetta la richiesta**: registra il numero di istanze di destinazione per ogni gruppo di istanze.
+ **Avvia il provisioning**: inizia a lanciare le istanze per tutti i gruppi di istanze in parallelo.
+ Effettua **innanzitutto il provisioning dei nodi prioritari**: il cluster passa a `InService` dopo che almeno un nodo controller (e un nodo di accesso, se viene specificato un gruppo di istanze di login) è stato eseguito correttamente.
+ Monitora l'**avanzamento**: monitora ogni tentativo di avvio dell'istanza e ne registra lo stato.
+ **Gestisce gli errori**: riprova automaticamente gli avvii non riusciti per i nodi di lavoro in modo asincrono.
Il provisioning continuo è disabilitato per impostazione predefinita. Per utilizzare questa funzionalità, impostala nella richiesta. `NodeProvisioningMode` `Continuous` `CreateCluster`
Con il provisioning continuo abilitato, puoi avviare più operazioni di dimensionamento contemporaneamente senza attendere il completamento delle operazioni precedenti. Ciò consente di scalare contemporaneamente diversi gruppi di istanze nello stesso cluster e di inviare più richieste di dimensionamento allo stesso gruppo di istanze.
## Provisioning basato sulla priorità
I cluster Slurm richiedono che un nodo controller sia operativo prima che i nodi di lavoro possano registrare e accettare lavori. Il provisioning continuo gestisce questo problema automaticamente tramite il provisioning basato sulle priorità:
1. Il gruppo di istanze del controller viene fornito per primo.
1. Una volta che un nodo controller è integro, i nodi di accesso e i nodi di lavoro iniziano il provisioning in parallelo.
1. Il cluster passa alla fase in `InService` cui un nodo di controller è attivo e un nodo di accesso è attivo (se viene specificato un gruppo di istanze di login). Se non viene specificato alcun gruppo di istanze di login, la transizione del cluster avviene non `InService` appena viene effettuato il provisioning del nodo di controller.
1. I nodi di lavoro che non possono essere immediatamente forniti a causa di vincoli di capacità entrano in un ciclo di tentativi asincrono e vengono aggiunti automaticamente al cluster Slurm non appena diventano disponibili.
## Gestione degli errori del controller
Durante la creazione del cluster, se il nodo controller non riesce a eseguire il provisioning, il comportamento dipende dal fatto che l'errore sia riprovabile o meno.
**Errori rieseguibili (ad esempio, istanze non integre o errori** temporanei):
+ HyperPod sostituisce continuamente l'istanza e riprova il provisioning fino all'attivazione del controller.
+ I nodi di lavoro e di accesso che sono già stati forniti rimangono disponibili, ma il cluster non effettua la transizione `InService` finché il controller non è integro.
**Errori non ripetibili** (ad esempio, nessuna capacità disponibile per il tipo di istanza del controller o l'errore dello script del ciclo di vita):
+ Il cluster è contrassegnato come. `Failed`
+ Il motivo dell'errore viene notificato all'utente e deve intraprendere azioni correttive, ad esempio scegliere un tipo di istanza diverso, correggere gli script del ciclo di vita o riprovare in un'altra zona di disponibilità.
## Prerequisiti
Il provisioning continuo richiede che i parametri di provisioning di Slurm (tipi di nodi, nomi delle partizioni) siano forniti tramite il payload dell'API nel campo di ciascun gruppo di istanze. `SlurmConfig` I cluster che si basano sul `provisioning_parameters.json` file legacy in Amazon S3 non sono compatibili con il provisioning continuo.
**Nota**
Le seguenti funzionalità non sono attualmente supportate con il provisioning continuo sui cluster Slurm: migrazione di cluster esistenti, configurazione a nodi multipli tramite topologia Slurm basata su API e. `SlurmConfigStrategy` Il provisioning `slurm.conf` continuo funziona esclusivamente in modalità di fusione per la gestione.
## Misurazione dell’utilizzo
HyperPod i cluster con provisioning continuo utilizzano la misurazione a livello di istanza per fornire una fatturazione accurata che rifletta l'utilizzo effettivo delle risorse. Questo approccio di misurazione si differenzia dalla tradizionale fatturazione a livello di cluster in quanto tiene traccia di ogni istanza in modo indipendente.
**Fatturazione a livello di istanza**
Con il provisioning continuo, la fatturazione inizia e si arresta a livello della singola istanza anziché attendere le modifiche dello stato a livello di cluster. Questa funzionalità fornisce i seguenti vantaggi:
+ **Accuratezza di fatturazione**: la fatturazione inizia quando inizia l’esecuzione dello script del ciclo di vita. Se lo script del ciclo di vita fallisce, la fornitura dell'istanza verrà ritentata e all'utente verrà addebitata la durata del runtime dello script del ciclo di vita.
+ **Misurazione indipendente: il** ciclo di vita di fatturazione di ogni istanza viene gestito separatamente, evitando errori di fatturazione a cascata.
+ **Aggiornamenti di fatturazione in tempo reale**: la fatturazione inizia quando un'istanza inizia a eseguire lo script di configurazione del ciclo di vita e si interrompe quando l'istanza entra in uno stato di terminazione.
**Ciclo di vita della fatturazione**
Ogni istanza del HyperPod cluster segue questo ciclo di vita di fatturazione:
+ La **fatturazione ha inizio**: quando l'istanza viene avviata correttamente e inizia a eseguire lo script di configurazione del ciclo di vita.
+ **La fatturazione continua**: per tutta la durata operativa dell'istanza.
+ La **fatturazione si interrompe**: quando l'istanza entra in uno stato di terminazione, indipendentemente dal motivo della chiusura.
**Nota**
La fatturazione non inizia in caso di errori di avvio delle istanze. Se l’avvio di un’istanza non riesce a causa di una capacità insufficiente o di altri problemi, non verrà addebitato alcun costo per il tentativo non riuscito. La fatturazione viene calcolata a livello di istanza e i costi sono aggregati e riportati nel nome della risorsa Amazon (ARN) del cluster.
## Creazione di un cluster con provisioning continuo abilitato
**Nota**
Prepara uno script di configurazione del ciclo di vita e caricalo in un bucket Amazon S3 a cui può accedere il tuo ruolo di esecuzione. Per ulteriori informazioni, consulta [SageMaker HyperPod Operazioni del cluster Slurm](sagemaker-hyperpod-operate-slurm.md).
Prepara un file di richiesta `CreateCluster` API in formato JSON. Imposta `NodeProvisioningMode` `Continuous` e fornisci informazioni sulla topologia Slurm nel campo di ogni gruppo di istanze. `SlurmConfig`
```
// create_cluster.json
{
"ClusterName": "my-training-cluster",
"NodeProvisioningMode": "Continuous",
"Orchestrator": {
"Slurm": {}
},
"InstanceGroups": [
{
"InstanceGroupName": "controller-group",
"InstanceType": "ml.m5.xlarge",
"InstanceCount": 1,
"LifeCycleConfig": {
"SourceS3Uri": "s3://amzn-s3-demo-bucket/lifecycle-scripts/src/",
"OnCreate": "on_create.sh"
},
"ExecutionRole": "arn:aws:iam::111122223333:role/iam-role-for-cluster",
"SlurmConfig": {
"NodeType": "Controller"
}
},
{
"InstanceGroupName": "login-group",
"InstanceType": "ml.m5.xlarge",
"InstanceCount": 1,
"LifeCycleConfig": {
"SourceS3Uri": "s3://amzn-s3-demo-bucket/lifecycle-scripts/src/",
"OnCreate": "on_create.sh"
},
"ExecutionRole": "arn:aws:iam::111122223333:role/iam-role-for-cluster",
"SlurmConfig": {
"NodeType": "Login"
}
},
{
"InstanceGroupName": "worker-gpu-a",
"InstanceType": "ml.p5.48xlarge",
"InstanceCount": 16,
"LifeCycleConfig": {
"SourceS3Uri": "s3://amzn-s3-demo-bucket/lifecycle-scripts/src/",
"OnCreate": "on_create.sh"
},
"ExecutionRole": "arn:aws:iam::111122223333:role/iam-role-for-cluster",
"SlurmConfig": {
"NodeType": "Compute",
"PartitionNames": ["gpu-training"]
}
}
],
"VpcConfig": {
"SecurityGroupIds": ["sg-12345678"],
"Subnets": ["subnet-12345678"]
}
}
```
Esegui il `create-cluster` comando per inviare la richiesta.
```
aws sagemaker create-cluster \
--cli-input-json file://complete/path/to/create_cluster.json
```
Questo restituisce l'ARN del nuovo cluster.
```
{
"ClusterArn": "arn:aws:sagemaker:us-west-2:111122223333:cluster/abcde12345"
}
```
## Gestione della configurazione Slurm
Il provisioning continuo funziona esclusivamente in modalità di fusione per la gestione delle partizioni. `slurm.conf` In modalità merge, HyperPod applica le modifiche alla configurazione delle partizioni in modo additivo alle modifiche apportate. `slurm.conf` HyperPod aggiorna solo le sezioni relative alla partizione di `slurm.conf` (come le voci relative al nome della partizione e al nome del nodo); gli altri parametri di configurazione di Slurm non vengono modificati. Ciò significa che:
+ Le modifiche manuali di vengono mantenute. `slurm.conf`
+ Non è previsto il rilevamento automatico delle deviazioni o la risoluzione dei conflitti tra le modifiche apportate e HyperPod lo stato previsto.
Il `SlurmConfigStrategy` parametro (`Managed`,`Merge`,`Overwrite`) non è supportato con il provisioning continuo. Il passaggio di qualsiasi `SlurmConfigStrategy` valore genera un errore API.
# SageMaker HyperPod gestione dei cluster
Negli argomenti seguenti vengono illustrate la registrazione e la gestione dei cluster. SageMaker HyperPod
## Registrazione degli eventi SageMaker HyperPod
Tutti gli eventi e i log di SageMaker HyperPod vengono salvati su Amazon CloudWatch con il nome `/aws/sagemaker/Clusters/[ClusterName]/[ClusterID]` del gruppo di log. Ogni chiamata all’API `CreateCluster` crea un nuovo gruppo di log. L’elenco seguente contiene tutti i flussi di log disponibili raccolti in ogni gruppo di log.
| | |
| --- |--- |
| Nome del gruppo di log | Nome del flusso di log |
| /aws/sagemaker/Clusters/[ClusterName]/[ClusterID] | LifecycleConfig/[instance-group-name]/[instance-id] |
## Registrazione a SageMaker HyperPod livello di istanza
È possibile accedere ai LifecycleScript log pubblicati CloudWatch durante la configurazione dell'istanza del cluster. Ogni istanza all’interno del cluster creato genera un flusso di log separato, distinguibile in base al formato `LifecycleConfig/[instance-group-name]/[instance-id]`.
Tutti i log in cui vengono scritti `/var/log/provision/provisioning.log` vengono caricati nel flusso precedente CloudWatch . Sample LifecycleScripts at [https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config](https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config)reindirizza il loro terreno `stderr` verso `stdout` questa posizione. Se utilizzi script personalizzati, scrivi i log nella `/var/log/provision/provisioning.log` posizione in cui saranno disponibili. CloudWatch
**Marcatori di log degli script del ciclo di vita**
CloudWatch i log per gli script del ciclo di vita includono marcatori specifici che consentono di tenere traccia dell'avanzamento dell'esecuzione e identificare i problemi:
| | |
| --- |--- |
| Marker | Descrizione |
| START | Indicates the beginning of lifecycle script logs for the instance |
| [SageMaker] Lifecycle scripts were provided, with S3 uri: [s3://bucket-name/] and entrypoint script: [script-name.sh] | Indicates the S3 location and entrypoint script that will be used |
| [SageMaker] Downloading lifecycle scripts | Indicates scripts are being downloaded from the specified S3 location |
| [SageMaker] Lifecycle scripts have been downloaded | Indicates scripts have been successfully downloaded from S3 |
| [SageMaker] The lifecycle scripts succeeded | Indicates successful completion of all lifecycle scripts |
| [SageMaker] The lifecycle scripts failed | Indicates failed execution of lifecycle scripts |
Questi marcatori consentono di identificare rapidamente in quale fase del processo di esecuzione degli script del ciclo di vita si è verificato un problema. Durante la risoluzione dei problemi, esaminate le voci di registro per identificare dove il processo si è interrotto o non è riuscito.
**Messaggi di errore dello script del ciclo di vita**
Se lo script del ciclo di vita esiste ma fallisce durante l'esecuzione, riceverai un messaggio di errore che include il nome del gruppo di log e il nome del flusso di CloudWatch log. Nel caso in cui si verifichino errori dello script del ciclo di vita su più istanze, il messaggio di errore indicherà solo un'istanza fallita, ma il gruppo di log deve contenere flussi per tutte le istanze.
È possibile visualizzare il messaggio di errore eseguendo l'[DescribeCluster](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_DescribeCluster.html)API o visualizzando la pagina dei dettagli del cluster nella console. SageMaker Nella console, è disponibile il pulsante **Visualizza i registri degli script del ciclo** di vita che accede direttamente al flusso di log. CloudWatch Il messaggio di errore ha il seguente formato:
```
Instance [instance-id] failed to provision with the following error: "Lifecycle scripts did not run successfully. To view lifecycle script logs,
visit log group ‘/aws/sagemaker/Clusters/[cluster-name]/[cluster-id]' and log stream ‘LifecycleConfig/[instance-group-name]/[instance-id]’.
If you cannot find corresponding lifecycle script logs in CloudWatch, please make sure you follow one of the options here:
https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-faq-slurm.html#hyperpod-faqs-q1.” Note that multiple instances may be impacted.
```
## Applicazione di tag alle risorse
AWS Il sistema di etichettatura aiuta a gestire, identificare, organizzare, cercare e filtrare le risorse. SageMaker HyperPod supporta l'etichettatura, in modo da poter gestire i cluster come risorsa. AWS Durante la creazione o la modifica di un cluster esistente, puoi aggiungere o modificare i tag per il cluster. Per ulteriori informazioni generali sul tagging, consulta [Tagging delle risorse AWS](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html).
### Utilizzo dell'interfaccia utente della console SageMaker HyperPod
Quando [crei un nuovo cluster](sagemaker-hyperpod-operate-slurm-console-ui.md#sagemaker-hyperpod-operate-slurm-console-ui-create-cluster) o [modifichi un cluster](sagemaker-hyperpod-operate-slurm-console-ui.md#sagemaker-hyperpod-operate-slurm-console-ui-edit-clusters), puoi aggiungere, modificare o rimuovere tag.
### Usando il SageMaker HyperPod APIs
Quando scrivi un file di richiesta [CreateCluster](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_CreateCluster.html)o [UpdateCluster](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_UpdateCluster.html)API in formato JSON, modifica la `Tags` sezione.
### Utilizzo dei comandi di AWS CLI tagging per l'IA SageMaker
**Per taggare un cluster**
Utilizza [https://docs.aws.amazon.com/cli/latest/reference/sagemaker/add-tags.html](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/add-tags.html) come segue.
```
aws sagemaker add-tags --resource-arn cluster_ARN --tags Key=string,Value=string
```
**Per rimuovere un tag da un cluster**
Utilizza [https://docs.aws.amazon.com/cli/latest/reference/sagemaker/delete-tags.html](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/delete-tags.html) come segue.
```
aws sagemaker delete-tags --resource-arn cluster_ARN --tag-keys "tag_key"
```
**Per elencare i tag per una risorsa**
Utilizza [https://docs.aws.amazon.com/cli/latest/reference/sagemaker/list-tags.html](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/list-tags.html) come segue.
```
aws sagemaker list-tags --resource-arn cluster_ARN
```
# SageMaker HyperPod FAQs
Utilizza le seguenti domande frequenti per risolvere i problemi relativi all'utilizzo. SageMaker HyperPod
**Topics**
+ [Perché non riesco a trovare i gruppi di log del mio SageMaker HyperPod cluster in Amazon CloudWatch?](#hyperpod-faqs-q1)
+ [Quali configurazioni particolari HyperPod gestisce nei file di configurazione di Slurm come e? `slurm.conf` `gres.conf`](#hyperpod-faqs-q2)
+ [Come posso eseguire Docker sui nodi Slurm? HyperPod](#hyperpod-faqs-q3)
+ [Perché il mio lavoro di training parallelo fallisce quando utilizzo NVIDIA Collective Communications Library (NCCL) con Slurm on platform? SageMaker HyperPod](#hyperpod-faqs-q4)
+ [Come posso utilizzare l' NVMe archivio locale di istanze P per avviare contenitori Docker o Enroot con Slurm?](#hyperpod-faqs-q5)
+ [Come si configurano i gruppi di sicurezza EFA?](#hyperpod-faqs-q6)
+ [Come posso monitorare i nodi del mio cluster? HyperPod Sono state esportate CloudWatch delle metriche da? HyperPod](#hyperpod-faqs-q7)
+ [Posso aggiungere uno storage aggiuntivo ai HyperPod nodi del cluster? Le istanze del cluster hanno un archivio dell’istanza locale limitato.](#hyperpod-faqs-q8)
+ [Perché i miei nodi di calcolo mostrano lo stato “DOWN” o “DRAINED” dopo un riavvio?](#hyperpod-faqs-q9)
+ [Perché i miei nodi vengono continuamente svuotati a causa di problemi di memoria insufficiente (OOM)?](#hyperpod-faqs-q10)
+ [Come posso avere la certezza che le risorse siano pulite correttamente dopo il completamento dei processi?](#hyperpod-faqs-q11)
## Perché non riesco a trovare i gruppi di log del mio SageMaker HyperPod cluster in Amazon CloudWatch?
Per impostazione predefinita, i log degli agenti e i registri di avvio delle istanze vengono inviati all'account della HyperPod piattaforma. CloudWatch Nel caso degli script del ciclo di vita degli utenti, i log di configurazione del ciclo di vita vengono inviati all'account dell'utente. CloudWatch
Se utilizzi gli [script del ciclo di vita di esempio](sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-base-config.md) forniti dal team di HyperPod assistenza, puoi aspettarti di trovare i log di configurazione del ciclo di vita scritti su e non incontrerai questo problema. `/var/log/provision/provisioning.log`
Tuttavia, se utilizzi percorsi personalizzati per raccogliere i log dal provisioning del ciclo di vita e non riesci a trovare i gruppi di log che appaiono nel tuo account CloudWatch, ciò potrebbe essere dovuto a una mancata corrispondenza tra i percorsi dei file di registro specificati negli script del ciclo di vita e ciò che cerca l' CloudWatch agente in esecuzione sulle istanze del HyperPod cluster. In questo caso, significa che è necessario configurare correttamente gli script del ciclo di vita per inviare i log all' CloudWatch agente e configurare di conseguenza la configurazione dell' CloudWatch agente. Per risolvere il problema, scegli una delle seguenti opzioni.
+ **Opzione 1:** aggiorna gli script del ciclo di vita per scrivere i log su `/var/log/provision/provisioning.log`.
+ **Opzione 2:** aggiorna l' CloudWatch agente per cercare percorsi personalizzati per la registrazione del provisioning del ciclo di vita.
1. Ogni istanza HyperPod del cluster contiene un file di configurazione CloudWatch dell'agente in formato JSON all'indirizzo. `/opt/aws/amazon-cloudwatch-agent/sagemaker_cwagent_config.json` Nel file di configurazione, trova il nome del campo `logs.logs_collected.files.collect_list.file_path`. Con l'impostazione predefinita di HyperPod, la coppia chiave-valore dovrebbe essere `"file_path": "/var/log/provision/provisioning.log"` quella documentata in. [Registrazione a SageMaker HyperPod livello di istanza](sagemaker-hyperpod-cluster-management-slurm.md#sagemaker-hyperpod-cluster-management-slurm-logging-at-instance-level) Il seguente frammento di codice mostra l'aspetto del file JSON con la configurazione predefinita. HyperPod
```
"logs": {
"logs_collected": {
"files": {
"collect_list": [
{
"file_path": "/var/log/provision/provisioning.log",
"log_group_name": "/aws/sagemaker/Clusters/[ClusterName]/[ClusterID]",
"log_stream_name": "LifecycleConfig/[InstanceGroupName]/{instance_id}",
"retention_in_days": -1
}
]
}
},
"force_flush_interval": 3
}
```
1. Sostituisci il valore del nome del campo `"file_path"` con il percorso personalizzato che utilizzi negli script del ciclo di vita. Ad esempio, se hai configurato gli script del ciclo di vita per la scrittura su `/var/log/custom-provision/custom-provisioning.log`, aggiorna il valore in modo che abbia la seguente corrispondenza.
```
"file_path": "/var/log/custom-provision/custom-provisioning.log"
```
1. Riavviare l' CloudWatch agente con il file di configurazione per completare l'applicazione del percorso personalizzato. Ad esempio, il CloudWatch comando seguente mostra come riavviare l' CloudWatch agente con il file di configurazione dell' CloudWatch agente del passaggio 1. Per ulteriori informazioni, vedere anche [Risoluzione dei problemi dell' CloudWatch agente](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/troubleshooting-CloudWatch-Agent.html).
```
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl \
-a fetch-config -m ec2 -s -c \
file:/opt/aws/amazon-cloudwatch-agent/sagemaker_cwagent_config.json
```
## Quali configurazioni particolari HyperPod gestisce nei file di configurazione di Slurm come e? `slurm.conf` `gres.conf`
Quando si crea un cluster Slurm su HyperPod, l' HyperPod agente configura [https://slurm.schedmd.com/gres.conf.html](https://slurm.schedmd.com/gres.conf.html)i file [https://slurm.schedmd.com/slurm.conf.html](https://slurm.schedmd.com/slurm.conf.html)and `/opt/slurm/etc/` per gestire il cluster Slurm in base alla richiesta di creazione del cluster e agli script del ciclo di vita HyperPod . L'elenco seguente mostra quali parametri specifici l'agente gestisce e sovrascrive. HyperPod
**Importante**
Ti consigliamo vivamente di NON modificare questi parametri gestiti da HyperPod.
+ In [https://slurm.schedmd.com/slurm.conf.html](https://slurm.schedmd.com/slurm.conf.html), HyperPod imposta i seguenti parametri di base: `ClusterName``SlurmctldHost`,`PartitionName`, e`NodeName`.
Inoltre, per abilitare la [Ripristino automatico dei nodi e ripristino automatico](sagemaker-hyperpod-resiliency-slurm-auto-resume.md) funzionalità, HyperPod richiede i `SchedulerParameters` parametri `TaskPlugin` e impostati come segue. Per impostazione predefinita, l' HyperPod agente imposta questi due parametri con i valori richiesti.
```
TaskPlugin=task/none
SchedulerParameters=permit_job_expansion
```
+ In [https://slurm.schedmd.com/gres.conf.html](https://slurm.schedmd.com/gres.conf.html), HyperPod gestisce `NodeName` i nodi GPU.
## Come posso eseguire Docker sui nodi Slurm? HyperPod
Per aiutarti a eseguire Docker sui nodi Slurm in esecuzione HyperPod, il team di HyperPod assistenza fornisce script di configurazione che puoi includere come parte della configurazione del ciclo di vita per la creazione di cluster. Per ulteriori informazioni, consultare [Script del ciclo di vita di base forniti da HyperPod](sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-base-config.md) e [Esecuzione di contenitori Docker su un nodo di calcolo Slurm su HyperPod](sagemaker-hyperpod-run-jobs-slurm-docker.md).
## Perché il mio lavoro di training parallelo fallisce quando utilizzo NVIDIA Collective Communications Library (NCCL) con Slurm on platform? SageMaker HyperPod
Per impostazione predefinita, il sistema operativo Linux imposta il flag `#RemoveIPC=yes`. I processi Slurm e mpirun che utilizzano NCCL generano risorse di comunicazione tra processi (IPC) nelle sessioni utente non root. Queste sessioni utente potrebbero disconnettersi durante il processo.
Quando esegui processi con Slurm o mpirun, se `systemd` rileva che l’utente non è connesso, pulisce le risorse IPC. I processi Slurm e mpirun possono essere eseguiti senza che l’utente sia connesso, ma è necessario disabilitare la pulizia a livello di systemd e riconfigurarla a livello Slurm. Per ulteriori informazioni, consulta [Systemd nella documentazione NCCL](https://docs.nvidia.com/deeplearning/nccl/user-guide/docs/troubleshooting.html#systemd).
Completa la procedura seguente per disabilitare la pulizia a livello di systemd.
1. Imposta il flag `#RemoveIPC=no` nel file `/etc/systemd/logind.conf` se stai eseguendo job di addestramento che utilizzano Slurm e NCCL.
1. Per impostazione predefinita, Slurm non pulisce le risorse condivise. Consigliamo di configurare uno script Epilog di Slurm per pulire le risorse condivise. Questa pulizia è utile se hai molte risorse condivise che vuoi eliminare dopo i job di addestramento. Di seguito è riportato un esempio di script.
```
#!/bin/bash
: <<'SUMMARY'
Script: epilog.sh
Use this script with caution, as it can potentially delete unnecessary resources and cause issues if you don't use it correctly.
Note: You must save this script in a shared in a shared location that is accessible to all nodes in the cluster, such as /fsx volume.
Workers must be able to access the script to run the script after jobs.
SUMMARY
# Define the log directory and create it if it doesn't exist
LOG_DIR="//epilogue" #NOTE: Update PLACEHOLDER to be a shared value path, such as /fsx/epilogue.
mkdir -p "$LOG_DIR"
# Name the log file using the Slurm job name and job ID
log_file="$LOG_DIR/epilogue-${SLURM_JOB_NAME}_${SLURM_JOB_ID}.log"
logging() {
echo "[$(date)] $1" | tee -a "$log_file"
}
# Slurm epilogue script to clean up IPC resources
logging "Starting IPC cleanup for Job $SLURM_JOB_ID"
# Clean up shared memory segments by username
for seg in $(ipcs -m | awk -v owner="$SLURM_JOB_USER" '$3 == owner {print $2}'); do
if ipcrm -m "$seg"; then
logging "Removed shared memory segment $seg"
else
logging "Failed to remove shared memory segment $seg"
fi
done
# Clean up semaphores by username
for sem in $(ipcs -s | awk -v user="$SLURM_JOB_USER" '$3 == user {print $2}'); do
if ipcrm -s "$sem"; then
logging "Removed semaphore $sem"
else
logging "Failed to remove semaphore $sem"
fi
done
# Clean up NCCL IPC
NCCL_IPC_PATH="/dev/shm/nccl-*"
for file in $NCCL_IPC_PATH; do
if [ -e "$file" ]; then
if rm "$file"; then
logging "Removed NCCL IPC file $file"
else
logging "Failed to remove NCCL IPC file $file"
fi
fi
done
logging "IPC cleanup completed for Job $SLURM_JOB_ID"
exit 0
```
Per ulteriori informazioni sul parametro Epilog, consulta la [documentazione di Slurm](https://slurm.schedmd.com/slurm.conf.html#OPT_Epilog).
1. Nel file `slurm.conf` del nodo controller, aggiungi una riga che punti allo script Epilog che hai creato.
```
Epilog="/path/to/epilog.sh" #For example: /fsx/epilogue/epilog.sh
```
1. Utilizza i comandi seguenti per modificare le autorizzazioni dello script e renderlo eseguibile.
```
chown slurm:slurm /path/to/epilog.sh
chmod +x /path/to/epilog.sh
```
1. Per applicare tutte le modifiche, esegui `scontrol reconfigure`.
## Come posso utilizzare l' NVMe archivio locale di istanze P per avviare contenitori Docker o Enroot con Slurm?
Poiché il volume root predefinito del nodo principale di solito è limitato a un volume EBS da 100 GB, è necessario configurare Docker ed Enroot per utilizzare l'instance store locale. NVMe Per informazioni su come configurare NVMe store e utilizzarlo per l'avvio di contenitori Docker, consulta. [Esecuzione di contenitori Docker su un nodo di calcolo Slurm su HyperPod](sagemaker-hyperpod-run-jobs-slurm-docker.md)
## Come si configurano i gruppi di sicurezza EFA?
Se desideri creare un HyperPod cluster con istanze abilitate per EFA, assicurati di configurare un gruppo di sicurezza per consentire tutto il traffico in entrata e in uscita da e verso il gruppo di sicurezza stesso. Per ulteriori informazioni, consulta [Step 1: Prepare an EFA-enabled security group](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa-start.html#efa-start-security) in *Amazon EC2 User Guide*.
## Come posso monitorare i nodi del mio cluster? HyperPod Sono state esportate CloudWatch delle metriche da? HyperPod
Per ottenere una maggiore visibilità sull'utilizzo delle risorse del HyperPod cluster, consigliamo di integrare il HyperPod cluster con Amazon Managed Grafana e Amazon Managed Service for Prometheus. Con varie dashboard Grafana open source e pacchetti di esportazione, puoi esportare e visualizzare le metriche relative alle risorse del cluster. HyperPod Per ulteriori informazioni sulla configurazione SageMaker HyperPod con Amazon Managed Grafana e Amazon Managed Service for Prometheus, consulta. [SageMaker HyperPod monitoraggio delle risorse del cluster](sagemaker-hyperpod-cluster-observability-slurm.md) Tieni presente che SageMaker HyperPod attualmente non supporta l'esportazione di metriche di sistema su Amazon. CloudWatch
## Posso aggiungere uno storage aggiuntivo ai HyperPod nodi del cluster? Le istanze del cluster hanno un archivio dell’istanza locale limitato.
Se l’archiviazione delle istanze predefinita è insufficiente per il tuo carico di lavoro, puoi configurare spazio aggiuntivo per ogni istanza. A partire dal [rilascio del 20 giugno 2024,](sagemaker-hyperpod-release-notes.md#sagemaker-hyperpod-release-notes-20240620) puoi aggiungere un volume Amazon Elastic Block Store (EBS) aggiuntivo a ciascuna istanza del cluster. SageMaker HyperPod Tieni presente che questa funzionalità non può essere applicata a gruppi di istanze di SageMaker HyperPod cluster esistenti creati prima del 20 giugno 2024. Puoi utilizzare questa funzionalità applicando patch SageMaker HyperPod ai cluster esistenti creati prima del 20 giugno 2024 e aggiungendovi nuovi gruppi di istanze. Questa funzionalità è pienamente efficace per tutti i SageMaker HyperPod cluster creati dopo il 20 giugno 2024.
## Perché i miei nodi di calcolo mostrano lo stato “DOWN” o “DRAINED” dopo un riavvio?
Questo caso si verifica in genere quando i nodi vengono riavviati con `sudo reboot` invece che con l’interfaccia di controllo di Slurm. Per riavviare correttamente i nodi, utilizza il comando Slurm `scontrol reboot nextstate=resume `. Questo garantisce che Slurm mantenga un controllo adeguato sullo stato del nodo e riprenda il normale funzionamento dopo il riavvio.
Per le istanze GPU (come NVIDIA P5), questo può accadere anche se il nodo non riesce a completare il processo di avvio entro il limite di tempo predefinito di Slurm (60 secondi). Per risolvere questo problema, aumenta il parametro `TimeToResume` in `slurm.conf` fino a 300 secondi. In questo modo, le istanze GPU hanno abbastanza tempo per avviare e inizializzare i driver.
## Perché i miei nodi vengono continuamente svuotati a causa di problemi di memoria insufficiente (OOM)?
I problemi di OOM si verificano quando i processi superano la capacità di memoria del nodo. Per evitare il problema, implementa `cgroups` per imporre limiti di memoria per ogni processo. Così facendo, eviti che un singolo processo influisca sull’intero nodo e migliori l’isolamento e la stabilità.
Configurazione di esempio in `slurm.conf`:
```
TaskPlugin=task/cgroup
```
Configurazione di esempio in `cgroup.conf`:
```
CgroupAutomount=yes
ConstrainCores=yes
CgroupPlugin=autodetect
ConstrainDevices=yes
ConstrainRAMSpace=yes
ConstrainSwapSpace=yes
SignalChildrenProcesses=yes
MaxRAMPercent=99
MaxSwapPercent=80
MinRAMSpace=100
```
Per ulteriori informazioni, consulta [Control Group in Slurm](https://slurm.schedmd.com/cgroups.html), [Cgroup and PAM-based login control for Slurm compute nodes](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/utils/pam_adopt_cgroup_wheel.sh#L197) e [Configure Cgroups for Slurm](https://catalog.workshops.aws/sagemaker-hyperpod/en-US/07-tips-and-tricks/16-enable-cgroups).
## Come posso avere la certezza che le risorse siano pulite correttamente dopo il completamento dei processi?
Implementa script Epilog per pulire automaticamente le risorse al completamento dei processi. Le risorse potrebbero non essere cancellate correttamente quando i processi si bloccano inaspettatamente, quando contengono bug che impediscono la normale pulizia o quando i buffer di memoria condivisa (inclusi quelli condivisi tra processi e driver GPU) rimangono allocati.
Gli script Epilog possono eseguire attività, ad esempio la cancellazione della memoria della GPU, la rimozione dei file temporanei e lo smontaggio dei file system. Questi script presentano delle limitazioni quando le risorse non sono allocate esclusivamente a un singolo processo. Per istruzioni dettagliate e script di esempio, consulta il secondo punto della domanda [Perché il mio lavoro di training parallelo fallisce quando utilizzo NVIDIA Collective Communications Library (NCCL) con Slurm on platform? SageMaker HyperPod](#hyperpod-faqs-q4). Per ulteriori informazioni, consulta [Enable Slurm epilog script](https://catalog.workshops.aws/sagemaker-hyperpod/en-US/07-tips-and-tricks/18-slurm-epilogue).
# Orchestrazione di SageMaker HyperPod cluster con Amazon EKS
SageMaker HyperPod è un servizio SageMaker gestito dall'intelligenza artificiale che consente l'addestramento su larga scala di modelli di base su cluster di elaborazione resilienti e di lunga durata, che si integra con Amazon EKS per orchestrare le risorse di calcolo. HyperPod Puoi eseguire lavori di formazione ininterrotti per settimane o mesi su larga scala utilizzando i cluster Amazon EKS con funzionalità di HyperPod resilienza che verificano la presenza di vari guasti hardware e ripristinano automaticamente i nodi difettosi.
Le funzionalità principali per gli utenti amministratori del cluster includono quanto segue.
+ Fornire cluster resilienti e collegarli a un piano di controllo HyperPod EKS
+ Abilitazione della gestione dinamica della capacità, come l’aggiunta di altri nodi, l’aggiornamento del software e l’eliminazione dei cluster
+ Abilitazione dell’accesso alle istanze del cluster direttamente tramite `kubectl` o SSM/SSH
+ Offre [funzionalità di resilienza](sagemaker-hyperpod-eks-resiliency.md), tra cui controlli sanitari di base, controlli sanitari approfonditi, un agente di monitoraggio dello stato di salute e supporto per la ripresa automatica del lavoro PyTorch
+ [Integrazione con strumenti di osservabilità come Amazon [ CloudWatchContainer Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContainerInsights.html), [Amazon Managed Service for Prometheus e Amazon Managed Grafana](https://docs.aws.amazon.com/prometheus/latest/userguide/what-is-Amazon-Managed-Service-Prometheus.html)](https://docs.aws.amazon.com/grafana/latest/userguide/what-is-Amazon-Managed-Service-Grafana.html)
Per gli utenti di data scientist, il supporto EKS abilita quanto segue. HyperPod
+ Esecuzione di carichi di lavoro containerizzati per la formazione dei modelli di base sul cluster HyperPod
+ Esecuzione dell'inferenza sul cluster EKS, sfruttando l'integrazione tra ed EKS HyperPod
+ Sfruttamento della funzionalità di ripresa automatica del lavoro per la formazione [ PyTorch Kubeflow](https://www.kubeflow.org/docs/components/training/user-guides/pytorch/) () PyTorchJob
**Nota**
Amazon EKS consente l'orchestrazione gestita dall'utente di attività e infrastrutture tramite Amazon EKS SageMaker HyperPod Control Plane. Assicurati che l'accesso degli utenti al cluster tramite l'endpoint Kubernetes API Server segua il principio del privilegio minimo e che l'uscita di rete dal cluster sia protetta. HyperPod
Per ulteriori informazioni sulla protezione dell’accesso al server API Amazon EKS, consulta [Control network access to cluster API server endpoint](https://docs.aws.amazon.com/eks/latest/userguide/cluster-endpoint.html).
Per ulteriori informazioni sulla protezione dell'accesso alla rete su, consulta. HyperPod [Configurazione SageMaker HyperPod con un Amazon VPC personalizzato](sagemaker-hyperpod-prerequisites.md#sagemaker-hyperpod-prerequisites-optional-vpc)
L'architettura di alto livello del supporto di Amazon EKS HyperPod prevede una mappatura 1 a 1 tra un cluster EKS (piano di controllo) e un HyperPod cluster (nodi di lavoro) all'interno di un VPC, come mostrato nel diagramma seguente.
![\[EKS and HyperPod VPC architecture with control plane, cluster nodes, and Servizi AWS.\]](http://docs.aws.amazon.com/it_it/sagemaker/latest/dg/images/hyperpod-eks-diagram.png)
# Gestione dei SageMaker HyperPod cluster orchestrati da Amazon EKS
Questa sezione fornisce indicazioni sulla gestione SageMaker HyperPod tramite l'interfaccia utente della console SageMaker AI o AWS Command Line Interface (CLI). Spiega come eseguire varie attività correlate a SageMaker HyperPod, sia che preferiate un'interfaccia visiva o l'utilizzo dei comandi.
**Topics**
+ [Inizia a usare il supporto di Amazon EKS in SageMaker HyperPod](sagemaker-hyperpod-eks-prerequisites.md)
+ [Installazione di pacchetti sul cluster Amazon EKS con Helm](sagemaker-hyperpod-eks-install-packages-using-helm-chart.md)
+ [Configurazione del controllo degli accessi basato su ruoli Kubernetes](sagemaker-hyperpod-eks-setup-rbac.md)
+ [Amazon Machine Images personalizzate (AMIs) per SageMaker HyperPod cluster](hyperpod-custom-ami-support.md)
+ [Gestione dei cluster SageMaker HyperPod EKS tramite la console SageMaker](sagemaker-hyperpod-eks-operate-console-ui.md)
+ [Creazione di SageMaker HyperPod cluster utilizzando modelli CloudFormation](smcluster-getting-started-eks-console-create-cluster-cfn.md)
+ [Gestione dei cluster SageMaker HyperPod EKS utilizzando il AWS CLI](sagemaker-hyperpod-eks-operate-cli-command.md)
+ [HyperPod checkpoint gestito a più livelli](managed-tier-checkpointing.md)
+ [SageMaker HyperPod governance delle attività](sagemaker-hyperpod-eks-operate-console-ui-governance.md)
+ [Report sull'utilizzo per l'attribuzione dei costi in SageMaker HyperPod](sagemaker-hyperpod-usage-reporting.md)
+ [Configurazione dello storage per i SageMaker HyperPod cluster orchestrati da Amazon EKS](sagemaker-hyperpod-eks-setup-storage.md)
+ [Utilizzo del driver CSI Amazon EBS su SageMaker HyperPod cluster EKS](sagemaker-hyperpod-eks-ebs.md)
+ [Configurazione di etichette e colori Kubernetes personalizzati in Amazon SageMaker HyperPod](sagemaker-hyperpod-eks-custom-labels-and-taints.md)
# Inizia a usare il supporto di Amazon EKS in SageMaker HyperPod
Oltre al modulo generale [Prerequisiti per l'utilizzo SageMaker HyperPod](sagemaker-hyperpod-prerequisites.md) SageMaker HyperPod, consulta i seguenti requisiti e considerazioni per l'orchestrazione SageMaker HyperPod dei cluster con Amazon EKS.
**Importante**
Puoi configurare la configurazione delle risorse per la creazione di SageMaker HyperPod cluster utilizzando and. Console di gestione AWS CloudFormation Per ulteriori informazioni, consultare [Creazione di un SageMaker HyperPod cluster con l'orchestrazione di Amazon EKS](sagemaker-hyperpod-eks-operate-console-ui-create-cluster.md) e [Creazione di SageMaker HyperPod cluster utilizzando modelli CloudFormation](smcluster-getting-started-eks-console-create-cluster-cfn.md).
**Requisiti**
**Nota**
Prima di creare un HyperPod cluster, è necessario un cluster Amazon EKS in esecuzione configurato con VPC e installato tramite Helm.
+ Se utilizzi la console SageMaker AI, puoi creare un cluster Amazon EKS all'interno della pagina della console del HyperPod cluster. Per ulteriori informazioni, consulta [Creazione di un SageMaker HyperPod cluster con l'orchestrazione di Amazon EKS](sagemaker-hyperpod-eks-operate-console-ui-create-cluster.md).
+ Se si utilizza la AWS CLI, è necessario creare un cluster Amazon EKS prima di creare un HyperPod cluster a cui associarsi. Per ulteriori informazioni, consulta [Create an Amazon EKS cluster](https://docs.aws.amazon.com/eks/latest/userguide/create-cluster.html) in Amazon EKS User Guide.
Durante il provisioning del cluster Amazon EKS, considera quanto segue:
1. **Versioni di Kubernetes supportate**
+ SageMaker HyperPod supporta le versioni 1.28, 1.29, 1.30, 1.31, 1.32, 1.33 e 1.34 di Kubernetes.
1. **Modalità di autenticazione del cluster Amazon EKS**
+ La modalità di autenticazione di un cluster Amazon EKS supportata da SageMaker HyperPod sono `API` e`API_AND_CONFIG_MAP`.
1. **Reti**
+ SageMaker HyperPod richiede il plug-in Amazon VPC Container Network Interface (CNI) versione 1.18.3 o successiva.
**Nota**
AWS Il [plug-in VPC CNI per Kubernetes](https://github.com/aws/amazon-vpc-cni-k8s) è l'unico CNI supportato da. SageMaker HyperPod
+ Il [tipo di sottorete](https://docs.aws.amazon.com/vpc/latest/userguide/configure-subnets.html#subnet-types) nel VPC deve essere privato HyperPod per i cluster.
1. **Ruoli IAM**
+ Assicurati che i ruoli IAM necessari per HyperPod siano configurati come indicato nella sezione. [AWS Identity and Access Management per SageMaker HyperPod](sagemaker-hyperpod-prerequisites-iam.md)
1. **Componenti aggiuntivi del cluster Amazon EKS**
+ Puoi continuare a utilizzare i vari componenti aggiuntivi forniti da Amazon EKS come [Kube-proxy](https://docs.aws.amazon.com/eks/latest/userguide/add-ons-kube-proxy.html), [CoredNS](https://docs.aws.amazon.com/eks/latest/userguide/add-ons-coredns.html), il plug-in [Amazon VPC Container Network Interface (CNI), l'identità GuardDuty del pod Amazon](https://docs.aws.amazon.com/eks/latest/userguide/add-ons-vpc-cni.html) EKS, l'agente, il driver Amazon Container Storage Interface (CSI), FSx il driver CSI Mountpoint per Amazon S3, l'agente Distro for e l'agente Observability. AWS OpenTelemetry CloudWatch
**Considerazioni sulla configurazione dei SageMaker HyperPod cluster con Amazon EKS**
+ Devi utilizzare ruoli IAM distinti a seconda del tipo di nodi. Per HyperPod i nodi, usa un ruolo basato su. [Ruolo IAM per SageMaker HyperPod](sagemaker-hyperpod-prerequisites-iam.md#sagemaker-hyperpod-prerequisites-iam-role-for-hyperpod) Per i nodi Amazon EKS, consulta il [ruolo IAM del nodo Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/create-node-role.html).
+ Puoi effettuare il provisioning e montare volumi Amazon EBS aggiuntivi sui SageMaker HyperPod nodi utilizzando due approcci: utilizzare [https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_ClusterInstanceGroupSpecification.html#sagemaker-Type-ClusterInstanceGroupSpecification-InstanceStorageConfigs](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_ClusterInstanceGroupSpecification.html#sagemaker-Type-ClusterInstanceGroupSpecification-InstanceStorageConfigs)per il provisioning di volumi a livello di cluster (disponibile durante la creazione o l'aggiornamento di gruppi di istanze) o utilizzare il driver Amazon Elastic Block Store (Amazon EBS) Container Storage Interface (CSI) per la gestione dinamica dei volumi a livello di pod. Con [https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_ClusterInstanceGroupSpecification.html#sagemaker-Type-ClusterInstanceGroupSpecification-InstanceStorageConfigs](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_ClusterInstanceGroupSpecification.html#sagemaker-Type-ClusterInstanceGroupSpecification-InstanceStorageConfigs), imposta il [percorso locale](https://kubernetes.io/docs/concepts/storage/volumes/#local) `/opt/sagemaker` per montare correttamente i volumi sui tuoi pod Amazon EKS. Per informazioni su come distribuire il controller [Amazon EBS CSI](https://docs.aws.amazon.com/eks/latest/userguide/ebs-csi.html) sui HyperPod nodi, consulta. [Utilizzo del driver CSI Amazon EBS su SageMaker HyperPod cluster EKS](sagemaker-hyperpod-eks-ebs.md)
+ Se utilizzi etichette di tipo di istanza per definire i vincoli di pianificazione, assicurati di utilizzare i tipi di istanza AI ML con il prefisso. SageMaker `ml.` Ad esempio, per le istanze P5, utilizza `ml.p5.48xlarge` invece di `p5.48xlarge`.
**Considerazioni sulla configurazione della rete per i SageMaker HyperPod cluster con Amazon EKS**
+ Ogni istanza HyperPod del cluster supporta un'interfaccia di rete elastica (ENI). Per il numero massimo di pod per tipo di istanza, consulta la tabella seguente.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/sagemaker/latest/dg/sagemaker-hyperpod-eks-prerequisites.html)
+ Per impostazione predefinita, solo i pod con `hostNetwork = true` hanno accesso al servizio di metadati di istanza (IMDS) di Amazon EC2. Utilizza l'identità Amazon EKS Pod o i [ruoli IAM per gli account di servizio (IRSA)](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html) per gestire l'accesso alle AWS credenziali per i pod.
+ HyperPod I cluster orchestrati da EKS supportano due modalità di indirizzamento IP, che consentono la configurazione con o IPv4 per i cluster IPv6 IPv6 Amazon EKS in ambienti VPC e sottorete IPv6 abilitati. Per ulteriori informazioni, consulta [Configurazione SageMaker HyperPod con un Amazon VPC personalizzato](sagemaker-hyperpod-prerequisites.md#sagemaker-hyperpod-prerequisites-optional-vpc).
**Considerazioni sull' HyperPod utilizzo delle funzionalità di resilienza del cluster**
+ La sostituzione automatica dei nodi non è supportata per le istanze CPU.
+ L'agente di HyperPod monitoraggio dello stato deve essere installato affinché il ripristino automatico del nodo funzioni. L’agente può essere installato con Helm. Per ulteriori informazioni, consulta [Installazione di pacchetti sul cluster Amazon EKS con Helm](sagemaker-hyperpod-eks-install-packages-using-helm-chart.md).
+ L'agente di controllo HyperPod approfondito e monitoraggio dello stato supporta istanze GPU e Trn.
+ SageMaker L'intelligenza artificiale applica la seguente macchia ai nodi quando sono sottoposti a controlli di integrità approfonditi:
```
effect: NoSchedule
key: sagemaker.amazonaws.com/node-health-status
value: Unschedulable
```
**Nota**
Non puoi aggiungere taint personalizzati ai nodi nei gruppi di istanze con `DeepHealthChecks` attivato.
Una volta che il cluster Amazon EKS è in esecuzione, configura il cluster utilizzando il gestore di pacchetti Helm come indicato [Installazione di pacchetti sul cluster Amazon EKS con Helm](sagemaker-hyperpod-eks-install-packages-using-helm-chart.md) prima di creare il HyperPod cluster.
# Installazione di pacchetti sul cluster Amazon EKS con Helm
Prima di creare un SageMaker HyperPod cluster e collegarlo a un cluster Amazon EKS, è necessario installare i pacchetti utilizzando [Helm](https://helm.sh/), un gestore di pacchetti per Kubernetes. Helm è uno strumento open source che consente di configurare un processo di installazione per i cluster Kubernetes. Consente l'automazione e la semplificazione delle installazioni delle dipendenze e semplifica varie configurazioni necessarie per preparare il cluster Amazon EKS come orchestratore (piano di controllo) per un cluster. SageMaker HyperPod
[Il team SageMaker HyperPod di assistenza fornisce un pacchetto Helm chart, che raggruppa dipendenze chiave come device/EFA plug-in, plug-in, Kubeflow Training Operator e configurazioni di autorizzazione associate.](https://www.kubeflow.org/docs/components/training/)
**Importante**
Questa fase di installazione di Helm è obbligatoria. Se configuri il cluster Amazon EKS utilizzando [Console di gestione AWS](sagemaker-hyperpod-eks-operate-console-ui-create-cluster.md) o [CloudFormation](smcluster-getting-started-eks-console-create-cluster-cfn.md), puoi saltare questa fase perché l’installazione viene gestita automaticamente durante il processo di configurazione. Se configuri il cluster direttamente utilizzando APIs, utilizza il grafico Helm fornito per configurare il cluster Amazon EKS. La mancata configurazione del cluster Amazon EKS utilizzando il grafico Helm fornito potrebbe comportare il malfunzionamento del SageMaker HyperPod cluster o il completo fallimento del processo di creazione. Il nome del namespace `aws-hyperpod` non può essere modificato.
1. [Installa Helm](https://helm.sh/docs/intro/install/) sul computer locale.
1. Scarica i grafici Helm forniti da che SageMaker HyperPod si trovano `helm_chart/HyperPodHelmChart` nel repository [SageMaker HyperPod CLI](https://github.com/aws/sagemaker-hyperpod-cli/tree/main/helm_chart).
```
git clone https://github.com/aws/sagemaker-hyperpod-cli.git
cd sagemaker-hyperpod-cli/helm_chart
```
1. Aggiorna le dipendenze del grafico Helm, visualizza in anteprima le modifiche che verranno apportate al cluster Kubernetes e installa il grafico Helm.
```
helm dependencies update HyperPodHelmChart
```
```
helm install hyperpod-dependencies HyperPodHelmChart --namespace kube-system --dry-run
```
```
helm install hyperpod-dependencies HyperPodHelmChart --namespace kube-system
```
In sintesi, l'installazione Helm configura vari componenti per il cluster Amazon EKS, tra cui la pianificazione e la coda dei processi (Kueue), la gestione dello storage, l'integrazione e Kubeflow. MLflow Inoltre, i grafici installano i seguenti componenti per l'integrazione con le funzionalità di resilienza del cluster, che sono componenti obbligatori. SageMaker HyperPod
+ **Health monitoring agent**: installa l'agente di monitoraggio dello stato di salute fornito da. SageMaker HyperPod Questo è necessario se si desidera monitorare il HyperPod cluster. Gli agenti di monitoraggio dell’integrità sono forniti come immagini Docker secondo quanto descritto di seguito. Nei grafici Helm, l’immagine è preimpostata nel file `values.yaml` fornito. L'agente supporta istanze e Trainium-accelerator-based istanze basate su GPU (`trn1`,,). `trn1n` `inf2` Viene installato nel namespace `aws-hyperpod`. Per trovare l'URI supportato, consulta la sezione [Regioni supportate e il relativo ECR URIs ](https://github.com/aws/sagemaker-hyperpod-cli/blob/main/helm_chart/readme.md#6-notes) nell'archivio su. sagemaker-hyperpod-cli GitHub
+ **Controllo approfondito** dello stato: imposta a`ClusterRole`, a ServiceAccount (`deep-health-check-service-account`) nel `aws-hyperpod` namespace e `ClusterRoleBinding` a per abilitare la funzionalità di controllo SageMaker HyperPod approfondito dello stato. Per ulteriori informazioni sul file RBAC di Kubernetes per il controllo approfondito dello stato, consulta il file di configurazione nell'[https://github.com/aws/sagemaker-hyperpod-cli/blob/main/helm_chart/HyperPodHelmChart/charts/deep-health-check/templates/deep-health-check-rbac.yaml](https://github.com/aws/sagemaker-hyperpod-cli/blob/main/helm_chart/HyperPodHelmChart/charts/deep-health-check/templates/deep-health-check-rbac.yaml)archivio CLI. SageMaker HyperPod GitHub
+ **`job-auto-restart`**- Questo imposta a`ClusterRole`, a ServiceAccount (`job-auto-restart`) nel `aws-hyperpod` namespace e a`ClusterRoleBinding`, per abilitare la funzionalità di riavvio automatico per i lavori di PyTorch formazione in. SageMaker HyperPod Per ulteriori informazioni sul file RBAC di Kubernetes`job-auto-restart`, consulta il file di configurazione nell'[https://github.com/aws/sagemaker-hyperpod-cli/blob/main/helm_chart/HyperPodHelmChart/charts/job-auto-restart/templates/job-auto-restart-rbac.yaml](https://github.com/aws/sagemaker-hyperpod-cli/blob/main/helm_chart/HyperPodHelmChart/charts/job-auto-restart/templates/job-auto-restart-rbac.yaml)archivio CLI. SageMaker HyperPod GitHub
+ **Operatore MPI Kubeflow**: l’[operatore MPI](https://github.com/kubeflow/mpi-operator) è un operatore Kubernetes che utilizza l’interfaccia per il passaggio dei messaggi (MPI) sui cluster Kubernetes per semplificare l’esecuzione di carichi di lavoro distribuiti di machine learning (ML) e di calcolo ad alte prestazioni (HPC). Installa l’operatore MPI v0.5. Viene installato nel namespace `mpi-operator`.
+ **`nvidia-device-plugin`**— Si tratta di un plug-in per dispositivi Kubernetes che consente di esporre automaticamente NVIDIA GPUs per l'utilizzo da parte dei container del cluster Amazon EKS. Consente a Kubernetes di allocare e fornire l'accesso a quanto richiesto per quel contenitore. GPUs Richiesto quando si utilizza un tipo di istanza con GPU.
+ **`neuron-device-plugin`**: plugin per dispositivi Kubernetes che consente di esporre automaticamente i chip AWS Inferentia da utilizzare con i container del cluster Amazon EKS. Consente a Kubernetes di accedere e utilizzare i chip Inferentia sui nodi del cluster. AWS Richiesto quando si utilizza un tipo di istanza Neuron.
+ **`aws-efa-k8s-device-plugin`**— Si tratta di un plug-in per dispositivi Kubernetes che consente l'uso di AWS Elastic Fabric Adapter (EFA) sui cluster Amazon EKS. EFA è un dispositivo di rete che fornisce comunicazioni a bassa latenza e ad alto throughput tra le istanze di un cluster. Richiesto quando si utilizza un tipo di istanza supportato da EFA.
Per ulteriori informazioni sulla procedura di installazione utilizzando i grafici Helm forniti, consultate il [file README nell'archivio CLI SageMaker HyperPod ](https://github.com/aws/sagemaker-hyperpod-cli/tree/main/helm_chart).
# Configurazione del controllo degli accessi basato su ruoli Kubernetes
Gli utenti amministratori del cluster devono inoltre configurare il [controllo degli accessi basato sul ruolo (RBAC) di Kubernetes](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) per consentire agli utenti di data scientist di utilizzare la [SageMaker HyperPod CLI per eseguire carichi di lavoro su cluster orchestrati con Amazon EKS](https://github.com/aws/sagemaker-hyperpod-cli). HyperPod
## Opzione 1: configurazione di RBAC con un grafico Helm
Il team di assistenza fornisce una sottocartella Helm per la configurazione di RBAC. SageMaker HyperPod Per ulteriori informazioni, consulta [Installazione di pacchetti sul cluster Amazon EKS con Helm](sagemaker-hyperpod-eks-install-packages-using-helm-chart.md).
## Opzione 2: configurazione manuale di RBAC
Crea `ClusterRole` e `ClusterRoleBinding` con privilegi minimi e `Role` e `RoleBinding` con autorizzazioni di mutazione.
**Per creare `ClusterRole` e `ClusterRoleBinding` per il ruolo IAM di Data Scientist**
Crea un file di configurazione a livello di cluster `cluster_level_config.yaml` come segue.
```
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: hyperpod-scientist-user-cluster-role
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["list"]
- apiGroups: [""]
resources: ["nodes"]
verbs: ["list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: hyperpod-scientist-user-cluster-role-binding
subjects:
- kind: Group
name: hyperpod-scientist-user-cluster-level
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: hyperpod-scientist-user-cluster-role # this must match the name of the Role or ClusterRole you wish to bind to
apiGroup: rbac.authorization.k8s.io
```
Applica la configurazione al cluster EKS.
```
kubectl apply -f cluster_level_config.yaml
```
**Per creare un ruolo e nello spazio dei nomi RoleBinding **
Questo è l’operatore di addestramento del namespace monitorato per impostazione predefinita dai job di addestramento eseguiti e da Resiliency. La funzionalità di ripresa automatica del processo è supportata solo nel namespace `kubeflow` o nel namespace con prefisso `aws-hyperpod`.
Crea un file di configurazione del ruolo `namespace_level_role.yaml` come segue. Questo esempio crea un ruolo nel namespace `kubeflow`.
```
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
namespace: kubeflow
name: hyperpod-scientist-user-namespace-level-role
###
# 1) add/list/describe/delete pods
# 2) get/list/watch/create/patch/update/delete/describe kubeflow pytroch job
# 3) get pod log
###
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["create", "get"]
- apiGroups: [""]
resources: ["nodes"]
verbs: ["get", "list"]
- apiGroups: [""]
resources: ["pods/log"]
verbs: ["get", "list"]
- apiGroups: [""]
resources: ["pods/exec"]
verbs: ["get", "create"]
- apiGroups: ["kubeflow.org"]
resources: ["pytorchjobs", "pytorchjobs/status"]
verbs: ["get", "list", "create", "delete", "update", "describe"]
- apiGroups: [""]
resources: ["configmaps"]
verbs: ["create", "update", "get", "list", "delete"]
- apiGroups: [""]
resources: ["secrets"]
verbs: ["create", "get", "list", "delete"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
namespace: kubeflow
name: hyperpod-scientist-user-namespace-level-role-binding
subjects:
- kind: Group
name: hyperpod-scientist-user-namespace-level
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: hyperpod-scientist-user-namespace-level-role # this must match the name of the Role or ClusterRole you wish to bind to
apiGroup: rbac.authorization.k8s.io
```
Applica la configurazione al cluster EKS.
```
kubectl apply -f namespace_level_role.yaml
```
## Creazione di una voce di accesso per i gruppi Kubernetes
Dopo aver configurato RBAC con una delle due opzioni precedenti, utilizza il comando di esempio seguente sostituendo le informazioni necessarie.
```
aws eks create-access-entry \
--cluster-name \
--principal-arn arn:aws:iam:::role/ScientistUserRole \
--kubernetes-groups '["hyperpod-scientist-user-namespace-level","hyperpod-scientist-user-cluster-level"]'
```
Per il parametro `principal-arn` è necessario utilizzare [Utenti IAM per Data Scientist](sagemaker-hyperpod-prerequisites-iam.md#sagemaker-hyperpod-prerequisites-iam-cluster-user).
# Amazon Machine Images personalizzate (AMIs) per SageMaker HyperPod cluster
Utilizzando Amazon Machine Images (AMIs) di base fornite e rese pubbliche da Amazon SageMaker HyperPod, puoi creare progetti personalizzati AMIs. Con un’AMI personalizzata, puoi creare ambienti specializzati per carichi di lavoro IA con stack software preconfigurati, personalizzazioni dei driver, dipendenze proprietarie e agenti di sicurezza. Questa funzionalità elimina la necessità di un complesso bootstrap post-avvio con script di configurazione del ciclo di vita.
Con custom AMIs, puoi standardizzare gli ambienti in diverse fasi, accelerare i tempi di avvio e avere il pieno controllo del tuo ambiente di runtime, sfruttando al contempo le funzionalità SageMaker HyperPod dell'infrastruttura e i vantaggi di scalabilità. Questo ti aiuta a mantenere il controllo sulla tua infrastruttura di intelligenza artificiale, pur continuando a beneficiare SageMaker HyperPod del runtime di base ottimizzato.
Puoi sfruttare le immagini di base SageMaker HyperPod ottimizzate per le prestazioni aggiungendo agenti di sicurezza, strumenti di conformità e librerie specializzate, preservando al contempo tutti i vantaggi della formazione distribuita. Grazie a questa funzionalità, non devi più scegliere come in passato tra l’ottimizzazione dell’infrastruttura e le policy di sicurezza organizzative.
L’esperienza AMI personalizzata si integra perfettamente con i flussi di lavoro di sicurezza aziendali consolidati. I team di sicurezza creano immagini rinforzate utilizzando le immagini pubbliche AMIs come base e i team SageMaker HyperPod della piattaforma di intelligenza artificiale possono specificarle personalizzate AMIs durante la creazione o l'aggiornamento dei cluster tramite. SageMaker HyperPod APIs APIs Convalidano la compatibilità delle immagini, gestiscono le autorizzazioni necessarie e mantengono la compatibilità con le versioni precedenti in modo che i flussi di lavoro esistenti continuino a funzionare. Le organizzazioni con protocolli di sicurezza rigorosi non devono più ricorrere all’alternativa più soggetta a errori che prevede l’installazione di agenti di sicurezza al runtime tramite script del ciclo di vita. Allineandosi alle pratiche di sicurezza aziendali anziché costringere le organizzazioni ad adattare i propri protocolli alle limitazioni, la soluzione personalizzata AMIs rimuove una barriera comune all' SageMaker HyperPodadozione per le organizzazioni attente alla sicurezza che eseguono carichi di lavoro di intelligenza artificiale critici.
Per le note di rilascio sugli aggiornamenti pubblici, vedere. AMIs [Rilasci di AMI pubbliche](sagemaker-hyperpod-release-public-ami.md) Per informazioni su come iniziare a creare un'AMI personalizzata e a utilizzarla nei HyperPod cluster, consulta i seguenti argomenti.
**Topics**
+ [Creazione di un’AMI personalizzata](hyperpod-custom-ami-how-to.md)
+ [Gestione dei cluster con funzionalità personalizzate AMIs](hyperpod-custom-ami-cluster-management.md)
# Creazione di un’AMI personalizzata
La pagina seguente spiega come creare un'Amazon Machine Image (AMI) personalizzata utilizzando Amazon SageMaker HyperPod base AMIs. Inizia selezionando un’AMI di base, quindi crea un’AMI personalizzata utilizzando uno dei diversi metodi disponibili per la creazione di nuove immagini, ad esempio la AWS CLI.
## Seleziona un AMI SageMaker HyperPod di base
È possibile selezionare un'AMI di SageMaker HyperPod base tramite uno dei seguenti metodi.
### AWS selezione della console
È possibile selezionare public SageMaker HyperPod AMIs tramite la AWS console o utilizzando la chiamata `DescribeImages` API. SageMaker HyperPod AMIs sono pubblici e visibili in ogni Account AWS. Puoi trovarli nel catalogo AMI Amazon EC2 applicando un filtro per cercare quelli di AMIs proprietà pubblica di Amazon.
Per trovarli SageMaker HyperPod AMIs nella console:
1. Accedi alla console Amazon EC2.
1. Nel riquadro di navigazione a sinistra, scegliere **AMIs**.
1. Nell’elenco a discesa **Tipo di immagine**, seleziona **Immagini pubbliche**.
1. Nei filtri della barra di ricerca, imposta il filtro **Alias proprietario** su **amazon**.
1. Cerca il AMIs prefisso **HyperPodEKS** e seleziona l'AMI (preferibilmente più recente) adatto al tuo caso d'uso. Ad esempio, puoi scegliere un’AMI Kubernetes 1.31 o Kubernetes 1.30.
### Recupera l'ultimo ID AMI pubblico tramite il AWS CLI
Se desideri utilizzare sempre l'AMI pubblica dell'ultima versione, è più efficiente utilizzare il parametro SageMaker HyperPod SSM pubblico che contiene il valore dell'ID AMI più recente rilasciato da SageMaker HyperPod.
L’esempio seguente spiega come recuperare l’ID dell’AMI più recente con la AWS CLI:
```
aws ssm get-parameter \
--name "/aws/service/sagemaker-hyperpod/ami/x86_64/eks-1.31-amazon-linux-2/latest/ami-id" \
--region us-east-1 \
--query "Parameter.Value" \
--output text
```
**Nota**
Sostituisci il nome del parametro con la versione di Kubernetes desiderata. Ad esempio, per utilizzare Kubernetes 1.30, utilizza il parametro seguente: `/aws/service/hyperpod/ami/x86_64/eks-1.30-amazon-linux-2/latest/ami-id`.
## Creazione di un’AMI personalizzata
Dopo aver selezionato un'AMI SageMaker HyperPod pubblica, usala come AMI di base per creare la tua AMI personalizzata con uno dei seguenti metodi. Nota che questo non è un elenco esaustivo per la creazione AMIs. Puoi usare qualsiasi metodo di tua scelta per costruire AMIs. SageMaker HyperPod non ha alcuna raccomandazione specifica.
+ **AWS Console di gestione**: puoi avviare un'istanza Amazon EC2 utilizzando l' SageMaker HyperPod AMI, effettuare le personalizzazioni desiderate e quindi creare un'AMI da quell'istanza.
+ **AWS CLI**: puoi anche utilizzare il comando `aws ec2 create-image` per creare un’AMI da un’istanza Amazon EC2 esistente dopo aver eseguito la personalizzazione.
+ **HashiCorp Packer**: Packer è uno strumento open source HashiCorp che consente di creare immagini di macchine identiche per più piattaforme da un'unica configurazione di origine. Supporta AMIs la creazione e l' AWS elaborazione di immagini per altri provider di cloud e piattaforme di virtualizzazione.
+ **Image Builder**: EC2 Image Builder è un servizio AWS completamente gestito che semplifica l’automazione delle operazioni di creazione, manutenzione, convalida, condivisione e implementazione di immagini Linux o Windows Server. Per ulteriori informazioni, consulta la [Guida per l'utente di EC2 Image Builder](https://docs.aws.amazon.com/imagebuilder/latest/userguide/what-is-image-builder.html).
### Crea un'AMI personalizzata con AWS KMS crittografia gestita dal cliente
Le sezioni seguenti descrivono come creare un'AMI personalizzata con una AWS KMS chiave gestita dal cliente per crittografare i volumi HyperPod del cluster. Per ulteriori informazioni sulle chiavi gestite dai clienti HyperPod e sulla concessione delle autorizzazioni necessarie per le policy relative alle chiavi IAM e KMS, consulta. [AWS KMS key Crittografia gestita dal cliente per SageMaker HyperPod](smcluster-cmk.md) Se prevedi di utilizzare un'AMI personalizzata crittografata con una chiave gestita dal cliente, assicurati di crittografare anche il volume root Amazon EBS del HyperPod cluster con la stessa chiave.
#### AWS CLI esempio: creare una nuova AMI utilizzando EC2 Image Builder HyperPod e un'immagine di base
L’esempio seguente illustra come creare un’AMI utilizzando Image Builder con crittografia AWS KMS :
```
aws imagebuilder create-image-recipe \
name "hyperpod-custom-recipe" \
version "1.0.0" \
parent-image "" \
block-device-mappings DeviceName="/dev/xvda",Ebs={VolumeSize=100,VolumeType=gp3,Encrypted=true,KmsKeyId=arn:aws:kms:us-east-1:111122223333:key/key-id,DeleteOnTermination=true}
```
#### Console Amazon EC2: creazione di una nuova AMI da Amazon EC2
Per creare un’AMI da un’istanza Amazon EC2 con la console di Amazon EC2:
1. Fai clic con il pulsante destro del mouse sull’istanza Amazon EC2 personalizzata e scegli **Crea immagine**.
1. Nella sezione **Crittografia**, seleziona **Crittografa snapshot**.
1. Seleziona la chiave KMS dall’elenco a discesa. Ad esempio: `arn:aws:kms:us-east-2:111122223333:key/` oppure utilizza l’alias della chiave: `alias/`.
#### AWS CLI esempio: creare una nuova AMI da un'istanza Amazon EC2
Utilizza il comando `aws ec2 create-image` con la crittografia AWS KMS :
```
aws ec2 create-image \
instance-id "" \
name "MyCustomHyperPodAMI" \
description "Custom HyperPod AMI" \
block-device-mappings '[
{
"DeviceName": "/dev/xvda",
"Ebs": {
"Encrypted": true,
"KmsKeyId": "arn:aws:kms:us-east-1:111122223333:key/key-id",
"VolumeType": "gp2"
}
}
]'
```
# Gestione dei cluster con funzionalità personalizzate AMIs
Dopo aver creato l'AMI personalizzata, puoi utilizzarla per creare o aggiornare un SageMaker HyperPod cluster Amazon. Puoi anche aumentare verticalmente o aggiungere gruppi di istanze che utilizzano la nuova AMI.
## Autorizzazioni necessarie per le operazioni del cluster
Aggiungi le seguenti autorizzazioni all'utente amministratore del cluster che gestisce e configura i SageMaker HyperPod cluster. Il seguente esempio di policy include il set minimo di autorizzazioni per gli amministratori dei cluster per eseguire il SageMaker HyperPod core APIs e gestire SageMaker HyperPod i cluster con AMI personalizzate.
Tieni presente che le autorizzazioni di condivisione degli snapshot con AMI e AMI EBS sono incluse tramite le autorizzazioni API `ModifyImageAttribute` e `ModifySnapshotAttribute` nell’ambito della policy seguente. Per definire l’ambito delle autorizzazioni di condivisione, procedi nel seguente modo:
+ Aggiungi tag per controllare le autorizzazioni di condivisione delle AMI nelle AMI e negli snapshot AMI. Ad esempio, puoi taggare l’AMI impostando `AllowSharing` come `true`.
+ Aggiungi la chiave di contesto nella policy per consentire la condivisione AMI solo per i AMIs tag con determinati tag.
La seguente politica è una politica ristretta per garantire che `true` siano consentiti solo i AMIs tag con `AllowSharing` as.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "arn:aws:iam::111122223333:role/your-execution-role-name"
},
{
"Effect": "Allow",
"Action": [
"sagemaker:CreateCluster",
"sagemaker:DeleteCluster",
"sagemaker:DescribeCluster",
"sagemaker:DescribeClusterNode",
"sagemaker:ListClusterNodes",
"sagemaker:ListClusters",
"sagemaker:UpdateCluster",
"sagemaker:UpdateClusterSoftware",
"sagemaker:BatchDeleteClusterNodes",
"eks:DescribeCluster",
"eks:CreateAccessEntry",
"eks:DescribeAccessEntry",
"eks:DeleteAccessEntry",
"eks:AssociateAccessPolicy",
"iam:CreateServiceLinkedRole",
"ec2:DescribeImages",
"ec2:DescribeSnapshots"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ec2:ModifyImageAttribute",
"ec2:ModifySnapshotAttribute"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"ec2:ResourceTag/AllowSharing": "true"
}
}
}
]
}
```
------
**Importante**
Se prevedi di utilizzare un’AMI personalizzata crittografata, assicurati che la tua chiave KMS soddisfi le autorizzazioni descritte in [AWS KMS key Crittografia gestita dal cliente per SageMaker HyperPod](smcluster-cmk.md). Inoltre, assicurati che la chiave KMS dell’AMI personalizzata venga utilizzata anche per crittografare il volume root Amazon EBS del cluster.
## Creazione di un cluster
Puoi specificare l’AMI personalizzata nel campo `ImageId` relativo all’operazione `CreateCluster`.
Gli esempi seguenti mostrano come creare un cluster con un'AMI personalizzata, con e senza una chiave gestita AWS KMS dal cliente per la crittografia dei volumi del cluster.
------
#### [ Standard example ]
L’esempio seguente mostra come creare un cluster con un’AMI personalizzata.
```
aws sagemaker create-cluster \
--cluster-name \
--orchestrator 'Eks={ClusterArn=''}' \
--node-provisioning-mode Continuous \
--instance-groups '{
"InstanceGroupName": "",
"InstanceType": "ml.c5.2xlarge",
"InstanceCount": 2,
"LifeCycleConfig": {
"SourceS3Uri": "",
"OnCreate": "on_create_noop.sh"
},
"ImageId": "",
"ExecutionRole": "",
"ThreadsPerCore": 1,
"InstanceStorageConfigs": [
{
"EbsVolumeConfig": {
"VolumeSizeInGB": 200
}
}
]
}' --vpc-config '{
"SecurityGroupIds": [""],
"Subnets": [""]
}'
```
------
#### [ Customer managed key example ]
L'esempio seguente mostra come creare un cluster con un'AMI personalizzata specificando la propria chiave gestita AWS KMS dal cliente per crittografare i volumi Amazon EBS del cluster. È possibile specificare diverse chiavi gestite dal cliente per il volume root e il volume di archiviazione dell'istanza. Se non si utilizzano chiavi gestite dal cliente sul `InstanceStorageConfigs` campo, viene utilizzata una chiave KMS di AWS proprietà per crittografare i volumi. Se utilizzi chiavi diverse per il volume principale e per i volumi di storage delle istanze secondarie, imposta le policy delle chiavi KMS richieste su entrambe le chiavi.
```
aws sagemaker create-cluster \
--cluster-name \
--orchestrator 'Eks={ClusterArn=''}' \
--node-provisioning-mode Continuous \
--instance-groups '{
"InstanceGroupName": "",
"InstanceType": "ml.c5.2xlarge",
"InstanceCount": 2,
"LifeCycleConfig": {
"SourceS3Uri": "",
"OnCreate": "on_create_noop.sh"
},
"ImageId": "",
"ExecutionRole": "",
"ThreadsPerCore": 1,
"InstanceStorageConfigs": [
# Root volume configuration
{
"EbsVolumeConfig": {
"RootVolume": True,
"VolumeKmsKeyId": "arn:aws:kms:us-east-1:111122223333:key/key-id"
}
},
# Instance storage volume configuration
{
"EbsVolumeConfig": {
"VolumeSizeInGB": 100,
"VolumeKmsKeyId": "arn:aws:kms:us-east-1:111122223333:key/key-id"
}
}
]
}' --vpc-config '{
"SecurityGroupIds": [""],
"Subnets": [""]
}'
```
------
## Aggiornamento del software del cluster
Per aggiornare un gruppo di istanze esistente sul cluster con la tua AMI personalizzata, puoi utilizzare l’operazione `UpdateClusterSoftware` e specificare l’AMI personalizzata nel campo `ImageId`. Tieni presente che, a meno che non indichi il nome di un gruppo di istanze specifico nella richiesta, la nuova immagine viene applicata a tutti i gruppi di istanze del cluster.
L’esempio seguente mostra come aggiornare il software della piattaforma di un cluster con un’AMI personalizzata:
```
aws sagemaker update-cluster-software \
--cluster-name \
--instance-groups \
--image-id
```
## Aumento verticale di un gruppo di istanze
Gli esempi seguenti mostrano come scalare un gruppo di istanze per un cluster utilizzando un'AMI personalizzata, con e senza l'utilizzo di una chiave gestita AWS KMS dal cliente per la crittografia.
------
#### [ Standard example ]
L’esempio seguente spiega come aumentare verticalmente un gruppo di istanze con un’AMI personalizzata.
```
aws sagemaker update-cluster \
--cluster-name --instance-groups '[{
"InstanceGroupName": "",
"InstanceType": "ml.c5.2xlarge",
"InstanceCount": 2,
"LifeCycleConfig": {
"SourceS3Uri": "",
"OnCreate": "on_create_noop.sh"
},
"ExecutionRole": "",
"ThreadsPerCore": 1,
"ImageId": ""
}]'
```
------
#### [ Customer managed key example ]
L'esempio seguente mostra come aggiornare e scalare il cluster con un'AMI personalizzata specificando al contempo la propria chiave gestita AWS KMS dal cliente per crittografare i volumi Amazon EBS del cluster. È possibile specificare diverse chiavi gestite dal cliente per il volume root e il volume di storage dell'istanza. Se non si utilizzano chiavi gestite dal cliente sul `InstanceStorageConfigs` campo, viene utilizzata una chiave KMS di AWS proprietà per crittografare i volumi. Se utilizzi chiavi diverse per il volume principale e per i volumi di storage delle istanze secondarie, imposta le policy delle chiavi KMS richieste su entrambe le chiavi.
```
aws sagemaker update-cluster \
--cluster-name --instance-groups '[{
"InstanceGroupName": "",
"InstanceType": "ml.c5.2xlarge",
"InstanceCount": 2,
"LifeCycleConfig": {
"SourceS3Uri": "",
"OnCreate": "on_create_noop.sh"
},
"ExecutionRole": "",
"ThreadsPerCore": 1,
"ImageId": "",
"InstanceStorageConfigs": [
# Root volume configuration
{
"EbsVolumeConfig": {
"RootVolume": True,
"VolumeKmsKeyId": "arn:aws:kms:us-east-1:111122223333:key/key-id"
}
},
# Instance storage volume configuration
{
"EbsVolumeConfig": {
"VolumeSizeInGB": 100,
"VolumeKmsKeyId": "arn:aws:kms:us-east-1:111122223333:key/key-id"
}
}
]
}]'
```
------
## Aggiunta di un gruppo di istanze
L’esempio seguente mostra come aggiungere un gruppo di istanze a un cluster utilizzando un’AMI personalizzata:
```
aws sagemaker update-cluster \
--cluster-name "" \
--instance-groups '{
"InstanceGroupName": "",
"InstanceType": "ml.c5.2xlarge",
"InstanceCount": 2,
"LifeCycleConfig": {
"SourceS3Uri": "",
"OnCreate": "on_create_noop.sh"
},
"ExecutionRole": "",
"ThreadsPerCore": 1,
"ImageId": ""
}' '{
"InstanceGroupName": "",
"InstanceType": "ml.c5.2xlarge",
"InstanceCount": 1,
"LifeCycleConfig": {
"SourceS3Uri": "",
"OnCreate": "on_create_noop.sh"
},
"ExecutionRole": "",
"ThreadsPerCore": 1,
"ImageId": ""
}'
```
# Gestione dei cluster SageMaker HyperPod EKS tramite la console SageMaker
I seguenti argomenti forniscono indicazioni su come gestire SageMaker HyperPod nella console AI. SageMaker
**Topics**
+ [Creazione di un SageMaker HyperPod cluster con l'orchestrazione di Amazon EKS](sagemaker-hyperpod-eks-operate-console-ui-create-cluster.md)
+ [Navigazione, visualizzazione e modifica dei cluster SageMaker HyperPod](sagemaker-hyperpod-eks-operate-console-ui-browse-view-edit.md)
+ [Eliminazione di un cluster SageMaker HyperPod](sagemaker-hyperpod-eks-operate-console-ui-delete-cluster.md)
# Creazione di un SageMaker HyperPod cluster con l'orchestrazione di Amazon EKS
Il seguente tutorial dimostra come creare un nuovo SageMaker HyperPod cluster e configurarlo con l'orchestrazione di Amazon EKS tramite l'interfaccia utente della console SageMaker AI.
**Topics**
+ [Crea un cluster](#smcluster-getting-started-eks-console-create-cluster-page)
+ [Distribuire le risorse](#smcluster-getting-started-eks-console-create-cluster-deploy)
## Crea un cluster
Per accedere alla pagina **SageMaker HyperPod Clusters** e scegliere l'orchestrazione di Amazon EKS, segui questi passaggi.
1. Apri la console Amazon SageMaker AI all'indirizzo [https://console.aws.amazon.com/sagemaker/](https://console.aws.amazon.com/sagemaker/).
1. Scegli **HyperPod Clusters** nel riquadro di navigazione a sinistra, quindi **Cluster Management**.
1. Nella pagina **SageMaker HyperPod Cluster, scegli **Crea HyperPod ** cluster**.
1. Nel menu a discesa **Crea HyperPod cluster**, scegli **Orchestrated by** Amazon EKS.
1. Nella pagina di creazione del cluster EKS, scegli l’opzione più adatta alle tue esigenze scegliendo tra le due disponibili.
1. **Configurazione rapida**: per iniziare subito con le impostazioni predefinite, scegli **Configurazione rapida**. Con questa opzione, l' SageMaker intelligenza artificiale creerà nuove risorse come VPC, sottoreti, gruppi di sicurezza, bucket Amazon S3, ruolo IAM e FSx for Lustre nel processo di creazione del cluster.
1. **Configurazione personalizzata**: per l’integrazione con le risorse AWS esistenti o per soddisfare requisiti di rete, sicurezza o archiviazione specifici, scegli **Configurazione personalizzata**. Con questa opzione, puoi scegliere di utilizzare le risorse esistenti o crearne di nuove e puoi personalizzare la configurazione in base alle tue esigenze.
## Configurazione rapida
Nella sezione **Configurazione rapida**, segui questi passaggi per creare il tuo HyperPod cluster con l'orchestrazione di Amazon EKS.
### Impostazioni generali
Specifica un nome per il nuovo cluster. Dopo la creazione del cluster, non è più possibile modificarne il nome.
### Gruppi di istanze
Per aggiungere un gruppo di istanze, scegli **Aggiungi gruppo**. Ogni gruppo di istanze può essere configurato in modo diverso ed è possibile creare un cluster eterogeneo composto da più gruppi di istanze con vari tipi di istanze. Per implementare un cluster, devi aggiungere almeno un gruppo di istanze. Segui questa procedura per aggiungere un gruppo di istanze.
1. In **Tipo di gruppo di istanze**, scegli **Standard** o **Gruppo di istanze limitato (RIG)**. Di solito si sceglie **Standard** perché fornisce un ambiente di calcolo generico senza limitazioni di sicurezza aggiuntive. **Gruppo di istanze limitato (RIG)** è un ambiente specializzato per la personalizzazione di modelli di fondazione come Amazon Nova. Per ulteriori informazioni sulla configurazione di RIG per la personalizzazione del modello Amazon Nova, consulta la personalizzazione di Amazon Nova nella guida per SageMaker HyperPod l'utente di [Amazon Nova 1.0 o nella guida per l'utente](https://docs.aws.amazon.com//nova/latest/userguide/nova-hp.html) di [Amazon Nova 2.0](https://docs.aws.amazon.com//nova/latest/nova2-userguide/nova-hp.html).
1. In **Nome**, specifica un nome per il gruppo di istanze.
1. In **Capacità dell’istanza**, scegli la capacità on demand o un piano di addestramento per riservare le tue risorse di calcolo.
1. Per **Tipo di istanza**, scegli l’istanza per il gruppo di istanze.
**Importante**
Assicurati di selezionare un tipo di istanza con quote sufficienti e un numero adeguato di indirizzi IP non assegnati per il tuo account. Per visualizzare o richiedere quote aggiuntive, consulta [SageMaker HyperPod quote](sagemaker-hyperpod-prerequisites.md#sagemaker-hyperpod-prerequisites-quotas).
1. In **Quantità istanze**. specifica un numero intero che non sia maggiore della quota dell’istanza per l’utilizzo del cluster. Per questo tutorial, inserisci **1** per tutti e tre i gruppi.
1. In **Zona di disponibilità di destinazione**, scegli la zona di disponibilità in cui allocare le istanze. La zona di disponibilità deve corrispondere alla posizione della capacità di calcolo accelerata.
1. Per **Volume di archiviazione aggiuntivo per istanza (GB) (facoltativo)**, specifica un numero intero compreso tra 1 e 16.384 per impostare la dimensione di un volume Elastic Block Store (EBS) aggiuntivo in gigabyte (GB). Il volume EBS è collegato a ciascuna istanza del gruppo di istanze. Il percorso di montaggio predefinito per il volume EBS aggiuntivo è `/opt/sagemaker`. Dopo aver creato correttamente il cluster, è possibile accedere tramite SSH alle istanze del cluster (nodi) e verificare che il volume EBS sia montato correttamente eseguendo il comando `df -h`. Il collegamento di un volume EBS aggiuntivo fornisce un’archiviazione stabile, fuori istanza e con persistenza indipendente, come descritto nella sezione [Amazon EBS volumes](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-volumes.html) in *Amazon Elastic Block Store User Guide*.
1. Per **Controlli approfonditi dell’integrità delle istanze**, scegli un’opzione. I controlli dell’integrità approfonditi monitorano l’integrità dell’istanza durante la creazione e dopo gli aggiornamenti software, ripristinando automaticamente le istanze difettose con riavvii o sostituzioni, se abilitati.
1. Se il tuo tipo di istanza supporta il partizionamento GPU con Multi-Instance GPU (MIG), puoi abilitare la configurazione delle partizioni GPU per il gruppo di istanze. Il partizionamento GPU consente di suddividerlo in partizioni più piccole e isolate per un migliore utilizzo delle risorse. GPUs Per ulteriori informazioni, consulta [Utilizzo delle partizioni GPU in Amazon SageMaker HyperPod](sagemaker-hyperpod-eks-gpu-partitioning.md).
1. Attiva **Usa la partizione GPU per abilitare il partizionamento GPU** per questo gruppo di istanze.
1. Seleziona un **profilo di partizione GPU** tra le opzioni disponibili per il tipo di istanza. Ogni profilo definisce la configurazione delle slice GPU e l'allocazione della memoria.
1. Scegli **Aggiungi gruppo di istanze**.
### Impostazioni predefinite della configurazione rapida
Questa sezione elenca tutte le impostazioni predefinite per la creazione del cluster, incluse tutte le nuove AWS risorse che verranno create durante il processo di creazione del cluster. Verificare le impostazioni predefinite.
## Configurazione personalizzata
Nella sezione **Configurazione personalizzata**, segui questi passaggi per creare il tuo primo HyperPod cluster con l'orchestrazione di Amazon EKS.
### Impostazioni generali
Specifica un nome per il nuovo cluster. Dopo la creazione del cluster, non è più possibile modificarne il nome.
In **Ripristino dell’istanza**, scegli **Automatico *(consigliato)*** o **Nessuno**.
### Rete
Configura le impostazioni di rete all'interno del cluster e in-and-out del cluster. Per l'orchestrazione del SageMaker HyperPod cluster con Amazon EKS, il VPC viene impostato automaticamente su quello configurato con il cluster EKS selezionato.
1. Per quanto riguarda il **VPC**, scegli il tuo VPC se ne hai già uno che consente all' SageMaker IA di accedere al tuo VPC. Per creare un nuovo VPC, segui le istruzioni in [Create a VPC](https://docs.aws.amazon.com/vpc/latest/userguide/create-vpc.html) in *Amazon Virtual Private Cloud User Guide*. Puoi lasciarlo su **Nessuno** per utilizzare il VPC SageMaker AI predefinito.
1. Per il **blocco VPC IPv4 CIDR**, inserisci l'IP iniziale del tuo VPC.
1. Per le **zone di disponibilità**, scegli le zone di disponibilità (AZ) in cui HyperPod verranno create le sottoreti per il tuo cluster. Scegli AZs quella che corrisponde alla posizione della tua capacità di elaborazione accelerata.
1. In **Gruppi di sicurezza**, scegli gruppi di sicurezza collegati al cluster Amazon EKS o il cui traffico in entrata è consentito dal gruppo di sicurezza associato al cluster Amazon EKS. Per creare nuovi gruppi di sicurezza, vai alla console di Amazon VPC.
### Orchestrazione
Segui questa procedura per creare o selezionare un cluster Amazon EKS da utilizzare come orchestratore.
1. In **Cluster EKS**, scegli di creare un nuovo cluster Amazon EKS o di utilizzarne uno esistente.
Se devi creare un nuovo cluster EKS, puoi farlo dalla sezione del cluster EKS senza dover aprire la console di Amazon EKS.
**Nota**
La sottorete VPC scelta HyperPod deve essere privata.
Dopo aver inviato una nuova richiesta di creazione di un cluster EKS, attendi che il cluster EKS diventi `Active`.
1. In **Versione Kubernetes**, scegli una versione dal menu a discesa. Per ulteriori informazioni sulle versioni di Kubernetes, consulta [Understand the Kubernetes version lifecycle on EKS](https://docs.aws.amazon.com//eks/latest/userguide/kubernetes-versions.html) in *Amazon EKS User Guide*.
1. In **Operatori**, scegli **Usa grafici e componenti aggiuntivi Helm predefiniti** o **Non installare operatori**. L’opzione predefinita è **Usa grafici e componenti aggiuntivi Helm predefiniti**, che verrà utilizzata per installare gli operatori sul cluster EKS. Per ulteriori informazioni sui grafici e sui componenti aggiuntivi di Helm predefiniti, consulta [https://github.com/aws/sagemaker-hyperpod-cli/tree/main/helm_chart/HyperPodHelmChart](https://github.com/aws/sagemaker-hyperpod-cli/tree/main/helm_chart/HyperPodHelmChart)dal repository. GitHub Per ulteriori informazioni, consulta [Installazione di pacchetti sul cluster Amazon EKS con Helm](sagemaker-hyperpod-eks-install-packages-using-helm-chart.md).
1. In **Operatori abilitati**, visualizza l’elenco degli operatori abilitati. Per modificare gli operatori, deseleziona la casella in alto e scegli gli operatori da abilitare per il cluster EKS.
**Nota**
Per utilizzarlo HyperPod con EKS, è necessario installare i grafici Helm e i componenti aggiuntivi che abilitano gli operatori sul cluster EKS. Questi componenti configurano EKS come piano di controllo HyperPod e forniscono la configurazione necessaria per la gestione e l'orchestrazione del carico di lavoro.
### Gruppi di istanze
Per aggiungere un gruppo di istanze, scegli **Aggiungi gruppo**. Ogni gruppo di istanze può essere configurato in modo diverso ed è possibile creare un cluster eterogeneo composto da più gruppi di istanze con vari tipi di istanze. Per implementare un cluster, devi aggiungere almeno un gruppo di istanze. Segui questa procedura per aggiungere un gruppo di istanze.
1. In **Tipo di gruppo di istanze**, scegli **Standard** o **Gruppo di istanze limitato (RIG)**. Di solito si sceglie **Standard** perché fornisce un ambiente di calcolo generico senza limitazioni di sicurezza aggiuntive. **Gruppo di istanze limitato (RIG)** è un ambiente specializzato per la personalizzazione di modelli di fondazione come Amazon Nova. Per ulteriori informazioni sulla configurazione di RIG per la personalizzazione del modello Amazon Nova, consulta la personalizzazione di Amazon Nova nella guida per SageMaker HyperPod l'utente di [Amazon Nova 1.0 o nella guida per l'utente](https://docs.aws.amazon.com//nova/latest/userguide/nova-hp.html) di [Amazon Nova 2.0](https://docs.aws.amazon.com//nova/latest/nova2-userguide/nova-hp.html).
1. In **Nome**, specifica un nome per il gruppo di istanze.
1. In **Capacità dell’istanza**, scegli la capacità on demand o un piano di addestramento per riservare le tue risorse di calcolo.
1. Per **Tipo di istanza**, scegli l’istanza per il gruppo di istanze.
**Importante**
Assicurati di selezionare un tipo di istanza con quote sufficienti e un numero adeguato di indirizzi IP non assegnati per il tuo account. Per visualizzare o richiedere quote aggiuntive, consulta [SageMaker HyperPod quote](sagemaker-hyperpod-prerequisites.md#sagemaker-hyperpod-prerequisites-quotas).
1. In **Quantità istanze**. specifica un numero intero che non sia maggiore della quota dell’istanza per l’utilizzo del cluster. Per questo tutorial, inserisci **1** per tutti e tre i gruppi.
1. In **Zona di disponibilità di destinazione**, scegli la zona di disponibilità in cui allocare le istanze. La zona di disponibilità deve corrispondere alla posizione della capacità di calcolo accelerata.
1. Per **Volume di archiviazione aggiuntivo per istanza (GB) (facoltativo)**, specifica un numero intero compreso tra 1 e 16.384 per impostare la dimensione di un volume Elastic Block Store (EBS) aggiuntivo in gigabyte (GB). Il volume EBS è collegato a ciascuna istanza del gruppo di istanze. Il percorso di montaggio predefinito per il volume EBS aggiuntivo è `/opt/sagemaker`. Dopo aver creato correttamente il cluster, è possibile accedere tramite SSH alle istanze del cluster (nodi) e verificare che il volume EBS sia montato correttamente eseguendo il comando `df -h`. Il collegamento di un volume EBS aggiuntivo fornisce un’archiviazione stabile, fuori istanza e con persistenza indipendente, come descritto nella sezione [Amazon EBS volumes](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-volumes.html) in *Amazon Elastic Block Store User Guide*.
1. Per **Controlli approfonditi dell’integrità delle istanze**, scegli un’opzione. I controlli dell’integrità approfonditi monitorano l’integrità dell’istanza durante la creazione e dopo gli aggiornamenti software, ripristinando automaticamente le istanze difettose con riavvii o sostituzioni, se abilitati. Per ulteriori informazioni, consulta [Controlli dell’integrità approfonditi](sagemaker-hyperpod-eks-resiliency-deep-health-checks.md)
1. Per **Usa la partizione GPU: facoltativo**, se il tipo di istanza supporta il partizionamento GPU con Multi-Instance GPU (MIG), puoi abilitare questa opzione per configurare il profilo di partizione GPU per il gruppo di istanze. Il partizionamento GPU consente di suddividerlo in partizioni più piccole e isolate per un migliore utilizzo delle risorse. GPUs Per ulteriori informazioni, consulta [Utilizzo delle partizioni GPU in Amazon SageMaker HyperPod](sagemaker-hyperpod-eks-gpu-partitioning.md).
1. Attiva **Usa la partizione GPU per abilitare il partizionamento GPU** per questo gruppo di istanze.
1. Seleziona un **profilo di partizione GPU** tra le opzioni disponibili per il tipo di istanza. Ogni profilo definisce la configurazione delle slice GPU e l'allocazione della memoria.
1. Scegli **Aggiungi gruppo di istanze**.
### Script del ciclo di vita
Puoi scegliere di utilizzare gli script del ciclo di vita predefiniti o quelli personalizzati, che verranno archiviati nel tuo bucket Amazon S3. [Puoi visualizzare gli script del ciclo di vita predefiniti nell'archivio Awesome Distributed Training. GitHub ](https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/7.sagemaker-hyperpod-eks/LifecycleScripts) Per ulteriori informazioni sugli script del ciclo di vita, consulta [Personalizzazione dei SageMaker HyperPod cluster utilizzando script del ciclo di vita](sagemaker-hyperpod-lifecycle-best-practices-slurm.md).
1. In **Script del ciclo di vita**, scegli tra script del ciclo di vita predefiniti o personalizzati.
1. In **Bucket S3 per gli script del ciclo di vita**, scegli se creare un nuovo bucket o utilizzare un bucket esistente per archiviare gli script del ciclo di vita.
### Permissions
Scegli o crea un ruolo IAM che HyperPod consenta di eseguire e accedere alle AWS risorse necessarie per tuo conto. Per ulteriori informazioni, consulta [Ruolo IAM per SageMaker HyperPod](sagemaker-hyperpod-prerequisites-iam.md#sagemaker-hyperpod-prerequisites-iam-role-for-hyperpod).
### Archiviazione
Configura il file system FSx for Lustre da fornire sul HyperPod cluster.
1. Per **File system**, scegliete un file system FSx for Lustre esistente, FSx per crearne uno nuovo, oppure non installatene uno FSx per Lustre.
1. In **Throughput per unità di archiviazione**, scegli il throughput che sarà disponibile per ogni TiB di archiviazione allocata.
1. In **Capacità di archiviazione**, inserisci un valore di capacità in TB.
1. Per **Tipo di compressione dei dati**, scegliete di **LZ4**abilitare la compressione dei dati.
1. In **Versione Lustre**, visualizza il valore consigliato per i nuovi file system.
### Tag (facoltativo)
Per i **tag: *facoltativo***, aggiungi coppie di chiavi e valori al nuovo cluster e gestisci il cluster come AWS risorsa. Per ulteriori informazioni, consulta [Tagging delle risorse AWS](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html).
## Distribuire le risorse
Dopo aver completato le configurazioni del cluster utilizzando **Configurazione rapida** o **Configurazione personalizzata**, scegli l’opzione seguente per avviare il provisioning delle risorse e la creazione del cluster.
+ **Invia**: l' SageMaker IA inizierà a fornire le risorse di configurazione predefinite e a creare il cluster.
+ **Scarica i parametri del CloudFormation modello**: scaricherai il file JSON dei parametri di configurazione ed eseguirai il AWS CLI comando per distribuire lo CloudFormation stack per fornire le risorse di configurazione e creare il cluster. Se necessario, puoi modificare il file JSON dei parametri scaricato. Se scegli questa opzione, consulta [Creazione di SageMaker HyperPod cluster utilizzando modelli CloudFormation](smcluster-getting-started-eks-console-create-cluster-cfn.md) per ulteriori informazioni.
# Navigazione, visualizzazione e modifica dei cluster SageMaker HyperPod
Utilizza le seguenti istruzioni per sfogliare, visualizzare e modificare SageMaker HyperPod i cluster orchestrati da Amazon EKS nella SageMaker console AI.
**Topics**
+ [Per sfogliare i tuoi cluster SageMaker HyperPod](#sagemaker-hyperpod-eks-operate-console-ui-browse-clusters)
+ [Per visualizzare i dettagli di ogni cluster SageMaker HyperPod](#sagemaker-hyperpod-eks-operate-console-ui-view-details-of-clusters)
+ [Per modificare un cluster SageMaker HyperPod](#sagemaker-hyperpod-eks-operate-console-ui-edit-clusters)
## Per sfogliare i tuoi cluster SageMaker HyperPod
In **Cluster** nella SageMaker HyperPod pagina della console SageMaker AI, tutti i cluster creati devono essere elencati nella sezione **Cluster**, che fornisce una visualizzazione riepilogativa dei cluster, del loro ARNs stato e dell'ora di creazione.
## Per visualizzare i dettagli di ogni cluster SageMaker HyperPod
In **Clusters** nella SageMaker HyperPod pagina della console SageMaker AI, i nomi dei cluster vengono attivati come collegamenti. Scegli il link del nome del cluster per visualizzare i dettagli di ogni cluster.
## Per modificare un cluster SageMaker HyperPod
1. In **Cluster** nel riquadro principale della SageMaker HyperPod console, scegli il cluster che desideri aggiornare.
1. Seleziona il cluster e scegli **Modifica**.
1. Nella pagina **Modifica **, puoi modificare le configurazioni dei gruppi di istanze esistenti, aggiungere altri gruppi di istanze, eliminare i gruppi di istanze e modificare i tag per il cluster. Dopo aver apportato le modifiche, scegli **Invia**.
1. Nella sezione **Configura gruppi di istanze**, puoi aggiungere altri gruppi di istanze scegliendo **Crea gruppo di istanze**.
1. Nella sezione **Configura gruppi di istanze**, puoi scegliere **Modifica** per modificarne la configurazione o **Elimina** per rimuovere definitivamente il gruppo di istanze.
**Importante**
Durante l’eliminazione di un gruppo di istanze, considera i seguenti punti:
Il SageMaker HyperPod cluster deve sempre mantenere almeno un gruppo di istanze.
Assicurati che venga eseguito il backup di tutti i dati critici prima della rimozione.
Il processo di rimozione non può essere annullato.
**Nota**
L’eliminazione di un gruppo di istanze comporterà la terminazione di tutte le risorse di calcolo associate a quel gruppo.
1. Nella sezione **Tag**, puoi aggiornare i tag per il cluster.
# Eliminazione di un cluster SageMaker HyperPod
Utilizza le seguenti istruzioni per eliminare SageMaker HyperPod i cluster orchestrati da Amazon EKS nella SageMaker console AI.
1. In **Clusters** nel riquadro principale della SageMaker HyperPod console, scegli il cluster che desideri eliminare.
1. Seleziona il cluster e scegli **Elimina**.
1. Nella finestra pop-up per l’eliminazione del cluster, esamina attentamente le informazioni sul cluster per verificare che il cluster sia quello desiderato.
1. Dopo aver esaminato le informazioni sul cluster, scegli **Sì, elimina il cluster**.
1. Digita **delete** nel campo di testo per confermare l’eliminazione.
1. Scegli **Elimina** nell’angolo in basso a destra della finestra pop-up per completare l’invio della richiesta di eliminazione del cluster.
**Nota**
Se l'eliminazione del cluster fallisce a causa delle politiche di governance delle SageMaker HyperPod attività allegate, dovrai farlo[Eliminazione delle policy](sagemaker-hyperpod-eks-operate-console-ui-governance-policies-delete.md).
# Creazione di SageMaker HyperPod cluster utilizzando modelli CloudFormation
È possibile creare SageMaker HyperPod cluster utilizzando i CloudFormation modelli per HyperPod. È necessario eseguire l'installazione AWS CLI per procedere.
**Topics**
+ [Configura le risorse nella console e distribuiscile utilizzando CloudFormation](#smcluster-getting-started-eks-console-create-cluster-deploy-console)
+ [Configura e distribuisci le risorse utilizzando CloudFormation](#smcluster-getting-started-eks-console-create-cluster-deploy-cfn)
## Configura le risorse nella console e distribuiscile utilizzando CloudFormation
È possibile configurare le risorse utilizzando Console di gestione AWS e distribuire utilizzando i CloudFormation modelli.
Segui questa procedura.
1. *Invece di scegliere **Invia***, scegli **Scarica i parametri del CloudFormation modello** alla fine del tutorial in[Guida introduttiva all' SageMaker HyperPod utilizzo della console SageMaker AI](smcluster-getting-started-slurm-console.md). Il tutorial contiene importanti informazioni di configurazione, necessarie per creare correttamente il cluster.
**Importante**
Se scegli **Invia**, non sarai in grado di implementare un cluster con lo stesso nome finché non elimini il cluster.
Dopo aver scelto **Scarica i parametri del CloudFormation modello**, **la finestra Utilizzo del file di configurazione per creare il cluster tramite** la AWS CLI finestra apparirà sul lato destro della pagina.
1. Nella finestra **Utilizzo del file di configurazione per creare il cluster con la AWS CLI**, scegli **Scarica il file dei parametri di configurazione**. Il file verrà scaricato sul tuo computer. Puoi modificare il file JSON di configurazione in base alle tue esigenze o lasciarlo così com’è, se non sono necessarie modifiche.
1. In un terminale, vai alla posizione del file dei parametri `file://params.json`.
1. Esegui il AWS CLI comando [create-stack](https://docs.aws.amazon.com//cli/latest/reference/cloudformation/create-stack.html) per distribuire lo CloudFormation stack che fornirà le risorse configurate e creerà il cluster. HyperPod
```
aws cloudformation create-stack
--stack-name my-stack
--template-url https://aws-sagemaker-hyperpod-cluster-setup.amazonaws.com/templates-slurm/main-stack-slurm-based-template.yaml
--parameters file://params.json
--capabilities CAPABILITY_IAM CAPABILITY_NAMED_IAM
```
1. [Per visualizzare lo stato del provisioning delle risorse, accedi alla console. CloudFormation ](https://console.aws.amazon.com/cloudformation)
**Una volta completata la creazione del cluster, visualizza il nuovo cluster in Cluster nel riquadro principale della console.** SageMaker HyperPod Puoi anche controllarne lo stato nella colonna **Stato**.
1. Quando lo stato del cluster diventa `InService`, puoi iniziare ad accedere ai nodi del cluster. Per accedere ai nodi del cluster e iniziare a eseguire carichi di lavoro di ML, consulta [Lavori su cluster SageMaker HyperPod](sagemaker-hyperpod-run-jobs-slurm.md).
## Configura e distribuisci le risorse utilizzando CloudFormation
È possibile configurare e distribuire risorse utilizzando i CloudFormation modelli per. SageMaker HyperPod
Segui questa procedura.
1. Scarica un CloudFormation modello per SageMaker HyperPod dal [sagemaker-hyperpod-cluster-setup](https://github.com/aws/sagemaker-hyperpod-cluster-setup) GitHub repository.
1. Esegui il AWS CLI comando [create-stack](https://docs.aws.amazon.com//cli/latest/reference/cloudformation/create-stack.html) per distribuire lo CloudFormation stack che fornirà le risorse configurate e creerà il cluster. HyperPod
```
aws cloudformation create-stack
--stack-name my-stack
--template-url URL_of_the_file_that_contains_the_template_body
--parameters file://params.json
--capabilities CAPABILITY_IAM CAPABILITY_NAMED_IAM
```
1. Per visualizzare lo stato del provisioning delle risorse, accedere alla console CloudFormation .
Una volta completata la creazione del cluster, visualizza il nuovo cluster in **Clusters nel riquadro principale** della console. SageMaker HyperPod Puoi anche controllarne lo stato nella colonna **Stato**.
1. Quando lo stato del cluster diventa `InService`, puoi iniziare ad accedere ai nodi del cluster.
# Gestione dei cluster SageMaker HyperPod EKS utilizzando il AWS CLI
I seguenti argomenti forniscono indicazioni sulla scrittura di file di richiesta SageMaker HyperPod API in formato JSON e sulla loro esecuzione utilizzando i comandi. AWS CLI
**Topics**
+ [Creazione di un cluster SageMaker HyperPod](sagemaker-hyperpod-eks-operate-cli-command-create-cluster.md)
+ [Recupero dei dettagli del cluster SageMaker HyperPod](sagemaker-hyperpod-eks-operate-cli-command-cluster-details.md)
+ [Aggiornamento SageMaker HyperPod della configurazione del cluster](sagemaker-hyperpod-eks-operate-cli-command-update-cluster.md)
+ [Aggiornamento del software della SageMaker HyperPod piattaforma](sagemaker-hyperpod-eks-operate-cli-command-update-cluster-software.md)
+ [Accesso ai SageMaker HyperPod nodi del cluster](sagemaker-hyperpod-eks-operate-access-through-terminal.md)
+ [Ridimensionamento di un cluster SageMaker HyperPod](smcluster-scale-down.md)
+ [Eliminazione di un cluster SageMaker HyperPod](sagemaker-hyperpod-eks-operate-cli-command-delete-cluster.md)
# Creazione di un cluster SageMaker HyperPod
Scopri come creare SageMaker HyperPod cluster orchestrati da Amazon EKS utilizzando. AWS CLI
1. Prima di creare un cluster: SageMaker HyperPod
1. Assicurati di disporre di un cluster Amazon EKS funzionante. Per istruzioni dettagliate su come configurare un cluster Amazon EKS, consulta [Create an Amazon EKS cluster](https://docs.aws.amazon.com/eks/latest/userguide/create-cluster.html) in *Amazon EKS User Guide*.
1. Installa il grafico Helm come indicato in [Installazione di pacchetti sul cluster Amazon EKS con Helm](sagemaker-hyperpod-eks-install-packages-using-helm-chart.md). Se crei un [ SageMaker HyperPod cluster Amazon Nova](https://docs.aws.amazon.com//nova/latest/nova2-userguide/nova-hp-cluster.html), avrai bisogno di un grafico Helm separato.
1. Prepara uno script di configurazione del ciclo di vita e caricalo in un bucket Amazon S3, ad esempio `s3://amzn-s3-demo-bucket/Lifecycle-scripts/base-config/`.
Per iniziare rapidamente, scarica lo script di esempio [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/7.sagemaker-hyperpod-eks/LifecycleScripts/base-config/on_create.sh](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/7.sagemaker-hyperpod-eks/LifecycleScripts/base-config/on_create.sh)dal GitHub repository AWS Home Distributed Training e caricalo nel bucket S3. Puoi anche includere istruzioni di configurazione aggiuntive, una serie di script di configurazione o comandi da eseguire durante la fase di provisioning del HyperPod cluster.
**Importante**
Se crei un [Ruolo IAM per SageMaker HyperPod](sagemaker-hyperpod-prerequisites-iam.md#sagemaker-hyperpod-prerequisites-iam-role-for-hyperpod) collegando solo la [https://docs.aws.amazon.com/sagemaker/latest/dg/security-iam-awsmanpol-cluster.html](https://docs.aws.amazon.com/sagemaker/latest/dg/security-iam-awsmanpol-cluster.html) gestita, il tuo cluster ha accesso ai bucket Amazon S3 con il prefisso `sagemaker-` specifico.
Se crei un gruppo di istanze limitato, non devi scaricare ed eseguire lo script del ciclo di vita. Devi eseguire `install_rig_dependencies.sh`, invece.
I prerequisiti per eseguire lo script `install_rig_dependencies.sh` includono:
+ AWS Node (CNI) e CoredNS devono essere entrambi abilitati. Si tratta di componenti aggiuntivi EKS standard che non sono gestiti dall' SageMaker HyperPod Helm standard, ma possono essere facilmente abilitati nella console EKS alla voce Componenti aggiuntivi.
+ Il grafico SageMaker HyperPod Helm standard deve essere installato prima di eseguire questo script.
Lo script `install_rig_dependencies.sh` esegue queste operazioni.
+ `aws-node` (CNI): nuovo DaemonSet `rig-aws-node` creato; applicate patch al `aws-node` esistente per evitare nodi RIG.
+ `coredns`: Convertito in Daemonset per supportare l'uso di Multi-Rig e RIGs prevenire il sovraccarico.
+ training-operators: aggiornato con le tolleranze di taint dei worker RIG e con nodeAffinity che favorisce le istanze non RIG.
+ Elastic Fabric Adapter (EFA): aggiornato per tollerare il taint dei worker RIG e utilizzare immagini dei container corrette per ogni Regione.
1. Prepara un file di richiesta [CreateCluster](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_CreateCluster.html)API in formato JSON. Per `ExecutionRole`, fornisci l’ARN del ruolo IAM che hai creato con la policy gestita `AmazonSageMakerClusterInstanceRolePolicy` nella sezione [Ruolo IAM per SageMaker HyperPod](sagemaker-hyperpod-prerequisites-iam.md#sagemaker-hyperpod-prerequisites-iam-role-for-hyperpod).
**Nota**
Assicurati che il SageMaker HyperPod cluster sia distribuito all'interno dello stesso Virtual Private Cloud (VPC) del cluster Amazon EKS. Le sottoreti e i gruppi di sicurezza specificati nella configurazione del SageMaker HyperPod cluster devono consentire la connettività di rete e la comunicazione con l'endpoint del server API del cluster Amazon EKS.
```
// create_cluster.json
{
"ClusterName": "string",
"InstanceGroups": [{
"InstanceGroupName": "string",
"InstanceType": "string",
"InstanceCount": number,
"LifeCycleConfig": {
"SourceS3Uri": "s3://amzn-s3-demo-bucket-sagemaker/lifecycle-script-directory/src/",
"OnCreate": "on_create.sh"
},
"ExecutionRole": "string",
"ThreadsPerCore": number,
"OnStartDeepHealthChecks": [
"InstanceStress", "InstanceConnectivity"
]
}],
"RestrictedInstanceGroups": [
{
"EnvironmentConfig": {
"FSxLustreConfig": {
"PerUnitStorageThroughput": number,
"SizeInGiB": number
}
},
"ExecutionRole": "string",
"InstanceCount": number,
"InstanceGroupName": "string",
"InstanceStorageConfigs": [
{ ... }
],
"InstanceType": "string",
"OnStartDeepHealthChecks": [ "string" ],
"OverrideVpcConfig": {
"SecurityGroupIds": [ "string" ],
"Subnets": [ "string" ]
},
"ScheduledUpdateConfig": {
"DeploymentConfig": {
"AutoRollbackConfiguration": [
{
"AlarmName": "string"
}
],
"RollingUpdatePolicy": {
"MaximumBatchSize": {
"Type": "string",
"Value": number
},
"RollbackMaximumBatchSize": {
"Type": "string",
"Value": number
}
},
"WaitIntervalInSeconds": number
},
"ScheduleExpression": "string"
},
"ThreadsPerCore": number,
"TrainingPlanArn": "string"
}
],
"VpcConfig": {
"SecurityGroupIds": ["string"],
"Subnets": ["string"]
},
"Tags": [{
"Key": "string",
"Value": "string"
}],
"Orchestrator": {
"Eks": {
"ClusterArn": "string",
"KubernetesConfig": {
"Labels": {
"nvidia.com/mig.config": "all-3g.40gb"
}
}
}
},
"NodeRecovery": "Automatic"
}
```
Tieni presente quanto segue durante la configurazione per creare un nuovo SageMaker HyperPod cluster associato a un cluster EKS.
+ Puoi configurare fino a 20 gruppi di istanze nel parametro `InstanceGroups`.
+ Per `Orchestator.Eks.ClusterArn`, specifica l’ARN del cluster EKS da utilizzare come orchestratore.
+ Per `OnStartDeepHealthChecks`, aggiungi `InstanceStress` e `InstanceConnectivity` per abilitare [Controlli dell’integrità approfonditi](sagemaker-hyperpod-eks-resiliency-deep-health-checks.md).
+ Per`NodeRecovery`, specificare di `Automatic` abilitare il ripristino automatico dei nodi. SageMaker HyperPod sostituisce o riavvia le istanze (nodi) quando l'agente di monitoraggio dello stato rileva problemi.
+ Per il `Tags` parametro, è possibile aggiungere tag personalizzati per la gestione del SageMaker HyperPod cluster come risorsa. AWS Puoi aggiungere tag al cluster con la stessa procedura utilizzata per altri servizi AWS che supportano il tagging. Per ulteriori informazioni generali sul tagging delle risorse AWS , consulta [Tagging AWS Resources User Guide](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html).
+ Per il parametro `VpcConfig`, specifica le informazioni del VPC utilizzato nel cluster EKS. Le sottoreti devono essere private.
+ In alternativa`Orchestrator.Eks.KubernetesConfig.Labels`, puoi specificare le etichette Kubernetes da applicare ai nodi. Per abilitare il partizionamento della GPU con Multi-Instance GPU (MIG), aggiungi l'etichetta con il profilo MIG desiderato. `nvidia.com/mig.config` Ad esempio, `"nvidia.com/mig.config": "all-3g.40gb"` configura tutto con il profilo di partizione 3g.40gb. GPUs Per ulteriori informazioni sul partizionamento della GPU e sui profili disponibili, vedere. [Utilizzo delle partizioni GPU in Amazon SageMaker HyperPod](sagemaker-hyperpod-eks-gpu-partitioning.md)
1. Utilizza il comando [create-cluster](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/create-cluster.html) come segue.
**Importante**
Quando esegui il comando `create-cluster` con il parametro `--cli-input-json`, devi includere il prefisso `file://` prima del percorso completo del file JSON. Questo prefisso è necessario per garantire che AWS CLI riconosca l'input come percorso di file. L’omissione del prefisso `file://` genera un errore di analisi del parametro.
```
aws sagemaker create-cluster \
--cli-input-json file://complete/path/to/create_cluster.json
```
Questo dovrebbe restituire l’ARN del nuovo cluster.
**Importante**
Per rimuovere un gruppo di istanze limitato (RIG), puoi utilizzare l’operazione [update-cluster](https://docs.aws.amazon.com//cli/latest/reference/ecs/update-cluster.html). Quando un RIG viene ridimensionato a 0, il file system FSx for Lustre non verrà eliminato. Per rimuovere completamente il file system FSx for Lustre, è necessario rimuovere completamente il RIG.
La rimozione di un RIG non eliminerà gli artefatti archiviati nel bucket Amazon S3 gestito dal servizio. Tuttavia, è necessario assicurarsi che tutti gli artefatti nel file system FSx for Lustre siano completamente sincronizzati con Amazon S3 prima della rimozione. Ti consigliamo di attendere almeno 30 minuti dopo il completamento del processo per garantire la sincronizzazione completa di tutti gli artefatti dal file system FSx for Lustre al bucket Amazon S3 gestito dal servizio.
**Importante**
Quando si utilizza una On-Demand Capacity Reservation (ODCR) onboarding, è necessario mappare il gruppo di istanze allo stesso ID della zona di disponibilità (ID AZ) dell'ODCR impostando una sottorete nell'ID AZ corrispondente. `OverrideVpcConfig`
CRITICO: verifica la `OverrideVpcConfig` configurazione prima dell'implementazione per evitare di incorrere in addebiti duplicati sia per ODCR che per On-Demand Capacity.
# Recupero dei dettagli del cluster SageMaker HyperPod
Scopri come recuperare i dettagli SageMaker HyperPod del cluster utilizzando. AWS CLI
## Descrizione di un cluster
Esegui [describe-cluster](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/describe-cluster.html) per verificare lo stato del cluster. Puoi specificare il nome o l’ARN del cluster.
```
aws sagemaker describe-cluster --cluster-name your-hyperpod-cluster
```
Quando lo stato del cluster diventa **InService**, procedi con la fase successiva. Utilizzando questa API, puoi anche recuperare i messaggi di errore dall'esecuzione di altre operazioni HyperPod API.
## Elenco dei dettagli dei nodi del cluster
Esegui [list-cluster-nodes](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/list-cluster-nodes.html)per controllare le informazioni chiave dei nodi del cluster.
```
aws sagemaker list-cluster-nodes --cluster-name your-hyperpod-cluster
```
Questo restituisce una risposta e `InstanceId` è ciò che ti serve per l’accesso (con `aws ssm`).
## Descrizione dei dettagli di un nodo del cluster
Esegui [describe-cluster-node](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/describe-cluster-node.html)per recuperare i dettagli di un nodo del cluster. È possibile ottenere l'ID del nodo del cluster dall' list-cluster-nodesoutput. Puoi specificare il nome o l’ARN del cluster.
```
aws sagemaker describe-cluster-node \
--cluster-name your-hyperpod-cluster \
--node-id i-111222333444555aa
```
## Elenco dei cluster
Esegui [list-clusters](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/list-clusters.html) per elencare tutti i cluster del tuo account.
```
aws sagemaker list-clusters
```
Puoi anche aggiungere ulteriori flag per filtrare l’elenco dei cluster. Per ulteriori informazioni su cosa viene eseguito questo comando a basso livello e sui flag aggiuntivi per il filtraggio, consulta il riferimento all'[ListClusters](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_ListClusters.html)API.
# Aggiornamento SageMaker HyperPod della configurazione del cluster
Esegui [update-cluster](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/update-cluster.html) per aggiornare la configurazione di un cluster.
**Nota**
Considerazioni importanti:
Non è possibile modificare le informazioni sul cluster EKS a cui il HyperPod cluster è associato dopo la creazione del cluster.
Se sul cluster sono in esecuzione controlli dell’integrità approfonditi, questa API non funzionerà come previsto. Potrebbe essere visualizzato un messaggio di errore che indica che sono in corso controlli dell’integrità approfonditi. Per aggiornare il cluster, è necessario attendere il completamento dei controlli dell’integrità approfonditi.
1. Crea un file di richiesta API [https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_UpdateCluster.html](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_UpdateCluster.html) in formato JSON. Assicurati di specificare correttamente il nome del cluster e il nome del gruppo di istanze da aggiornare. Per ogni gruppo di istanze, puoi modificare il tipo di istanza, il numero di istanze, lo script del punto di ingresso della configurazione del ciclo di vita e il percorso dello script.
**Nota**
È possibile utilizzarle `UpdateCluster` per ridimensionare o rimuovere interi gruppi di istanze dal SageMaker HyperPod cluster. Per ulteriori istruzioni su come ridurre verticalmente o eliminare i gruppi di istanze, consulta [Ridimensionamento di un cluster SageMaker HyperPod](smcluster-scale-down.md).
1. Per `ClusterName`, specifica il nome del cluster da aggiornare.
1. Per `InstanceGroupName`
1. Per aggiornare un gruppo di istanze esistente, specifica il nome del gruppo di istanze da aggiornare.
1. Per aggiungere un nuovo gruppo di istanze, specifica un nuovo nome non presente nel cluster.
1. Per `InstanceType`
1. Per aggiornare un gruppo di istanze esistente, è necessario che il tipo di istanza specificato all’inizio corrisponda al gruppo.
1. Per aggiungere un nuovo gruppo di istanze, specifica il tipo di istanza con cui configurare il gruppo.
1. Per `InstanceCount`
1. Per aggiornare un gruppo di istanze esistente, specifica un numero intero corrispondente al numero di istanze desiderato. Puoi fornire un valore più alto o più basso (fino a 0) per aumentare o ridurre verticalmente il gruppo di istanze.
1. Per aggiungere un nuovo gruppo di istanze, specifica un numero intero maggiore o uguale a 1.
1. In `LifeCycleConfig`, puoi modificare entrambi i valori `SourceS3Uri` e `OnCreate` secondo le tue preferenze per aggiornare il gruppo di istanze.
1. Per `ExecutionRole`
1. Per aggiornare un gruppo di istanze esistente, continua a utilizzare lo stesso ruolo IAM collegato durante la creazione del cluster.
1. Per aggiungere un nuovo gruppo di istanze, specifica un ruolo IAM da collegare.
1. Per `ThreadsPerCore`
1. Per aggiornare un gruppo di istanze esistente, continua a utilizzare lo stesso valore specificato durante la creazione del cluster.
1. Per aggiungere un nuovo gruppo di istanze, puoi scegliere qualsiasi valore tra le opzioni consentite dal tipo di istanza. Per ulteriori informazioni, cerca il tipo di istanza e consulta la colonna **Thread validi per core** nella tabella di riferimento in [CPU cores and threads per CPU core per instance type](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/cpu-options-supported-instances-values.html) in *Amazon EC2 User Guide*.
1. Per `OnStartDeepHealthChecks`, aggiungi `InstanceStress` e `InstanceConnectivity` per abilitare [Controlli dell’integrità approfonditi](sagemaker-hyperpod-eks-resiliency-deep-health-checks.md).
1. Per`NodeRecovery`, specifica `Automatic` di abilitare il ripristino automatico dei nodi. SageMaker HyperPod sostituisce o riavvia le istanze (nodi) quando l'agente di monitoraggio dello stato rileva problemi.
Puoi utilizzare il frammento di codice seguente, che corrisponde a un modello di file di richiesta JSON. Per ulteriori informazioni sulla sintassi della richiesta e sui parametri di questa API, consulta il riferimento all'API. [UpdateCluster](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_UpdateCluster.html)
```
// update_cluster.json
{
// Required
"ClusterName": "name-of-cluster-to-update",
// Required
"InstanceGroups": [{
"InstanceGroupName": "string",
"InstanceType": "string",
"InstanceCount": number,
"LifeCycleConfig": {
"SourceS3Uri": "string",
"OnCreate": "string"
},
"ExecutionRole": "string",
"ThreadsPerCore": number,
"OnStartDeepHealthChecks": [
"InstanceStress", "InstanceConnectivity"
]
}],
"NodeRecovery": "Automatic"
}
```
1. Esegui il comando `update-cluster` per inviare la richiesta.
```
aws sagemaker update-cluster \
--cli-input-json file://complete/path/to/update_cluster.json
```
# Aggiornamento del software della SageMaker HyperPod piattaforma
Quando crei il SageMaker HyperPod cluster, SageMaker HyperPod seleziona un'Amazon Machine Image (AMI) corrispondente alla versione Kubernetes del cluster Amazon EKS.
Esegui [update-cluster-software](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/update-cluster-software.html)per aggiornare i cluster esistenti con software e patch di sicurezza fornite dal servizio. SageMaker HyperPod Per `--cluster-name`, specifica il nome o l’ARN del cluster da aggiornare.
**Importante**
Quando questa API viene chiamata, SageMaker HyperPod non scarica o ridistribuisce i job (Pod) in esecuzione sui nodi. Controlla la presenza di processi in esecuzione sui nodi prima di chiamare questa API.
Il processo di applicazione delle patch sostituisce il volume root con l’AMI aggiornata, il che significa che i dati precedenti archiviati nel volume root dell’istanza andranno persi. Assicurati di eseguire il backup dei dati dal volume root dell'istanza su Amazon S3 o Amazon FSx for Lustre.
Tutti i nodi del cluster sono soggetti a tempi di inattività (i nodi appaiono come `` nell’output di`kubectl get node`) durante l’applicazione delle patch. Ti consigliamo di terminare tutti i carichi di lavoro prima di applicare le patch e di riprenderli al termine dell’applicazione delle patch.
Se la patch di sicurezza non riesce, è possibile recuperare i messaggi di errore eseguendo l’API [https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_DescribeCluster.html](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_DescribeCluster.html) come indicato in [Descrizione di un cluster](sagemaker-hyperpod-eks-operate-cli-command-cluster-details.md#sagemaker-hyperpod-eks-operate-cli-command-describe-cluster).
```
aws sagemaker update-cluster-software --cluster-name your-hyperpod-cluster
```
Quando chiami l'`UpdateClusterSoftware`API, SageMaker HyperPod aggiorna la versione Kubernetes dei nodi selezionando la più recente in [SageMaker HyperPod DLAMI](sagemaker-hyperpod-ref.md#sagemaker-hyperpod-ref-hyperpod-ami) base alla versione Kubernetes del tuo cluster Amazon EKS. Quindi, esegue gli script del ciclo di vita nel bucket Amazon S3 che hai specificato durante la creazione o l’aggiornamento del cluster.
Puoi verificare la versione kubelet di un nodo con il comando `kubectl describe node`.
La versione Kubernetes dei nodi del SageMaker HyperPod cluster non si aggiorna automaticamente quando aggiorni la versione del cluster Amazon EKS. Dopo aver aggiornato la versione Kubernetes per il tuo cluster Amazon EKS, devi utilizzare l'`UpdateClusterSoftware`API per aggiornare i nodi del SageMaker HyperPod cluster alla stessa versione di Kubernetes.
Si consiglia di aggiornare il SageMaker HyperPod cluster dopo aver aggiornato i nodi Amazon EKS ed evitare di avere più di una differenza di versione tra la versione del cluster Amazon EKS e la versione dei nodi del SageMaker HyperPod cluster.
Il team SageMaker HyperPod di assistenza lancia regolarmente nuovi strumenti [SageMaker HyperPod DLAMI](sagemaker-hyperpod-ref.md#sagemaker-hyperpod-ref-hyperpod-ami) per migliorare la sicurezza e l'esperienza degli utenti. Ti consigliamo di continuare ad aggiornare sempre alla versione più recente di SageMaker HyperPod DLAMI. Per i futuri aggiornamenti SageMaker HyperPod DLAMI per le patch di sicurezza, segui con. [Note di SageMaker HyperPod rilascio di Amazon](sagemaker-hyperpod-release-notes.md)
**Nota**
Puoi eseguire questa API solo in modo programmatico. La funzionalità di patching non è implementata nell'interfaccia utente della SageMaker HyperPod console.
# Accesso ai SageMaker HyperPod nodi del cluster
È possibile accedere direttamente ai nodi di un SageMaker HyperPod cluster in servizio utilizzando i AWS CLI comandi for AWS Systems Manager (SSM). Esegui `aws ssm start-session` con il nome host del nodo in formato `sagemaker-cluster:[cluster-id]_[instance-group-name]-[instance-id]`. È possibile recuperare l'ID del cluster, l'ID dell'istanza e il nome del gruppo di istanze dalla [SageMaker HyperPod console](sagemaker-hyperpod-operate-slurm-console-ui.md#sagemaker-hyperpod-operate-slurm-console-ui-view-details-of-clusters) o eseguendo `describe-cluster` e `list-cluster-nodes` dai [AWS CLI comandi](sagemaker-hyperpod-operate-slurm-cli-command.md#sagemaker-hyperpod-operate-slurm-cli-command-list-cluster-nodes) di. SageMaker HyperPod Ad esempio, se l’ID del cluster è `aa11bbbbb222`, il nome del nodo del cluster è `controller-group` e l’ID del nodo del cluster è `i-111222333444555aa`, il comando `start-session` di SSM dovrebbe essere il seguente.
**Nota**
Se non hai ancora effettuato la configurazione AWS Systems Manager, segui le istruzioni fornite all'indirizzo[Configurazione AWS Systems Manager ed esecuzione come per il controllo degli accessi degli utenti del cluster](sagemaker-hyperpod-prerequisites.md#sagemaker-hyperpod-prerequisites-ssm).
```
$ aws ssm start-session \
--target sagemaker-cluster:aa11bbbbb222_controller-group-i-111222333444555aa \
--region us-west-2
Starting session with SessionId: s0011223344aabbccdd
root@ip-111-22-333-444:/usr/bin#
```
# Ridimensionamento di un cluster SageMaker HyperPod
Puoi ridurre il numero di istanze in esecuzione sul tuo SageMaker HyperPod cluster Amazon. Potresti voler ridurre verticalmente un cluster per vari motivi, ad esempio per limitare l’utilizzo delle risorse o ottimizzare i costi.
La pagina seguente descrive i due approcci principali per la riduzione verticale:
+ **Riduzione verticale a livello di gruppo di istanze:** questo approccio utilizza l’API `UpdateCluster`, che consente di:
+ Ridurre verticalmente il numero di istanze per gruppi di istanze specifici in modo indipendente. SageMaker L'intelligenza artificiale gestisce la terminazione dei nodi in modo da raggiungere i nuovi conteggi di istanze target che hai impostato per ciascun gruppo. Per informazioni, consulta [Riduzione verticale di un gruppo di istanze](#smcluster-scale-down-updatecluster).
+ Elimina completamente i gruppi di istanze dal cluster. Per informazioni, consulta [Eliminazione di gruppi di istanze](#smcluster-remove-instancegroup).
+ **Riduzione verticale a livello di istanza:** questo approccio utilizza l’API `BatchDeleteClusterNodes`, che consente di specificare i singoli nodi da terminare. Per informazioni, consulta [Riduzione verticale a livello di istanza](#smcluster-scale-down-batchdelete).
**Nota**
Quando si esegue la riduzione verticale a livello di istanza con `BatchDeleteCusterNodes`, puoi terminare solo un massimo di 99 istanze alla volta. `UpdateCluster` supporta la terminazione di qualsiasi numero di istanze.
## Considerazioni importanti
+ Quando si riduce verticalmente un cluster, è necessario assicurarsi che le risorse rimanenti siano sufficienti per gestire il carico di lavoro e che qualsiasi operazione necessaria di migrazione o ribilanciamento dei dati sia gestita correttamente per evitare interruzioni.
+ Assicurati di eseguire il backup dei dati su Amazon S3 o su un file system FSx for Lustre prima di richiamare l'API su un gruppo di nodi di lavoro. Questo aiuta a prevenire qualsiasi potenziale perdita di dati dal volume root dell’istanza. Per ulteriori informazioni sui backup, consulta [Utilizza lo script di backup fornito da SageMaker HyperPod](sagemaker-hyperpod-operate-slurm-cli-command.md#sagemaker-hyperpod-operate-slurm-cli-command-update-cluster-software-backup).
+ Per richiamare questa API su un cluster esistente, devi prima applicare una patch al cluster eseguendo l'API. [ UpdateClusterSoftware](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_UpdateClusterSoftware.html) Per ulteriori informazioni sull’applicazione delle patch in un cluster, consulta [Aggiorna il software della SageMaker HyperPod piattaforma di un cluster](sagemaker-hyperpod-operate-slurm-cli-command.md#sagemaker-hyperpod-operate-slurm-cli-command-update-cluster-software).
+ La misurazione/fatturazione per le istanze on demand verrà interrotta automaticamente dopo la riduzione verticale. Per interrompere la misurazione delle istanze riservate ridotte, contatta il team del tuo AWS account per ricevere assistenza.
+ Puoi utilizzare la capacità rilasciata dalle istanze riservate ridimensionate per scalare un altro cluster. SageMaker HyperPod
## Riduzione verticale a livello di gruppo di istanze
L'[https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_UpdateCluster.html](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_UpdateCluster.html)operazione consente di apportare modifiche alla configurazione del SageMaker HyperPod cluster, ad esempio ridurre il numero di istanze di un gruppo di istanze o rimuovere interi gruppi di istanze. Questa opzione può essere utile per adattare le risorse allocate al cluster in base alle variazioni del carico di lavoro, ottimizzare i costi o modificare il tipo di istanza di un gruppo di istanze.
### Riduzione verticale di un gruppo di istanze
Utilizza questo approccio quando hai un gruppo di istanze inattivo, che può quindi essere ridotto verticalmente in modo sicuro terminando una qualsiasi delle sue istanze. Quando invii una `UpdateCluster` richiesta di ridimensionamento, sceglie HyperPod casualmente le istanze da terminare e le ridimensiona fino al numero di nodi specificato per il gruppo di istanze.
**Nota**
Quando riduci verticalmente a 0 il numero di istanze in un gruppo di istanze, tutte le istanze all’interno del gruppo verranno terminate. Tuttavia, il gruppo di istanze stesso continuerà a esistere come parte del cluster. SageMaker HyperPod Puoi aumentare di nuovo verticalmente il gruppo di istanze in un secondo momento, utilizzando la stessa configurazione del gruppo di istanze.
In alternativa, puoi scegliere di rimuovere un gruppo di istanze in modo permanente. Per ulteriori informazioni, consulta [Eliminazione di gruppi di istanze](#smcluster-remove-instancegroup).
**Per ridurre verticalmente con `UpdateCluster`**
1. Segui la procedura descritta in [Aggiornamento SageMaker HyperPod della configurazione del cluster](sagemaker-hyperpod-eks-operate-cli-command-update-cluster.md). Quando raggiungi il passaggio **1.d** in cui specifichi il **InstanceCount**campo, inserisci un numero inferiore al numero corrente di istanze per ridimensionare il cluster.
1. Esegui il AWS CLI comando [update-cluster](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/update-cluster.html) per inviare la richiesta.
Di seguito è riportato un esempio di un oggetto JSON `UpdateCluster`: Supponiamo che il gruppo di istanze abbia attualmente due istanze in esecuzione. Se imposti il **InstanceCount**campo su 1, come mostrato nell'esempio, seleziona HyperPod casualmente una delle istanze e la termina.
```
{
"ClusterName": "name-of-cluster-to-update",
"InstanceGroups": [
{
"InstanceGroupName": "training-instances",
"InstanceType": "instance-type",
"InstanceCount": 1,
"LifeCycleConfig": {
"SourceS3Uri": "s3://amzn-s3-demo-bucket/training-script.py",
"OnCreate": "s3://amzn-s3-demo-bucket/setup-script.sh"
},
"ExecutionRole": "arn:aws:iam::123456789012:role/SageMakerRole",
"ThreadsPerCore": number-of-threads,
"OnStartDeepHealthChecks": [
"InstanceStress",
"InstanceConnectivity"
]
}
],
"NodeRecovery": "Automatic"
}
```
### Eliminazione di gruppi di istanze
È possibile utilizzare l'[https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_UpdateCluster.html](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_UpdateCluster.html)operazione per rimuovere interi gruppi di istanze dal SageMaker HyperPod cluster quando non sono più necessari. Questa operazione va oltre la semplice riduzione verticale, poiché consente di eliminare completamente gruppi di istanze specifici dalla configurazione del cluster.
**Nota**
Quando rimuovi un gruppo di istanze:
Tutte le istanze all’interno del gruppo di destinazione vengono terminate.
L’intera configurazione del gruppo viene eliminata dal cluster.
Tutti i carichi di lavoro in esecuzione sul gruppo di istanze vengono arrestati.
**Per eliminare gruppi di istanze con `UpdateCluster`**
1. Quando segui la procedura descritta in [Aggiornamento SageMaker HyperPod della configurazione del cluster](sagemaker-hyperpod-eks-operate-cli-command-update-cluster.md):
1. Imposta il parametro `InstanceGroupsToDelete` facoltativo nel JSON `UpdateCluster` e passa l’elenco separato da virgole dei nomi dei gruppi di istanze da eliminare.
1. Quando indichi l’elenco `InstanceGroups`, assicurati che le specifiche dei gruppi di istanze che stai rimuovendo non siano più elencate in `InstanceGroups`.
1. Esegui il AWS CLI comando [update-cluster](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/update-cluster.html) per inviare la richiesta.
**Importante**
Il SageMaker HyperPod cluster deve sempre mantenere almeno un gruppo di istanze.
Assicurati che venga eseguito il backup di tutti i dati critici prima della rimozione.
Il processo di rimozione non può essere annullato.
Di seguito è riportato un esempio di un oggetto JSON `UpdateCluster`: Consideriamo il caso di un cluster con tre gruppi di istanze: *training*, *prototype-training* e *inference-serving*. Vuoi eliminare il gruppo *prototype-training*.
```
{
"ClusterName": "name-of-cluster-to-update",
"InstanceGroups": [
{
"InstanceGroupName": "training",
"InstanceType": "instance-type",
"InstanceCount": ,
"LifeCycleConfig": {
"SourceS3Uri": "s3://amzn-s3-demo-bucket/training-script.py",
"OnCreate": "s3://amzn-s3-demo-bucket/setup-script.sh"
},
"ExecutionRole": "arn:aws:iam::123456789012:role/SageMakerRole",
"ThreadsPerCore": number-of-threads,
"OnStartDeepHealthChecks": [
"InstanceStress",
"InstanceConnectivity"
]
},
{
"InstanceGroupName": "inference-serving",
"InstanceType": "instance-type",
"InstanceCount": 2,
[...]
},
],
"InstanceGroupsToDelete": [ "prototype-training" ],
"NodeRecovery": "Automatic"
}
```
## Riduzione verticale a livello di istanza
L'`BatchDeleteClusterNodes`operazione consente di ridimensionare un SageMaker HyperPod cluster specificando i singoli nodi che si desidera terminare. `BatchDeleteClusterNodes`fornisce un controllo più granulare per la rimozione mirata dei nodi e l'ottimizzazione del cluster. Ad esempio, è possibile utilizzare `BatchDeleteClusterNodes` per eliminare nodi mirati per la manutenzione, gli aggiornamenti in sequenza o il ribilanciamento geografico delle risorse.
**Richiesta e risposta API**
Quando invii una `BatchDeleteClusterNodes` richiesta, SageMaker HyperPod elimina i nodi in base alla loro istanza. IDs L'API accetta una richiesta con il nome del cluster e un elenco di nodi IDs da eliminare.
La risposta include due sezioni:
+ `Failed`: un elenco di errori di tipo `[ BatchDeleteClusterNodesError ](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_BatchDeleteClusterNodesError.html)`, uno per ogni ID di istanza.
+ `Successful`: L'elenco delle istanze è IDs stato terminato con successo.
**Convalida e gestione degli errori**
L’API esegue varie convalide, ad esempio:
+ Verifica del formato dell’ID del nodo (prefisso `i-` e struttura dell’ID dell’istanza Amazon EC2).
+ Verifica della lunghezza dell'elenco dei nodi, con un limite di 99 o meno nodi IDs in una singola `BatchDeleteClusterNodes` richiesta.
+ Garantire che sia presente un SageMaker HyperPod cluster valido con il nome del cluster di input e che non siano in corso operazioni a livello di cluster (aggiornamento, aggiornamento del sistema, applicazione di patch o eliminazione).
+ Gestione dei casi in cui le istanze non vengono trovate, hanno uno stato non valido o sono in uso.
**Codici di risposta API**
+ L’API restituisce un codice di stato `200` per le richieste riuscite (ad esempio, la convalida di tutti i nodi di input è riuscita) o parzialmente riuscite (ad esempio, la convalida di alcuni nodi di input non è riuscita).
+ Se tutte queste convalide non riescono (ad esempio, la convalida di tutti i nodi di input non riesce), l’API restituirà una risposta Richiesta non valida `400` con i messaggi e i codici di errore appropriati.
**Esempio**
Di seguito è riportato un esempio di **riduzione verticale di un cluster a livello di istanza** con la AWS CLI:
```
aws sagemaker batch-delete-cluster-nodes --cluster-name "cluster-name" --node-ids '["i-111112222233333", "i-111112222233333"]'
```
# Eliminazione di un cluster SageMaker HyperPod
Esegui [delete-cluster](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/delete-cluster.html) per eliminare un cluster. Puoi specificare il nome o l’ARN del cluster.
```
aws sagemaker delete-cluster --cluster-name your-hyperpod-cluster
```
Questa API pulisce solo le SageMaker HyperPod risorse e non elimina alcuna risorsa del cluster EKS associato. Ciò include il cluster Amazon EKS, le identità EKS Pod, FSx i volumi Amazon e i componenti aggiuntivi EKS. Comprende anche la configurazione iniziale aggiunta al cluster EKS. Per pulire tutte le risorse, ricorda di pulire separatamente anche le risorse EKS.
Assicurati di eliminare prima le SageMaker HyperPod risorse, seguite dalle risorse EKS. Eseguire l’eliminazione in ordine inverso può comportare la persistenza delle risorse.
**Importante**
Quando questa API viene chiamata, SageMaker HyperPod non scarica o ridistribuisce i job (Pods) in esecuzione sui nodi. Controlla la presenza di processi in esecuzione sui nodi prima di chiamare questa API.
# HyperPod checkpoint gestito a più livelli
Questa sezione spiega come funziona il checkpoint gestito su più livelli e i vantaggi che offre per la formazione su modelli su larga scala.
Il checkpointing SageMaker HyperPod gestito su più livelli di Amazon ti aiuta ad addestrare modelli di intelligenza artificiale generativa su larga scala in modo più efficiente. Utilizzano più livelli di archiviazione, inclusa la memoria CPU del cluster. Questo approccio riduce i tempi di recupero e minimizza le perdite durante l’avanzamento dell’addestramento. Inoltre, sfrutta le risorse di memoria sottoutilizzate nell’infrastruttura di addestramento.
Il checkpoint gestito su più livelli consente di salvare i checkpoint con una frequenza più elevata nella memoria. Vengono archiviati periodicamente in uno spazio di archiviazione durevole. In questo modo si mantengono sia le prestazioni che l’affidabilità durante il processo di addestramento.
Questa guida spiega come impostare, configurare e utilizzare il checkpoint gestito su più livelli con PyTorch framework sui cluster Amazon EKS. HyperPod
## Come funziona il checkpoint gestito su più livelli
Il checkpoint gestito su più livelli utilizza un approccio di storage a più livelli. La memoria CPU funge da livello primario per archiviare i checkpoint del modello. I livelli secondari includono opzioni di archiviazione persistente come Amazon S3.
Quando salvi un checkpoint, il sistema lo archivia in uno spazio della memoria allocato nei nodi del cluster. I dati vengono replicati automaticamente su nodi di calcolo adiacenti per una maggiore affidabilità. Questa strategia di replica garantisce la protezione in caso di guasto di uno o più nodi, fornendo al contempo un accesso rapido per le operazioni di ripristino.
Il sistema inoltre salva periodicamente i checkpoint nell’archiviazione persistente in base alla configurazione dell’utente. Questa operazione garantisce una durata a lungo termine dei progressi dell’addestramento.
I componenti principali includono:
+ **Sistema di gestione della memoria**: un daemon di gestione della memoria che fornisce memoria disaggregata come servizio per l’archiviazione dei checkpoint
+ **HyperPod Libreria Python**: si interfaccia con lo storage disaggregato APIs e fornisce utilità per il salvataggio, il caricamento e la gestione dei checkpoint su più livelli
+ **Replica dei checkpoint**: replica automaticamente i checkpoint in più nodi per garantire la tolleranza ai guasti
Il sistema si integra perfettamente con i cicli di formazione tramite semplici chiamate API. PyTorch Richiede modifiche minime al codice esistente.
## Vantaggi
Il checkpoint gestito su più livelli offre diversi vantaggi per la formazione su modelli su larga scala:
+ **Migliore usabilità**: gestisce il salvataggio, la replica, la persistenza e il ripristino dei checkpoint
+ **Operazioni di checkpoint più rapide**: l’archiviazione basata sulla memoria offre tempi di salvataggio e caricamento più rapidi rispetto ai checkpoint basati su disco, con una conseguente accelerazione del ripristino
+ **Tolleranza ai guasti**: la replica automatica dei checkpoint tra i nodi protegge dai guasti dei nodi hardware
+ **Modifiche minime al codice**: l’integrazione semplice delle API richiede solo piccole modifiche agli script di addestramento esistenti
+ **Miglior throughput di addestramento**: un sovraccarico ridotto sui checkpoint significa più tempo dedicato all’addestramento vero e proprio
**Topics**
+ [Come funziona il checkpoint gestito su più livelli](#managed-tier-checkpointing-works)
+ [Vantaggi](#managed-tier-checkpointing-benefits)
+ [Imposta un checkpoint gestito su più livelli](managed-tier-checkpointing-setup.md)
+ [Rimozione del checkpoint gestito a più livelli](managed-tier-checkpointing-remove.md)
+ [Considerazioni sulla sicurezza per il checkpoint gestito su più livelli](managed-tier-security-considerations.md)
# Imposta un checkpoint gestito su più livelli
Questa sezione contiene il processo di configurazione per il checkpoint gestito a più livelli per Amazon. SageMaker HyperPod Scoprirai come abilitare la funzionalità nel cluster e implementare i checkpoint nel codice di addestramento.
**Topics**
+ [Prerequisiti](#managed-tier-checkpointing-setup-prerequisites)
+ [Passaggio 1: abilita il checkpoint gestito su più livelli per il tuo cluster](#managed-tier-checkpointing-setup-step-enable-for-cluster)
+ [Fase 2. Installa la libreria Python nell’immagine di addestramento](#managed-tier-checkpointing-setup-step-install-library)
+ [Fase 3: salva i checkpoint nel ciclo di allenamento](#managed-tier-checkpointing-setup-step-save-checkpoint-in-loop)
+ [Fase 4: Caricare i checkpoint per il ripristino](#managed-tier-checkpointing-setup-step-load-checkpoint)
+ [Convalida le tue operazioni di checkpoint gestite su più livelli](#managed-tier-checkpointing-setup-validation)
## Prerequisiti
Prima di configurare il checkpoint gestito a più livelli, assicurati di avere:
+ Un HyperPod cluster Amazon EKS con sufficiente memoria CPU disponibile per l'allocazione dei checkpoint
+ PyTorch carichi di lavoro di formazione e lavori DCP (entrambi supportati)
+ Autorizzazioni IAM appropriate per la gestione dei cluster, tra cui:
+ Autorizzazioni di scrittura di Amazon CloudWatch e Amazon S3 per il pod di formazione per leggere/scrivere checkpoint e inviare metriche
+ Queste autorizzazioni possono essere configurate dalla [configurazione EKS OIDC](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html)
## Passaggio 1: abilita il checkpoint gestito su più livelli per il tuo cluster
**Importante**
È necessario attivare l'utilizzo del checkpoint gestito su più livelli.
Abilita il checkpoint gestito su più livelli tramite HyperPod APIs durante la creazione o l'aggiornamento del cluster. Il servizio installa automaticamente il sistema di gestione della memoria quando specifichi il parametro `TieredStorageConfig`.
Per i nuovi cluster, puoi usare. [https://docs.aws.amazon.com/cli/latest/reference/sagemaker/create-cluster.html](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/create-cluster.html) AWS CLI
```
aws sagemaker create-cluster \
--cluster-name cluster-name \
--orchestrator "Eks={ClusterArn=eks-cluster-arn}" \
--instance-groups '{
"InstanceGroupName": "instance-group-name",
"InstanceType": "instance-type",
"InstanceCount": instance-count,
"LifeCycleConfig": {
"SourceS3Uri": "s3-path-to-lifecycle-scripts",
"OnCreate": "lifecycle-script-name"
},
"ExecutionRole": "instance-group-iam-role",
"ThreadsPerCore": threads-per-core,
"InstanceStorageConfigs": [
{ "EbsVolumeConfig": {"VolumeSizeInGB": volume-size} }
]
}' \
--vpc-config '{
"SecurityGroupIds": ["security-group-ids"],
"Subnets": ["subnets"]
}' \
--tiered-storage-config '{
"Mode": "Enable"
}'
```
Il parametro `InstanceMemoryAllocationPercentage` specifica il valore `percentage` (int) della memoria del cluster da allocare per i checkpoint. L’intervallo è compreso tra 20 e 100.
## Fase 2. Installa la libreria Python nell’immagine di addestramento
Installa la [libreria Amazon SageMaker checkpointing](https://pypi.org/project/amzn-sagemaker-checkpointing/) e le sue dipendenze nella tua immagine di formazione aggiungendola al tuo Dockerfile:
```
# Add this line to your training image Dockerfile
RUN pip install amzn-sagemaker-checkpointing s3torchconnector tenacity torch boto3 s3torchconnector
```
## Fase 3: salva i checkpoint nel ciclo di allenamento
Nel ciclo di allenamento, puoi salvare i checkpoint in modo asincrono utilizzando DCP. PyTorch Di seguito è riportato un esempio su come eseguire questa operazione.
```
import torch
import torch.distributed as dist
from torch.distributed.checkpoint import async_save, load
from amzn_sagemaker_checkpointing.checkpointing.filesystem.filesystem import (
SageMakerTieredStorageWriter,
SageMakerTieredStorageReader
)
# Initialize distributed training
dist.init_process_group(backend="nccl")
# Configure checkpointing
checkpoint_config = SageMakerCheckpointConfig(
# Unique ID for your training job
# Allowed characters in ID include: alphanumeric, hyphens, and underscores
namespace=os.environ.get('TRAINING_JOB_NAME', f'job-{int(time.time())}'),
# Number of distributed processes/available GPUs
world_size=dist.get_world_size(),
# S3 storage location, required for SageMakerTieredStorageReader for read fallbacks
# Required for SageMakerTieredStorageWriter when save_to_s3 is True
s3_tier_base_path="s3://my-bucket/checkpoints"
)
# Your model and optimizer
model = MyModel()
optimizer = torch.optim.AdamW(model.parameters())
# Training loop
future = None
in_memory_ckpt_freq = 10
s3_ckpt_freq = 50
for training_step in range(1000):
# ... training code ...
# Save checkpoint
if (training_step % in_memory_ckpt_freq == 0 or
training_step % s3_ckpt_freq == 0):
# Create state dictionary
state_dict = {
"model": model.state_dict(),
"optimizer": optimizer.state_dict(),
"step": training_step,
"epoch": epoch
}
# Create storage writer for current step
checkpoint_config.save_to_s3 = training_step % s3_ckpt_freq == 0
storage_writer = SageMakerTieredStorageWriter(
checkpoint_config=checkpoint_config,
step=training_step
)
# wait for previous checkpoint to get completed
if future is not None:
exc = future.exception()
if exc:
print(f"Failure in saving previous checkpoint:{str(exc)}")
# Handle failures as required
else:
result = future.result()
# Process results from save, if required
# Async save checkpoint using PyTorch DCP
future = async_save(state_dict=state_dict, storage_writer=storage_writer)
# Continue training while checkpoint saves in background
```
## Fase 4: Caricare i checkpoint per il ripristino
Di seguito è riportato un esempio sul caricamento di un checkpoint.
```
# Create state dictionary template
state_dict = {
"model": model.state_dict(),
"optimizer": optimizer.state_dict(),
"step": 0,
"epoch": 0
}
# Load latest checkpoint
storage_reader = SageMakerTieredStorageReader(checkpoint_config=checkpoint_config)
load(state_dict, storage_reader=storage_reader)
# Load specific checkpoint step
storage_reader = SageMakerTieredStorageReader(
checkpoint_config=checkpoint_config,
step=500 # Or don't pass step if you have to load the latest available step.
)
try:
load(state_dict, storage_reader=storage_reader)
except BaseException as e:
print(f"Checkpoint load failed: {str(e)}")
# Add additional exception handling
```
## Convalida le tue operazioni di checkpoint gestite su più livelli
È possibile convalidare le operazioni di checkpoint gestite su più livelli con i log.
**Registrazione di log personalizzata (facoltativo)**
Puoi integrare i log dei checkpoint con altri log passando un logger personalizzato alla libreria. Ad esempio, puoi aggiungere un logger personalizzato al codice di addestramento in modo che tutti i log della libreria vengano raccolti anche nel logger di addestramento.
**Registrazione avanzata di log dei servizi (facoltativo)**
Per migliorare il debug e la visibilità del servizio, puoi montare il percorso del log dei checkpoint `/var/log/sagemaker_checkpointing` dall’interno del pod a un percorso `/var/logs/sagemaker_checkpointing` sull’host. Questa operazione garantisce che solo i log specifici della libreria vengano raccolti separatamente. Il team di assistenza può quindi avere una maggiore visibilità per il debug e il supporto.
# Rimozione del checkpoint gestito a più livelli
Questa sezione spiega come disabilitare il checkpoint gestito su più livelli quando non è più necessario.
Per disabilitare il checkpoint gestito su più livelli, utilizza per aggiornare la configurazione del [https://docs.aws.amazon.com/cli/latest/reference/sagemaker/update-cluster.html](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/update-cluster.html) AWS CLI cluster:
```
aws sagemaker update-cluster \
--cluster-name cluster-name \
--tiered-storage-config '{ "Mode": "Disable" }'
```
Questo rimuove il daemon di gestione della memoria dal cluster. Il daemon è implementato come Kubernetes standard e segue la gestione standard del ciclo di vita di Kubernetes DaemonSet .
# Considerazioni sulla sicurezza per il checkpoint gestito su più livelli
Questa sezione tratta importanti considerazioni sulla sicurezza quando si utilizza il checkpoint gestito su più livelli. Include l’utilizzo del modulo pickle di Python, la crittografia Amazon S3 e la sicurezza degli endpoint di rete.
**Utilizzo del modulo pickle di Python**
Il checkpoint gestito a più livelli utilizza il modulo pickle di Python per deserializzare i dati dei checkpoint archiviati in Amazon S3. Questa implementazione ha importanti implicazioni in termini di sicurezza:
+ **Limite di fiducia esteso: quando si utilizza il checkpoint gestito su più livelli con Amazon S3, il bucket Amazon S3 entra a far parte del limite** di fiducia del cluster.
+ **Rischio di esecuzione del codice**: il modulo pickle di Python può eseguire codice arbitrario durante la deserializzazione. Se un utente non autorizzato ottiene l'accesso in scrittura al tuo bucket Amazon S3 di checkpoint, potrebbe creare dati di pickle dannosi che vengono eseguiti quando caricati tramite un checkpoint gestito a più livelli.
**Best practice per l’archiviazione Amazon S3**
Quando si utilizza il checkpoint gestito su più livelli con lo storage Amazon S3:
+ **Limita l’accesso ai bucket Amazon S3**: assicurati che solo gli utenti e i ruoli autorizzati associati al tuo cluster di addestramento abbiano accesso al bucket Amazon S3 utilizzato per i checkpoint.
+ **Implementa le policy di bucket**: configura le policy di bucket appropriate per impedire accessi o modifiche non autorizzati.
+ **Convalida dei modelli di accesso**: implementa la registrazione per convalidare i modelli di accesso ai bucket Amazon S3 del checkpoint.
+ **Convalida i nomi dei bucket**: presta attenzione quando scegli i nomi dei bucket per evitare potenziali manomissioni.
**Endpoint di rete**
Il checkpoint gestito su più livelli abilita gli endpoint di rete su ciascuno dei nodi di elaborazione sulle seguenti porte: 9200/TCP, 9209/UDP, 9210/UDP, 9219/UDP, 9220/UDP, 9229/UDP, 9230/UDP, 9239/UDP, 9240/UDP. Queste porte sono necessarie per il funzionamento del servizio di checkpoint e il mantenimento della sincronizzazione dei dati.
Per impostazione SageMaker predefinita, la configurazione di rete limita l'accesso a questi endpoint per motivi di sicurezza. Consigliamo di mantenere queste limitazioni predefinite.
Quando configuri le impostazioni di rete per i nodi e il VPC, AWS segui le best practice VPCs per i gruppi di sicurezza e. ACLs Per ulteriori informazioni, consulta gli argomenti seguenti:
+ [ SageMaker HyperPod Prerequisiti Amazon](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-prerequisites.html#sagemaker-hyperpod-prerequisites-optional-vpcCluster)
+ [Best practice sulla sicurezza del VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-best-practices.html)
# SageMaker HyperPod governance delle attività
SageMaker HyperPod la governance delle attività è un robusto sistema di gestione progettato per semplificare l'allocazione delle risorse e garantire un utilizzo efficiente delle risorse di elaborazione tra team e progetti per i cluster Amazon EKS. Questa funzionalità offre agli amministratori la possibilità di impostare:
+ Livelli di priorità per varie attività
+ Allocazione delle risorse di calcolo per ogni team
+ In che modo ogni team presta e prende in prestito risorse di calcolo inattive
+ Se un team rende prerilasciabili le proprie attività
HyperPod la governance delle attività fornisce anche l'osservabilità del cluster Amazon EKS, offrendo visibilità in tempo reale sulla capacità del cluster. Questo include la disponibilità e l’utilizzo delle risorse di calcolo, l’allocazione e l’utilizzo del team e le informazioni sull’esecuzione delle attività e sui tempi di attesa, per consentirti di prendere decisioni informate e gestire in modo proattivo le risorse.
Le seguenti sezioni spiegano come configurare, comprendere i concetti chiave e utilizzare la governance delle HyperPod attività per i cluster Amazon EKS.
**Topics**
+ [Configurazione per la governance SageMaker HyperPod delle attività](sagemaker-hyperpod-eks-operate-console-ui-governance-setup.md)
+ [Pannello di controllo](sagemaker-hyperpod-eks-operate-console-ui-governance-metrics.md)
+ [Processi](sagemaker-hyperpod-eks-operate-console-ui-governance-tasks.md)
+ [Policy](sagemaker-hyperpod-eks-operate-console-ui-governance-policies.md)
+ [Esempi di comandi di governance delle HyperPod AWS CLI attività](sagemaker-hyperpod-eks-operate-console-ui-governance-cli.md)
+ [Risoluzione dei problemi](sagemaker-hyperpod-eks-operate-console-ui-governance-troubleshoot.md)
+ [Documento di attribuzione per la governance delle SageMaker HyperPod attività di Amazon](sagemaker-hyperpod-eks-operate-console-ui-governance-attributions.md)
# Configurazione per la governance SageMaker HyperPod delle attività
La sezione seguente fornisce informazioni su come configurare Amazon CloudWatch Observability EKS e i componenti aggiuntivi per la governance delle SageMaker HyperPod attività.
Assicurati di disporre della politica di autorizzazione minima per gli amministratori dei HyperPod cluster con Amazon EKS, in[Utenti IAM per l’amministratore del cluster](sagemaker-hyperpod-prerequisites-iam.md#sagemaker-hyperpod-prerequisites-iam-cluster-admin). Ciò include le autorizzazioni per eseguire il SageMaker HyperPod core APIs e gestire i SageMaker HyperPod cluster all'interno di te Account AWS, eseguendo le attività in cui ti trovi. [Gestione dei SageMaker HyperPod cluster orchestrati da Amazon EKS](sagemaker-hyperpod-eks-operate.md)
**Topics**
+ [Configurazione della dashboard](sagemaker-hyperpod-eks-operate-console-ui-governance-setup-dashboard.md)
+ [Configurazione della governance delle attività](sagemaker-hyperpod-eks-operate-console-ui-governance-setup-task-governance.md)
# Configurazione della dashboard
Utilizza le seguenti informazioni per configurare il componente aggiuntivo Amazon SageMaker HyperPod Amazon CloudWatch Observability EKS. Questo ti offre una dashboard visiva dettagliata che fornisce una panoramica delle metriche relative all’hardware del cluster EKS, all’allocazione dei team e alle attività.
In caso di problemi di configurazione, consulta [Risoluzione dei problemi](sagemaker-hyperpod-eks-operate-console-ui-governance-troubleshoot.md) per la risoluzione dei problemi noti.
**Topics**
+ [HyperPod Prerequisiti del componente aggiuntivo Amazon CloudWatch Observability EKS](#hp-eks-dashboard-prerequisites)
+ [HyperPod Configurazione del componente aggiuntivo Amazon CloudWatch Observability EKS](#hp-eks-dashboard-setup)
## HyperPod Prerequisiti del componente aggiuntivo Amazon CloudWatch Observability EKS
La sezione seguente include i prerequisiti necessari per installare il componente aggiuntivo Amazon EKS Observability.
+ Assicurati di disporre della politica di autorizzazione minima per gli amministratori del HyperPod cluster, in. [Utenti IAM per l’amministratore del cluster](sagemaker-hyperpod-prerequisites-iam.md#sagemaker-hyperpod-prerequisites-iam-cluster-admin)
+ Collega una policy `CloudWatchAgentServerPolicy` IAM ai nodi worker. A questo scopo, immetti il comando seguente. Sostituisci `my-worker-node-role` con il ruolo IAM utilizzato dai nodi worker Kubernetes.
```
aws iam attach-role-policy \
--role-name my-worker-node-role \
--policy-arn arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy
```
## HyperPod Configurazione del componente aggiuntivo Amazon CloudWatch Observability EKS
Utilizza le seguenti opzioni per configurare il componente aggiuntivo Amazon SageMaker HyperPod Amazon CloudWatch Observability EKS.
------
#### [ Setup using the SageMaker AI console ]
Le seguenti autorizzazioni sono necessarie per configurare e visualizzare la dashboard di governance delle attività. HyperPod Questa sezione espande le autorizzazioni elencate in [Utenti IAM per l’amministratore del cluster](sagemaker-hyperpod-prerequisites-iam.md#sagemaker-hyperpod-prerequisites-iam-cluster-admin).
Per gestire la governance delle attività, utilizza la policy di esempio:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"sagemaker:ListClusters",
"sagemaker:DescribeCluster",
"sagemaker:ListComputeQuotas",
"sagemaker:CreateComputeQuota",
"sagemaker:UpdateComputeQuota",
"sagemaker:DescribeComputeQuota",
"sagemaker:DeleteComputeQuota",
"sagemaker:ListClusterSchedulerConfigs",
"sagemaker:DescribeClusterSchedulerConfig",
"sagemaker:CreateClusterSchedulerConfig",
"sagemaker:UpdateClusterSchedulerConfig",
"sagemaker:DeleteClusterSchedulerConfig",
"eks:ListAddons",
"eks:CreateAddon",
"eks:DescribeAddon",
"eks:DescribeCluster",
"eks:DescribeAccessEntry",
"eks:ListAssociatedAccessPolicies",
"eks:AssociateAccessPolicy",
"eks:DisassociateAccessPolicy"
],
"Resource": "*"
}
]
}
```
------
Per concedere le autorizzazioni per gestire Amazon CloudWatch Observability Amazon EKS e visualizzare la dashboard del HyperPod cluster tramite la console SageMaker AI, utilizza la politica di esempio seguente:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"eks:ListAddons",
"eks:CreateAddon",
"eks:UpdateAddon",
"eks:DescribeAddon",
"eks:DescribeAddonVersions",
"sagemaker:DescribeCluster",
"sagemaker:DescribeClusterNode",
"sagemaker:ListClusterNodes",
"sagemaker:ListClusters",
"sagemaker:ListComputeQuotas",
"sagemaker:DescribeComputeQuota",
"sagemaker:ListClusterSchedulerConfigs",
"sagemaker:DescribeClusterSchedulerConfig",
"eks:DescribeCluster",
"cloudwatch:GetMetricData",
"eks:AccessKubernetesApi"
],
"Resource": "*"
}
]
}
```
------
Passa alla scheda **Dashboard** nella SageMaker HyperPod console per installare Amazon CloudWatch Observability EKS. Per garantire che le metriche relative alla governance delle attività siano incluse nella **Dashboard**, abilita la casella di controllo delle metriche Kueue. L'abilitazione delle metriche Kueue abilita i costi di Metrics, una volta CloudWatch **raggiunto** il limite del livello gratuito. Per ulteriori informazioni, consulta **Metrics** in [Amazon CloudWatch Pricing](https://aws.amazon.com/cloudwatch/pricing/).
------
#### [ Setup using the EKS AWS CLI ]
Utilizza il seguente AWS CLI comando EKS per installare il componente aggiuntivo:
```
aws eks create-addon --cluster-name cluster-name
--addon-name amazon-cloudwatch-observability
--configuration-values "configuration json"
```
Di seguito è riportato un JSON di esempio con i valori di configurazione:
```
{
"agent": {
"config": {
"logs": {
"metrics_collected": {
"kubernetes": {
"kueue_container_insights": true,
"enhanced_container_insights": true
},
"application_signals": { }
}
},
"traces": {
"traces_collected": {
"application_signals": { }
}
}
},
},
}
```
------
#### [ Setup using the EKS Console UI ]
1. Passa alla [console EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Scegli il cluster.
1. Scegli **Componenti aggiuntivi**.
1. Trova il componente aggiuntivo **Amazon CloudWatch Observability** e installalo. Installa la versione 2.4.0 o superiore per il componente aggiuntivo.
1. Includi i valori di configurazione JSON seguenti:
```
{
"agent": {
"config": {
"logs": {
"metrics_collected": {
"kubernetes": {
"kueue_container_insights": true,
"enhanced_container_insights": true
},
"application_signals": { }
},
},
"traces": {
"traces_collected": {
"application_signals": { }
}
}
},
},
}
```
------
**Una volta installato correttamente il componente aggiuntivo EKS Observability, puoi visualizzare le metriche del cluster EKS nella scheda Dashboard della console. HyperPod **
# Configurazione della governance delle attività
Questa sezione include informazioni su come configurare il componente aggiuntivo Amazon SageMaker HyperPod task governance EKS. Questo include la concessione di autorizzazioni che consentono di impostare l’assegnazione di priorità alle attività, l’allocazione di risorse di calcolo per i team, le modalità di condivisione delle risorse di calcolo inattive e la prelazione delle attività per i team.
In caso di problemi di configurazione, consulta [Risoluzione dei problemi](sagemaker-hyperpod-eks-operate-console-ui-governance-troubleshoot.md) per la risoluzione dei problemi noti.
**Topics**
+ [Impostazioni Kueue](#hp-eks-task-governance-kueue-settings)
+ [HyperPod Prerequisiti per la governance delle attività](#hp-eks-task-governance-prerequisites)
+ [HyperPod configurazione della governance delle attività](#hp-eks-task-governance-setup)
## Impostazioni Kueue
HyperPod Il componente aggiuntivo Task Governance EKS installa [Kueue](https://github.com/kubernetes-sigs/kueue/tree/main/apis/kueue) per i tuoi cluster EKS. HyperPod Kueue è un sistema nativo di Kubernetes che gestisce le quote e il loro consumo da parte dei processi.
| Versione aggiuntiva EKS Task Governance HyperPod | Versione di Kueue installata nell’ambito di questo componente aggiuntivo |
| --- | --- |
| v1.1.3 | v0.12.0 |
**Nota**
Kueue v.012.0 e versioni successive non sono inclusi nell' kueue-rbac-proxyinstallazione. Potrebbero essere state installate versioni precedenti. kueue-rbac-proxy Ad esempio, se utilizzi Kueue v0.8.1, potresti avere la v0.18.1. kueue-rbac-proxy
HyperPod la governance delle attività sfrutta la gestione delle code, della pianificazione e delle quote di lavoro native di Kueue per Kubernetes e viene installata con il componente aggiuntivo Task Governance EKS. HyperPod Una volta installato, HyperPod crea e modifica risorse Kubernetes gestite SageMaker dall'intelligenza artificiale come,,, e. `KueueManagerConfig` `ClusterQueues` `LocalQueues` `WorkloadPriorityClasses` `ResourceFlavors` `ValidatingAdmissionPolicies` Sebbene gli amministratori di Kubernetes abbiano la flessibilità necessaria per modificare lo stato di queste risorse, è possibile che qualsiasi modifica apportata a una risorsa gestita dall' SageMaker IA possa essere aggiornata e sovrascritta dal servizio.
Le seguenti informazioni descrivono le impostazioni di configurazione utilizzate dal componente aggiuntivo Task Governance per configurare Kueue. HyperPod
```
apiVersion: config.kueue.x-k8s.io/v1beta1
kind: Configuration
health:
healthProbeBindAddress: :8081
metrics:
bindAddress: :8443
enableClusterQueueResources: true
webhook:
port: 9443
manageJobsWithoutQueueName: false
leaderElection:
leaderElect: true
resourceName: c1f6bfd2.kueue.x-k8s.io
controller:
groupKindConcurrency:
Job.batch: 5
Pod: 5
Workload.kueue.x-k8s.io: 5
LocalQueue.kueue.x-k8s.io: 1
ClusterQueue.kueue.x-k8s.io: 1
ResourceFlavor.kueue.x-k8s.io: 1
clientConnection:
qps: 50
burst: 100
integrations:
frameworks:
- "batch/job"
- "kubeflow.org/mpijob"
- "ray.io/rayjob"
- "ray.io/raycluster"
- "jobset.x-k8s.io/jobset"
- "kubeflow.org/mxjob"
- "kubeflow.org/paddlejob"
- "kubeflow.org/pytorchjob"
- "kubeflow.org/tfjob"
- "kubeflow.org/xgboostjob"
- "pod"
- "deployment"
- "statefulset"
- "leaderworkerset.x-k8s.io/leaderworkerset"
podOptions:
namespaceSelector:
matchExpressions:
- key: kubernetes.io/metadata.name
operator: NotIn
values: [ kube-system, kueue-system ]
fairSharing:
enable: true
preemptionStrategies: [LessThanOrEqualToFinalShare, LessThanInitialShare]
resources:
excludeResourcePrefixes: []
```
Per ulteriori informazioni su ogni voce di configurazione, consulta [Configurazione](https://kueue.sigs.k8s.io/docs/reference/kueue-config.v1beta1/#Configuration) nella documentazione di Kueue.
## HyperPod Prerequisiti per la governance delle attività
+ Assicurati di disporre della politica di autorizzazione minima per gli amministratori HyperPod del cluster, in. [Utenti IAM per l’amministratore del cluster](sagemaker-hyperpod-prerequisites-iam.md#sagemaker-hyperpod-prerequisites-iam-cluster-admin) Ciò include le autorizzazioni per eseguire il SageMaker HyperPod core APIs, gestire SageMaker HyperPod i cluster al suo interno ed eseguire Account AWS le attività in. [Gestione dei SageMaker HyperPod cluster orchestrati da Amazon EKS](sagemaker-hyperpod-eks-operate.md)
+ La versione di Kubernetes dovrà essere >= 1.30. Per istruzioni, consulta [Update existing clusters to the new Kubernetes version](https://docs.aws.amazon.com/eks/latest/userguide/update-cluster.html).
+ Se hai già installato Kueue nei cluster, disinstalla Kueue prima di installare il componente aggiuntivo EKS.
+ Un HyperPod nodo deve già esistere nel cluster EKS prima di installare il componente aggiuntivo per la governance delle HyperPod attività.
## HyperPod configurazione della governance delle attività
Di seguito vengono fornite informazioni su come impostare la governance delle HyperPod attività.
------
#### [ Setup using the SageMaker AI console ]
Di seguito vengono fornite informazioni su come configurare la governance delle HyperPod attività utilizzando la SageMaker HyperPod console.
Hai già tutte le seguenti autorizzazioni allegate se hai già concesso le autorizzazioni per gestire Amazon CloudWatch Observability EKS e visualizzare il dashboard del HyperPod cluster tramite la console SageMaker AI in. [HyperPod Configurazione del componente aggiuntivo Amazon CloudWatch Observability EKS](sagemaker-hyperpod-eks-operate-console-ui-governance-setup-dashboard.md#hp-eks-dashboard-setup) Se non l'hai configurata, utilizza la politica di esempio riportata di seguito per concedere le autorizzazioni per gestire il componente aggiuntivo HyperPod Task Governance e visualizzare la dashboard del HyperPod cluster tramite la console AI. SageMaker
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"eks:ListAddons",
"eks:CreateAddon",
"eks:UpdateAddon",
"eks:DescribeAddon",
"eks:DescribeAddonVersions",
"sagemaker:DescribeCluster",
"sagemaker:DescribeClusterNode",
"sagemaker:ListClusterNodes",
"sagemaker:ListClusters",
"eks:DescribeCluster",
"eks:AccessKubernetesApi"
],
"Resource": "*"
}
]
}
```
------
Vai alla scheda **Dashboard** nella SageMaker HyperPod console per installare il componente aggiuntivo Amazon SageMaker HyperPod Task Governance.
------
#### [ Setup using the Amazon EKS AWS CLI ]
Utilizza il AWS CLI comando [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/eks/create-addon.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/eks/create-addon.html)EKS di esempio per configurare l'API Amazon EKS di HyperPod task governance e l'interfaccia utente della console utilizzando AWS CLI:
```
aws eks create-addon --region region --cluster-name cluster-name --addon-name amazon-sagemaker-hyperpod-taskgovernance
```
------
Puoi visualizzare la scheda **Policies** nella console HyperPod SageMaker AI se l'installazione è andata a buon fine. È inoltre possibile utilizzare il seguente AWS CLI comando [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/eks/describe-addon.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/eks/describe-addon.html)EKS di esempio per verificare lo stato.
```
aws eks describe-addon --region region --cluster-name cluster-name --addon-name amazon-sagemaker-hyperpod-taskgovernance
```
# Pannello di controllo
Amazon SageMaker HyperPod Task Governance offre una panoramica completa dei parametri di utilizzo dei cluster Amazon EKS, inclusi i parametri relativi all'hardware, al team e alle attività. Di seguito vengono fornite informazioni sulla dashboard del cluster HyperPod EKS.
La dashboard offre una visione completa delle metriche di utilizzo del cluster, incluse le metriche relative all’hardware, al team e alle attività. È necessario installare il componente aggiuntivo EKS per visualizzare la dashboard. Per ulteriori informazioni, consulta [Configurazione della dashboard](sagemaker-hyperpod-eks-operate-console-ui-governance-setup-dashboard.md).
Nella [console Amazon SageMaker AI](https://console.aws.amazon.com/sagemaker/), in **HyperPod Clusters**, puoi accedere alla HyperPod console e visualizzare l'elenco dei HyperPod cluster nella tua regione. Scegli il cluster e vai alla scheda **Dashboard**. La dashboard contiene le seguenti metriche. Puoi scaricare i dati per una sezione scegliendo la voce **Esporta** corrispondente.
**Utilizzo**
Fornisce lo stato del cluster EKS point-in-time e metriche basate sulle tendenze per le risorse di elaborazione critiche. Per impostazione predefinita, vengono visualizzati **tutti i gruppi di istanze**. Utilizza il menu a discesa per filtrare i gruppi di istanze. Le metriche incluse in questa sezione sono:
+ Numero di istanze totali, in esecuzione e con ripristino in sospeso. Il numero di istanze con ripristino in sospeso si riferisce al numero di istanze attendono di essere sottoposte a ripristino.
+ GPUs, memoria GPU, memoria v e v. CPUs CPUs
+ Utilizzo della GPU, utilizzo della memoria GPU, utilizzo della vCPU e utilizzo della memoria vCPU.
+ Un grafico interattivo dell’utilizzo di GPU e vCPU.
**Team**
Fornisce informazioni sulla gestione delle risorse specifica del team. Questo include:
+ Allocazione di istanze e GPU.
+ Tassi di utilizzo della GPU.
+ Statistiche sulla GPU prese in prestito.
+ Stato dell’attività (in esecuzione o in sospeso).
+ Un grafico a barre che confronta l’utilizzo della GPU e l’allocazione delle risorse di calcolo tra i team.
+ Informazioni dettagliate su GPU e vCPU del team. Per impostazione predefinita, le informazioni visualizzate includono **Tutti i team**. Puoi filtrare per team e istanza scegliendo i menu a discesa. Nel grafico interattivo puoi filtrare per ora.
**Attività**
**Nota**
Per visualizzare le attività del cluster HyperPod EKS nella dashboard:
Configura Kubernetes Role-Based Access Control (RBAC) per gli utenti di data scientist nello spazio dei HyperPod nomi designato per autorizzare l'esecuzione delle attività su cluster orchestrati da Amazon EKS. I namespace adottano il formato `hyperpod-ns-team-name`. Per stabilire le autorizzazioni RBAC, consulta le [istruzioni per la creazione dei ruoli del team](https://github.com/aws/sagemaker-hyperpod-cli/tree/main/helm_chart#5-create-team-role).
Verifica che il tuo processo sia venga inviato con il namespace e le etichette delle classi di priorità appropriati. Per un esempio completo, consulta [Invia un lavoro alla coda e allo SageMaker spazio dei nomi gestiti dall'intelligenza artificiale](sagemaker-hyperpod-eks-operate-console-ui-governance-cli.md#hp-eks-cli-start-job).
Fornisce informazioni sulle metriche relative alle attività. Questo include il numero di attività in esecuzione, in sospeso e prerilasciate, oltre alle statistiche sui tempi di esecuzione e attesa. Per impostazione predefinita, le informazioni visualizzate includono **Tutti i team**. Puoi filtrare per team selezionando il menu a discesa. Nel grafico interattivo puoi filtrare per ora.
# Processi
Di seguito vengono fornite informazioni sulle attività del cluster Amazon SageMaker HyperPod EKS. Le attività sono operazioni o processi che vengono inviati al cluster. Queste possono essere operazioni di machine learning, come addestramento, esecuzione di esperimenti o inferenza. L’elenco dei dettagli delle attività visualizzabili include lo stato, la durata di esecuzione e la quantità di calcolo utilizzata per ogni attività.
Nella [console Amazon SageMaker AI](https://console.aws.amazon.com/sagemaker/), in **HyperPod Clusters**, puoi accedere alla HyperPod console e visualizzare l'elenco dei HyperPod cluster nella tua regione. Scegli il tuo cluster e vai alla scheda **Attività**.
Per rendere visibile a tutti la scheda **Attività**, e non solo all’amministratore, l’amministratore deve [aggiungere una voce di accesso al cluster EKS per il ruolo IAM](https://docs.aws.amazon.com/eks/latest/userguide/access-entries.html).
**Nota**
Per visualizzare le attività del cluster HyperPod EKS nella dashboard:
Configura Kubernetes Role-Based Access Control (RBAC) per gli utenti di data scientist nello spazio dei HyperPod nomi designato per autorizzare l'esecuzione delle attività su cluster orchestrati da Amazon EKS. I namespace adottano il formato `hyperpod-ns-team-name`. Per stabilire le autorizzazioni RBAC, consulta le [istruzioni per la creazione dei ruoli del team](https://github.com/aws/sagemaker-hyperpod-cli/tree/main/helm_chart#5-create-team-role).
Verifica che il tuo processo sia venga inviato con il namespace e le etichette delle classi di priorità appropriati. Per un esempio completo, consulta [Invia un lavoro alla coda e allo SageMaker spazio dei nomi gestiti dall'intelligenza artificiale](sagemaker-hyperpod-eks-operate-console-ui-governance-cli.md#hp-eks-cli-start-job).
Per i cluster EKS, TensorFlow vengono mostrate le attività kubeflow (PyTorch, MPI,). Per impostazione predefinita, PyTorch vengono visualizzate le attività. Puoi filtrare per PyTorch TensorFlow attività MPI scegliendo il menu a discesa o utilizzando il campo di ricerca. Le informazioni mostrate per ogni attività includono il nome dell’attività, lo stato, il namespace, la classe di priorità e l’ora di creazione.
# Utilizzo della pianificazione basata sulla topologia nella governance delle attività di Amazon SageMaker HyperPod
La pianificazione basata sulla topologia in SageMaker HyperPod Amazon Task Governance ottimizza l'efficienza di formazione dei carichi di lavoro di machine learning distribuiti posizionando pod basati sulla topologia di rete fisica delle istanze Amazon EC2. Considerando la struttura gerarchica dell' AWS infrastruttura, tra cui zone di disponibilità, blocchi di rete e rack fisici, la pianificazione basata sulla topologia garantisce che i pod che richiedono comunicazioni frequenti siano pianificati in prossimità per ridurre al minimo la latenza di rete. Questo posizionamento intelligente è particolarmente utile per i lavori di formazione sull'apprendimento automatico su larga scala che implicano una pod-to-pod comunicazione intensiva, con conseguente riduzione dei tempi di formazione e un utilizzo più efficiente delle risorse in tutto il cluster.
**Nota**
Per utilizzare la pianificazione basata sulla topologia, assicurati che la tua versione di HyperPod task governance sia la v1.2.2-eksbuild.1 o successiva.
La pianificazione basata sulla topologia supporta i tipi di istanze seguenti:
+ ml.p3dn.24xlarge
+ ml.p4d.24xlarge
+ ml.p4de.24xlarge
+ ml.p5.48xlarge
+ ml.p5e.48xlarge
+ ml.p5en.48xlarge
+ ml.p6e-gb200.36xlarge
+ ml.trn1.2xlarge
+ ml.trn1.32xlarge
+ ml.trn1n.32xlarge
+ ml.trn2.48xlarge
+ ml.trn2u.48xlarge
La pianificazione basata sulla topologia si integra con i HyperPod flussi di lavoro esistenti fornendo al contempo preferenze di topologia flessibili tramite i file Kubectl YAML e la CLI. HyperPod HyperPod la governance delle attività configura automaticamente i nodi del cluster con etichette di topologia e funziona con le politiche di governance delle HyperPod attività e i meccanismi di prestito delle risorse, garantendo che la pianificazione basata sulla topologia non interrompa i processi operativi correnti. Grazie al supporto integrato per le specifiche di topologia preferite e richieste, puoi eseguire il fine-tuning del posizionamento dei carichi di lavoro in base a specifici requisiti delle prestazioni, mantenendo al contempo la flessibilità necessaria per tornare alla pianificazione standard se i vincoli della topologia non possono essere soddisfatti.
Sfruttando le etichette con riconoscimento della topologia HyperPod, è possibile potenziare i carichi di lavoro di machine learning di tali dispositivi mediante un posizionamento intelligente dei pod che tiene conto dell'infrastruttura fisica di rete. HyperPod la governance delle attività ottimizza automaticamente la pianificazione dei pod in base alla topologia gerarchica del data center, il che si traduce direttamente in una riduzione della latenza di rete e in migliori prestazioni di formazione per le attività di machine learning distribuite. La consapevolezza della topologia è particolarmente utile per carichi di lavoro di machine learning su larga scala, perché riduce al minimo il sovraccarico di comunicazione avvicinando strategicamente i pod correlati all’interno della gerarchia di rete. Il risultato è una latenza della rete di comunicazione ottimizzata tra i pod, un utilizzo più efficiente delle risorse e migliori prestazioni complessive per le AI/ML applicazioni a elaborazione intensiva, il tutto senza la necessità di gestire manualmente configurazioni di topologia di rete complesse.
Di seguito sono riportate le etichette per i livelli di rete topologici disponibili in cui Task Governance può pianificare i pod: HyperPod
+ topology.k8s.aws/ -1 network-node-layer
+ network-node-layertopologia.k8s.aws/ -2
+ network-node-layertopologia.k8s.aws/ -3
+ topology.k8s.aws/ultraserver-id
Per utilizzare la pianificazione basata sulla topologia, includi le etichette seguenti nel tuo file YAML:
+ kueue.x-k8s.io/ podset-required-topology - indica che questo lavoro deve avere i pod richiesti e che tutti i pod nei nodi devono essere programmati all'interno dello stesso livello di topologia.
+ kueue.x-k8s.io/ podset-preferred-topology - indica che questo job deve avere i pod, ma che la pianificazione dei pod all'interno dello stesso livello di topologia è preferibile ma non obbligatoria. HyperPod task governance proverà a pianificare i pod all'interno di un livello prima di provare il livello di topologia successivo.
Se le risorse non condividono la stessa etichetta di topologia, il processo viene sospeso. Il processo viene inserito in lista d’attesa. Quando Kueue rileva una quantità di risorse sufficiente, accetta ed esegue processo.
L’esempio seguente illustra come utilizzare le etichette nei file YAML:
```
apiVersion: batch/v1
kind: Job
metadata:
name: test-tas-job
namespace: hyperpod-ns-team-name
labels:
kueue.x-k8s.io/queue-name: hyperpod-ns-team-name-localqueue
kueue.x-k8s.io/priority-class: PRIORITY_CLASS-priority
spec:
parallelism: 10
completions: 10
suspend: true
template:
metadata:
labels:
kueue.x-k8s.io/queue-name: hyperpod-ns-team-name-localqueue
annotations:
kueue.x-k8s.io/podset-required-topology: "topology.k8s.aws/network-node-layer-3"
or
kueue.x-k8s.io/podset-preferred-topology: "topology.k8s.aws/network-node-layer-3"
spec:
nodeSelector:
topology.k8s.aws/network-node-layer-3: TOPOLOGY_LABEL_VALUE
containers:
- name: dummy-job
image: gcr.io/k8s-staging-perf-tests/sleep:v0.1.0
args: ["3600s"]
resources:
requests:
cpu: "100"
restartPolicy: Never
```
La tabella seguente spiega i nuovi parametri che puoi utilizzare nel file YAML kubectl.
| Parametro | Description |
| --- | --- |
| kueue.x-k8s.io/queue-name | Il nome della coda da utilizzare per eseguire il processo. Il formato di queue-name deve essere hyperpod-ns-team-name-localqueue. |
| kueue.x-k8s.io/priority-class | Consente di specificare una priorità per la pianificazione dei pod. Questa specifica è facoltativa. |
| annotations | Contiene l’annotazione della topologia collegata al processo. Le topologie disponibili sono kueue.x-k8s.io/ e podset-required-topologykueue.x-k8s.io/. podset-preferred-topology Puoi utilizzare un’annotazione o nodeSelector, ma non entrambi contemporaneamente. |
| nodeSelector | Specifica il livello di rete che rappresenta il livello di posizionamento delle istanze Amazon EC2. Utilizza questo campo o un’annotazione, ma non entrambi contemporaneamente. Nel file YAML, puoi anche utilizzare il parametro nodeSelector per scegliere il livello esatto per i tuoi pod. Per ottenere il valore della tua etichetta, usa l'operazione API. [ DescribeInstanceTopology](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeInstanceTopology.html) |
Puoi anche utilizzare la HyperPod CLI per eseguire il tuo lavoro e utilizzare la pianificazione basata sulla topologia. Per ulteriori informazioni sulla HyperPod CLI, vedere. [SageMaker HyperPod Comandi CLI](sagemaker-hyperpod-eks-hyperpod-cli-reference.md)
```
hyp create hyp-pytorch-job \
--version 1.1 \
--job-name sample-pytorch-job \
--image 123456789012.dkr.ecr.us-west-2.amazonaws.com/ptjob:latest \
--pull-policy "Always" \
--tasks-per-node 1 \
--max-retry 1 \
--priority high-priority \
--namespace hyperpod-ns-team-name \
--queue-name hyperpod-ns-team-name-localqueue \
--preferred-topology-label topology.k8s.aws/network-node-layer-1
```
Di seguito è riportato un esempio di file di configurazione che è possibile utilizzare per eseguire un file PytorchJob con etichette di topologia. Se desideri eseguire processi MPI e TensorFlow, il file è sostanzialmente uguale. Se invece desiderate eseguire questi lavori, ricordatevi di modificare il file di configurazione di conseguenza, ad esempio utilizzando l'immagine corretta anziché PyTorchJob. Se stai eseguendo un PyTorchJob, puoi assegnare topologie diverse ai nodi master e worker. PyTorchJob ha sempre un nodo master, quindi ti consigliamo di utilizzare invece la topologia per supportare i worker pod.
```
apiVersion: kubeflow.org/v1
kind: PyTorchJob
metadata:
annotations: {}
labels:
kueue.x-k8s.io/queue-name: hyperpod-ns-team-name-localqueue
name: tas-test-pytorch-job
namespace: hyperpod-ns-team-name
spec:
pytorchReplicaSpecs:
Master:
replicas: 1
restartPolicy: OnFailure
template:
metadata:
labels:
kueue.x-k8s.io/queue-name: hyperpod-ns-team-name-localqueue
spec:
containers:
- command:
- python3
- /opt/pytorch-mnist/mnist.py
- --epochs=1
image: docker.io/kubeflowkatib/pytorch-mnist:v1beta1-45c5727
imagePullPolicy: Always
name: pytorch
Worker:
replicas: 10
restartPolicy: OnFailure
template:
metadata:
# annotations:
# kueue.x-k8s.io/podset-required-topology: "topology.k8s.aws/network-node-layer-3"
labels:
kueue.x-k8s.io/queue-name: hyperpod-ns-team-name-localqueue
spec:
containers:
- command:
- python3
- /opt/pytorch-mnist/mnist.py
- --epochs=1
image: docker.io/kubeflowkatib/pytorch-mnist:v1beta1-45c5727
imagePullPolicy: Always
name: pytorch
resources:
limits:
cpu: 1
requests:
memory: 200Mi
cpu: 1
#nodeSelector:
# topology.k8s.aws/network-node-layer-3: xxxxxxxxxxx
```
Per visualizzare le topologie per il tuo cluster, utilizza l'[ DescribeInstanceTopology](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeInstanceTopology.html)operazione API. Per impostazione predefinita, le topologie sono nascoste in Console di gestione AWS e Amazon SageMaker Studio. Segui questa procedura per visualizzarle nell’interfaccia che stai utilizzando.
**SageMaker Studio**
1. In SageMaker Studio, accedi al tuo cluster.
1. Nella visualizzazione Attività, scegli il menu delle opzioni nella colonna Nome, quindi scegli **Gestisci colonne**.
1. Seleziona **Topologia richiesta** e **Vincolo di topologia** per aggiungere le colonne per visualizzare le informazioni sulla topologia nell’elenco dei pod Kubernetes.
**Console di gestione AWS**
1. Apri la console Amazon SageMaker AI all'indirizzo [https://console.aws.amazon.com/sagemaker/](https://console.aws.amazon.com/sagemaker/).
1. In **HyperPod Cluster**, scegli **Cluster management**.
1. Scegli la scheda **Attività**, quindi scegli l’icona a forma di ingranaggio.
1. Negli attributi dell’istanza, attiva **Topologia richiesta** e **Vincolo di topologia**.
1. Scegli **Conferma** per visualizzare le informazioni sulla topologia nella tabella.
# Policy
La governance delle SageMaker HyperPod attività di Amazon semplifica l'allocazione delle risorse del cluster Amazon EKS e l'assegnazione delle priorità alle attività. Di seguito vengono fornite informazioni sulle HyperPod politiche dei cluster EKS. Per informazioni su come configurare la governance delle attività, consulta [Configurazione della governance delle attività](sagemaker-hyperpod-eks-operate-console-ui-governance-setup-task-governance.md).
Le policy sono suddivise in **Priorità delle risorse di calcolo** e **Allocazione delle risorse di calcolo** I concetti delle policy seguenti vengono organizzati nel contesto di tali policy.
La **priorità delle risorse di calcolo**, o policy del cluster, determina in che modo le risorse di calcolo inattive vengono presa in prestito e in che modo i team assegnano priorità alle attività.
+ **Allocazione delle risorse di calcolo inattive** definisce in che modo le risorse di calcolo inattive vengono allocate tra i team. In altre parole, definisce in che modo le risorse di calcolo inutilizzate possono essere prese in prestito dai team. Quando selezioni **Allocazione delle risorse di calcolo inattive**, puoi scegliere tra:
+ **Primo arrivato, primo servito**: se applicata, questa opzione non assegna priorità ai team e ogni attività in arrivo ha la stessa probabilità di ottenere risorse oltre la quota stabilita. Alle attività viene assegnata una priorità in base all’ordine di invio. Ciò significa che un utente potrebbe utilizzare il 100% delle risorse di calcolo inattive se le richiede per primo.
+ **Condivisione equa**: quando viene applicata, i team prendono in prestito risorse di calcolo inattive in base al **Peso di condivisione equa** loro assegnato. Questi pesi sono definiti in **Allocazione delle risorse di calcolo**. Per ulteriori informazioni su come utilizzare questa opzione, consulta [Esempi di condivisione di risorse di calcolo inattive](#hp-eks-task-governance-policies-examples).
+ La **prioritizzazione delle attività** definisce il modo in cui le attività vengono messe in coda non appena il calcolo diventa disponibile. Quando scegli una **prioritizzazione delle attività**, puoi scegliere tra:
+ **Primo arrivato, primo servito**: se viene applicata questa opzione, le attività vengono messe in coda nell’ordine in cui sono state richieste.
+ **Classificazione delle attività**: se viene applicata questa opzione, le attività vengono messe in coda nell’ordine definito dalla loro priorità. Se scegli questa opzione, devi aggiungere le classi di priorità e i pesi in base ai quali viene assegnata la priorità. Le attività della stessa classe di priorità vengono eseguite in base al principio “primo arrivato, primo servito”. Se l’opzione è abilitata in Allocazione delle risorse di calcolo, le attività con priorità più bassa vengono sostituite dalle attività con priorità più alta all’interno del team.
Quando i Data Scientist inviano i processi al cluster, utilizzano il nome della classe di priorità nel file YAML. La classe di priorità è nel formato `priority-class-name-priority`. Per vedere un esempio, consulta [Invia un lavoro alla coda e allo SageMaker spazio dei nomi gestiti dall'intelligenza artificiale](sagemaker-hyperpod-eks-operate-console-ui-governance-cli.md#hp-eks-cli-start-job).
+ **Classi di priorità**: queste classi stabiliscono una priorità relativa per le attività quando prendono in prestito quote di capacità. Quando un’attività viene eseguita utilizzando una quota presa in prestito, può essere interrotta da un’altra attività con priorità più elevata, se la capacità disponibile per l’attività in entrata è terminata. Se **Prelazione** è abilitato in **Allocazione delle risorse di calcolo**, un’attività con priorità più elevata può anche interrompere altre attività all’interno del proprio team.
+ La **condivisione delle risorse non allocate** consente ai team di prendere in prestito risorse di elaborazione che non sono assegnate a nessun team tramite la quota di elaborazione. Se abilitata, la capacità del cluster non allocata diventa disponibile per i team che possono prenderla in prestito automaticamente. Per ulteriori informazioni, consulta [Come funziona la condivisione delle risorse non allocate](#sagemaker-hyperpod-eks-operate-console-ui-governance-policies-idle-resource-sharing-how-it-works).
L’**Allocazione delle risorse di calcolo**, o quota di calcolo, definisce l’allocazione delle risorse di calcolo di un team e il peso (o il livello di priorità) assegnato a un team per un’allocazione equa delle risorse di calcolo inattive.
+ **Nome del team**: il nome del team. Viene creato un **Namespace** corrispondente, di tipo `hyperpod-ns-team-name`.
+ **Membri**: i membri del namespace del team. Dovrai configurare un controllo degli accessi basato sui ruoli (RBAC) Kubernetes per gli utenti di data scientist che desideri far parte di questo team, per eseguire attività su cluster orchestrati con Amazon EKS. HyperPod Per configurare un RBAC Kubernetes, utilizza le istruzioni in [create team role](https://github.com/aws/sagemaker-hyperpod-cli/tree/main/helm_chart#5-create-team-role).
+ **Peso di condivisione equa**: si tratta del livello di priorità assegnato al team quando viene applicata la **Condivisione equa** per l’opzione **Allocazione delle risorse di calcolo inattive**. La priorità più alta ha un peso di 100, mentre quella più bassa è 0. Un peso maggiore consente a un team di accedere più rapidamente alle risorse inutilizzate all’interno della capacità condivisa. Un peso zero indica la priorità più bassa, che significa che il team sarà sempre in svantaggio rispetto agli altri team.
Il peso di condivisione equa offre un margine di vantaggio al team quando compete con altri team per le risorse disponibili. L’ammissione dà priorità alla pianificazione delle attività svolte dai team con i pesi più alti e il minor numero di risorse prese in prestito. Ad esempio, se il Team A ha un peso di 10 e il Team B ha un peso di 5, il Team A avrebbe un accesso prioritario alle risorse inutilizzate, perché ha processi pianificati prima del Team B.
+ **Prelazione delle attività**: le risorse di calcolo vengono prese da un’attività in base alla priorità. Per impostazione predefinita, il team che presta le risorse di calcolo inattive avrà la prelazione rispetto alle attività degli altri team.
+ **Prestare e prendere in prestito**: definisce in che modo il team presta le risorse di calcolo inattive e specifica se il team può prendere in prestito risorse da altri team.
+ Limite di **prestito basato sulla percentuale: il limite** di elaborazione inattiva che un team può prendere in prestito, espresso come percentuale della quota garantita. Un team può prendere in prestito fino al 10.000% delle risorse di calcolo allocate. Il valore fornito qui viene interpretato come percentuale. Ad esempio, un valore pari a 500 verrà interpretato come 500%. Questa percentuale si applica in modo uniforme a tutti i tipi di risorse (CPU, GPU, memoria) e ai tipi di istanze inclusi nella quota del team.
+ **Limite assoluto di prestito**: il limite di elaborazione inattiva che un team può prendere in prestito, definito come valori assoluti delle risorse per tipo di istanza. Ciò fornisce un controllo granulare sul comportamento di prestito per tipi di istanze specifici. È necessario specificare i limiti assoluti utilizzando lo stesso schema di **Compute Quota, incluso il conteggio** delle istanze, gli acceleratori, la vCPU, la memoria o le partizioni di accelerazione. Puoi specificare limiti assoluti per uno o più tipi di istanze nella quota del tuo team.
Per informazioni su come vengono utilizzati i concetti come le classi di priorità e i namespace, consulta [Esempi di comandi di governance delle HyperPod AWS CLI attività](sagemaker-hyperpod-eks-operate-console-ui-governance-cli.md).
## Esempi di condivisione di risorse di calcolo inattive
La quota totale riservata non deve superare la capacità disponibile del cluster per quella risorsa, al fine di garantire una corretta gestione delle quote. Ad esempio, se un cluster comprende 20 istanze `ml.c5.2xlarge`, la quota cumulativa assegnata ai team dovrebbe rimanere inferiore a 20.
Se le policy **Allocazione delle risorse di calcolo** per i team consentono **Presta e prendi in prestito** o **Presta**, la capacità inattiva viene condivisa tra questi team. Ad esempio, il Team A e il Team B hanno abilitato **Presta e prendi in prestito**. Il Team A ha una quota pari a 6, ma utilizza solo 2 risorse per i processi, mentre il Team B ha una quota pari a 5 e utilizza 4 risorse. Un processo inviato al Team B richiede 4 risorse, quindi il Team B prenderà in prestito 3 risorse dal Team A.
Se la policy **Allocazione delle risorse di calcolo** di un team è impostata su **Non prestare**, il team non potrà prendere in prestito alcuna capacità aggiuntiva oltre alle proprie allocazioni.
## Come funziona la condivisione delle risorse non allocate
La condivisione delle risorse non allocate gestisce automaticamente il pool di risorse che non sono allocate a nessuna quota di elaborazione nel cluster. Ciò significa che monitora HyperPod continuamente lo stato del cluster e si aggiorna automaticamente alla configurazione corretta nel tempo.
**Configurazione iniziale**
+ Quando l'impostazione è impostata su `Enabled` in your ClusterSchedulerConfig (`IdleResourceSharing`per impostazione predefinita`Disabled`), la governance delle HyperPod attività inizia a monitorare il cluster e calcola le risorse inattive disponibili sottraendo le quote del team dalla capacità totale dei nodi.
+ La condivisione non allocata delle risorse viene creata per rappresentare il pool di risorse che ClusterQueues possono essere prese in prestito.
+ Quando si abilita per la prima volta la condivisione di risorse non allocate, la configurazione dell'infrastruttura richiede diversi minuti. È possibile monitorare i progressi tramite policy `Status` e in. `DetailedStatus` ClusterSchedulerConfig
**Riconciliazione in corso**
+ HyperPod la governance delle attività monitora continuamente le modifiche, come l'aggiunta o la rimozione di nodi e gli aggiornamenti delle quote delle code dei cluster.
+ Quando si verificano modifiche, la condivisione delle risorse non allocate ricalcola la quota e gli aggiornamenti. ClusterQueues La riconciliazione viene in genere completata in pochi secondi.
**Monitoraggio**
Puoi verificare che la condivisione delle risorse non allocate sia completamente configurata controllando la condivisione delle risorse non allocate: ClusterQueues
```
kubectl get clusterqueue | grep hyperpod-ns-idle-resource-sharing
```
Quando vedi ClusterQueues con nomi come`hyperpod-ns-idle-resource-sharing-cq-1`, la condivisione delle risorse non allocate è attiva. Tieni presente che ClusterQueues possono esistere più condivisioni di risorse non allocate a seconda del numero di tipi di risorse presenti nel cluster.
## Idoneità dei nodi per la condivisione di risorse non allocate
La condivisione delle risorse non allocate include solo i nodi che soddisfano i seguenti requisiti:
1. **Stato Node Ready**
+ I nodi devono essere in `Ready` stato per poter contribuire al pool di risorse non allocate.
+ I nodi in stato non pronto `NotReady` o in altri stati non pronti sono esclusi dai calcoli della capacità.
+ Quando un nodo diventa`Ready`, viene automaticamente incluso nel ciclo di riconciliazione successivo.
1. **Stato programmabile del nodo**
+ I nodi con `spec.unschedulable: true` sono esclusi dalla condivisione di risorse non allocate.
+ Quando un nodo torna a essere programmabile, viene automaticamente incluso nel ciclo di riconciliazione successivo.
1. **Configurazione MIG (solo nodi GPU)**
+ Per i nodi GPU con partizionamento MIG (Multi-Instance GPU), l'`nvidia.com/mig.config.state`etichetta deve indicare che il nodo contribuisce con i profili MIG alla condivisione `success` di risorse non allocate.
+ Questi nodi verranno riprovati automaticamente una volta completata correttamente la configurazione MIG.
1. **Tipi di istanze supportati**
+ L'istanza deve essere un tipo di SageMaker HyperPod istanza supportato.
+ Vedi l'elenco dei tipi di istanza supportati nel SageMaker HyperPod cluster.
**Topics**
+ [Esempi di condivisione di risorse di calcolo inattive](#hp-eks-task-governance-policies-examples)
+ [Come funziona la condivisione delle risorse non allocate](#sagemaker-hyperpod-eks-operate-console-ui-governance-policies-idle-resource-sharing-how-it-works)
+ [Idoneità dei nodi per la condivisione di risorse non allocate](#sagemaker-hyperpod-eks-operate-console-ui-governance-policies-idle-resource-sharing-node-eligibility)
+ [Creazione di policy](sagemaker-hyperpod-eks-operate-console-ui-governance-policies-create.md)
+ [Modifica delle policy](sagemaker-hyperpod-eks-operate-console-ui-governance-policies-edit.md)
+ [Eliminazione delle policy](sagemaker-hyperpod-eks-operate-console-ui-governance-policies-delete.md)
+ [Allocazione della quota di elaborazione nella governance delle attività di Amazon SageMaker HyperPod](sagemaker-hyperpod-eks-operate-console-ui-governance-policies-compute-allocation.md)
# Creazione di policy
Puoi creare le configurazioni **Policy del cluster** e **Allocazione delle risorse di calcolo** nella scheda **Policy**. Di seguito vengono fornite istruzioni su come creare le configurazioni seguenti.
+ Crea la tua **Policy del cluster** per aggiornare il modo in cui viene assegnata la priorità alle attività e vengono allocate le risorse di calcolo inattive.
+ Crea un’**Allocazione delle risorse di calcolo** per creare una nuova policy di allocazione delle risorse di calcolo per un team.
**Nota**
Quando crei un'**allocazione Compute**, dovrai configurare un controllo degli accessi basato sui ruoli (RBAC) Kubernetes per gli utenti di data scientist nel namespace corrispondente per eseguire attività su cluster orchestrati con Amazon EKS. HyperPod I namespace adottano il formato `hyperpod-ns-team-name`. Per configurare un RBAC Kubernetes, utilizza le istruzioni in [create team role](https://github.com/aws/sagemaker-hyperpod-cli/tree/main/helm_chart#5-create-team-role).
Per informazioni sui concetti della [Policy](sagemaker-hyperpod-eks-operate-console-ui-governance-policies.md) politica dei cluster EKS per la governance dei task, consulta. HyperPod
**Creare politiche di governance delle HyperPod attività**
Questa procedura presuppone che tu abbia già creato un cluster Amazon EKS configurato con HyperPod. Se non l’hai ancora fatto, consulta [Creazione di un SageMaker HyperPod cluster con l'orchestrazione di Amazon EKS](sagemaker-hyperpod-eks-operate-console-ui-create-cluster.md).
1. Passa alla [console Amazon SageMaker AI](https://console.aws.amazon.com/sagemaker/).
1. Nel riquadro di navigazione a sinistra, in **HyperPodClusters**, scegli **Cluster Management**.
1. Scegli il tuo cluster Amazon EKS elencato tra **SageMaker HyperPodi cluster.**
1. Scegliere la scheda **Policy**.
1. Per creare la **Policy del cluster**:
1. Scegli **Modifica** per aggiornare il modo in cui viene assegnata la priorità alle attività e vengono allocate le risorse di calcolo inattive.
1. Dopo avere apportato le modifiche, scegli **Invia**.
1. Per creare un’**Allocazione delle risorse di calcolo**:
1.
1. Scegli l’opzione **Crea** corrispondente. Viene visualizzata la pagina per creare un’allocazione delle risorse di calcolo.
1. Dopo avere apportato le modifiche, scegli **Invia**.
# Modifica delle policy
Puoi modificare le configurazioni **Policy del cluster** e **Allocazione delle risorse di calcolo** nella scheda **Policy**. Di seguito vengono fornite istruzioni su come modificare le configurazioni seguenti.
+ Modifica **Policy del cluster** per aggiornare il modo in cui viene assegnata la priorità alle attività e vengono allocate le risorse di calcolo inattive.
+ Modifica **Allocazione delle risorse di calcolo** per creare una nuova policy di allocazione delle risorse di calcolo per un team.
**Nota**
Quando crei un'**allocazione Compute**, dovrai configurare un controllo degli accessi basato sui ruoli (RBAC) Kubernetes per gli utenti di data scientist nel namespace corrispondente per eseguire attività su cluster orchestrati con Amazon EKS. HyperPod I namespace adottano il formato `hyperpod-ns-team-name`. Per configurare un RBAC Kubernetes, utilizza le istruzioni in [create team role](https://github.com/aws/sagemaker-hyperpod-cli/tree/main/helm_chart#5-create-team-role).
Per ulteriori informazioni sui concetti della politica dei cluster EKS per la governance dei task, consulta. HyperPod [Policy](sagemaker-hyperpod-eks-operate-console-ui-governance-policies.md)
**Modifica le politiche di governance delle HyperPod attività**
Questa procedura presuppone che tu abbia già creato un cluster Amazon EKS configurato con HyperPod. Se non l’hai ancora fatto, consulta [Creazione di un SageMaker HyperPod cluster con l'orchestrazione di Amazon EKS](sagemaker-hyperpod-eks-operate-console-ui-create-cluster.md).
1. Passa alla [console Amazon SageMaker AI](https://console.aws.amazon.com/sagemaker/).
1. Nel riquadro di navigazione a sinistra, in **HyperPodClusters**, scegli **Cluster Management**.
1. Scegli il tuo cluster Amazon EKS elencato tra **SageMaker HyperPodi cluster.**
1. Scegliere la scheda **Policy**.
1. Per modificare la **Policy del cluster**:
1. Scegli **Modifica** per aggiornare il modo in cui viene assegnata la priorità alle attività e vengono allocate le risorse di calcolo inattive.
1. Dopo avere apportato le modifiche, scegli **Invia**.
1. Per modificare **Allocazione delle risorse di calcolo**:
1.
1. Scegli la configurazione da modificare in **Allocazione delle risorse di calcolo**. Si apre la pagina dei dettagli di configurazione.
1. Se desideri modificare queste configurazioni, scegli **Modifica**.
1. Dopo avere apportato le modifiche, scegli **Invia**.
# Eliminazione delle policy
Puoi eliminare le configurazioni **della policy del cluster** e **dell'allocazione di Compute** utilizzando la console SageMaker AI o. AWS CLI La pagina seguente fornisce istruzioni su come eliminare le politiche e le configurazioni di governance delle SageMaker HyperPod attività.
Per ulteriori informazioni sui concetti della politica del cluster EKS sulla governance delle HyperPod attività, vedere[Policy](sagemaker-hyperpod-eks-operate-console-ui-governance-policies.md).
**Nota**
In caso di problemi con la visualizzazione o l’eliminazione delle policy di governance delle attività, potrebbe essere necessario aggiornare il set minimo di autorizzazioni dell’amministratore del cluster. Consulta la scheda **Amazon EKS** nella sezione [Utenti IAM per l’amministratore del cluster](sagemaker-hyperpod-prerequisites-iam.md#sagemaker-hyperpod-prerequisites-iam-cluster-admin). Per ulteriori informazioni, consulta [Eliminazione dei cluster](sagemaker-hyperpod-eks-operate-console-ui-governance-troubleshoot.md#hp-eks-troubleshoot-delete-policies).
## Eliminare le politiche di governance delle HyperPod attività (console)
Quanto segue utilizza la console SageMaker AI per eliminare le politiche di governance delle HyperPod attività.
**Nota**
Non è possibile eliminare la **politica del cluster** (`ClusterSchedulerConfig`) utilizzando la console SageMaker AI. Per informazioni su come eseguire questa operazione utilizzando il AWS CLI, consulta[Elimina le politiche di governance delle HyperPod attività ()AWS CLI](#sagemaker-hyperpod-eks-operate-console-ui-governance-policies-delete-cli).
**Per eliminare le policy di governance delle attività (console)**
1. Passa alla [console Amazon SageMaker AI](https://console.aws.amazon.com/sagemaker/).
1. Nel riquadro di navigazione a sinistra, in **HyperPodClusters**, scegli **Cluster Management**.
1. Scegli il tuo cluster Amazon EKS elencato tra **SageMaker HyperPodi cluster.**
1. Scegliere la scheda **Policy**.
1. Per eliminare l’**allocazione delle risorse di calcolo** (`ComputeQuota`):
1. Nella sezione **Allocazione delle risorse di calcolo**, seleziona la configurazione da eliminare.
1. Dal menu a discesa **Azioni**, seleziona **Elimina**.
1. Segui le istruzioni nell’interfaccia utente per completare l’attività.
## Elimina le politiche di governance delle HyperPod attività ()AWS CLI
Quanto segue utilizza AWS CLI per eliminare le politiche di governance delle HyperPod attività.
**Nota**
In caso di problemi con l'utilizzo dei seguenti comandi, potrebbe essere necessario aggiornare il file AWS CLI. Per ulteriori informazioni, consulta [Installazione o aggiornamento alla versione più recente della AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html).
**Per eliminare le policy di governance delle attività (AWS CLI)**
Imposta innanzitutto le variabili per i AWS CLI comandi seguenti.
```
REGION=aws-region
```
1. Ottieni le *cluster-arn* informazioni associate alle politiche che desideri eliminare. Puoi usare il seguente AWS CLI comando per elencare i cluster presenti nel tuo Regione AWS.
```
aws sagemaker list-clusters \
--region ${REGION}
```
1. Per eliminare le allocazioni delle risorse di calcolo (`ComputeQuota`):
1. Elenca tutte le quote di calcolo associate al cluster. HyperPod
```
aws sagemaker list-compute-quotas \
--cluster-arn cluster-arn \
--region ${REGION}
```
1. Per ogni `compute-quota-id` che desideri eliminare, utilizza il comando seguente per eliminare la quota di calcolo.
```
aws sagemaker delete-compute-quota \
--compute-quota-id compute-quota-id \
--region ${REGION}
```
1. Per eliminare le policy del cluster (`ClusterSchedulerConfig`):
1. Elenca tutte le politiche del cluster associate al HyperPod cluster.
```
aws sagemaker list-cluster-scheduler-configs \
--cluster-arn cluster-arn \
--region ${REGION}
```
1. Per ogni `cluster-scheduler-config-id` che desideri eliminare, utilizza il comando seguente per eliminare la quota di calcolo.
```
aws sagemaker delete-cluster-scheduler-config
--cluster-scheduler-config-id scheduler-config-id \
--region ${REGION}
```
# Allocazione della quota di elaborazione nella governance delle attività di Amazon SageMaker HyperPod
Gli amministratori del cluster possono decidere le modalità di utilizzo delle risorse di calcolo acquistate dall’organizzazione. In questo modo si riducono gli sprechi e le risorse inattive. Puoi allocare una quota di calcolo in modo tale che i team possano prendere in prestito le risorse inutilizzate gli uni dagli altri. L'allocazione delle quote di calcolo nella governance delle HyperPod attività consente agli amministratori di allocare le risorse a livello di istanza e a un livello di risorse più granulare. Questa funzionalità offre una gestione flessibile ed efficiente delle risorse per i team, consentendo un controllo granulare sulle singole risorse di calcolo, invece di richiedere l’allocazione di intere istanze. L’allocazione a livello granulare elimina le inefficienze della tradizionale allocazione a livello di istanza. Grazie a questo approccio, puoi ottimizzare l’utilizzo delle risorse e ridurre le risorse di calcolo inattive.
L’allocazione delle quote di calcolo supporta tre tipi di allocazione delle risorse: acceleratori, vCPU e memoria. Gli acceleratori sono componenti delle istanze a calcolo accelerato che eseguono funzioni, ad esempio calcoli di numeri in virgola mobile, elaborazione grafica o corrispondenza di modelli di dati. Gli acceleratori includono acceleratori Trainium e nuclei GPUs neuronali. Per la condivisione di GPU tra più team, team diversi possono ricevere allocazioni della GPU specifiche dallo stesso tipo di istanza, massimizzando l’utilizzo dell’hardware dell’acceleratore. Per i carichi di lavoro a uso intensivo di memoria che richiedono RAM aggiuntiva per la preelaborazione dei dati o gli scenari di memorizzazione nella cache dei modelli, è possibile allocare una quota di memoria superiore al rapporto predefinito. GPU-to-memory Per le attività di pre-elaborazione che richiedono ingenti risorse di CPU, oltre all’addestramento della GPU, puoi allocare risorse della CPU indipendenti.
Una volta fornito un valore, la governance delle HyperPod attività calcola il rapporto utilizzando la formula «**risorsa allocata» divisa per la quantità totale di risorse disponibili nell'istanza**. HyperPod la governance delle attività utilizza quindi questo rapporto per applicare le allocazioni predefinite ad altre risorse, ma è possibile sovrascrivere queste impostazioni predefinite e personalizzarle in base al caso d'uso. Di seguito sono riportati alcuni scenari di esempio di come la governance delle HyperPod attività alloca le risorse in base ai valori dell'utente:
+ **Specificato solo l'acceleratore**: la governance delle HyperPod attività applica il rapporto predefinito a vCPU e memoria in base ai valori dell'acceleratore.
+ È stata **specificata solo la vCPU**: la governance delle HyperPod attività calcola il rapporto e lo applica alla memoria. Gli acceleratori sono impostati su 0.
+ **Specificata solo la memoria**: la HyperPod task governance calcola il rapporto e lo applica alla vCPU perché l'elaborazione è necessaria per eseguire carichi di lavoro specificati dalla memoria. Gli acceleratori sono impostati su 0.
Per controllare a livello di codice l'allocazione delle quote, è possibile utilizzare l'oggetto e specificare le allocazioni in numeri interi. [ ComputeQuotaResourceConfig](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_ComputeQuotaResourceConfig.html)
```
{
"ComputeQuotaConfig": {
"ComputeQuotaResources": [{
"InstanceType": "ml.g5.24xlarge",
"Accelerators": "16",
"vCpu": "200.0",
"MemoryInGiB": "2.0"
}]
}
}
```
Per visualizzare tutte le allocazioni allocate, incluse quelle predefinite, utilizza l'operazione. [ DescribeComputeQuota](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_DescribeComputeQuota.html) Per aggiornare le allocazioni, utilizzare l'operazione. [ UpdateComputeQuota](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_UpdateComputeQuota.html)
Puoi anche utilizzare la HyperPod CLI per allocare quote di calcolo. Per ulteriori informazioni sulla HyperPod CLI, vedere. [Esecuzione di processi su SageMaker HyperPod cluster orchestrati da Amazon EKS](sagemaker-hyperpod-eks-run-jobs.md) L'esempio seguente dimostra come impostare le quote di calcolo utilizzando la CLI. HyperPod
```
hyp create hyp-pytorch-job --version 1.1 --job-name sample-job \
--image 123456789012.dkr.ecr.us-west-2.amazonaws.com/ptjob:latest \
--pull-policy "Always" \
--tasks-per-node 1 \
--max-retry 1 \
--priority high-priority \
--namespace hyperpod-ns-team-name \
--queue-name hyperpod-ns-team-name-localqueue \
--instance-type sample-instance-type \
--accelerators 1 \
--vcpu 3 \
--memory 1 \
--accelerators-limit 1 \
--vcpu-limit 4 \
--memory-limit 2
```
Per allocare le quote utilizzando la console, segui questi passaggi. AWS
1. Apri la console Amazon SageMaker AI all'indirizzo [https://console.aws.amazon.com/sagemaker/](https://console.aws.amazon.com/sagemaker/).
1. In HyperPod Cluster, scegli **Cluster management**.
1. In **Allocazioni delle risorse di calcolo**, scegli **Crea**.
1. Se non sono ancora presenti istanze, scegli **Aggiungi allocazione** per aggiungere un’istanza.
1. In **Allocazioni**, scegli di allocare in base alle istanze o alle singole risorse. Se allochi per singole risorse, l' SageMaker IA assegna automaticamente le allocazioni ad altre risorse in base al rapporto che hai scelto. Per sostituire questa allocazione delle risorse di calcolo basata sul rapporto, utilizza l’interruttore corrispondente.
1. Ripeti le fasi 4 e 5 per configurare istanze aggiuntive.
Dopo aver assegnato la quota di elaborazione, puoi inviare lavori tramite la CLI o HyperPod . `kubectl` HyperPodpianifica in modo efficiente i carichi di lavoro in base alla quota disponibile.
# Allocazione della quota di partizione GPU
È possibile estendere l'allocazione delle quote di elaborazione per supportare il partizionamento della GPU, abilitando una condivisione dettagliata delle risorse a livello di partizione GPU. Quando il partizionamento GPU è abilitato su Support nel cluster, ogni GPU fisica può essere partizionata GPUs in più unità isolate con allocazioni multiprocessore definite di elaborazione, memoria e streaming. GPUs Per ulteriori informazioni sul partizionamento della GPU, vedere. [Utilizzo delle partizioni GPU in Amazon SageMaker HyperPod](sagemaker-hyperpod-eks-gpu-partitioning.md) Puoi assegnare partizioni GPU specifiche ai team, consentendo a più team di condividere una singola GPU mantenendo l'isolamento a livello di hardware e prestazioni prevedibili.
Ad esempio, un'istanza ml.p5.48xlarge con 8 H100 GPUs può essere partizionata in partizioni GPU ed è possibile allocare singole partizioni a team diversi in base ai requisiti delle rispettive attività. Quando si specificano le allocazioni delle partizioni GPU, la HyperPod task governance calcola le quote proporzionali di vCPU e memoria in base alla partizione GPU, in modo simile all'allocazione a livello di GPU. Questo approccio massimizza l'utilizzo della GPU eliminando la capacità inattiva e abilitando la condivisione delle risorse a costi contenuti tra più attività simultanee sulla stessa GPU fisica.
## Creazione di quote di calcolo
```
aws sagemaker create-compute-quota \
--name "fractional-gpu-quota" \
--compute-quota-config '{
"ComputeQuotaResources": [
{
"InstanceType": "ml.p4d.24xlarge",
"AcceleratorPartition": {
"Count": 4,
"Type": "mig-1g.5gb"
}
}
],
"ResourceSharingConfig": {
"Strategy": "LendAndBorrow",
"BorrowLimit": 100
}
}'
```
## Verifica delle risorse relative alle quote
```
# Check ClusterQueue
kubectl get clusterqueues
kubectl describe clusterqueue QUEUE_NAME
# Check ResourceFlavors
kubectl get resourceflavor
kubectl describe resourceflavor FLAVOR_NAME
```
# Esempi di comandi di governance delle HyperPod AWS CLI attività
È possibile utilizzare HyperPod con EKS tramite Kubectl o tramite CLI personalizzata HyperPod. È possibile utilizzare questi comandi tramite Studio o. AWS CLI Di seguito vengono forniti esempi di governance delle SageMaker HyperPod attività su come visualizzare i dettagli del cluster utilizzando i HyperPod AWS CLI comandi. Per ulteriori informazioni, incluse le modalità di installazione, consulta il repository [HyperPod Github della CLI](https://github.com/aws/sagemaker-hyperpod-cli).
**Topics**
+ [Informazioni sulla quota del dispositivo dell’acceleratore del cluster](#hp-eks-cli-get-clusters)
+ [Invia un lavoro alla coda e allo SageMaker spazio dei nomi gestiti dall'intelligenza artificiale](#hp-eks-cli-start-job)
+ [Elenco dei processi](#hp-eks-cli-list-jobs)
+ [Informazioni dettagliate su un processo](#hp-eks-cli-get-job)
+ [Sospensione e ripresa dei processi](#hp-eks-cli-patch-job)
+ [Debug dei processi](#hp-eks-cli-other)
## Informazioni sulla quota del dispositivo dell’acceleratore del cluster
Il comando di esempio seguente recupera le informazioni sulla quota del dispositivo dell’acceleratore del cluster.
```
hyperpod get-clusters -n hyperpod-ns-test-team
```
Il namespace in questo esempio, `hyperpod-ns-test-team`, viene creato in Kubernetes in base al nome del team, `test-team`, fornito durante l’allocazione delle risorse di calcolo Per ulteriori informazioni, consulta [Modifica delle policy](sagemaker-hyperpod-eks-operate-console-ui-governance-policies-edit.md).
Risposta di esempio:
```
[
{
"Cluster": "hyperpod-eks-test-cluster-id",
"InstanceType": "ml.g5.xlarge",
"TotalNodes": 2,
"AcceleratorDevicesAvailable": 1,
"NodeHealthStatus=Schedulable": 2,
"DeepHealthCheckStatus=Passed": "N/A",
"Namespaces": {
"hyperpod-ns-test-team": {
"TotalAcceleratorDevices": 1,
"AvailableAcceleratorDevices": 1
}
}
}
]
```
## Invia un lavoro alla coda e allo SageMaker spazio dei nomi gestiti dall'intelligenza artificiale
Il comando di esempio seguente invia un lavoro al cluster. HyperPod Se hai accesso a un solo team, in questo caso ti HyperPod AWS CLI assegnerà automaticamente la coda. Se invece vengono rilevate più code, verranno visualizzate tutte le possibili opzioni selezionabili.
```
hyperpod start-job --job-name hyperpod-cli-test --job-kind kubeflow/PyTorchJob --image docker.io/kubeflowkatib/pytorch-mnist-cpu:v1beta1-bc09cfd --entry-script /opt/pytorch-mnist/mnist.py --pull-policy IfNotPresent --instance-type ml.g5.xlarge --node-count 1 --tasks-per-node 1 --results-dir ./result --priority training-priority
```
Le classi di priorità sono definite in **Policy del cluster**, che specifica il modo in cui viene assegnata la priorità alle attività e vengono allocate le risorse di calcolo inattive. Quando un Data Scientist invia un processo, utilizza uno dei nomi delle classi di priorità con il formato `priority-class-name-priority`. In questo esempio, `training-priority` si riferisce alla classe di priorità denominata “addestramento”. Per ulteriori informazioni sui concetti della policy, consulta [Policy](sagemaker-hyperpod-eks-operate-console-ui-governance-policies.md).
Se non viene specificata una classe di priorità, il processo viene considerato a bassa priorità, con un valore di classificazione delle attività pari a 0.
Se viene specificata una classe di priorità, che però non corrisponde a una delle classi di priorità definite in **Policy del cluster**, l’invio non riesce e viene visualizzato un messaggio di errore che riporta il set definito di classi di priorità.
Puoi inviare il processo anche tramite un file di configurazione YAML con il comando seguente:
```
hyperpod start-job --config-file ./yaml-configuration-file-name.yaml
```
Di seguito è riportato un esempio di file di configurazione YAML che equivale all’operazione di invio di un processo, come discusso in precedenza.
```
defaults:
- override hydra/job_logging: stdout
hydra:
run:
dir: .
output_subdir: null
training_cfg:
entry_script: /opt/pytorch-mnist/mnist.py
script_args: []
run:
name: hyperpod-cli-test
nodes: 1
ntasks_per_node: 1
cluster:
cluster_type: k8s
instance_type: ml.g5.xlarge
custom_labels:
kueue.x-k8s.io/priority-class: training-priority
cluster_config:
label_selector:
required:
sagemaker.amazonaws.com/node-health-status:
- Schedulable
preferred:
sagemaker.amazonaws.com/deep-health-check-status:
- Passed
weights:
- 100
pullPolicy: IfNotPresent
base_results_dir: ./result
container: docker.io/kubeflowkatib/pytorch-mnist-cpu:v1beta1-bc09cfd
env_vars:
NCCL_DEBUG: INFO
```
In alternativa, puoi inviare un processo con `kubectl` per garantire che l’attività venga visualizzata nella scheda **Dashboard**. Il seguente è un comando kubectl di esempio.
```
kubectl apply -f ./yaml-configuration-file-name.yaml
```
Quando invii il processo, includi il nome della coda e le etichette della classe di priorità. Ad esempio, con il nome della coda `hyperpod-ns-team-name-localqueue` e la classe di priorità `priority-class-name-priority`, devi includere le seguenti etichette:
+ `kueue.x-k8s.io/queue-name: hyperpod-ns-team-name-localqueue`
+ `kueue.x-k8s.io/priority-class: priority-class-name-priority`
Il frammento di configurazione YAML seguente mostra come aggiungere etichette al file di configurazione originale per garantire che l’attività venga visualizzata nella scheda **Dashboard**:
```
metadata:
name: job-name
namespace: hyperpod-ns-team-name
labels:
kueue.x-k8s.io/queue-name: hyperpod-ns-team-name-localqueue
kueue.x-k8s.io/priority-class: priority-class-name-priority
```
## Elenco dei processi
Il comando seguente elenca i processi e i relativi dettagli.
```
hyperpod list-jobs
```
Risposta di esempio:
```
{
"jobs": [
{
"Name": "hyperpod-cli-test",
"Namespace": "hyperpod-ns-test-team",
"CreationTime": "2024-11-18T21:21:15Z",
"Priority": "training",
"State": "Succeeded"
}
]
}
```
## Informazioni dettagliate su un processo
Il comando seguente fornisce i dettagli di un processo. Se non viene specificato alcun namespace, HyperPod AWS CLI recupererà uno spazio dei nomi gestito dall' SageMaker IA a cui hai accesso.
```
hyperpod get-job --job-name hyperpod-cli-test
```
Risposta di esempio:
```
{
"Name": "hyperpod-cli-test",
"Namespace": "hyperpod-ns-test-team",
"Label": {
"app": "hyperpod-cli-test",
"app.kubernetes.io/managed-by": "Helm",
"kueue.x-k8s.io/priority-class": "training"
},
"CreationTimestamp": "2024-11-18T21:21:15Z",
"Status": {
"completionTime": "2024-11-18T21:25:24Z",
"conditions": [
{
"lastTransitionTime": "2024-11-18T21:21:15Z",
"lastUpdateTime": "2024-11-18T21:21:15Z",
"message": "PyTorchJob hyperpod-cli-test is created.",
"reason": "PyTorchJobCreated",
"status": "True",
"type": "Created"
},
{
"lastTransitionTime": "2024-11-18T21:21:17Z",
"lastUpdateTime": "2024-11-18T21:21:17Z",
"message": "PyTorchJob hyperpod-ns-test-team/hyperpod-cli-test is running.",
"reason": "PyTorchJobRunning",
"status": "False",
"type": "Running"
},
{
"lastTransitionTime": "2024-11-18T21:25:24Z",
"lastUpdateTime": "2024-11-18T21:25:24Z",
"message": "PyTorchJob hyperpod-ns-test-team/hyperpod-cli-test successfully completed.",
"reason": "PyTorchJobSucceeded",
"status": "True",
"type": "Succeeded"
}
],
"replicaStatuses": {
"Worker": {
"selector": "training.kubeflow.org/job-name=hyperpod-cli-test,training.kubeflow.org/operator-name=pytorchjob-controller,training.kubeflow.org/replica-type=worker",
"succeeded": 1
}
},
"startTime": "2024-11-18T21:21:15Z"
},
"ConsoleURL": "https://us-west-2.console.aws.amazon.com/sagemaker/home?region=us-west-2#/cluster-management/hyperpod-eks-test-cluster-id“
}
```
## Sospensione e ripresa dei processi
Se si desidera rimuovere alcuni lavori inviati dallo scheduler, HyperPod AWS CLI fornisce il `suspend` comando per rimuovere temporaneamente il lavoro dall'orchestrazione. Il processo sospeso non sarà più pianificato a meno che non venga ripreso manualmente con il comando `unsuspend`.
Per sospendere temporaneamente un processo:
```
hyperpod patch-job suspend --job-name hyperpod-cli-test
```
Per aggiungere nuovamente un processo alla coda:
```
hyperpod patch-job unsuspend --job-name hyperpod-cli-test
```
## Debug dei processi
Fornisce HyperPod AWS CLI anche altri comandi per il debug dei problemi di invio dei lavori. Ad esempio `list-pods` e `get-logs` nel repository HyperPod AWS CLI Github.
# Risoluzione dei problemi
La pagina seguente contiene soluzioni note per la risoluzione dei problemi dei cluster EKS. HyperPod
**Topics**
+ [Scheda Pannello di controllo](#hp-eks-troubleshoot-dashboard)
+ [Scheda Attività](#hp-eks-troubleshoot-tasks)
+ [Policy](#hp-eks-troubleshoot-policies)
+ [Eliminazione dei cluster](#hp-eks-troubleshoot-delete-policies)
+ [Condivisione di risorse non allocate](#hp-eks-troubleshoot-unallocated-resource-sharing)
## Scheda Pannello di controllo
**Installazione non riuscita del componente aggiuntivo EKS**
Per installare correttamente il componente aggiuntivo EKS, è necessaria una versione di Kubernets >= 1.30. Per l’aggiornamento, consulta [Update Kubernetes version](https://docs.aws.amazon.com/eks/latest/userguide/update-cluster.html).
Per installare correttamente il componente aggiuntivo EKS, tutti i nodi devono essere in stato **Pronto** e tutti i pod devono essere in stato **In esecuzione**.
Per verificare lo stato dei nodi, utilizza il [https://docs.aws.amazon.com/cli/latest/reference/sagemaker/list-cluster-nodes.html](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/list-cluster-nodes.html) AWS CLI comando o accedi al cluster EKS nella [console EKS](https://console.aws.amazon.com/eks/home#/clusters) e visualizza lo stato dei nodi. Risolvi il problema per ogni nodo o contatta il tuo amministratore. Se lo stato del nodo è **Sconosciuto**, elimina il nodo. Una volta che tutti gli stati dei nodi sono **pronti**, riprova a installare il componente aggiuntivo EKS HyperPod dalla console [Amazon SageMaker ](https://console.aws.amazon.com/sagemaker/) AI.
Per controllare lo stato dei pod, utilizza il comando della [CLI di Kubernetes](https://kubernetes.io/docs/reference/kubectl/) `kubectl get pods -n cloudwatch-agent` o accedi al cluster EKS nella [console EKS](https://console.aws.amazon.com/eks/home#/clusters) e visualizza lo stato dei pod con il namespace `cloudwatch-agent`. Risolvi il problema dei pod o contatta il tuo amministratore. Una volta che tutti gli stati del pod sono **in esecuzione**, riprova a installare il componente aggiuntivo EKS HyperPod dalla console [Amazon SageMaker ](https://console.aws.amazon.com/sagemaker/) AI.
Per ulteriori informazioni sulla risoluzione dei problemi, consulta [Risoluzione dei problemi del componente aggiuntivo Amazon CloudWatch Observability EKS](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/install-CloudWatch-Observability-EKS-addon.html#Container-Insights-setup-EKS-addon-troubleshoot).
## Scheda Attività
Se viene visualizzato il messaggio di errore relativo alla **mancata configurazione della Definizione di risorse personalizzate (CRD) nel cluster**, assegna le policy `EKSAdminViewPolicy` e `ClusterAccessRole` al ruolo di esecuzione del dominio.
+ Per informazioni su come ottenere il ruolo di esecuzione, consulta [Acquisizione del ruolo di esecuzione](sagemaker-roles.md#sagemaker-roles-get-execution-role).
+ Per informazioni su come collegare le policy a un utente o a un gruppo IAM, consulta [Adding and removing IAM identity permissions](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html).
## Policy
Di seguito sono elencate le soluzioni agli errori relativi alle politiche che utilizzano la console HyperPod APIs or.
+ Se la policy è in stato `CreateFailed` o `CreateRollbackFailed`, devi eliminare la policy non riuscita e crearne una nuova.
+ Se la policy è in stato `UpdateFailed`, prova a eseguire di nuovo l’aggiornamento con lo stesso ARN della policy.
+ Se la policy è in stato `UpdateRollbackFailed`, devi eliminare la policy non riuscita e crearne una nuova.
+ Se la policy è in stato `DeleteFailed` o `DeleteRollbackFailed`, prova a eliminarla di nuovo con lo stesso ARN della policy.
+ Se hai riscontrato un errore durante il tentativo di eliminare la **prioritizzazione di Compute**, o la policy del cluster, utilizzando la HyperPod console, prova a eliminarlo `cluster-scheduler-config` utilizzando l'API. Per verificare lo stato della risorsa, vai alla pagina dei dettagli di un’allocazione delle risorse di calcolo.
Per visualizzare maggiori dettagli sull’errore, utilizza l’API describe.
## Eliminazione dei cluster
Di seguito sono elencate le soluzioni note per gli errori relativi all’eliminazione dei cluster.
+ Se l'eliminazione del cluster fallisce a causa delle politiche di governance delle SageMaker HyperPod attività allegate, dovrai farlo. [Eliminazione delle policy](sagemaker-hyperpod-eks-operate-console-ui-governance-policies-delete.md)
+ Se l’eliminazione del cluster non riesce perché mancano le autorizzazioni seguenti, devi aggiornare il set minimo di autorizzazioni dell’amministratore del cluster. Consulta la scheda **Amazon EKS** nella sezione [Utenti IAM per l’amministratore del cluster](sagemaker-hyperpod-prerequisites-iam.md#sagemaker-hyperpod-prerequisites-iam-cluster-admin).
+ `sagemaker:ListComputeQuotas`
+ `sagemaker:ListClusterSchedulerConfig`
+ `sagemaker:DeleteComputeQuota`
+ `sagemaker:DeleteClusterSchedulerConfig`
## Condivisione di risorse non allocate
Se la capacità del pool di risorse non allocate è inferiore al previsto:
1. **Verifica lo stato di disponibilità del nodo**
```
kubectl get nodes
```
Verifica che tutti i nodi mostrino `Ready` lo stato nella colonna STATUS.
1. **Controlla lo stato di pianificazione del nodo**
```
kubectl get nodes -o custom-columns=NAME:.metadata.name,UNSCHEDULABLE:.spec.unschedulable
```
Verifica che i nodi mostrino `` o `false` (no`true`).
1. **Elenca la condivisione di risorse non allocate: ClusterQueues**
```
kubectl get clusterqueue | grep hyperpod-ns-idle-resource-sharing
```
Questo mostra tutte le condivisioni di risorse non allocate. ClusterQueues Se non ClusterQueues vengono visualizzati, controlla la ClusterSchedulerConfig politica `FailureReason` sottostante per vedere se ci sono messaggi di errore per continuare il debug.
1. **Verifica la quota di condivisione delle risorse non allocate:**
```
kubectl describe clusterqueue hyperpod-ns-idle-resource-sharing-
```
Controlla la `spec.resourceGroups[].flavors[].resources` sezione per vedere la quota assegnata per ogni tipo di risorsa.
ClusterQueues Può esistere una condivisione multipla di risorse non allocate a seconda del numero di tipologie di risorse presenti nel cluster.
1. **Verifica lo stato della configurazione MIG (nodi GPU):**
```
kubectl get nodes -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.metadata.labels.nvidia\.com/mig\.config\.state}{"\n"}{end}'
```
Verifica che i nodi abilitati a MIG mostrino lo stato. `success`
# Documento di attribuzione per la governance delle SageMaker HyperPod attività di Amazon
Di seguito puoi scoprire le attribuzioni e le licenze di terze parti per il materiale utilizzato nella SageMaker HyperPod task governance di Amazon.
**Topics**
+ [[base-files](https://packages.debian.org/bookworm/base-files)](#hp-eks-task-governance-attributions-base-files)
+ [[netbase](https://packages.debian.org/source/stable/netbase)](#hp-eks-task-governance-attributions-netbase)
+ [[golang-lru](https://github.com/hashicorp/golang-lru)](#hp-eks-task-governance-attributions-golang-lru)
## [base-files](https://packages.debian.org/bookworm/base-files)
```
This is the Debian prepackaged version of the Debian Base System
Miscellaneous files. These files were written by Ian Murdock
and Bruce Perens .
This package was first put together by Bruce Perens ,
from his own sources.
The GNU Public Licenses in /usr/share/common-licenses were taken from
ftp.gnu.org and are copyrighted by the Free Software Foundation, Inc.
The Artistic License in /usr/share/common-licenses is the one coming
from Perl and its SPDX name is "Artistic License 1.0 (Perl)".
Copyright © 1995-2011 Software in the Public Interest.
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
On Debian systems, the complete text of the GNU General
Public License can be found in `/usr/share/common-licenses/GPL'.
```
## [netbase](https://packages.debian.org/source/stable/netbase)
```
Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
Comment:
This package was created by Peter Tobias tobias@et-inf.fho-emden.de on
Wed, 24 Aug 1994 21:33:28 +0200 and maintained by Anthony Towns
until 2001.
It is currently maintained by Marco d'Itri .
Files: *
Copyright:
Copyright © 1994-1998 Peter Tobias
Copyright © 1998-2001 Anthony Towns
Copyright © 2002-2022 Marco d'Itri
License: GPL-2
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License, version 2, as
published by the Free Software Foundation.
.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
.
You should have received a copy of the GNU General Public License along
with this program; if not, write to the Free Software Foundation,
Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
.
On Debian systems, the complete text of the GNU General Public License
version 2 can be found in '/usr/share/common-licenses/GPL-2'.
```
## [golang-lru](https://github.com/hashicorp/golang-lru)
```
Copyright © 2014 HashiCorp, Inc.
Mozilla Public License, version 2.0
1. Definitions
1.1. "Contributor"
means each individual or legal entity that creates, contributes to the
creation of, or owns Covered Software.
1.2. "Contributor Version"
means the combination of the Contributions of others (if any) used by a
Contributor and that particular Contributor's Contribution.
1.3. "Contribution"
means Covered Software of a particular Contributor.
1.4. "Covered Software"
means Source Code Form to which the initial Contributor has attached the
notice in Exhibit A, the Executable Form of such Source Code Form, and
Modifications of such Source Code Form, in each case including portions
thereof.
1.5. "Incompatible With Secondary Licenses"
means
a. that the initial Contributor has attached the notice described in
Exhibit B to the Covered Software; or
b. that the Covered Software was made available under the terms of
version 1.1 or earlier of the License, but not also under the terms of
a Secondary License.
1.6. "Executable Form"
means any form of the work other than Source Code Form.
1.7. "Larger Work"
means a work that combines Covered Software with other material, in a
separate file or files, that is not Covered Software.
1.8. "License"
means this document.
1.9. "Licensable"
means having the right to grant, to the maximum extent possible, whether
at the time of the initial grant or subsequently, any and all of the
rights conveyed by this License.
1.10. "Modifications"
means any of the following:
a. any file in Source Code Form that results from an addition to,
deletion from, or modification of the contents of Covered Software; or
b. any new file in Source Code Form that contains any Covered Software.
1.11. "Patent Claims" of a Contributor
means any patent claim(s), including without limitation, method,
process, and apparatus claims, in any patent Licensable by such
Contributor that would be infringed, but for the grant of the License,
by the making, using, selling, offering for sale, having made, import,
or transfer of either its Contributions or its Contributor Version.
1.12. "Secondary License"
means either the GNU General Public License, Version 2.0, the GNU Lesser
General Public License, Version 2.1, the GNU Affero General Public
License, Version 3.0, or any later versions of those licenses.
1.13. "Source Code Form"
means the form of the work preferred for making modifications.
1.14. "You" (or "Your")
means an individual or a legal entity exercising rights under this
License. For legal entities, "You" includes any entity that controls, is
controlled by, or is under common control with You. For purposes of this
definition, "control" means (a) the power, direct or indirect, to cause
the direction or management of such entity, whether by contract or
otherwise, or (b) ownership of more than fifty percent (50%) of the
outstanding shares or beneficial ownership of such entity.
2. License Grants and Conditions
2.1. Grants
Each Contributor hereby grants You a world-wide, royalty-free,
non-exclusive license:
a. under intellectual property rights (other than patent or trademark)
Licensable by such Contributor to use, reproduce, make available,
modify, display, perform, distribute, and otherwise exploit its
Contributions, either on an unmodified basis, with Modifications, or
as part of a Larger Work; and
b. under Patent Claims of such Contributor to make, use, sell, offer for
sale, have made, import, and otherwise transfer either its
Contributions or its Contributor Version.
2.2. Effective Date
The licenses granted in Section 2.1 with respect to any Contribution
become effective for each Contribution on the date the Contributor first
distributes such Contribution.
2.3. Limitations on Grant Scope
The licenses granted in this Section 2 are the only rights granted under
this License. No additional rights or licenses will be implied from the
distribution or licensing of Covered Software under this License.
Notwithstanding Section 2.1(b) above, no patent license is granted by a
Contributor:
a. for any code that a Contributor has removed from Covered Software; or
b. for infringements caused by: (i) Your and any other third party's
modifications of Covered Software, or (ii) the combination of its
Contributions with other software (except as part of its Contributor
Version); or
c. under Patent Claims infringed by Covered Software in the absence of
its Contributions.
This License does not grant any rights in the trademarks, service marks,
or logos of any Contributor (except as may be necessary to comply with
the notice requirements in Section 3.4).
2.4. Subsequent Licenses
No Contributor makes additional grants as a result of Your choice to
distribute the Covered Software under a subsequent version of this
License (see Section 10.2) or under the terms of a Secondary License (if
permitted under the terms of Section 3.3).
2.5. Representation
Each Contributor represents that the Contributor believes its
Contributions are its original creation(s) or it has sufficient rights to
grant the rights to its Contributions conveyed by this License.
2.6. Fair Use
This License is not intended to limit any rights You have under
applicable copyright doctrines of fair use, fair dealing, or other
equivalents.
2.7. Conditions
Sections 3.1, 3.2, 3.3, and 3.4 are conditions of the licenses granted in
Section 2.1.
3. Responsibilities
3.1. Distribution of Source Form
All distribution of Covered Software in Source Code Form, including any
Modifications that You create or to which You contribute, must be under
the terms of this License. You must inform recipients that the Source
Code Form of the Covered Software is governed by the terms of this
License, and how they can obtain a copy of this License. You may not
attempt to alter or restrict the recipients' rights in the Source Code
Form.
3.2. Distribution of Executable Form
If You distribute Covered Software in Executable Form then:
a. such Covered Software must also be made available in Source Code Form,
as described in Section 3.1, and You must inform recipients of the
Executable Form how they can obtain a copy of such Source Code Form by
reasonable means in a timely manner, at a charge no more than the cost
of distribution to the recipient; and
b. You may distribute such Executable Form under the terms of this
License, or sublicense it under different terms, provided that the
license for the Executable Form does not attempt to limit or alter the
recipients' rights in the Source Code Form under this License.
3.3. Distribution of a Larger Work
You may create and distribute a Larger Work under terms of Your choice,
provided that You also comply with the requirements of this License for
the Covered Software. If the Larger Work is a combination of Covered
Software with a work governed by one or more Secondary Licenses, and the
Covered Software is not Incompatible With Secondary Licenses, this
License permits You to additionally distribute such Covered Software
under the terms of such Secondary License(s), so that the recipient of
the Larger Work may, at their option, further distribute the Covered
Software under the terms of either this License or such Secondary
License(s).
3.4. Notices
You may not remove or alter the substance of any license notices
(including copyright notices, patent notices, disclaimers of warranty, or
limitations of liability) contained within the Source Code Form of the
Covered Software, except that You may alter any license notices to the
extent required to remedy known factual inaccuracies.
3.5. Application of Additional Terms
You may choose to offer, and to charge a fee for, warranty, support,
indemnity or liability obligations to one or more recipients of Covered
Software. However, You may do so only on Your own behalf, and not on
behalf of any Contributor. You must make it absolutely clear that any
such warranty, support, indemnity, or liability obligation is offered by
You alone, and You hereby agree to indemnify every Contributor for any
liability incurred by such Contributor as a result of warranty, support,
indemnity or liability terms You offer. You may include additional
disclaimers of warranty and limitations of liability specific to any
jurisdiction.
4. Inability to Comply Due to Statute or Regulation
If it is impossible for You to comply with any of the terms of this License
with respect to some or all of the Covered Software due to statute,
judicial order, or regulation then You must: (a) comply with the terms of
this License to the maximum extent possible; and (b) describe the
limitations and the code they affect. Such description must be placed in a
text file included with all distributions of the Covered Software under
this License. Except to the extent prohibited by statute or regulation,
such description must be sufficiently detailed for a recipient of ordinary
skill to be able to understand it.
5. Termination
5.1. The rights granted under this License will terminate automatically if You
fail to comply with any of its terms. However, if You become compliant,
then the rights granted under this License from a particular Contributor
are reinstated (a) provisionally, unless and until such Contributor
explicitly and finally terminates Your grants, and (b) on an ongoing
basis, if such Contributor fails to notify You of the non-compliance by
some reasonable means prior to 60 days after You have come back into
compliance. Moreover, Your grants from a particular Contributor are
reinstated on an ongoing basis if such Contributor notifies You of the
non-compliance by some reasonable means, this is the first time You have
received notice of non-compliance with this License from such
Contributor, and You become compliant prior to 30 days after Your receipt
of the notice.
5.2. If You initiate litigation against any entity by asserting a patent
infringement claim (excluding declaratory judgment actions,
counter-claims, and cross-claims) alleging that a Contributor Version
directly or indirectly infringes any patent, then the rights granted to
You by any and all Contributors for the Covered Software under Section
2.1 of this License shall terminate.
5.3. In the event of termination under Sections 5.1 or 5.2 above, all end user
license agreements (excluding distributors and resellers) which have been
validly granted by You or Your distributors under this License prior to
termination shall survive termination.
6. Disclaimer of Warranty
Covered Software is provided under this License on an "as is" basis,
without warranty of any kind, either expressed, implied, or statutory,
including, without limitation, warranties that the Covered Software is free
of defects, merchantable, fit for a particular purpose or non-infringing.
The entire risk as to the quality and performance of the Covered Software
is with You. Should any Covered Software prove defective in any respect,
You (not any Contributor) assume the cost of any necessary servicing,
repair, or correction. This disclaimer of warranty constitutes an essential
part of this License. No use of any Covered Software is authorized under
this License except under this disclaimer.
7. Limitation of Liability
Under no circumstances and under no legal theory, whether tort (including
negligence), contract, or otherwise, shall any Contributor, or anyone who
distributes Covered Software as permitted above, be liable to You for any
direct, indirect, special, incidental, or consequential damages of any
character including, without limitation, damages for lost profits, loss of
goodwill, work stoppage, computer failure or malfunction, or any and all
other commercial damages or losses, even if such party shall have been
informed of the possibility of such damages. This limitation of liability
shall not apply to liability for death or personal injury resulting from
such party's negligence to the extent applicable law prohibits such
limitation. Some jurisdictions do not allow the exclusion or limitation of
incidental or consequential damages, so this exclusion and limitation may
not apply to You.
8. Litigation
Any litigation relating to this License may be brought only in the courts
of a jurisdiction where the defendant maintains its principal place of
business and such litigation shall be governed by laws of that
jurisdiction, without reference to its conflict-of-law provisions. Nothing
in this Section shall prevent a party's ability to bring cross-claims or
counter-claims.
9. Miscellaneous
This License represents the complete agreement concerning the subject
matter hereof. If any provision of this License is held to be
unenforceable, such provision shall be reformed only to the extent
necessary to make it enforceable. Any law or regulation which provides that
the language of a contract shall be construed against the drafter shall not
be used to construe this License against a Contributor.
10. Versions of the License
10.1. New Versions
Mozilla Foundation is the license steward. Except as provided in Section
10.3, no one other than the license steward has the right to modify or
publish new versions of this License. Each version will be given a
distinguishing version number.
10.2. Effect of New Versions
You may distribute the Covered Software under the terms of the version
of the License under which You originally received the Covered Software,
or under the terms of any subsequent version published by the license
steward.
10.3. Modified Versions
If you create software not governed by this License, and you want to
create a new license for such software, you may create and use a
modified version of this License if you rename the license and remove
any references to the name of the license steward (except to note that
such modified license differs from this License).
10.4. Distributing Source Code Form that is Incompatible With Secondary
Licenses If You choose to distribute Source Code Form that is
Incompatible With Secondary Licenses under the terms of this version of
the License, the notice described in Exhibit B of this License must be
attached.
Exhibit A - Source Code Form License Notice
This Source Code Form is subject to the
terms of the Mozilla Public License, v.
2.0. If a copy of the MPL was not
distributed with this file, You can
obtain one at
http://mozilla.org/MPL/2.0/.
If it is not possible or desirable to put the notice in a particular file,
then You may include the notice in a location (such as a LICENSE file in a
relevant directory) where a recipient would be likely to look for such a
notice.
You may add additional accurate notices of copyright ownership.
Exhibit B - "Incompatible With Secondary Licenses" Notice
This Source Code Form is "Incompatible
With Secondary Licenses", as defined by
the Mozilla Public License, v. 2.0.
```
# Report sull'utilizzo per l'attribuzione dei costi in SageMaker HyperPod
Il reporting sull'utilizzo nei cluster SageMaker HyperPod orchestrati da EKS offre una visibilità granulare sul consumo delle risorse di elaborazione. Questa funzionalità consente alle organizzazioni di implementare un’attribuzione trasparente dei costi, allocando i costi dei cluster a team, progetti o reparti in base al loro utilizzo effettivo. [Grazie al monitoraggio di parametri come le GPU/CPU ore e l'utilizzo di Neuron Core, rilevati *sia negli aggregati a livello di team che nelle suddivisioni specifiche delle attività, la reportistica sull'utilizzo integra la funzionalità Task Governance di Task Governance, garantendo un'equa distribuzione dei* costi in cluster multi-tenant condivisi mediante: HyperPod](sagemaker-hyperpod-eks-operate-console-ui-governance.md)
+ Eliminazione delle ipotesi nell’allocazione dei costi
+ Collegamento diretto delle spese al consumo misurabile delle risorse
+ Applicazione della responsabilità basata sull’utilizzo in ambienti di infrastruttura condivisi
## Prerequisiti
Per visualizzare questa funzionalità:
+ Hai bisogno di:
+ Un **SageMaker HyperPod ambiente** attivo con un cluster orchestrato da EKS in esecuzione.
+ (Consigliato vivamente) **Governance delle attività configurata** con quote di calcolo e regole di priorità. Per istruzioni sulla configurazione, consulta [Configurazione della governance delle attività](sagemaker-hyperpod-eks-operate-console-ui-governance-setup.md).
+ Acquisire familiarità con questi concetti fondamentali:
+ **Quota di calcolo allocata**: risorse riservate a un team in base a quote predefinite nelle sue policy di governance delle attività. Si tratta della *capacità garantita* per i carichi di lavoro del team.
+ **Risorse di calcolo prese in prestito:** risorse inattive nel pool del cluster condiviso che i team possono utilizzare temporaneamente *in aggiunta alla loro quota assegnata*. Le risorse di calcolo prese in prestito vengono assegnate dinamicamente in base alle regole di priorità definite nelle policy di governance delle attività e alla disponibilità delle risorse inutilizzate.
+ **Utilizzo del calcolo:** la misurazione delle risorse (GPU, CPU, ore di core Neuron) consumate da un team, definite come:
+ **Utilizzo allocato**: utilizzo compreso nella quota del team.
+ **Utilizzo preso in prestito**: utilizzo eccedente la quota, preso dal pool condiviso.
+ **Attribuzione dei costi:** il processo di allocazione dei costi del cluster ai team in base all’*utilizzo effettivo delle risorse di calcolo*, che include sia le risorse comprese nella quota predefinita che le risorse prese temporaneamente dal pool del cluster condiviso in aggiunta alla quota allocata.
## Tipi di report
HyperPodi report sull'utilizzo forniscono una granularità operativa variabile:
+ **I report di riepilogo** *forniscono una visibilità a livello aziendale sull'utilizzo delle risorse di calcolo, aggregando le ore GPU/CPU/Neuron Core totali per team (namespace) e distinguendo tra *utilizzo regolare* (risorse provenienti dalla quota allocata del team) ed elaborazione presa in prestito (capacità di sovraccarico da pool condivisi).*
+ I **report dettagliati** offrono suddivisioni a livello di attività per ogni team, tenendo traccia delle ore di calcolo esatte dedicate all’esecuzione di attività specifiche, tra cui attività prerilasciate, modelli di utilizzo orari e allocazioni specifiche per il namespace.
**Importante**
HyperPod i report sull'utilizzo tengono traccia dell'utilizzo dell'elaborazione in *tutti i namespace Kubernetes* in un cluster, inclusi quelli gestiti da Task Governance, i namespace predefiniti e i namespace creati **al di fuori di Task Governance** (ad esempio, tramite chiamate API Kubernetes dirette o strumenti esterni). Questo monitoraggio a livello di infrastruttura garantisce una responsabilità completa basata sull’utilizzo e previene le incoerenze nell’attribuzione dei costi per i cluster condivisi, indipendentemente dal modo in cui vengono gestiti i namespace.
## Formati e intervallo di tempo dei report
Utilizzando lo script Python fornito in [Generazione di report](sagemaker-hyperpod-usage-reporting-generate.md), gli amministratori possono generare report di utilizzo on demand in formato CSV o PDF, selezionando intervalli di tempo che vanno da snapshot giornalieri a finestre cronologiche di 180 giorni (6 mesi).
**Nota**
Quando configuri l’infrastruttura per la creazione di report, puoi configurare la finestra cronologica in modo che vada oltre il valore massimo predefinito di 180 giorni. Per ulteriori informazioni sulla configurazione del periodo di [conservazione dei CloudFormation dati](https://github.com/awslabs/sagemaker-hyperpod-usage-report/blob/main/README.md#install-usage-report-infrastructure-using-cloudformation), consulta Installare l'infrastruttura dei report di utilizzo utilizzando.
## Casi d’uso illustrativi
Questa funzionalità affronta scenari critici in AI/ML ambienti multi-tenant come:
1. **Allocazione dei costi per i cluster condivisi**: un amministratore gestisce un HyperPod cluster condiviso da 20 team che addestrano modelli di intelligenza artificiale generativa. Utilizzando un *report di riepilogo sull’utilizzo*, analizza l’utilizzo giornaliero della GPU per 180 giorni e rileva che il Team A ha consumato 200 ore di GPU per un tipo di istanza specifico, 170 dalla sua quota allocata e 30 dalle risorse di calcolo prese in prestito. L’amministratore fattura il Team A in base all’utilizzo rilevato.
1. **Audit e risoluzione delle controversie**: un team finanziario mette in dubbio l’accuratezza dell’attribuzione dei costi, menzionando la presenza di incongruenze. L’amministratore può esportare un *report dettagliato a livello di attività* per verificare le discrepanze. Incrociando i timestamp, i tipi di istanze e i processi prerilasciati all’interno del namespace del team, il report riconcilia in modo trasparente i dati di utilizzo contestati.
# Dettagli dei report e suddivisione dei dati
SageMaker HyperPodi report sull'utilizzo forniscono due obiettivi distinti per l'analisi del consumo di risorse di calcolo: report di **riepilogo per l'allocazione dei costi e report** **dettagliati** per il controllo granulare. I report di riepilogo aggregano l’utilizzo a livello di cluster per team o namespace, evidenziando le tendenze nel confronto tra risorse di calcolo allocate e risorse di calcolo prese in prestito in tutte le risorse GPU, CPU e core Neuron. I report dettagliati analizzano le singole attività, esponendo metriche come le finestre di esecuzione, lo stato delle attività e l’utilizzo delle classi di priorità. In questa sezione, analizziamo la struttura di questi report, ne comprendiamo le metriche chiave e mostriamo come amministratori e team finanziari possono incrociare le tendenze nei riepiloghi con i dati a livello di attività per convalidare l’accuratezza dell’attribuzione dei costi, risolvere le discrepanze e ottimizzare l’infrastruttura condivisa.
## Intestazioni di report comuni
Sia i report di riepilogo che quelli dettagliati includono i metadati seguenti per contestualizzare i dati di utilizzo:
+ **ClusterName: il nome del cluster** Hyperpod orchestrato da EKS in cui sono state consumate le risorse.
+ **Tipo:** la categoria del report (`Summary Utilization Report` o `Detailed Utilization Report`).
+ **Data di generazione:** la data di creazione del report, ad esempio `2025-04-18`.
+ **Intervallo di date (UTC):** il periodo di tempo coperto, ad esempio `2025-04-16 to 2025-04-18`.
+ **Periodi di dati mancanti:** interruzioni nella raccolta dei dati dovute a tempi di inattività del cluster o a problemi di monitoraggio, ad esempio `2025-04-16 00:00:00 to 2025-04-19 00:00:00`.
## Report di riepilogo
I report di riepilogo forniscono una panoramica generale quotidiana del consumo di risorse di calcolo tra team/namespace e tra tipi di istanze, distinguendo tra l’utilizzo di risorse allocate (quota riservata) e quello di risorse prese in prestito (in prestito dal pool). Questi report sono ideali per la generazione di fatture, le dichiarazioni di attribuzione dei costi o la previsione della capacità.
*Esempio: un report di riepilogo può mostrare che il Team A ha utilizzato 200 ore di GPU, di cui 170 provengono dalla sua quota allocata e 30 sono prese in prestito.*
Ecco una suddivisione strutturata delle colonne chiave di un report di riepilogo:
+ **Data:** la data dell’utilizzo riportato (ad esempio `2025-04-18`).
+ **Namespace:** il namespace Kubernetes associato al team (ad esempio `hyperpod-ns-ml-team`).
+ **Squadra:** The team/department Owning (ad es.). `ml-team`
+ **Tipo di istanza:** l’istanza di calcolo utilizzata (ad esempio ml.g5.4xlarge).
+ **Total/Allocated/BorrowedUtilizzo (ore):** suddivisione dell'utilizzo di GPU, CPU o Neuron Core per categoria.
Dove:
+ **Utilizzo totale = utilizzo allocato \$1 utilizzo preso in prestito**
+ L’**utilizzo allocato** è il numero di ore effettive di GPU, CPU o core Neuron utilizzate da un team, con un limite massimo del 100% della quota allocata.
+ L’**utilizzo preso in prestito** è il numero di ore effettive di GPU, CPU o core Neuron utilizzate da un team *oltre la quota allocata*, prese dal pool del cluster condiviso in base alle regole di priorità della governance delle attività e alla disponibilità delle risorse.
Esempio: 72 ore di GPU totali (48 allocate, 24 prese in prestito).
**Nota**
Viene visualizzato solo l’utilizzo totale per i namespace non gestiti dalla governance delle attività.
## Report dettagliati
I report dettagliati forniscono una visibilità a livello forense sull’utilizzo del calcolo, suddividendo il consumo delle risorse per attività ed esponendo metriche granulari come le finestre di esecuzione delle attività, lo stato (ad esempio, l’esito positivo o negativo) e l’utilizzo delle classi di priorità. Questi report sono ideali per la convalida delle discrepanze di fatturazione o per garantire la conformità alle policy di governance.
Ecco una suddivisione strutturata delle colonne chiave di un report dettagliato:
+ **Data:** la data dell’utilizzo riportato (ad esempio `2025-04-18`).
+ **Inizio/fine del periodo:** la finestra di esecuzione esatta (UTC) dell’attività (ad esempio `19:54:34`).
+ **Namespace:** il namespace Kubernetes associato al team (ad esempio `hyperpod-ns-ml-team`).
+ **Squadra:** The Owning (ad team/department es.). `ml-team`
+ **Attività:** l’identificatore del processo/pod (ad esempio `pytorchjob-ml-pytorch-job-2p5zt-db686`).
+ **Istanza:** l’istanza di calcolo utilizzata (ad esempio `ml.g5.4xlarge`).
+ **Stato:** risultato dell’attività (riuscita, non riuscita, prerilasciata).
+ **Utilizzo totale:** consumo totale (ore e numero di istanze) di risorse di GPU, CPU o core Neuron.
+ **Classe di priorità:** il livello di priorità assegnato (ad esempio, training-priority).
# Generazione di report
Questa guida fornisce step-by-step istruzioni per configurare e gestire i report sull'utilizzo per i SageMaker HyperPod cluster. Segui queste procedure per implementare l’infrastruttura, generare report personalizzati e rimuovere le risorse non più necessarie.
## Configurazione dei report di utilizzo
**Nota**
Prima di configurare l'infrastruttura dei report SageMaker HyperPod sull'utilizzo nel SageMaker HyperPod cluster, assicurati di aver soddisfatto tutti i prerequisiti descritti in questo documento. [https://github.com/awslabs/sagemaker-hyperpod-usage-report/blob/main/README.md#prerequisites](https://github.com/awslabs/sagemaker-hyperpod-usage-report/blob/main/README.md#prerequisites)
La reportistica sull'utilizzo richiede HyperPod :
+ Distribuzione delle AWS risorse SageMaker HyperPod dei report sull'utilizzo utilizzando uno CloudFormation stack
+ Installazione del rapporto di SageMaker HyperPod utilizzo dell'operatore Kubernetes tramite un grafico Helm
[Puoi trovare istruzioni di installazione complete nell'archivio dei report di utilizzo. SageMaker HyperPod GitHub ](https://github.com/awslabs/sagemaker-hyperpod-usage-report/blob/main/README.md) In particolare, segui la procedura nella sezione di [configurazione](https://github.com/awslabs/sagemaker-hyperpod-usage-report/blob/main/README.md#set-up-usage-reporting).
## Generazione di report di utilizzo on demand
Una volta installati l'infrastruttura di reporting sull'utilizzo e l'operatore Kubernetes, i dati di lavoro per il SageMaker HyperPod cluster vengono automaticamente raccolti e archiviati nel bucket S3 configurato durante la configurazione. L’operatore acquisisce continuamente metriche di utilizzo dettagliate in background, creando file di dati non elaborati nella directory `raw` del bucket S3 indicato.
Per generare un rapporto sull'utilizzo su richiesta, puoi utilizzare `run.py` lo script fornito nell'[ GitHub archivio dei report di utilizzo per estrarre ed esportare le SageMaker HyperPod metriche di utilizzo](https://github.com/awslabs/sagemaker-hyperpod-usage-report/blob/main/README.md). In particolare, puoi trovare lo script e le istruzioni complete per la generazione di un report nella sezione sulla [generazione di report](https://github.com/awslabs/sagemaker-hyperpod-usage-report/blob/main/README.md#generate-reports).
Lo script consente di:
+ Specificare intervalli di date personalizzati per la generazione dei report
+ Scegliere tra i tipi di report dettagliati e di riepilogo
+ Esportare i report in formato CSV o PDF
+ Indirizzare i report a una specifica posizione S3
## Pulizia delle risorse per la creazione di report di utilizzo
Quando non ti serve più l'infrastruttura di reporting SageMaker HyperPod sull'utilizzo, segui i passaggi descritti in [Clean Up Resources](https://github.com/awslabs/sagemaker-hyperpod-usage-report/blob/main/README.md#clean-up-resources) per ripulire l'operatore e le risorse di Kubernetes (in AWS quest'ordine). La corretta eliminazione delle risorse aiuta a evitare costi inutili.
# Configurazione dello storage per i SageMaker HyperPod cluster orchestrati da Amazon EKS
L'amministratore del cluster deve configurare lo storage per consentire agli utenti di data scientist di gestire i dati di input e output e archiviare i checkpoint durante la formazione sui cluster. SageMaker HyperPod
**Gestione di set di dati di grandi dimensioni (dati di input/output)**
+ **Accesso e gestione dei dati**: i Data Scientist spesso lavorano con set di dati di grandi dimensioni necessari per addestrare i modelli di machine learning. La specificazione dei parametri di archiviazione nell’invio del lavoro consente loro di definire dove si trovano questi set di dati (ad esempio, i bucket Amazon S3 o i volumi persistenti in Kubernetes) e come accedervi durante l’esecuzione del processo.
+ **Ottimizzazione delle prestazioni**: l’efficienza dell’accesso ai dati di input può influire in modo significativo sulle prestazioni del job di addestramento. Ottimizzando i parametri di archiviazione, i data scientist possono garantire che i dati vengano letti e scritti in modo efficiente, riducendo i colli di bottiglia. I/O
**Archiviazione dei checkpoint**
+ **Checkpoint durante l’addestramento**: durante i job di addestramento di lunga durata, è prassi comune salvare dei checkpoint, ovvero degli stati intermedi del modello. Questo consente ai Data Scientist di riprendere l’addestramento da un punto specifico in caso di guasto, anziché ricominciare da zero.
+ **Recupero e sperimentazione dei dati**: specificando la posizione di archiviazione per i checkpoint, i Data Scientist possono garantire che questi checkpoint siano archiviati in modo sicuro, possibilmente in un sistema di archiviazione distribuito che offre ridondanza e alta disponibilità. Questo è fondamentale per il ripristino dopo le interruzioni e per condurre esperimenti sulle diverse strategie di addestramento.
**Suggerimento**
Per un'esperienza pratica e linee guida su come configurare lo storage per SageMaker HyperPod cluster orchestrato con Amazon EKS, consulta le seguenti sezioni del workshop [Amazon EKS Support](https://catalog.us-east-1.prod.workshops.aws/workshops/2433d39e-ccfe-4c00-9d3d-9917b729258e) in corso. SageMaker HyperPod
[Configura Amazon FSx for Lustre su SageMaker HyperPod](https://catalog.us-east-1.prod.workshops.aws/workshops/2433d39e-ccfe-4c00-9d3d-9917b729258e/en-US/01-cluster/06-fsx-for-lustre)
[Configurare un punto di montaggio per Amazon S3 [utilizzando Mountpoint](https://docs.aws.amazon.com/AmazonS3/latest/userguide/mountpoint.html) per Amazon](https://catalog.us-east-1.prod.workshops.aws/workshops/2433d39e-ccfe-4c00-9d3d-9917b729258e/en-US/01-cluster/09-s3-mountpoint) S3
# Utilizzo del driver CSI Amazon EBS su SageMaker HyperPod cluster EKS
SageMaker HyperPod supporta il driver Amazon Elastic Block Store (Amazon EBS) Container Storage Interface (CSI), che gestisce il ciclo di vita dei volumi Amazon EBS come storage per i volumi Kubernetes che crei. Con il driver Amazon EBS CSI, puoi creare, collegare e gestire i volumi Amazon EBS per i carichi di lavoro di machine learning in esecuzione su cluster SageMaker HyperPod con orchestrazione Amazon EKS.
**Topics**
+ [Funzionalità chiave di archiviazione](#sagemaker-hyperpod-eks-ebs-features)
+ [Casi d’uso](#sagemaker-hyperpod-eks-ebs-use)
+ [Configurazione del driver CSI Amazon EBS sui SageMaker HyperPod cluster EKS](#sagemaker-hyperpod-eks-ebs-setup)
+ [Usando il APIs](#sagemaker-hyperpod-eks-ebs-setup-apis)
## Funzionalità chiave di archiviazione
Il driver CSI di Amazon EBS SageMaker HyperPod supporta le seguenti funzionalità di storage.
+ Provisioning statico: associa i volumi Amazon EBS precreati ai [volumi persistenti Kubernetes](https://kubernetes.io/docs/concepts/storage/persistent-volumes/) da utilizzare nei pod.
+ Provisioning dinamico: crea automaticamente i volumi Amazon EBS e i volumi persistenti associati da [https://kubernetes.io/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims). I parametri possono essere passati tramite [https://kubernetes.io/docs/concepts/storage/storage-classes/](https://kubernetes.io/docs/concepts/storage/storage-classes/) per un controllo granulare sulla creazione dei volumi.
+ Ridimensionamento dei volumi: espande i volumi esistenti aggiornando le specifiche delle dimensioni in [https://kubernetes.io/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) senza arrestare l’esecuzione dei carichi di lavoro. Questa opzione potrebbe essere essenziale per gestire repository di modelli in crescita o adattarsi a nodi più grandi senza interrompere il servizio.
+ Istantanee di volume: crea point-in-time istantanee di volumi per il backup, il ripristino e il controllo delle versioni dei dati.
+ Volumi a blocchi: fornisce l’accesso ai dispositivi a blocchi non elaborati per applicazioni ad alte prestazioni che richiedono l’accesso diretto all’archiviazione.
+ Modifica del volume: modifica le proprietà del volume, ad esempio il tipo, le operazioni di input o output al secondo (IOPS) o il throughput utilizzando le [classi di attributi del volume](https://kubernetes.io/docs/concepts/storage/volume-attributes-classes/).
Per ulteriori informazioni sul driver CSI di Amazon EBS, consulta [Use Kubernetes volume storage with Amazon EBS](https://docs.aws.amazon.com/eks/latest/userguide/ebs-csi.html) in *Amazon EKS User Guide*.
Per ulteriori informazioni sull’archiviazione nei pod del cluster, consulta [Storage](https://kubernetes.io/docs/concepts/storage/) nella *documentazione di Kubernetes*.
## Casi d’uso
L'integrazione dei driver CSI di Amazon EBS consente diversi casi d'uso chiave per carichi di lavoro di formazione e inferenza su cluster EKS. SageMaker HyperPod
**Carichi di lavoro di addestramento**
+ Archiviazione di set di dati: alloca volumi per set di dati di addestramento che persistono anche dopo il riavvio del pod.
+ Archiviazione dei checkpoint: salva i checkpoint del modello e i risultati intermedi dell’addestramento.
+ Artefatti condivisi: accedi a set di dati comuni e ad artefatti dei modelli in più job di addestramento.
**Carichi di lavoro di inferenza**
+ Archiviazione dei modelli: alloca dinamicamente volumi di dimensione appropriata in base ai requisiti del modello.
+ Caching dei container: crea un’archiviazione temporanea per migliorare le prestazioni di inferenza.
+ Registrazione di log degli eventi: archivia i risultati di inferenza e i log con archiviazione persistente.
## Configurazione del driver CSI Amazon EBS sui SageMaker HyperPod cluster EKS
Il driver Amazon Elastic Block Store (Amazon EBS) Container Storage Interface (CSI) consente di effettuare il provisioning e gestire dinamicamente i volumi Amazon EBS per i carichi di lavoro containerizzati in esecuzione su cluster con orchestrazione EKS. SageMaker HyperPod Questa sezione descrive l’installazione e la configurazione del driver CSI di Amazon EBS per abilitare l’archiviazione persistente per i carichi di lavoro di machine learning.
### Prerequisiti
Prima di iniziare, esegui queste attività:
+ [Installa e configura AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html)
+ [Crea un SageMaker HyperPod cluster con l'orchestrazione di Amazon EKS](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-eks-operate-console-ui-create-cluster.html)
+ Installazione del driver CSI di Amazon EBS versione [v1.47.0](https://github.com/kubernetes-sigs/aws-ebs-csi-driver/blob/master/CHANGELOG.md#v1470)
### Autorizzazioni aggiuntive
Per configurare il componente aggiuntivo del driver CSI di Amazon EBS, segui le istruzioni in [Use Kubernetes volume storage with Amazon EBS](https://docs.aws.amazon.com/eks/latest/userguide/ebs-csi.html) in *Amazon EKS User Guide*. Devi anche aggiungere le autorizzazioni seguenti al ruolo IAM utilizzato per eseguire il componente aggiuntivo del driver. Tieni presente che questo è il ruolo IAM specificato nella configurazione dell'account di servizio per il driver aggiuntivo, non il ruolo di esecuzione del HyperPod cluster.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":
[
{
"Effect": "Allow",
"Action":
[
"sagemaker:AttachClusterNodeVolume",
"sagemaker:DetachClusterNodeVolume"
],
"Resource": "arn:aws:sagemaker:us-east-1:111122223333:cluster/*"
},
{
"Effect": "Allow",
"Action":
[
"eks:DescribeCluster"
],
"Resource": "arn:aws:eks:us-east-1:111122223333:cluster/my-cluster-name"
}
]
}
```
------
## Usando il APIs
In alternativa, puoi utilizzare le operazioni [AttachClusterNodeVolume](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_AttachClusterNodeVolume.html)e [DetachClusterNodeVolume](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_DetachClusterNodeVolume.html)API per collegare e scollegare i volumi Amazon EBS alle istanze del cluster SageMaker HyperPod EKS.
**I requisiti chiave per il loro utilizzo APIs includono quanto segue.**
+ Sia il volume Amazon EBS che il cluster SageMaker HyperPod EKS devono essere di proprietà dello stesso Account AWS.
+ Il principale che esegue la chiamata necessita di autorizzazioni minime specifiche per eseguire correttamente l’operazione di collegamento o scollegamento. Per ulteriori informazioni su queste autorizzazioni, consulta le sezioni seguenti.
+ Dopo aver collegato un volume al HyperPod nodo, segui le istruzioni in [Accesso ai nodi del SageMaker HyperPod cluster](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-eks-operate-access-through-terminal.html) per accedere al nodo del cluster e [Rendere disponibile un volume da utilizzare per](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-using-volumes.html) montare il volume collegato.
### Autorizzazioni necessarie per `sagemaker:AttachClusterNodeVolume`
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":
[
{
"Effect": "Allow",
"Action":
[
"sagemaker:AttachClusterNodeVolume"
],
"Resource": "arn:aws:sagemaker:us-east-1:111122223333:cluster/*"
},
{
"Effect": "Allow",
"Action":
[
"eks:DescribeCluster"
],
"Resource": "arn:aws:eks:us-east-1:111122223333:cluster/my-cluster-name"
},
{
"Effect": "Allow",
"Action":
[
"ec2:AttachVolume",
"ec2:DescribeVolumes"
],
"Resource": "arn:aws:ec2:us-east-1:111122223333:volume/*"
}
]
}
```
------
### Autorizzazioni necessarie per `sagemaker:DetachClusterNodeVolume`
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":
[
{
"Effect": "Allow",
"Action":
[
"sagemaker:DetachClusterNodeVolume"
],
"Resource": "arn:aws:sagemaker:us-east-1:111122223333:cluster/*"
},
{
"Effect": "Allow",
"Action":
[
"eks:DescribeCluster"
],
"Resource": "arn:aws:eks:us-east-1:111122223333:cluster/my-cluster-name"
},
{
"Effect": "Allow",
"Action":
[
"ec2:DetachVolume",
"ec2:DescribeVolumes"
],
"Resource": "arn:aws:ec2:us-east-1:111122223333:volume/*"
}
]
}
```
------
### Autorizzazioni richieste per le chiavi AWS KMS
Aggiungi le seguenti AWS KMS autorizzazioni solo se utilizzi chiavi KMS gestite dal cliente per crittografare i volumi Amazon EBS collegati ai nodi del cluster. HyperPod Queste autorizzazioni non sono necessarie se utilizzi chiavi KMS gestite da AWS(l’opzione di crittografia predefinita).
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Id": "key-default-1",
"Statement":
[
{
"Effect": "Allow",
"Principal":
{
"AWS": "arn:aws:iam::111122223333:role/caller-role"
},
"Action": "kms:DescribeKey",
"Resource": "*"
},
{
"Effect": "Allow",
"Principal":
{
"AWS": "arn:aws:iam::111122223333:role/caller-role"
},
"Action": "kms:CreateGrant",
"Resource": "*",
"Condition":
{
"StringEquals":
{
"kms:CallerAccount": "111122223333",
"kms:ViaService": "ec2.us-east-1.amazonaws.com"
},
"ForAnyValue:StringEquals":
{
"kms:EncryptionContextKeys": "aws:ebs:id"
},
"Bool":
{
"kms:GrantIsForAWSResource": true
},
"ForAllValues:StringEquals":
{
"kms:GrantOperations":
[
"Decrypt"
]
}
}
}
]
}
```
------
**Nota**
Queste AWS KMS autorizzazioni non sono necessarie `sagemaker:DetachClusterNodeVolume` quando si scollega un volume Cluster Auto Volume Attachment (CAVA) crittografato con chiavi KMS gestite dal cliente.
# Configurazione di etichette e colori Kubernetes personalizzati in Amazon SageMaker HyperPod
SageMaker HyperPod I cluster Amazon con orchestrator Amazon Elastic Kubernetes Service (Amazon EKS) supportano etichette e taint Kubernetes personalizzati per i nodi all'interno dei gruppi di istanze. Le etichette e i taint sono meccanismi di pianificazione e organizzazione fondamentali in Kubernetes che offrono un controllo preciso sul posizionamento dei pod e sull'utilizzo delle risorse.
Le etichette sono coppie chiave-valore che possono essere allegate agli oggetti Kubernetes e consentono di organizzare e selezionare le risorse in base agli attributi. I taint, che funzionano insieme alle tolleranze, sono proprietà specifiche dei nodi che influenzano la pianificazione dei pod respingendo i pod che non hanno tolleranze corrispondenti. Insieme, questi meccanismi consentono di isolare i carichi di lavoro, assegnarli in base alle specifiche hardware e garantire un utilizzo ottimale delle risorse.
## Casi di utilizzo comune
Di seguito sono riportati gli scenari più comuni in cui etichette e colorazioni personalizzate sono vantaggiose:
+ **Prevenzione dei pod di sistema su istanze costose: applica dei trucchi alle istanze** GPU per evitare che i pod di sistema e altri carichi di lavoro non critici consumino costose risorse di elaborazione
+ **Integrazione con gli strumenti esistenti: applica etichette che corrispondono ai modelli di infrastruttura e** alle configurazioni di affinità dei nodi stabiliti dall'organizzazione
## Configurazione di etichette e colorazioni
Puoi configurare etichette e taint Kubernetes personalizzati a livello di gruppo di istanze utilizzando il parametro nella configurazione del `KubernetesConfig` cluster. Le etichette e i taint vengono applicati a tutti i nodi del gruppo di istanze e persistono per tutto il ciclo di vita del cluster.
Il `KubernetesConfig` parametro è dichiarativo, il che significa che si specifica lo stato completo desiderato di etichette e taint per un gruppo di istanze. SageMaker HyperPod quindi riconcilia lo stato effettivo dei nodi in modo che corrisponda allo stato desiderato.
+ **Aggiungere etichette o tinte**: includi le nuove etichette o tinte `KubernetesConfig` insieme a quelle esistenti che desideri conservare
+ **Aggiornamento di etichette o tinte**: modifica i valori delle `KubernetesConfig` etichette o delle tinte che desideri modificare e includi tutte le altre che desideri conservare
+ **Rimozione di etichette o tinte**: ometti le etichette o le sfumature che desideri rimuovere`KubernetesConfig`, mantenendo solo quelle che desideri conservare
### Creazione di un cluster con etichette e tinte
Quando crei un nuovo SageMaker HyperPod cluster, includi il `KubernetesConfig` parametro nella configurazione del gruppo di istanze. L'esempio seguente mostra come creare un cluster con etichette e tinte personalizzate:
```
{
"ClusterName": "my-cluster",
"InstanceGroups": [{
"InstanceGroupName": "worker-group-1",
"InstanceType": "ml.p4d.24xlarge",
"InstanceCount": 4,
"LifeCycleConfig": {
"SourceS3Uri": "s3://my-bucket/lifecycle-config.sh",
"OnCreate": "on-create.sh"
},
"ExecutionRole": "arn:aws:iam::123456789012:role/HyperPodExecutionRole",
"ThreadsPerCore": 1,
"KubernetesConfig": {
"Labels": {
"env": "prod",
"team": "ml-training",
"gpu-type": "a100"
},
"Taints": [{
"key": "gpu",
"value": "true",
"effect": "NoSchedule"
},
{
"key": "dedicated",
"value": "ml-workloads",
"effect": "NoExecute"
}]
}
}],
"VpcConfig": {
"SecurityGroupIds": ["sg-0123456789abcdef0"],
"Subnets": ["subnet-0123456789abcdef0", "subnet-0123456789abcdef1"]
},
"Orchestrator": {
"Eks": {
"ClusterArn": "arn:aws:eks:us-west-2:123456789012:cluster/my-eks-cluster"
}
}
}
```
In questo esempio:
+ **Etichette**: vengono applicate tre etichette personalizzate:`env=prod`,`team=ml-training`, e `gpu-type=a100`
+ **Taints**: due taint sono configurati per impedire la pianificazione indesiderata dei pod
### Aggiornamento di etichette e segni distintivi su un cluster esistente
È possibile modificare etichette e caratteri su un cluster esistente utilizzando l'`UpdateCluster`API. L'esempio seguente mostra come aggiornare il gruppo `KubernetesConfig` for an instance:
```
{
"ClusterName": "my-cluster",
"InstanceGroups": [{
"InstanceGroupName": "worker-group-1",
"KubernetesConfig": {
"Labels": {
"env": "prod",
"team": "ml-training",
"gpu-type": "a100",
"cost-center": "ml-ops"
},
"Taints": [{
"key": "gpu",
"value": "true",
"effect": "NoSchedule"
}]
}
}]
}
```
Quando aggiorni etichette e tinte, SageMaker HyperPod applica le modifiche a tutti i nodi del gruppo di istanze. Il servizio gestisce la transizione dallo stato corrente a quello desiderato, che è possibile monitorare utilizzando l'`DescribeCluster`API.
## Monitoraggio dell'etichetta e dell'applicazione di contaminazione
SageMaker HyperPod consente APIs di monitorare lo stato delle etichette e dei coloranti man mano che vengono applicati ai nodi del cluster.
### Verifica dello stato a livello di cluster
Utilizza l'`DescribeCluster`API per visualizzare lo stato attuale e desiderato delle etichette e dei coloranti a livello di gruppo di istanze. L'esempio seguente mostra la struttura della risposta:
```
{
"ClusterName": "my-cluster",
"ClusterStatus": "InService",
"InstanceGroups": [{
"InstanceGroupName": "worker-group-1",
"InstanceType": "ml.p4d.24xlarge",
"CurrentInstanceCount": 4,
"TargetInstanceCount": 4,
"KubernetesConfig": {
"CurrentLabels": {
"env": "prod",
"team": "ml-training",
"gpu-type": "a100"
},
"DesiredLabels": {
"env": "prod",
"team": "ml-training",
"gpu-type": "a100"
},
"CurrentTaints": [{
"key": "gpu",
"value": "true",
"effect": "NoSchedule"
}],
"DesiredTaints": [{
"key": "gpu",
"value": "true",
"effect": "NoSchedule"
}]
}
}]
}
```
In caso di `CurrentLabels` `CurrentTaints` corrispondenza `DesiredLabels``DesiredTaints`, a tutti i nodi del gruppo di istanze viene applicata la configurazione specificata. Se differiscono, il cluster sta ancora applicando le modifiche.
### Verifica dello stato dei singoli nodi
Per i dettagli a livello di nodo, usa l'`DescribeClusterNode`API per controllare l'etichetta e la configurazione del colore dei singoli nodi. L'esempio seguente mostra la struttura della risposta:
```
{
"NodeDetails": {
"InstanceId": "i-0123456789abcdef0",
"InstanceGroupName": "worker-group-1",
"InstanceType": "ml.p4d.24xlarge",
"InstanceStatus": {
"Status": "Running",
"Message": "Node is healthy"
},
"LifeCycleConfig": {
"SourceS3Uri": "s3://my-bucket/lifecycle-config.sh",
"OnCreate": "on-create.sh"
},
"LaunchTime": 1699564800.0,
"KubernetesConfig": {
"CurrentLabels": {
"env": "prod",
"team": "ml-training",
"gpu-type": "a100"
},
"DesiredLabels": {
"env": "prod",
"team": "ml-training",
"gpu-type": "a100"
},
"CurrentTaints": [{
"key": "gpu",
"value": "true",
"effect": "NoSchedule"
}],
"DesiredTaints": [{
"key": "gpu",
"value": "true",
"effect": "NoSchedule"
}]
}
}
}
```
Il monitoraggio a livello di nodo è utile per la risoluzione dei problemi quando etichette o contaminazioni non si applicano correttamente a nodi specifici o quando è necessario verificare la configurazione di una particolare istanza.
## Prefissi riservati
Alcuni prefissi sono riservati all'uso del sistema e non devono essere utilizzati per etichette o colorazioni personalizzate. I seguenti prefissi sono riservati:
+ `kubernetes.io/`- Riservato ai componenti principali di Kubernetes
+ `k8s.io/`- Riservato ai componenti principali di Kubernetes
+ `sagemaker.amazonaws.com/`- Riservato per SageMaker HyperPod
+ `eks.amazonaws.com/`- Riservato ad Amazon EKS
+ `k8s.aws/`- Riservato ad Amazon EKS
+ `karpenter.sh/`- Riservato alla scalabilità automatica di Karpenter
Le etichette e le macchie con questi prefissi sono gestite dai componenti del sistema e non devono essere sovrascritte con valori personalizzati.
# Formazione senza checkpointless in Amazon SageMaker HyperPod
La formazione Checkpointless su Amazon SageMaker HyperPod consente un ripristino più rapido dai guasti dell'infrastruttura di formazione. La seguente documentazione ti aiuta a iniziare con la formazione senza checkpoint e la messa a punto per i modelli supportati. NeMo
La formazione Checkpointless ha i seguenti prerequisiti:
+ [Inizia a usare il supporto di Amazon EKS in SageMaker HyperPod](sagemaker-hyperpod-eks-prerequisites.md)
+ [Installazione dell’operatore di addestramento](sagemaker-eks-operator-install.md). È necessario installare la versione 1.2.0 o successiva.
Checkpointless training on SageMaker HyperPod si basa sulla Guida per l'utente di [ NeMo NVIDIA](https://docs.nvidia.com/nemo-framework/user-guide/latest/nemotoolkit/core/exp_manager.html#experiment-manager) Framework. Puoi eseguire corsi di formazione senza checkpointless con ricette precreate. SageMaker HyperPod Se le conosci NeMo, il processo di utilizzo delle ricette di formazione senza checkpoint è simile. Con piccole modifiche, puoi iniziare ad addestrare un modello utilizzando funzionalità di allenamento senza checkpoint che ti consentono di recuperare rapidamente dagli errori di allenamento.
Le seguenti HyperPod ricette sono preconfigurate con ottimizzazioni dell'allenamento senza checkpoint. Puoi specificare i percorsi dei dati come parte della ricetta e utilizzare lo script di avvio associato per eseguire la formazione (consulta la guida rapida di avvio di seguito):
| Modello | Metodo | Dimensione | Nodi | Istanza | Accelerator | Recipe | Script | Tutorial |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| GPT OSS | Esempio completo di finetune | 120 g | 16 | p5.48xlarge | GPU H100 | [collegamento](https://github.com/aws/sagemaker-hyperpod-recipes/tree/main/recipes_collection/recipes/fine-tuning/gpt_oss/checkpointless_gpt_oss_120b_full_fine_tuning.yaml) | [collegamento](https://github.com/aws/sagemaker-hyperpod-recipes/tree/main/launcher_scripts/gpt_oss/run_checkpointless_gpt_oss_120b_full_fine_tuning.sh) | [collegamento](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-eks-checkpointless-recipes-finetune.html) |
| GPT BOSS | Esempio di LoRa | 120 b | 2 | p5.48xlarge | GPU H100 | [collegamento](https://github.com/aws/sagemaker-hyperpod-recipes/tree/main/recipes_collection/recipes/fine-tuning/gpt_oss/checkpointless_gpt_oss_120b_lora.yaml) | [collegamento](https://github.com/aws/sagemaker-hyperpod-recipes/tree/main/launcher_scripts/gpt_oss/run_checkpointless_gpt_oss_120b_lora.sh) | [collegamento](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-eks-checkpointless-recipes-peft.html) |
| Lama 3 | Esempio di pre-allenamento | 70 b | 16 | p5.48xlarge | GPU H100 | [collegamento](https://github.com/aws/sagemaker-hyperpod-recipes/tree/main/recipes_collection/recipes/training/llama/checkpointless_llama3_70b_pretrain.yaml) | [collegamento](https://github.com/aws/sagemaker-hyperpod-recipes/tree/main/launcher_scripts/llama/run_checkpointless_llama3_70b_pretrain.sh) | [collegamento](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-eks-checkpointless-recipes-pretraining-llama3.html) |
| Lama 3 | Esempio di Lora | 70 b | 2 | p5.48xlarge | GPU H100 | [collegamento](https://github.com/aws/sagemaker-hyperpod-recipes/tree/main/recipes_collection/recipes/fine-tuning/llama/checkpointless_llama3_70b_lora.yaml) | [collegamento](https://github.com/aws/sagemaker-hyperpod-recipes/tree/main/launcher_scripts/llama/run_checkpointless_llama3_70b_lora.sh) | [collegamento](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-eks-checkpointless-recipes-peft-llama.html) |
La seguente guida rapida fornisce tutorial per l'utilizzo di ricette di formazione senza checkpoint:
**Esempi introduttivi**
+ [Tutorial - Ottimizzazione completa di Amazon SageMaker HyperPod Checkpointless GPT OSS 120b](sagemaker-eks-checkpointless-recipes-finetune.md)
+ [Tutorial - Amazon SageMaker HyperPod Checkpointless Left-LoRa GPT OSS 120b](sagemaker-eks-checkpointless-recipes-peft.md)
+ [Tutorial - Amazon SageMaker HyperPod Checkpointless Pretraining Llama 3 70b](sagemaker-eks-checkpointless-recipes-pretraining-llama3.md)
+ [Tutorial - Amazon SageMaker HyperPod Checkpointless Left-Lora Llama 3 70b](sagemaker-eks-checkpointless-recipes-peft-llama.md)
Se desideri pre-addestrare o perfezionare i modelli personalizzati, consulta. [Tutorial - Amazon SageMaker HyperPod Checkpointless, preaddestramento o messa a punto di modelli personalizzati](sagemaker-eks-checkpointless-recipes-custom.md)
Per ulteriori informazioni sull'integrazione di componenti di formazione specifici senza checkpoint,. [HyperPod funzionalità di formazione senza checkpointless](sagemaker-eks-checkpointless-features.md)
# Tutorial di formazione SageMaker HyperPod senza checkpoint su Amazon
[ HyperPod Le ricette di formazione checkpointless](https://github.com/aws/sagemaker-hyperpod-checkpointless-training) sono configurazioni di lavoro predefinite con funzionalità di formazione senza checkpointless abilitate. L'utilizzo di queste ricette semplifica l'avvio di corsi di formazione senza checkpoint. HyperPod
**Topics**
+ [Tutorial - Ottimizzazione completa di Amazon SageMaker HyperPod Checkpointless GPT OSS 120b](sagemaker-eks-checkpointless-recipes-finetune.md)
+ [Tutorial - Amazon SageMaker HyperPod Checkpointless Left-LoRa GPT OSS 120b](sagemaker-eks-checkpointless-recipes-peft.md)
+ [Tutorial - Amazon SageMaker HyperPod Checkpointless Pretraining Llama 3 70b](sagemaker-eks-checkpointless-recipes-pretraining-llama3.md)
+ [Tutorial - Amazon SageMaker HyperPod Checkpointless Left-Lora Llama 3 70b](sagemaker-eks-checkpointless-recipes-peft-llama.md)
+ [Tutorial - Amazon SageMaker HyperPod Checkpointless, preaddestramento o messa a punto di modelli personalizzati](sagemaker-eks-checkpointless-recipes-custom.md)
# Tutorial - Ottimizzazione completa di Amazon SageMaker HyperPod Checkpointless GPT OSS 120b
La seguente sequenza di passaggi è necessaria per eseguire ricette di formazione senza checkpoint. HyperPod
## Prerequisiti
Prima di iniziare a configurare l’ambiente, assicurati di avere:
+ [Supporto Amazon EKS abilitato in Amazon SageMaker HyperPod](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-eks-prerequisites.html)
+ [Configura l'operatore HyperPod di formazione (v1.2\$1)](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-eks-operator.html)
+ Una posizione di archiviazione condivisa. Può essere un FSx file system Amazon o un sistema NFS accessibile dai nodi del cluster.
+ I dati in uno dei seguenti formati:
+ JSON
+ JSONGZ (JSON compresso)
+ ARROW
+ [Scegli una ricetta di formazione supportata senza checkpoint per Llama 70B o GPT-OSS 120B dalla fonte.](https://github.com/aws/sagemaker-hyperpod-recipes/tree/main/recipes_collection)
+ [Scaricate i pesi del modello Hugging](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-eks-checkpointless-release-notes.html) [Face e convertiteli nel formato supportato da Nemo.](https://docs.nvidia.com/nemo-framework/user-guide/latest/nemo-2.0/features/hf-integration.html#importing-from-hugging-face)
+ Configurare l’ambiente
## Configurazione dell'ambiente Kubernetes
Per configurare l'ambiente Kubernetes, procedi come segue:
1. Configura l’ambiente virtuale. Assicurati che la tua versione di Python sia maggiore o uguale a 3.10 e inferiore a 3.14.
```
python3 -m venv ${PWD}/venv
source venv/bin/activate
```
1. [Configura kubectl ed eksctl](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html)
1. [Installa Helm](https://helm.sh/docs/intro/install/)
1. Connettiti al cluster Kubernetes.
```
aws eks update-kubeconfig --region "${CLUSTER_REGION}" --name "${CLUSTER_NAME}"
```
1. Installa le dipendenze utilizzando uno dei metodi seguenti:
1. Metodo 1: metodo SageMaker HyperPod delle ricette:
```
# install SageMaker HyperPod Recipes.
git clone --recursive git@github.com:aws/sagemaker-hyperpod-recipes.git
cd sagemaker-hyperpod-recipes
pip3 install -r requirements.txt
```
1. Metodo 2: kubectl con metodo job yaml predefinito
```
# install SageMaker HyperPod checkpointless training.
git clone git@github.com:aws/sagemaker-hyperpod-checkpointless-training.git
cd sagemaker-hyperpod-checkpointless-training
```
Ora puoi lanciare la ricetta di allenamento senza checkpointless usando il programma di avvio -style o usando kubectl. NeMo
## Avvia i lavori di formazione con il programma di avvio delle ricette
Puoi utilizzare le SageMaker HyperPod ricette di Amazon per inviare il tuo lavoro di formazione. L'utilizzo delle ricette comporta l'aggiornamento di k8s.yaml, config.yaml e l'esecuzione dello script di avvio.
1. Aggiornamento di `launcher_scripts/gpt_oss/run_checkpointless_gpt_oss_120b_full_fine_tuning.sh`
your\$1container: Un contenitore di Deep Learning. Per trovare la versione più recente del contenitore di formazione checkpointless, consulta le note sulla versione di [checkpointless](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-eks-checkpointless-release-notes.html) training.
```
#!/bin/bash
SAGEMAKER_TRAINING_LAUNCHER_DIR=${SAGEMAKER_TRAINING_LAUNCHER_DIR:-"$(pwd)"}
TRAIN_DIR="${TRAIN_DIR}"
VAL_DIR="${VAL_DIR}"
EXP_DIR="${EXP_DIR}"
LOG_DIR="${LOG_DIR}"
CONTAINER_MOUNT="/data"
CONTAINER="${CONTAINER}"
MODEL_NAME_OR_PATH="${MODEL_NAME_OR_PATH}"
HYDRA_FULL_ERROR=1 python3 "${SAGEMAKER_TRAINING_LAUNCHER_DIR}/main.py" \
recipes=fine-tuning/gpt_oss/checkpointless_gpt_oss_120b_full_fine_tuning \
recipes.dataset.dataset_path="${TRAIN_DIR}" \
recipes.exp_manager.exp_dir="${EXP_DIR}" \
recipes.log_dir="${LOG_DIR}" \
recipes.resume.restore_config.path="${MODEL_NAME_OR_PATH}" \
base_results_dir="${SAGEMAKER_TRAINING_LAUNCHER_DIR}/results" \
git.use_default=false \
cluster=k8s \
cluster_type=k8s \
container="${CONTAINER}" \
+cluster.hostNetwork=true \
+cluster.persistent_volume_claims.0.claimName=fsx-claim \
+cluster.persistent_volume_claims.0.mountPath="${CONTAINER_MOUNT}" \
+recipes.dataset.val_dataset_path="${VAL_DIR}" \
++recipes.callbacks.3.test_fault_config.fault_prob_between_lock=1 \
```
1. Avvio del job di addestramento
```
bash launcher_scripts/gpt_oss/run_checkpointless_gpt_oss_120b_full_fine_tuning.sh
```
Dopo aver inviato il job di addestramento, puoi utilizzare il comando seguente per verificare se l’invio è riuscito.
```
kubectl get pods
NAME READY STATUS RESTARTS AGE
gpt-oss-120b-worker-0 0/1 running 0 36s
```
Se lo STATUS è in sospeso o ContainerCreating, esegui il comando seguente per ottenere maggiori dettagli
```
kubectl describe pod
```
Quando lo STATUS del processo diventa Running, puoi esaminare il log utilizzando il comando seguente.
```
kubectl logs
```
`STATUS` diventa `COMPLETED` quando esegui `kubectl get pods`.
## Avvia il processo di formazione con kubectl con yaml predefinito
Un'altra opzione è avviare la formazione tramite kubectl con un job predefinito yaml.
1. aggiorna examples/gpt\$1oss/launch/full \$1finetune\$1gpt\$1oss\$1120b\$1checkpointless\$1p5.yaml
+ immagine: Un contenitore di Deep Learning. Per trovare la versione più recente del contenitore di formazione checkpointless, consulta le note sulla versione di [checkpointless](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-eks-checkpointless-release-notes.html) training.
+ [resume.restore\$1config.path=: il percorso per scaricare i pesi dei modelli preaddestrati in formato Nemo nella fase Prerequisiti.](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-eks-checkpointless-recipes-finetune.html#sagemaker-eks-checkpointless-recipes-finetune-prereqs)
+ dataset.dataset\$1path=: il percorso del set di dati archiviato nella memoria condivisa
1. Invia il lavoro usando kubectl con full\$1finetune\$1gpt\$1oss\$1120b\$1checkpointless\$1p5.yaml
```
kubectl apply -f examples/gpt_oss/launch/full_finetune_gpt_oss_120b_checkpointless_p5.yaml
```
Dopo aver inviato il job di addestramento, puoi utilizzare il comando seguente per verificare se l’invio è riuscito.
```
kubectl get pods
NAME READY STATUS RESTARTS AGE
gpt-oss-120b-worker-0 0/1 running 0 36s
```
Se lo STATUS è in sospeso o, esegui il seguente comando per ottenere maggiori dettagli ContainerCreating
```
kubectl describe pod
```
Quando lo STATUS del processo diventa Running, puoi esaminare il log utilizzando il comando seguente.
```
kubectl logs
```
Lo STATUS diventerà Completato quando esegui kubectl get pods
# Tutorial - Amazon SageMaker HyperPod Checkpointless Left-LoRa GPT OSS 120b
La seguente sequenza di passaggi è necessaria per eseguire ricette di formazione senza checkpoint. HyperPod
## Prerequisiti
Prima di iniziare a configurare l’ambiente, assicurati di avere:
+ [Supporto Amazon EKS abilitato in Amazon SageMaker HyperPod](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-eks-prerequisites.html)
+ [Configura l'operatore HyperPod di formazione (v1.2\$1)](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-eks-operator.html)
+ Una posizione di archiviazione condivisa. Può essere un FSx file system Amazon o un sistema NFS accessibile dai nodi del cluster.
+ I dati in uno dei seguenti formati:
+ JSON
+ JSONGZ (JSON compresso)
+ ARROW
+ [Scegli una ricetta di formazione supportata senza checkpoint per Llama 70B o GPT-OSS 120B dalla fonte.](https://github.com/aws/sagemaker-hyperpod-recipes/tree/main/recipes_collection)
+ [Scaricate i pesi del modello Hugging](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-eks-checkpointless-release-notes.html) [Face e convertiteli nel formato supportato da Nemo.](https://docs.nvidia.com/nemo-framework/user-guide/latest/nemo-2.0/features/hf-integration.html#importing-from-hugging-face)
+ Configurare l’ambiente
## Configurazione dell'ambiente Kubernetes
Per configurare l'ambiente Kubernetes, procedi come segue:
1. Configura l’ambiente virtuale. Assicurati di usare Python maggiore o uguale a 3.10 e < 3.14.
```
python3 -m venv ${PWD}/venv
source venv/bin/activate
```
1. [Configura kubectl ed eksctl](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html)
1. [Installa Helm](https://helm.sh/docs/intro/install/)
1. Connettiti al cluster Kubernetes.
```
aws eks update-kubeconfig --region "${CLUSTER_REGION}" --name "${CLUSTER_NAME}"
```
1. Installa le dipendenze utilizzando uno dei metodi seguenti:
+ SageMaker HyperPod metodo delle ricette:
```
# install SageMaker HyperPod Recipes.
git clone --recursive git@github.com:aws/sagemaker-hyperpod-recipes.git
cd sagemaker-hyperpod-recipes
pip3 install -r requirements.txt
```
+ kubectl con metodo job yaml predefinito
```
# install SageMaker HyperPod checkpointless training.
git clone git@github.com:aws/sagemaker-hyperpod-checkpointless-training.git
cd sagemaker-hyperpod-checkpointless-training
```
Ora puoi lanciare la ricetta di allenamento senza checkpointless usando il programma di avvio -style o usando kubectl. NeMo
## Avvio del job di addestramento con l’utilità di avvio delle ricette
In alternativa, puoi utilizzare le SageMaker HyperPod ricette per inviare il tuo lavoro di formazione. L'uso delle ricette comporta l'aggiornamento di k8s.yaml, config.yaml e l'esecuzione dello script di avvio.
1. Aggiornamento di `launcher_scripts/gpt_oss/run_checkpointless_gpt_oss_120b_lora.sh`
your\$1contrainer: un contenitore di Deep Learning. [Per trovare la versione più recente del contenitore di formazione checkpointless, consulta le note sulla versione di checkpointless training.](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-eks-checkpointless-release-notes.html)
```
#!/bin/bash
SAGEMAKER_TRAINING_LAUNCHER_DIR=${SAGEMAKER_TRAINING_LAUNCHER_DIR:-"$(pwd)"}
TRAIN_DIR="${TRAIN_DIR}"
VAL_DIR="${VAL_DIR}"
EXP_DIR="${EXP_DIR}"
LOG_DIR="${LOG_DIR}"
CONTAINER_MOUNT="/data"
CONTAINER="${CONTAINER}"
MODEL_NAME_OR_PATH="${MODEL_NAME_OR_PATH}"
HYDRA_FULL_ERROR=1 python3 "${SAGEMAKER_TRAINING_LAUNCHER_DIR}/main.py" \
recipes=fine-tuning/gpt_oss/checkpointless_gpt_oss_120b_lora \
recipes.dataset.dataset_path="${TRAIN_DIR}" \
recipes.exp_manager.exp_dir="${EXP_DIR}" \
recipes.log_dir="${LOG_DIR}" \
recipes.resume.restore_config.path="${MODEL_NAME_OR_PATH}" \
base_results_dir="${SAGEMAKER_TRAINING_LAUNCHER_DIR}/results" \
git.use_default=false \
cluster=k8s \
cluster_type=k8s \
container="${CONTAINER}" \
+cluster.hostNetwork=true \
+cluster.persistent_volume_claims.0.claimName=fsx-claim \
+cluster.persistent_volume_claims.0.mountPath="${CONTAINER_MOUNT}" \
+recipes.dataset.val_dataset_path="${VAL_DIR}" \
++recipes.callbacks.3.test_fault_config.fault_prob_between_lock=1 \
```
1. Avvio del job di addestramento
```
bash launcher_scripts/gpt_oss/run_checkpointless_gpt_oss_120b_lora.sh
```
Dopo aver inviato il job di addestramento, puoi utilizzare il comando seguente per verificare se l’invio è riuscito.
```
kubectl get pods
NAME READY STATUS RESTARTS AGE
gpt-oss-120b-worker-0 0/1 running 0 36s
```
Se lo STATUS è in sospeso o ContainerCreating, esegui il comando seguente per ottenere maggiori dettagli
```
kubectl describe pod
```
Quando lo STATUS del processo diventa Running, puoi esaminare il log utilizzando il comando seguente.
```
kubectl logs
```
Lo STATUS diventerà Completato quando esegui kubectl get pods
## Avvia il processo di formazione con kubectl con yaml predefinito
Un'altra opzione è avviare la formazione tramite kubectl con un job predefinito yaml.
1. aggiorna examples/gpt\$1oss/launch/peft \$1gpt\$1oss\$1120b\$1checkpointless\$1p5.yaml
+ immagine: Un contenitore di Deep Learning. Per trovare la versione più recente del contenitore di formazione checkpointless, consulta le note sulla versione di [checkpointless](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-eks-checkpointless-release-notes.html) training.
+ [resume.restore\$1config.path=: il percorso per scaricare i pesi dei modelli preaddestrati in formato Nemo nella fase Prerequisiti.](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-eks-checkpointless-recipes-peft.html#sagemaker-eks-checkpointless-recipes-peft-prereqs)
+ dataset.dataset\$1path=: il percorso del set di dati archiviato nella memoria condivisa
1. Invia il lavoro usando kubectl con peft\$1gpt\$1oss\$1120b\$1checkpointless\$1p5.yaml
```
kubectl apply -f examples/gpt_oss/launch/peft_gpt_oss_120b_checkpointless_p5.yaml
```
Dopo aver inviato il job di addestramento, puoi utilizzare il comando seguente per verificare se l’invio è riuscito.
```
kubectl get pods
NAME READY STATUS RESTARTS AGE
gpt-120b-lora-checkpointless-worker-0 0/1 running 0 36s
```
Se lo STATUS è in sospeso o, esegui il seguente comando per ottenere maggiori dettagli ContainerCreating
```
kubectl describe pod
```
Quando lo STATUS del processo diventa Running, puoi esaminare il log utilizzando il comando seguente.
```
kubectl logs
```
Lo STATUS diventerà Completato quando esegui kubectl get pods
# Tutorial - Amazon SageMaker HyperPod Checkpointless Pretraining Llama 3 70b
La seguente sequenza di passaggi è necessaria per eseguire ricette di allenamento senza checkpoint. HyperPod
## Prerequisiti
Prima di iniziare a configurare l’ambiente, assicurati di avere:
+ [Supporto Amazon EKS abilitato in Amazon SageMaker HyperPod](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-eks-prerequisites.html)
+ [Configura l'operatore HyperPod di formazione (v1.2\$1)](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-eks-operator.html)
+ Una posizione di archiviazione condivisa. Può essere un FSx file system Amazon o un sistema NFS accessibile dai nodi del cluster.
+ I dati in uno dei seguenti formati:
+ JSON
+ JSONGZ (JSON compresso)
+ ARROW
+ [Scegli una ricetta di formazione supportata senza checkpoint per Llama 70B o GPT-OSS 120B dalla fonte.](https://github.com/aws/sagemaker-hyperpod-recipes/tree/main/recipes_collection)
+ [Scaricate i pesi del modello Hugging](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-eks-checkpointless-release-notes.html) [Face e convertiteli nel formato supportato da Nemo.](https://docs.nvidia.com/nemo-framework/user-guide/latest/nemo-2.0/features/hf-integration.html#importing-from-hugging-face)
+ Configurare l’ambiente
## Configurazione dell'ambiente Kubernetes
Per configurare l'ambiente Kubernetes, procedi come segue:
1. Configura l’ambiente virtuale. Assicurati di usare Python maggiore o uguale a 3.10 e inferiore a 3.14.
```
python3 -m venv ${PWD}/venv
source venv/bin/activate
```
1. [Configura kubectl ed eksctl](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html)
1. [Installa Helm](https://helm.sh/docs/intro/install/)
1. Connettiti al cluster Kubernetes.
```
aws eks update-kubeconfig --region "${CLUSTER_REGION}" --name "${CLUSTER_NAME}"
```
1. Installa le dipendenze utilizzando uno dei metodi seguenti:
1. Metodo 1: metodo SageMaker HyperPod delle ricette:
```
# install SageMaker HyperPod Recipes.
git clone --recursive git@github.com:aws/sagemaker-hyperpod-recipes.git
cd sagemaker-hyperpod-recipes
pip3 install -r requirements.txt
```
1. Metodo 2: kubectl con metodo job yaml predefinito
```
# install SageMaker HyperPod checkpointless training.
git clone git@github.com:aws/sagemaker-hyperpod-checkpointless-training.git
cd sagemaker-hyperpod-checkpointless-training
```
Ora puoi lanciare la ricetta di allenamento senza checkpointless usando il programma di avvio -style o usando kubectl. NeMo
## Metodo 1: avvia il processo di formazione con il programma di avvio delle ricette
In alternativa, puoi utilizzare le SageMaker HyperPod ricette per inviare il tuo lavoro di formazione. L'uso delle ricette comporta l'aggiornamento di k8s.yaml, config.yaml e l'esecuzione dello script di avvio.
1. Aggiornamento di `launcher_scripts/llama/run_checkpointless_llama3_70b_pretrain.sh`
Un contenitore di Deep Learning. Per trovare la versione più recente del contenitore di formazione checkpointless, consulta le note sulla versione di [checkpointless](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-eks-checkpointless-release-notes.html) training.
```
#!/bin/bash
SAGEMAKER_TRAINING_LAUNCHER_DIR=${SAGEMAKER_TRAINING_LAUNCHER_DIR:-"$(pwd)"}
TRAIN_DIR="${TRAIN_DIR}"
VAL_DIR="${VAL_DIR}"
EXP_DIR="${EXP_DIR}"
LOG_DIR="${LOG_DIR}"
CONTAINER_MOUNT="/data"
CONTAINER="${CONTAINER}"
HYDRA_FULL_ERROR=1 python3 "${SAGEMAKER_TRAINING_LAUNCHER_DIR}/main.py" \
recipes=training/llama/checkpointless_llama3_70b_pretrain \
recipes.dataset.dataset_path="${TRAIN_DIR}" \
recipes.exp_manager.exp_dir="${EXP_DIR}" \
recipes.log_dir="${LOG_DIR}" \
recipes.data.global_batch_size=16 \
recipes.data.micro_batch_size=4 \
base_results_dir="${SAGEMAKER_TRAINING_LAUNCHER_DIR}/results" \
git.use_default=false \
cluster=k8s \
cluster_type=k8s \
container="${CONTAINER}" \
+cluster.hostNetwork=true \
+cluster.persistent_volume_claims.0.claimName=fsx-claim \
+cluster.persistent_volume_claims.0.mountPath="${CONTAINER_MOUNT}" \
+recipes.dataset.val_dataset_path="${VAL_DIR}" \
++recipes.callbacks.3.test_fault_config.fault_prob_between_lock=1 \
```
1. Avvio del job di addestramento
```
bash launcher_scripts/llama/run_checkpointless_llama3_70b_pretrain.sh
```
1. Dopo aver inviato il job di addestramento, puoi utilizzare il comando seguente per verificare se l’invio è riuscito.
```
kubectl get pods
NAME READY STATUS RESTARTS AGE
llama-3-70b-worker-0 0/1 running 0 36s
```
1. Se lo STATUS è in sospeso o ContainerCreating, esegui il comando seguente per ottenere maggiori dettagli
```
kubectl describe pod
```
1. Quando lo STATUS del processo diventa Running, puoi esaminare il log utilizzando il comando seguente.
```
kubectl logs
```
Lo STATUS diventerà Completato quando esegui kubectl get pods
## Metodo 2: Avvia il processo di formazione con kubectl con yaml predefinito
Un'altra opzione è avviare la formazione tramite kubectl con un job predefinito yaml.
1. Aggiornamento di `examples/llama3/launch/pretrain_llama3_70b_checkpointless_p5.yaml`
+ `image`: un container per il Deep Learning. [Per trovare la versione più recente del contenitore di formazione checkpointless, consulta le note sulla versione di checkpointless training.](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-eks-checkpointless-release-notes.html)
+ `resume.restore_config.path=`[: Il percorso per scaricare i pesi dei modelli preaddestrati in formato Nemo nella fase Prerequisiti.](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-eks-checkpointless-recipes-finetune.html#sagemaker-eks-checkpointless-recipes-finetune-prereqs)
+ `dataset.dataset_path=`: Il percorso del set di dati archiviato nella memoria condivisa
1. Invia il lavoro usando kubectl con `pretrain_llama3_70b_checkpointless_p5.yaml`
```
kubectl apply -f examples/llama3/launch/pretrain_llama3_70b_checkpointless_p5.yaml
```
1. Dopo aver inviato il job di addestramento, puoi utilizzare il comando seguente per verificare se l’invio è riuscito.
```
kubectl get pods
NAME READY STATUS RESTARTS AGE
llama3-pretrain-checkpointless-worker-0 0/1 running 0 36s
```
1. Se lo STATUS è in sospeso o ContainerCreating, esegui il seguente comando per ottenere maggiori dettagli
```
kubectl describe pod
```
1. Quando lo STATUS del processo diventa Running, puoi esaminare il log utilizzando il comando seguente.
```
kubectl logs
```
Lo STATUS diventerà Completato quando esegui kubectl get pods
# Tutorial - Amazon SageMaker HyperPod Checkpointless Left-Lora Llama 3 70b
La seguente sequenza di passaggi è necessaria per eseguire ricette di formazione senza checkpoint. HyperPod
## Prerequisiti
Prima di iniziare a configurare l’ambiente, assicurati di avere:
+ [Supporto Amazon EKS abilitato in Amazon SageMaker HyperPod](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-eks-prerequisites.html)
+ [Configura l'operatore HyperPod di formazione (v1.2\$1)](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-eks-operator.html)
+ Una posizione di archiviazione condivisa. Può essere un FSx file system Amazon o un sistema NFS accessibile dai nodi del cluster.
+ I dati in uno dei seguenti formati:
+ JSON
+ JSONGZ (JSON compresso)
+ ARROW
+ [Scegli una ricetta di formazione supportata senza checkpoint per Llama 70B o GPT-OSS 120B dalla fonte.](https://github.com/aws/sagemaker-hyperpod-recipes/tree/main/recipes_collection)
+ [Scaricate i pesi del modello Hugging](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-eks-checkpointless-release-notes.html) [Face e convertiteli nel formato supportato da Nemo.](https://docs.nvidia.com/nemo-framework/user-guide/latest/nemo-2.0/features/hf-integration.html#importing-from-hugging-face)
+ Configurare l’ambiente
## Configurazione dell'ambiente Kubernetes
Per configurare l'ambiente Kubernetes, procedi come segue:
1. Configura l’ambiente virtuale. Assicurati di usare Python maggiore o uguale a 3.10 e inferiore a 3.14.
```
python3 -m venv ${PWD}/venv
source venv/bin/activate
```
1. [Configura kubectl ed eksctl](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html)
1. [Installa Helm](https://helm.sh/docs/intro/install/)
1. Connettiti al cluster Kubernetes.
```
aws eks update-kubeconfig --region "${CLUSTER_REGION}" --name "${CLUSTER_NAME}"
```
1. Installa le dipendenze utilizzando uno dei metodi seguenti:
1. Metodo 1: metodo SageMaker HyperPod delle ricette:
```
# install SageMaker HyperPod Recipes.
git clone --recursive git@github.com:aws/sagemaker-hyperpod-recipes.git
cd sagemaker-hyperpod-recipes
pip3 install -r requirements.txt
```
1. Metodo 2: kubectl con metodo job yaml predefinito
```
# install SageMaker HyperPod checkpointless training.
git clone git@github.com:aws/sagemaker-hyperpod-checkpointless-training.git
cd sagemaker-hyperpod-checkpointless-training
```
Ora puoi lanciare la ricetta di allenamento senza checkpointless usando il programma di avvio -style o usando kubectl. NeMo
## Metodo 1: avvia il processo di formazione con il programma di avvio delle ricette
In alternativa, puoi utilizzare le SageMaker HyperPod ricette per inviare il tuo lavoro di formazione. L'uso delle ricette comporta l'aggiornamento di k8s.yaml, config.yaml e l'esecuzione dello script di avvio.
1. Aggiornamento di `launcher_scripts/llama/run_checkpointless_llama3_70b_lora.sh`
Un contenitore di Deep Learning. Per trovare la versione più recente del contenitore di formazione checkpointless, consulta le note sulla versione di [checkpointless](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-eks-checkpointless-release-notes.html) training.
```
#!/bin/bash
SAGEMAKER_TRAINING_LAUNCHER_DIR=${SAGEMAKER_TRAINING_LAUNCHER_DIR:-"$(pwd)"}
TRAIN_DIR="${TRAIN_DIR}"
VAL_DIR="${VAL_DIR}"
EXP_DIR="${EXP_DIR}"
LOG_DIR="${LOG_DIR}"
CONTAINER_MOUNT="/data"
CONTAINER="${CONTAINER}"
MODEL_NAME_OR_PATH="${MODEL_NAME_OR_PATH}"
HYDRA_FULL_ERROR=1 python3 "${SAGEMAKER_TRAINING_LAUNCHER_DIR}/main.py" \
recipes=fine-tuning/llama/checkpointless_llama3_70b_lora \
recipes.dataset.dataset_path="${TRAIN_DIR}" \
recipes.exp_manager.exp_dir="${EXP_DIR}" \
recipes.log_dir="${LOG_DIR}" \
recipes.resume.restore_config.path="${MODEL_NAME_OR_PATH}" \
base_results_dir="${SAGEMAKER_TRAINING_LAUNCHER_DIR}/results" \
git.use_default=false \
cluster=k8s \
cluster_type=k8s \
container="${CONTAINER}" \
+cluster.hostNetwork=true \
+cluster.persistent_volume_claims.0.claimName=fsx-claim \
+cluster.persistent_volume_claims.0.mountPath="${CONTAINER_MOUNT}" \
+recipes.dataset.val_dataset_path="${VAL_DIR}" \
++recipes.callbacks.3.test_fault_config.fault_prob_between_lock=1 \
```
1. Avvio del job di addestramento
```
bash launcher_scripts/llama/run_checkpointless_llama3_70b_lora.sh
```
1. Dopo aver inviato il job di addestramento, puoi utilizzare il comando seguente per verificare se l’invio è riuscito.
```
kubectl get pods
NAME READY STATUS RESTARTS AGE
llama-3-70b-worker-0 0/1 running 0 36s
```
1. Se lo STATUS è in sospeso o ContainerCreating, esegui il comando seguente per ottenere maggiori dettagli
```
kubectl describe pod
```
1. Quando lo STATUS del processo diventa Running, puoi esaminare il log utilizzando il comando seguente.
```
kubectl logs
```
Lo STATUS diventerà Completato quando esegui kubectl get pods
## Metodo 2: Avvia il processo di formazione con kubectl con yaml predefinito
Un'altra opzione è avviare la formazione tramite kubectl con un job predefinito yaml.
1. Aggiornamento di `examples/llama3/launch/peft_llama3_70b_checkpointless_p5.yaml`
+ `image`: un container per il Deep Learning. [Per trovare la versione più recente del contenitore di formazione checkpointless, consulta le note sulla versione di checkpointless training.](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-eks-checkpointless-release-notes.html)
+ `resume.restore_config.path=`[: Il percorso per scaricare i pesi dei modelli preaddestrati in formato Nemo nella fase Prerequisiti.](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-eks-checkpointless-recipes-finetune.html#sagemaker-eks-checkpointless-recipes-finetune-prereqs)
+ `dataset.dataset_path=`: Il percorso del set di dati archiviato nella memoria condivisa
1. Invia il lavoro usando kubectl con `peft_llama3_70b_checkpointless_p5.yaml`
```
kubectl apply -f examples/llama3/launch/peft_llama3_70b_checkpointless_p5.yaml
```
1. Dopo aver inviato il job di addestramento, puoi utilizzare il comando seguente per verificare se l’invio è riuscito.
```
kubectl get pods
NAME READY STATUS RESTARTS AGE
llama3-70b-lora-checkpointless-worker-0 0/1 running 0 36s
```
1. Se lo STATUS è in sospeso o ContainerCreating, esegui il seguente comando per ottenere maggiori dettagli
```
kubectl describe pod
```
1. Quando lo STATUS del processo diventa Running, puoi esaminare il log utilizzando il comando seguente.
```
kubectl logs
```
Lo STATUS diventerà Completato quando esegui kubectl get pods
# Tutorial - Amazon SageMaker HyperPod Checkpointless, preaddestramento o messa a punto di modelli personalizzati
La seguente sequenza di passaggi è necessaria per eseguire un addestramento senza checkpoint con il modello personalizzato acceso. HyperPod
## Prerequisiti
Prima di iniziare a configurare l’ambiente, assicurati di avere:
+ [Supporto Amazon EKS abilitato in Amazon SageMaker HyperPod](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-eks-prerequisites.html)
+ [Configura l'operatore HyperPod di formazione (v1.2\$1)](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-eks-operator.html)
+ Una posizione di archiviazione condivisa. Può essere un FSx file system Amazon o un sistema NFS accessibile dai nodi del cluster.
+ I dati in uno dei seguenti formati:
+ JSON
+ JSONGZ (JSON compresso)
+ ARROW
+ [Scarica i pesi del modello Hugging Face](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-eks-checkpointless-release-notes.html) [e convertili nel formato supportato da Nemo.](https://docs.nvidia.com/nemo-framework/user-guide/latest/nemo-2.0/features/hf-integration.html#importing-from-hugging-face)
+ Configurare l’ambiente
## Configurazione dell'ambiente Kubernetes
Per configurare l'ambiente Kubernetes, procedi come segue:
1. Configura l’ambiente virtuale. Assicurati di usare Python maggiore o uguale a 3.10 e inferiore a 3.14.
```
python3 -m venv ${PWD}/venv
source venv/bin/activate
```
1. [Configura kubectl ed eksctl](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html)
1. Connettiti al cluster Kubernetes.
```
aws eks update-kubeconfig --region "${CLUSTER_REGION}" --name "${CLUSTER_NAME}"
```
1. Installare le dipendenze
```
# install SageMaker HyperPod checkpointless training.
git clone git@github.com:aws/sagemaker-hyperpod-checkpointless-training.git
cd sagemaker-hyperpod-checkpointless-training
```
## Istruzioni di modifica dell'allenamento Checkpointless
Per adottare in modo incrementale la formazione senza checkpoint per i modelli personalizzati, segui la guida all'integrazione (qui utilizziamo il pretraining di Llama 3 70b come esempio), che prevede:
+ Creazione rapida di comunicatori
+ Dataloader mappato in memoria (MMAP)
+ Ripristino in corso e senza checkpoint
### Componente 1: creazione rapida di comunicatori
Questo per ottimizzare i tempi necessari per stabilire connessioni tra i lavoratori. Non sono necessarie modifiche al codice e richiede solo l'impostazione delle variabili env
```
# Enable Rootless features
export HPCT_USE_ROOTLESS=1 && \
sysctl -w net.ipv4.ip_local_port_range="20000 65535" && \
hyperpodrun --nproc_per_node=8 \
...
--inprocess-restart \
...
```
La modifica completa può essere trovata nel file [llama3 70 pretrain](https://github.com/aws/sagemaker-hyperpod-checkpointless-training/blob/main/examples/llama3/launch/pretrain_llama3_70b_checkpointless_p5.yaml) launch job config.
### Componente 2: Dataloader mappato in memoria (MMAP)
Cache MMAP per archiviare campioni di dati precaricati e consentire l'avvio immediato della formazione senza dover attendere la preelaborazione dei dati. Richiede modifiche minime al codice da adottare inserendo il dataloader esistente.
```
data_module = MMAPDataModule(
data_module=base_data_module,
mmap_config=CacheResumeMMAPConfig(cache_dir=…)
)
```
### Componenti 3 e 4: ripristino in corso e senza checkpoint
Ciò consente il ripristino in caso di errore senza riavviare i processi di addestramento o il caricamento dai checkpoint. Sono necessarie ulteriori modifiche al codice (aggiornamento della configurazione di strategia e formazione, wrap existing main)
```
@HPWrapper(
health_check=CudaHealthCheck(),
hp_api_factory=HPAgentK8sAPIFactory(),
abort_timeout=60.0,
...)
def run_main(
cfg,
caller: Optional[HPCallWrapper] = None):
...
CheckpointlessMegatronStrategy(
**self.cfg.strategy,
ddp=self.ddp,
)
```
[La modifica completa è disponibile nello [script di immissione pretrain di llama3 70](https://github.com/aws/sagemaker-hyperpod-checkpointless-training/blob/main/examples/llama3/llama3_70b_pretrain_checkpointless.py) e la corrispondente modifica alla configurazione di allenamento è disponibile nella configurazione di addestramento di llama3 70b.](https://github.com/aws/sagemaker-hyperpod-checkpointless-training/blob/main/examples/llama3/config/llama3_70b_peft_checkpointless.yaml)
### Avvia la formazione
Ora puoi avviare l'allenamento senza checkpoint usando kubectl.
```
kubectl apply -f your_job_config.yaml
```
# HyperPod funzionalità di formazione senza checkpointless
Consulta le pagine seguenti per conoscere le funzionalità di formazione della formazione senza checkpointless.
**Topics**
+ [Archivi di formazione SageMaker HyperPod senza checkpoint di Amazon](#sagemaker-eks-checkpointless-repositories)
+ [Miglioramenti all'inizializzazione della comunicazione collettiva](sagemaker-eks-checkpointless-features-communication.md)
+ [Dataloader mappato in memoria](sagemaker-eks-checkpointless-features-mmap.md)
+ [Recupero durante il processo e formazione senza checkpoint](sagemaker-eks-checkpointless-in-process-recovery.md)
## Archivi di formazione SageMaker HyperPod senza checkpoint di Amazon
[ HyperPod checkpointless training](https://github.com/aws/sagemaker-hyperpod-checkpointless-training#) accelera il ripristino dai guasti dei cluster in ambienti di formazione distribuiti su larga scala attraverso ottimizzazioni a livello di framework. Queste ottimizzazioni vengono fornite tramite un'immagine del contenitore di base che include miglioramenti avanzati dell'inizializzazione NCCL, ottimizzazioni del caricamento dei dati e componenti di ripristino in corso e senza checkpoint. Il pacchetto di formazione HyperPod checkpointless si basa su queste basi.
La formazione Checkpointless è abilitata tramite tre percorsi di ottimizzazione eseguiti in sinergia:
+ **Miglioramenti all'inizializzazione della comunicazione (NCCL e Gloo)**: elimina gli ostacoli alla comunicazione decentralizzando le informazioni di rango tra pari e ring (riquadro rosso in basso).
+ **Ottimizzazioni del caricamento dei dati**: riduci il tempo necessario per fornire il primo batch di dati durante le operazioni di riavvio (riquadri arancioni sotto).
+ **Riduzione del sovraccarico di riavvio del programma**: riduci al minimo i costi di riavvio e abilita il rifornimento senza checkpoint attraverso il ripristino del processo su nodi integri (riquadri blu e verdi di seguito).
![\[alt text not found\]](http://docs.aws.amazon.com/it_it/sagemaker/latest/dg/images/hyperpod/hyperpod-checkpointless-optimization-tracks.png)
# Miglioramenti all'inizializzazione della comunicazione collettiva
NCCL e Gloo sono librerie di comunicazione fondamentali che consentono operazioni collettive (come all-reduce e broadcast) attraverso processi di formazione distribuiti. Tuttavia, l'inizializzazione tradizionale di NCCL e Gloo può creare colli di bottiglia durante il ripristino dei guasti.
Il processo di ripristino standard richiede che tutti i processi si connettano a un sistema centralizzato TCPStore e si coordinino tramite un processo root, il che comporta un oneroso sovraccarico che diventa particolarmente problematico durante i riavvii. Questo design centralizzato crea tre problemi critici: sovraccarico di coordinamento dovuto alle TCPStore connessioni obbligatorie, ritardi di ripristino poiché ogni riavvio deve ripetere l'intera sequenza di inizializzazione e un singolo punto di errore nel processo principale stesso. Ciò impone procedure di coordinamento costose e centralizzate ogni volta che la formazione viene inizializzata o riavviata.
HyperPod la formazione senza checkpointless elimina questi ostacoli di coordinamento, permettendo un recupero più rapido dai guasti grazie a un'inizializzazione «senza radici» e «...» TCPStoreless
## configurazioni rootless
Per abilitare Rootless, è sufficiente esporre le seguenti variabili di ambiente.
```
export HPCT_USE_ROOTLESS=1 && \
sysctl -w net.ipv4.ip_local_port_range="20000 65535" && \
```
HPCT\$1USE\$1ROOTLESS: 0 o 1. Si usa per accendere e spegnere rootless
sysctl -w net.ipv4.ip\$1local\$1port\$1range="20000 65535": imposta l'intervallo delle porte di sistema
[Vedi l'esempio per abilitare Rootless](https://github.com/aws/sagemaker-hyperpod-checkpointless-training/blob/main/examples/llama3/launch/pretrain_llama3_70b_checkpointless_p5.yaml#L111-L113).
## Rootless
HyperPod checkpointless training offre nuovi metodi di inizializzazione, Rootless e, per i gruppi di processi NCCL e TCPStoreless Gloo.
L'implementazione di queste ottimizzazioni comporta la modifica di NCCL, Gloo e: PyTorch
+ Estensione della libreria di terze parti APIs per abilitare le ottimizzazioni Rootless e Storeless NCCL e Gloo mantenendo al contempo la compatibilità con le versioni precedenti
+ Aggiornamento dei backend dei gruppi di processi per utilizzare in modo condizionale percorsi ottimizzati e gestire i problemi di ripristino durante il processo
+ Evitando costose TCPStore creazioni a livello PyTorch distribuito mantenendo al contempo modelli di indirizzi simmetrici attraverso contatori di gruppo globali
Il grafico seguente mostra l'architettura delle librerie di formazione distribuite e le modifiche apportate alla formazione senza checkpoint.
![\[Il grafico seguente mostra l'architettura delle librerie di formazione distribuite e le modifiche apportate alla formazione senza checkpointless.\]](http://docs.aws.amazon.com/it_it/sagemaker/latest/dg/images/hyperpod/hyperpod-checkpointless-training-libraries.png)
### NCCL e Gloo
Si tratta di pacchetti indipendenti che eseguono le funzionalità principali delle comunicazioni collettive. Forniscono chiavi APIs, come ncclCommInit Rank, per inizializzare le reti di comunicazione, gestire le risorse sottostanti ed eseguire comunicazioni collettive. Dopo aver apportato modifiche personalizzate a NCCL e Gloo, Rootless e Storeless ottimizzano (ad esempio, saltando la connessione a) l'inizializzazione della rete di comunicazione. TCPStore È possibile passare dall'utilizzo dei percorsi di codice originali ai percorsi di codice ottimizzati in modo flessibile.
### PyTorch backend del gruppo di processi
I backend del gruppo di processi, in particolare ProcessGroup NCCL e ProcessGroupGloo, lo implementano ProcessGroup APIs richiamando le APIs librerie sottostanti corrispondenti. Poiché estendiamo le librerie di terze parti APIs, dobbiamo richiamarle correttamente e modificare il percorso del codice in base alle configurazioni dei clienti.
Oltre all'ottimizzazione dei percorsi di codice, modifichiamo anche il backend del gruppo di processi per supportare il ripristino durante il processo.
# Dataloader mappato in memoria
Un altro sovraccarico di riavvio deriva dal caricamento dei dati: il cluster di addestramento rimane inattivo mentre il dataloader si inizializza, scarica i dati dai file system remoti e li elabora in batch.
Per risolvere questo problema, introduciamo il Memory Mapped DataLoader (MMAP) Dataloader, che memorizza nella cache i batch preimpostati nella memoria persistente, assicurando che rimangano disponibili anche dopo un riavvio indotto da un errore. Questo approccio elimina i tempi di configurazione del dataloader e consente di riprendere immediatamente l'addestramento utilizzando batch memorizzati nella cache, mentre il dataloader reinizializza e recupera contemporaneamente i dati successivi in background. La cache dei dati si trova su ogni livello che richiede dati di addestramento e mantiene due tipi di batch: i batch consumati di recente e utilizzati per l'addestramento e i batch precaricati pronti per l'uso immediato.
![\[Questa immagine illustra il Dataloader MMAP, le cache e i batch utilizzati.\]](http://docs.aws.amazon.com/it_it/sagemaker/latest/dg/images/hyperpod/hyperpod-checkpointless-mmap-dataloader.png)
Il dataloader MMAP offre due funzionalità seguenti:
+ **Prefetching dei dati**: recupera e memorizza in modo proattivo i dati generati dal dataloader
+ **Memorizzazione nella cache persistente**: archivia i batch consumati e quelli precaricati in un file system temporaneo che sopravvive al riavvio del processo
Utilizzando la cache, il processo di formazione trarrà vantaggio da:
+ **Impronta di memoria ridotta**: sfrutta la mappatura della memoria I/O per mantenere una singola copia condivisa dei dati nella memoria della CPU host, eliminando le copie ridondanti tra i processi GPU (ad esempio, riduce da 8 copie a 1 su un'istanza p5 con 8) GPUs
+ **Ripristino più rapido**: riduce il tempo medio di riavvio (MTTR) grazie alla possibilità di riprendere immediatamente la formazione dai batch memorizzati nella cache, eliminando così l'attesa per la reinizializzazione del dataloader e la prima generazione del batch
## Configurazioni MMAP
Per utilizzare MMAP, è sufficiente inserire il modulo dati originale in `MMAPDataModule`
```
data_module=MMAPDataModule(
data_module=MY_DATA_MODULE(...),
mmap_config=CacheResumeMMAPConfig(
cache_dir=self.cfg.mmap.cache_dir,
checkpoint_frequency=self.cfg.mmap.checkpoint_frequency),
)
```
`CacheResumeMMAPConfig`: I parametri di MMAP Dataloader controllano la posizione della directory della cache, i limiti di dimensione e la delega per il recupero dei dati. Per impostazione predefinita, solo il livello TP 0 per nodo recupera i dati dall'origine, mentre gli altri ranghi dello stesso gruppo di replica li leggono dalla cache condivisa, eliminando i trasferimenti ridondanti.
`MMAPDataModule`: racchiude il modulo di dati originale e restituisce il dataloader mmap sia per l'addestramento che per la convalida.
[Vedi l'esempio per abilitare MMAP.](https://github.com/aws/sagemaker-hyperpod-checkpointless-training/blob/main/examples/gpt_oss/gpt_oss_120b_full_finetune_checkpointless.py#L101-L109)
## Guida di riferimento alle API
### CacheResumeMMAPConfig
```
class hyperpod_checkpointless_training.dataloader.config.CacheResumeMMAPConfig(
cache_dir='/dev/shm/pdl_cache',
prefetch_length=10,
val_prefetch_length=10,
lookback_length=2,
checkpoint_frequency=None,
model_parallel_group=None,
enable_batch_encryption=False)
```
Classe di configurazione per la funzionalità del dataloader cache-resume memory-mapped (MMAP) durante la formazione senza checkpoint. HyperPod
Questa configurazione consente un caricamento efficiente dei dati con funzionalità di caching e prefetching, permettendo di riprendere rapidamente l'addestramento dopo i guasti mantenendo i batch di dati memorizzati nella cache in file mappati in memoria.
**Parametri**
+ **cache\$1dir** (str, opzionale) — Percorso della directory per l'archiviazione dei batch di dati memorizzati nella cache. Predefinito: «/\$1cache» dev/shm/pdl
+ **prefetch\$1length** (int, opzionale) — Numero di batch da prerecuperare durante l'allenamento. Impostazione predefinita: 10
+ **val\$1prefetch\$1length** (int, opzionale) — Numero di batch da prerecuperare in anticipo durante la convalida. Impostazione predefinita: 10
+ **lookback\$1length** (int, opzionale) — Numero di batch utilizzati in precedenza da conservare nella cache per un potenziale riutilizzo. Impostazione predefinita: 2
+ **checkpoint\$1frequency (int, opzionale) — Frequenza delle** fasi di checkpoint del modello. Utilizzato per l'ottimizzazione delle prestazioni della cache. Impostazione predefinita: nessuna
+ **model\$1parallel\$1group (oggetto, opzionale) — Gruppo** di processi per il parallelismo dei modelli. Se Nessuno, verrà creato automaticamente. Impostazione predefinita: nessuna
+ **enable\$1batch\$1encryption** (bool, opzionale) — Indica se abilitare la crittografia per i dati batch memorizzati nella cache. Impostazione predefinita: False
**Metodi**
```
create(dataloader_init_callable,
parallel_state_util,
step,
is_data_loading_rank,
create_model_parallel_group_callable,
name='Train',
is_val=False,
cached_len=0)
```
Crea e restituisce un'istanza di dataloader MMAP configurata.
**Parametri**
+ **dataloader\$1init\$1callable (Callable**) — Funzione per inizializzare il dataloader sottostante
+ **parallel\$1state\$1util (object) — Utilità** per la gestione dello stato parallelo tra i processi
+ **step** (int) — La fase relativa ai dati da cui riprendere durante l'allenamento
+ **is\$1data\$1loading\$1rank (Callable) — Funzione che restituisce True se il rank** corrente deve caricare i dati
+ **create\$1model\$1parallel\$1group\$1callable (Callable**) — Funzione per creare un gruppo di processi parallelo modello
+ name (str, opzionale) — **Identificatore del nome** per il dataloader. Predefinito: «Train»
+ **is\$1val** (bool, opzionale) — Se si tratta di un dataloader di convalida. Impostazione predefinita: False
+ **cached\$1len** (int, opzionale) — Lunghezza dei dati memorizzati nella cache se si riprende dalla cache esistente. Impostazione predefinita: 0
Restituisce `CacheResumePrefetchedDataLoader` o: istanza del dataloader MMAP configurata `CacheResumeReadDataLoader`
Aumenta `ValueError` se il parametro step è. `None`
**Esempio**
```
from hyperpod_checkpointless_training.dataloader.config import CacheResumeMMAPConfig
# Create configuration
config = CacheResumeMMAPConfig(
cache_dir="/tmp/training_cache",
prefetch_length=20,
checkpoint_frequency=100,
enable_batch_encryption=False
)
# Create dataloader
dataloader = config.create(
dataloader_init_callable=my_dataloader_init,
parallel_state_util=parallel_util,
step=current_step,
is_data_loading_rank=lambda: rank == 0,
create_model_parallel_group_callable=create_mp_group,
name="TrainingData"
)
```
**Note**
+ La directory della cache dovrebbe avere spazio sufficiente e I/O prestazioni veloci (ad esempio, /dev/shm per l'archiviazione in memoria).
+ L'impostazione `checkpoint_frequency` migliora le prestazioni della cache allineando la gestione della cache con il checkpointing del modello
+ Per i dataloaders di convalida (`is_val=True`), il passaggio viene reimpostato su 0 e l'avvio a freddo viene forzato
+ Vengono utilizzate diverse implementazioni del dataloader a seconda che il rango corrente sia responsabile del caricamento dei dati
### MMAPDataModulo
```
class hyperpod_checkpointless_training.dataloader.mmap_data_module.MMAPDataModule(
data_module,
mmap_config,
parallel_state_util=MegatronParallelStateUtil(),
is_data_loading_rank=None)
```
Un DataModule wrapper PyTorch Lightning che applica funzionalità di caricamento dei dati mappate in memoria (MMAP) a quelle esistenti per un addestramento senza checkpoint. DataModules
Questa classe integra un PyTorch Lightning esistente e lo migliora con la funzionalità MMAP, che consente una memorizzazione efficiente dei dati nella cache DataModule e un ripristino rapido in caso di errori di formazione. Mantiene la compatibilità con l'interfaccia originale DataModule aggiungendo funzionalità di formazione senza checkpoint.
Parameters
data\$1module (pl. LightningDataModule)
Il sottostante DataModule da avvolgere (ad esempio, LLMData Module)
mmap\$1config () MMAPConfig
L'oggetto di configurazione MMAP che definisce il comportamento e i parametri della memorizzazione nella cache
`parallel_state_util`(MegatronParallelStateUtil, opzionale)
Utilità per la gestione dello stato parallelo tra processi distribuiti. Impostazione predefinita: MegatronParallelStateUtil ()
`is_data_loading_rank`(Richiamabile, opzionale)
Funzione che restituisce True se il rango corrente deve caricare dati. Se Nessuno, il valore predefinito è parallel\$1state\$1util.is\$1tp\$10. Impostazione predefinita: nessuna
**Attributes**
`global_step` (int)
Fase di formazione globale attuale, utilizzata per riprendere dai checkpoint
`cached_train_dl_len` (int)
Lunghezza memorizzata nella cache del dataloader di addestramento
`cached_val_dl_len` (int)
Lunghezza memorizzata nella cache del dataloader di convalida
**Metodi**
```
setup(stage=None)
```
Imposta il modulo di dati sottostante per la fase di formazione specificata.
`stage`(str, opzionale)
Fase dell'allenamento («adattamento», «convalida», «test» o «previsione»). Impostazione predefinita: nessuna
```
train_dataloader()
```
Crea l'allenamento DataLoader con MMAP wrapping.
*Restituisce: DataLoader — Addestramento* basato su MMAP con funzionalità di caching e prefetching DataLoader
```
val_dataloader()
```
Crea la convalida con MMAP wrapping. DataLoader
*Restituisce:* DataLoader — Validazione avvolta in MMAP con funzionalità di memorizzazione nella cache DataLoader
```
test_dataloader()
```
Crea il test DataLoader se il modulo di dati sottostante lo supporta.
*Restituisce:* DataLoader o Nessuno: esegue il test DataLoader dal modulo di dati sottostante o Nessuno se non è supportato
```
predict_dataloader()
```
Crea la previsione DataLoader se il modulo di dati sottostante la supporta.
*Restituisce:* DataLoader o Nessuno: prevedi DataLoader dal modulo di dati sottostante o Nessuno se non è supportato
```
load_checkpoint(checkpoint)
```
Carica le informazioni sul checkpoint per riprendere l'allenamento da una fase specifica.
checkpoint (dict)
dizionario Checkpoint contenente la chiave 'global\$1step'
```
get_underlying_data_module()
```
Ottieni il modulo di dati racchiuso sottostante.
*Restituisce:* pl. LightningDataModule — Il modulo dati originale che è stato confezionato
```
state_dict()
```
Ottieni il dizionario di stato del MMAP DataModule per il checkpoint.
*Restituisce:* dict — Dizionario contenente le lunghezze del dataloader memorizzate nella cache
```
load_state_dict(state_dict)
```
Carica il dizionario di stato per ripristinare lo stato MMAP. DataModule
`state_dict`(dict)
Dizionario di stato da caricare
**Proprietà**
```
data_sampler
```
Esporre il campionatore di dati del modulo di dati sottostante al framework. NeMo
*Restituisce:* object or None: il campionatore di dati del modulo di dati sottostante
**Esempio**
```
from hyperpod_checkpointless_training.dataloader.mmap_data_module import MMAPDataModule
from hyperpod_checkpointless_training.dataloader.config import CacheResumeMMAPConfig
from my_project import MyLLMDataModule
# Create MMAP configuration
mmap_config = CacheResumeMMAPConfig(
cache_dir="/tmp/training_cache",
prefetch_length=20,
checkpoint_frequency=100
)
# Create original data module
original_data_module = MyLLMDataModule(
data_path="/path/to/data",
batch_size=32
)
# Wrap with MMAP capabilities
mmap_data_module = MMAPDataModule(
data_module=original_data_module,
mmap_config=mmap_config
)
# Use in PyTorch Lightning Trainer
trainer = pl.Trainer()
trainer.fit(model, data=mmap_data_module)
# Resume from checkpoint
checkpoint = {"global_step": 1000}
mmap_data_module.load_checkpoint(checkpoint)
```
**Note**
+ Il wrapper delega la maggior parte dell'accesso degli attributi al modulo di dati sottostante utilizzando \$1\$1getattr\$1\$1
+ Solo i ranghi di caricamento dei dati inizializzano e utilizzano effettivamente il modulo di dati sottostante; gli altri ranghi utilizzano dataloader falsi
+ Le lunghezze dei dataloader memorizzati nella cache vengono mantenute per ottimizzare le prestazioni durante la ripresa dell'allenamento
# Recupero durante il processo e formazione senza checkpoint
HyperPod la formazione senza checkpointless utilizza la ridondanza dei modelli per consentire un addestramento tollerante ai guasti. Il principio fondamentale è che gli stati del modello e dell'ottimizzatore vengono completamente replicati su più gruppi di nodi, con aggiornamenti di peso e modifiche dello stato dell'ottimizzatore replicati in modo sincrono all'interno di ciascun gruppo. Quando si verifica un errore, le repliche integre completano le fasi di ottimizzazione e trasmettono gli stati aggiornati alle repliche in fase di ripristino. model/optimizer
Questo approccio basato sulla ridondanza del modello consente diversi meccanismi di gestione dei guasti:
+ **Ripristino durante il processo:** i processi rimangono attivi nonostante i guasti, mantenendo tutti gli stati del modello e dell'ottimizzatore nella memoria della GPU con i valori più recenti
+ **Gestione agevole delle interruzioni: aborti** controllati e pulizia delle risorse per le operazioni interessate
+ Riesecuzione **del blocco di codice: riesecuzione** solo dei segmenti di codice interessati all'interno di un blocco di codice rieseguibile (RCB)
+ **Recupero senza punti di controllo senza perdita dei progressi di allenamento:** poiché i processi persistono e gli stati rimangono in memoria, nessun progresso dell'allenamento viene perso; quando si verifica un errore, l'allenamento riprende dalla fase precedente, anziché riprendere dall'ultimo checkpoint salvato
**Configurazioni senza checkpoint**
Ecco il frammento principale della formazione senza checkpointless.
```
from hyperpod_checkpointless_training.inprocess.train_utils import wait_rank
wait_rank()
def main():
@HPWrapper(
health_check=CudaHealthCheck(),
hp_api_factory=HPAgentK8sAPIFactory(),
abort_timeout=60.0,
checkpoint_manager=PEFTCheckpointManager(enable_offload=True),
abort=CheckpointlessAbortManager.get_default_checkpointless_abort(),
finalize=CheckpointlessFinalizeCleanup(),
)
def run_main(cfg, caller: Optional[HPCallWrapper] = None):
...
trainer = Trainer(
strategy=CheckpointlessMegatronStrategy(...,
num_distributed_optimizer_instances=2),
callbacks=[..., CheckpointlessCallback(...)],
)
trainer.fresume = resume
trainer._checkpoint_connector = CheckpointlessCompatibleConnector(trainer)
trainer.wrapper = caller
```
+ `wait_rank`: Tutti i ranghi aspetteranno le informazioni sulla classifica dall'infrastruttura. HyperpodTrainingOperator
+ `HPWrapper`: wrapper di funzioni Python che abilita le funzionalità di riavvio per un blocco di codice rieseguibile (RCB). L'implementazione utilizza un gestore di contesto anziché un decoratore Python perché i decoratori non possono determinare il numero di elementi da RCBs monitorare in fase di esecuzione.
+ `CudaHealthCheck`: Assicura che il contesto CUDA per il processo corrente sia integro mediante la sincronizzazione con la GPU. Utilizza il dispositivo specificato dalla variabile di ambiente LOCAL\$1RANK o utilizza come impostazione predefinita il dispositivo CUDA del thread principale se LOCAL\$1RANK non è impostato.
+ `HPAgentK8sAPIFactory`: Questa API consente la formazione senza checkpoint per interrogare lo stato di addestramento di altri pod nel cluster di formazione Kubernetes. Fornisce inoltre una barriera a livello di infrastruttura che garantisce che tutti i ranghi completino con successo le operazioni di interruzione e riavvio prima di procedere.
+ `CheckpointManager`: Gestisce i checkpoint in memoria e il ripristino per una tolleranza agli errori senza checkpoint. peer-to-peer Ha le seguenti responsabilità principali:
+ **Gestione dei checkpoint in memoria**: salva e gestisce i checkpoint NeMo del modello in memoria per un ripristino rapido senza disco I/O durante gli scenari di ripristino senza checkpoint.
+ Convalida **della fattibilità del ripristino: determina se è possibile il ripristino senza checkpoint convalidando** la coerenza globale dei passaggi, lo stato del rango e l'integrità dello stato del modello.
+ **Peer-to-Peer Orchestrazione del ripristino: coordina il trasferimento dei** checkpoint tra i ranghi sani e quelli danneggiati utilizzando la comunicazione distribuita per un ripristino rapido.
+ **Gestione dello stato RNG**: conserva e ripristina gli stati dei generatori di numeri casuali su Python e Megatron per il NumPy ripristino PyTorch deterministico.
+ **[Opzionale] Checkpoint Offload: trasferisci il checkpoint** di memoria sulla CPU se la GPU non ha una capacità di memoria sufficiente.
+ `PEFTCheckpointManager`: Si estende mantenendo i pesi del modello base `CheckpointManager` per la regolazione fine del PEFT.
+ `CheckpointlessAbortManager`: Gestisce le operazioni di interruzione in un thread in background quando si verifica un errore. Per impostazione predefinita, interrompe TransformerEngine, Checkpointing e. TorchDistributed DataLoader Gli utenti possono registrare gestori di aborti personalizzati in base alle esigenze. Una volta completata l'interruzione, tutte le comunicazioni devono cessare e tutti i processi e i thread devono terminare per evitare perdite di risorse.
+ `CheckpointlessFinalizeCleanup`: gestisce le operazioni di pulizia finale nel thread principale per i componenti che non possono essere interrotti o ripuliti in modo sicuro nel thread in background.
+ `CheckpointlessMegatronStrategy`: Eredita dalla forma di Nemo`MegatronStrategy`. Nota che l'addestramento senza checkpoint richiede almeno 2 partecipanti `num_distributed_optimizer_instances` per consentire la replica dell'ottimizzatore. La strategia si occupa anche della registrazione degli attributi essenziali e dell'inizializzazione dei gruppi di processi, ad esempio rootless.
+ `CheckpointlessCallback`: Lightning callback che integra l' NeMo allenamento con il sistema di tolleranza ai guasti di checkpointless training. Ha le seguenti responsabilità principali:
+ **Gestione del ciclo di vita delle fasi di allenamento**: tiene traccia dei progressi dell'allenamento e si coordina ParameterUpdateLock per enable/disable un recupero senza problemi in base allo stato dell'allenamento (prima fase e fasi successive).
+ **Checkpoint State Coordination**: gestisce il salvataggio/ripristino dei checkpoint del modello base PEFT in memoria.
+ `CheckpointlessCompatibleConnector`: Un PTL `CheckpointConnector` che tenta di precaricare il file di checkpoint in memoria, con il percorso di origine determinato in base a questa priorità:
+ prova checkpointless recovery
+ se checkpointless restituisce None, torna a parent.resume\$1start ()
Guarda l'esempio per aggiungere funzionalità di formazione senza [checkpointless ai codici.](https://github.com/aws/sagemaker-hyperpod-checkpointless-training/blob/main/examples/gpt_oss/gpt_oss_120b_full_finetune.py)
**Concetti**
Questa sezione introduce concetti di formazione senza checkpoint. La formazione Checkpointless su Amazon SageMaker HyperPod supporta il ripristino in corso. Questa interfaccia API segue un formato simile a quello di. NVRx APIs
**Concetto: Re-Executable Code Block (RCB)**
Quando si verifica un errore, i processi sani rimangono attivi, ma una parte del codice deve essere rieseguita per ripristinare gli stati di addestramento e gli stack python. Un Re-Executable Code Block (RCB) è un segmento di codice specifico che viene eseguito nuovamente durante il ripristino in caso di errore. Nell'esempio seguente, l'RCB comprende l'intero script di addestramento (ovvero, tutto ciò che è contenuto in main ()), il che significa che ogni ripristino in caso di errore riavvia lo script di addestramento preservando il modello in memoria e gli stati dell'ottimizzatore.
**Concetto: controllo dei guasti**
Un modulo di controllo dei guasti riceve notifiche quando si verificano guasti durante un addestramento senza checkpoint. Questo controller di guasto include i seguenti componenti:
+ **Modulo di rilevamento dei guasti:** riceve notifiche di guasti dell'infrastruttura
+ **Definizione RCB APIs:** consente agli utenti di definire il blocco di codice rieseguibile (RCB) nel proprio codice
+ **Modulo di riavvio:** termina l'RCB, ripulisce le risorse e riavvia l'RCB
![\[Questa immagine illustra come un modulo di controllo dei guasti riceve notifiche quando si verifica un errore durante un addestramento senza checkpoint.\]](http://docs.aws.amazon.com/it_it/sagemaker/latest/dg/images/hyperpod/hyperpod-checkpointless-fault-controller-module.png)
**Concetto: ridondanza del modello**
L'addestramento su modelli di grandi dimensioni richiede in genere una dimensione parallela dei dati sufficientemente grande per addestrare i modelli in modo efficiente. Nel tradizionale parallelismo dei dati come PyTorch DDP e Horovod, il modello è completamente replicato. Le tecniche più avanzate di parallelismo dei dati condivisi come DeepSpeed Zero Optimizer e FSDP supportano anche la modalità di sharding ibrida, che consente di suddividere gli stati all'interno del gruppo di sharding e di replicarli completamente tra i gruppi di replica. model/optimizer NeMo ha anche questa funzione di sharding ibrido tramite un argomento num\$1distributed\$1optimizer\$1instances, che consente la ridondanza.
Tuttavia, l'aggiunta della ridondanza indica che il modello non sarà completamente suddiviso in tutto il cluster, con conseguente maggiore utilizzo della memoria del dispositivo. La quantità di memoria ridondante varierà a seconda delle specifiche tecniche di sharding del modello implementate dall'utente. I pesi, i gradienti e la memoria di attivazione del modello a bassa precisione non ne risentiranno, poiché vengono suddivisi tramite il parallelismo del modello. Il modello master ad alta precisione e gli stati dell'ottimizzatore ne risentiranno. weights/gradients L'aggiunta di una replica ridondante del modello aumenta l'utilizzo della memoria del dispositivo all'incirca dell'equivalente delle dimensioni di un checkpoint DCP.
Lo sharding ibrido suddivide i collettivi di tutti i gruppi DP in collettivi relativamente più piccoli. In precedenza c'era una riduzione della dispersione e un raggruppamento universale tra l'intero gruppo DP. Dopo lo sharding ibrido, il reduce-scatter viene eseguito solo all'interno di ogni replica del modello e verrà applicata una riduzione totale tra i gruppi di repliche dei modelli. L'all-collect funziona anche all'interno di ogni replica del modello. Di conseguenza, l'intero volume di comunicazioni rimane pressoché invariato, ma i collettivi utilizzano gruppi più piccoli, quindi ci aspettiamo una latenza migliore.
**Concetto: tipi di errore e riavvio**
La tabella seguente riporta i diversi tipi di errore e i meccanismi di ripristino associati. Checkpointless training tenta innanzitutto il ripristino in caso di errore tramite un ripristino in corso, seguito da un riavvio a livello di processo. Si ritorna al riavvio a livello di processo solo in caso di guasto catastrofico (ad esempio, guasto di più nodi contemporaneamente).
| Tipo di errore | Causa | Tipo di ripristino | Meccanismo di ripristino |
| --- | --- | --- | --- |
| Guasto durante il processo | Errori a livello di codice, eccezioni | Ripristino in corso (IPR) | Riesegui RCB all'interno del processo esistente; i processi sani rimangono attivi |
| Errore di riavvio del processo | Contesto CUDA danneggiato, processo interrotto | Riavvio a livello di processo (PLR) | SageMaker HyperPod l'operatore addetto alla formazione riavvia i processi; salta il riavvio del pod K8s |
| Errore di sostituzione del nodo | Guasto node/GPU hardware permanente | Job Level Restart (JLR) | Sostituisci il nodo fallito; riavvia l'intero processo di formazione |
**Concetto: protezione Atomic Lock per Optimizer Step**
L'esecuzione del modello è suddivisa in tre fasi: propagazione in avanti, propagazione all'indietro e fase di ottimizzazione. Il comportamento di ripristino varia in base alla tempistica dell'errore:
+ **Propagazione avanti/indietro:** torna all'inizio della fase di addestramento corrente e trasmetti gli stati del modello ai nodi sostitutivi
+ **Fase di ottimizzazione:** consenti alle repliche sane di completare la fase di blocco della protezione, quindi trasmetti gli stati aggiornati del modello ai nodi sostitutivi
Questa strategia garantisce che gli aggiornamenti completati dell'ottimizzatore non vengano mai scartati, contribuendo a ridurre i tempi di ripristino dei guasti.
![\[Questa immagine illustra come viene gestito l'errore a seconda che si verifichi prima o dopo l'errore.\]](http://docs.aws.amazon.com/it_it/sagemaker/latest/dg/images/hyperpod/hyperpod-checkpointless-optimizer.png)
## Diagramma del flusso di allenamento Checkpointless
![\[Questo diagramma illustra il flusso di allenamento senza checkpoint.\]](http://docs.aws.amazon.com/it_it/sagemaker/latest/dg/images/hyperpod/hyperpod-checkpointless-training-flow.png)
I passaggi seguenti descrivono il processo di rilevamento degli errori e di ripristino senza checkpoint:
1. Inizia il ciclo di formazione
1. Si verifica un errore
1. Valuta la fattibilità di un curriculum senza controlli
1. Verifica se è possibile eseguire un curriculum senza checkpoint
+ Se possibile, prova a riprendere senza checkpointless
+ Se la ripresa fallisce, torna al caricamento del checkpoint dallo storage
+ Se la ripresa ha esito positivo, l'allenamento continua dallo stato di ripristino
+ Se non è possibile, ricorri al checkpoint di caricamento dal magazzino
1. Pulisci le risorse: interrompi tutti i gruppi di processi e i backend e libera le risorse in preparazione al riavvio.
1. Riprendi il ciclo di allenamento: inizia un nuovo ciclo di allenamento e il processo torna alla fase 1.
## Guida di riferimento alle API
### wait\$1rank
```
hyperpod_checkpointless_training.inprocess.train_utils.wait_rank()
```
Attende e recupera le informazioni sulla classificazione da HyperPod, quindi aggiorna l'ambiente di processo corrente con variabili di addestramento distribuite.
Questa funzione ottiene l'assegnazione del grado e le variabili di ambiente corrette per l'addestramento distribuito. Garantisce che ogni processo ottenga la configurazione appropriata per il suo ruolo nel processo di formazione distribuito.
**Parametri**
Nessuno
**Valori restituiti**
**Nessuno**
**Comportamento**
+ **Controllo del processo**: salta l'esecuzione se viene chiamato da un sottoprocesso (viene eseguito solo in) MainProcess
+ **Recupero dell'ambiente: recupera le variabili** correnti `RANK` e da quelle di ambiente `WORLD_SIZE`
+ **HyperPod Comunicazione**: chiamate `hyperpod_wait_rank_info()` da cui recuperare informazioni sulla classifica HyperPod
+ **Aggiornamento dell'ambiente**: aggiorna l'ambiente di processo corrente con le variabili di ambiente specifiche del lavoratore ricevute da HyperPod
**Variabili di ambiente**
La funzione legge le seguenti variabili di ambiente:
+ **RANK** (*int*) — Classificazione attuale del processo (impostazione predefinita: -1 se non è impostata)
+ **WORLD\$1SIZE** (*int*) — Numero totale di processi nel processo distribuito (predefinito: 0 se non è impostato)
**Aumenta**
+ **AssertionError**— Se la risposta di non HyperPod è nel formato previsto o se mancano i campi obbligatori
**Esempio**
```
from hyperpod_checkpointless_training.inprocess.train_utils import wait_rank
# Call before initializing distributed training
wait_rank()
# Now environment variables are properly set for this rank
import torch.distributed as dist
dist.init_process_group(backend='nccl')
```
**Note**
+ Viene eseguito solo nel processo principale; le chiamate ai sottoprocessi vengono saltate automaticamente
+ La funzione si blocca finché non HyperPod fornisce le informazioni sulla classificazione
### HPWrapper
```
class hyperpod_checkpointless_training.inprocess.wrap.HPWrapper(
*,
abort=Compose(HPAbortTorchDistributed()),
finalize=None,
health_check=None,
hp_api_factory=None,
abort_timeout=None,
enabled=True,
trace_file_path=None,
async_raise_before_abort=True,
early_abort_communicator=False,
checkpoint_manager=None,
check_memory_status=True)
```
*Wrapper di funzioni Python che abilita le funzionalità di riavvio per un Re-Executable Code Block (RCB) durante un addestramento senza checkpoint. HyperPod *
*Questo wrapper offre funzionalità di tolleranza agli errori e ripristino automatico monitorando l'esecuzione della formazione e coordinando i riavvii tra i processi distribuiti in caso di errori. Utilizza un approccio di gestione del contesto anziché un decoratore per mantenere le risorse globali durante tutto il ciclo di vita della formazione.*
**Parametri**
+ **abort** (Abort, *opzionale*): *interrompe* l'esecuzione in modo asincrono quando vengono rilevati errori. Impostazione predefinita: `Compose(HPAbortTorchDistributed())`
+ **finalize (Finalize**, *opzionale*) — Gestore di *finalizzazione* Rank-Local eseguito durante il riavvio. Impostazione predefinita: `None`
+ **health\$1check (*HealthCheck*, *opzionale*) — Controllo dello** stato di salute di Rank-local eseguito durante il riavvio. Impostazione predefinita: `None`
+ **hp\$1api\$1factory** (*Callable*, *opzionale*) — Funzione di fabbrica per la creazione di un'API con cui interagire. HyperPod HyperPod Impostazione predefinita: `None`
+ **abort\$1timeout (*float*, *opzionale*) — Timeout** per interrompere la chiamata nel thread di controllo degli errori. Impostazione predefinita: `None`
+ **enabled** (*bool*, *opzionale*) — Abilita la funzionalità wrapper. Quando`False`, il wrapper diventa un pass-through. Impostazione predefinita: `True`
+ **trace\$1file\$1path** (*str*, *opzionale*) — Percorso del file di traccia per la profilazione. VizTracer Impostazione predefinita: `None`
+ **async\$1raise\$1before\$1abort (bool, opzionale) — Abilita il raise before abort** **nel thread di controllo degli errori.** Impostazione predefinita: `True`
+ **early\$1abort\$1communicator** **(bool, opzionale) — Interrompe il comunicatore (nccl/Gloo) prima di interrompere il dataloader.** Impostazione predefinita: `False`
+ **checkpoint\$1manager** (*Any*, *opzionale*) — Gestore per la gestione dei checkpoint durante il ripristino. Impostazione predefinita: `None`
+ **check\$1memory\$1status** *(*bool*, opzionale) — Abilita il controllo e la registrazione dello stato della memoria.* Impostazione predefinita: `True`
**Metodi**
```
def __call__(self, fn)
```
*Racchiude una funzione per abilitare le funzionalità di riavvio.*
**Parametri:**
+ **fn** (*Callable*) — La funzione da completare con le funzionalità di riavvio
**Restituisce:**
+ **Richiamabile**: funzione racchiusa con funzionalità di riavvio o funzione originale se disabilitata
**Esempio**
```
from hyperpod_checkpointless_training.nemo_plugins.checkpoint_manager import CheckpointManager
from hyperpod_checkpointless_training.nemo_plugins.patches import patch_megatron_optimizer
from hyperpod_checkpointless_training.nemo_plugins.checkpoint_connector import CheckpointlessCompatibleConnector
from hyperpod_checkpointless_training.inprocess.train_utils import HPAgentK8sAPIFactory
from hyperpod_checkpointless_training.inprocess.abort import CheckpointlessFinalizeCleanup, CheckpointlessAbortManager
@HPWrapper(
health_check=CudaHealthCheck(),
hp_api_factory=HPAgentK8sAPIFactory(),
abort_timeout=60.0,
checkpoint_manager=CheckpointManager(enable_offload=False),
abort=CheckpointlessAbortManager.get_default_checkpointless_abort(),
finalize=CheckpointlessFinalizeCleanup(),
)def training_function():
# Your training code here
pass
```
**Note**
+ Il wrapper deve essere disponibile `torch.distributed`
+ Quando`enabled=False`, il wrapper diventa un pass-through e restituisce la funzione originale invariata
+ Il wrapper mantiene risorse globali come il monitoraggio dei thread durante tutto il ciclo di vita della formazione
+ Supporta la profilazione quando viene fornita VizTracer `trace_file_path`
+ Si integra HyperPod per una gestione coordinata dei guasti nell'ambito della formazione distribuita
### HPCallInvolucro
```
class hyperpod_checkpointless_training.inprocess.wrap.HPCallWrapper(wrapper)
```
Monitora e gestisce lo stato di un Restart Code Block (RCB) durante l'esecuzione.
Questa classe gestisce il ciclo di vita dell'esecuzione di RCB, incluso il rilevamento degli errori, il coordinamento con altri ranghi per i riavvii e le operazioni di pulizia. Gestisce la sincronizzazione distribuita e garantisce un ripristino coerente in tutti i processi di formazione.
**Parametri**
+ **wrapper** (*HPWrapper*) — Il wrapper principale contenente le impostazioni globali di ripristino durante il processo
**Attributes**
+ **step\$1upon\$1restart** (*int*) — Contatore che tiene traccia dei passaggi dall'ultimo riavvio, utilizzato per determinare la strategia di riavvio
**Metodi**
```
def initialize_barrier()
```
Attendi la sincronizzazione della HyperPod barriera dopo aver riscontrato un'eccezione da RCB.
```
def start_hp_fault_handling_thread()
```
Avvia il thread di gestione degli errori per monitorare e coordinare gli errori.
```
def handle_fn_exception(call_ex)
```
Elabora le eccezioni dalla funzione di esecuzione o da RCB.
**Parametri:**
+ **call\$1ex** (*Exception) — Eccezione* dalla funzione di monitoraggio
```
def restart(term_ex)
```
Esegue il gestore di riavvio che include la finalizzazione, la raccolta dei rifiuti e i controlli di integrità.
**Parametri:**
+ **term\$1ex** (*RankShouldRestart*) — Eccezione di terminazione che attiva il riavvio
```
def launch(fn, *a, **kw)
```
*Esegui l'RCB con una corretta gestione delle eccezioni.*
**Parametri:**
+ **fn** (*Callable*) — Funzione da eseguire
+ **a — Argomenti** della funzione
+ **kw** — Argomenti delle parole chiave della funzione
```
def run(fn, a, kw)
```
Ciclo di esecuzione principale che gestisce i riavvii e la sincronizzazione delle barriere.
**Parametri:**
+ **fn** (*Callable*) — Funzione da eseguire
+ **a — Argomenti** della funzione
+ **kw** — Argomenti delle parole chiave della funzione
```
def shutdown()
```
Gestione degli errori di spegnimento e thread di monitoraggio.
**Note**
+ Gestisce automaticamente le `RankShouldRestart` eccezioni per un ripristino coordinato
+ Gestisce il tracciamento e gli aborti della memoria, la raccolta dei rifiuti durante i riavvii
+ Supporta sia il ripristino in corso che le strategie PLR (Process-Level Restart) basate sulla tempistica degli errori
### CudaHealthCheck
```
class hyperpod_checkpointless_training.inprocess.health_check.CudaHealthCheck(timeout=datetime.timedelta(seconds=30))
```
Assicura che il contesto CUDA per il processo corrente sia in buono stato durante il recupero dall'allenamento senza checkpoint.
Questo controllo di integrità si sincronizza con la GPU per verificare che il contesto CUDA non sia danneggiato dopo un errore di allenamento. Esegue operazioni di sincronizzazione della GPU per rilevare eventuali problemi che potrebbero impedire la corretta ripresa dell'allenamento. Il controllo dello stato viene eseguito dopo la distruzione dei gruppi distribuiti e il completamento della finalizzazione.
**Parametri**
+ **timeout** (*datetime.timedelta, *opzionale*) — Durata del timeout* per le operazioni di sincronizzazione della GPU. Impostazione predefinita: `datetime.timedelta(seconds=30)`
**Metodi**
```
__call__(state, train_ex=None)
```
Esegui il controllo dello stato di salute CUDA per verificare l'integrità del contesto della GPU.
**Parametri:**
+ **state (*HPState*) — HyperPod Stato** attuale contenente informazioni sulla classificazione e sulla distribuzione
+ **train\$1ex** (*Eccezione*, *opzionale*) — L'eccezione di allenamento originale che ha attivato il riavvio. Impostazione predefinita: `None`
**Restituisce:**
+ **tuple** — Una tupla che contiene `(state, train_ex)` invariate le modifiche se il controllo sanitario ha esito positivo
**Aumenta:**
+ **TimeoutError**— Se la sincronizzazione della GPU scade, indica un contesto CUDA potenzialmente danneggiato
**Conservazione dello stato**: restituisce lo stato e l'eccezione originali invariati se tutti i controlli vengono superati
**Esempio**
```
import datetime
from hyperpod_checkpointless_training.inprocess.health_check import CudaHealthCheck
from hyperpod_checkpointless_training.inprocess.wrap import HPWrapper
# Create CUDA health check with custom timeout
cuda_health_check = CudaHealthCheck(
timeout=datetime.timedelta(seconds=60)
)
# Use with HPWrapper for fault-tolerant training
@HPWrapper(
health_check=cuda_health_check,
enabled=True
)
def training_function():
# Your training code here
pass
```
**Note**
+ Utilizza il threading per implementare la protezione da timeout per la sincronizzazione della GPU
+ Progettato per rilevare contesti CUDA danneggiati che potrebbero impedire la corretta ripresa dell'allenamento
+ Dovrebbe essere utilizzato come parte della pipeline di tolleranza agli errori negli scenari di formazione distribuiti
### HPAgentK8s APIFactory
```
class hyperpod_checkpointless_training.inprocess.train_utils.HPAgentK8sAPIFactory()
```
Classe Factory per la creazione di istanze HPAgent K8SAPi che comunicano con HyperPod l'infrastruttura per il coordinamento distribuito della formazione.
Questa factory fornisce un modo standardizzato per creare e configurare oggetti HPAgent K8SAPi che gestiscono la comunicazione tra i processi di addestramento e il piano di controllo. HyperPod Incapsula la creazione del client socket sottostante e dell'istanza API, garantendo una configurazione coerente tra le diverse parti del sistema di formazione.
**Metodi**
```
__call__()
```
Crea e restituisci un'istanza HPAgent K8SAPi configurata per la comunicazione. HyperPod
**Restituisce:**
+ **HPAgentK8sapi**: istanza API configurata per la comunicazione con l'infrastruttura HyperPod
**Esempio**
```
from hyperpod_checkpointless_training.inprocess.train_utils import HPAgentK8sAPIFactory
from hyperpod_checkpointless_training.inprocess.wrap import HPWrapper
from hyperpod_checkpointless_training.inprocess.health_check import CudaHealthCheck
# Create the factory
hp_api_factory = HPAgentK8sAPIFactory()
# Use with HPWrapper for fault-tolerant training
hp_wrapper = HPWrapper(
hp_api_factory=hp_api_factory,
health_check=CudaHealthCheck(),
abort_timeout=60.0,
enabled=True
)
@hp_wrapper
def training_function():
# Your distributed training code here
pass
```
**Note**
+ Progettato per funzionare perfettamente con l'infrastruttura basata su Kubernetes. HyperPod È essenziale per la gestione e il ripristino coordinati dei guasti in scenari di formazione distribuiti
### CheckpointManager
```
class hyperpod_checkpointless_training.nemo_plugins.checkpoint_manager.CheckpointManager(
enable_checksum=False,
enable_offload=False)
```
Gestisce i checkpoint in memoria e peer-to-peer il ripristino per una tolleranza agli errori senza checkpoint nell'addestramento distribuito.
Questa classe fornisce le funzionalità di base per un addestramento HyperPod senza checkpoint gestendo i checkpoint del NeMo modello in memoria, convalidando la fattibilità del recupero e orchestrando il trasferimento dei checkpoint tra i ranghi sani e quelli falliti. peer-to-peer Elimina la necessità del disco I/O durante il ripristino, riducendo in modo significativo il tempo medio di ripristino (MTTR).
**Parametri**
+ **enable\$1checksum** (*bool*, *opzionale*) — Abilita la convalida del checksum dello stato del modello per i controlli di integrità durante il ripristino. Impostazione predefinita: `False`
+ **enable\$1offload (*bool*, *opzionale*) — Abilita l'offload** dei checkpoint dalla GPU alla memoria della CPU per ridurre l'utilizzo della memoria della GPU. Impostazione predefinita: `False`
**Attributes**
+ **global\$1step (int o None) — Fase** *di allenamento corrente associata al checkpoint* *salvato*
+ **rng\$1states (*list* o *None*) — Stati** del generatore di numeri casuali memorizzati per il recupero deterministico
+ **checksum\$1manager** (*MemoryChecksumManager*) — Gestore per la convalida del checksum dello stato del modello
+ **parameter\$1update\$1lock (**) — Blocco per coordinare gli aggiornamenti dei parametri durante il ripristino *ParameterUpdateLock*
**Metodi**
```
save_checkpoint(trainer)
```
Salva il checkpoint del NeMo modello in memoria per un potenziale ripristino senza checkpoint.
**Parametri:**
+ **trainer (*Pytorch\$1Lightning.trainer***) — Istanza del trainer Lightning PyTorch
**Note:**
+ Chiamato CheckpointlessCallback alla fine del batch o durante la gestione delle eccezioni
+ Crea punti di ripristino senza I/O sovraccarico del disco
+ Memorizza gli stati completi del modello, dell'ottimizzatore e dello scheduler
```
delete_checkpoint()
```
Elimina il checkpoint in memoria ed esegui le operazioni di pulizia.
**Note:**
+ Cancella i dati del checkpoint, gli stati RNG e i tensori memorizzati nella cache
+ Esegue la raccolta dei rifiuti e la pulizia della cache CUDA
+ Chiamato dopo il ripristino riuscito o quando il checkpoint non è più necessario
```
try_checkpointless_load(trainer)
```
Tenta il ripristino senza checkpoint caricando lo stato dai ranghi dei peer ranks.
**Parametri:**
+ **trainer (*PyTorch\$1Lightning.trainer***) — Istanza del trainer Lightning PyTorch
**Restituisce:**
+ **dict** o **None**: checkpoint ripristinato in caso di successo, Nessuno se è necessario eseguire il fallback su disco
**Note:**
+ Punto di accesso principale per il ripristino senza checkpoint
+ Convalida la fattibilità del ripristino prima di tentare il trasferimento P2P
+ Pulisce sempre i checkpoint in memoria dopo il tentativo di ripristino
```
checkpointless_recovery_feasible(trainer, include_checksum_verification=True)
```
Determina se è possibile un ripristino senza checkpoint per lo scenario di errore corrente.
**Parametri:**
+ **trainer (*Pytorch\$1Lightning.trainer***) — Istanza del trainer Lightning PyTorch
+ **include\$1checksum\$1verification (bool, opzionale) — **Se includere la** convalida del checksum.** Impostazione predefinita: `True`
**Restituisce:**
+ **bool** — Vero se il ripristino senza checkpoint è fattibile, False altrimenti
**Criteri di convalida:**
+ Coerenza globale dei passaggi tra i ranghi più sani
+ Sono disponibili sufficienti repliche sane per il ripristino
+ Integrità del checksum dello stato del modello (se abilitata)
```
store_rng_states()
```
Memorizza tutti gli stati del generatore di numeri casuali per il ripristino deterministico.
**Note:**
+ Cattura gli stati RNG di Python NumPy PyTorch , CPU/GPU e Megatron
+ Essenziale per mantenere il determinismo dell'allenamento dopo il recupero
```
load_rng_states()
```
Ripristina tutti gli stati RNG per una continuazione deterministica del recupero.
**Note:**
+ Ripristina tutti gli stati RNG precedentemente memorizzati
+ Assicura che l'allenamento continui con sequenze casuali identiche
```
maybe_offload_checkpoint()
```
Sposta il checkpoint dalla GPU alla memoria della CPU se l'offload è abilitato.
**Note:**
+ Riduce l'utilizzo della memoria della GPU per i modelli di grandi dimensioni
+ Viene eseguito solo se `enable_offload=True`
+ Mantiene l'accessibilità ai checkpoint per il ripristino
**Esempio**
```
from hyperpod_checkpointless_training.inprocess.wrap import HPWrapper
from hyperpod_checkpointless_training.nemo_plugins.checkpoint_manager import CheckpointManager
# Use with HPWrapper for complete fault tolerance
@HPWrapper(
checkpoint_manager=CheckpointManager(),
enabled=True
)
def training_function():
# Training code with automatic checkpointless recovery
pass
```
**Convalida**: verifica l'integrità del checkpoint utilizzando i checksum (se abilitati)
**Note**
+ Utilizza primitive di comunicazione distribuite per un trasferimento P2P efficiente
+ Gestisce automaticamente le conversioni di tipo d del tensore e il posizionamento dei dispositivi
+ **MemoryChecksumManager**— Gestisce la convalida dell'integrità dello stato del modello
### PEFTCheckpointGestore
```
class hyperpod_checkpointless_training.nemo_plugins.checkpoint_manager.PEFTCheckpointManager(
*args,
**kwargs)
```
Gestisce i checkpoint per PEFT (Parameter-Efficient Fine-Tuning) con gestione separata della base e dell'adattatore per un ripristino ottimizzato senza checkpoint.
Questo gestore di checkpoint specializzato consente di ottimizzare i flussi di lavoro PEFT separando CheckpointManager i pesi del modello base dai parametri dell'adattatore.
**Parametri**
Eredita tutti i parametri da: **CheckpointManager**
+ **enable\$1checksum** (*bool*, *opzionale*) — Abilita la convalida del checksum dello stato del modello. Impostazione predefinita: `False`
+ **enable\$1offload (*bool*, opzionale) — Abilita l'offloading del checkpoint** *nella memoria della CPU.* Impostazione predefinita: `False`
**Attributi aggiuntivi**
+ **params\$1to\$1save** (*set) — Set* di nomi di parametri che devono essere salvati come parametri dell'adattatore
+ **base\$1model\$1weights (*dict* o None) — Pesi** *del modello base memorizzati nella cache, salvati una volta e riutilizzati*
+ ****base\$1model\$1keys\$1to\$1extract (list o None) — Chiavi per estrarre i tensori del modello base durante il trasferimento P2P****
**Metodi**
```
maybe_save_base_model(trainer)
```
Salva i pesi del modello base una volta, filtrando i parametri dell'adattatore.
**Parametri:**
+ **trainer (*PyTorch\$1Lightning.trainer***) — Istanza del trainer Lightning PyTorch
**Note:**
+ Salva i pesi del modello base solo alla prima chiamata; le chiamate successive non sono operative
+ Filtra i parametri dell'adattatore per memorizzare solo i pesi del modello base congelati
+ I pesi del modello base vengono mantenuti per più sessioni di allenamento
```
save_checkpoint(trainer)
```
Salva il checkpoint del modello di adattatore NeMo PEFT in memoria per un potenziale ripristino senza checkpoint.
**Parametri:**
+ **trainer (*PyTorch\$1Lightning.trainer***) — Istanza di Lightning trainer PyTorch
**Note:**
+ `maybe_save_base_model()`Chiama automaticamente se il modello base non è ancora stato salvato
+ Filtra il checkpoint per includere solo i parametri dell'adattatore e lo stato di allenamento
+ Riduce in modo significativo le dimensioni dei checkpoint rispetto ai checkpoint del modello completo
```
try_base_model_checkpointless_load(trainer)
```
Il modello base di Attempt PEFT soppesa il ripristino senza checkpoint caricando lo stato dai ranghi dei peer rank.
**Parametri:**
+ *trainer (**PyTorch\$1Lightning.trainer) — Istanza del trainer Lightning*** PyTorch
**Restituisce:**
+ **dict** o **None** — Il checkpoint del modello base è stato ripristinato in caso di successo, None se è necessario il fallback
**Note:**
+ Utilizzato durante l'inizializzazione del modello per recuperare i pesi del modello base
+ Non elimina i pesi del modello base dopo il ripristino (li conserva per il riutilizzo)
+ Ottimizzato per scenari di ripristino model-weights-only
```
try_checkpointless_load(trainer)
```
L'adattatore PEFT di Attempt soppesa il ripristino senza checkpoint caricando lo stato dai ranghi dei colleghi.
**Parametri:**
+ *trainer (**PyTorch\$1Lightning.trainer) — Istanza di Lightning trainer*** PyTorch
**Restituisce:**
+ **dict** o **None** — Il checkpoint dell'adattatore è stato ripristinato in caso di successo, Nessuno se è necessario il fallback
**Note:**
+ Recupera solo i parametri dell'adattatore, gli stati dell'ottimizzatore e gli scheduler
+ Carica automaticamente gli stati dell'ottimizzatore e dello scheduler dopo il ripristino riuscito
+ Pulisce i checkpoint dell'adattatore dopo il tentativo di ripristino
```
is_adapter_key(key)
```
Controlla se la chiave state dict appartiene ai parametri dell'adattatore.
**Parametri:**
+ **key** (*str* o *tuple*) — Chiave dict di stato da controllare
**Restituisce:**
+ **bool** — Vero se la chiave è il parametro dell'adattatore, False se è il parametro del modello base
**Logica di rilevamento:**
+ Controlla se la chiave è `params_to_save` impostata
+ Identifica le chiavi contenenti «.adapter». substring
+ Identifica le chiavi che terminano con «.adapters»
+ Per le chiavi tuple, controlla se il parametro richiede gradienti
```
maybe_offload_checkpoint()
```
Scarica i pesi del modello base dalla GPU alla memoria della CPU.
**Note:**
+ Estende il metodo principale per gestire lo scaricamento del peso del modello base
+ I pesi degli adattatori sono in genere piccoli e non richiedono lo scarico
+ Imposta un flag interno per tracciare lo stato di offload
**Note**
+ Progettato specificamente per scenari di fine-tuning efficienti dal punto di vista dei parametri (LoRa, adattatori, ecc.)
+ Gestisce automaticamente la separazione dei parametri del modello base e dell'adattatore
**Esempio**
```
from hyperpod_checkpointless_training.inprocess.wrap import HPWrapper
from hyperpod_checkpointless_training.nemo_plugins.checkpoint_manager import PEFTCheckpointManager
# Use with HPWrapper for complete fault tolerance
@HPWrapper(
checkpoint_manager=PEFTCheckpointManager(),
enabled=True
)
def training_function():
# Training code with automatic checkpointless recovery
pass
```
### CheckpointlessAbortManager
```
class hyperpod_checkpointless_training.inprocess.abort.CheckpointlessAbortManager()
```
Classe Factory per la creazione e la gestione delle composizioni dei componenti di interruzione per una tolleranza ai guasti senza checkpoint.
Questa classe di utilità fornisce metodi statici per creare, personalizzare e gestire le composizioni dei componenti di aborto utilizzate durante la gestione dei guasti durante la formazione senza checkpoint. HyperPod Semplifica la configurazione delle sequenze di interruzione che gestiscono la pulizia dei componenti di formazione distribuiti, dei caricatori di dati e delle risorse specifiche del framework durante il ripristino in caso di errore.
**Parametri**
Nessuno (tutti i metodi sono statici)
**Metodi statici**
```
get_default_checkpointless_abort()
```
Ottieni l'istanza abort compose predefinita contenente tutti i componenti di abort standard.
**Restituisce:**
+ **Componi**: istanza di interruzione composta predefinita con tutti i componenti di interruzione
**Componenti predefiniti:**
+ **AbortTransformerEngine()** — Pulisce le risorse TransformerEngine
+ **HPCheckpointingAbort ()** — Gestisce la pulizia del sistema di checkpoint
+ **HPAbortTorchDistributed()** — Interrompe le operazioni distribuite PyTorch
+ **HPDataLoaderAbort()** — Arresta e pulisce i caricatori di dati
```
create_custom_abort(abort_instances)
```
*Crea una composizione di interruzione personalizzata con solo le istanze di interruzione specificate.*
**Parametri:**
+ **abort\$1instances** (*Abort) — Numero variabile di istanze di aborto* da includere nella composizione
**Restituisce:**
+ **Componi** — Nuova istanza di interruzione composta contenente solo i componenti specificati
**Aumenta:**
+ **ValueError**— Se non vengono fornite istanze di interruzione
```
override_abort(abort_compose, abort_type, new_abort)
```
Sostituisci un componente di interruzione specifico in un'istanza Compose con un nuovo componente.
**Parametri:**
+ **abort\$1compose (Compose**) — L'*istanza Compose* originale da modificare
+ **abort\$1type (type**) — Il *tipo di componente di* interruzione da sostituire (ad esempio,) `HPCheckpointingAbort`
+ **new\$1abort** (Abort) — La nuova istanza di *abort* da utilizzare come sostituto
**Restituisce:**
+ **Compose** — Nuova istanza Compose con il componente specificato sostituito
**Aumenta:**
+ **ValueError**— Se abort\$1compose non ha l'attributo 'instances'
**Esempio**
```
from hyperpod_checkpointless_training.inprocess.wrap import HPWrapper
from hyperpod_checkpointless_training.nemo_plugins.callbacks import CheckpointlessCallback
from hyperpod_checkpointless_training.inprocess.abort import CheckpointlessFinalizeCleanup, CheckpointlessAbortManager
# The strategy automatically integrates with HPWrapper
@HPWrapper(
abort=CheckpointlessAbortManager.get_default_checkpointless_abort(),
health_check=CudaHealthCheck(),
finalize=CheckpointlessFinalizeCleanup(),
enabled=True
)
def training_function():
trainer.fit(...)
```
**Note**
+ Le configurazioni personalizzate consentono un controllo preciso sul comportamento di pulizia
+ Le operazioni di interruzione sono fondamentali per una corretta pulizia delle risorse durante il ripristino dei guasti
### CheckpointlessFinalizeCleanup
```
class hyperpod_checkpointless_training.inprocess.abort.CheckpointlessFinalizeCleanup()
```
Esegue una pulizia completa dopo il rilevamento dei guasti per prepararsi al ripristino in corso durante l'addestramento senza checkpoint.
Questo gestore di finalizzazione esegue operazioni di pulizia specifiche del framework, tra cui Megatron/TransformerEngine interruzione, pulizia DDP, ricaricamento dei moduli e pulizia della memoria, eliminando i riferimenti ai componenti di addestramento. Garantisce che l'ambiente di formazione venga ripristinato correttamente per il corretto ripristino durante il processo senza richiedere l'interruzione completa del processo.
**Parametri**
Nessuno
**Attributes**
+ **trainer** *(*Pytorch\$1Lightning.trainer o None) — Riferimento all'istanza del trainer Lightning** PyTorch
**Metodi**
```
__call__(*a, **kw)
```
**Esegui operazioni di pulizia complete per la preparazione del ripristino durante il processo.**
*Parametri:*
+ **a** — Argomenti posizionali variabili (ereditati dall'interfaccia Finalize)
+ **kw** — Argomenti variabili relativi alle parole chiave (ereditati dall'interfaccia Finalize)
**Operazioni di pulizia:**
+ **Megatron Framework Cleanup**: chiamate per ripulire le risorse specifiche `abort_megatron()` di Megatron
+ **TransformerEngine Cleanup: chiamate per ripulire le risorse** `abort_te()` TransformerEngine
+ **RoPE Cleanup**: chiamate `cleanup_rope()` per ripulire le risorse di incorporamento della posizione rotante
+ **DDP Cleanup: chiamate per ripulire** le risorse `cleanup_ddp()` DistributedDataParallel
+ **Module Reloading: chiamate `reload_megatron_and_te()` per ricaricare** i moduli del framework
+ **Pulizia del modulo Lightning: cancella facoltativamente il** modulo Lightning per ridurre la memoria della GPU
+ **Memory Cleanup**: elimina i riferimenti ai componenti di addestramento per liberare memoria
```
register_attributes(trainer)
```
*Registra l'istanza del trainer per utilizzarla durante le operazioni di pulizia.*
**Parametri:**
+ **trainer** (*PyTorch\$1Lightning.trainer) — Istanza di Lightning* trainer da registrare PyTorch
**Integrazione con CheckpointlessCallback**
```
from hyperpod_checkpointless_training.nemo_plugins.callbacks import CheckpointlessCallback
from hyperpod_checkpointless_training.inprocess.wrap import HPWrapper
# The strategy automatically integrates with HPWrapper
@HPWrapper(
...
finalize=CheckpointlessFinalizeCleanup(),
)
def training_function():
trainer.fit(...)
```
**Note**
+ Le operazioni di pulizia vengono eseguite in un ordine specifico per evitare problemi di dipendenza
+ La pulizia della memoria utilizza l'introspezione della raccolta dei rifiuti per trovare gli oggetti di destinazione
+ Tutte le operazioni di pulizia sono progettate per essere idempotenti e sicure da riprovare
### CheckpointlessMegatronStrategy
```
class hyperpod_checkpointless_training.nemo_plugins.megatron_strategy.CheckpointlessMegatronStrategy(*args, **kwargs)
```
NeMo Strategia Megatron con funzionalità integrate di ripristino senza checkpoint per una formazione distribuita con tolleranza ai guasti.
Tieni presente che l'addestramento senza checkpoint deve essere almeno 2 in `num_distributed_optimizer_instances` modo da garantire la replica dell'ottimizzatore. La strategia si occupa anche della registrazione degli attributi essenziali e dell'inizializzazione dei gruppi di processi.
**Parametri**
Eredita tutti i parametri da: **MegatronStrategy**
+ NeMo MegatronStrategy Parametri di inizializzazione standard
+ Opzioni di configurazione della formazione distribuita
+ Impostazioni del parallelismo del modello
**Attributes**
+ **base\$1store** *(torch.distributed). TCPStore*o *Nessuno*) — Archivio distribuito per il coordinamento dei gruppi di processi
**Metodi**
```
setup(trainer)
```
Inizializza la strategia e registra i componenti di tolleranza ai guasti con il trainer.
**Parametri:**
+ **trainer (*PyTorch\$1Lightning.trainer***) — Istanza del trainer Lightning PyTorch
**Operazioni di configurazione:**
+ **Parent Setup**: richiama la MegatronStrategy configurazione principale
+ **Fault Injection Registration**: registra HPFault InjectionCallback gli hook, se presenti
+ **Finalizza la registrazione**: registra il trainer con i gestori di finalize cleanup
+ Interrompi la **registrazione: registra il trainer con i gestori di aborti che lo supportano**
```
setup_distributed()
```
Inizializza il gruppo di processi utilizzando una connessione con prefisso o senza root. TCPStore
```
load_model_state_dict(checkpoint, strict=True)
```
Carica il modello state dict con compatibilità di ripristino senza checkpointless.
**Parametri:**
+ **checkpoint** (*Mapping [str, Any]*) — Dizionario Checkpoint contenente lo stato del modello
+ **strict** (*bool*, *optional*) — Se applicare rigorosamente la corrispondenza delle chiavi state dict. Impostazione predefinita: `True`
```
get_wrapper()
```
Ottieni l'istanza HPCall Wrapper per il coordinamento della tolleranza agli errori.
**Restituisce:**
+ **HPCallWrapper**: l'istanza wrapper collegata al trainer per la tolleranza agli errori
```
is_peft()
```
Controlla se PEFT (Parameter-Efficient Fine-Tuning) è abilitato nella configurazione di addestramento verificando la presenza di callback PEFT
**Restituisce:**
+ **bool** — Vero se è presente il callback PEFT, False in caso contrario
```
teardown()
```
Sostituisci lo smontaggio nativo di PyTorch Lightning per delegare la pulizia ai gestori di aborti.
**Esempio**
```
from hyperpod_checkpointless_training.inprocess.wrap import HPWrapper
# The strategy automatically integrates with HPWrapper
@HPWrapper(
checkpoint_manager=checkpoint_manager,
enabled=True
)
def training_function():
trainer = pl.Trainer(strategy=CheckpointlessMegatronStrategy())
trainer.fit(model, datamodule)
```
### CheckpointlessCallback
```
class hyperpod_checkpointless_training.nemo_plugins.callbacks.CheckpointlessCallback(
enable_inprocess=False,
enable_checkpointless=False,
enable_checksum=False,
clean_tensor_hook=False,
clean_lightning_module=False)
```
Lightning callback che integra la formazione con il sistema di tolleranza ai guasti di checkpointless training. NeMo
Questo callback gestisce il tracciamento dei passaggi, il salvataggio dei checkpoint e il coordinamento dell'aggiornamento dei parametri per le funzionalità di ripristino durante il processo. Funge da punto di integrazione principale tra i cicli di formazione PyTorch Lightning e i meccanismi di addestramento HyperPod senza checkpoint, coordinando le operazioni di tolleranza agli errori durante l'intero ciclo di vita della formazione.
**Parametri**
+ ****enable\$1inprocess (bool, opzionale) — Abilita le funzionalità di ripristino durante il processo.**** Impostazione predefinita: `False`
+ **enable\$1checkpointless (*bool*, opzionale) — Abilita il ripristino senza checkpointless** *(richiesto).* `enable_inprocess=True` Impostazione predefinita: `False`
+ **enable\$1checksum (bool, opzionale) — Abilita la convalida del checksum** *dello stato del modello (richiesto**).* `enable_checkpointless=True` Impostazione predefinita: `False`
+ **clean\$1tensor\$1hook (*bool*, opzionale) — Elimina gli hook** *tensoriali da tutti i tensori della GPU durante la pulizia (operazione* costosa). Impostazione predefinita: `False`
+ **clean\$1lightning\$1module (bool, opzionale) — Abilita la pulizia del modulo Lightning** **per liberare memoria della GPU dopo ogni riavvio.** Impostazione predefinita: `False`
**Attributes**
+ **tried\$1adapter\$1checkpointless** *(bool) — Contrassegna per verificare se è stato tentato il ripristino senza checkpointless dell'adattatore*
**Metodi**
```
get_wrapper_from_trainer(trainer)
```
Scarica l'istanza Wrapper dal trainer per il coordinamento della tolleranza agli errori. HPCall
**Parametri:**
+ **trainer (*PyTorch\$1Lightning.trainer***) — Istanza del trainer Lightning PyTorch
**Restituisce:**
+ **HPCallWrapper**: l'istanza wrapper per le operazioni di tolleranza ai guasti
```
on_train_batch_start(trainer, pl_module, batch, batch_idx, *args, **kwargs)
```
Richiamato all'inizio di ogni batch di allenamento per gestire il monitoraggio e il recupero delle fasi.
**Parametri:**
+ **trainer** (*PyTorch\$1Lightning.trainer) — Istanza di Lightning* trainer PyTorch
+ **pl\$1module** (*pytorch\$1lightning). LightningModule*) — Modulo Lightning in fase di addestramento
+ **batch: dati** correnti relativi al batch di addestramento
+ **batch\$1idx** (*int*) — Indice del batch corrente
+ args — **Argomenti** posizionali aggiuntivi
+ **kwargs** — Argomenti aggiuntivi relativi alle parole chiave
```
on_train_batch_end(trainer, pl_module, outputs, batch, batch_idx)
```
*Rilascia il blocco di aggiornamento dei parametri alla fine di ogni batch di addestramento.*
**Parametri:**
+ **trainer** (*Pytorch\$1Lightning.trainer) — Istanza del trainer Lightning* PyTorch
+ **pl\$1module** (*pytorch\$1lightning). LightningModule*) — Modulo Lightning in fase di addestramento
+ **outputs** (*STEP\$1OUTPUT) — Uscite* della fase di addestramento
+ **batch (Any**) — *Dati* correnti del batch di addestramento
+ **batch\$1idx** (*int*) — Indice del batch corrente
**Note:**
+ La tempistica di rilascio del blocco garantisce che il ripristino senza checkpoint possa procedere dopo il completamento degli aggiornamenti dei parametri
+ Viene eseguito solo quando entrambi i valori sono impostati su True `enable_inprocess` `enable_checkpointless`
```
get_peft_callback(trainer)
```
*Recupera il callback PEFT dall'elenco dei callback del trainer.*
**Parametri:**
+ *trainer (**Pytorch\$1Lightning.trainer**) — Istanza del trainer Lightning* PyTorch
**Restituisce:**
+ **PEFT** o **None**: istanza di callback PEFT se trovata, nessuna in caso contrario
```
_try_adapter_checkpointless_restore(trainer, params_to_save)
```
*Tenta il ripristino senza checkpoint dei parametri dell'adattatore PEFT.*
**Parametri:**
+ **trainer (*Pytorch\$1Lightning.trainer***) — Istanza di Lightning trainer PyTorch
+ ***params\$1to\$1save (set) — Set di nomi di parametri da salvare come parametri dell'adattatore***
**Note:**
+ Viene eseguito solo una volta per sessione di allenamento (controllata da flag) `tried_adapter_checkpointless`
+ Configura il gestore dei punti di controllo con le informazioni sui parametri dell'adattatore
**Esempio**
```
from hyperpod_checkpointless_training.nemo_plugins.callbacks import CheckpointlessCallback
from hyperpod_checkpointless_training.nemo_plugins.checkpoint_manager import CheckpointManager
import pytorch_lightning as pl
# Create checkpoint manager
checkpoint_manager = CheckpointManager(
enable_checksum=True,
enable_offload=True
)
# Create checkpointless callback with full fault tolerance
checkpointless_callback = CheckpointlessCallback(
enable_inprocess=True,
enable_checkpointless=True,
enable_checksum=True,
clean_tensor_hook=True,
clean_lightning_module=True
)
# Use with PyTorch Lightning trainer
trainer = pl.Trainer(
callbacks=[checkpointless_callback],
strategy=CheckpointlessMegatronStrategy()
)
# Training with fault tolerance
trainer.fit(model, datamodule=data_module)
```
**Gestione della memoria**
+ **clean\$1tensor\$1hook: rimuove i ganci tensoriali** durante la pulizia (costoso ma completo)
+ **clean\$1lightning\$1module**: libera memoria GPU del modulo Lightning durante i riavvii
+ Entrambe le opzioni aiutano a ridurre l'ingombro di memoria durante il ripristino dei guasti
+ Coordinate con ParameterUpdateLock per il tracciamento degli aggiornamenti dei parametri thread-safe
### CheckpointlessCompatibleConnector
```
class hyperpod_checkpointless_training.nemo_plugins.checkpoint_connector.CheckpointlessCompatibleConnector()
```
PyTorch Connettore Lightning Checkpoint che integra il ripristino senza checkpoint con il tradizionale caricamento dei checkpoint basato su disco.
Questo connettore estende quello di PyTorch Lightning per fornire una perfetta integrazione tra il ripristino senza checkpoint e `_CheckpointConnector` il ripristino dei checkpoint standard. Tenta innanzitutto il ripristino senza checkpoint, quindi torna al caricamento del checkpoint basato su disco se il ripristino senza checkpoint non è fattibile o fallisce.
**Parametri**
**Eredita** tutti i parametri da \$1 CheckpointConnector
**Metodi**
```
resume_start(checkpoint_path=None)
```
Tentativo di precaricare il checkpoint con priorità di ripristino senza checkpointless.
**Parametri:**
+ **checkpoint\$1path** (*str* o *None*, *opzionale*) — Percorso verso il checkpoint del disco per il fallback. Impostazione predefinita: `None`
```
resume_end()
```
Completa il processo di caricamento del checkpoint ed esegui le operazioni successive al caricamento.
**Note**
+ Estende la `_CheckpointConnector` classe interna di PyTorch Lightning con il supporto per il ripristino senza checkpoint
+ Mantiene la piena compatibilità con i flussi di lavoro Lightning checkpoint standard PyTorch
### CheckpointlessAutoResume
```
class hyperpod_checkpointless_training.nemo_plugins.resume.CheckpointlessAutoResume()
```
Estende NeMo la funzionalità AutoResume con configurazione ritardata per consentire la convalida del ripristino senza checkpoint prima della risoluzione del percorso di checkpoint.
Questa classe implementa una strategia di inizializzazione in due fasi che consente la convalida del ripristino senza checkpoint prima di tornare al tradizionale caricamento dei checkpoint basato su disco. Ritarda in modo condizionale la AutoResume configurazione per impedire la risoluzione prematura del percorso dei checkpoint, permettendo di verificare innanzitutto se il ripristino senza checkpoint è fattibile. CheckpointManager peer-to-peer
**Parametri**
Eredita tutti i parametri da **AutoResume**
**Metodi**
```
setup(trainer, model=None, force_setup=False)
```
Ritarda la AutoResume configurazione in modo condizionale per consentire la convalida del ripristino senza checkpoint.
**Parametri:**
+ **trainer (Pytorch\$1Lightning.trainer o** *lightning.Fabric.fabric) — Lightning* *trainer o istanza Fabric* PyTorch
+ **model** *(opzionale) — Istanza* del modello per la configurazione. Impostazione predefinita: `None`
+ **force\$1setup** (*bool*, *opzionale*) — Se True, ignora il ritardo ed esegui immediatamente la configurazione. AutoResume Impostazione predefinita: `False`
**Esempio**
```
from hyperpod_checkpointless_training.nemo_plugins.resume import CheckpointlessAutoResume
from hyperpod_checkpointless_training.nemo_plugins.megatron_strategy import CheckpointlessMegatronStrategy
import pytorch_lightning as pl
# Create trainer with checkpointless auto-resume
trainer = pl.Trainer(
strategy=CheckpointlessMegatronStrategy(),
resume=CheckpointlessAutoResume()
)
```
**Note**
+ La AutoResume classe NeMo di Extends con meccanismo di ritardo per consentire il ripristino senza checkpoint
+ Funziona in combinazione con `CheckpointlessCompatibleConnector` per un flusso di lavoro di ripristino completo
# Considerazioni speciali
Raccogliamo determinate metriche operative aggregate e anonime di routine per fornire la disponibilità essenziale del servizio. La creazione di queste metriche è completamente automatizzata e non prevede la revisione umana del carico di lavoro di formazione del modello sottostante. Queste metriche riguardano le operazioni lavorative, la gestione delle risorse e le funzionalità essenziali dei servizi.
HyperPod checkpoint gestito su più livelli e formazione elastica: tieni presente che la formazione HyperPod senza checkpoint è attualmente incompatibile con HyperPod il checkpointing gestito a più livelli e l'allenamento elastico.
Per semplificare l'avvio, vengono fornite ricette di formazione senza checkpointless per i modelli GPT OSS 120B e Llama. Queste ricette sono state verificate su istanze ml.p5. L'utilizzo di altri tipi di istanze può richiedere ulteriori modifiche alle ricette sottostanti. Queste ricette possono essere adattate anche a flussi di lavoro di ottimizzazione completi. [Per i modelli personalizzati, ti consigliamo di consultare gli esempi introduttivi.](https://docs.aws.amazon.com/sagemaker-eks-checkpointless-recipes-custom)
# Appendice
**Monitora i risultati dell'allenamento tramite HyperPod ricette**
SageMaker HyperPod le ricette offrono l'integrazione con Tensorboard per analizzare il comportamento di allenamento. Queste ricette includono VizTracer anche uno strumento a basso costo per tracciare e visualizzare l'esecuzione del codice Python. Per ulteriori informazioni, consulta [ VizTracer](https://github.com/gaogaotiantian/viztracer).
I log di tensorboard vengono generati e archiviati all'interno di. `log_dir` Per accedere ai log e analizzarli in locale, procedi come indicato di seguito:
1. Scarica la cartella degli esperimenti TensorBoard dal tuo ambiente di addestramento al computer locale.
1. Apri un prompt del terminale o di comando sul tuo computer locale.
1. Passa alla directory che contiene la cartella degli esperimenti scaricata.
1. Avvia Tensorboard eseguendo il comando:
```
tensorboard --port= --bind_all --logdir experiment.
```
1. Apri il tuo browser web e visita. `http://localhost:8008`
Ora puoi vedere lo stato e le visualizzazioni dei tuoi job di addestramento all’interno dell’interfaccia TensorBoard. L’accesso allo stato e alle visualizzazioni consente di monitorare e analizzare il processo di addestramento. Il monitoraggio e l’analisi del processo di addestramento consentono di ottenere informazioni approfondite sul comportamento e sulle prestazioni dei modelli. Per ulteriori informazioni su come monitorare e analizzare l'allenamento con Tensorboard, consulta la Guida per l'utente di [NVIDIA Framework NeMo ](https://docs.nvidia.com/nemo-framework/user-guide/latest/nemotoolkit/core/exp_manager.html#experiment-manager).
**VizTracer**
Per abilitarlo VizTracer, puoi modificare la tua ricetta impostando la variabile di ambiente su. `ENABLE_VIZTRACER` `1` Una volta completata la formazione, il tuo VizTracer profilo si trova nella cartella dell'esperimento`log_dir/viztracer_xxx.json`. Per analizzare il tuo profilo, puoi scaricarlo e aprirlo utilizzando lo **vizviewer** strumento:
```
vizviewer --port viztracer_xxx.json
```
Questo comando avvia vizviewer sulla porta 9001. Puoi visualizzarlo VizTracer andando su http://localhost: nel tuo browser. Dopo l'apertura VizTracer, iniziate ad analizzare il training. Per ulteriori informazioni sull'utilizzo VizTracer, consultate [ VizTracer la documentazione](https://viztracer.readthedocs.io/en/latest/installation.html).
# Note di rilascio
Consulta le seguenti note di rilascio per tenere traccia degli ultimi aggiornamenti per la formazione SageMaker HyperPod senza checkpoint.
**La formazione senza SageMaker HyperPod checkpointless v1.0.0**
Data: 03 dicembre 2025
**SageMaker HyperPod funzionalità di allenamento senza checkpointless**
+ **Miglioramenti all'inizializzazione della comunicazione collettiva**: offre nuovi metodi di inizializzazione, Rootless e per NCCL e Gloo. TCPStoreless
+ Dataloader **con mappatura in memoria (MMAP): memorizza** nella cache (persistono) i batch precaricati in modo che siano disponibili anche quando un errore causa il riavvio del processo di formazione.
+ **Checkpointless**: consente un ripristino più rapido dagli errori di training dei cluster in ambienti di formazione distribuiti su larga scala apportando ottimizzazioni a livello di framework
+ **Basato su Nvidia Nemo e PyTorch Lightning: sfrutta questi potenti framework per una formazione dei modelli efficiente e flessibile**
+ [Nividia NeMo](https://github.com/NVIDIA-NeMo/NeMo)
+ [PyTorch Fulmine](https://lightning.ai/docs/pytorch/stable/)
**SageMaker HyperPod Contenitore Docker di formazione Checkpointless**
[Checkpointless training on HyperPod si basa sul framework NVIDIA. NeMo ](https://docs.nvidia.com/nemo-framework/user-guide/latest/overview.html) HyperPod checkpointless training mira a recuperare più rapidamente gli errori di formazione su cluster in ambienti di formazione distribuiti su larga scala effettuando ottimizzazioni a livello di framework che verranno fornite su un contenitore di base contenente l'immagine di base con NCCL e ottimizzazioni. PyTorch
**Disponibilità**
Attualmente le immagini sono disponibili solo in:
```
eu-north-1
ap-south-1
us-east-2
eu-west-1
eu-central-1
sa-east-1
us-east-1
eu-west-2
ap-northeast-1
us-west-2
us-west-1
ap-southeast-1
ap-southeast-2
```
ma non disponibile nelle seguenti 3 regioni opzionali:
```
ap-southeast-3
ap-southeast-4
eu-south-2
```
**Dettagli container**
Contenitore Docker di formazione Checkpointless per PyTorch la versione 2.6.0 con CUDA v12.9
```
963403601044.dkr.ecr.eu-north-1.amazonaws.com/hyperpod-checkpointless-training:v1.0.0
423350936952.dkr.ecr.ap-south-1.amazonaws.com/hyperpod-checkpointless-training:v1.0.0
556809692997.dkr.ecr.us-east-2.amazonaws.com/hyperpod-checkpointless-training:v1.0.0
942446708630.dkr.ecr.eu-west-1.amazonaws.com/hyperpod-checkpointless-training:v1.0.0
391061375763.dkr.ecr.eu-central-1.amazonaws.com/hyperpod-checkpointless-training:v1.0.0
311136344257.dkr.ecr.sa-east-1.amazonaws.com/hyperpod-checkpointless-training:v1.0.0
327873000638.dkr.ecr.us-east-1.amazonaws.com/hyperpod-checkpointless-training:v1.0.0
016839105697.dkr.ecr.eu-west-2.amazonaws.com/hyperpod-checkpointless-training:v1.0.0
356859066553.dkr.ecr.ap-northeast-1.amazonaws.com/hyperpod-checkpointless-training:v1.0.0
920498770698.dkr.ecr.us-west-2.amazonaws.com/hyperpod-checkpointless-training:v1.0.0
827510180725.dkr.ecr.us-west-1.amazonaws.com/hyperpod-checkpointless-training:v1.0.0
885852567298.dkr.ecr.ap-southeast-1.amazonaws.com/hyperpod-checkpointless-training:v1.0.0
304708117039.dkr.ecr.ap-southeast-2.amazonaws.com/hyperpod-checkpointless-training:v1.0.0
```
**Pacchetti preinstallati**
```
PyTorch: v2.6.0
CUDA: v12.9
NCCL: v2.27.5
EFA: v1.43.0
AWS-OFI-NCCL v1.16.0
Libfabric version 2.1
Megatron v0.15.0
Nemo v2.6.0rc0
```
# Utilizzo delle partizioni GPU in Amazon SageMaker HyperPod
Gli amministratori dei cluster possono scegliere come massimizzare l'utilizzo della GPU all'interno dell'organizzazione. Puoi abilitare il partizionamento della GPU con la tecnologia NVIDIA Multi-Instance GPU (MIG) per partizionare le risorse GPU in istanze più piccole e isolate per un migliore utilizzo delle risorse. Questa funzionalità offre la possibilità di eseguire più attività di piccole dimensioni contemporaneamente su una singola GPU anziché dedicare l'intero hardware a una singola attività, spesso sottoutilizzata. Ciò elimina lo spreco di potenza di elaborazione e memoria.
Il partizionamento GPU con tecnologia MIG supporta GPUs e consente di partizionare una singola GPU supportata in un massimo di sette partizioni GPU separate. Ogni partizione GPU dispone di risorse di memoria, cache e calcolo dedicate, che garantiscono un isolamento prevedibile.
## Vantaggi
+ **Utilizzo migliorato della GPU**: massimizza l'efficienza di elaborazione mediante il partizionamento in base ai requisiti di elaborazione e memoria GPUs
+ **Isolamento delle attività**: ogni partizione GPU funziona in modo indipendente con risorse di memoria, cache e calcolo dedicate
+ **Flessibilità delle attività**: supporta una combinazione di attività su un'unica GPU fisica, tutte in esecuzione in parallelo
+ **Gestione flessibile della configurazione**: supporta sia le configurazioni Kubernetes Do-it-yourself (fai-da-te) utilizzando il client a riga di comando Kubernetes`kubectl`, sia una soluzione gestita con etichette personalizzate per configurare e applicare facilmente le etichette associate alle partizioni GPU
## Tipi di istanze supportati
Il partizionamento GPU con tecnologia MIG è supportato sui seguenti tipi di istanze: HyperPod
[Istanze GPU A100 - **instance-types/p4/** https://aws.amazon.com/ec2/](https://aws.amazon.com/ec2/instance-types/p4/)
+ ml.p4d.24xlarge - 8 schede NVIDIA **A100** (80 GB per GPU) GPUs HBM2e
+ **ml.p4de.24xlarge** - 8 schede NVIDIA A100 GPUs (80 GB HBM2e per GPU)
**Istanze GPU [https://aws.amazon.com/ec2/H100](https://aws.amazon.com/ec2/instance-types/p5/) - instance-types/p5/**
+ ml.p5.48xlarge - 8 NVIDIA **H100** (80 GB per GPU) GPUs HBM3
**Istanze GPU [https://aws.amazon.com/ec2/H200 - instance-types/p5/](https://aws.amazon.com/ec2/instance-types/p5/)**
+ ml.p5e.48xlarge - 8 schede NVIDIA **H200** (141 GB per GPU) GPUs HBM3e
+ **ml.p5en.48xlarge** - 8 schede NVIDIA H200 GPUs (141 GB HBM3e per GPU)
**Istanze GPU [https://aws.amazon.com/ec2/B200](https://aws.amazon.com/ec2/instance-types/p6/) - instance-types/p6/**
+ **ml.p6b.48xlarge - 8 schede NVIDIA B200** GPUs
## partizioni GPU
I profili NVIDIA MIG definiscono il modo in cui vengono partizionati. GPUs Ogni profilo specifica l'allocazione di calcolo e memoria per istanza MIG. Di seguito sono riportati i profili MIG associati a ciascun tipo di GPU:
**GPU A100 (ml.p4d.24xlarge)**
| Profilo | Memoria (GB) | Istanze per GPU | Totale per ml.p4d.24xlarge |
| --- | --- | --- | --- |
| `1g.5gb` | 5 | 7 | 56 |
| `2g.10gb` | 10 | 3 | 24 |
| `3g.20gb` | 20 | 2 | 16 |
| `4g.20gb` | 20 | 1 | 8 |
| `7g.40gb` | 40 | 1 | 8 |
**GPU H100 (ml.p5.48xlarge)**
| Profilo | Memoria (GB) | Istanze per GPU | Totale per ml.p5,48xlarge |
| --- | --- | --- | --- |
| `1g.10gb` | 10 | 7 | 56 |
| `1g.20gb` | 20 | 4 | 32 |
| `2g.20gb` | 20 | 3 | 24 |
| `3g.40gb` | 40 | 2 | 16 |
| `4g.40gb` | 40 | 1 | 8 |
| `7g.80gb` | 80 | 1 | 8 |
**GPU H200 (ml.p5e.48xlarge e ml.p5en.48xlarge)**
| Profilo | Memoria (GB) | Istanze per GPU | Totale per ml.p5en.48xlarge |
| --- | --- | --- | --- |
| `1g.18gb` | 18 | 7 | 56 |
| `1g.35gb` | 35 | 4 | 32 |
| `2g.35gb` | 35 | 3 | 24 |
| `3g.71gb` | 71 | 2 | 16 |
| `4g.71gb` | 71 | 1 | 8 |
| `7g.141gb` | 141 | 1 | 8 |
**Topics**
+ [Vantaggi](#sagemaker-hyperpod-eks-gpu-partitioning-benefits)
+ [Tipi di istanze supportati](#sagemaker-hyperpod-eks-gpu-partitioning-instance-types)
+ [partizioni GPU](#sagemaker-hyperpod-eks-gpu-partitioning-profiles)
+ [Configurazione di partizioni GPU su Amazon SageMaker HyperPod](sagemaker-hyperpod-eks-gpu-partitioning-setup.md)
+ [Ciclo di vita dei nodi ed etichette](sagemaker-hyperpod-eks-gpu-partitioning-labels.md)
+ [Invio di attività con MIG](sagemaker-hyperpod-eks-gpu-partitioning-task-submission.md)
# Configurazione di partizioni GPU su Amazon SageMaker HyperPod
**Topics**
+ [Prerequisiti](#sagemaker-hyperpod-eks-gpu-partitioning-setup-prerequisites)
+ [Creazione di un cluster con configurazione MIG](#sagemaker-hyperpod-eks-gpu-partitioning-setup-create-cluster)
+ [Aggiungere un operatore GPU a un cluster esistente](#sagemaker-hyperpod-eks-gpu-partitioning-setup-add-operator)
+ [Aggiornamento della configurazione MIG](#sagemaker-hyperpod-eks-gpu-partitioning-setup-update)
+ [Verifica della configurazione MIG](#sagemaker-hyperpod-eks-gpu-partitioning-setup-verify)
+ [Comandi comuni per il debug della configurazione MIG](#sagemaker-hyperpod-eks-gpu-partitioning-setup-debug-commands)
+ [Utilizzo della console SageMaker AI](#sagemaker-hyperpod-eks-gpu-partitioning-setup-console)
## Prerequisiti
+ HyperPod Cluster Amazon EKS con istanze GPU supportate
+ NVIDIA GPU Operator installato
+ Autorizzazioni IAM appropriate per la gestione dei cluster
## Creazione di un cluster con configurazione MIG
### Usando AWS CLI
```
aws sagemaker create-cluster \
--cluster-name my-mig-cluster \
--orchestrator 'Eks={ClusterArn=arn:aws:eks:region:account:cluster/cluster-name}' \
--instance-groups '{
"InstanceGroupName": "gpu-group",
"InstanceType": "ml.p4d.24xlarge",
"InstanceCount": 1,
"LifeCycleConfig": {
"SourceS3Uri": "s3://my-bucket",
"OnCreate": "on_create_script.sh"
},
"KubernetesConfig": {
"Labels": {
"nvidia.com/mig.config": "all-1g.5gb"
}
},
"ExecutionRole": "arn:aws:iam::account:role/execution-role",
"ThreadsPerCore": 1
}' \
--vpc-config '{
"SecurityGroupIds": ["sg-12345"],
"Subnets": ["subnet-12345"]
}' \
--node-provisioning-mode Continuous
```
### Usando CloudFormation
```
{
"ClusterName": "my-mig-cluster",
"InstanceGroups": [
{
"InstanceGroupName": "gpu-group",
"InstanceType": "ml.p4d.24xlarge",
"InstanceCount": 1,
"KubernetesConfig": {
"Labels": {
"nvidia.com/mig.config": "all-2g.10gb"
}
},
"ExecutionRole": "arn:aws:iam::account:role/execution-role"
}
],
"Orchestrator": {
"Eks": {
"ClusterArn": "arn:aws:eks:region:account:cluster/cluster-name"
}
},
"NodeProvisioningMode": "Continuous"
}
```
## Aggiungere un operatore GPU a un cluster esistente
### Installa GPU Operator
Sostituisci `{$AWS_REGION}` con la regione del tuo cluster (ad es. us-east-1, us-west-2).
```
helm install gpuo helm_chart/HyperPodHelmChart/charts/gpu-operator \
-f helm_chart/HyperPodHelmChart/charts/gpu-operator/regional-values/values-{$AWS_REGION}.yaml \
-n kube-system
```
### Verifica l'installazione (attendi 2-3 minuti)
Verifica che tutti i pod dell'operatore della GPU siano in funzione:
```
kubectl get pods -n kube-system | grep -E "(gpu-operator|nvidia-)"
```
**Pod previsti:**
+ gpu-operator-\$1 - 1 istanza (controller del cluster)
+ nvidia-device-plugin-daemonset-\$1 - 1 per nodo GPU (tutte le istanze GPU)
+ nvidia-mig-manager-\$1 - 1 per nodo compatibile con MiG (A100/H100)
### Rimuovi il vecchio plug-in del dispositivo
Disabilita l'esistente nvidia-device-plugin:
```
helm upgrade dependencies helm_chart/HyperPodHelmChart \
--set nvidia-device-plugin.devicePlugin.enabled=false \
-n kube-system
```
### Verifica le risorse della GPU
Conferma che i nodi mostrino la capacità della GPU. Dovrebbe mostrare: nvidia.com/gpu: 8 (o il numero effettivo di GPU).
```
kubectl describe nodes | grep "nvidia.com/gpu"
```
## Aggiornamento della configurazione MIG
**Preparazione dei nodi prima degli aggiornamenti MIG**
Prima di aggiornare le configurazioni MIG sul gruppo di istanze, è necessario preparare i nodi per evitare interruzioni del carico di lavoro. Segui questi passaggi per drenare in sicurezza i carichi di lavoro dai nodi che verranno riconfigurati.
### Fase 1: Identifica i nodi nel gruppo di istanze
Innanzitutto, identifica tutti i nodi che appartengono al gruppo di istanze che desideri aggiornare:
```
# List all nodes in the instance group
kubectl get nodes -l sagemaker.amazonaws.com/instance-group-name=INSTANCE_GROUP_NAME
# Example:
kubectl get nodes -l sagemaker.amazonaws.com/instance-group-name=p4d-group
```
Questo comando restituisce un elenco di tutti i nodi nel gruppo di istanze specificato. Prendi nota del nome di ogni nodo per i seguenti passaggi.
### Fase 2: cordonare e drenare ogni nodo
Per ogni nodo identificato nel passaggio 1, esegui le seguenti azioni:
#### Cordone il nodo
Il cordonamento impedisce la pianificazione di nuovi pod sul nodo:
```
# Cordon a single node
kubectl cordon NODE_NAME
# Example:
kubectl cordon hyperpod-i-014a41a7001adca60
```
#### Svuota i Workload Pods dal nodo
Svuota il nodo per eliminare tutti i pod del carico di lavoro preservando al contempo i pod di sistema:
```
# Drain the node (ignore DaemonSets and evict pods)
kubectl drain NODE_NAME \
--ignore-daemonsets \
--delete-emptydir-data \
--force \
--grace-period=300
# Example:
kubectl drain hyperpod-i-014a41a7001adca60 \
--ignore-daemonsets \
--delete-emptydir-data \
--force \
--grace-period=300
```
**Spiegazione delle opzioni di comando:**
+ `--ignore-daemonsets`- Consente di continuare l'operazione di scarico anche in presenza di DaemonSet cialde
+ `--delete-emptydir-data`- Elimina i pod utilizzando i volumi EmptyDir (necessario per il corretto drenaggio)
+ `--force`- Forza l'eliminazione dei pod non gestiti da un controller (usare con cautela)
+ `--grace-period=300`- Dà ai pod 5 minuti per terminare correttamente
**Importante**
L'operazione di scarico può richiedere diversi minuti a seconda del numero di pod e dei relativi periodi di tolleranza
I pod di sistema nei seguenti namespace rimarranno in esecuzione:`kube-system`,,,,`cert-manager`,`kubeflow`,`hyperpod-inference-system`,, `kube-public``mpi-operator`, e `gpu-operator` `aws-hyperpod` `jupyter-k8s-system` `hyperpod-observability` `kueue-system` `keda`
DaemonSet i pod rimarranno sul nodo (vengono ignorati in base alla progettazione)
### Passaggio 3: verifica che i pod del carico di lavoro non siano in esecuzione
Dopo il drenaggio, verifica che nessun pod del carico di lavoro rimanga sui nodi (esclusi i namespace di sistema):
```
# Check for any remaining pods outside system namespaces
kubectl get pods --all-namespaces --field-selector spec.nodeName=NODE_NAME \
| grep -v "kube-system" \
| grep -v "cert-manager" \
| grep -v "kubeflow" \
| grep -v "hyperpod-inference-system" \
| grep -v "kube-public" \
| grep -v "mpi-operator" \
| grep -v "gpu-operator" \
| grep -v "aws-hyperpod" \
| grep -v "jupyter-k8s-system" \
| grep -v "hyperpod-observability" \
| grep -v "kueue-system" \
| grep -v "keda"
# Example:
kubectl get pods --all-namespaces --field-selector spec.nodeName=hyperpod-i-014a41a7001adca60 \
| grep -v "kube-system" \
| grep -v "cert-manager" \
| grep -v "kubeflow" \
| grep -v "hyperpod-inference-system" \
| grep -v "kube-public" \
| grep -v "mpi-operator" \
| grep -v "gpu-operator" \
| grep -v "aws-hyperpod" \
| grep -v "jupyter-k8s-system" \
| grep -v "hyperpod-observability" \
| grep -v "kueue-system" \
| grep -v "keda"
```
**Output previsto:** se il nodo è drenato correttamente, questo comando non dovrebbe restituire alcun risultato (o mostrare solo la riga di intestazione). Se alcuni pod sono ancora in funzione, scoprite perché non sono stati rimossi ed eliminateli manualmente, se necessario.
### Fase 4: Verifica dello stato di preparazione del nodo
Prima di procedere con l'aggiornamento MIG, verificate che tutti i nodi siano isolati:
```
# Check node status - should show "SchedulingDisabled"
kubectl get nodes -l sagemaker.amazonaws.com/instance-group-name=INSTANCE_GROUP_NAME
```
I nodi devono essere visualizzati `SchedulingDisabled` nella colonna STATUS, a indicare che sono isolati e pronti per l'aggiornamento MIG.
### Aggiorna il profilo MIG sul cluster esistente
È possibile modificare i profili MIG sui cluster esistenti:
```
aws sagemaker update-cluster \
--cluster-name my-mig-cluster \
--instance-groups '{
"InstanceGroupName": "gpu-group",
"InstanceType": "ml.p4d.24xlarge",
"InstanceCount": 1,
"KubernetesConfig": {
"Labels": {
"nvidia.com/mig.config": "all-3g.20gb"
}
},
"ExecutionRole": "arn:aws:iam::account:role/execution-role"
}'
```
**Nota**
Se i lavori sono già in esecuzione su un nodo, il partizionamento MIG avrà esito negativo. L'utente riceverà un messaggio di errore per svuotare i nodi prima di tentare nuovamente il partizionamento MIG.
## Verifica della configurazione MIG
Dopo la creazione o l'aggiornamento del cluster, verifica la configurazione MIG:
```
# Update kubeconfig
aws eks update-kubeconfig --name your-eks-cluster --region us-east-2
# Check MIG labels
kubectl get node NODE_NAME -o=jsonpath='{.metadata.labels}' | grep mig
# Check available MIG resources
kubectl describe node NODE_NAME | grep -A 10 "Allocatable:"
```
## Comandi comuni per il debug della configurazione MIG
Utilizzate i seguenti comandi per risolvere i problemi e convalidare la configurazione MIG nel cluster:
```
# Check GPU Operator status
kubectl get pods -n gpu-operator-resources
# View MIG configuration
kubectl exec -n gpu-operator-resources nvidia-driver-XXXXX -- nvidia-smi mig -lgi
# Check device plugin configuration
kubectl logs -n gpu-operator-resources nvidia-device-plugin-XXXXX
# Monitor node events
kubectl get events --field-selector involvedObject.name=NODE_NAME
```
**Nota**
Sostituisci `nvidia-driver-XXXXX` e `nvidia-device-plugin-XXXXX` con i nomi effettivi dei pod del cluster e `NODE_NAME` con il nome del nodo.
## Utilizzo della console SageMaker AI
### Creazione di un nuovo cluster con MIG
1. Passa ad **Amazon SageMaker AI** > **HyperPod Clusters** > **Gestione dei cluster** > **Crea HyperPod ** cluster
1. Seleziona **Orchestrated by EKS**
1. Scegli **Configurazione personalizzata** e verifica che **GPU Operator** sia abilitato per impostazione predefinita
1. Nella sezione **Gruppi di istanze**, fai clic su **Aggiungi** gruppo
1. Configura il gruppo di istanze e vai a **Configurazione avanzata** per attivare **l'opzione Usa partizione GPU** e scegli la configurazione **MIG** desiderata dal menu a discesa
1. Fai clic su **Aggiungi gruppo di istanze** e completa la configurazione del cluster rimanente
1. Fai clic su **Invia** per creare il cluster
### Aggiornamento della configurazione MIG su un cluster esistente
1. Passa ad **Amazon SageMaker AI** > **HyperPod Clusters > Gestione dei** **cluster**
1. Seleziona il cluster esistente e fai clic su **Modifica** sul gruppo di istanze che desideri modificare
1. In **Configurazione avanzata**, attiva **Usa la partizione GPU** se non è già abilitata e seleziona una configurazione **MIG** diversa dal menu a discesa
1. **Fai clic su Salva modifiche**
# Ciclo di vita dei nodi ed etichette
Amazon SageMaker HyperPod esegue controlli approfonditi sullo stato delle istanze del cluster durante la creazione e l'aggiornamento dei HyperPod cluster prima che inizi il partizionamento della GPU. HyperPod l'agente di monitoraggio dello stato di salute monitora continuamente lo stato di salute delle istanze partizionate con GPU.
## Stati di configurazione MIG
I nodi con configurazione delle partizioni GPU attraversano diversi stati:
+ **In sospeso: il** nodo viene configurato con un profilo MIG
+ **Configurazione: l'**operatore GPU sta applicando il partizionamento MIG
+ Operazione **riuscita**: il partizionamento della GPU è stato completato correttamente
+ **Fallito**: il partizionamento della GPU ha rilevato un errore
## Monitoraggio degli stati dei nodi
```
# Check node health status
kubectl get nodes -l sagemaker.amazonaws.com/node-health-status=Schedulable
# Monitor MIG configuration progress
kubectl get node NODE_NAME -o jsonpath='{.metadata.labels.nvidia\.com/mig\.config\.state}'
# Check for configuration errors
kubectl describe node NODE_NAME | grep -A 5 "Conditions:"
```
## Etichette e segni personalizzati
Puoi gestire la configurazione MIG con etichette e colori personalizzati per etichettare le partizioni GPU e applicarle a tutte le istanze:
```
{
"KubernetesConfig": {
"Labels": {
"nvidia.com/mig.config": "all-2g.10gb",
"task-type": "inference",
"environment": "production"
},
"Taints": [
{
"Key": "gpu-task",
"Value": "mig-enabled",
"Effect": "NoSchedule"
}
]
}
}
```
# Invio di attività con MIG
**Topics**
+ [Utilizzo di Kubernetes YAML](#sagemaker-hyperpod-eks-gpu-partitioning-task-submission-kubectl)
+ [Utilizzo della HyperPod CLI](#sagemaker-hyperpod-eks-gpu-partitioning-task-submission-cli)
+ [Distribuzione del modello con MIG](#sagemaker-hyperpod-eks-gpu-partitioning-task-submission-deployment)
+ [Utilizzo della HyperPod CLI](#sagemaker-hyperpod-eks-gpu-partitioning-task-submission-hyperpod-cli)
## Utilizzo di Kubernetes YAML
```
apiVersion: batch/v1
kind: Job
metadata:
name: mig-job
namespace: default
spec:
template:
spec:
containers:
- name: pytorch
image: pytorch/pytorch:latest
resources:
requests:
nvidia.com/mig-1g.5gb: 1
cpu: "100m"
memory: "128Mi"
limits:
nvidia.com/mig-1g.5gb: 1
restartPolicy: Never
```
## Utilizzo della HyperPod CLI
Utilizza la HyperPod CLI per distribuire JumpStart modelli con supporto MIG. L'esempio seguente illustra i nuovi parametri CLI per il partizionamento della GPU:
```
# Deploy JumpStart model with MIG
hyp create hyp-jumpstart-endpoint \
--model-id deepseek-llm-r1-distill-qwen-1-5b \
--instance-type ml.p5.48xlarge \
--accelerator-partition-type mig-2g.10gb \
--accelerator-partition-validation True \
--endpoint-name my-endpoint \
--tls-certificate-output-s3-uri s3://certificate-bucket/ \
--namespace default
```
## Distribuzione del modello con MIG
HyperPod L'inferenza consente di implementare i modelli sui profili MIG tramite Studio Classic e `kubectl` CLI. HyperPod Per distribuire JumpStart i modelli`kubectl`, richiama CRDs i campi `spec.server.acceleratorPartitionType` per distribuire il modello sul profilo MIG desiderato. Eseguiamo convalide per garantire che i modelli possano essere implementati sul profilo MIG selezionato nel CRD. Nel caso in cui desideri disabilitare i controlli di convalida MIG, usa to. `spec.server.validations.acceleratorPartitionValidation` `False`
### JumpStart Modelli
```
apiVersion: inference.sagemaker.aws.amazon.com/v1
kind: JumpStartModel
metadata:
name: deepseek-model
namespace: default
spec:
sageMakerEndpoint:
name: deepseek-endpoint
model:
modelHubName: SageMakerPublicHub
modelId: deepseek-llm-r1-distill-qwen-1-5b
server:
acceleratorPartitionType: mig-7g.40gb
instanceType: ml.p4d.24xlarge
```
### Distribuisci il modello da Amazon S3 utilizzando InferenceEndpointConfig
InferenceEndpointConfig consente di distribuire un modello personalizzato da Amazon S3. Per implementare un modello su MIG, `spec.worker.resources` menziona il profilo MIG in and. `requests` `limits` Fai riferimento a una semplice implementazione di seguito:
```
apiVersion: inference.sagemaker.aws.amazon.com/v1
kind: InferenceEndpointConfig
metadata:
name: custom-model
namespace: default
spec:
replicas: 1
modelName: my-model
endpointName: my-endpoint
instanceType: ml.p4d.24xlarge
modelSourceConfig:
modelSourceType: s3
s3Storage:
bucketName: my-model-bucket
region: us-east-2
modelLocation: model-path
worker:
resources:
requests:
nvidia.com/mig-3g.20gb: 1
cpu: "5600m"
memory: "10Gi"
limits:
nvidia.com/mig-3g.20gb: 1
```
### Implementa il modello di FSx for Lustre utilizzando InferenceEndpointConfig
InferenceEndpointConfig consente di implementare un modello personalizzato di For Lustre. FSx Per implementare un modello su MIG, `spec.worker.resources` menziona il profilo MIG in and. `requests` `limits` Fai riferimento a una semplice implementazione di seguito:
```
apiVersion: inference.sagemaker.aws.amazon.com/v1
kind: InferenceEndpointConfig
metadata:
name: custom-model
namespace: default
spec:
replicas: 1
modelName: my-model
endpointName: my-endpoint
instanceType: ml.p4d.24xlarge
modelSourceConfig:
modelSourceType: fsx
fsxStorage:
fileSystemId: fs-xxxxx
modelLocation: location-on-fsx
worker:
resources:
requests:
nvidia.com/mig-3g.20gb: 1
cpu: "5600m"
memory: "10Gi"
limits:
nvidia.com/mig-3g.20gb: 1
```
### Utilizzo dell'interfaccia utente di Studio Classic
#### Distribuzione di JumpStart modelli con MIG
1. Apri **Studio Classic e vai** a **JumpStart**
1. Sfoglia o cerca il modello desiderato (ad es. "DeepSeek«, «Llama», ecc.)
1. **Fai clic sulla scheda del modello e seleziona Deploy**
1. Nella configurazione di distribuzione:
+ Scegli **HyperPod**come obiettivo di distribuzione
+ Seleziona il tuo cluster abilitato per MiG dal menu a discesa
+ **In Configurazione dell'istanza:**
+ Seleziona il tipo di istanza (ad esempio,`ml.p4d.24xlarge`)
+ Scegli il **tipo di partizione GPU** tra le opzioni disponibili
+ **Configura il **conteggio delle istanze e le** impostazioni di ridimensionamento automatico**
1. **Rivedi e fai clic su Distribuisci**
1. Monitora l'avanzamento della distribuzione nella sezione **Endpoints**
#### Opzioni di configurazione del modello
**Impostazioni dell'endpoint:**
+ **Nome dell'endpoint**: identificatore univoco per la distribuzione
+ **Nome variante** - Variante di configurazione (impostazione predefinita:) AllTraffic
+ **Tipo di istanza**: deve supportare la partizione GPU (serie p)
+ **Profilo MIG - partizione GPU**
+ Numero **iniziale di istanze: numero** di istanze da distribuire
+ **Scalabilità automatica: abilita la scalabilità** dinamica in base al traffico
**Configurazione avanzata:**
+ **Posizione dei dati del modello**: percorso Amazon S3 per modelli personalizzati
+ **Immagine del contenitore**: contenitore di inferenza personalizzato (opzionale)
+ **Variabili di ambiente: configurazioni** specifiche del modello
+ **Configurazione Amazon VPC: impostazioni di** isolamento della rete
#### Monitoraggio dei modelli implementati
1. **Passa a **Studio Classic** > **Distribuzioni > Endpoint****
1. Seleziona il tuo endpoint abilitato per MiG
1. Visualizza metriche tra cui:
+ Utilizzo **MIG: utilizzo** per partizione GPU
+ **Consumo di memoria**: per partizione GPU
+ **Latenza di inferenza: tempo di elaborazione della** richiesta
+ **Throughput: richieste** al secondo
1. Configura gli ** CloudWatch allarmi Amazon** per il monitoraggio automatico
1. Configurazione di politiche **di auto-scaling basate sull'utilizzo di** MIG
## Utilizzo della HyperPod CLI
### JumpStart Distribuzione
Il JumpStart comando HyperPod CLI include due nuovi campi per il supporto MIG:
+ `--accelerator-partition-type`- Speciifica la configurazione MIG (ad esempio, mig-4g.20gb)
+ `--accelerator-partition-validation`- Convalida la compatibilità tra i modelli e il profilo MIG (default: true)
```
hyp create hyp-jumpstart-endpoint \
--version 1.1 \
--model-id deepseek-llm-r1-distill-qwen-1-5b \
--instance-type ml.p4d.24xlarge \
--endpoint-name js-test \
--accelerator-partition-type "mig-4g.20gb" \
--accelerator-partition-validation true \
--tls-certificate-output-s3-uri s3://my-bucket/certs/
```
### Distribuzione personalizzata degli endpoint
Per la distribuzione tramite endpoint personalizzato, utilizza i campi esistenti `--resources-requests` e abilita la funzionalità del `--resources-limits` profilo MIG:
```
hyp create hyp-custom-endpoint \
--namespace default \
--metadata-name deepseek15b-mig-10-14-v2 \
--endpoint-name deepseek15b-mig-endpoint \
--instance-type ml.p4d.24xlarge \
--model-name deepseek15b-mig \
--model-source-type s3 \
--model-location deep-seek-15b \
--prefetch-enabled true \
--tls-certificate-output-s3-uri s3://sagemaker-bucket \
--image-uri lmcache/vllm-openai:v0.3.7 \
--container-port 8080 \
--model-volume-mount-path /opt/ml/model \
--model-volume-mount-name model-weights \
--s3-bucket-name model-storage-123456789 \
--s3-region us-east-2 \
--invocation-endpoint invocations \
--resources-requests '{"cpu":"5600m","memory":"10Gi","nvidia.com/mig-3g.20gb":"1"}' \
--resources-limits '{"nvidia.com/mig-3g.20gb":"1"}' \
--env '{
"OPTION_ROLLING_BATCH":"vllm",
"SERVING_CHUNKED_READ_TIMEOUT":"480",
"DJL_OFFLINE":"true",
"NUM_SHARD":"1",
"SAGEMAKER_PROGRAM":"inference.py",
"SAGEMAKER_SUBMIT_DIRECTORY":"/opt/ml/model/code",
"MODEL_CACHE_ROOT":"/opt/ml/model",
"SAGEMAKER_MODEL_SERVER_WORKERS":"1",
"SAGEMAKER_MODEL_SERVER_TIMEOUT":"3600",
"OPTION_TRUST_REMOTE_CODE":"true",
"OPTION_ENABLE_REASONING":"true",
"OPTION_REASONING_PARSER":"deepseek_r1",
"SAGEMAKER_CONTAINER_LOG_LEVEL":"20",
"SAGEMAKER_ENV":"1"
}'
```
# Funzionalità di resilienza del SageMaker HyperPod cluster per l'orchestrazione dei cluster con Amazon EKS
SageMaker HyperPod fornisce le seguenti funzionalità di resilienza del cluster.
**Topics**
+ [Sistema di monitoraggio della salute](sagemaker-hyperpod-eks-resiliency-health-monitoring-agent.md)
+ [Controlli dell’integrità di base](sagemaker-hyperpod-eks-resiliency-basic-health-check.md)
+ [Controlli dell’integrità approfonditi](sagemaker-hyperpod-eks-resiliency-deep-health-checks.md)
+ [Ripristino automatico del nodo](sagemaker-hyperpod-eks-resiliency-node-recovery.md)
+ [Etichette Kubernetes relative alla resilienza di SageMaker HyperPod](sagemaker-hyperpod-eks-resiliency-node-labels.md)
+ [Quarantena, sostituzione o riavvio manuale di un nodo](sagemaker-hyperpod-eks-resiliency-manual.md)
+ [Configurazioni di resilienza consigliate](sagemaker-hyperpod-eks-resiliency-config-tips.md)
# Sistema di monitoraggio della salute
SageMaker HyperPod il sistema di monitoraggio dello stato di salute include due componenti
1. Agenti di monitoraggio installati nei nodi, tra cui l'Health Monitoring Agent (HMA) che funge da monitoraggio dello stato dell'host e un set di monitor dello out-of-node stato.
1. Node Recovery System gestito da. SageMaker HyperPod Il sistema di monitoraggio dell'integrità monitorerà continuamente lo stato di salute del nodo tramite agenti di monitoraggio e quindi agirà automaticamente quando viene rilevato un guasto utilizzando il Node Recovery System.
![\[Questa immagine illustra come il sistema di monitoraggio della salute si sia integrato con HyperPod Cluster.\]](http://docs.aws.amazon.com/it_it/sagemaker/latest/dg/images/hyperpod/hyperpod-resilience-event.png)
## Controlli sanitari effettuati dall'agente di SageMaker HyperPod monitoraggio sanitario
L'agente di SageMaker HyperPod monitoraggio sanitario verifica quanto segue.
**NVIDIA GPUs**
+ [Notifiche di violazione delle policy DCGM](https://docs.nvidia.com/datacenter/dcgm/3.0/user-guide/feature-overview.html#notifications)
+ Errori nell’output `nvidia-smi`
+ Vari errori nei log generati dalla piattaforma Amazon Elastic Compute Cloud (EC2)
+ Convalida del conteggio GPU: se c'è una mancata corrispondenza tra il numero previsto di GPUs in un particolare tipo di istanza (ad esempio: 8 GPUs nel tipo di istanza ml.p5.48xlarge) e il conteggio restituito da, HMA riavvia il nodo `nvidia-smi`
**AWS Trainium**
+ Errori nell’output dal monitoraggio [AWS Neuron](https://awsdocs-neuron.readthedocs-hosted.com/en/latest/tools/neuron-sys-tools/neuron-monitor-user-guide.html)
+ Output generati dal rilevatore di problemi del nodo Neuron (per ulteriori informazioni sul rilevatore di problemi del nodo AWS Neuron, consulta [Rilevamento e ripristino dei problemi AWS dei nodi Neuron all'interno dei](https://aws.amazon.com/blogs/machine-learning/node-problem-detection-and-recovery-for-aws-neuron-nodes-within-amazon-eks-clusters/) cluster Amazon EKS).
+ Vari errori nei log generati dalla piattaforma Amazon EC2
+ Convalida del conteggio dei dispositivi Neuron: se c'è una discrepanza tra il numero effettivo di dispositivi neuronali in un particolare tipo di istanza e il conteggio restituito da, HMA riavvia il nodo `neuron-ls`
I controlli di cui sopra sono passivi, i controlli dello stato in background vengono eseguiti HyperPod continuamente sui nodi. Oltre a questi controlli, esegue HyperPod anche controlli di integrità approfonditi (o attivi) durante la creazione e l'aggiornamento dei HyperPod cluster. Scopri di più sui [controlli sanitari approfonditi](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-eks-resiliency-deep-health-checks.html).
## Rilevamento degli errori
Quando SageMaker HyperPod rileva un guasto, implementa una risposta in quattro parti:
1. **Etichette dei nodi**
1. Stato di salute: `sagemaker.amazonaws.com/node-health-status`
1. Tipo di errore: `sagemaker.amazonaws.com/fault-types` etichetta per la categorizzazione di alto livello
1. Motivo dell'errore: `sagemaker.amazonaws.com/fault-reasons` etichetta con informazioni dettagliate sull'errore
1. **Intossicazione del nodo**
1. `sagemaker.amazonaws.com/node-health-status=Unschedulable:NoSchedule`
1. **Annotazione del nodo**
1. Dettagli del guasto: `sagemaker.amazonaws.com/fault-details`
1. Registra fino a 20 errori con timestamp che si sono verificati sul nodo
1. **Condizioni del nodo (condizione** del nodo [Kubernetes](https://kubernetes.io/docs/reference/node/node-status/#condition))
1. Riflette lo stato di salute attuale nelle condizioni del nodo:
+ Tipo: uguale al tipo di errore
+ Stato: `True`
+ Motivo: uguale al motivo del guasto
+ LastTransitionTime: ora di insorgenza del guasto
![\[Questa immagine illustra come funziona il sistema di monitoraggio dello stato di salute quando viene rilevato un guasto.\]](http://docs.aws.amazon.com/it_it/sagemaker/latest/dg/images/hyperpod/hyperpod-resilience-workflow.png)
## Registri generati dall'agente di monitoraggio sanitario SageMaker HyperPod
L'agente di SageMaker HyperPod monitoraggio dello stato è una funzionalità di controllo dello out-of-the-box stato e viene eseguito continuamente su tutti i cluster. HyperPod L'agente di monitoraggio dello stato pubblica gli eventi sanitari rilevati su istanze GPU o Trn nel gruppo di log Cluster. CloudWatch `/aws/sagemaker/Clusters/`
I registri di rilevamento dell'agente di HyperPod monitoraggio dello stato vengono creati come flussi di registro separati denominati per ciascun nodo. `SagemakerHealthMonitoringAgent` È possibile interrogare i registri di rilevamento utilizzando CloudWatch log insights come segue.
```
fields @timestamp, @message
| filter @message like /HealthMonitoringAgentDetectionEvent/
```
Questo restituisce un output simile al seguente.
```
2024-08-21T11:35:35.532-07:00
{"level":"info","ts":"2024-08-21T18:35:35Z","msg":"NPD caught event: %v","details: ":{"severity":"warn","timestamp":"2024-08-22T20:59:29Z","reason":"XidHardwareFailure","message":"Node condition NvidiaErrorReboot is now: True, reason: XidHardwareFailure, message: \"NVRM: Xid (PCI:0000:b9:00): 71, pid=, name=, NVLink: fatal error detected on link 6(0x10000, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)\""},"HealthMonitoringAgentDetectionEvent":"HealthEvent"}
2024-08-21T11:35:35.532-07:00
{"level":"info","ts":"2024-08-21T18:35:35Z","msg":"NPD caught event: %v","details: ":{"severity":"warn","timestamp":"2024-08-22T20:59:29Z","reason":"XidHardwareFailure","message":"Node condition NvidiaErrorReboot is now: True, reason: XidHardwareFailure, message: \"NVRM: Xid (PCI:0000:b9:00): 71, pid=, name=, NVLink: fatal error detected on link 6(0x10000, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)\""},"HealthMonitoringAgentDetectionEvent":"HealthEvent"}
```
# Controlli dell’integrità di base
SageMaker HyperPod esegue una serie di *controlli di integrità di base* sulle istanze del cluster durante la creazione e l'aggiornamento dei cluster. HyperPod Questi controlli di integrità di base sono indipendenti dall'orchestratore, quindi sono applicabili indipendentemente dalle piattaforme di orchestrazione sottostanti supportate da SageMaker HyperPod (Amazon EKS o Slurm).
I controlli dell’integrità di base monitorano le istanze del cluster per individuare problemi relativi a dispositivi come gli acceleratori (core GPU e Trainium) e i dispositivi di rete (Elastic Fabric Adapter o EFA). Per trovare l’elenco dei controlli dell’integrità di base dei cluster, consulta la sezione sui [controlli dell’integrità del cluster](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-resiliency-slurm.html#sagemaker-hyperpod-resiliency-slurm-cluster-health-check).
# Controlli dell’integrità approfonditi
SageMaker HyperPod esegue *controlli approfonditi sullo stato* delle istanze del cluster durante la creazione e l'aggiornamento dei cluster. HyperPod I controlli approfonditi dello stato garantiscono l'affidabilità e la stabilità dei SageMaker HyperPod cluster testando a fondo i componenti hardware e dell'infrastruttura sottostanti prima di consentire l'utilizzo dei cluster per l'addestramento di modelli di machine learning. Questo approccio proattivo aiuta a identificare e mitigare i potenziali problemi nelle prime fasi del ciclo di vita del cluster.
## Elenco dei controlli sanitari approfonditi eseguiti da SageMaker HyperPod
SageMaker HyperPod esegue i seguenti controlli sanitari approfonditi.
**Controlli dell’integrità approfonditi a livello di istanza**
| Categoria | Nome dell’utilità | Compatibilità del tipo di istanza | Description |
| --- | --- | --- | --- |
| Accelerator | GPU/count NVLink | GPU | Verifica GPU/NVLink i conteggi. |
| Accelerator | [Diagnostica DCGM](https://docs.nvidia.com/datacenter/dcgm/latest/user-guide/dcgm-diagnostics.html) di livello 4 | GPU | Valuta lo stato e la funzionalità di NVIDIA GPUs eseguendo la diagnostica DCGM (NVIDIA Data Center GPU Manager) a livello 4, inclusi test di memoria aggiuntivi. |
| Accelerator | Neuron Sysfs | Trainium | Per le istanze basate su Trainium, l’integrità dei dispositivi Neuron viene determinato dalla lettura dei contatori di [Neuron Sysfs](https://awsdocs-neuron.readthedocs-hosted.com/en/latest/tools/neuron-sys-tools/neuron-sysfs-user-guide.html) propagati direttamente dal driver Neuron. |
| Accelerator | Controllo dell’hardware Neuron | Trainium | Esegue un carico di lavoro di formazione e verifica i risultati per testare l'hardware. |
| Accelerator | Test locale NCCOM | Trainium | Valuta le prestazioni delle operazioni di comunicazione collettiva su singoli nodi Trainium |
| Rete | EFA | GPU e Trainium | Esegue il benchmarking della latenza e della larghezza di banda sul dispositivo EFA collegato. |
**Controlli dell’integrità approfonditi a livello di cluster**
| Categoria | Nome dell’utilità | Compatibilità del tipo di istanza | Description |
| --- | --- | --- | --- |
| Accelerator | Test NCCL | GPU | Verifica le prestazioni delle operazioni di comunicazione collettiva su più unità NVIDIA GPUs |
| Accelerator | Test del cluster NCCOM | Trainium | Verifica le prestazioni delle operazioni di comunicazione collettiva su più nodi Trainium |
## Log dei controlli dell’integrità approfonditi
Di seguito sono riportati alcuni esempi di log tratti dai controlli sanitari SageMaker HyperPod approfonditi.
**Log a livello di cluster**
I log dei controlli sanitari approfonditi a livello di cluster sono archiviati nel gruppo di log all'indirizzo CloudWatch `/aws/sagemaker/Clusters//`
I flussi di log vengono registrati in `DeepHealthCheckResults/`.
Nell’esempio illustrato di seguito, i log di output dei controlli dell’integrità approfonditi mostrano l’ID dell’istanza che non ha superato i controlli insieme alla causa dell’errore.
```
{
"level": "error",
"ts": "2024-06-18T21:15:22Z",
"msg": "Encountered FaultyInstance. Replace the Instance. Region: us-west-2, InstanceType: p4d.24xlarge. ERROR:Bandwidth has less than threshold: Expected minimum threshold :80,NCCL Test output Bw: 30"
}
```
**Log a livello di istanza**
I log dei controlli dell’integrità approfonditi a livello di istanza sono archiviati in `/var/log/aws/clusters/sagemaker-deep-health-check.log` su ogni nodo. Accedi con SSH al nodo e apri il file di log eseguendo il comando seguente.
```
cat /var/log/aws/clusters/sagemaker-deep-health-check.log
```
Di seguito è riportato un esempio di output del controllo dello stress dell’hardware e di [NVIDIA DCGM](https://developer.nvidia.com/dcgm), oltre all’output del test di connettività EFA.
```
# Hardware Stress Test output
2024-08-20T21:53:58Z info Executing Hardware stress check with command: stress-ng, and args: [--cpu 32 --vm 2 --hdd 1 --fork 8 --switch 4 --timeout 60 --metrics]
2024-08-20T21:54:58Z info stress-ng success
2024-08-20T21:54:58Z info GpuPci Count check success
# DCGM Stress Test
2024-08-20T22:25:02Z info DCGM diagnostic health summary: dcgmCheckLevel: 0 dcgmVersion: 3.3.7 gpuDriverVersion: 535.183.01, gpuDeviceIds: [2237] replacementRequired: false rebootRequired:false
# EFA Loopback Test
2024-08-20T22:26:28Z info EFA Loopback check passed for device: rdmap0s29 . Output summary is MaxBw: 58.590000, AvgBw: 32.420000, MaxTypicalLat: 30.870000, MinTypicalLat: 20.080000, AvgLat: 21.630000
```
Di seguito è riportato un esempio di output del test di connettività NCCL.
```
# size count type redop root time algbw busbw #wrong time algbw busbw #wrong
# (B) (elements) (us) (GB/s) (GB/s) (us) (GB/s) (GB/s)
8 2 float sum -1 353.9 0.00 0.00 0 304.2 0.00 0.00 0
16 4 float sum -1 352.8 0.00 0.00 0 422.9 0.00 0.00 0
32 8 float sum -1 520.0 0.00 0.00 0 480.3 0.00 0.00 0
64 16 float sum -1 563.0 0.00 0.00 0 416.1 0.00 0.00 0
128 32 float sum -1 245.1 0.00 0.00 0 308.4 0.00 0.00 0
256 64 float sum -1 310.8 0.00 0.00 0 304.9 0.00 0.00 0
512 128 float sum -1 304.9 0.00 0.00 0 300.8 0.00 0.00 0
1024 256 float sum -1 509.3 0.00 0.00 0 495.4 0.00 0.00 0
2048 512 float sum -1 530.3 0.00 0.00 0 420.0 0.00 0.00 0
4096 1024 float sum -1 391.2 0.01 0.01 0 384.5 0.01 0.01 0
8192 2048 float sum -1 328.5 0.02 0.02 0 253.2 0.03 0.03 0
16384 4096 float sum -1 497.6 0.03 0.03 0 490.9 0.03 0.03 0
32768 8192 float sum -1 496.7 0.07 0.07 0 425.0 0.08 0.08 0
65536 16384 float sum -1 448.0 0.15 0.15 0 501.0 0.13 0.13 0
131072 32768 float sum -1 577.4 0.23 0.23 0 593.4 0.22 0.22 0
262144 65536 float sum -1 757.8 0.35 0.35 0 721.6 0.36 0.36 0
524288 131072 float sum -1 1057.1 0.50 0.50 0 1019.1 0.51 0.51 0
1048576 262144 float sum -1 1460.5 0.72 0.72 0 1435.6 0.73 0.73 0
2097152 524288 float sum -1 2450.6 0.86 0.86 0 2583.1 0.81 0.81 0
4194304 1048576 float sum -1 4344.5 0.97 0.97 0 4419.3 0.95 0.95 0
8388608 2097152 float sum -1 8176.5 1.03 1.03 0 8197.8 1.02 1.02 0
16777216 4194304 float sum -1 15312 1.10 1.10 0 15426 1.09 1.09 0
33554432 8388608 float sum -1 30149 1.11 1.11 0 29941 1.12 1.12 0
67108864 16777216 float sum -1 57819 1.16 1.16 0 58635 1.14 1.14 0
134217728 33554432 float sum -1 115699 1.16 1.16 0 115331 1.16 1.16 0
268435456 67108864 float sum -1 227507 1.18 1.18 0 228047 1.18 1.18 0
536870912 134217728 float sum -1 453751 1.18 1.18 0 456595 1.18 1.18 0
1073741824 268435456 float sum -1 911719 1.18 1.18 0 911808 1.18 1.18 0
2147483648 536870912 float sum -1 1804971 1.19 1.19 0 1806895 1.19 1.19 0
2024-08-20T16:22:43.831-07:00
# Out of bounds values : 0 OK
2024-08-20T16:22:43.831-07:00
# Avg bus bandwidth : 0.488398
2024-08-20T23:22:43Z info Nccl test successful. Summary: NcclMaxAlgoBw: 1.190000, NcclAvgAlgoBw: 0.488398, NcclThresholdAlgoBw: 1.180000, NcclOutOfBoundError: OK, NcclOperations: all_reduce_perf, NcclTotalDevices: 2, NcclNodes: 2, NcclClusterMessage:
```
# Ripristino automatico del nodo
Durante la creazione o l’aggiornamento del cluster, gli utenti amministratori del cluster possono selezionare l’opzione di ripristino del nodo (istanza) scegliendo tra `Automatic` (consigliato) e `None` a livello di cluster. Se impostato su`Automatic`, SageMaker HyperPod riavvia o sostituisce automaticamente i nodi difettosi.
**Importante**
Consigliamo di impostare l’opzione `Automatic`.
Il ripristino automatico dei nodi viene eseguito quando vengono rilevati problemi dall’agente di monitoraggio dell’integrità, dai controlli dell’integrità di base e dai controlli dell’integrità approfonditi. Se è impostato `None`, l’agente di monitoraggio dell’integrità etichetta le istanze in cui viene rilevato un guasto, ma non avvia automaticamente alcuna azione di correzione o ripristino sui nodi interessati. Questa opzione non è consigliata.
# Etichette Kubernetes relative alla resilienza di SageMaker HyperPod
*Le etichette* sono coppie chiave-valore allegate agli oggetti [Kubernetes](https://kubernetes.io/docs/concepts/overview/working-with-objects/#kubernetes-objects). SageMaker HyperPod introduce le seguenti etichette per i controlli sanitari che fornisce.
## Etichette dello stato di integrità dei nodi
Le etichette `node-health-status` rappresentano lo stato di integrità del nodo e devono essere utilizzate come parte del filtro di selezione dei nodi integri.
| Etichetta | Description |
| --- | --- |
| sagemaker.amazonaws.com/node-health-status: Schedulable | Il nodo ha superato i controlli dell’integrità di base ed è disponibile per l’esecuzione di carichi di lavoro. Questo controllo di integrità è lo stesso delle [funzionalità di SageMaker HyperPod resilienza attualmente disponibili per i cluster Slurm](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-resiliency-slurm.html). |
| sagemaker.amazonaws.com/node-health-status: Unschedulable | Il nodo sta eseguendo controlli dell’integrità approfonditi e non è disponibile per l’esecuzione di carichi di lavoro. |
| sagemaker.amazonaws.com/node-health-status: UnschedulablePendingReplacement | Il nodo non ha superato i controlli dell’integrità approfonditi o i controlli degli agenti di monitoraggio dell’integrità e deve essere sostituito. Se il ripristino automatico del nodo è abilitato, il nodo verrà automaticamente sostituito da. SageMaker HyperPod |
| sagemaker.amazonaws.com/node-health-status: UnschedulablePendingReboot | Il nodo non ha superato i controlli dell’integrità approfonditi o i controlli degli agenti di monitoraggio dell’integrità e richiede un riavvio. Se il ripristino automatico del nodo è abilitato, il nodo verrà riavviato automaticamente da. SageMaker HyperPod |
## Etichette dei controlli dell’integrità approfonditi
Le etichette `deep-health-check-status` rappresentano lo stato di avanzamento dei controlli dell’integrità approfonditi su un nodo specifico. Sono utili agli utenti di Kubernetes per filtrare rapidamente in base allo stato di avanzamento complessivo dei controlli dell’integrità approfonditi.
| Etichetta | Description |
| --- | --- |
| sagemaker.amazonaws.com/deep-health-check-status: InProgress | Il nodo sta eseguendo controlli dell’integrità approfonditi e non è disponibile per l’esecuzione di carichi di lavoro. |
| sagemaker.amazonaws.com/deep-health-check-status: Passed | Il nodo ha completato correttamente i controlli dell’integrità approfonditi e i controlli degli agenti di monitoraggio dell’integrità ed è disponibile per l’esecuzione di carichi di lavoro. |
| sagemaker.amazonaws.com/deep-health-check-status: Failed | Il nodo non ha superato i controlli dell’integrità approfonditi o i controlli degli agenti di monitoraggio dell’integrità e richiede il riavvio o la sostituzione. Se il ripristino automatico del nodo è abilitato, il nodo verrà riavviato o sostituito automaticamente da. SageMaker HyperPod |
## Etichette relative al tipo e al motivo del guasto
Di seguito vengono descritte le etichette `fault-type` e`fault-reason`.
+ Le etichette `fault-type` rappresentano categorie generali per i guasti in caso di controlli dell’integrità non riusciti. Queste vengono compilate per gli errori identificati sia durante i controlli dell’integrità approfonditi sia dai controlli dell’agente di monitoraggio dell’integrità.
+ Le etichette `fault-reason` riportano il motivo dettagliato del guasto associato a `fault-type`.
## Come SageMaker HyperPod etichette
Gli argomenti seguenti illustrano come viene eseguita l’etichettatura in base ai vari casi.
**Topics**
+ [Quando un nodo viene aggiunto a un SageMaker HyperPod cluster con la configurazione Deep Health Check disattivata](#sagemaker-hyperpod-eks-resiliency-node-how-it-labels-when-dhc-is-off)
+ [Quando un nodo viene aggiunto a un SageMaker HyperPod cluster con la configurazione Deep Health Check abilitata](#sagemaker-hyperpod-eks-resiliency-node-how-it-labels-when-dhc-is-on)
+ [Quando si verificano errori di calcolo sui nodi](#sagemaker-hyperpod-eks-resiliency-node-how-it-labels-when-node-fails)
### Quando un nodo viene aggiunto a un SageMaker HyperPod cluster con la configurazione Deep Health Check disattivata
Quando viene aggiunto un nuovo nodo a un cluster e se il controllo approfondito dello stato non è abilitato per il gruppo di istanze, SageMaker HyperPod esegue gli stessi controlli di integrità dei controlli di [ SageMaker HyperPod integrità attualmente disponibili per i cluster Slurm](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-resiliency-slurm.html).
Se il controllo dell’integrità viene superato, i nodi vengono contrassegnati con la seguente etichetta.
```
sagemaker.amazonaws.com/node-health-status: Schedulable
```
Se il controllo dell’integrità non viene superato, i nodi verranno terminati e sostituiti. Questo comportamento è lo stesso del modo in cui funziona il controllo dello stato di SageMaker HyperPod salute per i cluster Slurm.
### Quando un nodo viene aggiunto a un SageMaker HyperPod cluster con la configurazione Deep Health Check abilitata
Quando viene aggiunto un nuovo nodo a un SageMaker HyperPod cluster e se il test di controllo approfondito dello stato è abilitato per il gruppo di istanze, HyperPod prima contamina il nodo e avvia il check/stress test di integrità approfondito di circa 2 ore sul nodo. Ci sono tre possibili esiti per le etichette dei nodi dopo il controllo dell’integrità approfondito.
1. Quando il test di controllo dell’integrità approfondito viene superato.
```
sagemaker.amazonaws.com/node-health-status: Schedulable
```
1. Quando il test di controllo dell’integrità approfondito non riesce e l’istanza deve essere sostituita.
```
sagemaker.amazonaws.com/node-health-status: UnschedulablePendingReplacement
```
1. Quando il test di controllo dell’integrità approfondito non riesce e l’istanza deve essere riavviata per ripetere il test.
```
sagemaker.amazonaws.com/node-health-status: UnschedulablePendingReboot
```
Se un’istanza non supera il test di controllo dell’integrità approfondito, verrà sempre sostituita. Se i test del controllo dell’integrità approfondito hanno esito positivo, il taint sul nodo verrà rimosso.
### Quando si verificano errori di calcolo sui nodi
L'agente di monitoraggio dello stato di SageMaker HyperPod salute inoltre monitora continuamente lo stato di salute di ciascun nodo. Quando rileva eventuali guasti (ad esempio della GPU o del driver), l’agente contrassegna il nodo con una delle seguenti etichette.
1. Quando il nodo non è integro e deve essere sostituito.
```
sagemaker.amazonaws.com/node-health-status: UnschedulablePendingReplacement
```
1. Quando il nodo non è integro e deve essere riavviato.
```
sagemaker.amazonaws.com/node-health-status: UnschedulablePendingReboot
```
L’agente di monitoraggio dell’integrità esegue il taint anche sul nodo se rileva eventuali problemi di integrità del nodo.
# Quarantena, sostituzione o riavvio manuale di un nodo
Scopri come mettere in quarantena, sostituire e riavviare manualmente un nodo difettoso in SageMaker HyperPod cluster orchestrati con Amazon EKS.
**Per mettere in quarantena un nodo e forzare l’eliminazione di un pod di addestramento**
```
kubectl cordon
```
Dopo la quarantena, forza l’espulsione del pod. Questa operazione è utile se un pod è bloccato in stato di terminazione da più di 30 minuti o se `kubectl describe pod` indica che il nodo non è pronto in Eventi
```
kubectl delete pods --grace-period=0 --force
```
SageMaker HyperPod offre due metodi per il ripristino manuale dei nodi. L'approccio preferito consiste nell'utilizzare SageMaker HyperPod Reboot and Replace APIs, che fornisce un processo di ripristino più rapido e trasparente che funziona con tutti gli orchestratori. In alternativa, puoi usare i comandi kubectl per etichettare i nodi per le operazioni di riavvio e sostituzione. Entrambi i metodi attivano gli stessi processi di ripristino. SageMaker HyperPod
**Per riavviare un nodo utilizzando l'API Reboot**
Per riavviare un nodo puoi usare l'API. BatchRebootClusterNodes
Ecco un esempio di esecuzione dell'operazione di riavvio su due istanze di un cluster utilizzando: AWS Command Line Interface
```
aws sagemaker batch-reboot-cluster-nodes \
--cluster-name arn:aws:sagemaker:ap-northeast-1:123456789:cluster/test-cluster \
--node-ids i-0123456789abcdef0 i-0fedcba9876543210
```
**Per sostituire un nodo utilizzando l'API Replace**
Per sostituire un nodo puoi usare l' BatchReplaceClusterNodes API come segue
Ecco un esempio di esecuzione dell'operazione di sostituzione su due istanze di un cluster utilizzando: AWS Command Line Interface
```
aws sagemaker batch-replace-cluster-nodes \
--cluster-name arn:aws:sagemaker:ap-northeast-1:123456789:cluster/test-cluster \
--node-ids i-0123456789abcdef0 i-0fedcba9876543210
```
**Cluster gestiti da Karpenter**
Per SageMaker HyperPod i cluster che utilizzano Karpenter per il provisioning dei nodi, l'`BatchReplaceClusterNodes`API non garantisce la creazione di un nodo sostitutivo. Il nodo specificato *verrà* terminato, ma la sostituzione dipende dal modello di provisioning di Karpenter. pod-demand-based Karpenter crea nuovi nodi solo quando ci sono pod in `Pending` uno stato che non può essere pianificato su nodi esistenti.
Se il carico di lavoro del nodo eliminato può essere riprogrammato sui nodi rimanenti del cluster (ad esempio, se tali nodi hanno una capacità sufficiente), Karpenter non fornisce un supporto sostitutivo. Per garantire la creazione di un nodo sostitutivo, verificate che la configurazione del carico di lavoro (ad esempio le regole di anti-affinità dei pod o le richieste di risorse) richieda un nuovo nodo per i pod spostati.
Siamo consapevoli di questa limitazione e stiamo lavorando attivamente a una soluzione per imporre la sostituzione dei nodi quando richiesta tramite l'API.
**Per sostituire un nodo usando kubectl**
Etichetta il nodo con cui sostituirlo`sagemaker.amazonaws.com/node-health-status=UnschedulablePendingReplacement`, che attiva il. SageMaker HyperPod [Ripristino automatico del nodo](sagemaker-hyperpod-eks-resiliency-node-recovery.md) Tieni presente che devi anche attivare il ripristino automatico dei nodi durante la creazione o l’aggiornamento del cluster.
```
kubectl label nodes \
sagemaker.amazonaws.com/node-health-status=UnschedulablePendingReplacement
```
**Per riavviare un nodo usando kubectl**
Etichetta il nodo con `sagemaker.amazonaws.com/node-health-status=UnschedulablePendingReboot` cui riavviare, che attiva il. SageMaker HyperPod [Ripristino automatico del nodo](sagemaker-hyperpod-eks-resiliency-node-recovery.md) Tieni presente che devi anche attivare il ripristino automatico dei nodi durante la creazione o l’aggiornamento del cluster.
```
kubectl label nodes \
sagemaker.amazonaws.com/node-health-status=UnschedulablePendingReboot
```
Dopo aver applicato `UnschedulablePendingReboot` le etichette `UnschedulablePendingReplacement` o, dovresti essere in grado di vedere che il nodo viene terminato o riavviato in pochi minuti.
# Configurazioni di resilienza consigliate
Quando i controlli approfonditi dello stato sono abilitati, ogni volta che viene aggiunta una nuova istanza al HyperPod cluster (durante la creazione del cluster o tramite la sostituzione automatica del nodo), la nuova istanza viene sottoposta al processo di controllo approfondito (stress test a livello di istanza) per circa un paio d'ore. Di seguito sono illustrate alcune combinazioni di configurazione della resilienza, suggerite in base ai possibili casi.
1. **Caso**: hai altri nodi di riserva all’interno di un cluster come risorse di backup (la capacità non è completamente utilizzata) o puoi attendere circa 2 ore per ottenere le istanze meno soggette a errori grazie al processo di controllo dell’integrità approfondito.
**Raccomandazione**: abilita la configurazione dei controlli dell’integrità approfonditi per tutto il ciclo di vita del cluster. La configurazione del ripristino automatico del nodo è abilitata per impostazione predefinita.
1. **Caso**: non hai nodi di backup aggiuntivi (la capacità è completamente utilizzata da carichi di addestramento). Hai bisogno di nodi sostitutivi il prima possibile per riprendere il job di addestramento.
**Raccomandazione**: abilita il controllo dell’integrità approfondito durante la creazione del cluster, quindi disattiva la configurazione dei controlli dell’integrità approfonditi dopo la creazione del cluster. La configurazione del ripristino automatico del nodo è abilitata per impostazione predefinita.
1. **Caso**: non hai nodi di backup aggiuntivi e non vuoi attendere il processo di controllo dell’integrità approfondito, che richiede circa 2 ore (cluster di piccole dimensioni).
**Raccomandazione**: disabilita la configurazione dei controlli dell’integrità approfonditi per tutto il ciclo di vita del cluster. La configurazione del ripristino automatico del nodo è abilitata per impostazione predefinita.
Per riprendere immediatamente il job di addestramento dopo un errore, assicurati di avere nodi di riserva aggiuntivi disponibili come risorse di backup nel cluster.
# Istanze Spot in Amazon SageMaker HyperPod
Amazon SageMaker HyperPod supporta le istanze Spot di Amazon EC2, che consentono risparmi significativi sui costi per carichi di lavoro con tolleranza ai guasti e stateless. AI/ML I casi d'uso includono lavori di inferenza e formazione in batch, ottimizzazione degli iperparametri e carichi di lavoro sperimentali. Puoi anche utilizzare le istanze Spot per scalare automaticamente la capacità di elaborazione quando questa capacità a basso costo è disponibile e tornare alla capacità on demand quando viene recuperata la capacità Spot aggiunta.
Per impostazione predefinita, le istanze Spot on HyperPod funzionano con la [funzione HyperPod di provisioning continuo](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-scaling-eks.html), che consente di fornire automaticamente la capacità SageMaker HyperPod residua in background mentre i carichi di lavoro iniziano immediatamente sulle istanze disponibili. Quando il provisioning dei nodi riscontra errori dovuti a vincoli di capacità o altri problemi, riprova SageMaker HyperPod automaticamente in background finché i cluster non raggiungono la scala desiderata, in modo che le operazioni di scalabilità automatica rimangano resilienti e non bloccanti. [Puoi anche utilizzare le istanze Spot con la scalabilità automatica basata su Karpenter.](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-eks-autoscaling.html)
**Funzionalità e concetti chiave da considerare**
+ Ottieni un risparmio sui costi fino al 90% rispetto alle istanze On-Demand
+ Utilizza le istanze Spot per lavori in grado di gestire le interruzioni e in cui i tempi di inizio e completamento dei lavori sono flessibili
+ Quando si utilizza Karpenter per il ridimensionamento automatico, è possibile configurare la configurazione in modo da ricorrere automaticamente HyperPod a On-Demand quando la capacità Spot è interrotta o non disponibile
+ Accedi a un'ampia gamma di tipi di istanze di CPU, GPU e acceleratori supportati da HyperPod
+ La disponibilità della capacità dipende dalla fornitura di EC2 e varia in base alla regione e al tipo di istanza
+ È possibile eseguire varie azioni, come identificare la probabilità di ottenere le istanze desiderate o di subire interruzioni, utilizzando vari strumenti come [Spot Instance](https://aws.amazon.com/ec2/spot/instance-advisor/) Advisor fornito da EC2
## Nozioni di base
### Prerequisiti
Prima di iniziare, assicurati di disporre dei seguenti elementi:
#### AWS CLI installato e configurato
Imposta AWS le tue credenziali e la tua regione:
```
aws configure
```
Per istruzioni dettagliate, consulta la [documentazione relativa alle AWS credenziali](https://docs.aws.amazon.com/sdk-for-java/v1/developer-guide/setup-credentials.html).
#### Ruolo IAM per l'esecuzione SageMaker HyperPod
Per aggiornare il cluster, devi prima creare le autorizzazioni [AWS Identity and Access Management](https://aws.amazon.com/iam/) (IAM) per Karpenter. Per istruzioni, consulta [Creare un ruolo IAM per la scalabilità HyperPod automatica](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-eks-autoscaling-iam.html) con Karpenter.
#### Configurazione di cluster VPC ed EKS
**2.1 Creazione di cluster VPC ed EKS**
Segui la [guida all'installazione di HyperPod EKS](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-eks-install-packages-using-helm-chart.html) per:
1. Crea un VPC con sottoreti in più zone di disponibilità
1. Crea un cluster EKS
1. Installa [le dipendenze richieste utilizzando i](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-eks-install-packages-using-helm-chart.html) grafici Helm
**2.2 Imposta le variabili d'ambiente**
```
export EKS_CLUSTER_ARN="arn:aws:eks:REGION:ACCOUNT_ID:cluster/CLUSTER_NAME"
export EXECUTION_ROLE="arn:aws:iam::ACCOUNT_ID:role/SageMakerExecutionRole"
export BUCKET_NAME="your-s3-bucket-name"
export SECURITY_GROUP="sg-xxxxx"
export SUBNET="subnet-xxxxx"
export SUBNET1="subnet-xxxxx"
export SUBNET2="subnet-xxxxx"
export SUBNET3="subnet-xxxxx"
```
#### Quote di servizio per le istanze Spot
Verifica di disporre delle quote richieste per le istanze che creerai nel cluster. SageMaker HyperPod Per rivedere le quote, nella console Service Quotas, AWS scegli servizi nel riquadro di navigazione, quindi scegli. SageMaker Ad esempio, la schermata seguente mostra la quota disponibile per le istanze c5.
![\[Un'immagine contenente informazioni sulla regione di costo.\]](http://docs.aws.amazon.com/it_it/sagemaker/latest/dg/images/Screenshot-cluster-quota.png)
#### Verifica la disponibilità degli spot
Prima di creare gruppi di istanze Spot, verifica la disponibilità in diverse zone di disponibilità:
```
aws ec2 get-spot-placement-scores \
--region us-west-2 \
--instance-types c5.2xlarge \
--target-capacity 10 \
--single-availability-zone \
--region-names us-west-2
```
**Suggerimento**: scegli come target le zone di disponibilità con punteggi di posizionamento più alti per una migliore disponibilità. Puoi anche controllare i prezzi di Spot Instance Advisor ed EC2 Spot per verificare la disponibilità. Seleziona la zona di disponibilità richiesta con un punteggio di disponibilità migliore e configura il gruppo di istanze con la sottorete associata per avviare l'istanza in quella zona.
### Creazione di un gruppo di istanze (nessuna scalabilità automatica)
**CreateCluster (Spot)**
```
aws sagemaker create-cluster \
--cluster-name clusterNameHere \
--orchestrator 'Eks={ClusterArn='$EKS_CLUSTER_ARN'}' \
--node-provisioning-mode "Continuous" \
--cluster-role 'arn:aws:iam::YOUR-ACCOUNT-ID:role/SageMakerHyperPodRole' \
--instance-groups '[{
"InstanceGroupName": "auto-spot-c5-2x-az1",
"InstanceType": "ml.c5.2xlarge",
"InstanceCount": 2,
"CapacityRequirements: { "Spot": {} }
"LifeCycleConfig": {
"SourceS3Uri": "s3://'$BUCKET_NAME'",
"OnCreate": "on_create_noop.sh"
},
"ExecutionRole": "'$EXECUTION_ROLE'",
"ThreadsPerCore": 1,
"OverrideVpcConfig": {
"SecurityGroupIds": ["'$SECURITY_GROUP'"],
"Subnets": ["'$SUBNET1'"]
}
}]'
--vpc-config '{
"SecurityGroupIds": ["'$SECURITY_GROUP'"],
"Subnets": ["'$SUBNET'"]
}'
```
**Aggiorna cluster (Spot \$1 On-Demand)**
```
aws sagemaker update-cluster \
--cluster-name "my-cluster" \
--instance-groups '[{
"InstanceGroupName": "auto-spot-c5-x-az3",
"InstanceType": "ml.c5.xlarge",
"InstanceCount": 2,
"CapacityRequirements: { "Spot": {} },
"LifeCycleConfig": {
"SourceS3Uri": "s3://'$BUCKET_NAME'",
"OnCreate": "on_create_noop.sh"
},
"ExecutionRole": "'$EXECUTION_ROLE'",
"ThreadsPerCore": 1,
"OverrideVpcConfig": {
"SecurityGroupIds": ["'$SECURITY_GROUP'"],
"Subnets": ["'$SUBNET3'"]
}
},
{
"InstanceGroupName": "auto-spot-c5-2x-az2",
"InstanceType": "ml.c5.2xlarge",
"InstanceCount": 2,
"CapacityRequirements: { "Spot": {} }
"LifeCycleConfig": {
"SourceS3Uri": "s3://'$BUCKET_NAME'",
"OnCreate": "on_create_noop.sh"
},
"ExecutionRole": "'$EXECUTION_ROLE'",
"ThreadsPerCore": 1,
"OverrideVpcConfig": {
"SecurityGroupIds": ["'$SECURITY_GROUP'"],
"Subnets": ["'$SUBNET2'"]
}
},
{
"InstanceGroupName": "auto-ondemand-c5-2x-az1",
"InstanceType": "ml.c5.2xlarge",
"InstanceCount": 2,
"LifeCycleConfig": {
"SourceS3Uri": "s3://'$BUCKET_NAME'",
"OnCreate": "on_create_noop.sh"
},
"ExecutionRole": "'$EXECUTION_ROLE'",
"ThreadsPerCore": 1,
"OverrideVpcConfig": {
"SecurityGroupIds": ["'$SECURITY_GROUP'"],
"Subnets": ["'$SUBNET1'"]
}
}]'
```
`CapacityRequirements`non può essere modificato una volta creato un gruppo di istanze.
**Descrizione del cluster**
```
aws sagemaker describe-cluster --cluster-name $HP_CLUSTER_NAME --region us-west-2
```
```
## Sample Response
{
"ClusterName": "my-cluster",
"InstanceGroups": [
{
"InstanceGroupName": "ml.c5.2xlarge",
"InstanceType": "ml.c5.xlarge",
"InstanceCount": 5,
"CurrentCount": 3,
"CapacityRequirements: { "Spot": {} },
"ExecutionRole": "arn:aws:iam::account:role/SageMakerExecutionRole",
"InstanceStorageConfigs": [...],
"OverrideVpcConfig": {...}
}
// Other IGs
]
}
```
**DescribeClusterNode**
```
aws sagemaker describe-cluster-node --cluster-name $HP_CLUSTER_NAME --region us-west-2
```
```
## Sample Response
{
"NodeDetails": {
"InstanceId": "i-1234567890abcdef1",
"InstanceGroupName": "ml.c5.2xlarge",
"CapacityType": "Spot",
"InstanceStatus": {...}
}
}
```
### Utilizzo della console
#### Crea e configura un SageMaker HyperPod cluster
Per iniziare, avvia e configura il cluster SageMaker HyperPod EKS e verifica che la modalità di provisioning continuo sia abilitata durante la creazione del cluster. Completa questa procedura:
1. Sulla console SageMaker AI, scegli HyperPod i cluster nel pannello di navigazione.
1. Scegli Crea HyperPod cluster e Orchestrated on Amazon EKS.
1. Per le opzioni di configurazione, seleziona Configurazione personalizzata.
1. In Nome, immetti un nome.
1. Per Ripristino dell'istanza, seleziona Automatico.
1. Per la modalità di provisioning dell'istanza, seleziona Usa il provisioning continuo.
1. CapacityType : Seleziona Spot
1. Seleziona Invia.
Schermata della console:
![\[Un'immagine contenente il flusso del cluster di creazione.\]](http://docs.aws.amazon.com/it_it/sagemaker/latest/dg/images/Screenshot-create-cluster.png)
Questa configurazione crea la configurazione necessaria come cloud privato virtuale (VPC), sottoreti, gruppi di sicurezza e cluster EKS e installa gli operatori nel cluster. Puoi anche fornire risorse esistenti come un cluster EKS se desideri utilizzare un cluster esistente invece di crearne uno nuovo. Questa configurazione richiederà circa 20 minuti.
#### Aggiungere un nuovo gruppo di istanze Spot allo stesso cluster
Per aggiungere uno Spot IG al tuo cluster HyperPod EKS esistente. Completa questa procedura:
1. Sulla console SageMaker AI, scegli HyperPod i cluster nel riquadro di navigazione.
1. Seleziona un HyperPod cluster esistente con Amazon EKS Orchestration (assicurati che il provisioning continuo sia abilitato).
1. Fare clic su Edit (Modifica).
1. Nella pagina Modifica cluster, fai clic su Crea gruppo di istanze.
1. Seleziona il tipo di capacità: istanza Spot nella configurazione del gruppo di istanze.
1. Fai clic su Crea gruppo di istanze.
1. Fare clic su Submit (Invia).
**Schermata della console:**
![\[Un'immagine contenente il flusso di creazione del gruppo di istanze.\]](http://docs.aws.amazon.com/it_it/sagemaker/latest/dg/images/Screenshot-instance-group.png)
### Usando CloudFormation
```
Resources:
TestCluster:
Type: AWS::SageMaker::Cluster
Properties:
ClusterName: "SampleCluster"
InstanceGroups:
- InstanceGroupName: group1
InstanceType: ml.c5.2xlarge
InstanceCount: 1
LifeCycleConfig:
SourceS3Uri: "s3://'$BUCKET_NAME'"
OnCreate: "on_create_noop.sh"
ExecutionRole: "'$EXECUTION_ROLE'",
ThreadsPerCore: 1
CapacityRequirements:
Spot: {}
VpcConfig:
Subnets:
- "'$SUBNET1'"
SecurityGroupIds:
- "'$SECURITY_GROUP'"
Orchestrator:
Eks:
ClusterArn:
'$EKS_CLUSTER_ARN'
NodeProvisioningMode: "Continuous"
NodeRecovery: "Automatic"
```
Vedi [https://docs.aws.amazon.com/sagemaker/latest/dg/smcluster- getting-started-eks-console - create-cluster-cfn .html](https://docs.aws.amazon.com/sagemaker/latest/dg/smcluster-getting-started-eks-console-create-cluster-cfn.html) per i dettagli.
### Autoscaling basato su Karpenter
#### Crea il ruolo del cluster
**Passaggio 1: accedi alla console IAM**
1. Vai al servizio **Console di gestione AWS**→ **IAM**
1. Fai clic su **Ruoli** nella barra laterale sinistra
1. Fai clic su **Crea ruolo**
**Fase 2: Impostazione della politica di fiducia**
1. Seleziona la politica di fiducia personalizzata (anziché AWS il servizio)
1. Sostituisci il JSON predefinito con questa politica di fiducia:
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": [
"hyperpod.sagemaker.amazonaws.com"
]
},
"Action": "sts:AssumeRole"
}
]
}
```
fai clic su Avanti
**Passaggio 3: creazione di una politica di autorizzazioni personalizzata**
Poiché si tratta di SageMaker autorizzazioni specifiche, dovrai creare una politica personalizzata:
1. Fai clic su **Crea politica** (apre una nuova scheda)
1. Fai clic sulla **scheda JSON**
1. Inserisci questa policy:
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"sagemaker:BatchAddClusterNodes",
"sagemaker:BatchDeleteClusterNodes"
],
"Resource": "*"
}
]
}
```
1. **Fai clic su Avanti**
1. Dategli un nome come `SageMakerHyperPodRolePolicy`
1. Fai clic su **Crea politica**
**Fase 4: Allega la policy al ruolo**
1. Torna alla scheda di creazione del ruolo
1. Aggiorna l'elenco delle politiche
1. Cerca e seleziona la politica appena creata
1. Fai clic su **Avanti**
**Fase 5: Assegna un nome e crea un ruolo**
1. Inserisci il nome di un ruolo (ad esempio,`SageMakerHyperPodRole`)
1. Se lo desideri, aggiungi una descrizione
1. Rivedi la politica di fiducia e le autorizzazioni
1. Fai clic su **Crea ruolo**
#### Verifica
Dopo la creazione, puoi effettuare la verifica tramite:
+ Se si seleziona la scheda Relazioni di fiducia, viene visualizzato il servizio hyperpod
+ La selezione della scheda Autorizzazioni mostra la tua politica personalizzata
+ Il ruolo ARN sarà disponibile per l'uso con HyperPod
Il formato ARN del ruolo sarà:
```
arn:aws:iam::YOUR-ACCOUNT-ID:role/SageMakerHyperPodRole
```
#### Crea cluster con AutoScaling:
Per una migliore disponibilità, crea IGs in più sottoreti AZs configurando le sottoreti. Puoi anche includere IGs onDemand come fallback.
```
aws sagemaker create-cluster \
--cluster-name clusterNameHere \
--orchestrator 'Eks={ClusterArn='$EKS_CLUSTER_ARN'}' \
--node-provisioning-mode "Continuous" \
--cluster-role 'arn:aws:iam::YOUR-ACCOUNT-ID:role/SageMakerHyperPodRole' \
--instance-groups '[{
"InstanceGroupName": "auto-spot-c5-2x-az1",
"InstanceType": "ml.c5.2xlarge",
"InstanceCount": 0, // For Auto scaling keep instance count as 0
"CapacityRequirements: { "Spot": {} }
"LifeCycleConfig": {
"SourceS3Uri": "s3://'$BUCKET_NAME'",
"OnCreate": "on_create_noop.sh"
},
"ExecutionRole": "'$EXECUTION_ROLE'",
"ThreadsPerCore": 1,
"OverrideVpcConfig": {
"SecurityGroupIds": ["'$SECURITY_GROUP'"],
"Subnets": ["'$SUBNET1'"]
}
}]'
--vpc-config '{
"SecurityGroupIds": ["'$SECURITY_GROUP'"],
"Subnets": ["'$SUBNET'"]
}'
--auto-scaling ' {
"Mode": "Enable",
"AutoScalerType": "Karpenter"
}'
```
#### Aggiorna cluster (Spot \$1 On-Demand)
```
aws sagemaker update-cluster \
--cluster-name "my-cluster" \
--instance-groups '[{
"InstanceGroupName": "auto-spot-c5-x-az3",
"InstanceType": "ml.c5.xlarge",
"InstanceCount": 2,
"CapacityRequirements: { "Spot": {} },
"LifeCycleConfig": {
"SourceS3Uri": "s3://'$BUCKET_NAME'",
"OnCreate": "on_create_noop.sh"
},
"ExecutionRole": "'$EXECUTION_ROLE'",
"ThreadsPerCore": 1,
"OverrideVpcConfig": {
"SecurityGroupIds": ["'$SECURITY_GROUP'"],
"Subnets": ["'$SUBNET3'"]
}
},
{
"InstanceGroupName": "auto-spot-c5-2x-az2",
"InstanceType": "ml.c5.2xlarge",
"InstanceCount": 2,
"CapacityRequirements: { "Spot": {} }
"LifeCycleConfig": {
"SourceS3Uri": "s3://'$BUCKET_NAME'",
"OnCreate": "on_create_noop.sh"
},
"ExecutionRole": "'$EXECUTION_ROLE'",
"ThreadsPerCore": 1,
"OverrideVpcConfig": {
"SecurityGroupIds": ["'$SECURITY_GROUP'"],
"Subnets": ["'$SUBNET2'"]
}
},
{
"InstanceGroupName": "auto-ondemand-c5-2x-az1",
"InstanceType": "ml.c5.2xlarge",
"InstanceCount": 2,
"LifeCycleConfig": {
"SourceS3Uri": "s3://'$BUCKET_NAME'",
"OnCreate": "on_create_noop.sh"
},
"ExecutionRole": "'$EXECUTION_ROLE'",
"ThreadsPerCore": 1,
"OverrideVpcConfig": {
"SecurityGroupIds": ["'$SECURITY_GROUP'"],
"Subnets": ["'$SUBNET1'"]
}
}]'
```
#### Crea HyperpodNodeClass
`HyperpodNodeClass`è una risorsa personalizzata che esegue il mapping a gruppi di istanze precreati SageMaker HyperPod, definendo i vincoli relativi ai tipi di istanze e alle zone di disponibilità supportati per le decisioni di scalabilità automatica di Karpenter. Per `HyperpodNodeClass` utilizzarla, è sufficiente specificare i nomi `InstanceGroups` del SageMaker HyperPod cluster che si desidera utilizzare come origine per le risorse di AWS calcolo da utilizzare per scalare i pod del proprio. NodePools Il `HyperpodNodeClass` nome che usi qui viene riportato nella sezione successiva NodePool in cui fai riferimento ad esso. Questo indica da NodePool cosa `HyperpodNodeClass` attingere le risorse. Per creare un`HyperpodNodeClass`, completa i seguenti passaggi:
1. Create un file YAML (ad esempio, nodeclass.yaml) simile al codice seguente. Aggiungi `InstanceGroup` i nomi che hai usato al momento della creazione del cluster. SageMaker HyperPod Puoi anche aggiungere nuovi gruppi di istanze a un cluster SageMaker HyperPod EKS esistente.
1. Fai riferimento al `HyperPodNodeClass` nome nella tua NodePool configurazione.
Di seguito è riportato un esempio`HyperpodNodeClass`:
```
apiVersion: karpenter.sagemaker.amazonaws.com/v1
kind: HyperpodNodeClass
metadata:
name: multiazg6
spec:
instanceGroups:
# name of InstanceGroup in HyperPod cluster. InstanceGroup needs to pre-created
# before this step can be completed.
# MaxItems: 10
- auto-spot-c5-2x-az1
- auto-spot-c5-2x-az2
- auto-spot-c5-x-az3
- auto-ondemand-c5-2x-az1
```
Karpenter dà la priorità ai gruppi di istanze Spot rispetto alle istanze On-Demand, utilizzando On-Demand come fallback quando specificato nella configurazione. La selezione delle istanze viene ordinata in base ai punteggi di posizionamento Spot di EC2 associati alla zona di disponibilità di ciascuna sottorete.
**Applica la configurazione al tuo cluster EKS utilizzando: `kubectl`**
```
kubectl apply -f nodeclass.yaml
```
Il HyperPod cluster deve essere AutoScaling abilitato e lo AutoScaling stato deve cambiare `InService` prima di `HyperpodNodeClass` poter essere applicato. Mostra anche le capacità dei gruppi di istanze come Spot o OnDemand. Per ulteriori informazioni e considerazioni chiave, consulta Scaling [automatico](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-eks-autoscaling.html) su EKS. SageMaker HyperPod
**Ad esempio**
```
apiVersion: karpenter.sagemaker.amazonaws.com/v1
kind: HyperpodNodeClass
metadata:
creationTimestamp: "2025-11-30T03:25:04Z"
name: multiazc6
uid: ef5609be-15dd-4700-89ea-a3370e023690
spec:
instanceGroups:
-spot1
status:
conditions:
// true when all IGs in the spec are present in SageMaker cluster, false otherwise
- lastTransitionTime: "2025-11-20T03:25:04Z"
message: ""
observedGeneration: 3
reason: InstanceGroupReady
status: "True"
type: InstanceGroupReady
// true if subnets of IGs are discoverable, false otherwise
- lastTransitionTime: "2025-11-20T03:25:04Z"
message: ""
observedGeneration: 3
reason: SubnetsReady
status: "True"
type: SubnetsReady
// true when all dependent resources are Ready [InstanceGroup, Subnets]
- lastTransitionTime: "2025-11-30T05:47:55Z"
message: ""
observedGeneration: 3
reason: Ready
status: "True"
type: Ready
instanceGroups:
- instanceTypes:
- ml.c5.2xlarge
name:auto-spot-c5-2x-az2
subnets:
- id: subnet-03ecc649db2ff20d2
zone: us-west-2a
zoneId: usw2-az2
- capacities: {"Spot": {}}
```
#### Crea NodePool
NodePool Imposta i vincoli sui nodi che possono essere creati da Karpenter e sui pod che possono essere eseguiti su quei nodi. NodePool Possono essere impostati per eseguire varie azioni, come:
+ Definisci etichette e colorazioni per limitare i pod che possono essere eseguiti sui nodi creati da Karpenter
+ Limita la creazione di nodi a determinate zone, tipi di istanze e architetture di computer e così via
Per ulteriori informazioni su NodePool, fare riferimento a. [NodePools](https://karpenter.sh/docs/concepts/nodepools/) SageMaker HyperPod managed Karpenter supporta una serie limitata di requisiti noti per Kubernetes e Karpenter, che spieghiamo in questo post.
Per creare un, completa i seguenti passaggi: NodePool
Crea un file YAML denominato `nodepool.yaml` con la configurazione desiderata NodePool. Il codice seguente è una configurazione di esempio per creare un esempio. NodePool Specifichiamo NodePool di includere il nostro tipo di istanza SageMaker ml.g6.xlarge e lo specifichiamo inoltre per una zona. Per ulteriori personalizzazioni, fare riferimento a. [NodePools](https://karpenter.sh/docs/concepts/nodepools/)
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: gpunodepool
spec:
template:
spec:
nodeClassRef:
group: karpenter.sagemaker.amazonaws.com
kind: HyperpodNodeClass
name: multiazg6
expireAfter: Never
requirements:
- key: node.kubernetes.io/instance-type
operator: Exists
- key: "node.kubernetes.io/instance-type" // Optional otherwise Karpenter will decide based on Job config resource requirements
operator: In
values: ["ml.c5.2xlarge"]
- key: "topology.kubernetes.io/zone"
operator: In
values: ["us-west-2a"]
```
**Suggerimento**: in caso di interruzione di EC2 Spot, Hyperpod contamina il nodo per innescare lo sfratto del pod. **Il processo di **consolidamento** di Karpenter rispetta i budget destinati alle interruzioni dei pod ed esegue la normale rimozione di Kubernetes, ma se si imposta ConsolidateAfter: 0, il consolidamento può avvenire immediatamente, lasciando pochissimo tempo per lo sfratto graduale dei pod.** Impostalo su un valore diverso da zero per un massimo di 2 minuti per consentire lo sfratto graduale dei pod per qualsiasi esigenza di checkpoint.
**Applicalo NodePool al tuo cluster:**
```
kubectl apply -f nodepool.yaml
```
**Monitora lo NodePool stato per assicurarti che la condizione Ready nello stato sia impostata su True:**
```
kubectl get nodepool gpunodepool -oyaml
```
Questo esempio mostra come utilizzare a per specificare l'hardware (tipo di istanza) e il posizionamento (zona di disponibilità) per i pod. NodePool
**Avvia un carico di lavoro semplice**
Il seguente carico di lavoro esegue una distribuzione Kubernetes in cui i pod in fase di implementazione richiedono 1 CPU e 256 MB di memoria per replica, per pod. I pod non sono ancora stati attivati.
```
kubectl apply -f https://raw.githubusercontent.com/aws/karpenter-provider-aws/refs/heads/main/examples/workloads/inflate.yaml
```
Quando lo applichiamo, possiamo vedere una distribuzione e l'avvio di un singolo nodo nel nostro cluster, come mostrato nella schermata seguente.
**Per scalare questo componente, usa il seguente comando:**
```
kubectl scale deployment inflate --replicas 10
```
Vedi [https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker- hyperpod-eks-autoscaling .html](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-eks-autoscaling.html) per maggiori dettagli.
### Gestione dell'interruzione dei nodi
Le istanze Spot possono essere recuperate in qualsiasi momento. Nella maggior parte dei casi, EC2 fornisce un avviso di interruzione di 2 minuti nel migliore dei casi, ma questo avviso non è garantito. In alcune situazioni, EC2 può chiudere immediatamente le istanze Spot senza alcun preavviso. HyperPod gestisce automaticamente entrambi gli scenari:
+ Con un preavviso di 2 minuti: ritenta automaticamente lo sgombero graduale dei pod e la sostituzione controllata della capacità non appena la capacità Spot diventa disponibile.
+ Senza preavviso (cessazione immediata): ritenta automaticamente la sostituzione del nodo (quando la capacità Spot diventa disponibile) senza procedere allo sfratto
**Come funziona**
Quando EC2 invia un avviso di interruzione Spot, automaticamente: HyperPod
1. Rileva il segnale di interruzione
1. Influisce sul nodo: impedisce la pianificazione di nuovi pod sull'istanza interrotta
1. Rimuove con eleganza i pod: dà ai pod in esecuzione il tempo di completare o controllare il loro lavoro (nel rispetto di Kubernetes) `terminationGracePeriodSeconds`
1. Sostituisce la capacità: tenta automaticamente di fornire le istanze sostitutive (Spot o On-Demand in base alla disponibilità).
La sostituzione della capacità funziona fornendo automaticamente le istanze sostitutive. Quando la capacità non è immediatamente disponibile, il sistema continua a controllare fino a quando le risorse non diventano accessibili. Nel caso di gruppi di istanze senza scalabilità automatica, HyperPod tenta di scalare all'interno dello stesso gruppo di istanze fino a quando non diventa disponibile la capacità richiesta. Per i gruppi di istanze basati su Karpenter, Karpenter implementa un meccanismo di fallback su altri gruppi di istanze configurati nella classe Node quando il gruppo primario non è in grado di soddisfare la domanda. Inoltre, puoi configurare On-Demand come opzione di fallback, permettendo a Karpenter di passare automaticamente alle istanze On-Demand se non riesce a scalare correttamente i gruppi di istanze Spot.
1. Riprogramma i carichi di lavoro: Kubernetes riprogramma automaticamente i pod eliminati su nodi integri
### Individuazione dell'utilizzo e della fattura
Per verificare l'utilizzo e la fatturazione delle istanze Spot su, HyperPod puoi utilizzare la console AWS Cost Explorer. Vai a Billing and Cost Management > Fattura
![\[Un'immagine contenente informazioni sulla regione di costo.\]](http://docs.aws.amazon.com/it_it/sagemaker/latest/dg/images/Screenshot-cost-region.png)
**Per esplorare l'utilizzo e la fatturazione su Console, vai a Billing and Cost Management > Cost Explorer**
![\[Un'immagine contenente costi e utilizzo.\]](http://docs.aws.amazon.com/it_it/sagemaker/latest/dg/images/Screenshot-cost-usage.png)
# Utilizzo UltraServers in Amazon SageMaker HyperPod
SageMaker HyperPod il supporto per Ultraservers offre funzionalità di elaborazione GPU ad alte prestazioni per carichi di lavoro di intelligenza artificiale e apprendimento automatico. Basati su NVIDIA GB200 e sull' NVL72 architettura, questi Ultraserver forniscono NVLink connettività su 18 GB200 istanze in una configurazione dual-rack, per un totale di 72 B200. GPUs Questa NVLink struttura consente ai carichi di lavoro di utilizzare comunicazioni GPU che aumentano la capacità utilizzabile della GPU e la memoria indirizzabile oltre quanto possibile con le istanze discrete, supportando modelli di intelligenza artificiale più complessi e che richiedono molte risorse. La NVLink connettività è abilitata dalla tecnologia NVIDIA IMEX, che gestisce la configurazione di basso livello per connessioni sicure in struttura di GPU tra istanze all'interno dello stesso rack.
HyperPod semplifica l'implementazione e la gestione di questi cluster di GPU attraverso il riconoscimento intelligente della topologia e la configurazione automatizzata. La piattaforma rileva ed etichetta automaticamente i nodi con la loro posizione fisica e le informazioni sui blocchi di capacità, il che supporta la pianificazione basata sulla topologia per i carichi di lavoro distribuiti. HyperPod astrae i complessi requisiti di configurazione IMEX, consentendoti di concentrarti sull'implementazione dei carichi di lavoro piuttosto che sulla configurazione dell'infrastruttura GPU di basso livello. Puoi scegliere opzioni di implementazione flessibili, inclusi nodi autogestiti e gruppi di nodi gestiti da EKS. Amazon EKS offre soluzioni ottimizzate AMIs che includono driver NVIDIA preconfigurati, Fabric Manager, driver IMEX e tutto il software di sistema necessario per un funzionamento senza interruzioni.
L'integrazione include funzionalità di posizionamento dei pod che garantiscono una pianificazione ottimale dei carichi di lavoro distribuiti tra i NVL72 domini utilizzando etichette topologiche Kubernetes standard. Le funzionalità integrate di monitoraggio e ripristino automatico forniscono supporto operativo grazie all’agente di integrità AMI che rileva gli errori della GPU dai log del kernel e può correggere automaticamente i problemi o sostituire i nodi difettosi nei gruppi di nodi gestiti. Questa combinazione di scalabilità GPU, posizionamento intelligente dei carichi di lavoro e operazioni automatizzate ti aiuta a concentrarti sulle AI/ML innovazioni anziché sulla complessità dell'infrastruttura, ottenendo al contempo le massime prestazioni dagli investimenti in GPU.
Per eseguire la configurazione UltraServers con il HyperPod cluster, segui i seguenti passaggi:
1. Crea un cluster [basato su EKS HyperPod ](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-eks-operate-console-ui-create-cluster.html). Quando scegli un gruppo di istanze, assicurati di scegliere un. UltraServer
1. Dopo aver creato il cluster, utilizza i comandi seguenti per installare i plugin operativi:
Plugin per dispositivi NVIDIA v0.17.2
```
kubectl apply -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/v0.17.2/deployments/static/nvidia-device-plugin.yml
```
FD DaemonSet v0.17.3
```
kubectl apply -k "https://github.com/kubernetes-sigs/node-feature-discovery/deployment/overlays/default?ref=v0.17.3"
```
Rilevamento delle funzionalità della GPU
```
kubectl apply -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/v0.17.2/deployments/static/gpu-feature-discovery-daemonset.yaml
```
Ora puoi eseguire processi. Nell’esempio seguente viene illustrato come creare un dominio, configurare un dominio IMEX e abilitare l’allocazione dei canali. Queste fasi consentono inoltre di creare un pod per allocare un canale per la comunicazione NCCL.
1. Crea un file con le specifiche delle risorse da utilizzare con Kubectl.
```
cat < imex-channel-injection.yaml
---
apiVersion: resource.nvidia.com/v1beta1
kind: ComputeDomain
metadata:
name: imex-channel-injection
spec:
numNodes: 1
channel:
resourceClaimTemplate:
name: imex-channel-0
---
apiVersion: v1
kind: Pod
metadata:
name: imex-channel-injection
spec:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: nvidia.com/gpu.clique
operator: Exists
- key: topology.k8s.aws/ultraserver-id
operator: In
values:
-
containers:
- name: ctr
image: ubuntu:22.04
command: ["bash", "-c"]
args: ["ls -la /dev/nvidia-caps-imex-channels; trap 'exit 0' TERM; sleep 9999 & wait"]
resources:
claims:
- name: imex-channel-0
resourceClaims:
- name: imex-channel-0
resourceClaimTemplateName: imex-channel-0
EOF
```
1. Applica la configurazione che hai creato.
```
kubectl apply -f imex-channel-injection.yaml
```
1. Esegui i comandi `get pods` per verificare che il pod sia stato creato.
```
kubectl get pods
kubectl get pods -n nvidia-dra-driver-gpu -l resource.nvidia.com/computeDomain
```
1. Puoi anche controllare i log del pod per vedere se ha allocato un canale di comunicazione.
```
kubectl logs imex-channel-injection
```
```
total 0
drwxr-xr-x 2 root root 60 Feb 19 10:43 .
drwxr-xr-x 6 root root 380 Feb 19 10:43 ..
crw-rw-rw- 1 root root 507, 0 Feb 19 10:43 channel0
```
1. Puoi anche controllare i log per verificare che la configurazione IMEX automatizzata sia in esecuzione con un canale allocato.
```
kubectl logs -n nvidia-dra-driver-gpu -l resource.nvidia.com/computeDomain --tail=-1
/etc/nvidia-imex/nodes_config.cfg:
```
```
IMEX Log initializing at: 8/8/2025 14:23:12.081
[Aug 8 2025 14:23:12] [INFO] [tid 39] IMEX version 570.124.06 is running with the following configuration options
[Aug 8 2025 14:23:12] [INFO] [tid 39] Logging level = 4
[Aug 8 2025 14:23:12] [INFO] [tid 39] Logging file name/path = /var/log/nvidia-imex.log
[Aug 8 2025 14:23:12] [INFO] [tid 39] Append to log file = 0
[Aug 8 2025 14:23:12] [INFO] [tid 39] Max Log file size = 1024 (MBs)
[Aug 8 2025 14:23:12] [INFO] [tid 39] Use Syslog file = 0
[Aug 8 2025 14:23:12] [INFO] [tid 39] IMEX Library communication bind interface =
[JAug 8 2025 14:23:12] [INFO] [tid 39] IMEX library communication bind port = 50000
[Aug 8 2025 14:23:12] [INFO] [tid 39] Identified this node as ID 0, using bind IP of '10.115.131.8', and network interface of enP5p9s0
[Aug 8 2025 14:23:120] [INFO] [tid 39] nvidia-imex persistence file /var/run/nvidia-imex/persist.dat does not exist. Assuming no previous importers.
[Aug 8 2025 14:23:12] [INFO] [tid 39] NvGpu Library version matched with GPU Driver version
[Aug 8 2025 14:23:12] [INFO] [tid 63] Started processing of incoming messages.
[Aug 8 2025 14:23:12] [INFO] [tid 64] Started processing of incoming messages.
[Aug 8 2025 14:23:12] [INFO] [tid 65] Started processing of incoming messages.
[Aug 8 2025 14:23:12] [INFO] [tid 39] Creating gRPC channels to all peers (nPeers = 1).
[Aug 8 2025 14:23:12] [INFO] [tid 66] Started processing of incoming messages.
[Aug 8 2025 14:23:12] [INFO] [tid 39] IMEX_WAIT_FOR_QUORUM != FULL, continuing initialization without waiting for connections to all nodes.
[Aug 8 2025 14:23:12] [INFO] [tid 67] Connection established to node 0 with ip address 10.115.131.8. Number of times connected: 1
[Aug 8 2025 14:23:12] [INFO] [tid 39] GPU event successfully subscribed
```
1. Dopo aver verificato tutto, elimina il carico di lavoro e rimuovi la configurazione.
```
kubectl delete -f imex-channel-injection.yaml
```
# IDEs e notebook
Amazon SageMaker sta introducendo una nuova funzionalità per i cluster SageMaker HyperPod EKS, che consente agli sviluppatori di intelligenza artificiale di eseguire i propri carichi di lavoro interattivi di machine learning direttamente sul cluster HyperPod EKS. Questa funzionalità introduce un nuovo componente aggiuntivo chiamato Amazon SageMaker Spaces, che consente agli sviluppatori di intelligenza artificiale di creare e gestire ambienti autonomi per l'esecuzione di notebook.
Gli amministratori possono utilizzare SageMaker HyperPod Console per installare il componente aggiuntivo sul proprio cluster e definire configurazioni di spazio predefinite come immagini, risorse di elaborazione, archiviazione locale per le impostazioni dei notebook (spazio di archiviazione aggiuntivo da allegare agli spazi di sviluppo), file system e script di inizializzazione. Sarà disponibile un'opzione di installazione con un clic con impostazioni predefinite per semplificare l'esperienza di amministrazione. Gli amministratori possono utilizzare SageMaker HyperPod Console, kubectl o HyperPod CLI per installare l'operatore, creare impostazioni predefinite e gestire tutti gli spazi in una posizione centralizzata.
Gli sviluppatori di intelligenza artificiale possono utilizzare la HyperPod CLI per creare, aggiornare ed eliminare spazi di sviluppo. Hanno la flessibilità di utilizzare le configurazioni predefinite fornite dagli amministratori o personalizzare le impostazioni. Gli sviluppatori di intelligenza artificiale possono accedere ai propri spazi HyperPod utilizzando il codice VS locale IDEs, and/or il browser Web che ospita il proprio JupyterLab CodeEditor IDE su un dominio DNS personalizzato configurato dai propri amministratori. Possono anche utilizzare la funzionalità di port forwarding di Kubernetes per accedere agli spazi nei loro browser web.
## Admin
+ [Impostazione delle autorizzazioni](permission-setup.md)
+ [Installa il componente aggiuntivo SageMaker AI Spaces](operator-install.md)
+ [Personalizza il componente aggiuntivo](customization.md)
+ [Aggiungere utenti e configurare account di servizio](add-user.md)
+ [Limits](ds-limits.md)
+ [Gestione delle attività per Interactive Spaces su HyperPod](task-governance.md)
+ [Osservabilità](observability.md)
## Data Scientist
+ [Crea e gestisci spazi](create-manage-spaces.md)
+ [Accesso tramite browser Web](browser-access.md)
+ [Accesso remoto a SageMaker Spaces](vscode-access.md)
## SageMaker Prezzi delle istanze Spaces Managed
Il componente SageMaker aggiunto/operatore di Spaces non comporta alcun costo aggiuntivo per il cliente. Tuttavia, per supportare il SSH-over-SSM tunneling richiesto per la funzionalità di *connessione IDE remota*, Spaces utilizza un'istanza gestita. SageMaker AWS Questa istanza è registrata come istanza avanzata on-premise in SSM e pertanto viene fatturata per ora di elaborazione.
[Consulta la tariffa «On-Premises Instance Management» nella pagina dei prezzi di AWS Systems Manager: AWS Systems Manager Pricing: pricing/ https://aws.amazon.com/systems-manager/](https://aws.amazon.com/systems-manager/pricing.com)
# Impostazione delle autorizzazioni
## Ruoli richiesti per Add-on e relative dipendenze
### Ruoli IAM richiesti per SageMaker Spaces on SageMaker HyperPod
Quando si abilitano le funzionalità di **SageMaker Spaces (alias SageMaker ** **IDE/Notebooks)** su un cluster SageMaker HyperPod (EKS), è necessario creare e assegnare diversi ruoli IAM. Questi ruoli supportano l'accesso sicuro, il routing, le sessioni IDE remote e il provisioning dello storage EBS. La tabella seguente riassume i quattro ruoli e quando sono richiesti.
### Tabella riassuntiva dei ruoli
| Ruolo IAM | Obbligatorio? | Scopo | Chi lo usa? | Personalizzazione consentita dalla SageMaker console? |
| --- | --- | --- | --- | --- |
| Ruolo di esecuzione del componente aggiuntivo Spaces | Sempre richiesto | Consente al controller Spaces di gestire Spaces, generare sessioni SSM predefinite URLs e gestire sessioni SSM | Pod controller aggiuntivo (privilegiato) | ✔ Sì |
| Ruolo del router all'interno del cluster | Necessario per l'accesso WebUI | Consente al pod del router di eseguire operazioni KMS per la firma JWT (autenticazione WebUI) | Pod router interno al cluster (privilegiato) | ✔ Sì |
| Ruolo dell'istanza gestita SSM | Necessario per l'accesso remoto all'IDE | Utilizzato da SSM Agent Sidecar per sessioni IDE SSH-over-SSM remote | SSM Agent in Space IDE Pods (non un pod aggiuntivo) | ✔ Sì |
| Componente aggiuntivo IAM Role for EBS CSI Driver | Sempre richiesto | Consente a EBS CSI Driver di eseguire create/attach/modify volumi per i carichi di lavoro di Spaces | Componente aggiuntivo EBS CSI Driver | Creato automaticamente |
| Componente aggiuntivo IAM Role for External DNS | Necessario per l'accesso WebUI | Garantisce che agli endpoint Space e ai componenti del cluster possano essere assegnati automaticamente nomi DNS nelle zone ospitate Route 53 del cliente. | Componente aggiuntivo DNS esterno | Creato automaticamente |
### 1. Ruolo di esecuzione del componente aggiuntivo Spaces (obbligatorio)
Il ruolo di esecuzione del componente aggiuntivo Spaces è sempre richiesto perché viene utilizzato dal pod controller del componente aggiuntivo SageMaker Spaces, un componente amministrativo installato tramite il componente aggiuntivo EKS. Questo ruolo consente al controller di gestire gli spazi, fornire risorse, interagire con SSM e generare predefiniti URLs per l'accesso remoto all'IDE e al WebUI. Supporta anche l'accesso KMS utilizzato per la firma delle richieste per l'autenticazione delle richieste https WebUI. Questo ruolo può essere creato automaticamente quando il componente aggiuntivo SageMaker Spaces viene installato tramite la console. SageMaker Per la creazione manuale, AWS fornisce la policy `AmazonSageMakerSpacesControllerPolicy` gestita.
**Politica di fiducia di riferimento**
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "pods.eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
],
"Condition": {
"StringEquals": {
"aws:SourceAccount": "{{accountId}}",
"aws:SourceArn": "arn:aws:eks:{{region}}:{{accountId}}:cluster/{{eksClusterName}}"
}
}
}
]
}
```
### 2. Ruolo In-Cluster Router (richiesto per l'autenticazione WebUI)
Il ruolo In-Cluster Router viene utilizzato dal **router pod**, un componente privilegiato che autentica le sessioni WebUI di Spaces. Il router utilizza una chiave KMS per creare e firmare token JWT che autorizzano l'accesso degli utenti a spazi specifici. Questo ruolo consente al router pod di generare chiavi dati e decrittografarle. Analogamente al ruolo del controller, impone la sicurezza utilizzando restrizioni di ambito basate su tag e cluster. Questo ruolo può essere generato automaticamente quando il componente aggiuntivo Spaces viene installato tramite la AWS SageMaker console, ma i clienti possono crearlo manualmente.
**Politica di fiducia di riferimento**
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "pods.eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
],
"Condition": {
"StringEquals": {
"aws:SourceAccount": "{{accountId}}",
"aws:SourceArn": "arn:aws:eks:{{region}}:{{accountId}}:cluster/{{eksClusterName}}"
}
}
}
]
}
```
**Politica di autorizzazione di riferimento**
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "KMSDescribeKey",
"Effect": "Allow",
"Action": [
"kms:DescribeKey"
],
"Resource": "arn:aws:kms:{{region}}:{{accountId}}:key/{{kmsKeyId}}"
},
{
"Sid": "KMSKeyOperations",
"Effect": "Allow",
"Action": [
"kms:GenerateDataKey",
"kms:Decrypt"
],
"Resource": "arn:aws:kms:{{region}}:{{accountId}}:key/{{kmsKeyId}}",
"Condition": {
"StringEquals": {
"kms:EncryptionContext:sagemaker:component": "amazon-sagemaker-spaces",
"kms:EncryptionContext:sagemaker:eks-cluster-arn": "${aws:PrincipalTag/eks-cluster-arn}"
}
}
}
]
}
```
### 3. Ruolo dell'istanza gestita SSM (richiesto per l'accesso IDE remoto)
Il ruolo dell'istanza gestita SSM viene passato al momento della registrazione dell'istanza gestita SSM per abilitare l'accesso IDE remoto. Questo ruolo consente all'agente SSM di registrare il pod come istanza gestita SSM e utilizzare i canali SSM Session Manager per la connettività IDE remota (SSH-over-SSM). Può essere creato automaticamente quando si utilizza la console. AWS SageMaker Per le distribuzioni manuali, i clienti devono creare questo ruolo e fornirlo al componente aggiuntivo Spaces. Il controller pod di per sé non assume questo ruolo, ma lo fornisce solo durante la chiamata. `ssm:CreateActivation`
**Politica di fiducia di riferimento**
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "ssm.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "{{account}}"
},
"ArnEquals": {
"aws:SourceArn": "arn:aws:ssm:{{region}}:{{account}}:*"
}
}
}
]
}
```
**Politica sulle autorizzazioni di riferimento**
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:DescribeAssociation"
],
"Resource": [
"arn:aws:ssm:{{region}}:{{account}}:association/*",
"arn:aws:ssm:{{region}}:{{account}}:document/*",
"arn:aws:ec2:{{region}}:{{account}}:instance/*",
"arn:aws:ssm:{{region}}:{{account}}:managed-instance/*"
]
},
{
"Effect": "Allow",
"Action": [
"ssm:GetDocument",
"ssm:DescribeDocument"
],
"Resource": "arn:aws:ssm:{{region}}:{{account}}:document/*"
},
{
"Effect": "Allow",
"Action": [
"ssm:GetParameter",
"ssm:GetParameters"
],
"Resource": "arn:aws:ssm:{{region}}:{{account}}:parameter/*"
},
{
"Effect": "Allow",
"Action": [
"ssm:ListInstanceAssociations"
],
"Resource": [
"arn:aws:ec2:{{region}}:{{account}}:instance/*",
"arn:aws:ssm:{{region}}:{{account}}:managed-instance/*"
]
},
{
"Effect": "Allow",
"Action": [
"ssm:PutComplianceItems"
],
"Resource": [
"arn:aws:ec2:{{region}}:{{account}}:instance/*",
"arn:aws:ssm:{{region}}:{{account}}:managed-instance/*"
]
},
{
"Effect": "Allow",
"Action": [
"ssm:UpdateAssociationStatus"
],
"Resource": [
"arn:aws:ssm:{{region}}:{{account}}:document/*",
"arn:aws:ec2:{{region}}:{{account}}:instance/*",
"arn:aws:ssm:{{region}}:{{account}}:managed-instance/*"
]
},
{
"Effect": "Allow",
"Action": [
"ssm:UpdateInstanceAssociationStatus"
],
"Resource": [
"arn:aws:ssm:{{region}}:{{account}}:association/*",
"arn:aws:ec2:{{region}}:{{account}}:instance/*",
"arn:aws:ssm:{{region}}:{{account}}:managed-instance/*"
]
},
{
"Effect": "Allow",
"Action": [
"ssm:UpdateInstanceInformation"
],
"Resource": [
"arn:aws:ec2:{{region}}:{{account}}:instance/*",
"arn:aws:ssm:{{region}}:{{account}}:managed-instance/*"
]
},
{
"Effect": "Allow",
"Action": [
"ssm:GetDeployablePatchSnapshotForInstance",
"ssm:GetManifest",
"ssm:ListAssociations",
"ssm:PutInventory",
"ssm:PutConfigurePackageResult"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ssmmessages:CreateControlChannel",
"ssmmessages:CreateDataChannel",
"ssmmessages:OpenControlChannel",
"ssmmessages:OpenDataChannel"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ec2messages:AcknowledgeMessage",
"ec2messages:DeleteMessage",
"ec2messages:FailMessage",
"ec2messages:GetEndpoint"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ec2messages:GetMessages",
"ec2messages:SendReply"
],
"Resource": "*",
"Condition": {
"ArnLike": {
"ssm:SourceInstanceARN": "arn:aws:ssm:{{region}}:{{account}}:managed-instance/*"
}
}
}
]
}
```
### 4. Componente aggiuntivo IAM Role for EBS CSI Driver
Il ruolo IAM per il driver CSI EBS è necessario perché il driver CSI EBS fornisce volumi persistenti per i carichi di lavoro di Spaces. Sebbene la [Amazon EBSCSIDriver Policy AWS](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEBSCSIDriverPolicy.html) gestita fornisca autorizzazioni di base, SageMaker HyperPod i cluster richiedono [funzionalità aggiuntive](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-eks-ebs.html#sagemaker-hyperpod-eks-ebs-setup) come la creazione di ripristini rapidi di snapshot, l'etichettatura dei volumi di proprietà del cluster e dei volumi per i nodi gestiti. attaching/detaching HyperPod Queste SageMaker APIs `sagemaker:AttachClusterNodeVolume` autorizzazioni includono anche autorizzazioni specifiche come. **Se il driver EBS CSI non è installato, questo ruolo verrà ora creato automaticamente dalla SageMaker Console durante l'installazione del componente aggiuntivo Spaces, senza richiedere alcuna azione da parte del cliente.**
### 5. Componente aggiuntivo IAM Role for External DNS
Il componente aggiuntivo DNS esterno gestisce i record DNS per le risorse Services e Ingress sul cluster. HyperPod Garantisce che agli endpoint Space e ai componenti del cluster possano essere assegnati automaticamente nomi DNS nelle zone ospitate Route 53 del cliente. Oggi, i clienti spesso installano il DNS esterno manualmente tramite un'opzione con 1 clic nella console EKS. Come parte del miglioramento dell'esperienza di SageMaker Spaces, questo ruolo verrà ora creato automaticamente dalla SageMaker console durante l'installazione del componente aggiuntivo Spaces, **senza richiedere alcuna** azione da parte del cliente.
## Configurazione delle autorizzazioni per AWS Toolkit to Access Spaces SageMaker
Per consentire al pannello laterale di esplorazione delle risorse di AWS VS Code Toolkit di rilevare e connettersi a SageMaker Spaces, sono necessarie le seguenti autorizzazioni IAM. Queste autorizzazioni consentono al Toolkit di elencare SageMaker HyperPod i cluster disponibili, recuperare i dettagli del cluster e ottenere un token di connessione per il cluster Amazon EKS associato.
**Policy IAM richiesta**
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "SageMakerListClusters",
"Effect": "Allow",
"Action": "sagemaker:ListClusters",
"Resource": "*"
},
{
"Sid": "SageMakerDescribeCluster",
"Effect": "Allow",
"Action": "sagemaker:DescribeCluster",
"Resource": "arn:aws:sagemaker:{{region}}:{{account}}:cluster/cluster-name"
},
{
"Sid": "EksDescribeCluster",
"Effect": "Allow",
"Action": "eks:DescribeCluster",
"Resource": "arn:aws:eks:{{region}}:{{account}}:cluster/cluster-name"
},
{
"Sid": "EksGetToken",
"Effect": "Allow",
"Action": "eks:GetToken",
"Resource": "*"
}
]
}
```
**Raccomandazioni per l'ambito**
+ Sostituisci il nome del cluster con i SageMaker HyperPod cluster specifici a cui gli utenti devono accedere.
+ L'GetToken azione eks: attualmente non supporta le restrizioni a livello di risorsa e deve utilizzare Resource: «\$1». Questa è una limitazione del servizio. AWS L'autenticazione lato client viene eseguita tramite le [voci di accesso EKS](https://docs.aws.amazon.com/eks/latest/userguide/access-entries.html).
# Installa il componente aggiuntivo SageMaker AI Spaces
## Dipendenze
**Componente aggiuntivo Amazon EKS Pod Identity Agent**
+ Richiesto all'operatore per ottenere AWS le credenziali
+ **In genere preinstallato** sulla maggior parte dei cluster EKS
+ Installazione: tramite componenti aggiuntivi EKS
**CERT-manager**
+ Necessario per la gestione dei certificati TLS
+ **Preinstallato** se si utilizza la creazione HyperPod rapida del cluster
+ Installazione: tramite componenti aggiuntivi EKS
**Driver CSI EBS**
+ Necessario per lo storage persistente Space (volumi EBS)
+ **Installato automaticamente** quando si utilizza la SageMaker console per l'installazione
+ Richiede un ruolo IAM con `AmazonEBSCSIDriverPolicy` HyperPod autorizzazioni specifiche per \$1
+ Installazione: tramite componenti aggiuntivi EKS. Tuttavia, assicurati di seguire la guida per installare le autorizzazioni aggiuntive necessarie per. HyperPod
+ Riferimento: [utilizzo del driver CSI Amazon EBS](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-eks-ebs.html) su HyperPod
## Dipendenze aggiuntive per WebUI Access
**AWS Controller Load Balancer**
+ **Preinstallato** se si utilizza la creazione HyperPod rapida del cluster
+ Installazione: Via Helm
+ Guida all'installazione manuale: [installazione del AWS Load Balancer Controller](https://docs.aws.amazon.com/eks/latest/userguide/lbc-helm.html)
**DNS esterno**
+ Richiesto quando si utilizza un dominio personalizzato per l'accesso WebUI
+ Gestisce automaticamente i record DNS di Route53
+ Richiede un ruolo IAM con autorizzazioni Route53
+ Installazione: tramite componenti aggiuntivi EKS
## Installazione
Prima di iniziare, assicurati di avere:
+ Un SageMaker HyperPod cluster attivo con almeno un nodo di lavoro che esegue Kubernetes versione 1.30 o successiva
+ Almeno un nodo di lavoro con tipo minimo di istanza (XX vCPU, memoria YY GiB)
### Installazione del componente aggiuntivo Amazon SageMaker Spaces
Puoi installare il componente aggiuntivo SageMaker Spaces utilizzando l'installazione rapida per le impostazioni predefinite o l'installazione personalizzata per la configurazione avanzata.
#### Installazione rapida
1. Apri la SageMaker console Amazon all'indirizzo [https://console.aws.amazon.com/sagemaker/](https://console.aws.amazon.com/sagemaker/).
1. Scegli il tuo cluster dall'elenco dei cluster.
1. Nella scheda IDE e notebook, individua Amazon SageMaker Spaces, quindi scegli Installazione rapida.
Installazione rapida automatica:
+ Crea i ruoli IAM richiesti per il componente aggiuntivo
+ Abilita la modalità di accesso remoto con i ruoli IAM richiesti per Systems Manager
+ Installa il componente aggiuntivo e configura l'associazione delle identità dei pod
#### Installazione personalizzata
1. Apri la SageMaker console Amazon all'indirizzo [https://console.aws.amazon.com/sagemaker/](https://console.aws.amazon.com/sagemaker/).
1. Scegli il tuo cluster dall'elenco dei cluster.
1. Nella scheda IDE e notebook, individua Amazon SageMaker Spaces, quindi scegli Installazione personalizzata.
1. Configura le opzioni seguenti:
**Ruoli IAM necessari per il componente aggiuntivo**
+ Scegli se creare nuovi ruoli IAM con le autorizzazioni consigliate o utilizzare quelli esistenti con le autorizzazioni richieste (consulta la sezione sulla configurazione delle autorizzazioni degli amministratori sopra riportata)
**Configurazione dell'accesso remoto**
+ Abilita per consentire agli utenti di connettersi agli spazi dal codice di Visual Studio locale utilizzando AWS Systems Manager
+ Per il ruolo dell'istanza gestita SSM:
+ **Crea nuovo ruolo**: il componente aggiuntivo crea e gestisce il ruolo con le autorizzazioni di Systems Manager richieste
+ **Usa il ruolo esistente**: seleziona un ruolo preconfigurato con le autorizzazioni necessarie di Systems Manager
+ Assicurati che il ruolo di esecuzione del componente aggiuntivo di Spaces disponga PassRole delle autorizzazioni per il ruolo dell'istanza gestita SSM
**Nota**
L'abilitazione dell'accesso remoto attiva il livello Advanced Instances di AWS Systems Manager per costi aggiuntivi per istanza. Per informazioni sui prezzi, consulta la pagina dei prezzi di Systems Manager.
**Configurazione dell'accesso tramite browser Web**
+ Abilita per consentire agli utenti di accedere agli spazi tramite un browser Web utilizzando i certificati DNS e SSL Route 53
+ **Prerequisiti:** installare AWS Load Balancer Controller prima di abilitare l'accesso al browser
+ **Zona ospitata Route 53:** seleziona una zona ospitata esistente per un dominio o sottodominio di tua proprietà. Il dominio o il sottodominio deve essere registrato e sotto il tuo controllo per abilitare la gestione DNS e la convalida del certificato SSL.
Per maggiori dettagli sulla registrazione del dominio, consulta [Registrazione di un nuovo dominio](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/domain-register.html#domain-register-procedure-section) nella Route 53 Developer Guide.
+ **Sottodominio:** inserisci il prefisso del sottodominio (solo caratteri alfanumerici e trattini, massimo 63 caratteri)
+ Certificato **SSL: seleziona un certificato** SSL esistente da AWS Certificate Manager. Il certificato deve essere valido e coprire sia il sottodominio (ad esempio, subdomain.domain.com) che i sottodomini wildcard (ad es. \$1.subdomain.domain.com) per supportare l'accesso individuale allo spazio. URLs
+ **Chiave** di AWS firma con token: seleziona una chiave asimmetrica KMS per la firma con token JWT. La chiave viene utilizzata per crittografare i token di autenticazione per un accesso sicuro al WebUI. Puoi creare una nuova chiave asimmetrica in KMS o selezionarne una esistente a cui il tuo account ha accesso.
**Nota**
Per le zone ospitate e le query DNS si applicano le tariffe standard della Route 53. Per informazioni sui prezzi, consulta i prezzi di Route 53.
#### Installazione del componente aggiuntivo EKS - Jupyter K8s con WebUI
##### File di configurazione
Crea: `addon-config.yaml`
```
jupyter-k8s:
workspacePodWatching:
enable: true
jupyter-k8s-aws-hyperpod:
clusterWebUI:
enabled: true
domain: ""
awsCertificateArn: ""
kmsEncryptionContext:
enabled: true
traefik:
shouldInstall: true
auth:
kmsKeyId: ""
```
**Sostituisci i seguenti segnaposto:**
+ : Il tuo nome di dominio (ad esempio,) `jupyter.example.com`
+ : Il tuo certificato ACM ARN (ad es. `arn:aws:acm:us-west-2:111122223333:certificate/12345678-1234-1234-1234-123456789012`
+ : ARN della tua chiave KMS (ad es. `arn:aws:kms:us-west-2:111122223333:key/12345678-1234-1234-1234-123456789012`
##### Installazione tramite AWS CLI
```
aws eks create-addon \
--cluster-name \
--addon-name amazon-sagemaker-spaces \
--configuration-values file://addon-config.yaml \
--resolve-conflicts OVERWRITE \
--region
```
**Per aggiornare l'addon esistente:**
```
aws eks update-addon \
--cluster-name \
--addon-name amazon-sagemaker-spaces \
--configuration-values file://addon-config.yaml \
--resolve-conflicts OVERWRITE \
--region
```
##### Installazione tramite Console di gestione AWS
1. Vai alla **console EKS** → Seleziona il tuo cluster
1. Fai clic sulla scheda **Componenti aggiuntivi** → **Aggiungi nuovo**
1. Seleziona il componente aggiuntivo **SageMaker Spaces**
1. **Incolla la configurazione YAML riportata sopra nelle Impostazioni di configurazione opzionali**
1. Fai clic su **Avanti**, quindi rivedi le impostazioni del componente aggiuntivo
1. **Fai clic su Crea**
##### Verifica l'installazione
```
# Check addon status
aws eks describe-addon \
--cluster-name \
--addon-name amazon-sagemaker-spaces \
--region
```
##### Personalizzazione degli attributi ALB
Per impostazione predefinita, l'addon crea un sistema di bilanciamento del carico pubblico da utilizzare con l'interfaccia utente Web. È possibile personalizzare gli attributi del bilanciamento del carico utilizzando le proprietà del componente aggiuntivo EKS.
Per creare un ALB interno, imposta lo schema su: `internal`
```
jupyter-k8s-aws-hyperpod:
clusterWebUI:
enabled: true
domain: ""
awsCertificateArn: ""
alb:
scheme: "internal" # Default is "internet-facing"
```
Puoi anche usare il `alb.annotations` campo per personalizzare le impostazioni ALB:
```
jupyter-k8s-aws-hyperpod:
clusterWebUI:
enabled: true
domain: ""
awsCertificateArn: ""
alb:
scheme: "internal"
annotations:
alb.ingress.kubernetes.io/security-groups: ""
alb.ingress.kubernetes.io/subnets: ","
alb.ingress.kubernetes.io/load-balancer-attributes: "idle_timeout.timeout_seconds=60"
```
**Annotazioni ALB comuni:**
+ `alb.ingress.kubernetes.io/security-groups`: Specificare i gruppi di sicurezza per l'ALB
+ `alb.ingress.kubernetes.io/subnets`: Specificare le sottoreti per l'ALB
+ `alb.ingress.kubernetes.io/load-balancer-attributes`: imposta gli attributi ALB (timeout di inattività, registri di accesso, ecc.)
Consulta la [documentazione del AWS Load Balancer Controller per tutte le annotazioni](https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/guide/ingress/annotations/) disponibili.
### Aggiornamento/versionamento del componente aggiuntivo
```
aws eks update-addon \
--cluster-name \
--addon-name amazon-sagemaker-spaces \
--configuration-values file://addon-config.yaml \
--resolve-conflicts OVERWRITE \
--region
```
# Personalizza il componente aggiuntivo
## Modello
I modelli sono configurazioni di aree di lavoro riutilizzabili che fungono da modelli controllati dall'amministratore per la creazione di aree di lavoro. Forniscono impostazioni predefinite per i valori di configurazione dell'area di lavoro e protezioni per controllare cosa possono fare i data scientist. I modelli esistono a livello di cluster e possono essere riutilizzati in tutti i namespace.
SageMaker Spaces crea due modelli di sistema come punto di partenza per i data scientist, uno per Code Editor e uno per. JupyterLab Questi modelli di sistema sono gestiti dall'addon e non possono essere modificati direttamente. Gli amministratori possono invece creare nuovi modelli e impostarli come predefiniti.
## Governance delle attività
```
apiVersion: workspace.jupyter.org/v1alpha1
kind: WorkspaceTemplate
metadata:
name: my-jupyter-template
namespace: my-namespace
labels:
kueue.x-k8s.io/priority-class: -priority
spec:
displayName: "My Custom Jupyter Lab"
description: "Custom Jupyter Lab with specific configurations"
defaultImage: "public.ecr.aws/sagemaker/sagemaker-distribution:latest-cpu"
allowedImages:
- "public.ecr.aws/sagemaker/sagemaker-distribution:latest-cpu"
- "public.ecr.aws/sagemaker/sagemaker-distribution:latest-gpu"
defaultResources:
requests:
cpu: "1"
memory: "4Gi"
limits:
cpu: "4"
memory: "16Gi"
primaryStorage:
defaultSize: "10Gi"
minSize: "5Gi"
maxSize: "50Gi"
defaultStorageClassName: "sagemaker-spaces-default-storage-class"
defaultMountPath: "/home/sagemaker-user"
defaultContainerConfig:
command: ["/opt/amazon/sagemaker/workspace/bin/entrypoint-workspace-jupyterlab"]
defaultPodSecurityContext:
fsGroup: 1000
defaultOwnershipType: "Public"
defaultAccessStrategy:
name: "hyperpod-access-strategy"
allowSecondaryStorages: true
appType: "jupyterlab"
```
## SMD/Immagini personalizzate
I clienti possono configurare le politiche relative alle immagini tramite modelli fornendo un'immagine predefinita e un elenco di immagini consentite. Inoltre, gli amministratori possono scegliere se consentire ai data scientist di portare le proprie immagini personalizzate. Per impostazione predefinita, il sistema utilizza la SageMaker distribuzione più recente, ma se desideri aggiungere una versione specifica, puoi specificare l'esatta versione SMD da utilizzare in un modello.
Requisiti per immagini personalizzate:
+ `curl`se si desidera utilizzare lo spegnimento inattivo
+ porta 8888
+ accesso remoto
## Requisito IDE remoto
### Requisito per la versione di VS Code
È richiesta la versione VS Code [v1.90](https://code.visualstudio.com/updates/v1_90) o successiva. Consigliamo di utilizzare l’[ultima versione stabile di VS Code](https://code.visualstudio.com/updates).
### Requisiti del sistema operativo
Per connetterti in remoto agli spazi di Studio, devi disporre di uno dei seguenti sistemi operativi:
+ macOS 13\$1
+ Windows 10
+ [Il supporto per Windows 10 termina il 14 ottobre 2025](https://support.microsoft.com/en-us/windows/windows-10-support-ends-on-october-14-2025-2ca8b313-1946-43d3-b55c-2b95b107f281)
+ Windows 11
+ Linux
+ Installa il [Microsoft VS Code ufficiale per Linux](https://code.visualstudio.com/docs/setup/linux)
+ non è una versione open source
### Prerequisiti del computer locale
Prima di connettere il codice di Visual Studio locale agli spazi di Studio, assicurati che il computer locale disponga delle dipendenze e dell'accesso alla rete richiesti.
**Nota**
Gli ambienti con restrizioni all'installazione del software possono impedire agli utenti di installare le dipendenze richieste. Il AWS Toolkit for Visual Studio Code cerca automaticamente queste dipendenze all'avvio delle connessioni remote e richiederà l'installazione se ne mancano alcune. Coordinatevi con il vostro reparto IT per garantire la disponibilità di questi componenti.
**Dipendenze locali richieste**
Sul computer locale devono essere installati i seguenti componenti:
+ **[https://code.visualstudio.com/docs/remote/ssh](https://code.visualstudio.com/docs/remote/ssh)**
+ — Estensione standard di VS Code Marketplace per lo sviluppo remoto
+ **[Plugin Session Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-working-with-install-plugin.html)**: necessario per la gestione sicura delle sessioni
+ **Client SSH**: componente standard sulla maggior parte delle macchine ([OpenSSH consigliato](https://learn.microsoft.com/en-us/windows-server/administration/openssh/openssh_install_firstuse) per Windows)
+ **[https://code.visualstudio.com/docs/configure/command-line](https://code.visualstudio.com/docs/configure/command-line)**
+ In genere incluso nell'installazione di VS Code
**Requisiti specifici della piattaforma**
+ **Utenti Windows**: per le connessioni ai terminali SSH è richiesta la versione PowerShell 5.1 o successiva
**Requisiti per la connettività**
Il computer locale deve avere accesso di rete agli [endpoint di Session Manager](https://docs.aws.amazon.com/general/latest/gr/ssm.html). Ad esempio, negli Stati Uniti orientali (Virginia settentrionale) (us-east-1) questi possono essere:
+ `[ssm.us-east-1.amazonaws.com](http://ssm.us-east-1.amazonaws.com)`
+ `ssm.us-east-1.api.aws`
+ `[ssmmessages.us-east-1.amazonaws.com](http://ssmmessages.us-east-1.amazonaws.com)`
+ `[ec2messages.us-east-1.amazonaws.com](http://ec2messages.us-east-1.amazonaws.com)`
### Requisiti delle immagini
**SageMaker Immagini di distribuzione**
Quando si utilizza SageMaker Distribution con accesso remoto, utilizzare [SageMaker Distribution](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-distribution.html) versione 2.7 o successiva.
**Immagini personalizzate**
Quando utilizzi [Bring your own image (BYOI)](https://docs.aws.amazon.com/sagemaker/latest/dg/studio-updated-byoi.html) con accesso remoto, assicurati di seguire le [specifiche personalizzate dell'immagine](https://docs.aws.amazon.com/sagemaker/latest/dg/studio-updated-byoi-specs.html) e assicurati che siano installate le seguenti dipendenze:
+ `curl`o `wget` — Necessario per scaricare i componenti AWS CLI
+ `unzip`— Necessario per estrarre i file AWS CLI di installazione
+ `tar`— Necessario per l'estrazione dell'archivio
+ `gzip`— Necessario per la gestione di file compressi
### Requisiti per l’istanza
+ **Memoria**: almeno 8 GB
+ Utilizza istanze con almeno 8 GB di memoria. I seguenti tipi di istanze *non* sono supportati a causa della memoria insufficiente (meno di 8 GB): `ml.t3.medium`, `ml.c7i.large`, `ml.c6i.large`, `ml.c6id.large` e `ml.c5.large`. Per un elenco più completo dei tipi di istanze, consulta la pagina dei [prezzi on demand di Amazon EC2](https://aws.amazon.com/ec2/pricing/on-demand/)
## Ottimizzazione del tempo di avvio di Kubernetes preriscaldando le immagini dei container
Le prestazioni di acquisizione delle immagini dei container sono diventate un ostacolo significativo per molti clienti EKS, soprattutto perché i carichi di lavoro si basano su immagini di container sempre più AI/ML grandi. L'estrazione e il disimballaggio di queste immagini di grandi dimensioni richiedono in genere diversi minuti la prima volta che vengono utilizzate su ciascun nodo EKS. Questo ritardo aggiunge una notevole latenza all'avvio di SageMaker Spaces e influisce direttamente sull'esperienza utente, in particolare in ambienti in cui l'avvio rapido è essenziale, come notebook e processi di sviluppo interattivi.
Il preriscaldamento delle immagini è una tecnica utilizzata per precaricare immagini di container specifiche su ogni nodo del cluster prima che siano necessarie. EKS/HyperPod Invece di aspettare che un pod attivi la prima estrazione di un'immagine di grandi dimensioni, il cluster scarica e memorizza in modo proattivo le immagini su tutti i nodi. Ciò garantisce che all'avvio dei carichi di lavoro, le immagini richieste siano già disponibili localmente, eliminando i lunghi ritardi di avvio a freddo. Il preriscaldamento delle immagini migliora la velocità di avvio di SageMaker Spaces e offre un'esperienza più prevedibile e reattiva per gli utenti finali.
### Preriscaldamento tramite DaemonSet
Si consiglia di utilizzare un DaemonSet per precaricare le immagini. A DaemonSet garantisce che un pod venga eseguito su ogni nodo del cluster. Ogni contenitore all'interno del DaemonSet pod fa riferimento a un'immagine che si desidera memorizzare nella cache. Quando Kubernetes avvia il pod, estrae automaticamente le immagini, riscaldando la cache su ogni nodo.
L'esempio seguente mostra come creare un file DaemonSet che precarica due immagini GPU. Ogni contenitore esegue un `sleep infinity` comando leggero per mantenere attivo il pod con un sovraccarico minimo.
```
cat <
+ Ogni contenitore fa riferimento a un'immagine.
+ Kubernetes deve scaricare ogni immagine prima di avviare il contenitore.
+ Una volta che il pod è in esecuzione su ogni nodo, le immagini vengono memorizzate nella cache locale.
+ Qualsiasi carico di lavoro che utilizza queste immagini ora inizia molto più velocemente.
## Space Default Storage (EBS)
Per impostazione predefinita, il sistema utilizza il driver CSI EBS per eseguire il provisioning dei volumi di storage EBS per ogni area di lavoro. SageMaker crea una classe di archiviazione EBS da utilizzare con le aree di lavoro e gli amministratori possono personalizzare la dimensione predefinita e massima di questi volumi utilizzando le impostazioni del modello. Per gli utenti esperti che lavorano con gli strumenti CLI, puoi anche personalizzare la classe di archiviazione dell'area di lavoro, che consente agli utenti di sfruttare altre classi di archiviazione, inclusa la configurazione di chiavi KMS gestite dal cliente per i propri volumi EBS.
Tieni presente che i volumi EBS sono associati a una particolare AZ, il che significa che le aree di lavoro possono essere pianificate solo su nodi nella stessa AZ del volume di archiviazione. Ciò può portare a errori di pianificazione se la capacità del cluster esiste ma non nella zona di disponibilità corretta.
## Archiviazione aggiuntiva
SageMaker Spaces supporta il collegamento di volumi di storage aggiuntivi come Amazon EFS, FSx for Lustre o S3 Mountpoint ai tuoi spazi di sviluppo. Ciò ti consente di accedere a set di dati condivisi, collaborare a progetti o utilizzare storage ad alte prestazioni per i tuoi carichi di lavoro.
### Prerequisiti
Prima di aggiungere spazio di archiviazione aggiuntivo agli spazi, devi:
1. **Installa il componente aggiuntivo del driver CSI appropriato tramite componenti aggiuntivi** [EKS (](https://docs.aws.amazon.com/eks/latest/userguide/workloads-add-ons-available-eks.html)Amazon EFS CSI Driver, Amazon FSx for Lustre CSI Driver o Mountpoint per Amazon S3 CSI Driver)
1. **Configura le risorse di storage e** segui la documentazione del driver CSI per il tuo tipo di storage PersistentVolumeClaims specifico
1. **Assicurati che il PVC sia disponibile** nello stesso namespace in cui intendi creare il tuo spazio
### Collegamento dello spazio di archiviazione agli spazi
Una volta PersistentVolumeClaim configurato, puoi collegarlo a uno spazio usando la HyperPod CLI o kubectl.
**HyperPod CLI**
```
hyp create hyp-space \
--name my-space \
--display-name "My Space with FSx" \
--memory 8Gi \
--volume name=shared-fsx,mountPath=/shared,persistentVolumeClaimName=my-fsx-pvc
```
**kubectl**
```
apiVersion: workspace.jupyter.org/v1alpha1
kind: Workspace
metadata:
name: my-space
spec:
displayName: "My Space with FSx"
desiredStatus: Running
volumes:
- name: shared-fsx
mountPath: /shared
persistentVolumeClaimName: my-fsx-pvc
```
### Volumi multipli
Puoi collegare più volumi di archiviazione aggiuntivi a un singolo spazio specificando più `--volume` flag con la CLI o più voci nell'array con kubectl. `volumes`
**HyperPod CLI**
```
hyp create hyp-space \
--name my-space \
--display-name "My Space with Multiple Storage" \
--memory 8Gi \
--volume name=shared-efs,mountPath=/shared,persistentVolumeClaimName=my-efs-pvc \
--volume name=datasets,mountPath=/datasets,persistentVolumeClaimName=my-s3-pvc
```
**kubectl**
```
apiVersion: workspace.jupyter.org/v1alpha1
kind: Workspace
metadata:
name: my-space
spec:
displayName: "My Space with Multiple Storage"
desiredStatus: Running
volumes:
- name: shared-efs
mountPath: /shared
persistentVolumeClaimName: my-efs-pvc
- name: datasets
mountPath: /datasets
persistentVolumeClaimName: my-s3-pvc
```
## Configurazione delle risorse
SageMaker Spaces ti consente di configurare le risorse di calcolo per i tuoi ambienti di sviluppo, tra cui CPU, memoria e GPU, per soddisfare i requisiti del carico di lavoro.
### Configurazione della GPU
SageMaker Spaces supporta sia l'allocazione dell'intera GPU che il partizionamento della GPU utilizzando la tecnologia NVIDIA Multi-Instance GPU (MIG). Ciò consente di ottimizzare l'utilizzo della GPU per diversi tipi di carichi di lavoro di machine learning.
#### Allocazione completa della GPU
**HyperPod CLI**
```
hyp create hyp-space \
--name gpu-space \
--display-name "GPU Development Space" \
--image public.ecr.aws/sagemaker/sagemaker-distribution:latest-gpu \
--memory 16Gi \
--gpu 1 \
--gpu-limit 1
```
**kubectl**
```
apiVersion: workspace.jupyter.org/v1alpha1
kind: Workspace
metadata:
name: gpu-space
spec:
displayName: "GPU Development Space"
image: "public.ecr.aws/sagemaker/sagemaker-distribution:latest-gpu"
desiredStatus: Running
resources:
requests:
memory: "16Gi"
nvidia.com/gpu: "1"
limits:
memory: "16Gi"
nvidia.com/gpu: "1"
```
#### Partizionamento GPU (MIG)
Il partizionamento della GPU con la tecnologia NVIDIA Multi-Instance GPU (MIG) consente di partizionare una singola GPU in istanze più piccole e isolate. Il HyperPod cluster deve avere nodi GPU che supportano MIG e avere profili MIG configurati. Per ulteriori informazioni sulla configurazione MIG sul HyperPod cluster, consulta Partizionamento della [GPU](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-eks-gpu-partitioning-setup.html) con NVIDIA MIG.
**HyperPod CLI**
```
hyp create hyp-space \
--name mig-space \
--display-name "MIG GPU Space" \
--image public.ecr.aws/sagemaker/sagemaker-distribution:latest-gpu \
--memory 8Gi \
--accelerator-partition-type mig-3g.20gb \
--accelerator-partition-count 1
```
**kubectl**
```
apiVersion: workspace.jupyter.org/v1alpha1
kind: Workspace
metadata:
name: mig-space
spec:
displayName: "MIG GPU Space"
image: "public.ecr.aws/sagemaker/sagemaker-distribution:latest-gpu"
desiredStatus: Running
resources:
requests:
memory: "8Gi"
nvidia.com/mig-3g.20gb: "1"
limits:
memory: "8Gi"
nvidia.com/mig-3g.20gb: "1"
```
## Ciclo di vita
La configurazione del ciclo di vita fornisce script di avvio che vengono eseguiti quando viene creato o avviato uno spazio di lavoro. Questi script consentono agli amministratori di personalizzare l'ambiente dell'area di lavoro durante l'avvio. Si tratta di script bash con una dimensione massima di 1 KB. Se hai bisogno di una configurazione di configurazione più ampia, ti consigliamo di aggiungere uno script all'immagine del contenitore e di attivare lo script dalla configurazione del ciclo di vita.
[Utilizziamo gli hook del ciclo di vita dei container Kubernetes per fornire questa funzionalità https://kubernetes. io/docs/concepts/containers/container-lifecycle-hooks/.](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/) Tieni presente che Kubernetes non fornisce garanzie su quando lo script di avvio verrà eseguito in relazione al punto di ingresso del contenitore.
## Spegnimento in modalità inattiva
Configura lo spegnimento automatico delle aree di lavoro inattive per ottimizzare l'utilizzo delle risorse.
### Spegnimento in modalità inattiva
```
idleShutdown:
enabled: true
idleShutdownTimeoutMinutes: 30
detection:
httpGet:
path: /api/idle
port: 8888
scheme: HTTP
```
### Parameters
**abilitato** (booleano, obbligatorio): abilita o disabilita lo spegnimento inattivo per l'area di lavoro.
**idleShutdownTimeoutMinuti** (numeri interi, obbligatori): numero di minuti di inattività prima della chiusura dell'area di lavoro. Il valore minimo è 1.
**rilevamento** (oggetto, obbligatorio): definisce come rilevare lo stato di inattività dell'area di lavoro.
**detection.httpGet** (oggetto, opzionale) - Configurazione dell'endpoint HTTP per il rilevamento delle attività inattive. Utilizza la specifica HTTPGet Kubernetes Action.
+ **path: percorso** HTTP da richiedere
+ **port** - Numero o nome della porta
+ **schema** - HTTP o HTTPS (impostazione predefinita: HTTP)
### Posizioni di configurazione
**Configurazione dell'area di lavoro**
Definisci lo spegnimento inattivo direttamente nelle specifiche dell'area di lavoro:
```
apiVersion: workspace.jupyter.org/v1alpha1
kind: Workspace
metadata:
name: my-workspace
spec:
displayName: "Development Workspace"
image:
jupyter/scipy-notebook:latest
idleShutdown:
enabled: true
idleShutdownTimeoutMinutes: 30
detection:
httpGet:
path:
/api/idle
port: 8888
```
**Configurazione del modello**
Definisci il comportamento di spegnimento predefinito in caso di inattività in un: WorkspaceTemplate
```
apiVersion: workspace.jupyter.org/v1alpha1
kind: WorkspaceTemplate
metadata:
name: jupyter-template
spec:
displayName: "Jupyter Template"
defaultImage: jupyter/scipy-notebook:latest
defaultIdleShutdown:
enabled: true
idleShutdownTimeoutMinutes: 30
detection:
httpGet:
path: /api/idle
port: 8888
idleShutdownOverrides:
allow: true
minTimeoutMinutes: 60
maxTimeoutMinutes: 240
```
### Ereditarietà e sostituzioni dei modelli
Le aree di lavoro che utilizzano un modello ereditano automaticamente la configurazione del modello. `defaultIdleShutdown` Le aree di lavoro possono sovrascrivere questa configurazione se il modello lo consente.
**Ignora politica**
I modelli controllano il comportamento di override tramite: `idleShutdownOverrides`
**allow** (boolean, default: true) - Se gli spazi di lavoro possono sovrascrivere la configurazione predefinita di inattività.
**minTimeoutMinutes**(intero, opzionale) - Valore di timeout minimo consentito per le sostituzioni dell'area di lavoro.
**maxTimeoutMinutes**(intero, opzionale): valore di timeout massimo consentito per le sostituzioni dell'area di lavoro.
**Esempio di ereditarietà**
Workspace eredita le impostazioni predefinite del modello:
```
apiVersion: workspace.jupyter.org/v1alpha1
kind: Workspace
metadata:
name: my-workspace
spec:
displayName: "My Workspace"
templateRef:
name: jupyter-template
# Inherits defaultIdleShutdown from template
```
**Esempio di override**
Workspace sostituisce le impostazioni predefinite del modello:
```
apiVersion: workspace.jupyter.org/v1alpha1
kind: Workspace
metadata:
name: my-workspace
spec:
displayName: "My Workspace"
templateRef:
name: jupyter-template
idleShutdown:
enabled: true
idleShutdownTimeoutMinutes: 60 # Must be within template bounds
detection:
httpGet:
path: /api/idle
port: 8888
```
**Configurazione bloccata**
Impedisci le sostituzioni dello spazio di lavoro:
```
apiVersion: workspace.jupyter.org/v1alpha1
kind: WorkspaceTemplate
metadata:
name: locked-template
spec:
displayName: "Locked Template"
defaultImage: jupyter/scipy-notebook:latest
defaultIdleShutdown:
enabled: true
idleShutdownTimeoutMinutes: 30
detection:
httpGet:
path: /api/idle
port: 8888
idleShutdownOverrides:
allow: false # Workspaces cannot override
```
### Comportamento
Quando lo spegnimento in stato di inattività è abilitato, il sistema controlla periodicamente l'attività nell'area di lavoro utilizzando l'endpoint HTTP configurato. Se l'endpoint indica che l'area di lavoro è inattiva per la durata del timeout specificata, l'area di lavoro si interrompe automaticamente. È possibile riavviare manualmente l'area di lavoro quando necessario.
## Aggiornamenti dei modelli
Gli strumenti client come Kubectl o Hyperpod CLI e SDK possono essere utilizzati per gestire gli spazi all'interno del cluster EKS. Gli amministratori possono fornire modelli di spazio per le configurazioni Space predefinite, mentre i data scientist possono personalizzare i propri ambienti di sviluppo integrati senza dover comprendere la complessità sottostante di Kubernetes. Per istruzioni dettagliate sull'uso, consulta la documentazione della CLI e dell'SDK all'indirizzo. [https://sagemaker-hyperpod-cli.readthedocs.io/en/latest/index.html](https://sagemaker-hyperpod-cli.readthedocs.io/en/latest/index.html)
Gli amministratori possono eseguire operazioni CRUD sui modelli di spazio, che fungono da configurazioni di base per la creazione di uno spazio. I data scientist possono eseguire operazioni CRUD su Spaces e sovrascrivere vari parametri, inclusi i profili GPU multiistanza per nodi di calcolo specifici. Possono avviare, arrestare e connettersi a Spaces tramite VSCode accesso remoto e interfaccia utente Web. Quando un modello di spazio viene aggiornato, qualsiasi spazio creato successivamente verrà configurato con le impostazioni del modello aggiornato. I controlli di conformità verranno eseguiti quando gli spazi esistenti vengono aggiornati o avviati. Se alcune impostazioni superano i limiti o non corrispondono, gli spazi non verranno aggiornati o avviati.
## Usare hyp cli e kubectl
L'utente può eseguire CRUD sui modelli con la CLI Hyperpod
```
### 1. Create a Space Template
hyp create hyp-space-template --file template.yaml
### 2. List Space Templates
hyp list hyp-space-template
hyp list hyp-space-template --output json
### 3. Describe a Space Template
hyp describe hyp-space-template --name my-template
hyp describe hyp-space-template --name my-template --output json
### 4. Update a Space Template
hyp update hyp-space-template --name my-template --file updated-template.yaml
### 5. Delete a Space Template
hyp delete hyp-space-template --name my-template
```
Per creare modelli personalizzati, puoi utilizzare i nostri modelli di sistema come punto di partenza. Questo modello funzionerà per immagini simili a SMD, tuttavia può essere personalizzato in base alle immagini utilizzate dagli amministratori.
Esempio di modello personalizzato: JupyterLab
```
apiVersion: workspace.jupyter.org/v1alpha1
kind: WorkspaceTemplate
metadata:
name: my-jupyter-template
namespace: my-namespace
spec:
displayName: "My Custom Jupyter Lab"
description: "Custom Jupyter Lab with specific configurations"
defaultImage: "public.ecr.aws/sagemaker/sagemaker-distribution:latest-cpu"
allowedImages:
- "public.ecr.aws/sagemaker/sagemaker-distribution:latest-cpu"
- "public.ecr.aws/sagemaker/sagemaker-distribution:latest-gpu"
defaultResources:
requests:
cpu: "1"
memory: "4Gi"
limits:
cpu: "4"
memory: "16Gi"
primaryStorage:
defaultSize: "10Gi"
minSize: "5Gi"
maxSize: "50Gi"
defaultStorageClassName: "sagemaker-spaces-default-storage-class"
defaultMountPath: "/home/sagemaker-user"
defaultContainerConfig:
command: ["/opt/amazon/sagemaker/workspace/bin/entrypoint-workspace-jupyterlab"]
defaultPodSecurityContext:
fsGroup: 1000
defaultOwnershipType: "Public"
defaultAccessStrategy:
name: "hyperpod-access-strategy"
allowSecondaryStorages: true
appType: "jupyterlab"
```
Esempio di modello di Code Editor personalizzato:
```
apiVersion: workspace.jupyter.org/v1alpha1
kind: WorkspaceTemplate
metadata:
name: my-code-editor-template
namespace: my-namespace
spec:
displayName: "My Custom Code Editor"
description: "Custom Code Editor with specific configurations"
defaultImage: "public.ecr.aws/sagemaker/sagemaker-distribution:latest-cpu"
allowedImages:
- "public.ecr.aws/sagemaker/sagemaker-distribution:latest-cpu"
- "public.ecr.aws/sagemaker/sagemaker-distribution:latest-gpu"
defaultResources:
requests:
cpu: "1"
memory: "4Gi"
limits:
cpu: "4"
memory: "16Gi"
primaryStorage:
defaultSize: "10Gi"
minSize: "5Gi"
maxSize: "50Gi"
defaultStorageClassName: "sagemaker-spaces-default-storage-class"
defaultMountPath: "/home/sagemaker-user"
defaultContainerConfig:
command: ["/opt/amazon/sagemaker/workspace/bin/entrypoint-workspace-code-editor"]
defaultPodSecurityContext:
fsGroup: 1000
defaultOwnershipType: "Public"
defaultAccessStrategy:
name: "hyperpod-access-strategy"
allowSecondaryStorages: true
appType: "code-editor"
```
# Aggiungere utenti e configurare account di servizio
## Controllo granulare degli accessi: la nostra raccomandazione
Gli utenti vengono differenziati in base al nome utente Kubernetes. Il nome utente Kubernetes dell'utente è definito nella relativa voce di accesso. Per garantire che due utenti umani abbiano nomi utente distinti, sono disponibili due opzioni:
1. Consigliato: più utenti umani possono utilizzare lo stesso ruolo purché ognuno abbia il proprio nome di sessione distinto che persisterà tra le sessioni. Per impostazione predefinita, i nomi utente Kubernetes per i ruoli IAM sono nel formato. `arn:aws:sts::{ACCOUNT_ID}:assumed-role/{ROLE_NAME}/{SESSION_NAME}` Con questa impostazione predefinita, gli utenti saranno già differenziati in base al nome della sessione. Un amministratore dispone di alcuni modi per imporre nomi di sessione univoci per utente.
+ Accesso SSO: per impostazione predefinita, gli utenti che utilizzano l'accesso SSO avranno un nome di sessione associato al proprio nome utente AWS
+ Servizio centralizzato di vendita di credenziali: i clienti aziendali possono disporre di un servizio interno di vendita di credenziali che gli utenti possono chiamare per ottenere credenziali con la propria identità.
+ Applicazione basata sui ruoli: richiedi agli utenti IAM di impostare il proprio `aws:username` nome di sessione di ruolo quando assumono un ruolo IAM nella tua azienda. Account AWS La documentazione su come eseguire questa operazione è disponibile qui: [https://aws.amazon.com/blogs/security/ -/easily-control-naming-individualiam-role-sessions](https://aws.amazon.com/blogs/security/easily-control-naming-individual-iam-role-sessions/)
1. Se 2 Data Scientist utilizzano voci di accesso diverse (ruolo o utente IAM diverso), verranno sempre conteggiati come utenti diversi.
**Creazione di una voce di accesso**
Policy IAM richiesta per il ruolo di data scientist:
+ `eks:DescribeCluster`
Politiche di accesso richieste
+ `AmazonSagemakerHyperpodSpacePolicy`- con ambito limitato allo spazio dei nomi, DS dovrebbe creare spazi in
+ `AmazonSagemakerHyperpodSpaceTemplatePolicy`- limitato allo spazio dei nomi «jupyter-k8s-shared»
## Spazi privati e pubblici
Supportiamo 2 tipi di modelli di condivisione: «Pubblico» e «OwnerOnly». Entrambi i campi «AccessType» e «OwnershipType» utilizzano questi 2 valori.
+ AccessType: Gli spazi pubblici sono accessibili da chiunque disponga delle autorizzazioni nel namespace, mentre sono OwnerOnly accessibili solo dal creatore dello spazio e dagli utenti amministratori. Gli utenti amministratori sono definiti con i seguenti criteri:
+ OwnershipType: Gli spazi pubblici possono modified/deleted appartenere a chiunque disponga delle autorizzazioni nel namespace, OwnerOnly dal creatore o modified/deleted dall'amministratore.
Gli utenti amministratori sono definiti da:
1. Parte del gruppo `system:masters` Kubernetes
1. Parte del gruppo Kubernetes definito nella variabile di ambiente CLUSTER\$1ADMIN\$1GROUP nel grafico helm.
I gruppi di un utente possono essere configurati utilizzando le voci di accesso EKS. Uno spazio può essere definito come «Pubblico» o «OwnerOnly» configurando le specifiche nell'oggetto:
```
apiVersion: workspace.jupyter.org/v1alpha1
kind: Workspace
metadata:
labels:
app.kubernetes.io/name: jupyter-k8s
name: example-workspace
spec:
displayName: "Example Workspace"
image: "public.ecr.aws/sagemaker/sagemaker-distribution:3.4.2-cpu"
desiredStatus: "Running"
ownershipType: "Public"/"OwnerOnly"
accessType: "Public"/"OwnerOnly"
# more fields here
```
# Limits
Gli spazi vengono eseguiti come pod sui nodi HyperPod EKS con volumi EBS collegati. Il numero di Spaces che possono essere implementati per nodo è limitato dai limiti dell'infrastruttura. AWS
**Limiti di volume EBS per nodo**
[Riferimento: \$1limits.html https://docs.aws.amazon.com/AWSEC2/ latest/UserGuide/volume](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/volume_limits.html)
I nodi EC2 hanno un numero massimo di volumi EBS che possono essere collegati. Poiché ogni Space utilizza in genere un volume EBS, ciò limita il numero di Spaces con storage EBS dedicato che possono essere eseguiti su un singolo nodo.
**Numero massimo di pod per nodo HyperPod **
Riferimento: [https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker- .html hyperpod-eks-prerequisites](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-eks-prerequisites.html)
Ogni tipo di HyperPod istanza supporta un numero massimo di pod in base agli indirizzi IP disponibili dal plug-in VPC CNI. Poiché ogni Space funziona come un pod, questo limita direttamente il numero di spazi per nodo.
**Impatto**
Il limite effettivo per Spaces per nodo è il vincolo raggiunto per primo.
# Gestione delle attività per Interactive Spaces su HyperPod
Questa sezione spiega come ottimizzare i cluster Amazon SageMaker HyperPod EKS condivisi per i carichi di lavoro Interactive Spaces. Imparerai a configurare le funzionalità di governance delle attività di Kueue, tra cui la gestione delle quote, la pianificazione delle priorità e le politiche di condivisione delle risorse, per garantire che i carichi di lavoro di sviluppo funzionino senza interruzioni, mantenendo al contempo un'equa allocazione tra le attività di formazione, valutazione ed elaborazione in batch dei tuoi team.
## Come funziona la gestione interattiva dello spazio
Per gestire efficacemente gli spazi interattivi in cluster HyperPod EKS condivisi, implementa le seguenti strategie di governance delle attività utilizzando le funzionalità esistenti di Kueue.
**Configurazione della classe di priorità**
Definisci classi prioritarie dedicate per gli spazi interattivi con pesi elevati (ad esempio 100) per garantire che i pod di sviluppo siano ammessi e programmati prima di altri tipi di attività. Questa configurazione consente a Interactive Spaces di anticipare i lavori con priorità inferiore durante il caricamento del cluster, il che è fondamentale per mantenere flussi di lavoro di sviluppo ininterrotti.
**Dimensionamento e allocazione delle quote**
Riserva al tuo team risorse di elaborazione sufficienti per gestire i carichi di lavoro di sviluppo previsti. ClusterQueue Nei periodi in cui le risorse di sviluppo sono inattive, le quote di risorse inutilizzate possono essere temporaneamente assegnate alle attività di altri team. Quando la domanda di sviluppo aumenta, queste risorse prese in prestito possono essere recuperate per dare priorità ai pod Interactive Space in sospeso.
**Strategie di condivisione delle risorse**
Scegli tra due approcci di condivisione delle quote in base alle tue esigenze:
*Controllo rigoroso delle risorse*: disabilita il prestito e il prestito di quote per garantire che la capacità di elaborazione riservata sia sempre disponibile per i tuoi spazi interattivi. Questo approccio richiede il dimensionamento di quote sufficientemente ampie da gestire in modo indipendente i picchi di domanda di sviluppo e può comportare l'inattività dei nodi durante i periodi di utilizzo limitato.
*Condivisione flessibile delle risorse*: abilita il prestito tramite quote per consentire ad altri team di utilizzare risorse di sviluppo inattive quando necessario. Tuttavia, disabilita il prestito per garantire che gli Interactive Spaces non funzionino mai con risorse recuperabili e prese in prestito che potrebbero portare a sfratti imprevisti.
**Prelazione all’interno del team**
Abilita la priorità all'interno del team quando esegui carichi di lavoro misti (formazione, valutazione e spazi interattivi) nell'ambito della stessa quota. Ciò consente a Kueue di anticipare i lavori con priorità più bassa all'interno del team per ospitare i pod Interactive Space ad alta priorità, garantendo che il lavoro di sviluppo possa procedere senza dipendere da quote esterne in prestito.
## Esempio di configurazione di Interactive Space
L'esempio seguente mostra come Kueue gestisce le risorse di calcolo per Interactive Spaces in un cluster Amazon condiviso. SageMaker HyperPod
**Configurazione del cluster e impostazione delle politiche**
Il tuo cluster ha la configurazione seguente:
+ *Team Alpha (Dev Team)*: quota di 8 CPU per Interactive Spaces
+ *Team Beta (ML Team)*: quota di 16 CPU per la formazione e la valutazione
+ *Team Gamma (Research)*: quota di 6 CPU per la sperimentazione
+ *Provisioning statico*: nessun dimensionamento automatico
+ *Capacità totale*: 30 CPUs
Il pool di CPU condiviso utilizza questa politica di priorità:
+ *Spazi interattivi*: priorità 100
+ *Addestramento*: priorità 75
+ *Valutazione*: priorità 50
+ *Elaborazione in batch*: Priorità 25
Kueue impone le quote e le classi di priorità del team, con la priorità abilitata e il prestito disabilitato per il team di sviluppo.
**Stato iniziale: utilizzo normale del cluster**
Durante il normale funzionamento:
+ *Team Alpha*: gestisce 6 spazi interattivi utilizzando 6 CPUs, 2 CPUs inattivi
+ *Team Beta*: esegue lavori di formazione (12 CPUs) e valutazione (4 CPUs) entro la sua quota di 16 CPU
+ *Team Gamma*: esegue carichi di lavoro di ricerca su tutti e 6 CPUs
+ *Condivisione delle risorse*: il Team Beta prende in prestito l'idle CPUs 2 del Team Alpha per una formazione aggiuntiva
**Picco di sviluppo: il Team Alpha richiede risorse aggiuntive**
Quando gli sviluppatori di Team Alpha devono ampliare il lavoro di sviluppo, i pod Interactive Space aggiuntivi ne richiedono altre 4. CPUs Kueue rileva che i nuovi pod:
+ All'interno dello spazio dei nomi del Team Alpha
+ Priorità 100 (spazi interattivi)
+ Hanno l’ammissione in sospeso a causa di vincoli di quota
**Il processo di risposta di Kueue**
Kueue segue un processo in tre fasi per l’allocazione delle risorse:
1. **Controllo delle quote**
Domanda: Il Team Alpha ha una quota inutilizzata?
+ *Utilizzo attuale*: 6 CPUs usati, 2 disponibili CPUs
+ *Nuovo requisito*: 4 CPUs necessari
+ *Risultato*: quota insufficiente → Procedi alla Fase 2
1. **Auto-prelazione all'interno del Team Alpha**
Domanda: È possibile anticipare i lavori Team Alpha con priorità più bassa?
+ *Obiettivi disponibili*: nessun lavoro con priorità inferiore in Team Alpha
+ *Risultato*: Nessuna prelazione possibile → Procedi alla Fase 3
1. **Recupera le risorse prese in prestito**
Domanda: Le risorse del Team Alpha vengono prese in prestito da altri team?
+ *Risorse prese in prestito*: Team Beta utilizza 2 dal Team Alpha CPUs
+ *Azione*: Kueue smonta le capsule di allenamento prese in prestito dal Team Beta, liberandone 2 CPUs
+ *Necessità residua: ne* mancano ancora 2 CPUs → Gli spazi interattivi restano attivi fino a quando le risorse non saranno disponibili NotAdmitted
Questo approccio dà priorità agli spazi interattivi mantenendo al contempo i limiti delle quote del team e impedendo che il lavoro di sviluppo venga eseguito su risorse prese in prestito instabili.
# Osservabilità
## Monitoraggio standard di Kubernetes
Puoi monitorare Spaces utilizzando strumenti Kubernetes standard come description e logs. `kubectl` `kubectl`
**Monitoraggio dello stato dello spazio**
```
# List all Spaces with status
kubectl get workspace -A
# Get detailed information about a specific Space
kubectl describe workspace
```
**Visualizzazione dei registri spaziali**
```
# View workspace container logs
kubectl logs -l workspace.jupyter.org/workspace-name= -c workspace
# View SSM agent sidecar logs (for remote IDE connectivity)
kubectl logs -l workspace.jupyter.org/workspace-name=