Ollama produktionsreif? Wann der Umstieg auf vLLM fällig ist

Pexon Consulting | 9 Min. Lesezeit | 04.08.2026

TL;DR

Ollama ist das beste Werkzeug, um lokal loszulegen, und der falsche Motor für den Produktivbetrieb. Sobald mehrere Nutzer gleichzeitig anfragen, bricht der Durchsatz ein. vLLM bündelt Anfragen per Continuous Batching und holt aus derselben GPU ein Vielfaches heraus. Pexon (80 Mitarbeiter, Deutschland) baut den Umstieg auf produktives Serving als 6-Wochen-Pilot.

Das Problem: Ollama ist ein Laborwerkzeug, kein Serving-Stack

Ollama hat einen verdienten Ruf: In fünf Minuten läuft ein Modell auf dem Laptop, die Bedienung ist trivial, mit über 172.000 GitHub-Sternen (Stand Mai 2026) ist es das populärste lokale KI-Tool. Genau diese Stärke ist der Grund, warum es so oft im falschen Kontext landet. Was den Prototyp trägt, trägt nicht die Abteilung.

Der Kern des Problems ist die Architektur. Ollama basiert auf llama.cpp und ist auf einzelne, sequenzielle Anfragen optimiert. Kommen zehn Nutzer gleichzeitig, arbeitet es sie im Wesentlichen nacheinander ab, die GPU steht zwischen den Anfragen still. Für einen Entwickler am Schreibtisch ist das perfekt. Für einen internen Assistenten mit 50 aktiven Kollegen ist es ein Nadelöhr, das sich nicht wegkonfigurieren lässt.

Unsere klare Position: Der Fehler ist nicht, mit Ollama anzufangen, sondern mit Ollama produktiv gehen zu wollen. Die Frage ist nicht „Ollama oder vLLM“, sondern „ab wann“. Wer die Antwort zu spät gibt, debuggt Latenz-Spitzen in Produktion, statt vorher umzusteigen. Einen breiteren Motorvergleich inklusive TGI liefert unser Vergleich der Inference Engines Ollama, vLLM und TGI.

Die 6 Signale, dass der Laborbetrieb produktionsreif werden muss

Die kurze Antwort: Sobald mehr als eine Handvoll Menschen gleichzeitig auf dasselbe Modell zugreift, ist die Grenze erreicht. In der Praxis kündigt sich der Umstieg über sechs konkrete Signale an. Sobald zwei oder drei davon zutreffen, ist der Wechsel überfällig, nicht optional.

1. Mehr als 5 bis 10 gleichzeitige Nutzer, und die Antwortzeiten schwanken spürbar.
2. Ein Latenz- oder Verfügbarkeits-SLA, das Sie einhalten müssen, nicht nur wollen.
3. Die GPU ist teuer und schlecht ausgelastet, weil sie zwischen Anfragen wartet.
4. Sie brauchen ein Modell, das nicht auf eine GPU passt, also Tensor-Parallelität über mehrere GPUs.
5. Der Dienst soll autoskalieren, mit Health-Checks und Metriken für den Betrieb.
6. Mehrere Anwendungen teilen sich dasselbe Modell und konkurrieren um Durchsatz.

Kein einzelnes Signal zwingt zum Wechsel, aber die Häufung tut es. Wir sehen bei Kunden regelmäßig, dass der interne Chatbot im Pilot mit Ollama begeistert, und drei Wochen nach dem Rollout an genau diesen Punkten kippt. Der Auslöser ist fast nie das Modell, sondern die Gleichzeitigkeit.

Was vLLM anders macht: Continuous Batching

vLLM (Version 0.26.1, Juli 2026, über 86.900 GitHub-Sterne) ist von Grund auf für gleichzeitige Last gebaut. Zwei Mechanismen machen den Unterschied. PagedAttention verwaltet den Speicher der Aufmerksamkeits-Caches wie ein Betriebssystem seinen RAM, ohne Verschnitt. Und Continuous Batching schiebt neue Anfragen in laufende Batches hinein, statt zu warten, bis der alte fertig ist. Die GPU steht praktisch nie still.

Das Ergebnis ist keine Feinjustierung, sondern eine andere Größenordnung: Bei paralleler Last holt vLLM aus derselben Hardware ein Vielfaches des Durchsatzes gegenüber einem sequenziellen Runner. Dazu kommt Tensor-Parallelität für große Modelle wie Llama-3.3-70B-Instruct, die auf eine einzelne GPU nicht passen.

# vLLM als OpenAI-kompatibler Server, Continuous Batching ist Standard
vllm serve meta-llama/Llama-3.3-70B-Instruct 
  --tensor-parallel-size 2 
  --max-num-seqs 256 
  --port 8000

Der Preis ist Komplexität. vLLM will bewusst betrieben werden: GPU-Wahl, Speicher-Tuning, Monitoring, Deployment auf Kubernetes. Das ist kein Nachteil, sondern der Unterschied zwischen Werkzeug und Plattform. Ollama hat dafür kürzlich in die andere Richtung ausgebaut: Version 0.32 (Juli 2026) macht aus dem ollama-Befehl einen interaktiven Agenten, es wird bequemer für Entwickler, nicht tauglicher für Serving. Wie ein produktives vLLM-Deployment konkret aussieht, zeigt unsere Anleitung zum produktiven vLLM-Deployment.

Entscheidungsmatrix: wann Ollama reicht, wann vLLM muss

Die kurze Antwort: Ollama bleibt für alles, was lokal und einzeln ist, vLLM übernimmt alles, was zentral und gleichzeitig ist. Es ist kein Entweder-oder über die ganze Organisation, sondern eine Grenze pro Anwendungsfall. Ein Team kann lokal mit Ollama entwickeln und gegen einen zentralen vLLM-Dienst deployen.

Diese Grenze verschiebt sich nicht mit der nächsten Version. Ollama wird nicht zum Serving-Stack, weil es ein anderes Ziel hat, und vLLM wird nicht zum Ein-Klick-Laptop-Tool. Wer beide Werkzeuge für ihren jeweiligen Zweck einsetzt, spart sich die schmerzhafte Zwischenphase, in der ein Prototyp-Tool unter Produktionslast gequält wird.

Der Umstieg ist kein Rewrite

Die gute Nachricht für die Entscheidung: Der Wechsel ist billiger, als viele fürchten. Beide sprechen eine OpenAI-kompatible API. Wenn Ihre Anwendung schon gegen Ollamas /v1-Endpunkt läuft, ändert sich im Client praktisch nur die Basis-URL. Die Anwendungslogik, die Prompts, das SDK bleiben.

# Gleicher Client-Code, nur die base_url wechselt
from openai import OpenAI

client = OpenAI(base_url="http://vllm-host:8000/v1", api_key="egal")
# vorher Ollama: base_url="http://ollama-host:11434/v1"

antwort = client.chat.completions.create(
    model="meta-llama/Llama-3.3-70B-Instruct",
    messages=[{"role": "user", "content": "Fasse den Vertrag zusammen."}],
)

Die eigentliche Arbeit steckt nicht im Code, sondern im Betrieb: GPU-Dimensionierung, Deployment, Load Balancing und Monitoring. Mehrere vLLM-Instanzen hinter einem Balancer, Autoscaling und Metriken brauchen eine tragende Plattform darunter, und genau die bauen wir als AI-Platform-Engineering. Unsere Empfehlung: Planen Sie den Umstieg, bevor die Signale eintreten, nicht als Feuerwehreinsatz danach. Ein Umstieg unter Last, mit unzufriedenen Nutzern im Nacken, ist doppelt so teuer wie derselbe Schritt drei Wochen früher in Ruhe.

Kosten: die GPU ist der teuerste Posten

Der Grund, warum sich der Umstieg rechnet, ist selten die Software und fast immer die GPU-Auslastung. Eine A100 oder H100 kostet gleich viel, ob sie zu 20 oder zu 90 Prozent ausgelastet ist. Ollama lässt sie unter paralleler Last oft leer laufen, vLLM füllt sie. Bei gleicher Nutzerzahl brauchen Sie mit vLLM schlicht weniger GPUs.

In unseren Projekten ist die typische Rechnung simpel: Der Mehraufwand im Betrieb von vLLM ist einmalig, die eingesparte GPU-Kapazität ist monatlich. Bei einem internen Assistenten für ein paar hundert Mitarbeiter amortisiert sich der Umstieg meist im ersten Quartal, allein über die Hardware.

Häufig gestellte Fragen

Kann man Ollama produktiv einsetzen?

Für kleine, klar begrenzte Fälle ja: ein einzelner Nutzer, ein Batch-Job über Nacht, ein Prototyp mit wenig Last. Sobald mehrere Menschen gleichzeitig zugreifen oder ein SLA gilt, ist Ollama das falsche Werkzeug. Es ist auf sequenzielle Anfragen ausgelegt und lässt die GPU unter paralleler Last leerlaufen.

Ollama vs vLLM: was ist der Hauptunterschied?

Ollama ist ein Laptop-freundlicher lokaler Runner, vLLM eine Serving-Engine für gleichzeitige Last. vLLM nutzt Continuous Batching und PagedAttention, um viele Anfragen parallel über dieselbe GPU zu schieben, und skaliert über mehrere GPUs. Ollama gewinnt bei Einfachheit, vLLM bei Durchsatz und Betrieb.

Ist der Wechsel von Ollama zu vLLM aufwendig?

Im Code kaum, im Betrieb schon. Beide sprechen eine OpenAI-kompatible API, im Client wechselt oft nur die Basis-URL. Der Aufwand steckt in GPU-Dimensionierung, Deployment auf Kubernetes, Load Balancing und Monitoring. Genau diesen Betriebsteil sollte man planen, nicht improvisieren.

Ab wie vielen Nutzern lohnt sich vLLM?

Als Faustregel ab mehr als fünf bis zehn gleichzeitigen Anfragen auf dasselbe Modell. Es geht um Gleichzeitigkeit, nicht um die Gesamtzahl der Mitarbeiter: 300 Kollegen, von denen selten zwei zugleich fragen, sind unkritisch, 30 aktive Nutzer im selben Moment nicht.

Was kostet der Betrieb von vLLM im Vergleich?

Die Software ist bei beiden kostenlos, der Unterschied liegt in der Hardware. vLLM lastet die GPU besser aus und braucht für dieselbe Last weniger GPUs, das ist der eigentliche Hebel. Dem steht ein höherer, aber einmaliger Betriebsaufwand gegenüber. In der Regel amortisiert sich der Umstieg über die eingesparte GPU-Kapazität.

Nächster Schritt

Prüfen Sie ehrlich die sechs Signale. Wenn zwei zutreffen, ist der Umstieg keine Frage des Ob, sondern des Wann, und je früher geplant, desto billiger.

Verwandte Themen