VPS con GPU o CPU: quando serve davvero

Serve un VPS con GPU oppure è sufficiente la CPU?

Un VPS con GPU modifica due aspetti dell'esecuzione autonoma di un modello: la velocità con cui vengono generati i token e le dimensioni massime del modello che possono essere contenute in memoria. Non modifica 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, un normale VPS con CPU e RAM sufficiente è già adeguato. 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.7 GB su disco e all'incirca la stessa quantità in memoria; per produrre un token deve quindi trasferire circa 4.7 GB. Dividendo la larghezza di banda della memoria della macchina per questo valore si ottiene il limite massimo teorico in token al secondo. Questa singola divisione spiega quasi ogni benchmark che si possa consultare.

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 è notevole.

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

Throughput dei batch. È l'aspetto che viene più spesso sottovalutato. Una GPU che genera output per un solo utente lascia inutilizzata gran parte della propria capacità di calcolo, perché è in attesa dei dati in memoria. Gestendo 20 richieste contemporaneamente, la stessa lettura dei pesi serve tutte e 20 le richieste. Il numero complessivo di token al secondo aumenta di diverse volte, mentre la velocità per singolo utente diminuisce di poco. Una CPU non si comporta così. Su un server con CPU, 2 utenti simultanei si dividono all'incirca a metà le prestazioni. Se stai realizzando un'API chiamata da molti client, il batching è il principale argomento a favore di una GPU, più della velocità grezza su un singolo flusso.

Elaborazione del prompt. La lettura di un prompt lungo è limitata dalla capacità di calcolo, non dalla larghezza di banda della memoria, ed è l'ambito in cui le GPU offrono il vantaggio più ampio. Un contesto di 30,000 token che una CPU elabora in un minuto richiede pochi secondi su una GPU. Le configurazioni RAG che inseriscono documenti in ogni richiesta lo evidenziano continuamente.

Numeri approssimativi e come interpretarli

Il blocco seguente riporta valori tipici pubblicati per l'elaborazione di un singolo flusso con un modello da 8B a quantizzazione a 4 bit, aggiornati a luglio 2026. Sono indicazioni sull'ordine di grandezza, non una garanzia. La quantizzazione, la lunghezza del contesto e il motore di inferenza possono modificarli.

[
  {
    "label": "8 vCPU, DDR4",
    "mem_bandwidth_gbs": 40,
    "tokens_per_sec": 6
  },
  {
    "label": "16 vCPU, DDR5",
    "mem_bandwidth_gbs": 75,
    "tokens_per_sec": 11
  },
  {
    "label": "24GB GPU",
    "mem_bandwidth_gbs": 300,
    "tokens_per_sec": 50
  },
  {
    "label": "40GB data-centre GPU",
    "mem_bandwidth_gbs": 1555,
    "tokens_per_sec": 130
  }
]

La riga relativa alla GPU da 24 GB mostra 50 token al secondo, rispetto a 11 per un sistema CPU con DDR5. Si tratta di una velocità circa cinque volte superiore, in linea con il rapporto di larghezza di banda più che con una differenza nella potenza di calcolo pura. Il throughput reale è inoltre inferiore al risultato di larghezza di banda divisa per dimensione del modello, perché l'attenzione su un contesto in crescita aggiunge lavoro che il semplice calcolo non considera.

Per confronto, una persona legge circa da 5 a 10 parole al secondo. Una velocità pari o superiore a 15 token al secondo dà già a un singolo lettore la sensazione di una normale digitazione. Per questo molte configurazioni che usano soltanto la CPU sono perfettamente adeguate.

Dimensionare la VRAM prima dell'acquisto

La dimensione del file del modello è il limite minimo, non il requisito effettivo. Devi considerare i pesi, la KV cache (key-value cache, la memoria per token che il meccanismo di attention mantiene) e circa 1 GB di overhead.

Una regola pratica, valida a luglio 2026: prendi la dimensione del file del modello in gigabyte e aggiungi il 20 percento per un context normale da 8k a 16k. Un modello 8B da 4.7 GB richiede circa 6 GB di VRAM. Un modello 27B a 4 bit occupa circa 16 GB e richiede indicativamente 20 GB. Un modello 70B a 4 bit occupa circa 40 GB e richiede una scheda da 48 GB oppure due schede più piccole. Lo stesso calcolo resta valido anche per modelli molto più grandi; il calcolo della VRAM per un modello da 2.8 trilioni di parametri come Kimi K3 mostra quando la scelta della scheda non è più il problema principale.

