Skip to main content
PromptQuorumBuilt for humans. Structured for AI.
Startseite/Lokale LLMs Pro
Overview & Reference

SGLang erklärt: RadixAttention und strukturiertes LLM-Serving (2026)

·13 Min. LesezeitVon Hans Kuepper · Gründer von PromptQuorum · Entdeckungsplattform für Open-Weight- und Open-Source-KI

SGLang ist ein kostenloses, quelloffenes (Apache 2.0) Serving-Framework für große Sprachmodelle und Vision-Language-Modelle, entstanden aus Forschung mit Bezug zur UC Berkeley, Stanford und der LMSYS-Organisation hinter Chatbot Arena. Das technische Alleinstellungsmerkmal ist RadixAttention: Der Attention-KV-Cache abgeschlossener und laufender Anfragen wird in einem Radix-Baum gespeichert, sodass jede neue Anfrage mit gemeinsamem Präfix — ein System-Prompt, Few-Shot-Beispiele oder ein früherer Gesprächsabschnitt — die passenden Cache-Einträge automatisch wiederverwenden kann, statt sie neu zu berechnen. SGLang bringt außerdem eine in Python eingebettete Frontend-Sprache mit (sgl.gen, sgl.select und verwandte Primitiven) zum Schreiben mehrstufiger LLM-Programme und setzt Structured Output — JSON-Schemas und Regex-Muster — direkt in der Dekodierschleife durch statt als Nachbearbeitungsschritt. Es bringt einen OpenAI-kompatiblen Server mit (python -m sglang.launch_server), dokumentiert NVIDIA-GPUs als primäres, am besten unterstütztes Ziel mit zusätzlichen AMD-, Intel- und weiteren Backends, und ist — wie vLLM — für GPU-gestütztes Serving gebaut, nicht für den Einzelnutzer-Klick-Anwendungsfall, auf den Tools wie Ollama und LM Studio zielen.

Wichtigste Erkenntnisse

  • Kostenlos und Apache-2.0-lizenziert quelloffen, entstanden aus Forschung mit Bezug zur UC Berkeley, Stanford und LMSYS
  • RadixAttention verwendet KV-Cache-Einträge über Anfragen mit gemeinsamem Präfix automatisch weiter, mittels Radix-Baum statt anfragebasierter Cache-Isolation
  • Structured Output — JSON-Schemas und Regex-Constraints — wird während der Dekodierung über eine komprimierte Zustandsmaschine durchgesetzt, nicht als Nachbearbeitungsfilter
  • Bringt eine in Python eingebettete Frontend-DSL mit (sgl.gen, sgl.select, sgl.fork) zum Schreiben mehrstufiger LLM-Programme
  • Eingebauter OpenAI-kompatibler API-Server, gestartet mit python -m sglang.launch_server
  • Unterstützt Continuous Batching, Tensor-Parallelität und Quantisierungsformate wie FP8, INT4, AWQ und GPTQ
  • Primäre, am besten unterstützte Hardware sind NVIDIA-GPUs; das Projekt dokumentiert außerdem AMD-, Intel- und weitere Beschleuniger-Backends mit schmalerer Praxisabdeckung
  • Keine Einzelnutzer-Desktop-App — kein grafischer Installer, und nicht auf CPU-only oder Apple Silicon ausgelegt wie llama.cpp und Ollama

📍 In einem Satz

SGLang ist ein kostenloses, Apache-2.0-lizenziertes Serving-Framework für LLMs und Vision-Language-Modelle, entstanden aus Forschung mit Bezug zur UC Berkeley, Stanford und LMSYS, das mit RadixAttention den KV-Cache automatisch über Anfragen mit gemeinsamem Präfix wiederverwendet und Structured Output in der Dekodierschleife durchsetzt.

💬 In einfachen Worten

Statt einer Desktop-Chat-App ist SGLang Server-Software, die zwei Dinge gleichzeitig leistet: viele gleichzeitige Anfragen effizient bedienen — besonders solche, die einen System-Prompt oder Gesprächsverlauf wiederholen — und garantieren, dass die Ausgabe des Modells tatsächlich einem angegebenen JSON-Schema oder Muster entspricht.

📌Hinweis: Dieser Artikel basiert auf SGLangs offiziellem GitHub-Repository und öffentlicher Dokumentation, nicht auf eigenen Benchmarks. SGLangs eigenes Material nennt konkrete Beschleunigungsfaktoren für RadixAttention und JSON-Dekodierung in bestimmten Release-Benchmarks; dieser Artikel übernimmt diese nicht als allgemeingültige Zahlen, da sie von Workload, Hardware und getesteter Version abhängen und sowohl SGLang als auch vLLM für sich selbst günstige Benchmarks veröffentlichen.

