Was ist vLLM?
vLLM ist eine Open-Source-Bibliothek, die ein Sprachmodell zu einem Dienst macht. Du bringst ein Modell mit, Llama, Mistral oder Apertus, und vLLM stellt daraus eine API bereit, die deine Anwendungen aufrufen. Entstanden ist das Projekt im Sky Computing Lab der UC Berkeley; heute pflegen es über 2'000 Beitragende.
Wichtig ist die Abgrenzung: vLLM trainiert keine Modelle und liefert keine mit. Es betreibt sie. Wenn du dich entschieden hast, offene Modelle auf eigener Hardware laufen zu lassen statt eine gehostete API zu rufen, ist vLLM eines der Teile, die das praktikabel machen.
Das Problem dahinter
Der grösste Teil des GPU-Speichers geht beim Betrieb eines Sprachmodells in den KV-Cache, also in den Zwischenzustand, den jede laufende Anfrage beim Erzeugen von Tokens aufbaut. Einfache Implementierungen reservieren dafür pro Anfrage einen festen Block, bemessen an der längstmöglichen Antwort. Die meisten Antworten sind kürzer, der reservierte Speicher bleibt ungenutzt, und die GPU verarbeitet deutlich weniger Anfragen gleichzeitig, als sie könnte.
PagedAttention verwaltet diesen Speicher stattdessen seitenweise, ähnlich wie ein Betriebssystem virtuellen Speicher verwaltet. Jede Anfrage belegt nur, was sie tatsächlich braucht, und die GPU hält viel mehr davon gleichzeitig. Im Benchmark, den vLLM gegen naives HuggingFace-Serving veröffentlicht hat, ergibt das bis zu 23-mal höheren Durchsatz.
Zwei weitere Mechanismen zählen im Betrieb ebenso viel. Continuous Batching nimmt neue Anfragen in einen laufenden Batch auf, sobald frühere fertig sind, statt auf den ganzen Batch zu warten. Tensor-Parallelismus verteilt ein Modell über mehrere GPUs, wenn es auf einer nicht Platz findet.
Wann vLLM passt
Es passt, wenn du offene Modelle unter echtem Verkehr betreibst und die GPU-Rechnung eine Position ist, die dich interessiert. Der Vorteil liegt in der Gleichzeitigkeit: eine einzelne Anfrage auf einer leeren GPU läuft ungefähr so schnell wie mit jedem anderen Stack.
Es passt, wenn die Prompts die Jurisdiktion nicht verlassen dürfen. Das Modell selbst zu betreiben ist die einzige Konstellation, in der der Text einer Anfrage nie bei einem Dritten landet. Genau das ist der Grund, aus dem die meisten Schweizer Organisationen sich das überhaupt ansehen.
Wann nicht
Zum Ausprobieren auf dem Notebook bringt dich ein schlankerer lokaler Runner schneller zur ersten Antwort. vLLM ist für Server mit Rechenzentrums-GPUs gebaut.
Bei einer Handvoll Anfragen pro Tag ist eine gehostete API mit hoher Wahrscheinlichkeit günstiger. Eine stundenweise gemietete GPU kostet gleich viel, ob sie eine Anfrage bedient oder tausend, und der Durchsatzvorteil zahlt sich erst unter Last aus.
Wenn du ein bestimmtes proprietäres Modell brauchst, stellt sich die Frage nicht. vLLM betreibt offene Modelle und kann keines betreiben, dessen Gewichte niemand herausgibt.
vLLM gegenüber einer gehosteten API
Eine gehostete Inference-API ist ein Dienst. vLLM ist eine Komponente, die du betreibst. Du übernimmst den Lebenszyklus der Modelle, die GPU-Kapazitätsplanung und die Verfügbarkeit des Endpunkts und bekommst dafür Kontrolle darüber, wohin die Daten gehen und was die einzelne Anfrage kostet.
Ein Detail macht die Entscheidung umkehrbar: vLLM bietet eine OpenAI-kompatible API. Eine Anwendung, die gegen die OpenAI-Bibliotheken geschrieben ist, zeigt ohne Codeänderung auf einen vLLM-Endpunkt. Damit lässt sich die Frage testen, statt sie zu entscheiden.
Was der Betrieb verlangt
Unkompliziert sind: vLLM installieren, ein Modell laden, auf einer GPU eine Antwort bekommen.
Nicht unkompliziert, und ausschlaggebend dafür, ob die Sache echten Verkehr übersteht:
- GPU-Scheduling. Inference-Pods, Batch-Jobs und alles andere im Cluster konkurrieren um eine knappe Ressource. Device Plugins, Quotas und Priority Classes entscheiden, wer gewinnt, und die Voreinstellungen tun das nicht.
- Kapazität und Kosten. Allein die Modellgewichte umfassen zweistellige Gigabyte-Beträge, bevor überhaupt feststeht, wie viel GPU das Verkehrsprofil braucht. Geraten wird das in beide Richtungen teuer.
- Am richtigen Signal skalieren. Ein Inference-Dienst lässt sich nicht sinnvoll über CPU-Auslastung skalieren. Queue-Tiefe und Latenzziele funktionieren.
- Wissen, was es kostet. Latenz bei p50, p95 und p99, Tokens pro Sekunde, GPU-Auslastung und Queue-Tiefe sagen dir, ob du hoch- oder runterskalierst oder das Modell wechselst.
Nichts davon ist exotisch. Es ist gewöhnliche Plattformarbeit, und es ist der Grund, warum ein Proof of Concept auf einer GPU oft stehen bleibt, bevor er Nutzende erreicht.
Wo VSHN hineinpasst
VSHN betreibt vLLM auf Kubernetes und OpenShift in Schweizer Rechenzentren, auf Exoscale, Cloudscale und weiteren Schweizer Anbietern. Modellgewichte, Prompts, Antworten und Inference-Logs bleiben in der gewählten Jurisdiktion. Unsere Souveränitätsbewertung zeigt, wie das gegen das EU Cloud Sovereignty Framework abschneidet.
Wenn du abwägst, ob du Modelle selbst betreiben willst, ist der nützliche erste Schritt meist nicht die Architektur, sondern die Dimensionierung: wie viel GPU dein Modell und dein Verkehrsprofil tatsächlich brauchen und was das gegenüber der gehosteten Variante kostet.