Optionen für die Nutzung von Beschleunigern für KI-/ML-Arbeitslasten in GKE

Auf dieser Seite werden die verfügbaren Techniken beschrieben, mit denen Sie Computing-Beschleuniger wie GPUs oder TPUs basierend auf den Anforderungen Ihrer KI-/ML-Arbeitslasten erhalten können. Diese Techniken werden in GKE als Optionen für die Nutzung von Beschleunigern bezeichnet. Wenn Sie die verschiedenen Nutzungsoptionen kennen, können Sie die Ressourcennutzung optimieren, um eine Unterauslastung von Ressourcen zu vermeiden, die Wahrscheinlichkeit zu erhöhen, Ressourcen zu erhalten, und ein Gleichgewicht zwischen Kosten und Leistung zu finden.

Diese Seite richtet sich an Plattformadministratoren und ‑operatoren, die mit ML-Entwicklern zusammenarbeiten, um die erforderlichen Ressourcen für die erfolgreiche Bereitstellung von KI-/ML-Arbeitslasten zu erhalten.

Weitere Informationen zu gängigen Rollen und Beispielaufgaben, auf die wir in Google Cloud Inhalten verweisen, finden Sie unter Häufig verwendete GKE-Nutzerrollen und -Aufgaben.

Nutzungsoptionen

Sie können in GKE aus den folgenden Optionen auswählen, um Beschleuniger zu nutzen:

  • On-Demand:Sie nutzen TPUs oder GPUs in GKE, ohne Kapazität im Voraus zu reservieren. Bevor Sie Ressourcen anfordern, müssen Sie genügend On-Demand-Kontingent für den jeweiligen Typ und die jeweilige Anzahl von Beschleunigern haben. On-Demand ist die flexibelste Nutzungsoption. Es gibt jedoch keine Garantie dafür, dass genügend On-Demand-Ressourcen verfügbar sind, um Ihre Anfrage zu erfüllen.
  • Reservierungen:Sie reservieren Ressourcen für einen bestimmten Zeitraum. Eine Reservierung kann Folgendes sein:
    • Vorausschauende Reservierungen:Sie reservieren Ressourcen für in der Regel längere Zeiträume für einen bestimmten Zeitpunkt in der Zukunft. Sie haben während dieses Zeitraums exklusiven Zugriff auf die reservierten Ressourcen. Für vorausschauende Reservierungen ist die Zusammenarbeit mit einem Technical Account Manager (TAM) erforderlich. Weitere Informationen finden Sie in der Anleitung zu TPU und GPUs.
    • Vorausschauende Reservierungen für bis zu 90 Tage (im Kalendermodus) : Sie fordern Kapazität für einen bestimmten Zeitraum an. Ein Kalenderberater schlägt verfügbare Termine vor. Vorausschauende Reservierungen für bis zu 90 Tage (im Kalendermodus) bieten mehr Flexibilität für kürzere Zeiträume und die Suche nach Kapazität im Self-Service. Weitere Informationen finden Sie unter Anfragen für vorausschauende Reservierungen im Kalendermodus.
    • On-Demand-Reservierungen:Sie können eine On-Demand-Reservierung anfordern, die bereitgestellt wird, sobald die Kapazität verfügbar ist. Das ist ähnlich wie bei der On-Demand-Option. Während die Reservierung aktiv ist, bezahlen Sie für die Ressourcen, unabhängig davon, ob Sie sie verwenden oder nicht.
  • Flex-Start:Sie sichern sich eng zugewiesene Ressourcen für Arbeitslasten mit kurzer Ausführungsdauer ohne Reservierung. Sie fordern eine bestimmte Anzahl von GPUs oder TPUs an und Compute Engine stellt sie bereit, sobald Kapazität verfügbar ist. Die GPUs oder TPUs werden bis zu sieben Tage lang ohne Unterbrechung ausgeführt. Weitere Informationen finden Sie unter Flex-Start-Bereitstellung.
  • Spot:Sie stellen Spot-VMs bereit, mit denen Sie erhebliche Rabatte erhalten. Spot-VMs können jedoch jederzeit mit einer 30-sekündigen Warnung vorzeitig beendet werden. Weitere Informationen finden Sie unter Spot-VMs.

