Crea un cluster GKE ottimizzato per l'AI con la configurazione predefinita

Questa pagina mostra come creare un cluster Google Kubernetes Engine (GKE) ottimizzato per l'AI che utilizza macchine virtuali (VM) A4X, A4, A3 Ultra, A3 Mega e A3 High (8 GPU) per supportare i tuoi carichi di lavoro di AI e ML.

Le serie di macchine A4X, A4, A3 Ultra, A3 Mega e A3 High (8 GPU) sono progettate per consentirti di eseguire cluster AI/ML su larga scala con funzionalità come il posizionamento mirato dei workload, controlli avanzati di manutenzione dei cluster e pianificazione in base alla topologia. Per saperne di più, consulta la panoramica della gestione dei cluster.

GKE fornisce una singola piattaforma per eseguire un insieme diversificato di workload per le esigenze della tua organizzazione. Ciò include il pre-addestramento distribuito ad alte prestazioni, il perfezionamento del modello, l'inferenza del modello, la pubblicazione dell'applicazione e i servizi di supporto. GKE riduce il carico operativo della gestione di più piattaforme.

Scegliere come creare un cluster GKE ottimizzato per l'AI

Le seguenti opzioni per la creazione di cluster offrono ciascuna diversi gradi di facilità e flessibilità nella configurazione del cluster e nella pianificazione dei workload:

Prima di iniziare

Prima di iniziare, assicurati di aver eseguito le seguenti operazioni:

  • Attiva l'API Google Kubernetes Engine.
    • Attiva l'API Google Kubernetes Engine
  • Se vuoi utilizzare Google Cloud CLI per questa attività, installala e poi inizializza gcloud CLI. Se hai già installato gcloud CLI, scarica l'ultima versione eseguendo il comando gcloud components update. Le versioni precedenti di gcloud CLI potrebbero non supportare l'esecuzione dei comandi in questo documento.
  • Verifica di disporre delle autorizzazioni necessarie per creare e gestire il cluster GKE e i service account associati:
    • Amministratore Kubernetes Engine (roles/container.admin)
    • Compute Admin (roles/compute.admin)
    • Amministratore Storage (roles/storage.admin)
    • Project IAM Admin (roles/resourcemanager.projectIamAdmin)
    • Amministratore service account (roles/iam.serviceAccountAdmin)
    • Service Account User (roles/iam.serviceAccountUser)
    • Consumer utilizzo dei servizi (roles/serviceusage.serviceUsageConsumer)
    • Role Administrator (roles/iam.roleAdmin)
    • Manager versione secret di Secret Manager (roles/secretmanager.secretVersionManager)

Scegli un'opzione di consumo e ottieni la capacità

  1. Scegli un'opzione di consumo. Fai la tua scelta in base a come vuoi ottenere e utilizzare le risorse GPU. Per saperne di più, consulta la sezione Scegliere un'opzione di consumo.

    Per GKE, considera le seguenti informazioni aggiuntive quando scegli un'opzione di consumo:

  2. Ottenere capacità. La procedura per ottenere la capacità varia a seconda dell'opzione di consumo.

    Per informazioni sulla procedura per l'opzione di consumo scelta, consulta la sezione Panoramica della capacità.

Requisiti

Al cluster GKE ottimizzato per l'AI si applicano i seguenti requisiti:

  • Per A4X, assicurati di utilizzare, per la versione 1.33 o successive, GKE versione 1.33.4-gke.1036000 o successive. In alternativa, per la versione 1.32, utilizza GKE versione 1.32.8-gke.1108000 o successive. Queste versioni assicurano che A4X utilizzi quanto segue:

    • R580, la versione minima del driver GPU per A4X.
    • Coherent Driver-based Memory Management (CDMM), che è abilitato per impostazione predefinita. NVIDIA consiglia di attivare questa modalità nei cluster Kubernetes per risolvere il problema della segnalazione eccessiva della memoria. CDMM consente di gestire la memoria GPU tramite il driver anziché il sistema operativo. Questo approccio consente di evitare l'online del sistema operativo della memoria GPU ed espone la memoria GPU come nodo NUMA (Non-Uniform Memory Access) al sistema operativo. Le GPU multi-istanza non sono supportate quando CDMM è abilitato. Per ulteriori informazioni su CDMM, vedi Assistenza hardware e software.
    • GPUDirect RDMA, che è consigliato per consentire ai pool di nodi A4X di utilizzare le funzionalità di networking di A4X.

  • Assicurati di utilizzare la versione minima del driver GPU, a seconda del tipo di macchina:

    • A4X: le GPU GB200 nelle VM A4X richiedono almeno la versione del driver della GPU R580. Consulta i requisiti di versione menzionati in precedenza.
    • A4: le GPU B200 nelle VM A4 richiedono almeno la versione R570 del driver GPU. Per impostazione predefinita, GKE installa automaticamente questa versione del driver su tutti i nodi A4 che eseguono la versione minima richiesta per A4, 1.32.1-gke.1729000 o versioni successive.
    • A3 Ultra: le GPU H200 nelle VM A3 Ultra richiedono almeno la versione R550 del driver GPU, disponibile in GKE 1.31 come versione del driver latest. Per A3 Ultra, devi impostare gpu-driver-version=latest con GKE 1.31. Per GKE versione 1.31.5-gke.1169000 o successive, GKE, per impostazione predefinita, installa automaticamente le versioni del driver GPU R550 sui nodi A3 Ultra.

  • Per i pool di nodi A3 Ultra, devi impostare il tipo di disco su hyperdisk-balanced.

  • Per utilizzare GPUDirect RDMA, utilizza le seguenti versioni minime a seconda del tipo di macchina:

    • A4X: consulta i requisiti di versione menzionati in precedenza.
    • A4: utilizza la versione 1.32.2-gke.1475000 o successive.
    • A3 Ultra: utilizza la versione 1.31.4-gke.1183000 o successive.

  • Per utilizzare GPUDirect RDMA, i nodi GKE devono utilizzare un'immagine del nodo Container-Optimized OS. Le immagini dei nodi Ubuntu e Windows non sono supportate.

  • Per creare cluster con A4X, devi utilizzare il modello di provisioning con prenotazione. Altri modelli di provisioning non sono supportati.

