KI-optimierten GKE-Cluster mit Standardkonfiguration erstellen

Auf dieser Seite erfahren Sie, wie Sie einen eigenen KI-optimierten Google Kubernetes Engine-Cluster (GKE) erstellen, in dem virtuelle Maschinen (VMs) vom Typ A4X, A4, A3 Ultra, A3 Mega und A3 High (8 GPUs) verwendet werden, um Ihre KI- und ML-Arbeitslasten zu unterstützen.

Die Maschinenserien A4X, A4, A3 Ultra, A3 Mega und A3 High (8 GPUs) wurden entwickelt, damit Sie KI/ML-Cluster im großen Maßstab mit Funktionen wie gezielter Arbeitslastplatzierung, erweiterten Clusterwartungssteuerungen und Topology Aware Scheduling ausführen können. Weitere Informationen finden Sie unter Clusterverwaltung – Übersicht.

GKE bietet eine einheitliche Plattform, auf der Sie eine Vielzahl von Arbeitslasten für die Anforderungen Ihres Unternehmens ausführen können. Dazu gehören leistungsstarkes verteiltes Vortraining, Modellabstimmung, Modellinferenz, Anwendungsbereitstellung und unterstützende Dienste. GKE reduziert den Betriebsaufwand für die Verwaltung mehrerer Plattformen.

Auswählen, wie ein KI-optimierter GKE-Cluster erstellt werden soll

Die folgenden Optionen zum Erstellen von Clustern bieten jeweils unterschiedliche Grade an Benutzerfreundlichkeit und Flexibilität bei der Clusterkonfiguration und der Planung von Arbeitslasten:

Hinweise

Führen Sie die folgenden Aufgaben aus, bevor Sie beginnen:

  • Aktivieren Sie die Google Kubernetes Engine API.
    • Google Kubernetes Engine API aktivieren
  • Wenn Sie die Google Cloud CLI für diesen Task verwenden möchten, müssen Sie die gcloud CLI installieren und dann initialisieren. Wenn Sie die gcloud CLI bereits installiert haben, rufen Sie die neueste Version mit dem Befehl gcloud components update ab. In früheren gcloud CLI-Versionen werden die Befehle in diesem Dokument möglicherweise nicht unterstützt.
  • Prüfen Sie, ob Sie die erforderlichen Berechtigungen zum Erstellen und Verwalten des GKE-Cluster und der zugehörigen Dienstkonten haben:
    • Kubernetes Engine-Administrator roles/container.admin
    • Compute-Administrator (roles/compute.admin)
    • Storage-Administrator (roles/storage.admin)
    • Projekt-IAM-Administrator (roles/resourcemanager.projectIamAdmin)
    • Dienstkontoadministrator (roles/iam.serviceAccountAdmin)
    • Dienstkontonutzer (roles/iam.serviceAccountUser)
    • Service Usage Consumer (roles/serviceusage.serviceUsageConsumer)
    • Rollenadministrator (roles/iam.roleAdmin)
    • Verwalter von Secret Manager-Secret-Versionen (roles/secretmanager.secretVersionManager)

Nutzungsoption auswählen und Kapazität erhalten

  1. Wählen Sie eine Option für die Nutzung aus. Treffen Sie Ihre Auswahl basierend darauf, wie Sie GPU-Ressourcen erhalten und verwenden möchten. Weitere Informationen

    Berücksichtigen Sie für GKE die folgenden zusätzlichen Informationen, wenn Sie eine Nutzungsoption auswählen:

  2. Kapazität erhalten: Das Verfahren zum Erhalten von Kapazität unterscheidet sich je nach Verbrauchsoption.

    Informationen zum Prozess für die von Ihnen ausgewählte Verbrauchsoption finden Sie unter Kapazitätsübersicht.

Voraussetzungen

Für einen KI-optimierten GKE-Cluster gelten die folgenden Anforderungen:

  • Für A4X müssen Sie für Version 1.33 oder höher die GKE-Version 1.33.4-gke.1036000 oder höher verwenden. Oder verwenden Sie für 1.32 die GKE-Version 1.32.8-gke.1108000 oder höher. Mit diesen Versionen wird sichergestellt, dass A4X Folgendes verwendet:

    • R580, die Mindest-GPU-Treiberversion für A4X.
    • Coherent Driver-based Memory Management (CDMM), das standardmäßig aktiviert ist. NVIDIA empfiehlt, diesen Modus in Kubernetes-Clustern zu aktivieren, um zu hohe Arbeitsspeicherangaben zu vermeiden. Mit CDMM kann der GPU-Speicher über den Treiber anstelle des Betriebssystems verwaltet werden. So wird vermieden, dass das Betriebssystem den GPU-Arbeitsspeicher online schaltet, und der GPU-Arbeitsspeicher wird dem Betriebssystem als NUMA-Knoten (Non-Uniform Memory Access) zur Verfügung gestellt. GPUs mit mehreren Instanzen werden nicht unterstützt, wenn CDMM aktiviert ist. Weitere Informationen zu CDMM finden Sie unter Hardware- und Software-Support.
    • GPUDirect RDMA, das empfohlen wird, damit A4X-Knotenpools die Netzwerkfunktionen von A4X nutzen können.

  • Achten Sie darauf, dass Sie die Mindestversion des GPU-Treibers verwenden, die vom Maschinentyp abhängt:

    • A4X: Für die GB200-GPUs in A4X-VMs ist mindestens die R580-GPU-Treiberversion erforderlich. Siehe die oben genannten Versionsanforderungen.
    • A4: Für die B200-GPUs in A4-VMs ist mindestens die R570-Version des GPU-Treibers erforderlich. In GKE wird diese Treiberversion standardmäßig automatisch auf allen A4-Knoten installiert, auf denen die erforderliche Mindestversion für A4, 1.32.1-gke.1729000 oder höher, ausgeführt wird.
    • A3 Ultra: Für die H200-GPUs in A3 Ultra-VMs ist mindestens die GPU-Treiberversion R550 erforderlich, die in GKE 1.31 als latest-Treiberversion verfügbar ist. Für A3 Ultra müssen Sie gpu-driver-version=latest mit GKE 1.31 festlegen. In GKE-Version 1.31.5-gke.1169000 oder höher installiert GKE standardmäßig automatisch R550-GPU-Treiberversionen auf A3 Ultra-Knoten.

  • Bei A3-Ultra-Knotenpools müssen Sie den Laufwerkstyp auf hyperdisk-balanced festlegen.

  • Wenn Sie GPUDirect RDMA verwenden möchten, benötigen Sie je nach Maschinentyp die folgenden Mindestversionen:

    • A4X: Siehe die oben genannten Versionsanforderungen.
    • A4: Verwenden Sie 1.32.2-gke.1475000 oder höher.
    • A3 Ultra: Verwenden Sie 1.31.4-gke.1183000 oder höher.

  • Wenn Sie GPUDirect RDMA verwenden möchten, müssen die GKE-Knoten ein Knoten-Image für Container-Optimized OS verwenden. Ubuntu- und Windows-Knoten-Images werden nicht unterstützt.

  • Sie müssen das Bereitstellungsmodell reservierungsgebunden verwenden, um Cluster mit A4X zu erstellen. Andere Bereitstellungsmodelle werden nicht unterstützt.

