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à.
# 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= -c ssm-agent-sidecar
# Follow logs in real-time
kubectl logs -l workspace.jupyter.org/workspace-name= -c workspace -f
```
**Comprensione delle condizioni dello spazio**
Gli spazi riportano quattro tipi di condizioni nel loro stato:
+ **Disponibile**: `True` quando lo spazio è pronto per l'uso. Tutte le risorse richieste (pod, servizi, storage) sono funzionanti e integre.
+ **Progressione**: `True` quando lo Spazio viene creato, aggiornato o riconciliato. Passa a una volta stabile. `False`
+ **Degradato**: `True` quando vengono rilevati errori nelle risorse spaziali. Controlla il messaggio sulla condizione per i dettagli.
+ **Interrotto**: `True` quando lo stato desiderato di Space è impostato su`Stopped`. I pod vengono terminati ma l'archiviazione e la configurazione vengono preservate.
## CloudWatch Integrazione dei log
Puoi installare il componente aggiuntivo di CloudWatch registrazione per inviare i log di Space ad Amazon CloudWatch Logs per la gestione e la conservazione centralizzate dei log. Ciò consente l'aggregazione dei log su più cluster e l'integrazione con Insights per l'interrogazione e l'analisi. CloudWatch Tutti i `kubectl` log sopra disponibili possono essere interrogati con questo plugin. CloudWatch
**Riferimento: [https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker- - .html hyperpod-eks-cluster-observability](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-eks-cluster-observability-cluster-cloudwatch-ci.html)**. cluster-cloudwatch-ci
## HyperPod Componente aggiuntivo Observability
Il componente aggiuntivo SageMaker HyperPod Observability fornisce dashboard completi per il monitoraggio dell'utilizzo delle risorse spaziali. Dopo aver installato il componente aggiuntivo, puoi visualizzare lo spazio, la memoria e l'utilizzo della CPU nella scheda **Attività** della HyperPod console, che mostra le metriche nelle dashboard di Amazon Managed Grafana.
**[Riferimento: - .html https://docs.aws.amazon.com/sagemaker/ latest/dg/sagemaker hyperpod-observability-addon](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-observability-addon.html)**
**Metriche chiave disponibili:**
+ Utilizzo della CPU e della memoria per spazio
+ Metriche della GPU (se applicabile)
# Crea e gestisci spazi
I data scientist possono elencare per visualizzare tutti gli spazi a cui hanno accesso, creare uno spazio utilizzando uno dei modelli, aggiornare lo spazio per aggiornare l'immagine, il file system e altri attributi della configurazione dello spazio ed eliminare uno spazio. Come prerequisito, i clienti devono installare la HyperPod CLI o utilizzare kubectl per creare e gestire gli spazi. [Per ulteriori dettagli sulla HyperPod CLI, consulta questa pagina.](https://github.com/aws/sagemaker-hyperpod-cli/blob/main/README.md#space) Per usare i comandi kubectl, consulta [questa guida](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html) per installare kubectl.
## Crea spazio
**HyperPod CLI**
Crea uno spazio Jupyter
```
hyp create hyp-space \
--name myspace \
--display-name "My Space" \
--memory 8Gi \
--template-ref name=sagemaker-jupyter-template,namespace=jupyter-k8s-system
```
Crea uno spazio Code Editor
```
hyp create hyp-space \
--name myspace \
--display-name "My Space" \
--memory 8Gi \
--template-ref name=sagemaker-code-editor-template,namespace=jupyter-k8s-system
```
**kubectl**
```
kubectl apply -f - <
**HyperPod CLI**
```
hyp list hyp-space
```
**kubectl**
```
kubectl get workspaces -n
```
## Descrivi uno spazio
**HyperPod CLI**
```
hyp describe hyp-space --name myspace
```
**kubectl**
```
# Basic Status reporting
kubectl get workspace my-workspace -n
# Enhanced Workspace Information Retrieval
kubectl get workspace my-workspace -n -o wide
# Complete Workspace Information Retrieval
kubectl get workspace my-workspace -n -o json
kubectl get workspace my-workspace -n -o yaml
```
## Aggiorna uno spazio
**HyperPod CLI**
```
hyp update hyp-space \
--name myspace \
--display-name "Updated My Space"
```
**kubectl**
Aggiorna il file YAML dell'area di lavoro originale secondo necessità, quindi riapplicalo. Assicuratevi che il nome dei metadati non sia modificato. Puoi anche usare questi comandi kubectl per modificare i campi senza riapplicare l'intero spazio di lavoro yaml:
```
# Open a Terminal IDE and modify the Workspace
kubectl edit workspace -n
# Patch a Workspace
kubectl patch workspace --type='merge' -p \
'{"spec":{"":""}}' -n
```
## Avvia/arresta uno spazio
**HyperPod CLI**
```
hyp start hyp-space --name myspace
hyp stop hyp-space --name myspace
```
**kubectl**
È possibile aggiornare il campo di stato desiderato nell'area di lavoro in uno spazio. start/stop
```
# Start a Workspace
kubectl patch workspace --type='merge' -p \
'{"spec":{"desiredStatus":"Running"}}' -n
# Stop a Workspace
kubectl patch workspace --type='merge' -p \
'{"spec":{"desiredStatus":"Stopped"}}' -n
```
## Ottieni registri
**HyperPod CLI**
```
hyp get-logs hyp-space --name myspace
```
**kubectl**
```
# Check Pod Logs
kubectl logs -l workspace.jupyter.org/workspace-name=
# Check Pod Events
kubectl describe pod -l workspace.jupyter.org/workspace-name=
# Check Operator Logs
kubectl logs -n jupyter-k8s-system deployment/jupyter-k8s-controller-manager
```
## Eliminare uno spazio
**HyperPod CLI**
```
hyp delete hyp-space --name myspace
```
**kubectl**
```
# Delete a Workspace
kubectl delete workspace -n
```
# Accesso tramite browser Web
L'accesso all'interfaccia utente Web consente di connettersi direttamente agli spazi di sviluppo in esecuzione sul SageMaker HyperPod cluster tramite un'interfaccia browser Web sicura. Ciò fornisce l'accesso immediato a Jupyter Lab e ad altri ambienti di sviluppo basati sul Web senza richiedere l'installazione di software locale.
## Prerequisiti
Prima di configurare l'accesso all'interfaccia utente Web, assicurati di aver completato quanto segue:
+ SageMaker Installazione del *componente aggiuntivo Spaces: segui l'installazione* del [componente aggiuntivo SageMaker Spaces e abilita l'accesso all'interfaccia Web durante](https://docs.aws.amazon.com/sagemaker/latest/dg/operator-install.html) l'installazione
+ *Accesso utente al cluster EKS*: gli utenti devono configurare EKS Access Entry con le autorizzazioni appropriate. Vedi [Aggiungere utenti e configurare gli account di servizio per i dettagli di configurazione di EKS Access Entry](https://docs.aws.amazon.com/sagemaker/latest/dg/add-user.html)
+ *Spazi di sviluppo*: crea e avvia spazi di sviluppo sul tuo HyperPod cluster
+ *accesso kubectl*: assicurati che kubectl sia configurato per accedere al tuo cluster EKS
## Genera l'URL di accesso all'interfaccia utente Web
**Utilizzo della HyperPod CLI**
Se hai installato la HyperPod CLI, puoi usare questo comando semplificato:
```
hyp create hyp-space-access --name --connection-type web-ui
```
**Usare kubectl**
Puoi anche usare la `kubectl` riga di comando per creare una richiesta di connessione.
```
kubectl create -f - -o yaml <
spec:
workspaceName:
workspaceConnectionType: web-ui
EOF
```
L'URL è presente nell'`status.workspaceConnectionUrl`output di questo comando.
## Accesso al tuo spazio di sviluppo
1. *Genera l'URL dell'interfaccia utente Web* utilizzando uno dei metodi precedenti
1. *Copia l'URL* dalla risposta
1. *Apri l'URL* nel tuo browser web
1. *Accedi al tuo ambiente di sviluppo* tramite l'interfaccia web
## Ambienti di sviluppo supportati
L'interfaccia utente Web fornisce l'accesso a:
+ *Jupyter Lab*
+ *Editor di codici*
## Risoluzione dei problemi
**Impossibile generare l'accesso URLs**
Verifica quanto segue:
+ SageMaker Il componente aggiuntivo Spaces è in esecuzione: kubectl get pods -n sagemaker-spaces-system
+ Lo spazio di sviluppo è funzionante e funzionante
+ L'utente dispone delle autorizzazioni EKS Access Entry appropriate
# Accesso remoto a SageMaker Spaces
L'accesso remoto consente di connettere il codice di Visual Studio locale direttamente agli spazi di sviluppo in esecuzione sul SageMaker HyperPod cluster. Le connessioni remote utilizzano SSM per stabilire tunnel sicuri e crittografati tra il computer locale e gli spazi di sviluppo.
## Prerequisiti
Prima di configurare l'accesso remoto, assicurati di aver completato quanto segue:
+ *SageMaker Installazione del componente aggiuntivo SageMaker * [Spaces: segui l'installazione del componente aggiuntivo](https://docs.aws.amazon.com/sagemaker/latest/dg/operator-install.html) Spaces e abilita l'accesso remoto durante l'installazione (installazione rapida o installazione personalizzata con la configurazione dell'accesso remoto abilitata).
+ *Accesso utente al cluster EKS*: gli utenti devono configurare EKS Access Entry con le autorizzazioni appropriate. Vedi [Aggiungere utenti e configurare gli account di servizio per i dettagli di configurazione di EKS Access Entry](https://docs.aws.amazon.com/sagemaker/latest/dg/add-user.html)
+ *Spazi di sviluppo*: crea e avvia spazi di sviluppo sul tuo HyperPod cluster
+ *accesso kubectl*: assicurati che kubectl sia configurato per accedere al tuo cluster EKS
## Genera una connessione remota VS Code
### Utilizzo della HyperPod CLI
Se hai installato la HyperPod CLI, puoi usare questo comando semplificato:
```
hyp create hyp-space-access --name --connection-type vscode-remote
```
### Usare kubectl
Puoi anche usare la `kubectl` riga di comando per creare una richiesta di connessione.
```
kubectl create -f - -o yaml <
spec:
workspaceName:
workspaceConnectionType: vscode-remote
EOF
```
L'URL è presente nell'`status.workspaceConnectionUrl`output di questo comando.
## Connessione con VS Code
1. Genera l'URL di connessione VS Code utilizzando uno dei metodi sopra indicati
1. Copia l'URL del codice VS dalla risposta
1. Fai clic sull'URL o incollalo nel browser
1. VS Code richiederà di aprire la connessione remota
1. Conferma la connessione per stabilire l'ambiente di sviluppo remoto
## Ambienti di sviluppo supportati
L'interfaccia utente Web fornisce l'accesso a:
+ *Jupyter Lab*
+ *Editor di codici*
## Risoluzione dei problemi
**Impossibile generare una connessione URLs**
*Controlla quanto segue:*
+ SageMaker Il componente aggiuntivo Spaces è in esecuzione: kubectl get pods -n sagemaker-spaces-system
+ Lo spazio di sviluppo è funzionante e funzionante
+ L'accesso remoto è stato abilitato durante l'installazione del componente aggiuntivo
+ L'utente dispone delle autorizzazioni EKS Access Entry appropriate
# Addestra e implementa modelli con HyperPod CLI e SDK
Amazon ti SageMaker HyperPod aiuta ad addestrare e distribuire modelli di machine learning su larga scala. La AWS HyperPod CLI è un'interfaccia a riga di comando unificata che semplifica i flussi di lavoro di machine learning (ML). AWS Riduce le complessità dell’infrastruttura e offre un’esperienza semplificata per l’invio, il monitoraggio e la gestione dei job di addestramento di ML. La CLI è progettata specificamente per i Data Scientist e gli ingegneri di ML che desiderano concentrarsi sullo sviluppo di modelli piuttosto che sulla gestione dell’infrastruttura. Questo argomento illustra tre scenari chiave: addestramento di un PyTorch modello, implementazione di un modello personalizzato utilizzando artefatti addestrati e distribuzione di un modello. JumpStart Progettato per gli utenti alle prime armi, questo breve tutorial ti consente di configurare, addestrare e distribuire i modelli senza sforzo utilizzando la CLI o l' HyperPod SDK. Il processo di handshake tra l’addestramento e l’inferenza consente di gestire gli artefatti del modello in modo efficace.
## Prerequisiti
Prima di iniziare a utilizzare Amazon SageMaker HyperPod, assicurati di avere:
+ Un AWS account con accesso ad Amazon SageMaker HyperPod
+ Python 3.9, 3.10 o 3.11 installato
+ AWS CLI configurato con le credenziali appropriate.
## Installa la HyperPod CLI e l'SDK
Installa il pacchetto richiesto per accedere alla CLI e all’SDK:
```
pip install sagemaker-hyperpod
```
Questo comando imposta gli strumenti necessari per interagire con HyperPod i cluster.
## Configurazione del contesto del cluster
HyperPod opera su cluster ottimizzati per l'apprendimento automatico. Inizia elencando i cluster disponibili e selezionane uno per le tue attività.
1. Elenca tutti i cluster disponibili:
```
hyp list-cluster
```
1. Scegli e imposta il cluster attivo:
```
hyp set-cluster-context your-eks-cluster-name
```
1. Verifica la configurazione:
```
hyp get-cluster-context
```
**Nota**
Tutti i comandi successivi hanno come destinazione il cluster che hai impostato come contesto.
## Scelta dello scenario
Per istruzioni dettagliate su ogni scenario, fai clic sugli argomenti seguenti:
**Topics**
+ [Prerequisiti](#prerequisites)
+ [Installa la HyperPod CLI e l'SDK](#install-cli-sdk)
+ [Configurazione del contesto del cluster](#configure-cluster)
+ [Scelta dello scenario](#choose-scenario)
+ [Addestra un modello PyTorch](train-models-with-hyperpod.md)
+ [Implementazione di un modello personalizzato](deploy-trained-model.md)
+ [Implementa un modello JumpStart](deploy-jumpstart-model.md)
# Addestra un modello PyTorch
Questo argomento illustra il processo di addestramento di un PyTorch modello utilizzando HyperPod.
In questo scenario, formiamo un PyTorch modello utilizzando il `hyp-pytorch-job` modello, che semplifica la creazione di posti di lavoro esponendo i parametri di uso comune. Gli artefatti del modello vengono archiviati in un bucket S3 per essere utilizzati successivamente per l’inferenza. Tuttavia, questa impostazione è facoltativa, quindi puoi scegliere la tua posizione di archiviazione preferita.
## Creazione di un job di addestramento
Puoi addestrare il modello utilizzando la CLI o Python SDK.
### Utilizzo della CLI
Crea un job di addestramento con il comando seguente:
```
hyp create hyp-pytorch-job \
--version 1.0 \
--job-name test-pytorch-job \
--image pytorch/pytorch:latest \
--command '["python", "train.py"]' \
--args '["--epochs", "10", "--batch-size", "32"]' \
--environment '{"PYTORCH_CUDA_ALLOC_CONF": "max_split_size_mb:32"}' \
--pull-policy "IfNotPresent" \
--instance-type ml.p4d.24xlarge \
--tasks-per-node 8 \
--label-selector '{"accelerator": "nvidia", "network": "efa"}' \
--deep-health-check-passed-nodes-only true \
--scheduler-type "kueue" \
--queue-name "training-queue" \
--priority "high" \
--max-retry 3 \
--volumes '["data-vol", "model-vol", "checkpoint-vol"]' \
--persistent-volume-claims '["shared-data-pvc", "model-registry-pvc"]' \
--output-s3-uri s3://my-bucket/model-artifacts
```
**Spiegazione dei principali parametri richiesti**:
+ `--job-name`: identificatore univoco per il job di addestramento
+ `--image`: immagine Docker che contiene l’ambiente di addestramento
Questo comando avvia un job di addestramento denominato `test-pytorch-job`. `--output-s3-uri` specifica dove vengono archiviati gli artefatti del modello addestrato, ad esempio `s3://my-bucket/model-artifacts`. Annota questa posizione, perché ti servirà per implementare il modello personalizzato.
### Utilizzo di Python SDK
Per il controllo programmatico, utilizza l’SDK. Crea uno script Python per avviare lo stesso job di addestramento.
```
from sagemaker.hyperpod import HyperPodPytorchJob
from sagemaker.hyperpod.job
import ReplicaSpec, Template, Spec, Container, Resources, RunPolicy, Metadata
# Define job specifications
nproc_per_node = "1" # Number of processes per node
replica_specs =
[
ReplicaSpec
(
name = "pod", # Replica name
template = Template
(
spec = Spec
(
containers =
[
Container
(
# Container name
name="container-name",
# Training image
image="448049793756.dkr.ecr.us-west-2.amazonaws.com/ptjob:mnist",
# Always pull image
image_pull_policy="Always",
resources=Resources\
(
# No GPUs requested
requests={"nvidia.com/gpu": "0"},
# No GPU limit
limits={"nvidia.com/gpu": "0"},
),
# Command to run
command=["python", "train.py"],
# Script arguments
args=["--epochs", "10", "--batch-size", "32"],
)
]
)
),
)
]
# Keep pods after completion
run_policy = RunPolicy(clean_pod_policy="None")
# Create and start the PyTorch job
pytorch_job = HyperPodPytorchJob
(
# Job name
metadata = Metadata(name="demo"),
# Processes per node
nproc_per_node = nproc_per_node,
# Replica specifications
replica_specs = replica_specs,
# Run policy
run_policy = run_policy,
# S3 location for artifacts
output_s3_uri="s3://my-bucket/model-artifacts"
)
# Launch the job
pytorch_job.create()
```
## Monitoraggio del job di addestramento
Monitora lo stato di avanzamento del processo con questi comandi:
### Utilizzo della CLI
```
# Check job status
hyp list hyp-pytorch-job
# Get detailed information
hyp describe hyp-pytorch-job --job-name test-pytorch-job
# View logs
hyp get-logs hyp-pytorch-job \
--pod-name test-pytorch-job-pod-0 \
--job-name test-pytorch-job
```
**Nota**: la durata dell’addestramento varia in base alla complessità del modello e al tipo di istanza. Monitora i log per tenere traccia dello stato di avanzamento.
Questi comandi consentono di verificare lo stato del processo e di risolvere i problemi. Una volta completato correttamente il processo, gli artefatti del modello vengono salvati in `s3://my-bucket/model-artifacts`.
### Utilizzo di Python SDK
Aggiungi il codice seguente allo script Python:
```
print("List all pods created for this job:")
print(pytorch_job.list_pods())
print("Check the logs from pod0:")
print(pytorch_job.get_logs_from_pod(pod_name="demo-pod-0"))
print("List all HyperPodPytorchJobs:")
print(HyperPodPytorchJob.list())
print("Describe job:")
print(HyperPodPytorchJob.get(name="demo").model_dump())
pytorch_job.refresh()
print(pytorch_job.status.model_dump())
```
## Fasi successive
Dopo l’addestramento, gli artefatti del modello vengono archiviati nel bucket S3 che hai specificato (`s3://my-bucket/model-artifacts`). Puoi utilizzare questi artefatti per implementare un modello. Attualmente, è necessario gestire manualmente la transizione dall’addestramento all’inferenza. Questa operazione prevede:
+ **Individuazione degli artefatti**: controlla il bucket S3 (`s3://my-bucket/model-artifacts`) per verificare che i file del modello addestrato siano presenti.
+ **Registrazione del percorso**: annota il percorso S3 esatto (ad esempio `s3://my-bucket/model-artifacts/test-pytorch-job/model.tar.gz`) da utilizzare nella configurazione dell’inferenza.
+ **Riferimento durante l’implementazione**: inserisci questo percorso S3 nella configurazione dell’endpoint personalizzato per assicurarti che venga caricato il modello corretto.
# Implementazione di un modello personalizzato
Al termine dell’addestramento, implementa il modello per l’inferenza. Puoi implementare un modello personalizzato utilizzando la CLI o l’SDK.
## Individuazione degli artefatti del modello
+ **Controlla il tuo bucket S3**: verifica che gli artefatti del modello siano salvati in `s3://my-bucket/model-artifacts/`
+ **Annota il percorso esatto**: ti servirà il percorso completo (ad esempio `s3://my-bucket/model-artifacts/test-pytorch-job/model.tar.gz`)
## Implementazione con la CLI
Per implementare il modello personalizzato, utilizza il comando seguente:
```
hyp create hyp-custom-endpoint \
--version 1.0 \
--env '{"HF_MODEL_ID":"/opt/ml/model", "SAGEMAKER_PROGRAM":"inference.py", }' \
--model-source-type s3 \
--model-location test-pytorch-job \
--s3-bucket-name my-bucket \
--s3-region us-east-2 \
--prefetch-enabled true \
--image-uri 763104351884.dkr.ecr.us-east-1.amazonaws.com/pytorch-inference:latest \
--model-volume-mount-name model-weights \
--container-port 8080 \
--resources-requests '{"cpu": "30000m", "nvidia.com/gpu": 1, "memory": "100Gi"}' \
--resources-limits '{"nvidia.com/gpu": 1}' \
--tls-output-s3-uri s3:// \
--instance-type ml.g5.8xlarge \
--endpoint-name endpoint-custom-pytorch \
--model-name pytorch-custom-model
```
Questo comando distribuisce il modello addestrato come endpoint denominato `endpoint-custom-pytorch`. `--model-location` fa riferimento al percorso dell’artefatto specificato nel job di addestramento.
## Implementazione con Python SDK
Crea uno script Python con il seguente contenuto:
```
from sagemaker.hyperpod.inference.config.hp_custom_endpoint_config import Model, Server, SageMakerEndpoint, TlsConfig, EnvironmentVariables
from sagemaker.hyperpod.inference.hp_custom_endpoint import HPCustomEndpoint
model = Model(
model_source_type="s3",
model_location="test-pytorch-job",
s3_bucket_name="my-bucket",
s3_region="us-east-2",
prefetch_enabled=True
)
server = Server(
instance_type="ml.g5.8xlarge",
image_uri="763104351884.dkr.ecr.us-east-2.amazonaws.com/huggingface-pytorch-tgi-inference:2.4.0-tgi2.3.1-gpu-py311-cu124-ubuntu22.04-v2.0",
container_port=8080,
model_volume_mount_name="model-weights"
)
resources = {
"requests": {"cpu": "30000m", "nvidia.com/gpu": 1, "memory": "100Gi"},
"limits": {"nvidia.com/gpu": 1}
}
env = EnvironmentVariables(
HF_MODEL_ID="/opt/ml/model",
SAGEMAKER_PROGRAM="inference.py",
SAGEMAKER_SUBMIT_DIRECTORY="/opt/ml/model/code",
MODEL_CACHE_ROOT="/opt/ml/model",
SAGEMAKER_ENV="1"
)
endpoint_name = SageMakerEndpoint(name="endpoint-custom-pytorch")
tls_config = TlsConfig(tls_certificate_output_s3_uri="s3://")
custom_endpoint = HPCustomEndpoint(
model=model,
server=server,
resources=resources,
environment=env,
sage_maker_endpoint=endpoint_name,
tls_config=tls_config
)
custom_endpoint.create()
```
## Richiamare l'endpoint
### Utilizzo della CLI
Testa l’endpoint con un input di esempio:
```
hyp invoke hyp-custom-endpoint \
--endpoint-name endpoint-custom-pytorch \
--body '{"inputs":"What is the capital of USA?"}'
```
Questa operazione restituisce la risposta del modello, ad esempio “La capitale degli Stati Uniti è Washington, D.C.”
### Utilizzo di SDK
Aggiungi il codice seguente allo script Python:
```
data = '{"inputs":"What is the capital of USA?"}'
response = custom_endpoint.invoke(body=data).body.read()
print(response)
```
## Gestione dell’endpoint
### Utilizzo della CLI
Elenca e ispeziona l’endpoint:
```
hyp list hyp-custom-endpoint
hyp get hyp-custom-endpoint --name endpoint-custom-pytorch
```
### Utilizzo di SDK
Aggiungi il codice seguente allo script Python:
```
logs = custom_endpoint.get_logs()
print(logs)
```
## Eseguire la pulizia delle risorse
Al termine, elimina l’endpoint per evitare costi inutili.
### Utilizzo della CLI
```
hyp delete hyp-custom-endpoint --name endpoint-custom-pytorch
```
### Utilizzo di SDK
```
custom_endpoint.delete()
```
## Fasi successive
Hai distribuito e testato con successo un modello personalizzato utilizzando. SageMaker HyperPod Ora puoi utilizzare questo endpoint per l’inferenza nelle tue applicazioni.
# Implementa un modello JumpStart
Puoi implementare un JumpStart modello pre-addestrato per l'inferenza utilizzando la CLI o l'SDK.
## Utilizzo della CLI
Esegui il comando seguente per distribuire un modello: JumpStart
```
hyp create hyp-jumpstart-endpoint \
--version 1.0 \
--model-id deepseek-llm-r1-distill-qwen-1-5b \
--instance-type ml.g5.8xlarge \
--endpoint-name endpoint-test-jscli
```
## Utilizzo di SDK
Crea uno script Python con il seguente contenuto:
```
from sagemaker.hyperpod.inference.config.hp_jumpstart_endpoint_config import Model, Server, SageMakerEndpoint, TlsConfig
from sagemaker.hyperpod.inference.hp_jumpstart_endpoint import HPJumpStartEndpoint
model=Model(
model_id='deepseek-llm-r1-distill-qwen-1-5b'
)
server=Server(
instance_type='ml.g5.8xlarge',
)
endpoint_name=SageMakerEndpoint(name='')
# create spec
js_endpoint=HPJumpStartEndpoint(
model=model,
server=server,
sage_maker_endpoint=endpoint_name
)
```
## Richiamare l'endpoint
### Utilizzo della CLI
Testa l’endpoint con un input di esempio:
```
hyp invoke hyp-jumpstart-endpoint \
--endpoint-name endpoint-jumpstart \
--body '{"inputs":"What is the capital of USA?"}'
```
### Utilizzo di SDK
Aggiungi il codice seguente allo script Python:
```
data = '{"inputs":"What is the capital of USA?"}'
response = js_endpoint.invoke(body=data).body.read()
print(response)
```
## Gestione dell’endpoint
### Utilizzo della CLI
Elenca e ispeziona l’endpoint:
```
hyp list hyp-jumpstart-endpoint
hyp get hyp-jumpstart-endpoint --name endpoint-jumpstart
```
### Utilizzo di SDK
Aggiungi il codice seguente allo script Python:
```
endpoint_iterator = HPJumpStartEndpoint.list()
for endpoint in endpoint_iterator:
print(endpoint.name, endpoint.status)
logs = js_endpoint.get_logs()
print(logs)
```
## Eseguire la pulizia delle risorse
Al termine, elimina l’endpoint per evitare costi inutili.
### Utilizzo della CLI
```
hyp delete hyp-jumpstart-endpoint --name endpoint-jumpstart
```
### Utilizzo di SDK
```
js_endpoint.delete()
```
## Fasi successive
Ora che hai addestrato un PyTorch modello, lo hai distribuito come endpoint personalizzato e distribuito un JumpStart modello utilizzando la HyperPod CLI e l'SDK, esplora le funzionalità avanzate:
+ **Addestramento multinodo**: estensione dell’addestramento su più istanze
+ **Container personalizzati**: crea ambienti di addestramento specializzati
+ **Integrazione con SageMaker Pipelines**: automatizza i flussi di lavoro ML
+ **Monitoraggio avanzato**: configura metriche e avvisi personalizzati
[Per altri esempi e configurazioni avanzate, visita il repository. SageMaker HyperPod GitHub ](https://github.com/aws/amazon-sagemaker-examples)
# Esecuzione di processi su SageMaker HyperPod cluster orchestrati da Amazon EKS
I seguenti argomenti forniscono procedure ed esempi di accesso ai nodi di calcolo ed esecuzione di carichi di lavoro ML su SageMaker HyperPod cluster forniti orchestrati con Amazon EKS. A seconda di come hai configurato l'ambiente sul HyperPod cluster, esistono molti modi per eseguire carichi di lavoro ML sui cluster. HyperPod
**Nota**
Quando si eseguono lavori tramite SageMaker HyperPod CLI o kubectl, è HyperPod possibile tenere traccia dell'utilizzo del calcolo (ore GPU/CPU) tra i namespace (team). Queste metriche sono la base dei report di utilizzo, che forniscono:
Visibilità sul consumo di risorse allocate e di risorse prese in prestito
Utilizzo delle risorse dei team per gli audit (fino a 180 giorni)
Attribuzione dei costi in linea con le policy di governance delle attività
Per utilizzare i report di utilizzo, è necessario installare la relativa infrastruttura. Consigliamo vivamente di configurare la [governance delle attività](sagemaker-hyperpod-eks-operate-console-ui-governance.md) per applicare le quote di calcolo e abilitare l’attribuzione granulare dei costi.
[Per ulteriori informazioni sulla configurazione e la generazione di report sull'utilizzo, consulta Reporting Compute Usage in. HyperPod](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-usage-reporting.html)
**Suggerimento**
Per un'esperienza pratica e indicazioni su come configurare e utilizzare un SageMaker HyperPod cluster orchestrato con Amazon EKS, consigliamo di seguire questo [Amazon EKS Support](https://catalog.us-east-1.prod.workshops.aws/workshops/2433d39e-ccfe-4c00-9d3d-9917b729258e) in workshop. SageMaker HyperPod
Gli utenti di data scientist possono addestrare modelli fondamentali utilizzando il set di cluster EKS come orchestratore per il cluster. SageMaker HyperPod Gli scienziati sfruttano la [SageMaker HyperPod CLI](https://github.com/aws/sagemaker-hyperpod-cli) e i comandi `kubectl` nativi per trovare i cluster SageMaker HyperPod disponibili, inviare lavori di formazione (Pod) e gestire i propri carichi di lavoro. La SageMaker HyperPod CLI consente l'invio dei lavori utilizzando un file di schema dei lavori di formazione e fornisce funzionalità per l'elenco, la descrizione, l'annullamento e l'esecuzione dei lavori. Gli scienziati possono utilizzare [Kubeflow Training Operator](https://www.kubeflow.org/docs/components/training/overview/) in base alle quote di calcolo gestite da e gestito dall'[SageMaker IA per gestire gli esperimenti di HyperPod machine learning e le sessioni di MLflow](https://docs.aws.amazon.com/sagemaker/latest/dg/mlflow.html) formazione.
**Topics**
+ [Installazione della SageMaker HyperPod CLI](sagemaker-hyperpod-eks-run-jobs-access-nodes.md)
+ [SageMaker HyperPod Comandi CLI](sagemaker-hyperpod-eks-hyperpod-cli-reference.md)
+ [Esecuzione di lavori utilizzando la SageMaker HyperPod CLI](sagemaker-hyperpod-eks-run-jobs-hyperpod-cli.md)
+ [Esecuzione dei processi con `kubectl`](sagemaker-hyperpod-eks-run-jobs-kubectl.md)
# Installazione della SageMaker HyperPod CLI
SageMaker HyperPod fornisce il pacchetto CLI ([SageMaker HyperPod Command Line Interface](https://github.com/aws/sagemaker-hyperpod-cli)).
1. Controlla se la versione di Python sul computer locale è compresa tra 3.8 e 3.11.
1. [Controlla i prerequisiti nel file `README` markdown nel pacchetto CLI SageMaker HyperPod .](https://github.com/aws/sagemaker-hyperpod-cli)
1. Clona il pacchetto SageMaker HyperPod CLI da. GitHub
```
git clone https://github.com/aws/sagemaker-hyperpod-cli.git
```
1. Installa la SageMaker HyperPod CLI.
```
cd sagemaker-hyperpod-cli && pip install .
```
1. Verifica se la SageMaker HyperPod CLI è installata correttamente eseguendo il comando seguente.
```
hyperpod --help
```
**Nota**
Se sei un data scientist e desideri utilizzare la SageMaker HyperPod CLI, assicurati che il tuo ruolo IAM sia configurato correttamente dagli amministratori del cluster seguendo le istruzioni riportate in and. [Utenti IAM per Data Scientist](sagemaker-hyperpod-prerequisites-iam.md#sagemaker-hyperpod-prerequisites-iam-cluster-user) [Configurazione del controllo degli accessi basato su ruoli Kubernetes](sagemaker-hyperpod-eks-setup-rbac.md)
# SageMaker HyperPod Comandi CLI
La tabella seguente riassume i comandi SageMaker HyperPod CLI.
**Nota**
[Per un riferimento completo alla CLI, consulta [README nell'archivio](https://github.com/aws/sagemaker-hyperpod-cli?tab=readme-ov-file#sagemaker-hyperpod-command-line-interface) SageMaker HyperPod CLI. GitHub](https://github.com/aws/sagemaker-hyperpod-cli)
| SageMaker HyperPod Comando CLI | Entità | Description |
| --- | --- | --- |
| hyperpod get-clusters | cluster/accesso | Elenca tutti i cluster a cui l'utente è stato abilitato, con le autorizzazioni IAM, a inviare carichi di lavoro di formazione. Fornisce un'istantanea corrente di tutte le istanze disponibili che non eseguono carichi di lavoro o job e la capacità massima, raggruppandole per stati di controllo dello stato di integrità (es:) BurnInPassed |
| hyperpod connect-cluster | cluster/accesso | kubectlConfigura HyperPod per funzionare sul cluster e sullo spazio dei nomi specificati |
| hyperpod start-job | job | Invia il processo al cluster di destinazione. Il nome del processo sarà univoco a livello di namespace. Gli utenti potranno sostituire le specifiche yaml passandole come argomenti della CLI. |
| hyperpod get-job | job | Visualizza i metadati del processo inviato. |
| hyperpod list-jobs | job | Elenca tutti i job in Connected cluster/namespace a cui l'utente è stato aggiunto con le autorizzazioni IAM per inviare carichi di lavoro di formazione |
| hyperpod cancel-job | job | Arresta ed elimina il processo e rilascia le risorse di calcolo sottostanti. Questo processo non può essere ripreso di nuovo. Se necessario, va avviato un nuovo processo. |
| hyperpod list-pods | pod | Elenca tutti i pod del processo specificato in un namespace |
| hyperpod get-log | pod | Recupera i log di un particolare pod in un processo specificato |
| hyperpod exec | pod | Esegue il comando bash nella shell dei pod specificati e pubblica l’output |
| hyperpod --help | utility | elenca tutti i comandi supportati |
# Esecuzione di lavori utilizzando la SageMaker HyperPod CLI
Per eseguire i processi, assicurati di aver installato Kubeflow Training Operator nei cluster EKS. Per ulteriori informazioni, consulta [Installazione di pacchetti sul cluster Amazon EKS con Helm](sagemaker-hyperpod-eks-install-packages-using-helm-chart.md).
Esegui il `hyperpod get-cluster` comando per ottenere l'elenco dei cluster disponibili. HyperPod
```
hyperpod get-clusters
```
Esegui `hyperpod connect-cluster` per configurare la SageMaker HyperPod CLI con il cluster EKS che orchestra il cluster. HyperPod
```
hyperpod connect-cluster --cluster-name
```
Utilizza il comando `hyperpod start-job` per eseguire un processo. Il comando seguente mostra il comando con le opzioni richieste.
```
hyperpod start-job \
--job-name
--image
--entry-script
--instance-type
--node-count
```
Il comando `hyperpod start-job` include anche varie opzioni come la ripresa automatica e la pianificazione dei processi.
## Abilitazione della ripresa automatica del processo
Il comando `hyperpod start-job` include anche le opzioni seguenti per specificare la ripresa automatica del processo. Per consentire la ripresa automatica del lavoro in modo che funzioni con le funzionalità di resilienza del SageMaker HyperPod nodo, è necessario impostare il valore dell'opzione su. `restart-policy` `OnFailure` Il processo deve essere eseguito nel namespace `kubeflow` o in uno dei namespace con il prefisso `hyperpod`.
+ [--auto-resume ] \$1Facoltativo: abilita la ripresa automatica del processo in caso di errore. L’impostazione predefinita è false.
+ [--max-retry ] \$1Facoltativo: se la ripresa automatica è impostata su true, il valore predefinito di max-retry è 1, se non specificato.
+ [--restart-policy] \$1Optional, politica di riavvio. PyTorchJob I valori disponibili sono `Always`, `OnFailure`, `Never` o `ExitCode`. Il valore predefinito è `OnFailure`.
```
hyperpod start-job \
... // required options \
--auto-resume true \
--max-retry 3 \
--restart-policy OnFailure
```
## Esecuzione di processi con opzioni di pianificazione
Il comando `hyperpod start-job` offre le seguenti opzioni per configurare il processo con meccanismi di accodamento.
**Nota**
È necessario che [Kueue](https://kueue.sigs.k8s.io/docs/overview/) sia installato nel cluster EKS. Se non è installato, segui le istruzioni in [Configurazione per la governance SageMaker HyperPod delle attività](sagemaker-hyperpod-eks-operate-console-ui-governance-setup.md).
+ [--scheduler-type ] \$1Facoltativo: specifica il tipo di scheduler. Il valore predefinito è `Kueue`.
+ [--queue-name ] \$1Facoltativo: specifica il nome della [coda locale](https://kueue.sigs.k8s.io/docs/concepts/local_queue/) o della [coda del cluster](https://kueue.sigs.k8s.io/docs/concepts/cluster_queue/) da inviare insieme al processo. La coda deve essere creata dagli amministratori del cluster utilizzando `CreateComputeQuota`.
+ [--priority ] \$1Facoltativo: specifica il nome della [classe di priorità del carico di lavoro](https://kueue.sigs.k8s.io/docs/concepts/workload_priority_class/), che deve essere creata dagli amministratori del cluster.
```
hyperpod start-job \
... // required options
--scheduler-type Kueue \
--queue-name high-priority-queue \
--priority high
```
## Esecuzione dei processi da un file di configurazione
In alternativa, puoi creare un file di configurazione del processo che contenga tutti i parametri richiesti dal processo, quindi passarlo al comando `hyperpod start-job` utilizzando l’opzione --config-file. In questo caso:
1. Crea il file di configurazione del processo con i parametri richiesti. Fate riferimento al file di configurazione del lavoro nell' GitHub archivio SageMaker HyperPod CLI per un file di configurazione di [base](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-eks-run-jobs-hyperpod-cli.html#sagemaker-hyperpod-eks-hyperpod-cli-from-config).
1. Avvia il processo utilizzando il file di configurazione come segue.
```
hyperpod start-job --config-file /path/to/test_job.yaml
```
**Suggerimento**
Per un elenco completo dei parametri del `hyperpod start-job` comando, consultate la sezione [Invio di un Job](https://github.com/aws/sagemaker-hyperpod-cli?tab=readme-ov-file#submitting-a-job) nel `README.md` repository SageMaker HyperPod GitHub CLI.
# Esecuzione dei processi con `kubectl`
**Nota**
La ripresa automatica del job di addestramento richiede Kubeflow Training Operator versione `1.7.0`, `1.8.0` o `1.8.1`.
Tieni presente che Kubeflow Training Operator dovrebbe essere installato nei cluster con un grafico Helm. Per ulteriori informazioni, consulta [Installazione di pacchetti sul cluster Amazon EKS con Helm](sagemaker-hyperpod-eks-install-packages-using-helm-chart.md). Verifica che il piano di controllo (control-plane) di Kubeflow Training Operator sia configurato correttamente eseguendo questo comando.
```
kubectl get pods -n kubeflow
```
Questo restituisce un output simile al seguente.
```
NAME READY STATUS RESTARTS AGE
training-operator-658c68d697-46zmn 1/1 Running 0 90s
```
**Per inviare un job di addestramento**
Per eseguire un job di addestramento, prepara il file di configurazione del processo ed esegui il comando [https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#apply](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#apply) come segue.
```
kubectl apply -f /path/to/training_job.yaml
```
**Per descrivere un job di addestramento**
Per recuperare i dettagli del processo inviato al cluster EKS, utilizza il comando seguente. Restituisce informazioni sul processo come l’ora di invio, l’ora di completamento, lo stato e i dettagli di configurazione.
```
kubectl get -o yaml training-job -n kubeflow
```
**Per arrestare un job di addestramento ed eliminare le risorse EKS**
Per arrestare un job di addestramento, utilizza kubectl delete. Di seguito è riportato un esempio di come arrestare il job di addestramento creato dal file di configurazione `pytorch_job_simple.yaml`.
```
kubectl delete -f /path/to/training_job.yaml
```
Dovrebbe essere restituito l’output seguente.
```
pytorchjob.kubeflow.org "training-job" deleted
```
**Per abilitare la ripresa automatica del processo**
SageMaker HyperPod supporta la funzionalità di ripristino automatico dei lavori per i lavori Kubernetes, integrandosi con il piano di controllo Kubeflow Training Operator.
Assicurati che ci siano nodi sufficienti nel cluster che abbiano superato il controllo di integrità. SageMaker HyperPod Il taint `sagemaker.amazonaws.com/node-health-status` dei nodi deve essere impostato su `Schedulable`. Consigliamo di includere un selettore di nodi nel file YAML del processo per selezionare i nodi con la configurazione appropriata come descritto di seguito.
```
sagemaker.amazonaws.com/node-health-status: Schedulable
```
Il seguente frammento di codice è un esempio di come modificare una configurazione YAML di un PyTorch lavoro Kubeflow per abilitare la funzionalità di ripristino automatico del lavoro. È necessario aggiungere due annotazioni e impostare `restartPolicy` su `OnFailure` come segue.
```
apiVersion: "kubeflow.org/v1"
kind: PyTorchJob
metadata:
name: pytorch-simple
namespace: kubeflow
annotations: { // config for job auto resume
sagemaker.amazonaws.com/enable-job-auto-resume: "true"
sagemaker.amazonaws.com/job-max-retry-count: "2"
}
spec:
pytorchReplicaSpecs:
......
Worker:
replicas: 10
restartPolicy: OnFailure
template:
spec:
nodeSelector:
sagemaker.amazonaws.com/node-health-status: Schedulable
```
**Per controllare lo stato di ripresa automatica del processo**
Per controllare lo stato di ripresa automatica del processo, utilizza il comando seguente.
```
kubectl describe pytorchjob -n kubeflow
```
A seconda dei modelli di errore, potrebbero essere riavviati due modelli del job di addestramento Kubeflow, come riportato di seguito.
**Modello 1**:
```
Start Time: 2024-07-11T05:53:10Z
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal SuccessfulCreateService 9m45s pytorchjob-controller Created service: pt-job-1-worker-0
Normal SuccessfulCreateService 9m45s pytorchjob-controller Created service: pt-job-1-worker-1
Normal SuccessfulCreateService 9m45s pytorchjob-controller Created service: pt-job-1-master-0
Warning PyTorchJobRestarting 7m59s pytorchjob-controller PyTorchJob pt-job-1 is restarting because 1 Master replica(s) failed.
Normal SuccessfulCreatePod 7m58s (x2 over 9m45s) pytorchjob-controller Created pod: pt-job-1-worker-0
Normal SuccessfulCreatePod 7m58s (x2 over 9m45s) pytorchjob-controller Created pod: pt-job-1-worker-1
Normal SuccessfulCreatePod 7m58s (x2 over 9m45s) pytorchjob-controller Created pod: pt-job-1-master-0
Warning PyTorchJobRestarting 7m58s pytorchjob-controller PyTorchJob pt-job-1 is restarting because 1 Worker replica(s) failed.
```
**Modello 2**:
```
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal SuccessfulCreatePod 19m pytorchjob-controller Created pod: pt-job-2-worker-0
Normal SuccessfulCreateService 19m pytorchjob-controller Created service: pt-job-2-worker-0
Normal SuccessfulCreatePod 19m pytorchjob-controller Created pod: pt-job-2-master-0
Normal SuccessfulCreateService 19m pytorchjob-controller Created service: pt-job-2-master-0
Normal SuccessfulCreatePod 4m48s pytorchjob-controller Created pod: pt-job-2-worker-0
Normal SuccessfulCreatePod 4m48s pytorchjob-controller Created pod: pt-job-2-master-0
```
# HyperPod Utilizzo dell'operatore addetto alla formazione
L'operatore di SageMaker HyperPod formazione di Amazon ti aiuta ad accelerare lo sviluppo di modelli di intelligenza artificiale generativi gestendo in modo efficiente la formazione distribuita su cluster di GPU di grandi dimensioni. Introduce funzionalità intelligenti di ripristino dai guasti, rilevamento delle interruzioni e gestione a livello di processo che riducono al minimo le interruzioni dell’addestramento e riducono i costi. A differenza dell’infrastruttura di addestramento tradizionale che richiede il riavvio completo del processo in caso di guasto, questo operatore implementa un ripristino chirurgico del processo per garantire il corretto funzionamento dei job di addestramento.
L'operatore collabora anche con le funzioni di monitoraggio HyperPod dello stato di salute e osservabilità, fornendo visibilità in tempo reale sull'esecuzione della formazione e il monitoraggio automatico di parametri critici come i picchi di perdita e il degrado della produttività. Puoi definire le policy di ripristino tramite semplici configurazioni YAML senza modifiche al codice, che consentono di rispondere rapidamente e ripristinare gli stati irreversibili dell’addestramento. Queste funzionalità di monitoraggio e ripristino interagiscono per garantire prestazioni di addestramento ottimali riducendo al minimo il sovraccarico operativo.
Sebbene Kueue non sia necessario per questo operatore di addestramento, l’amministratore del cluster può installarlo e configurarlo per migliorare le capacità di pianificazione dei processi. Per ulteriori informazioni, consulta la [documentazione ufficiale di Kueue](https://kueue.sigs.k8s.io/docs/overview/).
**Nota**
Per utilizzare l'operatore di formazione, è necessario utilizzare l'ultima [versione HyperPod AMI](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-release-ami-eks.html). Per eseguire l'aggiornamento, utilizzate l'operazione [ UpdateClusterSoftware](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_UpdateClusterSoftware.html)API. Se utilizzi la [governance delle HyperPod attività](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-eks-operate-console-ui-governance.html), deve essere anche la versione più recente.
## Versioni supportate
L'operatore di HyperPod formazione funziona solo con versioni specifiche di Kubernetes, Kueue e. HyperPod Consulta l’elenco seguente per conoscere tutte le versioni compatibili.
+ Versioni di Kubernetes supportate: 1.28, 1.29, 1.30, 1.31, 1.32 e 1.33
+ Versioni di Kueue consigliate: [v.0.12.2](https://github.com/kubernetes-sigs/kueue/releases/tag/v0.12.2) e [v.0.12.3](https://github.com/kubernetes-sigs/kueue/releases/tag/v0.12.3)
+ L'ultima versione HyperPod AMI. Per eseguire l'aggiornamento alla versione AMI più recente, utilizza l'[ UpdateClusterSoftware](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_UpdateClusterSoftware.html)API.
+ [PyTorch 2.4.0 — 2.7.1](https://github.com/pytorch/pytorch/releases)
**Nota**
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.
# Installazione dell’operatore di addestramento
Consulta le sezioni seguenti per ulteriori informazioni su come installare l’operatore di addestramento.
## Prerequisiti
Prima di utilizzare l'operatore HyperPod di formazione, è necessario aver completato i seguenti prerequisiti:
+ [Creato un 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).
+ Hai installato l'AMI più recente sul tuo HyperPod cluster. Per ulteriori informazioni, consulta [SageMaker HyperPod Versioni AMI per Amazon EKS](sagemaker-hyperpod-release-ami-eks.md).
+ [Hai installato cert-manager](https://cert-manager.io/docs/installation/).
+ [Hai configurato l’agente EKS Pod Identity dalla console](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-agent-setup.html). Se desideri utilizzare il AWS CLI, usa il seguente comando:
```
aws eks create-addon \
--cluster-name my-eks-cluster \
--addon-name eks-pod-identity-agent \
--region Regione AWS
```
+ (Facoltativo) Se esegui i nodi HyperPod del cluster in un VPC privato, devi configurare gli endpoint PrivateLinks VPC per l'API Amazon AI (`com.amazonaws.aws-region.sagemaker.api`) e i servizi di autenticazione SageMaker Amazon EKS (com.amazonaws). *aws-region*.eks-auth). È inoltre necessario assicurarsi che i nodi del cluster funzionino con sottoreti che fanno parte di un gruppo di sicurezza che consente al traffico di instradare il traffico attraverso gli endpoint VPC per comunicare con AI SageMaker e Amazon EKS. Se questi non sono configurati correttamente, l'installazione del componente aggiuntivo può fallire. Per ulteriori informazioni sulla configurazione degli endpoint VPC, consulta Creare [un endpoint VPC](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#create-interface-endpoint-aws).
## Installazione dell’operatore di addestramento
Ora puoi installare l'operatore di HyperPod formazione tramite la console SageMaker AI, la console Amazon EKS o con i metodi AWS CLI La console offrono esperienze semplificate che ti aiutano a installare l'operatore. AWS CLI Offre un approccio programmatico che consente di personalizzare una parte maggiore dell'installazione.
Tra le due esperienze di console, l' SageMaker intelligenza artificiale fornisce un'installazione con un solo clic, crea il ruolo di esecuzione IAM, crea l'associazione di identità del pod e installa l'operatore. L’installazione con la console di Amazon EKS è simile, ma non crea automaticamente il ruolo di esecuzione IAM. Durante questo processo, puoi scegliere di creare un nuovo ruolo di esecuzione IAM con le informazioni precompilate dalla console. Per impostazione predefinita, i ruoli che crei hanno accesso solo al cluster corrente in cui stai installando l’operatore. A meno che non modifichi le autorizzazioni del ruolo per includere altri cluster, devi creare un nuovo ruolo se rimuovi e reinstalli l’operatore.
------
#### [ SageMaker AI console (recommended) ]
1. Apri la console Amazon SageMaker AI all'indirizzo [https://console.aws.amazon.com/sagemaker/](https://console.aws.amazon.com/sagemaker/).
1. Vai alla pagina dei dettagli del cluster.
1. Nella scheda **Dashboard**, individua il componente aggiuntivo denominato **Amazon SageMaker HyperPod training operator** e scegli **installa**. Durante il processo di installazione, l' SageMaker intelligenza artificiale crea un ruolo di esecuzione IAM con autorizzazioni simili alla policy [ AmazonSageMakerHyperPodTrainingOperatorAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonSageMakerHyperPodTrainingOperatorAccess.html)gestita e crea un'associazione di identità del pod tra il cluster Amazon EKS e il nuovo ruolo di esecuzione.
------
#### [ Amazon EKS console ]
**Nota**
Se installi il componente aggiuntivo tramite il cluster Amazon EKS, assicurati innanzitutto di aver taggato il HyperPod cluster con la coppia chiave-valore. `SageMaker:true` In caso contrario, l’installazione non riuscirà.
1. Apri la console Amazon EKS a [https://console.aws.amazon.com/eks/home\$1/clusters](https://console.aws.amazon.com/eks/home#/clusters).
1. Vai al cluster EKS, scegli **Componenti aggiuntivi**, quindi seleziona **Ottieni altri componenti aggiuntivi**.
1. Scegli Amazon SageMaker HyperPod Training Operator, quindi scegli **Avanti**.
1. In **Versione**, consigliamo di utilizzare l’impostazione predefinita della console, ovvero la versione più recente.
1. In **Accesso aggiuntivo**, scegli un ruolo IAM per Pod Identity da utilizzare con il componente aggiuntivo dell’operatore di addestramento. Se non disponi già di un ruolo, scegli **Crea ruolo consigliato** per crearne uno.
1. Durante questo processo di creazione del ruolo, la console IAM precompila tutte le informazioni necessarie, come il caso d'uso, la policy [ AmazonSageMakerHyperPodTrainingOperatorAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonSageMakerHyperPodTrainingOperatorAccess.html)gestita e le altre autorizzazioni richieste, il nome del ruolo e la descrizione. Prosegui con le varie fasi, controlla le informazioni e scegli **Crea ruolo**.
1. Nella console EKS, rivedi le impostazioni del componente aggiuntivo, quindi scegli **Crea**.
------
#### [ CLI ]
1. Assicurati che il ruolo di esecuzione IAM per il tuo HyperPod cluster abbia una relazione di fiducia che consenta a EKS Pod Identity di assumere il ruolo o di [creare un nuovo ruolo IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create.html) con la seguente politica di fiducia. In alternativa, puoi utilizzare la console di Amazon EKS per installare il componente aggiuntivo, che crea un ruolo consigliato.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowEksAuthToAssumeRoleForPodIdentity",
"Effect": "Allow",
"Principal": {
"Service": "pods.eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession",
"eks-auth:AssumeRoleForPodIdentity"
]
}
]
}
```
------
1. Allega la [policy AmazonSageMakerHyperPodTrainingOperatorAccess gestita](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonSageMakerHyperPodTrainingOperatorAccess.html) al ruolo che hai creato.
1. [Quindi, crea un’associazione Pod Identity tra il cluster EKS, il ruolo IAM e il nuovo ruolo IAM](https://docs.aws.amazon.com/eks/latest/userguide/pod-identities.html).
```
aws eks create-pod-identity-association \
--cluster-name my-eks-cluster \
--role-arn ARN of your execution role \
--namespace aws-hyperpod \
--service-account hp-training-operator-controller-manager \
--region Regione AWS
```
1. Al termine del processo, è possibile utilizzare l' ListPodIdentityAssociations operazione per visualizzare l'associazione creata. Il possibile aspetto è mostrato nella seguente risposta di esempio.
```
aws eks list-pod-identity-associations --cluster-name my-eks-cluster
{
"associations": [{
"clusterName": "my-eks-cluster",
"namespace": "aws-hyperpod",
"serviceAccount": "hp-training-operator-controller-manager",
"associationArn": "arn:aws:eks:us-east-2:123456789012:podidentityassociation/my-hyperpod-cluster/a-1a2b3c4d5e6f7g8h9",
"associationId": "a-1a2b3c4d5e6f7g8h9"
}]
}
```
1. Per installare l’operatore di addestramento, utilizza l’operazione `create-addon`. Il parametro `--addon-version` è facoltativo. Se non ne fornisci uno, l’impostazione predefinita è la versione più recente. Per ottenere le versioni possibili, utilizzate l'[ DescribeAddonVersions](https://docs.aws.amazon.com/eks/latest/APIReference/API_DescribeAddonVersions.html)operazione.
```
aws eks create-addon \
--cluster-name my-eks-cluster \
--addon-name amazon-sagemaker-hyperpod-training-operator \
--resolve-conflicts OVERWRITE
```
------
Se hai già installato l'operatore di formazione sul tuo HyperPod cluster, puoi aggiornare il componente aggiuntivo EKS alla versione che desideri. Se desideri utilizzare l'[allenamento senza checkpoint o l'allenamento](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-eks-checkpointless.html) [elastico](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-eks-elastic-training.html), considera quanto segue:
+ Sia l'allenamento senza checkpoint che l'allenamento elastico richiedono che il componente aggiuntivo EKS sia nella versione 1.2.0 o successiva.
+ L'operatore di SageMaker HyperPod formazione di Amazon mantiene la retrocompatibilità per qualsiasi versione aggiuntiva EKS, quindi puoi eseguire l'aggiornamento da qualsiasi versione aggiuntiva alla 1.2.0 o superiore.
+ Se effettui il downgrade dalla versione 1.2.0 o successiva a una versione precedente, devi prima eliminare i lavori esistenti prima del downgrade e inviare nuovamente i lavori dopo il completamento del downgrade.
------
#### [ Amazon EKS Console ]
1. Apri la console Amazon EKS a [https://console.aws.amazon.com/eks/home\$1/clusters](https://console.aws.amazon.com/eks/home#/clusters).
1. **Vai al tuo cluster EKS e scegli Componenti aggiuntivi.** Quindi, scegli il componente aggiuntivo Amazon SageMaker HyperPod Training Operator e scegli **Modifica**.
1. Nel menu **Versione**, scegli la versione del componente aggiuntivo che desideri, quindi scegli **Salva** modifiche.
------
#### [ CLI ]
1. Per prima cosa ottieni l'elenco delle versioni supportate del componente aggiuntivo per il tuo cluster.
```
aws eks describe-addon-versions \
--kubernetes-version $(aws eks describe-cluster --name my-eks-cluster --query 'cluster.version' --output text) \
--addon-name amazon-sagemaker-hyperpod-training-operator \
--query 'addons[0].addonVersions[].addonVersion' \
--output table
```
1. Quindi aggiorna il componente aggiuntivo alla versione che desideri.
```
aws eks update-addon \
--cluster-name my-eks-cluster \
--addon-name amazon-sagemaker-hyperpod-training-operator \
--addon-version target-version
--resolve-conflicts OVERWRITE
```
------
L’operatore di addestramento offre diverse opzioni con valori predefiniti che potrebbero essere adatte al tuo caso d’uso. Prima di modificarle, consigliamo di provare l’operatore di addestramento con i valori predefiniti. La tabella seguente descrive tutti i parametri e gli esempi che spiegano quando potrebbe essere utile configurare i singoli parametri.
| Parametro | Description | Predefinita |
| --- | --- | --- |
| hpTrainingControllerManager.Manager.Resources.Requests.CPU | Quanti processori allocare per il controller | 1 |
| hpTrainingControllerManager.Manager.Resources.Requests.Memoria | Quanta memoria allocare per il controller | 2Gi |
| hpTrainingControllerManager.Manager.Resources.Limits.CPU | Il limite della CPU per il controller | 2 |
| hpTrainingControllerManager.Manager.Resources.Limits.Memoria | Il limite della memoria per il controller | 4Gi |
| hpTrainingControllerManager.NodeSelector | Selettore di nodi per i pod del controller | Il comportamento predefinito consiste nel selezionare i nodi con l’etichetta sagemaker.amazonaws.com/compute-type: "HyperPod" |
## HyperPod agente elastico
L'agente HyperPod elastico è un'estensione [PyTorchdi s ElasticAgent](https://docs.pytorch.org/docs/stable/elastic/agent.html). Orchestra i cicli di vita dei lavoratori addetti alla formazione su ogni container e comunica con l'operatore addetto alla formazione. HyperPod Per utilizzare l'operatore addetto alla HyperPod formazione, è necessario installare l'agente HyperPod elastico nell'immagine di formazione prima di poter inviare ed eseguire i lavori utilizzando l'operatore. Il seguente è un file Docker che installa l’agente elastico e utilizza `hyperpodrun` per creare l’utilità di avvio dei processi.
**Nota**
Sia l'[allenamento senza checkpoint che l'allenamento](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-eks-checkpointless.html) [elastico](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-eks-elastic-training.html) richiedono l'utilizzo della versione 1.1.0 o successiva di HyperPod elastic agent.
```
RUN pip install hyperpod-elastic-agent
ENTRYPOINT ["entrypoint.sh"]
# entrypoint.sh
...
hyperpodrun --nnodes=node_count --nproc-per-node=proc_count \
--rdzv-backend hyperpod \ # Optional
--inprocess-restart \ # Optional (in-process fault recovery with checkpointless training)
... # Other torchrun args
# pre-traing arg_group
--pre-train-script pre.sh --pre-train-args "pre_1 pre_2 pre_3" \
# post-train arg_group
--post-train-script post.sh --post-train-args "post_1 post_2 post_3" \
training.py --script-args
```
Ora puoi inviare processi con `kubectl`.
### HyperPod argomenti dell'agente elastico
L'agente HyperPod elastico supporta tutti gli argomenti originali e aggiunge alcuni argomenti aggiuntivi. Di seguito sono riportati tutti gli argomenti disponibili nell'agente HyperPod elastico. Per ulteriori informazioni su PyTorch Elastic Agent, consulta la loro [documentazione ufficiale](https://docs.pytorch.org/docs/stable/elastic/agent.html).
| Argomento | Description | Valore predefinito |
| --- | --- | --- |
| --shutdown-signal | Segnale da inviare ai worker per lo spegnimento (SIGTERM o SIGKILL) | “SIGKILL” |
| --shutdown-timeout | Timeout in secondi tra il segnale di spegnimento e i segnali SIGKILL | 15 |
| --server-host | Indirizzo del server dell’agente | “0.0.0.0” |
| --server-port | Porta del server dell’agente | 8080 |
| --server-log-level | Livello dei log del server dell’agente | “info” |
| --server-shutdown-timeout | Timeout di spegnimento del server in secondi | 300 |
| --pre-train-script | Percorso dello script di preaddestramento | Nessuno |
| --pre-train-args | Argomenti per lo script di preaddestramento | Nessuno |
| --post-train-script | Percorso dello script di post-addestramento | Nessuno |
| --post-train-args | Argomenti per lo script di post-addestramento | Nessuno |
| --inprocess-restart | Contrassegno che specifica se utilizzare la funzionalità inprocess\$1restart | FALSE |
| --inprocess-timeout | Tempo in secondi in cui l'agente attende che i lavoratori raggiungano una barriera di sincronizzazione prima di attivare un riavvio a livello di processo. | Nessuno |
## Governance delle attività (facoltativo)
L'operatore di formazione è integrato con la [governance delle HyperPod attività](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-eks-operate-console-ui-governance), 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. Per configurare la governance delle attività, consulta. HyperPod [Configurazione per la governance SageMaker HyperPod delle attività](sagemaker-hyperpod-eks-operate-console-ui-governance-setup.md)
**Nota**
Quando si installa il componente aggiuntivo per la governance delle HyperPod attività, è necessario utilizzare la versione v1.3.0-eksbuild.1 o successiva.
Quando invii un processo, assicurati di includere il nome della coda e le etichette della classe di priorità di `hyperpod-ns-team-name-localqueue` e `priority-class-name-priority`. Ad esempio, se utilizzi Kueue, le etichette diventano:
+ *team-name*kueue.x-k8s.io/queue-name: hyperpod-ns- -localqueue
+ kueue.x-k8s.io/priority-class: -name-priority *priority-class*
Di seguito è riportato un esempio di come potrebbe essere il tuo file di configurazione:
```
apiVersion: sagemaker.amazonaws.com/v1
kind: HyperPodPytorchJob
metadata:
name: hp-task-governance-sample
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:
nprocPerNode: "1"
runPolicy:
cleanPodPolicy: "None"
replicaSpecs:
- name: pods
replicas: 4
spares: 2
template:
spec:
containers:
- name: ptjob
image: XXXX
imagePullPolicy: Always
ports:
- containerPort: 8080
resources:
requests:
cpu: "2"
```
Quindi utilizza il comando kubectl seguente per applicare il file YAML.
```
kubectl apply -f task-governance-job.yaml
```
## Kueue (facoltativo)
Sebbene sia possibile eseguire direttamente i processi, l’organizzazione può anche integrare l’operatore di addestramento con Kueue per allocare le risorse e pianificare i processi. Segui i passaggi seguenti per installare Kueue nel tuo cluster. HyperPod
1. Segui le istruzioni di installazione nella [documentazione ufficiale di Kueue](https://kueue.sigs.k8s.io/docs/installation/#install-a-custom-configured-released-version). Quando raggiungi la fase di configurazione di `controller_manager_config.yaml`, aggiungi la configurazione seguente:
```
externalFrameworks:
- "HyperPodPytorchJob.v1.sagemaker.amazonaws.com"
```
1. Segui le altre fasi indicate nella guida di installazione ufficiale. Dopo aver terminato l’installazione di Kueue, puoi creare alcune code di esempio con il comando `kubectl apply -f sample-queues.yaml`. Utilizza il file YAML seguente.
```
apiVersion: kueue.x-k8s.io/v1beta1
kind: ClusterQueue
metadata:
name: cluster-queue
spec:
namespaceSelector: {}
preemption:
withinClusterQueue: LowerPriority
resourceGroups:
- coveredResources:
- cpu
- nvidia.com/gpu
- pods
flavors:
- name: default-flavor
resources:
- name: cpu
nominalQuota: 16
- name: nvidia.com/gpu
nominalQuota: 16
- name: pods
nominalQuota: 16
---
apiVersion: kueue.x-k8s.io/v1beta1
kind: LocalQueue
metadata:
name: user-queue
namespace: default
spec:
clusterQueue: cluster-queue
---
apiVersion: kueue.x-k8s.io/v1beta1
kind: ResourceFlavor
metadata:
name: default-flavor
---
apiVersion: kueue.x-k8s.io/v1beta1
description: High priority
kind: WorkloadPriorityClass
metadata:
name: high-priority-class
value: 1000
---
apiVersion: kueue.x-k8s.io/v1beta1
description: Low Priority
kind: WorkloadPriorityClass
metadata:
name: low-priority-class
value: 500
```
# Utilizzo dell’operatore di addestramento per eseguire i processi
Per eseguire i processi con kubectl, devi creare un file job.yaml con le specifiche del processo ed eseguire `kubectl apply -f job.yaml` per inviare il processo. In questo file YAML, puoi specificare configurazioni personalizzate nell’argomento `logMonitoringConfiguration` per definire le regole di monitoraggio automatizzato che analizzano gli output dei log dei job di addestramento distribuito per rilevare problemi ed eseguire il ripristino.
```
apiVersion: sagemaker.amazonaws.com/v1
kind: HyperPodPyTorchJob
metadata:
labels:
app.kubernetes.io/name: HyperPod
app.kubernetes.io/managed-by: kustomize
name: &jobname xxx
annotations:
XXX: XXX
......
spec:
nprocPerNode: "X"
replicaSpecs:
- name: 'XXX'
replicas: 16
template:
spec:
nodeSelector:
beta.kubernetes.io/instance-type: ml.p5.48xlarge
containers:
- name: XXX
image: XXX
imagePullPolicy: Always
ports:
- containerPort: 8080 # This is the port that HyperPodElasticAgent listens to
resources:
limits:
nvidia.com/gpu: 8
hugepages-2Mi: 5120Mi
requests:
nvidia.com/gpu: 8
hugepages-2Mi: 5120Mi
memory: 32000Mi
......
runPolicy:
jobMaxRetryCount: 50
restartPolicy:
numRestartBeforeFullJobRestart: 3
evalPeriodSeconds: 21600
maxFullJobRestarts: 1
cleanPodPolicy: "All"
logMonitoringConfiguration:
- name: "JobStart"
logPattern: ".*Experiment configuration.*" # This is the start of the training script
expectedStartCutOffInSeconds: 120 # Expected match in the first 2 minutes
- name: "JobHangingDetection"
logPattern: ".*\\[Epoch 0 Batch \\d+.*'training_loss_step': (\\d+(\\.\\d+)?).*"
expectedRecurringFrequencyInSeconds: 300 # If next batch is not printed within 5 minute, consider it hangs. Or if loss is not decimal (e.g. nan) for 2 minutes, mark it hang as well.
expectedStartCutOffInSeconds: 600 # Allow 10 minutes of job startup time
- name: "NoS3CheckpointingDetection"
logPattern: ".*The checkpoint is finalized. All shards is written.*"
expectedRecurringFrequencyInSeconds: 600 # If next checkpoint s3 upload doesn't happen within 10 mins, mark it hang.
expectedStartCutOffInSeconds: 1800 # Allow 30 minutes for first checkpoint upload
- name: "LowThroughputDetection"
logPattern: ".*\\[Epoch 0 Batch \\d+.*'samples\\/sec': (\\d+(\\.\\d+)?).*"
metricThreshold: 80 # 80 samples/sec
operator: "lteq"
metricEvaluationDataPoints: 25 # if throughput lower than threshold for 25 datapoints, kill the job
```
Se desideri utilizzare le opzioni di monitoraggio del registro, assicurati di inviare il registro di allenamento a. `sys.stdout` HyperPod elastic agent monitora i log di allenamento in sys.stdout, che viene salvato in. `/tmp/hyperpod/` Per emettere i log di addestramento, puoi utilizzare il comando seguente.
```
logging.basicConfig(format="%(asctime)s [%(levelname)s] %(name)s: %(message)s", level=logging.INFO, stream=sys.stdout)
```
Nella tabella seguente sono descritte tutte le possibili configurazioni di monitoraggio dei log:
| Parametro | Utilizzo |
| --- | --- |
| jobMaxRetryConta | Numero massimo di riavvii a livello di processo. |
| Politica di riavvio: numRestartBefore FullJobRestart | Numero massimo di riavvii a livello di processo prima che l’operatore si riavvii a livello di processo. |
| Politica di riavvio: evalPeriodSeconds | Periodo di valutazione del limite di riavvio in secondi. |
| Politica di riavvio: riavvio maxFullJob | Numero massimo di riavvii completi del processo prima dell’errore del processo. |
| cleanPodPolicy | Specifica i pod che l’operatore deve pulire. I valori accettati sono All, OnlyComplete e None. |
| logMonitoringConfiguration | Le regole di monitoraggio dei log per il rilevamento di processi lenti e sospesi. |
| expectedRecurringFrequencyInSeconds | Intervallo di tempo tra due LogPattern partite consecutive dopo il quale la regola restituisce HANGING. Se non specificato, non esiste alcun vincolo di tempo tra partite consecutive. LogPattern |
| expectedStartCutOffInSeconds | Tempo intercorso dalla prima LogPattern partita dopo il quale la regola restituisce HANGING. Se non specificato, non esiste alcun vincolo di tempo per la prima partita. LogPattern |
| logPattern | Espressione regolare che identifica le righe del log a cui si applica la regola quando è attiva. |
| metricEvaluationDataPunti | Numero di volte consecutive in cui una regola restituisce SLOW prima di contrassegnare un processo come SLOW. Se il valore non viene specificato, viene usato il valore predefinito 1. |
| metricThreshold | Soglia per il valore estratto da LogPattern con un gruppo di acquisizione. Se non specificato, la valutazione delle metriche non viene eseguita. |
| operatore | La disuguaglianza da applicare alla configurazione del monitoraggio. I valori accettati sono gt, gteq, lt, lteq e eq. |
| stopPattern | Espressione regolare per identificare la riga del log in corrispondenza della quale disattivare la regola. Se non viene specificata, la regola sarà sempre attiva. |
| faultOnMatch | Indica se una corrispondenza di LogPattern deve causare immediatamente un errore di lavoro. Se impostato su true, il lavoro verrà contrassegnato come guasto non appena verrà trovato il LogPattern risultato, indipendentemente dagli altri parametri della regola. Se falsa o non è specificata, la regola verrà valutata come SLOW o HANGING in base ad altri parametri. |
Per una maggiore resilienza dell’addestramento, specifica i dettagli di configurazione dei nodi di riserva. Se il processo non riesce, l’operatore ricorre a Kueue per utilizzare i nodi riservati in anticipo per continuare a eseguire il processo. Le configurazioni dei nodi di riserva richiedono Kueue. Di conseguenza, se provi a inviare un processo con nodi di riserva ma Kueue non è installato, il processo non riuscirà. L’esempio seguente è un file `job.yaml` di esempio che contiene le configurazioni dei nodi di riserva.
```
apiVersion: sagemaker.amazonaws.com/v1
kind: HyperPodPyTorchJob
metadata:
labels:
kueue.x-k8s.io/queue-name: user-queue # Specify the queue to run the job.
name: hyperpodpytorchjob-sample
spec:
nprocPerNode: "1"
runPolicy:
cleanPodPolicy: "None"
replicaSpecs:
- name: pods
replicas: 1
spares: 1 # Specify how many spare nodes to reserve.
template:
spec:
containers:
- name: XXX
image: XXX
imagePullPolicy: Always
ports:
- containerPort: 8080
resources:
requests:
nvidia.com/gpu: "0"
limits:
nvidia.com/gpu: "0"
```
## Monitoraggio
Amazon SageMaker HyperPod è integrato con l'[osservabilità con Amazon Managed Grafana e Amazon Managed Service for Prometheus](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-observability-addon.html), quindi puoi configurare il monitoraggio per raccogliere e inserire i parametri in questi strumenti di osservabilità.
In alternativa, puoi acquisire le metriche tramite Servizio gestito da Amazon per Prometheus senza la funzionalità di osservabilità gestita. A tale scopo, includi nel file `job.yaml` le metriche da monitorare quando esegui i processi con `kubectl`.
```
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
name: hyperpod-training-operator
namespace: aws-hyperpod
spec:
......
endpoints:
- port: 8081
path: /metrics
interval: 15s
```
Di seguito sono riportati gli eventi emessi dall’operatore di addestramento che puoi inserire in Servizio gestito da Amazon per Prometheus per monitorare i job di addestramento.
| Event | Description |
| --- | --- |
| hyperpod\$1training\$1operator\$1jobs\$1created\$1total | Numero totale di processi eseguiti dall’operatore di addestramento |
| hyperpod\$1training\$1operator\$1jobs\$1restart\$1latency | Latenza di riavvio del processo corrente |
| hyperpod\$1training\$1operator\$1jobs\$1fault\$1detection\$1latency | Latenza di rilevamento guasti |
| hyperpod\$1training\$1operator\$1jobs\$1deleted\$1total | Numero totale di processi eliminati |
| hyperpod\$1training\$1operator\$1jobs\$1successful\$1total | Numero totale di processi completati |
| hyperpod\$1training\$1operator\$1jobs\$1failed\$1total | Numero totale di processi non riusciti |
| hyperpod\$1training\$1operator\$1jobs\$1restarted\$1total | Numero totale di processi riavviati automaticamente |
## Configurazione Docker di esempio
Di seguito è riportato un file Docker di esempio che puoi eseguire con il comando `hyperpod run`.
```
export AGENT_CMD="--backend=nccl"
exec hyperpodrun --server-host=${AGENT_HOST} --server-port=${AGENT_PORT} \
--tee=3 --log_dir=/tmp/hyperpod \
--nnodes=${NNODES} --nproc-per-node=${NPROC_PER_NODE} \
--pre-train-script=/workspace/echo.sh --pre-train-args='Pre-training script' \
--post-train-script=/workspace/echo.sh --post-train-args='Post-training script' \
/workspace/mnist.py --epochs=1000 ${AGENT_CMD}
```
## Configurazioni di esempio per il monitoraggio dei log
**Rilevamento di processi bloccati**
Per rilevare i processi bloccati, utilizza le configurazioni seguenti con questi parametri:
+ expectedStartCutOffInSeconds — quanto tempo deve attendere il monitor prima di aspettarsi i primi log
+ expectedRecurringFrequencyInSeconds — l'intervallo di tempo di attesa per il successivo lotto di log
Con queste impostazioni, il monitoraggio dei log prevede di visualizzare una riga del log corrispondente al modello regex `.*Train Epoch.*` entro 60 secondi dall’inizio del job di addestramento. Dopo la prima occorrenza, il monitoraggio prevede di rilevare righe del log corrispondenti ogni 10 secondi. Se i primi registri non vengono visualizzati entro 60 secondi o i registri successivi non vengono visualizzati ogni 10 secondi, l'agente HyperPod elastico considera il contenitore bloccato e si coordina con l'operatore addetto alla formazione per riavviare il lavoro.
```
runPolicy:
jobMaxRetryCount: 10
cleanPodPolicy: "None"
logMonitoringConfiguration:
- name: "JobStartGracePeriod"
# Sample log line: [default0]:2025-06-17 05:51:29,300 [INFO] __main__: Train Epoch: 5 [0/60000 (0%)] loss=0.8470
logPattern: ".*Train Epoch.*"
expectedStartCutOffInSeconds: 60
- name: "JobHangingDetection"
logPattern: ".*Train Epoch.*"
expectedRecurringFrequencyInSeconds: 10 # if the next batch is not printed within 10 seconds
```
**Picco di perdita dell’addestramento**
La configurazione del monitoraggio seguente emette log di addestramento con il modello `xxx training_loss_step xx`. Utilizza il parametro `metricEvaluationDataPoints`, che consente di specificare una soglia di punti dati prima che l’operatore riavvii il processo. Se il valore di perdita dell’addestramento è superiore a 2,0, l’operatore riavvia il processo.
```
runPolicy:
jobMaxRetryCount: 10
cleanPodPolicy: "None"
logMonitoringConfiguration:
- name: "LossSpikeDetection"
logPattern: ".*training_loss_step (\\d+(?:\\.\\d+)?).*" # training_loss_step 5.0
metricThreshold: 2.0
operator: "gt"
metricEvaluationDataPoints: 5 # if loss higher than threshold for 5 data points, restart the job
```
**Rilevamento basso TFLOPs **
La configurazione del monitoraggio seguente emette log di addestramento con il modello `xx TFLOPs xx` ogni cinque secondi. Se TFLOPs è inferiore a 100 per 5 punti dati, l'operatore riavvia il processo di formazione.
```
runPolicy:
jobMaxRetryCount: 10
cleanPodPolicy: "None"
logMonitoringConfiguration:
- name: "TFLOPs"
logPattern: ".* (.+)TFLOPs.*" # Training model, speed: X TFLOPs...
expectedRecurringFrequencyInSeconds: 5
metricThreshold: 100 # if Tflops is less than 100 for 5 data points, restart the job
operator: "lt"
metricEvaluationDataPoints: 5
```
**Rilevamento del registro degli errori dello script di allenamento**
La seguente configurazione di monitoraggio rileva se il modello specificato in `logPattern` è presente nei registri di addestramento. Non appena l'operatore addetto alla formazione rileva lo schema di errore, lo considera un guasto e riavvia il lavoro.
```
runPolicy:
jobMaxRetryCount: 10
cleanPodPolicy: "None"
logMonitoringConfiguration:
- name: "GPU Error"
logPattern: ".*RuntimeError.*out of memory.*"
faultOnMatch: true
```
# Risoluzione dei problemi
Consulta le sezioni seguenti per scoprire come risolvere gli errori relativi all’utilizzo dell’operatore di addestramento.
## Non riesco a installare l’operatore di addestramento
Se non riesci a installare l’operatore di addestramento, assicurati di utilizzare le [versioni supportate dei componenti](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-eks-operator.html#sagemaker-eks-operator-supported-versions). Ad esempio, se ricevi un errore che indica che la tua versione HyperPod AMI è incompatibile con l'operatore di formazione, esegui [l'aggiornamento alla versione più recente](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_UpdateClusterSoftware.html).
## Versione di HyperPod task governance incompatibile
Durante l'installazione, è possibile che venga visualizzato un messaggio di errore indicante che la versione di HyperPod task governance è incompatibile. L’operatore di addestramento funziona solo con la versione v1.3.0-eksbuild.1 o successive. Aggiorna il componente aggiuntivo per la governance delle HyperPod attività e riprova.
## Autorizzazioni mancanti
Durante la configurazione dell’operatore di addestramento o l’esecuzione dei processi, potresti ricevere errori che indicano che manca l’autorizzazione per eseguire determinate operazioni, ad esempio `DescribeClusterNode`. Per risolvere questi errori, assicurati di configurare correttamente le autorizzazioni IAM quando [configuri Amazon EKS Pod Identity Agent](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-eks-operator-install.html#sagemaker-eks-operator-install-pod-identity).
# Utilizzo dell'allenamento elastico in Amazon SageMaker HyperPod
Elastic Training è una nuova SageMaker HyperPod funzionalità di Amazon che ridimensiona automaticamente i lavori di formazione in base alla disponibilità delle risorse di calcolo e alla priorità del carico di lavoro. I lavori di formazione elastica possono iniziare con le risorse di calcolo minime necessarie per l'addestramento dei modelli e scalare dinamicamente verso l'alto o verso il basso attraverso il checkpoint e la ripresa automatici su diverse configurazioni di nodi (a dimensione mondiale). La scalabilità si ottiene regolando automaticamente il numero di repliche parallele dei dati. Durante i periodi di utilizzo elevato del cluster, è possibile configurare processi di formazione elastici in modo da ridurli automaticamente in risposta alle richieste di risorse provenienti da lavori con priorità più elevata, liberando l'elaborazione per carichi di lavoro critici. Quando le risorse si liberano durante i periodi non di punta, i job di formazione elastica vengono ridimensionati automaticamente verso l'alto per accelerare la formazione, per poi ridurli quando i carichi di lavoro con priorità più alta richiedono nuovamente risorse.
Elastic Training si basa sull'operatore addetto alla HyperPod formazione e integra i seguenti componenti:
+ [Amazon EKS per l'orchestrazione di Kubernetes](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-eks.html)
+ [Amazon SageMaker HyperPod Task Governance](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-eks-operate-console-ui-governance.html) per l'accodamento, l'assegnazione delle priorità e la pianificazione dei lavori
+ [PyTorch Distributed Checkpoint (DCP)](https://docs.pytorch.org/docs/stable/distributed.checkpoint.html) per una gestione scalabile dello stato e dei checkpoint, come DCP
**Framework supportati**
+ PyTorch con Distributed Data Parallel (DDP) e Fully Sharded Data Parallel (FSDP)
+ PyTorch Checkpoint distribuito (DCP)
## Prerequisiti
### SageMaker HyperPod Cluster EKS
È necessario disporre di un SageMaker HyperPod cluster in esecuzione con orchestrazione Amazon EKS. Per informazioni sulla creazione di un cluster HyperPod EKS, consulta:
+ [Guida introduttiva ad Amazon EKS in SageMaker HyperPod](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-eks-prerequisites.html)
+ [Creazione di 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)
### SageMaker HyperPod Operatore di formazione
Elastic Training è supportato nella versione 1.2 e successive di training operator.
Per installare l'operatore di formazione come componente aggiuntivo EKS, vedi: [https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker- .html eks-operator-install](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-eks-operator-install.html)
### (Consigliato) Installa e configura Task Governance e Kueue
Consigliamo di installare e configurare Kueue tramite [HyperPod Task Governance](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-eks-operate-console-ui-governance.html) per specificare le priorità dei carichi di lavoro con un training elastico. Kueue offre una gestione più efficace del carico di lavoro con code, prioritizzazione, pianificazione dei gruppi, monitoraggio delle risorse e prelazione, essenziali per operare in ambienti di formazione multi-tenant.
+ La pianificazione in gruppo garantisce che tutti i moduli necessari per un lavoro di formazione inizino insieme. In questo modo si evitano situazioni in cui alcuni pod vengono avviati mentre altri rimangono in sospeso, il che potrebbe causare uno spreco di risorse.
+ La priorità delicata consente ai lavori elastici con priorità più bassa di destinare risorse a carichi di lavoro con priorità più elevata. I lavori elastici possono essere ridimensionati senza essere sfrattati con la forza, migliorando la stabilità complessiva del cluster.
Consigliamo di configurare i seguenti componenti Kueue:
+ PriorityClasses per definire l'importanza relativa del lavoro
+ ClusterQueues per gestire la condivisione globale delle risorse e le quote tra team o carichi di lavoro
+ LocalQueues per indirizzare i lavori dai singoli namespace a quelli appropriati ClusterQueue
Per configurazioni più avanzate, puoi anche incorporare:
+ Politiche di condivisione equa per bilanciare l'utilizzo delle risorse tra più team
+ Regole di priorità personalizzate per applicare il controllo organizzativo o dei costi SLAs
Si prega di fare riferimento a:
+ [https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker- hyperpod-eks-operate-console -ui-governance.html](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-eks-operate-console-ui-governance.html)
+ [Documentazione Kueue](https://kueue.sigs.k8s.io/)
### (Consigliato) Imposta i namespace utente e le quote di risorse
Quando si implementa questa funzionalità su Amazon EKS, consigliamo di applicare una serie di configurazioni di base a livello di cluster per garantire l'isolamento, l'equità delle risorse e la coerenza operativa tra i team.
#### Configurazione dello spazio dei nomi e degli accessi
Organizza i tuoi carichi di lavoro utilizzando namespace separati per ogni team o progetto. Ciò consente di applicare un isolamento e una governance granulari. Consigliamo inoltre di configurare la mappatura RBAC da AWS IAM a Kubernetes per associare singoli utenti o ruoli IAM ai namespace corrispondenti.
Le pratiche chiave includono:
+ Mappa i ruoli IAM sugli account di servizio Kubernetes utilizzando IAM Roles for Service Accounts (IRSA) quando i carichi di lavoro richiedono autorizzazioni. AWS [https://docs.aws.amazon.com/eks/latest/userguide/access-entries.html](https://docs.aws.amazon.com/eks/latest/userguide/access-entries.html)
+ Applica le politiche RBAC per limitare gli utenti solo ai namespace designati (ad esempio,`Role`/`RoleBinding`anziché alle autorizzazioni a livello di cluster).
#### Vincoli relativi alle risorse e al calcolo
Per prevenire la contesa delle risorse e garantire una pianificazione equa tra i team, applica quote e limiti a livello di namespace:
+ ResourceQuotas per limitare il numero aggregato di CPU, memoria, storage e oggetti (pod, servizi, PVCs ecc.).
+ LimitRanges per applicare i limiti predefiniti e massimi di CPU e memoria per pod o per contenitore.
+ PodDisruptionBudgets (PDBs) se necessario per definire le aspettative di resilienza.
+ Facoltativo: vincoli di accodamento a livello di namespace (ad esempio, tramite Task Governance o Kueue) per impedire agli utenti di inviare lavori in modo eccessivo.
Questi vincoli aiutano a mantenere la stabilità del cluster e supportano una pianificazione prevedibile per carichi di lavoro di formazione distribuiti.
#### Dimensionamento automatico
SageMaker HyperPod su EKS supporta la scalabilità automatica dei cluster tramite Karpenter. Quando Karpenter o un fornitore di risorse simile vengono utilizzati insieme alla formazione elastica, il cluster e il lavoro di formazione elastica possono aumentare automaticamente dopo l'invio di un lavoro di formazione elastica. Questo perché elastic training operator adotta un approccio avido, richiede sempre più risorse di calcolo rispetto alle risorse di calcolo disponibili fino a raggiungere il limite massimo stabilito dal lavoro. Ciò si verifica perché l'operatore di elastic training richiede continuamente risorse aggiuntive come parte dell'esecuzione elastica del lavoro, il che può attivare il provisioning dei nodi. I fornitori continui di risorse come Karpenter soddisferanno le richieste scalando il cluster di calcolo.
Per mantenere queste scalabilità prevedibili e sotto controllo, consigliamo di configurare a livello di ResourceQuotas namespace negli spazi dei nomi in cui vengono creati i job di training elastici. ResourceQuotas aiutano a limitare il numero massimo di risorse che i job possono richiedere, prevenendo la crescita illimitata dei cluster e permettendo comunque un comportamento elastico entro limiti definiti.
Ad esempio, una istanza da ResourceQuota 8 ml.p5.48xlarge avrà il seguente formato:
```
apiVersion: v1
kind: ResourceQuota
metadata:
name:
namespace:
spec:
hard:
nvidia.com/gpu: "64"
vpc.amazonaws.com/efa: "256"
requests.cpu: "1536"
requests.memory: "5120Gi"
limits.cpu: "1536"
limits.memory: "5120Gi"
```
## Costruisci un contenitore di formazione
HyperPod [l'operatore addetto alla formazione lavora con un programma di PyTorch avvio personalizzato fornito tramite il pacchetto Python di HyperPod Elastic Agent (https://www.piwheels). org/project/hyperpod](https://www.piwheels.org/project/hyperpod-elastic-agent/)-elastic-agent/). I clienti devono installare l'agente elastico e sostituire il `torchrun` comando con to launch training. `hyperpodrun` Per maggiori dettagli, consulta:
[https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker- eks-operator-install .html\$1 sagemaker-eks-operator-elastic -agent](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-eks-operator-install.html#sagemaker-eks-operator-elastic-agent)
Un esempio di contenitore di formazione:
```
FROM ...
...
RUN pip install hyperpod-elastic-agent
ENTRYPOINT ["entrypoint.sh"]
# entrypoint.sh ...
hyperpodrun --nnodes=node_count --nproc-per-node=proc_count \
--rdzv-backend hyperpod \
# Optional ...
# Other torchrun args
# pre-traing arg_group
--pre-train-script pre.sh --pre-train-args "pre_1 pre_2 pre_3" \
# post-train arg_group
--post-train-script post.sh --post-train-args "post_1 post_2 post_3" \
training.py --script-args
```
## Modifica del codice di allenamento
SageMaker HyperPod fornisce un set di ricette già configurate per l'esecuzione con Elastic Policy.
Per abilitare l'allenamento elastico per script di PyTorch allenamento personalizzati, dovrai apportare piccole modifiche al ciclo di allenamento. Questa guida illustra le modifiche necessarie per garantire che il processo di formazione risponda agli eventi di scalabilità elastica che si verificano quando la disponibilità delle risorse di calcolo cambia. Durante tutti gli eventi elastici (ad esempio, i nodi sono disponibili o i nodi vengono bloccati), il job di formazione riceve un segnale di evento elastico che viene utilizzato per coordinare uno spegnimento regolare salvando un checkpoint e riprendere l'allenamento riavviando da quel checkpoint salvato con una nuova configurazione mondiale. Per abilitare l'allenamento elastico con script di allenamento personalizzati, devi:
### Rilevare eventi Elastic Scaling
Nel ciclo di allenamento, verifica la presenza di eventi elastici durante ogni iterazione:
```
from hyperpod_elastic_agent.elastic_event_handler import elastic_event_detected
def train_epoch(model, dataloader, optimizer, args):
for batch_idx, batch_data in enumerate(dataloader):
# Forward and backward pass
loss = model(batch_data).loss
loss.backward()
optimizer.step()
optimizer.zero_grad()
# Handle checkpointing and elastic scaling
should_checkpoint = (batch_idx + 1) % args.checkpoint_freq == 0
elastic_event = elastic_event_detected()
# Save checkpoint if scaling-up or scaling down job
if should_checkpoint or elastic_event:
save_checkpoint(model, optimizer, scheduler,
checkpoint_dir=args.checkpoint_dir,
step=global_step)
if elastic_event:
print("Elastic scaling event detected. Checkpoint saved.")
return
```
### Implementa Checkpoint Saving e Checkpoint Loading
Nota: consigliamo di utilizzare PyTorch Distributed Checkpoint (DCP) per salvare gli stati del modello e dell'ottimizzatore, poiché DCP supporta la ripresa da un checkpoint con dimensioni mondiali diverse. Altri formati di checkpoint potrebbero non supportare il caricamento dei checkpoint su mondi di dimensioni diverse, nel qual caso dovrai implementare una logica personalizzata per gestire le modifiche dinamiche delle dimensioni mondiali.
```
import torch.distributed.checkpoint as dcp
from torch.distributed.checkpoint.state_dict import get_state_dict, set_state_dict
def save_checkpoint(model, optimizer, lr_scheduler, user_content, checkpoint_path):
"""Save checkpoint using DCP for elastic training."""
state_dict = {
"model": model,
"optimizer": optimizer,
"lr_scheduler": lr_scheduler,
**user_content
}
dcp.save(
state_dict=state_dict,
storage_writer=dcp.FileSystemWriter(checkpoint_path)
)
def load_checkpoint(model, optimizer, lr_scheduler, checkpoint_path):
"""Load checkpoint using DCP with automatic resharding."""
state_dict = {
"model": model,
"optimizer": optimizer,
"lr_scheduler": lr_scheduler
}
dcp.load(
state_dict=state_dict,
storage_reader=dcp.FileSystemReader(checkpoint_path)
)
return model, optimizer, lr_scheduler
```
### (Facoltativo) Usa dataloader stateful
Se ti stai allenando solo per una singola epoca (ad esempio, un singolo passaggio attraverso l'intero set di dati), il modello deve vedere ogni campione di dati esattamente una volta. Se il processo di addestramento si interrompe a metà epoca e riprende con una dimensione mondiale diversa, i campioni di dati precedentemente elaborati verranno ripetuti se lo stato del dataloader non è persistente. Un dataloader con stato impedisce che ciò accada salvando e ripristinando la posizione del dataloader, assicurando che le esecuzioni riprese continuino dopo l'evento di scalabilità elastica senza rielaborare alcun campione. Consigliamo di utilizzare [StatefulDataLoader](https://meta-pytorch.org/data/main/torchdata.stateful_dataloader.html), che sostituisce direttamente tali aggiunte e metodi, che abiliti il checkpoint a metà periodo del processo di caricamento dei `torch.utils.data.DataLoader` dati. `state_dict()` `load_state_dict()`
## Invio di lavori di formazione elastici
[HyperPod l'operatore di formazione](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-eks-operator-usage.html) definisce un nuovo tipo di risorsa -`hyperpodpytorchjob`. Elastic Training estende questo tipo di risorsa e aggiunge i campi evidenziati di seguito:
```
apiVersion: sagemaker.amazonaws.com/v1
kind: HyperPodPyTorchJob
metadata:
name: elastic-training-job
spec:
elasticPolicy:
minReplicas: 1
maxReplicas: 4
# Increment amount of pods in fixed-size groups
# Amount of pods will be equal to minReplicas + N * replicaIncrementStep
replicaIncrementStep: 1
# ... or Provide an exact amount of pods that required for training
replicaDiscreteValues: [2,4,8]
# How long traing operator wait job to save checkpoint and exit during
# scaling events. Job will be force-stopped after this period of time
gracefulShutdownTimeoutInSeconds: 600
# When scaling event is detected:
# how long job controller waits before initiate scale-up.
# Some delay can prevent from frequent scale-ups and scale-downs
scalingTimeoutInSeconds: 60
# In case of faults, specify how long elastic training should wait for
# recovery, before triggering a scale-down
faultyScaleDownTimeoutInSeconds: 30
...
replicaSpecs:
- name: pods
replicas: 4 # Initial replica count
maxReplicas: 8 # Max for this replica spec (should match elasticPolicy.maxReplicas)
...
```
### Usare kubectl
Successivamente puoi avviare l'allenamento elastico con il seguente comando.
```
kubectl apply -f elastic-training-job.yaml
```
### Utilizzo delle SageMaker ricette
I lavori di Elastic Training possono essere avviati tramite [SageMaker HyperPod ricette](https://github.com/aws/sagemaker-hyperpod-recipes).
**Nota**
Abbiamo incluso **46** ricette elastiche per i lavori **SFO** e **DPO** su Hyperpod Recipe. Gli utenti possono avviare questi lavori con una sola modifica di riga sullo script di avvio statico esistente:
`++recipes.elastic_policy.is_elastic=true`
Oltre alle ricette statiche, le ricette elastiche aggiungono i seguenti campi per definire i comportamenti elastici:
#### Politica elastica
Il `elastic_policy` campo definisce la configurazione a livello di lavoro per il job di elastic training, ha le seguenti configurazioni:
+ `is_elastic`: `bool` - se questo lavoro è un lavoro elastico
+ `min_nodes`: `int` - il numero minimo di nodi utilizzati per l'allenamento elastico
+ `max_nodes`: `int` - il numero massimo di nodi utilizzati per l'allenamento elastico
+ `replica_increment_step`: `int` - incrementa la quantità di pod in gruppi a dimensione fissa, questo campo si esclude a vicenda per quello che definiremo più avanti. `scale_config`
+ `use_graceful_shutdown`: `bool` - se si utilizza Graceful Shutdown durante gli eventi di ridimensionamento, l'impostazione predefinita è. `true`
+ `scaling_timeout`: `int` - il tempo di attesa in secondi durante l'evento di ridimensionamento prima del timeout
+ `graceful_shutdown_timeout`: `int` - il tempo di attesa per lo spegnimento graduale
Di seguito è riportato un esempio di definizione di questo campo, che puoi trovare anche nel repository Hyperpod Recipe in recipe: `recipes_collection/recipes/fine-tuning/llama/llmft_llama3_1_8b_instruct_seq4k_gpu_sft_lora.yaml`
```
...
elastic_policy:
is_elastic: true
min_nodes: 1
max_nodes: 16
use_graceful_shutdown: true
scaling_timeout: 600
graceful_shutdown_timeout: 600
```
#### Config della scala
Il `scale_config` campo definisce le configurazioni prioritarie su ogni scala specifica. È un dizionario chiave-valore, dove key è un numero intero che rappresenta la scala di destinazione e value è un sottoinsieme della ricetta base. Su `` larga scala, utilizziamo il `` per aggiornare le configurazioni specifiche nella ricetta. base/static Di seguito viene mostrato un esempio di questo campo:
```
scale_config:
...
2:
trainer:
num_nodes: 2
training_config:
training_args:
train_batch_size: 128
micro_train_batch_size: 8
learning_rate: 0.0004
3:
trainer:
num_nodes: 3
training_config:
training_args:
train_batch_size: 128
learning_rate: 0.0004
uneven_batch:
use_uneven_batch: true
num_dp_groups_with_small_batch_size: 16
small_local_batch_size: 5
large_local_batch_size: 6
...
```
La configurazione precedente definisce la configurazione di addestramento su scala 2 e 3. In entrambi i casi, utilizziamo il tasso di apprendimento`4e-4`, la dimensione del batch di`128`. Ma sulla scala 2, utilizziamo un numero `micro_train_batch_size` di 8, mentre sulla scala 3, utilizziamo una dimensione del batch non uniforme poiché la dimensione del batch del treno non può essere divisa equamente su 3 nodi.
**Dimensione irregolare del Batch**
Questo è un campo per definire il comportamento di distribuzione dei batch quando la dimensione globale del batch non può essere divisa equamente per il numero di ranghi. Non è specifico per l'allenamento elastico, ma è un fattore abilitante per una maggiore granularità di scalabilità.
+ `use_uneven_batch`: `bool` - se si utilizza una distribuzione non uniforme dei lotti
+ `num_dp_groups_with_small_batch_size`: `int` - nella distribuzione non uniforme dei lotti, alcuni ranghi utilizzano lotti locali di dimensioni inferiori, mentre altri utilizzano lotti di dimensioni maggiori. La dimensione globale del batch deve essere uguale a `small_local_batch_size * num_dp_groups_with_small_batch_size + (world_size-num_dp_groups_with_small_batch_size) * large_local_batch_size`
+ `small_local_batch_size`: `int` - questo valore è la dimensione del batch locale più piccola
+ `large_local_batch_size`: `int` - questo valore è la dimensione del batch locale più grande
**Monitora la formazione su MLFlow**
I lavori di creazione di ricette Hyperpod supportano l'osservabilità tramite. MLFlow Gli utenti possono specificare le MLFlow configurazioni nella ricetta:
```
training_config:
mlflow:
tracking_uri: ""
run_id: ""
experiment_name: ""
run_name: ""
```
[Queste configurazioni sono mappate alla configurazione corrispondente. MLFlow ](https://mlflow.org/docs/latest/ml/tracking/tracking-api/#setup--configuration) Di seguito è riportato un esempio di MLflow dashboard per un lavoro di allenamento elastico.
![\[Di seguito è riportato un esempio di MLflow dashboard per un lavoro di allenamento elastico.\]](http://docs.aws.amazon.com/it_it/sagemaker/latest/dg/images/hyperpod/hyperpod-elastic-sample-dashboard.png)
Dopo aver definito le ricette elastiche, possiamo utilizzare gli script di avvio, ad esempio `launcher_scripts/llama/run_llmft_llama3_1_8b_instruct_seq4k_gpu_sft_lora.sh` per avviare un processo di allenamento elastico. È simile all'avvio di un lavoro statico utilizzando la ricetta Hyperpod.
**Nota**
Il processo di formazione elastico di Recipe Support riprende automaticamente dai checkpoint più recenti, tuttavia, per impostazione predefinita, ogni riavvio crea una nuova directory di formazione. Per consentire la corretta ripresa dall'ultimo checkpoint, dobbiamo assicurarci che venga riutilizzata la stessa directory di formazione. Questo può essere fatto impostando
`recipes.training_config.training_args.override_training_dir=true`
## Esempi e limitazioni dei casi d'uso
### Aumenta la scalabilità quando sono disponibili più risorse
Quando più risorse diventano disponibili sul cluster (ad esempio, altri carichi di lavoro vengono completati). Durante questo evento, il training controller aumenterà automaticamente il processo di formazione. Questo comportamento è spiegato di seguito.
Per simulare una situazione in cui diventano disponibili più risorse, possiamo inviare un lavoro ad alta priorità e quindi rilasciare nuovamente le risorse eliminando il lavoro ad alta priorità.
```
# Submit a high-priority job on your cluster. As a result of this command
# resources will not be available for elastic training
kubectl apply -f high_prioriy_job.yaml
# Submit an elastic job with normal priority
kubectl apply -f hyperpod_job_with_elasticity.yaml
# Wait for training to start....
# Delete high priority job. This command will make additional resources available for
# elastic training
kubectl delete -f high_prioriy_job.yaml
# Observe the scale-up of elastic job
```
Comportamento previsto:
+ L'operatore di formazione crea un carico di lavoro Kueue Quando un lavoro di formazione elastico richiede una modifica delle dimensioni mondiali, l'operatore di formazione genera un oggetto Kueue Workload aggiuntivo che rappresenta i nuovi requisiti di risorse.
+ Kueue ammette il carico di lavoro Kueue valuta la richiesta in base alle risorse disponibili, alle priorità e alle politiche di coda. Una volta approvato, il carico di lavoro viene ammesso.
+ L'operatore addetto all'addestramento crea i pod aggiuntivi Al momento dell'ammissione, l'operatore lancia i pod aggiuntivi necessari per raggiungere la nuova dimensione mondiale.
+ Quando i nuovi pod sono pronti, l'operatore addetto all'addestramento invia uno speciale segnale elastico di evento al training script.
+ **Il processo di addestramento esegue il checkpoint, per prepararsi a un arresto regolare Il processo di addestramento verifica periodicamente la presenza del segnale elastico dell'evento chiamando la funzione elastic\$1event\$1detected ().** Una volta rilevato, avvia un checkpoint. Una volta completato con successo il checkpoint, il processo di addestramento termina senza problemi.
+ L'operatore addetto alla formazione riavvia il lavoro con la nuova dimensione mondiale L'operatore attende la chiusura di tutti i processi, quindi riavvia il processo di formazione utilizzando la dimensione mondiale aggiornata e il checkpoint più recente.
**Nota:** quando Kueue non viene utilizzato, l'operatore addetto alla formazione salta i primi due passaggi. Tenta immediatamente di creare i pod aggiuntivi necessari per le nuove dimensioni del mondo. Se nel cluster non sono disponibili risorse sufficienti, questi pod rimarranno in **sospeso fino a quando la** capacità non sarà disponibile.
![\[Il diagramma illustra la tempistica del ridimensionamento e delle risorse.\]](http://docs.aws.amazon.com/it_it/sagemaker/latest/dg/images/hyperpod/hyperpod-elastic-resize-timeline.png)
### Prelazione per mansioni ad alta priorità
I lavori elastici possono essere ridimensionati automaticamente quando un lavoro ad alta priorità richiede risorse. Per simulare questo comportamento, puoi inviare un lavoro di formazione elastico, che utilizzi il numero massimo di risorse disponibili dall'inizio della formazione, inviare un lavoro ad alta priorità e osservare il comportamento di prelazione.
```
# Submit an elastic job with normal priority
kubectl apply -f hyperpod_job_with_elasticity.yaml
# Submit a high-priority job on your cluster. As a result of this command
# some amount of resources will be
kubectl apply -f high_prioriy_job.yaml
# Observe scale-down behaviour
```
Quando un lavoro ad alta priorità richiede risorse, Kueue può anticipare i carichi di lavoro Elastic Training con priorità più bassa (potrebbe esserci più di un oggetto Workload associato al job Elastic Training). Il processo di prelazione segue questa sequenza:
1. Viene inviato un lavoro ad alta priorità Il lavoro crea un nuovo carico di lavoro Kueue, ma il carico di lavoro non può essere ammesso a causa di risorse del cluster insufficienti.
1. Kueue anticipa uno dei carichi di lavoro di Elastic Training I job Elastic possono avere più carichi di lavoro attivi (uno per configurazione di dimensioni mondiali). Kueue ne seleziona uno da anticipare in base alle politiche di priorità e coda.
1. L'operatore addetto all'addestramento invia un segnale di evento elastico. Una volta attivata la prelazione, l'operatore addetto all'addestramento notifica che il processo di addestramento in corso si interrompa correttamente.
1. Il processo di formazione esegue il checkpoint. Il training job verifica periodicamente la presenza di segnali di eventi elastici. Quando viene rilevato, avvia un checkpoint coordinato per preservare i progressi prima dello spegnimento.
1. l'operatore addetto alla formazione pulisce i pod e i carichi di lavoro. L'operatore attende il completamento del checkpoint, quindi elimina i pod di addestramento che facevano parte del carico di lavoro previsto. Rimuove inoltre l'oggetto Workload corrispondente da Kueue.
1. Il carico di lavoro ad alta priorità è ammesso. Una volta liberate le risorse, Kueue ammette il lavoro ad alta priorità, consentendogli di avviare l'esecuzione.
![\[Cronologia di prelazione per carichi di lavoro di allenamento elastici.\]](http://docs.aws.amazon.com/it_it/sagemaker/latest/dg/images/hyperpod/hyperpod-elastic-preemption-timeline.png)
La prelazione può causare la sospensione dell'intero processo di formazione, il che potrebbe non essere auspicabile per tutti i flussi di lavoro. Per evitare la sospensione completa del lavoro e consentire comunque la scalabilità elastica, i clienti possono configurare due diversi livelli di priorità all'interno dello stesso processo di formazione definendo due sezioni: `replicaSpec`
+ Una ReplicaSpec primaria (fissa) con priorità normale o alta
+ Contiene il numero minimo richiesto di repliche necessarie per mantenere attivo il processo di formazione.
+ Ne utilizza uno superiore PriorityClass, garantendo che queste repliche *non vengano mai* annullate.
+ Mantiene i progressi di base anche quando il cluster è sotto pressione in termini di risorse.
+ Una ReplicaSpec elastica (scalabile) con priorità inferiore
+ Contiene le repliche opzionali aggiuntive che forniscono elaborazione aggiuntiva durante la scalabilità elastica.
+ Utilizza una versione inferiore PriorityClass, che consente a Kueue di anticipare queste repliche quando i lavori con priorità più alta richiedono risorse.
+ Assicura che venga recuperata solo la parte elastica, mentre l'allenamento di base continua senza interruzioni.
Questa configurazione consente la prelazione parziale, in cui viene recuperata solo la capacità elastica, mantenendo la continuità della formazione pur supportando un'equa condivisione delle risorse in ambienti multi-tenant. Esempio:
```
apiVersion: sagemaker.amazonaws.com/v1
kind: HyperPodPyTorchJob
metadata:
name: elastic-training-job
spec:
elasticPolicy:
minReplicas: 2
maxReplicas: 8
replicaIncrementStep: 2
...
replicaSpecs:
- name: base
replicas: 2
template:
spec:
priorityClassName: high-priority # set high-priority to avoid evictions
...
- name: elastic
replicas: 0
maxReplicas: 6
template:
spec:
priorityClassName: low-priority. # Set low-priority for elastic part
...
```
### Gestione dello sfratto dei pod, dei crash dei pod e del degrado dell'hardware:
L'operatore addetto alla HyperPod formazione include meccanismi integrati per ripristinare il processo di formazione quando viene interrotto inaspettatamente. Le interruzioni possono verificarsi per vari motivi, ad esempio errori del codice di addestramento, rimozione dei pod, guasti dei nodi, deterioramento dell'hardware e altri problemi di runtime.
Quando ciò accade, l'operatore tenta automaticamente di ricreare i pod interessati e di riprendere l'addestramento dal checkpoint più recente. Se il recupero non è immediatamente possibile, ad esempio a causa dell'insufficiente capacità di riserva, l'operatore può continuare a progredire riducendo temporaneamente le dimensioni mondiali e riducendo il lavoro di formazione elastica.
Quando un processo di training elastico si blocca o perde delle repliche, il sistema si comporta come segue:
+ Fase di ripristino (utilizzando nodi di riserva) Il Training Controller attende che le risorse siano `faultyScaleDownTimeoutInSeconds` disponibili e tenta di recuperare le repliche fallite ridistribuendo i pod sulla capacità di riserva.
+ Elastic scale-down Se il ripristino non è possibile entro la finestra di timeout, l'operatore addetto alla formazione ridimensiona il lavoro fino a renderlo più piccolo (se la politica elastica del lavoro lo consente). L'allenamento riprende quindi con un minor numero di repliche.
+ Scale-up elastico Quando le risorse aggiuntive diventano nuovamente disponibili, l'operatore ridimensiona automaticamente il lavoro di formazione fino alla dimensione mondiale preferita.
Questo meccanismo garantisce che la formazione possa continuare con tempi di inattività minimi, anche in caso di pressione delle risorse o di guasti parziali dell'infrastruttura, sfruttando al contempo la scalabilità elastica.
### Usa l'allenamento elastico con altre funzionalità HyperPod
Attualmente Elastic Training non supporta funzionalità di formazione senza checkpoint, checkpoint HyperPod gestito a più livelli o istanze Spot.
**Nota**
Raccogliamo determinate metriche operative di routine aggregate e anonime 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 un lavoro e la scalabilità delle operazioni, la gestione delle risorse e le funzionalità essenziali del servizio.
# Osservabilità per SageMaker HyperPod cluster Amazon orchestrata da Amazon EKS
[Per ottenere un'osservabilità completa nelle risorse e nei componenti software del cluster Amazon SageMaker HyperPod (SageMaker HyperPod), integra il cluster con [Amazon CloudWatch Container Insights, Amazon](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContainerInsights.html)[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) Questi strumenti forniscono visibilità sull’integrità del cluster, sulle metriche delle prestazioni e sull’utilizzo delle risorse.
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.
**Nota**
Mentre CloudWatch Amazon Managed Service for Prometheus e Amazon Managed Grafana si concentrano sulle metriche operative (ad esempio, lo stato del sistema, la formazione, le prestazioni lavorative SageMaker HyperPod ), i [report sull'utilizzo completano](sagemaker-hyperpod-eks-operate-console-ui-governance.md) la Task Governance per fornire informazioni sulla responsabilità finanziaria e delle risorse. Questi report monitorano:
Utilizzo del calcolo (GPU/CPU/Neuron Core hours) across namespaces/teams
Attribuzione dei costi per le risorse allocate e quelle prese in prestito
Tendenze cronologiche (fino a 180 giorni) per audit e ottimizzazione
Per ulteriori informazioni sulla configurazione e la generazione di report sull'utilizzo, consulta [Reporting Compute](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-usage-reporting.html) Usage in. HyperPod
**Suggerimento**
Per trovare esempi e soluzioni pratiche, consulta anche la sezione [Osservabilità](https://catalog.us-east-1.prod.workshops.aws/workshops/2433d39e-ccfe-4c00-9d3d-9917b729258e/en-US/06-observability) [nel SageMaker HyperPod workshop Amazon EKS Support](https://catalog.us-east-1.prod.workshops.aws/workshops/2433d39e-ccfe-4c00-9d3d-9917b729258e).
Passa ai seguenti argomenti per configurare l'osservabilità dei SageMaker HyperPod cluster.
**Topics**
+ [Osservabilità dei modelli per i lavori di formazione su SageMaker HyperPod cluster orchestrati da Amazon EKS](sagemaker-hyperpod-eks-cluster-observability-model.md)
+ [Osservabilità di cluster e attività](sagemaker-hyperpod-eks-cluster-observability-cluster.md)
# Osservabilità dei modelli per i lavori di formazione su SageMaker HyperPod cluster orchestrati da Amazon EKS
SageMaker HyperPod i cluster orchestrati con Amazon EKS possono integrarsi con l'applicazione [MLflow su Amazon Studio](https://docs.aws.amazon.com/sagemaker/latest/dg/mlflow.html). SageMaker Gli amministratori dei cluster configurano il MLflow server e lo collegano ai cluster. SageMaker HyperPod I Data Scientist possono ottenere informazioni approfondite sul modello.
**Per configurare un MLflow server tramite AWS CLI**
Un amministratore del cluster deve creare un server di MLflow tracciamento.
1. Crea un server di MLflow tracciamento SageMaker AI, seguendo le istruzioni in [Creare un server di tracciamento utilizzando la AWS CLI](https://docs.aws.amazon.com/sagemaker/latest/dg/mlflow-create-tracking-server-cli.html#mlflow-create-tracking-server-cli-infra-setup).
1. Assicurati che l'[https://docs.aws.amazon.com/eks/latest/APIReference/API_auth_AssumeRoleForPodIdentity.html](https://docs.aws.amazon.com/eks/latest/APIReference/API_auth_AssumeRoleForPodIdentity.html)autorizzazione esista nel ruolo di esecuzione IAM per SageMaker HyperPod.
1. Se il componente aggiuntivo `eks-pod-identity-agent` non è già installato sul cluster EKS, esegui l’operazione.
```
aws eks create-addon \
--cluster-name \
--addon-name eks-pod-identity-agent \
--addon-version vx.y.z-eksbuild.1
```
1. Crea un `trust-relationship.json` file per un nuovo ruolo da chiamare per Pod MLflow APIs.
```
cat >trust-relationship.json <hyperpod-mlflow-policy.json <"
},
{
"Effect": "Allow",
"Action": [
"s3:PutObject"
],
"Resource": "arn:aws:s3:::"
}
]
}
EOF
```
**Nota**
ARNs [Sono quelle del MLflow server e del bucket S3 configurati con il server durante il MLflow server che hai creato seguendo le istruzioni Configura l'infrastruttura. MLflow ](https://docs.aws.amazon.com/sagemaker/latest/dg/mlflow-create-tracking-server-cli.html#mlflow-create-tracking-server-cli-infra-setup)
1. Collega la policy `mlflow-metrics-emit-policy` a `hyperpod-mlflow-role` utilizzando il documento della policy salvato nella fase precedente.
```
aws iam put-role-policy \
--role-name hyperpod-mlflow-role \
--policy-name mlflow-metrics-emit-policy \
--policy-document file://hyperpod-mlflow-policy.json
```
1. Crea un account di servizio Kubernetes per consentire a Pod di accedere al server. MLflow
```
cat >mlflow-service-account.yaml <
Esistono due opzioni per il monitoraggio dei cluster: SageMaker HyperPod
**Il componente aggiuntivo SageMaker HyperPod Observability**: SageMaker HyperPod fornisce una out-of-the-box dashboard completa che fornisce informazioni dettagliate sulle attività di sviluppo del modello di base (FM) e sulle risorse del cluster. Questa soluzione unificata di osservabilità pubblica automaticamente le metriche chiave in Servizio gestito da Amazon per Prometheus e le visualizza nelle dashboard di Grafana gestito da Amazon. Le dashboard sono ottimizzate specificamente per lo sviluppo di FM con una copertura approfondita dello stato di integrità dell’hardware, dell’utilizzo delle risorse e delle prestazioni a livello di attività. Con questo componente aggiuntivo, puoi consolidare i dati sullo stato e sulle prestazioni di NVIDIA DCGM, degli esportatori di nodi Kubernetes a livello di istanza, Elastic Fabric Adapter, dei file system integrati, di Kubernetes, Kueue e degli operatori di attività. APIs SageMaker HyperPod
**Amazon CloudWatch Insights**: Amazon CloudWatch Insights raccoglie parametri per le risorse di calcolo, come CPU, memoria, disco e rete. Container Insights fornisce inoltre informazioni diagnostiche, ad esempio errori di riavvio del container, che consentono di isolare i problemi e risolverli in modo rapido. Puoi anche impostare CloudWatch allarmi sui parametri raccolti da Container Insights.
**Topics**
+ [SageMaker HyperPod Osservabilità di Amazon con Amazon Managed Grafana e Amazon Managed Service for Prometheus](sagemaker-hyperpod-observability-addon.md)
+ [Osservabilità con Amazon CloudWatch](sagemaker-hyperpod-eks-cluster-observability-cluster-cloudwatch-ci.md)
# SageMaker HyperPod Osservabilità di Amazon con Amazon Managed Grafana e Amazon Managed Service for Prometheus
Amazon SageMaker HyperPod (SageMaker HyperPod) offre una out-of-the-box dashboard completa che fornisce informazioni dettagliate sulle attività di sviluppo del modello di base (FM) e sulle risorse del cluster. Questa soluzione unificata di osservabilità pubblica automaticamente le metriche chiave in Servizio gestito da Amazon per Prometheus e le visualizza nelle dashboard di Grafana gestito da Amazon. Le dashboard sono ottimizzate specificamente per lo sviluppo di FM con una copertura approfondita dello stato di integrità dell’hardware, dell’utilizzo delle risorse e delle prestazioni a livello di attività. Con questo componente aggiuntivo, puoi consolidare i dati sullo stato e sulle prestazioni provenienti da NVIDIA DCGM, dagli esportatori di nodi Kubernetes a livello di istanza, Elastic Fabric Adapter, dai file system integrati, da Kubernetes, Kueue e dai task operator. APIs SageMaker HyperPod
## Supporto per Restricted Instance Group (RIG)
Il componente aggiuntivo di osservabilità supporta anche i cluster che contengono Restricted Instance Groups. Nei cluster RIG, il componente aggiuntivo adatta automaticamente la propria strategia di implementazione per rispettare l'isolamento della rete e i vincoli di sicurezza dei nodi con restrizioni. DaemonSet i componenti (node exporter, DCGM exporter, EFA exporter, Neuron monitor e node collector) funzionano su nodi standard e limitati. I componenti di distribuzione (central collector, Kube State Metrics e Training Metrics Agent) sono pianificati con una logica che riconosce i confini per rispettare l'isolamento della rete tra i gruppi di istanze. La raccolta dei log dei container con Fluent Bit non è disponibile su nodi con restrizioni.
Per informazioni sulla configurazione del componente aggiuntivo su cluster con gruppi di istanze limitati, consulta. [Configurazione del componente aggiuntivo Observability SageMaker HyperPod](hyperpod-observability-addon-setup.md)
**Topics**
+ [Supporto per Restricted Instance Group (RIG)](#hyperpod-observability-addon-rig-support)
+ [Configurazione del componente aggiuntivo Observability SageMaker HyperPod](hyperpod-observability-addon-setup.md)
+ [Dashboard di SageMaker HyperPod osservabilità di Amazon](hyperpod-observability-addon-viewing-dashboards.md)
+ [Esplorazione delle metriche dei SageMaker HyperPod cluster in Amazon Managed Grafana](hyperpod-observability-addon-exploring-metrics.md)
+ [Personalizzazione delle metriche, dei pannelli di controllo e degli avvisi SageMaker HyperPod del cluster.](hyperpod-observability-addon-customizing.md)
+ [Creazione di metriche personalizzate per i cluster SageMaker HyperPod](hyperpod-observability-addon-custom-metrics.md)
+ [SageMaker HyperPod metriche del cluster](hyperpod-observability-cluster-metrics.md)
+ [Avvisi preconfigurati](hyperpod-observability-addon-alerts.md)
+ [Risoluzione dei problemi relativi al componente aggiuntivo Amazon SageMaker HyperPod Observability](hyperpod-observability-addon-troubleshooting.md)
# Configurazione del componente aggiuntivo Observability SageMaker HyperPod
L’elenco seguente descrive i prerequisiti per la configurazione del componente aggiuntivo Observability.
Per inviare le metriche per il tuo cluster Amazon SageMaker HyperPod (SageMaker HyperPod) a un'area di lavoro Amazon Managed Service for Prometheus e, facoltativamente, visualizzarle in Amazon Managed Grafana, collega innanzitutto le seguenti politiche e autorizzazioni gestite al tuo ruolo di console.
+ Per utilizzare Amazon Managed Grafana, abilita AWS IAM Identity Center (IAM Identity Center) in un luogo in cui è Regione AWS disponibile Amazon Managed Grafana. Per istruzioni, consulta [Getting started with IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/getting-started.html) in *AWS IAM Identity Center User Guide*. Per un elenco delle Regioni AWS in cui è disponibile Grafana gestito da Amazon, consulta [Supported Regions](https://docs.aws.amazon.com/grafana/latest/userguide/what-is-Amazon-Managed-Service-Grafana.html#AMG-supported-Regions) in *Amazon Managed Grafana User Guide*.
+ Crea almeno un utente nel Centro identità IAM.
+ Assicurati che il componente aggiuntivo [Amazon EKS Pod Identity Agent](https://docs.aws.amazon.com/eks/latest/userguide/workloads-add-ons-available-eks.html#add-ons-pod-id) sia installato nel tuo cluster Amazon EKS. Il componente aggiuntivo Amazon EKS Pod Identity Agent consente al componente aggiuntivo di SageMaker HyperPod osservabilità di ottenere le credenziali per interagire con Amazon Managed Service for Prometheus and Logs. CloudWatch Per verificare se il tuo cluster Amazon EKS dispone del componente aggiuntivo, vai alla console di Amazon EKS e controlla la scheda **Componenti aggiuntivi** del cluster. Per informazioni su come installare il componente aggiuntivo, se non è installato, consulta [Create add-on (Console di gestione AWS)](https://docs.aws.amazon.com/eks/latest/userguide/creating-an-add-on.html#_create_add_on_console) in *Amazon EKS User Guide*.
**Nota**
L'Amazon EKS Pod Identity Agent è necessario per i gruppi di istanze standard. Per i Restricted Instance Groups (RIG), Pod Identity Agent non è disponibile a causa dei vincoli di isolamento della rete. Il ruolo IAM di esecuzione del gruppo di istanze del cluster viene utilizzato per interagire con Amazon Managed Service for Prometheus. Per informazioni su come configurare quel ruolo, consulta. [Prerequisiti aggiuntivi per i gruppi di istanze con restrizioni](#hyperpod-observability-addon-rig-prerequisites)
+ Assicurati di avere almeno un nodo nel SageMaker HyperPod cluster prima di installare il componente aggiuntivo SageMaker HyperPod Observability. Il tipo di istanza Amazon EC2 con le dimensioni più ridotte adatto a questo caso è `4xlarge`. Questo requisito di dimensione minima del nodo garantisce che il nodo possa ospitare tutti i pod creati dal componente aggiuntivo di SageMaker HyperPod osservabilità insieme a tutti gli altri pod già in esecuzione sul cluster.
+ Aggiungi le policy e le autorizzazioni seguenti al tuo ruolo.
+ [AWS politica gestita: AmazonSageMakerHyperPodObservabilityAdminAccess](security-iam-awsmanpol-AmazonSageMakerHyperPodObservabilityAdminAccess.md)
+ [AWS politica gestita: V2 AWSGrafana WorkspacePermissionManagement](https://docs.aws.amazon.com/grafana/latest/userguide/security-iam-awsmanpol.html#security-iam-awsmanpol-AWSGrafanaWorkspacePermissionManagementV2)
+ [AWS politica gestita: AmazonSageMakerFullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonSageMakerFullAccess.html)
+ Autorizzazioni aggiuntive per configurare i ruoli IAM richiesti per l’accesso ai componenti aggiuntivi Grafana gestito da Amazon e Amazon Elastic Kubernetes Service:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "CreateRoleAccess",
"Effect": "Allow",
"Action": [
"iam:CreateRole",
"iam:CreatePolicy",
"iam:AttachRolePolicy",
"iam:ListRoles"
],
"Resource": [
"arn:aws:iam::*:role/service-role/AmazonSageMakerHyperPodObservabilityGrafanaAccess*",
"arn:aws:iam::*:role/service-role/AmazonSageMakerHyperPodObservabilityAddonAccess*",
"arn:aws:iam::*:policy/service-role/HyperPodObservabilityAddonPolicy*",
"arn:aws:iam::*:policy/service-role/HyperPodObservabilityGrafanaPolicy*"
]
}
]
}
```
------
+ Autorizzazioni aggiuntive necessarie per gestire gli utenti del Centro identità IAM per Grafana gestito da Amazon:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "SSOAccess",
"Effect": "Allow",
"Action": [
"sso:ListProfileAssociations",
"sso-directory:SearchUsers",
"sso-directory:SearchGroups",
"sso:AssociateProfile",
"sso:DisassociateProfile"
],
"Resource": [
"*"
]
}
]
}
```
------
## Prerequisiti aggiuntivi per i gruppi di istanze con restrizioni
Se il cluster contiene gruppi di istanze con restrizioni, il ruolo di esecuzione del gruppo di istanze deve disporre delle autorizzazioni per scrivere metriche su Amazon Managed Service for Prometheus. Quando utilizzi la **configurazione rapida** per creare un cluster con l'osservabilità abilitata, queste autorizzazioni vengono aggiunte automaticamente al ruolo di esecuzione.
Se utilizzi la **configurazione personalizzata** o aggiungi l'osservabilità a un cluster RIG esistente, assicurati che il ruolo di esecuzione per ogni gruppo di istanze ristrette disponga delle seguenti autorizzazioni:
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "PrometheusAccess",
"Effect": "Allow",
"Action": "aps:RemoteWrite",
"Resource": "arn:aws:aps:us-east-1:account_id:workspace/workspace-ID"
}
]
}
```
Sostituisci *us-east-1* e *workspace-ID* con il tuo Regione AWS ID account e l'ID dell'area di lavoro Amazon Managed Service for Prometheus. *account\$1id*
Una volta soddisfatti i prerequisiti sopra indicati, puoi installare il componente aggiuntivo Observability.
**Per installare rapidamente il componente aggiuntivo Observability**
1. Apri la console Amazon SageMaker AI all'indirizzo [https://console.aws.amazon.com/sagemaker/](https://console.aws.amazon.com/sagemaker/).
1. Vai alla pagina dei dettagli del cluster.
1. Nella scheda **Dashboard**, individua il componente aggiuntivo denominato **HyperPod Monitoring & Observability** e scegli **Installazione rapida**.
**Per eseguire un’installazione personalizzata del componente aggiuntivo Observability**
1. Vai alla pagina dei dettagli del cluster.
1. **Nella scheda **Dashboard**, individua il componente aggiuntivo denominato **HyperPod Monitoring & Observability** e scegli Installazione personalizzata.**
1. Specifica le categorie delle metriche da visualizzare. Per ulteriori informazioni su tali categorie, consulta [SageMaker HyperPod metriche del cluster](hyperpod-observability-cluster-metrics.md).
1. Specificate se desiderate abilitare Amazon CloudWatch Logs.
1. Specifica se desideri che il servizio crei un nuovo spazio di lavoro del Servizio gestito da Amazon per Prometheus.
1. Per visualizzare le metriche nelle dashboard di Grafana gestito da Amazon, seleziona la casella **Utilizza uno spazio di lavoro Grafana gestito da Amazon**. Puoi specificare il tuo spazio di lavoro o lasciare che il servizio ne crei uno nuovo per te.
**Nota**
Amazon Managed Grafana non è disponibile in tutti gli Regioni AWS ambienti in cui è disponibile Amazon Managed Service for Prometheus. Tuttavia, puoi configurare uno spazio di lavoro Grafana in qualsiasi Regione AWS e impostarlo per ottenere dati metrici da uno spazio di lavoro di Prometheus che si trova in un’altra Regione AWS. Per informazioni, consulta [Use AWS data source configuration to add Amazon Managed Service for Prometheus as a data source](https://docs.aws.amazon.com/grafana/latest/userguide/AMP-adding-AWS-config.html) e [Connect to Amazon Managed Service for Prometheus and open-source Prometheus data sources](https://docs.aws.amazon.com/grafana/latest/userguide/prometheus-data-source.html).
# Dashboard di SageMaker HyperPod osservabilità di Amazon
Questo argomento descrive come visualizzare i dashboard delle metriche per i cluster Amazon SageMaker HyperPod (SageMaker HyperPod) e come aggiungere nuovi utenti a una dashboard. L’argomento descrive inoltre i diversi tipi di dashboard.
## Accesso alle dashboard
Per visualizzare i parametri del tuo SageMaker HyperPod cluster in Amazon Managed Grafana, esegui i seguenti passaggi:
1. Apri la console Amazon SageMaker AI all'indirizzo [https://console.aws.amazon.com/sagemaker/](https://console.aws.amazon.com/sagemaker/).
1. Vai alla pagina dei dettagli del cluster.
1. Nella scheda **Dashboard**, individua la sezione **HyperPod Osservabilità** e scegli **Apri dashboard in Grafana**.
## Aggiunta di nuovi utenti a uno spazio di lavoro Grafana gestito da Amazon
Per informazioni su come aggiungere utenti a uno spazio di lavoro Grafana gestito da Amazon, consulta [Use AWS IAM Identity Center with your Amazon Managed Grafana workspace](https://docs.aws.amazon.com/grafana/latest/userguide/authentication-in-AMG-SSO.html) in *Amazon Managed Grafana User Guide*.
## Dashboard di osservabilità
Il componente aggiuntivo SageMaker HyperPod Observability fornisce sei dashboard interconnesse nell'area di lavoro Amazon Managed Grafana predefinita. Ogni dashboard fornisce informazioni approfondite sulle diverse risorse e attività nei cluster per vari utenti come Data Scientist, ingegneri di machine learning e amministratori.
### Dashboard delle attività
La dashboard Task fornisce il monitoraggio e la visualizzazione completi dei parametri di utilizzo delle risorse per le attività. SageMaker HyperPod Il pannello principale mostra una tabella dettagliata che raggruppa l’utilizzo delle risorse per attività principali, mostrando l’utilizzo di CPU, GPU e memoria nei vari pod. I grafici interattivi delle serie temporali tracciano l’utilizzo della CPU, il consumo di memoria di sistema, le percentuali di utilizzo della GPU e l’utilizzo della memoria GPU per i pod selezionati, consentendoti di monitorare le tendenze delle prestazioni nel tempo. La dashboard offre potenti funzionalità di filtraggio tramite variabili, ad esempio il nome del cluster, il namespace, il tipo di attività e pod specifici, che semplificano l’analisi di determinati carichi di lavoro. Questa soluzione di monitoraggio è essenziale per ottimizzare l'allocazione delle risorse e mantenere le prestazioni dei carichi di lavoro di apprendimento automatico su. SageMaker HyperPod
### Dashboard di addestramento
La dashboard di addestramento fornisce un monitoraggio completo dell’integrità delle attività di addestramento, dell’affidabilità e delle metriche di gestione dei guasti. La dashboard presenta diversi indicatori chiave delle prestazioni, tra cui il numero di attività create, i tassi di successo e le percentuali del tempo di attività, oltre al tracciamento dettagliato degli eventi di riavvio automatici e manuali. Offre visualizzazioni dettagliate dei modelli di guasto tramite grafici a torta e mappe di calore che suddividono gli incidenti per tipo e latenza di correzione, consentendoti di identificare i problemi ricorrenti e ottimizzare l’affidabilità delle attività. L’interfaccia include il monitoraggio in tempo reale delle metriche critiche, ad esempio i tempi di ripristino del sistema e le latenze di rilevamento dei guasti, rendendola uno strumento essenziale per mantenere un’elevata disponibilità dei carichi di lavoro di addestramento. Inoltre, la finestra finale di 24 ore della dashboard fornisce un contesto cronologico per l’analisi delle tendenze e dei modelli nelle prestazioni delle attività di addestramento, aiutando i team a risolvere in modo proattivo i potenziali problemi prima che influiscano sui carichi di lavoro di produzione.
### Dashboard di inferenza
La dashboard di inferenza offre un monitoraggio completo delle prestazioni di implementazione del modello e delle metriche di integrità su più dimensioni. Offre una panoramica dettagliata delle implementazioni attive, il monitoraggio in tempo reale dei tassi di richiesta, dei tassi di successo e delle metriche di latenza, che consentono di monitorare le prestazioni di servizio dei modelli e di identificare potenziali colli di bottiglia. La dashboard include pannelli specializzati per le metriche di inferenza generali e le metriche specifiche dei token per i modelli linguistici, come il tempo al primo token (Time To First Token, TTFT) e il throughput dei token, il che la rende particolarmente utile per il monitoraggio delle implementazioni di modelli linguistici di grandi dimensioni. Inoltre, fornisce informazioni approfondite sull’infrastruttura grazie al tracciamento dell’allocazione di pod e nodi e offre al tempo stesso funzionalità di analisi dettagliata degli errori che contribuiscono a mantenere elevate la disponibilità e le prestazioni dei carichi di lavoro di inferenza.
### Dashboard del cluster
La dashboard del cluster offre una visione completa dello stato e delle prestazioni del cluster, offrendo visibilità in tempo reale sulle risorse di calcolo, memoria, rete e storage nell'ambiente Amazon SageMaker HyperPod (SageMaker HyperPod). Con una sola occhiata, puoi visualizzare metriche critiche come le istanze totali, l’utilizzo della GPU, l’utilizzo della memoria e le prestazioni di rete attraverso un’interfaccia intuitiva che aggiorna automaticamente i dati ogni pochi secondi. La dashboard è organizzata in sezioni logiche: parte da una panoramica generale del cluster che mostra le metriche chiave, come la percentuale di istanze integre e il numero totale di risorse, e prosegue poi con sezioni dettagliate sulle prestazioni della GPU, l’utilizzo della memoria, le statistiche di rete e le metriche di archiviazione. Ogni sezione presenta grafici e pannelli interattivi che consentono di approfondire metriche specifiche, con intervalli di tempo personalizzabili e opzioni di filtraggio per nome del cluster, istanza o ID della GPU.
### Dashboard del file system
La dashboard del file system offre una visibilità completa sulle prestazioni e sui parametri di salute del file system (Amazon FSx for Lustre). La dashboard mostra i parametri di storage critici, tra cui capacità libera, risparmi sulla deduplicazione, CPU/memory utilizzo, IOPS del disco, throughput e connessioni client su più visualizzazioni. Consente di monitorare sia gli indicatori di prestazioni a livello di sistema, come l'utilizzo della CPU e della memoria, sia le metriche specifiche dello storage, come le operazioni e i modelli di utilizzo del disco. read/write L’interfaccia include funzionalità di tracciamento degli avvisi e grafici dettagliati delle serie temporali per tenere traccia delle tendenze delle prestazioni nel tempo, opzioni che la rendono particolarmente utile per la manutenzione proattiva e la pianificazione della capacità. Inoltre, grazie alla copertura completa delle metriche, la dashboard aiuta a identificare potenziali colli di bottiglia, ottimizzare le prestazioni di storage e garantire operazioni affidabili dei file system per i carichi di lavoro. SageMaker HyperPod
### Dashboard delle partizioni GPU
Per monitorare le metriche specifiche della partizione GPU quando si utilizzano configurazioni Multi-Instance GPU (MIG), è necessario installare o eseguire l'aggiornamento alla versione più recente del componente aggiuntivo Observability. SageMaker HyperPod Questo addon offre funzionalità di monitoraggio complete, incluse metriche specifiche per MiG come il numero di partizioni, l'utilizzo della memoria e l'utilizzo del calcolo per partizione GPU.
Se hai già installato SageMaker HyperPod Observability ma hai bisogno del supporto per le metriche MIG, aggiorna semplicemente l'addon alla versione più recente. Questo processo non prevede interruzioni e mantiene la configurazione di monitoraggio esistente.
SageMaker HyperPod espone automaticamente metriche specifiche di MiG, tra cui:
+ `nvidia_mig_instance_count`: Numero di istanze MIG per profilo
+ `nvidia_mig_memory_usage`: utilizzo della memoria per istanza MIG
+ `nvidia_mig_compute_utilization`: utilizzo del calcolo per istanza MIG
### Dashboard Cluster Logs
La dashboard Cluster Logs offre una visualizzazione centralizzata dei CloudWatch log per il cluster. SageMaker HyperPod La dashboard interroga il gruppo di `/aws/sagemaker/Clusters/{cluster-name}/{cluster-id}` log e visualizza gli eventi di registro con funzionalità di filtraggio per ID di istanza, nome del flusso di log, livello di registro (ERROR, WARN, INFO, DEBUG) e ricerca a testo libero. La dashboard include una cronologia degli eventi che mostra la distribuzione degli eventi di registro nel tempo, un contatore totale degli eventi, una cronologia degli eventi cercati per i risultati filtrati e un pannello di log dettagliato con messaggi di registro completi, timestamp e metadati del flusso di log. Questa dashboard utilizza CloudWatch come fonte di dati ed è utile per il debug dei problemi del cluster, il monitoraggio degli eventi relativi allo stato delle istanze e l'analisi degli errori dei lavori di formazione.
# Esplorazione delle metriche dei SageMaker HyperPod cluster in Amazon Managed Grafana
Dopo aver collegato Grafana gestito da Amazon al tuo spazio di lavoro Servizio gestito da Amazon per Prometheus, puoi utilizzare l’editor di query e gli strumenti di visualizzazione di Grafana per esplorare i dati delle metriche. Grafana gestito da Amazon offre diversi modi per interagire con i dati di Prometheus, tra cui un editor di query completo per la creazione di espressioni PromQL, un browser di metriche per rilevare metriche ed etichette disponibili e funzionalità di creazione di modelli per la creazione di dashboard dinamiche. Puoi eseguire query su intervalli per visualizzare i dati di serie temporali per determinati periodi e query istantanee per recuperare i valori più recenti, con opzioni che consentono di formattare i risultati come grafi di serie temporali, tabelle o mappe termiche. Per informazioni dettagliate sulla configurazione delle impostazioni delle query, sull’utilizzo del browser delle metriche e sull’utilizzo delle funzionalità dei modelli, consulta [Using the Prometheus data source](https://docs.aws.amazon.com/grafana/latest/userguide/using-prometheus-datasource.html).
# Personalizzazione delle metriche, dei pannelli di controllo e degli avvisi SageMaker HyperPod del cluster.
Grafana gestito da Amazon ti consente di creare dashboard complete che visualizzano i dati in pannelli con query collegate alle tue origini dati. Puoi creare dashboard da zero, importare dashboard esistenti o esportare le dashboard create per scopi di condivisione e backup. Le dashboard Grafana supportano funzionalità dinamiche grazie a variabili che sostituiscono i valori con codifica fissa nelle query, rendendo le visualizzazioni più flessibili e interattive. Puoi anche migliorare le tue dashboard con funzionalità come annotazioni, pannelli di librerie per la riutilizzabilità, gestione della cronologia delle versioni e link personalizzati per creare una soluzione completa di monitoraggio e osservabilità. [Per step-by-step indicazioni su come creare, importare, configurare e gestire i dashboard, consulta Creazione di dashboard.](https://docs.aws.amazon.com/grafana/latest/userguide/v10-dash-building-dashboards.html)
# Creazione di metriche personalizzate per i cluster SageMaker HyperPod
Il componente aggiuntivo Amazon SageMaker HyperPod (SageMaker HyperPod) observability fornisce centinaia di parametri di salute, prestazioni ed efficienza. out-of-the-box Oltre a queste metriche, potrebbe essere necessario monitorare metriche personalizzate per applicazioni o esigenze aziendali specifiche che non rientrano nelle metriche predefinite, come indicatori di prestazioni specifici del modello, statistiche di elaborazione dei dati o misurazioni specifiche dell’applicazione. Per soddisfare questa esigenza, puoi implementare la raccolta di metriche personalizzate OpenTelemetry integrando un frammento di codice Python nella tua applicazione.
Per creare metriche personalizzate, esegui prima il seguente comando shell per installare i OpenTelemetry componenti principali necessari per strumentare le applicazioni Python per l'osservabilità. Questa installazione consente alle applicazioni Python eseguite su SageMaker HyperPod cluster di emettere dati di telemetria personalizzati. Questi dati vengono raccolti dal OpenTelemetry raccoglitore e inoltrati all'infrastruttura di osservabilità.
```
pip install opentelemetry-api opentelemetry-sdk opentelemetry-exporter-otlp-proto-grpc
```
Lo script di esempio seguente configura una pipeline di OpenTelemetry metriche che contrassegna automaticamente le metriche con informazioni su pod e nodi, garantendo la corretta attribuzione all'interno del cluster e invia queste metriche allo stack di osservabilità integrato ogni secondo. SageMaker HyperPod Lo script stabilisce una connessione al raccoglitore di SageMaker HyperPod metriche, imposta gli attributi di risorsa appropriati per l'identificazione e fornisce un'interfaccia di misurazione tramite la quale è possibile creare vari tipi di metriche (contatori, indicatori o istogrammi) per tenere traccia di qualsiasi aspetto delle prestazioni dell'applicazione. Le metriche personalizzate si integrano con le dashboard di monitoraggio insieme alle metriche di sistema. SageMaker HyperPod Questa integrazione consente un’osservabilità completa attraverso un’unica interfaccia, in cui puoi creare avvisi, visualizzazioni e report personalizzati per monitorare il profilo delle prestazioni completo del carico di lavoro.
```
import os
from opentelemetry import metrics
from opentelemetry.exporter.otlp.proto.grpc.metric_exporter import OTLPMetricExporter
from opentelemetry.sdk.metrics import MeterProvider
from opentelemetry.sdk.metrics.export import PeriodicExportingMetricReader
from opentelemetry.sdk.resources import Resource
# Get hostname/pod name
hostname = os.uname()[1]
node_name = os.getenv('NODE_NAME', 'unknown')
collector_endpoint = "hyperpod-otel-collector.hyperpod-observability:4317"
# Configure the OTLP exporter
exporter = OTLPMetricExporter(
endpoint=collector_endpoint,
insecure=True,
timeout=5000 # 5 seconds timeout
)
reader = PeriodicExportingMetricReader(
exporter,
export_interval_millis=1000
)
resource = Resource.create({
"service.name": "metric-test",
"pod.name": hostname,
"node.name": node_name
})
meter_provider = MeterProvider(
metric_readers=[reader],
resource=resource
)
metrics.set_meter_provider(meter_provider)
# Create a meter
meter = metrics.get_meter("test-meter")
# Create a counter
counter = meter.create_counter(
name="test.counter",
description="A test counter"
)
counter.add(1, {"pod": hostname, "node": node_name})
```
# SageMaker HyperPod metriche del cluster
Amazon SageMaker HyperPod (SageMaker HyperPod) pubblica diverse metriche in 9 categorie distinte nell'area di lavoro Amazon Managed Service for Prometheus. Non tutte le metriche sono abilitate per impostazione predefinita o visualizzate nello spazio di lavoro Grafana gestito da Amazon. La tabella seguente mostra quali metriche sono abilitate per impostazione predefinita quando installi il componente aggiuntivo Observability, quali categorie hanno metriche aggiuntive che possono essere abilitate per ottenere informazioni più granulari sul cluster e dove vengono visualizzate tali metriche nello spazio di lavoro Grafana gestito da Amazon.
| Categoria parametro | Abilitata per impostazione predefinita? | Sono disponibili ulteriori metriche avanzate? | In quali dashboard Grafana è disponibile? |
| --- | --- | --- | --- |
| Metriche di addestramento | Sì | Sì | Addestramento |
| Metriche di inferenza | Sì | No | Inferenza |
| Metriche di governance delle attività | No | Sì | Nessuna. Effettua una query sullo spazio di lavoro del Servizio gestito da Amazon per Prometheus per creare la tua dashboard. |
| Metriche di dimensionamento | No | Sì | Nessuna. Effettua una query sullo spazio di lavoro del Servizio gestito da Amazon per Prometheus per creare la tua dashboard. |
| Parametri cluster | Sì | Sì | Cluster |
| Parametri dell'istanza | Sì | Sì | Cluster |
| Metriche di calcolo accelerate | Sì | Sì | Attività, cluster |
| Metriche di rete | No | Sì | Cluster |
| File system | Sì | No | File system |
Le tabelle seguenti descrivono le metriche disponibili per il monitoraggio del cluster, organizzate per categoria. SageMaker HyperPod
## Disponibilità delle metriche nei gruppi di istanze con restrizioni
Quando il cluster contiene gruppi di istanze con restrizioni, la maggior parte delle categorie di metriche è disponibile su nodi con restrizioni con le seguenti eccezioni e considerazioni. Puoi anche impostare avvisi in base a qualsiasi metrica di tua scelta.
| Categoria parametro | Disponibile sui nodi RIG? | Note |
| --- | --- | --- |
| Metriche di addestramento | Sì | Vengono raccolte le metriche dei pod Kubeflow e Kubernetes. Le metriche dei KPI per la formazione avanzata (fornite da Training Metrics Agent) non sono disponibili nei nodi RIG. |
| Metriche di inferenza | No | I carichi di lavoro di inferenza non sono supportati nei gruppi di istanze con restrizioni. |
| Metriche di governance delle attività | No | Le metriche Kueue vengono raccolte solo dai nodi standard, se presenti. |
| Metriche di dimensionamento | No | Le metriche KEDA vengono raccolte solo dai nodi standard, se presenti. |
| Parametri cluster | Sì | Sono disponibili le metriche dello stato di Kube e le metriche del server API. Kube State Metrics è pianificato preferibilmente su nodi standard, ma può essere eseguito su nodi con restrizioni in cluster solo Rig. |
| Parametri dell'istanza | Sì | Le metriche di Node Exporter e CADvisor vengono raccolte su tutti i nodi, compresi i nodi con restrizioni. |
| Metriche di calcolo accelerate | Sì | DCGM Exporter funziona su nodi limitati abilitati alla GPU. Neuron Monitor funziona su nodi limitati abilitati a Neuron quando è abilitata la modalità avanzata. |
| Metriche di rete | Sì | EFA Exporter funziona su nodi con restrizioni abilitati per EFA quando è abilitata la modalità avanzata. |
| Metriche del file system | Sì | FSx le metriche di utilizzo del cluster for Lustre sono supportate su Restricted Instance Groups. |
**Nota**
La raccolta dei log dei container con Fluent Bit non viene distribuita su nodi con restrizioni. I log dei cluster provenienti dai nodi con restrizioni sono disponibili attraverso la SageMaker HyperPod piattaforma indipendentemente dal componente aggiuntivo Observability. È possibile visualizzare questi registri nella dashboard Cluster Logs.
## Metriche di addestramento
Utilizza queste metriche per tenere traccia delle prestazioni delle attività di formazione eseguite sul cluster. SageMaker HyperPod
| Nome o tipo di metrica | Description | Abilitata per impostazione predefinita? | Origine metrica |
| --- | --- | --- | --- |
| Metriche Kubeflow | [https://github.com/kubeflow/trainer](https://github.com/kubeflow/trainer) | Sì | Kubeflow |
| Metriche dei pod di Kubernetes | [https://github.com/kubernetes/kube-state-metrics](https://github.com/kubernetes/kube-state-metrics) | Sì | Kubernetes |
| training\$1uptime\$1percentage | Percentuale di tempo di addestramento rispetto alla finestra di tempo totale | No | SageMaker HyperPod operatore di formazione |
| training\$1manual\$1recovery\$1count | Numero totale di riavvii manuali eseguiti sul processo | No | SageMaker HyperPod operatore addetto alla formazione |
| training\$1manual\$1downtime\$1ms | Tempo totale in millisecondi in cui il processo è stato interrotto a causa di interventi manuali | No | SageMaker HyperPod operatore addetto alla formazione |
| training\$1auto\$1recovery\$1count | Numero totale di ripristini automatici | No | SageMaker HyperPod operatore addetto alla formazione |
| training\$1auto\$1recovery\$1downtime | Tempo totale di sovraccarico dell’infrastruttura in millisecondi durante il ripristino dei guasti | No | SageMaker HyperPod operatore addetto alla formazione |
| training\$1fault\$1count | Numero totale di guasti riscontrati durante l’addestramento | No | SageMaker HyperPod operatore addetto alla formazione |
| training\$1fault\$1type\$1count | Distribuzione dei guasti per tipo | No | SageMaker HyperPod operatore addetto alla formazione |
| training\$1fault\$1recovery\$1time\$1ms | Tempo di ripristino in millisecondi per ogni tipo di guasto | No | SageMaker HyperPod operatore addetto alla formazione |
| training\$1time\$1ms | Tempo totale in millisecondi dedicato all’addestramento effettivo | No | SageMaker HyperPod operatore addetto alla formazione |
## Metriche di inferenza
Utilizza queste metriche per tenere traccia delle prestazioni delle attività di inferenza sul SageMaker HyperPod cluster.
| Nome o tipo di metrica | Description | Abilitata per impostazione predefinita? | Origine metrica |
| --- | --- | --- | --- |
| model\$1invocations\$1total | Numero totale di richieste di invocazione al modello | Sì | SageMaker HyperPod operatore di inferenza |
| model\$1errors\$1total | Numero totale di errori durante l’invocazione del modello | Sì | SageMaker HyperPod operatore di inferenza |
| model\$1concurrent\$1requests | Richieste di modelli simultanee attive | Sì | SageMaker HyperPod operatore di inferenza |
| model\$1latency\$1milliseconds | Latenza di invocazione del modello in millisecondi | Sì | SageMaker HyperPod operatore di inferenza |
| model\$1ttfb\$1milliseconds | Latenza del tempo al primo byte (Time To First Byte, TTFB) del modello in millisecondi | Sì | SageMaker HyperPod operatore di inferenza |
| TGI | Queste metriche possono essere utilizzate per monitorare le prestazioni del TGI, eseguire il dimensionamento automatico dell’implementazione e identificare i colli di bottiglia. Per un elenco dettagliato delle metriche, vedere [https://github.com/deepjavalibrary/djl](https://github.com/deepjavalibrary/djl-serving/blob/master/prometheus/README.md) - .md. serving/blob/master/prometheus/README | Sì | Container del modello |
| LMI | Queste metriche possono essere utilizzate per monitorare le prestazioni dell’LMI e identificare i colli di bottiglia. [Per un elenco dettagliato delle metriche, vedere https://github.com/deepjavalibrary/ djl- .md. serving/blob/master/prometheus/README](https://github.com/deepjavalibrary/djl-serving/blob/master/prometheus/README.md) | Sì | Container del modello |
## Metriche di governance delle attività
Utilizza queste metriche per monitorare la governance delle attività e l'allocazione delle risorse nel cluster. SageMaker HyperPod
| Nome o tipo di metrica | Description | Abilitata per impostazione predefinita? | Origine metrica |
| --- | --- | --- | --- |
| Kueue | [Vedi https://kueue.sigs.k8s. io/docs/reference/metrics](https://kueue.sigs.k8s.io/docs/reference/metrics/)/. | No | Kueue |
## Metriche di dimensionamento
Utilizza queste metriche per monitorare il comportamento e le prestazioni dell'auto-scaling sul cluster. SageMaker HyperPod
| Nome o tipo di metrica | Description | Abilitata per impostazione predefinita? | Origine metrica |
| --- | --- | --- | --- |
| Metriche dell’operatore KEDA | [Vedi https://keda. sh/docs/2.17/integrations/prometheus/\$1operator](https://keda.sh/docs/2.17/integrations/prometheus/#operator). | No | Kubernetes Event-Driven Autoscaler (KEDA) |
| Metriche del webhook KEDA | Vedi [https://keda. sh/docs/2.17/integrations/prometheus/\$1admission -webhooks](https://keda.sh/docs/2.17/integrations/prometheus/#admission-webhooks). | No | Kubernetes Event-Driven Autoscaler (KEDA) |
| Metriche del server di metriche KEDA | [Vedi https://keda. sh/docs/2.17/integrations/prometheus/\$1metrics -server.](https://keda.sh/docs/2.17/integrations/prometheus/#metrics-server) | No | Kubernetes Event-Driven Autoscaler (KEDA) |
## Parametri cluster
Utilizza queste metriche per monitorare l’integrità complessiva del cluster e l’allocazione delle risorse.
| Nome o tipo di metrica | Description | Abilitata per impostazione predefinita? | Origine metrica |
| --- | --- | --- | --- |
| Integrità del cluster | Metriche del server API Kubernetes. Vedi [https://kubernetes. io/docs/reference/instrumentation/metrics](https://kubernetes.io/docs/reference/instrumentation/metrics/)/. | Sì | Kubernetes |
| KubeState | Vedi [https://github.com/kubernetes/kube-state-metrics/\$1default -resources tree/main/docs](https://github.com/kubernetes/kube-state-metrics/tree/main/docs#default-resources). | Limitato | Kubernetes |
| KubeState Avanzato | Vedi [https://github.com/kubernetes/kube-state-metrics/tree/main/docs\$1optional -resources](https://github.com/kubernetes/kube-state-metrics/tree/main/docs#optional-resources). | No | Kubernetes |
## Parametri dell'istanza
Utilizza queste metriche per monitorare le prestazioni e l’integrità delle singole istanze.
| Nome o tipo di metrica | Description | Abilitata per impostazione predefinita? | Origine metrica |
| --- | --- | --- | --- |
| Metriche dei nodi | [Vedi node\$1exporter? https://github.com/prometheus/ readme-ov-filetab= \$1 enabled-by-default](https://github.com/prometheus/node_exporter?tab=readme-ov-file#enabled-by-default). | Sì | Kubernetes |
| Metriche dei container | Metriche dei container esposte da Cadvisor. [Vedi cadvisor. https://github.com/google/](https://github.com/google/cadvisor) | Sì | Kubernetes |
## Metriche di calcolo accelerate
Utilizza queste metriche per monitorare le prestazioni, l’integrità e l’utilizzo dei singoli dispositivi di calcolo accelerati nel tuo cluster.
**Nota**
Quando il partizionamento della GPU con MIG (Multi-Instance GPU) è abilitato sul cluster, le metriche DCGM forniscono automaticamente la granularità a livello di partizione per il monitoraggio delle singole istanze MIG. Ogni partizione MIG è esposta come un dispositivo GPU separato con parametri propri per temperatura, potenza, utilizzo della memoria e attività di calcolo. Ciò consente di tenere traccia dell'utilizzo e dello stato delle risorse per ciascuna partizione GPU in modo indipendente, consentendo un monitoraggio preciso dei carichi di lavoro in esecuzione su risorse GPU frazionarie. Per ulteriori informazioni sulla configurazione del partizionamento della GPU, consulta. [Utilizzo delle partizioni GPU in Amazon SageMaker HyperPod](sagemaker-hyperpod-eks-gpu-partitioning.md)
| Nome o tipo di metrica | Description | Abilitata per impostazione predefinita? | Origine metrica |
| --- | --- | --- | --- |
| GPU NVIDIA | Metriche di DCGM. [Vedere dcgm- -metrics-included.csvhttps://github.com/NVIDIA/. exporter/blob/main/etc/dcp](https://github.com/NVIDIA/dcgm-exporter/blob/main/etc/dcp-metrics-included.csv) | Limitato | NVIDIA Data Center GPU Manager (DCGM) |
| GPU NVIDIA (avanzata) | Metriche di DCGM disattivate nel seguente file CSV:[https://github.com/NVIDIA/dcgm- -metrics-included.csv exporter/blob/main/etc/dcp](https://github.com/NVIDIA/dcgm-exporter/blob/main/etc/dcp-metrics-included.csv) | No | NVIDIA Data Center GPU Manager (DCGM) |
| AWS Trainium | Metriche di Neuron. Vedi [https://awsdocs-neuron.readthedocs-hosted.com/en/latest/tools/neuron-sys-tools/neuron- monitor-user-guide .html\$1. neuron-monitor-nc-counters](https://awsdocs-neuron.readthedocs-hosted.com/en/latest/tools/neuron-sys-tools/neuron-monitor-user-guide.html#neuron-monitor-nc-counters) | No | AWS Monitor neuronale |
## Metriche di rete
Utilizza queste metriche per monitorare le prestazioni e l’integrità degli Elastic Fabric Adapters (EFA) del cluster.
| Nome o tipo di metrica | Description | Abilitata per impostazione predefinita? | Origine metrica |
| --- | --- | --- | --- |
| EFA | Vedi [https://github.com/aws-samples/awsome-distributed-training/blob/main/4.validation\$1and\$1observability/3.efa-node-exporter/README.md.](https://github.com/aws-samples/awsome-distributed-training/blob/main/4.validation_and_observability/3.efa-node-exporter/README.md) | No | Elastic Fabric Adapter |
## Metriche del file system
| Nome o tipo di metrica | Description | Abilitata per impostazione predefinita? | Origine metrica |
| --- | --- | --- | --- |
| File system | Metriche FSx di Amazon for Lustre di Amazon: CloudWatch[Monitoraggio con Amazon CloudWatch](https://docs.aws.amazon.com/fsx/latest/LustreGuide/monitoring-cloudwatch.html). | Sì | Amazon FSx per Lustre |
# Avvisi preconfigurati
Il componente aggiuntivo Amazon SageMaker HyperPod (SageMaker HyperPod) observability abilita avvisi predefiniti per il cluster e i carichi di lavoro per avvisarti quando il sistema rileva indicatori precoci comuni di prestazioni insufficienti del cluster. Questi avvisi sono definiti all’interno del sistema di avvisi integrato di Grafana gestito da Amazon. Per informazioni su come modificare questi avvisi preconfigurati o crearne di nuovi, consulta [Alerts in Grafana version 10](https://docs.aws.amazon.com/grafana/latest/userguide/v10-alerts.html) in *Amazon Managed Grafana User Guide*. Il file YAML seguente mostra gli avvisi predefiniti.
```
groups:
- name: sagemaker_hyperpod_alerts
rules:
# GPU_TEMP_ABOVE_80C
- alert: GPUHighTemperature
expr: DCGM_FI_DEV_GPU_TEMP > 80
for: 5m
labels:
severity: warning
annotations:
summary: "GPU Temperature Above 80C"
description: "GPU {{ $labels.gpu }} temperature is {{ $value }}°C."
# GPU_TEMP_ABOVE_85C
- alert: GPUCriticalTemperature
expr: DCGM_FI_DEV_GPU_TEMP > 85
for: 1m
labels:
severity: critical
annotations:
summary: "GPU Temperature Above 85C"
description: "GPU {{ $labels.gpu }} temperature is {{ $value }}°C."
# GPU_MEMORY_ERROR
# Any ECC double-bit errors indicate serious memory issues requiring immediate attention
- alert: GPUMemoryErrorDetected
expr: DCGM_FI_DEV_ECC_DBE_VOL_TOTAL > 0 or DCGM_FI_DEV_ECC_DBE_AGG_TOTAL > DCGM_FI_DEV_ECC_DBE_AGG_TOTAL offset 5m
labels:
severity: critical
annotations:
summary: "GPU ECC Double-Bit Error Detected"
description: "GPU {{ $labels.gpu }} has detected ECC double-bit errors."
# GPU_POWER_WARNING
# Sustained power limit violations can impact performance and stability
- alert: GPUPowerViolation
expr: DCGM_FI_DEV_POWER_VIOLATION > 100
for: 5m
labels:
severity: warning
annotations:
summary: "GPU Power Violation"
description: "GPU {{ $labels.gpu }} has been operating at power limit for extended period."
# GPU_NVLINK_ERROR
# NVLink errors above threshold indicate interconnect stability issues
- alert: NVLinkErrorsDetected
expr: DCGM_FI_DEV_NVLINK_RECOVERY_ERROR_COUNT_TOTAL > 0 or DCGM_FI_DEV_NVLINK_REPLAY_ERROR_COUNT_TOTAL > 10
labels:
severity: warning
annotations:
summary: "NVLink Errors Detected"
description: "GPU {{ $labels.gpu }} has detected NVLink errors."
# GPU_THERMAL_VIOLATION
# Immediate alert on thermal violations to prevent hardware damage
- alert: GPUThermalViolation
expr: increase(DCGM_FI_DEV_THERMAL_VIOLATION[5m]) > 0
for: 1m
labels:
severity: critical
annotations:
summary: "GPU Thermal Violation Detected"
description: "GPU {{ $labels.gpu }} has thermal violations on node {{ $labels.Hostname }}"
# GPU_XID_ERROR
# XID errors indicate driver or hardware level GPU issues requiring investigation
- alert: GPUXidError
expr: DCGM_FI_DEV_XID_ERRORS > 0
for: 0m
labels:
severity: critical
annotations:
summary: "GPU XID Error Detected"
description: "GPU {{ $labels.gpu }} experienced XID error {{ $value }} on node {{ $labels.Hostname }}"
# MIG_CONFIG_FAILURE
# MIG configuration failures indicate issues with GPU partitioning setup
- alert: MIGConfigFailure
expr: kubelet_node_name{nvidia_com_mig_config_state="failed"} > 0
for: 1m
labels:
severity: critical
annotations:
summary: "MIG Configuration Failed"
description: "MIG configuration failed on node {{ $labels.instance }}"
# DISK_SPACE_WARNING
# 90% threshold ensures time to respond before complete disk exhaustion
- alert: NodeDiskSpaceWarning
expr: (node_filesystem_size_bytes - node_filesystem_free_bytes) / node_filesystem_size_bytes * 100 > 90
for: 5m
labels:
severity: warning
annotations:
summary: "High Disk Usage"
description: "Node {{ $labels.instance }} disk usage is above 90%"
# FSX_STORAGE_WARNING
# 80% FSx utilization allows buffer for burst workloads
- alert: FsxLustreStorageWarning
expr: fsx_lustre_storage_used_bytes / fsx_lustre_storage_capacity_bytes * 100 > 80
for: 5m
labels:
severity: warning
annotations:
summary: "High FSx Lustre Usage"
description: "FSx Lustre storage usage is above 80% on file system {{ $labels.filesystem_id }}"
```
# Risoluzione dei problemi relativi al componente aggiuntivo Amazon SageMaker HyperPod Observability
Utilizza le seguenti linee guida per risolvere problemi comuni con il componente aggiuntivo Amazon SageMaker HyperPod (SageMaker HyperPod) observability.
## Risoluzione dei problemi relativi alle metriche mancanti in Grafana gestito da Amazon
Se le metriche non compaiono nelle dashboard di Grafana gestito da Amazon, segui queste fasi per identificare e risolvere il problema.
### Verifica della connessione tra il Servizio gestito da Amazon per Prometheus e Grafana gestito da Amazon
1. Accedi alla console di Grafana gestito da Amazon.
1. Nel riquadro a sinistra, scegli **Tutto workspaces**.
1. Nella tabella **Workspace**, scegli il tuo spazio di lavoro.
1. Nella pagina dei dettagli dello spazio di lavoro, scegli la scheda **Origini dati**.
1. Verifica che l’origine dati del Servizio gestito da Amazon per Prometheus esista.
1. Controlla le impostazioni di connessione:
+ Conferma che l’URL dell’endpoint sia corretto.
+ Verifica che l’autenticazione IAM sia configurata correttamente.
+ Scegli **Test Connection (Connessione di prova)**. Verifica che lo stato sia **Origine dati funzionante**.
### Verifica dello stato del componente aggiuntivo Amazon EKS
1. Apri la console Amazon EKS a [https://console.aws.amazon.com/eks/home\$1/clusters](https://console.aws.amazon.com/eks/home#/clusters).
1. Selezionare il cluster.
1. Selezionare la scheda **Componenti aggiuntivi**.
1. **Verifica che il componente aggiuntivo di SageMaker HyperPod osservabilità sia elencato e che il suo stato sia ATTIVO.**
1. Se lo stato non è **ACTIVE**, consulta [Risoluzione degli errori di installazione del componente aggiuntivo](#troubleshooting-addon-installation-failures).
### Verifica dell’associazione Pod Identity
1. Apri la console Amazon EKS a [https://console.aws.amazon.com/eks/home\$1/clusters](https://console.aws.amazon.com/eks/home#/clusters).
1. Selezionare il cluster.
1. Nella pagina dei dettagli del cluster, scegli la scheda **Accesso**.
1. Nella tabella **Associazioni Pod Identity**, scegli l’associazione con i valori di proprietà seguenti:
+ **Spazio** dei nomi: `hyperpod-observability`
+ **Account del servizio**: `hyperpod-observability-operator-otel-collector`
+ **Componente aggiuntivo**: `amazon-sagemaker-hyperpod-observability`
1. Assicurati che il ruolo IAM collegato a questa associazione abbia le autorizzazioni seguenti.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "PrometheusAccess",
"Effect": "Allow",
"Action": "aps:RemoteWrite",
"Resource": "arn:aws:aps:us-east-1:111122223333:workspace/workspace-ID"
},
{
"Sid": "CloudwatchLogsAccess",
"Effect": "Allow",
"Action": [
"logs:CreateLogGroup",
"logs:CreateLogStream",
"logs:DescribeLogGroups",
"logs:DescribeLogStreams",
"logs:PutLogEvents",
"logs:GetLogEvents",
"logs:FilterLogEvents",
"logs:GetLogRecord",
"logs:StartQuery",
"logs:StopQuery",
"logs:GetQueryResults"
],
"Resource": [
"arn:aws:logs:us-east-1:111122223333:log-group:/aws/sagemaker/Clusters/*",
"arn:aws:logs:us-east-1:111122223333:log-group:/aws/sagemaker/Clusters/*:log-stream:*"
]
}
]
}
```
------
1. Assicurati che il ruolo IAM collegato a questa associazione abbia la policy di attendibilità seguente. Verifica che l’ARN di origine e l’account di origine siano corretti.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowEksAuthToAssumeRoleForPodIdentity",
"Effect": "Allow",
"Principal": {
"Service": "pods.eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
],
"Condition": {
"StringEquals": {
"aws:SourceArn": "arn:aws:eks:us-east-1:111122223333:cluster/cluster-name",
"aws:SourceAccount": "111122223333"
}
}
}
]
}
```
------
### Verifica della limitazione (della larghezza di banda della rete) del Servizio gestito da Amazon per Prometheus
1. Accedi Console di gestione AWS e apri la console Service Quotas all'indirizzo. [https://console.aws.amazon.com/servicequotas/](https://console.aws.amazon.com/servicequotas/)
1. Nella casella **Quote gestite**, cerca e seleziona Servizio gestito da Amazon per Prometheus.
1. Scegli la quota **Serie attiva per spazio di lavoro**.
1. Nella scheda **Quote a livello di risorsa**, seleziona lo spazio di lavoro del Servizio gestito da Amazon per Prometheus.
1. Assicurati che l’utilizzo sia inferiore alla tua quota attuale.
1. Se hai raggiunto il limite di quota, seleziona lo spazio di lavoro scegliendo il pulsante di opzione a sinistra, quindi seleziona **Richiedi un aumento a livello di risorsa**.
### Verifica che la memorizzazione nella cache KV e il routing intelligente siano abilitati
Se manca la `KVCache Metrics` dashboard, la funzionalità non è abilitata o la porta non è menzionata nel. `modelMetrics` Per ulteriori informazioni su come abilitarla, consulta i passaggi 1 e 3 di seguito[Configura la memorizzazione nella cache KV e il routing intelligente per migliorare le prestazioni](sagemaker-hyperpod-model-deployment-deploy-ftm.md#sagemaker-hyperpod-model-deployment-deploy-ftm-cache-route).
Se manca la `Intelligent Router Metrics` dashboard, abilita la funzione per farli apparire. Per ulteriori informazioni su come abilitarla, consulta[Configura la memorizzazione nella cache KV e il routing intelligente per migliorare le prestazioni](sagemaker-hyperpod-model-deployment-deploy-ftm.md#sagemaker-hyperpod-model-deployment-deploy-ftm-cache-route).
## Risoluzione degli errori di installazione del componente aggiuntivo
Se l’installazione del componente aggiuntivo Observability non riesce, utilizza la procedura seguente per diagnosticare e risolvere il problema.
### Controlla lo stato di integrità della sonda
1. Apri la console Amazon EKS a [https://console.aws.amazon.com/eks/home\$1/clusters](https://console.aws.amazon.com/eks/home#/clusters).
1. Selezionare il cluster.
1. Selezionare la scheda **Componenti aggiuntivi**.
1. Scegli il componente aggiuntivo non riuscito.
1. Consulta la sezione **Problemi di integrità**.
1. Se il problema di integrità è correlato alle credenziali o a Pod Identity, consulta [Verifica dell’associazione Pod Identity](#verify-pod-identity-association). Assicurati inoltre che il componente aggiuntivo Pod Identity Agent sia in esecuzione nel cluster.
1. Verifica la presenza di errori nei log del gestore. Per istruzioni, consulta [Revisione dei log del gestore](#review-manager-logs).
1. Contatta l' AWS assistenza per i dettagli del problema.
### Revisione dei log del gestore
1. Scarica il pod del gestore dei componenti aggiuntivi:
```
kubectl logs -n hyperpod-observability -l control-plane=hyperpod-observability-controller-manager
```
1. Per problemi urgenti, contatta Supporto.
## Revisione di tutti i pod di osservabilità
Tutti i pod creati dal componente aggiuntivo SageMaker HyperPod Observability si trovano nel namespace. `hyperpod-observability` Per ottenere lo stato di questi pod, utilizza il comando seguente.
```
kubectl get pods -n hyperpod-observability
```
Cerca i pod il cui stato è `pending` o `crashloopbackoff`. Utilizza il comando seguente per ottenere i log di questi pod in sospeso o in errore.
```
kubectl logs -n hyperpod-observability pod-name
```
Se non trovi errori nei log, utilizza il comando seguente per descrivere i pod e cercare gli errori.
```
kubectl describe -n hyperpod-observability pod pod-name
```
Per ottenere più contesto, esegui questi due comandi per visualizzare le descrizioni delle implementazioni e dei DaemonSet per questi pod.
```
kubectl describe -n hyperpod-observability deployment deployment-name
```
```
kubectl describe -n hyperpod-observability daemonset daemonset-name
```
## Risoluzione dei problemi relativi ai pod bloccati nello stato in sospeso
Se vedi che ci sono dei pod bloccati nello stato `pending`, assicurati che il nodo sia abbastanza grande da contenerli tutti. Per verificare che lo sia, procedi come segue.
1. Apri la console Amazon EKS a [https://console.aws.amazon.com/eks/home\$1/clusters](https://console.aws.amazon.com/eks/home#/clusters).
1. Scegli il cluster.
1. Scegli la scheda **Calcolo** del cluster.
1. Scegli il nodo con il tipo di istanza più piccolo.
1. Nella sezione di allocazione della capacità, cerca i pod disponibili.
1. Se non ci sono pod disponibili, devi scegliere un tipo di istanza più grande.
Per problemi urgenti, contatta Supporto AWS.
## Risoluzione dei problemi di osservabilità su gruppi di istanze con restrizioni
Utilizza la seguente guida per risolvere problemi specifici dei cluster con Restricted Instance Groups.
### I pod di osservabilità non iniziano su nodi con restrizioni
Se i pod di osservabilità non si avviano su nodi con restrizioni, controlla lo stato e gli eventi dei pod:
```
kubectl get pods -n hyperpod-observability -o wide
kubectl describe pod pod-name -n hyperpod-observability
```
Le cause più comuni includono:
+ **Errori di estrazione delle immagini:** gli eventi del pod possono mostrare errori di estrazione delle immagini se le immagini del contenitore di osservabilità non sono ancora elencate nei nodi con restrizioni. Assicurati di utilizzare la versione più recente del componente aggiuntivo Observability. Se il problema persiste dopo l'aggiornamento, contatta. Supporto
+ **Tolleranze di contaminazione:** verificate che le specifiche del pod includano la tolleranza richiesta per i nodi con restrizioni. Il componente aggiuntivo a partire dalla versione aggiunge `v1.0.5-eksbuild.1` automaticamente questa tolleranza quando il supporto RIG è abilitato. Se utilizzi una versione precedente, esegui l'aggiornamento alla versione più recente.
### Visualizzazione dei log dei pod su nodi con restrizioni
Il `kubectl logs` comando non funziona per i pod in esecuzione su nodi con restrizioni. Questa è una limitazione prevista perché il percorso di comunicazione richiesto per lo streaming dei log non è disponibile sui nodi con restrizioni.
Per visualizzare i log dai nodi con restrizioni, usa la dashboard **Cluster Logs** in Amazon Managed Grafana, che interroga direttamente i log. CloudWatch Puoi filtrare per ID di istanza, flusso di log, livello di log e ricerca a testo libero per trovare le voci di log pertinenti.
### Errori di risoluzione DNS in cluster con nodi standard e limitati
Nei cluster ibridi (cluster con gruppi di istanze standard e limitati), i pod sui nodi standard possono subire dei timeout di risoluzione DNS quando cercano di raggiungere AWS endpoint di servizio come Amazon Managed Service for Prometheus o. CloudWatch
**Causa:** il `kube-dns` servizio dispone di endpoint sia da pod CoredNS standard che da pod CoredNS RIG. I node pod standard non possono raggiungere gli endpoint RIG CoredNS a causa dell'isolamento della rete. Quando si `kube-proxy` bilancia il carico di una richiesta DNS da un pod di nodi standard a un endpoint RIG CoredNS, la richiesta scade.
**Risoluzione:** imposta il `kube-dns` servizio `internalTrafficPolicy: Local` in modo che i pod raggiungano CoredNS solo sul loro nodo locale:
```
kubectl patch svc kube-dns -n kube-system -p '{"spec":{"internalTrafficPolicy":"Local"}}'
```
Dopo aver applicato questa patch, riavvia i pod di osservabilità interessati:
```
kubectl delete pods -n hyperpod-observability -l app.kubernetes.io/name=hyperpod-node-collector
```
### Metriche dei nodi con restrizioni che non raggiungono Amazon Managed Service for Prometheus
Se le metriche dei nodi con restrizioni non vengono visualizzate nel tuo spazio di lavoro Amazon Managed Service for Prometheus:
1. **Verifica le autorizzazioni del ruolo di esecuzione.** Assicurati che il ruolo di esecuzione per il gruppo di istanze ristrette disponga dell'`aps:RemoteWrite`autorizzazione per il tuo spazio di lavoro Prometheus. Per ulteriori informazioni, consulta [Prerequisiti aggiuntivi per i gruppi di istanze con restrizioni](hyperpod-observability-addon-setup.md#hyperpod-observability-addon-rig-prerequisites).
1. **Controlla lo stato del pod node collector.** Esegui il comando seguente e verifica che i pod del collettore di nodi siano in esecuzione su nodi con restrizioni:
```
kubectl get pods -n hyperpod-observability | grep node-collector
```
1. **Controlla le implementazioni del collettore centrale.** Nei cluster con nodi limitati, il componente aggiuntivo implementa un collettore centrale per confine di rete. Verifica che esista un raccoglitore centrale per ogni limite:
```
kubectl get deployments -n hyperpod-observability | grep central-collector
```
1. **Verifica la presenza di errori negli eventi del pod.** `kubectl describe`Utilizzatelo sui collector pod per cercare gli eventi di errore:
```
kubectl describe pod collector-pod-name -n hyperpod-observability
```
Se il problema persiste dopo la verifica di quanto sopra, contatta. Supporto
### La verifica dell'identità del Pod non si applica ai nodi del gruppo di istanze con restrizioni
I [Verifica dell’associazione Pod Identity](#verify-pod-identity-association) passaggi per la risoluzione dei problemi si applicano solo ai nodi standard. Sui nodi con restrizioni, il componente aggiuntivo utilizza il ruolo di esecuzione del gruppo di istanze del cluster per AWS l'autenticazione anziché Amazon EKS Pod Identity. Se nei nodi con restrizioni mancano delle metriche, verifica le autorizzazioni del ruolo di esecuzione anziché l'associazione Pod Identity.
### Fluent Bit non funziona su nodi con restrizioni
Questo è il comportamento previsto. Fluent Bit non viene intenzionalmente distribuito su nodi con restrizioni. I log dei nodi con restrizioni vengono pubblicati CloudWatch attraverso la SageMaker HyperPod piattaforma indipendentemente dal componente aggiuntivo di osservabilità. Utilizza la dashboard **Cluster Logs** in Amazon Managed Grafana per visualizzare questi log.
# Osservabilità con Amazon CloudWatch
Usa [Amazon CloudWatch Container Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContainerInsights.html) per raccogliere, aggregare e riepilogare metriche e log dalle applicazioni containerizzate e dai microservizi sul cluster EKS associato a un cluster. HyperPod
Amazon CloudWatch Insights raccoglie parametri per le risorse di calcolo, come CPU, memoria, disco e rete. Container Insights fornisce inoltre informazioni diagnostiche, ad esempio errori di riavvio del container, che consentono di isolare i problemi e risolverli in modo rapido. Puoi anche impostare CloudWatch allarmi sui parametri raccolti da Container Insights.
Per trovare un elenco completo delle metriche, consulta [Amazon EKS and Kubernetes Container Insights metrics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Container-Insights-metrics-EKS.html) in *Amazon EKS User Guide*.
## Installa Container Insights CloudWatch
*Gli utenti amministratori del cluster devono configurare CloudWatch Container Insights seguendo le istruzioni in [Installa l' CloudWatch agente utilizzando il componente aggiuntivo Amazon CloudWatch Observability EKS o il grafico Helm](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/install-CloudWatch-Observability-EKS-addon.html) nella Guida per l'CloudWatch utente.* Per ulteriori informazioni sul componente aggiuntivo Amazon EKS, consulta anche [Installa il componente aggiuntivo Amazon CloudWatch Observability EKS nella Guida](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Container-Insights-setup-EKS-addon.html) per l'utente di *Amazon EKS*.
Una volta completata l'installazione, verifica che il componente aggiuntivo CloudWatch Observability sia visibile nella scheda del componente aggiuntivo del cluster EKS. Il caricamento della dashboard potrebbe richiedere un paio di minuti.
**Nota**
SageMaker HyperPod richiede CloudWatch Insight v2.0.1-eksbuild.1 o successivo.
![\[CloudWatch Observability service card showing status, version, and IAM role information.\]](http://docs.aws.amazon.com/it_it/sagemaker/latest/dg/images/hyperpod-eks-CIaddon.png)
# Accedi CloudWatch alla dashboard di Container Insights
1. Apri la CloudWatch console all'indirizzo [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. Scegli **Informazioni dettagliate** e **Container Insights**.
1. Seleziona il cluster EKS configurato con il HyperPod cluster che stai utilizzando.
1. Visualizza le metriche dei Pod/Cluster livelli.
![\[Performance monitoring dashboard for EKS cluster showing node status, resource utilization, and pod metrics.\]](http://docs.aws.amazon.com/it_it/sagemaker/latest/dg/images/hyperpod-eks-CIdashboard.png)
## Accedi ai log di CloudWatch Container Insights
1. Apri la CloudWatch console all'indirizzo [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. Scegli **Log** e quindi **Gruppi di log**.
Quando HyperPod i cluster sono integrati con Amazon CloudWatch Container Insights, puoi accedere ai gruppi di log pertinenti nel seguente formato:`/aws/containerinsights //*`. All’interno di questo gruppo di log, puoi trovare ed esplorare vari tipi di log, ad esempio delle prestazioni, degli host, delle applicazioni e del piano dati.
# Provisioning continuo per operazioni cluster avanzate su Amazon EKS
SageMaker HyperPod I cluster Amazon creati con l'orchestrazione di Amazon EKS ora supportano il provisioning continuo, una nuova funzionalità che consente una maggiore flessibilità ed efficienza nell'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 cluster creati con l'orchestrazione EKS. HyperPod I cluster creati con l’orchestrazione Slurm utilizzano un modello di dimensionamento diverso.
## Come funziona
Il sistema di provisioning continuo introduce un’architettura dello stato desiderato che sostituisce il tradizionale modello basato sulla richiesta. Questa nuova architettura consente operazioni parallele e non bloccanti su diversi livelli di risorse, mantenendo al contempo la stabilità e le prestazioni del sistema. Il sistema di provisioning continuo:
+ **Accetta la richiesta**: registra il numero delle istanze di destinazione per ogni gruppo di istanze
+ **Avvia il provisioning**: avvia le istanze per raggiungere il conteggio previsto
**Monitora lo stato di avanzamento**: monitora ogni tentativo di avvio dell’istanza e registra lo stato
+ **Gestisce gli errori**: riprova automaticamente gli avvii non riusciti
Il provisioning continuo è disabilitato per impostazione predefinita. Per utilizzare questa funzionalità, imposta `--node-provisioning-mode` su `Continuous`.
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.
Il provisioning continuo consente inoltre l'accesso e il monitoraggio dettagliato degli eventi [DescribeClusterEvent](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_DescribeClusterEvent.html)e [ListClusterEvent](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_ListClusterEvents.html)la visibilità operativa.
## 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 non riesce, l’allocazione dell’istanza verrà ritentata e verrà addebitata la durata del runtime dello script del ciclo di vita.
+ **Misurazione indipendente**: il ciclo di vita della fatturazione di ogni istanza viene gestito separatamente, evitando errori di fatturazione a cascata
+ **Aggiornamenti della fatturazione in tempo reale**: la fatturazione inizia quando un’istanza inizia a eseguire lo script del ciclo di vita e si arresta quando l’istanza entra in uno stato di terminazione
**Ciclo di vita della fatturazione**
Ogni istanza del cluster segue questo ciclo di vita di fatturazione: HyperPod
+ **La fatturazione inizia**: 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 arresta**: quando l’istanza entra in uno stato di terminazione, indipendentemente dal motivo della terminazione
**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**
È necessario che sia configurato un cluster Amazon EKS esistente con la rete VPC e che sia installato il grafico Helm richiesto. Inoltre, devi preparare uno script di configurazione del ciclo di vita e devi caricarlo in un bucket Amazon S3 a cui può accedere il tuo ruolo di esecuzione. Per ulteriori informazioni, consulta [Gestione dei SageMaker HyperPod cluster orchestrati da Amazon EKS](sagemaker-hyperpod-eks-operate.md).
La seguente AWS CLI operazione crea un HyperPod cluster con un gruppo di istanze e il provisioning continuo abilitato.
```
aws sagemaker create-cluster \
--cluster-name $HP_CLUSTER_NAME \
--orchestrator 'Eks={ClusterArn='$EKS_CLUSTER_ARN'}' \
--vpc-config '{
"SecurityGroupIds": ["'$SECURITY_GROUP'"],
"Subnets": ["'$SUBNET'"]
}' \
--instance-groups '{
"InstanceGroupName": "ig-1",
"InstanceType": "ml.c5.2xlarge",
"InstanceCount": 2,
"LifeCycleConfig": {
"SourceS3Uri": "s3://'$BUCKET_NAME'",
"OnCreate": "on_create_noop.sh"
},
"ExecutionRole": "'$EXECUTION_ROLE'",
"ThreadsPerCore": 1,
"TrainingPlanArn": ""
}' \
--node-provisioning-mode Continuous
// Expected Output:
{
"ClusterArn": "arn:aws:sagemaker:us-west-2::cluster/"
}
```
Dopo aver creato il cluster, puoi utilizzare [ListClusterNodes](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_ListClusterNodes.html)o [DescribeClusterNode](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_DescribeClusterNode.html)per trovare ulteriori informazioni sui nodi del cluster.
La chiamata a queste operazioni restituirà un [ClusterInstanceStatusDetails](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_ClusterInstanceStatusDetails.html)oggetto con uno dei seguenti valori:
+ **Running**: il nodo è integro e registrato con l’orchestratore del cluster (EKS).
+ **Failure**: il provisioning del nodo non è riuscito, ma il sistema riprova automaticamente a eseguire il provisioning con una nuova istanza EC2.
+ **Pending**: è in corso il provisioning o il riavvio del nodo.
+ **ShuttingDown**: La chiusura del nodo è in corso. Il nodo viene rimosso correttamente dal cluster oppure passa in stato di errore se si verificano errori durante la terminazione.
+ **SystemUpdating**: Il nodo è sottoposto a patch AMI, attivate manualmente o come parte dell'applicazione di patch ai cronjob.
+ **DeepHealthCheckInProgress**: Sono in corso [controlli sanitari approfonditi () DHCs](sagemaker-hyperpod-eks-resiliency-deep-health-checks.md). Questa operazione potrebbe richiedere da pochi minuti a diverse ore a seconda della natura dei test. I nodi danneggiati vengono sostituiti e i nodi integri passano in stato Running.
+ **NotFound**: Usato in [BatchAddClusterNodes](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_BatchAddClusterNodes.html)risposta a indicare che un nodo è stato eliminato durante la riproduzione idempotente.
## Requisiti di capacità minima () MinCount
La MinCount funzionalità consente di specificare il numero minimo di istanze che devono essere fornite correttamente prima che un gruppo di istanze passi allo stato. `InService` Questa funzionalità offre un migliore controllo sulle operazioni di scalabilità e aiuta a prevenire scenari in cui i gruppi di istanze con provisioning parziale non possono essere utilizzati efficacemente per i carichi di lavoro di formazione.
**Importante**
MinCount non è una garanzia permanente di capacità minima. Assicura che il numero minimo di istanze specificato sia disponibile solo quando il gruppo di istanze diventa `InService` disponibile per la prima volta. Durante le normali operazioni, ad esempio sostituzioni di istanze non funzionanti o attività di manutenzione, MinCount possono verificarsi brevi cali di seguito.
### Come funziona MinCount
Quando si crea o si aggiorna un gruppo di istanze con MinCount enabled, si verifica il seguente comportamento:
+ **Nuovi gruppi di istanze**: il gruppo di istanze rimane `Creating` attivo fino a quando almeno MinCount le istanze non vengono fornite correttamente e sono pronte. Una volta raggiunta questa soglia, il gruppo di istanze passa a. `InService`
+ **Gruppi di istanze esistenti**: quando si MinCount esegue l'aggiornamento su un gruppo di istanze esistente, lo stato cambia `Updating` fino al soddisfacimento del nuovo MinCount requisito.
+ **Scalabilità continua**: se TargetCount è maggiore di MinCount, il sistema di ridimensionamento continuo continua a tentare di avviare istanze aggiuntive finché non viene raggiunto. TargetCount
+ **Timeout e rollback**: se MinCount non possono essere soddisfatti entro 3 ore, il sistema ripristina automaticamente il gruppo di istanze all'ultimo stato valido conosciuto. Per ulteriori informazioni sul comportamento di rollback, vedete Comportamento [automatico](#sagemaker-hyperpod-scaling-eks-mincount-rollback) del rollback.
### Stato del gruppo di istanze durante le operazioni MinCount
I gruppi di istanze MinCount configurati presentano il seguente comportamento di stato:
Creazione in corso
Per i nuovi gruppi di istanze quando CurrentCount < MinCount. Il gruppo di istanze rimane in questo stato fino al raggiungimento del requisito di capacità minima.
Aggiornamento in corso
Per i gruppi di istanze esistenti quando MinCount viene modificato e CurrentCount < MinCount. Il gruppo di istanze rimane in questo stato finché non viene soddisfatto il nuovo requisito di capacità minima.
InService
Quando MinCount ≤ CurrentCount ≤ TargetCount. Il gruppo di istanze è pronto per l'uso e tutte le operazioni di modifica sono sbloccate.
Durante il `Creating` nostro `Updating` status, si applicano le seguenti restrizioni:
+ Operazioni mutanti come `BatchAddClusterNodes``BatchDeleteClusterNodes`, o `UpdateClusterSoftware` sono bloccate
+ È comunque possibile modificare TargetCount i valori MinCount e per correggere gli errori di configurazione
+ L'eliminazione di gruppi di cluster e istanze è sempre consentita
### Comportamento automatico del rollback
Se un gruppo di istanze non riesce a raggiungerlo MinCount entro 3 ore, il sistema avvia automaticamente un rollback per evitare un'attesa indefinita:
+ **Nuovi gruppi di istanze**: MinCount e TargetCount vengono reimpostati su (0, 0)
+ **Gruppi di istanze esistenti**: MinCount e TargetCount vengono ripristinati ai loro valori dall'ultimo `InService` stato
+ **Selezione delle istanze da terminare**: se è necessario terminare le istanze durante il rollback, il sistema seleziona prima le istanze non integre e poi quelle a cui è stato effettuato il provisioning più recente.
+ **Transizione dello stato**: il gruppo di istanze passa immediatamente `InService` allo stato dopo l'avvio del rollback, consentendo al sistema di scalabilità continua di gestire la capacità in base alle impostazioni di rollback
Il timeout di 3 ore si ripristina ogni volta che viene aggiornato. MinCount Ad esempio, se si esegue l'aggiornamento MinCount più volte, il periodo di timeout ricomincia dall'aggiornamento più recente.
### MinCount eventi
Il sistema emette eventi specifici per aiutarvi a tenere traccia MinCount delle operazioni:
+ **Capacità minima raggiunta**: emessa quando un gruppo di istanze raggiunge con successo la propria posizione MinCount e passa a `InService`
+ **Rollback avviato**: emesso quando scade il timeout di 3 ore e inizia il rollback automatico
È possibile monitorare questi eventi utilizzando per tenere traccia dello stato di avanzamento delle [ListClusterEvents](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_ListClusterEvents.html)operazioni. MinCount
### Utilizzo delle API
MinCount viene specificato utilizzando il `MinInstanceCount` parametro nelle configurazioni del gruppo di istanze:
```
aws sagemaker create-cluster \
--cluster-name $HP_CLUSTER_NAME \
--orchestrator 'Eks={ClusterArn='$EKS_CLUSTER_ARN'}' \
--vpc-config '{
"SecurityGroupIds": ["'$SECURITY_GROUP'"],
"Subnets": ["'$SUBNET'"]
}' \
--instance-groups '{
"InstanceGroupName": "worker-group",
"InstanceType": "ml.p4d.24xlarge",
"InstanceCount": 64,
"MinInstanceCount": 50,
"LifeCycleConfig": {
"SourceS3Uri": "s3://'$BUCKET_NAME'",
"OnCreate": "on_create.sh"
},
"ExecutionRole": "'$EXECUTION_ROLE'"
}' \
--node-provisioning-mode Continuous
```
Considerazioni chiave per MinCount l'utilizzo:
+ `MinInstanceCount`deve essere compreso tra 0 e il valore `InstanceCount` (incluso) del gruppo di istanze specificato nella [CreateCluster](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_CreateCluster.html)nostra richiesta [UpdateCluster](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_UpdateCluster.html)
+ L'impostazione `MinInstanceCount` su 0 (impostazione predefinita) mantiene il comportamento di ridimensionamento continuo standard
+ L'impostazione `MinInstanceCount` uguale a `InstanceCount` fornisce un comportamento di all-or-nothing ridimensionamento
+ MinCount è disponibile solo per i cluster impostati `NodeProvisioningMode` su `Continuous`
# Scalabilità automatica su EKS SageMaker HyperPod
Amazon SageMaker HyperPod fornisce una soluzione gestita di scalabilità automatica dei nodi basata su Karpenter per i cluster creati con l'orchestrazione EKS. [Karpenter](https://karpenter.sh/) è un gestore del ciclo di vita dei nodi Kubernetes open source creato da Kubernetes che ottimizza la scalabilità dei cluster e l'efficienza dei costi. AWS A differenza delle implementazioni Karpenter autogestite, l'implementazione gestita di Karpenter elimina il sovraccarico operativo legato all'installazione, SageMaker HyperPod alla configurazione e alla manutenzione dei controller Karpenter, fornendo al contempo resilienza e tolleranza ai guasti integrate. Questa soluzione di scalabilità automatica gestita si basa sulle funzionalità di [provisioning continuo](sagemaker-hyperpod-scaling-eks.md) di cui dispone e consente di scalare in modo efficiente le risorse HyperPod di calcolo per i carichi di lavoro di addestramento e inferenza con gestione e ripristino automatici degli errori.
I prezzi sono calcolati solo in base all'uso effettivo. Sei responsabile del pagamento di tutte le istanze di elaborazione il cui provisioning viene eseguito automaticamente tramite la scalabilità automatica in base ai prezzi standard. SageMaker HyperPod Per informazioni dettagliate sui prezzi, consulta [Amazon SageMaker AI](https://aws.amazon.com/sagemaker/ai/pricing/).
Abilitando la scalabilità automatica basata su Karpenter con HyperPod, hai accesso a:
+ **Ciclo di vita gestito dal servizio**: HyperPod gestisce l'installazione, gli aggiornamenti e la manutenzione di Karpenter, eliminando il sovraccarico operativo.
+ **Provisioning just-in-time**: Karpenter osserverà i pod in sospeso e allocherà le risorse di calcolo necessarie per i carichi di lavoro dal pool on demand.
+ **Riduzione verticale a zero**: riduci verticalmente i nodi a zero senza gestire un’infrastruttura di controller dedicata.
+ **Selezione dei nodi in base al carico di lavoro**: Karpenter sceglie i tipi di istanze ottimali in base ai requisiti dei pod, alle zone di disponibilità e ai prezzi per ridurre al minimo i costi.
+ **Consolidamento automatico dei nodi**: Karpenter valuta regolarmente i cluster per individuare opportunità di ottimizzazione, spostando i carichi di lavoro per eliminare i nodi sottoutilizzati.
+ **Resilienza integrata**: sfrutta i meccanismi integrati di tolleranza agli errori e HyperPod ripristino dei nodi.
I seguenti argomenti spiegano come abilitare la scalabilità HyperPod automatica con Karpenter.
**Topics**
+ [Prerequisiti](#sagemaker-hyperpod-eks-autoscaling-prereqs)
+ [Crea un ruolo IAM per la HyperPod scalabilità automatica con Karpenter](sagemaker-hyperpod-eks-autoscaling-iam.md)
+ [Crea e configura un HyperPod cluster con la scalabilità automatica di Karpenter](sagemaker-hyperpod-eks-autoscaling-cluster.md)
+ [Crea un NodeClass](sagemaker-hyperpod-eks-autoscaling-nodeclass.md)
+ [Crea un NodePool](sagemaker-hyperpod-eks-autoscaling-nodepool.md)
+ [Implementazione di un carico di lavoro](sagemaker-hyperpod-eks-autoscaling-workload.md)
## Prerequisiti
+ Il provisioning continuo è abilitato sul cluster. HyperPod Abilita il provisioning continuo impostando su `--node-provisioning-mode` al `Continuous` momento della creazione del cluster SageMaker HyperPod . Per ulteriori informazioni, consulta [Provisioning continuo per operazioni cluster avanzate su Amazon EKS](sagemaker-hyperpod-scaling-eks.md).
+ Deve essere installata la versione 1.0.742.0\$11.0.241.0 o successiva dell’agente di monitoraggio dell’integrità. Necessario per le operazioni e il monitoraggio del HyperPod cluster. L’agente deve essere configurato prima di abilitare il dimensionamento automatico di Karpenter per garantire la creazione di report corretti sull’integrità del cluster e la gestione del ciclo di vita dei nodi. Per ulteriori informazioni, consulta [Sistema di monitoraggio della salute](sagemaker-hyperpod-eks-resiliency-health-monitoring-agent.md).
+ Solo se sul cluster Amazon EKS è in esecuzione Karpenter, le versioni di `NodePool` e `NodeClaim` di Karpenter devono essere v1.
+ `NodeRecovery` deve essere impostato su automatico. Per ulteriori informazioni, consulta [Ripristino automatico del nodo](sagemaker-hyperpod-eks-resiliency-node-recovery.md).
# Crea un ruolo IAM per la HyperPod scalabilità automatica con Karpenter
Nei passaggi seguenti, creerai un ruolo IAM che consenta di gestire i nodi Kubernetes nel tuo cluster SageMaker HyperPod tramite la scalabilità automatica basata su Karpenter. Questo ruolo fornisce le autorizzazioni necessarie per aggiungere e rimuovere automaticamente i nodi del cluster in base HyperPod alla richiesta del carico di lavoro.
**Apertura della console IAM**
1. Accedi Console di gestione AWS e apri la console IAM all'indirizzo console.aws.amazon.com.
1. Nel pannello di navigazione, seleziona **Roles** (Ruoli).
1. Selezionare **Create role (Crea ruolo)**.
**Configurazione della policy di attendibilità**
1. Per **Trusted entity type** (Tipo di entità attendibile), scegli **Custom trust policy** (Policy di attendibilità personalizzata).
1. Nell’editor **Policy di attendibilità personalizzata**, sostituisci la policy predefinita con la seguente:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": [
"hyperpod.sagemaker.amazonaws.com"
]
},
"Action": "sts:AssumeRole"
}
]
}
```
------
1. Scegli **Next (Successivo)**.
**Creazione e collegamento della policy di autorizzazione**
Poiché SageMaker HyperPod richiede autorizzazioni specifiche che non sono disponibili nelle politiche AWS gestite, devi creare una politica personalizzata.
1. Scegli **Crea policy**. Si apre una nuova scheda del browser.
1. Scegli la scheda **JSON**.
1. Sostituisci la policy predefinita con la policy seguente:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"sagemaker:BatchAddClusterNodes",
"sagemaker:BatchDeleteClusterNodes"
],
"Resource": "arn:aws:sagemaker:*:*:cluster/*",
"Condition": {
"StringEquals": {
"aws:ResourceAccount": "${aws:PrincipalAccount}"
}
}
},
{
"Effect": "Allow",
"Action": [
"kms:CreateGrant",
"kms:DescribeKey"
],
"Resource": "arn:aws:kms:*:*:key/*",
"Condition": {
"StringLike": {
"kms:ViaService": "sagemaker.*.amazonaws.com"
},
"Bool": {
"kms:GrantIsForAWSResource": "true"
},
"ForAllValues:StringEquals": {
"kms:GrantOperations": [
"CreateGrant",
"Decrypt",
"DescribeKey",
"GenerateDataKeyWithoutPlaintext",
"ReEncryptTo",
"ReEncryptFrom",
"RetireGrant"
]
}
}
}
]
}
```
------
1. Scegli **Next (Successivo)**.
1. In **Policy name** (Nome policy), inserisci **SageMakerHyperPodKarpenterPolicy**.
1. (Facoltativo) In **Descrizione**, inserisci una descrizione per la policy.
1. Scegliere **Create Policy (Crea policy)**.
1. Torna alla scheda di creazione del ruolo e aggiorna l’elenco delle policy.
1. Cerca e seleziona **SageMakerHyperPodKarpenterPolicy**quello che hai appena creato.
1. Scegli **Next (Successivo)**.
**Assegnazione di un nome e creazione del ruolo**
1. Per **Nome ruolo**, inserisci `SageMakerHyperPodKarpenterRole`.
1. (Facoltativo) In **Descrizione**, inserisci una descrizione per il ruolo.
1. Nella sezione **Fase 1. Seleziona le entità attendibili**, verifica che la policy di attendibilità indichi i principali dei servizi corretti.
1. Nella sezione **Fase 2. Aggiungi autorizzazioni**, verifica che `SageMakerHyperPodKarpenterPolicy` sia collegato.
1. Scegli **Crea ruolo**.
**Registrazione dell’ARN del ruolo**
Dopo aver creato correttamente il ruolo:
1. Nell’elenco **Ruoli**, seleziona il ruolo chiamato `SageMakerHyperPodKarpenterRole`.
1. Copia l’**ARN del ruolo** dalla sezione **Riepilogo**. Avrai bisogno di questo ARN per creare il tuo HyperPod cluster.
L’ARN del ruolo ha questo formato: `arn:aws:iam::ACCOUNT-ID:role/SageMakerHyperPodKarpenterRole`.
# Crea e configura un HyperPod cluster con la scalabilità automatica di Karpenter
Nei passaggi seguenti, creerai un SageMaker HyperPod cluster con il provisioning continuo abilitato e lo configurerai per utilizzare la scalabilità automatica basata su Karpenter.
**Crea un cluster HyperPod**
1. Carica la configurazione dell'ambiente ed estrai i valori dagli CloudFormation stack.
```
source .env
SUBNET1=$(cfn-output $VPC_STACK_NAME PrivateSubnet1)
SUBNET2=$(cfn-output $VPC_STACK_NAME PrivateSubnet2)
SUBNET3=$(cfn-output $VPC_STACK_NAME PrivateSubnet3)
SECURITY_GROUP=$(cfn-output $VPC_STACK_NAME NoIngressSecurityGroup)
EKS_CLUSTER_ARN=$(cfn-output $EKS_STACK_NAME ClusterArn)
EXECUTION_ROLE=$(cfn-output $SAGEMAKER_STACK_NAME ExecutionRole)
SERVICE_ROLE=$(cfn-output $SAGEMAKER_STACK_NAME ServiceRole)
BUCKET_NAME=$(cfn-output $SAGEMAKER_STACK_NAME Bucket)
HP_CLUSTER_NAME="hyperpod-eks-test-$(date +%s)"
EKS_CLUSTER_NAME=$(cfn-output $EKS_STACK_NAME ClusterName)
HP_CLUSTER_ROLE=$(cfn-output $SAGEMAKER_STACK_NAME ClusterRole)
```
1. Carica lo script di inizializzazione del nodo sul tuo bucket Amazon S3.
```
aws s3 cp lifecyclescripts/on_create_noop.sh s3://$BUCKET_NAME
```
1. Crea un file di configurazione del cluster con le variabili di ambiente.
```
cat > cluster_config.json << EOF
{
"ClusterName": "$HP_CLUSTER_NAME",
"InstanceGroups": [
{
"InstanceCount": 1,
"InstanceGroupName": "system",
"InstanceType": "ml.c5.xlarge",
"LifeCycleConfig": {
"SourceS3Uri": "s3://$BUCKET_NAME",
"OnCreate": "on_create_noop.sh"
},
"ExecutionRole": "$EXECUTION_ROLE"
},
{
"InstanceCount": 0,
"InstanceGroupName": "auto-c5-az1",
"InstanceType": "ml.c5.xlarge",
"LifeCycleConfig": {
"SourceS3Uri": "s3://$BUCKET_NAME",
"OnCreate": "on_create_noop.sh"
},
"ExecutionRole": "$EXECUTION_ROLE"
},
{
"InstanceCount": 0,
"InstanceGroupName": "auto-c5-4xaz2",
"InstanceType": "ml.c5.4xlarge",
"LifeCycleConfig": {
"SourceS3Uri": "s3://$BUCKET_NAME",
"OnCreate": "on_create_noop.sh"
},
"ExecutionRole": "$EXECUTION_ROLE",
"OverrideVpcConfig": {
"SecurityGroupIds": [
"$SECURITY_GROUP"
],
"Subnets": [
"$SUBNET2"
]
}
},
{
"InstanceCount": 0,
"InstanceGroupName": "auto-g5-az3",
"InstanceType": "ml.g5.xlarge",
"LifeCycleConfig": {
"SourceS3Uri": "s3://$BUCKET_NAME",
"OnCreate": "on_create_noop.sh"
},
"ExecutionRole": "$EXECUTION_ROLE",
"OverrideVpcConfig": {
"SecurityGroupIds": [
"$SECURITY_GROUP"
],
"Subnets": [
"$SUBNET3"
]
}
}
],
"VpcConfig": {
"SecurityGroupIds": [
"$SECURITY_GROUP"
],
"Subnets": [
"$SUBNET1"
]
},
"Orchestrator": {
"Eks": {
"ClusterArn": "$EKS_CLUSTER_ARN"
}
},
"ClusterRole": "$HP_CLUSTER_ROLE",
"AutoScaling": {
"Mode": "Enable",
"AutoScalerType": "Karpenter"
},
"NodeProvisioningMode": "Continuous"
}
EOF
```
1. Esegui il comando seguente per creare il tuo HyperPod cluster.
```
aws sagemaker create-cluster --cli-input-json file://./cluster_config.json
```
1. La procedura di creazione del cluster richiede circa 20 minuti. Monitora lo stato del cluster fino alla visualizzazione sia ClusterStatus di .Status che di AutoScaling .Status. InService
1. Salva l’ARN del cluster per le operazioni successive.
```
HP_CLUSTER_ARN=$(aws sagemaker describe-cluster --cluster-name $HP_CLUSTER_NAME \
--output text --query ClusterArn)
```
**Abilitazione del dimensionamento automatico Karpenter**
1. Utilizza il comando seguente per abilitare il dimensionamento automatico basato su Karpenter su qualsiasi cluster preesistente con la modalità di provisioning continuo dei nodi.
```
aws sagemaker update-cluster \
--cluster-name $HP_CLUSTER_NAME \
--auto-scaling Mode=Enable,AutoScalerType=Karpenter \
--cluster-role $HP_CLUSTER_ROLE
```
1. Verifica che Karpenter sia stato abilitato correttamente:
```
aws sagemaker describe-cluster --cluster-name $HP_CLUSTER_NAME --query 'AutoScaling'
```
1. Output previsto:
```
{
"Mode": "Enable",
"AutoScalerType": "Karpenter",
"Status": "InService"
}
```
Attendi che `Status` venga visualizzato `InService` prima di procedere alla configurazione NodeClass e. NodePool
# Crea un NodeClass
**Importante**
È necessario iniziare con 0 nodi nel gruppo di istanze e lasciare che Karpenter gestisca il dimensionamento automatico. Se inizi con più di 0 nodi, Karpenter li ridurrà verticalmente fino a 0.
Una classe di nodi (`NodeClass`) definisce le impostazioni a livello di infrastruttura che si applicano ai gruppi di nodi del cluster Amazon EKS, tra cui la configurazione di rete, le impostazioni di archiviazione e il tagging delle risorse. A `HyperPodNodeClass` è una personalizzazione `NodeClass` che si associa a gruppi di istanze precreati e definisce i vincoli relativi ai tipi di istanze e alle zone di disponibilità supportati per le decisioni di scalabilità automatica di Karpenter. SageMaker HyperPod
**Considerazioni sulla creazione di una classe di nodi**
+ Puoi specificare fino a 10 gruppi di istanze in `NodeClass`.
+ Quando si utilizza il partizionamento GPU con MIG (Multi-Instance GPU), Karpenter può fornire automaticamente ai nodi gruppi di istanze abilitati per Mig. Assicurati che i tuoi gruppi di istanze includano tipi di istanze supportati da Mig (ml.p4d.24xlarge, ml.p5.48xlarge o ml.p5e/p5en.48xlarge) e configura le etichette MIG appropriate durante la creazione del cluster. Per ulteriori informazioni sulla [Utilizzo delle partizioni GPU in Amazon SageMaker HyperPod](sagemaker-hyperpod-eks-gpu-partitioning.md) configurazione del partizionamento GPU, consulta.
+ Se vengono applicate etichette personalizzate ai gruppi di istanze, è possibile visualizzarle sul `desiredLabels` campo quando si interroga lo stato. `HyperpodNodeClass` Ciò include etichette di configurazione MIG come. `nvidia.com/mig.config` Quando i lavori in entrata richiedono risorse MIG, Karpenter ridimensionerà automaticamente le istanze applicando le etichette MIG appropriate.
+ Se scegli di eliminare un gruppo di istanze, ti consigliamo di rimuoverlo dal tuo `NodeClass` prima di eliminarlo dal cluster. HyperPod Se un gruppo di istanze viene eliminato mentre è utilizzato in `NodeClass`, `NodeClass` viene contrassegnato come non pronto (`Ready`) per il provisioning e non verrà utilizzato per le successive operazioni di dimensionamento finché il gruppo di istanze non viene rimosso da `NodeClass`.
+ Quando rimuovi i gruppi di istanze da `NodeClass`, Karpenter rileva una deriva nei nodi gestiti da Karpenter in uno o più gruppi di istanze e arresta i nodi in base ai controlli del budget di interruzione.
+ Le sottoreti utilizzate dal gruppo di istanze devono appartenere alla stessa AZ. Le sottoreti vengono specificate a livello di cluster o utilizzando `OverrideVpcConfig` a livello di gruppo di istanze. `VpcConfig` viene utilizzato per impostazione predefinita.
+ Al momento è supportata solo la capacità on demand. I gruppi di istanze con piano di addestramento o capacità riservata non sono supportati.
+ I gruppi di istanze con `DeepHealthChecks (DHC)` non sono supportati. Questo dipende dal fatto che un DHC richiede circa 60-90 minuti per essere completato e durante questo periodo i pod restano in sospeso, causando potenzialmente un provisioning eccessivo.
La procedura che segue illustra come creare `NodeClass`.
1. Crea un file YAML (ad esempio, nodeclass.yaml) con la configurazione `NodeClass`.
1. Applica la configurazione al cluster utilizzando kubectl.
1. Fai riferimento a `NodeClass` nella configurazione `NodePool`.
1. Ecco un esempio di `NodeClass` che utilizza i tipi di istanze ml.c5.xlarge e ml.c5.4xlarge:
```
apiVersion: karpenter.sagemaker.amazonaws.com/v1
kind: HyperpodNodeClass
metadata:
name: sample-nc
spec:
instanceGroups:
# name of InstanceGroup in HyperPod cluster. InstanceGroup needs to pre-created
# MaxItems: 10
- auto-c5-xaz1
- auto-c5-4xaz2
```
1. Applica la configurazione:
```
kubectl apply -f nodeclass.yaml
```
1. Monitora lo NodeClass stato per assicurarti che la condizione Ready in status sia impostata su True:
```
kubectl get hyperpodnodeclass sample-nc -o yaml
```
```
apiVersion: karpenter.sagemaker.amazonaws.com/v1
kind: HyperpodNodeClass
metadata:
creationTimestamp: ""
name: sample-nc
uid:
spec:
instanceGroups:
- auto-c5-az1
- auto-c5-4xaz2
status:
conditions:
// true when all IGs in the spec are present in SageMaker cluster, false otherwise
- lastTransitionTime: ""
message: ""
observedGeneration: 3
reason: InstanceGroupReady
status: "True"
type: InstanceGroupReady
// true if subnets of IGs are discoverable, false otherwise
- lastTransitionTime: ""
message: ""
observedGeneration: 3
reason: SubnetsReady
status: "True"
type: SubnetsReady
// true when all dependent resources are Ready [InstanceGroup, Subnets]
- lastTransitionTime: ""
message: ""
observedGeneration: 3
reason: Ready
status: "True"
type: Ready
instanceGroups:
- desiredLabels:
- key:
value:
- key: nvidia.com/mig.config
value: all-1g.5gb
instanceTypes:
- ml.c5.xlarge
name: auto-c5-az1
subnets:
- id:
zone:
zoneId:
- instanceTypes:
- ml.c5.4xlarge
name: auto-c5-4xaz2
subnets:
- id:
zone:
zoneId:
```
# Crea un NodePool
`NodePool` imposta i vincoli sui nodi che possono essere creati da Karpenter e sui pod che possono essere eseguiti su tali nodi. `NodePool` può essere configurato per:
+ Limitare la creazione di nodi a determinate zone, tipi di istanze e architetture informatiche.
+ Definire le etichette o i taint per limitare i pod che possono essere eseguiti sui nodi creati da Karpenter.
**Nota**
HyperPod il provider supporta una serie limitata di requisiti noti di Kubernetes e Karpenter spiegati di seguito.
La procedura che segue illustra come creare `NodePool`.
1. Crea un file YAML denominato nodepool.yaml con la configurazione `NodePool` desiderata.
1. Puoi utilizzare la configurazione di esempio seguente.
Cerca `Ready` in `Conditions` per verificare che tutte le risorse dipendenti funzionino correttamente.
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: sample-np
spec:
template:
spec:
nodeClassRef:
group: karpenter.sagemaker.amazonaws.com
kind: HyperpodNodeClass
name: multiazc5
expireAfter: Never
requirements:
- key: node.kubernetes.io/instance-type
operator: Exists
```
1. Applica `NodePool` al cluster:
```
kubectl apply -f nodepool.yaml
```
1. Monitora lo stato di `NodePool` per assicurarti che la condizione `Ready` nello stato sia impostata su `True`:
```
kubectl get nodepool sample-np -oyaml
```
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name:
uid:
...
spec:
disruption:
budgets:
- nodes: 90%
consolidateAfter: 0s
consolidationPolicy: WhenEmptyOrUnderutilized
template:
spec:
expireAfter: 720h
nodeClassRef:
group: karpenter.sagemaker.amazonaws.com
kind: HyperpodNodeClass
name:
requirements:
- key: node.kubernetes.io/instance-type
operator: Exists
status:
conditions:
- lastTransitionTime: ""
message: ""
observedGeneration: 2
reason: ValidationSucceeded
status: "True"
type: ValidationSucceeded
- lastTransitionTime: ""
message: ""
observedGeneration: 2
reason: NodeClassReady
status: "True"
type: NodeClassReady
- lastTransitionTime: ""
message: ""
observedGeneration: 2
reason: Ready
status: "True"
type: Ready
```
**Etichette supportate per Karpenter Provider HyperPod**
Questi sono i vincoli e i requisiti facoltativi che puoi specificare nella tua configurazione `NodePool`.
| Tipo di requisito | Scopo | Usa valori Case/Supported | Raccomandazione |
| --- | --- | --- | --- |
| Tipi di istanza (`node.kubernetes.io/instance-type`) | Controlla i tipi di SageMaker istanza tra cui Karpenter può scegliere | Invece di limitarti a ml.c5.xlarge, lascia che Karpenter scelga tra tutti i tipi disponibili nei tuoi gruppi di istanze. | Lascia questo campo indefinito o utilizza l’operatore Exists per dare a Karpenter la massima flessibilità nella scelta di tipi di istanze più convenienti. |
| Zone di disponibilità (`topology.kubernetes.io/zone`) | Controlla in quali zone di AWS disponibilità possono essere creati i nodi | Nomi di zone specifici come us-east-1c. Da utilizzare se i pod devono funzionare in zone specifiche per motivi di latenza o conformità. | N/A |
| Architettura (`kubernetes.io/arch`) | Specifica l’architettura della CPU. | Solo amd64 (attualmente ARM non è supportato). | N/A |
# Implementazione di un carico di lavoro
Gli esempi seguenti mostrano come la HyperPod scalabilità automatica con Karpenter effettua automaticamente il provisioning dei nodi in risposta alle richieste del carico di lavoro. Questi esempi mostrano il comportamento di dimensionamento di base e i modelli di distribuzione in più zone di disponibilità.
**Implementazione di un carico di lavoro semplice**
1. La seguente implementazione di Kubernetes include pod che richiedono 1 CPU e 256 M di memoria per ogni replica o pod. In questo scenario, 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
```
1. Per testare il processo di aumento verticale, utilizza il comando seguente. Karpenter aggiungerà nuovi nodi al cluster.
```
kubectl scale deployment inflate --replicas 10
```
1. Per testare il processo di riduzione verticale, utilizza il comando seguente. Karpenter rimuoverà i nodi dal cluster.
```
kubectl scale deployment inflate --replicas 0
```
**Implementa un carico di lavoro su più AZs**
1. Utilizza il comando seguente per implementare un carico di lavoro che esegua un’implementazione di Kubernetes in cui i pod in fase di implementazione devono essere distribuiti uniformemente tra diverse zone di disponibilità con una differenza massima di 1.
```
kubectl apply -f https://raw.githubusercontent.com/aws/karpenter-provider-aws/refs/heads/main/examples/workloads/spread-zone.yaml
```
1. Utilizza il comando seguente per regolare il numero di pod:
```
kubectl scale deployment zone-spread --replicas 15
```
Karpenter aggiungerà nuovi nodi al cluster con almeno un nodo in una zona di disponibilità diversa.
Per altri esempi, consulta [Karpenter](https://github.com/aws/karpenter-provider-aws/tree/main/examples/workloads) example workloads on. GitHub