Crea un cluster

Segui queste istruzioni per creare un cluster utilizzando Cluster Toolkit o XPK.

Crea un cluster utilizzando Cluster Toolkit

Questa sezione ti guida nella procedura di creazione del cluster, assicurandosi che il tuo progetto segua le best practice e soddisfi i requisiti per un cluster GKE ottimizzato per l'AI.

A4X

  1. Avvia Cloud Shell. Puoi utilizzare un ambiente diverso, ma ti consigliamo Cloud Shell perché le dipendenze sono già preinstallate per Cluster Toolkit. Se non vuoi utilizzare Cloud Shell, segui le istruzioni per installare le dipendenze per preparare un ambiente diverso.

  2. Clona Cluster Toolkit dal repository Git:

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

  3. Installa Cluster Toolkit:

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

  4. Crea un bucket Cloud Storage per archiviare lo stato del deployment di Terraform:

    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

    Sostituisci le seguenti variabili:

    • BUCKET_NAME: il nome del nuovo bucket Cloud Storage.
    • PROJECT_ID: il tuo ID progetto Google Cloud .
    • COMPUTE_REGION_TERRAFORM_STATE: la regione di Compute in cui vuoi memorizzare lo stato del deployment Terraform.

  5. Nel progetto base examples/gke-a4x/gke-a4x-deployment.yaml dal repository GitHub, inserisci le seguenti impostazioni nelle sezioni terraform_backend_defaults e vars in modo che corrispondano ai valori specifici per il tuo deployment:

    • DEPLOYMENT_NAME: un nome univoco per il deployment, che deve essere compreso tra 6 e 30 caratteri. Se il nome del deployment non è univoco all'interno di un progetto, la creazione del cluster non va a buon fine. Il valore predefinito è gke-a4x.
    • BUCKET_NAME: il nome del bucket Cloud Storage creato nel passaggio precedente.
    • PROJECT_ID: il tuo ID progetto Google Cloud .
    • COMPUTE_REGION: la regione di computing del cluster.
    • COMPUTE_ZONE: la zona di computing del pool di nodi delle macchine A4X. Tieni presente che questa zona deve corrispondere a quella in cui le macchine sono disponibili nella prenotazione.
    • NODE_COUNT: il numero di nodi A4X nel pool di nodi del cluster, che deve essere pari o inferiore a 18. Ti consigliamo di utilizzare 18 nodi per ottenere la topologia della GPU di 1x72 in un sottoblocco utilizzando un dominio NVLink.
    • IP_ADDRESS/SUFFIX: l'intervallo di indirizzi IP a cui vuoi consentire di connettersi al cluster. Questo blocco CIDR deve includere l'indirizzo IP della macchina che vuoi utilizzare per chiamare Terraform. Per saperne di più, consulta Come funzionano le reti autorizzate.

    • Per il campo extended_reservation, utilizza uno dei seguenti valori, a seconda che tu voglia scegliere come target blocchi specifici in una prenotazione durante il provisioning del pool di nodi:

      • Per posizionare il pool di nodi in un punto qualsiasi della prenotazione, fornisci il nome della prenotazione (RESERVATION_NAME).

      • Per scegliere come target un blocco specifico all'interno della prenotazione, utilizza i nomi della prenotazione e del blocco nel seguente formato:

        RESERVATION_NAME/reservationBlocks/BLOCK_NAME

      Se non sai quali blocchi sono disponibili nella tua prenotazione, consulta Visualizzare la topologia di una prenotazione.

    • Imposta le dimensioni del disco di avvio per ogni nodo del sistema e dei node pool A4X. La dimensione del disco necessaria dipende dal caso d'uso. Ad esempio, se utilizzi il disco come cache per ridurre la latenza del pull ripetuto di un'immagine, puoi impostare una dimensione del disco più grande per adattarsi al framework, al modello o all'immagine del container:

      • SYSTEM_NODE_POOL_DISK_SIZE_GB: le dimensioni del disco di avvio per ogni nodo del pool di nodi di sistema. La dimensione minima del disco consentita è 10. Il valore predefinito è 200.
      • A4X_NODE_POOL_DISK_SIZE_GB: le dimensioni del disco di avvio per ogni nodo del pool di nodi A4X. La dimensione minima del disco consentita è 10. Il valore predefinito è 100.

    Per modificare le impostazioni avanzate, modifica il file examples/gke-a4x/gke-a4x.yaml.

  6. (Facoltativo) Puoi abilitare Cluster Health Scanner (CHS) sul cluster. CHS controlla l'integrità dei cluster GPU eseguendo test per verificare che siano pronti per eseguire i tuoi carichi di lavoro. Per attivare CHS, apporta le seguenti modifiche al file examples/gke-a4x/gke-a4x-deployment.yaml:

    • Nel blocco vars, imposta il campo enable_periodic_health_checks su true.

    • Per impostazione predefinita, i controlli di integrità vengono eseguiti ogni domenica alle 00:00 PST. Se vuoi modificare questa impostazione, nel blocco vars, imposta il campo health_check_schedule su un valore appropriato nel formato cron.
      Pianifica in formato cron: 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. Genera le credenziali predefinite dell'applicazione (ADC) per fornire l'accesso a Terraform. Se utilizzi Cloud Shell, puoi eseguire questo comando:

    gcloud auth application-default login

  8. Esegui il deployment del blueprint per eseguire il provisioning dell'infrastruttura GKE utilizzando i tipi di macchine A4X:

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

  9. Quando richiesto, seleziona Applica per eseguire il deployment del blueprint.

    • Il blueprint crea reti VPC, una rete VPC GPU RDMA, service account, un cluster e un pool di nodi.
    • Per supportare il modello di job fio-bench-job-template nel blueprint, vengono create risorse di bucket, spazio di archiviazione di rete e volumi permanentiGoogle Cloud .

