GPU dans WSL : exigences réelles (et pièges courants)

Le modèle mental : ce que « GPU dans WSL » signifie vraiment

WSL2 n’est pas « Linux sur Windows » dans le sens mignon. C’est une VM légère. Vos processus Linux s’exécutent dans un vrai noyau Linux (fourni par Microsoft),
et ils voient le matériel à travers une frontière de virtualisation.

Pour le calcul GPU, WSL2 utilise une interface GPU paravirtualisée. Sur les builds Windows modernes, le pilote GPU Windows expose un chemin de calcul vers la VM WSL.
Les processus Linux ne parlent pas à un périphérique PCI physique ; ils parlent à un nœud de périphérique virtuel qui relaie le travail au pilote hôte.
Le pilote Windows est la source de vérité. En pratique, cela signifie :

• Vous n’installez pas un pilote noyau NVIDIA Linux complet dans WSL pour le GPU. Si vous essayez, vous empirerez généralement les choses.
• libcuda dans WSL provient d’une couche d’intégration spéciale, pas de la pile habituelle de modules noyau de votre distribution.
• La plupart des échecs sont des incompatibilités entre la version du pilote Windows, les capacités du noyau WSL et les bibliothèques userland (toolkit CUDA / frameworks ML).

Considérez le support GPU dans WSL comme un « CUDA distant vers le pilote Windows via un canal local très rapide », et non comme « Linux possède le GPU ».
Ce changement de perspective évite l’erreur classique : courir après des modules noyau Linux qui ne s’appliquent même pas.

Blague n°1 : le dépannage GPU dans WSL, c’est comme faire coopérer des chats — sauf que les chats sont des pilotes, et ils affirment tous qu’ils sont déjà installés.

Les exigences réelles (ce qui doit être vrai)

1) Votre build Windows doit prendre en charge le calcul GPU dans WSL2

Le calcul GPU dans WSL2 dépend de la pile hôte Windows : pilotes GPU WDDM, plomberie WSL et support noyau.
Si Windows est trop ancien, vous aurez une installation WSL propre mais un chemin GPU complètement mort.

Conseil pratique : maintenez Windows à jour. Si vous êtes dans un ring d’entreprise qui accuse du retard, vérifiez le support GPU-in-WSL avant de promettre quoi que ce soit à votre équipe.
Ce n’est pas optionnel ; c’est la base.

2) Votre fournisseur GPU et le pilote doivent explicitement prendre en charge WSL

Dans la réalité, la plupart des gens faisant du CUDA dans WSL sont sur NVIDIA. AMD peut fonctionner dans certains scénarios (et DirectML existe),
mais CUDA-in-WSL est principalement une affaire NVIDIA.

L’exigence clé est la version du pilote NVIDIA Windows qui inclut le support WSL.
Installer un pilote « Studio » ou « Game Ready » au hasard convient tant qu’il est assez récent et comprend les composants de calcul WSL.
Les pilotes anciens rendront volontiers les jeux tout en refusant d’exposer le calcul à WSL.

3) WSL2, pas WSL1

WSL1 traduit les appels système Linux. C’est astucieux, mais ce n’est pas la plateforme pour le calcul GPU. Vous voulez WSL2 avec le vrai noyau.
Si votre distribution est encore en WSL1, stoppez. Convertissez-la. Ne déboguez rien d’autre tant que ce n’est pas fait.

4) Un noyau WSL et une version WSL pris en charge

Il y a deux pièces en mouvement : le build OS Windows et le composant WSL lui-même (qui se met à jour maintenant comme une application).
Le chemin GPU vit dans cet espace. Si vous êtes sur une version WSL obsolète, vous pouvez voir des incompatibilités étranges : le pilote Windows semble correct, mais WSL manque la colle.

5) Les bibliothèques userland doivent correspondre aux attentes du framework

C’est là que les gens se tirent souvent une balle dans le pied : ils installent l’intégralité du toolkit CUDA dans WSL comme sur un Ubuntu bare metal,
puis écrasent des bibliothèques clés, et s’étonnent ensuite que nvidia-smi fonctionne mais que PyTorch ne fonctionne pas.

Décidez de ce dont vous avez réellement besoin :

• Si vous exécutez uniquement PyTorch ou TensorFlow : vous n’avez souvent pas besoin du toolkit CUDA complet ; vous avez besoin de la bonne build du framework et des bibliothèques userland compatibles.
• Si vous compilez du code CUDA personnalisé : vous avez besoin du toolkit dans WSL, mais vous ne devriez toujours pas installer un pilote noyau Linux.

