Eseguire Qwen 27B su VPS con Ollama: guida e requisiti

È possibile eseguire Qwen 3.8 27B su una VPS priva di GPU?

Per eseguire Qwen 3.8 27B su una VPS è necessario innanzitutto un tag di modello esistente; 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, licenza Apache 2.0. Ogni comando e ogni numero riportato di seguito utilizza tale tag su Ollama v0.32.5, pubblicato il 27 luglio 2026.

La risposta breve è sì, su una VPS da 32 GB o superiore, ma con prestazioni lente. Un modello dense 27B in formato Q4 richiede circa 17 GB di RAM solo per i pesi, prima ancora che venga memorizzato un singolo token di contesto. Questo esclude completamente i piani da 8 GB e 16 GB. Su una comune VPS con memoria DDR4 a doppio canale, il limite massimo è di circa 3 token al secondo, una velocità inferiore alla capacità di lettura della maggior parte degli utenti.

Da dove deriva il valore 3.8? Molto probabilmente dal conteggio dei parametri. La pagina Ollama per qwen3.6:27b riporta 27,8B di parametri, e 27,8 è facile da ricordare in seguito come 3.8. Esiste anche una qwen3.5:27b, ovvero la stessa build Q4_K_M del rilascio precedente. Controlla l'elenco aggiornato prima di copiare qualsiasi comando, visitando la pagina del tag qwen3.6 di Ollama. Se in futuro venisse rilasciata una vera qwen3.8, i calcoli qui riportati rimarrebbero validi, poiché dipendono dal numero di parametri e dai bit per peso piuttosto che dal numero di versione.

Quale tag Ollama scaricare e come verificarlo

Scaricare un tag inesistente genera un errore chiaro, quindi è rapido risolvere il problema direttamente sul server. Un tag esistente potrebbe comunque non essere eseguibile localmente; questo è l'aspetto che trae in inganno gli utenti con GLM 5.2, presente nella libreria ma distribuito solo dal cloud di Ollama.

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 stampa l'architettura, il numero di parametri, la lunghezza del contesto e la quantizzazione del tag effettivamente in uso. Se la riga dei parametri riporta 27.8B e quella della quantizzazione Q4_K_M, si dispone della build su cui è basata questa guida. La libreria contiene anche qwen3.6:27b-q8_0 e qwen3.6:27b-bf16 per gli stessi pesi a una precisione superiore, oltre a una serie di tag 35b-a3b che sono modelli MoE (mixture of experts) e si comportano in modo molto diverso su CPU. Maggiori dettagli a riguardo sono riportati di seguito.

Conteggio dei 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 è su una riga. Byte dei pesi = parametri * bit per peso / 8. A 4 bit netti, 27,8 miliardi di parametri occuperebbero 13,9 GB. Il tag Q4_K_M rilasciato è di 17 GB, che corrisponde a 4.89 bit per peso nella pratica.

Questo scarto non è un errore. I formati K-quant non memorizzano ogni tensore alla larghezza nominale. I tensori che perdono più qualità durante la compressione vengono mantenuti a 5 o 6 bit, mentre i layer di token embedding e di output sono solitamente lasciati a Q6_K o Q8_0. Il nome del formato indica una media, e la media si attesta vicino a 4,9. Lo stesso effetto si nota all'altro estremo della scala: 56 GB per BF16 corrispondono a 16.1 bit per peso anziché 16 netti, poiché il file contiene anche metadati e una tabella di embedding a piena precisione.

Q5_K_M non ha un tag pubblicato per questo modello, quindi la riga da 19.8 GB è calcolata ai soliti 5,7 bit per peso previsti per quel formato, anziché misurata. Q8_0 quasi raddoppia Q4 arrivando a 30 GB. Su una macchina basata solo su CPU, tale raddoppio comporta il doppio del traffico di memoria per token, dimezzando di fatto i token al secondo. Q4_K_M è l'impostazione predefinita corretta per questo motivo. Se si preferisce dare priorità alla qualità rispetto alla memoria, un confronto più approfondito tra Q4, Q8 e fp16 mostra dove l'output inizia effettivamente a degradare.

Il costo della KV cache all'aumentare del contesto

