ATI vs NVIDIA : pourquoi cette rivalité ne s’arrête jamais

Pourquoi cette rivalité ne s’arrête jamais (ce n’est pas personnel, c’est opérationnel)

Les décisions d’achat de GPU ressemblent à des débats produits jusqu’à ce que vous les exploitiez. Ensuite, elles ressemblent à du risque de chaîne d’approvisionnement,
à des matrices de compatibilité noyau/pilote, à des bizarreries de firmware et à « pourquoi le conteneur ne voit plus l’appareil ». ATI/AMD vs NVIDIA perdure
parce que chaque camp optimise une définition différente de « ça marche ».

NVIDIA traite historiquement le pilote et la pile de calcul comme un produit strictement contrôlé. Vous obtenez une histoire cohérente :
CUDA, cuDNN, NCCL, TensorRT, et un modèle de pilote qui reste consistant entre distributions — au prix d’être un invité dans
le monde du noyau Linux, pas un citoyen à part entière. C’est efficace, rapide, et parfois comparable à l’utilisation d’un contrôleur RAID propriétaire :
génial jusqu’à ce que vous ayez besoin que les entrailles coopèrent avec votre noyau, votre compositeur ou votre posture de sécurité.

L’histoire moderne d’AMD est plus en amont : AMDGPU dans le noyau, Mesa en espace utilisateur, un comportement plus « natif » pour Linux.
Cela tend à être agréable opérationnellement — moins de colle bizarre, moins de blobs binaires, meilleure conformité avec ce que les distros
attendent pour la gestion graphique. Mais c’est dans le calcul que la gravité frappe : la base installée de CUDA est un fossé, et ROCm présente encore
des arêtes vives en matière de support matériel, de packaging et de longue traîne de bibliothèques.

Si vous attendez un vainqueur universel, vous achetez une religion. Mieux vaut : choisissez les modes de défaillance que vous pouvez tolérer.
Si vous faites du ML, vos choix par défaut sont façonnés par CUDA jusqu’à preuve du contraire. Si vous gérez des postes Linux à grande échelle,
l’alignement en amont et l’intégration noyau prévisible importent souvent plus que des gains de bench.

Faits historiques qui façonnent encore les décisions d’aujourd’hui

Le passé n’est pas anecdotique ici. Il explique pourquoi certaines API sont devenues des choix par défaut, pourquoi les piles de pilotes sont comme elles sont,
et pourquoi votre commercial parle de « feuille de route » comme d’une incantation.

8 points de contexte (concrets, pas de musée)

1. ATI a été rachetée par AMD en 2006. Cela a changé les incitations : les GPU sont devenus partie d’une stratégie CPU+GPU,
   influençant le graphique intégré, les APU et plus tard l’attitude « pilote open-source ».
2. NVIDIA a introduit CUDA en 2006. Ce n’était pas le premier en calcul GPU, mais c’est devenu le choix par défaut car il
   était utilisable, stable et promu sans relâche dans le milieu académique et industriel.
3. OpenCL n’a jamais détrôné CUDA. Il existe, il fonctionne, il est assez portable, et souvent c’est un outil « plus petit dénominateur commun »
   dans lequel les fournisseurs n’ont pas investi à égalité.
4. La trajectoire open-source d’AMD a été un pivot sur plusieurs années. Le passage des anciennes piles propriétaires à AMDGPU/Mesa n’était pas
   seulement idéologique ; c’était une manœuvre de survie pour la compatibilité Linux et la confiance des développeurs.
5. Le monde GPGPU a normalisé l’accélération « spécifique au fournisseur ». CUDA en est l’exemple évident, mais de nombreuses bibliothèques ML et HPC
   intègrent des hypothèses sur les kernels, le comportement mémoire et les outils de profilage liés à un fournisseur.
6. Le gaming a poussé à un rythme élevé de changements de fonctionnalités. Les évolutions des modèles de shaders, l’async compute, le ray tracing
   et les fonctionnalités de génération d’images rendent la « dernière version du pilote » tentante — et dangereuse côté opérationnel.
7. Les piles d’affichage ont changé sous nos pieds. L’adoption de Wayland et les compositeurs modernes ont exposé différents points de friction
   entre modèles propriétaires et upstream, en particulier pour le multi-écran et les taux de rafraîchissement variables.
8. Les gammes GPU datacenter ont divergé des comportements grand public. ECC VRAM, télémétrie, gestion de puissance et virtualisation ont rendu
   l’idée « c’est essentiellement le même silicium » risquée.

Deux philosophies : fermé-et-polished vs ouvert-et-intégré

Cette rivalité survit parce que les fournisseurs optimisent pour des bords différents d’un même triangle : performance, portabilité et opérabilité.
Vous obtenez rarement les trois.

La force de NVIDIA : gravité d’écosystème et « un seul interlocuteur »

Le plus grand atout de NVIDIA n’est pas les TFLOPS bruts. C’est l’attente que CUDA soit disponible, que l’outillage soit mature et que la prochaine
bibliothèque que vous pip-installerez possède une wheel CUDA avant toute autre chose. Le profilage est cohérent. Le support fournisseur est structuré.
En production, ça compte : vous pouvez standardiser images, AMI de base et provisionnement de nœuds autour d’une pile qui se comporte de façon similaire
entre générations de matériel.

