vLLM, SGLang oder TensorRT-LLM: Welche Inference-Engine für den eigenen GPU-Server?

Wenn ein Mittelständler seinen ersten GPU-Server für ein eigenes Sprachmodell anschafft, dreht sich die Diskussion meist um Hardware: H100 oder L40S, 80 oder 141 GB Speicher, ein Knoten oder zwei. Die Software-Schicht darüber – die Inference-Engine – wird häufig erst nach der Bestellung entschieden. Das ist ein teurer Reflex, denn zwischen der schwächsten und der stärksten Engine auf identischer Hardware liegen im gemessenen Betrieb zweistellige Prozentpunkte Durchsatz.

Dieser Artikel vergleicht die drei Engines, die 2026 im professionellen On-Premise-Betrieb tatsächlich eine Rolle spielen: vLLM, SGLang und NVIDIA TensorRT-LLM. Grundlage sind reproduzierbare Messwerte, die offiziellen Release-Notes der Projekte und die Betriebserfahrung aus Installationen beim Kunden – nicht die Herstellerfolien.

Warum die Engine-Wahl bares Geld ist

Die Rechnung ist unspektakulär, aber sie trägt: Wenn Engine A auf derselben H100 2.400 Token pro Sekunde ausgibt und Engine B 2.780, dann bedienen Sie mit B rund 16 Prozent mehr gleichzeitige Nutzer aus demselben Gerät. Bei einer Auslegung auf 300 aktive Mitarbeiter ist das der Unterschied zwischen zwei und drei Karten – und damit zwischen einer Investition von rund 30.000 Euro und einer von 45.000 Euro, laufende Stromkosten und Rack-Platz noch nicht eingerechnet. Eine gesparte GPU refinanziert mehrere Wochen Tuning-Aufwand mit Leichtigkeit.

Noch deutlicher wird es, wenn man auf die Kosten pro Million Token schaut. In einem prefix-lastigen RAG-Szenario auf H100-On-Demand-Kapazität kostet eine Million ausgegebener Token rund 0,61 US-Dollar mit vLLM gegenüber 0,44 US-Dollar mit SGLang – rund 28 Prozent weniger, ohne dass ein einziges Hardware-Teil ausgetauscht wurde. Wer eine eigene Maschine betreibt, sieht denselben Effekt nicht auf der Rechnung, sondern in der Anzahl Nutzer, die er bedienen kann, bevor die zweite Karte fällig wird.

Ein zweiter Hebel wirkt unabhängig von der Engine-Wahl und wird trotzdem regelmäßig übersehen: die Zahlenpräzision. FP8 statt FP16 bringt auf einer H100 den rund 1,5- bis 2-fachen Durchsatz, weil die FP8-Tensor-Cores der Hopper-Generation die doppelte FLOP-Rate der FP16-Einheiten fahren. Alle drei hier verglichenen Engines unterstützen FP8. Wer noch in FP16 serviert, sollte diesen Schritt vor jeder Engine-Diskussion gehen – er ist billiger und wirkt stärker.

vLLM 2026: Model Runner V2 und KV-Offloading

vLLM ist die Referenzimplementierung des Model Serving im Open-Source-Ökosystem und der Default, mit dem die meisten On-Premise-Installationen starten. Zwei Releases haben den Sommer 2026 geprägt.

v0.23.0 – 15. Juni 2026

