GPU- und TPU-Bereitstellung mit dem Bereitstellungsmodus „Flex-Start“

Auf dieser Seite wird der Bereitstellungsmodus „Flexibler Start“ in der Google Kubernetes Engine (GKE) beschrieben. Flex-Start, basierend auf dem Dynamic Workload Scheduler, ist eine flexible und kostengünstige Methode, um GPUs und TPUs zu erhalten, wenn Sie KI-/ML-Arbeitslasten ausführen müssen.

Mit der flexiblen Startzeit können Sie GPUs und TPUs nach Bedarf für bis zu sieben Tage dynamisch bereitstellen, ohne an eine bestimmte Startzeit gebunden zu sein und ohne langfristige Reservierungen verwalten zu müssen. Daher eignet sich die flexible Startzeit für kleinere bis mittelgroße Arbeitslasten mit schwankenden Nachfrageanforderungen oder kurzer Dauer. Beispiele: Vortraining kleiner Modelle, Modellabstimmung oder skalierbare Bereitstellungsmodelle.

Die Informationen auf dieser Seite können Ihnen bei folgenden Aufgaben helfen:

• Funktionsweise von „flex-start“ in GKE
• Entscheiden Sie, ob „flex-start“ für Ihre Arbeitslast geeignet ist.
• Entscheiden Sie, welche Flex-Start-Konfiguration für Ihre Arbeitslast geeignet ist.
• Unterbrechungen bei Verwendung von „flex-start“ verwalten
• Einschränkungen von „flex-start“ in GKE

Diese Seite richtet sich an Plattformadministratoren und ‑betreiber und Entwickler von maschinellem Lernen (ML), die die Beschleunigerinfrastruktur für ihre Arbeitslasten optimieren möchten.

Wann sollte „flex-start“ verwendet werden?

Wir empfehlen die Verwendung von „flex-start“, wenn Ihre Arbeitslasten die folgenden Bedingungen erfüllen:

• Ihre Arbeitslasten erfordern GPU-Ressourcen.
• Ihre Arbeitslasten erfordern TPU-Ressourcen, die in TPU-Slice-Knotenpools mit einem Host ausgeführt werden.
• Sie haben eine begrenzte oder keine reservierte GPU- oder TPU-Kapazität und benötigen einen zuverlässigeren Zugriff auf diese Beschleuniger.
• Ihre Arbeitslast ist zeitflexibel und Ihr Anwendungsfall kann es sich leisten, die gesamte angeforderte Kapazität zu erhalten, z. B. wenn GKE die GPU-Ressourcen außerhalb der stärksten Stunden zuweist.

Voraussetzungen

Damit Sie „flex-start“ in GKE verwenden können, muss Ihr Cluster die folgenden Anforderungen erfüllen:

• Verwenden Sie die GKE-Version 1.32.2-gke.1652000 oder höher, um GPUs auszuführen.

• Verwenden Sie die GKE-Version 1.33.0-gke.1712000 oder höher, um TPUs auszuführen. Flex-Start unterstützt die folgenden Versionen und Zonen:

  • TPU Trillium (v6e) in asia-northeast1-b und us-east5-a
  • TPU v5e in us-west4-a
  • TPU v5p in us-east5-a

  TPU v3 und v4 werden nicht unterstützt.

So funktioniert das Bereitstellungsmodell „Flex-Start“

Mit „flex-start“ geben Sie die erforderliche GPU- oder TPU-Kapazität in Ihren Arbeitslasten an. Bei Standardclustern konfigurieren Sie außerdem die Flex-Start-Funktion für bestimmte Knotenpools. GKE stellt VMs automatisch bereit, indem der folgende Vorgang ausgeführt wird, sobald Kapazität verfügbar ist:

