11 novembre 2026 · Team VRAMfarm

Versione di driver e CUDA non compatibili: sistemare PyTorch e ComfyUI su una GPU a noleggio

Avvii un server, installi il tuo progetto, e il primo controllo stampa torch.cuda.is_available() False. Oppure ComfyUI si ferma con “The NVIDIA driver on your system is too old”. Su una macchina a noleggio entrano in gioco diversi numeri di versione, e quello che decide di solito è la build di PyTorch, che puoi cambiare. Il driver appartiene all’host. Quindi la soluzione è quasi sempre una di due: installare la wheel di PyTorch che corrisponde al driver, oppure scegliere una macchina con il driver adatto alla build che ti serve. Entrambe richiedono pochi minuti, una volta capito quale numero è quale.

Driver, CUDA toolkit e build di PyTorch: tre numeri diversi

Una regola copre quasi tutti i casi: la versione CUDA della tua build di PyTorch non deve essere più recente della “CUDA Version” mostrata da nvidia-smi. I driver sono retrocompatibili. Un driver che supporta CUDA 12.8 fa girare le build cu118, cu124, cu126 e cu128. Una build cu130 non ci gira, e una cu129 forse sì, forse no (vedi la nota sotto la tabella).

Driver Linux minimo per ogni build CUDA:

I programmi CUDA 12.x a volte girano su un driver della serie 12 più vecchio (525 o più recente) grazie a quella che NVIDIA chiama minor-version compatibility, ma alcune funzioni richiedono il driver completo e gli errori saltano fuori in punti strani. Non farci affidamento.

Controlla la macchina in meno di un minuto

Apri il terminale di Jupyter o collegati via SSH (come configurare una chiave SSH) e lancia:

nvidia-smi
nvcc --version
python -c "import torch; print(torch.__version__, torch.version.cuda, torch.cuda.is_available()); print(torch.cuda.get_device_name(0), torch.cuda.get_device_capability(0)); print(torch.cuda.get_arch_list())"

Come leggere il risultato:

• nvidia-smi ti dà il driver e la versione di CUDA più recente che supporta. Se è nvidia-smi stesso a fallire, il problema è sull’host, non nel tuo software (vedi sotto).
• nvcc può rispondere “command not found”. Per PyTorch va bene, non gli serve.
• La riga Python dovrebbe stampare qualcosa come 2.8.0+cu128 12.8 True, poi il nome della scheda e la sua compute capability, per esempio (12, 0) per una RTX 5090. L’elenco delle architetture deve includere la tua scheda: sm_80 per la A100, sm_86 per la serie RTX 30 e le RTX A4000–A6000, sm_89 per la serie RTX 40, L4, L40 e L40S, sm_90 per H100 e H200, sm_120 per la serie RTX 50 e la RTX PRO 6000, sm_100 per la B200.

Se torch.version.cuda stampa None, hai una build solo CPU. ComfyUI stampa le stesse informazioni all’avvio: nel log cerca la riga “pytorch version” con il suffisso +cu e la riga “Device: cuda:0”.

Cosa significa ogni errore e come risolverlo

“RuntimeError: No CUDA GPUs are available”

Si presenta anche come torch.cuda.is_available() che restituisce False. Verifica le cause in quest’ordine:

1. echo $CUDA_VISIBLE_DEVICES stampa un valore vuoto o un indice sbagliato. Rimuovi la variabile o impostala a 0.
2. torch.version.cuda è None: una build CPU. Reinstalla come spiegato nella prossima sezione.
3. La build di PyTorch è più recente di quanto supporti il driver, e il controllo del driver è fallito in silenzio. Confronta i due numeri.
4. Fallisce anche nvidia-smi: il container non ha accesso alla GPU. È un problema dell’host.

“The NVIDIA driver on your system is too old (found version 12020)”

Il numero è la versione di CUDA più recente supportata dal driver, scritta senza punti: 12020 è 12.2, 12080 è 12.8. La tua build di PyTorch ne vuole una più recente. O installi una build più vecchia compatibile, che per un driver 12.2 vuol dire una vecchia release di PyTorch, o passi a una macchina con un driver più recente. Per i progetti attuali la seconda strada di solito è più rapida.

“AssertionError: Torch not compiled with CUDA enabled”

È installata una build solo CPU. Su Linux di solito arriva dall’indice CPU, da una versione +cpu fissata in un file requirements o da un pacchetto che ha reinstallato torch come propria dipendenza. I custom node di ComfyUI lo fanno più spesso di quanto immagini.

“CUDA error: no kernel image is available for execution on the device”

Di solito è preceduto da un avviso come “NVIDIA GeForce RTX 5090 with CUDA capability sm_120 is not compatible with the current PyTorch installation”. La build non contiene codice per l’architettura della tua scheda. Sulle schede Blackwell significa PyTorch più vecchio della 2.7 o una build precedente a cu128. Lo stesso errore arriva da estensioni compilate senza la tua architettura: xformers, flash-attn, vecchie versioni di bitsandbytes o kernel di attention fissati a una versione vecchia.

“nvidia-container-cli: requirement error: unsatisfied condition: cuda>=12.8”

