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 meisten von Ollama bereitgestellten Modelle liegen als GGUF-Dateien vor und sind in der Regel auf 4 Bit quantisiert. Deshalb belegt ein 7B- oder 8B-Modell auf dem Datenträger ungefähr 5 GB statt 16 GB. Die Quantisierung reduziert den für die Inferenz auf der CPU benötigten Speicher. Auf Macs mit Apple Silicon kann Ollama außerdem auf safetensors basierende Modelle über eine MLX-Engine ausführen. Seit v0.40.0 (September 2026) werden unterstützte Architekturen dort automatisch mit MLX ausgeführt.

Der GGUF-Runner basiert auf llama.cpp, der C++-Inferenzbibliothek, die GGUF-Quantisierung auf gewöhnlicher Hardware praktikabel gemacht hat. Seit Oktober 2026 unterstützt Ollama zwei Engines: llama.cpp und MLX. Linux-Builds unterstützen außerdem MLX-Inferenz mit CUDA. Der Entwicklungsleitfaden aktiviert dieses Backend mit cmake -B build . -DOLLAMA_MLX_BACKENDS=cuda_v13. Voraussetzung sind CUDA 13+ und cuDNN 9+. Wenn Personen Ollama mit llama.cpp vergleichen, vergleichen sie daher meistens eine Bedienungsschicht mit der Komponente, die diese Schicht kapselt.

Das Designziel ist die Nutzung durch einen Benutzer. Seit Oktober 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 Warteschlange enthält standardmäßig 512 Einträge (OLLAMA_MAX_QUEUE). Sie können die parallele Verarbeitung erhöhen. Der folgende Abschnitt erklärt, welche Kosten dadurch entstehen. Wenn Sie Ollama noch nicht ausgeführt haben, beginnen Sie mit Ollama auf einem VPS hosten und Port 11434 geschlossen halten, da die lokale API keine Authentifizierung erfordert.

Was vLLM eigentlich ist

vLLM ist ein Inference-Server, sonst nichts. Er verwaltet keine Modellbibliothek, stellt aber einen vllm chat-Client für einen laufenden Server bereit und lädt keine Modelle zum Zeitpunkt der Anfrage nach. Sie geben beim Start ein Hugging Face-Repository an, das System lädt dieses eine Modell und stellt es bereit, bis Sie den Prozess beenden.

Was Sie für diese Spezialisierung erhalten, ist Durchsatz. Zwei Mechanismen leisten die Arbeit. PagedAttention speichert den KV-Cache (Key-Value-Cache, den pro Token gespeicherten Attention-Zustand, den ein Modell für jede aktive Anfrage vorhält) in Blöcken fester Größe, ähnlich wie ein Betriebssystem den Arbeitsspeicher in Seiten unterteilt. Eine Anfrage benötigt keine große, zusammenhängende Reservierung mehr, die für den Worst-Case ausgelegt ist. Speicher, der früher reserviert und ungenutzt blieb, wird dadurch für mehr gleichzeitige Anfragen verfügbar. Continuous Batching ermöglicht es einer neuen Anfrage, dem laufenden Batch beim nächsten Decodierungsschritt beizutreten, anstatt darauf zu warten, dass der aktuelle Batch abgeschlossen ist. Eine abgeschlossene Sequenz verlässt den Batch sofort und ihr Slot wird neu belegt.

Das praktische Ergebnis: Auf einer einzelnen GPU steigt die Gesamtzahl der Token pro Sekunde bei einer Steigerung von einem auf dreißig gleichzeitige Benutzer stark an, während die Geschwindigkeit pro Benutzer deutlich weniger sinkt, als man erwarten würde. Unter der Standardeinstellung von Ollama führt der Wechsel von einem auf dreißig Benutzer lediglich dazu, dass neunundzwanzig Personen warten müssen.

Kontinuierliches Batching macht den entscheidenden Unterschied

Stellen Sie sich vor, dass gleichzeitig fünf Anfragen bei jedem Server eingehen. Die Hardware ist identisch.

Ollama verarbeitet eine Anfrage mit den Standardeinstellungen vollständig. Danach folgt die zweite 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 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 aufwendige Teil besteht darin, die Modellgewichte aus dem Speicher zu lesen. Dieser Lesevorgang wird über den gesamten Batch geteilt. Das ist derselbe Zusammenhang mit der Speicherbandbreite, der CPU-Inferenz langsam macht: Entscheidend ist das Verschieben der Gewichte, nicht die Arithmetik.

