Créer un cluster GKE optimisé pour l'IA avec la configuration par défaut

Cette page vous explique comment créer votre propre cluster Google Kubernetes Engine (GKE) optimisé pour l'IA, qui utilise des machines virtuelles (VM) A4X, A4, A3 Ultra, A3 Mega et A3 High (8 GPU) pour prendre en charge vos charges de travail d'IA et de ML.

Les séries de machines A4X, A4, A3 Ultra, A3 Mega et A3 High (8 GPU) sont conçues pour vous permettre d'exécuter des clusters d'IA/de ML à grande échelle avec des fonctionnalités telles que le placement ciblé des charges de travail, des contrôles avancés de maintenance des clusters et la planification tenant compte de la topologie. Pour en savoir plus, consultez la présentation de la gestion des clusters.

GKE fournit une plate-forme unique pour exécuter un ensemble varié de charges de travail afin de répondre aux besoins de votre organisation. Cela inclut le pré-entraînement distribué hautes performances, l'affinage des modèles, l'inférence des modèles, la diffusion d'applications et les services associés. GKE réduit la charge opérationnelle liée à la gestion de plusieurs plates-formes.

Choisir comment créer un cluster GKE optimisé pour l'IA

Les options suivantes pour la création de clusters offrent chacune différents degrés de facilité et de flexibilité dans la configuration des clusters et la planification des charges de travail :

Avant de commencer

Avant de commencer, effectuez les tâches suivantes :

  • Activez l'API Google Kubernetes Engine.
    • Activer l'API Google Kubernetes Engine
  • Si vous souhaitez utiliser la Google Cloud CLI pour cette tâche, installez et initialisez la gcloud CLI. Si vous avez déjà installé la gcloud CLI, obtenez la dernière version en exécutant la commande gcloud components update. Il est possible que les versions antérieures de la gcloud CLI ne permettent pas d'exécuter les commandes de ce document.
  • Vérifiez que vous disposez des autorisations requises pour créer et gérer le cluster GKE et les comptes de service associés :
    • Administrateur Kubernetes Engine (roles/container.admin)
    • Administrateur de Compute (roles/compute.admin)
    • Administrateur de l'espace de stockage (roles/storage.admin)
    • Administrateur de projet IAM (roles/resourcemanager.projectIamAdmin)
    • Administrateur de compte de service (roles/iam.serviceAccountAdmin)
    • Utilisateur du compte de service (roles/iam.serviceAccountUser)
    • Consommateur Service Usage (roles/serviceusage.serviceUsageConsumer)
    • Administrateur des rôles (roles/iam.roleAdmin)
    • Gestionnaire de versions de secrets Secret Manager (roles/secretmanager.secretVersionManager)

Choisir une option de consommation et obtenir de la capacité

  1. Sélectionnez une option de consommation. Faites votre choix en fonction de la manière dont vous souhaitez obtenir et utiliser les ressources GPU. Pour en savoir plus, consultez Choisir une option de consommation.

    Pour GKE, tenez compte des informations supplémentaires suivantes lorsque vous choisissez une option d'utilisation :

  2. Obtenez de la capacité. La procédure d'obtention de la capacité diffère pour chaque option de consommation.

    Pour en savoir plus sur le processus de l'option de consommation choisie, consultez Présentation de la capacité.

Conditions requises

Les exigences suivantes s'appliquent à un cluster GKE optimisé par l'IA :

  • Pour A4X, assurez-vous d'utiliser la version 1.33.4-gke.1036000 ou ultérieure de GKE pour la version 1.33 ou ultérieure. Pour la version 1.32, utilisez GKE version 1.32.8-gke.1108000 ou ultérieure. Ces versions garantissent qu'A4X utilise les éléments suivants :

    • R580, la version minimale du pilote GPU pour A4X.
    • Coherent Driver-based Memory Management (CDMM), qui est activé par défaut. NVIDIA recommande aux clusters Kubernetes d'activer ce mode pour résoudre les problèmes de surdéclaration de mémoire. CDMM permet de gérer la mémoire GPU via le pilote au lieu du système d'exploitation. Cette approche vous aide à éviter la mise en ligne de la mémoire GPU par l'OS et expose la mémoire GPU en tant que nœud NUMA (Non-Uniform Memory Access) à l'OS. Les GPU multi-instances ne sont pas compatibles lorsque CDMM est activé. Pour en savoir plus sur CDMM, consultez Assistance matérielle et logicielle.
    • GPUDirect RDMA, qui est recommandé pour permettre aux pools de nœuds A4X d'utiliser les fonctionnalités réseau d'A4X.

  • Assurez-vous d'utiliser la version minimale du pilote de GPU, en fonction du type de machine :

    • A4X : les GPU GB200 des VM A4X nécessitent au minimum la version R580 du pilote GPU. Consultez les exigences concernant les versions mentionnées précédemment.
    • A4 : les GPU B200 des VM A4 nécessitent au minimum la version R570 du pilote GPU. Par défaut, GKE installe automatiquement cette version du pilote sur tous les nœuds A4 exécutant la version minimale requise pour A4, à savoir 1.32.1-gke.1729000 ou version ultérieure.
    • A3 Ultra : les GPU H200 des VM A3 Ultra nécessitent au minimum la version R550 du pilote de GPU, qui est disponible dans GKE 1.31 en tant que version latest du pilote. Pour A3 Ultra, vous devez définir gpu-driver-version=latest avec GKE 1.31. Pour GKE version 1.31.5-gke.1169000 ou ultérieure, GKE installe automatiquement les versions de pilote GPU R550 sur les nœuds A3 Ultra par défaut.

  • Pour les pools de nœuds A3 Ultra, vous devez définir le type de disque sur hyperdisk-balanced.

  • Pour utiliser GPUDirect RDMA, utilisez les versions minimales suivantes en fonction du type de machine :

    • A4X : consultez les exigences concernant la version mentionnées précédemment.
    • A4 : Utilisez la version 1.32.2-gke.1475000 ou ultérieure.
    • A3 Ultra : utilisez la version 1.31.4-gke.1183000 ou ultérieure.

  • Pour utiliser GPUDirect RDMA, les nœuds GKE doivent utiliser une image de nœud Container-Optimized OS. Les images de nœuds Ubuntu et Windows ne sont pas acceptées.

  • Vous devez utiliser le modèle de provisionnement lié à la réservation pour créer des clusters avec A4X. Les autres modèles de provisionnement ne sont pas acceptés.

