Wer im September 2026 ein eigenes Sprachmodell im Unternehmen betreiben will, stößt schnell auf ein Problem: Ollama und LM Studio sind für den Einzelplatz gebaut, nicht für hundert gleichzeitige Anfragen. Genau hier setzt SGLang an. Das Open-Source-Projekt der University of California, Berkeley und der sgl-project-Community hat sich in eineinhalb Jahren von 10.000 auf über 33.000 GitHub-Sterne hochgearbeitet und wird laut PyPIStats.org mit rund 77 Millionen Downloads pro Monat installiert. Dieses Tutorial zeigt, wie Sie SGLang Schritt für Schritt installieren, einen ersten Server starten, die OpenAI-kompatible API testen und ein vollständiges Chat-Projekt aufsetzen.

Für IT-Abteilungen in Deutschland, Österreich und der Schweiz hat lokales LLM-Serving noch einen zweiten Vorteil neben der reinen Kostenfrage: Anfragen und Modellantworten verlassen das eigene Rechenzentrum nicht. Wer aus Datenschutzgründen keine Prompts an US-Cloud-APIs schicken darf, etwa bei Kundendaten oder internen Dokumenten, kommt an einem selbst gehosteten Serving-Layer kaum vorbei. Ollama eignet sich dafür auf dem Entwicklerlaptop hervorragend, stößt aber an Grenzen, sobald mehrere Abteilungen gleichzeitig auf denselben Endpunkt zugreifen. SGLang schließt genau diese Lücke zwischen Experimentierumgebung und Produktionsbetrieb, ohne dass Sie dafür auf eine kommerzielle Serving-Plattform umsteigen müssen.

Was ist SGLang und warum lohnt sich der Umstieg?

SGLang steht für “Structured Generation Language” und ist laut eigener GitHub-Beschreibung ein Hochleistungs-Serving-Framework für große Sprachmodelle und multimodale Modelle. Das Projekt liegt unter der Apache-2.0-Lizenz, ist in Python geschrieben und lebt in der GitHub-Organisation sgl-project. Am 5. September 2026 erschien Version 0.5.19, die aktuellste stabile Version zum Zeitpunkt dieses Artikels. Anders als Ollama oder LM Studio, die auf einfache lokale Nutzung zielen, optimiert SGLang gezielt den Durchsatz bei vielen parallelen Requests. Das macht das Tool zur ersten Wahl, wenn ein Modell nicht nur auf dem eigenen Laptop laufen soll, sondern als interner API-Dienst für ein Team oder eine Produktionsanwendung dient.

Entstanden ist SGLang ursprünglich als Forschungsprojekt zur strukturierten Steuerung von Sprachmodell-Ausgaben, hat sich seither aber zu einer vollständigen Serving-Infrastruktur weiterentwickelt, die von Forschungsteams ebenso genutzt wird wie von Unternehmen mit produktiven Chat- und Agenten-Anwendungen. Der Name spiegelt diesen Ursprung wider: Die ursprüngliche Idee war eine Domain-Specific Language für komplexe, mehrstufige Prompt-Programme, aus der sich der heutige Fokus auf effizientes Serving entwickelte. Diese Historie erklärt auch, warum SGLang neben reinem Chat-Completion-Serving zusätzliche Primitiven für strukturierte Ausgaben wie JSON-Schemas oder reguläre Ausdrücke mitbringt, die bei reinen Inferenz-Servern wie einer einfachen Ollama-Instanz fehlen.

Die Wachstumszahlen bestätigen den Trend. Laut star-history.com lag SGLang Ende August 2026 bei 32.600 bis 35.500 Sternen und belegte damit Rang 894 bis 1025 unter allen GitHub-Projekten. GitStarClub zählte im Februar 2025 erst 10.000 Sterne, im Mai 2026 waren es bereits 28.400. Wer heute mit dem Aufbau eines eigenen LLM-Serving-Stacks beginnt und dabei nicht auf Cloud-APIs wie die von OpenAI angewiesen sein will, landet fast zwangsläufig bei SGLang oder dessen direktem Konkurrenten vLLM. Beide Projekte werden in diesem Tutorial später im Detail verglichen.

Ein weiterer Grund für den Aufstieg von SGLang liegt im Ökosystem drumherum. Das Projekt bringt eine eigene Dokumentation unter docs.sglang.ai mit, die Release für Release aktualisiert wird, und pflegt ein aktives Discord für Support-Fragen. Enterprisedna listete SGLang im Juni 2026 mit 28.885 Sternen in seinem Open-Source-Verzeichnis für LLM-Infrastruktur, was zeigt, dass das Projekt inzwischen auch außerhalb der reinen GitHub-Community wahrgenommen wird. Für Teams, die zuvor mit Flowise experimentiert haben, ist zudem relevant, dass dieses Projekt am 13. August 2026 archiviert wurde und keine neuen Updates mehr erhält. Wer also gerade nach einer Alternative für produktives LLM-Serving sucht, hat mit SGLang und vLLM zwei aktiv gepflegte Optionen zur Auswahl.

Welche Modelle unterstützt SGLang?

SGLang ist kein Framework für ein einzelnes Modell, sondern eine generische Serving-Schicht. Laut eigener Dokumentation deckt das Projekt eine breite Palette gängiger offener Modellfamilien ab, darunter Llama, Qwen, Mistral, Gemma und DeepSeek, sowie ausgewählte multimodale Vision-Language-Modelle wie LLaVA. Neue Modellarchitekturen werden meist innerhalb weniger Wochen nach ihrer Veröffentlichung unterstützt, da die Community aktiv an Adaptern für neue Architekturen arbeitet. Das unterscheidet SGLang von proprietären Serving-Lösungen, bei denen Nutzer auf die Modellauswahl des jeweiligen Anbieters angewiesen sind.

