Comment configurer NVLink sur un serveur dédié

NVLink est l’interconnexion GPU haute vitesse propriétaire de NVIDIA qui remplace le bus PCIe comme voie de communication principale entre les GPU — et dans certaines architectures, entre les GPU et les CPU. Elle offre une bande passante bidirectionnelle allant jusqu’à 600 GB/s par lien sur le matériel de génération Hopper, contre un maximum théorique d’environ 64 GB/s sur PCIe 5.0 x16. Pour les charges de travail telles que l’entraînement de grands modèles de langage, la simulation de dynamique moléculaire ou l’inférence multi-GPU, cette différence n’est pas marginale — elle est architecturale.

Ce guide fournit une procédure complète, de qualité production, pour configurer NVLink sur un serveur dédié : de l’installation physique du matériel et de la configuration de la pile de pilotes à la vérification de la topologie, l’intégration au niveau applicatif et la surveillance continue des performances.

Ce qu’est réellement NVLink — et ce qu’il n’est pas

NVLink n’est pas simplement un câble plus rapide. C’est un tissu d’interconnexion cohérent point à point intégré directement dans la puce GPU. Chaque voie NVLink transporte des données dans les deux sens simultanément en utilisant un protocole de signalisation différentielle sérialisée. Plusieurs voies sont agrégées en un seul lien logique, et plusieurs liens peuvent connecter la même paire de GPU pour une bande passante additive.

De manière cruciale, NVLink prend en charge l’accès mémoire cohérent avec le cache. Cela signifie que le GPU A peut lire depuis la mémoire framebuffer du GPU B sans passer par la RAM hôte ou le contrôleur mémoire du CPU. Cette propriété est ce qui permet le modèle de programmation « mémoire unifiée » dans CUDA — un espace d’adressage virtuel unique couvrant plusieurs mémoires GPU physiques.

Ce que NVLink n’est pas : il ne remplace pas NVSwitch dans les systèmes à grande échelle. Dans les configurations avec plus de deux GPU, NVIDIA utilise NVSwitch — une puce de commutation crossbar dédiée — pour fournir une connectivité NVLink de tous à tous. Le DGX A100, par exemple, utilise six puces NVSwitch pour donner à chacun de ses huit GPU A100 une bande passante NVLink complète vers chaque autre GPU simultanément. Si vous construisez une station de travail à deux GPU ou un serveur à quatre GPU avec un pont pris en charge, vous travaillez avec des connexions NVLink directes. Si vous travaillez avec huit GPU ou plus, vous êtes presque certainement dans le domaine de NVSwitch.

Bande passante NVLink par génération de GPU

Comprendre le plafond de bande passante de votre matériel spécifique est essentiel avant de procéder à des tests de performance ou à une planification de capacité.

PCIe 4.0 x16 offre environ 32 GB/s bidirectionnel. PCIe 5.0 x16 double cela à environ 64 GB/s. Même un pont NVLink grand public à deux liens sur des cartes RTX 3090 offre près du double de la bande passante de PCIe 5.0 — et les GPU de centre de données sont dans une catégorie complètement différente.

Prérequis et compatibilité matérielle

Avant de toucher un seul fichier de configuration, confirmez les points suivants :

Compatibilité GPU. NVLink n’est pas disponible sur tous les GPU NVIDIA. Les cartes grand public en dessous de la RTX 2080 Ti ne le prennent pas en charge. La RTX 4080 ne prend pas en charge NVLink malgré être une carte haut de gamme — seule la RTX 4090 le fait dans la génération Ada. Vérifiez toujours la fiche technique officielle du GPU NVIDIA pour votre SKU exact.

Pont NVLink. Pour les GPU grand public et prosumer, un connecteur de pont NVLink physique est requis. Ces ponts sont spécifiques à la génération — un pont Turing ne s’adaptera pas à une carte Ampere. Les GPU de centre de données (A100, H100) au format SXM utilisent une carte mezzanine propriétaire et n’utilisent pas de pont discret.

Carte mère et espacement des slots PCIe. Le pont NVLink nécessite que les deux GPU soient dans des slots PCIe x16 adjacents avec un écart physique spécifique. La plupart des ponts grand public couvrent deux slots. Certains ponts haut de gamme couvrent trois slots. Vérifiez le pas des slots de votre carte mère par rapport aux dimensions du pont avant d’acheter.

