Com habilitar la GPU a WSL2 per a ML i CUDA pas a pas

Si treballes amb machine learning, deep learning o ciència de dades a Windows, segurament t'has plantejat més d'una vegada si val la pena muntar un Linux a part o estirar el núvol. Amb el suport oficial de GPU a WSL2 ja no cal complicar-se tant: pots tenir un entorn Linux real accelerat per CUDA directament al teu PC amb Windows.

En aquesta guia veurem, pas a pas, com habilitar la GPU a WSL2 per a ML i CUDA , què necessites a nivell de sistema, com instal·lar els controladors correctes, com preparar Ubuntu (o una altra distro), com integrar CUDA, cuDNN, Docker, TensorFlow, PyTorch i DirectML, i com resoldre els problemes.

Arquitectura: com funciona la GPU dins de WSL2

WSL2 executa un nucli de Linux real dins d'una màquina virtual lleugera que gestiona el mateix Windows. No és una emulació cutre: és Linux de veritat, amb el vostre nucli i el seu espai d'usuari, però extremadament integrat amb el sistema amfitrió.

Per aprofitar la GPU des d'aquest nucli, NVIDIA (i Microsoft) han desenvolupat un stack específic que exposa la GPU de l'amfitrió Windows a WSL2 . Des del punt de vista de Linux, el que apareix és la clàssica interfície de CUDA via libcuda.so , cosa que permet que el programari pensi que està en un Linux “natiu”.

Gràcies a aquesta capa, dins de WSL2 pots fer servir nvidia-smi, nvcc, el CUDA Toolkit, cuDNN i pràcticament qualsevol framework de ML compatible amb CUDA (PyTorch, TensorFlow, etc.) sense necessitat de muntar una màquina virtual pesada ni dependre sempre del núvol.

A més, aquesta integració s'estén a Docker i NVIDIA Container Toolkit , així que pots executar contenidors GPU-enabled igual que ho faries en un servidor Linux dedicat: per exemple, imatges oficials de NVIDIA NGC per a TensorFlow, PyTorch o altres frameworks d'IA.

A la part de gràfics, amb WSLg, també es pot controlar quin GPU es fa servir per a les aplicacions amb interfície gràfica de Linux, cosa molt útil si el teu equip té una iGPU Intel o GPU integrada AMD i una NVIDIA dedicada i vols que el treball pesat vagi a la NVIDIA.

Requisits de Windows, GPU i versions necessàries

Perquè tot això funcioni, el primer filtre és el sistema operatiu: necessites Windows 11 o Windows 10 a partir de la versió 21H2 . Versions anteriors no tenen suport madur (o directament no en tenen) per a GPU a WSL2.

A nivell de maquinari, cal una GPU moderna amb drivers actualitzats . Per a CUDA pur necessitaràs una GPU NVIDIA compatible (idealment una sèrie RTX recent), però també pots recolzar-te a DirectML si el teu GPU és AMD o Intel, o fins i tot si prefereixes utilitzar frameworks adaptats a DirectML sobre una NVIDIA.

A més, WSL2 ha d'executar un nucli prou recent. Per a les característiques de GPU, cal una versió de nucli 5.10.43.3 o superior . Pots comprovar-ho des de PowerShell amb:

wsl cat /proc/version

Si esteu just muntant l'entorn des de zero en un Windows actualitzat, el més normal és que ja tingueu una versió compatible, però convé verificar-ho per si el vostre equip porta temps sense rebre updates o si has tocat la configuració de WSL a mà.

Instal·lar i actualitzar WSL2 amb una distribució Linux adequada

Abans d'entrar a drivers i CUDA, cal assegurar-se que WSL2 està instal·lat i configurat correctament . El recomanat per a desenvolupaments de ML és fer servir una distribució basada en glibc, com Ubuntu o Debian, per la seva compatibilitat amb repositoris i paquets de NVIDIA.

Des del PowerShell amb permisos d'administrador, podeu habilitar WSL i el component necessari per a WSL2 amb les ordres adequades del Windows. En versions modernes de Windows 10/11, el flux més directe és fer servir wsl –install i especificar la distribució, per exemple:

wsl –install -d Ubuntu-22.04

Quan finalitzi la instal·lació, veuràs la nova app d'Ubuntu al menú Inici. En obrir-la per primer cop, s'iniciarà la configuració bàsica (usuari, contrasenya, etc.). El següent pas essencial és actualitzar la memòria cau de paquets i el sistema dins d'aquesta distro:

sudo apt update && sudo apt -y upgrade

A més, convé assegurar-se que el mateix WSL està usant el nucli més recent disponible a Windows. Des de PowerShell, executa:

wsl –actualització

Aquesta combinació de passos et deixa amb un Ubuntu actualitzat sobre WSL2 , perfecte com a base per a instal·lacions de CUDA, frameworks de ML o fins i tot Docker.

