Créer un cluster GKE A3 Edge personnalisé optimisé pour l'IA

Cette page vous explique comment créer un cluster Google Kubernetes Engine (GKE) optimisé pour l'IA qui utilise des machines virtuelles (VM) A3 Edge pour prendre en charge vos charges de travail d'intelligence artificielle (IA) et de machine learning (ML). Les machines A3 Edge sont conçues pour vous permettre d'exécuter des clusters d'IA et de ML à grande échelle à l'aide de fonctionnalités telles que le placement ciblé des charges de travail, le placement compact, des contrôles avancés de maintenance des clusters et TAS. 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 pour vos organisations, ce qui réduit la charge opérationnelle liée à la gestion de plusieurs plates-formes. Vous pouvez exécuter des charges de travail telles que le pré-entraînement distribué hautes performances, l'affinage de modèles, l'inférence de modèles, la diffusion d'applications et les services associés.

Cette page explique comment créer des clusters Google Kubernetes Engine (GKE) Standard et Autopilot à l'aide de GPUDirect-TCPX, gVNIC et du multiréseau.

Cette page est destinée aux ingénieurs en machine learning (ML) et aux administrateurs de plate-forme qui facilitent les charges de travail de ML. Pour en savoir plus sur les rôles courants et les exemples de tâches que nous citons dans le contenu Google Cloud , consultez Rôles utilisateur et tâches courantes de GKE.

Les applications d'intelligence artificielle (IA), de ML et de calcul hautes performances (HPC) nécessitent une accélération puissante pour optimiser les performances en réduisant les délais d'exécution des tâches. Par exemple, les modèles de ML axés sur l'IA conversationnelle et la génération d'images nécessitent une évolutivité et une puissance de calcul élevées.

Cette page suppose que vous connaissez les technologies de mise en réseau telles que les cartes d'interface réseau (NIC) et TCP, ainsi que les technologies d'accélération telles que la bibliothèque NVIDIA Collective Communications Library (NCCL).

À propos des superordinateurs sur GPU Google Cloud

Google Cloud dispose de superordinateurs optimisés pour les accélérateurs, conçus pour des modèles massifs et évolutifs. Ces types de machines GPU peuvent obtenir jusqu'à 3 600 Gbit/s de bande passante réseau.

Votre charge de travail GKE doit utiliser tous les GPU et toutes les cartes d'interface réseau secondaires disponibles sur un seul nœud, et utiliser une part importante de la bande passante disponible. La solution décrite dans ce document est conçue pour les charges de travail qui nécessitent de hautes performances, un débit élevé et une faible latence.

Fonctionnalités et capacités requises pour une bande passante maximale

Pour optimiser la bande passante de votre réseau dans les nœuds GPU de supercalculateur, vous devez utiliser les fonctionnalités suivantes :

  • Pile réseau GPUDirect : A3 Edge est compatible avec trois piles réseau pour l'accès à la mémoire directe distante (RDMA) personnalisée. Les machines A3 Edge utilisent GPUDirect-TCPX pour réduire la surcharge requise pour transférer les charges utiles de paquets vers et depuis les GPU, ce qui améliore considérablement le débit à grande échelle par rapport aux GPU qui n'utilisent pas GPUDirect.
  • gVNIC : activez les fonctionnalités GPUDirect telles que la division de l'en-tête du paquet, l'orientation du flux et la gestion de la mémoire tampon. gVNIC est requis pour utiliser GPUDirect-TCPX. Pour en savoir plus sur gVNIC, consultez la section Augmenter la vitesse de trafic réseau pour les nœuds GPU.

Vous devez également activer et configurer les fonctionnalités suivantes :

  • Multiréseau : ajoutez des cartes d'interface réseau secondaires à la machine optimisée pour les accélérateurs. Pour éviter les conflits, chaque carte d'interface réseau est associée à un sous-réseau distinct de son propre VPC. Pour en savoir plus sur la compatibilité multiréseau, consultez la section Configurer la compatibilité multiréseau pour les pods.
  • Stratégies d'emplacement : utilisez une règle d'emplacement des ressources pour placer tous les nœuds GPU d'une charge de travail spécifique sur des serveurs physiquement proches afin de minimiser la latence. Pour en savoir plus, consultez Définir un emplacement compact pour les nœuds GKE.

Aperçu de la procédure

Pour utiliser GPUDirect-TCPX, gVNIC, le multiréseau et les stratégies d'emplacement compact ensemble, procédez comme suit :

  1. Créer des clouds privés virtuels (VPC) et des sous-réseaux
  2. Créer l'environnement GKE
  3. Installer le binaire GPUDirect et le plug-in NCCL
  4. Déployer le plug-in NRI Device Injector
  5. Déployer une charge de travail de test pour vérifier la configuration de GPUDirect
  6. Adopter GPUDirect pour vos propres 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
  • Pour utiliser Google Cloud CLI pour cette tâche, installez puis initialisez 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.
  • Assurez-vous de disposer de la capacité associée aux VM A3 Edge. Pour obtenir cette capacité, commencez par choisir parmi les options de consommation. Pour suivre les instructions de cette page, vous pouvez utiliser la capacité à la demande, les réservations à la demande ou les réservations futures pour une durée maximale de 90 jours (en mode Agenda). Une fois que vous avez choisi une option de consommation, suivez les instructions correspondantes pour obtenir de la capacité à l'aide de l'option de consommation que vous avez choisie.
  • Assurez-vous de disposer d'un quota suffisant pour les GPU H100. Pour demander une augmentation de quota, consultez la page Quotas de GPU.

