SGLang vs vLLM: Welche Engine passt zu Agenten und RAG?

SGLang vs vLLM: Welche Engine ist die richtige Wahl?

vLLM ist die Standardempfehlung für die Bereitstellung. SGLang sollte bei Workloads mit überwiegend gemeinsamem Kontext zuerst evaluiert werden. Diese Empfehlungen stützen sich auf die dokumentierten Bereitstellungswege und Cache-Einstellungen. Sie besagen nicht, dass eine Engine grundsätzlich schneller ist.

Wer viele kurze Chats bedient, hat mit einem gemeinsamen System-Prompt einen guten Grund, SGLang zu prüfen. vLLM scheidet deshalb aber nicht aus: Beide Engines können Prompt-Berechnungen wiederverwenden. Für Gründer, die eine unkomplizierte API aufbauen und wenig Zeit für Infrastruktur haben, empfiehlt sich der Einstieg mit vLLM. Ein späterer Wechsel sollte einen nachweisbaren Vorteil bei Servicequalität oder Kosten bringen.

RAG, ausgeschrieben Retrieval-Augmented Generation, ergänzt den Prompt eines Modells um abgerufene Dokumente. Entscheidend für den Nutzen von Prefix Caching ist der wiederkehrende Anfang dieses Prompts, nicht die Bezeichnung RAG.

Stand der Prüfung: 14. Oktober 2026. Die bei dieser Prüfung ermittelten neuesten stabilen Versionen waren vLLM 0.31.0, veröffentlicht am 5. Oktober, und SGLang 0.5.21, veröffentlicht am 2. Oktober. Die folgenden Funktionsbeschreibungen orientieren sich an der aktuellen Projektdokumentation. Die benötigte Kombination muss gegen die festgeschriebene Release-Version geprüft werden. Für diesen Vergleich wurde kein Inferenz-Benchmark durchgeführt.

Die Lizenzangaben wurden anhand der Lizenz von vLLM und des SGLang-Repositorys geprüft. Lizenzen für Modellgewichte, Infrastruktur und Entwicklungsarbeit sind gesonderte Kostenpunkte. Für die Open-Source-Engines der beiden Projekte gibt es keinen gehosteten Token-Tarif, der sich vergleichen ließe.

Was die Engines leisten – und wo ihre Grenzen liegen

vLLM: Der Ausgangspunkt für allgemeines Model Serving

vLLM ist eine Inferenz- und Serving-Engine, die Modellgewichte lädt und Anfragen auf der vorhandenen Hardware einplant. Zu den dokumentierten Bausteinen gehören Continuous Batching, das neue Anfragen aufnimmt, sobald andere abgeschlossen sind, und PagedAttention. Letzteres verwaltet den Key-Value-Cache des Modells in Blöcken, statt für jede Anfrage einen großen zusammenhängenden Speicherbereich zu reservieren. Der KV-Cache speichert Zwischenzustände der Attention-Berechnung. So kann das Modell weitergenerieren, ohne den gesamten bisherigen Verlauf erneut zu berechnen. vLLM-Dokumentation

Für den Einstieg spricht eine klar umrissene Bereitstellung: ein Modell, ein offizielles Server-Image, eine API und ausdrückliche Installationsanleitungen für die einzelnen Plattformen. Ein Produktteam, das einen Endpunkt für den Kundensupport aufbaut, erhält damit eine überschaubare Grundlage für Kapazitätsmessungen.

Die Grenze liegt in der geprüften Konfiguration. Eine unterstützte GPU ist erst der Anfang. Modellarchitektur, Quantisierung, Attention-Backend und gewünschte Funktionen müssen zusammenspielen. Für Evaluierungsdienste ist eine konkrete Cache-Ausnahme relevant: Laut vLLM umgeht eine Anfrage nach Prompt-Log-Wahrscheinlichkeiten den Präfix-Cache und berechnet den Prompt erneut. Ein Scoring-Endpunkt kann sich deshalb anders verhalten als ein Chat-Endpunkt, der dasselbe Dokument nutzt. vLLM-V1-Leitfaden