A4

  1. Avvia Cloud Shell. Puoi utilizzare un ambiente diverso, ma ti consigliamo Cloud Shell perché le dipendenze sono già preinstallate per Cluster Toolkit. Se non vuoi utilizzare Cloud Shell, segui le istruzioni per installare le dipendenze per preparare un ambiente diverso.

  2. Clona Cluster Toolkit dal repository Git:

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

  3. Installa Cluster Toolkit:

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

  4. Crea un bucket Cloud Storage per archiviare lo stato del deployment di Terraform:

    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

    Sostituisci le seguenti variabili:

    • BUCKET_NAME: il nome del nuovo bucket Cloud Storage.
    • PROJECT_ID: il tuo ID progetto Google Cloud .
    • COMPUTE_REGION_TERRAFORM_STATE: la regione di Compute in cui vuoi memorizzare lo stato del deployment Terraform.

  5. I file che devi modificare per creare un cluster dipendono dall'opzione di consumo che utilizzi per il deployment. Seleziona la scheda corrispondente al modello di provisioning dell'opzione di consumo.

    Con prenotazione

    Nel progetto base examples/gke-a4/gke-a4-deployment.yaml dal repository GitHub, inserisci le seguenti impostazioni nelle sezioni terraform_backend_defaults e vars in modo che corrispondano ai valori specifici per il tuo deployment:

    • DEPLOYMENT_NAME: un nome univoco per il deployment, che deve essere compreso tra 6 e 30 caratteri. Se il nome del deployment non è univoco all'interno di un progetto, la creazione del cluster non va a buon fine. Il valore predefinito è gke-a4.
    • BUCKET_NAME: il nome del bucket Cloud Storage creato nel passaggio precedente.
    • PROJECT_ID: il tuo ID progetto Google Cloud .
    • COMPUTE_REGION: la regione di computing del cluster.
    • COMPUTE_ZONE: la zona di computing del pool di nodi delle macchine A4. Tieni presente che questa zona deve corrispondere a quella in cui le macchine sono disponibili nella prenotazione.
    • NODE_COUNT: il numero di nodi A4 nel cluster.
    • IP_ADDRESS/SUFFIX: l'intervallo di indirizzi IP a cui vuoi consentire di connettersi al cluster. Questo blocco CIDR deve includere l'indirizzo IP della macchina che vuoi utilizzare per chiamare Terraform. Per saperne di più, consulta Come funzionano le reti autorizzate.

    • Per il campo reservation, utilizza uno dei seguenti valori, a seconda che tu voglia scegliere come target blocchi specifici in una prenotazione durante il provisioning del pool di nodi:

      • Per posizionare il pool di nodi in un punto qualsiasi della prenotazione, fornisci il nome della prenotazione (RESERVATION_NAME).

      • Per scegliere come target un blocco specifico all'interno della prenotazione, utilizza i nomi della prenotazione e del blocco nel seguente formato:

        RESERVATION_NAME/reservationBlocks/BLOCK_NAME

      Se non sai quali blocchi sono disponibili nella tua prenotazione, consulta Visualizzare la topologia di una prenotazione.

    • Imposta le dimensioni del disco di avvio per ogni nodo del sistema e dei node pool A4. La dimensione del disco necessaria dipende dal caso d'uso. Ad esempio, se utilizzi il disco come cache per ridurre la latenza del pull ripetuto di un'immagine, puoi impostare una dimensione del disco più grande per adattarsi al framework, al modello o all'immagine del container:

      • SYSTEM_NODE_POOL_DISK_SIZE_GB: le dimensioni del disco di avvio per ogni nodo del pool di nodi di sistema. La dimensione minima del disco consentita è 10. Il valore predefinito è 100.
      • A4_NODE_POOL_DISK_SIZE_GB: le dimensioni del disco di avvio per ogni nodo del pool di nodi A4. La dimensione minima del disco consentita è 10. Il valore predefinito è 100.

    Per modificare le impostazioni avanzate, modifica examples/gke-a4/gke-a4.yaml.

    Avvio flessibile

    1. Nel progetto base examples/gke-a4/gke-a4-deployment.yaml dal repository GitHub, inserisci le seguenti impostazioni nelle sezioni terraform_backend_defaults e vars in modo che corrispondano ai valori specifici per il tuo deployment:

      • DEPLOYMENT_NAME: un nome univoco per il deployment, che deve essere compreso tra 6 e 30 caratteri. Se il nome del deployment non è univoco all'interno di un progetto, la creazione del cluster non riesce. Il valore predefinito è gke-a4.
      • BUCKET_NAME: il nome del bucket Cloud Storage creato nel passaggio precedente.
      • PROJECT_ID: il tuo ID progetto Google Cloud .
      • COMPUTE_REGION: la regione di computing del cluster.
      • COMPUTE_ZONE: la zona di computing del pool di nodi delle macchine A4.
      • Rimuovi static_node_count.
      • IP_ADDRESS/SUFFIX: l'intervallo di indirizzi IP a cui vuoi consentire di connettersi al cluster. Questo blocco CIDR deve includere l'indirizzo IP della macchina che vuoi utilizzare per chiamare Terraform. Per saperne di più, consulta Come funzionano le reti autorizzate.
      • Rimuovi il campo reservation e sostituiscilo con enable_flex_start: true. Aggiungi enable_queued_provisioning: true nella riga successiva se vuoi utilizzare anche il provisioning in coda. Per saperne di più, consulta Utilizzare i pool di nodi con avvio flessibile con provisioning in coda.

      • Imposta le dimensioni del disco di avvio per ogni nodo del sistema e dei node pool A4. La dimensione del disco necessaria dipende dal caso d'uso. Ad esempio, se utilizzi il disco come cache per ridurre la latenza del pull ripetuto di un'immagine, puoi impostare una dimensione del disco più grande per adattarsi al framework, al modello o all'immagine del container:

        • SYSTEM_NODE_POOL_DISK_SIZE_GB: le dimensioni del disco di avvio per ogni nodo del pool di nodi di sistema. La dimensione minima del disco consentita è 10. Il valore predefinito è 100.
        • A4_NODE_POOL_DISK_SIZE_GB: le dimensioni del disco di avvio per ogni nodo del pool di nodi A4. La dimensione minima del disco consentita è 10. Il valore predefinito è 100.

    2. Nel progetto base examples/gke-a4/gke-a4.yaml dal repository GitHub, apporta le seguenti modifiche:

      • Nel blocco vars, rimuovi static_node_count.
      • Nel blocco vars, assicurati che il numero version_prefix sia "1.32." o superiore. Per utilizzare l'avvio flessibile in GKE, il cluster deve utilizzare la versione 1.32.2-gke.1652000 o successive.
      • Nel blocco vars, sostituisci l'intero blocco reservation (inclusa la riga reservation) con enable_flex_start: true e, facoltativamente, enable_queued_provisioning: true.
      • Nel blocco vars, se non è necessario il provisioning in coda, rimuovi la seguente riga: kueue_configuration_path: $(ghpc_stage("./kueue-configuration.yaml.tftpl")).
      • In id: a4-pool, rimuovi la seguente riga: static_node_count: $(vars.static_node_count).

      • Nella sezione id: a4-pool, rimuovi il blocco reservation_affinity. Sostituisci questo blocco con le seguenti righe:

        • enable_flex_start: $(vars.enable_flex_start)
        • auto_repair: false
        • Per il provisioning in coda, se vuoi attivarlo, aggiungi le seguenti righe aggiuntive:
          • enable_queued_provisioning: $(vars.enable_queued_provisioning)
          • autoscaling_total_min_nodes: 0

      • In id: workload-manager-install, rimuovi il seguente blocco:

         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)

        • Per l'avvio flessibile con provisioning in coda:

          1. Aggiungi gpu_nominal_quota: NOMINAL_QUOTA al blocco vars. Il valore gpu_nominal_quota viene utilizzato per impostare nominalQuota delle GPU nella specifica ClusterQueue (vedi il passaggio di impostazione di ClusterQueue di seguito). In questo esempio, ClusterQueue ammette i workload solo se la somma delle richieste di GPU è inferiore o uguale al valore NOMINAL_QUOTA. Per saperne di più su ClusterQueue, consulta il seguente documento di Kueue sulla coda del cluster.

          2. Aggiorna il blocco kueue come segue:

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

          3. Sostituisci i contenuti del file kueue-configuration.yaml.tftpl con i seguenti:

            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"
