Quali modelli AI puoi eseguire in self-hosting?

Cosa determina i modelli AI che puoi eseguire in self-hosting

I modelli AI che puoi eseguire in self-hosting dipendono da un solo numero: la RAM disponibile sul server. La famiglia del modello e il framework contano molto meno rispetto al fatto che i pesi entrino in memoria lasciando margine libero. Questo articolo spiega i calcoli necessari per determinarlo. Installare un runtime è un'attività separata, descritta nella guida per eseguire Ollama su un VPS.

La risposta dipende da due costi. I pesi sono il costo fisso, determinato dal numero di parametri e dalla quantizzazione. La finestra di contesto è il costo variabile ed è l'elemento che spesso viene dimenticato, finché un modello caricato ieri non riesce più a essere caricato oggi.

Il calcolo del dimensionamento: bit per parametro

Un file del modello contiene quasi esclusivamente pesi. Ogni peso viene memorizzato con un determinato numero di bit. La quantizzazione consiste nel memorizzarli con meno bit rispetto alla precisione usata durante l'addestramento. Questo comporta una lieve perdita di accuratezza, ma consente di risparmiare molta memoria. La dimensione dipende direttamente da questo fattore:

weights in GB = (parameters in billions x bits per weight) / 8

I modelli vengono rilasciati a 16 bit, pari a 2 GB per miliardo di parametri. Per questo quasi nessuno esegue la precisione del rilascio su un VPS. Queste sono le quantizzazioni che incontrerai più spesso, con il numero medio effettivo di bit per peso:

• Q8_0 memorizza circa 8.5 bit per peso, quindi circa 1.1 GB per miliardo di parametri.
• Q6_K memorizza circa 6.6 bit, quindi circa 0.83 GB per miliardo di parametri.
• Q5_K_M memorizza circa 5.7 bit, quindi circa 0.71 GB per miliardo di parametri.
• Q4_K_M memorizza circa 4.8 bit, quindi circa 0.6 GB per miliardo di parametri.

Usa 0.6 GB per miliardo di parametri come valore di riferimento. Q4_K_M è la scelta predefinita più equilibrata su un server con memoria limitata: nella maggior parte delle attività la perdita di qualità rispetto a 8 bit è ridotta, mentre il file ha dimensioni quasi dimezzate. Sotto 4 bit la perdita aumenta rapidamente. Per questo, un modello 70B compresso a 2 bit in genere risponde peggio di un modello 32B a 4 bit della stessa generazione. Quando la memoria è limitata, passa a una classe dimensionale inferiore prima di scendere sotto 4 bit.

[
  {
    "label": "3B",
    "weights_gb": 1.8,
    "kv_8k_gb": 0.9,
    "kv_128k_gb": 14
  },
  {
    "label": "8B",
    "weights_gb": 4.8,
    "kv_8k_gb": 1,
    "kv_128k_gb": 16
  },
  {
    "label": "14B",
    "weights_gb": 8.4,
    "kv_8k_gb": 1.5,
    "kv_128k_gb": 24
  },
  {
    "label": "32B",
    "weights_gb": 19.2,
    "kv_8k_gb": 2,
    "kv_128k_gb": 32
  },
  {
    "label": "70B",
    "weights_gb": 42,
    "kv_8k_gb": 2.5,
    "kv_128k_gb": 40
  }
]

La colonna dei pesi riportata sopra applica la regola di 0.6 GB per miliardo. I file GGUF reali si discostano da questo valore di pochi punti percentuali, perché i livelli di embedding e di output vengono mantenuti a una precisione superiore rispetto al resto. Un modello 3B a 4 bit occupa circa 1.8 GB. Un modello 8B occupa 4.8 GB. Un modello 32B occupa 19.2 GB, mentre un modello 70B occupa 42 GB.

Perché la lunghezza del contesto richiede più RAM dei pesi