Die Engine kostet $0. Sie empfiehlt sich für allgemeines Model Serving und gemischte Hardwarebestände. Erfüllt eine funktionierende SGLang-Installation bereits das Serviceziel und fehlt keine benötigte Funktion, ist eine Migration zu vLLM nicht nötig.

SGLang: Ein guter Einstieg bei wiederkehrendem Agentenkontext

SGLang ist ein Open-Source-Inferenzframework für Sprach- und multimodale Modelle, das agentische Workloads ausdrücklich zu seinen Schwerpunkten zählt. RadixAttention organisiert wiederverwendbare Prompt-Zustände anhand gemeinsamer Präfixe. Die Erweiterung HiCache ergänzt den GPU-Cache um Host-Arbeitsspeicher und Massenspeicher. In der Praxis ist vor allem das dokumentierte Instrumentarium interessant, mit dem sich Kontext über wiederholte Anfragen hinweg vorhalten und wiederverwenden lässt. SGLang-Repository, HiCache-Architektur

Ein typisches Beispiel ist ein Agent, der immer wieder dieselben Supportrichtlinien liest und anschließend unterschiedliche Kundenfragen bearbeitet. Das ist ein überzeugenderer Anlass, SGLang zu evaluieren, als voneinander unabhängige Prompts, die lediglich mit hoher Parallelität eintreffen.

Die Grenzen liegen in der Lokalität des Caches und im Funktionsumfang der einzelnen Backends. Die GPU- und Host-Arbeitsspeicherebenen von HiCache gehören jeweils zu einer Inferenzinstanz. Massenspeicher wird erst dann gemeinsam nutzbar, wenn das gewählte Backend entsprechend konfiguriert ist. Ein größerer Host-Cache erzeugt also nicht automatisch einen Cache für den gesamten Serverbestand. Zusätzliche Ebenen bedeuten außerdem Speicherbudgets, Datentransfers und Konfiguration, die im Betrieb berücksichtigt werden müssen. Geltungsbereich der gemeinsamen HiCache-Nutzung

Die Engine kostet $0. Sie lohnt sich als Kandidat, wenn wiederkehrender Kontext eine gezielte Optimierung rechtfertigt. Teilen die Prompts nur selten ein exakt gleiches Präfix, ist das Schlagwort „Agenten“ allein kein Grund für einen Wechsel.

Prefix Caching und RadixAttention: SGLang zuerst testen

Bei verzweigten Workloads mit wiederkehrendem Kontext hat SGLang Vorrang bei der Evaluierung; die grundlegende Cache-Funktion bringt vLLM bereits mit. Hier stehen sich nicht PagedAttention und die Fähigkeit zum Caching gegenüber. PagedAttention betrifft die Speicherorganisation, Prefix Caching dagegen die Wiederverwendung. Automatic Prefix Caching von vLLM deckt ausdrücklich wiederholte Fragen zu langen Dokumenten und Gespräche mit mehreren Runden ab. Prefix Caching in vLLM

Prefill bezeichnet die Verarbeitung des Prompts, bevor die Generierung beginnt. Decode ist die Erzeugung neuer Tokens. Ein Cache-Treffer kann wiederholtes Prefill vermeiden, nimmt der Engine aber nicht die Decode-Arbeit für eine neue Antwort ab. Eine lange Antwort mit wenig gemeinsamer Eingabe profitiert deshalb unter Umständen kaum von der Präfix-Wiederverwendung – bei beiden Engines.

Bei einem Produkt für kurze Chats sollten unveränderte Richtlinien und Werkzeugbeschreibungen vor den wechselnden Anfrageinhalten stehen, sofern das vom Modell erwartete Prompt-Format dies zulässt. Serialisierung und Dokumentreihenfolge sollten stabil bleiben. Schon ein abweichender Zeitstempel weit vorne kann die Wiederverwendung des ansonsten identischen nachfolgenden Materials verhindern. Das lässt sich mit einem gemeinsamen Weg vergleichen: Sobald sich die Routen trennen, macht eine später identische Landschaft den zuvor zurückgelegten Weg nicht wieder identisch.

