Cette page a été traduite par l'API Cloud Translation.

Maximiser la bande passante réseau de GPU dans les clusters en mode Standard

Standard

Cette page explique comment optimiser la bande passante et le débit du réseau pour les charges de travail GPU hautes performances dans les clusters standards Google Kubernetes Engine (GKE) à l'aide de GPUDirect-TCPXO, GPUDirect-TCPX, gVNIC et du multiréseau. Si vous utilisez des clusters Autopilot, consultez la page Maximiser la bande passante réseau du GPU dans les clusters en mode Autopilot.

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 la section Rôles utilisateur et tâches courantes de l'utilisateur dans GKE Enterprise.

Les applications d'intelligence artificielle (IA), de ML et de calcul hautes performances 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.

Avant de lire cette page, assurez-vous de maîtriser 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 Google Cloud superordinateurs sur GPU

Google Cloud dispose de superordinateurs optimisés pour les accélérateurs, conçus pour des modèles massifs et évolutifs. Ces machines présentent les avantages suivants :

Huit GPU NVIDIA B200, H200 ou H100 par machine.
Jusqu'à 200 Gbit/s sur la carte d'interface réseau principale.
Cartes d'interface réseau secondaires (jusqu'à huit sur les types de machines A3 Mega et jusqu'à quatre sur les types de machines A3 High), chacune acceptant jusqu'à 200 Gbit/s de bande passante pour le transfert de données GPU.

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 idéale 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, utilisez toutes les fonctionnalités suivantes :

Pile réseau GPUDirect: la série de machines A3 est compatible avec trois piles réseau pour l'accès à la mémoire directe distante (RDMA) personnalisée :
- Sur les types de machines A3 High et les GPU NVIDIA H100, utilisez 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.
- Sur les types de machines A3 Mega et les GPU NVIDIA H100 Mega, utilisez GPUDirect-TCPXO, qui améliore encore la communication entre le GPU et la VM.
- Sur les types de machines A3 Ultra et les GPU NVIDIA H200, ainsi que sur les types de machines A4 et les GPU NVIDIA B200, utilisez GPUDirect RDMA pour exécuter des charges de travail d'IA distribuées avec des améliorations supplémentaires du débit. Pour commencer, créez un cluster GKE personnalisé optimisé par l'IA.
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 ou GPUDirect-TCPXO. Pour en savoir plus sur gVNIC, consultez la section Augmenter la vitesse de trafic réseau pour les nœuds GPU.
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 la section Définir un emplacement compact pour les nœuds GKE.

Aperçu de la procédure

Pour utiliser toutes ces fonctionnalités ensemble, procédez comme suit :

Créer des clouds privés virtuels (VPC) et des sous-réseaux
Créez l'environnement GKE.
Installer le binaire GPUDirect et le plug-in NCCL
Déployer le plug-in d'injection d'appareils NRI
Déployer une charge de travail de test pour vérifier la configuration de GPUDirect

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 Google Cloud CLI pour cette tâche, installez puis initialisez gcloud CLI. Si vous avez déjà installé gcloud CLI, assurez-vous de disposer de la dernière version en exécutant la commande gcloud components update.
Remarque : Pour les installations de gcloud CLI existantes, veillez à définir les propriétés compute/region et compute/zone. En définissant des emplacements par défaut, vous pouvez éviter les erreurs gcloud CLI telles que celle-ci : One of [--zone, --region] must be supplied: Please specify location.

Assurez-vous de disposer d'un quota suffisant pour les GPU H100. Pour demander une augmentation de quota, consultez la page Quotas de GPU.

Exigences

Les exigences suivantes s'appliquent à la fois à GPUDirect-TCPX et à GPUDirect-TCPXO, sauf indication contraire.