Cluster erstellen

Mit der folgenden Anleitung erstellen Sie einen Cluster entweder mit dem Cluster Toolkit oder mit XPK.

Cluster mit dem Cluster Toolkit erstellen

In diesem Abschnitt wird beschrieben, wie Sie einen Cluster erstellen, der den Anforderungen für einen KI-optimierten GKE-Cluster entspricht und Best Practices für Ihr Projekt befolgt.

A4X

  1. Cloud Shell starten Sie können eine andere Umgebung verwenden. Wir empfehlen jedoch Cloud Shell, da die Abhängigkeiten für Cluster Toolkit bereits vorinstalliert sind. Wenn Sie Cloud Shell nicht verwenden möchten, folgen Sie der Anleitung zum Installieren von Abhängigkeiten, um eine andere Umgebung vorzubereiten.

  2. Klonen Sie das Cluster-Toolkit aus dem Git-Repository:

    cd ~
git clone https://github.com/GoogleCloudPlatform/cluster-toolkit.git

  3. Cluster Toolkit installieren:

    cd cluster-toolkit && git checkout main && make

  4. Erstellen Sie einen Cloud Storage-Bucket zum Speichern des Status der Terraform-Bereitstellung:

    gcloud storage buckets create gs://BUCKET_NAME \
    --default-storage-class=STANDARD \
    --project=PROJECT_ID \
    --location=COMPUTE_REGION_TERRAFORM_STATE \
    --uniform-bucket-level-access
gcloud storage buckets update gs://BUCKET_NAME --versioning

    Ersetzen Sie die folgenden Variablen:

    • BUCKET_NAME: Der Name des neuen Cloud Storage-Bucket.
    • PROJECT_ID: Projekt-ID in Google Cloud .
    • COMPUTE_REGION_TERRAFORM_STATE: die Computing-Region, in der Sie den Zustand der Terraform-Bereitstellung speichern möchten.

  5. Füllen Sie im examples/gke-a4x/gke-a4x-deployment.yaml-Blueprint aus dem GitHub-Repository die folgenden Einstellungen in den Abschnitten terraform_backend_defaults und vars entsprechend den spezifischen Werten für Ihre Bereitstellung aus:

    • DEPLOYMENT_NAME: ein eindeutiger Name für die Bereitstellung, der zwischen 6 und 30 Zeichen lang sein muss. Wenn der Bereitstellungsname innerhalb eines Projekts nicht eindeutig ist, schlägt die Clustererstellung fehl. Der Standardwert ist gke-a4x.
    • BUCKET_NAME: der Name des Cloud Storage-Bucket, den Sie im vorherigen Schritt erstellt haben.
    • PROJECT_ID: Projekt-ID in Google Cloud .
    • COMPUTE_REGION: die Compute-Region für den Cluster.
    • COMPUTE_ZONE: Die Compute Engine-Zone für den Knotenpool mit A4X-Maschinen. Diese Zone sollte mit der Zone übereinstimmen, in der Maschinen in Ihrer Reservierung verfügbar sind.
    • NODE_COUNT: Die Anzahl der A4X-Knoten im Knotenpool Ihres Clusters. Diese muss 18 Knoten oder weniger betragen. Wir empfehlen, 18 Knoten zu verwenden, um die GPU-Topologie von 1x72 in einem Unterblock mit einer NVLink-Domäne zu erhalten.
    • IP_ADDRESS/SUFFIX: Der IP-Adressbereich, der eine Verbindung mit dem Cluster herstellen darf. Dieser CIDR-Block muss die IP-Adresse des Computers enthalten, den Sie zum Aufrufen von Terraform verwenden möchten. Weitere Informationen finden Sie unter Funktionsweise autorisierter Netzwerke.

    • Verwenden Sie für das Feld extended_reservation einen der folgenden Werte, je nachdem, ob Sie beim Bereitstellen des Knotenpools auf bestimmte Blöcke in einer Reservierung abzielen möchten:

      • Wenn Sie den Knotenpool an einer beliebigen Stelle in der Reservierung platzieren möchten, geben Sie den Namen Ihrer Reservierung (RESERVATION_NAME) an.

      • Wenn Sie einen bestimmten Block in Ihrer Reservierung ansprechen möchten, verwenden Sie die Reservierungs- und Blocknamen im folgenden Format:

        RESERVATION_NAME/reservationBlocks/BLOCK_NAME

      Wenn Sie nicht wissen, welche Blöcke in Ihrer Reservierung verfügbar sind, lesen Sie den Abschnitt Reservierungstopologie ansehen.

    • Legen Sie die Größen der Bootlaufwerke für jeden Knoten des Systems und die A4X-Knotenpools fest. Die benötigte Festplattengröße hängt von Ihrem Anwendungsfall ab. Wenn Sie das Laufwerk beispielsweise als Cache verwenden, um die Latenz beim wiederholten Abrufen eines Images zu verringern, können Sie eine größere Laufwerkgröße festlegen, um Ihr Framework, Modell oder Container-Image aufzunehmen:

      • SYSTEM_NODE_POOL_DISK_SIZE_GB: Die Größe des Bootlaufwerks für jeden Knoten des Systemknotenpools. Die kleinste zulässige Festplattengröße ist 10. Der Standardwert ist 200.
      • A4X_NODE_POOL_DISK_SIZE_GB: Die Größe des Bootlaufwerks für jeden Knoten des A4X-Knotenpools. Die kleinste zulässige Festplattengröße ist 10. Der Standardwert ist 100.

    Wenn Sie die erweiterten Einstellungen ändern möchten, bearbeiten Sie die Datei examples/gke-a4x/gke-a4x.yaml.

  6. Optional können Sie Cluster Health Scanner (CHS) für den Cluster aktivieren. CHS prüft den Zustand Ihrer GPU-Cluster, indem Tests ausgeführt werden, um zu prüfen, ob die Cluster bereit sind, Ihre Arbeitslasten auszuführen. Um CHS zu aktivieren, nehmen Sie die folgenden Änderungen in der Datei examples/gke-a4x/gke-a4x-deployment.yaml vor:

    • Legen Sie im Block vars das Feld enable_periodic_health_checks auf true fest.

    • Standardmäßig werden die Healthchecks jeden Sonntag um 00:00 Uhr PST ausgeführt. Wenn Sie diese Einstellung ändern möchten, legen Sie im Block vars das Feld health_check_schedule auf einen geeigneten Wert im Cron-Format fest.
      Zeitplan im Cron-Format: none * * * * * # | | | | | # | | | | day of the week (0-6) (Sunday to Saturday) # | | | month (1-12) # | | day of the month (1-31) # | hour (0-23) # minute (0-59)

  7. Generieren Sie Standardanmeldedaten für Anwendungen (Application Default Credentials, ADC), um Zugriff auf Terraform zu gewähren. Wenn Sie Cloud Shell verwenden, können Sie den folgenden Befehl ausführen:

    gcloud auth application-default login

  8. Stellen Sie den Blueprint bereit, um die GKE-Infrastruktur mit A4X-Maschinentypen bereitzustellen:

    cd ~/cluster-toolkit