I pesi rappresentano un costo fisso. La KV cache (cache di chiavi e valori, ovvero lo stato dell'attenzione che il modello mantiene per ogni token già elaborato) cresce in modo lineare con la lunghezza del contesto ed è la causa principale dell'esaurimento della 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 dati ipotizzano la struttura utilizzata da Qwen nei suoi recenti modelli densi di questa classe dimensionale: 64 layer, 8 head di chiave/valore con GQA (grouped-query attention) e una dimensione delle head pari a 128. Ciò corrisponde a 256 KiB per token in f16, ovvero 8 GB a 32k token e 32 GB a 128k. Non fare affidamento sui miei calcoli, verifica sulla tua macchina. Carica il modello e leggi la colonna SIZE di ollama ps, che riporta la somma di pesi, cache e overhead come valore unico.

Ecco perché il contesto da 256K indicato nella scheda del modello è un dato di marketing piuttosto che un piano operativo. Riempirlo in f16 richiederebbe 64 GB di cache oltre ai pesi, su una macchina che ne ha già impegnati 17 GB solo per questi ultimi. Ollama non assegna l'intera finestra di default. Ne carica una molto più piccola, che puoi aumentare intenzionalmente tramite OLLAMA_CONTEXT_LENGTH. Questa variabile a livello di server non è l'unica leva disponibile; impostare num_ctx sulla singola richiesta ti permette di mantenere un valore predefinito contenuto per le operazioni comuni, riservando una finestra più ampia solo a un job specifico. Aumenta il valore gradualmente e controlla ollama ps dopo ogni modifica.

Due impostazioni permettono di dimezzare (o ridurre ulteriormente) la cache. OLLAMA_KV_CACHE_TYPE=q8_0 memorizza la cache a 8 bit invece che a 16, riducendo il consumo per 32k token da 8 GB a 4 GB. Richiede flash attention, quindi imposta anche OLLAMA_FLASH_ATTENTION=1 e verifica l'effettiva riduzione in ollama ps invece di darla per scontata. Anche OLLAMA_NUM_PARALLEL=1 è altrettanto importante. Ollama può gestire diverse richieste simultaneamente e ogni slot ottiene la propria porzione di contesto; lasciare il parallelismo al valore predefinito moltiplica silenziosamente la cache che avevi pianificato. Se più persone utilizzeranno questa macchina, è proprio questa moltiplicazione a creare problemi, e il numero di utenti simultanei che un modello self-hosted può servire è determinato dagli slot di 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."
  }
]

I due numeri indicano le migliaia di token di contesto che possono essere gestiti insieme ai pesi, con cache f16, su una VPS Linux headless con circa 1,5 GB riservati al sistema operativo e un piccolo margine aggiuntivo. Lo zero indica che i pesi non entrano in memoria, quindi non è possibile eseguire il modello.

8 GB e 16 GB non sono configurazioni adatte. 17 GB di pesi non entrano in 16 GB di RAM e nessuna modifica alle impostazioni del contesto può risolvere il problema. Nemmeno l'aggiunta di swap è una soluzione. Ollama mappa in memoria il file GGUF; quando le pagine residenti superano la RAM, il kernel inizia a spostarle su disco e a rileggerle, causando il caricamento di gigabyte di dati per ogni singolo token. Il server raggiunge un elevato iowait e produce meno di un token al secondo.

32 GB rappresentano il punto di ingresso. I pesi occupano 17 GB e rimangono circa 13 GB liberi, che coprono circa 32k token di contesto f16 con un margine di sicurezza. I pesi Q8_0, con 30 GB, non entrano affatto in questo livello di memoria.

64 GB offrono una configurazione confortevole. La quantizzazione Q4 lascia spazio per circa 128k token di contesto, mentre i pesi Q8_0 entrano lasciando spazio per circa 64k token. Prima di acquistare 64 GB di RAM per utilizzare Q8, è necessario valutare cosa si sta ottenendo: un output leggermente migliore a metà della velocità, su una macchina che è già lenta. Per quasi tutti gli utenti, il compromesso migliore è utilizzare Q4 con un contesto più ampio.

Qual è la velocità di inferenza CPU su una VPS?

Generare un singolo token da un modello dense richiede la lettura di ogni peso dalla memoria. Non solo una parte. Tutti. Il limite di velocità non è quindi il numero di core, ma la larghezza di banda della memoria divisa per la dimensione dei pesi. A quantizzazione Q4, questo comporta 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 reali. L'output effettivo si attesta approssimativamente tra il 50 e il 70 percento del valore indicato, poiché la latenza della memoria e un prefetching imperfetto impediscono di raggiungere il picco teorico. Una VPS con DDR4-3200 a doppio canale ha un limite di 3 token al secondo, quindi aspettati circa 2. Una macchina con DDR5-4800 a doppio canale ha un limite di 4.5, quindi aspettati circa 3.