Conditions requises

Les exigences suivantes s'appliquent à GPUDirect-TCPX :

Standard

  • GPUDirect-TCPX est compatible avec toutes les versions mineures de GKE disponibles à l'aide de versions de correctif spécifiques :
    • Pour les versions 1.30 à 1.33 de GKE, utilisez n'importe quelle version de correctif.
    • Pour GKE version 1.34, utilisez la version de correctif 1.34.5-gke.1153000 ou ultérieure.
    • Pour GKE version 1.35, utilisez la version de correctif 1.35.2-gke.1485000 ou ultérieure.
    • Pour GKE version 1.36 ou ultérieure, utilisez n'importe quelle version de correctif.
  • Le nœud GKE doit utiliser une image de nœud Container-Optimized OS (COS). Les images de nœuds Ubuntu et Windows ne sont pas acceptées.
  • Vos nœuds GPU doivent utiliser le pilote NVIDIA version 535 ou ultérieure.
  • Vous devez utiliser GKE Dataplane V2.
  • Sur GKE version 1.34 et ultérieure, vous devez utiliser la version 3.1.9 ou ultérieure du programme d'installation GPUDirect-TCPX et la version 2.0.12 ou ultérieure du side-car GPUDirect-TCPX. Les versions de l'installateur et du side-car doivent correspondre. Par exemple, la version 3.1.12 de l'installateur correspond à la version 2.0.15 du side-car. Pour en savoir plus sur les versions de l'installateur et du side-car, consultez les notes de version de GPUDirect-TCPX.
  • Pour les charges de travail GPUDirect-TCPX qui s'exécutent sur plusieurs pools de nœuds, tous les pools de nœuds doivent se trouver dans les mêmes zones Compute Engine et utiliser les mêmes ensembles de réseaux, tels que les VPC et les sous-réseaux.

Autopilot

  • Pour utiliser GPUDirect-TCPX, votre cluster doit exécuter les versions de correctif GKE minimales suivantes :
    • Pour GKE version 1.31, utilisez la version de correctif 1.31.1-gke.1621000 ou ultérieure.
    • Pour les versions 1.32 à 1.33 de GKE, utilisez n'importe quelle version de correctif.
    • Pour GKE version 1.34, utilisez la version de correctif 1.34.5-gke.1153000 ou ultérieure.
    • Pour GKE version 1.35, utilisez la version de correctif 1.35.2-gke.1485000 ou ultérieure.
    • Pour GKE version 1.36 ou ultérieure, utilisez n'importe quelle version de correctif.
  • Vos nœuds GPU doivent utiliser le pilote NVIDIA version 535 ou ultérieure.
  • Vous devez utiliser GKE Dataplane V2.
  • Sur GKE version 1.34 et ultérieure, vous devez utiliser la version 3.1.9 ou ultérieure du programme d'installation GPUDirect-TCPX et la version 2.0.12 ou ultérieure du side-car GPUDirect-TCPX. Les versions de l'installateur et du side-car doivent correspondre (mappage un-à-un). Par exemple, la version 3.1.12 de l'installateur correspond à la version 2.0.15 du side-car. Pour en savoir plus sur les versions de l'installateur et du side-car, consultez les notes de version de GPUDirect-TCPX.
  • Pour les charges de travail GPUDirect-TCPX qui s'exécutent sur plusieurs pools de nœuds, tous les pools de nœuds doivent se trouver dans les mêmes zones Compute Engine et utiliser les mêmes ensembles de réseaux, tels que les VPC et les sous-réseaux.

Limites

Les limites suivantes s'appliquent :

  • GPUDirect-TCPX n'est pas compatible avec les GPU multi-instances, les GPU à temps partagé ni NVIDIA MPS.
  • Vous ne pouvez pas utiliser NCCL FastSocket avec GPUDirect-TCPX.
  • Votre charge de travail GKE doit utiliser tous les GPU et toutes les cartes d'interface réseau secondaires disponibles sur un seul nœud. Plusieurs pods ne peuvent pas utiliser GPUDirect-TCPX sur un même nœud.

Créer des VPC et des sous-réseaux

Créez des réseaux VPC distincts dans votre projet pour chaque carte d'interface réseau virtuelle que vous ajouterez à vos nœuds. Chaque réseau VPC doit comporter un sous-réseau et une règle de pare-feu autorisant le trafic réseau interne.

  1. Pour optimiser votre bande passante, nous vous recommandons de créer quatre autres réseaux.

    for N in $(seq 1 4); do
    gcloud compute networks create PREFIX-net-$N \
        --subnet-mode=custom \
        --mtu=8244
    
    gcloud compute networks subnets create PREFIX-sub-$N \
        --network=PREFIX-net-$N \
        --region=REGION \
        --range=SUBNET_RANGE
    
    gcloud compute firewall-rules create PREFIX-internal-$N \
    --network=PREFIX-net-$N \
    --action=ALLOW \
    --rules=tcp:0-65535,udp:0-65535,icmp \
    --source-ranges=SOURCE_RANGE
    done
    

    Remplacez les éléments suivants :

    • PROJECT_ID : ID de votre projet Google Cloud .
    • REGION : région Compute Engine de chaque sous-réseau.
    • SUBNET_RANGE : plage d'adresses IP de chaque sous-réseau au format CIDR. Cet exemple de commande effectue une itération pour quatre sous-réseaux. Utilisez donc une variable pour modifier l'adresse IP de chaque sous-réseau. Par exemple, spécifiez 192.168.$N.0/24 pour que le premier sous-réseau utilise 192.168.1.0/24, le second sous-réseau utilise 192.168.2.0/24, etc.
    • SOURCE_RANGE : plage d'adresses IP source de la règle de pare-feu pour autoriser le trafic entrant, au format CIDR. Exemple : 192.168.0.0/16.
  2. Vérifiez que les réseaux ont été créés :

    gcloud compute networks list
    