Bei RAG mit langem Kontext kommt eine weitere Frage hinzu: Ist der Kontext wiederverwendbar oder nur lang? Wiederholte Fragen zu einem unveränderten Handbuch sind ein guter Anwendungsfall für Caching. Ein Suchprodukt, das bei jeder Anfrage andere Passagen in anderer Reihenfolge zusammenstellt, behält möglicherweise nur sein kurzes Systempräfix bei. Diese Fälle sollten getrennt gemessen werden, bevor sich eine Investition in hierarchische Speicherung beurteilen lässt.

Laut Dokumentation ist RadixAttention in SGLang standardmäßig aktiv; gesteuert wird dies über --disable-radix-cache. HiCache ist eine zusätzliche Konfigurationsentscheidung. Bei beiden Engines zählt die tatsächlich wirksame Konfiguration. Der Projektname allein verrät nichts über das Cache-Verhalten. SGLang-Serverparameter

Funktionen für Agenten: Gleichstand bei JSON, Prüfbedarf bei Adaptern und Draft-Verfahren

Die Anforderung „JSON“ allein verschafft keiner Engine einen Vorsprung. Beide unterstützen eine durch ein Schema eingeschränkte Generierung. Das Modell wählt die Werte; die Struktur wird vorgegeben und das Ergebnis vor der Ausführung einer Aktion validiert.

Strukturierte JSON-Ausgaben

vLLM unterstützt JSON Schema über response_format und seine structured_outputs-Optionen. Auch SGLang unterstützt JSON Schema und nutzt XGrammar als Standard-Grammatik-Backend. Dabei handelt es sich um Vorgaben für das Decoding, nicht bloß um eine Aufforderung an das Modell, „JSON zurückzugeben“. Strukturierte Ausgaben in vLLM, strukturierte Ausgaben in SGLang

Bei einem Supportagenten kann ein Schema eine Aktion und eine Ticketkennung verlangen. Es kann aber weder feststellen, ob das Ticket dem anfragenden Nutzer gehört, noch ob die gewählte Aktion gerechtfertigt ist. Diese Prüfungen gehören in den Anwendungscode. Die tatsächlichen Schemas, der Reasoning-Modus und das Streaming-Verhalten müssen gemeinsam getestet werden. Dass eine Engine jedes Element einzeln unterstützt, belegt noch nicht, dass die konkrete Kombination korrekt funktioniert.

Ergebnis: Gleichstand bei üblichen JSON-Anforderungen. Ein Wechsel der bereits betriebenen Engine lohnt sich erst, wenn repräsentative Schema-Anfragen einen konkreten Unterschied aufzeigen.

Speculative Decoding

Speculative Decoding ist bei beiden Projekten eine Optimierungsoption, aber keine Garantie für mehr Geschwindigkeit. Ein Draft-Verfahren schlägt Tokens vor, die das Zielmodell überprüft. Brauchbare, akzeptierte Vorschläge können den Aufwand der sequenziellen Generierung verringern. Vorschlagserzeugung, Prüfung und Speicherbedarf verursachen jedoch weiterhin Kosten.

vLLM dokumentiert EAGLE, Multi-Token Prediction, separate Draft-Modelle sowie n-Gramm- und Suffix-Verfahren. Auch SGLang dokumentiert EAGLE, Multi-Token Prediction, Draft-Modelle und NGRAM-Verfahren. Das Zusammenspiel von Draft-Verfahren, Zielmodell, Hardware und Last ist wichtiger als ein Häkchen in der Funktionsliste. vLLM-Verfahren, SGLang-Verfahren

Vorn liegt die Engine, deren Draft-Verfahren für das eingesetzte Modell geprüft ist. Speculative Decoding sollte erst nach einer Basismessung aktiviert werden. Anschließend zählen Antwortlatenz und Gesamtkapazität im Vergleich. Zahlt sich die zusätzliche Arbeit unter Produktionslast nicht aus, bleibt die Funktion deaktiviert.

Multi-LoRA für mandantenspezifisches Verhalten

