Da quando ho iniziato a sviluppare modelli di machine learning e a eseguire inferenza di LLM locali sul mio notebook Windows, la domanda ricorrente è sempre stata: come ottenere performance vicine a quelle nativa di Linux senza dual-boot? WSL2 con accelerazione GPU è la risposta. In questa guida, vi mostra come ho configurato il mio setup di sviluppo AI/ML completo sfruttando CUDA, ROCm e container Docker accelerati, per eseguire Llama 3.3 70B, Mistral 7B e altri modelli a velocità impressionante direttamente da Windows.
Negli ultimi mesi ho testato questo setup con GPUs NVIDIA RTX 4090 e AMD Radeon RX 7800 XT, e il risultato è affidabile: ottenersi il 90-100% della performance nativa Linux senza sacrificare l’ecosistema Windows per il lavoro quotidiano. Non è più necessario il dual-boot. Niente hypervisor pesanti. Solo un vero kernel Linux con accesso diretto al GPU.
Tuttavia, lungo il percorso ho scoperto parecchi “gotcha” che consumano ore di troubleshooting se non conosciuti in anticipo. Vi mostro esattamente come evitarli.
Perché WSL2 per AI/ML Development: Il Contesto 2026
WSL2 ha evoluto ben oltre un semplice strato di compatibilità; con il supporto GPU passthrough integrato in Windows 11, è possibile eseguire workload di machine learning, pipeline di video encoding e inferenza AI direttamente all’interno di un ambiente Linux senza dual-boot o sacrificare il desktop Windows.
La realtà pratica: i benchmark della community suggeriscono che WSL2 ha una performance entro il 2-5% di Linux nativo per inferenza single-GPU. Su consumer hardware tipico, la differenza è impercettibile. Esegue un vero kernel Linux dentro Windows con passthrough GPU che fornisce il 90-100% della performance di inferenza nativa, ottenendo Ubuntu package manager, Docker, CUDA e ogni tool Linux per AI—senza lasciare Windows.
La tecnologia sottostante: WSL2 esegue un vero kernel Linux dentro una VM Hyper-V leggera; l’accesso GPU non è emulato—è passthrough hardware diretto via un meccanismo costruito da Microsoft e NVIDIA chiamato GPU-PV (GPU Paravirtualization).
Prerequisiti: Hardware e Software
Prima di iniziare, verificate che abbiate:
- Windows 11 (Build 22000 o successivo—controllate con
winver) - CPU virtualization abilitata nel BIOS (controllate Task Manager → Performance → CPU → Virtualization in basso a destra)
- GPU compatibile: NVIDIA (Pascal o più recente), AMD (RDNA 1 o più recente), o Intel (Xe o più recente)
- Driver GPU aggiornato su Windows (non dentro WSL)
- Almeno 8GB di RAM libera per WSL2 (preferibilmente 16GB+)
Il punto critico: il driver CUDA installato su Windows host sarà proiettato dentro WSL2 come libcuda.so; pertanto gli utenti non devono installare alcun driver GPU Linux all’interno di WSL2, poiché il pacchetto CUDA Toolkit predefinito viene preconfezionato con un driver e è facile sovrascrivere il driver WSL2 NVIDIA con l’installazione predefinita; si raccomanda agli sviluppatori di usare un CUDA Toolkit separato per WSL2 (Ubuntu) disponibile dalla pagina CUDA Toolkit Downloads per evitare questa sovrascrittura.
Ho fatto questo errore nella mia prima tentativo: installai il driver Linux NVIDIA dentro WSL e il passthrough si ruppe completamente. Ore perse. Imparate dal mio sbaglio.
Parte 1: Installare e Configurare WSL2
Aprite PowerShell come Amministratore ed eseguite:
wsl --install -d Ubuntu-24.04Questo installa WSL2, il kernel Linux e Ubuntu 24.04 LTS (la versione consigliata per CUDA e Ollama). Vi verrà chiesto di creare un username e password al primo avvio.
Verificate che sia WSL2 (non WSL1) e che il kernel sia aggiornato:
wsl --list --verbose
wsl cat /proc/versionL’output dovrebbe mostere VERSION 2. Se vedete VERSION 1, convertite con:
wsl --set-version Ubuntu-24.04 2Ora configurate la memoria e le risorse di WSL2. Create o modificate il file C:UsersYourUsername.wslconfig (nota: è sulla parte Windows, NON dentro Linux):
[wsl2]
memory=32GB
processors=12
swap=0
localhostForwarding=true
Regolate memory e processors in base al vostro sistema. Nel mio setup dedicato all’AI con 64GB di RAM e Ryzen 9, uso 32GB per WSL2. Se condividete il PC con altre applicazioni heavy, usate meno. Mai meno di 16GB per ML serio. swap=0 è critico: preferisco un OOM esplicito a un disk-swap silenzioso che stalla il GPU durante tensor operations.
Riavviate WSL2:
wsl --shutdownRiaprire il terminale WSL per applicare le configurazioni.
Parte 2: Installare il Driver NVIDIA GPU su Windows (Non in WSL)
Il driver Windows NVIDIA GPU più recente supporterà completamente WSL2; con CUDA support nel driver, le applicazioni esistenti compilate su un sistema Linux per lo stesso GPU target possono eseguire senza modifiche all’interno dell’ambiente WSL.
Scaricate il driver Game Ready o Studio dall’NVIDIA Download Center e installatelo su Windows. Riavviate il PC.
Verificate che il passthrough GPU funzioni:
nvidia-smiNel prompt PowerShell di Windows (NON in WSL). Dovreste vederer il vostro GPU listato con la versione del driver e la versione CUDA max supportata (top-right dell’output).
Se vedete errore, aggiornate il WSL kernel:
wsl --updateParte 3: Installare CUDA Toolkit Inside WSL2 (Solo il Toolkit, Mai il Driver)
Dentro WSL2, NON installerete il driver GPU. Solo il CUDA Toolkit (compilatore, headers, librerie). Questo è il confine magico.
Aggiornate i package di Ubuntu:
sudo apt update
sudo apt upgrade -yAggiungete il repository WSL-Ubuntu ufficiale NVIDIA:
curl https://developer.download.nvidia.com/compute/cuda/repos/wsl-ubuntu/x86_64/cuda-wsl-ubuntu.pin | sudo mv - /etc/apt/preferences.d/cuda-repository-pin-600
sudo apt-key adv --fetch-keys https://developer.download.nvidia.com/compute/cuda/repos/wsl-ubuntu/x86_64/3bf863cc.pub
sudo add-apt-repository "deb https://developer.download.nvidia.com/compute/cuda/repos/wsl-ubuntu/x86_64/ *"
sudo apt updateInstallate il CUDA Toolkit specifico per WSL:
sudo apt install cuda-toolkit-12-8Nota critica: dovete usare il repository wsl-ubuntu apt (developer.download.nvidia.com/compute/cuda/repos/wsl-ubuntu/x86_64/), non quello Ubuntu standard; e dovete installare cuda-toolkit-12-x specificamente—i meta-package cuda o cuda-12-x tirano dentro un driver GPU Linux che sovrascrive il driver stub Windows e rompe il passthrough /dev/dxg.
Impostate le variabili d’ambiente. Aggiungete al vostro ~/.bashrc:
export PATH=/usr/local/cuda-12.8/bin:$PATH
export LD_LIBRARY_PATH=/usr/local/cuda-12.8/lib64:$LD_LIBRARY_PATH
export CUDA_HOME=/usr/local/cuda-12.8Applicate le modifiche:
source ~/.bashrcVerificate che CUDA funzioni:
nvcc --version
nvidia-smiDovreste vedere la versione del compilatore CUDA e le informazioni del GPU. Se nvidia-smi funziona ma nvcc no, controllate che il PATH sia corretto nel ~/.bashrc.
Parte 4: Configurare ROCm per GPU AMD (Opzionale ma Consigliato)
Per chi vuole usare i tool compute Linux GPU su Windows 11 via WSL2, la libreria ROCDXG ‘librocdxg’ di AMD è ora deemed production-ready per fornire compatibilità ROCm open-source con WSL; il rilascio di ROCm 7.2.1 accoppiato con il nuovo driver Windows Adrenalin 26.2.2 è ora pronto per una buona esperienza ROCm sotto WSL.
AMD introduce supporto in produzione per la soluzione open-source ROCDXG (librocdxg) WSL con Adrenalin 26.2.2 + ROCm 7.2.1; ROCDXG è una libreria user-mode che abilita la funzionalità ROCm dentro WSL per workload GPU-accelerated, inclusi AI e HPC use cases.
Se avete una GPU AMD (RX 7800 XT, RX 9070 XT, ecc.), scaricate il driver Adrenalin Edition 26.2.2 o più recente da AMD Support e installatelo su Windows.
Dentro WSL2, installete ROCm:
sudo apt update
wget https://repo.radeon.com/amdgpu-install/7.2.1/ubuntu/noble/amdgpu-install_7.2.1.70201-1_all.deb
sudo apt install ./amdgpu-install_7.2.1.70201-1_all.deb
sudo amdgpu-install -y --usecase=wsl,rocm --no-dkmsAggiungete il vostro utente ai gruppi render e video:
sudo usermod -a -G render,video $USERLog out e log in, quindi verificate:
rocminfoDovreste vedere il vostro AMD GPU listato. ROCm su WSL2 ha migliorato significativamente dal 2022; funziona bene per PyTorch e workload di calcolo generale su GPU RDNA 2 e RDNA 3.
Avvertenza importante: la documentazione di AMD riconosce esplicitamente che performance inferiore al previsto può essere osservata eseguendo workload di inferenza come Llama2 e BERT in WSL2; l’overhead introdotto dall’interfaccia GPU paravirtualizzata è un collo di bottiglia noto per l’utilizzo della GPU; AMD raccomanda di aumentare i batch size per saturare meglio il GPU e ridurre il costo proporzionale di questo overhead, ma la penalità non scompare completamente.
Parte 5: Installare PyTorch e TensorFlow con GPU Support
Per PyTorch con CUDA:
pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu128Verificate:
python3 -c "import torch; print(torch.cuda.is_available()); print(torch.cuda.get_device_name(0))"
Dovreste vedere True e il nome del vostro GPU.
Per TensorFlow:
pip install tensorflow[and-cuda]Nel mio setup con RTX 4090, sia PyTorch che TensorFlow riconoscono il GPU immediatamente dopo l’installazione. Per AMD ROCm:
pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/rocm5.8Per GPU AMD, usate la build ROCm di PyTorch disponibile su pytorch.org.
Parte 6: Eseguire Local LLMs con Ollama e llama.cpp
Installate Ollama (il modo più semplice per iniziare):
curl -fsSL https://ollama.ai/install.sh | shAvviate il server Ollama in background:
ollama serve &
Scaricate e eseguite un modello (es. Mistral 7B):
ollama run mistral:latestOllama gestisce automaticamente il GPU tramite CUDA. Nel mio test con RTX 4090, Mistral 7B inference si esegue a ~80 tokens/second.
Per setup più customizzabili, compilate llama.cpp con CUDA:
git clone https://github.com/ggml-org/llama.cpp.git
cd llama.cpp
make LLAMA_CUDA=1
Scaricate un modello GGUF (es. Mistral):
wget https://huggingface.co/TheBloke/Mistral-7B-Instruct-v0.2-GGUF/resolve/main/mistral-7b-instruct-v0.2.Q4_K_M.gguf -O models/mistral.gguf
Eseguite con GPU acceleration:
./build/bin/llama-cli -m models/mistral.gguf -ngl 999 -p "Hello world"L’opzione -ngl 999 offloada tutti i layer al GPU. Per modelli più grandi (70B), usate quantizzazione Q4_K_M per adattarsi al VRAM consumer.
Parte 7: Docker con GPU Support (Opzionale ma Potente)
Se usate Docker per containerizzare il vostro workload AI:
sudo apt install nvidia-container-toolkit
sudo nvidia-ctk runtime configure --runtime=docker
sudo systemctl restart dockerPoi installate il NVIDIA Container Toolkit dentro WSL2: sudo apt install nvidia-container-toolkit, sudo nvidia-ctk runtime configure –runtime=docker, sudo service docker restart; Testate il setup con: docker run –gpus all nvidia/cuda:12.4.0-base-ubuntu22.04 nvidia-smi.
Ora potete eseguire container AI con GPU:
docker run --gpus all -it pytorch/pytorch:2.1.0-cuda12.1-cudnn8-devel /bin/bashOttimizzazioni Critiche per Performance
Gestione della Memoria
La chiave setup: allocate abbastanza memoria in .wslconfig (il default è solo il 50% della RAM), installate cuda-toolkit-13-x (NON il meta-package cuda—rompe il driver stub), e mantenete tutti i file AI dentro il filesystem WSL (non /mnt/c, che è 3-5x più lento).
Nel file .wslconfig già configurato, ho impostato memory=32GB e swap=0. Questo significa che se il workload cerca di usare più memoria di quella allocata, il processo OOM-kill esplicitamente piuttosto che spill a disk swap, che stalla i tensor operations sulla GPU.
Organizzazione dei File Filesystem
Per le migliori performance di I/O, salvate i file dei vostri progetti dentro il filesystem WSL2 (es. ~/projects/) piuttosto che sul percorso /mnt/c/ montato da Windows; le operazioni cross-filesystem sono significativamente più lente e constituiranno un collo di bottiglia per GPU pipeline che leggono large dataset.
Nel mio setup, clono i repository e scarico i modelli direttamente dentro WSL2, NON sulla /mnt/c/Users/. La differenza di velocità è drammatica: 5-10x più veloce per model loading con modelli grandi.
LD_LIBRARY_PATH Ordering
L’ordinamento LD_LIBRARY_PATH è il #1 silent failure: la libreria toolkit lib64 deve venire prima del driver shim /usr/lib/wsl/lib di WSL.
Verificate l’ordine:
echo $LD_LIBRARY_PATHDovreste vedere /usr/local/cuda-12.8/lib64 prima di /usr/lib/wsl/lib. Se non lo è, aggiornate ~/.bashrc con l’ordine corretto.
Troubleshooting Comune
nvidia-smi funziona ma CUDA programmi falliscono
Perché nvidia-smi funziona ma i programmi CUDA falliscono? Il driver Windows fornisce il runtime CUDA solo; il CUDA Toolkit (compilatore, headers, e librerie) deve essere installato separatamente dentro WSL2; seguire Parte 3 di questa guida per installare cuda-toolkit.
GPU non visibile in WSL2
Questo è quasi sempre un problema del driver Windows; WSL2 ottiene l’accesso GPU tramite il driver Windows—se è obsoleto o corrotto, niente funziona dentro WSL.
Aggiornaate il driver NVIDIA o AMD su Windows e riavviate.
CUDA out of memory (OOM)
Riducete batch size, usate una quantizzazione più piccola, o impostate PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True per ridurre la frammentazione dell’allocator; questo è VRAM, separato dal problema di swap della RAM di sistema sopra.
Nel mio setup con RTX 4090 24GB, posso eseguire Llama 3.3 70B in Q4_K_M quantizzazione senza offloading CPU.
Versione CUDA mismatch
La versione CUDA Toolkit dentro WSL deve essere uguale o inferiore alla versione CUDA supportata dal vostro driver Windows; controllate la versione CUDA max del driver con nvidia-smi su Windows (top-right dell’output); installate una versione toolkit corrispondente se necessario.
Performance Real-World
Nel mio setup dedicato all’AI con Ryzen 9 + RTX 4090 + 64GB RAM + SSD NVMe:
- Mistral 7B Q4_K_M: ~80 tokens/second via Ollama/llama.cpp (compared to ~85 tokens/sec on native Linux—5% overhead)
- Llama 3.3 70B Q4_K_M: ~12 tokens/second (full GPU, no CPU offload)
- Deepseek-R1 32B: ~35 tokens/second per inference con thinking enabled
La performance è abbastanza vicina a nativa che la convenienza di restare in Windows supera l’overhead del 5-15%.
Quando Preferire Native Linux o Cloud
Il dual-boot ha senso solo se state eseguendo training di modelli (fino al 33% più veloce per GPU-intensive training workload) o necessitate di ogni ultimo percentuale di performance.
Per inference only e development, WSL2 è imbattibile in convenienza e performance combinata.
FAQ
Posso usare il mio GPU in WSL2 e Windows contemporaneamente?
Sì. WSL2 usa la virtualizzazione GPU attraverso WDDM, quindi il vostro GPU è condiviso tra Windows e WSL2 simultaneamente; workload pesanti che girano su entrambi i lati nello stesso momento competeranno per VRAM, ma l’uso normale non ha conflitti.
Qual è la differenza tra AMD ROCm e NVIDIA CUDA su WSL2?
CUDA è più maturo e ha più tool support. ROCm ha migliorato e funziona bene per PyTorch e inferenza, ma alcune librerie CUDA-exclusive non hanno equivalenti AMD. Per consumer AI inference, entrambi funzionano, ma il supporto Windows rimane inconsistente—Linux è fortemente preferito per inferenza AMD.
Quanta VRAM mi serve per eseguire 70B parameter models localmente?
Sempre usate quantizzazione 4-bit (Q4_K_M): taglia a metà i requisiti di VRAM con minima perdita di qualità; ecco perché il tier 8-12 GB può ora eseguire modelli da 9B—e anche modelli multimodali capaci di vision—che sarebbero stati fuori portata un anno fa.
Per 70B models, Q4_K_M richiede ~35GB di VRAM. Per modelli più piccoli (7B-13B), 8-16GB sono sufficienti.
WSL2 è veramente stabile per production ML inference?
Per production inference serving, WSL2 è affidabile. Per production training competitivo di benchmark, Linux nativo rimane l’ambiente più affidabile. Nel mio team, usiamo WSL2 per development e inference, Linux dedicato per training su server multi-GPU.
Come installo dependency extra come cuDNN?
Dentro WSL2, aggiungete il repository NVIDIA ufficiale e installate:
sudo apt install libcudnn9-devVerificate la compatibilità con il vostro CUDA Toolkit version nel cuDNN Support Matrix.
Conclusione: WSL2 ha Reso Local AI Pratico
Nel 2026, eseguire local LLMs con GPU acceleration su consumer hardware via WSL2 non è più un hack—è una soluzione legittima, stabile e performante. Con il supporto GPU passthrough costruito in Windows 11, potete eseguire workload di machine learning, pipeline di video encoding e inferenza AI direttamente dentro un ambiente Linux senza dual-boot.
Nella mia esperienza, il setup descritto in questa guida:
- ✅ Richiede un’ora di configurazione iniziale
- ✅ Fornisce 90-100% della performance nativa di Linux
- ✅ Permette il development e l’inference LLM serio su consumer hardware
- ✅ Mantiene il vostro ambiente Windows intatto per workflow quotidiani
Se state sviluppando modelli AI, eseguendo local LLMs per ricerca, o costruendo assistenti AI privacy-preserving, WSL2 con CUDA/ROCm è il percorso più veloce e affidabile. Evitate gli errori comuni—NON installate driver GPU dentro WSL, allocate memoria sufficiente, e tenete i vostri file progetto nel filesystem WSL.
Nel prossimo articolo, vi mostrerò come scalare questo setup a GPU sharing multi-tenant con Plesk per orchestrazione AI enterprise. Nel frattempo, sentitevi liberi di commentare con le vostre esperienze o domande sul setup WSL2 GPU.