Le coût est l’enfermement fournisseur et un modèle de pilote qui peut donner l’impression d’ignorer poliment les règles de votre distro.
Les mises à jour du noyau deviennent de la gestion du changement. Secure Boot devient un sujet, pas une case à cocher. Et lorsque les serveurs d’affichage évoluent,
vous attendez la compatibilité.

La force d’AMD/ATI : alignement en amont et comportement « natif Linux »

AMDGPU dans le noyau et Mesa comme pile 3D principale signifient moins de surprises exotiques. Vous bénéficiez du même génie logiciel qui maintient le reste de Linux fonctionnel.
Le débogage peut être plus transparent. Et pour de nombreux usages graphiques — surtout sur des distros modernes — AMD peut être le choix « ça marche tout simplement » d’une
manière autrefois inimaginable.

Le coût apparaît dans le calcul et la longue traîne : contraintes de support matériel ROCm, douleur du pinning de versions et le fait que de nombreux projets upstream
considèrent toujours NVIDIA comme « la cible » et les autres comme « best effort ».

Avis tranché : si votre activité dépend aujourd’hui d’un framework ML spécifique, supposez NVIDIA sauf si vous avez un chemin ROCm testé. Si votre activité dépend de
postes Linux qui doivent rester fonctionnels à travers des mises à jour noyau, considérez AMD par défaut et faites mériter l’exception à NVIDIA.

Pilotes, noyaux et l’art de ne pas briquer votre poste

Les GPU sont deux choses à la fois : un périphérique de calcul et un périphérique d’affichage. Ces rôles se percutent dans l’architecture des pilotes. Le chemin d’affichage
s’intéresse aux compositeurs, modesetting, suspend/reprise et bizarreries multi-écrans. Le chemin de calcul s’intéresse aux bibliothèques utilisateur stables, à la découverte
cohérente des périphériques et au comportement mémoire prévisible.

Intégration noyau : en amont vs hors-arbre

Le pilote principal d’AMD fait partie de l’écosystème noyau. Cela ne garantit pas la perfection, mais signifie que les régressions sont visibles et corrigeables dans le même
workflow que le reste du système. Le module noyau propriétaire de NVIDIA vivait historiquement hors-arbre, avec un rythme et des contraintes différents. Cela s’améliore
avec des approches récentes, mais opérationnellement vous devez toujours prévoir l’accouplement noyau-pilote comme un risque de premier plan.

Piles d’affichage : Xorg pardonne, Wayland dit la vérité

Xorg permet aux fournisseurs de masquer les défauts. Wayland rend plus explicite une grande partie du pipeline, ce qui expose des désaccords : sync explicite, gestion des buffers,
routage multi-GPU et comportement VRR. Si vous déployez des stations de développeurs ou du VDI, votre « choix de fournisseur GPU » est souvent « quel ensemble de bugs d’affichage
souhaitons-nous assumer ».

Citation fiabilité (idée paraphrasée)

L’espoir n’est pas une stratégie. — idée paraphrasée largement attribuée dans les cercles ops/fiabilité

Traitez les décisions fournisseurs GPU comme des décisions sur un contrôleur de stockage : vous faites des benchmarks, oui. Mais vous testez aussi les upgrades,
la récupération après panne et l’observabilité. C’est là que la rivalité devient réelle.

Piles de calcul : CUDA, ROCm, OpenCL et la gravité des choix par défaut

La raison pratique pour laquelle la rivalité ne s’arrête pas : CUDA est devenu l’hypothèse par défaut pour le « calcul GPU ». Une fois qu’un millier de scripts internes,
notebooks, conteneurs et outils tiers supposent CUDA, changer de fournisseur devient un projet de migration — pas un bon de commande.

CUDA : le chemin bien éclairé

CUDA n’est pas juste une API ; c’est tout un écosystème de débogueurs, profileurs, bibliothèques mathématiques, communication collective et conventions de packaging.
Cet écosystème réduit la variance. La variance est ce qui cause les incidents à 3h du matin.

Quand NVIDIA casse quelque chose, ils ont tendance à le corriger vite parce que cela affecte beaucoup de clients payants. Ça ne signifie pas que vous êtes en sécurité.
Cela signifie que le rayon d’impact est suffisamment large pour motiver des correctifs rapides.

ROCm : réel, en amélioration, encore conditionnel

ROCm peut être excellent lorsque vous êtes sur du matériel et des versions pris en charge. Les performances peuvent être compétitives, et l’histoire de l’outillage
plus ouverte est attrayante. Mais le piège opérationnel est le « presque pris en charge ». Un GPU peut afficher correctement en graphique et rester un casse-tête en calcul.
Ou un léger décalage de pilote peut se transformer en périphériques manquants dans les conteneurs.

OpenCL et les API « portables »

OpenCL est la réponse classique au verrouillage, mais beaucoup d’équipes ne l’utilisent qu’indirectement. Certaines applications l’utilisent pour des kernels spécifiques
ou des accélérations legacy. En 2026, la portabilité est souvent obtenue via des frameworks de plus haut niveau qui choisissent des backends. C’est un progrès, mais aussi
une dette d’abstraction : quand les performances sont mauvaises, vous finissez par déboguer le backend que vous espériez éviter.

Avis tranché : si vous voulez de la portabilité, concevez-la tôt. N’achetez pas NVIDIA, écrivez tout en CUDA, puis « prévoyez » de migrer vers AMD plus tard.
Ce n’est pas un plan ; c’est une histoire pour dormir.

