MCM Graphics : Ce qui peut mal tourner et comment les fournisseurs le corrigent

Ce qui change avec les GPU MCM (et pourquoi l’équipe exploit devrait s’en soucier)

Les GPU MCM reposent sur l’idée qu’un « GPU » n’est plus un morceau monolithique de silicium. C’est un package avec plusieurs dies actifs — tiles de calcul, dies IO, empilements de mémoire, dies de cache — reliés entre eux par des interconnexions haute vitesse et un packaging avancé (interposers 2.5D, ponts silicium, substrats organiques, différentes variantes de micro-bumps).

Du point de vue opérationnel, le profil de risque change de trois manières :

1. Plus de liaisons susceptibles de tomber en panne. Chaque saut supplémentaire die-à-die est une opportunité pour l’intégrité du signal, l’horloge, l’entraînement ou le bruit d’alimentation de mal tourner.
2. Plus d’arbitrage côté firmware. Un die monolithique peut cacher la complexité interne derrière un « ça marche ». Les MCM nécessitent plus d’entraînements au démarrage, de gestion des liens, de traitement d’erreurs et parfois de reconfiguration à chaud.
3. Plus de façons d’être « à peu près fonctionnel ». La dégradation partielle devient courante : une tile throttle, un empilement mémoire génère des corrections ECC, un lien se réentraîne sous charge. Vos tableaux de bord indiquent « GPU opérationnel », tandis que vos SLO disent le contraire.

Voici le piège opérationnel : les ingénieurs traitent les GPU MCM comme de grandes versions des modèles de l’an dernier. Même playbook de pilotes, mêmes hypothèses thermiques, même état d’esprit « si ça passe le burn-in c’est bon ». Cette hypothèse ne vieillit pas bien.

Une citation qui reste douloureusement pertinente dans ce domaine est une idée paraphrasée souvent attribuée à John Ousterhout : La complexité s’accumule ; elle s’accumule jusqu’à ce que le système devienne difficile à comprendre et peu fiable. Les MCM ne créent pas la complexité à partir de rien — ils la déplacent dans le packaging, le firmware et la télémétrie, où vos intuitions peuvent être plus faibles.

Faits intéressants et contexte (court et utile)

• Les chiplets ne sont pas nouveaux. Les packages multi-die existent depuis des décennies ; ce qui a changé, c’est la densité de bande passante et le packaging qui les fait se comporter comme un seul dispositif à l’échelle GPU.
• HBM a fait du « niveau package » le nouveau point critique. Quand des empilements mémoire sont à côté du calcul sur un interposer, de nombreux schémas de panne de l’époque DIMM disparaissent — et de nouveaux apparaissent (thermiques locaux aux stacks, marge PHY, comportement ECC par empilement).
• Les anciens multi-GPU (SLI/CrossFire) sont un mauvais modèle mental. Ceux-là étaient « plusieurs dispositifs sur PCIe ». Les MCM sont « un dispositif avec des fabrics internes », ce qui change la contention d’erreurs et la sémantique des resets.
• L’économie du rendement est un moteur majeur. Les dies plus petits ont un meilleur rendement ; les fournisseurs peuvent trier les tiles, couper les unités faibles et construire des gammes de produits sans parier sur un seul grand masque.
• Le packaging avancé est son propre domaine de fiabilité. Micro-bumps, underfill et gauchissement du substrat peuvent créer des défaillances dépendantes du temps qui ressemblent à des « plantages pilotes aléatoires ».
• L’entraînement des interconnexions est désormais une phase critique au boot. Les échecs d’entraînement de liens peuvent se manifester par des problèmes d’énumération intermittents ou des chutes de performance qui n’apparaissent qu’après un démarrage à froid.
• La télémétrie s’est améliorée, mais son interprétation est plus difficile. Vous obtenez des compteurs par lien, ECC par empilement, throttle par tile… et un flot de faux positifs si vos seuils sont naïfs.
• Les fonctions RAS deviennent de plus en plus déterminantes. Les erreurs corrigeables et les comportements d’isolation font désormais partie de la promesse produit, pas seulement un bonus pour le HPC.

Modes de panne : ce qui casse dans le monde réel

1) Instabilité de l’interconnexion die-à-die : « ce n’est pas en panne, c’est juste lent… parfois »

Les GPU MCM vivent ou meurent par leurs fabrics internes : liens die-à-die, interconnexions cohérentes de cache, connexions PHY mémoire, et parfois des fabrics externes comme des liens NVLink entre packages. Ces liens ont des phases d’entraînement, d’égalisation et des mécanismes de correction d’erreurs qui peuvent dériver avec la température, la tension ou le vieillissement.

Comment ça se manifeste :

• Jitter de performance : la latence p95 double sans changement évident d’utilisation.
• Verrouillages intermittents sous charge maximale, souvent lors d’all-reduce ou de trafic pair-à-pair intensif.
• Les compteurs d’erreurs corrigeables augmentent régulièrement ; des erreurs non corrigeables provoquent un reset GPU ou l’arrêt du job.

Ce qui se passe réellement : marge de lien marginale, réentraînement périodique ou surcharge progressive des corrections d’erreurs. Le GPU « fonctionne », mais votre bande passante effective s’effondre.

2) Distribution d’alimentation et réponse transitoire : votre PSU est innocent, vos rails le sont moins

Les MCM tendent à augmenter les transitoires de courant locaux : plusieurs tiles commutant en synchronisme, rafales HBM, pics d’activité du fabric. Les VRM de la carte et les régulateurs sur package doivent suivre. S’ils n’y parviennent pas, vous obtenez un comportement de type brownout qui ressemble à des bugs logiciels.