Um den Erfolg der Bereitstellung bei Einschränkungen der Compute-Ressourcen zu optimieren, können Sie diese Optionen mit ComputeClasses orchestrieren.

Beschleunigerkontingent in GKE

Kontingente und Systemlimits beschränken Ihre Nutzung von Google Cloud Ressourcen, um die Ressourcenverfügbarkeit für alle Google Cloud Nutzer zu gewährleisten. Kontingente haben Standardwerte, aber Sie können in der Regel Anpassungen anfordern. Systemlimits sind feste Werte, die nicht geändert werden können. Standardmäßig haben Projekte in der Regel kein erhebliches Beschleunigerkontingent. Sie müssen ein Kontingent für bestimmte Beschleunigertypen und ‑regionen anfordern und genehmigen lassen.

Berücksichtigen Sie beim Verwalten der Kontingente, die für Ihre Arbeitslasten erforderlich sind, die folgenden Merkmale:

  • Sie müssen das für jede Nutzungsoption erforderliche Kontingent anfordern. Die erforderlichen Kontingente für die einzelnen Nutzungsoptionen finden Sie in der Tabelle Nutzungsoption auswählen in den entsprechenden Kontingentparametern. Wenn nicht genügend Kontingent vorhanden ist, schlagen Versuche, Cluster oder Knotenpools zu erstellen oder Arbeitslasten bereitzustellen, für die Beschleuniger erforderlich sind, mit dem Fehler Quota exceeded fehl.

  • Sie müssen ein Kontingent anfordern, wenn Sie benutzerdefinierte ComputeClasses in Autopilot verwenden. Die Knoten, die zur Erfüllung der ComputeClass-Anforderungen bereitgestellt werden, verbrauchen weiterhin das Kontingent Ihres Projekts für die angegebenen Beschleuniger.

  • Google Cloud Für Konten im kostenlosen Testzeitraum gelten Einschränkungen bei der Anforderung von Kontingenterhöhungen für hochwertige Ressourcen wie GPUs und TPUs. Wenn Sie auf Beschleunigerkontingente zugreifen möchten, führen Sie ein Upgrade auf ein kostenpflichtiges Konto durch.

Wenn Sie Kontingente prüfen und anfordern möchten, rufen Sie in der Google Cloud Console die Seite Kontingente auf. Sie können nach Beschleunigerkontingenten filtern und Erhöhungen anfordern.

Nutzungsoption auswählen

Berücksichtigen Sie die folgenden Punkte, um die beste Nutzungsoption für Ihre KI-/ML-Arbeitslast auszuwählen:

  • Arbeitslasttyp:Berücksichtigen Sie den Typ der Arbeitslast, die Sie implementieren möchten. Die GKE-Anforderungen variieren, je nachdem, ob Sie eine Trainings- oder eine Inferenzarbeitslast ausführen:
    • Training:Erfordert leistungsstarke Ressourcen mit erheblichem Arbeitsspeicher. Trainingsarbeitslasten haben in der Regel eine klar definierte Lebensdauer. Diese Arbeitslasten lassen sich in der Regel leichter planen, da sie weniger anfällig für plötzliche Spitzen im Ressourcenverbrauch sind.
    • Inferenz:Erfordert in der Regel Beschleuniger, die für Skalierbarkeit und niedrigere Kosten optimiert sind. Inferenzarbeitslasten können bei plötzlichen Spitzen im Ressourcenverbrauch erheblichen Beschleunigerspeicher erfordern.
  • Lebensdauer basierend auf der Implementierungsphase:Berücksichtigen Sie Ihr Geschäftsziel, wenn Sie einen Proof of Concept (POC), eine Plattformbewertung, eine Anwendungsentwicklung oder ‑prüfung, die Produktionsumgebung oder die Optimierung ausführen.
  • Zeit bis zur Bereitstellung:Bestimmen Sie, ob Ihre Arbeitslast sofort ausgeführt werden muss oder ob sie in der Zukunft ausgeführt werden kann. Wenn die Ausführung in der Zukunft möglich ist, bestimmen Sie, wie flexibel die Startzeit sein kann.
  • Gleichgewicht zwischen Kosten und Leistung:Bewerten Sie die Leistungsanforderungen Ihrer Arbeitslast und die Budgetbeschränkungen, um den kostengünstigsten Beschleuniger auszuwählen. Berücksichtigen Sie das Verhältnis zwischen den Kosten der Beschleuniger und ihren Leistungsmerkmalen. Neue Beschleuniger können zu einem besseren Kosten-Leistungs-Verhältnis führen.