GPUDirect-TCPX est compatible avec GKE version 1.27 ou ultérieure et nécessite les éléments suivants :
- * Type de machine a3-highgpu-8g.
- Pour GKE version 1.27, utilisez la version de correctif 1.27.7-gke.1121000 ou ultérieure de GKE.
- Pour GKE version 1.28, utilisez la version de correctif 1.28.10-gke.1141000 ou ultérieure de GKE.
- Pour GKE version 1.29, utilisez la version de correctif 1.29.5-gke.1121000 ou ultérieure de GKE.
GPUDirect-TCPXO est compatible avec GKE version 1.28 ou ultérieure et nécessite les éléments suivants:
- Type de machine a3-megagpu-8g.
- Pour GKE version 1.28, utilisez la version de correctif 1.28.9-gke.1250000 ou ultérieure de GKE.
- Pour GKE version 1.29, utilisez la version de correctif 1.29.4-gke.1542000 ou ultérieure de GKE.
- Pour GKE version 1.30, utilisez la version de correctif 1.30.4-gke.1129000 ou ultérieure de GKE.
- Pour GKE version 1.31, utilisez la version de correctif 1.31.1-gke.2008000 ou ultérieure de GKE.
- Pour GKE version 1.32, utilisez la version de correctif 1.32.2-gke.1489001 ou ultérieure de GKE.
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.
Pour les charges de travail GPUDirect-TCPX ou GPUDirect-TCPXO exécutées 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 et GPUDirect-TCPXO ne sont pas compatibles avec les GPU multi-instances, le partage de GPU à temps partagé ni NVIDIA MPS.
Vous ne pouvez pas utiliser NCCL FastSocket avec GPUDirect-TCPX ou GPUDirect-TCPXO .
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 ou GPUDirect-TCPXO sur un même nœud.
Vous ne pouvez utiliser que les types de machines a3-highgpu-8g et a3-megagpu-8g. Les autres types de machines A3 ne sont pas compatibles.

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.

Créez les réseaux VPC pour GPUDirect dans votre projet, chacun avec un sous-réseau et une règle de pare-feu : Choisissez l'onglet GPUDirect-TCPX pour les types de machines A3 High ou l'onglet GPUDirect-TCPXO pour les types de machines A3 Mega, puis suivez les instructions suivantes:
GPUDirect-TCPXO
Pour optimiser votre bande passante, nous vous recommandons de créer huit autres réseaux.
```
for N in $(seq 1 8); 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 Google Cloud projet.
- 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 huit 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.
GPUDirect-TCPX
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 Google Cloud projet.
- 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.
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 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.

GPUDirect-TCPXO

Choisissez une version de GKE disponible compatible avec GPUDirect-TCPXO. Pour lister les versions, exécutez la commande suivante:
```
gcloud container get-server-config \
    --format="yaml(validMasterVersions)" \
    --region=REGION \
    --project=PROJECT_ID
