Vergleich von Open-Source-LLM-Inferenz-Engines: SGLang, vLLM, MAX und BentoML 2026

Da KI-Modelle von der Forschung in die Produktion übergehen, bestimmt die gewählte Inferenz-Engine Ihre Latenz, Ihren Durchsatz und Ihre Infrastrukturkosten. Das Open-Source-Ökosystem hat sich auf drei ernsthafte Konkurrenten konzentriert – jeder mit einer eigenen Architekturphilosophie und spezifischen Kompromissen.

Dieser Beitrag analysiert SGLang, vLLM und MAX (Modular) – die drei wichtigsten Engines bis Ende 2026. Wir decken ab, was jede einzelne leistet, wo ihre Stärken und Schwächen liegen und wie sie im direkten Vergleich abschneiden.

---

SGLang

GitHub: sgl-project/sglang (~25.000 Sterne) · Lizenz: Apache 2.0 · Aktuellste Version: v0.5.9 (Feb. 2026)

Beschreibung

SGLang (Structured Generation Language) ist ein leistungsstarkes Serving-Framework für LLMs und multimodale Modelle, das ursprünglich am Sky Computing Lab der UC Berkeley vom LMSYS.org-Team entwickelt wurde. Im Januar 2026 wurde das SGLang-Projekt als RadixArk ausgegründet, ein kommerzielles Startup, das in einer von Accel angeführten Runde mit ~400 Mio. $ bewertet wurde – mit Angel-Investitionen vom Intel-CEO Lip-Bu Tan. Mitbegründer und CEO Ying Sheng war zuvor als Forschungswissenschaftler bei xAI tätig.

Die Kerninnovation von SGLang ist RadixAttention, die eine Radix-Baum-Datenstruktur für die automatische, feingranulare Wiederverwendung des KV-Caches nutzt. Dies macht die Engine außergewöhnlich schnell für Multi-Turn-Konversationen, RAG-Pipelines und alle Workloads mit geteilten Präfixen. Die Engine für strukturierte Ausgaben (xgrammar Backend) ist die schnellste im Open-Source-Bereich verfügbare Lösung und liefert eine bis zu 10-mal schnellere JSON-Dekodierung als Alternativen.

SGLang läuft mittlerweile auf über 400.000 GPUs weltweit und generiert täglich Billionen von Token. Zu den namhaften Produktionsnutzern gehören xAI (als Standard-LLM-Engine), AMD, NVIDIA, LinkedIn und Cursor.

Fish Audio S2 & SGLang: Das S2-Modell von Fish Audio – eine 4B-Parameter Dual-Autoregressive TTS-Architektur, die auf über 10 Mio. Stunden multilingualem Audio trainiert wurde – ist strukturell isomorph zu standardmäßigen autoregressiven LLMs. Das bedeutet, dass es nativ alle Optimierungen von SGLang erbt: Continuous Batching, Paged KV Cache, CUDA Graph Replay und RadixAttention. Bei Voice-Cloning-Workloads cached RadixAttention die KV-Zustände des Referenz-Audios und erreicht so eine durchschnittliche Präfix-Cache-Trefferquote von 86,4 % – ein massiver Effizienzgewinn für das produktive TTS-Serving. Fish Audio hat S2 mit erstklassiger SGLang-Unterstützung als Open-Source veröffentlicht.

Vorteile

• Best-in-Class-Durchsatz – ca. 29 % schneller als vLLM in Batch-Durchsatz-Benchmarks (H100, Llama 3.1 8B, ShareGPT 1K Prompts: ~16.200 tok/s vs. ~12.500 tok/s)
• RadixAttention liefert 10–20 % Geschwindigkeitssteigerung bei Multi-Turn-Chats und bis zu 6,4-fach bei präfixintensiven RAG-Workloads
• Schnellste strukturierte Ausgabe – das xgrammar Backend ist 3–10-mal schneller als Alternativen bei der eingeschränkten JSON-/Grammatik-Dekodierung
• Breite Modalitätsunterstützung – über 60 LLM-Familien, über 30 multimodale Modelle, Embedding-/Reward-Modelle, Diffusionsmodelle (Bild & Video, bis zu 5-mal schneller) und TTS (Fish Audio S2)
• Starke RL-Integration – Miles-Framework (von RadixArk) für Reinforcement Learning Trainingsschleifen
• Breite Hardware-Unterstützung – NVIDIA (GB200 → RTX 4090), AMD MI300X/MI355, Google TPU (via SGLang-Jax), Intel Xeon, Ascend NPU, Apple Silicon (MLX)
• Aktive Release-Zyklen – ca. 3-wöchiger Veröffentlichungszyklus, schnelle Unterstützung neuer Modelle (als Erste, die DeepSeek R1 skaliert mit P/D-Disaggregation auf 96 H100s ausführten)

