Ollama oder vLLM: Welcher LLM-Server passt?

Ollama und vLLM in einem Absatz

Ollama ist ein Modellmanager mit integriertem Server: Das Programm lädt quantisierte Gewichte herunter, lädt sie und beantwortet Anfragen auf 127.0.0.1:11434, auf einer CPU, wenn der Rechner nur über eine solche verfügt. vLLM ist eine Engine für hohen Durchsatz: Sie hält eine GPU mit vielen gleichzeitig laufenden Anfragen ausgelastet und ist auf einem Rechner ohne GPU das falsche Werkzeug. Das ist die gesamte Entscheidung. Ein Benutzer, der mit einem lokalen Assistenten spricht, verwendet Ollama. Eine Anwendung, die ein Team versorgt, verwendet vLLM.

Beide stellen eine mit OpenAI kompatible HTTP-API bereit. Daher kann Client-Code durch Ändern der Basis-URL zwischen ihnen wechseln. Die API ist nicht der Unterschied. Der Unterschied zeigt sich, wenn eine zweite Anfrage eintrifft, während die erste noch Tokens erzeugt.

Was Ollama tatsächlich ist

Ollama ist eine Komfortschicht. Mit einem einzigen Installationsbefehl erhalten Sie eine Modellregistrierung (ollama pull llama3.1:8b), einen lokalen Speicher für Gewichte, eine Chat-Eingabeaufforderung, einen systemd-Dienst und eine HTTP-API. Die bereitgestellten Modelle liegen als GGUF-Dateien vor und sind normalerweise auf 4 Bit quantisiert. Deshalb belegt ein 7B- oder 8B-Modell auf dem Datenträger etwa 5 GB statt 16 GB. Erst die Quantisierung macht die Inferenz auf der CPU überhaupt möglich.

Der Runner basiert auf llama.cpp, der C++-Inferenzbibliothek, die GGUF-Quantisierung auf gewöhnlicher Hardware praktikabel gemacht hat. Ollama hat inzwischen für einige neuere Modellfamilien eine eigene Engine ergänzt. llama.cpp bildet jedoch weiterhin die Grundlage für den größten Teil dessen, was Ollama bereitstellt. Wenn Menschen Ollama mit llama.cpp vergleichen, vergleichen sie daher meist eine Schicht für eine einfachere Bedienung mit der Komponente, die diese Schicht kapselt.

Das Design ist auf einen Benutzer ausgerichtet. Im Juli 2026 ist der Standardwert für OLLAMA_NUM_PARALLEL 1. Das bedeutet, dass ein Modell jeweils eine Anfrage verarbeitet und alle anderen Anfragen in einer Warteschlange warten. Diese enthält standardmäßig 512 Einträge (OLLAMA_MAX_QUEUE). Sie können die Einstellung für parallele Verarbeitung erhöhen. Der folgende Abschnitt erläutert die damit verbundenen Kosten. Wenn Sie Ollama noch nicht ausgeführt haben, beginnen Sie mit Ollama auf einem VPS hosten und Port 11434 geschlossen halten, da die API keinerlei Authentifizierung bietet.

Was vLLM tatsächlich ist

vLLM ist ausschließlich ein Inferenzserver. Es verwaltet keine Modellbibliothek, enthält keinen Chat-Prompt und lädt bei einer Anfrage kein Modell für Sie herunter. Sie geben beim Start ein Hugging Face-Repository an. vLLM lädt dieses eine Modell und stellt es bereit, bis Sie den Prozess beenden.

Diese Spezialisierung ermöglicht einen hohen Durchsatz. Dafür sind zwei Mechanismen verantwortlich. PagedAttention speichert den KV-Cache (Key-Value-Cache, den Attention-Zustand pro Token, den ein Modell für jede aktive Anfrage beibehält) in Blöcken fester Größe, ähnlich wie ein Betriebssystem den Speicher seitenweise verwaltet. Eine Anfrage benötigt dadurch keine zusammenhängende Speicherreservierung, die auf den ungünstigsten Fall ausgelegt ist. Speicher, der zuvor reserviert und ungenutzt war, steht für weitere parallele Anfragen zur Verfügung. Continuous Batching ermöglicht, dass eine neue Anfrage beim nächsten Decodierungsschritt dem laufenden Batch beitritt, anstatt auf den Abschluss des aktuellen Batches zu warten. Eine abgeschlossene Sequenz verlässt den Batch sofort, und ihr Platz wird wieder belegt.