---

      • In id: job-template, sostituisci la variabile node_count con 2.

    Spot

    1. Nel progetto base examples/gke-a4/gke-a4-deployment.yaml dal repository GitHub, inserisci le seguenti impostazioni nelle sezioni terraform_backend_defaults e vars in modo che corrispondano ai valori specifici per il tuo deployment:

      • DEPLOYMENT_NAME: un nome univoco per il deployment, che deve essere compreso tra 6 e 30 caratteri. Se il nome del deployment non è univoco all'interno di un progetto, la creazione del cluster non riesce. Il valore predefinito è gke-a4.
      • BUCKET_NAME: il nome del bucket Cloud Storage creato nel passaggio precedente.
      • PROJECT_ID: il tuo ID progetto Google Cloud .
      • COMPUTE_REGION: la regione di computing del cluster.
      • COMPUTE_ZONE: la zona di computing del pool di nodi delle macchine A4.
      • STATIC_NODE_COUNT: il numero di nodi A4 nel cluster.
      • IP_ADDRESS/SUFFIX: l'intervallo di indirizzi IP a cui vuoi consentire di connettersi al cluster. Questo blocco CIDR deve includere l'indirizzo IP della macchina che vuoi utilizzare per chiamare Terraform. Per saperne di più, consulta Come funzionano le reti autorizzate.
      • Sostituisci l'intero blocco reservation (inclusa la riga reservation) con spot: true.

      • Imposta le dimensioni del disco di avvio per ogni nodo del sistema e dei node pool A4. La dimensione del disco necessaria dipende dal caso d'uso. Ad esempio, se utilizzi il disco come cache per ridurre la latenza del pull ripetuto di un'immagine, puoi impostare una dimensione del disco più grande per adattarsi al framework, al modello o all'immagine del container:

        • SYSTEM_NODE_POOL_DISK_SIZE_GB: le dimensioni del disco di avvio per ogni nodo del pool di nodi di sistema. La dimensione minima del disco consentita è 10. Il valore predefinito è 100.
        • A4_NODE_POOL_DISK_SIZE_GB: le dimensioni del disco di avvio per ogni nodo del pool di nodi A4. La dimensione minima del disco consentita è 10. Il valore predefinito è 100.

    2. Nel progetto base examples/gke-a4/gke-a4.yaml dal repository GitHub, apporta le seguenti modifiche:

      • Nel blocco vars, sostituisci l'intero blocco reservation (inclusa la riga reservation) con spot: true.

      • Nella sezione id: a4-pool, rimuovi il blocco reservation_affinity. Sostituisci questo blocco con la seguente riga:

        • spot: $(vars.spot)

  6. (Facoltativo) Puoi abilitare Cluster Health Scanner (CHS) sul cluster. CHS controlla l'integrità dei cluster GPU eseguendo test per verificare che siano pronti per eseguire i tuoi carichi di lavoro. Per attivare CHS, apporta le seguenti modifiche al file examples/gke-a4/gke-a4-deployment.yaml:

    • Nel blocco vars, imposta il campo enable_periodic_health_checks su true.

    • Per impostazione predefinita, i controlli di integrità vengono eseguiti ogni domenica alle 00:00 PST. Se vuoi modificare questa impostazione, nel blocco vars, imposta il campo health_check_schedule su un valore appropriato nel formato cron.
      Pianifica in formato cron: 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. Genera le credenziali predefinite dell'applicazione (ADC) per fornire l'accesso a Terraform. Se utilizzi Cloud Shell, puoi eseguire questo comando:

    gcloud auth application-default login

  8. Esegui il deployment del blueprint per eseguire il provisioning dell'infrastruttura GKE utilizzando i tipi di macchine A4:

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

  9. Quando richiesto, seleziona Applica per eseguire il deployment del blueprint.

    • Il blueprint crea reti VPC, una rete VPC GPU RDMA, service account, un cluster e un pool di nodi.
    • Per supportare il modello di job fio-bench-job-template nel blueprint, vengono create risorse di bucket, spazio di archiviazione di rete e volumi permanentiGoogle Cloud .