Comment ça se manifeste :

• Resets GPU lors de rampes de charge soudaines (démarrage de job, rafale de lancements de kernels, transitions de phase en précision mixte).
• Les logs noyau affichent « GPU fallen off the bus » ou des resets de lien PCIe.
• Plus d’erreurs aux limites de puissance élevées ou avec des clocks boost agressifs.

3) Gradients thermiques à l’intérieur du package : la température moyenne ment

Avec plusieurs dies et des stacks HBM, le point le plus chaud n’est pas forcément là où pointe votre métrique « température GPU » sur une ligne. Vous pouvez avoir une température rapportée « correcte » et pourtant voir une tile ou un empilement mémoire être en throttling.

Comment ça se manifeste :

• Fréquences réduites de manière imprévisible ; la perf ressemble à une congestion mais ne l’est pas.
• Les ECC HBM correctables corrèlent avec une température ambiante élevée ou des courbes de ventilateur inappropriées.
• Les problèmes n’apparaissent qu’à certaines hauteurs de rack ou flux d’air.

Blague #1 : Le throttling thermique est la façon qu’a le GPU de dire « Je ne suis pas fâché, je suis juste déçu », tout en divisant votre débit par deux en douce.

4) Les sémantiques de reset deviennent plus étranges : resets partiels, contextes bloqués et « GPU fantômes »

Sur des GPU monolithiques, un reset signifiait souvent « resetter l’ensemble du périphérique ». Sur MCM, les fournisseurs peuvent tenter des récupérations plus fines : resetter une tile, réentraîner un lien, isoler un empilement mémoire, redémarrer un microcontrôleur. C’est bien — jusqu’à ce que votre pile pilote, noyau ou application suppose que « reset = tout réinitialisé ».

Comment ça se manifeste :

• GPU visible par l’OS, mais création de contextes CUDA/ROCm/OpenCL qui échoue.
• Les nœuds de périphérique existent ; les outils rapportent « OK » ; les jobs échouent immédiatement.
• Seul un redémarrage complet de l’hôte restaure le comportement normal.

5) ECC et télémétrie RAS : les corrections sont un avertissement, pas un motif de fierté

Les correctables ECC HBM sont souvent traitées comme « acceptables ». En production, une augmentation du taux de corrections est un signal précoce pour des problèmes thermiques, une intégrité signal marginale ou des erreurs non corrigeables imminentes. Les MCM ajoutent des surfaces supplémentaires : plusieurs stacks, plus de PHY, plus de contrôleurs.

Comment ça se manifeste :

• Montée lente des erreurs correctables, puis terminaisons soudaines de jobs.
• Erreurs « illegal memory access » inexpliquées qui corrèlent avec des événements ECC.
• Taux d’erreur plus élevé sur certains GPU ou emplacements dans le châssis.

6) Comportement PCIe et BAR : le lien hôte compte toujours

Même si l’intérieur du GPU est basé sur des chiplets, l’hôte voit un périphérique PCIe. Les GPU MCM peuvent augmenter la pression MMIO, la sensibilité au dimensionnement des BAR et la complexité des resets. Resizable BAR et les réglages IOMMU peuvent aider ou nuire selon la qualité du firmware.

Comment ça se manifeste :

• Le périphérique s’énonce, mais le pilote échoue à l’initialisation après des mises à jour de firmware.
• Les logs PCIe Advanced Error Reporting (AER) montrent des rafales correctables sous charge.
• Les transferts pair-à-pair sont plus lents que prévu, ou se terminent parfois par un timeout.

7) Ordonnancement du pilote et « hypothèses implicites » sur la symétrie

Certaines premières conceptions MCM exposent de l’asymétrie : die IO vs dies de calcul, caches partagés ou domaines d’affinité mémoire différents. Si le pilote suppose une latence uniforme, il peut placer le travail de façon sous-optimale. Si votre application suppose l’uniformité, elle peut amplifier le problème.

Comment ça se manifeste : des chutes de performance qui n’apparaissent que pour certaines tailles de batch, formes de tenseur ou motifs d’accès mémoire. Le benchmark A dit « super », la charge de production dit « pourquoi payons-nous pour ça ».

8) Microcontrôleurs firmware : le système d’exploitation caché à l’intérieur du GPU

Les GPU modernes embarquent plusieurs contrôleurs pour la gestion d’alimentation, la sécurité, l’ordonnancement et le RAS. Les MCM augmentent les besoins de coordination : plus d’endpoints, plus d’états, plus de séquences d’entraînement. Les bugs de firmware deviennent de la « flakiness hardware » dans votre canal d’incident.

Comment ça se manifeste :

• Problèmes qui disparaissent après une mise à jour du firmware (ou apparaissent après).
• Problèmes qui se reproduisent uniquement après un redémarrage à chaud, pas après un cold boot.
• « Bloqué en état basse consommation » ou « n’accélère pas » sans cause thermique.

9) Vieillissement au niveau du packaging : quand « ça marche en QA » ne veut pas dire « ça marche au mois 14 »

Les cycles thermiques, les vibrations et l’électromigration à long terme peuvent dégrader les connexions de bump et la marge d’interconnexion. Ces pannes commencent souvent par des erreurs corrigeables et des réentraînements de liens intermittents. Elles deviennent plus tard des « resets aléatoires ».

Comment ça se manifeste : « Nous avons changé le logiciel, le noyau, le pilote, la version du modèle, et le problème persiste sur le même GPU physique. » C’est le moment où on arrête de débattre et où l’on commence l’isolement matériel.