Nutzungsoption auswählen

Wählen Sie in der folgenden Tabelle eine Nutzungsoption aus:

Nutzungsoption Bereitstellungsparameter Unterstützte Beschleuniger Details Beispielarbeitslasten
On-Demand-Reservierungen
  • Zeit bis zur Bereitstellung:Sofort (mit genehmigter Reservierung)
  • Lebensdauer:Langfristig (pro Reservierung)
  • Beliebige GPU (außer A4X, A4 oder A3 Ultra)
  • Beliebige TPU
  • Kosten:Ihnen wird der gesamte Reservierungszeitraum in Rechnung gestellt.
  • Kontingent:Das Kontingent wird automatisch erhöht, bevor die Kapazität bereitgestellt wird.
  • Lang laufende, große Arbeitslasten wie das Vortraining von Foundation Models oder Inferenz mit mehreren Hosts.
  • Produktionsarbeitslasten.
Vorausschauende Reservierungen
  • Zeit bis zur Bereitstellung:Sofort (mit genehmigter Reservierung)
  • Lebensdauer:Langfristig (pro Reservierung)
  • G2
  • A2
  • A3 High mit 8 GPUs
  • A3 Mega
  • A3 Edge
  • Kosten:Ihnen wird der gesamte Reservierungszeitraum in Rechnung gestellt.
  • Kontingent:Das Kontingent wird automatisch erhöht, bevor die Kapazität bereitgestellt wird.
  • Lang laufende, große Arbeitslasten wie das Vortraining von Foundation Models oder Inferenz mit mehreren Hosts.
  • Produktionsarbeitslasten.
Vorausschauende Reservierungen für bis zu 90 Tage (im Kalendermodus)
  • Zeit bis zur Bereitstellung:Sofort (mit genehmigter Reservierung)
  • Lebensdauer:Bis zu 90 Tage
  • A4
  • A3 Ultra
  • A3 Mega
  • A3 High mit 8 GPUs
  • A3 Edge
  • Ironwood (TPU7x)
  • TPU v6e
  • TPU v5p
  • TPU v5e
  • Kosten:Mit Rabatt (bis zu 53%) Ihnen wird der Reservierungszeitraum in Rechnung gestellt.
  • Kontingent:Es wird kein Kontingent berechnet.
  • Verteilte Arbeitslasten mit kurzer Ausführungsdauer wie Modellfeinabstimmung, Simulationen oder Batch-Inferenz, bei denen eine genaue Startzeit erforderlich ist.
  • Arbeitslasten für Plattformbewertung, Benchmarking oder Optimierungstests.
Flex-Start-Bereitstellungsmodus
  • Zeit bis zur Bereitstellung:On-Demand (je nach Verfügbarkeit)
  • Lebensdauer:Bis zu 7 Tage pro Zuweisung
  • Alle GPU-Familien außer A4X
  • Alle TPU-Versionen
  • Batch-Arbeitslasten wie kleines Modelltraining, Feinabstimmung oder skalierbare Inferenz, bei denen die Startzeit flexibel ist.
  • Arbeitslasten für POCs oder Integrationstests.
