llama.cpp vs vLLM vs Exllama

#Un motore di inferenza: ciò che cambia veramente tra loro

Un motore di inferenza trasforma token di ingresso in token di uscita. Le applicazioni che installi (Ollama, LM Studio, Jan) ne incorporano uno; i server di produzione (vLLM, SGLang) sono essi stessi motori di inferenza. Tre differenze si riflettono sul tuo utilizzo: i formati dei modelli accettati, l'hardware utilizzabile e il modo di gestire più richieste contemporaneamente.

#Il formato del modello determina il motore possibile

Prima di confrontare le velocità, verifica il formato in cui il modello che desideri è pubblicato. Un file GGUF si carica in llama.cpp e quindi in Ollama, LM Studio e Jan. I pesi di Hugging Face in FP16, FP8 o quantizzati in AWQ o GPTQ si caricano in vLLM o SGLang. Un modello convertito per MLX si carica con MLX LM su Mac, e un modello EXL3 con ExLlamaV3. Cambiare motore spesso significa scaricare di nuovo il modello in un altro formato.

#llama.cpp: lo standard portabile

llama.cpp è un'implementazione in C/C++ senza dipendenze, il cui obiettivo dichiarato è l'inferenza con una configurazione minima su un'ampia gamma di hardware. Apple Silicon ha la priorità (NEON, Accelerate, Metal), le CPU x86 sono supportate con AVX, AVX2, AVX512 e AMX e sono supportati i backend NVIDIA (CUDA), AMD (HIP), Vulkan e SYCL per le GPU. Offre quantizzazioni da 1,5 a 8 bit e l'inferenza ibrida su CPU e GPU, che permette di eseguire un modello più grande della VRAM disponibile.

Un luogo comune da correggere: llama.cpp non si limita a una richiesta alla volta. Il suo server dichiara il supporto alla generazione parallela multiutente e al batching continuo, attivato per impostazione predefinita, con slot regolati dal parametro --parallel. Serve quindi adeguatamente un piccolo team; ciò che non cerca di eguagliare sono le funzionalità di produzione su larga scala di vLLM.

Punti di forza

Portabilità (Mac, Linux, Windows, Android), formati GGUF onnipresenti, uso ibrido di CPU e GPU, poche dipendenze.

Limiti

Nessuna funzione di deploy distribuito simile a quella di vLLM; bisogna conoscere i parametri (contesto, slot, layer su GPU).

Ecosistema

Alla base di Ollama e di LM Studio, citato anche da Jan.

Per la compilazione con CUDA, Metal o Vulkan, consulta le guide di compilazione; il tutorial completo su llama.cpp spiega l'uso.

#vLLM: il server per molti utenti

vLLM è una libreria per l'inferenza e il serving nata presso lo Sky Computing Lab dell'Università della California a Berkeley. Si basa su PagedAttention, che gestisce per pagine la memoria delle chiavi e dei valori dell'attenzione, e sul batching continuo, integrati dal prefill a blocchi e dalla cache dei prefissi. Dichiara il supporto per i formati FP8, INT4, GPTQ, AWQ e GGUF, un'API compatibile con OpenAI e il supporto per GPU NVIDIA, AMD e Intel, oltre che per CPU x86, ARM e PowerPC.

Due idee sbagliate da correggere. In primo luogo, vLLM non è più riservato a NVIDIA e supporta anche le CPU: il suo repository indica il supporto per diverse GPU e CPU. In secondo luogo, ora supporta anche GGUF: la documentazione descrive questo supporto come molto sperimentale e poco ottimizzato, utile soprattutto per ridurre l'occupazione di memoria. Per un uso quotidiano di GGUF, llama.cpp resta la soluzione abituale.

Punti di forza

Throughput sotto carico, memoria della cache gestita a pagine, API compatibile con OpenAI, parallelismo (tensor, pipeline, expert), numerosi formati.

Limiti

Più impegnativo da installare e configurare rispetto a llama.cpp; pensato per server GPU; il GGUF non è il suo punto forte.

Ecosistema

Scelta predefinita quando più persone o applicazioni interrogano lo stesso modello contemporaneamente.

La guida su vLLM spiega che cos'è il motore; quella sulla sua distribuzione in produzione descrive in dettaglio le impostazioni e il monitoraggio.