./gcluster deploy -d \
examples/gke-a4x/gke-a4x-deployment.yaml \
examples/gke-a4x/gke-a4x.yaml

  9. Wählen Sie bei entsprechender Aufforderung Anwenden aus, um das Blueprint bereitzustellen.

    • Mit dem Blueprint werden VPC-Netzwerke, ein GPU-RDMA-VPC-Netzwerk, Dienstkonten, ein Cluster und ein Knotenpool erstellt.
    • Zur Unterstützung der Jobvorlage fio-bench-job-template im Blueprint werdenGoogle Cloud -Buckets, Netzwerkspeicher und Ressourcen für persistente Volumes erstellt.

A4

  1. Cloud Shell starten Sie können eine andere Umgebung verwenden. Wir empfehlen jedoch Cloud Shell, da die Abhängigkeiten für Cluster Toolkit bereits vorinstalliert sind. Wenn Sie Cloud Shell nicht verwenden möchten, folgen Sie der Anleitung zum Installieren von Abhängigkeiten, um eine andere Umgebung vorzubereiten.

  2. Klonen Sie das Cluster-Toolkit aus dem Git-Repository:

    cd ~
git clone https://github.com/GoogleCloudPlatform/cluster-toolkit.git

  3. Cluster Toolkit installieren:

    cd cluster-toolkit && git checkout main && make

  4. Erstellen Sie einen Cloud Storage-Bucket zum Speichern des Status der Terraform-Bereitstellung:

    gcloud storage buckets create gs://BUCKET_NAME \
    --default-storage-class=STANDARD \
    --project=PROJECT_ID \
    --location=COMPUTE_REGION_TERRAFORM_STATE \
    --uniform-bucket-level-access
