> ## Documentation Index > Fetch the complete documentation index at: https://docs.tokios.com/llms.txt > Use this file to discover all available pages before exploring further. > ## Agent Instructions > Tokios exposes private local models through https://api.tokios.com using an outbound-only connector tunnel. > Use 'connector' for the local tokios-connector process. > Use 'deployment' for the public model name in the API model field. > Use 'upstream model id' for the model served by Ollama, llama.cpp, vLLM, LM Studio, or another local backend. > API keys use the prefix sk-tok-. Connector tokens use the prefix ct-tok-. # Konfiguration von SGLang und wann Sie es einsetzen sollten > Konfigurieren Sie SGLang für RAG- und Agent-Workloads – RadixAttention für Prefix-Caching, Entscheidungsmatrix vLLM vs. SGLang und SGLang-spezifische Optimierungs-Flags. SGLang ist eine Hochleistungs-Bereitstellungslaufzeit, die für Durchsatz gebaut ist. Sein Merkmal RadixAttention verwendet einen baumstrukturierten KV-Cache, der Berechnung über Anfragen mit gemeinsamen Token-Präfixen wiederverwendet. Das macht SGLang zur stärksten Open-Source-Wahl für Workloads, bei denen viele Anfragen dasselbe System-Prompt, Tool-Schema oder abgerufenen Kontext tragen — RAG-Pipelines, Multi-Turn-Chat und Agenten-Schleifen. Dieser Leitfaden behandelt, wann SGLang statt vLLM zu wählen ist, die wichtigen Konfigurations-Flags und gebrauchsfertige Startbefehle für gängige Setups. > [!NOTE] > > Zuletzt überprüft: 2026-10-14. Diese Seite spiegelt SGLang **v0.5.21** (veröffentlicht am 2. Oktober 2026) wider. Flag-Namen und Standardwerte können zwischen Versionen wechseln — überprüfen Sie sie mit `python -m sglang.launch_server --help` gegen Ihre installierte Version. ## RadixAttention SGLangs KV-Cache ist keine flache Tabelle — er ist ein **Radix-Baum**, indiziert nach Token-Sequenzen. Jedes Präfix, das jemals eine Anfrage verarbeitet hat, lebt im Baum. Wenn eine neue Anfrage eintrifft, durchläuft SGLang den Baum, um das längste passende Präfix zu finden, und verwendet seinen zwischengespeicherten KV-Zustand wieder, anstatt ihn neu zu berechnen. Konkret: Wenn 10 Anfragen ein 2,000-Token-System-Prompt teilen, wird das Prompt einmal geprefillt. Die restlichen 9 Anfragen überspringen direkt zum Decode. Wenn Konversationen auseinandergehen, bekommt jeder Zweig seinen eigenen Cache-Knoten, und gemeinsame Präfixe auf jeder Tiefe werden unabhängig wiederverwendet. Der Leistungsunterschied ist bei präfixlastigen Workloads erheblich. Bei 50 gleichzeitigen Anfragen mit 80% gemeinsamem Präfix liefert SGLang **37% niedrigere Time-to-First-Token (TTFT)** im Vergleich zu vLLM. Der Vorteil wächst, wenn die Präfix-Überlappung zunimmt, und schrumpft, wenn jede Anfrage einzigartig ist. > [!TIP] > > RadixAttention ist nichts, was Sie aktivieren — es ist die Art, wie SGLangs KV-Cache standardmäßig funktioniert. Jede Anfrage profitiert automatisch. Die Konfigurations-Flags steuern Eviction-Policy, Speichergrenzen und das Rust-basierte Storage-Backend. ## Wann SGLang gewinnt Wählen Sie SGLang, wenn Ihr Workload **hohe Präfix-Überlappung** hat: * **RAG-Pipelines** — dasselbe System-Prompt und abgerufene Chunks erscheinen über viele Anfragen. RadixAttention cached das Prompt- + Dokument-Präfix einmal und verwendet es für jede Frage wieder. * **Multi-Turn-Konversationen** — jeder Turn erweitert den vorherigen Kontext. Die gesamte Konversationshistorie bis zum letzten Turn ist ein gemeinsames Präfix. * **Agenten-Schleifen mit Tool-Schemas** — Agenten senden dieselben Tool-Definitionen, Few-Shot-Beispiele und Orchestrierungs-Prompts bei jedem Aufruf. SGLang cached diese Präfixe und prefillt nur die neuen Tool-Ergebnisse. * **Lange gemeinsame System-Prompts** — jedes Deployment, bei dem Dutzende oder Hunderte Nutzer ein großes System-Prompt teilen (Kunden-Support-Bots, Coding-Assistenten, Dokument-Q\&A). * **Batch-Evaluierung** — dasselbe Prompt-Template mit verschiedenen Variablen-Substitutionen ausführen. Das Template-Präfix wird gecached; nur der ausgefüllte Teil wird geprefillt. ## Wann vLLM gewinnt Wählen Sie vLLM, wenn Ihr Workload **Breite über Tiefe** priorisiert: * **Einzigartige Prompts pro Anfrage** — wenn jede Anfrage ein völlig anderes Prompt ohne gemeinsames Präfix hat, hat RadixAttention nichts wiederzuverwenden. vLLMs PagedAttention behandelt unabhängige Anfragen equally gut. * **Breite Modellunterstützung** — vLLM fügt Unterstützung für neue Modellarchitekturen schneller hinzu. Wenn Sie ein Modell brauchen, das letzte Woche erschien, unterstützt vLLM es wahrscheinlich zuerst. * **Blackwell-GPU-Optimierung** — vLLM hat dedizierte Optimierungspfade für NVIDIA Blackwell (B100/B200/GB200) Hardware. Wenn Sie auf Blackwell bereitstellen, extrahiert vLLM mehr Durchsatz. * **EAGLE3 spekulative Dekodierung** — vLLMs EAGLE-Integration ist ausgereifter. Wenn spekulative Dekodierung Ihr primärer Latenz-Hebel ist, ist vLLM heute die sicherere Wahl. * **Produktions-Härtung** — vLLM hat eine größere Bereitstellungsbasis und eine längere Erfolgsbilanz im Produktionsbetrieb. Wenn Stabilität und Community-Support wichtiger als Prefix-Caching sind, ist vLLM der Standard. ## Konfigurations-Flags Wichtige SGLang-spezifische Flags für `python -m sglang.launch_server`: | Flag | Standard | Zweck | | - | - | - | | `--model-path` | (erforderlich) | HuggingFace-Repo-ID oder lokaler Pfad zum Modell | | `--port` | `30000` | Lauschport für den OpenAI-kompatiblen Server | | `--host` | `127.0.0.1` | Bindungsadresse — Loopback behalten, außer ein Reverse Proxy steht vor SGLang | | `--tp` | `1` | Tensor-Parallelität über GPUs | | `--mem-fraction-static` | `0.88` | Anteil des GPU-Speichers, der beim Start dem KV-Cache zugewiesen wird. Auf `0.90`-`0.92` für Long-Context-Workloads erhöhen, wenn Sie Spielraum haben. | | `--context-length` | Modell-Max | Die maximale Kontextlänge des Modells überschreiben. Niedriger als das Modell-Max setzen, um den KV-Cache-Speicher pro Anfrage zu reduzieren. | | `--chunked-prefill-size` | `-1` (auto) | Große Prefills in Chunks aufteilen, um Decode nicht zu blockieren. Auf `2048`-`4096` für gemischte Workloads mit langen Inputs setzen. | | `--disable-radix-cache` | `false` | Deaktiviert RadixAttention vollständig. Das will man fast nie — es entfernt SGLangs Kernvorteil. | | `--enable-metrics` | `false` | Macht Prometheus-Metriken unter `/metrics` verfügbar. In der Produktion aktivieren. | | `--api-key` | (keine) | Einen Bearer-Token bei Anfragen an SGLangs eigenen Server erfordern. Nützlich als Defense-in-Depth auf Loopback. | ### Rust-basiertes Prefix-Caching Beginnend mit **v0.5.21** ist das RadixAttention-Cache-Backend in Rust implementiert und standardmäßig aktiviert. Das Rust-Backend ersetzt die frühere Python-Implementierung mit geringerem Overhead für Cache-Lookups, Einfügungen und Eviction. Sie brauchen kein Flag, um es zu aktivieren — es ist der Standardpfad. Wenn Sie auf Probleme stoßen, können Sie mit `--disable-cuda-graph` auf die Python-Implementierung zurückfallen und die SGLang-Release-Notes für das genaue Rollback-Flag für Ihre Version prüfen. In der Praxis ist das Rust-Backend stabil und schneller. ## Entscheidungsmatrix | Workload | Empfohlene Laufzeit | Warum | | - | - | - | | RAG mit wiederholtem Kontext | **SGLang** | RadixAttention cached System-Prompt + abgerufene Chunks | | Multi-Turn-Chat (10+ Turns) | **SGLang** | Jeder Turn erweitert ein gemeinsames Präfix | | Agenten-Schleifen mit Tool-Schemas | **SGLang** | Tool-Definitionen nach dem ersten Aufruf gecached | | Langes gemeinsames System-Prompt | **SGLang** | Ein Prefill bedient viele Anfragen | | Einzigartige Prompts pro Anfrage | **vLLM** | Kein Präfix-Wiederverwendungsvorteil; PagedAttention ist equally schnell | | Neueste Modellarchitekturen | **vLLM** | Schnellere Adoption neuer Modelle | | Blackwell-GPU (B100/B200) | **vLLM** | Dedizierte Blackwell-Optimierungspfade | | EAGLE3 spekulative Dekodierung | **vLLM** | Ausgereiftere Unterstützung für spekulative Dekodierung | | Batch-Evaluierung (gleiches Template) | **SGLang** | Template-Präfix über alle Varianten gecached | | Single-Nutzer, niedrige Parallelität | Beide | Beide performen gut; nach Vertrautheit wählen | ## Beispielkonfigurationen ### RAG-Pipeline mit langem abgerufenen Kontext Bereiten Sie ein 70B-Modell für RAG optimiert bereit, bei dem jede Anfrage dasselbe System-Prompt und große abgerufene Dokument-Chunks trägt: ```bash theme={"theme":{"light":"github-light","dark":"css-variables"}} python -m sglang.launch_server \ --model-path meta-llama/Llama-3.1-70B-Instruct \ --port 30000 \ --tp 4 \ --mem-fraction-static 0.92 \ --context-length 16384 \ --chunked-prefill-size 4096 \ --enable-metrics ``` `--mem-fraction-static 0.92` weist mehr GPU-Speicher dem KV-Cache für lange abgerufene Kontexte zu. `--chunked-prefill-size 4096` verhindert, dass große Dokument-Prefills gleichzeitige Decode-Anfragen blockieren. RadixAttention erledigt den Rest — das System-Prompt und Dokument-Präfix werden nach der ersten Anfrage gecached. ### Multi-Turn-Chat-Agent mit Tool-Schemas Bereiten Sie ein Modell für einen Agenten bereit, der bei jedem Aufruf dieselben Tool-Definitionen sendet: ```bash theme={"theme":{"light":"github-light","dark":"css-variables"}} python -m sglang.launch_server \ --model-path meta-llama/Llama-3.1-8B-Instruct \ --port 30000 \ --tp 1 \ --mem-fraction-static 0.90 \ --context-length 32768 \ --chunked-prefill-size 2048 \ --enable-metrics ``` Das Tool-Schema des Agenten, das System-Prompt und die Few-Shot-Beispiele sind über alle Aufrufe identisch. RadixAttention cached dieses gesamte Präfix. Nur die neuen Tool-Ergebnisse und die Benutzernachricht am Ende jedes Turns erfordern einen neuen Prefill. Mit 32K Kontext können Multi-Turn-Konversationen Dutzende Turns laufen, bevor das Limit erreicht ist. ### Hochdurchsatz-Batch-Evaluierung Führen Sie dasselbe Prompt-Template über Tausende von Inputs mit maximalem Durchsatz aus: ```bash theme={"theme":{"light":"github-light","dark":"css-variables"}} python -m sglang.launch_server \ --model-path meta-llama/Llama-3.1-70B-Instruct \ --port 30000 \ --tp 8 \ --mem-fraction-static 0.90 \ --context-length 8192 \ --chunked-prefill-size 4096 \ --enable-metrics ``` Das Prompt-Template wird einmal geprefillt und gecached. Jede Anfrage prefillt nur ihre einzigartige Variablen-Substitution. Über 8 GPUs mit Tensor-Parallelität wird der Batch-Durchsatz vom Decode dominiert — der Prefill-Overhead ist fast eliminiert. > [!WARNING] > > **Sicherheitshinweis — Qwen VL Video-Vorverarbeitung.** SGLang bis v0.5.21 hat eine Speicherschöpfungs-Denial-of-Service-Schwachstelle in der Qwen VL Video-Vorverarbeitung. Eine präparierte Anfrage kann eine unbegrenzte Speicherzuweisung während der Video-Frame-Dekodierung auslösen. Wenn Sie Qwen VL-Modelle bereitstellen, wenden Sie den Upstream-Patch an oder aktualisieren Sie auf eine Version, die den Fix enthält. Wenn Sie nicht sofort aktualisieren können, beschränken Sie den Zugriff auf den SGLang-Server auf vertrauenswürdige Aufrufer. ## Native Decisions API SGLang v0.5.21 hat eine **Native Decisions API** hinzugefügt, die demselben Muster wie Ollama und LM Studio folgt. Dies lässt Clients abfragen, welche Modelle verfügbar sind, den Modellstatus prüfen und Deployments über eine konsistente Schnittstelle verwalten — nützlich, wenn Sie Tooling bauen, das mit mehreren lokalen Backends spricht. Prüfen Sie die SGLang-Release-Notes für die genauen Endpunkt-Pfade und das Anfrage-/Antwortformat, da die API-Oberfläche neu ist und sich weiterentwickeln kann. ## SGLang durch Tokios verbinden Sobald SGLang läuft, legt der Tokios-Connector ihn für entfernte Clients frei, ohne eingehende Ports zu öffnen. Der Connector wählt sich ausgehend zu `https://api.tokios.com` ein und leitet Anfragen an SGLangs OpenAI-kompatiblen `/v1`-Endpunkt auf localhost weiter. Siehe [SGLang Fernzugriff](/de/guides/sglang-remote-access.md) für die vollständige Einrichtungsanleitung. > **[SGLang Fernzugriff](/de/guides/sglang-remote-access.md)** > > Verbinden Sie SGLang durch Tokios für authentifizierten Fernzugriff. > **[vLLM Fernzugriff](/de/guides/vllm-remote-access.md)** > > Dasselbe Muster für vLLM — Setups nebeneinander vergleichen. > **[Spekulative Dekodierung](/de/guides/speculative-decoding.md)** > > Decode mit Draft-Modellen, N-Grammen, MTP und EAGLE beschleunigen. > **[Ihr Deployment benchmarken](/de/guides/benchmark-your-deployment.md)** > > TTFT, Durchsatz und Latenz über Konfigurationen messen. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.