Lesen auf:
🇺🇸en🇩🇪de🇫🇷fr🇯🇵ja🇨🇳zh🇪🇸es🇧🇷pt🇸🇦ar🇰🇷ko

SGLang ist ein kostenloses, Apache-2.0-lizenziertes Serving-Framework für große Sprachmodelle und Vision-Language-Modelle, entstanden aus Forschung mit Bezug zur UC Berkeley, Stanford und der LMSYS-Organisation hinter Chatbot Arena. Der zentrale technische Beitrag ist RadixAttention, eine Technik zur automatischen, feingranularen Wiederverwendung des KV-Caches über mehrere Generierungsaufrufe hinweg, die ein gemeinsames Präfix teilen — etwa einen wiederholten System-Prompt, Few-Shot-Beispiele oder ein mehrstufiges Gespräch. SGLang kombiniert dieses Backend mit einer in Python eingebetteten Frontend-Sprache zum Schreiben mehrstufiger LLM-Programme und mit Structured-Output-Unterstützung auf Engine-Ebene (JSON-Schemas und Regex-Constraints, die während der Dekodierung durchgesetzt werden) — damit positioniert sich SGLang ebenso als Engine für strukturierte Generierung und agentische Workloads wie als reine Durchsatz-Engine.

SGLang erklärt: RadixAttention und strukturiertes LLM-Serving (2026)

Was ist SGLang?

SGLang ist ein kostenloses, Apache-2.0-lizenziertes Serving-Framework für große Sprachmodelle und Vision-Language-Modelle. Es entstand aus Forschung mit Bezug zur UC Berkeley, Stanford und der LMSYS-Organisation — derselben Community hinter Chatbot Arena — und wird heute unter der GitHub-Organisation sgl-project weiterentwickelt. Anders als Tools, die vor allem für einen einzelnen Nutzer gebaut sind, der lokal mit einem Modell chattet, zielt SGLang auf zwei überlappende Probleme: viele gleichzeitige Anfragen effizient bedienen, und garantieren, dass die Ausgabe eines Modells einem strukturierten Format wie JSON entspricht — relevant für Function Calling, Agenten-Pipelines und andere maschinell weiterverarbeitete Ausgaben.

  • Entstanden aus Forschung mit Bezug zur UC Berkeley, Stanford und LMSYS; heute unter der Open-Source-Organisation sgl-project weiterentwickelt
  • Apache-2.0-lizenziert: der Quellcode ist öffentlich verfügbar zur Nutzung, Änderung und Weitergabe gemäß den Lizenzbedingungen
  • Kombiniert eine in Python eingebettete Frontend-DSL zum Schreiben von LLM-Programmen mit einer dafür mitentwickelten Backend-Runtime (der SGLang Runtime, oft SRT abgekürzt)
  • Lädt Hugging-Transformers-kompatible Modell-Checkpoints, darunter Modellfamilien wie Llama, Qwen, Mistral und DeepSeek, meist ohne separaten Konvertierungsschritt
  • Dokumentiert Produktionseinsätze mit hohem täglichen Token-Volumen und nennt in eigenen Materialien mehrere Unternehmen und Forschungseinrichtungen als Anwender

Was ist RadixAttention, und warum ist es wichtig?

RadixAttention ist die Speicherverwaltungstechnik, für die SGLang am bekanntesten ist. Viele reale LLM-Workloads senden mehrere Generierungsaufrufe mit gemeinsamem Präfix — denselben System-Prompt in jeder Anfrage, dieselben Few-Shot-Beispiele oder frühere Abschnitte eines laufenden Gesprächs. Den Attention-KV-Cache für dieses gemeinsame Präfix bei jedem Aufruf neu zu berechnen, verschwendet GPU-Rechenleistung und -Speicher. RadixAttention speichert stattdessen KV-Cache-Einträge sowohl abgeschlossener als auch laufender Anfragen in einem Radix-Baum — einer Baumstruktur, die über Token-Sequenzen indiziert ist —, sodass eine neue Anfrage den Cache für jedes geteilte Präfix automatisch findet und wiederverwendet, ohne dass Entwickler diese Wiederverwendung manuell nachverfolgen müssen.

  • Findet und verwendet KV-Cache-Einträge über Anfragen mit gemeinsamem Token-Sequenz-Präfix automatisch weiter, mittels Radix-Baum-Datenstruktur
  • Deckt Präfixe aus wiederholten System-Prompts, geteilten Few-Shot-Beispielen und mehrstufigem Gesprächsverlauf ab — nicht nur exakt dieselbe wortwörtlich wiederholte Anfrage
  • Wendet eine Least-Recently-Used-Verdrängungsstrategie (LRU) auf den Radix-Baum an, sodass Cache-Speicher zurückgewonnen und wiederverwendet werden kann, während der Baum wächst
  • Arbeitet zusammen mit Continuous Batching und seitenbasierter, blockweiser KV-Cache-Zuweisung, was es SGLang erlaubt, Anfragen laufend in einen aktiven Batch aufzunehmen und daraus zu entfernen