#ExLlama: V2 archiviato, V3 in sviluppo

Il repository di ExLlamaV2 contiene una nota che indica che il progetto è archiviato per il momento e che lo sviluppo prosegue in ExLlamaV3. Molti confronti, tra cui la vecchia versione di questa pagina, presentano ancora V2 come l'opzione più avanzata. Il repository di ExLlamaV3 annuncia il formato di quantizzazione EXL3, l'inferenza con parallelismo dei tensori e degli esperti, l'offload sulla CPU per i modelli a esperti, il batching continuo, la decodifica speculativa e un'API compatibile con OpenAI tramite TabbyAPI, il suo server consigliato.

ExLlamaV3 è pensato per le GPU consumer, non per i server di produzione né per i Mac. Se hai una scheda NVIDIA e vuoi il miglior compromesso tra qualità e dimensioni, vale la pena provare la quantizzazione EXL3; verifica prima che il tuo modello figuri nell'elenco delle architetture del repository.

#SGLang, MLX LM e gli altri

SGLang

Framework di serving descritto come orientato a bassa latenza e alto throughput, da una singola GPU a grandi cluster. Annuncia RadixAttention per la cache dei prefissi, il batching continuo, PagedAttention e la decodifica speculativa. Compete con vLLM sui server; la guida dedicata lo descrive in dettaglio.

MLX LM

Pacchetto Python per generare testo ed eseguire il fine-tuning dei modelli su Apple Silicon con MLX. Non funziona su piattaforme diverse dal Mac. La guida MLX contro llama.cpp confronta i due su Mac.

TensorRT-LLM

Motore di NVIDIA, molto performante sulle sue schede ma più complesso da implementare; da considerare solo per una flotta NVIDIA in produzione.

#Cosa dicono le misurazioni pubblicate

Le velocità di elaborazione dipendono dall'hardware, dal modello, dalla quantizzazione, dalla lunghezza delle richieste e dalla versione del motore, e cambiano ogni mese. Questa guida non presenta quindi misurazioni proprie e ti invita a diffidare delle tabelle di token al secondo prive di un protocollo. Una fonte terza pubblica tuttavia un protocollo completo: Red Hat, nell'agosto 2025.

Da leggere con cautela: l'articolo è legato ai prodotti Red Hat AI, quindi proviene da un operatore commerciale del settore; i test riguardano Ollama e non direttamente llama.cpp, con impostazioni predefinite; risalgono a diverse versioni fa. La conclusione solida è qualitativa: con molte richieste simultanee, un motore di serving con batching aggressivo supera un'applicazione pensata per un singolo utente. Se lo usi da solo, la differenza di throughput non è ciò che ti penalizza.

#Memoria: quanto ogni motore riserva

La memoria occupata da un modello comprende i pesi, la cache di contesto (KV) e un margine. Lo spazio occupato dai pesi si può calcolare: un modello da 8 miliardi di parametri occupa circa 16 GB in FP16 (8 miliardi moltiplicati per 2 byte) e circa 5 GB in Q4, secondo il valore di riferimento del sito. La cache di contesto cresce con la lunghezza della conversazione e il numero di richieste simultanee.

Il punto da ricordare: vLLM riserva la memoria fin dall'inizio, il che lo rende efficiente nel servire richieste ma poco adatto a una scheda condivisa con altre applicazioni. Il valore del parametro gpu_memory_utilization va ridotto se la scheda viene usata anche per altro.

#Quale motore per quale utilizzo

I motori possono convivere: Ollama per la chat quotidiana, vLLM avviato su richiesta per elaborare un lotto di estrazioni. Non c'è motivo di conservarne solo uno se gli usi sono diversi. Prevedi solo lo spazio su disco per lo stesso modello salvato in due formati, ad esempio un file GGUF per la chat e i pesi Hugging Face per il server.

• Ollama contro llama.cpp
• vLLM: la guida completa
• SGLang come server LLM locale
• MLX contro llama.cpp su Mac
• llama.cpp : guida completa
• Ollama, LM Studio, Jan o GPT4All

• Fonte: repository di llama.cpp
• Fonte: repository di vLLM
• Fonte: repository di ExLlamaV2
• Fonte: Red Hat, Ollama contro vLLM