Réalités du datacenter : ECC, limites de puissance, thermiques et modes de défaillance

Dans les datacenters, les GPU tombent en panne comme tout autre composant : thermiques, alimentation, firmware et fatigue du silicium. La différence est que les pannes GPU
ressemblent souvent à des bugs applicatifs. Votre entraînement « a divergé ». Votre rendu présente des artefacts. Vos transcodages ont des corruptions subtiles.
Votre poste gèle mais le nœud répond toujours au ping. Félicitations : vous avez maintenant un problème de détection.

ECC VRAM et corruption de données silencieuse

L’ECC sur la VRAM est ennuyeux. L’ennui est bon. Si vous faites de l’entraînement ML, du calcul scientifique, de la finance ou quoi que ce soit où la justesse compte,
considérez l’ECC comme une exigence. Si votre gamme GPU ne le supporte pas, compensez par des contrôles de validation et de la redondance, et acceptez explicitement le risque.

La gestion de la puissance comme levier de production

Les GPU datacenter peuvent être limités en puissance pour respecter l’enveloppe thermique. Il ne s’agit pas seulement de factures d’électricité ; c’est pour éviter de faire sauter
des disjoncteurs, de surchauffer un châssis et de provoquer des cascades d’étranglement. L’outillage fournisseur diffère, mais le principe est le même : connaissez vos plafonds
de puissance, mesurez les raisons de throttling et définissez des limites délibérément.

Virtualisation et partitionnement de périphérique

NVIDIA a des histoires matures autour du vGPU dans de nombreux environnements. AMD a progressé, mais la disponibilité opérationnelle dépend fortement de votre hyperviseur,
du noyau et du SKU exact. Si vous faites du VDI ou de l’ordonnancement multi-tenant GPU, n’assumez pas « c’est un GPU, il va virtualiser ». Testez toute la pile : licences,
pilotes hôtes, pilotes invités et monitoring.

Blague #1 : Un GPU sans télémétrie, c’est comme une baie de stockage sans SMART — vous pouvez toujours l’exploiter, mais vous apprendrez l’humilité rapidement.

Trois mini-récits du monde de l’entreprise (douleur incluse)

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

Une entreprise d’analytique de taille moyenne a déployé de nouveaux nœuds GPU pour une chaîne de vision par ordinateur. La décision d’achat était
« cartes AMD modernes, bon rapport prix/perf, friendly Linux ». Le cluster était Kubernetes-based, et le modèle mental de l’équipe était simple : « Si le nœud voit le GPU, les pods verront le GPU. »

La mauvaise hypothèse : la découverte des périphériques et l’intégration du runtime conteneur se comportent de la même façon selon les fournisseurs. En pratique,
leur plugin de périphérique existant et leurs images de base étaient orientés CUDA. Des pods ont commencé à échouer avec « no GPU devices found », mais uniquement sur
les nouveaux nœuds. Les planificateurs ont continué à resoumettre. La file d’attente a gonflé. Les SLA ont sauté.

La première réponse fut la perte de temps classique : échange de cartes et réimage des nœuds. Rien n’a changé. Les GPU étaient bons. Les modules noyau étaient chargés.
Mais les bibliothèques en espace utilisateur à l’intérieur des conteneurs n’avaient pas les bons composants runtime, et le plugin GPU du cluster ne savait pas comment annoncer
correctement ces périphériques.

Ils ont corrigé cela en traitant la pile GPU comme faisant partie du graphe de dépendances applicatif. Les nouveaux pools de nœuds avaient des labels explicites,
des images séparées et un job de validation au démarrage confirmant la visibilité du périphérique et un test kernel trivial. La leçon fut inconfortable mais précieuse :
la parité matérielle est dépourvue de sens si les hypothèses runtime sont spécifiques au fournisseur.

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

Une société média effectuait des transcodages vidéo accélérés GPU sur une flotte de machines mixtes. Un ingénieur bien intentionné a remarqué que les GPU étaient « sous-utilisés »
et a proposé un gain rapide : coller plus de jobs de transcodage concurrents par GPU et augmenter les clocks pour stabiliser le débit.

Pendant deux semaines, les dashboards étaient beaux. Le débit a augmenté. Puis les incidents ont commencé : frames corrompues occasionnelles, crashes rares d’encodeur, et machines
qui se figent sous charge maximale. L’équipe a blâmé le codec, puis le runtime conteneur, puis le noyau.

Le vrai problème était le comportement thermique et de puissance sous charge soutenue. L’« optimisation » a supprimé la marge de sécurité et poussé les cartes dans des throttlings
fréquents et des erreurs transitoires. Certains workloads ne plantent pas bruyamment ; ils dégradent la qualité ou plantent de façon non déterministe. Le packing agressif a aussi
amplifié la fragmentation VRAM et la pression mémoire.

Le rollback fut ennuyeux : limiter les jobs concurrents, appliquer des limites de puissance et ordonnancer avec un contrôle d’admission sensible à la température.
La conclusion du postmortem : le GPU n’était pas sous-utilisé ; il réservait une marge de stabilité. Vous pouvez dépenser cette marge, mais vous devez vous attendre à payer des intérêts.

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