Was leisten die Frontend-DSL und Structured Output konkret?

SGLang bringt über das Kern-Serving hinaus zwei verwandte, aber getrennte Fähigkeiten mit: eine in Python eingebettete Frontend-Sprache zum Schreiben von LLM-Programmen, und die Durchsetzung strukturierter Ausgabeformate auf Engine-Ebene.

Die Frontend-DSL

SGLang bietet Python-Primitiven — darunter sgl.gen für Generierung, sgl.select für die Auswahl aus einer festen Menge von Optionen und sgl.fork für die Verzweigung in parallele Generierungspfade —, mit denen sich ein mehrstufiges LLM-Programm (zum Beispiel: einen Plan generieren, dann in mehrere parallele Teilgenerierungen verzweigen, dann Ergebnisse zusammenführen) als gewöhnlicher Python-Code ausdrücken lässt, wobei die Runtime Batching und Cache-Wiederverwendung über die Zweige hinweg automatisch übernimmt.

Structured Output auf Engine-Ebene

Gibt eine Anfrage ein JSON-Schema oder einen regulären Ausdruck vor, dem die Ausgabe entsprechen muss, setzt SGLang diesen Constraint innerhalb der Dekodierschleife durch, indem es die Logits jedes Tokens maskiert, das das Schema oder Muster an dieser Stelle verletzen würde — statt unbeschränkten Text zu generieren und ihn danach zu validieren oder erneut anzufragen. Das Projekt dokumentiert dafür eine interne, komprimierte Zustandsmaschinen-Darstellung, die es der Engine erlauben soll, mehrere Tokens in einem einzigen Forward-Pass zu dekodieren, wenn der Constraint eindeutig festlegt, was als Nächstes folgt.

Welche Hardware braucht SGLang?

SGLangs primäres und am besten unterstütztes Ziel sind NVIDIA-GPUs, und die meisten in eigenen Materialien beschriebenen Produktionseinsätze laufen auf NVIDIA-Hardware. Das Projekt dokumentiert außerdem weitere Backends, wobei Abdeckung und praktische Verbreitung nicht überall gleich sind.

NVIDIA-GPUs (CUDA)

Details:
Das primäre, ausgereifteste Ziel, von Rechenzentrums-GPUs bis zu aktuellen Consumer-/Workstation-Karten. Tensor-parallel-Serving über mehrere NVIDIA-GPUs ist gut dokumentiert.

AMD-GPUs (ROCm)

Details:
Als unterstütztes Backend für AMD-Instinct-Beschleuniger über ROCm dokumentiert, mit schmalerer praktischer Verbreitung und Community-Abdeckung als der CUDA-Pfad.

Intel-Xeon-CPUs und Gaudi-Beschleuniger

Details:
Zusätzliche, vom Projekt dokumentierte Backends für Intel-Hardware; als kleinerer, weniger erprobter Bereitstellungspfad als NVIDIA-GPUs zu behandeln.

Google TPUs und Ascend-NPUs

Details:
Dokumentierte Backends für Teams, die bereits auf Google-Cloud-TPU- oder Huawei-Ascend-Infrastruktur setzen.

Apple Silicon (Mac)

Details:
Kein erstklassiger, offiziell gepflegter Pfad. SGLang ist auf GPU-gestützte Rechenzentrums- und Workstation-Hardware ausgelegt, nicht auf lokale Nutzung auf einem einzelnen Mac.

Wer ein Modell auf einem einzelnen Mac oder einer reinen CPU-Maschine betreiben möchte, ist bei SGLang nicht richtig — llama.cpp und darauf aufbauende Tools wie Ollama und LM Studio zielen direkt auf CPU- und Apple-Silicon-Hardware und passen für dieses Szenario besser.

Welche Quantisierungsformate unterstützt SGLang?

SGLang unterstützt das Servieren von Modellen mit reduzierter numerischer Präzision, um den Speicherbedarf zu senken und in vielen Fällen den Durchsatz zu erhöhen, und dokumentiert dafür mehrere etablierte Quantisierungsformate.

