LLM in der Produktion betreiben: vLLM vs. SGLang vs. Ollama

Ein Unternehmen setzt ein lokales Modell über Ollama auf, schreibt einen internen Chatbot, das Team liebt ihn. Drei Monate später kommen weitere Nutzer hinzu, die Warteschlange wächst, die Antwortzeit steigt von zwei auf fünfzehn Sekunden. Jemand sagt: „Wir kaufen eine stärkere GPU." Die GPU wird gekauft. Die Antwortzeit sinkt auf acht Sekunden. Das Problem ist nicht die Hardware — das Problem ist ein Serving-Stack, der nicht für Produktionslasten ausgelegt war.

Das ist ein Szenario, das wir immer wieder sehen. Nicht weil die Teams etwas Falsches tun — Ollama ist ein hervorragendes Werkzeug für den Zweck, für den es gebaut wurde. Das Problem entsteht, wenn ein Entwicklungswerkzeug in die Produktion wandert, ohne dass jemand die Frage stellt: „Was brauchen wir eigentlich von einem Serving-Stack?" Dieser Artikel bietet Entscheidungskriterien statt pauschaler Empfehlungen — denn die richtige Wahl hängt von Last, Team und Infrastruktur ab.

Warum der Serving-Stack mehr zählt, als es scheint

Ein Serving-Framework ist kein bloßer „Wrapper um das Modell". Es ist ein Orchestrator, der entscheidet, wie parallele Anfragen gebatcht werden, wie der KV-Cache verwaltet wird und wie der Speicher bei mehreren gleichzeitigen Anfragen zugewiesen wird.

Klassisches Static Batching wartet, bis eine Charge gefüllt ist, und sendet dann alle Requests auf einmal — das Modell läuft durch, die Ergebnisse kommen zurück, dann wartet man auf den nächsten Batch. Das ist einfach, aber die Effizienz sinkt, wenn kurze und lange Requests gemischt ankommen. Continuous Batching (implementiert in vLLM, SGLang und TGI) löst dieses Problem anders: Jeder generierte Token ist eine Gelegenheit, einen neu eingetroffenen Request in den Batch aufzunehmen. Das Ergebnis ist ein 2–3-fach höherer Durchsatz ohne Hardware-Änderung.

Eine weitere kritische Dimension ist die Verwaltung des KV-Cache — der Zwischenergebnisse der Attention, die für jeden Token im Kontext gespeichert werden. Eine naive Implementierung reserviert Speicher für die maximale mögliche Kontextlänge im Voraus, auch wenn die meisten Requests wesentlich kürzer sind. PagedAttention (vLLM) löst dieses Problem, indem es den KV-Cache ähnlich wie ein Betriebssystem den RAM in Seiten einteilt — ohne Vorab-Reservierung, mit dynamischer Allokation. Das Ergebnis ist eine dramatische Reduktion der Fragmentierung: von typischerweise 60–80 % Verschwendung auf unter 4 %.

Diese Unterschiede machen sich im Produktionsbetrieb mit Dutzenden gleichzeitiger Requests um ein Vielfaches stärker bemerkbar, als einfache Benchmarks auf einer einzelnen Anfrage zeigen.

vLLM: Durchsatz als oberste Priorität

vLLM ist der De-facto-Standard für produktiven LLM-Betrieb, wenn maximaler Durchsatz auf NVIDIA-GPUs die primäre Priorität ist. Es entstand an der UC Berkeley, verfügt über das breiteste Integrations-Ökosystem und wird aktiv weiterentwickelt.

Wichtigste technische Eigenschaften:

• PagedAttention — KV-Cache-Verwaltung über virtuelle Seiten, reduziert die Speicherfragmentierung drastisch und ermöglicht höheren Parallelismus
• Continuous Batching — dynamisches Hinzufügen von Requests zum laufenden Batch ohne Wartezeit
• OpenAI-kompatibles API — die Migration von Cloud-API auf Self-Hosted ist meist nur eine Frage der URL- und API-Key-Änderung
• Unterstützung für NVIDIA, AMD (ROCm), Google TPU, Intel Gaudi
• Native Unterstützung für GPTQ-, AWQ-, FP8- und NVFP4-Quantisierung
• XGrammar-Backend für strukturierten Output (JSON-Modus) mit einem Overhead von unter 40 µs pro Token

