Faux et reconditionnés : comment éviter un GPU fantôme

octobre 24, 2025 • février 3, 2026 • Lecture : 27 min • Views: 0

Cet article vous a aidé ?

Vous avez acheté « une carte de classe A100 » chez un courtier parce que les délais étaient mauvais et le service financier pire encore. Elle arrive dans une boîte qui a l’air d’avoir survécu à une petite guerre, est montée en rack, et puis… vos tâches ML tournent comme si elles faisaient des calculs sur un grille-pain.

Bienvenue dans le GPU fantôme : du matériel qui « apparaît » dans l’inventaire et qui fonctionne en quelque sorte, jusqu’au moment où il ne fonctionne plus. Contrefaçons, reconditionnements, firmwares incompatibles, usure liée au minage, imposteurs virtualisés et revendeurs bien intentionnés qui estompent la ligne entre « testé » et « mis sous tension une fois ». Si vous exploitez des systèmes en production, la seule posture correcte est le scepticisme soutenu par des vérifications reproductibles.

Ce qu’est réellement un « GPU fantôme » (et pourquoi cela arrive)

Un GPU fantôme n’est pas une seule chose. C’est une catégorie de mauvaises surprises où le périphérique s’énumère et semble légitime, mais son identité, son état ou ses capacités ne correspondent pas à ce pour quoi vous avez payé. Le thème est la discordance des attentes :

Discordance d’identité : Vous attendiez le modèle X avec 80 Go ; vous obtenez le modèle Y avec un vBIOS mensonger, ou une carte avec des fonctionnalités désactivées.
Discordance d’état : « Neuf » signifie en réalité reconditionné ; « reconditionné » veut dire ex-centrale de minage ou datacenter crypto ayant subi une vie rude.
Discordance de capacité : C’est le bon silicium, mais la thermique, le lien PCIe, l’alimentation ou la stabilité mémoire sont compromis.
Discordance d’environnement : Le GPU est réel, mais votre pilote, noyau, firmware, topologie PCIe ou couche de virtualisation le fait paraître faux.

Les GPU modernes sont une pile : identifiants PCIe, vBIOS, champs VPD, identifiants de carte, numéros de série, fusibles, télémétrie ECC et un pilote qui traduit le marketing en réalité. Les attaquants, revendeurs douteux et accidents honnêtes ciblent tous le même point faible : vous faites confiance à l’étiquette plus qu’à la télémétrie.

Mon parti pris : traitez chaque GPU comme un dispositif de stockage. Vous n’installeriez pas un SSD d’occasion aléatoire dans un cluster de bases de données sans lire SMART, vérifier le firmware et faire un burn-in. Idem ici—sauf que les GPU échouent de façons plus créatives.

Blague n°1 : un « GPU légèrement utilisé pour le minage » est comme un « parachute légèrement utilisé ». Il peut être correct, mais vous ne voulez pas découvrir la vérité en vol.

Quelques faits et un peu d’histoire qui expliquent le bazar actuel

Un peu de contexte rend le marché actuel moins chaotique et plus proche d’une entropie prévisible.

Les contrefaçons de GPU précèdent l’IA. Bien avant les LLM, des contrefacteurs reflashaient des cartes grand public de gamme inférieure pour qu’elles ressemblent à des modèles supérieurs destinés aux joueurs et professionnels.
Le flash de vBIOS est un hobby vieux de plusieurs décennies. Des passionnés l’ont utilisé pour débloquer des fonctionnalités, modifier les courbes de ventilateur ou gagner en performances—créant des outils et un savoir-faire que les contrefacteurs ont ensuite weaponisé.
Le boom crypto 2017–2018 a normalisé les « flottes GPU ». Cette vague a produit d’énormes volumes de cartes très utilisées qui sont ensuite réapparues sur le marché de la revente, souvent nettoyées esthétiquement.
Les GPU datacenter sont devenus des cibles de la chaîne d’approvisionnement quand ils se sont raréfiés. Quand les délais ont explosé, des courtiers sont apparus du jour au lendemain. Certains sont légitimes ; d’autres sont essentiellement des services de routage d’e-déchets.
La topologie PCIe compte davantage aujourd’hui. Les serveurs modernes ont un routage de voies complexe, de la bifurcation, des retimers et plusieurs root complexes—donc « c’est lent » peut venir de votre plateforme, pas de la carte.
La télémétrie ECC a changé la donne. Beaucoup de GPU datacenter exposent des compteurs d’erreurs correctibles/non correctibles. C’est un cadeau—si vous le regardez réellement.
MIG et SR-IOV compliquent l’identité. Le partitionnement et la virtualisation peuvent faire paraître un GPU légitime « incorrect » si vous ignorez le mode dans lequel il se trouve.
Les matériaux thermiques vieillissent plus vite que le marketing ne l’admet. Les pads et pâtes se dégradent ; les ventilateurs s’usent ; les composants VRM dérivent. Un reconditionnement qui « passe le démarrage » peut être à un cycle thermique d’étranglement.