FP8

Details:
8-Bit-Gleitkomma-Präzision, unterstützt auf NVIDIA-GPU-Generationen mit Hardware-FP8-Unterstützung, mit etwas geringerer Präzision gegen niedrigeren Speicherbedarf und schnellere Ausführung als FP16/BF16.

FP4

Details:
Ein neueres, noch niedriger auflösendes Gleitkommaformat, das das Projekt für die neueste Generation kompatibler NVIDIA-Hardware dokumentiert.

AWQ

Details:
Activation-aware Weight Quantization, eine weit verbreitete 4-Bit-Gewichtsquantisierungsmethode mit vorquantisierten Modellen, die von der Community auf Hugging Face veröffentlicht werden.

GPTQ

Details:
Eine Post-Training-Quantisierungsmethode, häufig als vorquantisierte Modell-Checkpoints verteilt, ebenfalls typischerweise mit 4-Bit-Präzision.

INT4

Details:
Ein niedriger auflösender Integer-Quantisierungspfad, den das Projekt neben AWQ und GPTQ für weitere Speicherreduktion dokumentiert.

Dieser Artikel enthält keine unabhängig gemessenen Qualitätsverlust-Zahlen für die einzelnen Formate — diese variieren je nach Modellarchitektur und Aufgabe, sodass der Vergleich von Ausgaben mehrerer Formate an den eigenen Prompts der zuverlässigste Weg ist, den Trade-off für die eigene Workload zu beurteilen.

Was bietet der OpenAI-kompatible SGLang-Server?

