PCIe et GPU : quand x8 suffit et quand ça fait mal

novembre 8, 2025 • février 3, 2026 • Lecture : 29 min • Views: 0

Cet article vous a aidé ?

Quelque part dans votre parc, un GPU en parfait état tourne tranquillement en PCIe x8. Personne ne le remarque jusqu’à ce qu’un entraînement ralentisse, qu’un pipeline vidéo perde des images, ou qu’un service d’inférence voit sa latence en queue s’allonger et gâcher l’après-midi de tout le monde.

Ensuite, le débat commence : « x8, c’est pratiquement la même chose que x16, non ? » Parfois oui. Parfois cette hypothèse coûte des semaines et un budget d’achat. Voici la version de la réponse que vous pouvez apporter en production.

Calcul rapide des lanes que vous pouvez faire de tête

PCIe est une interconnexion série. Les lanes sont des liens indépendants qui agrègent la bande passante. « x16 » signifie 16 lanes. « x8 » signifie 8 lanes. Jusque-là, c’est simple.

Ce qui rend les gens imprécis, c’est que la « génération » PCIe change le débit par lane. Un GPU en Gen4 x8 peut dépasser un GPU plus ancien en Gen3 x16 en bande passante hôte→périphérique brute. Ça ressemble à une anecdote jusqu’à ce que vous regardiez un tableau de bord et vous demandiez pourquoi un nœud est plus lent alors qu’il a « le même nombre de lanes ». Ce n’est pas le cas.

Règle approximative de bande passante (suffisante pour déboguer)

PCIe Gen3 : ~1 GB/s par lane dans chaque direction (après overhead d’encodage). Donc Gen3 x16 ≈ 16 GB/s, Gen3 x8 ≈ 8 GB/s.
PCIe Gen4 : environ le double de Gen3. Gen4 x8 est à peu près équivalent à Gen3 x16.
PCIe Gen5 : environ le double de Gen4. Maintenant x8 peut offrir beaucoup de bande passante — si le reste du système peut suivre.

Et souvenez-vous : PCIe est full duplex. Un lien peut pousser des données dans les deux sens en même temps. La plupart des charges GPU ne le font pas. Elles ont des rafales.

Il y a aussi une différence subtile entre ce que le marketing suggère et ce que votre application ressent : la bande passante n’est pas la latence, et une grande partie de la « lenteur » GPU est en réalité un overhead de synchronisation ou une famine CPU. Le PCIe x8 devient le bouc émissaire parce qu’il est facile à pointer, comme blâmer le réseau pour une panne causée par le DNS.

Quand le PCIe x8 suffit (et quand arrêter de s’inquiéter)

Si vous traitez le GPU comme une île de calcul — charger les données une fois, faire beaucoup de calculs, renvoyer de petits résultats — le PCIe importe peu. Le GPU passe la plupart de son temps à calculer sur la bande passante HBM/GDDR mesurée en centaines de GB/s à plusieurs TB/s. Comparé à cela, le PCIe ressemble à un tuyau d’arrosage. Mais si vous ne le sollicitez qu’occasionnellement, peu importe.

Cas où x8 est généralement acceptable

1) Entraînement dont le pipeline d’entrée est sain

L’entraînement deep learning classique n’est souvent pas lié au PCIe si vous faites ces trois choses :

Garder des batchs de taille raisonnable pour ne pas faire des transferts microscopiques en permanence.
Utiliser la mémoire « pinned » et des copies asynchrones pour que le GPU puisse recouvrir calcul et transferts.
Ne pas demander au CPU de décompresser et prétraiter comme en 2009.

Dans ce monde, passer de x16 à x8 peut déplacer votre temps par étape de quelques pourcents. Parfois c’est du bruit. Si vous ne mesurez pas, vous racontez des histoires.

2) Inférence avec modèles résidents

Si les poids du modèle sont déjà sur le GPU et que les requêtes sont plutôt petites (tokens texte, embeddings, petites images), le trafic sur le PCIe concerne les entrées/sorties, pas le modèle complet. Cela ne sature généralement pas x8.

3) Charges graphiques qui résident en VRAM

Beaucoup de workloads de jeu/rendu streament des assets, mais l’ensemble de travail chaud vit en VRAM. PCIe aide pour le streaming d’assets et des transferts occasionnels, mais ce n’est pas un flux constant à haute bande passante. C’est pourquoi vous voyez des benchmarks où x8 ne change presque rien pour beaucoup de jeux, surtout à des résolutions plus élevées où le GPU est déjà le facteur limitant.

4) Multi-GPU où les GPU communiquent via NVLink (ou similaire)

Si le trafic GPU↔GPU passe par NVLink et que le trafic hôte est minimal, la largeur PCIe peut compter moins. Mais attention : le CPU orchestre encore le travail, et le stockage/réseau alimente toujours le job. « On a NVLink » n’est pas une carte « get-out-of-jail-free » pour une mauvaise topologie.

5) PCIe Gen4/Gen5 x8 avec des modèles DMA bien comportés