I context lunghi rendono questa regola insufficiente. La KV cache cresce linearmente con la lunghezza del context e, a 128k token, può superare le dimensioni dei pesi. Se prevedi di usare context lunghi, dimensiona prima la cache e verifica quali opzioni di quantizzazione della cache offre il tuo engine.

Verificare le risorse effettivamente disponibili sulla macchina

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

nvidia-smi

L'output deve contenere 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 il driver manca oppure che il modulo del kernel non è stato ricompilato dopo un aggiornamento del kernel. Su un'immagine Ubuntu standard, in genere la correzione consiste nell'eseguire sudo apt install -y ubuntu-drivers-common && sudo ubuntu-drivers install, quindi nel riavviare il sistema per caricare il nuovo modulo.

Per i container, il solo driver non è sufficiente. Docker richiede NVIDIA Container Toolkit per esporre 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

Verificare quindi che il passthrough funzioni dall'interno di un container:

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

Deve essere visualizzata la stessa tabella. Una riga docker: Error response from daemon: could not select device driver che indica una capacità GPU non disponibile significa che il toolkit è installato, ma Docker non è mai stato riconfigurato o riavviato. Eseguire 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 capabilities 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.

Il costo

Le istanze GPU costano diverse volte più di un'istanza CPU equivalente e vengono fatturate per ogni ora in cui sono attive, non in base ai token che generano. Una GPU sempre attiva che gestisce poche richieste al giorno è il modo più costoso per eseguire l'inferenza. Il punto di pareggio è il livello di utilizzo: una GPU molto utilizzata ha un costo contenuto per token, mentre una GPU inattiva è puro spreco.

Sono validi tre approcci. Mantieni i carichi di lavoro costanti e a basso volume su un VPS CPU. Invia le richieste difficili occasionali a un'API ospitata 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. Anche qui si applica la disciplina di budgeting descritta in Controllo dei costi di un agente AI su un VPS sempre attivo, 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 6 GB per un modello 8B quantizzato a 4 bit con una finestra di contesto normale, da 8k a 16k. I pesi occupano circa 4.7 GB; il resto è costituito dalla cache KV e da circa 1 GB di overhead. Una scheda da 12 GB lascia un margine adeguato per contesti più lunghi. Se prevedi di usare un contesto da 128k, calcola separatamente lo spazio per la cache, perché può superare quello 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, in base alla velocità della memoria, puoi aspettarti circa da 5 a 12 token al secondo, una velocità vicina a quella di lettura per un singolo utente. Sulla CPU, il problema principale sono i prompt lunghi: leggere 30,000 token di contesto richiede calcoli intensivi e molto più tempo rispetto alla 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 nella colonna PROCESSOR sia riportato 100% GPU. Se viene indicata una suddivisione, usa una quantizzazione più compatta o un modello più piccolo. L'altra causa comune è un benchmark breve, nel quale il tempo di caricamento del modello incide soprattutto sulla misurazione.

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

In genere no. Una persona legge da 5 a 10 parole al secondo e un server con CPU produce già i token più rapidamente per i modelli fino a circa 13B. I casi che giustificano il costo per un singolo utente sono i prompt lunghi, la generazione di immagini e il fine-tuning. Servire molti utenti contemporaneamente è l'argomento più forte a favore, perché il batching consente a una singola GPU di rispondere a venti richieste con un costo simile a quello di una sola risposta.

È meglio noleggiare una GPU a ore o lasciarla sempre attiva?

Noleggiala a ore quando il carico è intermittente: fine-tuning, esecuzione massiva di embedding o trascrizione in batch. Lasciala sempre attiva solo se la scheda rimane occupata, perché un'istanza GPU viene fatturata per il tempo di esistenza, non per i token prodotti. Un assistente con poco traffico costa meno su una CPU VPS o su un'API in hosting con fatturazione per token rispetto a una GPU inattiva.