Das Ergebnis in der Praxis: Auf einer einzelnen GPU steigt der Gesamtdurchsatz deutlich, wenn Sie von einem parallelen Benutzer auf dreißig wechseln. Die Geschwindigkeit pro Benutzer sinkt dabei wesentlich weniger als erwartet. Mit den Standardeinstellungen von Ollama führt der Wechsel von einem Benutzer auf dreißig lediglich dazu, dass neunundzwanzig Personen warten.

Kontinuierliches Batching macht den gesamten Unterschied

Stellen Sie sich fünf Anfragen vor, die gleichzeitig auf identischer Hardware jeden Server erreichen.

Ollama verarbeitet Anforderung eins mit den Standardeinstellungen bis zum Abschluss, danach Anforderung zwei und so weiter. Der fünfte Aufrufer wartet auf vier vollständige Generierungen. Der Gesamtdurchsatz entspricht ungefähr der Geschwindigkeit einer einzelnen Generierung, weil der Prozessor immer nur eine Sequenz verarbeitet.

vLLM dekodiert alle fünf Sequenzen im selben Forward-Pass. Die Generierung eines Tokens für fünf Sequenzen kostet kaum mehr als die Generierung eines Tokens für eine Sequenz, weil der aufwendige Teil darin besteht, die Modellgewichte aus dem Speicher zu lesen. Dieser Lesevorgang wird über den gesamten Batch geteilt. Das ist derselbe Speicherdurchsatz-Faktor, der CPU-Inferenz langsam macht: Sie bezahlen für das Verschieben der Gewichte, nicht für die Berechnung.

Sie können OLLAMA_NUM_PARALLEL=4 setzen und einen Teil dieses Effekts erzielen. Der Preis dafür ist Speicher. Jeder parallele Slot benötigt einen eigenen KV-Cache. Ollama teilt das Kontextfenster auf die Slots auf. Daher bleiben bei vier parallelen Anfragen an ein Modell, das für 8192 Tokens konfiguriert ist, für jede Anfrage 2048 Tokens Kontext. Der paged Cache von vLLM vermeidet diesen Zielkonflikt. Blöcke werden einer Anfrage zugewiesen, während diese tatsächlich wächst.

Mit Ollama installieren und bereitstellen

curl -fsSL https://ollama.com/install.sh | sh
ollama pull llama3.1:8b
ollama run --verbose llama3.1:8b "Write two sentences about Linux."

Das Installationsskript erstellt einen Systembenutzer ollama, installiert die Binärdatei und registriert ollama.service, gebunden an 127.0.0.1:11434. Die von --verbose ausgegebene Zeile eval rate enthält Ihre tatsächliche Anzahl von Tokens pro Sekunde auf diesem System. Maßgeblich ist dieser Wert, nicht eine veröffentlichte Angabe.

Um die gleichzeitige Verarbeitung zu erhöhen, verwenden Sie ein systemd-Drop-in. Dadurch wird die Änderung bei einem Upgrade nicht überschrieben:

sudo systemctl edit ollama.service

[Service]
Environment="OLLAMA_NUM_PARALLEL=4"
Environment="OLLAMA_KEEP_ALIVE=30m"

sudo systemctl restart ollama
ollama ps

ollama ps zeigt, was geladen ist. Die Spalte PROCESSOR enthält den tatsächlichen Wert. 100% CPU bedeutet, dass keine GPU verwendet wird. Das ist die sachliche Erklärung für die meisten Berichte, dass Ollama langsam ist.

Mit vLLM installieren und bereitstellen

vLLM benötigt Linux und Python 3.10 bis 3.13. Installieren Sie es in einer eigenen virtuellen Umgebung, weil dabei ein bestimmter PyTorch-Build installiert wird:

uv venv --python 3.12 --seed
source .venv/bin/activate
uv pip install vllm --torch-backend=auto

Stellen Sie anschließend ein Modell bereit. Der Name ist eine Hugging Face-Repository-ID und kein kurzes Tag:

vllm serve Qwen/Qwen2.5-1.5B-Instruct