Comment les fournisseurs patchent concrètement les GPU MCM

Quand un GPU MCM rencontre un problème sur le terrain, les fournisseurs patchent à travers les couches. Les changements matériels viennent plus tard. La production doit survivre à l’entre-deux.

Couche de patch 1 : mises à jour de firmware (VBIOS, firmware du périphérique, images de microcontrôleurs)

Les patches firmware ciblent typiquement :

• Entraînement de liens et égalisation : meilleurs presets, fenêtres d’entraînement plus longues, logique de retry ajustée pour des canaux marginaux.
• Gestion d’alimentation : transitions boost moins agressives, mitigation différente du droop de tension, séquences de power gating révisées.
• Politique RAS : quand resetter, quand isoler, quand fonctionner en mode dégradé ; seuils d’escalade pour les correctables.
• Gestion des resets : amélioration de la récupérabilité sans reboot hôte.

Réalité opérationnelle : les mises à jour firmware ne sont pas « agréables ». Ce sont des événements de changement avec risque de rollback, dépendance aux versions de pilotes et parfois interactions avec le BIOS de la carte mère.

Couche de patch 2 : changements dans le pilote noyau

Les pilotes corrigent autour du comportement matériel. Schémas communs :

• Ajustement de la détection de timeout : éviter les faux positifs de hang sur des kernels longs ou des fabrics lourds.
• Meilleure décodification d’erreurs : mapper des codes d’erreur cryptiques en catégories actionnables ; exposer des compteurs par lien.
• Contournements : désactiver un chemin d’optimisation qui déclenche un bug matériel (oui, ça arrive).
• Amélioration des resets : tenter un reset de tile avant un reset complet du périphérique ; meilleur nettoyage des contextes.

Couche de patch 3 : bibliothèques et runtimes en espace utilisateur

Les stacks CUDA/ROCm/OpenCL, bibliothèques de collectives et frameworks ML livrent parfois des mitigations :

• Choix d’algorithmes par défaut différents pour all-reduce quand le P2P est instable.
• Comportement de pooling mémoire plus conservateur pour réduire le stress induit par la fragmentation.
• Checks de santé qui détectent les états de « device zombie » et échouent vite.

Couche de patch 4 : BIOS de plateforme et quirks PCIe

Les mises à jour BIOS/UEFI de la carte mère peuvent ajuster ASPM PCIe, le comportement d’entraînement de liens, la gestion des BAR et les valeurs par défaut IOMMU. Sur certaines plateformes, c’est la différence entre « quelques correctables rares » et « resets de bus quotidiens ».

Comment les fournisseurs décident quoi patcher en premier

Les fournisseurs cherchent la reproductibilité. S’ils peuvent reproduire un hang avec un motif de workload spécifique, ils patcheront le pilote. Si c’est spécifique à une plateforme, ils donneront des recommandations BIOS. Si c’est clairement une marge d’intégrité signal, ils pourront ajuster l’entraînement ou baisser les clocks par défaut. Si c’est un vrai erratum silicium, ils fourniront des contournements maintenant et un correctif sur une révision plus tard.

Ce que vous devez faire : traitez firmware GPU et pilote comme une unité couplée. Ne « mettez pas à jour le pilote » isolément en vous étonnant ensuite qu’un mismatch firmware-pilote provoque de nouveaux modes de panne.

Blague #2 : Les notes de version des fournisseurs sont comme les bulletins météo : utiles, parfois erronées, et on ne devrait pas ignorer les avertissements de tempête.

Feuille de route pour un diagnostic rapide

Quand un cluster de GPU MCM commence à mal se comporter, vous ne résolvez pas un problème de philosophie. Vous localisez un goulot d’étranglement et décidez de remédier, mettre en quarantaine ou rétrograder.

Première étape : déterminer s’il s’agit du lien hôte, de la santé du périphérique ou du workload

1. Sanité du lien hôte : PCIe AER, changements de vitesse/largeur de lien, « fallen off the bus », fautes IOMMU.
2. Santé du périphérique : compteurs ECC, raisons de throttling, logs Xid/reset du pilote, erreurs fabric.
3. Corrélation workload : cela arrive-t-il seulement sur certains kernels, tailles de batch ou patrons de communication ?

Deuxième étape : classifier la panne comme « dégradation » vs « panne dure »

• Dégradation : débit en baisse, latence en hausse, correctables en augmentation, clocks instables. Action : drainer + investiguer, éventuellement tuning firmware/driver, vérifier flux d’air.
• Panne dure : ECC non corrigeable, boucles de reset GPU, périphérique qui disparaît. Action : mettre en quarantaine GPU/nœud immédiatement, préserver les logs, ne pas tourner en rond.

Troisième étape : déterminer l’étendue et le rayon d’impact

• Un seul GPU : suspecter marginalité matérielle ou problème local de slot/PSU/flux d’air.
• Noeud entier : suspecter BIOS plateforme, noyau, alimentation, backplane ou mise à jour pilote.
• Rack/rangée : suspecter refroidissement, distribution électrique, déploiement de firmware ou lot défectueux de nœuds.
• Cluster entier après un changement : suspecter mismatch logiciel/firmware ou comportement d’ordonnanceur.

Quatrième étape : choisir l’atténuation la moins risquée qui gagne du temps