A3 Ultra

  1. Avvia Cloud Shell. Puoi utilizzare un ambiente diverso, ma ti consigliamo Cloud Shell perché le dipendenze sono già preinstallate per Cluster Toolkit. Se non vuoi utilizzare Cloud Shell, segui le istruzioni per installare le dipendenze per preparare un ambiente diverso.

  2. Clona Cluster Toolkit dal repository Git:

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

  3. Installa Cluster Toolkit:

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

  4. Crea un bucket Cloud Storage per archiviare lo stato del deployment di Terraform:

    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

    Sostituisci le seguenti variabili:

    • BUCKET_NAME: il nome del nuovo bucket Cloud Storage.
    • PROJECT_ID: il tuo ID progetto Google Cloud .
    • COMPUTE_REGION_TERRAFORM_STATE: la regione di Compute in cui vuoi memorizzare lo stato del deployment Terraform.

  5. I file che devi modificare per creare un cluster dipendono dall'opzione di consumo che utilizzi per il deployment. Seleziona la scheda corrispondente al modello di provisioning dell'opzione di consumo.

    Con prenotazione

    Nel examples/gke-a3-ultragpu/gke-a3-ultragpu-deployment.yaml blueprint dal repository GitHub, sostituisci le seguenti variabili nelle sezioni terraform_backend_defaults e vars in modo che corrispondano ai valori specifici per il tuo deployment:

    • DEPLOYMENT_NAME: un nome univoco per il deployment, che deve essere compreso tra 6 e 30 caratteri. Se il nome del deployment non è univoco all'interno di un progetto, la creazione del cluster non va a buon fine.
    • BUCKET_NAME: il nome del bucket Cloud Storage creato nel passaggio precedente.
    • PROJECT_ID: il tuo ID progetto Google Cloud .
    • COMPUTE_REGION: la regione di computing del cluster.
    • COMPUTE_ZONE: la zona di computing del pool di nodi delle macchine A3 Ultra. Tieni presente che questa zona deve corrispondere a quella in cui le macchine sono disponibili nella prenotazione.
    • NODE_COUNT: il numero di nodi A3 Ultra nel cluster.
    • IP_ADDRESS/SUFFIX: l'intervallo di indirizzi IP a cui vuoi consentire di connettersi al cluster. Questo blocco CIDR deve includere l'indirizzo IP della macchina che vuoi utilizzare per chiamare Terraform. Per saperne di più, consulta Come funzionano le reti autorizzate.

    • Per il campo reservation, utilizza uno dei seguenti valori, a seconda che tu voglia scegliere come target blocchi specifici in una prenotazione durante il provisioning del pool di nodi:

      • Per posizionare il pool di nodi in un punto qualsiasi della prenotazione, fornisci il nome della prenotazione (RESERVATION_NAME).

      • Per scegliere come target un blocco specifico all'interno della prenotazione, utilizza i nomi della prenotazione e del blocco nel seguente formato:

        RESERVATION_NAME/reservationBlocks/BLOCK_NAME

      Se non sai quali blocchi sono disponibili nella tua prenotazione, consulta Visualizzare la topologia di una prenotazione.

    • Imposta le dimensioni del disco di avvio per ogni nodo del sistema e dei node pool A3 Ultra. La dimensione del disco necessaria dipende dal caso d'uso. Ad esempio, se utilizzi il disco come cache per ridurre la latenza del pull ripetuto di un'immagine, puoi impostare una dimensione del disco più grande per adattarsi al framework, al modello o all'immagine del container:

      • SYSTEM_NODE_POOL_DISK_SIZE_GB: le dimensioni del disco di avvio per ogni nodo del pool di nodi di sistema. La dimensione minima del disco consentita è 10. Il valore predefinito è 100.
      • A3ULTRA_NODE_POOL_DISK_SIZE_GB: le dimensioni del disco di avvio per ogni nodo del pool di nodi A3 Ultra. La dimensione minima del disco consentita è 10. Il valore predefinito è 100.

    Per modificare le impostazioni avanzate, modifica examples/gke-a3-ultragpu/gke-a3-ultragpu.yaml.

    Avvio flessibile

    1. Nel examples/gke-a3-ultragpu/gke-a3-ultragpu-deployment.yaml blueprint dal repository GitHub, sostituisci le seguenti variabili nelle sezioni terraform_backend_defaults e vars in modo che corrispondano ai valori specifici per il tuo deployment:

      • DEPLOYMENT_NAME: un nome univoco per il deployment, che deve essere compreso tra 6 e 30 caratteri. Se il nome del deployment non è univoco all'interno di un progetto, la creazione del cluster non riesce.
      • BUCKET_NAME: il nome del bucket Cloud Storage creato nel passaggio precedente.
      • PROJECT_ID: il tuo ID progetto Google Cloud .
      • COMPUTE_REGION: la regione di computing del cluster.
      • COMPUTE_ZONE: la zona di computing del pool di nodi delle macchine A3 Ultra.
      • Rimuovi static_node_count.
      • IP_ADDRESS/SUFFIX: l'intervallo di indirizzi IP a cui vuoi consentire di connettersi al cluster. Questo blocco CIDR deve includere l'indirizzo IP della macchina che vuoi utilizzare per chiamare Terraform. Per saperne di più, consulta Come funzionano le reti autorizzate.
      • Rimuovi il campo reservation e sostituiscilo con enable_flex_start: true. Aggiungi enable_queued_provisioning: true nella riga successiva se vuoi utilizzare anche il provisioning in coda. Per saperne di più, consulta Utilizzare i pool di nodi con avvio flessibile con provisioning in coda.

      • Imposta le dimensioni del disco di avvio per ogni nodo del sistema e dei node pool A3 Ultra. La dimensione del disco necessaria dipende dal caso d'uso. Ad esempio, se utilizzi il disco come cache per ridurre la latenza del pull ripetuto di un'immagine, puoi impostare una dimensione del disco più grande per adattarsi al framework, al modello o all'immagine del container:

        • SYSTEM_NODE_POOL_DISK_SIZE_GB: le dimensioni del disco di avvio per ogni nodo del pool di nodi di sistema. La dimensione minima del disco consentita è 10. Il valore predefinito è 100.
        • A3ULTRA_NODE_POOL_DISK_SIZE_GB: le dimensioni del disco di avvio per ogni nodo del pool di nodi A3 Ultra. La dimensione minima del disco consentita è 10. Il valore predefinito è 100.

    2. Nel progetto base examples/gke-a3-ultragpu/gke-a3-ultragpu.yaml del repository GitHub, apporta le seguenti modifiche:

      • Nel blocco vars, rimuovi static_node_count.
      • Nel blocco vars, aggiorna il numero version_prefix a "1.32." o a un valore superiore. Per utilizzare l'avvio flessibile in GKE, il cluster deve utilizzare la versione 1.32.2-gke.1652000 o successive.
      • Nel blocco vars, sostituisci l'intero blocco reservation (inclusa la riga reservation) con enable_flex_start: true e, facoltativamente, enable_queued_provisioning: true.
      • Nel blocco vars, rimuovi la seguente riga: kueue_configuration_path: $(ghpc_stage("./kueue-configuration.yaml.tftpl")).
      • In id: a3-ultragpu-pool, rimuovi la seguente riga: static_node_count: $(vars.static_node_count).

      • Nella sezione id: a3-ultragpu-pool, rimuovi il blocco reservation_affinity. Sostituisci questo blocco con le seguenti righe:

        • enable_flex_start: $(vars.enable_flex_start)
        • auto_repair: false
        • Per il provisioning in coda, se vuoi attivarlo, aggiungi le seguenti righe aggiuntive:
          • enable_queued_provisioning: $(vars.enable_queued_provisioning)
          • autoscaling_total_min_nodes: 0

      • In id: workload-manager-install, rimuovi il seguente blocco:

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

        • Per l'avvio flessibile con provisioning in coda, segui questi tre passaggi:

          1. Aggiungi gpu_nominal_quota: NOMINAL_QUOTA al blocco vars. Il valore gpu_nominal_quota viene utilizzato per impostare il valore nominalQuota delle GPU nella specifica ClusterQueue. In questo esempio, ClusterQueue ammette carichi di lavoro solo se la somma delle richieste di GPU è inferiore o uguale al valore di NOMINAL_QUOTA. Per saperne di più su ClusterQueue, consulta il seguente documento di Kueue sulla coda del cluster.

          2. Aggiorna il blocco kueue come segue:

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

          3. Sostituisci i contenuti del file kueue-configuration.yaml.tftpl con i seguenti:

            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"
