LLM Inference-Engines: vLLM vs LMDeploy vs SGLang
Wir haben 3 führende LLM Inference-Engines auf NVIDIA H100 verglichen: vLLM, LMDeploy und SGLang. Jede Engine verarbeitete identische Workloads: 1.000 ShareGPT-Prompts mit Llama 3.1 8B-Instruct, um die tatsächliche Leistungsauswirkung ihrer Architekturentscheidungen und Optimierungsstrategien zu isolieren.
Engines | Am besten geeignet für |
|---|---|
vLLM | -Prototyping und Experimentieren mit über 100 Modellarchitekturen -Multi-GPU-Umgebungen (NVIDIA, AMD, Intel) |
LMDeploy | -Produktionseinsätze, die H100-Leistung bei minimaler Komplexität erfordern -Teams, die Wert auf einfache Installation legen (Einzeilen-pip-Installation) |
SGLang | -Organisationen, die einen absolut maximalen Durchsatz benötigen (16.215 Tok/s) -Dedizierte Inferenzcluster |
Benchmark-Ergebnisse der Inference-Engines
Wir haben den Offline-Batch-Durchsatz über 10.000 gesamte Inferenzoperationen gemessen (1.000 Prompts × 10 Durchläufe pro Engine), um statistische Stabilität zu gewährleisten.
- Durchsatz: Ausgegebene Tokens pro Sekunde im Batch-Inferenzmodus. Misst, wie effizient jede Engine die Rechenkapazitäten der H100 nutzt.
Alle Engines wurden für ihre maximale theoretische Leistung konfiguriert: Llama 3.1 8B-Instruct, bfloat16-Präzision und 0,8 GPU-Speicherauslastung auf H100 80 GB Hardware.
Um zu verstehen, wie wir die Durchsatzraten berechnet haben, lesen Sie bitte unsere Inferenz-Benchmark-Methodik.
Kernergebnisse
Unser Ansatz minimiert Störfaktoren: identisches Modell, Hardware, Datensatz, Sampling-Konfiguration, Speicherlimits und Aufwärmprotokoll. Diese Isolation zeigt, was die Architektur jeder Engine tatsächlich beiträgt.
Der architektonische Abstand beträgt 29 %: Selbst wenn vLLM mit denselben Kernels (FlashInfer) wie SGLang optimiert ist, liegt es immer noch deutlich hinter den Spitzenreitern. SGLang (16.215 Tok/s) und LMDeploy (16.132 Tok/s) halten einen 29 % Vorteil gegenüber dem vollständig optimierten vLLM (12.553 Tok/s). Dies deutet darauf hin, dass der Engpass nicht mehr der mathematische Kernel ist, sondern der interne Orchestrierungs-Overhead der Engine.
SGLang und LMDeploy sind praktisch gleichauf: Der Leistungsunterschied zwischen ihnen beträgt weniger als 0,6 %, was innerhalb der Fehlermarge liegt. Dies legt nahe, dass sowohl der Ansatz „Python + Native Kernels“ (SGLang) als auch der Ansatz „Pure C++ Engine“ (LMDeploy) gleichermaßen gültige Strategien zur Erzielung von Spitzenleistung auf Hopper-Architekturen sind.
GPU-Speicher-„Sicherheitszone“ bei 80 % Auslastung: Versuche, 95 % GPU-Speicher zuzuweisen, verursachten während der CUDA-Graph-Kompilierung bei allen Engines sofortige Abstürze, trotz der 80 GB Kapazität. Als Ursache wurde die Erschöpfung des System-RAM während der Grapherfassung identifiziert, nicht die GPU-Speicherlimits. Ein Anteil von 0,8 bot das optimale Gleichgewicht zwischen Stabilität und Stapelgröße.
Die Leistungshierarchie verstehen
Die Durchsatzunterschiede zeigen eine klare Unterscheidung zwischen den Engine-Architekturen auf der H100:
SGLang & LMDeploy: Diese Engines erreichen ~16.200 Tok/s. SGLang erreicht dies durch RadixAttention, einen spezialisierten Speichermanager, der für komplexe Bereitstellungsmuster entwickelt wurde. LMDeploy erreicht dies durch TurboMind, ein benutzerdefiniertes C++-Backend, das den Python-Overhead vollständig eliminiert.
vLLM: Selbst mit aktiviertem FlashInfer-Backend erreicht vLLM Spitzenwerte von ~12.500 Tok/s. Dies ist zwar eine massive Verbesserung gegenüber Standardkonfigurationen, aber die verbleibende Lücke unterstreicht die Kosten der flexiblen, plugin-basierten Architektur von vLLM (PagedAttention) im Vergleich zu den hyperspezialisierten Designs der Spitzenreiter.
Unterschiede in der Architekturphilosophie: SGLang und LMDeploy entwerfen ihre Aufmerksamkeitsmechanismen zusammen mit den Kernel-Annahmen. vLLM unterhält eine breitere Kompatibilitätsschicht, die erfordert, dass Aufmerksamkeitsalgorithmen mit verschiedenen Backends funktionieren, was die Tiefe spezifischer Optimierungen auf modernster Hardware einschränkt.
Optimierung der Speicherzugriffsmuster: Die Lücke von 29 % deutet darauf hin, dass SGLang und LMDeploy die Speicherzusammenführung, Cache-Lokalität und Batch-Planung aggressiver optimieren als der Scheduler von vLLM es zulässt, insbesondere im Umgang mit dem Tensor Memory Accelerator (TMA) der H100.
Benchmark-Methodik
Testumgebung
Hardwarekonfiguration:
- GPU: NVIDIA H100 80 GB HBM3
- System: RunPod Cloud-Instanz
- Docker-Basis: runpod/pytorch:1.0.2-cu1281-torch280-ubuntu2404
Softwareversionen:
- CUDA: 12.8.1
- PyTorch: 2.8.0
- vLLM: 0.11.0 (FlashInfer aktiviert)
- LMDeploy: 0.10.2
- SGLang: v0.2.3
Datensatz und Workload
Quelle: ShareGPT_Vicuna_unfiltered Datensatz von Hugging Face
Auswahlkriterien:
Warum dieser Datensatz: ShareGPT enthält echte Benutzer-Chatbot-Konversationen mit natürlicher Längenvariation, die Produktions-Chatbot-Workloads genauer abbilden als synthetische Benchmarks.
Engine-Konfigurationen
Alle Engines wurden für maximale Leistung bei gleichzeitiger Wahrung der Fairness konfiguriert:
vLLM-Setup (FlashInfer Backend):
LMDeploy-Setup:
SGLang-Setup:
Messverfahren
Auf alle Engines angewendetes Standardprotokoll:
- Modell laden: Herunterladen und Initialisieren des Modells mit bfloat16-Präzision.
- Aufwärmphase: Verarbeiten von 20 Prompts, um die JIT-Kompilierung auszulösen und die GPU-Taktraten zu stabilisieren.
- Benchmark-Durchläufe: Ausführen von 10 vollständigen Durchläufen aller 1.000 Prompts.
- Zeitmessmethodik:
- Token-Zählung: Extrahieren der tatsächlichen Token-Anzahlen aus Engine-spezifischen Ausgabeformaten.
- Durchsatzberechnung: Gesamte_Ausgabe-Tokens / Dauer.
Statistische Genauigkeit:
- 10.000 gesamte Inferenzoperationen (1.000 Prompts × 10 Durchläufe pro Engine).
- ~1,5 Millionen generierte Tokens pro Engine.
- Standardabweichung konstant <1 % des Mittelwerts über alle Engines.
Interpretation der Ergebnisse
Was Sie schlussfolgern können:
Für die Offline-Stapelinferenz von Llama 3.1 8B auf H100-Hardware bestimmt die architektonische Effizienz den Gewinner. Selbst mit den bestmöglichen Kernels (FlashInfer) kann vLLM den Durchsatz von SGLang oder LMDeploy nicht erreichen. Die Lücke von 29 % stellt die Kosten der Python-Orchestrierung gegenüber der nativen C++-Optimierung dar.
Die Leistungshierarchie gilt für dieses exakte Szenario: gleichzeitige Stapelverarbeitung von 1.000 Prompts. SGLang und LMDeploy sind robuste Optionen, die ~45 % mehr Wert pro GPU-Stunde liefern als Standardbereitstellungen und ~29 % mehr als hochoptimierte vLLM-Bereitstellungen.
Was Sie nicht verallgemeinern können:
- Unterschiedliche Modelle: Ergebnisse spezifisch für Llama 3.1 8B. Größere Modelle (z. B. 70B) oder andere Architekturen (z. B. Mixtral, Qwen) zeigen andere Skalierungsmuster.
- Unterschiedliche Hardware: Diese Rangfolge gilt für die H100 80 GB. Bei A100 oder V100 könnte die Portabilität von vLLM die Spezialisierung von SGLang aufwiegen.
- Unterschiedliche Metriken: Dies misst nur den Durchsatz. Online-Serving erfordert TTFT- und Latenzperzentile, wo die Ergebnisse erheblich abweichen.
- Unterschiedliche Workloads: Zufällige Prompts minimieren die Vorteile der Präfix-Zwischenspeicherung. Wiederholte System-Prompts oder Multi-Turn-Konversationen verschieben die Leistungslandschaft drastisch zugunsten von SGLang.
Vergleich der Entwicklererfahrung
Leistungskennzahlen erfassen nicht das vollständige Bild der Bereitstellung. Jede Engine bietet eigene Entwicklungsworkflows:
vLLM: Industriestandard aus gutem Grund
Einfachheit trifft auf breite Kompatibilität. Eine einzige pip-Installation vllm unterstützt 100+ Modellarchitekturen auf NVIDIA-, AMD- und Intel-Hardware. Eine riesige Community bedeutet, dass Stack Overflow Ihre Antworten hat. OpenAI-kompatibler API-Server inklusive.
- Wählen Sie vLLM für: Schnelles Prototyping, heterogene GPU-Umgebungen, maximale Modellabdeckung oder die Nutzung des größten Ökosystems.
LMDeploy: Produktionsreif mit minimaler Reibung
Einzeilige Installation (pip install lmdeploy) liefert 99,5 % der H100-Spitzenleistung. Natives C++-Backend bedeutet null Python-Overhead. Erstklassige Quantisierungsunterstützung (AWQ, GPTQ) für weitere Optimierung. Keine Abhängigkeitshölle.
- Wählen Sie LMDeploy für Produktionseinsätze, die maximale H100-Leistung erfordern, ohne auf Installationsfreundlichkeit oder Stabilität zu verzichten.
SGLang: Leistungsgrenze mit Komplexitätskosten
Der absolute Spitzendurchsatz (16.215 Tok/s) hat seinen Preis: erheblicher Aufwand beim Debuggen der FlashInfer-Installation. Erfordert eine bestimmte PyTorch-Version. Binäre Inkompatibilitäten mit einigen vorkompilierten Wheels. RadixAttention glänzt bei konversationellen Workloads.
- Wählen Sie SGLang für: Dedizierte Inferenzcluster, bei denen ein spezialisiertes Team Abhängigkeiten verwalten kann und Sie jeden letzten Prozentpunkt Durchsatz benötigen.
Installations- und Bereitstellungsherausforderungen
Ein fairer Vergleich erforderte die Überwindung erheblicher technischer Hürden:
Herausforderung 1: FlashInfer-Abhängigkeitskonflikte
Problem: Die FlashInfer-Wheels von SGLang erwarten bestimmte PyTorch-Versionen, aber H100-optimierte Container liefern oft andere.
Lösung:
Zeitaufwand: 6 Stunden zur Identifizierung kompatibler Versionen.
Fazit: Vorkompilierte ML-Wheels verbergen oft Versionsbeschränkungen, die erst zur Laufzeit auftreten.
Herausforderung 2: FlashInfer in vLLM aktivieren
Problem: Standardmäßige vLLM-Versionen haben oft keine FlashInfer-Unterstützung oder erfordern eine komplexe Quellkompilierung.
Durchbruch: Wir haben den vLLM 0.11.0-Build auf PyTorch 2.8 Nightly verwendet. Dies ermöglichte erfolgreich native FlashInfer-Unterstützung via pip install “vllm[flashinfer]==0.11.0” und umging die Kompilierungsbarrieren älterer Versionen.
Auswirkung: Dies ermöglichte den fairsten möglichen Vergleich und bestätigte, dass Kernels zwar helfen, aber den architektonischen Engpass nicht lösen.
Herausforderung 3: Entdeckung des optimalen Speicherauslastungspunkts
Problem: Die Standardempfehlung von 0,9 GPU-Speicherauslastung verursachte std::bad_alloc Abstürze.
Testverlauf:
Erkenntnis: Die CUDA-Graph-Erfassung weist temporären System-RAM proportional zur GPU-Speichernutzung zu. Bei 0,9 × 80 GB = 72 GB GPU-Zuweisung ist der System-RAM während der Kompilierung erschöpft.
Praktisches Limit: 0,8 GPU-Auslastung ist die „Sicherheitszone“ trotz 80 GB Hardware-Kapazität.
Fazit
Für die Llama 3.1 8B-Stapelinferenz auf der H100 hat die Leistungshierarchie zwei klare Stufen: vLLM (mit FlashInfer optimiert) bietet eine solide Basis, während die C++-nativen Architekturen von SGLang und LMDeploy zusätzliche 29 % mehrDurchsatz freisetzen.
SGLang (16.215 Tok/s) und LMDeploy (16.132 Tok/s) erreichen nahezu identischen Durchsatz, was darauf hindeutet, dass beide Engines die Speicherbandbreite der H100 auslasten. Der minimale Unterschied zwischen ihnen ist statistisches Rauschen.
Für Produktionseinsätze: LMDeploy erweist sich als praktischer Gewinner, da es 99,5 % des Spitzendurchsatzes von SGLang mit trivialer Installation (pip install lmdeploy) gegenüber der komplexen Abhängigkeitsauflösung von SGLang liefert.
vLLM mit FlashInfer (12.553 Tok/s) bietet einen überzeugenden Mittelweg: respektable Leistung bei voller Hardware-Kompatibilität und der branchenweit größten Modellunterstützungsmatrix. Für dedizierte H100-Cluster ist es jedoch ein hoher Preis, 29 % Leistung liegen zu lassen.
Für die Standardisierung über heterogene Infrastruktur oder schnelle Modellexperimente bleibt vLLM die rationale Wahl. Für dedizierte H100-Bereitstellungen, bei denen der Durchsatz an erster Stelle steht, ist die Kombination aus Spitzenleistung und Installationsfreundlichkeit von LMDeploy unübertroffen.
Als bevorzugte Quelle hinzufügenFAQs
Eine LLM Inference-Engine ist eine spezialisierte Software, die optimiert, wie große Sprachmodelle Antworten generieren. Während Sie Modelle mit einfachem PyTorch oder TensorFlow ausführen können, fügen Inference-Engines entscheidende Optimierungen wie effiziente Speicherverwaltung, Stapelverarbeitung mehrerer Anfragen und GPU-Kerneloptimierungen hinzu. Diese Verbesserungen können den Durchsatz (generierte Tokens pro Sekunde) drastisch erhöhen und Kosten senken und möglicherweise eine 3- bis 5-fach bessere Leistung auf derselben Hardware liefern.
Offline-Stapelinferenz verarbeitet viele Prompts gleichzeitig ohne Echtzeitanforderungen, denken Sie an die Analyse Tausender Dokumente oder die Generierung von Embeddings für einen Datensatz. Online-Serving bearbeitet einzelne Benutzeranfragen mit strengen Latenzanforderungen, wobei Metriken wie die Time To First Token (TTFT) mehr zählen als der reine Durchsatz. Die Engine, die beim Batch-Durchsatz gewinnt, ist möglicherweise nicht optimal für interaktive Chatbots, also wählen Sie basierend auf Ihrem tatsächlichen Workload-Muster.
Diese Forschung zitieren
Wählen Sie das Format, das zu Ihrem Veröffentlichungsort passt. Wenn Sie die Link-Version in Ihr CMS einfügen, bleibt der Backlink erhalten.
@misc{dilmegani2026,
author = {Dilmegani, Cem and Sarı, Ekrem},
title = {{LLM Inference-Engines: vLLM vs LMDeploy vs SGLang}},
year = {2026},
month = apr,
howpublished = {\url{https://aimultiple.com/inference-engines}},
note = {AIMultiple. Abgerufen am 15. April 2026}
}
Seien Sie der Erste, der kommentiert
Ihre E-Mail-Adresse wird nicht veröffentlicht. Alle Felder sind erforderlich. Kommentare werden in ihrer Originalsprache belassen.