GPU-, TPU- und H4D-Nutzung mit dem Bereitstellungsmodus „Flex-Start“

Auf dieser Seite wird Flex-Start in Google Kubernetes Engine (GKE) beschrieben. Flex-Start, unterstützt durch Dynamic Workload Scheduler, bietet eine flexible und kostengünstige Methode zur Nutzung spezialisierter Compute-Ressourcen wie GPUs oder TPUs, wenn Sie KI-/ML-Arbeitslasten ausführen müssen.

Mit Flex-Start können Sie Flex-Start-VMs für GPUs, TPUs und die H4D-Maschinenserie 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. Beispiele sind 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, ob Flex-Start für Ihre Arbeitslast geeignet ist.
  • Entscheiden, welche Flex-Start-Konfiguration für Ihre Arbeitslast geeignet ist.
  • Unterbrechungen bei der Verwendung von Flex-Start-VMs verwalten.
  • Beschränkungen von Flex-Start-VMs in GKE.

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

Wann Flex-Start verwendet werden sollte

Wir empfehlen die Verwendung von Flex-Start, wenn Ihre Arbeitslasten alle folgenden Bedingungen erfüllen:

  • Ihre Arbeitslasten erfordern GPU-Ressourcen.
  • Ihre Arbeitslasten erfordern TPU-Ressourcen, die in TPU-Slice-Knotenpools mit einem einzelnen Host ausgeführt werden.
  • Ihre Arbeitslasten erfordern andere spezialisierte Hardware wie die für HPC optimierte H4D-Maschinenserie.
  • 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 Ihre Arbeitslast dynamisch bereitgestellte Ressourcen nach Bedarf für bis zu sieben Tage mit kurzfristigen Reservierungen, ohne komplexe Kontingentverwaltung und mit kostengünstigem Zugriff erfordert. Flex-Start wird von Dynamic Workload Scheduler unterstützt und nach den Preisen für Dynamic Workload Scheduler abgerechnet:

  • Rabattiert (bis zu 53%) für vCPUs, GPUs und TPUs.
  • Sie zahlen nach Nutzung.

Voraussetzungen

Für die Verwendung von Flex-Start in GKE muss Ihr Cluster die folgenden Anforderungen erfüllen:

  • Für die Ausführung von GPUs verwenden Sie die GKE-Version 1.32.2-gke.1652000 oder höher.

  • Informationen zu den GKE-Versionsanforderungen für die Ausführung von TPUs finden Sie unter TPUs in GKE planen. Flex-Start unterstützt die folgenden Versionen und Zonen:

    • Ironwood (TPU7x) in us-central1-c.
    • TPU Trillium (v6e) in asia-northeast1-b, us-east5-a und us-east5-b.
    • TPU v5e in us-west4-a.
    • TPU v5p in us-east5-a.

    TPU v3 und v4 werden nicht unterstützt.

Funktionsweise des Flex-Start-Bereitstellungsmodus

Mit Flex-Start geben Sie die erforderliche Compute-Kapazität (z. B. GPUs oder TPUs) in Ihren Arbeitslasten an. Außerdem können Sie in Standardclustern Flex-Start für bestimmte Knotenpools konfigurieren. GKE stellt Flex-Start-VMs automatisch bereit, indem der folgende Prozess ausgeführt wird, wenn Kapazität verfügbar wird:

  1. Die Arbeitslast fordert Kapazität an, die nicht sofort verfügbar ist. Diese Anfrage kann direkt über die Arbeitslastspezifikation oder über Orchestrierungstools wie benutzerdefinierte Compute-Klassen oder Kueue erfolgen.
  2. GKE erkennt, dass Flex-Start für Ihren Knoten aktiviert ist. Wenn das Flag --request-valid-for-duration nicht angegeben ist, können GPU-Arbeitslasten bis zu 14 Tage auf Ressourcen warten. Im Gegensatz dazu können TPU-Arbeitslasten unbegrenzt warten.
  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. 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 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, wobei GKE Ressourcen knotenweise zuweist. Für diese Konfiguration müssen Sie nur das Flag --flex-start beim Erstellen des Knotens festlegen.

  • Flex-Start mit Bereitstellung per Warteschlange, wobei 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. GKE folgt dem Prozess unter Funktionsweise des Flex-Start-Bereitstellungsmodus 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 nicht zwischen den Arbeitslastausführungen 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 Vorschau.
Unterstützte Beschleuniger
Empfohlene Arbeitslastgröße Klein bis mittelgroß, d. h., die Arbeitslast kann auf einem einzelnen Knoten ausgeführt werden. Diese Konfiguration eignet sich beispielsweise gut für kleine Trainingsjobs, Offline-Inferenzen 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 gleichzeitig bereitgestellt und einsatzbereit sind. Diese Konfiguration eignet sich beispielsweise gut für verteilte Trainingsarbeitslasten für maschinelles Lernen.
Bereitstellungstyp GKE stellt jeweils einen Knoten bereit, wenn Ressourcen verfügbar sind. Bei TPUs erstellt GKE jeweils einen Knoten in TPU-Slice-Knotenpools mit einem einzelnen Host und den vollständigen Slice in TPU-Slice-Knotenpools mit mehreren Hosts. GKE weist alle angeforderten Ressourcen gleichzeitig zu.
Komplexität der Einrichtung Weniger komplex. Diese Konfiguration ähnelt VMs auf Abruf 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
Quota
  • Kontingent für GPUs auf Abruf
  • Kontingent für TPUs auf Abruf
  • Kontingent für GPUs auf Abruf
  • Kontingent für TPUs 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 GPUs: TPUs: Große Arbeitslast mit Flex-Start mit 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 Ihren Arbeitslast anforderungen zu definieren. GKE wählt die am besten geeignete Konfiguration basierend auf der Verfügbarkeit und der von Ihnen definierten Priorität aus.

