Ollama oder vLLM: Welcher LLM-Server passt?

Ollama im Vergleich zu vLLM, in einem Absatz

Ollama ist ein Modellmanager mit integriertem Server: Es lädt quantisierte Gewichte herunter, lädt sie in den Speicher und beantwortet Anfragen auf 127.0.0.1:11434, bei Bedarf auch auf der CPU. 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. Eine Person, die mit einem lokalen Assistenten spricht, verwendet Ollama. Eine Anwendung, die ein Team bedient, verwendet vLLM.

Beide stellen eine OpenAI-kompatible HTTP-API bereit. Daher lässt sich Clientcode durch Ändern der Basis-URL zwischen ihnen verschieben. Die API ist nicht der Unterschied. Der Unterschied zeigt sich, wenn eine zweite Anfrage eintrifft, während die erste noch Tokens generiert.

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 benötigt ein 7B- oder 8B-Modell auf der Festplatte etwa 5 GB statt 16 GB. Erst die Quantisierung macht Inferenz auf der CPU überhaupt praktikabel.

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

Das Designziel ist ein einzelner Benutzer. Im Juli 2026 ist der Standardwert für OLLAMA_NUM_PARALLEL 1. Das bedeutet, dass ein Modell jeweils eine Anfrage verarbeitet und alle weiteren 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 ein Modell nicht erst zum Anfragezeitpunkt 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 vorhält) in Blöcken fester Größe, ähnlich wie ein Betriebssystem den Speicher seitenweise verwaltet. Eine Anfrage benötigt dadurch keine große zusammenhängende Speicherreservierung mehr, die auf den ungünstigsten Fall ausgelegt ist. Speicher, der zuvor reserviert und ungenutzt war, steht dadurch für weitere parallele Anfragen zur Verfügung. Continuous Batching ermöglicht es einer neuen Anfrage, beim nächsten Decodierungsschritt dem laufenden Batch beizutreten, statt auf dessen Abschluss zu warten. Eine abgeschlossene Sequenz verlässt den Batch sofort. Ihr Platz wird wieder belegt.

Das Ergebnis in der Praxis: Auf einer einzelnen GPU steigt der Gesamtdurchsatz von einer auf dreißig parallele Nutzeranfragen stark an, während die Geschwindigkeit pro Nutzer deutlich weniger sinkt als erwartet. Mit Ollamas Standardeinstellungen führt der Wechsel von einem auf dreißig Nutzer lediglich dazu, dass neunundzwanzig Personen warten.

Kontinuierliches Batching macht den entscheidenden Unterschied

Stellen Sie sich vor, dass gleichzeitig jeweils fünf Anfragen auf jedem Server mit identischer Hardware eintreffen.

Ollama verarbeitet mit den Standardeinstellungen zuerst die erste Anfrage vollständig, danach die zweite und so weiter. Der fünfte Aufrufer wartet auf vier vollständige Generierungsvorgänge. Der Gesamtdurchsatz entspricht ungefähr der Geschwindigkeit einer einzelnen Generierung, weil der Prozessor immer nur an einer Sequenz arbeitet.

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. Der teure Teil besteht darin, die Modellgewichte aus dem Speicher zu lesen. Dieser Lesevorgang wird über den gesamten Batch geteilt. Das ist derselbe Zusammenhang zwischen Speicherbandbreite und Leistung, 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 zusätzlicher Speicherbedarf. Jeder parallele Slot benötigt einen eigenen KV-Cache. Ollama teilt außerdem das Kontextfenster auf die Slots auf. Bei vier parallelen Anfragen und einem Modell, das auf 8192 Tokens konfiguriert ist, bleiben für jede Anfrage 2048 Tokens Kontext. Auch die 8192 sind eine Konfigurationsentscheidung und keine feste Vorgabe. Daher entscheidet das Erhöhen von num_ctx und die Dimensionierung des dafür benötigten RAMs, ob vier Slots überhaupt nutzbar sind. Der paged Cache von vLLM vermeidet diesen Zielkonflikt, weil Blöcke einer Anfrage erst zugewiesen werden, während sie tatsächlich wächst. In beiden Fällen hängt die maximale Anzahl der Personen, die ein einzelner Server gleichzeitig bedienen kann, von der Größe des KV-Caches, den Prefill-Kosten und der Warteschlangentiefe ab. Das erklärt, warum ein Server, der für eine Person problemlos lief, bei fünf Personen langsam wird.

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 ollama-Systembenutzer, installiert die Binärdatei und registriert ollama.service, der an 127.0.0.1:11434 gebunden ist. Die von --verbose ausgegebene Zeile eval rate zeigt die tatsächlichen Tokens pro Sekunde auf diesem System. Dieser Wert ist verlässlicher als veröffentlichte Angaben. Ein einzelner Messwert aus einer einzelnen Anfrage ist nur ein Ausgangspunkt und keine Kapazitätsangabe. Erst die Messung der Tokens pro Sekunde über verschiedene Parallelitätsstufen zeigt, ob das System die tatsächlich erwartete Last bewältigt und ob das Mieten einer GPU günstiger ist als die Abrechnung pro Token.

