vLLM vs SGLang: Architektur, Overhead und die Frage, wann man was wählt

Zwei Open-Source-Engines dominieren 2026 das selbstgehostete LLM-Serving: vLLM und SGLang. Beide liefern Continuous Batching, einen paged KV-Cache, OpenAI-kompatible HTTP-Endpunkte und austauschbare Attention-Kernel — und trotzdem unterscheiden sie sich spürbar darin, wohin die Engineering-Energie fließt, und genau das zeigt sich in Latenz- und Durchsatzzahlen. Dieser Guide vergleicht beide auf der Ebene, die für eine Deployment-Entscheidung zählt: Speicherlayout, Scheduler-Design, CPU-Overhead und Feature-Matrizen — jede Aussage an eine zitierte Benchmark oder offizielle Doku gebunden.

Die gemeinsame DNA

Beide Engines bauen auf denselben zwei tragenden Ideen auf, deshalb ist die Grundausstattung nahezu identisch:

• Paged KV-Cache-Management. vLLM hat das als PagedAttention eingeführt (arXiv:2309.06180, SOSP 2023): Der KV-Cache wird in Blöcke fester Größe zerlegt und on-demand allokiert — wie virtuelle Speicherseiten im Betriebssystem. Das senkte Speicherverschwendung durch Fragmentierung und Duplikate auf nahezu null und steigerte den Durchsatz 2–4× gegenüber FasterTransformer und Orca bei gleicher Latenz ¹. SGLang nutzt dieselbe blockbasierte Paging-Verwaltung (Standard-Seitengröße 1) — der Radix-Baum liegt darüber.
• Continuous Batching (Scheduling auf Iterationsebene): Requests treten zwischen den Forward-Pässen in den laufenden Batch ein und verlassen ihn wieder, statt auf das Ende eines Gesamtbatches zu warten. SGLangs v0.4-Blog nennt „Batch-Scheduling, Speicherallokation und Prefix-Matching" explizit als CPU-seitige Aufgaben neben den laufenden GPU-Schritten ².
• OpenAI-kompatible APIs. Beide stellen /v1/completions und /v1/chat/completions bereit (vLLM dokumentiert auf der Online-Serving-Seite ³; SGLang per OpenAI-SDK, inkl. Structured-Output-Beispiele ²).

Wer den KV-Cache-Deep-Dive dieser Seite kennt, wird die Speicherzahlen unten wiedererkennen — beide Engines stehen und fallen mit genau diesem Tensor.

Ein Rechenbeispiel in 60 Sekunden (Qwen3-VL-32B, dem Referenzmodell dieser Seite)

Für ein GQA-Modell mit 64 Layern, 8 KV-Heads und Head-Dimension 128 kostet ein Token:

KV-Bytes/Token = 2 (K und V) × 64 Layer × 8 Heads × 128 Dim × 2 B (fp16)
               = 262.144 B = 256 KiB pro Token

Ein einziger 4.096-Token-Kontext belegt damit 1,07 GB KV-Cache in fp16 — beide Engines allokieren das blockweise, egal ob die Pages aus einer vLLM-Blocktabelle oder einem SGLang-Radix-Baum kommen. Der Unterschied liegt rein in der Organisation der Wiederverwendung über Requests hinweg. Wer eigene Modelle durchrechnen will: Der LLM-Inference-Rechner liefert die Zahlen; die Mathematik dahinter ist für beide Engines identisch.

Austauschbare Attention-Backends — auf beiden Seiten

Keine der beiden Engines hat ihren Attention-Kernel hart verdrahtet:

• vLLM (V1) wählt über eine Registry mit plattformspezifischer Priorität zwischen FlashAttention (FA2/FA3/FA4), FlashInfer (inkl. TRTLLM-Stil-Kerneln) und Triton-Backends; Nutzer können per VLLM_ATTENTION_BACKEND übersteuern ⁴. Der V1-Blog nennt die FlashAttention-3-Integration ausdrücklich als Kernstück ⁵.
• SGLang nimmt --attention-backend (z. B. triton, flashinfer); das gespeicherte Scheduler-Profil aus v0.4 stammt selbst vom Triton-Backend, mit dem Hinweis, dass der FlashInfer-Pfad damals noch eine kleine Idle-Lücke hatte ². Grammar-Backend (xgrammar) und mm_attention_backend sind separat konfigurierbar ⁶.

„Engine X ist schneller" ist also fast nie eine Eigenschaft der Engine allein — es ist Engine × Kernel × Quantisierung × Hardware × Workload. Deshalb steht hinter jeder Perf-Aussage unten eine zitierte Benchmark.

