Zum Inhalt springen

Lokale Inferenz

vLLM
im Test.

vLLM ist ein quelloffener Server, der Sprachmodelle auf eigenen GPUs bereitstellt. PagedAttention verwaltet den Grafikspeicher in Seiten und lässt dadurch mehr gleichzeitige Anfragen auf derselben Karte zu, die fortlaufende Stapelverarbeitung hält die Karte beschäftigt, statt auf freie Plätze zu warten. vLLM unterstützt neue Modelle wie DeepSeek V4, Kimi K3, GLM-5.2 oder MiniMax-M3 meist schon am Erscheinungstag.

5,0 von 5

Stand 5. August 2026

Preismodell Kostenlos, Apache-2.0. Kosten entstehen nur für GPU-Hardware oder GPU-Instanzen in der Cloud.
Betriebsort auf eigener Hardware
DSGVO im Einzelfall zu prüfen
Quelloffen ja, Apache-2.0

Wer einen internen Modellserver betreiben will, an dem mehrere Nutzer gleichzeitig arbeiten, landet früher oder später bei vLLM. Das Projekt stammt aus der University of California in Berkeley und gehört seit dem 07.05.2025 als eigenständiges Projekt zur PyTorch Foundation, hat über 88.000 GitHub-Sterne und liegt in Version 0.26.0 vom 27.07.2026 vor. Zum Ausprobieren an einem einzelnen Arbeitsplatz ist Ollama die einfachere Wahl. vLLM zielt auf Teams, die eine teure GPU auslasten und die Kontrolle über Modell und Daten behalten wollen.

Wichtigste Funktionen

  • PagedAttention: vLLM verwaltet den Grafikspeicher (VRAM) in Seiten, ähnlich wie ein Betriebssystem den Arbeitsspeicher. Dadurch bleibt weniger davon ungenutzt liegen, und auf derselben Karte laufen mehr Anfragen gleichzeitig.
  • Fortlaufende Stapelverarbeitung: vLLM flicht neue Anfragen in bereits laufende Generierungen ein, statt sie auf einen freien Platz warten zu lassen. Die GPU steht dadurch selten still.
  • OpenAI-kompatible Schnittstelle: Anwendungen, die gegen die OpenAI-Schnittstelle gebaut sind, sprechen ohne Änderung am Code mit einem vLLM-Server im eigenen Netz. Das gilt auch für fertige Oberflächen und Bibliotheken, die auf dieser Schnittstelle aufsetzen.
  • Modelle am Erscheinungstag: Kimi K3 stand am 27.07.2026 an seinem Erscheinungstag bereit, DeepSeek V4, GLM-5.2, MiniMax-M3 und Qwen3 ebenso. Neue Architekturen kommen mit fast jeder Version dazu, multimodale Modelle mit Bildeingabe eingeschlossen.
  • Quantisierung: GPTQ, AWQ, INT4, INT8 und FP8 senken den VRAM-Bedarf, sodass größere Modelle auf kleinere Karten passen. Spekulatives Dekodieren beschleunigt die Ausgabe zusätzlich.
  • Skalierung und Hardware: Über Tensor- und Pipeline-Parallelität schaltet vLLM mehrere Grafikkarten und mehrere Server zusammen, Docker und Kubernetes sind vorgesehen. Im Hauptzweig liegen NVIDIA CUDA, AMD ROCm und Intel XPU sowie ein Prozessor-Zweig für x86, ARM und Apple Silicon, während Intel Gaudi und Google TPU als Erweiterungen außerhalb des Projekts gepflegt werden.

Preise und Tarife

vLLM steht unter Apache-2.0 und kostet nichts, auch im gewerblichen Einsatz. Geld kostet nur die Hardware darunter. Wie viel VRAM eine Karte mitbringen muss, hängt von Modellgröße und Quantisierung ab, für die großen offenen Modelle sind Karten der H100-Klasse oder mehrere Karten im Verbund die übliche Grundlage.

In der Cloud startet vLLM auf jeder GPU-Instanz, mehrere Anbieter liefern dafür fertige Abbilder aus, sodass nur die Instanzkosten anfallen. Was ein GPU-Anbieter dafür verlangt, steht auf seinen Preisseiten als Nettobetrag, die Umsatzsteuer kommt bei der Abrechnung hinzu.

Für wen ist vLLM geeignet?

  • Plattform- und Betriebsteams: Ein zentraler Modellserver für Entwicklung, interne Werkzeuge oder ein eigenes Produkt bedient mit vLLM viele Nutzer gleichzeitig auf derselben Karte.
  • Unternehmen mit strengen Datenschutzanforderungen: Mandanten-, Patienten- oder Personaldaten, die kein externer Schnittstellenanbieter verarbeiten darf, bleiben mit vLLM im eigenen Rechenzentrum.
  • Forschungsgruppen und KI-Entwicklungsteams: Ein Team, das Modelle vergleicht, eigene Feinabstimmungen ausliefert oder große Textmengen im Stapel verarbeitet, zahlt statt der Bezahl-Schnittstellen großer Anbieter nur die eigene GPU.