Beide Engines können mehrere LoRA-Adapter bereitstellen. Diese kleinen zusätzlichen Gewichte aus dem Fine-Tuning passen ein gemeinsames Basismodell an. vLLM registriert Adapter über --lora-modules und bietet Einstellungen für Parallelität und Rang. SGLang stellt --lora-paths und --max-loras-per-batch bereit; der dokumentierte Standardwert pro Batch beträgt 8 Adapter. Das ist keine Obergrenze für die Gesamtzahl der Kunden. LoRA in vLLM, LoRA in SGLang

Bei einem Schreibprodukt mit mandantenspezifischer Anpassung sollte die erwartete Verteilung der Adapternutzung getestet werden, einschließlich noch nicht geladener Adapter und häufiger Wechsel. Die Option zum überlappenden Laden in SGLang kann Transferzeiten verdecken. Die Dokumentation warnt jedoch auch davor, dass sie das Prefill-Batching über mehrere Adapter verringern und die Latenz bis zum ersten Token erhöhen kann. Mehr Einstellmöglichkeiten bedeuten nicht automatisch mehr Kapazität.

Empfehlung: Bei der Engine bleiben, deren Adapterbetrieb bereits geprüft ist. Multi-LoRA allein begründet keinen Wechsel. Ein Test von SGLang lohnt sich, wenn das Ladeverhalten der Adapter oder ein stark vom Cache geprägter Workload den Engpass bildet. Für TPU gilt die Funktionsmatrix des jeweiligen Backends: Der SGLang-JAX-Leitfaden führt Multi-LoRA weiterhin als in Entwicklung. SGLang-Funktionsmatrix für TPU

Hardwareunterstützung: vLLM als Ausgangspunkt für gemischte Bestände

Beide Projekte nennen Unterstützung für NVIDIA, AMD, TPU und CPU. Entscheidend ist jedoch die konkrete Kombination aus Backend und Modell. Eine projektweite Hardwareliste ist kein Versprechen, dass sich jede GPU-Konfiguration, jeder Adapter und jedes Decoding-Verfahren unverändert übertragen lässt.

• NVIDIA: vLLM dokumentiert die Installation auf CUDA-GPUs; das SGLang-Repository nennt Rechenzentrums- und RTX-Produktfamilien. Die aktuellen Release-Images und der Host-Treiber müssen zueinander passen. vLLM-GPU-Installation, SGLang-Hardwareliste
• AMD: Beide dokumentieren die Bereitstellung mit ROCm. SGLang führt Instinct MI300X, MI325X, MI350X und MI355X auf und bietet eine separate Installationsanleitung. Das ROCm-Image und die Modellkonfiguration müssen dazu passen. SGLang-Anleitung für AMD
• Google TPU: vLLM verweist auf seine separate tpu-inference-Installation. Der TPU-Leitfaden von SGLang nutzt das eigenständige SGLang-JAX-Backend und nennt v6e und v7. Diese Bereitstellungswege sind voneinander unabhängig und erfordern eigene Funktionsprüfungen. vLLM-TPU-Installation, SGLang-TPU-Leitfaden
• CPU: Zu den dokumentierten CPU-Installationswegen von vLLM gehören Intel/AMD x86 und ARM AArch64. Die CPU-Serveranleitung von SGLang richtet sich ausdrücklich an Intel AMX auf Xeon-Scalable-Prozessoren ab der vierten Generation. „CPU-Unterstützung“ bedeutet also nicht denselben Abdeckungsumfang. vLLM-CPU-Leitfaden, SGLang-CPU-Leitfaden

Ein konkreter Unterschied im Betrieb kann die nächste Bereitstellung entscheiden: vLLM 0.31.0 veröffentlicht neben dem Standard-Image mit CUDA 13.0 auch ein Image mit CUDA 12.9. Die aktuelle Installationsanleitung von SGLang verlangt CUDA 13 und gibt an, dass die Image-Reihe für CUDA 12 mit 0.5.19 endete. Kann der vorhandene Hardwarebestand noch nicht auf eine kompatible Treiberumgebung umgestellt werden, ist das vor jedem Durchsatzvergleich zu klären. vLLM-Release-Artefakte, SGLang-Installation