Wann vLLM klar die Nase vorn hat:

Wenn Sie einen API-Endpunkt betreiben, auf den mehrere Nutzer oder Prozesse gleichzeitig zugreifen — interner Unternehmens-Chatbot, RAG-Backend mit höherem Volumen, API-Server für eine Produktionsanwendung. Bei Benchmarks auf Single-Request-Latenz ist der Unterschied zur Konkurrenz geringer. Aber bei 8, 16 oder 32 gleichzeitigen Requests zeigt sich die Differenz deutlich.

Auf Blackwell-GPUs mit NVFP4-Quantisierung zeigen Benchmarks einen bis zu ~16-fach höheren Durchsatz gegenüber Ollama bei identischer Hardware — ein Unterschied, der die Wirtschaftlichkeit des gesamten Projekts verändert.

Einschränkungen:

vLLM hat eine steilere Lernkurve. Die Konfiguration für den Produktiveinsatz setzt voraus, Parameter wie --tensor-parallel-size, --max-model-len und --gpu-memory-utilization zu verstehen. Für ein Team ohne LLM-Infrastrukturerfahrung ist das initiale Setup nicht trivial. Für reine CPU-Umgebungen oder Endverbraucher-Hardware ohne NVIDIA-GPU ist das Ökosystem schwächer.

SGLang: komplexe Workloads und strukturierter Output

SGLang (Structured Generation Language) entstand im Forschungsumfeld mit Fokus auf eine andere Klasse von Problemen: Multi-Turn-Konversationen, agentische Workloads mit langen Prefixen und strukturiertem Output (JSON-Schemata, Grammatiken).

Die zentrale Innovation ist RadixAttention — ein LRU-Cache für KV-Werte, organisiert als Radix-Baum. Wenn mehrere Requests denselben Prefix teilen (z. B. denselben System-Prompt oder denselben Dokumentenkontext), berechnet SGLang diesen Prefix einmal und teilt ihn zwischen den Requests. In Agentic-RAG-Szenarien, wo jeder Request mit demselben langen Dokumentenkontext beginnt, kann das einen enormen Unterschied machen.

Wo SGLang vLLM übertrifft:

Bei prefix-intensiven Workloads zeigen Benchmarks ~29 % höheren Durchsatz auf H100 und ~23 % niedrigere TTFT (Time to First Token) — 79 ms vs. 103 ms. Das sind keine vernachlässigbaren Zahlen bei interaktiven Anwendungen, bei denen die TTFT die wahrgenommene Geschwindigkeit direkt beeinflusst.

Für strukturiertes Dekodieren (JSON-Modus, Grammatiken) ist SGLang schneller: Constraint-Dekodierung läuft ~3-mal schneller als bei älteren Implementierungen, da die Grammatik-Kompilierung effizienter abläuft.

Typische Anwendungsfälle, in denen SGLang glänzt:

• Multi-Turn-agentische Workloads, bei denen jede Runde einen langen Verlaufs-Prefix teilt
• Batch-Inferenz über ein großes Dokumentenkorpus mit demselben System-Prompt
• Anwendungen mit intensivem JSON-Output (Extraktion strukturierter Daten, Klassifikation)
• RAG-Pipelines, in denen dasselbe Dokument innerhalb einer Sitzung mehrfach abgefragt wird

Einschränkungen:

SGLang hat ein etwas kleineres Ökosystem als vLLM, und die Community ist kleiner — was sich in der Geschwindigkeit bei der Behebung von Randfällen und der Verfügbarkeit von Dokumentation bemerkbar macht. Bei Standard-Inferenz-Workloads ohne Prefix-Optimierungen ist der Unterschied zu vLLM geringer, und die Wahl hängt eher von der Teampräferenz ab.

Ollama: Developer Experience an erster Stelle

Ollama ist eine andere Kategorie von Werkzeug. Es ist kein produktiver Serving-Framework — es ist ein Entwickler-Desktop-Tool, das eine Sache hervorragend macht: Es ermöglicht, ein lokales Modell in fünf Minuten ohne Konfiguration auf beliebiger Hardware zu starten, einschließlich Mac, Linux und Windows.

