GPU-Netzwerkbandbreite mit GPUDirect-TCPX und Multi-Netzwerk maximieren

Auf dieser Seite wird erläutert, wie Sie die Netzwerkbandbreite und den Durchsatz für Hochleistungs-GPU-Arbeitslasten in Google Kubernetes Engine-Clustern (GKE) im Standardmodus maximieren. Diese Seite richtet sich an Entwickler von maschinellem Lernen (ML) und Plattformadministratoren, die ML-Arbeitslasten unterstützen. Sie sollten mit Netzwerktechnologien wie Netzwerkschnittstellenkarten (NICs) und TCP sowie mit Beschleunigertechnologien wie der NVIDIA Collective Communications Library (NCCL) vertraut sein.

Künstliche Intelligenz (KI), ML und Hochleistungs-Computing-Anwendungen erfordern eine leistungsstarke Beschleunigung, um die Leistung zu optimieren, indem die Abschlusszeiten von Jobs reduziert werden. ML-Modelle, die sich auf dialogorientierte KI und Bildgenerierung konzentrieren, erfordern beispielsweise hohe Skalierbarkeit und hohe Rechenleistung.

Informationen zu Google Cloud GPU-Supercomputern

Google Cloud verfügt über beschleunigungsoptimierte Supercomputer, die für skalierbare, große Modelle entwickelt wurden. Diese Maschinen bieten folgende Vorteile:

  • Acht NVIDIA H100-GPUs pro Maschine.
  • Bis zu 200 Gbit/s Bandbreite auf der primären NIC
  • Bis zu vier sekundäre NICs, die jeweils eine Bandbreite von bis zu 200 Gbit/s für die GPU-Datenübertragung unterstützen.

Eine vollständige Liste der Vorteile finden Sie in der Compute Engine-Dokumentation unter A3-Maschinenserie.

Ihre GKE-Arbeitslast muss alle verfügbaren GPUs und alle verfügbaren sekundären NICs auf einem einzelnen Knoten verwenden und einen erheblichen Teil der verfügbaren Bandbreite nutzen. Die in diesem Dokument beschriebene Lösung ist ideal für Arbeitslasten, die eine hohe Leistung, einen hohen Durchsatz und eine niedrige Latenz erfordern.

Erforderliche Features und Funktionen für maximale Bandbreite

Wenn Sie die Netzwerkbandbreite in GPU-Supercomputerknoten maximieren möchten, verwenden Sie alle der folgenden Features:

  • GPUDirect-TCPX: Reduzieren Sie den Aufwand für die Übertragung von Paketnutzlasten zu und von GPUs, was den Durchsatz im Vergleich zu GPUs, die GPUDirect-TCPX nicht verwenden, erheblich verbessert.
  • gVNIC: Aktivieren Sie GPUDirect-TCPX-Funktionen wie Paketheader-Aufteilung, Ablaufsteuerung und Zwischenspeicherverwaltung. gVNIC ist für die Verwendung von GPUDirect-TCPX erforderlich. Weitere Informationen zu gVNIC finden Sie unter Netzwerkgeschwindigkeit für GPU-Knoten erhöhen.
  • Multi-Netzwerk: Fügen Sie der beschleunigungsoptimierten Maschine sekundäre NICs hinzu. Für A3-Maschinen werden vier zusätzliche NICs hinzugefügt. Jede NIC ist einem separaten Subnetz in einer eigenen VPC zugeordnet, um Konflikte zu vermeiden. Weitere Informationen zur Unterstützung für mehrere Netzwerke finden Sie unter Unterstützung mehrerer Netzwerke für Pods einrichten.
  • Platzierungsrichtlinien: Verwenden Sie eine Richtlinie für Ressourcenplatzierungen, um alle GPU-Knoten für eine bestimmte Arbeitslast auf physisch naheliegenden Servern zu platzieren, um die Latenz zu minimieren. Weitere Informationen finden Sie unter Kompakte Platzierung für GKE-Knoten definieren.

Verfahrensüberblick

