Sie entscheiden gerade, mit welcher Engine Sie Sprachmodelle im Unternehmen betreiben? Im LLM-Hosting läuft vLLM mit OpenAI-kompatibler API und Betrieb durch WZ-IT. Wer eine dedizierte GPU braucht, nutzt den Managed GPU Server ab 699 € netto im Monat. LLM-Hosting ansehen · Auslegung gemeinsam klären
Die Frage "SGLang oder vLLM" wird meist mit einem Faktor beantwortet: x-mal schneller, y Prozent weniger GPU-Kosten. Solche Zahlen gelten für ein Modell, eine Version, eine GPU und ein Lastprofil, und veröffentlichte Tests kommen zu entgegengesetzten Ergebnissen. Dieser Beitrag vergleicht deshalb, was beide Projekte dokumentieren, und gibt eine Entscheidungstabelle und einen Messplan für die eigene Last. Die Angaben stammen aus den Projektdokumentationen, den Repositories und der GitHub-API, die Benchmark-Angaben aus den genannten Quellseiten, Stand 28. Oktober 2026. Eigene Benchmarks enthält der Beitrag nicht.
Inhaltsverzeichnis
- Kurzantwort
- Architektur: zwei Datenstrukturen für denselben Zweck
- Funktionen und Hardware laut Dokumentation
- Reife und Release-Takt
- Benchmarks: Quellen und ihre Bedingungen
- Eigenen Vergleich messen
- Entscheidungstabelle
- Betrieb und Wechsel
- Stand und Methodik
- Unser Vorgehen bei WZ-IT
- Weiterführende Guides
Kurzantwort
Beide Engines sind Apache-2.0-lizenziert, laufen auf NVIDIA- und AMD-Hardware, sprechen die OpenAI-API und decken die gängigen Funktionen ab. Der Unterschied liegt weniger in der Funktionsliste als im Verhalten bei Last mit wiederkehrenden Präfixen und im Reifegrad je Modell und Plattform.
- Ohne nennenswerten Präfixanteil (einzelne Dokumente, Klassifikation, Batch) zeigen zwei veröffentlichte Tests Gleichstand, ein dritter sieht vLLM bei Durchsatz und erstem Token vorn. Die Wahl folgt dann Modellunterstützung und Betrieb.
- Mit hohem Präfixanteil (Agenten mit langen Werkzeugbeschreibungen, lange Systemprompts, Mehrschritt-Gespräche) berichten zwei Anbietertests Vorteile für SGLang, ein dritter mit anderer Last sieht vLLM vorn. Hier lohnt der eigene Vergleich.
- Pauschale Faktoren aus Blogartikeln sind nicht übertragbar, siehe die Tabelle der Testbedingungen unten.
Architektur: zwei Datenstrukturen für denselben Zweck
vLLM verwaltet den KV-Cache in Blöcken (PagedAttention, Paper) und bündelt Anfragen per Continuous Batching. Das Prefix Caching (APC) bildet für jeden vollen Block einen Hash aus dem Hash des Vorgängers, den Tokens des Blocks und Zusatzwerten wie LoRA-ID oder Cache-Salt für Mandantentrennung; nur volle Blöcke werden gecacht (vLLM, Design). Im Quellcode ist das Verfahren standardmäßig aktiv, sofern das Modell es unterstützt (arg_utils.py).
SGLang legt den KV-Cache in einem Radix-Baum ab (RadixAttention, Paper). Der Baum ist standardmäßig aktiv (--disable-radix-cache steht auf False); für einzelne Modelle und Betriebsarten schaltet SGLang ihn selbst ab, etwa auf Decode-Servern der Prefill/Decode-Trennung. Bei Speicherdruck wählt eine Richtlinie die zu verdrängenden Präfixe: lru als Standard, dazu lfu, slru, priority und tlru, letztere für Agenten und Mehrschritt-Gespräche mit Zielwert für die Zeit bis zum ersten Token (SGLang, Eviction). HiCache ergänzt zwei weitere Ebenen für den KV-Cache: CPU-Speicher und externen Speicher.
Für einen identischen Systemprompt verhalten sich beide gleich: Der gemeinsame Teil wird nicht neu berechnet. Wie sich Hash über Blöcke und Radix-Baum bei teilweise überlappenden Prompts unterscheiden, hängt von Blockgröße und Lastprofil ab; keine Dokumentation beziffert das. Beide Verfahren verkürzen nur den Prefill. vLLM schreibt selbst, dass Prefix Caching bei langen Antworten keinen Gewinn bringt, weil dort die Erzeugung dominiert (vLLM, APC).
Funktionen und Hardware laut Dokumentation
| Merkmal | vLLM | SGLang |
|---|---|---|
| Lizenz | Apache-2.0 | Apache-2.0 |
| Träger | auf pytorch.org als Projekt der PyTorch Foundation geführt | von LMSYS (gemeinnützig) gehostet |
| Ausrichtung laut README | "Easy, fast, and cheap LLM serving for everyone" | optimiert für agentische Workloads, Serving im großen Maßstab und RL-Rollouts |
| Hardware | NVIDIA, AMD, Intel, CPUs (x86, ARM, PowerPC, IBM Z experimentell); per Plugin u. a. TPU, Gaudi, Ascend, Apple Silicon | NVIDIA (u. a. RTX PRO 6000, DGX Spark), AMD Instinct, TPU v6e/v7, Intel, Apple Silicon, Ascend |
| Spekulatives Decoding | EAGLE, MTP, Draft-Modell, PARD, N-Gram, Suffix, DFlash | EAGLE-2/3, MTP, Draft-Modell, NGRAM, DFlash, UNO |
| Strukturierte Ausgabe | xgrammar, guidance | xgrammar (Standard), Outlines, llguidance |
| Tool Calling | Parser je Modell (--tool-call-parser) |
Parser u. a. für DeepSeek, Llama, Qwen, Mistral, GLM, Kimi K2 |
| Multi-LoRA | dense und MoE | mehrere Adapter je Batch (S-LoRA, Punica) |
| Quantisierung | FP8, MXFP8/MXFP4, NVFP4, INT8, INT4, GPTQ, AWQ, GGUF u. a. | FP8, MXFP4, AWQ, GPTQ, ModelOpt (FP8/FP4) u. a. |
| Prefill/Decode getrennt | dokumentiert, als experimentell gekennzeichnet | PD Disaggregation mit Mooncake und NIXL |
| Expert Parallelism | --enable-expert-parallel, DeepEP-Backends, Lastausgleich EPLB (--enable-eplb) |
--moe-a2a-backend (DeepEP, Mooncake, NIXL), Lastausgleich EPLB |
| API | OpenAI-kompatibel, Anthropic Messages, gRPC | OpenAI-kompatibel, Anthropic- und Ollama-kompatibel |
| Metriken | Prometheus /metrics, Präfix vllm:, Prefix-Cache-Treffer |
Prometheus mit --enable-metrics, Präfix sglang:, cache_hit_rate |
| Container | vllm/vllm-openai |
lmsysorg/sglang (CUDA-Images nur noch mit CUDA 13) |
Quellen vLLM: README, Features, Installation, Metriken, PyTorch Foundation. Quellen SGLang: README, Dokumentation, Spekulatives Decoding, PD-Trennung, Expert Parallelism, Metriken.
Die Tabelle belegt, dass etwas dokumentiert ist, nicht dass es für ein bestimmtes Modell auf einer bestimmten GPU reibungslos läuft. Das zeigt erst der Test mit dem Zielmodell.
Reife und Release-Takt
| vLLM | SGLang | |
|---|---|---|
| Aktuelle Version | v0.32.0, 18. Oktober 2026 | v0.5.22, 19. Oktober 2026 |
| Vorherige Versionen | v0.31.0 (5. Okt.), v0.30.0 (22. Sep.), v0.29.0 (9. Sep.), v0.28.0 (26. Aug.) | v0.5.21 (2. Okt.), v0.5.20 (18. Sep.), v0.5.19 (5. Sep.), v0.5.18 (22. Aug.) |
| Abstand | 13 bis 14 Tage | 13 bis 17 Tage |
Beide Projekte veröffentlichen etwa alle zwei Wochen und tragen eine Versionsnummer unter 1.0. Das bedeutet in der Praxis: Versionen festhalten, Release Notes lesen, Updates testen. Beispiele für Brüche aus den Dokumentationen: SGLang veröffentlicht seit v0.5.20 keine CUDA-12-Images mehr (letzter Tag v0.5.19-cu129, Installation); vLLM entfernte in v0.12.0 die Anfragefelder guided_* zugunsten von structured_outputs (vLLM, Structured Outputs). GitHub-Sterne sind hier bewusst kein Kriterium: Sie messen Bekanntheit, nicht Eignung.
Benchmarks: Quellen und ihre Bedingungen
| Quelle | Wer misst | Bedingungen laut Quelle | Ergebnis (qualitativ) | Grenze |
|---|---|---|---|---|
| SGLang-Paper, Dezember 2023 | SGLang-Autoren | Vergleich mit damaligen Systemen (u. a. vLLM v0.2.5), meist A10G-GPUs, Aufgaben wie Agentensteuerung, JSON-Decoding, RAG, Multi-Turn-Chat | bis zu 6,4-facher Durchsatz | Stand 2023; vLLM hat seitdem Prefix Caching |
| Spheron, Update 19. Oktober 2026 | GPU-Cloud-Anbieter | 1x H100, Llama 3.3 70B in FP8, vLLM v0.18.0 und SGLang v0.5.9; Läufe mit eindeutigen Prompts und mit 80 % gemeinsamem Präfix | Gleichstand ohne Präfix, SGLang bei gemeinsamem Präfix mit kürzerer Zeit bis zum ersten Token | Versionen weit unter dem heutigen Stand |
| RunPod, Update 13. September 2026 | GPU-Cloud-Anbieter | 2x H100, DeepSeek-R1-Distill-Llama-70B, Mehrschritt-Prompt mit rund 7.000 Token Kontext | SGLang bei Cache-Treffern vorn; bei einer Einzelanfrage ohne Kontext vLLM schneller | Einzelanfragen, keine Last |
| Jarvislabs, 18. Mai 2026 | GPU-Cloud-Anbieter | H100, Qwen2.5-7B, Qwen3-30B-A3B, Qwen3-32B; ShareGPT und RULER 16K | vLLM als stärkster Standard; SGLang mit niedrigerer Decode-Latenz in einigen Läufen, aber späterem ersten Token | Versionen nicht angegeben |
| Red Hat Developers, 14. Oktober 2026 | Fachartikel, berichtet die Messung von Modal | Modal: mehr als ein Dutzend Modelle, zehn Kombinationen aus Eingabe- und Ausgabelänge, NVIDIA-GPUs, Standardeinstellungen, Prompts aus zufälligen Romanabschnitten | beide vergleichbar | kaum gemeinsame Präfixe; der Artikel nennt das selbst als Grenze |
| InferenceX (SemiAnalysis), fortlaufend | Analysefirma, Apache-2.0-Repository | Läufe über öffentliche GitHub-Actions-Workflows, Rezepte im Repository, viele Modelle und GPUs | keine Einzelzahl in diesem Beitrag | Hardware laut Danksagung von AMD, NVIDIA und Cloud-Anbietern gestellt |
Die Abweichungen erklären sich aus den Bedingungen: Versionen unterscheiden sich um mehr als zehn Releases, Modelle und Quantisierung wechseln, und die Messgröße ist mal Durchsatz in Token pro Sekunde, mal Zeit bis zum ersten Token, mal Latenz pro Ausgabetoken. Ein Test mit hohem Präfixanteil und einer mit zufälligen Prompts messen verschiedene Dinge. Zahlen aus diesen Quellen gehören deshalb nicht in eine Hardware-Entscheidung, die Richtung schon: Der Präfixanteil ist die Größe, die den Ausschlag gibt.
Eigenen Vergleich messen
- Lastprofil aus eigenen Logs ableiten: Länge von Eingabe und Ausgabe, Anteil gemeinsamer Präfixe (Systemprompt, Werkzeuge, Gesprächsverlauf), gleichzeitige Anfragen zur Spitzenzeit. Die Zahl der gleichzeitigen Nutzer ist meist kleiner als die der Zugangsberechtigten.
- Gleiche Bedingungen herstellen: dieselbe GPU, dasselbe Modell, dieselbe Quantisierung, Container-Tags festhalten, beide Versionen notieren, Startparameter aus den Rezepten der Projekte.
- Ein Messclient für beide Endpunkte: vLLM empfiehlt für Produktivserver GuideLLM (vLLM, Benchmark CLI);
python -m sglang.bench_servingunterstützt einvllm-Backend (SGLang, Bench Serving). - Parallelitätsstufen statt Einzelwert: eine Anfrage, Zielwert und das Doppelte, je Stufe mehrere Läufe nach der Aufwärmphase; kalten und warmen Cache getrennt ausweisen.
- Metriken zusammen lesen: Zeit bis zum ersten Token (p50 und p95), Latenz pro Ausgabetoken, Durchsatz unter einer festen Latenzgrenze und die Cache-Trefferquote aus
/metrics. - Qualität stichprobenartig prüfen: gleiche Prompts, Ausgaben und Tool-Aufrufe vergleichen.
- Betrieb mitbewerten: Startzeit, Speicherbedarf, Verhalten bei Überlast, Updatepfad.
Entscheidungstabelle
| Last | Erster Kandidat | Begründung | Zu messen |
|---|---|---|---|
| Chat-Assistent mit gemeinsamem Systemprompt auf einem GPU-Server, 5 bis 50 gleichzeitige Nutzer | vLLM; SGLang gegentesten bei hohem Präfixanteil | Beide cachen den gemeinsamen Prompt; der Unterschied zeigt sich bei verzweigten Verläufen | Zeit bis zum ersten Token (p95), Trefferquote |
| Agenten mit langen Werkzeugbeschreibungen, viele Schritte | SGLang testen, vLLM als Referenz | SGLang nennt agentische Workloads als Ziel und bietet tlru für Mehrschritt-Gespräche |
Latenz je Schritt, Dauer bis zur fertigen Aufgabe |
| Batch mit unterschiedlichen Prompts (Klassifikation, Extraktion) | vLLM | Der Präfixvorteil entfällt; zwei Tests zeigen Gleichstand, einer vLLM vorn | Anfragen pro Sekunde unter Latenzgrenze |
| Große MoE-Modelle über mehrere GPUs oder Knoten | beide gleichrangig prüfen | Beide dokumentieren Expert Parallelism und die Trennung von Prefill und Decode; das Rezept zum Modell entscheidet | Rezept des Projekts, Netzwerk (RDMA) |
| JSON-Schema-Ausgabe mit hoher Wiederholung | beide | beide unterstützen xgrammar | Dauer mit und ohne Schema |
| AMD, TPU oder Apple Silicon | Hardware-Seiten beider Projekte prüfen | Unterstützung ist je Modell und Version verschieden | Modell läuft stabil |
Betrieb und Wechsel
Beide Engines liefern eine OpenAI-kompatible API; ein Wechsel ändert für Clients meist nur Basis-URL und Modellnamen. Zu prüfen sind Tool-Call-Parser, Chat-Template, Reasoning-Parser und strukturierte Ausgabe je Modell. Ein Gateway wie LiteLLM kann beide hinter einer Adresse betreiben, etwa für einen A/B-Test mit echtem Verkehr. Für den Betrieb gelten Metriken (vllm:- und sglang:-Präfix), festgehaltene Image-Tags und ein Updatefenster pro Release. Die GPU-Auslegung ist von der Engine-Wahl getrennt: GPU und VRAM für LLMs und Multi-GPU-Inferenz behandeln sie.
Stand und Methodik
Abgerufen am 28. Oktober 2026: Versionen, Veröffentlichungsdaten und Lizenzen über die GitHub-API und die LICENSE-Dateien (beide Apache License 2.0); Funktionen und Hardware aus README und Dokumentation beider Projekte (Quelltexte der Dokumentationsrepositories); Standardverhalten des Prefix Caching aus vllm/engine/arg_utils.py und der SGLang-Serverargument-Referenz. Benchmark-Quellen sind mit Datum und den von ihnen genannten Bedingungen aufgeführt; Zahlen daraus werden nicht übernommen. Nicht geprüft wurde, ob jede aufgeführte Funktion mit jedem Modell zusammenarbeitet. Die Tabellen werden bei neuen Releases aktualisiert.
Unser Vorgehen bei WZ-IT
Im LLM-Hosting, auf dem Managed GPU Server und im AI Cube läuft vLLM, bei Teams mit mehreren gleichzeitigen Nutzern gemeinsam mit Open WebUI. Die Auslegung beginnt beim Lastprofil, also bei gleichzeitigen Nutzern, Kontextlängen und Präfixanteil, danach folgen Modell und Hardware. Den Unterschied zu Ollama behandelt vLLM vs. Ollama.
Weiterführende Guides
- Was ist vLLM? - Grundlagen der Engine
- vLLM vs. Ollama - Einstieg gegen Durchsatz
- vLLM, Ollama oder llama.cpp - Vergleich mit Abschnitt zu SGLang
- Multi-GPU-Inferenz ohne NVLink - Tensor-, Pipeline- und Datenparallelität
- GPU und VRAM für LLMs dimensionieren - KV-Cache und Kontextlänge
- LLM-Hosting, Managed GPU Server und vLLM-Expertise
Welche Engine zu Ihrer Last passt, zeigt eine Messung mit Ihrem Modell. Wir legen Hardware und Modell nach Ihrem Lastprofil aus; als Modellserver läuft vLLM. LLM-Hosting ansehen · Termin vereinbaren