Für die Praxis bedeutet das: Bevor Sie sich auf ein bestimmtes Modell festlegen, lohnt sich ein kurzer Blick in die aktuelle Modell-Kompatibilitätsliste der offiziellen Dokumentation, da nicht jede Modellvariante jede SGLang-Funktion wie Quantisierung oder Tool-Calling in gleichem Umfang unterstützt. Wer regelmäßig zwischen verschiedenen Modellen wechseln will, etwa um Antwortqualität zu vergleichen, kann mehrere SGLang-Instanzen mit unterschiedlichen --model-path-Werten parallel auf verschiedenen Ports betreiben und über den in diesem Tutorial gezeigten FastAPI-Proxy ansteuern.

Voraussetzungen: Hardware, Software und Accounts

Bevor Sie loslegen, sollten Sie die folgenden Punkte abhaken. SGLang ist kein Tool für den Feierabend-Laptop ohne Grafikkarte, sondern erwartet echte GPU-Rechenleistung. Community-Berichte und die Projektdokumentation nennen übereinstimmend folgende Mindestanforderungen für einen funktionierenden Serving-Betrieb.

KomponenteMindestanforderungEmpfehlung für Produktion
BetriebssystemLinux (Ubuntu 22.04+)Ubuntu 24.04 LTS
Python3.103.11 oder 3.12
GPUNVIDIA, CUDA-fähig (sm75+)NVIDIA A100 oder H100
CUDA-Toolkit12.x12.4 oder neuer
GPU-Speicher16 GB VRAM (für 7B/8B-Modelle)80 GB VRAM (für 70B-Modelle)
RAM32 GB128 GB+
SGLang-Version0.5.19 (Stand 05.09.2026)jeweils aktuellste Release

Zusätzlich brauchen Sie einen Hugging-Face-Account, falls das gewünschte Modell wie Llama 3.1 gated ist, sowie ein aktuelles NVIDIA-Treiberpaket. Prüfen Sie vorab mit nvidia-smi, ob Ihre Treiber und die installierte CUDA-Version zusammenpassen. Wer keine eigene GPU besitzt, kann alternativ eine gemietete H100- oder A100-Instanz bei einem Cloud-Anbieter nutzen. Für dieses Tutorial gehen wir von einer einzelnen NVIDIA-GPU mit mindestens 24 GB VRAM aus, was für ein 8B-Modell wie Llama 3.1 8B Instruct in der Regel ausreicht.

Wichtig ist außerdem die Netzwerkanbindung, falls Sie SGLang auf einer gemieteten Cloud-GPU betreiben und von einem anderen Standort aus zugreifen. Rechnen Sie bei großen Modellen mit Downloads zwischen 15 und 140 Gigabyte für die Modellgewichte, je nach Parametergröße und Quantisierung. Eine schnelle Internetverbindung spart hier beim ersten Start viel Wartezeit. Prüfen Sie zudem, ob genügend freier Festplattenspeicher vorhanden ist, denn der Hugging-Face-Cache legt heruntergeladene Gewichte standardmäßig unter ~/.cache/huggingface ab und wächst mit jedem zusätzlichen Modell weiter an.

RadixAttention erklärt: Warum SGLang schneller serviert

Der technische Kern von SGLang heißt RadixAttention. Dahinter steckt ein radix-baumbasiertes Caching des Key-Value-Speichers, das gemeinsame Prompt-Präfixe über mehrere Anfragen hinweg wiederverwendet. In der Praxis bedeutet das: Wenn zehn Nutzer dieselbe Systemanweisung oder denselben Dokumentenkontext mitschicken, muss das Modell diesen Teil nicht zehnmal neu durchrechnen. Der Cache erkennt den gemeinsamen Anfang und berechnet nur den abweichenden Teil neu.

Das zahlt sich besonders bei drei Workload-Typen aus: Chat-Anwendungen mit wiederkehrenden Systemprompts, Retrieval-Augmented-Generation-Pipelines mit ähnlichen Dokumentenausschnitten (mehr dazu im RAG-Pipeline-Tutorial) und Agenten-Frameworks, die denselben Tool-Kontext wiederholt an das Modell schicken. Laut dem offiziellen Benchmark-Repository von SGLang führt dieser Ansatz bei Llama 3.1 8B Instruct auf vier H100-GPUs zu einer medianen Zeit bis zum ersten Token (TTFT) von 35,68 Millisekunden bei acht Requests pro Sekunde, während eine vergleichbare vLLM-Konfiguration im selben Test 120,39 Millisekunden benötigte. Diese Zahl ist der Hauptgrund, warum viele Teams beim Aufbau eines produktiven Serving-Stacks zu SGLang wechseln, nachdem sie zunächst mit vLLM gestartet sind.

Technisch betrachtet organisiert RadixAttention den KV-Cache als Baumstruktur statt als flache Liste unabhängiger Sequenzen. Jeder Knoten im Baum repräsentiert ein Präfix-Segment, das mehrere laufende Anfragen gemeinsam nutzen können. Trifft eine neue Anfrage ein, sucht der Scheduler zunächst den längsten bereits gecachten gemeinsamen Präfix und hängt nur den neuen Teil an. Läuft der Speicher voll, entfernt SGLang die am längsten nicht genutzten Blätter des Baums, ähnlich einem klassischen LRU-Cache. Für Entwickler bedeutet das: Sie müssen keinen eigenen Cache bauen oder verwalten, das Verhalten ist bereits Teil des Schedulers und lässt sich über die Kontextlänge und den Speicheranteil nur indirekt beeinflussen.

Schritt 1 bis 3: Systemvorbereitung und Python-Umgebung

Die ersten drei Schritte legen das Fundament. Überspringen Sie hier keinen Punkt, denn eine falsche CUDA- oder Python-Version ist die häufigste Fehlerquelle bei der SGLang-Installation.