Um die Parallelität 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, welche Einstellungen geladen sind. Die Spalte PROCESSOR enthält den maßgeblichen Wert. 100% CPU bedeutet, dass keine GPU verwendet wird. Das ist die sachliche Erklärung für die meisten Berichte, dass Ollama langsam ist. Die Zeile OLLAMA_KEEP_ALIVE=30m im Drop-in ist auch auf einem wenig ausgelasteten System wichtig. Standardmäßig entlädt der Dienst das Modell nach fünf Minuten ohne Anfrage. Wenn das Modell zwischen Anfragen geladen bleibt, muss die erste Anfrage nach einer Stunde Leerlauf nicht erneut die vollständige Ladezeit abwarten.

Installation und Bereitstellung mit vLLM

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

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

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

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

Der erste Start dauert länger, weil zunächst die Gewichte heruntergeladen werden. Anschließend wird die GPU analysiert, um zu ermitteln, 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 Server installiert ist, entfällt mit dem offiziellen Image die Einrichtung der CUDA-Abhängigkeiten:

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 Dekoration: PyTorch übergibt Tensoren zwischen Prozessen über den Shared Memory. Die standardmäßige Docker-Zuweisung für Shared Memory ist für Inferenz mit Tensorparallelität zu klein.

Die wichtigsten produktiven Flags sind --max-model-len (das Kontextfenster, für das Sie Ressourcen bereitstellen), --gpu-memory-utilization (der Anteil des Grafikspeichers, den vLLM verwenden darf; seit Juli 2026 standardmäßig 0.92), --tensor-parallel-size, um ein Modell auf mehrere GPUs aufzuteilen, 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 Umgebungsvariablen VLLM_API_KEY stammen. Eine Anfrage ohne dieses Token erhält HTTP 401. Das ist dennoch kein Grund, Port 8000 an einer öffentlichen Schnittstelle zu veröffentlichen, da vLLM keine Ratenbegrenzung hat und ein Token über unverschlüsseltes HTTP während der Übertragung mitgelesen werden kann. Es bedeutet jedoch, dass der Server das Konzept eines Aufrufers kennt.

Ollama bietet keine solche Funktion. Es gibt keinen Schlüssel, keine Anmeldung und keine Allowlist. Jeder Prozess, der Port 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 terminiert (Transport Layer Security).

Hardware: Anforderungen der einzelnen Systeme

Ollama läuft auf der CPU. Ein mit 4 Bit quantisiertes Modell 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. Für ein 8B-Modell sind es etwa 8 GB. Auf einer gemeinsam genutzten vCPU liegt die Geschwindigkeit im einstelligen bis niedrigen zweistelligen Token-Bereich pro Sekunde. Das ist eine Folge der Speicherbandbreite und keine Fehlkonfiguration. Kein Flag kann das beheben. Wenn Sie diese Berechnung für ein bestimmtes Release statt anhand einer Faustregel nachvollziehen möchten, legt Nemotron 3.5 Lightning auf einem VPS ausführen den exakten abzurufenden Tag, den belegten RAM nach dem Laden und die Praxistauglichkeit eines reinen CPU-Betriebs fest.

vLLM setzt eine GPU voraus. Der Standardpfad stellt nicht quantisierte Gewichte mit 16 Bit Genauigkeit bereit. Das entspricht ungefähr 2 GB pro Milliarde Parameter. Ein 8B-Modell benötigt daher allein für die Gewichte etwa 16 GB Videospeicher. Der KV-Cache, der die für vLLM vorgesehene Parallelität ermöglicht, ist dabei noch nicht berücksichtigt. Auf einer 24-GB-Karte bleibt dafür ein brauchbarer Cache. Auf einer 16-GB-Karte reicht der Speicher nicht aus. Sie müssen dann entweder ein kleineres Modell auswählen oder --quantization mit einem quantisierten Checkpoint übergeben. Es gibt zwar ein CPU-Backend, aber die Standard-Wheels werden dafür nicht erstellt. Außerdem entfällt damit der eigentliche Grund, vLLM einzusetzen.