OpenAI-kompatible Server: Der Client lässt sich leichter umziehen als der Workload

Beide Engines können hinter einem Client arbeiten, der Chat Completions im OpenAI-Stil nutzt. Beide dokumentieren /v1/chat/completions und /v1/completions. Dadurch muss weniger Verbindungscode in der Anwendung ersetzt werden. Es bedeutet aber nicht, dass jeder Endpunkt, jede Erweiterung, jeder Tool-Parser und jedes Modellverhalten austauschbar ist. vLLM-Server, SGLang-API

Ein Chat-Template wandelt Nachrichten mit Rollenkennzeichnung in die vom Modell erwartete Tokenfolge um. Beim Vergleich der Engines muss dieses Template gleich bleiben. Andernfalls werden womöglich unbemerkt unterschiedliche Prompts verglichen. Auch Modellrevision, Tokenizer, Sampling-Einstellungen und Ausgabelimit müssen übereinstimmen.

Bei einem bestehenden vLLM-Client sollten vor einer Migration oder einem Upgrade alte Felder für eingeschränkte Ausgaben geprüft werden. Laut Dokumentation wurden guided_json und verwandte Felder in 0.12.0 entfernt. Aktueller Code sollte die unterstützte Struktur mit structured_outputs oder response_format verwenden. Ein veralteter Anfragekörper kann wie eine Inkompatibilität der Engine wirken. vLLM-Migrationshinweis

Ergebnis: Gleichstand bei der grundlegenden Clientschnittstelle; vLLM bleibt die Standardempfehlung für den Betrieb. Der Abnahmetest sollte vollständige Agentendurchläufe abdecken, einschließlich gestreamter Tool-Argumente, Fehler und Wiederholungsversuche. Eine einzige erfolgreiche Textantwort reicht nicht aus.

Beide Engines in einer GPU-Cloud betreiben

Der Einstieg erfolgt mit einer festgeschriebenen Containerversion und einem kleinen Modell für den Funktionstest. Danach werden Produktionsmodell und Speicherbudget eingesetzt. Die folgenden Beispiele passen die dokumentierten Docker- und Startbefehle der Projekte für einen Linux-Host mit NVIDIA-GPU an. Vorausgesetzt werden Docker, die NVIDIA-Container-Laufzeit und ein zum Image passender Treiber. Die Beispiele wurden anhand der Dokumentation geprüft, aber nicht auf einer gemieteten GPU ausgeführt. vLLM mit Docker, SGLang-Schnellstart

Das unten verwendete Modell Qwen/Qwen3-0.6B dient zur Prüfung der Anbindung und ist keine Empfehlung für die Antwortqualität eines Agenten. Auf demselben Port darf jeweils nur eine Engine laufen. Die Kontextgrenze ist eine bewusst gewählte Beispieleinstellung und nicht das vom Modell beworbene Maximum.

vLLM-Container

docker run --rm --gpus all --ipc=host \
  -p 127.0.0.1:8000:8000 \
  -v "$HOME/.cache/huggingface:/root/.cache/huggingface" \
  vllm/vllm-openai:v0.31.0 \
  --model Qwen/Qwen3-0.6B \
  --host 0.0.0.0 --port 8000 \
  --max-model-len 8192 \
  --enable-prefix-caching

SGLang-Container

docker run --rm --gpus all --ipc=host \
  -p 127.0.0.1:8000:8000 \
  -v "$HOME/.cache/huggingface:/root/.cache/huggingface" \
  lmsysorg/sglang:v0.5.21 \
  python3 -m sglang.launch_server \
  --model-path Qwen/Qwen3-0.6B \
  --host 0.0.0.0 --port 8000 \
  --context-length 8192

Nach der Initialisierung wird diese Anfrage auf dem GPU-Host ausgeführt:

curl http://127.0.0.1:8000/v1/chat/completions \
  -H 'Content-Type: application/json' \
  -d '{
    "model": "Qwen/Qwen3-0.6B",
    "messages": [{"role": "user", "content": "Say hello."}],
    "max_tokens": 64
  }'