6) Docker ajoute une autre couche de dépendances

Docker dans WSL est courant — et un amplificateur fréquent d’échecs. Vous avez maintenant :
Pilote Windows → interface GPU WSL → userland WSL → moteur Docker → NVIDIA container runtime → image de votre conteneur.
Une incompatibilité et vous perdez le GPU, ou vous obtenez un conteneur qui voit le GPU mais ne peut pas exécuter de kernels.

Faits et contexte historique (pourquoi c’est étrange)

Ce ne sont pas des trivia pour le plaisir. Ils expliquent le design d’aujourd’hui et les modes de panne que vous verrez réellement.

1. WSL1 (2016) n’était pas une VM. Il traduisait les appels système. Parfait pour les outils CLI ; pas adapté aux GPU et aux pilotes en mode noyau.
2. WSL2 (2019) est passé à un vrai noyau Linux. Cela a rendu les charges containers et les outils dépendants du noyau pratiques.
3. Le calcul GPU dans WSL2 est arrivé via la paravirtualisation, pas le passthrough PCI. Votre invité Linux ne « possède » pas le périphérique GPU comme dans un passthrough classique d’hyperviseur.
4. Le modèle de pilote d’affichage Windows (WDDM) est dans le chemin critique. Si les composants WDDM sont obsolètes, le calcul peut échouer même si le rendu graphique fonctionne.
5. Le support WSL de NVIDIA comprenait une voie CUDA en espace utilisateur dédiée. C’est pourquoi la version du pilote Windows compte plus que l’idée de « latest » du gestionnaire de paquets Linux.
6. nvidia-smi dans WSL est un signal de compatibilité, pas la vérité complète. Il peut réussir alors que votre framework ML échoue à cause de mismatchs cuDNN/cublas.
7. Le support GPU initial dans WSL était contraint par les builds Windows Insider. Beaucoup de « ça marche chez moi » vient de cette époque.
8. DirectML est devenu une alternative pragmatique pour certaines charges ML orientées Windows. Mais si vous voulez l’écosystème CUDA mainstream, vous resterez dans l’univers NVIDIA.

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

Ce sont des vérifications de niveau production. Pas les rituels « réinstallez tout ».
Chaque tâche inclut une commande, ce que signifie typiquement sa sortie, et la décision suivante.

Task 1: Confirmer la version de WSL et la santé de base (côté Windows)

cr0x@server:~$ wsl.exe --version
WSL version: 2.1.5.0
Kernel version: 5.15.146.1-2
WSLg version: 1.0.61
MSRDC version: 1.2.5326
Direct3D version: 1.611.1-81528511
DXCore version: 10.0.26052.1000-240405-2035.ge-release
Windows version: 10.0.22631.3007

Interprétation : Vous voulez une version WSL moderne et un noyau 5.15+ dans la plupart des environnements. Les numéros exacts varient, mais « ancien » est évident.

Décision : Si wsl.exe --version échoue ou affiche des composants très anciens, mettez à jour WSL avant de toucher à CUDA ou aux frameworks.

Task 2: Confirmer que votre distro fonctionne en WSL2 (pas WSL1)

cr0x@server:~$ wsl.exe -l -v
  NAME            STATE           VERSION
* Ubuntu-22.04    Running         2
  Debian          Stopped         2

Interprétation : VERSION doit être 2.

Décision : Si c’est 1, convertissez : wsl.exe --set-version <distro> 2. Ne déboguez pas GPU sur WSL1.

Task 3: Vérifier que Windows voit le pilote NVIDIA (sanity host)

cr0x@server:~$ nvidia-smi.exe
Tue Feb  6 09:14:22 2026
+---------------------------------------------------------------------------------------+
| NVIDIA-SMI 551.23                 Driver Version: 551.23         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 RTX 4090               On   |   00000000:01:00.0  On |                  N/A |
|  0%   44C    P8             21W / 450W  |     987MiB / 24564MiB   |      2%      Default |
+-----------------------------------------+------------------------+----------------------+

Interprétation : Le pilote Windows est installé et le GPU est visible. La version CUDA affichée ici reflète la capacité du pilote, pas votre toolkit WSL.

Décision : Si cela échoue sur Windows, arrêtez-vous et corrigez le pilote Windows d’abord. WSL ne l’améliorera pas magiquement.