gcloud storage buckets update gs://BUCKET_NAME --versioning

    Ersetzen Sie die folgenden Variablen:

    • BUCKET_NAME: Der Name des neuen Cloud Storage-Bucket.
    • PROJECT_ID: Projekt-ID in Google Cloud .
    • COMPUTE_REGION_TERRAFORM_STATE: die Computing-Region, in der Sie den Zustand der Terraform-Bereitstellung speichern möchten.

  5. Welche Dateien Sie zum Erstellen eines Clusters bearbeiten müssen, hängt von der Verbrauchsoption ab, die Sie für Ihre Bereitstellung verwenden. Wählen Sie den Tab aus, der dem Bereitstellungsmodell Ihrer Verbrauchsoption entspricht.

    Reservierungsgebunden

    Füllen Sie im examples/gke-a4/gke-a4-deployment.yaml-Blueprint aus dem GitHub-Repository die folgenden Einstellungen in den Abschnitten terraform_backend_defaults und vars entsprechend den spezifischen Werten für Ihre Bereitstellung aus:

    • DEPLOYMENT_NAME: ein eindeutiger Name für die Bereitstellung, der zwischen 6 und 30 Zeichen lang sein muss. Wenn der Bereitstellungsname innerhalb eines Projekts nicht eindeutig ist, schlägt die Clustererstellung fehl. Der Standardwert ist gke-a4.
    • BUCKET_NAME: der Name des Cloud Storage-Bucket, den Sie im vorherigen Schritt erstellt haben.
    • PROJECT_ID: Projekt-ID in Google Cloud .
    • COMPUTE_REGION: die Compute-Region für den Cluster.
    • COMPUTE_ZONE: Die Computing-Zone für den Knotenpool von A4-Maschinen. Diese Zone muss mit der Zone übereinstimmen, in der Maschinen in Ihrer Reservierung verfügbar sind.
    • NODE_COUNT: Die Anzahl der A4-Knoten in Ihrem Cluster.
    • IP_ADDRESS/SUFFIX: Der IP-Adressbereich, der eine Verbindung mit dem Cluster herstellen darf. Dieser CIDR-Block muss die IP-Adresse des Computers enthalten, den Sie zum Aufrufen von Terraform verwenden möchten. Weitere Informationen finden Sie unter Funktionsweise autorisierter Netzwerke.

    • Verwenden Sie für das Feld reservation einen der folgenden Werte, je nachdem, ob Sie beim Bereitstellen des Knotenpools auf bestimmte Blöcke in einer Reservierung abzielen möchten:

      • Wenn Sie den Knotenpool an einer beliebigen Stelle in der Reservierung platzieren möchten, geben Sie den Namen Ihrer Reservierung (RESERVATION_NAME) an.

      • Wenn Sie einen bestimmten Block in Ihrer Reservierung ansprechen möchten, verwenden Sie die Reservierungs- und Blocknamen im folgenden Format:

        RESERVATION_NAME/reservationBlocks/BLOCK_NAME

      Wenn Sie nicht wissen, welche Blöcke in Ihrer Reservierung verfügbar sind, lesen Sie den Abschnitt Reservierungstopologie ansehen.

    • Legen Sie die Größen der Bootlaufwerke für jeden Knoten des Systems und die A4-Knotenpools fest. Die benötigte Festplattengröße hängt von Ihrem Anwendungsfall ab. Wenn Sie das Laufwerk beispielsweise als Cache verwenden, um die Latenz beim wiederholten Abrufen eines Images zu verringern, können Sie eine größere Laufwerkgröße festlegen, um Ihr Framework, Modell oder Container-Image aufzunehmen:

      • SYSTEM_NODE_POOL_DISK_SIZE_GB: Die Größe des Bootlaufwerks für jeden Knoten des Systemknotenpools. Die kleinste zulässige Festplattengröße ist 10. Der Standardwert ist 100.
      • A4_NODE_POOL_DISK_SIZE_GB: Die Größe des Bootlaufwerks für jeden Knoten des A4-Knotenpools. Die kleinste zulässige Festplattengröße ist 10. Der Standardwert ist 100.

    Wenn Sie die erweiterten Einstellungen ändern möchten, bearbeiten Sie examples/gke-a4/gke-a4.yaml.

    Flex-Start

    1. Füllen Sie im examples/gke-a4/gke-a4-deployment.yaml-Blueprint aus dem GitHub-Repository die folgenden Einstellungen in den Abschnitten terraform_backend_defaults und vars entsprechend den spezifischen Werten für Ihre Bereitstellung aus:

      • DEPLOYMENT_NAME: ein eindeutiger Name für die Bereitstellung, der zwischen 6 und 30 Zeichen lang sein muss. Wenn der Bereitstellungsname innerhalb eines Projekts nicht eindeutig ist, schlägt die Clustererstellung fehl. Der Standardwert ist gke-a4.
      • BUCKET_NAME: der Name des Cloud Storage-Bucket, den Sie im vorherigen Schritt erstellt haben.
      • PROJECT_ID: Projekt-ID in Google Cloud .
      • COMPUTE_REGION: die Compute-Region für den Cluster.
      • COMPUTE_ZONE: Die Computing-Zone für den Knotenpool von A4-Maschinen.
      • static_node_count entfernen.
      • IP_ADDRESS/SUFFIX: Der IP-Adressbereich, der eine Verbindung mit dem Cluster herstellen darf. Dieser CIDR-Block muss die IP-Adresse des Computers enthalten, den Sie zum Aufrufen von Terraform verwenden möchten. Weitere Informationen finden Sie unter Funktionsweise autorisierter Netzwerke.
      • Entfernen Sie das Feld reservation und ersetzen Sie es durch enable_flex_start: true. Fügen Sie in der nächsten Zeile enable_queued_provisioning: true hinzu, wenn Sie auch die Bereitstellung in der Warteschlange verwenden möchten. Weitere Informationen finden Sie unter Knotenpools mit Flex-Start und in die Warteschlange gestellter Bereitstellung verwenden.

      • Legen Sie die Größen der Bootlaufwerke für jeden Knoten des Systems und die A4-Knotenpools fest. Die benötigte Festplattengröße hängt von Ihrem Anwendungsfall ab. Wenn Sie das Laufwerk beispielsweise als Cache verwenden, um die Latenz beim wiederholten Abrufen eines Images zu verringern, können Sie eine größere Laufwerkgröße festlegen, um Ihr Framework, Modell oder Container-Image aufzunehmen:

        • SYSTEM_NODE_POOL_DISK_SIZE_GB: Die Größe des Bootlaufwerks für jeden Knoten des Systemknotenpools. Die kleinste zulässige Festplattengröße ist 10. Der Standardwert ist 100.
        • A4_NODE_POOL_DISK_SIZE_GB: Die Größe des Bootlaufwerks für jeden Knoten des A4-Knotenpools. Die kleinste zulässige Festplattengröße ist 10. Der Standardwert ist 100.

    2. Nehmen Sie im examples/gke-a4/gke-a4.yaml-Blueprint aus dem GitHub-Repository die folgenden Änderungen vor:

      • Entfernen Sie im Block vars den Wert static_node_count.
      • Prüfen Sie im Block vars, ob die version_prefix-Nummer "1.32." oder höher ist. Wenn Sie Flex-Start in GKE verwenden möchten, muss Ihr Cluster die Version 1.32.2-gke.1652000 oder höher verwenden.
      • Ersetzen Sie im vars-Block den gesamten reservation-Block (einschließlich der reservation-Zeile) durch enable_flex_start: true und optional enable_queued_provisioning: true.
      • Wenn Sie die Bereitstellung in der Warteschlange nicht benötigen, entfernen Sie im Block vars die folgende Zeile: kueue_configuration_path: $(ghpc_stage("./kueue-configuration.yaml.tftpl")).
      • Entfernen Sie unter id: a4-pool die folgende Zeile: static_node_count: $(vars.static_node_count).

      • Entfernen Sie unter id: a4-pool den Block reservation_affinity. Ersetzen Sie diesen Block durch die folgenden Zeilen:

        • enable_flex_start: $(vars.enable_flex_start)
        • auto_repair: false
        • Wenn Sie die Bereitstellung in der Warteschlange aktivieren möchten, fügen Sie die folgenden zusätzlichen Zeilen hinzu:
          • enable_queued_provisioning: $(vars.enable_queued_provisioning)
          • autoscaling_total_min_nodes: 0

      • Entfernen Sie unter id: workload-manager-install den folgenden Block:

         kueue:
    install: true
    config_path: $(vars.kueue_configuration_path)
    config_template_vars:
       num_gpus: $(a3-ultragpu-pool.static_gpu_count)
       accelerator_type: $(vars.accelerator_type)

        • Gehen Sie für den Flex-Start mit Bereitstellung per Warteschlange folgendermaßen vor:

          1. Fügen Sie dem vars-Block gpu_nominal_quota: NOMINAL_QUOTA hinzu. Der Wert gpu_nominal_quota wird verwendet, um nominalQuota der GPUs in der ClusterQueue-Spezifikation festzulegen (siehe Schritt zum Festlegen von ClusterQueue unten). In diesem Beispiel lässt ClusterQueue nur Arbeitslasten zu, wenn die Summe der GPU-Anfragen kleiner oder gleich dem Wert NOMINAL_QUOTA ist. Weitere Informationen zu ClusterQueue finden Sie im folgenden Kueue-Dokument zur Clusterwarteschlange.

          2. Aktualisieren Sie den Block kueue so:

            kueue:
   install: true
   config_path: $(vars.kueue_configuration_path)
   config_template_vars:
      num_gpus: $(vars.gpu_nominal_quota)

          3. Ersetzen Sie den Inhalt der Datei kueue-configuration.yaml.tftpl durch Folgendes:

            apiVersion: kueue.x-k8s.io/v1beta1
kind: ResourceFlavor
metadata:
   name: "default-flavor"
---
apiVersion: kueue.x-k8s.io/v1beta1
kind: AdmissionCheck
metadata:
   name: dws-prov
spec:
   controllerName: kueue.x-k8s.io/provisioning-request
   parameters:
      apiGroup: kueue.x-k8s.io
      kind: ProvisioningRequestConfig
      name: dws-config
---
apiVersion: kueue.x-k8s.io/v1beta1
kind: ProvisioningRequestConfig
metadata:
   name: dws-config
spec:
   provisioningClassName: queued-provisioning.gke.io
   managedResources:
   - nvidia.com/gpu
---
apiVersion: kueue.x-k8s.io/v1beta1
kind: ClusterQueue
metadata:
   name: "dws-cluster-queue"
spec:
   namespaceSelector: {}
   resourceGroups:
   - coveredResources: ["nvidia.com/gpu"]
      flavors:
      - name: "default-flavor"
      resources:
      - name: "nvidia.com/gpu"
         nominalQuota: ${num_gpus}
   admissionChecks:
   - dws-prov
---
apiVersion: kueue.x-k8s.io/v1beta1
kind: LocalQueue
metadata:
   namespace: "default"
   name: "dws-local-queue"
spec:
   clusterQueue: "dws-cluster-queue"
