vLLM vs SGLang 2026: Beide auf H100s getestet — hier sind die Zahlen

vLLM vs SGLang: Den richtigen LLM-Inferenzserver im Jahr 2026 wählen

Hugging Face hat TGI im Dezember 2025 in den Wartungsmodus versetzt und empfiehlt Teams nun vLLM oder SGLang für neue Deployments. Wenn Sie heute einen Inferenz-Stack aufbauen, lautet die eigentliche Frage nicht "Soll ich TGI ablösen?" -- sondern welche dieser beiden Engines tatsächlich zu Ihrer Workload passt.

Kurzzusammenfassung

Wählen Sie vLLM, wenn Sie die breiteste Hardware-Unterstützung, die größte Community und einen bewährten Weg zur Produktion über AWS, GCP und Azure wünschen.

Wählen Sie SGLang, wenn Ihre Workload schwerpunktmäßig aus mehrstufigen Konversationen, strukturierten Ausgaben oder prefix-intensiven Pipelines wie RAG besteht -- und Sie mit einem kleineren Ökosystem zurechtkommen.

Nun schauen wir uns an, wo jede Engine tatsächlich die Nase vorn hat.

Wie sind wir hier angekommen? TGIs Abgang

Text Generation Inference (TGI) hat das Hugging Face-Ökosystem jahrelang getragen, aber seit Dezember 2025 werden nur noch Bugfixes akzeptiert -- keine neuen Features mehr. Hugging Faces eigene Inference Endpoints verwenden jetzt standardmäßig vLLM, mit SGLang als Alternative.

Das hinterlässt zwei echte Kandidaten für selbst gehostetes LLM-Serving. Beide sind Open-Source, beide sprechen die OpenAI-API, und beide laufen auf NVIDIA-GPUs. Die Unterschiede zeigen sich unter Last.

Fazit: Sowohl vLLM als auch SGLang sind produktionsreife TGI-Replacements. Wenn Sie migrieren, ist beides eine sichere Wahl -- der Rest dieses Leitfadens hilft Ihnen bei der Entscheidung.

Durchsatz- und Latenz-Benchmarks

Benchmarks variieren je nach Modell, GPU und Gleichzeitigkeit, daher hier Zahlen aus unabhängigen Tests auf derselben Hardware. Die folgenden Daten stammen aus Spherons H100-Benchmarks mit Llama 3.3 70B Instruct in FP8 und PremAIs Tests mit Llama 3.1 8B.

Llama 3.3 70B auf H100 (FP8)

Llama 3.1 8B auf H100

Bei kleineren Modellen vergrößert sich der Abstand. PremAI maß SGLang mit etwa 16.200 tok/s gegenüber vLLMs 12.500 tok/s -- ein 29%iger Durchsatzvorteil für SGLang. LMDeploy lag hier gleichauf mit SGLang, aber das ist ein separates Thema.

Was die Zahlen bedeuten

Bei 70B-Skala ist das Delta bescheiden (3-5%). Bei 8B-Skala ist es erheblich. Das Muster ergibt Sinn: SGLangs RadixAttention zahlt sich mehr aus, wenn der Prefill einen größeren Anteil der Gesamtkosten ausmacht, was bei kleineren Modellen und kürzeren Ausgaben geschieht.

Die Tail-Latenz erzählt eine ähnliche Geschichte. SGLangs TTFT p95 war auf jeder getesteten Gleichzeitigkeitsstufe durchgehend 5-8% niedriger als bei vLLM. Wenn Sie eine Echtzeit-Chat-Oberfläche bauen, bei der jede 50ms zählt, summiert sich dieser Abstand über Nutzer hinweg.

Fazit: SGLang gewinnt beim Rohdurchsatz, besonders bei kleineren Modellen. vLLM liegt bei 70B+-Skala nah dran. Für die meisten Produktionsworkloads ist der Unterschied einstellig -- bedeutsam bei großem Maßstab, aber für sich genommen kein Dealbreaker.

Prefix-Caching: RadixAttention vs. Automatisches Prefix-Caching