Task 4: Vérifier que le nœud de périphérique GPU existe dans WSL

cr0x@server:~$ ls -l /dev/dxg
crw-rw-rw- 1 root root 509, 0 Feb  6 09:10 /dev/dxg

Interprétation : /dev/dxg est le périphérique pont GPU WSL. Pas de /dev/dxg, pas de chemin compute GPU.

Décision : S’il manque, suspectez WSL/noyau obsolète, build Windows incorrect ou pilote GPU sans support WSL.

Task 5: Confirmer que WSL peut appeler la stack de gestion NVIDIA

cr0x@server:~$ nvidia-smi
Tue Feb  6 09:16:05 2026
+---------------------------------------------------------------------------------------+
| NVIDIA-SMI 551.23                 Driver Version: 551.23         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 RTX 4090               On   |   00000000:01:00.0  On |                  N/A |
|  0%   45C    P8             23W / 450W  |     992MiB / 24564MiB   |      1%      Default |
+-----------------------------------------+------------------------+----------------------+

Interprétation : C’est une vérification nécessaire mais non suffisante. Elle prouve que la stack de gestion fonctionne via WSL.

Décision : Si cela échoue, ne perdez pas de temps à réinstaller PyTorch maintenant. Corrigez d’abord l’intégration pilote/WSL.

Task 6: Vérifier si vous avez installé accidentellement un pilote NVIDIA noyau Linux (généralement mauvais dans WSL)

cr0x@server:~$ lsmod | grep -E '^nvidia|^nouveau' || true
nouveau              2539520  0
drm_ttm_helper         16384  1 nouveau
ttm                  106496  2 drm_ttm_helper,nouveau
drm_kms_helper        315392  1 nouveau

Interprétation : Voir des modules noyau nouveau ou nvidia chargés dans WSL est un signal d’alerte.
Dans les configurations GPU WSL typiques, vous ne devriez pas utiliser ces modules noyau pour le chemin paravirtualisé.

Décision : Si ces modules sont chargés, supprimez-les/blacklistez-les et revenez au modèle d’intégration WSL supporté. C’est une panne auto-infligée courante.

Task 7: Vérifier la résolution de libcuda.so dans WSL

cr0x@server:~$ ldconfig -p | grep -E 'libcuda\.so|libnvidia-ml\.so' | head
	libcuda.so.1 (libc6,x86-64) => /usr/lib/wsl/lib/libcuda.so.1
	libnvidia-ml.so.1 (libc6,x86-64) => /usr/lib/wsl/lib/libnvidia-ml.so.1

Interprétation : Dans WSL, vous souhaitez typiquement des stubs CUDA et des bibliothèques d’intégration sous /usr/lib/wsl/lib.
Si libcuda.so.1 se résout ailleurs (comme /usr/lib/x86_64-linux-gnu depuis un paquet distro), vous pouvez avoir des conflits de bibliothèques.

Décision : Si la résolution est incorrecte, corrigez le chemin des bibliothèques et retirez les paquets en conflit avant de déboguer les frameworks.

Task 8: Confirmer que l’environnement ne sabote pas les chemins de chargement des bibliothèques

cr0x@server:~$ env | grep -E 'LD_LIBRARY_PATH|CUDA_HOME|CUDA_PATH' || true
LD_LIBRARY_PATH=/usr/local/cuda/lib64:/usr/local/cuda/extras/CUPTI/lib64
CUDA_HOME=/usr/local/cuda

Interprétation : Cela peut être acceptable si vous avez intentionnellement installé un toolkit compatible.
Cela peut aussi forcer vos applications à charger de mauvaises bibliothèques et ignorer /usr/lib/wsl/lib.

Décision : Si vous utilisez uniquement des wheels/paquets conda de frameworks, envisagez de désactiver ces variables et laissez le framework gérer les dépendances.

Task 9: Valider l’accès GPU depuis un framework (exemple PyTorch)

cr0x@server:~$ python3 -c "import torch; print(torch.__version__); print('cuda:', torch.version.cuda); print('is_available:', torch.cuda.is_available()); print('device:', torch.cuda.get_device_name(0) if torch.cuda.is_available() else 'none')"
2.2.1
cuda: 12.1
is_available: True
device: NVIDIA RTX 4090

Interprétation : C’est le test décisif. Si nvidia-smi fonctionne mais que torch.cuda.is_available() est false, vous avez probablement des mismatches de bibliothèques userland.

