Lo Stato dei Motori di Inferenza LLM nel 2026: vLLM, llama.cpp, Aphrodite, LMDeploy

Un paio di anni fa, eseguire un modello di linguaggio di grandi dimensioni significava uno script di ricerca, un sacco di memoria GPU e una preghiera. Oggi significa scegliere tra un piccolo insieme di motori di inferenza maturi e specializzati — e la scelta importa, perché sono genuinamente strumenti diversi ottimizzati per situazioni diverse. Hai bisogno di servire migliaia di utenti contemporanei alla massima throughput, o eseguire un modello sul tuo laptop senza GPU? Hai bisogno di caricare un modello quantizzato dalla comunità in un formato esotico, o adattare un modello di 70 miliardi di parametri in una singola scheda grafica consumer? La risposta onesta a "qual è il miglior motore di inferenza LLM nel 2026" è che non ce n''è uno; c''è un portfolio, e scegliere bene significa capire per cosa è fatto ogni motore.

Questa guida mappa il paesaggio di inferenza del 2026 per il lavoro che ogni motore fa meglio. I principali progetti open-source — vLLM, llama.cpp, Aphrodite Engine, LMDeploy, SGLang e ExLlamaV3 — hanno ciascuno una chiara personalità, e conoscere quelle personalità è come eviti di forzare lo strumento sbagliato sul tuo carico di lavoro. Nel frattempo copre i concetti che effettivamente guidano la decisione: throughput versus latenza, quantizzazione e adattamento hardware.

I concetti che guidano la scelta

Prima dei motori, tre idee spiegano la maggior parte delle differenze tra loro. La prima è throughput versus latenza. Servire molti utenti contemporaneamente è un problema di throughput: vuoi mantenere la GPU satura accodando le richieste insieme, massimizzando i token totali al secondo per tutti. Eseguire un modello per un utente è un problema di latenza: vuoi la risposta più veloce possibile per quel singolo flusso. I motori ottimizzano per uno o l''altro, e le tecniche differiscono — continuous batching e paged attention per throughput, esecuzione snella single-stream per latenza.

La seconda è quantizzazione. I pesi del modello a precisione intera sono grandi; la quantizzazione li memorizza a precisione inferiore (8-bit, 4-bit o meno) per ridurre memoria e velocizzare l''inferenza, a qualche costo di qualità. Ma la quantizzazione non è una cosa — è uno zoo di formati (GGUF, GPTQ, AWQ, EXL3 e altro), ciascuno con strumenti diversi, tradeoff qualità/taglia e supporto del motore. Quali formati un motore può caricare è spesso il fattore decisivo, perché il tuo modello potrebbe esistere solo in certi formati.

Il terzo è adattamento hardware. Un datacenter con H100 ha bisogni diversi da uno sviluppatore su un MacBook o un hobbyist con una GPU consumer. Alcuni motori si rivolgono all''hardware del server NVIDIA e si scalano su molte GPU; altri funzionano ovunque incluso CPU e Apple Silicon; altri schiacchiano modelli grandi in una singola scheda consumer. Abbinare il motore al tuo hardware è metà della decisione.

vLLM: lo standard di throughput

vLLM è il motore di riferimento per servizio ad alto throughput, e ha guadagnato quella posizione con PagedAttention — una tecnica che gestisce il cache KV come memoria virtuale, in pagine, eliminando lo spreco che precedentemente limitava quante richieste potevano essere accodate insieme. Combinato con continuous batching, questo permette a vLLM di mantenere una GPU satura con molte richieste contemporanee, fornendo il throughput di token-al-secondo aggregato che servizio di produzione richiede. Espone un''API compatibile con OpenAI, supporta tensor e pipeline parallelism per scala su GPU ed è diventato il backend predefinito su cui altri strumenti si costruiscono.

vLLM è la scelta giusta quando il tuo problema è servire — molti utenti, traffico di produzione, formati di modello standard, hardware NVIDIA — e vuoi il throughput e la maturità dell''ecosistema che vengono con il motore più ampiamente adottato. Non è lo strumento per eseguire un modello sul tuo laptop, e storicamente la copertura dei formati di quantizzazione laggava i formati più esotici della comunità (anche se continua ad espandersi). Per il lavoro principale di servire modelli standard in scala, è il default sicuro e potente.

llama.cpp: locale e ovunque

Se vLLM possiede il datacenter, llama.cpp possiede ovunque altro. Scritto in C/C++ senza pesanti dipendenze di runtime, esegue LLM su quasi qualsiasi cosa — CPU, GPU consumer, Apple Silicon, persino telefoni e Raspberry Pi — ed è uno dei progetti IA più stellati su GitHub per buona ragione. Il suo formato GGUF e il sistema k-quant (Q4_K_M, Q5_K_S, Q6_K e così via) forniscono quantizzazione block-wise da 8-bit sotto a sotto 2-bit, permettendoti di scegliere esattamente quanta qualità scambiare per quanta memoria, ed eseguire modelli che altrimenti non si adatterebbero mai.