Un labo de recherche exécutait des entraînements nocturnes sur un petit cluster. Ils n’étaient pas fancy, mais disciplinés : versions de pilote épinglées, versions de noyau épinglées,
et une fenêtre de maintenance mensuelle où ils mettaient à jour un nœud canari d’abord.

Un mois, une mise à jour système de routine a introduit une régression de pilote GPU qui ne se manifestait que sous un pattern particulier de communication collective.
Le nœud canari l’a détectée en quelques heures. Les logs des jobs étaient étranges mais cohérents : timeouts NCCL intermittents sous charge.

Parce que l’équipe avait un plan de rollback écrit, ils ont rétabli le canari à la combinaison pilote/noyau précédente et ont laissé le reste de la flotte intact.
Ils ont ouvert un ticket chez le fournisseur et attendu un pilote patché.

Pas d’héroïsme. Pas d’alerte générale. Pas « trois jours perdus d’entraînement ». La pratique ennuyeuse — canariser les mises à jour de la pile GPU — a fait toute la différence
entre un mardi calme et une semaine de chaos.

Tâches pratiques : commandes, sorties et quoi décider ensuite

Si vous exploitez des GPU, vous devez avoir une mémoire musculaire de vérifications qui vous disent : « Le GPU est-il visible ? Est-il sain ? Se throttle-t-il ? La pile de pilotes est-elle cohérente ?
Le goulot est-il le calcul, la mémoire, le CPU, l’I/O ou le réseau ? »

Ci‑dessous des tâches pragmatiques que vous pouvez exécuter sur Linux. Elles sont écrites pour la réalité de production : elles incluent ce que signifie la sortie et la décision suivante.

Tâche 1 : Identifier le GPU et le pilote noyau en cours d’utilisation

cr0x@server:~$ lspci -nnk | grep -A3 -E "VGA|3D|Display"
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GA102 [GeForce RTX 3090] [10de:2204] (rev a1)
        Subsystem: Micro-Star International Co., Ltd. [MSI] Device [1462:3895]
        Kernel driver in use: nvidia
        Kernel modules: nvidiafb, nouveau, nvidia_drm, nvidia

Ce que cela signifie : Le noyau utilise nvidia, mais nouveau est aussi présent comme module possible.

Décision : Si vous voyez des modules conflictuels (par ex. nouveau chargé), mettez-le sur liste noire et reconstruisez initramfs ; sinon vous risquez des problèmes de modesetting instables ou des soucis de compute sans affichage.

Tâche 2 : Confirmer la santé du pilote NVIDIA et la télémétrie de base

cr0x@server:~$ nvidia-smi
Tue Jan 13 11:20:10 2026
+-----------------------------------------------------------------------------------------+
| NVIDIA-SMI 550.54.14              Driver Version: 550.54.14      CUDA Version: 12.4     |
|-----------------------------------------+------------------------+----------------------|
| GPU  Name                 Persistence-M | Bus-Id          Disp.A | Volatile Uncorr. ECC |
| Fan  Temp   Perf          Pwr:Usage/Cap |           Memory-Usage | GPU-Util  Compute M. |
|                                         |                        |               MIG M. |
|=========================================+========================+======================|
|   0  NVIDIA A10                    Off  | 00000000:01:00.0  Off  |                  0   |
|  35%   58C    P2              118W / 150W|   6120MiB / 24564MiB   |     72%      Default |
+-----------------------------------------+------------------------+----------------------+

Ce que cela signifie : Le pilote est chargé, le GPU est utilisé, la puissance est en dessous du plafond, ECC affiche 0 erreurs non corrigées.

Décision : Si nvidia-smi se bloque ou renvoie des erreurs, arrêtez et corrigez les problèmes de pilote/module avant de déboguer les applications. Si les erreurs ECC augmentent, planifiez un RMA ou isolez la carte.

Tâche 3 : Vérifier la présence du GPU AMD et l’état du pilote

cr0x@server:~$ sudo lshw -c display -short
H/W path           Device     Class          Description
========================================================
/0/100/1.0         card0      display        Advanced Micro Devices, Inc. [AMD/ATI] Navi 31 [Radeon RX 7900 XTX]
/0/100/1.0/0       /dev/fb0   display        AMDGPU framebuffer

Ce que cela signifie : Le système voit un GPU AMD/ATI et utilise le framebuffer AMDGPU.

Décision : Si cela affiche vesa ou aucun framebuffer, vous avez probablement un problème de pilote/initramfs ou un décalage de firmware.

Tâche 4 : Vérifier les logs noyau pour resets GPU, hangs ou erreurs firmware

cr0x@server:~$ sudo journalctl -k -b | egrep -i "amdgpu|nvidia|gpu|xid|ring|timeout" | tail -n 20
Jan 13 11:02:41 server kernel: NVRM: Xid (PCI:0000:01:00): 79, pid=24118, GPU has fallen off the bus.
Jan 13 11:02:41 server kernel: pcieport 0000:00:01.0: AER: Corrected error received: 0000:00:01.0
Jan 13 11:02:42 server kernel: nvidia 0000:01:00.0: AER: can't recover (no error_detected callback)

Ce que cela signifie : « Fallen off the bus » plus AER PCIe indique une instabilité au niveau matériel (alimentation, PCIe, riser, surchauffe) plutôt qu’un bug applicatif.

Décision : Changez d’emplacement la carte, vérifiez les câbles d’alimentation, réduisez la vitesse PCIe dans le BIOS et inspectez les aspects thermiques avant de réécrire du code.