Créer l'environnement GKE

Créez un cluster GKE qui utilise le multiréseau (preview) et créez un pool de nœuds GPU présentant les caractéristiques suivantes :

  • gVNIC activé
  • Sous-réseaux à mise en réseau spécifiés pour chaque carte d'interface réseau secondaire
  • Série de machines A3 Edge avec GPU H100 qui sauvegardent les nœuds
  • Derniers pilotes NVIDIA installés

Vous ne pouvez pas mettre à jour un cluster existant pour utiliser le multiréseau.

  1. Créez un cluster :

    Standard

    gcloud beta container clusters create CLUSTER_NAME \
      --enable-dataplane-v2 \
      --enable-ip-alias \
      --location=CONTROL_PLANE_LOCATION \
      --enable-multi-networking \
      --cluster-version=VERSION \
      --no-enable-autoupgrade \
      --project=PROJECT_ID
    

    Remplacez les éléments suivants :

    • CLUSTER_NAME : nom de votre nouveau cluster
    • CONTROL_PLANE_LOCATION : emplacement Compute Engine du plan de contrôle de votre cluster. Indiquez une région pour les clusters régionaux ou une zone pour les clusters zonaux.
    • VERSION : version de GKE compatible avec GPUDirect-TCPX, comme décrit dans Exigences.

    Autopilot

    gcloud beta container clusters create-auto CLUSTER_NAME \
        --project=PROJECT_ID \
        --location=CONTROL_PLANE_LOCATION \
        --cluster-version=VERSION \
        --enable-multi-networking \
        --workload-policies=allow-net-admin
    

    Remplacez les éléments suivants :

    • CLUSTER_NAME : nom de votre nouveau cluster
    • CONTROL_PLANE_LOCATION : région Compute Engine du plan de contrôle de votre cluster.
    • VERSION : version de GKE compatible avec GPUDirect-TCPX, comme décrit dans Exigences.
  2. Créez des ressources Network et GKENetworkParamSet dans le cluster correspondant aux réseaux et sous-réseaux VPC que vous avez créés :

    kubectl apply -f - <<EOF
    apiVersion: networking.gke.io/v1
    kind: Network
    metadata:
      name: vpc1
    spec:
      parametersRef:
        group: networking.gke.io
        kind: GKENetworkParamSet
        name: vpc1
      type: Device
    ---
    apiVersion: networking.gke.io/v1
    kind: Network
    metadata:
      name: vpc2
    spec:
      parametersRef:
        group: networking.gke.io
        kind: GKENetworkParamSet
        name: vpc2
      type: Device
    ---
    apiVersion: networking.gke.io/v1
    kind: Network
    metadata:
      name: vpc3
    spec:
      parametersRef:
        group: networking.gke.io
        kind: GKENetworkParamSet
        name: vpc3
      type: Device
    ---
    apiVersion: networking.gke.io/v1
    kind: Network
    metadata:
      name: vpc4
    spec:
      parametersRef:
        group: networking.gke.io
        kind: GKENetworkParamSet
        name: vpc4
      type: Device
    ---
    apiVersion: networking.gke.io/v1
    kind: GKENetworkParamSet
    metadata:
      name: vpc1
    spec:
      vpc: PREFIX-net-1
      vpcSubnet: PREFIX-sub-1
      deviceMode: NetDevice
    ---
    apiVersion: networking.gke.io/v1
    kind: GKENetworkParamSet
    metadata:
      name: vpc2
    spec:
      vpc: PREFIX-net-2
      vpcSubnet: PREFIX-sub-2
      deviceMode: NetDevice
    ---
    apiVersion: networking.gke.io/v1
    kind: GKENetworkParamSet
    metadata:
      name: vpc3
    spec:
      vpc: PREFIX-net-3
      vpcSubnet: PREFIX-sub-3
      deviceMode: NetDevice
    ---
    apiVersion: networking.gke.io/v1
    kind: GKENetworkParamSet
    metadata:
      name: vpc4
    spec:
      vpc: PREFIX-net-4
      vpcSubnet: PREFIX-sub-4
      deviceMode: NetDevice
    EOF
    

    Ces ressources indiquent à GKE de configurer les cartes d'interface réseau pour le trafic GPU en mode passthrough. GKE n'applique pas la programmation réseau intégrée en utilisant eBPF à ce trafic.