Gen4 x8 est souvent correct car il équivaut pratiquement à Gen3 x16. Gen5 x8 est encore plus permissif. Le plus grand avantage pratique des générations PCIe plus récentes n’est pas que vous pouvez aller plus vite ; c’est que vous pouvez préserver la performance tout en utilisant moins de lanes, ce qui simplifie le design des cartes et le budget de lanes de la plateforme.

Opinion : Si vous êtes en Gen4+ et que votre charge ne bouge pas en continu des dizaines de gigaoctets par seconde entre l’hôte et le périphérique, ne dépensez pas du capital politique à « réparer » un x8. Dépensez-le sur des cœurs CPU, la bande passante mémoire, le stockage et le chemin de données que vous utilisez réellement.

Quand le PCIe x8 fait mal (et comment ça se manifeste)

Le PCIe x8 fait mal lorsque le GPU est forcé de se comporter comme un accélérateur attaché qui a besoin d’être constamment alimenté par l’hôte, ou lorsque la topologie de la plateforme transforme « x8 » en « x8 partageant un bridge occupé avec votre NIC et un RAID NVMe ». C’est là que les ralentissements deviennent dramatiques et laids.

1) Charges avec fort trafic hôte↔périphérique

Cela se manifeste dans le monde réel par :

ETL à gros batchs qui remélangent des données via le GPU sans pouvoir les garder en résidant.
Bases de données accélérées par GPU qui paginent fréquemment les données.
Pipelines d’analyse vidéo déplaçant de nombreuses images non compressées.
Codes scientifiques qui lancent beaucoup de petits kernels avec des résultats intermédiaires renvoyés au CPU.

Quand x8 est le goulet, l’utilisation GPU paraît souvent « correcte » par rafales, mais votre débit de bout en bout est faible et les threads CPU se bloquent sur les transferts. La latence augmente, mais cela ne ressemble pas à une pente propre. Cela ressemble à une dent de scie d’attente.

2) Peer-to-peer, RDMA et chemins de données « astucieux »

GPUDirect RDMA et le peer-to-peer GPU sont excellents — jusqu’à ce qu’ils ne le soient plus. Quand ça casse, c’est souvent la topologie : le GPU et le NIC peuvent ne pas partager le même root complex, ou une configuration IOMMU force un overhead de traduction supplémentaire. La largeur de lien PCIe est une dimension ; la longueur du chemin et les bridges intermédiaires en sont d’autres.

3) Environnements virtualisés et passthrough

Dans les configurations virtualisées, vous pouvez finir avec :

Largeur effective réduite à cause du câblage du slot et de la bifurcation.
Paramètres ACS/ARI qui forcent le trafic à transiter par des chemins moins optimaux.
Comportement de l’IOMMU qui change les performances DMA.

Si vous exécutez un GPU pour un locataire et que vous ne mesurez que le temps des kernels, vous manquerez le vrai goulot. Mesurez le temps de transfert. Mesurez bout en bout.

4) Plusieurs périphériques « x8 » partageant la bande passante en amont

Le slot peut être mécaniquement x16 et électriquement x16, mais le lien en amont d’un switch PCIe vers le CPU peut être x16 desservant quatre GPU. Dans ce cas, chaque GPU peut négocier x16 vers le switch et perdre quand même en agrégat parce qu’ils partagent l’uplink. « lspci says x16 » n’est pas la fin de l’histoire.

Blague #1 : La budgétisation des lanes PCIe, c’est comme les places de bureau : tout le monde pense avoir la place près de la fenêtre jusqu’à ce que le responsable sécurité vienne.

5) Dégradation silencieuse : x16 physique, x8 négocié, génération diminuée

Un mode de défaillance classique : le GPU est dans un slot x16, mais il négocie x8, ou tombe de Gen4 à Gen3. Le job tourne, les graphes semblent plausibles, et les performances sont mystérieusement « un peu en-dessous ». C’est comme ça que le temps disparaît en ingénierie.

Les causes incluent une intégrité de signal médiocre (câbles riser, backplanes), des réglages BIOS, des problèmes de retimer, des contacts sales, ou simplement une carte qui partage des lanes avec un autre périphérique et qui réachemine sous charge ou configuration.

La topologie compte plus qu’on ne l’admet

PCIe est un arbre : les endpoints (GPU, NIC, NVMe) pendent des switches, qui pendent des root complexes (sockets CPU). Sur les systèmes à double socket c’est épicé : un GPU sur le socket 0 parlant à un NIC sur le socket 1 peut traverser le tissu inter-socket (UPI/Infinity Fabric) et subir à la fois une perte de bande passante et une hausse de latence.

C’est là que « x8 vs x16 » devient la mauvaise question. Les bonnes questions sont :

Quel socket CPU possède le GPU ?
Quel socket possède le NIC ou le contrôleur de stockage qui alimente le GPU ?
Y a-t-il un switch PCIe ? Quelle est la largeur et la génération de son uplink ?
Partageons-nous un root port avec d’autres périphériques lourds ?