• Réduire le power cap / désactiver le boost temporairement.
• Ajuster la courbe des ventilateurs ou la contention d’air ; vérifier les températures d’entrée d’air.
• Désactiver le chemin P2P problématique / changer l’algorithme de collective.
• Épingler sur un couple pilote+firmware stable ; rétrograder si la régression est évidente.
• Mettre en quarantaine les GPU avec des ECC en hausse ou des resets récurrents.

Tâches pratiques : commandes, sorties et décisions

Voici les vérifications de base que j’exécute quand les GPU MCM sentent le problème. Chaque tâche inclut une commande, ce que la sortie signifie et la décision à prendre. Les commandes supposent Linux avec des outils courants ; adaptez à votre environnement.

Task 1: Check basic GPU visibility and persistence state

cr0x@server:~$ nvidia-smi -L
GPU 0: NVIDIA A100-SXM4-80GB (UUID: GPU-2d3f...)
GPU 1: NVIDIA A100-SXM4-80GB (UUID: GPU-9a11...)

Ce que cela signifie : Les GPU s’énumèrent et le pilote peut communiquer avec eux. Des GPU manquants suggèrent des problèmes PCIe/lien/plateforme, pas un « kernel lent ».

Décision : Si un GPU est manquant ou apparaît de façon intermittente, vérifiez immédiatement PCIe AER et dmesg ; ne perdez pas de temps dans les logs du framework ML.

Task 2: Read driver/kernel error logs for resets and bus events

cr0x@server:~$ sudo dmesg -T | egrep -i "nvrm|xid|pcie|aer|amdgpu|iommu" | tail -n 20
[Mon Jan 21 08:12:44 2026] NVRM: Xid (PCI:0000:41:00): 79, pid=22341, GPU has fallen off the bus.
[Mon Jan 21 08:12:44 2026] pcieport 0000:40:01.0: AER: Corrected error received: 0000:40:01.0
[Mon Jan 21 08:12:44 2026] pcieport 0000:40:01.0: PCIe Bus Error: severity=Corrected, type=Physical Layer, (Receiver ID)

Ce que cela signifie : « Fallen off the bus » est un événement de classe lien hôte/puissance/reset. Les AER de couche physique suggèrent une intégrité de signal ou une instabilité du lien.

Décision : Si vous voyez des rafales AER répétées autour des pannes, traitez d’abord comme un problème matériel/plateforme : slot, riser, câble (le cas échéant), paramètres PCIe du BIOS, transitoires d’alimentation.

Task 3: Verify PCIe link width/speed didn’t downshift

cr0x@server:~$ sudo lspci -s 41:00.0 -vv | egrep -i "LnkCap:|LnkSta:"
LnkCap: Port #0, Speed 16GT/s, Width x16, ASPM L0s L1, Exit Latency L0s<1us, L1<8us
LnkSta: Speed 8GT/s (downgraded), Width x8 (downgraded)

Ce que cela signifie : Le dispositif peut faire Gen4 x16 mais fonctionne en Gen3 x8. C’est un cliff de performance et souvent le symptôme d’une intégrité de signal marginale ou de quirks BIOS.

Décision : Si downshift, reseat/contrôlez les risers, mettez à jour le BIOS plateforme, envisagez de forcer la génération PCIe dans le BIOS pour la stabilité, et comparez avec des nœuds connus bons.

Task 4: Check Resizable BAR status (common source of “works but weird”)

cr0x@server:~$ sudo lspci -s 41:00.0 -vv | egrep -i "Resizable BAR|BAR 1|Region 0" -n
55: Region 0: Memory at 3a000000000 (64-bit, prefetchable) [size=16M]
61: Resizable BAR: Current Size: 256MB, Supported: 256MB 512MB 1GB 2GB 4GB

Ce que cela signifie : Le dimensionnement des BAR affecte l’efficacité du mapping CPU des apertures mémoire GPU. Certains couples firmware/pilote régressent fortement avec certaines tailles.

Décision : Si vous voyez des échecs d’initialisation après des mises à jour, essayez de basculer Resizable BAR dans le BIOS de manière cohérente sur la flotte plutôt que de le laisser varier nœud par nœud.

Task 5: Check GPU clocks, power, and throttling reasons

cr0x@server:~$ nvidia-smi -q -d CLOCK,POWER,TEMPERATURE | egrep -i "GPU Current Temp|Power Draw|Power Limit|Clocks|Throttle" -n | head -n 60
118: GPU Current Temp            : 78 C
141: Power Draw                  : 345.22 W
142: Power Limit                 : 400.00 W
210: Clocks
214:     Graphics                : 990 MHz
230:     Memory                  : 1215 MHz
310: Clocks Throttle Reasons
314:     SW Power Cap            : Active
318:     HW Thermal Slowdown     : Not Active

Ce que cela signifie : Vous êtes limité en puissance par le logiciel même si les thermiques ne throttlent pas. Cela peut être intentionnel (politique data center) ou une mauvaise configuration.

Décision : Si la perf est basse et que SW power cap est actif, validez votre politique de limite de puissance ; envisagez d’augmenter la limite ou d’adoucir les pics de charge.

Task 6: Inspect ECC error counters (correctables matter)

cr0x@server:~$ nvidia-smi -q -d ECC | egrep -i "Volatile|Aggregate|Correctable|Uncorrectable" -n | head -n 80
60: Volatile ECC Errors
62:     Single Bit
64:         Device Memory        : 120
70:     Double Bit
72:         Device Memory        : 0
90: Aggregate ECC Errors
92:     Single Bit
94:         Device Memory        : 8421

Ce que cela signifie : Les erreurs ECC correctables s’accumulent. Les comptes volatiles se réinitialisent au reboot ; les agrégats persistent selon l’implémentation.