Décision : Si false, inspectez ldd sur les libs CUDA concernées, et vérifiez que vous avez installé une build du framework avec support CUDA.

Task 10: Inspecter le linkage dynamique d’une bibliothèque CUDA (attraper le « mauvais libcuda » vite)

cr0x@server:~$ python3 -c "import ctypes; import os; print(ctypes.CDLL('libcuda.so.1'))"
<CDLL 'libcuda.so.1', handle 55b7f6d8f900 at 0x7f2df0b7f2d0>

Interprétation : Si cela lève « cannot open shared object file », votre chemin de bibliothèques est cassé.

Décision : Si cela échoue, revenez aux Tasks 7 et 8. Ne réinstallez pas tout ; corrigez le linkage.

Task 11: Vérifier la configuration mémoire et swap de WSL (tueur silencieux de perf)

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:           31Gi       4.2Gi       21Gi       136Mi       5.8Gi        26Gi
Swap:          16Gi          0B       16Gi

Interprétation : WSL utilise de la mémoire dynamique, mais peut quand même atteindre du swap ou de la pression mémoire sous des workloads d’entraînement.
Si votre pipeline de données est gourmand en mémoire, l’utilisation GPU peut chuter tandis que le CPU pagine.

Décision : Si le swap est actif pendant l’entraînement, corrigez les limites mémoire et le buffering du pipeline de données. Ne blâmez pas CUDA en premier.

Task 12: Mesurer l’utilisation GPU pendant l’exécution d’un workload

cr0x@server:~$ nvidia-smi dmon -s pucm -d 1
# gpu   pwr gtemp   sm   mem   enc   dec  mclk  pclk
# Idx     W     C    %     %     %     %   MHz   MHz
    0    85    62   97    71     0     0  10501  2520
    0    92    63   98    73     0     0  10501  2520

Interprétation : Si sm est bas et que votre job est « training », vous n’êtes pas lié au GPU. Vous êtes limité en amont (CPU, I/O, data loader).

Décision : Une faible utilisation signifie que vous devez profiler le pipeline d’entrée, le stockage et les threads CPU avant de toucher aux réglages GPU.

Task 13: Vérifier le disque et le type de système de fichiers (audit I/O)

cr0x@server:~$ df -Th / /mnt/c
Filesystem     Type   Size  Used Avail Use% Mounted on
/dev/sdd       ext4   250G   42G  196G  18% /
C:\           drvfs  953G  611G  342G  65% /mnt/c

Interprétation : Le système de fichiers natif WSL ext4 (/) se comporte comme Linux. /mnt/c est DrvFS et a des caractéristiques de performance différentes.
Beaucoup de workloads ML sont détruits par des lectures de datasets depuis /mnt/c.

Décision : Gardez les datasets d’entraînement et les I/O lourdes dans le système de fichiers ext4 de WSL. Utilisez /mnt/c pour la commodité, pas pour la perf.

Task 14: Benchmark I/O rapide et sale là où vos données résident

cr0x@server:~$ dd if=/dev/zero of=./io-test.bin bs=1M count=2048 oflag=direct status=progress
2147483648 bytes (2.1 GB, 2.0 GiB) copied, 1.92 s, 1.1 GB/s
2048+0 records in
2048+0 records out
2147483648 bytes (2.1 GB, 2.0 GiB) copied, 1.92 s, 1.1 GB/s

Interprétation : Cela teste le débit séquentiel d’écriture. Si vous exécutez la même commande sur /mnt/c et obtenez des chiffres dramatiquement plus mauvais, vous avez trouvé un goulot.

Décision : Déplacez les données, ou redesign du pipeline (shards tar, cache, moins d’appels stat sur de petits fichiers) si vous devez rester sur DrvFS.

Task 15: Vérifier la visibilité GPU dans les conteneurs (si vous utilisez Docker)

cr0x@server:~$ docker run --rm --gpus all nvidia/cuda:12.3.2-base-ubuntu22.04 nvidia-smi
Tue Feb  6 09:22:18 2026
+---------------------------------------------------------------------------------------+
| NVIDIA-SMI 551.23                 Driver Version: 551.23         CUDA Version: 12.4   |
|-----------------------------------------+------------------------+----------------------+
| GPU  Name                 Persistence-M | Bus-Id          Disp.A | Volatile Uncorr. ECC |
|=========================================+========================+======================|
|   0  NVIDIA RTX 4090               On   |   00000000:01:00.0  On |                  N/A |
+---------------------------------------------------------------------------------------+