Nachteile

• Kleinere Community – ~25.000 GitHub-Sterne gegenüber ~75.000 bei vLLM; weniger Drittanbieter-Integrationen und Tutorials
• Nur Linux – erfordert WSL unter Windows; kein natives macOS GPU-Serving
• Python GIL-Engpass – der Request-Router stößt bei über ~150 gleichzeitigen Anfragen an Skalierungsgrenzen
• Eingeschränkte GGUF-Unterstützung – im Vergleich zu llama.cpp nicht ideal für quantisierte Edge-Bereitstellungen
• Stabilität – gelegentliche Probleme mit Abhängigkeiten in Release-Kandidaten; weniger praxiserprobt bei extremen Enterprise-Spezialfällen

---

vLLM

GitHub: vllm-project/vllm (~75.000 Sterne) · Lizenz: Apache 2.0 · Aktuellste Version: v0.19.0 (Apr. 2026)

Beschreibung

vLLM ist die am weitesten verbreitete Open-Source-LLM-Serving-Engine und der De-facto-Industriestandard. Sie treibt Produktionssysteme bei Amazon (Rufus, bedient 250 Mio. Kunden), LinkedIn, Roblox (4 Mrd. Token/Woche), Meta, Mistral AI, IBM und Stripe (das eine Reduzierung der Inferenzkosten um 73 % meldete) an. Das Team hinter vLLM gründete Inferact und sammelte im Januar 2026 150 Mio. $ ein, um das Projekt zu kommerzialisieren.

Die grundlegende Innovation von vLLM ist PagedAttention, die sich an der virtuellen Speicherverwaltung von Betriebssystemen orientiert, um KV-Caches in nicht zusammenhängende Blöcke aufzuteilen und so den GPU-Speicher-Verschnitt um bis zu 80 % zu reduzieren. Der V1 Architektur-Rewrite (Standard seit v0.8.0, vollständiger Ersatz von V0 bis Q3 2025) strukturierte die Engine in eine Multi-Prozess-Architektur mit isoliertem Scheduler, Engine-Kern und GPU-Workern um, die über ZeroMQ kommunizieren – was einen bis zu 1,7-mal höheren Durchsatz als das ursprüngliche Design ermöglicht.

vLLM bietet die breiteste Modell- und Hardware-Unterstützung aller Engines: Text-LLMs (Llama 3/4, Qwen 3, DeepSeek V3, Gemma 4, GPT-OSS), Vision-Language-Modelle (InternVL, Qwen2.5-VL, Pixtral), Audiomodelle (Qwen3-ASR/Omni) und Embedding-Modelle. Das separate Projekt vLLM-Omni erweitert die Unterstützung auf Diffusions- und TTS-Modelle. Die Hardware reicht von NVIDIA, AMD ROCm, Intel XPU/Gaudi, Google TPU, AWS Trainium, ARM-CPUs bis hin zu IBM Z Mainframes.

Vorteile

• Industriestandard – ~75.000 GitHub-Sterne, über 200 Mitwirkende pro Release, größtes Ökosystem an Tutorials, Anleitungen und Integrationen
• Breiteste Kompatibilität – mehr unterstützte Modellarchitekturen und Hardware-Backends als jede andere Engine
• Produktionserprobt – bewährt in massivem Maßstab (Amazon, Roblox, Stripe, Meta)
• V1-Architektur – Zero-Config-Optimierungen, automatisches Präfix-Caching, Unified Chunked Prefill; v0.16.0 fügte asynchrones Scheduling mit einer Durchsatzverbesserung von 30,8 % hinzu
• OpenAI-kompatible API – Drop-in-Ersatz für OpenAI-Endpunkte
• Starkes Kubernetes-Konzept – offizieller Production Stack + llm-d Projekt (Red Hat, Google Cloud, IBM, NVIDIA) für disaggregiertes Serving
• Skaliert bei extremer Gleichzeitigkeit – C++ Routing bewältigt über 150 gleichzeitige Anfragen besser als Python-basierte Alternativen

Nachteile

• Ca. 29 % langsamerer Durchsatz als SGLang in Batch-Benchmarks bei Workloads mit geteilten Präfixen
• Weniger effizientes Präfix-Caching – PagedAttention fehlt die automatische, auf Radix-Bäumen basierende Präfix-Wiederverwendung von SGLang
• Hohes Entwicklungstempo – geht gelegentlich zu Lasten der Stabilität; die V1-Migration entfernte einige Funktionen (best_of, Logits-Prozessoren pro Anfrage)
• GPU-fokussiert – eingeschränkte CPU-Fallback-Leistung
• Strukturierte Ausgabe – langsamer als das xgrammar Backend von SGLang bei eingeschränkter Dekodierung

---

MAX (Modular)