Tâche 5 : Vérifier que les nœuds de périphérique existent (point de défaillance courant en conteneur)

cr0x@server:~$ ls -l /dev/nvidia* 2>/dev/null || echo "no nvidia device nodes"
crw-rw-rw- 1 root root 195,   0 Jan 13 11:19 /dev/nvidia0
crw-rw-rw- 1 root root 195, 255 Jan 13 11:19 /dev/nvidiactl
crw-rw-rw- 1 root root 195, 254 Jan 13 11:19 /dev/nvidia-modeset

Ce que cela signifie : Les nœuds de périphérique existent ; l’espace utilisateur peut parler au pilote.

Décision : Si manquants, votre pilote n’est pas chargé ou les règles udev ne se sont pas exécutées. Corrigez la création des nœuds avant de toucher aux plugins Kubernetes.

Tâche 6 : Vérifier les nœuds de périphérique AMD et la configuration DRM

cr0x@server:~$ ls -l /dev/dri
total 0
drwxr-xr-x 2 root root        100 Jan 13 10:58 by-path
crw-rw---- 1 root video  226,   0 Jan 13 10:58 card0
crw-rw---- 1 root render 226, 128 Jan 13 10:58 renderD128

Ce que cela signifie : Les nœuds DRM existent. Les frameworks de calcul requièrent souvent l’accès à renderD128.

Décision : Dans les conteneurs, assurez-vous que l’utilisateur du process appartient au bon groupe ou que vous passez le périphérique ; sinon vous verrez des « permission denied » qui se déguisent en « no GPU ».

Tâche 7 : Confirmer quel pilote OpenGL/Vulkan vous utilisez réellement (Mesa vs propriétaire)

cr0x@server:~$ glxinfo -B | egrep "OpenGL vendor|OpenGL renderer|OpenGL version"
OpenGL vendor string: AMD
OpenGL renderer string: AMD Radeon RX 7900 XTX (radeonsi, navi31, LLVM 17.0.6, DRM 3.54, 6.6.12)
OpenGL version string: 4.6 (Core Profile) Mesa 24.0.3

Ce que cela signifie : Vous êtes sur Mesa/radeonsi, pas sur un renderer de repli.

Décision : Si le renderer affiche « llvmpipe », vous êtes en rendu logiciel. Arrêtez de benchmarker des jeux et corrigez votre pile d’affichage.

Tâche 8 : Vérifier la température GPU et les indices de throttling (sensors générique)

cr0x@server:~$ sensors | egrep -i "edge|junction|gpu|amdgpu" | head
amdgpu-pci-0100
edge:         +62.0°C
junction:     +88.0°C

Ce que cela signifie : La température de jonction est élevée ; une charge soutenue peut provoquer du throttling ou des erreurs si le flux d’air est médiocre.

Décision : Si la jonction est proche des limites constructeur sous charge normale, améliorez le flux d’air ou réduisez le cap de puissance avant de courir après des « plantages aléatoires ».

Tâche 9 : Vérifier l’utilisation GPU et l’usage par processus (NVIDIA)

cr0x@server:~$ nvidia-smi pmon -c 1
# gpu        pid  type    sm   mem   enc   dec   command
    0      24118     C    72    41     0     0   python
    0      10211     G     3     1     0     0   Xorg

Ce que cela signifie : Un processus de calcul domine ; Xorg est minimal.

Décision : Si vous voyez de nombreux petits processus utilisant peu de SM mais beaucoup de mémoire, vous êtes peut-être limité par l’overhead ; consolidez les batches ou augmentez le travail par lancement.

Tâche 10 : Confirmer la visibilité du toolkit CUDA dans votre runtime

cr0x@server:~$ nvcc --version
nvcc: NVIDIA (R) Cuda compiler driver
Copyright (c) 2005-2025 NVIDIA Corporation
Cuda compilation tools, release 12.4, V12.4.131

Ce que cela signifie : Le compilateur CUDA est installé dans cet environnement.

Décision : Si les apps échouent avec « CUDA not found » mais que nvidia-smi fonctionne, votre conteneur ou venv manque de bibliothèques utilisateur ; corrigez la construction de l’image, pas le pilote hôte.

Tâche 11 : Vérifier la visibilité ROCm (calcul AMD)

cr0x@server:~$ /opt/rocm/bin/rocminfo | head -n 12
ROCk module is loaded
=====================
HSA Agents
==========
*******
Agent 1
  Name:                    gfx1100
  Uuid:                    GPU-XX
  Marketing Name:          AMD Radeon RX 7900 XTX

Ce que cela signifie : La pile ROCm voit le GPU comme un agent HSA.

Décision : Si ROCm ne voit pas le GPU alors que l’affichage fonctionne, vous êtes probablement sur un combo matériel/driver ROCm non supporté. Arrêtez et alignez versions ou matériel.

Tâche 12 : Repérer les goulots CPU qui se font passer pour un « GPU lent »

cr0x@server:~$ mpstat -P ALL 1 3
Linux 6.6.12 (server)  01/13/2026  _x86_64_  (64 CPU)

11:21:01 AM  CPU   %usr %nice %sys %iowait %irq %soft %steal %idle
11:21:02 AM  all   92.10 0.00 3.22   0.04 0.00 0.30  0.00  4.34
11:21:02 AM    7   99.70 0.00 0.30   0.00 0.00 0.00  0.00  0.00

