GKE bietet eine zentrale Plattform für die Ausführung verschiedener Arbeitslasten für Ihre Organisationen, wodurch der Betriebsaufwand für die Verwaltung mehrerer Plattformen reduziert wird. Sie können Arbeitslasten wie verteiltes Hochleistungsvortraining, Modellabstimmung, Modellinferenz, Anwendungsbereitstellung und unterstützende Dienste ausführen.
Auf dieser Seite erfahren Sie, wie Sie GKE Standard- und Autopilot-Cluster (Google Kubernetes Engine) mit GPUDirect-TCPX, gVNIC und Multi-Networking erstellen.
Diese Seite richtet sich an Entwickler von maschinellem Lernen (ML) und Plattformadministratoren, die ML-Arbeitslasten ermöglichen. Weitere Informationen zu gängigen Rollen und Beispielaufgaben, auf die wir in Google Cloud Inhalten verweisen, finden Sie unter Häufig verwendete GKE-Nutzerrollen und -Aufgaben.
Anwendungen für künstliche Intelligenz (KI), maschinelles Lernen (ML) und Hochleistungs-Computing (HPC) erfordern eine leistungsstarke Beschleunigung, um die Leistung zu optimieren und die Ausführungszeiten von Jobs zu verkürzen. ML-Modelle, die sich auf konversationelle KI und die Bildgenerierung konzentrieren, erfordern beispielsweise eine hohe Skalierbarkeit und Rechenleistung.
Auf dieser Seite wird davon ausgegangen, dass Sie mit Netzwerktechnologien wie Netzwerkschnittstellenkarten (NICs) und TCP sowie mit Beschleunigertechnologien wie der NVIDIA Collective Communications Library (NCCL) vertraut sind.
Google Cloud GPU-Supercomputer
Google Cloud bietet beschleunigungsoptimierte Supercomputer, die für skalierbare, massive Modelle entwickelt wurden. Diese GPU-Maschinentypen können eine Netzwerkbandbreite von bis zu 3.600 Gbit/s erreichen.
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 für Arbeitslasten konzipiert, die hohe Leistung, hohen Durchsatz und niedrige Latenz erfordern.
Erforderliche Funktionen für maximale Bandbreite
Um die Netzwerkbandbreite in GPU-Supercomputerknoten zu maximieren, müssen Sie die folgenden Funktionen verwenden:
- GPUDirect-Netzwerkstack: A3 Edge unterstützt drei Netzwerkstacks für benutzerdefinierten Remote Direct Memory Access (RDMA). A3 Edge-Maschinen verwenden GPUDirect-TCPX, um den Overhead für die Übertragung von Paketnutzlasten an und von GPUs zu reduzieren. Dadurch wird der Durchsatz im Vergleich zu GPUs, die GPUDirect nicht verwenden, erheblich verbessert.
- gVNIC: Aktivieren Sie GPUDirect-Funktionen wie Paketheaderaufteilung, Flusssteuerung und Verwaltung des Zwischenspeichers. gVNIC ist erforderlich, um GPUDirect-TCPX zu verwenden. Weitere Informationen zu gVNIC finden Sie unter Netzwerkgeschwindigkeit für GPU-Knoten erhöhen.
Außerdem müssen Sie die folgenden Funktionen aktivieren und konfigurieren:
- Multi-Netzwerk: Fügen Sie der beschleunigungsoptimierten Maschine sekundäre NICs hinzu. Jede NIC ist einem separaten Subnetz in einem 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 zur Ressourcenplatzierung, um alle GPU-Knoten für eine bestimmte Arbeitslast auf physisch nahe Servern zu platzieren und so die Latenz zu minimieren. Weitere Informationen finden Sie unter Kompakte Platzierung für GKE-Knoten definieren.
Prozedurübersicht
So verwenden Sie GPUDirect-TCPX, gVNIC, Multi-Networking und kompakte Platzierungsrichtlinien zusammen:
- VPCs (Virtual Private Clouds) und Subnetze erstellen
- GKE-Umgebung erstellen
- GPUDirect-Binärprogramm und NCCL-Plug-in installieren
- NRI-Geräte-Injector-Plug-in bereitstellen
- Testarbeitslast bereitstellen, um die GPUDirect-Einrichtung zu überprüfen
- GPUDirect für eigene Arbeitslasten verwenden
Hinweis
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 dem Befehl
gcloud components updateab. In früheren gcloud CLI-Versionen werden die Befehle in diesem Dokument möglicherweise nicht unterstützt.
- Prüfen Sie, ob Sie Kapazität für A3 Edge-VMs haben. Um diese Kapazität zu erhalten, müssen Sie zuerst eine der Verbrauchsoptionen auswählen. Für die Anleitung auf dieser Seite können Sie entweder On-Demand-Kapazität, On-Demand-Reservierungen oder vorausschauende Reservierungen für bis zu 90 Tage (im Kalendermodus) verwenden. Nachdem Sie eine Nutzungsoption ausgewählt haben, folgen Sie der entsprechenden Anleitung, um Kapazität über die von Ihnen ausgewählte Nutzungsoption zu erhalten.
- Prüfen Sie, ob Sie ein ausreichendes Kontingent für H100-GPUs haben. Informationen zum Anfordern eines höheren Kontingents finden Sie unter GPU-Kontingente.
Voraussetzungen
Für GPUDirect-TCPX gelten die folgenden Anforderungen:
Standard
- GPUDirect-TCPX wird mit allen verfügbaren GKE-Nebenversionen mit bestimmten Patchversionen unterstützt:
- Für GKE-Version 1.30 bis 1.33 können Sie eine beliebige Patchversion verwenden.
- Verwenden Sie für GKE-Version 1.34 die Patchversion 1.34.5-gke.1153000 oder höher.
- Verwenden Sie für GKE-Version 1.35 die Patchversion 1.35.2-gke.1485000 oder höher.
- Für GKE-Version 1.36 oder höher können Sie eine beliebige Patch-Version verwenden.
- Der GKE-Knoten muss ein Knoten-Image für Container-Optimized OS (COS) verwenden. Ubuntu- und Windows-Knoten-Images werden nicht unterstützt.
- Ihre GPU-Knoten müssen die NVIDIA-Treiberversion 535 oder höher verwenden.
- Sie müssen GKE Dataplane V2 verwenden.
- In GKE-Version 1.34 und höher müssen Sie Version 3.1.9 oder höher des GPUDirect-TCPX-Installers und Version 2.0.12 oder höher des GPUDirect-TCPX-Sidecars verwenden. Die Versionen des Installers und des Sidecars haben eine 1:1-Zuordnung und müssen übereinstimmen. Die Installer-Version 3.1.12 entspricht beispielsweise der Sidecar-Version 2.0.15. Weitere Informationen zu Installer- und Sidecar-Versionen finden Sie in den Versionshinweisen zu GPUDirect-TCPX.
- Bei GPUDirect-TCPX-Arbeitslasten, die in mehreren Knotenpools ausgeführt werden, müssen sich alle Knotenpools in denselben Compute Engine-Zonen befinden und dieselben Netzwerkeinstellungen wie VPCs und Subnetze verwenden.
Autopilot
- Damit Sie GPUDirect-TCPX verwenden können, muss in Ihrem Cluster die folgende GKE-Mindestpatchversion ausgeführt werden:
- Verwenden Sie für GKE-Version 1.31 die Patchversion 1.31.1-gke.1621000 oder höher.
- Für GKE-Version 1.32 bis 1.33 können Sie eine beliebige Patchversion verwenden.
- Verwenden Sie für GKE-Version 1.34 die Patchversion 1.34.5-gke.1153000 oder höher.
- Verwenden Sie für GKE-Version 1.35 die Patchversion 1.35.2-gke.1485000 oder höher.
- Für GKE-Version 1.36 oder höher können Sie eine beliebige Patch-Version verwenden.
- Ihre GPU-Knoten müssen die NVIDIA-Treiberversion 535 oder höher verwenden.
- Sie müssen GKE Dataplane V2 verwenden.
- In GKE-Version 1.34 und höher müssen Sie Version 3.1.9 oder höher des GPUDirect-TCPX-Installers und Version 2.0.12 oder höher des GPUDirect-TCPX-Sidecars verwenden. Die Versionen des Installers und des Sidecars haben eine 1:1-Zuordnung und müssen übereinstimmen. Die Installer-Version 3.1.12 entspricht beispielsweise der Sidecar-Version 2.0.15. Weitere Informationen zu Installer- und Sidecar-Versionen finden Sie in den GPUDirect-TCPX-Versionshinweisen.
- Für GPUDirect-TCPX-Arbeitslasten, die in mehreren Knotenpools ausgeführt werden, müssen sich alle Knotenpools in denselben Compute Engine-Zonen befinden und dieselben Netzwerkeinstellungen wie VPCs und Subnetze verwenden.
Beschränkungen
Es gelten folgende Einschränkungen:
- GPUDirect-TCPX wird nicht mit GPUs mit mehreren Instanzen, GPU-Timesharing oder NVIDIA MPS unterstützt.
- Sie können NCCL FastSocket nicht mit GPUDirect-TCPX verwenden.
- Ihre GKE-Arbeitslast muss alle verfügbaren GPUs und alle verfügbaren sekundären NICs auf einem einzelnen Knoten verwenden. Mehrere Pods können GPUDirect-TCPX nicht auf einem einzelnen Knoten verwenden.
VPCs und Subnetze erstellen
Erstellen Sie in Ihrem Projekt separate VPC-Netzwerke für jede virtuelle NIC, die Sie Ihren Knoten hinzufügen. Jedes VPC-Netzwerk muss ein Subnetz und eine Firewallregel haben, die internen Netzwerkverkehr zulässt.
Um die Bandbreite zu maximieren, empfehlen wir, vier neue Netzwerke zu erstellen.
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 doneErsetzen Sie Folgendes:
PROJECT_ID: Projekt-ID in Google Cloud .REGION: die Compute Engine-Region für jedes Subnetz.SUBNET_RANGE: Der IP-Adressbereich jedes Subnetzes in CIDR-Notation. In diesem Beispielbefehl werden vier Subnetze durchlaufen. Sie sollten also eine Variable verwenden, um die IP-Adresse für jedes Subnetz zu ändern. Geben Sie beispielsweise192.168.$N.0/24an, damit das erste Subnetz192.168.1.0/24, das zweite Subnetz192.168.2.0/24usw. verwendet.SOURCE_RANGE: Der Quell-IP-Adressbereich für die Firewallregel, um eingehenden Traffic zuzulassen, in CIDR-Notation. Beispiel:192.168.0.0/16
Prüfen Sie, ob die Netzwerke erstellt wurden:
gcloud compute networks list
GKE-Umgebung erstellen
Erstellen Sie einen neuen GKE-Cluster, der Multi-Networking (Vorabversion) verwendet, und einen GPU-Knotenpool mit den folgenden Merkmalen:
- gVNIC aktiviert
- Für jede sekundäre NIC angegebene Subnetze für mehrere Netzwerke
- A3 Edge-Maschinenserie mit H100-GPUs zur Unterstützung der Knoten
- Neueste NVIDIA-Treiber installiert
Sie können einen vorhandenen Cluster nicht aktualisieren, um mehrere Netzwerke zu verwenden.
Erstellen Sie einen 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_IDErsetzen Sie Folgendes:
CLUSTER_NAME: Der Name des neuen Clusters.CONTROL_PLANE_LOCATION: der Compute Engine-Standort der Steuerungsebene Ihres Clusters. Geben Sie für regionale Cluster eine Region und für zonale Cluster eine Zone an.VERSION: Eine GKE-Version, die GPUDirect-TCPX unterstützt, wie unter Anforderungen beschrieben.
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-adminErsetzen Sie Folgendes:
CLUSTER_NAME: Der Name des neuen Clusters.CONTROL_PLANE_LOCATION: die Compute Engine-Region der Steuerungsebene des Clusters.VERSION: Eine GKE-Version, die GPUDirect-TCPX unterstützt, wie unter Anforderungen beschrieben.
Erstellen Sie im Cluster die Ressourcen „Network“ und „GKENetworkParamSet“, 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: 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 EOFDiese 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.
GPU-Knotenpool erstellen (nur Standard)
Erstellen Sie einen Knotenpool für die H100-GPUs:
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_NAMEErsetzen Sie
NODE_POOL_NAMEdurch den Namen des Knotenpools.Verwenden Sie die Flags
--placement-policy,--reservation-affinityund--reservation, um eine Reservierung zu nutzen. Geben Sie diese Flags an, um den Richtliniennamen und die Reservierung im Knotenpool zu konfigurieren. Wenn für die Reservierung keine Ressourcenrichtlinie erforderlich ist, lassen Sie das Flag--placement-policyweg.Das Flag
--reservation-affinitykann die Wertespecificoderanyhaben. Für verteilte KI-Arbeitslasten mit hoher Leistung empfehlen wir jedoch, eine bestimmte Reservierung zu verwenden. Hier finden Sie Informationen zu Ihrer Reservierung, z. B. den Namen Ihrer Reservierung oder den Namen eines bestimmten Blocks in Ihrer Reservierung. Wenn Sie diese Werte für On-Demand-Reservierungen abrufen möchten, rufen Sie eine Liste Ihrer Reservierungen auf oder zeigen Sie vorausschauende Reservierungsanfragen an.Ersetzen Sie Folgendes, um eine Reservierung zu verwenden:
PROJECT_ID: Optional Ihre Google Cloud-Projekt-ID. Wenn sich die Reservierung im aktuellen Projekt befindet (keine freigegebene Reservierung), können Sieprojects/PROJECT_ID/reservations/aus dem Reservierungswert weglassen.RESERVATION_NAME: der Name Ihrer Reservierung.BLOCK_NAME: Optional der Name eines bestimmten Blocks innerhalb der Reservierung. Lassen Sie/reservationBlocks/BLOCK_NAMEweg, wenn Sie keinen bestimmten Block verwenden möchten.
Wenn dieser Befehl fehlschlägt, haben Sie möglicherweise nicht genügend H100-GPU-Kontingent in Ihrem Projekt. Prüfen Sie, ob Sie ein Kontingent haben, und wiederholen Sie den Befehl.
Prüfen Sie nach dem Erstellen des Knotenpools, ob jeder Knoten die angehängten GPUs hat:
Rufen Sie eine Liste der Knoten im Cluster ab:
kubectl get nodesPrüfen Sie, ob jeder GPU-Knoten acht GPUs hat:
kubectl describe node NODE_NAMEErsetzen Sie
NODE_NAMEdurch den Namen des Knotens, der beschrieben werden soll.Die Ausgabe sieht etwa so aus:
Capacity: ... nvidia.com/gpu: 8 Allocatable: ... nvidia.com/gpu: 8
GPUDirect-Binärprogramm und NCCL-Plug-in installieren
In diesem Abschnitt erfahren Sie, wie Sie das GPUDirect-TCPX-Binärprogramm und eine bestimmte NCCL-Bibliotheksversion mithilfe eines DaemonSet installieren.
Dieses DaemonSet macht Folgendes:
- Installiert die NCCL-Bibliothek und das GPUDirect-TCPX-Binärprogramm auf dem Knoten.
- Speichert die Bibliothek und das Binärprogramm im Verzeichnis
/home/kubernetes/bin/nvidia/lib64auf der VM. Standardmäßig wird dieses Verzeichnis in GKE in den Pfad/usr/local/nvidia/lib64in GPU-Containern eingebunden, die NCCL und GPUDirect-TCPX verwenden müssen.
So installieren Sie das Binärprogramm und konfigurieren NCCL:
Standard
nccl-tcpx-installer.yaml-Daemonset-Manifest in GitHub prüfenStellen Sie das DaemonSet bereit:
kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/container-engine-accelerators/master/gpudirect-tcpx/nccl-tcpx-installer.yamlEs dauert etwa zwei Minuten, bis das NCCL-Plug-in ausgeführt wird.
Prüfen Sie den Status der DaemonSet-Pods:
kubectl get pods -n=kube-system -l=name=nccl-tcpx-installerDie Ausgabe sieht etwa so aus:
nccl-tcpx-installer-6c2pv 1/1 Running 0 2m11s nccl-tcpx-installer-qgg82 1/1 Running 0 2m11s
Autopilot
Prüfen Sie das
nccl-tcpx-installer-autopilot.yaml-Daemonset-Manifest in GitHub.Erstellen Sie einen dedizierten Namespace:
kubectl create ns gpudirect-systemStellen Sie das DaemonSet bereit:
kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/container-engine-accelerators/master/gpudirect-tcpx/nccl-tcpx-installer-autopilot.yamlEs dauert etwa zwei Minuten, bis das NCCL-Plug-in ausgeführt wird.
NRI-Geräte-Injector-Plug-in bereitstellen
In diesem Abschnitt erfahren Sie, wie Sie den NRI-Geräteinjektor mithilfe eines DaemonSets installieren. Dieses Plug-in tut Folgendes:
- Aktiviert die Node Resource Interface (NRI) auf dem Knoten mit H100-GPUs. NRI ist in GKE-Version 1.29 und höher standardmäßig aktiviert.
- Stellt einen NRI-Geräte-Injector-Plug-in-Container bereit, der GPU-Geräte in Container einfügt, die durch Pod-Annotationen angegeben werden.
Gehen Sie zum Installieren des Plug-ins so vor:
Standard
Prüfen Sie das
nri-device-injector.yaml-Deployment-Manifest in GitHub.Stellen Sie das DaemonSet bereit:
kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/container-engine-accelerators/master/nri_device_injector/nri-device-injector.yamlEs dauert etwa zwei Minuten, bis das NCCL-Plug-in ausgeführt wird.
Prüfen Sie den Status der DaemonSet-Pods:
kubectl get pods -n=kube-system -l=name=device-injectorDie Ausgabe sieht etwa so aus:
# Output device-injector-md6hb 1/1 Running 0 4h54m device-injector-vh9bm 1/1 Running 0 4h54m
Autopilot
Prüfen Sie das
nri-device-injector-autopilot.yaml-Deployment-Manifest in GitHub.Stellen Sie das DaemonSet bereit:
kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/container-engine-accelerators/master/nri_device_injector/nri-device-injector-autopilot.yamlEs dauert etwa zwei Minuten, bis das NCCL-Plug-in ausgeführt wird.
Testarbeitslast bereitstellen
In diesem Abschnitt stellen Sie eine Beispielarbeitslast bereit, um zu prüfen, ob NCCL und GPUDirect-TCPX wie erwartet funktionieren. Diese Beispielarbeitslast führt folgende Aktionen aus:
- Es werden zwei Pods bereitgestellt, die jeweils auf einem Knoten mit H100-GPUs ausgeführt werden.
- Stellt in jedem Pod einen Sidecar-Container bereit, damit diese Pods GPUDirect-TCPX verwenden können.
Diese Arbeitslast enthält einen Sidecar-Container mit dem Namen tcpx-daemon, in dem ein Dienst ausgeführt wird, mit dem der Pod GPUDirect-TCPX verwenden kann. Sie müssen diesen Sidecar-Container allen Pods in Ihrer eigenen Umgebung hinzufügen, die GPUDirect-TCPX verwenden müssen. Einen Ausschnitt der erforderlichen Felder, die Sie Ihren Manifesten hinzufügen müssen, finden Sie unter GPUDirect zu Manifesten hinzufügen.
Prüfen Sie das ConfigMap-Manifest
nccl-config.yamlin GitHub. Dieses Manifest stellt Scripts bereit, die einen NCCL-Allgather-Test initialisieren und NCCL-spezifische Konfigurationseinstellungen festlegen.Gehen Sie je nach Clustermodus so vor:
Standard
Prüfen Sie das
nccl-test-latest.yaml-Deployment-Manifest in GitHub.Autopilot
Prüfen Sie das
nccl-test-latest-autopilot.yaml-Deployment-Manifest in GitHub.Stellen Sie die ConfigMap und die Testarbeitslast bereit:
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.yamlAutopilot
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.yamlPrüfen Sie, ob die Pods ausgeführt werden und bereit sind. Die Bilder sind groß (ca. 5 GB) und der Download kann mehrere Minuten dauern.
kubectl get pods -wDer Befehl sucht nach Updates und gibt eine neue Zeile aus, wenn sich der Status eines Pods ändert. Die Ausgabe sieht etwa so aus:
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 46sWarten Sie, bis die
STATUS-Meldung für alle PodsRunninglautet und der Wert vonREADY2/2ist, bevor Sie mit dem nächsten Schritt fortfahren.Führen Sie die folgenden Befehle aus, um einen NCCL-Test-All-Gather-Test für die Knoten auszulösen:
kubectl exec \ --stdin --tty --container=nccl-test nccl-test-host-1 \ -- /configs/allgather.sh nccl-host-1 nccl-host-2Die Ausgabe sieht etwa so aus:
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
GPUDirect für eigene Arbeitslasten verwenden
Nachdem Sie bestätigt haben, dass die Clusternetzwerke mit der Beispielarbeitslast funktionieren, müssen Sie GPUDirect für Ihre tatsächlichen Arbeitslasten übernehmen. Wenn Sie GPUDirect verwenden möchten, müssen Sie Ihre NCCL-Einstellungen und Ihre Kubernetes-Pod-Manifeste aktualisieren.
Erforderliche NCCL-Konfigurationseinstellungen zur Leistungsverbesserung verwenden
Die folgenden Schlüssel/Wert-Paare sind die erforderlichen NCCL-Konfigurationseinstellungen für GPUDirect-TCPX. Wenn Sie Arbeitslasten bereitstellen, für die NCCL verwendet wird, legen Sie sie als Umgebungsvariablen fest, um die Leistung zu optimieren.
"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"
GPUDirect zu Manifesten hinzufügen
In diesem Abschnitt werden die erforderlichen Felder aufgeführt, die Sie Ihren Kubernetes-Manifesten hinzufügen müssen, damit Ihre Pods GPUDirect verwenden können.
Führen Sie je nach Clustermodus die folgenden Schritte aus:
Standard
Fügen Sie den Pod-Metadaten die folgenden Annotationen hinzu. Ohne diese Anmerkungen ist
hostNetwork:truefür den Pod undprivileged:truefür dentcpx-daemon-Container erforderlich.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"}, ]Fügen Sie der Pod-Spezifikation die folgenden Felder hinzu:
spec: volumes: - name: libraries hostPath: path: /home/kubernetes/bin/nvidia/lib64 - name: sys hostPath: path: /sys - name: proc-sys hostPath: path: /proc/sysFü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: 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/lib64Fügen Sie allen Containern, die GPUs anfordern, die folgenden Volume-Bereitstellungen hinzu:
volumeMounts: - name: tcpx-socket mountPath: /tmp - name: libraries mountPath: /usr/local/nvidia/lib64Fügen Sie Umgebungsvariablen hinzu, um NCCL-Optionen zu konfigurieren. Weitere Informationen finden Sie in diesem Dokument im Abschnitt Empfohlene NCCL-Konfigurationseinstellungen zur Leistungsverbesserung verwenden.
Fügen Sie jedem GPU-Container die folgende Umgebungsvariable hinzu:
env: - name: LD_LIBRARY_PATH value: /usr/local/nvidia/lib64
Ein Beispiel für eine vollständige Pod-Spezifikation finden Sie im Manifest nccl-test-latest.yaml auf GitHub.
Autopilot
Im Autopilot-Modus müssen Sie auch die entsprechenden GPUs in Ihren Pod-Manifesten auswählen, damit GKE die Hardware bereitstellt.
Fügen Sie Ihrem Pod die folgenden Knotenauswahlen hinzu:
nodeSelector:
cloud.google.com/gke-accelerator: a3-edgegpu-8g
cloud.google.com/gke-gpu-driver-version: latest
Wenn Sie reservierte Kapazität nutzen möchten, können Sie außerdem Informationen zur Reservierung angeben. Weitere Informationen finden Sie in den Unterabschnitten zum Aufnehmen von Reservierungen unter Kapazitätsreservierungen in Autopilot-Clustern aufnehmen.
Fügen Sie den Pod-Metadaten die folgenden Annotationen hinzu:
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"}, ]Fügen Sie der Pod-Spezifikation die folgenden Felder hinzu:
spec: volumes: - name: libraries hostPath: path: /home/kubernetes/bin/nvidia/lib64 - name: sys hostPath: path: /sys - name: proc-sys hostPath: path: /proc/sysFü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: 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/lib64Fügen Sie allen Containern, die GPUs anfordern, die folgenden Volume-Bereitstellungen hinzu:
volumeMounts: - name: tcpx-socket mountPath: /tmp - name: libraries mountPath: /usr/local/nvidia/lib64Fügen Sie Umgebungsvariablen hinzu, um NCCL-Optionen zu konfigurieren. Weitere Informationen finden Sie in diesem Dokument im Abschnitt Empfohlene NCCL-Konfigurationseinstellungen zur Leistungsverbesserung verwenden.
Ein Beispiel für eine vollständige Pod-Spezifikation finden Sie im Manifest nccl-test-latest-autopilot.yaml auf GitHub.
NCCL-Debugging-Logs erfassen
Wenn Sie NCCL-Fehler protokollieren möchten, empfehlen wir, die folgende NCCL-Konfiguration hinzuzufügen:
NCCL_DEBUG=INFO
NCCL_DEBUG_SUBSYS=INIT,NET,ENV,COLL,GRAPH
NCCL_DEBUG_FILE=/DIRECTORY/FILE_NAME.%h.%p
NCCL_DEBUG=INFO: Gibt Debugging-Informationen aus.- Bei umfangreichen Arbeitslasten (64 Knoten oder mehr) kann es zu umfangreichen Protokollierungen kommen. Um dieses Szenario zu vermeiden – und sofern Sie
NCCL_DEBUG_FILEnicht angegeben haben – empfehlen wir,NCCL_DEBUG=WARNfestzulegen, um Protokolle auf Fehler zu beschränken.
- Bei umfangreichen Arbeitslasten (64 Knoten oder mehr) kann es zu umfangreichen Protokollierungen kommen. Um dieses Szenario zu vermeiden – und sofern Sie
NCCL_DEBUG_SUBSYS: Filtert die Subsysteme, für die NCCL Debugging-Informationen erfasst. Wir empfehlen, Logs für die folgenden Subsysteme zu erfassen:INIT: Die Initialisierungsphase von NCCL.NET: das NCCL-Netzwerk.ENV: Die Umgebungsvariablen, die von NCCL verwendet werden.COLL: Kollektive Vorgänge.GRAPH: Topologieerkennung und Suche im Diagramm.
Wenn Sie Protokolle für verschiedene Subsysteme erfassen möchten, finden Sie in der NCCL-Dokumentation unter
NCCL_DEBUG_SUBSYSeine Liste der zulässigen Werte.NCCL_DEBUG_FILE(optional): Leitet die NCCL-Debug-Logging-Ausgabe in eine von Ihnen angegebene Datei um. Mit dieser Variablen werden NCCL-Logs in Standarddateien geschrieben, wodurch verhindert wird, dass sich die Logausgabe mit der Anwendungsausgabe vermischt. Mit dieser Variablen werden auch Logs von verschiedenen NCCL-Rängen in verschiedene Dateien geschrieben, wodurch verhindert wird, dass sich die Logs vermischen.Verwenden Sie das folgende Dateinamenformat:
/DIRECTORY/FILE_NAME.%h.%pErsetzen Sie Folgendes:
DIRECTORY: das Verzeichnis, in dem Sie die Logdateien speichern möchten.FILE_NAME: Der Name der Logdateien.
Der Platzhalter
%hwird in den Hostnamen des Knotens aufgelöst, während%pin die Prozess-ID (PID) des Prozesses aufgelöst wird, der das Log generiert.
Weitere Informationen zum Debuggen von NCCL-Logs finden Sie unter Fehlerbehebung bei GPUs in GKE.
Nächste Schritte
- Weitere Informationen zum Planen von Arbeitslasten in Ihren GKE-Clustern mit Topology Aware Scheduling (TAS) und Kueue finden Sie unter GKE-Arbeitslasten mit Topology Aware Scheduling planen.
- Weitere Informationen zum Verwalten häufiger Ereignisse, die für GKE-Cluster und KI-Arbeitslasten relevant sind, finden Sie unter KI-optimierte GKE-Cluster verwalten.