Die Beispiele binden den Host-Port an Loopback. Bevor externe Nutzer bedient werden, muss ein Anwendungsgateway mit Authentifizierung vor den Server geschaltet werden. Das ist bei vLLM besonders relevant: Laut Dokumentation authentifiziert --api-key nicht jede Route des HTTP-Servers. Geltungsbereich der vLLM-Authentifizierung

Der dokumentierte vLLM-Worker von Runpod

Runpod bietet über seinen Hub einen dokumentierten, einsatzfertigen vLLM-Worker an. Dieser vereinfachte Cloud-Einstieg stützt die Standardempfehlung für den Betrieb. Der Worker ist ein eigenständiges Bereitstellungspaket. Seine enthaltene Engine-Version muss geprüft werden; sie entspricht nicht zwangsläufig der neuesten Upstream-Version. Runpod-Anleitung zur Bereitstellung

Für SGLang besteht der hier beschriebene reproduzierbare Cloud-Weg aus dem offiziellen Container auf einem kompatiblen GPU-Host. Der vereinfachte Runpod-Einstieg oben bezieht sich ausdrücklich auf den von Runpod dokumentierten vLLM-Worker.

Kostenvergleich: Dieselbe GPU kostet bei beiden gleich viel

Bei gleicher gemieteter Kapazität ist keine Engine günstiger. Am 14. Oktober 2026 führte die aktuelle Preisseite von Runpod eine A100 PCIe mit 80 GB für $1.79/Stunde bei Pods auf. Das ist der Preis für eine dedizierte GPU, nicht der Abrechnungssatz des Serverless-Workers. Dieser gemeinsame Infrastrukturpreis bildet die Grundlage der folgenden Rechnung. Runpod-Preise

Bei einem Planungsmonat mit 730 Stunden kostet eine durchgehend bereitgestellte GPU sowohl mit vLLM als auch mit SGLang $1,306.70/Monat. Zwei kosten $2,613.40/Monat. Speicher, Netzwerkgebühren, Redundanz und Entwicklungsarbeit sind darin nicht enthalten.

Als einheitliches Rechenbeispiel dient ein hypothetischer Support-Workload: 50,000 Anfragen pro Monat mit jeweils 2,000 Eingabetokens und 200 Ausgabetokens. Das ergibt 100 Millionen Eingabetokens und 10 Millionen ausgelieferte Ausgabetokens. Passt dieser Workload bei der geforderten Antwortzeit auf eine GPU, beträgt die GPU-Rechnung bei beiden Engines $0.13067 je 1,000 ausgelieferte Ausgabetokens. Bezugsgröße sind die Ausgabetokens; bezahlt wird damit auch die Verarbeitung der Eingabe.

Das ist eine Kostenrechnung, keine Kapazitätsmessung. Reicht eine GPU für den Workload nicht aus, gilt das Ergebnis für eine einzelne GPU nicht.

Die Kostenschwelle liegt dort, wo eine Konfiguration ein zusätzliches Replikat benötigt, um dasselbe Serviceziel einzuhalten. Braucht SGLang eine GPU und vLLM zwei, spart SGLang $1,306.70/Monat. Zeigt die Kapazitätsmessung das umgekehrte Verhältnis, spart vLLM denselben Betrag. Kommen beide mit einer GPU aus, beträgt die Infrastrukturersparnis null.

Ein Migrationsbudget von 8 Stunden zu angenommenen $100/Stunde ergibt $800. Entfällt dadurch eine solche GPU, amortisiert sich die Migration nach etwa 0.61 Monaten, noch ohne Unterschiede im laufenden Betrieb. Ohne eingespartes Replikat oder einen als wertvoll bewerteten Servicegewinn kann „schneller“ wirtschaftlich völlig wirkungslos bleiben.

Beim Preis gewinnt die Konfiguration, die das Ziel mit geringeren Gesamtbetriebskosten erreicht. Eine belastbare, enginespezifische Lastschwelle lässt sich erst angeben, nachdem die unter den Vorgaben zuverlässig nutzbare Kapazität des eigenen Workloads gemessen wurde.

SGLang- und vLLM-Benchmark: Durchsatz unter Latenzvorgaben vergleichen