GitHub: modular/modular (~25.600 Sterne) · Lizenz: Apache 2.0 + LLVM Exceptions (Open-Source Kernel, Stdlib, Modellarchitekturen, Serving-Library); Modular Community License (Compiler-Binärdatei) · Aktuellste Version: v26.2 (März 2026) · Website: Modular

Beschreibung

MAX verfolgt einen grundlegend anderen Ansatz als vLLM und SGLang. Während andere Engines auf CUDA-Bibliotheken (cuBLAS, cuDNN, FlashAttention, FlashInfer) aufbauen, ist MAX der einzige voll vertikal integrierte Inferenz-Stack, der ohne CUDA-Abhängigkeit entwickelt wurde – von GPU-Kerneln (Mojo) über das Model-Serving (MAX Serve) bis hin zur Cluster-Orchestrierung (BentoML + Modular Cloud) wurde die gesamte Inferenz-Pipeline von Grund auf auf MLIR aufgebaut, ohne Abhängigkeit von hardware-spezifischen Bibliotheken.

Hinweis: MAX als Plattform ist breiter gefasst als eine Serving-Engine – sie enthält eine PyTorch-ähnliche Modellentwicklungs-API (model.compile(), Eager-Modus), die eher mit PyTorch selbst vergleichbar ist. MAX Serve ist die Inferenz-Serving-Komponente, die direkt mit vLLM und SGLang konkurriert. Der Einfachheit halber vergleicht dieser Beitrag sie unter dem Dachnamen "MAX", da Endnutzer typischerweise mit dem gesamten Stack interagieren.

MAX wird von Modular AI entwickelt – 2022 von Chris Lattner (Schöpfer von LLVM, Clang, Swift und MLIR) und Tim Davis (Mitschöpfer von TensorFlow Lite, skaliert auf Milliarden von Geräten bei Google) mitbegründet – mit 380 Mio. $Kapital bei einer Bewertung von 1,6 Mrd.$. Mojo, Modulars Systemprogrammiersprache auf Basis von MLIR, ermöglicht hardware-agnostische Kernel für NVIDIA, AMD, Apple Silicon und CPUs aus einer einzigen Codebasis, mit Docker-Images unter 700 MB.

Modular hat über 750.000 Zeilen Mojo-Code unter Apache 2.0 mit LLVM Exceptions veröffentlicht, einschließlich produktionsreifer GPU-Kernel, der vollständigen Standardbibliothek, Modellarchitekturen und der MAX Serving-Library. Der Mojo-Compiler selbst soll 2026 zusammen mit dem Release von Mojo 1.0 als Open-Source veröffentlicht werden. Im Februar 2026 übernahm Modular BentoML (das Open-Source-Framework für Modell-Deployment, das von über 10.000 Organisationen genutzt wird) und erweiterte den Stack um Produktions-Deployment und Cloud-Orchestrierung.

MAX unterstützt über 500 Modelle von Hugging Face, darunter Text, Vision-Language (Qwen2.5-VL, Kimi VL, Gemma 3/4) und Bildgenerierung (FLUX).

Vorteile

• Einziger Inferenz-Stack, der komplett ohne CUDA entwickelt wurde – Mojo-Kernel ersetzen cuBLAS, cuDNN und FlashAttention durch eine einzige portable Codebasis; Matmul-Kernel haben 1.772 TFLOPS auf B200 erreicht und übertreffen damit cuBLAS
• Konkurrenzfähiger oder überlegener Durchsatz – auf NVIDIA L40 mit Qwen3-8B: MAX schloss 500 Prompts in 50,6 s ab, verglichen mit 54,2 s bei SGLang und 58,9 s bei vLLM (16 % schneller als vLLM); auf Vast.ai mit Llama 3.1 8B: 89,9 tok/s vs. 75,9 bei vLLM (18 % schneller) bei fast halbierter TTFT
• Geringste Tail-Latency – p99 TTFT von 13,1 ms gegenüber 23,6 ms bei vLLM in L40 Benchmarks
• Hardware-portabel – Mojo-Kernel lassen sich für NVIDIA, AMD, Apple Silicon und CPUs aus einer Codebasis kompilieren; keine separaten CUDA/ROCm-Implementierungen nötig
• Kleinster Container-Footprint – Docker-Images unter 700 MB, deutlich leichter als vLLM oder SGLang
• Modernste Bildgenerierung – MAX bedient nativ Diffusionsmodelle (FLUX.2, SDXL) neben LLMs im selben Container und über dieselbe API, mit 4,1-fach schnellerer Inferenz als torch.compile auf B200
• Eigene Kernel-Entwicklung – PyTorch-ähnlicher Eager-Modus mit model.compile() zum Schreiben eigener Mojo-Kernel, mit vollständigen Open-Source-Kernel-Implementierungen als Referenz
• Tiefe Open-Source-Compiler-Wurzeln – geleitet von Chris Lattner, dem Schöpfer von LLVM (nach dem vLLM benannt wurde); derselbe community-getriebene Ansatz, der LLVM zum Industriestandard machte, wird nun auf MAX und Mojo angewendet
• 380 Mio. $ Finanzierung – gut kapitalisiert mit langem Atem und starkem Ingenieursteam (337 Mitarbeiter)