Créer un pool de nœuds GPU (Standard uniquement)

  1. Créez un pool de nœuds pour les GPU H100 :

    gcloud container node-pools create NODE_POOL_NAME \
        --cluster=CLUSTER_NAME \
        --location=CONTROL_PLANE_LOCATION \
        --machine-type=a3-edgegpu-8g \
        --accelerator=type=nvidia-h100-80gb,count=8,gpu-driver-version=LATEST \
        --additional-node-network=network=PREFIX-net-1,subnetwork=PREFIX-sub-1 \
        --additional-node-network=network=PREFIX-net-2,subnetwork=PREFIX-sub-2 \
        --additional-node-network=network=PREFIX-net-3,subnetwork=PREFIX-sub-3 \
        --additional-node-network=network=PREFIX-net-4,subnetwork=PREFIX-sub-4 \
        --enable-gvnic \
        --no-enable-autoupgrade \
        --placement-policy=POLICY_NAME \
        --reservation-affinity=specific \
        --reservation=projects/PROJECT_ID/reservations/RESERVATION_NAME/reservationBlocks/BLOCK_NAME
    

    Remplacez NODE_POOL_NAME par le nom du pool de nœuds.

    Pour utiliser une réservation, utilisez les options --placement-policy, --reservation-affinity et --reservation. Spécifiez ces indicateurs pour configurer le nom de la règle et la réservation dans le pool de nœuds. Si la réservation ne nécessite pas de règle de ressources, omettez l'option --placement-policy.

    L'indicateur --reservation-affinity peut prendre les valeurs specific ou any. Toutefois, pour les charges de travail d'IA distribuées à hautes performances, nous vous recommandons d'utiliser une réservation spécifique. Vous pouvez trouver des informations sur votre réservation, comme son nom ou celui d'un bloc spécifique. Pour trouver ces valeurs pour les réservations à la demande, affichez la liste de vos réservations ou affichez les demandes de réservations futures.

    Remplacez les éléments suivants pour utiliser une réservation :

    • PROJECT_ID : ID de votre projet Google Cloud(facultatif). Si la réservation se trouve dans le projet actuel (et non dans une réservation partagée), vous pouvez omettre projects/PROJECT_ID/reservations/ de la valeur de réservation.
    • RESERVATION_NAME : nom de votre réservation.
    • BLOCK_NAME : nom facultatif d'un bloc spécifique dans la réservation. Omettez /reservationBlocks/BLOCK_NAME si vous ne souhaitez pas utiliser de bloc spécifique.

    Si cette commande échoue, il est possible que votre quota de GPU H100 ne soit pas suffisant dans votre projet. Vérifiez que vous disposez d'un quota et relancez la commande.

  2. Après avoir créé le pool de nœuds, vérifiez que chaque nœud comporte les GPU associés :

    1. Obtenez la liste des nœuds du cluster :

      kubectl get nodes
      
    2. Vérifiez que chaque nœud GPU comporte huit GPU :

      kubectl describe node NODE_NAME
      

      Remplacez NODE_NAME par le nom du nœud à décrire.

      Le résultat ressemble à ce qui suit :

      Capacity:
        ...
        nvidia.com/gpu:             8
      Allocatable:
        ...
        nvidia.com/gpu:             8
      

Installer le binaire GPUDirect et le plug-in NCCL

Cette section explique comment installer le binaire GPUDirect-TCPX et une version spécifique de la bibliothèque NCCL à l'aide d'un DaemonSet.

Ce DaemonSet effectue les opérations suivantes :

  1. Installe la bibliothèque NCCL et le binaire GPUDirect-TCPX sur le nœud.
  2. Stocke la bibliothèque et le binaire dans le répertoire /home/kubernetes/bin/nvidia/lib64 de la VM. Par défaut, GKE installe ce répertoire dans le chemin d'accès /usr/local/nvidia/lib64 dans les conteneurs de GPU qui doivent utiliser NCCL et GPUDirect-TCPX.

Pour installer le binaire et configurer NCCL, procédez comme suit :

Standard

  1. Consultez le fichier manifeste DaemonSet nccl-tcpx-installer.yaml dans GitHub.

  2. Déployez le DaemonSet :

    kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/container-engine-accelerators/master/gpudirect-tcpx/nccl-tcpx-installer.yaml
    

    Le démarrage du plug-in NCCL prend environ deux minutes.

  3. Vérifiez l'état des pods DaemonSet :

    kubectl get pods -n=kube-system -l=name=nccl-tcpx-installer
    

    Le résultat ressemble à ce qui suit :

    nccl-tcpx-installer-6c2pv                    1/1     Running   0          2m11s
    nccl-tcpx-installer-qgg82                    1/1     Running   0          2m11s
    

Autopilot

  1. Examinez le fichier manifeste DaemonSet nccl-tcpx-installer-autopilot.yaml dans GitHub.

  2. Créez un espace de noms dédié :

    kubectl create ns gpudirect-system
    
  3. Déployez le DaemonSet :

    kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/container-engine-accelerators/master/gpudirect-tcpx/nccl-tcpx-installer-autopilot.yaml
    

    Le démarrage du plug-in NCCL prend environ deux minutes.

Déployer le plug-in d'injecteur d'appareils NRI