Gehen Sie folgendermaßen vor, um alle diese Funktionen zu verwenden:

  1. Virtual Private Cloud (VPC) und Subnetze erstellen
  2. GKE-Umgebung erstellen:
    1. Cluster mit aktiviertem Multi-Networking erstellen
    2. Erstellen Sie einen Knotenpool mit den folgenden Eigenschaften:
      1. gVNIC aktiviert
      2. Multi-Netzwerk-Subnetze, die für jede sekundäre NIC angegeben sind
      3. A3-Maschinenserie mit H100-GPUs (vier sekundäre NICs und acht GPUs) zur Unterstützung der Knoten
      4. Neueste installierte NVIDIA-Treiber
  3. GPUDirect-TCPX-Binärdatei und NCCL-Plug-in installieren
  4. Testarbeitslast bereitstellen, um die GPUDirect-TCPX-Einrichtung zu prüfen

Hinweise

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

  • Aktivieren Sie die Google Kubernetes Engine API.
    • Google Kubernetes Engine API aktivieren
  • Wenn Sie die Google Cloud CLI für diese Aufgabe verwenden möchten, müssen Sie die gcloud CLI installieren und dann initialisieren. Wenn Sie die gcloud CLI bereits installiert haben, rufen Sie die neueste Version mit gcloud components update ab.
  • Achten Sie darauf, dass Ihr Kontingent für H100-GPUs ausreicht. Informationen zum Anfordern eines höheren Kontingents finden Sie unter GPU-Kontingente.

Voraussetzungen

  • GPUDirect-TCPX wird in GKE Version 1.27 oder höher unterstützt und erfordert Folgendes:
    • Verwenden Sie für die GKE-Version 1.27 die GKE-Patchversion 1.27.7-gke.1121000 oder höher.
    • Verwenden Sie für die GKE-Version 1.28 die GKE-Patchversion 1.28.8-gke.1095000 oder höher.
    • Verwenden Sie für die GKE-Version 1.29 die GKE-Patchversion 1.29.3-gke.1093000 oder höher.
  • Ihre GPU-Knoten müssen die NVIDIA-Treiberversion 535 oder höher verwenden.
  • Sie müssen GKE Dataplane V2 verwenden.

Beschränkungen

Es gelten folgende Einschränkungen:

  • Sie können GPUDirect-TCPX nicht in Autopilot-Clustern verwenden
  • Sie können GPUDirect-TCPX nur in GKE-Version 1.27 oder höher und mit den folgenden Patchversionen verwenden:
    • Verwenden Sie für die GKE-Version 1.27 die GKE-Patchversion 1.27.7-gke.1121000 oder höher.
    • Verwenden Sie für die GKE-Version 1.28 die GKE-Patchversion 1.28.8-gke.1095000 oder höher.
    • Verwenden Sie für die GKE-Version 1.29 die GKE-Patchversion 1.29.3-gke.1093000 oder höher.
  • Sie können GPUDirect-TCPX nicht mit GPUs mit mehreren Instanzen oder GPU-Timesharing verwenden.
  • Sie können NCCL FastSocket nicht verwenden.
  • Ihre Umgebung muss das Festlegen von hostNetwork: true in der Pod-Spezifikation unterstützen

  • Wenn Sie lokale SSDs für Pod-Speicher verwenden möchten, müssen Sie explizit die genaue Anzahl der lokalen SSDs angeben, die an die zugrunde liegende A3-VM angehängt werden sollen. Verwenden Sie dazu das Flag --ephemeral-storage-local-ssd=count=SSD_COUNT für sitzungsspezifischen Speicher oder das Flag --local-nvme-ssd-block=count=SSD_COUNT für den Blockzugriff. Wenn Sie dieses Flag weglassen, können Sie die lokalen SSDs nicht in Ihren Pods verwenden. Diese Flags sind nur erforderlich, wenn Sie lokale SSDs für den Datenzugriff verwenden möchten.

    Die unterstützte Maschinengröße in GKE ist a3-highgpu-8g und die entsprechende Anzahl lokaler SSDs beträgt 16.

VPCs und Subnetze erstellen

