Quali modelli AI puoi eseguire in self-hosting?

Cosa determina quali modelli AI puoi eseguire in self-hosting

Quali modelli AI puoi eseguire in self-hosting dipende da un solo valore: la RAM disponibile sul server. La famiglia del modello e il framework contano molto meno della possibilità di caricare i pesi in memoria lasciando una quantità sufficiente di RAM libera. Questo articolo illustra i calcoli necessari per determinarlo. Installare un runtime è un'attività separata, descritta in la guida per eseguire Ollama su un VPS.

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

Il calcolo del dimensionamento: bit per parametro

Un file di modello contiene quasi esclusivamente pesi. Ogni peso viene memorizzato con un determinato numero di bit. La quantizzazione consiste nel memorizzare i pesi 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 rapporto:

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

I modelli vengono rilasciati a 16 bit, equivalenti a 2 GB per miliardo di parametri. Per questo quasi nessuno esegue la precisione originale su un VPS. Queste sono le quantizzazioni che incontrerai più spesso, con il loro 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.
• Q5_K_M memorizza circa 5.7 bit, quindi circa 0.71 GB per miliardo.
• Q4_K_M memorizza circa 4.8 bit, quindi circa 0.6 GB per miliardo.

Usa 0.6 GB per miliardo di parametri come valore di riferimento. Q4_K_M è la scelta predefinita più sensata su un sistema con memoria limitata: nella maggior parte delle attività la perdita di qualità rispetto a 8 bit è contenuta e il file ha dimensioni quasi dimezzate. Sotto 4 bit la perdita aumenta rapidamente. Per questo, nella stessa generazione, un modello 70B compresso a 2 bit risponde di norma peggio di un modello 32B a 4 bit. Quando la memoria è limitata, passa a una classe di dimensioni 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 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 KV cache (key value cache, lo stato dell'attenzione che il modello mantiene 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 linearmente 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 scheda del modello, usa 16 GB, cioè più di tre volte la memoria occupata dai pesi. Il modello 70B presenta il caso opposto: con un contesto di 128k, la sua cache occupa 40 GB, meno dei pesi stessi, 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 con la sola CPU. Quando è presente una GPU, Ollama sceglie invece il valore predefinito in base alla VRAM: 32k tra 24 e 48 GiB e 256k da 48 GiB in su. È possibile aumentarla con la variabile OLLAMA_CONTEXT_LENGTH sul server, quindi verificare il valore effettivamente assegnato a un modello in esecuzione nella colonna CONTEXT di ollama ps. Il calcolo della memoria alla base di questa impostazione è illustrato nell'articolo su num_ctx e sulla lunghezza del contesto.

Esistono due modi per ridurre nuovamente la cache. Richiedere il contesto necessario invece di quello dichiarato nella scheda del modello, poiché la maggior parte delle attività di chat e programmazione rientra tra 8k e 32k. In alternativa, quantizzare la cache stessa a 8 bit: in questo modo si dimezza, al costo di una possibile riduzione del richiamo delle informazioni nei 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, dove la prima richiesta dopo ogni periodo di inattività deve attendere nuovamente il caricamento.

ollama ps
ollama stop qwen3:4b

ollama ps mostra i modelli residenti. La colonna SIZE indica quanta memoria occupa ciascun modello. La colonna UNTIL indica quando scade. Per mantenere un modello sempre caricato, imposta OLLAMA_KEEP_ALIVE=-1 sul servizio. Il valore 0 lo scarica al termine di 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. Questo è esattamente il comportamento previsto: mantiene occupata quella RAM anche se nessuno lo sta 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 solo modello. Mantenere un modello in memoria illustra il compromesso rispetto alla latenza di avvio a freddo.

Cosa può eseguire un VPS da 4 GB

Riservate circa 1 GB al sistema operativo e al model server; restano quindi circa 3 GB. Questo consente di usare 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 le versioni più piccole di Gemma e Phi. Considerateli esempi di dimensioni, non raccomandazioni. I nomi cambiano ogni pochi mesi, ma il calcolo non cambia.

Prevedete 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 aziendale. Sono meno efficaci nel ragionamento a più passaggi e nel codice distribuito su più file. Nessuna tecnica di prompting risolve questo limite.

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

Cosa eseguire su un VPS da 8 a 16 GB

È il livello in cui un modello self-hosted diventa generalmente utile. Su 8 GB puoi eseguire un modello da 7B o 8B a 4 bit, con circa 4.8 GB di pesi e un contesto da 8k. Su 16 GB puoi 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 preferisci usare la memoria per la precisione invece che per il 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 a una velocità di circa 5-10 token al secondo, quindi un modello da 8B su un VPS con CPU dà l'impressione di osservare una persona che scrive lentamente. È adeguato per un processo in background, ma può risultare lento per una chat interattiva. Esecuzioni misurate di Qwen 3 a 8B e oltre su un VPS mostrano il comportamento nella pratica.

Cosa esegue una 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 comodamente 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.

Poi bisogna valutare la velocità in modo realistico. Un modello 32B eseguito sulla CPU produce circa 0.6-1.5 token al secondo, mentre un modello 70B produce da 0.2 a 0.5 token al secondo. Una risposta di 500 token generata dal modello 70B richiede circa venti minuti. Questi strumenti sono adatti all'elaborazione in batch. È possibile inserirvi una coda di documenti durante la notte senza che la velocità rappresenti un problema. Se invece vengono collegati a un'interfaccia di chat, la velocità diventa molto importante.

Il routing dei modelli Mixture of Experts modifica questo calcolo, ed è l'unico dettaglio architetturale che vale la pena comprendere. Un modello MoE instrada ogni token solo 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 legge soltanto gli 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 i parametri attivi determinano la velocità.

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

Per generare un token è necessario leggere dalla memoria tutti i pesi attivi, una volta. Non è possibile evitare questo passaggio, 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 utilizzabile della memoria per la dimensione dei pesi in byte. Un piccolo VPS condiviso offre realisticamente da 10 a 25 GB al secondo attraverso le vCPU, quindi un modello da 4.8 GB raggiunge al massimo 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 il risultato di un benchmark eseguito su una macchina specifica. Il valore dipende dalla generazione della memoria, dal numero di canali disponibili sull'host e dal numero di vicini che la stanno utilizzando. Misura il tuo valore usando un tag di modello che hai già:

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

Il riepilogo visualizzato al termine della risposta contiene una riga con il testo eval rate: ... tokens/s. Questa è la velocità di generazione. Ignora la prima esecuzione di una 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 i confronti.

Qui ci sono due risultati che spesso sorprendono. Aggiungere vCPU smette rapidamente di essere utile, perché oltre circa 8 core quelli aggiuntivi restano in attesa della memoria invece di eseguire calcoli. Inoltre, su un piano condiviso lo stesso comando restituisce valori diversi da un'ora all'altra. Si tratta del tempo di steal della CPU causato da un vicino rumoroso, non di un errore nella configurazione.

La lettura del prompt è un'attività 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 a una CPU per essere letto, mentre a una GPU bastano pochi secondi. Questo è il primo limite che si incontra quando si indirizza un agente di coding verso un modello ospitato, perché a ogni turno vengono reinviati 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 solo il pool a cui si applica. La VRAM è un limite rigido, quindi calcola cosa può contenere prima di noleggiare la GPU:

• 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 mantenendo breve il contesto.
• 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, i restanti sulla CPU. ollama ps mostra la suddivisione nella colonna PROCESSOR, con un valore simile a 78%/22% CPU/GPU. Considerala un avviso, non una funzionalità. La metà eseguita sulla CPU determina il ritmo, perché ogni token deve comunque attendere quei layer. Di conseguenza, un modello con un quarto dei layer sulla CPU opera 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 a causare il superamento del limite.

La concorrenza è un altro motivo per scegliere una GPU più capiente. 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 alla memoria occupata dai pesi. Gestire utenti simultanei con un unico modello self-hosted spiega in quali condizioni si raggiunge questo limite.

Anche stabilire se valga la pena noleggiare la GPU è una questione aritmetica. Dipende dal 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

Esistono due limiti distinti e conviene capire quale dei due stai incontrando.

Il primo riguarda i pesi chiusi. I modelli commerciali frontier non vengono distribuiti, quindi non esiste alcun file da scaricare e nessuna quantità di RAM può cambiare la 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 il problema in dettaglio.

Il secondo riguarda i pesi aperti che sono semplicemente troppo grandi. I modelli open più grandi sono architetture mixture of experts con centinaia di miliardi di parametri totali. La stessa regola vale anche in questo caso: un modello con 400B parametri totali a 4 bit richiede circa 240 GB solo per i pesi, prima di considerare qualsiasi cache. Si tratta di hardware specializzato 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 descrive i requisiti effettivi.

La distinzione corretta tra i due casi è questa: scegli l’hosting autonomo quando il carico è costante e i dati non devono lasciare il tuo server. Acquista token quando il carico è variabile oppure quando hai realmente bisogno della qualità delle risposte di un modello frontier.

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, che puoi gestire a 4 bit. Sottrai quindi la cache KV necessaria per il contesto effettivo che vuoi 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?

Servono circa 4.8 GB per i pesi con quantizzazione a 4 bit, oltre alla cache KV per la lunghezza del contesto e a 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 da 128k indicato nella scheda del modello, 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, il sistema deve leggere dalla RAM l'intero insieme di pesi attivo. 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 diverso da zero per si e so mentre il modello sta rispondendo, i pesi non entrano nella RAM. Una parte di ogni token viene quindi elaborata usando il disco, con un costo molto superiore a quanto si potrebbe prevedere.

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

Sì, e la crescita è lineare rispetto al numero di token. Un modello 8B tipico usa circa 128 KiB di cache KV per token. Di conseguenza, 8192 token richiedono 1 GB, mentre 131072 token richiedono 16 GB. La cache viene allocata quando il modello viene caricato, non quando cresce la conversazione. Richiedere un contesto da 128k riserva quindi immediatamente questa 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 solitamente risposte peggiori di un modello 32B a 4 bit della stessa generazione. Una quantizzazione aggressiva 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. Con una quantizzazione a 4 bit, questo richiede oltre 200 GB di RAM, senza considerare la cache KV. I modelli commerciali più potenti, inoltre, non vengono distribuiti affatto. L'hardware ordinario è adatto a eseguire un buon modello da 8B a 32B per un'attività specifica. In questi casi, un modello piccolo, specializzato e con un prompt ben progettato spesso raggiunge le prestazioni di un modello generico. Se ti serve una qualità di livello frontier, confronta il costo dell'API con quello dell'hardware prima di acquistare una delle due soluzioni.