La cache KV (key value cache, lo stato dell'attenzione che il modello conserva per ogni token attualmente presente nella conversazione) è il secondo costo. Viene allocata quando il modello viene caricato, dimensionata in base alla lunghezza del contesto richiesta e cresce in modo lineare con tale lunghezza.

bytes per token = 2 x layers x kv_heads x head_dim x bytes per element

Con il contesto predefinito di Ollama, quel modello 8B usa mezzo gigabyte per la cache. Con 8192 token usa 1 GB. Con il contesto di 128k dichiarato nella relativa scheda, usa 16 GB, più di tre volte il peso dei pesi. Il modello 70B rappresenta il caso opposto: la sua cache a 128k è pari a 40 GB, meno dei suoi stessi pesi, perché la grouped query attention impedisce al costo per token di crescere quasi quanto il numero di parametri.

La lunghezza del contesto predefinita di Ollama è di 4096 token su un server che usa solo la CPU. Quando è presente una GPU, Ollama sceglie invece il valore predefinito in base alla VRAM: 32k tra 24 e 48 GiB e 256k con 48 GiB o più. Aumentala con la variabile OLLAMA_CONTEXT_LENGTH sul server, quindi verifica quale valore ha effettivamente ricevuto un modello in esecuzione nella colonna CONTEXT di ollama ps. I calcoli della memoria alla base di questa impostazione sono illustrati nell'articolo su num_ctx e sulla lunghezza del contesto.

Esistono due modi per ridurre nuovamente la cache. Richiedi il contesto necessario invece di quello dichiarato nella scheda del modello, perché la maggior parte delle attività di chat e programmazione rientra tra 8k e 32k. In alternativa, quantizza la cache stessa a 8 bit: in questo modo si dimezza, con un certo costo nel recupero delle informazioni su contesti lunghi.

Un modello residente mantiene la RAM occupata finché non viene scaricato

Ollama mantiene un modello in memoria per 5 minuti dopo l’ultima richiesta, quindi lo scarica. Questo valore predefinito è adatto a un laptop, ma non a un server: dopo ogni periodo di inattività, la prima richiesta deve nuovamente sostenere il tempo di caricamento.

ollama ps
ollama stop qwen3:4b

ollama ps elenca i modelli residenti. La colonna SIZE mostra la quantità di memoria occupata, mentre la colonna UNTIL indica quando scade la permanenza in memoria. Per mantenere un modello sempre caricato, imposta OLLAMA_KEEP_ALIVE=-1 sul servizio. Un valore di 0 lo scarica appena termina ogni risposta.

sudo systemctl edit ollama.service

[Service]
Environment="OLLAMA_KEEP_ALIVE=-1"
Environment="OLLAMA_CONTEXT_LENGTH=8192"

sudo systemctl daemon-reload
sudo systemctl restart ollama

Invia un prompt, quindi esegui nuovamente ollama ps dopo 10 minuti. Il modello è ancora elencato, ed è esattamente questo il punto: mantiene occupata quella RAM indipendentemente dal fatto che qualcuno lo stia utilizzando. Un modello mantenuto in memoria non rappresenta capacità disponibile. Su un VPS da 16 GB, un modello 8B con contesto da 8k occupa circa 6 GB per tutta la durata del servizio. Dimensiona quindi il server considerando il modello e l’applicazione, non il modello da solo. Mantenere un modello in memoria illustra il compromesso rispetto alla latenza di avvio a freddo.

Cosa può eseguire un VPS con 4 GB

Riserva circa 1 GB per il sistema operativo e il model server. Restano circa 3 GB. Questo consente di eseguire un modello da 1B a 4B a 4 bit, con il contesto predefinito di 4096 token. Ad agosto 2026, questa categoria comprende Llama 3.2 da 3B, Qwen 3 da 1.7B e 4B e i modelli più piccoli delle release Gemma e Phi. Considerali esempi di dimensioni, non raccomandazioni. I nomi cambiano ogni pochi mesi, ma il calcolo della memoria resta invariato.

Prevedi circa 6–14 token al secondo. I modelli di queste dimensioni svolgono bene attività circoscritte: classificazione, estrazione di tag, riepiloghi brevi e riscrittura di un paragrafo secondo lo stile adottato. Sono poco adatti al ragionamento in più passaggi e al codice distribuito su più file. Nessuna tecnica di prompting risolve questi limiti.

A questo livello, il problema principale è lo swap. Se il modello non entra in memoria, Linux non rifiuta di caricarlo. Sposta invece le pagine di memoria sul disco. Poiché la generazione di ogni token legge tutti i pesi una volta, la velocità crolla fino a richiedere alcuni secondi per token. Durante la generazione, controlla free -h e le colonne si e so di vmstat 1. Valori diversi da zero per swap in e swap out indicano che il modello è troppo grande per il piano scelto.

Cosa può eseguire un VPS da 8 a 16 GB

È in questa fascia che un modello self-hosted diventa generalmente utile. Con 8 GB è possibile eseguire un modello da 7B o 8B a 4 bit, con circa 4.8 GB di pesi e un contesto di 8k. Con 16 GB è possibile eseguire un modello da 13B o 14B a 4 bit, con circa 8.4 GB, oppure mantenere un modello da 8B a 8 bit se si preferisce usare la memoria per aumentare la precisione invece del numero di parametri.

Il limite è la velocità. Un modello da 8B su CPU genera circa 3-7 token al secondo, mentre un modello da 14B genera circa 1.5-3.5 token al secondo. Una persona legge circa da 5 a 10 token al secondo, quindi un modello da 8B su un VPS con CPU dà l'impressione di osservare una persona che digita lentamente. È una velocità sufficiente per un processo in background, ma stancante per una chat interattiva. Esecuzioni misurate di Qwen 3 a 8B e versioni superiori su un VPS mostrano il comportamento nella pratica.

Cosa può eseguire un VPS da 32 a 64 GB

Un modello 32B a 4 bit occupa circa 19.2 GB, quindi rientra in un piano da 32 GB con un contesto breve e funziona senza problemi su 48 GB o 64 GB. Un modello 70B a 4 bit occupa circa 42 GB, quindi richiede 64 GB prima ancora di aggiungere una cache.

Quindi valuta le prestazioni in modo realistico. Un modello 32B su CPU genera circa 0.6-1.5 token al secondo, mentre un modello 70B genera 0.2-0.5 token al secondo. Una risposta di 500 token del modello 70B richiede circa venti minuti. A questa velocità, la richiesta in genere termina prima che il modello abbia finito, perché prima scade il timeout configurato nel client o nel proxy davanti a Ollama. Da qui deriva l'errore deadline di contesto superata. Questi strumenti sono adatti all'elaborazione batch. Puoi assegnare loro una coda di documenti durante la notte e la velocità non sarà rilevante. Se li usi dietro un'interfaccia di chat, invece, la velocità diventa un fattore molto importante.

Il routing dei modelli a mixture of experts modifica questo calcolo. È l'unico dettaglio dell'architettura che vale la pena conoscere. Un modello MoE fa passare ogni token soltanto attraverso una piccola parte dei propri pesi. Un modello con 30B di parametri totali e 3B di parametri attivi per token richiede la memoria di un modello 30B e genera a una velocità simile a quella di un modello denso 3B, perché ogni token accede soltanto agli esperti attivi. Su una macchina da 32 GB, un modello MoE con queste caratteristiche è molto più utilizzabile di un modello denso 30B. La regola da ricordare è questa: i parametri totali determinano la memoria, mentre quelli attivi determinano la velocità.

Quanto è veloce, in pratica, l'inferenza sulla CPU?

Per generare un token è necessario leggere una volta dalla memoria tutti i pesi attivi. Non è possibile evitare questa operazione, quindi la velocità di generazione su CPU dipende dalla larghezza di banda della memoria, non dal numero di core. Il limite massimo si calcola dividendo la larghezza di banda effettivamente disponibile per la dimensione dei pesi in byte. Una piccola VPS condivisa raggiunge realisticamente da 10 a 25 GB al secondo complessivi sulle proprie vCPU, quindi un modello da 4.8 GB arriva al massimo a circa 2-5 token al secondo.

[
  {
    "label": "3B",
    "tokens_per_second_low": 6,
    "tokens_per_second_high": 14
  },
  {
    "label": "8B",
    "tokens_per_second_low": 3,
    "tokens_per_second_high": 7
  },
  {
    "label": "14B",
    "tokens_per_second_low": 1.5,
    "tokens_per_second_high": 3.5
  },
  {
    "label": "32B",
    "tokens_per_second_low": 0.6,
    "tokens_per_second_high": 1.5
  },
  {
    "label": "70B",
    "tokens_per_second_low": 0.2,
    "tokens_per_second_high": 0.5
  }
]

Questi intervalli sono quelli comunemente riportati su hardware VPS ordinario, non costituiscono un benchmark di una macchina specifica. Il risultato dipende dalla generazione della memoria, dal numero di canali presenti sull'host e dal numero di altri utenti che la utilizzano contemporaneamente. Misura il tuo risultato usando un tag di modello che hai già disponibile:

ollama run qwen3:4b --verbose "Write three sentences about disk latency."

Il riepilogo stampato al termine della risposta contiene una riga con il testo eval rate: ... tokens/s. Questo è il valore della velocità di generazione. Ignora la prima esecuzione della sessione, perché load duration nello stesso riepilogo include anche la lettura dei pesi dal disco. Misurare correttamente i token al secondo spiega come ottenere un valore utile per il confronto.

In questo caso ci sono due risultati che sorprendono. Aggiungere vCPU smette rapidamente di essere utile, perché oltre circa 8 core quelli aggiuntivi attendono i dati dalla memoria invece di eseguire calcoli. Inoltre, su un piano condiviso lo stesso comando restituisce valori diversi da un'ora all'altra: si tratta di CPU steal time causato da un altro utente rumoroso, non di un errore nella configurazione.

La lettura del prompt è un'operazione diversa dalla generazione della risposta. L'elaborazione del prompt è limitata dalla capacità di calcolo, quindi scala con il numero di core ed è il punto in cui una GPU offre il maggiore vantaggio. Un documento lungo richiede minuti per essere letto dalla CPU e secondi dalla GPU. Questo è il primo limite che si incontra quando si collega un agente di programmazione a un modello ospitato, perché a ogni turno è necessario inviare nuovamente il contesto del file e le definizioni degli strumenti prima che venga restituito anche un solo token della risposta.

Cosa cambia quando aggiungi una GPU

L’aritmetica non cambia; cambia soltanto il pool a cui si applica. La VRAM è un limite rigido, quindi calcola in anticipo cosa può entrare prima di noleggiare la macchina:

• 8 GB di VRAM contengono un modello 7B o 8B a 4 bit con un contesto breve.
• 16 GB contengono un modello 14B a 4 bit con un contesto reale, oppure un modello 8B a 8 bit.
• 24 GB contengono un modello 32B a 4 bit se il contesto resta breve.
• 48 GB o più contengono un modello 70B a 4 bit, lasciando spazio per la cache e la concorrenza.

Quando un modello non entra nella memoria disponibile, Ollama lo suddivide: alcuni layer vengono eseguiti sulla GPU e i rimanenti sulla CPU. ollama ps riporta questa suddivisione nella colonna PROCESSOR, con un valore simile a 78%/22% CPU/GPU. Considerala un’avvertenza, non una funzionalità. La metà eseguita sulla CPU determina il ritmo, perché ogni token deve comunque attendere il completamento di quei layer. Di conseguenza, un modello con un quarto dei layer sulla CPU funziona a una velocità molto più vicina a quella della CPU che a quella della GPU. Se vedi una suddivisione che non avevi previsto, riduci prima la lunghezza del contesto. Di solito è la cache ad aver superato il limite.

La concorrenza è un altro motivo per scegliere una configurazione più potente. I pesi sono condivisi tra le richieste simultanee, ma ogni richiesta attiva richiede una propria cache KV. Dieci utenti simultanei che usano un modello 8B con un contesto di 8k richiedono quindi dieci volte 1 GB di cache, oltre allo spazio occupato dai pesi. Gestire utenti simultanei con un unico modello self-hosted mostra come determinare il limite raggiunto in questo scenario.

Anche la convenienza del noleggio di una GPU dipende da un calcolo. Il fattore decisivo è il numero effettivo di token generati ogni mese. Il punto di pareggio tra una GPU VPS e i token API riporta questi valori.

Cosa non puoi ospitare autonomamente

Ci sono due ostacoli distinti. È utile capire quale dei due stai incontrando.

Il primo riguarda i modelli con pesi chiusi. I modelli commerciali di frontiera non vengono distribuiti, quindi non esiste alcun file da scaricare e nessuna quantità di RAM può cambiare questa situazione. Puoi ospitare autonomamente tutto ciò che li circonda: l'interfaccia, il livello di retrieval, il ciclo dell'agente e i log. Il modello resta invece disponibile tramite un'API remota. Se puoi ospitare autonomamente Claude analizza la questione in dettaglio.

Il secondo riguarda i modelli con pesi aperti che sono semplicemente troppo grandi. I modelli open più grandi sono architetture mixture of experts con centinaia di miliardi di parametri complessivi. La stessa regola vale anche in questo caso: un modello con 400B parametri complessivi a 4 bit richiede circa 240 GB solo per i pesi, prima di considerare qualsiasi cache. Servono hardware specializzati e il noleggio mensile costa molto più di quanto la maggior parte delle persone spenda in token API in un anno. Cosa serve per ospitare autonomamente un modello della classe Kimi illustra i requisiti effettivi. La stessa distinzione emerge nella libreria di Ollama, dove GLM 5.2 è disponibile solo come modello cloud e il modello affine, molto più piccolo, è quello che viene effettivamente scaricato su un VPS.

La distinzione corretta è questa: ospita autonomamente il modello quando il carico è costante e i dati non devono lasciare il tuo server. Acquista token quando il carico è variabile oppure quando ti serve realmente la qualità delle risposte dei modelli di frontiera.

Verifica le risorse disponibili prima di scegliere

free -h
nproc
lscpu | grep 'Model name'

Pianifica in base alla colonna available di free -h, non alla colonna total, perché total include la memoria già utilizzata dal sistema. Sottrai circa 1 GB per il sistema operativo e il server del modello. Dividi il valore rimanente per 0.6 per ottenere il numero massimo di parametri, espresso in miliardi, gestibile a 4 bit. Sottrai quindi la cache KV per il contesto che vuoi effettivamente utilizzare. Il valore rimanente è la risposta e, a differenza di un elenco di nomi di modelli, non diventa obsoleto.

FAQ

Quanta RAM serve per eseguire un modello 8B?

Circa 4.8 GB per i pesi con quantizzazione a 4 bit, più la cache KV per la lunghezza del contesto, più circa 1 GB per il sistema operativo e il model server. Con un contesto di 8192 token, la cache aggiunge circa 1 GB. Un piano da 8 GB è quindi sufficiente, mentre uno da 4 GB non lo è. Se vuoi usare l'intero contesto di 128k token dichiarato nella model card, la sola cache occupa 16 GB. In questo caso serve un piano da 32 GB.

Perché il modello è lento anche se il VPS dispone di molti vCPU?

Perché la generazione è limitata dalla larghezza di banda della memoria, non dal numero di core. Per generare ogni token è necessario trasferire dalla RAM l'intero insieme di pesi attivi. Quando alcuni core saturano i canali di memoria, gli altri restano in attesa. Un'altra causa comune è lo swap. Se vmstat 1 mostra un valore non nullo per si e so mentre il modello risponde, i pesi non entrano nella RAM. Una parte di ogni token viene quindi elaborata dal disco, con un costo molto superiore a quanto potrebbe sembrare.

Una finestra di contesto più lunga richiede davvero più memoria?

Sì. La crescita è lineare rispetto al numero di token. Un tipico modello 8B usa circa 128 KiB di cache KV per token. 8192 token richiedono 1 GB, mentre 131072 token richiedono 16 GB. La cache viene allocata quando il modello viene caricato, non quando la conversazione aumenta. Richiedere un contesto di 128k riserva quindi immediatamente quella memoria, anche se ogni prompt inviato contiene 200 token.

È meglio eseguire un modello grande a 2 bit o uno più piccolo a 4 bit?

Scegli il modello più piccolo a 4 bit. La qualità diminuisce lentamente passando da 8 a 4 bit e rapidamente al di sotto di 4 bit. Per questo, un modello 70B compresso a 2 bit fornisce in genere risposte peggiori rispetto a un modello 32B a 4 bit della stessa generazione. Una quantizzazione spinta si manifesta con ripetizioni e istruzioni ignorate, non con un messaggio di errore. È quindi facile attribuire il problema al prompt. Considera 4 bit il limite minimo e modifica invece il numero di parametri.

Posso eseguire in self-hosting un modello con capacità paragonabili a quelle dei grandi modelli commerciali?

Non su un VPS ordinario. I più potenti modelli open weight arrivano a centinaia di miliardi di parametri. A 4 bit richiedono oltre 200 GB di RAM, prima ancora di considerare la cache KV. I modelli commerciali più potenti, inoltre, non vengono distribuiti. L'hardware ordinario è adatto a eseguire un buon modello da 8B a 32B per un'attività specifica. In questo scenario, un modello piccolo con un prompt mirato e ben strutturato può spesso raggiungere le prestazioni di un modello generalista. Se ti serve una qualità di livello frontier, confronta il costo dell'API con quello dell'hardware prima di acquistare una delle due soluzioni.