vLLM: Production-Serving für Open-Weight-LLMs mit hoher Throughput und PagedAttention

Was ist vLLM?

vLLM ist ein Open-Source-Inference-Server für grosse Sprachmodelle, ursprünglich an der UC Berkeley entwickelt und Mai 2026 unter Apache 2.0 frei verfügbar. Das Projekt liegt bei github.com/vllm-project/vllm und hat Stand Mai 2026 über 30.000 GitHub-Sterne, über 800 Mitwirkende und eine eigene Foundation-Struktur (vLLM ist mittlerweile Teil der Linux Foundation AI & Data).

Der Kern: vLLM ist auf GPU-basierte Production-Serving spezialisiert. Anders als Ollama, llama.cpp oder LM Studio, die primär Einzelnutzer und Hobby-Setups bedienen, wurde vLLM von Anfang an für Mehrbenutzer-Last entworfen. Zwei Techniken machen den Unterschied: PagedAttention verwaltet den KV-Cache des Transformers wie Speicherseiten in einem Betriebssystem und vermeidet damit den üblichen Fragmentierungs-Verlust von 30-60 Prozent. Continuous Batching schiebt eintreffende Anfragen im Sekundentakt zusammen in einen GPU-Batch, sodass die GPU statt 30 Prozent Auslastung dauerhaft bei 80-95 Prozent läuft.

Versionsstand Mai 2026: vLLM v0.6+ ist die produktive Linie. Die Engine unterstützt mehr als 50 Modell-Architekturen, darunter Llama 3.3 / Llama 4 Scout und Maverick, Mistral Large 2 und Small 3.1, Qwen 2.5 / Qwen 3, DeepSeek V3 / V4, Gemma 3, Phi-4, Apertus 8B und 70B, sowie Vision-Language-Modelle wie LLaVA und Qwen2-VL. Quantisierungs-Formate: AWQ, GPTQ, INT8, FP8, GGUF (eingeschränkt), Marlin-Kernel. Hardware-Support: NVIDIA CUDA (Ampere, Hopper, Blackwell), AMD ROCm (MI250, MI300), AWS Inferentia, Google TPU, Intel Gaudi.

Die Schnittstelle ist OpenAI-kompatibel: POST /v1/chat/completions und /v1/completions, ergänzt um native Endpunkte unter /generate. Damit funktionieren bestehende OpenAI-SDKs, LiteLLM, n8n, LangChain ohne Anpassung. Ein vLLM-Server lässt sich in einem einzigen Docker-Befehl starten oder über pip installieren und mit "python -m vllm.entrypoints.openai.api_server --model meta-llama/Llama-4-Scout-17B" hochfahren.

Warum vLLM für CH-Daten zählt

Drei Gründe machen vLLM zur ersten Wahl, sobald eine Schweizer Kanzlei oder ein Treuhandbüro über den Pilotstatus hinausgeht.

Erstens: GPU-Effizienz wird zum Kosten-Hebel. Eine H100 80GB kostet im Hetzner-GEX44-Vergleich oder bei Infomaniak etwa CHF 3.500-5.500 pro Monat. Auf dieser GPU bedient Ollama mit Llama 3.3 70B in 4-Bit-Quantisierung etwa 3-5 parallele Nutzer mit akzeptabler Latenz. vLLM auf der gleichen Hardware bedient 30-50 parallele Nutzer mit dem gleichen Modell. Wer fünfzehn Anwälte oder dreissig Treuhand-Mitarbeitende auf eigener Hardware bedienen will, kommt um vLLM nicht herum – oder muss das Vierfache an GPU-Budget einplanen.

Zweitens: Daten-Souveränität bleibt vollständig. vLLM läuft im eigenen Rack oder auf einer dedizierten GPU-Instanz bei Infomaniak in Genf oder bei einem deutschen Hoster wie Hetzner. Keine Anfrage verlässt den definierten Verarbeitungs-Raum. Das ist relevant für Mandanten unter Berufsgeheimnis nach Art. 321 StGB, für FINMA-beaufsichtigte Institute mit AM-08/2024-Bezug und für EU-AI-Act-Art-10-Anforderungen an die Daten-Governance.

