Proxmox GPU Passthrough: Guida Passo per Passo per l'AI

Punti Chiave

• Ci sono due modi per dare una GPU a un ospite Proxmox: il passthrough PCIe a una VM (esclusivo, driver gestito dalla VM) o la condivisione del dispositivo con i container LXC (più container, un solo driver sull’host).
• Il passthrough richiede IOMMU (Intel VT-d o AMD-Vi) attivo nel firmware e nella riga di comando del kernel, la GPU in un gruppo IOMMU pulito e la scheda assegnata a vfio-pci prima che un driver dell’host la prenda.
• La VM deve usare la macchina q35 con firmware OVMF (UEFI); dentro si installa il normale driver NVIDIA e si verifica con nvidia-smi.
• Per transcodifica video, archivi foto o riconoscimento nelle telecamere, condividere una GPU integrata con un container è più semplice e di solito basta. Per gli LLM in locale conta la VRAM, quindi serve una scheda dedicata.

Passthrough o condivisione: scegli prima la strada giusta

Quasi tutte le guide partono subito da vfio-pci. Prima di toccare il kernel conviene decidere a cosa serve la GPU, perché Proxmox offre due meccanismi diversi.

	Passthrough PCIe a una VM	Condivisione con LXC
Chi usa la GPU	Una sola VM, in esclusiva	Quanti container vuoi
Il driver sta	Nella VM	Sull’host Proxmox
L’host può ancora usarla	No	Sì
Lavoro di configurazione	IOMMU, vfio, firmware della VM	Una riga dev per container
Uso tipico	Ollama, CUDA, training, VM Windows da gioco	Jellyfin, Immich, Frigate, inferenza leggera

Se vuoi un server LLM con il suo stack CUDA, o un sistema ospite che non è Linux, usa il passthrough. Se vuoi che più servizi Linux usino la decodifica video hardware o OpenVINO, condividi il dispositivo con i container. Qui sotto trovi entrambe le strade.

Cosa uso io: condivisione, non passthrough

Il mio Proxmox di casa è una macchina piccola con un Intel Core i7 di undicesima generazione e la sua grafica integrata Iris Xe, senza scheda dedicata. IOMMU è spento, perché lì non serve: la GPU integrata non è passata a una VM, è condivisa con il container che gestisce l’archivio delle foto, così transcodifica video e lavori di machine learning possono girare sulla GPU invece che sulla CPU.

Tutta la modifica è una riga nella configurazione del container:

# /etc/pve/lxc/<id>.conf
dev0: /dev/dri/renderD128,mode=0666

Quella macchina però non è adatta a LLM seri in locale. Una GPU integrata usa la memoria di sistema e ha molta meno banda di quella che serve a un modello. Se l’obiettivo è l’inferenza in locale, metti in conto una scheda NVIDIA dedicata e la strada della VM descritta qui sotto.

Prerequisiti per il passthrough PCIe

• CPU e scheda madre con IOMMU: Intel VT-d o AMD-Vi (sulle schede AMD spesso si chiama “IOMMU” o “SVM + IOMMU”).
• Impostazioni del firmware: attiva VT-d / IOMMU, e anche Above 4G Decoding e Resizable BAR se la scheda madre li ha (servono alle schede con molta memoria).
• Una GPU che non sia l’unico schermo dell’host: se passi la scheda che fa da console, perdi l’uscita video locale. Su un server senza monitor va benissimo: lo gestisci dall’interfaccia web e via SSH.
• Proxmox VE recente (8.x o 9.x) e un backup della configurazione dell’host prima di iniziare.

Passo 1: attivare IOMMU nella riga di comando del kernel

I kernel recenti di Proxmox attivano IOMMU di default sui processori Intel, e su AMD è attivo da anni, ma conviene renderlo esplicito per sapere dove è impostato. iommu=pt lascia sulla strada veloce i dispositivi che non passi alle VM.

Controlla quale bootloader usi:

proxmox-boot-tool status

Se risulta GRUB (il default con installazioni ext4/LVM), modifica /etc/default/grub:

GRUB_CMDLINE_LINUX_DEFAULT="quiet intel_iommu=on iommu=pt"   # Intel
# GRUB_CMDLINE_LINUX_DEFAULT="quiet iommu=pt"               # AMD
update-grub

Se risulta systemd-boot (frequente con ZFS su UEFI), la riga di comando sta in /etc/kernel/cmdline, su una sola riga:

root=ZFS=rpool/ROOT/pve-1 boot=zfs intel_iommu=on iommu=pt
proxmox-boot-tool refresh

Riavvia e verifica:

dmesg | grep -e DMAR -e IOMMU | head
cat /proc/cmdline

