View a markdown version of this page

Die Aufgabenverwaltung für interaktive Spaces ist aktiviert HyperPod - Amazon SageMaker KI

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.

Die Aufgabenverwaltung für interaktive Spaces ist aktiviert HyperPod

In diesem Abschnitt wird beschrieben, wie Sie Ihre gemeinsam genutzten Amazon SageMaker HyperPod EKS-Cluster für Interactive Spaces-Workloads optimieren können. Sie lernen, die Aufgabenverwaltungsfunktionen von Kueue — einschließlich Kontingentverwaltung, Prioritätenplanung und Richtlinien zur gemeinsamen Nutzung von Ressourcen — zu konfigurieren, um sicherzustellen, dass Ihre Entwicklungsworkloads unterbrechungsfrei laufen und gleichzeitig eine faire Verteilung der Schulungs-, Evaluierungs- und Stapelverarbeitungsaktivitäten Ihrer Teams gewahrt bleibt.

So funktioniert interaktives Raummanagement

Um Interactive Spaces in gemeinsam genutzten HyperPod EKS-Clustern effektiv zu verwalten, implementieren Sie mithilfe der vorhandenen Funktionen von Kueue die folgenden Strategien zur Aufgabenverwaltung.

Konfiguration der Prioritätsklasse

Definieren Sie spezielle Prioritätsklassen für Interactive Spaces mit hoher Gewichtung (z. B. 100), um sicherzustellen, dass Entwicklungs-Pods vor anderen Aufgabentypen zugelassen und geplant werden. Diese Konfiguration ermöglicht es Interactive Spaces, Jobs mit niedrigerer Priorität beim Laden des Clusters zu verhindern, was für die Aufrechterhaltung unterbrechungsfreier Entwicklungsabläufe unerlässlich ist.

Größe und Zuteilung von Kontingenten

Reservieren Sie genügend Rechenressourcen in Ihrem Team, um die erwarteten Entwicklungslasten ClusterQueue zu bewältigen. In Zeiten, in denen Entwicklungsressourcen ungenutzt sind, können ungenutzte Quotenressourcen vorübergehend den Aufgaben anderer Teams zugewiesen werden. Wenn die Entwicklungsnachfrage steigt, können diese geliehenen Ressourcen zurückgefordert werden, um ausstehenden Interactive Space-Pods Priorität einzuräumen.

Strategien zur gemeinsamen Nutzung von Ressourcen

Wählen Sie zwischen zwei Anwesungen zur Aufteilung der Kontingente, die Ihren Anforderungen entsprechen:

Strikte Ressourcenkontrolle: Deaktiviere das Ausleihen und Ausleihen von Quoten, um sicherzustellen, dass reservierte Rechenkapazität für deine Interactive Spaces immer verfügbar ist. Bei diesem Ansatz sind Größenkontingente erforderlich, die groß genug sind, um den hohen Entwicklungsbedarf eigenständig abzudecken. In Zeiten geringer Auslastung kann dies dazu führen, dass Knoten im Leerlauf sind.

Flexible gemeinsame Nutzung von Ressourcen: Ermöglichen Sie die Ausleihe von Kontingenten, damit andere Teams ungenutzte Entwicklungsressourcen bei Bedarf nutzen können. Deaktivieren Sie jedoch die Ausleihe, um sicherzustellen, dass Interactive Spaces niemals mit geliehenen, rückzahlbaren Ressourcen betrieben werden, was zu unerwarteten Räumungen führen könnte.

Intra-Team Präventiv

Aktivieren Sie die teaminterne Präemption, wenn Sie gemischte Workloads (Schulung, Evaluierung und interaktive Bereiche) unter derselben Quote ausführen. Auf diese Weise kann Kueue Aufgaben innerhalb Ihres Teams mit niedrigerer Priorität verhindern, um Interactive Space-Pods mit hoher Priorität unterzubringen. So wird sichergestellt, dass die Entwicklungsarbeit ohne externe Quotenausleihe fortgesetzt werden kann.

