VPS con GPU o CPU: quando serve davvero

Serve una VPS con GPU o è sufficiente la CPU?

Una VPS con GPU modifica due aspetti dell'esecuzione autonoma di un modello: la velocità di generazione dei token e la dimensione massima del modello che può essere contenuto in memoria. Non modifica nient'altro. Se il carico di lavoro consiste in un modello chat quantizzato da 7B a 27B che risponde a una persona alla volta, in un'attività di embedding a basso volume o nella trascrizione vocale con Whisper small, una normale VPS con CPU e RAM sufficiente svolge già il lavoro. Inizia con la CPU, misura il valore che crea problemi e poi passa a una configurazione superiore.

Il motivo è la larghezza di banda della memoria. Quando un modello linguistico genera un token, legge dalla memoria tutti i pesi necessari. Un modello 8B quantizzato a 4 bit occupa circa 4.9 GB su disco e all'incirca la stessa quantità in memoria, quindi per produrre un token è necessario trasferire circa 4.9 GB. Dividendo la larghezza di banda della memoria della macchina per questo valore si ottiene il limite massimo di token al secondo. Questa singola divisione spiega quasi tutti i benchmark che leggerai.

Cosa offre realmente una GPU

Larghezza di banda. La memoria DDR5 di un server moderno trasferisce decine di gigabyte al secondo. La memoria della GPU (VRAM, video RAM) ne trasferisce da centinaia a oltre mille. Il rapporto tra questi valori determina l’accelerazione, che è significativa.

Capacità e velocità. Un sistema con CPU e 64 GB di RAM può caricare un modello da 70B a 4 bit. Il modello funzionerà, ma a una velocità più simile alla lettura che a una conversazione. In questo caso una GPU è utile solo se il modello entra nella VRAM, perché non appena i layer vengono trasferiti nella RAM di sistema, torna a prevalere il percorso lento.

Throughput dei batch. Questo aspetto viene spesso sottovalutato. Una GPU che genera testo per un solo utente lascia inutilizzata gran parte della propria capacità di calcolo, perché è in attesa dei dati dalla memoria. Gestendo 20 richieste contemporaneamente, la stessa lettura dei pesi viene utilizzata per tutte e 20. Il numero complessivo di token generati al secondo aumenta di diverse volte, mentre la velocità per singolo utente diminuisce di poco. Anche i motori di inferenza per CPU, come llama.cpp, supportano l’elaborazione in batch, con vantaggi che dipendono dall’hardware e dal carico di lavoro. Se stai sviluppando un’API chiamata da molti client, l’elaborazione in batch è il principale argomento a favore di una GPU, più della velocità assoluta su un singolo flusso.

Elaborazione del prompt. La lettura di un prompt lungo è un’operazione limitata dalla capacità di calcolo, non dalla larghezza di banda della memoria, ed è il contesto in cui le GPU offrono il vantaggio maggiore. Un contesto di 30,000 token che una CPU elabora in un minuto richiede pochi secondi su una GPU. Le configurazioni di retrieval che inseriscono documenti in ogni richiesta risentono costantemente di questa differenza.

Numeri approssimativi e come interpretarli

Il throughput effettivo è inoltre inferiore al risultato di bandwidth divisa per la dimensione del modello, perché l'attention su un contesto in crescita aggiunge lavoro che il semplice calcolo non considera.

Per fare un confronto, la lettura silenziosa degli adulti in inglese raggiunge in media circa 4.0-4.3 parole al secondo: 238 parole al minuto per la saggistica e 260 per la narrativa. Un valore pari o superiore a 15 token al secondo dà già a un singolo lettore la sensazione della normale velocità di digitazione. Per questo molte configurazioni che usano esclusivamente la CPU sono più che adeguate.

Dimensionamento della VRAM prima dell'acquisto

