Eseguire Qwen 3 27B su VPS con Ollama

È possibile eseguire Qwen 3.8 27B su un VPS senza GPU?

Per eseguire Qwen 3.8 27B su un VPS serve innanzitutto un tag del modello realmente disponibile. Al 4 agosto 2026, la libreria Ollama non contiene alcuna voce qwen3.8. Il tag 27B rilasciato più vicino è qwen3.6:27b: 27.8 miliardi di parametri, quantizzazione Q4_K_M e licenza Apache 2.0. Tutti i comandi e tutti i numeri riportati di seguito usano questo tag con Ollama v0.32.5, pubblicato il 27 luglio 2026.

La risposta breve è sì, su un VPS con almeno 32 GB di RAM, ma con prestazioni ridotte. Un modello denso 27B in formato Q4 richiede circa 17 GB di RAM solo per i pesi, prima di memorizzare anche un solo token del contesto. Sono quindi esclusi completamente i piani da 8 GB e 16 GB. Su un VPS comune con memoria DDR4 a due canali, il limite è di circa 3 token al secondo, una velocità inferiore a quella di lettura della maggior parte degli utenti.

Da dove deriva il numero 3.8? Molto probabilmente dal numero di parametri. La pagina Ollama di qwen3.6:27b indica 27.8B parametri, e in seguito è facile ricordare 27.8 come 3.8. Esiste anche qwen3.5:27b, la stessa build Q4_K_M della release precedente. Controlla l'elenco aggiornato prima di copiare un comando, nella pagina dei tag qwen3.6 di Ollama. Se in seguito viene rilasciato un vero qwen3.8, i calcoli riportati qui resteranno validi, perché dipendono dal numero di parametri e dai bit per peso, non dal numero di versione.

Quale tag di Ollama scaricare e come verificarlo

Il tentativo di scaricare un tag inesistente restituisce un errore chiaro. È quindi possibile verificare rapidamente il tag direttamente sul server.

ollama pull qwen3.8:27b
# Error: pull model manifest: file does not exist

ollama pull qwen3.6:27b
ollama show qwen3.6:27b

ollama show mostra l'architettura, il numero di parametri, la lunghezza del contesto e la quantizzazione del tag effettivamente installato. Se la riga dei parametri contiene 27.8B e quella della quantizzazione contiene Q4_K_M, è presente la build utilizzata da questa guida. La libreria include anche qwen3.6:27b-q8_0 e qwen3.6:27b-bf16, che contengono gli stessi pesi a maggiore precisione, oltre a una serie di tag 35b-a3b che corrispondono a modelli MoE (mixture of experts) e si comportano in modo molto diverso sulla CPU. Questi modelli sono descritti più avanti.

Numero di parametri moltiplicato per i byte per peso

[
  {
    "label": "Q4_K_M",
    "size_gb": 17,
    "bits_per_weight": 4.89,
    "notes": "published tag qwen3.6:27b"
  },
  {
    "label": "Q5_K_M",
    "size_gb": 19.8,
    "bits_per_weight": 5.7,
    "notes": "computed, no library tag exists"
  },
  {
    "label": "NVFP4",
    "size_gb": 20,
    "bits_per_weight": 5.76,
    "notes": "published tag 27b-nvfp4"
  },
  {
    "label": "Q8_0",
    "size_gb": 30,
    "bits_per_weight": 8.63,
    "notes": "published tag 27b-q8_0"
  },
  {
    "label": "BF16",
    "size_gb": 56,
    "bits_per_weight": 16.1,
    "notes": "published tag 27b-bf16"
  }
]

La formula occupa una sola riga. Byte dei pesi = parametri * bit per peso / 8. Con 4 bit esatti, 27.8 miliardi di parametri corrisponderebbero a 13.9 GB. Il tag Q4_K_M distribuito è di 17 GB, che corrispondono in pratica a 4.89 bit per peso.

Questa differenza non indica un errore. I formati K-quant non memorizzano ogni tensore alla larghezza nominale. I tensori che perdono più qualità con la compressione vengono mantenuti a 5 o 6 bit, mentre i livelli di embedding dei token e di output vengono generalmente lasciati in Q6_K o Q8_0. Il nome del formato indica una media, che in questo caso è vicina a 4.9. Lo stesso effetto si osserva all'estremo opposto della scala: 56 GB per BF16 corrispondono a 16.1 bit per peso invece di un valore fisso di 16, perché il file contiene anche metadati e una tabella di embedding a precisione completa.