---

        • Nel campo id: job-template, sostituisci la variabile node_count con 2.

    Spot

    1. Nel examples/gke-a3-ultragpu/gke-a3-ultragpu-deployment.yaml blueprint dal repository GitHub, inserisci le seguenti impostazioni nelle sezioni terraform_backend_defaults e vars in modo che corrispondano ai valori specifici per il tuo deployment:

      • DEPLOYMENT_NAME: un nome univoco per il deployment, che deve essere compreso tra 6 e 30 caratteri. Se il nome del deployment non è univoco all'interno di un progetto, la creazione del cluster non riesce.
      • BUCKET_NAME: il nome del bucket Cloud Storage creato nel passaggio precedente.
      • PROJECT_ID: il tuo ID progetto Google Cloud .
      • COMPUTE_REGION: la regione di computing del cluster.
      • COMPUTE_ZONE: la zona di computing del pool di nodi delle macchine A3 Ultra.
      • STATIC_NODE_COUNT: il numero di nodi A3 Ultra nel cluster.
      • IP_ADDRESS/SUFFIX: l'intervallo di indirizzi IP a cui vuoi consentire di connettersi al cluster. Questo blocco CIDR deve includere l'indirizzo IP della macchina che vuoi utilizzare per chiamare Terraform. Per saperne di più, consulta Come funzionano le reti autorizzate.
      • Sostituisci l'intero blocco reservation (inclusa la riga reservation) con spot: true.

      • Imposta le dimensioni del disco di avvio per ogni nodo del sistema e dei node pool A3 Ultra. La dimensione del disco necessaria dipende dal caso d'uso. Ad esempio, se utilizzi il disco come cache per ridurre la latenza del pull ripetuto di un'immagine, puoi impostare una dimensione del disco più grande per adattarsi al framework, al modello o all'immagine del container:

        • SYSTEM_NODE_POOL_DISK_SIZE_GB: le dimensioni del disco di avvio per ogni nodo del pool di nodi di sistema. La dimensione minima del disco consentita è 10. Il valore predefinito è 100.
        • A3ULTRA_NODE_POOL_DISK_SIZE_GB: le dimensioni del disco di avvio per ogni nodo del pool di nodi A3 Ultra. La dimensione minima del disco consentita è 10. Il valore predefinito è 100.

    2. Nel progetto base examples/gke-a3-ultragpu/gke-a3-ultragpu.yaml dal repository GitHub, apporta le seguenti modifiche:

      • Nel blocco vars, sostituisci l'intero blocco reservation (inclusa la riga reservation) con spot: true.

      • Nella sezione id: a3-ultragpu-pool, rimuovi il blocco reservation_affinity. Sostituisci questo blocco con la seguente riga:

        • spot: $(vars.spot)

  6. (Facoltativo) Puoi abilitare Cluster Health Scanner (CHS) sul cluster. CHS controlla l'integrità dei cluster GPU eseguendo test per verificare che siano pronti per eseguire i tuoi carichi di lavoro. Per attivare CHS, apporta le seguenti modifiche al file examples/gke-a3-ultragpu/gke-a3-ultragpu-deployment.yaml:

    • Nel blocco vars, imposta il campo enable_periodic_health_checks su true.

    • Per impostazione predefinita, i controlli di integrità vengono eseguiti ogni domenica alle 00:00 PST. Se vuoi modificare questa impostazione, nel blocco vars, imposta il campo health_check_schedule su un valore appropriato nel formato cron.
      Pianifica in formato cron: 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. Genera le credenziali predefinite dell'applicazione (ADC) per fornire l'accesso a Terraform. Se utilizzi Cloud Shell, puoi eseguire il seguente comando:

    gcloud auth application-default login

  8. Esegui il deployment del blueprint per eseguire il provisioning dell'infrastruttura GKE utilizzando i tipi di macchine A3 Ultra:

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

  9. Quando richiesto, seleziona Applica per eseguire il deployment del blueprint.

    • Il blueprint crea reti VPC, una rete VPC GPU RDMA, service account, un cluster e un pool di nodi.
    • Per supportare il modello di job fio-bench-job-template nel progetto, vengono create risorse di bucketGoogle Cloud , spazio di archiviazione di rete e volumi permanenti.

