LLM-Inferenzmaschinen: vLLM vs. LMDeploy vs. SGLang
Wir haben drei führende LLM-Inferenz-Engines auf dem H100-System (NVIDIA) getestet: vLLM, LMDeploy und SGLang. Jede Engine verarbeitete identische Arbeitslasten: 1.000 ShareGPT-Prompts mit Llama 3.1 8B-Instruct, um die tatsächlichen Leistungsauswirkungen ihrer Architektur und Optimierungsstrategien zu ermitteln.
Motoren | Am besten geeignet für |
|---|---|
vLLM | -Prototyping und Experimente mit über 100 Modellarchitekturen -Multi-GPU-Umgebungen (NVIDIA, AMD, Intel) |
LMDeploy | -Produktionsbereitstellungen, die H100-Leistung bei minimaler Komplexität erfordern -Teams, die Wert auf einfache Installation legen (einzeilige pip-Installation) |
SGLang | -Organisationen, die einen absolut maximalen Durchsatz (16.215 t/s) benötigen -Dedizierte Inferenzcluster |
Benchmark-Ergebnisse für Inferenzmaschinen
Um die statistische Stabilität zu gewährleisten, haben wir den Offline-Batch-Durchsatz über insgesamt 10.000 Inferenzoperationen (1.000 Eingabeaufforderungen × 10 Läufe pro Engine) gemessen.
- Durchsatz: Anzahl der pro Sekunde im Batch-Inferenzmodus generierten Ausgabetoken. Misst, wie effizient jede Engine die Rechenkapazität des H100 nutzt.
Alle Engines wurden für ihre maximale theoretische Leistung konfiguriert: Llama 3.1 8B-Instruct, bfloat16 Genauigkeit und 0,8 GPU-Speicherauslastung auf H100 80GB Hardware.
Um zu verstehen, wie wir die Durchsatzraten berechnet haben, lesen Sie bitte unsere Methodik für Inferenz-Benchmarks.
Wichtigste Erkenntnisse
Unser Ansatz minimiert Störvariablen: identisches Modell, identische Hardware, identischer Datensatz, identische Sampling-Konfiguration, identische Speichergrenzen und identisches Aufwärmprotokoll. Diese Isolation zeigt, welchen Beitrag die Architektur jeder Engine tatsächlich leistet.
Die architektonische Lücke beträgt 29 %: Selbst wenn vLLM mit denselben Kernels (FlashInfer) wie SGLang optimiert wird, bleibt es deutlich hinter den führenden Systemen zurück. SGLang (16.215 tok/s) und LMDeploy (16.132 tok/s) weisen einen Vorsprung von 29 % gegenüber dem vollständig optimierten vLLM (12.553 tok/s) auf. Dies deutet darauf hin, dass der Flaschenhals nicht mehr der mathematische Kernel ist, sondern der interne Orchestrierungsaufwand der Engine.
SGLang und LMDeploy liegen leistungsmäßig praktisch gleichauf: Der Leistungsunterschied beträgt weniger als 0,6 % und liegt damit innerhalb der Fehlertoleranz. Dies deutet darauf hin, dass sowohl der Ansatz „Python + Native Kernels“ (SGLang) als auch der Ansatz „Reine C++ Engine“ (LMDeploy) gleichermaßen valide Strategien zur Erzielung maximaler Leistung auf Hopper-Architekturen darstellen.
GPU-Speicher-„Sicherheitszone“ bei 80 % Auslastung: Versuche, 95 % des GPU-Speichers zuzuweisen, führten trotz der 80 GB Kapazität zu sofortigen Abstürzen während der CUDA-Graphkompilierung auf allen Engines. Die Ursache lag in der Erschöpfung des System-RAM während der Grapherfassung, nicht in den GPU-Speichergrenzen. Ein Anteil von 0,8 erwies sich als optimales Gleichgewicht zwischen Stabilität und Batchgröße.
Die Leistungshierarchie verstehen
Die Durchsatzunterschiede offenbaren einen deutlichen Unterschied zwischen den Motorarchitekturen des H100:
SGLang & LMDeploy: Diese Engines erreichen ca. 16.200 Tok/s. SGLang erzielt dies durch RadixAttention , einen spezialisierten Speichermanager für komplexe Serverarchitekturen. LMDeploy erreicht dies durch TurboMind , ein eigens entwickeltes C++-Backend, das den Python-Overhead vollständig eliminiert.
vLLM: Selbst mit aktiviertem FlashInfer-Backend erreicht vLLM maximal ~12.500 tok/s. Dies ist zwar eine deutliche Verbesserung gegenüber Standardkonfigurationen, doch die verbleibende Differenz verdeutlicht die Nachteile der flexiblen, pluginbasierten Architektur von vLLM (PagedAttention) im Vergleich zu den hochspezialisierten Designs der Marktführer.
Architekturphilosophieunterschiede: SGLang und LMDeploy entwickeln ihre Aufmerksamkeitsmechanismen gemeinsam mit Kernel-Annahmen. vLLM hingegen verwendet eine umfassendere Kompatibilitätsschicht, die voraussetzt, dass Aufmerksamkeitsalgorithmen mit verschiedenen Backends funktionieren. Dies schränkt die Tiefe spezifischer Optimierungen auf modernster Hardware ein.
Optimierung des Speicherzugriffsmusters: Die Differenz von 29 % lässt vermuten, dass SGLang und LMDeploy die Speicherzusammenführung, die Cache-Lokalität und die Batch-Planung aggressiver optimieren, als es der Scheduler von vLLM zulässt, insbesondere in Bezug auf die Handhabung des Tensor Memory Accelerator (TMA) des H100.
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 Arbeitslast
Quelle: ShareGPT_Vicuna_unfiltered-Datensatz von Hugging Face
Auswahlkriterien:
Warum dieser Datensatz? ShareGPT enthält reale Benutzer-Chatbot-Konversationen mit natürlichen Längenvariationen und bildet damit die Arbeitslasten von Chatbots in der Praxis genauer ab als synthetische Benchmarks.
Motorkonfigurationen
Alle Motoren wurden auf maximale Leistung unter Wahrung der Fairness konfiguriert:
vLLM-Setup (FlashInfer-Backend):
LMDeploy-Setup:
SGLang-Setup:
Messverfahren
Standardprotokoll gilt für alle Motoren:
- Modell laden: Laden Sie das Modell herunter und initialisieren Sie es mit bfloat16-Genauigkeit.
- Aufwärmphase: Prozess 20 fordert dazu auf, die JIT-Kompilierung auszulösen und die GPU-Taktraten zu stabilisieren.
- Benchmark-Testläufe: Führen Sie 10 vollständige Durchläufe aller 1000 Eingabeaufforderungen durch.
- Zeitmessungsmethodik:
- Tokenzählung: Extrahieren der tatsächlichen Tokenanzahl aus den enginespezifischen Ausgabeformaten.
- Durchsatzberechnung: Gesamtzahl der ausgegebenen Token / Dauer.
Statistische Strenge:
- Insgesamt 10.000 Inferenzoperationen (1.000 Eingabeaufforderungen × 10 Durchläufe pro Engine).
- Pro Engine werden ca. 1,5 Millionen Token generiert.
- Die Standardabweichung lag bei allen Motoren durchgehend unter 1 % des Mittelwerts.
Interpretation der Ergebnisse
Was man daraus schließen kann:
Für die Offline-Batch-Inferenz von Llama 3.1 8B auf H100-Hardware ist die Architektureffizienz ausschlaggebend. Selbst mit den bestmöglichen Kernels (FlashInfer) erreicht vLLM nicht den Durchsatz von SGLang oder LMDeploy. Die Differenz von 29 % entspricht den Kosten der Python-Orchestrierung im Vergleich zur nativen C++-Optimierung.
Die Leistungshierarchie gilt genau für dieses Szenario: die gleichzeitige Stapelverarbeitung von 1.000 Eingabeaufforderungen. SGLang und LMDeploy sind robuste Optionen, die pro GPU-Stunde etwa 45 % mehr Wert liefern als Standardbereitstellungen und etwa 29 % mehr als hochoptimierte vLLM-Bereitstellungen.
Was man nicht verallgemeinern kann:
- Unterschiedliche Modelle: Ergebnisse spezifisch für Llama 3.1 8B. Größere Modelle (z. B. 70B) oder andere Architekturen (z. B. Mixtral, Qwen) weisen andere Skalierungsmuster auf.
- Unterschiedliche Hardware: Diese Rangliste gilt für H100 80GB. Auf A100 oder V100 kann die Portabilität von vLLM die Spezialisierung von SGLang ausgleichen.
- Unterschiedliche Metriken: Diese Messung erfasst lediglich den Durchsatz. Für die Online-Bereitstellung werden TTFT und Latenzperzentile benötigt, deren Ergebnisse sich deutlich unterscheiden.
- Unterschiedliche Arbeitslasten: Zufällige Eingabeaufforderungen minimieren die Vorteile des Präfix-Cachings. Wiederholte Systemeingabeaufforderungen oder mehrstufige Dialoge verschieben das Leistungsbild drastisch zugunsten von SGLang.
Vergleich der Entwicklererfahrung
Leistungszahlen geben das Gesamtbild der Bereitstellung nicht vollständig wieder. Jede Engine bietet unterschiedliche Entwickler-Workflows:
vLLM: Industriestandard aus gutem Grund
Einfachheit trifft auf umfassende Kompatibilität. Mit einem einzigen `pip install vllm` werden über 100 Modellarchitekturen für die Hardware-Serien NVIDIA, AMD und Intel unterstützt. Dank einer großen Community finden Sie auf Stack Overflow schnell die passenden Antworten. Ein API-Server, der mit OpenAI kompatibel ist, ist ebenfalls enthalten.
- vLLM eignet sich für: Schnelles Prototyping, heterogene GPU-Umgebungen, maximale Modellabdeckung oder die Nutzung des größten Ökosystems.
LMDeploy: Produktionsreife Lösung mit minimalem Aufwand
Die Installation mit nur einer Zeile Code (pip install lmdeploy) erreicht 99,5 % der maximalen H100-Leistung. Das native C++-Backend bedeutet keinerlei Python-Overhead. Erstklassige Quantisierungsunterstützung (AWQ, GPTQ) für weitere Optimierung. Keine Abhängigkeitsprobleme.
- Wählen Sie LMDeploy für Produktionsumgebungen, die maximale H100-Leistung erfordern , ohne Kompromisse bei Installationsfreundlichkeit oder Stabilität einzugehen.
SGLang: Leistungsgrenze bei Komplexitätskosten
Der maximale Durchsatz (16.215 tok/s) hat seinen Preis: erheblicher Aufwand beim Debuggen der FlashInfer-Installation. Eine bestimmte PyTorch-Version ist erforderlich. Es bestehen Binärinkompatibilitäten mit einigen vorkompilierten Wheels. RadixAttention eignet sich besonders für dialogbasierte Anwendungen.
- Wählen Sie SGLang für: Dedizierte Inferenzcluster, bei denen ein spezialisiertes Team die Abhängigkeiten verwalten kann und Sie jeden einzelnen Prozentpunkt Durchsatz benötigen.
Herausforderungen bei Installation und Bereitstellung
Für einen fairen Vergleich mussten erhebliche technische Hürden überwunden werden:
Herausforderung 1: Abhängigkeitskonflikte bei FlashInfer
Problem: Die FlashInfer-Wheels von SGLang erwarten bestimmte PyTorch-Versionen, aber die H100-optimierten Container liefern oft andere Versionen aus.
Auflösung:
Zeitaufwand: 6 Stunden für die Ermittlung kompatibler Versionen.
Fazit: Vorkompilierte ML-Wheels verbergen oft Versionsbeschränkungen, die erst zur Laufzeit sichtbar werden.
Herausforderung 2: FlashInfer in vLLM aktivieren
Problem: Standardversionen von vLLM bieten oft keine FlashInfer-Unterstützung oder erfordern eine aufwendige Quellcodekompilation.
Durchbruch: Wir nutzten den vLLM-Build 0.11.0 auf PyTorch 2.8 Nightly. Dadurch wurde die native FlashInfer-Unterstützung erfolgreich über `pip install "vllm[flashinfer]==0.11.0"` aktiviert, wodurch die Kompilierungsbarrieren älterer Versionen umgangen wurden.
Auswirkung: Dies ermöglichte einen möglichst fairen Vergleich und bestätigte, dass Kernel zwar hilfreich sind, aber den architektonischen Flaschenhals nicht lösen.
Herausforderung 3: Optimale Speichernutzung finden
Problem: Die Standardempfehlung von 0,9 GPU-Speicherauslastung verursachte std::bad_alloc Abstürze.
Testfortschritt:
Entdeckung: Die CUDA-Grapherfassung reserviert temporären System-RAM proportional zur Speichernutzung der GPU. Bei einer GPU-Speicherbelegung von 0,9 × 80 GB = 72 GB ist der System-RAM während der Kompilierung erschöpft.
Praktische Grenze: Eine GPU-Auslastung von 0,8 gilt trotz einer Hardwarekapazität von 80 GB als „sichere Zone“.
Abschluss
Für die Batch-Inferenz von Llama 3.1 8B auf H100 gibt es zwei klare Leistungsstufen : vLLM (optimiert mit FlashInfer) bietet eine solide Basis, während die C++-nativen Architekturen von SGLang und LMDeploy einen zusätzlichen Durchsatz von 29 % ermöglichen.
SGLang (16.215 kJ/s) und LMDeploy (16.132 kJ/s) erreichen einen nahezu identischen Durchsatz, was darauf hindeutet, dass beide Engines die Speicherbandbreite von H100 voll ausnutzen. Die minimale Differenz zwischen ihnen ist statistisches Rauschen.
Für Produktionseinsätze erweist sich LMDeploy als praktischer Gewinner, da es 99,5 % des Spitzendurchsatzes von SGLang mit trivialer Installation (pip install lmdeploy) im Vergleich zur komplexen Abhängigkeitsauflösung von SGLang liefert.
vLLM mit FlashInfer (12.553 Tok/s) bietet einen überzeugenden Kompromiss: respektable Leistung bei gleichzeitig voller Hardwarekompatibilität und der branchenweit größten Modellunterstützung. Für dedizierte H100-Cluster sind 29 % ungenutztes Leistungspotenzial jedoch ein hoher Preis.
Für die Standardisierung heterogener Infrastrukturen oder schnelle Modellversuche bleibt vLLM die optimale Wahl. Bei dedizierten H100-Implementierungen, bei denen der Durchsatz höchste Priorität hat, ist die Kombination aus Spitzenleistung und einfacher Installation von LMDeploy unübertroffen.
FAQs
Eine LLM-Inferenz-Engine ist eine spezialisierte Software, die die Generierung von Antworten durch große Sprachmodelle optimiert. Zwar lassen sich Modelle auch mit PyTorch oder TensorFlow ausführen, doch Inferenz-Engines bieten entscheidende Optimierungen wie effizientes Speichermanagement, die Zusammenfassung mehrerer Anfragen und GPU-Kernel-Optimierungen. Diese Verbesserungen können den Durchsatz (generierte Token pro Sekunde) drastisch erhöhen und die Kosten senken, wodurch potenziell eine 3- bis 5-fach höhere Leistung auf derselben Hardware erzielt wird.
Offline-Batch-Inferenz verarbeitet viele Anfragen gleichzeitig ohne Echtzeitanforderungen, beispielsweise die Analyse Tausender Dokumente oder die Generierung von Einbettungen für einen Datensatz. Online-Serving hingegen verarbeitet einzelne Nutzeranfragen mit strengen Latenzanforderungen, wobei Metriken wie die Time To First Token (TTFT) wichtiger sind als der reine Durchsatz. Die Engine mit dem höchsten Batch-Durchsatz ist möglicherweise nicht optimal für interaktive Chatbots. Wählen Sie daher die Engine basierend auf Ihrem tatsächlichen Arbeitslastmuster.
Seien Sie der Erste, der kommentiert
Ihre E-Mail-Adresse wird nicht veröffentlicht. Alle Felder sind erforderlich.