SGLang: ein lokales LLM für mehrere utilisateurs

#Was SGLang macht

SGLang präsentiert sich als Hochleistungsframework für die Bereitstellung von LLMs und multimodalen Modellen, ausgelegt auf Inferenz mit geringer Latenz und hohem Durchsatz – von einer einzelnen GPU bis hin zu großen verteilten Clustern. Das Projekt gibt an, dass seine Produktionsdeployments täglich Trillionen von Tokens auf weltweit mehr als 400.000 GPUs erzeugen, und ist bei der gemeinnützigen Open-Source-Organisation LMSYS angesiedelt.

SGLang ist mit den APIs von OpenAI und Hugging Face kompatibel und unterstützt eine breite Palette an Modellen (Llama, Qwen, DeepSeek, GLM, Mistral, Gemma) und Hardware (NVIDIA- und AMD-GPUs, Intel-Xeon-CPUs, Google-TPUs, Ascend-NPUs). Mit Stand vom 28. September 2026 ist v0.5.20 die neueste Version, veröffentlicht am 18. September 2026.

#Den Server installieren und starten

Die von der offiziellen Dokumentation empfohlene Installation erfolgt über uv, das schneller ist als das klassische pip. Das Flag --prerelease=allow ist erforderlich, da einige Abhängigkeiten von SGLang nur Vorabversionen auf PyPI veröffentlichen.

pip install --upgrade pip
pip install uv
uv pip install --prerelease=allow sglang

Der Container-Start mit Docker bleibt die reproduzierbarste Methode für eine Serverbereitstellung, wobei standardmäßig der Port 30000 für die API verwendet wird.

docker run --gpus all \
    --shm-size 32g \
    -p 30000:30000 \
    -v ~/.cache/huggingface:/root/.cache/huggingface \
    --env "HF_TOKEN=<secret>" \
    --ipc=host \
    lmsysorg/sglang:latest \
    python3 -m sglang.launch_server --model-path meta-llama/Llama-3.1-8B-Instruct --host 0.0.0.0 --port 30000

Die Dokumentation stellt klar, dass SGLang inzwischen CUDA 13 erfordert: Images und Wheels für CUDA 12 (cu129) wurden entfernt, seit PyTorch 2.14 keinen Build für CUDA 12.9 mehr veröffentlicht. Version 0.5.19 bleibt die letzte, die eine Möglichkeit zur Nutzung von CUDA 12 bietet. Bei einer Bereitstellung auf älterer Hardware muss daher diese Version festgeschrieben oder vor dem Update der GPU-Treiber überprüft werden.

#RadixAttention und der Präfix-Cache

Das Herz der Leistungsversprechen von SGLang ist RadixAttention: Die bereits berechneten Sequenzvorgänge (ein gemeinsamer Systemprompt, der Anfang einer mehrfach-Dialogkonversation) werden in einem Radix-Baum organisiert und zwischen Anfragen wiederverwendet, anstatt jedes Mal neu berechnet zu werden. Die ursprüngliche Projektmitteilung im Januar 2024 behauptete bis zu 5-fach schnellere Inferenz durch dieses Mechanismus – eine Angabe aus dem eigenen Testsetup der damaligen Zeit, keine aktuelle, unabhängige Messung auf Ihrem Gerät.

Dieser Gewinn kommt vor allem Szenarien mit gemeinsamen Präfixen zugute: mehreren Nutzern, deren Anfragen denselben System-Prompt verwenden, einem Agenten, der bei jeder Runde denselben Kontext erneut liest, oder Few-Shot-Prompts mit denselben Beispielen. Ein Strom von Anfragen ohne jegliches gemeinsames Präfix (völlig unabhängige Fragen ohne Verlauf) profitiert deutlich weniger von RadixAttention.

Die Laufzeitumgebung kombiniert RadixAttention mit einem CPU-Scheduler ohne Overhead, Prefill-Decode-Disaggregation, spekulativem Decoding, kontinuierlicher Anfragenplanung (continuous batching) und paginierter Attention (paged attention) – eine Kombination mehrerer Optimierungstechniken statt eines isolierten Mechanismus.

#Parallelität und Speicher einstellen