Interprétation : Si cela échoue mais que nvidia-smi dans WSL fonctionne, votre problème se situe dans le chemin runtime du conteneur (toolkit/runtime).

Décision : Corrigez la configuration du NVIDIA container runtime et assurez-vous que Docker Desktop/Engine est connecté à WSL correctement.

Task 16: Valider les goulots CPU côté hôte (parce que le GPU est souvent innocent)

cr0x@server:~$ sudo apt-get update >/dev/null 2>&1; sudo apt-get install -y sysstat >/dev/null 2>&1; mpstat -P ALL 1 3
Linux 5.15.146.1-microsoft-standard-WSL2 (server) 	02/06/2026 	_x86_64_	(24 CPU)

09:23:10 AM  CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle
09:23:11 AM  all   320.00    0.00   40.00   55.00    0.00    0.00    0.00    0.00    0.00  585.00
09:23:12 AM  all   330.00    0.00   41.00   60.00    0.00    0.00    0.00    0.00    0.00  570.00

Interprétation : Un %iowait élevé indique que vous attendez le stockage, pas le calcul. C’est le mystère classique du « GPU à 10% ».

Décision : Corrigez l’I/O (Tasks 13/14), le parallélisme des data loaders et la disposition des fichiers avant de commencer à tuner les flags CUDA.

Mode d’emploi diagnostic rapide (trouver le goulot d’étranglement vite)

Quand quelqu’un vous dit « le GPU WSL est cassé », il veut généralement dire une des trois choses :
pas de visibilité GPU, GPU visible mais frameworks en échec, ou GPU fonctionnel mais performance dégradée.
Ce playbook vous amène rapidement au bon cas.

Première étape : est-ce une panne du pilote Windows / de l’intégration WSL ?

1. Exécutez nvidia-smi.exe sur Windows. Si cela échoue, stoppez. Corrigez l’installation du pilote Windows.
2. Dans WSL, vérifiez ls -l /dev/dxg. Si manquant, stoppez. Mettez à jour WSL et confirmez que le build/driver Windows supporte WSL.
3. Dans WSL, lancez nvidia-smi. S’il échoue mais que /dev/dxg existe, suspectez des conflits de bibliothèques (libnvidia-ml/libcuda) ou une intégration WSL cassée.

Deuxième étape : est-ce un mismatch userland (confusion framework/toolkit) ?

1. Vérifiez ldconfig -p | grep libcuda et assurez-vous qu’il pointe vers /usr/lib/wsl/lib.
2. Testez le framework directement (sonde GPU minimale PyTorch/TensorFlow).
3. Si le framework échoue mais que nvidia-smi fonctionne, corrigez les versions : build du framework vs userland CUDA vs tout LD_LIBRARY_PATH épinglé.

Troisième étape : est-ce la performance (pipeline de données / stockage / limites CPU) ?

1. Pendant l’exécution : nvidia-smi dmon -s pucm -d 1. Si sm est bas, vous n’êtes pas lié au GPU.
2. Vérifiez où résident les données : df -Th. Si l’entraînement lit depuis /mnt/c, déplacez-les.
3. Surveillez %iowait avec mpstat. Iowait élevé : goulot de stockage. Iowait bas mais CPU saturé : le data loader / prétraitement est le limiteur.

Idée paraphrasée de Werner Vogels (CTO d’Amazon) : « Tout échoue ; la fiabilité vient du fait de concevoir et d’opérer pour cette vérité. »

Trois mini-histoires d’entreprise depuis le terrain

Incident : la mauvaise hypothèse (« WSL, c’est juste Ubuntu, non ? »)

Une équipe data science avait une image Windows standard et utilisait WSL2 pour le dev. Ils ont embauché un nouvel ingénieur ML qui avait fait des années de CUDA sur Ubuntu bare-metal.
L’ingénieur a fait ce que ferait toute personne compétente : il a installé le pilote NVIDIA Linux et un toolkit CUDA correspondant dans la distro WSL.

Les symptômes étaient superbement déroutants. nvidia-smi fonctionnait sur Windows, mais à l’intérieur de WSL il alternait entre « No devices were found » et un segfault.
Parfois ça marchait après un reboot. Parfois ça marchait jusqu’au démarrage de Docker. L’équipe a perdu une semaine dans l’archéologie Slack.