Schritt 1: CUDA und Treiber prüfen

Öffnen Sie ein Terminal und kontrollieren Sie, ob Ihre GPU erkannt wird und welche CUDA-Version der Treiber unterstützt.

nvidia-smi
# Erwartete Ausgabe zeigt u.a.:
# Driver Version: 550.xx    CUDA Version: 12.4
nvcc --version

Falls nvcc nicht gefunden wird, ist meist nur der Treiber installiert, nicht aber das vollständige CUDA-Toolkit. Für SGLang reicht in den meisten Fällen der Treiber allein, da die PyPI-Pakete eigene CUDA-Bibliotheken mitbringen. Ein vollständiges Toolkit brauchen Sie nur, wenn Sie eigene Kernel kompilieren wollen.

Schritt 2: Virtuelle Python-Umgebung anlegen

Isolieren Sie die Installation in einer eigenen virtuellen Umgebung, damit SGLang nicht mit anderen Projekten auf Ihrem System kollidiert.

python3 --version
python3 -m venv ~/sglang-env
source ~/sglang-env/bin/activate
pip install --upgrade pip

Schritt 3: SGLang installieren

Mit aktivierter Umgebung installieren Sie SGLang samt aller optionalen Abhängigkeiten über das Erweiterungspaket [all]. Das zieht unter anderem FlashInfer, PyTorch und die Serving-Komponenten mit.

pip install "sglang[all]"
python3 -c "import sglang; print(sglang.__version__)"
# Erwartete Ausgabe: 0.5.19

Die Installation dauert je nach Internetverbindung und GPU-Treiber-Kompatibilität zwischen fünf und fünfzehn Minuten, da PyTorch mit CUDA-Unterstützung mehrere Gigabyte an Paketen umfasst. Prüfen Sie danach unbedingt die importierte Version, denn abweichende Nummern deuten meist auf eine parallel installierte alte Version in einer anderen Umgebung hin.

Schritt 4 bis 6: Server starten und erstes Modell laden

Schritt 4: Modell auswählen

Für den Einstieg eignet sich Llama 3.1 8B Instruct, weil es auf einer einzelnen 24-GB-GPU läuft und gut dokumentierte Benchmarks besitzt. Falls das Modell auf Hugging Face als gated markiert ist, melden Sie sich vorher mit huggingface-cli login an und akzeptieren die Lizenzbedingungen im Browser.

pip install huggingface_hub
huggingface-cli login

Schritt 5: Server starten

Jetzt starten Sie den SGLang-Server mit dem gewählten Modell auf Port 30000. Der erste Start lädt die Modellgewichte herunter und legt sie im lokalen Hugging-Face-Cache ab.

python -m sglang.launch_server \
  --model-path meta-llama/Meta-Llama-3.1-8B-Instruct \
  --port 30000

Eine erfolgreiche Ausgabe endet mit einer Zeile ähnlich zu Uvicorn running on http://0.0.0.0:30000. Von hier an läuft der Server im Vordergrund und wartet auf Anfragen. Für einen dauerhaften Betrieb starten Sie ihn später als systemd-Dienst, siehe Schritt 12.

Schritt 6: Health-Check durchführen

Öffnen Sie ein zweites Terminal und prüfen Sie, ob der Server erreichbar ist, bevor Sie mit der API weitermachen.

curl http://localhost:30000/health
# Erwartete Ausgabe: {"status":"ok"}
# oder ein leerer 200-Response ohne Fehlermeldung

Schritt 7 bis 9: OpenAI-kompatible API nutzen und testen

Schritt 7: Direkten API-Aufruf per curl testen

SGLang stellt standardmäßig eine zur OpenAI-API kompatible Schnittstelle unter /v1 bereit. Das erlaubt es, bestehenden Code, der ursprünglich für die OpenAI-API geschrieben wurde, ohne Änderungen gegen den eigenen Server laufen zu lassen.

curl http://localhost:30000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "meta-llama/Meta-Llama-3.1-8B-Instruct",
    "messages": [{"role": "user", "content": "Erkläre RadixAttention in zwei Sätzen."}],
    "temperature": 0.3
  }'

Die Antwort kommt als JSON-Objekt mit einem choices-Array zurück, exakt im gleichen Format, das auch die offizielle OpenAI-API liefert. Das macht den Umstieg für Teams einfach, die bereits mit der OpenAI-API oder Anthropics Claude API gearbeitet haben.

Schritt 8: Python-Client mit dem offiziellen OpenAI-SDK

Statt curl können Sie das offizielle Python-SDK von OpenAI verwenden und lediglich die Basis-URL umbiegen.

pip install openai

python3 << 'EOF'
from openai import OpenAI

client = OpenAI(base_url="http://localhost:30000/v1", api_key="kein-schluessel-noetig")

response = client.chat.completions.create(
    model="meta-llama/Meta-Llama-3.1-8B-Instruct",
    messages=[{"role": "user", "content": "Nenne drei Vorteile von RadixAttention."}],
    temperature=0.3,
)
print(response.choices[0].message.content)
EOF

Schritt 9: Streaming-Antworten aktivieren

Für Chat-Oberflächen ist Streaming Pflicht, damit Nutzer Token für Token eine Antwort sehen statt auf den kompletten Text zu warten. Setzen Sie dafür stream=True.

stream = client.chat.completions.create(
    model="meta-llama/Meta-Llama-3.1-8B-Instruct",
    messages=[{"role": "user", "content": "Zähle von 1 bis 5 auf Deutsch."}],
    stream=True,
)
for chunk in stream:
    delta = chunk.choices[0].delta.content or ""
    print(delta, end="", flush=True)

Schritt 10 bis 12: Multi-GPU-Serving und Produktivbetrieb

Schritt 10: Tensor-Parallelismus für größere Modelle

