vLLM vs. Ollama: 1 Nutzer oder 256 gleichzeitig – und welche Türen jeder öffnet

Nimm Ollama, wenn eine Person es nutzt, auf einem Mac, einem Windows-PC oder mit fast jeder Grafikkarte, mit GGUF-Modellen und einem einzigen Befehl. Nimm vLLM, wenn mehrere Personen oder Programme gleichzeitig dasselbe Modell auf einem Linux-Rechner mit NVIDIA-Karte nutzen, mit safetensors-Modellen. Zu Hause, für einen Nutzer: Ollama.

Die beiden sind weniger Rivalen als Werkzeuge für verschiedene Aufgaben. Ollama 0.40.10, seit dem 23. Oktober 2026 die stabile Version, ist dafür gebaut, ein Modell auf deinen eigenen Rechner zu bringen. vLLM 0.32.0, stabil seit dem 18. Oktober 2026, ist dafür gebaut, ein Modell vielen Nutzern gleichzeitig bereitzustellen. Mit der Stoppuhr haben wir sie nicht gegeneinander antreten lassen, einen Sieger beim Tempo findest du hier also nicht. Was wir getan haben: den Code beider Versionen überall gelesen, wo er Speicher, Netzwerk und deine Privatsphäre berührt, und genau dort unterscheiden sie sich am stärksten.

vLLMProgramm-Datenblatt→ OllamaProgramm-Datenblatt→

	vLLM	Ollama
Gebaut für	Ein Modell vielen Nutzern gleichzeitig bereitstellen	Modelle auf dem eigenen Rechner ausführen
Version am 24. Oktober 2026	0.32.0	0.40.10
Code und Lizenz	Offen, Apache 2.0	Offen, MIT
Läuft auf	Linux mit NVIDIA-Karte (Compute Capability 7.5+), AMD mit ROCm in wenigen bestimmten Versionen; Windows nur über WSL; Mac experimentell, nur Prozessor	Windows 10 22H2+, macOS 14+, Linux; NVIDIA, AMD, Apple Silicon und Vulkan
Modelldateien	safetensors, dazu AWQ, GPTQ, FP8 und weitere; GGUF nur über ein experimentelles Zusatzmodul	GGUF und safetensors; auf Apple Silicon standardmäßig MLX
Gleichzeitige Anfragen ab Werk	Bis zu 256 auf einer Heim-Grafikkarte, gebündelt	1 pro Modell; der Rest wartet in einer Warteschlange mit bis zu 512
Grafikspeicher	Reserviert beim Start 92 % der Karte	Nimmt, was Modell und Kontext brauchen
Installation und erste Antwort	Python-Paket, vllm download-kernels, dann vllm serve	Installer oder Einzeiler-Skript, dann ollama run
Fenster	Keins: Es ist ein API-Server	Desktop-App unter macOS und Windows
Lauscht auf	0.0.0.0:8000, alle Netzwerkschnittstellen	127.0.0.1:11434, nur dein Rechner
Schlüssel an der API	Ab Werk keiner; --api-key deckt nur 4 Routen-Präfixe ab	Keiner, und der lokale Server hat keinen Schlüssel zu prüfen
CORS ab Werk	Geschlossen seit 0.32.0 (kein Origin erlaubt)	Offen für Seiten von localhost, 127.0.0.1 und 0.0.0.0 auf jedem Port
Sendet von sich aus	Nutzungsstatistiken an stats.vllm.ai beim Start und alle 10 Minuten	2 Arten von Cloud-Aufrufen mit ollama serve, 4 mit der Desktop-App
Abschalten	VLLM_NO_USAGE_STATS=1 (oder 3 andere Wege)	OLLAMA_NO_CLOUD=1 stoppt die 2 Cloud-Arten; die stündliche Update-Prüfung und die Kontoabfrage der App bleiben

Eine Person zu Hause oder ein Dutzend gleichzeitig

Das ist die Frage, die entscheidet. Ollama bearbeitet ab Werk 1 Anfrage pro Modell auf einmal: Im Code von 0.40.7 steht OLLAMA_NUM_PARALLEL standardmäßig auf 1, und jede weitere Anfrage wartet in einer Warteschlange mit bis zu 512 Plätzen. Für eine Person, die chattet, programmiert oder ein Skript laufen lässt, ist das genau richtig: Die ganze Karte arbeitet an deiner Antwort. Du kannst OLLAMA_NUM_PARALLEL erhöhen, aber jeder zusätzliche Platz vervielfacht den Kontextspeicher: 4 parallele Anfragen mit 4.096 Token Kontext reservieren Speicher für 16.384.

