LLM Inferenz-Engines: vLLM vs LMDeploy vs SGLang
Wir haben 3 führende LLM-Inferenz-Engines auf NVIDIA H100 getestet: vLLM, LMDeploy und SGLang. Jede Engine verarbeitete identische Workloads: 1.000 ShareGPT-Prompts mit Llama 3.1 8B-Instruct, um den tatsächlichen Leistungseinfluss ihrer architektonischen Entscheidungen und Optimierungsstrategien zu isolieren.
Engines | Am besten geeignet für |
|---|---|
vLLM | -Prototyping und Experimente mit über 100 Modellarchitekturen -Multi GPU-Umgebungen (NVIDIA, AMD, Intel) |
LMDeploy | -Produktionseinsätze, die H100-Leistung mit minimaler Komplexität erfordern -Teams, die Installationsvereinfachung priorisieren (einzeiliges pip-Install) |
SGLang | -Organisationen, die absoluten maximalen Durchsatz benötigen (16.215 tok/s) -Dedizierte Inferenz-Cluster |
Ergebnisse des Benchmark-Tests der Inferenz-Engines
Wir haben den Offline-Batch-Durchsatz über 10.000 Inferenzvorgänge insgesamt (1.000 Prompts × 10 Durchläufe pro Engine) gemessen, um statistische Stabilität zu gewährleisten.
- Durchsatz: Ausgegebene Token pro Sekunde im Batch-Inferenzmodus. Misst, wie effizient jede Engine die Rechenleistung 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-Speichernutzung auf H100 80GB-Hardware.
Um zu verstehen, wie wir die Durchsatzraten berechnet haben, lesen Sie bitte unsere Methodik für Inferenz-Benchmarks.
Wichtige Erkenntnisse
Unser Ansatz minimiert störende Variablen: identisches Modell, Hardware, Datensatz, Sampling-Konfiguration, Speichergrenzen und Warmup-Protokoll. Diese Isolierung zeigt, was die Architektur jeder Engine wirklich beiträgt.
Die architektonische Lücke beträgt 29%: Selbst wenn vLLM mit exakt den gleichen Kernen (FlashInfer) wie SGLang optimiert wird, bleibt es den Führern deutlich hinterher. SGLang (16.215 tok/s) und LMDeploy (16.132 tok/s) haben einen Vorteil von 29% gegenüber dem vollständig optimierten vLLM (12.553 tok/s). Dies zeigt, dass die Engstelle nicht mehr der mathematische Kern ist, sondern der interne Orchestrierungsaufwand der Engine.
SGLang und LMDeploy sind effektiv gleichauf: der Leistungsunterschied zwischen ihnen beträgt weniger als 0,6%, was innerhalb der Fehlergrenze liegt. Dies legt nahe, dass sowohl der Ansatz „Python + Native Kernels" (SGLang) als auch der Ansatz „Pure C++ Engine" (LMDeploy) gleichwertige Strategien zur Erreichung der Spitzenleistung auf Hopper-Architekturen sind.
GPU-Speicher „Sicherheitszone" bei 80% Auslastung: Versuche, 95% GPU-Speicher zuzuweisen, führten zu sofortigen Abstürzen während der CUDA-Graph-Kompilierung bei allen Engines, trotz der 80GB-Kapazität. Die Ursache wurde als Erschöpfung des SystemRAM während der Graphenerfassung identifiziert, nicht als GPU-Speichergrenzen. Ein Faktor von 0,8 bot das optimale Gleichgewicht zwischen Stabilität und Batch-Größe.
Verstehen der Leistungshierarchie
Die Durchsatzunterschiede zeigen einen klaren Unterschied zwischen Engine-Architekturen auf H100:
SGLang & LMDeploy: Diese Engines erreichen ~16.200 tok/s. SGLang erreicht dies durch RadixAttention, einen spezialisierten Speichermanager, der für komplexe Servicing-Muster entwickelt wurde. LMDeploy erreicht dies durch TurboMind, eine benutzerdefinierte C++-Backend, die Python-Overhead vollständig eliminiert.
vLLM: Selbst mit aktiviertem FlashInfer-Backend erreicht vLLM maximal ~12.500 tok/s. Obwohl dies eine massive Verbesserung gegenüber Standardkonfigurationen ist, zeigt die verbleibende Lücke die Kosten von vLLMs flexibler, plugin-basierter Architektur (PagedAttention) im Vergleich zu den hochspezialisierten Designs der Führer.
Unterschiede in der Architekturphilosophie: SGLang und LMDeploy entwerfen ihre Aufmerksamkeitsmechanismen gemeinsam mit Kernel-Annahmen. vLLM unterhält eine breitere Kompatibilitätsschicht, die erfordert, dass Aufmerksamkeitsalgorithmen mit verschiedenen Backends funktionieren, was die Tiefe spezifischer Optimierungen auf hochmoderner Hardware begrenzt.
Optimierung des Speicherzugriffsmusters: Die 29% Lücke deutet darauf hin, dass SGLang und LMDeploy die Speicherzusammenführung, Cache-Lokalität und Batch-Planung aggressiver optimieren als es der vLLM-Planer zulässt, insbesondere bei der Handhabung des H100 Tensor Memory Accelerator (TMA).
Benchmark-Methodik
Testumgebung
Hardwarekonfiguration:
- GPU: NVIDIA H100 80GB 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-Gespräche mit natürlicher Längenvariation und repräsentiert Produktions-Chatbot-Workloads genauer als synthetische Benchmarks.
Engine-Konfigurationen
Alle Engines wurden für maximale Leistung konfiguriert, während Fairness gewahrt wurde:
vLLM-Setup (FlashInfer Backend):
LMDeploy-Setup:
SGLang-Setup:
Messverfahren
Standardprotokoll für alle Engines angewendet:
- Modell-Laden: Herunterladen und Initialisieren des Modells mit bfloat16-Präzision.
- Warmup-Phase: Verarbeiten von 20 Prompts, um JIT-Kompilierung auszulösen und GPU-Taktraten zu stabilisieren.
- Benchmark-Durchläufe: Ausführen von 10 vollständigen Durchläufen aller 1.000 Prompts.
- Timing-Methodik:
- Token-Zählen: Extrahieren der tatsächlichen Token-Anzahlen aus enginespezifischen Ausgabeformaten.
- Durchsatzberechnung: total_output_tokens / duration.
Statistische Strenge:
- 10.000 Inferenzvorgänge insgesamt (1.000 Prompts × 10 Durchläufe pro Engine).
- ~1,5 Millionen Token pro Engine generiert.
- Standardabweichung konsistent <1% des Mittelwerts über alle Engines.
Interpretation der Ergebnisse
Was Sie schlussfolgern können:
Für Offline-Batch-Inferenz von Llama 3.1 8B auf H100-Hardware bestimmt die architektonische Effizienz den Gewinner. Selbst mit den besten möglichen Kernen (FlashInfer) kann vLLM den Durchsatz von SGLang oder LMDeploy nicht erreichen. Die 29% Lücke repräsentiert die Kosten der Python-Orchestrierung im Vergleich zur nativen C++-Optimierung.
Die Leistungshierarchie gilt für dieses exakte Szenario: Batch-Verarbeitung von 1.000 Prompts gleichzeitig. SGLang und LMDeploy sind robuste Wahlmöglichkeiten, 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) werden unterschiedliche Skalierungsmuster aufweisen.
- Unterschiedliche Hardware: Diese Ranglisten gelten für H100 80GB. Auf A100 oder V100 kann vLLMs Portabilität SGLangs Spezialisierung überwiegen.
- Unterschiedliche Metriken: Dies misst nur den Durchsatz. Online-Serving erfordert TTFT und Latenz-Perzentile, wo die Ergebnisse erheblich abweichen.
- Unterschiedliche Workloads: Zufällige Prompts minimieren die Vorteile des Prefix-Cachings. Wiederholte System-Prompts oder Multi-Turn-Gespräche verschieben die Leistungslandschaft drastisch zugunsten von SGLang.
Vergleich der Entwicklererfahrung
Leistungszahlen erfassen nicht das gesamte Bereitstellungsprofil. Jede Engine bietet unterschiedliche Entwickler-Workflows:
vLLM: Industriestandard aus gutem Grund
Einfachheit trifft auf breite Kompatibilität. Single pip install vllm unterstützt über 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 Nutzung des größten Ökosystems.
LMDeploy: Produktionsreif mit minimalem Reibungswiderstand
Einzeilige Installation (pip install lmdeploy) liefert 99,5% der Spitzenleistung von H100. Native C++-Backend bedeutet null Python-Overhead. Erstklassige Quantisierungsunterstützung (AWQ, GPTQ) für weitere Optimierung. Keine Abhängigkeits-Hölle.
- Wählen Sie LMDeploy für Produktionseinsätze, die maximale H100-Leistung erfordern, ohne Installationsvereinfachung oder Stabilität zu opfern.
SGLang: Leistungsobergrenze mit Komplexitätskosten
Der absolute Spitzen-Durchsatz (16.215 tok/s) kommt zu einem Preis: erheblicher Aufwand beim Debuggen der FlashInfer-Installation. Erfordert eine spezifische PyTorch-Version. Binäre Inkompatibilitäten mit einigen vorgefertigten Wheels. RadixAttention glänzt bei konversationellen Workloads.
- Wählen Sie SGLang für: Dedizierte Inferenz-Cluster, wo ein spezialisiertes Team Abhängigkeiten verwalten kann und Sie jeden letzten Prozentsatz des Durchsatzes benötigen.
Als bevorzugte Quelle hinzufügenHerausforderungen bei Installation und Bereitstellung
Ein fairer Vergleich erforderte die Überwindung erheblicher technischer Hürden:
Herausforderung 1: FlashInfer-Abhängigkeitskonflikte
Problem: SGLangs FlashInfer-Wheels erwarten spezifische 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 sichtbar werden.
Herausforderung 2: Aktivierung von FlashInfer in vLLM
Problem: Standard-vLLM-Versionen bieten oft keine FlashInfer-Unterstützung oder erfordern komplexe Quellkompilierung.
Durchbruch: Wir nutzten den vLLM 0.11.0-Build auf PyTorch 2.8 Nightly. Dies ermöglichte erfolgreich native FlashInfer-Unterstützung via pip install „vllm[flashinfer]==0.11.0" und umging die Kompilierungshürden älterer Versionen.
Auswirkung: Dies bot den fairesten möglichen Vergleich und bestätigte, dass Kerne helfen, aber die architektonische Engstelle nicht lösen.
Herausforderung 3: Entdeckung des optimalen Speicher-Auslastungspunkts
Problem: Die Standardempfehlung von 0,9 GPU-Speichernutzung verursachte std::bad_alloc Abstürze.
Testfortschritt:
Entdeckung: CUDA-Graph-Erfassung weist temporären SystemRAM proportional zur GPU-Speichernutzung zu. Bei 0,9 × 80GB = 72GB GPU-Zuweisung ist der SystemRAM während der Kompilierung erschöpft.
Praktisches Limit: 0,8 GPU-Auslastung ist die „Sicherheitszone" trotz 80GB-Hardwarekapazität.
Fazit
Für Llama 3.1 8B-Batch-Inferenz auf H100 hat die Leistungshierarchie zwei klare Ebenen: vLLM (optimiert mit FlashInfer) bietet eine solide Basis, während die C++-nativen Architekturen von SGLang und LMDeploy zusätzliche 29% imDurchsatz freischalten.
SGLang (16.215 tok/s) und LMDeploy (16.132 tok/s) erreichen nahezu identischen Durchsatz, was darauf hindeutet, dass beide Engines die Speicherbandleistung von H100 ausreizen. Die minimale Lücke zwischen ihnen ist statistisches Rauschen.
Für Produktionseinsätze: LMDeploy erweist sich als praktischer Gewinner und liefert 99,5% von SGLangs Spitzen-Durchsatz mit trivialer Installation (pip install lmdeploy) im Vergleich zu SGLangs komplexer Abhängigkeitsauflösung.
vLLM mit FlashInfer (12.553 tok/s) bietet eine überzeugende Mitte: respektable Leistung bei voller Hardwarekompatibilität und dem größten Modell-Unterstützungsmatrix der Branche. Für dedizierte H100-Cluster ist es jedoch ein hoher Preis, 29% Leistung auf dem Tisch zu lassen.
Für Standardisierung über heterogene Infrastruktur oder schnelles Modell-Experimentieren bleibt vLLM die rationale Wahl. Für dedizierte H100-Bereitstellungen, bei denen Durchsatz von höchster Priorität ist, ist LMDeploys Kombination aus Spitzenleistung und Installationsvereinfachung unübertroffen.
FAQs
Eine LLM-Inferenz-Engine ist spezialisierte Software, die optimiert, wie große Sprachmodelle Antworten generieren. Obwohl Sie Modelle mit grundlegendem PyTorch oder TensorFlow ausführen können, fügen Inferenz-Engines kritische Optimierungen hinzu, wie effizientes Speichermanagement, Bündelung mehrerer Anfragen und GPU-Kernel-Optimierungen. Diese Verbesserungen können den Durchsatz (generierte Token pro Sekunde) drastisch erhöhen und Kosten senken, was potenziell 3-5x bessere Leistung auf derselben Hardware liefert.
Offline-Batch-Inferenz verarbeitet viele Prompts gleichzeitig ohne Echtzeitanforderungen, denken Sie an die Analyse Tausender Dokumente oder das Generieren von Embeddings für einen Datensatz. Online-Serving verarbeitet einzelne Benutzeranfragen mit strengen Latenzanforderungen, wo Metriken wie Time To First Token (TTFT) wichtiger sind als roher Durchsatz. Die Engine, die beim Batch-Durchsatz gewinnt, ist möglicherweise nicht optimal für interaktive Chatbots, wählen Sie also 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 Inferenz-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.