Sie können OLLAMA_NUM_PARALLEL=4 setzen und einen Teil dieses Effekts erzielen. Der Preis dafür ist der Speicherbedarf. Jeder parallele Slot benötigt einen eigenen KV-Cache. Ollama multipliziert die Kontextzuweisung, statt sie aufzuteilen: Laut FAQ skaliert der benötigte RAM mit OLLAMA_NUM_PARALLEL mal OLLAMA_CONTEXT_LENGTH. Vier parallele Anfragen an ein Modell, das für 8192 Tokens konfiguriert ist, behalten also jeweils 8192 Tokens. Der Server muss insgesamt jedoch einen Cache für 32768 Tokens vorhalten. Auch 8192 ist eine Konfigurationsentscheidung und kein fester Wert. Daher entscheidet das Erhöhen von num_ctx und die Dimensionierung des dafür benötigten RAM, ob vier Slots überhaupt passen. Der paged Cache von vLLM vermeidet es, das vollständige Kontextfenster im Voraus für jeden Slot zu reservieren. Stattdessen werden einer Anfrage Blöcke zugewiesen, sobald 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 Kosten des Prefill und der Warteschlangentiefe ab. Das erklärt, warum ein Server, der für eine Person ausreichend schnell war, bei fünf Personen langsam wird.

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, das an 127.0.0.1:11434 gebunden ist. Die von --verbose ausgegebene eval rate-Zeile zeigt die tatsächliche Tokenrate pro Sekunde auf diesem Rechner. Verlassen Sie sich darauf und nicht auf veröffentlichte Werte. Ein Messwert aus einer einzelnen Anfrage ist nur ein Ausgangspunkt und keine Kapazitätsangabe. Deshalb zeigt erst die Messung der Tokenrate pro Sekunde über mehrere Parallelitätsstufen, ob der Rechner die 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, was geladen ist. Die Spalte PROCESSOR zeigt den tatsächlichen Zustand. 100% CPU bedeutet, dass keine GPU verwendet wird. Das ist die sachliche Erklärung für die meisten Berichte, dass Ollama langsam ist. Die OLLAMA_KEEP_ALIVE=30m-Zeile in diesem Drop-in ist auch auf einem wenig ausgelasteten Rechner wichtig. Standardmäßig entlädt der Dienst das Modell nach fünf Minuten ohne Anfrage. Wenn das Modell zwischen Anfragen im Speicher bleibt, muss die erste Anfrage nach einer Pause von bis zu einer halben Stunde die vollständige Ladezeit nicht erneut abwarten. Wenn Ihre Pausen länger dauern, setzen Sie einen höheren Wert.

Installation und Bereitstellung mit vLLM

Die GPU-Builds von vLLM erfordern Linux (macOS auf Apple Silicon bietet CPU-only-Unterstützung mit einem vorgefertigten Wheel im Release 0.32.0; GPU-Beschleunigung auf diesen Macs erfolgt über vLLM-Metal, ein separates, von der Community gepflegtes Plugin auf Basis von MLX). Das aktuelle vLLM-Release (0.32.0, Oktober 2026) unterstützt Python 3.11 bis 3.14; die Installationsanleitung nennt denselben Bereich. Python 3.10 wurde in 0.32.0 entfernt, daher ist 3.12, wie unten verwendet, die sichere Wahl. Installieren Sie es in einer eigenen virtuellen Umgebung, da es einen spezifischen PyTorch-Build nachzieht:

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

Die letzte Zeile stammt aus der NVIDIA-Installationsanleitung von vLLM mit Stand Oktober 2026. Sie installiert die vorkompilierten Kernel von FlashInfer. Ohne diese lädt vLLM die Kernel beim Start herunter und kompiliert sie, was laut Anleitung auf Hopper-GPUs und neueren Modellen mehrere Minuten in Anspruch nehmen kann. Führen Sie diesen Schritt nach jedem vLLM-Upgrade erneut aus, da FlashInfer den Import verweigert, wenn die Kernel nicht übereinstimmen.

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

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

Der Startvorgang ist beim ersten Mal langsam, da die Gewichte heruntergeladen werden und die GPU profiliert wird, um zu bestimmen, wie viele KV-Cache-Blöcke in den Speicher passen. Der Dienst lauscht auf Port 8000. Überprüfen Sie dies, 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 vorhanden ist, erspart das offizielle Image die Arbeit mit 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 gewährt dem Container Zugriff auf den Shared Memory des Hosts; eine Erhöhung von --shm-size ist eine weitere Option. PyTorch überträgt Tensoren zwischen Prozessen über den Shared Memory, insbesondere bei Tensor-paralleler Inference.