Der Befehl python -m sglang.launch_server startet einen HTTP-Server, der das OpenAI-API-Protokoll implementiert, sodass Anwendungen und SDKs, die bereits für die OpenAI-API gebaut sind, oft nur mit einer Änderung von Basis-URL und Modellname auf eine selbst gehostete SGLang-Instanz zeigen können.

  • OpenAI-kompatible Chat-Completions- und Completions-Endpunkte, nutzbar als Drop-in-Ersatz für auf der OpenAI-API basierenden Client-Code
  • Konfigurierbarer Host und Port (in den eigenen Beispielen des Projekts häufig http://localhost:30000)
  • Anfragebasierte Structured-Output-Parameter für JSON-Schema- und Regex-beschränkte Generierung, über die API verfügbar
  • Engine-Flags für Tensor-Parallel-Größe, Speicherzuweisung und Quantisierungsformat, beim Serverstart gesetzt
  • Unterstützung für das Servieren mehrerer LoRA-Adapter auf Basis eines einzigen geladenen Basismodells

Wie installiert und startet man SGLang?

SGLang wird als Python-Paket verteilt und typischerweise in eine Python-Umgebung mit einer NVIDIA-GPU und kompatiblen CUDA-Treibern installiert.

  1. 1
    Sicherstellen, dass eine unterstützte NVIDIA-GPU mit aktuellen CUDA-Treibern vorhanden ist (oder in der Projektdokumentation die AMD-/Intel-/TPU-spezifischen Installationsanweisungen prüfen, falls eines dieser Backends genutzt werden soll).
  2. 2
    Eine Python-Virtual-Environment anlegen und dann SGLang installieren, zum Beispiel: `pip install "sglang[all]"`.
  3. 3
    Den OpenAI-kompatiblen Server mit einem Modell von Hugging Face starten, zum Beispiel: python -m sglang.launch_server --model-path meta-llama/Llama-3.1-8B-Instruct --host 127.0.0.1 --port 30000.
  4. 4
    Eine einfache Chat-Anfrage mit einem beliebigen OpenAI-API-kompatiblen Client senden, etwa dem Python-Paket openai mit base_url="http://127.0.0.1:30000/v1".
  5. 5
    Für eine JSON-beschränkte Antwort ein JSON-Schema in den Structured-Output-Parametern der Anfrage übergeben, damit der Server das Schema während der Dekodierung durchsetzt, statt JSON nur im Prompt anzufordern.
  6. 6
    Für Multi-GPU-Serving ein Tensor-Parallel-Flag hinzufügen, zum Beispiel --tp-size 2, um das Modell auf zwei GPUs aufzuteilen.
  7. 7
    Bestehenden OpenAI-API-Client-Code nur durch Änderung von Basis-URL und Modellname auf den selbst gehosteten Server richten.

Brauche ich eine GPU, um SGLang auszuführen?

Für alles über bloßes Testen hinaus ja — SGLangs primäres, am besten unterstütztes Ziel sind NVIDIA-GPUs. Das Projekt dokumentiert weitere Beschleuniger-Backends, diese sind aber nicht der Haupt-Bereitstellungspfad.

Kann ich garantiert JSON-Ausgaben von SGLang bekommen?

Ja — ein JSON-Schema in den Structured-Output-Parametern der Anfrage übergeben, und SGLang setzt es während der Dekodierung durch, indem es Tokens maskiert, die das Schema verletzen würden, statt das Modell im Prompt nur um JSON zu bitten.

Wie schneidet SGLang im Vergleich zu vLLM ab?

SGLang und vLLM sind die beiden meistdiskutierten quelloffenen, GPU-gestützten LLM-Serving-Engines, beide Apache-2.0-lizenziert und auf Produktions-Serving für viele Nutzer statt Einzelnutzer-Desktop-Chat ausgerichtet. Beide Projekte veröffentlichen Benchmarks, die sich selbst günstig gegenüber dem jeweils anderen darstellen; dieser Artikel entscheidet diesen Vergleich nicht, sondern beschreibt das dokumentierte Design und die Aussagen jedes Projekts.

Zentrale Cache-Technik

SGLang:
RadixAttention — automatische, radix-baum-basierte KV-Cache-Wiederverwendung über Anfragen mit beliebigem gemeinsamem Präfix.
vLLM:
PagedAttention — seitengroße, nicht zusammenhängende KV-Cache-Blöcke, die Speicherverschwendung durch übermäßig reservierte Zuweisungen reduzieren.

Structured Output

SGLang:
JSON-Schema- und Regex-Durchsetzung auf Engine-Ebene ist ein zentrales, stark dokumentiertes Feature, aufgebaut auf einer komprimierten Zustandsmaschine.
vLLM:
Unterstützt ebenfalls Structured/Guided Decoding über integrierte Grammar-Backends, dokumentiert als Teil des breiteren Funktionsumfangs, nicht als Kernmerkmal.

Programmiermodell

SGLang:
Bringt zusätzlich zum API-Server eine in Python eingebettete Frontend-DSL (sgl.gen, sgl.select, sgl.fork) für mehrstufige LLM-Programme mit.
vLLM:
Wird primär als API-Server oder Python-Bibliotheksaufruf genutzt; bringt keine vergleichbare Programm-Authoring-DSL mit.

Ursprung

SGLang:
Forschung mit Bezug zur UC Berkeley, Stanford und der LMSYS-Organisation hinter Chatbot Arena.
vLLM:
Entstanden im UC-Berkeley-Sky-Computing-Lab.

Durchsatzangaben

SGLang:
Veröffentlicht Release-Benchmarks mit Beschleunigungsfaktoren für RadixAttention und JSON-Dekodierung auf bestimmten Workloads.
vLLM:
Veröffentlicht eigene Release-Benchmarks; beschreibt die Speichereffizienz-Begründung von PagedAttention statt einer einzigen universellen Geschwindigkeitszahl.

Kein Marketing-Benchmark eines der beiden Engines sollte als neutrales Urteil verstanden werden — beide stammen vom jeweiligen Projekt, das das für sich selbst besser aussehende Ergebnis erzielt hat, auf von diesem Projekt gewählten Workloads. Wenn Durchsatz entscheidungsrelevant ist, ist das Testen beider Engines mit dem eigenen Modell, der eigenen Hardware und dem eigenen Traffic-Muster zuverlässiger als jede einzelne Artikelzahl, einschließlich dieser hier.

Wie schneidet SGLang im Vergleich zu llama.cpp und TensorRT-LLM ab?

SGLang, llama.cpp und TensorRT-LLM stehen an unterschiedlichen Punkten auf der Skala zwischen Hardware-Flexibilität und Spitzenoptimierung.

SGLang

Details:
Apache-2.0-lizenziert, Python-basiert, aufgebaut um RadixAttention und Structured Output auf Engine-Ebene. Lädt Hugging-Transformers-kompatible Modelle direkt; NVIDIA-GPUs sind das primäre Ziel, mit weiteren dokumentierten Backends.
Artikel über SGLang (5)

Auch erwähnt in:

+1 weitere nicht angezeigt

llama.cpp

Details:
MIT-lizenzierte C/C++-Inference-Engine, aufgebaut um das GGUF-Modellformat, läuft auf CPU, Apple Silicon und GPU. Zielt auf Einzelgeräte- und Edge-Einsatz statt Multi-GPU-Produktionscluster.
Artikel über llama.cpp (10)

+167 weitere nicht angezeigt

TensorRT-LLM

Details:
NVIDIAs Engine, speziell für NVIDIA-GPUs gebaut. Modelle werden vorab in eine für die Ziel-GPU optimierte TensorRT-Engine kompiliert, was starke Leistung auf dieser spezifischen Hardware ermöglichen kann — auf Kosten eines Kompilierschritts und geringerer Hardware-Flexibilität als bei SGLang.
Artikel über TensorRT-LLM (6)

Auch erwähnt in:

+1 weitere nicht angezeigt

Dieser Artikel hat diese drei Engines nicht unabhängig gegeneinander benchmarkt und behauptet nicht, dass eine universell schneller ist — der Durchsatz hängt stark von Modell, Hardware, Batch-Eigenschaften und der jeweiligen Engine-Version ab. Siehe den Guide zu Enterprise-Inference-Servern für einen bereitstellungsorientierten Vergleich, der auch vLLM, TGI und NVIDIA NIM abdeckt.

Für wen ist SGLang geeignet?

SGLang passt zu Teams, die ein Modell für viele gleichzeitige Nutzer oder Anwendungen auf GPU-Infrastruktur bereitstellen — besonders bei Workloads mit wiederholten Prompt-Präfixen oder einer harten Anforderung an Structured Output —, nicht zu Personen, die den schnellsten Weg suchen, um auf dem eigenen Rechner mit einem Modell zu chatten.

SGLang nutzen, wenn

  • Sie ein LLM hinter einer API bereitstellen, die viele Nutzer oder nachgelagerte Dienste gleichzeitig aufrufen — besonders mit wiederholten System-Prompts, Few-Shot-Beispielen oder mehrstufigen Gesprächen
  • Ihre Anwendung garantiert JSON-Schema- oder Regex-konforme Ausgaben benötigt — Function Calling, Tool-Use-Agenten oder strukturierte Datenextraktion
  • Sie mehrstufige LLM-Programme (verzweigende Generierungen, parallele Teilaufrufe) über eine in Python eingebettete DSL schreiben möchten, statt einzelne API-Aufrufe selbst zu orchestrieren
  • Sie Zugriff auf eine oder mehrere NVIDIA-GPUs (oder eine unterstützte AMD-/Intel-/TPU-Bereitstellung) haben und einen selbst gehosteten, OpenAI-kompatiblen API-Server möchten
  • Sie mit Python-Umgebungen, Kommandozeilen-Konfiguration und GPU-/CUDA-Setup vertraut sind

SGLang vermeiden, wenn

  • Sie ein Modell auf dem eigenen Laptop oder Desktop für persönlichen Einzelnutzer-Chat betreiben möchten — Ollama oder LM Studio passen dafür deutlich besser
  • Sie keine unterstützte GPU haben — SGLang ist nicht auf CPU-only- oder Apple-Silicon-Hardware ausgelegt wie llama.cpp oder Ollama
  • Sie eine grafische Klick-Oberfläche statt eines API-Servers, einer Python-DSL und Kommandozeilen-Flags möchten
  • Ihre Workload keine wiederholten Prompt-Präfixe und keine Structured-Output-Anforderung hat — in diesem Fall bieten RadixAttention und Constrained Decoding kaum einen Vorteil gegenüber jeder anderen Serving-Engine

SGLang vs. Alternativen im Überblick

Diese Tools stehen an unterschiedlichen Punkten auf der Skala Einzelnutzer versus Produktions-Serving und auf der Skala Durchsatz versus Fokus auf Structured Output.

SGLang

Interface & Einrichtung:
Python-Paket; OpenAI-kompatibler API-Server, gestartet mit python -m sglang.launch_server. Erwartet in den meisten Bereitstellungen eine NVIDIA-GPU und CUDA.
Am besten für:
Hoch-nebenläufiges GPU-Serving mit starker Präfix-Wiederverwendung und/oder harter Anforderung an strukturierte (JSON/Regex) Ausgaben.
Artikel über SGLang (5)

Auch erwähnt in:

+1 weitere nicht angezeigt

vLLM

Interface & Einrichtung:
Python-Paket; OpenAI-kompatibler API-Server, gestartet mit vllm serve. Erwartet in den meisten Bereitstellungen eine NVIDIA-GPU und CUDA.
Am besten für:
Hochdurchsatz-GPU-Serving für viele Nutzer in der Produktion, allgemein, ohne Structured-Output-First-Design-Fokus.
Artikel über vLLM (10)

+84 weitere nicht angezeigt

Ollama

Interface & Einrichtung:
CLI und REST-API, auf den meisten Plattformen häufig berichtet auf llama.cpp als Backend. Ein Befehl installiert es; ein Befehl lädt und startet ein Modell.
Am besten für:
Den schnellsten Weg zu einem laufenden lokalen Modell für einen einzelnen Nutzer, ohne Build-Schritt oder GPU.
Artikel über Ollama (10)

+310 weitere nicht angezeigt

llama.cpp

Interface & Einrichtung:
CLI, eingebautes Web-UI und OpenAI-kompatible API über llama-server. Aus dem Quellcode bauen oder ein vorgefertigtes Binary nutzen; läuft auf CPU oder GPU.
Am besten für:
Direkte Kontrolle auf Engine-Ebene, Embedded-/Edge-Einsatz und CPU- oder Apple-Silicon-Hardware.
Artikel über llama.cpp (10)

+167 weitere nicht angezeigt

Dieser Artikel hat Geschwindigkeit oder Ausgabequalität dieser Tools nicht unabhängig benchmarkt und behauptet nicht, dass eines technisch überlegen ist — der Vergleich oben umfasst nur dokumentierte Architektur-, Einrichtungs- und Zugriffsmodell-Fakten. Siehe den Vergleich llama.cpp vs. Ollama vs. vLLM für einen dedizierten Durchsatz- und Einrichtungskomplexitäts-Vergleich dieser drei, und den Guide zu Enterprise-Inference-Servern für einen bereitstellungsorientierten Blick auf vLLM, TGI und NVIDIA NIM.

Im Verzeichnis vergleichen

Was deckt dieser Artikel nicht ab?

Dies ist ein Erklärartikel auf Basis von SGLangs öffentlicher Dokumentation und Repository, kein praktischer Benchmark-Bericht.

  • Keine unabhängig gemessenen Durchsatz-, Latenz- oder Anfragen-pro-Sekunde-Zahlen für SGLang oder die Vergleiche — diese hängen stark von GPU, Modell, Batch-Zusammensetzung und Version ab
  • Keine unabhängige Überprüfung der von SGLang selbst genannten Beschleunigungsfaktoren für RadixAttention oder JSON-Dekodierung — diese stammen aus den Release-Benchmarks des Projekts, nicht aus unabhängiger Messung
  • Kein zeilenweises Sicherheitsaudit der SGLang-Codebasis — sie ist quelloffen und Apache-2.0-lizenziert, der Code selbst ist also zur Überprüfung verfügbar
  • Keine vollständige Abdeckung jedes unterstützten Hardware-Backends, Engine-Flags oder Bereitstellungs-Orchestrierungsoption (Kubernetes, cloud-spezifische Setups) — dieser Artikel konzentriert sich auf die Konzepte und Flags, die die meisten Teams zuerst prüfen
  • Keine Abdeckung kommerzieller Support-Vereinbarungen oder verwalteter SGLang-Hosting-Angebote, da SGLang selbst ein Community-Open-Source-Projekt ist und kein Anbieterprodukt mit Support-Vertrag

Häufige Fehler beim Ausprobieren von SGLang

Die meiste Reibung mit SGLang entsteht dadurch, es wie ein Einzelnutzer-Desktop-Tool zu behandeln, oder davon auszugehen, dass RadixAttention einem Workload hilft, der gar keine Präfixe teilt.

Fehler 1: Der Versuch, es auf einem Laptop ohne dedizierte GPU auszuführen

SGLang ist nicht auf CPU-only- oder Apple-Silicon-Hardware ausgelegt wie llama.cpp oder Ollama. Der Versuch, es auf einem reinen CPU-Laptop oder einem Apple-Silicon-Mac auszuführen, führt typischerweise zu schlechter Leistung oder Einrichtungsproblemen, die ein speziell dafür gebautes lokales Tool ganz vermeiden würde.

Fehler 2: Erwarten, dass RadixAttention Traffic ohne geteilte Präfixe beschleunigt

Der Nutzen von RadixAttention entsteht speziell durch die Wiederverwendung von KV-Cache-Zuständen über Anfragen mit gemeinsamem Token-Sequenz-Präfix. Ist jede Anfrage im eigenen Workload vollständig unabhängig — unterschiedliche System-Prompts, keine Few-Shot-Beispiele, kein Gesprächsverlauf —, gibt es kaum ein geteiltes Präfix für RadixAttention zur Wiederverwendung, und der Gewinn gegenüber einer Engine ohne Caching fällt gering aus.

Fehler 3: JSON im Prompt anfordern statt die Structured-Output-Parameter zu nutzen

Ein Modell im Prompt zu bitten, „in JSON zu antworten", ohne SGLangs schemabeschränkte Dekodierparameter zu nutzen, lässt das Modell weiterhin fehlerhafte oder nicht konforme Ausgaben erzeugen. Der Zuverlässigkeitsvorteil von Structured Output auf Engine-Ebene gilt nur, wenn das JSON-Schema oder der Regex-Constraint tatsächlich über die Structured-Output-Felder der API übergeben wird.

Häufig gestellte Fragen

Was ist SGLang?

SGLang ist ein kostenloses, Apache-2.0-lizenziertes Serving-Framework für große Sprachmodelle und Vision-Language-Modelle, entstanden aus Forschung mit Bezug zur UC Berkeley, Stanford und der LMSYS-Organisation hinter Chatbot Arena. Es ist vor allem für RadixAttention bekannt, eine Technik zur automatischen KV-Cache-Wiederverwendung über Anfragen mit gemeinsamem Präfix.

Ist SGLang kostenlos?

Ja. SGLang ist kostenlose, quelloffene Software unter der Apache-2.0-Lizenz, ohne Abonnement oder Kontopflicht für den Eigenbetrieb.

Was ist RadixAttention?

RadixAttention ist SGLangs Technik, den Attention-KV-Cache abgeschlossener und laufender Anfragen in einem Radix-Baum zu speichern, sodass neue Anfragen mit gemeinsamem Token-Sequenz-Präfix — System-Prompt, Few-Shot-Beispiele oder frühere Gesprächsabschnitte — den passenden Cache automatisch wiederverwenden können, statt ihn neu zu berechnen.

Garantiert SGLang gültige JSON-Ausgaben?

Enthält eine Anfrage ein JSON-Schema in SGLangs Structured-Output-Parametern, maskiert die Engine bei jedem Dekodierschritt Tokens, die das Schema verletzen würden — das soll die Ausgabe durch Konstruktion statt durch nachträgliche Validierung schemakonform machen. Nur im Prompt-Text um JSON zu bitten, ohne diese Parameter zu nutzen, bietet diese Garantie nicht.

Braucht SGLang eine GPU?

Für jede reale Workload ja — SGLangs primäres, am besten unterstütztes Ziel sind NVIDIA-GPUs. Das Projekt dokumentiert AMD-, Intel- und weitere Beschleuniger-Backends, diese sind aber nicht der Haupt-Bereitstellungspfad, und es gibt keine erstklassige Apple-Silicon-Unterstützung.

Welche Quantisierungsformate unterstützt SGLang?

SGLang unterstützt mehrere Formate, darunter FP8, FP4 auf neuerer Hardware, AWQ, GPTQ und INT4, mit vielen vorquantisierten Modellen in diesen Formaten auf Hugging Face.

Ist SGLang besser als vLLM?

Die eigenen Benchmarks keines der beiden Projekte sind ein neutrales Urteil dazu — beide veröffentlichen für sich selbst günstige Ergebnisse. SGLang stellt RadixAttentions präfixbasierte Cache-Wiederverwendung und Structured Output auf Engine-Ebene als Kernmerkmale heraus; vLLM stellt die Speichereffizienz von PagedAttention heraus. Was besser passt, hängt vom Präfix-Teilungsmuster der eigenen Workload und davon ab, ob Structured Output eine harte Anforderung ist — siehe die Vergleichstabelle oben.

Hat SGLang eine OpenAI-kompatible API?

Ja. Der Befehl python -m sglang.launch_server startet einen Server, der das OpenAI-API-Protokoll implementiert, sodass viele für die OpenAI-API gebaute Anwendungen nur mit einer Änderung von Basis-URL und Modellname auf eine selbst gehostete SGLang-Instanz zeigen können.

Wofür wird die SGLang-Frontend-DSL genutzt?

Es handelt sich um eine Reihe von Python-Primitiven — darunter sgl.gen, sgl.select und sgl.fork — zum Schreiben mehrstufiger LLM-Programme, etwa Verzweigen in mehrere parallele Teilgenerierungen und Zusammenführen der Ergebnisse, als gewöhnlicher Python-Code statt manueller Orchestrierung einzelner API-Aufrufe.

Wer hat SGLang entwickelt, und was ist RadixArk?

SGLang entstand aus Forschung, die UC Berkeley, Stanford und die LMSYS-Organisation hinter Chatbot Arena verbindet. 2026 gruendeten SGLang-Mitentwickler Ying Sheng und Banghua Zhu das KI-Infrastruktur-Startup RadixArk, das unter Fuehrung von Accel eine Seed-Finanzierung von 100 Millionen US-Dollar erhielt, um Dienstleistungen rund um SGLang zu kommerzialisieren — das Kern-Framework bleibt dabei Apache-2.0-lizenziert und kostenlos.

Quellen

← Zurück zu Lokale LLMs Pro

MCP