vLLM vs. Ollama — Welche Inference Engine passt?

Überblick: Was sind vLLM und Ollama?

Ollama — Einfachheit als Designprinzip

Ollama ist ein in Go geschriebener LLM-Server, der den Betrieb lokaler Modelle radikal vereinfacht. Mit einem einzigen Befehl (curl -fsSL https://ollama.com/install.sh | sh) ist die Installation abgeschlossen. Modelle werden wie Docker-Images verwaltet: ollama pull llama3.1 lädt ein Modell herunter, ollama run startet es.

Ollama nutzt das GGUF-Format (llama.cpp) für Modelle und unterstützt verschiedene Quantisierungsstufen (Q4_K_M, Q5_K_M, Q8_0 etc.). Die eingebaute Modellverwaltung mit Custom Modelfiles erlaubt es, unternehmensspezifische System-Prompts und Parameter direkt ins Modell zu baken.

vLLM — Maximaler Durchsatz als Designprinzip

vLLM (Virtual Large Language Model) wurde an der UC Berkeley entwickelt und ist eine Python-basierte Inference Engine, die auf maximalen Durchsatz optimiert ist. Die Kerninnnovation ist PagedAttention — eine Speicherverwaltungstechnik, die VRAM-Nutzung um bis zu 55% reduziert und deutlich mehr parallele Requests auf derselben Hardware ermöglicht.

vLLM nutzt das HuggingFace-Modellformat und unterstützt neben GGUF auch AWQ, GPTQ und FP16-Modelle. Es bietet native Integration mit Kubernetes, Prometheus-Metriken und Continuous Batching für maximale GPU-Auslastung.

Feature-Vergleich: vLLM vs. Ollama

Performance-Benchmarks

Wir haben beide Engines unter identischen Bedingungen getestet. Testumgebung: NVIDIA A100 80 GB, Ubuntu 24.04, CUDA 12.4, Llama 3.1 70B (Q4_K_M für Ollama, AWQ für vLLM).

Durchsatz: Tokens pro Sekunde

Latenz: Time to First Token (TTFT)

Die TTFT-Werte zeigen den dramatischsten Unterschied: Unter Last explodiert die Latenz bei Ollama, während vLLM durch Continuous Batching stabile TTFT-Werte beibehält. Für interaktive Anwendungen (Chat, Echtzeit-Assistenz) ist das entscheidend.

VRAM-Effizienz

Die größte Einsparung durch PagedAttention zeigt sich im KV-Cache: Ollama allokiert den maximalen Kontext pro Request im Voraus, während vLLM den Speicher dynamisch verwaltet. Bei 20 gleichzeitigen Requests spart vLLM bis zu 55% KV-Cache-Speicher — das bedeutet mehr parallele Anfragen auf derselben GPU.

Architektur-Unterschiede

Ollama: Der All-in-One-Ansatz

Ollama verfolgt einen monolithischen Ansatz: Server, Modellverwaltung und Inference in einer einzigen Binary. Das macht die Bedienung einfach, aber die Skalierung schwieriger. Intern nutzt Ollama llama.cpp als Inference-Backend, was eine breite Modellkompatibilität über das GGUF-Format gewährleistet.

• Modellverwaltung: Docker-ähnliches Pull/Push-System mit eigenem Registry
• Quantisierung: GGUF-Format mit verschiedenen Quantisierungsstufen
• Batching: Basisches Batching, sequentielle Verarbeitung bei Überlast
• Memory Management: Statische Allokation pro Modell

vLLM: Der Performance-First-Ansatz

vLLM trennt sauber zwischen Serving-Layer und Inference-Engine. Der Serving-Layer nutzt einen asynchronen FastAPI-Server, während die Inference-Engine hochoptimierte CUDA-Kernels für die eigentliche Modellausführung verwendet.

• PagedAttention: Dynamische Speicherverwaltung für KV-Cache
• Continuous Batching: Neue Requests werden dynamisch in laufende Batches eingefügt
• Speculative Decoding: Kleines Draft-Modell beschleunigt die Generierung
• Prefix Caching: Gemeinsame Prompt-Prefixe werden gecacht und geteilt

Skalierung im Enterprise

Ollama-Skalierung

Ollama skaliert primär vertikal: mehr VRAM, mehr GPUs im selben Server. Horizontale Skalierung erfordert einen externen Load Balancer (NGINX, HAProxy) und manuelle Modell-Synchronisation über alle Instanzen.

# Ollama: Load Balancing mit NGINX
upstream ollama {
    least_conn;
    server gpu-01:11434;
    server gpu-02:11434;
}

vLLM-Skalierung

vLLM bietet native horizontale Skalierung über Tensor Parallelism und Pipeline Parallelism — auch über Nodes hinweg. Mit der Ray-Integration können Sie ein Modell über einen ganzen GPU-Cluster verteilen:

# vLLM: Multi-Node mit Ray
python -m vllm.entrypoints.openai.api_server \
    --model meta-llama/Llama-3.1-70B-Instruct \
    --tensor-parallel-size 4 \
    --pipeline-parallel-size 2 \
    --max-model-len 32768 \
    --gpu-memory-utilization 0.95

Für Kubernetes-Umgebungen stellt vLLM offizielle Helm Charts bereit, die Auto-Scaling basierend auf GPU-Auslastung und Request-Queue-Tiefe unterstützen.

Deployment & Operations

Betriebskomplexität im Vergleich

Unsere Empfehlung: Entscheidungsmatrix

Alternativen zu Ollama und vLLM

Neben Ollama und vLLM gibt es weitere Inference Engines, die für bestimmte Szenarien interessant sind:

• Text Generation Inference (TGI): Von Hugging Face entwickelt, guter Kompromiss zwischen Einfachheit und Performance
• llama.cpp Server: Minimalistisch, läuft auch auf CPUs, ideal für Air-Gap-Umgebungen
• NVIDIA TensorRT-LLM: Maximale Performance auf NVIDIA-Hardware, aber hohe Komplexität
• SGLang: Neuer Ansatz mit strukturierter Generierung und RadixAttention

Weiterführende Ressourcen

• Ollama Enterprise Setup Guide
• GPU-Server Kaufguide
• Open-Source LLM Vergleich
• RAG-Systeme für On-Premise
• DSGVO & KI — Compliance Guide