Aufgabenverwaltung für interaktive Bereiche 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.

Aufgabenverwaltung für interaktive Bereiche 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 Quotenverwaltung, Prioritätsplanung und Richtlinien für die gemeinsame Nutzung von Ressourcen — so zu konfigurieren, dass Ihre Entwicklungs-Workloads ohne Unterbrechung laufen und gleichzeitig eine faire Verteilung der Schulungs-, Evaluierungs- und Batch-Verarbeitungsaktivitäten Ihrer Teams gewährleistet wird.

So funktioniert Interactive Space Management

Um interaktive Bereiche in gemeinsam genutzten HyperPod EKS-Clustern effektiv zu verwalten, implementieren Sie die folgenden Strategien zur Aufgabenverwaltung unter Verwendung der vorhandenen Funktionen von Kueue.

Konfiguration der Prioritätsklasse

Definieren Sie spezielle Prioritätsklassen für interaktive Bereiche 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 entscheidend ist.

Größe und Zuteilung von Kontingenten

Reservieren Sie ausreichend Rechenressourcen in Ihrem Team, um die erwarteten Entwicklungsworkloads ClusterQueue zu bewältigen. In Zeiten, in denen Entwicklungsressourcen ungenutzt sind, können ungenutzte Quotenressourcen vorübergehend den Aufgaben anderer Teams zugewiesen werden. Wenn der Entwicklungsbedarf steigt, können diese geliehenen Ressourcen zurückgewonnen werden, um ausstehende Interactive Space-Pods zu priorisieren.

Strategien zur gemeinsamen Nutzung von Ressourcen

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

Strikte Ressourcenkontrolle: Deaktivieren Sie das Ausleihen und Ausleihen von Kontingenten, um sicherzustellen, dass reservierte Rechenkapazität für Ihre Interactive Spaces immer verfügbar ist. Dieser Ansatz erfordert, dass die Kontingente groß genug sind, um Spitzenlasten bei der Entwicklung selbstständig bewältigen zu können. Dies kann dazu führen, dass Knoten in Zeiten geringer Auslastung inaktiv sind.

Flexible gemeinsame Nutzung von Ressourcen: Aktivieren Sie die Quotenausleihe, damit andere Teams bei Bedarf ungenutzte Entwicklungsressourcen nutzen können. Deaktivieren Sie jedoch die Ausleihe, um sicherzustellen, dass Interactive Spaces niemals mit geliehenen, zurückforderbaren Ressourcen ausgeführt wird, was zu unerwarteten Räumungen führen könnte.

Teaminterne Präemption

Aktivieren Sie die teaminterne Sperrung, wenn gemischte Workloads (Schulung, Evaluierung und interaktive Bereiche) unter demselben Kontingent ausgeführt werden. Auf diese Weise kann Kueue Aufgaben mit niedrigerer Priorität innerhalb Ihres Teams vorwegnehmen, um Interactive Space-Pods mit hoher Priorität unterzubringen. So wird sichergestellt, dass die Entwicklungsarbeit fortgesetzt werden kann, ohne auf externe Quoten angewiesen zu sein.

Beispiel für eine Einrichtung von Interactive Space

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

Cluster-Konfiguration und Richtlinieneinrichtung

Ihr Cluster hat die folgende Konfiguration:

  • Team Alpha (Entwicklungsteam): Quote von 8 CPUs für Interactive Spaces

  • Team Beta (ML-Team): Kontingent von 16 CPUs für Training und Evaluierung

  • 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 Teamkontingente und Prioritätsklassen durch, wobei Preemption aktiviert und Borlowing für das Entwicklerteam deaktiviert ist.

Ausgangszustand: Normale Clusterauslastung

Im Normalbetrieb:

  • Team Alpha: Führt 6 interaktive Bereiche mit 6 aus CPUs, davon 2 CPUs im Leerlauf

  • Team Beta: Führt Trainingsjobs (12 CPUs) und Evaluierungsaufgaben (4 CPUs) innerhalb des Kontingents von 16 CPUs aus

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

  • Gemeinsame Nutzung von Ressourcen: Team Beta leiht sich die 2 Idle von Team Alpha CPUs für zusätzliche Schulungen

Entwicklungsschub: Team Alpha benötigt zusätzliche Ressourcen

Wenn die Entwickler von Team Alpha die 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 Bereiche)

  • 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 gebraucht, 2 CPUs verfügbar

    • Neue Anforderung: 4 CPUs erforderlich

    • Ergebnis: Ungenügendes Kontingent → Weiter mit Schritt 2

  2. Selbstprävention innerhalb von Team Alpha

    Frage: Können Team Alpha-Jobs mit niedrigerer Priorität ausgeschlossen 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: Die Warteschlange entfernt die von Team Beta geliehenen Trainingskapseln und gibt 2 davon frei CPUs

    • Verbleibender Bedarf: Benötige noch 2 weitere CPUs → Interaktive Bereiche bleiben im NotAdmitted Status, bis Ressourcen verfügbar sind

Bei diesem Ansatz werden interaktive Bereiche priorisiert, wobei gleichzeitig die Quotengrenzen für Teams beibehalten werden und verhindert wird, dass Entwicklungsarbeiten mit instabilen, geliehenen Ressourcen ausgeführt werden.