Die Flags, die in der Produktion am wichtigsten sind, sind --max-model-len (das Kontextfenster, für das Sie Ressourcen bereitstellen möchten), --gpu-memory-utilization (der Anteil der Karte, den vLLM beanspruchen darf, standardmäßig 0.92 mit Stand Oktober 2026), --tensor-parallel-size für die Aufteilung eines Modells auf mehrere GPUs und --api-key.

Authentifizierung ist bei vLLM ein Flag und fehlt bei Ollamas lokaler API

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 an /v1, die ohne diesen Wert weitergeleitet wird, erhält HTTP 401. Der Schlüssel schützt jedoch nicht den gesamten Server. Der vLLM-Sicherheitsleitfaden und der Authentifizierungscode im Quelltext von 0.32.0 wenden ihn nur auf Endpunkte unter den Pfadpräfixen /v1, /v2, /inference und /cohere an. Der Hilfetext von --api-key auf der Seite vllm serve nennt nur die ersten drei Präfixe. Der Code prüft jedoch alle vier. Sowohl der Leitfaden als auch der Hilfetext weisen darauf hin, dass andere Endpunkte, insbesondere /invocations, die dieselbe Inferenz wie /v1 bereitstellt, nicht authentifiziert werden. Das ist ein ausreichender Grund, Port 8000 nicht an einer öffentlichen Schnittstelle zu veröffentlichen. Der vLLM-Sicherheitsleitfaden überlässt die Ratenbegrenzung außerdem einem vorgeschalteten Reverse Proxy. Ein über unverschlüsseltes HTTP übertragenes Token kann während der Übertragung gelesen werden. Das Flag bedeutet jedoch, dass der Server ein Konzept des Aufrufers besitzt.

Ollamas lokale API erfordert keine Authentifizierung. Cloud-Modelle, die Veröffentlichung von Modellen und private Modelldownloads erfordern eine Anmeldung. Der direkte API-Zugriff auf ollama.com erfordert einen API-Schlüssel. Jeder Prozess, der Port 11434 erreichen kann, kann Modelle ausführen, herunterladen oder löschen. Beschränken Sie den Dienst auf Loopback und greifen Sie über ein selbst gehostetes WireGuard-VPN darauf zu. Alternativ können Sie einen authentifizierenden Reverse Proxy verwenden, der TLS (Transport Layer Security) terminiert.

Hardware: Anforderungen der einzelnen Lösungen

Ollama läuft auf der CPU. Ein 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 RAM, ein 8B-Modell ungefähr 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 dieses Problem beheben. Wenn Sie diese Berechnung anhand eines bestimmten Releases 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 Frage fest, ob der reine CPU-Betrieb schnell genug für den praktischen Einsatz ist.

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 allein für die Gewichte etwa 16 GB Videospeicher. Der KV-Cache, wegen dessen benötigter Parallelität Sie vLLM installiert haben, kommt noch hinzu. Auf einer Karte mit 24 GB bleibt dafür ein nutzbarer Cache. Auf einer Karte mit 16 GB reicht der Speicher nicht aus. Sie müssen dann entweder ein kleineres Modell auswählen, --quantization übergeben (mit einem quantisierten Checkpoint oder zum Quantisieren von Gewichten mit voller Genauigkeit beim Laden) oder einen Teil der Gewichte mit --cpu-offload-gb in den System-RAM auslagern. Dabei bleibt ihre Genauigkeit erhalten, der Betrieb ist jedoch langsamer, weil diese Gewichte bei jedem Forward-Pass an die GPU übertragen werden. Es gibt ein CPU-Backend mit eigenen separaten Wheels. Damit entfällt jedoch der eigentliche Grund für den Einsatz von vLLM.

Die Hardwarefrage beantwortet daher meistens auch die Softwarefrage. Keine GPU bedeutet Ollama. Eine gemietete GPU, die mit 5 Prozent Auslastung läuft, weil Anfragen serialisiert 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 mit einem KV-Cache-Fehler nicht. Die Meldung nennt beide Werte:

ValueError: To serve at least one request with the model's max seq len (32768), (4.00 GiB KV cache is needed, which is larger than the available KV cache memory (1.00 GiB). Based on the available memory, the estimated maximum model length is 8192. Try increasing `gpu_memory_utilization` (which also controls CPU memory on the CPU backend) or decreasing `max_model_len` when initializing the engine. See https://docs.vllm.ai/en/latest/configuration/conserving_memory/ for more details.

Das Modell definiert ein Kontextfenster, das größer ist als der Speicher, der nach dem Laden der Gewichte noch verfügbar ist. Verringern Sie den Wert mit --max-model-len 8192. Wenn die Karte von keiner anderen Anwendung verwendet wird, können Sie alternativ --gpu-memory-utilization erhöhen.

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. Prüfen Sie dies mit sudo dmesg | grep -i oom. Die Lösung ist ein kleineres oder stärker quantisiertes Modell, nicht eine Einstellung.

Ollama antwortet bei alleiniger Nutzung korrekt und bleibt unter Last hängen. Es erscheint nirgendwo eine Fehlermeldung. Die Anfragen dauern einfach länger, je mehr Aufrufer vorhanden sind, weil OLLAMA_NUM_PARALLEL=1 sie nacheinander verarbeitet. Lange Antworten verschärfen das Problem. Ein Aufrufer, der den einzigen Slot belegt, bis das Modell seine Antwort beendet, blockiert alle nachfolgenden Aufrufer. Eine Begrenzung der 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 Verarbeitung und akzeptieren Sie den zusätzlichen RAM-Bedarf des Kontexts pro Slot. Alternativ können Sie die Arbeitslast auf vLLM verschieben.

vLLM gibt bei jedem /v1-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 den Schlüssel 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 durchführen. Bei vielen gleichzeitigen Anfragen liegt vLLM weit vorne, da Continuous Batching jede aktive Sequenz in einem einzigen Forward-Pass dekodiert, während Ollama standardmäßig Anfragen nacheinander abarbeitet. Auf Systemen ohne GPU unterstützen beide Inferenzpfade, wobei vLLM separate CPU-Wheels verwendet.

Kann vLLM ohne GPU ausgeführt werden?

Ja, über das CPU-Backend. Die Standard-Wheels sind auf NVIDIA- oder AMD-GPUs ausgelegt. Der Hauptgrund für die Existenz von vLLM – die Auslastung eines Beschleunigers durch gebündelte Anfragen – entfällt auf einer CPU. Es existiert ein CPU-Backend mit separaten Wheels für x86 und Arm. Für echte CPU-Inferenz sollten Sie Ollama oder llama.cpp direkt verwenden.

Was ist der Unterschied zwischen Ollama und llama.cpp?

llama.cpp ist die Inferenz-Bibliothek, und GGUF ist das zugehörige Format für quantisierte Gewichte. Ollama nutzt dies für die GGUF-Inferenz und ergänzt eine Modell-Registry, getaggte Downloads, Modellverwaltung sowie eine systemd-Unit. Ollama liefert zudem eine MLX-Engine aus, die auf Apple Silicon Modelle im safetensors-Format ausführt, und unterstützt CUDA-Builds unter Linux. Daher sind beide unter der Haube nicht immer identisch.

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

Bei 16-Bit-Präzision beanspruchen die Gewichte allein etwa 16 GB, grob 2 GB pro Milliarde Parameter; der KV-Cache benötigt zusätzlich Platz. Eine 24-GB-Karte ist ausreichend. Eine 16-GB-Karte erfordert ein quantisiertes Modell, ein kleineres Modell oder --cpu-offload-gb, um einen Teil der Gewichte in den Systemspeicher auszulagern, was jedoch die Geschwindigkeit reduziert. vLLM beansprucht einen Teil des Grafikspeichers, der durch --gpu-memory-utilization festgelegt wird; dieser Wert liegt mit Stand Oktober 2026 standardmäßig bei 0,92.

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

In der Regel müssen nur die Basis-URL, der API-Key und der Modellname angepasst werden. Ollama stellt seine OpenAI-kompatible Schnittstelle unter http://127.0.0.1:11434/v1 bereit und ignoriert den Key, während vLLM unter http://localhost:8000/v1 arbeitet und den Key auf seinen /v1-Routen erzwingt, sofern einer konfiguriert wurde. Die Modellnamen unterscheiden sich in der Form: llama3.1:8b für Ollama, eine vollständige Repository-ID wie Qwen/Qwen2.5-1.5B-Instruct für vLLM.