Spot-VMs
  • Zeit bis zur Bereitstellung:On-Demand (je nach Verfügbarkeit)
  • Lebensdauer:Variabel, kann mit einer 30-sekündigen Warnung vorzeitig beendet werden
  • Alle GPU-Familien außer A4X
  • Alle TPU-Versionen
  • Arbeitslasten mit niedrigerer Priorität und Fehlertoleranz wie CI/CD, Datenanalysen oder Hochleistungs-Computing (HPC).
  • Arbeitslasten, die häufig unterbrochen werden können.
On-Demand (GPUs oder TPUs)
  • Zeit bis zur Bereitstellung:Sofort (je nach Verfügbarkeit)
  • Lebensdauer:Kein Limit
  • Alle GPU-Familien außer A4X, A4 oder A3 Ultra
  • Alle TPU-Versionen
  • Kosten:Sie zahlen nach Nutzung.
  • Kontingent: GPU oder TPU On-Demand-Kontingent wird berechnet.
  • Allgemeine Arbeitslasten, die sofort ausgeführt werden müssen.

Kosten und Bereitstellung von Arbeitslasten mit ComputeClasses optimieren

Mit ComputeClasses können Sie Ihre Strategie für die Nutzung von Beschleunigern dynamisch verwalten und automatisieren, indem Sie eine prioritätsbasierte Liste von Fallback-Konfigurationen definieren. Bei Scale-up-Vorgängen versucht GKE, Knoten gemäß der von Ihnen festgelegten Prioritätshierarchie bereitzustellen.

In der folgenden Liste werden die Nutzungsoptionen beschrieben, die mit ComputeClasses verfügbar sind, und wie Sie sie konfigurieren. Vollständige YAML-Manifeste finden Sie unter Beispiele für Nutzungsoptionen mit ComputeClasses.

  • Reservierungen: Sie können den Namen der Reservierung im reservations Feld in Ihrer ComputeClass definieren. So wird sichergestellt, dass GKE zuerst versucht, Ihre reservierte Kapazität zu nutzen, bevor es auf eine Fallback-Option zurückgreift.
  • Flex-Start-Bereitstellungsmodus: Aktivieren Sie die Flex-Warteschlange mit dem flexStart Feld in Ihrer ComputeClass und konfigurieren Sie die Dauer für den Austausch von Fallback-Knoten mit den nodeRecycling Feldern.
  • Spot-VMs: Weisen Sie GKE an, Spot-VMs zu verwenden, wenn Knoten für diese Prioritätsregel bereitgestellt werden, indem Sie das spot Feld auf true setzen.
  • On-Demand-Kapazität in Kombination mit einer multizonalen Standortrichtlinie: Deklarieren Sie die Standardkonfigurationen für Maschinen in der Prioritätenliste und konfigurieren Sie eine Fallback-Standortstrategie mit den location Feldern.

ComputeClasses unterstützen keine vorausschauenden Reservierungen oder vorausschauenden Reservierungen für bis zu 90 Tage (im Kalendermodus).

Beispiele für Nutzungsoptionen mit ComputeClasses

In den folgenden Abschnitten finden Sie Konfigurationsbeispiele für diese Strategien.

Reservierungen mit Fallback-Konfiguration

Diese Konfiguration eignet sich am besten für Arbeitslasten, die Unterbrechungen tolerieren können, und nicht für Arbeitslasten, die von nichtflüchtigen Daten abhängen oder bis zum Abschluss ausgeführt werden müssen.