Drei Startparameter bestimmen, wie SGLang mehrere Benutzer gleichzeitig bedient. --mem-fraction-static legt den Anteil des GPU-Speichers fest, der für die Modellgewichte und den KV-Cache reserviert ist; die Dokumentation empfiehlt, diesen Anteil bei einem Fehler wegen erschöpften Speichers zu reduzieren, andernfalls wird er automatisch anhand des verfügbaren GPU-Speichers berechnet.

Ohne explizite Begrenzung für --max-running-requests nimmt SGLang so viele Anfragen an, wie der Speicher des KV-Caches zulässt. Das kann unter hoher Last die Latenz pro Anfrage verschlechtern, statt neue Verbindungen höflich abzulehnen. Eine explizite Begrenzung festzulegen, die zur verfügbaren VRAM passt, ist die erste Einstellung, die vorgenommen werden sollte, bevor der Server für mehrere tatsächliche Nutzer zugänglich gemacht wird.

#Wann SGLang statt vLLM oder Ollama wählen?

Die drei Werkzeuge erfüllen unterschiedliche Anforderungen. Ollama richtet sich an die persönliche Nutzung durch einen einzelnen Benutzer und erfordert nur eine minimale Einarbeitung; SGLang und vLLM zielen auf die Bereitstellung für mehrere Benutzer auf Server-GPUs ab, mit ähnlichen Ansätzen (Präfix-Cache, kontinuierliches Batching), aber unterschiedlichen Entwicklungsgeschichten und Ökosystemen.

Ein einzelner Benutzer, persönlicher Rechner

Ollama oder llama.cpp lassen sich weiterhin einfacher installieren und auf handelsüblichen CPUs oder GPUs betreiben, ohne einen Netzwerkdienst konfigurieren zu müssen.

Mehrere Benutzer, System bereits auf vLLM aufgebaut

Bei vLLM zu bleiben erspart eine Migration; unser spezieller Leitfaden behandelt dessen Bereitstellung in der Produktion.

Mehrere Benutzer, Priorität auf Durchsatz bei gemeinsam genutzten Präfixen

SGLang mit RadixAttention ist die naheliegende Wahl – vorausgesetzt, Sie verfügen über eine kompatible CUDA-GPU.

Kompatibilität mit Ollama-Clients gewünscht, ohne Ollama zu installieren

SGLang stellt eine API bereit, die mit der Ollama-CLI und der Python-Bibliothek von Ollama kompatibel ist. Dadurch lassen sich bestehende Skripte wiederverwenden, ohne den Ollama-Server selbst betreiben zu müssen.

Für einen breiteren Überblick über Inferenzarchitekturen (llama.cpp, vLLM, Exllama) erläutert der Backend-Vergleich auf dieser Website die Kompromisse über den Einzelfall SGLang hinaus.

#Was die Hardware vorgibt

Der Schnellstartleitfaden von SGLang ist eindeutig: Eine NVIDIA-GPU mit Unterstützung für CUDA sm80 oder höher (A10, A100, L4, L40S, H100) ist Voraussetzung für den standardmäßigen Installationsweg unter Linux, der empfohlenen Plattform. Darüber hinaus kündigt das Projekt eine breitere Hardwareunterstützung an – AMD-GPUs (MI355, MI300), Intel-Xeon-CPUs, Google-TPUs und Ascend-NPUs – über eigene Installationswege, die vom Hauptinstallationsweg für NVIDIA-GPUs getrennt sind.

#Speicherbedarf pro Anfrage

„Mehrere Nutzer bedienen“ bedeutet ganz konkret, dass der VRAM-Verbrauch mit der Anzahl aktiver Anfragen wächst, nicht nur mit der Modellgröße. Der von --mem-fraction-static und --max-total-tokens verwaltete KV-Cache speichert für jedes bereits generierte Token einer Anfrage zwei Vektoren (Schlüssel und Wert) pro Attention-Schicht. Die allgemeine Formel lautet: Bytes pro Token = 2 × Anzahl der Schichten × Anzahl der KV-Attention-Heads × Dimension eines Heads × Bytes pro Wert (2 bei FP16/BF16, 1 bei FP8).