La dimensione del file del modello è il limite minimo, non il requisito effettivo. Considera i pesi, aggiungi la KV cache (key-value cache, la memoria per token mantenuta dall'attention), più circa 1 GB di overhead.

Calcola la cache invece di aggiungere una percentuale fissa, perché la quantizzazione dei pesi non quantizza la cache. Per ogni token, un modello con full attention memorizza una key e una value per ogni layer e ogni KV head, usando 2 byte per numero in FP16, che è il tipo di cache predefinito di Ollama. I metadati del modello di Ollama, verificati il 2026-10-27, indicano per Llama 3.1 8B 32 layer e 8 KV head da 128 dimensioni; il risultato è 128 KiB per token: circa 1.07 GB con un contesto da 8k e 2.15 GB con 16k. Quindi, un modello 8B da 4.9 GB richiede circa 7 GB di VRAM con 8k e circa 8 GB con 16k. Un modello 27B a 4 bit richiede circa 17 GB (Gemma 3 27B nella libreria di Ollama). I metadati di Gemma 3 indicano una sliding window da 1,024 token, che impedisce a gran parte della cache di crescere; pianifica quindi almeno 20 GB. Un modello 70B a 4 bit richiede circa 43 GB (Llama 3.3 70B). Con 80 layer, la relativa cache FP16 aggiunge circa 2.7 GB con 8k e 5.4 GB con 16k, quindi serve una scheda da 48 GB con poco margine, oppure due schede più piccole. Lo stesso calcolo resta valido anche oltre queste dimensioni e il calcolo della VRAM per un modello da 2.8 bilioni di parametri come Kimi K3 mostra quando la scelta della scheda non è più la questione principale.

Questo aspetto è più importante con i contesti lunghi. Nei modelli con full attention come Llama 3.1, la KV cache cresce linearmente con la lunghezza del contesto e, con 128k token, può superare i pesi stessi. I modelli con sliding-window attention o chunked attention si comportano diversamente: la documentazione di Hugging Face Transformers indica Mistral, Gemma 2 e Llama 4 come esempi in cui la cache di quei layer smette di crescere quando raggiunge la dimensione della window o del chunk, quindi il totale cresce più lentamente. Se prevedi di usare contesti lunghi, dimensiona prima la cache e verifica quali opzioni di quantizzazione della cache offre il tuo engine. In Ollama, OLLAMA_KV_CACHE_TYPE=q8_0 usa circa metà della memoria rispetto a f16, il valore predefinito, e la quantizzazione della cache si applica solo quando Flash Attention è abilitato. Imposta esplicitamente anche la lunghezza del contesto. Ollama sceglie il valore predefinito in base alla VRAM: 4k sotto 24 GiB, 32k da 24 a 48 GiB e 256k con 48 GiB o più. Su una scheda da 48 GB che esegue un modello 70B, questo valore predefinito richiede molta più cache di quella disponibile sulla scheda.

Verifica cosa è effettivamente disponibile sulla macchina

Su un'istanza GPU, verifica innanzitutto che il driver rilevi la scheda.

nvidia-smi

Devi ottenere una tabella con il nome della GPU, la versione del driver e la memoria utilizzata rispetto a quella totale. NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver indica che NVIDIA-SMI non riesce a raggiungere il driver; verifica che il driver sia installato e che il relativo modulo del kernel sia caricato. Su un'immagine Ubuntu standard, la correzione consiste solitamente nell'eseguire sudo apt install -y ubuntu-drivers-common && sudo ubuntu-drivers install, quindi nel riavviare il sistema per caricare il nuovo modulo. Per le macchine dedicate al calcolo, la documentazione server di Ubuntu consiglia sudo ubuntu-drivers install --gpgpu, che seleziona il ramo del driver per server.

Per i container, il solo driver non è sufficiente. Docker richiede NVIDIA Container Toolkit per trasferire il dispositivo al container.

sudo apt-get update && sudo apt-get install -y --no-install-recommends ca-certificates curl gnupg2
curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg
curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list | sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' | sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list
sudo apt-get update && sudo apt-get install -y nvidia-container-toolkit
sudo nvidia-ctk runtime configure --runtime=docker
sudo systemctl restart docker

Verifica quindi che il trasferimento funzioni dall'interno di un container:

sudo docker run --rm --gpus all ubuntu:24.04 nvidia-smi

Deve comparire la stessa tabella. Una riga docker: Error response from daemon: could not select device driver, che indica una capacità GPU non soddisfacibile, significa che Docker non ha trovato un device driver compatibile con la richiesta; verifica che il toolkit sia installato, quindi esegui nuovamente la riga nvidia-ctk e il riavvio. In Compose, l'equivalente è una voce deploy.resources.reservations.devices il cui driver è nvidia e il cui elenco delle funzionalità contiene gpu; questa voce si integra nelle normali definizioni dei servizi descritte in Docker Compose su un VPS.

Misura prima di eseguire l'upgrade

Esegui il modello che intendi realmente utilizzare sul sistema CPU che hai già a disposizione e registra i risultati. Con Ollama per eseguire autonomamente un LLM su un VPS è sufficiente un flag:

ollama run llama3.1:8b --verbose "Summarise the causes of the 1929 crash in 200 words."

L'output termina con i tempi di esecuzione. eval rate indica la velocità di generazione, espressa in token al secondo. prompt eval rate indica la velocità con cui il sistema ha letto l'input. Questi due valori mostrano quale upgrade è utile: un valore eval rate basso indica un problema di larghezza di banda della memoria, mentre un valore prompt eval rate basso con input lunghi indica un problema di capacità di calcolo.

Su un sistema dotato di GPU, verifica che il modello sia stato effettivamente caricato sulla GPU:

ollama ps

La colonna PROCESSOR contiene 100% GPU quando il modello entra interamente nella memoria disponibile, oppure un valore simile a 43%/57% CPU/GPU quando non vi entra. Una suddivisione parziale è generalmente peggiore del previsto, perché ogni token deve comunque attendere la parte più lenta.

La questione dei costi

Le istanze GPU vengono fatturate in base al tempo di calcolo allocato, non al numero di token, con tariffe ed eventuali costi per le istanze arrestate stabiliti dal provider. Una GPU sempre attiva che gestisce poche richieste al giorno trascorre la maggior parte del tempo fatturato senza elaborare richieste. Il punto di pareggio è il livello di utilizzo: una GPU occupata ha un costo ridotto per token, mentre una GPU inattiva è puro spreco.

Esistono tre approcci concreti. Mantieni i carichi di lavoro costanti ma ridotti su un VPS con CPU. Invia le richieste complesse occasionali a un'API hosted e paga in base ai token. Noleggia una GPU a ore per processi batch, fine-tuning o un'elaborazione massiva di embedding, quindi distruggila. Combinare questi approcci è normale. La disciplina di budgeting descritta in Controllo dei costi degli agenti AI su un VPS sempre attivo si applica anche in questo caso, con una differenza: la perdita deriva dal tempo di inattività, non dal numero di token.

Cosa continua a funzionare bene senza GPU

Embeddings a basso volume. Un modello di embedding di piccole dimensioni elabora centinaia di documenti brevi al minuto usando pochi core CPU, mentre un indice creato una sola volta non deve essere generato rapidamente.

Whisper small e base per la trascrizione. Faster-whisper su CPU trascrive quasi in tempo reale con il modello small. È sufficiente per una pipeline eseguita durante la notte.

Modelli di chat quantizzati fino a circa 27B, per uno o due utenti. Sono lenti, ma leggibili e utilizzabili.

Qualsiasi attività che si possa considerare un batch job. Se nessuno controlla lo schermo, la durata effettiva è un dettaglio di pianificazione, non un requisito.

Cosa richiede realmente una GPU: training o fine-tuning oltre un adapter di piccole dimensioni, la gestione di molti utenti simultanei, la generazione di immagini e video e la gestione della voce in tempo reale, quando la latenza è parte essenziale del prodotto.

FAQ

Quanta VRAM serve per un modello 7B o 8B?

Servono circa 7 GB per un modello 8B quantizzato a 4 bit con contesto da 8k e circa 8 GB con contesto da 16k, usando la cache FP16 predefinita di Ollama. I pesi occupano circa 4.9 GB, la cache KV aggiunge circa 1.07 GB a 8k o 2.15 GB a 16k e il resto, dovuto all'overhead, è circa 1 GB. Una scheda da 8 GB è sufficiente a 8k, ma è al limite a 16k. Una scheda da 12 GB lascia un margine adeguato per contesti più lunghi. Impostando la cache su q8_0, lo spazio occupato dalla cache si riduce approssimativamente della metà. Se prevedi di usare un contesto da 128k, dimensiona la VRAM considerando separatamente la cache, perché può superare lo spazio occupato dai pesi.

Posso eseguire Ollama senza una GPU?

Sì. Ollama passa automaticamente alla CPU e richiede solo RAM sufficiente a contenere il modello. Per un modello 8B a 4 bit, prevedi circa 5-12 token al secondo, in base alla velocità della memoria. Per un singolo utente, questa velocità è vicina a quella della lettura. Il vero limite della CPU sono i prompt lunghi, perché l'elaborazione di 30,000 token di contesto è vincolata alla capacità di calcolo e richiede molto più tempo della generazione della risposta.

Perché la mia GPU è appena più veloce della CPU?

La causa più comune è che il modello non entra interamente nella VRAM. Di conseguenza, alcuni layer vengono eseguiti sulla CPU e ogni token deve attendere la parte più lenta. Esegui ollama ps e verifica che la colonna PROCESSOR riporti 100% GPU. Se mostra una suddivisione, usa una quantizzazione più piccola o un modello più piccolo. Un'altra causa comune è un benchmark breve, nel quale il tempo di caricamento del modello pesa più della misurazione dell'inferenza.

Vale la pena usare una GPU VPS per un singolo utente?

Di solito no. La lettura silenziosa in inglese da parte di un adulto ha una velocità media di circa 4.0-4.3 parole al secondo. Prima di confrontare una macchina CPU con questa velocità, devi convertire i token al secondo in parole al secondo. Per un singolo utente, i casi che possono giustificare il costo sono i prompt lunghi, la generazione di immagini e il fine-tuning. L'uso simultaneo da parte di molti utenti è l'argomento più forte a favore, perché il batching consente a una GPU di condividere la lettura dei pesi tra più richieste.

Conviene noleggiare una GPU a ore o tenerne una sempre attiva?

Noleggiala a ore quando il carico è intermittente: fine-tuning, generazione massiva di embedding o trascrizione in batch. Tienila sempre attiva solo se rimane occupata a lungo, perché il calcolo GPU assegnato viene fatturato in base al tempo e non al numero di token prodotti. Un assistente con poco traffico costa meno su una CPU VPS o tramite un'API gestita con tariffazione per token che su una GPU inattiva.