Qwen 3.8 27B su VPS con Ollama: requisiti e limiti

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

Per eseguire Qwen 3.8 27B su un VPS serve prima di tutto un tag del modello realmente disponibile. Al 4 agosto 2026, nella libreria Ollama non esiste 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 Q4 richiede circa 17 GB di RAM soltanto per i pesi, prima di memorizzare anche un solo token di contesto. I piani da 8 GB e 16 GB sono quindi completamente esclusi. 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 delle persone.

Da dove deriva il numero 3.8? Molto probabilmente dal conteggio dei parametri. La pagina Ollama di qwen3.6:27b indica 27.8B parametri, e in seguito è facile ricordare erroneamente 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 qualsiasi comando, nella pagina dei tag qwen3.6 di Ollama. Se in seguito viene rilasciato un qwen3.8 reale, i calcoli riportati qui rimangono 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 download di un tag inesistente restituisce un errore chiaro. Puoi quindi verificare rapidamente la scelta 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 stampa 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, hai la build a cui fa riferimento questa guida. La libreria include anche qwen3.6:27b-q8_0 e qwen3.6:27b-bf16 con 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 è una sola riga. Byte dei pesi = parametri * bit per peso / 8. Con 4 bit effettivi, 27.8 miliardi di parametri corrisponderebbero a 13.9 GB. Il tag Q4_K_M distribuito è di 17 GB, che corrispondono a 4.89 bit per peso nella pratica.

Questa differenza non è 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 solitamente 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: 56 GB per BF16 corrispondono a 16.1 bit per peso anziché a 16 fissi, perché il file contiene anche metadati e una tabella di embedding a precisione completa.

Per questo modello non esiste un tag Q5_K_M pubblicato, quindi la riga da 19.8 GB è calcolata usando i consueti 5.7 bit per peso di quel formato, anziché essere misurata. Q8_0 quasi raddoppia le dimensioni rispetto a Q4, arrivando a 30 GB. Su un sistema con solo CPU, questo raddoppia il traffico di memoria per token e riduce quindi all'incirca della metà il numero di token al secondo. Per questo motivo, Q4_K_M è la scelta predefinita corretta in questo caso.

Quanto costa la 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 in modo lineare con la lunghezza del contesto ed è il punto in cui la maggior parte degli utenti esaurisce effettivamente 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 si basano sull'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 delle head pari a 128. Il risultato è 256 KiB per token a f16, quindi 8 GB con 32k token e 32 GB con 128k. Non dare per scontati questi calcoli sul tuo server. Carica il modello e leggi la colonna SIZE di ollama ps, che indica pesi, cache e overhead come valore unico.

Per questo il contesto da 256K indicato nella scheda del modello è un dato di riferimento, non un'impostazione operativa. Riempirlo a f16 richiederebbe 64 GB di cache oltre ai pesi, su una macchina che ha già allocato 17 GB per i pesi. Ollama non assegna per impostazione predefinita 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 senza segnalarlo la cache prevista nel dimensionamento.

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 che possono essere caricati insieme ai pesi, con cache f16, su un VPS Linux headless con circa 1.5 GB lasciati al sistema operativo e un piccolo margine aggiuntivo. Zero significa che i pesi non entrano nella RAM e quindi non è possibile caricare alcun 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, quindi ogni token deve leggere gigabyte dal disco. Il server resta con un iowait elevato e produce ampiamente meno di un token al secondo.

32 GB sono il punto di ingresso. I pesi occupano 17 GB e restano 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 offrono un margine adeguato. Con Q4 restano 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 attenzione 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ù lungo è il compromesso migliore.

Quanto è veloce l'inferenza CPU su un VPS?

Generare un token da un modello denso significa leggere tutti i pesi dalla memoria una volta. Non solo una parte. Tutti. Per questo il limite di velocità non è 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à raggiunge 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 2 canali ha un limite di 3 token al secondo, quindi aspettati circa 2. Un server con DDR5-4800 a 2 canali ha un limite di 4.5, quindi aspettati circa 3.

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

Per lo stesso motivo, l'aumento delle vCPU smette presto di essere utile. Quando i core richiedono dati più velocemente di quanto il controller di memoria possa fornirli, i thread aggiuntivi aggiungono solo overhead di scheduling. Imposta OLLAMA_NUM_THREAD sul numero di core fisici, misura le prestazioni, quindi prova 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è l'elaborazione dell'input prima che venga visualizzato il primo token, è limitato dalla capacità di calcolo e non dalla larghezza di banda. Per questo scala con il numero di core. In pratica, con un prompt lungo si verifica una pausa significativa prima dell'inizio dell'output, seguita dalla velocità costante e ridotta descritta sopra. Misura separatamente le due fasi con --verbose, che stampa un prompt eval rate e un eval rate per ogni richiesta.

Se il modello denso da 27B è semplicemente troppo lento, controlla 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. Di conseguenza, il traffico di memoria per token diminuisce di quasi un ordine di grandezza, anche se il file su disco è più grande. In questo modo sacrifichi l'occupazione di RAM per ottenere maggiore velocità. Anche la scelta del runtime è importante. Ollama e llama.cpp espongono controlli diversi per l'ottimizzazione della 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 produce una risposta di categoria 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 raggiunge 197. Non è una differenza che si possa colmare regolando il numero di thread. La scheda esegue l'accesso alla memoria a 1008 GB/s, mentre il VPS raggiunge alcune decine di GB/s.

