Was vLLM ist und warum LLM-Inferenz der Engpass ist
vLLM ist eine quelloffene Inferenz-Engine für große Sprachmodelle, ursprünglich aus dem Sky Computing Lab der UC Berkeley und inzwischen ein breit genutztes Community-Projekt. Sie adressiert den Teil eines KI-Systems, der gern unterschätzt wird: die LLM-Inferenz, das effiziente Erzeugen von Tokens, sobald ein Modell fertig trainiert ist. Wer Self-Hosting von LLMs oder LLM-Hosting in Deutschland ernst meint, entscheidet genau hier über Kosten, Latenz und Hardware-Auslastung. Trainiert wird einmal; Inferenz läuft bei jeder einzelnen Anfrage. vLLM existiert, um diesen Schritt auf eigenen GPUs schnell, planbar und bezahlbar zu machen, statt ihn an eine fremde Cloud-API zu delegieren.
Das Kernproblem ist Speicher, nicht reine Rechenleistung. Während der Generierung hält ein Modell einen KV-Cache, die Attention-Keys und -Values aller bereits verarbeiteten Tokens. Dieser Cache wächst mit der Sequenzlänge und mit der Zahl gleichzeitiger Anfragen und dominiert den GPU-Speicher. Naives Serving verschwendet viel davon durch Fragmentierung und Überreservierung, erzwingt kleine Batches und lässt teure Beschleuniger im Leerlauf. vLLMs zentrale Idee: KV-Cache-Speicher so verwalten, wie ein Betriebssystem den Arbeitsspeicher verwaltet.
PagedAttention: KV-Cache wie virtueller Speicher
PagedAttention ist vLLMs prägende Technik. Statt pro Anfrage einen großen zusammenhängenden Speicherblock zu reservieren, zerlegt sie den KV-Cache in Blöcke fester Größe, Seiten, und bildet sie über eine Block-Tabelle ab, genau wie das Speicher-Paging eines Betriebssystems. Die Vorteile sind konkret: interne Fragmentierung wird weitgehend eliminiert, sodass sonst verschwendeter Speicher für mehr gleichzeitige Anfragen frei wird; auf gleicher Hardware sind größere effektive Batches möglich; und gleiche Präfixe lassen sich günstig teilen. Teilen sich viele Anfragen einen System-Prompt oder verzweigt ein Sampling-Baum, werden die gemeinsamen Seiten einmal gespeichert und nur referenziert statt kopiert. Praktisch bedeutet das deutlich höhere Speichereffizienz, und damit mehr bediente Nutzer pro Karte.
Continuous Batching und die API-Oberfläche
Die zweite Säule ist Continuous Batching, also Scheduling auf Iterationsebene. Klassisches statisches Batching wartet, bis ein Batch voll ist, rechnet alle Anfragen gemeinsam zu Ende und lässt erst danach neue zu, eine einzige lange Generierung blockiert dann alles dahinter. vLLM plant stattdessen pro Dekodierungsschritt: Fertige Sequenzen verlassen den Batch sofort, wartende Anfragen rücken in der nächsten Iteration nach. So bleibt die GPU auch unter realem Mischverkehr mit stark schwankenden Prompt- und Ausgabelängen ausgelastet, der Hauptgrund für vLLMs hohen Durchsatz.
Um die Engine herum liefert vLLM einen OpenAI-kompatiblen API-Server. Er stellt die vertrauten Endpunkte /v1/chat/completions und /v1/completions bereit, sodass bestehende Tools, SDKs und Gateways gegen ein selbst gehostetes Modell laufen, oft genügt eine geänderte Basis-URL. Diese Kompatibilität macht den Umzug von einer kommerziellen API zu einer Konfigurations- statt einer Umbau-Frage.
Skalierung: Tensor-Parallelismus, Quantisierung, Modelle
Eine einzelne GPU kann die größten Modelle nicht halten, deshalb unterstützt vLLM Tensor-Parallelismus: Die Gewichte jeder Schicht werden über mehrere GPUs verteilt, die im Gleichtakt rechnen, so läuft ein Modell der 70B-Klasse über mehrere Karten in einem Server. Für größere Deployments kommt Pipeline-Parallelismus über Knoten hinzu. Den Speicherdruck senkt zusätzlich die Quantisierung: vLLM unterstützt Formate wie AWQ, GPTQ und FP8, die die Gewichte (mit FP8 auch den KV-Cache) verkleinern, sodass ein Modell auf weniger oder kleinere GPUs passt, bei einem kontrollierten, messbaren Genauigkeits-Kompromiss, den man an den eigenen Aufgaben prüfen sollte.
Modellseitig deckt vLLM das gängige offene Ökosystem ab: Llama, Mistral und Mixtral, Qwen, Gemma, Phi sowie deutsche und europäische Projekte wie Teuken (OpenGPT-X/Fraunhofer, offene Gewichte unter Apache-2.0), neben vielen weiteren. Weil es offene Gewichte sind, lassen sie sich vollständig auf selbst kontrollierter Infrastruktur betreiben, das Fundament echter souveräner KI.
vLLM vs. Ollama und TGI, und der Zielkonflikt Durchsatz/Latenz
vLLM ist nicht die einzige Option. Welches Werkzeug passt, hängt vom Ziel ab. Ollama eignet sich hervorragend für lokales Experimentieren und Einzelplatz-Setups mit einem Nutzer, trivial zu installieren, freundliche Defaults, bescheidene Hardware. TGI (Text Generation Inference von Hugging Face) ist ein ausgereifter, in Rust geschriebener Produktionsserver mit ebenfalls hohem Durchsatz; zu beachten ist allerdings, dass Hugging Face TGI Ende 2025 in den Wartungsmodus überführt hat, es wird weiter gepflegt, aber nicht mehr aktiv weiterentwickelt, weshalb vLLM heute die dynamischere Wahl für neue Produktivdeployments ist. vLLM spielt seine Stärke aus, wenn maximaler Durchsatz und Nebenläufigkeit auf GPU-Servern gefragt sind, viele gleichzeitige Nutzer hinter einem Deployment. Faustregel: Ollama für Entwickler-Laptop oder kleines internes Tool, vLLM für einen gemeinsam genutzten Produktionsdienst (TGI weiterhin möglich, sofern der Wartungsstatus akzeptabel ist).
Durchsatz und Latenz ziehen gegeneinander, und die Balance hängt von GPU-Modell, Modellgröße, Kontextlänge und Nebenläufigkeit ab. Große Batches maximieren die Tokens pro Sekunde über alle Nutzer, können aber die Zeit bis zum ersten Token einer einzelnen Anfrage verlängern; kleine Batches kehren das um. Es gibt keine universelle Benchmark-Zahl, die sich übertragen lässt, wer eine nennt, ohne Hardware, Modell und Last zu benennen, rät. Kapazität dimensioniert man an der eigenen, repräsentativen Last.
Wie Beyonetix vLLM in Deutschland betreibt, und was kommt
Beyonetix betreibt vLLM auf eigenen GPU-Servern in Deutschland und bedient offene Modelle im Bereich 7B bis 70B. Vor den Inferenz-Engines sitzt ein LiteLLM-Gateway, das einen einzigen OpenAI-kompatiblen Endpunkt bereitstellt, Anfragen über Modelle und Instanzen routet, Schlüssel und Budgets verwaltet und Logging zentralisiert, so adressieren Anwendungen eine stabile Schnittstelle, während die dahinterliegenden Modelle wechseln können. Entscheidend: Prompts, Dokumente und generierte Texte verlassen die vom Kunden kontrollierte Infrastruktur nicht, Datenresidenz in Deutschland und kein Default auf US-Modelle. Das schafft eine gute technische Grundlage für Organisationen unter DSGVO oder branchenspezifischer Vertraulichkeit. Wir geben dabei keine pauschale Compliance-Garantie ab und halten keine ISO- oder BSI-Zertifikate: Ob ein konkreter Aufbau DSGVO-konform ist, hängt vom Gesamtsystem ab (Verträge, TOMs, Verarbeitungszwecke) und gehört zur Bewertung an Ihre Datenschutzbeauftragten oder Ihre Rechtsberatung. Derselbe Stack treibt unsere citation-basierte Recherche an, etwa ein großes produktives KI-Archiv, wo Antworten auf Quellen rückführbar sein müssen. Mehr dazu unter KI-Infrastruktur & Hosting.
Mit Blick nach vorn reift die Inferenzschicht schnell weiter: Speculative Decoding, Prefix-Caching, klügere Quantisierung und entkoppeltes Prefill/Decode heben die Effizienz stetig, während die offene Modelllandschaft, inklusive europäischer Modelle, Monat für Monat wächst. Für deutsche Organisationen ist genau diese Kombination der praktische Weg zu schneller, kostenkontrollierter und souveräner KI zu eigenen Bedingungen.