Team vLLM: PagedAttention und das V1-Redesign

vLLMs Ursprung ist die PagedAttention-Arbeit: virtuelle Speicherverwaltung für den KV-Cache — nahezu null Cache-Verschwendung, flexible Cache-Freigabe über Requests hinweg, 2–4× Durchsatz gegenüber dem damaligen Stand der Technik (FasterTransformer, Orca), mit wachsendem Abstand bei längeren Sequenzen und komplexerer Dekodierung ¹.

Die größere Architekturgeschichte heute ist der V1-Neubau (angekündigt Januar 2025). Die Designziele: modulare Codebasis, nahezu null CPU-Overhead, kombinierte Optimierungen und „zero configs" — Features standardmäßig an ⁵. Konkret:

• Bis zu 1,7× höherer Durchsatz gegenüber V0 (ohne Multi-Step-Scheduling), zurückgeführt auf CPU-Overhead-Reduktion über den gesamten Stack — die GPU-Kernel waren zwischen V0 und V1 praktisch identisch, der Gewinn ist Scheduler-/Execution-Loop-Engineering. Gemessen auf Llama 3.1 8B und Llama 3.3 70B mit ShareGPT-Traces; auf Qwen2-VL (VisionArena-Traces) fiel der Zugewinn noch größer aus ⁵.
• Zero-Overhead-Prefix-Caching, standardmäßig aktiv. V0s Prefix-Caching kostete spürbar CPU und war default-off; V1s überarbeitete Datenstrukturen halten den Nachteil unter 1 % Durchsatz bei 0 % Cache-Hit-Rate, deshalb wird es aktiviert ausgeliefert ⁵.
• torch.compile + stückweise CUDA-Graphen, um Kernel-Launch- und Python-Overhead zu drücken, ohne für jedes Modell Handkernels zu schreiben ⁵.
• Symmetrische TP-Architektur: Scheduler und alle Worker (inklusive Worker 0) laufen als getrennte Prozesse und tauschen nur inkrementelle Diffs aus — die V0-Sonderrolle des kolokierten Scheduler/Worker-0-Paares entfällt ⁵.
• Multimodal als First-Class-Citizen: Bild-Preprocessing (Decode/Crop/Transform) in einen separaten nicht-blockierenden Prozess mit Preprocessing-Cache verlagert, Prefix-Caching via Bild-Hashes für multimodale Mehrfachrunden, dazu ein „Encoder-Cache" für Chunked Prefill bei multimodalen Inputs ⁵. Die VLM-Zugewinne waren in den V1-Benchmarks die größten ⁵.

Seit dem V1-Alpha ist die Engine vLLMs Default-Pfad geworden, und die Doku führt heute Speculative Decoding (Draft-Modelle, EAGLE, MTP, N-Gram), LoRA, Structured Outputs und Quantisierung als First-Class-Features ^{7 8}.

Team SGLang: RadixAttention und der Overlap-Scheduler

SGLangs Identität ist RadixAttention (arXiv:2312.07104):Alle vergangenen KV-Caches liegen in einem LRU-verwalteten Radix-Baum, und jeder neue Request wiederverwendet automatisch den längsten passenden gecachten Prefix — ohne Konfiguration, ohne kollitionsanfälliges Hashing, ohne manuelles Cache-Warming. Das Paper meldet bis zu 6,4× höheren Durchsatz gegenüber damaligen Inference-Systemen auf prefix-lastigen Workloads (Few-Shot, Agent-Steuerung, RAG, Multi-Turn-Chat, JSON-Decoding) ⁹. Die Baum-Mechanik leiten wir hier bewusst nicht erneut her — der KV-Cache-Artikel erklärt exakt, wie Radix-Baum-Wiederverwendung funktioniert und wann sie zu vLLM-artiger Block-Wiederverwendung zusammenschrumpft.

Die zweite Säule ist der Zero-Overhead- (Overlap-)Batch-Scheduler, default-on seit v0.4 (Dezember 2024): Der CPU-Scheduler läuft einen Batch voraus und bereitet die Metadaten des nächsten Batches vor, während der aktuelle auf der GPU rechnet — Radix-Cache-Operationen und andere CPU-Arbeit verschwinden hinter der Rechnung. Ein Nsight-Profil über fünf aufeinanderfolgende Decode-Batches zeigt keine GPU-Idle-Zeit (aufgenommen mit dem Triton-Attention-Backend; auf FlashInfer blieb damals eine kleine Lücke). Ergebnis: 1,1× gegenüber SGLang v0.3 und 1,3× gegenüber anderen damaligen State-of-the-Art-Baselines, mit den größten Zugewinnen „auf kleinen Modellen und großen Tensor-Parallelism-Größen" ².