vLLM fängt am anderen Ende an. Auf einer Grafikkarte mit weniger als 70 GB Speicher, also jeder GeForce-Karte, lässt der Code von 0.32.0 vllm serve bis zu 256 Anfragen gleichzeitig bearbeiten, und neue Anfragen schiebt er in den laufenden Stapel, sobald sie eintreffen, statt sie warten zu lassen, bis die vorige fertig ist. Dafür wurde es gebaut. Wenn deine Familie, dein Team oder ein Dutzend Agenten in einer Pipeline dasselbe Modell nutzen, hält vLLM die Karte beschäftigt, wo Ollama sie einzeln nacheinander bedienen würde.

Wie viel schneller wird vLLM dadurch? Gemessen haben wir das nicht, und es hängt vom Modell, von der Karte und davon ab, wie viele Anfragen zusammen kommen. Mit einem einzigen Nutzer gibt es keinen Stapel zu füllen, und der große Vorteil von vLLM hat nichts zu tun.

NVIDIA, Mac oder nur Prozessor

Hier fällt die Wahl oft von selbst. vLLM ist ein Linux-Programm, und sein Paradefall ist eine NVIDIA-Karte mit Compute Capability 7.5 oder höher: Damit fallen die GTX-10-Serie und ältere Karten heraus. AMD-Karten laufen über ROCm, aber für 0.32.0 verlangt das veröffentlichte Paket Python 3.12, ROCm 7.2.3 und glibc 2.39 oder neuer. Unter Windows gibt es keine native Version, nur WSL. Auf einem Mac mit Apple Silicon ist die eigene Unterstützung von vLLM experimentell und nur für den Prozessor; der Grafikchip braucht ein separates Plug-in, das seine Community pflegt.

Ollama läuft fast überall: Windows 10 22H2 oder neuer, macOS 14 oder neuer und Linux, auf NVIDIA-Karten ab Compute Capability 5.0, AMD mit ROCm v7 und Vulkan, das unter Windows und Linux ab Werk aktiv und der empfohlene Weg für Radeon-Karten ohne ROCm ist. Auf einem Mac mit Apple Silicon nutzt es den Grafikchip, und seit 0.40.0 führt es ein Modell standardmäßig mit MLX aus, sobald es eine MLX-Version davon gibt.

Ist dein Rechner ein Mac oder ein Windows-Laptop, endet der Vergleich hier: Ollama. Welche Modelle auf deinen Rechner passen, rechnet dir unser Modellfinder aus.

GGUF oder safetensors: welche Dateien jeder liest

Das Format deiner Modelle ist der zweite Filter. Das native Format von vLLM ist safetensors, in dem die meisten Modelle veröffentlicht werden, dazu mehr als 20 Quantisierungsverfahren wie AWQ, GPTQ und FP8. GGUF, das Format fast aller quantisierten Modelle für zu Hause, ist nicht mehr eingebaut: Seit 0.27 steckt es in einem separaten Zusatzmodul, das die Dokumentation von vLLM selbst als hochgradig experimentell bezeichnet. Modelle kommen standardmäßig von Hugging Face.

Ollama spricht GGUF über llama.cpp und kann außerdem einen Ordner mit safetensors oder eine GGUF-Datei per Modelfile importieren und dabei auf Wunsch quantisieren. Die meisten sehen die Dateien nie: ollama pull lädt aus der eigenen Bibliothek von Ollama, und auf Apple Silicon kann ein Tag eine MLX-Version enthalten, die der Mac der GGUF-Version vorzieht.

Hast du also schon eine Sammlung von GGUF-Dateien, liest Ollama sie so, wie sie sind. Willst du ein Modell genau so ausführen, wie sein Hersteller es veröffentlicht hat, in voller Präzision oder in FP8 auf einer NVIDIA-Karte, ist das das Revier von vLLM.

Speicher: 92 % der Karte von Anfang an oder nur, was das Modell braucht

Wenn du vllm serve zum ersten Mal startest, schau auf den Grafikspeicher: 92 % sind weg. Das ist Absicht. Im Code von 0.32.0 steht gpu_memory_utilization standardmäßig auf 0.92, und vLLM reserviert diesen Anteil gleich beim Start, für die Gewichte und einen Cache, der groß genug für viele Unterhaltungen gleichzeitig ist. Das ist eine Reservierung, kein Verbrauch nach Bedarf: Alles andere, was die Karte braucht, muss in die übrigen 8 % passen. Teilst du sie, senk den Wert von Hand.