Beispiel für eine Einrichtung von Interactive Space

Das folgende Beispiel zeigt, wie Kueue die Rechenressourcen für Interactive Spaces in einem gemeinsam genutzten SageMaker HyperPod Amazon-Cluster verwaltet.

Cluster-Konfiguration und Einrichtung von Richtlinien

Ihr Cluster hat die folgende Konfiguration:

  • Team Alpha (Entwicklerteam): 8 CPU-Kontingent für interaktive Bereiche

  • Team Beta (ML Team): 16 CPU-Kontingent für Training und Bewertung

  • Team Gamma (Forschung): Quote von 6 CPUs für Experimente

  • Statische Bereitstellung: Keine automatische Skalierung

  • Gesamtkapazität: 30 CPUs

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

  • Interaktive Bereiche: Priorität 100

  • Schulung: Priorität 75

  • Bewertung: Priorität 50

  • Stapelverarbeitung: Priorität 25

Kueue setzt Teamquoten und Prioritätsklassen durch, wobei die Präemption für das Entwicklerteam aktiviert und die Kreditaufnahme deaktiviert ist.

Ausgangszustand: Normale Cluster-Auslastung

Im Normalbetrieb:

  • Team Alpha: Führt 6 interaktive Spaces mit 6 CPUs aus, 2 CPUs sind inaktiv

  • Team Beta: Führt Trainingsjobs (12 CPUs) und Evaluierungsaufgaben (4 CPUs) im Rahmen seines 16-CPU-Kontingents aus

  • Team Gamma: Führt Forschungs-Workloads auf allen 6 CPUs aus

  • Gemeinsame Nutzung von Ressourcen: Team Beta leiht sich die 2 inaktiven CPUs von Team Alpha für zusätzliches Training

Entwicklungsschub: Team Alpha benötigt zusätzliche Ressourcen

Wenn die Entwickler von Team Alpha ihre Entwicklungsarbeit ausweiten müssen, benötigen zusätzliche Interactive Space-Pods 4 weitere CPUs. Kueue stellt fest, dass es sich bei den neuen Pods um:

  • Im Namespace von Team Alpha

  • Priorität 100 (Interaktive Räume)

  • Aufgrund von Quotenbeschränkungen steht die Zulassung noch aus

Der Antwortprozess von Kueue

Kueue folgt einem dreistufigen Prozess zur Zuweisung von Ressourcen:

  1. Kontingentprüfung

    Frage: Hat Team Alpha ein ungenutztes Kontingent?

    • Aktuelle Nutzung: 6 CPUs verwendet, 2 CPUs verfügbar

    • Neue Anforderung: 4 CPUs erforderlich

    • Ergebnis: Ungenügendes Kontingent → Fahren Sie mit Schritt 2 fort

  2. Self-preemption innerhalb von Team Alpha

    Frage: Können Team-Alpha-Jobs mit niedrigerer Priorität verhindert werden?

    • Verfügbare Ziele: Keine Jobs mit niedrigerer Priorität in Team Alpha

    • Ergebnis: Keine Präemption möglich → Fahren Sie mit Schritt 3 fort

  3. Geliehene Ressourcen zurückfordern

    Frage: Werden Team Alpha-Ressourcen von anderen Teams ausgeliehen?

    • Ausgeliehene Ressourcen: Team Beta verwendet 2 CPUs von Team Alpha

    • Aktion: Kueue entfernt die geliehenen Trainingseinheiten von Team Beta und gibt 2 CPUs frei

    • Verbleibender Bedarf: Benötigt noch 2 CPUs → Interactive Spaces bleiben im Status, bis Ressourcen verfügbar sind NotAdmitted

Bei diesem Ansatz werden interaktive Bereiche priorisiert und gleichzeitig die Grenzen der Teamquoten beibehalten und verhindert, dass die Entwicklungsarbeit auf instabilen, geliehenen Ressourcen läuft.