Der Punkt, an dem Ollama nicht mehr reicht

TL;DR

Ollama ist für den Einstieg richtig und bleibt es für Einzelnutzer und Tests. Sobald mehr als etwa acht Personen gleichzeitig arbeiten, kippt das Bild: vLLM hält durch Continuous Batching den Durchsatz, während bei Ollama die Antwortzeiten linear mit der Nutzerzahl steigen. Der Wechsel ist ein Nachmittag Arbeit, nicht ein Projekt.

Warum der Pilot immer mit Ollama anfängt

Und warum das richtig ist. ollama run qwen3:30b-a3b — nach drei Minuten läuft ein Modell, ohne Konfiguration, ohne Container-Orchestrierung, ohne Kenntnisse über Tensor-Parallelität. Für die Frage "funktioniert das für unseren Anwendungsfall überhaupt" gibt es kein besseres Werkzeug.

Wir raten niemandem, mit vLLM zu beginnen. Der Einstieg ist steiler, und die Fragen, die man in der Pilotphase beantworten muss, sind fachliche, keine technischen.

Der Fehler passiert später: Der Pilot funktioniert, die Fachabteilung ist zufrieden, und man macht ihn produktiv, indem man mehr Nutzer draufschaltet. Genau dort bricht es.

Die vier Signale für den Wechsel

Erstes Signal: Die Antwortzeiten steigen mit der Nutzerzahl. Das ist das eindeutigste. Bei einem Nutzer 40 Token pro Sekunde, bei fünf gleichzeitigen Nutzern je 8 Token pro Sekunde. Die Gesamtleistung bleibt konstant, sie wird nur aufgeteilt.

Der Grund liegt in der Architektur. Ollama verarbeitet Anfragen weitgehend nacheinander; eine parallele Verarbeitung ist über OLLAMA_NUM_PARALLEL konfigurierbar, aber begrenzt und speicherhungrig, weil jede parallele Sitzung ihren eigenen Bereich im KV-Cache reserviert. vLLM arbeitet mit Continuous Batching: Neue Anfragen steigen in einen laufenden Stapel ein, statt zu warten, und der Speicher wird über PagedAttention seitenweise verwaltet statt blockweise reserviert.

In der Praxis bedeutet das: Der Gesamtdurchsatz eines vLLM-Servers ist bei acht bis zwanzig parallelen Nutzern ein Vielfaches dessen, was dieselbe Karte unter Ollama liefert. Die konkreten Zahlen hängen an Modell, Kontextlänge und Karte — messen Sie es auf Ihrer Hardware, statt Fremdbenchmarks zu übernehmen. Der Durchsatzvergleich zwischen vLLM und Ollama zeigt die Systematik.

Zweites Signal: Das Modell wird beim ersten Zugriff nach einer Pause neu geladen. Ollama entlädt Modelle nach einer Leerlaufzeit aus dem Speicher. Für einen Arbeitsplatzrechner ist das sinnvoll, für einen Dienst nicht: Die erste Anfrage am Morgen wartet dann 30 Sekunden auf das Laden. Sie können das über OLLAMA_KEEP_ALIVE=-1 abstellen — dass Sie es abstellen müssen, ist bereits das Signal.

Drittes Signal: Sie brauchen Kennzahlen. Wie viele Anfragen laufen gerade, wie lang ist die Warteschlange, wie ist der KV-Cache ausgelastet, wie hoch ist die Zeit bis zum ersten Token? vLLM liefert das als Prometheus-Endpunkt mit. Bei Ollama bauen Sie sich das drumherum. Wie das aussieht, steht im Beitrag zur Ollama-Überwachung.

Viertes Signal: Das Modell passt nicht mehr auf eine Karte. Sobald Sie über mehrere GPUs verteilen müssen, ist vLLM mit Tensor-Parallelität der vorgesehene Weg. Die Systematik dazu steht im vLLM-Cluster-Leitfaden.

Ein Signal, das nicht zählt: "vLLM ist professioneller." Wenn Ihre Installation drei Nutzer bedient und die Antwortzeiten stimmen, wechseln Sie nichts. Sie tauschen ein funktionierendes System gegen Betriebsaufwand.

Der Wechsel, konkret

Die gute Nachricht zuerst: Beide sprechen eine OpenAI-kompatible Schnittstelle. Wenn Ihre Anwendungen über ein Gateway gehen, ändern Sie eine Adresse — sonst nichts.

Schritt 1: Modell besorgen. Ollama arbeitet mit GGUF-Dateien aus seiner eigenen Registry, vLLM üblicherweise mit den Originalgewichten von Hugging Face. Das ist die eine Stelle, an der Sie tatsächlich etwas Neues herunterladen.

pip install -U vllm huggingface_hub
hf download Qwen/Qwen3-30B-A3B-Instruct --local-dir /models/qwen3-30b-a3b

Schritt 2: Server starten. Die Parameter, die zählen:

vllm serve /models/qwen3-30b-a3b \
  --served-model-name standard \
  --max-model-len 32768 \
  --gpu-memory-utilization 0.90 \
  --max-num-seqs 32 \
  --port 8000

--gpu-memory-utilization ist der Parameter, der am häufigsten falsch gesetzt wird. vLLM reserviert diesen Anteil des Grafikspeichers vorab für Gewichte und KV-Cache. Bei 0,90 bleiben 10 Prozent für alles andere. Läuft auf derselben Karte noch etwas — ein Einbettungsmodell, eine Bildschirmausgabe —, senken Sie den Wert. Ist die Karte exklusiv, können Sie auf 0,92 gehen; darüber wird es bei Lastspitzen eng.