Instal·lació del driver NVIDIA amb suport CUDA per a WSL2

La part crítica per utilitzar la GPU amb CUDA a WSL2 és el driver de NVIDIA instal·lat a Windows , no dins de Linux. Aquí molta gent s'embolica pensant que ha d'instal·lar també el driver dins de la distro, però per a WSL2 no és necessari.

Has de descarregar el controlador habilitat per a CUDA i WSL des de la pàgina oficial de NVIDIA dedicada a WSL (o des del cercador general de drivers, seleccionant el teu GPU i sistema). És important no quedar-se amb un driver antic: el suport de WSL2 i GPU ha anat rebent millores substancials.

Un cop instal·lat el driver a Windows, pots verificar que el sistema veu correctament la GPU i el driver des de PowerShell. Executeu una ordre que mostri la informació de l'adaptador, o simplement obre el Tauler de control de NVIDIA i comprova la versió. Des de WSL, quan tot està bé, nvidia-smi tornarà el llistat de dispositius CUDA disponibles.

En escenaris de servidor (per exemple, Windows Server amb WSL2), el flux és similar: primer instal·les WSL i la distro Linux, i després el driver NVIDIA per a Windows Server . A continuació, a la part Linux instal·les únicament el CUDA Toolkit i les llibreries necessàries, sense drivers addicionals de GPU dins del kernel de WSL.

Instal·lació de CUDA Toolkit, cuDNN i eines base dins de WSL2

Amb WSL i el driver NVIDIA llestos, toca configurar lentorn de desenvolupament dins de Linux. L'objectiu és tenir instal·lats el CUDA Toolkit, cuDNN i les eines bàsiques de Python per poder compilar, executar exemples i treballar còmodament amb frameworks de ML.

Hi ha dos enfocaments: utilitzar els repositoris oficials de NVIDIA per a WSL/Ubuntu o estirar el paquet nvidia-cuda-toolkit del teu distro. El més recomanable per a fluxos de treball moderns és afegir els repos de NVIDIA específics per a la teva distribució, ja que solen estar més actualitzats que els paquets genèrics.

Des del teu terminal d'Ubuntu a WSL2 pots afegir els repos i, a continuació, instal·lar CUDA. Un enfocament alternatiu, més simple en alguns entorns, és:

sudo apt -i install python3-pip nvidia-cuda-toolkit

Si utilitzeu aquest paquet, assegureu-vos que la versió de CUDA que instal·leu és compatible amb les versions de PyTorch o TensorFlow que teniu previst utilitzar. Un cop instal·lat, convé incloure la ruta als binaris de CUDA a la teva variable PATH , editant per exemple el fitxer ~/.bashrc i afegint una línia tipus:

export PATH=/home/usuari/.local/bin${PATH:+:${PATH}}

Després de desar i tancar, només cal obrir una nova sessió de terminal o executar source ~/.bashrc perquè els canvis tinguin efecte. Des d'aquí ja podràs fer servir eines com nvcc o executar scripts d'exemple que facin servir CUDA.

Ús de Docker i NVIDIA Container Toolkit a WSL2

En molts fluxos de ML, sobretot en empreses o projectes grans, és habitual encapsular-ho tot en contenidors. Per aprofitar la GPU des de Docker dins de WSL2, necessites que el motor Docker tingui accés a la GPU a través de NVIDIA Container Toolkit.

Hi ha dues opcions principals: instal·lar Docker Desktop a Windows i usar la seva integració amb WSL2, o bé instal·lar directament el motor de Docker a la distro Linux dins de WSL. En el segon cas, ho pots fer amb:

curl https://get.docker.com | sh
Inici del servei sudo docker

Un cop instal·lat Docker, toca configurar el dipòsit estable de NVIDIA Container Toolkit. Per a Ubuntu dins de WSL pots seguir la seqüència típica: definir la variable de distribució a partir de /etc/os-release, afegir la clau GPG i el llistat de repositoris de NVIDIA per a nvidia-docker.

Després instal·les el paquet necessari amb:

sudo apt-get update
sudo apt-get install -i nvidia-docker2

Amb això en marxa podeu llançar contenidors que vegin la GPU usant l'opció –gpus . Per exemple, per a un contenidor oficial de TensorFlow a NGC:

docker run –gpus all -it –shm-size=1g –ulimit memlock=-1 –ulimit stack=67108864 nvcr.io/nvidia/tensorflow:20.03-tf2-py3

Dins aquest contenidor, molts exemples ja vénen preparats. Per exemple, podeu anar als exemples CNN de NVIDIA i executar un ResNet entrenat prèviament:

cd nvidia-examples/cnn/python
resnet.py –batch_size=64

En entorns de servidor amb múltiples GPUs, també podeu provar contenidors d'exemple com el clàssic nbody de CUDA per verificar que totes les targetes responen correctament a través de Docker:

docker run –rm -it –gpus=all nvcr.io/nvidia/k8s/cuda-sample:nbody nbody -gpu -benchmark -numdevices=5

TensorFlow, PyTorch i DirectML a WSL2

WSL2 no es limita a CUDA pur: també permet aprofitar TensorFlow-DirectML i PyTorch-DirectML , una cosa especialment interessant si el teu GPU és AMD o Intel, o si vols treure partit a DirectML fins i tot amb una NVIDIA.

El punt de partida és el mateix: driver actualitzat del proveïdor de la GPU instal·lat a Windows, ja sigui AMD, Intel o NVIDIA. A partir d'aquí creeu un entorn de Python virtual dins del vostre distro Linux. Una opció habitual és fer servir Miniconda:

wget https://repo.anaconda.com/miniconda/Miniconda3-latest-Linux-x86_64.sh
bash Miniconda3-latest-Linux-x86_64.sh
comta create –name directml python=3.7 -y
comta activate directml

Amb l'entorn activat, instal·les el framework que t'interessi. Per TensorFlow-DirectML :

pip install tensorflow-directml

I per a PyTorch-DirectML , primer cobreixes algunes dependències bàsiques de BLAS i LAPACK, i després instal·les el paquet corresponent:

sudo apt install libblas3 libomp5 liblapack3
pip install torch-directml

Per comprovar que tot funciona, podeu obrir una sessió de Python i intentar una operació simple (per exemple, una suma de tensors) i verificar que no es produeixen errors i que es detecta l'acceleració de DirectML a la sortida del framework.

Instal·lació de PyTorch amb suport CUDA a WSL2

Si el teu objectiu és fer servir PyTorch amb CUDA “de tota la vida” sobre una GPU NVIDIA, el més còmode és instal·lar la versió preparada específicament per a una versió concreta de CUDA, per exemple, CUDA 11.8 . PyTorch proporciona índexs específics per a rodes compatibles.

Quan tens Python i pip o un entorn Comta llest, pots executar alguna cosa com:

pip3 install torch torchvision torchaudio –index-url https://download.pytorch.org/whl/cu118

Per verificar que PyTorch veu correctament la GPU, entra a la consola interactiva de Python dins de WSL2 i executa:

torxa d'importació
torch.cuda.device_count()
torch.cuda.is_available()

La primera ordre importa PyTorch, la segona t'indica quants dispositius compatibles amb CUDA detecta el sistema, i el tercer et torna un True si la GPU està disponible per al framework. Si alguna cosa falla, el més habitual és revisar drivers, versió de CUDA i si WSL està actualitzat.

En entorns amb multi-GPU, des de PyTorch també pots restringir l'ús a certes targetes usant variables d'entorn com CUDA_VISIBLE_DEVICES o APIs específiques de selecció de dispositiu, cosa útil quan comparteixes l'equip amb més processos o usuaris.

TensorFlow amb CUDA a WSL2 i flux de ML complet

TensorFlow també pot aprofitar la GPU a WSL2 via CUDA, especialment quan el combines amb imatges de Docker de NVIDIA o amb instal·lacions cuidades des dels repos de CUDA i cuDNN. El flux habitual inclou:

1) Instal·lar el driver de NVIDIA amb suport per a CUDA a Windows, com ja hem comentat, assegurant que la versió és compatible amb la release de TensorFlow que utilitzaràs.
2) Configurar a WSL2 el CUDA Toolkit i cuDNN seguint la guia oficial de NVIDIA CUDA a WSL.
3) Opcionalment, fer servir una imatge NGC de TensorFlow amb suport GPU, que ja ve ajustada amb les versions correctes de CUDA/cuDNN, evitant el ball de llibreries.

Quan el teu entorn reconeix la GPU (ho pots comprovar amb nvidia-smi des de WSL2), pots entrenar models intensius directament des de Linux a Windows, sense màquines virtuals completes ni necessitat de pujar tot al núvol. El més normal és combinar això amb VS Code Remote – WSL i Jupyter per treballar en notebooks còmodament.

Per als que comencen, una bona forma d'agafar soltesa és provar exemples simples de xarxes neuronals, monitoritzar el consum a nvidia-smi i experimentar amb la mida de batch, nombre de capes o precisió (FP16/FP32) per veure com varia la càrrega de la GPU.

Verificació d'accés a la GPU i monitorització

Verificar que tot està ben configurat és clau abans de llençar-se a entrenar models grans. Des de WSL2, l'ordre estrella és nvidia-smi , que hauria de mostrar la llista de GPU, memòria total i usada, procés que consumeix GPU, temperatura, etc.

Si la comanda torna un missatge tipus “No devices were found”, sol ser indici que el driver de Windows no està ben instal·lat o WSL no està actualitzat . En molts casos se soluciona amb:

wsl –shutdown

i tornant a obrir la distribució perquè es recarregui l'entorn, o bé actualitzant drivers i reiniciant el sistema. També hi ha eines addicionals com gpustat que donen un resum més amigable de la càrrega de les GPUs.

Durant entrenaments llargs, convé deixar una consola a part amb nvidia-smi o scripts de monitoratge per vigilar temperatura, consum de memòria i utilització . Això ajuda a detectar colls d'ampolla (per exemple, quedar-te curt de VRAM) o problemes de rendiment per configuració deficient.

Selecció de GPU en equips amb diverses targetes (NVIDIA, AMD, iGPU)

En portàtils i sobretaules moderns és freqüent tenir diverses GPUs: per exemple, una iGPU Intel o xip AMD integrat i una NVIDIA dedicada . Des de WSL2, especialment amb WSLg per a apps gràfiques, és important poder triar quina es fa servir.

Microsoft documenta mecanismes per seleccionar la GPU a WSLg, i usuaris que s'han vist en la situació que la seva aplicació tirava de la iGPU han resolt el problema seguint la guia oficial de selecció de GPU a WSLg disponible al repositori de GitHub de microsoft/wslg.

A més, per a entorns on es recolza DirectML a diverses GPUs, es pot escollir un dispositiu concret mitjançant la variable d'entorn:

export MESA_D3D12_DEFAULT_ADAPTER_NAME=» »

Aquesta variable fa una coincidència de cadena amb els noms dels adaptadors, per la qual cosa si poseu alguna cosa com «NVIDIA» , seleccioneu la primera GPU el nom del qual comenci per NVIDIA. És un truc útil quan el sistema tria per defecte la GPU equivocada (per exemple, prioritzant una AMD integrada davant d'una NVIDIA dedicada per a certes càrregues de ML).

En casos especialment punyeters (per exemple, en utilitzar FAISS o altres components dins de frameworks com LangChain o Ollama), pot ser que vegis que s'enganxa a la GPU equivocada fins i tot quan NVIDIA està visible a WSL. Aquí sol tocar combinar la configuració de WSLg, la variable d'entorn anterior i ajustaments específics de cada llibreria per forçar el dispositiu correcte.

Bones pràctiques i resolució de problemes freqüents

Quan tot està funcionant, hi ha algunes bones pràctiques que marquen la diferència en comoditat i rendiment del dia a dia. La primera és treballar sempre amb entorns virtuals de Python o comta, i activar-los abans de llançar qualsevol entrenament:

source ~/.venvs/ml/bin/activate (o l'ordre equivalent a la teva configuració)

Mantenir un fitxer requirements.txt actualitzat amb les dependències clau (per exemple, usant pip freeze > requirements.txt ) facilita reconstruir l'entorn en una altra màquina o després d'un formatatge sense mals de cap.

Una altra recomanació important és evitar treballar directament a /mnt/c/ per a dades d'entrenament o projectes grans. El rendiment de disc sol ser molt millor si utilitzes l'home de Linux a WSL (per exemple, ~/projectes_ml ), sobretot quan treballes amb molts fitxers o grans volums de dades.

Per a desenvolupament interactiu, VS Code amb l'extensió Remote – WSL i suport per a Jupyter ofereix una experiència molt còmoda: edites a Windows, executes a Linux amb GPU, i tot queda força integrat. A més, pots fer servir eines com tmux o screen per deixar entrenaments corrent en segon pla encara que tanquis la finestra de la terminal.

Si comparteixes la màquina o tens processos pesats en paral·lel, pot interessar-te ajustar límits de recursos al fitxer .wslconfig de Windows (per exemple, RAM i nombre de cors que WSL2 pot utilitzar), i controlar manualment en quins moments llances entrenaments grossos per no col·lapsar l'equip.

Quant al troubleshooting, les fallades més típiques inclouen que nvidia-smi no detecti la GPU (driver incorrecte o WSL desactualitzat), incompatibilitats entre versions de CUDA i els frameworks (PyTorch/TensorFlow) i instal·lacions de CUDA directament des de la web sense seguir els reps i guia. En general, és millor recolzar-se en els repos i documentació específica per a WSL que en instal·lacions genèriques.

Amb tots aquests elements ben configurats —Windows 11 o 10 modern, WSL2 actualitzat, drivers de GPU correctes, CUDA/cuDNN a la distro, Docker i/o DirectML segons el cas— pots tenir al teu propi portàtil o sobretaula un entorn Linux d'alt rendiment per a IA i ML sense renunciar a la comoditat de Windows. És una solució híbrida molt potent que, ben afinada, us permet entrenar models complexos, prototipar fluxos de treball i depurar codi de forma àgil sense dependre tant de màquines virtuals pesades o del núvol.