Modèle de menace : comment les GPU contrefaits et reconditionnés vous trompent

1) « Il s’énumère, donc il est réel » est un piège

L’énumération PCIe prouve que vous avez un périphérique. Elle ne prouve pas que c’est le bon périphérique, la bonne taille de mémoire ou la bonne classe de performance. Les contrefacteurs peuvent usurper des noms dans les couches visibles par le logiciel. Et des reconditionnements ordinaires peuvent embarquer des firmwares dépareillés qui rapportent des identifiants confus.

2) Les trois schémas de fraude courants

Reflasher un modèle inférieur en modèle supérieur : Échoue souvent sous charge, affiche une taille mémoire étrange ou présente des IDs de périphérique incohérents entre les outils.
Vendre des cartes réparées comme « neuves » : Composants refaits, puces mémoire remplacées ou GPU « rebullés ». Parfois stables, parfois non. Les pannes peuvent être intermittentes et dépendantes de la chaleur.
Vendre des ex-flottes/ex-minage comme « reconditionné » : Le silicium peut être correct. Le problème est la consommation de durée de vie : ventilateurs, VRAM et VRM. Les charges de minage sont brutales : charge constante, chaleur constante, expérimentations fréquentes d’undervolting/overclocking.

3) L’échec peu glamour : ambiguïté des achats

L’incident le plus courant de « GPU contrefait » en entreprise n’est pas un anneau de contrefaçon hollywoodien. C’est un bon de commande qui dit « équivalent A100 » et un processus d’entrée d’actif qui vérifie seulement que « nvidia-smi montre quelque chose ». Les fantômes prospèrent dans les lacunes entre équipes : achats, opérations datacenter, ingénierie plateforme et finance.

4) L’état d’esprit fiabilité, paraphrasé

Citation (idée paraphrasée) : L’idée de John Allspaw est que la fiabilité est un résultat de la pensée systémique—les hypothèses sont l’ennemi, et les boucles de rétroaction sont le remède.

Playbook de diagnostic rapide (premiers/deuxièmes/troisièmes contrôles)

Vous avez un GPU qui « semble étrange ». Peut-être les performances sont terribles, peut-être il disparaît, peut-être vous soupçonnez qu’il n’est pas conforme à l’étiquette. Voici comment trouver le goulot d’étranglement sans transformer votre journée en hobby médico-légal.

Premier : prouver l’identité basique et la topologie

Le noyau le voit-il de façon cohérente ? Vérifiez l’énumération PCI et les logs du noyau.
Le pilote est-il d’accord ? Comparez lspci vs nvidia-smi (ou les outils ROCm) pour cohérence.
Le lien PCIe est-il sain ? Vitesse et largeur du lien. Une carte x16 qui tourne en x4 est en pratique un « fantôme ».

Second : prouver que les capacités correspondent aux attentes

Taille mémoire et état ECC. Déclare-t-il la VRAM attendue ? ECC activé/désactivé correspond-il au SKU ?
Horloges et limites de puissance. Est-il bridé par la puissance ? Coincé dans un P-state bas ?
Thermique sous charge. Se met-il immédiatement en throttling ?

Troisième : prouver la stabilité avec un court burn-in

Lancez un test de charge contrôlé. Surveillez les erreurs Xid, les pics ECC, les réinitialisations.
Vérifiez la persistance et les redémarrages. Certaines fraudes n’apparaissent qu’après un démarrage à froid ou un cycle d’alimentation.
Comparez à une référence connue bonne. Même classe d’hôte, même pilote, même test.

L’objectif est de séparer : « mauvaise carte » vs « mauvaise plateforme » vs « mauvaise configuration » en moins d’une heure. Si vous ne pouvez pas, vous n’avez pas un problème de diagnostic—vous avez un manque d’observabilité.

Tests d’acceptation avec commandes : prouvez ce que vous avez acheté

Ci-dessous se trouvent des tâches pratiques à exécuter sur des hôtes Linux. Chaque tâche inclut : une commande, ce que signifie une sortie typique et la décision à prendre ensuite. Elles sont écrites pour les outils NVIDIA parce que c’est courant en production, mais la posture s’applique partout : vérifiez depuis plusieurs couches.

Task 1: Confirm PCIe device identity and vendor

cr0x@server:~$ sudo lspci -nn | egrep -i 'vga|3d|nvidia|amd'
01:00.0 3D controller [0302]: NVIDIA Corporation GA100 [A100 PCIe 80GB] [10de:20b5] (rev a1)

