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

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

Mit Flex-Start 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 Flex-Start gut für kleinere bis mittelgroße Arbeitslasten mit schwankenden Anforderungen oder kurzer Dauer. Dazu gehören beispielsweise das Vortraining kleiner Modelle, das Feinabstimmen von Modellen oder skalierbare Bereitstellungsmodelle.

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

  • Funktionsweise von Flex-Start in GKE.
  • Entscheiden Sie, ob der flexible Start für Ihre Arbeitslast geeignet ist.
  • Entscheiden Sie, welche Flex-Start-Konfiguration für Ihre Arbeitslast am besten geeignet ist.
  • Unterbrechungen bei Verwendung von Flex-Start verwalten
  • Einschränkungen von Flex-Start in GKE

Diese Seite richtet sich an Plattformadministratoren und ‑betreiber sowie 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:

  • Für Ihre Arbeitslasten sind GPU-Ressourcen erforderlich.
  • Für Ihre Arbeitslasten sind TPU-Ressourcen erforderlich, 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.

Flex-Start-Preise

Flex-Start wird empfohlen, wenn für Ihre Arbeitslast dynamisch bereitgestellte Ressourcen nach Bedarf für bis zu sieben Tage mit kurzfristigen Reservierungen, ohne komplexes Kontingentmanagement und kostengünstigen Zugriff erforderlich sind. Flex-Start basiert auf dem Dynamic Workload Scheduler und wird gemäß der Preisgestaltung für den Dynamic Workload Scheduler abgerechnet:

  • Rabattiert (bis zu 53%) für vCPUs, GPUs und TPUs.
  • Sie zahlen nur für die tatsächliche Nutzung.

Voraussetzungen

Damit Sie Flex-Start in GKE verwenden können, muss Ihr Cluster die folgenden Anforderungen erfüllen:

  • Wenn Sie GPUs verwenden möchten, benötigen Sie die GKE-Version 1.32.2-gke.1652000 oder höher.

  • Für die Ausführung von TPUs benötigen Sie die GKE-Version 1.33.0-gke.1712000 oder höher. 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.

Funktionsweise des Bereitstellungsmodus „Flex-Start“

Bei Flex-Start geben Sie die erforderliche GPU- oder TPU-Kapazität in Ihren Arbeitslasten an. Außerdem können Sie in Standardclustern den flexiblen Start für bestimmte Knotenpools konfigurieren. GKE stellt VMs automatisch bereit. Dazu wird der folgende Prozess ausgeführt, 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 der Flex-Start aktiviert ist und 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, sobald sie verfügbar sind. Diese Knoten werden maximal sieben Tage lang ausgeführt oder kürzer, wenn Sie einen Wert für den Parameter maxRunDurationSeconds angeben. 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, beträgt der Standardwert sieben Tage.
  5. Nach Ablauf der im Parameter maxRunDurationSeconds definierten Laufzeit werden die Knoten und die 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 Laufzeit, 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: GKE weist Ressourcen knotenweise zu. Bei dieser Konfiguration müssen Sie nur das Flag --flex-start beim Erstellen des Knotens festlegen.

  • Flex-Start mit Bereitstellung per Warteschlange: GKE weist alle angeforderten Ressourcen gleichzeitig zu. Wenn Sie diese Konfiguration verwenden möchten, müssen Sie beim Erstellen des Knotenpools die Flags --flex-start und enable-queued-provisioning hinzufügen. GKE folgt dem Prozess unter So funktioniert der Bereitstellungsmodus mit flexiblem Start in diesem Dokument, wendet aber auch die folgenden Bedingungen an:

    • 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 von Arbeitslasten nicht wiederverwendet.

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

Flex-Start Flex-Start mit Bereitstellung per Warteschlange
Verfügbarkeit Vorschau

Allgemein verfügbar (GA)

Hinweis: Flex-Start unterstützt die Flags flex-start und enable-queued-provisioning in der Vorschauphase.
Unterstützte Beschleuniger
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-Inferenz oder Batchjobs. Mittel bis groß, d. h., die Arbeitslast kann auf mehreren Knoten ausgeführt werden. Ihre Arbeitslast erfordert mehrere Ressourcen und kann erst ausgeführt werden, wenn alle Knoten bereitgestellt und gleichzeitig bereit sind. Diese Konfiguration eignet sich beispielsweise gut, wenn Sie Arbeitslasten für verteiltes Training mit maschinellem Lernen ausführen.
Bereitstellungstyp GKE stellt jeweils einen Knoten bereit, wenn Ressourcen verfügbar sind. GKE weist alle angeforderten Ressourcen gleichzeitig zu.
Einrichtungskomplexität 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
Strategie für Knotenupgrades Kurzlebige Upgrades Kurzlebige Upgrades
gcloud container node pool create-Flag --flex-start
  • --flex-start
  • --enable-queued-provisioning
Jetzt starten GPUs: TPUs: Große Arbeitslast mit Flex-Start und Bereitstellung per Warteschlange ausführen

Flex-Start-Konfiguration optimieren

Um eine robuste und kostenoptimierte KI-/ML-Infrastruktur zu erstellen, können Sie Flex-Start-Konfigurationen mit verfügbaren GKE-Funktionen kombinieren. Wir empfehlen, Compute-Klassen zu verwenden, um eine priorisierte Liste von Knotenkonfigurationen basierend auf den Anforderungen Ihrer Arbeitslast zu definieren. GKE wählt die am besten geeignete Konfiguration basierend auf der Verfügbarkeit und Ihrer definierten Priorität aus.

Unterbrechungen in Arbeitslasten verwalten, die Dynamic Workload Scheduler verwenden

Arbeitslasten, die die Verfügbarkeit aller oder der meisten Knoten in einem Knotenpool erfordern, reagieren empfindlich auf das Entfernen von Knoten. Außerdem wird die automatische Reparatur für Knoten, die über Dynamic Workload Scheduler-Anfragen bereitgestellt werden, nicht unterstützt. 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 Steuerungsebene des Clusters die Mindestversion für Flex-Start ausgeführt wird, also 1.32.2-gke.1652000 oder höher.

Bei kurzlebigen Upgrades wird ein Standard-Knotenpool oder eine Gruppe von Knoten in einem Autopilot-Cluster aktualisiert, ohne dass laufende Knoten unterbrochen werden. Neue Knoten werden mit der neuen Konfiguration erstellt und ersetzen nach und nach die vorhandenen Knoten mit der alten Konfiguration. Für frühere Versionen von GKE, die Flex-Start oder kurzlebige Upgrades nicht unterstützen, sind andere Best Practices erforderlich.

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

Flex-Start-Knoten und Knoten, die die Bereitstellung in der Warteschlange verwenden, werden automatisch für die Verwendung von kurzlebigen Upgrades konfiguriert, wenn auf dem Cluster Version 1.32.2-gke.1652000 oder höher ausgeführt wird.

Um Unterbrechungen bei Arbeitslasten zu minimieren, die auf Knoten mit kurzlebigen Upgrades ausgeführt werden, führen Sie die folgenden Aufgaben aus:

Bei Knoten in Clustern mit Versionen vor 1.32.2-gke.1652000, die also keine kurzlebigen Upgrades verwenden, finden Sie die spezifische Anleitung für diese Knoten.

Best Practices zur Minimierung von Arbeitslastunterbrechungen für in die Warteschlange gestellte Bereitstellungsknoten ohne kurzlebige Upgrades

Knoten, die die Warteschlangenbereitstellung in einem Cluster mit einer GKE-Version vor 1.32.2-gke.1652000 verwenden, nutzen keine kurzlebigen Upgrades. Cluster, die auf 1.32.2-gke.1652000 oder höher aktualisiert wurden und vorhandene in die Warteschlange gestellte Bereitstellungsknoten haben, werden automatisch für die Verwendung von kurzlebigen Upgrades aktualisiert.

Informationen zu Knoten, auf denen diese früheren Versionen ausgeführt werden, finden Sie in den folgenden Anleitungen:

Hinweise zur Migration Ihres Clusters zu kurzlebigen Upgrades

GKE aktualisiert vorhandene Knoten mithilfe der Warteschlangenbereitstellung, um kurzlebige Upgrades zu verwenden, wenn der Cluster auf Version 1.32.2-gke.1652000 oder höher aktualisiert wird. GKE aktualisiert keine anderen Einstellungen, z. B. das Aktivieren automatischer Knotenupgrades, wenn Sie sie für einen bestimmten Knotenpool deaktiviert haben.

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

  • Wenn Sie automatische Knotenupgrades mit dem Flag --no-enable-autoupgrade deaktiviert haben, werden sie durch diese Migration nicht wieder aktiviert. Wir empfehlen, automatische Knotenupgrades zu aktivieren, da kurzlebige Upgrades keine Auswirkungen auf vorhandene Knoten und die darauf ausgeführten Arbeitslasten haben. Weitere Informationen finden Sie unter Kurzlebige Upgrades.
  • Wenn Ihr Cluster noch nicht in einer Release-Version registriert ist, empfehlen wir, ihn zu registrieren, damit Sie detailliertere Wartungsausschlussbereiche verwenden können.

Knotenrecycling bei Flex-Start

Damit der Übergang von Knoten reibungslos verläuft und Ausfallzeiten für Ihre laufenden Jobs vermieden werden, unterstützt Flex-Start das Wiederverwenden von Knoten. Wenn ein Knoten das Ende seiner Laufzeit erreicht, wird er von GKE automatisch durch einen neuen Knoten ersetzt, um Ihre laufenden Arbeitslasten beizubehalten.

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

Mit dem Parameter leadTimeSeconds können Sie ein ausgewogenes Verhältnis zwischen Ressourcenverfügbarkeit und Kosteneffizienz schaffen. Mit diesem Parameter wird angegeben, wie viele Sekunden vor dem Ende der siebentägigen Laufzeit eines Knotens ein neuer Knoten bereitgestellt werden soll, um ihn zu ersetzen. Eine längere Vorlaufzeit erhöht die Wahrscheinlichkeit, dass der neue Knoten bereit ist, bevor der alte entfernt wird, kann aber zusätzliche Kosten verursachen.

Der Prozess zum Wiederverwenden von Knoten umfasst die folgenden Schritte:

  1. Wiederverwertungsphase:GKE prüft, ob für einen flexibel bereitgestellten Knoten das Feld nodeRecycling mit dem Parameter leadTimeSeconds festgelegt ist. Wenn ja, beginnt die Phase des Knoten-Recycling, wenn das aktuelle Datum größer oder gleich der Differenz zwischen den Werten aus den folgenden Feldern 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. Der Standardwert ist sieben Tage.

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

  3. Knoten, der das Ende seines siebentägigen Zeitraums erreicht, sperren:Nachdem der neue Knoten ausgeführt wird, wird der alte Knoten gesperrt. Dadurch wird verhindert, dass neue Pods auf dem Knoten geplant werden. Bestehende Pods auf diesem Knoten werden weiterhin ausgeführt.

  4. Bereitstellung des Knotens aufheben:Der Knoten, der das Ende seiner siebentägigen Laufzeit erreicht, wird nach einem angemessenen Zeitraum bereitgestellt. 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 zur Verwendung von Knoten-Recycling 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 keine Anti-Affinitätsregeln zwischen Pods bei der Knotenbereitstellung, was zu nicht planbaren Arbeitslasten führen kann. Dies kann passieren, wenn Knoten für zwei oder mehr Dynamic Workload Scheduler-Objekte im selben Knotenpool bereitgestellt wurden.
  • Es werden nur GPU-Knoten 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.
  • Mit einer einzelnen Dynamic Workload Scheduler-Anfrage können bis zu 1.000 VMs erstellt werden. 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 in Arbeitslasten verwalten, die den Dynamic Workload Scheduler verwenden.
  • Möglicherweise werden in der Google Cloud -Konsole zusätzliche kurzlebige VMs aufgeführt. Dieses Verhalten ist beabsichtigt, da Compute Engine möglicherweise VMs erstellt und dann sofort wieder entfernt, bis die Kapazität zum Bereitstellen aller erforderlichen Maschinen verfügbar ist.
  • Spot-VMs werden nicht unterstützt.
  • Der Dynamic Workload Scheduler unterstützt keine kurzlebigen Volumes. Sie müssen nichtflüchtige Volumes für den Speicher verwenden. Informationen zum Auswählen des besten Speichertyps, der nichtflüchtige Volumes verwendet, finden Sie unter Speicher für GKE-Cluster.
  • Wenn für die Arbeitslast das Knoten-Recycling verwendet wird und sie über einen Job bereitgestellt wird, konfigurieren Sie den Job mit dem completion mode (Abschlussmodus) auf Indexed.

Nächste Schritte