Décision : Si les correctables augmentent rapidement ou corrèlent avec des périodes chaudes, drenez ce GPU des charges sensibles à la latence et enquêtez sur le refroidissement et les mises à jour firmware. Si des doubles bits (non corrigeables) apparaissent, mettez immédiatement en quarantaine.

Task 7: Pull fabric / NVLink-class link status (where supported)

cr0x@server:~$ nvidia-smi nvlink --status
GPU 0: Link 0: Up
GPU 0: Link 1: Up
GPU 1: Link 0: Up
GPU 1: Link 1: Down

Ce que cela signifie : Un lien est down ; le système peut retomber sur des chemins plus lents, changeant la performance et parfois la stabilité selon la topologie.

Décision : Si un lien est down de façon inattendue, planifiez une maintenance. Ne « relancez pas simplement les jobs » — les collectives peuvent se comporter différemment et cacher le problème jusqu’au trafic maximal.

Task 8: Check PCIe AER counters live (if exposed) via journal

cr0x@server:~$ sudo journalctl -k --since "10 min ago" | egrep -i "AER:|PCIe Bus Error" | tail -n 20
Jan 21 08:11:05 server kernel: pcieport 0000:40:01.0: AER: Corrected error received: 0000:40:01.0
Jan 21 08:11:05 server kernel: pcieport 0000:40:01.0: PCIe Bus Error: severity=Corrected, type=Physical Layer

Ce que cela signifie : Les erreurs de couche physique corrigées indiquent souvent des liens marginaux. Une ou deux peuvent être du bruit ; des rafales sous charge sont un motif.

Décision : Si le compteur augmente avec l’activité GPU, priorisez des corrections plateforme : reseat, paramètres BIOS, swap du riser, ou déplacer le GPU vers un autre slot pour confirmer.

Task 9: Confirm IOMMU state (can interact with resets and peer-to-peer)

cr0x@server:~$ dmesg -T | egrep -i "iommu|dmar" | head -n 20
[Mon Jan 21 07:58:01 2026] DMAR: IOMMU enabled
[Mon Jan 21 07:58:01 2026] DMAR: Intel(R) Virtualization Technology for Directed I/O

Ce que cela signifie : L’IOMMU est activé. C’est souvent approprié en environnements partagés, mais cela peut exposer des bugs pilote/périphérique ou des régressions de performance selon les réglages.

Décision : Si vous voyez des fautes de mapping DMA ou un comportement pair-à-pair étrange, testez avec des réglages IOMMU connus bons (y compris passthrough) sur un canary avant de changer à l’échelle de la flotte.

Task 10: Measure GPU utilization vs memory utilization to spot “fabric waits”

cr0x@server:~$ nvidia-smi dmon -s pucm -d 1 -c 5
# gpu   pwr gtemp mtemp    sm   mem   enc   dec
# Idx     W     C     C     %     %     %     %
    0   210    74     -     12     85     0     0
    1   205    73     -     15     88     0     0

Ce que cela signifie : L’utilisation SM est faible tandis que l’utilisation mémoire est élevée : la charge est liée à la mémoire, en attente ou bloquée sur des transferts. En MCM, des problèmes de fabric interne peuvent se déguiser en « memory-bound ».

Décision : Si ce motif apparaît soudainement après un changement ou seulement sur certains GPU, suspectez throttling, downshifts de lien ou un problème de fabric/plumbing plutôt qu’un « modèle qui s’est dégradé ».

Task 11: Check for GPU resets and persistence events via vendor tools (NVIDIA example)

cr0x@server:~$ nvidia-smi -q | egrep -i "Reset Status|Pending|Retired Pages" -n | head -n 80
420: Reset Status
424:     Reset Required          : No
610: Retired Pages
614:     Single Bit ECC          : 2
618:     Double Bit ECC          : 0

Ce que cela signifie : Le retrait de pages indique que le pilote/firmware cartographie des zones mémoire défectueuses. C’est un signal de fiabilité, pas un détail anecdotique.

Décision : Si les retraits de pages augmentent, planifiez un remplacement. S’ils se stabilisent à un faible nombre et qu’aucune autre erreur n’apparaît, vous pouvez le garder dans un pool de niveau inférieur, mais surveillez de près.

Task 12: Stress-test the interconnect path you actually use (not a toy benchmark)

cr0x@server:~$ python3 -c "import torch; import time; x=torch.randn(8192,8192,device='cuda'); torch.cuda.synchronize(); t=time.time(); y=x@x; torch.cuda.synchronize(); print('matmul_s', time.time()-t)"
matmul_s 0.7421183586120605

Ce que cela signifie : Un test simple de timing de kernel. Il ne validera pas toute votre pile, mais aide à distinguer « GPU fondamentalement lent/cassé » de « réseau du cluster en feu ».

Décision : Si le calcul single-GPU est stable mais que les jobs multi-GPU échouent, concentrez-vous sur P2P/NVLink/PCIe et les bibliothèques de collectives. Si le single-GPU est instable, concentrez-vous sur thermiques/puissance/pilote/firmware par nœud.

Task 13: Validate topology and peer-to-peer capability (NVIDIA example)

cr0x@server:~$ nvidia-smi topo -m
        GPU0    GPU1    CPU Affinity
GPU0     X      NV1     0-31
GPU1    NV1      X      0-31

Ce que cela signifie : Les GPU ont un lien rapide (NV1). Si vous attendiez NVLink et voyez « PHB » ou « SYS », votre trafic passe par PCIe/CPU, et votre modèle de perf est faux.