Ce que cela signifie : Vous obtenez la paire vendor/device ID ([10de:20b5]) et un nom lisible. L’ID est plus difficile à falsifier qu’une appellation marketing.

Décision : Si l’ID du périphérique ne correspond pas au SKU acheté, arrêtez. Ne « voyez pas si ça marche ». Ouvrez un ticket d’entrée et mettez le matériel en quarantaine.

Task 2: Inspect extended PCIe capabilities and link status

cr0x@server:~$ sudo lspci -s 01:00.0 -vv | egrep -i 'LnkCap|LnkSta'
LnkCap: Port #0, Speed 16GT/s, Width x16, ASPM L0s L1, Exit Latency L0s <512ns, L1 <64us
LnkSta: Speed 16GT/s (ok), Width x16 (ok)

Ce que cela signifie : LnkCap représente ce que le matériel supporte ; LnkSta ce que vous avez effectivement négocié. « (ok) » est votre ami.

Décision : Si la largeur est x8/x4 ou la vitesse 8GT/s alors que vous attendez 16GT/s, dépannez la plateforme : positionnement, choix du slot, paramètres BIOS, bifurcation, retimers. Une plainte « GPU fake » est souvent une erreur de « mauvais slot » déguisée.

Task 3: Check kernel logs for GPU-related errors

cr0x@server:~$ sudo dmesg -T | egrep -i 'nvrm|xid|pcie|aer' | tail -n 25
[Mon Jan 21 09:13:42 2026] NVRM: loading NVIDIA UNIX x86_64 Kernel Module  550.54.14  Tue Dec 17 20:41:24 UTC 2025
[Mon Jan 21 09:14:03 2026] pcieport 0000:00:03.0: AER: Corrected error received: 0000:01:00.0
[Mon Jan 21 09:14:03 2026] nvidia 0000:01:00.0: AER: PCIe Bus Error: severity=Corrected, type=Physical Layer

Ce que cela signifie : Les erreurs AER corrigées peuvent être « tolérables » ou signe d’une intégrité de signal limite. Les erreurs non corrigées sont plus graves. Les codes Xid sont des fautes GPU côté pilote à corréler.

Décision : Si vous voyez beaucoup de spam AER sous charge, suspectez des risers, retimers, problèmes de slot ou matériel limite. Déplacez le GPU sur un autre hôte/slot avant de déclarer la carte frauduleuse.

Task 4: Confirm driver sees the same GPU(s)

cr0x@server:~$ nvidia-smi -L
GPU 0: NVIDIA A100-PCIE-80GB (UUID: GPU-3b2c1c39-1d1a-2f0a-8f1a-1f5c8f5c2a11)

Ce que cela signifie : La pile pilote énumère le GPU et expose un UUID. C’est la clé d’inventaire que vous devriez suivre dans la CMDB, pas « slot 1 ».

Décision : Si lspci montre le GPU mais nvidia-smi non, suspectez un mismatch de pilote, un échec de module noyau, des problèmes Secure Boot ou un GPU qui échoue à l’initialisation.

Task 5: Capture full inventory fields for later comparison

cr0x@server:~$ nvidia-smi -q | egrep -i 'Product Name|Product Brand|VBIOS Version|Serial Number|GPU UUID|Board Part Number|FRU Part Number' -A0
Product Name                    : NVIDIA A100-PCIE-80GB
Product Brand                   : NVIDIA
VBIOS Version                   : 94.00.9F.00.02
Serial Number                   : 0324XXXXXXXXXX
GPU UUID                        : GPU-3b2c1c39-1d1a-2f0a-8f1a-1f5c8f5c2a11
Board Part Number               : 699-2G133-0200-000
FRU Part Number                 : 900-2G133-0200-000

Ce que cela signifie : Ces champs aident à détecter les « lots mélangés » et les chaînes de reconditionnement douteuses. Si les numéros de série manquent, sont dupliqués ou incohérents entre les outils, c’est un signal d’alarme.

Décision : Enregistrez cette sortie à l’entrée. Si un RMA ou un audit survient, vous voudrez la preuve de ce que vous avez réellement reçu et déployé.

Task 6: Check memory size, ECC mode, and ECC error counters

cr0x@server:~$ nvidia-smi --query-gpu=name,memory.total,ecc.mode.current,ecc.errors.corrected.volatile.total,ecc.errors.uncorrected.volatile.total --format=csv
name, memory.total [MiB], ecc.mode.current, ecc.errors.corrected.volatile.total, ecc.errors.uncorrected.volatile.total
NVIDIA A100-PCIE-80GB, 81920 MiB, Enabled, 0, 0

Ce que cela signifie : VRAM et ECC sont des contrôles de cohérence. Des erreurs correctibles qui augmentent sous faible utilisation peuvent indiquer une mémoire vieillissante ou endommagée.

