Die Wahl der Inference-Engine entscheidet 2026 ueber Throughput, Latenz und Hardware-Flexibilitaet. Vier Systeme haben sich durchgesetzt, und jedes adressiert einen spezifischen Engpass. Wer die falsche Engine waehlt, zahlt entweder mit GPU-Stunden oder mit Setup-Aufwand.
Ein wichtiger struktureller Shift: HuggingFaces Text Generation Inference (TGI), lange der Default-Baustein fuer Selfhosting, ist 2026 im Maintenance Mode. HuggingFace selbst empfiehlt offiziell vLLM und SGLang fuer neue Deployments. Wer heute aufsetzt, sollte TGI nicht mehr beruehren.
Ollama -- Lokale Entwicklung und Prototyping
Ollama ist die Antwort auf die Frage "Wie bekomme ich in fuenf Minuten ein LLM auf meinem Laptop zum Laufen?". Ein einziger Befehl reicht:
ollama run llama3.1
- Laeuft auf NVIDIA, AMD und Apple Silicon
- OpenAI-kompatible API als Drop-in-Replacement
- Null Grenzkosten pro Request, solange die Hardware ohnehin laeuft
- Ideal fuer Single-User-Apps, CI-Pipelines und schnelle Iteration vor Production
Die Schwaeche wird sichtbar, sobald mehr als eine Person gleichzeitig zugreift. Ollama betreibt kein echtes Request-Batching. Der Throughput plateauisiert bei rund 22 Requests pro Sekunde, unabhaengig davon, wie viel GPU-Speicher frei waere. Fuer Produktion mit mehreren Nutzern ist Ollama das falsche Werkzeug -- fuer die Entwicklungsphase davor das richtige.
vLLM -- Der Default fuer General Production
vLLM ist 2026 der sichere Default fuer produktive LLM-Deployments, wenn keine spezielle Anforderung dagegenspricht. Die Kern-Innovation heisst PagedAttention: Der GPU-Speicher fuer den KV-Cache wird in kleine Pages aufgeteilt, aehnlich wie virtueller Speicher in Betriebssystemen. Der Verschnitt sinkt von 60-80% auf unter 4%, und dieselbe GPU traegt dadurch deutlich mehr gleichzeitige Requests.
- Hardware-Support fuer NVIDIA, AMD, Intel und TPUs
- Breite Modell-Kompatibilitaet ueber das gesamte HuggingFace-Oekosystem
- Speculative Decoding fuer schnellere Generierung
- 3,5-facher Throughput-Gewinn gegenueber Legacy-Serving-Systemen
- 85-92% GPU-Utilization bei 100+ concurrent Users, wo aeltere Engines bei 68-74% haengen bleiben
Die Schwaechen zeigen sich an zwei Stellen: Bei extremer Last verschlechtert sich die First-Token-Response-Zeit sichtbar, und bei Workloads mit stark geteiltem Kontext liegt vLLM rund 29% hinter SGLang. Wer mehrheitlich einzigartige Prompts serviert und Hardware-Flexibilitaet ueber mehrere Clouds hinweg braucht, ist mit vLLM trotzdem am besten aufgehoben.
SGLang -- Multi-Turn Chat, RAG und Agentic Workflows
SGLang adressiert einen Fall, der erst durch Agenten und RAG massenhaft geworden ist: viele Requests teilen grosse Praefixe. Zehn Nutzer stellen unterschiedliche Fragen zum selben Systemprompt oder zum selben Dokument-Kontext. Klassische Engines verarbeiten den geteilten Teil zehnmal. SGLang tut es einmal.
Die Kern-Innovation heisst RadixAttention: Ein Radix-Baum indexiert bereits berechnete KV-Caches und erkennt gemeinsame Praefixe zwischen Requests automatisch. Cache-Eintraege werden wiederverwendet, sobald die Token-Sequenz uebereinstimmt.
- 29% hoeherer Throughput auf H100 (16.200 vs. 12.500 Tokens/sec gegenueber vLLM)
- 75-95% Cache-Reuse in realistischen Agent- und RAG-Workloads
- 3x schnellere strukturierte JSON-Generierung durch constrained decoding
- Produktions-Scale bereits bewiesen: ueber 400.000 GPUs bei xAI, Microsoft Azure, LinkedIn und Cursor
Der Vorteil verschwindet, sobald jeder Prompt einzigartig ist -- dann faellt SGLang hinter vLLM zurueck, weil der Radix-Overhead ohne Cache-Treffer ungenutzt bleibt. Das Oekosystem ist kleiner als bei vLLM, Community-Tutorials sind duenner gesaet. Wer Agent-Pipelines mit geteilten Systemprompts, Chat-Verlaeufen oder RAG-Kontexten baut, findet in SGLang trotzdem die beste verfuegbare Engine.
TensorRT-LLM -- Maximum Performance auf NVIDIA
TensorRT-LLM ist die Engine fuer Faelle, in denen jedes Prozent Throughput zaehlt und die Hardware-Plattform feststeht. NVIDIA optimiert hier gegen die eigene Chip-Architektur, statt portablen Code zu erzeugen.
- 15-30% hoeherer Throughput als vLLM bei identischer Hardware
- Speculative Decoding mit 3,6-facher Generierungs-Geschwindigkeit
- Direkte Tensor-Core-Integration, FP8- und INT8-Quantisierung
- Nahtlose Kopplung an den Triton Inference Server
- 1.000 Tokens/sec pro User auf Blackwell
Der Preis dafuer ist hoch. Jedes Modell muss vor dem Serving mindestens 28 Minuten kompiliert werden, und jeder Modell-Wechsel erfordert eine neue Kompilierung. Die Lernkurve ist steil, Debugging schmerzhaft, Multi-Cloud-Portabilitaet nicht vorhanden. TensorRT-LLM rechnet sich, wenn ein Deployment lange steht und die Performance-Differenz in GPU-Kostenersparnis umschlaegt -- nicht fuer Setups, in denen Modelle woechentlich rotieren.
Entscheidungsframework
| Anforderung | Engine | Begruendung |
|---|---|---|
| Setup in fuenf Minuten, lokal | Ollama | One-command, Mehr-User-Load nicht noetig |
| Shared Context in vielen Requests | SGLang | RadixAttention liefert 29% Throughput-Vorteil |
| Einzigartige Prompts, Multi-Cloud | vLLM | Hardware-Flexibilitaet und breite Kompatibilitaet |
| Long-lived NVIDIA-Only, Performance kritisch | TensorRT-LLM | 15-30% Gewinn rechtfertigt Kompilierungs-Overhead |
Einordnung
Fuer Entwickler, die lokal arbeiten, bleibt Ollama der kuerzeste Weg vom Download zum funktionierenden Modell. Wer in Produktion geht, nimmt vLLM als sicheren Default und weicht nur begruendet davon ab: SGLang, sobald Agent- oder RAG-Workflows mit geteiltem Kontext dominieren, und TensorRT-LLM ausschliesslich bei NVIDIA-gebundenen Long-lived Deployments mit spuerbarem Performance-Druck.
Die Wahl der Inference-Engine ist keine akademische Frage. Sie entscheidet darueber, wie viele Nutzer eine GPU gleichzeitig bedient, wie schnell das erste Token erscheint und ob man morgen noch die Cloud wechseln kann. Eine Engine pro Workload-Typ -- nicht eine Engine fuer alles.