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.
SageMaker HyperPod Verweise
Weitere Informationen und Referenzen zur Verwendung finden Sie SageMaker HyperPod in den folgenden Themen.
Themen
SageMaker HyperPod Preisgestaltung
Die folgenden Themen enthalten Informationen zur SageMaker HyperPod Preisgestaltung. Weitere Informationen zum Preis pro Stunde für die Nutzung von SageMaker HyperPod Instances finden Sie auch unter SageMaker Amazon-Preise
Kapazitätsanfragen
Sie können mit SageMaker KI Rechenkapazität auf Abruf oder reservierte Rechenkapazität zur Nutzung auf SageMaker HyperPod zuweisen. On-demand Bei der Clustererstellung werden verfügbare Kapazitäten aus dem SageMaker KI-On-Demand-Kapazitätspool zugewiesen. Alternativ können Sie reservierte Kapazität anfordern, um den Zugriff sicherzustellen, indem Sie ein Ticket für eine Erhöhung des Kontingents einreichen. Eingehende Kapazitätsanfragen werden von SageMaker KI priorisiert und Sie erhalten eine geschätzte Zeit für die Kapazitätszuweisung.
Service – Fakturierung
Wenn Sie Rechenkapazität am bereitstellen SageMaker HyperPod, wird Ihnen die Dauer der Kapazitätszuweisung in Rechnung gestellt. SageMaker HyperPod Die Abrechnung erscheint in Ihren Jubiläumsrechnungen mit einer Zeile für die Art der Kapazitätszuweisung (auf Abruf, reserviert), den Instance-Typ und die für die Nutzung der Instance aufgewendete Zeit.
Informationen zum Einreichen eines Tickets für eine Erhöhung des Kontingents finden Sie unter SageMaker HyperPod Kontingente.
SageMaker HyperPod APIs
Die folgende Liste enthält einen vollständigen Satz von SageMaker HyperPod APIs zum Senden von Aktionsanfragen im JSON-Format an SageMaker KI über AWS CLI oder AWS SDK für Python (Boto3).
SageMaker HyperPod Slurm-Konfiguration
HyperPod unterstützt zwei Ansätze für die Konfiguration von Slurm auf Ihrem Cluster. Wählen Sie den Ansatz, der Ihren Bedürfnissen am besten entspricht.
| Ansatz | Beschreibung | Empfohlen für |
| API-driven Konfiguration | Definieren Sie die Slurm-Konfiguration direkt in den CreateCluster und UpdateCluster API-Anfragen | Neue Cluster; vereinfachtes Management |
| Legacy-Konfiguration | Verwenden Sie eine separate provisioning_parameters.json Datei, die in Amazon S3 gespeichert ist |
Bestehende Cluster; Abwärtskompatibilität |
API-driven Slurm-Konfiguration (empfohlen)
Bei der API-driven Konfiguration definieren Sie Slurm-Knotentypen, Partitionszuweisungen und Dateisystem-Mounts direkt in den CreateCluster und API-Anfragen. UpdateCluster Dieser Ansatz bietet:
-
Zentrale Informationsquelle — Die gesamte Konfiguration in der API-Anfrage
-
Keine S3-Dateiverwaltung — Keine Erstellung oder Wartung erforderlich
provisioning_parameters.json -
Built-in Validierung — Die API validiert die Slurm-Topologie vor der Clustererstellung
-
Drift-Erkennung — Erkennt unbefugte Änderungen an
slurm.conf -
Per-instance-group storage — Konfiguration verschiedener FSx-Dateisysteme für verschiedene Instanzgruppen
-
Unterstützung von FSx für OpenZFS — Mounten Sie OpenZFS-Dateisysteme zusätzlich zu FSx for Lustre
SlurmConfig (pro Instanzgruppe)
Fügen Sie SlurmConfig jede Instanzgruppe hinzu, um den Slurm-Knotentyp und die Partitionszuweisung zu definieren.
"SlurmConfig": { "NodeType": "Controller | Login | Compute", "PartitionNames": ["string"] }
Parameter:
-
NodeType– Erforderlich. Der Slurm-Knotentyp für diese Instanzgruppe. Zulässige Werte:-
Controller— Slurm-Controller-Knoten (Kopf). Führt denslurmctldDaemon aus. Genau eine Instanzgruppe muss diesen Knotentyp haben. -
Login— Login-Knoten für den Benutzerzugriff. Optional. Höchstens eine Instanzgruppe kann diesen Knotentyp haben. -
Compute— Worker-Knoten, die Jobs ausführen. Kann mehrere Instanzgruppen mit diesem Knotentyp haben.
Wichtig
NodeTypeist unveränderlich. Sobald es bei der Clustererstellung festgelegt wurde, kann es nicht geändert werden. Um einen anderen Knotentyp zu verwenden, erstellen Sie eine neue Instanzgruppe. -
-
PartitionNames— Befriedigend. Eine Reihe von Slurm-Partitionsnamen. Erforderlich fürComputeKnotentypen; nicht zulässig fürControllerLoginNode-Typen. Unterstützt derzeit einen einzelnen Partitionsnamen pro Instanzgruppe.Anmerkung
Alle Knoten werden der universellen
devPartition zusätzlich zu ihrer angegebenen Partition automatisch hinzugefügt.
Beispiel:
{ "InstanceGroupName": "gpu-compute", "InstanceType": "ml.p4d.24xlarge", "InstanceCount": 8, "SlurmConfig": { "NodeType": "Compute", "PartitionNames": ["gpu-training"] }, "LifeCycleConfig": { "SourceS3Uri": "s3://sagemaker-bucket/lifecycle/src/", "OnCreate": "on_create.sh" }, "ExecutionRole": "arn:aws:iam::111122223333:role/HyperPodRole" }
Orchestrator.Slurm (Clusterebene)
Orchestrator.SlurmZur Cluster-Konfiguration hinzufügen, um anzugeben, wie die slurm.conf Datei HyperPod verwaltet wird.
"Orchestrator": { "Slurm": { "SlurmConfigStrategy": "Managed | Overwrite | Merge" } }
Parameter:
-
SlurmConfigStrategy— Erforderlich,Orchestrator.Slurmwenn angegeben. Steuert, wie dieslurm.confDatei auf dem Controller-Knoten HyperPod verwaltet wird. Zulässige Werte:-
Managed(Standard) — Steuert HyperPod vollständig die Partitionsknoten-Zuordnungen in.slurm.confDie Drift-Erkennung ist aktiviert: Wenn der aktuelle Wert von der erwarteten Konfigurationslurm.confabweicht, UpdateCluster schlägt der Fehler fehl. Verwenden Sie diese Strategie, wenn Sie HyperPod die zentrale Informationsquelle für die Slurm-Konfiguration sein möchten. -
Overwrite— HyperPod erzwingt die Anwendung der API-Konfiguration und überschreibt alle manuellen Änderungen an.slurm.confDie Drifterkennung ist deaktiviert. Verwenden Sie diese Strategie, um die Drift zu beheben oder den Cluster auf einen bekannten Zustand zurückzusetzen. -
Merge— HyperPod behält manuelleslurm.confÄnderungen bei und führt sie mit der API-Konfiguration zusammen. Die Drifterkennung ist deaktiviert. Verwenden Sie diese Strategie, wenn Sie manuelle Änderungen an der Slurm-Konfiguration vornehmen müssen, die auch nach Updates beibehalten werden sollen.
-
Anmerkung
Wenn in der Anfrage nicht angegeben Orchestrator.Slurm wird, ist Managed das Standardverhalten Strategie.
Tipp
Sie können SlurmConfigStrategy jederzeit Änderungen vornehmen mit UpdateCluster. Es gibt keine Bindung an eine bestimmte Strategie.
Beispiel:
{ "ClusterName": "my-hyperpod-cluster", "InstanceGroups": [...], "Orchestrator": { "Slurm": { "SlurmConfigStrategy": "Managed" } } }
SlurmConfigStrategy Vergleich
| Strategie | Erkennung von Driften | Manuelle Änderungen | Anwendungsfall |
Managed |
Aktiviert — blockiert Updates, wenn eine Drift erkannt wird | Blocked | HyperPod verwaltet |
Overwrite |
Disabled | Überschrieben | Wiederherstellung nach Drift; auf bekannten Zustand zurückgesetzt |
Merge |
Disabled | Konserviert | Fortgeschrittene Benutzer mit individuellen slurm.conf Bedürfnissen |
FSx-Konfiguration über InstanceStorageConfigs
Mit der API-driven Konfiguration können Sie FSx-Dateisysteme pro Instanzgruppe mithilfe von konfigurieren. InstanceStorageConfigs Dies ermöglicht es verschiedenen Instanzgruppen, unterschiedliche Dateisysteme zu mounten.
Voraussetzungen:
-
Ihr Cluster muss eine benutzerdefinierte VPC (via
VpcConfig) verwenden. FSx-Dateisysteme befinden sich in Ihrer VPC, und die plattformverwaltete VPC kann sie nicht erreichen. -
Mindestens eine Instanzgruppe muss mit haben.
SlurmConfigNodeType: Controller
FsxLustreConfig
Konfigurieren Sie FSx for Lustre Lustre-Dateisystem-Mounten für eine Instanzgruppe.
"InstanceStorageConfigs": [ { "FsxLustreConfig": { "DnsName": "string", "MountPath": "string", "MountName": "string" } } ]
Parameter:
-
DnsName– Erforderlich. Der DNS-Name des FSx for Lustre-Dateisystems. Beispiel:fs-0abc123def456789.fsx.us-west-2.amazonaws.com -
MountPath– Optional. Der lokale Mount-Pfad auf der Instanz. Standard:/fsx -
MountName– Erforderlich. Der Mount-Name des FSx for Lustre-Dateisystems. Sie finden dies in der Amazon FSx-Konsole oder indem Sie es ausführenaws fsx describe-file-systems.
FsxOpenZfsConfig
Konfigurieren Sie FSx für das OpenZFS-Dateisystem-Mounten für eine Instanzgruppe.
"InstanceStorageConfigs": [ { "FsxOpenZfsConfig": { "DnsName": "string", "MountPath": "string" } } ]
Parameter:
-
DnsName– Erforderlich. Der DNS-Name des FSx for OpenZFS-Dateisystems. Beispiel:fs-0xyz987654321.fsx.us-west-2.amazonaws.com -
MountPath– Optional. Der lokale Mount-Pfad auf der Instanz. Standard:/home
Anmerkung
Jede Instanzgruppe kann höchstens eins FsxLustreConfig und eins habenFsxOpenZfsConfig.
Beispiel mit mehreren Dateisystemen:
{ "InstanceGroupName": "gpu-compute", "InstanceType": "ml.p4d.24xlarge", "InstanceCount": 4, "SlurmConfig": { "NodeType": "Compute", "PartitionNames": ["gpu-training"] }, "InstanceStorageConfigs": [ { "FsxLustreConfig": { "DnsName": "fs-0abc123def456789.fsx.us-west-2.amazonaws.com", "MountPath": "/fsx", "MountName": "abcdefgh" } }, { "FsxOpenZfsConfig": { "DnsName": "fs-0xyz987654321.fsx.us-west-2.amazonaws.com", "MountPath": "/shared" } }, { "EbsVolumeConfig": { "VolumeSizeInGB": 500 } } ], "LifeCycleConfig": { "SourceS3Uri": "s3://sagemaker-bucket/lifecycle/src/", "OnCreate": "on_create.sh" }, "ExecutionRole": "arn:aws:iam::111122223333:role/HyperPodRole" }
Wichtig
FSx-Konfigurationsänderungen gelten nur während der Knotenbereitstellung. Bestehende Knoten behalten ihre ursprüngliche FSx-Konfiguration bei. Um die neue FSx-Konfiguration auf alle Knoten anzuwenden, skalieren Sie die Instanzgruppe auf 0 und dann wieder nach oben.
Vollständiges API-driven Konfigurationsbeispiel
Das folgende Beispiel zeigt eine vollständige CreateCluster Anfrage mit der API-driven Slurm-Konfiguration:
{ "ClusterName": "ml-training-cluster", "InstanceGroups": [ { "InstanceGroupName": "controller", "InstanceType": "ml.c5.xlarge", "InstanceCount": 1, "SlurmConfig": { "NodeType": "Controller" }, "LifeCycleConfig": { "SourceS3Uri": "s3://sagemaker-us-west-2-111122223333/lifecycle/src/", "OnCreate": "on_create.sh" }, "ExecutionRole": "arn:aws:iam::111122223333:role/HyperPodRole", "ThreadsPerCore": 2 }, { "InstanceGroupName": "login", "InstanceType": "ml.m5.xlarge", "InstanceCount": 1, "SlurmConfig": { "NodeType": "Login" }, "LifeCycleConfig": { "SourceS3Uri": "s3://sagemaker-us-west-2-111122223333/lifecycle/src/", "OnCreate": "on_create.sh" }, "ExecutionRole": "arn:aws:iam::111122223333:role/HyperPodRole", "ThreadsPerCore": 2 }, { "InstanceGroupName": "gpu-compute", "InstanceType": "ml.p4d.24xlarge", "InstanceCount": 8, "SlurmConfig": { "NodeType": "Compute", "PartitionNames": ["gpu-training"] }, "InstanceStorageConfigs": [ { "FsxLustreConfig": { "DnsName": "fs-0abc123def456789.fsx.us-west-2.amazonaws.com", "MountPath": "/fsx", "MountName": "abcdefgh" } } ], "LifeCycleConfig": { "SourceS3Uri": "s3://sagemaker-us-west-2-111122223333/lifecycle/src/", "OnCreate": "on_create.sh" }, "ExecutionRole": "arn:aws:iam::111122223333:role/HyperPodRole", "ThreadsPerCore": 2, "OnStartDeepHealthChecks": ["InstanceStress", "InstanceConnectivity"] }, { "InstanceGroupName": "cpu-compute", "InstanceType": "ml.c5.18xlarge", "InstanceCount": 4, "SlurmConfig": { "NodeType": "Compute", "PartitionNames": ["cpu-preprocessing"] }, "InstanceStorageConfigs": [ { "FsxLustreConfig": { "DnsName": "fs-0abc123def456789.fsx.us-west-2.amazonaws.com", "MountPath": "/fsx", "MountName": "abcdefgh" } } ], "LifeCycleConfig": { "SourceS3Uri": "s3://sagemaker-us-west-2-111122223333/lifecycle/src/", "OnCreate": "on_create.sh" }, "ExecutionRole": "arn:aws:iam::111122223333:role/HyperPodRole", "ThreadsPerCore": 2 } ], "Orchestrator": { "Slurm": { "SlurmConfigStrategy": "Managed" } }, "VpcConfig": { "SecurityGroupIds": ["sg-0abc123def456789a"], "Subnets": ["subnet-0abc123def456789a", "subnet-0abc123def456789b"] }, "Tags": [ { "Key": "Project", "Value": "ML-Training" } ] }
Weitere Informationen zur Verwendung der API-driven Konfiguration finden Sie unterAnpassen von SageMaker HyperPod Clustern mithilfe von Lebenszyklusskripten.
Legacy-Konfiguration: provisioning_parameters.json
Anmerkung
Der provisioning_parameters.json Ansatz ist die alte Methode zur Konfiguration von Slurm on. HyperPod Für neue Cluster empfehlen wir, den oben beschriebenen API-driven Konfigurationsansatz zu verwenden. Der ältere Ansatz wird aus Gründen der Abwärtskompatibilität weiterhin vollständig unterstützt.
Beim Legacy-Ansatz erstellen Sie eine Slurm-Konfigurationsdatei mit dem Namen provisioning_parameters.json und laden sie als Teil Ihrer Lifecycle-Skripte auf Amazon S3 hoch. HyperPod liest diese Datei während der Clustererstellung, um Slurm-Knoten zu konfigurieren.
Konfigurationsformular für provisioning_parameters.json
Der folgende Code ist das Slurm-Konfigurationsformular, das Sie vorbereiten sollten, um Slurm-Knoten auf Ihrem Cluster ordnungsgemäß einzurichten. HyperPod Sie sollten dieses Formular ausfüllen und es während der Clustererstellung als Teil einer Reihe von Lebenszyklusskripten hochladen. Informationen darüber, wie dieses Formular während der HyperPod Clustererstellung vorbereitet werden sollte, finden Sie unter. Anpassen von SageMaker HyperPod Clustern mithilfe von Lebenszyklusskripten
// Save as provisioning_parameters.json. { "version": "1.0.0", "workload_manager": "slurm", "controller_group": "string", "login_group": "string", "worker_groups": [ { "instance_group_name": "string", "partition_name": "string" } ], "fsx_dns_name": "string", "fsx_mountname": "string" }
Parameter:
-
version– Erforderlich. Dies ist die Version des Formulars für HyperPod Bereitstellungsparameter. Belassen Sie es auf1.0.0. -
workload_manager– Erforderlich. Damit geben Sie an, welcher Workload-Manager auf dem HyperPod Cluster konfiguriert werden soll. Belassen Sie es aufslurm. -
controller_group– Erforderlich. Dies dient zur Angabe des Namens der HyperPod Cluster-Instanzgruppe, die Sie dem Slurm-Controller-Knoten (Head) zuweisen möchten. -
login_group– Optional. Dies dient zur Angabe des Namens der HyperPod Cluster-Instanzgruppe, die Sie dem Slurm-Login-Knoten zuweisen möchten. -
worker_groups– Erforderlich. Dies dient zum Einrichten von Slurm-Worker-Knoten (Compute) auf dem HyperPod Cluster.-
instance_group_name– Erforderlich. Dies dient zur Angabe des Namens der HyperPod Instanzgruppe, die Sie dem Slurm-Worker-Knoten (Compute) zuweisen möchten. -
partition_name– Erforderlich. Dies dient zur Angabe des Partitionsnamens für den Knoten.
-
-
fsx_dns_name– Optional. Wenn Sie Ihre Slurm-Knoten auf dem HyperPod Cluster für die Kommunikation mit Amazon FSx einrichten möchten, geben Sie den FSx-DNS-Namen an. -
fsx_mountname– Optional. Wenn Sie Ihre Slurm-Knoten auf dem HyperPod Cluster für die Kommunikation mit Amazon FSx einrichten möchten, geben Sie den FSx-Mount-Namen an.
Vergleich: im Vergleich zur Legacy-Konfiguration API-driven
| Merkmal | API-driven (Empfohlen) | Legacy (provisioning_parameters.json) |
| Speicherort der Konfiguration | CreateCluster API-Anfrage | S3-Datei |
| FSx für Lustre | Ja — Pro Instanzgruppe | Ja — Cluster-wide nur |
| FSx für OpenZFS | Ja — Pro Instanzgruppe | Nein — Nicht unterstützt |
| Built-in Validierung | Ja | Nein |
| Erkennung von Abweichungen | Ja — (Verwaltete Strategie) | Nein |
| S3-Dateiverwaltung | Nicht erforderlich | Erforderlich |
| Komplexität des Lebenszyklus-Skri | Vereinfacht | Vollständiges SLURM-Setup erforderlich |
SageMaker HyperPod DLAMI
SageMaker HyperPod führt ein DLAMI aus, das auf Folgendem basiert:
-
AWS Deep Learning Base GPU AMI (Ubuntu 20.04)
für die Orchestrierung mit Slurm. -
Auf Amazon Linux 2 basierendes AMI für die Orchestrierung mit Amazon EKS.
Das SageMaker HyperPod DLAMI wird mit zusätzlichen Paketen zur Unterstützung von Open-Source-Tools wie Slurm, Kubernetes, Abhängigkeiten und SageMaker HyperPod Cluster-Softwarepaketen zur Unterstützung von Resilienzfunktionen wie Cluster-Integritätsprüfung und Auto-Resume gebündelt. Weitere Informationen zu HyperPod Softwareupdates, die das Serviceteam über DLAMIs verteilt, finden Sie unter HyperPod . SageMaker HyperPod Versionshinweise von Amazon
SageMaker HyperPod Referenz zu API-Berechtigungen
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.
AWS verwaltete Richtlinien für Amazon SageMaker AIdie Berechtigungen zum Erstellen von SageMaker Ressourcen gewähren, beinhalten bereits Berechtigungen zum Hinzufügen von Tags beim Erstellen dieser Ressourcen.
Wenn Sie die Zugriffskontrolle für die Ausführung von SageMaker HyperPod API-Vorgängen einrichten und eine Berechtigungsrichtlinie schreiben, die Sie IAM-Benutzern für Cloud-Administratoren zuordnen können, verwenden Sie die folgende Tabelle als Referenz.
| SageMaker Amazon-API-Operationen | Erforderliche Berechtigungen (API-Aktionen) | Ressourcen |
| CreateCluster | sagemaker:CreateCluster |
arn:aws:sagemaker: |
| DeleteCluster | sagemaker:DeleteCluster |
arn:aws:sagemaker: |
| DescribeCluster | sagemaker:DescribeCluster |
arn:aws:sagemaker: |
| DescribeClusterNode | sagemaker:DescribeClusterNode |
arn:aws:sagemaker: |
| ListClusterNodes | sagemaker:ListClusterNodes |
arn:aws:sagemaker: |
| ListClusters | sagemaker:ListClusters |
arn:aws:sagemaker: |
| UpdateCluster | sagemaker:UpdateCluster |
arn:aws:sagemaker: |
| UpdateClusterSoftware | sagemaker:UpdateClusterSoftware |
arn:aws:sagemaker: |
Eine vollständige Liste der Berechtigungen und Ressourcentypen für SageMaker APIs finden Sie unter Aktionen, Ressourcen und Bedingungsschlüssel für Amazon SageMaker AI in der AWS Service Authorization Reference.
SageMaker HyperPod Befehle in AWS CLI
Im Folgenden finden Sie die AWS CLI Befehle SageMaker HyperPod zum Ausführen der wichtigsten HyperPod API-Operationen.
SageMaker HyperPod Python-Module in AWS SDK für Python (Boto3)
Im Folgenden sind die Methoden des AWS SDK für Python (Boto3) Clients für SageMaker KI zum Ausführen der wichtigsten HyperPod API-Operationen aufgeführt.