LLM Motori di Inferenza: vLLM vs LMDeploy vs SGLang
Abbiamo confrontato 3 principali motori di inferenza LLM su hardware NVIDIA H100: vLLM, LMDeploy e SGLang. Ciascun motore ha elaborato carichi di lavoro identici: 1.000 prompt ShareGPT utilizzando Llama 3.1 8B-Instruct per isolare il reale impatto prestazionale delle loro scelte architetturali e strategie di ottimizzazione.
Motori | Ideale per |
|---|---|
vLLM | -Prototipazione e sperimentazione su oltre 100 architetture di modelli -Ambienti multi GPU (NVIDIA, AMD, Intel) |
LMDeploy | -Implementazioni in produzione che richiedono prestazioni H100 con complessità minima -Team che privilegiano la semplicità di installazione (pip install a una riga) |
SGLang | -Organizzazioni che necessitano del massimo throughput assoluto (16.215 tok/s) -Cluster di inferenza dedicati |
Risultati del benchmark dei motori di inferenza
Abbiamo misurato il throughput batch offline su 10.000 operazioni di inferenza totali (1.000 prompt × 10 esecuzioni per motore) per garantire stabilità statistica.
- Throughput: Token di output generati al secondo in modalità inferenza batch. Misura l'efficienza con cui ciascun motore utilizza le capacità di calcolo dell'H100.
Tutti i motori sono stati configurati per le loro massime prestazioni teoriche: Llama 3.1 8B-Instruct, precisione bfloat16 e utilizzo della memoria GPU allo 0,8 su hardware H100 80GB.
Per comprendere come abbiamo calcolato i tassi di throughput, consulta la nostra metodologia di benchmark dell'inferenza.
Risultati principali
Il nostro approccio riduce al minimo le variabili confondenti: modello, hardware, dataset, configurazione di campionamento, limiti di memoria e protocollo di warmup identici. Questo isolamento rivela ciò che l'architettura di ciascun motore apporta realmente.
Il divario architetturale è del 29%: Anche quando vLLM è ottimizzato con gli stessi identici kernel (FlashInfer) di SGLang, resta significativamente indietro rispetto ai leader. SGLang (16.215 tok/s) e LMDeploy (16.132 tok/s) mantengono un vantaggio del 29% rispetto al vLLM completamente ottimizzato (12.553 tok/s). Ciò indica che il collo di bottiglia non è più il kernel matematico, ma il sovraccarico di orchestrazione interna del motore.
SGLang e LMDeploy sono sostanzialmente alla pari: la differenza prestazionale tra loro è inferiore allo 0,6%, rientrando nel margine di errore. Questo suggerisce che sia l'approccio "Python + Kernel nativi" (SGLang) sia l'approccio "Motore C++ puro" (LMDeploy) sono strategie ugualmente valide per raggiungere le massime prestazioni sulle architetture Hopper.
"Zona sicura" della memoria GPU all'80% di utilizzo: I tentativi di allocare il 95% della memoria GPU hanno causato crash immediati durante la compilazione CUDA Graph su tutti i motori, nonostante la capacità di 80GB. La causa principale è stata identificata nell'esaurimento della RAM di sistema durante l'acquisizione del grafo, non nei limiti di memoria GPU. Una frazione di 0,8 ha fornito l'equilibrio ottimale tra stabilità e dimensione del batch.
Comprendere la gerarchia delle prestazioni
Le differenze di throughput rivelano una chiara distinzione tra le architetture dei motori su H100:
SGLang & LMDeploy: Questi motori raggiungono ~16.200 tok/s. SGLang ottiene questo risultato tramite RadixAttention, un gestore di memoria specializzato progettato per pattern di serving complessi. LMDeploy lo raggiunge tramite TurboMind, un backend C++ personalizzato che elimina completamente il sovraccarico di Python.
vLLM: Anche con il backend FlashInfer abilitato, vLLM raggiunge un picco di ~12.500 tok/s. Sebbene questo rappresenti un enorme miglioramento rispetto alle configurazioni standard, il divario rimanente evidenzia il costo dell'architettura flessibile e basata su plugin di vLLM (PagedAttention) rispetto ai design iper-specializzati dei leader.
Differenze nella filosofia architetturale: SGLang e LMDeploy co-progettano i loro meccanismi di attenzione con le assunzioni dei kernel. vLLM mantiene un livello di compatibilità più ampio che richiede agli algoritmi di attenzione di funzionare con vari backend, limitando la profondità delle ottimizzazioni specifiche su hardware all'avanguardia.
Ottimizzazione dei pattern di accesso alla memoria: Il divario del 29% suggerisce che SGLang e LMDeploy ottimizzano il coalescing della memoria, la località della cache e la schedulazione dei batch in modo più aggressivo di quanto consenta lo scheduler di vLLM, in particolare nella gestione del Tensor Memory Accelerator (TMA) dell'H100.
Metodologia del benchmark
Ambiente di test
Configurazione hardware:
- GPU: NVIDIA H100 80GB HBM3
- Sistema: istanza cloud RunPod
- Base Docker: runpod/pytorch:1.0.2-cu1281-torch280-ubuntu2404
Versioni software:
- CUDA: 12.8.1
- PyTorch: 2.8.0
- vLLM: 0.11.0 (FlashInfer abilitato)
- LMDeploy: 0.10.2
- SGLang: v0.2.3
Dataset e carico di lavoro
Fonte: dataset ShareGPT_Vicuna_unfiltered da Hugging Face
Criteri di selezione:
Perché questo dataset: ShareGPT contiene conversazioni reali utente-chatbot con variazione naturale della lunghezza, rappresentando più accuratamente i carichi di lavoro reali dei chatbot rispetto ai benchmark sintetici.
Configurazioni dei motori
Tutti i motori sono stati configurati per le massime prestazioni mantenendo l'equità:
Configurazione vLLM (Backend FlashInfer):
Configurazione LMDeploy:
Configurazione SGLang:
Procedura di misurazione
Protocollo standard applicato a tutti i motori:
- Caricamento del modello: Scarica e inizializza il modello con precisione bfloat16.
- Fase di warmup: Elabora 20 prompt per attivare la compilazione JIT e stabilizzare i clock della GPU.
- Esecuzioni del benchmark: Esegui 10 passaggi completi di tutti i 1.000 prompt.
- Metodologia di temporizzazione:
- Conteggio dei token: Estrai i conteggi effettivi dei token dai formati di output specifici del motore.
- Calcolo del throughput: token_di_output_totali / durata.
Rigore statistico:
- 10.000 operazioni di inferenza totali (1.000 prompt × 10 esecuzioni per motore).
- ~1,5 milioni di token generati per motore.
- Deviazione standard costantemente <1% della media su tutti i motori.
Interpretare i risultati
Cosa puoi concludere:
Per l'inferenza batch offline di Llama 3.1 8B su hardware H100, l'efficienza architetturale determina il vincitore. Anche con i migliori kernel possibili (FlashInfer), vLLM non può eguagliare il throughput di SGLang o LMDeploy. Il divario del 29% rappresenta il costo dell'orchestrazione Python rispetto all'ottimizzazione nativa in C++.
La gerarchia delle prestazioni si applica a questo scenario esatto: elaborazione batch di 1.000 prompt simultaneamente. SGLang e LMDeploy sono scelte robuste che offrono circa il 45% di valore in più per ora-GPU rispetto alle implementazioni standard e circa il 29% in più rispetto alle implementazioni vLLM altamente ottimizzate.
Cosa non puoi generalizzare:
- Modelli diversi: Risultati specifici per Llama 3.1 8B. Modelli più grandi (es. 70B) o architetture diverse (es. Mixtral, Qwen) mostreranno pattern di scalabilità differenti.
- Hardware diverso: Queste classifiche si applicano all'H100 80GB. Su A100 o V100, la portabilità di vLLM potrebbe prevalere sulla specializzazione di SGLang.
- Metriche diverse: Questo misura solo il throughput. Il serving online richiede TTFT e percentili di latenza, dove i risultati differiscono significativamente.
- Carichi di lavoro diversi: Prompt casuali minimizzano i benefici della cache dei prefissi. Prompt di sistema ripetuti o conversazioni multi-turno spostano drasticamente il panorama prestazionale a favore di SGLang.
Confronto dell'esperienza di sviluppo
I numeri delle prestazioni non catturano il quadro completo dell'implementazione. Ogni motore offre flussi di lavoro di sviluppo distinti:
vLLM: Standard del settore per buone ragioni
Semplicità unita ad ampia compatibilità. Una singola installazione pip di vllm supporta oltre 100 architetture di modelli su hardware NVIDIA, AMD e Intel. Una comunità enorme significa che Stack Overflow ha le risposte. Server API compatibile con OpenAI incluso.
- Scegli vLLM per: Prototipazione rapida, ambienti GPU eterogenei, massima copertura di modelli o per sfruttare l'ecosistema più vasto.
LMDeploy: Grado di produzione con attrito minimo
Installazione a una riga (pip install lmdeploy) offre il 99,5% delle massime prestazioni su H100. Backend C++ nativo significa zero sovraccarico Python. Supporto alla quantizzazione di prima classe (AWQ, GPTQ) per ulteriori ottimizzazioni. Nessun inferno di dipendenze.
- Scegli LMDeploy per implementazioni in produzione che richiedono massime prestazioni su H100 senza sacrificare la semplicità di installazione o la stabilità.
SGLang: Massime prestazioni con costo di complessità
Il throughput di picco assoluto (16.215 tok/s) ha un prezzo: sforzo significativo nel debug dell'installazione di FlashInfer. Richiede una versione specifica di PyTorch. Incompatibilità binarie con alcuni wheel precompilati. RadixAttention eccelle nei carichi di lavoro conversazionali.
- Scegli SGLang per: Cluster di inferenza dedicati dove un team specializzato può gestire le dipendenze e hai bisogno di ogni ultimo punto percentuale di throughput.
Aggiungi come fonte preferitaSfide di installazione e implementazione
Un confronto equo ha richiesto il superamento di ostacoli ingegneristici significativi:
Sfida 1: Conflitti di dipendenza di FlashInfer
Problema: I wheel FlashInfer di SGLang richiedono versioni specifiche di PyTorch, ma i container ottimizzati per H100 spesso forniscono versioni diverse.
Risoluzione:
Investimento di tempo: 6 ore per identificare versioni compatibili.
Conclusione: I wheel ML precompilati spesso nascondono vincoli di versione che emergono solo in fase di esecuzione.
Sfida 2: Abilitare FlashInfer in vLLM
Problema: Le versioni standard di vLLM spesso mancano del supporto FlashInfer o richiedono una complessa compilazione dai sorgenti.
Svolta: Abbiamo utilizzato la build vLLM 0.11.0 su PyTorch 2.8 Nightly. Questo ha abilitato con successo il supporto nativo FlashInfer tramite pip install "vllm[flashinfer]==0.11.0", aggirando le barriere di compilazione delle versioni precedenti.
Impatto: Questo ha fornito il confronto più equo possibile, confermando che sebbene i kernel aiutino, non risolvono il collo di bottiglia architetturale.
Sfida 3: Scoperta del punto ottimale di utilizzo della memoria
Problema: La raccomandazione standard di utilizzo della memoria GPU a 0,9 causava crash std::bad_alloc.
Progressione dei test:
Scoperta: L'acquisizione di CUDA Graph alloca RAM di sistema temporanea proporzionale all'utilizzo della memoria GPU. A 0,9 × 80GB = 72GB di allocazione GPU, la RAM di sistema viene esaurita durante la compilazione.
Limite pratico: L'utilizzo della GPU a 0,8 è la "zona sicura" nonostante la capacità hardware di 80GB.
Conclusione
Per l'inferenza batch di Llama 3.1 8B su H100, la gerarchia delle prestazioni ha due chiari livelli: vLLM (ottimizzato con FlashInfer) fornisce una solida baseline, mentre le architetture C++ native di SGLang e LMDeploy sbloccano un ulteriore 29% di throughput.
SGLang (16.215 tok/s) e LMDeploy (16.132 tok/s) raggiungono un throughput quasi identico, suggerendo che entrambi i motori saturano la larghezza di banda della memoria dell'H100. Il divario minimo tra loro è rumore statistico.
Per implementazioni in produzione: LMDeploy emerge come il vincitore pratico, offrendo il 99,5% del throughput di picco di SGLang con un'installazione banale (pip install lmdeploy) rispetto alla complessa risoluzione delle dipendenze di SGLang.
vLLM con FlashInfer (12.553 tok/s) offre una via di mezzo interessante: prestazioni rispettabili mantenendo la piena compatibilità hardware e la più ampia matrice di supporto modelli del settore. Tuttavia, per cluster H100 dedicati, lasciare sul tavolo il 29% di prestazioni è un costo elevato.
Per la standardizzazione su infrastrutture eterogenee o la rapida sperimentazione di modelli, vLLM rimane la scelta razionale. Per implementazioni H100 dedicate dove il throughput è fondamentale, la combinazione di LMDeploy tra prestazioni di picco e semplicità di installazione è imbattibile.
FAQ
Un motore di inferenza LLM è un software specializzato che ottimizza il modo in cui i modelli linguistici di grandi dimensioni generano risposte. Sebbene sia possibile eseguire modelli con PyTorch o TensorFlow di base, i motori di inferenza aggiungono ottimizzazioni critiche come la gestione efficiente della memoria, il raggruppamento di più richieste insieme e le ottimizzazioni dei kernel GPU. Questi miglioramenti possono aumentare drasticamente il throughput (token generati al secondo) e ridurre i costi, offrendo potenzialmente prestazioni 3-5 volte superiori sullo stesso hardware.
L'inferenza batch offline elabora molti prompt simultaneamente senza requisiti in tempo reale, pensa all'analisi di migliaia di documenti o alla generazione di embedding per un dataset. Il serving online gestisce le richieste dei singoli utenti con rigorosi requisiti di latenza, dove metriche come il Time To First Token (TTFT) contano più del throughput puro. Il motore che vince nel throughput batch potrebbe non essere ottimale per i chatbot interattivi, quindi scegli in base al tuo effettivo modello di carico di lavoro
Cita questa ricerca
Scegli il formato adatto a dove pubblicherai. Incollare la versione con link nel tuo CMS preserva il backlink.
@misc{dilmegani2026,
author = {Dilmegani, Cem and Sarı, Ekrem},
title = {{LLM Motori di Inferenza: vLLM vs LMDeploy vs SGLang}},
year = {2026},
month = apr,
howpublished = {\url{https://aimultiple.com/inference-engines}},
note = {AIMultiple. Consultato il 15 Aprile 2026}
}
Sii il primo a commentare
Il tuo indirizzo email non verrà pubblicato. Tutti i campi sono obbligatori. I commenti vengono lasciati nella loro lingua originale.