SGLang ist in den letzten zwei Jahren in der Inferenz-Welt kaum zu umgehen: Auf derselben GPU läuft es bei Mehrturn-Dialogen, Agenten-Workloads und strukturierter Ausgabe oft spürbar schneller als ein einfacher Aufbau. Es ist aber kein Chatprodukt, sondern eine Inferenzmaschine, die GPUs, Tuning und Betreuung braucht. Ob sich Self-Hosting lohnt, hängt zuerst davon ab, wie Ihre Anfragen aussehen, und danach, ob Sie den Betrieb stemmen können.
Offizielle Repository-Angaben
- Plattform: GitHub
- Organisation: sgl-project
- Projekt: sglang
- Hintergrund: vom LMSYS-Team gestartet, mit Forschenden unter anderem von der UC Berkeley weiterentwickelt
- Lizenz: Apache 2.0, geschäftsfreundlich
- Positionierung: leistungsstarkes Serving-Framework für Sprach- und multimodale Modelle mit OpenAI-kompatibler Schnittstelle
Warum es sich durchsetzte: schnell dort, wo andere neu rechnen
Die meisten Inferenz-Frameworks behandeln jede Anfrage als völlig neue Aufgabe. SGLangs Kernmechanismus RadixAttention speichert den KV-Cache bereits berechneter Prompt-Präfixe in einem Radix-Baum; teilt eine neue Anfrage denselben Präfix, ob Systemprompt, Dokumentanfang oder frühere Dialogrunden, wird der Cache wiederverwendet statt neu berechnet. Das Paper des Projekts berichtet von Durchsatzgewinnen in mehrfacher Größenordnung bei Aufgaben wie Agentensteuerung und JSON-Dekodierung; der reale Abstand hängt davon ab, wie viel wiederverwendbarer Präfix in Ihrem Verkehr steckt.
Der zweite Verkaufs Punkt ist strukturierte Generierung. Muss die Ausgabe einem JSON-Schema, einem Regex oder einer Grammatik folgen, beschleunigt eine komprimierte Zustandsmaschine die Dekodierung und hält die Ausgabe zugleich in der Spur. Für Produkte, die massenhaft Felder extrahieren oder Werkzeugketten ausführen, zählt das mehr als ein nackter Chat-Endpunkt. Mit Continuous Batching, Tensorparallelismus und FP8- oder INT4-Quantisierung ergibt das einen kompletten produktiven Inferenz-Stack statt eines Einzeltricks.
Für wen es passt und für wen nicht
Es passt für Teams mit echtem Anfragevolumen und vielen wiederkehrenden Präfixen: Mehrturn-Support und Begleit-Chat, Agenten mit langen Systemprompts, RAG-Systeme, die dieselben Dokumente immer wieder zusammensetzen. Dort senkt eine selbst gehostete Installation den Preis pro Token wirklich. Wer noch eine nutzungsbasierte Cloud-API mit bescheidenem Volumen verwendet, sollte es lassen; API-Gebühren sind weit billiger als eine dauerhaft laufende GPU. Auch Einzelne, die nur ein Chatfenster auf dem eigenen Rechner wollen, sind hier falsch; eine Endnutzeroberfläche gibt es nicht, das ist die Aufgabe von Projekten wie Open WebUI oder LibreChat.
Betriebskosten und echte Fallstricke
Rechnung eins: GPUs. Eine Serverinstanz hostet genau ein Modell, zwei Modelle bedeuten zwei Prozesse und zwei VRAM-Anteile; bei Modellen der 70B-Klasse ist Tuning mit mehreren GPUs und Tensorparallelismus unvermeidlich. Zweitens das Release-Tempo: Neue Modelle und Quantisierungsformate kommen schnell an, Upgrades lohnen sich, aber Schnittstellen und Schalter bewegen sich mit; in Produktion Versionen fixieren, Regression fahren, dann anheben, niemals automatisch dem Neuesten folgen. Fallstrick drei ist der falsch eingeschätzte Gewinn: Teilen Ihre Anfragen praktisch keine Präfixe, etwa lauter unabhängige Kurzfragen, schrumpft der RadixAttention-Vorteil stark; messen Sie mit echtem Verkehr statt mit Papierwerten. Viertens der Betrieb selbst: Logging, Ratenbegrenzung, GPU-Ausfälle und Gewichtsverwaltung liegen bei Ihnen, ganz ohne die Sorglosigkeit einer gehosteten API.
Fazit: Hohes Volumen, viele Präfix-Wiederholungen und jemand im Team, der GPUs betreiben kann, machen Self-Hosting lohnend, und eine frühe Migration spart mehr. Bei kleinem oder gemischtem Verkehr bleiben Sie bei einer gehosteten API; wenn die Rechnung wirklich wehtut, ist dieser Beitrag noch da.
