Si vous exploitez du ML en production, vous l’avez ressenti : le courriel des achats qui dit « délai de livraison des GPU encore repoussé »,
l’équipe modèle qui insiste « ça doit être CUDA », et la personne des finances qui demande pourquoi vos « serveurs commodité »
contiennent des composants qui se comportent comme des métaux rares.
La question n’est pas de savoir si CUDA est bon (il l’est). La question est de savoir si l’industrie peut se permettre qu’un
seul empilement propriétaire soit le système d’exploitation par défaut du calcul accéléré. « Anti‑CUDA » sonne comme un
mème. Ce n’en est pas un. C’est une posture de gestion des risques qui se transforme lentement en travail d’ingénierie.
Ce que « anti‑CUDA » signifie réellement (et ce que ça ne signifie pas)
« Anti‑CUDA » est une expression floue. En réunions d’entreprise elle est utilisée pour trois choses différentes,
et les confondre est la façon dont vous livrez accidentellement une réécriture plutôt qu’une stratégie.
Ça signifie réduire le risque opérationnel lié à un unique fournisseur
Si votre flotte d’entraînement, flotte d’inférence, pilotes, images de base de conteneur, outils de profilage et la mémoire musculaire des développeurs
supposent tous le runtime d’un seul fournisseur — alors vous n’« utilisez pas des GPU ». Vous exécutez une plateforme verticalement intégrée
que vous ne contrôlez pas. Cela peut aller. Jusqu’au moment où ça ne va plus.
Ça signifie exiger la portabilité là où elle est réaliste
La portabilité n’est pas binaire. Certaines couches peuvent être portables aujourd’hui (formats de modèle, frameworks de haut niveau, patterns de construction de conteneurs),
tandis que d’autres resteront spécifiques au fournisseur pendant des années (certaines bibliothèques noyau, certains schémas de communications, des profileurs niches).
Le travail « anti‑CUDA » consiste essentiellement à déplacer la frontière du « non‑portable » vers une zone plus petite et bien gérée.
Ça ne signifie pas remplacer CUDA par des intentions vagues
Si vous avez déjà essayé d’imposer une « abstraction unifiée » dans une base de code où le budget de performance est réel,
vous connaissez la fin : tout le monde promet la portabilité, puis le premier gros client veut du débit,
et soudain il y a un chemin rapide spécifique au fournisseur… pour tout.
Blague n°1 : Une « stratégie anti‑CUDA » sans benchmarks, c’est comme un exercice d’évacuation où tout le monde convient que l’escalier est optionnel.
Pourquoi CUDA a gagné : incitations, ergonomie et la mathématique impitoyable des outils
CUDA n’a pas gagné parce que NVIDIA a écrit un joli PDF. Il a gagné parce que la pile était cohérente, rapide et agressivement
industrialisée de bout en bout : compilateur, bibliothèques, profilage, pilotes et un modèle mental cohérent pour les développeurs.
En termes d’exploitation : moins d’inconnues imprévues.
Le vrai différenciateur : bibliothèques et performances prévisibles
L’histoire CUDA n’est pas « écrire des kernels ». La plupart des équipes de production n’écrivent pas de kernels personnalisés sauf nécessité.
L’histoire, ce sont cuBLAS, cuDNN, NCCL, TensorRT, et le fait que le « chemin par défaut » est généralement suffisant et parfois excellent.
Votre plateforme MLOps moyenne est un graphe de dépendances avec des opinions ; CUDA est une base opinionnée.
La gravité des frameworks
PyTorch, TensorFlow, JAX, XGBoost, LightGBM, serveurs d’inférence Triton, extensions C++ personnalisées — ces écosystèmes
se sont accumulés autour de CUDA comme chemin de moindre résistance. Une fois que vos artefacts modèle, images CI et « nœuds dorés »
dépendent de CUDA, le coût de changement devient organisationnel plutôt que technique. Ce sont les coûts les plus difficiles à payer.
Les écosystèmes fermés gagnent quand ils enlèvent des points de décision
Les systèmes ouverts « gagnent » souvent sur le papier et perdent dans les incidents. L’écosystème fermé offre moins de choix,
ce que la production réclame fréquemment à 3 heures du matin.
Écosystèmes ouverts vs fermés : où se cache vraiment le verrouillage
On parle de verrouillage comme si c’était seulement une question d’APIs. Dans la vie réelle, le verrouillage se trouve là où
il n’apparaît pas sur les diagrammes d’architecture : versions de pilotes, toolchains de compilateur, couches de conteneur, modules noyau,
et la forme exacte des falaises de performance.
Cinq couches d’« écosystème », et lesquelles font mal
- Couche matériel : architecture GPU, taille mémoire, interconnexions (PCIe, NVLink), support SR‑IOV/MIG.
- Couche noyau/pilote : comportement du pilote + firmware, compatibilité des modules noyau, douleur des reconstructions DKMS.
- Couche runtime : runtime CUDA vs ROCm/HIP, découverte de périphériques, sémantiques de stream, allocateurs mémoire.
- Couche bibliothèques : kernels GEMM/conv/attention, comms (équivalents NCCL), toolchains de quantification.
- Couche framework/application : PyTorch/XLA/JAX, ops personnalisés, moteurs d’inférence, hooks de monitoring.
« Ouvert » aide surtout à la couche framework/application et parfois à la couche runtime. La douleur la plus profonde se situe souvent
dans les pilotes et les bibliothèques, car c’est là que la performance se crée.
Ce que « ouvert » peut raisonnablement vous apporter
Un écosystème ouvert crédible vous offre :
- Plusieurs fournisseurs en concurrence sur la performance et l’approvisionnement.
- Des échappatoires claires lorsque les prix ou la disponibilité deviennent défavorables.
- Plus d’yeux sur la correction des toolchains (parfois), et plus d’options d’intégration aval.
Ce que cela ne garantit pas, c’est que votre modèle s’exécute aussi vite partout. La portabilité est facile.
La portabilité de la performance est la partie coûteuse.
Faits & contexte historique qui comptent en boardrooms
Vous ne pouvez pas prendre une décision lucide sur « anti‑CUDA » sans vous souvenir d’où nous venons. Quelques faits concrets
qui reviennent dans les discussions d’achats et de feuille de route :
- CUDA a été lancé en 2006 comme plateforme de calcul général pour GPU NVIDIA ; il est assez ancien pour avoir son folklore opérationnel.
- OpenCL 1.0 est arrivé en 2008 avec la promesse de portabilité, mais les fournisseurs et la qualité des outils ont rapidement divergé.
- cuDNN a débuts en 2014 et a aidé à standardiser les primitives du deep learning ; ce sont les bibliothèques, pas les compilateurs, qui ont dicté le rythme pour la plupart des équipes.
- NCCL est devenu le choix par défaut pour l’entraînement multi‑GPU dans de nombreuses piles parce que la collectivité des communications « ça marche » bat la portabilité.
- TensorRT a changé la donne pour l’inférence en regroupant optimisation de graphe + sélection de kernels + quantification dans un flux de travail pratique.
- La trajectoire de ROCm a été inégale — des périodes d’amélioration rapide ponctuées de frictions de compatibilité et de packaging.
- Metal Performance Shaders d’Apple a montré une autre leçon : les écosystèmes fermés peuvent être extrêmement productifs si la plateforme est cohérente.
- SYCL a mûri comme modèle single‑source en C++ capable de cibler plusieurs backends ; c’est sérieux, mais « sérieux » n’est pas synonyme de « dominant ».
- Les cycles de rareté GPU ont changé les comportements : quand l’offre est tendue, la portabilité cesse d’être académique et devient un plan de continuité d’activité.
Qui pousse « anti‑CUDA », et pourquoi maintenant
La poussée n’est pas un mouvement unique. C’est un empilement d’incitations.
Les fournisseurs cloud veulent du levier
Si vous vendez du calcul, vous ne voulez pas que votre ligne de produit soit « ce que fournit un fournisseur, quand il le fournit ».
Vous investissez donc dans des alternatives, des couches de compatibilité et des accélérateurs différenciés. Pas parce que vous détestez CUDA,
mais parce que marge et chaîne d’approvisionnement sont une physique réelle.
Les entreprises veulent de l’optionnalité sans réécriture
L’informatique d’entreprise ne veut pas qu’on lui dise « nous sommes une boutique CUDA » de la même façon qu’elle n’aime pas « nous sommes un seul fournisseur SAN ».
Ce n’est pas idéologique. Il s’agit de pouvoir de négociation, de planification du cycle de vie, et de réduire le rayon d’impact des incidents propres à un fournisseur.
Les chercheurs veulent moins de murs
Le monde académique et les communautés open source tendent à pousser pour des standards ouverts et des runtimes portables parce que cela élargit la participation.
Mais la partie difficile reste la qualité des kernels. Les standards ne produisent pas automatiquement du code rapide.
Le déclencheur économique : utilisation rencontrant rareté
Quand les GPU étaient « agréables à avoir », on pouvait tolérer de l’inefficacité. Quand votre facture GPU ressemble à une seconde masse salariale,
vous commencez à tout mesurer : temps de kernel, copies hôte‑dispositif, recouvrements de comms, et le coût d’attendre un matériel spécifique.
Ce qui casse réellement dans les piles GPU en production
Au laboratoire, la « portabilité » est surtout une question de compilation. En production, c’est une question de modes de défaillance.
Voici les points chauds que je vois répéter quand des équipes tentent de diversifier hors de CUDA ou simplement moderniser leur pile.
Incompatibilités pilote/runtime
La plupart des « incidents GPU » ne sont pas des pannes matérielles. Ce sont des matrices de versions aux arêtes vives :
mises à jour du noyau, updates du pilote, dérive des images de base de conteneur, ou une reconstruction silencieuse d’une extension CUDA qui cible le mauvais ABI.
Falaises de performance qui ressemblent à des bugs
Vous passez d’un backend à un autre, et soudain un modèle est 3× plus lent. Rien ne plante. Tout « fonctionne ».
C’est la pire catégorie : ça passe les tests fonctionnels et ça échoue sur le budget.
Collectives et surprises de topologie
L’entraînement multi‑GPU est souvent limité par la communication, pas par les maths. La topologie d’interconnexion (racines PCIe, NUMA,
maillages NVLink) et le comportement de la bibliothèque de collectives dictent l’échelle. Changez de fournisseur et vous changez l’histoire des comms.
Lacunes d’observabilité
CUDA dispose de patterns de profilage et de télémétrie matures que de nombreuses équipes ops ont internalisés. Les piles alternatives peuvent avoir
différents compteurs, différents outils, et différents « pièges » sur la signification réelle d’un métrique.
Une citation à agrafer sur chaque plan de migration : L’espoir n’est pas une stratégie.
— Général Gordon R. Sullivan
Trois mini‑histoires d’entreprise issues du terrain
Mini‑histoire 1 : L’incident causé par une mauvaise hypothèse
Une société SaaS de taille moyenne a décidé de « rendre l’inférence portable ». Le plan semblait raisonnable : standardiser sur des conteneurs,
utiliser PyTorch avec un lockfile de dépendances propre, et éviter les extensions CUDA personnalisées. Ils ont construit un second pool d’inférence
utilisant des accélérateurs non‑NVIDIA pour le coût et la disponibilité.
La mauvaise hypothèse était subtile : ils ont supposé que « pas d’extensions personnalisées » signifiait « pas de binaires spécifiques au fournisseur ».
Mais une dépendance a importé une bibliothèque de performance qui livrait des wheels précompilés ciblant un runtime GPU spécifique.
Le CI a passé parce que le CI tournait sur CPU. Le staging a passé parce que le staging avait des nœuds NVIDIA. La production sur le nouveau pool ne passait pas.
Le symptôme était moche : les pods démarraient puis bouclaient en crash avec des erreurs du linker dynamique. Les SRE l’ont traité d’abord comme un problème Kubernetes —
pulls d’images, taints de nœud, contextes de sécurité. La vraie défaillance se trouvait dans le système de fichiers du conteneur : le wheel contenait
des binaires attendant des bibliothèques CUDA absentes.
La correction n’a pas été héroïque. Ils ont reconstruit les images avec des extras explicites par backend et ont fait du « type de backend » un axe de build de première classe.
Plus important, ils ont ajouté un job de prévalidation qui importait la pile modèle et exécutait un warmup d’un batch sur chaque classe de nœud.
La leçon durable : la portabilité n’est pas « ne pas écrire CUDA ». La portabilité, c’est « prouver que votre graphe de dépendances ne fait pas entrer CUDA par la porte de service ».
Mini‑histoire 2 : L’optimisation qui s’est retournée contre eux
Une grande équipe plateforme ML d’entreprise poursuivait un objectif clair : réduire la latence d’inférence et couper les coûts GPU.
Ils ont activé une compilation de graphe agressive et fusionné des kernels, poussant leurs modèles via un runtime optimisé. Ça a fonctionné brillamment — sur une génération de GPU.
Puis les achats ont livré un lot mixte : même fournisseur, stepping d’architecture différent. Les moteurs optimisés étaient mis en cache et réutilisés
entre nœuds parce que « un GPU est un GPU », disait la pipeline de déploiement. La latence a grimpé, et certaines requêtes ont commencé à expirer.
La cause racine était l’invalidation de cache, le méchant classique au meilleur marketing. Les artefacts d’engine étaient spécifiques à l’architecture.
Sur les « nouveaux » GPU, le runtime retombait sur des chemins plus lents ou passait trop de temps à recompiler à la première requête, transformant le p99 en cauchemar.
Ils l’ont corrigé en indexant les caches sur les propriétés du dispositif (compute capability, versions pilote/runtime) et en préchauffant les engines pendant le déploiement,
pas sous charge client. Ils ont aussi cessé de considérer l’optimisation comme une action unique et ont commencé à la traiter comme un contrat de compatibilité.
La leçon pour la discussion anti‑CUDA : au moment où vous optimisez pour une pile, vous créez un contrat implicite. Rendez‑le explicite, sinon il vous mordra.
Mini‑histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise
Une société de services financiers exploitait des clusters GPU multi‑locataires. Rien de fancy, juste un flux régulier d’entraînements modèle et d’inférences par lot.
Ils voulaient de l’optionnalité : NVIDIA pour l’entraînement lourd, accélérateurs alternatifs pour certaines inférences et l’accélération ETL.
Leur arme secrète n’était pas un compilateur brillant. C’était une gouvernance ennuyeuse : chaque classe de nœud GPU avait une « golden image » épinglée avec
un noyau, un pilote et un runtime de conteneur testés ensemble. Les changements passaient par une pool canaris avec des smoke tests automatisés :
découverte de périphérique, un benchmark GEMM simple, un test de comms, et un run d’inférence minimal.
Une semaine, une mise à jour de sécurité du noyau a cassé les builds DKMS pour une classe de nœud. Le pool canari l’a détecté immédiatement ; la production ne l’a jamais vu.
Ils ont retardé le déploiement, appliqué une mise à jour pilote recommandée par le fournisseur, puis ont poursuivi.
La leçon : la diversification est viable quand votre discipline plateforme est réelle. Sinon, « anti‑CUDA » devient du « développement piloté par incidents ».
Tâches pratiques : commandes, sorties et décisions (12+)
C’est la partie que la plupart des documents stratégiques ignorent : ce que vous faites réellement un mardi quand la flotte est lente, en panne, ou en migration.
Ci‑dessous se trouvent des tâches concrètes avec commandes réalistes, sorties d’exemple, et la décision que vous en tirez.
Ces exemples supposent des hôtes Linux et un mélange de Kubernetes et de bare‑metal. Adaptez‑les, mais gardez l’intention.
Tâche 1 : Confirmer la visibilité des GPU (NVIDIA)
cr0x@server:~$ nvidia-smi -L
GPU 0: NVIDIA A100-SXM4-40GB (UUID: GPU-2a3c...)
GPU 1: NVIDIA A100-SXM4-40GB (UUID: GPU-8f19...)Ce que cela signifie : Le pilote peut énumérer les dispositifs. Si cela échoue, rien au‑dessus n’a d’importance.
Décision : Si des GPU manquent, arrêtez et corrigez le pilote/noyau/matériel avant de toucher aux frameworks.
Tâche 2 : Vérifier l’appariement pilote/runtime et l’état
cr0x@server:~$ nvidia-smi
+-----------------------------------------------------------------------------+
| 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 |
| 0 A100-SXM4-40GB On | 00000000:41:00.0 Off | 0 |
+-------------------------------+----------------------+----------------------+Ce que cela signifie : Le pilote est chargé ; la version CUDA signalée est le maximum supporté par le pilote, pas nécessairement celle utilisée par votre conteneur.
Décision : Si les conteneurs livrent un userland CUDA plus récent que ce que le pilote hôte supporte, attendez‑vous à des erreurs d’exécution. Épinglez ou mettez à jour délibérément.
Tâche 3 : Valider la découverte de dispositif ROCm (AMD)
cr0x@server:~$ rocminfo | head -n 12
ROCk module is loaded
=====================
HSA System Attributes
=====================
Runtime Version: 1.14
System Timestamp Freq.: 1000.000000MHz
Signal Max Wait Duration:18446744073709551615 (0xffffffffffffffff) (ns)Ce que cela signifie : Le runtime ROCm peut communiquer avec le pilote noyau et la couche HSA.
Décision : Si ROCk/HSA n’est pas sain, ne blâmez pas le modèle. Corrigez les modules noyau, le firmware et les combos distro/noyau supportés.
Tâche 4 : Vérifier l’utilisation GPU et si vous êtes lié par le calcul ou par l’entrée
cr0x@server:~$ nvidia-smi dmon -s pucvmet -d 1 -c 5
# gpu pwr gtemp mtemp sm mem enc dec mclk pclk rxpci txpci fb bar1
# Idx W C C % % % % MHz MHz MB/s MB/s % %
0 215 62 - 18 12 0 0 1215 1410 120 30 40 1
0 220 63 - 19 13 0 0 1215 1410 110 28 41 1Ce que cela signifie : Faible utilisation SM avec peu de PCIe suggère que votre GPU est sous‑alimenté par le CPU/dataloader ou attend une synchronisation.
Décision : Si le SM est bas, n’achetez pas plus de GPU. Profilez d’abord le pipeline d’entrée, le pinning CPU et la taille des lots.
Tâche 5 : Confirmer la topologie PCIe et la localité NUMA
cr0x@server:~$ nvidia-smi topo -m
GPU0 GPU1 CPU Affinity NUMA Affinity
GPU0 X NV1 0-31 0
GPU1 NV1 X 0-31 0Ce que cela signifie : Les GPU sont connectés via NVLink (NV1) et partagent le même nœud NUMA/affinité CPU.
Décision : Si les GPU sont sur des nœuds NUMA différents, pinglez les processus et dataloaders de façon appropriée ou attendez‑vous à des échecs d’échelle « mystérieux ».
Tâche 6 : Détecter le bridage CPU qui prend l’apparence d’une lenteur GPU
cr0x@server:~$ lscpu | egrep 'Model name|CPU\(s\)|Thread|NUMA node'
Model name: AMD EPYC 7543 32-Core Processor
CPU(s): 64
Thread(s) per core: 2
NUMA node(s): 2Ce que cela signifie : Vous avez plusieurs nœuds NUMA ; le trafic mémoire inter‑nœuds peut nuire aux dataloaders et aux copies hôte‑dispositif.
Décision : Si le pipeline d’entrée est sensible au CPU/NUMA, imposez le pinning CPU/mémoire dans votre orchestrateur.
Tâche 7 : Vérifier le plugin device Kubernetes et les ressources allocatables
cr0x@server:~$ kubectl describe node gpu-worker-12 | sed -n '/Allocatable:/,/Events:/p'
Allocatable:
cpu: 62
memory: 503842Mi
nvidia.com/gpu: 8
pods: 110Ce que cela signifie : Le nœud annonce des GPU au scheduler ; si ça affiche 0, le device plugin/stack pilote est cassé.
Décision : Si les GPU allocatables sont incorrects, corrigez le provisioning du nœud avant de déboguer les pods.
Tâche 8 : Vérifier qu’un conteneur peut accéder au GPU (test d’intégration runtime)
cr0x@server:~$ docker run --rm --gpus all nvidia/cuda:12.3.2-base-ubuntu22.04 nvidia-smi -L
GPU 0: NVIDIA A100-SXM4-40GB (UUID: GPU-2a3c...)
GPU 1: NVIDIA A100-SXM4-40GB (UUID: GPU-8f19...)Ce que cela signifie : Le runtime de conteneur est correctement câblé pour le passthrough GPU et l’image a des outils userland compatibles.
Décision : Si cela échoue, votre problème est l’intégration runtime conteneur/pilote, pas votre application.
Tâche 9 : Détecter les dépendances CUDA cachées dans les wheels Python
cr0x@server:~$ python3 -c "import pkgutil,sys; import torch; print(torch.version.cuda); print(torch.cuda.is_available())"
12.1
TrueCe que cela signifie : Votre build PyTorch est activé CUDA et voit le GPU.
Décision : Si vous ciblez un backend non‑CUDA, cessez de livrer des builds CUDA par défaut ; séparez les artefacts par backend.
Tâche 10 : Confirmer que NCCL peut s’initialiser et voir les interfaces attendues
cr0x@server:~$ env | egrep 'NCCL|CUDA' | head
NCCL_DEBUG=INFO
NCCL_SOCKET_IFNAME=eth0Ce que cela signifie : Votre environnement est configuré pour aider NCCL à choisir la bonne NIC et émettre des logs exploitables.
Décision : Si l’entraînement multi‑nœud est instable, activez le debug NCCL et vérifiez la sélection NIC avant de blâmer « le réseau ».
Tâche 11 : Mesurer la latence disque et système de fichiers qui peut affamer les GPU
cr0x@server:~$ iostat -xz 1 3
avg-cpu: %user %nice %system %iowait %steal %idle
18.21 0.00 2.91 9.44 0.00 69.44
Device r/s rkB/s rrqm/s %rrqm r_await rareq-sz w/s wkB/s w_await aqu-sz %util
nvme0n1 420.0 65536.0 0.0 0.00 6.20 156.0 110.0 8192.0 1.10 3.50 98.0Ce que cela signifie : %util élevé et r_await croissant indiquent que le dispositif de stockage est saturé ; les dataloaders vont jitter.
Décision : Si l’iowait est non trivial et que l’utilisation disque est saturée, corrigez la mise en scène/caching des datasets avant d’optimiser les kernels.
Tâche 12 : Valider le débit réseau et la perte de paquets (réalité de l’entraînement multi‑nœud)
cr0x@server:~$ ip -s link show dev eth0 | sed -n '1,8p'
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff
RX: bytes packets errors dropped missed mcast
9876543210 8123456 0 12 0 12345
TX: bytes packets errors dropped carrier collsns
8765432109 7345678 0 0 0 0Ce que cela signifie : Des paquets RX perdus peuvent ruiner la performance des collectives et causer des timeouts qui ressemblent à des « problèmes GPU ».
Décision : Si les pertes augmentent sous charge, inspectez les queues NIC, le MTU, le contrôle de congestion et la configuration des switches.
Tâche 13 : Vérifier les logs noyau pour resets GPU et événements de type Xid
cr0x@server:~$ sudo dmesg -T | egrep -i 'nvrm|xid|amdgpu|gpu reset' | tail -n 8
[Mon Jan 21 10:12:03 2026] NVRM: Xid (PCI:0000:41:00): 79, GPU has fallen off the bus.
[Mon Jan 21 10:12:04 2026] nvidia: GPU 0000:41:00.0: GPU recovery action changed from 0x0 to 0x1Ce que cela signifie : Problèmes matériel, alimentation, firmware ou intégrité PCIe. Ce n’est pas un « bug de framework ».
Décision : Quarantainez le nœud, vérifiez l’alimentation/le câblage/BIOS/firmware, et envisagez un RMA si cela se reproduit.
Tâche 14 : Identifier la fragmentation mémoire GPU et la pression d’allocation
cr0x@server:~$ nvidia-smi --query-gpu=memory.total,memory.used,memory.free --format=csv
memory.total [MiB], memory.used [MiB], memory.free [MiB]
40960 MiB, 39812 MiB, 1148 MiBCe que cela signifie : Vous êtes proche de la limite ; des échecs d’allocation ou un comportement proche du paging peuvent apparaître comme des pics de latence.
Décision : Réduisez la taille des lots, activez une meilleure planification mémoire, ou allouez un modèle par GPU plutôt que de multiplexez.
Tâche 15 : Vérifier la configuration MIG (si utilisé)
cr0x@server:~$ nvidia-smi -i 0 -q | sed -n '/MIG Mode/,/GPU Instance/p'
MIG Mode
Current : Enabled
Pending : EnabledCe que cela signifie : MIG est activé ; vos domaines de performance et de défaillance sont désormais des « instances », pas des GPU entiers.
Décision : Assurez‑vous que la planification, le monitoring et les plans de capacité sont MIG‑aware ; sinon vous interpréterez mal l’utilisation et la saturation.
Playbook de diagnostic rapide : quoi vérifier en premier/deuxième/troisième
Quand quelqu’un dit « les GPU sont lents », il décrit généralement un des quatre goulots : calcul, bande passante mémoire,
pipeline d’entrée, ou communication. Ne devinez pas. Triez comme un SRE.
Premier : Le dispositif est‑il même sain et visible ?
- Exécutez
nvidia-smiourocminfo; vérifiez les dispositifs manquants. - Consultez les logs noyau pour resets, erreurs bus et paniques du pilote.
- Si des erreurs existent : mettez le nœud en quarantaine. Ne « retentez » pas indéfiniment.
Deuxième : Sous‑utilisons‑nous le GPU ?
- Utilisez
nvidia-smi dmon(ou équivalents fournisseur) pour observer l’utilisation SM et mémoire. - Si le SM est bas : suspectez le dataloader, le pinning CPU, des petites tailles de batch, des points de synchronisation, ou l’overhead Python.
- Si la mémoire est élevée mais le SM bas : suspectez des kernels limités par la mémoire ou une mauvaise fusion/implémentation des attention.
Troisième : Le système nourrit‑il le GPU (stockage, CPU, PCIe) ?
- Vérifiez
iostat -xzpour saturation disque etmpstatpour iowait CPU. - Confirmez la topologie PCIe et l’affinité NUMA ; pinglez les processus en conséquence.
- Vérifiez les débits hôte‑dispositif (compteurs PCIe rx/tx comme signal brut).
Quatrième : Si multi‑GPU ou multi‑nœud, la communication est‑elle le goulot ?
- Cherchez pertes réseau, retransmissions et saturation NIC.
- Activez les logs debug NCCL (ou équivalents) et confirmez la sélection d’interface.
- Validez la topologie : présence NVLink, layout des switches PCIe, et localité NUMA.
Cinquième : Ce n’est qu’ensuite qu’on discute des choix de portabilité « anti‑CUDA »
Si vous ne pouvez pas mesurer de façon fiable où le temps est passé sur votre pile actuelle, migrer de pile amplifiera le chaos.
La portabilité est une fonctionnalité. L’observabilité en est le prérequis.
Erreurs fréquentes : symptômes → cause racine → correction
Ce sont les récidivistes quand des équipes poursuivent des objectifs « anti‑CUDA » ou même juste essaient d’exploiter des flottes GPU mixtes.
Chaque entrée est assez spécifique pour passer à l’action.
1) « Ça tourne en staging mais ça plante sur le nouveau pool GPU »
Symptôme : Erreurs d’import, bibliothèques partagées manquantes, instruction illégale, ou échecs d’initialisation runtime.
Cause racine : Dépendance binaire spécifique au fournisseur cachée (wheels, extensions, moteurs d’inférence) compilée pour CUDA ou pour une arch différente.
Correction : Séparez les artefacts de build par backend ; ajoutez un préflight par classe de nœud qui importe et exécute un warmup d’un batch sur chaque pool cible.
2) « Même modèle, même code, 2–5× plus lent sur un backend alternatif »
Symptôme : Pas d’erreurs, juste un débit épouvantable.
Cause racine : Écart de maturité des kernels/bibliothèques (GEMM/attention), chemins rapides mémoire différents, absence de fusion, ou support de précision sous‑optimal.
Correction : Benchmarquez les primitives (GEMM/attention) séparément ; ajustez les paramètres du modèle (précision, ops fusionnés) ; acceptez le tuning par backend comme partie du contrat.
3) « L’entraînement multi‑nœud se fige aléatoirement »
Symptôme : Processus bloqués dans all‑reduce ; timeouts ; un rang prend du retard.
Cause racine : Mauvaise NIC sélectionnée, perte de paquets, mismatch MTU, ou mismatch de topologie entre hôtes.
Correction : Pinglez les comms sur la NIC correcte, validez les compteurs de lien, et exécutez des microbenchmarks de comms dans la même image conteneur que celle utilisée en entraînement.
4) « Les mises à jour de pilote cassent les nœuds Kubernetes »
Symptôme : Nœud passe en NotReady après patch noyau ; les GPU disparaissent des ressources allocatables.
Cause racine : Échec de rebuild DKMS ou incompatibilité noyau‑pilote ; dérive d’images entre groupes de nœuds.
Correction : Utilisez des golden images épinglées par classe de nœud ; rollouts canaris ; traitez noyau+pilote+runtime comme une unité.
5) « Pics de latence p99 après activation de compilation/optimisation »
Symptôme : Cold‑start ou recompilation occasionnelle sous charge ; misses de cache.
Cause racine : Cache d’engine indexé trop lâchement ; artefacts réutilisés sur des combos appareil/pilote incompatibles.
Correction : Indexez les caches sur les propriétés du dispositif et les versions runtime ; préchauffez pendant le déploiement ; stockez les artefacts par classe de nœud.
6) « L’utilisation GPU est basse mais le CPU aussi »
Symptôme : Tout semble inactif ; le débit reste faible.
Cause racine : Overhead de synchronisation, petits kernels, overhead Python, ou transferts hôte‑dispositif excessifs.
Correction : Profilez la timeline ; augmentez la taille des lots ; fusionnez les ops ; déplacez le prétraitement sur GPU ; réduisez les transferts.
Blague n°2 : Les abstractions neutres vis‑à‑vis du fournisseur sont géniales jusqu’à ce que vous ayez besoin d’un profileur spécifique au fournisseur pour comprendre pourquoi l’abstraction neutre est lente.
Listes de vérification / plan étape par étape
Si vous voulez une vraie posture « anti‑CUDA » — c’est‑à‑dire de l’optionnalité sans des outages auto‑infligés — faites‑le par étapes.
Traitez‑le comme une migration de backends de stockage : vous ne commencez pas par réécrire l’application, vous commencez par définir des interfaces,
mesurer la performance, et contrôler le déploiement.
Étape 1 : Définir ce qui doit être portable vs ce qui peut être spécifique au fournisseur
- Portable : format de modèle (lorsque possible), API de service, schémas requête/réponse, tests CI, harnais de benchmark.
- Autorisé spécifique fournisseur : moteurs d’inférence, fusions de kernels, bibliothèques de comms, profileurs bas‑niveau.
- Règle : le spécifique fournisseur est acceptable s’il est modulaire et mesurable.
Étape 2 : Faire du « node class » un concept de première classe
- Étiquetez explicitement les pools par type d’accélérateur, interconnexion, taille mémoire, et versions pilote/runtime.
- Arrêtez de déployer « une image pour tous » à moins de pouvoir le prouver.
- Consignez les matrices de compatibilité dans le code (CI) plutôt que dans des feuilles de calcul (l’espoir).
Étape 3 : Construire une pipeline d’artefacts consciente du backend
- Créez des tags de conteneur séparés par backend (et par version runtime majeure si nécessaire).
- Exécutez des smoke tests backend‑spécifiques : découverte de périphérique, inférence d’un batch, contrôle sanity de débit, test de pression mémoire.
- Faites échouer les builds quand de mauvaises wheels se glissent.
Étape 4 : Établir un harnais de benchmark qui reflète la production
- Mesurez p50/p95/p99, pas seulement le débit moyen.
- Incluez les comportements cold‑start et warmup de cache.
- Utilisez les mêmes tailles de batch, longueurs de séquence et prétraitements que le trafic de production.
Étape 5 : Adopter le multi‑vendeur seulement lorsque l’économie tient
- Entraînement : le plus difficile à porter en raison des attentes sur les comms et la maturité des kernels.
- Inférence : souvent plus facile si vous acceptez des builds d’engine par backend et un peu de tuning.
- Batch/accélération ETL : bon candidat si les primitives sont standard et les contraintes de latence plus souples.
Étape 6 : Déployer comme un SRE, pas comme un manifeste
- Canarisez les nouveaux pools avec de vraies tranches de trafic.
- Mettez des seuils de rollback automatisés sur taux d’erreur et latence tail.
- Gardez un pool « known‑good » prêt pendant que vous apprenez les nouveaux modes de défaillance.
FAQ
1) Existe‑t‑il vraiment un mouvement coordonné « anti‑CUDA » ?
Pas au sens d’une seule organisation avec un plan unifié. Ce qui existe, c’est une convergence d’incitations :
pression sur les coûts, contraintes d’approvisionnement, et désir d’avoir du levier en négociation. Le résultat ressemble à un mouvement.
2) « Ouvert » veut‑il automatiquement dire « portable » ?
Non. Les standards ouverts aident la portabilité, mais la portabilité en production dépend des pilotes, du packaging, des bibliothèques et de la discipline de test.
Vous pouvez avoir des APIs ouvertes et garder des falaises de performance spécifiques à un fournisseur.
3) Quel est le plus gros obstacle technique pour quitter CUDA ?
La maturité des bibliothèques et la profondeur des outils. Le code au niveau framework peut souvent tourner ailleurs avec du travail,
mais égaler la qualité des kernels CUDA pour votre workload spécifique est la partie difficile.
4) Dois‑je parier sur une couche de portabilité unique comme SYCL ou OpenCL ?
Pariez sur une architecture, pas sur un slogan. Utilisez des couches de portabilité quand elles aident, mais gardez des issues de secours
pour des chemins optimisés fournisseur. Votre objectif est l’optionnalité opérationnelle, pas la pureté idéologique.
5) L’inférence est‑elle plus facile à diversifier que l’entraînement ?
En général oui. L’inférence peut tolérer la compilation d’engine par backend et est souvent moins sensible aux collectives multi‑nœuds.
L’entraînement est l’endroit où les comms et les cas limites de kernel apparaissent en premier.
6) Que devrais‑je standardiser pour réduire le verrouillage sans perdre de performance ?
Standardisez les interfaces : API modèle, contrats de service, harnais build/test, et définitions de classes de nœuds.
Autorisez des implémentations spécifiques fournisseur derrière ces interfaces quand elles vous apportent une vraie performance.
7) Comment éviter les dépendances CUDA cachées ?
Traitez la résolution de dépendances comme un problème de chaîne d’approvisionnement. Construisez des images par backend, exécutez des vérifications à l’import,
et faites un warmup GPU d’un batch sur chaque classe de nœud en CI ou en pré‑prod.
8) Quelle est la raison la plus courante pour laquelle les projets « anti‑CUDA » échouent ?
Ils commencent par des réécritures. Les projets réussis commencent par des contrôles opérationnels : harnais de benchmark, épinglage d’images,
rollouts canaris, et backends modulaires. La portabilité se gagne par la discipline.
9) Puis‑je obtenir les bénéfices de l’anti‑CUDA sans changer de fournisseur matériel ?
Oui. Même dans des flottes uniquement NVIDIA, vous pouvez réduire le verrouillage en rendant vos builds reproductibles, en indexant correctement les caches,
et en n’attachant pas votre produit à une seule combinaison pilote/runtime.
Conclusion : quoi faire la semaine prochaine, pas la décennie prochaine
Y aura‑t‑il une « vraie » poussée anti‑CUDA ? Oui, mais elle ne ressemblera pas à une exode de masse. Elle ressemblera à des achats qui demandent des options,
des équipes plateforme qui construisent des pipelines conscients des backends, et des SRE qui insistent sur des classes de nœuds reproductibles parce qu’ils en ont marre de la roulette des pilotes.
CUDA restera dominante pour un avenir proche parce que ce n’est pas seulement une API — c’est un écosystème de production avec des bibliothèques et des outils matures.
Le choix pratique n’est pas de « combattre CUDA ». Le choix pratique est d’arrêter de laisser CUDA être une dépendance non examinée.
Étapes suivantes exécutables
- Inventoriez votre graphe de dépendances pour les binaires spécifiques GPU et identifiez où CUDA est implicitement requis.
- Définissez des classes de nœuds et épinglez les combos noyau/pilote/runtime par classe avec des rollouts canaris.
- Construisez un harnais de benchmark mesurant la latence tail et le comportement cold‑start, pas seulement le débit.
- Séparez les artefacts de conteneur par backend et ajoutez des warmups de préflight sur chaque pool cible.
- Choisissez une charge de travail (souvent l’inférence) comme pilote de portabilité et traitez‑la comme un service soutenu par des SLO, pas comme un projet de recherche.
L’optionnalité n’est pas gratuite. Mais rester coincé ne l’est pas non plus.