Diese Konfiguration erstellt mit den folgenden Schritten eine robuste Fallback-Strategie:

  1. Reservierungen zuerst nutzen:GKE versucht, Knoten mit Ihrer spezifischen, im Voraus gekauften Kapazitätsreservierung bereitzustellen.
  2. Fallback auf Flex-Start:Wenn die Reservierungskapazität vollständig genutzt wird, greift GKE auf kurzfristige, rabattierte Flex-Start-Ressourcen zurück.
  3. Fallback auf On-Demand:Als letzte Fallback-Option stellt GKE Standard-On-Demand-Ressourcen bereit.

  4. Zurück zu Reservierungen migrieren:Wenn Sie die aktive Migration aktivieren, weist GKE Arbeitslasten automatisch zusammen und migriert sie zurück zu den Reservierungsknoten mit höherer Priorität, sobald Kapazität verfügbar ist. Diese Migration kann zu Unterbrechungen führen.

    apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: ha-gpu-fallback
spec:
  activeMigration:
    optimizeRulePriority: true # Migrate workloads back to reservation when capacity releases
  priorities:
  # Priority 1: Consume specific corporate reservation first
  - gpu:
      type: nvidia-l4
      count: 1
    reservations:
      affinity: Specific
      specific:
      - name: reserved-l4-pool
        project: my-project
        zones: [us-central1-a]
  # Priority 2: Fallback to Flex Start (short-duration allocation)
  - gpu:
      type: nvidia-l4
      count: 1
    flexStart:
      enabled: true
  # Priority 3: Fallback to On-demand resources
  - gpu:
      type: nvidia-l4
      count: 1

Flex-Start-Bereitstellungsmodus mit Knoten-Recycling-Konfiguration

Diese Konfiguration verwaltet kurzfristige, rabattierte Kapazität mit kontinuierlicher Verfügbarkeit. Dazu werden die folgenden Schritte ausgeführt:

  1. Flex-Start-VMs anfordern:GKE fordert VM-Instanzen aus der Flex-Start-Warteschlange an (die bis zu sieben Tage lang ohne Unterbrechung ausgeführt werden).
  2. Ablauf der Lease beobachten:GKE verfolgt die verbleibende Dauer der aktiven Flex-Start-Knoten.
  3. Knoten-Recycling auslösen:Zwanzig Minuten (1.200 Sekunden) vor Ablauf der VM-Lease stellt GKE automatisch einen Ersatzknoten bereit.

  4. Arbeitslasten neu planen:Arbeitslasten werden auf den neuen Knoten migriert und die Ausführung wird ohne Dienstunterbrechung fortgesetzt.

    apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: flex-node-recycling
spec:
  priorities:
  - gpu:
      type: nvidia-l4
      count: 1
    flexStart:
      enabled: true
      nodeRecycling:
        leadTimeSeconds: 1200 # Automatically launch replacement node before VM lease expires

Konfiguration der multizonalen Zuweisungsrichtlinie

Diese Konfiguration umgeht Einschränkungen bei der Bereitstellung in einer einzelnen Zone. Dazu werden die folgenden Schritte ausgeführt:

  1. Zielzonen definieren:Sie listen in den Prioritätsregeln mehrere Backupzonen auf, z. B. us-central1-a, us-central1-b und us-central1-c.
  2. Zielparameter erweitern:Sie setzen die Standortrichtlinie auf ANY. Diese Einstellung weist Cluster Autoscaler an, in allen angegebenen Zonen nach der angeforderten Kapazität zu suchen.
  3. Zonale Verfügbarkeit analysieren:Bei Scale-up-Ereignissen scannt GKE die angegebenen Zonen.

  4. In verfügbaren Zonen bereitstellen:GKE stellt die angeforderten Arbeitslastknoten sofort in der Zielzone bereit, die über die passende Kapazität verfügt. Diese Strategie verhindert Blockierungen in Zuweisungswarteschlangen.

    apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: broad-zonal-serving
spec:
  priorities:
  - gpu:
      type: nvidia-l4
      count: 1
    location:
      zones: [us-central1-a, us-central1-b, us-central1-c]
      locationPolicy: ANY # Provision accelerator in any target zone with supply

Nächste Schritte