I server di grandi dimensioni richiedono cautela. Una piattaforma EPYC a dodici canali offre 460.8 GB/s e un limite di 27.1 token al secondo, ma non si noleggia un intero EPYC. La larghezza di banda della memoria è una risorsa condivisa tra tutti i tenant della macchina, pertanto una slice da 8 vCPU non dispone di dodici canali di banda esclusiva. Le guide focalizzate sulle GPU ignorano questo aspetto, che è il motivo per cui due piani VPS con lo stesso numero di vCPU possono differire di un fattore tre sullo stesso modello.

Aumentare le vCPU smette presto di essere utile per lo stesso motivo. Quando i core richiedono dati più velocemente di quanto il controller di memoria possa fornirli, i thread aggiuntivi introducono solo overhead di scheduling. Imposta OLLAMA_NUM_THREAD sul numero di core fisici, effettua una misurazione, quindi prova con la metà. Su molti piani condivisi, l'impostazione inferiore risulta più veloce.

L'elaborazione del prompt si comporta diversamente. Il prefill, ovvero il passaggio sull'input prima che appaia il primo token, è limitato dalla potenza di calcolo piuttosto che dalla larghezza di banda, quindi scala con i core. L'effetto pratico è una lunga pausa prima che inizi l'output su un prompt esteso, seguita dal ritmo costante e lento descritto sopra. Cronometra entrambe le fasi separatamente con --verbose, che stampa un prompt eval rate e un eval rate per ogni richiesta.

Se il modello dense da 27B risulta troppo lento, osserva i tag qwen3.6:35b-a3b prima di rinunciare alla 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 in cambio della velocità. Anche la scelta del runtime è importante, e Ollama e llama.cpp espongono controlli di ottimizzazione CPU differenti pur utilizzando lo stesso codice di inferenza sottostante.

Quando noleggiare invece 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 pubblicata fornisce una categoria di risposta diversa. Una scheda consumer da 24 GB ha un limite massimo di 59 token al secondo su questi pesi. Una scheda per data center attuale raggiunge 197. Non è un divario che si colma ottimizzando il numero di thread. La scheda esegue la sua memoria a 1008 GB/s, mentre il tuo VPS opera a decine.

Traccia quindi il limite in base al carico di lavoro piuttosto che alle preferenze. L'inferenza su CPU è la scelta corretta quando il lavoro è asincrono e nessuno è in attesa: riassunti notturni di una pila di documenti o un processo di classificazione notturno che viene eseguito mentre dormi. Noleggia una GPU nel momento in cui una persona è in attesa di un output, o nel momento in cui le richieste arrivano più velocemente di una ogni 30 secondi, poiché una macchina basata solo su CPU non ha margine di batching e la coda aumenta semplicemente.

Il confronto dei costi è meno ovvio di quanto sembri. Un VPS da 64 GB viene fatturato ogni ora del mese, indipendentemente dal fatto che il modello sia caricato o meno, mentre un'istanza GPU viene fatturata solo per le ore in cui la mantieni attiva. Se il tuo utilizzo reale è di due ore al giorno, la GPU noleggiata può essere sia più veloce che più economica. Calcola prima il tuo ciclo di lavoro, poi valuta il prezzo. Scegliere un VPS con una GPU copre cosa verificare sull'istanza stessa, e vLLM supera Ollama una volta che si servono richieste concorrenti su una GPU perché le gestisce correttamente in batch.

Esiste una terza opzione che le persone dimenticano. Mantieni il modello da 27B su CPU per il lavoro in batch e inserisci un modello API ospitato davanti al percorso interattivo. Nulla richiede che un singolo modello serva entrambi.

Installazione di Ollama e misurazione delle prestazioni del sistema

Lo script di installazione è quello ufficiale e configura un servizio systemd in esecuzione come utente dedicato ollama.

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

ollama --version dovrebbe restituire 0.32.5 o una versione successiva. Controlla free -g prima di scaricare qualsiasi elemento. Se la colonna total sulla riga Mem indica un valore inferiore a 32, interrompi l'operazione e scegli un modello più piccolo; scaricare 17 GB che non puoi eseguire comporta uno spreco di un'ora e di una notevole quantità di spazio su disco.

