- Published on
vLLM vs. SGLang vs. TensorRT-LLM: welcher Server wofür
- Authors

- Name
- Phillip Pham
- @ddppham
Inferenzserver im Vergleich: vLLM, SGLang und TensorRT-LLM
TL;DR
vLLM ist die vernünftige Standardwahl: breiteste Modellunterstützung, größte Verbreitung, ausreichender Durchsatz. SGLang gewinnt bei Arbeitslasten mit vielen gemeinsamen Präfixen — also genau bei RAG mit gleichem Systemprompt. TensorRT-LLM holt auf NVIDIA-Hardware das Letzte heraus und kostet dafür erheblichen Betriebsaufwand.
Was die drei überhaupt tun
Ein Inferenzserver lädt Modellgewichte und beantwortet Anfragen. Die Unterschiede liegen darin, wie er mit vielen gleichzeitigen Anfragen umgeht — und genau dort entscheidet sich, wie viele Nutzer eine Karte bedient.
Drei Techniken, die alle drei in unterschiedlicher Ausprägung beherrschen:
Continuous Batching. Neue Anfragen steigen in einen laufenden Stapel ein, statt auf dessen Ende zu warten. Der wichtigste Einzelfaktor für den Durchsatz bei mehreren Nutzern.
Seitenweise Speicherverwaltung. Der KV-Cache wird in Blöcken verwaltet statt am Stück reserviert. Das reduziert Verschnitt erheblich und erlaubt mehr parallele Sitzungen bei gleichem Speicher.
Präfix-Wiederverwendung. Wenn mehrere Anfragen denselben Anfang haben — etwa denselben Systemprompt —, wird der zugehörige KV-Cache geteilt statt neu berechnet.
Der dritte Punkt ist der, an dem sich die drei unterscheiden, und er ist für Unternehmensanwendungen relevanter, als er klingt.
vLLM: die vernünftige Standardwahl
Für die meisten Installationen ist die Entscheidung hier zu Ende, und das ist keine Bequemlichkeit.
Was dafür spricht: die breiteste Modellunterstützung — neue Architekturen sind meist zuerst hier verfügbar. Eine OpenAI-kompatible Schnittstelle. Prometheus-Kennzahlen ab Werk. Und die größte Nutzerbasis, was praktisch bedeutet: Wenn Sie ein Problem haben, hatte es jemand vor Ihnen.
vllm serve /models/qwen3-30b-a3b \
--served-model-name standard \
--max-model-len 32768 \
--gpu-memory-utilization 0.90 \
--enable-prefix-caching \
--max-num-seqs 32
--enable-prefix-caching ist der Schalter, den man kennen sollte. Bei RAG-Anwendungen, in denen jede Anfrage denselben Systemprompt trägt, spart er messbar Rechenzeit in der Prompt-Verarbeitung. Er ist in neueren Versionen teils standardmäßig aktiv — prüfen Sie es für Ihre Version.
Wo vLLM an Grenzen stößt: bei sehr hoher Präfix-Überlappung und bei Arbeitslasten mit vielen kurzen, strukturell ähnlichen Anfragen.
SGLang: wenn viele Anfragen denselben Anfang haben
SGLang setzt auf eine Baumstruktur für den KV-Cache, die gemeinsame Präfixe systematisch wiederverwendet. Bei Arbeitslasten, in denen ein langer Systemprompt oder ein gemeinsamer Dokumentenkontext bei vielen Anfragen identisch ist, ist das ein struktureller Vorteil.
Der Fall, in dem sich das lohnt, ist konkreter, als er klingt: Ein RAG-Assistent mit einem 800-Token-Systemprompt und Few-Shot-Beispielen, den 200 Mitarbeiter nutzen. Jede Anfrage trägt dieselben ersten 800 Token. Ohne Präfix-Wiederverwendung werden sie jedes Mal neu berechnet.
Was Sie einplanen sollten: Die Modellunterstützung ist etwas schmaler als bei vLLM, und die Verbreitung geringer. Bei einer neuen Modellarchitektur warten Sie unter Umständen länger.
Unsere Empfehlung: Wenn Ihre Arbeitslast dieses Muster hat, testen Sie es gegen vLLM mit aktivierter Präfix-Zwischenspeicherung — der Abstand ist dann kleiner als die Vergleichszahlen im Netz suggerieren, aber er kann bestehen.
TensorRT-LLM: das letzte Prozent, teuer bezahlt
TensorRT-LLM kompiliert das Modell in eine hardwarespezifische Ausführungsform. Das Ergebnis läuft auf NVIDIA-Karten schneller als eine allgemeine Implementierung — der Preis ist ein zusätzlicher Arbeitsschritt vor jedem Einsatz.
Was das im Betrieb bedeutet: Ein Modellwechsel ist nicht mehr "Gewichte laden und starten", sondern ein Kompilierlauf mit eigener Konfiguration für Batchgröße, Sequenzlänge und Quantisierung. Ändern sich diese Parameter, kompilieren Sie neu. Bei einem Treiber- oder Bibliotheksupdate ebenfalls.
Für ein Unternehmen mit einer oder zwei GPUs steht dieser Aufwand in keinem Verhältnis zum Gewinn. Für einen Betrieb mit zwanzig Karten, bei dem 15 Prozent mehr Durchsatz drei Karten einspart, sieht die Rechnung anders aus.
Klare Position: Wenn Sie diesen Artikel lesen, um eine Entscheidung für Ihre erste Installation zu treffen, ist TensorRT-LLM nicht Ihre Antwort.
Die Entscheidung
| Situation | Empfehlung |
|---|---|
| Erste produktive Installation | vLLM |
| Häufige Modellwechsel oder neue Architekturen | vLLM |
| Langer gemeinsamer Systemprompt, viele Nutzer | SGLang testen, gegen vLLM messen |
| Zweistellige Kartenzahl, stabile Konfiguration | TensorRT-LLM prüfen |
| Einzelnutzer, Erprobung | Ollama, keiner der drei |
Der letzte Punkt ist ernst gemeint: Für Erprobung und Einzelplätze ist ein Inferenzserver dieser Klasse überdimensioniert. Wann der Wechsel fällig wird, steht im Beitrag zur Migration von Ollama auf vLLM.
Was Sie selbst messen müssen
Alle Vergleichszahlen im Netz — auch die groben Einordnungen in diesem Artikel — sind für Ihre Kaufentscheidung wertlos. Der Durchsatz hängt an Modell, Quantisierung, Kontextlänge, Gleichzeitigkeit, Karte und Versionsstand.
Was zählt, ist eine Messung mit Ihrer Last:
vllm bench serve \
--model /models/qwen3-30b-a3b \
--dataset-name random \
--random-input-len 2048 \
--random-output-len 512 \
--max-concurrency 32 \
--num-prompts 500
Setzen Sie --random-input-len auf Ihre reale Kontextlänge — bei RAG mit acht abgerufenen Abschnitten sind das eher 2.000 bis 4.000 Token als 128. Und messen Sie bei der Gleichzeitigkeit, die Sie erwarten, nicht bei einer einzelnen Anfrage. Die Zahl, die zählt, ist der aggregierte Ausgabedurchsatz.
Häufig gestellte Fragen
Welcher Inferenzserver ist der schnellste?
Das hängt vollständig von der Arbeitslast ab. TensorRT-LLM erreicht auf NVIDIA-Hardware bei fester Konfiguration die höchsten Werte, SGLang gewinnt bei hoher Präfix-Überlappung, vLLM liegt in einem breiten Feld an Aufgaben konstant gut. Ohne eine Messung mit Ihrem Modell, Ihrer Kontextlänge und Ihrer Gleichzeitigkeit ist die Frage nicht beantwortbar.
Was bringt Präfix-Zwischenspeicherung bei RAG?
Sie vermeidet die wiederholte Verarbeitung identischer Prompt-Anfänge. Bei einer RAG-Anwendung, in der jede Anfrage denselben mehrere hundert Token langen Systemprompt trägt, wird dieser Teil einmal berechnet und danach wiederverwendet. Der Gewinn steigt mit der Länge des gemeinsamen Präfixes und der Zahl paralleler Nutzer.
Lohnt sich TensorRT-LLM für ein mittelständisches Unternehmen?
In der Regel nicht. Der Kompilierschritt vor jedem Einsatz macht Modellwechsel und Konfigurationsänderungen zu Vorgängen statt zu Neustarts, und Treiber- oder Bibliotheksupdates erzwingen neue Läufe. Bei ein bis vier Karten steht dieser Aufwand in keinem Verhältnis zum Durchsatzgewinn.
Kann ich zwischen den Servern wechseln?
Ja, wenn Ihre Anwendungen über ein Gateway laufen und alle drei eine OpenAI-kompatible Schnittstelle bereitstellen. Dann ist der Wechsel eine geänderte Adresse in der Gateway-Konfiguration. Ohne Gateway müssten Sie jede Anwendung anfassen — ein weiterer Grund, eines davorzusetzen.
Wie messe ich, ob mein Inferenzserver ausgelastet ist?
Über die Kennzahlen, die der Server selbst bereitstellt: die Zahl laufender und wartender Anfragen sowie die Auslastung des KV-Cache. Wartende Anfragen bei niedriger Cache-Auslastung bedeuten, dass die Obergrenze paralleler Sequenzen zu niedrig steht. Ein voller Cache bedeutet, dass Sie mehr Speicher oder weniger Kontext brauchen.
Der nächste Schritt
Nehmen Sie vLLM, messen Sie mit Ihrer realen Kontextlänge und Gleichzeitigkeit, und schauen Sie sich das Ergebnis an. Wenn es reicht, ist die Entscheidung gefallen — in den meisten mittelständischen Installationen reicht es. Bei der Auslegung schauen wir gern mit.
📖 Verwandte Artikel
Weitere interessante Beiträge zu ähnlichen Themen
Von Ollama zu vLLM: wann der Pilot produktiv werden muss
Ollama trägt den Piloten, nicht den Betrieb. Die vier Signale für den Wechsel auf vLLM — und die Migration Schritt für Schritt.
vLLM Cluster: 70B-Modelle auf Multi-GPU self-hosted
vLLM Cluster für Multi-GPU-Inferenz: Llama-3.3-70B auf 2-4 GPUs verteilen, Tensor-Parallelismus und Ray-Multi-Node konfigurieren — mit echten Configs.
vLLM vs Ollama: Durchsatz-Benchmark self-hosted 2026
vLLM vs Ollama im Durchsatz-Benchmark: bis 19x mehr Tokens/s unter Last durch Continuous Batching. Welches Tool wann self-hosted passt.
Bereit für KI im Mittelstand?
Nutzen Sie unsere 10 kostenlosen KI-Tools und Praxis-Guides – oder sprechen Sie direkt mit unseren Experten.
Pexon Consulting – KI-Beratung für den Mittelstand | Scaly Academy – Geförderte KI-Weiterbildung (KI-Spezialist, KI-Experte, Workflow-Automatisierung)