```
Remplacez les éléments suivants :
- REGION : région de calcul du plan de contrôle du cluster.
- PROJECT_ID: ID de votre Google Cloud projet.

Créez un cluster :

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

Remplacez les éléments suivants :

CLUSTER_NAME : nom de votre nouveau cluster
VERSION: version de GKE compatible avec GPUDirect-TCPXO, comme décrit dans la section Conditions requises.
ZONE : zone de calcul du cluster.

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: Network
metadata:
  name: vpc5
spec:
  parametersRef:
    group: networking.gke.io
    kind: GKENetworkParamSet
    name: vpc5
  type: Device
---
apiVersion: networking.gke.io/v1
kind: Network
metadata:
  name: vpc6
spec:
  parametersRef:
    group: networking.gke.io
    kind: GKENetworkParamSet
    name: vpc6
  type: Device
---
apiVersion: networking.gke.io/v1
kind: Network
metadata:
  name: vpc7
spec:
  parametersRef:
    group: networking.gke.io
    kind: GKENetworkParamSet
    name: vpc7
  type: Device
---
apiVersion: networking.gke.io/v1
kind: Network
metadata:
  name: vpc8
spec:
  parametersRef:
    group: networking.gke.io
    kind: GKENetworkParamSet
    name: vpc8
  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
---
apiVersion: networking.gke.io/v1
kind: GKENetworkParamSet
metadata:
  name: vpc5
spec:
  vpc: PREFIX-net-5
  vpcSubnet: PREFIX-sub-5
  deviceMode: NetDevice
---
apiVersion: networking.gke.io/v1
kind: GKENetworkParamSet
metadata:
  name: vpc6
spec:
  vpc: PREFIX-net-6
  vpcSubnet: PREFIX-sub-6
  deviceMode: NetDevice
---
apiVersion: networking.gke.io/v1
kind: GKENetworkParamSet
metadata:
  name: vpc7
spec:
  vpc: PREFIX-net-7
  vpcSubnet: PREFIX-sub-7
  deviceMode: NetDevice
---
apiVersion: networking.gke.io/v1
kind: GKENetworkParamSet
metadata:
  name: vpc8
spec:
  vpc: PREFIX-net-8
  vpcSubnet: PREFIX-sub-8
  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.

GPUDirect-TCPX

Créez un cluster :

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

Remplacez les éléments suivants : * CLUSTER_NAME: nom de votre nouveau cluster. * VERSION: version de GKE compatible avec GPUDirect-TCPX, comme décrit dans la section Conditions requises. * ZONE: zone de calcul du cluster.

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

Créer un pool de nœuds GPU

GPUDirect-TCPXO

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

gcloud beta container node-pools create NODE_POOL_NAME \
    --zone=ZONE \
    --cluster=CLUSTER_NAME \
    --project=PROJECT_ID \
    --accelerator=type=nvidia-h100-mega-80gb,count=8,gpu-driver-version=LATEST \
    --machine-type=a3-megagpu-8g \
    --num-nodes=2 \
    --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 \
    --additional-node-network network=PREFIX-net-5,subnetwork=PREFIX-sub-5 \
    --additional-node-network network=PREFIX-net-6,subnetwork=PREFIX-sub-6 \
    --additional-node-network network=PREFIX-net-7,subnetwork=PREFIX-sub-7 \
    --additional-node-network network=PREFIX-net-8,subnetwork=PREFIX-sub-8 \
    --enable-gvnic \
    --no-enable-autoupgrade \
    --scopes "https://www.googleapis.com/auth/cloud-platform" \
    [--placement-policy=POLICY_NAME \
    --reservation-affinity=specific \
    --reservation=RESERVATION_NAME \
    --host-maintenance-interval=PERIODIC]

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

Dans l'exemple, l'argument --scopes "https://www.googleapis.com/auth/cloud-platform" définit le champ d'application de l'instance de nœud sur cloud-platform pour faciliter les tests. Pour la production, vous pouvez limiter la portée afin de configurer des identifiants plus précis.

Utilisez les options --placement-policy, --reservation-affinity et --reservation si vous utilisez une réservation. Spécifiez ces indicateurs pour configurer le nom de la règle et la réservation dans le pool de nœuds.

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 suffisant et relancez la commande.

GPUDirect-TCPX

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

gcloud container node-pools create NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=LOCATION \
    --machine-type=a3-highgpu-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

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

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.

Après avoir créé le pool de nœuds, vérifiez que chaque nœud dispose des GPU associés:

Obtenez la liste des nœuds du cluster :
```
kubectl get nodes
```
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 configurer NCCL

Cette section explique comment installer le binaire GPUDirect, en fonction de votre type de machine A3 (GPUDirect-TCPX pour A3 High, GPUDirect-TCPXO pour A3 Mega) et d'une version spécifique de la bibliothèque NCCL à l'aide d'un DaemonSet.

GPUDirect-TCPXO

Ce DaemonSet effectue les opérations suivantes :

Préinstallation pour configurer les configurations liées à GPUDirect-TCPXO.
Installe la bibliothèque NCCL et le binaire GPUDirect-TCPXO sur le nœud.
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-TCPXO.

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

Consultez le fichier manifeste nccl-tcpxo-installer.yaml Daemonset dans GitHub.

Déployez le DaemonSet :

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

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

Vérifiez l'état des pods DaemonSet :

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

Le résultat ressemble à ce qui suit :

# Output
nccl-tcpxo-installer-6c2pv                    1/1     Running   0          2m11s
nccl-tcpxo-installer-qgg82                    1/1     Running   0          2m11s

GPUDirect-TCPX

Ce DaemonSet effectue les opérations suivantes :

Installe la bibliothèque NCCL et le binaire GPUDirect-TCPX sur le nœud.
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:

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

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.

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

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. Les deux types de machines GPU H100 installent le même plug-in d'injecteur d'appareils NRI. Ce plug-in effectue les opérations suivantes:

Active l'interface de ressources de nœud (NRI) sur le nœud doté de GPU H100. La NRI est activée par défaut sur GKE 1.29 et versions ultérieures.
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 :

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

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.

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

Déployer une charge de travail de test

Dans cette section, vous allez déployer un exemple de charge de travail pour vérifier que NCCL et GPUDirect-TCPX ou GPUDirect-TCPXO fonctionnent comme prévu. Cet exemple de charge de travail effectue les opérations suivantes:

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

Pour déployer cet exemple de charge de travail, procédez comme suit:

GPUDirect-TCPXO

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

Examinez le fichier manifeste nccl-test-latest.yaml dans GitHub.

Déployez deux pods avec la charge de travail de test:

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

Une fois les pods déployés, déclenchez un test de collecte complète:

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

Le résultat ressemble à ce qui suit :

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

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.

Consultez le fichier manifeste ConfigMap nccl-config.yaml dans GitHub. Ce fichier manifeste déploie des scripts qui initialisent un test global de la bibliothèque NCCL et définissent des paramètres de configuration spécifiques à la bibliothèque NCCL.
Examinez le fichier manifeste de déploiement nccl-test-latest.yaml dans GitHub.

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

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

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 :

#                                                              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

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 et GPUDirect-TCPXO. Lorsque vous déployez vos charges de travail qui utilisent NCCL, définissez-les en tant que variables d'environnement pour optimiser les performances.

GPUDirect-TCPXO

## required

"LD_LIBRARY_PATH=\"${LD_LIBRARY_PATH}:/usr/local/nvidia/lib64\"",
"NCCL_FASTRAK_CTRL_DEV=eth0",
"NCCL_FASTRAK_IFNAME=eth1,eth2,eth3,eth4,eth5,eth6,eth7,eth8",
"NCCL_SOCKET_IFNAME=eth0",
"NCCL_CROSS_NIC=0",
"NCCL_ALGO=Ring,Tree",
"NCCL_PROTO=Simple,LL128",
"NCCL_MIN_NCHANNELS=4",
"NCCL_TUNER_PLUGIN=libnccl-tuner.so",
"NCCL_TUNER_CONFIG_PATH=/usr/local/nvidia/lib64/a3plus_tuner_config.textproto",
"NCCL_SHIMNET_GUEST_CONFIG_CHECKER_CONFIG_FILE=/usr/local/nvidia/lib64/a3plus_guest_config.textproto",
"NCCL_DYNAMIC_CHUNK_SIZE=524288",
"NCCL_P2P_NET_CHUNKSIZE=524288",
"NCCL_P2P_PCI_CHUNKSIZE=524288",
"NCCL_P2P_NVL_CHUNKSIZE=1048576",
"NCCL_FASTRAK_NUM_FLOWS=2",
"NCCL_FASTRAK_USE_SNAP=1",
"NCCL_FASTRAK_PLUGIN_ACCEPT_TIMEOUT_MS=600000",
"NCCL_FASTRAK_ENABLE_CONTROL_CHANNEL=0",
"NCCL_BUFFSIZE=8388608",
"CUDA_VISIBLE_DEVICES=0,1,2,3,4,5,6,7",
"NCCL_NET_GDR_LEVEL=PIX",
"NCCL_FASTRAK_ENABLE_HOTPATH_LOGGING=0",
"NCCL_FASTRAK_USE_LLCM=1",
"NCCL_NVLS_ENABLE=0"
## recommended, to log NCCL errors
"NCCL_DEBUG=WARN",
"NCCL_DEBUG_SUBSYS=INIT,NET,ENV,COLL,GRAPH"

Vous pouvez également définir toutes les configurations en même temps en procédant comme suit :

Ajoutez la paire clé-valeur suivante en tant que variable d'environnement dans le fichier manifeste de votre conteneur de charge de travail :
```
NCCL_LIB_DIR="/usr/local/nvidia/lib64"
```
Assurez-vous que le script nccl-env-profile.sh est exécuté au démarrage de votre conteneur de charge de travail. Par exemple, vous pouvez le faire dans la spécification de votre pod en remplaçant la commande du conteneur pour inclure les éléments suivants:
```
source ${NCCL_LIB_DIR}/nccl-env-profile.sh
```

GPUDirect-TCPX

"LD_LIBRARY_PATH=\"${LD_LIBRARY_PATH}:/usr/local/tcpx/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"

Compatibilité avec LL128

Le protocole de communication NCCL NVIDIA LL128 (low-latency 128) peut améliorer considérablement les performances des collectifs de petite à moyenne taille. GPUDirect-TCPXO est compatible avec le protocole LL128.

Pour utiliser LL128, assurez-vous que le fichier nccl-tcpxo-installer.yaml de la section Installer le binaire GPUDirect et configurer NCCL utilise la version d'image de conteneur suivante ou une version ultérieure:

us-docker.pkg.dev/gce-ai-infra/gpudirect-tcpxo/nccl-plugin-gpudirecttcpx-
dev:v1.0.8-1

Pour configurer LL128, procédez comme suit:

Pour la version du plug-in NCCL us-docker.pkg.dev/gce-ai-infra/gpudirect-tcpxo/nccl-plugin-gpudirecttcpx- dev:v1.0.8-1, procédez comme suit:
1. Dans le fichier manifeste de votre charge de travail, définissez la variable d'environnement suivante:
```
NCCL_LIB_DIR="/usr/local/nvidia/lib64
```
2. Configurez votre charge de travail pour qu'elle exécute le script nccl-env-profile-ll128.sh au démarrage du conteneur. Dans votre fichier manifeste de charge de travail, définissez la commande suivante:
```
source ${NCCL_LIB_DIR}/nccl-env-profile-ll128.sh
```
  Le script nccl-env-profile-ll128.sh contient les variables d'environnement suivantes:
```
NCCL_PROTO=Simple,LL128
NCCL_TUNER_CONFIG_PATH=/usr/local/nvidia/lib64/a3plus_tuner_config_ll128.textproto
NCCL_SHIMNET_GUEST_CONFIG_CHECKER_CONFIG_FILE=/usr/local/nvidia/lib64/a3plus_guest_config_ll128.textproto
```
Pour la version du plug-in NCCL us-docker.pkg.dev/gce-ai-infra/gpudirect-tcpxo/nccl-plugin-gpudirecttcpx-dev:v1.0.9-1 et les versions ultérieures, LL128 devient un paramètre par défaut. Par conséquent, l'utilisation du script nccl-env-profile.sh ou du script nccl-env-profile-ll128.sh active LL128. Pour désactiver LL128:
1. Dans le fichier manifeste de votre charge de travail, définissez la variable d'environnement suivante:
```
NCCL_LIB_DIR="/usr/local/nvidia/lib64
```
2. Configurez votre charge de travail pour qu'elle exécute le script nccl-env-profile-ll128.sh au démarrage du conteneur. Dans votre fichier manifeste de charge de travail, définissez la commande suivante:
```
source ${NCCL_LIB_DIR}/nccl-env-profile-simple.sh
```
  Le script nccl-env-profile-simple.sh contient les variables d'environnement suivantes:
```
NCCL_PROTO=Simple
NCCL_TUNER_CONFIG_PATH=/usr/local/nvidia/lib64/a3plus_tuner_config_simple.textproto
NCCL_SHIMNET_GUEST_CONFIG_CHECKER_CONFIG_FILE=/usr/local/nvidia/lib64/a3plus_tuner_config_simple.textproto
```

Collecter les journaux de débogage NCCL

Si vous ne parvenez pas à résoudre un problème avec NCCL, collectez les journaux NCCL avec des informations de débogage. Ces journaux contiennent des informations précieuses sur les opérations NCCL et peuvent vous aider à identifier la source de votre problème. Si vous ne parvenez pas à résoudre le problème, collectez ces journaux avant d'ouvrir une demande auprès de Cloud Customer Care. Ces journaux peuvent aider le Cloud Customer Care à résoudre votre problème plus rapidement.

Pour générer et collecter les journaux, procédez comme suit:

Ouvrez le fichier approprié pour définir les variables. Le fichier à modifier dépend de votre environnement. Si vous utilisez un cluster GKE, définissez les variables dans le fichier manifeste de votre pod ou de votre application. Si vous utilisez un cluster Slurm, définissez les variables dans vos scripts de tâche.
Définissez les variables d'environnement suivantes :
```
NCCL_DEBUG=INFO
NCCL_DEBUG_SUBSYS=INIT,NET,ENV,COLL,GRAPH
NCCL_DEBUG_FILE=/DIRECTORY/FILE_NAME.%h.%p
```
Ces variables configurent les paramètres de journalisation NCCL suivants:
- NCCL_DEBUG=INFO: imprime des informations de débogage.
- NCCL_DEBUG_SUBSYS: filtre les sous-systèmes pour lesquels NCCL collecte des informations de débogage. Nous vous recommandons de collecter les journaux des 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 dans le graphique.
  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: dirige la sortie de journalisation 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 niveaux 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 renvoie le nom d'hôte du nœud, tandis que %p renvoie l'ID de processus (PID) du processus qui génère le journal.
Pour générer des données pour vos journaux, exécutez un test NCCL. La manière d'exécuter ce test dépend du type de cluster que vous utilisez. Pour les clusters GKE, consultez la section Déployer et exécuter le test NCCL avec la planification tenant compte de la topologie (TAS). Pour les clusters Slurm, consultez la section Tester les performances réseau sur le cluster Slurm. Une fois le test NCCL exécuté, NCCL génère automatiquement les journaux sur tous les nœuds participants.
Collectez les journaux de tous les nœuds. Assurez-vous d'avoir collecté les journaux NCCL de tous les nœuds en vérifiant qu'ils contiennent les informations suivantes:
- Noms d'hôte de toutes les VM impliquées dans une charge de travail.
- PID de tous les processus pertinents sur la VM.
- Classement de tous les GPU utilisés par la charge de travail sur chaque VM.
Si vous ne savez pas où se trouvent les fichiers journaux, l'exemple suivant vous montre où NCCL les crée lorsque la variable NCCL_DEBUG_FILE est définie sur /tmp/nccl_log.%h.%p. Vous disposez de deux VM nommées a3plus-vm-1 et a3plus-vm-2, et chacune d'elles exécute huit processus dans le conteneur de charge de travail. Dans ce scénario, NCCL crée les fichiers journaux suivants dans le répertoire /tmp du conteneur de charge de travail sur chaque VM:
- Sur a3plus-vm-1: huit fichiers journaux nommés nccl_log.a3plus-vm-1.PID, où PID est l'ID de processus.
- Sur a3plus-vm-2: huit fichiers journaux nommés nccl_log.a3plus-vm-2.PID.
Examinez les journaux. Les entrées de journal NCCL ont le format suivant:
```
HOSTNAME:PID:TID [RANK] NCCL_MESSAGE
```
Ces entrées de journal contiennent les valeurs suivantes:
- HOSTNAME: nom d'hôte de la VM. Cette valeur identifie la VM utilisée lorsque NCCL a généré l'entrée de journal.
- PID: PID. Cette valeur identifie le processus qui a généré l'entrée de journal.
- TID: ID du thread. Cette valeur identifie le thread du processus utilisé lorsque NCCL a généré l'entrée de journal.
- RANK: ID du classement local. Cette valeur identifie le GPU utilisé lorsque NCCL a généré l'entrée de journal. Les rangs sont numérotés de 0 à N, où N correspond au nombre total de GPU impliqués dans le processus. Par exemple, si votre charge de travail s'exécute avec huit GPU par VM, chaque VM doit avoir huit valeurs de classement différentes (0 à 7).
- NCCL_MESSAGE: message descriptif qui fournit plus d'informations sur l'événement et inclut le code temporel de la création du journal par NCCL.
Exemple :
```
gke-a3plus-mega-np-2-aa33fe53-7wvq:1581:1634 [1] NCCL INFO 00:09:24.631392: NET/FasTrak plugin initialized.
```
Cet exemple comporte les valeurs suivantes:
- gke-a3plus-mega-np-2-aa33fe53-7wvq: nom d'hôte.
- 1581: ID du processus.
- 1634: ID du thread.
- 1: ID du classement local.
- NCCL INFO 00:09:24.631392: NET/FasTrak plugin initialized.: le message expliquant ce qui s'est passé.
Si vous ouvrez une demande d'assistance, empaquetez les journaux que vous avez collectés, ainsi que la sortie du test NCCL, dans un fichier ZIP. Incluez le fichier ZIP lorsque vous envoyez une demande d'assistance à Cloud Customer Care.
Pour arrêter la collecte des journaux de débogage NCCL, supprimez les variables que vous avez ajoutées à l'étape 2.

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.

En fonction du type de GPUDirect, procédez comme suit:

GPUDirect-TCPXO

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 tcpxo-daemon.

metadata:
  annotations:
    devices.gke.io/container.tcpxo-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
      - path: /dev/dmabuf_import_helper
    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"},
        {"interfaceName":"eth5","network":"vpc5"},
        {"interfaceName":"eth6","network":"vpc6"},
        {"interfaceName":"eth7","network":"vpc7"},
        {"interfaceName":"eth8","network":"vpc8"}
      ]

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
  - name: aperture-devices
    hostPath:
      path: /dev/aperture_devices

Ajoutez le conteneur suivant au fichier manifeste pour exécuter le service tcpxo-daemon. Remplacez (TCPXO_DAEMON_IMAGE) par la dernière image, us-docker.pkg.dev/gce-ai-infra/gpudirect-tcpxo/tcpgpudmarxd-dev:v1.0.15:

- name: tcpxo-daemon
  image: TCPXO_DAEMON_IMAGE
  imagePullPolicy: Always
  command: ["/bin/sh", "-c"]
  args:
    - |
      set -ex
      chmod 755 /fts/entrypoint_rxdm_container.sh
      /fts/entrypoint_rxdm_container.sh --num_hops=2 --num_nics=8 --uid= --alsologtostderr
  securityContext:
    capabilities:
      add:
        - NET_ADMIN
        - NET_BIND_SERVICE
  volumeMounts:
    - name: libraries
      mountPath: /usr/local/nvidia
    - name: sys
      mountPath: /hostsysfs
    - name: proc-sys
      mountPath: /hostprocsysfs
  env:
    - name: LD_LIBRARY_PATH
      value: /usr/local/nvidia/lib64

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

env:
- name: LD_LIBRARY_PATH
  value: /usr/local/nvidia/lib64
- name: NCCL_FASTRAK_LLCM_DEVICE_DIRECTORY
  value: /dev/aperture_devices

Ajoutez les volumesMounts suivants à chaque conteneur de GPU. Sans configuration aperture_devices, privileged:true est obligatoire pour les conteneurs GPU:
```
volumeMounts:
  - name: aperture-devices
    mountPath: /dev/aperture_devices