Questo compare con una tua immagine Docker. Le immagini base CUDA di NVIDIA dichiarano la versione di CUDA che richiedono, e il container non parte su una macchina con un driver più vecchio. Ricostruisci l’immagine su una base con una versione di CUDA più bassa, oppure scegli una macchina con un driver più recente.

“Failed to initialize NVML: Driver/library version mismatch”

Se nvidia-smi fallisce con questo errore o con “couldn’t communicate with the NVIDIA driver”, il driver dell’host è rotto o è cambiato sotto il container. Dall’interno non puoi sistemarlo. Salva /workspace e ferma il server (la fatturazione finisce quando si è fermato), avviane un altro e comunica all’assistenza di quale macchina si trattava.

“ImportError: libcudnn.so.9: cannot open shared object file”

Due pacchetti si aspettano librerie CUDA diverse, per esempio PyTorch per CUDA 12 e una build di ONNX Runtime o TensorFlow per un’altra versione. Lancia pip check, tieni tutto sulla stessa generazione di CUDA e, nel dubbio, parti da un ambiente virtuale nuovo.

Installa la build di PyTorch giusta

1. Leggi la “CUDA Version” in nvidia-smi.
2. Scegli la build di PyTorch più recente che non la supera: 12.8 → cu128; 12.6 → cu126; 13.0 → cu130 o cu128. Il selettore su pytorch.org elenca le build offerte dalla release attuale.
3. Installala in un ambiente virtuale, con torch, torchvision e torchaudio insieme dallo stesso indice, così le versioni corrispondono:

python -m venv /workspace/venv
source /workspace/venv/bin/activate
pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu128

Tenere l’ambiente in /workspace significa che finisce nella cartella salvata quando fermi il server. Ricorda che a quel punto anche la macchina successiva dovrà avere un driver abbastanza recente per quella build.

4. Impedisci ad altri pacchetti di sostituirla. Scrivi la versione installata in un file di vincoli e fai in modo che pip lo rispetti:

pip freeze | grep -E "^torch(vision|audio)?==" > /workspace/constraints.txt
export PIP_CONSTRAINT=/workspace/constraints.txt

5. Installa le estensioni per la stessa build. xformers pubblica le wheel sullo stesso indice di PyTorch; un semplice pip install xformers può tirarsi dietro un torch diverso. flash-attn ha wheel precompilate per le coppie torch-CUDA più comuni. Compilarlo da te richiede il CUDA toolkit con la stessa versione major e può portare via un’ora o più di tempo fatturato, a seconda della CPU.

Per ComfyUI: dopo aver installato custom node tramite il Manager, rifai il controllo Python. Se un nodo ha sostituito torch, reinstallalo con la riga qui sopra, poi lancia pip install -r requirements.txt nella cartella di ComfyUI. Il template ComfyUI arriva con PyTorch su CUDA 12.8.

Le RTX serie 50 e le altre Blackwell vogliono CUDA 12.8 o successivo

RTX 5090, RTX 5080, RTX 5070 Ti e RTX PRO 6000 usano l’architettura Blackwell sm_120; la B200 usa sm_100. Servono tutte e tre queste condizioni:

• driver 570 o più recente;
• una build di PyTorch per CUDA 12.8 o successivo (cu128, cu129, cu130);
• PyTorch 2.7 o successivo, la prima release stabile con supporto Blackwell.

I progetti fermi su uno stack vecchio, come torch 2.1 con cu118 in un vecchio repository di training, su Blackwell non girano proprio. Le schede Ampere e Ada fanno ancora girare quelle build, quindi per un progetto vecchio la scelta pratica è una RTX 4090 o una RTX 3090. La maggior parte delle estensioni più diffuse ormai pubblica wheel con sm_120; le loro vecchie versioni fissate no. Se un’estensione fallisce su una RTX 5090, controlla che la versione sia recente prima di dare la colpa alla scheda.

Il driver non si aggiorna, quindi sceglilo prima dell’avvio

Il driver fa parte del sistema operativo dell’host. Il tuo server è un container che riceve le librerie del driver dall’esterno. Installare un pacchetto driver al suo interno non cambia niente di utile e può rompere quelle librerie. Il pacchetto di forward compatibility di NVIDIA aiuta solo sulle schede da data center e non è una soluzione generale.

VRAMfarm mostra driver e versione di CUDA di ogni macchina prima dell’avvio, sia nella procedura di avvio della dashboard sia nel catalogo server, dove puoi filtrare per versione minima di CUDA. Sceglilo come scegli la memoria:

• uno stack su cu128 → CUDA 12.8 o successivo, driver 570 o più recente;
• cu130 → CUDA 13.0 o successivo, driver 580 o più recente;
• un vecchio progetto su cu118 → qualsiasi driver attuale, ma non una scheda Blackwell.

Per la tua immagine Docker, parti dalla versione di CUDA più bassa di cui il tuo stack ha davvero bisogno, non dalla più recente. Un’immagine su CUDA 12.6 parte su più macchine di una su 13.0. Se dopo questi controlli resta un errore di versione, scrivi all’assistenza con il testo dell’errore e l’output dei tre comandi qui sopra; di solito basta per trovare la causa. Altre domande frequenti sui server trovano risposta nelle FAQ.