Cette section vous explique comment installer l'injecteur d'appareils NRI à l'aide d'un DaemonSet. Ce plug-in effectue les opérations suivantes :

  1. Active l'interface de ressources de nœud (NRI) sur le nœud doté de GPU H100. NRI est activé par défaut sur GKE 1.29 et versions ultérieures.
  2. Déploie un conteneur de plug-in d'injecteur d'appareil NRI qui injecte des appareils GPU dans les conteneurs spécifiés par les annotations de pod.

Pour installer le plug-in, procédez comme suit :

Standard

  1. Examinez le fichier manifeste de déploiement nri-device-injector.yaml dans GitHub.

  2. Déployez le DaemonSet :

    kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/container-engine-accelerators/master/nri_device_injector/nri-device-injector.yaml
    

    Le démarrage du plug-in NCCL prend environ deux minutes.

  3. Vérifiez l'état des pods DaemonSet :

    kubectl get pods -n=kube-system -l=name=device-injector
    

    Le résultat ressemble à ce qui suit :

    # Output
    device-injector-md6hb                         1/1     Running   0       4h54m
    device-injector-vh9bm                         1/1     Running   0       4h54m
    

Autopilot

  1. Examinez le fichier manifeste de déploiement nri-device-injector-autopilot.yaml dans GitHub.

  2. Déployez le DaemonSet :

    kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/container-engine-accelerators/master/nri_device_injector/nri-device-injector-autopilot.yaml
    

    Le démarrage du plug-in NCCL prend environ deux minutes.

Déployer une charge de travail de test

Dans cette section, vous déployez un exemple de charge de travail pour vérifier que la bibliothèque NCCL et les GPU GPU-TCPX fonctionnent comme prévu. Cet exemple de charge de travail effectue les opérations suivantes :

  1. Déploie deux pods, chacun s'exécutant dans un nœud doté de GPU H100.
  2. Il déploie un conteneur side-car dans chaque pod pour permettre à ces pods d'utiliser GPUDirect-TCPX.