1. Die Arbeitslast fordert Kapazität an, die nicht sofort verfügbar ist. Diese Anfrage kann direkt über die Arbeitslastspezifikation oder über Planungstools wie benutzerdefinierte Compute-Klassen oder Kueue erfolgen.
2. GKE erkennt, dass für Ihren Knoten die flexible Startzeit aktiviert ist und dass die Arbeitslast für einen unbestimmten Zeitraum warten kann.
3. Das Cluster-Autoscaling akzeptiert Ihre Anfrage und berechnet die Anzahl der erforderlichen Knoten als solche, die als eine Einheit behandelt werden.
4. Cluster Autoscaler stellt die erforderlichen Knoten bereit, wenn sie verfügbar sind. Diese Knoten werden maximal sieben Tage lang ausgeführt. Wenn Sie einen Wert für den Parameter maxRunDurationSeconds angeben, ist die Ausführungsdauer kürzer. Dieser Parameter ist in der GKE-Version 1.28.5-gke.1355000 oder höher verfügbar. Wenn Sie keinen Wert für den Parameter maxRunDurationSeconds angeben, wird standardmäßig sieben Tage verwendet.
5. Nach Ablauf der im Parameter maxRunDurationSeconds angegebenen Laufzeit werden die Knoten und Pods vorzeitig beendet.
6. Wenn die Pods früher beendet sind und die Knoten nicht mehr verwendet werden, entfernt Cluster Autoscaler sie gemäß dem Autoscaling-Profil.

GKE zählt die Dauer für jede Flex-Start-Anfrage auf Knotenebene. Die Ausführungszeit von Pods ist aufgrund von Verzögerungen beim Start möglicherweise etwas kürzer. Pod-Wiederholungsversuche zählen zu dieser Dauer, was bedeutet, dass nach der Wiederholung weniger Zeit für die Pods verfügbar ist. GKE zählt die Dauer für jede Flex-Start-Anfrage separat.

Flex-Start-Konfigurationen

GKE unterstützt die folgenden Flex-Start-Konfigurationen:

• Flex-Start, bei dem GKE Ressourcen Knoten für Knoten zuweist. Bei dieser Konfiguration müssen Sie das Flag --flex-start nur bei der Knotenerstellung festlegen.

• Flex-Start mit Bereitstellung per Warteschlange, bei der GKE alle angeforderten Ressourcen gleichzeitig zuweist. Wenn Sie diese Konfiguration verwenden möchten, müssen Sie beim Erstellen des Knotenpools die Flags --flex-start und enable-queued-provisioning hinzufügen. In GKE wird der Prozess in diesem Dokument unter So funktioniert der Bereitstellungsmodus mit flexiblem Start beschrieben. Außerdem gelten die folgenden Bedingungen:

  • Der Scheduler wartet, bis alle angeforderten Ressourcen in einer einzigen Zone verfügbar sind.
  • Alle Pods der Arbeitslast können gemeinsam auf neu bereitgestellten Knoten ausgeführt werden.
  • Die bereitgestellten Knoten werden zwischen den Ausführungen des Arbeitsloads nicht wiederverwendet.

In der folgenden Tabelle werden die Flex-Start-Konfigurationen verglichen:

Flex-Start-Konfiguration optimieren

Wenn Sie eine robuste und kostenoptimierte KI-/ML-Infrastruktur erstellen möchten, können Sie Konfigurationen mit flexiblem Start mit verfügbaren GKE-Funktionen kombinieren. Wir empfehlen die Verwendung von Rechenklassen, um eine priorisierte Liste von Knotenkonfigurationen basierend auf Ihren Arbeitslastanforderungen zu definieren. GKE wählt die am besten geeignete Konfiguration basierend auf Verfügbarkeit und Ihrer definierten Priorität aus.

Unterbrechungen bei Arbeitslasten mit Dynamic Workload Scheduler verwalten

Arbeitslasten, für die alle oder die meisten Knoten in einem Knotenpool verfügbar sein müssen, sind anfällig für Auslagerungen. Außerdem wird die automatische Reparatur nicht für Knoten unterstützt, die über Dynamic Workload Scheduler-Anfragen bereitgestellt werden. Bei der automatischen Reparatur werden alle Arbeitslasten von einem Knoten entfernt, sodass sie nicht mehr ausgeführt werden können.