Der Start dauert beim ersten Mal länger, weil zunächst die Gewichte heruntergeladen werden. Danach wird die GPU profiliert, um zu bestimmen, wie viele KV-Cache-Blöcke hineinpassen. vLLM lauscht auf Port 8000. Prüfen Sie den Dienst, bevor Sie Client-Code schreiben:

curl http://localhost:8000/v1/models
curl http://localhost:8000/v1/chat/completions \
    -H "Content-Type: application/json" \
    -d '{"model": "Qwen/Qwen2.5-1.5B-Instruct", "messages": [{"role": "user", "content": "Who won the world series in 2020?"}]}'

Wenn Docker bereits auf dem System installiert ist, erspart Ihnen das offizielle Image die Arbeit mit der CUDA-Abhängigkeit:

docker run --runtime nvidia --gpus all \
    -v ~/.cache/huggingface:/root/.cache/huggingface \
    --env "HF_TOKEN=$HF_TOKEN" \
    -p 8000:8000 \
    --ipc=host \
    vllm/vllm-openai:latest \
    --model Qwen/Qwen3-0.6B

--ipc=host ist erforderlich und nicht nur dekorativ: PyTorch überträgt Tensoren zwischen Prozessen über den Shared Memory, und die standardmäßige Shared-Memory-Zuweisung von Docker ist für Tensor-Parallel-Inferenz zu klein.

Die wichtigsten Flags für den Produktionsbetrieb sind --max-model-len (das Kontextfenster, für das Sie Ressourcen bereitstellen), --gpu-memory-utilization (der Anteil des GPU-Speichers, den vLLM beanspruchen darf; ab Juli 2026 standardmäßig 0.92), --tensor-parallel-size zum Aufteilen eines Modells auf mehrere GPUs und --api-key.

Authentifizierung ist bei vLLM ein Flag und bei Ollama nicht vorhanden

vLLM erzwingt ein Bearer-Token, wenn Sie eines angeben:

vllm serve Qwen/Qwen2.5-1.5B-Instruct --api-key token-abc123

Derselbe Wert kann aus der Umgebungsvariable VLLM_API_KEY stammen. Eine Anfrage ohne diesen Wert erhält HTTP 401. Das ist trotzdem kein Grund, Port 8000 an einer öffentlichen Schnittstelle bereitzustellen, da vLLM keine Ratenbegrenzung hat und ein Token über einfaches HTTP während der Übertragung gelesen werden kann. Der Server hat dadurch aber ein Konzept des anfragenden Clients.

Ollama bietet keine entsprechende Funktion. Es gibt keinen Schlüssel, keine Anmeldung und keine Zulassungsliste. Jeder Prozess, der 11434 erreichen kann, kann Modelle ausführen, herunterladen oder löschen. Lassen Sie Ollama an Loopback gebunden und greifen Sie über ein WireGuard-VPN, das Sie selbst betreiben darauf zu. Alternativ können Sie einen authentifizierenden Reverse-Proxy verwenden, der TLS (Transport Layer Security) beendet.

Hardware: Was das jeweilige System benötigt

Ollama läuft auf der CPU. Ein quantisiertes Modell mit 4 Bit benötigt pro Milliarde Parameter ungefähr ein halbes Gigabyte RAM. Dazu kommen etwa ein Gigabyte Laufzeit-Overhead und zusätzlicher Speicher für den Kontext. Ein 3B-Modell benötigt daher ungefähr 4 GB freien Speicher. Ein 8B-Modell benötigt ungefähr 8 GB. Auf einer gemeinsam genutzten vCPU liegt die Geschwindigkeit im einstelligen bis niedrigen zweistelligen Token-Bereich pro Sekunde. Ursache ist die Speicherbandbreite, nicht eine Fehlkonfiguration. Kein Flag kann das beheben.