Imposta le opzioni di runtime in un override di systemd anziché nella shell. Il modello viene eseguito all'interno del servizio, pertanto non rileva il tuo 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 è la misurazione che ti serve. eval rate indica i token al secondo durante la generazione. prompt eval rate è la velocità di prefill. load duration indica il tempo necessario per leggere i pesi dal disco; questo è il motivo per cui OLLAMA_KEEP_ALIVE=60m è impostato: su CPU, ricaricare 17 GB dal disco a ogni richiesta costa più della richiesta stessa. Il timeout di inattività predefinito è di cinque minuti, un valore sufficientemente breve da far sì che una coda batch con intervalli tra gli elementi paghi ripetutamente quel costo di caricamento. Le opzioni per mantenere un modello residente coprono sia il campo keep_alive per singola richiesta, sia la persistenza dell'impostazione dopo un riavvio.

Mentre il modello è caricato, verifica l'impronta di memoria da un secondo terminale.

ollama ps

La colonna SIZE rappresenta l'effettiva impronta di memoria, inclusa la cache KV, e dovrebbe essere vicina al peso dei file più la riga relativa alla lunghezza del contesto nella tabella KV. Con 8192 token e una cache a 8-bit, prevedi circa un gigabyte oltre ai pesi, contro 2 GB se la cache rimanesse in f16. La colonna PROCESSOR dovrebbe indicare 100% CPU. Se indica un valore diverso, significa che un altro processo ha occupato la GPU e i valori di velocità riportati in questa guida non descrivono il tuo sistema.

Modalità di errore e stringhe esatte visualizzate

Il modello rifiuta di caricarsi. Ollama stampa una riga che nomina entrambe le cifre, nel formato model requires more system memory (18.6 GiB) than is available (15.2 GiB). Questo è il caso di errore gestito correttamente, poiché Ollama ha effettuato il controllo prima dell'allocazione invece di lasciare che fosse il kernel a gestire il problema. Riduci la lunghezza del contesto, passa a un tag più piccolo o effettua l'upgrade a un piano superiore.

Il processo scompare durante la generazione di una risposta. Il client non mostra nulla di utile e journalctl -u ollama -n 50 indica che il servizio si sta riavviando. Esegui dmesg -T | tail; una riga che riporta Out of memory: Killed process ... (ollama) indica che il processo è stato terminato dall'OOM killer del kernel. Ciò accade quando il controllo di pre-caricamento è passato, ma la cache è cresciuta oltre la stima durante una conversazione prolungata. 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. Digitare qwen3.8:27b produce esattamente questo errore, così come qualsiasi refuso nel numero di versione. Verifica il tag sulla pagina della libreria prima di imputare la colpa alla rete.

Tutto funziona ma è insopportabilmente lento. Una velocità inferiore a un token al secondo su una macchina con RAM sufficiente indica un problema di paging piuttosto che di calcolo. Esegui vmstat 1 durante la generazione. Una colonna si o so con valori diversi da zero indica che il kernel sta effettuando swap; la soluzione consiste nel ridurre il contesto o il numero di modelli caricati. Un valore wa costantemente alto senza attività di swap indica che i pesi mappati in memoria vengono riletti dal disco, il che significa che non rientrano effettivamente nella RAM.

Il primo token impiega 30 secondi e poi la generazione accelera. Si tratta della fase di prefill ed è normale. Un prompt di sistema lungo viene elaborato a ogni richiesta che non trova riscontro nella cache; pertanto, accorcia il prompt di sistema prima di modificare qualsiasi altra impostazione.

A cosa serve realmente un modello 27B basato solo su CPU

Imposta le aspettative basandoti sui numeri, non sulle speranze. A una velocità compresa tra due e quattro token al secondo, una risposta di 500 token richiede dai due ai quattro minuti. Questo è inutilizzabile per una chat, ma perfettamente gestibile per una coda di elaborazione. Un modello che "ragiona" prima di rispondere peggiora questo calcolo, poiché i token di ragionamento nascosti vengono generati alla stessa velocità ridotta della risposta; pertanto, adeguare il livello di sforzo di ragionamento al compito è una delle poche leve disponibili per abbreviare una risposta senza cambiare modello. Il riassunto di documenti, la marcatura in blocco, l'estrazione di campi da un archivio di file e la revisione del codice non presidiata tollerano questa latenza, poiché nessuno è in attesa della risposta. L'assistenza alla programmazione si trova esattamente su questo confine, quindi indirizzare un agente di programmazione verso un modello ospitato in locale è vantaggioso per attività in background come i messaggi di commit e la creazione di scheletri di test, ma non per i suggerimenti inline per cui si resta in attesa.