Décision : Si la VRAM est incorrecte, arrêtez. Si les correctables augmentent pendant le burn-in, mettez en quarantaine : cette carte n’est pas pour l’entraînement ou l’inférence en production sous SLA.

Task 7: Verify power limits and throttling reasons

cr0x@server:~$ nvidia-smi --query-gpu=power.draw,power.limit,clocks.current.sm,clocks_throttle_reasons.active --format=csv
power.draw [W], power.limit [W], clocks.current.sm [MHz], clocks_throttle_reasons.active
45.12 W, 250.00 W, 210 MHz, Not Active

Ce que cela signifie : Les horloges au repos doivent être basses ; sous charge vous devriez voir les horloges monter et la puissance approcher la limite. Les raisons de throttling indiquent si vous êtes limité par la puissance/thermique.

Décision : Si le throttling est actif à une charge modeste, vérifiez le refroidissement, le câblage d’alimentation et les rails PSU. Si la limite de puissance est étrangement basse et verrouillée, suspectez des politiques firmware ou des restrictions typiques de certains reconditionnements.

Task 8: Confirm PCIe generation from the driver’s perspective

cr0x@server:~$ nvidia-smi -q | egrep -i 'PCIe Generation|Link Width' -A2
PCIe Generation
    Max                         : 4
    Current                     : 4
Link Width
    Max                         : 16x
    Current                     : 16x

Ce que cela signifie : Croisez avec lspci. S’ils divergent, vous avez un problème de rapport de plateforme ou un lien négocié qui change avec l’état de puissance.

Décision : Si Current est inférieur à Max en état stable sous charge, vous pouvez être bloqué dans un état basse consommation à cause des paramètres BIOS ou des bizarreries ASPM.

Task 9: Check temperature, fan, and immediate throttling behavior

cr0x@server:~$ nvidia-smi --query-gpu=temperature.gpu,temperature.memory,fan.speed,pstate --format=csv
temperature.gpu, temperature.memory, fan.speed [%], pstate
36, 40, 30 %, P8

Ce que cela signifie : Les températures à l’arrêt doivent être raisonnables. Sous charge, surveillez les températures mémoire ; la mémoire peut se mettre en throttling avant le cœur.

Décision : Si la température mémoire est élevée au repos ou augmente rapidement, suspectez un mauvais contact des pads (fréquent après un reconditionnement bâclé) ou un flux d’air bloqué.

Task 10: Validate compute functionality with a minimal CUDA sample

cr0x@server:~$ /usr/local/cuda/samples/1_Utilities/deviceQuery/deviceQuery | egrep -i 'Device 0|CUDA Capability|Total amount of global memory|Result'
Device 0: "NVIDIA A100-PCIE-80GB"
  CUDA Capability Major/Minor version number:    8.0
  Total amount of global memory:                 81161 MBytes (85014073344 bytes)
Result = PASS

Ce que cela signifie : Confirme que le runtime voit la capacité de calcul et la mémoire attendues. C’est une vérification peu coûteuse pour détecter des discordances évidentes.

Décision : Si la capacité de calcul ne correspond pas à l’attendu, votre « A100 » peut être d’une architecture différente, ou votre pile conteneur/pilote ment via des bibliothèques incompatibles.

Task 11: Run a short burn-in and watch for Xid/ECC events

cr0x@server:~$ sudo gpu-burn -d 60
Burning for 60 seconds.
GPU 0: 0.0%  (0/1024 MB)
GPU 0: 100.0%  (1024/1024 MB)
Tested 1 GPUs:
  GPU 0: OK

Ce que cela signifie : Un burn-in rapide n’est pas la preuve d’une santé à long terme, mais il met en évidence une instabilité immédiate : mauvaises puces VRAM, alimentation marginale, surchauffe.

Décision : Si le test plante le pilote, génère des Xid ou fait monter l’ECC, mettez en quarantaine et retestez sur un autre hôte. Si le problème suit la carte, c’est la carte.

Task 12: Check GPU reset behavior (useful for flaky refurbs)

cr0x@server:~$ sudo nvidia-smi --gpu-reset -i 0
GPU 00000000:01:00.0 was reset.

Ce que cela signifie : Le fait que la réinitialisation fonctionne est un signe que le GPU répond correctement aux contrôles de gestion.

Décision : Si la réinitialisation échoue de façon répétée, ou si le GPU disparaît après réinitialisation jusqu’à un cycle d’alimentation complet de l’hôte, c’est un signal rouge de stabilité. Ne le déployez pas dans un pool Kubernetes en espérant le meilleur.

Task 13: Verify IOMMU grouping for passthrough / isolation sanity