Erstellen Sie in Ihrem Projekt für jede virtuelle NIC, die Sie Ihren Knoten hinzufügen, separate VPC-Netzwerke. Jede VPC muss ein Subnetz und eine Firewallregel haben, die internen Netzwerktraffic zulässt. Zur Maximierung Ihrer Bandbreite empfehlen wir die Erstellung von vier neuen Netzwerken.

  1. Aktualisieren Sie das standardmäßige VPC-Subnetzwerk in Ihrem Projekt, um sekundäre IP-Adressbereiche für Pods und für Services hinzuzufügen:

    gcloud compute networks subnets update DEFAULT_NETWORK \
    --region=REGION \
    --add-secondary-ranges="CLUSTER_NAME-pods=POD_IP_ADDRESS_RANGE,CLUSTER_NAME-services=SERVICE_IP_ADDRESS_RANGE"

    Ersetzen Sie Folgendes:

    • DEFAULT_NETWORK: der Name des Standardsubnetzes in Ihrem Projekt.
    • REGION: die Region des Standardsubnetzes.
    • CLUSTER_NAME: Name Ihres GKE-Clusters.
    • POD_IP_ADDRESS_RANGE: der IP-Adressbereich für Pods im Cluster in CIDR-Notation. Beispiel: 10.64.0.0/19.
    • SERVICE_IP_ADDRESS_RANGE: der IP-Adressbereich für Dienste, die im Cluster verwendet werden sollen, in CIDR-Notation. Muss sich vom Pod-Bereich unterscheiden. Beispiel: 10.65.0.0/19.

  2. Erstellen Sie in Ihrem Projekt die VPC-Netzwerke für GPUDirect-TCPX mit jeweils einem Subnetz und einer Firewallregel:

    for N in $(seq 1 4); do
gcloud compute networks create PROJECT_ID-net-$N \
    --subnet-mode=custom \
    --mtu=8244

gcloud compute networks subnets create PROJECT_ID-sub-$N \
    --network=PROJECT_ID-net-$N \
    --region=REGION \
    --range=SUBNET_RANGE

gcloud compute firewall-rules create PROJECT_ID-internal-$N \
  --network=PROJECT_ID-net-$N \
  --action=ALLOW \
  --rules=tcp:0-65535,udp:0-65535,icmp \
  --source-ranges=SOURCE_RANGE
done

    Ersetzen Sie Folgendes:

    • PROJECT_ID ist Ihre Google Cloud-Projekt-ID.
    • REGION: Die Compute Engine-Region für jedes Subnetz
    • SUBNET_RANGE: der IP-Adressbereich jedes Subnetzes in CIDR-Notation. Dieser Beispielbefehl geht für vier Subnetze durch. Verwenden Sie daher eine Variable, um die IP-Adresse für jedes Subnetz zu ändern. Geben Sie beispielsweise 192.168.$N.0/24 an, damit das erste Subnetz 192.168.1.0/24 verwendet, das zweite Subnetz 192.168.2.0/24 verwendet usw.
    • SOURCE_RANGE: Der Quell-IP-Adressbereich für die Firewallregel, um eingehenden Traffic in CIDR-Notation zuzulassen. Beispiel: 192.168.0.0/16

  3. Prüfen Sie, ob die Netzwerke erstellt wurden:

    gcloud compute networks list

GKE-Umgebung erstellen

Erstellen Sie einen neuen GKE-Cluster, der Multi-Netzwerk (Vorschau) verwendet, und erstellen Sie einen GPU-Knotenpool, der A3-Maschinen mit angehängten H100-GPUs und vier zusätzlichen NICs verwendet. Sie können einen vorhandenen Cluster nicht aktualisieren, um Multi-Netzwerk zu verwenden.

  1. Erstellen Sie einen Cluster.

    gcloud container clusters create CLUSTER_NAME \
    --location=LOCATION \
    --cluster-version=VERSION \
    --enable-dataplane-v2 --enable-ip-alias \
    --enable-multi-networking \
    --no-enable-autoupgrade \
    --cluster-secondary-range-name=CLUSTER_NAME-pods \
    --services-secondary-range-name=CLUSTER_NAME-services

    Ersetzen Sie Folgendes:

    • CLUSTER_NAME: Der Name des neuen Clusters.
    • LOCATION: die Compute Engine-Region für den Cluster.
    • VERSION: die GKE-Version für den Cluster. Muss eine unterstützte Version sein, wie im Abschnitt „Anforderungen“ beschrieben.

    Mit diesem Befehl wird auch explizit die sekundäre IP-Adresse für Pods und Dienste für den Cluster angegeben, den Sie im vorherigen Abschnitt erstellt haben.

  2. Erstellen Sie im Cluster Netzwerk- und GKENetworkParamSet-Ressourcen, die den von Ihnen erstellten VPC-Netzwerken und Subnetzwerken entsprechen:

    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: PROJECT_ID-net-1
  vpcSubnet: PROJECT_ID-sub-1
  deviceMode: NetDevice