Crea un cluster ed esegui i workload utilizzando XPK

Accelerated Processing Kit (XPK) ti consente di eseguire rapidamente il provisioning e l'utilizzo dei cluster. XPK genera un'infrastruttura preconfigurata e ottimizzata per l'addestramento, ideale quando l'esecuzione del workload è il tuo obiettivo principale.

Crea un cluster ed esegui i workload con le VM A3 Ultra utilizzando XPK:

  1. Installa gli strumenti richiesti per soddisfare i prerequisiti XPK.
  2. Copia il numero di versione dell'ultima release taggata di XPK, ad esempio "v0.8.0". Nel comando seguente, sostituisci XPK_TAG con il numero dell'ultima versione di XPK.

  3. Apri una finestra della shell su una macchina Linux e inserisci i seguenti comandi per clonare XPK dal repository Git e installare i pacchetti richiesti:

      ## 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. Crea un cluster Standard utilizzando le VM A3 Ultra. Puoi eseguire il provisioning dei nodi del cluster utilizzando la capacità riservata:

      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

    Sostituisci le seguenti variabili:

    • CLUSTER_NAME: un nome per il cluster.
    • COMPUTE_ZONE: la zona di computing per il pool di nodi delle macchine A3 Ultra. Per utilizzare la capacità riservata, assicurati di utilizzare la zona in cui hai prenotato la capacità. In genere, consigliamo di scegliere una zona vicina all'utente per ridurre al minimo la latenza.
    • PROJECT_ID: il tuo Google Cloud ID progetto.
    • NUM_NODES: il numero di nodi worker nel pool di nodi.

    • RESERVATION_NAME: il nome della prenotazione.

      XPK offre argomenti aggiuntivi per la creazione di cluster, inclusi quelli per la creazione di cluster privati, la creazione di Vertex AI TensorBoard e l'utilizzo del provisioning automatico dei nodi. Per saperne di più, consulta la guida alla creazione di cluster per XPK.

  5. Verifica che il cluster sia stato creato correttamente:

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

  6. (Facoltativo) Esegui un workload per testare l'ambiente del cluster:

      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

    Sostituisci le seguenti variabili:

    • WORKLOAD_NAME: il nome del tuo workload.
    • CLUSTER_NAME: il nome del cluster.
    • WORKLOAD_NUM_NODES: il numero di nodi di lavoro utilizzati per l'esecuzione del workload.
    • COMPUTE_ZONE: la zona di calcolo per il pool di nodi delle macchine A3 Ultra.
    • PROJECT_ID: il tuo Google Cloud ID progetto.