Créer un cluster

Suivez les instructions ci-dessous pour créer un cluster à l'aide de Cluster Toolkit ou de XPK.

Créer un cluster à l'aide de Cluster Toolkit

Cette section vous guide dans la création du cluster. Elle vous permet de vous assurer que votre projet respecte les bonnes pratiques et répond aux exigences d'un cluster GKE optimisé pour l'IA.

A4X

  1. Lancez Cloud Shell. Vous pouvez utiliser un autre environnement, mais nous vous recommandons Cloud Shell, car les dépendances sont déjà préinstallées pour Cluster Toolkit. Si vous ne souhaitez pas utiliser Cloud Shell, suivez les instructions pour installer les dépendances afin de préparer un autre environnement.

  2. Clonez Cluster Toolkit à partir du dépôt Git :

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

  3. Installez Cluster Toolkit :

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

  4. Créez un bucket Cloud Storage pour stocker l'état du déploiement 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

    Remplacez les variables suivantes :

    • BUCKET_NAME : nom du nouveau bucket Cloud Storage.
    • PROJECT_ID : ID de votre projet Google Cloud .
    • COMPUTE_REGION_TERRAFORM_STATE : région de calcul dans laquelle vous souhaitez stocker l'état du déploiement Terraform.

  5. Dans le plan examples/gke-a4x/gke-a4x-deployment.yaml du dépôt GitHub, renseignez les paramètres suivants dans les sections terraform_backend_defaults et vars pour qu'ils correspondent aux valeurs spécifiques de votre déploiement :

    • DEPLOYMENT_NAME : nom unique du déploiement, qui doit comporter entre 6 et 30 caractères. Si le nom du déploiement n'est pas unique dans un projet, la création du cluster échoue. La valeur par défaut est gke-a4x.
    • BUCKET_NAME : nom du bucket Cloud Storage que vous avez créé à l'étape précédente.
    • PROJECT_ID : ID de votre projet Google Cloud .
    • COMPUTE_REGION : région de calcul du cluster.
    • COMPUTE_ZONE : zone de calcul pour le pool de nœuds de machines A4X. Notez que cette zone doit correspondre à celle dans laquelle les machines sont disponibles dans votre réservation.
    • NODE_COUNT : nombre de nœuds A4X dans le pool de nœuds de votre cluster, qui doit être inférieur ou égal à 18. Nous vous recommandons d'utiliser 18 nœuds pour obtenir la topologie GPU 1x72 dans un sous-bloc à l'aide d'un domaine NVLink.
    • IP_ADDRESS/SUFFIX : plage d'adresses IP que vous souhaitez autoriser à se connecter au cluster. Ce bloc CIDR doit inclure l'adresse IP de la machine que vous souhaitez utiliser pour appeler Terraform. Pour en savoir plus, consultez Fonctionnement des réseaux autorisés.

    • Pour le champ extended_reservation, utilisez l'une des valeurs suivantes, selon que vous souhaitez cibler des blocs spécifiques dans une réservation lors du provisionnement du pool de nœuds :

      • Pour placer le pool de nœuds n'importe où dans la réservation, indiquez le nom de votre réservation (RESERVATION_NAME).

      • Pour cibler un bloc spécifique dans votre réservation, utilisez les noms de réservation et de bloc au format suivant :

        RESERVATION_NAME/reservationBlocks/BLOCK_NAME

      Si vous ne savez pas quels blocs sont disponibles dans votre réservation, consultez Afficher la topologie d'une réservation.

    • Définissez la taille des disque de démarrage pour chaque nœud du système et des pools de nœuds A4X. La taille du disque dont vous avez besoin dépend de votre cas d'utilisation. Par exemple, si vous utilisez le disque comme cache pour réduire la latence de l'extraction répétée d'une image, vous pouvez définir une taille de disque plus grande pour l'adapter à votre framework, modèle ou image de conteneur :

      • SYSTEM_NODE_POOL_DISK_SIZE_GB : taille du disque de démarrage pour chaque nœud du pool de nœuds système. La taille de disque minimale autorisée est de 10. La valeur par défaut est 200.
      • A4X_NODE_POOL_DISK_SIZE_GB : taille du disque de démarrage pour chaque nœud du pool de nœuds A4X. La taille de disque minimale autorisée est de 10. La valeur par défaut est 100.

    Pour modifier les paramètres avancés, modifiez le fichier examples/gke-a4x/gke-a4x.yaml.

  6. Vous pouvez également activer le Cluster Health Scanner (CHS) sur le cluster. CHS vérifie l'état de vos clusters de GPU en exécutant des tests pour s'assurer qu'ils sont prêts à exécuter vos charges de travail. Pour activer CHS, apportez les modifications suivantes dans le fichier examples/gke-a4x/gke-a4x-deployment.yaml :

    • Dans le bloc vars, définissez le champ enable_periodic_health_checks sur true.

    • Par défaut, les vérifications de l'état s'exécutent tous les dimanches à minuit (PST). Si vous souhaitez modifier ce paramètre, définissez le champ health_check_schedule sur une valeur appropriée au format cron dans le bloc vars.
      Planifier au format 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. Générez des identifiants par défaut de l'application (ADC) pour fournir un accès à Terraform. Si vous utilisez Cloud Shell, vous pouvez exécuter la commande suivante :

    gcloud auth application-default login

  8. Déployez le plan pour provisionner l'infrastructure GKE à l'aide des types de machines A4X :

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

  9. Lorsque vous y êtes invité, sélectionnez (A)pply (Appliquer) pour déployer le plan.

    • Le plan crée des réseaux VPC, un réseau VPC RDMA GPU, des comptes de service, un cluster et un pool de nœuds.
    • Pour prendre en charge le modèle de job fio-bench-job-template dans le blueprint, des ressources de bucketsGoogle Cloud , de stockage réseau et de volumes persistants sont créées.

