Ollama vs vLLM : quale runtime LLM per la produzione?

Scegliere tra Ollama e vLLM significa trovare un equilibrio tra semplicità di distribuzione e throughput puro con richieste concorrenti. Questo confronto orienta oggi gran parte delle decisioni sull'infrastruttura autogestita per gli LLM a pesi aperti, sia per fornire un servizio a un agente interno sia per esporre un'API multi-tenant. Confronteremo qui i due runtime dal punto di vista dell'architettura, del throughput misurabile sulle GPU NVIDIA, della gestione della memoria (KV cache, PagedAttention), delle licenze e dei formati supportati e dei costi operativi, per poi concludere con raccomandazioni in base alle dimensioni del modello e una FAQ tecnica. Il nostro obiettivo: consentire a un ingegnere di piattaforma di decidere in meno di quindici minuti di lettura.

Architettura e filosofia: due runtime, due mondi

Ollama è un wrapper attorno a llama.cpp, scritto in Go, che espone una semplice API HTTP e gestisce il download, il caching e il caricamento dinamico dei modelli GGUF. Il suo pubblico di riferimento storico: le macchine degli sviluppatori (Mac serie M, PC desktop RTX) e i deployment single-tenant leggeri. Il runtime sottostante effettua in modo trasparente l'offloading sulla CPU, permettendo di eseguire un Qwen 2.5 72B Instruct (VRAM Q4 ~42 GB) su una RTX 4090 da 24 GB ricorrendo alla RAM di sistema, a scapito del throughput.

vLLM, pubblicato da UC Berkeley, è un server Python ottimizzato per il serving ad alta concorrenza. Il suo contributo chiave è PagedAttention, che gestisce la cache KV come la memoria virtuale di un sistema operativo: blocchi di dimensione fissa, paginazione, condivisione tra richieste. In pratica, laddove un runtime ingenuo spreca il 60-80% della cache KV a causa della frammentazione, vLLM scende sotto il 4%. Il risultato è un throughput aggregato da 2 a 24 volte superiore a seconda del carico, ma con un costo iniziale: nessuna quantizzazione GGUF nativa, dipendenza stretta da CUDA, modello interamente in VRAM.

Per approfondire la differenza di approccio tra llama.cpp e vLLM per il serving, consulta la nostra guida completa llama.cpp vs vLLM.

Throughput e latenza: cosa dicono i numeri

Le misurazioni pubbliche concordano su un punto: con carichi simultanei, vLLM domina nettamente. Su un Llama 3.3 70B Instruct (70B, ctx 128 000) servito in FP8 su 4× A100 80 GB, si osserva tipicamente (da confermare in base alla dimensione del batch) :

La differenza si accentua ancora sui modelli MoE come Mixtral 8x22B Instruct (141B, Apache 2.0, ctx 64K) in cui vLLM sfrutta il tensor parallelism multi-GPU con un'efficienza che llama.cpp fatica a raggiungere. Per i modelli MoE molto grandi come DeepSeek V3 671B o Qwen 3 235B-A22B, vLLM rimane l'unica scelta realistica per la produzione multiutente, soprattutto grazie al supporto nativo del parallelismo degli esperti.

Tuttavia, per un carico single-stream con quantizzazione aggressiva (Q4_K_M, Q5_K_M), Ollama regge il confronto in termini di latenza del primo token (TTFT), talvolta inferiore sui modelli 7B-13B grazie alla leggerezza del runtime. Per un benchmark dettagliato su GPU consumer, vedi il nostro confronto RTX 4090 vs RTX 5090 per LLM.

Quantizzazione, formati e VRAM effettiva

È qui che i due runtime divergono radicalmente. Ollama utilizza esclusivamente GGUF (da Q2_K a Q8_0, più FP16). Questa flessibilità permette di ospitare un Llama 3.1 70B (~40 GB in Q4) su una sola RTX A6000 48 GB. vLLM accetta i pesi nativi di HuggingFace (FP16, BF16) e supporta ora AWQ, GPTQ e FP8, ma non GGUF in produzione stabile.

Alcuni riferimenti VRAM Q4 del catalogo QualeLLM :

Per deployment di piccole dimensioni, gpt-oss 120B e Mistral Small 4 offrono un compromesso ragionevole: dimensioni gestibili, licenza permissiva, supporto di entrambi i runtime. Consulta la nostra scheda Mistral Small 4 per i benchmark dettagliati.

Licenze e conformità

La scelta del runtime non ha alcun impatto sulle licenze — è il modello che stabilisce le condizioni. Alcuni casi tipici negli ambienti di produzione europei:

Per una panoramica completa, vedere il nostro guida alle licenze LLM open-source e gli aggiornamenti della comunità su Modelli di HuggingFace.

Casi d'uso: quale scegliere per cosa?

Scegli Ollama se: - Distribuisci un assistente interno su una postazione di sviluppo o una singola workstation GPU - Vuoi iterare rapidamente su più modelli (cambio a caldo tramite API) - Il tuo carico è < 5 utenti simultanei - Punti a una RTX 3090/4090/5090 o a un Mac Studio M3 Ultra - Vuoi testare dots.llm1 Instruct (142B, MIT, Rednote) o Hunyuan-A13B Instruct senza configurare un cluster