Opinion : Si vous exécutez des nœuds multi-GPU en production, vous devriez traiter la topologie PCIe comme un inventaire de première classe, comme le modèle de CPU et la taille de la RAM. Si vous ne pouvez pas répondre « sous quel root complex est ce GPU ? » depuis vos données d’actif, vous naviguez à vue.

Note sur NUMA et pourquoi il vous trompe à 3h du matin

La localité NUMA affecte :

Les threads CPU qui alimentent le GPU (les engines de copie ont toujours besoin d’orchestration CPU).
La bande passante mémoire hôte (surtout si vous utilisez par erreur de la mémoire distante).
La latence vers le NIC/stockage qui fournit les données d’entrée.

Vous pouvez « corriger » un goulot PCIe perçu en affinant l’affectation des threads du data loader et des allocations mémoire au nœud NUMA local au GPU. Ce n’est pas de la magie ; c’est juste rapprocher le CPU et la mémoire du root port PCIe auquel le GPU est attaché.

Faits intéressants et brève histoire (ce qui explique les bizarreries d’aujourd’hui)

Fait 1 : PCIe a remplacé AGP et PCI(-X) en passant d’un bus parallèle partagé à un tissu série commuté, d’où l’existence des « lanes ».
Fait 2 : Le passage au 128b/130b d’encodage en Gen3 a drastiquement réduit l’overhead comparé au 8b/10b de Gen1/2 ; c’est une partie de la raison pour laquelle Gen3 a semblé être un grand saut réel.
Fait 3 : Beaucoup de slots « x16 » desktop sont mécaniquement x16 mais électriquement x8 quand plusieurs slots sont peuplés ; la multiplexation des lanes sur les cartes mères est plus vieille que la plupart des frameworks ML dont on discute.
Fait 4 : L’entraînement du lien PCIe peut négocier à la fois la largeur et la vitesse au démarrage ; quand la qualité du signal est marginale, les systèmes sous-dimensionnent souvent plutôt que d’échouer complètement.
Fait 5 : Les premières piles de calcul GPU s’appuyaient lourdement sur le CPU pour l’orchestration et la gestion mémoire, ce qui rendait le comportement PCIe plus visible ; les fonctionnalités récentes réduisent les transferts mais n’éliminent pas les contraintes de topologie.
Fait 6 : Les switches PCIe sont courants dans les serveurs multi-GPU ; le GPU peut afficher « x16 » vers le switch même si l’uplink du switch vers le CPU est le vrai point d’étranglement.
Fait 7 : « Resizable BAR » (et idées connexes) provient d’une douleur ancienne autour du mapping d’une grande mémoire device dans l’espace d’adresses CPU ; cela peut réduire l’overhead pour certains transferts mais ne crée pas de bande passante ex nihilo.
Fait 8 : Sur les systèmes à double socket, le trafic PCIe inter-socket peut être limité par le lien inter-socket, faisant qu’un GPU Gen4 x16 se comporte comme s’il avait un tuyau beaucoup plus fin pour certains chemins.
Fait 9 : Les compteurs d’erreurs PCIe (erreurs corrigées) peuvent augmenter longtemps avant que quelqu’un ne remarque, et les performances peuvent se dégrader à cause des retransmissions même quand rien ne « tombe en panne ».

Une citation opérationnelle qui vieillit bien : L’espoir n’est pas une stratégie. — Gene Kranz.

Tâches pratiques : commandes, sorties et la décision à prendre

Ci-dessous se trouvent des tâches réelles que vous pouvez exécuter sous Linux pour confirmer la largeur/vitesse de lien, la topologie, la localité NUMA, le comportement des erreurs et si le PCIe est réellement votre limiteur. Chaque tâche inclut ce qu’il faut chercher et la décision suivante.

Task 1: Check GPU-reported link width and generation

cr0x@server:~$ nvidia-smi -q -d PCI
==============NVSMI LOG==============
PCI
    Bus Id                    : 00000000:3B:00.0
    PCIe Generation
        Current               : 4
        Max                   : 4
    Link Width
        Current               : 8x
        Max                   : 16x

Ce que ça signifie : Le GPU pourrait faire Gen4 x16 mais est actuellement en Gen4 x8. Ce n’est pas automatiquement mauvais, mais c’est un résultat de configuration que vous devriez expliquer.

Décision : Si les performances sont correctes, documentez-le. Si les performances sont en retrait, passez aux vérifications de topologie et d’erreurs — ne sautez pas directement à l’achat de matériel.

Task 2: Confirm link status from PCIe capability registers

cr0x@server:~$ sudo lspci -s 3b:00.0 -vv | sed -n '/LnkCap:/,/LnkSta:/p'
        LnkCap: Port #0, Speed 16GT/s, Width x16, ASPM L1, Exit Latency L1 <16us
        LnkSta: Speed 16GT/s (ok), Width x8 (downgraded)

Ce que ça signifie : Le périphérique et le slot supportent x16, mais ont négocié x8. « downgraded » est le mot intéressant.