---

      • Ersetzen Sie unter id: job-template die Variable node_count durch 2.

    Spot

    1. Füllen Sie im examples/gke-a4/gke-a4-deployment.yaml-Blueprint aus dem GitHub-Repository die folgenden Einstellungen in den Abschnitten terraform_backend_defaults und vars entsprechend den spezifischen Werten für Ihre Bereitstellung aus:

      • DEPLOYMENT_NAME: ein eindeutiger Name für die Bereitstellung, der zwischen 6 und 30 Zeichen lang sein muss. Wenn der Bereitstellungsname innerhalb eines Projekts nicht eindeutig ist, schlägt die Clustererstellung fehl. Der Standardwert ist gke-a4.
      • BUCKET_NAME: der Name des Cloud Storage-Bucket, den Sie im vorherigen Schritt erstellt haben.
      • PROJECT_ID: Projekt-ID in Google Cloud .
      • COMPUTE_REGION: die Compute-Region für den Cluster.
      • COMPUTE_ZONE: Die Computing-Zone für den Knotenpool von A4-Maschinen.
      • STATIC_NODE_COUNT: Die Anzahl der A4-Knoten in Ihrem Cluster.
      • IP_ADDRESS/SUFFIX: Der IP-Adressbereich, der eine Verbindung mit dem Cluster herstellen darf. Dieser CIDR-Block muss die IP-Adresse des Computers enthalten, den Sie zum Aufrufen von Terraform verwenden möchten. Weitere Informationen finden Sie unter Funktionsweise autorisierter Netzwerke.
      • Ersetzen Sie den gesamten reservation-Block (einschließlich der reservation-Zeile selbst) durch spot: true.

      • Legen Sie die Größen der Bootlaufwerke für jeden Knoten des Systems und die A4-Knotenpools fest. Die benötigte Festplattengröße hängt von Ihrem Anwendungsfall ab. Wenn Sie das Laufwerk beispielsweise als Cache verwenden, um die Latenz beim wiederholten Abrufen eines Images zu verringern, können Sie eine größere Laufwerkgröße festlegen, um Ihr Framework, Modell oder Container-Image aufzunehmen:

        • SYSTEM_NODE_POOL_DISK_SIZE_GB: Die Größe des Bootlaufwerks für jeden Knoten des Systemknotenpools. Die kleinste zulässige Festplattengröße ist 10. Der Standardwert ist 100.
        • A4_NODE_POOL_DISK_SIZE_GB: Die Größe des Bootlaufwerks für jeden Knoten des A4-Knotenpools. Die kleinste zulässige Festplattengröße ist 10. Der Standardwert ist 100.

    2. Nehmen Sie im examples/gke-a4/gke-a4.yaml-Blueprint aus dem GitHub-Repository die folgenden Änderungen vor:

      • Ersetzen Sie im vars-Block den gesamten reservation-Block (einschließlich der Zeile reservation selbst) durch spot: true.

      • Entfernen Sie unter id: a4-pool den Block reservation_affinity. Ersetzen Sie diesen Block durch die folgende Zeile:

        • spot: $(vars.spot)

  6. Optional können Sie Cluster Health Scanner (CHS) für den Cluster aktivieren. CHS prüft den Zustand Ihrer GPU-Cluster, indem Tests ausgeführt werden, um zu prüfen, ob die Cluster bereit sind, Ihre Arbeitslasten auszuführen. Um CHS zu aktivieren, nehmen Sie die folgenden Änderungen in der Datei examples/gke-a4/gke-a4-deployment.yaml vor:

    • Legen Sie im Block vars das Feld enable_periodic_health_checks auf true fest.

    • Standardmäßig werden die Healthchecks jeden Sonntag um 00:00 Uhr PST ausgeführt. Wenn Sie diese Einstellung ändern möchten, legen Sie im Block vars das Feld health_check_schedule auf einen geeigneten Wert im Cron-Format fest.
      Zeitplan im Cron-Format: none * * * * * # | | | | | # | | | | day of the week (0-6) (Sunday to Saturday) # | | | month (1-12) # | | day of the month (1-31) # | hour (0-23) # minute (0-59)

  7. Generieren Sie Standardanmeldedaten für Anwendungen (Application Default Credentials, ADC), um Zugriff auf Terraform zu gewähren. Wenn Sie Cloud Shell verwenden, können Sie den folgenden Befehl ausführen:

    gcloud auth application-default login

  8. Stellen Sie den Blueprint bereit, um die GKE-Infrastruktur mit A4-Maschinentypen bereitzustellen:

    cd ~/cluster-toolkit
./gcluster deploy -d \
examples/gke-a4/gke-a4-deployment.yaml \
examples/gke-a4/gke-a4.yaml

  9. Wählen Sie bei entsprechender Aufforderung Anwenden aus, um das Blueprint bereitzustellen.

    • Mit dem Blueprint werden VPC-Netzwerke, ein GPU-RDMA-VPC-Netzwerk, Dienstkonten, ein Cluster und ein Knotenpool erstellt.
    • Zur Unterstützung der Jobvorlage fio-bench-job-template im Blueprint werdenGoogle Cloud -Buckets, Netzwerkspeicher und Ressourcen für persistente Volumes erstellt.

A3 Ultra

  1. Cloud Shell starten Sie können eine andere Umgebung verwenden. Wir empfehlen jedoch Cloud Shell, da die Abhängigkeiten für Cluster Toolkit bereits vorinstalliert sind. Wenn Sie Cloud Shell nicht verwenden möchten, folgen Sie der Anleitung zum Installieren von Abhängigkeiten, um eine andere Umgebung vorzubereiten.

  2. Klonen Sie das Cluster-Toolkit aus dem Git-Repository:

    cd ~
git clone https://github.com/GoogleCloudPlatform/cluster-toolkit.git

  3. Cluster Toolkit installieren:

    cd cluster-toolkit && git checkout main && make

  4. Erstellen Sie einen Cloud Storage-Bucket zum Speichern des Status der Terraform-Bereitstellung:

    gcloud storage buckets create gs://BUCKET_NAME \
    --default-storage-class=STANDARD \
    --project=PROJECT_ID \
    --location=COMPUTE_REGION_TERRAFORM_STATE \
    --uniform-bucket-level-access
