VPS con GPU: quando serve davvero?

Ti serve una VPS con GPU o basta la CPU?

Una 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 nient'altro. Se il carico di lavoro consiste in un modello di chat quantizzato da 7B a 27B che risponde a una persona alla volta, in un'attività di generazione di embedding a basso volume o nella trascrizione vocale con Whisper small, una normale VPS con CPU e RAM sufficiente è già adeguata. Inizia con la CPU, misura il valore che causa problemi e poi aumenta le risorse.

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, quindi la generazione di un token richiede lo spostamento di circa 4.7 GB. Dividi la larghezza di banda della memoria della macchina per quel valore e ottieni il limite massimo di token al secondo. Questa singola divisione spiega quasi ogni benchmark che leggerai.

Che cosa offre realmente una GPU

Larghezza di banda. La memoria DDR5 del server su un host moderno trasferisce decine di gigabyte al secondo. La memoria della GPU (VRAM, video RAM) ne trasferisce da centinaia a oltre mille. Il rapporto determina l'accelerazione, che è elevata.

Capacità e velocità. Un sistema con CPU e 64 GB di RAM può caricare un modello 70B a 4 bit. Funzionerà, ma a una velocità più vicina alla lettura che a una conversazione. In questo caso una GPU è utile solo se il modello entra nella VRAM, perché non appena alcuni layer passano 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 inattiva gran parte della propria capacità di calcolo, perché è in attesa dei dati dalla 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 utente diminuisce appena. Una CPU non funziona così. Su un sistema con CPU, 2 utenti simultanei si dividono all'incirca a metà le prestazioni. Se si sta creando un'API utilizzata 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 è un'operazione limitata dalla capacità di calcolo, non dalla memoria, ed è l'ambito in cui le GPU offrono il margine più ampio. 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.

Valori approssimativi e come interpretarli

Il blocco seguente contiene valori tipici pubblicati per l'elaborazione di un singolo flusso con un modello 8B e quantizzazione a 4 bit, aggiornati a luglio 2026. Sono indicazioni dell'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. Il valore è circa cinque volte superiore; ciò riflette il rapporto di larghezza di banda, non una differenza nella potenza di calcolo grezza. Il throughput effettivo è inoltre inferiore al rapporto tra larghezza di banda e dimensione del modello, perché l'attenzione su un contesto in crescita aggiunge lavoro che la semplice divisione non considera.

Per confronto, una persona legge circa da 5 a 10 parole al secondo. Un valore 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 solo la CPU sono perfettamente adeguate.

Dimensionare la VRAM prima dell'acquisto

La dimensione del file del modello è il limite inferiore, non il requisito effettivo. Calcola lo spazio per i pesi, aggiungi la cache KV (cache key-value, ovvero la memoria per token che il meccanismo di attenzione 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 contesto 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 all'incirca 20 GB. Un modello 70B a 4 bit occupa circa 40 GB e richiede una scheda da 48 GB oppure due schede più piccole.

I contesti lunghi rendono questa regola inaffidabile. La cache KV cresce linearmente con la lunghezza del contesto e, a 128k token, può superare i pesi del modello. Se prevedi di usare contesti lunghi, dimensiona prima la cache e verifica quali opzioni di quantizzazione della cache offre il tuo motore.

Verificare cosa è effettivamente installato 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 manca il driver oppure che il modulo del kernel non è stato ricompilato dopo un aggiornamento del kernel. Su un'immagine Ubuntu standard, la correzione consiste in genere 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 comparire la stessa tabella. Una riga docker: Error response from daemon: could not select device driver che indica una capacità GPU non supportata significa che il toolkit è installato, ma Docker non è 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 capacità contiene gpu. Questa voce si inserisce nelle normali definizioni dei servizi descritte in Docker Compose su un VPS.

Misurare prima di aggiornare

Eseguite il modello che intendete realmente usare sul server CPU già disponibile e registrate i valori. Con Ollama: 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, in token al secondo. prompt eval rate indica la velocità con cui il computer legge l'input. Questi due valori indicano quale aggiornamento è utile: un valore eval rate basso segnala un problema di larghezza di banda della memoria, mentre un valore prompt eval rate basso con input lunghi segnala un problema di capacità di calcolo.

Su una macchina dotata di GPU, verificate che il modello sia stato effettivamente caricato sulla GPU:

ollama ps

La colonna PROCESSOR mostra 100% GPU quando il modello entra interamente nella GPU, 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 costano diverse volte più di un'istanza CPU comparabile e vengono fatturate per ogni ora in cui esistono, non per i token che producono. 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 ridotto per token, mentre una GPU inattiva è solo uno spreco.

Esistono tre approcci pratici. Mantieni i carichi di lavoro continuativi 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 i processi batch, il fine-tuning o l'elaborazione massiva degli embedding, quindi distruggila. È normale combinarli. Anche la disciplina di budgeting descritta in Controllo dei costi degli agenti AI su un VPS sempre attivo si applica in questo caso, con una differenza: la perdita deriva dal tempo di inattività, non dal numero di token.

Cosa continua a funzionare bene senza una GPU

Gli embeddings a basso volume. Un piccolo modello di embeddings elabora centinaia di documenti brevi al minuto usando pochi core CPU, e un indice creato una sola volta non deve essere necessariamente veloce.

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 processo batch. Se nessuno osserva lo schermo, la velocità reale è un dettaglio di pianificazione, non un requisito.

Cosa richiede realmente una GPU: addestramento o fine-tuning oltre un piccolo adapter, gestione di molti utenti simultanei, generazione di immagini e video e riconoscimento vocale in tempo reale, quando la latenza è il prodotto.

FAQ

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

Circa 6 GB per un modello 8B quantizzato a 4 bit con un contesto normale da 8k a 16k. I pesi occupano circa 4.7 GB. La parte restante è la cache KV, oltre a circa 1 GB di overhead. Una scheda da 12 GB lascia spazio sufficiente per contesti più lunghi. Se prevedi di usare un contesto da 128k, dimensiona la cache separatamente, perché può diventare più grande dei pesi.

Posso eseguire Ollama senza una GPU?

Sì. Ollama passa automaticamente alla CPU e richiede solo RAM sufficiente per contenere il modello. Per un modello 8B a 4 bit, in base alla velocità della memoria, puoi aspettarti circa 5-12 token al secondo. Per un singolo utente, questa velocità è vicina a quella di lettura. Sulla CPU, il vero collo di bottiglia sono i prompt lunghi. L'elaborazione di 30,000 token di contesto è limitata dalla 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ù compatta o un modello più piccolo. L'altra causa comune è un benchmark breve, in cui il tempo di caricamento del modello domina la misurazione.

Conviene usare un GPU VPS per un singolo utente?

Di solito no. Una persona legge da 5 a 10 parole al secondo, mentre una macchina con CPU genera già token a una velocità superiore per i modelli fino a circa 13B. Per un singolo utente, i casi che giustificano il costo 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 a un costo simile a quello di una sola risposta.

Devo noleggiare una GPU a ore o lasciarla sempre attiva?

Noleggiala a ore quando il carico di lavoro è discontinuo: fine-tuning, un'esecuzione massiva di embedding o un job di trascrizione in batch. Lasciala sempre attiva solo quando 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 un CPU VPS o su un'API ospitata con pagamento per token che su una GPU inattiva.