Décision : Traitez cela comme un problème matériel/firmware/chemin jusqu’à preuve du contraire : reseat, retirez les risers, vérifiez le BIOS, vérifiez la bifurcation.

Task 3: Map the PCIe tree and spot switches/uplinks

cr0x@server:~$ sudo lspci -tv
-[0000:3a]-+-00.0  Intel Corporation PCIe Root Port
           +-01.0-[3b]----00.0  NVIDIA Corporation Device
           \-02.0-[3c]----00.0  Mellanox Technologies NIC

Ce que ça signifie : Le GPU et le NIC sont sous le même root complex (bon signe pour GPUDirect RDMA et pour éviter des détours cross-socket).

Décision : Si GPU et NIC sont sur des roots/sockets différents, pincez les processus ou déplacez les cartes si possible.

Task 4: Identify NUMA locality of the GPU PCIe device

cr0x@server:~$ cat /sys/bus/pci/devices/0000:3b:00.0/numa_node
0

Ce que ça signifie : Le GPU est local au nœud NUMA 0.

Décision : Exécutez vos threads de data loader sur le nœud 0 et allouez les buffers hôtes là-bas (ou utilisez l’interleaving consciemment).

Task 5: Check CPU socket topology and NUMA layout

cr0x@server:~$ lscpu | egrep 'Socket|NUMA node|Model name'
Model name:                           Intel(R) Xeon(R) Gold 6338 CPU @ 2.00GHz
Socket(s):                            2
NUMA node(s):                         2
NUMA node0 CPU(s):                    0-31
NUMA node1 CPU(s):                    32-63

Ce que ça signifie : Deux sockets, deux nœuds NUMA. Le trafic inter-nœud est réel.

Décision : Si le GPU est sur le nœud0, évitez de planifier votre pipeline d’entrée sur le nœud1 à moins que vous aimiez donner des performances en cadeau.

Task 6: Confirm kernel driver sees the expected max payload/read request

cr0x@server:~$ sudo lspci -s 3b:00.0 -vv | egrep 'MaxPayload|MaxReadReq'
        DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
                MaxPayload 256 bytes, MaxReadReq 512 bytes

Ce que ça signifie : Les tailles de payload et de read request peuvent influencer l’efficacité, surtout avec beaucoup de petits transferts.

Décision : Si vous voyez des valeurs anormalement petites par rapport aux normes de la plateforme, vérifiez les défauts BIOS/firmware et si ACS/quirks les contraignent.

Task 7: Look for PCIe corrected error spam (a silent bandwidth killer)

cr0x@server:~$ sudo journalctl -k -b | egrep -i 'pcie|aer|Corrected|Uncorrected' | tail -n 8
pcieport 0000:3a:00.0: AER: Corrected error received: 0000:3a:00.0
pcieport 0000:3a:00.0: AER: PCIe Bus Error: severity=Corrected, type=Physical Layer
pcieport 0000:3a:00.0: AER:   device [8086:xxxx] error status/mask=00000001/00002000
pcieport 0000:3a:00.0: AER:    [ 0] RxErr

Ce que ça signifie : Les erreurs de couche physique (RxErr) signifient souvent des problèmes d’intégrité de signal : riser, slot, lien marginal, retimer.

Décision : Si les erreurs corrigées sont non triviales, arrêtez les benchs et commencez à réparer le chemin matériel et les réglages BIOS ; les retransmissions peuvent imiter une « lenteur x8 mystérieuse ».

Task 8: Check negotiated link speed/width via sysfs (fast scripting)

cr0x@server:~$ cat /sys/bus/pci/devices/0000:3b:00.0/current_link_speed
16.0 GT/s
cr0x@server:~$ cat /sys/bus/pci/devices/0000:3b:00.0/current_link_width
8

Ce que ça signifie : Même chose que lspci/nvidia-smi, mais script-friendly pour les vérifications à l’échelle du parc.

Décision : Construisez une vérification de conformité : alerter quand un SKU attendu x16 montre x8.

Task 9: Verify GPU/NIC proximity for GPUDirect RDMA setups

cr0x@server:~$ nvidia-smi topo -m
        GPU0    NIC0    CPU Affinity    NUMA Affinity
GPU0     X      PHB     0-31            0
NIC0    PHB      X      0-31            0

Ce que ça signifie : PHB indique que le GPU et le NIC partagent le même bridge hôte PCIe. C’est généralement ce que vous voulez.

Décision : Si vous voyez SYS ou une relation moins locale, reconsidérez le placement des slots, les réglages BIOS, ou quel NIC vous attachez aux workloads.

Task 10: Measure host↔device transfer bandwidth with a CUDA sample (if installed)

cr0x@server:~$ /usr/local/cuda/samples/1_Utilities/bandwidthTest/bandwidthTest --mode=shmoo --memory=pinned
[CUDA Bandwidth Test] - Starting...
Host to Device Bandwidth, 1 Device(s), Pinned memory
  Transfer Size (Bytes)    Bandwidth(MB/s)
  33554432                24000.0
