LLM Motori di inferenza: vLLM vs LMDeploy vs SGLang
Abbiamo testato 3 principali motori di inferenza LLM su NVIDIA H100: vLLM, LMDeploy e SGLang. Ogni motore ha elaborato carichi di lavoro identici: 1,000 prompt ShareGPT utilizzando Llama 3.1 8B-Instruct per isolare il reale impatto sulle prestazioni 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 | -Distribuzioni in produzione che richiedono prestazioni H100 con minima complessità -Team che danno priorità alla semplicità di installazione (installazione con un solo comando pip) |
SGLang | -Organizzazioni che necessitano di throughput massimo assoluto (16,215 tok/s) -Cluster di inferenza dedicati |
Risultati 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 quanto efficientemente ogni motore utilizza le capacità di calcolo del 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 al 0.8 su hardware H100 80GB.
Per comprendere come abbiamo calcolato i tassi di throughput, consulta la nostra metodologia di benchmark per l'inferenza.
Risultati principali
Il nostro approccio minimizza le variabili confondenti: modello, hardware, dataset, configurazione di campionamento, limiti di memoria e protocollo di warm-up identici. Questo isolamento rivela ciò che l'architettura di ciascun motore contribuisce realmente.
Il divario architetturale è del 29%: Anche quando vLLM è ottimizzato con gli stessi identici kernel (FlashInfer) di SGLang, rimane significativamente indietro rispetto ai leader. SGLang (16,215 tok/s) e LMDeploy (16,132 tok/s) mantengono un vantaggio del 29% rispetto a vLLM completamente ottimizzato (12,553 tok/s). Ciò indica che il collo di bottiglia non è più il kernel matematico, ma il sovraccarico di orchestrazione interno del motore.
SGLang e LMDeploy sono sostanzialmente alla pari: la differenza di prestazioni tra loro è inferiore al 0.6%, che rientra nel margine di errore. Ciò 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 di sicurezza della memoria GPU all'utilizzo del 80%: I tentativi di allocare il 95% della memoria GPU hanno causato crash immediati durante la compilazione del grafo CUDA 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 della 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 tramite RadixAttention, un gestore di memoria specializzato progettato per pattern di serving complessi. LMDeploy lo ottiene 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 si tratti di 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 assunzioni sui kernel. vLLM mantiene un livello di compatibilità più ampio che richiede che gli algoritmi di attenzione funzionino con vari backend, il che limita 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 pianificazione dei batch in modo più aggressivo di quanto consenta lo scheduler di vLLM, in particolare nel modo in cui gestiscono il Tensor Memory Accelerator (TMA) del 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 variazioni naturali di lunghezza, rappresentando più accuratamente i carichi di lavoro dei chatbot in produzione 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: Scaricare e inizializzare il modello con precisione bfloat16.
- Fase di warm-up: Elaborare 20 prompt per attivare la compilazione JIT e stabilizzare i clock della GPU.
- Esecuzioni di benchmark: Eseguire 10 passaggi completi di tutti i 1,000 prompt.
- Metodologia di temporizzazione:
- Conteggio dei token: Estrarre i conteggi effettivi dei token dai formati di output specifici del motore.
- Calcolo del throughput: total_output_tokens / 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 inferiore al 1% della media su tutti i motori.
Interpretazione dei risultati
Cosa si può 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 forniscono circa 45% in più di valore per ora GPU rispetto alle distribuzioni standard e circa 29% in più rispetto alle distribuzioni vLLM altamente ottimizzate.
Cosa non si può generalizzare:
- Modelli diversi: Risultati specifici per Llama 3.1 8B. Modelli più grandi (ad es., 70B) o architetture diverse (ad es., Mixtral, Qwen) mostreranno pattern di scaling differenti.
- Hardware diversi: Queste classifiche si applicano a H100 80GB. Su A100 o V100, la portabilità di vLLM potrebbe superare la specializzazione di SGLang.
- Metriche diverse: Questo misura solo il throughput. Il serving online richiede TTFT e percentile di latenza, dove i risultati differiscono significativamente.
- Carichi di lavoro diversi: I prompt casuali minimizzano i benefici del caching dei prefissi. Prompt di sistema ripetuti o conversazioni multi-turno spostano drasticamente il panorama delle prestazioni a favore di SGLang.
Confronto dell'esperienza di sviluppo
I numeri delle prestazioni non catturano il quadro completo della distribuzione. Ogni motore offre flussi di lavoro di sviluppo distinti:
vLLM: Standard del settore per una buona ragione
La semplicità incontra un'ampia compatibilità. Una singola installazione pip install vllm supporta oltre 100 architetture di modelli su hardware NVIDIA, AMD e Intel. Una comunità massiccia significa che Stack Overflow ha le tue risposte. Server API compatibile con OpenAI incluso.
- Scegli vLLM per: Prototipazione rapida, ambienti GPU eterogenei, massima copertura di modelli o sfruttare il più grande ecosistema.
LMDeploy: Grado di produzione con minimo attrito
Installazione con una sola riga (pip install lmdeploy) offre il 99.5% delle massime prestazioni del H100. Backend nativo C++ significa zero sovraccarico Python. Supporto di prima classe per la quantizzazione (AWQ, GPTQ) per ulteriori ottimizzazioni. Nessun inferno di dipendenze.
- Scegli LMDeploy per Distribuzioni in produzione che richiedono le massime prestazioni H100 senza sacrificare la semplicità di installazione o la stabilità.
SGLang: Tetto delle prestazioni con costo di complessità
Il throughput massimo assoluto (16,215 tok/s) ha un prezzo: uno sforzo significativo nel debug dell'installazione di FlashInfer. Richiede una versione specifica di PyTorch. Incompatibilità binarie con alcuni pacchetti precompilati. RadixAttention brilla sui carichi di lavoro conversazionali.
- Scegli SGLang per: Cluster di inferenza dedicati dove un team specializzato può gestire le dipendenze, e hai bisogno di ogni singolo punto percentuale di throughput.
Sfide di installazione e distribuzione
Un confronto equo ha richiesto il superamento di significativi ostacoli ingegneristici:
Sfida 1: Conflitti di dipendenza di FlashInfer
Problema: I pacchetti FlashInfer di SGLang si aspettano versioni specifiche di PyTorch, ma i container ottimizzati per H100 spesso ne forniscono di diverse.
Risoluzione:
Investimento di tempo: 6 ore per identificare le versioni compatibili.
Lezione appresa: I pacchetti ML precompilati spesso nascondono vincoli di versione che emergono solo a runtime.
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 di 0.9 causava crash std::bad_alloc.
Progressione dei test:
Scoperta: L'acquisizione del grafo CUDA alloca RAM di sistema temporanea proporzionale all'utilizzo della memoria della GPU. Con 0.9 × 80GB = 72GB di allocazione GPU, la RAM di sistema si esaurisce 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 livelli chiari: vLLM (ottimizzato con FlashInfer) fornisce una solida base, 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 del H100. Il divario minimo tra loro è rumore statistico.
Per le distribuzioni in produzione: LMDeploy emerge come il vincitore pratico, offrendo il 99.5% del throughput massimo 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 un compromesso convincente: prestazioni rispettabili mantenendo la piena compatibilità hardware e la più ampia matrice di supporto dei modelli del settore. Tuttavia, per cluster H100 dedicati, lasciare sul tavolo il 29% di prestazioni ha un costo elevato.
Per la standardizzazione su infrastrutture eterogenee o la rapida sperimentazione di modelli, vLLM rimane la scelta razionale. Per distribuzioni H100 dedicate dove il throughput è fondamentale, la combinazione di prestazioni di picco e semplicità di installazione di LMDeploy è senza rivali.
Aggiungi come fonte preferitaFAQ
Un motore di inferenza LLM è un software specializzato che ottimizza il modo in cui i modelli linguistici di grandi dimensioni generano risposte. Mentre è possibile eseguire modelli con PyTorch o TensorFlow di base, i motori di inferenza aggiungono ottimizzazioni critiche come una gestione efficiente della memoria, il raggruppamento di più richieste insieme e le ottimizzazioni del kernel della GPU. Questi miglioramenti possono aumentare notevolmente il throughput (token generati al secondo) e ridurre i costi, offrendo potenzialmente prestazioni 3-5x 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 Time To First Token (TTFT) contano più del throughput grezzo. 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.