Décision : Si la topologie n’est pas celle prévue, ne peaufinez pas le logiciel à l’infini. Corrigez le placement, le câblage, le BIOS ou la construction physique.

Task 14: Confirm versions (driver, firmware) and stop running mystery combos

cr0x@server:~$ nvidia-smi
Wed Jan 21 08:14:02 2026
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 550.54.14    Driver Version: 550.54.14    CUDA Version: 12.4     |
+-----------------------------------------------------------------------------+

Ce que cela signifie : Vous avez une version de pilote concrète. Liezz-la à votre inventaire de versions firmware ; « dernier » n’est pas une stratégie d’inventaire.

Décision : Si des pannes corrèlent avec un déploiement pilote récent, geler et rétrograder sur un sous-ensemble. Si ça corrèle avec le firmware, coordonnez une montée/descente d’images assorties.

Task 15: Check CPU frequency scaling and IRQ storms (because GPUs don’t live alone)

cr0x@server:~$ sudo turbostat --Summary --quiet --show Avg_MHz,Busy%,Bzy_MHz -i 2 -n 3
Avg_MHz  Busy%  Bzy_MHz
  1020   12.34    8270
   980   10.90    8205
  1005   11.80    8250

Ce que cela signifie : Si le CPU reste à basse fréquence à cause d’une politique d’alimentation ou de limites thermiques, il peut goulotter l’alimentation des données, le surcoût de lancement et la gestion I/O — surtout pour des kernels petits ou un plan de contrôle chargé.

Décision : Si l’utilisation GPU est faible et que le CPU est contraint, corrigez la politique d’alimentation CPU, le refroidissement ou la distribution IRQ avant d’accuser le GPU.

Task 16: Quick NIC and RDMA sanity (multi-GPU jobs fail here a lot)

cr0x@server:~$ ip -s link show dev eth0 | head -n 12
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP mode DEFAULT group default qlen 1000
    RX:  bytes  packets  errors  dropped  missed   mcast
    9876543210  1234567  0       0        0        12
    TX:  bytes  packets  errors  dropped  carrier collsns
    8765432109  2345678  0       0        0       0

Ce que cela signifie : Pas d’erreurs/drops. Si vous voyez des erreurs, votre « GPU hang » peut être simplement un job en attente de collectives réseau.

Décision : Si des erreurs réseau alignent avec des stalls, triez d’abord le réseau. Si le réseau est propre et que seules certaines paires GPU échouent, revenez aux liens P2P GPU et à la topologie.

Trois mini-histoires d’entreprise (anonymisées, plausibles et douloureuses)

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

L’entreprise avait une nouvelle flotte GPU basée sur MCM et une jolie doc interne qui disait « les correctables ECC sont attendus ; ignorez-les sauf si non corrigeables ». Quelqu’un a écrit ce doc à partir d’une génération plus ancienne où les correctables étaient rares et essentiellement inoffensifs.

Six mois plus tard, des jobs d’entraînement ont commencé à échouer dans des clusters — toujours pendant la même phase d’une exécution de modèle. Les ingénieurs ont accusé une mise à jour de framework. Ils l’ont rollbackée. Les pannes ont continué. Puis ils ont blâmé la bibliothèque de collectives. Ils l’ont réglée. Les pannes ont continué. Pendant ce temps, le tableau de bord des correctables ECC affichait vert parce que le seuil d’alerte était réglé « déraisonnablement haut, pour éviter le bruit ».

Finalement, un SRE a comparé un « nœud bon » et un « nœud mauvais » côte à côte. Le nœud mauvais montrait une montée régulière des erreurs HBM correctables corrélée à des températures d’entrée plus élevées en haut du rack. Rien de spectaculaire. Juste une pente.

La solution n’était pas glamour : ils ont resserré le contrôle thermique, ajusté les courbes de ventilateurs et changé l’automatisation pour mettre en quarantaine les GPU quand les correctables montent plus vite qu’une ligne de base. Après cela, les non corrigeables ont majoritairement disparu. La mauvaise hypothèse était de traiter les correctables comme négligeables plutôt que prédictifs.

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

Une équipe performance voulait gratter du débit. Ils ont augmenté les limites de puissance GPU et activé le boost le plus agressif permis par le fournisseur. Les benchmarks s’amélioraient bien. Le déploiement s’est fait à large échelle, car les tests canary étaient courts et les graphiques flatteurs.

Deux semaines plus tard, des resets GPU intermittents sont apparus, toujours sous des charges en rafales. Les logs ressemblaient à une « flakiness pilote » classique. Les ingénieurs ont chassé des fantômes logiciels : runtimes de conteneurs, versions de noyau, même un agent de monitoring suspect. Les resets continuaient, surtout sur des nœuds avec des PSU légèrement plus anciens et un air ambiant un peu plus chaud.

Ce qui s’était réellement passé était de la physique ennuyeuse : la nouvelle politique de puissance augmentait les paliers de charge transitoires, et un sous-ensemble de cartes/plateformes avait moins de marge. Les fabrics internes et les liens PCIe étaient plus sensibles à ces chutes que les anciens GPU monolithiques. Les pannes étaient assez rares pour échapper aux tests courts, mais assez fréquentes pour détruire les SLOs en production.

Le rollback vers des limites de puissance conservatrices a arrêté les resets. Ensuite, ils ont réintroduit le tuning lentement, avec des soak tests plus longs et une surveillance explicite des rafales PCIe AER et des changements de raisons de throttling. La leçon : en territoire MCM, « plus de puissance » n’est pas un curseur de performance gratuit ; c’est aussi un levier de fiabilité.

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