llama.cpp è la scelta per inferenza locale, offline o edge: eseguire un modello sulla tua macchina, offline, senza GPU richiesta, o incorporare inferenza LLM in un''applicazione che deve funzionare su hardware modesto. È quello che alimenta una grande parte dell''ecosistema local-LLM, includendo strumenti come Ollama che lo avvolgono in un''interfaccia più amichevole. Quando la portabilità e il funzionamento ovunque importano più del throughput grezzo multi-utente, llama.cpp è senza pari — e il suo formato GGUF è diventato una lingua franca dei modelli quantizzati condivisi dalla comunità.

Aphrodite: l''onnivoro di quantizzazione

Aphrodite Engine è un fork di vLLM che mantiene l''architettura di throughput di vLLM ma aggiunge due cose: la copertura di quantizzazione più ampia di qualsiasi motore e sampler avanzati. Dove vLLM supporta un insieme crescente ma curato di formati, Aphrodite carica quasi tutto quello che la comunità produce — GGUF, GPTQ, AWQ, ExLlamaV3, AQLM, BitNet, Marlin e altro, più cache KV quantizzato. Dal lato del sampling spedisce DRY (anti-ripetizione), XTC (creatività) e Mirostat, che importano per applicazioni chat e creative.

Aphrodite è la scelta quando hai bisogno di servire un modello (quindi vuoi il throughput di classe vLLM) ma il modello esiste in un formato che vLLM non può caricare, o quando vuoi quei sampler avanzati come caratteristiche di prima classe. È emerso dall''ecosistema di modelli della comunità e roleplay, e quel pedigree si mostra nelle priorità: esegui qualsiasi quantizzazione la comunità ha prodotto, con controllo preciso del sampler. Se hai mai trovato un modello quantizzato perfetto solo per scoprire che il tuo motore non può caricare il suo formato, Aphrodite è la risposta.

LMDeploy: compressione più servizio e VLM

LMDeploy, dall''ecosistema InternLM/OpenMMLab, accoppia un motore di servizio ad alto throughput (TurboMind) con un toolkit di compressione integrato. Fornisce throughput forte tramite persistent batching e cache KV bloccato, offre quantizzazione 4-bit AWQ di pesi e quantizzazione di cache KV out-of-box e ha supporto particolarmente forte per modelli vision-language (VLM) come InternVL e Qwen-VL. Il suo punto di vendita è l''integrazione: quantizza un modello e servilo con un toolkit, piuttosto che cucire insieme strumenti separati.

LMDeploy è la scelta quando vuoi un percorso all-in-one da un modello a precisione intera a un endpoint quantizzato servito efficientemente, specialmente se servi modelli multimodali o lavori nell''ecosistema InternLM. Riguarda meno il caricamento di ogni formato della comunità (la nicchia di Aphrodite) e più un percorso pulito, ad alte prestazioni, compress-and-serve con supporto VLM di prima classe.

SGLang e ExLlamaV3: due specialisti in più

Due motori in più arrotondano il paesaggio per esigenze specifiche. SGLang si concentra su servizio ad alte prestazioni con una forza particolare in generazione strutturata e complessi programmi LLM multi-step — il suo RadixAttention ottimizza il prefix caching, che risplende quando molte richieste condividono prefissi di prompt (comune nei carichi di lavoro agentic e few-shot). È un motore di throughput forte con un bordo per generazione strutturata e programmatica.

ExLlamaV3 attacca un problema più ristretto, prezioso: massima qualità-per-VRAM su GPU NVIDIA consumer. Il suo formato EXL3 offre quantizzazione variable-bitrate — puoi puntare un media bit-per-weight precisamente — permettendoti di adattare un modello grande in una singola scheda 24GB alla migliore qualità che la memoria consente. Per l''entusiasta locale che esegue modelli grandi su una GPU consumer, ExLlamaV3 spesso estrae più qualità usabile dallo stesso VRAM di alternative a formato fisso, e si collega a server come TabbyAPI per un endpoint compatibile con OpenAI.

Capire i tradeoff di quantizzazione

Perché la quantizzazione è la leva che più spesso decide quale motore puoi usare, vale la pena capire cosa effettivamente scambi quando la attivi. La quantizzazione riduce la precisione numerica dei pesi di un modello — da float 16-bit down a 8, 4 o anche meno bit — e l''effetto è approssimativamente lineare sulla memoria: una quantizzazione 4-bit di un modello è circa un quarto della taglia del suo originale 16-bit, il che è quello che permette a un modello di 70-miliardi-parametri che richiederebbe 140GB a precisione intera di schiacciare in una singola scheda consumer 24GB. Il vantaggio della velocità segue, perché meno traffico di memoria e pesi più piccoli significano inferenza più veloce, specialmente quando la larghezza di banda della memoria è il collo di bottiglia.