Testare le prestazioni della rete

Ti consigliamo di convalidare la funzionalità dei cluster di cui è stato eseguito il provisioning. Per farlo, utilizza i test NCCL/gIB, ovvero i test NVIDIA Collective Communications Library (NCCL) ottimizzati per l'ambiente Google.

Eseguire benchmark riproducibili

Puoi utilizzare i benchmark di pre-addestramento per modelli open source di machine learning di grandi dimensioni su VM A4 e A3 Ultra su GKE.

Ogni ricetta fornisce le istruzioni per completare le seguenti attività:

  • Prepara l'ambiente.
  • Esegui il benchmark.
  • Analizza i risultati dei benchmark. Sono inclusi i risultati del benchmark e i log dettagliati per ulteriori analisi.

Per visualizzare tutte le formule disponibili, consulta il repository GitHub GPU recipes.

Modelli Framework Formula
Llama-3.1-70B MaxText Carico di lavoro di 32 nodi
Llama-3.1-70B NeMo Carico di lavoro di 32 nodi
Mixtral-8-7B NeMo Carico di lavoro di 32 nodi

Ripulisci le risorse create da Cluster Toolkit

Per evitare addebiti ricorrenti per le risorse utilizzate in questa pagina, pulisci le risorse di cui è stato eseguito il provisioning da Cluster Toolkit, incluse le reti VPC e il cluster GKE:

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

Sostituisci CLUSTER_NAME con il nome del tuo cluster. Per i cluster creati con Cluster Toolkit, il nome del cluster si basa su DEPLOYMENT_NAME.

Passaggi successivi