Une autre organisation tenait une matrice stricte hardware+firmware. Chaque nœud rapportait version pilote, versions VBIOS/firmware, BIOS plateforme et un petit ensemble de compteurs RAS dans un système style CMDB. C’était ennuyeux. Les ingénieurs se plaignaient que cela ralentissait les rollouts.

Puis un fournisseur a sorti une mise à jour pilote qui améliore la performance sur le papier mais introduit un bug de reset rare sur un stepping firmware spécifique. Seul un sous-ensemble de nœuds avait ce stepping — à cause d’un lot d’achat en milieu d’année. Les flottes mixtes arrivent ; faire comme si ce n’était pas le cas n’aide pas.

Quand les pannes ont commencé, ils n’ont pas eu besoin d’une semaine d’archéologie. Ils ont interrogé : « montre les nœuds avec pilote X et firmware Y et augmentation PCIe AER. » L’intersection était petite et nette. Ils ont épinglé ces nœuds sur l’ancien pilote, gardé le reste sur la nouvelle version et ont continué à expédier.

Ce n’était pas de l’héroïsme. C’était de la discipline d’inventaire et des déploiements graduels. La meilleure réponse aux incidents, c’est de ne pas avoir à deviner.

Erreurs courantes : symptôme → cause racine → correctif

1) Symptom: sudden throughput drop on a subset of nodes

Cause racine : downshift du lien PCIe (Gen4→Gen3, x16→x8) après réentraînement à cause d’une intégrité de signal marginale ou de problèmes de riser.

Fix : Vérifier le statut du lien avec lspci -vv ; reseater/remplacer GPU/riser, mettre à jour le BIOS plateforme, envisager de forcer la gen PCIe, remplacer les risers suspects.

2) Symptom: intermittent “GPU fallen off the bus” under load

Cause racine : problème de transitoire d’alimentation/marge VRM, parfois aggravé par des limites de puissance/boost agressives ou un manque de headroom PSU.

Fix : baisser temporairement le power cap ; vérifier PSU et câblage ; mettre à jour le firmware GPU ; effectuer des soak tests plus longs avant de réactiver les réglages agressifs.

3) Symptom: jobs fail only on multi-GPU, single-GPU tests pass

Cause racine : problèmes fabric/P2P/NVLink-class, mismatch de topologie ou sensibilité d’algorithme de collective aux erreurs de lien.

Fix : vérifier nvidia-smi topo -m et l’état des liens ; changer l’algorithme de collective ou désactiver le chemin P2P en mitigation ; planifier une inspection matérielle si un lien est down.

4) Symptom: rising correctable ECC errors but “no failures yet”

Cause racine : gradient thermique, PHY HBM marginal, vieillissement du package. C’est souvent prédictif.

Fix : corréler le taux ECC avec la température d’entrée et la vitesse des ventilateurs ; améliorer le refroidissement ; mettre à jour firmware/pilote ; mettre en quarantaine si le taux dépasse la ligne de base ou si les retraits de pages augmentent.

5) Symptom: GPU visible to OS but runtime fails to create contexts

Cause racine : reset partiel laissant le périphérique dans un état incohérent ; mismatch pilote/firmware ; état persistant du daemon de persistence obsolète.

Fix : tenter un reset GPU supporté par le fournisseur ; si non fiable, redémarrer le nœud ; imposer des couples pilote+firmware assortis et des paramètres de persistence cohérents.

6) Symptom: performance jitter at stable utilization

Cause racine : réentraînement de lien interne, raisons de throttling cachées ou oscillation de gestion d’énergie.

Fix : inspecter les raisons de throttling ; rechercher des rafales AER ; stabiliser la politique d’alimentation ; mettre à jour le firmware qui améliore l’entraînement de liens.

7) Symptom: after an update, some nodes won’t initialize GPU driver

Cause racine : interaction BIOS plateforme + Resizable BAR + pilote, ou dépendance firmware non satisfaite.

Fix : standardiser les paramètres BIOS ; valider l’état Resizable BAR ; rétrograder le pilote sur le stepping matériel affecté ; éviter les réglages mixtes dans la flotte.

8) Symptom: “random” failures that follow the same physical GPU across hosts

Cause racine : marginalité matérielle ou vieillissement au niveau du packaging ; les compteurs d’erreurs racontent l’histoire.

Fix : swapper le GPU dans un hôte connu bon pour confirmer ; si le problème suit le GPU, mettre en quarantaine et lancer RMA ; arrêter de blâmer les kernels.

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

Quand vous achetez ou adoptez des GPU MCM

1. Exiger une matrice support pilote+firmware et la traiter comme un contrat, pas une suggestion.
2. Planifier l’ingestion de télémétrie : ECC (par empilement si disponible), compteurs de lien, raisons de throttling, compteurs de reset.
3. Standardiser les paramètres BIOS plateforme : politique gen PCIe, Resizable BAR, mode IOMMU.
4. Concevoir une marge thermique : cibles de température d’entrée, politiques ventilateurs et validation du flux d’air au niveau du rack.
5. Exécuter des soak tests qui imitent la production (la durée compte ; la rafale compte).

Quand vous déployez un nouveau firmware/pilote

