Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
# Amazon SageMaker HyperPod
SageMaker HyperPod hilft Ihnen bei der Bereitstellung robuster Cluster für die Ausführung von Workloads für maschinelles Lernen (ML) und die Entwicklung von state-of-the-art Modellen wie großen Sprachmodellen (LLMs), Diffusionsmodellen und Basismodellen (). FMs Es beschleunigt die Entwicklung von, FMs indem der undifferenzierte Aufwand für den Aufbau und die Wartung großer Rechencluster entfällt, die von Tausenden von Beschleunigern wie AWS Trainium und NVIDIA A100 und H100 Graphical Processing Units () unterstützt werden. GPUs Wenn Beschleuniger ausfallen, erkennen und ersetzen die Resilienzfunktionen von SageMaker HyperPod Monitor the Cluster Instances die fehlerhafte Hardware automatisch im laufenden Betrieb, sodass Sie sich auf die Ausführung von ML-Workloads konzentrieren können.
Überprüfen Sie zunächst eine der folgenden Orchestrator-Optionen[Voraussetzungen für die Verwendung SageMaker HyperPod](sagemaker-hyperpod-prerequisites.md), die von unterstützt werden[AWS Identity and Access Management für SageMaker HyperPod](sagemaker-hyperpod-prerequisites-iam.md), und richten Sie sie ein und wählen Sie sie aus. SageMaker HyperPod
**Slurm-Unterstützung in SageMaker HyperPod**
SageMaker HyperPod bietet Unterstützung für die Ausführung von Machine-Learning-Workloads auf belastbaren Clustern durch die Integration mit Slurm, einem Open-Source-Workload-Manager. Die Slurm-Unterstützung SageMaker HyperPod ermöglicht eine nahtlose Cluster-Orchestrierung durch die Slurm-Cluster-Konfiguration, sodass Sie Head-, Anmelde- und Worker-Knoten auf den SageMaker HyperPod Clustern einrichten können. Diese Integration erleichtert auch die SLURM-basierte Jobplanung für die Ausführung von ML-Workloads auf dem Cluster sowie den direkten Zugriff auf Clusterknoten für die Jobplanung. Mit HyperPod der Unterstützung für die Lebenszykluskonfiguration können Sie die Computerumgebung der Cluster an Ihre spezifischen Anforderungen anpassen. Darüber hinaus können Sie durch die Nutzung der verteilten Schulungsbibliotheken von Amazon SageMaker AI die Leistung der Cluster in Bezug auf AWS Rechen- und Netzwerkressourcen optimieren. Weitere Informationen hierzu finden Sie unter [Orchestrierung von SageMaker HyperPod Clustern mit Slurm](sagemaker-hyperpod-slurm.md).
**Amazon EKS-Unterstützung in SageMaker HyperPod**
SageMaker HyperPod lässt sich auch in Amazon EKS integrieren, um ein umfangreiches Training von Basismodellen auf langlebigen und belastbaren Rechenclustern zu ermöglichen. Auf diese Weise können Cluster-Administratoren HyperPod Cluster bereitstellen und sie an eine EKS-Steuerebene anhängen, was ein dynamisches Kapazitätsmanagement, direkten Zugriff auf Cluster-Instances und Resilienzfunktionen ermöglicht. Für Datenwissenschaftler HyperPod ermöglicht die Amazon EKS-Unterstützung die Ausführung containerisierter Workloads für das Training von Basismodellen, Inferenzen auf dem EKS-Cluster und die Nutzung der Funktion zur automatischen Wiederaufnahme von Jobs für Kubeflow-Schulungen. PyTorch Die Architektur beinhaltet eine 1-zu-1-Zuordnung zwischen einem EKS-Cluster (Kontrollebene) und einem HyperPod Cluster (Worker-Knoten) innerhalb einer VPC und bietet so eine eng integrierte Lösung für die Ausführung umfangreicher ML-Workloads. Weitere Informationen hierzu finden Sie unter [Orchestrierung von SageMaker HyperPod Clustern mit Amazon EKS](sagemaker-hyperpod-eks.md).
**UltraServers mit HyperPod**
HyperPod mit UltraServers liefert KI-Rechenleistung durch die Integration von NVIDIA-Superchips in eine zusammenhängende, leistungsstarke Infrastruktur. Jede Instanz NVL72 UltraServer kombiniert 18 Instanzen mit 72 GPUs miteinander verbundenen NVIDIA-Blackwell-Instanzen NVLink, was im Vergleich zu Instances der vorherigen Generation schnellere Inferenzen und eine schnellere Trainingsleistung ermöglicht. Diese Architektur ist besonders nützlich für Unternehmen, die mit Basismodellen mit Billionen Parametern arbeiten, da der vereinheitlichte GPU-Speicher es ermöglicht, dass ganze Modelle in einer einzigen NVLink Domäne verbleiben, wodurch knotenübergreifende Netzwerkengpässe vermieden werden. HyperPod verstärkt diesen Hardwarevorteil durch eine intelligente topologieorientierte Planung, die die Verteilung der Arbeitslast optimiert, durch automatischen Austausch von Instanzen zur Minimierung von Unterbrechungen und durch flexible Bereitstellungsoptionen, die sowohl Konfigurationen für dedizierte als auch gemeinsam genutzte Ressourcen unterstützen. Für Teams, die die Grenzen der Modellgröße und -leistung erweitern möchten, bietet diese Integration die erforderliche Rechenbasis, um die fortschrittlichsten KI-Modelle mit beispielloser Effizienz zu trainieren und einzusetzen.
SageMaker HyperPod optimiert automatisch die Instanzplatzierung in Ihrem. UltraServers HyperPod Priorisiert standardmäßig alle Instanzen in einer, UltraServer bevor eine andere verwendet wird. Wenn Sie beispielsweise 14 Instanzen haben möchten und 2 UltraServers in Ihrem Plan haben, verwendet SageMaker KI alle Instanzen der ersten Instanz. UltraServer Wenn Sie 20 Instanzen benötigen, verwendet SageMaker KI alle 18 Instanzen in der ersten Instanz UltraServer und dann 2 weitere Instanzen in der zweiten.
## AWS-Regionen unterstützt von SageMaker HyperPod
SageMaker HyperPod ist im Folgenden verfügbar AWS-Regionen.
+ us-east-1
+ us-east-2
+ us-west-1
+ us-west-2
+ eu-central-1
+ eu-north-1
+ eu-west-1
+ eu-west-2
+ eu-south-2
+ ap-south-1
+ ap-southeast-1
+ ap-southeast-2
+ ap-southeast-3
+ ap-southeast-4
+ ap-northeast-1
+ sa-east-1
**Topics**
+ [AWS-Regionen unterstützt von SageMaker HyperPod](#sagemaker-hyperpod-available-regions)
+ [SageMaker HyperPod Amazon-Schnellstart](sagemaker-hyperpod-quickstart.md)
+ [Voraussetzungen für die Verwendung SageMaker HyperPod](sagemaker-hyperpod-prerequisites.md)
+ [AWS Identity and Access Management für SageMaker HyperPod](sagemaker-hyperpod-prerequisites-iam.md)
+ [Vom Kunden verwaltete Verschlüsselung für AWS KMS key SageMaker HyperPod](smcluster-cmk.md)
+ [SageMaker HyperPod Rezepte](sagemaker-hyperpod-recipes.md)
+ [Orchestrierung von SageMaker HyperPod Clustern mit Slurm](sagemaker-hyperpod-slurm.md)
+ [Orchestrierung von SageMaker HyperPod Clustern mit Amazon EKS](sagemaker-hyperpod-eks.md)
+ [Verwendung von topologieorientierter Planung in Amazon SageMaker HyperPod](sagemaker-hyperpod-topology.md)
+ [Bereitstellen von Modellen auf Amazon SageMaker HyperPod](sagemaker-hyperpod-model-deployment.md)
+ [HyperPod im Studio](sagemaker-hyperpod-studio.md)
+ [SageMaker HyperPod Verweise](sagemaker-hyperpod-ref.md)
+ [SageMaker HyperPod Versionshinweise von Amazon](sagemaker-hyperpod-release-notes.md)
+ [SageMaker HyperPod Amazon-AMI](sagemaker-hyperpod-release-ami.md)
# SageMaker HyperPod Amazon-Schnellstart
Dieser Schnellstart führt Sie durch die Erstellung Ihres ersten HyperPod Clusters mit Slurm- und Amazon EKS (EKS) -Orchestrierungen. Wählen Sie zunächst die Orchestrierung, die am besten zu Ihren Infrastrukturanforderungen passt. SageMaker HyperPod
**Topics**
+ [Erstellen Sie einen SLURM-orchestrierten Cluster SageMaker HyperPod](#sagemaker-hyperpod-quickstart-slurm)
+ [Erstellen Sie einen EKS-orchestrierten Cluster SageMaker HyperPod](#sagemaker-hyperpod-quickstart-eks)
+ [Übermitteln von Workloads](#sagemaker-hyperpod-quickstart-workload)
## Erstellen Sie einen SLURM-orchestrierten Cluster SageMaker HyperPod
Folgen Sie diesen Schritten, um Ihren ersten SageMaker HyperPod Cluster mit Slurm-Orchestrierung zu erstellen.
1. Öffnen Sie die Amazon SageMaker AI-Konsole unter [https://console.aws.amazon.com/sagemaker/](https://console.aws.amazon.com/sagemaker/).
1. Wählen Sie im linken Navigationsbereich **HyperPod Clusters** und dann **Cluster Management** aus.
1. Wählen Sie auf der Seite **SageMaker HyperPod Cluster** die Option ** HyperPod Cluster erstellen** aus.
1. Wählen **Sie im Drop-down-Menü HyperPod Cluster erstellen** die Option **Orchestrated by Slurm aus**.
1. Wählen Sie auf der Seite zur Clustererstellung die Option **Quick Setup** aus. Mit dieser Option können Sie sofort mit den Standardeinstellungen beginnen. SageMaker KI erstellt bei der Erstellung Ihres Clusters neue Ressourcen wie VPC, Subnetze, Sicherheitsgruppen, Amazon S3 S3-Bucket, IAM-Rolle und FSx für Lustre.
1. Geben Sie unter **Allgemeine Einstellungen** einen Namen für den neuen Cluster an. Sie können den Namen nicht ändern, nachdem der Cluster erstellt wurde.
1. Wählen Sie unter **Instance-Gruppen** die Option **Gruppe hinzufügen** aus. Jede Instance-Gruppe kann anders konfiguriert werden und Sie können einen heterogenen Cluster erstellen, der aus mehreren Instance-Gruppen mit verschiedenen Instance-Typen besteht. Um einen Cluster bereitzustellen, müssen Sie mindestens eine Instance-Gruppe hinzufügen. Sie können jeweils eine Instance-Gruppe hinzufügen. Wenn Sie mehrere Instance-Gruppen erstellen möchten, wiederholen Sie den Vorgang für jede Instance-Gruppe.
Gehen Sie folgendermaßen vor, um eine Instance-Gruppe hinzuzufügen.
1. Wählen Sie unter **Instance-Gruppentyp** einen Typ für die Instance-Gruppe aus. Wählen Sie für diesen Schnellstart **Controller (Head)** für `my-controller-group`, **Login** für `my-login-group` und **Compute (Worker)** für `worker-group-1` aus.
1. Geben Sie unter **Name** einen Namen für die Instance-Gruppe an. Erstellen Sie für diesen Schnellstart drei Instance-Gruppen mit den Namen `my-controller-group`, `my-login-group` und `worker-group-1`.
1. Wählen Sie als **Instance-Kapazität** entweder On-Demand-Kapazität oder einen Trainingsplan aus, um Ihre Datenverarbeitungsressourcen zu reservieren.
1. Wählen Sie unter **Instance-Typ** die Instance für die Instance-Gruppe aus. Wählen Sie für diesen Schnellstart `ml.c5.xlarge` für `my-controller-group`, `ml.m5.4xlarge` für `my-login-group` und `ml.trn1.32xlarge` für `worker-group-1` aus.
Stellen Sie sicher, dass Sie den Instance-Typ mit ausreichenden Kontingenten in Ihrem Konto auswählen, oder fordern Sie zusätzliche Kontingente an, indem Sie den Anweisungen unter [SageMaker HyperPod Kontingente](sagemaker-hyperpod-prerequisites.md#sagemaker-hyperpod-prerequisites-quotas) folgen.
1. Geben Sie unter **Instance-Anzahl** eine Ganzzahl an, die das Instance-Kontingent für die Cluster-Nutzung nicht überschreitet. Geben Sie für diesen Schnellstart **1** für alle drei Gruppen ein.
1. Wählen Sie als **Ziel-Availability-Zone** die Availability Zone aus, in der Ihre Instances bereitgestellt werden. Die Availability Zone sollte dem Standort Ihrer beschleunigten Datenverarbeitungskapazität entsprechen.
1. Geben Sie unter **Zusätzliches Speichervolumen pro Instance (GB) – optional** eine Ganzzahl zwischen 1 und 16 384 an, um die Größe eines zusätzlichen Elastic Book Store (EBS)-Volume in Gigabyte (GB) festzulegen. Das EBS-Volume ist an jede Instance der Instance-Gruppe angefügt. Der Standard-Bereitstellungspfad für das zusätzliche EBS-Volume ist `/opt/sagemaker`. Nachdem der Cluster erfolgreich erstellt wurde, können Sie per SSH auf die Cluster-Instances (Knoten) zugreifen und überprüfen, ob das EBS-Volume korrekt gemountet wurde, indem Sie den `df -h`-Befehl ausführen. Durch das Anfügen eines zusätzlichen EBS-Volumes wird stabiler, Instance-unabhängiger persistenter Speicher bereitgestellt, wie im Abschnitt [Amazon-EBS-Volumes](https://docs.aws.amazon.com//ebs/latest/userguide/ebs-volumes.html) im *Benutzerhandbuch für Amazon Elastic Block Store* beschrieben.
1. Wählen Sie **Instance-Gruppe hinzufügen** aus.
1. Überprüfen Sie unter **Standardwerte für die Schnellkonfiguration** die Standardeinstellungen. In diesem Abschnitt sind alle Standardeinstellungen für Ihre Clustererstellung aufgeführt, einschließlich aller neuen AWS Ressourcen, die während der Clustererstellung erstellt werden.
1. Wählen Sie **Absenden** aus.
Weitere Informationen finden Sie unter [Erste Schritte mit der SageMaker HyperPod Verwendung der SageMaker KI-Konsole](smcluster-getting-started-slurm-console.md).
## Erstellen Sie einen EKS-orchestrierten Cluster SageMaker HyperPod
Gehen Sie wie folgt vor, um Ihren ersten SageMaker HyperPod Cluster mit Amazon EKS-Orchestrierung zu erstellen.
1. Öffnen Sie die Amazon SageMaker AI-Konsole unter [https://console.aws.amazon.com/sagemaker/](https://console.aws.amazon.com/sagemaker/).
1. Wählen Sie im linken Navigationsbereich **HyperPod Clusters** und dann **Cluster Management** aus.
1. Wählen Sie auf der Seite **SageMaker HyperPod Cluster** die Option ** HyperPod Cluster erstellen** aus.
1. Wählen **Sie im Drop-down-Menü HyperPod Cluster erstellen** die Option **Orchestrated by Amazon EKS** aus.
1. Wählen Sie auf der Seite zur Clustererstellung die Option **Schnellkonfiguration** aus. Mit dieser Option können Sie sofort mit den Standardeinstellungen beginnen. SageMaker KI erstellt bei der Erstellung Ihres Clusters neue Ressourcen wie VPC, Subnetze, Sicherheitsgruppen, Amazon S3 S3-Bucket, IAM-Rolle und FSx für Lustre.
1. Geben Sie unter **Allgemeine Einstellungen** einen Namen für den neuen Cluster an. Sie können den Namen nicht ändern, nachdem der Cluster erstellt wurde.
1. Wählen Sie unter **Instance-Gruppen** die Option **Gruppe hinzufügen** aus. Jede Instance-Gruppe kann anders konfiguriert werden und Sie können einen heterogenen Cluster erstellen, der aus mehreren Instance-Gruppen mit verschiedenen Instance-Typen besteht. Um einen Cluster bereitzustellen, müssen Sie mindestens eine Instance-Gruppe hinzufügen. Sie können jeweils eine Instance-Gruppe hinzufügen. Wenn Sie mehrere Instance-Gruppen erstellen möchten, wiederholen Sie den Vorgang für jede Instance-Gruppe.
Gehen Sie folgendermaßen vor, um eine Instance-Gruppe hinzuzufügen.
1. Wählen Sie als **Instance-Gruppentyp** **Standard** oder **Restricted Instance Group (RIG)** aus. Normalerweise wählen Sie **Standard**, denn es bietet eine allgemeine Datenverarbeitungsumgebung ohne zusätzliche Sicherheitseinschränkungen. **Restricted Instance Group (RIG)** ist eine spezialisierte Umgebung für die Anpassung von Grundlagenmodellen wie Amazon Nova. Weitere Informationen zur Einrichtung von RIG für die Amazon Nova-Modellanpassung finden Sie unter Amazon Nova-Anpassung SageMaker HyperPod im [Amazon Nova 1.0-Benutzerhandbuch](https://docs.aws.amazon.com//nova/latest/userguide/nova-hp.html) oder im [Amazon Nova 2.0-Benutzerhandbuch](https://docs.aws.amazon.com//nova/latest/nova2-userguide/nova-hp.html).
1. Geben Sie unter **Name** einen Namen für die Instance-Gruppe an.
1. Wählen Sie als **Instance-Kapazität** entweder On-Demand-Kapazität oder einen Trainingsplan aus, um Ihre Datenverarbeitungsressourcen zu reservieren.
1. Wählen Sie unter **Instance-Typ** die Instance für die Instance-Gruppe aus. Stellen Sie sicher, dass Sie den Instance-Typ mit ausreichenden Kontingenten in Ihrem Konto auswählen, oder fordern Sie zusätzliche Kontingente an, indem Sie den Anweisungen unter [SageMaker HyperPod Kontingente](sagemaker-hyperpod-prerequisites.md#sagemaker-hyperpod-prerequisites-quotas) folgen.
1. Geben Sie unter **Instance-Anzahl** eine Ganzzahl an, die das Instance-Kontingent für die Cluster-Nutzung nicht überschreitet. Geben Sie für diesen Schnellstart **1** für alle drei Gruppen ein.
1. Wählen Sie als **Ziel-Availability-Zone** die Availability Zone aus, in der Ihre Instances bereitgestellt werden. Die Availability Zone sollte dem Standort Ihrer beschleunigten Datenverarbeitungskapazität entsprechen.
1. Geben Sie unter **Zusätzliches Speichervolumen pro Instance (GB) – optional** eine Ganzzahl zwischen 1 und 16 384 an, um die Größe eines zusätzlichen Elastic Book Store (EBS)-Volume in Gigabyte (GB) festzulegen. Das EBS-Volume ist an jede Instance der Instance-Gruppe angefügt. Der Standard-Bereitstellungspfad für das zusätzliche EBS-Volume ist `/opt/sagemaker`. Nachdem der Cluster erfolgreich erstellt wurde, können Sie per SSH auf die Cluster-Instances (Knoten) zugreifen und überprüfen, ob das EBS-Volume korrekt gemountet wurde, indem Sie den `df -h`-Befehl ausführen. Durch das Anfügen eines zusätzlichen EBS-Volumes wird stabiler, Instance-unabhängiger persistenter Speicher bereitgestellt, wie im Abschnitt [Amazon-EBS-Volumes](https://docs.aws.amazon.com//ebs/latest/userguide/ebs-volumes.html) im *Benutzerhandbuch für Amazon Elastic Block Store* beschrieben.
1. Wählen Sie unter **Detaillierte Instance-Zustandsprüfungen** die gewünschte Option aus. Detaillierte Zustandsprüfungen überwachen den Zustand der Instances während der Erstellung und nach Softwareupdates und stellen fehlerhafte Instances automatisch durch Neustarts oder Austausch, sofern aktiviert, wieder her.
1. Wählen Sie **Instance-Gruppe hinzufügen** aus.
1. Überprüfen Sie unter **Standardwerte für die Schnellkonfiguration** die Standardeinstellungen. In diesem Abschnitt sind alle Standardeinstellungen für Ihre Clustererstellung aufgeführt, einschließlich aller neuen AWS Ressourcen, die während der Clustererstellung erstellt werden.
1. Wählen Sie **Absenden** aus.
Weitere Informationen finden Sie unter [Erstellen eines SageMaker HyperPod Clusters mit Amazon EKS-Orchestrierung](sagemaker-hyperpod-eks-operate-console-ui-create-cluster.md).
## Übermitteln von Workloads
Folgen Sie diesen Workshop-Tutorials, um Beispiel-Workloads zu übermitteln.
+ [Amazon SageMaker HyperPod für Slurm](https://catalog.workshops.aws/sagemaker-hyperpod/en-US)
+ [Amazon SageMaker HyperPod für Amazon EKS](https://catalog.workshops.aws/sagemaker-hyperpod-eks/en-US)
# Voraussetzungen für die Verwendung SageMaker HyperPod
In den folgenden Abschnitten werden die Voraussetzungen beschrieben, bevor Sie damit beginnen SageMaker HyperPod.
**Topics**
+ [SageMaker HyperPod Kontingente](#sagemaker-hyperpod-prerequisites-quotas)
+ [Einrichtung SageMaker HyperPod mit einer benutzerdefinierten Amazon VPC](#sagemaker-hyperpod-prerequisites-optional-vpc)
+ [Einrichtung von Clustern über mehrere SageMaker HyperPod AZs](#sagemaker-hyperpod-prerequisites-multiple-availability-zones)
+ [Einrichtung AWS Systems Manager und Ausführung als für die Cluster-Benutzerzugriffskontrolle](#sagemaker-hyperpod-prerequisites-ssm)
+ [(Optional) Einrichtung SageMaker HyperPod mit Amazon FSx for Lustre](#sagemaker-hyperpod-prerequisites-optional-fsx)
## SageMaker HyperPod Kontingente
Sie können SageMaker HyperPod Cluster erstellen, wenn Sie die Kontingente für die *Clusternutzung* in Ihrem AWS Konto berücksichtigen.
**Wichtig**
Weitere Informationen zur SageMaker HyperPod Preisgestaltung finden Sie unter [SageMaker HyperPod Preisgestaltung](sagemaker-hyperpod-ref.md#sagemaker-hyperpod-ref-pricing) und unter [ SageMaker Amazon-Preise](https://aws.amazon.com/sagemaker/pricing/).
### SageMaker HyperPod Amazon-Kontingente anzeigen mit dem AWS-Managementkonsole
Suchen Sie nach den Standardwerten und den angewendeten Werten eines *Kontingents*, das auch als *Limit* bezeichnet wird, für die *Cluster-Nutzung* SageMaker HyperPod.
1. Öffnen Sie die [Service Quotas -Konsole](https://console.aws.amazon.com/servicequotas/).
1. Wählen Sie im linken Navigationsbereich **AWS services** aus.
1. Suchen Sie in der **AWS Serviceliste** nach **Amazon SageMaker AI** und wählen Sie es aus.
1. In der Liste der **Servicekontingente** finden Sie den Namen des Servicekontingents, den angewendeten Wert (falls verfügbar), das AWS Standardkontingent und ob der Kontingentwert anpassbar ist.
1. Geben Sie in die Suchleiste **Cluster-Nutzung** ein. Hier werden die Kontingente für die Cluster-Nutzung, die angewendeten Kontingente und die Standardkontingente angezeigt.
**Liste gängiger Servicekontingenten für die Erstellung eines HyperPod Clusters und der zugehörigen Voraussetzungen**
Möglicherweise möchten Sie in der AI-Konsole überprüfen, ob Sie für die folgenden Kontingente eine Erhöhung der Servicekontingenten beantragt haben, um einen neuen HyperPod Cluster zusammen mit den Voraussetzungen zu erstellen. SageMaker Navigieren Sie zur **Service Quota-Konsole** und suchen Sie nach den folgenden Begriffen.
****
| Nein | Name des Kontingents | Suchbegriff | Description |
| --- | --- | --- | --- |
| 1 | Maximal zulässige Anzahl von Instanzen pro SageMaker HyperPod Cluster | Suchen Sie unter SageMaker KI nach „Maximale Anzahl erlaubter Instanzen pro SageMaker HyperPod Cluster“ | Ihr Kontingentwert auf Kontoebene muss höher sein als die Anzahl der Instanzen, die Sie Ihrem Cluster hinzufügen möchten |
| 2 | Maximale Größe des EBS-Volumes in GB für eine Cluster-Instance SageMaker HyperPod | Suchen Sie unter SageMaker KI nach „Maximale Größe des EBS-Volumes in GB für eine HyperPod Cluster-Instance“ | Ihr Kontingentwert auf Kontoebene muss höher sein als das EBS-Volume, das Sie Ihrem Cluster hinzufügen möchten |
| 3 | Gesamtzahl der in Clustern zulässigen Instances SageMaker HyperPod | Suchen Sie unter SageMaker KI nach „Gesamtzahl der in SageMaker HyperPod Clustern zulässigen Instanzen“ | Ihr Kontingentwert auf Kontoebene muss höher sein als die Gesamtzahl der Instances, die Sie für alle Ihre Cluster in Ihrem Konto insgesamt hinzufügen möchten |
| 4 | Instanzkontingente | Suchen Sie unter SageMaker KI nach „ml. „für Cluster-Nutzung“, z. B.: ml.p5.48xlarge für Cluster-Nutzung | Ihr Kontingentwert auf Kontoebene für den jeweiligen Instance-Typ (z. B.: ml.p5.48xlarge) muss größer sein als die Anzahl der Instances, die Sie für alle Ihre Cluster in Ihrem Konto insgesamt hinzufügen möchten. |
| 5 | VPCs pro Region | Suchen Sie unter Amazon Virtual Private Cloud (Amazon VPC) nach „VPCspro Region“ | Ihr Kontingentwert auf Kontoebene muss ausreichen, um bei der Einrichtung Ihres Clusters eine neue VPC im Konto zu erstellen. HyperPod Überprüfen Sie in der VPC-Konsole, ob Sie dieses Kontingentlimit bereits ausgeschöpft haben. Diese Erhöhung des Kontingents ist nur erforderlich, wenn Sie über die Cluster-Setup-Option „Schnell“ oder „Benutzerdefiniert“ in der SageMaker HyperPod Konsole eine neue VPC erstellen. |
| 6 | Internet-Gateways pro Region | Suchen Sie unter Amazon Virtual Private Cloud (Amazon VPC) nach „Internet-Gateways pro Region“ | Ihr Kontingentwert auf Kontoebene muss ausreichen, um bei der Einrichtung Ihres Clusters ein zusätzliches Internet-Gateway im Konto einzurichten. SageMaker HyperPod Diese Erhöhung des Kontingents ist nur erforderlich, wenn Sie über die Cluster-Setup-Option „Schnell“ oder „Benutzerdefiniert“ in der SageMaker HyperPod Konsole eine neue VPC erstellen. |
| 7 | Netzwerkschnittstellen pro Region | Suchen Sie unter Amazon Virtual Private Cloud (Amazon VPC) nach „Netzwerkschnittstellen pro Region“ | Ihr Kontingentwert auf Kontoebene muss bei der Einrichtung Ihres Clusters über genügend Netzwerkschnittstellen verfügen. HyperPod |
| 8 | EC2-VPC Elastisch IPs | Suchen Sie unter Amazon Elastic Compute Cloud (Amazon EC2) nach „EC2-VPC Elastic“ IPs | Ihr Kontingentwert auf Kontoebene muss ausreichen, um bei der Einrichtung Ihres Clusters eine neue VPC im Konto zu erstellen. HyperPod Überprüfen Sie in der VPC-Konsole, ob Sie dieses Kontingentlimit bereits ausgeschöpft haben. Diese Erhöhung des Kontingents ist nur erforderlich, wenn Sie über die Cluster-Setup-Option „Schnell“ oder „Benutzerdefiniert“ in der SageMaker HyperPod Konsole eine neue VPC erstellen. |
### Beantragen Sie eine Erhöhung des SageMaker HyperPod Amazon-Kontingents mit dem AWS-Managementkonsole
Erhöhen Sie Ihre Kontingente auf Konto- oder Ressourcenebene.
1. Um das Kontingent der Instances für die *Cluster-Nutzung* zu erhöhen, wählen Sie das Kontingent aus, das Sie erhöhen möchten.
1. Wenn das Kontingent anpassbar ist, können Sie eine Erhöhung des Kontingents entweder auf Konto- oder Ressourcenebene beantragen, basierend auf dem Wert, der in der Spalte **Anpassbarkeit** aufgeführt ist.
1. Geben Sie unter **Kontingentwert erhöhen** den neuen Wert ein. Der neue Wert muss größer als der aktuelle Wert sein.
1. Wählen Sie **Anfrage** aus.
1. Um ausstehende oder kürzlich gelöste Anfragen in der Konsole anzuzeigen, navigieren Sie auf der Detailseite des Services zur Registerkarte **Anfrageverlauf** oder wählen Sie im Navigationsbereich **Dashboard** aus. Wählen Sie für ausstehende Anfragen den Status der Anfrage, um die Anfrage zu öffnen. Der Anfangsstatus einer Anfrage ist **Pending** (Ausstehend). Nachdem sich der Status in „**Kontingent angefordert**“ geändert hat, sehen Sie die Fallnummer mit AWS Support. Wählen Sie die Fallnummer, um das Ticket für Ihre Anfrage zu öffnen.
Weitere Informationen zur Anforderung einer Erhöhung eines Kontingents finden Sie unter [Beantragen einer Kontingenterhöhung](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html) im *Benutzerhandbuch zu AWS -Service-Quotas*.
## Einrichtung SageMaker HyperPod mit einer benutzerdefinierten Amazon VPC
Um einen SageMaker HyperPod Cluster mit einer benutzerdefinierten Amazon VPC einzurichten, überprüfen Sie die folgenden Voraussetzungen.
**Anmerkung**
Die VPC-Konfiguration ist für die Amazon-EKS-Orchestrierung obligatorisch. Für die Slurm-Orchestrierung ist die VPC-Einrichtung optional.
+ Überprüfen Sie die [Elastic Network Interface](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html) (ENI) -Kapazität in Ihrem, AWS-Konto bevor Sie einen SageMaker HyperPod Cluster mit einer benutzerdefinierten VPC erstellen. Das ENI-Limit wird von Amazon EC2 gesteuert und variiert je nach AWS-Region. SageMaker HyperPod kann nicht automatisch Quotenerhöhungen beantragen.
**So überprüfen Sie Ihr aktuelles ENI-Kontingent:**
1. Öffnen Sie die [Service Quotas -Konsole](https://console.aws.amazon.com/servicequotas/).
1. Verwenden **Sie im Abschnitt Kontingente verwalten** die Dropdownliste ** AWS Dienste**, um nach **VPC** zu suchen.
1. Wählen Sie die Option zum Anzeigen der Kontingente von **Amazon Virtual Private Cloud (Amazon VPC)**.
1. Suchen Sie nach dem Service Quota, den **Netzwerkschnittstellen pro Region** oder dem **Kontingentcode** `L-DF5E4CA3`.
Wenn Ihr derzeitiges ENI-Limit für Ihre SageMaker HyperPod Cluster-Anforderungen nicht ausreicht, fordern Sie eine Erhöhung des Kontingents an. Wenn Sie im Voraus eine ausreichende ENI-Kapazität sicherstellen, können Sie Ausfälle bei der Cluster-Bereitstellung vermeiden.
+ Wenn Sie eine benutzerdefinierte VPC verwenden, um einen SageMaker HyperPod Cluster mit AWS Ressourcen zu verbinden, geben Sie IDs bei der Clustererstellung den VPC-Namen, die ID AWS-Region, das Subnetz IDs und die Sicherheitsgruppe an.
**Anmerkung**
Wenn Ihre Amazon VPC und Subnetze auf Cluster- oder Instance-Gruppenebene mithilfe [https://docs.aws.amazon.com//sagemaker/latest/APIReference/API_CreateCluster.html#sagemaker-CreateCluster-request-VpcConfig](https://docs.aws.amazon.com//sagemaker/latest/APIReference/API_CreateCluster.html#sagemaker-CreateCluster-request-VpcConfig)des `OverrideVPCConfig` Attributs von unterstützen IPv6 [https://docs.aws.amazon.com//sagemaker/latest/APIReference/API_ClusterInstanceGroupSpecification.html](https://docs.aws.amazon.com//sagemaker/latest/APIReference/API_ClusterInstanceGroupSpecification.html), unterscheidet sich die Netzwerkkommunikation je nach Cluster-Orchestrierungsplattform:
Slurm-orchestrierte Cluster konfigurieren automatisch Knoten mit dualen Adressen IPv6 und IPv4 ermöglichen so eine sofortige Netzwerkkommunikation. IPv6 Neben den Einstellungen ist keine zusätzliche Konfiguration erforderlich. `VPCConfig` IPv6
In EKS-orchestrierten Clustern erhalten Knoten eine Dual-Stack-Adressierung, aber Pods können nur verwendet werden, IPv6 wenn der Amazon EKS-Cluster explizit aktiviert ist. IPv6 Sie müssen einen neuen IPv6 Amazon EKS-Cluster erstellen. Bestehende IPv4 Amazon EKS-Cluster können nicht konvertiert werden IPv6. Informationen zur Bereitstellung eines IPv6 Amazon EKS-Clusters finden Sie unter [Amazon EKS IPv6 Cluster-Bereitstellung](https://docs.aws.amazon.com/eks/latest/userguide/deploy-ipv6-cluster.html#_deploy_an_ipv6_cluster_with_eksctl).
Zusätzliche Ressourcen für die IPv6 Konfiguration:
Informationen zum Hinzufügen von IPv6 Unterstützung zu Ihrer VPC finden Sie unter [IPv6 Support für VPC](https://docs.aws.amazon.com//vpc/latest/userguide/vpc-migrate-ipv6.html).
Informationen zum Erstellen einer neuen IPv6 -kompatiblen VPC finden Sie im [Amazon VPC Creation](https://docs.aws.amazon.com//vpc/latest/userguide/create-vpc.html) Guide.
Informationen zur Konfiguration SageMaker HyperPod mit einer benutzerdefinierten Amazon VPC finden Sie unter [Benutzerdefiniertes Amazon VPC-Setup für](https://docs.aws.amazon.com//sagemaker/latest/dg/sagemaker-hyperpod-prerequisites.html#sagemaker-hyperpod-prerequisites-optional-vpc). SageMaker HyperPod
+ Stellen Sie sicher, dass alle Ressourcen im gleichen AWS-Region Cluster bereitgestellt werden. SageMaker HyperPod Konfigurieren Sie Sicherheitsgruppenregeln, um die Kommunikation zwischen Ressourcen innerhalb der VPC zu ermöglichen, wenn Sie beispielsweise eine VPC in `us-west-2` erstellen, Subnetze in einer oder mehreren Availability Zones (z.B. `us-west-2a` oder`us-west-2b`) bereitstellen und eine Sicherheitsgruppe erstellen, die gruppeninternen Datenverkehr ermöglicht.
**Anmerkung**
SageMaker HyperPod unterstützt die Bereitstellung in mehreren Verfügbarkeitszonen. Weitere Informationen finden Sie unter [Einrichtung von Clustern über mehrere SageMaker HyperPod AZs](#sagemaker-hyperpod-prerequisites-multiple-availability-zones).
+ Stellen Sie Amazon Simple Storage Service (Amazon S3) Konnektivität für von VPC bereitgestellte SageMaker HyperPod Instanzgruppen her, indem Sie einen VPC-Endpunkt erstellen. Ohne Internetzugang können Instance-Gruppen keine Lebenszyklusskripte, Trainingsdaten oder Modellartefakte speichern oder abrufen. Wir empfehlen Ihnen, eine benutzerdefinierte IAM-Richtlinie zu erstellen, die den Zugriff des Amazon-S3-Buckets auf die private VPC einschränkt. Weitere Informationen finden Sie unter [Endpunkte für Amazon S3](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-endpoints-s3.html) im *AWS PrivateLink -Benutzerhandbuch*.
+ Für HyperPod Cluster, die Elastic Fabric Adapter (EFA) -fähige Instances verwenden, konfigurieren Sie die Sicherheitsgruppe so, dass der gesamte ein- und ausgehende Datenverkehr zur und von der Sicherheitsgruppe selbst zugelassen wird. Vermeiden Sie insbesondere die Verwendung von `0.0.0.0/0` für ausgehende Regeln, da dies dazu führen kann, dass die EFA-Zustandsprüfung fehlschlägt. Weitere Informationen zu den Richtlinien zur Vorbereitung von EFA-Sicherheitsgruppen finden Sie unter [Schritt 1: Vorbereiten einer EFA-fähigen Sicherheitsgruppe](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa-start.html#efa-start-security) im *Benutzerhandbuch für Amazon EC2*.
+ Überlegen Sie sich vor der Erstellung von Clustern sorgfältig die Blockgröße Ihres Subnetzes mit Classless Inter-Domain Routing (CIDR). HyperPod
+ Die Größe des CIDR-Blocks des Subnetzes kann nach der Erstellung nicht mehr geändert werden. Dies ist besonders wichtig, wenn Sie große beschleunigte Instances wie P5 verwenden. Ohne ausreichende Blockgröße müssen Sie Ihre Cluster bei der Skalierung neu erstellen.
+ Berücksichtigen Sie bei der Auswahl der geeigneten CIDR-Blockgröße für das Subnetz folgende Faktoren: Ihre Instance-Typen, die erwartete Anzahl von Instances und die Anzahl der von jeder Instance belegten IP-Adressen.
+ Bei SLURM-orchestrierten Clustern kann jede P5-Instance 32 IP-Adressen (eine pro Netzwerkkarte) erstellen. Bei EKS-orchestrierten Clustern kann jede P5-Instance 81 IP-Adressen erstellen (50 von der primären Karte plus eine von jeder der verbleibenden 31 Karten). Detaillierte Spezifikationen finden Sie unter [Netzwerkspezifikationen](https://docs.aws.amazon.com/ec2/latest/instancetypes/ac.html#ac_network) im *Entwicklerhandbuch für Instance-Typen von Amazon EC2*.
+ [Beispiele für CloudFormation Vorlagen, die die CIDR-Blockgröße des Subnetzes angeben, finden Sie in der [HyperPod Slurm-Vorlage](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/sagemaker-hyperpod.yaml) und der [HyperPod Amazon EKS-Vorlage im Repository](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/7.sagemaker-hyperpod-eks/cfn-templates/nested-stacks/private-subnet-stack.yaml). awsome-distributed-training ](https://github.com/aws-samples/awsome-distributed-training/tree/main)
## Einrichtung von Clustern über mehrere SageMaker HyperPod AZs
Sie können Ihre SageMaker HyperPod Cluster für mehrere Availability Zones (AZs) konfigurieren, um die Zuverlässigkeit und Verfügbarkeit zu verbessern.
**Anmerkung**
Elastic Fabric Adapter (EFA) -Datenverkehr kann AZs oder VPCs nicht überqueren. Dies gilt nicht für normalen IP-Verkehr vom ENA-Gerät einer EFA-Schnittstelle. Weitere Informationen finden Sie unter [EFA-Einschränkungen](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa.html).
+ **Standardverhalten**
HyperPod stellt alle Cluster-Instances in einer einzigen Availability Zone bereit. Die VPC-Konfiguration bestimmt die Bereitstellungs-AZ:
+ Für SLURM-orchestrierte Cluster ist die VPC-Konfiguration optional. Wenn keine VPC-Konfiguration bereitgestellt wird, wird HyperPod standardmäßig ein Subnetz von der Plattform-VPC verwendet.
+ Für EKS-orchestrierte Cluster ist die VPC-Konfiguration erforderlich.
+ Sowohl für Slurm- als auch für EKS-Orchestratoren [https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_VpcConfig.html](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_VpcConfig.html)wird, sofern angegeben, ein Subnetz aus der Subnetzliste des Anbieters HyperPod ausgewählt. `VpcConfig` Alle Instance-Gruppen erben die AZ des Subnetzes.
**Anmerkung**
Sobald Sie einen Cluster erstellt haben, können Sie seine `VpcConfig`-Einstellungen nicht mehr ändern.
Weitere Informationen VPCs zur Konfiguration von HyperPod Clustern finden Sie im vorherigen Abschnitt,. [Einrichtung SageMaker HyperPod mit einer benutzerdefinierten Amazon VPC](#sagemaker-hyperpod-prerequisites-optional-vpc)
+ ** Multi-AZ-Konfiguration **
Sie können Ihren HyperPod Cluster für mehrere einrichten, AZs wenn Sie einen Cluster erstellen oder wenn Sie einem vorhandenen Cluster eine neue Instanzgruppe hinzufügen. Um Multi-AZ-Bereitstellungen zu konfigurieren, können Sie die VPC-Standardeinstellungen des Clusters überschreiben, indem Sie für einzelne Instance-Gruppen innerhalb Ihres Clusters unterschiedliche Subnetze und Sicherheitsgruppen angeben, möglicherweise über verschiedene Availability Zones hinweg.
SageMaker HyperPod API-Benutzer können die `OverrideVpcConfig` Eigenschaft innerhalb von verwenden [ClusterInstanceGroupSpecification](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_ClusterInstanceGroupSpecification.html), wenn sie mit dem [https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_CreateCluster.html](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_CreateCluster.html)oder arbeiten [https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_UpdateCluster.html](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_UpdateCluster.html) APIs.
Das Feld `OverrideVpcConfig`:
+ Kann nicht geändert werden, nachdem die Instance-Gruppe erstellt wurde.
+ ist optional. Wenn nicht anders angegeben, wird standardmäßig die Cluster-Ebene [https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_VpcConfig.html](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_VpcConfig.html) verwendet.
+ Kann für Slurm-orchestrierte Cluster nur angegeben werden, wenn die Clusterebene `VpcConfig` angegeben ist. Wenn auf Clusterebene `VpcConfig` angegeben ist, kann `OverrideVpcConfig` für keine Instance-Gruppe verwendet werden.
+ Enthält zwei Pflichtfelder:
+ `Subnets`- akzeptiert zwischen 1 und 16 Subnetze IDs
+ `SecurityGroupIds`- akzeptiert zwischen 1 und 5 Sicherheitsgruppen IDs
Weitere Informationen zum Erstellen oder Aktualisieren eines SageMaker HyperPod Clusters über die Benutzeroberfläche der SageMaker HyperPod Konsole oder über AWS CLI:
+ Slurm-Orchestrierung: Siehe [Betrieb von HyperPod Slurm-orchestrierten](sagemaker-hyperpod-operate-slurm.md) Clustern.
+ EKS-Orchestrierung. [ HyperPodSiehe Betrieb von EKS-orchestrierten](sagemaker-hyperpod-eks-operate.md) Clustern.
**Anmerkung**
Wenn Sie Workloads über mehrere ausführen, sollten Sie sich bewusst sein AZs, dass die Netzwerkkommunikation zwischen AZs diesen zu zusätzlicher Latenz führt. Berücksichtigen Sie diese Auswirkungen bei der Entwicklung latenzempfindlicher Anwendungen.
## Einrichtung AWS Systems Manager und Ausführung als für die Cluster-Benutzerzugriffskontrolle
[SageMaker HyperPod DLAMI](sagemaker-hyperpod-ref.md#sagemaker-hyperpod-ref-hyperpod-ami)ist standardmäßig mit [AWS Systems Manager](https://aws.amazon.com/systems-manager/)(SSM) ausgestattet, um Ihnen bei der Verwaltung des Zugriffs auf Ihre SageMaker HyperPod Cluster-Instanzgruppen zu helfen. In diesem Abschnitt wird beschrieben, wie Sie Betriebssystembenutzer (OS) in Ihren SageMaker HyperPod Clustern erstellen und sie IAM-Benutzern und -Rollen zuordnen. Dies ist nützlich, um SSM-Sitzungen mithilfe der Anmeldeinformationen des Betriebssystem-Benutzerkontos zu authentifizieren.
**Anmerkung**
Wenn Sie Benutzern Zugriff auf HyperPod Clusterknoten gewähren, können sie benutzerverwaltete Software auf den Knoten installieren und ausführen. Stellen Sie sicher, dass Sie das Prinzip der geringsten Berechtigung für Benutzer beibehalten.
### Aktivieren Sie Run As in Ihrem Konto AWS
Als AWS Kontoadministrator oder Cloud-Administrator können Sie den Zugriff auf SageMaker HyperPod Cluster auf IAM-Rollen- oder Benutzerebene verwalten, indem Sie die [Funktion „Ausführen als“ in SSM](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-preferences-run-as.html) verwenden. Mit diesem Feature können Sie jede SSM-Sitzung mit dem Betriebssystembenutzer starten, der der IAM-Rolle oder dem IAM-Benutzer zugeordnet ist.
Um Run As in Ihrem AWS Konto zu aktivieren, folgen Sie den Schritten [unter Run As-Unterstützung für verwaltete Linux- und macOS-Nodes](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-preferences-run-as.html) aktivieren. Wenn Sie bereits Betriebssystembenutzer in Ihrem Cluster erstellt haben, stellen Sie sicher, dass Sie sie IAM-Rollen oder -Benutzern zuordnen, indem Sie sie wie in **Option 2** von Schritt 5 unter **So aktivieren Sie die Unterstützung von „Ausführen als“ für verwaltete Linux- und macOS-Knoten** beschrieben markieren.
## (Optional) Einrichtung SageMaker HyperPod mit Amazon FSx for Lustre
Um mit der Verwendung SageMaker HyperPod und Zuordnung von Datenpfaden zwischen dem Cluster und Ihrem FSx for Lustre-Dateisystem zu beginnen, wählen Sie einen der AWS-Regionen unterstützten von. SageMaker HyperPod Nachdem AWS-Region Sie die von Ihnen bevorzugte ausgewählt haben, sollten Sie auch festlegen, welche Availability Zone (AZ) Sie verwenden möchten.
Wenn Sie SageMaker HyperPod Rechenknoten an einem AZs anderen Ort als AZs dem verwenden, an dem Ihr FSx for Lustre-Dateisystem eingerichtet ist AWS-Region, kann es zu Kommunikations- und Netzwerkaufwand kommen. Wir empfehlen Ihnen, dieselbe physische AZ wie die für das SageMaker HyperPod Dienstkonto zu verwenden, um AZ-übergreifenden Verkehr zwischen SageMaker HyperPod Clustern und Ihrem FSx for Lustre-Dateisystem zu vermeiden. Stellen Sie außerdem sicher, dass Sie es mit Ihrer VPC konfiguriert haben. Wenn Sie Amazon FSx als Hauptdateisystem für die Speicherung verwenden möchten, müssen Sie SageMaker HyperPod Cluster mit Ihrer VPC konfigurieren.
# AWS Identity and Access Management für SageMaker HyperPod
AWS Identity and Access Management (IAM) ist ein AWS Dienst, der einem Administrator hilft, den Zugriff auf Ressourcen sicher zu AWS kontrollieren. IAM-Administratoren kontrollieren, wer *authentifiziert* (angemeldet) und *autorisiert* (mit Berechtigungen ausgestattet) werden kann, um Amazon-EKS-Ressourcen zu nutzen. IAM ist ein AWS Dienst, den Sie ohne zusätzliche Kosten nutzen können.
**Wichtig**
Benutzerdefinierte IAM-Richtlinien, die es Amazon SageMaker Studio oder Amazon SageMaker Studio Classic ermöglichen, SageMaker Amazon-Ressourcen zu erstellen, müssen auch Berechtigungen zum Hinzufügen von Tags zu diesen Ressourcen gewähren. Die Berechtigung zum Hinzufügen von Tags zu Ressourcen ist erforderlich, da Studio und Studio Classic automatisch alle von ihnen erstellten Ressourcen taggen. Wenn eine IAM-Richtlinie Studio und Studio Classic das Erstellen von Ressourcen, aber kein Tagging erlaubt, können "AccessDenied" Fehler beim Versuch, Ressourcen zu erstellen, auftreten. Weitere Informationen finden Sie unter [Erteilen Sie Berechtigungen für das Taggen von SageMaker KI-Ressourcen](security_iam_id-based-policy-examples.md#grant-tagging-permissions).
[AWS verwaltete Richtlinien für Amazon SageMaker AI](security-iam-awsmanpol.md)die Berechtigungen zum Erstellen von SageMaker Ressourcen gewähren, beinhalten bereits Berechtigungen zum Hinzufügen von Tags beim Erstellen dieser Ressourcen.
Nehmen wir an, dass es zwei SageMaker HyperPod Hauptnutzerschichten gibt: *Cluster-Admin-Benutzer* und *Data-Scientist-Benutzer*.
+ **Cluster-Admin-Benutzer** — Sind für die Erstellung und Verwaltung von SageMaker HyperPod Clustern verantwortlich. Dazu gehören die Konfiguration der HyperPod Cluster und die Verwaltung des Benutzerzugriffs auf sie.
+ Erstellen und konfigurieren Sie SageMaker HyperPod Cluster mit Slurm oder Amazon EKS.
+ Erstellen und konfigurieren Sie IAM-Rollen für Data-Scientist-Benutzer und HyperPod Cluster-Ressourcen.
+ Für die SageMaker HyperPod Orchestrierung mit Amazon EKS müssen Sie [EKS-Zugriffseinträge](https://docs.aws.amazon.com/eks/latest/userguide/access-entries.html), [rollenbasierte Zugriffskontrolle (RBAC)](sagemaker-hyperpod-eks-setup-rbac.md) und Pod Identity erstellen und konfigurieren, um datenwissenschaftliche Anwendungsfälle zu erfüllen.
+ **Datenwissenschaftsbenutzer** – Konzentration auf das Training von ML-Modellen. Sie verwenden den Open-Source-Orchestrator oder die SageMaker HyperPod CLI, um Schulungsjobs einzureichen und zu verwalten.
+ Nehmen Sie die von Cluster-Admin-Benutzern bereitgestellte IAM-Rolle an und verwenden Sie sie.
+ Interagieren Sie mit dem Open-Source-Orchestrator, der von SageMaker HyperPod (Slurm oder Kubernetes) oder der SageMaker HyperPod CLI CLIs unterstützt wird, um die Clusterkapazität zu überprüfen, eine Verbindung zum Cluster herzustellen und Workloads einzureichen.
Richten Sie IAM-Rollen für Cluster-Administratoren ein, indem Sie die richtigen Berechtigungen oder Richtlinien für den Betrieb von Clustern hinzufügen. SageMaker HyperPod Cluster-Administratoren sollten außerdem IAM-Rollen einrichten, um SageMaker HyperPod Ressourcen bereitzustellen, die für den Betrieb und die Kommunikation mit den erforderlichen AWS Ressourcen wie Amazon S3 CloudWatch, Amazon und AWS Systems Manager (SSM) zuständig sind. Schließlich sollten der AWS Kontoadministrator oder die Cluster-Administratoren Wissenschaftlern Berechtigungen für den Zugriff auf die SageMaker HyperPod Cluster und die Ausführung von ML-Workloads gewähren.
Je nachdem, welchen Orchestrator Sie auswählen, können die für den Cluster-Administrator und die Wissenschaftler erforderlichen Berechtigungen variieren. Sie können auch den Umfang der Berechtigungen für verschiedene Aktionen in den Rollen mithilfe der Bedingungsschlüssel pro Service steuern. Verwenden Sie die folgenden Referenzen zur Serviceautorisierung, um den detaillierten Umfang der Dienste im Zusammenhang mit hinzuzufügen. SageMaker HyperPod
+ [Amazon Elastic Compute Cloud](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonec2.html)
+ [Amazon Elastic Container Registry](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelasticcontainerregistry.html) (für SageMaker HyperPod Cluster-Orchestrierung mit Amazon EKS)
+ [Amazon Elastic Kubernetes Service](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html) (für SageMaker HyperPod Cluster-Orchestrierung mit Amazon EKS)
+ [Amazon FSx](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonfsx.html)
+ [AWS IAM Identity Center (Nachfolger von Single Sign-On) AWS](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsiamidentitycentersuccessortoawssinglesign-on.html)
+ [AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsidentityandaccessmanagementiam.html)
+ [Amazon Simple Storage Service](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazons3.html)
+ [Amazon SageMaker KI](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonsagemaker.html)
+ [AWS Systems Manager](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awssystemsmanager.html)
**Topics**
+ [IAM-Berechtigungen für die Clustererstellung](#sagemaker-hyperpod-prerequisites-iam-cluster-creation)
+ [IAM-Benutzer für den Clusteradministrator](#sagemaker-hyperpod-prerequisites-iam-cluster-admin)
+ [IAM-Benutzer für Wissenschaftler](#sagemaker-hyperpod-prerequisites-iam-cluster-user)
+ [IAM-Rolle für SageMaker HyperPod](#sagemaker-hyperpod-prerequisites-iam-role-for-hyperpod)
## IAM-Berechtigungen für die Clustererstellung
Für die Erstellung von HyperPod Clustern sind die im folgenden Richtlinienbeispiel beschriebenen IAM-Berechtigungen erforderlich. Wenn Sie AWS-Konto über [https://docs.aws.amazon.com//aws-managed-policy/latest/reference/AdministratorAccess.html](https://docs.aws.amazon.com//aws-managed-policy/latest/reference/AdministratorAccess.html)Berechtigungen verfügen, werden diese Berechtigungen standardmäßig gewährt.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"sagemaker:CreateCluster",
"sagemaker:DeleteCluster",
"sagemaker:UpdateCluster"
],
"Resource": "arn:aws:sagemaker:*:*:cluster/*"
},
{
"Effect": "Allow",
"Action": [
"sagemaker:AddTags"
],
"Resource": "arn:aws:sagemaker:*:*:cluster/*"
},
{
"Effect": "Allow",
"Action": [
"sagemaker:ListTags",
"sagemaker:ListClusters",
"sagemaker:ListClusterNodes",
"sagemaker:ListComputeQuotas",
"sagemaker:ListTrainingPlans",
"sagemaker:DescribeCluster",
"sagemaker:DescribeClusterNode"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"cloudformation:CreateStack",
"cloudformation:UpdateStack",
"cloudformation:DeleteStack",
"cloudformation:ContinueUpdateRollback",
"cloudformation:SetStackPolicy",
"cloudformation:ValidateTemplate",
"cloudformation:DescribeStacks",
"cloudformation:DescribeStackEvents",
"cloudformation:Get*",
"cloudformation:List*"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "arn:aws:iam::*:role/sagemaker-*",
"Condition": {
"StringEquals": {
"iam:PassedToService": [
"sagemaker.amazonaws.com",
"eks.amazonaws.com",
"lambda.amazonaws.com"
]
}
}
},
{
"Effect": "Allow",
"Action": [
"iam:PassRole",
"iam:GetRole"
],
"Resource": "arn:aws:iam::*:role/*",
"Condition": {
"StringEquals": {
"iam:PassedToService": [
"sagemaker.amazonaws.com",
"eks.amazonaws.com",
"lambda.amazonaws.com",
"cloudformation.amazonaws.com"
]
}
}
},
{
"Sid": "AmazonVPCFullAccess",
"Effect": "Allow",
"Action": [
"ec2:AcceptVpcPeeringConnection",
"ec2:AcceptVpcEndpointConnections",
"ec2:AllocateAddress",
"ec2:AssignIpv6Addresses",
"ec2:AssignPrivateIpAddresses",
"ec2:AssociateAddress",
"ec2:AssociateDhcpOptions",
"ec2:AssociateRouteTable",
"ec2:AssociateSecurityGroupVpc",
"ec2:AssociateSubnetCidrBlock",
"ec2:AssociateVpcCidrBlock",
"ec2:AttachClassicLinkVpc",
"ec2:AttachInternetGateway",
"ec2:AttachNetworkInterface",
"ec2:AttachVpnGateway",
"ec2:AuthorizeSecurityGroupEgress",
"ec2:AuthorizeSecurityGroupIngress",
"ec2:CreateCarrierGateway",
"ec2:CreateCustomerGateway",
"ec2:CreateDefaultSubnet",
"ec2:CreateDefaultVpc",
"ec2:CreateDhcpOptions",
"ec2:CreateEgressOnlyInternetGateway",
"ec2:CreateFlowLogs",
"ec2:CreateInternetGateway",
"ec2:CreateLocalGatewayRouteTableVpcAssociation",
"ec2:CreateNatGateway",
"ec2:CreateNetworkAcl",
"ec2:CreateNetworkAclEntry",
"ec2:CreateNetworkInterface",
"ec2:CreateNetworkInterfacePermission",
"ec2:CreateRoute",
"ec2:CreateRouteTable",
"ec2:CreateSecurityGroup",
"ec2:CreateSubnet",
"ec2:CreateTags",
"ec2:CreateVpc",
"ec2:CreateVpcEndpoint",
"ec2:CreateVpcEndpointConnectionNotification",
"ec2:CreateVpcEndpointServiceConfiguration",
"ec2:CreateVpcPeeringConnection",
"ec2:CreateVpnConnection",
"ec2:CreateVpnConnectionRoute",
"ec2:CreateVpnGateway",
"ec2:DeleteCarrierGateway",
"ec2:DeleteCustomerGateway",
"ec2:DeleteDhcpOptions",
"ec2:DeleteEgressOnlyInternetGateway",
"ec2:DeleteFlowLogs",
"ec2:DeleteInternetGateway",
"ec2:DeleteLocalGatewayRouteTableVpcAssociation",
"ec2:DeleteNatGateway",
"ec2:DeleteNetworkAcl",
"ec2:DeleteNetworkAclEntry",
"ec2:DeleteNetworkInterface",
"ec2:DeleteNetworkInterfacePermission",
"ec2:DeleteRoute",
"ec2:DeleteRouteTable",
"ec2:DeleteSecurityGroup",
"ec2:DeleteSubnet",
"ec2:DeleteTags",
"ec2:DeleteVpc",
"ec2:DeleteVpcEndpoints",
"ec2:DeleteVpcEndpointConnectionNotifications",
"ec2:DeleteVpcEndpointServiceConfigurations",
"ec2:DeleteVpcPeeringConnection",
"ec2:DeleteVpnConnection",
"ec2:DeleteVpnConnectionRoute",
"ec2:DeleteVpnGateway",
"ec2:DescribeAccountAttributes",
"ec2:DescribeAddresses",
"ec2:DescribeAvailabilityZones",
"ec2:DescribeCarrierGateways",
"ec2:DescribeClassicLinkInstances",
"ec2:DescribeCustomerGateways",
"ec2:DescribeDhcpOptions",
"ec2:DescribeEgressOnlyInternetGateways",
"ec2:DescribeFlowLogs",
"ec2:DescribeInstances",
"ec2:DescribeInternetGateways",
"ec2:DescribeIpv6Pools",
"ec2:DescribeLocalGatewayRouteTables",
"ec2:DescribeLocalGatewayRouteTableVpcAssociations",
"ec2:DescribeKeyPairs",
"ec2:DescribeMovingAddresses",
"ec2:DescribeNatGateways",
"ec2:DescribeNetworkAcls",
"ec2:DescribeNetworkInterfaceAttribute",
"ec2:DescribeNetworkInterfacePermissions",
"ec2:DescribeNetworkInterfaces",
"ec2:DescribePrefixLists",
"ec2:DescribeRouteTables",
"ec2:DescribeSecurityGroupReferences",
"ec2:DescribeSecurityGroupRules",
"ec2:DescribeSecurityGroups",
"ec2:DescribeSecurityGroupVpcAssociations",
"ec2:DescribeStaleSecurityGroups",
"ec2:DescribeSubnets",
"ec2:DescribeTags",
"ec2:DescribeVpcAttribute",
"ec2:DescribeVpcClassicLink",
"ec2:DescribeVpcClassicLinkDnsSupport",
"ec2:DescribeVpcEndpointConnectionNotifications",
"ec2:DescribeVpcEndpointConnections",
"ec2:DescribeVpcEndpoints",
"ec2:DescribeVpcEndpointServiceConfigurations",
"ec2:DescribeVpcEndpointServicePermissions",
"ec2:DescribeVpcEndpointServices",
"ec2:DescribeVpcPeeringConnections",
"ec2:DescribeVpcs",
"ec2:DescribeVpnConnections",
"ec2:DescribeVpnGateways",
"ec2:DetachClassicLinkVpc",
"ec2:DetachInternetGateway",
"ec2:DetachNetworkInterface",
"ec2:DetachVpnGateway",
"ec2:DisableVgwRoutePropagation",
"ec2:DisableVpcClassicLink",
"ec2:DisableVpcClassicLinkDnsSupport",
"ec2:DisassociateAddress",
"ec2:DisassociateRouteTable",
"ec2:DisassociateSecurityGroupVpc",
"ec2:DisassociateSubnetCidrBlock",
"ec2:DisassociateVpcCidrBlock",
"ec2:EnableVgwRoutePropagation",
"ec2:EnableVpcClassicLink",
"ec2:EnableVpcClassicLinkDnsSupport",
"ec2:GetSecurityGroupsForVpc",
"ec2:ModifyNetworkInterfaceAttribute",
"ec2:ModifySecurityGroupRules",
"ec2:ModifySubnetAttribute",
"ec2:ModifyVpcAttribute",
"ec2:ModifyVpcEndpoint",
"ec2:ModifyVpcEndpointConnectionNotification",
"ec2:ModifyVpcEndpointServiceConfiguration",
"ec2:ModifyVpcEndpointServicePermissions",
"ec2:ModifyVpcPeeringConnectionOptions",
"ec2:ModifyVpcTenancy",
"ec2:MoveAddressToVpc",
"ec2:RejectVpcEndpointConnections",
"ec2:RejectVpcPeeringConnection",
"ec2:ReleaseAddress",
"ec2:ReplaceNetworkAclAssociation",
"ec2:ReplaceNetworkAclEntry",
"ec2:ReplaceRoute",
"ec2:ReplaceRouteTableAssociation",
"ec2:ResetNetworkInterfaceAttribute",
"ec2:RestoreAddressToClassic",
"ec2:RevokeSecurityGroupEgress",
"ec2:RevokeSecurityGroupIngress",
"ec2:UnassignIpv6Addresses",
"ec2:UnassignPrivateIpAddresses",
"ec2:UpdateSecurityGroupRuleDescriptionsEgress",
"ec2:UpdateSecurityGroupRuleDescriptionsIngress"
],
"Resource": "*"
},
{
"Sid": "CloudWatchPermissions",
"Effect": "Allow",
"Action": [
"cloudwatch:*",
"logs:*",
"sns:CreateTopic",
"sns:ListSubscriptions",
"sns:ListSubscriptionsByTopic",
"sns:ListTopics",
"sns:Subscribe",
"iam:GetPolicy",
"iam:GetPolicyVersion",
"iam:GetRole",
"oam:ListSinks",
"rum:*",
"synthetics:*",
"xray:*"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"s3:CreateBucket",
"s3:DeleteBucket",
"s3:PutBucketPolicy",
"s3:PutBucketTagging",
"s3:PutBucketPublicAccessBlock",
"s3:PutBucketLogging",
"s3:DeleteBucketPolicy",
"s3:PutObject",
"s3:DeleteObject",
"s3:PutEncryptionConfiguration",
"s3:AbortMultipartUpload",
"s3:Get*",
"s3:List*"
],
"Resource": [
"arn:aws:s3:::*",
"arn:aws:s3:::*/*"
]
},
{
"Effect": "Allow",
"Action": [
"eks:CreateCluster",
"eks:DeleteCluster",
"eks:CreateNodegroup",
"eks:DeleteNodegroup",
"eks:UpdateNodegroupConfig",
"eks:UpdateNodegroupVersion",
"eks:UpdateClusterConfig",
"eks:UpdateClusterVersion",
"eks:CreateFargateProfile",
"eks:DeleteFargateProfile",
"eks:CreateAddon",
"eks:DeleteAddon",
"eks:UpdateAddon",
"eks:CreateAccessEntry",
"eks:DeleteAccessEntry",
"eks:UpdateAccessEntry",
"eks:AssociateAccessPolicy",
"eks:AssociateIdentityProviderConfig",
"eks:DisassociateIdentityProviderConfig",
"eks:TagResource",
"eks:UntagResource",
"eks:AccessKubernetesApi",
"eks:Describe*",
"eks:List*"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ssm:GetParameter",
"ssm:PutParameter",
"ssm:DeleteParameter",
"ssm:DescribeParameters"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"kms:Decrypt",
"kms:GenerateDataKey"
],
"Resource": "*",
"Condition": {
"StringLike": {
"kms:ViaService": [
"sagemaker.*.amazonaws.com",
"ec2.*.amazonaws.com",
"s3.*.amazonaws.com",
"eks.*.amazonaws.com"
]
}
}
},
{
"Effect": "Allow",
"Action": [
"lambda:CreateFunction",
"lambda:DeleteFunction",
"lambda:GetFunction",
"lambda:UpdateFunctionCode",
"lambda:UpdateFunctionConfiguration",
"lambda:AddPermission",
"lambda:RemovePermission",
"lambda:PublishLayerVersion",
"lambda:DeleteLayerVersion",
"lambda:InvokeFunction",
"lambda:Get*",
"lambda:List*",
"lambda:TagResource"
],
"Resource": [
"arn:aws:lambda:*:*:function:*",
"arn:aws:lambda:*:*:layer:*"
]
},
{
"Effect": "Allow",
"Action": [
"iam:DeleteRole",
"iam:DeleteRolePolicy"
],
"Resource": [
"arn:aws:iam::*:role/*sagemaker*",
"arn:aws:iam::*:role/*eks*",
"arn:aws:iam::*:role/*hyperpod*",
"arn:aws:iam::*:policy/*sagemaker*",
"arn:aws:iam::*:policy/*hyperpod*",
"arn:aws:iam::*:role/*LifeCycleScriptStack*",
"arn:aws:iam::*:role/*LifeCycleScript*"
]
},
{
"Effect": "Allow",
"Action": [
"iam:CreateRole",
"iam:TagRole",
"iam:PutRolePolicy",
"iam:Get*",
"iam:List*",
"iam:AttachRolePolicy",
"iam:DetachRolePolicy"
],
"Resource": [
"arn:aws:iam::*:role/*",
"arn:aws:iam::*:policy/*"
]
},
{
"Sid": "FullAccessToFSx",
"Effect": "Allow",
"Action": [
"fsx:AssociateFileGateway",
"fsx:AssociateFileSystemAliases",
"fsx:CancelDataRepositoryTask",
"fsx:CopyBackup",
"fsx:CopySnapshotAndUpdateVolume",
"fsx:CreateAndAttachS3AccessPoint",
"fsx:CreateBackup",
"fsx:CreateDataRepositoryAssociation",
"fsx:CreateDataRepositoryTask",
"fsx:CreateFileCache",
"fsx:CreateFileSystem",
"fsx:CreateFileSystemFromBackup",
"fsx:CreateSnapshot",
"fsx:CreateStorageVirtualMachine",
"fsx:CreateVolume",
"fsx:CreateVolumeFromBackup",
"fsx:DetachAndDeleteS3AccessPoint",
"fsx:DeleteBackup",
"fsx:DeleteDataRepositoryAssociation",
"fsx:DeleteFileCache",
"fsx:DeleteFileSystem",
"fsx:DeleteSnapshot",
"fsx:DeleteStorageVirtualMachine",
"fsx:DeleteVolume",
"fsx:DescribeAssociatedFileGateways",
"fsx:DescribeBackups",
"fsx:DescribeDataRepositoryAssociations",
"fsx:DescribeDataRepositoryTasks",
"fsx:DescribeFileCaches",
"fsx:DescribeFileSystemAliases",
"fsx:DescribeFileSystems",
"fsx:DescribeS3AccessPointAttachments",
"fsx:DescribeSharedVpcConfiguration",
"fsx:DescribeSnapshots",
"fsx:DescribeStorageVirtualMachines",
"fsx:DescribeVolumes",
"fsx:DisassociateFileGateway",
"fsx:DisassociateFileSystemAliases",
"fsx:ListTagsForResource",
"fsx:ManageBackupPrincipalAssociations",
"fsx:ReleaseFileSystemNfsV3Locks",
"fsx:RestoreVolumeFromSnapshot",
"fsx:TagResource",
"fsx:UntagResource",
"fsx:UpdateDataRepositoryAssociation",
"fsx:UpdateFileCache",
"fsx:UpdateFileSystem",
"fsx:UpdateSharedVpcConfiguration",
"fsx:UpdateSnapshot",
"fsx:UpdateStorageVirtualMachine",
"fsx:UpdateVolume"
],
"Resource": "*"
}
]
}
```
------
## IAM-Benutzer für den Clusteradministrator
Clusteradministratoren (Admins) betreiben und konfigurieren SageMaker HyperPod Cluster und führen die Aufgaben in[SageMaker HyperPod Slurm-Clusteroperationen](sagemaker-hyperpod-operate-slurm.md). Das folgende Richtlinienbeispiel umfasst die Mindestberechtigungen für Clusteradministratoren, um den SageMaker HyperPod Kern auszuführen APIs und SageMaker HyperPod Cluster innerhalb Ihres AWS Kontos zu verwalten.
**Anmerkung**
IAM-Benutzer mit Cluster-Administratorrollen können Bedingungsschlüssel verwenden, um bei der Verwaltung von SageMaker HyperPod Clusterressourcen speziell für die Aktionen `CreateCluster` und `UpdateCluster` eine detaillierte Zugriffskontrolle zu gewährleisten. Um die Bedingungsschlüssel zu finden, die für diese Aktionen unterstützt werden, suchen Sie nach `CreateCluster` oder `UpdateCluster` in den [von SageMaker KI definierten Aktionen](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonsagemaker.html#amazonsagemaker-actions-as-permissions).
------
#### [ Slurm ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"sagemaker:CreateCluster",
"sagemaker:ListClusters"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"sagemaker:DeleteCluster",
"sagemaker:DescribeCluster",
"sagemaker:DescribeClusterNode",
"sagemaker:ListClusterNodes",
"sagemaker:UpdateCluster",
"sagemaker:UpdateClusterSoftware",
"sagemaker:BatchDeleteClusterNodes"
],
"Resource": "arn:aws:sagemaker:us-east-1:111122223333:cluster/*"
}
]
}
```
------
#### [ Amazon EKS ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "arn:aws:iam::111122223333:role/execution-role-name"
},
{
"Effect": "Allow",
"Action": [
"sagemaker:CreateCluster",
"sagemaker:DeleteCluster",
"sagemaker:DescribeCluster",
"sagemaker:DescribeClusterNode",
"sagemaker:ListClusterNodes",
"sagemaker:ListClusters",
"sagemaker:UpdateCluster",
"sagemaker:UpdateClusterSoftware",
"sagemaker:BatchAddClusterNodes",
"sagemaker:BatchDeleteClusterNodes",
"sagemaker:ListComputeQuotas",
"sagemaker:ListClusterSchedulerConfigs",
"sagemaker:DeleteClusterSchedulerConfig",
"sagemaker:DeleteComputeQuota",
"eks:DescribeCluster",
"eks:CreateAccessEntry",
"eks:DescribeAccessEntry",
"eks:DeleteAccessEntry",
"eks:AssociateAccessPolicy",
"iam:CreateServiceLinkedRole"
],
"Resource": "*"
}
]
}
```
------
Um Berechtigungen für den Zugriff auf die SageMaker AI-Konsole zu erteilen, verwenden Sie die Beispielrichtlinie unter [Erforderliche Berechtigungen für die Nutzung der Amazon SageMaker AI-Konsole](https://docs.aws.amazon.com/sagemaker/latest/dg/security_iam_id-based-policy-examples.html#console-permissions).
Um Berechtigungen für den Zugriff auf die Amazon EC2 Systems Manager Manager-Konsole zu erteilen, verwenden Sie die Beispielrichtlinie, die Sie im * AWS Systems Manager Benutzerhandbuch* [unter Die AWS Systems Manager Konsole verwenden](https://docs.aws.amazon.com/systems-manager/latest/userguide/security_iam_id-based-policy-examples.html#security_iam_id-based-policy-examples-console) finden.
Sie könnten auch erwägen, die [`AmazonSageMakerFullAccess`](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonSageMakerFullAccess)Richtlinie an die Rolle anzuhängen. Beachten Sie jedoch, dass die `AmazonSageMakerFullAccess` Richtlinie Berechtigungen für die gesamten SageMaker API-Aufrufe, Funktionen und Ressourcen gewährt.
Allgemeine Hinweise zu IAM-Benutzern finden Sie unter [IAM-Benutzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html) im *AWS Identity and Access Management -Benutzerhandbuch*.
## IAM-Benutzer für Wissenschaftler
Wissenschaftler melden sich an und führen ML-Workloads auf SageMaker HyperPod Clusterknoten aus, die von Clusteradministratoren bereitgestellt werden. Wissenschaftlern in Ihrem AWS Konto sollten Sie die Erlaubnis erteilen, den `"ssm:StartSession"` SSM-Befehl auszuführen. `start-session` Im Folgenden finden Sie ein Beispiel für eine Richtlinie für IAM-Benutzer.
------
#### [ Slurm ]
Fügen Sie die folgende Richtlinie hinzu, um SSM-Sitzungsberechtigungen für die Verbindung mit einem SSM-Ziel für alle Ressourcen zu gewähren. Dadurch können Sie auf HyperPod Cluster zugreifen.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:StartSession",
"ssm:TerminateSession"
],
"Resource": "*"
}
]
}
```
------
------
#### [ Amazon EKS ]
Gewähren Sie Datenwissenschaftlern die folgenden IAM-Rollenberechtigungen zur Ausführung `hyperpod list-clusters` und `hyperpod connect-cluster` Befehle unter den HyperPod CLI-Befehlen. Weitere Informationen zur HyperPod CLI finden Sie unter[Ausführung von Jobs auf SageMaker HyperPod Clustern, die von Amazon EKS orchestriert wurden](sagemaker-hyperpod-eks-run-jobs.md). Es umfasst auch SSM-Sitzungsberechtigungen für alle Ressourcen, um eine Verbindung zu einem SSM-Ziel herzustellen. Dadurch können Sie auf HyperPod Cluster zugreifen.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DescribeHyerpodClusterPermissions",
"Effect": "Allow",
"Action": [
"sagemaker:DescribeCluster"
],
"Resource": "arn:aws:sagemaker:us-east-2:111122223333:cluster/hyperpod-cluster-name"
},
{
"Sid": "UseEksClusterPermissions",
"Effect": "Allow",
"Action": [
"eks:DescribeCluster"
],
"Resource": "arn:aws:sagemaker:us-east-2:111122223333:cluster/eks-cluster-name"
},
{
"Sid": "ListClustersPermission",
"Effect": "Allow",
"Action": [
"sagemaker:ListClusters"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ssm:StartSession",
"ssm:TerminateSession"
],
"Resource": "*"
}
]
}
```
------
*Informationen darüber, wie Datenwissenschaftlern IAM-Benutzern oder -Rollen Zugriff auf Kubernetes APIs im Cluster gewährt werden, finden Sie unter [Gewähren Sie IAM-Benutzern und -Rollen Zugriff auf Kubernetes APIs](https://docs.aws.amazon.com/eks/latest/userguide/grant-k8s-access.html) im Amazon EKS-Benutzerhandbuch.*
------
## IAM-Rolle für SageMaker HyperPod
Damit SageMaker HyperPod Cluster ausgeführt werden und mit den erforderlichen AWS Ressourcen kommunizieren können, müssen Sie eine IAM-Rolle erstellen, die der HyperPod Cluster übernehmen soll.
Beginnen Sie mit dem Anfügen der verwalteten Rolle [AWS verwaltete Richtlinie: AmazonSageMakerHyperPodServiceRolePolicy](security-iam-awsmanpol-AmazonSageMakerHyperPodServiceRolePolicy.md). Aufgrund dieser AWS verwalteten Richtlinie übernehmen SageMaker HyperPod Cluster-Instance-Gruppen die Rolle, mit Amazon CloudWatch, Amazon S3 und AWS Systems Manager Agent (SSM-Agent) zu kommunizieren. Diese verwaltete Richtlinie ist die Mindestanforderung für den ordnungsgemäßen Betrieb von SageMaker HyperPod Ressourcen. Daher müssen Sie allen Instance-Gruppen eine IAM-Rolle mit dieser Richtlinie zuweisen.
**Tipp**
Je nachdem, wie Sie die Berechtigungen für mehrere Instance-Gruppen gestalten möchten, können Sie auch mehrere IAM-Rollen einrichten und diese verschiedenen Instance-Gruppen zuweisen. Wenn Sie Ihren Cluster-Benutzerzugriff auf bestimmte SageMaker HyperPod Clusterknoten einrichten, übernehmen die Knoten die Rolle mit den selektiven Berechtigungen, die Sie manuell zugewiesen haben.
Wenn Sie den Zugriff für Wissenschaftler auf bestimmte Clusterknoten über [AWS Systems Manager](https://aws.amazon.com/systems-manager/) (siehe auch [Einrichtung AWS Systems Manager und Ausführung als für die Cluster-Benutzerzugriffskontrolle](sagemaker-hyperpod-prerequisites.md#sagemaker-hyperpod-prerequisites-ssm)) einrichten, übernehmen die Clusterknoten die Rolle mit den selektiven Berechtigungen, die Sie manuell zuweisen.
Wenn Sie mit der Erstellung der IAM-Rollen fertig sind, notieren Sie sich deren Namen und ARNs. Sie verwenden die Rollen beim Erstellen eines SageMaker HyperPod Clusters und gewähren dabei jeder Instanzgruppe die richtigen Berechtigungen, um mit den erforderlichen AWS Ressourcen zu kommunizieren.
------
#### [ Slurm ]
Für „ HyperPod Orchestrated with Slurm“ müssen Sie die folgende verwaltete Richtlinie an die SageMaker HyperPod IAM-Rolle anhängen.
+ [AmazonSageMakerClusterInstanceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonSageMakerClusterInstanceRolePolicy.html)
**(Optional) Zusätzliche Berechtigungen für die Verwendung SageMaker HyperPod mit Amazon Virtual Private Cloud**
Wenn Sie Ihre eigene Amazon Virtual Private Cloud (VPC) anstelle der standardmäßigen SageMaker KI-VPC verwenden möchten, sollten Sie der IAM-Rolle für die folgenden zusätzlichen Berechtigungen hinzufügen. SageMaker HyperPod
```
{
"Effect": "Allow",
"Action": [
"ec2:CreateNetworkInterface",
"ec2:CreateNetworkInterfacePermission",
"ec2:DeleteNetworkInterface",
"ec2:DeleteNetworkInterfacePermission",
"ec2:DescribeNetworkInterfaces",
"ec2:DescribeVpcs",
"ec2:DescribeDhcpOptions",
"ec2:DescribeSubnets",
"ec2:DescribeSecurityGroups",
"ec2:DetachNetworkInterface"
],
"Resource": "*"
}
{
"Effect": "Allow",
"Action": "ec2:CreateTags",
"Resource": [
"arn:aws:ec2:*:*:network-interface/*"
]
}
```
In der folgenden Liste ist aufgeführt, welche Berechtigungen erforderlich sind, um SageMaker HyperPod Cluster-Funktionen zu aktivieren, wenn Sie den Cluster mit Ihrer eigenen Amazon VPC konfigurieren.
+ Die folgenden `ec2` Berechtigungen sind erforderlich, um die Konfiguration eines SageMaker HyperPod Clusters mit Ihrer VPC zu ermöglichen.
```
{
"Effect": "Allow",
"Action": [
"ec2:CreateNetworkInterface",
"ec2:CreateNetworkInterfacePermission",
"ec2:DeleteNetworkInterface",
"ec2:DeleteNetworkInterfacePermission",
"ec2:DescribeNetworkInterfaces",
"ec2:DescribeVpcs",
"ec2:DescribeDhcpOptions",
"ec2:DescribeSubnets",
"ec2:DescribeSecurityGroups"
],
"Resource": "*"
}
```
+ Die folgende `ec2` Berechtigung ist erforderlich, um die [SageMaker HyperPod automatische Wiederaufnahmefunktion](sagemaker-hyperpod-resiliency-slurm-auto-resume.md) zu aktivieren.
```
{
"Effect": "Allow",
"Action": [
"ec2:DetachNetworkInterface"
],
"Resource": "*"
}
```
+ Die folgende `ec2` Berechtigung ermöglicht SageMaker HyperPod das Erstellen von Tags auf den Netzwerkschnittstellen in Ihrem Konto.
```
{
"Effect": "Allow",
"Action": "ec2:CreateTags",
"Resource": [
"arn:aws:ec2:*:*:network-interface/*"
]
}
```
------
#### [ Amazon EKS ]
Für die HyperPod Orchestrierung mit Amazon EKS müssen Sie die folgenden verwalteten Richtlinien an die SageMaker HyperPod IAM-Rolle anhängen.
+ [AmazonSageMakerClusterInstanceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonSageMakerClusterInstanceRolePolicy.html)
Fügen Sie der Rolle zusätzlich zu den verwalteten Richtlinien die folgende Berechtigungsrichtlinie hinzu.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:AssignPrivateIpAddresses",
"ec2:AttachNetworkInterface",
"ec2:CreateNetworkInterface",
"ec2:CreateNetworkInterfacePermission",
"ec2:DeleteNetworkInterface",
"ec2:DeleteNetworkInterfacePermission",
"ec2:DescribeInstances",
"ec2:DescribeInstanceTypes",
"ec2:DescribeNetworkInterfaces",
"ec2:DescribeTags",
"ec2:DescribeVpcs",
"ec2:DescribeDhcpOptions",
"ec2:DescribeSubnets",
"ec2:DescribeSecurityGroups",
"ec2:DetachNetworkInterface",
"ec2:ModifyNetworkInterfaceAttribute",
"ec2:UnassignPrivateIpAddresses",
"ecr:BatchCheckLayerAvailability",
"ecr:BatchGetImage",
"ecr:GetAuthorizationToken",
"ecr:GetDownloadUrlForLayer",
"eks-auth:AssumeRoleForPodIdentity"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ec2:CreateTags"
],
"Resource": [
"arn:aws:ec2:*:*:network-interface/*"
]
}
]
}
```
------
**Anmerkung**
Die `"eks-auth:AssumeRoleForPodIdentity"`-Erlaubnis ist optional. Sie ist erforderlich, wenn Sie EKS Pod Identity verwenden möchten.
**SageMaker HyperPod Mit einem Service verknüpfte Rolle**
HyperPod Erstellt für Amazon EKS-Unterstützung in SageMaker HyperPod eine serviceverknüpfte Rolle mit [AWS verwaltete Richtlinie: AmazonSageMakerHyperPodServiceRolePolicy](security-iam-awsmanpol-AmazonSageMakerHyperPodServiceRolePolicy.md) zur Überwachung und Unterstützung der Resilienz Ihres EKS-Clusters, z. B. zum Ersetzen von Knoten und zum Neustarten von Jobs.
**Zusätzliche IAM-Richtlinien für Amazon-EKS-Cluster mit eingeschränkter Instance-Gruppe (RIG)**
Workloads, die in eingeschränkten Instance-Gruppen ausgeführt werden, benötigen die Ausführungsrolle, um Daten aus Amazon S3 zu laden. Sie müssen der Ausführungsrolle die zusätzlichen Amazon-S3-Berechtigungen hinzufügen, damit Anpassungsaufträge, die in eingeschränkten Instance-Gruppen ausgeführt werden, Eingabedaten ordnungsgemäß abrufen können.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket"
]
},
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject",
"s3:DeleteObject"
],
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket/*"
]
}
]
}
```
------
------
# Vom Kunden verwaltete Verschlüsselung für AWS KMS key SageMaker HyperPod
Standardmäßig wird das Amazon EBS-Root-Volume, das an Ihren SageMaker HyperPod Cluster angehängt ist, mit einem AWS KMS key eigenen Volume verschlüsselt. AWS Sie haben nun die Möglichkeit, sowohl das Root-Volume von Amazon EBS als auch das sekundäre Volume mit Ihren eigenen, vom Kunden verwalteten KMS-Schlüsseln zu verschlüsseln. Im folgenden Thema wird beschrieben, wie vom Kunden verwaltete Schlüssel (CMKs) mit Volumes in HyperPod Clustern funktionieren.
**Anmerkung**
Die folgenden Ausnahmen gelten für die Verwendung von kundenverwalteten Schlüsseln für SageMaker HyperPod Cluster:
Die kundenseitig verwaltete Schlüsselverschlüsselung wird nur für Cluster mit kontinuierlichem Knotenbereitstellungsmodus unterstützt. Eingeschränkte Instance-Gruppen unterstützen keine kundenseitig verwalteten Schlüssel.
HyperPod Cluster unterstützen derzeit nicht die Weitergabe von AWS KMS Verschlüsselungskontext in vom Kunden verwalteten Schlüsselverschlüsselungsanforderungen. Stellen Sie daher sicher, dass Ihre KMS-Schlüsselrichtlinie nicht anhand von Verschlüsselungskontextbedingungen begrenzt ist, da dies verhindert, dass der Cluster den Schlüssel verwendet.
Die Übertragung von KMS-Schlüsseln wird derzeit nicht unterstützt, sodass Sie den in Ihrer Konfiguration angegebenen KMS-Schlüssel nicht ändern können. Um einen anderen Schlüssel zu verwenden, erstellen Sie eine neue Instance-Gruppe mit dem gewünschten Schlüssel und löschen Sie Ihre alte Instance-Gruppe.
Die Angabe von kundenverwalteten Schlüsseln für HyperPod Cluster über die Konsole wird derzeit nicht unterstützt.
## Berechtigungen
Bevor Sie Ihren vom Kunden verwalteten Schlüssel mit verwenden können HyperPod, müssen Sie die folgenden Voraussetzungen erfüllen:
+ Stellen Sie sicher, dass der AWS IAM-Ausführungsrolle, die Sie für SageMaker KI verwenden, die folgenden Berechtigungen AWS KMS hinzugefügt wurden. Mit `[ kms:CreateGrant](https://docs.aws.amazon.com/kms/latest/APIReference/API_CreateGrant.html)` dieser Berechtigung können HyperPod Sie mithilfe von Berechtigungen für Ihren KMS-Schlüssel die folgenden Aktionen ausführen:
+ Skalierung der Anzahl Ihrer Instanzen (UpdateCluster Operationen)
+ Hinzufügen von Clusterknoten (BatchAddClusterNodes Operationen)
+ Software patchen (UpdateClusterSoftware Operationen)
Weitere Informationen zum Aktualisieren der Berechtigungen Ihrer IAM-Rolle finden Sie unter [Hinzufügen und Entfernen von IAM-Identitätsberechtigungen](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html) im *IAM-Benutzerhandbuch*.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"kms:CreateGrant",
"kms:DescribeKey"
],
"Resource": "*"
}
]
}
```
------
+ Fügen Sie Ihrer KMS-Schlüsselrichtlinie die folgenden Berechtigungen hinzu. Weitere Informationen finden Sie unter [Ändern einer Schlüsselrichtlinie](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-modifying.html) im *AWS KMS -Entwicklerhandbuch*.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Id": "hyperpod-key-policy",
"Statement": [
{
"Sid": "Enable IAM User Permissions",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:root"
},
"Action": "kms:*",
"Resource": "*"
},
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:role/"
},
"Action": "kms:CreateGrant",
"Resource": "arn:aws:kms:us-east-1:111122223333:key/key-id",
"Condition": {
"StringEquals": {
"kms:ViaService": "sagemaker.us-east-1.amazonaws.com"
},
"Bool": {
"kms:GrantIsForAWSResource": "true"
}
}
},
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:role/"
},
"Action": "kms:DescribeKey",
"Resource": "arn:aws:kms:us-east-1:111122223333:key/key-id",
"Condition": {
"StringEquals": {
"kms:ViaService": "sagemaker.us-east-1.amazonaws.com"
}
}
}
]
}
```
------
## So verwenden Sie Ihren KMS-Schlüssel
Sie können Ihre vom Kunden verwalteten Schlüssel angeben, wenn Sie einen Cluster mithilfe der Operationen [CreateCluster](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_CreateCluster.html)und [UpdateCluster](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_UpdateCluster.html)API erstellen oder aktualisieren. Die `InstanceStorageConfigs`-Struktur ermöglicht bis zu zwei `EbsVolumeConfig`-Konfigurationen, in denen Sie das Amazon EBS-Stammvolume und optional ein sekundäres Volume konfigurieren können. Sie können entweder denselben KMS-Schlüssel oder einen anderen KMS-Schlüssel für jedes Volume verwenden, je nach Ihren Anforderungen.
Sie können wählen, ob Sie einen kundenseitig verwalteten Schlüssel für keinen, beide oder einen der beiden Volumes angeben möchten. Sie können jedoch nicht zwei Root-Volumes oder zwei sekundäre Volumes angeben.
Bei der Konfiguration des Root-Volumes gelten folgende Anforderungen:
+ muss `RootVolume` auf `True` festgelegt sein. Der Standardwert ist `False`, wodurch stattdessen das sekundäre Volume konfiguriert wird.
+ Das `VolumeKmsKeyId`-Feld ist erforderlich und Sie müssen Ihren kundenseitig verwalteten Schlüssel angeben. Das liegt daran, dass das Root-Volume immer entweder mit einem AWS eigenen Schlüssel oder einem vom Kunden verwalteten Schlüssel verschlüsselt werden muss (wenn Sie keinen eigenen angeben, wird ein AWS eigener Schlüssel verwendet).
+ Sie können das `VolumeSizeInGB` Feld für Root-Volumes nicht angeben, da es die Größe des Root-Volumes für Sie HyperPod bestimmt.
Bei der Konfiguration des sekundären Volumes gelten folgende Anforderungen:
+ `RootVolume` muss `False` sein (der Wert für dieses Feld ist standardmäßig `False`).
+ Das Feld `VolumeKmsKeyId` ist optional. Sie können denselben kundenseitig verwalteten Schlüssel verwenden, den Sie für das Root-Volume angegeben haben, oder Sie können einen anderen Schlüssel verwenden.
+ Das Feld `VolumeSizeInGB` ist erforderlich, da Sie die gewünschte Größe für das sekundäre Volume angeben müssen.
**Wichtig**
Wenn Sie kundenseitig verwaltete Schlüssel verwenden, empfehlen wir Ihnen dringend, für jede Instance-Gruppe in Ihrem Cluster unterschiedliche KMS-Schlüssel zu verwenden. Die Verwendung desselben kundenseitig verwalteten Schlüssels für mehrere Instance-Gruppen kann dazu führen, dass Berechtigungen unbeabsichtigt bestehen bleiben, selbst wenn Sie versuchen, eine Erteilung zu widerrufen. Wenn Sie beispielsweise einen AWS KMS Zuschuss für die Volumes einer Instanzgruppe widerrufen, kann diese Instanzgruppe weiterhin Skalierungs- und Patching-Operationen zulassen, da Zuschüsse für andere Instanzgruppen mit demselben Schlüssel bestehen. Um dieses Problem zu vermeiden, stellen Sie sicher, dass Sie jeder Instance-Gruppe in Ihrem Cluster eindeutige KMS-Schlüssel zuweisen. Wenn Sie Berechtigungen für Instance-Gruppen einschränken müssen, können Sie eine der folgenden Optionen verwenden:
Deaktivieren Sie den KMS-Schlüssel.
Wenden Sie Ablehnungsrichtlinien auf die KMS-Schlüsselrichtlinie an.
Widerrufen Sie alle Instance-Gruppenberechtigungen für den Schlüssel (anstatt nur eine Berechtigung zu widerrufen).
Löschen Sie die Instance-Gruppe.
Löschen Sie den Cluster.
Die folgenden Beispiele zeigen, wie Sie mithilfe von und vom Kunden verwaltete Schlüssel sowohl für Stamm- als auch für Sekundärvolumes angeben. CreateCluster UpdateCluster APIs Diese Beispiele zeigen nur die erforderlichen Felder für die Integration von kundenseitig verwalteten Schlüsseln. Um einen kundenseitig verwalteten Schlüssel nur für eines der Volumes zu konfigurieren, geben Sie nur eine `EbsVolumeConfig` an.
Weitere Informationen zur Konfiguration von Clustererstellung und Aktualisierungsanforderungen finden Sie unter [Einen SageMaker HyperPod Cluster erstellen](sagemaker-hyperpod-eks-operate-cli-command-create-cluster.md) und [Die SageMaker HyperPod Cluster-Konfiguration wird aktualisiert](sagemaker-hyperpod-eks-operate-cli-command-update-cluster.md).
------
#### [ CreateCluster ]
Das folgende Beispiel zeigt eine AWS CLI Anfrage zur [Clustererstellung](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/create-cluster.html) mit vom Kunden verwalteter Schlüsselverschlüsselung.
```
aws sagemaker create-cluster \
--cluster-name \
--instance-groups '[{
"ExecutionRole": "arn:aws:iam::111122223333:role/",
"InstanceCount": 2,
"InstanceGroupName": "",
"InstanceStorageConfigs": [
{
"EbsVolumeConfig": {
"RootVolume": True,
"VolumeKmsKeyId": "arn:aws:kms:us-east-1:111122223333:key/root-volume-key-id"
}
},
{
"EbsVolumeConfig": {
"VolumeSizeInGB": 100,
"VolumeKmsKeyId": "arn:aws:kms:us-east-1:111122223333:key/secondary-volume-key-id"
}
}
],
"InstanceType": ""
}]' \
--vpc-config '{
"SecurityGroupIds": [""],
"Subnets": [""]
}'
```
------
#### [ UpdateCluster ]
Das folgende Beispiel zeigt eine [AWS CLI Cluster-Update-Anfrage](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/update-cluster.html) mit vom Kunden verwalteter Schlüsselverschlüsselung.
```
aws sagemaker update-cluster \
--cluster-name \
--instance-groups '[{
"InstanceGroupName": "",
"InstanceStorageConfigs": [
{
"EbsVolumeConfig": {
"RootVolume": true,
"VolumeKmsKeyId": "arn:aws:kms:us-east-1:111122223333:key/root-volume-key-id"
}
},
{
"EbsVolumeConfig": {
"VolumeSizeInGB": 100,
"VolumeKmsKeyId": "arn:aws:kms:us-east-1:111122223333:key/secondary-volume-key-id"
}
}
]
}]'
```
------
# SageMaker HyperPod Rezepte
SageMaker HyperPod Amazon-Rezepte sind vorkonfigurierte Trainingsstapel, die von bereitgestellt werden AWS , damit Sie schnell mit dem Training und der Feinabstimmung öffentlich verfügbarer Grundmodelle (FMs) aus verschiedenen Modellfamilien wie Llama, Mistral, Mixtral oder beginnen können. DeepSeek Rezepte automatisieren die end-to-end Trainingsschleife, einschließlich des Ladens von Datensätzen, der Anwendung verteilter Trainingstechniken und der Verwaltung von Prüfpunkten für eine schnellere Wiederherstellung nach Fehlern.
SageMaker HyperPod Rezepte sind besonders nützlich für Benutzer, die möglicherweise nicht über fundierte Kenntnisse im Bereich maschinelles Lernen verfügen, da sie einen Großteil der Komplexität, die mit dem Training großer Modelle verbunden ist, abstrahieren.
Sie können Rezepte innerhalb SageMaker HyperPod oder als SageMaker Trainingsjobs ausführen.
Die folgenden Tabellen werden im SageMaker HyperPod GitHub Repository verwaltet und enthalten die meisten up-to-date Informationen zu den Modellen, die für die Vorbereitung und Feinabstimmung unterstützt werden, zu ihren jeweiligen Rezepten und Startskripten, zu den unterstützten Instance-Typen und mehr.
+ Die aktuelle Liste der unterstützten Modelle, Rezepte und Startskripte für das Training finden Sie in der [Vortraining-Tabelle](https://github.com/aws/sagemaker-hyperpod-recipes?tab=readme-ov-file#pre-training).
+ Die aktuelle Liste der unterstützten Modelle, Rezepte und Startskripte für die Feinabstimmung finden Sie in der [Feinabstimmungs-Tabelle](https://github.com/aws/sagemaker-hyperpod-recipes?tab=readme-ov-file#fine-tuning).
Für SageMaker HyperPod Benutzer ergibt sich die Automatisierung der end-to-end Trainingsabläufe aus der Integration des Trainingsadapters mit SageMaker HyperPod den Rezepten. Der Trainingsadapter basiert auf dem [ NeMo NVIDIA-Framework](https://docs.nvidia.com/nemo-framework/user-guide/latest/overview.html) und dem [Neuronx Distributed Training](https://awsdocs-neuron.readthedocs-hosted.com/en/latest/libraries/neuronx-distributed/index.html) Package. Wenn Sie mit der Verwendung des Trainingsadapters vertraut sind NeMo, ist der Vorgang bei der Verwendung des Trainingsadapters derselbe. Der Trainingsadapter führt das Rezept auf Ihrem Cluster aus.
![\[Diagramm, das den SageMaker HyperPod Rezept-Arbeitsablauf zeigt. Ein „Rezept“ -Symbol oben führt in ein Feld mit dem Namen „HyperPod Rezeptstarter“. Dieses Feld ist mit einem größeren Abschnitt mit der Bezeichnung „Cluster: Slurm, K8s, ...” verbunden, der drei GPU-Symbole mit zugehörigen Rezeptdateien enthält. Der untere Teil des Cluster-Bereichs trägt die Aufschrift „Train with HyperPod Training Adapter“.\]](http://docs.aws.amazon.com/de_de/sagemaker/latest/dg/images/sagemaker-hyperpod-recipes-overview.png)
Sie können auch Ihr eigenes Modell trainieren, indem Sie Ihr eigenes benutzerdefiniertes Rezept definieren.
Informationen zum Einstieg in ein Tutorial finden Sie unter [Lernprogramme](sagemaker-hyperpod-recipes-tutorials.md).
**Topics**
+ [Lernprogramme](sagemaker-hyperpod-recipes-tutorials.md)
+ [Standardkonfigurationen](default-configurations.md)
+ [Cluster-spezifische Konfigurationen](cluster-specific-configurations.md)
+ [Überlegungen](cluster-specific-configurations-special-considerations.md)
+ [Erweiterte Einstellungen](cluster-specific-configurations-advanced-settings.md)
+ [Anhang](appendix.md)
# Lernprogramme
Die folgenden Schnellstart-Tutorials helfen Ihnen bei den ersten Schritten mit der Verwendung der Rezepte für das Training:
+ SageMaker HyperPod mit Slurm-Orchestrierung
+ Vortraining
+ [HyperPod Tutorial zur Vorbereitung des Slurm-Clusters (GPU)](hyperpod-gpu-slurm-pretrain-tutorial.md)
+ [Tutorial zum Vortraining des Trainium-Slurm-Clusters](hyperpod-trainium-slurm-cluster-pretrain-tutorial.md)
+ Feinabstimmung
+ [HyperPod Slurm-Cluster Left-LoRa-Tutorial (GPU)](hyperpod-gpu-slurm-peft-lora-tutorial.md)
+ [HyperPod Tutorial zum Slurm-Cluster DPO (GPU)](hyperpod-gpu-slurm-dpo-tutorial.md)
+ SageMaker HyperPod mit K8s Orchestrierung
+ Vortraining
+ [Tutorial zum Vortraining des Kubernetes-Cluster (GPU)](sagemaker-hyperpod-gpu-kubernetes-cluster-pretrain-tutorial.md)
+ [Tutorial zur Vorbereitung von SageMaker Trainium-Schulungsaufträgen](sagemaker-hyperpod-trainium-sagemaker-training-jobs-pretrain-tutorial.md)
+ SageMaker Ausbildungsberufe
+ Vortraining
+ [SageMaker Tutorial für Trainingsjobs vor dem Training (GPU)](sagemaker-hyperpod-gpu-sagemaker-training-jobs-pretrain-tutorial.md)
+ [Tutorial zur Vorbereitung von SageMaker Trainium-Schulungsaufträgen](sagemaker-hyperpod-trainium-sagemaker-training-jobs-pretrain-tutorial.md)
# HyperPod Tutorial zur Vorbereitung des Slurm-Clusters (GPU)
Das folgende Tutorial richtet die Slurm-Umgebung ein und startet einen Trainingsjob auf einem Lama-Modell mit 8 Milliarden Parametern.
**Voraussetzungen**
Bevor Sie mit der Einrichtung Ihrer Umgebung zur Ausführung des Rezepts beginnen, stellen Sie sicher, dass Sie über Folgendes verfügen:
Richten Sie einen HyperPod GPU-Slurm-Cluster ein.
In Ihrem HyperPod Slurm-Cluster müssen Nvidia Enroot und Pyxis aktiviert sein (diese sind standardmäßig aktiviert).
Ein gemeinsam genutzter Speicherort. Es kann sich um ein FSx Amazon-Dateisystem oder ein NFS-System handeln, auf das von den Clusterknoten aus zugegriffen werden kann.
Daten in einem der folgenden Formate:
JSON
JSONGZ (komprimiertes JSON)
ARROW
(Optional) Sie benötigen ein HuggingFace Token, wenn Sie die Modellgewichte von HuggingFace für das Training oder die Feinabstimmung verwenden. Weitere Informationen zum Abrufen des Tokens finden Sie unter [Benutzerzugriffstoken](https://huggingface.co/docs/hub/en/security-tokens).
## HyperPod Einrichtung der GPU-Slurm-Umgebung
Gehen Sie wie folgt vor, um einen Trainingsjob auf einem HyperPod GPU-Slurm-Cluster zu initiieren:
1. Verbinden Sie sich per SSH mit dem Hauptknoten Ihres Slurm-Clusters.
1. Nachdem Sie sich angemeldet haben, richten Sie die virtuelle Umgebung ein. Vergewissern Sie sich, dass Sie Python 3.9 oder höher verwenden.
```
#set up a virtual environment
python3 -m venv ${PWD}/venv
source venv/bin/activate
```
1. Klonen Sie die SageMaker HyperPod Rezepte und SageMaker HyperPod Adapter-Repositorys an einen gemeinsam genutzten Speicherort.
```
git clone https://github.com/aws/sagemaker-hyperpod-training-adapter-for-nemo.git
git clone --recursive https://github.com/aws/sagemaker-hyperpod-recipes.git
cd sagemaker-hyperpod-recipes
pip3 install -r requirements.txt
```
1. Erstellen Sie mit Enroot eine Squash-Datei. Die aktuelle Version des SMP-Containers finden Sie unter [Versionshinweise für die SageMaker Modellparallelitätsbibliothek](model-parallel-release-notes.md). Weitere Informationen zur Verwendung der Enroot-Datei finden Sie unter [Erstellen eines AWS optimierten Nemo-Launcher-Images](https://github.com/aws-samples/awsome-distributed-training/tree/main/3.test_cases/2.nemo-launcher#2-build-aws-optimized-nemo-launcher-image).
```
REGION=""
IMAGE="658645717510.dkr.ecr.${REGION}.amazonaws.com/smdistributed-modelparallel:2.4.1-gpu-py311-cu121"
aws ecr get-login-password --region ${REGION} | docker login --username AWS --password-stdin 658645717510.dkr.ecr.${REGION}.amazonaws.com
enroot import -o $PWD/smdistributed-modelparallel.sqsh dockerd://${IMAGE}
mv $PWD/smdistributed-modelparallel.sqsh "/fsx/"
```
1. Um die Enroot-Squash-Datei zum Starten des Trainings zu verwenden, ändern Sie die `recipes_collection/config.yaml`-Datei anhand des folgenden Beispiels.
```
container: /fsx/path/to/your/smdistributed-modelparallel.sqsh
```
## Starten eines Trainingsjobs
Nachdem Sie die Abhängigkeiten installiert haben, starten Sie einen Trainingsjob aus dem `sagemaker-hyperpod-recipes/launcher_scripts`-Verzeichnis. [Sie erhalten die Abhängigkeiten, indem Sie das Rezept-Repository klonen: SageMaker HyperPod ](https://github.com/aws/sagemaker-hyperpod-recipes)
Wählen Sie zunächst Ihr Trainingsrezept von Github aus. Der Modellname wird als Teil des Rezepts angegeben. Im folgenden Beispiel verwenden wir das `launcher_scripts/llama/run_hf_llama3_8b_seq16k_gpu_p5x16_pretrain.sh`-Skript, um ein Llama 8b mit einer Sequenzlänge von 8192, `llama/hf_llama3_8b_seq16k_gpu_p5x16_pretrain`, und einem Vorab-Trainingsrezept zu starten.
+ `IMAGE`: Der Container aus dem Abschnitt „Umgebungseinrichtung“.
+ (Optional) Sie können das HuggingFace Token bereitstellen, wenn Sie vorab trainierte Gewichtungen von benötigen, HuggingFace indem Sie das folgende Schlüssel-Wert-Paar festlegen:
```
recipes.model.hf_access_token=
```
```
#!/bin/bash
IMAGE="${YOUR_IMAGE}"
SAGEMAKER_TRAINING_LAUNCHER_DIR="${SAGEMAKER_TRAINING_LAUNCHER_DIR:-${PWD}}"
TRAIN_DIR="${YOUR_TRAIN_DIR}" # Location of training dataset
VAL_DIR="${YOUR_VAL_DIR}" # Location of validation dataset
# experiment ouput directory
EXP_DIR="${YOUR_EXP_DIR}"
HYDRA_FULL_ERROR=1 python3 "${SAGEMAKER_TRAINING_LAUNCHER_DIR}/main.py" \
recipes=training/llama/hf_llama3_8b_seq16k_gpu_p5x16_pretrain \
base_results_dir="${SAGEMAKER_TRAINING_LAUNCHER_DIR}/results" \
recipes.run.name="hf_llama3_8b" \
recipes.exp_manager.exp_dir="$EXP_DIR" \
recipes.model.data.train_dir="$TRAIN_DIR" \
recipes.model.data.val_dir="$VAL_DIR" \
container="${IMAGE}" \
+cluster.container_mounts.0="/fsx:/fsx"
```
Nachdem Sie alle erforderlichen Parameter im Launcher-Skript konfiguriert haben, können Sie das Skript mit dem folgenden Befehl ausführen.
```
bash launcher_scripts/llama/run_hf_llama3_8b_seq16k_gpu_p5x16_pretrain.sh
```
Weitere Informationen zur Konfiguration des Slurm-Clusters finden Sie unter [Einen Trainingsjob auf HyperPod Slurm ausführen](cluster-specific-configurations-run-training-job-hyperpod-slurm.md).
# Tutorial zum Vortraining des Trainium-Slurm-Clusters
Das folgende Tutorial richtet eine Trainium-Umgebung auf einem Slurm-Cluster ein und startet einen Trainingsjob auf einem Lama-Modell mit 8 Milliarden Parametern.
**Voraussetzungen**
Bevor Sie mit der Einrichtung Ihrer Umgebung beginnen, stellen Sie sicher, dass Sie über Folgendes verfügen:
Richten Sie einen SageMaker HyperPod Trainium Slurm-Cluster ein.
Ein gemeinsam genutzter Speicherort. Es kann sich um ein FSx Amazon-Dateisystem oder ein NFS-System handeln, auf das von den Clusterknoten aus zugegriffen werden kann.
Daten in einem der folgenden Formate:
JSON
JSONGZ (komprimiertes JSON)
ARROW
(Optional) Sie benötigen ein HuggingFace Token, wenn Sie die Modellgewichte von HuggingFace für das Training oder die Feinabstimmung verwenden. Weitere Informationen zum Abrufen des Tokens finden Sie unter [Benutzerzugriffstoken](https://huggingface.co/docs/hub/en/security-tokens).
## Einrichten der Trainium-Umgebung auf dem Slurm-Cluster
Um einen Trainingsjob auf einem Slurm-Cluster zu initiieren, führen Sie die folgenden Schritte aus:
+ Verbinden Sie sich per SSH mit dem Hauptknoten Ihres Slurm-Clusters.
+ Nachdem Sie sich angemeldet haben, richten Sie die Neuron-Umgebung ein. Informationen zur Einrichtung von Neuron finden Sie unter [Schritte zum Einrichten von Neuron](https://awsdocs-neuron.readthedocs-hosted.com/en/latest/libraries/nxd-training/tutorials/hf_llama3_8B_SFT.html#setting-up-the-environment). Wir empfehlen, sich auf die Deep-Learning-AMIs zu verlassen, die mit den Treibern von Neuron vorinstalliert sind, z. B. [Ubuntu 20 mit DLAMI Pytorch](https://awsdocs-neuron.readthedocs-hosted.com/en/latest/general/setup/neuron-setup/pytorch/neuronx/ubuntu/torch-neuronx-ubuntu20-pytorch-dlami.html#setup-torch-neuronx-ubuntu20-dlami-pytorch)
+ Klonen Sie das SageMaker HyperPod Rezept-Repository an einen gemeinsam genutzten Speicherort im Cluster. Der gemeinsam genutzte Speicherort kann ein FSx Amazon-Dateisystem oder ein NFS-System sein, auf das von den Clusterknoten aus zugegriffen werden kann.
```
git clone --recursive https://github.com/aws/sagemaker-hyperpod-recipes.git
cd sagemaker-hyperpod-recipes
pip3 install -r requirements.txt
```
+ Gehen Sie das folgende Tutorial durch: [HuggingFace Llama3-8B](https://awsdocs-neuron.readthedocs-hosted.com/en/latest/libraries/nxd-training/tutorials/hf_llama3_8B_pretraining.html#) Pretraining
+ Bereiten Sie eine Modellkonfiguration vor. Die im Neuron-Repo verfügbaren Modellkonfigurationen. Die in diesem Tutorial verwendete Modellkonfiguration finden Sie unter [llama3 8b-Modellkonfiguration](https://github.com/aws-neuron/neuronx-distributed/blob/main/examples/training/llama/tp_zero1_llama_hf_pretrain/8B_config_llama3/config.json)
## Starten des Trainingsjobs in Trainium
Um einen Trainingsjob in Trainium zu starten, geben Sie eine Cluster-Konfiguration und ein Neuron-Rezept an. Um beispielsweise einen lama3 8b-Vortrainigsjob in Trainium zu starten, legen Sie das Startskript `launcher_scripts/llama/run_hf_llama3_8b_seq8k_trn1x4_pretrain.sh` wie folgt fest:
+ `MODEL_CONFIG`: Die Modellkonfiguration aus dem Abschnitt „Umgebungseinrichtung“
+ (Optional) Sie können das HuggingFace Token angeben, wenn Sie vorab trainierte Gewichte von benötigen, HuggingFace indem Sie das folgende Schlüssel-Wert-Paar festlegen:
```
recipes.model.hf_access_token=
```
```
#!/bin/bash
#Users should set up their cluster type in /recipes_collection/config.yaml
SAGEMAKER_TRAINING_LAUNCHER_DIR=${SAGEMAKER_TRAINING_LAUNCHER_DIR:-"$(pwd)"}
COMPILE=0
TRAIN_DIR="${TRAIN_DIR}" # Location of training dataset
MODEL_CONFIG="${MODEL_CONFIG}" # Location of config.json for the model
HYDRA_FULL_ERROR=1 python3 "${SAGEMAKER_TRAINING_LAUNCHER_DIR}/main.py" \
base_results_dir="${SAGEMAKER_TRAINING_LAUNCHER_DIR}/results" \
instance_type="trn1.32xlarge" \
recipes.run.compile="$COMPILE" \
recipes.run.name="hf-llama3-8b" \
recipes.trainer.num_nodes=4 \
recipes=training/llama/hf_llama3_8b_seq8k_trn1x4_pretrain \
recipes.data.train_dir="$TRAIN_DIR" \
recipes.model.model_config="$MODEL_CONFIG"
```
Um den Trainingsjob zu starten, führen Sie bitte den folgenden Befehl aus:
```
bash launcher_scripts/llama/run_hf_llama3_8b_seq8k_trn1x4_pretrain.sh
```
Weitere Informationen zur Konfiguration des Slurm-Clusters finden Sie unter [Einen Trainingsjob auf HyperPod Slurm ausführen](cluster-specific-configurations-run-training-job-hyperpod-slurm.md).
# HyperPod Tutorial zum Slurm-Cluster DPO (GPU)
Das folgende Tutorial richtet die Slurm-Umgebung ein und startet einen Job von Direct Preference Optimization (DPO) auf einem Lama-Modell mit 8 Milliarden Parametern.
**Voraussetzungen**
Bevor Sie mit der Einrichtung Ihrer Umgebung beginnen, stellen Sie sicher, dass Sie über Folgendes verfügen:
HyperPod GPU-Slurm-Cluster einrichten
In Ihrem HyperPod Slurm-Cluster müssen Nvidia Enroot und Pyxis aktiviert sein (diese sind standardmäßig aktiviert).
Ein gemeinsam genutzter Speicherort. Es kann sich um ein FSx Amazon-Dateisystem oder ein NFS-System handeln, auf das von den Clusterknoten aus zugegriffen werden kann.
Ein tokenisierter binärer Präferenzdatensatz in einem der folgenden Formate:
JSON
JSONGZ (komprimiertes JSON)
ARROW
(Optional) Wenn du die vortrainierten Gewichte von einem Lama 3.2-Modell benötigst HuggingFace oder wenn du ein Lama 3.2-Modell trainierst, musst du dir das HuggingFace Token besorgen, bevor du mit dem Training beginnst. Weitere Informationen zum Abrufen des Tokens finden Sie unter [Benutzerzugriffstoken](https://huggingface.co/docs/hub/en/security-tokens).
## Richten Sie die HyperPod GPU-Slurm-Umgebung ein
Um einen Trainingsjob auf einem Slurm-Cluster zu initiieren, führen Sie die folgenden Schritte aus:
+ Verbinden Sie sich per SSH mit dem Hauptknoten Ihres Slurm-Clusters.
+ Nachdem Sie sich angemeldet haben, richten Sie die virtuelle Umgebung ein. Vergewissern Sie sich, dass Sie Python 3.9 oder höher verwenden.
```
#set up a virtual environment
python3 -m venv ${PWD}/venv
source venv/bin/activate
```
+ Klonen Sie die SageMaker HyperPod Rezepte und SageMaker HyperPod Adapter-Repositorys auf einen gemeinsam genutzten Speicherort. Der gemeinsam genutzte Speicherort kann ein FSx Amazon-Dateisystem oder ein NFS-System sein, auf das von den Clusterknoten aus zugegriffen werden kann.
```
git clone https://github.com/aws/sagemaker-hyperpod-training-adapter-for-nemo.git
git clone --recursive https://github.com/aws/sagemaker-hyperpod-recipes.git
cd sagemaker-hyperpod-recipes
pip3 install -r requirements.txt
```
+ Erstellen Sie mit Enroot eine Squash-Datei. Die aktuelle Version des SMP-Containers finden Sie unter [Versionshinweise für die SageMaker Modellparallelitätsbibliothek](model-parallel-release-notes.md). Weitere Informationen zur Verwendung der Enroot-Datei finden Sie unter [Erstellen eines AWS optimierten Nemo-Launcher-Images](https://github.com/aws-samples/awsome-distributed-training/tree/main/3.test_cases/2.nemo-launcher#2-build-aws-optimized-nemo-launcher-image).
```
REGION=""
IMAGE="658645717510.dkr.ecr.${REGION}.amazonaws.com/smdistributed-modelparallel:2.4.1-gpu-py311-cu121"
aws ecr get-login-password --region ${REGION} | docker login --username AWS --password-stdin 658645717510.dkr.ecr.${REGION}.amazonaws.com
enroot import -o $PWD/smdistributed-modelparallel.sqsh dockerd://${IMAGE}
mv $PWD/smdistributed-modelparallel.sqsh "/fsx/"
```
+ Um die Enroot-Squash-Datei zum Starten des Trainings zu verwenden, ändern Sie die `recipes_collection/config.yaml`-Datei anhand des folgenden Beispiels.
```
container: /fsx/path/to/your/smdistributed-modelparallel.sqsh
```
## Starten eines Trainingsjobs
Um einen DPO-Job für das Llama-Modell mit 8 Milliarden Parametern und einer Sequenzlänge von 8192 auf einem einzelnen Slurm-Rechenknoten zu starten, setzen Sie das Startskript, `launcher_scripts/llama/run_hf_llama3_8b_seq8k_gpu_dpo.sh`, auf Folgendes:
+ `IMAGE`: Der Container aus dem Abschnitt „Umgebungseinrichtung“.
+ `HF_MODEL_NAME_OR_PATH`: Definieren Sie den Namen oder den Pfad der vortrainierten Gewichte im Parameter hf\$1model\$1name\$1or\$1path des Rezepts.
+ (Optional) Sie können das HuggingFace Token angeben, wenn Sie vorab trainierte Gewichtungen von benötigen, HuggingFace indem Sie das folgende Schlüssel-Wert-Paar festlegen:
```
recipes.model.hf_access_token=${HF_ACCESS_TOKEN}
```
**Anmerkung**
Das für DPO in dieser Einrichtung verwendete Referenzmodell wird automatisch aus dem trainierten Basismodell abgeleitet (es wird kein separates Referenzmodell explizit definiert). DPO-spezifische Hyperparameter sind mit den folgenden Standardwerten vorkonfiguriert:
`beta`: 0,1 (steuert die Stärke der KL-Divergenz-Regularisierung)
`label_smoothing`: 0,0 (keine Glättung auf Präferenzbezeichnungen angewendet)
```
recipes.dpo.beta=${BETA}
recipes.dpo.label_smoothing=${LABEL_SMOOTHING}
```
```
#!/bin/bash
IMAGE="${YOUR_IMAGE}"
SAGEMAKER_TRAINING_LAUNCHER_DIR="${SAGEMAKER_TRAINING_LAUNCHER_DIR:-${PWD}}"
TRAIN_DIR="${YOUR_TRAIN_DIR}" # Location of training dataset
VAL_DIR="${YOUR_VAL_DIR}" # Location of validation dataset
# experiment output directory
EXP_DIR="${YOUR_EXP_DIR}"
HF_ACCESS_TOKEN="${YOUR_HF_TOKEN}"
HF_MODEL_NAME_OR_PATH="${HF_MODEL_NAME_OR_PATH}"
BETA="${BETA}"
LABEL_SMOOTHING="${LABEL_SMOOTHING}"
# Add hf_model_name_or_path and turn off synthetic_data
HYDRA_FULL_ERROR=1 python3 ${SAGEMAKER_TRAINING_LAUNCHER_DIR}/main.py \
recipes=fine-tuning/llama/hf_llama3_8b_seq8k_gpu_dpo \
base_results_dir=${SAGEMAKER_TRAINING_LAUNCHER_DIR}/results \
recipes.run.name="hf_llama3_dpo" \
recipes.exp_manager.exp_dir="$EXP_DIR" \
recipes.model.data.train_dir="$TRAIN_DIR" \
recipes.model.data.val_dir="$VAL_DIR" \
recipes.model.hf_model_name_or_path="$HF_MODEL_NAME_OR_PATH" \
container="${IMAGE}" \
+cluster.container_mounts.0="/fsx:/fsx" \
recipes.model.hf_access_token="${HF_ACCESS_TOKEN}" \
recipes.dpo.enabled=true \
recipes.dpo.beta="${BETA}" \
recipes.dpo.label_smoothing="${LABEL_SMOOTHING}$" \
```
Nachdem Sie alle erforderlichen Parameter im vorherigen Skript konfiguriert haben, können Sie den Trainingsjob starten, indem Sie ihn ausführen.
```
bash launcher_scripts/llama/run_hf_llama3_8b_seq8k_gpu_dpo.sh
```
Weitere Informationen zur Konfiguration des Slurm-Clusters finden Sie unter [Einen Trainingsjob auf HyperPod Slurm ausführen](cluster-specific-configurations-run-training-job-hyperpod-slurm.md).
# HyperPod Slurm-Cluster Left-LoRa-Tutorial (GPU)
Das folgende Tutorial richtet die Slurm-Umgebung ein und startet einen PEFT-Job (Parameter-Efficient Fine-Tuning) auf einem Lama-Modell mit 8 Milliarden Parametern.
**Voraussetzungen**
Bevor Sie mit der Einrichtung Ihrer Umgebung beginnen, stellen Sie sicher, dass Sie über Folgendes verfügen:
GPU-Slurm-Cluster einrichten HyperPod
In Ihrem HyperPod Slurm-Cluster müssen Nvidia Enroot und Pyxis aktiviert sein (diese sind standardmäßig aktiviert).
Ein gemeinsam genutzter Speicherort. Es kann sich um ein FSx Amazon-Dateisystem oder ein NFS-System handeln, auf das von den Clusterknoten aus zugegriffen werden kann.
Daten in einem der folgenden Formate:
JSON
JSONGZ (komprimiertes JSON)
ARROW
(Optional) Wenn du die vortrainierten Gewichte von einem Lama 3.2-Modell benötigst HuggingFace oder wenn du ein Lama 3.2-Modell trainierst, musst du dir das HuggingFace Token besorgen, bevor du mit dem Training beginnst. Weitere Informationen zum Abrufen des Tokens finden Sie unter [Benutzerzugriffstoken](https://huggingface.co/docs/hub/en/security-tokens).
## Richten Sie die HyperPod GPU-Slurm-Umgebung ein
Um einen Trainingsjob auf einem Slurm-Cluster zu initiieren, führen Sie die folgenden Schritte aus:
+ Verbinden Sie sich per SSH mit dem Hauptknoten Ihres Slurm-Clusters.
+ Nachdem Sie sich angemeldet haben, richten Sie die virtuelle Umgebung ein. Vergewissern Sie sich, dass Sie Python 3.9 oder höher verwenden.
```
#set up a virtual environment
python3 -m venv ${PWD}/venv
source venv/bin/activate
```
+ Klonen Sie die SageMaker HyperPod Rezepte und SageMaker HyperPod Adapter-Repositorys auf einen gemeinsam genutzten Speicherort. Der gemeinsam genutzte Speicherort kann ein FSx Amazon-Dateisystem oder ein NFS-System sein, auf das von den Clusterknoten aus zugegriffen werden kann.
```
git clone https://github.com/aws/sagemaker-hyperpod-training-adapter-for-nemo.git
git clone --recursive https://github.com/aws/sagemaker-hyperpod-recipes.git
cd sagemaker-hyperpod-recipes
pip3 install -r requirements.txt
```
+ Erstellen Sie mit Enroot eine Squash-Datei. Die aktuelle Version des SMP-Containers finden Sie unter [Versionshinweise für die SageMaker Modellparallelitätsbibliothek](model-parallel-release-notes.md). Weitere Informationen zur Verwendung der Enroot-Datei finden Sie unter [Erstellen eines AWS optimierten Nemo-Launcher-Images](https://github.com/aws-samples/awsome-distributed-training/tree/main/3.test_cases/2.nemo-launcher#2-build-aws-optimized-nemo-launcher-image).
```
REGION=""
IMAGE="658645717510.dkr.ecr.${REGION}.amazonaws.com/smdistributed-modelparallel:2.4.1-gpu-py311-cu121"
aws ecr get-login-password --region ${REGION} | docker login --username AWS --password-stdin 658645717510.dkr.ecr.${REGION}.amazonaws.com
enroot import -o $PWD/smdistributed-modelparallel.sqsh dockerd://${IMAGE}
mv $PWD/smdistributed-modelparallel.sqsh "/fsx/"
```
+ Um die Enroot-Squash-Datei zum Starten des Trainings zu verwenden, ändern Sie die `recipes_collection/config.yaml`-Datei anhand des folgenden Beispiels.
```
container: /fsx/path/to/your/smdistributed-modelparallel.sqsh
```
## Starten eines Trainingsjobs
Um einen PEFT-Job für das Llama-Modell mit 8 Milliarden Parametern und einer Sequenzlänge von 8192 auf einem einzelnen Slurm-Rechenknoten zu starten, setzen Sie das Startskript, `launcher_scripts/llama/run_hf_llama3_8b_seq8k_gpu_lora.sh`, auf Folgendes:
+ `IMAGE`: Der Container aus dem Abschnitt „Umgebungseinrichtung“.
+ `HF_MODEL_NAME_OR_PATH`: Definieren Sie den Namen oder den Pfad der vortrainierten Gewichte im Parameter hf\$1model\$1name\$1or\$1path des Rezepts.
+ (Optional) Sie können das HuggingFace Token angeben, wenn Sie vorab trainierte Gewichtungen von benötigen, HuggingFace indem Sie das folgende Schlüssel-Wert-Paar festlegen:
```
recipes.model.hf_access_token=${HF_ACCESS_TOKEN}
```
```
#!/bin/bash
IMAGE="${YOUR_IMAGE}"
SAGEMAKER_TRAINING_LAUNCHER_DIR="${SAGEMAKER_TRAINING_LAUNCHER_DIR:-${PWD}}"
TRAIN_DIR="${YOUR_TRAIN_DIR}" # Location of training dataset
VAL_DIR="${YOUR_VAL_DIR}" # Location of validation dataset
# experiment output directory
EXP_DIR="${YOUR_EXP_DIR}"
HF_ACCESS_TOKEN="${YOUR_HF_TOKEN}"
HF_MODEL_NAME_OR_PATH="${YOUR_HF_MODEL_NAME_OR_PATH}"
# Add hf_model_name_or_path and turn off synthetic_data
HYDRA_FULL_ERROR=1 python3 ${SAGEMAKER_TRAINING_LAUNCHER_DIR}/main.py \
recipes=fine-tuning/llama/hf_llama3_8b_seq8k_gpu_lora \
base_results_dir=${SAGEMAKER_TRAINING_LAUNCHER_DIR}/results \
recipes.run.name="hf_llama3_lora" \
recipes.exp_manager.exp_dir="$EXP_DIR" \
recipes.model.data.train_dir="$TRAIN_DIR" \
recipes.model.data.val_dir="$VAL_DIR" \
recipes.model.hf_model_name_or_path="$HF_MODEL_NAME_OR_PATH" \
container="${IMAGE}" \
+cluster.container_mounts.0="/fsx:/fsx" \
recipes.model.hf_access_token="${HF_ACCESS_TOKEN}"
```
Nachdem Sie alle erforderlichen Parameter im vorherigen Skript konfiguriert haben, können Sie den Trainingsjob starten, indem Sie ihn ausführen.
```
bash launcher_scripts/llama/run_hf_llama3_8b_seq8k_gpu_lora.sh
```
Weitere Informationen zur Konfiguration des Slurm-Clusters finden Sie unter [Einen Trainingsjob auf HyperPod Slurm ausführen](cluster-specific-configurations-run-training-job-hyperpod-slurm.md).
# Tutorial zum Vortraining des Kubernetes-Cluster (GPU)
Es gibt zwei Möglichkeiten, einen Trainingsjob in einem GPU-Kubernetes-Cluster zu starten:
+ [(Empfohlen) Befehlszeilentool HyperPod ](https://github.com/aws/sagemaker-hyperpod-cli)
+ Der Style-Launcher NeMo
**Voraussetzungen**
Bevor Sie mit der Einrichtung Ihrer Umgebung beginnen, stellen Sie sicher, dass Sie über Folgendes verfügen:
Ein HyperPod GPU-Kubernetes-Cluster ist ordnungsgemäß eingerichtet.
Ein gemeinsam genutzter Speicherort. Es kann sich um ein FSx Amazon-Dateisystem oder ein NFS-System handeln, auf das von den Clusterknoten aus zugegriffen werden kann.
Daten in einem der folgenden Formate:
JSON
JSONGZ (komprimiertes JSON)
ARROW
(Optional) Sie benötigen ein HuggingFace Token, wenn Sie die Modellgewichte von HuggingFace für das Training oder die Feinabstimmung verwenden. Weitere Informationen zum Abrufen des Tokens finden Sie unter [Benutzerzugriffstoken](https://huggingface.co/docs/hub/en/security-tokens).
## Einrichten der GPU-Kubernetes-Umgebung
Gehen Sie zum Einrichten einer GPU-Kubernetes-Umgebung wie folgt vor:
+ Richten Sie die virtuelle Umgebung ein. Vergewissern Sie sich, dass Sie Python 3.9 oder höher verwenden.
```
python3 -m venv ${PWD}/venv
source venv/bin/activate
```
+ Installieren Sie Abhängigkeiten mit einer der folgenden Methoden:
+ (Empfohlen): Methode des [HyperPod Befehlszeilentools](https://github.com/aws/sagemaker-hyperpod-cli):
```
# install HyperPod command line tools
git clone https://github.com/aws/sagemaker-hyperpod-cli
cd sagemaker-hyperpod-cli
pip3 install .
```
+ SageMaker HyperPod Methode für Rezepte:
```
# 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 und eksctl einrichten](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html)
+ [Helm installieren](https://helm.sh/docs/intro/install/)
+ Verbinden mit Ihrem Kubernetes-Cluster
```
aws eks update-kubeconfig --region "CLUSTER_REGION" --name "CLUSTER_NAME"
hyperpod connect-cluster --cluster-name "CLUSTER_NAME" [--region "CLUSTER_REGION"] [--namespace ]
```
## Starten Sie den Trainingsjob mit der SageMaker HyperPod CLI
Wir empfehlen, das SageMaker HyperPod Befehlszeilenschnittstellentool (CLI) zu verwenden, um Ihren Schulungsjob mit Ihren Konfigurationen einzureichen. Im folgenden Beispiel wird ein Trainingsjob für das Modell `hf_llama3_8b_seq16k_gpu_p5x16_pretrain` eingereicht.
+ `your_training_container`: Ein Deep-Learning-Container. Die aktuelle Version des SMP-Containers finden Sie unter [Versionshinweise für die SageMaker Modellparallelitätsbibliothek](model-parallel-release-notes.md).
+ (Optional) Sie können das HuggingFace Token angeben, wenn Sie vorab trainierte Gewichte von benötigen, HuggingFace indem Sie das folgende Schlüssel-Wert-Paar festlegen:
```
"recipes.model.hf_access_token": ""
```
```
hyperpod start-job --recipe training/llama/hf_llama3_8b_seq16k_gpu_p5x16_pretrain \
--persistent-volume-claims fsx-claim:data \
--override-parameters \
'{
"recipes.run.name": "hf-llama3-8b",
"recipes.exp_manager.exp_dir": "/data/",
"container": "658645717510.dkr.ecr..amazonaws.com/smdistributed-modelparallel:2.4.1-gpu-py311-cu121",
"recipes.model.data.train_dir": "",
"recipes.model.data.val_dir": "",
"cluster": "k8s",
"cluster_type": "k8s"
}'
```
Nachdem Sie einen Trainingsjob eingereicht haben, können Sie mit dem folgenden Befehl überprüfen, ob die Übermittlung erfolgreich war.
```
kubectl get pods
NAME READY STATUS RESTARTS AGE
hf-llama3--worker-0 0/1 running 0 36s
```
Wenn der `STATUS` `PENDING` oder `ContainerCreating` lautet, führen Sie den folgenden Befehl aus, um weitere Informationen zu erhalten.
```
kubectl describe pod name_of_pod
```
Nachdem der Job-`STATUS` zu `Running` geändert wurde, können Sie das Protokoll mit dem folgenden Befehl überprüfen.
```
kubectl logs name_of_pod
```
Der `STATUS` wird zu `Completed`, wenn Sie `kubectl get pods` ausführen.
## Starten des Trainingsjobs mit dem Launcher für Rezepte
Alternativ kannst du die SageMaker HyperPod Rezepte verwenden, um deinen Ausbildungsjob einzureichen. Die Verwendung der Rezepte beinhaltet die Aktualisierung von `k8s.yaml`, `config.yaml` und Ausführung des Startskripts.
+ Aktualisieren Sie in `k8s.yaml` den Code `persistent_volume_claims`. Es fügt den FSx Amazon-Claim dem `/data` Verzeichnis jedes Computer-Pods hinzu
```
persistent_volume_claims:
- claimName: fsx-claim
mountPath: data
```
+ In `config.yaml` aktualisieren Sie `repo_url_or_path` unter `git`.
```
git:
repo_url_or_path:
branch: null
commit: null
entry_script: null
token: null
```
+ Aktualisieren: `launcher_scripts/llama/run_hf_llama3_8b_seq16k_gpu_p5x16_pretrain.sh`
+ `your_contrainer`: Ein Deep-Learning-Container. Die aktuelle Version des SMP-Containers finden Sie unter [Versionshinweise für die SageMaker Modellparallelitätsbibliothek](model-parallel-release-notes.md).
+ (Optional) Sie können das HuggingFace Token angeben, wenn Sie vorab trainierte Gewichte von benötigen, HuggingFace indem Sie das folgende Schlüssel-Wert-Paar festlegen:
```
recipes.model.hf_access_token=
```
```
#!/bin/bash
#Users should setup their cluster type in /recipes_collection/config.yaml
REGION=""
IMAGE="658645717510.dkr.ecr.${REGION}.amazonaws.com/smdistributed-modelparallel:2.4.1-gpu-py311-cu121"
SAGEMAKER_TRAINING_LAUNCHER_DIR=${SAGEMAKER_TRAINING_LAUNCHER_DIR:-"$(pwd)"}
EXP_DIR="" # Location to save experiment info including logging, checkpoints, ect
TRAIN_DIR="" # Location of training dataset
VAL_DIR="" # Location of talidation dataset
HYDRA_FULL_ERROR=1 python3 "${SAGEMAKER_TRAINING_LAUNCHER_DIR}/main.py" \
recipes=training/llama/hf_llama3_8b_seq8k_gpu_p5x16_pretrain \
base_results_dir="${SAGEMAKER_TRAINING_LAUNCHER_DIR}/results" \
recipes.run.name="hf-llama3" \
recipes.exp_manager.exp_dir="$EXP_DIR" \
cluster=k8s \
cluster_type=k8s \
container="${IMAGE}" \
recipes.model.data.train_dir=$TRAIN_DIR \
recipes.model.data.val_dir=$VAL_DIR
```
+ Starten eines Trainingsjobs
```
bash launcher_scripts/llama/run_hf_llama3_8b_seq16k_gpu_p5x16_pretrain.sh
```
Nachdem Sie den Trainingsjob eingereicht haben, können Sie mit dem folgenden Befehl überprüfen, ob die Übermittlung erfolgreich war.
```
kubectl get pods
```
```
NAME READY STATUS RESTARTS AGE
hf-llama3--worker-0 0/1 running 0 36s
```
Wenn der `STATUS` `PENDING` oder `ContainerCreating` lautet, führen Sie den folgenden Befehl aus, um weitere Informationen zu erhalten.
```
kubectl describe pod
```
Nachdem der Job-`STATUS` zu `Running` geändert wurde, können Sie das Protokoll mit dem folgenden Befehl überprüfen.
```
kubectl logs name_of_pod
```
Der `STATUS` wechselt zu `Completed`, wenn Sie `kubectl get pods` ausführen.
Weitere Informationen zur Konfiguration des k8s-Clusters finden Sie unter [Einen Trainingsjob auf HyperPod k8s ausführen](cluster-specific-configurations-run-training-job-hyperpod-k8s.md).
# Tutorial zum Vortraining des Trainium-Kubernetes-Clusters
Sie können eine der folgenden Methoden verwenden, um einen Trainingsjob in einem Trainium-Kubernetes-Cluster zu starten.
+ [(Empfohlen) Befehlszeilentool HyperPod ](https://github.com/aws/sagemaker-hyperpod-cli)
+ Der Style-Launcher NeMo
**Voraussetzungen**
Bevor Sie mit der Einrichtung Ihrer Umgebung beginnen, stellen Sie sicher, dass Sie über Folgendes verfügen:
Richten Sie einen HyperPod Trainium Kubernetes-Cluster ein
Ein gemeinsam genutzter Speicherort, bei dem es sich um ein FSx Amazon-Dateisystem oder ein NFS-System handeln kann, auf das von den Clusterknoten aus zugegriffen werden kann.
Daten in einem der folgenden Formate:
JSON
JSONGZ (komprimiertes JSON)
ARROW
(Optional) Sie benötigen ein HuggingFace Token, wenn Sie die Modellgewichte von HuggingFace für das Training oder die Feinabstimmung verwenden. Weitere Informationen zum Abrufen des Tokens finden Sie unter [Benutzerzugriffstoken](https://huggingface.co/docs/hub/en/security-tokens).
## Einrichten Ihrer Trainium-Kubernetes-Umgebung
Gehen Sie zum Einrichten einer Trainium-Kubernetes-Umgebung wie folgt vor:
1. **Führen Sie die Schritte im folgenden Tutorial aus: [HuggingFace Llama3-8B Pretraining](https://awsdocs-neuron.readthedocs-hosted.com/en/latest/libraries/nxd-training/tutorials/hf_llama3_8B_pretraining.html#download-the-dataset), beginnend mit Datensatz herunterladen.**
1. Bereiten Sie eine Modellkonfiguration vor. Sie sind im Neuron-Repo verfügbar. Für dieses Tutorial können Sie die llama3 8b-Modellkonfiguration verwenden.
1. Einrichtung der virtuellen Umgebung. Vergewissern Sie sich, dass Sie Python 3.9 oder höher verwenden.
```
python3 -m venv ${PWD}/venv
source venv/bin/activate
```
1. Installieren der Abhängigkeiten
+ (Empfohlen) Verwenden Sie das folgende Befehlszeilentool HyperPod
```
# install HyperPod command line tools
git clone https://github.com/aws/sagemaker-hyperpod-cli
cd sagemaker-hyperpod-cli
pip3 install .
```
+ Wenn Sie SageMaker HyperPod Rezepte verwenden, geben Sie Folgendes an
```
# 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. [kubectl und eksctl einrichten](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html)
1. [Helm installieren](https://helm.sh/docs/intro/install/)
1. Verbinden mit Ihrem Kubernetes-Cluster
```
aws eks update-kubeconfig --region "${CLUSTER_REGION}" --name "${CLUSTER_NAME}"
hyperpod connect-cluster --cluster-name "${CLUSTER_NAME}" [--region "${CLUSTER_REGION}"] [--namespace ]
```
1. Container: Der [Neuron-Container](https://github.com/aws-neuron/deep-learning-containers?tab=readme-ov-file#pytorch-training-neuronx)
## Starten Sie den Trainingsjob mit der SageMaker HyperPod CLI
Wir empfehlen, das SageMaker HyperPod Befehlszeilenschnittstellentool (CLI) zu verwenden, um Ihren Schulungsjob mit Ihren Konfigurationen einzureichen. Im folgenden Beispiel wird ein Trainingsjob für das `hf_llama3_8b_seq8k_trn1x4_pretrain`-Trainium-Modell eingereicht.
+ `your_neuron_container`: Der [Neuron-Container](https://github.com/aws-neuron/deep-learning-containers?tab=readme-ov-file#pytorch-training-neuronx).
+ `your_model_config`: Die Modellkonfiguration aus dem Abschnitt „Umgebungseinrichtung“
+ (Optional) Sie können das HuggingFace Token angeben, wenn Sie vorab trainierte Gewichte von benötigen, HuggingFace indem Sie das folgende Schlüssel-Wert-Paar festlegen:
```
"recipes.model.hf_access_token": ""
```
```
hyperpod start-job --recipe training/llama/hf_llama3_8b_seq8k_trn1x4_pretrain \
--persistent-volume-claims fsx-claim:data \
--override-parameters \
'{
"cluster": "k8s",
"cluster_type": "k8s",
"container": "",
"recipes.run.name": "hf-llama3",
"recipes.run.compile": 0,
"recipes.model.model_config": "",
"instance_type": "trn1.32xlarge",
"recipes.data.train_dir": ""
}'
```
Nachdem Sie einen Trainingsjob eingereicht haben, können Sie mit dem folgenden Befehl überprüfen, ob die Übermittlung erfolgreich war.
```
kubectl get pods
NAME READY STATUS RESTARTS AGE
hf-llama3--worker-0 0/1 running 0 36s
```
Wenn der `STATUS` `PENDING` oder `ContainerCreating` lautet, führen Sie den folgenden Befehl aus, um weitere Informationen zu erhalten.
```
kubectl describe pod name_of_pod
```
Nachdem der Job-`STATUS` zu `Running` geändert wurde, können Sie das Protokoll mit dem folgenden Befehl überprüfen.
```
kubectl logs name_of_pod
```
Der `STATUS` wechselt zu `Completed`, wenn Sie `kubectl get pods` ausführen.
## Starten des Trainingsjobs mit dem Launcher für Rezepte
Alternativ kannst du SageMaker HyperPod Rezepte verwenden, um deinen Ausbildungsjob einzureichen. Um den Trainingsjob mithilfe eines Rezepts einzureichen, aktualisieren Sie `k8s.yaml` und `config.yaml`. Führen Sie das Bash-Skript für das Modell aus, um es zu starten.
+ Aktualisieren Sie in persistent\$1volume\$1claims`k8s.yaml`, um den FSx Amazon-Claim im Verzeichnis /data in den Rechenknoten einzuhängen
```
persistent_volume_claims:
- claimName: fsx-claim
mountPath: data
```
+ scripts/llama/runAktualisieren Sie launcher\$1 \$1hf\$1llama3\$18b\$1seq8k\$1trn1x4\$1pretrain.sh
+ `your_neuron_contrainer`: Der Container aus dem Abschnitt „Umgebungseinrichtung“.
+ `your_model_config`: Die Modellkonfiguration aus dem Abschnitt „Umgebungseinrichtung“
(Optional) Sie können das HuggingFace Token bereitstellen, wenn Sie vorab trainierte Gewichte von benötigen, HuggingFace indem Sie das folgende Schlüssel-Wert-Paar festlegen:
```
recipes.model.hf_access_token=
```
```
#!/bin/bash
#Users should set up their cluster type in /recipes_collection/config.yaml
IMAGE=""
MODEL_CONFIG=""
SAGEMAKER_TRAINING_LAUNCHER_DIR=${SAGEMAKER_TRAINING_LAUNCHER_DIR:-"$(pwd)"}
TRAIN_DIR="" # Location of training dataset
VAL_DIR="" # Location of talidation dataset
HYDRA_FULL_ERROR=1 python3 "${SAGEMAKER_TRAINING_LAUNCHER_DIR}/main.py" \
recipes=training/llama/hf_llama3_8b_seq8k_trn1x4_pretrain \
base_results_dir="${SAGEMAKER_TRAINING_LAUNCHER_DIR}/results" \
recipes.run.name="hf-llama3-8b" \
instance_type=trn1.32xlarge \
recipes.model.model_config="$MODEL_CONFIG" \
cluster=k8s \
cluster_type=k8s \
container="${IMAGE}" \
recipes.data.train_dir=$TRAIN_DIR \
recipes.data.val_dir=$VAL_DIR
```
+ Starten des Jobs
```
bash launcher_scripts/llama/run_hf_llama3_8b_seq8k_trn1x4_pretrain.sh
```
Nachdem Sie einen Trainingsjob eingereicht haben, können Sie mit dem folgenden Befehl überprüfen, ob die Übermittlung erfolgreich war.
```
kubectl get pods
NAME READY STATUS RESTARTS AGE
hf-llama3--worker-0 0/1 running 0 36s
```
Wenn der `STATUS` `PENDING` oder `ContainerCreating` lautet, führen Sie den folgenden Befehl aus, um weitere Informationen zu erhalten.
```
kubectl describe pod name_of_pod
```
Nachdem der Job-STATUS zu „Laufend“ geändert wurde, können Sie das Protokoll mit dem folgenden Befehl überprüfen.
```
kubectl logs name_of_pod
```
Der `STATUS` wechselt zu `Completed`, wenn Sie `kubectl get pods` ausführen.
Weitere Informationen zur Konfiguration des k8s-Clusters finden Sie unter [Tutorial zum Vortraining des Trainium-Kubernetes-Clusters](#sagemaker-hyperpod-trainium-kubernetes-cluster-pretrain-tutorial).
# SageMaker Tutorial für Trainingsjobs vor dem Training (GPU)
Dieses Tutorial führt Sie durch den Prozess der Einrichtung und Ausführung eines Vortrainingsjobs mithilfe SageMaker von Trainingsaufträgen mit GPU-Instanzen.
+ So richten Sie Ihre Umgebung ein
+ Starten Sie einen Trainingsjob mithilfe von Rezepten SageMaker HyperPod
Bevor Sie beginnen, stellen Sie sicher, dass Sie die folgenden Voraussetzungen erfüllen.
**Voraussetzungen**
Bevor Sie mit der Einrichtung Ihrer Umgebung beginnen, stellen Sie sicher, dass Sie über Folgendes verfügen:
FSx Amazon-Dateisystem oder ein Amazon S3-Bucket, in den Sie die Daten laden und die Trainingsartefakte ausgeben können.
Ich habe ein Servicekontingent für 1x ml.p4d.24xlarge und 1x ml.p5.48xlarge auf Amazon AI angefordert. SageMaker Um eine Erhöhung der Servicekontingente zu beantragen, gehen Sie wie folgt vor:
Navigieren Sie in der AWS Service Quotas Quotas-Konsole zu AWS Services,
Wählen Sie **Amazon SageMaker AI**.
Wählen Sie eine ml.p4d.24xlarge- und eine ml.p5.48xlarge-Instance aus.
Erstellen Sie eine AWS Identity and Access Management(IAM-) Rolle mit den folgenden verwalteten Richtlinien, um SageMaker KI Berechtigungen zur Ausführung der Beispiele zu erteilen.
AmazonSageMakerFullAccess
Amazon EC2 FullAccess
Daten in einem der folgenden Formate:
JSON
JSONGZ (komprimiertes JSON)
ARROW
(Optional) Sie müssen sich einen HuggingFace Token besorgen, wenn Sie die Modellgewichte von vor dem Training oder HuggingFace zur Feinabstimmung verwenden. Weitere Informationen zum Abrufen des Tokens finden Sie unter [Benutzerzugriffstoken](https://huggingface.co/docs/hub/en/security-tokens).
## Einrichtung der Umgebung für SageMaker GPU-Trainingsjobs
Bevor Sie einen SageMaker Trainingsjob ausführen, konfigurieren Sie Ihre AWS Anmeldeinformationen und Ihre bevorzugte Region, indem Sie den `aws configure` Befehl ausführen. Als Alternative zum Befehl configure können Sie Ihre Anmeldeinformationen über Umgebungsvariablen wie `AWS_ACCESS_KEY_ID``AWS_SECRET_ACCESS_KEY`, und angeben. `AWS_SESSION_TOKEN.` Weitere Informationen finden Sie unter [SageMaker AI Python SDK](https://github.com/aws/sagemaker-python-sdk).
Wir empfehlen dringend, ein SageMaker KI-Jupyter-Notizbuch in SageMaker KI JupyterLab zu verwenden, um einen SageMaker Trainingsjob zu starten. Weitere Informationen finden Sie unter [SageMaker JupyterLab](studio-updated-jl.md).
+ (Optional) Richten Sie die virtuelle Umgebung und Abhängigkeiten ein. Wenn Sie ein Jupyter-Notizbuch in Amazon SageMaker Studio verwenden, können Sie diesen Schritt überspringen. Vergewissern Sie sich, dass Sie Python 3.9 oder höher verwenden.
```
# set up a virtual environment
python3 -m venv ${PWD}/venv
source venv/bin/activate
# install dependencies after git clone.
git clone --recursive git@github.com:aws/sagemaker-hyperpod-recipes.git
cd sagemaker-hyperpod-recipes
pip3 install -r requirements.txt
# Set the aws region.
aws configure set
```
+ Installieren Sie das SageMaker AI Python SDK
```
pip3 install --upgrade sagemaker
```
+ `Container`: Der GPU-Container wird automatisch vom SageMaker AI Python SDK festgelegt. Sie können auch Ihren eigenen Container bereitstellen.
**Anmerkung**
Wenn Sie einen multimodalen Trainingsjob mit Llama 3.2 ausführen, muss die `transformers`-Version `4.45.2 ` oder höher sein.
`source_dir`Nur `transformers==4.45.2` an `requirements.txt` in anhängen, wenn Sie das SageMaker AI Python SDK verwenden. Hängen Sie es beispielsweise an, wenn Sie es in einem Notizbuch in SageMaker AI verwenden. JupyterLab
Wenn Sie HyperPod Rezepte verwenden, um mithilfe des Clustertyps zu starten`sm_jobs`, erfolgt dies automatisch.
## Starten des Trainingsjobs mit einem Jupyter Notebook
Sie können den folgenden Python-Code verwenden, um einen SageMaker Trainingsjob mit Ihrem Rezept auszuführen. Es nutzt den PyTorch Schätzer aus dem [SageMaker AI Python SDK, um das](https://sagemaker.readthedocs.io/en/stable/) Rezept einzureichen. Im folgenden Beispiel wird das Rezept llama3-8b auf der AI-Trainingsplattform gestartet. SageMaker
```
import os
import sagemaker,boto3
from sagemaker.debugger import TensorBoardOutputConfig
from sagemaker.pytorch import PyTorch
sagemaker_session = sagemaker.Session()
role = sagemaker.get_execution_role()
bucket = sagemaker_session.default_bucket()
output = os.path.join(f"s3://{bucket}", "output")
output_path = ""
overrides = {
"run": {
"results_dir": "/opt/ml/model",
},
"exp_manager": {
"exp_dir": "",
"explicit_log_dir": "/opt/ml/output/tensorboard",
"checkpoint_dir": "/opt/ml/checkpoints",
},
"model": {
"data": {
"train_dir": "/opt/ml/input/data/train",
"val_dir": "/opt/ml/input/data/val",
},
},
}
tensorboard_output_config = TensorBoardOutputConfig(
s3_output_path=os.path.join(output, 'tensorboard'),
container_local_output_path=overrides["exp_manager"]["explicit_log_dir"]
)
estimator = PyTorch(
output_path=output_path,
base_job_name=f"llama-recipe",
role=role,
instance_type="ml.p5.48xlarge",
training_recipe="training/llama/hf_llama3_8b_seq8k_gpu_p5x16_pretrain",
recipe_overrides=recipe_overrides,
sagemaker_session=sagemaker_session,
tensorboard_output_config=tensorboard_output_config,
)
estimator.fit(inputs={"train": "s3 or fsx input", "val": "s3 or fsx input"}, wait=True)
```
Der obige Code erstellt ein PyTorch Schätzerobjekt mit dem Trainingsrezept und passt das Modell dann mithilfe der Methode an. `fit()` Verwenden Sie den Parameter training\$1recipe, um das Rezept anzugeben, das Sie für das Training verwenden möchten.
**Anmerkung**
Wenn Sie einen multimodalen Trainingsjob mit Llama 3.2 ausführen, muss die Transformers-Version 4.45.2 oder höher sein.
`source_dir`Nur `transformers==4.45.2` an `requirements.txt` in anhängen, wenn Sie das SageMaker AI Python SDK direkt verwenden. Beispielsweise müssen Sie die Version an die Textdatei anfügen, wenn Sie ein Jupyter Notebook verwenden.
Wenn Sie den Endpunkt für einen SageMaker Trainingsjob bereitstellen, müssen Sie den Bild-URI angeben, den Sie verwenden. Wenn Sie den Image-URI nicht angeben, verwendet die Schätzfunktion das Trainings-Image als Image für die Bereitstellung. Die bereitgestellten Trainings-Images enthalten nicht die Abhängigkeiten, die für Inferenz und Bereitstellung erforderlich sind. SageMaker HyperPod Im Folgenden finden Sie ein Beispiel dafür, wie ein Inferenz-Image für die Bereitstellung verwendet werden kann:
```
from sagemaker import image_uris
container=image_uris.retrieve(framework='pytorch',region='us-west-2',version='2.0',py_version='py310',image_scope='inference', instance_type='ml.p4d.24xlarge')
predictor = estimator.deploy(initial_instance_count=1,instance_type='ml.p4d.24xlarge',image_uri=container)
```
**Anmerkung**
Die Ausführung des vorherigen Codes auf der Sagemaker-Notebook-Instanz benötigt möglicherweise mehr als die von KI bereitgestellten Standardspeicher von 5 GB. SageMaker JupyterLab Wenn Sie auf Probleme mit nicht verfügbarem Speicherplatz stoßen, erstellen Sie eine neue Notebook-Instance, in der Sie eine andere Notebook-Instance verwenden, und vergrößern Sie den Speicherplatz des Notebooks.
## Starten des Trainingsjobs mit dem Launcher für Rezepte
Aktualisieren Sie die `./recipes_collection/cluster/sm_jobs.yaml`-Datei wie folgt:
```
sm_jobs_config:
output_path:
tensorboard_config:
output_path:
container_logs_path: /opt/ml/output/tensorboard # Path to logs on the container
wait: True # Whether to wait for training job to finish
inputs: # Inputs to call fit with. Set either s3 or file_system, not both.
s3: # Dictionary of channel names and s3 URIs. For GPUs, use channels for train and validation.
train:
val: null
additional_estimator_kwargs: # All other additional args to pass to estimator. Must be int, float or string.
max_run: 180000
enable_remote_debug: True
recipe_overrides:
exp_manager:
explicit_log_dir: /opt/ml/output/tensorboard
data:
train_dir: /opt/ml/input/data/train
model:
model_config: /opt/ml/input/data/train/config.json
compiler_cache_url: ""
```
Aktualisieren Sie `./recipes_collection/config.yaml`, um `sm_jobs` im `cluster` und `cluster_type` anzugeben.
```
defaults:
- _self_
- cluster: sm_jobs # set to `slurm`, `k8s` or `sm_jobs`, depending on the desired cluster
- recipes: training/llama/hf_llama3_8b_seq8k_trn1x4_pretrain
cluster_type: sm_jobs # bcm, bcp, k8s or sm_jobs. If bcm, k8s or sm_jobs, it must match - cluster above.
```
Starten des Jobs mit dem folgenden Befehl
```
python3 main.py --config-path recipes_collection --config-name config
```
Weitere Informationen zur Konfiguration von SageMaker Trainingsjobs finden Sie unter Trainingsjobs ausführen SageMaker .
# Tutorial zur Vorbereitung von SageMaker Trainium-Schulungsaufträgen
Dieses Tutorial führt Sie durch den Prozess der Einrichtung und Ausführung eines Vorbereitungsjobs mithilfe von Schulungsaufträgen mit SageMaker Trainium-Instanzen. AWS
+ So richten Sie Ihre Umgebung ein
+ Starten eines Trainingsjobs
Bevor Sie beginnen, stellen Sie sicher, dass Sie die folgenden Voraussetzungen erfüllen.
**Voraussetzungen**
Bevor Sie mit der Einrichtung Ihrer Umgebung beginnen, stellen Sie sicher, dass Sie über Folgendes verfügen:
FSx Amazon-Dateisystem oder S3-Bucket, in den Sie die Daten laden und die Trainingsartefakte ausgeben können.
Fordern Sie ein Service-Kontingent für die `ml.trn1.32xlarge` Instance auf Amazon SageMaker AI an. Um eine Erhöhung der Servicekontingente zu beantragen, gehen Sie wie folgt vor:
Navigieren Sie zur AWS Service Quotas Quotas-Konsole.
Wählen Sie AWS Dienste aus.
Wählen Sie aus JupyterLab.
Geben Sie eine Instance für `ml.trn1.32xlarge` an.
Erstellen Sie eine AWS Identity and Access Management (IAM-) Rolle mit den `AmazonSageMakerFullAccess` und `AmazonEC2FullAccess` verwalteten Richtlinien. Diese Richtlinien gewähren Amazon SageMaker AI die Erlaubnis, die Beispiele auszuführen.
Daten in einem der folgenden Formate:
JSON
JSONGZ (komprimiertes JSON)
ARROW
(Optional) Wenn du die vorab trainierten Gewichte von einem Lama 3.2-Modell benötigst HuggingFace oder wenn du ein Lama 3.2-Modell trainierst, musst du dir das HuggingFace Token besorgen, bevor du mit dem Training beginnst. Weitere Informationen zum Abrufen des Tokens finden Sie unter [Benutzerzugriffstoken](https://huggingface.co/docs/hub/en/security-tokens).
## Richten Sie Ihre Umgebung für Trainingsjobs bei SageMaker Trainium ein
Bevor Sie einen SageMaker Trainingsjob ausführen, konfigurieren Sie mit dem `aws configure` Befehl Ihre AWS Anmeldeinformationen und Ihre bevorzugte Region. Als Alternative können Sie Ihre Anmeldeinformationen auch über Umgebungsvariablen wie `AWS_ACCESS_KEY_ID`, `AWS_SECRET_ACCESS_KEY` und `AWS_SESSION_TOKEN` angeben. Weitere Informationen finden Sie unter [SageMaker AI Python SDK](https://github.com/aws/sagemaker-python-sdk).
Wir empfehlen dringend, ein SageMaker KI-Jupyter-Notizbuch in SageMaker KI JupyterLab zu verwenden, um einen SageMaker Trainingsjob zu starten. Weitere Informationen finden Sie unter [SageMaker JupyterLab](studio-updated-jl.md).
+ (Optional) Wenn Sie das Jupyter-Notebook in Amazon SageMaker Studio verwenden, können Sie die Ausführung des folgenden Befehls überspringen. Stellen Sie sicher, dass Sie eine Version >= Python 3.9 verwenden.
```
# set up a virtual environment
python3 -m venv ${PWD}/venv
source venv/bin/activate
# install dependencies after git clone.
git clone --recursive git@github.com:aws/sagemaker-hyperpod-recipes.git
cd sagemaker-hyperpod-recipes
pip3 install -r requirements.txt
```
+ Installieren Sie das SageMaker AI Python SDK
```
pip3 install --upgrade sagemaker
```
+
+ Wenn Sie einen multimodalen Trainingsjob mit llama 3.2 ausführen, muss die `transformers`-Version `4.45.2` oder höher sein.
+ Hängen Sie `transformers==4.45.2` es nur an `requirements.txt` in source\$1dir an, wenn Sie das SageMaker AI Python SDK verwenden.
+ Wenn Sie HyperPod Rezepte zum Starten `sm_jobs` als Clustertyp verwenden, müssen Sie die Transformer-Version nicht angeben.
+ `Container`: Der Neuron-Container wird automatisch vom SageMaker AI Python SDK festgelegt.
## Starten des Trainingsjobs mit einem Jupyter Notebook
Sie können den folgenden Python-Code verwenden, um einen SageMaker Trainingsjob nach Ihrem Rezept auszuführen. Es nutzt den PyTorch Schätzer aus dem [SageMaker AI Python SDK, um das](https://sagemaker.readthedocs.io/en/stable/) Rezept einzureichen. Im folgenden Beispiel wird das Rezept llama3-8b als KI-Trainingsjob gestartet. SageMaker
+ `compiler_cache_url`: Cache, der zum Speichern der kompilierten Artefakte verwendet wird, z. B. ein Amazon-S3-Artefakt.
```
import os
import sagemaker,boto3
from sagemaker.debugger import TensorBoardOutputConfig
from sagemaker.pytorch import PyTorch
sagemaker_session = sagemaker.Session()
role = sagemaker.get_execution_role()
recipe_overrides = {
"run": {
"results_dir": "/opt/ml/model",
},
"exp_manager": {
"explicit_log_dir": "/opt/ml/output/tensorboard",
},
"data": {
"train_dir": "/opt/ml/input/data/train",
},
"model": {
"model_config": "/opt/ml/input/data/train/config.json",
},
"compiler_cache_url": ""
}
tensorboard_output_config = TensorBoardOutputConfig(
s3_output_path=os.path.join(output, 'tensorboard'),
container_local_output_path=overrides["exp_manager"]["explicit_log_dir"]
)
estimator = PyTorch(
output_path=output_path,
base_job_name=f"llama-trn",
role=role,
instance_type="ml.trn1.32xlarge",
sagemaker_session=sagemaker_session,
training_recipe="training/llama/hf_llama3_70b_seq8k_trn1x16_pretrain",
recipe_overrides=recipe_overrides,
)
estimator.fit(inputs={"train": "your-inputs"}, wait=True)
```
Der obige Code erstellt ein PyTorch Schätzerobjekt mit dem Trainingsrezept und passt das Modell dann mithilfe der Methode an. `fit()` Verwenden Sie den Parameter `training_recipe`, um das Rezept anzugeben, das Sie für das Training verwenden möchten.
## Starten des Trainingsjobs mit dem Launcher für Rezepte
+ Aktualisieren: `./recipes_collection/cluster/sm_jobs.yaml`
+ compiler\$1cache\$1url: Die URL, die zum Speichern der Artefakte verwendet wurde. Es kann sich um eine Amazon-S3-URL handeln.
```
sm_jobs_config:
output_path:
wait: True
tensorboard_config:
output_path:
container_logs_path: /opt/ml/output/tensorboard # Path to logs on the container
wait: True # Whether to wait for training job to finish
inputs: # Inputs to call fit with. Set either s3 or file_system, not both.
s3: # Dictionary of channel names and s3 URIs. For GPUs, use channels for train and validation.
train:
val: null
additional_estimator_kwargs: # All other additional args to pass to estimator. Must be int, float or string.
max_run: 180000
image_uri:
enable_remote_debug: True
py_version: py39
recipe_overrides:
model:
exp_manager:
exp_dir:
data:
train_dir: /opt/ml/input/data/train
val_dir: /opt/ml/input/data/val
```
+ Aktualisieren: `./recipes_collection/config.yaml`
```
defaults:
- _self_
- cluster: sm_jobs
- recipes: training/llama/hf_llama3_8b_seq8k_trn1x4_pretrain
cluster_type: sm_jobs # bcm, bcp, k8s or sm_jobs. If bcm, k8s or sm_jobs, it must match - cluster above.
instance_type: ml.trn1.32xlarge
base_results_dir: ~/sm_job/hf_llama3_8B # Location to store the results, checkpoints and logs.
```
+ Starten des Jobs mit `main.py`
```
python3 main.py --config-path recipes_collection --config-name config
```
Weitere Informationen zur Konfiguration von SageMaker Trainingsjobs finden Sie unter[SageMaker Tutorial für Trainingsjobs vor dem Training (GPU)](sagemaker-hyperpod-gpu-sagemaker-training-jobs-pretrain-tutorial.md).
# Standardkonfigurationen
In diesem Abschnitt werden die wesentlichen Komponenten und Einstellungen beschrieben, die für die Initiierung und Anpassung Ihrer LLM-Schulungsprozesse (Large Language Model) erforderlich sind. SageMaker HyperPod Dieser Abschnitt behandelt die wichtigsten Repositorys, Konfigurationsdateien und Rezeptstrukturen, die die Grundlage Ihrer Trainingsjobs bilden. Das Verständnis dieser Standardkonfigurationen ist entscheidend für die effektive Einrichtung und Verwaltung Ihrer LLM-Trainings-Workflows, unabhängig davon, ob Sie vordefinierte Rezepte verwenden oder diese an Ihre spezifischen Anforderungen anpassen.
**Topics**
+ [GitHub Repositorien](github-repositories.md)
+ [Allgemeine Konfiguration](sagemaker-hyperpod-recipes-general-configuration.md)
# GitHub Repositorien
Um einen Trainingsjob zu starten, verwenden Sie Dateien aus zwei verschiedenen GitHub Repositorys:
+ [SageMaker HyperPod Rezepte](https://github.com/aws/sagemaker-hyperpod-recipes)
+ [SageMaker HyperPod Trainingsadapter für NeMo](https://github.com/aws/sagemaker-hyperpod-training-adapter-for-nemo)
Diese Repositorys enthalten wichtige Komponenten für die Initiierung, Verwaltung und Anpassung von Trainingsprozessen für große Sprachmodelle (LLMs). Sie verwenden die Skripte aus den Repositorys, um die Trainingsjobs für Sie LLMs einzurichten und auszuführen.
## HyperPod Rezept-Repository
Verwenden Sie das [SageMaker HyperPod Rezept-Repository](https://github.com/aws/sagemaker-hyperpod-recipes), um ein Rezept abzurufen.
1. `main.py`: Diese Datei dient als primärer Einstiegspunkt für die Einleitung des Prozesses, bei dem ein Schulungsjob entweder einem Cluster oder einem SageMaker Schulungsjob zugewiesen wird.
1. `launcher_scripts`: Dieses Verzeichnis enthält eine Sammlung häufig verwendeter Skripte, die den Trainingsprozess für verschiedene Large Language Models (LLMs) erleichtern sollen.
1. `recipes_collection`: Dieser Ordner enthält eine Zusammenstellung von vordefinierten LLM-Rezepten, die von den Entwicklern bereitgestellt wurden. Benutzer können diese Rezepte in Verbindung mit ihren benutzerdefinierten Daten nutzen, um LLM-Modelle zu trainieren, die auf ihre spezifischen Anforderungen zugeschnitten sind.
Sie verwenden die SageMaker HyperPod Rezepte, um Schulungs- oder Feinabstimmungsaufgaben zu starten. Unabhängig davon, welchen Cluster Sie verwenden, ist der Prozess zum Einreichen des Jobs derselbe. Sie können beispielsweise dasselbe Skript verwenden, um einen Job an einen Slurm- oder Kubernetes-Cluster zu senden. Der Launcher sendet einen Trainingsjob auf der Grundlage von drei Konfigurationsdateien aus:
1. Allgemeine Konfiguration (`config.yaml`): enthält allgemeine Einstellungen wie die Standardparameter oder Umgebungsvariablen, die im Trainingsjob verwendet werden.
1. Cluster-Konfiguration (Cluster): nur für Trainingsjobs, bei denen Cluster verwendet werden. Wenn Sie einen Trainingsjob an einen Kubernetes-Cluster senden, müssen Sie möglicherweise Informationen wie Volumen, Bezeichnung oder Neustartrichtlinie angeben. Für Slurm-Cluster müssen Sie möglicherweise den Slurm-Jobnamen angeben. Alle Parameter beziehen sich auf den spezifischen Cluster, den Sie verwenden.
1. Rezept (Rezepte): Rezepte enthalten die Einstellungen für Ihren Trainingsjob, z. B. die Modelltypen, den Grad der Aufteilung oder die Datensatzpfade. Beispielsweise können Sie Llama als Ihr Trainingsmodell festlegen und es mithilfe von Modell- oder Datenparallelismus-Techniken wie Fully Sharded Distributed Parallel (FSDP) auf acht Maschinen trainieren. Sie können auch verschiedene Checkpoint-Frequenzen oder Pfade für Ihren Trainingsjob angeben.
Nachdem Sie ein Rezept angegeben haben, führen Sie das Launcher-Skript aus, um einen end-to-end Trainingsjob auf einem Cluster auf der Grundlage der Konfigurationen über den `main.py` Einstiegspunkt anzugeben. Für jedes Rezept, das Sie verwenden, gibt es zugehörige Shell-Skripte im Ordner launch\$1scripts. Diese Beispiele führen Sie durch das Einreichen und Initiieren von Trainingsjobs. Die folgende Abbildung zeigt, wie ein SageMaker HyperPod Rezept-Launcher einen Trainingsjob auf der Grundlage des Vorhergehenden an einen Cluster weiterleitet. Derzeit basiert der SageMaker HyperPod Recipe Launcher auf dem Nvidia NeMo Framework Launcher. Weitere Informationen finden Sie im [NeMo Launcher-Handbuch](https://docs.nvidia.com/nemo-framework/user-guide/latest/overview.html).
![\[Diagramm, das den Arbeitsablauf des HyperPod Recipe Launchers veranschaulicht. Auf der linken Seite, in einem gestrichelten Feld, befinden sich drei Dateisymbole mit den Bezeichnungen „Recipe“, „config.yaml“ und „slurm.yaml oder k8s.yaml oder sm_job.yaml (Cluster-Konfiguration)“. Ein Pfeil zeigt von diesem Feld auf ein zentrales Feld mit der Bezeichnung "HyperPod Recipe Launcher“. Von diesem zentralen Feld aus zeigt ein weiterer Pfeil nach rechts auf „Training Job“, wobei „main.py“ über dem Pfeil steht.\]](http://docs.aws.amazon.com/de_de/sagemaker/latest/dg/images/sagemaker-hyperpod-recipe-launcher.png)
## HyperPod Rezeptadapter-Repository
Der SageMaker HyperPod Trainingsadapter ist ein Trainingsframework. Sie können damit den gesamten Lebenszyklus Ihrer Trainingsjobs verwalten. Verwenden Sie den Adapter, um das Vortraining oder die Feinabstimmung Ihrer Modelle auf mehrere Maschinen zu verteilen. Der Adapter verwendet verschiedene Parallelitätstechniken, um das Training zu verteilen. Er kümmert sich auch um die Implementierung und Verwaltung der Speicherung der Checkpoints. Weitere Details finden Sie unter [Erweiterte Einstellungen](cluster-specific-configurations-advanced-settings.md).
Verwenden Sie das [SageMaker HyperPod Rezeptadapter-Repository](https://github.com/aws/sagemaker-hyperpod-training-adapter-for-nemo), um den Rezeptadapter zu verwenden.
1. `src`: Dieses Verzeichnis enthält die Implementierung des Trainings für große Sprachmodelle (LLMs) und umfasst verschiedene Features wie Modellparallelität, Training mit gemischter Genauigkeit und Checkpoint-Verwaltung.
1. `examples`: Dieser Ordner enthält eine Sammlung von Beispielen, die zeigen, wie ein Einstiegspunkt für das Training eines LLM-Modells erstellt wird, und dient als praktischer Leitfaden für Benutzer.
# Allgemeine Konfiguration
Die Datei config.yaml spezifiziert das Trainingsrezept und den Cluster. Sie enthält auch Laufzeitkonfigurationen wie Umgebungsvariablen für den Trainingsjob.
```
defaults:
- _self_
- cluster: slurm
- recipes: training/llama/hf_llama3_8b_seq8192_gpu
instance_type: p5.48xlarge
git:
repo_url_or_path: null
branch: null
commit: null
entry_script: null
token: null
env_vars:
NCCL_DEBUG: WARN
```
Sie können die folgenden Parameter in `config.yaml` ändern:
1. `defaults`: Geben Sie Ihre Standardeinstellungen an, z. B. den Standardcluster oder Standardrezepte.
1. `instance_type`: Passen Sie den Instance-Typ von Amazon EC2 an den von Ihnen verwendeten Instance-Typ an.
1. `git`: Geben Sie den Speicherort des SageMaker HyperPod Rezeptadapter-Repositorys für den Trainingsjob an.
1. `env_vars`: Sie können die Umgebungsvariablen angeben, die an Ihren Laufzeit-Trainingsjob übergeben werden sollen. Sie können beispielsweise die Protokollierungsebene von NCCL anpassen, indem Sie die Umgebungsvariable NCCL\$1DEBUG angeben.
Das Rezept ist die Kernkonfiguration, die Ihre Trainingsjob-Architektur definiert. Diese Datei enthält viele wichtige Informationen für Ihren Trainingsjob, z. B.:
+ Ob Modellparallelität verwendet werden soll
+ Die Quelle Ihrer Datensätze
+ Training mit gemischter Präzision
+ Konfigurationen im Zusammenhang mit Checkpoints
Sie können die Rezepte unverändert verwenden. Sie können auch die folgenden Informationen verwenden, um sie zu ändern.
## run
Im Folgenden finden Sie die grundlegenden Informationen zum Ausführen Ihres Trainingsjobs.
```
run:
name: llama-8b
results_dir: ${base_results_dir}/${.name}
time_limit: "6-00:00:00"
model_type: hf
```
1. `name`: Geben Sie den Namen für Ihren Trainingsjob in der Konfigurationsdatei an.
1. `results_dir`: Sie können das Verzeichnis angeben, in dem die Ergebnisse Ihres Trainingsjobs gespeichert werden.
1. `time_limit`: Sie können eine maximale Trainingszeit für Ihren Trainingsjob festlegen, um zu verhindern, dass er zu lange Hardwareressourcen beansprucht.
1. `model_type`: Sie können den Modelltyp angeben, den Sie verwenden. Sie können beispielsweise angeben, `hf` ob Ihr Modell von stammt HuggingFace.
## exp\$1manager
Der exp\$1manager konfiguriert das Experiment. Mit dem exp\$1manager können Sie Felder wie das Ausgabeverzeichnis oder Checkpoint-Einstellungen angeben. Im folgenden Beispiel wird gezeigt, wie Sie den exp\$1manager konfigurieren können.
```
exp_manager:
exp_dir: null
name: experiment
create_tensorboard_logger: True
```
1. `exp_dir`: Das Experimentverzeichnis enthält die Standardausgabe- und Standardfehlerdateien für Ihren Trainingsjob. Standardmäßig verwendet es Ihr aktuelles Verzeichnis.
1. `name`: Der Name des Experiments, der zur Identifizierung Ihres Experiments unter dem exp\$1dir verwendet wurde.
1. `create_tensorboard_logger`: Geben Sie an `True``False`, ob der TensorBoard Logger aktiviert oder deaktiviert werden soll.
## Checkpointing
Wir unterstützen drei Arten von Checkpoints:
+ Automatisches Checkpointing
+ Manuelles Checkpointing
+ Vollständiges Checkpointing
### Automatisches Checkpointing
Wenn Sie Checkpoints speichern oder laden, die automatisch vom SageMaker HyperPod Rezeptadapter verwaltet werden, können Sie sie aktivieren`auto_checkpoint`. Legen Sie `enabled` auf `True` fest, um `auto_checkpoint` zu aktivieren. Sie können das automatische Checkpointing sowohl für das Training als auch für die Feinabstimmung verwenden. Sie können das automatische Checkpointing sowohl für gemeinsam genutzte Dateisysteme als auch für Amazon S3 verwenden.
```
exp_manager
checkpoint_dir: ${recipes.exp_manager.exp_dir}/checkpoints/
auto_checkpoint:
enabled: True
```
Beim automatischen Checkpoint wird das local\$1state\$1dict asynchron mit einem automatisch berechneten optimalen Speicherintervall gespeichert.
**Anmerkung**
In diesem Checkpointing-Modus unterstützt das automatische Speichern von Checkpoints kein erneutes Sharding zwischen Trainingsausführungen. Um den letzten automatisch gespeicherten Checkpoint wieder aufzunehmen, müssen Sie die gleichen Shard-Grade beibehalten. Sie müssen keine zusätzlichen Informationen angeben, um die automatische Wiederaufnahme zu aktivieren.
### Manuelles Checkpointing
Sie können `checkpoint_callback_params` ändern, um einen Zwischen-Checkpoint asynchron in shared\$1state\$1dict zu speichern. Beispielsweise können Sie die folgende Konfiguration festlegen, um alle 10 Schritte ein Sharded Checkpointing zu aktivieren und die letzten 3 Checkpoints zu behalten.
Mit Sharded Checkpointing können Sie die Shard-Grade zwischen den Trainingsausführungen ändern und den Checkpoint laden, indem Sie einstellen.
**Anmerkung**
Wenn es sich um eine PEFT-Feinabstimmung handelt, unterstützt Sharded Checkpointing Amazon S3 nicht.
Automatisches und manuelles Checkpointing schließen sich gegenseitig aus.
Nur Änderungen von FSDP-Shard- und Replikationsgraden sind zulässig.
```
exp_manager:
checkpoint_callback_params:
# Set save_top_k = 0 to disable sharded checkpointing
save_top_k: 3
every_n_train_steps: 10
monitor: "step"
mode: "max"
save_last: False
resume_from_checkpoint: ${recipes.exp_manager.exp_dir}/checkpoints/
```
Weitere Informationen zum Checkpointing finden Sie unter [Checkpointing mit SMP](model-parallel-core-features-v2-checkpoints.md).
### Vollständiges Checkpointing
Der exportierte Checkpoint full\$1state\$1dict kann für Inferenz oder Feinabstimmung verwendet werden. Sie können einen vollständigen Checkpoint über hf\$1model\$1name\$1or\$1path laden. In diesem Modus werden nur die Modellgewichte gespeichert.
Um das Modell full\$1state\$1dict zu exportieren, können Sie die folgenden Parameter festlegen.
**Anmerkung**
Derzeit wird vollständiges Checkpointing für Amazon-S3-Checkpointing nicht unterstützt. Sie können den S3-Pfad für `exp_manager.checkpoint_dir` nicht festlegen, wenn Sie das vollständige Checkpointing aktivieren. Sie können jedoch `exp_manager.export_full_model.final_export_dir` auf ein bestimmtes Verzeichnis in Ihrem lokalen Dateisystem setzen und gleichzeitig `exp_manager.checkpoint_dir` auf einen Amazon-S3-Pfad festlegen.
```
exp_manager:
export_full_model:
# Set every_n_train_steps = 0 to disable full checkpointing
every_n_train_steps: 0
save_last: True
final_export_dir : null
```
## model
Definieren Sie verschiedene Aspekte Ihrer Modellarchitektur und Ihres Trainingsprozesses. Dazu gehören Einstellungen für Modellparallelität, Präzision und Datenverarbeitung. Im Folgenden sind die wichtigsten Komponenten aufgeführt, die Sie im Modellbereich konfigurieren können:
### Modellparallelität
Nachdem Sie das Rezept festgelegt haben, definieren Sie das Modell, das Sie trainieren. Sie können auch die Modellparallelität definieren. Sie können beispielsweise tensor\$1model\$1parallel\$1degree definieren. Sie können andere Funktionen wie FP8 präzises Training aktivieren. Sie können beispielsweise ein Modell mit Tensorparallelität und Kontextparallelität trainieren:
```
model:
model_type: llama_v3
# Base configs
train_batch_size: 4
val_batch_size: 1
seed: 12345
grad_clip: 1.0
# Model parallelism
tensor_model_parallel_degree: 4
expert_model_parallel_degree: 1
context_parallel_degree: 2
```
Um ein besseres Verständnis der verschiedenen Arten von Modellparallelitätstechniken zu erlangen, können Sie auf die folgenden Ansätze zurückgreifen:
1. [Tensor-Parallelität](model-parallel-core-features-v2-tensor-parallelism.md)
1. [Expertenparallelität](model-parallel-core-features-v2-expert-parallelism.md)
1. [Kontextparallelität](model-parallel-core-features-v2-context-parallelism.md)
1. [Parallelität hybrider fragmentierter Daten](model-parallel-core-features-v2-sharded-data-parallelism.md)
### FP8
Zur Aktivierung FP8 (8-Bit-Gleitkomma-Präzision) können Sie die entsprechende Konfiguration im FP8 folgenden Beispiel angeben:
```
model:
# FP8 config
fp8: True
fp8_amax_history_len: 1024
fp8_amax_compute_algo: max
```
Es ist wichtig zu beachten, dass das FP8 Datenformat derzeit nur für den Instance-Typ P5 unterstützt wird. Wenn Sie einen älteren Instanztyp wie P4 verwenden, deaktivieren Sie die FP8 Funktion für Ihren Modelltrainingsprozess. Weitere Informationen zu finden Sie FP8 unter[Training mit gemischter Präzision](model-parallel-core-features-v2-mixed-precision.md).
### data
Sie können Ihre benutzerdefinierten Datensätze für Ihren Trainingsjob angeben, indem Sie die Datenpfade unter Daten hinzufügen. Das Datenmodul in unserem System unterstützt die folgenden Datenformate:
1. JSON
1. JSONGZ (komprimiertes JSON)
1. ARROW
Sie sind jedoch dafür verantwortlich, Ihren eigenen vortokenisierten Datensatz vorzubereiten. Wenn Sie ein fortgeschrittener Benutzer mit spezifischen Anforderungen sind, besteht auch die Möglichkeit, ein maßgeschneidertes Datenmodul zu implementieren und zu integrieren. Weitere Informationen zu HuggingFace Datensätzen finden Sie unter [Datensätze](https://huggingface.co/docs/datasets/v3.1.0/en/index).
```
model:
data:
train_dir: /path/to/your/train/data
val_dir: /path/to/your/val/data
dataset_type: hf
use_synthetic_data: False
```
Sie können angeben, wie Sie das Modell trainieren. Standardmäßig verwendet das Rezept ein Vortraining anstelle einer Feinabstimmung. Im folgenden Beispiel wird das Rezept so konfiguriert, dass es einen Feinabstimmungsjob mit LoRa (Low-Rank Adaptation) ausführt.
```
model:
# Fine tuning config
do_finetune: True
# The path to resume from, needs to be HF compatible
hf_model_name_or_path: null
hf_access_token: null
# PEFT config
peft:
peft_type: lora
rank: 32
alpha: 16
dropout: 0.1
```
[Informationen zu den Rezepten finden Sie unter SageMaker HyperPod Rezepte.](https://github.com/aws/sagemaker-hyperpod-recipes)
# Cluster-spezifische Konfigurationen
SageMaker HyperPod bietet Flexibilität bei der Ausführung von Trainingsaufträgen in verschiedenen Cluster-Umgebungen. Jede Umgebung hat ihre eigenen Konfigurationsanforderungen und ihren eigenen Einrichtungsprozess. In diesem Abschnitt werden die Schritte und Konfigurationen beschrieben, die für die Ausführung von Trainingsjobs in SageMaker HyperPod Slurm, SageMaker HyperPod K8s und SageMaker Trainingsjobs erforderlich sind. Das Verständnis dieser Konfigurationen ist entscheidend, um das Potenzial von verteiltem Training in der von Ihnen gewählten Umgebung effektiv nutzen zu können.
Sie können ein Rezept in den folgenden Cluster-Umgebungen verwenden:
+ SageMaker HyperPod Slurm-Orchestrierung
+ SageMaker HyperPod Orchestrierung von Amazon Elastic Kubernetes Service
+ SageMaker Ausbildungsberufe
Um einen Trainingsjob in einem Cluster zu starten, müssen Sie die entsprechende Cluster-Konfiguration und -Umgebung einrichten und installieren.
**Topics**
+ [Einen Trainingsjob auf HyperPod Slurm ausführen](cluster-specific-configurations-run-training-job-hyperpod-slurm.md)
+ [Einen Trainingsjob auf HyperPod k8s ausführen](cluster-specific-configurations-run-training-job-hyperpod-k8s.md)
+ [SageMaker Einen Trainingsjob ausführen](cluster-specific-configurations-run-sagemaker-training-job.md)
# Einen Trainingsjob auf HyperPod Slurm ausführen
SageMaker HyperPod Recipes unterstützt das Senden eines Trainingsjobs an einen GPU/Trainium Slurm-Cluster. Bevor Sie den Trainingsjob einreichen, aktualisieren Sie die Cluster-Konfiguration. Verwenden Sie eines der folgenden Verfahren zum Aktualisieren der Cluster-Konfiguration:
+ Ändern von `slurm.yaml`
+ Überschreiben über die Befehlszeile
Nachdem Sie die Clusterkonfiguration aktualisiert haben, installieren Sie die Umgebung.
## Konfigurieren des Clusters
Um einen Trainingsjob an einen Slurm-Cluster zu senden, geben Sie die Slurm-spezifische Konfiguration an. Ändern Sie `slurm.yaml`, um den Slurm-Cluster zu konfigurieren. Im Folgenden finden Sie ein Beispiel für eine Slurm-Clusterkonfiguration. Sie können diese Datei für Ihre eigenen Trainingsbedürfnisse ändern:
```
job_name_prefix: 'sagemaker-'
slurm_create_submission_file_only: False
stderr_to_stdout: True
srun_args:
# - "--no-container-mount-home"
slurm_docker_cfg:
docker_args:
# - "--runtime=nvidia"
post_launch_commands:
container_mounts:
- "/fsx:/fsx"
```
1. `job_name_prefix`: Geben Sie ein Präfix für den Jobnamen an, um Ihre Einsendungen für den Slurm-Cluster leicht identifizieren zu können.
1. `slurm_create_submission_file_only`: Setzen Sie diese Konfiguration für einen Probelauf auf True, um Ihnen das Debuggen zu erleichtern.
1. `stderr_to_stdout`: Geben Sie an, ob Sie Ihren Standardfehler (stderr) zur Standardausgabe (stdout) umleiten möchten.
1. `srun_args`: Passen Sie zusätzliche Srun-Konfigurationen an, z. B. das Ausschließen bestimmter Rechenknoten. Weitere Informationen finden Sie in der srun-Dokumentation.
1. `slurm_docker_cfg`: Der SageMaker HyperPod Rezept-Launcher startet einen Docker-Container, um deinen Trainingsjob auszuführen. In diesem Parameter können Sie zusätzliche Docker-Argumente angeben.
1. `container_mounts`: Geben Sie die Volumes an, die Sie in den Container für den Rezept-Launcher mounten, damit Ihre Trainingsjobs auf die Dateien in diesen Volumes zugreifen können.
# Einen Trainingsjob auf HyperPod k8s ausführen
SageMaker HyperPod Recipes unterstützt das Senden eines Trainingsjobs an einen GPU/Trainium-Kubernetes-Cluster. Bevor Sie den Trainingsjob einreichen, führen Sie einen der folgenden Schritte aus:
+ Ändern Sie die `k8s.yaml`-Cluster-Konfigurationsdatei.
+ Überschreiben Sie die Clusterkonfiguration über die Befehlszeile.
Nachdem Sie einen der vorherigen Schritte ausgeführt haben, installieren Sie die entsprechende Umgebung.
## Konfigurieren des Clusters unter Verwendung von `k8s.yaml`
Um einen Trainingsjob an einen Kubernetes-Cluster zu senden, geben Sie Kubernetes-spezifische Konfigurationen an. Die Konfigurationen beinhalten den Cluster-Namespace oder den Speicherort des persistenten Volumes.
```
pullPolicy: Always
restartPolicy: Never
namespace: default
persistent_volume_claims:
- null
```
1. `pullPolicy`: Sie können die Pull-Richtlinie angeben, wenn Sie einen Trainingsjob einreichen. Wenn Sie „Immer“ angeben, ruft der Kubernetes-Cluster Ihr Image immer aus dem Repository ab. Weitere Informationen finden Sie unter [Richtlinie zum Image-Abruf](https://kubernetes.io/docs/concepts/containers/images/#image-pull-policy).
1. `restartPolicy`: Geben Sie an, ob Ihr Trainingsjob neu gestartet werden soll, falls er fehlschlägt.
1. `namespace`: Sie können den Kubernetes-Namespace angeben, in den Sie den Trainingsjob übermitteln.
1. `persistent_volume_claims`: Sie können ein gemeinsames Volume für Ihren Trainingsjob angeben, damit alle Trainingsprozesse auf die Dateien im Volume zugreifen können.
# SageMaker Einen Trainingsjob ausführen
SageMaker HyperPod Recipes unterstützt das Einreichen eines SageMaker Trainingsjobs. Bevor Sie den Trainingsjob übermitteln, müssen Sie die Cluster-Konfiguration, `sm_job.yaml`, aktualisieren und die entsprechende Umgebung installieren.
## Verwende dein Rezept als SageMaker Ausbildungsjob
Sie können Ihr Rezept als SageMaker Trainingsjob verwenden, wenn Sie keinen Cluster hosten. Sie müssen die Konfigurationsdatei für den SageMaker Trainingsjob ändern`sm_job.yaml`, um Ihr Rezept ausführen zu können.
```
sm_jobs_config:
output_path: null
tensorboard_config:
output_path: null
container_logs_path: null
wait: True
inputs:
s3:
train: null
val: null
file_system:
directory_path: null
additional_estimator_kwargs:
max_run: 1800
```
1. `output_path`: Sie können angeben, wo Sie Ihr Modell unter einer Amazon-S3-URL speichern möchten.
1. `tensorboard_config`: Sie können eine TensorBoard zugehörige Konfiguration angeben, z. B. den Ausgabepfad oder den TensorBoard Protokollpfad.
1. `wait`: Sie können angeben, ob Sie darauf warten, dass der Job abgeschlossen ist, wenn Sie Ihren Trainingsjob einreichen.
1. `inputs`: Sie können die Pfade für Ihre Trainings- und Validierungsdaten angeben. Die Datenquelle kann aus einem gemeinsam genutzten Dateisystem wie Amazon FSx oder einer Amazon S3 S3-URL stammen.
1. `additional_estimator_kwargs`: Zusätzliche Schätzerargumente für die Einreichung einer Ausbildungsstelle auf der Plattform für SageMaker Ausbildungsangebote. Weitere Informationen finden Sie unter [Algorithmus-Schätzfunktion](https://sagemaker.readthedocs.io/en/stable/api/training/algorithm.html).
# Überlegungen
Wenn Sie ein SageMaker HyperPod Amazon-Rezept verwenden, gibt es einige Faktoren, die den Prozess des Modelltrainings beeinflussen können.
+ Die `transformers`-Version muss `4.45.2` für Llama 3.2 oder höher sein. Wenn Sie einen Slurm- oder K8s-Workflow verwenden, wird die Version automatisch aktualisiert.
+ Mixtral unterstützt keine 8-Bit-Gleitkomma-Präzision () FP8
+ Amazon EC2 p4-Instance unterstützt nicht FP8
# Erweiterte Einstellungen
Der SageMaker HyperPod Rezeptadapter basiert auf den Frameworks Nvidia Nemo und PyTorch-Lightning. Wenn Sie diese Frameworks bereits verwendet haben, ist die Integration Ihrer benutzerdefinierten Modelle oder Funktionen in den SageMaker HyperPod Rezeptadapter ein ähnlicher Prozess. Sie können nicht nur den Rezeptadapter ändern, sondern auch Ihr eigenes Skript für die Vorbereitung oder Feinabstimmung ändern. Anleitungen zum Schreiben Ihres benutzerdefinierten Trainingsskripts finden Sie in den [Beispielen](https://github.com/aws/sagemaker-hyperpod-training-adapter-for-nemo/tree/main/examples).
## Verwenden Sie den SageMaker HyperPod Adapter, um Ihr eigenes Modell zu erstellen
Im Rezeptadapter können Sie die folgenden Dateien an den folgenden Speicherorten anpassen:
1. `collections/data`: Enthält ein Modul, das für das Laden von Datensätzen verantwortlich ist. Derzeit unterstützt es nur Datensätze von HuggingFace. Wenn Sie erweiterte Anforderungen haben, können Sie mithilfe der Codestruktur benutzerdefinierte Datenmodule innerhalb desselben Ordners hinzufügen.
1. `collections/model`: Beinhaltet die Definitionen verschiedener Sprachmodelle. Derzeit unterstützt es gängige große Sprachmodelle wie Llama, Mixtral und Mistral. Sie haben die Flexibilität, Ihre eigenen Modelldefinitionen in diesen Ordner einzufügen.
1. `collections/parts`: Dieser Ordner enthält Strategien für das verteilte Training von Modellen. Ein Beispiel hierfür ist die Fully Sharded Data Parallel (FSDP)-Strategie, die es ermöglicht, ein großes Sprachmodell auf mehrere Beschleuniger aufzuteilen. Darüber hinaus unterstützen die Strategien verschiedene Formen der Modellparallelität. Sie haben auch die Möglichkeit, Ihre eigenen maßgeschneiderten Trainingsstrategien für das Modelltraining einzuführen.
1. `utils`: Enthält verschiedene Dienstprogramme, die die Verwaltung eines Trainingsjob erleichtern sollen. Es dient als Repository für Ihre eigenen Tools. Sie können Ihre eigenen Tools für Aufgaben wie Fehlerbehebung oder Benchmarking verwenden. Sie können diesem Ordner auch Ihre eigenen personalisierten PyTorch Lightning-Rückrufe hinzufügen. Sie können PyTorch Lightning-Rückrufe verwenden, um bestimmte Funktionen oder Abläufe nahtlos in den Schulungslebenszyklus zu integrieren.
1. `conf`: Enthält die Definitionen des Konfigurationsschemas, die für die Validierung bestimmter Parameter in einem Trainingsjob verwendet werden. Wenn Sie neue Parameter oder Konfigurationen einführen, können Sie Ihr benutzerdefiniertes Schema zu diesem Ordner hinzufügen. Sie können das benutzerdefinierte Schema verwenden, um die Validierungsregeln zu definieren. Sie können Datentypen, Bereiche oder jede andere Parameterbeschränkung validieren. Sie können auch Ihr eigenes benutzerdefiniertes Schema definieren, um die Parameter zu validieren.
# Anhang
Verwenden Sie die folgenden Informationen, um Informationen zur Überwachung und Analyse von Trainingsergebnissen zu erhalten.
## Überwachen der Trainingsergebnisse
Die Überwachung und Analyse von Schulungsergebnissen ist für Entwickler unerlässlich, um Konvergenz zu beurteilen und Probleme zu beheben. SageMaker HyperPod Rezepte bieten eine Tensorboard-Integration zur Analyse des Trainingsverhaltens. Um den Herausforderungen zu begegnen, die mit der Erstellung von Profilen großer, verteilter Trainingsjobs verbunden sind, beinhalten diese Rezepte auch Folgendes: VizTracer VizTracerist ein Tool mit geringem Aufwand zum Verfolgen und Visualisieren der Python-Codeausführung. Weitere Informationen VizTracer zu finden Sie unter. [VizTracer](https://viztracer.readthedocs.io/en/latest/installation.html)
In den folgenden Abschnitten erfahren Sie, wie Sie diese Funktionen in Ihren SageMaker HyperPod Rezepten implementieren.
### Tensorboard
Tensorboard ist ein leistungsstarkes Tool zur Visualisierung und Analyse des Trainingsprozesses. Um Tensorboard zu aktivieren, ändern Sie Ihr Rezept, indem Sie den folgenden Parameter einstellen:
```
exp_manager:
exp_dir: null
name: experiment
create_tensorboard_logger: True
```
Nachdem Sie den Tensorboard-Logger aktiviert haben, werden die Trainingsprotokolle generiert und im Experimentverzeichnis gespeichert. Das geleitete Experiment ist in exp\$1manager.exp\$1dir definiert. Gehen Sie wie folgt vor, um auf diese Protokolle zuzugreifen und sie lokal zu analysieren:
**So greifen Sie auf Protokolle zu und analysieren sie:**
1. Laden Sie den Tensorboard-Experimentordner aus Ihrer Trainingsumgebung auf Ihren lokalen Computer herunter.
1. Öffnen Sie ein Terminal oder einen Prompt auf Ihrem lokalen Rechner.
1. Navigieren Sie zu dem Verzeichnis, das den heruntergeladenen Experimentordner enthält.
1. Starten Sie Tensorboard mit dem folgenden Befehl.
```
tensorboard --port= --bind_all --logdir experiment.
```
1. Öffnen Sie Ihren Browser und navigieren Sie zu http://localhost:8008.
Sie können jetzt den Status und die Visualisierungen Ihrer Trainingsjobs in der Tensorboard-Oberfläche sehen. Wenn Sie den Status und die Visualisierungen sehen, können Sie den Trainingsprozess überwachen und analysieren. Durch die Überwachung und Analyse des Trainingsprozesses können Sie Einblicke in das Verhalten und die Leistung Ihrer Modelle gewinnen. Weitere Informationen zur Überwachung und Analyse des Trainings mit Tensorboard finden Sie im [NVIDIA NeMo Framework-Benutzerhandbuch](https://docs.nvidia.com/nemo-framework/user-guide/latest/llms/index.html).
### VizTracer
Zur Aktivierung können Sie Ihr Rezept ändern VizTracer, indem Sie den Parameter model.viztracer.enabled auf true setzen. Sie können beispielsweise Ihr Lama-Rezept aktualisieren, um es zu aktivieren VizTracer , indem Sie die folgende Konfiguration hinzufügen:
```
model:
viztracer:
enabled: true
```
Nach Abschluss der Schulung befindet sich Ihr VizTracer Profil im Experimentordner exp\$1dir/result.json. Um Ihr Profil zu analysieren, können Sie es herunterladen und mit dem VizViewer-Tool öffnen:
```
vizviewer --port result.json
```
Dieser Befehl startet den VizViewer auf Port 9001. Sie können Ihre anzeigen, VizTracer indem Sie http://localhost: in Ihrem Browser angeben. Nach dem Öffnen VizTracer beginnen Sie mit der Analyse des Trainings. Weitere Informationen zur Verwendung VizTracer finden Sie in der VizTracer Dokumentation.
## SageMaker JumpStart versus SageMaker HyperPod
Die SageMaker HyperPod Rezepte SageMaker JumpStart bieten zwar Funktionen zur Feinabstimmung, bieten aber Folgendes:
+ Zusätzliche fein abgestufte Kontrolle über die Trainingsschleife
+ Anpassung des Rezepts für Ihre eigenen Modelle und Daten
+ Unterstützung für Modellparallelität
Verwenden Sie die SageMaker HyperPod Rezepte, wenn Sie Zugriff auf die Hyperparameter des Modells, das Training mit mehreren Knoten und die Anpassungsoptionen für die Trainingsschleife benötigen.
Weitere Informationen zur Feinabstimmung Ihrer Modelle finden Sie unter SageMaker JumpStart [Optimieren von öffentlich verfügbaren Basismodellen mit der `JumpStartEstimator`-Klasse](jumpstart-foundation-models-use-python-sdk-estimator-class.md)
# Orchestrierung von SageMaker HyperPod Clustern mit Slurm
Die Slurm-Unterstützung SageMaker HyperPod unterstützt Sie bei der Bereitstellung robuster Cluster für die Ausführung von Workloads für maschinelles Lernen (ML) und die Entwicklung von state-of-the-art Modellen wie großen Sprachmodellen (LLMs), Diffusionsmodellen und Basismodellen (). FMs Es beschleunigt die Entwicklung von, FMs indem der undifferenzierte Aufwand für den Aufbau und die Wartung großer Rechencluster entfällt, die von Tausenden von Beschleunigern wie AWS Trainium und NVIDIA A100 und H100 Graphical Processing Units () angetrieben werden. GPUs Wenn Beschleuniger ausfallen, erkennen die Ausfallsicherheitsfunktionen der SageMaker HyperPod Monitore die fehlerhafte Hardware automatisch und ersetzen sie im laufenden Betrieb, sodass Sie sich auf die Ausführung von ML-Workloads konzentrieren können. Darüber hinaus können Sie mit der Unterstützung für die Lebenszykluskonfiguration Ihre Computerumgebung an Ihre Bedürfnisse anpassen und sie mit den verteilten Schulungsbibliotheken von Amazon SageMaker AI konfigurieren, um eine optimale Leistung zu erzielen AWS. SageMaker HyperPod
**Betrieb von Clustern**
Sie können SageMaker HyperPod Cluster grafisch über die Konsolenbenutzeroberfläche (UI) und programmgesteuert über die AWS Befehlszeilenschnittstelle (CLI) oder erstellen, konfigurieren und verwalten. AWS SDK für Python (Boto3) Mit Amazon VPC können Sie das Cluster-Netzwerk sichern und auch die Vorteile der Konfiguration Ihres Clusters mit Ressourcen in Ihrer VPC nutzen, z. B. Amazon FSx for Lustre, das den schnellsten Durchsatz bietet. Sie können Cluster-Instance-Gruppen auch unterschiedliche IAM-Rollen zuweisen und die Aktionen einschränken, die Ihre Cluster-Ressourcen und Benutzer ausführen können. Weitere Informationen hierzu finden Sie unter [SageMaker HyperPod Slurm-Clusteroperationen](sagemaker-hyperpod-operate-slurm.md).
**Konfigurieren der ML-Umgebung**
SageMaker HyperPod wird ausgeführt[SageMaker HyperPod DLAMI](sagemaker-hyperpod-ref.md#sagemaker-hyperpod-ref-hyperpod-ami), wodurch eine ML-Umgebung auf den Clustern eingerichtet wird. HyperPod Sie können zusätzliche Anpassungen für das DLAMI konfigurieren, indem Sie Lebenszyklusskripte zur Unterstützung Ihres Anwendungsfalls bereitstellen. Weitere Informationen zum Einrichten von Lebenszyklusskripten finden Sie unter [Erste Schritte mit SageMaker HyperPod](smcluster-getting-started-slurm.md) und [Anpassen von SageMaker HyperPod Clustern mithilfe von Lifecycle-Skripten](sagemaker-hyperpod-lifecycle-best-practices-slurm.md).
**Planen von Aufträgen**
Nachdem Sie erfolgreich einen HyperPod Cluster erstellt haben, können sich Clusterbenutzer bei den Clusterknoten (wie dem Head- oder Controller-Knoten, dem Anmeldeknoten und dem Worker-Knoten) anmelden und Jobs für die Ausführung von Workloads für maschinelles Lernen planen. Weitere Informationen hierzu finden Sie unter [Jobs auf Clustern SageMaker HyperPod](sagemaker-hyperpod-run-jobs-slurm.md).
**Widerstandskraft gegen Hardwareausfälle**
SageMaker HyperPod führt Integritätsprüfungen auf Clusterknoten durch und bietet eine Funktion zur automatischen Wiederaufnahme der Arbeitslast. Mit den Cluster-Resilienzfunktionen von HyperPod können Sie Ihre Arbeitslast ab dem letzten Checkpoint fortsetzen, den Sie gespeichert haben, nachdem fehlerhafte Knoten in Clustern mit mehr als 16 Knoten durch fehlerfreie ersetzt wurden. Weitere Informationen hierzu finden Sie unter [SageMaker HyperPod Cluster-Resilienz](sagemaker-hyperpod-resiliency-slurm.md).
**Protokollieren und Verwalten von Clustern**
Sie können Metriken zur SageMaker HyperPod Ressourcennutzung und Lebenszyklusprotokolle in Amazon finden und SageMaker HyperPod Ressourcen verwalten CloudWatch, indem Sie sie taggen. Jede `CreateCluster` API-Ausführung erstellt einen eigenen Protokollstream, der im Format `-` benannt ist. Im Protokollstream können Sie die Hostnamen, die Namen fehlgeschlagener Lebenszyklusskripte und die Ausgaben der fehlgeschlagenen Skripte wie `stdout` und `stderr` überprüfen. Weitere Informationen finden Sie unter [SageMaker HyperPod Cluster-Verwaltung](sagemaker-hyperpod-cluster-management-slurm.md).
**Kompatibel mit SageMaker KI-Tools**
Mithilfe von SageMaker HyperPod SageMaker KI können Sie Cluster mit AWS optimierten Bibliotheken für kollektive Kommunikation konfigurieren, wie z. B. der [SageMaker AI Distributed Data Parallelism (SMDDP](data-parallel.md)) -Bibliothek. Die SMDDP-Bibliothek implementiert den für die AWS Rechen- und Netzwerkinfrastruktur optimierten `AllGather` Betrieb für die leistungsstärksten SageMaker KI-Instanzen für maschinelles Lernen, die auf NVIDIA A100 basieren. GPUs Weitere Informationen hierzu finden Sie unter [Ausführung verteilter Trainingsworkloads mit aktiviertem Slurm HyperPod](sagemaker-hyperpod-run-jobs-slurm-distributed-training-workload.md).
**Platzierung von Instanzen mit UltraServers**
SageMaker KI weist automatisch Jobs Ihren Instances zu. Dies UltraServer basiert auf einer Best-Effort-Strategie, bei der alle Instanzen in einer Instanz verwendet werden, UltraServer bevor eine andere verwendet wird. Wenn Sie beispielsweise 14 Instanzen anfordern und 2 UltraServers in Ihrem Trainingsplan haben, verwendet SageMaker KI alle Instanzen der ersten Instanz. UltraServer Wenn du 20 Instanzen angefordert hast und 2 UltraServers in deinem Trainingsplan hast, verwendet SageMaker KI alle 17 Instanzen in der ersten Instanz UltraServer und dann 3 von der zweiten UltraServer.
**Topics**
+ [Erste Schritte mit SageMaker HyperPod](smcluster-getting-started-slurm.md)
+ [SageMaker HyperPod Slurm-Clusteroperationen](sagemaker-hyperpod-operate-slurm.md)
+ [Anpassen von SageMaker HyperPod Clustern mithilfe von Lifecycle-Skripten](sagemaker-hyperpod-lifecycle-best-practices-slurm.md)
+ [SageMaker HyperPod Unterstützung für Multi-Head-Knoten](sagemaker-hyperpod-multihead-slurm.md)
+ [Jobs auf Clustern SageMaker HyperPod](sagemaker-hyperpod-run-jobs-slurm.md)
+ [SageMaker HyperPod Überwachung der Cluster-Ressourcen](sagemaker-hyperpod-cluster-observability-slurm.md)
+ [SageMaker HyperPod Cluster-Resilienz](sagemaker-hyperpod-resiliency-slurm.md)
+ [Kontinuierliche Bereitstellung für erweiterte Clusteroperationen mit Slurm](sagemaker-hyperpod-scaling-slurm.md)
+ [SageMaker HyperPod Cluster-Verwaltung](sagemaker-hyperpod-cluster-management-slurm.md)
+ [SageMaker HyperPod FAQs](sagemaker-hyperpod-faq-slurm.md)
# Erste Schritte mit SageMaker HyperPod
Beginnen Sie mit der Erstellung Ihres ersten SageMaker HyperPod Clusters und lernen Sie die Funktionen des Clusterbetriebs von kennen SageMaker HyperPod. Sie können einen SageMaker HyperPod Cluster über die Benutzeroberfläche der SageMaker AI-Konsole oder die AWS CLI Befehle erstellen. Dieses Tutorial zeigt, wie Sie mit Slurm, einer beliebten Workload-Scheduler-Software, einen neuen SageMaker HyperPod Cluster erstellen. Nachdem Sie dieses Tutorial durchgearbeitet haben, wissen Sie, wie Sie sich mit den AWS Systems Manager Befehlen () `aws ssm` bei den Cluster-Knoten anmelden. Nachdem Sie dieses Tutorial abgeschlossen haben, finden Sie unter auch weitere Informationen [SageMaker HyperPod Slurm-Clusteroperationen](sagemaker-hyperpod-operate-slurm.md) zu den SageMaker HyperPod grundlegenden Vorgängen und [Jobs auf Clustern SageMaker HyperPod](sagemaker-hyperpod-run-jobs-slurm.md) zum Planen von Jobs auf dem bereitgestellten Cluster.
**Tipp**
[Praktische Beispiele und Lösungen finden Sie auch im Workshop. SageMaker HyperPod](https://catalog.workshops.aws/sagemaker-hyperpod)
**Topics**
+ [Erste Schritte mit der SageMaker HyperPod Verwendung der SageMaker KI-Konsole](smcluster-getting-started-slurm-console.md)
+ [Cluster mithilfe von Vorlagen erstellen SageMaker HyperPod CloudFormation](smcluster-getting-started-slurm-console-create-cluster-cfn.md)
+ [Erste Schritte mit der SageMaker HyperPod Verwendung von AWS CLI](smcluster-getting-started-slurm-cli.md)
# Erste Schritte mit der SageMaker HyperPod Verwendung der SageMaker KI-Konsole
Das folgende Tutorial zeigt, wie Sie einen neuen SageMaker HyperPod Cluster erstellen und ihn mit Slurm über die Benutzeroberfläche der SageMaker AI-Konsole einrichten. Im Anschluss an das Tutorial erstellen Sie einen HyperPod Cluster mit drei Slurm-Knoten, `my-controller-group``my-login-group`, und. `worker-group-1`
**Topics**
+ [Cluster erstellen](#smcluster-getting-started-slurm-console-create-cluster-page)
+ [Bereitstellen von Ressourcen](#smcluster-getting-started-slurm-console-create-cluster-deploy)
+ [Löschen des Clusters und Bereinigen der Ressourcen](#smcluster-getting-started-slurm-console-delete-cluster-and-clean)
## Cluster erstellen
Gehen Sie wie folgt vor, um zur **SageMaker HyperPod Cluster-Seite** zu navigieren **und Slurm-Orchestration** auszuwählen.
1. Öffnen Sie die Amazon SageMaker AI-Konsole unter [https://console.aws.amazon.com/sagemaker/](https://console.aws.amazon.com/sagemaker/).
1. Wählen Sie im linken Navigationsbereich **HyperPod Clusters** und dann **Cluster Management** aus.
1. Wählen Sie auf der Seite **SageMaker HyperPod Cluster** die Option ** HyperPod Cluster erstellen** aus.
1. Wählen **Sie im Drop-down-Menü HyperPod Cluster erstellen** die Option **Orchestrated by Slurm aus**.
1. Auf der Seite zur Erstellung eines Slurm-Clusters sehen Sie zwei Optionen. Wählen Sie die Option aus, die Ihren Bedürfnissen am besten entspricht.
1. **Quick Setup**: Um sofort mit den Standardeinstellungen zu beginnen, wählen Sie **Quick Setup** aus. Mit dieser Option erstellt SageMaker KI bei der Erstellung Ihres Clusters neue Ressourcen wie VPC, Subnetze, Sicherheitsgruppen, Amazon S3 S3-Bucket, IAM-Rolle und FSx für Lustre.
1. **Benutzerdefinierte Einrichtung**: Um eine Integration mit vorhandenen Ressourcen vorzunehmen oder bestimmte Anforderungen hinsichtlich Netzwerk, Sicherheit oder Speicher zu erfüllen, wählen Sie **Benutzerdefinierte Einrichtung** aus. Mit dieser Option können Sie wählen, ob Sie die vorhandenen Ressourcen verwenden oder neue erstellen möchten, und Sie können die Konfiguration an Ihre Bedürfnisse anpassen.
## Quick Setup
Folgen Sie im Abschnitt **Schnelleinrichtung** diesen Schritten, um Ihren HyperPod Cluster mit Slurm-Orchestrierung zu erstellen.
### Allgemeine Einstellungen
Geben Sie einen Namen für den neuen Cluster ein. Sie können den Namen nicht ändern, nachdem der Cluster erstellt wurde.
### Instance-Gruppen
Um eine Instance-Gruppe hinzuzufügen, wählen Sie **Gruppe hinzufügen** aus. Jede Instance-Gruppe kann anders konfiguriert werden und Sie können einen heterogenen Cluster erstellen, der aus mehreren Instance-Gruppen mit verschiedenen Instance-Typen besteht. Um einen Cluster bereitzustellen, müssen Sie mindestens eine Instance-Gruppe für die Gruppentypen „Controller“ und „Compute“ hinzufügen.
**Wichtig**
Sie können jeweils eine Instance-Gruppe hinzufügen. Wenn Sie mehrere Instance-Gruppen erstellen möchten, wiederholen Sie den Vorgang für jede Instance-Gruppe.
Gehen Sie folgendermaßen vor, um eine Instance-Gruppe hinzuzufügen.
1. Wählen Sie unter **Instance-Gruppentyp** einen Typ für die Instance-Gruppe aus. Für dieses Tutorial wählen Sie **Controller (Head)** für `my-controller-group`, **Login** für `my-login-group` und **Compute (Worker)** für `worker-group-1` aus.
1. Geben Sie unter **Name** einen Namen für die Instance-Gruppe an. Für dieses Tutorial erstellen Sie drei Instance-Gruppen mit den Namen `my-controller-group`, `my-login-group` und `worker-group-1`.
1. Wählen Sie als **Instance-Kapazität** entweder On-Demand-Kapazität oder einen Trainingsplan aus, um Ihre Datenverarbeitungsressourcen zu reservieren.
1. Wählen Sie unter **Instance-Typ** die Instance für die Instance-Gruppe aus. Wählen Sie für dieses Tutorial `ml.c5.xlarge` für `my-controller-group`, `ml.m5.4xlarge` für `my-login-group` und `ml.trn1.32xlarge` für `worker-group-1`.
**Wichtig**
Stellen Sie sicher, dass Sie einen Instance-Typ mit ausreichenden Kontingenten und ausreichend nicht zugewiesenen IP-Adressen für Ihr Konto auswählen. Informationen zum Anzeigen oder Anfordern zusätzlicher Kontingente finden Sie unter [SageMaker HyperPod Kontingente](sagemaker-hyperpod-prerequisites.md#sagemaker-hyperpod-prerequisites-quotas).
1. Geben Sie unter **Instance-Anzahl** eine Ganzzahl an, die das Instance-Kontingent für die Cluster-Nutzung nicht überschreitet. Für dieses Tutorial geben Sie **1** für alle drei Gruppen ein.
1. Wählen Sie als **Ziel-Availability-Zone** die Availability Zone aus, in der Ihre Instances bereitgestellt werden. Die Availability Zone sollte dem Standort Ihrer beschleunigten Datenverarbeitungskapazität entsprechen.
1. Geben Sie unter **Zusätzliches Speichervolumen pro Instance (GB) – optional** eine Ganzzahl zwischen 1 und 16 384 an, um die Größe eines zusätzlichen Elastic Book Store (EBS)-Volume in Gigabyte (GB) festzulegen. Das EBS-Volume ist an jede Instance der Instance-Gruppe angefügt. Der Standard-Bereitstellungspfad für das zusätzliche EBS-Volume ist `/opt/sagemaker`. Nachdem der Cluster erfolgreich erstellt wurde, können Sie per SSH auf die Cluster-Instances (Knoten) zugreifen und überprüfen, ob das EBS-Volume korrekt gemountet wurde, indem Sie den `df -h`-Befehl ausführen. Durch das Anfügen eines zusätzlichen EBS-Volumes wird stabiler, Instance-unabhängiger persistenter Speicher bereitgestellt, wie im Abschnitt [Amazon-EBS-Volumes](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-volumes.html) im *Benutzerhandbuch für Amazon Elastic Block Store* beschrieben.
1. Wählen Sie **Instance-Gruppe hinzufügen** aus.
### Quick Setup – Standardwerte
In diesem Abschnitt sind alle Standardeinstellungen für Ihre Clustererstellung aufgeführt, einschließlich aller neuen AWS Ressourcen, die während des Clustererstellungsprozesses erstellt werden. Überprüfen Sie die Standardeinstellungen.
## Benutzerdefinierte Einrichtung
Gehen Sie im Abschnitt **Benutzerdefiniertes Setup** wie folgt vor, um Ihren HyperPod Cluster mit Slurm-Orchestrierung zu erstellen.
### Allgemeine Einstellungen
Geben Sie einen Namen für den neuen Cluster ein. Sie können den Namen nicht ändern, nachdem der Cluster erstellt wurde.
Wählen Sie für die **Instance-Wiederherstellung** **Automatisch – *empfohlen*** oder **Keine**.
### Netzwerk
Konfigurieren Sie Ihre Netzwerkeinstellungen für die Clustererstellung. Nachdem der Cluster erstellt wurde, können diese Einstellungen nicht mehr geändert werden.
1. Wählen Sie für **VPC** Ihre eigene VPC aus, falls Sie bereits eine haben, die SageMaker KI Zugriff auf Ihre VPC gewährt. Um eine neue VPC zu erstellen, folgen Sie den Anweisungen unter [Erstellen einer VPC](https://docs.aws.amazon.com/vpc/latest/userguide/create-vpc.html) im *Benutzerhandbuch für Amazon Virtual Private Cloud*. Sie können es auf **None** belassen, um die standardmäßige SageMaker KI-VPC zu verwenden.
1. Geben Sie für den **VPC IPv4 CIDR-Block** die Start-IP Ihrer VPC ein.
1. Wählen Sie für **Availability Zones** die Availability Zones (AZ) aus, in denen Subnetze für HyperPod Ihren Cluster erstellt werden sollen. Wählen Sie AZs diese aus, die dem Standort Ihrer beschleunigten Rechenkapazität entsprechen.
1. Erstellen Sie für **Sicherheitsgruppen** eine Sicherheitsgruppe oder wählen Sie bis zu fünf Sicherheitsgruppen aus, die mit Regeln konfiguriert sind, um die Kommunikation zwischen Ressourcen innerhalb der VPC zu ermöglichen.
### Instance-Gruppen
Um eine Instance-Gruppe hinzuzufügen, wählen Sie **Gruppe hinzufügen** aus. Jede Instance-Gruppe kann anders konfiguriert werden und Sie können einen heterogenen Cluster erstellen, der aus mehreren Instance-Gruppen mit verschiedenen Instance-Typen besteht. Um einen Cluster bereitzustellen, müssen Sie mindestens eine Instance-Gruppe hinzufügen.
**Wichtig**
Sie können jeweils eine Instance-Gruppe hinzufügen. Wenn Sie mehrere Instance-Gruppen erstellen möchten, wiederholen Sie den Vorgang für jede Instance-Gruppe.
Gehen Sie folgendermaßen vor, um eine Instance-Gruppe hinzuzufügen.
1. Wählen Sie unter **Instance-Gruppentyp** einen Typ für die Instance-Gruppe aus. Für dieses Tutorial wählen Sie **Controller (Head)** für `my-controller-group`, **Login** für `my-login-group` und **Compute (Worker)** für `worker-group-1` aus.
1. Geben Sie unter **Name** einen Namen für die Instance-Gruppe an. Für dieses Tutorial erstellen Sie drei Instance-Gruppen mit den Namen `my-controller-group`, `my-login-group` und `worker-group-1`.
1. Wählen Sie als **Instance-Kapazität** entweder On-Demand-Kapazität oder einen Trainingsplan aus, um Ihre Datenverarbeitungsressourcen zu reservieren.
1. Wählen Sie unter **Instance-Typ** die Instance für die Instance-Gruppe aus. Wählen Sie für dieses Tutorial `ml.c5.xlarge` für `my-controller-group`, `ml.m5.4xlarge` für `my-login-group` und `ml.trn1.32xlarge` für `worker-group-1`.
**Wichtig**
Stellen Sie sicher, dass Sie einen Instance-Typ mit ausreichenden Kontingenten und ausreichend nicht zugewiesenen IP-Adressen für Ihr Konto auswählen. Informationen zum Anzeigen oder Anfordern zusätzlicher Kontingente finden Sie unter [SageMaker HyperPod Kontingente](sagemaker-hyperpod-prerequisites.md#sagemaker-hyperpod-prerequisites-quotas).
1. Geben Sie unter **Instance-Anzahl** eine Ganzzahl an, die das Instance-Kontingent für die Cluster-Nutzung nicht überschreitet. Für dieses Tutorial geben Sie **1** für alle drei Gruppen ein.
1. Wählen Sie als **Ziel-Availability-Zone** die Availability Zone aus, in der Ihre Instances bereitgestellt werden. Die Availability Zone sollte dem Standort Ihrer beschleunigten Datenverarbeitungskapazität entsprechen.
1. Geben Sie unter **Zusätzliches Speichervolumen pro Instance (GB) – optional** eine Ganzzahl zwischen 1 und 16 384 an, um die Größe eines zusätzlichen Elastic Book Store (EBS)-Volume in Gigabyte (GB) festzulegen. Das EBS-Volume ist an jede Instance der Instance-Gruppe angefügt. Der Standard-Bereitstellungspfad für das zusätzliche EBS-Volume ist `/opt/sagemaker`. Nachdem der Cluster erfolgreich erstellt wurde, können Sie per SSH auf die Cluster-Instances (Knoten) zugreifen und überprüfen, ob das EBS-Volume korrekt gemountet wurde, indem Sie den `df -h`-Befehl ausführen. Durch das Anfügen eines zusätzlichen EBS-Volumes wird stabiler, Instance-unabhängiger persistenter Speicher bereitgestellt, wie im Abschnitt [Amazon-EBS-Volumes](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-volumes.html) im *Benutzerhandbuch für Amazon Elastic Block Store* beschrieben.
1. Wählen Sie **Instance-Gruppe hinzufügen** aus.
### Lebenszyklusskripte
Sie können zwischen den Standard-Lebenszyklusskripten und den benutzerdefinierten Lebenszyklusskripten wählen, die in Ihrem Amazon-S3-Bucket gespeichert werden. Sie können die standardmäßigen Lebenszyklusskripte im [Awesome Distributed GitHub Training-Repository](https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/7.sagemaker-hyperpod-eks/LifecycleScripts) einsehen. Weitere Informationen zu den Lebenszyklusskripten finden Sie unter [Anpassen von SageMaker HyperPod Clustern mithilfe von Lifecycle-Skripten](sagemaker-hyperpod-lifecycle-best-practices-slurm.md).
1. Wählen Sie für **Lebenszyklusskripte**, ob Sie standardmäßige oder benutzerdefinierte Lebenszyklusskripte verwenden möchten.
1. Wählen Sie für **S3-Bucket für Lebenszyklusskripte**, ob Sie einen neuen Bucket erstellen oder einen vorhandenen Bucket zum Speichern der Lebenszyklusskripten verwenden möchten.
### Berechtigungen
Wählen oder erstellen Sie eine IAM-Rolle, mit der Sie die erforderlichen AWS Ressourcen in Ihrem Namen ausführen und darauf zugreifen können HyperPod .
### Speicher
Konfigurieren Sie das FSx for Lustre-Dateisystem, das auf dem Cluster bereitgestellt werden soll. HyperPod
1. Wählen Sie für **Dateisystem** ein vorhandenes FSx for Lustre-Dateisystem aus, um ein neues FSx for Lustre-Dateisystem zu erstellen, oder stellen Sie kein FSx for Lustre-Dateisystem bereit.
1. Wählen Sie für **Durchsatz pro Speichereinheit** den Durchsatz aus, der pro TiB bereitgestellten Speichers verfügbar sein soll.
1. Geben Sie für **Speicherkapazität** einen Kapazitätswert in TB ein.
1. Wählen Sie als **Datenkomprimierungstyp** die Option **LZ4**Datenkomprimierung aktivieren.
1. Sehen Sie sich für die **Lustre-Version** den Wert an, der für die neuen Dateisysteme empfohlen wird.
### Tags – optional
Fügen Sie **unter Tags — *optional*** Schlüssel- und Wertepaare zum neuen Cluster hinzu und verwalten Sie den Cluster als AWS Ressource. Weitere Informationen finden Sie unter [Markieren Ihrer AWS -Ressourcen](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html).
## Bereitstellen von Ressourcen
Nachdem Sie die Clusterkonfigurationen entweder mit **Quick Setup** oder **Benutzerdefinierte Einrichtung** abgeschlossen haben, wählen Sie die folgende Option aus, um mit der Ressourcenbereitstellung und Clustererstellung zu beginnen.
+ **Absenden** — SageMaker KI beginnt mit der Bereitstellung der Standardkonfigurationsressourcen und der Erstellung des Clusters.
+ ** CloudFormation Vorlagenparameter herunterladen** — Sie laden die JSON-Datei mit den Konfigurationsparametern herunter und führen einen AWS CLI Befehl aus, um den CloudFormation Stack bereitzustellen, um die Konfigurationsressourcen bereitzustellen und den Cluster zu erstellen. Sie können die heruntergeladene Parameter-JSON-Datei bei Bedarf bearbeiten. Wenn Sie diese Option auswählen, finden Sie weitere Anweisungen unter [Cluster mithilfe von Vorlagen erstellen SageMaker HyperPod CloudFormation](smcluster-getting-started-slurm-console-create-cluster-cfn.md).
## Löschen des Clusters und Bereinigen der Ressourcen
Nachdem Sie die Erstellung eines SageMaker HyperPod Clusters erfolgreich getestet haben, läuft er im `InService` Status weiter, bis Sie den Cluster löschen. Wir empfehlen, dass Sie alle Cluster löschen, die mit SageMaker On-Demand-AI-Instances erstellt wurden, wenn sie nicht verwendet werden, um zu vermeiden, dass weitere Servicegebühren aufgrund von On-Demand-Preisen anfallen. In diesem Tutorial haben Sie einen Cluster erstellt, der aus zwei Instance-Gruppen besteht. Eine davon verwendet eine C5-Instance. Stellen Sie also sicher, dass Sie den Cluster löschen, indem Sie den Anweisungen unter [Löschen Sie einen SageMaker HyperPod Cluster](sagemaker-hyperpod-operate-slurm-console-ui.md#sagemaker-hyperpod-operate-slurm-console-ui-delete-cluster) folgen.
Wenn Sie jedoch einen Cluster mit reservierter Rechenkapazität erstellt haben, hat der Status der Cluster keinen Einfluss auf die Serviceabrechnung.
Um die Lebenszyklusskripte aus dem für dieses Tutorial verwendeten S3-Bucket zu bereinigen, wechseln Sie zu dem S3-Bucket, den Sie bei der Clustererstellung verwendet haben, und entfernen Sie die Dateien vollständig.
Wenn Sie die Ausführung von Workloads auf dem Cluster getestet haben, vergewissern Sie sich, ob Sie Daten hochgeladen haben oder ob Ihr Job Artefakte in verschiedenen S3-Buckets oder Dateisystemdiensten wie Amazon FSx for Lustre und Amazon Elastic File System gespeichert hat. Um Gebühren zu vermeiden, löschen Sie alle Artefakte und Daten aus dem Speicher- oder Dateisystem.
# Cluster mithilfe von Vorlagen erstellen SageMaker HyperPod CloudFormation
Sie können SageMaker HyperPod Cluster mithilfe der CloudFormation Vorlagen für erstellen HyperPod. Sie müssen installieren AWS CLI , um fortzufahren.
**Topics**
+ [Konfigurieren Sie Ressourcen in der Konsole und stellen Sie sie bereit mit CloudFormation](#smcluster-getting-started-slurm-console-create-cluster-deploy-console)
+ [Ressourcen konfigurieren und bereitstellen mit CloudFormation](#smcluster-getting-started-slurm-console-create-cluster-deploy-cfn)
## Konfigurieren Sie Ressourcen in der Konsole und stellen Sie sie bereit mit CloudFormation
Sie können Ressourcen mithilfe der konfigurieren AWS-Managementkonsole und mithilfe der CloudFormation Vorlagen bereitstellen.
Dazu gehen Sie wie folgt vor:
1. *Anstatt auf **Senden zu klicken***, wählen Sie am Ende des Tutorials unter die Option ** CloudFormation Vorlagenparameter herunterladen** aus[Erste Schritte mit der SageMaker HyperPod Verwendung der SageMaker KI-Konsole](smcluster-getting-started-slurm-console.md). Das Tutorial enthält wichtige Konfigurationsinformationen, die Sie benötigen, um Ihren Cluster erfolgreich zu erstellen.
**Wichtig**
Wenn Sie **Absenden** auswählen, können Sie einen Cluster mit demselben Namen erst bereitstellen, wenn Sie den Cluster löschen.
Nachdem Sie die Option ** CloudFormation Vorlagenparameter herunterladen** ausgewählt haben, wird **das Fenster Verwenden der Konfigurationsdatei zur Erstellung des AWS CLI Clusters mithilfe** des Fensters auf der rechten Seite angezeigt.
1. Wählen Sie im Fenster **Verwenden der Konfigurationsdatei zum Erstellen des Clusters unter Verwendung der AWS CLI** die Option **Konfigurationsparameter-Datei herunterladen** aus. Die Datei wird auf Ihren Computer heruntergeladen. Sie können die JSON-Konfigurationsdatei nach Ihren Bedürfnissen bearbeiten oder sie unverändert lassen, wenn keine Änderung erforderlich ist.
1. Navigieren Sie in einem Terminalfenster zum Speicherort der Parameterdatei `file://params.json`.
1. Führen Sie den AWS CLI Befehl [create-stack](https://docs.aws.amazon.com//cli/latest/reference/cloudformation/create-stack.html) aus, um den CloudFormation Stack bereitzustellen, der die konfigurierten Ressourcen bereitstellt und den HyperPod Cluster erstellt.
```
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. [Um den Status der Ressourcenbereitstellung einzusehen, navigieren Sie zur Konsole. CloudFormation ](https://console.aws.amazon.com/cloudformation)
Nachdem die Clustererstellung abgeschlossen ist, sehen Sie sich den neuen **Cluster im Hauptbereich der SageMaker HyperPod Konsole unter Cluster** an. Sie können den Status in der Spalte **Status** überprüfen.
1. Wenn der Status des Clusters zu `InService` wechselt, können Sie mit der Anmeldung bei den Clusterknoten beginnen. Informationen zum Zugriff auf die Clusterknoten und zum Starten der Ausführung von ML-Workloads finden Sie unter [Jobs auf Clustern SageMaker HyperPod](sagemaker-hyperpod-run-jobs-slurm.md).
## Ressourcen konfigurieren und bereitstellen mit CloudFormation
Sie können Ressourcen konfigurieren und bereitstellen, indem Sie die CloudFormation Vorlagen für verwenden SageMaker HyperPod.
Dazu gehen Sie wie folgt vor:
1. Laden Sie eine CloudFormation Vorlage für SageMaker HyperPod aus dem [sagemaker-hyperpod-cluster-setup](https://github.com/aws/sagemaker-hyperpod-cluster-setup) GitHub Repository herunter.
1. Führen Sie den AWS CLI Befehl [create-stack](https://docs.aws.amazon.com//cli/latest/reference/cloudformation/create-stack.html) aus, um den CloudFormation Stack bereitzustellen, der die konfigurierten Ressourcen bereitstellt und den HyperPod Cluster erstellt.
```
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. Um den Status der Ressourcenbereitstellung einzusehen, navigieren Sie zur CloudFormation -Konsole.
Nachdem die Clustererstellung abgeschlossen ist, sehen Sie sich den neuen **Cluster unter Cluster** im Hauptbereich der SageMaker HyperPod Konsole an. Sie können den Status in der Spalte **Status** überprüfen.
1. Wenn der Status des Clusters zu `InService` wechselt, können Sie mit der Anmeldung bei den Clusterknoten beginnen. Informationen zum Zugriff auf die Clusterknoten und zum Starten der Ausführung von ML-Workloads finden Sie unter [Jobs auf Clustern SageMaker HyperPod](sagemaker-hyperpod-run-jobs-slurm.md).
# Erste Schritte mit der SageMaker HyperPod Verwendung von AWS CLI
Erstellen Sie Ihren ersten SageMaker HyperPod Cluster mit den AWS CLI Befehlen für HyperPod.
## Erstelle deinen ersten SageMaker HyperPod Cluster mit Slurm
Das folgende Tutorial zeigt, wie Sie mithilfe der [AWS CLI Befehle](sagemaker-hyperpod-ref.md#sagemaker-hyperpod-ref-cli) für einen neuen SageMaker HyperPod Cluster erstellen und ihn mit Slurm einrichten. SageMaker HyperPod Im Anschluss an das Tutorial erstellen Sie einen HyperPod Cluster mit drei Slurm-Knoten: `my-controller-group``my-login-group`, und. `worker-group-1`
Mit dem API-gesteuerten Konfigurationsansatz definieren Sie Slurm-Knotentypen und Partitionszuweisungen direkt in der CreateCluster API-Anfrage mithilfe von. `SlurmConfig` Dadurch entfällt die Notwendigkeit einer separaten `provisioning_parameters.json` Datei und bietet eine integrierte Validierung, Drifterkennung und Konfiguration. per-instance-group FSx
1. Bereiten Sie zunächst Lebenszyklusskripte vor und laden Sie sie in einen Amazon-S3-Bucket hoch. HyperPod Führt sie während der Clustererstellung in jeder Instanzgruppe aus. Laden Sie mithilfe des folgenden Befehls Lebenszyklusskripte in Amazon S3 hoch.
```
aws s3 sync \
~/local-dir-to-lifecycle-scripts/* \
s3://sagemaker-//src
```
**Anmerkung**
Der S3-Bucket-Pfad sollte mit einem Präfix beginnen`sagemaker-`, da die [IAM-Rolle für SageMaker HyperPod with](sagemaker-hyperpod-prerequisites-iam.md#sagemaker-hyperpod-prerequisites-iam-role-for-hyperpod) `AmazonSageMakerClusterInstanceRolePolicy` nur den Zugriff auf Amazon S3 S3-Buckets ermöglicht, die mit dem spezifischen Präfix beginnen.
Wenn Sie bei Null anfangen, verwenden Sie Lebenszyklus-Beispielskripts, die im [Awsome Distributed](https://github.com/aws-samples/awsome-distributed-training/) Training Repository bereitgestellt werden. GitHub Die folgenden Teilschritte zeigen, wie Sie die Lebenszyklus-Beispielskripts herunterladen und in einen Amazon S3 S3-Bucket hochladen.
1. Laden Sie eine Kopie der Beispiel-Lebenszyklusskripte in ein Verzeichnis auf Ihrem lokalen Computer herunter.
```
git clone https://github.com/aws-samples/awsome-distributed-training/
```
1. Gehen Sie in das Verzeichnis [https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config](https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config), in dem Sie eine Reihe von Lebenszyklusskripten finden.
```
cd awsome-distributed-training/1.architectures/5.sagemaker_hyperpods/LifecycleScripts/base-config
```
Weitere Informationen zu den Lebenszyklusskript-Beispielen finden Sie unter [Anpassen von SageMaker HyperPod Clustern mithilfe von Lifecycle-Skripten](sagemaker-hyperpod-lifecycle-best-practices-slurm.md).
1. Laden Sie die Skripte auf `s3://sagemaker-//src` hoch. Sie können dazu die Amazon-S3-Konsole oder den folgenden AWS CLI -Amazon-S3-Befehl ausführen.
```
aws s3 sync \
~/local-dir-to-lifecycle-scripts/* \
s3://sagemaker-//src
```
**Anmerkung**
Bei der API-gesteuerten Konfiguration müssen Sie keine Datei erstellen oder hochladen. `provisioning_parameters.json` Die Slurm-Konfiguration wird im nächsten Schritt direkt in der CreateCluster API-Anfrage definiert.
1. Bereiten Sie eine [CreateCluster](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_CreateCluster.html)Anforderungsdatei im JSON-Format vor und speichern Sie sie `create_cluster.json` unter.
Bei der API-gesteuerten Konfiguration geben Sie mithilfe des Felds den Slurm-Knotentyp und die Partitionszuweisung für jede Instanzgruppe an. `SlurmConfig` Sie konfigurieren auch die Slurm-Einstellungen auf Clusterebene mithilfe von. `Orchestrator.Slurm`
Geben Sie für `ExecutionRole` den ARN der IAM-Rolle an, die Sie mit der verwalteten `AmazonSageMakerClusterInstanceRolePolicy` in [Voraussetzungen für die Verwendung SageMaker HyperPod](sagemaker-hyperpod-prerequisites.md) erstellt haben.
```
{
"ClusterName": "my-hyperpod-cluster",
"InstanceGroups": [
{
"InstanceGroupName": "my-controller-group",
"InstanceType": "ml.c5.xlarge",
"InstanceCount": 1,
"SlurmConfig": {
"NodeType": "Controller"
},
"LifeCycleConfig": {
"SourceS3Uri": "s3://sagemaker-//src",
"OnCreate": "on_create.sh"
},
"ExecutionRole": "arn:aws:iam:::role/HyperPodExecutionRole",
"InstanceStorageConfigs": [
{
"EbsVolumeConfig": {
"VolumeSizeInGB": 500
}
}
]
},
{
"InstanceGroupName": "my-login-group",
"InstanceType": "ml.m5.4xlarge",
"InstanceCount": 1,
"SlurmConfig": {
"NodeType": "Login"
},
"LifeCycleConfig": {
"SourceS3Uri": "s3://sagemaker-//src",
"OnCreate": "on_create.sh"
},
"ExecutionRole": "arn:aws:iam:::role/HyperPodExecutionRole"
},
{
"InstanceGroupName": "worker-group-1",
"InstanceType": "ml.trn1.32xlarge",
"InstanceCount": 1,
"SlurmConfig": {
"NodeType": "Compute",
"PartitionNames": ["partition-1"]
},
"LifeCycleConfig": {
"SourceS3Uri": "s3://sagemaker-//src",
"OnCreate": "on_create.sh"
},
"ExecutionRole": "arn:aws:iam:::role/HyperPodExecutionRole"
}
],
"Orchestrator": {
"Slurm": {
"SlurmConfigStrategy": "Managed"
}
}
}
```
**SlurmConfig Felder**:
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/sagemaker/latest/dg/smcluster-getting-started-slurm-cli.html)
**Orchestrator.Slurm-Felder:**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/sagemaker/latest/dg/smcluster-getting-started-slurm-cli.html)
**SlurmConfigStrategy Optionen:**
+ `Managed`(empfohlen): Verwaltet `slurm.conf` und erkennt unberechtigte Änderungen HyperPod vollständig (Drift-Erkennung). Aktualisierungen schlagen fehl, wenn eine Abweichung erkannt wird.
+ `Overwrite`: HyperPod überschreibt `slurm.conf` bei Updates und ignoriert alle manuellen Änderungen.
+ `Merge`: HyperPod behält manuelle Änderungen bei und führt sie mit der API-Konfiguration zusammen.
** FSx Für Lustre hinzufügen (optional):**
Um ein FSx for Lustre-Dateisystem auf Ihren Rechenknoten zu mounten, fügen Sie es der `FsxLustreConfig` Instanzgruppe `InstanceStorageConfigs` for hinzu. Dies erfordert eine benutzerdefinierte VPC-Konfiguration.
```
{
"InstanceGroupName": "worker-group-1",
"InstanceType": "ml.trn1.32xlarge",
"InstanceCount": 1,
"SlurmConfig": {
"NodeType": "Compute",
"PartitionNames": ["partition-1"]
},
"InstanceStorageConfigs": [
{
"FsxLustreConfig": {
"DnsName": "fs-0abc123def456789.fsx.us-west-2.amazonaws.com",
"MountPath": "/fsx",
"MountName": "abcdefgh"
}
}
],
"LifeCycleConfig": {
"SourceS3Uri": "s3://sagemaker-//src",
"OnCreate": "on_create.sh"
},
"ExecutionRole": "arn:aws:iam:::role/HyperPodExecutionRole"
}
```
** FSx Für OpenZFS hinzufügen (optional):**
Sie können auch FSx für OpenZFS-Dateisysteme mounten:
```
"InstanceStorageConfigs": [
{
"FsxOpenZfsConfig": {
"DnsName": "fs-0xyz789abc123456.fsx.us-west-2.amazonaws.com",
"MountPath": "/shared"
}
}
]
```
**Anmerkung**
Jede Instanzgruppe kann höchstens eine FSx für die Lustre- und eine FSx für die OpenZFS-Konfiguration haben. Verschiedene Instanzgruppen können unterschiedliche Dateisysteme mounten.
**VPC-Konfiguration hinzufügen (erforderlich für FSx):**
Bei Verwendung FSx müssen Sie eine benutzerdefinierte VPC-Konfiguration angeben:
```
{
"ClusterName": "my-hyperpod-cluster",
"InstanceGroups": [
{
"InstanceGroupName": "my-controller-group",
"InstanceType": "ml.c5.xlarge",
"InstanceCount": 1,
"SlurmConfig": {
"NodeType": "Controller"
},
"LifeCycleConfig": {
"SourceS3Uri": "s3://sagemaker-//src",
"OnCreate": "on_create.sh"
},
"ExecutionRole": "arn:aws:iam:::role/HyperPodExecutionRole"
},
],
"Orchestrator": {
"Slurm": {
"SlurmConfigStrategy": "Managed"
}
},
"VpcConfig": {
"SecurityGroupIds": ["sg-0abc123def456789a"],
"Subnets": ["subnet-0abc123def456789a"]
}
}
```
1. Führen Sie den folgenden Befehl aus, um den Cluster zu erstellen.
```
aws sagemaker create-cluster --cli-input-json file://complete/path/to/create_cluster.json
```
Dies sollte den ARN des erstellten Clusters zurückgeben.
```
{
"ClusterArn": "arn:aws:sagemaker:us-west-2:111122223333:cluster/my-hyperpod-cluster"
}
```
Wenn Sie aufgrund von Ressourcenbeschränkungen eine Fehlermeldung erhalten, stellen Sie sicher, dass Sie den Instance-Typ in Ihrem Konto in einen mit ausreichenden Kontingenten ändern oder zusätzliche Kontingente anfordern, indem Sie den folgenden Schritten folgen.
**Häufige Validierungsfehler:**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/sagemaker/latest/dg/smcluster-getting-started-slurm-cli.html)
1. Führen Sie `describe-cluster` aus, um den Status des -Clusters zu prüfen.
```
aws sagemaker describe-cluster --cluster-name my-hyperpod-cluster
```
Beispielantwort:
```
{
"ClusterArn": "arn:aws:sagemaker:us-west-2:111122223333:cluster/my-hyperpod-cluster",
"ClusterName": "my-hyperpod-cluster",
"ClusterStatus": "Creating",
"InstanceGroups": [
{
"InstanceGroupName": "my-controller-group",
"InstanceType": "ml.c5.xlarge",
"InstanceCount": 1,
"CurrentCount": 0,
"TargetCount": 1,
"SlurmConfig": {
"NodeType": "Controller"
},
"LifeCycleConfig": {
"SourceS3Uri": "s3://sagemaker-/src",
"OnCreate": "on_create.sh"
},
"ExecutionRole": "arn:aws:iam::111122223333:role/HyperPodExecutionRole"
},
{
"InstanceGroupName": "my-login-group",
"InstanceType": "ml.m5.4xlarge",
"InstanceCount": 1,
"CurrentCount": 0,
"TargetCount": 1,
"SlurmConfig": {
"NodeType": "Login"
},
"LifeCycleConfig": {
"SourceS3Uri": "s3://sagemaker-/src",
"OnCreate": "on_create.sh"
},
"ExecutionRole": "arn:aws:iam::111122223333:role/HyperPodExecutionRole"
},
{
"InstanceGroupName": "worker-group-1",
"InstanceType": "ml.trn1.32xlarge",
"InstanceCount": 1,
"CurrentCount": 0,
"TargetCount": 1,
"SlurmConfig": {
"NodeType": "Compute",
"PartitionNames": ["partition-1"]
},
"LifeCycleConfig": {
"SourceS3Uri": "s3://sagemaker-/src",
"OnCreate": "on_create.sh"
},
"ExecutionRole": "arn:aws:iam::111122223333:role/HyperPodExecutionRole"
}
],
"Orchestrator": {
"Slurm": {
"SlurmConfigStrategy": "Managed"
}
},
"CreationTime": "2024-01-15T10:30:00Z"
}
```
Nachdem der Status des Clusters auf **InService** geändert wurde, fahren Sie mit dem nächsten Schritt fort. Die Clustererstellung dauert in der Regel 10 bis 15 Minuten.
1. Führen Sie `list-cluster-nodes` aus, um die Details der Clusterknoten zu überprüfen.
```
aws sagemaker list-cluster-nodes --cluster-name my-hyperpod-cluster
```
Beispielantwort:
```
{
"ClusterNodeSummaries": [
{
"InstanceGroupName": "my-controller-group",
"InstanceId": "i-0abc123def456789a",
"InstanceType": "ml.c5.xlarge",
"InstanceStatus": {
"Status": "Running",
"Message": ""
},
"LaunchTime": "2024-01-15T10:35:00Z"
},
{
"InstanceGroupName": "my-login-group",
"InstanceId": "i-0abc123def456789b",
"InstanceType": "ml.m5.4xlarge",
"InstanceStatus": {
"Status": "Running",
"Message": ""
},
"LaunchTime": "2024-01-15T10:35:00Z"
},
{
"InstanceGroupName": "worker-group-1",
"InstanceId": "i-0abc123def456789c",
"InstanceType": "ml.trn1.32xlarge",
"InstanceStatus": {
"Status": "Running",
"Message": ""
},
"LaunchTime": "2024-01-15T10:36:00Z"
}
]
}
```
`InstanceId`Das benötigen Ihre Cluster-Benutzer, um sich bei ihnen anzumelden (`aws ssm`). Weitere Informationen zur Anmeldung bei den Clusterknoten und zum Ausführen von ML-Workloads finden Sie unter [Jobs auf Clustern SageMaker HyperPod](sagemaker-hyperpod-run-jobs-slurm.md).
1. Stellen Sie mithilfe von AWS Systems Manager Session Manager eine Connect zu Ihrem Cluster her.
```
aws ssm start-session \
--target sagemaker-cluster:my-hyperpod-cluster_my-login-group-i-0abc123def456789b \
--region us-west-2
```
Sobald die Verbindung hergestellt ist, stellen Sie sicher, dass Slurm korrekt konfiguriert ist:
```
# Check Slurm nodes
sinfo
# Check Slurm partitions
sinfo -p partition-1
# Submit a test job
srun -p partition-1 --nodes=1 hostname
```
## Löschen des Clusters und Bereinigen der Ressourcen
Nachdem Sie die Erstellung eines SageMaker HyperPod Clusters erfolgreich getestet haben, läuft er im `InService` Status weiter, bis Sie den Cluster löschen. Wir empfehlen, dass Sie alle Cluster löschen, die mithilfe von SageMaker On-Demand-KI-Kapazität erstellt wurden, wenn sie nicht genutzt werden, um zu vermeiden, dass weitere Servicegebühren aufgrund von On-Demand-Preisen anfallen. In diesem Tutorial haben Sie einen Cluster erstellt, der aus drei Instanzgruppen besteht. Stellen Sie sicher, dass Sie den Cluster löschen, indem Sie den folgenden Befehl ausführen.
```
aws sagemaker delete-cluster --cluster-name my-hyperpod-cluster
```
Um die Lebenszyklusskripte aus dem für dieses Tutorial verwendeten Amazon-S3-Bucket zu bereinigen, wechseln Sie zu dem Amazon-S3-Bucket, den Sie bei der Clustererstellung verwendet haben, und entfernen Sie die Dateien vollständig.
```
aws s3 rm s3://sagemaker-//src --recursive
```
Wenn Sie die Ausführung von Modelltraining-Workloads auf dem Cluster getestet haben, überprüfen Sie auch, ob Sie Daten hochgeladen haben oder ob Ihr Job Artefakte in verschiedenen Amazon S3 S3-Buckets oder Dateisystemdiensten wie Amazon FSx for Lustre und Amazon Elastic File System gespeichert hat. Um Gebühren zu vermeiden, löschen Sie alle Artefakte und Daten aus dem Speicher- oder Dateisystem.
## Verwandte Themen
+ [SageMaker HyperPod Slurm-Konfiguration](sagemaker-hyperpod-ref.md#sagemaker-hyperpod-ref-slurm-configuration)
+ [Anpassen von SageMaker HyperPod Clustern mithilfe von Lifecycle-Skripten](sagemaker-hyperpod-lifecycle-best-practices-slurm.md)
+ [FSx Konfiguration über InstanceStorageConfigs](sagemaker-hyperpod-ref.md#sagemaker-hyperpod-ref-slurm-fsx-config)
+ [SageMaker HyperPod Slurm-Clusteroperationen](sagemaker-hyperpod-operate-slurm.md)
# SageMaker HyperPod Slurm-Clusteroperationen
Dieser Abschnitt enthält Anleitungen zur Verwaltung SageMaker HyperPod über die Benutzeroberfläche der SageMaker AI-Konsole oder die AWS Command Line Interface (CLI). Sie erfahren, wie Sie verschiedene Aufgaben ausführen können SageMaker HyperPod, je nachdem, ob Sie eine visuelle Oberfläche bevorzugen oder mit Befehlen arbeiten.
**Topics**
+ [Verwaltung von SageMaker HyperPod Slurm-Clustern über die Konsole SageMaker](sagemaker-hyperpod-operate-slurm-console-ui.md)
+ [Verwaltung von SageMaker HyperPod Slurm-Clustern mit dem AWS CLI](sagemaker-hyperpod-operate-slurm-cli-command.md)
# Verwaltung von SageMaker HyperPod Slurm-Clustern über die Konsole SageMaker
Die folgenden Themen enthalten Anleitungen zur Verwaltung SageMaker HyperPod über die Benutzeroberfläche der Konsole.
**Topics**
+ [Erstellen Sie einen SageMaker HyperPod Cluster](#sagemaker-hyperpod-operate-slurm-console-ui-create-cluster)
+ [Durchsuchen Sie Ihre SageMaker HyperPod Cluster](#sagemaker-hyperpod-operate-slurm-console-ui-browse-clusters)
+ [Details zu den einzelnen SageMaker HyperPod Clustern anzeigen](#sagemaker-hyperpod-operate-slurm-console-ui-view-details-of-clusters)
+ [Bearbeiten Sie einen SageMaker HyperPod Cluster](#sagemaker-hyperpod-operate-slurm-console-ui-edit-clusters)
+ [Löschen Sie einen SageMaker HyperPod Cluster](#sagemaker-hyperpod-operate-slurm-console-ui-delete-cluster)
## Erstellen Sie einen SageMaker HyperPod Cluster
Anweisungen finden Sie unter [Erste Schritte mit der SageMaker HyperPod Verwendung der SageMaker KI-Konsole](smcluster-getting-started-slurm-console.md) So erstellen Sie einen neuen SageMaker HyperPod Cluster über die Benutzeroberfläche der SageMaker HyperPod Konsole.
## Durchsuchen Sie Ihre SageMaker HyperPod Cluster
Unter **Cluster** im Hauptbereich der SageMaker HyperPod Konsole auf der Hauptseite der SageMaker HyperPod Konsole sollten alle erstellten Cluster im Abschnitt **Cluster** aufgeführt werden, der eine Zusammenfassung der Cluster ARNs, ihres Status und der Erstellungszeit bietet.
## Details zu den einzelnen SageMaker HyperPod Clustern anzeigen
Unter **Cluster** auf der Hauptseite der Konsole sind die **Clusternamen** als Links aktiviert. Wählen Sie den Link zum Clusternamen aus, um Details zu den einzelnen Clustern anzuzeigen.
## Bearbeiten Sie einen SageMaker HyperPod Cluster
1. Wählen Sie im Hauptbereich der SageMaker HyperPod Konsole unter **Cluster** den Cluster aus, den Sie aktualisieren möchten.
1. Wählen Sie Ihren Cluster aus und klicken Sie auf **Bearbeiten**.
1. Auf der Seite ** bearbeiten** können Sie die Konfigurationen bestehender Instance-Gruppen bearbeiten, weitere Instance-Gruppen hinzufügen, Instance-Gruppen löschen und Tags für den Cluster ändern. Nachdem Sie die Änderungen vorgenommen haben, wählen Sie **Absenden** aus.
1. Im Abschnitt **Instance-Gruppen konfigurieren** können Sie weitere Instance-Gruppen hinzufügen, indem Sie **Instance-Gruppe erstellen** auswählen.
1. Im Abschnitt **Instance-Gruppen konfigurieren** können Sie **Bearbeiten** auswählen, um die Konfiguration zu ändern, oder **Löschen**, um die Instance-Gruppe dauerhaft zu entfernen.
**Wichtig**
Berücksichtigen Sie beim Löschen einer Instance-Gruppe die folgenden Punkte:
Ihr SageMaker HyperPod Cluster muss immer mindestens eine Instanzgruppe verwalten.
Stellen Sie sicher, dass alle wichtigen Daten gesichert sind, bevor Sie sie entfernen.
Die Entfernung kann nicht rückgängig gemacht werden.
**Anmerkung**
Durch das Löschen einer Instance-Gruppe werden alle mit dieser Gruppe verknüpften Rechenressourcen beendet.
1. Im Abschnitt **Tags** können Sie die Tags für den Cluster aktualisieren.
## Löschen Sie einen SageMaker HyperPod Cluster
1. Wählen Sie im Hauptbereich der SageMaker HyperPod Konsole unter **Cluster** den Cluster aus, den Sie löschen möchten.
1. Wählen Sie Ihren Cluster aus und klicken Sie auf **Löschen**.
1. Überprüfen Sie im Popup-Fenster für das Löschen von Clustern die Clusterinformationen sorgfältig, um sicherzustellen, dass Sie den richtigen Cluster zum Löschen ausgewählt haben.
1. Nachdem Sie die Clusterinformationen überprüft haben, wählen Sie **Ja, Cluster löschen** aus.
1. Geben Sie im Textfeld zur Bestätigung dieser Löschung **delete** ein.
1. Wählen Sie in der unteren rechten Ecke des Popup-Fensters **Löschen** aus, um das Senden der Anfrage zum Löschen des Clusters abzuschließen.
# Verwaltung von SageMaker HyperPod Slurm-Clustern mit dem AWS CLI
Die folgenden Themen enthalten Anleitungen zum Schreiben von SageMaker HyperPod API-Anforderungsdateien im JSON-Format und zum Ausführen dieser Dateien mithilfe der AWS CLI Befehle.
**Topics**
+ [Erstellen eines neuen Clusters](#sagemaker-hyperpod-operate-slurm-cli-command-create-cluster)
+ [Beschreiben eines Clusters](#sagemaker-hyperpod-operate-slurm-cli-command-describe-cluster)
+ [Listet die Details der Clusterknoten auf](#sagemaker-hyperpod-operate-slurm-cli-command-list-cluster-nodes)
+ [Beschreiben der Details eines Cluster-Knotens](#sagemaker-hyperpod-operate-slurm-cli-command-describe-cluster-node)
+ [Auflisten von Clustern](#sagemaker-hyperpod-operate-slurm-cli-command-list-clusters)
+ [Aktualisieren der Clusterkonfiguration](#sagemaker-hyperpod-operate-slurm-cli-command-update-cluster)
+ [Aktualisieren Sie die SageMaker HyperPod Plattformsoftware eines Clusters](#sagemaker-hyperpod-operate-slurm-cli-command-update-cluster-software)
+ [Herunterskalieren eines Clusters](#sagemaker-hyperpod-operate-slurm-cli-command-scale-down)
+ [Einen Cluster löschen](#sagemaker-hyperpod-operate-slurm-cli-command-delete-cluster)
## Erstellen eines neuen Clusters
1. Bereiten Sie Skripte zur Lebenszykluskonfiguration vor und laden Sie sie in einen S3-Bucket hoch, z. B. `s3://sagemaker-amzn-s3-demo-bucket/lifecycle-script-directory/src/`. Im folgenden Schritt 2 wird davon ausgegangen, dass sich im angegebenen S3-Bucket ein Einstiegspunktskript namens `on_create.sh` befindet.
**Wichtig**
Legen Sie den S3-Pfad so fest, dass er mit `s3://sagemaker-` beginnt. An [IAM-Rolle für SageMaker HyperPod](sagemaker-hyperpod-prerequisites-iam.md#sagemaker-hyperpod-prerequisites-iam-role-for-hyperpod) ist die verwaltete [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) angefügt, wodurch der Zugriff auf S3-Buckets mit dem spezifischen Präfix `sagemaker-` ermöglicht wird.
1. Bereiten Sie eine [CreateCluster](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_CreateCluster.html)API-Anforderungsdatei im JSON-Format vor. Sie sollten Instance-Gruppen so konfigurieren, dass sie mit dem Slurm-Cluster übereinstimmen, den Sie in der `provisioning_parameters.json`-Datei entwerfen, die während der Clustererstellung als Teil der Ausführung einer Reihe von Lebenszyklusskripten verwendet wird. Weitere Informationen hierzu finden Sie unter [Anpassen von SageMaker HyperPod Clustern mithilfe von Lifecycle-Skripten](sagemaker-hyperpod-lifecycle-best-practices-slurm.md). Die folgende Vorlage enthält zwei Instance-Gruppen, um die Mindestanforderungen für einen Slurm-Cluster zu erfüllen: einen Controller-Knoten (Head) und einen Rechenknoten (Worker). Geben Sie für `ExecutionRole` den ARN der IAM-Rolle an, die Sie mit der verwalteten `AmazonSageMakerClusterInstanceRolePolicy` aus Abschnitt [IAM-Rolle für SageMaker HyperPod](sagemaker-hyperpod-prerequisites-iam.md#sagemaker-hyperpod-prerequisites-iam-role-for-hyperpod) erstellt haben.
```
// create_cluster.json
{
"ClusterName": "your-hyperpod-cluster",
"InstanceGroups": [
{
"InstanceGroupName": "controller-group",
"InstanceType": "ml.m5.xlarge",
"InstanceCount": 1,
"LifeCycleConfig": {
"SourceS3Uri": "s3://amzn-s3-demo-bucket-sagemaker/lifecycle-script-directory/src/",
"OnCreate": "on_create.sh"
},
"ExecutionRole": "arn:aws:iam::111122223333:role/iam-role-for-cluster",
// Optional: Configure an additional storage per instance group.
"InstanceStorageConfigs": [
{
// Attach an additional EBS volume to each instance within the instance group.
// The default mount path for the additional EBS volume is /opt/sagemaker.
"EbsVolumeConfig":{
// Specify an integer between 1 and 16384 in gigabytes (GB).
"VolumeSizeInGB": integer,
}
}
]
},
{
"InstanceGroupName": "worker-group-1",
"InstanceType": "ml.p4d.xlarge",
"InstanceCount": 1,
"LifeCycleConfig": {
"SourceS3Uri": "s3://amzn-s3-demo-bucket-sagemaker/lifecycle-script-directory/src/",
"OnCreate": "on_create.sh"
},
"ExecutionRole": "arn:aws:iam::111122223333:role/iam-role-for-cluster"
}
],
// Optional
"Tags": [
{
"Key": "string",
"Value": "string"
}
],
// Optional
"VpcConfig": {
"SecurityGroupIds": [ "string" ],
"Subnets": [ "string" ]
}
}
```
Je nachdem, wie Sie die Clusterstruktur mithilfe Ihrer Lebenszyklusskripte entwerfen, können Sie bis zu 20 Instance-Gruppen unter dem `InstanceGroups`-Parameter konfigurieren.
Für den `Tags` Anforderungsparameter können Sie benutzerdefinierte Tags hinzufügen, um den SageMaker HyperPod Cluster als AWS Ressource zu verwalten. Sie können Ihrem Cluster auf die gleiche Weise Tags hinzufügen, wie Sie sie in anderen AWS Diensten hinzufügen, die Tagging unterstützen. Weitere Informationen zum Taggen von AWS Ressourcen im Allgemeinen finden Sie im [Tagging AWS Resources User Guide](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html).
Geben Sie für den `VpcConfig`-Anforderungsparameter die Informationen einer VPC an, die Sie verwenden möchten. Weitere Informationen finden Sie unter [Einrichtung SageMaker HyperPod mit einer benutzerdefinierten Amazon VPC](sagemaker-hyperpod-prerequisites.md#sagemaker-hyperpod-prerequisites-optional-vpc).
1. Führen Sie den Befehl [create-cluster](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/create-cluster.html) aus, um den Cluster zu erstellen.
```
aws sagemaker create-cluster \
--cli-input-json file://complete/path/to/create_cluster.json
```
Dies sollte den ARN des neuen Clusters zurückgeben.
## Beschreiben eines Clusters
Führen Sie [describe-cluster](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/describe-cluster.html) aus, um den Status des Clusters zu prüfen. Sie können entweder den Namen oder den ARN des Clusters angeben.
```
aws sagemaker describe-cluster --cluster-name your-hyperpod-cluster
```
Nachdem der Status des Clusters auf **InService** geändert wurde, fahren Sie mit dem nächsten Schritt fort. Mit dieser API können Sie auch Fehlermeldungen aus anderen HyperPod API-Vorgängen abrufen.
## Listet die Details der Clusterknoten auf
Führen Sie aus [list-cluster-nodes](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/list-cluster-nodes.html), um die wichtigsten Informationen der Clusterknoten zu überprüfen.
```
aws sagemaker list-cluster-nodes --cluster-name your-hyperpod-cluster
```
Dies gibt eine Antwort zurück und Ihre Cluster-Benutzer benötigen `InstanceId` für die Protokollierung (Verwendung von `aws ssm`) in ihnen.
## Beschreiben der Details eines Cluster-Knotens
Ausführen [describe-cluster-node](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/describe-cluster-node.html), um Details eines Clusterknotens abzurufen. Sie können die Clusterknoten-ID aus der list-cluster-nodes Ausgabe abrufen. Sie können entweder den Namen oder den ARN des Clusters angeben.
```
aws sagemaker describe-cluster-node \
--cluster-name your-hyperpod-cluster \
--node-id i-111222333444555aa
```
## Auflisten von Clustern
Führen Sie [list-clusters](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/list-clusters.html) aus, um alle Cluster in Ihrem Konto aufzulisten.
```
aws sagemaker list-clusters
```
Sie können auch zusätzliche Flags hinzufügen, um die Liste der Cluster zu filtern. Weitere Informationen darüber, wie dieser Befehl auf niedriger Ebene ausgeführt wird, und weitere Flags zum Filtern finden Sie in der [ListClusters](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_ListClusters.html)API-Referenz.
## Aktualisieren der Clusterkonfiguration
Führen Sie [update-cluster](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/update-cluster.html) aus, um die Konfiguration eines Clusters zu aktualisieren.
**Anmerkung**
Sie können die `UpdateCluster` API verwenden, um ganze Instanzgruppen aus Ihrem SageMaker HyperPod Cluster zu verkleinern oder sie zu entfernen. Weitere Anweisungen zum Herunterskalieren oder Löschen von Instance-Gruppen finden Sie unter [Herunterskalieren eines Clusters](#sagemaker-hyperpod-operate-slurm-cli-command-scale-down).
1. Erstellen Sie eine `UpdateCluster`-Anforderungsdatei im JSON-Format. Stellen Sie sicher, dass Sie den richtigen Clusternamen und Instance-Gruppennamen für die Aktualisierung angeben. Sie können den Instance-Typ, die Anzahl der Instances, das Einstiegspunktskript für die Lebenszykluskonfiguration und den Pfad zum Skript ändern.
1. Geben Sie für `ClusterName` den Namen des Clusters an, den Sie aktualisieren möchten.
1. Für `InstanceGroupName`
1. Um eine bestehende Instance-Gruppe zu aktualisieren, geben Sie den Namen der Instance-Gruppe an, die Sie aktualisieren möchten.
1. Um eine neue Instance-Gruppe hinzuzufügen, geben Sie einen neuen Namen an, der in Ihrem Cluster nicht vorhanden ist.
1. Für `InstanceType`
1. Um eine bestehende Instance-Gruppe zu aktualisieren, müssen Sie den Instance-Typ, den Sie ursprünglich angegeben haben, der Gruppe zuordnen.
1. Um eine neue Instance-Gruppe hinzuzufügen, geben Sie einen Instance-Typ an, mit dem Sie die Gruppe konfigurieren möchten.
1. Für `InstanceCount`
1. Um eine bestehende Instance-Gruppe zu aktualisieren, geben Sie eine Ganzzahl an, die der gewünschten Anzahl von Instances entspricht. Sie können einen höheren oder niedrigeren Wert (bis 0) angeben, um die Instance-Gruppe herauf- oder herunterskalieren.
1. Um eine neue Instance-Gruppe hinzuzufügen, geben Sie eine Ganzzahl größer oder gleich 1 an.
1. Für `LifeCycleConfig` können Sie die Werte `SourceS3Uri` und `OnCreate` ändern, wenn Sie die Instance-Gruppe aktualisieren möchten.
1. Für `ExecutionRole`
1. Verwenden Sie zum Aktualisieren einer vorhandenen Instance-Gruppe weiterhin dieselbe IAM-Rolle, die Sie bei der Clustererstellung zugewiesen haben.
1. Um eine neue Instance-Gruppe hinzuzufügen, geben Sie eine IAM-Rolle an, die Sie anfügen möchten.
1. Für `ThreadsPerCore`
1. Verwenden Sie zum Aktualisieren einer vorhandenen Instance-Gruppe weiterhin denselben Wert, den Sie bei der Clustererstellung zugewiesen haben.
1. Um eine neue Instance-Gruppe hinzuzufügen, können Sie einen beliebigen Wert aus den zulässigen Optionen pro Instance-Typ auswählen. Weitere Informationen finden Sie unter dem Instance-Typ und in der Spalte **Gültige Threads pro Kern** in der Referenztabelle unter [CPU-Kerne und Threads pro CPU-Kern pro Instance-Typ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/cpu-options-supported-instances-values.html) im *Benutzerhandbuch für Amazon EC2*.
Der folgende Codeausschnitt ist eine JSON-Anforderungsdateivorlage, die Sie verwenden können. Weitere Informationen zur Anforderungssyntax und zu den Parametern dieser API finden Sie in der [UpdateCluster](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_UpdateCluster.html)API-Referenz.
```
// update_cluster.json
{
// Required
"ClusterName": "name-of-cluster-to-update",
// Required
"InstanceGroups": [
{
"InstanceGroupName": "name-of-instance-group-to-update",
"InstanceType": "ml.m5.xlarge",
"InstanceCount": 1,
"LifeCycleConfig": {
"SourceS3Uri": "s3://amzn-s3-demo-bucket-sagemaker/lifecycle-script-directory/src/",
"OnCreate": "on_create.sh"
},
"ExecutionRole": "arn:aws:iam::111122223333:role/iam-role-for-cluster",
// Optional: Configure an additional storage per instance group.
"InstanceStorageConfigs": [
{
// Attach an additional EBS volume to each instance within the instance group.
// The default mount path for the additional EBS volume is /opt/sagemaker.
"EbsVolumeConfig":{
// Specify an integer between 1 and 16384 in gigabytes (GB).
"VolumeSizeInGB": integer,
}
}
]
},
// add more blocks of instance groups as needed
{ ... }
]
}
```
1. Führen Sie den folgenden `update-cluster`-Befehl aus, um die Anfrage einzureichen.
```
aws sagemaker update-cluster \
--cli-input-json file://complete/path/to/update_cluster.json
```
## Aktualisieren Sie die SageMaker HyperPod Plattformsoftware eines Clusters
Führen Sie aus [update-cluster-software](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/update-cluster-software.html), um vorhandene Cluster mit Software und Sicherheitspatches zu aktualisieren, die vom SageMaker HyperPod Dienst bereitgestellt werden. Für `--cluster-name` geben Sie entweder den Namen oder den ARN des zu aktualisierenden Clusters an.
**Wichtig**
Vor der Ausführung dieser API müssen Sie eine Sicherungskopie Ihrer Arbeit erstellen. Der Patching-Prozess ersetzt das Root-Volume durch das aktualisierte AMI, was bedeutet, dass Ihre zuvor im Root-Volume der Instance gespeicherten Daten verloren gehen. Stellen Sie sicher, dass Sie Ihre Daten vom Instance-Root-Volume auf Amazon S3 oder Amazon FSx for Lustre sichern. Weitere Informationen finden Sie unter [Verwenden Sie das Backup-Skript von SageMaker HyperPod](#sagemaker-hyperpod-operate-slurm-cli-command-update-cluster-software-backup).
```
aws sagemaker update-cluster-software --cluster-name your-hyperpod-cluster
```
Dieser Befehl ruft die [UpdateClusterSoftware](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_UpdateClusterSoftware.html)API auf. SageMaker HyperPod Prüft nach dem API-Aufruf, ob ein neueres DLAMI für die Clusterinstanzen verfügbar ist. Wenn ein DLAMI-Update erforderlich ist, SageMaker HyperPod werden die Cluster-Instances so aktualisiert, dass sie die neuesten Versionen verwenden, [SageMaker HyperPod DLAMI](sagemaker-hyperpod-ref.md#sagemaker-hyperpod-ref-hyperpod-ami) und Ihre Lifecycle-Skripte in dem Amazon S3 S3-Bucket ausführen, den Sie bei der Cluster-Erstellung oder -Aktualisierung angegeben haben. Wenn der Cluster bereits das neueste DLAMI verwendet, nimmt er keine Änderungen am Cluster vor und SageMaker HyperPod führt die Lebenszyklusskripts nicht erneut aus. Das SageMaker HyperPod Serviceteam bringt regelmäßig neue [SageMaker HyperPod DLAMI](sagemaker-hyperpod-ref.md#sagemaker-hyperpod-ref-hyperpod-ami) Funktionen zur Erhöhung der Sicherheit und Verbesserung der Benutzererfahrung auf den Markt. Wir empfehlen Ihnen, immer auf die neueste Version von SageMaker HyperPod DLAMI zu aktualisieren. Für future SageMaker HyperPod DLAMI-Updates für Sicherheitspatches folgen Sie bitte. [SageMaker HyperPod Versionshinweise von Amazon](sagemaker-hyperpod-release-notes.md)
**Tipp**
Wenn der Sicherheitspatch fehlschlägt, können Sie Fehlermeldungen abrufen, indem Sie die [https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_DescribeCluster.html](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_DescribeCluster.html)-API wie unter [Beschreiben eines Clusters](#sagemaker-hyperpod-operate-slurm-cli-command-describe-cluster) beschrieben ausführen.
**Anmerkung**
Sie können diese API nur programmgesteuert ausführen. Die Patching-Funktionalität ist nicht in der Benutzeroberfläche der Konsole implementiert. SageMaker HyperPod
### Verwenden Sie das Backup-Skript von SageMaker HyperPod
SageMaker HyperPod bietet ein Skript zum Sichern und Wiederherstellen Ihrer Daten [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/patching-backup.sh](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/patching-backup.sh)im *Awsome Distributed Training GitHub Repository*. Das Skript stellt die folgenden zwei Funktionen zur Verfügung.
**So sichern Sie Daten vor dem Patchen in einem S3-Bucket**
```
sudo bash patching-backup.sh --create
```
Nachdem Sie den Befehl ausgeführt haben, überprüft das Skript `squeue`, ob sich Aufträge in der Warteschlange befinden, beendet Slurm, wenn dies nicht der Fall ist, erstellt ein Backup von `mariadb` und kopiert lokale Elemente auf die unter `LOCAL_ITEMS` definierte Festplatte. Sie können weitere Dateien und Verzeichnisse zu `LOCAL_ITEMS` hinzufügen.
```
# Define files and directories to back up.
LOCAL_ITEMS=(
"/var/spool/slurmd"
"/var/spool/slurmctld"
"/etc/systemd/system/slurmctld.service"
"/home/ubuntu/backup_slurm_acct_db.sql"
# ... Add more items as needed
)
```
Sie können dem bereitgestellten Skript auch benutzerdefinierten Code hinzufügen, um alle Anwendungen für Ihren Anwendungsfall zu sichern.
**So stellen Sie Daten nach dem Patchen aus einem S3-Bucket wieder her**
```
sudo bash patching-backup.sh --restore
```
## Herunterskalieren eines Clusters
Sie können die Anzahl der Instanzen reduzieren oder Instanzgruppen in Ihrem SageMaker HyperPod Cluster löschen, um die Ressourcenzuweisung zu optimieren oder die Kosten zu senken.
Sie skalieren die Instance-Gruppe entweder mithilfe der `UpdateCluster`-API-Operation herunter, um Instances aus Ihrer Instance-Gruppe nach dem Zufallsprinzip bis auf eine bestimmte Anzahl zu reduzieren, oder indem Sie bestimmte Instances mithilfe der `BatchDeleteClusterNodes`-API-Operation beenden. Mithilfe der `UpdateCluster`-API können Sie auch ganze Instance-Gruppen vollständig entfernen. Weitere Informationen zum Herunterskalieren diesen Methoden finden Sie unter [Einen SageMaker HyperPod Cluster herunterskalieren](smcluster-scale-down.md).
**Anmerkung**
Sie können keine Instances entfernen, die als Slurm-Controller-Knoten konfiguriert sind. Der Versuch, einen Slurm-Controller-Knoten zu löschen, führt zu einem Validierungsfehler mit dem Fehlercode `NODE_ID_IN_USE`.
## Einen Cluster löschen
Führen Sie [delete-cluster](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/delete-cluster.html) aus, um einen Cluster zu löschen. Sie können entweder den Namen oder den ARN des Clusters angeben.
```
aws sagemaker delete-cluster --cluster-name your-hyperpod-cluster
```
# Anpassen von SageMaker HyperPod Clustern mithilfe von Lifecycle-Skripten
SageMaker HyperPod bietet up-and-running Always-Compute-Cluster, die in hohem Maße anpassbar sind, da Sie Lebenszyklus-Skripte schreiben können, die angeben, SageMaker HyperPod wie die Cluster-Ressourcen eingerichtet werden. Die folgenden Themen enthalten bewährte Methoden für die Vorbereitung von Lebenszyklusskripten für die Einrichtung von SageMaker HyperPod Clustern mit Open-Source-Workload-Manager-Tools.
In den folgenden Themen werden ausführliche bewährte Methoden für die Vorbereitung von Lifecycle-Skripten für die Einrichtung von Slurm-Konfigurationen erörtert. SageMaker HyperPod
## Allgemeine Übersicht
Das folgende Verfahren ist der Hauptablauf für die Bereitstellung eines HyperPod Clusters und dessen Einrichtung mit Slurm. Die Schritte werden dabei ***von unten nach oben*** angeordnet.
1. Planen Sie, wie Sie Slurm-Knoten auf einem Cluster erstellen möchten. HyperPod Wenn Sie beispielsweise zwei Slurm-Knoten konfigurieren möchten, müssen Sie zwei Instanzgruppen in einem HyperPod Cluster einrichten.
1. Bereiten Sie die Slurm-Konfiguration vor. Wählen Sie einen der folgenden Ansätze:
+ **Option A: API-gesteuerte Konfiguration (empfohlen)** — Definieren Sie Slurm-Knotentypen und -partitionen direkt in der `CreateCluster` API-Payload und verwenden Sie sie `SlurmConfig` innerhalb jeder Instanzgruppe. Mit diesem Ansatz:
+ Es wird keine `provisioning_parameters.json` Datei benötigt
+ Die Slurm-Topologie ist in der API-Nutzlast zusammen mit den Definitionen der Instanzgruppen definiert
+ FSx Dateisysteme werden konfiguriert über per-instance-group `InstanceStorageConfigs`
+ Die Konfigurationsstrategie wird gesteuert über `Orchestrator.Slurm.SlurmConfigStrategy`
Beispiel `SlurmConfig` in einer Instanzgruppe:
```
{
"InstanceGroupName": "gpu-compute",
"InstanceType": "ml.p4d.24xlarge",
"InstanceCount": 8,
"SlurmConfig": {
"NodeType": "Compute",
"PartitionNames": ["gpu-training"]
}
}
```
+ **Option B: Legacy-Konfiguration** — Bereiten Sie eine `provisioning_parameters.json` Datei vor, bei der es sich um eine[Konfigurationsformular für provisioning\$1parameters.json](sagemaker-hyperpod-ref.md#sagemaker-hyperpod-ref-provisioning-forms-slurm). `provisioning_parameters.json`sollte Informationen zur Konfiguration des Slurm-Knotens enthalten, der HyperPod auf dem Cluster bereitgestellt werden soll. Dies sollte das Design der Slurm-Knotens aus Schritt 1 widerspiegeln.
1. Bereiten Sie eine Reihe von Lifecycle-Skripten vor, auf denen Slurm eingerichtet werden HyperPod soll, um Softwarepakete zu installieren und eine Umgebung im Cluster für Ihren Anwendungsfall einzurichten. Sie sollten die Lebenszyklusskripte so strukturieren, dass sie gemeinsam in einem zentralen Python-Skript (`lifecycle_script.py`) ausgeführt werden, und ein Einstiegspunkt-Shell-Skript (`on_create.sh`) schreiben, um das Python-Skript auszuführen. Das Entrypoint-Shell-Skript müssen Sie später in Schritt 5 für eine Anfrage zur HyperPod Clustererstellung bereitstellen.
Beachten Sie außerdem, dass Sie beim Schreiben der Skripts davon ausgehen sollten`resource_config.json`, dass sie HyperPod bei der Clustererstellung generiert werden. `resource_config.json`enthält HyperPod Cluster-Ressourceninformationen wie IP-Adressen, Instanztypen und, und ist genau das ARNs, was Sie für die Konfiguration von Slurm verwenden müssen.
1. Sammeln Sie alle Dateien aus den vorherigen Schritten in einem Ordner. Die Ordnerstruktur hängt vom Konfigurationsansatz ab, den Sie in Schritt 2 ausgewählt haben.
Wenn Sie Option A (API-gesteuerte Konfiguration) ausgewählt haben:
Ihr Ordner benötigt nur Lebenszyklusskripts für benutzerdefinierte Einrichtungsaufgaben. Die Konfiguration und FSx das Mounten von Slurm werden automatisch auf der HyperPod Grundlage der API-Payload durchgeführt.
```
└── lifecycle_files // your local folder
├── on_create.sh
├── lifecycle_script.py
└── ... // more setup scripts to be fed into lifecycle_script.py
```
**Anmerkung**
Die `provisioning_parameters.json` Datei ist bei Verwendung einer API-gesteuerten Konfiguration nicht erforderlich.
Wenn Sie Option B (Legacy-Konfiguration) ausgewählt haben:
Ihr Ordner muss den vollständigen Satz von Lebenszyklus-Skripten enthalten`provisioning_parameters.json`.
```
└── lifecycle_files // your local folder
├── provisioning_parameters.json
├── on_create.sh
├── lifecycle_script.py
└── ... // more setup scrips to be fed into lifecycle_script.py
```
1. Laden Sie alle Dateien in einen S3-Bucket hoch. Kopieren Sie den S3-Bucket-Pfad und behalten Sie ihn. Beachten Sie, dass Sie einen S3-Bucket-Pfad erstellen sollten, der mit `sagemaker-` beginnt, da Sie eine [IAM-Rolle für SageMaker HyperPod](sagemaker-hyperpod-prerequisites-iam.md#sagemaker-hyperpod-prerequisites-iam-role-for-hyperpod) auswählen müssen, an die [`AmazonSageMakerClusterInstanceRolePolicy`](security-iam-awsmanpol-AmazonSageMakerClusterInstanceRolePolicy.md) angefügt ist, wodurch nur S3-Bucket-Pfade zulässig sind, die mit dem Präfix `sagemaker-` beginnen. Der folgende Befehl ist ein Beispielbefehl zum Hochladen aller Dateien in einen S3-Bucket.
```
aws s3 cp --recursive ./lifecycle_files s3://sagemaker-hyperpod-lifecycle/src
```
1. Bereiten Sie eine Anfrage zur HyperPod Clustererstellung vor.
+ Option 1: Wenn Sie die verwenden AWS CLI, schreiben Sie eine Anfrage zur Clustererstellung im JSON-Format (`create_cluster.json`) gemäß den Anweisungen unter[Erstellen eines neuen Clusters](sagemaker-hyperpod-operate-slurm-cli-command.md#sagemaker-hyperpod-operate-slurm-cli-command-create-cluster).
+ Option 2: Wenn Sie die Benutzeroberfläche der SageMaker AI-Konsole verwenden, füllen Sie das Formular „**Clusteranfrage erstellen**“ in der Benutzeroberfläche der HyperPod Konsole aus. Folgen Sie dabei den Anweisungen unter[Erstellen Sie einen SageMaker HyperPod Cluster](sagemaker-hyperpod-operate-slurm-console-ui.md#sagemaker-hyperpod-operate-slurm-console-ui-create-cluster).
Stellen Sie in dieser Phase sicher, dass Sie Instance-Gruppen in derselben Struktur erstellen, die Sie in Schritt 1 und 2 geplant haben. Achten Sie außerdem darauf, dass Sie den S3-Bucket aus Schritt 5 in den Anforderungsformularen angeben.
1. Reichen Sie die Anfrage zur Clustererstellung ein. HyperPod stellt auf der Grundlage der Anfrage einen Cluster bereit, erstellt dann eine `resource_config.json` Datei in den HyperPod Cluster-Instanzen und richtet Slurm auf dem Cluster ein, auf dem die Lifecycle-Skripten ausgeführt werden.
Die folgenden Themen führen Sie durch die einzelnen Schritte und gehen detailliert darauf ein, wie Sie Konfigurationsdateien und Lebenszyklusskripte so organisieren, dass sie bei der HyperPod Clustererstellung ordnungsgemäß funktionieren.
**Topics**
+ [Allgemeine Übersicht](#sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-highlevel-overview)
+ [Die grundlegenden Lebenszyklusskripte werden bereitgestellt von HyperPod](sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-base-config.md)
+ [Welche speziellen Konfigurationen werden in Slurm-Konfigurationsdateien verwaltet HyperPod](sagemaker-hyperpod-lifecycle-best-practices-slurm-what-hyperpod-overrides-in-slurm-conf.md)
+ [Rotationen im Slurm-Protokoll](sagemaker-hyperpod-slurm-log-rotation.md)
+ [Einbinden von Amazon FSx for Lustre und Amazon FSx for OpenZFS in einem Cluster HyperPod](sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-setup-with-fsx.md)
+ [Validierung der JSON-Konfigurationsdateien vor der Erstellung eines Slurm-Clusters auf HyperPod](sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-validate-json-files.md)
+ [Validierung der Laufzeit vor der Ausführung von Produktionsworkloads auf einem Slurm-Cluster HyperPod](sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-validate-runtime.md)
+ [Interaktive Entwicklung von Lebenszyklus-Skripten auf einem Clusterknoten HyperPod](sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-develop-lifecycle-scripts.md)
# Die grundlegenden Lebenszyklusskripte werden bereitgestellt von HyperPod
In diesem Abschnitt werden Sie von oben nach ***unten durch alle Komponenten des grundlegenden Ablaufs der Einrichtung von Slurm geführt***. HyperPod Es beginnt mit der Vorbereitung einer Anfrage zur HyperPod Clustererstellung zur Ausführung der `CreateCluster` API und taucht tief in die hierarchische Struktur ein, bis hin zu Lebenszyklus-Skripten. Verwenden Sie die Beispiel-Lebenszyklus-Skripte, die im [Awsome Distributed Training GitHub ](https://github.com/aws-samples/awsome-distributed-training/) Repository bereitgestellt werden. Klonen Sie das Repository, indem Sie den folgenden Befehl ausführen.
```
git clone https://github.com/aws-samples/awsome-distributed-training/
```
Die grundlegenden Lebenszyklus-Skripte für die Einrichtung eines Slurm-Clusters SageMaker HyperPod finden Sie unter. [https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config](https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config)
```
cd awsome-distributed-training/1.architectures/5.sagemaker_hyperpods/LifecycleScripts/base-config
```
Das folgende Flussdiagramm zeigt eine detaillierte Übersicht darüber, wie Sie die Basis-Lebenszyklusskripte gestalten sollten. In den Beschreibungen unter dem Diagramm und dem Verfahrensleitfaden wird erklärt, wie sie während des HyperPod `CreateCluster` API-Aufrufs funktionieren.
![\[Ein detailliertes Flussdiagramm der HyperPod Clustererstellung und der Struktur von Lebenszyklusskripten.\]](http://docs.aws.amazon.com/de_de/sagemaker/latest/dg/images/hyperpod-lifecycle-structure.png)
***Abbildung:** Ein detailliertes Flussdiagramm der HyperPod Clustererstellung und der Struktur von Lebenszyklusskripten. (1) Die gestrichelten Pfeile zeigen in die Richtung, in die die Kästen „aufgerufen“ werden, und veranschaulichen den Ablauf der Vorbereitung von Konfigurationsdateien und Lebenszyklusskripten. Der erste Schritt besteht in der Vorbereitung von `provisioning_parameters.json` und den Lebenszyklusskripten. Diese werden dann für eine gemeinsame Ausführung in der richtigen Reihenfolge in `lifecycle_script.py` codiert. Und die Ausführung des `lifecycle_script.py` Skripts erfolgt durch das `on_create.sh` Shell-Skript, das im HyperPod Instanzterminal ausgeführt werden soll. (2) Die durchgezogenen Pfeile zeigen den Hauptablauf bei der HyperPod Clustererstellung und wie die Boxen „aufgerufen“ oder „eingereicht“ werden. `on_create.sh`ist für die Anfrage zur Clustererstellung erforderlich, entweder im Formular zur **Clustererstellung `create_cluster.json` oder im Formular zur Clustererstellung** in der Benutzeroberfläche der Konsole. Nachdem Sie die Anfrage eingereicht haben, HyperPod wird die `CreateCluster` API auf der Grundlage der angegebenen Konfigurationsinformationen aus der Anfrage und den Lebenszyklusskripts ausgeführt. (3) Der gepunktete Pfeil weist darauf hin, dass die HyperPod Plattform während der Bereitstellung von Clusterressourcen Instances `resource_config.json` in den Clustern erstellt. `resource_config.json`enthält HyperPod Clusterressourceninformationen wie den Cluster-ARN, Instanztypen und IP-Adressen. Es ist wichtig zu beachten, dass Sie die Lebenszyklusskripte so vorbereiten sollten, dass sie die `resource_config.json`-Datei während der Clustererstellung erwarten. Weitere Informationen finden Sie in der folgenden Verfahrensanleitung.*
In der folgenden Anleitung wird erklärt, was bei der HyperPod Clustererstellung passiert und wie die grundlegenden Lebenszyklusskripts entworfen werden.
1. `create_cluster.json`— Um eine Anfrage zur HyperPod Clustererstellung einzureichen, bereiten Sie eine `CreateCluster` Anforderungsdatei im JSON-Format vor. In diesem Beispiel für bewährte Methoden gehen wir davon aus, dass die Anforderungsdatei `create_cluster.json` heißt. Schreiben Sie`create_cluster.json`, um einen HyperPod Cluster mit Instanzgruppen bereitzustellen. Es hat sich bewährt, die gleiche Anzahl von Instanzgruppen hinzuzufügen wie die Anzahl der Slurm-Knoten, die Sie auf dem HyperPod Cluster konfigurieren möchten. Stellen Sie sicher, dass Sie den Instance-Gruppen, die Sie den Slurm-Knoten zuweisen möchten, eindeutige Namen geben.
Außerdem müssen Sie einen S3-Bucket-Pfad angeben, um Ihren gesamten Satz an Konfigurationsdateien und Lebenszyklusskripten im Feldnamen `InstanceGroups.LifeCycleConfig.SourceS3Uri` im `CreateCluster`-Anforderungsformular zu speichern, und den Dateinamen eines Einstiegspunkt-Shell-Skripts (angenommen, es heißt `on_create.sh`) als `InstanceGroups.LifeCycleConfig.OnCreate` angeben.
**Anmerkung**
Wenn Sie das Formular „**Cluster erstellen**“ in der Benutzeroberfläche der HyperPod Konsole verwenden, verwaltet die Konsole das Ausfüllen und Senden der `CreateCluster` Anfrage in Ihrem Namen und führt die `CreateCluster` API im Backend aus. In diesem Fall müssen Sie `create_cluster.json` nicht erstellen. Achten Sie stattdessen darauf, dass Sie die richtigen Informationen zur Cluster-Konfiguration in das zu übermittelnde Formular **Cluster erstellen** eingeben.
1. `on_create.sh`— Für jede Instanzgruppe müssen Sie ein Einstiegs-Shell-Skript bereitstellen, um Befehle auszuführen`on_create.sh`, Skripte zur Installation von Softwarepaketen auszuführen und die HyperPod Clusterumgebung mit Slurm einzurichten. Die beiden Dinge, die Sie vorbereiten müssen, sind ein `provisioning_parameters.json` erforderliches HyperPod für die Einrichtung von Slurm und eine Reihe von Lifecycle-Skripten für die Installation von Softwarepaketen. Dieses Skript sollte so geschrieben werden, dass es die folgenden Dateien findet und ausführt, wie im Beispielskript unter [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/on_create.sh](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/on_create.sh) gezeigt.
**Anmerkung**
Stellen Sie sicher, dass Sie den gesamten Satz von Lebenszyklusskripten an den in den S3-Speicherort hochladen, den Sie in `create_cluster.json` angeben. Sie sollten Ihre `provisioning_parameters.json` auch an demselben Speicherort speichern.
1. `provisioning_parameters.json`— Das ist ein[Konfigurationsformular für provisioning\$1parameters.json](sagemaker-hyperpod-ref.md#sagemaker-hyperpod-ref-provisioning-forms-slurm). Das `on_create.sh`-Skript findet diese JSON-Datei und definiert eine Umgebungsvariable, um den Pfad zu ihr zu identifizieren. Über diese JSON-Datei können Sie Slurm-Knoten und Speicheroptionen wie Amazon FSx for Lustre for Slurm für die Kommunikation konfigurieren. Stellen Sie sicher`provisioning_parameters.json`, dass Sie die HyperPod Cluster-Instanzgruppen mit den Namen, die Sie angegeben haben, den Slurm-Knoten entsprechend zuweisen, je nachdem, wie Sie sie einrichten möchten. `create_cluster.json`
Das folgende Diagramm zeigt ein Beispiel dafür, wie die beiden JSON-Konfigurationsdateien `create_cluster.json` geschrieben werden `provisioning_parameters.json` sollten, um den HyperPod Slurm-Knoten Instanzgruppen zuzuweisen. In diesem Beispiel gehen wir von der Einrichtung von drei Slurm-Knoten aus: Controller-Knoten (Verwaltung), Anmeldeknoten (optional) und Rechenknoten (Worker).
**Tipp**
Um Ihnen bei der Validierung dieser beiden JSON-Dateien zu helfen, stellt das HyperPod Serviceteam ein Validierungsskript zur Verfügung. [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/validate-config.py](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/validate-config.py) Weitere Informationen hierzu finden Sie unter [Validierung der JSON-Konfigurationsdateien vor der Erstellung eines Slurm-Clusters auf HyperPod](sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-validate-json-files.md).
![\[Direkter Vergleich zwischen .json-Dateien.\]](http://docs.aws.amazon.com/de_de/sagemaker/latest/dg/images/hyperpod-lifecycle-slurm-config.png)
***Abbildung:** Direkter Vergleich zwischen `create_cluster.json` der HyperPod Clustererstellung und `provisiong_params.json` der Slurm-Konfiguration. Die Anzahl der Instance-Gruppen in `create_cluster.json` sollte der Anzahl der Knoten entsprechen, die Sie als Slurm-Knoten konfigurieren möchten. Im Fall des Beispiels in der Abbildung werden drei Slurm-Knoten auf einem HyperPod Cluster aus drei Instanzgruppen konfiguriert. Sie sollten die HyperPod Cluster-Instanzgruppen den Slurm-Knoten zuweisen, indem Sie die Namen der Instanzgruppen entsprechend angeben.*
1. `resource_config.json`— Während der Clustererstellung wird das `lifecycle_script.py` Skript so geschrieben, dass es eine `resource_config.json` Datei von HyperPod erwartet. Diese Datei enthält Informationen über den Cluster, z. B. Instance-Typen und IP-Adressen.
Wenn Sie die `CreateCluster` API ausführen, HyperPod erstellt es eine Ressourcenkonfigurationsdatei unter, die auf der `create_cluster.json` Datei `/opt/ml/config/resource_config.json` basiert. Der Dateipfad wird in der Umgebungsvariablen namens `SAGEMAKER_RESOURCE_CONFIG_PATH` gespeichert.
**Wichtig**
Die `resource_config.json` Datei wird automatisch von der HyperPod Plattform generiert und Sie müssen sie NICHT erstellen. Der folgende Code zeigt ein Beispiel für `resource_config.json`, die aus der Clustererstellung basierend auf `create_cluster.json` im vorherigen Schritt erstellt würde, und soll Ihnen helfen zu verstehen, was im Backend geschieht und wie eine automatisch generierte `resource_config.json` aussehen würde.
```
{
"ClusterConfig": {
"ClusterArn": "arn:aws:sagemaker:us-west-2:111122223333:cluster/abcde01234yz",
"ClusterName": "your-hyperpod-cluster"
},
"InstanceGroups": [
{
"Name": "controller-machine",
"InstanceType": "ml.c5.xlarge",
"Instances": [
{
"InstanceName": "controller-machine-1",
"AgentIpAddress": "111.222.333.444",
"CustomerIpAddress": "111.222.333.444",
"InstanceId": "i-12345abcedfg67890"
}
]
},
{
"Name": "login-group",
"InstanceType": "ml.m5.xlarge",
"Instances": [
{
"InstanceName": "login-group-1",
"AgentIpAddress": "111.222.333.444",
"CustomerIpAddress": "111.222.333.444",
"InstanceId": "i-12345abcedfg67890"
}
]
},
{
"Name": "compute-nodes",
"InstanceType": "ml.trn1.32xlarge",
"Instances": [
{
"InstanceName": "compute-nodes-1",
"AgentIpAddress": "111.222.333.444",
"CustomerIpAddress": "111.222.333.444",
"InstanceId": "i-12345abcedfg67890"
},
{
"InstanceName": "compute-nodes-2",
"AgentIpAddress": "111.222.333.444",
"CustomerIpAddress": "111.222.333.444",
"InstanceId": "i-12345abcedfg67890"
},
{
"InstanceName": "compute-nodes-3",
"AgentIpAddress": "111.222.333.444",
"CustomerIpAddress": "111.222.333.444",
"InstanceId": "i-12345abcedfg67890"
},
{
"InstanceName": "compute-nodes-4",
"AgentIpAddress": "111.222.333.444",
"CustomerIpAddress": "111.222.333.444",
"InstanceId": "i-12345abcedfg67890"
}
]
}
]
}
```
1. `lifecycle_script.py`— Dies ist das wichtigste Python-Skript, das gemeinsam Lifecycle-Skripte ausführt, die Slurm auf dem HyperPod Cluster einrichten, während es bereitgestellt wird. Dieses Skript liest in `provisioning_parameters.json` und `resource_config.json` aus den in `on_create.sh` angegebenen oder identifizierten Pfaden, übergibt die relevanten Informationen an jedes Lebenszyklusskript und führt dann die Lebenszyklusskripte der Reihe nach aus.
Lebenszyklusskripte sind eine Reihe von Skripten, die Sie vollständig flexibel anpassen können, um Softwarepakete zu installieren und während der Clustererstellung notwendige oder benutzerdefinierte Konfigurationen vorzunehmen, z. B. Slurm einrichten, Benutzer anlegen, Conda oder Docker installieren. Das [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/lifecycle_script.py](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/lifecycle_script.py)Beispielskript ist darauf vorbereitet, andere grundlegende Lebenszyklusskripte im Repository auszuführen, z. B. Slurm deamons ([https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/start_slurm.sh](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/start_slurm.sh)) zu starten, Amazon FSx for Lustre () zu mounten und MariaDB-Buchhaltung ([https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/mount_fsx.sh](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/mount_fsx.sh)) und RDS-Buchhaltung ([https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/setup_mariadb_accounting.sh](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/setup_mariadb_accounting.sh)) einzurichten. [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/setup_rds_accounting.sh](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/setup_rds_accounting.sh) Sie können auch weitere Skripte hinzufügen, sie in dasselbe Verzeichnis packen und Codezeilen hinzufügen, um die Skripte ausführen zu `lifecycle_script.py` lassen. HyperPod Weitere Informationen zu den grundlegenden Lebenszyklus-Skripten finden Sie auch unter [3.1 Lifecycle-Skripten](https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod#31-lifecycle-scripts) im *Awsome Distributed Training GitHub Repository*.
**Anmerkung**
HyperPod läuft [SageMaker HyperPod DLAMI](sagemaker-hyperpod-ref.md#sagemaker-hyperpod-ref-hyperpod-ami) auf jeder Instanz eines Clusters, und das AMI verfügt über vorinstallierte Softwarepakete, die Kompatibilitäten zwischen ihnen und Funktionen erfüllen. HyperPod Beachten Sie, dass Sie bei der Neuinstallation eines der vorinstallierten Pakete für die Installation kompatibler Pakete verantwortlich sind und beachten Sie, dass einige HyperPod Funktionen möglicherweise nicht wie erwartet funktionieren.
Zusätzlich zu den Standardeinstellungen sind weitere Skripte zur Installation der folgenden Software im [https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/utils](https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/utils)-Ordner verfügbar. Die `lifecycle_script.py`-Datei enthält bereits Codezeilen zum Ausführen der Installationsskripte. Suchen Sie diese Zeilen anhand der folgenden Angaben und entfernen Sie die Kommentare, um sie zu aktivieren.
1. Die folgenden Codezeilen beziehen sich auf die Installation von [Docker](https://www.docker.com/), [Enroot](https://github.com/NVIDIA/enroot) und [Pyxis](https://github.com/NVIDIA/pyxis). Diese Pakete sind erforderlich, um Docker-Container auf einem Slurm-Cluster auszuführen.
Um diesen Installationsschritt zu aktivieren, legen Sie den `enable_docker_enroot_pyxis`-Parameter in der [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/config.py](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/config.py)-Datei auf `True` fest.
```
# Install Docker/Enroot/Pyxis
if Config.enable_docker_enroot_pyxis:
ExecuteBashScript("./utils/install_docker.sh").run()
ExecuteBashScript("./utils/install_enroot_pyxis.sh").run(node_type)
```
1. Sie können Ihren HyperPod Cluster mit [Amazon Managed Service for Prometheus und Amazon Managed](https://docs.aws.amazon.com/prometheus/latest/userguide/what-is-Amazon-Managed-Service-Prometheus.html) [Grafana](https://docs.aws.amazon.com/grafana/latest/userguide/what-is-Amazon-Managed-Service-Grafana.html) integrieren, um Metriken über den HyperPod Cluster und die Clusterknoten in Amazon Managed Grafana-Dashboards zu exportieren. Um Metriken zu exportieren und das [Slurm-Dashboard](https://grafana.com/grafana/dashboards/4323-slurm-dashboard/), das [Dashboard von NVIDIA DCGM Exporter](https://grafana.com/grafana/dashboards/12239-nvidia-dcgm-exporter-dashboard/) und das [EFA-Metrics-Dashboard](https://grafana.com/grafana/dashboards/20579-efa-metrics-dev/) auf Amazon Managed Grafana zu verwenden, müssen Sie den [Slurm-Exporter für Prometheus](https://github.com/vpenso/prometheus-slurm-exporter), den [NVIDIA-DCGM-Exporter](https://github.com/NVIDIA/dcgm-exporter) und den [EFA-Knoten-Exporter](https://github.com/aws-samples/awsome-distributed-training/blob/main/4.validation_and_observability/3.efa-node-exporter/README.md) installieren. Weitere Informationen zur Installation der Exportpakete und zur Verwendung von Grafana-Dashboards in einem Workspace von Amazon Managed Grafana finden Sie unter [SageMaker HyperPod Überwachung der Cluster-Ressourcen](sagemaker-hyperpod-cluster-observability-slurm.md).
Um diesen Installationsschritt zu aktivieren, legen Sie den `enable_observability`-Parameter in der [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/config.py](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/config.py)-Datei auf `True` fest.
```
# Install metric exporting software and Prometheus for observability
if Config.enable_observability:
if node_type == SlurmNodeType.COMPUTE_NODE:
ExecuteBashScript("./utils/install_docker.sh").run()
ExecuteBashScript("./utils/install_dcgm_exporter.sh").run()
ExecuteBashScript("./utils/install_efa_node_exporter.sh").run()
if node_type == SlurmNodeType.HEAD_NODE:
wait_for_scontrol()
ExecuteBashScript("./utils/install_docker.sh").run()
ExecuteBashScript("./utils/install_slurm_exporter.sh").run()
ExecuteBashScript("./utils/install_prometheus.sh").run()
```
1. Stellen Sie sicher, dass Sie alle Konfigurationsdateien und Einrichtungsskripte aus **Schritt 2** in den S3-Bucket hochladen, den Sie in der `CreateCluster`-Anforderung in **Schritt 1** angegeben haben. Nehmen wir beispielsweise an, dass Ihre `create_cluster.json` Folgendes enthält.
```
"LifeCycleConfig": {
"SourceS3URI": "s3://sagemaker-hyperpod-lifecycle/src",
"OnCreate": "on_create.sh"
}
```
Dann sollte ihr `on_create.sh`, `lifecycle_script.py`, `provisioning_parameters.json` und alle anderen Einrichtungsskripte enthalten. Angenommen, Sie haben die Dateien wie folgt in einem lokalen Ordner vorbereitet.
```
└── lifecycle_files // your local folder
├── provisioning_parameters.json
├── on_create.sh
├── lifecycle_script.py
└── ... // more setup scrips to be fed into lifecycle_script.py
```
Verwenden Sie den S3-Befehl wie folgt, um die Dateien hochzuladen.
```
aws s3 cp --recursive ./lifecycle_scripts s3://sagemaker-hyperpod-lifecycle/src
```
# Welche speziellen Konfigurationen werden in Slurm-Konfigurationsdateien verwaltet HyperPod
Wenn Sie einen Slurm-Cluster erstellen HyperPod, richtet der HyperPod Agent die [https://slurm.schedmd.com/gres.conf.html](https://slurm.schedmd.com/gres.conf.html)Dateien [https://slurm.schedmd.com/slurm.conf.html](https://slurm.schedmd.com/slurm.conf.html)und die Dateien unter ein, `/opt/slurm/etc/` um den Slurm-Cluster auf der Grundlage Ihrer Anfrage zur Clustererstellung und Ihrer HyperPod Lebenszyklusskripte zu verwalten. Die folgende Liste zeigt, welche spezifischen Parameter der HyperPod Agent verarbeitet und überschreibt.
**Wichtig**
Es wird dringend empfohlen, diese von HyperPod verwalteten Parameter **nicht** zu ändern.
+ [https://slurm.schedmd.com/slurm.conf.html](https://slurm.schedmd.com/slurm.conf.html)In HyperPod richtet die folgenden grundlegenden Parameter ein: `ClusterName``SlurmctldHost`,`PartitionName`, und`NodeName`.
Um die [Automatische Knotenwiederherstellung und automatische Wiederaufnahme](sagemaker-hyperpod-resiliency-slurm-auto-resume.md) Funktionalität zu aktivieren, HyperPod müssen außerdem die `SchedulerParameters` Parameter `TaskPlugin` und wie folgt festgelegt werden. Der HyperPod Agent richtet diese beiden Parameter standardmäßig mit den erforderlichen Werten ein.
```
TaskPlugin=task/none
SchedulerParameters=permit_job_expansion
```
+ In [https://slurm.schedmd.com/gres.conf.html](https://slurm.schedmd.com/gres.conf.html), HyperPod verwaltet `NodeName` für GPU-Knoten.
# Rotationen im Slurm-Protokoll
SageMaker HyperPod bietet automatische Protokollrotation für Slurm-Daemon-Logs, um die Speicherplatznutzung zu verwalten und die Systemleistung aufrechtzuerhalten. Die Rotation von Protokollen ist entscheidend, um zu verhindern, dass Protokolle übermäßig viel Speicherplatz beanspruchen, und um einen optimalen Systembetrieb sicherzustellen, indem alte Protokolldateien automatisch archiviert und entfernt werden, während die aktuellen Protokollierungsinformationen beibehalten werden. Slurm-Protokollrotationen sind standardmäßig aktiviert, wenn Sie einen Cluster erstellen.
## Wie funktioniert die Log-Rotation
Wenn diese Option aktiviert ist, gilt für die Konfiguration der Protokollrotation Folgendes:
+ Überwacht alle Slurm-Protokolldateien mit der Erweiterung, die `.log` sich im `/var/log/slurm/` Ordner auf den Controller-, Anmelde- und Rechenknoten befinden.
+ Dreht die Protokolle, wenn sie eine Größe von 50 MB erreichen.
+ Behält bis zu zwei rotierte Protokolldateien bei, bevor sie gelöscht werden.
+ Sendet nach der Rotation SIGUSR2 ein Signal an die Slurm-Daemons (`slurmctld``slurmd`, und`slurmdbd`).
## Liste der rotierten Protokolldateien
Slurm-Logs befinden sich im `/var/log/slurm/` Verzeichnis. Die Protokollrotation ist für alle `/var/log/slurm/*.log` übereinstimmenden Dateien aktiviert. Wenn eine Rotation stattfindet, haben rotierte Dateien numerische Suffixe (z. B.`slurmd.log.1`). Die folgende Liste erhebt keinen Anspruch auf Vollständigkeit, zeigt jedoch einige der kritischen Protokolldateien, die automatisch rotieren:
+ `/var/log/slurm/slurmctld.log`
+ `/var/log/slurm/slurmd.log`
+ `/var/log/slurm/slurmdb.log`
+ `/var/log/slurm/slurmrestd.log`
## Aktivieren oder deaktivieren Sie die Protokollrotation
Sie können die Funktion zur Protokollrotation mithilfe des `enable_slurm_log_rotation` Parameters im `config.py` Skript der Lifecycle-Skripten Ihres Clusters steuern, wie im folgenden Beispiel gezeigt:
```
class Config:
# Set false if you want to disable log rotation of Slurm daemon logs
enable_slurm_log_rotation = True # Default value
```
Um die Log-Rotation zu deaktivieren, setzen Sie den Parameter auf`False`, wie im folgenden Beispiel gezeigt:
```
enable_slurm_log_rotation = False
```
**Anmerkung**
Lifecycle-Skripten werden während der Clustererstellung auf allen Slurm-Knoten (Controller-, Anmelde- und Rechenknoten) ausgeführt. Sie werden auch auf neuen Knoten ausgeführt, wenn sie dem Cluster hinzugefügt werden. Die Aktualisierung der Protokollrotationskonfigurationen muss nach der Clustererstellung manuell erfolgen. Die Konfiguration der Protokollrotation ist in gespeichert`/etc/logrotate.d/sagemaker-hyperpod-slurm`. Wir empfehlen, die Protokollrotation aktiviert zu lassen, um zu verhindern, dass Protokolldateien übermäßig viel Speicherplatz beanspruchen. Um die Protokollrotation zu deaktivieren, löschen Sie die `sagemaker-hyperpod-slurm` Datei oder kommentieren Sie ihren Inhalt, indem Sie `#` am Anfang jeder Zeile in der `sagemaker-hyperpod-slurm` Datei etwas hinzufügen.
## Standardeinstellungen für die Protokollrotation
Die folgenden Einstellungen werden automatisch für jede rotierte Protokolldatei konfiguriert:
| Einstellung | Wert | Description |
| --- | --- | --- |
| rotate | 2 | Anzahl der rotierten Protokolldateien, die aufbewahrt werden sollen |
| size | 50 MB | Maximale Größe vor der Rotation |
| copytruncate | aktiviert | Kopiert und kürzt die ursprüngliche Protokolldatei |
| compress | disabled | Rotierte Protokolle werden nicht komprimiert |
| missingok | aktiviert | Kein Fehler, wenn die Protokolldatei fehlt |
| notifempty | aktiviert | Rotiert keine leeren Dateien |
| noolddir | aktiviert | Rotierte Dateien bleiben im selben Verzeichnis |
# Einbinden von Amazon FSx for Lustre und Amazon FSx for OpenZFS in einem Cluster HyperPod
Um ein gemeinsam genutztes Amazon FSx for Lustre-Dateisystem in Ihren HyperPod Cluster einzubinden, richten Sie Folgendes ein.
1. Verwenden Sie Ihre Amazon-VPC.
1. Damit HyperPod Cluster-Instances innerhalb Ihrer VPC kommunizieren können, stellen Sie sicher, dass Sie die der [Einrichtung SageMaker HyperPod mit einer benutzerdefinierten Amazon VPC](sagemaker-hyperpod-prerequisites.md#sagemaker-hyperpod-prerequisites-optional-vpc) IAM-Rolle für zuordnen. SageMaker HyperPod
1. Fügen Sie in `create_cluster.json` die folgenden VPC-Informationen ein.
```
"VpcConfig": {
"SecurityGroupIds": [ "string" ],
"Subnets": [ "string" ]
}
```
Weitere Tipps zur Einrichtung von Amazon VPC finden Sie unter [Voraussetzungen für die Verwendung SageMaker HyperPod](sagemaker-hyperpod-prerequisites.md).
1. Um die Konfiguration von Slurm mit Amazon FSx for Lustre abzuschließen, können Sie einen der folgenden Ansätze verwenden. Sie finden die FSx Amazon-Informationen entweder in der Amazon FSx for Lustre-Konsole in Ihrem Konto oder indem Sie den folgenden AWS CLI Befehl ausführen:. `aws fsx describe-file-systems`
**Option A: API-gesteuerte Konfiguration (empfohlen)**
Geben Sie die FSx Amazon-Konfiguration direkt in der CreateCluster API-Nutzlast an und verwenden Sie sie `InstanceStorageConfigs` innerhalb jeder Instanzgruppe. Dieser Ansatz unterstützt sowohl FSx Lustre als auch OpenZFS und FSx ermöglicht die Konfiguration. per-instance-group FSx
```
"InstanceStorageConfigs": [
{
"FsxLustreConfig": {
"DnsName": "fs-12345678a90b01cde.fsx.us-west-2.amazonaws.com",
"MountPath": "/fsx",
"MountName": "1abcdefg"
}
}
]
```
Verwenden Sie FSx für OpenZFS stattdessen: `FsxOpenZfsConfig`
```
"InstanceStorageConfigs": [
{
"FsxOpenZfsConfig": {
"DnsName": "fs-12345678a90b01cde.fsx.us-west-2.amazonaws.com",
"MountPath": "/fsx-openzfs"
}
}
]
```
Weitere Informationen finden Sie unter [Erste Schritte mit der SageMaker HyperPod Verwendung der AWS CLI](sagemaker-hyperpod-quickstart.md).
**Option B: Legacy-Konfiguration**
Geben Sie den FSx Amazon-DNS-Namen und den FSx Amazon-Mount-Namen an, `provisioning_parameters.json` wie in der Abbildung im [Die grundlegenden Lebenszyklusskripte werden bereitgestellt von HyperPod](sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-base-config.md) Abschnitt gezeigt.
```
"fsx_dns_name": "fs-12345678a90b01cde.fsx.us-west-2.amazonaws.com",
"fsx_mountname": "1abcdefg"
```
# Validierung der JSON-Konfigurationsdateien vor der Erstellung eines Slurm-Clusters auf HyperPod
Verwenden Sie das Konfigurationsvalidierungsskript [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/validate-config.py](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/validate-config.py), um die JSON-Konfigurationsdateien zu validieren, bevor Sie ein Anforderung zur Clustererstellung übermitteln. Dieses Skript analysiert und vergleicht Ihre HyperPod Cluster-Konfigurations-JSON-Datei und die Slurm-Konfigurations-JSON-Datei und ermittelt, ob zwischen den beiden Dateien und auch zwischen Amazon EC2-, Amazon VPC- und Amazon-Ressourcen eine Fehlkonfiguration der Ressourcen vorliegt. FSx Um beispielsweise die Dateien `provisioning_parameters.json` und `create_cluster.json` aus dem [Die grundlegenden Lebenszyklusskripte werden bereitgestellt von HyperPod](sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-base-config.md)-Abschnitt zu validieren, führen Sie das Validierungsskript wie folgt aus.
```
python3 validate-config.py --cluster-config create_cluster.json --provisioning-parameters provisioning_parameters.json
```
Im Folgenden finden Sie eine Beispielausgabe für eine erfolgreiche Validierung.
```
✔️ Validated instance group name worker-group-1 is correct ...
✔️ Validated subnet subnet-012345abcdef67890 ...
✔️ Validated security group sg-012345abcdef67890 ingress rules ...
✔️ Validated security group sg-012345abcdef67890 egress rules ...
✔️ Validated FSx Lustre DNS name fs-012345abcdef67890.fsx.us-east-1.amazonaws.com
✔️ Validated FSx Lustre mount name abcdefgh
✅ Cluster Validation succeeded
```
# Validierung der Laufzeit vor der Ausführung von Produktionsworkloads auf einem Slurm-Cluster HyperPod
Verwenden Sie das Runtime-Validierungsskript, um die Laufzeit zu überprüfen HyperPod, bevor Sie Produktions-Workloads auf einem Slurm-Cluster ausführen. [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/hyperpod-precheck.py](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/hyperpod-precheck.py) Dieses Skript prüft, ob auf dem Slurm-Cluster alle Pakete für die Ausführung von Docker installiert sind, ob der Cluster über ein ordnungsgemäß FSx für Lustre gemountetes Dateisystem und ein Benutzerverzeichnis verfügt, das das Dateisystem gemeinsam nutzt, und ob der Slurm-Daemon auf allen Rechenknoten läuft.
Um das Skript auf mehreren Knoten gleichzeitig auszuführen, verwenden Sie `srun`, wie im folgenden Beispielbefehl zum Ausführen des Skripts auf einem Slurm-Cluster mit 8 Knoten gezeigt.
```
# The following command runs on 8 nodes
srun -N 8 python3 hyperpod-precheck.py
```
**Anmerkung**
Weitere Informationen zum Validierungsskript, z. B. zu den Funktionen zur Laufzeitvalidierung, die das Skript bietet, und Richtlinien zur Lösung von Problemen, die die Validierungen nicht bestehen, finden Sie unter [Laufzeitvalidierung vor dem Ausführen von Workloads](https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod#35-runtime-validation-before-running-workloads) im *Awsome Distributed GitHub Training-Repository*.
# Interaktive Entwicklung von Lebenszyklus-Skripten auf einem Clusterknoten HyperPod
In diesem Abschnitt wird erklärt, wie Sie interaktiv Lebenszyklusskripts entwickeln können, ohne wiederholt einen HyperPod Cluster erstellen und löschen zu müssen.
1. Erstellen Sie einen HyperPod Cluster mit den grundlegenden Lebenszyklusskripten.
1. Melden Sie sich bei einem Clusterknoten an.
1. Entwickeln Sie ein Skript (`configure_xyz.sh`), indem Sie es auf dem Knoten bearbeiten und wiederholt ausführen.
1. HyperPod führt die Lebenszyklusskripts als Root-Benutzer aus. Wir empfehlen daher, dass Sie das während der Entwicklung `configure_xyz.sh` als Root-Benutzer ausführen, um sicherzustellen, dass das Skript unter derselben Bedingung getestet wird, während es von ausgeführt wird HyperPod.
1. Integrieren Sie das Skript in `lifecycle_script.py`, indem Sie eine Codezeile ähnlich der folgenden hinzufügen.
```
ExecuteBashScript("./utils/configure_xyz.sh").run()
```
1. Laden Sie die aktualisierten Lebenszyklusskripte in den S3-Bucket hoch, den Sie ursprünglich für das Hochladen der grundlegenden Lebenszyklusskripte verwendet haben.
1. Testen Sie die integrierte Version von, `lifecycle_script.py` indem Sie einen neuen HyperPod Cluster erstellen. Sie können auch den manuellen Instanzersatz verwenden, um die aktualisierten Lebenszyklusskripts zu testen, indem Sie neue Instanzen erstellen. Eine ausführliche Anleitung finden Sie unter [Manuelles Ersetzen eines Knotens](https://docs.aws.amazon.com//sagemaker/latest/dg/sagemaker-hyperpod-resiliency-slurm-replace-faulty-instance.html#sagemaker-hyperpod-resiliency-slurm-replace-faulty-instance-replace). Beachten Sie, dass nur Worker-Knoten austauschbar sind.
# SageMaker HyperPod Unterstützung für Multi-Head-Knoten
Sie können mehrere Controller-Knoten (Head) in einem einzigen SageMaker HyperPod Slurm-Cluster erstellen, wobei einer als primärer Controller-Knoten und die anderen als Backup-Controller-Knoten dienen. Der primäre Controller-Knoten ist für die Steuerung der Rechenknoten (Worker-Knoten) und die Verarbeitung der Slurm-Operationen zuständig. Die Backup-Controller-Knoten überwachen den primären Controller-Knoten konstant. Wenn der primäre Controller-Knoten ausfällt oder nicht mehr reagiert, übernimmt einer der Backup-Controller-Knoten automatisch die Position des neuen primären Controller-Knotens.
Die Konfiguration mehrerer Controller-Knoten in SageMaker HyperPod Slurm-Clustern bietet mehrere wichtige Vorteile. Sie eliminiert das Risiko eines Ausfalls eines einzelnen Controller-Knotens durch die Bereitstellung von Controller-Hauptknoten, ermöglicht ein automatisches Failover auf Backup-Controller-Knoten mit schnellerer Wiederherstellung und ermöglicht Ihnen die unabhängige Verwaltung Ihrer eigenen Buchhaltungsdatenbanken und Slurm-Konfiguration.
## Die wichtigsten Konzepte
Im Folgenden finden Sie Einzelheiten zu den Konzepten im Zusammenhang mit der Unterstützung SageMaker HyperPod mehrerer Controller- (Kopf-) Knoten für Slurm-Cluster.
**Controller-Knoten**
Ein Controller-Knoten ist eine Amazon-EC2-Instance innerhalb eines Clusters, auf der wichtige Slurm-Services zur Verwaltung und Koordination der Cluster-Operationen ausgeführt werden. Insbesondere hostet er den [Slurm-Controller-Daemon (slurmctld)](https://slurm.schedmd.com/slurmctld.html) und den [Slurm-Datenbank-Daemon (slurmdbd)](https://slurm.schedmd.com/slurmdbd.html). Ein Controller-Knoten wird auch als Hauptknoten bezeichnet.
**Primärer Controller-Knoten**
Ein primärer Controller-Knoten ist der aktive und aktuell steuernde Controller-Knoten in einem Slurm-Cluster. Es wird von Slurm als primärer Controller-Knoten identifiziert, der für die Verwaltung des Clusters verantwortlich ist. Der primäre Controller-Knoten empfängt und führt Befehle von Benutzern aus, um Ressourcen auf den Rechenknoten für die Ausführung von Aufträgen zu steuern und zuzuweisen.
**Backup-Controller-Knoten**
Ein Backup-Controller-Knoten ist ein inaktiver und Standby-Controller-Knoten in einem Slurm-Cluster. Er wird von Slurm als Backup-Controller-Knoten identifiziert, der den Cluster derzeit nicht verwaltet. Auf dem Backup-Controller-Knoten wird der [Slurm-Controller-Daemon (slurmctld](https://slurm.schedmd.com/slurmctld.html)) im Standby-Modus ausgeführt. Alle Controller-Befehle, die auf den Backup-Controller-Knoten ausgeführt werden, werden zur Ausführung an den primären Controller-Knoten weitergegeben. Sein Hauptzweck besteht darin, den primären Controller-Knoten kontinuierlich zu überwachen und dessen Aufgaben zu übernehmen, wenn der primäre Controller-Knoten ausfällt oder nicht mehr reagiert.
**Rechenknoten**
Ein Rechenknoten ist eine Amazon-EC2-Instance innerhalb eines Clusters, der den [Slurm-Worker-Daemon (slurmd)](https://slurm.schedmd.com/slurmd.html) hostet. Die Hauptfunktion des Datenverarbeitungsknotens besteht darin, Aufträge auszuführen, die vom [Slurm-Controller-Daemon (slurmctld)](https://slurm.schedmd.com/slurmctld.html) zugewiesen werden, der auf dem primären Controller-Knoten ausgeführt wird. Wenn ein Auftrag geplant wird, erhält der Rechenknoten Anweisungen vom [Slurm-Controller-Daemon (slurmctld)](https://slurm.schedmd.com/slurmctld.html), um die für diesen Auftrag erforderlichen Aufgaben und Berechnungen innerhalb des Knotens selbst auszuführen. Ein Rechenknoten wird auch als Worker-Node bezeichnet.
## Funktionsweise
Das folgende Diagramm zeigt, wie verschiedene AWS Dienste zusammenarbeiten, um die Architektur mit mehreren Controller-Nodes (Head) für SageMaker HyperPod Slurm-Cluster zu unterstützen.
![\[SageMaker HyperPod Architekturdiagramm für Knoten mit mehreren Köpfen\]](http://docs.aws.amazon.com/de_de/sagemaker/latest/dg/images/hyperpod/hyperpod-multihead-architecture.png)
Zu den AWS Diensten, die zusammenarbeiten, um die Architektur mit SageMaker HyperPod mehreren Controller-Knoten (Hauptknoten) zu unterstützen, gehören die folgenden.
**AWS Dienste, die zusammenarbeiten, um die Architektur mit SageMaker HyperPod mehreren Controller-Knoten zu unterstützen**
| Service | Description |
| --- | --- |
| ICH BIN ()AWS Identity and Access Management | Definiert zwei IAM-Rollen zur Steuerung der Zugriffsberechtigungen: eine Rolle für die Instance-Gruppe des Rechenknotens und eine weitere für die Instance-Gruppe des Controller-Knotens. |
| Amazon RDS für MariaDB | Speichert Buchhaltungsdaten für Slurm, das Auftragsaufzeichnungen und Messdaten enthält. |
| AWS Secrets Manager | Speichert und verwaltet Anmeldeinformationen, auf die Amazon FSx for Lustre zugreifen kann. |
| Amazon FSx für Lustre | Speichert Slurm-Konfigurationen und den Laufzeitstatus. |
| Amazon VPC | Stellt eine isolierte Netzwerkumgebung bereit, in der der HyperPod Cluster und seine Ressourcen bereitgestellt werden. |
| Amazon SNS | Sendet Benachrichtigungen an Administratoren, wenn Statusänderungen (Slurm-Controller ist ON oder OFF) in Bezug auf den primären Controller-Knoten (Hauptknoten) auftreten. |
Der HyperPod Cluster selbst besteht aus Controller-Knoten (primär und Backup) und Rechenknoten. Auf den Controller-Knoten laufen die Slurm-Controller- (SlurmCtld) und Datenbankkomponenten (SlurmDBd), die die Arbeitslast auf den Rechenknoten verwalten und überwachen.
Die Controller-Knoten greifen auf Slurm-Konfigurationen und den Laufzeitstatus zu, die im Amazon FSx for Lustre-Dateisystem gespeichert sind. Die Slurm-Buchhaltungsdaten werden in der Amazon RDS for MariaDB MariaDB-Datenbank gespeichert. AWS Secrets Manager bietet sicheren Zugriff auf die Datenbankanmeldedaten für die Controller-Knoten.
Wenn sich der Status der Slurm-Controller-Knoten ändert (Slurm-Controller ist `ON` oder `OFF`), sendet Amazon SNS Benachrichtigungen an den Administrator, damit dieser weitere Maßnahmen ergreifen kann.
Diese Architektur mit mehreren Controller-Knoten beseitigt den Single Point of Failure eines einzelnen Controller-Knotens (Hauptknotens), ermöglicht eine schnelle und automatische Failover-Wiederherstellung und gibt Ihnen die Kontrolle über die Slurm-Buchhaltungsdatenbank und -Konfigurationen.
# Einrichtung mehrerer Controller-Knoten für einen SageMaker HyperPod Slurm-Cluster
In diesem Thema wird erklärt, wie Sie mehrere Controller-Knoten (Head) in einem SageMaker HyperPod Slurm-Cluster mithilfe von Lifecycle-Skripten konfigurieren. Bevor Sie beginnen, überprüfen Sie die in [Voraussetzungen für die Verwendung SageMaker HyperPod](sagemaker-hyperpod-prerequisites.md) aufgeführten Voraussetzungen und machen Sie sich mit den Lebenszyklusskripten in [Anpassen von SageMaker HyperPod Clustern mithilfe von Lifecycle-Skripten](sagemaker-hyperpod-lifecycle-best-practices-slurm.md) vertraut. Die Anweisungen in diesem Thema verwenden AWS CLI Befehle in der Amazon Linux-Umgebung. Beachten Sie, dass die in diesen Befehlen verwendeten Umgebungsvariablen in der aktuellen Sitzung verfügbar sind, sofern sie nicht explizit beibehalten werden.
**Topics**
+ [Bereitstellung von Ressourcen mithilfe von Stacks CloudFormation](sagemaker-hyperpod-multihead-slurm-cfn.md)
+ [Erstellen und Anfügen einer IAM-Richtlinie](sagemaker-hyperpod-multihead-slurm-iam.md)
+ [Vorbereiten und Hochladen von Lebenszyklusskripten](sagemaker-hyperpod-multihead-slurm-scripts.md)
+ [Einen SageMaker HyperPod Cluster erstellen](sagemaker-hyperpod-multihead-slurm-create.md)
+ [Berücksichtigung wichtiger Hinweise](sagemaker-hyperpod-multihead-slurm-notes.md)
+ [Überprüfen der Referenz zu Umgebungsvariablen](sagemaker-hyperpod-multihead-slurm-variables-reference.md)
# Bereitstellung von Ressourcen mithilfe von Stacks CloudFormation
Um mehrere Controller-Knoten in einem HyperPod Slurm-Cluster einzurichten, stellen Sie AWS Ressourcen über zwei CloudFormation Stacks bereit: und. [Bereitstellen von grundlegenden Ressourcen](#sagemaker-hyperpod-multihead-slurm-cfn-basic) [Bereitstellen zusätzlicher Ressourcen zur Unterstützung mehrerer Controller-Knoten](#sagemaker-hyperpod-multihead-slurm-cfn-multihead)
## Bereitstellen von grundlegenden Ressourcen
Gehen Sie wie folgt vor, um grundlegende Ressourcen für Ihren Amazon SageMaker HyperPod Slurm-Cluster bereitzustellen.
1. Laden Sie die Vorlagendatei [sagemaker-hyperpod.yaml](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/sagemaker-hyperpod.yaml) auf Ihren Computer herunter. Diese YAML-Datei ist eine CloudFormation Vorlage, die die folgenden Ressourcen definiert, die Sie für Ihren Slurm-Cluster erstellen müssen.
+ Eine Ausführungs-IAM-Rolle für die Rechenknoten-Instance-Gruppe
+ Ein Amazon-S3-Bucket zum Speichern der Lebenszyklusskripte
+ Öffentliche und private Subnetze (private Subnetze haben Internetzugang über NAT-Gateways)
+ Internet-Gateways Gateway/NAT
+ Zwei Amazon-EC2-Sicherheitsgruppen
+ Ein FSx Amazon-Volume zum Speichern von Konfigurationsdateien
1. Führen Sie den folgenden CLI-Befehl aus, um einen CloudFormation Stack mit dem Namen zu erstellen`sagemaker-hyperpod`. Definieren Sie die Availability Zone (AZ) IDs für Ihren Cluster in `PrimarySubnetAZ` und`BackupSubnetAZ`. *use1-az4*Ist beispielsweise eine AZ-ID für eine Availability Zone in der `us-east-1` Region. Weitere Informationen finden Sie unter [Availability Zone IDs](https://docs.aws.amazon.com//ram/latest/userguide/working-with-az-ids.html) und[Einrichtung von Clustern über mehrere SageMaker HyperPod AZs](sagemaker-hyperpod-prerequisites.md#sagemaker-hyperpod-prerequisites-multiple-availability-zones).
```
aws cloudformation deploy \
--template-file /path_to_template/sagemaker-hyperpod.yaml \
--stack-name sagemaker-hyperpod \
--parameter-overrides PrimarySubnetAZ=use1-az4 BackupSubnetAZ=use1-az1 \
--capabilities CAPABILITY_IAM
```
Weitere Informationen finden Sie in der AWS Command Line Interface Referenz unter [Bereitstellen](https://docs.aws.amazon.com//cli/latest/reference/cloudformation/deploy/). Die Erstellung des Stacks kann einige Minuten in Anspruch nehmen. Wenn der Vorgang abgeschlossen ist, wird in Ihrer Befehlszeilenschnittstelle Folgendes angezeigt.
```
Waiting for changeset to be created..
Waiting for stack create/update to complete
Successfully created/updated stack - sagemaker-hyperpod
```
1. (Optional) Überprüfen Sie den Stack in der [CloudFormation -Konsole](https://console.aws.amazon.com/cloudformation/home).
+ Wählen Sie im linken Navigationsbereich **Stack** aus.
+ Suchen Sie auf der **Stack**-Seite nach **sagemaker-hyperpod** und wählen Sie es aus.
+ Wählen Sie die Registerkarten wie **Ressourcen** und **Ergebnisse** aus, um die Ressourcen und Ergebnisse zu überprüfen.
1. Erstellen Sie Umgebungsvariablen aus den Stack-Ausgaben (`sagemaker-hyperpod`). Sie verwenden die Werte dieser Variablen, um [Bereitstellen zusätzlicher Ressourcen zur Unterstützung mehrerer Controller-Knoten](#sagemaker-hyperpod-multihead-slurm-cfn-multihead).
```
source .env
PRIMARY_SUBNET=$(aws --region $REGION cloudformation describe-stacks --stack-name $SAGEMAKER_STACK_NAME --query 'Stacks[0].Outputs[?OutputKey==`PrimaryPrivateSubnet`].OutputValue' --output text)
BACKUP_SUBNET=$(aws --region $REGION cloudformation describe-stacks --stack-name $SAGEMAKER_STACK_NAME --query 'Stacks[0].Outputs[?OutputKey==`BackupPrivateSubnet`].OutputValue' --output text)
EMAIL=$(bash -c 'read -p "INPUT YOUR SNSSubEmailAddress HERE: " && echo $REPLY')
DB_USER_NAME=$(bash -c 'read -p "INPUT YOUR DB_USER_NAME HERE: " && echo $REPLY')
SECURITY_GROUP=$(aws --region $REGION cloudformation describe-stacks --stack-name $SAGEMAKER_STACK_NAME --query 'Stacks[0].Outputs[?OutputKey==`SecurityGroup`].OutputValue' --output text)
ROOT_BUCKET_NAME=$(aws --region $REGION cloudformation describe-stacks --stack-name $SAGEMAKER_STACK_NAME --query 'Stacks[0].Outputs[?OutputKey==`AmazonS3BucketName`].OutputValue' --output text)
SLURM_FSX_DNS_NAME=$(aws --region $REGION cloudformation describe-stacks --stack-name $SAGEMAKER_STACK_NAME --query 'Stacks[0].Outputs[?OutputKey==`FSxLustreFilesystemDNSname`].OutputValue' --output text)
SLURM_FSX_MOUNT_NAME=$(aws --region $REGION cloudformation describe-stacks --stack-name $SAGEMAKER_STACK_NAME --query 'Stacks[0].Outputs[?OutputKey==`FSxLustreFilesystemMountname`].OutputValue' --output text)
COMPUTE_NODE_ROLE=$(aws --region $REGION cloudformation describe-stacks --stack-name $SAGEMAKER_STACK_NAME --query 'Stacks[0].Outputs[?OutputKey==`AmazonSagemakerClusterExecutionRoleArn`].OutputValue' --output text)
```
Wenn Sie aufgefordert werden, Ihre E-Mail-Adresse und Ihren Datenbankbenutzernamen einzugeben, geben Sie Werte wie die folgenden ein.
```
INPUT YOUR SNSSubEmailAddress HERE: Email_address_to_receive_SNS_notifications
INPUT YOUR DB_USER_NAME HERE: Database_user_name_you_define
```
Verwenden Sie den `print $variable`-Befehl, um Variablenwerte zu überprüfen.
```
print $REGION
us-east-1
```
## Bereitstellen zusätzlicher Ressourcen zur Unterstützung mehrerer Controller-Knoten
Gehen Sie wie folgt vor, um zusätzliche Ressourcen für Ihren Amazon SageMaker HyperPod Slurm-Cluster mit mehreren Controller-Knoten bereitzustellen.
1. Laden Sie die [sagemaker-hyperpod-slurm-multiVorlagendatei -headnode.yaml](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/sagemaker-hyperpod-slurm-multi-headnode.yaml) auf Ihren Computer herunter. Diese zweite YAML-Datei ist eine CloudFormation Vorlage, die die zusätzlichen Ressourcen definiert, die für die Unterstützung mehrerer Controller-Knoten in Ihrem Slurm-Cluster erstellt werden müssen.
+ Eine Ausführungs-IAM-Rolle für die Instance-Gruppe des Controller-Knotens
+ Eine Instance von Amazon RDS für MariaDB
+ Ein Amazon-SNS-Thema und -Abonnement
+ AWS Secrets Manager Anmeldeinformationen für Amazon RDS for MariaDB
1. Führen Sie den folgenden CLI-Befehl aus, um einen CloudFormation Stack mit dem Namen zu erstellen`sagemaker-hyperpod-mh`. Dieser zweite Stack verwendet die CloudFormation Vorlage, um zusätzliche AWS Ressourcen zur Unterstützung der Architektur mit mehreren Controller-Knoten zu erstellen.
```
aws cloudformation deploy \
--template-file /path_to_template/slurm-multi-headnode.yaml \
--stack-name sagemaker-hyperpod-mh \
--parameter-overrides \
SlurmDBSecurityGroupId=$SECURITY_GROUP \
SlurmDBSubnetGroupId1=$PRIMARY_SUBNET \
SlurmDBSubnetGroupId2=$BACKUP_SUBNET \
SNSSubEmailAddress=$EMAIL \
SlurmDBUsername=$DB_USER_NAME \
--capabilities CAPABILITY_NAMED_IAM
```
Weitere Informationen finden Sie in der AWS Command Line Interface Referenz unter [Deploy](https://docs.aws.amazon.com//cli/latest/reference/cloudformation/deploy/). Die Erstellung des Stacks kann einige Minuten in Anspruch nehmen. Wenn der Vorgang abgeschlossen ist, wird in Ihrer Befehlszeilenschnittstelle Folgendes angezeigt.
```
Waiting for changeset to be created..
Waiting for stack create/update to complete
Successfully created/updated stack - sagemaker-hyperpod-mh
```
1. (Optional) Überprüfen Sie den Stack in der [Konsole von AWS Cloud Formation](https://console.aws.amazon.com/cloudformation/home).
+ Wählen Sie im linken Navigationsbereich **Stack** aus.
+ Suchen und wählen Sie auf der **Stack-Seite **sagemaker-hyperpod-mh****.
+ Wählen Sie die Registerkarten wie **Ressourcen** und **Ergebnisse** aus, um die Ressourcen und Ergebnisse zu überprüfen.
1. Erstellen Sie Umgebungsvariablen aus den Stack-Ausgaben (`sagemaker-hyperpod-mh`). Sie verwenden die Werte dieser Variablen, um die Konfigurationsdatei (`provisioning_parameters.json`) in [Vorbereiten und Hochladen von Lebenszyklusskripten](sagemaker-hyperpod-multihead-slurm-scripts.md) zu aktualisieren.
```
source .env
SLURM_DB_ENDPOINT_ADDRESS=$(aws --region us-east-1 cloudformation describe-stacks --stack-name $MULTI_HEAD_SLURM_STACK --query 'Stacks[0].Outputs[?OutputKey==`SlurmDBEndpointAddress`].OutputValue' --output text)
SLURM_DB_SECRET_ARN=$(aws --region us-east-1 cloudformation describe-stacks --stack-name $MULTI_HEAD_SLURM_STACK --query 'Stacks[0].Outputs[?OutputKey==`SlurmDBSecretArn`].OutputValue' --output text)
SLURM_EXECUTION_ROLE_ARN=$(aws --region us-east-1 cloudformation describe-stacks --stack-name $MULTI_HEAD_SLURM_STACK --query 'Stacks[0].Outputs[?OutputKey==`SlurmExecutionRoleArn`].OutputValue' --output text)
SLURM_SNS_FAILOVER_TOPIC_ARN=$(aws --region us-east-1 cloudformation describe-stacks --stack-name $MULTI_HEAD_SLURM_STACK --query 'Stacks[0].Outputs[?OutputKey==`SlurmFailOverSNSTopicArn`].OutputValue' --output text)
```
# Erstellen und Anfügen einer IAM-Richtlinie
In diesem Abschnitt wird erklärt, wie Sie eine IAM-Richtlinie erstellen und sie an die Ausführungsrolle anfügen, die sie in [Bereitstellen zusätzlicher Ressourcen zur Unterstützung mehrerer Controller-Knoten](sagemaker-hyperpod-multihead-slurm-cfn.md#sagemaker-hyperpod-multihead-slurm-cfn-multihead) erstellt haben.
1. Laden Sie das [Beispiel für eine IAM-Richtlinie](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/1.AmazonSageMakerClustersExecutionRolePolicy.json) aus dem GitHub Repository auf Ihren Computer herunter.
1. Erstellen Sie eine IAM-Richtlinie mit dem heruntergeladenen Beispiel, indem Sie den CLI-Befehl [create-policy](https://docs.aws.amazon.com//cli/latest/reference/iam/create-policy.html) verwenden.
```
aws --region us-east-1 iam create-policy \
--policy-name AmazonSagemakerExecutionPolicy \
--policy-document file://1.AmazonSageMakerClustersExecutionRolePolicy.json
```
Beispielausgabe des Befehls.
```
{
"Policy": {
"PolicyName": "AmazonSagemakerExecutionPolicy",
"PolicyId": "ANPAXISIWY5UYZM7WJR4W",
"Arn": "arn:aws:iam::111122223333:policy/AmazonSagemakerExecutionPolicy",
"Path": "/",
"DefaultVersionId": "v1",
"AttachmentCount": 0,
"PermissionsBoundaryUsageCount": 0,
"IsAttachable": true,
"CreateDate": "2025-01-22T20:01:21+00:00",
"UpdateDate": "2025-01-22T20:01:21+00:00"
}
}
```
1. Hängen Sie die Richtlinie mithilfe des [attach-role-policy](https://docs.aws.amazon.com//cli/latest/reference/iam/attach-role-policy.html)CLI-Befehls `AmazonSagemakerExecutionPolicy` an die Slurm-Ausführungsrolle an[Bereitstellen zusätzlicher Ressourcen zur Unterstützung mehrerer Controller-Knoten](sagemaker-hyperpod-multihead-slurm-cfn.md#sagemaker-hyperpod-multihead-slurm-cfn-multihead), in der Sie sie erstellt haben.
```
aws --region us-east-1 iam attach-role-policy \
--role-name AmazonSagemakerExecutionRole \
--policy-arn arn:aws:iam::111122223333:policy/AmazonSagemakerExecutionPolicy
```
Dieser Befehl liefert keine Ausgabe.
(Optional) Wenn Sie Umgebungsvariablen verwenden, finden Sie hier die Beispielbefehle.
+ So rufen Sie den Rollen- und Richtliniennamen ab
```
POLICY=$(aws --region $REGION iam list-policies --query 'Policies[?PolicyName==AmazonSagemakerExecutionPolicy].Arn' --output text)
ROLENAME=$(aws --region $REGION iam list-roles --query "Roles[?Arn=='${SLURM_EXECUTION_ROLE_ARN}'].RoleName" —output text)
```
+ So fügen Sie die Richtlinie an
```
aws --region us-east-1 iam attach-role-policy \
--role-name $ROLENAME --policy-arn $POLICY
```
Weitere Informationen finden Sie unter [IAM-Rolle für SageMaker HyperPod](sagemaker-hyperpod-prerequisites-iam.md#sagemaker-hyperpod-prerequisites-iam-role-for-hyperpod).
# Vorbereiten und Hochladen von Lebenszyklusskripten
Nachdem Sie alle erforderlichen Ressourcen erstellt haben, müssen Sie [Lifecycle-Skripte](https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts) für Ihren SageMaker HyperPod Cluster einrichten. Diese [Lebenszyklus-Skripte](https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts) bieten eine [Basiskonfiguration](https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config), mit der Sie einen grundlegenden HyperPod Slurm-Cluster erstellen können.
## Vorbereiten der Lebenszyklusskripte
Gehen Sie wie folgt vor, um die Lebenszyklusskripte anzurufen.
1. Laden Sie die [Lebenszyklus-Skripte](https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts) aus dem GitHub Repository auf Ihren Computer herunter.
1. Laden Sie die [Lebenszyklusskripte](https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts) mit dem CLI-Befehl [cp](https://docs.aws.amazon.com//cli/latest/reference/s3/cp.html) in den Amazon-S3-Bucket hoch, den Sie in [Bereitstellen von grundlegenden Ressourcen](sagemaker-hyperpod-multihead-slurm-cfn.md#sagemaker-hyperpod-multihead-slurm-cfn-basic) erstellt haben.
```
aws s3 cp --recursive LifeCycleScripts/base-config s3://${ROOT_BUCKET_NAME}/LifeCycleScripts/base-config
```
## Erstellen einer Konfigurationsdatei
Gehen Sie wie folgt vor, um die Konfigurationsdatei zu erstellen und sie in denselben Amazon-S3-Bucket hochzuladen, in dem Sie die Lebenszyklusskripte speichern.
1. Erstellen Sie eine Konfigurationsdatei namens `provisioning_parameters.json` mit der folgenden Konfiguration. Beachten Sie, dass `slurm_sns_arn` optional ist. Wenn nicht angegeben, HyperPod werden die Amazon SNS SNS-Benachrichtigungen nicht eingerichtet.
```
cat < /tmp/provisioning_parameters.json
{
"version": "1.0.0",
"workload_manager": "slurm",
"controller_group": "$CONTOLLER_IG_NAME",
"login_group": "my-login-group",
"worker_groups": [
{
"instance_group_name": "$COMPUTE_IG_NAME",
"partition_name": "dev"
}
],
"fsx_dns_name": "$SLURM_FSX_DNS_NAME",
"fsx_mountname": "$SLURM_FSX_MOUNT_NAME",
"slurm_configurations": {
"slurm_database_secret_arn": "$SLURM_DB_SECRET_ARN",
"slurm_database_endpoint": "$SLURM_DB_ENDPOINT_ADDRESS",
"slurm_shared_directory": "/fsx",
"slurm_database_user": "$DB_USER_NAME",
"slurm_sns_arn": "$SLURM_SNS_FAILOVER_TOPIC_ARN"
}
}
EOF
```
1. Laden Sie die `provisioning_parameters.json`-Datei in denselben Amazon-S3-Bucket hoch, in dem Sie die Lebenszyklusskripte speichern.
```
aws s3 cp /tmp/provisioning_parameters.json s3://${ROOT_BUCKET_NAME}/LifeCycleScripts/base-config/provisioning_parameters.json
```
**Anmerkung**
Wenn Sie eine API-gesteuerte Konfiguration verwenden, ist die `provisioning_parameters.json` Datei nicht erforderlich. Bei der API-gesteuerten Konfiguration definieren Sie Slurm-Knotentypen, Partitionen und FSx Mounting direkt in der API-Nutzlast. CreateCluster Einzelheiten finden Sie unter [Erste Schritte mit](smcluster-getting-started-slurm-cli.md) der Verwendung von. SageMaker HyperPod AWS CLI
## Überprüfen von Dateien im Amazon-S3-Bucket
Nachdem Sie alle Lebenszyklusskripts und die `provisioning_parameters.json`-Datei hochgeladen haben, sollte Ihr Amazon-S3-Bucket wie folgt aussehen.
![\[Bild mit allen Lebenszyklusskripten, die in der Konsole von Amazon Simple Storage Service in den Amazon-S3-Bucket hochgeladen wurden.\]](http://docs.aws.amazon.com/de_de/sagemaker/latest/dg/images/hyperpod/hyperpod-lifecycle-scripts-s3.png)
Weitere Informationen finden Sie unter [Beginnen Sie mit grundlegenden Lebenszyklusskripten von HyperPod](https://docs.aws.amazon.com//sagemaker/latest/dg/sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-base-config.html).
# Einen SageMaker HyperPod Cluster erstellen
Nachdem Sie alle erforderlichen Ressourcen eingerichtet und die Skripte in den Amazon-S3-Bucket hochgeladen haben, können Sie einen Cluster erstellen.
1. Führen Sie den [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 Befehl aus, um einen Cluster zu erstellen. Der Erstellungsprozess kann bis zu 15 Minuten dauern.
```
aws --region $REGION sagemaker create-cluster \
--cluster-name $HP_CLUSTER_NAME \
--vpc-config '{
"SecurityGroupIds":["'$SECURITY_GROUP'"],
"Subnets":["'$PRIMARY_SUBNET'", "'$BACKUP_SUBNET'"]
}' \
--instance-groups '[{
"InstanceGroupName": "'$CONTOLLER_IG_NAME'",
"InstanceType": "ml.t3.medium",
"InstanceCount": 2,
"LifeCycleConfig": {
"SourceS3Uri": "s3://'$BUCKET_NAME'",
"OnCreate": "on_create.sh"
},
"ExecutionRole": "'$SLURM_EXECUTION_ROLE_ARN'",
"ThreadsPerCore": 1
},
{
"InstanceGroupName": "'$COMPUTE_IG_NAME'",
"InstanceType": "ml.c5.xlarge",
"InstanceCount": 2,
"LifeCycleConfig": {
"SourceS3Uri": "s3://'$BUCKET_NAME'",
"OnCreate": "on_create.sh"
},
"ExecutionRole": "'$COMPUTE_NODE_ROLE'",
"ThreadsPerCore": 1
}]'
```
Nach erfolgreicher Ausführung gibt der Befehl den Cluster-ARN wie folgt zurück.
```
{
"ClusterArn": "arn:aws:sagemaker:us-east-1:111122223333:cluster/cluster_id"
}
```
1. (Optional) Um den Status Ihres Clusters zu überprüfen, können Sie die SageMaker AI-Konsole ([https://console.aws.amazon.com/sagemaker/](https://console.aws.amazon.com/sagemaker/)) verwenden. Wählen Sie in der linken Navigationsleiste **HyperPod Clusters** und anschließend **Cluster Management** aus. Wählen Sie einen Clusternamen aus, um die Cluster-Detailseite zu öffnen. Wenn Ihr Cluster erfolgreich erstellt wurde, sehen Sie, dass der Cluster-Status lautet **InService**.
![\[Das Bild zeigt einen HyperPod Slurm-Cluster mit mehreren Controller-Knoten in der Amazon SageMaker AI-Konsole.\]](http://docs.aws.amazon.com/de_de/sagemaker/latest/dg/images/hyperpod/hyperpod-lifecycle-multihead-cluster.png)
# Berücksichtigung wichtiger Hinweise
Dieser Abschnitt enthält einige wichtige Hinweise, die für Sie hilfreich sein könnten.
1. Gehen Sie wie folgt vor, um zu einem Slurm-Cluster mit mehreren Controllern zu migrieren.
1. Folgen Sie den Anweisungen unter [Bereitstellung von Ressourcen mithilfe von Stacks CloudFormation](sagemaker-hyperpod-multihead-slurm-cfn.md), um alle erforderlichen Ressourcen bereitzustellen.
1. Folgen Sie den Anweisungen unter [Vorbereiten und Hochladen von Lebenszyklusskripten](sagemaker-hyperpod-multihead-slurm-scripts.md), um die aktualisierten Lebenszyklusskripte hochzuladen. Verschieben Sie beim Aktualisieren der `provisioning_parameters.json`-Datei Ihre bestehende Controller-Gruppe in den `worker_groups`-Abschnitt und fügen Sie dem `controller_group`-Abschnitt einen neuen Controller-Gruppennamen hinzu.
1. Führen Sie den API-Aufruf [update-cluster](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/update-cluster.html) aus, um eine neue Controller-Gruppe zu erstellen und die ursprünglichen Compute-Instance-Gruppen und die Controller-Gruppe beizubehalten.
1. Verwenden Sie den CLI-Befehl [update-cluster](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/update-cluster.html), um die Anzahl der Controller-Knoten zu reduzieren. Für jede Controller-Instance-Gruppe beträgt die Mindestanzahl der Controller-Knoten, auf die Sie herunterskalieren können, 1. Das bedeutet, dass Sie die Anzahl der Controller-Knoten nicht auf 0 herunterskalieren können.
**Wichtig**
Für Cluster, die vor dem 24. Januar 2025 erstellt wurden, müssen Sie zuerst Ihre Clustersoftware mithilfe der [UpdateClusterSoftware](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_UpdateClusterSoftware.html)API aktualisieren, bevor Sie den CLI-Befehl [update-cluster](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/update-cluster.html) ausführen.
Im Folgenden finden Sie ein Beispiel für einen CLI-Befehl zum Herunterskalieren der Anzahl der Controller-Knoten.
```
aws sagemaker update-cluster \
--cluster-name my_cluster \
--instance-groups '[{
"InstanceGroupName": "controller_ig_name",
"InstanceType": "ml.t3.medium",
"InstanceCount": 3,
"LifeCycleConfig": {
"SourceS3Uri": "s3://amzn-s3-demo-bucket1",
"OnCreate": "on_create.sh"
},
"ExecutionRole": "slurm_execution_role_arn",
"ThreadsPerCore": 1
},
{
"InstanceGroupName": "compute-ig_name",
"InstanceType": "ml.c5.xlarge",
"InstanceCount": 2,
"LifeCycleConfig": {
"SourceS3Uri": "s3://amzn-s3-demo-bucket1",
"OnCreate": "on_create.sh"
},
"ExecutionRole": "compute_node_role_arn",
"ThreadsPerCore": 1
}]'
```
1. Verwenden Sie den [batch-delete-cluster-nodes](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/batch-delete-cluster-nodes.html)CLI-Befehl, um die Controller-Knoten stapelweise zu löschen. Für jede Controller-Instance-Gruppe müssen Sie mindestens einen Controller-Knoten behalten. Wenn Sie alle Controller-Knoten stapelweise löschen möchten, funktioniert die API-Operation nicht.
**Wichtig**
Für Cluster, die vor dem 24. Januar 2025 erstellt wurden, müssen Sie zuerst Ihre Clustersoftware mithilfe der [UpdateClusterSoftware](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_UpdateClusterSoftware.html)API aktualisieren, bevor Sie den [batch-delete-cluster-nodes](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/batch-delete-cluster-nodes.html)CLI-Befehl ausführen.
Im Folgenden finden Sie ein Beispiel für einen CLI-Befehl, um die Controller-Knoten stapelweise zu löschen.
```
aws sagemaker batch-delete-cluster-nodes --cluster-name my_cluster --node-ids instance_ids_to_delete
```
1. Um Ihre Probleme bei der Clustererstellung zu beheben, überprüfen Sie die Fehlermeldung auf der Seite mit den Cluster-Details in Ihrer SageMaker AI-Konsole. Sie können CloudWatch Protokolle auch verwenden, um Probleme bei der Clustererstellung zu beheben. Wählen Sie in der CloudWatch Konsole **Protokollgruppen** aus. Suchen Sie dann nach `clusters`, um die Liste der Protokollgruppen anzuzeigen, die sich auf Ihre Clustererstellung beziehen.
![\[Bild, das SageMaker HyperPod Amazon-Cluster-Protokollgruppen in der CloudWatch Konsole zeigt.\]](http://docs.aws.amazon.com/de_de/sagemaker/latest/dg/images/hyperpod/hyperpod-lifecycle-multihead-logs.png)
# Überprüfen der Referenz zu Umgebungsvariablen
Die folgenden Umgebungsvariablen werden im Tutorial von [Einrichtung mehrerer Controller-Knoten für einen SageMaker HyperPod Slurm-Cluster](sagemaker-hyperpod-multihead-slurm-setup.md) definiert und verwendet. Diese Umgebungsvariablen sind nur in der aktuellen Sitzung verfügbar, sofern sie nicht explizit beibehalten werden. Sie werden mit der `$variable_name`-Syntax definiert. Variablen mit key/value Paaren stehen für AWS von ihnen erstellte Ressourcen, während Variablen ohne Schlüssel benutzerdefiniert sind.
**Referenz zu Umgebungsvariablen**
| Variable | Description |
| --- | --- |
| \$1BACKUP\$1SUBNET | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/sagemaker/latest/dg/sagemaker-hyperpod-multihead-slurm-variables-reference.html) |
| \$1COMPUTE\$1IG\$1NAME | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/sagemaker/latest/dg/sagemaker-hyperpod-multihead-slurm-variables-reference.html) |
| \$1COMPUTE\$1NODE\$1ROLE | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/sagemaker/latest/dg/sagemaker-hyperpod-multihead-slurm-variables-reference.html) |
| \$1CONTOLLER\$1IG\$1NAME | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/sagemaker/latest/dg/sagemaker-hyperpod-multihead-slurm-variables-reference.html) |
| \$1DB\$1USER\$1NAME | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/sagemaker/latest/dg/sagemaker-hyperpod-multihead-slurm-variables-reference.html) |
| \$1EMAIL | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/sagemaker/latest/dg/sagemaker-hyperpod-multihead-slurm-variables-reference.html) |
| \$1PRIMARY\$1SUBNET | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/sagemaker/latest/dg/sagemaker-hyperpod-multihead-slurm-variables-reference.html) |
| \$1POLICY | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/sagemaker/latest/dg/sagemaker-hyperpod-multihead-slurm-variables-reference.html) |
| \$1REGION | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/sagemaker/latest/dg/sagemaker-hyperpod-multihead-slurm-variables-reference.html) |
| \$1ROOT\$1BUCKET\$1NAME | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/sagemaker/latest/dg/sagemaker-hyperpod-multihead-slurm-variables-reference.html) |
| \$1SECURITY\$1GROUP | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/sagemaker/latest/dg/sagemaker-hyperpod-multihead-slurm-variables-reference.html) |
| \$1SLURM\$1DB\$1ENDPOINT\$1ADDRESS | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/sagemaker/latest/dg/sagemaker-hyperpod-multihead-slurm-variables-reference.html) |
| \$1SLURM\$1DB\$1SECRET\$1ARN | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/sagemaker/latest/dg/sagemaker-hyperpod-multihead-slurm-variables-reference.html) |
| \$1SLURM\$1EXECUTION\$1ROLE\$1ARN | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/sagemaker/latest/dg/sagemaker-hyperpod-multihead-slurm-variables-reference.html) |
| \$1SLURM\$1FSX\$1DNS\$1NAME | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/sagemaker/latest/dg/sagemaker-hyperpod-multihead-slurm-variables-reference.html) |
| \$1SLURM\$1FSX\$1MOUNT\$1NAME | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/sagemaker/latest/dg/sagemaker-hyperpod-multihead-slurm-variables-reference.html) |
| \$1SLURM\$1SNS\$1FAILOVER\$1TOPIC\$1ARN | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/sagemaker/latest/dg/sagemaker-hyperpod-multihead-slurm-variables-reference.html) |
# Jobs auf Clustern SageMaker HyperPod
Die folgenden Themen enthalten Verfahren und Beispiele für den Zugriff auf Rechenknoten und die Ausführung von ML-Workloads auf bereitgestellten SageMaker HyperPod Clustern. Je nachdem, wie Sie die Umgebung auf Ihrem HyperPod Cluster eingerichtet haben, gibt es viele Möglichkeiten, ML-Workloads auf Clustern auszuführen. HyperPod Beispiele für die Ausführung von ML-Workloads auf HyperPod Clustern finden Sie auch im [Awsome Distributed](https://github.com/aws-samples/awsome-distributed-training/) Training Repository. GitHub In den folgenden Themen erfahren Sie, wie Sie sich bei den bereitgestellten HyperPod Clustern anmelden und wie Sie mit der Ausführung von ML-Beispielworkloads beginnen können.
**Tipp**
[Praktische Beispiele und Lösungen finden Sie auch im SageMaker HyperPod Workshop.](https://catalog.workshops.aws/sagemaker-hyperpod)
**Topics**
+ [Zugriff auf Ihre SageMaker HyperPod Clusterknoten](sagemaker-hyperpod-run-jobs-slurm-access-nodes.md)
+ [Planung eines Slurm-Jobs auf einem Cluster SageMaker HyperPod](sagemaker-hyperpod-run-jobs-slurm-schedule-slurm-job.md)
+ [Docker-Container auf einem Slurm-Rechenknoten ausführen auf HyperPod](sagemaker-hyperpod-run-jobs-slurm-docker.md)
+ [Ausführung verteilter Trainingsworkloads mit aktiviertem Slurm HyperPod](sagemaker-hyperpod-run-jobs-slurm-distributed-training-workload.md)
# Zugriff auf Ihre SageMaker HyperPod Clusterknoten
Sie können über AWS Systems Manager (SSM) auf Ihren **InService**Cluster zugreifen, indem Sie den AWS CLI Befehl `aws ssm start-session` mit dem SageMaker HyperPod Cluster-Hostnamen im Format von `sagemaker-cluster:[cluster-id]_[instance-group-name]-[instance-id]` ausführen. Sie können die Cluster-ID, die Instanz-ID und den Namen der Instanzgruppe von der [SageMaker HyperPod Konsole](sagemaker-hyperpod-operate-slurm-console-ui.md#sagemaker-hyperpod-operate-slurm-console-ui-view-details-of-clusters) aus abrufen oder indem Sie `describe-cluster` und `list-cluster-nodes` die [AWS CLI Befehle für SageMaker HyperPod](sagemaker-hyperpod-operate-slurm-cli-command.md#sagemaker-hyperpod-operate-slurm-cli-command-list-cluster-nodes) ausführen. Wenn Ihre Cluster-ID beispielsweise `aa11bbbbb222`, der Clusterknotenname `controller-group` und die Clusterknoten-ID `i-111222333444555aa` lautet, sollte der SSM-Befehl `start-session` wie folgt lauten.
**Anmerkung**
Wenn Sie Benutzern Zugriff auf HyperPod Clusterknoten gewähren, können sie benutzerverwaltete Software auf den Knoten installieren und ausführen. Stellen Sie sicher, dass Sie das Prinzip der geringsten Berechtigung für Benutzer beibehalten.
Wenn Sie noch keine Einrichtung vorgenommen haben AWS Systems Manager, folgen Sie den Anweisungen unter[Einrichtung AWS Systems Manager und Ausführung als für die Cluster-Benutzerzugriffskontrolle](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#
```
Beachten Sie, dass Sie dadurch zunächst als Root-Benutzer verbunden werden. Bevor Sie Aufträge ausführen, wechseln Sie zum `ubuntu`-Benutzer, indem Sie den folgenden Befehl ausführen.
```
root@ip-111-22-333-444:/usr/bin# sudo su - ubuntu
ubuntu@ip-111-22-333-444:/usr/bin#
```
Erweiterte Einstellungen für die praktische Verwendung von HyperPod Clustern finden Sie in den folgenden Themen.
**Topics**
+ [Zusätzliche Tipps für den Zugriff auf Ihre SageMaker HyperPod Clusterknoten](#sagemaker-hyperpod-run-jobs-slurm-access-nodes-tips)
+ [Richten Sie über den Amazon FSx Shared Space eine Mehrbenutzerumgebung ein](#sagemaker-hyperpod-run-jobs-slurm-access-nodes-multi-user-with-fxs-shared-space)
+ [Richten Sie eine Mehrbenutzerumgebung ein, indem Sie HyperPod Cluster in Active Directory integrieren](#sagemaker-hyperpod-run-jobs-slurm-access-nodes-multi-user-with-active-directory)
## Zusätzliche Tipps für den Zugriff auf Ihre SageMaker HyperPod Clusterknoten
**Verwenden Sie das von bereitgestellte `easy-ssh.sh` Skript, HyperPod um den Verbindungsvorgang zu vereinfachen**
Um aus dem vorherigen Prozess einen einzeiligen Befehl zu machen, stellt das HyperPod Team das [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/easy-ssh.sh](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/easy-ssh.sh)Skript bereit, das Ihre Clusterinformationen abruft, sie im SSM-Befehl zusammenfasst und eine Verbindung zum Rechenknoten herstellt. Sie müssen nicht manuell nach den erforderlichen HyperPod Clusterinformationen suchen, da dieses Skript ausgeführt wird `describe-cluster` und die Informationen, die für die Ausführung des SSM-Befehls benötigt werden, `list-cluster-nodes` befiehlt und analysiert. Die folgenden Beispielbefehle veranschaulichen die Ausführung des [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/easy-ssh.sh](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/easy-ssh.sh)-Skripts. Wenn es erfolgreich ausgeführt wird, werden Sie als Root-Benutzer mit dem Cluster verbunden. Außerdem wird ein Codeausschnitt gedruckt, um SSH einzurichten, indem der HyperPod Cluster über einen SSM-Proxy als Remote-Host hinzugefügt wird. Durch die Einrichtung von SSH können Sie Ihre lokale Entwicklungsumgebung wie Visual Studio Code mit dem Cluster verbinden. HyperPod
```
$ chmod +x easy-ssh.sh
$ ./easy-ssh.sh -c
Cluster id:
Instance id:
Node Group:
Add the following to your ~/.ssh/config to easily connect:
$ cat <> ~/.ssh/config
Host
User ubuntu
ProxyCommand sh -c "aws ssm start-session --target sagemaker-cluster:_- --document-name AWS-StartSSHSession --parameters 'portNumber=%p'"
EOF
Add your ssh keypair and then you can do:
$ ssh
aws ssm start-session --target sagemaker-cluster:_-
Starting session with SessionId: s0011223344aabbccdd
root@ip-111-22-333-444:/usr/bin#
```
Beachten Sie, dass Sie dadurch zunächst als Root-Benutzer verbunden werden. Bevor Sie Aufträge ausführen, wechseln Sie zum `ubuntu`-Benutzer, indem Sie den folgenden Befehl ausführen.
```
root@ip-111-22-333-444:/usr/bin# sudo su - ubuntu
ubuntu@ip-111-22-333-444:/usr/bin#
```
**Richten Sie den einfachen Zugriff mit SSH ein, indem Sie den HyperPod Rechenknoten als Remote-Host verwenden**
Um den Zugriff auf den Rechenknoten mithilfe von SSH von einem lokalen Computer aus weiter zu vereinfachen, gibt das `easy-ssh.sh` Skript einen Codeausschnitt zur Einrichtung des HyperPod Clusters als Remote-Host aus, wie im vorherigen Abschnitt gezeigt. Das Code-Snippet wird automatisch generiert, damit Sie es direkt zur `~/.ssh/config`-Datei auf Ihrem lokalen Gerät hinzufügen können. Das folgende Verfahren zeigt, wie Sie den einfachen Zugriff mithilfe von SSH über den SSM-Proxy einrichten, sodass Sie oder Ihre Clusterbenutzer direkt eine Verbindung `ssh ` zum Clusterknoten herstellen können. HyperPod
1. Fügen Sie auf Ihrem lokalen Gerät den HyperPod Rechenknoten mit einem Benutzernamen als Remote-Host zur `~/.ssh/config` Datei hinzu. Der folgende Befehl zeigt, wie der automatisch generierte Codeausschnitt aus dem `easy-ssh.sh`-Skript an die `~/.ssh/config`-Datei angefügt wird. Stellen Sie sicher, dass Sie es aus der automatisch generierten Ausgabe des `easy-ssh.sh`-Skripts kopieren, das die richtigen Clusterinformationen enthält.
```
$ cat <> ~/.ssh/config
Host
User ubuntu
ProxyCommand sh -c "aws ssm start-session --target sagemaker-cluster:_- --document-name AWS-StartSSHSession --parameters 'portNumber=%p'"
EOF
```
1. Fügen Sie auf dem HyperPod Clusterknoten den öffentlichen Schlüssel auf Ihrem lokalen Gerät zur `~/.ssh/authorized_keys` Datei auf dem HyperPod Clusterknoten hinzu.
1. Drucken Sie den öffentlichen Schlüsseldatei auf Ihrem lokalen Computer.
```
$ cat ~/.ssh/id_rsa.pub
```
Dies sollte Ihren Schlüssel zurückgeben. Kopieren Sie die Ausgabe dieses Befehls.
(Optional) Wenn Sie keinen öffentlichen Schlüssel haben, erstellen Sie einen, indem Sie den folgenden Befehl ausführen.
```
$ ssh-keygen -t rsa -q -f "$HOME/.ssh/id_rsa" -N ""
```
1. Stellen Sie eine Verbindung zum Clusterknoten her und wechseln Sie zum Benutzer, um den Schlüssel hinzuzufügen. Der folgende Befehl ist ein Beispiel für den Zugriff als `ubuntu`-Benutzer. Ersetzen Sie `ubuntu` durch den Benutzernamen, für den Sie den einfachen Zugriff mit SSH einrichten möchten.
```
$ ./easy-ssh.sh -c
$ sudo su - ubuntu
ubuntu@ip-111-22-333-444:/usr/bin#
```
1. Öffnen Sie die `~/.ssh/authorized_keys`-Datei und fügen Sie den öffentlichen Schlüssel am Ende der Datei hinzu.
```
ubuntu@ip-111-22-333-444:/usr/bin# vim ~/.ssh/authorized_keys
```
Nachdem Sie die Einrichtung abgeschlossen haben, können Sie als Benutzer eine Verbindung zum HyperPod Clusterknoten herstellen, indem Sie einen vereinfachten SSH-Befehl wie folgt ausführen.
```
$ ssh
ubuntu@ip-111-22-333-444:/usr/bin#
```
Sie können den Host auch für die Remote-Entwicklung von einer IDE auf Ihrem lokalen Gerät aus verwenden, z. B. [Visual Studio Code Remote – SSH](https://code.visualstudio.com/docs/remote/ssh).
## Richten Sie über den Amazon FSx Shared Space eine Mehrbenutzerumgebung ein
Sie können den Amazon FSx Shared Space verwenden, um eine Mehrbenutzerumgebung in einem Slurm-Cluster auf zu verwalten. SageMaker HyperPod Wenn Sie Ihren Slurm-Cluster FSx während der HyperPod Cluster-Erstellung mit Amazon konfiguriert haben, ist dies eine gute Option, um Workspace für Ihre Cluster-Benutzer einzurichten. Erstellen Sie einen neuen Benutzer und richten Sie das Home-Verzeichnis für den Benutzer im FSx gemeinsamen Amazon-Dateisystem ein.
**Tipp**
Damit Benutzer über ihren Benutzernamen und dedizierte Verzeichnisse auf Ihren Cluster zugreifen können, sollten Sie sie auch mit IAM-Rollen oder Benutzern verknüpfen, indem Sie sie gemäß den Anweisungen in **Option 2** von Schritt 5 unter dem Verfahren **So aktivieren Sie die Unterstützung von „Ausführen als“ für verwaltete Linux- und macOS-Knoten** im AWS Systems Manager -Benutzerhandbuch.[https://docs.aws.amazon.com/systems-manager/latest/userguide/session-preferences-run-as.html](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-preferences-run-as.html) Siehe auch [Einrichtung AWS Systems Manager und Ausführung als für die Cluster-Benutzerzugriffskontrolle](sagemaker-hyperpod-prerequisites.md#sagemaker-hyperpod-prerequisites-ssm).
**Um eine Mehrbenutzer-Umgebung einzurichten und gleichzeitig einen Slurm-Cluster zu erstellen SageMaker HyperPod**
Das SageMaker HyperPod Serviceteam stellt ein Skript [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/add_users.sh](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/add_users.sh)als Teil der Script-Beispiele für den Basislebenszyklus zur Verfügung.
1. Bereiten Sie eine Textdatei mit dem Namen vor `shared_users.txt`, die Sie im folgenden Format erstellen müssen. Die erste Spalte ist für Benutzernamen, die zweite Spalte für eindeutige Benutzer IDs und die dritte Spalte für die Benutzerverzeichnisse im FSx gemeinsamen Amazon-Bereich.
```
username1,uid1,/fsx/username1
username2,uid2,/fsx/username2
...
```
1. Stellen Sie sicher, dass Sie die [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/add_users.sh](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/add_users.sh)Dateien `shared_users.txt` und in den S3-Bucket für HyperPod Lifecycle-Skripte hochladen. Während die Clustererstellung, die Clusteraktualisierung oder die Cluster-Softwareaktualisierung läuft, liest [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/add_users.sh](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/add_users.sh) die Daten in `shared_users.txt` und richtet die Benutzerverzeichnisse ordnungsgemäß ein.
**Um neue Benutzer zu erstellen und sie zu einem bestehenden Slurm-Cluster hinzuzufügen, der auf läuft SageMaker HyperPod **
1. Führen Sie auf dem Hauptknoten den folgenden Befehl aus, um ein Skript zu speichern, das beim Erstellen eines Benutzers hilft. Stellen Sie sicher, dass Sie dies mit Sudo-Berechtigungen ausführen.
```
$ cat > create-user.sh << EOL
#!/bin/bash
set -x
# Prompt user to get the new user name.
read -p "Enter the new user name, i.e. 'sean':
" USER
# create home directory as /fsx/
# Create the new user on the head node
sudo useradd \$USER -m -d /fsx/\$USER --shell /bin/bash;
user_id=\$(id -u \$USER)
# add user to docker group
sudo usermod -aG docker \${USER}
# setup SSH Keypair
sudo -u \$USER ssh-keygen -t rsa -q -f "/fsx/\$USER/.ssh/id_rsa" -N ""
sudo -u \$USER cat /fsx/\$USER/.ssh/id_rsa.pub | sudo -u \$USER tee /fsx/\$USER/.ssh/authorized_keys
# add user to compute nodes
read -p "Number of compute nodes in your cluster, i.e. 8:
" NUM_NODES
srun -N \$NUM_NODES sudo useradd -u \$user_id \$USER -d /fsx/\$USER --shell /bin/bash;
# add them as a sudoer
read -p "Do you want this user to be a sudoer? (y/N):
" SUDO
if [ "\$SUDO" = "y" ]; then
sudo usermod -aG sudo \$USER
sudo srun -N \$NUM_NODES sudo usermod -aG sudo \$USER
echo -e "If you haven't already you'll need to run:\n\nsudo visudo /etc/sudoers\n\nChange the line:\n\n%sudo ALL=(ALL:ALL) ALL\n\nTo\n\n%sudo ALL=(ALL:ALL) NOPASSWD: ALL\n\nOn each node."
fi
EOL
```
1. Führen Sie das Skript mit dem folgenden Befehl aus. Sie werden aufgefordert, den Namen eines Benutzers und die Anzahl der Rechenknoten hinzuzufügen, auf die der Benutzer zugreifen kann.
```
$ bash create-user.sh
```
1. Testen Sie den Benutzer, indem Sie die folgenden Befehle ausführen.
```
$ sudo su - && ssh $(srun hostname)
```
1. Fügen Sie die Benutzerinformationen zur `shared_users.txt`-Datei hinzu, sodass der Benutzer auf allen neuen Rechenknoten oder neuen Clustern erstellt wird.
## Richten Sie eine Mehrbenutzerumgebung ein, indem Sie HyperPod Cluster in Active Directory integrieren
In praktischen Anwendungsfällen werden HyperPod Cluster in der Regel von mehreren Benutzern verwendet: Forschern für maschinelles Lernen (ML), Softwareingenieuren, Datenwissenschaftlern und Clusteradministratoren. Sie bearbeiten ihre eigenen Dateien und führen ihre eigenen Aufträge aus, ohne sich gegenseitig bei der Arbeit zu beeinträchtigen. Um eine Mehrbenutzerumgebung einzurichten, verwenden Sie den Linux-Benutzer- und Gruppenmechanismus, um mithilfe von Lebenszyklusskripten statisch mehrere Benutzer für jede Instance zu erstellen. Der Nachteil dieses Ansatzes besteht jedoch darin, dass Sie Benutzer- und Gruppeneinstellungen über mehrere Instances im Cluster hinweg duplizieren müssen, um bei Aktualisierungen wie dem Hinzufügen, Bearbeiten und Entfernen von Benutzern eine konsistente Konfiguration über alle Instances hinweg zu gewährleisten.
Um dieses Problem zu lösen, können Sie [Lightweight Directory Access Protocol (LDAP) und LDAP](https://en.wikipedia.org/wiki/Lightweight_Directory_Access_Protocol) [Over TLS/SSL (LDAPS)](https://en.wikipedia.org/wiki/Lightweight_Directory_Access_Protocol) verwenden, um die Integration in einen Directory Service wie den [Verzeichnisdienst für Microsoft AWS Active Directory](https://aws.amazon.com/directoryservice/) zu ermöglichen. Weitere Informationen zur Einrichtung von Active Directory und einer Mehrbenutzerumgebung in einem HyperPod Cluster finden Sie im Blogbeitrag [Integrieren von HyperPod Clustern mit Active Directory für](https://aws.amazon.com/blogs/machine-learning/integrate-hyperpod-clusters-with-active-directory-for-seamless-multi-user-login/) eine nahtlose Mehrbenutzeranmeldung.
# Planung eines Slurm-Jobs auf einem Cluster SageMaker HyperPod
Sie können Trainingsjobs mit den Standard-Slurm-Befehlen `sbatch` oder `srun` starten. Um beispielsweise einen Trainingsjob mit 8 Knoten zu starten, können Sie `srun -N 8 --exclusive train.sh` SageMaker HyperPod unterstützende Schulungen in einer Reihe von Umgebungen ausführen, darunter`conda`, `venv``docker`, und`enroot`. Sie können eine ML-Umgebung konfigurieren, indem Sie Lifecycle-Skripten auf Ihren SageMaker HyperPod Clustern ausführen. Sie haben auch die Möglichkeit, ein gemeinsam genutztes Dateisystem wie Amazon anzuhängen FSx, das auch als virtuelle Umgebung verwendet werden kann.
Das folgende Beispiel zeigt, wie ein Job zum Trainieren von Llama-2 mit der FSDP-Technik (Fully Sharded Data Parallelism) auf einem SageMaker HyperPod Cluster mit einem gemeinsamen Amazon-Dateisystem ausgeführt wird. FSx [Weitere Beispiele finden Sie auch im Awsome Distributed Training Repository. GitHub ](https://github.com/aws-samples/awsome-distributed-training/)
**Tipp**
Alle SageMaker HyperPod Beispiele sind im `3.test_cases` Ordner des [Awsome Distributed Training GitHub ](https://github.com/aws-samples/awsome-distributed-training/) Repositorys verfügbar.
1. Klonen Sie das [Awsome Distributed Training GitHub Repository](https://github.com/aws-samples/awsome-distributed-training/) und kopieren Sie die Beispiele für Trainingsjobs in Ihr FSx Amazon-Dateisystem.
```
$ TRAINING_DIR=/fsx/users/my-user/fsdp
$ git clone https://github.com/aws-samples/awsome-distributed-training/
```
1. Führen Sie das [https://github.com/aws-samples/awsome-distributed-training/blob/main/3.test_cases/10.FSDP/0.create_conda_env.sh](https://github.com/aws-samples/awsome-distributed-training/blob/main/3.test_cases/10.FSDP/0.create_conda_env.sh)-Skript aus. Dadurch wird eine `conda` Umgebung auf Ihrem FSx Amazon-Dateisystem erstellt. Stellen Sie sicher, dass das Dateisystem für alle Knoten im Cluster zugänglich ist.
1. Erstellen Sie die virtuelle Conda-Umgebung, indem Sie einen Slurm-Auftrag mit einem einzelnen Knoten wie folgt starten.
```
$ srun -N 1 /path_to/create_conda_env.sh
```
1. Nachdem die Umgebung erstellt wurde, können Sie einen Trainingsjob starten, indem Sie auf den Umgebungspfad auf dem gemeinsam genutzten Volume verweisen. Sie können sowohl Trainingsjobs mit einem Knoten als auch mit mehreren Knoten mit derselben Konfiguration starten. Um einen Job zu starten, erstellen Sie wie folgt ein Job-Launcher-Skript (auch als Einstiegspunktskript bezeichnet).
```
#!/usr/bin/env bash
set -ex
ENV_PATH=/fsx/users/my_user/pytorch_env
TORCHRUN=$ENV_PATH/bin/torchrun
TRAINING_SCRIPT=/fsx/users/my_user/pt_train.py
WORLD_SIZE_JOB=$SLURM_NTASKS
RANK_NODE=$SLURM_NODEID
PROC_PER_NODE=8
MASTER_ADDR=(`scontrol show hostnames \$SLURM_JOB_NODELIST | head -n 1`)
MASTER_PORT=$(expr 10000 + $(echo -n $SLURM_JOBID | tail -c 4))
DIST_ARGS="--nproc_per_node=$PROC_PER_NODE \
--nnodes=$WORLD_SIZE_JOB \
--node_rank=$RANK_NODE \
--master_addr=$MASTER_ADDR \
--master_port=$MASTER_PORT \
"
$TORCHRUN $DIST_ARGS $TRAINING_SCRIPT
```
**Tipp**
Wenn Sie Ihren Trainingsjob mithilfe der Funktion zur automatischen Wiederaufnahme von widerstandsfähiger gegen Hardwareausfälle machen möchten SageMaker HyperPod, müssen Sie die Umgebungsvariable `MASTER_ADDR` im Entrypoint-Skript ordnungsgemäß einrichten. Weitere Informationen hierzu finden Sie unter [Automatische Knotenwiederherstellung und automatische Wiederaufnahme](sagemaker-hyperpod-resiliency-slurm-auto-resume.md).
In diesem Tutorial wird davon ausgegangen, dass dieses Skript unter `/fsx/users/my_user/train.sh` gespeichert ist.
1. Führen Sie mit diesem Skript im freigegebenen Volume unter `/fsx/users/my_user/train.sh` den folgenden `srun`-Befehl aus, um den Slurm-Auftrag zu planen.
```
$ cd /fsx/users/my_user/
$ srun -N 8 train.sh
```
# Docker-Container auf einem Slurm-Rechenknoten ausführen auf HyperPod
[https://github.com/NVIDIA/enroot](https://github.com/NVIDIA/enroot) Das Enroot-Paket hilft dabei, Docker-Images in eine Laufzeitumgebung zu konvertieren, die Slurm verstehen kann, während Pyxis die Planung der Laufzeitumgebung als Slurm-Auftrag über einen `srun`-Befehl, `srun --container-image=docker/image:tag`, ermöglicht.
**Tipp**
Die Docker-, Enroot- und Pyxis-Pakete sollten während der Clustererstellung als Teil der Ausführung der Lebenszyklusskripte wie in der Anleitung [Die grundlegenden Lebenszyklusskripte werden bereitgestellt von HyperPod](sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-base-config.md) beschrieben installiert werden. Verwenden Sie bei der Erstellung [eines Clusters die vom HyperPod Serviceteam bereitgestellten Basis-Lebenszyklus-Skripte](https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config). HyperPod Diese Basisskripte sind standardmäßig so eingerichtet, dass sie die Pakete installieren. Im [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/config.py](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/config.py)-Skript gibt es die `Config`-Klasse mit dem Booleschen Typparameter für die Installation der Pakete, der auf `True` (`enable_docker_enroot_pyxis=True`) gesetzt ist. Dies wird vom [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/lifecycle_script.py](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/lifecycle_script.py)-Skript aufgerufen und analysiert, das `install_docker.sh`- und `install_enroot_pyxis.sh`-Skripte aus dem [https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/utils](https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/utils)-Ordner aufruft und ausführt. In den Installationsskripten finden die eigentlichen Installationen der Pakete statt. Darüber hinaus ermitteln die Installationsskripten, ob sie NVMe Speicherpfade von den Instances, auf denen sie ausgeführt werden, erkennen können, und richten die Root-Pfade für Docker und Enroot ein. `/opt/dlami/nvme` Das Standard-Root-Volume jeder neuen Instance wird `/tmp` nur mit einem 100-GB-EBS-Volume gemountet. Dieses Volume läuft aus, wenn der Workload, den Sie ausführen möchten, das Training von Docker-Containern LLMs und somit großen Docker-Containern beinhaltet. Wenn Sie Instance-Familien wie P und G mit lokalem NVMe Speicher verwenden, müssen Sie sicherstellen, dass Sie den NVMe Speicher verwenden, der unter angehängt ist`/opt/dlami/nvme`, und die Installationsskripten kümmern sich um die Konfigurationsprozesse.
**So überprüfen Sie, ob die Root-Pfade richtig eingerichtet sind**
Führen Sie auf einem Rechenknoten Ihres eingeschalteten Slurm-Clusters die folgenden Befehle aus SageMaker HyperPod, um sicherzustellen, dass das Lifecycle-Skript ordnungsgemäß funktioniert hat und das Root-Volume jedes Knotens auf `/opt/dlami/nvme/*` eingestellt ist. Die folgenden Befehle zeigen Beispiele für die Überprüfung des Enroot-Laufzeitpfads und des Daten-Root-Pfads für 8 Rechenknoten eines Slurm-Clusters.
```
$ srun -N 8 cat /etc/enroot/enroot.conf | grep "ENROOT_RUNTIME_PATH"
ENROOT_RUNTIME_PATH /opt/dlami/nvme/tmp/enroot/user-$(id -u)
... // The same or similar lines repeat 7 times
```
```
$ srun -N 8 cat /etc/docker/daemon.json
{
"data-root": "/opt/dlami/nvme/docker/data-root"
}
... // The same or similar lines repeat 7 times
```
Nachdem Sie überprüft haben, dass die Laufzeitpfade korrekt auf `/opt/dlami/nvme/*` festgelegt sind, können Sie Docker-Container mit Enroot und Pyxis erstellen und ausführen.
**So testen Sie Docker mit Slurm**
1. Probieren Sie auf Ihrem Rechenknoten die folgenden Befehle aus, um zu überprüfen, ob Docker und Enroot ordnungsgemäß installiert sind.
```
$ docker --help
$ enroot --help
```
1. Testen Sie, ob Pyxis und Enroot korrekt installiert wurden, indem Sie eines der Images von [NVIDIA CUDA Ubuntu](https://catalog.ngc.nvidia.com/orgs/nvidia/containers/cuda) ausführen.
```
$ srun --container-image=nvidia/cuda:XX.Y.Z-base-ubuntuXX.YY nvidia-smi
pyxis: importing docker image: nvidia/cuda:XX.Y.Z-base-ubuntuXX.YY
pyxis: imported docker image: nvidia/cuda:XX.Y.Z-base-ubuntuXX.YY
DAY MMM DD HH:MM:SS YYYY
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 470.141.03 Driver Version: 470.141.03 CUDA Version: XX.YY |
|-------------------------------+----------------------+----------------------+
| GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. |
| | | MIG M. |
|===============================+======================+======================|
| 0 Tesla T4 Off | 00000000:00:1E.0 Off | 0 |
| N/A 40C P0 27W / 70W | 0MiB / 15109MiB | 0% Default |
| | | N/A |
+-------------------------------+----------------------+----------------------+
+-----------------------------------------------------------------------------+
| Processes: |
| GPU GI CI PID Type Process name GPU Memory |
| ID ID Usage |
|=============================================================================|
| No running processes found |
+-----------------------------------------------------------------------------+
```
Sie können es auch testen, indem Sie ein Skript erstellen und einen `sbatch`-Befehl wie folgt ausführen.
```
$ cat <> container-test.sh
#!/bin/bash
#SBATCH --container-image=nvidia/cuda:XX.Y.Z-base-ubuntuXX.YY
nvidia-smi
EOF
$ sbatch container-test.sh
pyxis: importing docker image: nvidia/cuda:XX.Y.Z-base-ubuntuXX.YY
pyxis: imported docker image: nvidia/cuda:XX.Y.Z-base-ubuntuXX.YY
DAY MMM DD HH:MM:SS YYYY
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 470.141.03 Driver Version: 470.141.03 CUDA Version: XX.YY |
|-------------------------------+----------------------+----------------------+
| GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. |
| | | MIG M. |
|===============================+======================+======================|
| 0 Tesla T4 Off | 00000000:00:1E.0 Off | 0 |
| N/A 40C P0 27W / 70W | 0MiB / 15109MiB | 0% Default |
| | | N/A |
+-------------------------------+----------------------+----------------------+
+-----------------------------------------------------------------------------+
| Processes: |
| GPU GI CI PID Type Process name GPU Memory |
| ID ID Usage |
|=============================================================================|
| No running processes found |
+-----------------------------------------------------------------------------+
```
**So führen Sie einen Test-Slurm-Auftrag mit Docker aus**
Nachdem Sie die Einrichtung von Slurm mit Docker abgeschlossen haben, können Sie alle vorgefertigten Docker-Images verwenden und mit Slurm on ausführen. SageMaker HyperPod Im Folgenden finden Sie ein Beispiel für einen Anwendungsfall, der Ihnen zeigt, wie Sie einen Trainingsjob mit Docker und eingeschaltetem Slurm ausführen. SageMaker HyperPod Es zeigt ein Beispiel für das modellparallele Training des Llama-2-Modells mit der SageMaker AI-Bibliothek für Modellparallelismus (SMP).
1. Wenn Sie eines der vorgefertigten ECR-Images verwenden möchten, die von SageMaker AI oder DLC vertrieben werden, stellen Sie sicher, dass Sie Ihrem HyperPod Cluster die Berechtigungen zum Abrufen von ECR-Bildern über die geben. [IAM-Rolle für SageMaker HyperPod](sagemaker-hyperpod-prerequisites-iam.md#sagemaker-hyperpod-prerequisites-iam-role-for-hyperpod) Wenn Sie ein eigenes oder ein Docker-Image (Open Source) verwenden, können Sie diesen Schritt überspringen. Fügen Sie [IAM-Rolle für SageMaker HyperPod](sagemaker-hyperpod-prerequisites-iam.md#sagemaker-hyperpod-prerequisites-iam-role-for-hyperpod) die folgenden Berechtigungen hinzu. In diesem Tutorial verwenden wir das [SMP-Docker-Image](distributed-model-parallel-support-v2.md#distributed-model-parallel-supported-frameworks-v2), das mit der SMP-Bibliothek vorinstalliert ist.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ecr:BatchCheckLayerAvailability",
"ecr:BatchGetImage",
"ecr-public:*",
"ecr:GetDownloadUrlForLayer",
"ecr:GetAuthorizationToken",
"sts:*"
],
"Resource": "*"
}
]
}
```
------
1. Klonen Sie auf dem Rechenknoten das Repository und wechseln Sie zu dem Ordner, der die Beispielskripte für das Training mit SMP enthält.
```
$ git clone https://github.com/aws-samples/awsome-distributed-training/
$ cd awsome-distributed-training/3.test_cases/17.SM-modelparallelv2
```
1. Führen Sie in diesem Tutorial das Beispielskript-[https://github.com/aws-samples/awsome-distributed-training/blob/main/3.test_cases/17.SM-modelparallelv2/docker_build.sh](https://github.com/aws-samples/awsome-distributed-training/blob/main/3.test_cases/17.SM-modelparallelv2/docker_build.sh) aus, das das SMP-Docker-Image abruft, den Docker-Container erstellt und ihn als Enroot-Laufzeitumgebung ausführt. Sie können dies nach Belieben ändern.
```
$ cat docker_build.sh
#!/usr/bin/env bash
region=us-west-2
dlc_account_id=658645717510
aws ecr get-login-password --region $region | docker login --username AWS --password-stdin $dlc_account_id.dkr.ecr.$region.amazonaws.com
docker build -t smpv2 .
enroot import -o smpv2.sqsh dockerd://smpv2:latest
```
```
$ bash docker_build.sh
```
1. Erstellen Sie ein Batch-Skript, um einen Trainingsjob mit `sbatch` zu starten. In diesem Tutorial startet das bereitgestellte Beispielskript [https://github.com/aws-samples/awsome-distributed-training/blob/main/3.test_cases/17.SM-modelparallelv2/launch_training_enroot.sh](https://github.com/aws-samples/awsome-distributed-training/blob/main/3.test_cases/17.SM-modelparallelv2/launch_training_enroot.sh) einen modellparallelen Trainingsjob des Llama 2-Modells mit 70 Milliarden Parametern und einem synthetischen Datensatz auf 8 Rechenknoten. Eine Reihe von Trainingsskripten wird unter [https://github.com/aws-samples/awsome-distributed-training/tree/main/3.test_cases/17.SM-modelparallelv2/scripts](https://github.com/aws-samples/awsome-distributed-training/tree/main/3.test_cases/17.SM-modelparallelv2/scripts) bereitgestellt und `launch_training_enroot.sh` nimmt `train_external.py` als Einstiegsskript.
**Wichtig**
Um einen Docker-Container zu verwenden SageMaker HyperPod, müssen Sie das `/var/log` Verzeichnis vom Host-Computer, der in diesem Fall der HyperPod Rechenknoten ist, in das Verzeichnis im Container mounten. `/var/log` Sie können ihn einrichten, indem Sie die folgende Variable für Enroot hinzufügen.
```
"${HYPERPOD_PATH:="/var/log/aws/clusters":"/var/log/aws/clusters"}"
```
```
$ cat launch_training_enroot.sh
#!/bin/bash
# Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
# SPDX-License-Identifier: MIT-0
#SBATCH --nodes=8 # number of nodes to use, 2 p4d(e) = 16 A100 GPUs
#SBATCH --job-name=smpv2_llama # name of your job
#SBATCH --exclusive # job has exclusive use of the resource, no sharing
#SBATCH --wait-all-nodes=1
set -ex;
###########################
###### User Variables #####
###########################
#########################
model_type=llama_v2
model_size=70b
# Toggle this to use synthetic data
use_synthetic_data=1
# To run training on your own data set Training/Test Data path -> Change this to the tokenized dataset path in Fsx. Acceptable formats are huggingface (arrow) and Jsonlines.
# Also change the use_synthetic_data to 0
export TRAINING_DIR=/fsx/path_to_data
export TEST_DIR=/fsx/path_to_data
export CHECKPOINT_DIR=$(pwd)/checkpoints
# Variables for Enroot
: "${IMAGE:=$(pwd)/smpv2.sqsh}"
: "${HYPERPOD_PATH:="/var/log/aws/clusters":"/var/log/aws/clusters"}" # This is needed for validating its hyperpod cluster
: "${TRAIN_DATA_PATH:=$TRAINING_DIR:$TRAINING_DIR}"
: "${TEST_DATA_PATH:=$TEST_DIR:$TEST_DIR}"
: "${CHECKPOINT_PATH:=$CHECKPOINT_DIR:$CHECKPOINT_DIR}"
###########################
## Environment Variables ##
###########################
#export NCCL_SOCKET_IFNAME=en
export NCCL_ASYNC_ERROR_HANDLING=1
export NCCL_PROTO="simple"
export NCCL_SOCKET_IFNAME="^lo,docker"
export RDMAV_FORK_SAFE=1
export FI_EFA_USE_DEVICE_RDMA=1
export NCCL_DEBUG_SUBSYS=off
export NCCL_DEBUG="INFO"
export SM_NUM_GPUS=8
export GPU_NUM_DEVICES=8
export FI_EFA_SET_CUDA_SYNC_MEMOPS=0
# async runtime error ...
export CUDA_DEVICE_MAX_CONNECTIONS=1
#########################
## Command and Options ##
#########################
if [ "$model_size" == "7b" ]; then
HIDDEN_WIDTH=4096
NUM_LAYERS=32
NUM_HEADS=32
LLAMA_INTERMEDIATE_SIZE=11008
DEFAULT_SHARD_DEGREE=8
# More Llama model size options
elif [ "$model_size" == "70b" ]; then
HIDDEN_WIDTH=8192
NUM_LAYERS=80
NUM_HEADS=64
LLAMA_INTERMEDIATE_SIZE=28672
# Reduce for better perf on p4de
DEFAULT_SHARD_DEGREE=64
fi
if [ -z "$shard_degree" ]; then
SHARD_DEGREE=$DEFAULT_SHARD_DEGREE
else
SHARD_DEGREE=$shard_degree
fi
if [ -z "$LLAMA_INTERMEDIATE_SIZE" ]; then
LLAMA_ARGS=""
else
LLAMA_ARGS="--llama_intermediate_size $LLAMA_INTERMEDIATE_SIZE "
fi
if [ $use_synthetic_data == 1 ]; then
echo "using synthetic data"
declare -a ARGS=(
--container-image $IMAGE
--container-mounts $HYPERPOD_PATH,$CHECKPOINT_PATH
)
else
echo "using real data...."
declare -a ARGS=(
--container-image $IMAGE
--container-mounts $HYPERPOD_PATH,$TRAIN_DATA_PATH,$TEST_DATA_PATH,$CHECKPOINT_PATH
)
fi
declare -a TORCHRUN_ARGS=(
# change this to match the number of gpus per node:
--nproc_per_node=8 \
--nnodes=$SLURM_JOB_NUM_NODES \
--rdzv_id=$SLURM_JOB_ID \
--rdzv_backend=c10d \
--rdzv_endpoint=$(hostname) \
)
srun -l "${ARGS[@]}" torchrun "${TORCHRUN_ARGS[@]}" /path_to/train_external.py \
--train_batch_size 4 \
--max_steps 100 \
--hidden_width $HIDDEN_WIDTH \
--num_layers $NUM_LAYERS \
--num_heads $NUM_HEADS \
${LLAMA_ARGS} \
--shard_degree $SHARD_DEGREE \
--model_type $model_type \
--profile_nsys 1 \
--use_smp_implementation 1 \
--max_context_width 4096 \
--tensor_parallel_degree 1 \
--use_synthetic_data $use_synthetic_data \
--training_dir $TRAINING_DIR \
--test_dir $TEST_DIR \
--dataset_type hf \
--checkpoint_dir $CHECKPOINT_DIR \
--checkpoint_freq 100 \
$ sbatch launch_training_enroot.sh
```
*Die herunterladbaren Codebeispiele finden Sie unter [Ausführen eines modellparallelen Trainingsjobs mithilfe der SageMaker AI-Modellparallelismusbibliothek, Docker und Enroot mit Slurm](https://github.com/aws-samples/awsome-distributed-training/tree/main/3.test_cases/17.SM-modelparallelv2#option-2----run-training-using-docker-and-enroot) im Awsome Distributed Training Repository. GitHub * Weitere Informationen zu verteiltem Training mit eingeschaltetem Slurm-Cluster finden Sie im nächsten Thema unter. SageMaker HyperPod [Ausführung verteilter Trainingsworkloads mit aktiviertem Slurm HyperPod](sagemaker-hyperpod-run-jobs-slurm-distributed-training-workload.md)
# Ausführung verteilter Trainingsworkloads mit aktiviertem Slurm HyperPod
SageMaker HyperPod ist auf das Training großer Sprachmodelle (LLMs) und Basismodelle () spezialisiert. FMs Diese Workloads erfordern häufig den Einsatz mehrerer Parallelitätstechniken und optimierter Abläufe für die ML-Infrastruktur und -Ressourcen. Mithilfe von SageMaker HyperPod können Sie die folgenden verteilten SageMaker KI-Schulungs-Frameworks verwenden:
+ Die [SageMaker AI-Bibliothek für verteilte Datenparallelität (SMDDP)](data-parallel.md), die kollektive Kommunikationsoperationen bietet, die optimiert sind für. AWS
+ Die [SageMaker AI-Bibliothek für Modellparallelismus (SMP)](model-parallel-v2.md), die verschiedene Techniken zur Modellparallelität implementiert.
**Topics**
+ [Verwenden von SMDDP auf einem SageMaker HyperPod](#sagemaker-hyperpod-run-jobs-slurm-distributed-training-workload-smddp)
+ [SMP auf einem Cluster verwenden SageMaker HyperPod](#sagemaker-hyperpod-run-jobs-slurm-distributed-training-workload-smp)
## Verwenden von SMDDP auf einem SageMaker HyperPod
Die [SMDDP-Bibliothek](data-parallel.md) ist eine kollektive Kommunikationsbibliothek, die die Rechenleistung von parallelem Training mit verteilten Daten verbessert. Die SMDDP-Bibliothek funktioniert mit den folgenden verteilten Trainings-Frameworks (Open Source):
+ [PyTorchparallel verteilte Daten (DDP)](https://pytorch.org/docs/stable/notes/ddp.html)
+ [PyTorch vollständig vernetzte Datenparallelität (FSDP)](https://pytorch.org/docs/stable/fsdp.html)
+ [DeepSpeed](https://github.com/microsoft/DeepSpeed)
+ [Megatron- DeepSpeed](https://github.com/microsoft/Megatron-DeepSpeed)
Die SMDDP-Bibliothek deckt den Kommunikationsaufwand der wichtigsten kollektiven Kommunikationsoperationen ab, indem sie Folgendes für anbietet. SageMaker HyperPod
+ Die Bibliothek bietet `AllGather` optimierte Angebote für. AWS`AllGather`ist eine wichtige Operation, die beim Sharded Data Parallel Training verwendet wird. Dabei handelt es sich um eine speichereffiziente Technik zur Datenparallelität, die von gängigen Bibliotheken angeboten wird. Dazu gehören die Bibliothek SageMaker AI Model Parallelism (SMP), DeepSpeed Zero Redundancy Optimizer (ZerO) und Fully Sharded Data Parallelism (FSDP). PyTorch
+ Die Bibliothek ermöglicht eine optimierte node-to-node Kommunikation, indem sie die Netzwerkinfrastruktur und die KI-ML-Instanztopologie vollständig nutzt. AWS SageMaker
**So führen Sie Beispiele für datenparallele Trainingsjobs aus**
Entdecken Sie die folgenden verteilten Trainingsbeispiele, die Datenparallelitätstechniken unter Verwendung der SMDDP-Bibliothek implementieren.
+ [https://github.com/aws-samples/awsome-distributed-training/tree/main/3.test_cases/12.SM-dataparallel-FSDP](https://github.com/aws-samples/awsome-distributed-training/tree/main/3.test_cases/12.SM-dataparallel-FSDP)
+ [https://github.com/aws-samples/awsome-distributed-training/tree/main/3.test_cases/13.SM-dataparallel-deepspeed](https://github.com/aws-samples/awsome-distributed-training/tree/main/3.test_cases/13.SM-dataparallel-deepspeed)
**Um eine Umgebung für die Verwendung der SMDDP-Bibliothek einzurichten auf SageMaker HyperPod**
Im Folgenden sind die Anforderungen an die Trainingsumgebung für die Verwendung der SMDDP-Bibliothek aufgeführt. SageMaker HyperPod
+ PyTorch v2.0.1 und höher
+ CUDA v11.8 und höher
+ `libstdc++`-Laufzeitversion 3 oder höher
+ Python v3.10.x oder höher
+ `ml.p4d.24xlarge` und `ml.p4de.24xlarge`, die von der SMDDP-Bibliothek unterstützte Instance-Typen sind
+ `imdsv2` auf dem Trainingshost aktiviert
Je nachdem, wie Sie den verteilten Trainingsjob ausführen möchten, gibt es zwei Möglichkeiten, die SMDDP-Bibliothek zu installieren:
+ Eine direkte Installation mithilfe der SMDDP-Binärdatei.
+ Verwenden der SageMaker AI Deep Learning Containers (DLCs), auf denen die SMDDP-Bibliothek vorinstalliert ist.
[Docker-Images, auf denen die SMDDP-Bibliothek oder die SMDDP-Binärdateien vorinstalliert sind, sind URLs in der Dokumentation zur SMDDP-Bibliothek unter Unterstützte Frameworks aufgeführt.](https://docs.aws.amazon.com/sagemaker/latest/dg/distributed-data-parallel-support.html#distributed-data-parallel-supported-frameworks)
**So installieren Sie die SMDDP-Bibliothek auf dem DLAMI SageMaker HyperPod**
+ `pip install --no-cache-dir https://smdataparallel.s3.amazonaws.com/binary/pytorch//cuXYZ/YYYY-MM-DD/smdistributed_dataparallel-X.Y.Z-cp310-cp310-linux_x86_64.whl`
**Anmerkung**
Wenn Sie in einer Conda-Umgebung arbeiten, stellen Sie sicher, dass Sie die Installation mit statt mit. PyTorch `conda install` `pip`
```
conda install pytorch==X.Y.Z torchvision==X.Y.Z torchaudio==X.Y.Z pytorch-cuda=X.Y.Z -c pytorch -c nvidia
```
**So verwenden Sie die SMDDP-Bibliothek in einem Docker-Container**
+ Die SMDDP-Bibliothek ist auf den SageMaker AI Deep Learning Containers () vorinstalliert. DLCs Eine Liste der SageMaker KI-Frameworks DLCs für PyTorch die SMDDP-Bibliothek finden Sie in der Dokumentation zur SMDDP-Bibliothek unter [Unterstützte Frameworks](https://docs.aws.amazon.com/sagemaker/latest/dg/distributed-data-parallel-support.html#distributed-data-parallel-supported-frameworks). Sie können auch Ihren eigenen Docker-Container einspielen, in dem die erforderlichen Abhängigkeiten installiert sind, um die SMDDP-Bibliothek zu verwenden. Weitere Informationen zum Einrichten eines benutzerdefinierten Docker-Containers zur Verwendung der SMDDP-Bibliothek finden Sie auch unter [Erstellen Sie Ihren eigenen Docker-Container mit der SageMaker AI Distributed Data Parallel Library](data-parallel-bring-your-own-container.md).
**Wichtig**
Um die SMDDP-Bibliothek in einem Docker-Container zu verwenden, mounten Sie das `/var/log`-Verzeichnis vom Host-Computer auf `/var/log` im Container. Dies kann erreicht werden, indem Sie beim Ausführen Ihres Containers die folgende Option hinzufügen.
```
docker run -v /var/log:/var/log ...
```
Informationen zur Ausführung datenparalleler Trainingsaufträge mit SMDDP im Allgemeinen finden Sie unter [Verteiltes Training mit der SageMaker KI-Bibliothek für verteilte Datenparallelität](data-parallel-modify-sdp.md).
## SMP auf einem Cluster verwenden SageMaker HyperPod
Die [SageMaker AI-Bibliothek für Modellparallelismus (SMP)](model-parallel-v2.md) bietet verschiedene Techniken zur [state-of-the-artModellparallelität](model-parallel-core-features-v2.md), darunter:
+ Parallelität vollständig fragmentierter Daten
+ Expertenparallelität
+ gemischtes Präzisionstraining mit/und Datentypen FP16 BF16 FP8
+ Tensor-Parallelität
Die SMP-Bibliothek ist auch mit Open-Source-Frameworks wie PyTorch FSDP, NVIDIA Megatron und NVIDIA Transformer Engine kompatibel.
**So führen Sie ein Beispiel für einen Workload mit modellparallelem Training aus**
Die SageMaker KI-Serviceteams bieten unter Beispielschulungen zur Implementierung der Modellparallelität mit der SMP-Bibliothek an. [https://github.com/aws-samples/awsome-distributed-training/tree/main/3.test_cases/17.SM-modelparallelv2](https://github.com/aws-samples/awsome-distributed-training/tree/main/3.test_cases/17.SM-modelparallelv2)
# SageMaker HyperPod Überwachung der Cluster-Ressourcen
Um eine umfassende Beobachtbarkeit Ihrer SageMaker HyperPod Cluster-Ressourcen und Softwarekomponenten zu erreichen, integrieren Sie den Cluster in [Amazon Managed Service for Prometheus](https://docs.aws.amazon.com/prometheus/latest/userguide/what-is-Amazon-Managed-Service-Prometheus.html) und [Amazon](https://docs.aws.amazon.com/grafana/latest/userguide/what-is-Amazon-Managed-Service-Grafana.html) Managed Grafana. Die Integration mit Amazon Managed Service for Prometheus ermöglicht den Export von Metriken zu Ihren HyperPod Cluster-Ressourcen und bietet so Einblicke in deren Leistung, Auslastung und Zustand. Die Integration mit Amazon Managed Grafana ermöglicht die Visualisierung dieser Metriken über verschiedene Grafana-Dashboards, die eine intuitive Oberfläche für die Überwachung und Analyse des Clusterverhaltens bieten. Durch die Nutzung dieser Services erhalten Sie eine zentralisierte und einheitliche Ansicht Ihres HyperPod Clusters, was die proaktive Überwachung, Fehlerbehebung und Optimierung Ihrer verteilten Trainingsworkloads erleichtert.
**Tipp**
[Praktische Beispiele und Lösungen finden Sie auch im SageMaker HyperPod Workshop.](https://catalog.workshops.aws/sagemaker-hyperpod)
![\[Ein Überblick über die Konfiguration SageMaker HyperPod mit Amazon Managed Service für Prometheus und Amazon Managed Grafana.\]](http://docs.aws.amazon.com/de_de/sagemaker/latest/dg/images/hyperpod-observability-architecture.png)
Abbildung: Dieses Architekturdiagramm zeigt einen Überblick über die Konfiguration SageMaker HyperPod mit Amazon Managed Service für Prometheus und Amazon Managed Grafana.
Fahren Sie mit den folgenden Themen fort, um die Cluster-Observability einzurichten. SageMaker HyperPod
**Topics**
+ [Voraussetzungen für die SageMaker HyperPod Cluster-Observability](sagemaker-hyperpod-cluster-observability-slurm-prerequisites.md)
+ [Installation von Metrics Exporter-Paketen auf Ihrem Cluster HyperPod](sagemaker-hyperpod-cluster-observability-slurm-install-exporters.md)
+ [Validierung des Prometheus-Setups auf dem Hauptknoten eines Clusters HyperPod](sagemaker-hyperpod-cluster-observability-slurm-validate-prometheus-setup.md)
+ [Einrichten eines Workspaces von Amazon Managed Grafana](sagemaker-hyperpod-cluster-observability-slurm-managed-grafana-ws.md)
+ [Referenz zu exportierten Metriken](sagemaker-hyperpod-cluster-observability-slurm-exported-metrics-reference.md)
+ [Amazon SageMaker HyperPod Slurm-Metriken](smcluster-slurm-metrics.md)
# Voraussetzungen für die SageMaker HyperPod Cluster-Observability
Bevor Sie mit den Schritten unter [Installation von Metrics Exporter-Paketen auf Ihrem Cluster HyperPod](sagemaker-hyperpod-cluster-observability-slurm-install-exporters.md) fortfahren, stellen Sie sicher, dass die folgenden Voraussetzungen erfüllt sind.
## IAM Identity Center aktivieren
Um Observability für Ihren SageMaker HyperPod Cluster zu aktivieren, müssen Sie zuerst IAM Identity Center aktivieren. Dies ist eine Voraussetzung für die Bereitstellung eines CloudFormation Stacks, der den Amazon Managed Grafana-Workspace und Amazon Managed Service für Prometheus einrichtet. Beide Services benötigen außerdem das IAM Identity Center für die Authentifizierung und Autorisierung, um den sicheren Benutzerzugriff und die Verwaltung der Überwachungsinfrastruktur zu gewährleisten.
Eine ausführliche Anleitung zur Aktivierung von IAM Identity Center finden Sie im Abschnitt [Aktivierung von IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/get-set-up-for-idc.html) im *Benutzerhandbuch für AWS IAM Identity Center*.
Nachdem Sie IAM Identity Center erfolgreich aktiviert haben, richten Sie ein Benutzerkonto ein, das während der folgenden Konfigurationsschritte als Administratorbenutzer dient.
## Erstellen und implementieren Sie einen Stack für CloudFormation Observability SageMaker HyperPod
Erstellen und implementieren Sie mithilfe von Amazon Managed Service for Prometheus und Amazon Managed Grafana einen CloudFormation Stack für SageMaker HyperPod Observability, um HyperPod Cluster-Metriken in Echtzeit zu überwachen. Beachten Sie, dass Sie vor der Bereitstellung des Stacks auch Ihr [IAM Identity Center](https://console.aws.amazon.com/singlesignon) aktivieren sollten.
Verwenden Sie das CloudFormation Beispielskript [https://github.com/aws-samples/awsome-distributed-training/blob/main/4.validation_and_observability/4.prometheus-grafana/cluster-observability.yaml](https://github.com/aws-samples/awsome-distributed-training/blob/main/4.validation_and_observability/4.prometheus-grafana/cluster-observability.yaml), das Ihnen hilft, Amazon VPC-Subnetze, Amazon FSx for Lustre-Dateisysteme, Amazon S3 S3-Buckets und IAM-Rollen einzurichten, die für die Erstellung eines Cluster-Observability-Stacks erforderlich sind. HyperPod
# Installation von Metrics Exporter-Paketen auf Ihrem Cluster HyperPod
Zu den vom SageMaker HyperPod Team bereitgestellten [Lebenszyklusskripten für die Basiskonfiguration](sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-base-config.md) gehört auch die Installation verschiedener Metrik-Export-Pakete. Um den Installationsschritt zu aktivieren, müssen Sie lediglich den Parameter `enable_observability=True` in der Datei [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/config.py](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/config.py) festlegen. Die Lebenszyklusskripte dienen dazu, Ihren Cluster mit den folgenden Metrik-Exporter-Paketen (Open Source) zu booten.
| | | |
| --- |--- |--- |
| Name | Zielknoten für die Skriptbereitstellung | Beschreibung des Exporters |
| [Slurm-Exporteur für Prometheus](https://github.com/vpenso/prometheus-slurm-exporter) | Hauptknoten (Controller) | Exportiert die Buchhaltungsmetriken von Slurm |
| [Knoten-Exporter von Elastic Fabric Adapter (EFA)](https://github.com/aws-samples/awsome-distributed-training/tree/main/4.validation_and_observability/3.efa-node-exporter) | Rechenknoten | Exportiert Metriken aus Clusterknoten und EFA. Das Paket ist eine Vergabelung des [Prometheus-Knoten-Exporters](https://github.com/prometheus/node_exporter). |
| [Exporter für NVIDIA Data Center GPU Management (DCGM)](https://github.com/NVIDIA/dcgm-exporter) | Rechenknoten | Exportiert NVIDIA DCGM-Metriken zum Zustand und zur Leistung von NVIDIA. GPUs |
Mit `enable_observability=True` in der Datei [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/config.py](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/config.py) wird der folgende Installationsschritt im [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/lifecycle_script.py](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/lifecycle_script.py)-Skript aktiviert.
```
# Install metric exporting software and Prometheus for observability
if Config.enable_observability:
if node_type == SlurmNodeType.COMPUTE_NODE:
ExecuteBashScript("./utils/install_docker.sh").run()
ExecuteBashScript("./utils/install_dcgm_exporter.sh").run()
ExecuteBashScript("./utils/install_efa_node_exporter.sh").run()
if node_type == SlurmNodeType.HEAD_NODE:
wait_for_scontrol()
ExecuteBashScript("./utils/install_docker.sh").run()
ExecuteBashScript("./utils/install_slurm_exporter.sh").run()
ExecuteBashScript("./utils/install_prometheus.sh").run()
```
Auf den Rechenknoten installiert das Skript den NVIDIA Data Center GPU Management (DCGM)-Exporter und den Elastic Fabric Adapter (EFA)-Knoten-Exporter. Der DCGM-Exporter ist ein Exporter für Prometheus, der Metriken von NVIDIA sammelt und so die Überwachung der GPU-Nutzung GPUs, Leistung und Integrität ermöglicht. Der EFA-Knoten-Exporter hingegen erfasst Metriken zur EFA-Netzwerkschnittstelle, die für eine Kommunikation mit geringer Latenz und hoher Bandbreite in HPC-Clustern unerlässlich ist.
Auf dem Hauptknoten installiert das Skript den Slurm-Exporter für Prometheus und die [Open-Source-Software Prometheus](https://prometheus.io/docs/introduction/overview/). Der Slurm-Exporter stellt Prometheus Metriken zu Slurm-Aufträgen, Partitionen und Knotenstatus zur Verfügung.
Beachten Sie, dass die Lebenszyklusskripte so konzipiert sind, dass sie alle Exportpakete als Docker-Container installieren. Daher sollte das Docker-Paket auch sowohl auf dem Haupt- als auch auf dem Compute-Knoten installiert werden. *Die Skripte für diese Komponenten befinden sich praktischerweise im [https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/utils](https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/utils)Ordner des Awsome Distributed Training Repositorys. GitHub *
Nachdem Sie Ihren HyperPod Cluster erfolgreich mit den Exportpaketen installiert haben, fahren Sie mit dem nächsten Thema fort, um die Einrichtung von Amazon Managed Service für Prometheus und Amazon Managed Grafana abzuschließen.
# Validierung des Prometheus-Setups auf dem Hauptknoten eines Clusters HyperPod
Nachdem Sie Ihren HyperPod Cluster erfolgreich mit den Exporter-Paketen installiert haben, überprüfen Sie, ob Prometheus auf dem Hauptknoten Ihres Clusters ordnungsgemäß eingerichtet ist. HyperPod
1. Stellen Sie eine Verbindung mit dem Hauptknoten Ihres Clusters her. Anweisungen zum Zugriff auf einen Knoten finden Sie unter [Zugriff auf Ihre SageMaker HyperPod Clusterknoten](sagemaker-hyperpod-run-jobs-slurm-access-nodes.md).
1. Führen Sie den folgenden Befehl aus, um zu überprüfen, ob die vom Lebenszyklusskript erstellte Prometheus-Konfigurations- und Servicedatei `install_prometheus.sh` auf dem Controller-Knoten ausgeführt wird. Die Ausgabe sollte den Status „Aktiv“ als **active (running)** anzeigen.
```
$ sudo systemctl status prometheus
• prometheus service - Prometheus Exporter
Loaded: loaded (/etc/systemd/system/prometheus.service; enabled; preset:disabled)
Active: active (running) since DAY YYYY-MM-DD HH:MM:SS UTC; Ss ago
Main PID: 12345 (prometheus)
Tasks: 7 (limit: 9281)
Memory: 35M
CPU: 234ms
CGroup: /system.slice/prometheus.service
-12345 /usr/bin/prometheus--config.file=/etc/prometheus/prometheus.yml
```
1. Überprüfen Sie die Prometheus-Konfigurationsdatei wie folgt. Die Ausgabe muss in etwa wie folgt aussehen, wobei drei Exporter mit den richtigen IP-Adressen der Rechenknoten konfiguriert sind.
```
$ cat /etc/prometheus/prometheus.yml
global:
scrape_interval: 15s
evaluation_interval: 15s
scrape_timeout: 15s
scrape_configs:
- job_name: 'slurm_exporter'
static_configs:
- targets:
- 'localhost:8080'
- job_name: 'dcgm_exporter'
static_configs:
- targets:
- ':9400'
- ':9400'
- job_name: 'efa_node_exporter'
static_configs:
- targets:
- ':9100'
- ':9100'
remote_write:
- url:
queue_config:
max_samples_per_send: 1000
max_shards: 200
capacity: 2500
sigv4:
region:
```
1. Um zu testen, ob Prometheus die Slurm-, DCGM- und EFA-Metriken ordnungsgemäß exportiert, führen Sie den folgenden `curl`-Befehl für Prometheus auf dem Port `:9090` des Hauptknotens aus.
```
$ curl -s http://localhost:9090/metrics | grep -E 'slurm|dcgm|efa'
```
Nachdem die Metriken über die Remote-Write-Konfiguration von Prometheus vom Controller-Knoten zu Amazon Managed Service für Prometheus Workspace exportiert wurden, können Sie mit dem nächsten Thema fortfahren, um die Dashboards von Amazon Managed Grafana für die Anzeige der Metriken einzurichten.
# Einrichten eines Workspaces von Amazon Managed Grafana
Erstellen Sie einen neuen Workspace von Amazon Managed Grafana oder aktualisieren Sie einen bestehenden mit Amazon Managed Service für Prometheus als Datenquelle.
**Topics**
+ [Erstellen Sie einen Grafana-Workspace und legen Sie Amazon Managed Service für Prometheus als Datenquelle fest.](#sagemaker-hyperpod-cluster-observability-slurm-managed-grafana-ws-create)
+ [Öffnen des Grafana-Workspaces und Beenden der Einrichtung der Datenquelle](#sagemaker-hyperpod-cluster-observability-slurm-managed-grafana-ws-connect-data-source)
+ [Importieren von Open-Source-Dashboards von Grafana](#sagemaker-hyperpod-cluster-observability-slurm-managed-grafana-ws-import-dashboards)
## Erstellen Sie einen Grafana-Workspace und legen Sie Amazon Managed Service für Prometheus als Datenquelle fest.
Um Metriken aus Amazon Managed Service für Prometheus zu visualisieren, erstellen Sie einen Workspace von Amazon Managed Grafana und richten Sie ihn so ein, dass Amazon Managed Service für Prometheus als Datenquelle verwendet wird.
1. Um einen Grafana-Workspace zu erstellen, befolgen Sie die Anweisungen unter [Erstellen eines Workspace](https://docs.aws.amazon.com/grafana/latest/userguide/AMG-create-workspace.html#creating-workspace) im *Benutzerhandbuch für Amazon Managed Service für Prometheus*.
1. Wählen Sie in Schritt 13 Amazon Managed Service für Prometheus als Datenquelle aus.
1. In Schritt 17 können Sie den Admin-Benutzer und auch andere Benutzer in Ihrem IAM Identity Center hinzufügen.
Weitere Informationen finden Sie auch in den folgenden Ressourcen.
+ [Einrichten von Amazon Managed Grafana für die Verwendung mit Amazon Managed Service für Prometheus](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-amg.html) im *Benutzerhandbuch für Amazon Managed Service für Prometheus*
+ [Verwenden Sie die AWS Datenquellenkonfiguration, um Amazon Managed Service for Prometheus als Datenquelle im *Amazon Managed Grafana-Benutzerhandbuch* hinzuzufügen](https://docs.aws.amazon.com/grafana/latest/userguide/AMP-adding-AWS-config.html)
## Öffnen des Grafana-Workspaces und Beenden der Einrichtung der Datenquelle
Nachdem Sie erfolgreich einen Workspace von Amazon Managed Grafana erstellt oder aktualisiert haben, wählen Sie die Workspace-URL aus, um den Workspace zu öffnen. Sie werden aufgefordert, einen Benutzernamen und das Passwort des Benutzers einzugeben, den Sie im IAM Identity Center eingerichtet haben. Sie sollten sich mit dem Admin-Benutzer anmelden, um die Einrichtung des Workspaces abzuschließen.
1. Wählen Sie auf der Workspace-**Startseite** **Apps**, **-Datenquellen** und **Datenquellen** aus.
1. Wählen Sie auf der Seite **Datenquellen** die Registerkarte **Datenquellen** aus.
1. Wählen Sie für **Service** Amazon Managed Service für Prometheus aus.
1. Wählen **Sie im Abschnitt Datenquellen durchsuchen und bereitstellen** die AWS Region aus, in der Sie einen Amazon Managed Service for Prometheus Workspace bereitgestellt haben.
1. Wählen Sie aus der Liste der Datenquellen in der ausgewählten Region die für Amazon Managed Service für Prometheus aus. Stellen Sie sicher, dass Sie die Ressourcen-ID und den Ressourcenalias des Amazon Managed Service for Prometheus Workspace überprüfen, den Sie für den HyperPod Observability Stack eingerichtet haben.
## Importieren von Open-Source-Dashboards von Grafana
Nachdem Sie Ihren Workspace von Amazon Managed Grafana mit Amazon Managed Service für Prometheus als Datenquelle erfolgreich eingerichtet haben, beginnen Sie mit der Erfassung von Metriken für Prometheus. Sie sollten dann die verschiedenen Dashboards mit Diagrammen, Informationen und mehr sehen. Die Open-Source-Software Grafana bietet verschiedene Dashboards, die Sie in Amazon Managed Grafana importieren können.
**So importieren Sie Open-Source-Dashboards von Grafana in Amazon Managed Grafana**
1. Wählen Sie auf der **Startseite** Ihres Workspaces von Amazon Managed Grafana die Option **Dashboards** aus.
1. Wählen Sie die Dropdown-Menüschaltfläche mit dem Benutzeroberflächen-Text **Neu** und dann **Importieren** aus.
1. Fügen Sie die URL in das [Slurm-Dashboard](https://grafana.com/grafana/dashboards/4323-slurm-dashboard/) ein.
```
https://grafana.com/grafana/dashboards/4323-slurm-dashboard/
```
1. Wählen Sie **Laden** aus.
1. Wiederholen Sie die vorherigen Schritte zum Importieren der folgenden Dashboards.
1. [Knoten-Exporter –vollständiges Dashboard](https://grafana.com/grafana/dashboards/1860-node-exporter-full/)
```
https://grafana.com/grafana/dashboards/1860-node-exporter-full/
```
1. [Exporter-Dashboard von NVIDIA DCGM](https://grafana.com/grafana/dashboards/12239-nvidia-dcgm-exporter-dashboard/)
```
https://grafana.com/grafana/dashboards/12239-nvidia-dcgm-exporter-dashboard/
```
1. [Dashboard von EFA-Metriken](https://grafana.com/grafana/dashboards/20579-efa-metrics-dev/)
```
https://grafana.com/grafana/dashboards/20579-efa-metrics-dev/
```
1. [FSx für das Lustre Metrics Dashboard](https://grafana.com/grafana/dashboards/20906-fsx-lustre/)
```
https://grafana.com/grafana/dashboards/20906-fsx-lustre/
```
# Referenz zu exportierten Metriken
Die folgenden Abschnitte enthalten umfassende Listen von Metriken, die SageMaker HyperPod nach erfolgreicher Konfiguration des CloudFormation Stacks für Observability aus Amazon Managed Service for SageMaker HyperPod Prometheus exportiert wurden. Sie können mit der Überwachung dieser in den Dashboards von Amazon Managed Grafana visualisierten Metriken beginnen.
## Slurm-Exporter-Dashboard
Stellt visualisierte Informationen zu Slurm-Clustern bereit. SageMaker HyperPod
**Arten von Metriken**
+ **Cluster-Übersicht:** Anzeige der Gesamtzahl der Knoten, Aufträgen und ihrer Status.
+ **Auftragsmetriken:** Visualisierung der Anzahl und des Status von Aufträgen im Zeitverlauf.
+ **Knotenmetriken:** Anzeige des Knotenstatus, der Zuweisung und der verfügbaren Ressourcen.
+ **Partitionsmetriken:** Überwachung partitionsspezifischer Metriken wie CPU-, Arbeitsspeicher- und GPU-Auslastung.
+ **Auftragseffizienz:** Berechnung der Auftragseffizienz auf der Grundlage der eingesetzten Ressourcen.
**Liste der Metriken**
| Metrikname | Description |
| --- | --- |
| slurm\$1job\$1count | Die Gesamtzahl der Aufträge im Slurm-Cluster |
| slurm\$1job\$1state\$1count | Anzahl der Aufträge in jedem Status (z. B. wird ausgeführt, ausstehend, abgeschlossen) |
| slurm\$1node\$1count | Die Gesamtzahl der Knoten im Slurm-Cluster |
| slurm\$1node\$1state\$1count | Anzahl der Knoten in jedem Status (z. B. inaktiv, alloc, mix) |
| slurm\$1partition\$1node\$1count | Anzahl der Knoten in jeder Partition |
| slurm\$1partition\$1job\$1count | Anzahl der Aufträge in jeder Partition |
| slurm\$1partition\$1alloc\$1cpus | Gesamtzahl der CPUs in jeder Partition zugewiesenen |
| slurm\$1partition\$1free\$1cpus | Gesamtzahl der CPUs in jeder Partition verfügbaren |
| slurm\$1partition\$1alloc\$1memory | Insgesamt zugewiesener Speicher in jeder Partition |
| slurm\$1partition\$1free\$1memory | Insgesamt verfügbarer Speicher in jeder Partition |
| slurm\$1partition\$1alloc\$1gpus | Gesamtzahl der GPUs in jeder Partition zugewiesenen |
| slurm\$1partition\$1free\$1gpus | Insgesamt GPUs in jeder Partition verfügbar |
## Knoten-Exporter-Dashboard
Stellt visualisierte Informationen zu Systemmetriken bereit, die vom [Prometheus-Knotenexporter von den Clusterknoten](https://github.com/prometheus/node_exporter) gesammelt wurden. HyperPod
**Arten von Metriken**
+ **Systemübersicht:** Anzeige der durchschnittlichen CPU-Last und der Speicherauslastung.
+ **Speichermetriken:** Visualisierung der Speicherauslastung, einschließlich Gesamtspeicher, freiem Speicher und Auslagerungsbereich.
+ **Festplattennutzung:** Überwachung der Festplattenauslastung und -verfügbarkeit.
+ **Netzwerkverkehr:** Anzeige der im Laufe der Zeit empfangenen und übertragenen Netzwerkbytes.
+ **Dateisystem-Metriken:** Analyse der Nutzung und Verfügbarkeit des Dateisystems.
+ ** I/O Festplatten-Metriken:** Visualisierung der Lese- und Schreibaktivitäten auf der Festplatte.
**Liste der Metriken**
Eine vollständige Liste der exportierten Metriken finden Sie in den Repositorys [Node Exporter](https://github.com/prometheus/node_exporter?tab=readme-ov-file#enabled-by-default) und [ GitHub procfs](https://github.com/prometheus/procfs?tab=readme-ov-file). Die folgende Tabelle zeigt einen Teil der Metriken, die Einblicke in die Nutzung der Systemressourcen wie CPU-Auslastung, Speicherverbrauch, Festplattenspeicher und Netzwerkaktivität geben.
| Metrikname | Description |
| --- | --- |
| node\$1load1 | Durchschnittliche Auslastung 1 Minute |
| node\$1load5 | Durchschnittliche Auslastung 5 Minuten |
| node\$1load15 | Durchschnittliche Auslastung 15 Minuten |
| node\$1memory\$1MemTotal | Gesamtsystemspeicher |
| node\$1memory\$1MemFree | Freier Systemspeicher |
| node\$1memory\$1MemAvailable | Verfügbarer Speicher für die Zuweisung zu Prozessen |
| node\$1memory\$1Buffers | Speicher, der vom Kernel für die Pufferung verwendet wird |
| node\$1memory\$1Cached | Speicher, der vom Kernel für das Zwischenspeichern von Dateisystemdaten verwendet wird |
| node\$1memory\$1SwapTotal | Verfügbarer Auslagerungsbereich |
| node\$1memory\$1SwapFree | Kostenloser Auslagerungsbereich |
| node\$1memory\$1SwapCached | Einmal ausgelagerter Speicher wird wieder eingelagert, befindet sich aber weiterhin im Swap |
| node\$1filesystem\$1avail\$1bytes | Verfügbarer Festplattenspeicher in Byte |
| node\$1filesystem\$1size\$1bytes | Gesamter Festplattenspeicher in Byte |
| node\$1filesystem\$1free\$1bytes | Freier Festplattenspeicher in Byte |
| node\$1network\$1receive\$1bytes | Empfangene Netzwerk-Byte |
| node\$1network\$1transmit\$1bytes | Übertragene Netzwerk-Byte |
| node\$1disk\$1read\$1bytes | Gelesene Festplatten-Byte |
| node\$1disk\$1written\$1bytes | Geschriebene Festplatten-Byte |
## Exporter-Dashboard von NVIDIA DCGM
Bietet visualisierte Informationen zu NVIDIA-GPU-Metriken, die vom [NVIDIA-DCGM-Exporter](https://github.com/NVIDIA/dcgm-exporter) erfasst wurden.
**Arten von Metriken**
+ **GPU-Übersicht:** Anzeige der GPU-Auslastung, der Temperaturen, des Stromverbrauchs und der Speicherauslastung.
+ **Temperaturmetriken:** Visualisierung der GPU-Temperaturen im Zeitverlauf.
+ **Stromverbrauch:** Überwachung des GPU-Stromverbrauchs und der Trends beim Stromverbrauch.
+ **Speicherauslastung:** Analyse der GPU-Speichernutzung, einschließlich belegtem, freiem Speicher und Gesamtspeicher.
+ **Lüftergeschwindigkeit:** Anzeige der Geschwindigkeiten und Variationen der GPU-Lüfter.
+ **ECC-Fehler:** Verfolgung von ECC-Fehlern und ausstehenden Fehlern im GPU-Speicher.
**Liste der Metriken**
Die folgende Tabelle enthält eine Liste der Metriken, die Einblicke in den Zustand und die Leistung der NVIDIA-GPU bieten, darunter Taktfrequenzen, Temperaturen, Stromverbrauch, Speicherauslastung, Lüftergeschwindigkeiten und Fehlermetriken.
| Metrikname | Description |
| --- | --- |
| DCGM\$1FI\$1DEV\$1SM\$1CLOCK | SM-Taktfrequenz (in MHz) |
| DCGM\$1FI\$1DEV\$1MEM\$1CLOCK | Speichertaktfrequenz (in MHz) |
| DCGM\$1FI\$1DEV\$1MEMORY\$1TEMP | Speichertemperatur (in C) |
| DCGM\$1FI\$1DEV\$1GPU\$1TEMP | GPU-Temperatur (in C) |
| DCGM\$1FI\$1DEV\$1POWER\$1USAGE | Leistungsaufnahme (in W) |
| DCGM\$1FI\$1DEV\$1TOTAL\$1ENERGY\$1CONSUMPTION | Gesamtenergieverbrauch seit dem Start (in mJ) |
| DCGM\$1FI\$1DEV\$1PCIE\$1REPLAY\$1COUNTER | Gesamtzahl der PCIe Wiederholungen |
| DCGM\$1FI\$1DEV\$1MEM\$1COPY\$1UTIL | Speichernutzung (in %) |
| DCGM\$1FI\$1DEV\$1ENC\$1UTIL | Encoder-Nutzung (in%) |
| DCGM\$1FI\$1DEV\$1DEC\$1UTIL | Decoder-Nutzung (in%) |
| DCGM\$1FI\$1DEV\$1XID\$1ERRORS | Wert des letzten aufgetretenen XID-Fehlers |
| DCGM\$1FI\$1DEV\$1FB\$1FREE | Freier Frame-Pufferspeicher (in MiB) |
| DCGM\$1FI\$1DEV\$1FB\$1USED | Verwendeter Frame-Pufferspeicher (in MiB) |
| DCGM\$1FI\$1DEV\$1NVLINK\$1BANDWIDTH\$1TOTAL | Gesamtzahl der NVLink Bandbreitenzähler für alle Lanes |
| DCGM\$1FI\$1DEV\$1VGPU\$1LICENSE\$1STATUS | Status der vGPU-Lizenz |
| DCGM\$1FI\$1DEV\$1UNCORRECTABLE\$1REMAPPED\$1ROWS | Anzahl der neu zugewiesenen Zeilen für nicht behebbare Fehler |
| DCGM\$1FI\$1DEV\$1CORRECTABLE\$1REMAPPED\$1ROWS | Anzahl der neu zugewiesenen Zeilen für behebbare Fehler |
| DCGM\$1FI\$1DEV\$1ROW\$1REMAP\$1FAILURE | Ob die Neuzuweisung von Zeilen fehlgeschlagen ist |
## Dashboard für EFA-Metriken
Stellt visualisierte Informationen zu den Metriken von [Amazon Elastic Fabric Adapter (EFA)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa.html) bereit, die auf P-Instances installiert sind und vom [EFA-Knoten-Exporter](https://github.com/aws-samples/awsome-distributed-training/blob/main/4.validation_and_observability/3.efa-node-exporter/README.md) erfasst wurden.
**Arten von Metriken**
+ **EFA-Fehlermetriken:** Visualisierung von Fehlern wie Zuweisungsfehler, Befehlsfehler und Speicherzuordnungsfehler.
+ **EFA-Netzwerkverkehr:** Überwachung empfangener und übertragener Byte, Pakete und Arbeitsanfragen.
+ **EFA-RDMA-Leistung:** Analyse von RDMA-Lese- und Schreibvorgängen, einschließlich übertragener Byte und Fehlerraten.
+ **Lebensdauer von EFA-Ports:** Anzeige der Lebensdauer von EFA-Ports im Zeitverlauf.
+ **EFA-Keep-Alive-Pakete:** Verfolgung der Anzahl der empfangenen Keep-Alive-Pakete.
**Liste der Metriken**
Die folgende Tabelle enthält eine Liste der Metriken, die Einblicke in verschiedene Aspekte des EFA-Betriebs bieten, darunter Fehler, ausgeführte Befehle, Netzwerkverkehr und Ressourcenauslastung.
| Metrikname | Description |
| --- | --- |
| node\$1amazonefa\$1info | Nicht numerische Daten von/sys/class/infiniband/, Wert ist immer 1. |
| node\$1amazonefa\$1lifespan | Lebensdauer des Ports |
| node\$1amazonefa\$1rdma\$1read\$1bytes | Anzahl der mit RDMA gelesenen Byte |
| node\$1amazonefa\$1rdma\$1read\$1resp\$1bytes | Anzahl der mit RDMA gelesenen Antwort-Byte |
| node\$1amazonefa\$1rdma\$1read\$1wr\$1err | Anzahl der Lese- und Schreibfehler mit RDMA |
| node\$1amazonefa\$1rdma\$1read\$1wrs | Anzahl der mit RDMA gelesenen rs |
| node\$1amazonefa\$1rdma\$1write\$1bytes | Anzahl der mit RDMA geschriebenen Byte |
| node\$1amazonefa\$1rdma\$1write\$1recv\$1bytes | Anzahl der mit RDMA geschriebenen und empfangenen Byte |
| node\$1amazonefa\$1rdma\$1write\$1wr\$1err | Anzahl der mit Fehler geschriebenen Byte RDMA |
| node\$1amazonefa\$1rdma\$1write\$1wrs | Anzahl der geschriebenen Byte wrs RDMA |
| node\$1amazonefa\$1recv\$1bytes | Anzahl der empfangenen Bytes |
| node\$1amazonefa\$1recv\$1wrs | Anzahl der empfangenen Bytes wrs |
| node\$1amazonefa\$1rx\$1bytes | Anzahl der empfangenen Bytes |
| node\$1amazonefa\$1rx\$1drops | Anzahl der verworfenen Pakete |
| node\$1amazonefa\$1rx\$1pkts | Anzahl der empfangenen Pakete |
| node\$1amazonefa\$1send\$1bytes | Anzahl der gesendeten Byte |
| node\$1amazonefa\$1send\$1wrs | Anzahl der gesendeten wrs |
| node\$1amazonefa\$1tx\$1bytes | Anzahl der übertragenen Bytes |
| node\$1amazonefa\$1tx\$1pkts | Anzahl der übertragenen Pakete |
## FSx für das Lustre-Metrik-Dashboard
[Bietet visualisierte Informationen zu den [von Amazon FSx für das Lustre-Dateisystem gesammelten Metriken](https://docs.aws.amazon.com/fsx/latest/LustreGuide/monitoring-cloudwatch.html). CloudWatch](https://docs.aws.amazon.com/fsx/latest/LustreGuide/monitoring-cloudwatch.html)
**Anmerkung**
Das Grafana FSx for Lustre-Dashboard verwendet Amazon CloudWatch als Datenquelle, was sich von den anderen Dashboards unterscheidet, die Sie für die Verwendung von Amazon Managed Service für Prometheus konfiguriert haben. Um eine genaue Überwachung und Visualisierung von Metriken zu gewährleisten, die sich auf Ihr FSx for Lustre-Dateisystem beziehen, konfigurieren Sie das FSx for Lustre-Dashboard so, dass Amazon CloudWatch als Datenquelle verwendet wird, und geben Sie an, AWS-Region wo Ihr FSx for Lustre-Dateisystem bereitgestellt wird.
**Arten von Metriken**
+ **DataReadBytes:** Die Anzahl der Byte für Lesevorgänge im Dateisystem.
+ **DataWriteBytes:** Die Anzahl der Byte für Schreiboperationen im Dateisystem.
+ **DataReadOperations:** Die Anzahl der Lesevorgänge.
+ **DataWriteOperations:** Die Anzahl der Schreiboperationen.
+ **MetadataOperations:** Die Anzahl der Metadatenoperationen.
+ **FreeDataStorageCapacity:** Die Menge der verfügbaren Speicherkapazität.
# Amazon SageMaker HyperPod Slurm-Metriken
Amazon SageMaker HyperPod bietet eine Reihe von CloudWatch Amazon-Metriken, mit denen Sie den Zustand und die Leistung Ihrer HyperPod Cluster überwachen können. Diese Metriken werden vom Slurm-Workload-Manager erfasst, der auf Ihren HyperPod Clustern ausgeführt wird, und sind im `/aws/sagemaker/Clusters` CloudWatch Namespace verfügbar.
## Metriken auf Clusterebene
Die folgenden Metriken auf Clusterebene sind verfügbar für. HyperPod Diese Metriken verwenden die `ClusterId` Dimension, um den spezifischen HyperPod Cluster zu identifizieren.
| CloudWatch Name der Metrik | Hinweise | Metrikname „Amazon EKS Container Insights“ |
| --- | --- | --- |
| cluster\$1node\$1count | Gesamtzahl der Knoten im Cluster | cluster\$1node\$1count |
| cluster\$1idle\$1node\$1count | Anzahl der inaktiven Knoten im Cluster | – |
| cluster\$1failed\$1node\$1count | Anzahl der ausgefallenen Knoten im Cluster | cluster\$1failed\$1node\$1count |
| cluster\$1cpu\$1count | Gesamtzahl der CPU-Kerne im Cluster | node\$1cpu\$1limit |
| cluster\$1idle\$1cpu\$1count | Anzahl der CPU-Kerne im Cluster | – |
| cluster\$1gpu\$1count | Summe GPUs im Cluster | node\$1gpu\$1limit |
| cluster\$1idle\$1gpu\$1count | Anzahl der inaktiven GPUs Benutzer im Cluster | – |
| cluster\$1running\$1task\$1count | Gesamtzahl der laufenden Slurm-Aufträge im Cluster | – |
| cluster\$1pending\$1task\$1count | Gesamtzahl der ausstehenden Slurm-Aufträge im Cluster | – |
| cluster\$1preempted\$1task\$1count | Gesamtzahl der unterbrochenen Slurm-Aufträge im Cluster | – |
| cluster\$1avg\$1task\$1wait\$1time | Durchschnittliche Wartezeit für Slurm-Aufträge im Cluster | – |
| cluster\$1max\$1task\$1wait\$1time | Maximale Wartezeit für Slurm-Aufträge im Cluster | – |
## Metriken auf Instance-Ebene
Die folgenden Metriken auf Instanzebene sind verfügbar für. HyperPod Diese Metriken verwenden die `ClusterId` Dimension auch, um den spezifischen HyperPod Cluster zu identifizieren.
| CloudWatch Name der Metrik | Hinweise | Metrikname „Amazon EKS Container Insights“ |
| --- | --- | --- |
| node\$1gpu\$1utilization | Durchschnittliche GPU-Auslastung über alle Instances | node\$1gpu\$1utilization |
| node\$1gpu\$1memory\$1utilization | Durchschnittliche GPU-Speicherauslastung über alle Instances | node\$1gpu\$1memory\$1utilization |
| node\$1cpu\$1utilization | Durchschnittliche CPU-Auslastung über alle Instances hinweg | node\$1cpu\$1utilization |
| node\$1memory\$1utilization | Durchschnittliche Speicherauslastung über alle Instances hinweg | node\$1memory\$1utilization |
# SageMaker HyperPod Cluster-Resilienz
SageMaker HyperPod durch Slurm-Orchestrierung werden die folgenden Funktionen zur Cluster-Resilienz bereitgestellt.
**Topics**
+ [Beauftragter für Gesundheitsüberwachung](sagemaker-hyperpod-resiliency-slurm-cluster-health-check.md)
+ [Automatische Knotenwiederherstellung und automatische Wiederaufnahme](sagemaker-hyperpod-resiliency-slurm-auto-resume.md)
+ [Ersetzen Sie einen Knoten manuell mit Slurm oder starten Sie ihn neu](sagemaker-hyperpod-resiliency-slurm-replace-faulty-instance.md)
# Beauftragter für Gesundheitsüberwachung
In diesem Abschnitt werden die Integritätsprüfungen beschrieben, mit denen SageMaker HyperPod der Zustand der Cluster-Instance regelmäßig auf Probleme mit Geräten wie Beschleunigern (GPU- und Trainium-Kerne) und Netzwerken (EFA) überwacht wird. SageMaker HyperPod Der Health Monitoring Agent (HMA) überwacht kontinuierlich den Integritätsstatus jeder GPU-basierten oder Trainium-basierten Instanz. Wenn er Instance- oder GPU-Ausfälle erkennt, markiert der Agent die Instance als fehlerhaft.
SageMaker HyperPod HMA führt dieselben Integritätsprüfungen für EKS- und Slurm-Orchestratoren durch. Weitere Informationen zu HMA finden Sie unter. [System zur Gesundheitsüberwachung](sagemaker-hyperpod-eks-resiliency-health-monitoring-agent.md)
# Automatische Knotenwiederherstellung und automatische Wiederaufnahme
**Anmerkung**
Seit dem 11. September 2025 unterstützt die Orchestrierung HyperPod mit Slurm nun Agenten zur Gesundheitsüberwachung. Führen Sie das AMI aus [UpdateClusterSoftware](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_UpdateClusterSoftware.html)und aktualisieren Sie es auf die neueste Version, um diese Funktionalität nutzen zu können.
In diesem Abschnitt werden die beiden sich ergänzenden Resilienzfunktionen SageMaker HyperPod von Amazon behandelt: die automatische Wiederherstellung von Knoten, die fehlerhafte Infrastruktur ohne manuelles Eingreifen ersetzt, und die Funktion zur automatischen Wiederaufnahme, mit der Trainingsjobs nach Hardwareausfällen vom letzten Checkpoint aus neu gestartet werden.
## So funktioniert die automatische Wiederherstellung von Knoten
Während der Clustererstellung oder -aktualisierung können Clusteradministratoren die Wiederherstellungsoption für Knoten (Instance) zwischen `Automatic` (empfohlen) und `None` auf Clusterebene wählen. Wenn diese Option auf gesetzt `Automatic` ist, SageMaker HyperPod werden fehlerhafte Knoten automatisch neu gestartet oder ersetzt.
**Wichtig**
Wir empfehlen, die Option `Automatic` einzustellen. Standardmäßig sind die Cluster mit automatischer Knotenwiederherstellung eingerichtet.
Die automatische Knotenwiederherstellung wird ausgeführt, wenn Probleme beim Health Monitoring Agent, bei grundlegenden Zustandsprüfungen und bei umfassenden Integritätsprüfungen festgestellt werden. Wenn diese Option auf gesetzt ist`None`, kennzeichnet der Health Monitoring Agent die Instances, wenn ein Fehler erkannt wird, leitet aber nicht automatisch Reparatur- oder Wiederherstellungsaktionen an den betroffenen Knoten ein. Wir empfehlen diese Option nicht.
## Einen Trainingsjob mit der SageMaker HyperPod Amazon-Funktion zur automatischen Wiederaufnahme ausführen
In diesem Abschnitt wird beschrieben, wie Sie einen Trainingsjob mit der Funktion zur SageMaker HyperPod automatischen Wiederaufnahme ausführen, die eine Zero-Touch-Resilienz-Infrastruktur bietet, mit der ein Trainingsjob bei einem Hardwarefehler automatisch vom zuletzt gespeicherten Checkpoint wiederhergestellt werden kann.
Wenn mit der Funktion zur automatischen Wiederaufnahme ein Job aufgrund eines Hardwarefehlers oder vorübergehender Probleme zwischen den Schulungen fehlschlägt, startet die SageMaker HyperPod automatische Wiederaufnahme den Knotenaustausch-Workflow und startet den Job neu, nachdem die fehlerhaften Knoten ersetzt wurden. Die folgenden Hardwareprüfungen werden immer dann ausgeführt, wenn ein Job bei Verwendung der automatischen Wiederaufnahme fehlschlägt:
| Kategorie | Name des Dienstprogramms | Kompatibilität von Instance-Typen | Description |
| --- | --- | --- | --- |
| Accelerator | NVIDIA SMI | GPU | Das [nvidia-smi](https://developer.nvidia.com/nvidia-system-management-interface) Utility ist eine bekannte CLI zur Verwaltung und Überwachung. GPUs Die integrierte Zustandsprüfung analysiert die Ausgabe von nvidia-smi, um den Zustand der Instance zu ermitteln. |
| Accelerator | Neuron sysfs | Trainium | Bei Trainium-basierten Instances wird der Zustand der Neuron-Geräte durch Auslesen der Zähler aus [Neuron sysfs](https://awsdocs-neuron.readthedocs-hosted.com/en/latest/tools/neuron-sys-tools/neuron-sysfs-user-guide.html) ermittelt, die direkt vom Neuron-Treiber übertragen werden. |
| Netzwerk | EFA | GPU und Trainium | Um die Diagnose von Elastic Fabric Adapter (EFA)-Geräten zu unterstützen, führt die EFA-Zustandsprüfung eine Reihe von Verbindungstests mit allen verfügbaren EFA-Karten innerhalb der Instance durch. |
**Anmerkung**
Wenn [Generic Resources (GRES)](https://slurm.schedmd.com/gres.html) an einen Slurm-Knoten angefügt sind, lässt Slurm in der Regel keine Änderungen an der Knotenzuweisung zu, wie z. B. das Ersetzen von Knoten, und erlaubt daher auch nicht die Wiederaufnahme eines fehlgeschlagenen Jobs. Sofern nicht ausdrücklich verboten, setzt die Funktion zur HyperPod automatischen Wiederaufnahme automatisch alle fehlerhaften Jobs, die mit den GRES-fähigen Knoten verknüpft sind, erneut in die Warteschlange. Dieser Vorgang umfasst das Anhalten des Jobs, das Zurücksetzen in die Job-Warteschlange und das anschließende Neustarten des Jobs von Anfang an.
**Verwendung der SageMaker HyperPod Auto-Resume-Funktion mit Slurm**
Wenn Sie die SageMaker HyperPod automatische Wiederaufnahme mit Slurm verwenden, sollten Sie den Job innerhalb einer exklusiven Zuordnung ausführen, die Sie entweder mit `salloc` oder erhalten haben. `sbatch` In jedem Fall müssen Sie das Einstiegspunktskript ändern, um sicherzustellen, dass alle Einrichtungsschritte bei der Wiederaufnahme des Jobs in einem einzigen `srun`-Befehl ausgeführt werden. Über das Eintrittspunktskript ist es wichtig, die Umgebung auf dem ersetzten Knoten so einzurichten, dass sie mit der Umgebung übereinstimmt, in der der Jobschritt vor seiner Unterbrechung ausgeführt wurde. Das folgende Verfahren zeigt, wie Sie ein Entrypoint-Skript vorbereiten, um die Umgebung konsistent zu halten und es als einen einzigen Befehl auszuführen. `srun`
**Tipp**
Wenn Sie `sbatch` verwenden, können Sie das Batch-Skript einfach halten, indem Sie ein separates Skript zum Einrichten der Umgebung erstellen und einen einzigen `srun`-Befehl verwenden.
1. Erstellen Sie mithilfe des folgenden Codebeispiels ein Skript und speichern Sie es unter `train_auto_resume.sh`. Dieses Skript stellt Trainingsumgebungen bereit, wobei davon ausgegangen wird, dass zuvor keine manuelle Konfiguration für den ersetzten Knoten vorgenommen wurde. Dadurch wird sichergestellt, dass die Umgebung knotenunabhängig ist, sodass beim Austausch eines Knotens dieselbe Umgebung auf dem Knoten bereitgestellt wird, bevor der Job wieder aufgenommen wird.
**Anmerkung**
Im folgenden Codebeispiel sehen Sie, wie Sie die Slurm-Knotenliste ermitteln, die dem Job zugeordnet ist. Verwenden Sie nicht die von Slurm bereitgestellte `$SLURM_JOB_NODELIST` Umgebungsvariable, da ihr Wert nach der SageMaker HyperPod automatischen Wiederaufnahme des Jobs veraltet sein könnte. Das folgende Codebeispiel zeigt, wie Sie eine neue `NODE_LIST`-Variable definieren, um `SLURM_JOB_NODELIST` zu ersetzen, und dann die Variablen `MASTER_NODE` und `MASTER_ADDR` außerhalb der `NODE_LIST`-Variablen einrichten.
```
#!/bin/bash
# Filename: train_auto_resume.sh
# Sample containerized script to launch a training job with a single srun which can be auto-resumed.
# Place your training environment setup here.
# Example: Install conda, docker, activate virtual env, etc.
# Get the list of nodes for a given job
NODE_LIST=$(scontrol show jobid=$SLURM_JOBID | \ # Show details of the SLURM job
awk -F= '/NodeList=/{print $2}' | \ # Extract NodeList field
grep -v Exc) # Exclude nodes marked as excluded
# Determine the master node from the node list
MASTER_NODE=$(scontrol show hostname $NODE_LIST | \ # Convert node list to hostnames
head -n 1) # Select the first hostname as master node
# Get the master node address
MASTER_ADDR=$(scontrol show node=$MASTER_NODE | \ # Show node information
awk -F= '/NodeAddr=/{print $2}' | \ # Extract NodeAddr
awk '{print $1}') # Print the first part of NodeAddr
# Torchrun command to launch the training job
torchrun_cmd="torchrun --nnodes=$SLURM_NNODES \
--nproc_per_node=1 \
--node_rank=$SLURM_NODE \
--master-addr=$MASTER_ADDR \
--master_port=1234 \
"
# Execute the torchrun command in the 'pytorch' Conda environment,
# streaming output live
/opt/conda/bin/conda run --live-stream -n pytorch $torchrun_cmd
```
**Tipp**
Sie können das vorherige Skript verwenden, um weitere Befehle für die Installation zusätzlicher Abhängigkeiten für Ihren Job hinzuzufügen. Wir empfehlen jedoch, die Skripte zur Installation von Abhängigkeiten in dem [Satz von Lebenszyklusskripten](sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-base-config.md) zu belassen, die bei der Clustererstellung verwendet werden. Wenn Sie eine virtuelle Umgebung verwenden, die in einem gemeinsam genutzten Verzeichnis gehostet wird, können Sie dieses Skript auch zum Aktivieren der virtuellen Umgebung verwenden.
1. Starten Sie den Job mit aktivierter SageMaker HyperPod automatischer Wiederaufnahme, indem Sie das Kennzeichen `--auto-resume=1` hinzufügen, das angibt, dass der `srun` Befehl bei einem Hardwarefehler automatisch wiederholt werden soll.
**Anmerkung**
Wenn Sie mit `sbatch` oder `salloc` eine Ressourcenzuweisung eingerichtet haben, können Sie innerhalb der Zuordnung mehrere `srun`-Befehle ausführen. Im Falle eines Fehlers funktioniert die Funktion zur SageMaker HyperPod automatischen Wiederaufnahme nur im aktuellen [Jobschritt](https://slurm.schedmd.com/job_launch.html#step_allocation) des `srun` Befehls mit der Markierung`--auto-resume=1`. Mit anderen Worten, die Aktivierung der automatischen Wiederaufnahme in einem `srun`-Befehl gilt nicht für andere `srun`-Befehle, die innerhalb einer Ressourcenzuweisungssitzung gestartet werden.
Im Folgenden finden Sie einige Beispiele für `srun`-Befehle mit `auto-resume` aktiviert.
**Verwenden von sbatch**
Da der Großteil der Logik zum Einrichten der Umgebung bereits in `train_auto_resume.sh` vorhanden ist, sollte das Batch-Skript einfach sein und dem folgenden Codebeispiel ähneln. Gehen Sie davon aus, dass das folgende Batch-Skript unter `batch.sh` gespeichert ist.
```
#!/bin/bash
#SBATCH --nodes 2
#SBATCH --exclusive
srun --auto-resume=1 train_auto_resume.sh
```
Führen Sie das vorstehende Batch-Skript mit dem folgenden Befehl aus.
```
sbatch batch.sh
```
**Verwenden von salloc**
Beginnen Sie mit dem Erwerb einer exklusiven Zuweisung und führen Sie den `srun`-Befehl mit dem Flag `--auto-resume` und dem Einstiegspunktskript aus.
```
salloc -N 2 --exclusive
srun --auto-resume=1 train_auto_resume.sh
```
## So arbeiten automatische Node Recovery und Auto-Resume zusammen
Wenn sowohl automatische Node-Recovery- als auch Auto-Resume-Systeme aktiv sind, verfolgen sie einen koordinierten Ansatz zur Behandlung von Ausfällen. Wenn das HMA einen Hardwarefehler feststellt, wird der Knoten unabhängig vom Status auf Jobebene als leer markiert. Wenn die automatische Wiederherstellung des Knotens aktiviert ist, werden die Knoten automatisch ersetzt, sobald alle auf den Knoten ausgeführten Jobs beendet sind. In diesem Szenario wird bei Jobs mit aktivierter automatischer Wiederaufnahme ein Exit-Status ungleich Null in dem Schritt aktiviert (die Jobs werden fortgesetzt, sobald die Knoten ersetzt wurden). Jobs, bei denen die automatische Wiederaufnahme nicht aktiviert ist, werden einfach beendet und erfordern eine manuelle erneute Einreichung durch Administratoren oder Benutzer.
**Anmerkung**
Wenn Sie die automatische Wiederaufnahme verwenden, werden die Knoten immer ersetzt (keine Neustarts), wenn Hardwarefehler erkannt werden.
# Ersetzen Sie einen Knoten manuell mit Slurm oder starten Sie ihn neu
In diesem Abschnitt geht es darum, wann Sie einen Knoten manuell neu starten oder ersetzen sollten, und es gibt Anleitungen, wie Sie beides tun können.
## Wann muss ein Knoten manuell neu gestartet oder ersetzt werden
Die HyperPod Auto-Resume-Funktion überwacht, ob der Status Ihrer Slurm-Knoten auf `fail` oder wechselt. `down` Sie können den Status der Slurm-Knoten überprüfen, indem Sie `sinfo` ausführen.
Wenn ein Knoten feststeckt oder nicht reagiert und der automatische Wiederaufnahmeprozess ihn nicht wiederherstellt, können Sie die Wiederherstellung manuell einleiten. Die Wahl zwischen dem Neustart und dem Ersetzen eines Knotens hängt von der Art des Problems ab. Ziehen Sie einen Neustart in Betracht, wenn temporäre oder softwarebezogene Probleme auftreten, wie z. B. Systemabstürze, Speicherlecks, Probleme mit GPU-Treibern, Kernel-Updates oder abgestürzte Prozesse. Wenn Sie jedoch auf anhaltende oder hardwarebezogene Probleme wie Ausfälle GPUs, Speicher- oder Netzwerkfehler, wiederholte Fehler bei der Integritätsprüfung oder Knoten stoßen, die nach mehreren Neustartversuchen nicht mehr reagieren, ist der Austausch von Knoten die geeignetere Lösung.
## Möglichkeiten, Knoten manuell neu zu starten oder zu ersetzen
SageMaker HyperPod bietet zwei Methoden für die manuelle Wiederherstellung von Knoten. Der bevorzugte Ansatz ist die Verwendung von SageMaker HyperPod Reboot and Replace APIs, das einen schnelleren und transparenteren Wiederherstellungsprozess ermöglicht, der für alle Orchestratoren funktioniert. Alternativ können Sie herkömmliche Slurm-Befehle wie verwenden`scontrol update`, obwohl diese ältere Methode direkten Zugriff auf den Controller-Knoten des Slurms erfordert. Beide Methoden aktivieren dieselben SageMaker HyperPod Wiederherstellungsprozesse.
## Starten Sie einen Knoten mithilfe der Reboot-API manuell neu
Sie können den verwenden **BatchRebootClusterNodes**, um einen fehlerhaften Knoten in Ihrem SageMaker HyperPod Cluster manuell neu zu starten.
Hier ist ein Beispiel für die Ausführung des Neustartvorgangs auf zwei Instanzen eines Clusters mithilfe von 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
```
## Manuelles Ersetzen eines Knotens mithilfe der Replace-API
Sie können den verwenden **BatchReplaceClusterNodes**, um einen fehlerhaften Knoten in Ihrem SageMaker HyperPod Cluster manuell zu ersetzen.
Hier ist ein Beispiel für die Ausführung des Ersetzungsvorgangs auf zwei Instanzen eines Clusters mithilfe von 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
```
## Starten Sie einen Knoten manuell mit Slurm neu
Sie können auch die Slurm-Befehle von scontrol verwenden, um die Wiederherstellung des Knotens auszulösen. Diese Befehle interagieren direkt mit der Slurm-Steuerebene und rufen dieselben zugrunde liegenden Wiederherstellungsmechanismen auf. SageMaker HyperPod
Ersetzen Sie den Befehl im folgenden Befehl durch den Slurm-Knotennamen (Hostnamen) der fehlerhaften Instanz, die Sie neu starten möchten.
```
scontrol update node= state=fail reason="Action:Reboot"
```
Dadurch wird der Knoten mit dem angegebenen Grund als FAIL markiert. SageMaker HyperPod erkennt dies und startet die Instanz neu. Vermeiden Sie es, während des Vorgangs den Knotenstatus zu ändern oder den Slurm-Controller neu zu starten.
## Ersetzen Sie einen Knoten manuell mithilfe von Slurm
Sie können den Befehl scontrol update wie folgt verwenden, um einen Knoten zu ersetzen.
Ersetzen Sie den Befehl im folgenden Befehl `` durch den Slurm-Knotennamen (Hostnamen) der fehlerhaften Instanz, die Sie ersetzen möchten.
```
scontrol update node= state=fail reason="Action:Replace"
```
Nach der Ausführung dieses Befehls wechselt der Knoten in den `fail` Status, wartet, bis die aktuell ausgeführten Jobs abgeschlossen sind, wird durch eine fehlerfreie Instanz ersetzt und mit demselben Hostnamen wiederhergestellt. Dieser Vorgang benötigt Zeit, abhängig von den verfügbaren Instances in Ihrer Availability Zone und der Zeit, die für die Ausführung Ihrer Lebenszyklusskripts benötigt wird. Vermeiden Sie es während des Aktualisierungs- und Austauschvorgangs, den Status des Knotens erneut manuell zu ändern oder den Slurm-Controller neu zu starten, da dies dazu führen kann, dass der Austausch fehlschlägt. Wenn der Knoten nicht wiederhergestellt wird oder nach langer Zeit nicht in den Status `idle` wechselt, wenden Sie sich an den [AWS -Support](https://console.aws.amazon.com/support/).
## Manuell die Änderung eines Knotens erzwingen
Wenn der fehlerhafte Knoten kontinuierlich in diesem Zustand verharrt, besteht als letzte Möglichkeit darin, den Knotenstatus manuell auf `fail` zu ändern. Dies erfordert Administratorrechte (Sudo-Berechtigungen).
**Warnung**
Gehen Sie vorsichtig vor, bevor Sie den folgenden Befehl ausführen, da dadurch alle Aufträge beendet werden und Sie möglicherweise alle nicht gespeicherten Arbeiten verlieren.
```
scontrol update node= state=down reason="Action:Replace"
```
# Kontinuierliche Bereitstellung für erweiterte Clusteroperationen mit Slurm
SageMaker HyperPod Amazon-Cluster, die mit Slurm-Orchestrierung erstellt wurden, unterstützen jetzt Continuous Provisioning, eine Funktion, die mehr Flexibilität und Effizienz bei der Ausführung großer Workloads ermöglicht. AI/ML Durch die kontinuierliche Bereitstellung können Sie schnell mit dem Training beginnen, nahtlos skalieren, Wartungsarbeiten ohne Betriebsunterbrechung durchführen und einen detaillierten Einblick in den Clusterbetrieb erhalten.
**Anmerkung**
Continuous Provisioning ist als optionale Konfiguration für neue HyperPod Cluster verfügbar, die mit Slurm-Orchestrierung erstellt wurden. Bestehende Cluster, die das vorherige Skalierungsmodell verwenden, können derzeit nicht auf Continuous Provisioning migriert werden.
## Funktionsweise
Das Continuous Provisioning System führt eine Architektur mit gewünschtem Status ein, die das herkömmliche Skalierungsmodell ersetzt. all-or-nothing Wenn beim vorherigen Modell eine Instanzgruppe nicht vollständig bereitgestellt werden konnte, schlug der gesamte Vorgang zur Clustererstellung oder -aktualisierung fehl und wurde zurückgesetzt. Bei kontinuierlicher Bereitstellung akzeptiert das System Teilkapazität und stellt die verbleibenden Instanzen weiterhin asynchron bereit.
Das System zur kontinuierlichen Bereitstellung:
+ **Akzeptiert die Anfrage**: Zeichnet die Anzahl der Zielinstanzen für jede Instanzgruppe auf.
+ **Initiiert die Bereitstellung**: Beginnt mit dem parallel Start von Instanzen für alle Instanzgruppen.
+ **Stellt zuerst Prioritätsknoten** bereit: Der Cluster wechselt zu, `InService` nachdem mindestens ein Controller-Knoten (und ein Login-Node, falls eine Login-Instanzgruppe angegeben wurde) erfolgreich bereitgestellt wurde.
+ **Verfolgt den Fortschritt**: Überwacht jeden Instance-Startversuch und zeichnet den Status auf.
+ **Behandelt Fehler**: Wiederholt automatisch asynchron fehlgeschlagene Starts für Worker-Knoten.
Die kontinuierliche Bereitstellung ist standardmäßig deaktiviert. Um diese Funktion zu verwenden, stellen Sie `Continuous` in Ihrer `NodeProvisioningMode` `CreateCluster` Anfrage auf ein.
Wenn Continuous Provisioning aktiviert ist, können Sie mehrere Skalierungsvorgänge gleichzeitig initiieren, ohne auf den Abschluss früherer Operationen warten zu müssen. Auf diese Weise können Sie verschiedene Instance-Gruppen im selben Cluster gleichzeitig skalieren und mehrere Skalierungsanforderungen an dieselbe Instance-Gruppe senden.
## Prioritätsbasierte Bereitstellung
Slurm-Cluster erfordern, dass ein Controller-Knoten betriebsbereit ist, bevor sich Worker-Knoten registrieren und Jobs annehmen können. Continuous Provisioning erledigt dies automatisch durch prioritätsbasiertes Provisioning:
1. Die Controller-Instanzgruppe wird zuerst bereitgestellt.
1. Sobald ein Controller-Knoten fehlerfrei ist, beginnen Anmelde- und Worker-Knoten parallel mit der Bereitstellung.
1. Der Cluster wechselt zu dem `InService` Zeitpunkt, zu dem ein Controller-Knoten und ein Login-Node aktiv sind (sofern eine Login-Instanzgruppe angegeben ist). Wenn keine Login-Instanzgruppe angegeben ist, wechselt der Cluster zu, `InService` sobald der Controller-Knoten bereitgestellt ist.
1. Worker-Knoten, die aufgrund von Kapazitätsbeschränkungen nicht sofort bereitgestellt werden können, treten in eine asynchrone Wiederholungsschleife ein und werden dem Slurm-Cluster automatisch hinzugefügt, sobald sie verfügbar sind.
## Behandlung von Controller-Fehlern
Wenn der Controller-Knoten bei der Clustererstellung die Bereitstellung fehlschlägt, hängt das Verhalten davon ab, ob der Fehler erneut versucht werden kann oder nicht.
Fehler**, die wiederholt werden können (z. B. fehlerhafte** Instanzen oder vorübergehende Ausfälle):
+ HyperPod ersetzt kontinuierlich die Instanz und versucht erneut, sie bereitzustellen, bis der Controller wieder verfügbar ist.
+ Worker- und Login-Knoten, die bereits bereitgestellt wurden, bleiben verfügbar, aber der Cluster wechselt `InService` erst, wenn der Controller fehlerfrei ist.
**Fehler, die nicht wiederholt werden können** (z. B. keine verfügbare Kapazität für den Controller-Instanztyp oder Fehler im Lifecycle-Skript):
+ Der Cluster ist markiert als. `Failed`
+ Sie werden über die Ursache des Fehlers informiert und müssen Abhilfemaßnahmen ergreifen, z. B. einen anderen Instance-Typ wählen, Lebenszyklusskripts korrigieren oder es in einer anderen Availability Zone erneut versuchen.
## Voraussetzungen
Kontinuierliches Provisioning erfordert, dass die Slurm-Bereitstellungsparameter (Knotentypen, Partitionsnamen) über die API-Payload im Feld jeder Instanzgruppe bereitgestellt werden. `SlurmConfig` Cluster, die auf der `provisioning_parameters.json` Legacy-Datei in Amazon S3 basieren, sind nicht mit Continuous Provisioning kompatibel.
**Anmerkung**
Die folgenden Funktionen werden derzeit bei der kontinuierlichen Bereitstellung auf Slurm-Clustern nicht unterstützt: Migration vorhandener Cluster, Konfiguration mehrerer Knoten über eine API-basierte Slurm-Topologie und. `SlurmConfigStrategy` Die kontinuierliche Bereitstellung erfolgt ausschließlich im Merge-Modus für die Verwaltung. `slurm.conf`
## Nutzungsmessung
HyperPod Cluster mit kontinuierlicher Bereitstellung verwenden Metering auf Instanzebene, um eine genaue Abrechnung zu gewährleisten, die die tatsächliche Ressourcennutzung widerspiegelt. Dieser Zählungsansatz unterscheidet sich von der herkömmlichen Abrechnung auf Clusterebene dadurch, dass jede Instance unabhängig verfolgt wird.
**Abrechnung auf Instance-Ebene**
Bei kontinuierlicher Bereitstellung beginnt und endet die Abrechnung auf der Ebene der einzelnen Instances, anstatt auf Statusänderungen auf Clusterebene zu warten. Diese Methode bietet folgende Vorteile:
+ **Präzise Rechnungsgenauigkeit: Die Abrechnung** beginnt, wenn die Ausführung des Lifecycle-Skripts beginnt. Wenn das Lifecycle-Skript fehlschlägt, wird die Instance-Bereitstellung erneut versucht, und Ihnen wird die Dauer der Laufzeit des Lifecycle-Skripts in Rechnung gestellt.
+ **Unabhängige Messung**: Der Abrechnungszyklus jeder Instanz wird separat verwaltet, wodurch kaskadierende Abrechnungsfehler vermieden werden.
+ **Abrechnungsupdates in Echtzeit**: Die Abrechnung beginnt, wenn eine Instance mit der Ausführung ihres Lebenszyklus-Konfigurationsskripts beginnt, und endet, wenn die Instance in den Endzustand übergeht.
**Lebenszyklus der Abrechnung**
Jede Instance in Ihrem HyperPod Cluster folgt diesem Abrechnungszyklus:
+ Die **Abrechnung beginnt**: Wenn die Instance erfolgreich gestartet wird und mit der Ausführung ihres Lebenszyklus-Konfigurationsskripts beginnt.
+ Die **Abrechnung wird fortgesetzt**: Während der gesamten Betriebsdauer der Instance.
+ Die **Abrechnung wird beendet**: Wenn die Instance unabhängig vom Grund für die Kündigung in den Status „Beenden“ übergeht.
**Anmerkung**
Die Abrechnung für Instances, die nicht gestartet werden können, beginnt nicht. Wenn der Start einer Instance aufgrund unzureichender Kapazität oder anderer Probleme fehlschlägt, wird Ihnen dieser fehlgeschlagene Versuch nicht in Rechnung gestellt. Die Abrechnung wird auf Instance-Ebene berechnet und die Kosten werden zusammengefasst und unter dem Amazon-Ressourcennamen (ARN) Ihres Clusters gemeldet.
## Erstellen Sie einen Cluster mit aktivierter kontinuierlicher Bereitstellung
**Anmerkung**
Bereiten Sie ein Lifecycle-Konfigurationsskript vor und laden Sie es in einen Amazon S3 S3-Bucket hoch, auf den Ihre Ausführungsrolle zugreifen kann. Weitere Informationen finden Sie unter [SageMaker HyperPod Slurm-Clusteroperationen](sagemaker-hyperpod-operate-slurm.md).
Bereiten Sie eine `CreateCluster` API-Anforderungsdatei im JSON-Format vor. Stellen `NodeProvisioningMode` Sie diese Option ein `Continuous` und geben Sie im Feld jeder Instanzgruppe Informationen zur Slurm-Topologie an`SlurmConfig`.
```
// create_cluster.json
{
"ClusterName": "my-training-cluster",
"NodeProvisioningMode": "Continuous",
"Orchestrator": {
"Slurm": {}
},
"InstanceGroups": [
{
"InstanceGroupName": "controller-group",
"InstanceType": "ml.m5.xlarge",
"InstanceCount": 1,
"LifeCycleConfig": {
"SourceS3Uri": "s3://amzn-s3-demo-bucket/lifecycle-scripts/src/",
"OnCreate": "on_create.sh"
},
"ExecutionRole": "arn:aws:iam::111122223333:role/iam-role-for-cluster",
"SlurmConfig": {
"NodeType": "Controller"
}
},
{
"InstanceGroupName": "login-group",
"InstanceType": "ml.m5.xlarge",
"InstanceCount": 1,
"LifeCycleConfig": {
"SourceS3Uri": "s3://amzn-s3-demo-bucket/lifecycle-scripts/src/",
"OnCreate": "on_create.sh"
},
"ExecutionRole": "arn:aws:iam::111122223333:role/iam-role-for-cluster",
"SlurmConfig": {
"NodeType": "Login"
}
},
{
"InstanceGroupName": "worker-gpu-a",
"InstanceType": "ml.p5.48xlarge",
"InstanceCount": 16,
"LifeCycleConfig": {
"SourceS3Uri": "s3://amzn-s3-demo-bucket/lifecycle-scripts/src/",
"OnCreate": "on_create.sh"
},
"ExecutionRole": "arn:aws:iam::111122223333:role/iam-role-for-cluster",
"SlurmConfig": {
"NodeType": "Compute",
"PartitionNames": ["gpu-training"]
}
}
],
"VpcConfig": {
"SecurityGroupIds": ["sg-12345678"],
"Subnets": ["subnet-12345678"]
}
}
```
Führen Sie den `create-cluster` Befehl aus, um die Anfrage einzureichen.
```
aws sagemaker create-cluster \
--cli-input-json file://complete/path/to/create_cluster.json
```
Dies gibt den ARN des neuen Clusters zurück.
```
{
"ClusterArn": "arn:aws:sagemaker:us-west-2:111122223333:cluster/abcde12345"
}
```
## Verwaltung der Slurm-Konfiguration
Die kontinuierliche Bereitstellung erfolgt ausschließlich im Merge-Modus für die `slurm.conf` Partitionsverwaltung. HyperPodWendet im Zusammenführungsmodus die Änderungen der Partitionskonfiguration zusätzlich zu den Änderungen an, an denen Sie Änderungen vorgenommen haben. `slurm.conf` HyperPod aktualisiert nur die partitionsbezogenen Abschnitte von `slurm.conf` (wie Partitionsnamen- und Knotennameneinträge); andere Slurm-Konfigurationsparameter werden nicht geändert. Das bedeutet Folgendes:
+ Ihre manuellen Änderungen an bleiben erhalten. `slurm.conf`
+ Es gibt keine automatische Erkennung von Abweichungen oder eine automatische Lösung von Konflikten zwischen Ihren Änderungen und HyperPod dem erwarteten Status.
Der `SlurmConfigStrategy` Parameter (`Managed`,`Merge`,`Overwrite`) wird bei kontinuierlicher Bereitstellung nicht unterstützt. Die Übergabe eines beliebigen `SlurmConfigStrategy` Werts führt zu einem API-Fehler.
# SageMaker HyperPod Cluster-Verwaltung
In den folgenden Themen werden die Protokollierung und Verwaltung von SageMaker HyperPod Clustern behandelt.
## SageMaker HyperPod Ereignisse protokollieren
Alle Ereignisse und Protokolle von SageMaker HyperPod werden in Amazon CloudWatch unter dem Namen der Protokollgruppe gespeichert`/aws/sagemaker/Clusters/[ClusterName]/[ClusterID]`. Jeder Aufruf der `CreateCluster`-API erstellt eine neue Protokollgruppe. Die folgende Liste enthält alle verfügbaren Protokollstreams, die in jeder Protokollgruppe gesammelt wurden.
| | |
| --- |--- |
| Name der Protokollgruppe | Name des Protokollstreams |
| /aws/sagemaker/Clusters/[ClusterName]/[ClusterID] | LifecycleConfig/[instance-group-name]/[instance-id] |
## Protokollierung SageMaker HyperPod auf Instanzebene
Sie können CloudWatch während der Konfiguration der Clusterinstanz auf die veröffentlichten LifecycleScript Protokolle zugreifen. Jede Instance innerhalb des erstellten Clusters generiert einen separaten Protokollstream, der sich durch das Format `LifecycleConfig/[instance-group-name]/[instance-id]` unterscheidet.
Alle Protokolle, in die geschrieben wird, `/var/log/provision/provisioning.log` werden in den vorherigen CloudWatch Stream hochgeladen. Beispiel LifecycleScripts bei der [https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config](https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config)Weiterleitung ihres `stdout` und `stderr` an diesen Speicherort. Wenn Sie Ihre benutzerdefinierten Skripts verwenden, schreiben Sie Ihre Protokolle an den `/var/log/provision/provisioning.log` Ort, an dem sie verfügbar sind CloudWatch.
**Markierungen für Lifecycle-Skripte**
CloudWatch Logs für Lebenszyklusskripte enthalten spezielle Markierungen, anhand derer Sie den Ausführungsfortschritt verfolgen und Probleme identifizieren können:
| | |
| --- |--- |
| Marker | Beschreibung |
| START | Indicates the beginning of lifecycle script logs for the instance |
| [SageMaker] Lifecycle scripts were provided, with S3 uri: [s3://bucket-name/] and entrypoint script: [script-name.sh] | Indicates the S3 location and entrypoint script that will be used |
| [SageMaker] Downloading lifecycle scripts | Indicates scripts are being downloaded from the specified S3 location |
| [SageMaker] Lifecycle scripts have been downloaded | Indicates scripts have been successfully downloaded from S3 |
| [SageMaker] The lifecycle scripts succeeded | Indicates successful completion of all lifecycle scripts |
| [SageMaker] The lifecycle scripts failed | Indicates failed execution of lifecycle scripts |
Anhand dieser Markierungen können Sie schnell erkennen, an welcher Stelle im Ausführungsprozess des Lebenszyklus-Skripts ein Problem aufgetreten ist. Überprüfen Sie bei der Behebung von Fehlern die Protokolleinträge, um festzustellen, wo der Prozess gestoppt wurde oder fehlgeschlagen ist.
**Fehlermeldungen bei Lifecycle-Skripten**
Wenn das Lifecycle-Skript existiert, aber während der Ausführung fehlschlägt, erhalten Sie eine Fehlermeldung, die den Namen der CloudWatch Protokollgruppe und den Namen des Protokolldatenstroms enthält. Falls bei mehreren Instanzen ein Lifecycle-Skript fehlschlägt, weist die Fehlermeldung nur auf eine ausgefallene Instanz hin. Die Protokollgruppe sollte jedoch Streams für alle Instanzen enthalten.
Sie können die Fehlermeldung anzeigen, indem Sie die [DescribeCluster](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_DescribeCluster.html)API ausführen oder die Seite mit den Cluster-Details in der SageMaker Konsole aufrufen. In der Konsole befindet sich die Schaltfläche **Lebenszyklus-Skriptprotokolle anzeigen**, mit der Sie direkt zum CloudWatch Protokollstream gelangen. Die Fehlermeldung hat das folgende Format:
```
Instance [instance-id] failed to provision with the following error: "Lifecycle scripts did not run successfully. To view lifecycle script logs,
visit log group ‘/aws/sagemaker/Clusters/[cluster-name]/[cluster-id]' and log stream ‘LifecycleConfig/[instance-group-name]/[instance-id]’.
If you cannot find corresponding lifecycle script logs in CloudWatch, please make sure you follow one of the options here:
https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-faq-slurm.html#hyperpod-faqs-q1.” Note that multiple instances may be impacted.
```
## Taggen von Ressourcen
AWS Das Tagging-System hilft bei der Verwaltung, Identifizierung, Organisation, Suche und Filterung von Ressourcen. SageMaker HyperPod unterstützt Tagging, sodass Sie die Cluster als Ressource verwalten können. AWS Während der Clustererstellung oder Bearbeitung eines vorhandenen Clusters können Sie Tags für den Cluster hinzufügen oder bearbeiten. Weitere Informationen zum Markieren im Allgemeinen finden Sie unter [Markieren Ihrer AWS -Ressourcen](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html).
### Verwenden der Benutzeroberfläche der SageMaker HyperPod Konsole
Wenn Sie [einen neuen Cluster erstellen](sagemaker-hyperpod-operate-slurm-console-ui.md#sagemaker-hyperpod-operate-slurm-console-ui-create-cluster) oder [einen Cluster bearbeiten](sagemaker-hyperpod-operate-slurm-console-ui.md#sagemaker-hyperpod-operate-slurm-console-ui-edit-clusters), können Sie Tags hinzufügen, entfernen oder bearbeiten.
### Mit dem SageMaker HyperPod APIs
Wenn Sie eine [CreateCluster](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_CreateCluster.html)oder [UpdateCluster](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_UpdateCluster.html)API-Anforderungsdatei im JSON-Format schreiben, bearbeiten Sie den `Tags` Abschnitt.
### Verwenden Sie die AWS CLI Tagging-Befehle für KI SageMaker
**So markieren Sie einen Cluster**
Verwenden Sie [https://docs.aws.amazon.com/cli/latest/reference/sagemaker/add-tags.html](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/add-tags.html) wie folgt.
```
aws sagemaker add-tags --resource-arn cluster_ARN --tags Key=string,Value=string
```
**So heben Sie die Markierung eines Clusters auf**
Verwenden Sie [https://docs.aws.amazon.com/cli/latest/reference/sagemaker/delete-tags.html](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/delete-tags.html) wie folgt.
```
aws sagemaker delete-tags --resource-arn cluster_ARN --tag-keys "tag_key"
```
**So listen Sie Tags für eine Ressource auf**
Verwenden Sie [https://docs.aws.amazon.com/cli/latest/reference/sagemaker/list-tags.html](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/list-tags.html) wie folgt.
```
aws sagemaker list-tags --resource-arn cluster_ARN
```
# SageMaker HyperPod FAQs
Verwenden Sie die folgenden häufig gestellten Fragen, um Probleme bei der Verwendung von zu beheben SageMaker HyperPod.
**Topics**
+ [Warum kann ich in Amazon keine Protokollgruppen meines SageMaker HyperPod Clusters finden CloudWatch?](#hyperpod-faqs-q1)
+ [Welche speziellen Konfigurationen werden in Slurm-Konfigurationsdateien wie `slurm.conf` und HyperPod `gres.conf` verwaltet?](#hyperpod-faqs-q2)
+ [Wie führe ich Docker auf Slurm-Knoten aus? HyperPod](#hyperpod-faqs-q3)
+ [Warum schlägt mein parallel Trainingsjob fehl, wenn ich die NVIDIA Collective Communications Library (NCCL) mit Slurm auf der Plattform verwende? SageMaker HyperPod](#hyperpod-faqs-q4)
+ [Wie verwende ich den lokalen NVMe Speicher von P-Instances, um Docker- oder Enroot-Container mit Slurm zu starten?](#hyperpod-faqs-q5)
+ [Wie richten Sie EFA-Sicherheitsgruppen ein?](#hyperpod-faqs-q6)
+ [Wie überwache ich meine Clusterknoten? HyperPod Gibt es CloudWatch Metriken, aus denen exportiert wurde HyperPod?](#hyperpod-faqs-q7)
+ [Kann ich den HyperPod Clusterknoten zusätzlichen Speicher hinzufügen? Die Cluster-Instances haben einen begrenzten lokalen Instance-Speicher.](#hyperpod-faqs-q8)
+ [Warum werden meine Rechenknoten nach einem Neustart als „DOWN“ oder „DRAINED“ angezeigt?](#hyperpod-faqs-q9)
+ [Warum werden meine Knoten aufgrund von Speicherplatzproblemen (OOM) immer wieder heruntergefahren?](#hyperpod-faqs-q10)
+ [Wie kann ich sicherstellen, dass Ressourcen nach Abschluss von Aufträgen ordnungsgemäß bereinigt werden?](#hyperpod-faqs-q11)
## Warum kann ich in Amazon keine Protokollgruppen meines SageMaker HyperPod Clusters finden CloudWatch?
Standardmäßig werden Agentenprotokolle und Instance-Startprotokolle an die Konten der HyperPod Plattform gesendet CloudWatch. Im Fall von Benutzerlebenszyklus-Skripten werden die Lebenszykluskonfigurationsprotokolle an Ihr Konto gesendet CloudWatch.
Wenn Sie die vom HyperPod Serviceteam bereitgestellten [Beispiel-Lebenszyklusskripte](sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-base-config.md) verwenden, können Sie davon ausgehen, dass die Lebenszyklus-Konfigurationsprotokolle in die geschrieben wurden`/var/log/provision/provisioning.log`, und dieses Problem würde nicht auftreten.
Wenn Sie jedoch benutzerdefinierte Pfade für das Sammeln von Protokollen aus der Lebenszyklusbereitstellung verwenden und die Protokollgruppen in Ihren Konten nicht finden können, kann dies daran liegen CloudWatch, dass die in Ihren Lifecycle-Skripten angegebenen Protokolldateipfade nicht mit dem übereinstimmen, wonach der auf den HyperPod Cluster-Instances ausgeführte CloudWatch Agent sucht. In diesem Fall bedeutet dies, dass Sie Ihre Lifecycle-Skripts ordnungsgemäß einrichten müssen, um Protokolle an den CloudWatch Agenten zu senden, und auch die CloudWatch Agentenkonfiguration entsprechend einrichten müssen. Um das Problem zu beheben, wählen Sie eine der folgenden Optionen.
+ **Option 1:** Aktualisieren Sie Ihre Lebenszyklusskripte, um Protokolle in `/var/log/provision/provisioning.log` zu schreiben.
+ **Option 2:** Aktualisieren Sie den CloudWatch Agenten so, dass er nach Ihren benutzerdefinierten Pfaden für die Protokollierung der Lebenszyklusbereitstellung sucht.
1. Jede HyperPod Clusterinstanz enthält eine CloudWatch Agentenkonfigurationsdatei im JSON-Format unter`/opt/aws/amazon-cloudwatch-agent/sagemaker_cwagent_config.json`. Suchen Sie in der Konfigurationsdatei nach dem Feldnamen `logs.logs_collected.files.collect_list.file_path`. Bei der Standardeinstellung von sollte HyperPod das Schlüssel-Wert-Paar `"file_path": "/var/log/provision/provisioning.log"` wie unter dokumentiert sein. [Protokollierung SageMaker HyperPod auf Instanzebene](sagemaker-hyperpod-cluster-management-slurm.md#sagemaker-hyperpod-cluster-management-slurm-logging-at-instance-level) Der folgende Codeausschnitt zeigt, wie die JSON-Datei mit der Standardkonfiguration aussieht. HyperPod
```
"logs": {
"logs_collected": {
"files": {
"collect_list": [
{
"file_path": "/var/log/provision/provisioning.log",
"log_group_name": "/aws/sagemaker/Clusters/[ClusterName]/[ClusterID]",
"log_stream_name": "LifecycleConfig/[InstanceGroupName]/{instance_id}",
"retention_in_days": -1
}
]
}
},
"force_flush_interval": 3
}
```
1. Ersetzen Sie den Wert für den `"file_path"`-Feldnamen durch den benutzerdefinierten Pfad, den Sie in Ihren Lebenszyklusskripten verwenden. Wenn Sie beispielsweise Ihre Lebenszyklusskripte so eingerichtet haben, dass sie in `/var/log/custom-provision/custom-provisioning.log` schreiben, aktualisieren Sie den Wert wie folgt, sodass er mit ihm übereinstimmt.
```
"file_path": "/var/log/custom-provision/custom-provisioning.log"
```
1. Starten Sie den CloudWatch Agenten mit der Konfigurationsdatei neu, um die Anwendung des benutzerdefinierten Pfads abzuschließen. Der folgende CloudWatch Befehl zeigt beispielsweise, wie der CloudWatch Agent mit der CloudWatch Agent-Konfigurationsdatei aus Schritt 1 neu gestartet wird. Weitere Informationen finden Sie unter [Problembehandlung beim CloudWatch Agenten](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/troubleshooting-CloudWatch-Agent.html).
```
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl \
-a fetch-config -m ec2 -s -c \
file:/opt/aws/amazon-cloudwatch-agent/sagemaker_cwagent_config.json
```
## Welche speziellen Konfigurationen werden in Slurm-Konfigurationsdateien wie `slurm.conf` und HyperPod `gres.conf` verwaltet?
Wenn Sie einen Slurm-Cluster erstellen HyperPod, richtet der HyperPod Agent die [https://slurm.schedmd.com/gres.conf.html](https://slurm.schedmd.com/gres.conf.html)Dateien [https://slurm.schedmd.com/slurm.conf.html](https://slurm.schedmd.com/slurm.conf.html)und unter ein, um den Slurm-Cluster auf der Grundlage Ihrer Anfrage `/opt/slurm/etc/` zur Clustererstellung und der HyperPod Lebenszyklusskripte zu verwalten. Die folgende Liste zeigt, welche spezifischen Parameter der HyperPod Agent verarbeitet und überschreibt.
**Wichtig**
Wir empfehlen dringend, diese von HyperPod verwalteten Parameter NICHT zu ändern.
+ In [https://slurm.schedmd.com/slurm.conf.html](https://slurm.schedmd.com/slurm.conf.html), HyperPod richtet die folgenden grundlegenden Parameter ein: `ClusterName``SlurmctldHost`,`PartitionName`, und`NodeName`.
Um die [Automatische Knotenwiederherstellung und automatische Wiederaufnahme](sagemaker-hyperpod-resiliency-slurm-auto-resume.md) Funktionalität zu aktivieren, HyperPod müssen außerdem die `SchedulerParameters` Parameter `TaskPlugin` und wie folgt festgelegt werden. Der HyperPod Agent richtet diese beiden Parameter standardmäßig mit den erforderlichen Werten ein.
```
TaskPlugin=task/none
SchedulerParameters=permit_job_expansion
```
+ In [https://slurm.schedmd.com/gres.conf.html](https://slurm.schedmd.com/gres.conf.html), HyperPod verwaltet `NodeName` für GPU-Knoten.
## Wie führe ich Docker auf Slurm-Knoten aus? HyperPod
Um Sie bei der Ausführung von Docker auf Ihren Slurm-Knoten zu unterstützen HyperPod, stellt das HyperPod Service-Team Setup-Skripte zur Verfügung, die Sie als Teil der Lebenszykluskonfiguration für die Clustererstellung hinzufügen können. Weitere Informationen hierzu finden Sie unter [Die grundlegenden Lebenszyklusskripte werden bereitgestellt von HyperPod](sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-base-config.md) und [Docker-Container auf einem Slurm-Rechenknoten ausführen auf HyperPod](sagemaker-hyperpod-run-jobs-slurm-docker.md).
## Warum schlägt mein parallel Trainingsjob fehl, wenn ich die NVIDIA Collective Communications Library (NCCL) mit Slurm auf der Plattform verwende? SageMaker HyperPod
Standardmäßig legt das Linux-Betriebssystem die `#RemoveIPC=yes`-Flag fest. Slurm- und mpirun-Aufträge, die NCCL verwenden, generieren Ressourcen für die Interprozesskommunikation (IPC) unter Nicht-Root-Benutzersitzungen. Diese Benutzersitzungen werden möglicherweise während des Auftragsvorgangs abgemeldet.
Wenn Sie Aufträge mit Slurm oder mpirun ausführen, wenn `systemd` feststellt, dass der Benutzer nicht angemeldet ist, werden die IPC-Ressourcen bereinigt. Slurm- und mpirun-Aufträge können ausgeführt werden, ohne dass der Benutzer angemeldet ist. Dazu ist es jedoch erforderlich, die Bereinigung auf systemd-Ebene zu deaktivieren und stattdessen auf Slurm-Ebene einzurichten. Weitere Informationen finden Sie unter [Systemd in der NCCL-Dokumentation](https://docs.nvidia.com/deeplearning/nccl/user-guide/docs/troubleshooting.html#systemd).
Führen Sie die folgenden Schritte aus, um die Bereinigung auf Systemd-Ebene zu deaktivieren.
1. Legen Sie die Flag `#RemoveIPC=no` in der Datei `/etc/systemd/logind.conf` fest, wenn Sie Trainingsjobs ausführen, die Slurm und NCCL verwenden.
1. Standardmäßig bereinigt Slurm gemeinsam genutzte Ressourcen nicht. Wir empfehlen Ihnen, ein Slurm-Epilog-Skript einzurichten, um gemeinsam genutzte Ressourcen zu bereinigen. Diese Bereinigung ist nützlich, wenn Sie viele gemeinsam genutzte Ressourcen haben und diese nach Trainingsjobs bereinigen möchten. Nachfolgend sehen Sie ein Beispielskript.
```
#!/bin/bash
: <<'SUMMARY'
Script: epilog.sh
Use this script with caution, as it can potentially delete unnecessary resources and cause issues if you don't use it correctly.
Note: You must save this script in a shared in a shared location that is accessible to all nodes in the cluster, such as /fsx volume.
Workers must be able to access the script to run the script after jobs.
SUMMARY
# Define the log directory and create it if it doesn't exist
LOG_DIR="//epilogue" #NOTE: Update PLACEHOLDER to be a shared value path, such as /fsx/epilogue.
mkdir -p "$LOG_DIR"
# Name the log file using the Slurm job name and job ID
log_file="$LOG_DIR/epilogue-${SLURM_JOB_NAME}_${SLURM_JOB_ID}.log"
logging() {
echo "[$(date)] $1" | tee -a "$log_file"
}
# Slurm epilogue script to clean up IPC resources
logging "Starting IPC cleanup for Job $SLURM_JOB_ID"
# Clean up shared memory segments by username
for seg in $(ipcs -m | awk -v owner="$SLURM_JOB_USER" '$3 == owner {print $2}'); do
if ipcrm -m "$seg"; then
logging "Removed shared memory segment $seg"
else
logging "Failed to remove shared memory segment $seg"
fi
done
# Clean up semaphores by username
for sem in $(ipcs -s | awk -v user="$SLURM_JOB_USER" '$3 == user {print $2}'); do
if ipcrm -s "$sem"; then
logging "Removed semaphore $sem"
else
logging "Failed to remove semaphore $sem"
fi
done
# Clean up NCCL IPC
NCCL_IPC_PATH="/dev/shm/nccl-*"
for file in $NCCL_IPC_PATH; do
if [ -e "$file" ]; then
if rm "$file"; then
logging "Removed NCCL IPC file $file"
else
logging "Failed to remove NCCL IPC file $file"
fi
fi
done
logging "IPC cleanup completed for Job $SLURM_JOB_ID"
exit 0
```
Weitere Informationen zum Epilog-Parameter finden Sie in der [Slurm-Dokumentation](https://slurm.schedmd.com/slurm.conf.html#OPT_Epilog).
1. Fügen Sie in der `slurm.conf`-Datei vom Controller-Knoten eine Zeile hinzu, die auf das von Ihnen erstellte Epilog-Skript verweist.
```
Epilog="/path/to/epilog.sh" #For example: /fsx/epilogue/epilog.sh
```
1. Führen Sie die folgenden Befehle aus, um die Berechtigungen des Skripts zu ändern und es ausführbar zu machen.
```
chown slurm:slurm /path/to/epilog.sh
chmod +x /path/to/epilog.sh
```
1. Führen Sie den Befehl `scontrol reconfigure` aus, um alle Ihre Änderungen zu übernehmen.
## Wie verwende ich den lokalen NVMe Speicher von P-Instances, um Docker- oder Enroot-Container mit Slurm zu starten?
Da das Standard-Root-Volume Ihres Hauptknotens normalerweise auf ein EBS-Volume von 100 GB begrenzt ist, müssen Sie Docker und Enroot so einrichten, dass sie den lokalen Instance-Speicher verwenden. NVMe Informationen zum Einrichten eines NVMe Speichers und dessen Verwendung zum Starten von Docker-Containern finden Sie unter. [Docker-Container auf einem Slurm-Rechenknoten ausführen auf HyperPod](sagemaker-hyperpod-run-jobs-slurm-docker.md)
## Wie richten Sie EFA-Sicherheitsgruppen ein?
Wenn Sie einen HyperPod Cluster mit EFA-fähigen Instances erstellen möchten, stellen Sie sicher, dass Sie eine Sicherheitsgruppe einrichten, die den gesamten eingehenden und ausgehenden Datenverkehr zur und von der Sicherheitsgruppe selbst zulässt. Weitere Informationen finden Sie unter [Schritt 1: Vorbereiten einer EFA-fähigen Sicherheitsgruppe](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa-start.html#efa-start-security) im *Amazon-EC2-Benutzerhandbuch*.
## Wie überwache ich meine Clusterknoten? HyperPod Gibt es CloudWatch Metriken, aus denen exportiert wurde HyperPod?
Um einen Überblick über die Ressourcennutzung Ihres HyperPod Clusters zu erhalten, empfehlen wir Ihnen, den HyperPod Cluster in Amazon Managed Grafana und Amazon Managed Service for Prometheus zu integrieren. Mit verschiedenen Open-Source-Grafana-Dashboards und Exportpaketen können Sie Metriken zu den Cluster-Ressourcen exportieren und visualisieren. HyperPod Weitere Informationen zur Einrichtung SageMaker HyperPod mit Amazon Managed Grafana und Amazon Managed Service für Prometheus finden Sie unter. [SageMaker HyperPod Überwachung der Cluster-Ressourcen](sagemaker-hyperpod-cluster-observability-slurm.md) Beachten Sie, dass der Export von Systemmetriken nach Amazon SageMaker HyperPod derzeit nicht unterstützt wird. CloudWatch
## Kann ich den HyperPod Clusterknoten zusätzlichen Speicher hinzufügen? Die Cluster-Instances haben einen begrenzten lokalen Instance-Speicher.
Wenn der standardmäßige Instance-Speicher für Ihren Workload nicht ausreicht, können Sie zusätzlichen Speicher pro Instance konfigurieren. Ab der [Veröffentlichung am 20. Juni 2024](sagemaker-hyperpod-release-notes.md#sagemaker-hyperpod-release-notes-20240620) können Sie jeder Instance in Ihrem SageMaker HyperPod Cluster ein zusätzliches Amazon Elastic Block Store (EBS) -Volume hinzufügen. Beachten Sie, dass diese Funktion nicht auf bestehende Instanzgruppen von SageMaker HyperPod Clustern angewendet werden kann, die vor dem 20. Juni 2024 erstellt wurden. Sie können diese Funktion nutzen, indem Sie bestehende SageMaker HyperPod Cluster, die vor dem 20. Juni 2024 erstellt wurden, patchen und ihnen neue Instanzgruppen hinzufügen. Diese Funktion ist für alle SageMaker HyperPod Cluster, die nach dem 20. Juni 2024 erstellt wurden, voll wirksam.
## Warum werden meine Rechenknoten nach einem Neustart als „DOWN“ oder „DRAINED“ angezeigt?
Dies tritt in der Regel auf, wenn Knoten mit `sudo reboot` statt mit der Slurm-Steuerungsschnittstelle neu gestartet werden. Verwenden Sie den Slurm-Befehl `scontrol reboot nextstate=resume `, um Knoten ordnungsgemäß neu zu starten. Dadurch wird sichergestellt, dass Slurm die richtige Kontrolle über den Knotenstatus behält und nach dem Neustart den normalen Betrieb wieder aufnimmt.
Bei GPU-Instances (wie NVIDIA P5) kann dies auch passieren, wenn der Knoten seinen Startvorgang nicht innerhalb der Standardzeit von Slurm (60 Sekunden) abschließen kann. Um dieses Problem zu beheben, erhöhen Sie den `TimeToResume`-Parameter in `slurm.conf` auf 300 Sekunden. Dadurch haben GPU-Instances ausreichend Zeit, um Treiber zu starten und zu initialisieren.
## Warum werden meine Knoten aufgrund von Speicherplatzproblemen (OOM) immer wieder heruntergefahren?
OOM-Probleme treten auf, wenn Aufträge die Speicherkapazität des Knotens überschreiten. Um dies zu verhindern, implementieren Sie `cgroups`, um das Speicherlimits pro Auftrag zu erzwingen. Dadurch wird verhindert, dass sich ein einzelner Auftrag auf den gesamten Knoten auswirkt, und Isolierung und Stabilität werden verbessert.
Beispieleinrichtung in `slurm.conf`:
```
TaskPlugin=task/cgroup
```
Beispieleinrichtung in `cgroup.conf`:
```
CgroupAutomount=yes
ConstrainCores=yes
CgroupPlugin=autodetect
ConstrainDevices=yes
ConstrainRAMSpace=yes
ConstrainSwapSpace=yes
SignalChildrenProcesses=yes
MaxRAMPercent=99
MaxSwapPercent=80
MinRAMSpace=100
```
Weitere Informationen finden Sie unter [Kontrollgruppe in Slurm](https://slurm.schedmd.com/cgroups.html), [Cgroup- und PAM-basierte Anmeldesteuerung für Slurm-Rechenknoten](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/utils/pam_adopt_cgroup_wheel.sh#L197) und [Konfigurieren von Cgroups für Slurm](https://catalog.workshops.aws/sagemaker-hyperpod/en-US/07-tips-and-tricks/16-enable-cgroups).
## Wie kann ich sicherstellen, dass Ressourcen nach Abschluss von Aufträgen ordnungsgemäß bereinigt werden?
Implementieren Sie Epilog-Skripte, um Ressourcen nach Abschluss von Aufträgen automatisch zu bereinigen. Ressourcen werden möglicherweise nicht ordnungsgemäß gelöscht, wenn Aufträge unerwartet abstürzen, Fehler enthalten, die eine normale Bereinigung verhindern, oder wenn gemeinsam genutzte Speicherpuffer (einschließlich solcher, die zwischen Prozessen und GPU-Treibern gemeinsam genutzt werden) zugewiesen bleiben.
Epilog-Skripte können Aufgaben wie das Löschen des GPU-Speichers, das Entfernen temporärer Dateien und das Aushängen von Dateisystemen ausführen. Diese Skripte weisen Einschränkungen auf, wenn Ressourcen nicht ausschließlich einem einzelnen Auftrag zugewiesen sind. Ausführliche Anweisungen und Beispielskripte finden Sie im zweiten Aufzählungspunkt der Frage [Warum schlägt mein parallel Trainingsjob fehl, wenn ich die NVIDIA Collective Communications Library (NCCL) mit Slurm auf der Plattform verwende? SageMaker HyperPod](#hyperpod-faqs-q4). Weitere Informationen finden Sie unter [Aktivieren des Slurm-Epilog-Skripts](https://catalog.workshops.aws/sagemaker-hyperpod/en-US/07-tips-and-tricks/18-slurm-epilogue).
# Orchestrierung von SageMaker HyperPod Clustern mit Amazon EKS
SageMaker HyperPod ist ein SageMaker KI-verwalteter Service, der ein umfangreiches Training von Basismodellen auf langlebigen und belastbaren Rechenclustern ermöglicht und zur Orchestrierung der HyperPod Rechenressourcen in Amazon EKS integriert wird. Mithilfe von Amazon EKS-Clustern mit HyperPod Resilienzfunktionen, die nach verschiedenen Hardwarefehlern suchen und fehlerhafte Knoten automatisch wiederherstellen, können Sie unterbrechungsfreie Trainingsjobs über Wochen oder Monate in großem Umfang ausführen.
Zu den wichtigsten Features für Clusteradministratoren gehören die folgenden.
+ Bereitstellung HyperPod robuster Cluster und deren Anbindung an eine EKS-Steuerebene
+ Ermöglicht dynamisches Kapazitätsmanagement, wie das Hinzufügen weiterer Knoten, das Aktualisieren von Software und das Löschen von Clustern.
+ Aktivierung des Zugriffs auf die Cluster-Instances direkt über `kubectl` oder SSM/SSH
+ Bietet [Resilienzfunktionen](sagemaker-hyperpod-eks-resiliency.md), darunter grundlegende Gesundheitschecks, eingehende Gesundheitschecks, einen Agenten zur Gesundheitsüberwachung und Unterstützung für die automatische Wiederaufnahme von Jobs PyTorch
+ [Integration mit Observability-Tools wie [Amazon CloudWatch Container Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContainerInsights.html), [Amazon Managed Service for Prometheus](https://docs.aws.amazon.com/prometheus/latest/userguide/what-is-Amazon-Managed-Service-Prometheus.html) und Amazon Managed Grafana](https://docs.aws.amazon.com/grafana/latest/userguide/what-is-Amazon-Managed-Service-Grafana.html)
Für Benutzer von Datenwissenschaftlern ermöglicht die EKS-Unterstützung Folgendes. HyperPod
+ Ausführung von containerisierten Workloads zum Trainieren von Basismodellen auf dem Cluster HyperPod
+ Inferenz auf dem EKS-Cluster ausführen und dabei die Integration zwischen und EKS nutzen HyperPod
+ Nutzung der Funktion zur automatischen Wiederaufnahme von Jobs für [ PyTorch Kubeflow-Schulungen](https://www.kubeflow.org/docs/components/training/user-guides/pytorch/) () PyTorchJob
**Anmerkung**
Amazon EKS ermöglicht die benutzerverwaltete Orchestrierung von Aufgaben und Infrastruktur SageMaker HyperPod über die Amazon EKS Control Plane. Stellen Sie sicher, dass der Benutzerzugriff auf den Cluster über den Kubernetes API-Server-Endpunkt dem Prinzip der geringsten Rechte folgt und dass der Netzwerkausgang aus dem Cluster gesichert ist. HyperPod
Weitere Informationen zur Sicherung des Zugriffs auf den API-Server von Amazon EKS finden Sie unter [Steuern des Netzwerkzugriffs auf den Cluster-API-Serverendpunkt](https://docs.aws.amazon.com/eks/latest/userguide/cluster-endpoint.html).
Weitere Informationen zur Sicherung des Netzwerkzugriffs finden Sie unter. HyperPod [Einrichtung SageMaker HyperPod mit einer benutzerdefinierten Amazon VPC](sagemaker-hyperpod-prerequisites.md#sagemaker-hyperpod-prerequisites-optional-vpc)
Die High-Level-Architektur der Amazon EKS-Unterstützung HyperPod beinhaltet eine 1-zu-1-Zuordnung zwischen einem EKS-Cluster (Kontrollebene) und einem HyperPod Cluster (Worker-Knoten) innerhalb einer VPC, wie in der folgenden Abbildung dargestellt.
![\[EKS and HyperPod VPC architecture with control plane, Cluster nodes, and AWS-Services.\]](http://docs.aws.amazon.com/de_de/sagemaker/latest/dg/images/hyperpod-eks-diagram.png)
# Verwaltung von SageMaker HyperPod Clustern, die von Amazon EKS orchestriert werden
Dieser Abschnitt enthält Anleitungen zur Verwaltung SageMaker HyperPod über die Benutzeroberfläche der SageMaker AI-Konsole oder die AWS Command Line Interface (CLI). Es wird erklärt, wie Sie verschiedene Aufgaben ausführen können SageMaker HyperPod, je nachdem, ob Sie eine visuelle Oberfläche bevorzugen oder mit Befehlen arbeiten.
**Topics**
+ [Erste Schritte mit der Amazon EKS-Unterstützung in SageMaker HyperPod](sagemaker-hyperpod-eks-prerequisites.md)
+ [Installation von Paketen auf dem Amazon-EKS-Cluster mit Helm](sagemaker-hyperpod-eks-install-packages-using-helm-chart.md)
+ [Einrichten der rollenbasierten Zugriffskontrolle für Kubernetes](sagemaker-hyperpod-eks-setup-rbac.md)
+ [Benutzerdefinierte Amazon Machine Images (AMIs) für SageMaker HyperPod Cluster](hyperpod-custom-ami-support.md)
+ [Verwaltung von SageMaker HyperPod EKS-Clustern mithilfe der SageMaker Konsole](sagemaker-hyperpod-eks-operate-console-ui.md)
+ [SageMaker HyperPod Cluster mithilfe von CloudFormation Vorlagen erstellen](smcluster-getting-started-eks-console-create-cluster-cfn.md)
+ [Verwaltung von SageMaker HyperPod EKS-Clustern mit dem AWS CLI](sagemaker-hyperpod-eks-operate-cli-command.md)
+ [HyperPod verwaltetes mehrstufiges Checkpointing](managed-tier-checkpointing.md)
+ [SageMaker HyperPod Verwaltung von Aufgaben](sagemaker-hyperpod-eks-operate-console-ui-governance.md)
+ [Nutzungsberichte für die Kostenzuweisung in SageMaker HyperPod](sagemaker-hyperpod-usage-reporting.md)
+ [Konfiguration von Speicher für von Amazon EKS orchestrierte SageMaker HyperPod Cluster](sagemaker-hyperpod-eks-setup-storage.md)
+ [Verwenden des Amazon EBS CSI-Treibers auf SageMaker HyperPod EKS-Clustern](sagemaker-hyperpod-eks-ebs.md)
+ [Konfiguration benutzerdefinierter Kubernetes-Labels und -Taints in Amazon SageMaker HyperPod](sagemaker-hyperpod-eks-custom-labels-and-taints.md)
# Erste Schritte mit der Amazon EKS-Unterstützung in SageMaker HyperPod
Informieren Sie sich neben den allgemeinen Angaben [Voraussetzungen für die Verwendung SageMaker HyperPod](sagemaker-hyperpod-prerequisites.md) über die folgenden Anforderungen und Überlegungen zur Orchestrierung von SageMaker HyperPod Clustern mithilfe von Amazon EKS. SageMaker HyperPod
**Wichtig**
Sie können die Ressourcenkonfiguration für die Erstellung von SageMaker HyperPod Clustern mithilfe von AWS-Managementkonsole und CloudFormation einrichten. Weitere Informationen erhalten Sie unter [Erstellen eines SageMaker HyperPod Clusters mit Amazon EKS-Orchestrierung](sagemaker-hyperpod-eks-operate-console-ui-create-cluster.md) und [SageMaker HyperPod Cluster mithilfe von CloudFormation Vorlagen erstellen](smcluster-getting-started-eks-console-create-cluster-cfn.md).
**Voraussetzungen**
**Anmerkung**
Bevor Sie einen HyperPod Cluster erstellen, benötigen Sie einen laufenden Amazon EKS-Cluster, der mit VPC konfiguriert und mit Helm installiert wurde.
+ Wenn Sie die SageMaker AI-Konsole verwenden, können Sie auf der Cluster-Konsolenseite einen Amazon HyperPod EKS-Cluster erstellen. Weitere Informationen finden Sie unter [Erstellen eines SageMaker HyperPod Clusters mit Amazon EKS-Orchestrierung](sagemaker-hyperpod-eks-operate-console-ui-create-cluster.md).
+ Wenn Sie AWS CLI verwenden, sollten Sie einen Amazon EKS-Cluster erstellen, bevor Sie einen HyperPod Cluster erstellen, mit dem Sie eine Verbindung herstellen möchten. Weitere Informationen finden Sie unter [Erstellen eines Amazon-EKS-Clusters](https://docs.aws.amazon.com/eks/latest/userguide/create-cluster.html) im Benutzerhandbuch für Amazon EKS.
Beachten Sie bei der Bereitstellung Ihres Amazon-EKS-Clusters Folgendes:
1. **Support für Kubernetes-Version**
+ SageMaker HyperPod unterstützt die Kubernetes-Versionen 1.28, 1.29, 1.30, 1.31, 1.32, 1.33 und 1.34.
1. **Cluster-Authentifizierungsmodus von Amazon EKS**
+ Der Authentifizierungsmodus eines Amazon EKS-Clusters, der von unterstützt wird, SageMaker HyperPod sind `API` und`API_AND_CONFIG_MAP`.
1. **Netzwerkfunktionen**
+ SageMaker HyperPod erfordert das Amazon VPC Container Network Interface (CNI) -Plug-In Version 1.18.3 oder höher.
**Anmerkung**
AWS Das [VPC CNI-Plugin für Kubernetes](https://github.com/aws/amazon-vpc-cni-k8s) ist das einzige CNI, das von unterstützt wird. SageMaker HyperPod
+ Der [Typ des Subnetzes](https://docs.aws.amazon.com/vpc/latest/userguide/configure-subnets.html#subnet-types) in Ihrer VPC muss für HyperPod Cluster privat sein.
1. **IAM-Rollen**
+ Stellen Sie sicher, dass die erforderlichen IAM-Rollen für wie im Abschnitt beschrieben eingerichtet HyperPod sind. [AWS Identity and Access Management für SageMaker HyperPod](sagemaker-hyperpod-prerequisites-iam.md)
1. **Cluster-Add-ons von Amazon EKS**
+ Sie können die verschiedenen von Amazon EKS bereitgestellten Add-Ons wie [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), das [Amazon VPC Container Network Interface (CNI)](https://docs.aws.amazon.com/eks/latest/userguide/add-ons-vpc-cni.html) -Plugin, Amazon EKS-Pod-Identität, den GuardDuty Agenten, den Amazon FSx Container Storage Interface (CSI) -Treiber, den Mountpoint for Amazon S3 CSI-Treiber, den Distro for und den AWS Observability Agent weiterhin verwenden. OpenTelemetry CloudWatch
**Überlegungen zur Konfiguration von SageMaker HyperPod Clustern mit Amazon EKS**
+ Sie müssen je nach Art Ihrer Knoten unterschiedliche IAM-Rollen verwenden. Verwenden Sie für HyperPod Knoten eine Rolle, die auf basiert[IAM-Rolle für SageMaker HyperPod](sagemaker-hyperpod-prerequisites-iam.md#sagemaker-hyperpod-prerequisites-iam-role-for-hyperpod). Informationen zu Amazon-EKS-Knoten finden Sie unter [IAM-Rolle für Amazon-EKS-Knoten](https://docs.aws.amazon.com/eks/latest/userguide/create-node-role.html).
+ Sie können zusätzliche Amazon EBS-Volumes auf SageMaker HyperPod Knoten auf zwei Arten bereitstellen und mounten: [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)für die Volume-Bereitstellung auf Cluster-Ebene (verfügbar beim Erstellen oder Aktualisieren von Instance-Gruppen) oder den Amazon Elastic Block Store (Amazon EBS) Container Storage Interface (CSI) -Treiber für dynamisches Volume-Management auf Pod-Ebene. Stellen Sie mit [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)den [lokalen Pfad](https://kubernetes.io/docs/concepts/storage/volumes/#local) auf ein, `/opt/sagemaker` um die Volumes ordnungsgemäß in Ihre Amazon EKS-Pods einzubinden. Informationen zur Bereitstellung des [Amazon EBS CSI-Controllers](https://docs.aws.amazon.com/eks/latest/userguide/ebs-csi.html) auf HyperPod Knoten finden Sie unter[Verwenden des Amazon EBS CSI-Treibers auf SageMaker HyperPod EKS-Clustern](sagemaker-hyperpod-eks-ebs.md).
+ Wenn Sie Instance-Typ-Labels zur Definition von Scheduling-Einschränkungen verwenden, stellen Sie sicher, dass Sie die SageMaker AI ML-Instance-Typen mit dem Präfix verwenden. `ml.` Verwenden Sie beispielsweise für P5-Instances `ml.p5.48xlarge` anstelle von `p5.48xlarge`.
**Überlegungen zur Netzwerkkonfiguration für SageMaker HyperPod Cluster mit Amazon EKS**
+ Jede HyperPod Cluster-Instance unterstützt ein Elastic Network Interface (ENI). Die maximale Anzahl von Pods pro Instance-Typ finden Sie in der folgenden Tabelle.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/sagemaker/latest/dg/sagemaker-hyperpod-eks-prerequisites.html)
+ Standardmäßig haben nur Pods mit `hostNetwork = true` Zugriff auf den Amazon EC2 Instance Metadata Service (IMDS). Verwenden Sie die Amazon EKS-Pod-Identität oder die [IAM-Rollen für Dienstkonten (IRSA)](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html), um den Zugriff auf die AWS Anmeldeinformationen für Pods zu verwalten.
+ EKS-orchestrierte HyperPod Cluster unterstützen duale IP-Adressierungsmodi und ermöglichen so die Konfiguration mit IPv4 oder IPv6 für IPv6 Amazon EKS-Cluster in IPv6 -fähigen VPC- und Subnetzumgebungen. Weitere Informationen finden Sie unter [Einrichtung SageMaker HyperPod mit einer benutzerdefinierten Amazon VPC](sagemaker-hyperpod-prerequisites.md#sagemaker-hyperpod-prerequisites-optional-vpc).
**Überlegungen zur Verwendung der Cluster-Resilienzfunktionen HyperPod **
+ Die automatische Ersetzung von Knoten wird für CPU-Instances nicht unterstützt.
+ Der HyperPod Health Monitoring Agent muss installiert sein, damit die automatische Wiederherstellung des Knotens funktioniert. Der Agent kann mit Helm installiert werden. Weitere Informationen finden Sie unter [Installation von Paketen auf dem Amazon-EKS-Cluster mit Helm](sagemaker-hyperpod-eks-install-packages-using-helm-chart.md).
+ Der Agent zur HyperPod umfassenden Gesundheitsprüfung und Gesundheitsüberwachung unterstützt GPU- und Trn-Instanzen.
+ SageMaker KI wendet den folgenden Makel auf Knoten an, wenn sie tiefgreifenden Gesundheitschecks unterzogen werden:
```
effect: NoSchedule
key: sagemaker.amazonaws.com/node-health-status
value: Unschedulable
```
**Anmerkung**
Es ist nicht möglich, benutzerdefinierte Taints zu Knoten in Instance-Gruppen hinzuzufügen, bei denen `DeepHealthChecks` aktiviert ist.
Sobald Ihr Amazon EKS-Cluster läuft, konfigurieren Sie Ihren Cluster mit dem Helm-Paketmanager, wie unter beschrieben, [Installation von Paketen auf dem Amazon-EKS-Cluster mit Helm](sagemaker-hyperpod-eks-install-packages-using-helm-chart.md) bevor Sie Ihren HyperPod Cluster erstellen.
# Installation von Paketen auf dem Amazon-EKS-Cluster mit Helm
Bevor Sie einen SageMaker HyperPod Cluster erstellen und an einen Amazon EKS-Cluster anhängen, sollten Sie Pakete mit [Helm](https://helm.sh/), einem Paketmanager für Kubernetes, installieren. Helm ist ein Open-Source-Tool zum Einrichten eines Installationsprozesses für Kubernetes-Cluster. Es ermöglicht die Automatisierung und Rationalisierung von Abhängigkeitsinstallationen und vereinfacht verschiedene Setups, die für die Vorbereitung des Amazon EKS-Clusters als Orchestrator (Kontrollebene) für einen Cluster erforderlich sind. SageMaker HyperPod
Das SageMaker HyperPod Serviceteam stellt ein Helm-Chart-Paket bereit, das wichtige Abhängigkeiten wie device/EFA Plug-ins, Plug-ins, [Kubeflow Training Operator](https://www.kubeflow.org/docs/components/training/) und zugehörige Berechtigungskonfigurationen bündelt.
**Wichtig**
Dieser Helm-Installationsschritt ist erforderlich. Wenn Sie Ihren Amazon-EKS-Cluster mit der [AWS-Managementkonsole](sagemaker-hyperpod-eks-operate-console-ui-create-cluster.md) oder [CloudFormation](smcluster-getting-started-eks-console-create-cluster-cfn.md) einrichten, können Sie diesen Schritt überspringen, da die Installation während des Einrichtungsvorgangs automatisch durchgeführt wird. Wenn Sie den Cluster direkt mit dem einrichten APIs, verwenden Sie das bereitgestellte Helm-Diagramm, um Ihren Amazon EKS-Cluster zu konfigurieren. Wenn Sie Ihren Amazon EKS-Cluster nicht mithilfe des bereitgestellten Helm-Diagramms konfigurieren, kann dies dazu führen, dass der SageMaker HyperPod Cluster nicht richtig funktioniert oder der Erstellungsprozess vollständig fehlschlägt. Der `aws-hyperpod`-Namespace-Name kann nicht geändert werden.
1. [Installieren Sie Helm](https://helm.sh/docs/intro/install/) auf Ihrem lokalen Computer.
1. Laden Sie die Helm-Charts herunter, die SageMaker HyperPod sich unter `helm_chart/HyperPodHelmChart` im [SageMaker HyperPod CLI-Repository](https://github.com/aws/sagemaker-hyperpod-cli/tree/main/helm_chart) befinden.
```
git clone https://github.com/aws/sagemaker-hyperpod-cli.git
cd sagemaker-hyperpod-cli/helm_chart
```
1. Aktualisieren Sie die Abhängigkeiten des Helm-Charts, überprüfen Sie die Änderungen, die an Ihrem Kubernetes-Cluster vorgenommen werden, und installieren Sie das Helm-Chart.
```
helm dependencies update HyperPodHelmChart
```
```
helm install hyperpod-dependencies HyperPodHelmChart --namespace kube-system --dry-run
```
```
helm install hyperpod-dependencies HyperPodHelmChart --namespace kube-system
```
Zusammenfassend lässt sich sagen, dass die Helm-Installation verschiedene Komponenten für Ihren Amazon EKS-Cluster einrichtet, darunter Job Scheduling and Queueing (Kueue), Speicherverwaltung, MLflow Integration und Kubeflow. Darüber hinaus werden in den Diagrammen die folgenden Komponenten für die Integration in die SageMaker HyperPod Cluster-Resilienzfunktionen installiert, bei denen es sich um erforderliche Komponenten handelt.
+ **Health Monitoring Agent** — Dadurch wird der Health Monitoring Agent installiert, der von bereitgestellt wird. SageMaker HyperPod Dies ist erforderlich, wenn Sie möchten, dass Ihr HyperPod Cluster überwacht wird. Agent für die Zustandsüberwachung werden wie folgt als Docker-Images bereitgestellt. Im bereitgestellten `values.yaml` in den Helm-Charts ist das Image voreingestellt. Der Agent unterstützt GPU-basierte Instanzen und Trainium-accelerator-based Instanzen (`trn1`,`trn1n`,`inf2`). Er ist im `aws-hyperpod`-Namespace installiert. Ihre unterstützte URI finden Sie unter [Unterstützte Regionen und deren ECR URIs im sagemaker-hyperpod-cli Repository](https://github.com/aws/sagemaker-hyperpod-cli/blob/main/helm_chart/readme.md#6-notes) unter. GitHub
+ **Deep Health Check** — Dadurch werden a`ClusterRole`, a ServiceAccount (`deep-health-check-service-account`) im `aws-hyperpod` Namespace und a eingerichtet, `ClusterRoleBinding` um die SageMaker HyperPod Deep Health Check-Funktion zu aktivieren. Weitere Informationen zur Kubernetes-RBAC-Datei für den Deep Health Check finden Sie in der Konfigurationsdatei [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)im CLI-Repository. SageMaker HyperPod GitHub
+ **`job-auto-restart`**- Dadurch werden a`ClusterRole`, a ServiceAccount (`job-auto-restart`) im `aws-hyperpod` Namespace und a, eingerichtet`ClusterRoleBinding`, um die automatische Neustartfunktion für PyTorch Trainingsjobs in zu aktivieren. SageMaker HyperPod Weitere Informationen zur Kubernetes-RBAC-Datei für `job-auto-restart` finden Sie in der Konfigurationsdatei [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)im CLI-Repository. SageMaker HyperPod GitHub
+ **Kubeflow MPI Operator**: Der MPI Operator ist ein Kubernetes Operator, der die Ausführung verteilter Machine Learning (ML)- und High-Performance Computing (HPC)-Workloads unter Verwendung der Message Passing Interface (MPI) auf Kubernetes-Clustern vereinfacht. Er installiert MPI Operator v0.5. Er ist im `mpi-operator`-Namespace installiert.
+ **`nvidia-device-plugin`**— Dies ist ein Kubernetes-Geräte-Plug-in, mit dem Sie NVIDIA automatisch GPUs für die Nutzung durch Container in Ihrem Amazon EKS-Cluster verfügbar machen können. Es ermöglicht Kubernetes, den für diesen Container angeforderten Container zuzuweisen und Zugriff darauf bereitzustellen. GPUs Erforderlich, wenn ein Instance-Typ mit GPU verwendet wird.
+ **`neuron-device-plugin`** – dies ist ein Kubernetes-Geräte-Plugin, mit dem Sie AWS -Inferentia-Chips automatisch für die Nutzung durch Container in Ihrem Amazon-EKS-Cluster verfügbar machen können. Es ermöglicht Kubernetes, auf die AWS Inferentia-Chips auf den Clusterknoten zuzugreifen und diese zu nutzen. Erforderlich, wenn ein Neuron-Instance-Typ verwendet wird.
+ **`aws-efa-k8s-device-plugin`**— Dies ist ein Kubernetes-Geräte-Plug-in, das die Verwendung des AWS Elastic Fabric Adapter (EFA) auf Amazon EKS-Clustern ermöglicht. EFA ist ein Netzwerkgerät, das Kommunikation mit niedriger Latenz und hohem Durchsatz zwischen Instances in einem Cluster ermöglicht. Erforderlich, wenn ein von EFA unterstützter Instance-Typ verwendet wird.
Weitere Informationen zum Installationsverfahren mithilfe der bereitgestellten Helm-Diagramme finden Sie in der [README-Datei im SageMaker HyperPod CLI-Repository](https://github.com/aws/sagemaker-hyperpod-cli/tree/main/helm_chart).
# Einrichten der rollenbasierten Zugriffskontrolle für Kubernetes
Cluster-Administratoren müssen außerdem die [rollenbasierte Zugriffskontrolle (RBAC) von Kubernetes](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) einrichten, damit Data-Scientist-Benutzer die [SageMaker HyperPod CLI](https://github.com/aws/sagemaker-hyperpod-cli) verwenden können, um Workloads auf Clustern auszuführen, die mit Amazon EKS orchestriert wurden. HyperPod
## Option 1: RBAC mithilfe von Helm-Chart einrichten
Das SageMaker HyperPod Serviceteam stellt ein Helm-Subdiagramm für die Einrichtung von RBAC zur Verfügung. Weitere Informationen hierzu finden Sie unter [Installation von Paketen auf dem Amazon-EKS-Cluster mit Helm](sagemaker-hyperpod-eks-install-packages-using-helm-chart.md).
## Option 2: RBAC manuell einrichten
Erstellen Sie `ClusterRole` und `ClusterRoleBinding` mit den Mindestberechtigungen und erstellen Sie `Role` und `RoleBinding` mit Mutationsberechtigungen.
**So erstellen Sie `ClusterRole` & `ClusterRoleBinding` für die IAM-Rolle für Datenwissenschaftler**
Erstellen Sie eine Konfigurationsdatei `cluster_level_config.yaml` auf Clusterebene wie folgt.
```
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
```
Wenden Sie die Konfiguration auf den EKS-Cluster an.
```
kubectl apply -f cluster_level_config.yaml
```
**Um eine Rolle und einen Namespace zu erstellen RoleBinding **
Dies ist der Namespace-Trainingsoperator, der Trainingsjobs ausführt und von Resiliency standardmäßig überwacht wird. Die automatische Wiederaufnahme von Aufträgen kann nur im `kubeflow`-Namespace oder im Namespace mit dem Präfix `aws-hyperpod` unterstützt werden.
Erstellen Sie eine Rollenkonfigurationsdatei `namespace_level_role.yaml` wie folgt. In diesem Beispiel wird eine Rolle mit dem Namespace `kubeflow` erstellt.
```
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
```
Wenden Sie die Konfiguration auf den EKS-Cluster an.
```
kubectl apply -f namespace_level_role.yaml
```
## Erstellen eines Zugriffseintrags mit Kubernetes-Gruppen
Nachdem Sie RBAC mithilfe einer der beiden oben genannten Optionen eingerichtet haben, verwenden Sie bitte den folgenden Beispielbefehl und ersetzen Sie die erforderlichen Informationen.
```
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"]'
```
Für den `principal-arn`-Parameter müssen Sie [IAM-Benutzer für Wissenschaftler](sagemaker-hyperpod-prerequisites-iam.md#sagemaker-hyperpod-prerequisites-iam-cluster-user) verwenden.
# Benutzerdefinierte Amazon Machine Images (AMIs) für SageMaker HyperPod Cluster
Mithilfe von Amazon Machine Images (AMIs), die von Amazon bereitgestellt und veröffentlicht wurden SageMaker HyperPod, können Sie benutzerdefinierte Images erstellen AMIs. Mit einem benutzerdefinierten AMI können Sie spezielle Umgebungen für KI-Workloads mit vorkonfigurierten Software-Stacks, Treiberanpassungen, proprietären Abhängigkeiten und Sicherheitsagenten erstellen. Diese Funktion macht komplexes Bootstrapping nach dem Start mithilfe von Skripten zur Lebenszykluskonfiguration überflüssig.
Mit Custom AMIs können Sie Umgebungen über verschiedene Phasen hinweg standardisieren, die Startzeiten beschleunigen und die volle Kontrolle über Ihre Laufzeitumgebung haben, während Sie gleichzeitig die Infrastrukturfunktionen und Skalierungsvorteile nutzen SageMaker HyperPod. Auf diese Weise behalten Sie die Kontrolle über Ihre KI-Infrastruktur und profitieren gleichzeitig von der optimierten SageMaker HyperPod Basislaufzeit.
Sie können auf den SageMaker HyperPod leistungsoptimierten Basis-Images aufbauen, indem Sie Sicherheitsagenten, Compliance-Tools und Spezialbibliotheken hinzufügen und gleichzeitig alle Vorteile der verteilten Schulungen beibehalten. Durch diese Funktion entfällt die bisher erforderliche Wahl zwischen Infrastrukturoptimierung und organisatorischen Sicherheitsrichtlinien.
Das maßgeschneiderte AMI-Erlebnis lässt sich nahtlos in etablierte Sicherheitsworkflows von Unternehmen integrieren. Sicherheitsteams erstellen sichere Images, indem sie die öffentliche Version AMIs als Basis verwenden SageMaker HyperPod. KI-Plattformteams können diese AMIs bei der Erstellung oder Aktualisierung von Clustern über die benutzerdefiniert angeben. SageMaker HyperPod APIs APIs Sie überprüfen die Image-Kompatibilität, kümmern sich um die erforderlichen Berechtigungen und wahren die Abwärtskompatibilität, sodass bestehende Workflows weiterhin funktionieren. Unternehmen mit strengen Sicherheitsprotokollen können die fehleranfällige Alternative der Installation von Sicherheitsagenten zur Laufzeit durch Lebenszyklusskripte vermeiden. Durch die Anpassung an die Sicherheitspraktiken von Unternehmen, anstatt Unternehmen zu zwingen, ihre Protokolle an SageMaker HyperPod die Einschränkungen anzupassen, wird ein gängiges Hindernis für die Einführung sicherheitsbewusster Unternehmen, die kritische KI-Workloads ausführen, AMIs beseitigt.
Veröffentlichungshinweise zu Updates für die Öffentlichkeit finden Sie unter. AMIs [Öffentliche AMI-Veröffentlichungen](sagemaker-hyperpod-release-public-ami.md) In den folgenden Themen erfahren Sie, wie Sie mit dem Erstellen eines benutzerdefinierten AMI und dessen Verwendung in Ihren HyperPod Clustern beginnen können.
**Topics**
+ [Erstellen einer benutzerdefinierten AMI](hyperpod-custom-ami-how-to.md)
+ [Clusterverwaltung mit benutzerdefiniertem AMIs](hyperpod-custom-ami-cluster-management.md)
# Erstellen einer benutzerdefinierten AMI
Auf der folgenden Seite wird erklärt, wie Sie mithilfe von Amazon SageMaker HyperPod Base ein benutzerdefiniertes Amazon Machine Image (AMI) erstellen AMIs. Sie wählen zunächst einen Basis-AMI aus und erstellen dann Ihren eigenen benutzerdefinierten AMI mit einer der gängigen Methoden zum Erstellen neuer Images, z. B. AWS CLI.
## Wählen Sie ein SageMaker HyperPod Basis-AMI
Sie können ein SageMaker HyperPod Basis-AMI mit einer der folgenden Methoden auswählen.
### AWS Auswahl der Konsole
Sie können SageMaker HyperPod AMIs über die AWS Konsole oder mithilfe des `DescribeImages` API-Aufrufs „Öffentlich“ auswählen. SageMaker HyperPod AMIs sind öffentlich und in jedem sichtbar AWS-Konto. Sie finden sie im Amazon EC2 AMI-Katalog, indem Sie einen Filter anwenden, um nach öffentlichen AMIs Eigentum von Amazon zu suchen.
SageMaker HyperPod AMIs In der Konsole finden Sie:
1. Melden Sie sich bei der Amazon-EC2-Konsole an.
1. Wählen Sie im linken Navigationsbereich die Option **AMIs** aus.
1. Wählen Sie in der Dropdown-Liste **Image-Typ** die Option **Öffentliche Images** aus.
1. Stellen Sie in den Suchleistenfiltern den Filter **Eigentümer-Alias** auf **amazon** ein.
1. Suchen Sie nach dem AMIs Präfix **HyperPodEKS** und wählen Sie das AMI (vorzugsweise das neueste) aus, das für Ihren Anwendungsfall geeignet ist. Sie können beispielsweise ein AMI zwischen Kubernetes 1.31 und Kubernetes 1.30 auswählen.
### Rufen Sie die neueste öffentliche AMI-ID ab über AWS CLI
Wenn Sie immer das neueste öffentliche AMI verwenden möchten, ist es effizienter, den öffentlichen SageMaker HyperPod SSM-Parameter zu verwenden, der den Wert der letzten AMI-ID enthält, die von SageMaker HyperPod veröffentlicht wurde.
Das folgende Beispiel zeigt, wie Sie die neueste AMI-ID über die AWS CLI abrufen:
```
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
```
**Anmerkung**
Ersetzen Sie den Parameternamen nach Bedarf durch die entsprechende Kubernetes-Version. Wenn Sie beispielsweise Kubernetes 1.30 verwenden möchten, verwenden Sie den folgenden Parameter: `/aws/service/hyperpod/ami/x86_64/eks-1.30-amazon-linux-2/latest/ami-id`
## Erstellen Ihrer benutzerdefinierten AMI
Nachdem Sie ein SageMaker HyperPod öffentliches AMI ausgewählt haben, verwenden Sie dieses als Basis-AMI, um Ihr eigenes benutzerdefiniertes AMI mit einer der folgenden Methoden zu erstellen. Beachten Sie, dass dies keine vollständige Liste für die Erstellung AMIs ist. Sie können jede Methode Ihrer Wahl zum Bauen AMIs verwenden. SageMaker HyperPod hat keine spezifische Empfehlung.
+ **AWS Managementkonsole**: Sie können eine Amazon EC2 EC2-Instance mithilfe des SageMaker HyperPod AMI starten, die gewünschten Anpassungen vornehmen und dann aus dieser Instance ein AMI erstellen.
+ **AWS CLI**: Sie können den `aws ec2 create-image`-Befehl auch verwenden, um nach der Anpassung eines AMI aus einer vorhandenen Amazon-EC2-Instance zu erstellen.
+ **HashiCorp Packer**: Packer ist ein Open-Source-Tool von HashiCorp , mit dem Sie identische Maschinen-Images für mehrere Plattformen aus einer einzigen Quellkonfiguration erstellen können. Es unterstützt sowohl die Erstellung von Bildern AMIs für AWS andere Cloud-Anbieter und Virtualisierungsplattformen als auch für diese.
+ **Image Builder**: EC2 Image Builder ist ein vollständig verwalteter AWS -Service, der die Automatisierung der Erstellung, Wartung, Validierung, Freigabe und Bereitstellung von Linux- oder Windows Server-Images vereinfacht. Weitere Informationen finden Sie im [Benutzerhandbuch von EC2 Image Builder](https://docs.aws.amazon.com/imagebuilder/latest/userguide/what-is-image-builder.html).
### Erstellen Sie ein benutzerdefiniertes AMI mit vom Kunden verwalteter AWS KMS Verschlüsselung
In den folgenden Abschnitten wird beschrieben, wie Sie ein benutzerdefiniertes AMI mit einem vom Kunden verwalteten AWS KMS Schlüssel zur Verschlüsselung Ihrer HyperPod Cluster-Volumes erstellen. Weitere Informationen zu vom Kunden verwalteten Schlüsseln HyperPod und zur Gewährung der erforderlichen IAM- und KMS-Schlüsselrichtlinienberechtigungen finden Sie unter. [Vom Kunden verwaltete Verschlüsselung für AWS KMS key SageMaker HyperPod](smcluster-cmk.md) Wenn Sie beabsichtigen, ein benutzerdefiniertes AMI zu verwenden, das mit einem vom Kunden verwalteten Schlüssel verschlüsselt ist, stellen Sie sicher, dass Sie auch das Amazon EBS-Root-Volume Ihres HyperPod Clusters mit demselben Schlüssel verschlüsseln.
#### AWS CLI Beispiel: Erstellen Sie ein neues AMI mit EC2 Image Builder und einem HyperPod Basis-Image
Im folgenden Beispiel sehen Sie, wie Sie ein AMI mit Image Builder mit AWS KMS -Verschlüsselung erstellen:
```
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}
```
#### Amazon-EC2-Konsole: ein neues AMI aus einem Amazon EC2 erstellen
So erstellen Sie eine AMI aus einer Amazon-EC2-Instance mithilfe der Amazon-EC2-Konsole:
1. Klicken Sie mit der rechten Maustaste auf Ihre benutzerdefinierte Amazon-EC2-Instance und wählen Sie **Image erstellen** aus.
1. Wählen Sie im Abschnitt **Verschlüsselung** die Option **Snapshots verschlüsseln** aus.
1. Wählen Sie Ihren KMS-Schlüssel aus dem Dropdown-Menü aus. Zum Beispiel: `arn:aws:kms:us-east-2:111122223333:key/` oder verwenden Sie den Schlüsselalias: `alias/`
#### AWS CLI Beispiel: Erstellen Sie ein neues AMI aus einer Amazon EC2 EC2-Instance
Verwenden Sie den `aws ec2 create-image`-Befehl mit AWS KMS -Verschlüsselung:
```
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"
}
}
]'
```
# Clusterverwaltung mit benutzerdefiniertem AMIs
Nachdem das benutzerdefinierte AMI erstellt wurde, können Sie es zum Erstellen oder Aktualisieren eines SageMaker HyperPod Amazon-Clusters verwenden. Sie können auch Instance-Gruppen, die das neue AMI verwenden, skalieren oder hinzufügen.
## Für Cluster-Operationen erforderliche Berechtigungen
Fügen Sie dem Cluster-Admin-Benutzer, der Cluster betreibt und konfiguriert SageMaker HyperPod , die folgenden Berechtigungen hinzu. Das folgende Richtlinienbeispiel enthält die Mindestberechtigungen für Clusteradministratoren, um den SageMaker HyperPod Kern auszuführen APIs und SageMaker HyperPod Cluster mit benutzerdefiniertem AMI zu verwalten.
Beachten Sie, dass die Berechtigungen für die Freigabe von AMI- und AMI-EBS-Snapshots über `ModifyImageAttribute`- und `ModifySnapshotAttribute`-API-Berechtigungen als Teil der folgenden Richtlinie enthalten sind. Um die Freigabeberechtigungen einzuschränken, können Sie die folgenden Schritte ausführen:
+ Fügen Sie Tags hinzu, um die AMI-Freigabeberechtigungen für AMI und AMI-Snapshots zu verwalten. Sie können das AMI beispielsweise mit `AllowSharing` als `true` markieren.
+ Fügen Sie der Richtlinie den Kontextschlüssel hinzu, um die AMI-Sharing nur für Personen zuzulassen, die mit bestimmten Tags AMIs gekennzeichnet sind.
Bei der folgenden Richtlinie handelt es sich um eine Richtlinie mit eingeschränktem Geltungsbereich, mit der sichergestellt werden soll, dass nur mit „`AllowSharing`als“ AMIs markierte Elemente zulässig `true` sind.
------
#### [ 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"
}
}
}
]
}
```
------
**Wichtig**
Wenn Sie beabsichtigen, ein verschlüsseltes benutzerdefiniertes AMI zu verwenden, stellen Sie sicher, dass Ihr KMS-Schlüssel die unter [Vom Kunden verwaltete Verschlüsselung für AWS KMS key SageMaker HyperPod](smcluster-cmk.md) beschriebenen Berechtigungen erfüllt. Stellen Sie außerdem sicher, dass der KMS-Schlüssel Ihrer benutzerdefinierten AMI auch zur Verschlüsselung des Amazon EBS-Root-Volumes Ihres Clusters verwendet wird.
## Erstellen eines Clusters
Sie können Ihr benutzerdefiniertes AMI im `ImageId`-Feld für die `CreateCluster`-Operation angeben.
Die folgenden Beispiele zeigen, wie Sie einen Cluster mit einem benutzerdefinierten AMI erstellen, sowohl mit als auch ohne einen vom AWS KMS Kunden verwalteten Schlüssel zur Verschlüsselung der Cluster-Volumes.
------
#### [ Standard example ]
Das folgende Beispiel zeigt, wie ein Cluster mit einer benutzerdefinierten AMI erstellt wird.
```
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 ]
Das folgende Beispiel zeigt, wie Sie einen Cluster mit einem benutzerdefinierten AMI erstellen und dabei Ihren eigenen, vom AWS KMS Kunden verwalteten Schlüssel für die Verschlüsselung der Amazon EBS-Volumes des Clusters angeben. Es ist möglich, unterschiedliche vom Kunden verwaltete Schlüssel für das Root-Volume und das Instance-Speichervolume anzugeben. Wenn Sie vor `InstanceStorageConfigs` Ort keine vom Kunden verwalteten Schlüssel verwenden, wird ein AWS eigener KMS-Schlüssel zur Verschlüsselung der Volumes verwendet. Wenn Sie unterschiedliche Schlüssel für das Root-Volume und das sekundäre Instance-Speichervolume verwenden, legen Sie die erforderlichen KMS-Schlüsselrichtlinien für Ihre beiden Schlüssel fest.
```
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": [""]
}'
```
------
## Aktualisieren der Cluster-Software
Wenn Sie eine bestehende Instance-Gruppe auf Ihrem Cluster mit Ihrem benutzerdefinierten AMI aktualisieren möchten, können Sie die `UpdateClusterSoftware`-Operation verwenden und Ihr benutzerdefiniertes AMI im `ImageId`-Feld angeben. Beachten Sie, dass das neue Image auf alle Instance-Gruppen in Ihrem Cluster angewendet wird, sofern Sie in Ihrer Anfrage nicht den Namen einer bestimmten Instance-Gruppe angeben.
Im folgenden Beispiel sehen Sie, wie Sie die Plattformsoftware eines Clusters mit einem benutzerdefinierten AMI aktualisieren:
```
aws sagemaker update-cluster-software \
--cluster-name \
--instance-groups \
--image-id
```
## Skalieren einer Instance-Gruppe
Die folgenden Beispiele zeigen, wie Sie eine Instanzgruppe für einen Cluster mithilfe eines benutzerdefinierten AMI skalieren können, sowohl mit als auch ohne Verwendung eines vom AWS KMS Kunden verwalteten Schlüssels für die Verschlüsselung.
------
#### [ Standard example ]
Im folgenden Beispiel wird gezeigt, wie eine Instance-Gruppe mit einem benutzerdefinierten AMI hochskaliert wird.
```
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 ]
Das folgende Beispiel zeigt, wie Sie Ihren Cluster mit einem benutzerdefinierten AMI aktualisieren und skalieren und dabei Ihren eigenen, vom AWS KMS Kunden verwalteten Schlüssel für die Verschlüsselung der Amazon EBS-Volumes des Clusters angeben. Es ist möglich, unterschiedliche vom Kunden verwaltete Schlüssel für das Root-Volume und das Instance-Speichervolume anzugeben. Wenn Sie vor `InstanceStorageConfigs` Ort keine vom Kunden verwalteten Schlüssel verwenden, wird ein AWS eigener KMS-Schlüssel zur Verschlüsselung der Volumes verwendet. Wenn Sie unterschiedliche Schlüssel für das Root-Volume und das sekundäre Instance-Speichervolume verwenden, legen Sie die erforderlichen KMS-Schlüsselrichtlinien für Ihre beiden Schlüssel fest.
```
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"
}
}
]
}]'
```
------
## Hinzufügen einer Instance-Gruppe
Das folgende Beispiel veranschaulicht, wie eine Instance-Gruppe mithilfe eines benutzerdefinierten AMI zu einem Cluster hinzugefügt wird:
```
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": ""
}'
```
# Verwaltung von SageMaker HyperPod EKS-Clustern mithilfe der SageMaker Konsole
Die folgenden Themen enthalten Anleitungen zur Verwaltung SageMaker HyperPod in der SageMaker AI-Konsole.
**Topics**
+ [Erstellen eines SageMaker HyperPod Clusters mit Amazon EKS-Orchestrierung](sagemaker-hyperpod-eks-operate-console-ui-create-cluster.md)
+ [SageMaker HyperPod Cluster durchsuchen, anzeigen und bearbeiten](sagemaker-hyperpod-eks-operate-console-ui-browse-view-edit.md)
+ [Einen SageMaker HyperPod Cluster löschen](sagemaker-hyperpod-eks-operate-console-ui-delete-cluster.md)
# Erstellen eines SageMaker HyperPod Clusters mit Amazon EKS-Orchestrierung
Das folgende Tutorial zeigt, wie Sie einen neuen SageMaker HyperPod Cluster erstellen und ihn mit Amazon EKS-Orchestrierung über die Benutzeroberfläche der SageMaker KI-Konsole einrichten.
**Topics**
+ [Cluster erstellen](#smcluster-getting-started-eks-console-create-cluster-page)
+ [Bereitstellen von Ressourcen](#smcluster-getting-started-eks-console-create-cluster-deploy)
## Cluster erstellen
Gehen Sie wie folgt vor, um zur **SageMaker HyperPod Cluster-Seite** zu navigieren und Amazon EKS-Orchestration auszuwählen.
1. Öffnen Sie die Amazon SageMaker AI-Konsole unter [https://console.aws.amazon.com/sagemaker/](https://console.aws.amazon.com/sagemaker/).
1. Wählen Sie im linken Navigationsbereich **HyperPod Clusters** und dann **Cluster Management** aus.
1. Wählen Sie auf der Seite **SageMaker HyperPod Cluster** die Option ** HyperPod Cluster erstellen** aus.
1. Wählen **Sie im Drop-down-Menü HyperPod Cluster erstellen** die Option **Orchestrated by Amazon EKS** aus.
1. Auf der Seite zur Erstellung eines EKS-Clusters sehen Sie zwei Optionen. Wählen Sie die Option aus, die Ihren Anforderungen am besten entspricht.
1. **Quick Setup**: Um sofort mit den Standardeinstellungen zu beginnen, wählen Sie **Quick Setup** aus. Mit dieser Option erstellt SageMaker KI bei der Erstellung Ihres Clusters neue Ressourcen wie VPC, Subnetze, Sicherheitsgruppen, Amazon S3 S3-Bucket, IAM-Rolle und FSx für Lustre.
1. **Benutzerdefinierte Einrichtung**: Um eine Integration mit vorhandenen Ressourcen vorzunehmen oder bestimmte Anforderungen hinsichtlich Netzwerk, Sicherheit oder Speicher zu erfüllen, wählen Sie **Benutzerdefinierte Einrichtung** aus. Mit dieser Option können Sie wählen, ob Sie die vorhandenen Ressourcen verwenden oder neue erstellen möchten, und Sie können die Konfiguration an Ihre Bedürfnisse anpassen.
## Quick Setup
Gehen Sie im Abschnitt **Schnelleinrichtung** wie folgt vor, um Ihren HyperPod Cluster mit Amazon EKS-Orchestrierung zu erstellen.
### Allgemeine Einstellungen
Geben Sie einen Namen für den neuen Cluster ein. Sie können den Namen nicht ändern, nachdem der Cluster erstellt wurde.
### Instance-Gruppen
Um eine Instance-Gruppe hinzuzufügen, wählen Sie **Gruppe hinzufügen** aus. Jede Instance-Gruppe kann anders konfiguriert werden und Sie können einen heterogenen Cluster erstellen, der aus mehreren Instance-Gruppen mit verschiedenen Instance-Typen besteht. Um einen Cluster bereitzustellen, müssen Sie mindestens eine Instance-Gruppe hinzufügen. Gehen Sie folgendermaßen vor, um eine Instance-Gruppe hinzuzufügen.
1. Wählen Sie als **Instance-Gruppentyp** **Standard** oder **Restricted Instance Group (RIG)** aus. Normalerweise wählen Sie **Standard**, denn es bietet eine allgemeine Datenverarbeitungsumgebung ohne zusätzliche Sicherheitseinschränkungen. **Restricted Instance Group (RIG)** ist eine spezialisierte Umgebung für die Anpassung von Grundlagenmodellen wie Amazon Nova. Weitere Informationen zur Einrichtung von RIG für die Amazon Nova-Modellanpassung finden Sie unter Amazon Nova-Anpassung SageMaker HyperPod im [Amazon Nova 1.0-Benutzerhandbuch](https://docs.aws.amazon.com//nova/latest/userguide/nova-hp.html) oder im [Amazon Nova 2.0-Benutzerhandbuch](https://docs.aws.amazon.com//nova/latest/nova2-userguide/nova-hp.html).
1. Geben Sie unter **Name** einen Namen für die Instance-Gruppe an.
1. Wählen Sie als **Instance-Kapazität** entweder On-Demand-Kapazität oder einen Trainingsplan aus, um Ihre Datenverarbeitungsressourcen zu reservieren.
1. Wählen Sie unter **Instance-Typ** die Instance für die Instance-Gruppe aus.
**Wichtig**
Stellen Sie sicher, dass Sie einen Instance-Typ mit ausreichenden Kontingenten und ausreichend nicht zugewiesenen IP-Adressen für Ihr Konto auswählen. Informationen zum Anzeigen oder Anfordern zusätzlicher Kontingente finden Sie unter [SageMaker HyperPod Kontingente](sagemaker-hyperpod-prerequisites.md#sagemaker-hyperpod-prerequisites-quotas).
1. Geben Sie unter **Instance-Anzahl** eine Ganzzahl an, die das Instance-Kontingent für die Cluster-Nutzung nicht überschreitet. Für dieses Tutorial geben Sie **1** für alle drei Gruppen ein.
1. Wählen Sie als **Ziel-Availability-Zone** die Availability Zone aus, in der Ihre Instances bereitgestellt werden. Die Availability Zone sollte dem Standort Ihrer beschleunigten Datenverarbeitungskapazität entsprechen.
1. Geben Sie unter **Zusätzliches Speichervolumen pro Instance (GB) – optional** eine Ganzzahl zwischen 1 und 16 384 an, um die Größe eines zusätzlichen Elastic Book Store (EBS)-Volume in Gigabyte (GB) festzulegen. Das EBS-Volume ist an jede Instance der Instance-Gruppe angefügt. Der Standard-Bereitstellungspfad für das zusätzliche EBS-Volume ist `/opt/sagemaker`. Nachdem der Cluster erfolgreich erstellt wurde, können Sie per SSH auf die Cluster-Instances (Knoten) zugreifen und überprüfen, ob das EBS-Volume korrekt gemountet wurde, indem Sie den `df -h`-Befehl ausführen. Durch das Anfügen eines zusätzlichen EBS-Volumes wird stabiler, Instance-unabhängiger persistenter Speicher bereitgestellt, wie im Abschnitt [Amazon-EBS-Volumes](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-volumes.html) im *Benutzerhandbuch für Amazon Elastic Block Store* beschrieben.
1. Wählen Sie unter **Detaillierte Instance-Zustandsprüfungen** die gewünschte Option aus. Detaillierte Zustandsprüfungen überwachen den Zustand der Instances während der Erstellung und nach Softwareupdates und stellen fehlerhafte Instances automatisch durch Neustarts oder Austausch, sofern aktiviert, wieder her.
1. Wenn Ihr Instance-Typ die GPU-Partitionierung mit Multi-Instance-GPU (MIG) unterstützt, können Sie die GPU-Partitionskonfiguration für die Instance-Gruppe aktivieren. Die GPU-Partitionierung ermöglicht Ihnen die GPUs Aufteilung in kleinere, isolierte Partitionen, um die Ressourcennutzung zu verbessern. Weitere Informationen finden Sie unter [Verwenden von GPU-Partitionen in Amazon SageMaker HyperPod](sagemaker-hyperpod-eks-gpu-partitioning.md).
1. Aktivieren **Sie die Option GPU-Partitionierung verwenden**, um die GPU-Partitionierung für diese Instanzgruppe zu aktivieren.
1. Wählen Sie ein **GPU-Partitionsprofil** aus den verfügbaren Optionen für Ihren Instanztyp aus. Jedes Profil definiert die GPU-Slice-Konfiguration und die Speicherzuweisung.
1. Wählen Sie **Instance-Gruppe hinzufügen** aus.
### Quick Setup – Standardwerte
In diesem Abschnitt sind alle Standardeinstellungen für die Clustererstellung aufgeführt, einschließlich aller neuen AWS Ressourcen, die während der Clustererstellung erstellt werden. Überprüfen Sie die Standardeinstellungen.
## Benutzerdefinierte Einrichtung
Gehen Sie im Abschnitt **Benutzerdefiniertes Setup** wie folgt vor, um Ihren ersten HyperPod Cluster mit Amazon EKS-Orchestrierung zu erstellen.
### Allgemeine Einstellungen
Geben Sie einen Namen für den neuen Cluster ein. Sie können den Namen nicht ändern, nachdem der Cluster erstellt wurde.
Wählen Sie für die **Instance-Wiederherstellung** **Automatisch – *empfohlen*** oder **Keine**.
### Netzwerk
Konfigurieren Sie die Netzwerkeinstellungen innerhalb des Clusters und in-and-out des Clusters. Für die Orchestrierung des SageMaker HyperPod Clusters mit Amazon EKS wird die VPC automatisch auf die VPC eingestellt, die mit dem von Ihnen ausgewählten EKS-Cluster konfiguriert wurde.
1. Wählen Sie für **VPC** Ihre eigene VPC aus, falls Sie bereits eine haben, die SageMaker KI Zugriff auf Ihre VPC gewährt. Um eine neue VPC zu erstellen, folgen Sie den Anweisungen unter [Erstellen einer VPC](https://docs.aws.amazon.com/vpc/latest/userguide/create-vpc.html) im *Benutzerhandbuch für Amazon Virtual Private Cloud*. Sie können es auf **None** belassen, um die standardmäßige SageMaker KI-VPC zu verwenden.
1. Geben Sie für den **VPC IPv4 CIDR-Block** die Start-IP Ihrer VPC ein.
1. Wählen Sie für **Availability Zones** die Availability Zones (AZ) aus, in denen Subnetze für HyperPod Ihren Cluster erstellt werden sollen. Wählen Sie AZs diese aus, die dem Standort Ihrer beschleunigten Rechenkapazität entsprechen.
1. Wählen Sie für **Sicherheitsgruppe(n)** Sicherheitsgruppen aus, die entweder mit dem Amazon-EKS-Cluster verbunden sind oder deren eingehender Datenverkehr von der mit dem Amazon-EKS-Cluster verbundenen Sicherheitsgruppe zugelassen wird. Um neue Sicherheitsgruppen zu erstellen, öffnen Sie die Amazon-VPC-Konsole.
### Orchestrierung
Gehen Sie wie folgt vor, um einen Amazon-EKS-Cluster zu erstellen oder auszuwählen, der als Orchestrator verwendet werden soll.
1. Für den **EKS-Cluster** haben Sie die Wahl, entweder einen neuen Amazon-EKS-Cluster zu erstellen oder einen bestehenden zu verwenden.
Wenn Sie einen neuen EKS-Cluster erstellen müssen, können Sie ihn im EKS-Cluster-Bereich erstellen, ohne die Amazon-EKS-Konsole öffnen zu müssen.
**Anmerkung**
Das VPC-Subnetz, für das Sie sich entscheiden, HyperPod muss privat sein.
Nachdem Sie eine neue Anfrage zur Erstellung eines EKS-Clusters eingereicht haben, warten Sie, bis der EKS-Cluster `Active` wird.
1. Wählen Sie für die **Kubernetes-Version** eine Version aus dem Dropdown-Menü aus. Weitere Informationen zu Kubernetes-Versionen finden Sie unter [Verständnis des Kubernetes-Versionslebenszyklus auf EKS](https://docs.aws.amazon.com//eks/latest/userguide/kubernetes-versions.html) im *Benutzerhandbuch für Amazon EKS*.
1. Wählen Sie für **Operatoren** die Option **Standard-Helm-Charts und -Add-ons verwenden** oder **Keine Operatoren installieren** aus. Die Option ist standardmäßig auf **Standard-Helm-Charts und -Add-ons verwenden** eingestellt, die zur Installation von Operatoren auf dem EKS-Cluster verwendet werden. Weitere Informationen zu den standardmäßigen Helm-Charts und -Add-Ons finden Sie im [https://github.com/aws/sagemaker-hyperpod-cli/tree/main/helm_chart/HyperPodHelmChart](https://github.com/aws/sagemaker-hyperpod-cli/tree/main/helm_chart/HyperPodHelmChart) GitHubRepository. Weitere Informationen finden Sie unter [Installation von Paketen auf dem Amazon-EKS-Cluster mit Helm](sagemaker-hyperpod-eks-install-packages-using-helm-chart.md).
1. Informationen zu **aktivierten Operatoren** finden Sie in der Liste der aktivierten Operatoren. Um die Operatoren zu bearbeiten, deaktivieren Sie das Kontrollkästchen oben und wählen Sie Operatoren aus, die für den EKS-Cluster aktiviert werden sollen.
**Anmerkung**
Für die Verwendung HyperPod mit EKS müssen Sie Helm-Diagramme und Add-Ons installieren, die Operatoren auf dem EKS-Cluster aktivieren. Diese Komponenten konfigurieren EKS als Steuerungsebene für das Workload-Management HyperPod und die Orchestrierung und bieten das erforderliche Setup dafür.
### Instance-Gruppen
Um eine Instance-Gruppe hinzuzufügen, wählen Sie **Gruppe hinzufügen** aus. Jede Instance-Gruppe kann anders konfiguriert werden und Sie können einen heterogenen Cluster erstellen, der aus mehreren Instance-Gruppen mit verschiedenen Instance-Typen besteht. Um einen Cluster bereitzustellen, müssen Sie mindestens eine Instance-Gruppe hinzufügen. Gehen Sie folgendermaßen vor, um eine Instance-Gruppe hinzuzufügen.
1. Wählen Sie als **Instance-Gruppentyp** **Standard** oder **Restricted Instance Group (RIG)** aus. Normalerweise wählen Sie **Standard**, denn es bietet eine allgemeine Datenverarbeitungsumgebung ohne zusätzliche Sicherheitseinschränkungen. **Restricted Instance Group (RIG)** ist eine spezialisierte Umgebung für die Anpassung von Grundlagenmodellen wie Amazon Nova. Weitere Informationen zur Einrichtung von RIG für die Amazon Nova-Modellanpassung finden Sie unter Amazon Nova-Anpassung SageMaker HyperPod im [Amazon Nova 1.0-Benutzerhandbuch](https://docs.aws.amazon.com//nova/latest/userguide/nova-hp.html) oder im [Amazon Nova 2.0-Benutzerhandbuch](https://docs.aws.amazon.com//nova/latest/nova2-userguide/nova-hp.html).
1. Geben Sie unter **Name** einen Namen für die Instance-Gruppe an.
1. Wählen Sie als **Instance-Kapazität** entweder On-Demand-Kapazität oder einen Trainingsplan aus, um Ihre Datenverarbeitungsressourcen zu reservieren.
1. Wählen Sie unter **Instance-Typ** die Instance für die Instance-Gruppe aus.
**Wichtig**
Stellen Sie sicher, dass Sie einen Instance-Typ mit ausreichenden Kontingenten und ausreichend nicht zugewiesenen IP-Adressen für Ihr Konto auswählen. Informationen zum Anzeigen oder Anfordern zusätzlicher Kontingente finden Sie unter [SageMaker HyperPod Kontingente](sagemaker-hyperpod-prerequisites.md#sagemaker-hyperpod-prerequisites-quotas).
1. Geben Sie unter **Instance-Anzahl** eine Ganzzahl an, die das Instance-Kontingent für die Cluster-Nutzung nicht überschreitet. Für dieses Tutorial geben Sie **1** für alle drei Gruppen ein.
1. Wählen Sie als **Ziel-Availability-Zone** die Availability Zone aus, in der Ihre Instances bereitgestellt werden. Die Availability Zone sollte dem Standort Ihrer beschleunigten Datenverarbeitungskapazität entsprechen.
1. Geben Sie unter **Zusätzliches Speichervolumen pro Instance (GB) – optional** eine Ganzzahl zwischen 1 und 16 384 an, um die Größe eines zusätzlichen Elastic Book Store (EBS)-Volume in Gigabyte (GB) festzulegen. Das EBS-Volume ist an jede Instance der Instance-Gruppe angefügt. Der Standard-Bereitstellungspfad für das zusätzliche EBS-Volume ist `/opt/sagemaker`. Nachdem der Cluster erfolgreich erstellt wurde, können Sie per SSH auf die Cluster-Instances (Knoten) zugreifen und überprüfen, ob das EBS-Volume korrekt gemountet wurde, indem Sie den `df -h`-Befehl ausführen. Durch das Anfügen eines zusätzlichen EBS-Volumes wird stabiler, Instance-unabhängiger persistenter Speicher bereitgestellt, wie im Abschnitt [Amazon-EBS-Volumes](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-volumes.html) im *Benutzerhandbuch für Amazon Elastic Block Store* beschrieben.
1. Wählen Sie unter **Detaillierte Instance-Zustandsprüfungen** die gewünschte Option aus. Detaillierte Zustandsprüfungen überwachen den Zustand der Instances während der Erstellung und nach Softwareupdates und stellen fehlerhafte Instances automatisch durch Neustarts oder Austausch, sofern aktiviert, wieder her. Weitere Informationen hierzu finden Sie unter [Tiefgreifende Zustandsprüfungen](sagemaker-hyperpod-eks-resiliency-deep-health-checks.md).
1. Wenn Ihr Instance-Typ die **GPU-Partitionierung** mit Multi-Instance-GPU (MIG) unterstützt, können Sie diese Option aktivieren, um das GPU-Partitionsprofil für die Instanzgruppe zu konfigurieren. Die GPU-Partitionierung ermöglicht Ihnen die GPUs Aufteilung in kleinere, isolierte Partitionen, um die Ressourcennutzung zu verbessern. Weitere Informationen finden Sie unter [Verwenden von GPU-Partitionen in Amazon SageMaker HyperPod](sagemaker-hyperpod-eks-gpu-partitioning.md).
1. Aktivieren **Sie die Option GPU-Partitionierung verwenden**, um die GPU-Partitionierung für diese Instanzgruppe zu aktivieren.
1. Wählen Sie ein **GPU-Partitionsprofil** aus den verfügbaren Optionen für Ihren Instanztyp aus. Jedes Profil definiert die GPU-Slice-Konfiguration und die Speicherzuweisung.
1. Wählen Sie **Instance-Gruppe hinzufügen** aus.
### Lebenszyklusskripte
Sie können zwischen den Standard-Lebenszyklusskripten und den benutzerdefinierten Lebenszyklusskripten wählen, die in Ihrem Amazon-S3-Bucket gespeichert werden. Sie können die standardmäßigen Lebenszyklusskripte im [Awesome Distributed GitHub Training-Repository](https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/7.sagemaker-hyperpod-eks/LifecycleScripts) einsehen. Weitere Informationen zu den Lebenszyklusskripten finden Sie unter [Anpassen von SageMaker HyperPod Clustern mithilfe von Lifecycle-Skripten](sagemaker-hyperpod-lifecycle-best-practices-slurm.md).
1. Wählen Sie für **Lebenszyklusskripte**, ob Sie standardmäßige oder benutzerdefinierte Lebenszyklusskripte verwenden möchten.
1. Wählen Sie für **S3-Bucket für Lebenszyklusskripte**, ob Sie einen neuen Bucket erstellen oder einen vorhandenen Bucket zum Speichern der Lebenszyklusskripten verwenden möchten.
### Berechtigungen
Wählen oder erstellen Sie eine IAM-Rolle, mit der Sie die erforderlichen AWS Ressourcen in Ihrem Namen ausführen und darauf zugreifen können HyperPod . Weitere Informationen finden Sie unter [IAM-Rolle für SageMaker HyperPod](sagemaker-hyperpod-prerequisites-iam.md#sagemaker-hyperpod-prerequisites-iam-role-for-hyperpod).
### Speicher
Konfigurieren Sie das FSx for Lustre-Dateisystem, das auf dem Cluster bereitgestellt werden soll. HyperPod
1. Wählen Sie für **Dateisystem** ein vorhandenes FSx for Lustre-Dateisystem aus, um ein neues FSx for Lustre-Dateisystem zu erstellen, oder stellen Sie kein FSx for Lustre-Dateisystem bereit.
1. Wählen Sie für **Durchsatz pro Speichereinheit** den Durchsatz aus, der pro TiB bereitgestellten Speichers verfügbar sein soll.
1. Geben Sie für **Speicherkapazität** einen Kapazitätswert in TB ein.
1. Wählen Sie als **Datenkomprimierungstyp** die Option **LZ4**Datenkomprimierung aktivieren.
1. Sehen Sie sich für die **Lustre-Version** den Wert an, der für die neuen Dateisysteme empfohlen wird.
### Tags – optional
Fügen Sie **unter Tags — *optional*** Schlüssel- und Wertepaare zum neuen Cluster hinzu und verwalten Sie den Cluster als AWS Ressource. Weitere Informationen finden Sie unter [Markieren Ihrer AWS -Ressourcen](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html).
## Bereitstellen von Ressourcen
Nachdem Sie die Clusterkonfigurationen entweder mit **Quick Setup** oder **Benutzerdefinierte Einrichtung** abgeschlossen haben, wählen Sie die folgende Option aus, um mit der Ressourcenbereitstellung und Clustererstellung zu beginnen.
+ **Absenden** — Die SageMaker KI beginnt mit der Bereitstellung der Standardkonfigurationsressourcen und der Erstellung des Clusters.
+ ** CloudFormation Vorlagenparameter herunterladen** — Sie laden die JSON-Datei mit den Konfigurationsparametern herunter und führen einen AWS CLI Befehl aus, um den CloudFormation Stack bereitzustellen, um die Konfigurationsressourcen bereitzustellen und den Cluster zu erstellen. Sie können die heruntergeladene Parameter-JSON-Datei bei Bedarf bearbeiten. Wenn Sie diese Option auswählen, finden Sie weitere Anweisungen unter [SageMaker HyperPod Cluster mithilfe von CloudFormation Vorlagen erstellen](smcluster-getting-started-eks-console-create-cluster-cfn.md).
# SageMaker HyperPod Cluster durchsuchen, anzeigen und bearbeiten
Verwenden Sie die folgenden Anweisungen, um von Amazon EKS orchestrierte SageMaker HyperPod Cluster in der SageMaker AI-Konsole zu durchsuchen, anzuzeigen und zu bearbeiten.
**Topics**
+ [Um Ihre SageMaker HyperPod Cluster zu durchsuchen](#sagemaker-hyperpod-eks-operate-console-ui-browse-clusters)
+ [Um Details zu den einzelnen SageMaker HyperPod Clustern anzuzeigen](#sagemaker-hyperpod-eks-operate-console-ui-view-details-of-clusters)
+ [Um einen SageMaker HyperPod Cluster zu bearbeiten](#sagemaker-hyperpod-eks-operate-console-ui-edit-clusters)
## Um Ihre SageMaker HyperPod Cluster zu durchsuchen
Unter **Cluster** auf der SageMaker HyperPod Seite in der SageMaker AI-Konsole sollten alle erstellten Cluster im Abschnitt **Cluster** aufgeführt werden, der eine Zusammenfassung der Cluster ARNs, ihres Status und der Erstellungszeit bietet.
## Um Details zu den einzelnen SageMaker HyperPod Clustern anzuzeigen
Unter **Cluster** auf der SageMaker HyperPod Seite in der SageMaker AI-Konsole sind die Clusternamen als Links aktiviert. Wählen Sie den Link zum Clusternamen aus, um Details zu den einzelnen Clustern anzuzeigen.
## Um einen SageMaker HyperPod Cluster zu bearbeiten
1. Wählen Sie im Hauptbereich der SageMaker HyperPod Konsole unter **Cluster** den Cluster aus, den Sie aktualisieren möchten.
1. Wählen Sie Ihren Cluster aus und klicken Sie auf **Bearbeiten**.
1. Auf der Seite ** bearbeiten** können Sie die Konfigurationen bestehender Instance-Gruppen bearbeiten, weitere Instance-Gruppen hinzufügen, Instance-Gruppen löschen und Tags für den Cluster ändern. Nachdem Sie die Änderungen vorgenommen haben, wählen Sie **Absenden** aus.
1. Im Abschnitt **Instance-Gruppen konfigurieren** können Sie weitere Instance-Gruppen hinzufügen, indem Sie **Instance-Gruppe erstellen** auswählen.
1. Im Abschnitt **Instance-Gruppen konfigurieren** können Sie **Bearbeiten** auswählen, um die Konfiguration zu ändern, oder **Löschen**, um die Instance-Gruppe dauerhaft zu entfernen.
**Wichtig**
Berücksichtigen Sie beim Löschen einer Instance-Gruppe die folgenden Punkte:
Ihr SageMaker HyperPod Cluster muss immer mindestens eine Instanzgruppe verwalten.
Stellen Sie sicher, dass alle wichtigen Daten gesichert sind, bevor Sie sie entfernen.
Die Entfernung kann nicht rückgängig gemacht werden.
**Anmerkung**
Durch das Löschen einer Instance-Gruppe werden alle mit dieser Gruppe verknüpften Rechenressourcen beendet.
1. Im Abschnitt **Tags** können Sie die Tags für den Cluster aktualisieren.
# Einen SageMaker HyperPod Cluster löschen
Verwenden Sie die folgenden Anweisungen, um von Amazon EKS orchestrierte SageMaker HyperPod Cluster in der SageMaker AI-Konsole zu löschen.
1. Wählen Sie im Hauptbereich der SageMaker HyperPod Konsole unter **Cluster** den Cluster aus, den Sie löschen möchten.
1. Wählen Sie Ihren Cluster aus und klicken Sie auf **Löschen**.
1. Überprüfen Sie im Popup-Fenster für das Löschen von Clustern die Clusterinformationen sorgfältig, um sicherzustellen, dass Sie den richtigen Cluster zum Löschen ausgewählt haben.
1. Nachdem Sie die Clusterinformationen überprüft haben, wählen Sie **Ja, Cluster löschen** aus.
1. Geben Sie im Textfeld zur Bestätigung dieser Löschung **delete** ein.
1. Wählen Sie in der unteren rechten Ecke des Popup-Fensters **Löschen** aus, um das Senden der Anfrage zum Löschen des Clusters abzuschließen.
**Anmerkung**
Wenn das Löschen des Clusters aufgrund angehängter SageMaker HyperPod Task-Governance-Richtlinien fehlschlägt, müssen Sie dies tun[Löschen von Richtlinien](sagemaker-hyperpod-eks-operate-console-ui-governance-policies-delete.md).
# SageMaker HyperPod Cluster mithilfe von CloudFormation Vorlagen erstellen
Sie können SageMaker HyperPod Cluster mithilfe der CloudFormation Vorlagen für erstellen HyperPod. Sie müssen installieren AWS CLI , um fortzufahren.
**Topics**
+ [Konfigurieren Sie Ressourcen in der Konsole und stellen Sie sie bereit mit CloudFormation](#smcluster-getting-started-eks-console-create-cluster-deploy-console)
+ [Konfigurieren und implementieren Sie Ressourcen mit CloudFormation](#smcluster-getting-started-eks-console-create-cluster-deploy-cfn)
## Konfigurieren Sie Ressourcen in der Konsole und stellen Sie sie bereit mit CloudFormation
Sie können Ressourcen mithilfe der konfigurieren AWS-Managementkonsole und mithilfe der CloudFormation Vorlagen bereitstellen.
Dazu gehen Sie wie folgt vor:
1. *Anstatt auf **Senden zu klicken***, wählen Sie am Ende des Tutorials unter die Option ** CloudFormation Vorlagenparameter herunterladen** aus[Erste Schritte mit der SageMaker HyperPod Verwendung der SageMaker KI-Konsole](smcluster-getting-started-slurm-console.md). Das Tutorial enthält wichtige Konfigurationsinformationen, die Sie benötigen, um Ihren Cluster erfolgreich zu erstellen.
**Wichtig**
Wenn Sie **Absenden** auswählen, können Sie einen Cluster mit demselben Namen erst bereitstellen, wenn Sie den Cluster löschen.
Nachdem Sie die Option ** CloudFormation Vorlagenparameter herunterladen** ausgewählt haben, wird **das Fenster Verwenden der Konfigurationsdatei zur Erstellung des AWS CLI Clusters mithilfe** des Fensters auf der rechten Seite angezeigt.
1. Wählen Sie im Fenster **Verwenden der Konfigurationsdatei zum Erstellen des Clusters unter Verwendung der AWS CLI** die Option **Konfigurationsparameter-Datei herunterladen** aus. Die Datei wird auf Ihren Computer heruntergeladen. Sie können die JSON-Konfigurationsdatei nach Ihren Bedürfnissen bearbeiten oder sie unverändert lassen, wenn keine Änderung erforderlich ist.
1. Navigieren Sie in einem Terminalfenster zum Speicherort der Parameterdatei `file://params.json`.
1. Führen Sie den AWS CLI Befehl [create-stack](https://docs.aws.amazon.com//cli/latest/reference/cloudformation/create-stack.html) aus, um den CloudFormation Stack bereitzustellen, der die konfigurierten Ressourcen bereitstellt und den HyperPod Cluster erstellt.
```
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. [Um den Status der Ressourcenbereitstellung einzusehen, navigieren Sie zur Konsole. CloudFormation ](https://console.aws.amazon.com/cloudformation)
Nachdem die Clustererstellung abgeschlossen ist, sehen Sie sich den neuen **Cluster unter Cluster** im Hauptbereich der SageMaker HyperPod Konsole an. Sie können den Status in der Spalte **Status** überprüfen.
1. Wenn der Status des Clusters zu `InService` wechselt, können Sie mit der Anmeldung bei den Clusterknoten beginnen. Informationen zum Zugriff auf die Clusterknoten und zum Starten der Ausführung von ML-Workloads finden Sie unter [Jobs auf Clustern SageMaker HyperPod](sagemaker-hyperpod-run-jobs-slurm.md).
## Konfigurieren und implementieren Sie Ressourcen mit CloudFormation
Sie können Ressourcen mithilfe der CloudFormation Vorlagen für konfigurieren und bereitstellen SageMaker HyperPod.
Dazu gehen Sie wie folgt vor:
1. Laden Sie eine CloudFormation Vorlage für SageMaker HyperPod aus dem [sagemaker-hyperpod-cluster-setup](https://github.com/aws/sagemaker-hyperpod-cluster-setup) GitHub Repository herunter.
1. Führen Sie den AWS CLI Befehl [create-stack](https://docs.aws.amazon.com//cli/latest/reference/cloudformation/create-stack.html) aus, um den CloudFormation Stack bereitzustellen, der die konfigurierten Ressourcen bereitstellt und den HyperPod Cluster erstellt.
```
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. Um den Status der Ressourcenbereitstellung einzusehen, navigieren Sie zur CloudFormation -Konsole.
Nachdem die Clustererstellung abgeschlossen ist, sehen Sie sich den neuen **Cluster unter Cluster** im Hauptbereich der SageMaker HyperPod Konsole an. Sie können den Status in der Spalte **Status** überprüfen.
1. Wenn der Status des Clusters zu `InService` wechselt, können Sie mit der Anmeldung bei den Clusterknoten beginnen.
# Verwaltung von SageMaker HyperPod EKS-Clustern mit dem AWS CLI
Die folgenden Themen enthalten Anleitungen zum Schreiben von SageMaker HyperPod API-Anforderungsdateien im JSON-Format und zum Ausführen dieser Dateien mithilfe der AWS CLI Befehle.
**Topics**
+ [Einen SageMaker HyperPod Cluster erstellen](sagemaker-hyperpod-eks-operate-cli-command-create-cluster.md)
+ [Clusterdetails werden abgerufen SageMaker HyperPod](sagemaker-hyperpod-eks-operate-cli-command-cluster-details.md)
+ [Die SageMaker HyperPod Cluster-Konfiguration wird aktualisiert](sagemaker-hyperpod-eks-operate-cli-command-update-cluster.md)
+ [Aktualisierung der SageMaker HyperPod Plattformsoftware](sagemaker-hyperpod-eks-operate-cli-command-update-cluster-software.md)
+ [Zugreifen auf SageMaker HyperPod Clusterknoten](sagemaker-hyperpod-eks-operate-access-through-terminal.md)
+ [Einen SageMaker HyperPod Cluster herunterskalieren](smcluster-scale-down.md)
+ [Löschen eines Clusters SageMaker HyperPod](sagemaker-hyperpod-eks-operate-cli-command-delete-cluster.md)
# Einen SageMaker HyperPod Cluster erstellen
Erfahren Sie, wie Sie von Amazon EKS orchestrierte SageMaker HyperPod Cluster mithilfe der AWS CLI erstellen.
1. Bevor Sie einen SageMaker HyperPod Cluster erstellen:
1. Stellen Sie sicher, dass Sie über einen bestehenden Amazon-EKS-Cluster verfügen, der betriebsbereit ist. Detaillierte Anweisungen zur Einrichtung eines Amazon-EKS-Clusters finden Sie unter [Erstellen eines Amazon-EKS-Clusters](https://docs.aws.amazon.com/eks/latest/userguide/create-cluster.html) im *Benutzerhandbuch für Amazon EKS*.
1. Installieren Sie das Helm-Chart wie unter [Installation von Paketen auf dem Amazon-EKS-Cluster mit Helm](sagemaker-hyperpod-eks-install-packages-using-helm-chart.md) beschrieben. Wenn Sie einen [Amazon SageMaker HyperPod Nova-Cluster](https://docs.aws.amazon.com//nova/latest/nova2-userguide/nova-hp-cluster.html) erstellen, benötigen Sie ein separates Helm-Diagramm.
1. Bereiten Sie ein Skript zur Lebenszykluskonfiguration vor und laden Sie sie in einen Amazon-S3-Bucket hoch, z. B. `s3://amzn-s3-demo-bucket/Lifecycle-scripts/base-config/`.
Laden Sie für einen schnellen Start das Beispielskript [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)aus dem AWS ome Distributed Training GitHub Repository herunter und laden Sie es in den S3-Bucket hoch. Sie können auch zusätzliche Setup-Anweisungen, eine Reihe von Setup-Skripten oder Befehle hinzufügen, die während der HyperPod Cluster-Bereitstellungsphase ausgeführt werden sollen.
**Wichtig**
Wenn Sie [IAM-Rolle für SageMaker HyperPod](sagemaker-hyperpod-prerequisites-iam.md#sagemaker-hyperpod-prerequisites-iam-role-for-hyperpod) erstellen und nur die verwaltete [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) anfügen, hat Ihr Cluster Zugriff auf Amazon-S3-Buckets mit dem spezifischen Präfix `sagemaker-`.
Wenn Sie eine eingeschränkte Instances erstellen, müssen Sie das Lebenszyklusskript nicht herunterladen und ausführen. Stattdessen müssen Sie `install_rig_dependencies.sh` ausführen.
Zu den Voraussetzungen für die Ausführung des `install_rig_dependencies.sh`-Skripts gehören:
+ AWS Node (CNI) und CoreDNS sollten beide aktiviert sein. Dies sind Standard-EKS-Add-Ons, die nicht vom SageMaker HyperPod Standard-Helm verwaltet werden, aber einfach in der EKS-Konsole unter Add-Ons aktiviert werden können.
+ Das SageMaker HyperPod Standard-Helm-Diagramm sollte installiert werden, bevor dieses Skript ausgeführt wird.
Das `install_rig_dependencies.sh`-Skript führt die folgenden Aktionen aus.
+ `aws-node` (CNI): Neues `rig-aws-node` Daemonset wurde erstellt; vorhandenes `aws-node` wurde gepatcht, um RIG-Knoten zu vermeiden.
+ `coredns`: In Daemonset konvertiert, um die Verwendung mehrerer RIGs RIGs zu unterstützen und eine Überlastung zu verhindern.
+ training-operators: Aktualisiert mit RIG Worker-Taint-Toleranzen und nodeAffinity, die Nicht-RIG-Instances bevorzugen.
+ Elastic Fabric Adapter (EFA): Aktualisiert, um RIG-Worker-Taint zu tolerieren und für jede Region die richtigen Container-Images zu verwenden.
1. Bereiten Sie eine [CreateCluster](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_CreateCluster.html)API-Anforderungsdatei im JSON-Format vor. Geben Sie für `ExecutionRole` den ARN der IAM-Rolle an, die Sie mit der verwalteten `AmazonSageMakerClusterInstanceRolePolicy` aus Abschnitt [IAM-Rolle für SageMaker HyperPod](sagemaker-hyperpod-prerequisites-iam.md#sagemaker-hyperpod-prerequisites-iam-role-for-hyperpod) erstellt haben.
**Anmerkung**
Stellen Sie sicher, dass Ihr SageMaker HyperPod Cluster in derselben Virtual Private Cloud (VPC) wie Ihr Amazon EKS-Cluster bereitgestellt wird. Die in der SageMaker HyperPod Cluster-Konfiguration angegebenen Subnetze und Sicherheitsgruppen müssen Netzwerkkonnektivität und Kommunikation mit dem API-Serverendpunkt des Amazon EKS-Clusters ermöglichen.
```
// 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"
}
```
Beachten Sie bei der Konfiguration zur Erstellung eines neuen SageMaker HyperPod Clusters, der einem EKS-Cluster zugeordnet ist, Folgendes.
+ Sie können bis zu 20 Instance-Gruppen unter dem Parameter konfigurieren. `InstanceGroups`
+ Geben Sie für `Orchestator.Eks.ClusterArn` die ARN des EKS-Clusters an, den Sie als Orchestrator verwenden möchten.
+ Für`OnStartDeepHealthChecks`, hinzufügen `InstanceStress` und `InstanceConnectivity` aktivieren[Tiefgreifende Zustandsprüfungen](sagemaker-hyperpod-eks-resiliency-deep-health-checks.md).
+ Geben Sie für an`NodeRecovery`, ob `Automatic` die automatische Knotenwiederherstellung aktiviert werden soll. SageMaker HyperPod ersetzt Instanzen (Knoten) oder startet sie neu, wenn der Health Monitoring Agent Probleme feststellt.
+ Für den `Tags` Parameter können Sie benutzerdefinierte Tags hinzufügen, um den SageMaker HyperPod Cluster als Ressource zu verwalten. AWS Sie können Ihrem Cluster auf die gleiche Weise Tags hinzufügen, wie Sie sie in anderen AWS -Services hinzufügen, die das Markieren unterstützen. Weitere Informationen zum Markieren von AWS -Ressourcen im Allgemeinen finden Sie im [Benutzerhandbuch zur Markierung von AWS -Ressourcen](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html).
+ Geben Sie für den `VpcConfig`-Parameter die Informationen der im EKS-Cluster verwendeten VPC an. Die Subnetze müssen privat sein.
+ Für `Orchestrator.Eks.KubernetesConfig.Labels` können Sie optional Kubernetes-Labels angeben, die auf die Knoten angewendet werden sollen. Um die GPU-Partitionierung mit Multi-Instance-GPU (MIG) zu aktivieren, fügen Sie das `nvidia.com/mig.config` Label mit dem gewünschten MIG-Profil hinzu. `"nvidia.com/mig.config": "all-3g.40gb"`Konfiguriert beispielsweise alle GPUs mit dem 3G.40GB-Partitionsprofil. Weitere Informationen zur GPU-Partitionierung und zu verfügbaren Profilen finden Sie unter. [Verwenden von GPU-Partitionen in Amazon SageMaker HyperPod](sagemaker-hyperpod-eks-gpu-partitioning.md)
1. Führen Sie den Befehl [create-cluster](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/create-cluster.html) aus, um den Cluster zu erstellen.
**Wichtig**
Wenn Sie den `create-cluster`-Befehl mit dem Parameter `--cli-input-json` ausführen, müssen Sie das Präfix `file://` vor dem vollständigen Pfad zur JSON-Datei angeben. Dieses Präfix ist erforderlich, um sicherzustellen, dass der die Eingabe als Dateipfad AWS CLI erkennt. Das Weglassen des Präfixes `file://` führt zu einem Parsing-Parameterfehler.
```
aws sagemaker create-cluster \
--cli-input-json file://complete/path/to/create_cluster.json
```
Dies sollte den ARN des neuen Clusters zurückgeben.
**Wichtig**
Sie können den Vorgang „[Cluster aktualisieren](https://docs.aws.amazon.com//cli/latest/reference/ecs/update-cluster.html)“ verwenden, um eine eingeschränkte Instance-Gruppe (RIG) zu entfernen. Wenn ein RIG auf 0 herunterskaliert wird, wird das FSx for Lustre-Dateisystem nicht gelöscht. Um das FSx for Lustre-Dateisystem vollständig zu entfernen, müssen Sie das RIG vollständig entfernen.
Durch das Entfernen eines RIGs werden keine Artefakte gelöscht, die im vom Dienst verwalteten Amazon-S3-Bucket gespeichert sind. Sie sollten jedoch sicherstellen, dass alle Artefakte im FSx for Lustre-Dateisystem vollständig mit Amazon S3 synchronisiert sind, bevor Sie sie entfernen. Wir empfehlen, nach Abschluss des Auftrags mindestens 30 Minuten zu warten, um die vollständige Synchronisation aller Artefakte aus dem FSx for Lustre-Dateisystem mit dem service-verwalteten Amazon S3 S3-Bucket sicherzustellen.
**Wichtig**
Wenn Sie eine Onboard-On-Demand-Kapazitätsreservierung (ODCR) verwenden, müssen Sie Ihre Instance-Gruppe derselben Availability Zone ID (AZ ID) wie die ODCR zuordnen, indem Sie sie `OverrideVpcConfig` mit einem Subnetz in der entsprechenden AZ-ID festlegen.
WICHTIG: Überprüfen Sie die `OverrideVpcConfig` Konfiguration vor der Bereitstellung, um zu vermeiden, dass doppelte Gebühren sowohl für ODCR als auch für On-Demand-Kapazität anfallen.
# Clusterdetails werden abgerufen SageMaker HyperPod
Erfahren Sie, wie Sie SageMaker HyperPod Clusterdetails mithilfe der abrufen AWS CLI.
## Beschreiben eines Clusters
Führen Sie [describe-cluster](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/describe-cluster.html) aus, um den Status des Clusters zu prüfen. Sie können entweder den Namen oder den ARN des Clusters angeben.
```
aws sagemaker describe-cluster --cluster-name your-hyperpod-cluster
```
Nachdem der Status des Clusters auf **InService** geändert wurde, fahren Sie mit dem nächsten Schritt fort. Mit dieser API können Sie auch Fehlermeldungen aus anderen HyperPod API-Vorgängen abrufen.
## Listet die Details der Clusterknoten auf
Führen Sie aus [list-cluster-nodes](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/list-cluster-nodes.html), um die wichtigsten Informationen der Clusterknoten zu überprüfen.
```
aws sagemaker list-cluster-nodes --cluster-name your-hyperpod-cluster
```
Dies gibt eine Antwort zurück und Ihre Cluster-Benutzer benötigen `InstanceId` für die Protokollierung (Verwendung von `aws ssm`) in ihnen.
## Beschreiben der Details eines Cluster-Knotens
Ausführen [describe-cluster-node](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/describe-cluster-node.html), um Details eines Clusterknotens abzurufen. Sie können die Clusterknoten-ID aus der list-cluster-nodes Ausgabe abrufen. Sie können entweder den Namen oder den ARN des Clusters angeben.
```
aws sagemaker describe-cluster-node \
--cluster-name your-hyperpod-cluster \
--node-id i-111222333444555aa
```
## Auflisten von Clustern
Führen Sie [list-clusters](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/list-clusters.html) aus, um alle Cluster in Ihrem Konto aufzulisten.
```
aws sagemaker list-clusters
```
Sie können auch zusätzliche Flags hinzufügen, um die Liste der Cluster zu filtern. Weitere Informationen darüber, wie dieser Befehl auf niedriger Ebene ausgeführt wird, und weitere Flags zum Filtern finden Sie in der [ListClusters](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_ListClusters.html)API-Referenz.
# Die SageMaker HyperPod Cluster-Konfiguration wird aktualisiert
Führen Sie [update-cluster](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/update-cluster.html) aus, um die Konfiguration eines Clusters zu aktualisieren.
**Anmerkung**
Wichtige Überlegungen:
Sie können die EKS-Clusterinformationen, denen Ihr HyperPod Cluster zugeordnet ist, nach der Erstellung des Clusters nicht ändern.
Wenn auf dem Cluster umfassende Zustandsprüfungen durchgeführt werden, funktioniert diese API nicht wie erwartet. Möglicherweise wird eine Fehlermeldung angezeigt, dass derzeit umfassende Zustandsprüfungen durchgeführt werden. Um den Cluster zu aktualisieren, sollten Sie warten, bis die umfassenden Zustandsprüfungen abgeschlossen sind.
1. Erstellen Sie eine [https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_UpdateCluster.html](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_UpdateCluster.html)-Anforderungsdatei im JSON-Format. Stellen Sie sicher, dass Sie den richtigen Clusternamen und Instance-Gruppennamen für die Aktualisierung angeben. Für jede Instance-Gruppe können Sie den Instance-Typ, die Anzahl der Instances, das Einstiegsskript für die Lebenszykluskonfiguration und den Pfad zum Skript ändern.
**Anmerkung**
Sie können den verwenden`UpdateCluster`, um ganze Instanzgruppen herunterzuskalieren oder ganze Instanzgruppen aus Ihrem SageMaker HyperPod Cluster zu entfernen. Weitere Anweisungen zum Herunterskalieren oder Löschen von Instance-Gruppen finden Sie unter [Einen SageMaker HyperPod Cluster herunterskalieren](smcluster-scale-down.md).
1. Geben Sie für `ClusterName` den Namen des Clusters an, den Sie aktualisieren möchten.
1. Für `InstanceGroupName`
1. Um eine bestehende Instance-Gruppe zu aktualisieren, geben Sie den Namen der Instance-Gruppe an, die Sie aktualisieren möchten.
1. Um eine neue Instance-Gruppe hinzuzufügen, geben Sie einen neuen Namen an, der in Ihrem Cluster nicht vorhanden ist.
1. Für `InstanceType`
1. Um eine bestehende Instance-Gruppe zu aktualisieren, müssen Sie den Instance-Typ, den Sie ursprünglich angegeben haben, der Gruppe zuordnen.
1. Um eine neue Instance-Gruppe hinzuzufügen, geben Sie einen Instance-Typ an, mit dem Sie die Gruppe konfigurieren möchten.
1. Für `InstanceCount`
1. Um eine bestehende Instance-Gruppe zu aktualisieren, geben Sie eine Ganzzahl an, die der gewünschten Anzahl von Instances entspricht. Sie können einen höheren oder niedrigeren Wert (bis 0) angeben, um die Instance-Gruppe herauf- oder herunterskalieren.
1. Um eine neue Instance-Gruppe hinzuzufügen, geben Sie eine Ganzzahl größer oder gleich 1 an.
1. Denn `LifeCycleConfig` Sie können die Werte für beide ändern `SourceS3Uri` und `OnCreate` wenn Sie die Instance-Gruppe aktualisieren möchten.
1. Für `ExecutionRole`
1. Verwenden Sie zum Aktualisieren einer vorhandenen Instance-Gruppe weiterhin dieselbe IAM-Rolle, die Sie bei der Clustererstellung zugewiesen haben.
1. Um eine neue Instance-Gruppe hinzuzufügen, geben Sie eine IAM-Rolle an, die Sie anfügen möchten.
1. Für `ThreadsPerCore`
1. Verwenden Sie zum Aktualisieren einer vorhandenen Instance-Gruppe weiterhin denselben Wert, den Sie bei der Clustererstellung zugewiesen haben.
1. Um eine neue Instance-Gruppe hinzuzufügen, können Sie einen beliebigen Wert aus den zulässigen Optionen pro Instance-Typ auswählen. Weitere Informationen finden Sie unter dem Instance-Typ und in der Spalte **Gültige Threads pro Kern** in der Referenztabelle unter [CPU-Kerne und Threads pro CPU-Kern pro Instance-Typ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/cpu-options-supported-instances-values.html) im *Benutzerhandbuch für Amazon EC2*.
1. Für`OnStartDeepHealthChecks`, hinzufügen `InstanceStress` und `InstanceConnectivity` aktivieren[Tiefgreifende Zustandsprüfungen](sagemaker-hyperpod-eks-resiliency-deep-health-checks.md).
1. Geben Sie für an`NodeRecovery`, `Automatic` ob die automatische Knotenwiederherstellung aktiviert werden soll. SageMaker HyperPod ersetzt Instanzen (Knoten) oder startet sie neu, wenn der Health Monitoring Agent Probleme feststellt.
Der folgende Codeausschnitt ist eine JSON-Anforderungsdateivorlage, die Sie verwenden können. Weitere Informationen zur Anforderungssyntax und zu den Parametern dieser API finden Sie in der [UpdateCluster](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_UpdateCluster.html)API-Referenz.
```
// 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. Führen Sie den folgenden `update-cluster`-Befehl aus, um die Anfrage einzureichen.
```
aws sagemaker update-cluster \
--cli-input-json file://complete/path/to/update_cluster.json
```
# Aktualisierung der SageMaker HyperPod Plattformsoftware
Wenn Sie Ihren SageMaker HyperPod Cluster erstellen, SageMaker HyperPod wählt er ein Amazon Machine Image (AMI) aus, das der Kubernetes-Version Ihres Amazon EKS-Clusters entspricht.
Wird ausgeführt [update-cluster-software](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/update-cluster-software.html), um bestehende Cluster mit Software und Sicherheitspatches zu aktualisieren, die SageMaker HyperPod vom Service bereitgestellt werden. Für `--cluster-name` geben Sie entweder den Namen oder den ARN des zu aktualisierenden Clusters an.
**Wichtig**
Wenn diese API aufgerufen wird, werden die Jobs (Pods), die auf den Knoten ausgeführt werden, SageMaker HyperPod weder gelöscht noch neu verteilt. Stellen Sie sicher, dass Sie überprüfen, ob auf den Knoten Jobs ausgeführt werden, bevor Sie diese API aufrufen.
Der Patching-Prozess ersetzt das Root-Volume durch das aktualisierte AMI, was bedeutet, dass Ihre zuvor im Root-Volume der Instance gespeicherten Daten verloren gehen. Stellen Sie sicher, dass Sie Ihre Daten vom Instance-Root-Volume auf Amazon S3 oder Amazon FSx for Lustre sichern.
Alle Clusterknoten weisen während der Durchführung der Patches Ausfallzeiten auf (die Knoten werden in der Ausgabe von `kubectl get node` als `` angezeigt). Wir empfehlen Ihnen, alle Workloads vor dem Patchen zu beenden und sie nach Abschluss des Patches wieder aufzunehmen.
Wenn der Sicherheitspatch fehlschlägt, können Sie Fehlermeldungen abrufen, indem Sie die [https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_DescribeCluster.html](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_DescribeCluster.html)-API wie unter [Beschreiben eines Clusters](sagemaker-hyperpod-eks-operate-cli-command-cluster-details.md#sagemaker-hyperpod-eks-operate-cli-command-describe-cluster) beschrieben ausführen.
```
aws sagemaker update-cluster-software --cluster-name your-hyperpod-cluster
```
Wenn Sie die `UpdateClusterSoftware` API aufrufen, SageMaker HyperPod aktualisiert die Kubernetes-Version der Knoten, indem Sie die neueste Version [SageMaker HyperPod DLAMI](sagemaker-hyperpod-ref.md#sagemaker-hyperpod-ref-hyperpod-ami) basierend auf der Kubernetes-Version Ihres Amazon EKS-Clusters auswählen. Anschließend werden die Lebenszyklusskripte in dem Amazon-S3-Bucket ausgeführt, den Sie bei der Erstellung oder Aktualisierung des Clusters angegeben haben.
Sie können die Kubelet-Version eines Knotens überprüfen, indem Sie den Befehl `kubectl describe node` ausführen.
Die Kubernetes-Version von SageMaker HyperPod Clusterknoten wird nicht automatisch aktualisiert, wenn Sie Ihre Amazon EKS-Cluster-Version aktualisieren. Nachdem Sie die Kubernetes-Version für Ihren Amazon EKS-Cluster aktualisiert haben, müssen Sie die `UpdateClusterSoftware` API verwenden, um Ihre SageMaker HyperPod Clusterknoten auf dieselbe Kubernetes-Version zu aktualisieren.
Es wird empfohlen, Ihren SageMaker HyperPod Cluster nach der Aktualisierung Ihrer Amazon EKS-Knoten zu aktualisieren und zu vermeiden, dass mehr als ein Versionsunterschied zwischen der Amazon EKS-Cluster-Version und der SageMaker HyperPod Cluster-Knoten-Version besteht.
Das SageMaker HyperPod Serviceteam bringt regelmäßig neue [SageMaker HyperPod DLAMI](sagemaker-hyperpod-ref.md#sagemaker-hyperpod-ref-hyperpod-ami) Funktionen zur Erhöhung der Sicherheit und Verbesserung der Benutzererfahrung auf den Markt. Wir empfehlen Ihnen, immer auf die neueste Version von SageMaker HyperPod DLAMI zu aktualisieren. Für future SageMaker HyperPod DLAMI-Updates für Sicherheitspatches folgen Sie bitte. [SageMaker HyperPod Versionshinweise von Amazon](sagemaker-hyperpod-release-notes.md)
**Anmerkung**
Sie können diese API nur programmgesteuert ausführen. Die Patching-Funktionalität ist nicht in der Benutzeroberfläche der Konsole implementiert. SageMaker HyperPod
# Zugreifen auf SageMaker HyperPod Clusterknoten
Mit den AWS CLI Befehlen für AWS Systems Manager (SSM) können Sie direkt auf die Knoten eines in Betrieb befindlichen SageMaker HyperPod Clusters zugreifen. Führen Sie `aws ssm start-session` mit dem Hostnamen des Knotens im Format `sagemaker-cluster:[cluster-id]_[instance-group-name]-[instance-id]` aus. Sie können die Cluster-ID, die Instanz-ID und den Namen der Instanzgruppe von der [SageMaker HyperPod Konsole](sagemaker-hyperpod-operate-slurm-console-ui.md#sagemaker-hyperpod-operate-slurm-console-ui-view-details-of-clusters) oder durch Ausführen von `describe-cluster` und `list-cluster-nodes` aus den [AWS CLI Befehlen für SageMaker HyperPod](sagemaker-hyperpod-operate-slurm-cli-command.md#sagemaker-hyperpod-operate-slurm-cli-command-list-cluster-nodes) abrufen. Wenn Ihre Cluster-ID beispielsweise `aa11bbbbb222`, der Clusterknotenname `controller-group` und die Clusterknoten-ID `i-111222333444555aa` lautet, sollte der SSM-Befehl `start-session` wie folgt lauten.
**Anmerkung**
Wenn Sie noch keine Einrichtung vorgenommen haben AWS Systems Manager, folgen Sie den Anweisungen unter[Einrichtung AWS Systems Manager und Ausführung als für die Cluster-Benutzerzugriffskontrolle](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#
```
# Einen SageMaker HyperPod Cluster herunterskalieren
Sie können die Anzahl der Instances, die auf Ihrem SageMaker HyperPod Amazon-Cluster ausgeführt werden, reduzieren. Es kann verschiedene Gründe geben, warum Sie einen Cluster herunterskalieren möchten, beispielsweise eine geringere Ressourcennutzung oder Kostenoptimierung.
Die folgende Seite beschreibt zwei Hauptansätze zum Herunterskalieren:
+ **Herunterskalieren auf Instance-Gruppenebene:** Dieser Ansatz verwendet die `UpdateCluster`-API, mit der Sie:
+ Die Anzahl der Instances für bestimmte Instance-Gruppen unabhängig voneinander herunterskalieren. SageMaker KI verarbeitet die Terminierung von Knoten so, dass die Anzahl der neuen Zielinstanzen erreicht wird, die Sie für jede Gruppe festgelegt haben. Siehe [Verkleinern Sie eine Instance-Gruppe](#smcluster-scale-down-updatecluster).
+ Löschen Sie Instance-Gruppen vollständig aus Ihrem Cluster. Siehe [Instance-Gruppen löschen](#smcluster-remove-instancegroup).
+ **Herunterskalieren auf Instance-Ebene** Dieser Ansatz nutzt die `BatchDeleteClusterNodes`-API, mit der Sie die einzelnen Knoten angeben können, die Sie beenden möchten. Siehe [Herunterskalieren auf Instance-Ebene](#smcluster-scale-down-batchdelete).
**Anmerkung**
Beim Herunterskalieren auf Instance-Ebene mit `BatchDeleteCusterNodes` können Sie nur maximal 99 Instances gleichzeitig beenden. `UpdateCluster` unterstützt das Beenden einer beliebigen Anzahl von Instances.
## Wichtige Überlegungen
+ Wenn Sie einen Cluster herunterskalieren, sollten Sie sicherstellen, dass die verbleibenden Ressourcen für Ihren Workload ausreichen und dass alle erforderlichen Datenmigrationen oder Neugewichtungen ordnungsgemäß durchgeführt werden, um Störungen zu vermeiden.
+ Stellen Sie sicher, dass Sie Ihre Daten auf Amazon S3 oder einem FSx for Lustre-Dateisystem sichern, bevor Sie die API für eine Worker-Knotengruppe aufrufen. Dies kann dazu beitragen, potenziellen Datenverlust durch das Instance-Root-Volume zu verhindern. Weitere Informationen über Sicherungen finden Sie unter [Verwenden Sie das Backup-Skript von SageMaker HyperPod](sagemaker-hyperpod-operate-slurm-cli-command.md#sagemaker-hyperpod-operate-slurm-cli-command-update-cluster-software-backup).
+ Um diese API auf einem vorhandenen Cluster aufzurufen, müssen Sie zuerst den Cluster patchen, indem Sie die API ausführen. [ UpdateClusterSoftware](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_UpdateClusterSoftware.html) Weitere Informationen zum Patchen eines Clusters finden Sie unter [Aktualisieren Sie die SageMaker HyperPod Plattformsoftware eines Clusters](sagemaker-hyperpod-operate-slurm-cli-command.md#sagemaker-hyperpod-operate-slurm-cli-command-update-cluster-software).
+ Die Zählung/Abrechnung für On-Demand-Instances wird nach der Herunterskalierung automatisch gestoppt. Wenn Sie die Erfassung von reservierten Instances mit reduzierter Kapazität beenden möchten, wenden Sie sich an Ihr AWS Account-Team, um Unterstützung zu erhalten.
+ Sie können die freigegebene Kapazität der herunterskalierten Reserved Instances verwenden, um einen anderen Cluster hochzuskalieren. SageMaker HyperPod
## Herunterskalieren auf Instance-Gruppenebene
Dieser [https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_UpdateCluster.html](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_UpdateCluster.html)Vorgang ermöglicht es Ihnen, Änderungen an der Konfiguration Ihres SageMaker HyperPod Clusters vorzunehmen, z. B. die Anzahl der Instanzen einer Instanzgruppe zu reduzieren oder ganze Instanzgruppen zu entfernen. Dies kann nützlich sein, wenn Sie die Ihrem Cluster zugewiesenen Ressourcen an Änderungen Ihrer Arbeitslast anpassen, die Kosten optimieren oder den Instance-Typ einer Instance-Gruppe ändern möchten.
### Verkleinern Sie eine Instance-Gruppe
Verwenden Sie diesen Ansatz, wenn Sie eine Instance-Gruppe haben, die inaktiv ist und es sicher ist, eine der Instances zu beenden, um sie herunterzuskalieren. Wenn Sie eine `UpdateCluster` Anfrage zum Herunterskalieren einreichen, werden HyperPod nach dem Zufallsprinzip Instances für die Kündigung ausgewählt und auf die angegebene Anzahl von Knoten für die Instanzgruppe herunterskaliert.
**Anmerkung**
Wenn Sie die Anzahl der Instances in einer Instance-Gruppe auf 0 herunterskalieren, werden alle Instances innerhalb dieser Gruppe beendet. Die Instanzgruppe selbst wird jedoch weiterhin als Teil des SageMaker HyperPod Clusters existieren. Sie können die Instance-Gruppe zu einem späteren Zeitpunkt mit derselben Instance-Gruppenkonfiguration wieder hochskalieren.
Alternativ können Sie festlegen, dass eine Instance-Gruppe dauerhaft entfernt wird. Weitere Informationen finden Sie unter [Instance-Gruppen löschen](#smcluster-remove-instancegroup).
**So skalieren Sie mit `UpdateCluster`**
1. Befolgen Sie die in [Die SageMaker HyperPod Cluster-Konfiguration wird aktualisiert](sagemaker-hyperpod-eks-operate-cli-command-update-cluster.md) beschriebenen Schritte. Wenn Sie Schritt **1.d** erreicht haben, in dem Sie das **InstanceCount**Feld angeben, geben Sie eine Zahl ein, die kleiner ist als die aktuelle Anzahl von Instanzen, um den Cluster zu verkleinern.
1. Führen Sie den AWS CLI Befehl [update-cluster](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/update-cluster.html) aus, um Ihre Anfrage einzureichen.
Nachfolgend finden Sie ein Beispiel für ein `UpdateCluster`-JSON-Objekt: Stellen Sie sich den Fall vor, dass Ihre Instance-Gruppe derzeit aus 2 laufenden Instances besteht. Wenn Sie das **InstanceCount**Feld auf 1 setzen, wie im Beispiel gezeigt, wählen Sie HyperPod nach dem Zufallsprinzip eine der Instanzen aus und beenden sie.
```
{
"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"
}
```
### Instance-Gruppen löschen
Sie können den [https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_UpdateCluster.html](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_UpdateCluster.html)Vorgang verwenden, um ganze Instanzgruppen aus Ihrem SageMaker HyperPod Cluster zu entfernen, wenn sie nicht mehr benötigt werden. Dies geht über eine einfache Verkleinerung hinaus und ermöglicht es Ihnen, bestimmte Instance-Gruppen vollständig aus der Konfiguration Ihres Clusters zu entfernen.
**Anmerkung**
Gehen Sie beim Entfernen einer Instance-Gruppe wie folgt vor:
Alle Instances innerhalb der Zielgruppe werden beendet.
Die gesamte Gruppenkonfiguration wird aus dem Cluster gelöscht.
Alle Workloads, die auf dieser Instance-Gruppe ausgeführt werden, werden gestoppt.
**So löschen Sie Instance-Gruppen mit `UpdateCluster`**
1. Wenn Sie die unter [Die SageMaker HyperPod Cluster-Konfiguration wird aktualisiert](sagemaker-hyperpod-eks-operate-cli-command-update-cluster.md) beschriebenen Schritte ausführen:
1. Legen Sie den optionalen `InstanceGroupsToDelete`-Parameter in Ihrer `UpdateCluster`-JSON-Datei fest und übergeben Sie die kommagetrennte Liste der Instance-Gruppennamen, die Sie löschen möchten.
1. Wenn Sie die `InstanceGroups`-Liste angeben, stellen Sie sicher, dass die Spezifikationen der Instance-Gruppen, die Sie entfernen, nicht mehr in der `InstanceGroups`-Liste aufgeführt sind.
1. Führen Sie den AWS CLI Befehl [update-cluster](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/update-cluster.html) aus, um Ihre Anfrage einzureichen.
**Wichtig**
Ihr SageMaker HyperPod Cluster muss immer mindestens eine Instanzgruppe verwalten.
Stellen Sie sicher, dass alle wichtigen Daten gesichert sind, bevor Sie sie entfernen.
Die Entfernung kann nicht rückgängig gemacht werden.
Nachfolgend finden Sie ein Beispiel für ein `UpdateCluster`-JSON-Objekt: Betrachten wir den Fall, dass ein Cluster derzeit über drei Instance-Gruppen verfügt: eine *Trainingsgruppe*, eine *Prototyp-Trainingsgruppe* und eine *Inferenz-Servicegruppe*. Sie möchten die *Prototyp-Trainingsgruppe* löschen.
```
{
"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"
}
```
## Herunterskalieren auf Instance-Ebene
Mit `BatchDeleteClusterNodes` diesem Vorgang können Sie einen SageMaker HyperPod Cluster herunterskalieren, indem Sie die einzelnen Knoten angeben, die Sie beenden möchten. `BatchDeleteClusterNodes`bietet eine detailliertere Steuerung für die gezielte Entfernung von Knoten und die Clusteroptimierung. Beispielsweise können Sie `BatchDeleteClusterNodes` verwenden, um bestimmte Knoten für Wartungszwecke, rollierende Upgrades oder die geografische Neuverteilung von Ressourcen zu löschen.
**API-Anforderung und -Antwort**
Wenn Sie eine `BatchDeleteClusterNodes` Anfrage einreichen, SageMaker HyperPod werden Knoten nach ihrer Instanz gelöscht. IDs Die API akzeptiert eine Anfrage mit dem Clusternamen und einer Liste der IDs zu löschenden Knoten.
Die Antwort hat zwei Abschnitte:
+ `Failed`: Eine Liste von Fehlern des Typs `[ BatchDeleteClusterNodesError ](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_BatchDeleteClusterNodesError.html)`– einer pro Instance-ID.
+ `Successful`: Die Liste der Instanzen IDs wurde erfolgreich beendet.
**Validierung und Fehlerbehandlung**
Die API führt verschiedene Validierungen durch, wie zum Beispiel:
+ Überprüfung des Knoten-ID-Formats (Präfix von `i-` und Instance-ID-Struktur von Amazon EC2).
+ Überprüfung der Länge der Knotenliste mit einem Limit von 99 oder weniger Knoten IDs in einer einzigen `BatchDeleteClusterNodes` Anfrage.
+ Stellen Sie sicher, dass ein gültiger SageMaker HyperPod Cluster mit dem eingegebenen Clusternamen vorhanden ist und dass keine Operationen auf Clusterebene (Aktualisierung, Systemaktualisierung, Patchen oder Löschen) im Gange sind.
+ Behandlung von Fällen, in denen Instances nicht gefunden wurden, einen ungültigen Status haben oder verwendet werden.
**API-Antwortcodes**
+ Die API gibt einen `200`-Statuscode für erfolgreiche (z. B. alle Eingabeknoten haben die Validierung bestanden) oder teilweise erfolgreiche Anfragen (z. B. einige Eingabeknoten haben die Validierung nicht bestanden) zurück.
+ Wenn alle diese Validierungen fehlschlagen sind (z. B. wenn alle Eingabeknoten die Validierung nicht bestehen), gibt die API eine Antwort `400` Bad Request mit den entsprechenden Fehlermeldungen und Fehlercodes zurück.
**Beispiel**
Im Folgenden finden Sie ein Beispiel für das **Herunterskalieren eines Clusters auf Instance-Ebene** unter Verwendung der AWS CLI:
```
aws sagemaker batch-delete-cluster-nodes --cluster-name "cluster-name" --node-ids '["i-111112222233333", "i-111112222233333"]'
```
# Löschen eines Clusters SageMaker HyperPod
Führen Sie [delete-cluster](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/delete-cluster.html) aus, um einen Cluster zu löschen. Sie können entweder den Namen oder den ARN des Clusters angeben.
```
aws sagemaker delete-cluster --cluster-name your-hyperpod-cluster
```
Diese API bereinigt nur die SageMaker HyperPod Ressourcen und löscht keine Ressourcen des zugehörigen EKS-Clusters. Dazu gehören der Amazon EKS-Cluster, EKS-Pod-Identitäten, FSx Amazon-Volumes und EKS-Add-Ons. Dazu gehört auch die Erstkonfiguration, die Sie Ihrem EKS-Cluster hinzugefügt haben. Wenn Sie alle Ressourcen bereinigen möchten, stellen Sie sicher, dass Sie auch die EKS-Ressourcen separat bereinigen.
Stellen Sie sicher, dass Sie zuerst die SageMaker HyperPod Ressourcen löschen, gefolgt von den EKS-Ressourcen. Wenn Sie den Löschvorgang in umgekehrter Reihenfolge durchführen, kann dies zu verbliebenen Ressourcen führen.
**Wichtig**
Wenn diese API aufgerufen wird, werden die Jobs (Pods), die auf den Knoten ausgeführt werden, SageMaker HyperPod weder gelöscht noch neu verteilt. Stellen Sie sicher, dass Sie überprüfen, ob auf den Knoten Jobs ausgeführt werden, bevor Sie diese API aufrufen.
# HyperPod verwaltetes mehrstufiges Checkpointing
In diesem Abschnitt wird erklärt, wie verwaltetes mehrstufiges Checkpointing funktioniert und welche Vorteile es für groß angelegte Modellschulungen bietet.
Mit Amazon SageMaker HyperPod Managed Tiered Checkpointing können Sie umfangreiche generative KI-Modelle effizienter trainieren. Es verwendet mehrere Speicherebenen, einschließlich des CPU-Speichers Ihres Clusters. Dieser Ansatz reduziert Ihre Erholungszeit und minimiert den Verlust an Trainingsfortschritten. Außerdem werden nicht ausgelastete Speicherressourcen in Ihrer Trainingsinfrastruktur genutzt.
Das verwaltete mehrstufige Checkpointing ermöglicht das Speichern von Checkpoints mit einer höheren Frequenz im Speicher. Sie werden in regelmäßigen Abständen dauerhaft gespeichert. Dadurch bleiben sowohl die Leistung als auch die Zuverlässigkeit während Ihres Trainingsprozesses erhalten.
In diesem Handbuch wird beschrieben, wie Sie verwaltetes mehrstufiges Checkpointing mit PyTorch Frameworks auf Amazon HyperPod EKS-Clustern einrichten, konfigurieren und verwenden.
## So funktioniert verwaltetes mehrstufiges Checkpointing
Beim verwalteten mehrstufigen Checkpointing wird ein mehrstufiger Speicheransatz verwendet. Der CPU-Speicher dient als primäre Ebene zum Speichern von Modell-Checkpoints. Sekundäre Stufen umfassen persistente Speicheroptionen wie Amazon S3.
Wenn Sie einen Checkpoint speichern, speichert das System ihn im zugewiesenen Speicherplatz auf Ihren Clusterknoten. Er repliziert automatisch Daten zwischen benachbarten Rechenknoten, um die Zuverlässigkeit zu erhöhen. Diese Replikationsstrategie schützt vor Ausfällen einzelner oder mehrerer Knoten und bietet gleichzeitig schnellen Zugriff für Wiederherstellungsvorgänge.
Das System speichert außerdem regelmäßig Checkpoints entsprechend Ihrer Konfiguration im persistenten Speicher. Dies gewährleistet eine langfristige Haltbarkeit Ihres Trainingsfortschritts.
Zu den wichtigsten Komponenten gehören:
+ **Speicherverwaltungssystem**: Ein Speicherverwaltungs-Daemon, der disaggregierten Speicher als Service für Checkpoint-Speicher bereitstellt
+ **HyperPod Python-Bibliothek**: Stellt eine Schnittstelle zum disaggregierten Speicher her APIs und bietet Dienstprogramme zum Speichern, Laden und Verwalten von Checkpoints über Stufen hinweg
+ **Checkpoint-Replikation**: Aus Gründen der Fehlertoleranz werden Checkpoints automatisch über mehrere Knoten hinweg repliziert
Das System lässt sich über einfache API-Aufrufe nahtlos in PyTorch Trainingsschleifen integrieren. Es erfordert nur minimale Änderungen an Ihrem vorhandenen Code.
## Vorteile
Das verwaltete mehrstufige Checkpointing bietet mehrere Vorteile für das Training umfangreicher Modelle:
+ **Verbesserte Benutzerfreundlichkeit**: Verwaltet die Speicherung, Replikation, Persistenz und Wiederherstellung von Checkpoints
+ **Schnellere Checkpoint-Operationen**: Speicherbasierter Speicher bietet schnellere Speicher- und Ladezeiten als festplattenbasiertes Checkpointing, was zu einer schnelleren Wiederherstellung führt
+ **Fehlertoleranz**: Die automatische knotenübergreifende Checkpoint-Replikation schützt vor Ausfällen von Hardwareknoten
+ **Minimale Codeänderungen**: Die einfache API-Integration erfordert nur geringfügige Änderungen an vorhandenen Trainingsskripten
+ **Verbesserter Trainingsdurchsatz**: Der geringere Aufwand an Checkpoints bedeutet, dass mehr Zeit für das eigentliche Training aufgewendet wird
**Topics**
+ [So funktioniert verwaltetes mehrstufiges Checkpointing](#managed-tier-checkpointing-works)
+ [Vorteile](#managed-tier-checkpointing-benefits)
+ [Richten Sie verwaltetes mehrstufiges Checkpointing ein](managed-tier-checkpointing-setup.md)
+ [Verwaltetes mehrstufiges Checkpointing wird entfernt](managed-tier-checkpointing-remove.md)
+ [Sicherheitsüberlegungen für verwaltetes mehrstufiges Checkpointing](managed-tier-security-considerations.md)
# Richten Sie verwaltetes mehrstufiges Checkpointing ein
Dieser Abschnitt enthält den Einrichtungsprozess für verwaltetes mehrstufiges Checkpointing für Amazon. SageMaker HyperPod Sie erfahren, wie Sie die Funktion in Ihrem Cluster aktivieren und Checkpointing in Ihrem Trainingscode implementieren.
**Topics**
+ [Voraussetzungen](#managed-tier-checkpointing-setup-prerequisites)
+ [Schritt 1: Aktivieren Sie verwaltetes mehrstufiges Checkpointing für Ihren Cluster](#managed-tier-checkpointing-setup-step-enable-for-cluster)
+ [Schritt 2: Python-Bibliothek in Ihrem Trainings-Image installieren](#managed-tier-checkpointing-setup-step-install-library)
+ [Schritt 3: Speichern Sie Checkpoints in Ihrer Trainingsschleife](#managed-tier-checkpointing-setup-step-save-checkpoint-in-loop)
+ [Schritt 4: Checkpoints für die Wiederherstellung laden](#managed-tier-checkpointing-setup-step-load-checkpoint)
+ [Bestätigen Sie Ihre verwalteten mehrstufigen Checkpoint-Operationen](#managed-tier-checkpointing-setup-validation)
## Voraussetzungen
Bevor Sie verwaltetes mehrstufiges Checkpointing einrichten, stellen Sie sicher, dass Sie über Folgendes verfügen:
+ Ein Amazon HyperPod EKS-Cluster mit ausreichend verfügbarem CPU-Speicher für die Checkpoint-Zuweisung
+ PyTorch Trainingsworkloads und DCP-Jobs (beide werden unterstützt)
+ Geeignete IAM-Berechtigungen für die Clusterverwaltung, einschließlich:
+ Amazon CloudWatch - und Amazon S3 S3-Schreibberechtigungen für den Trainings-Pod zum Lesen/Schreiben von Checkpoints und Push-Metriken
+ Diese Berechtigungen können über die [EKS-OIDC-Einrichtung](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html) konfiguriert werden.
## Schritt 1: Aktivieren Sie verwaltetes mehrstufiges Checkpointing für Ihren Cluster
**Wichtig**
Sie müssen sich für die Verwendung von verwaltetem mehrstufigem Checkpointing anmelden.
Aktivieren Sie verwaltetes mehrstufiges Checkpointing über, HyperPod APIs wenn Sie Ihren Cluster erstellen oder aktualisieren. Der Service installiert das Speicherverwaltungssystem automatisch, wenn Sie den `TieredStorageConfig`-Parameter angeben.
Für neue Cluster können Sie verwenden. [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"
}'
```
Der `InstanceMemoryAllocationPercentage`-Parameter gibt die `percentage` (int) des Cluster-Speichers an, der für Checkpointing zugewiesen werden soll. Der Bereich liegt zwischen 20 und 100.
## Schritt 2: Python-Bibliothek in Ihrem Trainings-Image installieren
Installieren Sie die [Amazon SageMaker Checkpointing-Bibliothek](https://pypi.org/project/amzn-sagemaker-checkpointing/) und ihre Abhängigkeiten in Ihrem Trainings-Image, indem Sie sie zu Ihrem Dockerfile hinzufügen:
```
# Add this line to your training image Dockerfile
RUN pip install amzn-sagemaker-checkpointing s3torchconnector tenacity torch boto3 s3torchconnector
```
## Schritt 3: Speichern Sie Checkpoints in Ihrer Trainingsschleife
In deiner Trainingsschleife kannst du Checkpoints mithilfe von DCP asynchron speichern. PyTorch Im Folgenden finden Sie ein Beispiel dafür.
```
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
```
## Schritt 4: Checkpoints für die Wiederherstellung laden
Das Folgende ist ein Beispiel für das Laden eines Checkpoints.
```
# 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
```
## Bestätigen Sie Ihre verwalteten mehrstufigen Checkpoint-Operationen
Sie können Ihre verwalteten mehrstufigen Checkpoint-Operationen anhand von Protokollen validieren.
**Benutzerdefinierte Protokollierung (optional)**
Sie können Checkpointing-Protokolle in andere Protokolle integrieren, indem Sie einen benutzerdefinierten Logger an die Bibliothek übergeben. Beispielsweise können Sie Ihrem Trainingscode einen benutzerdefinierten Logger hinzufügen, sodass alle Protokolle aus der Bibliothek auch im Trainings-Logger gesammelt werden.
**Verbesserte Serviceprotokollierung (optional)**
Um das Debugging und die Transparenz der Services zu verbessern, können Sie den Checkpointing-Protokollpfad `/var/log/sagemaker_checkpointing` von Ihrem Pod aus in einen `/var/logs/sagemaker_checkpointing`-Pfad auf Ihrem Host mounten. Dadurch wird sichergestellt, dass nur bibliotheksspezifische Protokolle separat gesammelt werden. So erhält das Serviceteam verbesserte Transparenz hinsichtlich Debugging und Support.
# Verwaltetes mehrstufiges Checkpointing wird entfernt
In diesem Abschnitt wird erklärt, wie Sie das verwaltete mehrstufige Checkpointing deaktivieren, wenn Sie es nicht mehr benötigen.
Um das verwaltete mehrstufige Checkpointing zu deaktivieren, verwenden Sie den, um Ihre Clusterkonfiguration [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 zu aktualisieren:
```
aws sagemaker update-cluster \
--cluster-name cluster-name \
--tiered-storage-config '{ "Mode": "Disable" }'
```
Dadurch wird der Speicherverwaltungs-Daemon aus Ihrem Cluster entfernt. Der Daemon ist als Standard-Kubernetes implementiert DaemonSet und folgt dem standardmäßigen Kubernetes-Lifecycle-Management.
# Sicherheitsüberlegungen für verwaltetes mehrstufiges Checkpointing
In diesem Abschnitt werden wichtige Sicherheitsaspekte bei der Verwendung von verwaltetem mehrstufigem Checkpointing behandelt. Es umfasst die Verwendung von Python Pickle, Amazon-S3-Verschlüsselung und Netzwerk-Endpunktsicherheit.
**Verwendung von Python Pickle**
Managed Tiered Checkpointing verwendet das Pickle-Modul von Python, um in Amazon S3 gespeicherte Checkpoint-Daten zu deserialisieren. Diese Implementierung hat wichtige Auswirkungen auf die Sicherheit:
+ **Erweiterte Vertrauensgrenze**: Wenn Sie Managed Tiered Checkpointing mit Amazon S3 verwenden, wird der Amazon S3 S3-Bucket Teil der Vertrauensgrenze Ihres Clusters.
+ **Risiko bei der Codeausführung**: Das Pickle-Modul von Python kann während der Deserialisierung beliebigen Code ausführen. Wenn sich ein nicht autorisierter Benutzer Schreibzugriff auf Ihren Checkpoint Amazon S3 S3-Bucket verschafft, könnte er potenziell bösartige Pickle-Daten erstellen, die ausgeführt werden, wenn sie durch verwaltetes mehrstufiges Checkpointing geladen werden.
**Bewährte Methoden für Amazon-S3-Speicher**
Wenn Sie verwaltetes mehrstufiges Checkpointing mit Amazon S3 S3-Speicher verwenden:
+ **Beschränken Sie den Zugriff auf den Amazon-S3-Bucket**: Stellen Sie sicher, dass nur autorisierte Benutzer und Rollen, die mit Ihrem Trainings-Cluster verbunden sind, Zugriff auf den Amazon-S3-Bucket haben, der für Checkpointing verwendet wird.
+ **Implementieren Sie Bucket-Richtlinien**: Konfigurieren Sie geeignete Bucket-Richtlinien, um unbefugten Zugriff oder nicht autorisierte Änderungen zu verhindern.
+ **Zugriffsmuster überprüfen**: Implementieren Sie die Protokollierung zur Validierung von Zugriffsmustern auf Ihre Checkpoint Amazon S3 S3-Buckets.
+ **Validieren Sie die Bucket-Namen**: Wählen Sie den Bucket-Namen mit Bedacht, um ein mögliches Bucket-Hijacking zu vermeiden.
**Netzwerk-Endpunkte**
Managed Tiered Checkpointing ermöglicht Netzwerkendpunkte auf jedem Ihrer Rechenknoten an den folgenden Ports: 9200/TCP, 9209/UDP, 9210/UDP, 9219/UDP, 9220/UDP, 9229/UDP, 9230/UDP, 9239/UDP, 9240/UDP. Diese Ports sind für die Funktion des Checkpointing-Services und die Aufrechterhaltung der Datensynchronisation erforderlich.
Standardmäßig SageMaker schränkt die Netzwerkkonfiguration den Zugriff auf diese Endpunkte aus Sicherheitsgründen ein. Wir empfehlen Ihnen, diese Standardeinschränkungen beizubehalten.
Beachten Sie bei der Konfiguration Ihrer Netzwerkeinstellungen für Ihre Knoten und VPC die AWS bewährten Methoden für VPCs, Sicherheitsgruppen und ACLs. Weitere Informationen finden Sie hier:
+ [ SageMaker HyperPod Voraussetzungen für Amazon](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-prerequisites.html#sagemaker-hyperpod-prerequisites-optional-vpcCluster)
+ [Bewährte VPC-Sicherheitsmethoden](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-best-practices.html)
# SageMaker HyperPod Verwaltung von Aufgaben
SageMaker HyperPod Task Governance ist ein robustes Managementsystem, das entwickelt wurde, um die Ressourcenzuweisung zu optimieren und eine effiziente Nutzung der Rechenressourcen durch Teams und Projekte für Ihre Amazon EKS-Cluster sicherzustellen. Dadurch haben Administratoren die Möglichkeit, Folgendes festzulegen:
+ Prioritätsstufen für verschiedene Aufgaben
+ Rechenkapazitätszuweisung für jedes Team
+ Wie jedes Team ungenutzte Rechenleistung verleiht und ausleiht
+ Wenn ein Team seine eigenen Aufgaben vorwegnimmt
HyperPod Task Governance bietet auch Amazon EKS-Cluster-Observability und bietet so Echtzeiteinblicke in die Clusterkapazität. Dazu gehört die Verfügbarkeit und Nutzung von Rechenleistung, die Zuweisung und Auslastung von Teams sowie Informationen zu Aufgabenausführung und Wartezeiten, sodass Sie fundierte Entscheidungen treffen und Ressourcen proaktiv verwalten können.
In den folgenden Abschnitten erfahren Sie, wie Sie Ihre Amazon EKS-Cluster einrichten, die wichtigsten Konzepte verstehen und die HyperPod Task-Governance verwenden.
**Topics**
+ [Einrichtung für die SageMaker HyperPod Task-Governance](sagemaker-hyperpod-eks-operate-console-ui-governance-setup.md)
+ [Dashboard](sagemaker-hyperpod-eks-operate-console-ui-governance-metrics.md)
+ [Aufgaben](sagemaker-hyperpod-eks-operate-console-ui-governance-tasks.md)
+ [Richtlinien](sagemaker-hyperpod-eks-operate-console-ui-governance-policies.md)
+ [Beispiele für HyperPod Task-Governance-Befehle AWS CLI](sagemaker-hyperpod-eks-operate-console-ui-governance-cli.md)
+ [Fehlerbehebung](sagemaker-hyperpod-eks-operate-console-ui-governance-troubleshoot.md)
+ [Zuweisungsdokument für Amazon SageMaker HyperPod Task Governance](sagemaker-hyperpod-eks-operate-console-ui-governance-attributions.md)
# Einrichtung für die SageMaker HyperPod Task-Governance
Der folgende Abschnitt enthält Informationen zur Einrichtung der Amazon CloudWatch Observability EKS- und SageMaker HyperPod Task-Governance-Add-Ons.
Stellen Sie sicher, dass Sie über die Mindestberechtigungsrichtlinie für HyperPod Clusteradministratoren mit Amazon EKS verfügen, in[IAM-Benutzer für den Clusteradministrator](sagemaker-hyperpod-prerequisites-iam.md#sagemaker-hyperpod-prerequisites-iam-cluster-admin). Dazu gehören Berechtigungen zum Ausführen des SageMaker HyperPod Kerns APIs und zur Verwaltung von SageMaker HyperPod Clustern innerhalb Ihres AWS-Konto Unternehmens sowie zur Ausführung der Aufgaben in[Verwaltung von SageMaker HyperPod Clustern, die von Amazon EKS orchestriert werden](sagemaker-hyperpod-eks-operate.md).
**Topics**
+ [Dashboard-Einrichtung](sagemaker-hyperpod-eks-operate-console-ui-governance-setup-dashboard.md)
+ [Einrichtung der Aufgaben-Governance](sagemaker-hyperpod-eks-operate-console-ui-governance-setup-task-governance.md)
# Dashboard-Einrichtung
Verwenden Sie die folgenden Informationen, um das Amazon SageMaker HyperPod Amazon CloudWatch Observability EKS-Add-on einzurichten. Dadurch erhalten Sie ein detailliertes visuelles Dashboard, das Ihnen einen Überblick über die Metriken für Ihre EKS-Cluster-Hardware, die Teamzuweisung und die Aufgaben bietet.
Falls Sie Schwierigkeiten bei der Einrichtung haben, finden Sie unter [Fehlerbehebung](sagemaker-hyperpod-eks-operate-console-ui-governance-troubleshoot.md) bekannte Lösungen zur Fehlerbehebung.
**Topics**
+ [HyperPod Voraussetzungen für das Amazon CloudWatch Observability EKS-Add-on](#hp-eks-dashboard-prerequisites)
+ [HyperPod Einrichtung des Amazon CloudWatch Observability EKS-Add-ons](#hp-eks-dashboard-setup)
## HyperPod Voraussetzungen für das Amazon CloudWatch Observability EKS-Add-on
Der folgende Abschnitt enthält die Voraussetzungen, die vor der Installation des Add-Ons „Beobachtbarkeits-EKS von Amazon“ erfüllt sein müssen.
+ Stellen Sie sicher, dass Sie über die Mindestberechtigungsrichtlinien für HyperPod Cluster-Administratoren verfügen, in[IAM-Benutzer für den Clusteradministrator](sagemaker-hyperpod-prerequisites-iam.md#sagemaker-hyperpod-prerequisites-iam-cluster-admin).
+ Fügen Sie die `CloudWatchAgentServerPolicy`-IAM-Richtlinie an Ihre Worker-Knoten an. Geben Sie dazu den folgenden Befehl ein. Ersetzen Sie `my-worker-node-role` durch die IAM-Rolle, die von Ihren Kubernetes-Worker-Knoten verwendet wird.
```
aws iam attach-role-policy \
--role-name my-worker-node-role \
--policy-arn arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy
```
## HyperPod Einrichtung des Amazon CloudWatch Observability EKS-Add-ons
Verwenden Sie die folgenden Optionen, um das Amazon SageMaker HyperPod Amazon CloudWatch Observability EKS-Add-on einzurichten.
------
#### [ Setup using the SageMaker AI console ]
Die folgenden Berechtigungen sind für die Einrichtung und Visualisierung des HyperPod Task-Governance-Dashboards erforderlich. In diesem Abschnitt werden die unter [IAM-Benutzer für den Clusteradministrator](sagemaker-hyperpod-prerequisites-iam.md#sagemaker-hyperpod-prerequisites-iam-cluster-admin) aufgeführten Berechtigungen erweitert.
Verwenden Sie zur Verwaltung der Aufgaben-Governance die Beispielrichtlinie:
------
#### [ 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": "*"
}
]
}
```
------
Verwenden Sie die folgende Beispielrichtlinie, um Berechtigungen zur Verwaltung von Amazon CloudWatch Observability Amazon EKS und zur Anzeige des HyperPod Cluster-Dashboards über die SageMaker KI-Konsole zu erteilen:
------
#### [ 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": "*"
}
]
}
```
------
Navigieren Sie in der SageMaker HyperPod Konsole zur Registerkarte **Dashboard**, um Amazon CloudWatch Observability EKS zu installieren. Um sicherzustellen, dass Kennzahlen zur Aufgaben-Governance im **Dashboard** enthalten sind, aktivieren Sie das Kontrollkästchen „Kueue-Metriken“. Durch die Aktivierung der Kueue-Metriken werden CloudWatch **Metrics-Kosten** aktiviert, sobald das Limit für das kostenlose Kontingent erreicht ist. Weitere Informationen finden Sie unter **Kennzahlen** in der [ CloudWatchAmazon-Preisgestaltung](https://aws.amazon.com/cloudwatch/pricing/).
------
#### [ Setup using the EKS AWS CLI ]
Verwenden Sie den folgenden AWS CLI EKS-Befehl, um das Add-on zu installieren:
```
aws eks create-addon --cluster-name cluster-name
--addon-name amazon-cloudwatch-observability
--configuration-values "configuration json"
```
Nachfolgend finden Sie ein Beispiel für die JSON-Konfigurationswerte:
```
{
"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. Navigieren Sie zur [EKS-Konsole](https://console.aws.amazon.com/eks/home#/clusters).
1. Wählen Sie Ihren Cluster aus.
1. Wählen Sie **Add-Ons** aus.
1. Suchen Sie das **Amazon CloudWatch Observability-Add-on** und installieren Sie es. Installieren Sie Version >= 2.4.0 für das Add-on.
1. Fügen Sie die folgenden JSON-Konfigurationswerte ein:
```
{
"agent": {
"config": {
"logs": {
"metrics_collected": {
"kubernetes": {
"kueue_container_insights": true,
"enhanced_container_insights": true
},
"application_signals": { }
},
},
"traces": {
"traces_collected": {
"application_signals": { }
}
}
},
},
}
```
------
Sobald das EKS Observability-Add-on erfolgreich installiert wurde, können Sie Ihre EKS-Cluster-Metriken auf der Registerkarte **Dashboard** der HyperPod Konsole einsehen.
# Einrichtung der Aufgaben-Governance
Dieser Abschnitt enthält Informationen zur Einrichtung des Amazon SageMaker HyperPod Task Governance EKS-Add-ons. Dies umfasst die Erteilung von Berechtigungen, mit denen Sie die Priorisierung von Aufgaben, die Zuweisung von Rechenkapazitäten für Teams, die Verteilung ungenutzter Rechenkapazitäten und die Vorrangigkeit von Aufgaben für Teams festlegen können.
Falls Sie Schwierigkeiten bei der Einrichtung haben, finden Sie unter [Fehlerbehebung](sagemaker-hyperpod-eks-operate-console-ui-governance-troubleshoot.md) bekannte Lösungen zur Fehlerbehebung.
**Topics**
+ [Kueue-Einstellungen](#hp-eks-task-governance-kueue-settings)
+ [HyperPod Voraussetzungen für die Task-Governance](#hp-eks-task-governance-prerequisites)
+ [HyperPod Einrichtung der Task-Governance](#hp-eks-task-governance-setup)
## Kueue-Einstellungen
HyperPod Das Task Governance EKS-Add-on installiert [Kueue](https://github.com/kubernetes-sigs/kueue/tree/main/apis/kueue) für Ihre HyperPod EKS-Cluster. Kueue ist ein Kubernetes-natives System, das Kontingente verwaltet und deren Verbrauch durch Aufträge regelt.
| EKS HyperPod Task Governance-Zusatzversion | Version von Kueue, die als Teil des Add-ons installiert wird |
| --- | --- |
| v1.1.3 | v0.12.0 |
**Anmerkung**
Kueue v.012.0 und höher sind nicht Teil der kueue-rbac-proxy Installation. Frühere Versionen wurden möglicherweise installiert. kueue-rbac-proxy Wenn Sie beispielsweise Kueue v0.8.1 verwenden, haben Sie möglicherweise v0.18.1. kueue-rbac-proxy
HyperPod Task Governance nutzt Kueue für Kubernetes-natives Job Queueing, Scheduling und Quotenmanagement und wird zusammen mit dem Task Governance EKS-Add-on installiert. HyperPod Nach der Installation werden SageMaker KI-verwaltete Kubernetes-Ressourcen wie,,, und HyperPod erstellt und geändert. `KueueManagerConfig` `ClusterQueues` `LocalQueues` `WorkloadPriorityClasses` `ResourceFlavors` `ValidatingAdmissionPolicies` Kubernetes-Administratoren haben zwar die Flexibilität, den Status dieser Ressourcen zu ändern, es ist jedoch möglich, dass alle Änderungen, die an einer SageMaker KI-verwalteten Ressource vorgenommen werden, vom Service aktualisiert und überschrieben werden.
Die folgenden Informationen beschreiben die Konfigurationseinstellungen, die vom HyperPod Task Governance-Add-on für die Einrichtung von Kueue verwendet werden.
```
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: []
```
Weitere Informationen zu den einzelnen Konfigurationseinträgen finden Sie unter [Konfiguration](https://kueue.sigs.k8s.io/docs/reference/kueue-config.v1beta1/#Configuration) in der Kueue-Dokumentation.
## HyperPod Voraussetzungen für die Task-Governance
+ Stellen Sie sicher, dass Sie über die Mindestberechtigungsrichtlinie für HyperPod Clusteradministratoren verfügen, in[IAM-Benutzer für den Clusteradministrator](sagemaker-hyperpod-prerequisites-iam.md#sagemaker-hyperpod-prerequisites-iam-cluster-admin). Dazu gehören Berechtigungen zum Ausführen des SageMaker HyperPod Kerns APIs, zum Verwalten von SageMaker HyperPod Clustern in Ihrem AWS-Konto System und zum Ausführen der Aufgaben in[Verwaltung von SageMaker HyperPod Clustern, die von Amazon EKS orchestriert werden](sagemaker-hyperpod-eks-operate.md).
+ Sie benötigen die Kubernetes-Version >= 1.30. Anweisungen finden Sie unter [Aktualisieren vorhandener Cluster auf die neue Kubernetes-Version](https://docs.aws.amazon.com/eks/latest/userguide/update-cluster.html).
+ Wenn Sie Kueue bereits in ihren Clustern installiert haben, deinstallieren Sie Kueue, bevor Sie das EKS-Add-on installieren.
+ Vor der Installation des HyperPod Task Governance-Add-ons muss bereits ein HyperPod Knoten im EKS-Cluster vorhanden sein.
## HyperPod Einrichtung der Task-Governance
Im Folgenden finden Sie Informationen zur Einrichtung der HyperPod Task-Governance.
------
#### [ Setup using the SageMaker AI console ]
Im Folgenden finden Sie Informationen zur Einrichtung der HyperPod Task-Governance mithilfe der SageMaker HyperPod Konsole.
Ihnen sind bereits alle der folgenden Berechtigungen zugeordnet, wenn Sie bereits Berechtigungen zur Verwaltung von Amazon CloudWatch Observability EKS und zum Anzeigen des HyperPod Cluster-Dashboards über die SageMaker KI-Konsole im erteilt haben. [HyperPod Einrichtung des Amazon CloudWatch Observability EKS-Add-ons](sagemaker-hyperpod-eks-operate-console-ui-governance-setup-dashboard.md#hp-eks-dashboard-setup) Wenn Sie dies nicht eingerichtet haben, verwenden Sie die unten stehende Beispielrichtlinie, um Berechtigungen zur Verwaltung des HyperPod Task-Goverance-Add-ons zu erteilen und das HyperPod Cluster-Dashboard über die SageMaker AI-Konsole anzuzeigen.
------
#### [ 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": "*"
}
]
}
```
------
Navigieren Sie in der SageMaker HyperPod Konsole zum Tab **Dashboard**, um das Amazon SageMaker HyperPod Task Governance Add-on zu installieren.
------
#### [ Setup using the Amazon EKS AWS CLI ]
Verwenden Sie den [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) AWS CLI EKS-Beispielbefehl, um die HyperPod Task-Governance-Amazon EKS-API und die Konsolen-Benutzeroberfläche einzurichten. Verwenden Sie dazu AWS CLI:
```
aws eks create-addon --region region --cluster-name cluster-name --addon-name amazon-sagemaker-hyperpod-taskgovernance
```
------
Sie können den Tab **Richtlinien** in der HyperPod SageMaker AI-Konsole aufrufen, wenn die Installation erfolgreich war. Sie können auch den folgenden [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) AWS CLI EKS-Beispielbefehl verwenden, um den Status zu überprüfen.
```
aws eks describe-addon --region region --cluster-name cluster-name --addon-name amazon-sagemaker-hyperpod-taskgovernance
```
# Dashboard
Amazon SageMaker HyperPod Task Governance bietet eine umfassende Dashboard-Ansicht Ihrer Amazon EKS-Cluster-Nutzungsmetriken, einschließlich Hardware-, Team- und Aufgabenmetriken. Im Folgenden finden Sie Informationen zu Ihrem HyperPod EKS-Cluster-Dashboard.
Das Dashboard bietet einen umfassenden Überblick über die Kennzahlen zur Cluster-Auslastung, einschließlich Hardware-, Team- und Aufgabenmetriken. Sie müssen das EKS-Add-On installieren, um das Dashboard anzeigen zu können. Weitere Informationen finden Sie unter [Dashboard-Einrichtung](sagemaker-hyperpod-eks-operate-console-ui-governance-setup-dashboard.md).
In der [Amazon SageMaker AI-Konsole](https://console.aws.amazon.com/sagemaker/) können Sie unter **HyperPod Clusters** zur HyperPod Konsole navigieren und Ihre Liste der HyperPod Cluster in Ihrer Region einsehen. Wählen Sie Ihren Cluster aus und navigieren Sie zur Registerkarte **Dashboard**. Das Dashboard enthält die folgenden Metriken. Sie können die Daten für einen Abschnitt herunterladen, indem Sie den entsprechenden **Export** auswählen.
**Nutzung**
Stellt den Zustand des EKS-Clusters point-in-time und trendbasierte Metriken für kritische Rechenressourcen bereit. Standardmäßig wird **Alle Instance-Gruppen** angezeigt. Verwenden Sie das Dropdown-Menü, um Ihre Instance-Gruppen zu filtern. Die in diesem Abschnitt enthaltenen Metriken sind:
+ Anzahl der gesamten, laufenden und ausstehenden WiederherstellungsInstances. Die Anzahl der ausstehenden WiederherstellungsInstances bezieht sich auf die Anzahl der Instances, die für die Wiederherstellung behoben werden müssen.
+ GPUs, GPU-SpeicherCPUs, V- und CPUs V-Speicher.
+ GPU-Auslastung, GPU-Speicherauslastung, vCPU-Auslastung und vCPU-Speicherauslastung.
+ Ein interaktives Diagramm Ihrer GPU- und vCPU-Auslastung.
**Teams**
Bietet Informationen zur teamspezifischen Ressourcenverwaltung. Dies umfasst:
+ Instance- und GPU-Zuweisung.
+ GPU-Auslastung.
+ Ausgeliehene GPU-Statistiken.
+ Status der Aufgabe (läuft oder steht noch aus).
+ Eine Balkendiagrammansicht der GPU-Auslastung im Vergleich zur Rechenzuweisung zwischen den Teams.
+ Detaillierte GPU- und vCPU-bezogene Informationen für das Team. Standardmäßig enthalten die angezeigten Informationen Alle Teams. Sie können nach Team und Instances filtern, indem Sie die Dropdownmenüs auswählen. In der interaktiven Handlung können Sie nach Zeit filtern.
**Aufgaben**
**Anmerkung**
So zeigen Sie Ihre HyperPod EKS-Cluster-Aufgaben im Dashboard an:
Konfigurieren Sie Kubernetes Role-Based Access Control (RBAC) für Data-Scientist-Benutzer im angegebenen HyperPod Namespace, um die Ausführung von Aufgaben auf Amazon EKS-orchestrierten Clustern zu autorisieren. Namespaces folgen dem Format `hyperpod-ns-team-name`. Informationen zum Festlegen von RBAC-Berechtigungen finden Sie in den [Anweisungen zum Erstellen von Teamrollen](https://github.com/aws/sagemaker-hyperpod-cli/tree/main/helm_chart#5-create-team-role).
Stellen Sie sicher, dass Ihr Job mit den entsprechenden Namespace- und Prioritätsklassenbezeichnungen eingereicht wird. Ein umfassendes Beispiel finden Sie unter [Senden Sie einen Job an eine von SageMaker KI verwaltete Warteschlange und einen Namespace](sagemaker-hyperpod-eks-operate-console-ui-governance-cli.md#hp-eks-cli-start-job).
Enthält Informationen zu aufgabenbezogenen Metriken. Dazu gehören die Anzahl der laufenden, ausstehenden und präemptiven Aufgaben sowie Statistiken zu Ausführungs- und Wartezeiten. Standardmäßig enthalten die angezeigten Informationen **Alle Teams**. Sie können nach Team filtern, indem Sie das Dropdown-Menü auswählen. In der interaktiven Handlung können Sie nach Zeit filtern.
# Aufgaben
Im Folgenden finden Sie Informationen zu Amazon SageMaker HyperPod EKS-Cluster-Aufgaben. Aufgaben sind Operationen oder Jobs, die an den Cluster gesendet werden. Dabei kann es sich um Operationen des maschinellen Lernens wie Training, Durchführung von Experimenten oder Inferenz handeln. Die Liste mit den einsehbaren Aufgabendetails umfasst den Status, die Laufzeit und den Rechenaufwand, der pro Aufgabe verwendet wird.
In der [Amazon SageMaker AI-Konsole](https://console.aws.amazon.com/sagemaker/) können Sie unter **HyperPod Clusters** zur HyperPod Konsole navigieren und Ihre Liste der HyperPod Cluster in Ihrer Region einsehen. Wählen Sie Ihren Cluster aus und navigieren Sie zur Registerkarte **Aufgaben**.
Damit die Registerkarte **Aufgaben** für jeden außer dem Administrator sichtbar ist, muss der Administrator dem [EKS-Cluster einen Zugriffseintrag für die IAM-Rolle hinzufügen](https://docs.aws.amazon.com/eks/latest/userguide/access-entries.html).
**Anmerkung**
So sehen Sie sich Ihre HyperPod EKS-Cluster-Aufgaben im Dashboard an:
Konfigurieren Sie Kubernetes Role-Based Access Control (RBAC) für Data-Scientist-Benutzer im angegebenen HyperPod Namespace, um die Ausführung von Aufgaben auf Amazon EKS-orchestrierten Clustern zu autorisieren. Namespaces folgen dem Format `hyperpod-ns-team-name`. Informationen zum Festlegen von RBAC-Berechtigungen finden Sie in den [Anweisungen zum Erstellen von Teamrollen](https://github.com/aws/sagemaker-hyperpod-cli/tree/main/helm_chart#5-create-team-role).
Stellen Sie sicher, dass Ihr Job mit den entsprechenden Namespace- und Prioritätsklassenbezeichnungen eingereicht wird. Ein umfassendes Beispiel finden Sie unter [Senden Sie einen Job an eine von SageMaker KI verwaltete Warteschlange und einen Namespace](sagemaker-hyperpod-eks-operate-console-ui-governance-cli.md#hp-eks-cli-start-job).
Für EKS-Cluster werden kubeflow (, MPI,) -Aufgaben angezeigt. PyTorch TensorFlow Standardmäßig werden PyTorch Aufgaben angezeigt. Sie können nach PyTorch TensorFlow Aufgaben (MPI) filtern, indem Sie das Drop-down-Menü auswählen oder das Suchfeld verwenden. Zu den Informationen, die für jede Aufgabe angezeigt werden, gehören der Aufgabenname, der Status, der Namespace, die Prioritätsklasse und die Erstellungszeit.
# Verwendung von topologieorientierter Planung in der Amazon Task Governance SageMaker HyperPod
Die topologieorientierte Planung in Amazon SageMaker HyperPod Task Governance optimiert die Trainingseffizienz verteilter Machine-Learning-Workloads, indem Pods auf der Grundlage der physischen Netzwerktopologie Ihrer Amazon EC2 EC2-Instances platziert werden. Durch Berücksichtigung der hierarchischen Struktur der AWS Infrastruktur, einschließlich Availability Zones, Netzwerkblöcken und physischen Racks, stellt die topologieorientierte Planung sicher, dass Pods, die häufig kommunizieren müssen, in unmittelbarer Nähe geplant werden, um die Netzwerklatenz zu minimieren. Diese intelligente Platzierung ist besonders vorteilhaft für groß angelegte Schulungsaufgaben im Bereich maschinelles Lernen, die intensive pod-to-pod Kommunikation erfordern. Dies führt zu kürzeren Schulungszeiten und einer effizienteren Ressourcennutzung in Ihrem gesamten Cluster.
**Anmerkung**
Um die topologieorientierte Planung zu verwenden, stellen Sie sicher, dass Ihre Version von HyperPod Task Governance v1.2.2-eksbuild.1 oder höher ist.
Die topologiebezogene Planung unterstützt die folgenden Instance-Typen:
+ ml.p3dn.24xlarge
+ ml.p4d.24xlarge
+ ml.p4de.24xlarge
+ ml.p5.48xlarge
+ ml.p5e.48x groß
+ ml.p5en.48xlarge
+ ml.p6e-gb200.36xlarge
+ ml.trn1.2xlarge
+ ml.trn1.32xlarge
+ ml.trn1n.32xlarge
+ ml.trn2.48xlarge
+ ml.trn2u.48xlarge
Die topologieorientierte Planung lässt sich in Ihre bestehenden HyperPod Workflows integrieren und bietet gleichzeitig flexible Topologieeinstellungen sowohl über kubectl-YAML-Dateien als auch über die CLI. HyperPod HyperPod Task Governance konfiguriert Clusterknoten automatisch mit Topologie-Labels und arbeitet mit HyperPod Task-Governance-Richtlinien und Mechanismen zur Ressourcenausleihe zusammen, um sicherzustellen, dass eine topologieorientierte Planung Ihre aktuellen Betriebsprozesse nicht stört. Dank der integrierten Unterstützung für bevorzugte und erforderliche Topologiespezifikationen können Sie die Platzierung der Workloads genau auf Ihre spezifischen Leistungsanforderungen abstimmen und gleichzeitig flexibel auf die Standardplanung zurückgreifen, wenn die Topologiebeschränkungen nicht erfüllt werden können.
Durch die Nutzung topologiebewusster Labels können Sie ihre Workloads für maschinelles Lernen durch eine intelligente Pod-Platzierung verbessern HyperPod, die die physische Netzwerkinfrastruktur berücksichtigt. HyperPod Die Task-Governance optimiert automatisch die Pod-Planung auf der Grundlage der hierarchischen Rechenzentrumstopologie, was sich direkt in einer geringeren Netzwerklatenz und einer verbesserten Trainingsleistung für verteilte ML-Aufgaben niederschlägt. Dieses Topologiebewusstsein ist besonders wertvoll für umfangreiche Machine-Learning-Workloads, da es den Kommunikationsaufwand minimiert, indem verwandte Pods strategisch näher beieinander in der Netzwerkhierarchie platziert werden. Das Ergebnis ist eine optimierte Kommunikationsnetzwerklatenz zwischen Pods, eine effizientere Ressourcennutzung und eine bessere Gesamtleistung für rechenintensive AI/ML Anwendungen. All das, ohne dass Sie komplexe Netzwerktopologiekonfigurationen manuell verwalten müssen.
Im Folgenden finden Sie Bezeichnungen für die verfügbaren Topologie-Netzwerkschichten, in denen HyperPod Task Governance Pods einplanen kann:
+ topology.k8s.aws/ -1 network-node-layer
+ network-node-layertopology.k8s.aws/ -2
+ network-node-layertopology.k8s.aws/ -3
+ topology.k8s.aws/ultraserver-id
Um die topologiebezogene Planung zu verwenden, fügen Sie die folgenden Labels in Ihre YAML-Datei ein:
+ kueue.x-k8s.io/ podset-required-topology — gibt an, dass dieser Job über die erforderlichen Pods verfügen muss und dass alle Pods in den Knoten innerhalb derselben Topologieebene geplant werden müssen.
+ kueue.x-k8s.io/ podset-preferred-topology — gibt an, dass dieser Job die Pods haben muss, dass die Planung von Pods innerhalb derselben Topologieebene jedoch bevorzugt, aber nicht erforderlich ist. HyperPod Task Governance versucht, die Pods innerhalb einer Ebene zu planen, bevor es mit der nächsten Topologieebene versucht wird.
Wenn Ressourcen nicht dieselbe Topologiebezeichnung haben, wird der Auftrag unterbrochen. Der Auftrag wird in die Warteliste aufgenommen. Sobald Kueue feststellt, dass genügend Ressourcen vorhanden sind, wird der Auftrag angenommen und ausgeführt.
Das folgende Beispiel zeigt, wie Sie die Labels in Ihren YAML-Dateien verwenden:
```
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
```
In der folgenden Tabelle werden die neuen Parameter erläutert, die Sie in der kubectl-YAML-Datei verwenden können.
| Parameter | Description |
| --- | --- |
| kueue.x-k8s.io/queue-name | Der Name der Warteschlange, die zum Ausführen des Auftrags verwendet werden soll. Das Format dieses Warteschlangennamens muss hyperpod-ns-team-name-localqueue lauten. |
| kueue.x-k8s.io/priority-class | Ermöglicht die Angabe einer Priorität für die Pod-Planung. Diese Angabe ist optional. |
| Anmerkungen | Enthält die Topologie-Anmerkung, die Sie dem Auftrag hinzufügen. Verfügbare Topologien sind kueue.x-k8s.io/ und podset-required-topology kueue.x-k8s.io/. podset-preferred-topology Sie können entweder eine Anmerkung oder nodeSelector verwenden, aber nicht beides gleichzeitig. |
| nodeSelector | Gibt die Netzwerkschicht an, die die Ebene der Platzierung der Amazon-EC2-Instance darstellt. Verwenden Sie entweder dieses Feld oder eine Anmerkung, aber nicht beides gleichzeitig. In Ihrer YAML-Datei können Sie auch den nodeSelector-Parameter verwenden, um die genaue Ebene für Ihre Pods auszuwählen. Verwenden Sie die API-Operation, um den Wert Ihres Labels zu ermitteln. [ DescribeInstanceTopology](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeInstanceTopology.html) |
Sie können auch die HyperPod CLI verwenden, um Ihren Job auszuführen und die topologieorientierte Planung zu verwenden. Weitere Informationen zur HyperPod CLI finden Sie unter[SageMaker HyperPod CLI-Befehle](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
```
Im Folgenden finden Sie ein Beispiel für eine Konfigurationsdatei, die Sie verwenden können, um eine PytorchJob mit Topologie-Labels auszuführen. Die Datei ist weitgehend identisch, wenn Sie MPI- und Tensorflow-Aufträge ausführen möchten. Wenn Sie stattdessen diese Jobs ausführen möchten, denken Sie daran, die Konfigurationsdatei entsprechend zu ändern, z. B. das richtige Bild anstelle von PyTorchJob zu verwenden. Wenn Sie einen ausführen PyTorchJob, können Sie den Master- und Worker-Knoten unterschiedliche Topologien zuweisen. PyTorchJob hat immer einen Master-Knoten, daher empfehlen wir, stattdessen die Topologie zur Unterstützung von Worker-Pods zu verwenden.
```
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
```
Verwenden Sie die [ DescribeInstanceTopology](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeInstanceTopology.html)API-Operation, um die Topologien für Ihren Cluster zu sehen. Standardmäßig sind die Topologien in Amazon Studio AWS-Managementkonsole und Amazon SageMaker Studio ausgeblendet. Folgen Sie diesen Schritten, um sie in der Benutzeroberfläche zu sehen, die Sie verwenden.
Studio
1. Navigieren Sie in SageMaker Studio zu Ihrem Cluster.
1. Wählen Sie in der Aufgabenansicht das Optionsmenü in der Spalte Name und dann **Spalten verwalten** aus.
1. Wählen Sie **Angeforderte Topologie** und **Topologieeinschränkung** aus, um die Spalten hinzuzufügen, in denen die Topologieinformationen in der Liste der Kubernetes-Pods angezeigt werden sollen.
**AWS-Managementkonsole**
1. Öffnen Sie die Amazon SageMaker AI-Konsole unter [https://console.aws.amazon.com/sagemaker/](https://console.aws.amazon.com/sagemaker/).
1. Wählen Sie unter **HyperPod Cluster** die Option **Clusterverwaltung** aus.
1. Wählen Sie die Registerkarte **Aufgaben** und dann das Zahnradsymbol aus.
1. Schalten Sie unter Instance-Attribute die Optionen **Angeforderte Topologie** und **Topologieeinschränkung** um.
1. Wählen Sie **Bestätigen** aus, um die Topologieinformationen in der Tabelle anzuzeigen.
# Richtlinien
Amazon SageMaker HyperPod Task Governance vereinfacht die Zuweisung Ihrer Amazon EKS-Cluster-Ressourcen und die Priorisierung von Aufgaben. Im Folgenden finden Sie Informationen zu HyperPod EKS-Clusterrichtlinien. Weitere Informationen dazu, wie Sie Aufgaben-Governance einrichten, finden Sie unter [Einrichtung der Aufgaben-Governance](sagemaker-hyperpod-eks-operate-console-ui-governance-setup-task-governance.md).
Die Richtlinien sind in **Rechenpriorisierung** und **Rechenzuweisung** unterteilt. Die folgenden Richtlinienkonzepte werden im Kontext dieser Richtlinien strukturiert.
Die **Rechenpriorisierung** oder Clusterrichtlinie bestimmt, wie ungenutzte Rechenleistung ausgeliehen wird und wie Aufgaben von Teams priorisiert werden.
+ Die **Zuweisung inaktiver Rechenleistung** definiert, wie ungenutzte Rechenleistung den Teams zugewiesen wird. Das heißt, wie ungenutzte Rechenleistung von Teams ausgeliehen werden kann. Bei der Auswahl einer **Zuweisung inaktiver Rechenleistung** können Sie zwischen folgenden Optionen wählen:
+ **First-come first-serve**: Bei der Anwendung werden Teams nicht gegeneinander priorisiert, und jede eingehende Aufgabe hat die gleiche Wahrscheinlichkeit, Ressourcen über die Quote hinaus zu erhalten. Aufgaben werden in der Reihenfolge ihrer Einreichung priorisiert. Das bedeutet, dass ein Benutzer möglicherweise 100 % der inaktiven Rechenleistung nutzen kann, wenn er dies zuerst anfordert.
+ **Fair-Share**: Bei Anwendung dieser Option leihen sich Teams ungenutzte Rechenleistung auf der Grundlage des ihnen zugewiesenen **Fair-Share-Gewichts**. Diese Gewichtungen sind unter **Rechenzuweisung** definiert. Weitere Informationen zur Verwendung finden Sie unter [Beispiele für die gemeinsame Nutzung inaktiver Rechenressourcen](#hp-eks-task-governance-policies-examples).
+ **Aufgabenpriorisierung** definiert, wie Aufgaben in die Warteschlange gestellt werden, sobald Rechenleistung verfügbar ist. Bei der Auswahl einer **Aufgabenpriorisierung** können Sie zwischen folgenden Optionen wählen:
+ **First-come first-serve**: Wenn diese Option angewendet wird, werden sie in der Reihenfolge, in der sie angefordert wurden, in die Warteschlange gestellt.
+ **Rangfolge der Aufgaben**: Wenn diese Option angewendet wird, werden sie in der Reihenfolge, die durch ihre Priorisierung definiert ist, in die Warteschlange gestellt. Wenn diese Option ausgewählt ist, müssen Sie Prioritätsklassen zusammen mit den Gewichtungen hinzufügen, nach denen sie priorisiert werden sollen. Aufgaben derselben Prioritätsklasse werden nach dem Prinzip „first-come first-serve“ ausgeführt. Wenn diese Option in der Rechenzuweisung aktiviert ist, werden Aufgaben mit niedrigerer Priorität durch Aufgaben mit höherer Priorität innerhalb des Teams vorgezogen.
Wenn Datenwissenschaftler Aufträge an den Cluster senden, verwenden sie den Namen der Prioritätsklasse in der YAML-Datei. Die Prioritätsklasse hat das Format `priority-class-name-priority`. Ein Beispiel finden Sie unter [Senden Sie einen Job an eine von SageMaker KI verwaltete Warteschlange und einen Namespace](sagemaker-hyperpod-eks-operate-console-ui-governance-cli.md#hp-eks-cli-start-job).
+ **Prioritätsklassen**: Diese Klassen legen eine relative Priorität für Aufgaben beim Ausleihen von Kapazitäten fest. Wenn eine Aufgabe mit geliehenem Kontingent ausgeführt wird, kann sie von einer anderen Aufgabe mit höherer Priorität verdrängt werden, wenn für die eingehende Aufgabe keine Kapazität mehr verfügbar ist. Wenn **Preemption** in der **Rechenzuweisung** aktiviert ist, kann eine Aufgabe mit höherer Priorität auch Aufgaben innerhalb ihres eigenen Teams vorrangig behandeln.
+ Die **gemeinsame Nutzung nicht zugewiesener Ressourcen** ermöglicht es Teams, Rechenressourcen auszuleihen, die im Rahmen der Rechenquote keinem Team zugewiesen wurden. Wenn diese Option aktiviert ist, steht Teams nicht zugewiesene Clusterkapazität automatisch zur Verfügung. Weitere Informationen finden Sie unter [So funktioniert die gemeinsame Nutzung nicht zugewiesener Ressourcen](#sagemaker-hyperpod-eks-operate-console-ui-governance-policies-idle-resource-sharing-how-it-works).
Die **Rechenzuweisung** oder das Rechenkontingent definiert die Rechenzuweisung eines Teams und legt fest, welche Gewichtung (oder Prioritätsstufe) ein Team erhält, wenn es ungenutzte Rechenleistung fair verteilt.
+ **Teamname**: Der Teamname. Es wird ein entsprechender **Namespace** des Typs `hyperpod-ns-team-name` erstellt.
+ **Mitglieder**: Mitglieder des Team-Namespace. Sie müssen eine rollenbasierte Zugriffskontrolle (RBAC) von Kubernetes für Data Scientist-Benutzer einrichten, die Teil dieses Teams sein sollen, um Aufgaben auf HyperPod Clustern auszuführen, die mit Amazon EKS orchestriert wurden. Um einen Kubernetes-RBAC einzurichten, folgen Sie den Anweisungen unter [Teamrolle erstellen](https://github.com/aws/sagemaker-hyperpod-cli/tree/main/helm_chart#5-create-team-role).
+ **Fair-Share-Gewichtung**: Dies ist die Priorisierungsstufe, die dem Team zugewiesen wird, wenn **Fair-Share** für die **Zuweisung von inaktiver Rechenleistung** angewendet wird. Die höchste Priorität hat eine Gewichtung von 100 und die niedrigste Priorität hat eine Gewichtung von 0. Eine höhere Gewichtung ermöglicht es einem Team, früher auf ungenutzte Ressourcen innerhalb gemeinsam genutzter Kapazitäten zuzugreifen. Eine Gewichtung von Null bedeutet die niedrigste Priorität, was bedeutet, dass dieses Team im Vergleich zu anderen Teams immer im Nachteil sein wird.
Die Fair-Share-Gewichtung verschafft diesem Team einen Wettbewerbsvorteil, wenn es um verfügbare Ressourcen gegen andere wetteifert. Die Zulassung priorisiert die Planung von Aufgaben von Teams mit den höchsten Gewichtungen und den geringsten Ausleihen. Wenn beispielsweise Team A ein Gewicht von 10 und Team B ein Gewicht von 5 hat, hätte Team A Vorrang beim Zugriff auf ungenutzte Ressourcen, da es Aufgaben hätte, die früher als Team B geplant sind.
+ **Aufgaben-Preemption**: Die Berechnung wird basierend auf der Priorität von einer Aufgabe übernommen. Standardmäßig hat das Team, das inaktive Rechenleistung ausleiht, Vorrang vor Aufgaben anderer Teams.
+ **Verleihen und Ausleihen**: Wie inaktive Rechenleistung vom Team verliehen wird und ob das Team Rechenleistung von anderen Teams ausleihen kann.
+ **Prozentuales Kreditlimit: Das Limit für ungenutzte Rechenleistung, das ein Team ausleihen** darf, ausgedrückt als Prozentsatz der garantierten Quote. Ein Team kann bis zu 10.000% der zugewiesenen Rechenleistung ausleihen. Der Wert, den Sie hier angeben, wird als Prozentsatz interpretiert. Ein Wert von 500 wird beispielsweise als 500 % interpretiert. Dieser Prozentsatz gilt einheitlich für alle Ressourcentypen (CPU, GPU, Arbeitsspeicher) und Instanztypen, die im Kontingent des Teams enthalten sind.
+ **Absolutes Kreditlimit**: Das Limit für ungenutzte Rechenleistung, das ein Team ausleihen darf, definiert als absolute Ressourcenwerte pro Instanztyp. Dies ermöglicht eine detaillierte Steuerung des Ausleihverhaltens für bestimmte Instance-Typen. Sie müssen absolute Grenzwerte angeben, indem Sie dasselbe Schema wie das **Compute-Kontingent** verwenden, einschließlich Instanzanzahl, Beschleuniger, vCPU, Arbeitsspeicher oder Beschleunigerpartitionen. Sie können absolute Grenzwerte für einen oder mehrere Instanztypen in der Quote Ihres Teams angeben.
Informationen zur Verwendung dieser Konzepte, wie Prioritätsklassen und Namensräume, finden Sie unter [Beispiele für HyperPod Task-Governance-Befehle AWS CLI](sagemaker-hyperpod-eks-operate-console-ui-governance-cli.md).
## Beispiele für die gemeinsame Nutzung inaktiver Rechenressourcen
Das reservierte Gesamtkontingent sollte die verfügbare Kapazität des Clusters für diese Ressource nicht überschreiten, um eine ordnungsgemäße Kontingentverwaltung zu gewährleisten. Wenn ein Cluster beispielsweise 20 `ml.c5.2xlarge`-Instances umfasst, sollte das den Teams zugewiesene Gesamtkontingent unter 20 bleiben.
Wenn die Richtlinien **Rechenzuweisung** für Teams **Verleihen und Ausleihen** oder **Verleihen** zulassen, wird die freie Kapazität zwischen diesen Teams geteilt. Beispielsweise haben Team A und Team B die Option **Ausleihen und Verleihen** aktiviert. Team A hat ein Kontingent von 6, nutzt aber nur 2 für seine Aufgaben, und Team B hat ein Kontingent von 5 und nutzt 4 für seine Aufgaben. Ein Job, der bei Team B eingereicht wird und 4 Ressourcen benötigt. 3 werden von Team A ausgeliehen.
Wenn die **Compute-Zuweisungsrichtlinie** eines Teams auf **„Nicht leihen**“ gesetzt ist, kann sich das Team keine zusätzliche Kapazität leihen, die über die eigenen Zuweisungen hinausgeht.
## So funktioniert die gemeinsame Nutzung nicht zugewiesener Ressourcen
Durch die gemeinsame Nutzung nicht zugewiesener Ressourcen wird automatisch der Pool von Ressourcen verwaltet, die keinem Rechenkontingent in Ihrem Cluster zugewiesen sind. Das bedeutet, dass Ihr Clusterstatus HyperPod kontinuierlich überwacht und im Laufe der Zeit automatisch auf die richtige Konfiguration aktualisiert wird.
**Ersteinrichtung**
+ Wenn Sie dies `Enabled` in Ihrem festlegen `IdleResourceSharing` ClusterSchedulerConfig (standardmäßig ist dies der Fall`Disabled`), beginnt HyperPod Task Governance mit der Überwachung Ihres Clusters und berechnet die verfügbaren ungenutzten Ressourcen, indem die Teamkontingente von der gesamten Knotenkapazität abgezogen werden.
+ Die gemeinsame Nutzung ClusterQueues nicht zugewiesener Ressourcen wird erstellt, um den ausleihbaren Ressourcenpool darzustellen.
+ Wenn Sie die gemeinsame Nutzung nicht zugewiesener Ressourcen zum ersten Mal aktivieren, dauert die Einrichtung der Infrastruktur mehrere Minuten. Sie können den Fortschritt anhand von Richtlinien `Status` und `DetailedStatus` in ClusterSchedulerConfig überwachen.
**Kontinuierliche Versöhnung**
+ HyperPod Task Governance überwacht kontinuierlich Änderungen wie das Hinzufügen oder Entfernen von Knoten und Aktualisierungen der Cluster-Warteschlangenkontingente.
+ Wenn Änderungen vorgenommen werden, werden bei der gemeinsamen Nutzung nicht zugewiesener Ressourcen das Kontingent und die Aktualisierungen neu berechnet. ClusterQueues Der Abgleich ist in der Regel innerhalb von Sekunden abgeschlossen.
**Überwachung**
Sie können überprüfen, ob die gemeinsame Nutzung nicht zugewiesener Ressourcen vollständig konfiguriert ist, indem Sie nach der gemeinsamen Nutzung nicht zugewiesener Ressourcen suchen: ClusterQueues
```
kubectl get clusterqueue | grep hyperpod-ns-idle-resource-sharing
```
Wenn Sie Namen wie sehen ClusterQueues `hyperpod-ns-idle-resource-sharing-cq-1`, ist die gemeinsame Nutzung nicht zugewiesener Ressourcen aktiv. Beachten Sie, dass je nach Anzahl der Ressourcenvarianten in Ihrem Cluster mehrere nicht zugewiesene Ressourcen gemeinsam genutzt werden ClusterQueues können.
## Eignung des Knotens für die gemeinsame Nutzung nicht zugewiesener Ressourcen
Die gemeinsame Nutzung nicht zugewiesener Ressourcen umfasst nur Knoten, die die folgenden Anforderungen erfüllen:
1. **Status „Knoten bereit“**
+ Knoten müssen `Ready` den Status haben, dass sie zum nicht zugewiesenen Ressourcenpool beitragen können.
+ Knoten im Zustand `NotReady` oder in einem anderen Zustand, der nicht bereit ist, werden von der Kapazitätsberechnung ausgeschlossen.
+ Wenn ein Knoten zu einem Knoten wird`Ready`, wird er automatisch in den nächsten Abstimmungszyklus aufgenommen.
1. **Status des Knotens planbar**
+ Knoten mit `spec.unschedulable: true` sind von der gemeinsamen Nutzung nicht zugewiesener Ressourcen ausgeschlossen.
+ Wenn ein Knoten wieder planbar ist, wird er automatisch in den nächsten Abstimmungszyklus aufgenommen.
1. **MIG-Konfiguration (nur GPU-Knoten)**
+ Bei GPU-Knoten mit MIG-Partitionierung (Multi-Instance-GPU) muss die `nvidia.com/mig.config.state` Bezeichnung angezeigt `success` werden, damit der Knoten MIG-Profile zur gemeinsamen Nutzung nicht zugewiesener Ressourcen beitragen kann.
+ Diese Knoten werden automatisch erneut versucht, sobald die MIG-Konfiguration erfolgreich abgeschlossen wurde.
1. **Unterstützte Instance-Typen**
+ Bei der Instance muss es sich um einen unterstützten SageMaker HyperPod Instance-Typ handeln.
+ Sehen Sie sich die Liste der unterstützten Instance-Typen im SageMaker HyperPod Cluster an.
**Topics**
+ [Beispiele für die gemeinsame Nutzung inaktiver Rechenressourcen](#hp-eks-task-governance-policies-examples)
+ [So funktioniert die gemeinsame Nutzung nicht zugewiesener Ressourcen](#sagemaker-hyperpod-eks-operate-console-ui-governance-policies-idle-resource-sharing-how-it-works)
+ [Eignung des Knotens für die gemeinsame Nutzung nicht zugewiesener Ressourcen](#sagemaker-hyperpod-eks-operate-console-ui-governance-policies-idle-resource-sharing-node-eligibility)
+ [Erstellen von Richtlinien](sagemaker-hyperpod-eks-operate-console-ui-governance-policies-create.md)
+ [Richtlinien bearbeiten](sagemaker-hyperpod-eks-operate-console-ui-governance-policies-edit.md)
+ [Löschen von Richtlinien](sagemaker-hyperpod-eks-operate-console-ui-governance-policies-delete.md)
+ [Zuweisung von Rechenkontingenten in Amazon SageMaker HyperPod Task Governance](sagemaker-hyperpod-eks-operate-console-ui-governance-policies-compute-allocation.md)
# Erstellen von Richtlinien
Auf der Registerkarte Richtlinien können Sie Ihre **Cluster-Richtlinien** und Konfigurationen **für** die **Compute-Zuweisung** erstellen. Nachfolgend sehen Sie Anweisungen zum Erstellen der folgenden Konfigurationen.
+ Erstellen Sie Ihre **Cluster-Richtlinie**, um zu aktualisieren, wie Aufgaben priorisiert und ungenutzte Rechenleistung zugewiesen wird.
+ Erstellen Sie die **Rechenzuweisung**, um eine neue Richtlinie zur Rechenzuweisung für ein Team zu erstellen.
**Anmerkung**
Wenn Sie eine **Compute-Zuweisung** erstellen, müssen Sie eine rollenbasierte Zugriffskontrolle (RBAC) von Kubernetes für Data-Scientist-Benutzer im entsprechenden Namespace einrichten, um Aufgaben auf Clustern auszuführen, die mit Amazon EKS orchestriert wurden. HyperPod Die Namespaces haben das Format `hyperpod-ns-team-name`. Um einen Kubernetes-RBAC einzurichten, folgen Sie den Anweisungen unter [Teamrolle erstellen](https://github.com/aws/sagemaker-hyperpod-cli/tree/main/helm_chart#5-create-team-role).
Informationen zu den Konzepten der EKS-Clusterrichtlinien zur HyperPod Task-Governance finden Sie unter. [Richtlinien](sagemaker-hyperpod-eks-operate-console-ui-governance-policies.md)
**Erstellen Sie Richtlinien für die HyperPod Task-Governance**
Bei diesem Verfahren wird davon ausgegangen, dass Sie bereits einen Amazon EKS-Cluster erstellt haben, der mit eingerichtet wurde HyperPod. Falls dies noch nicht geschehen ist, finden Sie weitere Informationen unter [Erstellen eines SageMaker HyperPod Clusters mit Amazon EKS-Orchestrierung](sagemaker-hyperpod-eks-operate-console-ui-create-cluster.md).
1. Navigieren Sie zur [Amazon SageMaker AI-Konsole](https://console.aws.amazon.com/sagemaker/).
1. Wählen Sie im linken Navigationsbereich unter **HyperPodCluster** die Option **Cluster Management** aus.
1. Wählen Sie Ihren Amazon EKS-Cluster aus, der unter **SageMaker HyperPodCluster** aufgeführt ist.
1. Wählen Sie die Registerkarte **Policies**.
1. **So erstellen Sie Ihre Cluster-Richtlinie:**
1. Wählen Sie die entsprechende Option **Bearbeiten** aus, um zu aktualisieren, wie Aufgaben priorisiert und ungenutzte Rechenleistung zugewiesen wird.
1. Nachdem Sie Ihre Änderungen durchgeführt haben, wählen Sie **Absenden** aus.
1. Um eine **Compute-Zuweisung** zu erstellen:
1.
1. Wählen Sie die entsprechende Option **Erstellen** aus. Dadurch gelangen Sie zur Seite zum Erstellen von Compute-Allokationen.
1. Nachdem Sie Ihre Änderungen durchgeführt haben, wählen Sie **Absenden** aus.
# Richtlinien bearbeiten
Sie können Ihre **Cluster-Richtlinien** und Konfigurationen für die **Compute-Zuweisung** auf der Registerkarte **Richtlinien** bearbeiten. Nachfolgend sehen Sie Anweisungen zum Bearbeiten der folgenden Konfigurationen.
+ Bearbeiten Sie Ihre **Cluster-Richtlinie**, um zu aktualisieren, wie Aufgaben priorisiert und ungenutzte Rechenleistung zugewiesen wird.
+ Bearbeiten Sie die **Rechenzuweisung**, um eine neue Richtlinie zur Rechenzuweisung für ein Team zu erstellen.
**Anmerkung**
Wenn Sie eine **Compute-Zuweisung** erstellen, müssen Sie eine rollenbasierte Zugriffskontrolle (RBAC) von Kubernetes für Data-Scientist-Benutzer im entsprechenden Namespace einrichten, um Aufgaben auf Clustern auszuführen, die mit Amazon EKS orchestriert wurden. HyperPod Die Namespaces haben das Format `hyperpod-ns-team-name`. Um einen Kubernetes-RBAC einzurichten, folgen Sie den Anweisungen unter [Teamrolle erstellen](https://github.com/aws/sagemaker-hyperpod-cli/tree/main/helm_chart#5-create-team-role).
Weitere Informationen zu den Konzepten der EKS-Clusterrichtlinien zur HyperPod Task-Governance finden Sie unter. [Richtlinien](sagemaker-hyperpod-eks-operate-console-ui-governance-policies.md)
**Bearbeiten Sie die HyperPod Task-Governance-Richtlinien**
Bei diesem Verfahren wird davon ausgegangen, dass Sie bereits einen Amazon EKS-Cluster erstellt haben, der mit eingerichtet wurde HyperPod. Falls dies noch nicht geschehen ist, finden Sie weitere Informationen unter [Erstellen eines SageMaker HyperPod Clusters mit Amazon EKS-Orchestrierung](sagemaker-hyperpod-eks-operate-console-ui-create-cluster.md).
1. Navigieren Sie zur [Amazon SageMaker AI-Konsole](https://console.aws.amazon.com/sagemaker/).
1. Wählen Sie im linken Navigationsbereich unter **HyperPodCluster** die Option **Cluster Management** aus.
1. Wählen Sie Ihren Amazon EKS-Cluster aus, der unter **SageMaker HyperPodCluster** aufgeführt ist.
1. Wählen Sie die Registerkarte **Policies**.
1. So bearbeiten Sie Ihre **Clusterrichtlinie**:
1. Wählen Sie die entsprechende Option **Bearbeiten** aus, um zu aktualisieren, wie Aufgaben priorisiert und ungenutzte Rechenleistung zugewiesen wird.
1. Nachdem Sie Ihre Änderungen durchgeführt haben, wählen Sie **Absenden** aus.
1. So bearbeiten Sie Ihre **Rechenzuweisung**:
1.
1. Wählen Sie unter **Rechenzuweisung** die Konfiguration aus, die Sie bearbeiten möchten. Sie gelangen nun zur Seite mit den Konfigurationsdetails.
1. Wenn Sie diese Konfigurationen bearbeiten möchten, wählen Sie **Bearbeiten** aus.
1. Nachdem Sie Ihre Änderungen durchgeführt haben, wählen Sie **Absenden** aus.
# Löschen von Richtlinien
Sie können Ihre **Cluster-Richtlinien** - und **Compute-Zuweisungskonfigurationen** mithilfe der SageMaker AI-Konsole oder löschen AWS CLI. Auf der folgenden Seite finden Sie Anweisungen zum Löschen Ihrer SageMaker HyperPod Task-Governance-Richtlinien und -Konfigurationen.
Weitere Informationen zu den Konzepten der EKS-Clusterrichtlinien für HyperPod Task Governance finden Sie unter[Richtlinien](sagemaker-hyperpod-eks-operate-console-ui-governance-policies.md).
**Anmerkung**
Sollten Sie Probleme beim Auflisten oder Löschen von Aufgaben-Governance-Richtlinien haben, müssen Sie möglicherweise die Mindestberechtigungen Ihres Clusteradministrators aktualisieren. Weitere Informationen finden Sie im [IAM-Benutzer für den Clusteradministrator](sagemaker-hyperpod-prerequisites-iam.md#sagemaker-hyperpod-prerequisites-iam-cluster-admin) Abschnitt auf der Registerkarte **Amazon EKS**. Weitere Informationen finden Sie unter [Löschen von Clustern](sagemaker-hyperpod-eks-operate-console-ui-governance-troubleshoot.md#hp-eks-troubleshoot-delete-policies).
## HyperPod Task-Governance-Richtlinien löschen (Konsole)
Im Folgenden wird die SageMaker AI-Konsole verwendet, um Ihre HyperPod Task-Governance-Richtlinien zu löschen.
**Anmerkung**
Sie können Ihre **Cluster-Richtlinie** (`ClusterSchedulerConfig`) nicht mit der SageMaker AI-Konsole löschen. Informationen dazu mit dem finden Sie AWS CLI unter[Löschen Sie die Richtlinien zur HyperPod Aufgabenverwaltung (AWS CLI)](#sagemaker-hyperpod-eks-operate-console-ui-governance-policies-delete-cli).
**So löschen Sie Richtlinien zur Aufgaben-Governance (Konsole)**
1. Navigieren Sie zur [Amazon SageMaker AI-Konsole](https://console.aws.amazon.com/sagemaker/).
1. Wählen Sie im linken Navigationsbereich unter **HyperPodCluster** die Option **Cluster Management** aus.
1. Wählen Sie Ihren Amazon EKS-Cluster aus, der unter **SageMaker HyperPodCluster** aufgeführt ist.
1. Wählen Sie die Registerkarte **Policies**.
1. So löschen Sie Ihre **Rechenzuweisung** (`ComputeQuota`):
1. Wählen Sie im Abschnitt **Rechenzuweisung** die Konfiguration aus, die Sie löschen möchten.
1. Wählen Sie im Dropdown-Menü **Aktionen** die Option **Löschen** aus.
1. Befolgen Sie die Anweisungen in der Benutzeroberfläche, um die Aufgabe abzuschließen.
## Löschen Sie die Richtlinien zur HyperPod Aufgabenverwaltung (AWS CLI)
Im Folgenden werden die verwendet AWS CLI , um Ihre HyperPod Task-Governance-Richtlinien zu löschen.
**Anmerkung**
Wenn Sie Probleme mit der Verwendung der folgenden Befehle haben, müssen Sie möglicherweise Ihre aktualisieren AWS CLI. Weitere Informationen finden Sie unter [Installieren oder Aktualisierung auf die neueste Version der AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html).
**So löschen Sie Aufgaben-Governance-Richtlinien (AWS CLI)**
Stellen Sie zunächst Ihre Variablen für die folgenden AWS CLI Befehle ein.
```
REGION=aws-region
```
1. Holen Sie sich die mit den Richtlinien *cluster-arn* verknüpften Richtlinien, die Sie löschen möchten. Sie können den folgenden AWS CLI Befehl verwenden, um die Cluster in Ihrem aufzulisten AWS-Region.
```
aws sagemaker list-clusters \
--region ${REGION}
```
1. So löschen Sie Ihre Rechenzuweisungen (`ComputeQuota`):
1. Listet alle Rechenkontingente auf, die dem HyperPod Cluster zugeordnet sind.
```
aws sagemaker list-compute-quotas \
--cluster-arn cluster-arn \
--region ${REGION}
```
1. Führen Sie für jeden `compute-quota-id`, den Sie löschen möchten, den folgenden Befehl aus, um das Rechenkontingent zu löschen.
```
aws sagemaker delete-compute-quota \
--compute-quota-id compute-quota-id \
--region ${REGION}
```
1. So löschen Sie Ihre Clusterrichtlinien (`ClusterSchedulerConfig`):
1. Listet alle Clusterrichtlinien auf, die dem HyperPod Cluster zugeordnet sind.
```
aws sagemaker list-cluster-scheduler-configs \
--cluster-arn cluster-arn \
--region ${REGION}
```
1. Führen Sie für jeden `cluster-scheduler-config-id`, den Sie löschen möchten, den folgenden Befehl aus, um das Rechenkontingent zu löschen.
```
aws sagemaker delete-cluster-scheduler-config
--cluster-scheduler-config-id scheduler-config-id \
--region ${REGION}
```
# Zuweisung von Rechenkontingenten in Amazon SageMaker HyperPod Task Governance
Clusteradministratoren können entscheiden, wie die Organisation gekaufte Rechenleistung verwendet. Dadurch werden Verschwendung und ungenutzte Ressourcen reduziert. Sie können Rechenquoten so zuweisen, dass sich Teams ungenutzte Ressourcen gegenseitig ausleihen können. Die Berechnung der Quotenzuweisung in HyperPod Task Governance ermöglicht es Administratoren, Ressourcen auf Instanzebene und auf detaillierterer Ressourcenebene zuzuweisen. Diese Funktion ermöglicht ein flexibles und effizientes Ressourcenmanagement für Teams, indem sie eine detaillierte Kontrolle über einzelne Rechenressourcen ermöglicht, anstatt ganze Instance-Zuweisungen erforderlich zu machen. Durch die Zuweisung auf granularer Ebene werden Ineffizienzen der herkömmlichen Zuweisung auf Instance-Ebene vermieden. Durch diesen Ansatz können Sie die Ressourcennutzung optimieren und ungenutzte Rechenleistung reduzieren.
Die Compute-Kontingentzuweisung unterstützt drei Arten der Ressourcenzuweisung: Beschleuniger, vCPU und Arbeitsspeicher. Beschleuniger sind Komponenten in beschleunigten ComputerInstances, die Funktionen wie Berechnungen von Gleitkommazahlen, Grafikverarbeitung oder Mustererkennung in Daten ausführen. Zu den Beschleunigern gehören GPUs Trainium-Beschleuniger und Neuronenkerne. Bei der gemeinsamen Nutzung von GPUs durch mehrere Teams können verschiedene Teams spezifische GPU-Zuweisungen vom gleichen Instance-Typ erhalten, wodurch die Auslastung der Beschleuniger-Hardware maximiert wird. Für speicherintensive Workloads, die zusätzlichen Arbeitsspeicher für Datenvorverarbeitungs- oder Modell-Caching-Szenarien benötigen, können Sie ein Speicherkontingent zuweisen, das über das Standardverhältnis hinausgeht. GPU-to-memory Für CPU-intensive Vorverarbeitungsaufgaben, die neben dem GPU-Training auch erhebliche CPU-Ressourcen benötigen, können Sie eine unabhängige CPU-Ressourcenzuweisung zuweisen.
Sobald Sie einen Wert eingegeben haben, berechnet HyperPod Task Governance das Verhältnis anhand der Formel **zugewiesene Ressourcen geteilt durch die Gesamtmenge der in der Instanz verfügbaren** Ressourcen. HyperPod Task Governance verwendet dann dieses Verhältnis, um Standardzuweisungen auf andere Ressourcen anzuwenden. Sie können diese Standardwerte jedoch überschreiben und sie an Ihren Anwendungsfall anpassen. Im Folgenden finden Sie Beispielszenarien dafür, wie HyperPod Task Governance Ressourcen auf der Grundlage Ihrer Werte zuweist:
+ **Nur Beschleuniger angegeben** — HyperPod Task Governance wendet das Standardverhältnis auf vCPU und Arbeitsspeicher auf der Grundlage der Beschleunigerwerte an.
+ **Nur vCPU angegeben** — HyperPod Task Governance berechnet das Verhältnis und wendet es auf den Arbeitsspeicher an. Beschleuniger sind auf 0 gesetzt.
+ **Nur Arbeitsspeicher angegeben** — HyperPod Task Governance berechnet das Verhältnis und wendet es auf vCPU an, da Rechenleistung erforderlich ist, um speicherspezifische Workloads auszuführen. Beschleuniger sind auf 0 gesetzt.
Um die Quotenzuweisung programmgesteuert zu steuern, können Sie das [ ComputeQuotaResourceConfig](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_ComputeQuotaResourceConfig.html)Objekt verwenden und Ihre Zuweisungen in Ganzzahlen angeben.
```
{
"ComputeQuotaConfig": {
"ComputeQuotaResources": [{
"InstanceType": "ml.g5.24xlarge",
"Accelerators": "16",
"vCpu": "200.0",
"MemoryInGiB": "2.0"
}]
}
}
```
Verwenden Sie die Operation, um alle zugewiesenen Zuweisungen, einschließlich der Standardzuweisungen, anzuzeigen. [ DescribeComputeQuota](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_DescribeComputeQuota.html) Verwenden Sie den Vorgang, um Ihre Zuordnungen zu aktualisieren. [ UpdateComputeQuota](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_UpdateComputeQuota.html)
Sie können die HyperPod CLI auch verwenden, um Rechenkontingente zuzuweisen. Weitere Informationen zur HyperPod CLI finden Sie unter[Ausführung von Jobs auf SageMaker HyperPod Clustern, die von Amazon EKS orchestriert wurden](sagemaker-hyperpod-eks-run-jobs.md). Das folgende Beispiel zeigt, wie Rechenkontingente mithilfe der HyperPod CLI festgelegt werden.
```
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
```
Gehen Sie folgendermaßen vor, um Kontingente mithilfe der AWS Konsole zuzuweisen.
1. Öffnen Sie die Amazon SageMaker AI-Konsole unter [https://console.aws.amazon.com/sagemaker/](https://console.aws.amazon.com/sagemaker/).
1. Wählen Sie unter HyperPod Cluster die Option **Clusterverwaltung** aus.
1. Wählen Sie unter **Rechenzuweisung** die Option **Erstellen** aus.
1. Wenn Sie noch keine Instances haben, wählen Sie **Zuweisung hinzufügen** aus, um eine Instance hinzuzufügen.
1. Wählen Sie unter **Zuweisungen** aus, ob die Zuweisung nach Instances oder einzelnen Ressourcen erfolgen soll. Wenn Sie die Zuteilung nach einzelnen Ressourcen vornehmen, weist SageMaker KI anderen Ressourcen automatisch Allokationen in dem von Ihnen ausgewählten Verhältnis zu. Um diese verhältnisbasierte Zuordnung zu überschreiben, verwenden Sie den entsprechenden Schalter, um diese Berechnung zu überschreiben.
1. Wiederholen Sie die Schritte 4 und 5, um weitere Instances zu konfigurieren.
Nachdem Sie das Rechenkontingent zugewiesen haben, können Sie Jobs über die HyperPod CLI oder `kubectl` einreichen. HyperPodplant Workloads effizient auf der Grundlage des verfügbaren Kontingents.
# Zuweisung des GPU-Partitionskontingents
Sie können die Zuweisung von Rechenkontingenten erweitern, um die GPU-Partitionierung zu unterstützen und so eine differenzierte gemeinsame Nutzung von Ressourcen auf GPU-Partitionsebene zu ermöglichen. Wenn die GPU-Partitionierung aktiviert ist oder im Cluster unterstützt wird, kann jede physische GPU GPUs in mehrere isolierte GPUs GPUs mit definierten Rechen-, Arbeitsspeicher- und Streaming-Multiprozessor-Zuweisungen partitioniert werden. Weitere Informationen zur GPU-Partitionierung finden Sie unter. [Verwenden von GPU-Partitionen in Amazon SageMaker HyperPod](sagemaker-hyperpod-eks-gpu-partitioning.md) Sie können Gruppen bestimmte GPU-Partitionen zuweisen, sodass mehrere Teams dieselbe GPU gemeinsam nutzen können. Gleichzeitig bleiben die Isolierung auf Hardwareebene und die vorhersehbare Leistung erhalten.
Beispielsweise kann eine ml.p5.48xlarge-Instance mit 8 H100 in GPU-Partitionen partitioniert werden, und Sie GPUs können einzelnen Teams je nach Aufgabenanforderungen einzelne Partitionen zuweisen. Wenn Sie GPU-Partitionszuweisungen angeben, berechnet HyperPod Task Governance proportionale vCPU- und Speicherkontingente auf der Grundlage der GPU-Partition, ähnlich der Zuweisung auf GPU-Ebene. Dieser Ansatz maximiert die GPU-Auslastung, indem ungenutzte Kapazitäten eliminiert und eine kostengünstige gemeinsame Nutzung von Ressourcen für mehrere gleichzeitige Aufgaben auf derselben physischen GPU ermöglicht wird.
## Rechenkontingente erstellen
```
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
}
}'
```
## Quota-Ressourcen überprüfen
```
# Check ClusterQueue
kubectl get clusterqueues
kubectl describe clusterqueue QUEUE_NAME
# Check ResourceFlavors
kubectl get resourceflavor
kubectl describe resourceflavor FLAVOR_NAME
```
# Beispiele für HyperPod Task-Governance-Befehle AWS CLI
Sie können es HyperPod mit EKS über Kubectl oder über eine HyperPod benutzerdefinierte CLI verwenden. Sie können diese Befehle über Studio oder verwenden. AWS CLI Im Folgenden finden Sie Beispiele zur SageMaker HyperPod Task-Governance, die zeigen, wie Sie Clusterdetails mithilfe der HyperPod AWS CLI Befehle anzeigen können. Weitere Informationen, einschließlich der Installation, finden Sie im [HyperPod CLI-Github-Repository](https://github.com/aws/sagemaker-hyperpod-cli).
**Topics**
+ [Informationen zum Cluster-Accelerator-Gerätekontingent](#hp-eks-cli-get-clusters)
+ [Senden Sie einen Job an eine von SageMaker KI verwaltete Warteschlange und einen Namespace](#hp-eks-cli-start-job)
+ [Auflisten von Aufträgen](#hp-eks-cli-list-jobs)
+ [Detaillierte Informationen zum Auftrag](#hp-eks-cli-get-job)
+ [Jobs aussetzen und die Aussetzung rückgängig machen](#hp-eks-cli-patch-job)
+ [Debuggen von Aufträgen](#hp-eks-cli-other)
## Informationen zum Cluster-Accelerator-Gerätekontingent
Mit dem folgenden Beispielbefehl werden Informationen zum Cluster Accelerator-Gerätekontingent abgerufen.
```
hyperpod get-clusters -n hyperpod-ns-test-team
```
Der Namespace in diesem Beispiel, `hyperpod-ns-test-team`, wird in Kubernetes auf Grundlage des angegebenen Teamnamens, `test-team`, erstellt, wenn die Rechenzuweisung erstellt wird. Weitere Informationen finden Sie unter [Richtlinien bearbeiten](sagemaker-hyperpod-eks-operate-console-ui-governance-policies-edit.md).
Beispielantwort:
```
[
{
"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
}
}
}
]
```
## Senden Sie einen Job an eine von SageMaker KI verwaltete Warteschlange und einen Namespace
Mit dem folgenden Beispielbefehl wird ein Job an Ihren Cluster gesendet. HyperPod Wenn Sie nur Zugriff auf ein Team haben, HyperPod AWS CLI wird Ihnen die Warteschlange in diesem Fall automatisch zugewiesen. Andernfalls, wenn mehrere Warteschlangen entdeckt werden, zeigen wir dir alle praktikablen Optionen an, die du auswählen kannst.
```
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
```
Die Prioritätsklassen sind in der **Clusterrichtlinie** definiert, die festlegt, wie Aufgaben priorisiert und ungenutzte Rechenleistung zugewiesen wird. Wenn ein Datenwissenschaftler einen Auftrag einreicht, verwendet er einen der Prioritätsklassen-Namen im Format `priority-class-name-priority`. `training-priority`Bezieht sich in diesem Beispiel auf die Prioritätsklasse mit dem Namen „Training“. Weitere Informationen zu Richtlinienkonzepten finden Sie unter [Richtlinien](sagemaker-hyperpod-eks-operate-console-ui-governance-policies.md).
Wenn keine Prioritätsklasse angegeben ist, wird der Job als Job mit niedriger Priorität behandelt, wobei der Wert 0 für die Aufgabenrangfolge lautet.
Wenn eine Prioritätsklasse angegeben ist, diese aber keiner der in der **Clusterrichtlinie** definierten Prioritätsklassen entspricht, schlägt die Übermittlung fehl und eine Fehlermeldung gibt die definierten Prioritätsklassen an.
Sie können den Job auch mithilfe einer YAML-Konfigurationsdatei mithilfe des folgenden -Befehls einreichen:
```
hyperpod start-job --config-file ./yaml-configuration-file-name.yaml
```
Im Folgenden finden Sie ein Beispiel für eine YAML-Konfigurationsdatei, die dem oben beschriebenen Einreichen eines Jobs entspricht.
```
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
```
Alternativ können Sie einen Job einreichen, indem Sie sicherstellen`kubectl`, dass die Aufgabe auf der Registerkarte **Dashboard** angezeigt wird. Nachfolgend finden Sie ein Beispiel für einen kubectl-Befehl.
```
kubectl apply -f ./yaml-configuration-file-name.yaml
```
Geben Sie beim Absenden des Jobs den Namen Ihrer Warteschlange und die Bezeichnungen der Prioritätsklassen an. Zum Beispiel müssen Sie zusammen mit dem Namen der Warteschlange `hyperpod-ns-team-name-localqueue` und der Prioritätsklasse `priority-class-name-priority` die folgenden Labels angeben:
+ `kueue.x-k8s.io/queue-name: hyperpod-ns-team-name-localqueue`
+ `kueue.x-k8s.io/priority-class: priority-class-name-priority`
**Der folgende YAML-Konfigurationsausschnitt zeigt, wie Sie Ihrer ursprünglichen Konfigurationsdatei Labels hinzufügen, um sicherzustellen, dass Ihre Aufgabe auf der Registerkarte Dashboard angezeigt wird:**
```
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
```
## Auflisten von Aufträgen
Der folgende Befehl listet die Jobs und ihre Details auf.
```
hyperpod list-jobs
```
Beispielantwort:
```
{
"jobs": [
{
"Name": "hyperpod-cli-test",
"Namespace": "hyperpod-ns-test-team",
"CreationTime": "2024-11-18T21:21:15Z",
"Priority": "training",
"State": "Succeeded"
}
]
}
```
## Detaillierte Informationen zum Auftrag
Der folgende Befehl stellt die Details eines Jobs bereit. Wenn kein Namespace angegeben ist, HyperPod AWS CLI wird ein von SageMaker AI verwalteter Namespace abgerufen, auf den Sie Zugriff haben.
```
hyperpod get-job --job-name hyperpod-cli-test
```
Beispielantwort:
```
{
"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“
}
```
## Jobs aussetzen und die Aussetzung rückgängig machen
Wenn Sie einen eingereichten Job aus dem Scheduler entfernen möchten, HyperPod AWS CLI bietet dieser `suspend` Befehl, um den Job vorübergehend aus der Orchestrierung zu entfernen. Der unterbrochene Job wird nicht mehr geplant, es sei denn, der Job wird manuell durch den Befehl aufgehoben `unsuspend`
Um einen Job vorübergehend auszusetzen:
```
hyperpod patch-job suspend --job-name hyperpod-cli-test
```
Um einen Job wieder zur Warteschlange hinzuzufügen:
```
hyperpod patch-job unsuspend --job-name hyperpod-cli-test
```
## Debuggen von Aufträgen
Der bietet HyperPod AWS CLI auch andere Befehle, mit denen Sie Probleme bei der Auftragsübermittlung beheben können. Zum Beispiel `list-pods` und `get-logs` im HyperPod AWS CLI Github-Repository.
# Fehlerbehebung
Die folgende Seite enthält bekannte Lösungen zur Fehlerbehebung bei Ihren HyperPod EKS-Clustern.
**Topics**
+ [Registerkarte Dashboard](#hp-eks-troubleshoot-dashboard)
+ [Registerkarte „Aufgaben“](#hp-eks-troubleshoot-tasks)
+ [Richtlinien](#hp-eks-troubleshoot-policies)
+ [Löschen von Clustern](#hp-eks-troubleshoot-delete-policies)
+ [Gemeinsame Nutzung nicht zugewiesener Ressourcen](#hp-eks-troubleshoot-unallocated-resource-sharing)
## Registerkarte Dashboard
**Die Installation des EKS-Add-ons ist fehlgeschlagen.**
Damit die Installation des EKS-Add-ons erfolgreich ist, benötigen Sie eine Kubernets-Version >= 1.30. [Informationen zum Update finden Sie unter Kubernetes-Version aktualisieren.](https://docs.aws.amazon.com/eks/latest/userguide/update-cluster.html)
Damit die Installation des EKS-Add-ons erfolgreich ist, müssen sich alle Knoten im Status **Bereit** und alle Pods im Status **Running** befinden.
Um den Status Ihrer Knoten zu überprüfen, verwenden Sie den [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 Befehl oder navigieren Sie in der [EKS-Konsole zu Ihrem EKS-Cluster](https://console.aws.amazon.com/eks/home#/clusters) und sehen Sie sich den Status Ihrer Knoten an. Beheben Sie das Problem für jeden Knoten oder wenden Sie sich an Ihren Administrator. Wenn der Knotenstatus **Unbekannt** ist, löschen Sie den Knoten. Sobald der Status aller Knoten „**Bereit**“ lautet, versuchen Sie erneut, das EKS-Add-on HyperPod von der [Amazon SageMaker AI-Konsole](https://console.aws.amazon.com/sagemaker/) aus zu installieren.
Um den Status Ihrer Pods zu überprüfen, verwenden Sie den [Kubernetes-CLI](https://kubernetes.io/docs/reference/kubectl/)-Befehl `kubectl get pods -n cloudwatch-agent` oder navigieren Sie in der EKS-Konsole[ zu Ihrem EKS-Cluster](https://console.aws.amazon.com/eks/home#/clusters) und zeigen Sie den Status Ihrer Pods mit dem Namespace `cloudwatch-agent` an. Beheben Sie das Problem mit den Pods oder wenden Sie sich an Ihren Administrator, um das Problem zu lösen. Sobald alle Pod-Status „Wird **ausgeführt**“ lauten, versuchen Sie erneut, das EKS-Add-on HyperPod von der [Amazon SageMaker AI-Konsole](https://console.aws.amazon.com/sagemaker/) aus zu installieren.
Weitere Informationen zur Fehlerbehebung finden Sie unter [Fehlerbehebung beim Amazon CloudWatch Observability EKS-Add-on](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/install-CloudWatch-Observability-EKS-addon.html#Container-Insights-setup-EKS-addon-troubleshoot).
## Registerkarte „Aufgaben“
Wenn Ihnen die Fehlermeldung angezeigt wird, dass die **benutzerdefinierte Ressourcendefinition (CRD) auf dem Cluster nicht konfiguriert ist**, gewähren Sie Ihrer Domain-Ausführungsrolle Rechte `EKSAdminViewPolicy` und `ClusterAccessRole` Richtlinien.
+ Weitere Informationen zum Abrufen Ihrer Ausführungsrolle finden Sie unter [Abrufen Ihrer Ausführungsrolle](sagemaker-roles.md#sagemaker-roles-get-execution-role).
+ Informationen zum Hinzufügen von Richtlinien zu einem IAM-Benutzer oder einer IAM-Gruppe finden Sie unter [Hinzufügen und Entfernen von IAM-Identitätsberechtigungen](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html).
## Richtlinien
Im Folgenden werden Lösungen für Fehler im Zusammenhang mit Richtlinien aufgeführt, die die HyperPod APIs OR-Konsole verwenden.
+ Wenn sich die Richtlinie in `CreateFailed` oder im `CreateRollbackFailed` Status befindet, müssen Sie die fehlgeschlagene Richtlinie löschen und eine neue erstellen.
+ Wenn die Richtlinie im Status `UpdateFailed` ist, versuchen Sie die Aktualisierung mit derselben Richtlinien-ARN erneut.
+ Wenn die Richtlinie den `UpdateRollbackFailed` Status hat, müssen Sie die fehlgeschlagene Richtlinie löschen und anschließend eine neue erstellen.
+ Wenn die Richtlinie im Status `DeleteFailed` und ist, versuchen Sie erneut, sie mit derselben Richtlinien-ARN zu löschen.
+ Wenn Sie beim Versuch, die **Compute-Priorisierung** oder Cluster-Richtlinie über die HyperPod Konsole zu löschen, auf einen Fehler gestoßen sind, versuchen Sie, diese `cluster-scheduler-config` mithilfe der API zu löschen. Um den Status der Ressource zu überprüfen, rufen Sie die Detailseite einer Rechenzuweisung auf.
Verwenden Sie die Describe-API, um weitere Informationen zu dem Fehler zu erhalten.
## Löschen von Clustern
Im Folgenden sind bekannte Lösungen für Fehler im Zusammenhang mit dem Löschen von Clustern aufgeführt.
+ Wenn das Löschen des Clusters aufgrund der beigefügten SageMaker HyperPod Task-Governance-Richtlinien fehlschlägt, müssen Sie dies tun[Löschen von Richtlinien](sagemaker-hyperpod-eks-operate-console-ui-governance-policies-delete.md).
+ Wenn das Löschen eines Clusters fehlschlägt, weil die folgenden Berechtigungen fehlen, müssen Sie die Mindestberechtigungen Ihres Clusteradministrators aktualisieren. Weitere Informationen finden Sie im [IAM-Benutzer für den Clusteradministrator](sagemaker-hyperpod-prerequisites-iam.md#sagemaker-hyperpod-prerequisites-iam-cluster-admin) Abschnitt auf der Registerkarte **Amazon EKS**.
+ `sagemaker:ListComputeQuotas`
+ `sagemaker:ListClusterSchedulerConfig`
+ `sagemaker:DeleteComputeQuota`
+ `sagemaker:DeleteClusterSchedulerConfig`
## Gemeinsame Nutzung nicht zugewiesener Ressourcen
Wenn die Kapazität Ihres nicht zugewiesenen Ressourcenpools geringer als erwartet ist:
1. **Überprüfen Sie den Status des Knotens bereit**
```
kubectl get nodes
```
Stellen Sie sicher, dass alle Knoten `Ready` den Status in der STATUS-Spalte anzeigen.
1. **Überprüfen Sie den Status des Knotens, der planbar ist**
```
kubectl get nodes -o custom-columns=NAME:.metadata.name,UNSCHEDULABLE:.spec.unschedulable
```
Überprüfen Sie, ob die Knoten angezeigt `` werden `false` oder nicht`true`.
1. **Listet die gemeinsame Nutzung ClusterQueues nicht zugewiesener Ressourcen auf:**
```
kubectl get clusterqueue | grep hyperpod-ns-idle-resource-sharing
```
Dies zeigt alle nicht zugewiesenen Ressourcen, die gemeinsam genutzt werden. ClusterQueues Wenn sie nicht angezeigt ClusterQueues werden, überprüfen Sie in der `FailureReason` nachfolgenden ClusterSchedulerConfig Richtlinie, ob es Fehlermeldungen gibt, um das Debuggen fortzusetzen.
1. **Überprüfen Sie das Kontingent für die gemeinsame Nutzung nicht zugewiesener Ressourcen**
```
kubectl describe clusterqueue hyperpod-ns-idle-resource-sharing-
```
In dem `spec.resourceGroups[].flavors[].resources` Abschnitt finden Sie das für die einzelnen Ressourcenarten zugewiesene Kontingent.
Abhängig von der Anzahl der Ressourcenvarianten in Ihrem Cluster ClusterQueues können mehrere nicht zugewiesene Ressourcen gemeinsam genutzt werden.
1. **Überprüfen Sie den MIG-Konfigurationsstatus (GPU-Knoten):**
```
kubectl get nodes -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.metadata.labels.nvidia\.com/mig\.config\.state}{"\n"}{end}'
```
Überprüfen Sie, ob MIG-fähige Knoten den Status anzeigen`success`.
# Zuweisungsdokument für Amazon SageMaker HyperPod Task Governance
Im Folgenden erfahren Sie mehr über Quellenangaben und Drittanbieterlizenzen für Materialien, die im Rahmen der Amazon SageMaker HyperPod Task Governance verwendet werden.
**Topics**
+ [[Basisdateien](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)
## [Basisdateien](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.
```
# Nutzungsberichte für die Kostenzuweisung in SageMaker HyperPod
Die Nutzungsberichterstattung in SageMaker HyperPod EKS-orchestrierten Clustern bietet einen detaillierten Einblick in den Rechenressourcenverbrauch. Diese Funktion ermöglicht es Unternehmen, eine transparente Kostenzuweisung zu implementieren und die Cluster-Kosten Teams, Projekten oder Abteilungen auf der Grundlage ihrer tatsächlichen Nutzung zuzuweisen. Durch die Erfassung von Kennzahlen wie GPU/CPU Stunden und Neuron Core-Auslastung, die *sowohl in Aggregaten auf Teamebene als auch in aufgabenspezifischen Aufschlüsselungen erfasst werden, ergänzt die Nutzungsberichterstattung die Task-Governance-Funktionalität und* [gewährleistet eine faire Kostenverteilung in gemeinsam genutzten HyperPod Multi-Tenant-Clustern](sagemaker-hyperpod-eks-operate-console-ui-governance.md) durch:
+ Schluss mit Rätselraten bei der Kostenzuweisung
+ Direkte Verknüpfung von Ausgaben mit messbarem Ressourcenverbrauch
+ Durchsetzung der nutzungsbasierten Rechenschaftspflicht in Umgebungen mit gemeinsam genutzter Infrastruktur
## Voraussetzungen
So nutzen Sie diese Funktion:
+ Sie benötigen:
+ Eine aktive **SageMaker HyperPod Umgebung** mit einem laufenden EKS-orchestrierten Cluster.
+ (Dringend empfohlen) **Task Governance, konfiguriert** mit Rechenkontingenten und Prioritätsregeln. Anweisungen zur Einrichtung finden Sie unter [Einrichtung von Task Governance](sagemaker-hyperpod-eks-operate-console-ui-governance-setup.md).
+ Machen Sie sich mit diesen Kernkonzepten vertraut:
+ **Zugewiesenes Rechenkontingent:** Ressourcen, die einem Team auf der Grundlage vordefinierter Kontingente in den Richtlinien zur Aufgaben-Governance vorbehalten sind. Das ist *garantierte Kapazität* für ihre Workloads.
+ **Ausgeliehene Rechenleistung:** Ungenutzte Ressourcen aus dem gemeinsam genutzten Clusterpool, die Teams vorübergehend *über ihr zugewiesenes Kontingent hinaus* nutzen können. Die ausgeliehene Rechenleistung wird dynamisch zugewiesen, basierend auf den Prioritätsregeln in den Richtlinien zur Aufgaben-Governance und der Verfügbarkeit ungenutzter Ressourcen.
+ **Computernutzung:** Die Messung der von einem Team verbrauchten Ressourcen (GPU, CPU, Neuron Core-Stunden) wird wie folgt erfasst:
+ **Zugewiesene Auslastung**: Nutzung innerhalb des Kontingents des Teams.
+ **Ausgeliehene Nutzung**: Nutzung, die über das Kontingent hinausgeht und aus dem gemeinsamen Pool stammt.
+ **Kostenzuweisung:** Der Prozess der Zuweisung von Cluster-Kosten an Teams auf der Grundlage ihrer *tatsächlichen Computernutzung*, einschließlich der Ressourcen, die innerhalb ihres vordefinierten Kontingents verbraucht wurden, und der Ressourcen, die vorübergehend aus dem gemeinsam genutzten Cluster-Pool verwendet wurden, außerhalb ihres Kontingents.
## Berichtstypen
HyperPodDie Nutzungsberichte bieten unterschiedliche betriebliche Granularität:
+ **Übersichtsberichte** bieten unternehmensweite Einblicke in die Computernutzung. Sie aggregieren die gesamten GPU/CPU/Neuron Kernstunden pro Team (Namespace) und unterscheiden dabei zwischen *regulärer Nutzung* (Ressourcen aus dem zugewiesenen Kontingent eines Teams) und *geliehener Rechenleistung* (Überkapazität aus gemeinsam genutzten Pools).
+ **Detaillierte Berichte** bieten Aufschlüsselungen auf Aufgabenebene nach Teams und verfolgen die exakten Rechenstunden, die für die Ausführung bestimmter Aufgaben aufgewendet wurden – einschließlich Aufgaben, die zuvor ausgeführt wurden, stündliche Nutzungsmuster und nameBereichepezifische Zuweisungen.
**Wichtig**
HyperPod Die Nutzungsberichterstattung verfolgt die Computernutzung in *allen Kubernetes-Namespaces* in einem Cluster — einschließlich der von Task Governance verwalteten Namespaces, Standard-Namespaces und Namespaces, die **außerhalb von Task Governance** erstellt wurden (z. B. über direkte Kubernetes-API-Aufrufe oder externe Tools). Diese Überwachung auf Infrastrukturebene gewährleistet eine umfassende nutzungsbasierte Rechenschaftspflicht und verhindert so Lücken bei der Kostenzuweisung für gemeinsam genutzte Cluster, unabhängig davon, wie NameBereiche verwaltet werden.
## Formate und Zeitraum der Berichte
Mithilfe des unter [Berichte erstellen](sagemaker-hyperpod-usage-reporting-generate.md) bereitgestellten Python-Skripts können Administratoren Nutzungsberichte auf Abruf im CSV- oder PDF-Format erstellen und dabei Zeitbereiche von täglichen Schnappschüssen bis hin zu historischen Zeitfenstern mit 180 Tagen (6 Monaten) auswählen.
**Anmerkung**
Bei der Einrichtung der Berichtsinfrastruktur können Sie das historische Fenster so konfigurieren, dass es über das standardmäßige Maximum von 180 Tagen hinausgeht. [Weitere Informationen zur Konfiguration des Datenaufbewahrungszeitraums finden Sie unter Installation der Usage Report Infrastructure using. CloudFormation](https://github.com/awslabs/sagemaker-hyperpod-usage-report/blob/main/README.md#install-usage-report-infrastructure-using-cloudformation)
## Anschauliche Anwendungsfälle
Diese Funktion eignet sich für kritische Szenarien in AI/ML Umgebungen mit mehreren Mandanten, z. B.:
1. **Kostenzuweisung für gemeinsam genutzte Cluster**: Ein Administrator verwaltet einen HyperPod Cluster, der von 20 Teams gemeinsam genutzt wird, die generative KI-Modelle trainieren. Anhand eines *zusammenfassenden Nutzungsberichts* analysieren sie die tägliche GPU-Auslastung über einen Zeitraum von 180 Tagen und stellen fest, dass Team A 200 GPU-Stunden eines bestimmten Instance-Typs verbraucht hat – 170 aus ihrem zugewiesenen Kontingent und 30 aus ausgeliehenen Rechenressourcen. Der Administrator stellt Team A auf der Grundlage dieser gemeldeten Nutzung eine Rechnung.
1. **Prüfung und Streitbeilegung**: Ein Finanzteam stellt die Richtigkeit der Kostenzurechnung in Frage und führt Inkonsistenzen an. Der Administrator kann einen *detaillierten Bericht auf Aufgabenebene* exportieren, um Unstimmigkeiten zu prüfen. Durch den Abgleich von Zeitstempeln, Instance-Typen und vorrangigen Aufträgen innerhalb des Namensraums des Teams werden umstrittene Nutzungsdaten in dem Bericht transparent abgeglichen.
# Berichte, Einzelheiten und Aufschlüsselung der Daten
SageMaker HyperPodDie Nutzungsberichte bieten zwei unterschiedliche Möglichkeiten zur Analyse des Rechenressourcenverbrauchs: **Übersichtsberichte** für die Kostenzuweisung und **detaillierte Berichte** für detaillierte Prüfungen. Übersichtsberichte aggregieren die clusterweite Nutzung nach Team oder Namespace und heben Trends bei zugewiesener und geliehener Rechenleistung für GPU-, CPU- und Neuron Core-Ressourcen hervor. Detaillierte Berichte gehen detailliert auf einzelne Aufgaben ein und enthalten Kennzahlen wie Ausführungsfenster, Aufgabenstatus und Auslastung nach Prioritätsklassen. In diesem Abschnitt gehen wir auf die Struktur dieser Berichte ein, verstehen ihre wichtigsten Kennzahlen und zeigen, wie Administratoren und Finanzteams zusammenfassende Trends mit Daten auf Aufgabenebene vergleichen können, um die Genauigkeit der Kostenzuweisung zu überprüfen, Unstimmigkeiten zu beheben und die gemeinsam genutzte Infrastruktur zu optimieren.
## Allgemeine Berichtskopfzeilen
Sowohl zusammenfassende als auch detaillierte Berichte enthalten die folgenden Metadaten zur Kontextualisierung der Nutzungsdaten:
+ **ClusterName:** Der Name des EKS-orchestrierten Hyperpod-Clusters, in dem Ressourcen verbraucht wurden.
+ **Typ:** die Berichtskategorie (`Summary Utilization Report` oder `Detailed Utilization Report`).
+ **Generierungsdatum:** Datum, an dem der Bericht erstellt wurde (z. B. `2025-04-18`).
+ **Datumsbereich (UTC):** der abgedeckte Zeitraum (z. B. `2025-04-16 to 2025-04-18`).
+ **Fehlende Datenperioden:** Lücken bei der Datenerfassung aufgrund von Cluster-Ausfallzeiten oder Überwachungsproblemen (z. B. `2025-04-16 00:00:00 to 2025-04-19 00:00:00`).
## Zusammenfassungsberichte
Zusammenfassende Berichte bieten einen täglichen Überblick über den Verbrauch von Rechenressourcen in verschiedenen Teams/Namespaces und Instance-Typen, wobei zwischen zugewiesener (reserviertes Kontingent) und ausgeliehener (ausgeliehener Pool) Nutzung unterschieden wird. Diese Berichte eignen sich ideal für die Erstellung von Rechnungen, Kostenzuweisungen oder Kapazitätsprognosen.
*Beispiel: Ein zusammenfassender Bericht könnte zeigen, dass Team A 200 GPU-Stunden genutzt hat – 170 Stunden aus dem zugewiesenen Kontingent und 30 geliehene.*
Im Folgenden finden Sie eine strukturierte Aufschlüsselung der wichtigsten Spalten in einem zusammenfassenden Bericht:
+ **Datum:** das Datum der gemeldeten Nutzung (z. B. `2025-04-18`).
+ **Namespace:** der dem Team zugeordnete Kubernetes-Namespace (z. B. `hyperpod-ns-ml-team`).
+ **Team:** The Owning team/department (z. B.). `ml-team`
+ **Instance-Typ:** die verwendete Rechen-Instance (z. B. ml.g5.4xlarge).
+ **Total/Allocated/BorrowedAuslastung (Stunden):** Die Aufschlüsselung der GPU-, CPU- oder Neuron Core-Nutzung nach Kategorien.
Wobei Folgendes gilt:
+ **Gesamtauslastung = Zugewiesene Auslastung \$1 Ausgelehnte Auslastung**
+ Die **zugewiesene Auslastung** ist die tatsächliche GPU-CPU oder Neuron Core-Stunden, die ein Team genutzt hat, begrenzt auf 100% des zugewiesenen Kontingents.
+ Die **ausgeliehene Nutzung** bezieht sich auf die tatsächlichen GPU-, CPU- oder Neuron-Core-Stunden, die ein Team *über sein zugewiesenes Kontingent hinaus* genutzt hat. Diese werden aus dem gemeinsamen Cluster-Pool auf der Grundlage der Prioritätsregeln der Aufgaben-Governance und der Verfügbarkeit von Ressourcen bezogen.
Beispiel: Insgesamt 72 GPU-Stunden (48 zugewiesene, 24 geliehene).
**Anmerkung**
Für NameBereiche, die nicht von Task Governance verwaltet werden, wird nur die Gesamtauslastung angezeigt.
## Detaillierte Berichte
Detaillierte Berichte bieten forensische Einblicke in die Computernutzung, indem sie den Ressourcenverbrauch nach Aufgaben aufschlüsseln und detaillierte Metriken wie Zeitfenster für die Ausführung von Aufgaben, Status (z. B. erfolgreich, Fehlgeschlagen) und Nutzung nach Prioritätsklassen bereitstellen. Diese Berichte eignen sich ideal zur Überprüfung von Abrechnungsabweichungen oder zur Sicherstellung der Einhaltung von Governance-Richtlinien.
Im Folgenden finden Sie eine strukturierte Aufschlüsselung der wichtigsten Spalten in einem ausführlichen Bericht:
+ **Datum:** das Datum der gemeldeten Nutzung (z. B. `2025-04-18`).
+ **Start/Ende des Zeitraums:** Exaktes Ausführungsfenster (UTC) für die Aufgabe. (z. B. `19:54:34`)
+ **Namespace:** der dem Team zugeordnete Kubernetes-Namespace (z. B. `hyperpod-ns-ml-team`).
+ **Team:** Der Eigentümer team/department (z. B.`ml-team`).
+ **Aufgabe:** Die Kennung für den Job/Pod (z. B.). `pytorchjob-ml-pytorch-job-2p5zt-db686`
+ **Instance:** die verwendete Rechen-Instance (z. B. `ml.g5.4xlarge`).
+ **Status:** Ergebnis der Aufgabe (erfolgreich, Fehlgeschlagen, Präemptiv).
+ **Gesamtauslastung:** Gesamtverbrauch (Stunden und Anzahl der Instances) von GPU-, CPU- oder Neuron Core-Ressourcen.
+ **Prioritätsklasse:** die zugewiesene Prioritätsstufe (z. B. Trainingspriorität).
# Berichte erstellen
Dieses Handbuch enthält step-by-step Anweisungen zur Konfiguration und Verwaltung der Nutzungsberichte für Ihre SageMaker HyperPod Cluster. Folgen Sie diesen Verfahren, um die Infrastruktur bereitzustellen, benutzerdefinierte Berichte zu erstellen und Ressourcen zu entfernen, wenn sie nicht mehr benötigt werden.
## Einrichten von Nutzungsberichten
**Anmerkung**
Stellen Sie vor der Konfiguration der Infrastruktur für SageMaker HyperPod Nutzungsberichte in Ihrem SageMaker HyperPod Cluster sicher, dass Sie alle in diesem Dokument aufgeführten Voraussetzungen erfüllt haben [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).
Für die Nutzungsberichterstattung in HyperPod ist Folgendes erforderlich:
+ Bereitstellung von AWS Ressourcen für SageMaker HyperPod Nutzungsberichte mithilfe eines CloudFormation Stacks
+ Installation des Kubernetes-Operators für den SageMaker HyperPod Nutzungsbericht über ein Helm-Diagramm
Umfassende Installationsanweisungen finden Sie im [SageMaker HyperPod Usage Report GitHub Repository](https://github.com/awslabs/sagemaker-hyperpod-usage-report/blob/main/README.md). Folgen Sie insbesondere den Schritten im Abschnitt „[Einrichten“](https://github.com/awslabs/sagemaker-hyperpod-usage-report/blob/main/README.md#set-up-usage-reporting).
## Generieren Sie bei Bedarf Nutzungsberichte
Sobald die Infrastruktur für die Nutzungsberichterstattung und der Kubernetes-Operator installiert sind, werden Auftragsdaten für Ihren SageMaker HyperPod Cluster automatisch erfasst und in dem S3-Bucket gespeichert, den Sie bei der Einrichtung konfiguriert haben. Der Operator erfasst kontinuierlich detaillierte Nutzungsmetriken im Hintergrund und erstellt Rohdatendateien im `raw` Verzeichnis Ihres angegebenen S3-Buckets.
Um einen Nutzungsbericht auf Abruf zu erstellen, können Sie das im [ GitHub Nutzungsbericht-Repository bereitgestellte `run.py` Skript verwenden, um SageMaker HyperPod Nutzungsmetriken](https://github.com/awslabs/sagemaker-hyperpod-usage-report/blob/main/README.md) zu extrahieren und zu exportieren. Insbesondere finden Sie das Skript und eine umfassende Anleitung zum Generieren eines Berichts im Abschnitt Berichte [erstellen](https://github.com/awslabs/sagemaker-hyperpod-usage-report/blob/main/README.md#generate-reports).
Das Skript ermöglicht Ihnen:
+ Geben Sie benutzerdefinierte Datumsbereiche für die Berichtsgenerierung an
+ Wählen Sie zwischen detaillierten und zusammenfassenden Berichtstypen
+ Exportieren Sie Berichte im CSV- oder PDF-Format
+ Direkte Berichte an einen bestimmten S3-Standort
## Bereinigen Sie die Ressourcen für die Nutzungsberichterstattung
Wenn Sie Ihre Infrastruktur für die SageMaker HyperPod Nutzungsberichterstattung nicht mehr benötigen, folgen Sie den Schritten unter [Ressourcen bereinigen](https://github.com/awslabs/sagemaker-hyperpod-usage-report/blob/main/README.md#clean-up-resources), um den Kubernetes-Operator und die AWS Ressourcen (in dieser Reihenfolge) zu bereinigen. Durch das ordnungsgemäße Löschen von Ressourcen können unnötige Kosten vermieden werden.
# Konfiguration von Speicher für von Amazon EKS orchestrierte SageMaker HyperPod Cluster
Der Cluster-Administrator muss Speicher für Data Scientist-Benutzer konfigurieren, um Eingabe- und Ausgabedaten zu verwalten und Checkpoints während des Trainings auf Clustern zu speichern. SageMaker HyperPod
**Umgang mit großen Datensätzen (Eingabe-/Ausgabedaten)**
+ **Datenzugriff und Datenverwaltung**: Datenwissenschaftler arbeiten häufig mit großen Datensätzen, die für das Training von Modellen für maschinelles Lernen erforderlich sind. Durch die Angabe von Speicherparametern bei der Auftragsübermittlung können sie festlegen, wo sich diese Datensätze befinden (z. B. Amazon-S3-Buckets, persistente Volumes in Kubernetes) und wie während der Auftragsausführung darauf zugegriffen wird.
+ **Leistungsoptimierung**: Die Effizienz des Zugriffs auf Eingabedaten kann sich erheblich auf die Leistung der Trainingsaufgabe auswirken. Durch die Optimierung der Speicherparameter können Datenwissenschaftler sicherstellen, dass Daten effizient gelesen und geschrieben werden, wodurch I/O Engpässe reduziert werden.
**Speichern von Checkpoints**
+ **Checkpointing im Training**: Bei Trainingsjobs mit langer Laufzeit ist es üblich, Checkpoints zu speichern, d. h. Zwischenzustände des Modells. Auf diese Weise können Datenwissenschaftler das Training im Falle eines Fehlers an einem bestimmten Punkt fortsetzen, anstatt bei Null anzufangen.
+ **Datenwiederherstellung und Experimente**: Durch die Angabe des Speicherorts für Checkpoints können Datenwissenschaftler sicherstellen, dass diese Checkpoints sicher gespeichert sind, möglicherweise in einem verteilten Speichersystem, das Redundanz und hohe Verfügbarkeit bietet. Dies ist entscheidend, um sich nach Unterbrechungen zu erholen und mit verschiedenen Trainingsstrategien zu experimentieren.
**Tipp**
Praktische Erfahrungen und Anleitungen zur Einrichtung von Speicher für mit Amazon EKS orchestrierte SageMaker HyperPod Cluster finden Sie in den folgenden Abschnitten des [Amazon EKS Support im SageMaker HyperPod Workshop](https://catalog.us-east-1.prod.workshops.aws/workshops/2433d39e-ccfe-4c00-9d3d-9917b729258e).
[Richten Sie Amazon FSx for Lustre ein auf SageMaker HyperPod](https://catalog.us-east-1.prod.workshops.aws/workshops/2433d39e-ccfe-4c00-9d3d-9917b729258e/en-US/01-cluster/06-fsx-for-lustre)
[Richten Sie mit Mountpoint for Amazon S3 einen](https://catalog.us-east-1.prod.workshops.aws/workshops/2433d39e-ccfe-4c00-9d3d-9917b729258e/en-US/01-cluster/09-s3-mountpoint) [Mountpoint](https://docs.aws.amazon.com/AmazonS3/latest/userguide/mountpoint.html) für Amazon S3 ein
# Verwenden des Amazon EBS CSI-Treibers auf SageMaker HyperPod EKS-Clustern
SageMaker HyperPod unterstützt den Amazon Elastic Block Store (Amazon EBS) Container Storage Interface (CSI) -Treiber, der den Lebenszyklus von Amazon EBS-Volumes als Speicher für die von Ihnen erstellten Kubernetes-Volumes verwaltet. Mit dem Amazon EBS CSI-Treiber können Sie Ihre Amazon EBS-Volumes für Ihre Machine-Learning-Workloads, die auf SageMaker HyperPod Clustern mit Amazon EKS-Orchestrierung ausgeführt werden, erstellen, anhängen und verwalten.
**Topics**
+ [Wichtige Speicherfunktionen](#sagemaker-hyperpod-eks-ebs-features)
+ [Anwendungsfälle](#sagemaker-hyperpod-eks-ebs-use)
+ [Einrichtung des Amazon EBS CSI-Treibers auf SageMaker HyperPod EKS-Clustern](#sagemaker-hyperpod-eks-ebs-setup)
+ [Unter Verwendung der APIs](#sagemaker-hyperpod-eks-ebs-setup-apis)
## Wichtige Speicherfunktionen
Der Amazon EBS CSI-Treiber on SageMaker HyperPod unterstützt die folgenden Speicherfunktionen.
+ Statische Bereitstellung: Ordnet vorab erstellte Amazon EBS-Volumes [persistenten Kubernetes-Volumes](https://kubernetes.io/docs/concepts/storage/persistent-volumes/) zur Verwendung in Ihren Pods zu.
+ Dynamische Bereitstellung: Erstellt automatisch Amazon EBS-Volumes und zugehörige persistente Volumes aus [https://kubernetes.io/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims). Parameter können übergeben werden, [https://kubernetes.io/docs/concepts/storage/storage-classes/](https://kubernetes.io/docs/concepts/storage/storage-classes/)um die Volume-Erstellung detailliert zu steuern.
+ Volumenänderung: Erweitert bestehende Volumes durch Aktualisierung der [https://kubernetes.io/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)Größenspezifikation, ohne laufende Workloads zu unterbrechen. Dies kann für den Umgang mit wachsenden Modell-Repositorys oder die Anpassung an größere Knoten ohne Betriebsunterbrechung unerlässlich sein.
+ Volume-Snapshots: Erstellt point-in-time Snapshots von Volumes für Backup, Wiederherstellung und Datenversionierung.
+ Block-Volumes: Ermöglicht unformatierten Blockgerätezugriff für Hochleistungsanwendungen, die direkten Speicherzugriff benötigen.
+ Volumenänderung: Ändert Volume-Eigenschaften wie Typ, Eingabe- oder Ausgabeoperationen pro Sekunde (IOPS) oder Durchsatz mithilfe von [Volume-Attributklassen](https://kubernetes.io/docs/concepts/storage/volume-attributes-classes/).
Weitere Informationen zum Amazon EBS CSI-Treiber finden Sie unter [Use Kubernetes Volume Storage with Amazon EBS im *Amazon* EKS-Benutzerhandbuch](https://docs.aws.amazon.com/eks/latest/userguide/ebs-csi.html).
*Weitere Informationen zur Speicherung auf Pods in Ihrem Cluster finden Sie in der Kubernetes-Dokumentation unter [Speicher](https://kubernetes.io/docs/concepts/storage/).*
## Anwendungsfälle
Die Amazon EBS CSI-Treiberintegration ermöglicht mehrere wichtige Anwendungsfälle sowohl für Schulungs- als auch für Inferenz-Workloads auf SageMaker HyperPod EKS-Clustern.
**Workloads für Schulungen**
+ Speicherung von Datensätzen: Stellen Sie Volumes für Trainingsdatensätze bereit, die auch nach einem Pod-Neustart bestehen bleiben
+ Checkpoint-Speicher: Speichern Sie Modell-Checkpoints und Zwischentrainingsergebnisse
+ Gemeinsam genutzte Artefakte: Greifen Sie über mehrere Trainingsjobs hinweg auf gemeinsame Datensätze und Modellartefakte zu
**Inferenz-Workloads**
+ Modellspeicher: Dynamische Bereitstellung angemessen dimensionierter Volumes auf der Grundlage der Modellanforderungen
+ Container-Caching: Erstellen Sie kurzlebigen Speicher für eine verbesserte Inferenzleistung
+ Ereignisprotokollierung: Speichern Sie Inferenzergebnisse und Protokolle im persistenten Speicher
## Einrichtung des Amazon EBS CSI-Treibers auf SageMaker HyperPod EKS-Clustern
Der Container Storage Interface (CSI) -Treiber für Amazon Elastic Block Store (Amazon EBS) ermöglicht Ihnen die dynamische Bereitstellung und Verwaltung von Amazon EBS-Volumes für Ihre containerisierten Workloads, die auf SageMaker HyperPod Clustern mit EKS-Orchestrierung ausgeführt werden. Dieser Abschnitt führt Sie durch die Installation und Konfiguration des Amazon EBS-CSI-Treibers zum Aktivieren des persistenten Speichers für Ihre Workloads im Machine Learning.
### Voraussetzungen
Bevor Sie beginnen, führen Sie die folgenden Schritte aus:
+ [Installieren und konfigurieren Sie den AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html)
+ [Erstellen Sie einen SageMaker HyperPod Cluster mit Amazon EKS-Orchestrierung](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-eks-operate-console-ui-create-cluster.html)
+ [Installieren Sie den Amazon-EBS-CSI-Treiber mit der Version von v1.47.0](https://github.com/kubernetes-sigs/aws-ebs-csi-driver/blob/master/CHANGELOG.md#v1470)
### Zusätzliche Berechtigungen
Um das Amazon EBS CSI-Treiber-Add-on einzurichten, folgen Sie den Anweisungen unter [Use Kubernetes Volume Storage with Amazon EBS im *Amazon* EKS-Benutzerhandbuch](https://docs.aws.amazon.com/eks/latest/userguide/ebs-csi.html). Sie sollten der IAM-Rolle, die zur Ausführung des Treiber-Add-ons verwendet wird, auch die folgenden zusätzlichen Berechtigungen hinzufügen. Beachten Sie, dass dies die IAM-Rolle ist, die in Ihrer Dienstkontokonfiguration für das Treiber-Add-on angegeben ist, nicht die HyperPod Cluster-Ausführungsrolle.
------
#### [ 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"
}
]
}
```
------
## Unter Verwendung der APIs
Als Alternative können Sie die Operationen [AttachClusterNodeVolume](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_AttachClusterNodeVolume.html)und [DetachClusterNodeVolume](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_DetachClusterNodeVolume.html)API verwenden, um Ihre Amazon EBS-Volumes an SageMaker HyperPod EKS-Cluster-Instances anzuhängen und zu trennen.
**Zu den wichtigsten Anforderungen für deren Verwendung APIs gehören die folgenden.**
+ Sowohl das Amazon EBS-Volume als auch der SageMaker HyperPod EKS-Cluster müssen demselben AWS-Konto gehören.
+ Der aufrufende Principal benötigt bestimmte Mindestberechtigungen, um den Vorgang zum anfügen oder Trennen erfolgreich ausführen zu können. Weitere Informationen zu den Mindestberechtigungen finden Sie in den folgenden Abschnitten.
+ Nachdem Sie Ihrem HyperPod Knoten ein Volume hinzugefügt haben, folgen Sie den Anweisungen [unter [Zugreifen auf SageMaker HyperPod Cluster-Knoten, um auf den Cluster-Knoten](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-eks-operate-access-through-terminal.html) zuzugreifen, und Bereitstellen eines Volumes, das zum Mounten des angehängten Volumes verwendet](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-using-volumes.html) werden kann.
### Erforderliche Berechtigungen für `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/*"
}
]
}
```
------
### Erforderliche Berechtigungen für `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/*"
}
]
}
```
------
### Erforderliche Berechtigungen für Schlüssel AWS KMS
Fügen Sie die folgenden AWS KMS Berechtigungen nur hinzu, wenn Sie vom Kunden verwaltete KMS-Schlüssel verwenden, um Ihre Amazon EBS-Volumes zu verschlüsseln, die an HyperPod Clusterknoten angeschlossen sind. Diese Berechtigungen sind nicht erforderlich, wenn Sie AWS-verwaltete KMS-Schlüssel (die Standardverschlüsselungsoption) verwenden.
------
#### [ 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"
]
}
}
}
]
}
```
------
**Anmerkung**
Diese AWS KMS Berechtigungen sind nicht erforderlich, `sagemaker:DetachClusterNodeVolume` wenn ein CAVA-Volume (Cluster Auto Volume Attachment) -Volume getrennt wird, das mit vom Kunden verwalteten KMS-Schlüsseln verschlüsselt wurde.
# Konfiguration benutzerdefinierter Kubernetes-Labels und -Taints in Amazon SageMaker HyperPod
SageMaker HyperPod Amazon-Cluster mit dem Orchestrator Amazon Elastic Kubernetes Service (Amazon EKS) unterstützen benutzerdefinierte Kubernetes-Labels und -Taints für Knoten innerhalb von Instanzgruppen. Labels and Taints sind grundlegende Planungs- und Organisationsmechanismen in Kubernetes, mit denen Sie die Pod-Platzierung und die Ressourcennutzung genau steuern können.
Labels sind Schlüssel-Wert-Paare, die an Kubernetes-Objekte angehängt werden können, sodass Sie Ressourcen anhand von Attributen organisieren und auswählen können. Bei Taints handelt es sich in Verbindung mit Toleranzen um knotenspezifische Eigenschaften, die das Pod-Scheduling beeinflussen, indem sie Pods abwehren, für die es keine passenden Toleranzen gibt. Zusammen ermöglichen Ihnen diese Mechanismen, Workloads zu isolieren, sie gemäß den Hardwarespezifikationen zuzuweisen und eine optimale Ressourcennutzung sicherzustellen.
## Häufige Anwendungsfälle
Im Folgenden finden Sie häufig vorkommende Szenarien, in denen benutzerdefinierte Labels und Taints von Vorteil sind:
+ **Vermeidung von System-Pods auf teuren Instanzen** — Wenden Sie Taints auf GPU-Instances an, um zu verhindern, dass System-Pods und andere unkritische Workloads teure Rechenressourcen verbrauchen
+ **Integration mit vorhandenen Tools** — Wenden Sie Labels an, die den etablierten Infrastrukturmustern und Knotenaffinitätskonfigurationen Ihres Unternehmens entsprechen
## Konfiguration von Labels und Taints
Sie können benutzerdefinierte Kubernetes-Labels und -Taints auf Instanzgruppenebene konfigurieren, indem Sie den `KubernetesConfig` Parameter in Ihrer Cluster-Konfiguration verwenden. Labels und Taints werden auf alle Knoten in der Instanzgruppe angewendet und bleiben während des gesamten Lebenszyklus des Clusters bestehen.
Der `KubernetesConfig` Parameter ist deklarativ, d. h. Sie geben den vollständigen gewünschten Status von Labels und Taints für eine Instanzgruppe an. SageMaker HyperPod gleicht dann den tatsächlichen Zustand der Knoten so ab, dass er diesem gewünschten Zustand entspricht.
+ **Hinzufügen von Labels oder Taints** — Fügen Sie die neuen Labels oder Taints `KubernetesConfig` zusammen mit allen vorhandenen hinzu, die Sie behalten möchten
+ **Beschriftungen oder Verschmutzungen aktualisieren** — Ändern Sie die Werte `KubernetesConfig` für die Beschriftungen oder Verfärbungen, die Sie ändern möchten, und schließen Sie alle anderen ein, die Sie behalten möchten
+ **Beschriftungen oder Verschmutzungen entfernen** — Lassen Sie die Beschriftungen oder Verfälschungen aus, die Sie entfernen möchten, und behalten Sie nur diejenigen bei`KubernetesConfig`, die Sie beibehalten möchten
### Erstellen eines Clusters mit Labels und Makeln
Wenn Sie einen neuen SageMaker HyperPod Cluster erstellen, nehmen Sie den `KubernetesConfig` Parameter in Ihre Instanzgruppenkonfiguration auf. Das folgende Beispiel zeigt, wie Sie einen Cluster mit benutzerdefinierten Labels und Taints erstellen:
```
{
"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 diesem Beispiel:
+ **Labels** — Drei benutzerdefinierte Labels werden angewendet:`env=prod`,`team=ml-training`, und `gpu-type=a100`
+ **Taints** — Zwei Taints wurden konfiguriert, um ungewolltes Pod-Scheduling zu verhindern
### Labels und Taints auf einem vorhandenen Cluster werden aktualisiert
Sie können Labels und Taints auf einem vorhandenen Cluster mithilfe der `UpdateCluster` API ändern. Das folgende Beispiel zeigt, wie Sie die `KubernetesConfig` für eine Instanzgruppe aktualisieren:
```
{
"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"
}]
}
}]
}
```
Wenn Sie Labels und Taints aktualisieren, werden die Änderungen auf alle Knoten in der Instanzgruppe SageMaker HyperPod angewendet. Der Service verwaltet den Übergang vom aktuellen zum gewünschten Status, den Sie mithilfe der `DescribeCluster` API überwachen können.
## Überwachung, Etikett und Anwendung
SageMaker HyperPod ermöglicht APIs die Überwachung des Status von Labels und Taints, wenn sie auf Ihre Clusterknoten angewendet werden.
### Überprüfen Sie den Status auf Clusterebene
Verwenden Sie die `DescribeCluster` API, um den aktuellen und gewünschten Status von Labels und Taints auf Instanzgruppenebene anzuzeigen. Das folgende Beispiel zeigt die Antwortstruktur:
```
{
"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"
}]
}
}]
}
```
Bei `CurrentLabels` Übereinstimmung `DesiredLabels` und `CurrentTaints` Übereinstimmung `DesiredTaints` wird auf alle Knoten in der Instanzgruppe die angegebene Konfiguration angewendet. Wenn sie sich unterscheiden, ist der Cluster noch dabei, die Änderungen anzuwenden.
### Der Status einzelner Knoten wird überprüft
Für Details auf Knotenebene verwenden Sie die `DescribeClusterNode` API, um die Bezeichnung und die fehlerhafte Konfiguration einzelner Knoten zu überprüfen. Das folgende Beispiel zeigt die Antwortstruktur:
```
{
"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"
}]
}
}
}
```
Die Überwachung auf Knotenebene ist nützlich für die Fehlerbehebung, wenn Labels oder Taints nicht korrekt auf bestimmte Knoten angewendet werden oder wenn Sie die Konfiguration einer bestimmten Instanz überprüfen müssen.
## Reservierte Präfixe
Bestimmte Präfixe sind für die Verwendung durch das System reserviert und sollten nicht für benutzerdefinierte Beschriftungen oder Markierungen verwendet werden. Die folgenden Präfixe sind reserviert:
+ `kubernetes.io/`- Reserviert für Kubernetes-Kernkomponenten
+ `k8s.io/`— Reserviert für Kubernetes-Kernkomponenten
+ `sagemaker.amazonaws.com/`- Reserviert für SageMaker HyperPod
+ `eks.amazonaws.com/`- Reserviert für Amazon EKS
+ `k8s.aws/`- Reserviert für Amazon EKS
+ `karpenter.sh/`— Reserviert für Karpenter Autoscaling
Labels und Taints mit diesen Präfixen werden von Systemkomponenten verwaltet und sollten nicht mit benutzerdefinierten Werten überschrieben werden.
# Checkpointless-Schulungen bei Amazon SageMaker HyperPod
Checkpointless-Training bei Amazon SageMaker HyperPod ermöglicht eine schnellere Wiederherstellung nach Fehlern in der Trainingsinfrastruktur. Die folgende Dokumentation hilft Ihnen bei den ersten Schritten mit Checkpointless-Schulungen und der Feinabstimmung für unterstützte Modelle. NeMo
Für das Checkpointless-Training gelten die folgenden Voraussetzungen:
+ [Erste Schritte mit der Amazon EKS-Unterstützung in SageMaker HyperPod](sagemaker-hyperpod-eks-prerequisites.md)
+ [Den Trainingsoperator installieren](sagemaker-eks-operator-install.md). Sie müssen v1.2.0 oder höher installieren.
Checkpointless Training on SageMaker HyperPod basiert auf dem [NVIDIA NeMo Framework-Benutzerhandbuch](https://docs.nvidia.com/nemo-framework/user-guide/latest/nemotoolkit/core/exp_manager.html#experiment-manager). Sie können Checkpointless-Training mit vorgefertigten Rezepten durchführen. SageMaker HyperPod Wenn Sie damit vertraut sind NeMo, ist der Prozess der Verwendung der Trainingsrezepte für Checkpointless-Trainings ähnlich. Mit geringfügigen Änderungen können Sie beginnen, ein Modell mithilfe von Trainingsfunktionen ohne Kontrollpunkte zu trainieren, mit denen Sie sich schnell von Trainingsfehlern erholen können.
Die folgenden HyperPod Rezepte sind mit Trainingsoptimierungen ohne Checkpoints vorkonfiguriert. Sie können Ihre Datenpfade als Teil des Rezepts angeben und das zugehörige Startskript verwenden, um das Training auszuführen (siehe Kurzanleitung unten):
| Modell | Methode | Größe | Knoten | Instance | Accelerator | Rezept | Script | Tutorial |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| ICH HABE UNS | Vollständiges Finetune-Beispiel | 120b | 16 | p5.48xlarge | GPU H100 | [verlinken](https://github.com/aws/sagemaker-hyperpod-recipes/tree/main/recipes_collection/recipes/fine-tuning/gpt_oss/checkpointless_gpt_oss_120b_full_fine_tuning.yaml) | [verlinken](https://github.com/aws/sagemaker-hyperpod-recipes/tree/main/launcher_scripts/gpt_oss/run_checkpointless_gpt_oss_120b_full_fine_tuning.sh) | [verlinken](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-eks-checkpointless-recipes-finetune.html) |
| ICH HABE UNS | Lora-Beispiel | 120b | 2 | p5.48xlarge | GPU H100 | [verlinken](https://github.com/aws/sagemaker-hyperpod-recipes/tree/main/recipes_collection/recipes/fine-tuning/gpt_oss/checkpointless_gpt_oss_120b_lora.yaml) | [verlinken](https://github.com/aws/sagemaker-hyperpod-recipes/tree/main/launcher_scripts/gpt_oss/run_checkpointless_gpt_oss_120b_lora.sh) | [verlinken](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-eks-checkpointless-recipes-peft.html) |
| Lama 3 | Beispiel für Pretrain | 70b | 16 | p5.48xlarge | GPU H100 | [verlinken](https://github.com/aws/sagemaker-hyperpod-recipes/tree/main/recipes_collection/recipes/training/llama/checkpointless_llama3_70b_pretrain.yaml) | [verlinken](https://github.com/aws/sagemaker-hyperpod-recipes/tree/main/launcher_scripts/llama/run_checkpointless_llama3_70b_pretrain.sh) | [verlinken](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-eks-checkpointless-recipes-pretraining-llama3.html) |
| Lama 3 | LoRa-Beispiel | 70b | 2 | p5.48xlarge | GPU H100 | [verlinken](https://github.com/aws/sagemaker-hyperpod-recipes/tree/main/recipes_collection/recipes/fine-tuning/llama/checkpointless_llama3_70b_lora.yaml) | [verlinken](https://github.com/aws/sagemaker-hyperpod-recipes/tree/main/launcher_scripts/llama/run_checkpointless_llama3_70b_lora.sh) | [verlinken](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-eks-checkpointless-recipes-peft-llama.html) |
Die folgende Schnellstartanleitung enthält Tutorials zur Verwendung von Trainingsrezepten ohne Checkpoint:
**Beispiele für den Einstieg**
+ [Tutorials — Vollständige Feinabstimmung von Amazon SageMaker HyperPod Checkpointless GPT OSS 120b](sagemaker-eks-checkpointless-recipes-finetune.md)
+ [Anleitungen — Amazon SageMaker HyperPod Checkpointless LEFT-LoRa GPT OSS 120b](sagemaker-eks-checkpointless-recipes-peft.md)
+ [Anleitungen — Amazon SageMaker HyperPod Checkpointless Pretraining Llama 3 70b](sagemaker-eks-checkpointless-recipes-pretraining-llama3.md)
+ [Anleitungen — Amazon SageMaker HyperPod Checkpointless Left-LoRa Lama 3 70b](sagemaker-eks-checkpointless-recipes-peft-llama.md)
Wenn Sie benutzerdefinierte Modelle vorab trainieren oder optimieren möchten, finden Sie weitere Informationen unter. [Tutorials — Amazon SageMaker HyperPod Checkpointless — Vortraining oder Feinabstimmung benutzerdefinierter Modelle](sagemaker-eks-checkpointless-recipes-custom.md)
Weitere Informationen zur Integration bestimmter Trainingskomponenten ohne Checkpointless finden Sie unter. [HyperPod Checkpointless-Trainingsfunktionen](sagemaker-eks-checkpointless-features.md)
# Schulungs-Tutorials zu Amazon SageMaker HyperPod Checkpointless
[ HyperPod Trainingsrezepte für Checkpointless](https://github.com/aws/sagemaker-hyperpod-checkpointless-training) sind vordefinierte Jobkonfigurationen mit aktivierten Checkpointless-Trainingsfunktionen. Die Verwendung dieser Rezepte erleichtert den Einstieg in das Training ohne Checkpoint. HyperPod
**Topics**
+ [Tutorials — Vollständige Feinabstimmung von Amazon SageMaker HyperPod Checkpointless GPT OSS 120b](sagemaker-eks-checkpointless-recipes-finetune.md)
+ [Anleitungen — Amazon SageMaker HyperPod Checkpointless LEFT-LoRa GPT OSS 120b](sagemaker-eks-checkpointless-recipes-peft.md)
+ [Anleitungen — Amazon SageMaker HyperPod Checkpointless Pretraining Llama 3 70b](sagemaker-eks-checkpointless-recipes-pretraining-llama3.md)
+ [Anleitungen — Amazon SageMaker HyperPod Checkpointless Left-LoRa Lama 3 70b](sagemaker-eks-checkpointless-recipes-peft-llama.md)
+ [Tutorials — Amazon SageMaker HyperPod Checkpointless — Vortraining oder Feinabstimmung benutzerdefinierter Modelle](sagemaker-eks-checkpointless-recipes-custom.md)
# Tutorials — Vollständige Feinabstimmung von Amazon SageMaker HyperPod Checkpointless GPT OSS 120b
Die folgende Abfolge von Schritten ist erforderlich, um Trainingsrezepte ohne Checkpoint ausführen zu können. HyperPod
## Voraussetzungen
Bevor Sie mit der Einrichtung Ihrer Umgebung beginnen, stellen Sie sicher, dass Sie über Folgendes verfügen:
+ [Amazon EKS-Unterstützung in Amazon aktiviert SageMaker HyperPod](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-eks-prerequisites.html)
+ [Richten Sie den HyperPod Trainingsoperator ein (v1.2\$1)](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-eks-operator.html)
+ Ein gemeinsam genutzter Speicherort. Es kann sich um ein FSx Amazon-Dateisystem oder ein NFS-System handeln, auf das von den Clusterknoten aus zugegriffen werden kann.
+ Daten in einem der folgenden Formate:
+ JSON
+ JSONGZ (komprimiertes JSON)
+ ARROW
+ [Wählen Sie ein unterstütztes Checkpointless-Trainingsrezept für Llama 70B oder GPT-OSS 120B aus der Quelle aus.](https://github.com/aws/sagemaker-hyperpod-recipes/tree/main/recipes_collection)
+ [Laden Sie die Gewichte des Modells Hugging Face](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-eks-checkpointless-release-notes.html) [herunter und konvertieren Sie es in das von Nemo unterstützte Format.](https://docs.nvidia.com/nemo-framework/user-guide/latest/nemo-2.0/features/hf-integration.html#importing-from-hugging-face)
+ Einrichtung Ihrer Umgebung
## Einrichtung der Kubernetes-Umgebung
Gehen Sie wie folgt vor, um Ihre Kubernetes-Umgebung einzurichten:
1. Richten Sie die virtuelle Umgebung ein. Stellen Sie sicher, dass Ihre Version von Python größer oder gleich 3.10 und niedriger als 3.14 ist.
```
python3 -m venv ${PWD}/venv
source venv/bin/activate
```
1. [Richten Sie kubectl und eksctl ein](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html)
1. [Installieren Sie Helm](https://helm.sh/docs/intro/install/)
1. Verbinden mit Ihrem Kubernetes-Cluster
```
aws eks update-kubeconfig --region "${CLUSTER_REGION}" --name "${CLUSTER_NAME}"
```
1. Installieren Sie Abhängigkeiten mit einer der folgenden Methoden:
1. Methode 1: SageMaker HyperPod Rezeptmethode:
```
# 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. Methode 2: kubectl mit vordefinierter Job-Yaml-Methode
```
# install SageMaker HyperPod checkpointless training.
git clone git@github.com:aws/sagemaker-hyperpod-checkpointless-training.git
cd sagemaker-hyperpod-checkpointless-training
```
Sie können das Checkpointless-Trainingsrezept jetzt entweder mit dem Launcher im -style oder mit kubectl starten. NeMo
## Starten Sie Trainingsjobs mit dem Recipes-Launcher
Sie können die SageMaker HyperPod Amazon-Rezepte verwenden, um Ihren Ausbildungsjob einzureichen. Die Verwendung der Rezepte beinhaltet die Aktualisierung von k8s.yaml, config.yaml und die Ausführung des Startskripts.
1. Aktualisieren: `launcher_scripts/gpt_oss/run_checkpointless_gpt_oss_120b_full_fine_tuning.sh`
your\$1container: Ein Deep-Learning-Container. Die neueste Version des Checkpointless Training Containers finden Sie in den Versionshinweisen zu [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. Starten eines Trainingsjobs
```
bash launcher_scripts/gpt_oss/run_checkpointless_gpt_oss_120b_full_fine_tuning.sh
```
Nachdem Sie den Trainingsjob eingereicht haben, können Sie mit dem folgenden Befehl überprüfen, ob die Übermittlung erfolgreich war.
```
kubectl get pods
NAME READY STATUS RESTARTS AGE
gpt-oss-120b-worker-0 0/1 running 0 36s
```
Wenn der STATUS auf PENDING oder steht ContainerCreating, führen Sie den folgenden Befehl aus, um weitere Informationen zu erhalten
```
kubectl describe pod
```
Nachdem der Job-STATUS zu „Laufend“ geändert wurde, können Sie das Protokoll mit dem folgenden Befehl überprüfen.
```
kubectl logs
```
Der `STATUS` wechselt zu `COMPLETED`, wenn Sie `kubectl get pods` ausführen.
## Starten Sie den Trainingsjob mit kubectl mit vordefiniertem Yaml
Eine weitere Option besteht darin, das Training über kubectl mit einem vordefinierten Job-Yaml zu starten.
1. aktualisiere die examples/gpt\$1oss/launch/full Datei \$1finetune\$1gpt\$1oss\$1120b\$1checkpointless\$1p5.yaml
+ Bild: Ein Deep-Learning-Container. Die neueste Version des Checkpointless-Trainingscontainers finden Sie in den Versionshinweisen zu [Checkpointless](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-eks-checkpointless-release-notes.html) Training.
+ [resume.restore\$1config.path=: Der Pfad zu den heruntergeladenen vortrainierten Modellgewichten im Nemo-Format im Schritt Voraussetzungen.](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-eks-checkpointless-recipes-finetune.html#sagemaker-eks-checkpointless-recipes-finetune-prereqs)
+ dataset.dataset\$1path=: Der Pfad zu dem Datensatz, der im gemeinsam genutzten Speicher gespeichert wurde
1. Reichen Sie den Job mithilfe von kubectl mit full\$1finetune\$1gpt\$1oss\$1120b\$1checkpointless\$1p5.yaml ein
```
kubectl apply -f examples/gpt_oss/launch/full_finetune_gpt_oss_120b_checkpointless_p5.yaml
```
Nachdem Sie den Trainingsjob eingereicht haben, können Sie mit dem folgenden Befehl überprüfen, ob die Übermittlung erfolgreich war.
```
kubectl get pods
NAME READY STATUS RESTARTS AGE
gpt-oss-120b-worker-0 0/1 running 0 36s
```
Wenn der STATUS auf PENDING oder steht, führen Sie den folgenden Befehl aus, um weitere Informationen zu erhalten ContainerCreating
```
kubectl describe pod
```
Nachdem der Job-STATUS zu „Laufend“ geändert wurde, können Sie das Protokoll mit dem folgenden Befehl überprüfen.
```
kubectl logs
```
Der STATUS wechselt zu Abgeschlossen, wenn Sie kubectl get pods ausführen
# Anleitungen — Amazon SageMaker HyperPod Checkpointless LEFT-LoRa GPT OSS 120b
Die folgende Abfolge von Schritten ist erforderlich, um Trainingsrezepte ohne Checkpoint ausführen zu können. HyperPod
## Voraussetzungen
Bevor Sie mit der Einrichtung Ihrer Umgebung beginnen, stellen Sie sicher, dass Sie über Folgendes verfügen:
+ [Amazon EKS-Unterstützung in Amazon aktiviert SageMaker HyperPod](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-eks-prerequisites.html)
+ [Richten Sie den HyperPod Trainingsoperator ein (v1.2\$1)](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-eks-operator.html)
+ Ein gemeinsam genutzter Speicherort. Es kann sich um ein FSx Amazon-Dateisystem oder ein NFS-System handeln, auf das von den Clusterknoten aus zugegriffen werden kann.
+ Daten in einem der folgenden Formate:
+ JSON
+ JSONGZ (komprimiertes JSON)
+ ARROW
+ [Wählen Sie ein unterstütztes Checkpointless-Trainingsrezept für Llama 70B oder GPT-OSS 120B aus der Quelle aus.](https://github.com/aws/sagemaker-hyperpod-recipes/tree/main/recipes_collection)
+ [Laden Sie die Gewichte des Modells Hugging Face](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-eks-checkpointless-release-notes.html) [herunter und konvertieren Sie es in das von Nemo unterstützte Format.](https://docs.nvidia.com/nemo-framework/user-guide/latest/nemo-2.0/features/hf-integration.html#importing-from-hugging-face)
+ Einrichtung Ihrer Umgebung
## Einrichtung der Kubernetes-Umgebung
Gehen Sie wie folgt vor, um Ihre Kubernetes-Umgebung einzurichten:
1. Richten Sie die virtuelle Umgebung ein. Stellen Sie sicher, dass Sie Python verwenden, das größer oder gleich 3.10 und < 3.14 ist.
```
python3 -m venv ${PWD}/venv
source venv/bin/activate
```
1. [Richten Sie kubectl und eksctl ein](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html)
1. [Installieren Sie Helm](https://helm.sh/docs/intro/install/)
1. Verbinden mit Ihrem Kubernetes-Cluster
```
aws eks update-kubeconfig --region "${CLUSTER_REGION}" --name "${CLUSTER_NAME}"
```
1. Installieren Sie Abhängigkeiten mit einer der folgenden Methoden:
+ SageMaker HyperPod Methode der Rezepte:
```
# 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 mit vordefinierter Job-Yaml-Methode
```
# install SageMaker HyperPod checkpointless training.
git clone git@github.com:aws/sagemaker-hyperpod-checkpointless-training.git
cd sagemaker-hyperpod-checkpointless-training
```
Sie können das Checkpointless-Trainingsrezept jetzt entweder mit dem Launcher im -style oder mit kubectl starten. NeMo
## Starten des Trainingsjobs mit dem Launcher für Rezepte
Alternativ kannst du die SageMaker HyperPod Rezepte verwenden, um deinen Ausbildungsjob einzureichen. Zur Verwendung der Rezepte müssen k8s.yaml und config.yaml aktualisiert und das Startskript ausgeführt werden.
1. Aktualisieren: `launcher_scripts/gpt_oss/run_checkpointless_gpt_oss_120b_lora.sh`
your\$1contrainer: Ein Deep-Learning-Container. [Die neueste Version des Checkpointless-Trainingscontainers finden Sie in den Versionshinweisen zu 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. Starten eines Trainingsjobs
```
bash launcher_scripts/gpt_oss/run_checkpointless_gpt_oss_120b_lora.sh
```
Nachdem Sie den Trainingsjob eingereicht haben, können Sie mit dem folgenden Befehl überprüfen, ob die Übermittlung erfolgreich war.
```
kubectl get pods
NAME READY STATUS RESTARTS AGE
gpt-oss-120b-worker-0 0/1 running 0 36s
```
Wenn der STATUS auf PENDING oder steht ContainerCreating, führen Sie den folgenden Befehl aus, um weitere Informationen zu erhalten
```
kubectl describe pod
```
Nachdem der Job-STATUS zu „Laufend“ geändert wurde, können Sie das Protokoll mit dem folgenden Befehl überprüfen.
```
kubectl logs
```
Der STATUS wechselt zu Abgeschlossen, wenn Sie kubectl get pods ausführen
## Starten Sie den Trainingsjob mit kubectl mit vordefiniertem Yaml
Eine weitere Option besteht darin, das Training über kubectl mit einem vordefinierten Job-Yaml zu starten.
1. aktualisiere examples/gpt\$1oss/launch/peft die Datei \$1gpt\$1oss\$1120b\$1checkpointless\$1p5.yaml
+ Bild: Ein Deep-Learning-Container. Die neueste Version des Checkpointless-Trainingscontainers finden Sie in den Versionshinweisen zu [Checkpointless](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-eks-checkpointless-release-notes.html) Training.
+ [resume.restore\$1config.path=: Der Pfad zu den heruntergeladenen vortrainierten Modellgewichten im Nemo-Format im Schritt Voraussetzungen.](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-eks-checkpointless-recipes-peft.html#sagemaker-eks-checkpointless-recipes-peft-prereqs)
+ dataset.dataset\$1path=: Der Pfad zu dem Datensatz, der im gemeinsam genutzten Speicher gespeichert wurde
1. Reichen Sie den Job mithilfe von kubectl mit peft\$1gpt\$1oss\$1120b\$1checkpointless\$1p5.yaml ein
```
kubectl apply -f examples/gpt_oss/launch/peft_gpt_oss_120b_checkpointless_p5.yaml
```
Nachdem Sie den Trainingsjob eingereicht haben, können Sie mit dem folgenden Befehl überprüfen, ob die Übermittlung erfolgreich war.
```
kubectl get pods
NAME READY STATUS RESTARTS AGE
gpt-120b-lora-checkpointless-worker-0 0/1 running 0 36s
```
Wenn der STATUS den Wert PENDING oder hat, führen Sie den folgenden Befehl aus, um weitere Informationen zu erhalten ContainerCreating
```
kubectl describe pod
```
Nachdem der Job-STATUS zu „Laufend“ geändert wurde, können Sie das Protokoll mit dem folgenden Befehl überprüfen.
```
kubectl logs
```
Der STATUS wechselt zu Abgeschlossen, wenn Sie kubectl get pods ausführen
# Anleitungen — Amazon SageMaker HyperPod Checkpointless Pretraining Llama 3 70b
Die folgende Abfolge von Schritten ist erforderlich, um Trainingsrezepte ohne Checkpoint ausführen zu können. HyperPod
## Voraussetzungen
Bevor Sie mit der Einrichtung Ihrer Umgebung beginnen, stellen Sie sicher, dass Sie über Folgendes verfügen:
+ [Amazon EKS-Unterstützung in Amazon aktiviert SageMaker HyperPod](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-eks-prerequisites.html)
+ [Richten Sie den HyperPod Trainingsoperator ein (v1.2\$1)](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-eks-operator.html)
+ Ein gemeinsam genutzter Speicherort. Es kann sich um ein FSx Amazon-Dateisystem oder ein NFS-System handeln, auf das von den Clusterknoten aus zugegriffen werden kann.
+ Daten in einem der folgenden Formate:
+ JSON
+ JSONGZ (komprimiertes JSON)
+ ARROW
+ [Wählen Sie ein unterstütztes Checkpointless-Trainingsrezept für Llama 70B oder GPT-OSS 120B aus der Quelle aus.](https://github.com/aws/sagemaker-hyperpod-recipes/tree/main/recipes_collection)
+ [Laden Sie die Gewichte des Modells Hugging Face](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-eks-checkpointless-release-notes.html) [herunter und konvertieren Sie es in das von Nemo unterstützte Format.](https://docs.nvidia.com/nemo-framework/user-guide/latest/nemo-2.0/features/hf-integration.html#importing-from-hugging-face)
+ Einrichtung Ihrer Umgebung
## Einrichtung der Kubernetes-Umgebung
Gehen Sie wie folgt vor, um Ihre Kubernetes-Umgebung einzurichten:
1. Richten Sie die virtuelle Umgebung ein. Stellen Sie sicher, dass Sie Python verwenden, das größer oder gleich 3.10 und kleiner als 3.14 ist.
```
python3 -m venv ${PWD}/venv
source venv/bin/activate
```
1. [Richten Sie kubectl und eksctl ein](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html)
1. [Installieren Sie Helm](https://helm.sh/docs/intro/install/)
1. Verbinden mit Ihrem Kubernetes-Cluster
```
aws eks update-kubeconfig --region "${CLUSTER_REGION}" --name "${CLUSTER_NAME}"
```
1. Installieren Sie Abhängigkeiten mit einer der folgenden Methoden:
1. Methode 1: SageMaker HyperPod Rezeptmethode:
```
# 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. Methode 2: kubectl mit vordefinierter Job-Yaml-Methode
```
# install SageMaker HyperPod checkpointless training.
git clone git@github.com:aws/sagemaker-hyperpod-checkpointless-training.git
cd sagemaker-hyperpod-checkpointless-training
```
Sie können das Checkpointless-Trainingsrezept jetzt entweder mit dem Launcher im -style oder mit kubectl starten. NeMo
## Methode 1: Starte den Trainingsjob mit dem Recept-Launcher
Alternativ kannst du die SageMaker HyperPod Rezepte verwenden, um deinen Ausbildungsjob einzureichen. Zur Verwendung der Rezepte müssen k8s.yaml und config.yaml aktualisiert und das Startskript ausgeführt werden.
1. Aktualisieren: `launcher_scripts/llama/run_checkpointless_llama3_70b_pretrain.sh`
Ein Deep-Learning-Container. Die neueste Version des Checkpointless Training Containers finden Sie in den Versionshinweisen zu [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. Starten eines Trainingsjobs
```
bash launcher_scripts/llama/run_checkpointless_llama3_70b_pretrain.sh
```
1. Nachdem Sie den Trainingsjob eingereicht haben, können Sie mit dem folgenden Befehl überprüfen, ob die Übermittlung erfolgreich war.
```
kubectl get pods
NAME READY STATUS RESTARTS AGE
llama-3-70b-worker-0 0/1 running 0 36s
```
1. Wenn der STATUS auf PENDING oder steht ContainerCreating, führen Sie den folgenden Befehl aus, um weitere Informationen zu erhalten
```
kubectl describe pod
```
1. Nachdem der Job-STATUS zu „Laufend“ geändert wurde, können Sie das Protokoll mit dem folgenden Befehl überprüfen.
```
kubectl logs
```
Der STATUS wechselt zu Abgeschlossen, wenn Sie kubectl get pods ausführen
## Methode 2: Starten Sie den Trainingsjob mit kubectl mit vordefiniertem Yaml
Eine weitere Option besteht darin, das Training über kubectl mit einem vordefinierten Job-Yaml zu starten.
1. Aktualisieren des `examples/llama3/launch/pretrain_llama3_70b_checkpointless_p5.yaml`
+ `image`: Ein Deep-Learning-Container. [Die neueste Version des Checkpointless Training Containers finden Sie in den Versionshinweisen zu Checkpointless Training.](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-eks-checkpointless-release-notes.html)
+ `resume.restore_config.path=`[: Der Pfad zu heruntergeladenen vortrainierten Modellgewichten im Nemo-Format im Schritt Voraussetzungen.](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-eks-checkpointless-recipes-finetune.html#sagemaker-eks-checkpointless-recipes-finetune-prereqs)
+ `dataset.dataset_path=`: Der Pfad zu dem Datensatz, der im gemeinsam genutzten Speicher gespeichert wurde
1. Senden Sie den Job mithilfe von kubectl mit `pretrain_llama3_70b_checkpointless_p5.yaml`
```
kubectl apply -f examples/llama3/launch/pretrain_llama3_70b_checkpointless_p5.yaml
```
1. Nachdem Sie den Trainingsjob eingereicht haben, können Sie mit dem folgenden Befehl überprüfen, ob die Übermittlung erfolgreich war.
```
kubectl get pods
NAME READY STATUS RESTARTS AGE
llama3-pretrain-checkpointless-worker-0 0/1 running 0 36s
```
1. Wenn der STATUS den Wert PENDING oder hat ContainerCreating, führen Sie den folgenden Befehl aus, um weitere Informationen zu erhalten
```
kubectl describe pod
```
1. Nachdem der Job-STATUS zu „Laufend“ geändert wurde, können Sie das Protokoll mit dem folgenden Befehl überprüfen.
```
kubectl logs
```
Der STATUS wechselt zu Abgeschlossen, wenn Sie kubectl get pods ausführen
# Anleitungen — Amazon SageMaker HyperPod Checkpointless Left-LoRa Lama 3 70b
Die folgende Abfolge von Schritten ist erforderlich, um Trainingsrezepte ohne Checkpoint ausführen zu können. HyperPod
## Voraussetzungen
Bevor Sie mit der Einrichtung Ihrer Umgebung beginnen, stellen Sie sicher, dass Sie über Folgendes verfügen:
+ [Amazon EKS-Unterstützung in Amazon aktiviert SageMaker HyperPod](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-eks-prerequisites.html)
+ [Richten Sie den HyperPod Trainingsoperator ein (v1.2\$1)](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-eks-operator.html)
+ Ein gemeinsam genutzter Speicherort. Es kann sich um ein FSx Amazon-Dateisystem oder ein NFS-System handeln, auf das von den Clusterknoten aus zugegriffen werden kann.
+ Daten in einem der folgenden Formate:
+ JSON
+ JSONGZ (komprimiertes JSON)
+ ARROW
+ [Wählen Sie ein unterstütztes Checkpointless-Trainingsrezept für Llama 70B oder GPT-OSS 120B aus der Quelle aus.](https://github.com/aws/sagemaker-hyperpod-recipes/tree/main/recipes_collection)
+ [Laden Sie die Gewichte des Modells Hugging Face](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-eks-checkpointless-release-notes.html) [herunter und konvertieren Sie es in das von Nemo unterstützte Format.](https://docs.nvidia.com/nemo-framework/user-guide/latest/nemo-2.0/features/hf-integration.html#importing-from-hugging-face)
+ Einrichtung Ihrer Umgebung
## Einrichtung der Kubernetes-Umgebung
Gehen Sie wie folgt vor, um Ihre Kubernetes-Umgebung einzurichten:
1. Richten Sie die virtuelle Umgebung ein. Stellen Sie sicher, dass Sie Python verwenden, das größer oder gleich 3.10 und kleiner als 3.14 ist.
```
python3 -m venv ${PWD}/venv
source venv/bin/activate
```
1. [Richten Sie kubectl und eksctl ein](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html)
1. [Installieren Sie Helm](https://helm.sh/docs/intro/install/)
1. Verbinden mit Ihrem Kubernetes-Cluster
```
aws eks update-kubeconfig --region "${CLUSTER_REGION}" --name "${CLUSTER_NAME}"
```
1. Installieren Sie Abhängigkeiten mit einer der folgenden Methoden:
1. Methode 1: SageMaker HyperPod Rezeptmethode:
```
# 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. Methode 2: kubectl mit vordefinierter Job-Yaml-Methode
```
# install SageMaker HyperPod checkpointless training.
git clone git@github.com:aws/sagemaker-hyperpod-checkpointless-training.git
cd sagemaker-hyperpod-checkpointless-training
```
Sie können das Checkpointless-Trainingsrezept jetzt entweder mit dem Launcher im -style oder mit kubectl starten. NeMo
## Methode 1: Starte den Trainingsjob mit dem Recept-Launcher
Alternativ kannst du die SageMaker HyperPod Rezepte verwenden, um deinen Ausbildungsjob einzureichen. Zur Verwendung der Rezepte müssen k8s.yaml und config.yaml aktualisiert und das Startskript ausgeführt werden.
1. Aktualisieren: `launcher_scripts/llama/run_checkpointless_llama3_70b_lora.sh`
Ein Deep-Learning-Container. Die neueste Version des Checkpointless Training Containers finden Sie in den Versionshinweisen zu [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. Starten eines Trainingsjobs
```
bash launcher_scripts/llama/run_checkpointless_llama3_70b_lora.sh
```
1. Nachdem Sie den Trainingsjob eingereicht haben, können Sie mit dem folgenden Befehl überprüfen, ob die Übermittlung erfolgreich war.
```
kubectl get pods
NAME READY STATUS RESTARTS AGE
llama-3-70b-worker-0 0/1 running 0 36s
```
1. Wenn der STATUS auf PENDING oder steht ContainerCreating, führen Sie den folgenden Befehl aus, um weitere Informationen zu erhalten
```
kubectl describe pod
```
1. Nachdem der Job-STATUS zu „Laufend“ geändert wurde, können Sie das Protokoll mit dem folgenden Befehl überprüfen.
```
kubectl logs
```
Der STATUS wechselt zu Abgeschlossen, wenn Sie kubectl get pods ausführen
## Methode 2: Starten Sie den Trainingsjob mit kubectl mit vordefiniertem Yaml
Eine weitere Option besteht darin, das Training über kubectl mit einem vordefinierten Job-Yaml zu starten.
1. Aktualisieren des `examples/llama3/launch/peft_llama3_70b_checkpointless_p5.yaml`
+ `image`: Ein Deep-Learning-Container. [Die neueste Version des Checkpointless Training Containers finden Sie in den Versionshinweisen zu Checkpointless Training.](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-eks-checkpointless-release-notes.html)
+ `resume.restore_config.path=`[: Der Pfad zu heruntergeladenen vortrainierten Modellgewichten im Nemo-Format im Schritt Voraussetzungen.](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-eks-checkpointless-recipes-finetune.html#sagemaker-eks-checkpointless-recipes-finetune-prereqs)
+ `dataset.dataset_path=`: Der Pfad zu dem Datensatz, der im gemeinsam genutzten Speicher gespeichert wurde
1. Senden Sie den Job mithilfe von kubectl mit `peft_llama3_70b_checkpointless_p5.yaml`
```
kubectl apply -f examples/llama3/launch/peft_llama3_70b_checkpointless_p5.yaml
```
1. Nachdem Sie den Trainingsjob eingereicht haben, können Sie mit dem folgenden Befehl überprüfen, ob die Übermittlung erfolgreich war.
```
kubectl get pods
NAME READY STATUS RESTARTS AGE
llama3-70b-lora-checkpointless-worker-0 0/1 running 0 36s
```
1. Wenn der STATUS den Wert PENDING oder hat ContainerCreating, führen Sie den folgenden Befehl aus, um weitere Informationen zu erhalten
```
kubectl describe pod
```
1. Nachdem der Job-STATUS zu „Laufend“ geändert wurde, können Sie das Protokoll mit dem folgenden Befehl überprüfen.
```
kubectl logs
```
Der STATUS wechselt zu Abgeschlossen, wenn Sie kubectl get pods ausführen
# Tutorials — Amazon SageMaker HyperPod Checkpointless — Vortraining oder Feinabstimmung benutzerdefinierter Modelle
Die folgende Abfolge von Schritten ist erforderlich, um ein Training ohne Checkpoint durchzuführen, während Ihr benutzerdefiniertes Modell aktiviert ist. HyperPod
## Voraussetzungen
Bevor Sie mit der Einrichtung Ihrer Umgebung beginnen, stellen Sie sicher, dass Sie über Folgendes verfügen:
+ [Amazon EKS-Unterstützung in Amazon aktiviert SageMaker HyperPod](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-eks-prerequisites.html)
+ [Richten Sie den HyperPod Trainingsoperator ein (v1.2\$1)](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-eks-operator.html)
+ Ein gemeinsam genutzter Speicherort. Es kann sich um ein FSx Amazon-Dateisystem oder ein NFS-System handeln, auf das von den Clusterknoten aus zugegriffen werden kann.
+ Daten in einem der folgenden Formate:
+ JSON
+ JSONGZ (komprimiertes JSON)
+ ARROW
+ [Laden Sie die Gewichte des Modells Hugging Face](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-eks-checkpointless-release-notes.html) [herunter und konvertieren Sie es in das von Nemo unterstützte Format.](https://docs.nvidia.com/nemo-framework/user-guide/latest/nemo-2.0/features/hf-integration.html#importing-from-hugging-face)
+ Einrichtung Ihrer Umgebung
## Einrichtung der Kubernetes-Umgebung
Gehen Sie wie folgt vor, um Ihre Kubernetes-Umgebung einzurichten:
1. Richten Sie die virtuelle Umgebung ein. Stellen Sie sicher, dass Sie Python verwenden, das größer oder gleich 3.10 und kleiner als 3.14 ist.
```
python3 -m venv ${PWD}/venv
source venv/bin/activate
```
1. [Richten Sie kubectl und eksctl ein](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html)
1. Verbinden mit Ihrem Kubernetes-Cluster
```
aws eks update-kubeconfig --region "${CLUSTER_REGION}" --name "${CLUSTER_NAME}"
```
1. Abhängigkeiten installieren
```
# install SageMaker HyperPod checkpointless training.
git clone git@github.com:aws/sagemaker-hyperpod-checkpointless-training.git
cd sagemaker-hyperpod-checkpointless-training
```
## Anweisungen zur Änderung des Trainings ohne Checkpointless
Folgen Sie dem Integrationsleitfaden (hier verwenden wir das Llama 3 70b Pretraining als Beispiel), um das Training ohne Checkpoint für benutzerdefinierte Modelle schrittweise einzuführen. Dieser beinhaltet:
+ Schnelle Erstellung von Kommunikatoren
+ Datenlader mit Speicherabbildung (MMAP)
+ Prozessbegleitende Wiederherstellung und Wiederherstellung ohne Checkpoint
### Komponente 1: Schnelle Erstellung von Kommunikatoren
Dies dient dazu, die Zeit für den Aufbau von Verbindungen zwischen den Arbeitern zu optimieren. Es sind keine Codeänderungen erforderlich und es müssen lediglich Umgebungsvariablen gesetzt werden
```
# 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 \
...
```
Die vollständige Änderung finden Sie in der Konfiguration des [llama3 70 Pretrain](https://github.com/aws/sagemaker-hyperpod-checkpointless-training/blob/main/examples/llama3/launch/pretrain_llama3_70b_checkpointless_p5.yaml) Launch Jobs.
### Komponente 2: Memory-mapped Dataloader (MMAP)
MMAP-Caches zum Speichern vorab abgerufener Datenproben und ermöglichen einen sofortigen Trainingsstart, ohne auf die Datenvorverarbeitung warten zu müssen. Für die Übernahme durch das Umschließen vorhandener Dataloader sind nur minimale Codeänderungen erforderlich.
```
data_module = MMAPDataModule(
data_module=base_data_module,
mmap_config=CacheResumeMMAPConfig(cache_dir=…)
)
```
### Komponenten 3 und 4: Prozessbegleitende Wiederherstellung und Wiederherstellung ohne Checkpoint
Dies ermöglicht die Wiederherstellung nach einem Ausfall, ohne die Trainingsprozesse neu starten oder das Laden von Checkpoints aus durchführen zu müssen. Zusätzliche Codeänderungen erforderlich (Aktualisierung der Strategie- und Trainingskonfiguration, Wrapping vorhandener Hauptdateien)
```
@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,
)
```
Die vollständige Änderung finden Sie im [Pretrain-Eintragsskript llama3 70](https://github.com/aws/sagemaker-hyperpod-checkpointless-training/blob/main/examples/llama3/llama3_70b_pretrain_checkpointless.py) und die entsprechende Änderung der Trainingskonfiguration finden Sie in der [llama3](https://github.com/aws/sagemaker-hyperpod-checkpointless-training/blob/main/examples/llama3/config/llama3_70b_peft_checkpointless.yaml) 70b-Trainingskonfiguration.
### Starten Sie das Training
Sie können das Checkpointless-Training jetzt mit kubectl starten.
```
kubectl apply -f your_job_config.yaml
```
# HyperPod Checkpointless-Trainingsfunktionen
Auf den folgenden Seiten erfahren Sie mehr über die Trainingsfunktionen des Checkpointless-Trainings.
**Topics**
+ [Amazon SageMaker HyperPod Checkpointless-Schulungsrepositorien](#sagemaker-eks-checkpointless-repositories)
+ [Verbesserungen bei der Initialisierung der kollektiven Kommunikation](sagemaker-eks-checkpointless-features-communication.md)
+ [Dataloader mit Speicherzuweisung](sagemaker-eks-checkpointless-features-mmap.md)
+ [Prozessbegleitende Wiederherstellung und Training ohne Kontrollpunkte](sagemaker-eks-checkpointless-in-process-recovery.md)
## Amazon SageMaker HyperPod Checkpointless-Schulungsrepositorien
[ HyperPod Training ohne Checkpoint](https://github.com/aws/sagemaker-hyperpod-checkpointless-training#) beschleunigt die Wiederherstellung nach Clusterfehlern in großen, verteilten Trainingsumgebungen durch Optimierungen auf Framework-Ebene. Diese Optimierungen werden über ein Basis-Container-Image bereitgestellt, das erweiterte Verbesserungen der NCCL-Initialisierung, Optimierungen beim Laden von Daten sowie Komponenten für die Wiederherstellung während des Prozesses und ohne Checkpoint umfasst. Das HyperPod Checkpointless-Schulungspaket basiert auf dieser Grundlage.
Das Checkpointless-Training wird über drei Optimierungstracks ermöglicht, die zusammen laufen:
+ **Verbesserungen der Kommunikationsinitialisierung (NCCL und Gloo)** — Beseitigen Sie Kommunikationsengpässe, indem Sie Rang-Peer- und Ringinformationen dezentralisieren (rotes Feld unten).
+ **Optimierungen beim Laden von Daten** — Reduzieren Sie den Zeitaufwand für die Bereitstellung des ersten Datenstapels bei Neustartvorgängen (orangefarbene Felder unten).
+ **Reduzierung des Programmneustartaufwands** — Minimiert die Neustartkosten und ermöglicht die Wiederherstellung ohne Checkpoint durch Wiederherstellung von Prozessen auf fehlerfreien Knoten (blaue und grüne Felder unten).
![\[alt text not found\]](http://docs.aws.amazon.com/de_de/sagemaker/latest/dg/images/hyperpod/hyperpod-checkpointless-optimization-tracks.png)
# Verbesserungen bei der Initialisierung der kollektiven Kommunikation
NCCL und Gloo sind grundlegende Kommunikationsbibliotheken, die kollektive Operationen (wie All-Reduce und Broadcast) in verteilten Trainingsprozessen ermöglichen. Herkömmliche NCCL- und Gloo-Initialisierungen können jedoch zu Engpässen bei der Fehlerbehebung führen.
Beim standardmäßigen Wiederherstellungsprozess müssen alle Prozesse eine Verbindung zu einem zentralen Prozess herstellen TCPStore und über einen Stammprozess koordiniert werden, was zu einem teuren Overhead führt, der bei Neustarts besonders problematisch wird. Dieser zentralisierte Aufbau führt zu drei kritischen Problemen: Koordinationsaufwand aufgrund obligatorischer TCPStore Verbindungen, Verzögerungen bei der Wiederherstellung, da bei jedem Neustart die gesamte Initialisierungssequenz wiederholt werden muss, und eine einzelne Fehlerquelle im Stammprozess selbst. Dies führt bei jeder Initialisierung oder jedem Neustart der Schulung zu teuren, zentralen Koordinationsschritten.
HyperPod Das Training ohne Checkpoint beseitigt diese Koordinationsengpässe und ermöglicht eine schnellere Behebung von Fehlern, da die Initialisierung ohne Wurzeln und „“ erfolgt. TCPStoreless
## Konfigurationen ohne Wurzeln
Um Rootless zu aktivieren, kann man einfach die folgenden Umgebungsvariablen verfügbar machen.
```
export HPCT_USE_ROOTLESS=1 && \
sysctl -w net.ipv4.ip_local_port_range="20000 65535" && \
```
HPCT\$1USE\$1ROOTLESS: 0 oder 1. Wird verwendet, um Rootless ein- und auszuschalten
sysctl -w net.ipv4.ip\$1local\$1port\$1range="20000 65535": Legt den Portbereich des Systems fest
Sehen Sie sich [das Beispiel für die Aktivierung von Rootless an.](https://github.com/aws/sagemaker-hyperpod-checkpointless-training/blob/main/examples/llama3/launch/pretrain_llama3_70b_checkpointless_p5.yaml#L111-L113)
## Rootless
HyperPod Das Checkpointless-Training bietet neuartige Initialisierungsmethoden, Rootless und, für NCCL- und TCPStoreless Gloo-Prozessgruppen.
Die Implementierung dieser Optimierungen beinhaltet die Modifikation von NCCL, Gloo und: PyTorch
+ Erweiterung der Drittanbieterbibliothek APIs , um Rootless- und Storeless NCCL- und Gloo-Optimierungen zu ermöglichen und gleichzeitig die Abwärtskompatibilität aufrechtzuerhalten
+ Aktualisierung von Prozessgruppen-Backends, sodass optimierte Pfade unter bestimmten Bedingungen verwendet und Probleme bei der Wiederherstellung während des Prozesses behoben werden
+ Umgehung der teuren TCPStore Erstellung auf PyTorch verteilter Ebene bei gleichzeitiger Beibehaltung symmetrischer Adressmuster durch globale Gruppenzähler
Die folgende Grafik zeigt die Architektur der verteilten Trainingsbibliotheken und die Änderungen, die beim Training ohne Checkpoints vorgenommen wurden.
![\[Die folgende Grafik zeigt die Architektur der verteilten Trainingsbibliotheken und die Änderungen, die beim Training ohne Kontrollpunkte vorgenommen wurden.\]](http://docs.aws.amazon.com/de_de/sagemaker/latest/dg/images/hyperpod/hyperpod-checkpointless-training-libraries.png)
### NCCL und Gloo
Dies sind unabhängige Pakete, die die Kernfunktionen der kollektiven Kommunikation erfüllen. Sie stellen Schlüssel APIs wie ncclCommInit Rank bereit, um Kommunikationsnetzwerke zu initialisieren, die zugrunde liegenden Ressourcen zu verwalten und kollektive Kommunikation durchzuführen. Nachdem benutzerdefinierte Änderungen in NCCL und Gloo vorgenommen wurden, optimieren Rootless und Storeless die Initialisierung des Kommunikationsnetzwerks (überspringen z. B. die Verbindung zum). TCPStore Sie können flexibel zwischen der Verwendung der ursprünglichen Codepfade und der optimierten Codepfade wechseln.
### PyTorch Prozessgruppen-Backend
Die Prozessgruppen-Backends, insbesondere ProcessGroup NCCL und ProcessGroupGloo, implementieren das, ProcessGroup APIs indem sie die entsprechenden zugrunde liegenden APIs Bibliotheken aufrufen. Da wir die Bibliotheken von Drittanbietern erweitern APIs, müssen wir sie ordnungsgemäß aufrufen und Codepfadwechsel auf der Grundlage der Kundenkonfigurationen vornehmen.
Zusätzlich zu den Optimierungscodepfaden ändern wir auch das Prozessgruppen-Backend, um die Wiederherstellung während des Prozesses zu unterstützen.
# Dataloader mit Speicherzuweisung
Ein weiterer Mehraufwand beim Neustart ist auf das Laden von Daten zurückzuführen: Der Trainingscluster bleibt inaktiv, während der Dataloader initialisiert, Daten von Remote-Dateisystemen herunterlädt und sie stapelweise verarbeitet.
Um dieses Problem zu lösen, führen wir den Memory Mapped DataLoader (MMAP) Dataloader ein, der vorab abgerufene Batches im persistenten Speicher zwischenspeichert und so sicherstellt, dass sie auch nach einem fehlerbedingten Neustart verfügbar bleiben. Dieser Ansatz macht die Einrichtung des Dataloaders überflüssig und ermöglicht es, das Training mithilfe zwischengespeicherter Batches sofort wieder aufzunehmen, während der Dataloader gleichzeitig die nachfolgenden Daten im Hintergrund neu initialisiert und abruft. Der Datencache befindet sich in jedem Rang, der Trainingsdaten benötigt, und verwaltet zwei Arten von Batches: kürzlich verbrauchte Batches, die für das Training verwendet wurden, und vorab abgerufene Batches, die sofort verwendet werden können.
![\[Dieses Bild zeigt den MMAP-Dataloader, die Caches und die verbrauchten Batches.\]](http://docs.aws.amazon.com/de_de/sagemaker/latest/dg/images/hyperpod/hyperpod-checkpointless-mmap-dataloader.png)
Der MMAP-Dataloader bietet zwei folgende Funktionen:
+ **Datenvorabruf** — Ruft proaktiv vom Dataloader generierte Daten ab und speichert sie im Cache
+ **Persistentes Caching** — Speichert sowohl verbrauchte als auch vorab abgerufene Batches in einem temporären Dateisystem, das Prozessneustarts übersteht
Durch die Verwendung des Caches profitiert der Trainingsjob von folgenden Vorteilen:
+ **Reduzierter Speicherbedarf** — Nutzt die Speicherzuweisung, I/O um eine einzige gemeinsam genutzte Kopie der Daten im Host-CPU-Speicher zu verwalten, wodurch redundante Kopien zwischen GPU-Prozessen vermieden werden (z. B. Reduzierung von 8 Kopien auf 1 bei einer P5-Instance mit 8) GPUs
+ **Schnellere Wiederherstellung** — Reduziert die mittlere Zeit bis zum Neustart (MTTR), da das Training sofort nach zwischengespeicherten Batches wieder aufgenommen werden kann. Somit entfällt das Warten auf die Neuinitialisierung des Dataloaders und die Generierung des ersten Batches
## MMAP-Konfigurationen
Um MMAP zu verwenden, übergeben Sie einfach Ihr ursprüngliches Datenmodul an `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`: Die MMAP-Dataloader-Parameter steuern den Speicherort des Cache-Verzeichnisses, die Größenbeschränkungen und die Delegierung des Datenabrufs. Standardmäßig ruft nur der TP-Rang 0 pro Knoten Daten aus der Quelle ab, während andere Ränge in derselben Datenreplikationsgruppe aus dem gemeinsam genutzten Cache lesen, wodurch redundante Übertragungen vermieden werden.
`MMAPDataModule`: Es umschließt das ursprüngliche Datenmodul und gibt den MMAP-Dataloader sowohl zum Trainieren als auch zur Validierung zurück.
Sehen Sie sich [das Beispiel für die Aktivierung von MMAP an](https://github.com/aws/sagemaker-hyperpod-checkpointless-training/blob/main/examples/gpt_oss/gpt_oss_120b_full_finetune_checkpointless.py#L101-L109).
## API-Referenz
### 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)
```
Konfigurationsklasse für Cache-Resume-Memory-Mapped (MMAP) -Dataloader-Funktionalität beim Checkpointless-Training. HyperPod
Diese Konfiguration ermöglicht effizientes Laden von Daten mit Caching- und Prefetching-Funktionen, sodass das Training nach Ausfällen schnell wieder aufgenommen werden kann, indem zwischengespeicherte Datenstapel in Dateien mit Speicherzuweisung beibehalten werden.
**Parameter**
+ **cache\$1dir** (str, optional) — Verzeichnispfad zum Speichern zwischengespeicherter Datenstapel. Standard: „/\$1cache“ dev/shm/pdl
+ **prefetch\$1length** (int, optional) — Anzahl der Batches, die während des Trainings vorab abgerufen werden müssen. Standard: 10
+ **val\$1prefetch\$1length** (int, optional) — Anzahl der Batches, die während der Validierung vorab abgerufen werden sollen. Standard: 10
+ **lookback\$1length** (int, optional) — Anzahl der zuvor verwendeten Batches, die zur möglichen Wiederverwendung im Cache aufbewahrt werden sollen. Standard: 2
+ **checkpoint\$1frequency (int, optional) — Häufigkeit** der Modell-Checkpoint-Schritte. Wird zur Optimierung der Cache-Leistung verwendet. Standard: keiner
+ **model\$1parallel\$1group** (Objekt, optional) — Prozessgruppe für Modellparallelität. Bei None wird sie automatisch erstellt. Standard: keiner
+ **enable\$1batch\$1encryption (bool, optional) — Ob die Verschlüsselung** für zwischengespeicherte Batchdaten aktiviert werden soll. Standard: False
**Methoden**
```
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)
```
Erstellt eine konfigurierte MMAP-Dataloader-Instanz und gibt sie zurück.
**Parameter**
+ **dataloader\$1init\$1callable (Callable**) — Funktion zur Initialisierung des zugrunde liegenden Dataloaders
+ **parallel\$1state\$1util** (object) — Hilfsprogramm zur prozessübergreifenden Verwaltung des parallel Zustands
+ **step** (int) — Der Datenschritt, von dem aus während des Trainings fortgefahren werden soll
+ **is\$1data\$1loading\$1rank** (Callable) — Funktion, die True zurückgibt, wenn der aktuelle Rang Daten laden soll
+ **create\$1model\$1parallel\$1group\$1callable (Callable**) — Funktion zum Erstellen einer parallel Modellprozessgruppe
+ **name (str, optional) — Namenskennung** für den Dataloader. Standard: „Train“
+ **is\$1val** (bool, optional) — Ob es sich um einen Validierungs-Dataloader handelt. Standard: False
+ **cached\$1len** (int, optional) — Länge der zwischengespeicherten Daten bei Wiederaufnahme aus dem vorhandenen Cache. Standard: 0
Gibt `CacheResumePrefetchedDataLoader` oder — Konfigurierte MMAP-Dataloader-Instanz `CacheResumeReadDataLoader` zurück
`ValueError`Wird ausgelöst, wenn der Schrittparameter ist. `None`
**Beispiel**
```
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"
)
```
**Hinweise**
+ Das Cache-Verzeichnis sollte über ausreichend Speicherplatz und eine schnelle I/O Leistung verfügen (z. B. /dev/shm für In-Memory-Speicher).
+ Durch `checkpoint_frequency` die Einstellung wird die Cache-Leistung verbessert, indem die Cache-Verwaltung auf das Modell-Checkpointing abgestimmt wird
+ Für die Validierung von Dataloaders (`is_val=True`) wird der Schritt auf 0 zurückgesetzt und ein Kaltstart wird erzwungen
+ Je nachdem, ob der aktuelle Rang für das Laden von Daten verantwortlich ist, werden unterschiedliche Dataloader-Implementierungen verwendet
### MMAPDataModul
```
class hyperpod_checkpointless_training.dataloader.mmap_data_module.MMAPDataModule(
data_module,
mmap_config,
parallel_state_util=MegatronParallelStateUtil(),
is_data_loading_rank=None)
```
Ein PyTorch DataModule Lightning-Wrapper, der Funktionen zum Laden von Memory-Mapping-Daten (MMAP) auf vorhandene Daten anwendet, sodass das Training ohne Checkpoints möglich ist. DataModules
Dieser Kurs umschließt ein vorhandenes PyTorch Lightning DataModule und erweitert es um MMAP-Funktionen, wodurch effizientes Zwischenspeichern von Daten und eine schnelle Wiederherstellung bei Trainingsausfällen ermöglicht werden. Es behält die Kompatibilität mit der ursprünglichen DataModule Oberfläche bei und bietet gleichzeitig zusätzliche Trainingsfunktionen ohne Checkpoints.
Parameters
data\$1module (pl. LightningDataModule)
Der DataModule zu verpackende Basiswert (z. B. LLMData Modul)
mmap\$1config () MMAPConfig
Das MMAP-Konfigurationsobjekt, das Verhalten und Parameter beim Zwischenspeichern definiert
`parallel_state_util`(MegatronParallelStateUtil, optional)
Hilfsprogramm für die Verwaltung des parallel Zustands über verteilte Prozesse hinweg. Standard: MegatronParallelStateUtil ()
`is_data_loading_rank`(Aufrufbar, optional)
Funktion, die True zurückgibt, wenn der aktuelle Rang Daten laden soll. Bei None wird standardmäßig parallel\$1state\$1util.is\$1tp\$10 verwendet. Standard: keiner
**Attribute**
`global_step` (int)
Aktueller globaler Trainingsschritt, der für die Wiederaufnahme von Checkpoints verwendet wird
`cached_train_dl_len` (int)
Länge des Trainingsdataloaders im Cache
`cached_val_dl_len` (int)
Länge des Validierungs-Dataloaders im Cache
**Methoden**
```
setup(stage=None)
```
Richten Sie das zugrunde liegende Datenmodul für die angegebene Trainingsphase ein.
`stage`(str, optional)
Phase des Trainings („fit“, „validieren“, „testen“ oder „vorhersagen“). Standard: keiner
```
train_dataloader()
```
Erstellen Sie das Training DataLoader mit MMAP-Wrapping.
*Gibt zurück:* DataLoader — MMAP-umschlossenes Training DataLoader mit Caching- und Prefetching-Funktionen
```
val_dataloader()
```
Erstellen Sie die Validierung mit MMAP-Wrapping. DataLoader
*Gibt zurück:* DataLoader — MMAP-umschlossene Validierung mit Caching-Funktionen DataLoader
```
test_dataloader()
```
Erstellen Sie den Test, DataLoader wenn das zugrunde liegende Datenmodul ihn unterstützt.
*Gibt zurück:* DataLoader oder None — Test DataLoader aus dem zugrunde liegenden Datenmodul, oder None, falls nicht unterstützt
```
predict_dataloader()
```
Erstellen Sie die Prognose DataLoader , wenn das zugrunde liegende Datenmodul sie unterstützt.
*Gibt zurück:* DataLoader oder None — Prognose DataLoader aus dem zugrunde liegenden Datenmodul, oder None, falls nicht unterstützt
```
load_checkpoint(checkpoint)
```
Lädt Checkpoint-Informationen, um das Training ab einem bestimmten Schritt fortzusetzen.
Checkpoint (Diktat)
Checkpoint-Wörterbuch mit dem Schlüssel 'global\$1step'
```
get_underlying_data_module()
```
Ruft das zugrunde liegende verpackte Datenmodul ab.
*Gibt zurück:* pl. LightningDataModule — Das ursprüngliche Datenmodul, das verpackt wurde
```
state_dict()
```
Ruft das Statuswörterbuch der MMAP DataModule für Checkpoints ab.
*Gibt zurück:* dict — Wörterbuch, das zwischengespeicherte Dataloader-Längen enthält
```
load_state_dict(state_dict)
```
Lädt das Statuswörterbuch, um den MMAP-Status wiederherzustellen. DataModule
`state_dict`(Diktat)
Staatliches Wörterbuch, das geladen werden soll
**Eigenschaften**
```
data_sampler
```
Stellen Sie den Datensampler des zugrunde liegenden Datenmoduls dem NeMo Framework zur Verfügung.
*Gibt zurück:* object oder None — Der Datensampler aus dem zugrunde liegenden Datenmodul
**Beispiel**
```
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)
```
**Hinweise**
+ Der Wrapper delegiert die meisten Attributzugriffe mit \$1\$1getattr\$1\$1 an das zugrunde liegende Datenmodul
+ Nur Ränge zum Laden von Daten initialisieren und verwenden das zugrunde liegende Datenmodul tatsächlich; andere Ränge verwenden gefälschte Dataloader
+ Die Längen der zwischengespeicherten Dataloader werden beibehalten, um die Leistung bei der Wiederaufnahme des Trainings zu optimieren
# Prozessbegleitende Wiederherstellung und Training ohne Kontrollpunkte
HyperPod Checkpointless-Training nutzt Modellredundanz, um fehlertolerantes Training zu ermöglichen. Das Kernprinzip besteht darin, dass Modell- und Optimizer-Status über mehrere Knotengruppen hinweg vollständig repliziert werden, wobei Gewichtungsaktualisierungen und Optimizer-Statusänderungen innerhalb jeder Gruppe synchron repliziert werden. Wenn ein Fehler auftritt, schließen fehlerfreie Replikate ihre Optimierungsschritte ab und übertragen die aktualisierten Zustände an wiederherstellende Replikate. model/optimizer
Dieser auf Modellredundanz basierende Ansatz ermöglicht mehrere Mechanismen zur Fehlerbehandlung:
+ **Prozessbegleitende Wiederherstellung:** Prozesse bleiben trotz Fehlern aktiv, wobei alle Modell- und Optimierungsstatus im GPU-Speicher mit den neuesten Werten beibehalten werden
+ **Reibungslose Behandlung von Abbrüchen:** kontrollierte Abbrüche und Bereinigung der Ressourcen bei betroffenen Vorgängen
+ **Neuausführung von Codeblöcken:** Nur die betroffenen Codesegmente innerhalb eines wiederausführbaren Codeblocks (RCB) werden erneut ausgeführt
+ **Wiederherstellung ohne Kontrollpunkt ohne verlorenen Trainingsfortschritt:** Da die Prozesse andauern und die Zustände im Speicher verbleiben, geht kein Trainingsfortschritt verloren. Wenn ein Fehler auftritt, wird das Training mit dem vorherigen Schritt fortgesetzt, im Gegensatz zum letzten gespeicherten Checkpoint
**Konfigurationen ohne Checkpoint**
Hier ist der Kernausschnitt des Checkpointless-Trainings.
```
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`: Alle Ränge warten auf die Ranginformationen von der Infrastruktur. HyperpodTrainingOperator
+ `HPWrapper`: Python-Funktionswrapper, der Neustartfunktionen für einen wiederausführbaren Codeblock (RCB) ermöglicht. Die Implementierung verwendet einen Kontextmanager anstelle eines Python-Dekorators, da Dekoratoren die Anzahl der zur Laufzeit RCBs zu überwachenden Objekte nicht bestimmen können.
+ `CudaHealthCheck`: Stellt sicher, dass sich der CUDA-Kontext für den aktuellen Prozess in einem fehlerfreien Zustand befindet, indem es mit der GPU synchronisiert wird. Verwendet das in der Umgebungsvariablen LOCAL\$1RANK angegebene Gerät oder verwendet standardmäßig das CUDA-Gerät des Haupt-Threads, wenn LOCAL\$1RANK nicht gesetzt ist.
+ `HPAgentK8sAPIFactory`: Diese API ermöglicht ein Training ohne Checkpoint, um den Trainingsstatus anderer Pods im Kubernetes-Trainingscluster abzufragen. Sie bietet auch eine Barriere auf Infrastrukturebene, die sicherstellt, dass alle Ränge Abbruch- und Neustartvorgänge erfolgreich abschließen, bevor sie fortfahren.
+ `CheckpointManager`: Verwaltet die Checkpoints und die Wiederherstellung im Speicher und sorgt so für Fehlertoleranz ohne Checkpoints. peer-to-peer Es hat die folgenden Kernaufgaben:
+ **In-Memory-Checkpoint-Management**: Speichert und verwaltet NeMo Modell-Checkpoints im Arbeitsspeicher für eine schnelle Wiederherstellung ohne Festplatte I/O bei Wiederherstellungsszenarien ohne Checkpoint.
+ **Überprüfung der Durchführbarkeit der Wiederherstellung**: Ermittelt, ob eine Wiederherstellung ohne Checkpoint möglich ist, indem die globale Schrittkonsistenz, der Rangstatus und die Integrität des Modellstatus überprüft werden.
+ **Peer-to-Peer Orchestrierung der Wiederherstellung**: Koordiniert die Checkpoint-Übertragung zwischen fehlerfreien und ausgefallenen Rängen mithilfe verteilter Kommunikation für eine schnelle Wiederherstellung.
+ **RNG State Management**: Behält die Zustände des Zufallszahlengenerators in Python,, und Megatron bei und stellt sie wieder her NumPy PyTorch, um eine deterministische Wiederherstellung zu ermöglichen.
+ **[Optional] Checkpoint-Offload: Verlagerung im Speicher-Checkpoint** auf die CPU, wenn die GPU nicht über genügend Speicherkapazität verfügt.
+ `PEFTCheckpointManager`: Es wird erweitert, `CheckpointManager` indem die Gewichte des Basismodells für die PEFT-Feinabstimmung beibehalten werden.
+ `CheckpointlessAbortManager`: Verwaltet Abbruchvorgänge in einem Hintergrund-Thread, wenn ein Fehler auftritt. Standardmäßig werden Checkpointing TransformerEngine, TorchDistributed und abgebrochen. DataLoader Benutzer können bei Bedarf benutzerdefinierte Abbruch-Handler registrieren. Nach Abschluss des Abbruchs muss die gesamte Kommunikation beendet und alle Prozesse und Threads müssen beendet werden, um Ressourcenlecks zu verhindern.
+ `CheckpointlessFinalizeCleanup`: Führt die letzten Bereinigungsvorgänge im Haupt-Thread für Komponenten durch, die im Hintergrundthread nicht sicher abgebrochen oder bereinigt werden können.
+ `CheckpointlessMegatronStrategy`: Das erbt `MegatronStrategy` von der Form in Nemo. Beachten Sie, dass für das Training ohne Checkpoint mindestens 2 erforderlich sind`num_distributed_optimizer_instances`, damit die Optimizer-Replikation durchgeführt werden kann. Die Strategie kümmert sich auch um die Registrierung wichtiger Attribute und die Initialisierung von Prozessgruppen, z. B. ohne Wurzeln.
+ `CheckpointlessCallback`: Lightning-Rückruf, der das NeMo Training in das Fehlertoleranzsystem des Checkpointless-Trainings integriert. Es hat die folgenden Kernaufgaben:
+ **Lebenszyklusmanagement für Trainingsschritte**: Verfolgt den Trainingsfortschritt und koordiniert je ParameterUpdateLock nach Trainingsstatus (erster Schritt im Vergleich zu nachfolgenden Schritten) die Wiederherstellung enable/disable ohne Checkpoint.
+ **Koordination des Checkpoint-Zustands**: Verwaltet das Speichern/Wiederherstellen von Checkpoints im PEFT-Basismodell im Arbeitsspeicher.
+ `CheckpointlessCompatibleConnector`: Eine PTL`CheckpointConnector`, die versucht, die Checkpoint-Datei vorab in den Speicher zu laden, wobei der Quellpfad in dieser Priorität festgelegt wird:
+ versuchen Sie es mit einer Wiederherstellung ohne Checkpoint
+ Wenn checkpointless None zurückgibt, wird auf parent.resume\$1start () zurückgegriffen
Sehen Sie sich das Beispiel an, um Codes Trainingsfunktionen ohne [Checkpoint](https://github.com/aws/sagemaker-hyperpod-checkpointless-training/blob/main/examples/gpt_oss/gpt_oss_120b_full_finetune.py) hinzuzufügen.
**Konzepte**
In diesem Abschnitt werden Trainingskonzepte ohne Checkpoint vorgestellt. Checkpointless-Schulungen bei Amazon SageMaker HyperPod unterstützen die Wiederherstellung während des Prozesses. Diese API-Schnittstelle folgt einem ähnlichen Format wie die. NVRx APIs
**Konzept — Wiederausführbarer Codeblock (RCB)**
Wenn ein Fehler auftritt, bleiben gesunde Prozesse am Leben, aber ein Teil des Codes muss erneut ausgeführt werden, um die Trainingszustände und Python-Stacks wiederherzustellen. Ein wiederausführbarer Codeblock (RCB) ist ein bestimmtes Codesegment, das bei der Wiederherstellung nach einem Fehler erneut ausgeführt wird. Im folgenden Beispiel umfasst der RCB das gesamte Trainingsskript (d. h. alles, was unter main () steht), was bedeutet, dass bei jeder Wiederherstellung nach einem Fehler das Trainingsskript neu gestartet wird, wobei das In-Memory-Modell und der Optimizer-Status beibehalten werden.
**Konzept — Fehlerkontrolle**
Ein Fault Controller-Modul erhält Benachrichtigungen, wenn beim Training ohne Checkpoint Fehler auftreten. Dieser Fehlercontroller umfasst die folgenden Komponenten:
+ **Fehlererkennungsmodul:** Empfängt Benachrichtigungen über Infrastrukturfehler
+ **RCB-Definition APIs:** Ermöglicht es Benutzern, den wiederausführbaren Codeblock (RCB) in ihrem Code zu definieren
+ **Neustartmodul:** Beendet den RCB, bereinigt Ressourcen und startet den RCB neu
![\[Dieses Bild zeigt, wie ein Fehler-Controller-Modul während eines Trainings ohne Checkpoint Benachrichtigungen erhält, wenn ein Fehler auftritt.\]](http://docs.aws.amazon.com/de_de/sagemaker/latest/dg/images/hyperpod/hyperpod-checkpointless-fault-controller-module.png)
**Konzept — Modellredundanz**
Das Training großer Modelle erfordert normalerweise eine ausreichend große Datenparallelgröße, um Modelle effizient zu trainieren. Bei herkömmlicher Datenparallelität wie PyTorch DDP und Horovod wird das Modell vollständig repliziert. Fortgeschrittenere Techniken der Shard-Datenparallelität wie DeepSpeed ZerO Optimizer und FSDP unterstützen auch den Hybrid-Sharding-Modus, der das Sharding der Status innerhalb der Sharding-Gruppe und die vollständige Replikation zwischen Replikationsgruppen ermöglicht. model/optimizer NeMo verfügt über diese Hybrid-Sharding-Funktion auch über ein Argument num\$1distributed\$1optimizer\$1instances, das Redundanz ermöglicht.
Das Hinzufügen von Redundanz bedeutet jedoch, dass das Modell nicht vollständig auf den gesamten Cluster verteilt wird, was zu einer höheren Speicherauslastung des Geräts führt. Die Menge des redundanten Speichers hängt von den spezifischen Model-Sharding-Techniken ab, die der Benutzer implementiert. Die Gewichtungen, Gradienten und der Aktivierungsspeicher des Modells mit niedriger Genauigkeit werden nicht beeinträchtigt, da sie aufgrund der Modellparallelität fragmentiert werden. Das hochpräzise Master-Modell weights/gradients und der Optimizer-Status werden davon beeinflusst. Durch das Hinzufügen eines redundanten Modellreplikats erhöht sich die Speicherauslastung des Geräts um etwa die Größe eines DCP-Checkpoints.
Beim Hybrid-Sharding werden die Kollektive der gesamten DP-Gruppen in relativ kleinere Kollektive aufgeteilt. Bisher gab es in der gesamten DP-Gruppe ein Prinzip zur Reduzierung der Streuung und ein All-Gathering. Nach dem Hybrid-Sharding läuft die Methode zur Reduzierung der Streuung nur innerhalb der einzelnen Modellreplikate, und es wird eine All-Reduce-Methode für alle Modellreplikatgruppen geben. Das All-Gather-System wird auch innerhalb jeder Modellreplikation ausgeführt. Dadurch bleibt das gesamte Kommunikationsvolumen in etwa unverändert, aber die Kollektive arbeiten mit kleineren Gruppen, sodass wir mit einer besseren Latenz rechnen.
**Konzept — Fehler- und Neustarttypen**
In der folgenden Tabelle sind verschiedene Fehlertypen und zugehörige Wiederherstellungsmechanismen aufgeführt. Beim Checkpointless-Training wird zunächst versucht, Fehler mithilfe einer prozessinternen Wiederherstellung zu beheben, gefolgt von einem Neustart auf Prozessebene. Nur bei einem schwerwiegenden Ausfall (z. B. wenn mehrere Knoten gleichzeitig ausfallen), wird auf einen Neustart auf Jobebene zurückgegriffen.
| Art des Fehlers | Ursache | Art der Wiederherstellung | Wiederherstellungsmechanismus |
| --- | --- | --- | --- |
| Fehler während des Prozesses | Fehler auf Codeebene, Ausnahmen | Prozessbegleitende Wiederherstellung (IPR) | RCB innerhalb des bestehenden Prozesses erneut ausführen; intakte Prozesse bleiben aktiv |
| Fehler beim Neustart des Prozesses | Beschädigter CUDA-Kontext, Prozess beendet | Neustart auf Prozessebene (PLR) | SageMaker HyperPod Der geschulte Bediener startet die Prozesse neu; der Neustart des K8s-Pods wird übersprungen |
| Fehler beim Austausch des Knotens | Dauerhafter node/GPU Hardwarefehler | Neustart auf Jobebene (JLR) | Ersetzen Sie den ausgefallenen Knoten; starten Sie den gesamten Trainingsjob neu |
**Konzept: Atomic Lock-Schutz für den Optimizer-Schritt**
Die Modellausführung ist in drei Phasen unterteilt: Vorwärtsausbreitung, Rückwärtsausbreitung und Optimierungsschritt. Das Wiederherstellungsverhalten hängt vom Zeitpunkt des Fehlers ab:
+ Übertragung **vorwärts/rückwärts:** Gehen Sie zurück zum Anfang des aktuellen Trainingsschritts und senden Sie den Modellstatus an die Ersatzknoten
+ **Optimierungsschritt:** Lassen Sie fehlerfreie Replikate den Schritt unter Sperrschutz abschließen, und senden Sie dann die aktualisierten Modellstatus an die Ersatzknoten
Diese Strategie stellt sicher, dass abgeschlossene Optimizer-Updates niemals verworfen werden, wodurch die Zeit für die Fehlerbehebung reduziert wird.
![\[Dieses Bild zeigt, wie mit einem Ausfall umgegangen wird, je nachdem, ob er vor oder nach dem Ausfall auftritt.\]](http://docs.aws.amazon.com/de_de/sagemaker/latest/dg/images/hyperpod/hyperpod-checkpointless-optimizer.png)
## Ablaufdiagramm des Checkpointless-Trainings
![\[Dieses Diagramm veranschaulicht den Trainingsablauf ohne Kontrollpunkte.\]](http://docs.aws.amazon.com/de_de/sagemaker/latest/dg/images/hyperpod/hyperpod-checkpointless-training-flow.png)
Die folgenden Schritte beschreiben den Prozess der Fehlererkennung und Wiederherstellung ohne Checkpoint:
1. Die Trainingsschleife beginnt
1. Es tritt ein Fehler auf
1. Prüfen Sie die Durchführbarkeit eines Lebenslaufs ohne Checkpoint
1. Prüfen Sie, ob es möglich ist, einen Lebenslauf ohne Kontrollpunkt durchzuführen
+ Falls möglich, versuchen Sie eine Wiederaufnahme ohne Checkpoint
+ Wenn die Wiederaufnahme fehlschlägt, greifen Sie auf das Laden am Checkpoint aus dem Speicher zurück
+ Wenn die Wiederaufnahme erfolgreich ist, wird das Training im wiederhergestellten Zustand fortgesetzt
+ Falls dies nicht möglich ist, greifen Sie auf das Laden am Checkpoint aus dem Speicher zurück
1. Ressourcen bereinigen — Brechen Sie alle Prozessgruppen und Backends ab und geben Sie Ressourcen frei, um den Neustart vorzubereiten.
1. Trainingsschleife fortsetzen — eine neue Trainingsschleife beginnt und der Vorgang kehrt zu Schritt 1 zurück.
## API-Referenz
### wait\$1rank
```
hyperpod_checkpointless_training.inprocess.train_utils.wait_rank()
```
Wartet auf Ranginformationen von der aktuellen Prozessumgebung HyperPod, ruft sie ab und aktualisiert sie anschließend mit verteilten Trainingsvariablen.
Diese Funktion ruft die richtigen Rangzuweisungen und Umgebungsvariablen für verteiltes Training ab. Sie stellt sicher, dass jeder Prozess die passende Konfiguration für seine Rolle im verteilten Trainingsjob erhält.
**Parameter**
Keine
**Rückgabewerte**
**Keine**
**Behavior**
+ **Prozessüberprüfung**: Überspringt die Ausführung, wenn sie von einem Unterprozess aus aufgerufen wird (läuft nur in) MainProcess
+ **Umgebungsabruf**: Ruft aktuelle Variablen `RANK` und `WORLD_SIZE` aus Umgebungsvariablen ab
+ **HyperPod Kommunikation**: Ruft `hyperpod_wait_rank_info()` zum Abrufen von Ranginformationen von HyperPod
+ **Umgebungsupdate**: Aktualisiert die aktuelle Prozessumgebung mit arbeiterspezifischen Umgebungsvariablen, die von empfangen wurden HyperPod
**Umgebungsvariablen**
Die Funktion liest die folgenden Umgebungsvariablen:
+ **RANK** (*int*) — Aktueller Prozessrang (Standard: -1, falls nicht gesetzt)
+ **WORLD\$1SIZE** (*int*) — Gesamtzahl der Prozesse im verteilten Job (Standard: 0, falls nicht festgelegt)
**Erhöht**
+ **AssertionError**— Wenn die Antwort von nicht HyperPod das erwartete Format hat oder wenn Pflichtfelder fehlen
**Beispiel**
```
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')
```
**Hinweise**
+ Wird nur im Hauptprozess ausgeführt; Aufrufe von Unterprozessen werden automatisch übersprungen
+ Die Funktion blockiert, bis die Ranginformationen HyperPod bereitgestellt werden
### 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)
```
*Python-Funktionswrapper, der Neustartfunktionen für einen reausführbaren Codeblock (RCB) beim Checkpointless-Training ermöglicht. HyperPod *
*Dieser Wrapper bietet Funktionen für Fehlertoleranz und automatische Wiederherstellung, indem er die Trainingsausführung überwacht und bei Ausfällen Neustarts zwischen verteilten Prozessen koordiniert. Er verwendet eher einen Context-Manager-Ansatz als einen Dekorateur, um die globalen Ressourcen während des gesamten Schulungszyklus aufrechtzuerhalten.*
**Parameter**
+ **abort** (*Abort*, *optional*) — Die Ausführung wird asynchron abgebrochen, wenn Fehler erkannt werden. Standard: `Compose(HPAbortTorchDistributed())`
+ **finalize (Finalize**, *optional) — Lokaler *Finalisierungshandler** auf Rang, der beim Neustart ausgeführt wird. Standard: `None`
+ **health\$1check** (*HealthCheck*, *optional*) — Lokale Zustandsprüfung nach Rang, die während des Neustarts ausgeführt wird. Standard: `None`
+ **hp\$1api\$1factory** (*Callable*, *optional*) — Factory-Funktion zum Erstellen einer API für die Interaktion. HyperPod HyperPod Standard: `None`
+ **abort\$1timeout (*float*, *optional*) — Timeout** für den Abbruch eines Aufrufs im Fehlersteuerungsthread. Standard: `None`
+ **enabled** (*bool*, *optional*) — Aktiviert die Wrapper-Funktionalität. Wenn`False`, wird der Wrapper zu einem Pass-Through. Standard: `True`
+ **trace\$1file\$1path (*str*, *optional*) — Pfad zur** Trace-Datei für die Profilerstellung. VizTracer Standard: `None`
+ **async\$1raise\$1before\$1abort (*bool*, optional) — Aktiviert das Erhöhen vor dem Abbruch** *im Fehlerkontroll-Thread.* Standard: `True`
+ **early\$1abort\$1communicator (bool, optional) — Bricht den Kommunikator** **(NCCL/Gloo) ab, bevor der Dataloader abgebrochen wird.** Standard: `False`
+ **checkpoint\$1manager (Beliebig***,* *optional*) — Manager für die Behandlung von Checkpoints während der Wiederherstellung. Standard: `None`
+ **check\$1memory\$1status** (*bool*, *optional*) — Aktiviert die Überprüfung und Protokollierung des Speicherstatus. Standard: `True`
**Methoden**
```
def __call__(self, fn)
```
*Schließt eine Funktion ein, um Neustartfunktionen zu aktivieren.*
**Parameter:**
+ **fn** (*Callable*) — Die Funktion, die mit Neustartfunktionen umschlossen werden soll
**Gibt zurück:**
+ **Aufrufbar** — Umschlossene Funktion mit Neustartfunktionen oder ursprüngliche Funktion, falls deaktiviert
**Beispiel**
```
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
```
**Hinweise**
+ Der Wrapper muss verfügbar `torch.distributed` sein
+ Wenn`enabled=False`, wird der Wrapper zu einem Pass-Through und gibt die ursprüngliche Funktion unverändert zurück
+ Der Wrapper verwaltet globale Ressourcen wie die Überwachung von Threads während des gesamten Trainingszyklus
+ Unterstützt die VizTracer Profilerstellung, sofern sie bereitgestellt wird `trace_file_path`
+ Lässt sich HyperPod für eine koordinierte Fehlerbehandlung in verteilten Schulungen integrieren
### HPCallWrapper
```
class hyperpod_checkpointless_training.inprocess.wrap.HPCallWrapper(wrapper)
```
Überwacht und verwaltet den Status eines Restart-Codeblocks (RCB) während der Ausführung.
Diese Klasse befasst sich mit dem Lebenszyklus der RCB-Ausführung, einschließlich der Fehlererkennung, der Koordination mit anderen Rängen bei Neustarts und Bereinigungsvorgängen. Es verwaltet die verteilte Synchronisation und gewährleistet eine konsistente Wiederherstellung aller Trainingsprozesse.
**Parameter**
+ **wrapper** (*HPWrapper*) — Der übergeordnete Wrapper, der globale Einstellungen für die prozessinterne Wiederherstellung enthält
**Attribute**
+ **step\$1upon\$1restart** (*int*) — Zähler, der die Schritte seit dem letzten Neustart verfolgt und zur Bestimmung der Neustartstrategie verwendet wird
**Methoden**
```
def initialize_barrier()
```
Warten Sie auf die HyperPod Barrierensynchronisierung, nachdem Sie auf eine Ausnahme von RCB gestoßen sind.
```
def start_hp_fault_handling_thread()
```
Starten Sie den Fehlerbehandlungs-Thread zur Überwachung und Koordination von Fehlern.
```
def handle_fn_exception(call_ex)
```
Verarbeiten Sie Ausnahmen von der Ausführungsfunktion oder vom RCB.
**Parameter:**
+ **call\$1ex** (*Exception*) — Ausnahme von der Überwachungsfunktion
```
def restart(term_ex)
```
Führt den Neustart-Handler aus, einschließlich Finalisierung, Garbage-Collection und Integritätsprüfungen.
**Parameter:**
+ **term\$1ex** (*RankShouldRestart*) — Eine Terminierungsausnahme, die den Neustart auslöst
```
def launch(fn, *a, **kw)
```
*Führt den RCB mit der richtigen Ausnahmebehandlung aus.*
**Parameter:**
+ **fn** (*Callable*) — Funktion, die ausgeführt werden soll
+ **a** — Funktionsargumente
+ **kw** — Argumente für Funktionsschlüsselwörter
```
def run(fn, a, kw)
```
Hauptausführungsschleife, die Neustarts und Barrierensynchronisierung verarbeitet.
**Parameter:**
+ **fn** (*Callable*) — Funktion, die ausgeführt werden soll
+ **a** — Funktionsargumente
+ **kw** — Argumente für Funktionsschlüsselwörter
```
def shutdown()
```
Threads zur Fehlerbehandlung und Überwachung herunterfahren.
**Hinweise**
+ Behandelt automatisch `RankShouldRestart` Ausnahmen für eine koordinierte Wiederherstellung
+ Verwaltet die Speicherverfolgung und Abbrüche sowie die Speicherbereinigung bei Neustarts
+ Unterstützt sowohl In-Process-Recovery- als auch PLR-Strategien (Process-Level Restart), die auf dem Timing von Fehlern basieren
### CudaHealthCheck
```
class hyperpod_checkpointless_training.inprocess.health_check.CudaHealthCheck(timeout=datetime.timedelta(seconds=30))
```
Stellt sicher, dass sich der CUDA-Kontext für den aktuellen Prozess während der Trainingswiederherstellung ohne Checkpoint in einem fehlerfreien Zustand befindet.
Diese Integritätsprüfung wird mit der GPU synchronisiert, um sicherzustellen, dass der CUDA-Kontext nach einem Trainingsfehler nicht beschädigt ist. Es führt GPU-Synchronisierungsvorgänge durch, um Probleme zu erkennen, die eine erfolgreiche Wiederaufnahme des Trainings verhindern könnten. Die Integritätsprüfung wird ausgeführt, nachdem die verteilten Gruppen gelöscht wurden und die Finalisierung abgeschlossen ist.
**Parameter**
+ **timeout** (*datetime.timedelta, *optional*) — Timeout-Dauer* für GPU-Synchronisierungsvorgänge. Standard: `datetime.timedelta(seconds=30)`
**Methoden**
```
__call__(state, train_ex=None)
```
Führen Sie die CUDA-Integritätsprüfung aus, um die Integrität des GPU-Kontexts zu überprüfen.
**Parameter:**
+ **state** (*HPState*) — Aktueller HyperPod Status, der Ranginformationen und verteilte Informationen enthält
+ **train\$1ex** (*Ausnahme*, *optional*) — Die ursprüngliche Trainingsausnahme, die den Neustart ausgelöst hat. Standard: `None`
**Gibt zurück:**
+ **Tupel** — Ein Tupel, das `(state, train_ex)` unverändert enthält, falls die Gesundheitsprüfung bestanden wurde
**Erhöht:**
+ **TimeoutError**— Wenn bei der GPU-Synchronisierung ein Timeout auftritt, was auf einen potenziell beschädigten CUDA-Kontext hindeutet
**Beibehaltung des Zustands**: Gibt den ursprünglichen Status und die Ausnahme unverändert zurück, wenn alle Prüfungen bestanden wurden
**Beispiel**
```
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
```
**Hinweise**
+ Verwendet Threading, um den Timeout-Schutz für die GPU-Synchronisierung zu implementieren
+ Entwickelt, um beschädigte CUDA-Kontexte zu erkennen, die eine erfolgreiche Wiederaufnahme des Trainings verhindern könnten
+ Sollte als Teil der Fehlertoleranz-Pipeline in verteilten Trainingsszenarien verwendet werden
### HPAgentK8s APIFactory
```
class hyperpod_checkpointless_training.inprocess.train_utils.HPAgentK8sAPIFactory()
```
Factory-Klasse zum Erstellen von HPAgent K8SAPI-Instanzen, die mit der HyperPod Infrastruktur kommunizieren, um die Trainingskoordination auf verteilter Ebene zu gewährleisten.
Diese Factory bietet eine standardisierte Methode zur Erstellung und Konfiguration von HPAgent K8sAPI-Objekten, die die Kommunikation zwischen Trainingsprozessen und der Steuerungsebene regeln. HyperPod Es kapselt die Erstellung des zugrunde liegenden Socket-Clients und der API-Instanz und gewährleistet so eine konsistente Konfiguration in verschiedenen Teilen des Trainingssystems.
**Methoden**
```
__call__()
```
Erstellen Sie eine für die Kommunikation konfigurierte HPAgent K8SAPI-Instanz und geben Sie sie zurück. HyperPod
**Gibt zurück:**
+ **HPAgentk8SAPI — Konfigurierte API-Instanz** für die Kommunikation mit der Infrastruktur HyperPod
**Beispiel**
```
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
```
**Hinweise**
+ Entwickelt, um nahtlos mit HyperPod der Kubernetes-basierten Infrastruktur zusammenzuarbeiten. Es ist für die koordinierte Fehlerbehandlung und -behebung in verteilten Schulungsszenarien unerlässlich
### CheckpointManager
```
class hyperpod_checkpointless_training.nemo_plugins.checkpoint_manager.CheckpointManager(
enable_checksum=False,
enable_offload=False)
```
Verwaltet die Checkpoints und die peer-to-peer Wiederherstellung im Speicher und sorgt so für Fehlertoleranz ohne Checkpoints bei verteilten Schulungen.
Diese Klasse bietet die Kernfunktionen für das Training HyperPod ohne Checkpoints, indem sie NeMo Modell-Checkpoints im Speicher verwaltet, die Durchführbarkeit der Wiederherstellung überprüft und die Checkpoint-Übertragung zwischen fehlerfreien und ausgefallenen Rängen orchestriert peer-to-peer. Dadurch entfällt die Notwendigkeit einer Festplatte I/O bei der Wiederherstellung, wodurch die mittlere Wiederherstellungszeit (MTTR) erheblich reduziert wird.
**Parameter**
+ **enable\$1checksum** (*bool*, *optional*) — Aktiviert die Überprüfung der Modellstatus-Prüfsumme für Integritätsprüfungen während der Wiederherstellung. Standard: `False`
+ **enable\$1offload** (*bool*, *optional*) — Aktiviert das Checkpoint-Offloading vom GPU- in den CPU-Speicher, um die GPU-Speichernutzung zu reduzieren. Standard: `False`
**Attribute**
+ **global\$1step** (*int* oder *None*) — Aktueller Trainingsschritt, der dem gespeicherten Checkpoint zugeordnet ist
+ **rng\$1states** (*list* oder *None*) — Gespeicherte Zufallszahlengenerator-Zustände für die deterministische Wiederherstellung
+ **checksum\$1manager (*MemoryChecksumManager*) — Manager** für die Überprüfung der Prüfsumme des Modellstatus
+ **parameter\$1update\$1lock** (*ParameterUpdateLock*) — Sperre zur Koordination von Parameter-Updates während der Wiederherstellung
**Methoden**
```
save_checkpoint(trainer)
```
Speichert den NeMo Modell-Checkpoint im Speicher für eine mögliche Wiederherstellung ohne Checkpoint.
**Parameter:**
+ **trainer** (*pytorch\$1lightning.Trainer*) — Lightning-Trainer-Instanz PyTorch
**Hinweise:**
+ Wird am Ende des Batches oder während der Ausnahmebehandlung CheckpointlessCallback aufgerufen
+ Erstellt Wiederherstellungspunkte ohne I/O Festplatten-Overhead
+ Speichert den vollständigen Modell-, Optimizer- und Scheduler-Status
```
delete_checkpoint()
```
Löschen Sie den In-Memory-Checkpoint und führen Sie Bereinigungsvorgänge durch.
**Hinweise:**
+ Löscht Checkpoint-Daten, RNG-Zustände und zwischengespeicherte Tensoren
+ Führt die Speicherbereinigung und die CUDA-Cache-Bereinigung durch
+ Wird nach erfolgreicher Wiederherstellung aufgerufen oder wenn der Checkpoint nicht mehr benötigt wird
```
try_checkpointless_load(trainer)
```
Versuchen Sie eine Wiederherstellung ohne Checkpoint, indem Sie den Status aus Peer-Rängen laden.
**Parameter:**
+ **trainer** (*pytorch\$1lightning.Trainer*) — Lightning-Trainer-Instanz PyTorch
**Gibt zurück:**
+ **dict** oder **None** — Checkpoint wurde wiederhergestellt, falls erfolgreich, None, wenn ein Fallback auf die Festplatte erforderlich ist
**Hinweise:**
+ Wichtigster Einstiegspunkt für die Wiederherstellung ohne Checkpoint
+ Überprüft die Durchführbarkeit der Wiederherstellung, bevor eine P2P-Übertragung versucht wird
+ Bereinigt nach dem Wiederherstellungsversuch immer die In-Memory-Checkpoints
```
checkpointless_recovery_feasible(trainer, include_checksum_verification=True)
```
Stellen Sie fest, ob eine Wiederherstellung ohne Checkpoint für das aktuelle Fehlerszenario möglich ist.
**Parameter:**
+ **trainer** (*pytorch\$1lightning.Trainer*) — Lightning-Trainer-Instanz PyTorch
+ **include\$1checksum\$1verification (bool, optional) — Ob die Prüfsummenvalidierung** **eingeschlossen werden soll.** Standard: `True`
**Gibt zurück:**
+ **bool** — True, wenn eine Wiederherstellung ohne Checkpoint möglich ist, andernfalls False
**Validierungskriterien:**
+ Gleichbleibende globale Schrittweite in gesunden Rängen
+ Es stehen ausreichend fehlerfreie Replikate für die Wiederherstellung zur Verfügung
+ Integrität der Prüfsumme für den Modellstatus (falls aktiviert)
```
store_rng_states()
```
Speichert alle Zustände des Zufallszahlengenerators für die deterministische Wiederherstellung.
**Hinweise:**
+ Erfasst Python- NumPy, PyTorch CPU/GPU- und Megatron-RNG-Zustände
+ Unverzichtbar für die Aufrechterhaltung des Trainingsdeterminismus nach der Erholung
```
load_rng_states()
```
Stellen Sie alle RNG-Zustände wieder her, um die deterministische Erholung fortzusetzen.
**Hinweise:**
+ Stellt alle zuvor gespeicherten RNG-Zustände wieder her
+ Stellt sicher, dass das Training mit identischen Zufallssequenzen fortgesetzt wird
```
maybe_offload_checkpoint()
```
Wenn Offload aktiviert ist, wird der Checkpoint von der GPU auf den CPU-Speicher verlagert.
**Hinweise:**
+ Reduziert die GPU-Speicherauslastung für große Modelle
+ Wird nur ausgeführt, wenn `enable_offload=True`
+ Behält den Zugriff auf Checkpoints für die Wiederherstellung bei
**Beispiel**
```
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
```
**Validierung**: Überprüft die Checkpoint-Integrität anhand von Prüfsummen (falls aktiviert)
**Hinweise**
+ Nutzt verteilte Kommunikationsprimitive für eine effiziente P2P-Übertragung
+ Verarbeitet automatisch Tensor-DType-Konvertierungen und Geräteplatzierung
+ **MemoryChecksumManager**— Verwaltet die Integritätsprüfung des Modellzustands
### PEFTCheckpoint— Manager
```
class hyperpod_checkpointless_training.nemo_plugins.checkpoint_manager.PEFTCheckpointManager(
*args,
**kwargs)
```
Verwaltet Checkpoints für PEFT (Parameter-Efficient Fine-Tuning) mit separater Basis- und Adapterverwaltung für eine optimierte Wiederherstellung ohne Checkpoints.
Dieser spezialisierte Checkpoint-Manager ermöglicht die Optimierung von PEFT-Workflows CheckpointManager , indem er die Gewichtung des Basismodells von den Adapterparametern trennt.
**Parameter**
Erbt alle Parameter von: **CheckpointManager**
+ **enable\$1checksum** (*bool*, *optional*) — Aktiviert die Überprüfung der Prüfsumme des Modellstatus. Standard: `False`
+ **enable\$1offload (*bool*, optional) — Aktiviert das Checkpoint-Offloading** *in den CPU-Speicher.* Standard: `False`
**Zusätzliche Attribute**
+ **params\$1to\$1save** (*set) — Satz* von Parameternamen, die als Adapterparameter gespeichert werden sollen
+ **base\$1model\$1weights** (*dict* oder *None*) — Gewichte des Basismodells im Cache, einmal gespeichert und wiederverwendet
+ **base\$1model\$1keys\$1to\$1extract (list oder None) — Schlüssel zum Extrahieren** **von Basismodell-Tensoren während der P2P-Übertragung**
**Methoden**
```
maybe_save_base_model(trainer)
```
Speichert einmal die Gewichte des Basismodells und filtert dabei die Adapterparameter heraus.
**Parameter:**
+ **trainer** (*pytorch\$1lightning.Trainer) — Lightning-Trainer-Instanz* PyTorch
**Hinweise:**
+ Speichert die Gewichte des Basismodells nur beim ersten Aufruf; nachfolgende Aufrufe sind keine Operationen
+ Filtert Adapterparameter heraus, um nur eingefrorene Basismodellgewichte zu speichern
+ Die Gewichte des Basismodells werden über mehrere Trainingseinheiten hinweg beibehalten
```
save_checkpoint(trainer)
```
Speichern Sie den Prüfpunkt des NeMo PEFT-Adaptermodells im Speicher für eine mögliche Wiederherstellung ohne Checkpoint.
**Parameter:**
+ **trainer** (*pytorch\$1lightning.Trainer) — Lightning-Trainer-Instanz* PyTorch
**Hinweise:**
+ Ruft automatisch auf, wenn das Basismodell noch nicht gespeichert ist `maybe_save_base_model()`
+ Filtert den Checkpoint so, dass er nur Adapterparameter und Trainingsstatus enthält
+ Reduziert die Größe der Checkpoints im Vergleich zu Checkpoints des vollständigen Modells erheblich
```
try_base_model_checkpointless_load(trainer)
```
Das PEFT-Basismodell versucht, die Wiederherstellung ohne Checkpoint zu gewichten, indem der Status aus Peer-Rängen geladen wird.
**Parameter:**
+ **trainer** (*pytorch\$1lightning.Trainer*) — Lightning-Trainer-Instanz PyTorch
**Gibt zurück:**
+ **dict** oder **None** — Der Basismodell-Checkpoint wurde wiederhergestellt, falls erfolgreich, None, wenn ein Fallback erforderlich ist
**Hinweise:**
+ Wird während der Modellinitialisierung verwendet, um die Gewichte des Basismodells wiederherzustellen
+ Löscht die Gewichte des Basismodells nach der Wiederherstellung nicht (wird für die Wiederverwendung aufbewahrt)
+ Optimiert für model-weights-only Wiederherstellungsszenarien
```
try_checkpointless_load(trainer)
```
Der PEFT-Adapter versucht, die Wiederherstellung ohne Checkpoint zu gewichten, indem er den Status aus Peer-Rängen lädt.
**Parameter:**
+ **trainer** (*pytorch\$1lightning.Trainer*) — Lightning-Trainer-Instanz PyTorch
**Gibt zurück:**
+ **dict** oder **None** — Der Adapter-Checkpoint wurde wiederhergestellt, falls erfolgreich, None, wenn ein Fallback erforderlich ist
**Hinweise:**
+ Stellt nur Adapterparameter, Optimizer-Status und Scheduler wieder her
+ Lädt nach erfolgreicher Wiederherstellung automatisch den Optimizer- und Scheduler-Status
+ Bereinigt die Adapter-Checkpoints nach dem Wiederherstellungsversuch
```
is_adapter_key(key)
```
Prüfen Sie, ob der State-Dict-Schlüssel zu den Adapterparametern gehört.
**Parameter:**
+ **key** (*str* oder *tuple) — Zu* prüfender State-Dict-Schlüssel
**Gibt zurück:**
+ **bool** — True, wenn der Schlüssel ein Adapterparameter ist, False, wenn der Basismodellparameter
**Erkennungslogik:**
+ Prüft, ob der Schlüssel `params_to_save` gesetzt ist
+ Identifiziert Schlüssel, die „.adapter“ enthalten. substring
+ Identifiziert Schlüssel, die mit „.adapters“ enden
+ Überprüft bei Tupelschlüsseln, ob der Parameter Farbverläufe erfordert
```
maybe_offload_checkpoint()
```
Verlagert die Gewichte des Basismodells von der GPU auf den CPU-Speicher.
**Hinweise:**
+ Erweitert die übergeordnete Methode, um die Gewichtsverlagerung des Basismodells zu handhaben
+ Die Gewichte der Adapter sind in der Regel gering und müssen nicht abgeladen werden
+ Setzt ein internes Kennzeichen, um den Offload-Status zu verfolgen
**Hinweise**
+ Speziell für parametereffiziente Feinabstimmungsszenarien (LoRa, Adapter usw.) konzipiert
+ Sorgt automatisch für die Trennung von Basismodell- und Adapterparametern
**Beispiel**
```
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()
```
Factory-Klasse für die Erstellung und Verwaltung von Komponentenzusammensetzungen bei Abbruch, um eine fehlerfreie Fehlertoleranz zu gewährleisten.
Diese Utility-Klasse bietet statische Methoden zum Erstellen, Anpassen und Verwalten von Zusammenstellungen von Abbruchkomponenten, die bei der Fehlerbehandlung beim Checkpointless-Training verwendet werden. HyperPod Sie vereinfacht die Konfiguration von Abbruchsequenzen, mit denen verteilte Trainingskomponenten, Datenlader und Framework-spezifische Ressourcen bei der Wiederherstellung nach einem Ausfall bereinigt werden.
**Parameter**
Keine (alle Methoden sind statisch)
**Statische Methoden**
```
get_default_checkpointless_abort()
```
Ruft die Standard-Abort-Compose-Instanz ab, die alle Standardabbruchkomponenten enthält.
**Gibt zurück:**
+ **Compose** — Standardmäßig erstellte Abbruchinstanz mit allen Abbruchkomponenten
**Standardkomponenten:**
+ **AbortTransformerEngine()** — Bereinigt Ressourcen TransformerEngine
+ **HPCheckpointingAbort ()** — Führt die Bereinigung des Checkpoint-Systems durch
+ **HPAbortTorchDistributed()** — Bricht verteilte Operationen ab PyTorch
+ **HPDataLoaderAbort()** — Stoppt und bereinigt Datenlader
```
create_custom_abort(abort_instances)
```
*Erstellen Sie eine benutzerdefinierte Abbruchmeldung, die nur die angegebenen Abbruchinstanzen enthält.*
**Parameter:**
+ **abort\$1instances** (*Abort) — Variable Anzahl von Abbruchinstanzen*, die in die Erstellung aufgenommen werden sollen
**Gibt zurück:**
+ **Compose** — Neue komponierte Abbruchinstanz, die nur die angegebenen Komponenten enthält
**Löst aus:**
+ **ValueError**— Wenn keine Abbruchinstanzen bereitgestellt werden
```
override_abort(abort_compose, abort_type, new_abort)
```
Ersetzt eine bestimmte Abbruchkomponente in einer Compose-Instanz durch eine neue Komponente.
**Parameter:**
+ **abort\$1compose (*Compose***) — Die ursprüngliche Compose-Instanz, die geändert werden soll
+ **abort\$1type (type**) — Der *Typ* der Abbruchkomponente, die ersetzt werden soll (z. B.) `HPCheckpointingAbort`
+ **new\$1abort (Abort***) — Die neue Abbruchinstanz*, die als Ersatz verwendet werden soll
**Gibt zurück:**
+ **Compose** — Neue Compose-Instanz, bei der die angegebene Komponente ersetzt wurde
**Erhöht:**
+ **ValueError**— Wenn abort\$1compose kein Attribut 'instances' hat
**Beispiel**
```
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(...)
```
**Hinweise**
+ Benutzerdefinierte Konfigurationen ermöglichen eine fein abgestimmte Steuerung des Bereinigungsverhaltens
+ Abbruchvorgänge sind entscheidend für die ordnungsgemäße Bereinigung der Ressourcen bei der Fehlerbehebung
### CheckpointlessFinalizeCleanup
```
class hyperpod_checkpointless_training.inprocess.abort.CheckpointlessFinalizeCleanup()
```
Führt nach der Fehlererkennung eine umfassende Säuberung durch, um die Wiederherstellung während des Prozesses während einer Schulung ohne Kontrollpunkte vorzubereiten.
Dieser Finalize-Handler führt Framework-spezifische Bereinigungsvorgänge wie Megatron/TransformerEngine Abbruch, DDP-Bereinigung, erneutes Laden von Modulen und Speicherbereinigung durch, indem er die Referenzen der Trainingskomponenten zerstört. Er stellt sicher, dass die Trainingsumgebung für eine erfolgreiche Wiederherstellung während des Prozesses ordnungsgemäß zurückgesetzt wird, ohne dass ein vollständiger Prozessabbruch erforderlich ist.
**Parameter**
Keine
**Attribute**
+ **trainer** (*pytorch\$1lightning.Trainer oder *None*) — Verweis auf die Lightning-Trainer-Instanz* PyTorch
**Methoden**
```
__call__(*a, **kw)
```
**Führen Sie umfassende Bereinigungsvorgänge aus, um die Wiederherstellung während des Prozesses vorzubereiten.**
*Parameter:*
+ **a** — Variable Positionsargumente (von der Finalize-Schnittstelle übernommen)
+ **kw** — Variable Schlüsselwortargumente (von der Finalize-Schnittstelle übernommen)
**Säuberungsvorgänge:**
+ **Megatron Framework Cleanup — Aufrufe zur Bereinigung** von Megatron-spezifischen `abort_megatron()` Ressourcen
+ TransformerEngine Cleanup — Aufrufe zur **Bereinigung** von Ressourcen `abort_te()` TransformerEngine
+ **RoPE Cleanup** — Aufrufe `cleanup_rope()` zum Aufräumen von Ressourcen in rotierenden Positionen
+ **DDP Cleanup** — Aufrufe `cleanup_ddp()` zur Bereinigung von Ressourcen DistributedDataParallel
+ **Module Reloading** — Aufrufe `reload_megatron_and_te()` zum Neuladen von Framework-Modulen
+ **Lightning-Modulbereinigung** — Löscht optional das Lightning-Modul, um den GPU-Speicher zu reduzieren
+ **Speicherbereinigung** — Zerstört die Verweise der Trainingskomponenten auf freien Arbeitsspeicher
```
register_attributes(trainer)
```
*Registrieren Sie die Trainer-Instanz für die Verwendung bei Bereinigungsvorgängen.*
**Parameter:**
+ **trainer** (*pytorch\$1lightning.Trainer) — Lightning-Trainer-Instanz* zur Registrierung PyTorch
**Integration mit 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(...)
```
**Hinweise**
+ Bereinigungsvorgänge werden in einer bestimmten Reihenfolge ausgeführt, um Abhängigkeitsprobleme zu vermeiden
+ Die Speicherbereinigung verwendet Garbage-Collection-Introspektion, um Zielobjekte zu finden
+ Alle Bereinigungsvorgänge sind so konzipiert, dass sie idempotent sind und sicher wiederholt werden können
### CheckpointlessMegatronStrategy
```
class hyperpod_checkpointless_training.nemo_plugins.megatron_strategy.CheckpointlessMegatronStrategy(*args, **kwargs)
```
NeMo Megatron-Strategie mit integrierten Funktionen zur Wiederherstellung ohne Checkpoint für fehlertolerantes, verteiltes Training.
Beachten Sie, dass für das Training ohne Checkpoints mindestens 2 erforderlich sind`num_distributed_optimizer_instances`, damit eine Optimizer-Replikation durchgeführt werden kann. Die Strategie kümmert sich auch um die Registrierung wichtiger Attribute und die Initialisierung von Prozessgruppen.
**Parameter**
Erbt alle Parameter von: **MegatronStrategy**
+ NeMo MegatronStrategy Standard-Initialisierungsparameter
+ Konfigurationsoptionen für verteilte Schulungen
+ Einstellungen für Modellparallelität
**Attribute**
+ **base\$1store** *(torch.distributed). TCPStore*oder *None*) — Verteilter Speicher für die Koordination von Prozessgruppen
**Methoden**
```
setup(trainer)
```
Initialisieren Sie die Strategie und registrieren Sie die Fehlertoleranzkomponenten beim Trainer.
**Parameter:**
+ **trainer** (*pytorch\$1lightning.Trainer) — Lightning-Trainer-Instanz* PyTorch
**Einrichtungsvorgänge:**
+ **Übergeordnetes Setup** — Ruft das übergeordnete MegatronStrategy Setup auf
+ **Registrierung von Fehlerinjektionen** — Registriert HPFault InjectionCallback Hooks, falls vorhanden
+ **Registrierung abschließen — Registriert** den Trainer bei den Finalize Cleanup-Handlern
+ **Registrierung abbrechen — Registriert den Trainer bei Abort-Handlern**, die dies unterstützen
```
setup_distributed()
```
Initialisieren Sie die Prozessgruppe entweder mit Präfix oder TCPStore mit einer Verbindung ohne Wurzel.
```
load_model_state_dict(checkpoint, strict=True)
```
Lädt das Status-Diktat des Modells mit Checkpointless-Recovery-Kompatibilität.
**Parameter:**
+ **checkpoint** (*Mapping [str, Any]) — Checkpoint-Wörterbuch,* das den Modellstatus enthält
+ **strict** (*bool*, *optional*) — Ob der Abgleich von State-Dict-Schlüsseln strikt erzwungen werden soll. Standard: `True`
```
get_wrapper()
```
Holen Sie sich die HPCall Wrapper-Instanz für die Koordination der Fehlertoleranz.
**Gibt zurück:**
+ **HPCallWrapper** — Die Wrapper-Instanz, die aus Gründen der Fehlertoleranz an den Trainer angeschlossen ist
```
is_peft()
```
Prüfen Sie, ob PEFT (Parameter-Efficient Fine-Tuning) in der Trainingskonfiguration aktiviert ist, indem Sie nach PEFT-Callbacks suchen
**Gibt zurück:**
+ **bool** — Wahr, wenn ein PEFT-Callback vorhanden ist, andernfalls False
```
teardown()
```
Überschreiben Sie den systemeigenen PyTorch Lightning-Teardown, um die Bereinigung an Abbruchprozeduren zu delegieren.
**Beispiel**
```
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-Rückruf, der das NeMo Training in das Fehlertoleranzsystem von Checkpointless-Trainings integriert.
Dieser Rückruf verwaltet die Schrittverfolgung, das Speichern von Checkpoints und die Koordination der Parameteraktualisierung für Funktionen zur Wiederherstellung während des Prozesses. Er dient als primärer Integrationspunkt zwischen PyTorch Lightning-Trainingsschleifen und Trainingsmechanismen HyperPod ohne Checkpoints und koordiniert die Fehlertoleranzoperationen während des gesamten Trainingszyklus.
**Parameter**
+ **enable\$1inprocess** *(*bool*, optional) — Aktiviert Funktionen zur prozessinternen Wiederherstellung.* Standard: `False`
+ **enable\$1checkpointless** *(*bool*, optional) — Aktiviert die Wiederherstellung ohne Prüfpunkt (erforderlich).* `enable_inprocess=True` Standard: `False`
+ **enable\$1checksum (bool, optional) — Aktiviert die Überprüfung der Modellstatus-Prüfsumme** *(erforderlich**).* `enable_checkpointless=True` Standard: `False`
+ **clean\$1tensor\$1hook** (*bool*, *optional*) — Löscht während der Bereinigung Tensor-Hooks von allen GPU-Tensoren (teurer Vorgang). Standard: `False`
+ **clean\$1lightning\$1module (*bool*, optional) — Aktiviert die Bereinigung des Lightning-Moduls***, um nach jedem Neustart GPU-Speicher freizugeben.* Standard: `False`
**Attribute**
+ ***tried\$1adapter\$1checkpointless (bool) — Markierung, um nachzuverfolgen, ob versucht wurde, den Adapter ohne Checkpoint wiederherzustellen***
**Methoden**
```
get_wrapper_from_trainer(trainer)
```
Holen Sie sich die Wrapper-Instanz vom Trainer für die Koordination der Fehlertoleranz. HPCall
**Parameter:**
+ **trainer** (*pytorch\$1lightning.Trainer) — Lightning-Trainer-Instanz* PyTorch
**Gibt zurück:**
+ **HPCallWrapper** — Die Wrapper-Instanz für Fehlertoleranzoperationen
```
on_train_batch_start(trainer, pl_module, batch, batch_idx, *args, **kwargs)
```
Wird zu Beginn jedes Trainingsstapels aufgerufen, um die Schrittverfolgung und Wiederherstellung zu verwalten.
**Parameter:**
+ **trainer** (*pytorch\$1lightning.Trainer) — Lightning-Trainer-Instanz* PyTorch
+ **pl\$1module** (*pytorch\$1lightning). LightningModule*) — Lightning-Modul wird trainiert
+ **batch** — Aktuelle Trainingsstapeldaten
+ **batch\$1idx** (*int*) — Index des aktuellen Batches
+ args — **Zusätzliche Positionsargumente**
+ **kwargs** — Zusätzliche Schlüsselwortargumente
```
on_train_batch_end(trainer, pl_module, outputs, batch, batch_idx)
```
*Geben Sie die Sperre für die Aktualisierung der Parameter am Ende jedes Trainingsstapels auf.*
**Parameter:**
+ **trainer** (*pytorch\$1lightning.Trainer) — Lightning-Trainer-Instanz* PyTorch
+ **pl\$1module** (*pytorch\$1lightning). LightningModule*) — Lightning-Modul wird trainiert
+ **outputs** (*STEP\$1OUTPUT*) — Ausgaben von Trainingsschritten
+ **batch** (*Any*) — Aktuelle Trainingsstapeldaten
+ **batch\$1idx** (*int*) — Index des aktuellen Batches
**Hinweise:**
+ Der Zeitpunkt der Freigabe von Sperren stellt sicher, dass die Wiederherstellung ohne Checkpoint fortgesetzt werden kann, nachdem die Parameteraktualisierungen abgeschlossen sind
+ Wird nur ausgeführt, wenn sowohl als auch wahr sind `enable_inprocess` `enable_checkpointless`
```
get_peft_callback(trainer)
```
*Ruft den PEFT-Callback aus der Rückrufliste des Trainers ab.*
**Parameter:**
+ **trainer** (*pyTorch\$1Lightning.Trainer*) — Lightning-Trainer-Instanz PyTorch
**Gibt zurück:**
+ **PEFT** oder **None** — PEFT-Callback-Instanz, falls gefunden, sonst None
```
_try_adapter_checkpointless_restore(trainer, params_to_save)
```
*Versuchen Sie, die PEFT-Adapterparameter ohne Checkpoint wiederherzustellen.*
**Parameter:**
+ **trainer** (*pytorch\$1lightning.Trainer*) — Lightning-Trainer-Instanz PyTorch
+ **params\$1to\$1save** (*set) — Satz* von Parameternamen, die als Adapterparameter gespeichert werden sollen
**Hinweise:**
+ Wird nur einmal pro Trainingseinheit ausgeführt (wird durch das Flag gesteuert) `tried_adapter_checkpointless`
+ Konfiguriert den Checkpoint Manager mit Adapterparameterinformationen
**Beispiel**
```
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)
```
**Arbeitsspeicher-Verwaltung**
+ **clean\$1tensor\$1hook: Entfernt Tensor-Hooks** während der Bereinigung (teuer, aber gründlich)
+ **clean\$1lightning\$1module**: Gibt den GPU-Speicher des Lightning-Moduls bei Neustarts frei
+ Beide Optionen tragen dazu bei, den Speicherbedarf bei der Fehlerbehebung zu reduzieren
+ Koordiniert mit ParameterUpdateLock für die Thread-sichere Nachverfolgung von Parameteraktualisierungen
### CheckpointlessCompatibleConnector
```
class hyperpod_checkpointless_training.nemo_plugins.checkpoint_connector.CheckpointlessCompatibleConnector()
```
PyTorch Lightning-Checkpoint-Konnektor, der die Wiederherstellung ohne Checkpoint in das herkömmliche Laden von Checkpoints auf Festplatte integriert.
Dieser Konnektor erweitert den von PyTorch `_CheckpointConnector` Lightning und bietet so eine nahtlose Integration zwischen der Wiederherstellung ohne Checkpoint und der standardmäßigen Checkpoint-Wiederherstellung. Es versucht zunächst eine Wiederherstellung ohne Checkpoint und greift dann auf festplattenbasiertes Laden von Checkpoints zurück, falls eine Wiederherstellung ohne Checkpoint nicht möglich ist oder fehlschlägt.
**Parameter**
**Erbt** alle Parameter von \$1 CheckpointConnector
**Methoden**
```
resume_start(checkpoint_path=None)
```
Versuchen Sie, den Checkpoint vorab mit einer Wiederherstellungspriorität ohne Checkpoint zu laden.
**Parameter:**
+ **checkpoint\$1path** (*str* oder *None*, *optional*) — Pfad zum Festplatten-Checkpoint für Fallback. Standard: `None`
```
resume_end()
```
Schließen Sie den Checkpoint-Ladevorgang ab und führen Sie Operationen nach dem Laden durch.
**Hinweise**
+ Erweitert die interne `_CheckpointConnector` Klasse von PyTorch Lightning um Unterstützung für die Wiederherstellung ohne Checkpoint
+ Behält die volle Kompatibilität mit standardmäßigen PyTorch Lightning-Checkpoint-Workflows bei
### CheckpointlessAutoResume
```
class hyperpod_checkpointless_training.nemo_plugins.resume.CheckpointlessAutoResume()
```
Wird um NeMo eine AutoResume verzögerte Einrichtung erweitert, sodass eine Überprüfung der Wiederherstellung ohne Checkpoint vor der Auflösung des Checkpoint-Pfads möglich ist.
Diese Klasse implementiert eine zweiphasige Initialisierungsstrategie, die eine Überprüfung der Wiederherstellung ohne Checkpoint ermöglicht, bevor auf das herkömmliche Laden von Checkpoints auf der Festplatte zurückgegriffen wird. Sie verzögert die AutoResume Einrichtung bedingt, um eine vorzeitige Auflösung des Checkpoint-Pfads zu verhindern, sodass zunächst geprüft werden kann, ob eine Wiederherstellung ohne Checkpoint möglich ist CheckpointManager . peer-to-peer
**Parameter**
Erbt alle Parameter von **AutoResume**
**Methoden**
```
setup(trainer, model=None, force_setup=False)
```
Verzögern Sie die AutoResume Einrichtung bedingt, um eine Überprüfung der Wiederherstellung ohne Checkpoint zu ermöglichen.
**Parameter:**
+ **trainer** *(*pytorch\$1lightning.trainer oder lightning.Fabric.Fabric) — Lightning-Trainer* oder Fabric-Instanz* PyTorch
+ **model** *(optional) —* Modellinstanz für die Einrichtung. Standard: `None`
+ **force\$1setup** (*bool*, *optional*) — Bei True wird die Verzögerung umgangen und das Setup sofort ausgeführt AutoResume . Standard: `False`
**Beispiel**
```
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()
)
```
**Hinweise**
+ Erweitert NeMo die AutoResume Klasse um einen Verzögerungsmechanismus, der eine Wiederherstellung ohne Checkpoint ermöglicht
+ Funktioniert in Verbindung mit `CheckpointlessCompatibleConnector` für einen vollständigen Wiederherstellungs-Workflow
# Besondere Überlegungen
Wir erheben regelmäßig aggregierte und anonymisierte Betriebskennzahlen, um die Verfügbarkeit wesentlicher Dienste sicherzustellen. Die Erstellung dieser Metriken erfolgt vollautomatisch und erfordert keine Überprüfung des zugrundeliegenden Trainingsaufwands des Modells durch einen Menschen. Diese Kennzahlen beziehen sich auf Arbeitsabläufe, Ressourcenmanagement und grundlegende Servicefunktionen.
HyperPod verwaltetes mehrstufiges Checkpoint-Training und elastisches Training: Beachten Sie, dass Training HyperPod ohne Checkpoint derzeit nicht mit HyperPod verwaltetem mehrstufigem Checkpoint-Training und elastischem Training kompatibel ist.
Für die Modelle GPT OSS 120B und Lama werden Rezepte für das Checkpointless-Training bereitgestellt, um den Einstieg zu vereinfachen. Diese Rezepte wurden auf ml.p5-Instanzen verifiziert. Die Verwendung anderer Instance-Typen kann zusätzliche Änderungen an den zugrunde liegenden Rezepten erfordern. Diese Rezepte können auch an vollständige Feinabstimmungsworkflows angepasst werden. Für benutzerdefinierte Modelle empfehlen wir, sich die Beispiele für die [ersten Schritte anzusehen](https://docs.aws.amazon.com/sagemaker-eks-checkpointless-recipes-custom).
# Anhang
**Überwachen Sie die Trainingsergebnisse anhand von HyperPod Rezepten**
SageMaker HyperPod Rezepte bieten eine Tensorboard-Integration zur Analyse des Trainingsverhaltens. Diese Rezepte beinhalten auch VizTracer, ein Tool mit geringem Overhead zum Verfolgen und Visualisieren der Python-Codeausführung. Weitere Informationen finden Sie unter [ VizTracer](https://github.com/gaogaotiantian/viztracer).
Die Tensorboard-Protokolle werden generiert und im gespeichert. `log_dir` Gehen Sie wie folgt vor, um auf diese Protokolle zuzugreifen und sie lokal zu analysieren:
1. Laden Sie den Tensorboard-Experimentordner aus Ihrer Trainingsumgebung auf Ihren lokalen Computer herunter.
1. Öffnen Sie ein Terminal oder einen Prompt auf Ihrem lokalen Rechner.
1. Navigieren Sie zu dem Verzeichnis, das den heruntergeladenen Experimentordner enthält.
1. Starten Sie Tensorboard, indem Sie den folgenden Befehl ausführen:
```
tensorboard --port= --bind_all --logdir experiment.
```
1. Öffnen Sie Ihren Webbrowser und besuchen Sie. `http://localhost:8008`
Sie können jetzt den Status und die Visualisierungen Ihrer Trainingsjobs in der Tensorboard-Oberfläche sehen. Wenn Sie den Status und die Visualisierungen sehen, können Sie den Trainingsprozess überwachen und analysieren. Durch die Überwachung und Analyse des Trainingsprozesses können Sie Einblicke in das Verhalten und die Leistung Ihrer Modelle gewinnen. Weitere Informationen darüber, wie Sie das Training mit Tensorboard überwachen und analysieren, finden Sie im [NVIDIA NeMo Framework-Benutzerhandbuch](https://docs.nvidia.com/nemo-framework/user-guide/latest/nemotoolkit/core/exp_manager.html#experiment-manager).
**VizTracer**
Zur Aktivierung können Sie Ihr Rezept ändern VizTracer, indem Sie die Umgebungsvariable `ENABLE_VIZTRACER` auf setzen. `1` Nach Abschluss der Schulung befindet sich Ihr VizTracer Profil im Experimentordner`log_dir/viztracer_xxx.json`. Um Ihr Profil zu analysieren, können Sie es herunterladen und mit dem folgenden **vizviewer** Tool öffnen:
```
vizviewer --port viztracer_xxx.json
```
Dieser Befehl startet den VizViewer auf Port 9001. Sie können Ihre einsehen, VizTracer indem Sie in Ihrem Browser auf http://localhost: gehen. Nach dem Öffnen VizTracer beginnen Sie mit der Analyse des Trainings. Weitere Informationen zur Verwendung VizTracer finden Sie in der [ VizTracer Dokumentation](https://viztracer.readthedocs.io/en/latest/installation.html).
# Versionshinweise
In den folgenden Versionshinweisen finden Sie die neuesten Updates für das SageMaker HyperPod Checkpointless-Training.
**Das SageMaker HyperPod Checkpointless-Training v1.0.0**
Datum: 03. Dezember 2025
**SageMaker HyperPod Funktionen für das Training ohne Checkpoint**
+ **Verbesserungen der kollektiven Kommunikationsinitialisierung**: Bietet neuartige Initialisierungsmethoden, Rootless und für NCCL und Gloo. TCPStoreless
+ **Memory-Mapped (MMAP)** Dataloader: Speichert vorab abgerufene Batches im Cache (persistiert), sodass sie auch dann verfügbar sind, wenn ein Fehler einen Neustart des Trainingsjobs verursacht.
+ **Checkpointless**: Ermöglicht eine schnellere Wiederherstellung nach Cluster-Trainingsfehlern in großen, verteilten Trainingsumgebungen durch Optimierungen auf Framework-Ebene
+ **Basiert auf Nvidia Nemo und PyTorch Lightning**: Nutzt diese leistungsstarken Frameworks für effizientes und flexibles Modelltraining
+ [Nvidia NeMo](https://github.com/NVIDIA-NeMo/NeMo)
+ [PyTorch Blitze](https://lightning.ai/docs/pytorch/stable/)
**SageMaker HyperPod Docker-Container für zielloses Training**
[Checkpointless Training on HyperPod basiert auf dem NVIDIA-Framework. NeMo ](https://docs.nvidia.com/nemo-framework/user-guide/latest/overview.html) HyperPod Checkpointless Training zielt darauf ab, Cluster-Trainingsfehler in großen verteilten Trainingsumgebungen schneller zu beheben, indem Optimierungen auf Framework-Ebene vorgenommen werden, die auf einem Basiscontainer bereitgestellt werden, der das Basis-Image mit NCCL und Optimierungen enthält. PyTorch
**Verfügbarkeit**
Derzeit sind Bilder nur verfügbar 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
```
aber nicht verfügbar in den folgenden 3 Opt-in-Regionen:
```
ap-southeast-3
ap-southeast-4
eu-south-2
```
**Details zum Container**
Docker-Container für Checkpointless-Training für PyTorch v2.6.0 mit 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
```
**Vorinstallierte Pakete**
```
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
```
# Verwenden von GPU-Partitionen in Amazon SageMaker HyperPod
Clusteradministratoren können wählen, wie sie die GPU-Auslastung in ihrer gesamten Organisation maximieren möchten. Sie können die GPU-Partitionierung mit der NVIDIA Multi-Instance-GPU (MIG) -Technologie aktivieren, um GPU-Ressourcen zur besseren Ressourcennutzung in kleinere, isolierte Instanzen zu partitionieren. Diese Funktion bietet die Möglichkeit, mehrere kleinere Aufgaben gleichzeitig auf einer einzigen GPU auszuführen, anstatt die gesamte Hardware einer einzigen, oft nicht ausgelasteten Aufgabe zu widmen. Dadurch wird die Verschwendung von Rechenleistung und Speicherplatz vermieden.
Die GPU-Partitionierung mit MIG-Technologie unterstützt GPUs und ermöglicht Ihnen die Partitionierung einer einzelnen unterstützten GPU in bis zu sieben separate GPU-Partitionen. Jede GPU-Partition verfügt über dedizierte Speicher-, Cache- und Rechenressourcen, wodurch eine vorhersehbare Isolierung gewährleistet ist.
## Vorteile
+ **Verbesserte GPU-Auslastung** — Maximieren Sie die Recheneffizienz durch Partitionierung auf der GPUs Grundlage der Rechen- und Speicheranforderungen
+ **Aufgabenisolierung** — Jede GPU-Partition arbeitet unabhängig mit dedizierten Speicher-, Cache- und Rechenressourcen
+ **Aufgabenflexibilität** — Support eine Mischung von Aufgaben auf einer einzigen physischen GPU, die alle parallel ausgeführt werden
+ **Flexibles Einrichtungsmanagement** — Support sowohl Do-it-yourself (DIY-) Kubernetes-Konfigurationen mit dem Kubernetes-Befehlszeilenclient als auch eine verwaltete Lösung mit benutzerdefinierten Labels`kubectl`, um Ihre Labels für GPU-Partitionen einfach zu konfigurieren und anzuwenden
## Unterstützte Instance-Typen
Die GPU-Partitionierung mit MIG-Technologie wird auf den folgenden Instance-Typen unterstützt: HyperPod
**A100 GPU-Instanzen** [— Instanztypen/p4/ https://aws.amazon.com/ec2/](https://aws.amazon.com/ec2/instance-types/p4/)
+ **ml.p4d.24xlarge — 8 NVIDIA A100 (80 GB pro GPU**) GPUs HBM2e
+ **ml.p4de.24xlarge** - 8 NVIDIA A100 (80 GB pro GPU) GPUs HBM2e
**[https://aws.amazon.com/ec2/H100-GPU-Instanzen — Instanztypen/p5/](https://aws.amazon.com/ec2/instance-types/p5/)**
+ **ml.p5.48xlarge — 8 NVIDIA H100 (80 GB pro GPU**) GPUs HBM3
**[https://aws.amazon.com/ec2/H200-GPU-Instanzen — Instanztypen/p5/](https://aws.amazon.com/ec2/instance-types/p5/)**
+ **ml.p5e.48xlarge — 8 NVIDIA H200 (141 GB pro GPU**) GPUs HBM3e
+ **ml.p5en.48xlarge — 8 NVIDIA H200 (141 GB pro GPU)** GPUs HBM3e
**[https://aws.amazon.com/ec2/B200](https://aws.amazon.com/ec2/instance-types/p6/) GPU-Instanzen — Instanztypen/p6/**
+ ml.p6b.48xlarge — 8 NVIDIA **B200** GPUs
## GPU-Partitionen
NVIDIA MIG-Profile definieren, wie partitioniert GPUs werden. Jedes Profil spezifiziert die Rechen- und Speicherzuweisung pro MIG-Instanz. Im Folgenden sind die MIG-Profile aufgeführt, die jedem GPU-Typ zugeordnet sind:
**A100-GPU (ml.p4d.24xlarge)**
| Profil | Speicher (GB) | Instanzen pro GPU | Insgesamt pro 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 |
**H100-GPU (ml.p 5,48 x groß)**
| Profil | Speicher (GB) | Instanzen pro GPU | Insgesamt pro 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 |
**H200-GPU (ml.p5e.48xlarge und ml.p5en.48xlarge)**
| Profil | Speicher (GB) | Instanzen pro GPU | Insgesamt pro 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**
+ [Vorteile](#sagemaker-hyperpod-eks-gpu-partitioning-benefits)
+ [Unterstützte Instance-Typen](#sagemaker-hyperpod-eks-gpu-partitioning-instance-types)
+ [GPU-Partitionen](#sagemaker-hyperpod-eks-gpu-partitioning-profiles)
+ [GPU-Partitionen bei Amazon einrichten SageMaker HyperPod](sagemaker-hyperpod-eks-gpu-partitioning-setup.md)
+ [Lebenszyklus und Labels von Knoten](sagemaker-hyperpod-eks-gpu-partitioning-labels.md)
+ [Einreichung von Aufgaben mit MIG](sagemaker-hyperpod-eks-gpu-partitioning-task-submission.md)
# GPU-Partitionen bei Amazon einrichten SageMaker HyperPod
**Topics**
+ [Voraussetzungen](#sagemaker-hyperpod-eks-gpu-partitioning-setup-prerequisites)
+ [Einen Cluster mit MIG-Konfiguration erstellen](#sagemaker-hyperpod-eks-gpu-partitioning-setup-create-cluster)
+ [Hinzufügen eines GPU-Operators zu einem vorhandenen Cluster](#sagemaker-hyperpod-eks-gpu-partitioning-setup-add-operator)
+ [Die MIG-Konfiguration wird aktualisiert](#sagemaker-hyperpod-eks-gpu-partitioning-setup-update)
+ [Die MIG-Konfiguration wird überprüft](#sagemaker-hyperpod-eks-gpu-partitioning-setup-verify)
+ [Allgemeine Befehle zum Debuggen der MIG-Konfiguration](#sagemaker-hyperpod-eks-gpu-partitioning-setup-debug-commands)
+ [Verwenden der SageMaker AI-Konsole](#sagemaker-hyperpod-eks-gpu-partitioning-setup-console)
## Voraussetzungen
+ HyperPod Amazon EKS-Cluster mit unterstützten GPU-Instances
+ NVIDIA GPU Operator ist installiert
+ Entsprechende IAM-Berechtigungen für die Clusterverwaltung
## Einen Cluster mit MIG-Konfiguration erstellen
### Verwenden 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
```
### Benutzen 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"
}
```
## Hinzufügen eines GPU-Operators zu einem vorhandenen Cluster
### Installieren Sie den GPU Operator
`{$AWS_REGION}`Ersetzen Sie es durch Ihre Clusterregion (z. B. 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
```
### Überprüfen Sie die Installation (warten Sie 2-3 Minuten)
Überprüfen Sie, ob alle GPU-Operator-Pods laufen:
```
kubectl get pods -n kube-system | grep -E "(gpu-operator|nvidia-)"
```
**Erwartete Pods:**
+ gpu-operator-\$1 — 1 Instanz (Cluster-Controller)
+ nvidia-device-plugin-daemonset-\$1 - 1 pro GPU-Knoten (alle GPU-Instanzen)
+ nvidia-mig-manager-\$1 - 1 pro MIG-fähigem Knoten (A100/H100)
### Entfernen Sie das alte Geräte-Plug-In
Deaktivieren Sie das vorhandene nvidia-device-plugin:
```
helm upgrade dependencies helm_chart/HyperPodHelmChart \
--set nvidia-device-plugin.devicePlugin.enabled=false \
-n kube-system
```
### Überprüfen Sie die GPU-Ressourcen
Bestätigen Sie, dass die Knoten GPU-Kapazität anzeigen. Es sollte Folgendes anzeigen: nvidia.com/gpu: 8 (oder deine tatsächliche GPU-Anzahl).
```
kubectl describe nodes | grep "nvidia.com/gpu"
```
## Die MIG-Konfiguration wird aktualisiert
**Knoten vor MIG-Updates vorbereiten**
Bevor Sie die MIG-Konfigurationen in Ihrer Instanzgruppe aktualisieren, müssen Sie die Knoten vorbereiten, um eine Unterbrechung der Arbeitslast zu vermeiden. Gehen Sie wie folgt vor, um Workloads sicher von den Knoten abzuleiten, die neu konfiguriert werden.
### Schritt 1: Identifizieren Sie die Knoten in der Instanzgruppe
Identifizieren Sie zunächst alle Knoten, die zu der Instanzgruppe gehören, die Sie aktualisieren möchten:
```
# 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
```
Dieser Befehl gibt eine Liste aller Knoten in der angegebenen Instanzgruppe zurück. Notieren Sie sich jeden Knotennamen für die folgenden Schritte.
### Schritt 2: Sperren und Entleeren Sie jeden Knoten
Führen Sie für jeden in Schritt 1 identifizierten Knoten die folgenden Aktionen aus:
#### Sperren Sie den Knoten ab
Durch das Absperren wird verhindert, dass neue Pods auf dem Knoten geplant werden:
```
# Cordon a single node
kubectl cordon NODE_NAME
# Example:
kubectl cordon hyperpod-i-014a41a7001adca60
```
#### Workload-Pods vom Knoten entleeren
Entleeren Sie den Knoten, um alle Workload-Pods zu entfernen und gleichzeitig die System-Pods beizubehalten:
```
# 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
```
**Erläuterung der Befehlsoptionen:**
+ `--ignore-daemonsets`- Ermöglicht es, den Entleerungsvorgang auch dann fortzusetzen, wenn DaemonSet Pods vorhanden sind
+ `--delete-emptydir-data`— Löscht Pods mithilfe von EmptyDir-Volumes (erforderlich, damit das Entleeren erfolgreich ist)
+ `--force`- Erzwingt das Löschen von Pods, die nicht von einem Controller verwaltet werden (mit Vorsicht verwenden)
+ `--grace-period=300`- Gibt Pods 5 Minuten Zeit, um sie ordnungsgemäß zu beenden
**Wichtig**
Der Entleerungsvorgang kann je nach Anzahl der Pods und deren Übergangsfristen mehrere Minuten dauern
System-Pods in den folgenden Namespaces werden weiterhin ausgeführt:`kube-system`,`cert-manager`,`kubeflow`,`hyperpod-inference-system`,`kube-public`,,`mpi-operator`,`gpu-operator`, `aws-hyperpod``jupyter-k8s-system`, und `hyperpod-observability` `kueue-system` `keda`
DaemonSet Pods bleiben auf dem Knoten (sie werden vom Design her ignoriert)
### Schritt 3: Stellen Sie sicher, dass keine Workload-Pods ausgeführt werden
Stellen Sie nach dem Entleeren sicher, dass keine Workload-Pods auf den Knoten verbleiben (außer System-Namespaces):
```
# 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"
```
**Erwartete Ausgabe:** Wenn der Knoten ordnungsgemäß entleert wurde, sollte dieser Befehl keine Ergebnisse zurückgeben (oder nur die Kopfzeile anzeigen). Falls noch Pods laufen, untersuchen Sie, warum sie nicht entfernt wurden, und löschen Sie sie gegebenenfalls manuell.
### Schritt 4: Überprüfen Sie den Bereitschaftsstatus des Knotens
Bevor Sie mit dem MIG-Update fortfahren, stellen Sie sicher, dass alle Knoten gesperrt sind:
```
# Check node status - should show "SchedulingDisabled"
kubectl get nodes -l sagemaker.amazonaws.com/instance-group-name=INSTANCE_GROUP_NAME
```
Die Knoten sollten `SchedulingDisabled` in der STATUS-Spalte angezeigt werden, was bedeutet, dass sie gesperrt und bereit für das MIG-Update sind.
### MIG-Profil auf vorhandenem Cluster aktualisieren
Sie können die MIG-Profile auf vorhandenen Clustern ändern:
```
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"
}'
```
**Anmerkung**
Wenn Jobs bereits auf einem Knoten ausgeführt werden, schlägt die MIG-Partitionierung fehl. Der Benutzer erhält eine Fehlermeldung mit der Aufforderung, die Knoten zu entleeren, bevor er erneut versucht, die MIG-Partitionierung durchzuführen.
## Die MIG-Konfiguration wird überprüft
Überprüfen Sie nach der Erstellung oder Aktualisierung des Clusters die MIG-Konfiguration:
```
# 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:"
```
## Allgemeine Befehle zum Debuggen der MIG-Konfiguration
Verwenden Sie die folgenden Befehle, um Fehler bei der MIG-Konfiguration in Ihrem Cluster zu beheben und zu überprüfen:
```
# 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
```
**Anmerkung**
Ersetzen Sie `nvidia-driver-XXXXX` und `nvidia-device-plugin-XXXXX` durch die tatsächlichen Pod-Namen aus Ihrem Cluster und `NODE_NAME` durch den Namen Ihres Knotens.
## Verwenden der SageMaker AI-Konsole
### Einen neuen Cluster mit MIG erstellen
1. Navigieren Sie zu **Amazon SageMaker AI** > **HyperPod Clusters** **> Cluster Management** > ** HyperPod Cluster erstellen**
1. Wählen Sie **Orchestriert von EKS**
1. Wählen Sie **Benutzerdefiniertes Setup** und stellen Sie sicher, dass der **GPU-Operator** standardmäßig aktiviert ist
1. Klicken Sie im Abschnitt **Instanzgruppen** auf **Gruppe hinzufügen**
1. Konfigurieren Sie die Instanzgruppe und navigieren Sie zu **Erweiterte Konfiguration**, um die Option **GPU-Partition verwenden** zu aktivieren, und wählen Sie die gewünschte **MIG-Konfiguration aus der Dropdownliste** aus
1. Klicken Sie auf **Instanzgruppe hinzufügen** und schließen Sie die verbleibende Clusterkonfiguration ab
1. Klicken Sie auf **Senden**, um den Cluster zu erstellen
### Die MIG-Konfiguration auf einem vorhandenen Cluster wird aktualisiert
1. Navigieren Sie zu **Amazon SageMaker AI** > **HyperPod Clusters** **> Cluster Management**
1. Wählen Sie Ihren vorhandenen Cluster aus und klicken Sie in der Instance-Gruppe, die Sie ändern möchten, auf **Bearbeiten**
1. Aktivieren **Sie in der **erweiterten Konfiguration** die Option GPU-Partition verwenden**, falls nicht bereits aktiviert, und wählen Sie eine andere **MIG-Konfiguration aus der Dropdownliste** aus
1. **Klicken Sie auf Änderungen speichern**
# Lebenszyklus und Labels von Knoten
Amazon SageMaker HyperPod führt während der Erstellung und Aktualisierung von HyperPod Clustern vor Beginn der GPU-Partitionierung eingehende Integritätsprüfungen für Cluster-Instances durch. HyperPod Der Health Monitoring Agent überwacht kontinuierlich den Integritätsstatus von GPU-partitionierten Instances.
## Status der MIG-Konfiguration
Knoten mit GPU-Partitionskonfiguration durchlaufen mehrere Zustände:
+ **Ausstehend** — Der Knoten wird mit einem MIG-Profil konfiguriert
+ **Konfiguration** — Der GPU-Operator wendet die MIG-Partitionierung an
+ **Erfolgreich** — Die GPU-Partitionierung wurde erfolgreich abgeschlossen
+ **Fehlgeschlagen** — Bei der GPU-Partitionierung ist ein Fehler aufgetreten
## Überwachen von Knotenzuständen
```
# 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:"
```
## Benutzerdefinierte Labels und Taints
Sie können die MIG-Konfiguration mit benutzerdefinierten Labels und Taints verwalten, um Ihre GPU-Partitionen zu kennzeichnen und sie instanzübergreifend anzuwenden:
```
{
"KubernetesConfig": {
"Labels": {
"nvidia.com/mig.config": "all-2g.10gb",
"task-type": "inference",
"environment": "production"
},
"Taints": [
{
"Key": "gpu-task",
"Value": "mig-enabled",
"Effect": "NoSchedule"
}
]
}
}
```
# Einreichung von Aufgaben mit MIG
**Topics**
+ [Verwenden von Kubernetes YAML](#sagemaker-hyperpod-eks-gpu-partitioning-task-submission-kubectl)
+ [HyperPod CLI verwenden](#sagemaker-hyperpod-eks-gpu-partitioning-task-submission-cli)
+ [Modellbereitstellung mit MIG](#sagemaker-hyperpod-eks-gpu-partitioning-task-submission-deployment)
+ [HyperPod CLI verwenden](#sagemaker-hyperpod-eks-gpu-partitioning-task-submission-hyperpod-cli)
## Verwenden von 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
```
## HyperPod CLI verwenden
Verwenden Sie die HyperPod CLI, um JumpStart Modelle mit MIG-Unterstützung bereitzustellen. Das folgende Beispiel zeigt die neuen CLI-Parameter für die GPU-Partitionierung:
```
# 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
```
## Modellbereitstellung mit MIG
HyperPod Inference ermöglicht die Bereitstellung der Modelle auf MIG-Profilen über Studio Classic `kubectl` und HyperPod CLI. Um JumpStart Modelle auf bereitzustellen`kubectl`, CRDs müssen Felder aufgerufen werden, `spec.server.acceleratorPartitionType` um das Modell für das gewünschte MIG-Profil bereitzustellen. Wir führen Validierungen durch, um sicherzustellen, dass Modelle auf dem in der CRD ausgewählten MIG-Profil bereitgestellt werden können. Falls Sie die MIG-Validierungsprüfungen deaktivieren möchten, verwenden Sie `spec.server.validations.acceleratorPartitionValidation` `False`
### JumpStart Modelle
```
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
```
### Modell von Amazon S3 bereitstellen mit InferenceEndpointConfig
InferenceEndpointConfig ermöglicht es Ihnen, ein benutzerdefiniertes Modell von Amazon S3 aus bereitzustellen. Um ein Modell auf MIG bereitzustellen, `spec.worker.resources` erwähnen Sie das MIG-Profil in `requests` und`limits`. Im Folgenden wird eine einfache Bereitstellung beschrieben:
```
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
```
### Stellen Sie das Modell von FSx for Lustre bereit mit InferenceEndpointConfig
InferenceEndpointConfig ermöglicht es Ihnen, ein benutzerdefiniertes Modell FSx für Lustre bereitzustellen. Um ein Modell auf MIG bereitzustellen, `spec.worker.resources` erwähnen Sie das MIG-Profil in `requests` und`limits`. Im Folgenden wird eine einfache Bereitstellung beschrieben:
```
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
```
### Verwenden der klassischen Benutzeroberfläche von Studio
#### Bereitstellen von JumpStart Modellen mit MIG
1. Öffnen Sie **Studio Classic** und navigieren Sie zu **JumpStart**
1. Suchen oder suchen Sie nach Ihrem gewünschten Modell (z. B. "DeepSeek„, „Lama“ usw.)
1. **Klicken Sie auf die Modellkarte und wählen Sie Bereitstellen**
1. In der Bereitstellungskonfiguration:
+ Wählen Sie **HyperPod**als Bereitstellungsziel
+ Wählen Sie Ihren MIG-fähigen Cluster aus der Dropdownliste aus
+ Unter **Instance-Konfiguration**:
+ Wählen Sie den Instanztyp aus (z. B.) `ml.p4d.24xlarge`
+ Wählen Sie den **GPU-Partitionstyp** aus den verfügbaren Optionen
+ Konfigurieren Sie die Einstellungen für die **Anzahl der Instanzen** und die **automatische Skalierung**
1. **Überprüfen Sie und klicken Sie auf Bereitstellen**
1. Überwachen Sie den Bereitstellungsfortschritt im Bereich **Endpoints**
#### Optionen für die Modellkonfiguration
**Endpunkt-Einstellungen:**
+ **Endpunktname** — Eindeutiger Bezeichner für Ihre Bereitstellung
+ **Variantenname** — Konfigurationsvariante (Standard: AllTraffic)
+ **Instanztyp** — Muss die GPU-Partition (P-Serie) unterstützen
+ **MIG-Profil** — GPU-Partition
+ **Anfängliche Anzahl der Instanzen** — Anzahl der bereitzustellenden Instanzen
+ **Automatische Skalierung** — Aktiviert die dynamische Skalierung auf der Grundlage des Datenverkehrs
**Erweiterte Konfiguration:**
+ **Speicherort der Modelldaten** — Amazon S3 S3-Pfad für benutzerdefinierte Modelle
+ **Container-Image** — Benutzerdefinierter Inferenzcontainer (optional)
+ **Umgebungsvariablen** — Modellspezifische Konfigurationen
+ **Amazon VPC-Konfiguration — Einstellungen** für die Netzwerkisolierung
#### Überwachung der eingesetzten Modelle
1. **Navigieren Sie zu **Studio Classic** > **Bereitstellungen > Endpoints****
1. Wählen Sie Ihren MIG-fähigen Endpunkt
1. Sehen Sie sich unter anderem folgende Kennzahlen an:
+ **MIG-Nutzung — Nutzung** pro GPU-Partition
+ **Speicherverbrauch** — Pro GPU-Partition
+ **Inferenzlatenz** — Verarbeitungszeit der Anfrage
+ **Durchsatz** — Anfragen pro Sekunde
1. ** CloudWatch Amazon-Alarme** für die automatische Überwachung einrichten
1. Konfigurieren Sie **Richtlinien für die auto-scaling** auf der Grundlage der MIG-Nutzung
## HyperPod CLI verwenden
### JumpStart Einsatz
Der HyperPod JumpStart CLI-Befehl enthält zwei neue Felder für die MIG-Unterstützung:
+ `--accelerator-partition-type`- Spezifiziert die MIG-Konfiguration (z. B. mig-4g.20gb)
+ `--accelerator-partition-validation`- Überprüft die Kompatibilität zwischen Modellen und MIG-Profil (Standard: 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/
```
### Bereitstellung benutzerdefinierter Endgeräte
Verwenden Sie für die Bereitstellung über einen benutzerdefinierten Endpunkt die vorhandenen Felder `--resources-requests` und aktivieren `--resources-limits` Sie die MIG-Profilfunktion:
```
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"
}'
```
# Cluster-Resilienzfunktionen für SageMaker HyperPod Cluster-Orchestrierung mit Amazon EKS
SageMaker HyperPod bietet die folgenden Funktionen zur Cluster-Resilienz.
**Topics**
+ [System zur Gesundheitsüberwachung](sagemaker-hyperpod-eks-resiliency-health-monitoring-agent.md)
+ [Grundlegende Zustandsprüfungen](sagemaker-hyperpod-eks-resiliency-basic-health-check.md)
+ [Tiefgreifende Zustandsprüfungen](sagemaker-hyperpod-eks-resiliency-deep-health-checks.md)
+ [Automatische Wiederherstellung von Knoten](sagemaker-hyperpod-eks-resiliency-node-recovery.md)
+ [Kubernetes-Labels im Zusammenhang mit Resilienz von SageMaker HyperPod](sagemaker-hyperpod-eks-resiliency-node-labels.md)
+ [Einen Knoten manuell unter Quarantäne stellen, ersetzen oder neu starten](sagemaker-hyperpod-eks-resiliency-manual.md)
+ [Empfohlene Ausfallsicherheitskonfigurationen](sagemaker-hyperpod-eks-resiliency-config-tips.md)
# System zur Gesundheitsüberwachung
SageMaker HyperPod Das System zur Gesundheitsüberwachung besteht aus zwei Komponenten
1. In Ihren Knoten installierte Monitoring-Agenten, zu denen der Health Monitoring Agent (HMA), der als Systemmonitor auf dem Host dient, und eine Reihe von out-of-node Gesundheitsmonitoren gehören.
1. Node Recovery System, verwaltet von. SageMaker HyperPod Das System zur Zustandsüberwachung überwacht den Zustand des Knotens kontinuierlich über Überwachungsagenten und ergreift dann automatisch Maßnahmen, wenn mithilfe des Node Recovery Systems ein Fehler erkannt wird.
![\[Dieses Bild zeigt, wie das System zur Gesundheitsüberwachung in den HyperPod Cluster integriert ist.\]](http://docs.aws.amazon.com/de_de/sagemaker/latest/dg/images/hyperpod/hyperpod-resilience-event.png)
## Gesundheitschecks, die vom SageMaker HyperPod Gesundheitsüberwacher durchgeführt werden
Der Beauftragte für die SageMaker HyperPod Gesundheitsüberwachung überprüft Folgendes.
**NVIDIA GPUs**
+ [Benachrichtigungen bei Verstößen gegen die DCGM-Richtlinien](https://docs.nvidia.com/datacenter/dcgm/3.0/user-guide/feature-overview.html#notifications)
+ Fehler in der Ausgabe `nvidia-smi`
+ Verschiedene Fehler in den Protokollen, die von der Amazon Elastic Compute Cloud (EC2) -Plattform generiert wurden
+ Validierung der GPU-Anzahl — Wenn die erwartete Anzahl von GPUs in einem bestimmten Instance-Typ (zum Beispiel: 8 GPUs im Instance-Typ ml.p5.48xlarge) und der von zurückgegebenen Anzahl nicht übereinstimmt, startet HMA den Knoten neu `nvidia-smi`
**AWS Trainium**
+ Fehler in der Ausgabe des [AWS Neuron-Monitors](https://awsdocs-neuron.readthedocs-hosted.com/en/latest/tools/neuron-sys-tools/neuron-monitor-user-guide.html)
+ Vom Neuron-Knoten-Problemdetektor generierte Ausgaben (Weitere Informationen zum AWS Neuron-Knoten-Problemdetektor finden Sie unter [Erkennung und Wiederherstellung von Knotenproblemen für AWS Neuron-Knoten in Amazon EKS-Clustern](https://aws.amazon.com/blogs/machine-learning/node-problem-detection-and-recovery-for-aws-neuron-nodes-within-amazon-eks-clusters/).)
+ Verschiedene Fehler in den von der Amazon EC2-Plattform generierten Protokollen
+ Überprüfung der Anzahl neuronaler Geräte — Wenn die tatsächliche Anzahl der neuronalen Geräte in einem bestimmten Instance-Typ nicht mit der von `neuron-ls` zurückgegebenen Anzahl übereinstimmt, startet HMA den Knoten neu
Die oben genannten Prüfungen sind passiv. Die Zustandsprüfungen im Hintergrund werden kontinuierlich auf Ihren Knoten HyperPod ausgeführt. Zusätzlich zu diesen Prüfungen werden während der Erstellung und Aktualisierung von HyperPod Clustern gründliche (oder aktive) Zustandsprüfungen durchgeführt. HyperPod Erfahren Sie mehr über [Deep Health Checks](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-eks-resiliency-deep-health-checks.html).
## Erkennung von Fehlern
Wenn ein Fehler SageMaker HyperPod erkannt wird, wird eine vierteilige Reaktion implementiert:
1. **Knotenbeschriftungen**
1. Gesundheitsstatus: `sagemaker.amazonaws.com/node-health-status`
1. Fehlertyp: `sagemaker.amazonaws.com/fault-types` Bezeichnung für eine allgemeine Kategorisierung
1. Fehlergrund: `sagemaker.amazonaws.com/fault-reasons` Etikett für detaillierte Fehlerinformationen
1. **Node Taint**
1. `sagemaker.amazonaws.com/node-health-status=Unschedulable:NoSchedule`
1. **Anmerkung zum Knoten**
1. Einzelheiten zum Fehler: `sagemaker.amazonaws.com/fault-details`
1. Zeichnet bis zu 20 Fehler mit Zeitstempeln auf, die auf dem Knoten aufgetreten sind
1. **Knotenbedingungen** ([Kubernetes-Knotenzustand](https://kubernetes.io/docs/reference/node/node-status/#condition))
1. Spiegelt den aktuellen Gesundheitszustand in den Knotenbedingungen wider:
+ Typ: Entspricht dem Fehlertyp
+ Status: `True`
+ Grund: Entspricht dem Fehlergrund
+ LastTransitionTime: Zeit des Auftretens des Fehlers
![\[Dieses Bild zeigt, wie das System zur Gesundheitsüberwachung funktioniert, wenn ein Fehler erkannt wird.\]](http://docs.aws.amazon.com/de_de/sagemaker/latest/dg/images/hyperpod/hyperpod-resilience-workflow.png)
## Vom SageMaker HyperPod Health Monitoring-Agenten generierte Protokolle
Der SageMaker HyperPod Health Monitoring Agent ist eine out-of-the-box Funktion zur Integritätsprüfung und wird kontinuierlich auf allen Clustern ausgeführt. HyperPod Der Health Monitoring Agent veröffentlicht erkannte Integritätsereignisse auf GPU- oder Trn-Instances in der CloudWatch Cluster-Protokollgruppe. `/aws/sagemaker/Clusters/`
Die Erkennungsprotokolle des HyperPod Health Monitoring Agents werden als separate Protokollstreams erstellt, die `SagemakerHealthMonitoringAgent` nach jedem Knoten benannt sind. Sie können die Erkennungsprotokolle mithilfe von CloudWatch Log Insights wie folgt abfragen.
```
fields @timestamp, @message
| filter @message like /HealthMonitoringAgentDetectionEvent/
```
Dies sollte eine Ausgabe ähnlich der folgenden erzeugen.
```
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"}
```
# Grundlegende Zustandsprüfungen
SageMaker HyperPod führt während der Erstellung und Aktualisierung von Clustern eine Reihe *grundlegender Integritätsprüfungen* für HyperPod Cluster-Instances durch. Diese grundlegenden Zustandsprüfungen sind orchestratorunabhängig, sodass diese Prüfungen unabhängig von den zugrunde liegenden Orchestrierungsplattformen, die von SageMaker HyperPod (Amazon EKS oder Slurm) unterstützt werden, anwendbar sind.
Bei den grundlegenden Zustandsprüfungen werden Cluster-Instances auf Probleme im Zusammenhang mit Geräten wie Beschleunigern (GPU- und Trainium-Kernen) und Netzwerkgeräten (Elastic Fabric Adapter oder EFA) überwacht. [Eine Liste der grundlegenden Cluster-Zustandsprüfungen finden Sie unter Cluster-Zustandsprüfungen.](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-resiliency-slurm.html#sagemaker-hyperpod-resiliency-slurm-cluster-health-check)
# Tiefgreifende Zustandsprüfungen
SageMaker HyperPod führt während der Erstellung und Aktualisierung von Clustern *eingehende Integritätsprüfungen* für HyperPod Clusterinstanzen durch. Die umfassenden Integritätsprüfungen stellen die Zuverlässigkeit und Stabilität der SageMaker HyperPod Cluster sicher, indem die zugrunde liegenden Hardware- und Infrastrukturkomponenten gründlich getestet werden, bevor die Cluster für das Training von Modellen für maschinelles Lernen verwendet werden können. Dieser proaktive Ansatz hilft dabei, potenzielle Probleme zu einem frühen Zeitpunkt im Cluster-Lebenszyklus zu erkennen und zu beheben.
## Liste der tiefgreifenden Integritätsprüfungen, die durchgeführt wurden von SageMaker HyperPod
SageMaker HyperPod führt die folgenden umfassenden Integritätsprüfungen durch.
**Umfassende Zustandsprüfungen auf Instance-Ebene**
| Kategorie | Name des Dienstprogramms | Kompatibilität von Instance-Typen | Description |
| --- | --- | --- | --- |
| Accelerator | GPU/Anzahl NVLink | GPU | Überprüft die Anzahl GPU/NVLink . |
| Accelerator | [DCGM-Diagnose Stufe](https://docs.nvidia.com/datacenter/dcgm/latest/user-guide/dcgm-diagnostics.html) 4 | GPU | Beurteilt den Zustand und die Funktionalität von NVIDIA, GPUs indem DCGM-Diagnosen (NVIDIA Data Center GPU Manager) auf Stufe 4 ausgeführt werden, einschließlich zusätzlicher Speichertests. |
| Accelerator | Neuron sysfs | Trainium | Bei Trainium-basierten Instances wird der Zustand der Neuron-Geräte durch Auslesen der Zähler aus [Neuron sysfs](https://awsdocs-neuron.readthedocs-hosted.com/en/latest/tools/neuron-sys-tools/neuron-sysfs-user-guide.html) ermittelt, die direkt vom Neuron-Treiber übertragen werden. |
| Accelerator | Neuron-Hardwareprüfung | Trainium | Führt einen Trainings-Workload durch und verifiziert die Ergebnisse, um die Hardware zu testen. |
| Accelerator | Lokaler NCCOM-Test | Trainium | Evaluiert die Leistung kollektiver Kommunikationsoperationen auf einzelnen Trainium-Knoten |
| Netzwerk | EFA | GPU und Trainium | Führt einen Latenz- und Bandbreiten-Benchmarking auf dem angeschlossenen EFA-Gerät durch. |
**Tiefgreifende Integritätsprüfungen auf Clusterebene**
| Kategorie | Name des Dienstprogramms | Kompatibilität von Instance-Typen | Description |
| --- | --- | --- | --- |
| Accelerator | NCCL-Prüfung | GPU | Überprüft die Leistung kollektiver Kommunikationsvorgänge auf mehreren NVIDIA-Geräten GPUs |
| Accelerator | NCCOM-Clustertest | Trainium | Überprüft die Leistung kollektiver Kommunikationsoperationen auf mehreren Trainium-Knoten |
## Protokolle der umfassenden Gesundheitschecks
Im Folgenden finden Sie Beispielprotokolle aus den SageMaker HyperPod Deep Health Checks.
**Protokolle auf Clusterebene**
Die Protokolle für tiefe Integritätsprüfungen auf Clusterebene werden in Ihrer CloudWatch Protokollgruppe unter gespeichert `/aws/sagemaker/Clusters//`
Die Protokollstream werden unter `DeepHealthCheckResults/` protokolliert.
Als Beispiel unten zeigen die Ausgabeprotokolle für Deep Health Checks die Instance-ID, die die Prüfungen nicht bestanden hat, mit der Ursache des Fehlers.
```
{
"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"
}
```
**Protokolle auf Instance-Ebene**
Die Protokolle der umfassenden Zustandsprüfung auf Instance-Ebene werden unter `/var/log/aws/clusters/sagemaker-deep-health-check.log` auf jedem Knoten gespeichert. Stellen Sie eine Verbindung mit SSH auf den Knoten her und öffnen Sie die Protokolldatei, indem Sie den folgenden Befehl ausführen.
```
cat /var/log/aws/clusters/sagemaker-deep-health-check.log
```
Im Folgenden finden Sie ein Beispiel für die Ausgabe des Hardwarestress, des [NVIDIA DCGM-Stresses](https://developer.nvidia.com/dcgm) und des EFA-Konnektivitätstests.
```
# 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
```
Im Folgenden finden Sie eine Beispielausgabe des NCCL-Konnektivitätstests.
```
# 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:
```
# Automatische Wiederherstellung von Knoten
Während der Clustererstellung oder -aktualisierung können Clusteradministratoren die Wiederherstellungsoption für Knoten (Instance) zwischen `Automatic` (empfohlen) und `None` auf Clusterebene wählen. Wenn diese Option auf gesetzt ist`Automatic`, SageMaker HyperPod werden fehlerhafte Knoten automatisch neu gestartet oder ersetzt.
**Wichtig**
Wir empfehlen, die Option `Automatic` einzustellen.
Die automatische Knotenwiederherstellung wird ausgeführt, wenn Probleme beim Health Monitoring Agent, bei grundlegenden Zustandsprüfungen und bei umfassenden Integritätsprüfungen festgestellt werden. Wenn diese Option auf gesetzt ist`None`, kennzeichnet der Health Monitoring Agent die Instances, wenn ein Fehler erkannt wird, leitet aber nicht automatisch Reparatur- oder Wiederherstellungsaktionen an den betroffenen Knoten ein. Diese Option wird nicht empfohlen.
# Kubernetes-Labels im Zusammenhang mit Resilienz von SageMaker HyperPod
*Labels* sind Schlüssel-Wert-Paare, die an [Kubernetes-Objekte](https://kubernetes.io/docs/concepts/overview/working-with-objects/#kubernetes-objects) angehängt werden. SageMaker HyperPod führt die folgenden Bezeichnungen für die bereitgestellten Zustandsprüfungen ein.
## Zustandsetiketten
Die `node-health-status` Beschriftungen stellen den Status des Knotenzustands dar und können als Teil des Knotenauswahlfilters in fehlerfreien Knoten verwendet werden.
| Label (Bezeichnung) | Description |
| --- | --- |
| sagemaker.amazonaws.com/node-health-status: Schedulable | Der Knoten hat die grundlegenden Integritätsprüfungen bestanden und ist für die Ausführung von Workloads verfügbar. Diese Integritätsprüfung entspricht den [derzeit verfügbaren SageMaker HyperPod Resilienzfunktionen für Slurm-Cluster](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-resiliency-slurm.html). |
| sagemaker.amazonaws.com/node-health-status: Unschedulable | Der Knoten führt tiefgreifende Integritätsprüfungen durch und ist nicht für die Ausführung von Workloads verfügbar. |
| sagemaker.amazonaws.com/node-health-status: UnschedulablePendingReplacement | Der Knoten hat die tiefgreifenden Integritätsprüfungen oder die Prüfungen des Integritätsüberwachungs-Agents nicht bestanden und muss ersetzt werden. Wenn die automatische Knotenwiederherstellung aktiviert ist, wird der Knoten automatisch durch ersetzt. SageMaker HyperPod |
| sagemaker.amazonaws.com/node-health-status: UnschedulablePendingReboot | Der Knoten hat die gründlichen Integritätsprüfungen oder die Prüfungen durch einen Agenten zur Gesundheitsüberwachung nicht bestanden und muss neu gestartet werden. Wenn die automatische Knotenwiederherstellung aktiviert ist, wird der Knoten automatisch von neu gestartet. SageMaker HyperPod |
## Deep-Zustandsprüfung
Die `deep-health-check-status` Beschriftungen stellen den Fortschritt der gründlichen Integritätsprüfung auf einem bestimmten Knoten dar. Hilfreich für Kubernetes-Benutzer, um schnell nach dem Fortschritt der allgemeinen Deep Health Checks zu filtern.
| Label (Bezeichnung) | Description |
| --- | --- |
| sagemaker.amazonaws.com/deep-health-check-status: InProgress | Der Knoten führt tiefgreifende Integritätsprüfungen durch und ist nicht für die Ausführung von Workloads verfügbar. |
| sagemaker.amazonaws.com/deep-health-check-status: Passed | Der Knoten hat eingehende Integritätsprüfungen und Agentenprüfungen zur Gesundheitsüberwachung erfolgreich abgeschlossen und ist für die Ausführung von Workloads verfügbar. |
| sagemaker.amazonaws.com/deep-health-check-status: Failed | Der Knoten hat die tiefgreifenden Integritätsprüfungen oder die Prüfungen der Systemüberwachungs-Agenten nicht bestanden und muss neu gestartet oder ausgetauscht werden. Wenn die automatische Knotenwiederherstellung aktiviert ist, wird der Knoten automatisch neu gestartet oder durch ersetzt. SageMaker HyperPod |
## Bezeichnungen für Art und Ursache des Fehlers
Im Folgenden werden die Bezeichnungen `fault-type` und `fault-reason` beschrieben.
+ `fault-type`Beschriftungen stehen für allgemeine Fehlerkategorien, wenn Integritätsprüfungen fehlschlagen. Diese werden für Fehler aufgefüllt, die sowohl bei gründlichen Integritätsprüfungen als auch bei der Integritätsüberwachung der Agenten festgestellt wurden.
+ `fault-reason`-Labels geben den detaillierten Fehlergrund in Verbindung mit einem `fault-type` an.
## Wie SageMaker HyperPod Beschriftungen
In den folgenden Themen wird beschrieben, wie die Etikettierung je nach Fall erfolgt.
**Topics**
+ [Wenn ein Knoten zu einem SageMaker HyperPod Cluster hinzugefügt wird, bei dem die Konfiguration für die Deep-Health-Überprüfung deaktiviert ist](#sagemaker-hyperpod-eks-resiliency-node-how-it-labels-when-dhc-is-off)
+ [Wenn ein Knoten zu einem SageMaker HyperPod Cluster hinzugefügt wird, bei dem die Konfiguration für den Deep Health Check aktiviert ist](#sagemaker-hyperpod-eks-resiliency-node-how-it-labels-when-dhc-is-on)
+ [Wenn es Rechenausfälle auf den Knoten gibt](#sagemaker-hyperpod-eks-resiliency-node-how-it-labels-when-node-fails)
### Wenn ein Knoten zu einem SageMaker HyperPod Cluster hinzugefügt wird, bei dem die Konfiguration für die Deep-Health-Überprüfung deaktiviert ist
Wenn ein neuer Knoten zu einem Cluster hinzugefügt wird und der Deep Health Check für die Instanzgruppe nicht aktiviert ist, SageMaker HyperPod werden dieselben Integritätsprüfungen durchgeführt wie die [derzeit verfügbaren SageMaker HyperPod Zustandsprüfungen für Slurm-Cluster](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-resiliency-slurm.html).
Wenn die Zustandsprüfung erfolgreich ist, werden die Knoten mit der folgenden Bezeichnung gekennzeichnet.
```
sagemaker.amazonaws.com/node-health-status: Schedulable
```
Wenn die Zustandsprüfung nicht bestanden wird, werden die Knoten beendet und ersetzt. Dieses Verhalten entspricht der Funktionsweise der Integritätsprüfung für Slurm-Cluster. SageMaker HyperPod
### Wenn ein Knoten zu einem SageMaker HyperPod Cluster hinzugefügt wird, bei dem die Konfiguration für den Deep Health Check aktiviert ist
Wenn ein neuer Knoten zu einem SageMaker HyperPod Cluster hinzugefügt wird und der Deep Health Check-Test für die Instanzgruppe aktiviert ist, wird HyperPod zuerst der Knoten verunreinigt und der \$12-stündige Deep Health check/stress Test auf dem Knoten gestartet. Es gibt 3 mögliche Ausgaben der Node-Labels nach dem Deep Health Check.
1. Wenn der Deep Health Check-Test bestanden wurde
```
sagemaker.amazonaws.com/node-health-status: Schedulable
```
1. Wenn der Deep Health Check-Test fehlschlägt und die Instance ersetzt werden muss
```
sagemaker.amazonaws.com/node-health-status: UnschedulablePendingReplacement
```
1. Wenn der Deep Health Check-Test fehlschlägt und die Instance neu gestartet werden muss, um den Deep Health Check erneut auszuführen
```
sagemaker.amazonaws.com/node-health-status: UnschedulablePendingReboot
```
Wenn eine Instance den Deep Health Check-Test nicht besteht, wird die Instance immer ersetzt. Wenn der Deep Health Check-Test erfolgreich ist, wird der Makel auf dem Knoten entfernt.
### Wenn es Rechenausfälle auf den Knoten gibt
Der SageMaker HyperPod Health Monitor Agent überwacht außerdem kontinuierlich den Integritätsstatus jedes Knotens. Wenn der Agent Fehler feststellt (z. B. GPU-Ausfall oder Treiberabsturz), kennzeichnet er den Knoten mit einer der folgenden Bezeichnungen.
1. Wenn der Knoten fehlerhaft ist und ersetzt werden muss
```
sagemaker.amazonaws.com/node-health-status: UnschedulablePendingReplacement
```
1. Wenn der Knoten fehlerhaft ist und neu gestartet werden muss
```
sagemaker.amazonaws.com/node-health-status: UnschedulablePendingReboot
```
Der Health Monitor-Agent verfälscht den Knoten auch, wenn er Probleme mit dem Zustand des Knotens feststellt.
# Einen Knoten manuell unter Quarantäne stellen, ersetzen oder neu starten
Erfahren Sie, wie Sie einen fehlerhaften Knoten in SageMaker HyperPod Clustern, die mit Amazon EKS orchestriert wurden, manuell unter Quarantäne stellen, ersetzen und neu starten können.
**Um einen Knoten unter Quarantäne zu stellen und das Löschen eines Trainings-Pods zu erzwingen**
```
kubectl cordon
```
Erzwingen Sie nach der Quarantäne das Auswerfen des Pods. Dies ist nützlich, wenn Sie sehen, dass ein Pod länger als 30 Minuten im Terminierungsmodus hängen geblieben ist oder wenn unter Ereignisse die Meldung „Knoten ist nicht bereit“ `kubectl describe pod` angezeigt wird
```
kubectl delete pods --grace-period=0 --force
```
SageMaker HyperPod bietet zwei Methoden für die manuelle Wiederherstellung von Knoten. Der bevorzugte Ansatz ist die Verwendung von SageMaker HyperPod Reboot and Replace APIs, das einen schnelleren und transparenteren Wiederherstellungsprozess ermöglicht, der für alle Orchestratoren funktioniert. Alternativ können Sie kubectl-Befehle verwenden, um Knoten für Neustart- und Ersetzungsvorgänge zu kennzeichnen. Beide Methoden aktivieren dieselben SageMaker HyperPod Wiederherstellungsprozesse.
**Um einen Knoten mithilfe der Reboot-API neu zu starten**
Um einen Knoten neu zu starten, können Sie die BatchRebootClusterNodes API verwenden.
Hier ist ein Beispiel für die Ausführung des Neustartvorgangs auf zwei Instanzen eines Clusters mithilfe von 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
```
**Um einen Knoten mithilfe der Replace-API zu ersetzen**
Um einen Knoten zu ersetzen, können Sie die BatchReplaceClusterNodes API wie folgt verwenden
Hier ist ein Beispiel für die Ausführung des Ersetzungsvorgangs auf zwei Instanzen eines Clusters mithilfe von 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
```
**Von Karpenter verwaltete Cluster**
Bei SageMaker HyperPod Clustern, die Karpenter für die Knotenbereitstellung verwenden, garantiert die `BatchReplaceClusterNodes` API nicht, dass ein Ersatzknoten erstellt wird. Der angegebene Knoten *wird* beendet, aber der Ersatz hängt vom Bereitstellungsmodell von Karpenter ab. pod-demand-based Karpenter erstellt nur dann neue Knoten, wenn sich Pods in einem `Pending` Zustand befinden, der nicht für bestehende Knoten geplant werden kann.
Wenn die Arbeitslast des gelöschten Knotens auf die verbleibenden Knoten im Cluster verschoben werden kann (z. B. wenn diese Knoten über eine ausreichende Kapazität verfügen), stellt Karpenter keinen Ersatz bereit. Um sicherzustellen, dass ein Ersatzknoten erstellt wird, stellen Sie sicher, dass Ihre Workload-Konfiguration (wie Pod-Anti-Affinitätsregeln oder Ressourcenanforderungen) einen neuen Knoten für die verdrängten Pods erfordert.
Wir sind uns dieser Einschränkung bewusst und arbeiten aktiv an einer Lösung, um den Austausch von Knoten zu erzwingen, wenn dies über die API angefordert wird.
**Um einen Knoten mit kubectl zu ersetzen**
Benennen Sie den Knoten, durch den ersetzt werden soll`sagemaker.amazonaws.com/node-health-status=UnschedulablePendingReplacement`, was den auslöst. SageMaker HyperPod [Automatische Wiederherstellung von Knoten](sagemaker-hyperpod-eks-resiliency-node-recovery.md) Beachten Sie, dass Sie auch die automatische Knotenwiederherstellung während der Clustererstellung oder -aktualisierung aktivieren müssen.
```
kubectl label nodes \
sagemaker.amazonaws.com/node-health-status=UnschedulablePendingReplacement
```
**Um einen Knoten mit kubectl neu zu starten**
Benennen Sie den Knoten, mit dem neu gestartet werden soll`sagemaker.amazonaws.com/node-health-status=UnschedulablePendingReboot`, was den auslöst. SageMaker HyperPod [Automatische Wiederherstellung von Knoten](sagemaker-hyperpod-eks-resiliency-node-recovery.md) Beachten Sie, dass Sie auch die automatische Knotenwiederherstellung während der Clustererstellung oder -aktualisierung aktivieren müssen.
```
kubectl label nodes \
sagemaker.amazonaws.com/node-health-status=UnschedulablePendingReboot
```
Nachdem die Labels `UnschedulablePendingReplacement` oder `UnschedulablePendingReboot` hinzugefügt wurden, sollten Sie in wenigen Minuten sehen können, dass der Knoten beendet oder neu gestartet wurde.
# Empfohlene Ausfallsicherheitskonfigurationen
Wenn die Deep Health Checks aktiviert sind und dem Cluster eine neue Instance hinzugefügt wird (entweder während der HyperPod Clustererstellung oder durch automatischen Knotenaustausch), durchläuft die neue Instance für etwa ein paar Stunden den Deep Health Check-Prozess (Stresstests auf Instanzebene). Im Folgenden finden Sie Vorschläge für Kombinationen von Resilienz-Konfigurationen, die von möglichen Fällen abhängen.
1. **Fall**: Wenn Sie zusätzliche Ersatzknoten innerhalb eines Clusters als Backup-Ressourcen haben (ohne die volle Kapazität zu nutzen), oder wenn Sie etwa 2 Stunden warten können, bis der gründliche Integritätscheck durchgeführt wird, um die weniger fehleranfälligen Instances zu finden.
**Empfehlung**: Aktivieren Sie die Konfiguration für die umfassende Integritätsprüfung während des gesamten Cluster-Lebenszyklus. Die Konfiguration für die automatische Wiederherstellung des Knotens ist standardmäßig aktiviert.
1. **Fall**: Wenn Sie keine zusätzlichen Backup-Knoten haben (die Kapazität ist für einen Teil der Trainingslast voll ausgeschöpft). Sie möchten die Ersatzknoten so schnell wie möglich erhalten, um den Trainingsjob wieder aufnehmen zu können.
**Empfehlung**: Aktivieren Sie den Deep Health Check während der Clustererstellung und schalten Sie dann die Konfiguration für den Deep Health Check aus, nachdem der Cluster erstellt wurde. Die Konfiguration für die auto Wiederherstellung des Knotens ist standardmäßig aktiviert.
1. **Fall**: Wenn Sie keine zusätzlichen Backup-Knoten haben und nicht auf den \$12-stündigen umfassenden Zustandstest warten möchten (kleine Cluster).
**Empfehlung**: Deaktivieren Sie die Konfiguration für die umfassende Integritätsprüfung während des gesamten Cluster-Lebenszyklus. Die Konfiguration für die auto Wiederherstellung des Knotens ist standardmäßig aktiviert.
Wenn Sie den Trainingsjob nach einem Ausfall sofort fortsetzen möchten, stellen Sie sicher, dass Sie über zusätzliche Ersatzknoten als Backup-Ressourcen im Cluster verfügen.
# Spot-Instances bei Amazon SageMaker HyperPod
Amazon SageMaker HyperPod unterstützt Amazon EC2 Spot-Instances und ermöglicht so erhebliche Kosteneinsparungen bei fehlertoleranten und statusfreien Workloads. AI/ML Zu den Anwendungsfällen gehören Batch-Inferenz- und Trainingsjobs, Hyperparameter-Tuning und experimentelle Workloads. Sie können Spot-Instances auch verwenden, um Ihre Rechenkapazität automatisch zu skalieren, wenn diese kostengünstige Kapazität verfügbar ist, und auf On-Demand-Kapazität zurückzuskalieren, wenn die zusätzliche Spot-Kapazität zurückgewonnen wird.
Standardmäßig verwenden Spot-Instances on HyperPod Work die [Continuous Provisioning-Funktion](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-scaling-eks.html), mit HyperPod der die verbleibende Kapazität automatisch im Hintergrund bereitgestellt werden kann SageMaker HyperPod , während die Workloads auf verfügbaren Instances sofort gestartet werden. Wenn bei der Knotenbereitstellung aufgrund von Kapazitätsengpässen oder anderen Problemen Fehler auftreten, versucht es SageMaker HyperPod automatisch im Hintergrund, bis die Cluster ihre gewünschte Größe erreicht haben, sodass Ihre Autoscaling-Operationen stabil und blockierungsfrei bleiben. [Sie können Spot-Instances auch mit Karpenter-basierter Autoskalierung verwenden.](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-eks-autoscaling.html)
**Wichtige Funktionen und Konzepte, die es zu berücksichtigen gilt**
+ Erzielen Sie Kosteneinsparungen von bis zu 90% im Vergleich zu On-Demand-Instances
+ Verwenden Sie Spot-Instances für Jobs, die Unterbrechungen bewältigen können und bei denen die Start- und Abschlusszeiten von Aufträgen flexibel sind
+ Wenn Sie Karpenter für die automatische Skalierung verwenden, können Sie so konfigurieren, dass automatisch HyperPod auf On-Demand zurückgegriffen wird, wenn die Spot-Kapazität unterbrochen oder nicht verfügbar ist
+ Greifen Sie auf eine Vielzahl von CPU-, GPU- und Accelerator-Instance-Typen zu, die von unterstützt werden HyperPod
+ Die Kapazitätsverfügbarkeit hängt vom Angebot von EC2 ab und variiert je nach Region und Instance-Typ
+ Mithilfe verschiedener Tools wie dem von EC2 bereitgestellten [Spot Instance Advisor](https://aws.amazon.com/ec2/spot/instance-advisor/) können Sie verschiedene Aktionen ausführen, z. B. die Wahrscheinlichkeit ermitteln, mit der gewünschte Instances abgerufen oder unterbrochen werden
## Erste Schritte
### Voraussetzungen
Stellen Sie vor Beginn sicher, dass Sie über Folgendes verfügen:
#### AWS CLI installiert und konfiguriert
Richten Sie Ihre AWS Anmeldeinformationen und Ihre Region ein:
```
aws configure
```
Detaillierte Anweisungen finden Sie in der [Dokumentation zu den AWS Anmeldeinformationen](https://docs.aws.amazon.com/sdk-for-java/v1/developer-guide/setup-credentials.html).
#### IAM-Rolle für die Ausführung SageMaker HyperPod
Um den Cluster zu aktualisieren, müssen Sie zunächst [AWS Identity and Access Management Zugriffsverwaltungsberechtigungen](https://aws.amazon.com/iam/) (IAM) für Karpenter erstellen. Anweisungen finden Sie unter [Erstellen einer IAM-Rolle für HyperPod ](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-eks-autoscaling-iam.html) Autoscaling mit Karpenter.
#### Einrichtung von VPC- und EKS-Clustern
**2.1 VPC- und EKS-Cluster erstellen**
Folgen Sie der [HyperPod EKS-Installationsanleitung](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-eks-install-packages-using-helm-chart.html), um:
1. Erstellen Sie eine VPC mit Subnetzen in mehreren Availability Zones
1. Erstellen Sie einen EKS-Cluster
1. Installieren Sie [die erforderlichen Abhängigkeiten](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-eks-install-packages-using-helm-chart.html) mithilfe von Helm-Diagrammen
**2.2 Legen Sie Umgebungsvariablen fest**
```
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"
```
#### Dienstkontingente für die Spot-Instances
Stellen Sie sicher, dass Sie über die erforderlichen Kontingente für die Instances verfügen, die Sie im SageMaker HyperPod Cluster erstellen werden. Um Ihre Kontingente zu überprüfen, wählen Sie in der Konsole Service Quotas im Navigationsbereich AWS Services und anschließend SageMaker. Der folgende Screenshot zeigt beispielsweise das verfügbare Kontingent für C5-Instances.
![\[Ein Bild mit Informationen zur Kostenregion.\]](http://docs.aws.amazon.com/de_de/sagemaker/latest/dg/images/Screenshot-cluster-quota.png)
#### Überprüfen Sie die Verfügbarkeit von Spots
Bevor Sie Spot-Instanzgruppen erstellen, überprüfen Sie die Verfügbarkeit in verschiedenen Availability Zones:
```
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
```
**Tipp**: Wählen Sie Availability Zones mit höheren Platzierungswerten aus, um eine bessere Verfügbarkeit zu erzielen. Sie können auch die Verfügbarkeit der Preise für Spot Instance Advisor und EC2 Spot überprüfen. Wählen Sie die erforderliche Availability Zone mit einem besseren Verfügbarkeitswert aus und konfigurieren Sie die Instanzgruppe mit dem zugehörigen Subnetz, um die Instance in dieser AZ zu starten.
### Eine Instanzgruppe erstellen (kein Autoscaling)
**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'"]
}'
```
**Cluster aktualisieren (Spot \$1 auf Anfrage)**
```
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`kann nicht geändert werden, sobald eine Instanzgruppe erstellt wurde.
**Beschreiben Sie den 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": {...}
}
}
```
### Konsole verwenden
#### Erstellen und konfigurieren Sie einen SageMaker HyperPod Cluster
Starten und konfigurieren Sie zunächst Ihren SageMaker HyperPod EKS-Cluster und stellen Sie sicher, dass der Continuous Provisioning-Modus bei der Clustererstellung aktiviert ist. Führen Sie folgende Schritte aus:
1. Wählen Sie auf der SageMaker AI-Konsole im Navigationsbereich HyperPod Cluster aus.
1. Wählen Sie Create HyperPod cluster and Orchestrated on Amazon EKS aus.
1. Wählen Sie für Einrichtungsoptionen die Option Benutzerdefiniertes Setup aus.
1. Geben Sie unter Name einen Namen ein.
1. Wählen Sie für Instanzwiederherstellung die Option Automatisch aus.
1. Wählen Sie für den Instanzbereitstellungsmodus die Option Kontinuierliche Bereitstellung verwenden aus.
1. CapacityType : Wählen Sie Spot
1. Wählen Sie Absenden aus.
Screenshot der Konsole:
![\[Ein Bild, das den Ablauf zur Erstellung des Clusters enthält.\]](http://docs.aws.amazon.com/de_de/sagemaker/latest/dg/images/Screenshot-create-cluster.png)
Dieses Setup erstellt die erforderliche Konfiguration wie Virtual Private Cloud (VPC), Subnetze, Sicherheitsgruppen und EKS-Cluster und installiert Operatoren im Cluster. Sie können auch vorhandene Ressourcen wie einen EKS-Cluster bereitstellen, wenn Sie einen vorhandenen Cluster verwenden möchten, anstatt einen neuen zu erstellen. Diese Einrichtung dauert etwa 20 Minuten.
#### Dem gleichen Cluster wird eine neue Spot-Instance-Gruppe hinzugefügt
Um Ihrem bestehenden HyperPod EKS-Cluster eine Spot-IG hinzuzufügen. Führen Sie folgende Schritte aus:
1. Wählen Sie auf der SageMaker AI-Konsole im Navigationsbereich HyperPod Cluster aus.
1. Wählen Sie einen vorhandenen HyperPod Cluster mit Amazon EKS Orchestration aus (stellen Sie sicher, dass die kontinuierliche Bereitstellung aktiviert ist).
1. Klicken Sie auf Bearbeiten.
1. Klicken Sie auf der Seite „Cluster bearbeiten“ auf Instanzgruppe erstellen.
1. Wählen Sie in der Instanzgruppenkonfiguration den Kapazitätstyp Spot-Instance aus.
1. Klicken Sie auf Instanzgruppe erstellen.
1. Klicken Sie auf Submit.
**Screenshot der Konsole:**
![\[Ein Bild, das den Ablauf der Instanzgruppenerstellung enthält.\]](http://docs.aws.amazon.com/de_de/sagemaker/latest/dg/images/Screenshot-instance-group.png)
### Verwenden 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"
```
Einzelheiten finden Sie unter [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).
### Autoscaling auf Basis von Karpenter
#### Clusterrolle erstellen
**Schritt 1: Navigieren Sie zur IAM-Konsole**
1. Gehen Sie zum **AWS-Managementkonsole**→ **IAM-Dienst**
1. Klicken Sie in der linken Seitenleiste auf **Rollen**
1. Klicken Sie auf **Rolle erstellen**
**Schritt 2: Richten Sie eine Vertrauensrichtlinie ein**
1. Wählen Sie Benutzerdefinierte Vertrauensrichtlinie (statt AWS Service)
1. Ersetzen Sie das Standard-JSON durch diese Vertrauensrichtlinie:
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": [
"hyperpod.sagemaker.amazonaws.com"
]
},
"Action": "sts:AssumeRole"
}
]
}
```
klicken Sie auf Weiter
**Schritt 3: Erstellen Sie eine benutzerdefinierte Berechtigungsrichtlinie**
Da es sich um spezifische SageMaker Berechtigungen handelt, müssen Sie eine benutzerdefinierte Richtlinie erstellen:
1. Klicken Sie auf **Richtlinie erstellen** (öffnet neuen Tab)
1. Klicken Sie auf die Registerkarte **JSON**
1. Geben Sie diese Richtlinie ein:
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"sagemaker:BatchAddClusterNodes",
"sagemaker:BatchDeleteClusterNodes"
],
"Resource": "*"
}
]
}
```
1. Klicken Sie auf **Weiter**
1. Geben Sie ihm einen Namen wie `SageMakerHyperPodRolePolicy`
1. Klicken Sie auf **Richtlinie erstellen**
**Schritt 4: Hängen Sie die Richtlinie an die Rolle an**
1. Kehren Sie zur Registerkarte zur Rollenerstellung zurück
1. Aktualisieren Sie die Richtlinienliste
1. Suchen Sie nach Ihrer neu erstellten Richtlinie und wählen Sie sie aus
1. Klicken Sie auf **Weiter**
**Schritt 5: Rolle benennen und erstellen**
1. Geben Sie einen Rollennamen ein (z. B.`SageMakerHyperPodRole`)
1. Fügen Sie bei Bedarf eine Beschreibung hinzu
1. Überprüfen Sie die Vertrauensrichtlinie und die Berechtigungen
1. Klicken Sie auf **Rolle erstellen**
#### Verifizierung
Nach der Erstellung können Sie Folgendes überprüfen:
+ Wenn Sie auf der Registerkarte Vertrauensbeziehungen nachsehen, wird der Hyperpod-Dienst angezeigt
+ Auf der Registerkarte „Berechtigungen“ wird Ihre benutzerdefinierte Richtlinie angezeigt
+ Die Rolle ARN wird für die Verwendung mit verfügbar sein HyperPod
Das ARN-Format der Rolle wird sein:
```
arn:aws:iam::YOUR-ACCOUNT-ID:role/SageMakerHyperPodRole
```
#### Cluster erstellen mit AutoScaling:
Für eine bessere Verfügbarkeit können Sie mehrere erstellen IGs , AZs indem Sie Subnetze konfigurieren. Sie können auch OnDemand als Fallback IGs einbeziehen.
```
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"
}'
```
#### Cluster aktualisieren (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'"]
}
}]'
```
#### Erstellen HyperpodNodeClass
`HyperpodNodeClass`ist eine benutzerdefinierte Ressource, die vorab erstellten Instanzgruppen zugeordnet wird und Einschränkungen dafür definiert SageMaker HyperPod, welche Instanztypen und Availability Zones für die Auto Scaling-Entscheidungen von Karpenter unterstützt werden. Geben Sie zur Verwendung `HyperpodNodeClass` einfach die Namen Ihres SageMaker HyperPod Clusters an, den `InstanceGroups` Sie als Quelle für die AWS Rechenressourcen verwenden möchten, die Sie für die Skalierung Ihrer Pods in Ihrem verwenden möchten. NodePools Der `HyperpodNodeClass` Name, den Sie hier verwenden, wird NodePool in den nächsten Abschnitt übernommen, in dem Sie darauf verweisen. Dies gibt `HyperpodNodeClass` an NodePool , aus welchem Material Ressourcen bezogen werden sollen. Gehen Sie wie folgt vor`HyperpodNodeClass`, um eine zu erstellen:
1. Erstellen Sie eine YAML-Datei (z. B. nodeclass.yaml), die dem folgenden Code ähnelt. Fügen Sie `InstanceGroup` Namen hinzu, die Sie bei der Clustererstellung verwendet haben. SageMaker HyperPod Sie können einem vorhandenen SageMaker HyperPod EKS-Cluster auch neue Instanzgruppen hinzufügen.
1. Verweisen Sie in Ihrer NodePool Konfiguration auf den `HyperPodNodeClass` Namen.
Das Folgende ist ein Beispiel`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 priorisiert Spot-Instance-Gruppen gegenüber On-Demand-Instances und verwendet On-Demand-Instances als Fallback, sofern dies in der Konfiguration angegeben ist. Die Instance-Auswahl ist nach den EC2 Spot Placement Scores sortiert, die der Availability Zone jedes Subnetzes zugeordnet sind.
**Wenden Sie die Konfiguration auf Ihren EKS-Cluster an, indem Sie: `kubectl`**
```
kubectl apply -f nodeclass.yaml
```
Der HyperPod Cluster muss AutoScaling aktiviert sein und der AutoScaling Status muss sich auf ändern, `InService` bevor der angewendet werden `HyperpodNodeClass` kann. Außerdem werden die Kapazitäten der Instanzgruppen als Spot oder angezeigt OnDemand. Weitere Informationen und wichtige Überlegungen finden Sie unter [Autoscaling auf SageMaker HyperPod EKS](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-eks-autoscaling.html).
**Zum Beispiel**
```
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": {}}
```
#### Erstellen NodePool
Das NodePool legt Einschränkungen für die Knoten fest, die von Karpenter erstellt werden können, und für die Pods, die auf diesen Knoten ausgeführt werden können. NodePool Sie können so eingestellt werden, dass sie verschiedene Aktionen ausführen, wie z. B.:
+ Definieren Sie Labels und Taints, um die Anzahl der Pods zu begrenzen, die auf von Karpenter erstellten Knoten ausgeführt werden können
+ Beschränken Sie die Knotenerstellung auf bestimmte Zonen, Instanztypen und Computerarchitekturen usw.
Weitere Informationen zu finden NodePool Sie unter. [NodePools](https://karpenter.sh/docs/concepts/nodepools/) SageMaker HyperPod managed Karpenter unterstützt eine begrenzte Anzahl bekannter Kubernetes- und Karpenter-Anforderungen, die wir in diesem Beitrag erläutern.
Gehen Sie wie folgt vor, um eine NodePool zu erstellen:
Erstellen Sie eine YAML-Datei `nodepool.yaml` mit dem Namen Ihrer gewünschten NodePool Konfiguration. Der folgende Code ist eine Beispielkonfiguration zum Erstellen eines NodePool Beispiels. Wir geben an NodePool , dass es unseren SageMaker ml.g6.xlarge-Instance-Typ einschließt, und wir geben ihn zusätzlich für eine Zone an. Weitere Anpassungen finden Sie unter. [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"]
```
**Tipp**: Bei einer EC2-Spot-Unterbrechung manipuliert Hyperpod den Knoten, um die Pod-Entfernung auszulösen. **Der **Konsolidierungsprozess** von Karpenter berücksichtigt die Budgets für Pod-Unterbrechungen und führt eine normale Kubernetes-Räumung durch. Wenn Sie jedoch ConsolidateAfter: 0 setzen, kann die Konsolidierung sofort erfolgen, sodass nur sehr wenig Zeit für eine ordentliche Pod-Räumung bleibt.** Stellen Sie ihn bis zu 2 Minuten auf einen Wert ungleich Null ein, damit der Pod bei allen Checkpoint-Anforderungen ordnungsgemäß entfernt werden kann.
**Wenden Sie das auf Ihren Cluster an: NodePool **
```
kubectl apply -f nodepool.yaml
```
**Überwachen Sie den NodePool Status, um sicherzustellen, dass die Bedingung Bereit im Status auf True gesetzt ist:**
```
kubectl get nodepool gpunodepool -oyaml
```
Dieses Beispiel zeigt, wie a verwendet werden NodePool kann, um die Hardware (Instanztyp) und die Platzierung (Availability Zone) für Pods anzugeben.
**Starten Sie einen einfachen Workload**
Mit dem folgenden Workload wird eine Kubernetes-Bereitstellung ausgeführt, bei der die bereitgestellten Pods 1 CPU und 256 MB Speicher pro Replikat und Pod anfordern. Die Pods wurden noch nicht hochgefahren.
```
kubectl apply -f https://raw.githubusercontent.com/aws/karpenter-provider-aws/refs/heads/main/examples/workloads/inflate.yaml
```
Wenn wir dies anwenden, können wir eine Bereitstellung und den Start eines einzelnen Knotens in unserem Cluster sehen, wie im folgenden Screenshot gezeigt.
**Verwenden Sie den folgenden Befehl, um diese Komponente zu skalieren:**
```
kubectl scale deployment inflate --replicas 10
```
Weitere [https://docs.aws.amazon.com/sagemaker/latest/dg/sagemakerInformationen finden Sie unter hyperpod-eks-autoscaling .html](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-eks-autoscaling.html).
### Verwaltung von Knotenunterbrechungen
Spot-Instances können jederzeit zurückgefordert werden. In den meisten Fällen bietet EC2 nach bestem Wissen eine zweiminütige Unterbrechungsanzeige, die jedoch nicht garantiert werden kann. In einigen Situationen kann EC2 Spot-Instances sofort und ohne Vorwarnung beenden. HyperPod verarbeitet automatisch beide Szenarien:
+ Mit 2 Minuten Vorankündigung: Automatisch wird erneut versucht, den Pod ordnungsgemäß zu entfernen und die Kapazität kontrolliert auszutauschen, sobald Spot-Kapazität verfügbar ist.
+ Ohne Vorankündigung (sofortige Kündigung): Es wird automatisch erneut versucht, den Node auszutauschen (sobald Spot-Kapazität verfügbar ist), ohne dass der Knoten ordnungsgemäß gelöscht wird
**Funktionsweise**
Wenn EC2 eine Spot-Unterbrechungsbenachrichtigung sendet, wird automatisch Folgendes ausgeführt: HyperPod
1. Erkennt ein Unterbrechungssignal
1. Beeinträchtigt den Knoten: Verhindert, dass neue Pods für die unterbrochene Instanz geplant werden
1. Räumt Pods ordnungsgemäß aus: Gibt laufenden Pods Zeit, ihre Arbeit abzuschließen oder zu überprüfen (unter Berücksichtigung von Kubernetes) `terminationGracePeriodSeconds`
1. Ersetzt Kapazität: Versucht automatisch, die Ersatz-Instances bereitzustellen (Spot- oder On-Demand-Instances, je nach Verfügbarkeit).
Der Kapazitätsersatz erfolgt durch die automatische Bereitstellung von Ersatzinstanzen. Wenn Kapazität nicht sofort verfügbar ist, fährt das System mit der Überprüfung fort, bis Ressourcen verfügbar sind. Bei Instanzgruppen ohne automatische Skalierung wird HyperPod versucht, innerhalb derselben Instanzgruppe nach oben zu skalieren, bis die erforderliche Kapazität verfügbar ist. Für auf Karpenter basierende Instanzgruppen implementiert Karpenter einen Fallback-Mechanismus für andere Instanzgruppen, die in der Node-Klasse konfiguriert sind, wenn die primäre Gruppe den Bedarf nicht decken kann. Darüber hinaus können Sie On-Demand als Fallback-Option konfigurieren, sodass Karpenter automatisch zu On-Demand-Instances wechseln kann, wenn Spot-Instanzgruppen nicht erfolgreich hochskaliert werden können.
1. Verschiebt Workloads: Kubernetes verschiebt automatisch gelöschte Pods auf fehlerfreien Knoten
### Finden Sie Ihre Nutzung und Rechnung heraus
Um Ihre Nutzung und Abrechnung für Spot-Instances auf zu überprüfen, können HyperPod Sie die AWS Cost Explorer Explorer-Konsole verwenden. Gehen Sie zu Billing and Cost Management > Rechnung
![\[Ein Bild mit Informationen zur Kostenregion.\]](http://docs.aws.amazon.com/de_de/sagemaker/latest/dg/images/Screenshot-cost-region.png)
**Um mehr über Nutzung und Abrechnung auf der Konsole zu erfahren, gehen Sie zu Billing and Cost Management > Cost Explorer**
![\[Ein Bild mit Kosten und Nutzung.\]](http://docs.aws.amazon.com/de_de/sagemaker/latest/dg/images/Screenshot-cost-usage.png)
# UltraServers In Amazon verwenden SageMaker HyperPod
SageMaker HyperPod Die Unterstützung für Ultraserver bietet leistungsstarke GPU-Rechenfunktionen für KI- und Machine-Learning-Workloads. Diese auf NVIDIA GB200 und der NVL72 Architektur basierenden Ultraserver bieten NVLink Konnektivität für 18 GB200 Instanzen in einer Dual-Rack-Konfiguration, was insgesamt 72 B200 entspricht. GPUs Diese NVLink Struktur ermöglicht es Workloads, GPU-Kommunikation zu nutzen, die die nutzbare GPU-Kapazität und den adressierbaren Speicher im Vergleich zu diskreten Instances erhöht und komplexere und ressourcenintensivere KI-Modelle unterstützt. Die NVLink Konnektivität wird durch die NVIDIA IMEX-Technologie ermöglicht, die die Low-Level-Konfiguration für sichere GPU-Fabric-Verbindungen zwischen Instanzen innerhalb desselben Racks übernimmt.
HyperPod vereinfacht die Bereitstellung und Verwaltung dieser GPU-Cluster durch intelligente Topologieerkennung und automatisierte Konfiguration. Die Plattform erkennt Knoten automatisch und kennzeichnet sie mit ihrem physischen Standort und ihren Kapazitätsblockinformationen, was eine topologieorientierte Planung für verteilte Workloads unterstützt. HyperPod abstrakt die komplexen IMEX-Konfigurationsanforderungen, sodass Sie sich auf die Bereitstellung von Workloads konzentrieren können, anstatt sich auf die GPU-Fabric-Konfiguration auf niedriger Ebene zu konzentrieren. Sie können flexible Bereitstellungsoptionen wählen, darunter sowohl selbstverwaltete Knoten als auch EKS-verwaltete Knotengruppen. Amazon EKS bietet optimierte AMIs , darunter vorkonfigurierte NVIDIA-Treiber, Fabric Manager, IMEX-Treiber und die gesamte erforderliche Systemsoftware für einen reibungslosen Betrieb.
Die Integration umfasst Funktionen zur Pod-Platzierung, die sicherstellen, dass verteilte Workloads mithilfe von standardmäßigen Kubernetes-Topologie-Labels optimal auf mehrere NVL72 Domains verteilt werden. Integrierte Überwachungs- und automatische Wiederherstellungsfunktionen bieten Betriebsunterstützung, wobei der AMI-Integritätsagent GPU-Fehler anhand von Kernelprotokollen erkennt und Probleme automatisch beheben oder fehlerhafte Knoten in verwalteten Knotengruppen ersetzen kann. Diese Kombination aus GPU-Skalierung, intelligenter Workload-Platzierung und automatisierten Abläufen hilft Ihnen, sich auf Ihre AI/ML Innovationen statt auf die Komplexität der Infrastruktur zu konzentrieren und gleichzeitig die maximale Leistung aus Ihren GPU-Investitionen herauszuholen.
Gehen Sie wie folgt vor, um die Verwendung UltraServers mit Ihrem HyperPod Cluster einzurichten:
1. Erstellen Sie einen [EKS-basierten Cluster HyperPod ](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-eks-operate-console-ui-create-cluster.html). Wenn Sie eine Instanzgruppe auswählen, stellen Sie sicher, dass Sie eine auswählen. UltraServer
1. Nachdem Ihr Cluster erstellt wurde, verwenden Sie die folgenden Befehle, um betriebsbereite Plug-ins zu installieren:
NVIDIA-Geräte-Plugin 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"
```
Erkennung von GPU-Funktionen
```
kubectl apply -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/v0.17.2/deployments/static/gpu-feature-discovery-daemonset.yaml
```
Sie können jetzt Aufträge ausführen. Im folgenden Beispiel wird gezeigt, wie Sie eine Domain erstellen, eine IMEX-Domain konfigurieren und die Kanalzuweisung aktivieren. Mit diesen Schritten können Sie auch einen Pod erstellen, um einen Kanal für die NCCL-Kommunikation bereitzustellen.
1. Erstellen Sie eine Ressourcenspezifikationsdatei zur Verwendung mit 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. Wenden Sie die Konfiguration an, die Sie erstellt haben.
```
kubectl apply -f imex-channel-injection.yaml
```
1. Um zu überprüfen, ob Ihr Pod erstellt wurde, führen Sie die `get pods`-Befehle aus.
```
kubectl get pods
kubectl get pods -n nvidia-dra-driver-gpu -l resource.nvidia.com/computeDomain
```
1. Sie können auch in den Protokollen des Pods nachsehen, ob er einen Kommunikationskanal zugewiesen hat.
```
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. Sie können auch anhand der Protokolle überprüfen, ob die automatisierte IMEX-Konfiguration mit einem zugewiesenen Kanal ausgeführt wird.
```
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. Nachdem Sie alles überprüft haben, löschen Sie den Workload und entfernen Sie die Konfiguration.
```
kubectl delete -f imex-channel-injection.yaml
```
# IDEs und Notizbücher
Amazon führt SageMaker eine neue Funktion für SageMaker HyperPod EKS-Cluster ein, mit der KI-Entwickler ihre interaktiven Workloads für maschinelles Lernen direkt auf dem HyperPod EKS-Cluster ausführen können. Mit dieser Funktion wird ein neues Add-on namens Amazon SageMaker Spaces eingeführt, mit dem KI-Entwickler eigenständige Umgebungen für den Betrieb von Notebooks erstellen und verwalten können.
Administratoren können die SageMaker HyperPod Konsole verwenden, um das Add-on auf ihrem Cluster zu installieren und Standardspeicherkonfigurationen wie Bilder, Rechenressourcen, lokalen Speicher für Notebook-Einstellungen (zusätzlicher Speicher, der an ihre Entwicklungsbereiche angehängt werden muss), Dateisysteme und Initialisierungsskripten zu definieren. Eine Installationsoption mit nur einem Klick wird mit Standardeinstellungen verfügbar sein, um die Admin-Erfahrung zu vereinfachen. Administratoren können die SageMaker HyperPod Konsole, kubectl oder HyperPod CLI verwenden, um den Operator zu installieren, Standardeinstellungen zu erstellen und alle Bereiche an einem zentralen Ort zu verwalten.
KI-Entwickler können HyperPod CLI verwenden, um Dev Spaces zu erstellen, zu aktualisieren und zu löschen. Sie haben die Flexibilität, von Administratoren bereitgestellte Standardkonfigurationen zu verwenden oder Einstellungen anzupassen. KI-Entwickler können über ihren lokalen VS Code IDEs, ihren HyperPod Webbrowser, der and/or ihre Spaces hostet, JupyterLab oder ihre CodeEditor IDE auf einer benutzerdefinierten DNS-Domain zugreifen, die von ihren Administratoren konfiguriert wurde. Sie können auch die Portweiterleitungsfunktion von Kubernetes verwenden, um auf Bereiche in ihren Webbrowsern zuzugreifen.
## Admin.
+ [Berechtigungen einrichten](permission-setup.md)
+ [Installieren Sie das SageMaker AI Spaces Add-on](operator-install.md)
+ [Add-on anpassen](customization.md)
+ [Fügen Sie Benutzer hinzu und richten Sie Dienstkonten ein](add-user.md)
+ [Einschränkungen](ds-limits.md)
+ [Aufgabenverwaltung für interaktive Bereiche aktiviert HyperPod](task-governance.md)
+ [Beobachtbarkeit](observability.md)
## Datenwissenschaftler
+ [Bereiche erstellen und verwalten](create-manage-spaces.md)
+ [Zugriff über einen Webbrowser](browser-access.md)
+ [Fernzugriff auf SageMaker Spaces](vscode-access.md)
## SageMaker Preise für verwaltete Spaces Instances
Für den SageMaker Spaces-Add-on/Operator fallen für den Kunden keine zusätzlichen Kosten an. Um das für die *Remote-IDE-Verbindungsfunktion* erforderliche SSH-over-SSM Tunneling zu unterstützen, verwendet SageMaker Spaces jedoch eine -verwaltete Instanz. AWS Diese Instanz ist unter SSM als Advanced On-Premises Instance registriert und wird daher pro Rechenstunde abgerechnet.
[Den Tarif „On-Premise Instance Management“ finden Sie auf der Preisseite von AWS Systems Manager: AWS Systems Manager Manager-Preise: Preise/ https://aws.amazon.com/systems-manager/](https://aws.amazon.com/systems-manager/pricing.com)
# Berechtigungen einrichten
## Erforderliche Rollen für das Add-on und seine Abhängigkeiten
### Für SageMaker Spaces on sind IAM-Rollen erforderlich SageMaker HyperPod
Bei der Aktivierung **von SageMaker Spaces-Funktionen (**auch bekannt als **SageMaker IDE/Notebooks)** auf einem SageMaker HyperPod (EKS) -Cluster müssen mehrere IAM-Rollen erstellt und zugewiesen werden. Diese Rollen unterstützen sicheren Zugriff, Routing, Remote-IDE-Sitzungen und EBS-Speicherbereitstellung. In der folgenden Tabelle werden die vier Rollen zusammengefasst und angegeben, wann sie benötigt werden.
### Tabelle mit der Zusammenfassung der Rollen
| IAM Role (IAM-Rolle) | Erforderlich? | Zweck | Wer benutzt sie? | Ist eine Anpassung über die SageMaker Konsole zulässig? |
| --- | --- | --- | --- | --- |
| Ausführungsrolle des Spaces-Add-ons | Immer erforderlich | Ermöglicht dem Spaces-Controller, Spaces zu verwalten, vorsignierte SSM-Sitzungen zu generieren URLs und zu verwalten | Zusätzlicher Controller-Pod (privilegiert) | ✔ Ja |
| Rolle des Routers im Cluster | Für den WebUI-Zugriff erforderlich | Ermöglicht dem Router-Pod die Ausführung von KMS-Vorgängen für die JWT-Signatur WebUI WebUI-Authentifizierung) | Router-Pod im Cluster (privilegiert) | ✔ Ja |
| Rolle „Verwaltete SSM-Instanz“ | Für den IDE-Remote-Zugriff erforderlich | Wird vom SSM-Agent-Sidecar für SSH-over-SSM Remote-IDE-Sitzungen verwendet | SSM-Agent in Space IDE-Pods (kein Add-On-Pod) | ✔ Ja |
| IAM-Rolle für das EBS CSI-Treiber-Add-on | Immer erforderlich | Ermöglicht es dem EBS CSI-Treiber, create/attach/modify Volumes für Spaces-Workloads zu verwenden | EBS CSI-Treiber-Add-on | Automatisch erstellt |
| IAM-Rolle für externes DNS-Add-on | Für den WebUI-Zugriff erforderlich | Es stellt sicher, dass Space-Endpunkten und Cluster-Komponenten in den von Route 53 gehosteten Zonen des Kunden automatisch DNS-Namen zugewiesen werden können. | Externes DNS-Addon | Automatisch erstellt |
### 1. Ausführungsrolle für das Spaces-Add-on (erforderlich)
Die Spaces-Add-On-Ausführungsrolle ist immer erforderlich, da sie vom SageMaker Spaces-Add-on-Controller-Pod verwendet wird, einer Verwaltungskomponente, die über das EKS-Add-on installiert wird. Diese Rolle ermöglicht es dem Controller, Spaces zu verwalten, Ressourcen bereitzustellen, mit SSM zu interagieren und vordefinierte Generierungen sowohl URLs für den Remote-IDE- als auch für den WebUI-Zugriff zu generieren. Es unterstützt auch den KMS-Zugriff, der für das Signieren von Anfragen zur Authentifizierung der WebUI-HTTPS-Anfragen verwendet wird. Diese Rolle kann automatisch erstellt werden, wenn das SageMaker Spaces-Add-on über die Konsole installiert wird. SageMaker AWS Stellt die `AmazonSageMakerSpacesControllerPolicy` verwaltete Richtlinie für die manuelle Erstellung bereit.
**Referenz-Vertrauensrichtlinie**
```
{
"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. Router-Rolle im Cluster (für die WebUI-Authentifizierung erforderlich)
Die In-Cluster-Router-Rolle wird vom **Router-Pod** verwendet, einer privilegierten Komponente, die Spaces-WebUI-Sitzungen authentifiziert. Der Router verwendet einen KMS-Schlüssel, um JWT-Token zu erstellen und zu signieren, die den Benutzerzugriff auf bestimmte Spaces autorisieren. Diese Rolle ermöglicht es dem Router-Pod, Datenschlüssel zu generieren und diese zu entschlüsseln. Ähnlich wie bei der Controller-Rolle setzt sie die Sicherheit mithilfe von tag- und clusterbasierten Bereichsbeschränkungen durch. Diese Rolle kann automatisch generiert werden, wenn das Spaces-Add-on über die AWS SageMaker Konsole installiert wird. Kunden können sie jedoch auch manuell erstellen.
**Verweise auf die Vertrauensrichtlinie**
```
{
"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}}"
}
}
}
]
}
```
**Referenzrichtlinie für Genehmigungen**
```
{
"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. Rolle „Verwaltete SSM-Instanz“ (für IDE-Remotezugriff erforderlich)
Die Rolle der verwalteten SSM-Instanz wird bei der Registrierung der verwalteten SSM-Instanz zur Aktivierung des IDE-Remotezugriffs übergeben. Diese Rolle ermöglicht es dem SSM-Agenten, den Pod als verwaltete SSM-Instanz zu registrieren und die SSM Session Manager-Kanäle für die Remote-IDE-Konnektivität (SSH-over-SSM) zu verwenden. Sie kann bei Verwendung der Konsole automatisch erstellt werden. AWS SageMaker Für manuelle Bereitstellungen müssen Kunden diese Rolle erstellen und sie dem Spaces-Add-on zur Verfügung stellen. Der Controller-Pod selbst übernimmt diese Rolle nicht; er stellt sie nur bei Aufrufen `ssm:CreateActivation` bereit.
**Verweise auf die Vertrauensrichtlinie**
```
{
"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}}:*"
}
}
}
]
}
```
**Referenzrichtlinie für Genehmigungen**
```
{
"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. IAM-Rolle für das EBS CSI-Treiber-Add-on
Die IAM-Rolle für den EBS-CSI-Treiber ist erforderlich, da der EBS CSI-Treiber persistente Volumes für Spaces-Workloads bereitstellt. Während die von [Amazon AWS verwaltete EBSCSIDriver Richtlinie](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEBSCSIDriverPolicy.html) grundlegende Berechtigungen vorsieht, benötigen SageMaker HyperPod Cluster [zusätzliche Funktionen](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-eks-ebs.html#sagemaker-hyperpod-eks-ebs-setup) wie die Erstellung schneller Snapshot-Wiederherstellungen, das Markieren von Cluster-eigenen Volumes und attaching/detaching Volumes für -verwaltete Knoten. HyperPod Zu diesen Berechtigungen gehören auch spezifische Berechtigungen wie. SageMaker APIs `sagemaker:AttachClusterNodeVolume` Wenn der EBS CSI-Treiber nicht installiert ist, wird diese Rolle jetzt bei der Installation des Spaces-Add-ons automatisch von der SageMaker Konsole erstellt, **sodass kein Eingreifen des Kunden erforderlich** ist.
### 5. IAM-Rolle für das externe DNS-Add-on
Das externe DNS-Add-on verwaltet DNS-Einträge für Dienste und Eingangsressourcen auf dem HyperPod Cluster. Es stellt sicher, dass Space-Endpunkten und Cluster-Komponenten in den von Route 53 gehosteten Zonen des Kunden automatisch DNS-Namen zugewiesen werden können. Heutzutage installieren Kunden External DNS häufig manuell über eine 1-Klick-Option in der EKS-Konsole. Im Rahmen der Verbesserung der SageMaker Spaces-Erfahrung wird diese Rolle nun bei der Installation des Spaces-Add-ons automatisch von der SageMaker Konsole erstellt, **sodass kein Eingreifen des Kunden erforderlich** ist.
## Einrichtung der Berechtigungen für den Zugriff auf SageMaker Spaces für das AWS Toolkit
Damit der Seitenbereich des Ressourcen-Explorers von AWS VS Code Toolkit Spaces erkennen und eine Verbindung zu SageMaker Spaces herstellen kann, sind die folgenden IAM-Berechtigungen erforderlich. Diese Berechtigungen ermöglichen es dem Toolkit, verfügbare SageMaker HyperPod Cluster aufzulisten, Cluster-Details abzurufen und ein Verbindungstoken für den zugehörigen Amazon EKS-Cluster abzurufen.
**Erforderliche IAM-Richtlinie**
```
{
"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": "*"
}
]
}
```
**Empfehlungen zur Festlegung des Geltungsbereichs**
+ Ersetzen Sie den Clusternamen durch die spezifischen SageMaker HyperPod Cluster, auf die Ihre Benutzer zugreifen müssen.
+ Die GetToken Aktion eks: unterstützt derzeit keine Einschränkungen auf Ressourcenebene und muss Resource: „\$1“ verwenden. Dies ist eine AWS Dienstbeschränkung. Die clientseitige Authentifizierung erfolgt über [EKS-Zugriffseinträge](https://docs.aws.amazon.com/eks/latest/userguide/access-entries.html).
# Installieren Sie das SageMaker AI Spaces Add-on
## Abhängigkeiten
**Zusatzmodul Amazon EKS Pod Identity Agent**
+ Erforderlich, damit der Betreiber AWS Anmeldeinformationen abrufen kann
+ **In der Regel auf den meisten EKS-Clustern vorinstalliert**
+ Installation: Über EKS-Add-Ons
**CERT-Manager**
+ Erforderlich für die Verwaltung von TLS-Zertifikaten
+ **Vorinstalliert**, wenn HyperPod Quick Cluster Create verwendet wird
+ Installation: Über EKS-Add-Ons
**EBS CSI-Treiber**
+ Erforderlich für persistenten Space-Speicher (EBS-Volumes)
+ Wird **automatisch installiert**, wenn die Installation über die SageMaker Konsole erfolgt
+ Erfordert eine IAM-Rolle mit `AmazonEBSCSIDriverPolicy` \$1 HyperPod -spezifischen Berechtigungen
+ Installation: Über EKS-Add-Ons. Folgen Sie jedoch unbedingt der Anleitung, um zusätzliche Berechtigungen zu installieren, die für erforderlich sind HyperPod.
+ Referenz: [Verwenden des Amazon EBS CSI-Treibers](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-eks-ebs.html) auf HyperPod
## Zusätzliche Abhängigkeiten für WebUI Access
**AWS Load Balancer Balancer-Controller**
+ **Vorinstalliert**, wenn HyperPod Quick Cluster Create verwendet wird
+ Installation: Über Helm
+ Manuelle Installationsanleitung: [Installation des AWS Load Balancer Controllers](https://docs.aws.amazon.com/eks/latest/userguide/lbc-helm.html)
**Externes DNS**
+ Erforderlich, wenn eine benutzerdefinierte Domain für den WebUI-Zugriff verwendet wird
+ Verwaltet Route53-DNS-Einträge automatisch
+ Erfordert eine IAM-Rolle mit Route53-Berechtigungen
+ Installation: Über EKS-Add-Ons
## Installation
Bevor Sie beginnen, stellen Sie sicher, dass Sie über Folgendes verfügen:
+ Ein aktiver SageMaker HyperPod Cluster mit mindestens einem Worker-Knoten, auf dem Kubernetes Version 1.30 oder höher ausgeführt wird
+ Mindestens ein Worker-Knoten mit minimalem Instanztyp (XX vCPU, YY GiB Arbeitsspeicher)
### Installation des Amazon SageMaker Spaces-Add-ons
Sie können das SageMaker Spaces-Add-on entweder mit der Schnellinstallation für die Standardeinstellungen oder mit der benutzerdefinierten Installation für die erweiterte Konfiguration installieren.
#### Schnelle Installation
1. Öffnen Sie die SageMaker Amazon-Konsole unter [https://console.aws.amazon.com/sagemaker/](https://console.aws.amazon.com/sagemaker/).
1. Wählen Sie Ihren Cluster aus der Cluster-Liste aus.
1. Suchen Sie auf der Registerkarte IDE und Notebooks nach Amazon SageMaker Spaces und wählen Sie dann Schnellinstallation.
Automatische Schnellinstallation:
+ Erstellt die erforderlichen IAM-Rollen für das Add-on
+ Aktiviert den Fernzugriffsmodus mit den erforderlichen IAM-Rollen für Systems Manager
+ Installiert das Add-on und konfiguriert die Pod-Identitätszuweisung
#### Benutzerdefinierte Installation
1. Öffnen Sie die SageMaker Amazon-Konsole unter [https://console.aws.amazon.com/sagemaker/](https://console.aws.amazon.com/sagemaker/).
1. Wählen Sie Ihren Cluster aus der Cluster-Liste aus.
1. Suchen Sie auf der Registerkarte IDE und Notebooks nach Amazon SageMaker Spaces und wählen Sie dann Benutzerdefinierte Installation.
1. Konfigurieren Sie die folgenden Optionen:
**IAM-Rollen, die vom Add-On benötigt werden**
+ Wählen Sie aus, ob Sie neue IAM-Rollen mit den empfohlenen Berechtigungen erstellen oder bestehende Rollen mit den erforderlichen Berechtigungen verwenden möchten (siehe Abschnitt Einrichtung von Administratorberechtigungen oben)
**Konfiguration des Fernzugriffs**
+ Aktivieren Sie diese Option, damit Benutzer mithilfe von AWS Systems Manager eine Verbindung zu Bereichen aus lokalem Visual Studio Code herstellen können
+ Für die Rolle „Verwaltete SSM-Instanz“:
+ **Neue Rolle erstellen** — Das Add-on erstellt und verwaltet die Rolle mit den erforderlichen Systems Manager Manager-Berechtigungen
+ **Bestehende Rolle verwenden** — Wählen Sie eine vorkonfigurierte Rolle mit den erforderlichen Systems Manager Manager-Berechtigungen
+ Stellen Sie sicher, dass die Spaces Add-on-Ausführungsrolle über PassRole Berechtigungen für die Rolle der verwalteten SSM-Instanz verfügt
**Anmerkung**
Durch die Aktivierung des Fernzugriffs wird die Advanced-Instance-Stufe von AWS Systems Manager gegen zusätzliche Gebühren pro Instanz aktiviert. Preisinformationen finden Sie unter Systems Manager Manager-Preise.
**Konfiguration des Webbrowser-Zugriffs**
+ Aktivieren Sie diese Option, um Benutzern den Zugriff auf Bereiche über einen Webbrowser mithilfe von Route 53 53-DNS- und SSL-Zertifikaten zu ermöglichen
+ **Voraussetzungen:** Installieren Sie den AWS Load Balancer Controller, bevor Sie den Browserzugriff aktivieren
+ **Route 53 53-Hosting-Zone:** Wählen Sie eine bestehende Hosting-Zone für eine Domain oder Subdomain aus, die Sie besitzen. Die Domain oder Subdomain muss registriert sein und sich unter Ihrer Kontrolle befinden, um die DNS-Verwaltung und die SSL-Zertifikatsvalidierung zu aktivieren.
Weitere Informationen zur Domainregistrierung finden Sie unter [Registrierung einer neuen Domain](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/domain-register.html#domain-register-procedure-section) im Route 53 Developer Guide.
+ **Subdomain:** Geben Sie das Subdomain-Präfix ein (nur alphanumerische Zeichen und Bindestriche, maximal 63 Zeichen)
+ **SSL-Zertifikat:** Wählen Sie ein vorhandenes SSL-Zertifikat aus dem AWS Certificate Manager aus. Das Zertifikat muss gültig sein und sowohl Ihre Subdomain (z. B. subdomain.domain.com) als auch Wildcard-Unterdomänen (z. B. \$1.subdomain.domain.com) abdecken, um den individuellen Speicherzugriff zu unterstützen. URLs
+ **Token-Signaturschlüssel: Wählen Sie einen asymmetrischen KMS-Schlüssel für die JWT-Tokensignierung** aus. AWS Der Schlüssel wird verwendet, um Authentifizierungstoken für einen sicheren WebUI-Zugriff zu verschlüsseln. Sie können einen neuen asymmetrischen Schlüssel in KMS erstellen oder einen vorhandenen auswählen, auf den Ihr Konto Zugriff hat.
**Anmerkung**
Für gehostete Zonen und DNS-Abfragen fallen Standardroute 53-Gebühren an. Preisinformationen finden Sie unter Route 53 53-Preise.
#### Installation des EKS-Addons - Jupyter K8s mit WebUI
##### Konfigurationsdatei
Erstellen: `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: ""
```
**Ersetze die folgenden Platzhalter:**
+ : Ihr Domainname (z. B.`jupyter.example.com`)
+ : Ihr ACM-Zertifikat ARN (z. B. `arn:aws:acm:us-west-2:111122223333:certificate/12345678-1234-1234-1234-123456789012`
+ : Ihr KMS-Schlüssel-ARN (z. B. `arn:aws:kms:us-west-2:111122223333:key/12345678-1234-1234-1234-123456789012`
##### Installation über AWS CLI
```
aws eks create-addon \
--cluster-name \
--addon-name amazon-sagemaker-spaces \
--configuration-values file://addon-config.yaml \
--resolve-conflicts OVERWRITE \
--region
```
**Um ein vorhandenes Addon zu aktualisieren:**
```
aws eks update-addon \
--cluster-name \
--addon-name amazon-sagemaker-spaces \
--configuration-values file://addon-config.yaml \
--resolve-conflicts OVERWRITE \
--region
```
##### Installation über AWS-Managementkonsole
1. Gehen Sie zur **EKS-Konsole** → Wählen Sie Ihren Cluster
1. Klicken Sie auf den Tab **Add-Ons** → **Neu hinzufügen**
1. Wählen Sie das **SageMaker Spaces-Addon**
1. Fügen Sie die obige YAML-Konfiguration in **Optionale** Konfigurationseinstellungen ein
1. Klicken Sie auf **Weiter** und überprüfen Sie dann die Addon-Einstellungen
1. **Klicken Sie auf Erstellen**
##### Überprüfen Sie die Installation
```
# Check addon status
aws eks describe-addon \
--cluster-name \
--addon-name amazon-sagemaker-spaces \
--region
```
##### Anpassen von ALB-Attributen
Standardmäßig erstellt das Addon einen öffentlichen Load Balancer für die Verwendung mit der Weboberfläche. Sie können die Load Balancer-Attribute mithilfe der EKS-Addoneigenschaften anpassen.
Um ein internes ALB zu erstellen, stellen Sie das Schema wie folgt ein: `internal`
```
jupyter-k8s-aws-hyperpod:
clusterWebUI:
enabled: true
domain: ""
awsCertificateArn: ""
alb:
scheme: "internal" # Default is "internet-facing"
```
Sie können das `alb.annotations` Feld auch verwenden, um die ALB-Einstellungen anzupassen:
```
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"
```
**Allgemeine ALB-Anmerkungen:**
+ `alb.ingress.kubernetes.io/security-groups`: Geben Sie Sicherheitsgruppen für das ALB an
+ `alb.ingress.kubernetes.io/subnets`: Geben Sie Subnetze für das ALB an
+ `alb.ingress.kubernetes.io/load-balancer-attributes`: Legt ALB-Attribute fest (Leerlauf-Timeout, Zugriffsprotokolle usw.)
Alle verfügbaren Anmerkungen finden Sie in der [AWS Load Balancer Controller-Dokumentation](https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/guide/ingress/annotations/).
### Upgrade/Versionierung des Add-ons
```
aws eks update-addon \
--cluster-name \
--addon-name amazon-sagemaker-spaces \
--configuration-values file://addon-config.yaml \
--resolve-conflicts OVERWRITE \
--region
```
# Add-on anpassen
## Vorlage
Vorlagen sind wiederverwendbare Workspace-Konfigurationen, die als vom Administrator gesteuerte Blueprints für die Erstellung von Arbeitsbereichen dienen. Sie bieten Standardwerte für Workspace-Konfigurationswerte und Richtlinien, mit denen gesteuert werden kann, was Datenwissenschaftler tun können. Vorlagen existieren auf Clusterebene und können in verschiedenen Namespaces wiederverwendet werden.
SageMaker Spaces erstellt zwei Systemvorlagen als Ausgangspunkt für Datenwissenschaftler, eine für den Code-Editor und eine für. JupyterLab Diese Systemvorlagen werden vom Addon verwaltet und können nicht direkt bearbeitet werden. Stattdessen können Admins neue Vorlagen erstellen und diese als Standard festlegen.
## Verwaltung von Aufgaben
```
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//Benutzerdefinierte Bilder
Kunden können Image-Richtlinien mithilfe von Vorlagen konfigurieren, indem sie ein Standard-Image und eine Liste der zulässigen Images bereitstellen. Darüber hinaus können Administratoren wählen, ob Datenwissenschaftler ihre eigenen benutzerdefinierten Images mitbringen dürfen. Das System verwendet standardmäßig die neueste SageMaker Distribution. Wenn Sie sich jedoch an eine bestimmte Version binden möchten, können Sie die genaue SMD-Version angeben, die in einer Vorlage verwendet werden soll.
Anforderungen an benutzerdefinierte Bilder:
+ `curl`wenn Sie Idle Shutdown verwenden möchten
+ Port 8888
+ Remote-Zugriff
## Remote-IDE-Anforderung
### Anforderung an die VS-Code-Version
VS-Code-Version [v1.90](https://code.visualstudio.com/updates/v1_90) oder höher ist erforderlich. Wir empfehlen die [neueste stabile Version von VS Code](https://code.visualstudio.com/updates) zu verwenden.
### Anforderungen an Betriebssysteme
Sie benötigen eines der folgenden Betriebssysteme, um eine Remoteverbindung zu Studio-Bereichen herzustellen:
+ macOS 13\$1
+ Windows 10
+ [Die Unterstützung für Windows 10 endet am 14. Oktober 2025](https://support.microsoft.com/en-us/windows/windows-10-support-ends-on-october-14-2025-2ca8b313-1946-43d3-b55c-2b95b107f281)
+ Windows 11
+ Linux
+ Installieren Sie den offiziellen [Microsoft VS Code für Linux](https://code.visualstudio.com/docs/setup/linux)
+ keine Open-Source-Version
### Voraussetzungen für lokale Maschinen
Bevor Sie Ihren lokalen Visual Studio-Code mit Studio Spaces verbinden, stellen Sie sicher, dass Ihr lokaler Computer über die erforderlichen Abhängigkeiten und den erforderlichen Netzwerkzugriff verfügt.
**Anmerkung**
Umgebungen mit Einschränkungen bei der Softwareinstallation können Benutzer daran hindern, die erforderlichen Abhängigkeiten zu installieren. Das AWS Toolkit for Visual Studio Code sucht beim Initiieren von Remoteverbindungen automatisch nach diesen Abhängigkeiten und fordert Sie zur Installation auf, falls diese fehlen. Stimmen Sie sich mit Ihrer IT-Abteilung ab, um sicherzustellen, dass diese Komponenten verfügbar sind.
**Erforderliche lokale Abhängigkeiten**
Auf Ihrem lokalen Computer müssen die folgenden Komponenten installiert sein:
+ **[https://code.visualstudio.com/docs/remote/ssh](https://code.visualstudio.com/docs/remote/ssh)**
+ — Standard-VS Code Marketplace-Erweiterung für die Fernentwicklung
+ **[Session Manager-Plugin](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-working-with-install-plugin.html)** — Für eine sichere Sitzungsverwaltung erforderlich
+ **SSH-Client** — Standardkomponente auf den meisten Maschinen ([OpenSSH wird für Windows empfohlen](https://learn.microsoft.com/en-us/windows-server/administration/openssh/openssh_install_firstuse))
+ **[https://code.visualstudio.com/docs/configure/command-line](https://code.visualstudio.com/docs/configure/command-line)**
+ In der Regel in der VS Code-Installation enthalten
**Plattformspezifische Anforderungen**
+ **Windows-Benutzer** — PowerShell 5.1 oder höher ist für SSH-Terminalverbindungen erforderlich
**Anforderungen an die Netzwerkkonnektivität**
Ihr lokaler Computer muss Netzwerkzugriff auf die [Session Manager-Endpunkte](https://docs.aws.amazon.com/general/latest/gr/ssm.html) haben. In USA Ost (Nord-Virginia) (us-east-1) können dies beispielsweise sein:
+ `[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)`
### Anforderungen an Images
**SageMaker Bilder zur Verteilung**
Wenn Sie SageMaker Distribution mit Fernzugriff verwenden, verwenden Sie [SageMaker Distribution](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-distribution.html) Version 2.7 oder höher.
**Benutzerdefinierte Bilder**
Wenn Sie [Bring Your Own Image (BYOI)](https://docs.aws.amazon.com/sagemaker/latest/dg/studio-updated-byoi.html) mit Fernzugriff verwenden, stellen Sie sicher, dass Sie die [benutzerdefinierten Image-Spezifikationen](https://docs.aws.amazon.com/sagemaker/latest/dg/studio-updated-byoi-specs.html) einhalten und dass die folgenden Abhängigkeiten installiert sind:
+ `curl`oder `wget` — Erforderlich für das Herunterladen von Komponenten AWS CLI
+ `unzip`— Erforderlich für das Extrahieren von AWS CLI Installationsdateien
+ `tar`— Für das Extrahieren von Archiven erforderlich
+ `gzip`— Erforderlich für die Handhabung komprimierter Dateien
### Instance-Anforderungen
+ **Arbeitsspeicher**: 8 GB oder mehr
+ Verwenden Sie Instanzen mit mindestens 8 GB Arbeitsspeicher. Die folgenden Instance-Typen werden aufgrund unzureichenden Speichers (weniger als 8 GB) *nicht* unterstützt: `ml.t3.medium`, `ml.c7i.large`, `ml.c6i.large`, `ml.c6id.large` und `ml.c5.large`. Eine vollständigere Liste der Instance-Typen finden Sie auf der Seite [Amazon EC2 On-Demand-Preise](https://aws.amazon.com/ec2/pricing/on-demand/)
## Optimierung der Kubernetes-Startzeit durch Vorwärmen von Container-Images
Die Leistung beim Abrufen von Container-Images ist für viele EKS-Kunden zu einem erheblichen Engpass geworden, insbesondere da AI/ML Workloads auf immer größere Container-Images angewiesen sind. Das Ziehen und Entpacken dieser großen Images dauert in der Regel mehrere Minuten, wenn sie zum ersten Mal auf jedem EKS-Knoten verwendet werden. Diese Verzögerung erhöht die Latenz beim Start von SageMaker Spaces erheblich und wirkt sich direkt auf die Benutzererfahrung aus — insbesondere in Umgebungen, in denen ein schneller Start unerlässlich ist, wie Notebooks oder interaktive Entwicklungsjobs.
Bei der Image-Vorwärmung handelt es sich um eine Technik, mit der bestimmte Container-Images vorab auf jeden Knoten im EKS/HyperPod Cluster geladen werden, bevor sie benötigt werden. Anstatt darauf zu warten, dass ein Pod den ersten Abruf eines großen Images auslöst, lädt der Cluster proaktiv Bilder herunter und speichert sie zwischen allen Knoten. Dadurch wird sichergestellt, dass beim Start von Workloads die erforderlichen Images bereits lokal verfügbar sind, wodurch lange Kaltstartverzögerungen vermieden werden. Das Vorwärmen von Bildern verbessert die Startgeschwindigkeit von SageMaker Spaces und sorgt für ein vorhersehbareres und reaktionsschnelleres Erlebnis für Endbenutzer.
### Vorwärmen über DaemonSet
Wir empfehlen die Verwendung von a DaemonSet zum Vorladen von Bildern. A DaemonSet stellt sicher, dass auf jedem Knoten im Cluster ein Pod ausgeführt wird. Jeder Container im DaemonSet Pod verweist auf ein Bild, das Sie zwischenspeichern möchten. Wenn Kubernetes den Pod startet, werden die Bilder automatisch abgerufen, wodurch der Cache auf jedem Knoten erwärmt wird.
Das folgende Beispiel zeigt, wie Sie einen erstellen, der zwei DaemonSet GPU-Images vorab lädt. Jeder Container führt einen einfachen `sleep infinity` Befehl aus, um den Pod bei minimalem Overhead aktiv zu halten.
```
cat <
+ Jeder Container referenziert ein Bild.
+ Kubernetes muss jedes Image herunterladen, bevor der Container gestartet wird.
+ Sobald der Pod auf jedem Knoten ausgeführt wird, werden die Bilder lokal zwischengespeichert.
+ Jeder Workload, der diese Images verwendet, startet jetzt viel schneller.
## Space Default Storage (EBS)
Das System verwendet standardmäßig den EBS-CSI-Treiber, um EBS-Speicher-Volumes für jeden Workspace bereitzustellen. SageMaker erstellt eine EBS-Speicherklasse für die Verwendung mit Workspaces, und Administratoren können die Standard- und Maximalgröße dieser Volumes mithilfe von Vorlageneinstellungen anpassen. Für fortgeschrittene Benutzer, die mit CLI-Tools arbeiten, können Sie auch die Speicherklasse des Workspace anpassen, sodass Benutzer andere Speicherklassen nutzen können, einschließlich der Konfiguration von kundenverwalteten KMS-Schlüsseln für ihre EBS-Volumes.
Beachten Sie, dass EBS-Volumes an eine bestimmte AZ gebunden sind, was bedeutet, dass Workspaces nur auf Knoten geplant werden können, die sich in derselben AZ wie ihr Speichervolume befinden. Dies kann zu Planungsfehlern führen, wenn Clusterkapazität vorhanden ist, aber nicht in der richtigen AZ.
## Zusätzlicher Speicher
SageMaker Spaces unterstützt das Anhängen zusätzlicher Speichervolumes wie Amazon EFS, FSx for Lustre oder S3 Mountpoint an Ihre Entwicklungsbereiche. Auf diese Weise können Sie auf gemeinsam genutzte Datensätze zugreifen, an Projekten zusammenarbeiten oder Hochleistungsspeicher für Ihre Workloads verwenden.
### Voraussetzungen
Bevor Sie Spaces zusätzlichen Speicherplatz hinzufügen, müssen Sie:
1. **Installieren Sie das entsprechende CSI-Treiber-Add-on** über [EKS-Add-Ons](https://docs.aws.amazon.com/eks/latest/userguide/workloads-add-ons-available-eks.html) (Amazon EFS CSI Driver, Amazon FSx for Lustre CSI Driver oder Mountpoint for Amazon S3 CSI Driver)
1. **Richten Sie Speicherressourcen ein und PersistentVolumeClaims befolgen** Sie die CSI-Treiber-Dokumentation für Ihren spezifischen Speichertyp
1. **Stellen Sie sicher, dass das PVC in demselben Namespace verfügbar ist**, in dem Sie Ihren Bereich einrichten möchten
### Speicher an Räume anhängen
Sobald Sie eine PersistentVolumeClaim konfiguriert haben, können Sie sie entweder über die HyperPod CLI oder kubectl an einen Space anhängen.
**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
```
### Mehrere Bände
Sie können mehrere zusätzliche Speichervolumes an einen einzelnen Speicherplatz anhängen, indem Sie mehrere `--volume` Flags mit der CLI oder mehrere Einträge im `volumes` Array mit kubectl angeben.
**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
```
## Konfiguration der Ressourcen
SageMaker Mit Spaces können Sie Rechenressourcen für Ihre Entwicklungsumgebungen konfigurieren, einschließlich CPU-, Arbeitsspeicher- und GPU-Ressourcen, die Ihren Workload-Anforderungen entsprechen.
### GPU-Konfiguration
SageMaker Spaces unterstützt sowohl die gesamte GPU-Zuweisung als auch die GPU-Partitionierung mithilfe der NVIDIA Multi-Instance-GPU (MIG) -Technologie. Auf diese Weise können Sie die GPU-Auslastung für verschiedene Arten von Workloads für maschinelles Lernen optimieren.
#### Vollständige GPU-Zuweisung
**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"
```
#### GPU-Partitionierung (MIG)
Die GPU-Partitionierung mithilfe der NVIDIA Multi-Instance-GPU (MIG) -Technologie ermöglicht es Ihnen, eine einzelne GPU in kleinere, isolierte Instanzen zu partitionieren. Ihr HyperPod Cluster muss über GPU-Knoten verfügen, die MIG unterstützen, und es müssen MIG-Profile konfiguriert sein. Weitere Informationen zur Einrichtung von MIG auf Ihrem HyperPod Cluster finden Sie unter [GPU-Partitionierung mit NVIDIA MIG](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-eks-gpu-partitioning-setup.html).
**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"
```
## Lebenszyklus
Die Lebenszykluskonfiguration stellt Startskripts bereit, die ausgeführt werden, wenn ein Workspace erstellt oder gestartet wird. Diese Skripts ermöglichen es Administratoren, die Workspace-Umgebung beim Start anzupassen. Dies sind Bash-Skripte mit einer maximalen Größe von 1 KB. Wenn Sie eine größere Setup-Konfiguration benötigen, empfehlen wir, dem Container-Image ein Skript hinzuzufügen und das Skript über die Lebenszykluskonfiguration auszulösen.
[Wir nutzen Kubernetes-Container-Lifecycle-Hooks, um diese Funktionalität bereitzustellen https://kubernetes. io/docs/concepts/containers/container-lifelycle-hooks/.](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/) Beachten Sie, dass Kubernetes keine Garantie dafür gibt, wann das Startskript in Bezug auf den Einstiegspunkt des Containers ausgeführt wird.
## Herunterfahren im Leerlauf
Konfigurieren Sie das automatische Herunterfahren inaktiver Workspaces, um die Ressourcennutzung zu optimieren.
### Herunterfahren im Leerlauf
```
idleShutdown:
enabled: true
idleShutdownTimeoutMinutes: 30
detection:
httpGet:
path: /api/idle
port: 8888
scheme: HTTP
```
### Parameters
**enabled** (boolean, required) — Aktiviert oder deaktiviert das Herunterfahren im Leerlauf für den Workspace.
**idleShutdownTimeoutMinuten** (Ganzzahl, erforderlich) — Anzahl der Minuten der Inaktivität, bevor der Workspace heruntergefahren wird. Der Mindestwert ist 1.
**detection** (object, required) — Definiert, wie der Ruhezustand eines Workspace erkannt wird.
**Detection.HttpGet** (Objekt, optional) — HTTP-Endpunktkonfiguration für die Erkennung von Leerlauf. Verwendet die Kubernetes Action-Spezifikation. HTTPGet
+ **path** — HTTP-Pfad zur Anfrage
+ **port** — Portnummer oder Name
+ **Schema** — HTTP oder HTTPS (Standard: HTTP)
### Speicherorte der Konfiguration
**Konfiguration des Arbeitsbereichs**
Definieren Sie das Herunterfahren im Leerlauf direkt in der Workspace-Spezifikation:
```
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
```
**Konfiguration der Vorlage**
Definieren Sie das Standardverhalten beim Herunterfahren im Leerlauf in einem 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
```
### Vererbung und Überschreibungen von Vorlagen
Arbeitsbereiche, die eine Vorlage verwenden, erben automatisch die Konfiguration der Vorlage. `defaultIdleShutdown` Arbeitsbereiche können diese Konfiguration überschreiben, wenn die Vorlage dies zulässt.
**Richtlinie außer Kraft setzen**
Vorlagen steuern das Verhalten beim Außerkraftsetzen durch`idleShutdownOverrides`:
**allow** (boolean, default: true) — Ob Workspaces die Standardkonfiguration zum Herunterfahren im Leerlauf überschreiben können.
**minTimeoutMinutes**(Ganzzahl, optional) — Minimaler zulässiger Timeout-Wert für Workspace-Overrides.
**maxTimeoutMinutes**(Ganzzahl, optional) — Maximal zulässiger Timeout-Wert für Workspace-Overrides.
**Beispiel für Vererbung**
Workspace erbt die Standardeinstellungen für Vorlagen:
```
apiVersion: workspace.jupyter.org/v1alpha1
kind: Workspace
metadata:
name: my-workspace
spec:
displayName: "My Workspace"
templateRef:
name: jupyter-template
# Inherits defaultIdleShutdown from template
```
**Beispiel überschreiben**
Workspace überschreibt die Standardeinstellungen der Vorlage:
```
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
```
**Gesperrte Konfiguration**
Workspace-Überschreibungen verhindern:
```
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
```
### Behavior
Wenn das Herunterfahren im Leerlauf aktiviert ist, überprüft das System den Workspace regelmäßig anhand des konfigurierten HTTP-Endpunkts auf Aktivitäten. Wenn der Endpunkt angibt, dass der Workspace für die angegebene Timeout-Dauer inaktiv ist, stoppt der Workspace automatisch. Sie können den Workspace bei Bedarf manuell neu starten.
## Vorlagenaktualisierungen
Die Client-Tools wie Kubectl oder Hyperpod CLI und SDK können für die Verwaltung von Spaces innerhalb des EKS-Clusters verwendet werden. Administratoren können Space-Vorlagen für standardmäßige Space-Konfigurationen bereitstellen, während Datenwissenschaftler ihre integrierten Entwicklungsumgebungen anpassen können, ohne die zugrunde liegende Komplexität von Kubernetes verstehen zu müssen. Detaillierte Nutzungsanweisungen finden Sie in der CLI- und SDK-Dokumentation unter [https://sagemaker-hyperpod-cli.readthedocs.io/en/latest/index.html](https://sagemaker-hyperpod-cli.readthedocs.io/en/latest/index.html).
Administratoren können CRUD-Operationen mit Space-Vorlagen durchführen, die als Basiskonfigurationen bei der Erstellung eines Space dienen. Datenwissenschaftler können CRUD-Operationen auf Spaces ausführen und verschiedene Parameter außer Kraft setzen, einschließlich der Multi-Instanz-GPU-Profile für bestimmte Rechenknoten. Sie können die Spaces über VSCode Fernzugriff und die Weboberfläche starten, beenden und eine Verbindung zu ihnen herstellen. Wenn eine Space-Vorlage aktualisiert wird, werden alle später erstellten Spaces mit den Einstellungen in der aktualisierten Vorlage konfiguriert. Konformitätsprüfungen werden durchgeführt, wenn bestehende Spaces aktualisiert oder gestartet werden. Wenn Einstellungen außerhalb der zulässigen Grenzen liegen oder nicht übereinstimmen, können die Spaces nicht aktualisiert oder gestartet werden.
## Verwenden von hyp cli und kubectl
Der Benutzer kann mit der Hyperpod-CLI CRUD für die Vorlagen ausführen
```
### 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
```
Um benutzerdefinierte Vorlagen zu erstellen, können Sie unsere Systemvorlagen als Ausgangspunkt verwenden. Diese Vorlage funktioniert für SMD-ähnliche Bilder, kann jedoch auf der Grundlage der von Administratoren verwendeten Bilder angepasst werden.
Beispiel für eine benutzerdefinierte Vorlage: 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"
```
Beispiel für eine benutzerdefinierte Code-Editor-Vorlage:
```
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"
```
# Fügen Sie Benutzer hinzu und richten Sie Dienstkonten ein
## Feinkörnige Zutrittskontrolle — unsere Empfehlung
Benutzer werden anhand ihres Kubernetes-Benutzernamens unterschieden. Der Kubernetes-Benutzername des Benutzers ist in seinem Zugriffseintrag definiert. Um sicherzustellen, dass zwei menschliche Benutzer unterschiedliche Benutzernamen haben, gibt es zwei Optionen:
1. Empfohlen — Mehrere menschliche Benutzer können dieselbe Rolle verwenden, solange jeder Benutzer seinen eigenen eindeutigen Sitzungsnamen hat, der zwischen den Sitzungen bestehen bleibt. Standardmäßig haben Kubernetes-Benutzernamen für IAM-Rollen das folgende Format. `arn:aws:sts::{ACCOUNT_ID}:assumed-role/{ROLE_NAME}/{SESSION_NAME}` Mit dieser Standardeinstellung werden Benutzer bereits nach dem Sitzungsnamen unterschieden. Ein Administrator hat mehrere Möglichkeiten, eindeutige Sitzungsnamen pro Benutzer durchzusetzen.
+ SSO-Anmeldung — Benutzer, die die SSO-Anmeldung verwenden, haben standardmäßig einen Sitzungsnamen, der mit ihrem AWS Benutzernamen verknüpft ist
+ Zentraler Verkaufsservice für Anmeldeinformationen — Für Unternehmenskunden gibt es möglicherweise einen internen Verkaufsdienst für Anmeldeinformationen, den Benutzer anrufen können, um Anmeldeinformationen mit ihrer Identität zu erhalten.
+ Rollenbasierte Durchsetzung — IAM-Benutzer müssen ihren eigenen Sitzungsnamen `aws:username` angeben, wenn sie in Ihrer Rolle eine IAM-Rolle übernehmen. AWS-Konto Die Dokumentation dazu finden Sie hier: [https://aws.amazon.com/blogs/easily-control-naming-individualsecurity/](https://aws.amazon.com/blogs/security/easily-control-naming-individual-iam-role-sessions/) -/iam-role-sessions
1. Wenn 2 Data Scientists unterschiedliche Zugriffseinträge verwenden (unterschiedliche IAM-Rolle oder Benutzer), werden sie immer als unterschiedliche Benutzer gezählt.
**Zugangseintrag wird erstellt**
Erforderliche IAM-Richtlinie für die Rolle eines Datenwissenschaftlers:
+ `eks:DescribeCluster`
Erforderliche Richtlinien für den Zugriff
+ `AmazonSagemakerHyperpodSpacePolicy`- Auf den Namespace beschränkt, sollte DS Leerzeichen erzeugen in
+ `AmazonSagemakerHyperpodSpaceTemplatePolicy`- ist auf den Namespace „jupyter-k8s-shared“ beschränkt
## Private und öffentliche Räume
Wir unterstützen zwei Arten von Sharing-Mustern: „Öffentlich“ und „OwnerOnly“. Sowohl die Felder „AccessType“ als auch „OwnershipType“ verwenden diese beiden Werte.
+ AccessType: Auf öffentliche Bereiche kann jeder zugreifen, der über Berechtigungen im Namespace verfügt. Auf öffentliche Bereiche OwnerOnly können jedoch nur der Ersteller des Bereichs sowie Administratorbenutzer zugreifen. Administratorbenutzer werden anhand der folgenden Kriterien definiert:
+ OwnershipType: Öffentliche Bereiche können modified/deleted von jedem eingerichtet werden, der über Berechtigungen im Namespace verfügt, OwnerOnly entweder modified/deleted vom Ersteller oder vom Administrator.
Admin-Benutzer werden definiert durch:
1. Teil der `system:masters` Kubernetes-Gruppe
1. Teil der Kubernetes-Gruppe, die in der Umgebungsvariablen CLUSTER\$1ADMIN\$1GROUP im Helmdiagramm definiert ist.
Die Gruppen eines Benutzers können mithilfe von EKS-Zugriffseinträgen konfiguriert werden. Ein Bereich kann als „Öffentlich“ oder „OwnerOnly“ definiert werden, indem die Spezifikation im Objekt konfiguriert wird:
```
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
```
# Einschränkungen
Spaces werden als Pods auf HyperPod EKS-Knoten mit angeschlossenen EBS-Volumes ausgeführt. Die Anzahl der Spaces, die pro Knoten bereitgestellt werden können, ist durch AWS Infrastrukturgrenzen begrenzt.
**EBS-Volumenlimits pro Knoten**
[Referenz: \$1limits.html https://docs.aws.amazon.com/AWSEC2/ latest/UserGuide/volume](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/volume_limits.html)
EC2-Knoten haben eine maximale Anzahl von EBS-Volumes, die angehängt werden können. Da jeder Space in der Regel ein EBS-Volume verwendet, wird dadurch begrenzt, wie viele Spaces mit dediziertem EBS-Speicher auf einem einzelnen Knoten ausgeführt werden können.
**Maximale Anzahl an Pods pro Knoten HyperPod **
Referenz: [https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker- hyperpod-eks-prerequisites .html](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-eks-prerequisites.html)
Jeder HyperPod Instance-Typ unterstützt eine maximale Anzahl von Pods auf der Grundlage der verfügbaren IP-Adressen aus dem VPC CNI-Plugin. Da jeder Space als Pod ausgeführt wird, begrenzt dies direkt die Anzahl der Spaces pro Knoten.
**Auswirkung**
Die effektive Grenze für Spaces pro Knoten ist die Beschränkung, die zuerst erreicht wird.
# Aufgabenverwaltung für interaktive Bereiche aktiviert HyperPod
In diesem Abschnitt wird beschrieben, wie Sie Ihre gemeinsam genutzten Amazon SageMaker HyperPod EKS-Cluster für Interactive Spaces-Workloads optimieren können. Sie lernen, die Aufgabenverwaltungsfunktionen von Kueue — einschließlich Quotenverwaltung, Prioritätsplanung und Richtlinien für die gemeinsame Nutzung von Ressourcen — zu konfigurieren, um sicherzustellen, dass Ihre Entwicklungs-Workloads ohne Unterbrechung laufen und gleichzeitig eine faire Verteilung der Schulungs-, Evaluierungs- und Batch-Verarbeitungsaktivitäten Ihrer Teams gewährleistet wird.
## So funktioniert Interactive Space Management
Um interaktive Bereiche in gemeinsam genutzten HyperPod EKS-Clustern effektiv zu verwalten, implementieren Sie die folgenden Strategien zur Aufgabenverwaltung unter Verwendung der vorhandenen Funktionen von Kueue.
**Konfiguration der Prioritätsklasse**
Definieren Sie spezielle Prioritätsklassen für interaktive Bereiche mit hoher Gewichtung (z. B. 100), um sicherzustellen, dass Entwicklungs-Pods vor anderen Aufgabentypen zugelassen und geplant werden. Diese Konfiguration ermöglicht es Interactive Spaces, Jobs mit niedrigerer Priorität beim Laden des Clusters zu verhindern, was für die Aufrechterhaltung unterbrechungsfreier Entwicklungsabläufe entscheidend ist.
**Größe und Zuteilung von Kontingenten**
Reservieren Sie ausreichend Rechenressourcen in Ihrem Team, um die erwarteten Entwicklungsworkloads ClusterQueue zu bewältigen. In Zeiten, in denen Entwicklungsressourcen ungenutzt sind, können ungenutzte Quotenressourcen vorübergehend den Aufgaben anderer Teams zugewiesen werden. Wenn der Entwicklungsbedarf steigt, können diese geliehenen Ressourcen zurückgewonnen werden, um ausstehende Interactive Space-Pods zu priorisieren.
**Strategien zur gemeinsamen Nutzung von Ressourcen**
Wählen Sie zwischen zwei Anwesungen zur Aufteilung der Kontingente, die Ihren Anforderungen entsprechen:
*Strikte Ressourcenkontrolle*: Deaktivieren Sie das Ausleihen und Ausleihen von Kontingenten, um sicherzustellen, dass reservierte Rechenkapazität für Ihre Interactive Spaces immer verfügbar ist. Dieser Ansatz erfordert, dass die Kontingente groß genug sind, um Spitzenlasten bei der Entwicklung selbstständig bewältigen zu können. Dies kann dazu führen, dass Knoten in Zeiten geringer Auslastung inaktiv sind.
*Flexible gemeinsame Nutzung von Ressourcen*: Aktivieren Sie die Quotenausleihe, damit andere Teams bei Bedarf ungenutzte Entwicklungsressourcen nutzen können. Deaktivieren Sie jedoch die Ausleihe, um sicherzustellen, dass Interactive Spaces niemals mit geliehenen, zurückforderbaren Ressourcen ausgeführt wird, was zu unerwarteten Räumungen führen könnte.
**Teaminterne Präemption**
Aktivieren Sie die teaminterne Sperrung, wenn gemischte Workloads (Schulung, Evaluierung und interaktive Bereiche) unter demselben Kontingent ausgeführt werden. Auf diese Weise kann Kueue Aufgaben mit niedrigerer Priorität innerhalb Ihres Teams vorwegnehmen, um Interactive Space-Pods mit hoher Priorität unterzubringen. So wird sichergestellt, dass die Entwicklungsarbeit fortgesetzt werden kann, ohne auf externe Quoten angewiesen zu sein.
## Beispiel für eine Einrichtung von Interactive Space
Das folgende Beispiel zeigt, wie Kueue Rechenressourcen für Interactive Spaces in einem gemeinsam genutzten SageMaker HyperPod Amazon-Cluster verwaltet.
**Cluster-Konfiguration und Einrichtung von Richtlinien**
Ihr Cluster hat die folgende Konfiguration:
+ *Team Alpha (Entwicklungsteam)*: Quote von 8 CPUs für Interactive Spaces
+ *Team Beta (ML-Team)*: Kontingent von 16 CPUs für Training und Evaluierung
+ *Team Gamma (Forschung)*: Quote von 6 CPUs für Experimente
+ *Statische Bereitstellung*: Keine automatische Skalierung
+ *Gesamtkapazität*: 30 CPUs
Der gemeinsam genutzte CPU-Pool verwendet diese Prioritätsrichtlinie:
+ *Interaktive Bereiche*: Priorität 100
+ *Schulung*: Priorität 75
+ *Bewertung*: Priorität 50
+ *Stapelverarbeitung*: Priorität 25
Kueue setzt Teamkontingente und Prioritätsklassen durch, wobei Preemption aktiviert und Borlowing für das Entwicklerteam deaktiviert ist.
**Ausgangszustand: Normale Clusterauslastung**
Im Normalbetrieb:
+ *Team Alpha*: Führt 6 interaktive Bereiche mit 6 aus CPUs, davon 2 CPUs im Leerlauf
+ *Team Beta*: Führt Trainingsjobs (12 CPUs) und Evaluierungsaufgaben (4 CPUs) innerhalb des Kontingents von 16 CPUs aus
+ *Team Gamma*: Führt Forschungs-Workloads auf allen 6 aus CPUs
+ *Gemeinsame Nutzung von Ressourcen*: Team Beta leiht sich die 2 Idle von Team Alpha CPUs für zusätzliche Schulungen
**Entwicklungsschub: Team Alpha benötigt zusätzliche Ressourcen**
Wenn die Entwickler von Team Alpha die Entwicklungsarbeit ausweiten müssen, benötigen zusätzliche Interactive Space-Pods 4 weitere CPUs. Kueue stellt fest, dass es sich bei den neuen Pods um:
+ Im Namespace von Team Alpha
+ Priorität 100 (Interaktive Bereiche)
+ Aufgrund von Quotenbeschränkungen steht die Zulassung noch aus
**Der Antwortprozess von Kueue**
Kueue folgt einem dreistufigen Prozess zur Zuweisung von Ressourcen:
1. **Kontingentprüfung**
Frage: Hat Team Alpha ein ungenutztes Kontingent?
+ *Aktuelle Nutzung*: 6 CPUs gebraucht, 2 CPUs verfügbar
+ *Neue Anforderung*: 4 CPUs erforderlich
+ *Ergebnis*: Ungenügendes Kontingent → Weiter mit Schritt 2
1. **Selbstprävention innerhalb von Team Alpha**
Frage: Können Team Alpha-Jobs mit niedrigerer Priorität ausgeschlossen werden?
+ *Verfügbare Ziele*: Keine Jobs mit niedrigerer Priorität in Team Alpha
+ *Ergebnis*: Keine Präemption möglich → Fahren Sie mit Schritt 3 fort
1. **Entliehene Ressourcen zurückfordern**
Frage: Werden Team Alpha-Ressourcen von anderen Teams ausgeliehen?
+ *Ausgeliehene Ressourcen*: Team Beta verwendet 2 CPUs von Team Alpha
+ *Aktion*: Die Warteschlange entfernt die von Team Beta geliehenen Trainingskapseln und gibt 2 davon frei CPUs
+ *Verbleibender Bedarf*: Benötige noch 2 weitere CPUs → Interaktive Bereiche bleiben im NotAdmitted Status, bis Ressourcen verfügbar sind
Bei diesem Ansatz werden interaktive Bereiche priorisiert und gleichzeitig die Quotengrenzen für Teams beibehalten und verhindert, dass Entwicklungsarbeiten mit instabilen, geliehenen Ressourcen ausgeführt werden.
# Beobachtbarkeit
## Standardmäßige Kubernetes-Überwachung
Sie können Spaces mit Standard-Kubernetes-Tools wie `kubectl` Describe und Logs überwachen. `kubectl`
**Den Space-Status überwachen**
```
# List all Spaces with status
kubectl get workspace -A
# Get detailed information about a specific Space
kubectl describe workspace
```
**Speicherprotokolle anzeigen**
```
# 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=