Il costo è qualità, ma la relazione non è lineare e questo è l''intuizione chiave. Andare da 16-bit a 8-bit è quasi lossless per la maggior parte dei modelli — la differenza di qualità è impercettibile in pratica. Andare a 4-bit introduce una piccola, usualmente accettabile degradazione, che è perché formati 4-bit come Q4_K_M e 4-bit AWQ sono i cavalli da tiro dell''inferenza locale. Sotto 4-bit, la qualità cade più steeply e da 2-bit la degradazione è significativa, anche se i metodi moderni come l''approccio variable-bitrate di EXL3 e AQLM spingono quella frontiera più lontano di quanto i metodi più antichi potessero. La guida pratica è usare il bitrate più alto che la tua memoria consente: se un modello si adatta a 5 o 6 bit, raramente c''è ragione di andare più in basso, e se si adatta solo a 3 bit, aspettati di sentirlo.

Questo è anche perché il formato di quantizzazione — non solo il bitrate — importa per la scelta del motore. Diversi formati usano diversi algoritmi per decidere come arrotondare i pesi, e non sono intercambiabili: un modello GGUF ha bisogno di un motore che legge GGUF, un modello EXL3 ha bisogno di ExLlamaV3 o un server compatibile, un modello AWQ ha bisogno del supporto AWQ. La comunità produce modelli in qualsiasi formato i suoi strumenti favoriti usino, quindi il formato in cui il tuo modello target esiste vincola quali motori possono servirlo. Questo è precisamente il vincolo che rende prezioso l''ampiezza di formato di Aphrodite e che occasionalmente forza un team su un motore specifico non per le sue prestazioni ma semplicemente perché è l''unico che può caricare il modello che vogliono. Comprendi la curva bitrate/qualità e il paesaggio dei formati, e le parti del motore di selezione guidate dalla quantizzazione smettono di essere misteriose.

Scelta di un motore

La decisione riduce a abbinare il motore al tuo lavoro e hardware. Per servizio di produzione in scala su hardware NVIDIA con formati di modello standard usa vLLM — è lo standard di throughput con l''ecosistema più profondo. Per inferenza locale, offline o edge, o esecuzione su CPU/Apple Silicon/hardware modesto, usa llama.cpp — niente eguaglia la sua portabilità, e il suo formato GGUF è lo standard della comunità. Per servire modelli quantizzati dalla comunità in formati esotici, o desiderando sampler avanzati, usa Aphrodite Engine — è l''onnivoro di quantizzazione. Per un percorso all-in-one compress-and-serve, specialmente con modelli vision-language, usa LMDeploy. Per generazione strutturata/agentic al throughput, considera SGLang. E per massima qualità-per-VRAM su una singola GPU consumer, usa ExLlamaV3.

Il meta-punto è che questi motori sempre più condividono fondazioni — diversi si costruiscono su o biforcano vLLM, diversi parlano l''API compatibile con OpenAI e i modelli quantizzati si muovono tra loro — quindi la scelta è meno su lock-in e più su quale personalità si abbina al tuo carico di lavoro oggi. Un team potrebbe anche usarne due: llama.cpp per lo sviluppo locale e vLLM per il servizio di produzione, o LMDeploy per quantizzare un modello che Aphrodite poi serve. Diagnostica il tuo vincolo dominante — throughput, portabilità, larghezza di quantizzazione o qualità-per-VRAM — e il motore giusto segue.

Il punto finale

Non c''è un unico miglior motore di inferenza LLM nel 2026 e cercare uno è l''obiettivo sbagliato. C''è un portfolio maturo, ogni motore con un lavoro chiaro: vLLM per servizio di throughput in scala, llama.cpp per locale e ovunque, Aphrodite per la copertura di quantizzazione più ampia, LMDeploy per compress-and-serve e VLM, SGLang per generazione strutturata e ExLlamaV3 per qualità-per-VRAM su GPU consumer. Comprendi le tre leve che guidano la scelta — throughput versus latenza, formato di quantizzazione e adattamento hardware — abbina il motore al tuo vincolo dominante e eseguirai i tuoi modelli più velocemente, più economicamente e sull''hardware che effettivamente hai.

Riferimenti e Risorse

Motori

Sfondo e analisi

Cheatsheet 1337skills correlati

vLLM, llama.cpp, Aphrodite Engine, LMDeploy
SGLang, ExLlamaV3, Ollama, TensorRT-LLM