---
apiVersion: networking.gke.io/v1
kind: GKENetworkParamSet
metadata:
  name: vpc2
spec:
  vpc: PROJECT_ID-net-2
  vpcSubnet: PROJECT_ID-sub-2
  deviceMode: NetDevice
---
apiVersion: networking.gke.io/v1
kind: GKENetworkParamSet
metadata:
  name: vpc3
spec:
  vpc: PROJECT_ID-net-3
  vpcSubnet: PROJECT_ID-sub-3
  deviceMode: NetDevice
---
apiVersion: networking.gke.io/v1
kind: GKENetworkParamSet
metadata:
  name: vpc4
spec:
  vpc: PROJECT_ID-net-4
  vpcSubnet: PROJECT_ID-sub-4
  deviceMode: NetDevice
EOF

    Diese Ressourcen weisen GKE an, die NICs für GPU-Traffic im Passthrough-Modus zu konfigurieren. GKE wendet keine integrierte Netzwerkprogrammierung mit eBPF auf diesen Traffic an.

  3. Erstellen Sie einen Knotenpool für die H100-GPUs:

    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=PROJECT_ID-net-1,subnetwork=PROJECT_ID-sub-1 \
    --additional-node-network=network=PROJECT_ID-net-2,subnetwork=PROJECT_ID-sub-2 \
    --additional-node-network=network=PROJECT_ID-net-3,subnetwork=PROJECT_ID-sub-3 \
    --additional-node-network=network=PROJECT_ID-net-4,subnetwork=PROJECT_ID-sub-4 \
    --enable-gvnic \
    --no-enable-autoupgrade \
    [--ephemeral-storage-local-ssd=count=16]

    Ersetzen Sie NODE_POOL_NAME durch den Namen des Knotenpools.

    Wenn dieser Befehl fehlschlägt, haben Sie möglicherweise nicht genügend H100-GPU-Kontingent in Ihrem Projekt. Prüfen Sie, ob Ihr Kontingent ausreicht, und führen Sie den Befehl noch einmal aus.

  4. Rufen Sie eine Liste der Knoten im Cluster ab:

    kubectl get nodes

  5. Prüfen Sie, ob jeder GPU-Knoten acht GPUs hat:

    kubectl describe node NODE_NAME

    Die Ausgabe sieht in etwa so aus:

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

GPUDirect-TCPX installieren und NCCL konfigurieren

In diesem Abschnitt erfahren Sie, wie Sie die GPUDirect-TCPX-Binärdatei und eine bestimmte NCCL mit einem DaemonSet installieren.

  1. Prüfen Sie das DaemonSet-Manifest:

    apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: nccl-tcpx-installer
  namespace: kube-system
  labels:
    k8s-app: nccl-tcpx-installer