cr0x@server:~$ for d in /sys/kernel/iommu_groups/*/devices/*; do echo "$d"; done | egrep '01:00.0|01:00.1'
/sys/kernel/iommu_groups/42/devices/0000:01:00.0
/sys/kernel/iommu_groups/42/devices/0000:01:00.1

Ce que cela signifie : Si vous faites du passthrough, un comportement « mystérieux » du GPU peut venir de problèmes IOMMU et ACS. Un GPU légitime peut sembler hanté s’il est groupé avec d’autres périphériques.

Décision : Si le GPU partage un groupe avec du stockage ou des NICs, vous pourriez avoir besoin des paramètres BIOS ACS ou d’un emplacement de slot différent.

Task 14: Confirm persistence mode and compute mode policies

cr0x@server:~$ sudo nvidia-smi -pm 1
Enabled persistence mode for GPU 00000000:01:00.0.

Ce que cela signifie : La persistance peut réduire les remaniements d’initialisation et améliorer la stabilité pour certaines charges. Ce n’est pas une solution pour du mauvais matériel, mais cela réduit le bruit des « cold starts » du pilote pendant les tests.

Décision : Si l’activation de la persistance génère des erreurs, vous avez probablement un mismatch pilote/matériel. Enquêtez avant le déploiement des charges.

Task 15: Spot virtualization/MIG configuration that changes what you “see”

cr0x@server:~$ nvidia-smi -q | egrep -i 'MIG Mode' -A2
MIG Mode
    Current                     : Enabled
    Pending                     : Enabled

Ce que cela signifie : Avec MIG activé, vous ne verrez peut-être pas « un grand GPU » dans votre ordonnanceur comme vous l’attendiez. Les gens confondent cela avec « reconditionné ayant mauvaise VRAM » en permanence.

Décision : Si votre attente est une allocation GPU complète, désactivez MIG (pendant une fenêtre de maintenance) ou adaptez votre ordonnancement et votre logique d’inventaire aux instances MIG.

Task 16: Cross-check PCIe errors live while stressing

cr0x@server:~$ sudo journalctl -k -f | egrep -i 'aer|xid|nvrm'
Jan 21 09:22:41 server kernel: NVRM: Xid (PCI:0000:01:00): 13, Graphics SM Warp Exception
Jan 21 09:22:41 server kernel: pcieport 0000:00:03.0: AER: Uncorrected (Non-Fatal) error received: 0000:01:00.0

Ce que cela signifie : La corrélation en direct pendant la mise en contrainte est la façon de séparer « lent » de « cassé ». Xid 13 est souvent lié au calcul ; la ligne AER pointe vers des problèmes de lien.

Décision : Si des erreurs AER apparaissent uniquement dans un châssis/slot, réparez la plateforme. Si elles suivent le GPU, il y a un risque matériel—traitez en conséquence.

Blague n°2 : le GPU le plus cher est celui qui passe les achats et échoue lors de la première rotation d’astreinte.

Trois mini-histoires d’entreprise tirées du terrain

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

Une entreprise SaaS de taille moyenne a décidé de ramener l’inférence en interne. Ils ont acheté un petit lot de « GPU de classe datacenter » via un courtier parce que le distributeur agréé avait une liste d’attente. Le contrôle d’entrée était simple : monter le nœud en rack, lancer nvidia-smi, confirmer une chaîne de nom, puis le remettre à l’équipe plateforme.

Tout semblait correct pendant une semaine. Puis la latence du service modèle a commencé à augmenter d’une façon qui ne correspondait pas au trafic. L’auto-scaling ajoutait des nœuds, ce qui aidait brièvement, puis plus. L’SRE en astreinte a remarqué un motif : les nœuds du nouveau lot étaient systématiquement plus lents, mais seulement sous charge maximale. Les tableaux de bord blâmaient la « variance du modèle ». Le business blâmait les « données ». Classique.

La vraie panne était une mauvaise hypothèse : « Si nvidia-smi dit A40, c’est une A40. » Les périphériques étaient des cartes NVIDIA réelles, mais elles avaient négocié une largeur PCIe plus faible à cause d’un mauvais slot/riser dans cette génération de châssis. Sous faible charge, personne ne l’a remarqué. Sous forte charge, le goulot PCIe rendait les transferts de lots et host-device painfully lents, et la logique de placement de l’ordonnanceur continuait à mettre des modèles à débit élevé sur ces nœuds.

La réparation fut embarrassante de simplicité : déplacer les GPU vers les slots corrects et verrouiller les paramètres BIOS pour empêcher la bifurcation accidentelle. La leçon n’était pas « les courtiers sont malfaisants ». La leçon était que les contrôles d’identité doivent inclure des vérifications de topologie. Un GPU fantôme peut être créé par votre propre agencement de rack.

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

Une équipe ML d’entreprise voulait une meilleure utilisation. Ils ont activé MIG sur toute une flotte pour que plusieurs équipes puissent partager les GPU en sécurité. L’idée était bonne : isoler les charges, augmenter l’équité, réduire l’inactivité. Finance adorait la projection.

Puis les jobs d’entraînement ont commencé à échouer de façons bizarres : out-of-memory à des tailles qui « devraient tenir », performances incohérentes, et quelques conteneurs rapportant une VRAM plus petite que prévu. L’équipe a soupçonné du matériel contrefait parce que les symptômes correspondaient au folklore internet : « la carte ment sur la mémoire ». Ils ont escaladé vers les achats, puis vers le légal, et tout le monde a eu une poussée d’adrénaline.

La cause racine était une optimisation qui s’était retournée contre eux à cause d’une communication incomplète. MIG était activé, mais l’ordonnanceur et la documentation interne supposait encore une allocation GPU complète. Certaines équipes lançaient de gros jobs sur des tranches MIG puis s’étonnaient que la tranche se comporte comme une tranche. Pire, la surveillance agrégait la mémoire GPU au niveau de l’hôte et faisait sembler que la mémoire « disparaissait » dans la journée.

La correction fut opérationnelle : étiquetage explicite des profils MIG, contrôle d’admission pour empêcher les jobs full-GPU sur des devices tranchés, et un point d’identité GPU qui rapporte le mode MIG et les tailles d’instances. Le matériel était innocent ; c’était la couche d’abstraction qui faisait la farce.

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

Une fintech avec un contrôle de changement strict traitait les GPU comme tout autre composant critique. Chaque carte entrante passait par un harnais d’entrée : enregistrer les IDs PCI, enregistrer les versions vBIOS, effectuer un test de stress de 30 minutes, consigner les compteurs ECC avant et après, et stocker les résultats dans une base d’actifs indexée par UUID GPU.

Un trimestre, ils ont acheté un lot mixte : certains neufs, certains reconditionnés par le fournisseur, tous de canaux légitimes. Un sous-ensemble a passé la fonctionnalité initiale mais a montré une petite hausse des erreurs ECC correctibles pendant le stress. Pas assez pour planter. Assez pour susciter suspicion. Le harnais d’entrée les a automatiquement signalés car la politique était « mouvement ECC pendant burn-in = quarantaine ». Règle ennuyeuse, appliquée de manière cohérente.

Deux semaines plus tard, une autre équipe du secteur a rapporté une série de pannes GPU liées à la mémoire après avoir déployé des lots reconditionnés similaires en production. Cette entreprise n’a pas participé à cette « fête ». Leurs GPUs mis en quarantaine ont été renvoyés selon les conditions du fournisseur, et la flotte de production est restée propre.

La pratique n’était pas ingénieuse. Elle ne nécessitait pas d’accès spécial ni de secrets fournisseurs. C’était juste de la discipline : capturer la télémétrie de base, la comparer et prendre des décisions d’acceptation avant que le matériel ne rencontre vos clients.

Erreurs courantes : symptôme → cause racine → correction

Cette section est conçue pour le triage. Si votre situation GPU semble « hantée », faites correspondre le symptôme à une cause probable et appliquez la correction qui change réellement l’issue.

1) Symptom: “GPU is detected, but performance is half of expected”

Cause racine : Lien PCIe négocié à une largeur/vitesse plus basse (x4/x8, Gen3 au lieu de Gen4), souvent dû à un mauvais slot, des problèmes de riser ou une bifurcation BIOS.

Correction : Vérifiez LnkSta via lspci -vv et nvidia-smi -q. Déplacez vers un slot x16 connu bon. Désactivez la bifurcation inattendue. Remplacez riser/retimer si les erreurs persistent.

2) Symptom: “nvidia-smi shows the right name, but memory size is wrong”

Cause racine : MIG activé, ou vous regardez une instance GPU et non le GPU complet. Alternativement, mismatch firmware ou reflash frauduleux.

Correction : Vérifiez le mode MIG. Si MIG est désactivé et que la mémoire est toujours incorrecte, comparez les IDs PCI et les champs vBIOS ; mettez la carte en quarantaine et vérifiez sur un hôte connu bon.

3) Symptom: “GPU disappears after reboot or under load”

Cause racine : Instabilité de l’alimentation, VRM qui surchauffent, intégrité de signal PCIe marginale, ou compatibilité pilote/noyau. Les reconditionnements avec alimentation fatiguée peuvent faire cela à chaud.

Correction : Vérifiez dmesg pour AER et Xid. Assurez un câblage d’alimentation correct. Validez le flux d’air du châssis et les courbes de ventilateurs. Retestez dans un autre nœud pour isoler carte vs plateforme.

4) Symptom: “Correctable ECC errors increase during stress”

Cause racine : Dégradation VRAM ou usage intensif antérieur. Parfois induit aussi par une mémoire qui surchauffe à cause de pads défectueux.

Correction : Mettre en quarantaine pour usage production. Inspecter la thermique ; réinstaller et vérifier le refroidissement. Si cela augmente encore, retourner/RMA.

5) Symptom: “Clocks are stuck low; GPU never boosts”

Cause racine : Limite de puissance verrouillée basse, plafond thermique, problèmes de persistance/configuration, ou mode restreint dans un environnement partagé.

Correction : Vérifiez les raisons de throttling et la limite de puissance. Confirmez qu’aucune politique admin (gestion datacenter, réglages nvidia) ne bride. Corrigez le flux d’air ; confirmez les pilotes corrects.

6) Symptom: “Driver loads, but CUDA sample fails”

Cause racine : Versions pilote/runtime incompatibles, mauvaise configuration du runtime conteneur, ou défauts matériels qui n’apparaissent qu’en calcul.

Correction : Alignez pilote et runtime CUDA. Lancez deviceQuery sur l’hôte d’abord, puis dans le conteneur. Si l’hôte échoue, traitez comme un problème matériel/pilote ; si seul le conteneur échoue, corrigez la pile conteneur.

7) Symptom: “Lots of PCIe corrected errors, but workloads mostly run”

Cause racine : Problèmes d’intégrité de signal : riser, retimer, connecteur sale, ou carte mère marginale. Parfois déclenché par une forte consommation et la chaleur.

Correction : Déplacez le GPU vers un autre slot ou hôte. Nettoyez/inspectez les connecteurs. Mettez à jour BIOS/firmware. Si les erreurs suivent le slot, corrigez la plateforme ; si elles suivent le GPU, considérez-le comme un risque.

8) Symptom: “Two GPUs report the same serial or missing serial”

Cause racine : Chaîne de reconditionnement reprogrammée les champs VPD, ou rapportage tooling/firmware cassé.

Correction : Clé d’inventaire sur UUID GPU et IDs PCI, pas seulement le numéro de série. Si les anomalies de série corrèlent avec d’autres bizarreries, mettez le lot en quarantaine et poussez sur le fournisseur.

Listes de contrôle / plan étape par étape (de l’achat à la prod)

Step 0: Procurement rules (before money leaves the building)

Rédigez les spécifications d’achat comme un ingénieur, pas un marketeur. Spécifiez le modèle exact, la taille mémoire, le facteur de forme, l’interconnexion (PCIe vs SXM) et le statut reconditionné acceptable.
Exigez la provenance et les termes. Vous voulez une confirmation écrite du statut neuf/reconditionné, de la garantie et des conditions de retour. S’ils refusent de s’engager, vous ne devriez pas non plus.
Demandez les vBIOS et numéros de pièce en amont. Les fournisseurs légitimes peuvent généralement fournir les plages typiques de vBIOS/PN ou au moins les reconnaître.
Budgetez du temps pour les tests d’entrée. Du matériel sans test d’acceptation n’est que du hasard coûteux.

Step 1: Physical intake (the “don’t be impressed by shrink-wrap” phase)

Photographiez les étiquettes, connecteurs et tout indicateur d’altération. Pas pour le spectacle—pour pouvoir prouver l’état à l’arrivée.
Inspectez la tranche PCIe pour l’usure, des résidus ou des signes de reprise de soudure.
Inspectez les connecteurs d’alimentation pour coloration thermique.
Vérifiez les vis du dissipateur pour marques d’outil ; un reconditionnement lourd laisse des cicatrices.

Step 2: Baseline software inventory (10 minutes per node)

Enregistrez lspci -nn, l’état du lien lspci -vv, et les champs d’identité nvidia-smi -q.
Consignez l’UUID GPU, la version vBIOS et les numéros de pièce de carte.
Assurez-vous que les versions de pilote sont cohérentes sur la flotte avant de juger les performances.

Step 3: Platform validation (stop blaming the card for your chassis)

Vérifiez la largeur et la génération PCIe au repos et sous charge.
Confirmez les paramètres BIOS : Above 4G decoding, politiques Resizable BAR (si applicable), ASPM, bifurcation, attentes SR-IOV/MIG.
Confirmez une alimentation adéquate : câbles appropriés, capacité PSU et absence de surprises de rails partagés.

Step 4: Burn-in and telemetry policy (make it hard for bad hardware to sneak in)

Stress pendant au moins 30 minutes pour les GPU destinés à la production ; plus long si possible.
Capturez les compteurs ECC avant et après.
Capturez les logs noyau pendant le stress (AER, Xid).
Critères de rejet : toute ECC non correctible, toute augmentation d’ECC correctible pendant le burn-in, réinitialisations Xid répétées, AER persistants sous charge.

Step 5: Production rollout (gradual, labeled, reversible)

Déployez d’abord dans un pool canari. Lancez des charges réelles avec un rayon d’impact sécurisé.
Étiquetez les nœuds avec les UUID GPU et le statut d’acceptation dans l’inventaire de votre ordonnanceur.
Configurez des alertes : deltas ECC, fréquence Xid, throttling thermique, taux d’erreurs PCIe.
Ayez une trappe de secours : cordon/vidage rapide des nœuds GPU et workflow RMA clair.

FAQ

1) Can a fake GPU really pass `nvidia-smi`?

Oui, dans le sens où les chaînes visibles par le logiciel peuvent être manipulées. Mais il est difficile de tout falsifier de façon cohérente : IDs PCI, capacité de calcul, comportement taille mémoire sous charge, télémétrie ECC et stabilité. C’est pourquoi vous croisez les contrôles.

2) What’s the single best “authenticity” check?

Il n’y en a pas une seule. Si on vous force : commencez par lspci -nn pour les device IDs plus un court test de contrainte tout en surveillant ECC/Xid et l’état du lien PCIe. L’identité sans stabilité est une illusion.

3) Are refurbished GPUs always a bad idea?

Non. Le reconditionné peut être correct s’il vient d’un canal crédible avec garantie et si vous effectuez des tests d’acceptation. Le problème est l’usage de « reconditionné » comme euphémisme pour « historique inconnu ».

4) How do mining GPUs fail differently?

Vous verrez souvent l’usure des ventilateurs, des interfaces thermiques dégradées et de l’instabilité mémoire. Elles peuvent « bien tourner » jusqu’à atteindre certaines plages de température, puis commencer à générer des ECC correctibles ou des réinitialisations de pilote.

5) If ECC is disabled, can I still detect memory problems?

Oui, mais vous les détecterez plus tard et de façon plus douloureuse. Sans la télémétrie ECC, vous vous fiez davantage aux tests de stress, erreurs applicatives et plantages. Pour la fiabilité en production, préférez des SKU avec ECC et ECC activé.

6) Why does PCIe width matter so much if my compute is on the GPU?

Parce que vous transférez toujours des données : lots, poids, activations, pré/post-traitement, checkpointing et communications multi-nœuds. Un GPU avec un lien PCIe bridé peut sembler être du « code modèle lent » jusqu’à ce que vous le mesuriez.

7) How long should burn-in be?

Pour l’entrée : 30 minutes détectent beaucoup de cas. Pour des clusters à enjeux élevés : 2–12 heures est préférable, surtout pour les reconditionnés. L’objectif n’est pas la perfection ; c’est faire apparaître les défaillances début-de-vie et la mémoire marginale.

8) What if the GPU is real but has a weird vBIOS version?

Étrange ne veut pas automatiquement dire faux. Cela peut signifier firmware OEM spécifique, mise à jour de reconditionnement ou décalage. La bonne réponse est de comparer dans le lot, vérifier le comportement sous charge et s’aligner sur une matrice firmware/pilote supportée.

9) Can virtualization make a real GPU look counterfeit?

Absolument. MIG, vGPU, passthrough et mismatches runtime conteneur peuvent changer la mémoire rapportée, le nom du périphérique et même l’exposition des capacités. Vérifiez toujours sur l’hôte nu avant d’escalader à « fraude ».

10) What do I store in my asset database for GPUs?

Au minimum : UUID GPU, vendor/device PCI IDs, numéros de pièce de carte, version vBIOS, mapping hôte/slot, et résultats des tests d’entrée (ECC avant/après, résultat du stress, logs). Les numéros de série aident, mais ne basez pas votre audit uniquement dessus.

Prochaines étapes pratiques

Si vous voulez moins de GPU fantômes dans votre vie, faites trois choses et faites-les de façon cohérente :

Arrêtez de faire confiance aux chaînes de nom. Croisez les IDs PCI, les champs vBIOS et les capacités rapportées par le pilote. Enregistrez-les à l’entrée.
Mesurez la plateforme, pas seulement la carte. Vérifiez la largeur/vitesse PCIe et surveillez les erreurs AER sous charge. Beaucoup de « mauvais GPU » sont en fait des slots, risers ou paramètres BIOS défectueux.
Adoptez une politique de rejet que vous appliquerez réellement. Mouvement ECC, tempêtes de Xid et throttling thermique pendant le burn-in ne sont pas des « bizarreries ». Ce sont des avertissements précoces.

L’objectif n’est pas la paranoïa. C’est l’hygiène opérationnelle. En production, « probablement correct » est la façon dont le matériel devient folklore—et le folklore est la façon dont les incidents obtiennent des budgets.