Nachteile

• Hardware-abhängige Performance – exzellent auf NVIDIA B200 und AMD MI355X, aber die Leistung variiert über GPU-Generationen hinweg; nicht universell am schnellsten auf jedem Hardware-Ziel
• Mojo-Compiler noch nicht Open-Source – Veröffentlichung für 2026 zusammen mit Mojo 1.0 geplant; die Standardbibliothek, Kernel, Modellarchitekturen und Serving-Library sind bereits Open-Source (über 750.000 Zeilen)
• Jüngeres Ökosystem – weniger Praxiserprobung in der Produktion als vLLM; weniger von der Community gepflegte Modellimplementierungen
• Weniger unterstützte Architekturen – über 500 Modelle sind beeindruckend, aber immer noch weniger als bei vLLM/SGLang für topaktuelle oder Nischenmodelle
• Mojo-Lernkurve für Kernel-Entwicklung – Mojo ist als Python-Superset für einfache Adoption konzipiert, aber die fortgeschrittene GPU-Kernel-Entwicklung erfordert dennoch das Erlernen neuer Konzepte
• Disaggregierte Inferenz und Orchestrierung nicht Open-Source – Funktionen wie getrenntes Prefill/Decode, KV-Cache-bewusstes Routing, Multi-Modell-Orchestrierung und Autoscaling über gemischte GPU-Flotten sind über Modular Cloud verfügbar, nicht in der selbst gehosteten Community Edition

---

Direkter Vergleich

Wann man was verwenden sollte

Wählen Sie SGLang, wenn Sie für Multi-Turn-Chatbots, RAG-Pipelines, strukturierte JSON-Ausgaben oder TTS-Serving (insbesondere mit Fish Audio S2) optimieren. Die RadixAttention und das xgrammar Backend von SGLang bieten messbare Leistungsvorteile in diesen Workloads, und die kommerzielle Unterstützung durch RadixArk gewährleistet langfristigen Support.

Wählen Sie vLLM, wenn Sie die sicherste, am meisten produktionserprobte Option mit der breitesten Modell- und Hardwarekompatibilität benötigen. Die Community von vLLM mit 75.000 Sternen, die Akzeptanz in Unternehmen (Amazon, Roblox, Stripe) und die umfassende Kubernetes-Unterstützung machen es zur risikoärmsten Wahl für allgemeines LLM-Serving in großem Maßstab.

Wählen Sie MAX, wenn Sie in Umgebungen mit unterschiedlicher Hardware arbeiten (NVIDIA + AMD + CPU), Wert auf den Container-Footprint und die operative Einfachheit legen oder in die Entwicklung eigener Kernel mit Mojo investieren möchten. Der compiler-gesteuerte Ansatz von MAX bietet eine einzigartige Flexibilität, und durch die Übernahme von BentoML verfügt es über die vollständigste Deployment-Plattform der drei Kandidaten.

---

Was die Inferenz im Jahr 2026 prägt

Drei Trends verändern die Wettbewerbslandschaft:

Getrenntes (disaggregiertes) Prefill/Decode hat sich vom Experiment zum Standard entwickelt. SGLang demonstrierte P/D im Produktionsmaßstab auf 96 H100s für DeepSeek; das llm-d Projekt von vLLM (Red Hat, Google Cloud, IBM, NVIDIA) treibt die Kubernetes-native Disaggregation voran; und der Dynamo-Orchestrator von NVIDIA lässt sich in alle großen Engines integrieren.

Multimodales Serving expandiert rasant. vLLM-Omni und SGLang-Diffusion starteten beide Ende 2025 und unterstützen Diffusionsmodelle sowie TTS neben traditionellen LLMs. Die Grenze zwischen "LLM-Engine" und "allgemeinem Modell-Server" verschwimmt.

Kommerzielle Konsolidierung beschleunigt sich. RadixArk (400 Mio. $Bewertung), Inferact (150 Mio.$ Finanzierung für vLLM) und Modular (1,6 Mrd. $ Bewertung + BentoML-Übernahme) bestätigen, dass die Open-Source-Inferenz in ihre kommerzielle Phase für Unternehmen eingetreten ist. HuggingFace TGI ist in den Wartungsmodus gewechselt – womit SGLang, vLLM und MAX die drei primären Open-Source-Inferenz-Engines bis Ende 2026 bleiben.