Unter der Haube läuft llama.cpp, das für CPU-Inferenz und die effiziente Arbeit mit GGUF-quantisierten Modellen optimiert ist. Für Single-User-Experimente und Entwicklung ist das der perfekte Stack.

Wo Ollama Sinn ergibt:

• Entwickler-Desktop — lokale Experimente, Prototyping, Modelltest
• Single-User-interne Tools mit geringer Last (ein bis zwei gleichzeitige Nutzer)
• Teams ohne DevOps-Erfahrung, die schnell etwas Funktionierendes brauchen
• Mac- oder Windows-Umgebungen, wo vLLM/SGLang keine native GPU-Unterstützung haben (oder diese eingeschränkt ist)
• On-Device-Einsatz auf Entwicklerlaptops

Warum Ollama für die Produktion nicht ausreicht:

llama.cpp, das unter Ollama läuft, ist nicht für gleichzeitige Requests ausgelegt. Wenn 8 parallele Requests eintreffen, wird die Warteschlange seriell abgearbeitet — ohne Continuous Batching. Benchmarks zeigen konsistent, dass vLLM auf identischer Hardware bei 8 gleichzeitigen Requests ~2,3-mal schneller ist. Bei 16 Requests ist der Unterschied noch größer.

Das ist kein Bug von Ollama — es ist die Konsequenz von Designentscheidungen, die Einfachheit und Kompatibilität vor Durchsatz stellen. Für den Entwickler-Desktop ist das der richtige Trade-off. Für einen Produktionsendpunkt mit Dutzenden von Nutzern ist es ein Problem.

Entscheidung nach Last und Team

Statt einer pauschalen Empfehlung bieten wir eine Entscheidungsmatrix:

Kleines Team (2–5 Personen), Einstieg in lokale LLMs, Experimentieren: Beginnen Sie mit Ollama. Sie lernen die Arbeit mit Modellen ohne Infrastrukturaufwand. Wenn Sie an Leistungsgrenzen stoßen (und das werden Sie), wird klar sein, warum eine Migration notwendig ist.

Produktiver API-Endpunkt mit mehreren gleichzeitigen Nutzern, NVIDIA-GPU: vLLM ist die Standardwahl. Breitestes Ökosystem, beste Dokumentation, OpenAI-kompatibles API. Wenn das Team keine LLM-Infrastrukturerfahrung hat, rechnen Sie damit, dass das Setup Tage, nicht Stunden in Anspruch nimmt.

Agentische Anwendungen, RAG mit langen wiederkehrenden Prefixen, intensiver JSON-Output: Erwägen Sie SGLang — RadixAttention spart GPU-Speicher und Latenz bei prefix-intensiven Workloads. Für Teams, die bereits vLLM einsetzen und es funktioniert, gibt es keinen Grund, allein wegen marginaler Verbesserungen zu migrieren. SGLang ist relevant, wenn Sie wissen, dass Ihr Workload prefix-intensiv ist.

NVIDIA Blackwell (GB200/B200), maximale Leistung: vLLM oder TensorRT-LLM — beide sind für NVFP4-Quantisierung auf Blackwell-GPUs optimiert. TensorRT-LLM hat eine höhere Peak-Leistung, aber deutlich höhere Setup- und Betriebskomplexität.

Reguliertes Umfeld, Air-Gapped-Netzwerk, keine Cloud-Abhängigkeiten: Alle drei laufen vollständig offline. Für produktive Deployments in regulierten Umgebungen empfehlen wir vLLM wegen des Ökosystems und der Auditierbarkeit. Mehr zu den Besonderheiten regulierter Deployments im Artikel On-Prem-LLM für regulierte Branchen.

Was ein Serving-Stack nicht ist: Abgrenzung von Quantisierung und GPU-Sizing

Wenn Unternehmen anfangen, „wie setzt man LLMs ein" zu klären, vermischen sich regelmäßig drei Themen: Serving-Stack, Quantisierung und GPU-Sizing. Das sind separate Entscheidungen mit unterschiedlicher Priorität.

