Hochdurchsatz-LLM-Inferenz mit vLLM auf eigener Hardware

Lokale LLMs sind längst Werkzeuge im Tagesbetrieb, kein Experiment mehr. Aber rohe Inferenz mit Transformers ist langsam. vLLM adressiert genau das.

PagedAttention: Der Schlüssel

Klassische Inferenz speichert den Key-Value-Cache jedes Tokens linear: das führt zu Speicherfragmentierung und Ineffizienz beim Batching. vLLM nutzt stattdessen PagedAttention: der KV-Cache wird in Blöcken (Pages) verwaltet, wie virtueller Speicher. Das erlaubt Sharing, Wiederverwendung und vor allem kontinuierliches Batching.

Das bedeutet konkret: Neue Requests müssen nicht warten, bis der aktuelle Batch geschlossen wird. Sie rücken in den nächsten freien Block ein, sobald Platz ist. Der Durchsatz richtet sich nach der GPU, nicht nach der Starrheit des Batch-Rasters — im Dauerbetrieb summiert sich das zu spürbar mehr Durchsatz.

Ergebnis: 10 gleichzeitige Requests laufen nicht 10× langsamer, sondern vielleicht 2×, weil Speicher und Rechenzeit dynamisch geteilt werden.

Betrieb auf einer RTX 5090

Die 5090 mit 32 GB VRAM ist unsere Standard-Inferenzkarte. Mit vLLM läuft darauf problemlos ein 70B-Modell mit Q4-Quantisierung oder ein 13B-Modell mit vollen Gewichten. Die OpenAI-kompatible API funktioniert mit jedem Tool, das openai als Backend erwartet, ohne Anpassung.

python -m vllm.entrypoints.openai.api_server \
  --model mistralai/Mixtral-8x22B-Instruct-v0.1 \
  --tensor-parallel-size 1 --max-model-len 8192

Dann zeigt jedes Tool, das „OpenAI-kompatibel" kann, einfach auf http://<server>:8000/v1.

Was im Betrieb wirklich zählt

Bei hoch verfügbarem Einsatz sind drei Dinge entscheidend: VRAM-Budget sauber setzen (--max-model-len und --gpu-memory-utilization auf den konkreten Host abstimmen, sonst gibt es OOM unter Last), Token-Raten monitoren (Prometheus-Endpoint von vLLM liefert Latenz und Durchsatz pro Modell), und die Quantisierung bewusst wählen. Für Text reicht Q4 oft völlig; für Strukturierung und Ziffern-Extraktion bevorzugen wir hingegen FP8, weil es die Trefferquote der Ergebnisse spürbar hebt.

vLLM-Engine-Logs mit Prompt-Durchsatz, Generierungsdurchsatz und KV-Cache-Auslastung — vLLM im Eigenbetrieb: Die Engine-Logs zeigen Prefill-Durchsatz, Generierungsrate und KV-Cache-Auslastung pro Intervall — genau die Kennzahlen, auf die es im Dauerbetrieb ankommt.

Wann vllm, wann llama.cpp?

vLLM glänzt bei hohem Durchsatz, vielen parallelen Requests und Server-Betrieb. Für einzelne Requests, CPU-Offload oder exotische Quantisierungen ist llama.cpp besser. Beide haben ihre Berechtigung — siehe nächster Artikel.

Warum selbst hosten statt Cloud-API?

Für den Mittelstand rechnet sich der Eigenbetrieb schnell. Eine einzelne RTX 5090 im eigenen Rack deckt die Last dutzender Nutzer ab — ohne pro-Token-Abrechnung und ohne dass ein Beleg das Haus verlässt. Die Cloud-API rechnet sich bei kleinem Volumen oder bei Modellen, die lokal nicht laufen; sobald aber Daten-Souveränität, gleichbleibende Latenz und berechenbare Kosten zählen, ist on-prem die klarere Lösung.

Dazu kommt die Vorhersagbarkeit: Eine lokale Karte skaliert linear bis zu ihrem Limit, während Cloud-Preise je nach Tarif, Region und verwendetem Modell schwanken. Wer eine Extraktions-Pipeline im Dauerbetrieb hält, weiß am Ende des Monats ganz genau, was die Karte gekostet hat: Stromrechnung inklusive.

Fazit

Wenn Sie LLMs für mehr als einen einzelnen Nutzer bereitstellen wollen, ist vLLM die erste Wahl. Die Architektur mit PagedAttention spart VRAM und erhöht den Durchsatz messbar. Für den Mittelstand heißt das: eine einzelne eigene Karte ersetzt mehrere teure Cloud-API-Abos, und die Daten bleiben im Haus.