Aufgabenverwaltung für die Modellbereitstellung am HyperPod - Amazon SageMaker KI
So funktioniert das Inferenz-Workload-ManagementBeispiel für die Einrichtung eines Inferenz-Workloads

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.

Aufgabenverwaltung für die Modellbereitstellung am HyperPod

In diesem Abschnitt wird beschrieben, wie Sie Ihre gemeinsam genutzten Amazon SageMaker HyperPod EKS-Cluster für Inferenz-Workloads in Echtzeit optimieren können. Sie lernen, die Task-Governance-Funktionen von Kueue — einschließlich Quotenverwaltung, Prioritätsplanung und Richtlinien für die gemeinsame Nutzung von Ressourcen — zu konfigurieren, um sicherzustellen, dass Ihre Inferenz-Workloads die GPU-Ressourcen erhalten, die sie bei Verkehrsspitzen benötigen, und gleichzeitig eine faire Verteilung der Schulungs-, Evaluierungs- und Testaktivitäten Ihrer Teams gewährleisten. Weitere SageMaker HyperPod Verwaltung von Aufgaben allgemeine Informationen zur Aufgabenverwaltung finden Sie unter.

So funktioniert das Inferenz-Workload-Management

Um die Spitzen des Inferenzverkehrs in Echtzeit in gemeinsam genutzten HyperPod EKS-Clustern effektiv zu bewältigen, implementieren Sie die folgenden Task-Governance-Strategien unter Verwendung der vorhandenen Funktionen von Kueue.

Konfiguration der Prioritätsklasse

Definieren Sie spezielle Prioritätsklassen für Inferenz-Workloads mit hohen Gewichtungen (z. B. 100), um sicherzustellen, dass Inferenz-Pods vor anderen Tasktypen zugelassen und geplant werden. Diese Konfiguration ermöglicht es Inferenz-Workloads, Jobs mit niedrigerer Priorität während der Clusterlast zuvorzukommen, was für die Einhaltung niedriger Latenzanforderungen bei hohen Datenverkehrszahlen entscheidend ist.

Größe und Zuteilung von Kontingenten

Reservieren Sie ausreichend GPU-Ressourcen in Ihrem TeamClusterQueue, um erwartete Inferenzspitzen zu bewältigen. In Zeiten mit geringem Inferenzverkehr können ungenutzte Quotenressourcen vorübergehend den Aufgaben anderer Teams zugewiesen werden. Wenn der Bedarf an Inferenzen steigt, können diese geliehenen Ressourcen zurückgewonnen werden, um ausstehende Inferenz-Pods zu priorisieren. Weitere Informationen finden Sie unter Cluster-Warteschlange.

Strategien zur gemeinsamen Nutzung von Ressourcen

Wählen Sie je nach Ihren Anforderungen zwischen zwei Ansätzen zur Aufteilung von Kontingenten:

  1. Strikte Ressourcenkontrolle: Deaktivieren Sie das Ausleihen und Ausleihen von Kontingenten, um sicherzustellen, dass reservierte GPU-Kapazität immer für Ihre Workloads verfügbar ist. Bei diesem Ansatz müssen die Kontingente so dimensioniert werden, dass sie Spitzenlasten unabhängig voneinander bewältigen können. Dies kann dazu führen, dass Knoten in Zeiten mit geringem Datenverkehr inaktiv sind.

  2. Flexible gemeinsame Nutzung von Ressourcen: Ermöglichen Sie die Ausleihe von Kontingenten, um bei Bedarf ungenutzte Ressourcen anderer Teams zu nutzen. Ausgeliehene Kapseln sind als vorrätig gekennzeichnet und können geräumt werden, wenn das Ausleihteam Kapazitäten zurückfordert.

Teaminterne Präemption

Aktivieren Sie die teaminterne Präemption, wenn gemischte Workloads (Evaluierung, Schulung und Inferenz) unter demselben Kontingent ausgeführt werden. Auf diese Weise kann Kueue Aufgaben mit niedrigerer Priorität innerhalb Ihres Teams vorwegnehmen, um Inferenz-Pods mit hoher Priorität zu unterstützen. Dadurch wird sichergestellt, dass Inferenz in Echtzeit ausgeführt werden kann, ohne auf externe Quotenausleihe angewiesen zu sein. Weitere Informationen finden Sie unter Präemption.