Quantisierung ist die Entscheidung über die numerische Präzision der Modellgewichte (FP16 vs. Q8 vs. Q4 vs. GPTQ/AWQ). Sie beeinflusst die Modellgröße im Speicher und die Inferenzgeschwindigkeit bei akzeptablem Qualitätsverlust. Q4_K_M liegt bei den meisten Benchmarks ~5–8 % unter FP16 — ein Unterschied, der bei den meisten Produktions-Use-Cases nicht wahrnehmbar ist. Quantisierung ist orthogonal zur Wahl des Serving-Stacks: Sie können ein quantisiertes Modell sowohl über vLLM als auch über Ollama betreiben. Mehr zu den Formaten im Artikel LLM-Quantisierung (GGUF, AWQ, GPTQ).

GPU-Sizing ist die Entscheidung, wie viel VRAM (und wie viele GPUs) Sie für ein gegebenes Modell und eine gegebene Last benötigen. Das ist eine separate Kalkulation: VRAM für die Modellgewichte + KV-Cache für die erwartete Anzahl gleichzeitiger Requests × Kontextlänge. Ein schlechter Serving-Stack auf der richtigen Hardware wird trotzdem nicht performant sein; der richtige Serving-Stack auf unterdimensionierter Hardware ebenfalls nicht. Mehr zu konkreten VRAM-Kalkulationen im Artikel Welche GPU für LLM-Inferenz.

Die Reihenfolge der Entscheidungen in der Praxis: zunächst Modell (Größe, Fähigkeiten), dann Quantisierung (reduziert Speicherbedarf), dann GPU-Sizing (wie viel VRAM wird benötigt), zuletzt Serving-Stack (wie wird die Last bedient). Viele Teams machen das in umgekehrter Reihenfolge und wundern sich dann, warum Optimierungen nicht ausreichen.

KV-Cache und langer Kontext: die versteckte Speicherlast

Eine Zahl, die bei Serving-Stack-Vergleichen unterschätzt wird: Der KV-Cache wächst linear mit der Kontextlänge. Für ein 70B-Modell bei 128K Kontext kann der KV-Cache allein etwa 40 GB belegen — zusätzlich zu den Modellgewichten. Für vier parallele Requests mit einem solchen Kontext sind das ~160 GB extra.

Moderne Modelle mit Grouped Query Attention (GQA) reduzieren diese Last gegenüber klassischer Multi-Head-Attention dramatisch — die meisten aktuellen Modelle (Llama 4, Qwen 3, Mistral Large) haben GQA. Eine weitere Optimierung ist KV-Cache-Quantisierung auf INT8/FP8, die die Größe bei minimalem Qualitätsverlust halbiert.

Bei Workloads mit langem Kontext — etwa der Verarbeitung langer industrieller Dokumente oder mehrstufiger Konversationen im technischen Support — ist diese Zahl bei der GPU-Konfigurationsentscheidung entscheidend. vLLM verwaltet den KV-Cache über PagedAttention dynamisch und effizienter als naive Implementierungen; SGLang teilt den KV-Cache via RadixAttention zusätzlich für wiederkehrende Prefixe.

Praktische Konsequenz: „1M-Token-Kontextfenster" klingt für Kunden hervorragend. In der Praxis beansprucht jeder Request mit 1M Token Dutzende Gigabyte KV-Cache. Für die meisten Produktions-Use-Cases ist RAG wirtschaftlich effizienter als das Befüllen des gesamten Dokuments in den Kontext — auch wenn das Modell technisch langen Kontext unterstützt.

Monitoring und Observability im Produktivbetrieb

Egal für welchen Serving-Stack Sie sich entscheiden — produktiver Betrieb ohne Monitoring ist Blindflug. Drei Metriken, die vom ersten Tag an überwacht werden sollten:

TTFT (Time to First Token) — wie lange es dauert, bis das Modell den ersten Token produziert. Beeinflusst die wahrgenommene Geschwindigkeit bei interaktiven Anwendungen direkt. Bei konversationellen UIs ist eine TTFT unter 300–500 ms die Grenze, bei der ein Nutzer die Reaktion als „sofortig" empfindet.

Durchsatz (Token/Sekunde) — global und per Request. Wichtig für Batch-Workloads und bei der Kapazitätsplanung.

Queue-Tiefe und Warteschlangenlatenz — wenn die Warteschlange wächst, ist das ein Signal für horizontales Skalieren oder eine Überprüfung der Batching-Konfiguration. Eine wachsende Warteschlange bei stabiler TTFT zeigt an, dass das Problem die Kapazität ist, nicht die Serving-Effizienz.