Die Hardwarefrage beantwortet daher meistens auch die Softwarefrage. Keine GPU bedeutet Ollama. Eine gemietete GPU, die mit 5 Prozent Auslastung läuft, weil Anfragen nacheinander verarbeitet werden, bedeutet vLLM.

Welches Modell für Ihre Arbeitslast

• Eine Person, ein CPU-VPS, Entwürfe und Zusammenfassungen: Ollama. Die Geschwindigkeit ist akzeptabel, und nichts anderes ist einfacher.
• Ein Coding-Assistent 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 Abrufen und Löschen von Modellen mit Tags ist genau seine Stärke, während vLLM für jedes Modell einen Prozessneustart benötigt.
• Eine interne Anwendung, ein Chat-Produkt oder eine Retrieval-Pipeline mit echten Benutzern: vLLM. Hier rechtfertigt Batching die GPU-Kosten.
• Ein Batch-Auftrag, der über Nacht hunderttausend Dokumente bewertet: vLLM mit einem hohen --max-num-seqs. Der Durchsatz ist die einzige relevante Metrik, die Latenz pro Dokument dagegen nicht.
• Eine Agent-Plattform, auf der mehrere selbst gehostete KI-Agenten gleichzeitig auf das Modell zugreifen: vLLM, weil Agentenverkehr stoßweise auftritt und naturgemäß parallel ist.

Fehlerbilder mit den 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 Karte von keinem anderen Prozess verwendet wird. Eine Auslastung von mehr als etwa 0.95 führt später unter Last häufig statt dieses Startfehlers zu einem CUDA-Out-of-Memory-Absturz. 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 dieses Problem nicht.

Ollama antwortet allein problemlos und stockt unter Last. Es erscheint nirgends eine Fehlermeldung. Die Anfragen dauern einfach länger, sobald mehr Clients vorhanden sind, weil OLLAMA_NUM_PARALLEL=1 sie nacheinander verarbeitet. Lange Antworten verschärfen das Problem, da ein Client den einzigen Slot so lange belegt, bis das Modell das Ende der Antwort festlegt, und dadurch alle nachfolgenden Anfragen blockiert werden. Begrenzen Sie die Antwort mit num_predict setzt daher eine Obergrenze dafür, wie lange ein einzelner Durchlauf den Server belegen kann. Erhöhen Sie die Einstellung für parallele Anfragen und akzeptieren Sie das kleinere Kontextfenster pro Anfrage, oder verlagern 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. Setzen Sie ihn daher im Client, statt das Flag zu entfernen.

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

Beide zu betreiben ist eine sinnvolle Lösung

Sie schließen sich nicht gegenseitig aus. Ein häufiges Setup besteht aus vLLM auf einer GPU-Instanz, die die Anwendung bedient, und Ollama auf dem gewöhnlichen VPS daneben für lokale Skripte, Cronjobs und das Ausprobieren neuer Modell-Releases. Beide Endpunkte sind mit der OpenAI-API kompatibel. Daher genügen eine Client-Bibliothek und das Umschalten der Basis-URL. Die Kostenkontrolle ist hier wichtiger als die Wahl der Engine. Eine ungenutzte GPU verursacht dieselben Kosten wie eine ausgelastete GPU. Außerdem ist die planbare Kontrolle der Kosten für Agenten und Inferenz 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 liegt vLLM deutlich vorn, weil Continuous Batching alle aktiven Sequenzen in einem Forward-Pass dekodiert, während Ollama sie standardmäßig nacheinander verarbeitet. Auf einem Rechner ohne GPU stellt sich die Frage nicht: Ollama läuft dort, vLLM praktisch nicht.

Kann vLLM ohne GPU ausgeführt werden?

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

Was ist der Unterschied zwischen Ollama und llama.cpp?

llama.cpp ist die Inferenzbibliothek, und GGUF ist das quantisierte Gewichtsformat. Der Ollama-Runner basiert darauf und ergänzt die Funktionen, die llama.cpp Ihnen überlässt: eine Modellregistrierung, automatische Downloads, einen dauerhaft laufenden Server, eine systemd-Unit und einen 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 Platz für den KV-Cache vorhanden sein. Eine 24-GB-Karte bietet ausreichend Spielraum. Bei einer 16-GB-Karte benötigen Sie einen quantisierten Checkpoint oder ein kleineres Modell. vLLM beansprucht den durch --gpu-memory-utilization festgelegten Anteil des Kartenspeichers. Dieser Wert beträgt seit Juli 2026 standardmäßig 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 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 im Format: llama3.1:8b bei Ollama und eine vollständige Repository-ID wie Qwen/Qwen2.5-1.5B-Instruct bei vLLM.