```
Vous pouvez également ajouter des variables d'environnement pour configurer les options NCCL. Pour en savoir plus, consultez Utiliser les paramètres de configuration de NCCL recommandés pour améliorer les performances.

Une spécification de pod terminée ressemble à ce qui suit :

apiVersion: v1
kind: Pod
metadata:
name: a3plus-workloads
annotations:
  devices.gke.io/container.tcpxo-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
    - path: /dev/dmabuf_import_helper
  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"},
      {"interfaceName":"eth5","network":"vpc5"},
      {"interfaceName":"eth6","network":"vpc6"},
      {"interfaceName":"eth7","network":"vpc7"},
      {"interfaceName":"eth8","network":"vpc8"}
    ]
...
containers:
  - name: tcpxo-daemon
    image: TCPXO_DAEMON_IMAGE
    imagePullPolicy: Always
    command: ["/bin/sh", "-c"]
    args:
      - |
        set -ex
        chmod 755 /fts/entrypoint_rxdm_container.sh
        /fts/entrypoint_rxdm_container.sh --num_hops=2 --num_nics=8 --uid= --alsologtostderr
    securityContext:
      capabilities:
        add:
          - NET_ADMIN
          - NET_BIND_SERVICE
    volumeMounts:
      - name: libraries
        mountPath: /usr/local/nvidia
      - name: sys
        mountPath: /hostsysfs
      - name: proc-sys
        mountPath: /hostprocsysfs
    env:
      - name: LD_LIBRARY_PATH
        value: /usr/local/nvidia/lib64
  - name: main-application-container
...
   env:
      - name: LD_LIBRARY_PATH
        value: /usr/local/nvidia/lib64
      - name: NCCL_FASTRAK_LLCM_DEVICE_DIRECTORY
        value: /dev/aperture_devices
    securityContext:
    volumeMounts:
      - name: aperture-devices
        mountPath: /dev/aperture_devices
    resources:
      limits:
        nvidia.com/gpu: 8
volumes:
  - name: libraries
    hostPath:
      path: /home/kubernetes/bin/nvidia
  - name: sys
    hostPath:
      path: /sys
  - name: proc-sys
    hostPath:
      path: /proc/sys
  - name: aperture-devices
    hostPath:
      path: /dev/aperture_devices

GPUDirect-TCPX

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"},
      ]

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

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

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
```
Remarque : Le chemin d'accès par défaut au socket tcpx est /tmp pour les conteneurs qui demandent des GPU. Si vous définissez la variable d'environnement NCCL_GPUDIRECTTCPX_UNIX_CLIENT_PREFIX sur une valeur autre que /tmp, GKE installe le volume tcpx-socket dans ce chemin mountPath.
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.
Ajoutez la variable d'environnement suivante à chaque conteneur de GPU :
```
env:
- name: LD_LIBRARY_PATH
  value: /usr/local/nvidia/lib64
```