Device to Host Bandwidth, 1 Device(s), Pinned memory
  Transfer Size (Bytes)    Bandwidth(MB/s)
  33554432                25000.0

Ce que ça signifie : ~24–25 GB/s est cohérent avec un comportement Gen4 x8-ish en conditions réelles (varie selon la plateforme). Si vous attendiez ~28–30+ et obtenez la moitié, quelque chose cloche.

Décision : Si la bande passante est faible, vérifiez une rétrogradation de Gen, une baisse de lanes, des erreurs, ou un uplink partagé. Si la bande passante est correcte, votre goulet est ailleurs.

Task 11: Correlate GPU copy engine utilization vs compute (quick sanity)

cr0x@server:~$ nvidia-smi dmon -s u -d 1
# gpu   sm   mem   enc   dec   mclk   pclk
# Idx    %     %     %     %   MHz    MHz
    0   15    20     0     0  9501   1410
    0   18    22     0     0  9501   1410

Ce que ça signifie : Une faible utilisation SM pourrait être une famine de données, mais ça peut aussi être de petits kernels, un goulet CPU, ou un overhead de synchronisation. dmon seul n’est pas une preuve.

Décision : Si SM% reste bas alors que la charge devrait être compute-heavy, profilez les transferts et le comportement des threads CPU avant d’accuser les lanes PCIe.

Task 12: Confirm you’re not accidentally running on remote NUMA memory

cr0x@server:~$ numastat -p $(pgrep -n python)
Per-node process memory usage (in MBs) for PID 24817 (python)
Node 0        18240.3
Node 1          512.7

Ce que ça signifie : Ce processus utilise majoritairement la mémoire du nœud 0, bon si le GPU est sur le nœud0.

Décision : Si la mémoire est majoritairement distante du nœud NUMA du GPU, corrigez votre pinning/allocation (systemd CPUAffinity, taskset, numactl, cpusets de conteneur).

Task 13: Check for BIOS/firmware lane sharing symptoms (multiple endpoints)

cr0x@server:~$ sudo lspci | egrep -i 'NVIDIA|Non-Volatile|Mellanox'
3b:00.0 VGA compatible controller: NVIDIA Corporation Device
3c:00.0 Ethernet controller: Mellanox Technologies Device
5d:00.0 Non-Volatile memory controller: Samsung Electronics NVMe SSD Controller

Ce que ça signifie : Faites l’inventaire des éléments lourds. Si tous ces éléments sont sous un même root port ou un même switch uplink, la sursouscription est plausible.

Décision : Utilisez lspci -tv pour voir s’ils partagent un uplink ; si oui, repensez le placement ou acceptez la contention et planifiez les workloads en conséquence.

Task 14: Validate actual PCIe generation on the root port too

cr0x@server:~$ sudo lspci -s 3a:00.0 -vv | egrep 'LnkCap:|LnkSta:'
LnkCap: Speed 16GT/s, Width x16
LnkSta: Speed 8GT/s (downgraded), Width x16 (ok)

Ce que ça signifie : Le root port fonctionne en Gen3 même si le GPU peut faire Gen4. C’est un problème de négociation au niveau plateforme (réglage BIOS, riser, retimer, ou compatibilité forcée).

Décision : Réparez la vitesse en premier ; x16 Gen3 vs x8 Gen4 peut s’équivaloir en bande passante, mais une rétrogradation de génération surprise corrèle souvent avec des problèmes de signal et des erreurs.

Playbook de diagnostic rapide

Ceci est la séquence « j’ai 20 minutes et un pager ». L’objectif est de décider si la largeur/vitesse/topologie PCIe est réellement le goulet, et si oui, quel levier tirer.

Première étape : confirmez que le lien est ce que vous pensez

Exécutez nvidia-smi -q -d PCI et enregistrez la génération et la largeur Current/Max.
Exécutez sudo lspci -s <gpu> -vv et vérifiez LnkSta pour une vitesse/largeur downgraded.
Vérifiez sysfs current_link_speed et current_link_width pour la consistance de script.

Décision : Si vous voyez « downgraded », traitez-le comme une piste réelle, pas comme une curiosité.

Deuxième étape : cherchez les erreurs silencieuses et le retraining

Scannez les logs du kernel pour les erreurs AER corrigées.
Si vous voyez des rafales RxErr, arrêtez de faire confiance aux benchmarks — réparez le chemin physique/firmware.

Décision : Les erreurs corrigées sont « le système qui vous sauve ». Elles vous coûtent aussi en retransmissions.

Troisième étape : mappez la topologie et la localité NUMA

Utilisez lspci -tv pour voir s’il y a un switch et qui partage le même root.
Utilisez nvidia-smi topo -m pour voir GPU↔NIC proximité.
Vérifiez /sys/bus/pci/devices/.../numa_node et pincez les threads CPU en conséquence.