Ollama lädt die Gewichte und den Cache, den der Kontext braucht, und wählt diesen Kontext nach dem Grafikspeicher, den es vorfindet: 4.096, 32.768 oder 262.144 Token. Wird das Modell eine Weile nicht genutzt, entlädt es das Modell und gibt den Speicher frei.

Installation und erste Antwort

Ollama sind 2 Schritte: per Installer oder Einzeiler-Skript installieren, dann ollama run mit einem Modellnamen. Es lädt das Modell und startet einen Chat im Terminal. Unter macOS und Windows gibt es zusätzlich eine Desktop-App mit Chatfenster.

vLLM ist ein Python-Paket ohne Fenster. Mit 0.32.0 brauchst du Python 3.11 bis 3.14; installiert wird es mit uv pip install vllm --torch-backend=auto (oder dem offiziellen Docker-Image), nach jeder Installation oder jedem Update läuft einmal vllm download-kernels, und gestartet wird es mit vllm serve und einem Modell von Hugging Face. Danach sprichst du über seine OpenAI-kompatible API mit ihm, aus Code oder über eine Chat-Oberfläche, die du davorsetzt. Schwer ist das nicht, wenn du dich im Terminal wohlfühlst, aber es sind mehr Teile, und die Speichereinstellungen von oben gehören zur Arbeit.

Unsere Schritt-für-Schritt-Anleitungen begleiten dich bei beiden: Ollama lokal einrichten und vLLM lokal einrichten.

Welche Türen offen stehen: 0.0.0.0:8000 gegen 127.0.0.1:11434

Ab Werk lauscht vllm serve auf 0.0.0.0:8000: auf allen Netzwerkschnittstellen des Rechners, ohne Schlüssel. Auf einem Laptop im Hotel könnte jeder in diesem WLAN dein Modell nutzen. Ollama lauscht auf 127.0.0.1:11434, nur auf deinem Rechner, und um es von einem anderen Gerät zu erreichen, musst du es mit OLLAMA_HOST=0.0.0.0 bewusst öffnen.

Keiner von beiden verlangt ab Werk ein Passwort. vLLM kann es: Starte es mit --api-key oder der Variablen VLLM_API_KEY, und Clients müssen den Schlüssel mitschicken. Aber der Schlüssel deckt nur Routen unter 4 Präfixen ab, /v1, /v2, /inference und /cohere; andere Routen auf demselben Port antworten ohne ihn, und die Sicherheitsseite von vLLM selbst rät, sich nicht allein auf den Schlüssel zu verlassen. Der lokale Server von Ollama hat überhaupt keinen Schlüssel: Seine Schutzmechanismen sind, nur auf deinem Rechner zu lauschen, CORS und eine Prüfung des Host-Headers jeder Anfrage, die nur greift, solange er auf deinem eigenen Rechner lauscht.

CORS entscheidet, welche Webseiten den Server aus deinem Browser heraus nutzen dürfen, und hier ist vLLM inzwischen der Strengere. Seit 0.32.0 ist seine Liste erlaubter Origins leer: Keine Seite einer anderen Website kann seine Antworten lesen, bis du sie mit --allowed-origins hinzufügst. Ollama akzeptiert Seiten von localhost, 127.0.0.1 und 0.0.0.0 auf jedem Port, dazu ein paar App-Schemata, und antwortet jedem anderen Origin mit 403; Browser-Erweiterungen müssen per OLLAMA_ORIGINS hinzugefügt werden. Denk daran, dass CORS nur Browser bindet: Jedes Programm in deinem Netzwerk erreicht vLLM trotzdem.

Noch etwas haben wir im Code von vLLM geprüft, weil seine Sicherheitsseite warnt, dass die interne Kommunikation von PyTorch auf allen Schnittstellen lauschen kann. Auf 1 Rechner richtet der Code von 0.32.0 ab Werk diese Kommunikation über eine Datei im temporären Ordner ein, nicht über einen Netzwerkport; TCP nutzt er nur auf AMD-Karten mit dem All-Reduce von AITER, bei Datenparallelität (--data-parallel-size größer als 1) und zwischen mehreren Rechnern. Diese internen Ports sollten nie von außen erreichbar sein.

Was jeder von sich aus sendet