spec:
  selector:
    matchLabels:
      k8s-app: nccl-tcpx-installer
  updateStrategy:
    type: RollingUpdate
  template:
    metadata:
      labels:
        name: nccl-tcpx-installer
        k8s-app: nccl-tcpx-installer
    spec:
      priorityClassName: system-node-critical
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
              - matchExpressions:
                  - key: cloud.google.com/gke-accelerator
                    operator: In
                    values:
                      - nvidia-h100-80gb
      tolerations:
        - operator: "Exists"
      hostNetwork: true
      hostPID: true
      volumes:
        - name: var-lib
          hostPath:
            path: /var/lib
        - name: tcpx
          hostPath:
            path: /var/lib/tcpx
        - name: library-dir-host
          hostPath:
            path: /home/kubernetes/bin
      initContainers:
        - image: us-docker.pkg.dev/gce-ai-infra/gpudirect-tcpx/nccl-plugin-gpudirecttcpx-dev:v3.1.9
          name: nccl-tcpx-installer
          resources:
            requests:
              cpu: 150m
          securityContext:
            privileged: true
          volumeMounts:
            - name: var-lib
              mountPath: /var/lib
            - name: library-dir-host
              mountPath: /usr/local
          command: ["/bin/sh", "-c"]
          args:
            - |
              set -ex
              /scripts/container_entry.sh install --install-nccl
              mkdir -p /usr/local/nvidia/lib64
              cp -r /var/lib/tcpx/lib64/. /usr/local/nvidia/lib64
              echo "installation finishes"
      containers:
        - image: "gcr.io/google-containers/pause:2.0"
          name: pause

    Dieses DaemonSet tut Folgendes:

    1. Installiert eine NCCL-Bibliothek und die GPUDirect-TCPX-Binärdatei auf dem Knoten.
    2. Speichert die Bibliothek und die Binärdatei im Verzeichnis /home/kubernetes/bin/nvidia/lib64 der VM. Standardmäßig stellt GKE dieses Verzeichnis im GPU-Container /usr/local/nvidia/lib64 bereit, der NCCL und GPUDirect-TCPX verwenden muss.

  2. Stellen Sie das DaemonSet bereit:

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

    Die Ausführung des NCCL-Plug-ins dauert ungefähr zwei Minuten.

  3. Prüfen Sie den Status der DaemonSet-Pods:

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

    Die Ausgabe sieht in etwa so aus:

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

Testarbeitslast bereitstellen

In diesem Abschnitt stellen Sie eine Beispielarbeitslast bereit, um zu prüfen, ob NCCL und GPUDirect-TCPX wie erwartet funktionieren. Diese Arbeitslast enthält einen Sidecar-Container mit dem Namen tcpx-daemon, der einen Dienst ausführt, der es dem Pod ermöglicht, GPUDirect-TCPX zu verwenden. Sie müssen diesen Sidecar-Container allen Pods in Ihrer eigenen Umgebung hinzufügen, die GPUDirect-TCPX verwenden müssen. Ein Snippet der erforderlichen Felder, die Sie Ihren Manifesten hinzufügen können, finden Sie in diesem Dokument unter GPUDirect-TCPX zu Ihrem Manifest hinzufügen.

  1. ConfigMap-Manifest nccl-config-default.yaml in GitHub prüfen Dieses Manifest stellt Scripts bereit, die einen NCCL-Allgather-Test initialisieren und NCCL-spezifische Umgebungsvariablen festlegen.

  2. Prüfen Sie das Manifest nccl-test.yaml in GitHub. Das Manifest tut Folgendes:

    1. Stellt zwei Pods bereit, die jeweils auf einem Knoten mit H100-GPUs ausgeführt werden.
    2. Stellt in jedem Pod einen Sidecar-Container mit dem Namen tcpx-daemon bereit, damit diese Pods GPUDirect-TCPX verwenden können.

  3. Stellen Sie die ConfigMap und die Testarbeitslast bereit:

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

  4. Führen Sie die folgenden Befehle aus, um einen NCCL-Test-All-Gather-Test für die Knoten auszulösen:

    head_pod=$(kubectl get pods --output='custom-columns=POD:.metadata.name' --no-headers | head -n1)

nodes=($(kubectl get pods --output='custom-columns=NODE:.spec.nodeName' --no-headers))

kubectl exec --stdin --tty --container=nccl-test ${head_pod} -- /configs/allgather.sh ${nodes[@]}

    Die Ausgabe sieht in etwa so aus:

    #                                                              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

Mit NCCL-Umgebungsvariablen die Leistung verbessern

Sie können optional bestimmte Umgebungsvariablen festlegen, um die Leistung Ihrer Arbeitslasten zu verbessern, die NCCL verwenden. Die ConfigMap nccl-config-default.yaml, die Sie im Abschnitt Testarbeitslast bereitstellen bereitstellen, legt standardmäßig einige NCCL-Variablen fest. Die Variablenkonfiguration wird im Skript run-nccl.sh in der ConfigMap gespeichert.

