**Unterstützung für die Verbesserung dieser Seite beitragen** 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. Um zu diesem Benutzerhandbuch beizutragen, wählen Sie den GitHub Link **Diese Seite bearbeiten auf**, der sich im rechten Bereich jeder Seite befindet. 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. # Rechenressourcen für AI/ML Workloads auf Amazon EKS verwalten Dieser Abschnitt soll Ihnen bei der Verwaltung von Rechenressourcen für Machine-Learning-Workloads in Amazon Elastic Kubernetes Service (EKS) behilflich sein. Sie finden Einzelheiten zur Reservierung GPUs mithilfe von Kapazitätsblöcken für verwaltete Knotengruppen und selbstverwaltete Knoten, einschließlich der Voraussetzungen, der Einrichtung der Startvorlage, der Skalierungskonfigurationen, der Vorbereitung der Arbeitslast und der wichtigsten Überlegungen zum Umgang mit Reservierungszyklen und der ordnungsgemäßen Kündigung von Knoten. **Topics** + [Erstellung einer verwalteten Knotengruppe mit Kapazitätsblöcken für ML](capacity-blocks-mng.md) + [Erstellung selbstverwalteter Knoten mit Kapazitätsblöcken für ML](capacity-blocks.md) + [Verwenden Sie P6e- GB200 UltraServers mit Amazon EKS](ml-eks-nvidia-ultraserver.md) # Erstellung einer verwalteten Knotengruppe mit Kapazitätsblöcken für ML Kapazitätsblöcke für Machine Learning (ML) ermöglichen es Ihnen, GPU-Instances zu einem zukünftigen Zeitpunkt zu reservieren, um Ihre ML-Workloads mit kurzer Dauer zu unterstützen. Weitere Informationen finden Sie unter [Kapazitätsblöcke für ML](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-blocks.html) im *Amazon-EC2-Benutzerhandbuch für Linux-Instances*. ## Überlegungen **Wichtig** Kapazitätsblöcke sind nur für bestimmte Amazon-EC2-Instance-Typen und AWS-Regionen verfügbar. Informationen zur Kompatibilität finden Sie unter [Arbeiten mit Kapazitätsblöcken – Voraussetzungen](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/capacity-blocks-using.html#capacity-blocks-prerequisites) im *Amazon-EC2-Benutzerhandbuch für Linux-Instances*. Weitere Informationen finden Sie unter [Verwenden von Kapazitätsblöcken für Machine Learning im](https://docs.aws.amazon.com/autoscaling/ec2/userguide/launch-template-capacity-blocks.html) *Benutzerhandbuch für Amazon EC2 Auto Scaling*. Verwaltete Knotengruppen mit Kapazitätsblöcken können nur mit benutzerdefinierten Startvorlagen erstellt werden. Stellen Sie beim Upgrade verwalteter Knotengruppen mit Kapazitätsblöcken sicher, dass die gewünschte Größe der Knotengruppe auf `0` eingestellt ist. ## Erstellung einer verwalteten Knotengruppe mit Amazon-EC2-Kapazitätsblöcken Sie können Kapazitätsblöcke mit von Amazon EKS verwalteten Knotengruppen zum Bereitstellen und Skalieren von GPU-beschleunigten Worker-Knoten verwenden. Die folgenden Beispiele für AWS-CloudFormation-Vorlagen decken nicht alle Aspekte ab, die in Produktions-Clustern erforderlich sind. Normalerweise benötigen Sie auch ein Bootstrapping-Skript, um den Knoten mit dem Cluster zu verbinden und ein beschleunigtes Amazon-EKS-AMI anzugeben. Weitere Informationen finden Sie unter [Eine verwaltete Knotengruppe für Ihren Cluster erstellen](create-managed-node-group.md). 1. Erstellen Sie eine Startvorlage, die für Ihre Workloads geeignet ist und mit von Amazon EKS verwalteten Knotengruppen funktioniert. Weitere Informationen finden Sie unter [Verwaltete Knoten mit Startvorlagen anpassen](launch-templates.md). Stellen Sie zusätzlich zu den Anforderungen in den oben genannten Verfahren sicher, dass `LaunchTemplateData` ​​Folgendes enthält: + `InstanceMarketOptions` mit der Einstellung `"capacity-block"` für `MarketType` + `CapacityReservationSpecification: CapacityReservationTarget` mit `CapacityReservationId` als Kapazitätsblock (zum Beispiel: `cr-02168da1478b509e0 `) + `InstanceType` auf einen Instance-Typ eingestellt, der Kapazitätsblöcke unterstützt (zum Beispiel: *p5.48xlarge*) Nachfolgend finden Sie einen Auszug aus einer CloudFormation-Vorlage, die eine Startvorlage für einen Kapazitätsblock erstellt. Um eine benutzerdefinierte AMI-verwaltete Knotengruppe zu erstellen, können Sie auch `ImageId`- und `UserData`-Parameter hinzufügen. ``` NodeLaunchTemplate: Type: "AWS::EC2::LaunchTemplate" Properties: LaunchTemplateData: InstanceMarketOptions: MarketType: "capacity-block" CapacityReservationSpecification: CapacityReservationTarget: CapacityReservationId: "cr-02168da1478b509e0" InstanceType: p5.48xlarge ``` 1. Verwenden Sie die Startvorlage, um eine verwaltete Knotengruppe zu erstellen. Nachfolgend finden Sie ein Beispiel für den Befehl zum Erstellen einer Knotengruppe für Kapazitätsblöcke. Ersetzen Sie die *Beispielwerte* durch die für Ihren Cluster geltenden Werte. Gehen Sie beim Erstellen der verwalteten Knotengruppe für Kapazitätsblöcke wie folgt vor: + Legen Sie den Wert für `capacity-type` auf `"CAPACITY_BLOCK"` fest. Wenn der Kapazitätstyp nicht auf `"CAPACITY_BLOCK"` gesetzt ist oder einer der anderen oben genannten erforderlichen Startvorlagenwerte fehlt, wird die Erstellungsanfrage abgelehnt. + Achten Sie beim Angeben von `subnets` in der Erstellungsanfrage darauf, nur das Subnetz in derselben Availability Zone wie die Kapazitätsreservierung anzugeben. + Wenn Sie in der Erstellungsanforderung einen `desiredSize` ungleich Null angeben, berücksichtigt Amazon EKS dies beim Erstellen der Auto Scaling-Gruppe (ASG). Erfolgt die Erstellungsanfrage jedoch vor Aktivierung der Kapazitätsreservierung, kann die ASG keine Amazon-EC2-Instances starten, bis sie aktiviert wird. Dies führt dazu, dass bei ASG-Skalierungsaktivitäten Startfehler auftreten. Sobald die Reservierung aktiv wird, ist der Start der Instances erfolgreich und die ASG wird auf die bei der Erstellung angegebene `desiredSize` skaliert. ``` aws eks create-nodegroup \ --cluster-name my-cluster \ --nodegroup-name my-mng \ --node-role node-role-arn \ --region region-code \ --subnets subnet-id \ --scaling-config minSize=node-group-min-size,maxSize=node-group-max-size,desiredSize=node-group-desired-size \ --ami-type "AL2023_x86_64_NVIDIA" \ --capacity-type "CAPACITY_BLOCK" \ --launch-template id="lt-id",version=1 ``` 1. Stellen Sie sicher, dass die Knoten nach der Hochskalierung hinzugefügt werden. Amazon-EKS-Cluster, die verwaltete Knotengruppen mit Kapazitätsblöcken verwenden, führen keine Überprüfungen durch, ob die gestarteten Instances tatsächlich zum Cluster hinzugefügt und dort registriert werden. 1. Wenn Sie `desiredSize` beim Erstellen auf `0` setzen, haben Sie verschiedene Möglichkeiten, die Knotengruppe hoch zu skalieren, wenn die Kapazitätsreservierung aktiv wird: + Erstellen Sie eine geplante Skalierungsrichtlinie für die ASG, die mit dem Startzeitpunkt der Kapazitätsblock-Reservierung übereinstimmt. Weitere Informationen finden Sie unter [Geplante Skalierung für Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-scheduled-scaling.html) im *Amazon EC2 Auto Scaling-Benutzerhandbuch*. + Verwenden Sie die Amazon-EKS-Konsole oder `eks update-nodegroup-config`, um die Skalierungskonfiguration zu aktualisieren und die gewünschte Größe der Knotengruppe festzulegen. + Verwenden Sie den Kubernetes Cluster Autoscaler. Weitere Informationen finden Sie unter [Cluster Autoscaler on AWS](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md). 1. Die Knotengruppe ist jetzt bereit für die Planung von Workloads und Pods. 1. Damit Ihre Pods vor Ablauf der Reservierung ordnungsgemäß entleert werden, verwendet Amazon EKS eine geplante Skalierungsrichtlinie, um die Größe der Knotengruppe auf `0` herunterzuskalieren. Diese geplante Skalierung wird mit dem Namen `Amazon EKS Node Group Capacity Scaledown Before Reservation End` festgelegt. Wir empfehlen, diese Aktion nicht zu bearbeiten oder zu löschen. Amazon EC2 beginnt 30 Minuten vor Ablauf der Reservierungszeit mit dem Herunterfahren der Instances. Daher richtet Amazon EKS 40 Minuten vor dem Ende der Reservierung eine geplante Herunterskalierung der Knotengruppe ein, um Pods sicher und ordnungsgemäß zu entfernen. # Erstellung selbstverwalteter Knoten mit Kapazitätsblöcken für ML Kapazitätsblöcke für Machine Learning (ML) ermöglichen es Ihnen, GPU-Instances zu einem zukünftigen Zeitpunkt zu reservieren, um Ihre ML-Workloads mit kurzer Dauer zu unterstützen. Weitere Informationen finden Sie unter [Kapazitätsblöcke für ML](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-blocks.html) im *Amazon-EC2-Benutzerhandbuch für Linux-Instances*. ## Überlegungen **Wichtig** Kapazitätsblöcke sind nur für bestimmte Amazon-EC2-Instance-Typen und AWS-Regionen verfügbar. Informationen zur Kompatibilität finden Sie unter [Arbeiten mit Kapazitätsblöcken – Voraussetzungen](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/capacity-blocks-using.html#capacity-blocks-prerequisites) im *Amazon-EC2-Benutzerhandbuch für Linux-Instances*. Wenn Sie eine selbstverwaltete Knotengruppe erstellen, bevor die Kapazitätsreservierung aktiv wird, legen Sie die gewünschte Kapazität auf `0` fest. Um genügend Zeit zu haben, den/die Knoten ordnungsgemäß zu entleeren, empfehlen wir, die Skalierung so zu planen, dass sie mehr als 30 Minuten vor der Endzeit der Kapazitätsblock-Reservierung auf Null skaliert. Damit Ihre Pods ordnungsgemäß entladen werden, empfehlen wir Ihnen, den AWS Node Termination Handler wie in den Beispielschritten beschrieben einzurichten. ## Verwendung von Kapazitätsblöcken mit selbstverwalteten Knoten Sie können Kapazitätsblöcke mit Amazon EKS für die Bereitstellung und Skalierung Ihrer selbstverwalteten Knoten verwenden. Die folgenden Schritte geben einen allgemeinen Beispielüberblick. Die Beispiele für AWS CloudFormation-Vorlagen decken nicht alle Aspekte ab, die in einem Produktions-Workload erforderlich sind. Normalerweise benötigen Sie außerdem ein Bootstrapping-Skript, um den Knoten mit dem Cluster zu verbinden, ein beschleunigtes Amazon-EKS-AMI und ein entsprechendes Instance-Profil für den Beitritt zum Cluster anzugeben. Weitere Informationen finden Sie unter [Selbstverwaltete Amazon-Linux-Knoten erstellen](launch-workers.md). 1. Erstellen Sie eine Startvorlage, die auf Ihre Workload anwendbar ist. Weitere Informationen finden Sie unter [Verwenden von Kapazitätsblöcken für Machine Learning im](https://docs.aws.amazon.com/autoscaling/ec2/userguide/launch-template-capacity-blocks.html) *Benutzerhandbuch für Amazon EC2 Auto Scaling*. Stellen Sie sicher, dass `LaunchTemplateData` Folgendes enthält: + `InstanceMarketOptions` mit der Einstellung `"capacity-block"` für `MarketType` + `CapacityReservationSpecification: CapacityReservationTarget` mit `CapacityReservationId` als Kapazitätsblock (zum Beispiel: `cr-02168da1478b509e0 `) + `IamInstanceProfile` mit `Arn` auf das entsprechende *iam-instance-profile-arn* eingestellt + `ImageId` auf das entsprechende *image-id* eingestellt + `InstanceType` auf einen Instance-Typ eingestellt, der Kapazitätsblöcke unterstützt (zum Beispiel: *p5.48xlarge*) + `SecurityGroupIds` auf die entsprechenden IDs eingestellt (zum Beispiel: *sg-05b1d815d1EXAMPLE*) + `UserData` auf die entsprechende *user-data* für Ihre selbstverwaltete Knotengruppe eingestellt Nachfolgend finden Sie einen Auszug aus einer CloudFormation-Vorlage, die eine Startvorlage für einen Kapazitätsblock erstellt. ``` NodeLaunchTemplate: Type: "aws::EC2::LaunchTemplate" Properties: LaunchTemplateData: InstanceMarketOptions: MarketType: "capacity-block" CapacityReservationSpecification: CapacityReservationTarget: CapacityReservationId: "cr-02168da1478b509e0" IamInstanceProfile: Arn: iam-instance-profile-arn ImageId: image-id InstanceType: p5.48xlarge KeyName: key-name SecurityGroupIds: - sg-05b1d815d1EXAMPLE UserData: user-data ``` Sie müssen das Subnetz in der Availability Zone übergeben, in der die Reservierung vorgenommen wurde, da Kapazitätsblöcke zonal sind. 1. Verwenden Sie die Startvorlage, um eine selbstverwaltete Knotengruppe zu erstellen. Wenn Sie dies vor der Aktivierung der Kapazitätsreservierung tun, legen Sie die gewünschte Kapazität auf `0` fest. Achten Sie beim Erstellen der Knotengruppe darauf, dass Sie nur das entsprechende Subnetz für die Availability Zone angeben, in der die Kapazität reserviert ist. Nachfolgend finden Sie ein Beispiel für eine CloudFormation-Vorlage, die Sie als Referenz verwenden können, wenn Sie eine für Ihre Workload geeignete Vorlage erstellen. In diesem Beispiel werden die `LaunchTemplateId` und das `Version` der im vorherigen Beispiel gezeigten ` AWS::Amazon EC2::LaunchTemplate`-Ressource ermittelt. Sie erhält auch die Werte für `DesiredCapacity`, `MaxSize`, `MinSize`, und `VPCZoneIdentifier`, die an anderer Stelle in derselben Vorlage deklariert sind. ``` NodeGroup: Type: "AWS::AutoScaling::AutoScalingGroup" Properties: DesiredCapacity: !Ref NodeAutoScalingGroupDesiredCapacity LaunchTemplate: LaunchTemplateId: !Ref NodeLaunchTemplate Version: !GetAtt NodeLaunchTemplate.LatestVersionNumber MaxSize: !Ref NodeAutoScalingGroupMaxSize MinSize: !Ref NodeAutoScalingGroupMinSize VPCZoneIdentifier: !Ref Subnets Tags: - Key: Name PropagateAtLaunch: true Value: !Sub ${ClusterName}-${NodeGroupName}-Node - Key: !Sub kubernetes.io/cluster/${ClusterName} PropagateAtLaunch: true Value: owned ``` 1. Nachdem die Knotengruppe erfolgreich erstellt wurde, stellen Sie sicher, dass Sie die `NodeInstanceRole` für die Knotengruppe aufzeichnen, die erstellt wurde. Dies ist erforderlich, um sicherzustellen, dass bei einer Skalierung der Knotengruppe die neuen Knoten dem Cluster beitreten und Kubernetes die Knoten erkennen kann. Weitere Informationen finden Sie in den AWS-Managementkonsole-Anweisungen unter [Erstellen selbstverwalteter Amazon Linux-Knoten](launch-workers.md). 1. Wir empfehlen Ihnen, eine geplante Skalierungsrichtlinie für die Auto-Scaling-Gruppe zu erstellen, die sich an den Reservierungszeiten für Kapazitätsblöcke orientiert. Weitere Informationen finden Sie unter [Geplante Skalierung für Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-scheduled-scaling.html) im *Amazon EC2 Auto Scaling-Benutzerhandbuch*. Sie können alle von Ihnen reservierten Instances bis 30 Minuten vor Ablauf der Endzeit des Kapazitätsblocks verwenden. Instances, die zu diesem Zeitpunkt noch laufen, werden beendet. Um genügend Zeit zu haben, den/die Knoten ordnungsgemäß zu entleeren, empfehlen wir, die Skalierung so zu planen, dass sie mehr als 30 Minuten vor der Endzeit der Kapazitätsblock-Reservierung auf Null skaliert. Wenn Sie stattdessen manuell hochskalieren wollen, wenn die Kapazitätsreservierung `Active` wird, müssen Sie die gewünschte Kapazität der Auto-Scaling-Gruppe zum Startzeitpunkt der Kapazitätsblock-Reservierung aktualisieren. Dann müssten Sie auch mehr als 30 Minuten vor dem Ende der Kapazitätsblock-Reservierung manuell herunterskalieren. 1. Die Knotengruppe ist jetzt bereit für die Planung von Workloads und Pods. 1. Damit Ihre Pods ordnungsgemäß entleert werden kann, empfehlen wir Ihnen, AWS Node Termination Handler einzurichten. Dieser Handler kann mithilfe von EventBridge nach „ASG Scale-in“-Lebenszyklusereignissen von Amazon EC2 Auto Scaling Ausschau halten und es der Kubernetes-Steuerebene ermöglichen, die erforderlichen Maßnahmen zu ergreifen, bevor die Instance nicht verfügbar ist. Andernfalls bleiben Ihre Pods und Kubernetes-Objekte in einem ausstehenden Zustand hängen. Weitere Informationen finden Sie unter [AWS Node Termination Handler](https://github.com/aws/aws-node-termination-handler) auf GitHub. Wenn Sie keinen Node Termination Handler einrichten, empfehlen wir Ihnen, mit der manuellen Entleerung Ihrer Pods zu beginnen, bevor das 30-Minuten-Fenster erreicht ist, damit sie genügend Zeit haben, um ordnungsgemäß entleert zu werden. # Verwenden Sie P6e- GB200 UltraServers mit Amazon EKS In diesem Thema wird beschrieben, wie Amazon EKS mit P6e- konfiguriert und verwendet wird. GB200 UltraServers Der `p6e-gb200.36xlarge` Instance-Typ mit 4 NVIDIA Blackwell GPUs ist nur als P6e- verfügbar. GB200 UltraServers Es gibt zwei Arten von P6e-. GB200 UltraServers Der `u-p6e-gb200x36` UltraServer hat 9 `p6e-gb200.36xlarge` Instanzen und der `u-p6e-gb200x72` UltraServer hat 18 `p6e-gb200.36xlarge` Instanzen. Weitere Informationen finden Sie auf der [Amazon EC2 P6e-Webseite. GB200 UltraServers ](https://aws.amazon.com/ec2/instance-types/p6/) ## Überlegungen + Amazon EKS unterstützt P6e- GB200 UltraServers für Kubernetes-Versionen 1.33 und höher. [Diese Kubernetes-Version bietet Unterstützung für [Dynamic Resource Allocation](https://kubernetes.io/docs/concepts/scheduling-eviction/dynamic-resource-allocation/) (DRA), die standardmäßig in EKS und in der EKS-optimierten beschleunigten Version aktiviert ist. AL2023 AMIs](https://docs.aws.amazon.com/eks/latest/userguide/ml-eks-optimized-ami.html) DRA ist eine Voraussetzung für die Verwendung von P6e- mit EKS. GB200 UltraServers DRA wird im automatischen Modus von Karpenter oder EKS nicht unterstützt, und es wird empfohlen, selbstverwaltete EKS-Knotengruppen oder EKS-verwaltete Knotengruppen zu verwenden, wenn Sie den P6e- mit EKS verwenden. GB200 UltraServers + [P6e- GB200 UltraServers werden über EC2 Capacity Blocks für ML verfügbar gemacht.](https://aws.amazon.com/ec2/capacityblocks/) Informationen [Rechenressourcen für AI/ML Workloads auf Amazon EKS verwalten](ml-compute-management.md) zum Starten von EKS-Knoten mit Capacity-Blöcken finden Sie unter. + Wenn Sie von EKS verwaltete Knotengruppen mit Kapazitätsblöcken verwenden, müssen Sie benutzerdefinierte Startvorlagen verwenden. Wenn Sie von EKS verwaltete Knotengruppen mit P6e- aktualisieren GB200 UltraServers, müssen Sie `0` vor dem Upgrade die gewünschte Größe der Knotengruppe auf einstellen. + Es wird empfohlen, die AL2023 ARM NVIDIA-Variante des EKS-optimierten Beschleunigers zu verwenden. AMIs Dieses AMI enthält die erforderlichen Knotenkomponenten und die Konfiguration für die Arbeit mit P6e-. GB200 UltraServers Wenn Sie sich entscheiden, Ihr eigenes AMI zu erstellen, sind Sie für die Installation und Überprüfung der Kompatibilität der Knoten- und Systemsoftware, einschließlich der Treiber, verantwortlich. Weitere Informationen finden Sie unter [Verwenden Sie EKS-optimierte beschleunigte AMIs GPU-Instanzen](ml-eks-optimized-ami.md). + Es wird empfohlen, die EKS-optimierte AMI-Version `v20251103` oder höher zu verwenden, die die NVIDIA-Treiberversion 580 enthält. Diese NVIDIA-Treiberversion ermöglicht Coherent Driver-Based Memory (CDMM), um potenziellen Speicherüberschüssen entgegenzuwirken. Wenn CDMM aktiviert ist, werden die folgenden Funktionen nicht unterstützt: NVIDIA Multi-Instance-GPU (MIG) und vGPU. Weitere Informationen zu CDMM finden Sie unter [NVIDIA Coherent Driver-based Memory](https://nvdam.widen.net/s/gpqp6wmz7s/cuda-whitepaper—​cdmm-pdf) Management (CDMM). + Wenn Sie den [NVIDIA-GPU-Operator](https://docs.nvidia.com/datacenter/cloud-native/gpu-operator/latest/overview.html) mit dem EKS-optimierten AL2023 NVIDIA-AMI verwenden, müssen Sie die Operatorinstallation des Treibers und des Toolkits deaktivieren, da diese bereits im AMI enthalten sind. Das EKS-optimierte AL2023 NVIDIA enthält AMIs weder das NVIDIA Kubernetes-Geräte-Plugin noch den NVIDIA DRA-Treiber, und diese müssen separat installiert werden. + Jede `p6e-gb200.36xlarge` Instanz kann mit bis zu 17 Netzwerkkarten konfiguriert werden und EFA für die Kommunikation zwischen ihnen nutzen. UltraServers Der Netzwerkverkehr kann Workloads durchqueren UltraServers, aber für eine optimale Leistung wird empfohlen, Workloads nach demselben Schema zu planen und dabei IMEX für die GPU-interne Kommunikation zu UltraServer nutzen. UltraServer Weitere Informationen finden Sie unter [EFA-Konfiguration für P6e-Instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa-acc-inst-types.html#efa-for-p6e). GB200 + [Jede `p6e-gb200.36xlarge` Instance verfügt über 3 x 7,5 TB Instance-Speicher.](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/InstanceStorage.html) Standardmäßig formatiert und mountet das EKS-optimierte AMI die Instance-Speicher nicht. Der kurzlebige Speicher des Knotens kann von Pods gemeinsam genutzt werden, die kurzlebigen Speicher anfordern, und von Container-Images, die auf den Knoten heruntergeladen werden. Wenn Sie das AL2023 EKS-optimierte AMI verwenden, kann dies als Teil des Knoten-Bootstraps in den Benutzerdaten konfiguriert werden, indem die lokale Speicherrichtlinie der Instanz auf eingestellt wird. [NodeConfig](https://docs.aws.amazon.com/eks/latest/eksctl/node-bootstrapping.html#configuring-the-bootstrapping-process) RAID0 Bei Einstellung auf RAID0 Stripe speichert und konfiguriert die Instance die Container-Runtime und Kubelet, um diesen kurzlebigen Speicher zu nutzen. ## Komponenten Die folgenden Komponenten werden für die Ausführung von Workloads auf EKS mit dem P6e- empfohlen. GB200 UltraServers Sie können optional den [NVIDIA-GPU-Operator verwenden, um die NVIDIA-Knotenkomponenten](https://docs.nvidia.com/datacenter/cloud-native/gpu-operator/latest/overview.html) zu installieren. Wenn Sie den NVIDIA-GPU-Operator mit dem EKS-optimierten AL2023 NVIDIA-AMI verwenden, müssen Sie die Operatorinstallation des Treibers und des Toolkits deaktivieren, da diese bereits im AMI enthalten sind. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/eks/latest/userguide/ml-eks-nvidia-ultraserver.html) Die Knotenkomponenten in der obigen Tabelle erfüllen die folgenden Funktionen: + **VPC CNI**: Weist VPC IPs als primäre Netzwerkschnittstelle für Pods zu, die auf EKS ausgeführt werden + **EFA-Geräte-Plugin: Weist** EFA-Geräte als sekundäre Netzwerke für Pods zu, die auf EKS ausgeführt werden. Verantwortlich für den Netzwerkverkehr über P6e-. GB200 UltraServers Für Workloads mit mehreren Knoten, für GPU-to-GPU innerhalb eines UltraServer Kanals, der über mehrere Knoten fließt. NVLink + **NVIDIA Kubernetes-Geräte-Plugin**: Weist Pods, die auf EKS laufen, GPUs als Geräte zu. Es wird empfohlen, das NVIDIA Kubernetes-Geräte-Plugin zu verwenden, bis die GPU-Zuweisungsfunktion des NVIDIA DRA-Treibers den experimentellen Status erreicht hat. Aktuelle Informationen finden Sie in den [NVIDIA-DRA-Treiberversionen](https://github.com/NVIDIA/k8s-dra-driver-gpu/releases). + **NVIDIA-DRA-Treiber**: Ermöglicht ComputeDomain benutzerdefinierte Ressourcen, die die Erstellung von IMEX-Domänen erleichtern, die Workloads folgen, die auf P6e- ausgeführt werden. GB200 UltraServers + Die ComputeDomain Ressource beschreibt eine IMEX-Domäne (Internode Memory Exchange). Wenn Workloads mit einem ResourceClaim for a auf dem Cluster bereitgestellt ComputeDomain werden, erstellt der NVIDIA DRA-Treiber automatisch ein IMEX, DaemonSet das auf passenden Knoten ausgeführt wird, und richtet die IMEX-Kanäle zwischen den Knoten ein, bevor der Workload gestartet wird. Weitere Informationen zu IMEX finden Sie in [der Übersicht über NVIDIA IMEX](https://docs.nvidia.com/multi-node-nvlink-systems/imex-guide/overview.html) für Systeme mit mehreren Knoten. NVLink + Der NVIDIA-DRA-Treiber verwendet ein von NVIDIA GFD verwendetes Clique-ID-Label (`nvidia.com/gpu.clique`), das Informationen über die Netzwerktopologie und -domäne weitergibt. NVLink + Es hat sich bewährt, einen Job pro Workload zu erstellen ComputeDomain . + **NVIDIA Node Feature Discovery (NFD)**: Erforderliche Abhängigkeit für GFD, um Knotenbezeichnungen auf der Grundlage der erkannten Attribute auf Knotenebene anzuwenden. + **NVIDIA GPU Feature Discovery (GFD)**: Wendet ein NVIDIA-Standard-Topologie-Label an, das auf die Knoten aufgerufen wird. `nvidia.com/gpu.clique` Knoten innerhalb desselben Systems `nvidia.com/gpu.clique` sind über mehrere Knoten erreichbar NVLink, und Sie können Pod-Affinitäten in Ihrer Anwendung verwenden, um Pods für dieselbe Domain zu planen. NVlink ## Verfahren Im folgenden Abschnitt wird davon ausgegangen, dass Sie über einen EKS-Cluster verfügen, auf dem Kubernetes Version 1.33 oder höher ausgeführt wird und über eine oder mehrere Knotengruppen mit P6e verfügt, auf GB200 UltraServers denen das für AL2023 ARM NVIDIA EKS optimierte beschleunigte AMI ausgeführt wird. Die erforderlichen Schritte [Rechenressourcen für AI/ML Workloads auf Amazon EKS verwalten](ml-compute-management.md) für selbstverwaltete EKS-Knoten und verwaltete Knotengruppen finden Sie unter den Links unter. Das folgende Verfahren verwendet die folgenden Komponenten. | Name | Version | Description | | --- | --- | --- | | NVIDIA-GPU-Betreiber | 25.3.4\$1 | Für das Lebenszyklusmanagement erforderlicher Plug-ins wie NVIDIA Kubernetes Device Plugin und NFD/GFD. | | NVIDIA DRA-Treiber | 25.8.0 oder höher | Für ComputeDomain CRDs und IMEX-Domainverwaltung. | | EFA-Geräte-Plugin | 0.5.14\$1 | Für die übergreifende Kommunikation. UltraServer | ## Installieren Sie den NVIDIA GPU-Operator Der NVIDIA-GPU-Operator vereinfacht die Verwaltung der Komponenten, die für die Verwendung GPUs in Kubernetes-Clustern erforderlich sind. Da der NVIDIA-GPU-Treiber und das Container-Toolkit als Teil des EKS-optimierten beschleunigten AMI installiert werden, müssen diese `false` in der Konfiguration der Helm-Werte auf eingestellt werden. 1. Erstellen Sie eine Helm-Wertedatei `gpu-operator-values.yaml` mit dem Namen der folgenden Konfiguration. ``` devicePlugin: enabled: true nfd: enabled: true gfd: enabled: true driver: enabled: false toolkit: enabled: false migManager: enabled: false ``` 1. Installieren Sie den NVIDIA-GPU-Operator für Ihren Cluster mithilfe der `gpu-operator-values.yaml` Datei, die Sie im vorherigen Schritt erstellt haben. ``` helm repo add nvidia https://helm.ngc.nvidia.com/nvidia helm repo update ``` ``` helm install gpu-operator nvidia/gpu-operator \ --namespace gpu-operator \ --create-namespace \ --version v25.3.4 \ --values gpu-operator-values.yaml ``` ## Installieren Sie den NVIDIA DRA-Treiber Ab der NVIDIA-GPU-Operatorversion `v25.3.4` muss der NVIDIA-DRA-Treiber separat installiert werden. Es wird empfohlen, die [Versionshinweise](https://github.com/NVIDIA/gpu-operator/releases) zum NVIDIA-GPU-Operator zu lesen, da sich dies in einer future Version ändern kann. 1. Erstellen Sie eine Helm-Wertedatei `dra-values.yaml` mit dem Namen der folgenden Konfiguration. Beachten Sie das `nodeAffinity` und `tolerations` das konfiguriert den DRA-Treiber so, dass er nur auf Knoten mit einer NVIDIA-GPU bereitgestellt wird. ``` resources: gpus: enabled: false # set to false to disable experimental gpu support computeDomains: enabled: true controller: nodeSelector: null affinity: null tolerations: [] kubeletPlugin: affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: "nvidia.com/gpu.present" operator: In values: - "true" tolerations: - key: "nvidia.com/gpu" operator: Exists effect: NoSchedule ``` 1. Installieren Sie den NVIDIA-DRA-Treiber für Ihren Cluster mithilfe der `dra-values.yaml` Datei, die Sie im vorherigen Schritt erstellt haben. ``` helm repo add nvidia https://helm.ngc.nvidia.com/nvidia helm repo update ``` ``` helm install nvidia-dra-driver-gpu nvidia/nvidia-dra-driver-gpu \ --version="25.8.0" \ --namespace nvidia-dra-driver-gpu \ --create-namespace \ -f dra-values.yaml ``` 1. Nach der Installation erstellt der DRA-Treiber `DeviceClass` Ressourcen, die es Kubernetes ermöglichen, Ressourcen zu verstehen und zuzuweisen`ComputeDomain`, sodass das IMEX-Management für verteilte GPU-Workloads auf P6e- möglich ist. GB200 UltraServers Stellen Sie mit den folgenden Befehlen sicher, dass die DRA-Ressourcen verfügbar sind. ``` kubectl api-resources | grep resource.k8s.io ``` ``` deviceclasses resource.k8s.io/v1 false DeviceClass resourceclaims resource.k8s.io/v1 true ResourceClaim resourceclaimtemplates resource.k8s.io/v1 true ResourceClaimTemplate resourceslices resource.k8s.io/v1 false ResourceSlice ``` ``` kubectl get deviceclasses ``` ``` NAME compute-domain-daemon.nvidia.com compute-domain-default-channel.nvidia.com ``` ## Installieren Sie das EFA-Geräte-Plugin Um die EFA-Kommunikation zwischen nutzen zu können UltraServers, müssen Sie das Kubernetes-Geräte-Plugin für EFA installieren. GB200 P6e-Instances können mit bis zu [17 Netzwerkkarten](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa-acc-inst-types.html#efa-for-p6e) konfiguriert werden, und das primäre NCI (Index 0) muss vom Typ sein und bis zu 100 Gbit/s `interface` ENA-Bandbreite unterstützen. Konfigurieren Sie Ihre EFA- und ENA-Schnittstellen bei der Knotenbereitstellung gemäß Ihren Anforderungen. Weitere Informationen [zur EFA-Konfiguration finden Sie in der Dokumentation zu GB200 P6e-Instanzen in der AWS Dokumentation](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa-acc-inst-types.html#efa-for-p6e) zur EFA-Konfiguration. 1. Erstellen Sie eine Helm-Wertedatei `efa-values.yaml` mit dem Namen der folgenden Konfiguration. ``` tolerations: - key: nvidia.com/gpu operator: Exists effect: NoSchedule ``` 1. Installieren Sie den NVIDIA DRA-Operator für Ihren Cluster mithilfe der `dra-values.yaml` Datei, die Sie im vorherigen Schritt erstellt haben. ``` helm repo add eks https://aws.github.io/eks-charts helm repo update ``` ``` helm install efa eks/aws-efa-k8s-device-plugin -n kube-system \ --version="0.5.14" \ -f efa-values.yaml ``` Wenn Sie Ihre Instances beispielsweise mit einer reinen EFA-Schnittstelle in jeder [NCI-Gruppe](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa-acc-inst-types.html#efa-for-p6e) konfiguriert haben, wird bei der Beschreibung eines Knotens davon ausgegangen, dass pro Knoten 4 zuweisbare EFA-Geräte vorhanden sind. ``` kubectl describe node/ ``` ``` Capacity: ... vpc.amazonaws.com/efa: 4 Allocatable: ... vpc.amazonaws.com/efa: 4 ``` ## Validieren Sie IMEX über Multi-Node NVLink Einen NVLINK-NCCL-Test mit mehreren Knoten und andere Mikro-Benchmarks finden Sie im Repository. [awesome-distributed-training](https://github.com/aws-samples/awsome-distributed-training/tree/main/micro-benchmarks/nccl-tests) GitHub Die folgenden Schritte zeigen, wie Sie einen Test mit mehreren Knoten mit nvbandwidth durchführen. NVLink 1. Um einen Bandbreitentest mit mehreren Knoten auf zwei Knoten in der NVL72 Domäne durchzuführen, installieren Sie zunächst den MPI-Operator: ``` kubectl create -f https://github.com/kubeflow/mpi-operator/releases/download/v0.7.0/mpi-operator.yaml ``` 1. Erstellen Sie eine Helm-Wertedatei mit dem Namen`nvbandwidth-test-job.yaml`, die das Testmanifest definiert. Beachten Sie die `nvidia.com/gpu.clique` Pod-Affinität, die Worker in derselben NVLink Domäne einzuplanen, die über mehrere Knoten erreichbar NVLink ist. Im folgenden Beispiel wird ein device-to-device CE Read-Memcpy-Test mit mehreren Knoten ausgeführt cuMemcpyAsync und die Ergebnisse werden in den Protokollen gedruckt. Ab der NVIDIA DRA-Treiberversion `v25.8.0` ComputeDomains sind sie elastisch und `.spec.numNodes` können `0` in der Definition auf eingestellt werden. ComputeDomain Informationen zu Updates finden Sie in den neuesten [Versionshinweisen zum NVIDIA DRA-Treiber](https://github.com/NVIDIA/k8s-dra-driver-gpu). ``` --- apiVersion: resource.nvidia.com/v1beta1 kind: ComputeDomain metadata: name: nvbandwidth-test-compute-domain spec: numNodes: 0 # This can be set to 0 from NVIDIA DRA Driver version v25.8.0+ channel: resourceClaimTemplate: name: nvbandwidth-test-compute-domain-channel --- apiVersion: kubeflow.org/v2beta1 kind: MPIJob metadata: name: nvbandwidth-test spec: slotsPerWorker: 4 # 4 GPUs per worker node launcherCreationPolicy: WaitForWorkersReady runPolicy: cleanPodPolicy: Running sshAuthMountPath: /home/mpiuser/.ssh mpiReplicaSpecs: Launcher: replicas: 1 template: metadata: labels: nvbandwidth-test-replica: mpi-launcher spec: affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: # Only schedule on NVIDIA GB200/GB300 nodes - key: node.kubernetes.io/instance-type operator: In values: - p6e-gb200.36xlarge - p6e-gb300.36xlarge containers: - image: ghcr.io/nvidia/k8s-samples:nvbandwidth-v0.7-8d103163 name: mpi-launcher securityContext: runAsUser: 1000 command: - mpirun args: - --bind-to - core - --map-by - ppr:4:node - -np - "8" - --report-bindings - -q - nvbandwidth - -t - multinode_device_to_device_memcpy_read_ce Worker: replicas: 2 # 2 worker nodes template: metadata: labels: nvbandwidth-test-replica: mpi-worker spec: affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: # Only schedule on NVIDIA GB200/GB300 nodes - key: node.kubernetes.io/instance-type operator: In values: - p6e-gb200.36xlarge - p6e-gb300.36xlarge podAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: nvbandwidth-test-replica operator: In values: - mpi-worker topologyKey: nvidia.com/gpu.clique containers: - image: ghcr.io/nvidia/k8s-samples:nvbandwidth-v0.7-8d103163 name: mpi-worker securityContext: runAsUser: 1000 env: command: - /usr/sbin/sshd args: - -De - -f - /home/mpiuser/.sshd_config resources: limits: nvidia.com/gpu: 4 # Request 4 GPUs per worker claims: - name: compute-domain-channel # Link to IMEX channel resourceClaims: - name: compute-domain-channel resourceClaimTemplateName: nvbandwidth-test-compute-domain-channel ``` 1. Erstellen Sie den Job ComputeDomain und starten Sie ihn mit dem folgenden Befehl. ``` kubectl apply -f nvbandwidth-test-job.yaml ``` 1. ComputeDomain Bei der Erstellung können Sie sehen, dass der ComputeDomain Workload aus zwei Knoten besteht: ``` kubectl get computedomains.resource.nvidia.com -o yaml ``` ``` status: nodes: - cliqueID: . ipAddress: name: - cliqueID: . ipAddress: name: status: Ready ``` 1. Überprüfen Sie die Ergebnisse des Jobs mit dem folgenden Befehl. ``` kubectl logs --tail=-1 -l job-name=nvbandwidth-test-launcher ``` Bei einem erfolgreichen Test werden Bandbreitenstatistiken GB/s für den Memcpy-Test mit mehreren Knoten angezeigt. Ein Beispiel für eine erfolgreiche Testausgabe ist unten dargestellt. ``` ... nvbandwidth Version: ... Built from Git version: ... MPI version: ... CUDA Runtime Version: ... CUDA Driver Version: ... Driver Version: ... Process 0 (nvbandwidth-test-worker-0): device 0: NVIDIA GB200 (...) Process 1 (nvbandwidth-test-worker-0): device 1: NVIDIA GB200 (...) Process 2 (nvbandwidth-test-worker-0): device 2: NVIDIA GB200 (...) Process 3 (nvbandwidth-test-worker-0): device 3: NVIDIA GB200 (...) Process 4 (nvbandwidth-test-worker-1): device 0: NVIDIA GB200 (...) Process 5 (nvbandwidth-test-worker-1): device 1: NVIDIA GB200 (...) Process 6 (nvbandwidth-test-worker-1): device 2: NVIDIA GB200 (...) Process 7 (nvbandwidth-test-worker-1): device 3: NVIDIA GB200 (...) Running multinode_device_to_device_memcpy_read_ce. memcpy CE GPU(row) -> GPU(column) bandwidth (GB/s) 0 1 2 3 4 5 6 7 0 N/A 821.45 822.18 821.73 822.05 821.38 822.61 821.89 1 822.34 N/A 821.67 822.12 821.94 820.87 821.53 822.08 2 821.76 822.29 N/A 821.58 822.43 821.15 821.82 822.31 3 822.19 821.84 822.05 N/A 821.67 821.23 820.95 822.47 4 821.63 822.38 821.49 822.17 N/A 821.06 821.78 822.22 5 822.08 821.52 821.89 822.35 821.27 N/A 821.64 822.13 6 821.94 822.15 821.68 822.04 821.39 820.92 N/A 822.56 7 822.27 821.73 822.11 821.86 822.38 821.04 821.49 N/A SUM multinode_device_to_device_memcpy_read_ce ... NOTE: The reported results may not reflect the full capabilities of the platform. Performance can vary with software drivers, hardware clocks, and system topology. ``` 1. Wenn der Test abgeschlossen ist, löschen Sie ihn mit dem folgenden Befehl. ``` kubectl delete -f nvbandwidth-test-job.yaml ```