--max-model-len bestimmt, wie viel KV-Cache pro Sitzung anfällt, und ist damit der Hebel für die Anzahl paralleler Nutzer. Setzen Sie ihn auf das, was Sie brauchen, nicht auf das Maximum des Modells. Ein Modell mit 128k Kontextfenster auf 32k zu begrenzen, vervierfacht die Anzahl gleichzeitiger Sitzungen. Die Rechnung dahinter steht im Beitrag zum VRAM-Bedarf.

Schritt 3: Umschalten. Im Gateway die Basis-URL ändern:

model_list:
  - model_name: standard
    litellm_params:
      model: openai/standard              # entspricht --served-model-name
      api_base: http://vllm.intern:8000/v1
      api_key: "nicht-benoetigt"

Schritt 4: Prüfen, ob es besser wurde. Nicht gefühlt, gemessen:

# Kennzahlen, die vLLM selbst liefert
curl -s http://vllm.intern:8000/metrics | grep -E \
  "num_requests_running|num_requests_waiting|gpu_cache_usage_perc"

Steht num_requests_waiting dauerhaft über null, während gpu_cache_usage_perc unter 0,8 liegt, ist --max-num-seqs zu niedrig. Ist der Cache dagegen voll, brauchen Sie mehr Speicher oder weniger Kontext.

Was Sie beim Wechsel verlieren

Ehrlichkeitshalber, weil das in Migrationsanleitungen selten steht:

Die Bequemlichkeit. ollama pull und ein neues Modell läuft. Bei vLLM laden Sie Gewichte, prüfen die Unterstützung der Architektur in Ihrer Version und starten den Dienst neu. Modellwechsel wird von einer Minute zu einer geplanten Aktion.

Mehrere Modelle auf einer Karte. Ollama lädt und entlädt nach Bedarf. vLLM belegt den reservierten Speicher dauerhaft für ein Modell. Wenn Sie drei Modelle parallel anbieten wollen, brauchen Sie drei Prozesse und entsprechend Speicher — oder Sie akzeptieren, dass ein Gateway zwischen Servern verteilt.

Die niedrige Einstiegshürde für Kollegen. Wer Ollama auf seinem Rechner laufen hat, kann etwas ausprobieren. Ein vLLM-Server ist Infrastruktur.

Deshalb unsere übliche Empfehlung: Behalten Sie Ollama. Nicht als Produktivsystem, sondern als Werkzeug für Erprobung und Einzelplätze. Die beiden schließen sich nicht aus, und ein Gateway davor macht den Unterschied für die Anwendungen unsichtbar.

Häufig gestellte Fragen

Ab wie vielen Nutzern lohnt sich der Wechsel von Ollama zu vLLM?

Ab etwa acht gleichzeitig arbeitenden Nutzern wird der Unterschied deutlich spürbar. Entscheidend ist nicht die Anzahl der Berechtigten, sondern die Gleichzeitigkeit: 50 Nutzer, die über den Tag verteilt einzelne Fragen stellen, belasten weniger als 8, die parallel längere Texte verarbeiten. Messen Sie die tatsächliche Parallelität, bevor Sie umstellen.

Ist vLLM schneller als Ollama bei einem einzelnen Nutzer?

Nur geringfügig, und der Unterschied rechtfertigt den Wechsel nicht. Der Vorteil von vLLM entsteht durch Continuous Batching und die seitenweise Speicherverwaltung — beides wirkt erst bei mehreren gleichzeitigen Anfragen. Bei einem Nutzer liegen beide in derselben Größenordnung.

Muss ich meine Anwendungen für vLLM anpassen?

In der Regel nicht. Beide bieten eine OpenAI-kompatible Schnittstelle, sodass sich der Wechsel auf eine geänderte Basis-URL und einen geänderten Modellnamen beschränkt. Wenn Ihre Anwendungen über ein Gateway laufen, ändern Sie die Konfiguration an einer Stelle und fassen keinen Anwendungscode an.

Kann vLLM mehrere Modelle gleichzeitig bereitstellen?

Ein vLLM-Prozess bedient ein Modell. Für mehrere Modelle starten Sie mehrere Prozesse auf verschiedenen Ports oder Karten und verteilen über ein Gateway. Das ist der wesentliche Bequemlichkeitsverlust gegenüber Ollama, das Modelle bei Bedarf lädt und entlädt — dafür bekommen Sie vorhersagbares Verhalten unter Last.

Welche Rolle spielt die maximale Kontextlänge für die Nutzerzahl?

Eine große. Der KV-Cache wächst linear mit der Kontextlänge und mit jeder gleichzeitigen Sitzung. Wer --max-model-len von 128k auf 32k senkt, vervierfacht bei gleichem Speicher die Anzahl möglicher paralleler Sitzungen. Setzen Sie den Wert deshalb auf das, was Ihre Anwendungsfälle tatsächlich brauchen, nicht auf das, was das Modell könnte.

Der nächste Schritt

Messen Sie eine Woche lang, wie viele Anfragen tatsächlich gleichzeitig laufen — nicht wie viele Nutzer berechtigt sind. Bleibt der Spitzenwert unter fünf, lassen Sie Ollama stehen und sparen sich den Betriebsaufwand. Liegt er darüber, ist der Wechsel ein Nachmittag. Bei der Auslegung schauen wir gern drauf.