- 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.
- Neither runs natively on Windows or macOS — use Linux (or WSL2), or a desktop tool like Ollama/LM Studio for local use.
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 steht für Structured Generation Language — ursprünglich kam es mit einer Python DSL zum Verketten und Verzweigen von LLM-Aufrufen — aber die Serving-Runtime ist das, was die meisten heute deployten. Es hat ernsthafte Production-Credentials: es war unter den Engines DeepSeek empfohlen beim V3-Launch, und es ist bekannt für aggressive Multi-GPU-Optimierungen (Prefill/Decode-Disaggregation, Large-Scale-Expert-Parallelismus für MoE-Modelle).
RadixAttention versus PagedAttention – einfach erklärt
Die zwei Headline-Techniken lösen unterschiedliche Probleme, und die Namen suggerieren ein falsches Entweder-Oder.
PagedAttention (vLLM) ist Speicherverwaltung. Es speichert den KV-Cache in Blöcken fester Größe, wie ein Betriebssystem virtuelle Speicherseiten auslagert, statt einen großen zusammenhängenden Chunk pro Request zu reservieren. Das eliminiert Fragmentierung fast vollständig, sodass weit mehr gleichzeitige Sequenzen in den gleichen VRAM passen, und größere Batches bedeuten höheren Durchsatz. Es geht darum, mehr hineinzupassen.
RadixAttention (SGLang) ist Speicherwiederverwendung. Es organisiert den KV-Cache als Radix-Baum, dessen Schlüssel Token-Sequenzen sind. Wenn ein neuer Request ankommt, läuft die Engine den Baum ab, findet das längste übereinstimmende Präfix und spart das Neuberechnen. System Prompts, Few-Shot-Beispiele, Conversation History und Agent Scratchpads, die sich über Requests wiederholen, werden einmal vorberechnet und wiederverwendet. Es geht darum, weniger zu berechnen.
In 2026 sind die zwei Engines näher zusammengerückt, als das Branding suggeriert: vLLM hat automatisches Prefix-Caching (in neueren Versionen standardmäßig aktiviert), und SGLang pagediert seinen Speicher auch. Der verbleibende praktische Unterschied ist, dass SGLang von Anfang an auf Wiederverwendung ausgelegt war — sein Scheduler ist Cache-bewusst und ordnet und routet Requests so, um die Hit-Rate zu maximieren. Die Faustregel: je größer der Anteil deines typischen Prompts, der sich über Requests wiederholt, desto mehr zahlt sich SGLangs Design aus.
In jedem Fall konkurriert der KV-Cache mit Model Weights um denselben GPU-Speicher, und Concurrency-Spielraum ist das, was eine Serving-Engine dir tatsächlich bringt. Nutze den VRAM-Rechner um zu schätzen, wie viel Speicher ein gegebenes Modell plus Context für Cache vor dem Hardware-Sizing übrig lässt.
Durchsatz und Latenz: Wo jeweils Vorteile liegen
| Workload | Typischerweise schneller | Warum |
|---|---|---|
| Multi-Turn-Chat, Agent Loops, große gemeinsame System Prompts | SGLang | RadixAttention spart das erneute Prefilling wiederholter Präfixe, reduziert Time-to-First-Token und gibt Compute frei |
| One-Off-Prompts mit geringem Overlap (unique Dokumente, Batch-Summarisation) | Ungefähr gleichauf | Beide nutzen Continuous Batching und Chunked Prefill; Cache-Wiederverwendung triggert selten |
| Hohes Volumen JSON / Constrained Output | SGLang | Jump-Forward Decoding sendet Grammar-erzwungene Tokens ohne Model Forward Pass |
| Gemischte Model Zoo, exotische Quantisierung, Non-NVIDIA-Hardware | vLLM | Breitere Backend- und Format-Abdeckung bedeutet weniger unoptimierte Fallback-Pfade |
Behandle jeden spezifischen Durchsatzzahlen, die du online findest, als versionsgebunden. Beide Projekte shippten kontinuierlich Optimierungen, und jedes hat veröffentlichte Benchmarks, wo es das andere schlägt. Die ehrliche Antwort ist: bei Cache-freundlichem Traffic führt SGLang üblicherweise, bei Cold-Cache-Traffic sind sie nah beieinander, und der einzige Benchmark, der zählt, ist deiner: beide shipten Load-Testing-Tools (vLLMs vllm bench serve, SGLangs python -m sglang.bench_serving), die realistische Request-Streams replay.
Strukturierte und eingeschränkte Ausgabe
Beide Engines können Output zwingen, einem JSON-Schema, Regular Expression oder Grammar zu entsprechen, exposed über den OpenAI-kompatiblen response_format -Parameter plus Engine-spezifische Extensions.
SGLang war Vorreiter hier: es kompiliert Constraints in eine komprimierte Finite-State-Machine und nutzt Jump-Forward Decoding — wenn die Grammar die nächsten mehreren Tokens deterministisch macht (Klammern, Anführungszeichen, feste Schlüsselnamen), hängt es sie direkt an, statt das Modell für jeden auszuführen. Für Extraction Pipelines, die Token-lastige JSON produzieren, ist das eine spürbare Beschleunigung.
vLLM unterstützt die gleiche Klasse von Constraints durch pluggable Grammar Backends (xgrammar, guidance, outlines), und da beide Projekte xgrammar als Default Backend adoptiert haben, ist die Lücke erheblich geschrumpft. Fazit: beide sind Production-Ready; SGLang behält einen Vorteil bei stark strukturierten, hochvolumigen Workloads.
Ökosystem, Hardware-Unterstützung und Deployment-Aufwand
| vLLM | SGLang | |
|---|---|---|
| Herkunft | UC Berkeley; PyTorch Foundation project | LMSYS (Chatbot Arena team) |
| Hardware | NVIDIA, AMD ROCm, Intel, Google TPU, AWS Neuron, x86 CPU | NVIDIA First-Class, AMD ROCm unterstützt; andere weniger mature |
| Model Coverage | Am weitesten von allen Engines, inklusive viele Multimodal und Nische Architekturen | Alle großen Familien (Llama, Qwen, DeepSeek, Mistral, GPT-OSS…), kürzerer Tail |
| Quantisierung | FP8, AWQ, GPTQ, INT8, bitsandbytes, mehr | FP8, AWQ, GPTQ; engere Liste |
| API | OpenAI-kompatibel, Default-Port 8000 | OpenAI-kompatibel, Default-Port 30000 |
| Docker Image | vllm/vllm-openai |
lmsysorg/sglang |
Die ersten Schritte sind eine One-Liner für jede auf einer CUDA Linux Box:
pip install vllm dann vllm serve Qwen/Qwen2.5-7B-Instruct — served eine OpenAI-kompatible API auf Port 8000.
pip install "sglang[all]" dann python -m sglang.launch_server --model-path Qwen/Qwen2.5-7B-Instruct — gleiche API Shape auf Port 30000.
Multi-GPU Tensor Parallelism ist --tensor-parallel-size 2 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- versus-API-Kosten-Grenzwert-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.