Motori di inferenza LLM: vLLM vs LMDeploy vs SGLang
Abbiamo eseguito un benchmark su H100 con NVIDIA tre motori di inferenza LLM leader di mercato: vLLM, LMDeploy e SGLang. Ciascun motore ha elaborato carichi di lavoro identici: 1.000 richieste 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 | -Implementazioni di produzione che richiedono prestazioni H100 con complessità minima - I team danno priorità alla semplicità di installazione (installazione con pip in una sola riga) |
SGLang | -Organizzazioni che necessitano della massima velocità di trasmissione assoluta (16.215 token/s) -Cluster di inferenza dedicati |
Risultati del benchmark dei motori di inferenza
Abbiamo misurato la velocità di elaborazione batch offline su un totale di 10.000 operazioni di inferenza (1.000 richieste × 10 esecuzioni per motore) per garantire la stabilità statistica.
- Throughput: Token di output generati al secondo in modalità di 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 pari allo 0,8% su hardware H100 da 80 GB.
Per comprendere come abbiamo calcolato i tassi di throughput, si prega di consultare la nostra metodologia di benchmark per l'inferenza.
Principali risultati
Il nostro approccio riduce al minimo le variabili confondenti: modello, hardware, set di dati, configurazione di campionamento, limiti di memoria e protocollo di riscaldamento identici. Questo isolamento rivela il reale contributo dell'architettura di ciascun motore.
Il divario architetturale è del 29%: anche quando vLLM è ottimizzato con gli stessi kernel (FlashInfer) di SGLang, rimane comunque 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 l'overhead di orchestrazione interno del motore.
SGLang e LMDeploy sono praticamente alla pari: la differenza di prestazioni tra i due è inferiore allo 0,6%, un valore che rientra nel margine di errore. Ciò suggerisce che sia l'approccio "Python + kernel nativi" (SGLang) sia quello "motore C++ puro" (LMDeploy) sono strategie ugualmente valide per ottenere prestazioni ottimali sulle architetture Hopper.
Zona di sicurezza per la memoria GPU all'80% di utilizzo: i tentativi di allocare il 95% della memoria GPU hanno causato arresti anomali immediati durante la compilazione del grafico CUDA su tutti i motori, nonostante la capacità di 80 GB. La causa principale è stata identificata nell'esaurimento della RAM di sistema durante l'acquisizione del grafico, non nei limiti della memoria GPU. Una frazione di 0,8 ha fornito il compromesso ottimale tra stabilità e dimensione del batch.
Comprendere la gerarchia delle prestazioni
Le differenze di rendimento rivelano una netta distinzione tra le architetture dei motori sull'H100:
SGLang e LMDeploy: questi motori raggiungono circa 16.200 token/s. SGLang raggiunge questo risultato tramite RadixAttention , un gestore di memoria specializzato progettato per modelli di erogazione complessi. LMDeploy lo raggiunge tramite TurboMind , un backend C++ personalizzato che elimina completamente l'overhead di Python.
vLLM: Anche con il backend FlashInfer abilitato, vLLM raggiunge un picco di circa 12.500 token/s. Sebbene questo rappresenti un notevole 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 del settore.
Differenze nella filosofia architetturale: SGLang e LMDeploy progettano congiuntamente i loro meccanismi di attenzione con presupposti a livello di kernel. vLLM mantiene un livello di compatibilità più ampio che richiede che gli algoritmi di attenzione funzionino con diversi backend, il che limita la portata delle ottimizzazioni specifiche su hardware di ultima generazione.
Ottimizzazione del modello di accesso alla memoria: il divario del 29% suggerisce che SGLang e LMDeploy ottimizzano la coalescenza della memoria, la località della cache e la pianificazione batch in modo più aggressivo di quanto consentito dallo scheduler di vLLM, in particolare nel modo in cui gestiscono il Tensor Memory Accelerator (TMA) dell'H100.
Metodologia di benchmarking
Ambiente di test
Configurazione hardware:
- GPU: NVIDIA H100 80GB HBM3
- Sistema: istanza cloud di RunPod
- Docker base: runpod/pytorch:1.0.2-cu1281-torch280-ubuntu2404
Versioni del software:
- CUDA: 12.8.1
- PyTorch: 2.8.0
- vLLM: 0.11.0 (FlashInfer abilitato)
- LMDeploy: 0.10.2
- SGLang: v0.2.3
Set di dati e carico di lavoro
Fonte: set di dati ShareGPT_Vicuna_unfiltered da Hugging Face
Criteri di selezione:
Perché questo dataset: ShareGPT contiene conversazioni reali tra utenti e chatbot con variazioni di lunghezza naturali, rappresentando in modo più accurato i carichi di lavoro dei chatbot in produzione rispetto ai benchmark sintetici.
Configurazioni del motore
Tutti i motori sono stati configurati per ottenere le massime prestazioni, garantendo al contempo l'equità:
Configurazione vLLM (backend FlashInfer):
Configurazione di 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 riscaldamento: vengono elaborati 20 prompt per attivare la compilazione JIT e stabilizzare le frequenze della GPU.
- Test di benchmark: Eseguire 10 passaggi completi di tutti i 1.000 prompt.
- Metodologia di cronometraggio:
- Conteggio dei token: estrai il numero effettivo di token dai formati di output specifici del motore.
- Calcolo del throughput: token_output_totali / durata.
Rigore statistico:
- 10.000 operazioni di inferenza totali (1.000 richieste × 10 esecuzioni per motore).
- Circa 1,5 milioni di token generati per ogni motore.
- La deviazione standard è risultata costantemente inferiore all'1% della media per 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 kernel migliori possibili (FlashInfer), vLLM non riesce a eguagliare il throughput di SGLang o LMDeploy. La differenza del 29% rappresenta il costo dell'orchestrazione in Python rispetto all'ottimizzazione nativa in C++.
La gerarchia delle prestazioni si applica esattamente a questo scenario: elaborazione batch di 1.000 richieste simultanee. SGLang e LMDeploy sono soluzioni affidabili che offrono un valore superiore di circa il 45% per ora di GPU rispetto alle implementazioni standard e del 29% rispetto alle implementazioni vLLM altamente ottimizzate.
Ciò che non si può generalizzare:
- Modelli diversi: Risultati specifici per Llama 3.1 8B. Modelli più grandi (ad esempio, 70B) o architetture diverse (ad esempio, Mixtral, Qwen) mostreranno modelli di scalatura diversi.
- Hardware differente: queste classifiche si applicano all'H100 da 80 GB. Su A100 o V100, la portabilità di vLLM potrebbe prevalere sulla specializzazione di SGLang.
- Metriche diverse: questa misura solo la velocità di trasmissione. Il servizio online richiede i percentili di TTFT e latenza, dove i risultati differiscono in modo significativo.
- Carichi di lavoro differenti: i prompt casuali riducono al minimo i vantaggi della memorizzazione nella cache dei prefissi. I prompt di sistema ripetuti o le conversazioni a più turni modificano drasticamente il panorama delle prestazioni a favore di SGLang.
uniformità dell'esperienza dello sviluppatore
I dati sulle prestazioni non forniscono un quadro completo dell'implementazione. Ogni motore offre flussi di lavoro di sviluppo distinti:
vLLM: uno standard di settore per ottime ragioni.
Semplicità e ampia compatibilità si incontrano. Un singolo comando pip install vllm supporta oltre 100 architetture di modelli su hardware NVIDIA, AMD e Intel. Una vasta community ti permette di trovare tutte le risposte che cerchi su Stack Overflow. Server API compatibile con OpenAI incluso.
- Scegli vLLM per: prototipazione rapida, ambienti GPU eterogenei, massima copertura del modello o per sfruttare il più ampio ecosistema.
LMDeploy: Livello di produzione con attrito minimo
L'installazione con una sola riga di codice (pip install lmdeploy) offre il 99,5% delle prestazioni massime di H100. Il backend nativo in C++ elimina qualsiasi overhead di Python. Supporto di prim'ordine per la quantizzazione (AWQ, GPTQ) per un'ulteriore ottimizzazione. Nessun problema di dipendenze.
- Scegli LMDeploy per le implementazioni in produzione che richiedono le massime prestazioni H100 senza sacrificare la semplicità di installazione o la stabilità.
SGLang: Limite di prestazioni con costo di complessità
La velocità di elaborazione massima assoluta (16.215 token/s) ha un costo: un notevole impegno nel debug dell'installazione di FlashInfer. Richiede una versione specifica di PyTorch. Incompatibilità binarie con alcuni pacchetti precompilati. RadixAttention eccelle nei carichi di lavoro conversazionali.
- Scegli SGLang se: hai bisogno di cluster di inferenza dedicati in cui un team specializzato può gestire le dipendenze e ogni singolo punto percentuale di throughput è fondamentale.
Sfide di installazione e implementazione
Per un confronto equo è stato necessario superare notevoli 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 includono di diverse.
Risoluzione:
Tempo necessario: 6 ore per identificare le versioni compatibili.
In sintesi: i pacchetti 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 non supportano FlashInfer o richiedono una complessa compilazione del codice sorgente.
Svolta: abbiamo utilizzato la build vLLM 0.11.0 su PyTorch 2.8 Nightly. Questo ha permesso di abilitare con successo il supporto nativo per 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 siano d'aiuto, non risolvono il collo di bottiglia architetturale.
Sfida 3: Individuazione del punto ottimale di utilizzo della memoria
Problema: la raccomandazione standard di utilizzo della memoria GPU pari a 0,9 ha causato 11329908 arresti anomali.
Progressione del test:
Scoperta: la cattura del grafico CUDA alloca RAM di sistema temporanea in proporzione all'utilizzo della memoria della GPU. Con un'allocazione di 0,9 × 80 GB = 72 GB sulla GPU, la RAM di sistema si esaurisce durante la compilazione.
Limite pratico: l'utilizzo della GPU allo 0,8% rappresenta la "zona di sicurezza" nonostante una capacità hardware di 80 GB.
Conclusione
Per l'inferenza batch 8B di Llama 3.1 su H100, la gerarchia delle prestazioni presenta due livelli ben distinti : vLLM (ottimizzato con FlashInfer) offre una solida base di partenza, mentre le architetture native C++ di SGLang e LMDeploy consentono di ottenere un ulteriore 29% di throughput .
SGLang (16.215 tok/s) e LMDeploy (16.132 tok/s) raggiungono una velocità di trasmissione pressoché identica, il che suggerisce che entrambi i motori saturano la larghezza di banda della memoria dell'H100. La minima differenza tra di loro è dovuta a un rumore statistico.
Per le implementazioni 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 token/s) offre un compromesso interessante: prestazioni rispettabili pur mantenendo la piena compatibilità hardware e la più ampia matrice di supporto modelli del settore. Tuttavia, per i cluster H100 dedicati, rinunciare al 29% delle prestazioni rappresenta un costo elevato.
Per la standardizzazione su infrastrutture eterogenee o per la sperimentazione rapida di modelli, vLLM rimane la scelta razionale. Per le implementazioni H100 dedicate, dove la velocità di trasmissione è fondamentale, la combinazione di prestazioni di alto livello e semplicità di installazione di LMDeploy è impareggiabile.
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 i modelli con PyTorch o TensorFlow di base, i motori di inferenza aggiungono ottimizzazioni fondamentali come una gestione efficiente della memoria, l'elaborazione in batch di più richieste e l'ottimizzazione del 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, ad esempio analizzando migliaia di documenti o generando embedding per un dataset. L'erogazione online gestisce le singole richieste degli utenti con rigorosi requisiti di latenza, dove metriche come il Time To First Token (TTFT) sono più importanti della semplice velocità di elaborazione. Il motore che eccelle in termini di velocità di elaborazione batch potrebbe non essere ottimale per i chatbot interattivi, quindi la scelta deve basarsi sul carico di lavoro effettivo.
Prossimo da leggere
Benchmark delle piattaforme di agenti AI: Claude Managed Agents vs Google Vertex Agent Engine
I 15 migliori strumenti di ottimizzazione per i motori di ricerca
Ottimizzazione dei motori di risposta (AEO): suggerimenti e migliori pratiche
Sii il primo a commentare
Il tuo indirizzo email non verrà pubblicato. Tutti i campi sono obbligatori.