L'argomento della privacy è quello decisivo. Il modello viene eseguito su hardware che noleggi e controlli, nessuna richiesta lascia il server e non ci sono costi per singolo token. Questo ha un valore elevato per i dati regolamentati, anche a tre token al secondo. Valuta onestamente l'alternativa: l'hosting autonomo di un modello di frontiera richiede un ordine di grandezza superiore di hardware, e un modello 27B su CPU rappresenta il punto più economico di quella curva in cui l'output è ancora degno di essere letto.

Per eseguire il benchmark di tutto ciò sono necessari input strutturati reali, e la maggior parte delle API di dati pubbliche richiede un account prima ancora di poter misurare il throughput. L'endpoint demo di Strasmore (gestito da noi) risponde a query SQL in sola lettura su 22 anni di dati di mercato statunitensi senza bisogno di chiavi o registrazioni: una richiesta GET a https://ai.strasmore.com/api/demo/sql?sql=SELECT ticker, close FROM delayed_stocks_minute_aggs LIMIT 5 restituisce un JSON che puoi inviare direttamente a un ciclo di prompt, insieme all'SQL esatto che lo ha generato, in modo che il modello abbia qualcosa da riassumere che tu possa verificare in modo indipendente. I limiti sono 500 righe e 20 secondi per chiamata, comodamente superiori a quanto un sistema da due token al secondo possa consumare. L'elenco completo delle colonne si trova su https://api.strasmore.com/v1/schema.

Se questa è la tua prima installazione di Ollama, la guida completa per eseguire Ollama su una VPS copre la configurazione del servizio, l'API HTTP e le regole del firewall che questa guida presuppone tu abbia già implementato. Non esporre la porta 11434 su Internet. Ollama viene distribuito senza alcuna autenticazione nativa, quindi chiunque raggiunga la porta può utilizzare il tuo modello e leggere i tuoi 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 esistenti sono qwen3.5:27b e qwen3.6:27b, entrambi build Q4_K_M di un modello dense da 27,8 miliardi di parametri. Il valore 3.8 nel termine di ricerca è quasi certamente il conteggio di 27,8B parametri ricordato erroneamente come numero di versione. Controlla https://ollama.com/library/qwen3.6/tags per l'elenco aggiornato ed esegui pull su qwen3.6:27b se desideri la versione 27B rilasciata più di recente. Un tag inesistente genera un errore Error: pull model manifest: file does not exist.

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

32 GB sono il minimo pratico per la versione Q4_K_M. I pesi occupano 17 GB, il sistema operativo richiede circa 1,5 GB e la cache KV aggiunge circa 1 GB ogni 4000 token di contesto in f16. Un piano da 16 GB non può contenere i pesi; lo swap non è d'aiuto poiché il file è mappato in memoria e il kernel lo rilegge dal disco a ogni token. 64 GB offrono spazio per contesti lunghi o per 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 calcola dal 50 al 70 percento di tale valore. Una VPS con DDR4-3200 a doppio canale ha un limite teorico vicino a 3 token al secondo e ne eroga circa 2. Una macchina con DDR5-4800 a doppio canale ha un limite vicino a 4.5 e ne eroga circa 3. Le piattaforme server con più canali sembrano superiori sulla carta, ma la larghezza di banda della memoria è condivisa tra tutti i tenant dell'host; misura la tua con ollama run qwen3.6:27b --verbose e leggi la riga eval rate.

È meglio usare Q4 o Q8 su una VPS solo CPU?

Q4_K_M, in quasi tutti i casi. Q8_0 occupa 30 GB contro i 17 GB di Q4, richiedendo quindi un piano da 64 GB e spostando quasi il doppio dei dati in memoria per ogni token, il che dimezza approssimativamente i token al secondo. La differenza di qualità tra Q4_K_M e Q8_0 su un modello 27B è minima per la maggior parte delle attività. Investi la RAM in un contesto più lungo, poiché ciò modifica le capacità del modello invece della sola precisione formale.

Quando conviene noleggiare una GPU rispetto a una VPS con molta RAM?

Quando il ciclo di lavoro è ridotto o quando il tempo di attesa dell'utente è un fattore critico. Una GPU con 24 GB di memoria raggiunge circa 59 token al secondo con questi pesi, contro i 2 o 3 di una tipica VPS, e viene fatturata solo per le ore di utilizzo effettivo. Una VPS da 64 GB ha un costo mensile fisso, indipendentemente dal fatto che il modello sia caricato o meno. Calcola quante ore al giorno generi effettivamente token. Sotto le due o tre ore, il noleggio orario di una GPU è solitamente più vantaggioso sia in termini di velocità che di costi. Il lavoro batch continuo a bassa priorità è l'ambito in cui la VPS sempre attiva risulta vincente.