Drittens: Routing-Fähigkeit über LiteLLM. vLLM ist OpenAI-kompatibel – damit lässt sich ein vLLM-Server als Provider in LiteLLM eintragen und gemeinsam mit Mistral-Cloud, Apertus-Swisscom-API und Claude routen. Eine typische Schweizer Multi-Provider-Strategie Mai 2026 sieht so aus: hochsensitive Anfragen an On-Premises-vLLM mit Apertus 70B, mittel-sensitive an Mistral La Plateforme in EU, Top-Reasoning-Fälle an das aktuelle Claude-Spitzenmodell mit revDSG-konformem Vertrag. Der Wechsel ist eine Routing-Regel, kein Code-Refactor.

Viertens, oft übersehen: vLLM dokumentiert Performance gut. Logs zeigen Time-To-First-Token, Inter-Token-Latency, GPU-Auslastung pro Anfrage. Diese Metriken landen über Prometheus in Grafana und damit in einer Audit-fähigen Form – wichtig für FINMA-AM-08/2024-Säule-3 (Robustheit) und EU-AI-Act-Art-15-Loggings-Pflichten.

Wie vLLM technisch funktioniert

vLLM ist ein Python-Paket mit C++/CUDA-Kerneln. Der Server-Modus startet einen Worker-Prozess pro GPU oder pro Tensor-Parallel-Gruppe. Anfragen kommen über FastAPI, werden in eine Request-Queue gestellt und im Scheduler-Loop zu Mikro-Batches zusammengefasst.

Setup-Beispiel. Ein produktives Setup auf einer einzelnen H100 80GB sieht so aus:

``` docker run --gpus all -p 8000:8000 \ -v /models:/models \ vllm/vllm-openai:v0.6.3 \ --model meta-llama/Llama-4-Scout-17B-Instruct \ --max-model-len 131072 \ --gpu-memory-utilization 0.92 \ --enable-prefix-caching \ --api-key sk-fairlane-prod-key ```

Dieser Befehl lädt Llama 4 Scout mit 128k Context, reserviert 92 Prozent des GPU-Speichers für Modell und KV-Cache und aktiviert Prefix-Caching (Antworten für wiederholte System-Prompts kommen aus dem Cache).

PagedAttention im Detail. Der KV-Cache des Transformers wächst linear mit der Eingabelänge. Klassische Implementationen reservieren den Cache als zusammenhängenden Block – bei variabel langen Anfragen entstehen Loecher (Fragmentierung). PagedAttention zerlegt den Cache in feste Blöcke (typisch 16 Tokens) und verwaltet diese über eine Tabelle, ähnlich wie virtueller Speicher im OS. Resultat: der nutzbare Anteil des GPU-Speichers steigt von 60-70 Prozent auf 95+ Prozent.

Continuous Batching. Ein klassischer Server bearbeitet Anfragen FIFO. Solange Anfrage A 200 Tokens generiert, wartet Anfrage B. vLLM dagegen mischt eintreffende Anfragen Token für Token: ist die GPU im selben Forward-Pass mit Anfrage A bei Token 150, kann Anfrage B im nächsten Schritt mitgenommen werden. Das erhöht die Auslastung dramatisch.

Tensor-Parallelism und Pipeline-Parallelism. Für Modelle, die nicht auf eine einzelne GPU passen (Llama 4 Maverick 400B, Apertus 70B in fp16), verteilt vLLM die Layer über mehrere GPUs. "--tensor-parallel-size 2" auf zwei H100 startet Maverick in 4-Bit-AWQ-Quantisierung mit etwa 40-60 Tokens/Sekunde aggregiert.

Monitoring. vLLM exportiert Prometheus-Metriken auf /metrics: vllm:num_requests_running, vllm:gpu_cache_usage_perc, vllm:time_to_first_token_seconds, vllm:e2e_request_latency_seconds. Diese landen in Grafana mit Alerts auf p95-Latenz und Queue-Wartezeit. Logs kommen über stdout in den Docker-Stack und weiter nach Loki.