Beispiel für die Einrichtung eines Inferenz-Workloads

Das folgende Beispiel zeigt, wie Kueue GPU-Ressourcen in einem gemeinsam genutzten SageMaker HyperPod Amazon-Cluster verwaltet.

Cluster-Konfiguration und Richtlinien-Setup

Ihr Cluster hat die folgende Konfiguration:

  • Team A: 10-P4-GPU-Kontingent

  • Team B: 20-P4-GPU-Kontingent

  • Statische Bereitstellung: Keine automatische Skalierung

  • Gesamtkapazität: 30 P4 GPUs

Der gemeinsam genutzte GPU-Pool verwendet diese Prioritätsrichtlinie:

  1. Inferenz in Echtzeit: Priorität 100

  2. Schulung: Priorität 75

  3. Bewertung: Priorität 50

In der Warteschlange werden Teamkontingente und Prioritätsklassen durchgesetzt, wobei Präemption und Quotenausleihe aktiviert sind.

Ausgangszustand: Normale Clusterauslastung

Im normalen Betrieb:

  • Team A führt Schulungs- und Bewertungsjobs auf allen 10 P4 durch GPUs

  • Team B führt Inferenz (10 P4s) und Evaluierungen (10 P4s) in Echtzeit im Rahmen seiner 20-GPU-Quote durch

  • Der Cluster ist voll ausgelastet, da alle Jobs zugelassen sind und ausgeführt werden

Inferenzanstieg: Team B benötigt zusätzliche GPUs

Wenn Team B einen Anstieg des Datenverkehrs verzeichnet, benötigen zusätzliche Inferenz-Pods 5 weitere P4. GPUs Kueue erkennt, dass es sich bei den neuen Pods um:

  • Im Namespace von Team B

  • Priorität 100 (Inferenz in Echtzeit)

  • Aufgrund von Quotenbeschränkungen steht die Zulassung noch aus

Bei der Reaktion von Kueue wird zwischen zwei Optionen gewählt:

Option 1: Quotenausleihe — Wenn Team A nur 6 seiner 10 P4 verwendet, kann Kueue die Pods von Team B zulassen, die die 4 P4 im Leerlauf verwenden. Diese geliehenen Ressourcen sind jedoch präventiv — wenn Team A Aufträge einreicht, um sein volles Kontingent zu erreichen, entfernt Kueue die geliehenen Inferenzkapseln von Team B.

Option 2: Selbstprävention (empfohlen) — Team B führt Bewertungsaufträge mit niedriger Priorität aus (Priorität 50). Wenn Inferenz-Pods mit hoher Priorität warten, nimmt Kueue die Evaluierungsjobs innerhalb des Kontingents von Team B vor und lässt die Inferenz-Pods zu. Dieser Ansatz ermöglicht eine sichere Ressourcenzuweisung ohne das Risiko einer externen Räumung.

Bei der Zuweisung von Ressourcen folgt Kueue einem dreistufigen Prozess:

  1. Kontingentprüfung

    Frage: Hat Team B ein ungenutztes Kontingent?

    • Ja → Gib die Pods zu

    • Nein → Fahren Sie mit Schritt 2 fort

  2. Selbstprävention innerhalb von Team B

    Frage: Können Team-B-Jobs mit niedrigerer Priorität ausgeschlossen werden?

    • Ja → Evaluierungsjobs (Priorität 50) zuvorkommen, 5 P4 freigeben und Inferenz-Pods zulassen

    • Nein → Weiter mit Schritt 3

    Dieser Ansatz hält die Arbeitslast innerhalb der garantierten Quote von Team B und vermeidet so das Risiko einer externen Unternehmensräumung.

  3. Kredite von anderen Teams aufnehmen

    Frage: Gibt es ungenutzte, ausleihbare Quoten von anderen Teams?

    • Ja → Gib zu, ein geliehenes Kontingent genutzt zu haben (als präemptiv gekennzeichnet)

    • Nein → Der Pod bleibt im Status NotAdmitted