Alle Knoten, die Flex-Start, die Bereitstellung in der Warteschlange oder beides verwenden, nutzen kurzlebige Upgrades, wenn auf der Clustersteuerungsebene die Mindestversion für Flex-Start, 1.32.2-gke.1652000 oder höher, ausgeführt wird.

Bei kurzlebigen Upgrades wird ein Standardknotenpool oder eine Gruppe von Knoten in einem Autopilot-Cluster aktualisiert, ohne die laufenden Knoten zu stören. Es werden neue Knoten mit der neuen Konfiguration erstellt, die nach und nach die vorhandenen Knoten mit der alten Konfiguration ersetzen. Für frühere GKE-Versionen, die keine flexiblen oder kurzlebigen Upgrades unterstützen, gelten andere Best Practices.

Best Practices zur Minimierung von Arbeitslastunterbrechungen für Knoten mit kurzlebigen Upgrades

Flex-Start-Knoten und Knoten, für die die Bereitstellung in der Warteschlange verwendet wird, werden automatisch für kurzlebige Upgrades konfiguriert, wenn im Cluster Version 1.32.2-gke.1652000 oder höher ausgeführt wird.

Führen Sie die folgenden Aufgaben aus, um Unterbrechungen bei Arbeitslasten zu minimieren, die auf Knoten ausgeführt werden, auf denen kurzlebige Upgrades verwendet werden:

• Konfigurieren Sie Wartungsfenster und ‑ausschlüsse, um festzulegen, wann GKE Aktualisierungsvorgänge wie Knotenupgrades ausführen soll und wann nicht. Achten Sie dabei darauf, dass GKE noch Zeit für die automatische Wartung hat.
• Automatische Knotenreparatur deaktivieren

Für Knoten in Clustern mit Versionen älter als 1.32.2-gke.1652000, bei denen also keine kurzlebigen Upgrades verwendet werden, lesen Sie die spezifischen Anleitungen für diese Knoten.

Best Practices zur Minimierung von Arbeitslastunterbrechungen für in der Warteschlange befindliche Bereitstellungsknoten ohne kurzlebige Upgrades

Für Knoten mit gepufferter Bereitstellung in einem Cluster, in dem eine GKE-Version vor 1.32.2-gke.1652000 ausgeführt wird, werden keine kurzlebigen Upgrades verwendet. Cluster, die auf Version 1.32.2-gke.1652000 oder höher umgestellt wurden und für die bereits bereitgestellte Knoten in der Warteschlange vorhanden sind, werden automatisch auf die Verwendung von kurzlebigen Upgrades umgestellt.

Für Knoten, auf denen diese älteren Versionen ausgeführt werden, finden Sie hier weitere Informationen:

• Je nach Registrierung des Clusters für einen Release-Kanal können Sie mit den folgenden Best Practices verhindern, dass automatische Knotenupgrades Ihre Arbeitslasten beeinträchtigen:
  • Wenn Ihr Cluster für eine Release-Version registriert ist, können Sie mit Wartungsfenstern und ‑ausschlüssen verhindern, dass GKE Ihre Knoten automatisch aktualisiert, während Ihre Arbeitslast ausgeführt wird.
  • Wenn Ihr Cluster nicht für eine Release-Version registriert ist, deaktivieren Sie automatische Knotenupgrades. Wir empfehlen jedoch, Release-Versionen zu verwenden, bei denen Sie Wartungsausschlüsse mit detaillierteren Bereichen verwenden können.
• Automatische Knotenreparatur deaktivieren
• Mit Wartungsfenstern und ‑ausschlüssen können Sie Unterbrechungen bei laufenden Arbeitslasten minimieren und gleichzeitig dafür sorgen, dass GKE genügend Zeit für die automatische Wartung hat. Planen Sie diese Zeit so, dass keine Arbeitslasten ausgeführt werden.
• Damit Ihr Knotenpool auf dem neuesten Stand bleibt, empfehlen wir ein manuelles Upgrade Ihres Knotenpools, wenn keine Dynamic Workload Scheduler-Anfragen aktiv sind und der Knotenpool leer ist.