Für ein 70B-Modell reicht eine einzelne GPU nicht aus. SGLang verteilt das Modell dann per Tensor-Parallelismus über mehrere GPUs. Der Parameter --tp gibt die Anzahl der GPUs an, über die das Modell aufgeteilt wird.

python -m sglang.launch_server \
  --model-path meta-llama/Meta-Llama-3.1-70B-Instruct \
  --tp 4 \
  --port 30000

Laut dem offiziellen SGLang-Benchmark-Repository erreicht diese Konfiguration mit vier H100-80G-GPUs bei unbegrenzter Anfragerate und 5000 Prompts einen Durchsatz von 19,84 Requests pro Sekunde und 3856,01 Output-Token pro Sekunde. Zum Vergleich lag vLLM in derselben Testumgebung bei 19,04 Requests pro Sekunde und 3700,64 Token pro Sekunde.

Schritt 11: Speicheranteil und Kontextlänge feinjustieren

Ein häufiges Problem bei knappem VRAM ist ein zu großzügig reservierter statischer Speicheranteil. Der Parameter --mem-fraction-static steuert, wie viel des GPU-Speichers SGLang für Gewichte und KV-Cache reserviert.

python -m sglang.launch_server \
  --model-path meta-llama/Meta-Llama-3.1-8B-Instruct \
  --mem-fraction-static 0.85 \
  --context-length 8192 \
  --port 30000

Schritt 12: Als systemd-Dienst für den Dauerbetrieb einrichten

Damit der Server einen Neustart des Rechners übersteht, richten Sie ihn als systemd-Dienst ein statt ihn manuell im Terminal laufen zu lassen.

sudo tee /etc/systemd/system/sglang.service << 'EOF'
[Unit]
Description=SGLang LLM Serving
After=network.target

[Service]
User=sglang
WorkingDirectory=/home/sglang
ExecStart=/home/sglang/sglang-env/bin/python -m sglang.launch_server --model-path meta-llama/Meta-Llama-3.1-8B-Instruct --port 30000 --mem-fraction-static 0.85
Restart=on-failure

[Install]
WantedBy=multi-user.target
EOF

sudo systemctl daemon-reload
sudo systemctl enable --now sglang
sudo systemctl status sglang

Vollständiges Projekt: Ein eigener Chat-Service mit SGLang

Mit den zwölf Schritten läuft ein produktiver SGLang-Server. Für ein vollständiges Projekt fehlt noch eine schlanke Anwendungsschicht, die Anfragen entgegennimmt und an SGLang weiterreicht. Das folgende Beispiel baut mit FastAPI einen minimalen Proxy-Dienst, der zusätzlich Anfragen protokolliert, was in einer echten Produktionsumgebung für Monitoring und Abrechnung nötig ist. Der Proxy übernimmt damit genau die Aufgaben, die SGLang selbst bewusst nicht mitbringt: Nutzerverwaltung, Logging in einem für das eigene Team passenden Format und eine Stelle, an der sich später zusätzliche Geschäftslogik wie Kostenlimits pro Abteilung einbauen lässt.

pip install fastapi uvicorn openai

cat > chat_service.py << 'EOF'
import time
import logging
from fastapi import FastAPI
from pydantic import BaseModel
from openai import OpenAI

logging.basicConfig(level=logging.INFO)
logger = logging.getLogger("chat-service")

app = FastAPI(title="Interner Chat-Service")
client = OpenAI(base_url="http://localhost:30000/v1", api_key="kein-schluessel-noetig")

class ChatRequest(BaseModel):
    message: str
    temperature: float = 0.3

@app.post("/chat")
def chat(req: ChatRequest):
    start = time.time()
    response = client.chat.completions.create(
        model="meta-llama/Meta-Llama-3.1-8B-Instruct",
        messages=[{"role": "user", "content": req.message}],
        temperature=req.temperature,
    )
    duration_ms = round((time.time() - start) * 1000, 1)
    answer = response.choices[0].message.content
    logger.info(f"Anfrage beantwortet in {duration_ms} ms, Tokens: {response.usage.total_tokens}")
    return {"answer": answer, "duration_ms": duration_ms}
EOF

uvicorn chat_service:app --host 0.0.0.0 --port 8000

Testen Sie den fertigen Dienst mit einem einfachen curl-Aufruf gegen Port 8000 statt direkt gegen SGLang auf Port 30000.

curl -X POST http://localhost:8000/chat \
  -H "Content-Type: application/json" \
  -d '{"message": "Was ist der Unterschied zwischen SGLang und Ollama?"}'

# Beispielausgabe:
# {"answer":"SGLang ist auf hohen Durchsatz bei vielen parallelen Anfragen ausgelegt ...",
#  "duration_ms":842.3}

Dieser Aufbau aus SGLang-Server plus schlankem FastAPI-Proxy lässt sich beliebig erweitern, etwa mit einem Redis-Cache vor dem Proxy, der wiederholte Anfragen zusätzlich abfängt, oder einer Nginx-Instanz davor, die TLS-Terminierung übernimmt. Ein Prometheus-Exporter liest die Log-Zeilen für Dashboards aus, sodass sich Antwortzeiten und Fehlerraten über die Zeit beobachten lassen. Wer stattdessen eine ganze Retrieval-Pipeline um SGLang bauen will, findet die nötigen Zusatzschritte im separaten RAG-Pipeline-Tutorial.

Für echte Teamnutzung lohnt sich zusätzlich ein einfaches Rate-Limiting im Proxy, damit ein einzelner Nutzer nicht versehentlich die gesamte GPU-Kapazität blockiert. Ergänzen Sie dafür ein Token-Bucket pro Nutzer-ID oder greifen Sie auf eine bestehende Middleware wie slowapi zurück, die sich nahtlos in FastAPI einbinden lässt. Ebenso empfiehlt sich ein einfacher API-Key-Mechanismus, sobald der Dienst außerhalb eines rein internen Netzwerks erreichbar sein soll, da SGLang selbst standardmäßig ohne Authentifizierung arbeitet und jede Anfrage ungeprüft verarbeitet.