Beispielrechnung für eine Architektur ähnlich wie Llama-3.1-8B-Instruct (32 Schichten, 8 KV-Köpfe bei gruppierter Attention, Kopfdimension 128): In FP16 ergibt das 2 × 32 × 8 × 128 × 2 = 131.072 Byte pro Token, also etwa 128 KB pro Token. Bei einer Anfrage mit 8.192 Tokens Kontext (Prompt und Antwort zusammen) belegt der KV-Cache dieser einen Anfrage somit etwa 1 GB VRAM — noch bevor die Modellgewichte berücksichtigt werden. Auf einer GPU mit 24 GB, von denen etwa 16 GB für die Gewichte in Q4 und den grundlegenden Speicherbedarf der Laufzeitumgebung reserviert sind, reicht der verbleibende Spielraum bei dieser Kontextlänge nur für wenige gleichzeitig aktive Anfragen. Das erklärt, warum eine explizite Begrenzung über --max-running-requests eine Verschlechterung verhindert, statt neue Verbindungen sauber abzulehnen.

#Sicherheit und Observabilität

Standardmäßig erfordert die mit sglang.launch_server gestartete SGLang-API keine Authentifizierung: Jeder, der Port 30000 erreichen kann, kann Anfragen senden. Die Option --api-key legt einen Schlüssel fest, den der Server auch an seinem OpenAI-kompatiblen Endpunkt verlangt; ohne diese Option bedeutet ein Zugriff auf den Server über localhost oder ein vertrauenswürdiges internes Netzwerk hinaus, dass die Inferenz offen zugänglich ist und damit auch die zugehörigen GPU-Kosten verursacht werden können.

Für die Überwachung im Produktionsbetrieb stellt die Option --enable-metrics (standardmäßig deaktiviert) Metriken im Prometheus-Format am Endpunkt /metrics bereit: Anfragerate, Inferenzlatenz, Geschwindigkeit der Tokengenerierung und Cache-Effizienz lassen sich dort regelmäßig per Scraping erfassen, statt den Serverzustand allein anhand der Protokolle zu erraten.

• Grundsätze zur Absicherung eines von außen erreichbaren Inferenzservers
• Quelle: Referenz der Serverargumente (--api-key, --enable-metrics)

#Troubleshooting: Symptome, Ursache, Lösung

#Grenzen und Punkte, auf die Sie achten sollten

Die Angabe „bis zu 5x schneller“, die die Vorstellung von RadixAttention weiterhin begleitet, stammt aus der ursprünglichen Ankündigung des Projekts im Januar 2024: Sie veranschaulicht den Nutzen des Mechanismus auf dem damaligen Testsystem, keinen garantierten Leistungsgewinn bei einem aktuellen Einsatz mit anderen Modellen und GPUs. Die tatsächliche Dimensionierung hängt davon ab, wie häufig Anfragen gemeinsame Präfixe haben, welches Modell gewählt und welche GPU verwendet wird — anhand des eigenen Anfrageaufkommens messen, statt sie aus der ursprünglichen Ankündigung abzuleiten.

Der zwingende Umstieg auf CUDA 13 (Version 0.5.19 ist die letzte, die eine CUDA-12-Option bietet) macht es ratsam, vor jedem Update auf eine neuere Version den GPU-Treiber und die installierte CUDA-Version zu prüfen. Andernfalls kann die Installation auf einem Server, der noch CUDA 12 verwendet, fehlschlagen.

Auch der Veröffentlichungsrhythmus des Projekts ist bei einem Produktivdeployment zu beachten: SGLang veröffentlicht etwa alle zwei bis drei Wochen neue Minor-Versionen (v0.5.20 am 18. September 2026, v0.5.19 am 5. September, v0.5.18 am 22. August). Deshalb muss in den Docker-Images eine bestimmte Version festgelegt werden, statt bei einem Dienst im Produktivbetrieb dem Tag latest zu folgen. Andernfalls besteht bei einem erneuten Deployment das Risiko einer nicht vorhergesehenen Verhaltensänderung.

• vLLM in der Produktion einsetzen
• vLLM: Was ist das, für wen eignet es sich und wann sollte man es nutzen?
• llama.cpp vs. vLLM vs. Exllama
• Quelle: offizielle Dokumentation von SGLang
• Quelle: offizielle README-Datei des SGLang-Repositorys
• Quelle: Referenz der Serverargumente