Cette charge de travail inclut un conteneur side-car nommé tcpx-daemon, qui exécute un service permettant au pod d'utiliser GPUDirect-TCPX. Vous devez ajouter ce conteneur side-car à tous les pods de votre propre environnement qui doivent utiliser GPUDirect-TCPX. Pour obtenir un extrait des champs obligatoires à ajouter à vos fichiers manifestes, consultez la section Ajouter GPUDirect à votre fichier manifeste.

  1. Consultez le fichier manifeste ConfigMap nccl-config.yaml dans GitHub. Ce fichier manifeste déploie des scripts qui initialisent un test all-gather NCCL et définissent des paramètres de configuration spécifiques à NCCL.

  2. Procédez comme suit en fonction du mode de votre cluster :

  3. Déployez le ConfigMap et la charge de travail de test :

    Standard

    kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/container-engine-accelerators/master/gpudirect-tcpx/nccl-config.yaml
    kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/container-engine-accelerators/master/gpudirect-tcpx/nccl-test-latest.yaml
    

    Autopilot

    kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/container-engine-accelerators/master/gpudirect-tcpx/nccl-config.yaml
    kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/container-engine-accelerators/master/gpudirect-tcpx/nccl-test-latest-autopilot.yaml
    
  4. Vérifiez que les pods sont en cours d'exécution et prêts. Notez que les images sont volumineuses (environ 5 Go) et que leur téléchargement peut prendre plusieurs minutes.

    kubectl get pods -w
    

    La commande surveille les mises à jour et imprime une nouvelle ligne lorsque l'état d'un pod change. Le résultat ressemble à ce qui suit :

    NAME               READY   STATUS              RESTARTS   AGE
    nccl-test-host-1   0/2     ContainerCreating   0          23s
    nccl-test-host-2   2/2     Running             0          23s
    nccl-test-host-1   2/2     Running             0          46s
    

    Avant de passer à l'étape suivante, attendez que le message STATUS pour tous les pods soit Running et que la valeur de READY soit 2/2.

  5. Exécutez les commandes suivantes pour déclencher un test NCCL complet pour les nœuds :

    kubectl exec \
      --stdin --tty --container=nccl-test nccl-test-host-1 \
      -- /configs/allgather.sh nccl-host-1 nccl-host-2
    

    Le résultat ressemble à ce qui suit :

    Standard

      #                                                              out-of-place                       in-place
      #        size         count      type   redop    root     time   algbw   busbw #wrong     time   algbw   busbw #wrong
      #         (B)    (elements)                               (us)  (GB/s)  (GB/s)            (us)  (GB/s)  (GB/s)
                  0             0     float    none      -1     0.24    0.00    0.00      0     0.18    0.00    0.00      0
                  0             0     float    none      -1     0.19    0.00    0.00      0     0.17    0.00    0.00      0
                  0             0     float    none      -1     0.17    0.00    0.00      0     0.17    0.00    0.00      0
                  0             0     float    none      -1     0.17    0.00    0.00      0     0.17    0.00    0.00      0
                  0             0     float    none      -1     0.17    0.00    0.00      0     0.17    0.00    0.00      0
                256             4     float    none      -1    235.2    0.00    0.00      0    235.1    0.00    0.00      0
                512             8     float    none      -1    241.0    0.00    0.00      0    236.1    0.00    0.00      0
               1024            16     float    none      -1    236.3    0.00    0.00      0    233.3    0.00    0.00      0
               2048            32     float    none      -1    234.1    0.01    0.01      0    233.4    0.01    0.01      0
               4096            64     float    none      -1    237.1    0.02    0.02      0    235.3    0.02    0.02      0
               8192           128     float    none      -1    236.2    0.03    0.03      0    235.2    0.03    0.03      0
              16384           256     float    none      -1    236.6    0.07    0.06      0    238.5    0.07    0.06      0
              32768           512     float    none      -1    237.9    0.14    0.13      0    238.8    0.14    0.13      0
              65536          1024     float    none      -1    242.3    0.27    0.25      0    239.4    0.27    0.26      0
             131072          2048     float    none      -1    263.0    0.50    0.47      0    275.1    0.48    0.45      0
             262144          4096     float    none      -1    279.2    0.94    0.88      0    269.9    0.97    0.91      0
             524288          8192     float    none      -1    273.5    1.92    1.80      0    273.5    1.92    1.80      0
            1048576         16384     float    none      -1    315.1    3.33    3.12      0    314.1    3.34    3.13      0
            2097152         32768     float    none      -1    319.2    6.57    6.16      0    311.5    6.73    6.31      0
            4194304         65536     float    none      -1    331.8   12.64   11.85      0    331.3   12.66   11.87      0
            8388608        131072     float    none      -1    356.3   23.54   22.07      0    353.8   23.71   22.23      0
           16777216        262144     float    none      -1    409.1   41.01   38.45      0    405.2   41.40   38.81      0
           33554432        524288     float    none      -1    451.4   74.34   69.69      0    447.7   74.94   70.26      0
           67108864       1048576     float    none      -1    713.4   94.07   88.19      0    713.8   94.01   88.13      0
          134217728       2097152     float    none      -1   1122.1  119.62  112.14      0   1116.3  120.23  112.72      0
          268435456       4194304     float    none      -1   1785.8  150.32  140.92      0   1769.2  151.72  142.24      0
          536870912       8388608     float    none      -1   2859.7  187.74  176.00      0   2852.6  188.20  176.44      0
         1073741824      16777216     float    none      -1   5494.1  195.44  183.22      0   5568.2  192.83  180.78      0
         2147483648      33554432     float    none      -1    10841  198.09  185.71      0    10798  198.88  186.45      0
         4294967296      67108864     float    none      -1    21453  200.21  187.70      0    21490  199.86  187.37      0
         8589934592     134217728     float    none      -1    42603  201.63  189.03      0    42670  201.31  188.73      0
      # Out of bounds values : 0 OK
      # Avg bus bandwidth    : 45.7587
      #
      ```
    

    Autopilot

    #                                                              out-of-place                       in-place
    #       size         count      type   redop    root     time   algbw   busbw #wrong     time   algbw   busbw #wrong
    #        (B)    (elements)                               (us)  (GB/s)  (GB/s)            (us)  (GB/s)  (GB/s)
        1048576         16384     float    none      -1    696.8    1.50    1.41      0    729.0    1.44    1.35      0
        2097152         32768     float    none      -1    776.4    2.70    2.53      0    726.7    2.89    2.71      0
        4194304         65536     float    none      -1    774.3    5.42    5.08      0    805.1    5.21    4.88      0
        8388608        131072     float    none      -1    812.1   10.33    9.68      0    817.6   10.26    9.62      0
       16777216        262144     float    none      -1   1035.2   16.21   15.19      0   1067.8   15.71   14.73      0
       33554432        524288     float    none      -1   1183.3   28.36   26.59      0   1211.8   27.69   25.96      0
       67108864       1048576     float    none      -1   1593.4   42.12   39.49      0   1510.5   44.43   41.65      0
      134217728       2097152     float    none      -1   2127.8   63.08   59.13      0   2312.7   58.03   54.41      0
      268435456       4194304     float    none      -1   3603.0   74.50   69.85      0   3586.2   74.85   70.17      0
      536870912       8388608     float    none      -1   7101.7   75.60   70.87      0   7060.9   76.03   71.28      0
    # Out of bounds values : 0 OK
    # Avg bus bandwidth    : 29.8293
    

Adopter GPUDirect pour vos propres charges de travail

Une fois que vous avez vérifié que la mise en réseau de votre cluster fonctionne correctement avec l'exemple de charge de travail de test, l'étape suivante consiste à adopter GPUDirect pour vos charges de travail réelles. Pour adopter GPUDirect, vous devez mettre à jour vos paramètres NCCL et vos fichiers manifestes de pod Kubernetes.

Utiliser les paramètres de configuration de NCCL requis pour améliorer les performances

Les paires clé/valeur suivantes correspondent aux paramètres de configuration NCCL requis pour GPUDirect-TCPX. Lorsque vous déployez vos charges de travail qui utilisent NCCL, définissez-les en tant que variables d'environnement pour optimiser les performances.

"LD_LIBRARY_PATH=\"${LD_LIBRARY_PATH}:/usr/local/nvidia/lib64\"",
"NCCL_SOCKET_IFNAME=\"eth0\"",
"NCCL_ALGO=Ring",
"NCCL_PROTO=Simple",
"NCCL_CROSS_NIC=0",
"NCCL_NET_GDR_LEVEL=PIX",
"NCCL_P2P_PXN_LEVEL=0",
"NCCL_GPUDIRECTTCPX_SOCKET_IFNAME=eth1,eth2,eth3,eth4",
"NCCL_GPUDIRECTTCPX_CTRL_DEV=eth0",
"NCCL_DYNAMIC_CHUNK_SIZE=524288",
"NCCL_P2P_NET_CHUNKSIZE=524288",
"NCCL_P2P_PCI_CHUNKSIZE=524288",
"NCCL_P2P_NVL_CHUNKSIZE=1048576",
"NCCL_BUFFSIZE=4194304",
"NCCL_NSOCKS_PERTHREAD=4",
"NCCL_SOCKET_NTHREADS=1",
"NCCL_GPUDIRECTTCPX_TX_BINDINGS=\"eth1:8-21,112-125;eth2:8-21,112-125;eth3:60-73,164-177;eth4:60-73,164-177\"",
"NCCL_GPUDIRECTTCPX_RX_BINDINGS=\"eth1:22-35,126-139;eth2:22-35,126-139;eth3:74-87,178-191;eth4:74-87,178-191\"",
"NCCL_GPUDIRECTTCPX_PROGRAM_FLOW_STEERING_WAIT_MICROS=500000"

Ajouter GPUDirect à vos fichiers manifestes

Cette section montre les champs obligatoires que vous devez ajouter à vos fichiers manifestes Kubernetes pour que vos pods puissent utiliser GPUDirect.

Selon le mode de votre cluster, procédez comme suit :

Standard

  1. Ajoutez les annotations suivantes aux métadonnées du pod. Sans ces annotations, hostNetwork:true sera requis pour le pod et privileged:true pour le conteneur tcpx-daemon.

    metadata:
      annotations:
        devices.gke.io/container.tcpx-daemon: |+
          - path: /dev/nvidia0
          - path: /dev/nvidia1
          - path: /dev/nvidia2
          - path: /dev/nvidia3
          - path: /dev/nvidia4
          - path: /dev/nvidia5
          - path: /dev/nvidia6
          - path: /dev/nvidia7
          - path: /dev/nvidiactl
          - path: /dev/nvidia-uvm
        networking.gke.io/default-interface: 'eth0'
        networking.gke.io/interfaces: |
          [
            {"interfaceName":"eth0","network":"default"},
            {"interfaceName":"eth1","network":"vpc1"},
            {"interfaceName":"eth2","network":"vpc2"},
            {"interfaceName":"eth3","network":"vpc3"},
            {"interfaceName":"eth4","network":"vpc4"},
          ]
    
  2. Ajoutez les champs suivants à la spécification de pod :

    spec:
      volumes:
      - name: libraries
        hostPath:
          path: /home/kubernetes/bin/nvidia/lib64
      - name: sys
        hostPath:
          path: /sys
      - name: proc-sys
        hostPath:
          path: /proc/sys
    
  3. Ajoutez le conteneur suivant au fichier manifeste pour exécuter le service tcpx-daemon :

    - name: tcpx-daemon
      image: us-docker.pkg.dev/gce-ai-infra/gpudirect-tcpx/tcpgpudmarxd-dev:v2.0.9
      command:
        - /tcpgpudmarxd/build/app/tcpgpudmarxd
        - --gpu_nic_preset
        - a3vm
        - --gpu_shmem_type
        - fd
        - --uds_path
        - /run/tcpx
        - --setup_param
        - \"--verbose 128 2 0 \"
      securityContext:
        capabilities:
            add:
              - NET_ADMIN
      volumeMounts:
        - name: libraries
          mountPath: /usr/local/nvidia/lib64
        - name: tcpx-socket
          mountPath: /run/tcpx
        - name: sys
          mountPath: /hostsysfs
        - name: proc-sys
          mountPath: /hostprocsysfs
      env:
        - name: LD_LIBRARY_PATH
          value: /usr/local/nvidia/lib64
    
  4. Ajoutez les installations de volume suivantes à tous les conteneurs qui demandent des GPU :

    volumeMounts:
    - name: tcpx-socket
      mountPath: /tmp
    - name: libraries
      mountPath: /usr/local/nvidia/lib64
    
  5. Vous pouvez également ajouter des variables d'environnement pour configurer les options NCCL. Pour en savoir plus, consultez la section Utiliser les paramètres de configuration de NCCL recommandés pour améliorer les performances dans ce document.

  6. Ajoutez la variable d'environnement suivante à chaque conteneur de GPU :

    env:
    - name: LD_LIBRARY_PATH
      value: /usr/local/nvidia/lib64
    

Pour obtenir un exemple de spécification de pod terminée, consultez le fichier manifeste nccl-test-latest.yaml sur GitHub.

Autopilot

Pour le mode Autopilot, vous devez également sélectionner les GPU appropriés dans les fichiers manifestes de vos pods afin que GKE provisionne le matériel.

Ajoutez les sélecteurs de nœuds suivants à votre pod :

nodeSelector:
  cloud.google.com/gke-accelerator: a3-edgegpu-8g
  cloud.google.com/gke-gpu-driver-version: latest

De plus, si vous souhaitez utiliser la capacité réservée, vous pouvez fournir des informations sur la réservation. Pour en savoir plus, consultez les sous-sections sur la consommation de réservations dans Consommer des réservations de capacité dans des clusters Autopilot.

  1. Ajoutez les annotations suivantes aux métadonnées du pod :

    metadata:
      annotations:
        devices.gke.io/container.tcpx-daemon: |+
          - path: /dev/nvidia0
          - path: /dev/nvidia1
          - path: /dev/nvidia2
          - path: /dev/nvidia3
          - path: /dev/nvidia4
          - path: /dev/nvidia5
          - path: /dev/nvidia6
          - path: /dev/nvidia7
          - path: /dev/nvidiactl
          - path: /dev/nvidia-uvm
        networking.gke.io/default-interface: 'eth0'
        networking.gke.io/interfaces: |
          [
            {"interfaceName":"eth0","network":"default"},
            {"interfaceName":"eth1","network":"vpc1"},
            {"interfaceName":"eth2","network":"vpc2"},
            {"interfaceName":"eth3","network":"vpc3"},
            {"interfaceName":"eth4","network":"vpc4"},
          ]
    
  2. Ajoutez les champs suivants à la spécification de pod :

    spec:
      volumes:
      - name: libraries
        hostPath:
          path: /home/kubernetes/bin/nvidia/lib64
      - name: sys
        hostPath:
          path: /sys
      - name: proc-sys
        hostPath:
          path: /proc/sys
    
  3. Ajoutez le conteneur suivant au fichier manifeste pour exécuter le service tcpx-daemon :

    - name: tcpx-daemon
      image: us-docker.pkg.dev/gce-ai-infra/gpudirect-tcpx/tcpgpudmarxd-dev:v2.0.9
      command:
        - /tcpgpudmarxd/build/app/tcpgpudmarxd
        - --gpu_nic_preset
        - a3vm
        - --gpu_shmem_type
        - fd
        - --uds_path
        - /run/tcpx
        - --setup_param
        - \"--verbose 128 2 0 \"
      securityContext:
        capabilities:
            add:
              - NET_ADMIN
      volumeMounts:
        - name: libraries
          mountPath: /usr/local/nvidia/lib64
        - name: tcpx-socket
          mountPath: /run/tcpx
        - name: sys
          mountPath: /hostsysfs
        - name: proc-sys
          mountPath: /hostprocsysfs
      env:
        - name: LD_LIBRARY_PATH
          value: /usr/local/nvidia/lib64
    
  4. Ajoutez les installations de volume suivantes à tous les conteneurs qui demandent des GPU :

    volumeMounts:
    - name: tcpx-socket
      mountPath: /tmp
    - name: libraries
      mountPath: /usr/local/nvidia/lib64
    
  5. Vous pouvez également ajouter des variables d'environnement pour configurer les options NCCL. Pour en savoir plus, consultez la section Utiliser les paramètres de configuration de NCCL recommandés pour améliorer les performances dans ce document.

Pour obtenir un exemple de spécification de pod terminée, consultez le fichier manifeste nccl-test-latest-autopilot.yaml sur GitHub.

Collecter les journaux de débogage NCCL

Pour consigner les erreurs NCCL, nous vous recommandons d'ajouter la configuration NCCL suivante :

NCCL_DEBUG=INFO
NCCL_DEBUG_SUBSYS=INIT,NET,ENV,COLL,GRAPH
NCCL_DEBUG_FILE=/DIRECTORY/FILE_NAME.%h.%p
  • NCCL_DEBUG=INFO : imprime les informations de débogage.
    • Pour les charges de travail à grande échelle (64 nœuds ou plus), une journalisation intensive peut se produire. Pour éviter ce scénario, et sauf si vous avez spécifié NCCL_DEBUG_FILE, nous vous recommandons de définir NCCL_DEBUG=WARN pour limiter les journaux aux erreurs uniquement.
  • NCCL_DEBUG_SUBSYS : filtre les sous-systèmes pour lesquels NCCL collecte des informations de débogage. Nous vous recommandons de collecter les journaux pour les sous-systèmes suivants :

    • INIT : phase d'initialisation de NCCL.
    • NET : réseau NCCL.
    • ENV : variables d'environnement utilisées par NCCL.
    • COLL : opérations collectives.
    • GRAPH : détection de la topologie et recherche de graphiques.

    Si vous souhaitez collecter des journaux pour différents sous-systèmes, consultez NCCL_DEBUG_SUBSYS dans la documentation NCCL pour obtenir la liste des valeurs acceptées.

  • NCCL_DEBUG_FILE (facultatif) : redirige la sortie des journaux de débogage NCCL vers un fichier que vous spécifiez. Cette variable écrit les journaux NCCL dans des fichiers standards, ce qui empêche la sortie du journal de se mélanger à la sortie de l'application. Cette variable écrit également les journaux de différents rangs NCCL dans différents fichiers, ce qui évite que les journaux ne se mélangent.

    Utilisez le format de nom de fichier suivant :

    /DIRECTORY/FILE_NAME.%h.%p
    

    Remplacez les éléments suivants :

    • DIRECTORY : répertoire dans lequel vous souhaitez stocker les fichiers journaux.
    • FILE_NAME : nom des fichiers journaux.

    L'espace réservé %h est résolu en nom d'hôte du nœud, tandis que %p est résolu en ID de processus (PID) du processus qui génère le journal.

Pour en savoir plus sur le débogage des journaux NCCL, consultez Résoudre les problèmes liés aux GPU dans GKE.

Étapes suivantes