Devi vedere righe come DMAR: IOMMU enabled (Intel) o AMD-Vi: ... enabled e i tuoi parametri in /proc/cmdline.

Passo 2: caricare i moduli vfio

Aggiungi queste righe a /etc/modules perché vengano caricati all’avvio:

vfio
vfio_iommu_type1
vfio_pci

Dal kernel 6.2 in poi vfio_virqfd fa parte di vfio, quindi puoi ignorare le guide vecchie che lo elencano.

Passo 3: controllare i gruppi IOMMU

Il passthrough funziona per gruppo IOMMU: tutto quello che sta nel gruppo va alla VM insieme. Stampa i gruppi:

for d in /sys/kernel/iommu_groups/*/devices/*; do
  g=${d#*/iommu_groups/}; g=${g%%/*}
  printf 'group %s  ' "$g"; lspci -nns "${d##*/}"
done | sort -V

Il risultato ideale è un gruppo che contiene solo la GPU e la sua parte audio, per esempio:

group 14  01:00.0 VGA compatible controller [0300]: NVIDIA ... [10de:2684]
group 14  01:00.1 Audio device [0403]: NVIDIA ... [10de:22ba]

Se la GPU condivide il gruppo con un controller SATA o una scheda di rete, prova prima un altro slot PCIe: quelli collegati direttamente alla CPU di solito hanno gruppi più puliti. L’opzione del kernel pcie_acs_override può dividere i gruppi, ma indebolisce proprio l’isolamento per cui esiste IOMMU: usala solo come ultima risorsa, su una macchina di cui ti fidi.

Passo 4: assegnare la GPU a vfio-pci

Annota gli ID produttore e dispositivo di ogni funzione della scheda (i numeri tra parentesi quadre qui sopra), poi crea /etc/modprobe.d/vfio.conf:

options vfio-pci ids=10de:2684,10de:22ba disable_vga=1
softdep nouveau pre: vfio-pci
softdep nvidia pre: vfio-pci
softdep snd_hda_intel pre: vfio-pci

Le righe softdep fanno in modo che vfio-pci prenda la scheda prima del driver video o audio dell’host. Sono più sicure che mettere in blacklist snd_hda_intel, che toglierebbe l’audio anche all’host.

Ricostruisci l’initramfs e riavvia:

update-initramfs -u -k all
reboot

Poi verifica che la scheda sia gestita da vfio:

lspci -nnk -s 01:00
# Kernel driver in use: vfio-pci   <- per entrambe le funzioni

Passo 5: creare la VM

Crea una VM con queste impostazioni (da interfaccia web o da riga di comando):

• Machine: q35
• BIOS: OVMF (UEFI), con un disco EFI
• Tipo di CPU: host
• Memoria: dimensione fissa. Una VM con un dispositivo in passthrough blocca tutta la sua RAM, quindi il ballooning non serve a niente: imposta il balloon a 0.
• Dispositivo PCI: Hardware → Add → PCI Device → Raw Device → la tua GPU, con All Functions e PCI-Express spuntati. Spunta Primary GPU solo se la scheda deve gestire lo schermo della VM.

Lo stesso da shell, per la VM 120:

qm set 120 --machine q35 --bios ovmf --cpu host --balloon 0
qm set 120 --hostpci0 0000:01:00,pcie=1

Usare 0000:01:00 senza il numero di funzione passa tutte le funzioni della scheda insieme.

Passo 6: driver e primo test dentro la VM

Installa la distribuzione Linux come al solito (Ubuntu Server 24.04 LTS è una scelta comoda per CUDA). Poi:

sudo apt update
sudo ubuntu-drivers install      # sceglie il driver NVIDIA consigliato
sudo reboot
nvidia-smi                       # devono comparire scheda, driver e versione CUDA

Per un server LLM, Ollama è il test più rapido:

curl -fsSL https://ollama.com/install.sh | sh
ollama run llama3.1:8b "Say hello in one sentence."
ollama ps                        # PROCESSOR deve indicare 100% GPU

Se usi Docker, aggiungi il NVIDIA Container Toolkit e verifica che un container veda la scheda:

docker run --rm --gpus all nvidia/cuda:12.6.0-base-ubuntu24.04 nvidia-smi

Come riferimento indicativo per modelli quantizzati a 4 bit: un modello da 8B sta in circa 6 GB di VRAM, uno da 14B in circa 10 GB, e i modelli da 70B chiedono 40 GB o più. La lunghezza del contesto si aggiunge a questi numeri.

La strada dei container nel dettaglio

GPU integrate Intel e AMD. Da Proxmox VE 8.2 puoi passare i dispositivi a un container senza scrivere a mano le regole lxc.cgroup2. Dall’host:

