Fare girare un modello di linguaggio grande in locale, sul proprio hardware, è uno di quegli obiettivi che sembrano semplici fino a quando non ci si mette davvero. Poi si scopre che i driver NVIDIA non compilano, il kernel è troppo nuovo, e la GPU che hai in casa appartiene a una generazione che il mondo sta cercando attivamente di dimenticare.
Questo articolo racconta esattamente quello che ho fatto: installare Ollama con un modello Qwen3 da 32B su un nodo del mio cluster Proxmox, usando una GPU NVIDIA Pascal da 8GB in passthrough verso una VM dedicata. Non è filato tutto liscio, e i problemi incontrati sono esattamente quelli che probabilmente troverete anche voi su hardware simile.
📝 Nota a margine: la prima bozza di questo articolo è stata scritta da Qwen3.5:9b — il modello più leggero della stessa famiglia, già in uso sul sistema descritto qui sotto. Circa due minuti dal prompt al testo grezzo. Ho poi revisionato e corretto tutto manualmente. Un workflow interessante di cui parlerò in un articolo dedicato.
1. L'Hardware di Partenza
Il nodo coinvolto è Titan, un server enterprise nel mio cluster Proxmox: processore Xeon, 128GB di RAM, storage su pool SSD dedicato. La GPU è una NVIDIA Quadro P4000, architettura Pascal, 8GB di VRAM. Una scheda che oggi si trova usata a prezzi ragionevoli, ma che ha più di qualche anno sulle spalle — e si sente, quando si tratta di driver.
L'obiettivo era fare il passthrough della P4000 a una VM Ubuntu dedicata, installare Ollama, e caricare un modello abbastanza grande da essere utile. Il modello scelto è Qwen3:32b, nella variante MoE (Mixture of Experts): a differenza dei modelli densi, attiva solo una parte dei parametri a ogni inferenza, il che riduce significativamente il consumo di VRAM rispetto alle dimensioni nominali.
2. Il Primo Ostacolo: il Kernel Proxmox
La versione del kernel attiva sul nodo era 7.0.12-1-pve. Il problema è che i driver NVIDIA serie 580.x — gli ultimi a supportare l'architettura Pascal — non si compilano su kernel Linux 7.x. Le nuove API di VMA locking introdotte nelle versioni recenti del kernel rompono la compilazione dello stack driver legacy NVIDIA. Non è un errore di configurazione: è un'incompatibilità strutturale.
La soluzione è stata fare il pin del kernel a una versione precedente, stabile e compatibile con i driver che servivano:
# Installazione del kernel compatibile
apt install proxmox-kernel-6.17.13-1-pve
# Pin per impedire aggiornamenti automatici
proxmox-boot-tool kernel pin 6.17.13-13-pve
# Hold dei kernel indesiderati
apt-mark hold proxmox-kernel-7.0 proxmox-kernel-6.14Contestualmente, ho blacklistato il driver nouveau in /etc/modprobe.d/blacklist-nouveau.conf, prerequisito obbligatorio prima di installare qualsiasi driver NVIDIA proprietario.
3. Il Secondo Ostacolo: i Repository NVIDIA su Debian Trixie
Risolto il kernel, il problema successivo riguardava i driver stessi sull'host. Il repository CUDA ufficiale per debian12 contiene ancora i driver compatibili con Pascal, ma le firme SHA1 vengono rifiutate dai pacchetti base di Debian Trixie. Al contrario, i driver del repository debian13 supportano solo architetture più recenti (Ampere in poi) e ignorano completamente Pascal.
Il workaround che ha funzionato: scaricare direttamente il runfile dall'archivio NVIDIA e installarlo con il flag --dkms, che garantisce la ricompilazione automatica del modulo a ogni aggiornamento del kernel:
sudo ./NVIDIA-Linux-x86_64-580.159.04.run --dkms
nvidia-smi # verifica: P4000 riconosciuta, CUDA 13.04. La VM e il Passthrough GPU
La scelta di fare il passthrough a una VM dedicata, anziché usare la GPU direttamente sull'host, non è solo per comodità: evita conflitti con altre VM sul nodo e mantiene l'host il più pulito possibile. La VM è configurata con 32GB di RAM, 8 core, storage su pool SSD, e la P4000 mappata come dispositivo PCI primario con interrupt remapping abilitato.
Una volta avviata la VM con Ubuntu Server, l'installazione del driver è banale:
sudo apt update && sudo apt install nvidia-driver-580 cuda-toolkit -y
nvidia-smi # la P4000 appare come 0000:01:00 nella VM5. Ollama, il Modello e Open WebUI
Con la GPU riconosciuta correttamente nella VM, l'installazione di Ollama è immediata tramite lo script ufficiale. Il sistema rileva automaticamente la GPU disponibile e la usa per l'inferenza.
curl -fsSL https://ollama.com/install.sh | sh
OLLAMA_HOST=0.0.0.0:11434 ollama serve &
# Download del modello (circa 20GB)
ollama pull qwen3:32bPer l'interfaccia ho scelto Open WebUI, containerizzato via Docker e reso accessibile dall'esterno tramite reverse proxy con SSL. I WebSocket devono essere abilitati esplicitamente sul proxy: senza di essi, la generazione testuale in streaming si interrompe o non parte affatto.
6. Risultati: Cosa Gira e a Che Velocità
Il modello Qwen3:32b MoE ha un footprint attivo di circa 20GB, distribuito tra la VRAM della P4000 (8GB) e la RAM della VM. Il fatto che sia un modello MoE fa sì che solo una parte dei parametri sia attiva a ogni step di inferenza: la GPU è utilizzata al 25% circa della sua capacità massima teorica, ma è comunque lei a fare il lavoro pesante.
La velocità di generazione ottenuta si attesta intorno ai 3,7 token al secondo. Non è veloce come un'API cloud, ma è più che sufficiente per uso personale e sperimentazione — e soprattutto, gira tutto in locale, senza inviare nulla all'esterno.
| Componente | Versione / Stato | Note |
|---|---|---|
| Kernel Host | 6.17.13-13-pve |
Pinato, stabile dopo reboot |
| Driver NVIDIA (host) | 580.159.04 via .run |
Installato con flag --dkms |
| GPU Passthrough | P4000 8GB → VM | Funzionante, interrupt remapping OK |
| Modello caricato | qwen3:32b MoE |
~20GB, offload parziale su RAM |
| Open WebUI | Docker + Reverse Proxy SSL | WebSocket abilitati, accesso privato |
Conclusioni: Vale la Pena?
Se avete già un server con una GPU Pascal ferma, la risposta è sì. Il percorso è accidentato — pin del kernel, driver via runfile, passthrough da configurare con attenzione — ma una volta in piedi il sistema è stabile e funziona senza sorprese.
Il consiglio principale, se partite da zero su questo tipo di setup: non usate Debian Trixie come base per la VM se volete supporto NVIDIA Pascal senza complicarvi la vita. Ubuntu LTS gestisce questi driver nei propri repository ufficiali, e vi risparmia ore di debug.
Il vero collo di bottiglia rimane la VRAM: 8GB obbligano all'offload di buona parte del modello su RAM, e la velocità di generazione ne risente. Con una GPU di fascia più alta o con più VRAM il quadro cambia radicalmente. Per ora, 3,7 token al secondo per uso interno sono più che accettabili — specialmente considerando che il dato può cambiare una volta completato l'upgrade hardware pianificato.