Wir haben kürzlich die Möglichkeit eingeführt, Amazon SageMaker Spaces auf Amazon SageMaker HyperPod EKS-Clustern direkt über die Amazon SageMaker Studio-Benutzeroberfläche zu erstellen und zu verwalten. Data Scientists und Machine Learning (ML)-Engineers können JupyterLab- und Code Editor-Umgebungen jetzt auf HyperPod-Clustern starten, ohne den Browser zu verlassen oder Kommandozeilen-Tools zu verwenden, wodurch sich der Weg vom Clusterzugriff zur produktiven Entwicklung auf wenige Klicks verkürzt.
Hintergrund
Amazon SageMaker HyperPod bietet speziell entwickelte Infrastruktur für Foundation Model (FM)-Training und -Inferenz im großen Maßstab. Mit der Orchestrierung durch Amazon Elastic Kubernetes Service (Amazon EKS) können Teams verteilte Trainingsjobs über hunderte von Beschleunigern hinweg mit integrierter Resilienz und automatischer Fehlerbehebung ausführen. Zusätzlich zum Training erweitert HyperPod diese EKS-orchestrierte Infrastruktur, um latenzarme, skalierbare Inferenz für Foundation Models mit mehreren Milliarden Parametern bereitzustellen.
Anfang dieses Jahres haben wir Amazon SageMaker Spaces für HyperPodeingeführt, ein Add-on, mit dem ML-Entwickler interaktive Entwicklungsumgebungen direkt auf HyperPod EKS-Clustern erstellen können. Organisationen konnten damit ihre GPU-Investitionen maximieren, indem sie interaktive Workloads neben Trainingsjobs und Modellbereitstellungen auf derselben Infrastruktur ausführten, mit Unterstützung für anteilige GPU-Zuweisungen.
Bisher basierte das Erstellen und Verwalten von Spaces hauptsächlich auf der HyperPod CLI oder kubectl Befehlen. Dieser Ansatz bietet Infrastrukturadministratoren zwar eine leistungsstarke, granulare Kontrolle, aber Data Scientists, die eine visuelle Oberfläche bevorzugen, können nun diese neue SageMaker Studio-Funktion nutzen, um Kommandozeilen-Tools zu umgehen und sich vollständig auf die Modellentwicklung zu konzentrieren.
Was ist neu
Mit dieser neuen Funktion können Data Scientists Spaces jetzt direkt aus SageMaker Studio heraus erstellen, konfigurieren, starten, stoppen und öffnen. Der neue Tab „IDE and Notebooks“ auf der Detailseite des HyperPod-Clusters bietet eine vollständige Benutzeroberfläche für die Space-Verwaltung, sodass Kommandozeilen-Tools für tägliche Space-Vorgänge nicht mehr benötigt werden.
Zu den über Studio verfügbaren Hauptfunktionen gehören:
- Erstellen von Spaces mit konfigurierbarer Compute-Leistung, Namespaces, Speicher, HyperPod Task Governance für Compute-Quotenverwaltung und Bildeinstellungen über ein geführtes Formular.
- Anzeige aller Spaces in einer durchsuchbaren Tabelle mit Name, Anwendungstyp, Status, Zugriffstyp, Speicher, GPU- und vCPU-Zuweisungen.
- Starten und Stoppen von Spaces mit einer einzigen Auswahl, um Compute-Ressourcen freizugeben, wenn Spaces nicht verwendet werden.
- Öffnen von Spaces direkt im Browser (JupyterLab oder Code Editor) oder Verbindung über eine Remote-IDE Ihrer Wahl (z. B. VS Code).
Abbildung 1: Der Tab „IDE and Notebooks“ auf der Detailseite des HyperPod-Clusters zeigt alle Spaces mit ihrem Status, ihrer Compute-Zuweisung sowie Schnellaktionen zum Stoppen, Öffnen oder Öffnen in einer Remote-IDE
Erste Schritte
Das Setup umfasst zwei Rollen: Administratoren bereiten den Cluster vor, und Data Scientists erstellen und öffnen Spaces. Die folgenden Abschnitte behandeln beides.
Für Administratoren
Administratoren installieren das SageMaker Spaces Add-on auf ihrem HyperPod EKS-Cluster entweder über die Schnellinstallation (Ein-Klick mit optimierten Standardeinstellungen) oder die Option Benutzerdefinierte Installation (erforderlich, um den Web-UI-Zugriff einzurichten) über den Tab IDE und Notebooks ihres SageMaker HyperPod EKS-Clusters. Nach der Installation kann der Administrator Namespaces konfigurieren, Space-Vorlagen erstellen und den Zugriff über EKS-Access-Entries verwalten.
Das folgende ist eine einmalige Einrichtung, die Administratoren durchführen müssen:
- Installieren Sie das Spaces Add-on: Öffnen Sie in der Amazon SageMaker AI-Konsole Ihren HyperPod-Cluster, wechseln Sie zum Tab IDE und Notebooks und wählen Sie entweder Schnellinstallation oder Benutzerdefinierte Installation (die benutzerdefinierte Installation ist erforderlich, um den Webbrowser-Zugriff zu aktivieren). Die vollständigen Anweisungen finden Sie in der AWS-Dokumentation .
- Konfigurieren Sie EKS-Access-Entries: Fügen Sie die drei verwalteten Richtlinien
AmazonSagemakerHyperpodSpacePolicy,AmazonSagemakerHyperpodUserClusterPolicyundAmazonSagemakerHyperpodSpaceTemplatePolicyan die AWS Identity and Access Management (IAM)-Rollen an, die von Ihren Data Scientists verwendet werden. - Aktivieren Sie die Identitätsweitergabe pro Benutzer (per-user identity propagation) auf der Studio-Domain: Wenn Ihre Studio-Domain erstellt wurde, bevor die Integration von SageMaker Studio und HyperPod Spaces eingeführt wurde, müssen Sie die Identitätsweitergabe pro Benutzer zum HyperPod-EKS-Cluster aktivieren. Dies stellt sicher, dass die Aktionen jedes Studio-Benutzers auf dem Cluster (Erstellen, Stoppen oder Löschen eines Space) seinem Benutzerprofil in den EKS access entries und AWS CloudTrail zugeordnet werden. Darüber hinaus erzwingt diese Identitätszuordnung ein strenges Space-Eigentum. Sie verfolgt, welcher Benutzer die Umgebung erstellt hat, und bestimmt, ob der Space privat ist oder innerhalb der SageMaker Studio-Domain geteilt wird.
Führen Sie den folgenden Befehl einmal pro Studio-Domain aus:
aws sagemaker update-domain \
--domain-id $DOMAIN_ID \
--default-user-settings '{
"StudioWebPortalSettings": {
"ExecutionRoleSessionNameMode": "USER_IDENTITY"
}
}'
Aktualisieren Sie nach der Aktualisierung der Domain die folgende Überprüfung, indem Sie prüfen, dass der folgende Befehl „USER_IDENTITY“ zurückgibt:
aws sagemaker describe-domain --domain-id $DOMAIN_ID \
--query 'DefaultUserSettings.StudioWebPortalSettings.ExecutionRoleSessionNameMode'
Bereits laufende Apps sind nicht betroffen. Benutzer erhalten die neue Einstellung bei ihrer nächsten Anmeldung.
- Optional können Sie zusätzliche Funktionen aktivieren: Aktivieren Sie beliebige Funktionen aus der folgenden Tabelle mit optionalen Funktionen (Optional capabilities).
Für Data Scientists
Nachdem das Add-on installiert und der Zugriff konfiguriert wurde, navigieren Data Scientists in SageMaker Studio unter Compute zu ihrem HyperPod-Cluster → HyperPod und wählen den Tab IDE and Notebooks aus, um die Spaces-Verwaltungsoberfläche zu sehen (siehe Abbildung 1). Erfahren Sie mehr über das Erstellen und Verwalten von Spaces: Erstellen und Verwalten von Spaces auf HyperPod.
Sobald der Status des Space Running anzeigt (typischerweise einige Minuten auf einem kalten Cluster, etwa 30–40 Sekunden mit Over-Provisioning), wählen Sie Open um JupyterLab oder Code Editor in Ihrem Browser zu starten (Abbildungen 2 und 3), oder Open in VS Code um sich über SSH-over-SSM aus Ihrem lokalen Editor zu verbinden (Abbildung 4).
Abbildung 2: Ein über den Webbrowser aufgerufener JupyterLab Space mit dem Launcher und verfügbaren Notebook-Kernels, Konsolen und Terminalzugriff
Arbeiten in einem JupyterLab Space
Nach dem Öffnen eines JupyterLab Space erhalten Sie eine vollständig konfigurierte Entwicklungsumgebung mit Zugriff auf:
- Python 3 Notebooks mit ipykernel.
- Glue PySpark- und Glue Spark-Konsolen.
- SparkMagic PySpark- und Spark-Kernels.
- Terminalzugriff zum Ausführen von Befehlen.
- Dateibrowser mit persistentem Speicher.
- Integrierten Chat und kontextbezogene Hilfe.
Ihre Arbeit bleibt auf dem angehängten Amazon Elastic Block Store (Amazon EBS)-Volume erhalten, sodass Sie Spaces stoppen und neu starten können, ohne Fortschritte zu verlieren.
Abbildung 3: Ein auf HyperPod laufender Code Editor Space mit der VS Code-artigen Weboberfläche mit Datei-Explorer, Editor und integriertem Terminal
Arbeiten in einem Code Editor Space
Für Entwickler, die ein VS Code-artiges Erlebnis im Browser bevorzugen, bieten Code Editor Spaces eine schlanke, webbasierte IDE mit:
- Vollständiger Dateibearbeitung mit Syntaxhervorhebung und IntelliSense.
- Integriertes Terminal zum Ausführen von Shell-Befehlen, zum Einreichen von Trainingsjobs oder zur Interaktion mit Cluster-Ressourcen.
- Erweiterungsunterstützung für Language Server, Linter und Formatter.
- Git-Integration für Workflows zur Versionskontrolle.
- Direkter Zugriff auf das Cluster-Dateisystem und eingebundene Amazon-FSx-Volumes.
Code Editor Spaces eignen sich gut zum Schreiben und Debuggen von Trainingsskripten, zum Verwalten von Experimentkonfigurationen und zum Arbeiten mit Code-Repositories – alles, ohne den Browser zu verlassen.
Abbildung 4: Eine lokale VS Code-Instanz, die remote mit einem HyperPod Space verbunden ist, mit dem Indikator für die Remote-Verbindung und den vollständigen IDE-Funktionen, die auf Cluster-Compute ausgeführt werden
Remote-IDE-Verbindung (VS Code)
Wählen Sie in der Spaces-Tabelle Open in VS Code aus, um Ihre lokale Visual Studio Code-Instanz mit dem auf HyperPod laufenden Space zu verbinden. Dies verwendet intern SSH-over-SSM-Tunneling und bietet eine sichere Verbindung, ohne dass Sie SSH-Schlüssel verwalten oder Port 22 freigeben müssen.
Sie erhalten die volle Leistung Ihrer lokalen VS Code-Umgebung, einschließlich Erweiterungen, Themes und Tastenkombinationen, während Code auf HyperPod-Cluster-Compute ausgeführt wird.
Sie können auch eine Verbindung über das AWS Toolkit for Visual Studio Code herstellen, das Ihre Spaces unter SageMaker AI > HyperPod auflistet, und Sie können Spaces direkt über das Toolkit-Panel starten, stoppen und eine Verbindung zu ihnen herstellen.
Optionale Funktionen
Jede der folgenden Funktionen ist optional und kombinierbar. Aktivieren Sie beliebige Kombinationen, die zu den Anforderungen Ihres Teams passen.
| Funktion | Beschreibung |
| Webbrowser-Zugriff | AWS Application Load Balancer und benutzerdefiniertes DNS über Amazon Route 53, um Browser-Traffic an Spaces zu routen. Nicht für den Remote-IDE-Zugriff (VS Code über SSM) erforderlich. |
| Space-Vorlagen | Von Administratoren definierte Vorlagen, die Compute, Images, Storage und Lifecycle-Skripte vorkonfigurieren, um konsistente Space-Konfigurationen teamübergreifend zu gewährleisten. |
| Task Governance | Compute-Quotas auf Namespace-Ebene, Warteschlangen und prioritätsbasierte Zulassung durch Kueue für Multi-Tenant-Cluster. |
| Karpenter-Autoscaling | Dynamisches Hoch-/Herunterskalieren von Knoten basierend auf Space-Bedarf. |
| Karpenter Over-Provisioning | Vorgewärmte Knoten mit vorab geladenen Images, die den Space-Start von 5–7 Minuten auf etwa 30–40 Sekunden verkürzen. Siehe den folgenden Pro-Tip-Abschnitt. |
| Persistente Volumes (EFS / FSx) | Gemeinsame Benutzerverzeichnisse und Team-Datensätze, die über Spaces hinweg bestehen bleiben. |
| Eigene Images (ECR) | Team-spezifische Runtimes und Bibliotheken, die in Container-Images integriert sind und in Amazon Elastic Container Registry (Amazon ECR) gehostet werden. |
| Herunterfahren bei Inaktivität | Automatische Beendigung inaktiver Spaces zum Schutz vor unkontrollierten Compute-Kosten. |
| NVIDIA MIG | Bruchteilweise GPU-Zuteilung für kosteneffiziente interaktive Workloads auf A100/H100-Hardware. |
Pro-Tipp: Verkürzung der Space-Startzeit mit Node Over-Provisioning
Standardmäßig verursacht SageMaker Spaces auf HyperPod-EKS-Clustern mit Karpenter-Autoscaling eine Cold-Start-Verzögerung von 5–7 Minuten beim ersten Erstellen eines Space auf einem Scale-to-Zero-Cluster, die hauptsächlich verursacht wird durch:
- Start der Amazon Elastic Compute Cloud (Amazon EC2)-Instance.
- Registrierung des Kubernetes-Knotens.
- Abruf des SageMaker Distribution (SMD)-Images.
Für latenzempfindliche interaktive Workloads (JupyterLab, Code Editor) können Sie einen Pool von vorgewärmten Knoten mit zwischengespeicherten Images vorhalten unter Verwendung des Standard-Kubernetes-Over-Provisioning-Musters. Dies verkürzt die Startzeit eines Spaces von Minuten auf etwa 30–40 Sekunden.
So funktioniert es
- Ein Low-Priority-
-1000)-Platzhalter-Deployment hält einen Kubernetes-Pod auf jedem vorgewärmten Node. Diese Pods fordern dieselbe CPU/denselben Arbeitsspeicher an wie ein echter Space. - Ein
initContainerauf jedem Platzhalter zieht das SageMaker-Distribution-Image vorab auf den Node, wenn Karpenter ihn bereitstellt. - Wenn ein Nutzer einen Space erstellt (Standardpriorität
0), preemptiert der Kubernetes-Scheduler den Platzhalter (Priorität-1000). Der Space landet dann in wenigen Sekunden auf dem bereits aufgewärmten Node mit Image-Cache, ohne Image-Pull und ohne Wartezeit auf den Node-Start. - Karpenter stellt im Hintergrund einen Ersatzknoten für den verdrängten Platzhalter bereit.
Erfahren Sie mehr über die Pro-Tip-Bereitstellung: Overprovisioning für HyperPod Spaces.
Verifizierte Startlatenzen auf ml.m5.12xlarge (24 vCPU zuweisbar, 2 vCPU Platzhalter, 8 GiB Platzhalter-Speicher) mit dem sagemaker-distribution:latest-cpu SMD-Image, das etwa 3,5 GB groß ist:
| Pfad | Latenz |
| Space passt neben dem Platzhalter (Koexistenz) | ~14 s |
| Space verdrängt den Platzhalter | ~35 s |
| Kaltstart (kein Warm Pool) | 5-7 min |
Hinweis: Diese Zahlen gelten nur für CPU. GPU Spaces benötigen ihre eigene Platzhalter-Deployment, die nvidia.com/gpu anfordert, mit vorab heruntergeladenem GPU-Image. Andernfalls bleiben GPU-Knoten kalt, und mit etwa 10 GB kostet das GPU-Image beim Herunterladen weit mehr als das 3,5-GB-CPU-Image.
Hinweis: Jeder Warm-Knoten hält eine EC2-Instanz im Zustand Running. Bei On-Demand-Knoten entstehen dadurch laufende zusätzliche Kosten für den Betrieb der Warm-Knoten.
Weitere Informationen zur Installation des HyperPod-Spaces-Add-ons und zu den ersten Schritten finden Sie in der AWS-Dokumentation.
Preise
Das Konfigurieren des SageMaker-Spaces-Add-ons verursacht keine zusätzlichen Gebühren. Sie zahlen für die von Ihren Spaces verbrauchte Rechenleistung des zugrunde liegenden HyperPod-Clusters sowie einen Stundensatz für die AWS Systems Manager Advanced On-Premises Instance, die für SSH-over-SSM-Fernkonnektivität verwendet wird. Details finden Sie unter AWS Systems Manager Pricing .
Wenn Sie das zuvor beschriebene Overprovisioning verwenden, beachten Sie, dass zusätzliche Kosten für Warm-Knoten anfallen. Je nach Instanztyp und -größe verbleiben diese Knoten im laufenden Zustand und warten auf die Bereitstellung von Spaces.
Fazit
Die Verwaltung von HyperPod Spaces mit SageMaker Studio überbrückt die Lücke zwischen Data Scientists und leistungsstarker Recheninfrastruktur. Teams können nun in wenigen Minuten vom Clusterzugriff zu einer laufenden JupyterLab- oder Code-Editor-Umgebung gelangen, ohne CLI-Tools oder Kubernetes-Konzepte lernen zu müssen. In Kombination mit Funktionen wie HyperPod Task Governance, fractionalem GPU-Support und Idle Shutdown können Organisationen Self-Service-Zugriff auf gemeinsame Cluster ermöglichen und gleichzeitig Kostenkontrolle und Ressourcenfairness wahren.
Um loszulegen, navigieren Sie in der SageMaker-AI-Konsole zu Ihrem HyperPod-EKS-Cluster und wählen Sie die Registerkarte IDE und Notebooks aus. Weitere Informationen finden Sie in der SageMaker HyperPod Spaces-Dokumentation.