pct set 114 --dev0 /dev/dri/renderD128,mode=0666

mode=0666 è l’opzione semplice. Più restrittiva è gid=<id>, con l’id del gruppo render dentro il container, così solo i membri di quel gruppo possono aprire il dispositivo. Dentro il container installa i driver userspace che servono alla tua applicazione (intel-media-va-driver o mesa-va-drivers, più il supporto OpenVINO o VA-API dell’app) e verifica con vainfo.

Schede NVIDIA nei container. Installa il driver NVIDIA sull’host, poi la stessa versione del driver dentro il container senza il modulo del kernel, e passa i dispositivi:

dev0: /dev/nvidia0
dev1: /dev/nvidiactl
dev2: /dev/nvidia-uvm
dev3: /dev/nvidia-uvm-tools

Le versioni devono coincidere esattamente, quindi ogni aggiornamento del driver sull’host significa aggiornare anche i container. In cambio, più container possono usare la stessa scheda contemporaneamente, cosa che il passthrough a una VM non permette.

Risoluzione dei problemi

• “No IOMMU detected” quando aggiungi il dispositivo: VT-d / IOMMU è spento nel firmware, oppure il parametro del kernel non è stato applicato. Controlla /proc/cmdline e di aver modificato la configurazione del bootloader che usi davvero.
• L’host si blocca quando parte la VM: un driver dell’host tiene ancora la scheda. lspci -nnk deve mostrare vfio-pci per ogni funzione; ricontrolla gli ID e le righe softdep, poi ricostruisci l’initramfs.
• “Failed to set iommu for container”: un altro dispositivo dello stesso gruppo IOMMU è ancora legato a un driver dell’host. Passa anche quello, oppure sposta la scheda in un altro slot.
• La VM si avvia ma non si vede niente: è normale se la GPU non è segnata come Primary GPU e non c’è un monitor collegato. Usa la console di Proxmox e nvidia-smi via SSH.
• Le schede AMD più vecchie funzionano una volta e poi non più dopo il riavvio della VM: è il problema di reset di Polaris e Vega. Il modulo del kernel vendor-reset risolve la maggior parte di questi casi.
• Windows mostra l’Errore 43: una vecchia limitazione dei driver NVIDIA consumer, eliminata dal driver 465 in poi. Aggiorna il driver nella VM.

Domande Frequenti

Cos’è il GPU passthrough in Proxmox?

È l’assegnazione di una GPU PCIe fisica a una sola macchina virtuale. La VM carica il driver del produttore e parla direttamente con la scheda, quindi CUDA, NVENC e il resto funzionano come su una macchina fisica, mentre l’host Proxmox rinuncia completamente alla scheda.

Più VM possono condividere una GPU?

Non con il passthrough semplice: una scheda, una VM accesa. Dividere una GPU tra più VM richiede vGPU sulle schede datacenter supportate oppure SR-IOV. Per i servizi Linux, condividere la GPU con i container LXC è il modo pratico per far usare una scheda a più carichi di lavoro.

Serve una GPU dedicata per l’AI in locale?

Per gli LLM, in pratica sì: servono VRAM e banda di memoria che le GPU integrate non hanno. Per il riconoscimento oggetti nelle telecamere, la transcodifica e gli archivi foto, una GPU Intel integrata condivisa con un container funziona bene.

Perché q35 e OVMF invece delle impostazioni di default?

q35 dà alla VM un bus PCI Express nativo, che le GPU moderne e i loro driver si aspettano, e OVMF fornisce l’UEFI richiesto dalle schede attuali e dalle BAR di grandi dimensioni. La vecchia macchina i440fx con SeaBIOS funziona con alcune schede, ma crea più problemi di quanti ne valga la pena.

Il passthrough rallenta la GPU?

Nella pratica la differenza rispetto a una macchina fisica è piccola per i carichi di calcolo, perché la VM gestisce la scheda direttamente. Conta di più dare alla VM abbastanza core e memoria fissa, così la GPU non resta ad aspettare.

Prodotti Consigliati

Se vuoi replicare questo setup, ecco da dove partirei:

• Crucial RAM 32GB DDR4: più margine per le VM
• Samsung 870 EVO SSD 1TB: storage veloce per VM e container

Link affiliati: se acquisti da qui ricevo una piccola commissione, senza costi in più per te.

Articoli Correlati

• Proxmox Home Lab: Guida Pratica al Self-Hosting
• Proxmox LXC vs VM: Scegliere la Virtualizzazione Giusta
• Proxmox Ollama Installazione: Il Tuo Server AI Locale