La cause racine était simple : ils avaient installé des paquets qui tentaient de gérer un pilote noyau que WSL n’était pas censé utiliser.
Des fichiers de bibliothèques furent écrasés, la logique de chargement de modules heurta une frontière noyau, et l’environnement devint nondéterministe selon ce qui se chargeait en premier.

La correction fut ennuyeuse : supprimer les paquets pilote NVIDIA Linux, purger les dépôts CUDA périmés, et restaurer la pile /usr/lib/wsl/lib fournie par WSL.
Ensuite, ils installèrent seulement les parties userland dont ils avaient réellement besoin pour compiler le code, et épinglèrent les versions des frameworks.

Ce qui changea culturellement était plus important que les commandes : ils cessèrent de traiter WSL comme un « vrai hôte Linux » et commencèrent à le traiter comme un runtime spécialisé.
Le rapport d’incident avait littéralement une ligne en surbrillance : « Le pilote Windows est le pilote. »

Optimisation qui a échoué : « Gardons les datasets sur C: pour que OneDrive les sauvegarde »

Une équipe voulait une source unique de vérité pour les datasets entre les outils Windows et les notebooks WSL.
Ils stockèrent tout sous C:\Users\...\datasets et y accédèrent depuis WSL via /mnt/c.
C’était propre. Ça rassurait les gens compliance. Ça rendit l’entraînement douloureusement lent.

Les graphes GPU racontèrent l’histoire : l’utilisation oscillait, le temps d’entraînement doublait, et des blocages aléatoires apparurent.
L’équipe a supposé un overhead de virtualisation GPU. Ils ont ajusté la taille des batches, activé la précision mixte, changé les versions CUDA, et même remplacé les GPU.
Rien n’a tenu.

Le vrai coupable était le comportement I/O sous DrvFS, amplifié par une disposition de dataset avec des millions de petits fichiers et des accès riches en métadonnées.
Ajoutez la protection des endpoints d’entreprise et la synchronisation cloud, et vous obtenez la mort par mille petits stat().

Ils corrigèrent cela en déplaçant les datasets chauds dans le système de fichiers ext4 de WSL et en exportant seulement les artefacts finalisés vers les chemins Windows.
Pour les datasets qui devaient rester sur Windows, ils les repackagèrent en archives shardées pour réduire les accès métadonnées.
L’« optimisation » fut inversée, et les performances revinrent comme si quelqu’un avait ôté une botte du cou du data loader.

Pratique ennuyeuse mais correcte : épinglage de versions et un test de fumée ont sauvé la mise

Une autre organisation avait une vraie équipe plateforme. Pas glamour. Surtout des feuilles de calcul et des garde-fous.
Ils construisirent une image WSL de base standard : plage de versions pilote Windows, version minimale WSL, version de distro Ubuntu, et un ensemble approuvé de frameworks ML.

Chaque lundi, un job programmé exécutait un test de fumée sur une poignée de machines : vérifier /dev/dxg, lancer nvidia-smi, importer PyTorch, exécuter un petit kernel CUDA,
et enregistrer les résultats. Pas de benchmarking en profondeur — juste « la chaîne fonctionne-t-elle encore ».

Une semaine, des mises à jour Windows furent déployées et le test de fumée détecta qu’un sous-ensemble de machines avait silencieusement réinstallé un pilote OEM GPU plus ancien.
Les utilisateurs ne l’avaient pas encore remarqué, car le graphisme était correct. Le calcul aurait été la première chose à casser pendant une échéance.

La correction fut une politique d’application des pilotes et un script de remédiation automatisé. Le gain clé n’était pas le script.
C’était l’existence d’un test routinier qui traitait GPU-in-WSL comme une dépendance opérationnelle, pas comme une superstition de développeur.

Blague n°2 : La configuration GPU la plus fiable est celle que personne n’« améliore » un vendredi après-midi.

Erreurs courantes : symptôme → cause racine → correction

1) Symptom: nvidia-smi dans WSL dit « command not found »

• Cause racine : Outils userland NVIDIA non installés dans la distro, ou PATH manquant.
• Correction : Installez l’ensemble de paquets userland approprié pour votre distro, ou utilisez des tests au niveau framework. N’installez pas de pilotes noyau. Assurez-vous que /usr/lib/wsl/lib existe.

2) Symptom: nvidia-smi dans WSL dit « No devices were found »