vLLM setzt eine GPU voraus. Der Standardpfad stellt Gewichte mit einer Präzision von 16 Bit ohne Quantisierung bereit. Das entspricht ungefähr 2 GB pro Milliarde Parameter. Ein 8B-Modell benötigt allein für die Gewichte etwa 16 GB Videospeicher. Der KV-Cache ist dabei noch nicht berücksichtigt. Er ermöglicht die Parallelität, für die Sie vLLM installiert haben. Auf einer 24-GB-Karte bleibt dafür ein nutzbarer Cache. Auf einer 16-GB-Karte ist das nicht möglich. Sie wählen daher entweder ein kleineres Modell oder übergeben --quantization mit einem quantisierten Checkpoint. Es gibt ein CPU-Backend. Die standardmäßigen Wheels sind dafür jedoch nicht erstellt. Außerdem entfällt damit der eigentliche Grund, vLLM einzusetzen.

Die Hardwarefrage beantwortet daher meistens auch die Softwarefrage. Ohne GPU verwenden Sie Ollama. Wenn eine gemietete GPU nur zu 5 Prozent ausgelastet ist, weil Anfragen nacheinander verarbeitet werden, verwenden Sie vLLM.

Welche Lösung für Ihre Arbeitslast

• Eine Person, ein CPU-VPS, Entwürfe und Zusammenfassungen: Ollama. Die Geschwindigkeit ist akzeptabel, und nichts anderes ist einfacher.
• Ein Programmierassistent oder ein MCP-Server, der Ihre Tools mit einem lokalen Modell verbindet, den nur Sie aufrufen: Ollama. Eine Parallelität von eins entspricht der tatsächlichen Arbeitslast.
• Sie vergleichen diese Woche fünf Modelle: Ollama. Das Herunterladen und Löschen von Modellen mit Tags gehört genau zu seinen Stärken, während vLLM für jedes Modell einen Prozessneustart benötigt.
• Eine interne Anwendung, ein Chat-Produkt oder eine Retrieval-Pipeline mit tatsächlichen Benutzern: vLLM. Hier rechtfertigt Batching die GPU-Kosten.
• Ein Batchauftrag, der über Nacht hunderttausend Dokumente bewertet: vLLM, mit einem hohen --max-num-seqs. Der Durchsatz ist die einzige relevante Kennzahl; die Latenz pro Dokument spielt keine Rolle.
• Eine Agentenplattform, auf der mehrere selbst gehostete KI-Agenten gleichzeitig auf das Modell zugreifen: vLLM, weil Agentenverkehr stoßweise auftritt und naturgemäß parallel ist.

Fehlerbilder und die angezeigten Meldungen

vLLM startet wegen eines KV-Cache-Fehlers nicht. Die Meldung nennt beide Werte:

ValueError: The model's max seq len (32768) is larger than the maximum number of tokens that can be stored in KV cache (8192). Try increasing gpu_memory_utilization or decreasing max_model_len when initializing the engine.

Das Modell definiert ein Kontextfenster, das größer ist als der nach dem Laden der Gewichte verfügbare Speicher. Verringern Sie den Wert mit --max-model-len 8192, oder erhöhen Sie --gpu-memory-utilization, wenn die GPU von nichts anderem verwendet wird. Eine Auslastung von mehr als etwa 0.95 führt häufig dazu, dass dieser Startfehler später unter Last durch einen CUDA-Out-of-Memory-Absturz ersetzt wird. Das ist die ungünstigere Variante.

Ollama gibt während der Generierung Killed aus. Der Linux-Out-of-Memory-Killer hat den Prozess beendet, weil das Modell mehr RAM benötigte, als auf dem System verfügbar ist. Bestätigen Sie dies mit sudo dmesg | grep -i oom. Verwenden Sie ein kleineres oder stärker quantisiertes Modell. Eine Einstellung behebt das Problem nicht.

Ollama antwortet allein problemlos, bleibt aber unter Last stehen. Es wird nirgends ein Fehler angezeigt. Die Anfragen dauern mit steigender Zahl der Aufrufer einfach länger, weil OLLAMA_NUM_PARALLEL=1 sie nacheinander verarbeitet. Erhöhen Sie den Wert und akzeptieren Sie den kleineren Kontext pro Anfrage, oder verschieben Sie die Workload zu vLLM.

vLLM gibt bei jedem Aufruf 401 zurück. Sie haben den Dienst mit --api-key gestartet, aber der Client sendet keinen Authorization-Header. Die meisten OpenAI-Clientbibliotheken senden den Wert, den Sie als Schlüssel übergeben. Legen Sie ihn daher dort fest, anstatt das Flag zu entfernen.

