Verfügbarkeit von GPUs mit dem Bereitstellungsmodus „Flex-Start“

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

Mit der flexiblen Startzeit können Sie Accelerators nach Bedarf für bis zu sieben Tage dynamisch bereitstellen, ohne dass eine bestimmte Startzeit festgelegt ist und ohne dass Sie langfristige Reservierungen verwalten müssen. Daher eignet sich Flex-Start gut 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.
  • Sie haben eine begrenzte oder keine reservierte GPU-Kapazität und benötigen einen zuverlässigeren Zugriff auf GPUs.
  • 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

Wenn Sie „flex-start“ in GKE verwenden möchten, muss Ihr Cluster die Version 1.32.2-gke.1652000 oder höher verwenden.

So funktioniert das Bereitstellungsmodell „Flex-Start“

Mit „flex-start“ geben Sie die erforderliche GPU-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 GPU-Ressourcen an, die nicht sofort verfügbar sind. Diese Anfrage kann direkt über die Arbeitslastspezifikation oder über Planungstools wie benutzerdefinierte Compute-Klassen oder Warteschlangen 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. Der Scheduler wartet, bis alle benötigten Ressourcen in einer einzigen Zone verfügbar sind.
  5. 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.
  6. Nach Ablauf der im Parameter maxRunDurationSeconds angegebenen Laufzeit werden die Knoten und Pods vorzeitig beendet.
  7. 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. 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. 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 der folgenden Tabelle werden die Flex-Start-Konfigurationen verglichen:

Flex-Start Flex-Start mit Bereitstellung per Warteschlange
Verfügbarkeit Vorabversion
Hinweis: Wenn Sie sich für die Vorabversion von Flex-Start anmelden möchten, füllen Sie dieses Antragsformular aus. Wenn Sie Feedback geben oder Support für diese Funktion anfordern möchten, wenden Sie sich an dws-flex-start-feedback@google.com.

Allgemein verfügbar (General Availability, GA)

Hinweis: „Flex-start“ unterstützt in der Vorabversion die Flags flex-start und enable-queued-provisioning. Wenn Sie sich für die Vorabversion dieser Flags registrieren möchten, füllen Sie dieses Formular aus. Wenn Sie Feedback geben oder Support für diese Funktion anfordern möchten, wenden Sie sich an dws-flex-start-feedback@google.com.
Empfohlene Arbeitslastgröße Klein bis mittel, was bedeutet, dass die Arbeitslast auf einem einzelnen Knoten ausgeführt werden kann. Diese Konfiguration eignet sich beispielsweise gut für kleine Trainingsjobs, Offline-Inferenzen oder Batchjobs. Mittel bis groß, was bedeutet, dass die Arbeitslast auf mehreren Knoten ausgeführt werden kann. Ihre Arbeitslast erfordert mehrere Ressourcen und kann erst ausgeführt werden, wenn alle GPU-Knoten bereitgestellt und bereit sind. Diese Konfiguration eignet sich beispielsweise gut für verteilte ML-Trainingslasten.
Bereitstellungstyp GKE stellt einen Knoten nach dem anderen bereit, wenn Ressourcen verfügbar sind. GKE weist alle angeforderten Ressourcen gleichzeitig zu.
Komplexität der Einrichtung Weniger komplex. Diese Konfiguration ähnelt On-Demand- und Spot-VMs. Komplexer. Wir empfehlen dringend, ein Tool zur Kontingentverwaltung wie Kueue zu verwenden.
Unterstützung für benutzerdefinierte Compute-Klassen Ja Nein
Knotenrecycling Ja Nein
Preis Flex-Start-SKU Flex-Start-SKU
Kontingent Auf Abruf Auf Abruf
Strategie für Knotenupgrades Kurzlebige Upgrades Kurzlebige Upgrades
gcloud container node pool create-Flag --flex-start
  • --flex-start
  • --enable-queued-provisioning
Jetzt starten Große Arbeitslast mit Flex-Start und Bereitstellung per Warteschlange ausführen

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:

Für Knoten in Clustern mit Versionen vor 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 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 kurzlebiger Upgrades umgestellt.

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

Hinweise für die 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 siebentägige Laufzeit eines Knotens abgelaufen ist, ersetzt GKE ihn automatisch durch einen neuen, um Ihre laufenden Arbeitslasten zu erhalten.

Wenn Sie das Knotenrecycling verwenden möchten, müssen Sie ein benutzerdefiniertes Profil für Compute-Klassen erstellen und das Feld nodeRecycling in die flexStart-Spezifikation mit den folgenden Parametern aufnehmen:

  • leadTimeSeconds:Ein konfigurierbarer Parameter, mit dem Sie die Ressourcenverfügbarkeit und die Kosteneffizienz in Einklang bringen können. Mit dem Parameter leadTimeSeconds wird angegeben, wie viele Sekunden vor Ablauf der siebentägigen Laufzeit eines Knotens ein neuer Bereitstellungsprozess für den Knoten gestartet werden soll. Mit einer längeren Vorlaufzeit steigt die Wahrscheinlichkeit, dass der neue Knoten bereit ist, bevor der alte entfernt wird. Dies kann jedoch zusätzliche Kosten verursachen.
  • maxRunDurationSeconds:Ein konfigurierbarer Parameter, mit dem Sie die maximale Dauer festlegen können, für die ein Knoten aktiv sein kann.

Das Recycling von Knoten umfasst die folgenden Schritte:

  1. Recyclingphase:GKE prüft, ob für einen mit „flex-start“ bereitgestellten Knoten das Flag nodeRecycling auf true gesetzt ist. In diesem Fall startet GKE die Phase des Knotenrecyclings, wenn das aktuelle Datum der Differenz zwischen den Werten der folgenden Felder entspricht oder größer ist:

    • creationTimestamp + maxRunDurationSeconds
    • leadTimeSeconds

    Das Flag creationTimeStamp enthält die Uhrzeit, zu der der Knoten erstellt wurde.

  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 je nach Zone und spezifischer Beschleunigerkapazität variieren.

  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. Vorhandene 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.

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 Console werden 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