• Cause racine : Pont GPU WSL manquant (/dev/dxg), pilote Windows non supporté, ou WSL/noyau obsolète.
• Correction : Mettez à jour Windows, mettez à jour WSL, installez un pilote NVIDIA Windows qui supporte le calcul WSL. Validez ls -l /dev/dxg.

3) Symptom: /dev/dxg manquant

• Cause racine : Pas en WSL2, composant WSL trop ancien, ou build Windows qui ne supporte pas le chemin compute GPU.
• Correction : Convertissez la distro en WSL2, mettez à jour WSL, et assurez-vous que l’OS hôte répond aux exigences GPU-in-WSL.

4) Symptom: nvidia-smi fonctionne, mais PyTorch dit CUDA non disponible

• Cause racine : Build PyTorch CPU-only installé, ou bibliothèques CUDA userland mismatched/écrasées par LD_LIBRARY_PATH.
• Correction : Installez une build du framework avec support CUDA ; retirez les libs CUDA en conflit ; assurez-vous que libcuda.so.1 se résout vers /usr/lib/wsl/lib.

5) Symptom: Le conteneur Docker ne voit pas le GPU, mais WSL oui

• Cause racine : NVIDIA container runtime non configuré, Docker n’utilise pas correctement le moteur WSL, ou --gpus all manquant.
• Correction : Corrigez l’intégration Docker + NVIDIA runtime ; retestez avec une image CUDA connue et nvidia-smi dans le conteneur.

6) Symptom: L’entraînement est lent ; utilisation GPU basse et en pics

• Cause racine : Goulot pipeline de données (I/O, prétraitement CPU, trop peu de workers), souvent aggravé par l’utilisation de /mnt/c.
• Correction : Déplacez les datasets dans l’ext4 de WSL ; augmentez les workers du data loader ; shardez les fichiers ; surveillez %iowait et le sm GPU pendant les runs.

7) Symptom: Segfaults aléatoires ou « illegal instruction » après l’installation du toolkit CUDA

• Cause racine : Conflits de bibliothèques entre paquets CUDA de la distro et les libs d’intégration fournies par WSL ; mélange occasionnel de versions de dépôts.
• Correction : Auditez ldconfig -p, retirez les paquets en conflit, évitez d’écraser des libs critiques via LD_LIBRARY_PATH.

8) Symptom: GPU visible, mais manque de mémoire plus tôt que prévu

• Cause racine : Mauvaise lecture de l’utilisation VRAM (caching du framework), ou pression mémoire WSL provoquant des problèmes côté CPU qui ressemblent à des problèmes GPU.
• Correction : Utilisez nvidia-smi pour inspecter la VRAM, et free -h pour inspecter la mémoire/swap hôte ; ajustez la taille de batch et le pipeline mémoire.

Listes de contrôle / plan pas à pas

Checklist A: Base propre pour le calcul GPU dans WSL (centred NVIDIA)

1. Windows : Installez un pilote NVIDIA à jour avec support de calcul WSL. Vérifiez avec nvidia-smi.exe.
2. Windows : Assurez-vous que WSL est à jour : wsl.exe --version doit montrer des composants modernes.
3. WSL : Assurez-vous que votre distro est en WSL2 : wsl.exe -l -v.
4. WSL : Confirmez le périphérique pont GPU : ls -l /dev/dxg.
5. WSL : Confirmez la stack de gestion : nvidia-smi.
6. WSL : Confirmez la résolution des bibliothèques : ldconfig -p | grep libcuda doit pointer vers /usr/lib/wsl/lib.
7. WSL : Exécutez un test de fumée framework (PyTorch/TensorFlow).

Checklist B: Sanity performance pour workloads ML

1. Gardez les datasets sous ext4 de WSL, pas sous /mnt/c. Vérifiez avec df -Th.
2. Pendant l’entraînement, surveillez le GPU : nvidia-smi dmon -s pucm -d 1.
3. Pendant l’entraînement, surveillez l’iowait CPU : mpstat -P ALL 1.
4. Si l’iowait est élevé, benchmez le chemin disque avec dd (ou des outils plus adaptés) et corrigez la disposition des données.
5. Si le CPU est saturé mais iowait bas, réduisez le coût du prétraitement, augmentez les threads/processus workers, et mettez en cache les données décodées.

Checklist C: Chemin Docker (uniquement si nécessaire)