Stabilisci quindi il limite in base al carico di lavoro, non alle preferenze. L'inferenza su CPU è la scelta corretta quando il lavoro è asincrono e nessuno attende il risultato: ad esempio, il riepilogo notturno di una raccolta di documenti o un processo di classificazione giornaliero eseguito durante la notte. Noleggia una GPU non appena una persona deve attendere l'output oppure quando arrivano richieste a una frequenza superiore a una ogni 30 secondi, perché un server con sole 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, mentre un'istanza GPU viene fatturata soltanto per le ore in cui la lasci in esecuzione. Se l'utilizzo effettivo è di due ore al giorno, la GPU noleggiata può essere sia più veloce sia più economica. Calcola prima il duty cycle, quindi confronta i prezzi. Scelta di un VPS con una GPU spiega cosa verificare sull'istanza, mentre vLLM supera Ollama quando servi richieste concorrenti su una GPU perché gestisce correttamente il batching.

Esiste una terza opzione che spesso viene trascurata. Mantieni il modello 27B sulla CPU per i processi batch e usa un modello tramite API hosted per il percorso interattivo. Nulla impone di usare un unico modello per entrambi gli scopi.

Installare Ollama e misurare il proprio sistema

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

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

ollama --version dovrebbe visualizzare 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 occupa 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 misurazione richiesta. 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 17 GB dal disco a ogni richiesta richiede più tempo 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 KV cache, e dovrebbe essere vicina alla dimensione dei pesi più la riga relativa alla lunghezza del contesto nel grafico della KV cache. Con 8192 token e una cache a 8 bit, prevedere circa un gigabyte aggiuntivo rispetto ai pesi, contro 2 GB se la cache rimanesse in formato f16. La colonna PROCESSOR dovrebbe visualizzare 100% CPU. Se visualizza un valore diverso, un processo ha utilizzato una GPU e i valori di velocità riportati in questa guida non descrivono il proprio sistema.

Modalità di errore e stringhe esatte visualizzate

Il modello non viene caricato. Ollama stampa una riga che indica entrambe le cifre, nel formato model requires more system memory (18.6 GiB) than is available (15.2 GiB). È un errore positivo, 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 mostra 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. Questo accade 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 è disponibile nella library. L'esecuzione di qwen3.8:27b produce esattamente questo risultato, così come qualsiasi errore di battitura nel numero di versione. Verifica il tag nella pagina della library prima di attribuire il problema alla rete.

Tutto funziona, ma il sistema è estremamente lento. Una velocità inferiore a un token al secondo su un host con RAM sufficiente indica un problema di paging, non di capacità di calcolo. Esegui vmstat 1 durante la generazione. Una colonna si o so diversa da zero indica che il kernel sta usando lo swapping; la soluzione consiste nel ridurre il contesto o nel caricare meno modelli. Un valore wa costantemente elevato 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 system prompt lungo viene elaborato nuovamente per ogni richiesta che non utilizza la cache. Riduci quindi il system prompt prima di intervenire su altri parametri.

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. Questo è inutilizzabile per una chat, ma del tutto adeguato 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 sta aspettando la risposta.

Il vantaggio principale è la privacy. Il modello viene eseguito su hardware che noleggi e controlli, 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ò in modo realistico questa soluzione con l'alternativa: per eseguire in self-hosting un modello di dimensioni paragonabili ai modelli più avanzati servono risorse hardware di un ordine di grandezza superiore, mentre un modello 27B su CPU rappresenta il punto più economico di questa curva in cui l'output è ancora utile da leggere.

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

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 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 27B rilasciata. Un tag inesistente restituisce l'errore 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 circa 1 GB ogni 4000 token di contesto a f16. Un piano da 16 GB non può contenere nemmeno i pesi. Lo swap non risolve il problema, perché il file è mappato in memoria e il kernel deve rileggerlo dal disco a ogni token. 64 GB consentono di usare un contesto più lungo oppure i pesi Q8_0, che occupano 30 GB.

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

Dividi la larghezza di banda della memoria per la dimensione dei pesi, quindi considera il 50-70% del risultato. Un VPS DDR4-3200 a due canali ha un limite teorico vicino a 3 token al secondo e raggiunge circa 2. Un sistema DDR5-4800 a due canali ha un limite teorico vicino a 4.5 e raggiunge circa 3. Le piattaforme server con più canali hanno valori teorici 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.

È meglio usare Q4 o Q8 su un VPS con sola CPU?

Q4_K_M, quasi sempre. Q8_0 occupa 30 GB rispetto ai 17 GB di Q4_K_M. 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. Su un modello 27B la differenza di qualità tra Q4_K_M e Q8_0 è ridotta per la maggior parte delle attività. È preferibile usare la RAM per un contesto più lungo, perché questo modifica ciò che il modello può fare, 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 quando c'è una persona in attesa del risultato. Una GPU con 24 GB di memoria raggiunge circa 59 token al secondo con questi pesi, rispetto ai 2 o 3 di un VPS tipico, e viene fatturata soltanto per le ore di utilizzo. 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 è in genere più conveniente sia in termini di velocità sia di costo. Il VPS sempre attivo è invece vantaggioso per i processi batch a bassa priorità eseguiti continuativamente.