Paramètres BIOS. Activez « Above 4G Decoding » et « Resizable BAR » (également appelé Smart Access Memory sur les plateformes AMD) dans l’UEFI. Certains systèmes nécessitent également de désactiver le CSM (Compatibility Support Module) pour permettre l’allocation complète de l’espace d’adressage PCIe pour plusieurs GPU.

Alimentation électrique. Deux GPU haut de gamme sous charge complète accélérée par NVLink peuvent consommer 600W ou plus combinés. Assurez-vous que votre alimentation dispose d’une marge suffisante et que les connecteurs d’alimentation GPU sont sur des rails séparés dans la mesure du possible.

Système d’exploitation. Ce guide couvre Linux (Ubuntu 22.04 LTS / Debian 12) comme cible principale, qui est l’environnement standard pour les charges de travail IA et HPC sur les Serveurs Dédiés. Les étapes spécifiques à Windows sont indiquées lorsqu’elles diffèrent significativement.

Étape 1 : Installation physique du GPU et du pont

Éteignez complètement le serveur et débranchez-le du secteur. Mettez-vous à la terre à l’aide d’un bracelet antistatique avant de manipuler des cartes PCIe.

1. Retirez les caches des slots PCIe cibles.
2. Insérez le premier GPU dans le slot x16 principal (généralement le plus proche du CPU).
3. Insérez le second GPU dans le slot x16 adjacent, en vous assurant que l’écart physique correspond à votre pont NVLink.
4. Enclenchez fermement les deux cartes jusqu’à ce que les clips de rétention PCIe s’enclenchent.
5. Connectez tous les connecteurs d’alimentation PCIe requis de l’alimentation à chaque GPU. N’utilisez pas de connecteurs en guirlande pour les cartes à TDP élevé — utilisez des câbles séparés de l’alimentation.
6. Alignez le pont NVLink sur les plages de contact dorées sur le bord supérieur des deux GPU. Appuyez fermement et uniformément jusqu’à ce qu’il soit complètement en place. Un pont partiellement inséré entraînera l’échec silencieux du lien ou son fonctionnement à largeur réduite.
7. Si vos GPU prennent en charge deux ponts NVLink (par exemple, la RTX 2080 Ti dispose de deux connecteurs NVLink), installez les deux ponts pour une bande passante maximale.
8. Fermez le châssis et rebranchez l’alimentation.

Étape 2 : Configuration du BIOS et de l’UEFI

Démarrez dans la configuration UEFI (généralement Del ou F2 au POST).

• Activez Above 4G Decoding.
• Activez Resizable BAR si pris en charge.
• Réglez la vitesse de lien PCIe sur Auto ou Gen4/Gen5 selon votre matériel.
• Désactivez le CSM si votre OS démarre via UEFI.
• Sauvegardez et quittez.

Étape 3 : Installer les pilotes NVIDIA sur Linux

NVIDIA propose plusieurs méthodes d’installation. La méthode par gestionnaire de paquets est préférée pour les environnements serveur car elle s’intègre avec DKMS (Dynamic Kernel Module Support), qui reconstruit automatiquement le module noyau après les mises à jour du noyau.

Tout d’abord, ajoutez le dépôt de paquets NVIDIA et installez le pilote :

sudo apt-get update
sudo apt-get install -y software-properties-common
sudo add-apt-repository -y ppa:graphics-drivers/ppa
sudo apt-get update
sudo apt-get install -y nvidia-driver-545 nvidia-dkms-545

Remplacez 545 par la dernière version de branche de production disponible pour votre GPU. Vous pouvez interroger les versions disponibles avec :

apt-cache search nvidia-driver | grep "^nvidia-driver"

Après l’installation, redémarrez :

sudo reboot

Après le redémarrage, vérifiez que le pilote s’est chargé correctement :

nvidia-smi

La sortie doit lister les deux GPU avec leur version de pilote, la compatibilité de version CUDA et l’état d’alimentation actuel. Si un seul GPU apparaît, la seconde carte n’est peut-être pas correctement insérée ou présente un problème d’alimentation.

Un écueil critique : Si Nouveau (le pilote NVIDIA open-source) est chargé, il entrera en conflit avec le pilote propriétaire. Mettez-le explicitement sur liste noire :