DSGVO und Datenschutz

vLLM verarbeitet Anfragen auf der eigenen GPU. Einen Anbieter, der Prompts und Antworten speichert oder zum Training nutzt, gibt es in diesem Aufbau nicht.

Ab Werk ist allerdings eine Nutzungsstatistik eingeschaltet, die beim Start und danach alle 10 Minuten einen Datensatz an stats.vllm.ai schickt, darin eine erzeugte Kennung, der Cloud-Anbieter, Prozessortyp und Kernzahl, Arbeitsspeicher, Betriebssystem, CUDA-Version, Anzahl und Typ der Grafikkarten, die Modellarchitektur, die vLLM-Version und die wichtigsten Startparameter. Prompts und Antworten stehen nicht darin, die IP-Adresse des Servers fällt bei der Verbindung dennoch an. Die Meldung schaltet die Umgebungsvariable VLLM_NO_USAGE_STATS=1 ab, ebenso DO_NOT_TRACK=1 oder eine leere Datei unter ~/.config/vllm/do_not_track.

Ohne --host bindet der Server an alle Netzwerkschnittstellen, und ohne --api-key verlangt er keinen Schlüssel. Beide Werkseinstellungen gehören vor den ersten Start geprüft, denn ohne vorgelagerten Zugriffsschutz steht das Modell dem gesamten erreichbaren Netz offen. Die Modellgewichte holt vLLM ab Werk von Hugging Face, ein lokaler Pfad oder ein Spiegel im eigenen Netz ersetzt diesen Weg.

Das grüne Abzeichen steht auf dieser Seite deshalb auf nein. Eine Installation im Auslieferungszustand meldet Betriebsdaten an einen Server des Projekts, dessen Träger eine US-amerikanische Stiftung ist, und sie steht ohne Anmeldung im Netz. Wer die Statistik abschaltet, den Server an eine feste Adresse bindet, einen Schlüssel vergibt und die Gewichte aus dem eigenen Speicher lädt, hat dagegen einen Aufbau, bei dem überhaupt kein Auftragsverarbeiter entsteht. Für Kanzleien, Kliniken und Behörden ist das die am leichtesten zu begründende Betriebsform, von allein stellt sie sich nicht ein.

Alternativen zu vLLM

  • Ollama: Für einen einzelnen Arbeitsplatz in wenigen Minuten eingerichtet und auch ohne Grafikkarte brauchbar. Bei vielen gleichzeitigen Anfragen liegt es deutlich hinter vLLM.
  • LiteLLM: Vermittler, der mehrere Modellanbieter samt vLLM hinter einer OpenAI-kompatiblen Schnittstelle bündelt. Sinnvoll vor einem vLLM-Server, wenn mehrere Modelle unter einer Adresse liegen sollen.
  • llama.cpp: Läuft auf fast jeder Hardware, auch ohne Grafikkarte, und kommt ohne die Werkseinstellungen aus, die bei vLLM erst abzustellen sind. Für viele parallele Anfragen ist vLLM die stärkere Grundlage.

Wofür vLLM taugt

  • OpenAI-kompatible Schnittstelle, bestehende Anwendungen laufen ohne Änderung am Code gegen den eigenen Server
  • Läuft auf NVIDIA CUDA, AMD ROCm und Intel XPU, dazu ein Zweig für x86-, ARM- und Apple-Silicon-Prozessoren
  • Neue Modelle wie Kimi K3 oder GLM-5.2 sind meist am Erscheinungstag lauffähig
  • Apache-2.0 ohne Einschränkung für den gewerblichen Einsatz, getragen von der PyTorch Foundation

Wo es hakt

  • GPU mit viel VRAM nötig, damit sich der Betrieb rechnet
  • Die Einrichtung verlangt Kenntnisse in Docker, CUDA und GPU-Treibern
  • Der Server bindet ab Werk an alle Netzwerkschnittstellen und verlangt keinen Schlüssel
  • Die Nutzungsstatistik ist ab Werk eingeschaltet und meldet Hardware- und Startdaten an stats.vllm.ai

Wofür es eingesetzt wird

Modellserver für Teams und Unternehmen · Bestehende OpenAI-Anwendungen auf eigene Modelle umstellen · Große Textmengen im Stapel verarbeiten · Viele gleichzeitige Nutzer auf einer GPU bedienen · Sprachmodelle im eigenen Rechenzentrum betreiben