Dieser Vergleich ermittelt keinen allgemeingültigen Durchsatzsieger. Ein vom Projekt veröffentlichtes Ergebnis gilt für das verwendete Modell, die Hardware, die Rechengenauigkeit, die Anfragelängen und die Release-Version. Eine Kernel-Verbesserung ist keine Verbesserung des gesamten Serving-Ablaufs, und Prefill-Durchsatz ist nicht Ausgabetoken-Durchsatz. Daraus darf weder pauschal „SGLang ist schneller“ noch „vLLM ist schneller“ werden.

Als Ausgangspunkt eignen sich die Werkzeuge der Projekte: die Benchmark-CLI von vLLM und der Serving-Benchmark-Leitfaden von SGLang. Der Vergleich braucht Durchläufe mit gefülltem und leerem Cache sowie das Lastprofil, das das eigene Produkt tatsächlich erzeugt.

Vier Bedingungen sollten getrennt gemessen werden: kurze Chats mit einem stabilen gemeinsamen System-Prompt; wiederholte Fragen zu demselben langen Dokument; lange RAG-Prompts mit wechselnden abgerufenen Passagen; und die tatsächlich genutzte Mischung aus Schemas, Tool-Aufrufen und Adaptern. Neben der Parallelität müssen auch die zeitlichen Abstände der eintreffenden Anfragen erhalten bleiben. Ein Schub gleichzeitiger Anfragen kann andere Engpässe offenlegen als ein gleichmäßiger Strom.

Zu erfassen sind abgeschlossene Anfragen, ausgelieferte Ausgabetokens, Fehler und die Latenz bis zum ersten Token. Zusätzlich zählen die Latenzen p95 und p99, also das 95. und 99. Perzentil: Ein guter Durchschnitt kann einzelne sehr lange Wartezeiten verdecken. Ausgaben, die an den Schema- oder Korrektheitsprüfungen der Anwendung scheitern, zählen als Fehler und nicht als nutzbare Kapazität.

Es gewinnt die günstigste Bereitstellung, die innerhalb dieser Abnahmekriterien bleibt. Ein Geschwindigkeitsversprechen für ein anderes Modell oder eine ältere Version ist ein Anlass für diesen Vergleich, aber noch kein Ergebnis.

Engine wechseln: Schnittstellenvertrag erhalten und Rückweg offenhalten

Ein Wechsel der Serving-Schicht lohnt sich erst, wenn der gemessene Nutzen die Migrations- und Betriebskosten übersteigt. Werden nur die Backends für die Generierung ausgetauscht, können Anwendungsdaten und Retrieval-Speicher meist an ihrem bisherigen Ort bleiben. Die Arbeit steckt in der Modellpaketierung, den Anfrageerweiterungen, der Ausgabeverarbeitung und dem Verhalten bei der Bereitstellung.

Eine gut laufende vLLM-Bereitstellung sollte nicht allein wegen Prefix Caching oder JSON-Vorgaben ersetzt werden; beides ist bereits vorhanden. Ebenso wenig rechtfertigt die hiesige Standardempfehlung für vLLM einen Wechsel von einer gut laufenden SGLang-Installation. Vorhandenes Betriebswissen gehört in den Kostenvergleich.

Ist noch offen, ob überhaupt ein gemeinsam genutzter Produktionsserver gebraucht wird, hilft Ollama vs vLLM weiter. Dieser Vergleich behandelt die vorgelagerte Entscheidung zwischen einem komfortablen lokalen Modell-Workflow und einer Serving-Schicht für zeitlich überlappende Anfragen.

Der nächste Schritt: repräsentative Spitzenlast aufzeichnen, maximal akzeptable Antwortzeiten und Fehlerquote festlegen und die Engines in festgeschriebenen Versionen auf derselben Hardware vergleichen, bevor der Hardwarebestand erweitert wird.

Häufig gestellte Fragen

Die Checkliste für das Audit von KI-Geschäftsabläufen hilft dabei, den Workflow zu finden, der einen gemeinsam genutzten Modellserver rechtfertigt. Der Newsletter informiert über spätere Änderungen bei den Tools.