vLLM vs Ollama: quale scegliere e quando migrare

vLLM vs Ollama: quale conviene scegliere?

Resta su Ollama per un portatile, un assistente privato o un piccolo servizio interno che risponde già abbastanza in fretta. Scegli vLLM per un servizio su GPU condiviso che gestisce richieste simultanee in modo continuativo, oppure quando serve un controllo esplicito sull'inferenza distribuita. Il solo fatto di eseguire il servizio su un server non giustifica il passaggio.

Ollama è un runner di modelli che riunisce download, configurazione ed erogazione del servizio in un flusso compatto. vLLM è un motore di inferenza progettato per pianificare molte richieste e gestirne la memoria di lavoro. Nessuno dei due è il modello: spostare la stessa applicazione dall'uno all'altro cambia il modo in cui viene eseguito.

La scelta dipende da quattro elementi: picco di richieste simultanee, memoria GPU disponibile, esatta versione e formato del modello e latenza promessa agli utenti. Il numero di utenti registrati è un indicatore poco utile. Un piccolo gruppo di sviluppatori che usa agenti può generare più lavoro simultaneo di un gruppo molto più numeroso che pone domande occasionali.

Costi software e documentazione verificati il 12 ottobre 2026. Il confronto si basa sulla documentazione e su un esempio di analisi dei costi; per questo articolo non sono stati eseguiti benchmark di inferenza. La pagina prezzi di Ollama include l'uso locale gratuito e la licenza del progetto vLLM ne consente l'uso senza costi software. Prezzi di Ollama, licenza di vLLM.

Le funzionalità riportate in tabella provengono dalla documentazione ufficiale sulla concorrenza di Ollama, dalla panoramica delle funzionalità di vLLM e dalla guida alla scalabilità di vLLM. Le preferenze sono valutazioni editoriali di quelle capacità documentate, non classifiche di velocità misurata.

Come scegliere in base a utenti, GPU e dimensioni del modello

Questi scenari servono a decidere cosa valutare per primo, non garantiscono una determinata capacità. Per «utenti» si intendono persone o agenti che generano lavoro simultaneo; le fasce sono esempi di pianificazione. Un modello 8B ha circa otto miliardi di parametri, cioè i valori numerici memorizzati che lo definiscono.

Le sole dimensioni del modello non bastano a decidere quale GPU acquistare. Un modello denso 8B idealizzato, con 4 bit per peso, richiede almeno 4 GB per i soli pesi; per un modello 70B il minimo è 35 GB. Il calcolo è parametri × bit ÷ 8, in byte decimali. Metadati della quantizzazione, tensori a precisione maggiore, runtime e memoria delle conversazioni si aggiungono a quel minimo. Nessuna delle due cifre è una raccomandazione sulla VRAM da acquistare.

Ecco perché «il modello si è caricato» è un criterio di accettazione debole. La macchina può contenere i pesi senza avere spazio sufficiente per le conversazioni che gli utenti tengono aperte. Scegli prima il checkpoint con la guida ai modelli locali per programmare, poi dimensiona l'infrastruttura per il carico che dovrà gestire.

Installazione e hardware: Ollama è più semplice sulla prima macchina

Ollama è la scelta migliore quando l'obiettivo immediato è usare un modello utile sull'hardware che si possiede già. Le versioni desktop e il flusso da riga di comando riducono le decisioni necessarie per il deployment. Su Linux, l'installazione documentata è:

curl -fsSL https://ollama.com/install.sh | sh
ollama run llama3.2

Usa ollama serve se il server non è già in esecuzione. La guida Linux descrive anche un servizio con avvio automatico: un servizio persistente è più adatto che lasciare aperto un terminale per rispondere alle richieste altrui.

