vLLM oder SGLang: Parallelität entscheidet über das Tempo

Ob vLLM oder SGLang für ein Team schneller ist, entscheidet sich unter der vorgesehenen Last. Ein einzelner Wert für generierte Tokens pro Sekunde reicht dafür nicht: Beide Server müssen dieselben Anfragen mit denselben Modellgewichten bearbeiten, während die Zahl gleichzeitiger Anfragen steigt. Erst dann wird sichtbar, wie viel Durchsatz bei akzeptabler Antwortzeit übrig bleibt.

Die Reihenfolge kann sich dabei ändern. In der SiliconBench-Messung mit Qwen3-0.6B in BF16 auf einem NVIDIA DGX Spark und jeweils 100 Chat-Anfragen pro Laststufe lieferte SGLang bei einer gleichzeitigen Anfrage 106,8 Output-Tokens pro Sekunde gegenüber 103,3 bei vLLM; bei 16 gleichzeitigen Anfragen lag vLLM mit 796,0 vor SGLang mit 734,1. Das ist ein Ergebnis dieser Konfiguration, kein allgemeiner Sieger für andere Modelle, Geräte oder Prompt-Muster.

Dieselbe Aufgabe für beide Server

Ein reproduzierbarer Vergleich beginnt mit einer festgelegten Modell- und Gewichtsrevision. Tokenizer, Präzision, Quantisierung, Kontextlänge, Chat-Template und Sampling-Parameter müssen ebenso dokumentiert werden wie Framework-Versionen und Startoptionen. Beide Kandidaten sollten nacheinander auf derselben GPU-Konfiguration laufen. Andernfalls lässt sich ein gemessener Abstand nicht eindeutig dem Serving-System zuordnen.

Der Prompt-Korpus muss die geplante Nutzung abbilden: kurze Chats, lange Eingaben, wiederkehrende System-Prompts, gewünschte Ausgabelängen und gegebenenfalls Anfragen mit Tool-Schemata. Synthetische Prompts eignen sich, um einzelne Faktoren kontrolliert zu verändern. Für die Auswahl ist zusätzlich ein bereinigter oder eigens erstellter Korpus sinnvoll, dessen Längen und Struktur der erwarteten Produktion entsprechen. Reihenfolge, Anfragezahl und Ausgabelimit bleiben in jedem Vergleichslauf gleich.

Die vLLM-Benchmarkübersicht unterscheidet Einzelbatch-Latenz, Online-Durchsatz sowie kalte und warme Startzeit. Für einen dauerhaft laufenden API-Server beantwortet der Online-Test die zentrale Leistungsfrage. Die Startzeit verdient eine eigene Messung, wenn Instanzen häufig hochgefahren werden; sie sollte nicht mit der Latenz bereits laufender Anfragen vermischt werden.

Eine Lastkurve statt eines Spitzenwerts

Die Messmatrix beginnt bei einer aktiven Anfrage und erhöht die Parallelität in mehreren Stufen bis zur erwarteten Spitzenlast. Eine mögliche, ausdrücklich beispielhafte Folge wäre 1, 4, 16 und 64 gleichzeitige Anfragen. Die letzte Stufe muss zur tatsächlichen Kapazitätsfrage passen; eine willkürlich hohe Obergrenze liefert wenig Orientierung. Wiederholte Läufe pro Stufe zeigen, ob der Abstand zwischen den Servern stabil bleibt.

Das SGLang-Werkzeug bench_serving kann SGLang und vLLM über ihre OpenAI-kompatiblen Endpunkte belasten und misst Durchsatz, Time to First Token (TTFT), Inter-Token-Latenz (ITL) und Antwortzeit. Für Chat-Anfragen sind auf beiden Seiten die Chat-Endpunkte zu wählen; ein nativer SGLang-Endpunkt und ein OpenAI-kompatibler vLLM-Endpunkt wären unterschiedliche API-Pfade. Streaming, Chat-Template und Anfrageformat gehören deshalb zur festgehaltenen Konfiguration.

Parallelitätsgrenze und Ankunftsrate beschreiben verschiedene Dinge. Treffen Anfragen selten ein, wird die erlaubte Parallelität kaum erreicht. Ein sofort versendeter großer Stapel erzeugt dagegen einen Lastfall mit Warteschlange. Für jede Stufe müssen daher auch Sendeprofil, tatsächlich erreichte Parallelität und erfolgreiche Antworten erfasst werden. So wird erkennbar, bei welcher Last die Antwortzeiten steigen oder Anfragen scheitern, obwohl der reine Token-Durchsatz noch wächst.

Warm-up und Präfix-Cache auseinanderhalten