Beide Engines cachen KV-Berechnungen für wiederholte Präfixe, aber die Mechanismen unterscheiden sich auf eine Weise, die für bestimmte Workloads wichtig ist. Wenn Sie bereits mit Prompt-Caching auf API-Ebene vertraut sind, denken Sie daran als serverseitige Version davon.

vLLM verwendet Block-Level-Hashing. Es unterteilt den KV-Cache in Blöcke fester Größe, hasht sie und sucht bei neuen Anfragen nach Übereinstimmungen. Vorhersehbar, effizient und leicht nachvollziehbar -- aber Sie benötigen konsistente Blockgrenzen für Cache-Treffer.

SGLang verwendet einen Radix-Baum, der auf Token-Ebene indiziert ist. Er erkennt automatisch gemeinsame Präfixe über Anfragen hinweg ohne manuelle Konfiguration. Wenn 50 Nutzer Nachrichten im selben Konversations-Thread senden, findet und nutzt SGLang den gemeinsamen Präfix automatisch wieder.

Wo es wirklich einen Unterschied macht

RunPod benchmarkte mehrstufige Konversationen und stellte fest, dass SGLang unter hoher Gleichzeitigkeit konstant ~30-31 tok/s lieferte, während vLLM von 22 auf 16 tok/s abfiel, als der Cache-Druck zunahm. Das ist eine bedeutende Lücke für Chatbot- und Agent-Workloads.

Für Batch-Inferenz auf templatisierten Prompts -- bei denen jede Anfrage denselben System-Prompt verwendet -- funktioniert vLLMs Ansatz einwandfrei. Die Cache-Grenzen stimmen natürlich mit Ihrer Template-Struktur überein.

Fazit: SGLang gewinnt bei dynamischen, mehrstufigen Workloads. vLLM ist für Batch-Inferenz und templatisierte Prompts, bei denen Präfixe vorhersehbar sind, völlig ausreichend.

Strukturierte Ausgaben

Wenn Sie JSON-Schema-Durchsetzung oder eingeschränkte Generierung benötigen, ist dieser Abschnitt sehr wichtig. Beide Engines unterstützen strukturierte Ausgaben durch Grammar-Backends wie XGrammar und LLGuidance, aber die Performance-Geschichte ist sehr unterschiedlich.

SqueezeBits führte detaillierte Benchmarks durch und stellte fest, dass vLLM mit aktiviertem Guided Decoding eine erhebliche Durchsatzdegradierung zeigt, insbesondere bei Batch-Größen ab 8. SGLang hingegen überschneidet die Maskengenerierung mit dem GPU-Inferenzschritt und hält den Overhead minimal.

Repetitive vs. dynamische Schemas

Die Wahl des Backends spielt ebenfalls eine Rolle:

Ohne strukturierte Durchsetzung fällt die Ausgabe bei komplexen Schemas auf ~61% Korrektheit. Mit ihr steigt die Korrektheit um 20-25 Prozentpunkte. Das ist also für Produktions-Agent-Workflows nicht optional -- und die von Ihnen gewählte Engine bestimmt, wie viel Durchsatz Sie opfern.

Fazit: SGLang gewinnt bei strukturierten Ausgaben. Wenn Ihre Pipeline auf JSON-Schema-Durchsetzung angewiesen ist (und die meisten Agent-Workflows tun das), bedeutet SGLangs überlappter Ansatz, dass Sie keine Durchsatzsteuer zahlen.

Multi-LoRA und Fine-Tuned Model Serving

Beide Engines unterstützen das Serving mehrerer LoRA-Adapter von einem einzigen Basismodell, was unerlässlich ist, wenn Sie Modelle fein abstimmen für verschiedene Mandanten oder Aufgaben.

SGLang behandelt Multi-LoRA als erstklassiges Feature mit nativem Batching -- Anfragen, die auf verschiedene Adapter abzielen, können denselben Batch teilen. vLLM unterstützt es auch, aber SGLangs Implementierung war in letzten Releases etwas ausgefeilter.

Der praktische Unterschied? Wenn Sie 5-10 LoRA-Adapter von einem Llama-70B-Basismodell aus betreiben, funktionieren beide. Wenn Sie 50+ Adapter mit heterogenen Traffic-Mustern betreiben, handhabt SGLangs natives Batching das Scheduling eleganter.