SGLang in Docker betreiben

Statt SGLang direkt auf dem Host-System zu installieren, bevorzugen viele Teams eine Docker-Variante, weil sie Abhängigkeitskonflikte zwischen CUDA-Version, Python-Version und Systembibliotheken vermeidet. Das Projekt stellt dafür offizielle Container-Images bereit, die bereits mit den passenden CUDA-Treibern gebaut sind. Voraussetzung ist das NVIDIA Container Toolkit, das den GPU-Zugriff aus dem Container heraus erst möglich macht.

# NVIDIA Container Toolkit prüfen
docker run --rm --gpus all nvidia/cuda:12.4.0-base-ubuntu22.04 nvidia-smi

# SGLang-Server im Container starten
docker run --gpus all \
  -p 30000:30000 \
  -v ~/.cache/huggingface:/root/.cache/huggingface \
  --shm-size 16g \
  lmsysorg/sglang:latest \
  python3 -m sglang.launch_server \
  --model-path meta-llama/Meta-Llama-3.1-8B-Instruct \
  --host 0.0.0.0 --port 30000

Der Parameter --shm-size ist beim Container-Betrieb entscheidend, denn PyTorch nutzt für die Kommunikation zwischen Prozessen geteilten Speicher. Fehlt dieser Wert oder ist er zu knapp bemessen, bricht der Server bei größeren Batch-Größen mit einem Bus-Error ab. Das Volume-Mount auf den Hugging-Face-Cache-Ordner sorgt außerdem dafür, dass heruntergeladene Modellgewichte einen Container-Neustart überstehen und nicht bei jedem Neustart erneut heruntergeladen werden müssen. Für den produktiven Einsatz lässt sich dieser Docker-Aufruf ohne großen Aufwand in eine Kubernetes-Deployment-Definition mit einem GPU-Resource-Limit übersetzen.

Der Container-Ansatz bringt einen weiteren praktischen Vorteil mit sich: Rollbacks werden trivial. Läuft eine neue SGLang-Version in der Produktion instabil, genügt es, den vorherigen Image-Tag erneut zu deployen, statt eine Paketinstallation auf dem Host manuell rückgängig zu machen. Für Teams, die bereits eine CI/CD-Pipeline betreiben, lässt sich das Container-Image zudem automatisiert bauen und testen, bevor es in die Produktionsumgebung ausgerollt wird, was das Risiko manueller Konfigurationsfehler beim Update deutlich senkt.

Sicherheit: Zugriffskontrolle und Netzwerk-Isolation

Ein selbst gehosteter LLM-Server ist nur so sicher wie sein Netzwerkzugang. Da SGLang standardmäßig keine Authentifizierung mitbringt, sollte der Port 30000 niemals direkt ins öffentliche Internet freigegeben werden. Binden Sie den Server stattdessen an ein internes Netzwerk oder an localhost und legen Sie einen Reverse Proxy mit eigener Authentifizierung davor, etwa Nginx mit Basic Auth oder OAuth2-Proxy für eine vollwertige Single-Sign-On-Anbindung.

Für Firmen mit strengeren Compliance-Vorgaben empfiehlt sich zusätzlich eine Netzwerksegmentierung, bei der die GPU-Server in einem eigenen VLAN ohne direkten Internetzugang laufen und nur über einen definierten Gateway-Host erreichbar sind. Da Prompts und Modellantworten in solchen Umgebungen unternehmenskritische Informationen enthalten können, lohnt sich außerdem eine Prüfung, ob Logging-Systeme wie das im FastAPI-Beispiel gezeigte den vollständigen Prompt-Text mitschreiben. Für viele DACH-Unternehmen ist es aus Datenschutzsicht sinnvoller, nur Metadaten wie Antwortzeit und Token-Anzahl zu protokollieren statt des kompletten Gesprächsinhalts.

Denken Sie außerdem an regelmäßige Sicherheitsupdates für das Basissystem selbst. Ein GPU-Server, der Wochen ohne Patches läuft, weil ein Neustart den laufenden Serving-Betrieb unterbrechen würde, wird schnell zum Schwachpunkt in einer sonst gut abgesicherten Infrastruktur. Planen Sie deshalb feste Wartungsfenster ein, in denen sowohl das Betriebssystem als auch SGLang selbst aktualisiert werden, und testen Sie Updates zuerst auf einem Staging-Server mit identischer Hardware-Konfiguration, bevor Sie sie auf die Produktionsumgebung übertragen.

SGLang vs. vLLM vs. TensorRT-LLM im Vergleich

SGLang steht nicht allein im Markt für LLM-Serving-Frameworks. Der direkteste Konkurrent ist vLLM, das ebenfalls quelloffen ist und eine ähnliche Zielgruppe bedient. NVIDIAs TensorRT-LLM verfolgt einen anderen Ansatz mit tiefer Hardware-Optimierung, verlangt dafür aber mehr Einarbeitung. Die folgende Tabelle fasst die offiziell dokumentierten Benchmark-Zahlen aus dem SGLang-Repository zusammen.

Kennzahl (Llama 3.1 8B, 4x H100, 5000 Prompts)SGLangvLLM
Requests pro Sekunde22,0321,27
Output-Token pro Sekunde4281,514132,37
Median TTFT bei 8 RPS (2400 Prompts)35,68 ms120,39 ms
Median ITL bei 8 RPS (2400 Prompts)14,41 ms158,63 ms
Requests/s bei Llama 3.1 70B (4x H100)19,8419,04
Output-Token/s bei Llama 3.1 70B (4x H100)3856,013700,64

