Ollama vs vLLM vs llama.cpp - welcher lokale LLM-Server?

Worum geht das Duell?

Drei Namen tauchen in jeder Diskussion über lokale Sprachmodelle auf: Ollama, vLLM und llama.cpp. Auf den ersten Blick sehen alle drei wie Konkurrenten aus - tatsächlich besetzen sie unterschiedliche Schichten desselben Stacks. llama.cpp ist die fundamentale C++-Bibliothek, die ein Modell in den Arbeitsspeicher lädt und Inferenz auf CPU, GPU, Metal oder Vulkan ausführt. Ollama ist ein Komfort-Layer in Go über llama.cpp, der Modell-Management, eine REST-API und ein Repository hinzufügt. vLLM ist eine eigenständige Python-Runtime von der UC Berkeley, die für GPU-Production-Serving mit hohem Throughput entworfen wurde - andere Codebasis, andere Optimierungen.

Die Wahl entscheidet drei harte Fragen. Erstens: Wie viel Setup-Aufwand investieren Sie? Ollama startet mit einem Befehl, vLLM braucht ein bis zwei Tage Konfiguration, llama.cpp pur erfordert manuelle Modell-Konvertierung. Zweitens: Wie viele parallele Anfragen muss der Server beantworten? Ollama kommt bei etwa fünf Concurrent-Requests an seine Grenzen, vLLM dank PagedAttention und Continuous Batching auch bei dreissig oder mehr. Drittens: Welche Hardware steht zur Verfügung? llama.cpp ist die einzige Option für reine CPU-Setups, für Apple Silicon mit Metal und für Edge-Geräte. vLLM verlangt Linux mit CUDA-GPU. Ollama deckt CPU+GPU ab, ist auf Mac/Windows/Linux lauffähig.

Warum die Wahl wichtig ist

Die Runtime entscheidet über drei Kosten-Achsen, die ein Treuhand- oder Anwalts-Büro direkt spürt. Erstens: Hardware-Kosten. Ein Llama 3.3 70B im 4-Bit-Format läuft auf einer RTX 4090 (24 GB) mit Ollama bei rund 18 Tokens pro Sekunde für eine einzelne Anfrage. Auf derselben Karte erreicht vLLM mit Continuous Batching über alle Concurrent-Requests aggregiert etwa 120-180 Tokens pro Sekunde. Wer fünfzehn aktive Nutzer hat, braucht mit Ollama vier Server, mit vLLM einen einzigen.

Zweitens: Setup- und Wartungs-Kosten. Ollama installiert sich in dreissig Minuten, ein 8B-Modell ist eine Stunde später live. vLLM ist nicht schwierig, aber unforgiving - falsche CUDA-Version, falscher PyTorch-Build, falscher Tensor-Parallel-Wert und der Server stuerzt im Boot. Realistisch: ein bis zwei Personentage Setup, plus laufende Aufmerksamkeit für Updates. llama.cpp pur ist noch tiefer - jeder Modell-Wechsel verlangt einen GGUF-Quantisierungs-Lauf, jeder API-Endpunkt eine eigene Implementation.

Drittens: Integrations-Kosten. Alle drei Runtimes liefern Mai 2026 eine OpenAI-kompatible API - Ollama auf Port 11434, vLLM auf 8000, llama.cpp über den eingebauten Server. Damit funktionieren LiteLLM, n8n und LangChain ohne Anpassung. Wer aber mehrere Modelle pro Server hosten will (Llama-70B für Mandanten-Chat, Phi-4 für schnelle Triage), stösst bei Ollama auf das Limit eines geladenen Modells pro Prozess, während vLLM und llama.cpp Multi-Modell-Setups erlauben - mit etwas mehr Konfigurations-Disziplin.

Die drei Runtimes im Detail

Ollama (Go, MIT, Mai 2026 De-facto-Standard): Ein einziger Befehl - ollama run llama3.3 - lädt das Modell, startet den Daemon und öffnet die API. Die Konfiguration steckt in einer einfachen Modelfile, das Repository auf ollama.com/library deckt Llama, Mistral, Qwen, Gemma, Phi und über 100 weitere Modelle ab. Quantisierung passiert automatisch im Hintergrund. Mac mit Metal-Beschleunigung, Windows über WSL2 oder nativ, Linux mit CUDA oder ROCm. Wichtig für KMU-Setups: Ollama hält das Modell bei Inaktivität automatisch im Speicher und entlädt es nach einer konfigurierbaren Wartezeit - das schont VRAM bei Multi-Modell-Use.

vLLM (Python+CUDA, Apache 2.0, Linux-only): Die Production-Antwort auf Throughput-Probleme. Zwei Kern-Optimierungen heben vLLM über den Rest. PagedAttention verwaltet den KV-Cache wie ein Betriebssystem virtuelle Speicherseiten - kein Verschnitt, lange Kontexte sind machbar. Continuous Batching hängt neue Anfragen mitten in einer laufenden Generation an den Batch an, statt sie zu serialisieren. Ergebnis: 80-90 Prozent GPU-Auslastung statt der 30-40 Prozent von Ollama. Preis: vLLM braucht eine kompatible CUDA-Version, GPU mit mindestens 16 GB VRAM und Linux. Kein Mac, kein einfacher Windows-Pfad.