A4

  1. Lancez Cloud Shell. Vous pouvez utiliser un autre environnement, mais nous vous recommandons Cloud Shell, car les dépendances sont déjà préinstallées pour Cluster Toolkit. Si vous ne souhaitez pas utiliser Cloud Shell, suivez les instructions pour installer les dépendances afin de préparer un autre environnement.

  2. Clonez Cluster Toolkit à partir du dépôt Git :

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

  3. Installez Cluster Toolkit :

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

  4. Créez un bucket Cloud Storage pour stocker l'état du déploiement 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

    Remplacez les variables suivantes :

    • BUCKET_NAME : nom du nouveau bucket Cloud Storage.
    • PROJECT_ID : ID de votre projet Google Cloud .
    • COMPUTE_REGION_TERRAFORM_STATE : région de calcul dans laquelle vous souhaitez stocker l'état du déploiement Terraform.

  5. Les fichiers que vous devez modifier pour créer un cluster dépendent de l'option de consommation que vous utilisez pour votre déploiement. Sélectionnez l'onglet correspondant au modèle de provisionnement de votre option de consommation.

    Lié à la réservation

    Dans le plan examples/gke-a4/gke-a4-deployment.yaml du dépôt GitHub, renseignez les paramètres suivants dans les sections terraform_backend_defaults et vars pour qu'ils correspondent aux valeurs spécifiques de votre déploiement :

    • DEPLOYMENT_NAME : nom unique du déploiement, qui doit comporter entre 6 et 30 caractères. Si le nom du déploiement n'est pas unique dans un projet, la création du cluster échoue. La valeur par défaut est gke-a4.
    • BUCKET_NAME : nom du bucket Cloud Storage que vous avez créé à l'étape précédente.
    • PROJECT_ID : ID de votre projet Google Cloud .
    • COMPUTE_REGION : région de calcul du cluster.
    • COMPUTE_ZONE : zone de calcul pour le pool de nœuds de machines A4. Notez que cette zone doit correspondre à celle dans laquelle les machines sont disponibles dans votre réservation.
    • NODE_COUNT : nombre de nœuds A4 dans votre cluster.
    • IP_ADDRESS/SUFFIX : plage d'adresses IP autorisées à se connecter au cluster. Ce bloc CIDR doit inclure l'adresse IP de la machine que vous souhaitez utiliser pour appeler Terraform. Pour en savoir plus, consultez Fonctionnement des réseaux autorisés.

    • Pour le champ reservation, utilisez l'une des valeurs suivantes, selon que vous souhaitez cibler des blocs spécifiques dans une réservation lors du provisionnement du pool de nœuds :

      • Pour placer le pool de nœuds n'importe où dans la réservation, indiquez le nom de votre réservation (RESERVATION_NAME).

      • Pour cibler un bloc spécifique dans votre réservation, utilisez les noms de réservation et de bloc au format suivant :

        RESERVATION_NAME/reservationBlocks/BLOCK_NAME

      Si vous ne savez pas quels blocs sont disponibles dans votre réservation, consultez Afficher la topologie d'une réservation.

    • Définissez la taille des disque de démarrage pour chaque nœud du système et des pools de nœuds A4. La taille du disque dont vous avez besoin dépend de votre cas d'utilisation. Par exemple, si vous utilisez le disque comme cache pour réduire la latence de l'extraction répétée d'une image, vous pouvez définir une taille de disque plus grande pour l'adapter à votre framework, modèle ou image de conteneur :

      • SYSTEM_NODE_POOL_DISK_SIZE_GB : taille du disque de démarrage pour chaque nœud du pool de nœuds système. La taille de disque minimale autorisée est de 10. La valeur par défaut est 100.
      • A4_NODE_POOL_DISK_SIZE_GB : taille du disque de démarrage pour chaque nœud du pool de nœuds A4. La taille de disque minimale autorisée est de 10. La valeur par défaut est 100.

    Pour modifier les paramètres avancés, modifiez examples/gke-a4/gke-a4.yaml.

    Démarrage flexible

    1. Dans le plan examples/gke-a4/gke-a4-deployment.yaml du dépôt GitHub, renseignez les paramètres suivants dans les sections terraform_backend_defaults et vars pour qu'ils correspondent aux valeurs spécifiques de votre déploiement :

      • DEPLOYMENT_NAME : nom unique du déploiement, qui doit comporter entre 6 et 30 caractères. Si le nom du déploiement n'est pas unique dans un projet, la création du cluster échoue. La valeur par défaut est gke-a4.
      • BUCKET_NAME : nom du bucket Cloud Storage que vous avez créé à l'étape précédente.
      • PROJECT_ID : ID de votre projet Google Cloud .
      • COMPUTE_REGION : région de calcul du cluster.
      • COMPUTE_ZONE : zone de calcul pour le pool de nœuds de machines A4.
      • Supprimez static_node_count.
      • IP_ADDRESS/SUFFIX : plage d'adresses IP autorisées à se connecter au cluster. Ce bloc CIDR doit inclure l'adresse IP de la machine que vous souhaitez utiliser pour appeler Terraform. Pour en savoir plus, consultez Fonctionnement des réseaux autorisés.
      • Supprimez le champ reservation et remplacez-le par enable_flex_start: true. Sur la ligne suivante, ajoutez enable_queued_provisioning: true si vous souhaitez également utiliser le provisionnement mis en file d'attente. Pour en savoir plus, consultez Utiliser des pools de nœuds avec démarrage flexible et provisionnement en file d'attente.

      • Définissez la taille des disque de démarrage pour chaque nœud du système et des pools de nœuds A4. La taille du disque dont vous avez besoin dépend de votre cas d'utilisation. Par exemple, si vous utilisez le disque comme cache pour réduire la latence de l'extraction répétée d'une image, vous pouvez définir une taille de disque plus grande pour l'adapter à votre framework, modèle ou image de conteneur :

        • SYSTEM_NODE_POOL_DISK_SIZE_GB : taille du disque de démarrage pour chaque nœud du pool de nœuds système. La taille de disque minimale autorisée est de 10. La valeur par défaut est 100.
        • A4_NODE_POOL_DISK_SIZE_GB : taille du disque de démarrage pour chaque nœud du pool de nœuds A4. La taille de disque minimale autorisée est de 10. La valeur par défaut est 100.

    2. Dans le plan examples/gke-a4/gke-a4.yaml du dépôt GitHub, apportez les modifications suivantes :

      • Dans le bloc vars, supprimez static_node_count.
      • Dans le bloc vars, assurez-vous que le numéro version_prefix est "1.32." ou supérieur. Pour utiliser le démarrage flexible dans GKE, votre cluster doit utiliser la version 1.32.2-gke.1652000 ou ultérieure.
      • Dans le bloc vars, remplacez l'intégralité du bloc reservation (y compris la ligne reservation elle-même) par enable_flex_start: true et, éventuellement, enable_queued_provisioning: true.
      • Dans le bloc vars, si vous n'avez pas besoin de l'approvisionnement mis en file d'attente, supprimez la ligne suivante : kueue_configuration_path: $(ghpc_stage("./kueue-configuration.yaml.tftpl")).
      • Sous id: a4-pool, supprimez la ligne suivante : static_node_count: $(vars.static_node_count).

      • Sous id: a4-pool, supprimez le bloc reservation_affinity. Remplacez ce bloc par les lignes suivantes :

        • enable_flex_start: $(vars.enable_flex_start)
        • auto_repair: false
        • Pour le provisionnement en file d'attente, si vous souhaitez l'activer, ajoutez les lignes supplémentaires suivantes :
          • enable_queued_provisioning: $(vars.enable_queued_provisioning)
          • autoscaling_total_min_nodes: 0

      • Sous id: workload-manager-install, supprimez le bloc suivant :

         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)

        • Pour le démarrage flexible avec provisionnement en file d'attente, procédez comme suit :

          1. Ajoutez gpu_nominal_quota: NOMINAL_QUOTA au bloc vars. La valeur gpu_nominal_quota est utilisée pour définir le nominalQuota des GPU dans la spécification ClusterQueue (voir l'étape de définition de ClusterQueue ci-dessous). Dans cet exemple, ClusterQueue n'accepte les charges de travail que si la somme des demandes de GPU est inférieure ou égale à la valeur NOMINAL_QUOTA. Pour en savoir plus sur ClusterQueue, consultez la documentation Kueue sur la file d'attente de cluster.

          2. Mettez à jour le bloc kueue comme suit :

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

          3. Remplacez le contenu du fichier kueue-configuration.yaml.tftpl par le code suivant :

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

      • Sous id: job-template, remplacez la variable node_count par 2.

    Spot

    1. Dans le plan examples/gke-a4/gke-a4-deployment.yaml du dépôt GitHub, renseignez les paramètres suivants dans les sections terraform_backend_defaults et vars pour qu'ils correspondent aux valeurs spécifiques de votre déploiement :

      • DEPLOYMENT_NAME : nom unique du déploiement, qui doit comporter entre 6 et 30 caractères. Si le nom du déploiement n'est pas unique dans un projet, la création du cluster échoue. La valeur par défaut est gke-a4.
      • BUCKET_NAME : nom du bucket Cloud Storage que vous avez créé à l'étape précédente.
      • PROJECT_ID : ID de votre projet Google Cloud .
      • COMPUTE_REGION : région de calcul du cluster.
      • COMPUTE_ZONE : zone de calcul pour le pool de nœuds de machines A4.
      • STATIC_NODE_COUNT : nombre de nœuds A4 dans votre cluster.
      • IP_ADDRESS/SUFFIX : plage d'adresses IP autorisées à se connecter au cluster. Ce bloc CIDR doit inclure l'adresse IP de la machine que vous souhaitez utiliser pour appeler Terraform. Pour en savoir plus, consultez Fonctionnement des réseaux autorisés.
      • Remplacez l'intégralité du bloc reservation (y compris la ligne reservation elle-même) par spot: true.

      • Définissez la taille des disque de démarrage pour chaque nœud du système et des pools de nœuds A4. La taille du disque dont vous avez besoin dépend de votre cas d'utilisation. Par exemple, si vous utilisez le disque comme cache pour réduire la latence de l'extraction répétée d'une image, vous pouvez définir une taille de disque plus grande pour l'adapter à votre framework, modèle ou image de conteneur :

        • SYSTEM_NODE_POOL_DISK_SIZE_GB : taille du disque de démarrage pour chaque nœud du pool de nœuds système. La taille de disque minimale autorisée est de 10. La valeur par défaut est 100.
        • A4_NODE_POOL_DISK_SIZE_GB : taille du disque de démarrage pour chaque nœud du pool de nœuds A4. La taille de disque minimale autorisée est de 10. La valeur par défaut est 100.

    2. Dans le plan examples/gke-a4/gke-a4.yaml du dépôt GitHub, apportez les modifications suivantes :

      • Dans le bloc vars, remplacez l'intégralité du bloc reservation (y compris la ligne reservation elle-même) par spot: true.

      • Sous id: a4-pool, supprimez le bloc reservation_affinity. Remplacez ce bloc par la ligne suivante :

        • spot: $(vars.spot)

  6. Vous pouvez également activer le Cluster Health Scanner (CHS) sur le cluster. CHS vérifie l'état de vos clusters de GPU en exécutant des tests pour s'assurer qu'ils sont prêts à exécuter vos charges de travail. Pour activer CHS, apportez les modifications suivantes dans le fichier examples/gke-a4/gke-a4-deployment.yaml :

    • Dans le bloc vars, définissez le champ enable_periodic_health_checks sur true.

    • Par défaut, les vérifications de l'état s'exécutent tous les dimanches à minuit (PST). Si vous souhaitez modifier ce paramètre, définissez le champ health_check_schedule sur une valeur appropriée au format cron dans le bloc vars.
      Planifier au format 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. Générez des identifiants par défaut de l'application (ADC) pour fournir un accès à Terraform. Si vous utilisez Cloud Shell, vous pouvez exécuter la commande suivante :

    gcloud auth application-default login

  8. Déployez le plan pour provisionner l'infrastructure GKE à l'aide des types de machines A4 :

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

  9. Lorsque vous y êtes invité, sélectionnez (A)pply (Appliquer) pour déployer le plan.

    • Le plan crée des réseaux VPC, un réseau VPC RDMA GPU, des comptes de service, un cluster et un pool de nœuds.
    • Pour prendre en charge le modèle de job fio-bench-job-template dans le blueprint, des ressources de bucketsGoogle Cloud , de stockage réseau et de volumes persistants sont créées.

A3 Ultra

  1. Lancez Cloud Shell. Vous pouvez utiliser un autre environnement, mais nous vous recommandons Cloud Shell, car les dépendances sont déjà préinstallées pour Cluster Toolkit. Si vous ne souhaitez pas utiliser Cloud Shell, suivez les instructions pour installer les dépendances afin de préparer un autre environnement.

  2. Clonez Cluster Toolkit à partir du dépôt Git :

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

  3. Installez Cluster Toolkit :

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

  4. Créez un bucket Cloud Storage pour stocker l'état du déploiement 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

    Remplacez les variables suivantes :

    • BUCKET_NAME : nom du nouveau bucket Cloud Storage.
    • PROJECT_ID : ID de votre projet Google Cloud .
    • COMPUTE_REGION_TERRAFORM_STATE : région de calcul dans laquelle vous souhaitez stocker l'état du déploiement Terraform.

  5. Les fichiers que vous devez modifier pour créer un cluster dépendent de l'option de consommation que vous utilisez pour votre déploiement. Sélectionnez l'onglet correspondant au modèle de provisionnement de votre option de consommation.

    Lié à la réservation

    Dans le plan examples/gke-a3-ultragpu/gke-a3-ultragpu-deployment.yaml du dépôt GitHub, remplacez les variables suivantes dans les sections terraform_backend_defaults et vars pour qu'elles correspondent aux valeurs spécifiques de votre déploiement :

    • DEPLOYMENT_NAME : nom unique du déploiement, qui doit comporter entre 6 et 30 caractères. Si le nom du déploiement n'est pas unique dans un projet, la création du cluster échoue.
    • BUCKET_NAME : nom du bucket Cloud Storage que vous avez créé à l'étape précédente.
    • PROJECT_ID : ID de votre projet Google Cloud .
    • COMPUTE_REGION : région de calcul du cluster.
    • COMPUTE_ZONE : zone de calcul pour le pool de nœuds de machines A3 Ultra. Notez que cette zone doit correspondre à celle dans laquelle les machines sont disponibles dans votre réservation.
    • NODE_COUNT : nombre de nœuds A3 Ultra dans votre cluster.
    • IP_ADDRESS/SUFFIX : plage d'adresses IP autorisées à se connecter au cluster. Ce bloc CIDR doit inclure l'adresse IP de la machine que vous souhaitez utiliser pour appeler Terraform. Pour en savoir plus, consultez Fonctionnement des réseaux autorisés.

    • Pour le champ reservation, utilisez l'une des valeurs suivantes, selon que vous souhaitez cibler des blocs spécifiques dans une réservation lors du provisionnement du pool de nœuds :

      • Pour placer le pool de nœuds n'importe où dans la réservation, indiquez le nom de votre réservation (RESERVATION_NAME).

      • Pour cibler un bloc spécifique dans votre réservation, utilisez les noms de réservation et de bloc au format suivant :

        RESERVATION_NAME/reservationBlocks/BLOCK_NAME

      Si vous ne savez pas quels blocs sont disponibles dans votre réservation, consultez Afficher la topologie d'une réservation.

    • Définissez la taille du disque de démarrage pour chaque nœud du système et des pools de nœuds A3 Ultra. La taille du disque dont vous avez besoin dépend de votre cas d'utilisation. Par exemple, si vous utilisez le disque comme cache pour réduire la latence de l'extraction répétée d'une image, vous pouvez définir une taille de disque plus grande pour l'adapter à votre framework, modèle ou image de conteneur :

      • SYSTEM_NODE_POOL_DISK_SIZE_GB : taille du disque de démarrage pour chaque nœud du pool de nœuds système. La taille de disque minimale autorisée est de 10. La valeur par défaut est 100.
      • A3ULTRA_NODE_POOL_DISK_SIZE_GB : taille du disque de démarrage pour chaque nœud du pool de nœuds A3 Ultra. La taille de disque minimale autorisée est de 10. La valeur par défaut est 100.

    Pour modifier les paramètres avancés, modifiez examples/gke-a3-ultragpu/gke-a3-ultragpu.yaml.

    Démarrage flexible

    1. Dans le plan examples/gke-a3-ultragpu/gke-a3-ultragpu-deployment.yaml du dépôt GitHub, remplacez les variables suivantes dans les sections terraform_backend_defaults et vars pour qu'elles correspondent aux valeurs spécifiques de votre déploiement :

      • DEPLOYMENT_NAME : nom unique du déploiement, qui doit comporter entre 6 et 30 caractères. Si le nom du déploiement n'est pas unique dans un projet, la création du cluster échoue.
      • BUCKET_NAME : nom du bucket Cloud Storage que vous avez créé à l'étape précédente.
      • PROJECT_ID : ID de votre projet Google Cloud .
      • COMPUTE_REGION : région de calcul du cluster.
      • COMPUTE_ZONE : zone de calcul pour le pool de nœuds de machines A3 Ultra.
      • Supprimez static_node_count.
      • IP_ADDRESS/SUFFIX : plage d'adresses IP autorisées à se connecter au cluster. Ce bloc CIDR doit inclure l'adresse IP de la machine que vous souhaitez utiliser pour appeler Terraform. Pour en savoir plus, consultez Fonctionnement des réseaux autorisés.
      • Supprimez le champ reservation et remplacez-le par enable_flex_start: true. Sur la ligne suivante, ajoutez enable_queued_provisioning: true si vous souhaitez également utiliser le provisionnement mis en file d'attente. Pour en savoir plus, consultez Utiliser des pools de nœuds avec démarrage flexible et provisionnement en file d'attente.

      • Définissez la taille du disque de démarrage pour chaque nœud du système et des pools de nœuds A3 Ultra. La taille du disque dont vous avez besoin dépend de votre cas d'utilisation. Par exemple, si vous utilisez le disque comme cache pour réduire la latence de l'extraction répétée d'une image, vous pouvez définir une taille de disque plus grande pour l'adapter à votre framework, modèle ou image de conteneur :

        • SYSTEM_NODE_POOL_DISK_SIZE_GB : taille du disque de démarrage pour chaque nœud du pool de nœuds système. La taille de disque minimale autorisée est de 10. La valeur par défaut est 100.
        • A3ULTRA_NODE_POOL_DISK_SIZE_GB : taille du disque de démarrage pour chaque nœud du pool de nœuds A3 Ultra. La taille de disque minimale autorisée est de 10. La valeur par défaut est 100.

    2. Dans le plan examples/gke-a3-ultragpu/gke-a3-ultragpu.yaml du dépôt GitHub, apportez les modifications suivantes :

      • Dans le bloc vars, supprimez static_node_count.
      • Dans le bloc vars, remplacez le nombre version_prefix par "1.32." ou une valeur supérieure. Pour utiliser le démarrage flexible dans GKE, votre cluster doit utiliser la version 1.32.2-gke.1652000 ou ultérieure.
      • Dans le bloc vars, remplacez l'intégralité du bloc reservation (y compris la ligne reservation elle-même) par enable_flex_start: true et, éventuellement, enable_queued_provisioning: true.
      • Dans le bloc vars, supprimez la ligne suivante : kueue_configuration_path: $(ghpc_stage("./kueue-configuration.yaml.tftpl")).
      • Sous id: a3-ultragpu-pool, supprimez la ligne suivante : static_node_count: $(vars.static_node_count).

      • Sous id: a3-ultragpu-pool, supprimez le bloc reservation_affinity. Remplacez ce bloc par les lignes suivantes :

        • enable_flex_start: $(vars.enable_flex_start)
        • auto_repair: false
        • Pour le provisionnement en file d'attente, si vous souhaitez l'activer, ajoutez les lignes supplémentaires suivantes :
          • enable_queued_provisioning: $(vars.enable_queued_provisioning)
          • autoscaling_total_min_nodes: 0

      • Sous id: workload-manager-install, supprimez le bloc suivant :

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

        • Pour le démarrage flexible avec provisionnement en file d'attente, suivez ces trois étapes :

          1. Ajoutez gpu_nominal_quota: NOMINAL_QUOTA au bloc vars. La valeur gpu_nominal_quota est utilisée pour définir le nominalQuota des GPU dans la spécification ClusterQueue. Dans cet exemple, ClusterQueue n'accepte les charges de travail que si la somme des requêtes GPU est inférieure ou égale à la valeur NOMINAL_QUOTA. Pour en savoir plus sur ClusterQueue, consultez la documentation Kueue sur la file d'attente de cluster.

          2. Mettez à jour le bloc kueue comme suit :

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

          3. Remplacez le contenu du fichier kueue-configuration.yaml.tftpl par le code suivant :

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

        • Dans le champ id: job-template, remplacez la variable node_count par 2.

    Spot

    1. Dans le plan examples/gke-a3-ultragpu/gke-a3-ultragpu-deployment.yaml du dépôt GitHub, renseignez les paramètres suivants dans les sections terraform_backend_defaults et vars pour qu'ils correspondent aux valeurs spécifiques de votre déploiement :

      • DEPLOYMENT_NAME : nom unique du déploiement, qui doit comporter entre 6 et 30 caractères. Si le nom du déploiement n'est pas unique dans un projet, la création du cluster échoue.
      • BUCKET_NAME : nom du bucket Cloud Storage que vous avez créé à l'étape précédente.
      • PROJECT_ID : ID de votre projet Google Cloud .
      • COMPUTE_REGION : région de calcul du cluster.
      • COMPUTE_ZONE : zone de calcul pour le pool de nœuds de machines A3 Ultra.
      • STATIC_NODE_COUNT : nombre de nœuds A3 Ultra dans votre cluster.
      • IP_ADDRESS/SUFFIX : plage d'adresses IP autorisées à se connecter au cluster. Ce bloc CIDR doit inclure l'adresse IP de la machine que vous souhaitez utiliser pour appeler Terraform. Pour en savoir plus, consultez Fonctionnement des réseaux autorisés.
      • Remplacez l'intégralité du bloc reservation (y compris la ligne reservation elle-même) par spot: true.

      • Définissez la taille du disque de démarrage pour chaque nœud du système et des pools de nœuds A3 Ultra. La taille du disque dont vous avez besoin dépend de votre cas d'utilisation. Par exemple, si vous utilisez le disque comme cache pour réduire la latence de l'extraction répétée d'une image, vous pouvez définir une taille de disque plus grande pour l'adapter à votre framework, modèle ou image de conteneur :

        • SYSTEM_NODE_POOL_DISK_SIZE_GB : taille du disque de démarrage pour chaque nœud du pool de nœuds système. La taille de disque minimale autorisée est de 10. La valeur par défaut est 100.
        • A3ULTRA_NODE_POOL_DISK_SIZE_GB : taille du disque de démarrage pour chaque nœud du pool de nœuds A3 Ultra. La taille de disque minimale autorisée est de 10. La valeur par défaut est 100.

    2. Dans le plan examples/gke-a3-ultragpu/gke-a3-ultragpu.yaml du dépôt GitHub, apportez les modifications suivantes :

      • Dans le bloc vars, remplacez l'intégralité du bloc reservation (y compris la ligne reservation elle-même) par spot: true.

      • Sous id: a3-ultragpu-pool, supprimez le bloc reservation_affinity. Remplacez ce bloc par la ligne suivante :

        • spot: $(vars.spot)

  6. Vous pouvez également activer le Cluster Health Scanner (CHS) sur le cluster. CHS vérifie l'état de vos clusters de GPU en exécutant des tests pour s'assurer qu'ils sont prêts à exécuter vos charges de travail. Pour activer CHS, apportez les modifications suivantes dans le fichier examples/gke-a3-ultragpu/gke-a3-ultragpu-deployment.yaml :

    • Dans le bloc vars, définissez le champ enable_periodic_health_checks sur true.

    • Par défaut, les vérifications de l'état s'exécutent tous les dimanches à minuit (PST). Si vous souhaitez modifier ce paramètre, définissez le champ health_check_schedule sur une valeur appropriée au format cron dans le bloc vars.
      Planifier au format 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. Générez des identifiants par défaut de l'application (ADC) pour fournir l'accès à Terraform. Si vous utilisez Cloud Shell, vous pouvez exécuter la commande suivante :

    gcloud auth application-default login

  8. Déployez le plan pour provisionner l'infrastructure GKE à l'aide des types de machines 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. Lorsque vous y êtes invité, sélectionnez (A)pply (Appliquer) pour déployer le plan.

    • Le plan crée des réseaux VPC, un réseau VPC RDMA GPU, des comptes de service, un cluster et un pool de nœuds.
    • Pour prendre en charge le modèle de job fio-bench-job-template dans le blueprint, des ressources de bucketsGoogle Cloud , de stockage réseau et de volumes persistants sont créées.

Créer un cluster et exécuter des charges de travail à l'aide de XPK

Le kit de traitement accéléré (XPK) vous permet de provisionner et d'utiliser rapidement des clusters. XPK génère une infrastructure préconfigurée et optimisée pour l'entraînement, idéale lorsque l'exécution de la charge de travail est votre objectif principal.

Créez un cluster et exécutez des charges de travail avec des VM A3 Ultra à l'aide de XPK :

  1. Installez les outils nécessaires pour répondre aux prérequis XPK.
  2. Copiez le numéro de version de la dernière version taguée de XPK, par exemple "v0.8.0". Dans la commande suivante, remplacez XPK_TAG par le dernier numéro de version XPK.

  3. Ouvrez une fenêtre de terminal sur une machine Linux, puis saisissez les commandes suivantes pour cloner XPK à partir du dépôt Git et installer les packages requis :

      ## 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. Créez un cluster Standard à l'aide de VM A3 Ultra. Vous pouvez provisionner les nœuds du cluster à l'aide de la capacité réservée :

      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

    Remplacez les variables suivantes :

    • CLUSTER_NAME : nom du cluster.
    • COMPUTE_ZONE : zone de calcul pour le pool de nœuds de machines A3 Ultra. Pour utiliser la capacité réservée, assurez-vous d'utiliser la zone dans laquelle vous avez réservé la capacité. En règle générale, nous vous recommandons de choisir une zone proche de l'utilisateur pour minimiser la latence.
    • PROJECT_ID : ID de votre projet Google Cloud .
    • NUM_NODES : nombre de nœuds de calcul dans le pool de nœuds.

    • RESERVATION_NAME : nom de votre réservation.

      XPK propose des arguments supplémentaires pour la création de clusters, y compris ceux permettant de créer des clusters privés, de créer des Tensorboards Vertex AI et d'utiliser l'autoprovisonnement de nœuds. Pour en savoir plus, consultez le guide de création de clusters pour XPK.

  5. Vérifiez que le cluster a bien été créé :

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

  6. Facultatif : Exécutez une charge de travail pour tester l'environnement du 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

    Remplacez les variables suivantes :

    • WORKLOAD_NAME : nom de votre charge de travail.
    • CLUSTER_NAME : nom du cluster.
    • WORKLOAD_NUM_NODES : nombre de nœuds de calcul utilisés pour l'exécution de la charge de travail.
    • COMPUTE_ZONE : zone de calcul pour le pool de nœuds de machines A3 Ultra.
    • PROJECT_ID : ID de votre projet Google Cloud .

Tester les performances du réseau

Nous vous recommandons de valider le fonctionnement des clusters provisionnés. Pour ce faire, utilisez les tests NCCL/gIB, qui sont des tests NVIDIA Collective Communications Library (NCCL) optimisés pour l'environnement Google.

Exécuter des benchmarks reproductibles

Vous pouvez utiliser des benchmarks de pré-entraînement pour reproduire de grands modèles de machine learning open source sur des VM A4 et A3 Ultra sur GKE.

Chaque recette vous fournit les instructions pour effectuer les tâches suivantes :

  • Préparez votre environnement.
  • Exécutez le benchmark.
  • Analysez les résultats des benchmarks. Cela inclut les résultats des benchmarks et les journaux détaillés pour une analyse plus approfondie.

Pour afficher toutes les recettes disponibles, consultez le dépôt GitHub GPU recipes.

Modèles Framework Recette
Llama-3.1-70B MaxText Charge de travail de 32 nœuds
Llama-3.1-70B NeMo Charge de travail de 32 nœuds
Mixtral-8-7B NeMo Charge de travail de 32 nœuds

Nettoyer les ressources créées par Cluster Toolkit

Pour éviter les frais récurrents pour les ressources utilisées sur cette page, nettoyez les ressources provisionnées par Cluster Toolkit, y compris les réseaux VPC et le cluster GKE :

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

Remplacez CLUSTER_NAME par le nom de votre cluster. Pour les clusters créés avec Cluster Toolkit, le nom du cluster est basé sur DEPLOYMENT_NAME.

Étapes suivantes