Die Zahlen stammen aus dem offiziellen Benchmark-Ordner des SGLang-Projekts auf GitHub und sind damit vom Projekt selbst veröffentlicht, was bei der Interpretation zu berücksichtigen ist. Auffällig ist der große Abstand bei TTFT und ITL, den RadixAttention durch das Wiederverwenden gemeinsamer Prompt-Präfixe erklärt. Für TensorRT-LLM liegt im selben Repository keine direkt vergleichbare Tabelle mit exakten Token-pro-Sekunde-Werten vor, weshalb an dieser Stelle nur der dokumentierte SGLang-vs-vLLM-Vergleich zitiert wird. Grundsätzlich gilt: TensorRT-LLM kann bei sorgfältiger Kernel-Kompilierung für ein einzelnes Modell auf einer bestimmten GPU-Generation ähnliche oder bessere Werte erreichen, verlangt dafür aber deutlich mehr manuelle Optimierungsarbeit als SGLang oder vLLM.

Für die Wahl zwischen den drei Frameworks zählt vor allem der Anwendungsfall. Wer schnell produktiv gehen will und Wert auf einfache Installation legt, ist mit SGLang oder vLLM gut bedient. Wer die letzten Prozentpunkte Leistung aus einer festen NVIDIA-Hardware-Kombination herausholen muss und Zeit für Kernel-Tuning hat, sollte TensorRT-LLM in Betracht ziehen. Für Fine-Tuning statt Serving ist ohnehin ein anderes Werkzeug wie Axolotl oder das in einem separaten LoRA-Tutorial beschriebene Verfahren die richtige Wahl, da SGLang ausschließlich auf Inferenz zielt.

Ein oft unterschätzter Faktor bei der Entscheidung ist die Größe und Aktivität der jeweiligen Community. Ein Projekt mit vielen aktiven Mitwirkenden und häufigen Releases löst gemeldete Fehler in der Regel schneller als ein Projekt mit wenigen Maintainern. SGLang veröffentlichte allein im September 2026 die Version 0.5.19, was für eine hohe Release-Frequenz spricht und bei der Fehlerbehebung tendenziell von Vorteil ist. Bevor Sie sich langfristig auf ein Framework festlegen, lohnt sich deshalb ein Blick auf die Häufigkeit offener, unbeantworteter Issues im jeweiligen GitHub-Repository, da dieser Wert oft mehr über die tatsächliche Wartungsqualität aussagt als reine Sternezahlen.

Kosten im Vergleich: Eigenes Hosting vs. Cloud-API

Neben Datenschutz und Kontrolle spielt bei der Entscheidung für SGLang meist auch die Kostenfrage eine Rolle. Eine gemietete H100-Instanz kostet je nach Anbieter und Vertragslaufzeit zwischen 2 und 4 US-Dollar pro Stunde, was bei durchgehendem Betrieb auf etwa 1.500 bis 3.000 US-Dollar im Monat hinausläuft. Diese Kosten fallen unabhängig davon an, wie viele Anfragen tatsächlich verarbeitet werden, solange der Server läuft. Bei einer nutzungsbasierten Cloud-API zahlen Sie dagegen pro verarbeitetem Token, was bei niedrigem bis mittlerem Volumen oft günstiger ist, bei durchgehend hoher Auslastung aber schnell teurer werden kann als eine eigene GPU.

SzenarioEigenes SGLang-HostingCloud-API (nutzungsbasiert)
Geringes Volumen (unter 1 Mio. Token/Monat)Teurer, da GPU-Miete unabhängig von Nutzung anfälltGünstiger, da nur tatsächliche Nutzung bezahlt wird
Hohes, konstantes VolumenGünstiger ab einem bestimmten Schwellenwert, planbare FixkostenKosten skalieren linear mit Volumen, können unvorhersehbar steigen
Datenschutz-AnforderungenVolle Kontrolle, keine Daten verlassen die eigene InfrastrukturAbhängig von Vertrag und Standort des Anbieters
WartungsaufwandEigenes Team für Updates, Monitoring und Skalierung nötigEntfällt vollständig, Anbieter übernimmt Betrieb

Als grobe Faustregel gilt: Wer regelmäßig mehr als einige Millionen Token pro Tag verarbeitet und dabei sensible Daten verarbeitet, fährt mit einem eigenen SGLang-Server meist günstiger und compliance-sicherer. Wer nur gelegentlich Anfragen stellt oder kein eigenes Infrastruktur-Team hat, ist mit einer Cloud-API oft besser beraten. Ein hybrider Ansatz, bei dem Standardanfragen über SGLang laufen und nur Ausreißer-Fälle an ein größeres Cloud-Modell weitergereicht werden, kombiniert beide Vorteile, erfordert aber zusätzliche Routing-Logik in der eigenen Anwendung.

Performance-Tuning: Quantisierung und Speicherverwaltung

Nach der Grundinstallation lohnt sich Feinarbeit an drei Stellschrauben. Erstens die Quantisierung: SGLang unterstützt unter anderem AWQ und GPTQ, wodurch ein 70B-Modell auch auf weniger GPU-Speicher passt, allerdings mit leichten Qualitätseinbußen bei der Textgenerierung. Zweitens die Batch-Größe: Der Parameter --max-running-requests begrenzt, wie viele Anfragen SGLang gleichzeitig verarbeitet, was bei Spitzenlast vor Out-of-Memory-Fehlern schützt. Drittens das Prefix-Caching selbst: Bei Workloads mit sehr unterschiedlichen Prompts ohne gemeinsame Präfixe bringt RadixAttention weniger Vorteil, hier lohnt sich ein Test mit deaktiviertem Cache zum Vergleich.