Ollama supporta l'accelerazione GPU di Apple tramite Metal, hardware AMD selezionato tramite ROCm, GPU NVIDIA e ulteriori dispositivi Windows/Linux tramite Vulkan. La pagina dedicata a NVIDIA indica attualmente una compute capability pari o superiore a 5.0, con requisiti dei driver che variano per le schede più vecchie. Verifica la combinazione esatta di scheda e sistema operativo nell'elenco hardware di Ollama.

vLLM è la scelta migliore quando l'installazione è il primo passo verso un ambiente di inferenza da gestire come servizio. La guida rapida attuale per NVIDIA usa un ambiente Python isolato. Con uv installato e un driver GPU compatibile, la sequenza documentata è:

uv venv --python 3.12 --seed
source .venv/bin/activate
uv pip install vllm --torch-backend=auto

Questi comandi provengono dalla documentazione e non sono stati eseguiti per il confronto. Le installazioni su AMD e Intel seguono istruzioni diverse per il backend. Guida rapida di vLLM.

Il percorso di installazione NVIDIA di vLLM richiede Linux e una compute capability pari o superiore a 7.5. Questo percorso non supporta Windows in modo nativo; la documentazione indirizza gli utenti Windows verso WSL. NVIDIA non è l'unica opzione hardware: l'indice delle installazioni comprende anche AMD ROCm, Intel XPU, percorsi per CPU e Apple Silicon tramite il plugin vLLM-Metal, mantenuto dalla community. Requisiti GPU, indice delle installazioni.

Il percorso Apple usa MLX e modelli ottimizzati per MLX. Va valutato come backend a sé, senza presumere che si comporti come un server CUDA. Per chi lavora soprattutto su Mac, Ollama resta il punto di partenza più semplice. Se la scelta riguarda principalmente l'ambiente di lavoro desktop, consulta il confronto tra Ollama e LM Studio.

vLLM vs Ollama: nelle prestazioni conta la concorrenza

vLLM è il punto di partenza più solido per gestire richieste simultanee in modo continuativo, perché le sue funzioni documentate di scheduling affrontano proprio quel carico. Il throughput è la quantità totale di lavoro completato nel tempo. Non coincide con la rapidità con cui compare una singola risposta isolata.

vLLM include il continuous batching, che inserisce nuovo lavoro mentre le richieste in corso avanzano, e PagedAttention, che gestisce la cache di chiavi e valori usata durante la generazione del testo. Questa cache, solitamente chiamata KV cache, è la memoria di lavoro del modello per i token della conversazione. Panoramica delle funzionalità di vLLM.

Il chunked prefill suddivide la lettura di un prompt lungo in porzioni più piccole, che possono condividere il tempo di elaborazione con la generazione delle risposte già in corso. Il prefix caching riutilizza l'elaborazione delle parti iniziali identiche dei prompt, come un prompt di sistema ripetuto. Aiuta a elaborare il prompt; non elimina il lavoro necessario a generare i nuovi token della risposta. Scheduling e ottimizzazione, limiti del prefix caching.

Ollama supporta già le richieste parallele

Ollama documenta sia richieste parallele per modello sia più modelli caricati contemporaneamente, nei limiti della memoria disponibile. OLLAMA_NUM_PARALLEL controlla le prime; OLLAMA_MAX_LOADED_MODELS i secondi. OLLAMA_MAX_QUEUE limita il lavoro in attesa e un server sovraccarico può restituire HTTP 503. Le FAQ attuali indicano 1 come valore predefinito delle richieste parallele. Impostazioni di concorrenza di Ollama.

Per un piccolo assistente di supporto, aumentare il numero di richieste simultanee consentite può bastare. Una coda più lunga, però, non aggiunge capacità di calcolo: può semplicemente far aspettare di più i clienti prima del primo token. Ottimizza in funzione del tempo di risposta desiderato, non della coda più lunga che il server può accettare.

Il contesto può occupare la memoria prevista per altri utenti

Imposta esplicitamente il contesto prima di confrontare i motori. La pagina di Ollama dedicata al contesto descrive valori predefiniti che dipendono dalla memoria, mentre le FAQ ne indicano ancora uno fisso. Questa discrepanza nella documentazione è un motivo in più per verificare le impostazioni effettive, senza presumere che portatile e server coincidano. ollama ps mostra il contesto caricato e la distribuzione su CPU/GPU. Guida al contesto di Ollama.

In una configurazione esemplificativa, quattro conversazioni parallele da 8,192 token riservano capacità per 32,768 token di contesto. Rispetto a una conversazione da 4,096, la capacità complessiva del contesto è otto volte maggiore: non significa otto volte la RAM totale del processo. I pesi del modello e le altre allocazioni non crescono allo stesso modo. La documentazione di Ollama sulla concorrenza spiega questo moltiplicatore del contesto.

Anche vLLM incontra limiti di memoria. La guida all'ottimizzazione avverte che uno spazio KV insufficiente può causare interruzioni dell'esecuzione e ricalcoli, peggiorando la latenza. Ridurre le sequenze simultanee o il budget di token per batch è una possibile risposta; aggiungere GPU è un'altra. Uno scheduler più capace non può creare memoria che la macchina non ha.

Il momento di cambiare arriva quando, anche dopo un'ottimizzazione ragionevole, il servizio non rispetta gli obiettivi sotto un carico di picco rappresentativo. Registra tempo al primo token, tempo di completamento della risposta, richieste riuscite, crescita della coda ed errori. Confronta anche un percentile di coda, oltre alla mediana, perché gli utenti si accorgono dei casi lenti. vLLM espone metriche di produzione utili a questo lavoro.

Mantieni allineati revisione del modello, precisione, lunghezza dei prompt, limiti di output e andamento del traffico. Confrontare un piccolo modello quantizzato su Ollama con un checkpoint più grande ad alta precisione su vLLM significa confrontare due deployment, non misurare isolatamente i motori.

Formati quantizzati: anche il modello fa parte della migrazione

Ollama è preferibile per un pacchetto di modello locale già in uso; vLLM per scegliere un formato di inferenza adatto all'hardware. La quantizzazione memorizza i valori del modello con una precisione ridotta per contenere il fabbisogno di memoria. Contenitore del file, metodo di quantizzazione e backend di esecuzione pongono questioni di compatibilità distinte.

Ollama documenta l'importazione di pesi Safetensors e di modelli GGUF, sia in un unico file sia suddivisi in più file. GGUF è un formato di file per modelli diffuso nell'inferenza locale; la guida attuale di Ollama specifica che la quantizzazione GGUF deve avvenire prima dell'importazione, non durante. Separatamente, l'API di creazione cita nvfp4 come esempio di quantizzazione in fase di importazione. Questo non garantisce che il percorso sia supportato da ogni architettura e GPU. Guida all'importazione di Ollama, API di creazione.

Ollama indica anche f16, q8_0 e q4_0 per la KV cache. Sono impostazioni della cache, non un elenco intercambiabile di formati per i pesi del modello. L'uso della cache quantizzata richiede Flash Attention. Documentazione della cache di Ollama.

vLLM elenca AWQ/GPTQ, FP8, INT8, INT4, MXFP4/MXFP8, NVFP4 e altre integrazioni per la quantizzazione. La matrice di supporto varia in base all'implementazione e all'hardware: «supporta i 4-bit» non basta per decidere un acquisto. Verifica l'esatta combinazione di checkpoint e kernel. Documentazione sulla quantizzazione di vLLM, panoramica dei formati.

Un tokenizer converte il testo negli ID dei token che il modello comprende. Cambiare pesi, tokenizer, formattazione della chat o quantizzazione può modificare risposte, chiamate agli strumenti e uso della memoria. Prevedi verifiche di regressione anche se il nome della famiglia del modello resta invariato.

Mellum2.1 mostra perché conta il formato disponibile al lancio

