- vLLM ist die sicherere Standardwahl– breiteste Modell- und Hardwareunterstützung, größtes Ökosystem, geringster Aufwand beim Deployment.
- Wählen Sie SGLang wenn Ihr Datenverkehr stark wiederverwendete Prompt-Präfixe aufweist (Agenten, Mehr-Runden-Chats, umfangreiche System-Prompts) oder viel strukturierte JSON-Ausgabe erzeugt – hier überzeugen RadixAttention und Jump-Forward-Decoding.
- Die Leistungslücke hängt von der Workload ab und schrumpft mit jeder neuen Version. Beide unterstützen die OpenAI-API, sodass ein Vergleich anhand Ihres echten Datenverkehrs kostengünstig ist.
- Keines der beiden läuft nativ unter Windows oder macOS – verwenden Sie stattdessen Linux (oder WSL2) oder ein Desktop-Tool wie Ollama/LM Studio für den lokalen Einsatz.
vLLM und SGLang sind die beiden führenden Open-Source-Engines zum Hosting großer Sprachmodelle auf eigenen GPUs; für die meisten Teams gilt vLLM ist die sicherere Standardwahl: mehr Modelle, mehr Hardware-Backends, ein größeres Ökosystem. Wählen Sie SGLang wenn Ihr Datenverkehr überwiegend aus gemeinsam genutzten Prompt-Präfixen besteht – etwa bei Agenten, Mehr-Runden-Chats oder umfangreichen System-Prompts – oder wenn strukturierte JSON-Ausgaben dominieren, wo dessen RadixAttention-Cache und grammatikbasierte Decodierung echte Vorteile bieten. Beide stellen eine OpenAI-kompatible API bereit, sodass ein späterer Wechsel nahezu kostenfrei ist.
Dieser Leitfaden vergleicht beide Engines so, wie Sie sie tatsächlich wählen würden: worauf sich jedes Projekt spezialisiert hat, wie sich RadixAttention und PagedAttention in der Praxis unterscheiden, wo jeweils Durchsatz und Latenz Vorteile bieten, sowie klare Empfehlungen je nach Workload.
Auf was sich jedes Projekt spezialisiert
vLLM wurde 2023 an der UC Berkeley als Referenzimplementierung des PagedAttention-Papiers gestartet und ist mittlerweile zur de-facto-Standard-Open-Source-Hosting-Engine geworden; heute ist vLLM ein Projekt der PyTorch Foundation. Seine Prioritäten sind Breite und Robustheit: Fast jedes Open-Weight-Modell lässt sich auf nahezu jeder Beschleunigerhardware ausführen – NVIDIA CUDA, AMD ROCm, Intel, Google TPU, AWS Neuron und sogar x86-CPU – mit starkem Durchsatz „out of the box“. Neue Modellfamilien erhalten üblicherweise bereits am Tag ihrer Veröffentlichung Unterstützung durch vLLM.
SGLang stammt vom LMSYS-Team hinter Chatbot Arena. Es optimiert zwei konkrete Aspekte: Wiederverwendung des KV-Caches (RadixAttention) und schnelle strukturierte Generierung. Der Name ist eine Abkürzung für Structured Generation Language – ursprünglich wurde sie mit einer Python-DSL zum Verketten und Verzweigen von LLM-Aufrufen ausgeliefert – doch die Laufzeitumgebung für das Serving ist heute das, was die meisten Nutzer einsetzen. Sie verfügt über ernstzunehmende Produktionsqualifikationen: Sie gehörte zu den empfohlenen Engines bei der V3-Lancierung und ist bekannt für aggressive Multi-GPU-Optimierungen (Aufteilung von Prefill und Decode, großskaliges Expert-Parallelismus-Verfahren für MoE-Modelle). DeepSeek Die beiden zentralen Techniken lösen unterschiedliche Probleme, und ihre Namen suggerieren fälschlicherweise eine entweder-oder-Entscheidung.
RadixAttention versus PagedAttention – einfach erklärt
PagedAttention (vLLM) ist ein Speichermanagement.
Sie speichert den KV-Cache in Blöcken fester Größe – ähnlich wie ein Betriebssystem virtuellen Arbeitsspeicher in Seiten einteilt – statt pro Anfrage einen großen zusammenhängenden Speicherbereich vorzubehalten. Dadurch wird Fragmentierung nahezu vollständig vermieden, sodass deutlich mehr parallele Sequenzen im selben VRAM Platz finden; größere Batches bedeuten höhere Durchsatzraten. Es geht also darum, mehr in den Speicher zu bekommen RadixAttention (SGLang) ist Speicherwiederverwendung..
Sie organisiert den KV-Cache als Radixbaum, dessen Schlüssel Token-Sequenzen sind. Sobald eine neue Anfrage eingeht, durchläuft die Engine den Baum, findet das längste übereinstimmende Präfix und überspringt dessen erneute Berechnung. System-Prompts, Few-Shot-Beispiele, Gesprächsverläufe sowie Agent-„Scratchpads“, die sich über mehrere Anfragen hinweg wiederholen, werden einmal im Prefill berechnet und anschließend wiederverwendet. Es geht also darum, weniger zu berechnen Im Jahr 2026 haben sich beide Engines stärker angenähert, als es die Markennamen vermuten lassen: vLLM bietet mittlerweile automatisches Prefix-Caching (in neueren Versionen standardmäßig aktiviert), und SGLang nutzt ebenfalls ein Paging-Verfahren für seinen Speicher. Der verbleibende praktische Unterschied besteht darin, dass SGLang von Anfang an auf Wiederverwendung ausgelegt war – sein Scheduler ist cache-bewusst und ordnet sowie leitet Anfragen so weiter, dass die Trefferquote maximiert wird. Die Faustregel lautet:.
Je größer der Anteil Ihres typischen Prompts ist, der sich über Anfragen hinweg wiederholt, desto stärker zahlt sich SGLangs Design aus. In jedem Fall konkurriert der KV-Cache mit den Modellgewichten um denselben GPU-Speicher, und Spielraum für Parallelität ist das, was eine Serving-Engine Ihnen tatsächlich bietet. Nutzen Sie den.
zur Abschätzung, wie viel Speicher ein bestimmtes Modell inklusive Kontext für den Cache freilässt, bevor Sie die Hardware dimensionieren. VRAM-Rechner Typischerweise schneller
Durchsatz und Latenz: Wo jeweils Vorteile liegen
| Workload | Mehrstufige Chat-Interaktionen, Agent-Schleifen, große gemeinsame System-Prompts | Warum |
|---|---|---|
| RadixAttention überspringt die erneute Prefill-Berechnung wiederholter Präfixe, verkürzt so die Zeit bis zum ersten Token und entlastet die Rechenkapazität | SGLang | Einmalige Prompts mit geringer Überschneidung (einzigartige Dokumente, Batch-Zusammenfassungen) |
| Großteils vergleichbar | Beide nutzen kontinuierliches Batching und chunked Prefill; Cache-Wiederverwendung tritt selten in Kraft | Hochvolumige JSON-/eingeschränkte Ausgaben |
| Jump-forward decoding generiert grammatikgezwungene Tokens ohne Vorwärtspass durch das Modell | SGLang | Gemischter Modell-Zoo, exotische Quantisierungen, Nicht-NVIDIA-Hardware |
| Eine breitere Abdeckung von Backends und Formaten bedeutet weniger nicht optimierte Fallback-Pfade | vLLM | Behandeln Sie alle spezifischen Durchsatzangaben, die Sie online finden, als versionsgebunden. Beide Projekte liefern kontinuierlich Optimierungen aus und haben jeweils Benchmarks veröffentlicht, in denen sie den anderen schlagen. Die ehrliche Antwort lautet: Bei cache-freundlichem Datenverkehr liegt SGLang meist vorn, bei kaltem Cache liegen beide eng beieinander – und das einzige aussagekräftige Benchmark ist Ihr eigener: Beide stellen Tools zum Lasttest bereit (vLLMs |
vllm bench serve , SGLangspython -m sglang.bench_serving ), mit denen realistische Anfrageströme wiedergegeben werden können.Beide Engines können die Ausgabe zwingend an ein JSON-Schema, einen regulären Ausdruck oder eine Grammatik anpassen – dies erfolgt über den OpenAI-kompatiblen Parameter
Strukturierte und eingeschränkte Ausgabe
response_format sowie engine-spezifische Erweiterungen. SGLang hat hier den beschleunigten Pfad pioneering eingeführt: Sie kompiliert Einschränkungen in eine komprimierte endliche Zustandsmaschine und nutzt
jump-forward decoding – wenn die Grammatik die nächsten mehreren Tokens deterministisch festlegt (geschweifte Klammern, Anführungszeichen, feste Schlüsselnamen), werden diese direkt angehängt, anstatt für jeden einzelnen Token einen Vorwärtspass durch das Modell auszuführen. Für Extraktionspipelines, die tokenreiche JSON-Daten erzeugen, stellt dies eine spürbare Beschleunigung dar. vLLM unterstützt dieselbe Klasse von Einschränkungen über austauschbare Grammatik-Backends (xgrammar, guidance, outlines); seit beide Projekte xgrammar als Standardbackend übernommen haben, hat sich die Lücke deutlich verkleinert. Fazit: Beide sind produktionsreif; SGLang behält jedoch einen Vorteil bei stark strukturierten, hochvolumigen Workloads.
UC Berkeley; PyTorch Foundation-Projekt
Ökosystem, Hardware-Unterstützung und Deployment-Aufwand
| vLLM | SGLang | |
|---|---|---|
| Herkunft | LMSYS (Chatbot Arena-Team) | NVIDIA, AMD ROCm, Intel, Google TPU, AWS Neuron, x86-CPU |
| Hardware | NVIDIA erstklassig unterstützt, AMD ROCm ebenfalls unterstützt; andere Plattformen weniger ausgereift | Modellabdeckung |
| Breiteste aller Engines, inklusive vieler multimodaler und spezieller Architekturen | Alle wichtigen Modellfamilien (Llama, Qwen, DeepSeek, Mistral, GPT-OSS …), kürzere lange Schwanz-Liste | FP8, AWQ, GPTQ, INT8, bitsandbytes u. a. |
| Quantisierung | FP8, AWQ, GPTQ; kürzere Liste | OpenAI-kompatibel, Standardport 8000 |
| API | OpenAI-kompatibel, Standardport 30000 | Docker-Image |
| vllm/vllm-openai | lmsysorg/sglang | Der Einstieg ist auf einem CUDA-fähigen Linux-System mit jeweils einer Zeile möglich: |
— stellt eine OpenAI-kompatible API am Port 8000 bereit.
pip install vllm dann vllm serve Qwen/Qwen2.5-7B-Instruct pip install "sglang[all]"
python -m sglang.launch_server --model-path Qwen/Qwen2.5-7B-Instruct dann — dieselbe API-Struktur am Port 30000. Multi-GPU-Tensor-Parallelismus wird in vLLM mittels
--tensor-parallel-size 2 aktiviert und in vLLM und --tp 2 in SGLang. Beide laden die Gewichte direkt von Hugging Face. Für die Auswahl der passenden Grafikkarte siehe den Leitfaden zu den beste GPUs für lokale LLMs und prüfen Sie die individuellen Modellanforderungen im Modelldatenbank.
Wo sich die Reibung unterscheidet: Die Dokumentation von vLLM, die Kubernetes-Tools sowie die Community-Antworten sind deutlich umfangreicher – bei obskuren Fehlern ist die Wahrscheinlichkeit höher, dass bereits eine gelöste GitHub-Issue existiert. Die Installationen von SGLang sind gelegentlich wählerischer hinsichtlich der Kombinationen aus CUDA- und PyTorch-Versionen; das offizielle Docker-Image stellt hier den Weg mit geringstem Aufwand dar.
Plattformunterstützung
Linux
Die einzige Plattform mit vollständiger, nativer Unterstützung für beide Engines. NVIDIA-GPUs mit einem aktuellen, CUDA-fähigen Treiber stellen den Hauptweg dar; AMD ROCm funktioniert auf beiden Engines mit unterstützten Grafikkarten. Verwenden Sie die offiziellen Docker-Images, um Versionskonflikte möglichst zu vermeiden.
Windows
Keine der beiden Engines unterstützt Windows nativ. Beide laufen jedoch unter WSL2 mit dem WSL-CUDA-Treiber von NVIDIA, und diese Konfiguration eignet sich gut für die Entwicklung. Für Produktionsumgebungen empfehlen wir jedoch einen echten Linux-Host. Falls Sie lediglich ein lokales Modell auf einem Windows-Desktop benötigen – also keinen Bereitstellungsendpunkt – dann ist Ollama das einfachere Werkzeug.
macOS
Keine GPU-basierte Inferenz auf Apple Silicon durch eines der beiden Projekte. vLLM lässt sich zwar von der Quelle aus für rein CPU-basierte Inferenz unter macOS kompilieren, doch handelt es sich dabei lediglich um eine Entwicklerhilfe, nicht um ein Deployment-Ziel; SGLang unterstützt macOS überhaupt nicht. Für lokale Inferenz auf dem Mac empfehlen wir Ollama oder LM Studio, die Apples Metal-GPU-Beschleunigung nutzen.
Welche Engine je nach Workload zu wählen ist
- Chatbots, Assistenten, Agenten-Frameworks — lange System-Prompts, Tools, mehrstufige Dialogverläufe: SGLang. Genau diesen Lasttyp wurde RadixAttention entwickelt.
- Hochvolumige strukturierte Extraktion — Klassifizierung/Extraktion in JSON im großen Maßstab: SGLang, für Jump-Forward-Decoding.
- Batch-Verarbeitung einzigartiger Dokumente — Zusammenfassung, Pipelines zur Erzeugung von Embeddings mit geringer Prompt-Überlappung: vLLM; Cache-Wiederverwendung bringt hier keinen Nutzen, und vLLMs Tooling ist umfassender.
- Viele verschiedene Modelle oder Nicht-NVIDIA-Hardware — AMD, Intel, TPU, Inferentia, exotische quantisierte Checkpoints: vLLM, hier gibt es keine Konkurrenz hinsichtlich der Abdeckung.
- Sie sind sich unsicher: Beginnen Sie mit vLLM und führen Sie anschließend einen A/B-Vergleich mit SGLang anhand Ihrer realen Anfragelogs durch. Die gemeinsame OpenAI-API macht den Wechsel zu einer bloßen Basis-URL-Änderung.
Und bevor Sie sich für eine der beiden Lösungen entscheiden, überprüfen Sie sorgfältig, ob Self-Hosting bei Ihrem Anfragevolumen tatsächlich kosteneffizienter ist als der Aufruf einer externen API – der Selbsthosting- vs. API-Breakeven-Rechner berechnet diese Kosten pro Modell und Anfragelast.
Häufig gestellte Fragen
Ist SGLang schneller als vLLM?
Bei Workloads mit starkem Präfix-Wiederverwendung oder strukturierten Ausgaben ist dies meistens der Fall – manchmal sogar deutlich. Bei kaltem Cache und einmaligen Prompts liegen beide nahe beieinander, und die Ergebnisse können zwischen Versionen wechseln. Führen Sie daher Benchmarks mit Ihrem eigenen Traffic-Muster durch, statt sich auf einzelne veröffentlichte Zahlen zu verlassen.
Kann ich das OpenAI-Python-SDK mit beiden Engines verwenden?
Ja. Beide Engines stellen einen OpenAI-kompatiblen /v1/chat/completions Endpunkt bereit, sodass das offizielle SDK einfach auf base_url auf http://localhost:8000/v1 (vLLM) oder http://localhost:30000/v1 (SGLang) gerichtet werden kann – ein beliebiger Platzhalter-API-Schlüssel reicht aus. Genau das macht den A/B-Vergleich nahezu kostenfrei.
Hat vLLM nicht ebenfalls Präfix-Caching?
Ja, das tut es – automatisches Präfix-Caching ist in neueren Versionen standardmäßig aktiviert und wiederverwendet KV-Blöcke, deren gehashter Inhalt übereinstimmt. SGLangs Radixbaum vergleicht jedoch feingranularer, und sein Scheduler ordnet Anfragen aktiv so an, dass die Trefferquote steigt; deshalb liegt SGLang bei cache-intensiven Workloads nach wie vor meist vorn.
Welche Engine unterstützt mehr Modelle?
vLLM, eindeutig – seine Liste unterstützter Architekturen ist die längste aller Open-Source-Engines, insbesondere bei multimodalen und Nischenmodellen. SGLang deckt alle wichtigen Open-Weight-Modellfamilien ab und bietet häufig bereits am Tag der Veröffentlichung Unterstützung für neue Flaggschiff-Modelle (seine Optimierungen für DeepSeek sind besonders hervorzuheben), doch der lange Schwanz gehört vLLM. Prüfen Sie die jeweiligen Anforderungen eines Modells im Leitfaden zu VRAM-Anforderungen.
Wo ordnen sich Ollama und llama.cpp ein?
Eine andere Kategorie. Ollama und LM Studio sind lokal ausgeführte Einzelbenutzer-Tools, optimiert für Komfort auf Desktop-Systemen – inklusive Macs; SGLang und vLLM hingegen sind Server-Engines mit hoher Parallelität, optimiert für GPU-Durchsatz bei vielen gleichzeitigen Anfragen. Wenn Sie nur einen Benutzer bedienen, verwenden Sie Ollama; wenn Sie eine Anwendung bedienen, wählen Sie eine dieser beiden Engines.
