vLLM Trial

Überblick

vLLM ist eine High-Throughput-LLM-Inference-Engine mit PagedAttention und Continuous Batching für GPU-Cluster (vLLM Docs). Das Projekt entstand im Sky Computing Lab der UC Berkeley (vLLM GitHub), ist seit Mai 2025 ein Hosted Project der PyTorch Foundation (PyTorch Foundation) und stellt einen OpenAI-kompatiblen HTTP-Server bereit (OpenAI-compatible server).

Trial als Serving-Layer hinter internen Model-Endpoints, wenn Latenz und Kosten pro Token zählen. Dazu gehören Autoscaling, Model-Versioning und Safety-Filter am Gateway.

Adoptionssignale

  • Projektgröße Stand 30. September 2026: rund 93.000 GitHub-Stars, mehr als 2.000 Contributors, Apache-2.0-Lizenz, v0.30.0 veröffentlicht am 22. September 2026 (vLLM GitHub, vLLM Releases).
  • Neutrale Governance: Die PyTorch Foundation hat vLLM am 7. Mai 2025 als eines der ersten Projekte unter ihrer neuen Dachstruktur als Hosted Project aufgenommen (PyTorch Foundation).
  • Benannter Produktionseinsatz im großen Maßstab: LinkedIn bedient mehr als 50 GenAI-Use-Cases mit vLLM auf Tausenden Hosts, mit Latenzzielen unter 600 ms für das Query Understanding von AI Job Search (LinkedIn Engineering).
  • Kommerzielle Unterstützung: Inferact, gegründet von den ursprünglichen Entwicklern von vLLM, hat im Januar 2026 eine Seed-Runde über 150 Mio. USD bei einer Bewertung von 800 Mio. USD abgeschlossen, um die Engine zu kommerzialisieren (TechCrunch).
  • Standard-Engine in verteilten Serving-Stacks: llm-d, ein CNCF-Sandbox-Projekt, verbindet Control Planes wie KServe mit vLLM (CNCF) und bildet die Distributed-Inference-Schicht von Red Hat AI 3 (Red Hat), und NVIDIA Dynamo unterstützt vLLM als eines von drei Backends (Dynamo GitHub).

Risiken

  • Exponierte Angriffsfläche. CVE-2026-22778 ermöglichte in den Versionen 0.8.3 bis 0.14.0 Remote Code Execution ohne Authentifizierung über eine präparierte Video-URL (Orca Security); CVE-2026-24779 erlaubte SSRF ins interne Netz, was das Advisory in containerisierten Umgebungen wie llm-d als besonders kritisch einstuft (OSV).
  • Nur teilweise Authentifizierung. Der vLLM-Security-Guide stellt klar, dass --api-key nur einige Pfad-Präfixe abdeckt, und rät davon ab, sich allein darauf zu verlassen; zudem beschreibt er einen Timing-Side-Channel im Prefix Cache, der in Multi-Tenant-Setups Cache Salting erfordert (vLLM Security).
  • Upgrade-Aufwand. Die Releases v0.28.0 bis v0.30.0 haben bitsandbytes in ein Out-of-Tree-Plugin verschoben, Model Runner V1 und den alten api_server-Entrypoint als deprecated markiert und veraltete Umgebungsvariablen entfernt (vLLM Releases); ungepinnte Images können Serving-Konfigurationen brechen.
  • Tuning ist workload-spezifisch. Die Gewinne bei LinkedIn stammen aus Scheduler-Parametern, Prefix Caching und eigenen Upstream-Patches (LinkedIn Engineering); Standardeinstellungen erreichen auf anderen Modellen und GPUs selten die veröffentlichten Durchsatzwerte.

Vorteile & Nachteile

Vorteile

  • Herstellerneutrale Governance und breite Hardware-Abdeckung: vLLM ist ein Apache-2.0-Projekt der PyTorch Foundation mit mehr als 2.000 Contributors und läuft auf GPUs von NVIDIA, AMD und Intel, Google TPUs, Intel Gaudi und weiteren Beschleunigern, was die Bindung an einen einzelnen GPU-Hersteller begrenzt.
  • In großem Produktionsmaßstab bewährt: LinkedIn betreibt mehr als 50 GenAI-Use-Cases, darunter Hiring Assistant und AI Job Search, auf vLLM über Tausende Hosts und hat Optimierungen in das Projekt zurückgespielt.
  • vLLM ist die Engine, auf der der verteilte Serving-Stack aufbaut: llm-d und Red Hat AI setzen auf vLLM, NVIDIA Dynamo unterstützt es als Backend. Wissen und Konfigurationen bleiben nutzbar, wenn ein Team später horizontal skaliert.

Nachteile

  • Die Security-Lage erfordert aktives Management: 2026 wurden unter anderem eine Remote Code Execution ohne Authentifizierung (CVE-2026-22778, CVSS 9,8) und eine SSRF-Lücke (CVE-2026-24779) im Multimodal-Media-Handling veröffentlicht, beide behoben in 0.14.1. Patches müssen entsprechend schnell eingespielt werden.
  • Das eingebaute --api-key schützt nur die Präfixe /v1, /v2, /inference und /cohere; weitere sensible Endpoints auf demselben Server bleiben ohne Authentifizierung, daher gehört vLLM hinter ein Gateway und in ein privates Netz.
  • Hohe Release-Frequenz mit Breaking Changes: etwa alle zwei Wochen erscheint ein Minor Release, mit Entfernungen und Deprecations wie dem als deprecated markierten Model Runner V1 in v0.29.0. Versions-Pinning und Regressionstests sind daher Pflicht.

Empfehlung

vLLM im Trial als Engine hinter selbst betriebenen Endpoints für Open-Weight-Modelle einsetzen, wenn ein Team stetigen Traffic, eigene oder reservierte Cloud-GPUs und einen Grund gegen eine Managed API hat, etwa Datenresidenz oder Kosten pro Token bei hohem Volumen. vLLM gehört hinter ein authentifizierendes Gateway oder einen Proxy im Stil von LiteLLM und in ein privates Netz; Multimodal-Media-Fetching sollte deaktiviert bleiben, solange es nicht gebraucht wird. Prometheus-Metriken und ein Lasttest mit eigenen Prompts sollten vor der ersten produktiven Route stehen.

Eine exakte Version pinnen, die Security Advisories des Projekts abonnieren und einen Patch-Pfad einplanen, der in Tagen statt Quartalen gemessen wird. Für kleine interne Workloads oder Entwickler-Laptops genügt meist eine einfachere Runtime oder ein Managed Endpoint; der Schritt zu llm-d oder NVIDIA Dynamo lohnt sich erst, wenn ein einzelnes vLLM-Deployment pro Modell Latenz- oder Kostenziele nicht mehr erreicht.

Quellen