Die ehrliche Einschränkung: Der Overlap-Gewinn ist nicht universell. Issue #2558 im SGLang-Tracker dokumentiert, dass Qwen2.5-0.5B auf einer einzelnen A100 mit --disable-overlap reproduzierbar schneller misst — auf derselben bench_serving-Random-Workload (4.096 Token Input, 2.048 Token Output), die auch der v0.4-Blog nutzt ¹⁰. Die v0.4-Aussage lautet konkret „kleine Modelle und große TP-Größen" ² — bei einem winzigen Modell auf einer GPU können die Forward-Schritte kürzer sein als die Buchhaltung, die die Overlap-Pipeline hinzufügt; als Lösungsweg wird im Issue Run-to-Completion-Scheduling für kleine Modelle diskutiert ¹⁰. Beide Quellen zusammengelesen: Overhead lohnt sich vor allem, wenn die GPU-Schritte relativ zur Scheduler-CPU-Arbeit lang sind. Wer eine kleine Modellflotte betreibt, misst selbst nach, statt „default-on" mit „immer schneller" gleichzusetzen.

Drei weitere v0.4-Zahlen, die man kennen sollte:

• Cache-bewusster Load Balancer (sglang-router, in Rust): leitet jeden Request an den Worker mit der höchsten erwarteten Prefix-Hit-Rate. Auf einer balancierten Shared-Prefix-Workload über 8× A100: Durchsatz 82.665 → 158.596 Tok/s (≈1,9×), Cache-Hit-Rate 20 % → 75 % (3,8×) ².
• DP-Attention für MLA-Modelle (DeepSeek): Jeder DP-Rank besitzt seinen eigenen KV-Cache statt der TP-typischen Duplikation für MLAs einzelner KV-Heads, mit All-Gather vor der MoE-Schicht — 1,9× Decode-Durchsatz auf DeepSeek-Coder-V2 über 8× H100 (bei TP 8) ².
• xgrammar für Structured Outputs: bis zu 10× schnelleres JSON-Decoding als andere Open-Source-Engines, via adaptiver Token-Masken über dem kontextfreien Kern der Grammatik ^{2 11}.

Später kamen EAGLE-2/EAGLE-3-Speculative-Decoding hinzu (laut Doku-Tabelle auf Llama 3.1 8B auf MT-Bench: 158,34 → 373,25 Tok/s mit EAGLE-3 auf 1× H100) ¹² sowie S-LoRA/Punica-basiertes Multi-LoRA ⁶.

Unterschiede, die man an der Tastatur spürt

Jenseits der Schlagzeilen-Benchmarks entscheiden vier Bereiche die meisten Deployments. Alle Einträge stammen aus den aktuellen offiziellen Dokus der Projekte.

1. Prefix-Cache-Ergonomie

vLLM V1s hash-basiertes APC ist inzwischen default-on und praktisch gratis, aber die Wiederverwendung ist exakt-prefix-orientiert und blockgranular. SGLangs Radix-Baum arbeitet automatisch, unterhalb der Blockgranularität, und bringt Fleet-Tooling mit: lpm-Scheduling (Requests nach längstem gemeinsamen Prefix gruppieren), --disable-radix-cache für Ablationen und den cache-bewussten Router. Beim Multi-Tenant-Chat mit viel System-Prompt-Wiederverwendung ist SGLang vorn; für einen einzelnen Node mit gemischtem Traffic spielt es keine Rolle.

2. Speculative Decoding

vLLM unterstützt Draft-Modell-Spekulation, EAGLE, MTP (Multi-Token Prediction), N-Gram-/Lookup-Spekulation und dynamisches Spekulieren, mit dokumentierter algorithmischer Verlustfreiheit und einer scharfen Kante: Pipeline-Parallelism ist mit Speculative Decoding inkompatibel (Stand vLLM ≤ 0.15.0) ⁷. SGLangs Flaggschiff ist EAGLE-2/EAGLE-3 (plus eigenständige Draft-Modelle und MTP für neuere Architekturen), kompatibel mit Radix-Cache und Chunked Prefill ¹². Historisch lag jeweils mal die eine, mal die andere Engine bei Out-of-the-box-Spec-Decode-Durchsatz vorn — mit eurem Draft-Modell-Paar messen, nicht mit den Diagrammen der Projekte.

3. Quantisierungs-Unterstützung