Vor einer Laufzeitmessung sollten beide Server geladen und mit gleichen, vom eigentlichen Test getrennten Warm-up-Anfragen vorbereitet sein. Danach sind zwei Reihen sinnvoll: eine ohne wiederverwendete Testpräfixe und eine mit absichtlich wiederkehrenden Prompt-Anfängen. Die zweite Reihe ist besonders relevant, wenn die Anwendung häufig denselben langen System-Prompt oder gemeinsamen Kontext verwendet.

Die vLLM-Anleitung zur Benchmark-CLI warnt, dass wiederholte Läufe gegen denselben Server Prompts aus dem Präfix-Cache übernehmen und den gemessenen Durchsatz erhöhen können; sie nennt unter anderem Cache-Reset und Neustart als Gegenmaßnahmen. Für die kalte Reihe sollte ein möglicher Cache-Reset vor jedem Lauf erfolgen. Ist ein Neustart nötig, folgen zunächst Warm-up-Anfragen mit anderen Präfixen, damit die Initialisierung nicht wieder in die Messung gerät.

In der warmen Reihe müssen die gemeinsam genutzten Präfixe bei beiden Kandidaten gleich häufig vorkommen. Notieren Sie auch, ob sie schon vor dem Lauf im Cache liegen oder erst während des Laufs wiederverwendet werden. Diese Bedingungen können verschiedene Ergebnisse erzeugen. Ein gemeinsamer Durchschnitt aus kalten und warmen Läufen würde den Anteil der Cache-Wiederverwendung verschleiern, der in der späteren Anwendung tatsächlich zu erwarten ist.

Latenz, Durchsatz und Speicher gemeinsam auswerten

TTFT misst bei gestreamten Antworten die Zeit bis zur ersten Ausgabe. ITL erfasst die Abstände zwischen aufeinanderfolgenden Ausgaben. Für einen interaktiven Chat kann ein hoher Gesamtdurchsatz wenig nützen, wenn viele Nutzer lange auf den Beginn ihrer Antwort warten oder die Ausgabe danach stockt. Deshalb gehören Median und hohe Perzentile beider Werte zu jeder Parallelitätsstufe.

Ergänzen Sie die vollständige Antwortzeit, erfolgreiche Anfragen pro Sekunde, generierte Tokens pro Sekunde sowie die tatsächlich erzeugten Tokenmengen. Letztere sind nötig, weil unterschiedlich lange Antworten einen Durchsatzvergleich verzerren können. Das Ergebnis sollte für jede Laststufe zusammenbleiben: Der beste Durchsatz aus einem Lauf und die beste Latenz aus einem anderen ergeben keine reale Serverkonfiguration.

Auch belegter und maximal benötigter GPU-Speicher gehören in dieselbe Matrix, zusammen mit abgebrochenen Anfragen und Speicherfehlern. Ein Server kann bei einer Laststufe schnell sein und bei der nächsten an seine Speichergrenze geraten. Angezeigte Belegungswerte allein sind allerdings kein identisches Maß für nutzbare Reserve, wenn die Systeme Speicher unterschiedlich vorhalten. Entscheidend ist, welche Last mit der festgelegten Modellkonfiguration zuverlässig abgeschlossen wird.

Tool-Aufrufe als eigene Qualitätsprüfung

Bei Agenten-Anwendungen ist ein erfolgreicher HTTP-Request noch keine korrekte Antwort. Ein Testkorpus braucht Fälle, in denen ein bestimmtes Tool aufgerufen werden soll, und Fälle, in denen kein Aufruf nötig ist. Pro Antwort zählen der richtige Funktionsname, schema-konforme Argumente und das Ausbleiben unerwünschter Aufrufe. Ein reiner Serving-Benchmark bewertet diese fachliche Korrektheit nicht automatisch.

Speichern Sie dafür die vollständigen strukturierten Antworten und legen Sie die erwarteten Aufrufe vor dem Test fest. Benötigt ein Kandidat ein anderes Chat-Template oder einen anderen Tool-Parser, gehört diese Einstellung zur getesteten Konfiguration. Die Leistungswerte sind nur dann für die Agenten-Last aussagekräftig, wenn die gemessene Kombination die verlangten Aufrufe auch korrekt ausgibt.

Welcher Kandidat zur Last passt

Die Auswahl richtet sich nach der Laststufe, die der Dienst tatsächlich tragen muss. Zuerst müssen Antworten und Tool-Aufrufe korrekt sein. Unter den funktionierenden Konfigurationen zählt dann, welcher Server die geforderte Zahl gleichzeitiger Anfragen mit ausreichender Speicherreserve und innerhalb der eigenen Grenzen für TTFT und Antwortzeit bearbeitet. Der Durchsatz entscheidet innerhalb dieser Grenzen. Ändern sich Modell, Prompt-Muster oder Cache-Anteil, ist auch die Leistungsreihenfolge neu zu messen.

Lesen Sie auch: