vLLM vs Ollama: Tokens pro Sekunde unter Last realistisch vergleichen

TL;DR

Ollama und vLLM liefern bei einer einzelnen Anfrage fast identischen Durchsatz. Unter paralleler Last dreht sich das Bild: vLLM aggregiert Anfragen per Continuous Batching und erreicht das 2- bis 19-Fache an Tokens pro Sekunde. Ollama bleibt einfacher im Betrieb. Faustregel: bis zwei aktive Nutzer Ollama, ab mehreren gleichzeitigen Anfragen vLLM.

Wer self-hosted LLMs evaluiert, stolpert schnell über einen Widerspruch: Ollama läuft in fünf Minuten, fühlt sich schnell an — und trotzdem behaupten Benchmarks, vLLM sei um ein Vielfaches schneller. Beides stimmt. Der Unterschied liegt nicht in der Modellqualität, sondern darin, wie beide Tools mit mehreren gleichzeitigen Anfragen umgehen. Genau das entscheidet, ob ein GPU-Server 15 oder 150 Mitarbeiter bedient.

Dieser Beitrag zeigt die realen Durchsatz-Zahlen aus öffentlichen Benchmarks, erklärt die Architektur dahinter und gibt eine klare Empfehlung, wann welches Tool die richtige Wahl ist.

Der eine Benchmark, der alles verändert: Concurrency

Bei genau einer Anfrage zur Zeit gibt es kaum einen Grund, sich zwischen den Tools zu entscheiden. Beide landen am Ende auf denselben Matmul-Kernels der GPU. Einzelne Messungen zeigen Ollama sogar leicht vorn (ca. 45 gegenüber 38 Tokens/s bei Single-Request-Latenz), andere geben vLLM einen kleinen Vorsprung. Die Differenz liegt im einstelligen Prozentbereich und ist für die Tool-Wahl irrelevant.

Interessant wird es bei paralleler Last. Aus mehreren unabhängigen Benchmarks 2025/2026:

Quellen: SitePoint-Benchmark 2026, Tech-Insider (Red-Hat-Analyse 08/2025), Markaicode. Die absoluten Zahlen schwanken je nach Modell, GPU und Prompt-Länge — der Trend ist über alle Quellen konsistent.

Der Punkt, der oft untergeht: Ollamas Gesamtdurchsatz sinkt unter Last teilweise sogar, weil Anfragen in einer FIFO-Queue nacheinander abgearbeitet werden. vLLMs Gesamtdurchsatz steigt mit der Anzahl paralleler Anfragen, bis die GPU gesättigt ist. Das ist kein Tuning-Detail, sondern ein architektonischer Unterschied.

Genauso wichtig wie der Mittelwert ist die Streuung. vLLM zeigt in den Messungen niedrigere p95- und p99-Latenzen, weil Continuous Batching die Anfragen gleichmäßig durchschiebt statt sie stauen zu lassen. Für einen Chat-Assistenten, den 80 Mitarbeiter parallel nutzen, ist eine vorhersehbare Antwortzeit oft mehr wert als der reine Spitzendurchsatz. Ein Nutzer, der gelegentlich acht Sekunden auf den ersten Token wartet, empfindet das System als kaputt — auch wenn der Durchschnitt gut aussieht.

Warum der Unterschied so groß ist

Ollama: llama.cpp mit FIFO-Queue

Ollama ist ein komfortabler Wrapper um llama.cpp. Das Modell wird als quantisiertes GGUF geladen, läuft auf CPU, GPU oder gemischt und ist in Minuten einsatzbereit. Der Preis für diese Einfachheit: Anfragen werden im Kern sequenziell verarbeitet. Kommt eine zweite Anfrage rein, während die erste noch generiert, wartet sie im Wesentlichen. Die GPU ist zwischen den Token-Schritten oft nicht ausgelastet.

Für einen einzelnen Entwickler am Laptop oder ein kleines Team spielt das keine Rolle. Für einen geteilten Server mit vielen gleichzeitigen Chat-Sessions wird es zum Flaschenhals.

vLLM: PagedAttention und Continuous Batching

vLLM ist von Grund auf für Serving-Durchsatz gebaut. Zwei Mechanismen tragen die Last:

PagedAttention verwaltet den KV-Cache wie ein Betriebssystem den Arbeitsspeicher — in Pages statt in einem starren Block. Das reduziert die Speicherverschwendung im KV-Cache um bis zu 96 Prozent gegenüber naiven Implementierungen. Weniger verschwendeter VRAM heißt: mehr gleichzeitige Anfragen passen auf dieselbe GPU.

Continuous Batching verschachtelt laufende Anfragen im selben GPU-Batch. Statt einen Batch zu füllen, komplett abzuarbeiten und dann den nächsten zu starten, kann vLLM fertige Sequenzen sofort durch neue ersetzen. Die GPU bleibt durchgehend beschäftigt.

Das Ergebnis für ein 70B-Modell auf einer einzelnen H100: vLLM serviert laut Benchmarks etwa das Acht- bis Neunfache an aggregierten Tokens gegenüber einem Ollama-Deployment auf identischer Hardware.

VRAM-Effizienz und Konfiguration

Beim Speicher zeigen sich beide Philosophien deutlich. Ollama quantisiert standardmäßig aggressiv (oft Q4), lädt schnell und läuft auch auf Consumer-GPUs oder sogar CPU. vLLM will die GPU voll ausnutzen und reserviert vorab einen festen Anteil des VRAM für den KV-Cache.

Ein produktionsnaher vLLM-Start für ein großes Modell auf zwei GPUs sieht so aus:

# vLLM als OpenAI-kompatibler Server im Docker-Container
docker run --gpus all --ipc=host -p 8000:8000 \
  -e HUGGING_FACE_HUB_TOKEN=$HF_TOKEN \
  vllm/vllm-openai:latest \
  --model meta-llama/Llama-3.3-70B-Instruct \
  --dtype fp8 \                       # FP8 halbiert den KV-Cache-Bedarf
  --tensor-parallel-size 2 \          # Modell auf 2 GPUs verteilen
  --max-model-len 16384 \             # Kontextfenster begrenzen spart VRAM
  --gpu-memory-utilization 0.92 \     # 92 % des VRAM für Weights + KV-Cache
  --max-num-seqs 512 \                # parallele Sequenzen im Batch
  --enable-chunked-prefill \          # lange Prompts stückeln
  --kv-cache-dtype fp8

Die relevanten Stellschrauben:

• --gpu-memory-utilization steuert, wie viel VRAM vorab reserviert wird. Typisch 0,85–0,92 in Produktion. Mehr Reservierung heißt mehr Platz für den KV-Cache und damit mehr Concurrency.
• --kv-cache-dtype fp8 und --dtype fp8 reduzieren den Speicherbedarf spürbar. Ein 70B-Modell mit 32k Kontext und 10 gleichzeitigen Nutzern braucht rund 112 GB KV-Cache in FP16, aber nur etwa 56 GB in FP8.
• --tensor-parallel-size verteilt die Modellgewichte über mehrere GPUs und gibt jeder GPU mehr freien Speicher für den Cache.

Ollama ist dagegen kaum konfigurationsbedürftig. Modell ziehen, starten, fertig:

# Ollama: Modell laden und als HTTP-API bereitstellen
ollama pull llama3.1:8b
ollama run llama3.1:8b

# Parallele Verarbeitung erhöhen (Standard ist konservativ)
OLLAMA_NUM_PARALLEL=4 OLLAMA_MAX_LOADED_MODELS=2 ollama serve

OLLAMA_NUM_PARALLEL hebt die Zahl paralleler Slots an — das mildert das Concurrency-Problem, schließt die Lücke zu vLLM aber nicht. Die grundlegende Serving-Architektur bleibt eine andere.

Ein praktischer Nebeneffekt der Quantisierung: Ollama bekommt ein 8B-Modell in Q4 auf einer 12-GB-Consumer-GPU zum Laufen, während vLLM in FP16 dieselbe GPU sprengen würde. Das ist kein Widerspruch zu den Durchsatz-Zahlen, sondern eine andere Zielsetzung. Ollama optimiert dafür, dass ein Modell überhaupt und schnell startet. vLLM optimiert dafür, dass eine bewusst dimensionierte GPU so viele Anfragen wie möglich gleichzeitig trägt. Wer die vLLM-Reservierung zu knapp setzt, riskiert Out-of-Memory-Fehler bei langen Prompts; wer sie zu hoch setzt, lässt keinen Puffer für Spitzen. Diese Kalkulation entfällt bei Ollama komplett — der Preis dafür ist der niedrigere Durchsatz unter Last.

Setup-Aufwand und Betrieb

Hier gewinnt Ollama klar, und das sollte man nicht kleinreden. Die Installation dauert Minuten, es gibt keine GPU-Memory-Kalkulation, Modelle wechselt man mit einem Befehl. Wer schnell einen internen Prototyp braucht oder ein Team mit einer Handvoll Nutzern bedient, ist mit Ollama am schnellsten produktiv. Eine detaillierte Anleitung dazu finden Sie in unserem Beitrag zur Ollama-Installation auf Ubuntu.

vLLM verlangt mehr: passende CUDA-Umgebung, bewusste VRAM-Planung, oft mehrere GPUs. Ein weiterer Punkt für Auto-Scaling-Szenarien ist der Cold-Start — Benchmarks nennen rund 3,2 Sekunden für Ollama gegenüber etwa 8,7 Sekunden für vLLM. Wer Instanzen dynamisch hoch- und runterfährt, spürt das. Bei dauerhaft laufenden Servern ist es irrelevant.

Ein oft unterschätzter Betriebsaspekt ist die Modellauswahl. Ollama pflegt eine kuratierte Bibliothek fertig quantisierter Modelle, die per ollama pull in Sekunden verfügbar sind. vLLM lädt Modelle direkt vom Hugging-Face-Hub und erwartet, dass Sie Format, Quantisierung und Kontextlänge selbst passend wählen. Das gibt mehr Kontrolle, verlangt aber auch mehr Wissen über die Trade-offs zwischen AWQ, GPTQ und FP8. Für ein Team ohne dedizierte ML-Ops-Rolle ist das ein realer Aufwand, der in die Entscheidung gehört.

Unsere Empfehlung: vLLM nicht wegen der Zahlen einführen, sondern wenn der Bedarf da ist. Ein GPU-Server, der solide dimensioniert werden muss — dazu haben wir einen eigenen Hardware-Guide für KI-Server geschrieben.

Direkter Vergleich

Beide sprechen die OpenAI-API, ein späterer Wechsel ist deshalb selten ein großer Bruch. Wer heute mit Ollama startet und morgen auf vLLM umzieht, muss die Client-Integration meist nicht anfassen.

Wann welches Tool — unsere Position

Die Tool-Wahl hängt fast ausschließlich an der Concurrency, nicht am Modell und nicht am Feature-Set.

Ollama nehmen, wenn Sie einen Prototyp bauen, ein Team mit ein bis zwei aktiven Nutzern gleichzeitig bedienen, auf gemischter oder schwacher Hardware arbeiten oder KI lokal am Arbeitsplatz laufen soll. Der Betriebsaufwand ist minimal, und bei geringer Parallelität verschenken Sie praktisch nichts.

vLLM nehmen, sobald mehr als zwei bis drei gleichzeitige Anfragen dauerhaft auf einer GPU landen. Ab diesem Punkt rechtfertigt allein PagedAttention den Umstieg, weil der Durchsatzunterschied unter Last eine Größenordnung erreicht. Ein einzelner gut ausgelasteter vLLM-Server ersetzt oft einen ganzen Ollama-Cluster.

Wovon wir abraten: vLLM einführen, "weil es schneller ist", obwohl real nie mehr als eine Handvoll Anfragen pro Stunde reinkommen. Dann zahlen Sie Setup-Komplexität und längeren Cold-Start, ohne den Durchsatzvorteil je zu nutzen. Die Zahlen aus den Benchmarks gelten unter Sättigung — bei leerer Queue sind beide gleich schnell.

Beide Wege halten Ihre Daten im eigenen Haus. Warum das für viele Mittelständler der eigentliche Treiber ist, behandeln wir im Beitrag zu KI on-premise ohne Cloud. Wer eine Nutzeroberfläche darüberlegen will, kombiniert beides gern mit Open WebUI im Docker-Setup.

Häufig gestellte Fragen

Ist vLLM immer schneller als Ollama? Nein. Bei einer einzelnen Anfrage sind beide praktisch gleich schnell, weil sie dieselben GPU-Kernel nutzen. vLLMs Vorsprung entsteht erst unter paralleler Last durch Continuous Batching — dort sind es je nach Modell und Auslastung Faktor 2 bis 19.

Was kostet vLLM im Vergleich zu Ollama? Beide sind Open Source und kostenlos. Der Unterschied liegt im Betrieb: vLLM verlangt in der Regel dedizierte GPUs mit ausreichend VRAM und mehr Einrichtungsaufwand, während Ollama auch auf Consumer-Hardware oder gemischt mit CPU läuft. Die Hardware-Kosten dominieren, nicht die Software.

Kann ich später von Ollama zu vLLM wechseln? Ja, meist ohne großen Aufwand. Beide bieten eine OpenAI-kompatible API. Ihre Anwendungen sprechen denselben Endpunkt, sodass der Wechsel sich oft auf das Austauschen des Servers und der Basis-URL beschränkt.

Wie viele gleichzeitige Nutzer bedient ein Ollama-Server? Ein einzelner Server mit einer starken GPU bedient grob 15–20 gleichzeitige Nutzer akzeptabel; darüber steigen Latenz und Timeout-Risiko. Mit OLLAMA_NUM_PARALLEL lässt sich das etwas verbessern, aber für dauerhaft hohe Parallelität ist vLLM die robustere Wahl.

Was ist PagedAttention und warum ist es relevant? PagedAttention verwaltet den KV-Cache in Speicher-Pages statt in einem starren Block und reduziert die Speicherverschwendung um bis zu 96 Prozent. Dadurch passen mehr gleichzeitige Anfragen auf dieselbe GPU — der technische Kern von vLLMs Durchsatzvorteil.

Fazit und nächster Schritt

Die Entscheidung ist keine Frage von "besser oder schlechter", sondern von Last. Bis zu einer Handvoll paralleler Anfragen ist Ollama die pragmatische Wahl mit minimalem Aufwand. Sobald ein geteilter Server viele gleichzeitige Sessions tragen muss, spielt vLLM seine Architektur aus. Bevor Sie ein Tool festlegen, messen Sie Ihre reale Concurrency — starten Sie mit unserer Ollama-Anleitung und ziehen Sie erst auf vLLM um, wenn die Queue wirklich voll läuft.