Une spécification de pod terminée ressemble à ce qui suit :

apiVersion: v1
kind: Pod
metadata:
name: a3-gpu-workloads-example
labels:
  name: a3-gpu-workloads-example
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"}
    ]
spec:
containers:
  - name: tcpx-daemon
    image: us-docker.pkg.dev/gce-ai-infra/gpudirect-tcpx/tcpgpudmarxd-dev:v2.0.11
    imagePullPolicy: Always
    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
        readOnly: true
      - 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
  - name: a3-gpu-workloads-example
    ...
    volumeMounts:
      - name: tcpx-socket
        mountPath: /tmp
      - name: libraries
        mountPath: /usr/local/nvidia/lib64
        readOnly: true
    resources:
      limits:
        nvidia.com/gpu: 8
    env:
      - name: LD_LIBRARY_PATH
        value: /usr/local/nvidia/lib64
...
volumes:
  - name: libraries
    hostPath:
      path: /home/kubernetes/bin/nvidia/lib64
  - name: tcpx-socket
    emptyDir:
  - name: sys
    hostPath:
      path: /sys
  - name: proc-sys
    hostPath:
      path: /proc/sys

Étapes suivantes

Consultez les notes de version de GPUDirect-TCPXO.
En savoir plus sur les bonnes pratiques pour exécuter des charges de travail avec GPUDirect-TCPX(O)
Découvrez les bonnes pratiques de mise en réseau GKE.
Découvrez la famille de technologies GPUDirect de NVIDIA pour le transfert et l'accès aux données sur les GPU NVIDIA.
Découvrez la disponibilité actuelle des versions des GPU et comment demander des GPU dans GKE.

Maximiser la bande passante réseau de GPU dans les clusters en mode Standard Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

À propos des Google Cloud superordinateurs sur GPU

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

Aperçu de la procédure

Avant de commencer

Exigences

Limites

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

GPUDirect-TCPXO

GPUDirect-TCPX

Créer l'environnement GKE

GPUDirect-TCPXO

GPUDirect-TCPX

Créer un pool de nœuds GPU

GPUDirect-TCPXO

GPUDirect-TCPX

Installer le binaire GPUDirect et configurer NCCL

GPUDirect-TCPXO

GPUDirect-TCPX

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

Déployer une charge de travail de test

GPUDirect-TCPXO

GPUDirect-TCPX

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

GPUDirect-TCPXO

GPUDirect-TCPX

Compatibilité avec LL128

Collecter les journaux de débogage NCCL

Ajouter GPUDirect à vos fichiers manifestes

GPUDirect-TCPXO

GPUDirect-TCPX

Étapes suivantes

Maximiser la bande passante réseau de GPU dans les clusters en mode Standard