Ce que cela signifie : Les CPUs sont saturés ; un cœur est à fond. Le GPU peut attendre la préparation d’entrées, la décompression, l’overhead Python ou les threads du dataloader.

Décision : Augmentez le parallélisme, pinnez les threads, déplacez le prétraitement sur le GPU ou réécrivez la boucle chaude. N’achetez pas un nouveau GPU pour résoudre un goulot CPU mono-coeur.

Tâche 13 : Vérifier la largeur/vitesse du lien PCIe (limiteur caché classique)

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

Ce que cela signifie : La carte a négocié une vitesse et une largeur inférieures à ses capacités. Cela peut étrangler des workloads lourds en données.

Décision : Reseat la GPU, vérifiez les paramètres BIOS, vérifiez le riser/câble et confirmez le câblage du slot. Si c’est intentionnel (lignes partagées), planifiez en conséquence.

Tâche 14 : Vérifier que l’I/O n’asphyxie pas le GPU (courant pour l’entraînement)

cr0x@server:~$ iostat -xz 1 3
Device            r/s     w/s   rkB/s   wkB/s  await  %util
nvme0n1         220.0    15.0  54000.0  8000.0  18.5  92.0

Ce que cela signifie : Le NVMe est à 92% d’utilisation avec un await élevé ; votre dataloader peut être lié par l’I/O et nourrir le GPU en retard.

Décision : Cachez les datasets localement, augmentez le read-ahead, utilisez un stockage plus rapide ou pré-shardez/comprimez différemment. Votre problème d’« utilisation GPU » pourrait être un problème disque.

Tâche 15 : Vérifier les goulots réseau pour l’entraînement multi-nœuds

cr0x@server:~$ sar -n DEV 1 3 | egrep "IFACE|eno1"
11:22:11 AM IFACE   rxpck/s   txpck/s    rxkB/s    txkB/s   rxcmp/s   txcmp/s  rxmcst/s
11:22:12 AM eno1    8200.00   9100.00  980000.00 1040000.00   0.00      0.00     0.00

Ce que cela signifie : Vous êtes près du débit maximal (chiffres autour de 10GbE en KB/s). L’all-reduce peut saturer cela et bloquer les GPUs.

Décision : Montez la fabric, activez RDMA si approprié, ou ajustez tailles de batch/accumulation de gradients pour réduire la fréquence de synchronisation.

Tâche 16 : Confirmer que le runtime conteneur voit le GPU (exemple NVIDIA)

cr0x@server:~$ docker run --rm --gpus all nvidia/cuda:12.4.1-base-ubuntu22.04 nvidia-smi
Tue Jan 13 11:23:19 2026
+-----------------------------------------------------------------------------------------+
| NVIDIA-SMI 550.54.14              Driver Version: 550.54.14      CUDA Version: 12.4     |
+-----------------------------------------------------------------------------------------+

Ce que cela signifie : L’intégration pilote hôte / runtime conteneur fonctionne.

Décision : Si cela échoue, corrigez nvidia-container-toolkit et la configuration du runtime avant d’accuser votre framework ML.

Blague #2 : Choisir entre AMD et NVIDIA, c’est comme choisir entre deux bases de données — quelqu’un aura tort, et ce pourrait être vous.

Méthode de diagnostic rapide : trouver le goulot vite

Quand les performances chutent ou que des jobs échouent, vous n’avez pas le temps pour la philosophie. Vous avez besoin d’un ordre de triage répétable qui coupe le bruit.
Voici l’ordre qui fonctionne dans de vraies flottes.

Première étape : « Le GPU est-il même sain et visible ? »

• Visibilité matérielle : lspci -nnk montre le périphérique et le pilote noyau prévu.
• Télémétrie : nvidia-smi fonctionne (NVIDIA) ou rocminfo fonctionne (ROCm) et n’affiche pas d’erreur.
• Logs noyau : scannez journalctl -k -b pour resets, Xid, timeouts de ring, échecs de chargement firmware.

Condition d’arrêt : Si vous voyez du bruit PCIe/AER, « fallen off the bus », timeouts ring ou spam firmware — traitez d’abord ça comme un problème plateforme.

Deuxième étape : « Le GPU se throttle-t-il ou est-il affamé ? »

• Thermiques : sensors ou télémétrie fournisseur. Surveillez les températures de jonction sous charge soutenue.
• Caps de puissance : comparez usage/cap (NVIDIA : nvidia-smi). Recherchez des P-states persistants coincés bas.
• Pipeline d’alimentation : vérifiez CPU (mpstat), disque (iostat) et réseau (sar -n DEV).

Condition d’arrêt : Si le CPU est saturé ou le disque à 90% d’utilisation, corrigez cela. Les GPUs ne fonctionnent pas avec de l’optimisme.

Troisième étape : « La pile logicielle est-elle décalée ? »

• Alignement des versions : version du pilote vs version du toolkit (CUDA/ROCm) et attentes du framework.
• Conteneurs : validez avec un test minimal connu-good en container (ex. nvidia/cuda).
• Permissions : nœuds de périphérique et appartenance aux groupes (/dev/nvidia*, /dev/dri/renderD*).

Condition d’arrêt : Si le conteneur minimal échoue, votre débogage applicatif est prématuré.

Quatrième étape : « Est-ce un décalage workload ? »