Fazit: SGLang hat einen leichten Vorteil bei Multi-LoRA in großem Maßstab. Für eine Handvoll Adapter funktionieren beide Engines gleich gut.

Spekulatives Dekodieren

Beide Engines unterstützen spekulatives Dekodieren, das ein kleines "Draft"-Modell verwendet, um Token vorherzusagen, die das Hauptmodell dann parallel verifiziert. Das Ergebnis ist 2-3x schnellere Inferenz für speicherbegrenzte Szenarien.

vLLM hat kürzlich Unified Parallel Drafting eingeführt, und spekulatives Dekodieren funktioniert jetzt zusammen mit strukturierten Ausgaben. SGLangs Implementierung ist in der Fähigkeit ähnlich, mit leicht besserer Performance bei moderaten Gleichzeitigkeitsstufen.

Der eigentliche Unterschied ist nicht die Engine -- es ist die Frage, ob spekulatives Dekodieren zu Ihrer Workload passt. Es hilft am meisten bei langen Ausgaben von großen Modellen, bei denen der Engpass die Speicherbandbreite ist, nicht die Rechenleistung.

Fazit: Unentschieden. Beide Engines liefern vergleichbare Beschleunigungen durch spekulatives Dekodieren.

Hardware-Unterstützung und Deployment

Hier liegt vLLM deutlich vorn.

vLLM

• NVIDIA-GPUs (A100, H100, H200, B200)
• AMD-GPUs (MI250, MI300X)
• Intel-GPUs (über vllm-xpu-kernels)
• AWS Trainium und Inferentia
• Google TPUs
• Ausgereifte Kubernetes-Docs mit Helm-Charts, Startup-/Readiness-/Liveness-Probes
• NVIDIA Container Toolkit Integration out of the box

SGLang

• NVIDIA-GPUs (A100, H100, H200, B200)
• AMD-GPUs (MI300X, über ROCm)
• Docker-First-Deployment
• Kubernetes ist möglich, aber weniger dokumentiert

Wenn Sie auf etwas anderem als NVIDIA oder AMD deployen, ist vLLM Ihre einzige Option. Auf AWS speziell bedeutet die Trainium-Unterstützung, dass Sie Inferenzkosten erheblich senken können -- und SGLang kann diese Hardware nicht ansprechen.

Für Teams, die auf Standard-NVIDIA-GPUs laufen, ist die Deployment-Geschichte ähnlich. Beide bieten Docker-Images und OpenAI-kompatible Endpunkte. vLLM hat einfach mehr bewährte Produktionsleitfäden und Community-beigesteuerte Helm-Charts.

Wenn Sie Tools zum lokalen Ausführen von LLMs erkunden oder einen breiteren Überblick über self-hosted Inferenz möchten, unterstützen beide Engines auch lokales Deployment auf Consumer-GPUs -- obwohl sie für Datacenter-Hardware konzipiert sind.

Fazit: vLLM gewinnt bei Hardware-Breite und Deployment-Reife. SGLang ist in Ordnung, wenn Sie auf NVIDIA oder AMD sind. Überall sonst ist vLLM die einzige Wahl.

Disaggregiertes Serving

Beide Engines unterstützen die Trennung von Prefill (rechenintensiv) und Decode (speicherintensiv) in verschiedene Worker-Pools. Das ermöglicht es, jede Phase unabhängig zu skalieren -- mehr Prefill-Worker bei prompt-intensiven Bursts, mehr Decode-Worker für lange Generierung.

SGLang unterstützt Mooncake und NIXL als Transfer-Backends für die Disaggregierung und hat Ergebnisse veröffentlicht, die einen 2,7-fach höheren Decoding-Durchsatz auf NVIDIA GB200 NVL72-Clustern zeigen. vLLMs disaggregiertes Serving ist ebenfalls funktional, wenn auch weniger prominent dokumentiert.

Dieses Feature ist am wichtigsten bei sehr großem Maßstab (96+ GPUs). Wenn Sie eine Handvoll GPUs betreiben, benötigen Sie es wahrscheinlich noch nicht.