gcloud storage buckets update gs://BUCKET_NAME --versioning

    Ersetzen Sie die folgenden Variablen:

    • BUCKET_NAME: Der Name des neuen Cloud Storage-Bucket.
    • PROJECT_ID: Projekt-ID in Google Cloud .
    • COMPUTE_REGION_TERRAFORM_STATE: die Computing-Region, in der Sie den Zustand der Terraform-Bereitstellung speichern möchten.

  5. Welche Dateien Sie zum Erstellen eines Clusters bearbeiten müssen, hängt von der Verbrauchsoption ab, die Sie für Ihre Bereitstellung verwenden. Wählen Sie den Tab aus, der dem Bereitstellungsmodell Ihrer Verbrauchsoption entspricht.

    Reservierungsgebunden

    Ersetzen Sie im examples/gke-a3-ultragpu/gke-a3-ultragpu-deployment.yaml-Blueprint aus dem GitHub-Repository die folgenden Variablen in den Abschnitten terraform_backend_defaults und vars durch die spezifischen Werte für Ihre Bereitstellung:

    • DEPLOYMENT_NAME: ein eindeutiger Name für die Bereitstellung, der zwischen 6 und 30 Zeichen lang sein muss. Wenn der Bereitstellungsname innerhalb eines Projekts nicht eindeutig ist, schlägt die Clustererstellung fehl.
    • BUCKET_NAME: der Name des Cloud Storage-Bucket, den Sie im vorherigen Schritt erstellt haben.
    • PROJECT_ID: Projekt-ID in Google Cloud .
    • COMPUTE_REGION: die Compute-Region für den Cluster.
    • COMPUTE_ZONE: Die Computing-Zone für den Knotenpool mit A3-Ultra-Maschinen. Diese Zone sollte mit der Zone übereinstimmen, in der Maschinen in Ihrer Reservierung verfügbar sind.
    • NODE_COUNT: die Anzahl der A3 Ultra-Knoten in Ihrem Cluster.
    • IP_ADDRESS/SUFFIX: Der IP-Adressbereich, der eine Verbindung mit dem Cluster herstellen darf. Dieser CIDR-Block muss die IP-Adresse des Computers enthalten, den Sie zum Aufrufen von Terraform verwenden möchten. Weitere Informationen finden Sie unter Funktionsweise autorisierter Netzwerke.

    • Verwenden Sie für das Feld reservation einen der folgenden Werte, je nachdem, ob Sie beim Bereitstellen des Knotenpools auf bestimmte Blöcke in einer Reservierung abzielen möchten:

      • Wenn Sie den Knotenpool an einer beliebigen Stelle in der Reservierung platzieren möchten, geben Sie den Namen Ihrer Reservierung (RESERVATION_NAME) an.

      • Wenn Sie einen bestimmten Block in Ihrer Reservierung ansprechen möchten, verwenden Sie die Reservierungs- und Blocknamen im folgenden Format:

        RESERVATION_NAME/reservationBlocks/BLOCK_NAME

      Wenn Sie nicht wissen, welche Blöcke in Ihrer Reservierung verfügbar sind, lesen Sie den Abschnitt Reservierungstopologie ansehen.

    • Legen Sie die Größen der Bootlaufwerke für jeden Knoten des Systems und der A3 Ultra-Knotenpools fest. Die benötigte Festplattengröße hängt von Ihrem Anwendungsfall ab. Wenn Sie das Laufwerk beispielsweise als Cache verwenden, um die Latenz beim wiederholten Abrufen eines Images zu verringern, können Sie eine größere Laufwerkgröße festlegen, um Ihr Framework, Modell oder Container-Image aufzunehmen:

      • SYSTEM_NODE_POOL_DISK_SIZE_GB: Die Größe des Bootlaufwerks für jeden Knoten des Systemknotenpools. Die kleinste zulässige Festplattengröße ist 10. Der Standardwert ist 100.
      • A3ULTRA_NODE_POOL_DISK_SIZE_GB: Die Größe des Bootlaufwerks für jeden Knoten des A3 Ultra-Knotenpools. Die kleinste zulässige Festplattengröße ist 10. Der Standardwert ist 100.

    Wenn Sie die erweiterten Einstellungen ändern möchten, bearbeiten Sie examples/gke-a3-ultragpu/gke-a3-ultragpu.yaml.

    Flex-Start

    1. Ersetzen Sie im examples/gke-a3-ultragpu/gke-a3-ultragpu-deployment.yaml-Blueprint aus dem GitHub-Repository die folgenden Variablen in den Abschnitten terraform_backend_defaults und vars durch die spezifischen Werte für Ihre Bereitstellung:

      • DEPLOYMENT_NAME: ein eindeutiger Name für die Bereitstellung, der zwischen 6 und 30 Zeichen lang sein muss. Wenn der Bereitstellungsname innerhalb eines Projekts nicht eindeutig ist, schlägt die Clustererstellung fehl.
      • BUCKET_NAME: der Name des Cloud Storage-Bucket, den Sie im vorherigen Schritt erstellt haben.
      • PROJECT_ID: Projekt-ID in Google Cloud .
      • COMPUTE_REGION: die Compute-Region für den Cluster.
      • COMPUTE_ZONE: Die Computing-Zone für den Knotenpool mit A3-Ultra-Maschinen.
      • static_node_count entfernen.
      • IP_ADDRESS/SUFFIX: Der IP-Adressbereich, der eine Verbindung mit dem Cluster herstellen darf. Dieser CIDR-Block muss die IP-Adresse des Computers enthalten, den Sie zum Aufrufen von Terraform verwenden möchten. Weitere Informationen finden Sie unter Funktionsweise autorisierter Netzwerke.
      • Entfernen Sie das Feld reservation und ersetzen Sie es durch enable_flex_start: true. Fügen Sie in der nächsten Zeile enable_queued_provisioning: true hinzu, wenn Sie auch die Bereitstellung in der Warteschlange verwenden möchten. Weitere Informationen finden Sie unter Knotenpools mit Flex-Start und in die Warteschlange gestellter Bereitstellung verwenden.

      • Legen Sie die Größen der Bootlaufwerke für jeden Knoten des Systems und der A3 Ultra-Knotenpools fest. Die benötigte Festplattengröße hängt von Ihrem Anwendungsfall ab. Wenn Sie das Laufwerk beispielsweise als Cache verwenden, um die Latenz beim wiederholten Abrufen eines Images zu verringern, können Sie eine größere Laufwerkgröße festlegen, um Ihr Framework, Modell oder Container-Image aufzunehmen:

        • SYSTEM_NODE_POOL_DISK_SIZE_GB: Die Größe des Bootlaufwerks für jeden Knoten des Systemknotenpools. Die kleinste zulässige Festplattengröße ist 10. Der Standardwert ist 100.
        • A3ULTRA_NODE_POOL_DISK_SIZE_GB: Die Größe des Bootlaufwerks für jeden Knoten des A3 Ultra-Knotenpools. Die kleinste zulässige Festplattengröße ist 10. Der Standardwert ist 100.

    2. Nehmen Sie im examples/gke-a3-ultragpu/gke-a3-ultragpu.yaml-Blueprint aus dem GitHub-Repository die folgenden Änderungen vor:

      • Entfernen Sie im Block vars den Wert static_node_count.
      • Aktualisieren Sie im Block vars die version_prefix-Nummer auf "1.32." oder höher. Wenn Sie Flex-Start in GKE verwenden möchten, muss Ihr Cluster die Version 1.32.2-gke.1652000 oder höher verwenden.
      • Ersetzen Sie im vars-Block den gesamten reservation-Block (einschließlich der reservation-Zeile) durch enable_flex_start: true und optional enable_queued_provisioning: true.
      • Entfernen Sie im Block vars die folgende Zeile: kueue_configuration_path: $(ghpc_stage("./kueue-configuration.yaml.tftpl")).
      • Entfernen Sie unter id: a3-ultragpu-pool die folgende Zeile: static_node_count: $(vars.static_node_count).

      • Entfernen Sie unter id: a3-ultragpu-pool den Block reservation_affinity. Ersetzen Sie diesen Block durch die folgenden Zeilen:

        • enable_flex_start: $(vars.enable_flex_start)
        • auto_repair: false
        • Wenn Sie die Bereitstellung in der Warteschlange aktivieren möchten, fügen Sie die folgenden zusätzlichen Zeilen hinzu:
          • enable_queued_provisioning: $(vars.enable_queued_provisioning)
          • autoscaling_total_min_nodes: 0

      • Entfernen Sie unter id: workload-manager-install den folgenden Block:

        config_path: $(vars.kueue_configuration_path)