L'annuncio di Mellum2.1 pubblicato da JetBrains l'8 ottobre 2026 illustra un rilascio pensato prima per i server: il post indicava come imminenti le versioni GGUF per Ollama, llama.cpp e LM Studio. La pagina del modello fornisce una configurazione per servirlo con vLLM e le integrazioni al lancio includono vLLM e SGLang, un altro server di inferenza. Post di lancio di JetBrains, pagina del rilascio.

Il divario iniziale si è già ridotto: alla verifica del 12 ottobre, il repository GGUF ufficiale di JetBrains contiene file quantizzati scaricabili. L'«in arrivo» del post di lancio non descrive più la disponibilità attuale. La lezione pratica è verificare i file disponibili e la configurazione di inferenza prima di cambiare motore solo per ottenere un nuovo modello. File GGUF ufficiali.

Server compatibili con OpenAI: il client resta, il comportamento va verificato

Entrambi documentano un server compatibile con OpenAI, ma richieste dalla stessa struttura non garantiscono lo stesso comportamento. L'URL di base locale di Ollama è http://localhost:11434/v1/; l'esempio di vLLM usa http://localhost:8000/v1. Se l'applicazione usa l'endpoint nativo /api/chat di Ollama, il passaggio richiede un adattamento dell'API, non solo un cambio di porta. Compatibilità di Ollama, documentazione del server vLLM.

Per esempio, dopo aver installato vLLM su hardware compatibile, questo comando avvia il modello usato nell'esempio documentato del server, con un limite di contesto esplicito e un nome esposto all'applicazione:

vllm serve NousResearch/Meta-Llama-3-8B-Instruct \
  --host 127.0.0.1 \
  --port 8000 \
  --max-model-len 8192 \
  --served-model-name app-model

È un esempio di configurazione: non usa il checkpoint corrispondente al precedente comando Ollama e non costituisce una raccomandazione per il dimensionamento in produzione. --served-model-name permette al client di mantenere un nome stabile per il modello mentre cambia il deployment. Argomenti del motore vLLM.

Controlla i template della chat, che trasformano i ruoli dei messaggi nel formato di input del modello, e imposta esplicitamente i parametri di campionamento. vLLM può applicare i valori predefiniti del file generation_config.json di un repository; --generation-config vllm disabilita questa sostituzione. Verifica parsing delle chiamate agli strumenti, output strutturato, streaming, annullamento e gestione degli errori usando le richieste reali dell'applicazione.

L'autenticazione fa parte della migrazione. L'esempio di compatibilità locale di Ollama ignora il valore della chiave API del client. vLLM supporta una chiave API, ma la documentazione sulla sicurezza avverte che non protegge tutti gli endpoint. Mantieni il backend privato e applica autenticazione, TLS e restrizioni sulle route al punto di accesso al servizio. Limiti della chiave API di vLLM.

Se l'app cambia spesso modello di base, c'è un altro costo di migrazione da considerare: le FAQ di vLLM descrivono l'uso di istanze server separate e di un livello di routing per gestire più modelli di base. Un alias API non carica un altro modello. Per uno strumento interno poco utilizzato, la gestione di più modelli caricati offerta da Ollama può essere più comoda. Limite di vLLM nella gestione di più modelli.

Confronto dei costi: stesso carico, spese di gestione diverse

Nessuno dei due motori vince grazie a una tariffa per token più bassa in self-hosting: il motore non fattura i token. I piani cloud a pagamento di Ollama sono un servizio separato, non un requisito per servire modelli locali. La guida ai prezzi di Ollama chiarisce questa distinzione; per le offerte cloud attuali, consulta la pagina del fornitore collegata sopra.

Con hardware di proprietà, il costo mensile comprende elettricità, quota del costo dell'hardware e tempo dedicato alla gestione. Con hardware a noleggio, parti dalle ore macchina quotate, poi aggiungi storage, rete e gestione operativa. Un'inferenza più efficiente fa risparmiare solo se riduce le risorse allocate, accorcia il tempo fatturabile o produce un beneficio aziendale a cui si può attribuire un valore.