Fazit: SGLang hat einen leichten Vorsprung bei der Reife des disaggregierten Servings. Beide unterstützen es; SGLang hat mehr reale Ergebnisse veröffentlicht.

Wann welche verwenden: Entscheidungsframework

Die ehrliche Antwort für viele Teams: Testen Sie beide. Beide sind Open-Source, beide stellen dieselbe OpenAI-API bereit, und das Wechseln zwischen ihnen ist ein Container-Swap. Führen Sie Ihre tatsächliche Workload einen Tag lang gegen jede aus und vergleichen Sie die Metriken, die für Sie wichtig sind.

Wenn Sie Traffic über mehrere Inferenz-Backends routen, kann ein LLM-Gateway vor beiden Engines sitzen und Failover, Rate-Limiting und Observability übernehmen.

Wie Techsy die Auswahl des Inferenzservers angeht

Wenn wir Teams beim Deployment von LLM-basierten Features helfen, hängt die Wahl der Inferenz-Engine von drei Fragen ab:

1. Welche Hardware haben Sie? Wenn es Trainium oder TPUs sind, ist es vLLM. Alles andere, beide funktionieren.
2. Wie sieht Ihre Workload aus? Multi-Turn-Chat und Agent-Loops begünstigen SGLangs Prefix-Caching. Batch-Verarbeitung und einfache Completions funktionieren auf beiden gut.
3. Wie viel Ops-Kapazität haben Sie? vLLMs größere Community bedeutet mehr StackOverflow-Antworten und Helm-Charts, wenn nachts um 3 Uhr etwas kaputtgeht.

Wir haben Produktionsworkloads auf beiden betrieben. Sie sind wirklich nah beieinander. Die richtige Antwort hängt von Ihren Einschränkungen ab, nicht davon, dass eine abstrakt "besser" ist.

Benötigen Sie Hilfe bei der Auswahl oder dem Deployment eines Inferenzservers? Kontaktieren Sie uns -- wir bewerten Ihre Workload und empfehlen den richtigen Stack.

Ein Tool auszuwählen ist der einfache Teil. Es zuverlässig in einem echten Produkt zum Laufen zu bringen, daran scheitern die meisten Teams, und genau das baut unser KI-Integrationsteam für Kunden, von RAG-Pipelines bis zu individuellen Agenten.

Häufig gestellte Fragen

Ist SGLang schneller als vLLM?

Bei kleineren Modellen (7B-8B) zeigt SGLang auf H100-GPUs einen etwa 29% höheren Durchsatz. Bei Modellen mit 70B+ verengt sich der Abstand auf 3-5%. SGLang hat auch bei allen getesteten Gleichzeitigkeitsstufen eine niedrigere Tail-Latenz (TTFT p95).

Kann ich vLLM und SGLang mit dem OpenAI-API-Format verwenden?

Ja. Beide stellen OpenAI-kompatible Endpunkte out of the box bereit. Sie können eines gegen das andere austauschen, ohne Ihren Client-Code zu ändern. Ihre /v1/chat/completions-Aufrufe funktionieren auf beiden identisch.

Warum hat Hugging Face TGI eingestellt?

TGI trat im Dezember 2025 in den Wartungsmodus. Hugging Face entschied sich, zu vLLM und SGLang beizutragen, anstatt eine separate Inferenz-Engine zu pflegen. TGI funktioniert noch für bestehende Deployments, aber es kommen keine neuen Features mehr.

Unterstützt SGLang NVIDIA- und AMD-GPUs?

SGLang unterstützt NVIDIA-GPUs (A100, H100, H200, B200) und AMD-GPUs (MI300X über ROCm). Es unterstützt keine Intel-GPUs, AWS Trainium, Inferentia oder Google TPUs. vLLM hat eine breitere Hardware-Abdeckung.

Was ist RadixAttention und warum ist es wichtig?

