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.
Verwaltung beschleunigter Rechenleistung für AI/ML Workloads auf Amazon EKS
Tipp
Melden Sie sich
In diesem Abschnitt wird beschrieben, wie Sie EC2 Accelerated Compute-Instances für AI/ML Trainings- und Inferenz-Workloads mit Amazon EKS erwerben und bereitstellen. Ganz gleich, ob Sie groß angelegte Modelle trainieren, Inferenzen in Echtzeit ausführen oder generative KI-Anwendungen bereitstellen, die Verwendung der richtigen NVIDIA-GPU- oder AWS Trainium-Kapazität ist für die Leistung Ihrer Workloads von grundlegender Bedeutung.
Wählen Sie aus EC2-Instance-Typen
Einzelheiten zu den verfügbaren Amazon EC2 Accelerated Compute-Instances finden Sie in den Spezifikationen für Amazon EC2 Accelerated Computing Instances. Dazu gehören NVIDIA-GPU-Instances von P-family und sowie die von G-family ihnen AWS entwickelten Beschleuniger Trainium und Inferentia.
Machen Sie sich mit den EC2-Kaufoptionen vertraut
Sobald Sie wissen, welche beschleunigten Instances Sie für Ihre Workloads benötigen, müssen Sie sich im nächsten Schritt mit den Kaufoptionen vertraut machen, die für den Erwerb dieser beschleunigten Instance-Typen verfügbar sind. AWS bietet vier Kaufoptionen für Rechenkapazität: On-Demand Instances, Spot-Instances, Capacity Blocks for ML und On-Demand Capacity Reservations (ODCRs). Jede Option erfüllt unterschiedliche Workload-Muster, Kostenprofile und Verfügbarkeitsanforderungen. In der Dokumentation zu den Kaufoptionen für Amazon EC2 EC2-Instances wird erklärt, wie die einzelnen Optionen funktionieren, welches Preismodell sie haben und wann sie verwendet werden sollten.
-
On-Demand Instances: Zahlen Sie unverbindlich und sekundengenau und sind sofort verfügbar, wenn Kapazität vorhanden ist. Ideal für Entwicklung, Prototyping, unvorhersehbare Skalierung von Inferenzen und alle Workloads, die sofort und ohne Unterbrechungsrisiko verarbeitet werden müssen.
-
Spot-Instances: Einsparungen von bis zu 90% gegenüber der Nutzung On-Demand von EC2-Reservekapazitäten mit einer Unterbrechungsbenachrichtigung von 2 Minuten. Ideal für fehlertolerante Workloads, bei denen auf dauerhaften Speicher zurückgegriffen wird: Hyperparameter-Tuning, verteiltes Training mit regelmäßigen Checkpoints, Batch- und Offline-Inferenz sowie Pipelines zur Datenvorverarbeitung.
-
Kapazitätsblöcke für ML: Reserve P-family - und Trainium-Instances für ein festes Zeitfenster (24 Stunden, bis zu 6 Monate), bis zu 8 Wochen im Voraus gebucht und mit garantierter Verfügbarkeit. Ideal für geplante groß angelegte Trainingsläufe, zeitgebundene Feinabstimmungsexperimente und Forschungsprojekte mit bekannten Zeitplänen, die ununterbrochenen Zugriff auf einen GPU-Cluster benötigen.
-
On-Demand Kapazitätsreservierungen (ODCRs): Reservieren Sie beschleunigte Kapazität in einer bestimmten Availability Zone ohne langfristige Bindung. Die Abrechnung erfolgt zu On-Demand Standardpreisen, unabhängig davon, ob die Kapazität genutzt wird oder nicht. Ideal für Produktionsinferenz, SLA-bound Services und geschäftskritische Anwendungen, bei denen Terminverzögerungen oder Kapazitätsausfälle nicht akzeptabel sind. Im Gegensatz zu Capacity Blocks unterstützen ODCRs sowohl als auch Instances. P-family G-family
Passen Sie die Kaufoptionen an die Workload-Anforderungen an
Nachdem Sie die beschleunigten Instance-Typen und Kaufoptionen verstanden haben, besteht der nächste Schritt darin, die richtige Kaufoption an Ihre Workload-spezifischen Anforderungen anzupassen. Workloads mit größerer Flexibilität in Bezug auf Instance-Typen, Regionen und Timing qualifizieren sich für mehr Kaufoptionen und niedrigere Preise.
Stützen Sie Ihre Entscheidung auf Faktoren wie:
-
Strategische Bedeutung und SLA-Verpflichtungen
-
Vorhersagbarkeit der Nachfrage und Flexibilität bei der Terminplanung
-
Bereitschaft, sich im Voraus auf reservierte Kapazitäten festzulegen
-
Flexibilität in Bezug auf Instance-Typen, Regionen und Timing
-
Toleranz gegenüber Unterbrechungen im Vergleich zu Kosteneinsparungen
In der Praxis verfolgen Teams einen hybriden Ansatz, bei dem mehrere Kaufoptionen kombiniert werden, um ein ausgewogenes Verhältnis zwischen Kosten, Verfügbarkeit und Zuverlässigkeit in ihrem Workload-Portfolio zu erreichen. Der Artikel How to GU Capacity On AWS
Überprüfen Sie Ihre EC2-Servicekontingenten
Bevor Sie eine Option zum Kauf von Kapazitäten in Ihrem EKS-Cluster implementieren, stellen Sie sicher, dass Ihr AWS Konto über ein ausreichendes vCPU-Kontingent für die GPU-Instance-Familien verfügt, die Sie verwenden möchten. Ohne angemessene Kontingente können Karpenter NodePools, EKS Auto Mode Provisioning und EKS-Knotengruppen unabhängig von der ausgewählten Kaufoption keine beschleunigten Rechenknoten starten.
AWS erzwingt separate vCPU-Kontingente pro Instanzfamilie und Kaufmodell. Sehen Sie sich die Kontingente für den Amazon EC2 EC2-Instance-Typ an, um mehr über die Standardkontingente für beschleunigte Recheninstanzen zu erfahren.
Diese Kontingente basieren auf der Anzahl der vCPUs, nicht auf der Anzahl der Instanzen. Für den Start von 10 p6-b300.48xlarge-Instances sind beispielsweise 1.920 vCPUs (10 × 192) erforderlich. Die standardmäßigen GPU-Kontingente sind für neue Konten häufig auf 0 festgelegt, sodass die Anfrage erhöht wird, bevor versucht wird, Instances bereitzustellen.
Wenn Sie beim Erstellen von Kapazitätsblock-Reservierungen, beim Starten von On-Demand Instances oder beim Einreichen von Spot-Anfragen auf Kontingentbeschränkungen stoßen, wenden Sie sich an den AWS Support oder Ihr AWS Account-Team, um Ihre Anforderungen zu besprechen und Optionen zur Sicherung der beschleunigten Rechenkapazität zu prüfen, die Ihren Anforderungen am besten entspricht.
Verwenden Sie EC2-Kaufoptionen mit Amazon EKS
Nachdem Sie eine Kaufoption für EC2 Accelerated Compute ausgewählt haben, konfigurieren Sie Ihren Amazon EKS-Cluster so, dass er die Kapazität nutzt. Amazon EKS bietet drei Bereitstellungsmethoden mit jeweils unterschiedlicher Balance zwischen Kontrolle und Automatisierung:
-
Amazon EKS Auto Mode: AWS verwaltete Rechenleistung, die Knoten automatisch bereitstellt, skaliert und patcht. Verwendet den integrierten Karpenter für die Bereitstellung und das Bottlerocket-Betriebssystem mit NVIDIA-Treibern und Geräte-Plug-ins. Am besten, wenn Sie eine verwaltete Infrastruktur mit minimalem Betriebsaufwand wünschen. Unterstützt sowohl statische als auch dynamische Kapazitätsbereitstellung.
-
Karpenter (selbstverwaltet): Open-Source-Upstream-Projekt, das Sie in Ihrem Amazon EKS-Cluster installieren und betreiben. Bietet dasselbe Bereitstellungsmodell wie der automatische Modus von EKS und Sie haben die volle Kontrolle über Betriebssystem, AMIs, Kernel-Tuning und Knotenlebenszyklus. Am besten geeignet für Plattformteams mit Anforderungen, die EKS Auto Mode nicht standardmäßig bietet.
-
Knotengruppen (verwaltet und selbst verwaltet): Die Kapazität wird von EC2 Auto Scaling Groups (ASG) unterstützt und im Voraus über eine EC2-Startvorlage definiert. Ideal für Plattformteams mit bestehenden, von EKS verwalteten oder selbstverwalteten Knotengruppen sowie für Trainingsworkloads mit vorhersehbarer Größe und einem bekannten, statisch beschleunigten Rechenbedarf.
Auf den folgenden Seiten werden die einzelnen Bereitstellungsoptionen ausführlich behandelt.
Gemischte Strategie: Kombinieren Sie Kaufoptionen
Es ist üblich, mehrere Kapazitätskaufoptionen innerhalb eines einzigen Amazon EKS-Clusters zu kombinieren. Dieser Ansatz optimiert gleichzeitig Kosten, Verfügbarkeit und Zuverlässigkeit, indem verschiedene Workloads an die am besten geeignete Kapazitätsquelle weitergeleitet werden. Kunden implementieren diese Hybridstrategie mit einem der drei EKS-Compute-Management-Ansätze (EKS Auto Mode, Karpenter oder Node Groups) oder kombinieren sie innerhalb desselben Clusters.
EKS Auto Mode und Karpenter stellen immer zuerst reservierte Kapazität (ODCRs und Kapazitätsblöcke) bereit, gefolgt von Spot oder. On-Demand Sie können diese Priorität bei der Instanzbereitstellung mit der Planung Ihrer kritischen Workloads auf garantierter Kapazität kombinieren und gleichzeitig flexible Workloads auf Spot oder Instances planen. On-Demand Sie steuern das Workload-Routing mithilfe von Kubernetes-native Planungsprimitiven: Sie nodeSelector zielen auf einen bestimmten Kapazitätstyp ab, isolieren NVIDIA-GPU- oder AWS Trainium-Knoten und topologySpreadConstraints verteilen die Workloads auf Availability Zones, um eine hohe Verfügbarkeit zu gewährleisten.
Ein gut durchdachter Amazon EKS-Cluster organisiert beschleunigte Rechen NodePools - oder Knotengruppen in zwei Kategorien, Reserviert und Burst, die jeweils auf die Workload-Muster abgestimmt sind, die für die Kapazitätsstrategie am besten geeignet sind. Ein Beispiel wird unten beschrieben.
Reserviert (garantierte Kapazität)
Eine gpu-reserved NodePool oder eine Knotengruppe führt Produktionsinferenzen und geplante groß angelegte Schulungen auf reservierter Kapazität (ODCRs und Kapazitätsblöcke) durch, um die garantierte Verfügbarkeit von SLA-bound Diensten und geplanten rechenintensiven Aufgaben sicherzustellen. Diese NodePool oder Knotengruppe dient Inferenzendpunkten in Echtzeit, der Bereitstellung von Produktionsmodellen, geschäftskritischen Anwendungen, die eine ständige GPU-Verfügbarkeit mit vorhersehbarer Leistung erfordern, geplante verteilte Schulungen, groß angelegte Feinabstimmungsexperimente, zeitgebundene Forschungsprojekte und alle Workloads, bei denen Sie Startzeit und Dauer im Voraus kennen.
Burst (Elastische Kapazität)
Eine gpu-burst NodePool oder Knotengruppe führt Experimente, Ad-hoc-Workloads und Batch-Verarbeitung mithilfe von Spot-Instances als primärem Kapazitätstyp mit On-Demand Fallback durch. Dadurch werden die Kosteneinsparungen für fehlertolerante Workloads maximiert und gleichzeitig die Kapazität gewährleistet, wenn Spot nicht verfügbar ist. Diese NodePool oder Knotengruppe dient Batch-Offline-Inferenz, Datenvorverarbeitungspipelines, Modellevaluierungsjobs, Entwicklung und Prototyping, unvorhersehbare Skalierung von Inferenzen, kurzlebige Debugging-Sitzungen und alle Workloads, die Checkpointing implementieren und Spot-Unterbrechungen bewältigen können oder die keine Reservierung rechtfertigen, aber nicht auf reservierte Fenster warten können. Workloads auf dieser NodePool oder dieser Knotengruppe implementieren Checkpoints und ein ordnungsgemäßes Herunterfahren, um den Knotenverlust innerhalb des 2-minütigen Spot-Unterbrechungsfensters zu bewältigen.
Der gewünschte Kapazitätstyp für Workloads wird mit NodeSelector: karpenter.sh/capacity-type: spot (oder auf Abruf, reserviert) angegeben, und die gewichtsbasierte Bereitstellung stellt sicher, dass der Cluster effizient über alle Kapazitätspools hinweg skaliert werden kann. Diese Architektur bietet Teams die Flexibilität, verschiedene AI/ML Workloads — von experimentellen Notebooks bis hin zu Produktionsinferenzen — innerhalb eines einzigen EKS-Clusters auszuführen und gleichzeitig die Kosten zu optimieren.