Hinweise zur Migration Ihres Clusters zu kurzlebigen Upgrades

GKE aktualisiert vorhandene Knoten mithilfe der Bereitstellung in der Warteschlange, um kurzlebige Upgrades zu verwenden, wenn der Cluster auf Version 1.32.2-gke.1652000 oder höher aktualisiert wird. Andere Einstellungen werden von GKE nicht aktualisiert. So werden beispielsweise keine automatischen Knotenupgrades aktiviert, wenn Sie sie für einen bestimmten Knotenpool deaktiviert haben.

Wir empfehlen Ihnen, die folgenden Best Practices jetzt zu implementieren, da Ihre Knotenpools kurzlebige Upgrades verwenden:

• Wenn Sie automatische Knotenupgrades mit dem Flag --no-enable-autoupgrade deaktiviert haben, werden sie durch diese Migration nicht wieder für den Knotenpool aktiviert. Wir empfehlen, automatische Knotenupgrades zu aktivieren, da kurzlebige Upgrades keine Unterbrechungen für vorhandene Knoten und die darauf ausgeführten Arbeitslasten verursachen. Weitere Informationen finden Sie unter Kurzlebige Upgrades.
• Wenn Ihr Cluster noch nicht in einem Release-Kanal registriert ist, sollten Sie ihn registrieren, damit Sie detailliertere Wartungsausschlüsse verwenden können.

Knotenrecycling bei Flex-Start

Um einen reibungslosen Übergang von Knoten zu ermöglichen und Ausfallzeiten für laufende Jobs zu vermeiden, unterstützt „flex-start“ das Knoten-Recycling. Wenn die Laufzeit eines Knotens abgelaufen ist, ersetzt GKE ihn automatisch durch einen neuen, um die laufenden Arbeitslasten zu erhalten.

Wenn Sie das Knotenrecycling verwenden möchten, müssen Sie ein benutzerdefiniertes Compute-Klassenprofil erstellen und das Feld nodeRecycling mit dem Parameter leadTimeSeconds in die flexStart-Spezifikation aufnehmen.

Mit dem Parameter leadTimeSeconds können Sie die Ressourcenverfügbarkeit und die Kosteneffizienz in Einklang bringen. Mit diesem Parameter wird angegeben, wie lange (in Sekunden) vor Ablauf der siebentägigen Lebensdauer eines Knotens mit der Bereitstellung eines neuen Knotens begonnen werden soll. Eine längere Vorlaufzeit erhöht die Wahrscheinlichkeit, dass der neue Knoten bereit ist, bevor der alte entfernt wird. Dies kann jedoch zusätzliche Kosten verursachen.

Das Recycling von Knoten umfasst die folgenden Schritte:

1. Recyclingphase:GKE prüft, ob ein mit „flex-start“ bereitgestellter Knoten das Feld nodeRecycling mit dem Parameter leadTimeSeconds hat. In diesem Fall startet GKE die Phase des Knotenrecyclings, wenn das aktuelle Datum größer oder gleich der Differenz zwischen den Werten der folgenden Felder ist:

   • creationTimestamp + maxRunDurationSeconds
   • leadTimeSeconds

   Das Flag creationTimeStamp enthält die Uhrzeit, zu der der Knoten erstellt wurde. Das Feld maxRunDurationSeconds kann in der benutzerdefinierten Compute-Klasse angegeben werden. Standardmäßig beträgt die Aufbewahrungsdauer sieben Tage.

2. Knoten erstellen:Der Erstellungsprozess für den neuen Knoten beginnt und durchläuft die Phasen „Warteschlange“ und „Bereitstellung“. Die Dauer der Warteschlangenphase kann dynamisch variieren, je nach Zone und spezifischer Beschleunigerkapazität.