vLLM und SGLang exportieren Prometheus-Metriken nativ — ein Grafana-Dashboard ist eine Stunde Arbeit. Für Teams, die auch die Kostenseite im Blick haben, ist LLM-Routing ein interessanter Ansatz: einfache Requests an ein kleineres, günstigeres Modell senden, komplexe an ein größeres. Mehr dazu im Artikel LLM-Routing und Cascading.

Häufige Fragen

Kann ich Ollama in der Produktion einsetzen, wenn ich nur einen oder zwei gleichzeitige Nutzer habe?

Ja, bei wirklich kleinen Lasten — ein Team, wenige Personen, niedrige Request-Frequenz — funktioniert Ollama im Produktiveinsatz. Das Problem entsteht beim Wachstum. Wenn sich die Last verdoppelt und Ollama nicht mehr ausreicht, ist die Migration auf vLLM keine triviale Änderung: anderes Konfigurationsmodell, anderes Prozessmanagement, andere Deployment-Patterns. Wenn Sie absehen, dass die Last wachsen wird, lohnt es sich, den Serving-Stack von Anfang an richtig aufzubauen.

Ist vLLM oder SGLang besser für RAG-Anwendungen?

Das hängt von der konkreten RAG-Architektur ab. Wenn jeder Request mit demselben System-Prompt mit geringer Variabilität beginnt und kurze Dokumente sich bei jedem Request ändern, sind vLLM und SGLang vergleichbar. Wenn die Architektur einen langen Dokumentenkontext über mehrere Requests in einer Sitzung teilt (z. B. Analyse eines langen Handbuchs mit mehreren Fragen), kann RadixAttention in SGLang erheblich Speicher und Latenz sparen. Mehr zu RAG-Architekturen unter Agentic RAG.

Wie unterscheidet sich vLLM von TensorRT-LLM?

TensorRT-LLM von NVIDIA erreicht auf NVIDIA-Hardware (insbesondere Blackwell) eine höhere Peak-Leistung dank Fused Kernels und NVFP4-Quantisierung. Der Preis ist eine deutlich höhere Komplexität: Modelle müssen vor dem Deployment kompiliert werden, die Pipeline ist weniger flexibel, das Setup dauert länger. vLLM ist in den meisten Produktionsszenarien die pragmatischere Wahl — Sie bekommen 80–90 % der TensorRT-LLM-Leistung bei einem Bruchteil der operativen Komplexität. TensorRT-LLM lohnt sich bei extremen Durchsatzanforderungen oder wenn Sie ein bestimmtes Modell auf bestimmter Hardware optimieren.

Funktionieren diese Frameworks auch mit quantisierten Modellen?

Ja, alle drei unterstützen quantisierte Modelle. vLLM und SGLang verarbeiten native AWQ- und GPTQ-Formate und haben FP8/NVFP4-Unterstützung für Blackwell-GPUs. Ollama arbeitet primär mit dem GGUF-Format (llama.cpp). Für produktive Deployments auf NVIDIA-GPUs ist AWQ oder GPTQ in der Regel vorteilhafter als GGUF, da optimierte CUDA-Kernel genutzt werden. Für Cross-Platform- oder CPU-Deployment ist GGUF praktischer.

Wie schnell lässt sich von Ollama auf vLLM migrieren?

Wenn Ihre Anwendung über ein OpenAI-kompatibles REST-API kommuniziert (was bei den meisten Ollama-Deployments der Fall ist), ist die Migration auf vLLM aus Sicht des Anwendungscodes nur eine Änderung von Base-URL und API-Key. Der größere Aufwand liegt auf der Infrastrukturseite: Deployment, Monitoring, Kapazitätskonfiguration. Für ein Team, das das zum ersten Mal macht, kalkulieren Sie ein bis zwei Arbeitstage für ein funktionierendes Produktions-Deployment.

*Bei MP Industrial Solutions helfen wir Unternehmen, eine LLM-Infrastruktur zu entwerfen und einzusetzen, die der realen Last und dem Team entspricht — nicht nur einer Demo. Wenn Sie klären möchten, welcher Serving-Stack für Ihren Use-Case der richtige ist, oder wenn Ollama unter Last zu stocken beginnt, besprechen wir das gerne gemeinsam.*