echo -e "blacklist nouveaunoptions nouveau modeset=0" | sudo tee /etc/modprobe.d/blacklist-nouveau.conf
sudo update-initramfs -u
sudo reboot

Étape 4 : Installer le kit d’outils CUDA

La capacité complète de NVLink — notamment l’accès mémoire pair-à-pair et les communications collectives — nécessite le kit d’outils CUDA. Installez-le via le dépôt CUDA de NVIDIA pour une correspondance de version la plus fiable :

wget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2204/x86_64/cuda-keyring_1.1-1_all.deb
sudo dpkg -i cuda-keyring_1.1-1_all.deb
sudo apt-get update
sudo apt-get install -y cuda-toolkit-12-4

Ajoutez les binaires et bibliothèques CUDA à votre environnement shell :

echo 'export PATH=/usr/local/cuda/bin:$PATH' >> ~/.bashrc
echo 'export LD_LIBRARY_PATH=/usr/local/cuda/lib64:$LD_LIBRARY_PATH' >> ~/.bashrc
source ~/.bashrc

Vérifiez l’installation :

nvcc --version

Vous devriez voir une sortie identifiant la version du compilateur CUDA. Exécutez également l’exemple CUDA deviceQuery si vous avez les exemples installés — il énumérera les deux GPU et rapportera les indicateurs de capacité NVLink.

Étape 5 : Vérifier la topologie et l’état de NVLink

C’est l’étape la plus importante sur le plan diagnostique. nvidia-smi fournit plusieurs sous-commandes spécifiquement pour l’inspection NVLink.

Vérifiez la matrice de topologie du système :

nvidia-smi topo -m

La sortie est une matrice montrant le type d’interconnexion entre chaque paire de périphériques dans le système. Recherchez les étiquettes NV# entre vos GPU, où # est le nombre de ponts NVLink les connectant. Une étiquette NV2 signifie que deux ponts NVLink sont actifs. Une étiquette PIX ou PHB signifie que les GPU communiquent via PCIe — NVLink n’est pas actif.

Exemple de sortie pour un système dual-GPU correctement configuré :

        GPU0    GPU1    CPU Affinity    NUMA Affinity
GPU0     X      NV2     0-23            0
GPU1    NV2      X      0-23            0

Vérifiez l’état des liens NVLink par GPU :

nvidia-smi nvlink --status -i 0

Cela affiche l’état de chaque port NVLink sur le GPU 0. Les liens actifs afficheront l’état Active et la vitesse négociée.

Vérifiez les compteurs d’erreurs NVLink :

nvidia-smi nvlink --errorcounters -i 0

Des compteurs d’erreurs de relecture ou de récupération non nuls indiquent un problème de couche physique — un pont partiellement inséré, un connecteur endommagé ou des problèmes d’intégrité du signal dus à une alimentation insuffisante.

Surveillez le débit NVLink en temps réel :

nvidia-smi nvlink -s

Cela affiche des compteurs de débit cumulatifs. Pour une surveillance des deltas en temps réel, combinez-le avec watch :

watch -n 1 nvidia-smi nvlink -s

Étape 6 : Activer et vérifier l’accès mémoire pair-à-pair

L’accès mémoire cohérent de NVLink nécessite que l’accès pair-à-pair (P2P) soit activé au niveau CUDA. Vous pouvez le vérifier par programmation :

cat << 'EOF' > check_p2p.py
import subprocess
result = subprocess.run(['nvidia-smi', 'topo', '-p2p', 'r'], capture_output=True, text=True)
print(result.stdout)
EOF
python3 check_p2p.py

Ou utilisez un programme CUDA C avec cudaDeviceCanAccessPeer(). Pour une validation rapide, les exemples CUDA simpleP2P et p2pBandwidthLatencyTest sont les outils de référence :

cd /usr/local/cuda/samples/1_Utilities/p2pBandwidthLatencyTest
make
./p2pBandwidthLatencyTest

La sortie affichera la bande passante bidirectionnelle entre les paires de GPU. Sur NVLink, vous devriez voir des valeurs cohérentes avec le tableau de bande passante ci-dessus. Si vous observez une bande passante au niveau PCIe (~10–30 GB/s), le P2P sur NVLink n’est pas actif — vérifiez que le pont est complètement inséré et qu’aucun paramètre IOMMU ne bloque l’accès pair.