• Noyaux liés à la mémoire vs noyaux liés au calcul : si la bande passante VRAM limite, acheter plus de SMs n’aidera pas.
• Taille de batchs petite : le GPU passe du temps à lancer des kernels plutôt qu’à faire du travail.
• Overhead de synchronisation : mise à l’échelle multi-GPU limitée par l’interconnect ou le réseau.

Décision : Optimisez la forme du workload (batching, pipeline de données, précision, ops fusionnées) avant de changer de fournisseur par frustration.

Erreurs courantes : symptômes → cause racine → correction

1) « Le GPU est installé, mais mon conteneur dit qu’il n’y a pas de GPU »

Symptômes : Les logs d’app affichent « CUDA device not found » ou le compte de périphériques ROCm est 0 à l’intérieur des conteneurs.

Cause racine : Intégration du runtime conteneur manquante (NVIDIA toolkit), mauvais device plugin, ou nœuds de périphérique non montés/permissionnés.

Correction : Validez avec un conteneur minimal (docker run --gpus all ... nvidia-smi), puis alignez la configuration du runtime et du plugin de périphérique sur le fournisseur.

2) « Les performances ont empiré après une mise à jour du noyau »

Symptômes : Même workload, moins d’utilisation GPU, nouveaux saccades/gel, glitches de compositeur occasionnels.

Cause racine : Mismatch noyau/pilote, régression dans la pile DRM, ou problèmes de build de module propriétaire après la mise à jour.

Correction : Epingler noyau+pilote comme unité, canariser les upgrades et garder une voie de rollback. Pour les postes, validez explicitement le comportement Wayland/Xorg.

3) « L’entraînement est plus lent mais le GPU affiche 30% d’utilisation »

Symptômes : Faible utilisation GPU, CPU élevé, disque occupé ou réseau saturé.

Cause racine : Goulot du pipeline de données : décodage, augmentation, filesystem ou lectures de datasets sharded.

Correction : Profilez CPU et I/O ; mettez les datasets en cache sur NVMe local rapide ; augmentez le nombre de workers du loader ; prétraitez hors ligne ; envisagez le décodage accéléré par GPU.

4) « Freezes complets aléatoires sous charge »

Symptômes : Le nœud cesse de répondre, le GPU disparaît, les logs noyau montrent Xid ou timeouts de ring, parfois des événements AER.

Cause racine : Problèmes d’alimentation, emballement thermique, risers marginaux, négociation PCIe instable ou bugs firmware exposés par une charge soutenue.

Correction : Réduisez le cap de puissance, améliorez le flux d’air, reseatez les cartes, remplacez les risers, mettez à jour BIOS/firmware, testez en gen PCIe inférieur et isolez les GPU suspects.

5) « Nous avons optimisé la concurrence et maintenant la qualité de sortie est incohérente »

Symptômes : Artefacts vidéo, crashes rares d’encodeur, échecs nondéterministes, NaNs occasionnels.

Cause racine : Throttling thermique ou pression mémoire amplifiant des bugs en bordure ; fragmentation VRAM ; trop de contextes.

Correction : Réduisez la concurrence, imposez des limites puissance/thermiques, adoptez un contrôle d’admission et validez la correction par des contrôles d’échantillonnage.

6) « Wayland multi-écran est hanté »

Symptômes : Scintillement, bizarreries VRR, applications qui saccadent sur un écran, écrans noirs aléatoires au réveil.

Cause racine : Interactions sync pilote/compositeur explicites, taux de rafraîchissement mixtes ou problèmes de routage multi-GPU.

Correction : Testez sur une paire driver/compositeur stable connue ; envisagez Xorg pour des postes critiques ; standardisez les configs moniteurs ; évitez de mélanger panneaux VRR et non-VRR dans les déploiements en flotte.

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

Checklist A : Choisir AMD vs NVIDIA pour un nouveau déploiement

1. Définissez « l’écosystème par défaut » du workload. Si c’est du ML avec des frameworks mainstream et des outils tiers, partez sur une hypothèse CUDA-first sauf preuve du contraire.
2. Décidez de votre posture de mise à jour. Si vous devez suivre les noyaux récents (postes développeurs), l’alignement en amont est un avantage sérieux.
3. Listez les éléments non négociables : ECC ? virtualisation ? SR-IOV/vGPU ? codecs spécifiques ? exigences de la pile d’affichage ?
4. Choisissez une matrice supportée, pas un produit. Choisissez (SKU GPU, version pilote, version noyau, version distro, image conteneur) comme une unité testée.
5. Exécutez un burn-in. 24–72 heures de charge soutenue plus cycles suspend/reprise (si poste), et tests multi-GPU (si cluster).
6. Planifiez l’observabilité. Vous avez besoin de télémétrie GPU par nœud et d’alertes pour températures, erreurs ECC, throttling et resets de périphérique.

Checklist B : Upgrades sûrs de la pile GPU (pilotes/toolkits)

1. Inventoriez et épinglez les versions actuelles (pilote, toolkit, noyau, firmware).
2. Mettez à jour un nœud canari en premier. Exécutez des workloads représentatifs, pas des benchmarks synthétiques.
3. Vérifiez les logs noyau pour nouveaux avertissements après burn-in.
4. Validez l’accès GPU en conteneur avec une image minimale connue-good.
5. Puis roulez sur un petit pourcentage, puis sur la flotte.
6. Gardez des artefacts de rollback prêts : paquets précédents, entrée noyau et tags d’images conteneur.