Scegli vLLM se: - Fornisci un'API dietro un load balancer con > 20 richieste/sec - Utilizzi il parallelismo tensoriale su 2, 4 o 8 GPU - Vuoi sfruttare PagedAttention, decoding speculativo e batching continuo - Punti a modelli MoE di dimensioni enormi: DeepSeek V3.2 (685B), Mistral Large 3 675B, Llama 3.1 405B Instruct, Ring-1T (1000B) - Ti serve Llama 4 Scout 109B con il suo contesto di 10M token in serving multi-tenant

Una terza scelta merita di essere menzionata: Text Generation Inference di HuggingFace, una soluzione intermedia tra i due, con supporto nativo per Mistral Medium 3.5 128B e la famiglia Llama. Per gestire un cluster vLLM, Ray Serve rimane il punto di riferimento.

Per consigli in base al budget per la GPU, consulta la nostra guida del configuratore e la pagina migliore LLM per server GPU.

Costi operativi e osservabilità

Ollama ha un vantaggio in termini di semplicità operativa: un unico binario, telemetria minima, aggiornamento del modello con un solo comando. Il costo nascosto è l'assenza di metriche dettagliate (nessun supporto nativo per Prometheus nelle versioni stabili recenti, da confermare). vLLM espone nativamente un endpoint Prometheus con time-to-first-token, throughput per richiesta, utilizzo della cache KV, e si integra direttamente con Grafana.

Quanto ai costi GPU, un cluster vLLM ben ottimizzato riduce il costo per milione di token di un fattore da 3 a 8 rispetto a un deployment Ollama equivalente con più istanze — la differenza deriva dal batching continuo e dalla quasi assenza di frammentazione KV. Su Qwen3-Coder-Next 80B-A3B (MoE, Apache 2.0), i nostri lettori riportano (da confermare) circa 14.000 token/sec aggregati su 2× H100 con vLLM, contro circa 80 token/sec su un singolo flusso con Ollama e una RTX 6000 Ada.

Per approfondire il tuning, vedi il blog ufficiale di vLLM e il nostro comparazione vLLM vs TGI.

FAQ

Q: Ollama può servire più utenti contemporaneamente in produzione?

Tecnicamente sì, ma con dei limiti. Ollama gestisce più richieste tramite una coda interna, senza un batching continuo efficace. Oltre 3-5 utenti simultanei su un modello 70B come Llama 3.3 70B Instruct, la latenza p95 peggiora fortemente. Per una produzione multi-tenant seria, vLLM o TGI restano le scelte tecnicamente giustificate.

Q: vLLM supporta quantizzazioni aggressive come Q4 GGUF?

Non in formato GGUF nativo. vLLM privilegia FP8, AWQ e GPTQ, che offrono un compromesso qualità/VRAM diverso. Su DeepSeek R1 671B, esiste una versione AWQ a 4 bit ufficiale su HuggingFace e funziona con vLLM. Se vuoi usare esclusivamente GGUF Q4_K_M, resta su Ollama o usa direttamente llama.cpp — è il loro punto forte.

Q: Quale runtime per un MoE come Qwen 3 235B-A22B?

vLLM, senza esitazione. I modelli MoE traggono notevolmente vantaggio dall'expert parallelism e dal continuous batching che vLLM implementa nativamente. Qwen 3 235B-A22B (Apache 2.0, ctx 131K) raggiunge un throughput aggregato a cui Ollama non riesce nemmeno ad avvicinarsi, neppure su un cluster 8× H100. Vedere la nostra scheda Qwen 3 235B-A22B.

Q: Si può usare Ollama su un cluster Kubernetes?

Sì, esistono chart Helm della comunità, ma Ollama non è stato progettato per la scalabilità orizzontale senza stato. Ogni pod ricarica i propri modelli, la cache GGUF non è condivisa. Per l'integrazione nativa con Kubernetes, vLLM si integra meglio tramite KServe e il suo operatore dedicato.

Q: Qual è il runtime da scegliere per Llama 4 Scout 109B e il suo contesto 10M?

vLLM con attenzione sparsa attivata. Il contesto da 10M di Llama 4 Scout 109B richiede una gestione della cache KV che solo PagedAttention rende economicamente sostenibile. Tecnicamente Ollama può caricare il modello, ma senza paginazione la cache KV per 10M token fa esplodere il fabbisogno di VRAM. Da riservare a vLLM o TGI.

Q: Esiste un'alternativa ai due per i Mac Apple Silicon?

Sì: MLX d'Apple è ottimizzato per Metal e supera Ollama su M3 Ultra per modelli come DeepSeek R1 Distill Llama 70B. Ma il serving multiutente su Mac resta un ambito di nicchia. Vedi la nostra guida LLM per Mac M3 Ultra.

Conclusione

La scelta tra Ollama e vLLM dipende dal carico di lavoro previsto: Ollama per la prototipazione, l'uso da parte di un singolo utente e i Mac; vLLM quando si tratta di API multi-tenant, modelli MoE di grandi dimensioni o parallelismo tensoriale. Per identificare la coppia modello/runtime adatta alla tua VRAM e alla licenza che cerchi, avvia il nostro configuratore oppure esplora i 249 modelli indicizzati nel catalogo QualeLLM.

Articolo pubblicato il da Mohamed Meguedmi · Fonte dati: /api/models.json · Licenza dei contenuti: CC BY 4.0.

Un errore o un aggiornamento da segnalare? Contribuire.