Ein oft übersehener Hebel ist die Kontextlänge. Wird sie größer eingestellt als tatsächlich gebraucht, reserviert SGLang unnötig viel KV-Cache-Speicher pro Sitzung, was die maximale Anzahl gleichzeitiger Nutzer senkt. Setzen Sie --context-length deshalb so knapp wie möglich über der längsten realistisch erwarteten Konversation. Für ein internes Support-Tool reichen oft 4096 bis 8192 Token, während ein Dokumenten-Analyse-Tool 32768 Token oder mehr benötigen kann.

Messen Sie vor jeder größeren Konfigurationsänderung den Ist-Zustand, statt Parameter nach Gefühl anzupassen. Ein einfaches Lastskript, das mit einem Tool wie locust oder einem selbst geschriebenen Python-Skript parallele Anfragen gegen den /v1/chat/completions-Endpunkt schickt, liefert belastbare Zahlen zu Durchsatz und Latenz unter realistischer Last. Nur mit einem solchen Vorher-Nachher-Vergleich lässt sich beurteilen, ob eine Änderung an --mem-fraction-static oder --context-length tatsächlich eine Verbesserung bringt oder in der eigenen Umgebung sogar das Gegenteil bewirkt.

Häufige Fehler beim SGLang-Setup

Die meisten Probleme beim ersten SGLang-Setup lassen sich auf eine Handvoll wiederkehrender Ursachen zurückführen. Die folgende Liste sortiert sie nach Häufigkeit, wie sie in Support-Foren und GitHub Issues des Projekts auftauchen, und zeigt jeweils den schnellsten Weg zur Behebung.

  • Falsche PyTorch-CUDA-Kombination: Wird SGLang in einer Umgebung installiert, in der bereits eine CPU-only-Version von PyTorch liegt, startet der Server ohne Fehlermeldung, nutzt aber keine GPU. Prüfen Sie vorab mit python3 -c "import torch; print(torch.cuda.is_available())", ob True zurückkommt.
  • Zu hoher statischer Speicheranteil: Der Standardwert von --mem-fraction-static ist für Multi-Modell-Setups oft zu aggressiv gewählt und führt zu Out-of-Memory-Abbrüchen, sobald ein zweiter Prozess GPU-Speicher belegt.
  • Gated Modelle ohne Login: Wer versucht, ein zugangsbeschränktes Hugging-Face-Modell ohne vorherigen huggingface-cli login zu laden, erhält einen kryptischen 401-Fehler statt einer klaren Meldung.
  • Tensor-Parallelismus ohne passende GPU-Anzahl: Der Wert von --tp muss ein Teiler der Anzahl der Attention-Heads des Modells sein, sonst bricht der Start mit einer Shape-Fehlermeldung ab.
  • Veraltete NVIDIA-Treiber: Da SGLang regelmäßig neue CUDA-Kernel-Features nutzt, führen ältere Treiber unterhalb von CUDA 12 häufig zu Kernel-Kompatibilitätsfehlern beim Serverstart, obwohl die Installation selbst fehlerfrei durchläuft.

Troubleshooting: Die häufigsten Probleme und Lösungen

Auch bei sorgfältiger Installation treten in der Praxis wiederkehrende Probleme auf, die in den GitHub Issues des Projekts dokumentiert sind. Die folgende Tabelle ordnet die häufigsten Fehlerbilder ihren Lösungen zu.

ProblemWahrscheinliche UrsacheLösung
CUDA Out of Memory beim ServerstartStatischer Speicheranteil zu hoch--mem-fraction-static auf 0.7 bis 0.8 senken
Server startet, antwortet aber nieFirewall blockiert Port 30000Port mit ufw allow 30000 freigeben oder lokal testen
Illegal memory access (CUDA-Fehler)Inkompatible Modell-/Treiber-KombinationTreiber und PyTorch-CUDA-Version aktualisieren, Modell-Dtype prüfen
GPU-Speicherverlust bei multimodalen ModellenBekannter Leak in älteren VLM-CodepfadenAuf Version 0.5.19 oder neuer aktualisieren
Ungleiche Speicherauslastung bei Tensor-ParallelismusUnausgewogene Shard-Verteilung--tp-Wert an Anzahl Attention-Heads anpassen
Abhängigkeitskonflikt beim pip installVorab installierte inkompatible PaketversionenFrische virtuelle Umgebung anlegen statt bestehende zu reparieren
Absturz bei NVIDIA-MIG-Betrieb auf H100NVML/DCGM erkennt MIG-Partitionen fehlerhaftMIG deaktivieren oder aktuellste NVIDIA-Treiber einspielen
401-Fehler beim Modell-DownloadKein Hugging-Face-Login oder Lizenz nicht akzeptierthuggingface-cli login ausführen und Modelllizenz im Browser bestätigen
Sehr langsame erste Antwort nach ServerstartModell wird noch geladen bzw. CUDA-Graphen werden kompiliertHealth-Check abwarten, erst danach Last erzeugen

Falls keine der genannten Lösungen greift, lohnt sich vor der Fehlersuche im eigenen Code ein Blick in die GitHub-Issues des Projekts. Die meisten Fehlerbilder mit CUDA-Bezug sind dort bereits mit genauer Treiber- und Hardware-Kombination dokumentiert, da die Community sehr aktiv Reproduktionsschritte sammelt. Geben Sie bei einer eigenen Fehlermeldung immer die exakte SGLang-Version, die CUDA-Version, den GPU-Typ und den vollständigen Startbefehl an, das beschleunigt eine Antwort im Issue-Tracker oder im projekteigenen Discord erheblich.

Fortgeschrittene Tipps für den Produktivbetrieb

Sobald der Grundbetrieb stabil läuft, lohnen sich einige zusätzliche Maßnahmen. Richten Sie ein separates Monitoring für GPU-Auslastung ein, etwa mit nvidia-smi dmon im Hintergrund oder einem dedizierten Exporter für Prometheus, damit Sie Speicherengpässe erkennen, bevor Nutzer Fehler melden. Für mehrere Modelle gleichzeitig starten Sie mehrere SGLang-Instanzen auf unterschiedlichen Ports und legen eine Nginx- oder Traefik-Instanz als Router davor, die Anfragen nach Modellname verteilt.