1. Prouvez d’abord que le GPU marche dans WSL sans conteneurs (nvidia-smi et un test framework).
2. Ensuite testez une image base CUDA connue avec docker run --gpus all ... nvidia-smi.
3. Si le conteneur échoue : traitez cela comme un problème d’intégration runtime, pas comme un problème GPU.
4. Epingler la version CUDA de l’image de base au besoin pour correspondre au framework. Evitez « latest » à moins d’aimer l’archéologie.

FAQ

1) Dois-je installer le pilote NVIDIA Linux dans WSL ?

Typiquement, non. Le calcul GPU dans WSL s’appuie sur le pilote Windows et une couche d’intégration WSL.
Installer des pilotes noyau Linux dans WSL est une manière courante de créer des conflits de bibliothèques et une instabilité étrange.

2) Si nvidia-smi.exe fonctionne sous Windows, pourquoi nvidia-smi ne marche-t-il pas dans WSL ?

Parce que « pilote installé » est nécessaire mais pas suffisant. WSL a besoin du périphérique pont GPU (/dev/dxg) et des bibliothèques userland correctes.
Si /usr/lib/wsl/lib est ignoré ou écrasé, les outils WSL peuvent échouer.

3) Quel est le contrôle le plus rapide pour savoir si le GPU est disponible dans WSL ?

Vérifiez ls -l /dev/dxg. S’il est manquant, le chemin de calcul n’est même pas présent.
Ensuite exécutez nvidia-smi en suivi.

4) Pourquoi l’entraînement GPU est-il parfois plus lent dans WSL que sur Linux natif ?

Souvent ce n’est pas le chemin GPU — c’est le stockage et le file I/O. S’entraîner depuis /mnt/c peut être dramatiquement plus lent pour des workloads riches en métadonnées.
Placez les données sur le système de fichiers ext4 de WSL et surveillez l’utilisation GPU.

5) Puis-je utiliser des GPU AMD pour le calcul dans WSL ?

Il existe des options (notamment DirectML pour certains stacks), mais les écosystèmes CUDA reposent majoritairement sur NVIDIA.
Si votre workload dépend des bibliothèques CUDA, prévoyez du matériel et des pilotes NVIDIA.

6) Docker ne voit pas mon GPU dans WSL. Quel est le coupable habituel ?

Intégration runtime GPU pour conteneurs manquante ou mal configurée, ou simplement absence de --gpus all.
Prouvez d’abord que le GPU fonctionne hors Docker, puis déboguez la couche conteneur.

7) Ai-je besoin du toolkit CUDA complet dans WSL pour exécuter PyTorch ou TensorFlow ?

Pas toujours. Beaucoup de distributions de frameworks incluent les bibliothèques userland CUDA nécessaires (ou exigent des versions spécifiques).
Installez le toolkit seulement si vous compilez du code CUDA ou avez une dépendance spécifique qui l’exige.

8) Pourquoi nvidia-smi affiche une version CUDA qui ne correspond pas à mon toolkit ?

La version CUDA affichée dans nvidia-smi reflète la capacité maximale prise en charge par le pilote.
Votre version toolkit/framework CUDA est un composant userland séparé. Le mismatch n’est pas automatiquement une erreur ; c’est l’incompatibilité qui l’est.

9) Le support GPU WSL est-il suffisamment stable pour l’entraînement en production ?

Pour beaucoup d’équipes, oui — en particulier pour les postes développeur et les pipelines CI reproductibles.
Pour « c’est notre seul cluster d’entraînement » vous voudrez encore le contrôle opérationnel d’un serveur Linux natif, mais WSL peut être tout à fait crédible pour de nombreux workflows.

Étapes pratiques suivantes

1. Décidez votre stack cible. Framework-only (plus simple) versus compilation CUDA personnalisée (nécessite le toolkit). Arrêtez de mélanger les objectifs.
2. Prouvez la chaîne dans l’ordre. Pilote Windows → WSL2 → /dev/dxg → nvidia-smi → sonde framework GPU → (facultatif) sonde Docker.
3. Déplacez les données hors de /mnt/c pour l’entraînement. Si vous ne faites rien d’autre pour la performance, faites ceci.
4. Epingler les versions et ajouter un test de fumée. Une vérification automatisée d’une minute vaut mieux qu’une semaine de « mais ça marchait hier » à chaque fois.

Si vous traitez le GPU dans WSL comme un système — avec dépendances, contrats et routine de vérification — il se comportera comme tel.
Si vous le traitez comme un tour de magie, il finira par faire le tour classique : disparaître juste avant votre deadline.