vLLM schlägt SGLang bei 64K-Token-Prompts, aber SGLang übernimmt die Führung, sobald der Kontext auf 200K steigt – auf einem 8-GPU B300-Server. Dieser Umschwung zeigt, dass bei größeren Token-Fenstern Engpässe in der Decode-Phase und nicht die Prefill-Arbeit die Performance bestimmen.

Warum dieser Benchmark wichtig ist

Long-Context-Inferenz treibt die Kosten für Chat-Assistenten, Code-Assistenten und jede Anwendung voran, die Hunderttausende von Token im Speicher halten muss. Kimi-K3, ein Modell mit einer großen Anzahl an Parametern, ist eines der ersten Open-Weight-LLMs, das solche Fenster problemlos bewältigen kann, aber die Engine, die es ausführt, entscheidet darüber, ob eine Anfrage in Sekunden oder Minuten abgeschlossen ist.

Sowohl vLLM als auch SGLang versprechen eine Inferenz mit hohem Durchsatz, verfolgen jedoch gegensätzliche Ansätze in der Decode-Phase. vLLM hält den Decode-Pfad einfach und vermeidet die zusätzliche Synchronisierung, die durch Decode Context Parallelism (DCP) eingeführt wird. SGLang verteilt die Lesezugriffe auf den Key-Value (KV)-Cache über mehrere GPUs mittels DCP – eine Technik, die die Speicherbandbreite auf Kosten zusätzlicher Kommunikation amortisieren kann.

Der Testaufbau

  • Hardware: ein einzelner Server mit acht NVIDIA B300 GPUs, jede mit identischem Speicher.
  • Workloads: zwei Einstellungen für die Kontextlänge – 64 K Token (die Untergrenze für „Long Context“) und 200 K Token (die Obergrenze, die viele Forschungsdemos anstreben).
  • Metriken: Gesamtzeit zur Verarbeitung eines festen Batches von Prompts; der Durchsatz leitet sich aus der Zeitdifferenz ab.

Wir hielten die Batch-Größe, die Modellgewichte und die Ziele für die Speicherauslastung konstant. Der einzige Parameter, den wir zwischen den Durchläufen geändert haben, war die Inferenz-Engine.

Die nackten Zahlen

Kontext Engine Zeit (s) Relative Geschwindigkeit
64 K vLLM 100,5 –
SGLang 150,8 vLLM ≈ 1,5× schneller
200 K vLLM 295,2 –
SGLang 225,3 SGLang ≈ 1,31× schneller

Der Durchsatz (Token pro Sekunde) sank bei vLLM dramatisch, als der Kontext wuchs: ein Rückgang um das 3,29-Fache von 64 K auf 200 K. Der Durchsatz von SGLang sank im gleichen Bereich nur um das 1,25-Fache.

Woher die Differenz kommt

Beide Engines verbringen eine ähnliche Zeit in der Prefill-Phase – dem Laden des Prompts in den KV-Cache. Die Divergenz zeigt sich in der Decode-Phase, in der das Modell Token einzeln generiert.

  • 64 K Token: Die Kommunikation zwischen den GPUs dominiert. Der Single-GPU-Decode-Pfad von vLLM umgeht die durch DCP erforderliche zusätzliche Synchronisierung, wodurch es etwa 1,5× schneller fertig ist.
  • 200 K Token: Der KV-Cache wird so groß, dass das Lesen zum Engpass wird. SGLangs DCP, das auf eine Größe von 8 eingestellt ist, verteilt diese Lesezugriffe auf alle acht GPUs. Der Bandbreitengewinn überwiegt den Kommunikationsnachteil, was SGLang einen klaren Vorsprung verschafft.

Eine sekundäre, praktische Beobachtung betrifft den Speicherdruck. Das Ausführen einer der beiden Engines mit einem Zielwert für die Speicherauslastung von 0,95 löste auf den B300s Out-of-Memory (OOM)-Retries aus. Eine Senkung des Zielwerts auf 0,92 eliminierte die Retries und stabilisierte die Laufzeiten, allerdings auf Kosten eines moderaten Anstiegs der Latenz.

Wer gewinnt, wer verliert

  • Entwickler mit kurzen bis mittleren Kontexten (≤ 64 K Token) profitieren mehr vom schlanken Decode-Pfad von vLLM. Schnellere Antwortzeiten führen zu niedrigeren Cloud-Computing-Rechnungen und einer flüssigeren User Experience.
  • Teams, die Deep-Analysis- oder Forschungstools entwickeln, die Hunderttausende von Token im Kontext halten müssen, sollten zu SGLang mit aktiviertem DCP tendieren. Dessen konstanterer Durchsatz reduziert das Risiko von Timeouts und hält die GPU-Auslastung hoch, wenn der Speicherbedarf steigt.
  • Hardware-Planer sehen, dass die reine Anzahl der GPUs allein keine lineare Skalierung garantiert. Wenn die KV-Bandbreite zum Engpass wird, werden Architekturen, die Cache-Lesezugriffe parallelisieren können – entweder über DCP oder zukünftige Upgrades des Speicher-Subsystems – mehr Wert aus derselben Hardware herausholen.

Gegenargument: Kann vLLM den Rückstand aufholen?

Bis neue Daten vorliegen, stellen die aktuellen Zahlen den besten öffentlichen Vergleich dar.

Worauf man als Nächstes achten sollte

  • Größere Kontextfenster werden die KV-Bandbreite noch stärker beanspruchen und den Vorsprung von SGLang potenziell vergrößern.

Fazit

Wenn Sie Long-Context-Anfragen auf einem B300-basierten Cluster bedienen müssen, wählen Sie die Engine, die zu Ihrem Token-Fenster passt. Bei Workloads mit 64 K Token liefert vLLM eine etwa 1,5× schnellere Inferenz. Gehen Sie über 200 K Token hinaus, und SGLangs DCP-gesteuerter Decode wird zur effizienteren Wahl, da sein Durchsatz nur um das 1,25-Fache sinkt, verglichen mit dem 3,29-fachen Rückgang bei vLLM. Passen Sie die Speicherauslastung auf 0,92 an, um OOM-Retries zu vermeiden, und denken Sie daran, dass die „beste“ Engine kontextabhängig ist und keine Einheitslösung darstellt.