Considération IOMMU : Sur les plateformes AMD EPYC et certaines plateformes Intel Xeon, l’IOMMU peut être activé par défaut et peut bloquer l’accès P2P GPU. Si le P2P ne fonctionne pas, ajoutez iommu=pt (mode passthrough) ou amd_iommu=on iommu=pt à votre ligne de commande du noyau dans /etc/default/grub :

sudo nano /etc/default/grub
# Add iommu=pt to GRUB_CMDLINE_LINUX_DEFAULT
sudo update-grub
sudo reboot

Étape 7 : Configurer les frameworks de deep learning pour utiliser NVLink

Les frameworks modernes détectent NVLink automatiquement via NCCL (NVIDIA Collective Communications Library), mais comprendre comment vérifier et ajuster ce comportement est essentiel pour les déploiements en production.

Variables d’environnement NCCL pour l’optimisation NVLink :

export NCCL_DEBUG=INFO
export NCCL_P2P_LEVEL=NVL        # Force NVLink for P2P transfers
export NCCL_SHM_DISABLE=0        # Keep shared memory enabled
export NCCL_SOCKET_IFNAME=eth0   # Specify network interface for multi-node

Définir NCCL_DEBUG=INFO amène NCCL à afficher sa détection de topologie à l’exécution. Vous verrez des lignes comme [0] NCCL INFO Channel 00 : 0[...] -> 1[...] via NVL confirmant que NVLink est utilisé pour les transferts inter-GPU.

Vérification multi-GPU PyTorch :

import torch

print(f"CUDA available: {torch.cuda.is_available()}")
print(f"GPU count: {torch.cuda.device_count()}")

for i in range(torch.cuda.device_count()):
    for j in range(torch.cuda.device_count()):
        if i != j:
            can_access = torch.cuda.can_device_access_peer(i, j)
            print(f"GPU {i} -> GPU {j} P2P access: {can_access}")

Si can_device_access_peer retourne True pour les deux directions, DataParallel et DistributedDataParallel de PyTorch utiliseront NVLink pour la synchronisation des gradients automatiquement.

Vérification multi-GPU TensorFlow :

import tensorflow as tf

gpus = tf.config.list_physical_devices('GPU')
print(f"Detected GPUs: {len(gpus)}")
for gpu in gpus:
    print(gpu)

# Enable memory growth to prevent TF from allocating all VRAM at startup
for gpu in gpus:
    tf.config.experimental.set_memory_growth(gpu, True)

TensorFlow utilise NCCL pour les opérations collectives lors de l’exécution avec MirroredStrategy, donc les variables d’environnement NCCL ci-dessus s’appliquent également.

Étape 8 : Évaluer les performances de NVLink

Avant de confier des charges de travail de production, établissez une base de référence de performance. Cela sert également de test de régression après les mises à jour de pilotes ou les modifications matérielles.

Test de bande passante all-reduce NCCL (le benchmark le plus représentatif pour l’entraînement distribué) :

git clone https://github.com/NVIDIA/nccl-tests.git
cd nccl-tests
make CUDA_HOME=/usr/local/cuda
./build/all_reduce_perf -b 8 -e 512M -f 2 -g 2

L’indicateur -g 2 spécifie deux GPU. Regardez la colonne busbw — c’est la bande passante effective du bus. Sur NVLink avec des cartes RTX 3090, vous devriez voir des valeurs approchant 100 GB/s. Sur PCIe, attendez-vous à 20–30 GB/s.

Benchmark cuBLAS GEMM pour les charges de travail limitées par le calcul :

/usr/local/cuda/extras/demo_suite/bandwidthTest --mode=shmoo

Étape 9 : Surveillance continue et alertes

Pour les environnements de production, nvidia-smi en mode démon ou l’intégration avec Prometheus via dcgm-exporter est l’approche recommandée.

Installez DCGM (Data Center GPU Manager) :

sudo apt-get install -y datacenter-gpu-manager
sudo systemctl enable nvidia-dcgm
sudo systemctl start nvidia-dcgm

Interrogez les métriques spécifiques à NVLink via DCGM :

dcgmi dmon -e 1011,1012,1013,1014

Les IDs de champ 1011–1014 correspondent aux compteurs de bande passante NVLink (TX/RX par lien). Ceux-ci peuvent être exportés vers Prometheus et visualisés dans Grafana pour une analyse de tendance à long terme.

Pour une surveillance plus légère, une simple boucle nvidia-smi capture l’essentiel :

nvidia-smi dmon -s pucvmet -d 5

Les indicateurs -s pucvmet activent le rapport de puissance, d’utilisation, d’horloge, de VRAM, de bande passante mémoire, d’ECC et de température à des intervalles de 5 secondes.

NVLink vs. PCIe vs. NVSwitch : quand chaque architecture s’applique

Modes de défaillance courants et dépannage

NVLink non détecté après l’installation physique. Exécutez nvidia-smi topo -m et vérifiez la présence de PIX au lieu de NV#. Réinsérez le pont. Vérifiez que les deux GPU sont sur le même complexe racine PCIe — les GPU sur des sockets CPU différents connectés via QPI/UPI ne formeront pas une paire NVLink même avec un pont installé.

La bande passante P2P correspond aux vitesses PCIe malgré le pont NVLink. L’IOMMU bloque presque certainement l’accès pair. Appliquez le paramètre noyau iommu=pt comme décrit ci-dessus.

Erreurs NVLink s’accumulant dans nvidia-smi nvlink --errorcounters. Problème de couche physique. Inspectez les plages de contact du pont pour détecter des débris ou des dommages. Essayez de réinsérer le pont. Si les erreurs persistent, le pont lui-même peut être défectueux.

NCCL n’utilise pas NVLink malgré une topologie affichant NV2. Définissez NCCL_P2P_LEVEL=NVL explicitement. Vérifiez également la compatibilité de la version NCCL avec votre version CUDA — les incompatibilités amènent NCCL à revenir au transport par mémoire partagée ou socket.

L’installation du pilote échoue avec des erreurs DKMS. Les en-têtes du noyau pour votre noyau en cours d’exécution peuvent ne pas être installés. Corrigez avec :

sudo apt-get install -y linux-headers-$(uname -r)
sudo dkms autoinstall

Choisir la bonne infrastructure serveur pour les charges de travail NVLink

La configuration NVLink n’est efficace qu’en fonction de la plateforme serveur sous-jacente. Plusieurs facteurs d’infrastructure affectent directement les performances de NVLink en pratique :

Topologie PCIe. Sur les plateformes EPYC ou Xeon à double socket, les voies PCIe sont distribuées entre les deux CPU. Les GPU connectés à des CPU différents communiquent via le tissu inter-socket (Infinity Fabric ou UPI), ce qui ajoute de la latence et réduit la bande passante effective pour les transferts GPU à GPU qui doivent traverser la frontière de socket. Dans la mesure du possible, installez les GPU couplés par NVLink sur des slots PCIe attachés au même socket CPU.

Bande passante mémoire. Même avec NVLink gérant les transferts GPU à GPU, le sous-système mémoire du CPU reste le goulot d’étranglement pour l’ingestion de données. Les plateformes DDR5 haute bande passante ou équipées de HBM réduisent le temps passé à préparer les données avant qu’elles n’atteignent le GPU.

Débit de stockage. Les grands points de contrôle de modèles et les ensembles de données d’entraînement nécessitent un stockage rapide. Les SSD NVMe avec des vitesses de lecture séquentielle supérieures à 7 GB/s empêchent la couche de stockage de devenir le goulot d’étranglement lors du chargement des données.

Refroidissement. Deux GPU à TDP élevé sous charge soutenue accélérée par NVLink génèrent une chaleur substantielle. Assurez une circulation d’air adéquate ou une capacité de refroidissement liquide suffisante. La limitation thermique réduira les vitesses d’horloge du GPU et annulera l’avantage de bande passante que NVLink procure.

Pour les équipes exécutant des entraînements IA multi-GPU ou des simulations HPC, les Serveurs Dédiés avec stockage NVMe et accès root fournissent le contrôle matériel nécessaire pour mettre en œuvre la configuration complète décrite dans ce guide. Pour les charges de travail accélérées par GPU spécifiquement, l’Hébergement GPU offre des environnements préconfigurés avec les pilotes NVIDIA déjà installés. Les équipes qui ont besoin d’une base flexible pour des environnements CUDA personnalisés peuvent également trouver l’Hébergement VPS utile pour le développement et les tests avant de passer à du matériel dédié.

Points clés et liste de contrôle de décision

Avant de déployer NVLink en production, vérifiez chaque élément :

• Matériel confirmé : Les deux GPU figurent sur la liste de compatibilité NVLink de NVIDIA pour votre SKU spécifique, pas seulement la famille de produits.
• Génération du pont correspondante : La génération du pont NVLink correspond à la génération du GPU (pont Turing pour les GPU Turing, pont Ampere pour les GPU Ampere).
• Installation physique vérifiée : nvidia-smi topo -m affiche NV1 ou NV2 entre les paires de GPU, pas PIX ou PHB.
• Accès P2P confirmé : p2pBandwidthLatencyTest rapporte une bande passante au niveau NVLink (pas au niveau PCIe).
• IOMMU traité : Si vous exécutez sur EPYC ou Xeon, iommu=pt est défini dans les paramètres du noyau.
• Transport NCCL confirmé : La sortie de NCCL_DEBUG=INFO affiche via NVL pour les canaux inter-GPU.
• Compteurs d’erreurs propres : nvidia-smi nvlink --errorcounters affiche zéro erreur de relecture et de récupération après un test de rodage.
• Surveillance active : DCGM ou nvidia-smi dmon enregistre la bande passante NVLink et les métriques d’erreurs dans un stockage persistant.
• Marge thermique confirmée : Les deux GPU maintiennent les vitesses d’horloge cibles sous charge complète sans limitation thermique.
• Versions de pilote et CUDA épinglées : Les environnements de production utilisent des versions de pilote épinglées gérées via DKMS pour éviter que des mises à jour involontaires ne cassent la configuration.

Foire aux questions

NVLink fonctionne-t-il sur toutes les cartes NVIDIA RTX ?

Non. La prise en charge de NVLink varie considérablement même au sein de la gamme RTX. La RTX 4080, par exemple, ne prend pas en charge NVLink malgré être une carte Ada Lovelace haut de gamme. Seule la RTX 4090 prend en charge NVLink dans cette génération. Vérifiez toujours la fiche technique du GPU spécifique, pas la famille de produits.

NVLink peut-il être utilisé entre différents modèles de GPU ?

En général, non. NVLink nécessite que les deux GPU soient du même modèle et de la même génération. NVIDIA ne prend pas officiellement en charge les configurations NVLink à modèles mixtes, et la pile de pilotes ne formera pas de relation NVLink pair-à-pair entre des GPU dissemblables même si les connecteurs physiques sont compatibles.

Que se passe-t-il si le pont NVLink est retiré pendant que le système fonctionne ?

Le système ne plantera pas immédiatement, mais tous les transferts P2P actifs sur NVLink échoueront, ce qui amènera généralement l’application CUDA en cours d’exécution à générer une erreur CUDA et à se terminer. Les GPU reviendront au PCIe pour les opérations suivantes. Le retrait à chaud du pont n’est pas pris en charge et risque d’endommager physiquement les plages de contact.

NVLink est-il automatiquement utilisé par PyTorch et TensorFlow, ou nécessite-t-il une configuration explicite ?

Les deux frameworks utilisent NCCL pour les opérations collectives multi-GPU, et NCCL détecte automatiquement la topologie NVLink. Cependant, vous devriez toujours vérifier avec NCCL_DEBUG=INFO que NCCL sélectionne réellement le chemin de transport NVLink. Dans certaines configurations — notamment avec l’IOMMU activé ou des versions NCCL/CUDA incompatibles — NCCL reviendra silencieusement à des transports plus lents.

Comment savoir si NVLink améliore réellement le débit de mon entraînement ?

Exécutez votre tâche d’entraînement avec NCCL_P2P_DISABLE=1 (force PCIe) puis sans (permet NVLink). Comparez le temps d’itération ou les échantillons par seconde. Pour les charges de travail à forte communication comme l’entraînement de grands transformers avec des opérations all-reduce fréquentes, NVLink réduit généralement le temps de synchronisation inter-GPU de 40 à 70 % par rapport au PCIe, se traduisant directement par des temps d’époque plus rapides.