config_template_vars:
  num_gpus: $(a4-pool.static_gpu_count)
  accelerator_type: $(vars.accelerator_type)

        • So richten Sie den flexiblen Start mit der Bereitstellung in der Warteschlange ein:

          1. Fügen Sie dem vars-Block gpu_nominal_quota: NOMINAL_QUOTA hinzu. Der Wert gpu_nominal_quota wird verwendet, um die nominalQuota von GPUs in der ClusterQueue-Spezifikation festzulegen. In diesem Beispiel lässt ClusterQueue nur Arbeitslasten zu, wenn die Summe der GPU-Anforderungen kleiner oder gleich dem Wert von NOMINAL_QUOTA ist. Weitere Informationen zu ClusterQueue finden Sie im folgenden Kueue-Dokument zur Clusterwarteschlange.

          2. Aktualisieren Sie den Block kueue so:

            kueue:
   install: true
   config_path: $(vars.kueue_configuration_path)
   config_template_vars:
      num_gpus: $(vars.gpu_nominal_quota)

          3. Ersetzen Sie den Inhalt der Datei kueue-configuration.yaml.tftpl durch Folgendes:

            apiVersion: kueue.x-k8s.io/v1beta1
kind: ResourceFlavor
metadata:
   name: "default-flavor"
---
apiVersion: kueue.x-k8s.io/v1beta1
kind: AdmissionCheck
metadata:
   name: dws-prov
spec:
   controllerName: kueue.x-k8s.io/provisioning-request
   parameters:
      apiGroup: kueue.x-k8s.io
      kind: ProvisioningRequestConfig
      name: dws-config
---
apiVersion: kueue.x-k8s.io/v1beta1
kind: ProvisioningRequestConfig
metadata:
   name: dws-config
spec:
   provisioningClassName: queued-provisioning.gke.io
   managedResources:
   - nvidia.com/gpu
---
apiVersion: kueue.x-k8s.io/v1beta1
kind: ClusterQueue
metadata:
   name: "dws-cluster-queue"
spec:
   namespaceSelector: {}
   resourceGroups:
   - coveredResources: ["nvidia.com/gpu"]
      flavors:
      - name: "default-flavor"
      resources:
      - name: "nvidia.com/gpu"
         nominalQuota: ${num_gpus}
   admissionChecks:
   - dws-prov
---
apiVersion: kueue.x-k8s.io/v1beta1
kind: LocalQueue
metadata:
   namespace: "default"
   name: "dws-local-queue"
spec:
   clusterQueue: "dws-cluster-queue"
---

        • Ersetzen Sie im Feld id: job-template die Variable node_count durch 2.

    Spot

    1. Füllen Sie im examples/gke-a3-ultragpu/gke-a3-ultragpu-deployment.yaml-Blueprint aus dem GitHub-Repository die folgenden Einstellungen in den Abschnitten terraform_backend_defaults und vars entsprechend den spezifischen Werten für Ihre Bereitstellung aus:

      • DEPLOYMENT_NAME: ein eindeutiger Name für die Bereitstellung, der zwischen 6 und 30 Zeichen lang sein muss. Wenn der Bereitstellungsname innerhalb eines Projekts nicht eindeutig ist, schlägt die Clustererstellung fehl.
      • BUCKET_NAME: der Name des Cloud Storage-Bucket, den Sie im vorherigen Schritt erstellt haben.
      • PROJECT_ID: Projekt-ID in Google Cloud .
      • COMPUTE_REGION: die Compute-Region für den Cluster.
      • COMPUTE_ZONE: Die Computing-Zone für den Knotenpool mit A3-Ultra-Maschinen.
      • STATIC_NODE_COUNT: Die Anzahl der A3 Ultra-Knoten in Ihrem Cluster.
      • IP_ADDRESS/SUFFIX: Der IP-Adressbereich, der eine Verbindung mit dem Cluster herstellen darf. Dieser CIDR-Block muss die IP-Adresse des Computers enthalten, den Sie zum Aufrufen von Terraform verwenden möchten. Weitere Informationen finden Sie unter Funktionsweise autorisierter Netzwerke.
      • Ersetzen Sie den gesamten reservation-Block (einschließlich der reservation-Zeile selbst) durch spot: true.

      • Legen Sie die Größen der Bootlaufwerke für jeden Knoten des Systems und der A3 Ultra-Knotenpools fest. Die benötigte Festplattengröße hängt von Ihrem Anwendungsfall ab. Wenn Sie das Laufwerk beispielsweise als Cache verwenden, um die Latenz beim wiederholten Abrufen eines Images zu verringern, können Sie eine größere Laufwerkgröße festlegen, um Ihr Framework, Modell oder Container-Image aufzunehmen:

        • SYSTEM_NODE_POOL_DISK_SIZE_GB: Die Größe des Bootlaufwerks für jeden Knoten des Systemknotenpools. Die kleinste zulässige Festplattengröße ist 10. Der Standardwert ist 100.
        • A3ULTRA_NODE_POOL_DISK_SIZE_GB: Die Größe des Bootlaufwerks für jeden Knoten des A3 Ultra-Knotenpools. Die kleinste zulässige Festplattengröße ist 10. Der Standardwert ist 100.

    2. Nehmen Sie im examples/gke-a3-ultragpu/gke-a3-ultragpu.yaml-Blueprint aus dem GitHub-Repository die folgenden Änderungen vor:

      • Ersetzen Sie im vars-Block den gesamten reservation-Block (einschließlich der Zeile reservation selbst) durch spot: true.

      • Entfernen Sie unter id: a3-ultragpu-pool den Block reservation_affinity. Ersetzen Sie diesen Block durch die folgende Zeile:

        • spot: $(vars.spot)

  6. Optional können Sie Cluster Health Scanner (CHS) für den Cluster aktivieren. CHS prüft den Zustand Ihrer GPU-Cluster, indem Tests ausgeführt werden, um zu prüfen, ob die Cluster bereit sind, Ihre Arbeitslasten auszuführen. Um CHS zu aktivieren, nehmen Sie die folgenden Änderungen in der Datei examples/gke-a3-ultragpu/gke-a3-ultragpu-deployment.yaml vor:

    • Legen Sie im Block vars das Feld enable_periodic_health_checks auf true fest.

    • Standardmäßig werden die Healthchecks jeden Sonntag um 00:00 Uhr PST ausgeführt. Wenn Sie diese Einstellung ändern möchten, legen Sie im Block vars das Feld health_check_schedule auf einen geeigneten Wert im Cron-Format fest.
      Zeitplan im Cron-Format: none * * * * * # | | | | | # | | | | day of the week (0-6) (Sunday to Saturday) # | | | month (1-12) # | | day of the month (1-31) # | hour (0-23) # minute (0-59)

  7. Generieren Sie Standardanmeldedaten für Anwendungen (Application Default Credentials, ADC), um Zugriff auf Terraform zu gewähren. Wenn Sie Cloud Shell verwenden, können Sie den folgenden Befehl ausführen:

    gcloud auth application-default login

  8. Stellen Sie den Blueprint bereit, um die GKE-Infrastruktur mit A3-Ultra-Maschinentypen bereitzustellen:

    cd ~/cluster-toolkit