Checklist C : Quand vous suspectez que le GPU est « lent »

1. Confirmez la vitesse/largeur du lien (négociation PCIe).
2. Confirmez le cap de puissance et le comportement des P-states.
3. Confirmez les signaux thermiques et de throttling.
4. Mesurez la saturation CPU et les hotspots par cœur.
5. Mesurez la saturation disque et réseau.
6. Ce n’est qu’ensuite que vous profilez les kernels GPU et le comportement mémoire.

FAQ

1) « ATI vs NVIDIA » est-ce encore une vraie chose si ATI est devenu AMD ?

Oui, parce que le nom de la marque a changé mais la tension fondamentale est restée : la lignée GPU d’AMD versus celle de NVIDIA. Les gens disent encore
« ATI » comme les ops disent « ethernet » pour parler du réseau. C’est imprécis, mais la rivalité est réelle.

2) Pour des postes Linux, lequel est le moins pénible ?

Si vous voulez moins de surprises lors des changements de noyau et de compositeur, le modèle pilote upstream d’AMD est souvent plus fluide.
NVIDIA peut être parfaitement acceptable, mais traitez les mises à jour de pilote comme des événements de changement, pas comme du bruit de fond.

3) Pour le machine learning aujourd’hui, AMD peut-il remplacer NVIDIA ?

Parfois, oui — surtout avec ROCm sur du matériel supporté et des frameworks bien testés. Mais CUDA reste l’hypothèse par défaut dans de nombreux outils et binaires préconstruits.
Si vous avez besoin d’une compatibilité maximale avec un minimum d’intégration, NVIDIA reste le choix pragmatique.

4) Pourquoi CUDA « gagne » même quand le matériel concurrent est solide ?

Parce que les choix par défaut se cumulent. Plus de bibliothèques publient des wheels CUDA-first, plus d’équipes standardisent sur CUDA, plus il y a d’outillage et de savoir-faire,
et plus cela devient l’option sûre pour respecter des délais.

5) Les pilotes propriétaires signifient-ils automatiquement « instable » ?

Non. Les stacks propriétaires peuvent être extrêmement stables — parfois plus stables que des composants open qui évoluent vite. Le risque opérationnel est le couplage :
quand votre noyau, compositeur, politique Secure Boot et le rythme des releases divergent, vous effectuez plus d’intégration vous-même.

6) L’ECC VRAM vaut-il le coût ?

Si la justesse compte, oui. La corruption silencieuse est le type de panne qui traverse les dashboards et réapparaît comme « le modèle s’est comporté bizarrement »
ou « le rendu a des artefacts ». L’ECC ne résout pas tout, mais réduit fortement le risque.

7) Quelle est la raison la plus courante pour laquelle les GPU sous-performent en production ?

La famine : prétraitement CPU, stockage lent ou synchronisation réseau. Le GPU devient le composant visible, donc il est blâmé. Mesurez toute la chaîne avant de changer de matériel.

8) Devons-nous standardiser sur un seul fournisseur dans l’entreprise ?

Standardisez par plateforme quand c’est possible. Un fournisseur unique pour les clusters ML peut réduire la variance d’outillage. Un fournisseur différent pour les postes Linux
peut réduire la douleur de la pile d’affichage. L’objectif est moins de matrices, pas la pureté idéologique.

9) Quand devrions-nous choisir intentionnellement l’option « non par défaut » ?

Quand vous pouvez le prouver sur votre workload exact et que vous êtes prêts à prendre en charge l’intégration. Si votre équipe maîtrise ROCm et que vos modèles y tournent bien,
AMD peut être un gain stratégique coût/performance. Si vous avez besoin d’une compatibilité tierce maximale, choisissez NVIDIA et investissez dans l’observabilité plutôt que dans le portage.

Prochaines étapes que vous pouvez réellement faire cette semaine

La rivalité ATI/AMD vs NVIDIA ne s’arrêtera pas parce qu’elle est alimentée par des vrais compromis : intégration en amont contre enfermement d’écosystème,
ouverture contre polish, compatibilité contre contrôle. Vous ne résolvez pas cela avec un graphique de benchmarks. Vous le résolvez avec une intention opérationnelle.

1. Écrivez votre matrice supportée (SKU GPU, pilotes, noyau, distro, images conteneur). Si ce n’est pas écrit, ce n’est pas supporté.
2. Construisez un processus canari pour les upgrades de la pile GPU. Un nœud d’abord. Toujours.
3. Ajoutez de la télémétrie et des alertes pour températures, throttling, resets et erreurs ECC. Si vous ne le voyez pas, vous ne pouvez pas en être responsable.
4. Exécutez les tâches pratiques ci-dessus sur un nœud sain et un nœud « problématique » et differez les sorties. La plupart des mystères sont des différences.
5. Choisissez votre fournisseur selon vos contraintes : gravité CUDA pour le ML, alignement upstream pour les flottes Linux, et fonctionnalités matérielles (ECC/virtualisation) pour les datacenters.

Si vous ne retenez rien d’autre : arrêtez de traiter les GPU comme des accélérateurs interchangeables. Traitez-les comme une plateforme. Votre futur vous — celui qui tient le pager —
vous en sera péniblement reconnaissant.