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.
Rechenleistung für AI/ML Workloads mit EKS Auto Mode und Karpenter verwalten
Tipp
Melden Sie sich
In diesem Abschnitt wird beschrieben, wie Sie beschleunigte Rechenleistung (AWS Trainium, NVIDIA-GPUs) für KI-Trainings- und Inferenz-Workloads mithilfe von Amazon EKS Auto Mode oder selbstverwaltetem Karpenter verwalten.
EKS Auto Mode und Karpenter unterstützen zwei Bereitstellungsmodi: dynamische Bereitstellung und statische Bereitstellung. Bei der dynamischen Bereitstellung stellen EKS Auto Mode und Karpenter beschleunigte Recheninstanzen bereit und skalieren sie, je nachdem, welche Workloads auf dem Cluster geplant sind. Bei der statischen Bereitstellung stellen EKS Auto Mode und Karpenter eine feste Anzahl von Knoten bereit und verwalten sie. Dynamisches und statisches Provisioning können im selben Cluster verwendet werden, um einen konstanten Basiskapazitätspool aufrechtzuerhalten und gleichzeitig mit den Workload-Anforderungen zu skalieren.
EKS Auto Mode und Karpenter unterstützen alle vier Kapazitätskaufoptionen (SpotOn-Demand, Capacity Blocks und ODCRs) und stellen immer zuerst reservierte Kapazität bereit, gefolgt von Spot oder. On-Demand
EKS Auto Mode gegen Karpenter
Beide Ansätze nutzen dieselbe NodePool API, unterscheiden sich jedoch in Bezug auf die betriebliche Eigentümerschaft, die Ressourcen-APIs, die Betriebssystemunterstützung, die Behandlung von Spot-Unterbrechungen und die Flexibilität bei der Konfiguration.
| Feature | EKS Auto Mode | Self-managed Karpenter |
|---|---|---|
|
Am besten geeignet für |
Teams, die eine verwaltete Infrastruktur mit minimalem Betriebsaufwand bevorzugen |
Teams, die die volle Kontrolle über den Knotenlebenszyklus, AMIs, Betriebssystem-Tuning und Patching bevorzugen. |
|
Betriebsmodell |
AWS stellt den Karpenter-Controller, die GPU/Trainium Treiber, Geräte-Plugins, das Betriebssystem-Patching und die Behandlung von Spot-Unterbrechungen bereit und verwaltet sie. |
Sie installieren und betreiben den Karpenter-Controller in Ihrem Cluster und besitzen GPU/Trainium Treiber, Geräte-Plugins, den AMI-Lebenszyklus, das Patchen und die Behandlung von Spot-Unterbrechungen. |
|
Rechenoptionen |
On-Demand, Spot, ODCRs, Kapazitätsblöcke für ML |
On-Demand, Spot, ODCRs, Kapazitätsblöcke für ML |
|
Ressourcen-APIs |
|
|
|
Betriebssystem des Knotens |
Nur Bottlerocket. NVIDIA-GPU-, AWS Trainium- und EFA-Abhängigkeiten enthalten. |
AL2023, Bottlerocket, Windows oder Ihr eigenes AMI. |
|
Lebensdauer des Knotens |
Maximale Knotenlebensdauer von 21 Tagen für Sicherheitspatches. Workloads müssen eine Rotation der Knoten tolerieren. |
Sie definieren den Knotenlebenszyklus NodePool |
|
Behandlung von Unterbrechungen direkt vor Ort |
Einheimisch. Keine SQS-Warteschlange oder kein Node Termination Handler erforderlich. |
Sie sind für die Konfiguration und Aktivierung verantwortlich. |
|
Schnelles Ziehen von Containern |
SOCI-Parallel-Pull ist in allen Instances der G-, P- und Trn-Familie enthalten |
Sie sind für die Konfiguration und Aktivierung verantwortlich. |
|
EC2-Platzierungsgruppen |
Cluster, Partition, Verteilung |
Clustern, partitionieren, verteilen |
|
Konfiguration der Netzwerkschnittstelle |
Nicht unterstützt |
Pro Schnittstellenkonfiguration für Typ |
|
Reparatur von Knoten |
Standardmäßig aktiviert, der EKS-Node-Monitoring-Agent ist enthalten |
Optional aktiviert, der EKS-Node-Monitoring-Agent wird selbst verwaltet |
|
Preisgestaltung |
Die Verwaltungsgebühr für den automatischen Modus von EKS wird |
Open-Source-Software. Sie zahlen für die zugrunde liegenden EC2-Instances. |
Gängige AI/ML bekannte Labels
EKS Auto Mode und Karpenter stellen Instanzbezeichnungen zur Verfügung, die Sie in NodePool requirements und Pod nodeSelector oder für Ziel-Workloads verwenden können, ohne Instanztypen fest nodeAffinity zu codieren. Das Label-Präfix unterscheidet sich zwischen den beiden: EKS Auto Mode verwendet, eks.amazonaws.com/ während Karpenter selbst verwaltet verwendet. karpenter.k8s.aws/
Die folgenden Tabellen zeigen relevante Labels, die in verwendet werden können. NodePools EKS Auto Mode und Karpenter wenden im Rahmen des Bereitstellungsprozesses auch die in der Karpenter-Dokumentation
Planung von Labels für reservierte Kapazität
Wenn EKS Auto Mode oder Karpenter einen Knoten in einer Reservierung starten, werden die folgenden Beschriftungen hinzugefügt. Verwenden Sie sie innodeSelector, in der Knotenaffinität oder in NodePool Anforderungen, um Workloads weiterzuleiten.
-
karpenter.sh/capacity-type:reserved, oderon-demand.spotGibt die Kapazität an, die dem Knoten zugrunde liegt. -
karpenter.k8s.aws/capacity-reservation-id: Die spezifische Reservierungs-ID, mit der der Knoten gestartet wurde. -
karpenter.k8s.aws/capacity-reservation-type:defaultfür ODCRs,capacity-blockfür Capacity Blocks.
Die folgenden Beispiele zeigen gängige Planungsmuster:
Verbinde einen Pod mit einer bestimmten Reservierung (kein Fallback):
spec: nodeSelector: karpenter.sh/capacity-type: reserved karpenter.k8s.aws/capacity-reservation-id: "cr-0123456789abcdef0"
Nur ODCR-Zielknoten (alle ODCR-Knoten, keine Kapazitätsblöcke):
spec: nodeSelector: karpenter.sh/capacity-type: reserved karpenter.k8s.aws/capacity-reservation-type: default
Auf jede reservierte Kapazität (ODCR oder Kapazitätsblock) abzielen:
spec: nodeSelector: karpenter.sh/capacity-type: reserved
Bevorzugen Sie reserviert, greifen Sie aber auf Spot zurück oder On-Demand falls nicht verfügbar:
spec: affinity: nodeAffinity: preferredDuringSchedulingIgnoredDuringExecution: - weight: 100 preference: matchExpressions: - key: karpenter.sh/capacity-type operator: In values: ["reserved"]
Verhalten beim Ablauf der Reservierung
ODCRs und Capacity Blocks verhalten sich unterschiedlich, wenn die Reservierung endet. Vergewissern Sie sich, dass Ihre Terminplanung und Checkpoint-Strategie der Art der Reservierung entspricht, die Ihren Arbeitsaufwand unterstützt.
Dokumente
Eine in einem ODCR gestartete Instanz befindet sich nicht auf unbestimmte Zeit in diesem ODCR. Das ODCR kann ablaufen, gekündigt werden oder die Instanz kann manuell aus dem ODCR entfernt werden. Wenn einer dieser Fälle eintritt und EKS Auto Mode//Karpenter feststellt, dass die Instanz nicht mehr zu einem ODCR gehört, aktualisiert es die Bezeichnung des Knotens von bis. karpenter.sh/capacity-type reserved on-demand Die Instanz wird weiterhin mit On-Demand Standardkapazität ausgeführt, und bestehende Pods laufen ohne Unterbrechung weiter.
Anmerkung
Jeder Pod, der mit einem Strict-Wert geplant ist, nodeSelector: karpenter.sh/capacity-type: reserved wird nicht auf den Knoten eingeplant, wenn er neu beschriftet wurde. Damit Workloads einen Ablauf oder eine Kündigung von ODCR überstehen, verwenden Sie das oben gezeigte preferredDuringSchedulingIgnoredDuringExecution Muster anstelle von a. nodeSelector
Kapazitätsblöcke
Im Gegensatz zu ODCRs haben Capacity-Blöcke immer eine Endzeit, und EC2 beendet Capacity Block-Instances 30 Minuten vor der Endzeit (60 Minuten für UltraServer Instance-Typen). Planen Sie Schulungs- und Inferenzaufgaben so, dass sie abgeschlossen sind, oder speichern Sie den Status, bevor das Reservierungsfenster geschlossen wird. Pods, die capacity-reservation-id nach Pending Ablauf der Sperre einen Strict nodeSelector für eine bestimmte Ausführung verwenden und nicht an anderer Stelle verschoben werden können. Kombinieren Sie Checkpointing mit dem oben genannten flexiblen Affinitätsmuster, wenn Sie Workloads während des Ablaufs des Capacity-Blocks auf eine andere Kapazität verschieben müssen.
-
Sie können Reserved Instances für die meisten Instance-Typen bis 30 Minuten vor der Endzeit des Kapazitätsblocks oder bis 60 Minuten vor der Endzeit für UltraServer Instance-Typen verwenden.
-
EKS Auto Mode und Karpenter beginnen 10 Minuten vor der Terminierung von EC2 präventiv mit der Entleerung von Knoten in einem Kapazitätsblock, sodass Workloads Zeit haben, Checkpoints durchzuführen und ordnungsgemäß herunterzufahren.
Statische Kapazität NodePools
EKS Auto Mode und Karpenter unterstützen statische Kapazität NodePools, wodurch unabhängig vom Workload-Bedarf eine feste Anzahl von Knoten aufrechterhalten wird. Statische Pools verhindern Kaltstartverzögerungen für latenzempfindliche Inferenzen und ermöglichen es Ihnen, einen minimalen Infrastrukturbedarf für Ihren Cluster zu reservieren.
Die statische Kapazität wird konfiguriert, indem Sie das Feld auf dem festlegen. replicas NodePool
Überlegungen
-
Sobald
replicases auf a gesetzt ist NodePool, können Sie es nicht mehr entfernen. Eine einzelne Person NodePool kann nicht zwischen statischer und dynamischer Kapazitätsbereitstellung wechseln. -
Statische Kapazitäten NodePools werden bei der Konsolidierung nicht berücksichtigt. Wird
limits.nodesoben festgelegtreplicas, um eine temporäre Skalierung während der AMI-Drift oder -Ablaufzeit zu ermöglichen. -
Für eine vorhersehbare Verteilung der Availability Zone (AZ) sollten Sie eine statische Kapazität NodePool pro AZ einrichten, anstatt sich über mehrere Zonen in einem einzigen Pool zu erstrecken.
Kapazitätsblöcke für ML
Capacity Blocks for ML ermöglichen es Ihnen, Instances für ein definiertes future Fenster zu reservieren P-family und zu trainieren. Sie sind im Voraus bezahlt, weshalb EKS Auto Mode und Karpenter sie als kostenlos abbilden und ihnen Vorrang vor Spot einräumen. On-Demand Kapazitätsblöcke für ML können eine Reservierungsdauer von 1—14 Tagen oder einem Vielfachen von 7 Tagen bis zu 182 Tagen (6 Monaten) haben.
Um Capacity Blocks for ML mit EKS Auto Mode oder Karpenter zu verwenden, konfigurieren Sie es capacityReservationSelectorTerms mit Ihrer Kapazitätsreservierungs-ID in Ihrem. NodeClass Sie können den offenen Reservierungsabgleich nicht mit Capacity Blocks for ML verwenden. Ein Begriff kann eine ID, eine Reihe von Tags oder Kriterien für die Instanzübereinstimmung angeben, anhand derer ausgewählt werden soll. Bei der Angabe von Stichwörtern werden alle Kapazitätsreservierungen ausgewählt, auf die über das Konto zugegriffen werden kann, mit passenden Stichwörtern. Dies kann durch Angabe einer Eigentümerkonto-ID weiter eingeschränkt werden.
Weitere Beispiele finden Sie in der Karpenter-Dokumentation
On-Demand Kapazitätsreservierungen (ODCRs)
ODCRs garantieren Kapazität in einer bestimmten Availability Zone (AZ) ohne langfristige Verpflichtung. Ihnen werden On-Demand Standardtarife in Rechnung gestellt, unabhängig davon, ob die Kapazität genutzt wird oder nicht. ODCRs unterstützen alle NVIDIA-GPU-Familien, einschließlich G-family Instanzen, die von Capacity Blocks for ML nicht unterstützt werden. ODCRs sind im Voraus bezahlt, sodass sie von EKS Auto Mode und Karpenter als kostenlos angeboten werden und ihnen Vorrang vor Spot eingeräumt werden. On-Demand
ODCRs verhalten sich am Ende der Reservierung anders als Capacity Blocks für ML. Wenn ein ODCR abläuft oder storniert wird, läuft die Instanz standardmäßig weiter. On-Demand Details dazu finden Sie unter Verhalten beim Ablauf der Reservierung.
Um ODCRs mit EKS Auto Mode oder Karpenter zu verwenden, konfigurieren Sie es capacityReservationSelectorTerms mit Ihren Kapazitätsreservierungsbedingungen in Ihrem. NodeClass Ein Begriff kann eine ID, eine Reihe von Tags oder Instance-Übereinstimmungskriterien angeben, anhand derer ausgewählt werden soll. Bei der Angabe von Stichwörtern werden alle Kapazitätsreservierungen ausgewählt, auf die über das Konto zugegriffen werden kann, mit passenden Stichwörtern. Bei der Angabe von Kriterien für die Zuordnung von Instanzen werden Reservierungen anhand ihres Abgleichverhaltens ausgewählt: offen (entspricht allen kompatiblen Instances) oder zielgerichtet (entspricht nur explizit ausgewählten Instances). Dies kann durch Angabe einer Besitzerkonto-ID weiter eingeschränkt werden.
Weitere Beispiele finden Sie in der Karpenter-Dokumentation
On-Demand
On-Demand ist der Standardkapazitätstyp und kann mit statischer oder dynamischer Bereitstellung in EKS Auto Mode und Karpenter verwendet werden. Sie können On-Demand Instanzen explizit anfordern, indem Sie Ihre einrichtenkarpenter.sh/capacity-type: on-demand. NodePool EKS Auto Mode und Karpenter wählen die Instanz mit dem niedrigsten Preis aus, die die Ressourcenanforderungen des Pods erfüllt. Wird On-Demand für Entwicklung, Prototyping, unvorhersehbare Skalierung von Inferenzen und für alle Workloads verwendet, die sofortige Verfügbarkeit ohne Unterbrechungsrisiko erfordern.
Spot-Instances
Spot bietet Einsparungen von bis zu 90% gegenüber der Verwendung On-Demand von EC2-Reservekapazitäten. AWS kann Spot-Instances mit einer Unterbrechungsbenachrichtigung von 2 Minuten zurückfordern. Maximieren Sie die Verfügbarkeit, indem Sie mehrere Instance-Familien auf dem NodePool auflisten. Kombinieren Sie Spot-Workloads in regelmäßigen Abständen mit einem PodDisruptionBudget und einem Checkpoint zu einem dauerhaften Speicher (Amazon S3 oder Amazon EFS), sodass Pods den Status speichern können, während das Fenster leer ist.
Spot-Workloads eignen sich hervorragend für fehlertolerante, wiederaufnehmbare Trainings- und Inferenz-Workloads, bei denen gelegentliche Unterbrechungen als Gegenleistung für erhebliche Kosteneinsparungen akzeptabel sind.
Zu den gängigen Kandidaten gehören:
-
Hyperparameter-Tuning und Sweeps: viele kurze, parallel Versuche, die wiederholt werden können, wenn sie unterbrochen werden.
-
Verteiltes Training mit Checkpointing: lang andauernde Jobs, die den Status regelmäßig in S3 oder FSx speichern und nach einem Knotenverlust ab dem letzten Checkpoint wieder aufgenommen werden können.
-
Batch- und Offline-Inferenz: groß angelegte Scoring-Jobs anhand von Datensätzen, bei denen die End-to-End-Latenz in Stunden statt in Sekunden gemessen wird.
-
Datenvorverarbeitungs- und Feature-Engineering-Pipelines: parallel Transformationen über große Datensätze.
-
Modellevaluierung und Benchmarking: wiederholbare Aufgaben, die zu idempotenten Ergebnissen führen.
-
Entwicklung, Prototyping und Notebooks: interaktives Experimentieren, bei dem Benutzer gelegentliche Neustarts tolerieren können.
Vermeiden Sie Spot für latenzempfindliche Echtzeit-Inferenzen, SLA-bound Produktionsendpunkte und Workloads, die keine Checkpoints ausführen oder Neustarts nicht tolerieren können.
Sie können Spot-Instances explizit anfordern, indem Sie Ihre einrichten. karpenter.sh/capacity-type: spot NodePool