vLLM meldet, dass das Modell nicht gefunden wurde. Ollama lädt Modelle bei Bedarf, vLLM nicht. Das Feld model im Anforderungstext muss mit der Repository-ID übereinstimmen, mit der Sie den Dienst gestartet haben, oder mit dem Wert von --served-model-name, falls Sie diesen gesetzt haben. Bestätigen Sie die exakte Zeichenfolge mit curl http://localhost:8000/v1/models.

Beide zusammen zu betreiben, ist eine sinnvolle Lösung

Sie schließen sich nicht gegenseitig aus. Ein häufiges Modell ist vLLM auf einer GPU-Instanz, die die Anwendung versorgt, und Ollama auf dem normalen VPS daneben für lokale Skripte, Cron-Jobs und das Ausprobieren neuer Modell-Releases. Beide Endpunkte sind mit der OpenAI-API kompatibel. Daher genügen eine Client-Bibliothek und ein Wechsel der Base-URL. Die Kostenkontrolle ist hier wichtiger als die Wahl der Engine. Eine im Leerlauf befindliche GPU verursacht dieselben Kosten wie eine ausgelastete GPU. Agenten- und Inferenzkosten vorhersehbar zu halten ist eine eigene Disziplin und unabhängig von der Wahl des Servers.

FAQ

Ist vLLM schneller als Ollama?

Bei einer einzelnen Anfrage auf derselben GPU ist der Unterschied gering, da beide dieselben Berechnungen ausführen. Bei vielen parallelen Anfragen ist vLLM deutlich schneller, da Continuous Batching jede aktive Sequenz in einem Forward Pass dekodiert, während Ollama sie standardmäßig nacheinander ausführt. Auf einem Rechner ohne GPU ist die Frage nicht relevant: Ollama läuft dort, vLLM praktisch nicht.

Kann vLLM ohne GPU ausgeführt werden?

Nicht sinnvoll. Die Standard-Wheels sind für NVIDIA- oder AMD-GPUs vorgesehen. Der Grund für vLLM, einen Beschleuniger mit gebündelten Anfragen auszulasten, entfällt auf einer CPU. Für Entwicklungsarbeiten gibt es ein CPU-Backend. Verwenden Sie für echte CPU-Inferenz Ollama oder llama.cpp direkt.

Was ist der Unterschied zwischen Ollama und llama.cpp?

llama.cpp ist die Inferenzbibliothek, und GGUF ist ihr quantisiertes Gewichtsformat. Der Runner von Ollama basiert darauf und ergänzt die Funktionen, die Sie bei llama.cpp selbst bereitstellen müssen: eine Modellregistrierung, automatische Downloads, einen dauerhaft laufenden Server, eine systemd-Unit und einen mit OpenAI kompatiblen Endpunkt. Ollama hat für einige neuere Modellfamilien eine eigene Engine ergänzt. Daher sind beide intern nicht mehr vollständig identisch.

Wie viel GPU-Speicher benötigt vLLM für ein 8B-Modell?

Bei 16-Bit-Genauigkeit benötigen allein die Gewichte etwa 16 GB, also ungefähr 2 GB pro Milliarde Parameter. Zusätzlich muss ausreichend Platz für den KV-Cache vorhanden sein. Eine Karte mit 24 GB ist dafür gut geeignet. Bei einer Karte mit 16 GB benötigen Sie einen quantisierten Checkpoint oder ein kleineres Modell. vLLM verwendet den durch --gpu-memory-utilization festgelegten Anteil des Kartenspeichers. Seit Juli 2026 ist der Standardwert 0.92.

Muss ich meinen Anwendungscode ändern, um zwischen beiden zu wechseln?

Normalerweise müssen Sie nur die Basis-URL, den API-Schlüssel und den Modellnamen ändern. Ollama stellt seine mit OpenAI kompatible Schnittstelle unter http://127.0.0.1:11434/v1 bereit und ignoriert den Schlüssel. vLLM stellt http://localhost:8000/v1 bereit und erzwingt den Schlüssel, wenn Sie einen festlegen. Die Modellnamen unterscheiden sich in ihrer Form: llama3.1:8b für Ollama und eine vollständige Repository-ID wie Qwen/Qwen2.5-1.5B-Instruct für vLLM.