1. Canary sur des steppings matériels représentatifs et des emplacements de rack (zones chaudes/froides).
2. Suivre : rafales PCIe AER, largeur/vitesse de lien, taux correctables ECC, retraits de pages, événements de reset.
3. Garder prêts les artefacts de rollback (paquets pilote, images firmware, profil BIOS connu bon).
4. Déployer graduellement ; arrêter au premier signe d’une nouvelle signature d’erreur.
5. Ne jamais changer firmware, pilote et BIOS en même temps sauf si vous aimez l’ambiguïté.

Quand vous êtes en incident

1. Classifier : dégradation vs panne dure.
2. Préserver les preuves : dmesg/journal, logs fournisseur, compteurs ECC avant reboot si possible.
3. Vérifier l’état du lien PCIe et AER en premier ; c’est rapide et souvent décisif.
4. Atténuer avec le plus petit rayon d’impact : drainer/mettre en quarantaine un GPU ou un nœud ; réduire le power cap.
5. Ensuite seulement creuser dans les symptômes au niveau framework.

Quand vous construisez la fiabilité à long terme

1. Alerter sur les taux, pas seulement les seuils absolus (correctables ECC par heure vaut mieux que « ECC > 10 000 »).
2. Garder un nœud « connu bon » pour comparaisons.
3. Automatiser la quarantaine pour signatures de reset récurrentes et taux d’erreurs en hausse.
4. Maintenir l’inventaire de : firmware/VBIOS GPU, pilote, noyau, BIOS plateforme et mapping slot/riser.
5. Exécuter des vérifications périodiques de lien et de débit pour détecter les downshifts silencieux.

FAQ

1) Les GPU MCM sont-ils intrinsèquement moins fiables que les GPU monolithiques ?

Pas intrinsèquement. Ils ont plus de surfaces de panne (liens, entraînement, packaging), mais aussi de meilleures options RAS et un meilleur tri de rendement. La fiabilité dépend fortement de la maturité du firmware, de la qualité de la plateforme et de votre discipline opérationnelle.

2) Quel est l’indicateur unique le plus courant d’un problème matériel ?

Des événements PCIe AER répétés sous charge, des downshifts de lien et des messages « fallen off the bus ». Ce ne sont pas vos scripts Python qui déraillent.

3) Dois‑je ignorer les erreurs ECC correctables ?

Non. Traitez-les comme un détecteur de fumée. Une correction occasionnelle peut aller ; un taux en hausse mérite investigation ou quarantaine.

4) Pourquoi des problèmes n’apparaissent-ils qu’après un warm reboot ?

Parce que l’entraînement de lien et les séquences d’initialisation du firmware peuvent différer entre cold boot et reset à chaud. Certains canaux marginaux passent par un chemin mais pas l’autre.

5) Les mises à jour firmware améliorent-elles généralement la stabilité ?

Souvent oui — surtout tôt dans la vie d’un produit. Mais elles peuvent aussi introduire des régressions. Déployez le firmware comme vous déployez des noyaux : par étapes, mesuré, réversible.

6) Quelles métriques dois-je alerter pour les GPU MCM ?

Taux correctables ECC, événements non corrigeables, retraits de pages, compteurs de reset, raisons de throttling (puissance/thermique), largeur/vitesse de lien PCIe, rafales PCIe AER. Ajoutez l’état des liens fabric quand disponible.

7) « GPU utilisation basse, mémoire haute » est-ce toujours un problème de modèle ?

Non. Cela peut indiquer un comportement memory-bound, mais dans les systèmes MCM cela peut aussi indiquer des problèmes de fabric interne, des réentraînements de lien, du throttling ou des goulots côté hôte alimentant le GPU.

8) Comment décider entre mettre en quarantaine un GPU ou remplacer tout le nœud ?

Si le problème suit le GPU lorsqu’il est déplacé vers un hôte connu bon, mettre en quarantaine/RMA le GPU. Si plusieurs GPU échouent dans le même hôte/slot/rack, suspecter l’alimentation plateforme, les thermiques, le BIOS, les risers ou le backplane.

9) Resizable BAR peut-il causer de vrais problèmes en production ?

Oui — principalement via des interactions firmware/pilote. Standardisez le paramètre et validez avec votre couple pilote+firmware exact ; ne le laissez pas varier dans la flotte.

10) Quel est le meilleur « premier test » quand la performance semble erronée ?

Vérifiez l’état du lien PCIe (lspci -vv), puis les raisons de throttling et la puissance/thermiques, puis ECC et logs de reset. Rapide, objectif et souvent décisif.

Conclusion : étapes pratiques suivantes

Les GPU MCM ne sont pas de la magie fragile. Ce sont juste des GPU plus distribués : plus de liens, plus de contrôleurs, plus d’états. Quand ils tombent en panne, ils se dégradent souvent plutôt que de tomber en panne proprement, ce qui est pire pour les SLO et éprouvant pour les personnes.

Ce qu’il faut faire ensuite, dans l’ordre :

1. Standardiser et inventorier votre matrice pilote+firmware+BIOS. Les combos mystères mixtes sont la cause des clusters hantés.
2. Alerter sur les tendances : taux correctables ECC, rafales AER, downshifts de lien, signatures de reset.
3. Opérationnaliser la quarantaine pour les récidivistes. Ne laissez pas un GPU marginal empoisonner une file de jobs.
4. Déployer par étapes avec des soak tests qui reflètent la production, incluant des phases rafales et des collectives multi-GPU.
5. Conserver une boucle de diagnostic rapide qui commence par PCIe/lien/thermiques avant de plonger dans les logs du framework.

Si vous faites ces choses, les GPU MCM cessent d’être mystérieux. Ils redeviennent ce qu’ils devraient être : des radiateurs coûteux qui font aussi des calculs utiles.