RadixAttention ist SGLangs Prefix-Caching-Mechanismus. Er speichert KV-Cache-Einträge in einem Radix-Baum, der auf Token-Ebene indiziert ist, und erkennt automatisch gemeinsame Präfixe über Anfragen hinweg. Das macht mehrstufige Konversationen und RAG-Pipelines deutlich schneller, weil wiederholter Kontext nicht neu berechnet werden muss.

Welche Engine ist besser für strukturierte JSON-Ausgaben?

SGLang. Es überschneidet die Grammar-Maskengenerierung mit der GPU-Inferenz, sodass die Durchsetzung strukturierter Ausgaben den Durchsatz kaum beeinträchtigt. vLLM zeigt merkliche Degradierung bei Batch-Größen ab 8, wenn Guided Decoding aktiviert ist.

Kann ich mehrere LoRA-Adapter von einem Basismodell aus betreiben?

Beide Engines unterstützen Multi-LoRA-Serving. SGLang behandelt es als natives Feature mit Batching über verschiedene Adapter im selben Request-Batch. vLLM unterstützt es ebenfalls, aber SGLangs Scheduling ist bei hohen Adapter-Zahlen effizienter.

Was ist disaggregiertes Prefill/Decode-Serving?

Es bedeutet, die Prefill-Phase (Verarbeitung des Prompts) auf separaten GPU-Workern von der Decode-Phase (Generierung von Token) auszuführen. Prefill ist rechengebunden; Decode ist speichergebunden. Die Trennung ermöglicht es, jede Phase unabhängig zu skalieren. Beide Engines unterstützen dies, wobei SGLang mehr veröffentlichte Produktionsergebnisse hat.

Wie migriere ich von TGI zu vLLM oder SGLang?

Da alle drei OpenAI-kompatible APIs bereitstellen, ist die Migration größtenteils ein Container-Swap. Verweisen Sie Ihr Docker Compose oder Kubernetes-Deployment auf das neue Image, passen Sie die Modell-Ladeflags an und aktualisieren Sie die Health-Check-Endpunkte. Der Client-Code bleibt gleich.

Sollte ich vLLM oder SGLang für eine RAG-Pipeline verwenden?

SGLang ist die stärkere Wahl für RAG. Seine RadixAttention cached und nutzt automatisch die langen System-Prompts und Dokumentkontexte wieder, die RAG-Pipelines wiederholt senden. vLLMs Block-Level-Caching funktioniert auch, aber Sie werden mit SGLangs Token-Level-Ansatz bessere Cache-Trefferquoten sehen, wenn Dokumentchunks leicht über Anfragen variieren.

Abschließendes Fazit

SGLang gewinnt mehr Kategorien, aber vLLMs Vorteile -- Hardware-Breite und Ökosystem-Reife -- sind die Art von Dingen, die nachts um 3 Uhr wichtig sind, wenn ein Node ausfällt.

Wenn Sie auf NVIDIA-Hardware sind und Ihre Workload mehrstufige Konversationen, Agents mit strukturierten Ausgaben oder RAG-Pipelines mit gemeinsamen Präfixen umfasst, beginnen Sie mit SGLang. Sie erhalten besseren Durchsatz und niedrigere Latenz, wo es drauf ankommt.

Wenn Sie Multi-Cloud-Flexibilität, Unterstützung für Nicht-NVIDIA-Hardware oder den Komfort der größten Open-Source-LLM-Serving-Community benötigen, beginnen Sie mit vLLM. Es ist der sicherere Standard, der den meisten Teams gut dienen wird.

So oder so sind beide Engines ausgezeichnet und verbessern sich schnell. Wählen Sie eine, deployen Sie sie, messen Sie Ihre tatsächliche Workload und wechseln Sie, wenn die Zahlen es Ihnen sagen. Die OpenAI-kompatible API macht diesen Wechsel schmerzlos.

Quellen

• Spheron H100 Benchmarks: vLLM vs TensorRT-LLM vs SGLang
• PremAI: vLLM vs SGLang vs LMDeploy Benchmarks
• SqueezeBits: Guided Decoding Performance auf vLLM und SGLang
• RunPod: SGLang vs vLLM KV Cache Reuse
• SGLang Offizielle Dokumentation
• vLLM Offizielle Dokumentation