./gcluster deploy -d \
examples/gke-a3-ultragpu/gke-a3-ultragpu-deployment.yaml \
examples/gke-a3-ultragpu/gke-a3-ultragpu.yaml

  9. Wählen Sie bei entsprechender Aufforderung Anwenden aus, um das Blueprint bereitzustellen.

    • Mit dem Blueprint werden VPC-Netzwerke, ein GPU-RDMA-VPC-Netzwerk, Dienstkonten, ein Cluster und ein Knotenpool erstellt.
    • Zur Unterstützung der Jobvorlage fio-bench-job-template im Blueprint werdenGoogle Cloud -Buckets, Netzwerkspeicher und Ressourcen für persistente Volumes erstellt.

Cluster erstellen und Arbeitslasten mit XPK ausführen

Mit dem Accelerated Processing Kit (XPK) können Sie Cluster schnell bereitstellen und nutzen. XPK generiert vorkonfigurierte, für das Training optimierte Infrastruktur, die sich ideal eignet, wenn die Ausführung von Arbeitslasten Ihr Hauptaugenmerk ist.

Cluster erstellen und Arbeitslasten mit A3 Ultra-VMs mit XPK ausführen:

  1. Installieren Sie die erforderlichen Tools, um die XPK-Voraussetzungen zu erfüllen.
  2. Kopieren Sie die Versionsnummer des letzten getaggten Releases von XPK, z. B. „v0.8.0“. Ersetzen Sie im folgenden Befehl XPK_TAG durch die aktuelle XPK-Versionsnummer.

  3. Öffnen Sie ein Shell-Fenster auf einem Linux-Computer und geben Sie die folgenden Befehle ein, um XPK aus dem Git-Repository zu klonen und die erforderlichen Pakete zu installieren:

      ## Setup virtual environment.
  VENV_DIR=~/venvp3
  python3 -m venv $VENV_DIR
  source $VENV_DIR/bin/activate
  ## Clone the repository.
  git clone --branch XPK_TAG https://github.com/google/xpk.git
  cd xpk
  ## Install required packages
  make install && export PATH=$PATH:$PWD/bin

  4. Standardcluster mit A3-Ultra-VMs erstellen Sie können die Knoten des Clusters mit reservierter Kapazität bereitstellen:

      python3 xpk.py cluster create \
     --cluster=CLUSTER_NAME \
     --device-type=h200-141gb-8 \
     --zone=COMPUTE_ZONE  \
     --project=PROJECT_ID \
     --num-nodes=NUM_NODES \
     --reservation=RESERVATION_NAME

    Ersetzen Sie die folgenden Variablen:

    • CLUSTER_NAME: ein Name für den Cluster.
    • COMPUTE_ZONE: die Computing-Zone für den Knotenpool von A3-Ultra-Maschinen. Wenn Sie reservierte Kapazität verwenden möchten, müssen Sie die Zone verwenden, in der Sie die Kapazität reserviert haben. Im Allgemeinen empfehlen wir, eine Zone in der Nähe des Nutzers auszuwählen, um die Latenz zu minimieren.
    • PROJECT_ID: Ihre Google Cloud Projekt-ID.
    • NUM_NODES: die Anzahl der Worker-Knoten im Knotenpool.

    • RESERVATION_NAME: der Name Ihrer Reservierung.

      XPK bietet zusätzliche Argumente für die Clustererstellung, einschließlich der Argumente zum Erstellen privater Cluster, zum Erstellen von Vertex AI Tensorboards und zum Verwenden der automatischen Knotenbereitstellung. Weitere Informationen finden Sie im Leitfaden zum Erstellen von Clustern für XPK.

  5. Prüfen Sie, ob der Cluster erfolgreich erstellt wurde:

      python3 xpk.py cluster list --zone=COMPUTE_ZONE --project=PROJECT_ID

  6. Optional: Führen Sie eine Arbeitslast aus, um die Clusterumgebung zu testen:

      python3 xpk.py workload create \
     --workload WORKLOAD_NAME --command "echo goodbye" \
     --cluster CLUSTER_NAME \
     --device-type=h200-141gb-8 \
     --num-nodes=WORKLOAD_NUM_NODES \
     --zone=COMPUTE_ZONE \
     --project=PROJECT_ID

    Ersetzen Sie die folgenden Variablen:

    • WORKLOAD_NAME: Name Ihrer Arbeitslast.
    • CLUSTER_NAME ist der Name des Clusters.
    • WORKLOAD_NUM_NODES: Anzahl der Worker-Knoten, die für die Ausführung der Arbeitslast verwendet werden.
    • COMPUTE_ZONE: die Compute-Zone für den Knotenpool von A3 Ultra-Maschinen.
    • PROJECT_ID: Ihre Google Cloud Projekt-ID.

Netzwerkleistung testen

Wir empfehlen, die Funktionalität der bereitgestellten Cluster zu prüfen. Verwenden Sie dazu NCCL/gIB-Tests, die NVIDIA Collective Communications Library (NCCL)-Tests sind, die für die Google-Umgebung optimiert wurden.

Reproduzierbare Benchmarks ausführen

Sie können Benchmarks für das Vortraining großer Open-Source-Modelle für maschinelles Lernen auf A4- und A3-Ultra-VMs in GKE reproduzieren.

Jedes Rezept enthält eine Anleitung für die folgenden Aufgaben:

  • Bereiten Sie Ihre Umgebung vor.
  • Führen Sie den Benchmark aus.
  • Analysieren Sie die Benchmark-Ergebnisse. Dazu gehören die Benchmark-Ergebnisse und detaillierte Protokolle für die weitere Analyse.

Eine Liste aller verfügbaren Rezepturen finden Sie im GitHub-Repository für GPU-Rezepturen.

Modelle Framework Schema
Llama-3.1-70B MaxText Arbeitslast mit 32 Knoten
Llama-3.1-70B NeMo Arbeitslast mit 32 Knoten
Mixtral-8-7B NeMo Arbeitslast mit 32 Knoten

Von Cluster Toolkit erstellte Ressourcen bereinigen

So vermeiden Sie wiederkehrende Gebühren für die auf dieser Seite verwendeten Ressourcen: Bereinigen Sie die vom Cluster Toolkit bereitgestellten Ressourcen, einschließlich der VPC-Netzwerke und des GKE-Cluster:

   cd ~/cluster-toolkit
   ./gcluster destroy CLUSTER_NAME/

Ersetzen Sie CLUSTER_NAME durch den Namen Ihres Clusters. Bei Clustern, die mit dem Cluster-Toolkit erstellt wurden, basiert der Clustername auf DEPLOYMENT_NAME.

Nächste Schritte