Für Teams, die bereits Erfahrung mit Ollama für die lokale Entwicklung gesammelt haben, empfiehlt sich ein zweistufiges Setup: Entwickler testen Prompts lokal mit Ollama, während die eigentliche Produktionslast über SGLang läuft. So bleibt die Entwicklerumgebung leichtgewichtig, während der Produktivbetrieb von RadixAttention profitiert. Wer zusätzlich die Modellqualität objektiv vergleichen will, kann die im LLM-Benchmark-Setup-Tutorial beschriebene Methodik direkt gegen den SGLang-Endpunkt laufen lassen, da die OpenAI-kompatible API von den meisten Benchmark-Tools ohne Anpassung unterstützt wird.

Planen Sie außerdem regelmäßige Updates ein. Da SGLang sich in einem sehr aktiven Entwicklungstempo befindet, mit wöchentlichen Commits laut star-history.com, bringt jede neue Version meist spürbare Performance-Verbesserungen und Fehlerkorrekturen mit. Ein einfacher pip install --upgrade "sglang[all]" im Wartungsfenster reicht meist aus, sollte aber zuerst in einer Staging-Umgebung getestet werden, da sich CLI-Parameter zwischen Versionen gelegentlich ändern.

Wenn ein einzelner Server nicht mehr ausreicht, lohnt sich horizontale Skalierung über mehrere SGLang-Instanzen statt eines einzelnen, immer größer konfigurierten Servers. Ein einfacher Load Balancer wie HAProxy oder Nginx mit Round-Robin-Verteilung reicht für den Einstieg aus, verteilt Anfragen aber ohne Wissen über die aktuelle Auslastung der einzelnen Server. Fortgeschrittene Setups nutzen stattdessen ein Least-Connections-Routing oder ein eigenes Scheduling, das die Warteschlangenlänge jeder SGLang-Instanz berücksichtigt, bevor eine neue Anfrage zugewiesen wird. Für Teams mit stark schwankender Last empfiehlt sich zusätzlich eine automatische Skalierung über Kubernetes Horizontal Pod Autoscaling auf Basis der GPU-Auslastung, sodass zusätzliche Instanzen nur bei tatsächlichem Bedarf starten und wieder herunterfahren.

Häufig gestellte Fragen zu SGLang

Ist SGLang kostenlos nutzbar?
Ja. SGLang steht unter der Apache-2.0-Lizenz und darf sowohl privat als auch kommerziell kostenlos eingesetzt werden.

Brauche ich zwingend eine NVIDIA-GPU?
Für den produktiven Betrieb ja. SGLang ist auf CUDA-fähige NVIDIA-GPUs mit Compute Capability sm75 oder höher ausgelegt. AMD-Unterstützung existiert über separate ROCm-Installationsvarianten, ist aber weniger verbreitet getestet.

Kann ich SGLang ohne GPU zum Testen ausprobieren?
Ein CPU-Betrieb ist technisch möglich, aber für reale Modelle wegen der Geschwindigkeit nicht praxistauglich. Für erste Tests ohne eigene Hardware eignet sich eine gemietete Cloud-GPU-Instanz besser.

Was unterscheidet SGLang konkret von Ollama?
Ollama ist auf einfache lokale Nutzung mit einem Nutzer optimiert. SGLang zielt auf hohen Durchsatz bei vielen gleichzeitigen Anfragen und eignet sich damit besser als interner API-Server für ein Team oder eine Anwendung mit mehreren Nutzern.

Unterstützt SGLang auch multimodale Modelle?
Ja, laut Projektbeschreibung dient SGLang sowohl dem Serving von reinen Sprachmodellen als auch multimodalen Modellen, wobei für einige Vision-Language-Modell-Codepfade in älteren Versionen Speicherlecks gemeldet wurden, die in Version 0.5.19 behoben sein sollen.

Wie viele GPUs brauche ich für ein 70B-Modell?
In der Regel vier GPUs mit jeweils 80 GB VRAM, etwa NVIDIA H100, kombiniert mit Tensor-Parallelismus über den Parameter --tp 4.

Kann ich SGLang mit dem OpenAI-Python-SDK verwenden?
Ja, da SGLang eine zur OpenAI-API kompatible Schnittstelle unter /v1 bereitstellt, reicht es, die base_url im OpenAI-SDK auf die eigene SGLang-Instanz zu setzen.

Wie aktuell ist die SGLang-Dokumentation?
Die offizielle Dokumentation unter docs.sglang.ai wird parallel zu den Code-Releases gepflegt und listet zu jeder Version die aktuellen CLI-Parameter, was angesichts der wöchentlichen Release-Frequenz besonders wichtig ist.

Lohnt sich SGLang auch für ein kleines Team mit nur einer GPU?
Ja. Schon auf einer einzelnen GPU mit 24 GB VRAM profitieren mehrere gleichzeitige Nutzer von RadixAttention, weil wiederkehrende Systemprompts nur einmal berechnet werden. Der Umstieg lohnt sich bereits, sobald mehr als eine Person regelmäßig denselben Endpunkt nutzt.

Muss ich meinen bestehenden Anwendungscode umschreiben, wenn ich von einer Cloud-API zu SGLang wechsle?
In den meisten Fällen nicht. Da die Schnittstelle unter /v1 zur OpenAI-API kompatibel ist, genügt es, die Basis-URL und den API-Schlüssel im bestehenden Client anzupassen. Modellspezifische Parameter wie Funktionsaufrufe sollten Sie trotzdem einzeln testen, da nicht jedes Feature der OpenAI-API 1:1 unterstützt wird.