Q5_K_M non dispone di un tag pubblicato per questo modello, quindi la riga da 19.8 GB è calcolata usando i consueti 5.7 bit per peso di questo formato, anziché essere misurata. Q8_0 quasi raddoppia Q4, arrivando a 30 GB. Su un sistema con sola CPU, questo raddoppio comporta il doppio del traffico di memoria per token e riduce quindi all'incirca della metà il numero di token al secondo. Per questo motivo, Q4_K_M è il valore predefinito corretto in questo caso.

Costo della cache KV all'aumentare del contesto

I pesi hanno un costo fisso. La cache KV (cache di key e value, cioè lo stato dell'attenzione che il modello conserva per ogni token già elaborato) cresce linearmente con la lunghezza del contesto. È qui che la maggior parte degli utenti esaurisce la RAM.

[
  {
    "label": "4k tokens",
    "kv_f16_gb": 1,
    "kv_q8_gb": 0.5
  },
  {
    "label": "8k tokens",
    "kv_f16_gb": 2,
    "kv_q8_gb": 1
  },
  {
    "label": "16k tokens",
    "kv_f16_gb": 4,
    "kv_q8_gb": 2
  },
  {
    "label": "32k tokens",
    "kv_f16_gb": 8,
    "kv_q8_gb": 4
  },
  {
    "label": "64k tokens",
    "kv_f16_gb": 16,
    "kv_q8_gb": 8
  },
  {
    "label": "128k tokens",
    "kv_f16_gb": 32,
    "kv_q8_gb": 16
  }
]

Questi valori presuppongono l'architettura usata da Qwen nei recenti modelli dense di questa classe dimensionale: 64 layer, 8 head key/value con GQA (grouped-query attention) e una dimensione della head pari a 128. Il risultato è 256 KiB per token a f16, quindi 8 GB a 32k token e 32 GB a 128k. Non fidarti dei miei calcoli per il tuo sistema. Carica il modello e leggi la colonna SIZE di ollama ps, che riporta pesi, cache e overhead come un unico valore.

Per questo il contesto da 256K indicato nella scheda del modello è un dato di riferimento, non un'impostazione operativa. Utilizzarlo interamente a f16 richiederebbe 64 GB di cache oltre ai pesi, su una macchina che ha già allocato 17 GB per i pesi. Per impostazione predefinita, Ollama non assegna l'intera finestra. Ne carica una molto più piccola, che puoi aumentare deliberatamente con OLLAMA_CONTEXT_LENGTH. Aumentala per gradi e controlla ollama ps dopo ogni modifica.

Due impostazioni dimezzano la cache o la riducono ulteriormente. OLLAMA_KV_CACHE_TYPE=q8_0 memorizza la cache a 8 bit invece che a 16, riducendo il valore per 32k token da 8 GB a 4 GB. Richiede flash attention, quindi imposta anche OLLAMA_FLASH_ATTENTION=1 e verifica la riduzione in ollama ps invece di presumere che l'impostazione sia stata applicata. OLLAMA_NUM_PARALLEL=1 è altrettanto importante. Ollama può gestire più richieste contemporaneamente e ogni slot riceve la propria porzione di contesto. Lasciare il parallelismo al valore predefinito moltiplica quindi silenziosamente la cache prevista. Se più di una persona utilizzerà questo sistema, è questa moltiplicazione a creare problemi. Il numero di utenti simultanei che un modello self-hosted può gestire dipende dagli slot della cache e dalla profondità della coda molto prima che dal numero di core.

Cosa entra in 8, 16, 32 e 64 GB di RAM

[
  {
    "label": "8 GB",
    "q4_max_ctx_ktok": 0,
    "q8_max_ctx_ktok": 0,
    "notes": "Weights alone exceed the box. Use a 4b or 8b model."
  },
  {
    "label": "16 GB",
    "q4_max_ctx_ktok": 0,
    "q8_max_ctx_ktok": 0,
    "notes": "17 GB of weights does not fit in 16 GB of RAM."
  },
  {
    "label": "32 GB",
    "q4_max_ctx_ktok": 32,
    "q8_max_ctx_ktok": 0,
    "notes": "Q4 fits with room to spare. Q8 weights do not fit."
  },
  {
    "label": "64 GB",
    "q4_max_ctx_ktok": 128,
    "q8_max_ctx_ktok": 64,
    "notes": "Both fit. Q8 leaves much less room for context."
  }
]

Leggi i due numeri come migliaia di token di contesto disponibili insieme ai pesi, con cache f16, su un VPS Linux headless con circa 1,5 GB riservati al sistema operativo e un piccolo margine aggiuntivo. Zero significa che i pesi non entrano nella memoria disponibile, quindi non rimane spazio per il contesto.

8 GB e 16 GB non sono configurazioni al limite. 17 GB di pesi non entrano in 16 GB di RAM, e nessuna impostazione del contesto può cambiare questo limite. Anche aggiungere swap non risolve il problema. Ollama esegue il memory mapping del file GGUF. Quando le pagine residenti superano la RAM, il kernel inizia a espellerle e a rileggerle. Ogni token deve quindi recuperare gigabyte dal disco. Il sistema rimane con un iowait elevato e genera molto meno di un token al secondo.

32 GB è il livello di ingresso. I pesi occupano 17 GB e rimangono circa 13 GB, sufficienti per circa 32k token di contesto f16, mantenendo un margine. I pesi Q8_0 da 30 GB non entrano affatto in questa configurazione.

64 GB offre un margine adeguato. Con Q4 rimane spazio per circa 128k token di contesto, mentre i pesi Q8_0 entrano lasciando circa 64k token disponibili. Prima di pagare 64 GB per usare Q8, valuta con precisione cosa stai acquistando: un output leggermente migliore a metà della velocità, su una macchina che era già lenta. Per quasi tutti, Q4 con un contesto più ampio è il compromesso migliore.

Quanto è veloce l'inferenza CPU su un VPS?

Generare un token da un modello dense richiede la lettura di ogni peso dalla memoria una volta. Non solo di alcuni. Di tutti. Il limite di velocità non è quindi il numero di core, ma la larghezza di banda della memoria divisa per la dimensione dei pesi. Con Q4 si tratta di 17 GB di traffico di memoria per token.

[
  {
    "label": "DDR4-2666, 2 channel",
    "mem_bandwidth_gb_s": 42.6,
    "ceiling_tok_s": 2.5
  },
  {
    "label": "DDR4-3200, 2 channel",
    "mem_bandwidth_gb_s": 51.2,
    "ceiling_tok_s": 3
  },
  {
    "label": "DDR5-4800, 2 channel",
    "mem_bandwidth_gb_s": 76.8,
    "ceiling_tok_s": 4.5
  },
  {
    "label": "DDR4-3200, 8 channel",
    "mem_bandwidth_gb_s": 204.8,
    "ceiling_tok_s": 12
  },
  {
    "label": "DDR5-4800, 12 channel",
    "mem_bandwidth_gb_s": 460.8,
    "ceiling_tok_s": 27.1
  }
]

Questi sono limiti teorici, non misurazioni. Nella pratica, la velocità è circa il 50-70% del valore indicato, perché la latenza della memoria e il prefetching non perfetto impediscono di raggiungere il picco teorico. Un VPS con DDR4-3200 a due canali ha un limite di 3 token al secondo, quindi è realistico aspettarsi circa 2. Un server con DDR5-4800 a due canali ha un limite di 4.5, quindi è realistico aspettarsi circa 3.

Le righe relative ai server più grandi richiedono una precisazione. Una piattaforma EPYC a dodici canali ha 460.8 GB/s e un limite di 27.1 token al secondo, ma non si noleggia un intero sistema EPYC. La larghezza di banda della memoria è una risorsa dell'host, condivisa da tutti i tenant della macchina. Una porzione con 8 vCPU non dispone quindi di dodici canali di larghezza di banda dedicati. Le guide incentrate sulle GPU ignorano completamente questo aspetto. È il motivo per cui due piani VPS con lo stesso numero di vCPU possono differire di un fattore 3 sullo stesso modello.

Per lo stesso motivo, aumentare il numero di vCPU smette presto di essere utile. Quando i core richiedono dati più rapidamente di quanto il controller di memoria possa fornirli, i thread aggiuntivi introducono solo overhead di scheduling. Impostare OLLAMA_NUM_THREAD sul numero di core fisici, eseguire una misurazione, quindi provare la metà di quel valore. Su molti piani condivisi, l'impostazione più bassa è più veloce.

L'elaborazione del prompt si comporta in modo diverso. Il prefill, cioè il passaggio sull'input prima della visualizzazione del primo token, è limitato dalla capacità di calcolo e non dalla larghezza di banda. Per questo motivo scala con il numero di core. In pratica, con un prompt lungo si verifica una pausa prolungata prima dell'inizio dell'output, seguita dalla velocità costante e ridotta indicata sopra. Misurare separatamente le due fasi con --verbose, che stampa un prompt eval rate e un eval rate per ogni richiesta.

Se il modello dense 27B è semplicemente troppo lento, controllare i tag qwen3.6:35b-a3b prima di rinunciare all'esecuzione sulla CPU. Questi attivano circa 3 miliardi di parametri per token invece di tutti i 27.8 miliardi. Il traffico di memoria per token diminuisce quindi di quasi un ordine di grandezza, anche se il file su disco è più grande. Si sacrifica l'occupazione di RAM a favore della velocità. Anche la scelta del runtime è importante: Ollama e llama.cpp espongono controlli diversi per l'ottimizzazione CPU sullo stesso codice di inferenza sottostante.

Quando conviene invece noleggiare un'ora di GPU

[
  {
    "label": "L40S, 48 GB",
    "mem_bandwidth_gb_s": 864,
    "ceiling_tok_s": 51
  },
  {
    "label": "RTX 4090, 24 GB",
    "mem_bandwidth_gb_s": 1008,
    "ceiling_tok_s": 59
  },
  {
    "label": "A100, 80 GB",
    "mem_bandwidth_gb_s": 2039,
    "ceiling_tok_s": 120
  },
  {
    "label": "H100 SXM, 80 GB",
    "mem_bandwidth_gb_s": 3350,
    "ceiling_tok_s": 197
  }
]

La stessa formula applicata alla larghezza di banda della memoria GPU dichiarata dai produttori porta a una conclusione diversa. Una scheda consumer da 24 GB raggiunge un limite teorico di 59 token al secondo con questi pesi. Una scheda attuale per data center arriva a 197. Non è una differenza che si possa colmare regolando il numero di thread. La scheda esegue gli accessi alla memoria a 1008 GB/s, mentre il tuo VPS raggiunge poche decine di GB/s.

Quindi stabilisci il limite in base al carico di lavoro, non alle preferenze. L'inferenza su CPU è la scelta corretta quando il lavoro è asincrono e nessuno aspetta il risultato: ad esempio, il riepilogo notturno di una raccolta di documenti o un job di classificazione eseguito durante la notte. Noleggia una GPU non appena una persona deve attendere l'output oppure quando arrivano più richieste di una ogni 30 secondi, perché una macchina solo CPU non dispone di margine per il batching e la coda continua semplicemente a crescere.

Il confronto dei costi è meno immediato di quanto sembri. Un VPS da 64 GB viene fatturato per ogni ora del mese, indipendentemente dal fatto che il modello sia caricato o meno, mentre un'istanza GPU viene fatturata soltanto per le ore in cui la mantieni in esecuzione. Se il tuo utilizzo effettivo è di due ore al giorno, la GPU noleggiata può essere sia più veloce sia più economica. Calcola prima il tuo duty cycle, quindi confronta i prezzi. Scegliere un VPS con una GPU spiega che cosa controllare direttamente sull'istanza, mentre vLLM supera Ollama quando servi richieste concorrenti su una GPU descrive perché vLLM è più efficace in questo caso: esegue correttamente il batching.

Esiste una terza opzione che spesso viene trascurata. Mantieni il modello 27B sulla CPU per i job batch e usa un modello API ospitato per il percorso interattivo. Non è necessario che un unico modello gestisca entrambi i carichi.

Installare Ollama e misurare il proprio server

Lo script di installazione è quello ufficiale e configura un servizio systemd eseguito da un utente dedicato ollama.

curl -fsSL https://ollama.com/install.sh | sh
ollama --version
free -g

ollama --version dovrebbe stampare 0.32.5 o una versione successiva. Controllare free -g prima di scaricare qualsiasi elemento. Se nella riga Mem la colonna total indica un valore inferiore a 32, fermarsi e scegliere un modello più piccolo: scaricare 17 GB che non è possibile eseguire fa perdere un'ora e molto spazio su disco.

Impostare le opzioni di runtime in un override di systemd, non nella shell. Il modello viene eseguito all'interno del servizio, quindi non vede l'ambiente interattivo.

sudo systemctl edit ollama

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=8192"
Environment="OLLAMA_NUM_PARALLEL=1"
Environment="OLLAMA_MAX_LOADED_MODELS=1"
Environment="OLLAMA_FLASH_ATTENTION=1"
Environment="OLLAMA_KV_CACHE_TYPE=q8_0"
Environment="OLLAMA_KEEP_ALIVE=60m"

sudo systemctl restart ollama
ollama pull qwen3.6:27b
ollama run qwen3.6:27b --verbose "Name two Linux distributions."

L'output di --verbose contiene la misura che interessa. eval rate indica i token al secondo durante la generazione. prompt eval rate indica la velocità di prefill. load duration indica il tempo impiegato per leggere i pesi dal disco; per questo OLLAMA_KEEP_ALIVE=60m è impostato: su CPU, ricaricare dal disco 17 GB di pesi a ogni richiesta costa più dell'elaborazione della richiesta stessa.

Mentre il modello è caricato, controllare l'occupazione da un secondo terminale.

ollama ps

La colonna SIZE indica l'occupazione reale della memoria, inclusa la cache KV, e dovrebbe essere vicina alla dimensione dei pesi più la riga corrispondente alla lunghezza del contesto nel grafico KV. Con 8192 token e una cache a 8 bit, prevedere circa un gigabyte oltre i pesi, rispetto a 2 GB se la cache restasse in f16. La colonna PROCESSOR dovrebbe indicare 100% CPU. Se indica un valore diverso, un processo ha utilizzato una GPU e i valori di velocità riportati in questa guida non descrivono il proprio server.

Modalità di errore e stringhe esatte visualizzate

Il modello non viene caricato. Ollama stampa una riga che riporta entrambe le cifre, nel formato model requires more system memory (18.6 GiB) than is available (15.2 GiB). Questo è l’errore preferibile, perché Ollama esegue il controllo prima di allocare la memoria, invece di lasciare la gestione al kernel. Riduci la lunghezza del contesto, passa a un tag più piccolo oppure scegli un piano con più risorse.

Il processo scompare durante la generazione di una risposta. Il client non mostra informazioni utili e journalctl -u ollama -n 50 indica che il servizio viene riavviato. Esegui dmesg -T | tail: una riga con Out of memory: Killed process ... (ollama) indica che il kernel ha terminato il processo tramite OOM killer. Succede quando il controllo preliminare ha avuto esito positivo, ma la cache supera la stima durante una conversazione lunga. Riduci la lunghezza del contesto.

Il pull fallisce immediatamente. Error: pull model manifest: file does not exist indica che il tag non è presente nella libreria. L’esecuzione di qwen3.8:27b produce esattamente questo risultato, così come qualsiasi errore di digitazione nel numero di versione. Verifica il tag nella pagina della libreria prima di attribuire il problema alla rete.

Tutto funziona, ma il servizio è estremamente lento. Una velocità inferiore a un token al secondo su un sistema con RAM sufficiente indica un problema di paging, non di capacità di calcolo. Esegui vmstat 1 durante la generazione. Un valore diverso da zero nella colonna si o so indica che il kernel sta usando lo swap; la soluzione consiste nel ridurre il contesto o il numero di modelli caricati. Un valore elevato e costante di wa senza attività di swap indica che i pesi mappati in memoria vengono riletti dal disco, quindi non entrano realmente nella memoria disponibile.

Il primo token richiede 30 secondi, poi l’output accelera. Si tratta del prefill ed è normale. Un prompt di sistema lungo deve essere elaborato per ogni richiesta che non utilizza la cache. Riduci quindi il prompt di sistema prima di modificare qualsiasi altra impostazione.

A cosa serve davvero un modello 27B eseguito solo su CPU

Definisci le aspettative in base ai numeri, non alle speranze. Con una velocità compresa tra due e quattro token al secondo, una risposta di 500 token richiede da due a quattro minuti. È inutilizzabile per la chat, ma perfettamente gestibile per una coda di elaborazione. La sintesi di documenti, l'assegnazione massiva di tag, l'estrazione di campi da un insieme di file e la revisione automatica del codice tollerano questi tempi, perché nessuno attende la risposta. L'assistenza alla programmazione si trova esattamente al limite: indirizzare un agente di coding verso un modello che ospiti tu è utile per processi in background, come generare messaggi di commit e strutture di test, ma non per i suggerimenti inline che richiedono di restare in attesa.

Il vero argomento è la privacy. Il modello viene eseguito su hardware che noleggi e controlli tu, nessuna richiesta lascia il server e non paghi alcun costo per token. Questo è importante per i dati soggetti a normative, anche con una velocità di tre token al secondo. Confronta però questa soluzione in modo realistico con l'alternativa: il self-hosting di un modello di dimensioni frontier richiede un ordine di grandezza in più di hardware, mentre un modello 27B eseguito su CPU è il punto meno costoso di questa curva in cui l'output resta utile da leggere.

Se questa è la tua prima installazione di Ollama, la guida completa per eseguire Ollama su un VPS descrive la configurazione del servizio, l'API HTTP e le regole del firewall che questa guida presuppone tu abbia già configurato. Non esporre la porta 11434 a Internet. Ollama non include un sistema di autenticazione proprio, quindi chiunque riesca a raggiungere la porta può usare il tuo modello e leggere i prompt.

FAQ

Esiste un modello Qwen 3.8 27B su Ollama?

No. Al 4 agosto 2026, la libreria Ollama non contiene alcun namespace qwen3.8. I tag 27B disponibili sono qwen3.5:27b e qwen3.6:27b, entrambi build Q4_K_M di un modello denso con 27.8 miliardi di parametri. Il valore 3.8 nella query di ricerca è quasi certamente il numero di parametri 27.8B ricordato come numero di versione. Controlla https://ollama.com/library/qwen3.6/tags per l'elenco aggiornato e scarica qwen3.6:27b se vuoi l'ultima versione rilasciata del modello 27B. Un tag inesistente causa un errore con Error: pull model manifest: file does not exist.

Quanta RAM serve per eseguire un modello Qwen 27B su un VPS?

32 GB sono il minimo pratico per Q4_K_M. I pesi occupano 17 GB, il sistema operativo richiede circa 1.5 GB e la cache KV aggiunge all'incirca 1 GB ogni 4000 token di contesto a f16. Un piano da 16 GB non può contenere nemmeno i pesi, e lo swap non risolve il problema perché il file è mappato in memoria e il kernel deve rileggerlo dal disco a ogni token. 64 GB lasciano spazio per un contesto lungo o per i pesi Q8_0 da 30 GB.

Quanti token al secondo può generare un modello 27B su CPU?

Dividi la larghezza di banda della memoria per la dimensione dei pesi, quindi considera il 50-70% del risultato. Un VPS con DDR4-3200 a due canali ha un limite teorico vicino a 3 token al secondo e raggiunge circa 2. Un server con DDR5-4800 a due canali ha un limite teorico vicino a 4.5 e raggiunge circa 3. Le piattaforme server con più canali hanno prestazioni teoriche molto migliori, ma la larghezza di banda della memoria è condivisa tra tutti i tenant dell'host. Misura quindi le prestazioni del tuo sistema con ollama run qwen3.6:27b --verbose e leggi la riga eval rate.

Devo usare Q4 o Q8 su un VPS con solo CPU?

Q4_K_M, nella quasi totalità dei casi. Q8_0 occupa 30 GB invece di 17 GB. Richiede quindi un piano da 64 GB e trasferisce quasi il doppio della memoria per token, riducendo circa della metà il numero di token al secondo. La differenza di qualità tra Q4_K_M e Q8_0 su un modello 27B è ridotta per la maggior parte delle attività. È preferibile usare la RAM per un contesto più lungo, perché questo modifica le capacità del modello e non soltanto il modo in cui formula le risposte.

Quando noleggiare una GPU costa meno di un VPS con molta RAM?

Quando il carico è discontinuo o c'è una persona in attesa del risultato. Una GPU con 24 GB di memoria raggiunge circa 59 token al secondo con questi pesi, contro 2 o 3 su un VPS tipico, e viene fatturata soltanto per le ore in cui è in esecuzione. Un VPS da 64 GB viene fatturato per tutto il mese, indipendentemente dal fatto che il modello sia caricato o meno. Calcola quante ore al giorno generi davvero token. Per meno di due o tre ore al giorno, il noleggio orario di una GPU è generalmente più conveniente sia in termini di velocità sia di costo. Per i job batch continui a bassa priorità conviene invece il VPS sempre attivo.