408 Commits von 200 Contributoren, davon 63 Erstbeiträge. Der wichtigste Punkt: Der Model Runner V2 (MRv2) ist hier per Default für Llama- und Mistral-Dense-Modelle aktiv, zusätzlich zu Qwen3 (PR #43458). MRv2 ist die überarbeitete Ausführungsschicht zwischen Scheduler und Kernel-Aufrufen; für Betreiber äußert sich das vor allem in geringerem CPU-Overhead pro Schritt und stabilerem Verhalten bei hoher Parallelität.

Der zweite relevante Baustein ist das KV-Cache-Offloading-Framework. v0.23.0 bringt einen Object-Store als Secondary Tier, aktiviert die Hierarchical Memory Architecture standardmäßig für kompatible Connectoren und erlaubt Offloading-Policies pro Request. Praktisch heißt das: Kontexte, die gerade nicht aktiv dekodiert werden, wandern aus dem knappen VRAM in Host-RAM oder einen angebundenen Objektspeicher und kommen bei Bedarf zurück – statt neu berechnet zu werden. Bei Chat-Anwendungen mit langen Sitzungspausen ist das der Unterschied zwischen einer schnellen Fortsetzung und einem vollständigen Prefill.

v0.24.0 – 29. Juni 2026

571 Commits von 256 Contributoren, davon 77 Erstbeiträge. Sicherheitsrelevant: Starlette wird auf Version 1.0.1 oder höher angehoben, um CVE-2026-48710 zu schließen. Wer eine vLLM-Instanz ins interne Netz stellt, sollte diesen Sprung nicht überspringen.

Wichtiger für die Betriebsplanung sind die Breaking Changes: vLLM setzt CUDA_VISIBLE_DEVICES nicht mehr intern, stattdessen gibt es das neue Argument device_ids. Wer seine Startskripte auf das alte Verhalten gebaut hat, bekommt nach dem Upgrade eine Instanz, die auf den falschen Karten landet. Zusätzlich wurden die Modell-Implementierungen für ERNIE, Xverse, Dots1, Bamba und Mono-InternVL entfernt; Qwen und QwenVL der ersten Generation sowie der Transformers-v4-Support sind als deprecated markiert. Upgrades sind bei vLLM also nicht folgenlos – sie gehören ins Wartungsfenster, nicht in den laufenden Betrieb.

SGLang und RadixAttention bei geteiltem Kontext

SGLang ist keine „vLLM-Alternative für alles", sondern eine Engine mit einer sehr spezifischen Stärke: geteilter Kontext. Ihr Kernstück ist RadixAttention – ein Radix-Baum über den bereits berechneten KV-Cache-Einträgen, der gemeinsame Prefixe token-genau wiederverwendet statt nur blockweise. Der Unterschied klingt akademisch, ist es aber nicht: Wenn zwei Anfragen sich 511 Token teilen und die Blockgröße 16 beträgt, kann ein blockweiser Cache 496 Token wiederverwenden, ein token-genauer 511.

Typische Kandidaten für geteilten Kontext im Mittelstand: ein langer System-Prompt mit Unternehmensregeln, der bei jedem Request identisch vorangestellt wird; Few-Shot-Blöcke in Klassifikationspipelines; wiederkehrende Referenzdokumente in einem RAG-Assistenten; Multi-Turn-Chats, bei denen jede Folgeantwort den kompletten bisherigen Verlauf enthält.

Was die Messung hergibt – und was nicht

In einem prefix-lastigen Szenario (80 Prozent geteilter 512-Token-Prefix, H100, Llama 3.3 70B in FP8, 50 parallele Requests) liefert SGLang 2.550 Token/s gegenüber 1.850 Token/s bei vLLM – rund 38 Prozent mehr. Noch deutlicher wird der Effekt bei der Time to First Token: 195 ms statt 310 ms im Median (37 Prozent niedriger) und 340 ms statt 580 ms im 95. Perzentil (41 Prozent niedriger). Für ein Chat-Frontend ist das der Unterschied zwischen „reagiert sofort" und „denkt kurz nach".

Ebenso wichtig ist der Gegentest: Bei Unique-Prompt-Workloads ohne geteilten Kontext liegen vLLM und SGLang praktisch gleichauf – 1.850 gegenüber 1.920 Token/s bei 50 parallelen Requests, also 2 bis 4 Prozent und damit innerhalb der Lauf-zu-Lauf-Varianz. RadixAttention bringt hier schlicht nichts, weil es nichts zu teilen gibt. Die häufig zitierte Marketingzahl „bis zu 5x schneller durch RadixAttention" stammt aus einem Blogpost von Januar 2024, gemessen gegen vLLM v0.2.5 auf einer A10G, und ist für eine Entscheidung im Jahr 2026 wertlos.

Als praktische Entscheidungsschwelle hat sich bewährt: Unter rund 40 Prozent Prefix-Overlap ist der SGLang-Vorteil marginal, ab rund 60 Prozent geteiltem Kontext wird er konsistent relevant. Diesen Wert können Sie aus Ihren eigenen Logs schätzen – Sie brauchen dafür keinen Benchmark, sondern nur die durchschnittliche Länge Ihres System-Prompts im Verhältnis zur durchschnittlichen Gesamt-Promptlänge.

Der aktuelle SGLang-Stand ist v0.5.16 vom 25. Juli 2026 mit 574 Pull Requests von 169 Contributoren. Neu sind unter anderem der UnifiedRadixTree als Default für SWA-, Mamba- und DSA-Modelle sowie DSpark, ein confidence-getriebenes Speculative-Decoding-Verfahren, das auf DeepSeek-V4-Pro 383,7 Token/s erreicht.

TensorRT-LLM: maximale Leistung, maximale Bindung

TensorRT-LLM ist NVIDIAs eigene Engine und beim reinen Durchsatz auf NVIDIA-Hardware der Spitzenreiter. Der Grund ist strukturell: Statt das Modell zur Laufzeit zu interpretieren, wird es in eine kompilierte Engine übersetzt, die auf die konkrete GPU-Architektur, die Zahlenpräzision und die geplanten Batch-Größen zugeschnitten ist. Was an Flexibilität verloren geht, kommt an Effizienz zurück.

Der gemessene Vorsprung – realistisch betrachtet

Ein Third-Party-Benchmark (Spheron, 2026) auf einer H100 SXM5 80 GB mit Llama 3.3 70B Instruct in FP8, 200 Prompts, im Schnitt 512 Token Input und 256 Token Output, ergibt folgendes Bild beim Output-Durchsatz:

Parallele Requests	vLLM	SGLang	TensorRT-LLM	Vorsprung TRT-LLM
1	120 Tok/s	125 Tok/s	130 Tok/s	+8,3 %
10	650 Tok/s	680 Tok/s	710 Tok/s	+9,2 %
50	1.850 Tok/s	1.920 Tok/s	2.100 Tok/s	+13,5 %
100	2.400 Tok/s	2.460 Tok/s	2.780 Tok/s	+15,8 %

Damit liegt TensorRT-LLM je nach Parallelität rund 8 bis 16 Prozent vor vLLM – nicht 15 bis 30 Prozent, wie es in vielen Sekundärquellen kolportiert wird. Der Vorsprung wächst mit der Concurrency, was zum kompilierten Ansatz passt: Je stärker die Maschine ausgelastet ist, desto mehr zahlt sich die optimierte Kernel-Auswahl aus. Bei der Latenz sieht es ähnlich aus: Bei zehn parallelen Requests liegt TensorRT-LLM bei 105 ms TTFT im Median und 170 ms im 95. Perzentil, vLLM bei 120 und 195 ms, SGLang bei 112 und 178 ms.

Die 1.000 Token/s pro Nutzer – korrekt eingeordnet

Die viel zitierte Zahl von über 1.000 Token pro Sekunde und Nutzer bei Llama 4 Maverick ist real, wird aber regelmäßig falsch datiert. Sie stammt aus einem NVIDIA-Blogpost vom 22. Mai 2025, nicht aus 2026, und beschreibt einen einzelnen DGX-B200-Knoten mit acht Blackwell-GPUs, TensorRT-LLM in FP8 und EAGLE-3-basiertem Speculative Decoding. Im Durchsatz-Maximum meldet derselbe Beitrag 72.000 Token/s pro Server. Das Speculative Decoding steuerte dabei etwa den Faktor 4 gegenüber der vorherigen Blackwell-Baseline bei – die Zahl ist also weniger ein Beleg für TensorRT-LLM als solches, sondern für die Kombination aus Hardware, Präzision und Draft-Modell.

Der Preis: Betriebsaufwand und Bindung

Für den Aufbau produktionsreifer kompilierter Engines sollten Sie ein bis zwei Wochen einplanen – pro Modell, pro Hardware-Generation, pro Präzisionsvariante. Jeder Modellwechsel wiederholt diesen Aufwand. Dazu kommt die Bindung an NVIDIA: Ein Wechsel auf AMD-Instinct- oder Intel-Gaudi-Beschleuniger bedeutet nicht nur neue Hardware, sondern eine komplett neue Serving-Schicht.

Ein Argument, das in der Praxis schwerer wiegt als erwartet, ist die Release-Kadenz. TensorRT-LLM veröffentlichte als letztes stabiles Release v1.2.1 am 20. April 2026 (Fix für eine KV-Cache-Korruption, aktualisierte xgrammar- und flashinfer-Komponenten). Gegenüber vLLM (v0.26.0, 27. Juli 2026) und SGLang (v0.5.16, 25. Juli 2026) ist das ein deutlich langsamerer Takt – und neue Modelle landen entsprechend früher bei den Open-Source-Engines. Ein konkretes Beispiel: Die Inkling-Modellfamilie wird sowohl in vLLM v0.26.0 als auch in SGLang v0.5.16 unterstützt, beide innerhalb derselben Juli-Woche. SGLang meldet für Inkling – ein multimodales MoE mit 975 Milliarden Parametern – auf Blackwell 71,7k Token/s Input und 171,0 Token/s Decode pro Nutzer.

FlashAttention 4 und Hardware-Defaults

Ein Teil des Leistungsunterschieds zwischen Setups entsteht gar nicht durch die Engine, sondern durch das darunterliegende Attention-Backend. Seit vLLM v0.20.0 ist FlashAttention 4 das Default-Backend auf Blackwell-GPUs mit SM100 und SM103 (B200, B300). Auf Hopper (SM90, also H100 und H200) bleibt FlashAttention 3 der Default, auf älteren Generationen FlashAttention 2. Überschreiben lässt sich das per --attention-config.flash_attn_version=2|3|4. In v0.20.0 wurde FA4 zusätzlich als Default-MLA-Prefill-Backend reaktiviert (Head-Dim 512, Paged-KV, ab SM90).

Der praktische Nutzen: bessere Prefill-Leistung bei langen Eingaben und ein sauberer Pfad für spekulatives Decoding – ohne dass Sie eine Zeile Konfiguration schreiben müssen. Vorausgesetzt, Sie fahren eine ausreichend aktuelle vLLM-Version. Wer noch auf v0.18 oder v0.19 steht, verschenkt hier Leistung, die er sich sonst mit teurerer Hardware erkaufen müsste.

Prefill-Decode-Disaggregation als Tuning-Hebel

Ein LLM-Request besteht aus zwei sehr unterschiedlichen Phasen. Der Prefill verarbeitet den gesamten Eingabe-Prompt in einem Rutsch und ist compute-bound – er sättigt die Recheneinheiten. Das Decode erzeugt Token für Token und ist memory-bandwidth-bound – es wartet auf Speicherzugriffe. Beide Phasen auf derselben Instanz mit derselben Parallelisierungsstrategie zu fahren, ist immer ein Kompromiss.

vLLM unterstützt deshalb Prefill-Decode-Disaggregation: getrennte Instanzen für beide Phasen, die unterschiedliche Tensor- und Pipeline-Parallelität (tp, pp) bekommen können. Der KV-Cache wird zwischen ihnen übertragen. Der Gewinn liegt in zwei Bereichen: Erstens lassen sich TTFT und Inter-Token-Latenz (ITL) unabhängig voneinander tunen. Zweitens – und das ist im Alltag oft wertvoller – wird die Tail-ITL stabiler, weil keine Prefill-Jobs mehr in laufende Decode-Schritte eingeschoben werden. Genau diese Einschübe erzeugen das „Stottern" in Chat-Oberflächen, das Nutzer als unruhig empfinden.

Entscheidungsmatrix nach Lastprofil

Die ehrliche Zusammenfassung lautet: Alle drei Engines sind gut. Der Unterschied liegt nicht in der Qualität, sondern in der Passung zum Lastprofil. Drei Szenarien decken die überwiegende Mehrheit der Mittelstandsprojekte ab.

Szenario 1 – Gemischte Last, häufige Modellwechsel: vLLM

Das ist der Normalfall: ein interner Assistent, ein paar Automatisierungen, gelegentliche Experimente mit einem neuen Modell. Hier zählt, wie schnell ein neues Modell produktiv ist – und da ist vLLM konkurrenzlos, weil es Modelle direkt von Hugging Face lädt, ohne Kompilierschritt. Der Rückstand von 8 bis 16 Prozent gegenüber TensorRT-LLM wiegt weniger schwer als die Fähigkeit, ein Modell an einem Nachmittag zu tauschen. Für die überwiegende Mehrheit der Installationen ist vLLM die richtige Erstentscheidung – und in vielen Fällen auch die letzte.

Szenario 2 – RAG mit langen, geteilten Prefixen: SGLang

Wenn Ihr System-Prompt 800 Token lang ist, jedes Request dieselben fünf Referenzdokumente mitschickt und Nutzer in Multi-Turn-Dialogen arbeiten, dann ist RadixAttention ein echter Hebel – vor allem auf die TTFT, die der Nutzer direkt spürt. Prüfen Sie vorher den Prefix-Overlap: unter 40 Prozent lohnt der Wechsel nicht, ab 60 Prozent klar. Und vergleichen Sie fair, also gegen vLLM mit aktiviertem Automatic Prefix Caching.

Szenario 3 – Fester Modellstand, maximaler Durchsatz, NVIDIA-only: TensorRT-LLM

Wenn das Modell für die nächsten zwölf Monate feststeht, die Hardware NVIDIA bleibt und die Auslastung dauerhaft hoch ist, holen Sie mit TensorRT-LLM die letzten 10 bis 16 Prozent. Bei einer Vier-GPU-Installation entspricht das grob einer halben Karte – das rechtfertigt ein bis zwei Wochen Setup. Bei einer Ein-GPU-Installation für 30 Nutzer rechnet es sich nicht.

Was Sie unabhängig von der Engine tun sollten

1. Erst messen, dann wechseln. Bestimmen Sie aus Ihren Logs den durchschnittlichen Prefix-Overlap und die typische Concurrency. Ohne diese zwei Zahlen ist jeder Engine-Vergleich Kaffeesatzleserei.
2. FP8 vor Engine-Tuning. Der Sprung von FP16 auf FP8 bringt auf H100 mehr als jeder Engine-Wechsel und kostet einen Konfigurationsparameter.
3. Versionsstand festschreiben. Bei zwei Wochen Release-Kadenz und regelmäßigen Breaking Changes brauchen Sie einen definierten Stand und ein Patch-Fenster – kein „latest" im Container-Tag.
4. Benchmarks mit der eigenen Last fahren. Fremde Zahlen zeigen Größenordnungen, nicht Ihr Ergebnis. Ein Nachmittag mit Ihren eigenen 200 Beispielprompts ist aussagekräftiger als jede Herstellertabelle.
5. Sicherheitsupdates nicht überspringen. CVE-2026-48710 in v0.24.0 ist ein Beispiel dafür, dass eine Inference-Engine ein exponierter HTTP-Dienst ist und entsprechend gepflegt werden muss.

Wenn Sie unsicher sind, welche Kombination aus GPU, Präzision und Engine zu Ihrem Lastprofil passt, rechnen wir das gern gemeinsam durch – von der Dimensionierung des On-Premise-KI-Servers bis zum laufenden Betrieb im KI-Full-Stack-Providing. Eine erste Kostenschätzung liefert Ihnen der TCO-Rechner.

Quellen & Primärbelege

Alle Zahlen, Fristen und Produktangaben in diesem Beitrag wurden vor der Veröffentlichung gegen die folgenden Primaerquellen geprüft.

1. GitHub v0.23.0
2. api.github.com v0.23.0
3. GitHub v0.24.0
4. api.github.com v0.24.0
5. GitHub releases.atom
6. GitHub releases
7. GitHub v0.20.0
8. vLLM-Dokumentation attention backends
9. vLLM-Dokumentation disagg prefill
10. api.github.com latest
11. api.github.com latest
12. NVIDIA Developer blackwell breaks the 1000 tps user barrier with metas llama 4 maverick

Häufig gestellte Fragen zum Engine-Vergleich

Reicht Ollama für den Produktivbetrieb?

Für Tests und Einzelplatz ja, für mehrere gleichzeitige Nutzer nein. Ollama liefert kein vergleichbares Continuous Batching und keine Prefill-Decode-Trennung; im Mehrbenutzerbetrieb liegen vLLM, SGLang und TensorRT-LLM deutlich vorn.

Wann lohnt sich der Aufwand für TensorRT-LLM?

Wenn das Modell fixiert ist, die Hardware NVIDIA-basiert bleibt und jeder Prozent Durchsatz zählt. Rechnen Sie mit ein bis zwei Wochen für kompilierte Engines und mit erneutem Aufwand bei jedem Modellwechsel.

Was bringt SGLang konkret bei RAG?

RadixAttention erkennt geteilte Prefixe token-genau und spart deren Neuberechnung. Bei Workloads mit langem gemeinsamem System-Prompt oder wiederkehrenden Dokumenten sind bis zu 38 % mehr Durchsatz gegenüber vLLM ohne Automatic Prefix Caching dokumentiert – mit aktiviertem APC schrumpft der Abstand deutlich.

Muss ich FlashAttention manuell konfigurieren?

Nein. Ab vLLM v0.20.0 ist FlashAttention 4 auf Blackwell-GPUs Default für die Standard-Attention-Pfade, auf Hopper bleibt FlashAttention 3 aktiv. Wichtig ist nur, eine ausreichend aktuelle vLLM-Version einzusetzen.