Unterbrechungen in Arbeitslasten verwalten, die Dynamic Workload Scheduler verwenden

Arbeitslasten, für die die Verfügbarkeit aller oder der meisten Knoten in einem Knotenpool erforderlich ist, sind anfällig für vorzeitige Beendigungen. Außerdem unterstützen Knoten, die mit Dynamic Workload Scheduler-Anfragen bereitgestellt werden, keine automatische Reparatur. Bei der automatischen Reparatur werden alle Arbeitslasten von einem Knoten entfernt, sodass sie nicht ausgeführt werden können.

Für alle Knoten, die Flex-Start-VMs, die Bereitstellung per Warteschlange oder beides verwenden, werden kurzlebige Upgrades verwendet, wenn auf der Steuerungsebene des Clusters die Mindestversion für Flex-Start ausgeführt wird: 1.32.2-gke.1652000 oder höher.

Bei kurzlebigen Upgrades wird ein Standardknotenpool 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 vorhandene Knoten mit der alten Konfiguration. Für frühere Versionen von GKE, die Flex-Start oder kurzlebige Upgrades nicht unterstützen, gelten andere Best Practices.

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

Knoten, die Flex-Start-VMs verwenden, und Knoten, die die Bereitstellung per 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.

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

Informationen zu Knoten in Clustern mit Versionen vor 1.32.2-gke.1652000, die daher keine kurzlebigen Upgrades verwenden, finden Sie in der spezifischen Anleitung für diese Knoten.

Best Practices zur Minimierung von Arbeitslastunterbrechungen für Knoten mit Bereitstellung per Warteschlange ohne kurzlebige Upgrades

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

Informationen zu Knoten mit diesen früheren Versionen finden Sie in der folgenden Anleitung:

Hinweise zur Migration Ihres Clusters zu kurzlebigen Upgrades

GKE aktualisiert vorhandene Knoten mit Bereitstellung per Warteschlange, 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, die folgenden Best Practices zu implementieren, da Ihre Knotenpools jetzt kurzlebige Upgrades verwenden:

Knotenrecycling in Flex-Start

Um einen reibungslosen Übergang von Knoten zu gewährleisten und Ausfallzeiten für Ihre laufenden Jobs zu vermeiden, unterstützt Flex-Start das Knotenrecycling. Wenn ein Knoten das Ende seiner Laufzeit erreicht, ersetzt GKE ihn automatisch durch einen neuen, um Ihre laufenden Arbeitslasten beizubehalten.

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

Mit dem Parameter leadTimeSeconds können Sie die Verfügbarkeit von Ressourcen und die Kosteneffizienz ausgleichen. Dieser Parameter gibt an, wie viele Sekunden vor Ablauf der siebentägigen Laufzeit eines Knotens ein neuer Knotenbereitstellungsprozess gestartet 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 Knotenrecyclingprozess besteht aus den folgenden Schritten:

  1. Recyclingphase:GKE prüft, ob für einen mit Flex-Start bereitgestellten Knoten das Feld nodeRecycling mit dem Parameter leadTimeSeconds festgelegt ist. Wenn ja, startet GKE die Knotenrecyclingphase, wenn das aktuelle Datum größer oder gleich der Differenz zwischen den Werten aus den folgenden Feldern ist:

    • creationTimestamp plus 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 und ist standardmäßig auf sieben Tage festgelegt.

  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 seiner siebentägigen Laufzeit erreicht, sperren: Nachdem der neue Knoten ausgeführt wird, wird der alte Knoten gesperrt. Dadurch wird verhindert, dass neue Pods darauf geplant werden. Vorhandene Pods auf diesem Knoten werden weiterhin ausgeführt.

  4. Knotenbereitstellung aufheben:Die Bereitstellung des Knotens, der das Ende seiner siebentägigen Laufzeit erreicht, wird nach einem geeigneten Zeitraum aufgehoben. 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 des Knotenrecyclings finden Sie in der Anleitung LLMs in GKE mit einer kostenoptimierten und hochverfügbaren GPU-Bereitstellungsstrategie bereitstellen.

Beschränkungen

  • Die 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.
  • 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 ANY Standortrichtlinie für Cluster-Autoscaling.
  • Eine einzelne Dynamic Workload Scheduler-Anfrage kann bis zu 1.000 VMs erstellen. Dies ist die maximale Anzahl von Knoten pro Zone für einen einzelnen Knotenpool.
  • GKE verwendet das Compute Engine-Kontingent ACTIVE_RESIZE_REQUESTS, um die Anzahl der Dynamic Workload Scheduler-Anfragen 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 Dynamic Workload Scheduler verwenden.
  • In der Google Cloud Konsole werden möglicherweise zusätzliche kurzlebige VMs aufgeführt. Dieses Verhalten ist beabsichtigt, da Compute Engine möglicherweise VMs erstellt und dann sofort entfernt, bis die Kapazität zur Bereitstellung aller erforderlichen Maschinen verfügbar ist.
  • Spot-VMs werden nicht unterstützt.
  • 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 die Arbeitslast Knotenrecycling verwendet und von einem Job bereitgestellt wird, konfigurieren Sie den Job so, dass der Abschlussmodus auf Indexed festgelegt ist.
  • Ein einzelnes ProvisioningRequest-Objekt unterstützt nur einen Eintrag in der Liste podSets. Anfragen mit mehreren podSet-Einträgen schlagen fehl.

Nächste Schritte