Décision : Si le GPU et son « feeder » (NIC/NVMe) sont sur des sockets différents, corrigez l’affinité ou le placement avant de toucher la largeur PCIe.

Quatrième étape : mesurez ce que vous accusez du PCIe

Exécutez un test de bande passante hôte↔périphérique (échantillon CUDA ou votre microbench).
Profilez votre app : temps de transfert vs temps de calcul. Si les copies sont une petite fraction, x8 ne changera pas grand-chose.

Décision : Si la bande passante mesurée est proche des attentes et que vous êtes toujours lent, vous avez probablement un problème CPU/pipeline de données.

Trois mini-histoires d’entreprise depuis le terrain

Mini-histoire 1 : L’incident causé par une mauvaise hypothèse

Ils déployaient un nouveau cluster d’inférence. Même SKU GPU, même pile logicielle, même image de conteneur. La seule différence était un nouveau modèle de serveur promettant une meilleure densité. L’équipe a fait comme la plupart : a regardé le nombre de GPU par rack et a souri.

Deux semaines plus tard, la rotation on-call a commencé à voir des pics de latence périodiques. Pas constants. Pas une régression propre. Juste une queue qui empirait aux heures de pointe. Le service était assez stable pour éviter une panne totale, ce qui est le type d’échec le plus dangereux : celui qui vous laisse continuer à avoir tort.

La première hypothèse était que le modèle avait grandi. Il ne l’avait pas. La seconde était que le réseau était congestionné. Il ne l’était pas. Finalement, quelqu’un a lancé nvidia-smi -q -d PCI sur un nœud « mauvais » et a remarqué que les GPU négociaient x8 au lieu de x16. L’équipe a haussé les épaules : « x8 c’est correct. » Puis ils ont fait ce qui répond vraiment aux questions : mesurer la bande passante hôte↔périphérique pendant les pics, et elle était significativement plus faible que sur les nœuds « bons ».

La cause racine était le câblage des slots plus un réglage de bifurcation BIOS. Sur ce modèle, peupler un certain riser NVMe forçait les slots GPU adjacents en mode x8. Personne ne l’avait documenté parce que c’était « dans le guide plateforme », et personne ne lit les guides plateforme jusqu’à ce qu’ils saignent. Ils ont déplacé le riser NVMe dans une baie différente, restauré x16, et la latence en queue est revenue à la normale.

Leçon : « x8 suffit » est une hypothèse, pas un fait. Votre système transformera volontiers cette hypothèse en violation d’un SLO.

Mini-histoire 2 : L’optimisation qui s’est retournée contre eux

Une équipe plateforme de données voulait réduire le temps d’entraînement en accélérant le pipeline d’entrée. Ils ont fait le classique : augmenter le parallélisme, préfetch agressivement, et garder plus de batchs en vol. Les graphes d’utilisation GPU semblaient plus beaux. Les dashboards ont reçu des applaudissements.

Puis la bizarrerie a commencé. Certains nœuds sont devenus plus rapides, d’autres plus lents, et la variance entre nœuds identiques est devenue le nouvel ennemi. Ils ont essayé de mettre à jour les drivers. Ils ont essayé de changer les runtimes de conteneur. Ils ont essayé de débattre en réunions, ce qui est le benchmark préféré de tout le monde.

Le vrai problème était que leur « optimisation » augmentait le trafic hôte↔périphérique en plus petits morceaux et augmentait la contention sur le root complex PCIe. Sur certains nœuds, les GPU étaient derrière un switch PCIe dont l’uplink était déjà occupé par des lectures NVMe à haut débit. Le pool de prefetch a transformé ces lectures en un flux plus régulier, ce qui était excellent pour le stockage, et terrible pour l’uplink PCIe partagé.

Une fois qu’ils ont arrêté le prefetch aveugle et au lieu de cela mis en scène des buffers plus grands et contigus (et les ont pinés), le débit s’est stabilisé. Certains nœuds ont perdu un peu de vitesse de pointe, mais le p95 à l’échelle du parc s’est amélioré, qui est ce dont ils avaient vraiment besoin.

Leçon : les optimisations qui augmentent la concurrence peuvent augmenter la contention. PCIe n’est pas infini, et les uplinks partagés sont l’endroit où « x8 » se transforme en « pourquoi sommes-nous lents ».

Mini-histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une autre équipe gérait un cluster mixte : entraînement le jour, inférence batch la nuit. Ils avaient une politique : chaque SKU matériel avait un « manifeste de topologie connu-bon ». Il indiquait quels slots peupler, quels réglages BIOS étaient requis, et quel « état de lien PCIe attendu » ressemblait pour chaque GPU.

Ce n’était pas glamour. C’était une page wiki interne et quelques scripts qui s’exécutaient pendant le provisioning. Les scripts vérifiaient current_link_width, current_link_speed, la localité NUMA, et si des erreurs AER apparaissaient durant un court stress test.

