Eigene Sprachmodelle mit vLLM auf Kubernetes, Daten im Haus und Kosten, die Sie planen können

Eigene Modelle ermöglichen zwei Dinge, die eine öffentliche API nicht leistet: Daten, die Ihre Infrastruktur nicht verlassen dürfen, lassen sich mit KI nutzen, und eine Aufgabe, die den ganzen Tag läuft, kostet, was die GPUs kosten, egal wie viele Anfragen sie stellt. Außerdem behalten Sie die Kontrolle über die Modellversion, sodass sich Antworten nicht ändern, weil ein Anbieter sein Modell aktualisiert hat.

Viele Unternehmen bereiten sich darauf vor. In einer Umfrage von CIO und Computerwoche mit Dell aus dem Jahr 2026 unter 106 IT-Verantwortlichen aus mittelständischen Unternehmen in Deutschland, Österreich und der Schweiz hatten 20 % begonnen, lokale Serverinfrastruktur für KI aufzubauen. GPUs sind eine große Anschaffung, deshalb messen wir mit Ihrer Last, bevor etwas gekauft wird.

Eigene Modelle lohnen sich, wenn Daten Ihre Infrastruktur nicht verlassen dürfen, wenn eine Aufgabe dauerhaft in hohem Volumen läuft oder wenn Sie die Modellversion vollständig kontrollieren müssen. Für eine kleine Nutzergruppe, sehr ungleichmäßige Nutzung oder Aufgaben, bei denen nur die größten kommerziellen Modelle gut genug sind, sind sie meist die falsche Wahl.

Die Kosten hängen von GPU-Klasse und Anzahl ab, davon, wie ausgelastet die GPUs sind, von der Modellgröße und vom Aufwand für den Betrieb. Diese Faktoren vergleichen wir mit dem, was dieselbe Arbeit über eine API kosten würde, bevor Sie entscheiden.

Die Frage „Wie viele GPUs brauchen wir für 50 Nutzer?“ lässt sich ohne Details nicht beantworten: wie viele Anfragen gleichzeitig ankommen, wie lang Dokumente und Antworten sind, welche Modellgröße und Quantisierung Ihre Tests bestehen und welche Antwortzeiten Ihre Nutzer akzeptieren. Bei vielen gleichzeitigen Anfragen geht meist zuerst der GPU-Speicher für den KV-Cache aus, bevor die Rechenleistung an ihre Grenze kommt.

Deshalb messen wir zuerst, auf gemieteten GPUs oder vorhandener Hardware, mit Ihren eigenen Prompts und Dokumenten. Server kaufen Sie erst, wenn Sie die Zahlen gesehen haben.

vLLM läuft gut auf Kubernetes, sobald die GPU-spezifischen Teile gelöst sind.

• GPU-Knotenpools mit den Treibern und dem Device Plugin, die Ihr Cluster braucht, im eigenen Rechenzentrum oder auf EKS oder AKS.
• Modelldateien nah an den Knoten zwischengespeichert, damit ein neues Replikat nicht erst Gigabytes herunterlädt, bevor es antworten kann.
• Autoscaling nach den eigenen Metriken von vLLM, etwa wartenden Anfragen und Cache-Auslastung, weil die CPU-Last niedrig bleibt, während die GPU arbeitet.
• Readiness-Checks, die warten, bis das Modell geladen ist, und Rollouts, die genug Kapazität halten, während eine neue Version startet.
• Dashboards und Alarme für Antwortzeiten, Warteschlange, Fehler und GPU-Auslastung, im Monitoring, das Sie schon betreiben.

vLLM ist die Serving-Engine. KServe ergänzt einen einheitlichen Weg, Modelldienste auf Kubernetes zu beschreiben und auszurollen, und llm-d ist ein neueres Projekt, das Inferenz mit vLLM auf viele GPUs verteilt. Nach unserer Einschätzung starten die meisten Unternehmen gut mit einfachen vLLM-Deployments hinter einem Gateway und ergänzen diese Schichten, wenn die Zahl der Modelle oder GPUs sie rechtfertigt.

Ein kleineres oder quantisiertes Modell kann günstiger und schneller sein, aber schlechter bei Ihrer Aufgabe. Bevor ein Modell live geht und vor jedem Update lassen wir Ihre Regressionstests gegen das Modell laufen, das ersetzt würde, und wechseln nur, wenn die Qualität hält.