Un esempio di budget a parità di condizioni

Quelle che seguono sono ipotesi esplicite di budget, non prezzi dei fornitori né risultati di benchmark: una GPU a $1 all'ora, 730 ore al mese e 100,000 elaborazioni completate con successo. Ogni elaborazione ha 2,000 token nel prompt e 1,000 token in output, usando lo stesso modello, la stessa quantizzazione, gli stessi requisiti di qualità e lo stesso obiettivo di latenza su entrambi i motori.

Se entrambi rispettano i requisiti su una GPU noleggiata in modo continuativo, ciascuno costa $730 al mese di calcolo, cioè $0.0073 per elaborazione riuscita e per 1,000 token in output. Il denominatore basato sui token in output mantiene costante il lavoro sui prompt; non è un prezzo misto per input e output.

Ipotizziamo ora due ore aggiuntive di gestione al mese per il deployment vLLM, a $100 all'ora, più quattro ore una tantum per la migrazione:

• Deployment Ollama di riferimento: $730 ricorrenti, prima dei costi comuni a entrambi.
• vLLM sullo stesso hardware: $930 ricorrenti, cioè $0.0093 per 1,000 token in output.
• Primo mese di vLLM, migrazione inclusa: $1,330, cioè $0.0133 per 1,000 token in output.

Queste ore sono valori da sostituire con una propria stima, non un'indicazione della durata effettiva della migrazione. Attività operative comuni, storage, costi di rete e imposte sono esclusi da entrambi i lati del confronto.

Quando cambia la convenienza economica

A quella tariffa oraria, vLLM deve far risparmiare più di 200 ore GPU al mese per compensare la gestione aggiuntiva ipotizzata. Recuperare tutti i $400 della migrazione nel primo mese porta la soglia a più di 600 ore GPU risparmiate.

Consideriamo un servizio sempre attivo: supponiamo che il tuo test di carico mostri che Ollama richiede due repliche GPU identiche, mentre a vLLM ne basta una per rispettare lo stesso carico e lo stesso tempo di risposta. La spesa di calcolo per Ollama sale a $1,460; quella per vLLM, inclusa la gestione aggiuntiva, resta a $930. Se queste condizioni si verificano, il risparmio è di $530 al mese e ripaga i $400 della migrazione in circa 0.75 mesi.

È un calcolo del punto di pareggio, non l'affermazione che vLLM dimezzi il fabbisogno di GPU. Se entrambi richiedono lo stesso hardware e nessun altro beneficio giustifica il passaggio, il confronto dei costi software non diventa mai favorevole a vLLM. Non esiste una soglia universale di utenti, sostenibile con i dati, oltre la quale la convenienza si inverte.

Una breve checklist per migrare da Ollama a vLLM

Sposta una combinazione validata di modello e comportamento API dietro un instradamento reversibile. I pesi scaricati sono solo una parte di ciò da cui dipendono gli utenti.

Non migrare ancora se Ollama rispetta gli obiettivi del servizio, se il modello richiesto non ha un percorso validato su vLLM o se il passaggio sostituirebbe soltanto un pacchetto funzionante con un backend che conosci poco. Può avere senso anche mantenere Ollama sui portatili e vLLM su un server condiviso, purché si verifichino le differenze invece di presumere che sviluppo e produzione siano identici. Per ampliare la scelta, consulta le alternative a Ollama.

Il prossimo passo è concreto: registra il carico rappresentativo più intenso, definisci il tempo di risposta accettabile e riproducilo sul server proposto prima di acquistare altra capacità.

Domande frequenti

Usa la checklist per valutare i flussi di lavoro aziendali con l'AI per scegliere quale flusso di lavoro privato merita un server di modelli condiviso e iscriviti alla newsletter per seguire le successive novità sugli strumenti.