Hier sollte jemand, dem Privatsphäre wichtig ist, zweimal hinschauen, und die Antwort ist vielleicht nicht die erwartete. vLLM sendet ab Werk Nutzungsstatistiken an stats.vllm.ai: 1 vollständigen Bericht beim Start der Engine (Grafikkarte, Prozessor, Speicher, Betriebssystem, vLLM-Version, die Architektur des Modells, aber nicht seinen Namen, und Starteinstellungen), danach einen Herzschlag alle 10 Minuten, solange der Server läuft. Das sind 144 Herzschläge am Tag. Zu seinen Gunsten: Es legt eine Kopie von allem, was es sendet, in ~/.config/vllm/usage_stats.json ab, und jeder von 4 Schaltern stellt es ab: VLLM_NO_USAGE_STATS=1, DO_NOT_TRACK=1, VLLM_DO_NOT_TRACK=1 oder eine leere Datei unter ~/.config/vllm/do_not_track. Der Wert muss genau 1 sein.

vLLM lädt außerdem von Hugging Face herunter, wenn du ein Modell anforderst, das nicht im Cache liegt (HF_HUB_OFFLINE=1 verhindert das, sobald deine Modelle auf der Platte sind). Und fehlen die vorkompilierten Kernel von FlashInfer, holt FlashInfer sie beim Start von vLLM von NVIDIAs Servern; vllm download-kernels erledigt das einmal bei der Installation, und FLASHINFER_NO_DOWNLOAD=1 verbietet es. Eine Update-Prüfung oder ein Konto gibt es nicht. Bevor FlashInfer diese Kernel herunterlädt, fragt vLLM meist, ob NVIDIAs Server edge.urm.nvidia.com antwortet (1 Anfrage, 5 Sekunden Limit), und FLASHINFER_NO_DOWNLOAD=1 stoppt diese Prüfung nicht. Mit pip installiert passiert das auf B200- und B300-Karten mit fast jedem Modell von selbst und kann auf einer H100 oder einer RTX 50 mit Modellen wie gpt-oss passieren. Das Docker-Image bringt die Kernel schon mit, und liegen sie nach vllm download-kernels auf der Platte, geht meist keine der beiden Anfragen raus.

Ollama hat keine Analytics-Bibliothek im Code. Nur mit ollama serve, wie unter Linux, macht es von sich aus 2 Arten von Aufrufen an ollama.com: einen Katalog empfohlener Modelle alle 4 Stunden und die Steckbriefe seiner Cloud-Modelle beim Serverstart. OLLAMA_NO_CLOUD=1 stellt beide ab. Mit der Desktop-App unter macOS oder Windows kommen 2 Arten hinzu: eine Update-Prüfung jede Stunde, die keine Einstellung stoppt, und eine Kontoabfrage beim Öffnen der App.

Die stillste Einrichtung von allen ist also einer der beiden mit seinem Schalter: vLLM mit VLLM_NO_USAGE_STATS=1, HF_HUB_OFFLINE=1 und FLASHINFER_NO_DOWNLOAD=1, nachdem vllm download-kernels gelaufen ist, oder ollama serve ohne App und mit OLLAMA_NO_CLOUD=1. Jedes Ziel, mit Quelle und Datum, steht auf unserer vLLM-Seite und unserer Ollama-Seite.

Welches wir installieren würden, je nach Fall

• Eine Person, beliebiger Rechner: Ollama. Ein Befehl, ein Modell, das sich selbst lädt und entlädt, und nichts offen im Netzwerk.
• Ein Mac oder ein Windows-Laptop: Ollama. vLLM hat keine native Windows-Version, und auf dem Mac läuft es nur auf dem Prozessor.
• Ein Regal voller GGUF-Dateien: Ollama, das sie ohne Umwandlung importiert (ein Modelfile und ollama create pro Modell).
• Ein Linux-Rechner mit NVIDIA-Karte für den ganzen Haushalt, ein Team oder eine Flotte von Agenten: vLLM, mit --host, API-Schlüssel und abgeschalteten Statistiken.
• Ein Modell genau so, wie sein Hersteller es veröffentlicht hat, in safetensors oder FP8: vLLM.
• Eine Karte, die du auch zum Spielen oder für andere Programme nutzt: Ollama, oder vLLM mit von Hand gesenktem gpu_memory_utilization.

Überlegst du auch, ob es eine Desktop-App sein soll? Unser Vergleich LM Studio vs. Ollama hilft dir weiter.