vLLM produktiv in 5 Schritten

1. 01Hardware-Prüfung: GPU mit mindestens 24 GB VRAM, CUDA 12.4+, Linux (Ubuntu 22.04 oder Debian 12). Treiber-Version mit "nvidia-smi" verifizieren.
2. 02Modell-Wahl und Quantisierung: Apertus 70B in 4-Bit-AWQ für CH-Souveränität, Llama 4 Scout für Long-Context, Mistral Small 3.1 für EU-DE/FR/IT, Phi-4 für minimalen VRAM. Quantisierte Varianten von Hugging Face laden.
3. 03Docker-Container starten: vllm/vllm-openai:v0.6.3 mit Modell, max-model-len, gpu-memory-utilization 0.90-0.92 und einem definierten API-Key.
4. 04LiteLLM-Anbindung: vLLM als OpenAI-kompatibler Provider in der LiteLLM config.yaml eintragen, logischer Name (z.B. local-apertus-70b) und Routing-Regeln definieren.
5. 05Monitoring: Prometheus-Scraper auf /metrics, Grafana-Dashboard mit p95-Latenz, GPU-Cache-Usage und Queue-Tiefe. Alerts ab 1500ms p95 und 80 Prozent GPU-Cache.

Wann vLLM einsetzen

vLLM ist die richtige Wahl, wenn drei Bedingungen zusammenkommen: (a) eine GPU mit mindestens 24 GB VRAM steht zur Verfügung, (b) zehn oder mehr parallele Anfragen pro Sekunde sind erwartbar, (c) Linux als Betriebssystem ist Standard.

Konkrete Fälle: Anwaltskanzlei mit 20+ Mitarbeitern und einem internen Chat-Frontend für Mandanten-Schriftverkehr – vLLM auf 2x H100 mit Apertus 70B oder Llama 4 Maverick. Treuhandgesellschaft mit hohem Batch-Volumen (10.000+ Belege pro Tag mit OCR und Klassifikation) – vLLM auf einer L40S 48GB mit Phi-4 oder Apertus 8B. Versicherung mit Schadenmeldungs-Triage und hohem Throughput-Bedarf – vLLM auf RTX A6000 mit Mistral Small 3.1.

Für den produktiven Einsatz lohnt vLLM auch dann, wenn die Latenz-Anforderungen streng sind. Time-To-First-Token unter 300ms ist auf einer H100 mit Llama 4 Scout problemlos erreichbar – Ollama liegt bei vergleichbarer Last bei 800-1500ms.

Wann NICHT

Ohne GPU ist vLLM nicht der richtige Pfad. Eine CPU-only-Installation läuft technisch, ist aber langsamer als llama.cpp oder Ollama auf der gleichen Hardware – vLLM ist auf GPU-Kerne optimiert.

Wenn die Last unter fünf parallelen Anfragen pro Sekunde liegt, ist der Setup-Aufwand für vLLM nicht gerechtfertigt. Ollama mit Llama 3.3 70B auf derselben H100 ist in einer Stunde aufgesetzt, vLLM braucht ein bis zwei Tage für eine produktive Konfiguration mit Monitoring und Alerts.

Für Mac-Notebooks und Apple-Silicon-Setups ist vLLM nicht relevant – die CUDA-Abhängigkeit schliesst Apple Metal aus. Hier sind Ollama, LM Studio und llama.cpp die richtigen Werkzeuge.

Für Hobby-Erkundung oder Wochenend-Projekte ohne klares Skalierungs-Ziel ist Ollama schlicht angenehmer. vLLM lohnt sich ab dem Moment, wo Throughput, Stabilität und Observability harte Anforderungen werden.

Vor- und Nachteile

Häufige Fragen

Verwandte Themen

Quellen

1. vLLM Project – official documentation · 2026-05
2. vllm-project/vllm – GitHub releases v0.6+ · 2026-05
3. PagedAttention paper – Efficient Memory Management for Large Language Model Serving · 2026-04
4. vLLM 2026 roadmap and benchmark notes (blog) · 2026-05