llama.cpp (C++, MIT, alle Plattformen): Die Bibliothek darunter. Geschrieben von Georgi Gerganov, ursprünglich für Apple-Silicon-Inferenz. GGUF-Format, das de facto zum Standard für quantisierte Modelle geworden ist - 4-bit, 5-bit, 8-bit Quantisierung mit messbaren Qualitäts-Trade-offs. Backends für CPU mit AVX2/AVX-512, CUDA, Metal, Vulkan, ROCm. Ein eingebauter HTTP-Server liefert OpenAI-kompatible Endpoints. Wer maximale Hardware-Effizienz auf ungewöhnlicher Hardware (Apple M3 Max, alte Xeon-Server, ARM-Server) sucht, baut direkt auf llama.cpp - und akzeptiert, dass jede Bequemlichkeit selbst gebaut werden muss.

Auswahl in 5 Schritten

1. 01Hardware-Inventar: Welche Box steht zur Verfügung? CPU only, Apple Silicon, NVIDIA GPU mit wieviel VRAM?
2. 02Concurrent-Last schätzen: 1-5 parallele Nutzer = Ollama; 10-30 = vLLM; Edge / Apple = llama.cpp pur.
3. 03Modell-Anforderung: 7B-13B für Standard-Triage = jede Runtime; 70B für ernsthafte Aufgaben = GPU mit 24+ GB VRAM oder 4-Bit-Quantisierung.
4. 04PoC mit Ollama: zwei Tage installieren, ein 8B-Modell laden, fünf typische Mandantenanfragen testen. Erkenntnis vor Production-Wechsel.
5. 05Production-Migration nur bei nachgewiesenem Load-Problem: vLLM lohnt erst bei dauerhaft mehr als acht Concurrent-Requests, nicht bei Spitzen.

Empfehlung je Szenario

Treuhand 5-15 Personen, gemischte Last, ein Server: Ollama. Der Setup-Aufwand ist eine Stunde, die OpenAI-API läuft ab Tag eins, LiteLLM-Integration ohne Code-Änderung. Auf einer Workstation mit RTX 4090 oder einem Hetzner GEX44 (RTX 6000 Ada) bedient Ollama bis zu fünf parallele Nutzer mit Llama 3.3 70B in 4-Bit ohne sichtbare Latenz-Probleme. Der typische Mai-2026-Default in Schweizer KMU.

Kanzlei oder Hosting-Provider mit 30+ aktiven Nutzern: vLLM. Der Wechsel lohnt sich ab etwa zehn parallelen Anfragen pro Sekunde. Auf einer A100 80 GB liefert vLLM mit Llama 3.3 70B in FP8-Quantisierung etwa 400-500 Tokens pro Sekunde aggregiert - vier- bis fünfmal mehr als Ollama auf derselben Karte. Setup ein bis zwei Tage, dann lange stabil. Erfordert Linux, CUDA 12.x, GPU mit 24+ GB VRAM.

Apple Silicon, Edge-Hardware, ungewöhnliche Architekturen: llama.cpp. Auf einem MacBook Pro M3 Max mit 64 GB Unified Memory läuft Llama 3.3 70B in 4-Bit-Quantisierung bei etwa 8-12 Tokens pro Sekunde - genug für Solo-Nutzung ohne GPU-Server. Wer eine ARM-Box, einen Industrial-PC oder einen Raspberry Pi 5 mit lokalem LLM bestücken will, hat ausser llama.cpp keine ernsthafte Option.

Multi-Modell auf einem Server: vLLM mit Model-Tower oder mehrere llama.cpp-Instanzen auf verschiedenen Ports. Ollama unterstützt das nicht sauber - es lädt zwar mehrere Modelle, aber nur eines bleibt aktiv im VRAM.

Maximaler Reasoning-Throughput bei langen Kontexten: vLLM mit PagedAttention. Wer 128k-Token-Kontexte regelmässig nutzt (lange Verträge, mehrere Aktenstücke parallel), spürt hier den Unterschied zu Ollama deutlich.

Wann keine dieser Runtimes passt

Wenn die Cloud-Variante reicht und kein Compliance-Argument gegen Anthropic-EU, OpenAI-EU oder Mistral-La-Plateforme spricht, ist eine lokale Runtime der falsche Hebel. Faustregel: unter etwa 5 Millionen Tokens pro Monat zahlt sich die GPU-Investition nicht aus. Eine RTX 4090 kostet rund CHF 2200, eine A100 80 GB über CHF 18000 - das sind viele Token zum Anthropic-API-Preis.

Wenn das Use-Case-Profil hauptsächlich kurze, einzelne Anfragen mit langen Wartezeiten dazwischen verlangt, ist die GPU-Auslastung schlecht und der Setup-Aufwand nicht gerechtfertigt. vLLM glänzt erst bei dauerhaft hohem Concurrent-Load, Ollama hat keinen Throughput-Vorteil über eine Cloud-API bei Einzel-Anfragen.

Wenn das Reasoning-Niveau aktueller proprietärer Modelle (das aktuelle Claude-Spitzenmodell, das jeweils aktuelle GPT-Spitzenmodell) zwingend gebraucht wird - bestimmte Rechts-Recherchen, komplexe Steuer-Entscheide - reichen Mai 2026 lokale Open-Weight-Modelle nicht heran. Llama 3.3 70B und Qwen 2.5 72B sind exzellent für Standard-Aufgaben, bleiben aber bei mehrstufigem Reasoning hinter den Spitzenmodellen zurück. Wer das Maximum braucht, betreibt eine hybride Strategie: lokale Runtime für 80 Prozent der Anfragen, Cloud-API für die anderen 20 Prozent.

Vor- und Nachteile

Häufige Fragen

Verwandte Themen

Quellen

1. Ollama - official documentation & model library · 2026-05
2. vLLM - high-throughput LLM serving (docs) · 2026-05
3. llama.cpp - GitHub repository · 2026-05
4. Kwon et al. - PagedAttention paper (vLLM) · 2023-09