Un trimestre, ils ont commencé à voir un lot de nœuds échouer la vérification de provisioning : les GPU négociaient Gen4 mais retombaient aléatoirement en Gen3 après un warm reboot. Les nœuds démarraient toujours, exécutaient des conteneurs, et auraient passé des smoke tests superficiels. Mais leur gate l’a détecté.

Ils l’ont isolé à un lot de risers marginal et les ont remplacés avant que les nœuds n’entrent en production. Personne en dehors de l’équipe n’a remarqué. Ce qui est le but.

Blague #2 : La maintenance préventive, c’est comme passer le fil dentaire : tout le monde convient que ça marche, et presque personne ne le fait jusqu’à ce que quelque chose de cher fasse mal.

Erreurs fréquentes : symptômes → cause racine → correction

1) Symptom: “GPU shows x8, performance is down 20–40%”

Cause racine : Pas seulement x8 — généralement une rétrogradation de génération (Gen4→Gen3), des retransmissions liées à des erreurs corrigées, ou un uplink partagé via un switch PCIe.

Correction : Vérifiez LnkSta pour une vitesse downgraded. Scannez les logs pour les erreurs AER. Mappez la topologie avec lspci -tv. Réparez le chemin physique (reseat, retirer riser, remplacer retimer), et assurez-vous que le BIOS est configuré à la génération PCIe prévue.

2) Symptom: “One node is slower than identical nodes”

Cause racine : Population de slot différente, attachement NUMA différent, ou bifurcation déclenchée par un autre périphérique (riser NVMe, second NIC).

Correction : Comparez nvidia-smi -q -d PCI et lspci -tv entre nœuds. Standardisez le mapping des slots. Ajoutez des vérifications de provisioning pour la largeur/vitesse de lien et la NUMA.

3) Symptom: “GPUDirect RDMA didn’t help (or got worse)”

Cause racine : GPU et NIC ne sont pas sous le même host bridge, des réglages IOMMU/ACS forcent un routage sous-optimal, ou le trafic RDMA entre en contention avec d’autres endpoints.

Correction : Utilisez nvidia-smi topo -m. Si GPU↔NIC n’est pas local (PHB/PIX), déplacez les cartes ou changez le NIC utilisé. Validez la config IOMMU et mesurez à nouveau.

4) Symptom: “GPU utilization low, people blame PCIe”

Cause racine : Goulet côté CPU pour le prétraitement, pipeline d’entrée mono-thread, mémoire NUMA distante, ou batchs trop petits causant une synchronisation excessive.

Correction : Pincez les threads et allouez la mémoire sur le nœud local au GPU. Profilez les stalls au niveau applicatif. Augmentez la taille des batchs ou fusionnez des opérations si possible. Confirmez que la bande passante de transfert est réellement saturée avant de toucher au matériel.

5) Symptom: “After adding a second GPU/NVMe, everything regressed”

Cause racine : Partage de lanes ou sursouscription de l’uplink du switch. La plateforme fait ce pour quoi elle a été conçue : des compromis.

Correction : Réévaluez le budget de lanes. Répartissez les périphériques lourds sur des root ports/sockets différents. Si inévitable, programmez les workloads pour éviter les pics simultanés sur les uplinks partagés.

6) Symptom: “lspci says x16, but bandwidth test is low”

Cause racine : Uplink partagé, throttling dû à des erreurs/retransmissions, overhead IOMMU, ou petites tailles de MaxPayload/MaxReadReq interagissant avec le pattern de transfert.

Correction : Confirmez la topologie ; vérifiez les logs AER ; inspectez LnkSta du root port aussi ; comparez MaxPayload/MaxReadReq avec des nœuds connus-bons.

Listes de contrôle / plan étape par étape

Checklist A: Décider si x8 est acceptable pour une charge GPU donnée

Mesurez la fraction de transferts : Quel pourcentage du temps d’étape/requête sont les copies hôte↔périphérique ?
Mesurez la bande passante réelle : Lancez un microbench de bande passante avec mémoire pinned.
Vérifiez la génération PCIe : Gen4 x8 peut suffire ; Gen3 x8 est plus facile à saturer.
Vérifiez la topologie : Partagez-vous un uplink avec NIC/NVMe ? C’est l’embuscade.
Vérifiez NUMA : Les threads CPU et la mémoire sont-ils locaux au socket du GPU ?
Décidez : Si les copies représentent <10% du temps et que la bande passante est proche des attentes, acceptez x8. Si les copies sont importantes et la bande passante faible, réparez le lien ou redesign.

Checklist B: Validation standard de provisioning pour les nœuds GPU

Enregistrez current_link_speed et current_link_width pour chaque GPU dans l’inventaire.
Échouez le provisioning si le lien est downgradué par rapport au manifeste plateforme (avec processus de dérogation).
Exécutez un court test de bande passante hôte↔périphérique et conservez les résultats comme référence.
Scannez journalctl -k pour les erreurs AER après stress. Échouez si le taux d’erreurs dépasse votre tolérance.
Capturez nvidia-smi topo -m et validez la localité GPU↔NIC si vous dépendez de RDMA.