vLLMs Quantisierungs-Seite listet AutoAWQ, GPTQModel, BitsAndBytes, Intel Neural Compressor, LLM Compressor (FP8 W8A8, INT4 W4A16, INT8 W4A8/W8A8), NVIDIA Model Optimizer (inkl. NVFP4-Klasse), Online-Quantisierung, AMD Quark, TorchAO, GGUF und quantisierten KV-Cache ¹³. SGLangs Tabelle umfasst fp8, w8a8 fp8/int8, blockwise_int8, mxfp4/mxfp8-Varianten, awq, gptq (auf NVIDIA/AMD via gptq_marlin), compressed-tensors, quark und auto-round über NVIDIA/AMD/Ascend ¹⁴. Die praktische Schnittmenge ist riesig (FP8, AWQ, GPTQ-Marlin, INT8, MXFP4 auf beiden Seiten); Unterschiede stecken vor allem in Nischen bei Format und Hardware — das Quant-Rezept des konkreten Checkpoints gegen beide Tabellen prüfen, bevor man sich festlegt.

4. LoRA und Parallelism

Multi-LoRA: Beide dienen viele Adapter in einem Batch aus. vLLM bietet --enable-lora, --max-lora-rank (Default im OpenAI-Server) plus dynamisches LoRA-Laden über die API (Opt-in, mit Sicherheitswarnung) ⁸. SGLangs Multi-LoRA ist S-LoRA/Punica-abgeleitet (--lora-paths, max_loras_per_batch default 8, Triton- und Chunked-SGMV-Backends, LRU-Adapter-Eviction, TP-kompatibel) ⁶.

Verteilt: vLLM fährt Tensor-, Pipeline-, Expert- und Data-Parallelism (mit --enable-expert-parallel für MoE) ^{8 7}. SGLang deckt TP, PP, EP, DP-Attention (--enable-dp-attention, siehe oben) ab und liefert einen eigenen cache-bewussten, Multi-Node-fähigen Router mit ^{2 12}. Für DeepSeek-artige MLA-Architekturen bei großem TP ist SGLangs DP-Attention-Story die differenziertere; für heterogene Flotten ist vLLMs Hardware-Matrix (NVIDIA, AMD, TPU, CPU) breiter ¹³.

Entscheidungstabelle

TensorRT-LLM der Vollständigkeit halber

NVIDIAs TensorRT-LLM ist der dritte Name in all diesen Vergleichen — und es bewegt sich in dieselbe Richtung: Der aktuelle Stack baut schwerpunktmäßig auf einem PyTorch-Backend auf (verfügbar ab Version 0.17, tensorrt_llm._torch) und stellt mit trtllm-serve ebenfalls eine OpenAI-kompatible API bereit ¹⁵. Einsatzgebiete mit enger Modell-/Engine-Versionskopplung und einer weitgehend auf NVIDIA beschränkten Hardware-Matrix — Continuous Batching, In-Flight-Updates, FP8/NVFP4 und speculative decoding: Inference- und Latenzvorteile sind hier gegen geringere Modellbreite und kürzere Release-Zyklen abzuwägen; auf homogenen NVIDIA-Flotten liefert TensorRT die vom Hersteller beworbenen Engpass-Kennziffern. Für NVIDIA-dominierte Deployments ist es den benchmark-mäßigen Vergleich wert; wer engine-agnostische Artefakte, GPUs verschiedener Hersteller oder maximale Hackability braucht, fährt mit den beiden Open-Source-Engines praktischer. Die vLLM-V1-Autoren nennen TensorRT-LLM ausdrücklich unter den Engines, die V1s Design beeinflusst haben ⁵.

Fazit

vLLM und SGLang konvergieren bei den Grundlagen — paged KV-Cache, Continuous Batching, OpenAI-APIs, pluggable Attention — und konkurrieren an den Rändern. vLLM hat auf einen Execution-Loop-Neubau von Grund auf gesetzt (V1: 1,7× über V0, Prefix-Caching gratis und aktiv, multimodal zuerst); SGLang auf automatische Prefix-Wiederverwendung überall (Radix-Baum + cache-bewusster Router) und aggressives Scheduler-Overlapping. Der Workload entscheidet: Wiederverwendungsmuster und Routing sprechen für SGLang; Breite, VLMs und Hardware-Abdeckung für vLLM. Und niemals auf eine Schlagzeilen-Zahl deployen: bench_serving-artige Traces auf dem eigenen Traffic, den eigenen GPUs und mit der Quantisierung sowie den Kontextlängen messen, die wirklich ausgeliefert werden. Wer die Grundlagen auffrischen will, startet bei wie LLMs funktionieren und dem VRAM-Modell hinter diesen Zahlen.