3. Knoten, dessen siebentägige Laufzeit bald abläuft, absperren:Nachdem der neue Knoten in Betrieb ist, wird der alte Knoten gesperrt. Dadurch wird verhindert, dass neue Pods darauf geplant werden. Bestehende Pods auf diesem Knoten werden weiterhin ausgeführt.

4. Knotendeaktivierung:Der Knoten, dessen siebentägige Laufzeit bald abläuft, wird nach einem geeigneten Zeitraum deaktiviert. So wird sichergestellt, dass laufende Arbeitslasten zum neuen Knoten migriert wurden.

Das folgende Beispiel für eine Compute-Klassenkonfiguration enthält die Felder leadTimeSeconds und maxRunDuration:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: dws-model-inference-class
spec:
  priorities:
    - machineType: g2-standard-24
      spot: true
    - machineType: g2-standard-24
      maxRunDurationSeconds: 72000
      flexStart:
        enabled: true
        nodeRecycling:
          leadTimeSeconds: 3600
  nodePoolAutoCreation:
    enabled: true

Weitere Informationen zum Knotenrecycling finden Sie in der Anleitung LLMs in GKE mit einer kostenoptimierten und hochverfügbaren GPU-Bereitstellungsstrategie bereitstellen.

Beschränkungen

• Anti-Affinität zwischen Pods wird nicht unterstützt. Cluster Autoscaler berücksichtigt bei der Bereitstellung von Knoten keine Anti-Affinitätsregeln zwischen Pods. Dies kann zu nicht planbaren Arbeitslasten führen. Dies kann passieren, wenn Knoten für zwei oder mehr Dynamic Workload Scheduler-Objekte im selben Knotenpool bereitgestellt wurden.
• Nur GPU-Knoten werden unterstützt.
• Reservierungen werden mit dem Dynamic Workload Scheduler nicht unterstützt. Beim Erstellen des Knotenpools müssen Sie das Flag --reservation-affinity=none angeben. Der Dynamic Workload Scheduler erfordert und unterstützt nur die Standortrichtlinie ANY für Cluster-Autoscaling.
• Eine einzelne Dynamic Workload Scheduler-Anfrage kann bis zu 1.000 virtuelle Maschinen (VMs) erstellen. Dies ist die maximale Anzahl von Knoten pro Zone für einen einzelnen Knotenpool.
• GKE verwendet das ACTIVE_RESIZE_REQUESTS-Kontingent von Compute Engine, um die Anzahl der Anfragen für Dynamic Workload Scheduler zu steuern, die in einer Warteschlange ausstehen. Dieses Kontingent hat standardmäßig ein Limit von 100 Anfragen pro Google Cloud Projekt. Wenn Sie versuchen, eine Dynamic Workload Scheduler-Anfrage zu erstellen, die dieses Kontingent überschreitet, schlägt die neue Anfrage fehl.
• Knotenpools, die Dynamic Workload Scheduler verwenden, sind störungsanfällig, da die Knoten gemeinsam bereitgestellt werden. Weitere Informationen finden Sie unter Unterbrechungen bei Arbeitslasten mit Dynamic Workload Scheduler verwalten.
• In der Google Cloud -Konsole sind möglicherweise weitere kurzlebige VMs aufgeführt. Dieses Verhalten ist beabsichtigt, da die Compute Engine VMs erstellen und dann sofort wieder entfernen kann, bis die Kapazität zur Bereitstellung aller erforderlichen Maschinen verfügbar ist.
• Spot-VMs werden nicht unterstützt.
• Der Dynamic Workload Scheduler unterstützt keine sitzungsspezifischen Volumes. Sie müssen nichtflüchtige Volumes für den Speicher verwenden. Informationen zum Auswählen des besten Speichertyps mit nichtflüchtigen Volumes finden Sie unter Speicher für GKE-Cluster.
• Wenn für die Arbeitslast das Knotenrecycling verwendet wird und sie über einen Job bereitgestellt wird, konfigurieren Sie den Job mit Indexed als Abschlussmodus.

Nächste Schritte

• GPU-Typ auswählen
• GPUs mit dem Dynamic Workload Scheduler bereitstellen