Checklist C: Étapes de remédiation quand x8 vous nuit réellement

Éliminez les problèmes physiques : reseat GPU, retirer/remplacer riser, vérifier retimers, nettoyer les contacts.
Normalisez le BIOS : assurez-vous que le slot est configuré pour la génération prévue ; désactivez les modes compatibilité forcée sauf si nécessaire.
Corrigez la population de slots : déplacez NVMe/NIC pour arrêter le « lane stealing » ; évitez de déclencher la bifurcation qui divise les lanes GPU par deux.
Fixez l’affinité NUMA : pincez les threads du data loader et les allocations mémoire locales au GPU.
Réduisez le trafic PCIe : batchs plus grands, placez les données sur le GPU, utilisez la mémoire pinned, recouvrez copies et calculs.
Retestez : microbench de bande passante + workload bout en bout. N’acceptez pas « j’ai l’impression que c’est plus rapide ».

FAQ

1) PCIe Gen4 x8 est-il pratiquement la même chose que Gen3 x16 ?

Pour la bande passante brute, à peu près oui. En pratique, les overheads plateforme, les switches et les patterns de transfert peuvent encore les faire se comporter différemment, mais le calcul de base est suffisamment proche pour orienter les décisions.

2) Si mon GPU est en x8 au lieu de x16, est-ce que quelque chose est cassé ?

Pas toujours. Cela peut être un partage de lanes normal sur la carte mère, une bifurcation attendue, ou un choix de conception de la plateforme. C’est cassé quand c’est inattendu pour ce SKU, ou quand vous voyez « downgraded » plus des erreurs et une régression de performance.

3) Pourquoi mon GPU affiche x8 « Current » mais x16 « Max » ?

Parce que l’entraînement du lien a négocié x8 : soit le slot est électriquement x8 dans la population actuelle, soit la qualité du signal a forcé un downshift, ou les réglages BIOS le contraignent.

4) Un câble riser ou un backplane peut-il vraiment forcer x8 ou Gen3 ?

Oui. Une intégrité de signal marginale résulte souvent en un lien stable mais plus lent. Le système préfère « ça marche en x8/Gen3 » plutôt que « ça ne boot pas ». C’est une bonne pratique d’ingénierie — et un piège de performance.

5) Resizable BAR corrige-t-il les limitations de bande passante PCIe ?

Non. Il peut réduire l’overhead de mapping et améliorer certains patterns d’accès, mais il ne change pas le nombre de lanes, la vitesse du lien, ni la contention de l’uplink du switch.

6) x8 est-il plus pénible pour l’entraînement multi-GPU ?

Ça dépend d’où va le trafic de synchronisation. Si les GPU communiquent principalement via NVLink, le PCIe compte moins. S’ils s’appuient sur des transferts médiés par l’hôte ou que votre pipeline de données tape constamment la mémoire hôte, x8 peut faire plus mal.

7) Comment savoir si le goulet est le PCIe ou mon pipeline d’entrée ?

Mesurez le temps de transfert vs le temps de calcul. Lancez un microbench de bande passante hôte↔périphérique pour voir ce que le lien peut faire. Si le lien est sain mais que votre appli est lente, vous êtes probablement limité par le CPU, le stockage ou la synchronisation.

8) Dans les serveurs avec switches PCIe, « x16 » peut-il encore être trompeur ?

Oui. Le GPU peut négocier x16 vers le switch, mais plusieurs GPU peuvent partager l’uplink du switch vers le CPU. Vous devez comprendre tout le chemin, pas seulement le lien endpoint.

9) Quelle est la raison la plus courante pour qu’un GPU fonctionne en Gen3 plutôt qu’en Gen4/Gen5 ?

Les réglages BIOS par défaut et l’intégrité de signal. Une fraction surprenante des « régressions mystères » vient de paramètres firmware plus des chemins matériels marginaux qui déclenchent un downtrain au reboot.

10) Dois-je toujours acheter des plateformes qui garantissent x16 par GPU ?

Si votre charge est gourmande en transferts ou que vous avez besoin de performances multi-tenant prévisibles, oui, payez pour les lanes et la topologie. Si vos workloads sont compute-heavy et bien conçus, vous pouvez souvent échanger des lanes contre la densité — mais validez d’abord avec de vrais benchmarks.

Prochaines étapes pratiques

Faites trois choses cette semaine si vous exploitez des GPU en production :

Inventaire de la réalité : collectez current_link_width et current_link_speed pour chaque nœud GPU et stockez-les avec l’actif.
Bande passante de référence : exécutez un test de bande passante hôte↔périphérique avec mémoire pinned sur chaque SKU matériel et conservez les résultats comme référence.
Codifiez la topologie : notez les règles de population des slots qui préservent l’allocation de lanes prévue et la localité NUMA, et appliquez-les au provisioning.

Puis, quand quelqu’un dira « x8, c’est pratiquement la même chose », vous pourrez répondre comme un adulte : « Parfois. Voici quand. Voici la mesure. Voici la correction. »