Stellen Sie ein aktualisiertes ConfigMap-Manifest mit geänderten Variablen bereit, um die NCCL-Umgebungsvariablen zu ändern. Das nccl-config-latest.yaml-Manifest in GitHub enthält jede empfohlene Variable mit einem aktualisierten run-nccl.sh-Skript.

Mit dem folgenden Befehl wird die vorhandene ConfigMap mit den Standardvariablen mit der aktualisierten nccl-config-latest.yaml-ConfigMap aktualisiert:

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

Kubernetes benötigt ungefähr zwei Minuten, um die ConfigMap zu aktualisieren.

Führen Sie den folgenden Befehl aus, um die NCCL-Umgebungsvariablen zu prüfen:

head_pod=$(kubectl get pods --output='custom-columns=POD:.metadata.name' --no-headers | head -n1)

kubectl exec --stdin --tty --container=nccl-test ${head_pod} -- cat /configs/run-nccl.sh

GPUDirect-TCPX zu Manifesten hinzufügen

Dieser Abschnitt enthält die Pflichtfelder, die Sie Ihren Kubernetes-Manifesten hinzufügen müssen, damit Ihre Pods GPUDirect-TCPX verwenden können.

  1. Fügen Sie der Pod-Spezifikation die folgenden Felder hinzu:

    spec:
  hostNetwork: true
  dnsPolicy: ClusterFirstWithHostNet
  volumes:
  - name: libraries
    hostPath:
      path: /home/kubernetes/bin/nvidia/lib64
  - name: tcpx-socket
    hostPath:
      path: /run/tcpx

  2. Fügen Sie dem Manifest den folgenden Container hinzu, um den Dienst tcpx-daemon auszuführen:

    - 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:
    privileged: true
  volumeMounts:
    - name: libraries
      mountPath: /usr/local/nvidia/lib64
    - name: tcpx-socket
      mountPath: /run/tcpx
  env:
    - name: LD_LIBRARY_PATH
      value: /usr/local/nvidia/lib64

  3. Fügen Sie allen Containern, die GPUs anfordern, die folgenden Volume-Bereitstellungen hinzu:

    volumeMounts:
- name: tcpx-socket
  mountPath: /tmp
- name: libraries
  mountPath: /usr/local/nvidia/lib64

  4. Fügen Sie jedem GPU-Container die folgende Umgebungsvariable hinzu:

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

  5. Fügen Sie optional Umgebungsvariablen hinzu, um NCCL-Optionen zu konfigurieren. Weitere Informationen finden Sie im Abschnitt NCCL-Umgebungsvariablen verwenden, um die Leistung zu verbessern in diesem Dokument.

Eine fertige Pod-Spezifikation sieht so aus:

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
  labels:
    name: example-pod
spec:
  hostNetwork: true
  dnsPolicy: ClusterFirstWithHostNet
  containers:
  - 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:
      privileged: true
    volumeMounts:
      - name: libraries
        mountPath: /usr/local/nvidia/lib64
      - name: tcpx-socket
        mountPath: /run/tcpx
    env:
      - name: LD_LIBRARY_PATH
        value: /usr/local/nvidia/lib64
    - name: nccl-test
      image: us-docker.pkg.dev/gce-ai-infra/gpudirect-tcpx/nccl-plugin-gpudirecttcpx:v3.1.2
      imagePullPolicy: Always
      command:
        - /bin/sh
        - -c
        - "while true; do echo hello; sleep 1; done"
      env:
        - name: LD_LIBRARY_PATH
          value: /usr/local/nvidia/lib64
      volumeMounts:
        - name: tcpx-socket
          mountPath: /run/tcpx
        - name: libraries
          mountPath: /usr/local/nvidia/lib64
      resources:
        limits:
          nvidia.com/gpu: 8
  volumes:
    - name: libraries
      hostPath:
        path: /home/kubernetes/bin/nvidia/lib64
    - name: tcpx-socket
      hostPath:
        path: /run/tcpx