KI-Inferenz auf Kubernetes: vLLM produktiv, betrieben von Pexon
Pexon betreibt vLLM und LiteLLM auf eurem eigenen Kubernetes-Cluster: GPU-Autoscaling, Modell-Updates, Quantisierung und Inferenz-Verfügbarkeit, auf offenen Standards ohne Hyperscaler-Lock-in. Von 51 untersuchten Anbietern im deutschsprachigen Kubernetes-Markt liefert keiner KI auf Kubernetes als Betriebsangebot (Pexon Anbieter-Auswertung, Stand August 2026). Betrieb ab 5.000 EUR im Monat, Servicezeit Mo-Fr 08:00-18:00 MEZ.
Warum der vLLM-PoC im Eigenbetrieb teuer wird
Ein vLLM-Pod steht in einer Stunde. Teuer wird erst der Monat danach: GPU-Nodes laufen auch dann, wenn niemand eine Anfrage schickt, ein Modellwechsel legt die Schnittstelle still, und unter Last wächst die Warteschlange schneller als die Antwortzeit. Von 51 untersuchten Anbietern im deutschsprachigen Kubernetes-Markt liefert keiner KI auf Kubernetes als Betriebsangebot.
Wer macht was im vLLM-Betrieb auf Kubernetes?
KI-Inferenz auf Kubernetes heißt: ein Sprachmodell beantwortet Anfragen aus eurem eigenen Cluster statt aus der API eines Anbieters. Die Inferenz-Engine dafür ist vLLM: Der Dienst lädt die Modellgewichte in den GPU-Speicher, fasst eingehende Anfragen zu Stapeln zusammen und liefert Antworten über eine OpenAI-kompatible Schnittstelle. Davor sitzt in der Regel ein Gateway wie LiteLLM, das Anfragen auf mehrere Modelle verteilt, Schlüssel je Team vergibt und den Verbrauch zuordnet. Kubernetes liefert darunter, was ein Produktivbetrieb braucht: GPU-Nodes als planbare Ressource, Neustarts ohne Handarbeit und Rollouts über GitOps. Betrieb meint dabei mehr als das erste Deployment. GPU-Kapazität wächst und schrumpft mit der Last, Modellstände werden versioniert ausgerollt und bei schlechter Antwortqualität wieder zurückgenommen, die Quantisierung wird vor jedem Rollout gegen Speicherbedarf und Antwortqualität geprüft, und für den Ausfall des Endpunkts gibt es eine benannte Zuständigkeit. Genau diese Dauerpflichten unterscheiden eine produktive Inferenz-Plattform von einem funktionierenden PoC. Der Streit im Projekt entsteht deshalb selten an der Engine, sondern an der Zuständigkeit. Die folgende Tabelle ist der Schnitt, den wir vertraglich ziehen: links die Betriebsaufgabe, rechts die Person, die sie am Montagmorgen tatsächlich macht.
| Betriebsaufgabe | Werkzeug im Stack | Takt | Wer macht es |
|---|---|---|---|
| GPU-Kapazität skalieren | Karpenter und NVIDIA GPU Operator | laufend | Pexon |
| Inferenz-Engine betreiben | vLLM auf eurem Cluster | laufend | Pexon |
| Modell-Rollout und Rückweg | GitOps, ein Commit je Änderung | je Modellversion | Pexon plant, ihr gebt frei |
| Quantisierung wählen und prüfen | vLLM mit reduzierter Gewichts-Genauigkeit | vor jedem Rollout | Pexon |
| Routing und Ausweichpfad über mehrere Modelle | LiteLLM-Gateway | laufend | Pexon |
| Kosten je Team zuordnen | LiteLLM-Budgets und getrennte Keys | monatlich | Pexon liefert die Zahlen, ihr entscheidet |
| Prompts, Retrieval und Anwendungslogik | euer eigener Code | euer Takt | ihr |
| Modell-Training und Fine-Tuning | nicht Teil des Angebots | - | bleibt bei euch oder eurem Data-Science-Partner |
Die Servicezeit für alle Zeilen mit Pexon in der letzten Spalte ist Mo-Fr 08:00-18:00 MEZ. Verfügbarkeitsprozente und Reaktionszeiten nennen wir hier bewusst nicht, solange sie nicht im Vertrag stehen.
Was ändert sich, wenn jemand die Inferenz betreibt statt nur aufsetzt?
Vier Größen, die sich messbar ändern, sobald der Inferenz-Betrieb eine bezahlte Leistung ist statt eine Nebentätigkeit.
Ab wann sich betriebene vLLM-Inferenz lohnt
Wofür Kunden vLLM auf Kubernetes betreiben lassen
Inferenz-Betrieb für ein SaaS-Produkt
Ein SaaS-Anbieter aus dem DACH-Raum hat KI-Features im Produkt, aber kein Plattform-Team. Pexon betreibt die vLLM-Inferenz auf dem Cluster des Kunden, inklusive GPU-Nodes, Modellständen und Gateway.
Ein Endpunkt für mehrere Modelle
Produktteams rufen unterschiedliche Modelle, jedes mit eigenem Schlüssel und eigener Rechnung. Wir setzen LiteLLM als Gateway davor, so dass die Anwendungen eine Adresse kennen und wir dahinter umbauen können.
Modellwechsel ohne stille Schnittstelle
Eine neue Modellversion soll produktiv gehen. Der Wechsel läuft über das Repository, nicht über den Cluster-Zugang, und der alte Stand bleibt als Ziel im selben Weg erhalten.
Übernahme eines bestehenden vLLM-Setups
Der PoC läuft schon, aber gewachsen und undokumentiert. Wir nehmen den Stand auf, ziehen ihn nach GitOps und übernehmen danach den Betrieb, ohne dass ihr die Engine tauschen müsst.
Welche Bausteine vLLM-Inferenz auf Kubernetes braucht
Wir bringen keine Plattform mit, die ihr mieten müsst. Wir arbeiten auf eurem Cluster, mit den Bausteinen, die im Inferenz-Umfeld ohnehin Standard sind.
Inferenz-Schicht
Cluster und Hardware
Wie der Inferenz-Betrieb funktioniert
vLLM selbst betreiben oder betreiben lassen?
Wie lange dauert es, vLLM produktiv zu bekommen?
Was kostet es, vLLM betreiben zu lassen?
Drei Positionen, mehr nicht: ein Scan zum Einstieg, ein einmaliges Onboarding bis zum Go-live, danach der monatliche Betrieb. Die Rechenleistung kauft ihr direkt bei eurem Anbieter, wir schlagen nichts darauf.
| Position | Was darin passiert | Dauer | Preis |
|---|---|---|---|
| AI-Readiness-Scan | Bestandsaufnahme von Modell, GPU-Ausstattung, Lastprofil und Datenwegen | 1 Tag | 990 EUR einmalig |
| Onboarding bis Go-live | GPU-Landing-Zone, vLLM-Setup, LiteLLM-Gateway, alles als Code im Repository | 6 bis 10 Wochen | 35.000 bis 60.000 EUR einmalig |
| Hypercare | enge Begleitung nach dem Go-live, Lastprofil und Skalierregeln werden nachgeschärft | 30 Tage | im Onboarding enthalten |
| Dauerbetrieb | Modell-Updates, GPU-Schicht, Kapazität und monatlicher Kostenbericht | monatlich | 5.000 bis 10.000 EUR im Monat |
| Rechenleistung | GPU-Kapazität kauft ihr direkt bei eurem Anbieter | laufend | nicht über Pexon abgerechnet |
Verwandte Inhalte zu vLLM und LiteLLM
Fachartikel zur Inferenz
Die Engine-Seite, der Gateway-Pfad und der Cluster darunter. Hier der Betrieb, dort die Anleitung.
Häufige Fragen zum vLLM-Betrieb auf Kubernetes
Was gehört zum Betrieb einer vLLM-Inferenz auf Kubernetes?
Wie skaliert man GPU-Kapazität für Inferenz?
Was kostet vLLM im Produktivbetrieb auf dem eigenen Cluster?
Wozu ein LiteLLM-Gateway, wenn vLLM schon eine OpenAI-kompatible API hat?
Wo hört euer Inferenz-Betrieb auf?
Wie läuft ein Modell-Update ohne Ausfall der Inferenz-Schnittstelle?
Nachricht senden
Kein passender Termin? Schreibt uns, wir melden uns werktags innerhalb von 24 Stunden.
Sie suchen einen Partner für Ihr Projekt?
Wir analysieren Ihren individuellen Bedarf, geben erste Empfehlungen zu Umsetzungsstrategien und bieten Ihnen transparente Einblicke in unsere Methoden, Technologien und Referenzen.
Vertrieb kontaktieren