KI auf Kubernetes betreiben: 7 Lehren aus der Praxis

Gastbeitrag aus der Praxis: Dieser Artikel stammt von Pexon Consulting, dem Betreiber dieser Seite und selbst Kubernetes-Dienstleister. Er beschreibt eigene Projekte und Erfahrungen und ist nicht Teil unserer neutralen Vergleiche.

TL;DR

KI auf Kubernetes funktioniert im Mittelstand, wenn drei Dinge sitzen: ein sauberer GPU-Unterbau mit NVIDIA GPU Operator, vLLM als Inferenz-Server mit Modell-Cache und LiteLLM als Gateway für Budgets und Audit. Wir bei Pexon sehen die Kosten vor allem in ungenutzten GPU-Stunden, nicht im Chip. Sizing, Quantisierung und Sharing entscheiden über die Monatsrechnung.

Welcher Stack hat sich für KI auf Kubernetes bewährt?

Unser Standard-Stack besteht aus vier Schichten: NVIDIA GPU Operator für Treiber und Device Plugin, vLLM als Inferenz-Server, LiteLLM als OpenAI-kompatibles Gateway mit Keys und Quoten und GitOps für jede Änderung. Dazu kommen Autoscaling der GPU-Nodes und Monitoring über DCGM. Proprietäre Zwischenschichten lassen wir bewusst weg.

Dieser Beitrag ist ein gekennzeichneter Praxisbericht von Pexon Consulting, dem Betreiber dieser Seite. Wir beschreiben, wie wir KI-Workloads auf Kubernetes für Kunden aufbauen und betreiben, mit den Zahlen, die wir auf pexon-consulting.de veröffentlicht haben.

Der Stack im Überblick:

Schicht	Komponente	Aufgabe
GPU-Unterbau	NVIDIA GPU Operator	Treiber, Container Toolkit, Device Plugin, DCGM Exporter, MIG Manager
Skalierung	Karpenter oder Cluster Autoscaler	GPU-Nodes nach Bedarf statt nach Spitzenlast
Inferenz	vLLM (optional unter KServe)	OpenAI-kompatible Endpunkte für offene Modelle
Gateway	LiteLLM mit PostgreSQL und Redis	Virtual Keys, Budgets pro Team, Request-Logs
Betrieb	GitOps	Jede Änderung als Commit, Audit-Trail inklusive
Pipelines (optional)	Kubeflow, Model Registry	Datenpipelines und Versionierung

Warum offene Komponenten? Weil das Cluster und die Region beim Kunden bleiben und keine US-API zwingend im Datenpfad liegt. Welche Managed-Kubernetes-Angebote dafür in deutschen Rechenzentren laufen, zeigt der Vergleich Managed Kubernetes Deutschland. Was wir ausdrücklich nicht machen: Modelltraining, Fine-Tuning, Data-Science-Beratung und Anwendungsentwicklung. Wir betreiben die Plattform, nicht die Modelle.

Wie rechnen wir GPU-Sizing und Monatskosten?

Die Faustregel: Ein Modell braucht in FP16 etwa zwei Byte VRAM pro Parameter, plus Reserve für KV-Cache. Ein 7B-Modell passt auf eine L4 mit 24 GB, ein 70B-Modell braucht in FP16 rund 140 GB. Quantisierung schiebt das Modell eine GPU-Klasse nach unten. Das ist der größte Kostenhebel, den wir kennen.

Die folgende Tabelle stammt aus unserer Sizing-Rechnung vom August 2026. Grundlage sind On-Demand-Listenpreise in USD, Stichtag 28.08.2026, 730 Stunden pro Monat, umgerechnet mit rund 0,92 € pro USD, netto, ohne Rabatte. Die Stundenpreise haben wir aus einer Preisübersicht eines Drittanbieters übernommen; prüfen Sie für Ihre Region immer die Preisliste des Hyperscalers.

Modellklasse	VRAM (FP16)	GPU-Beispiel	ca. pro GPU-Stunde	ca. pro Monat (730 h)
7B Chat/RAG	14 bis 16 GB	1x L4 24 GB (GCP)	0,70 USD	ca. 470 €
13B FP16	26 bis 28 GB	1x A100 40 GB (GCP)	3,67 USD	ca. 2.470 €
70B quantisiert (INT4)	35 bis 40 GB	1x A100 80 GB (GCP)	5,03 USD	ca. 3.380 €
70B FP16	ca. 140 GB	H100 (AWS)	6,88 USD	ca. 4.620 €

Die Rechnung ist simpel: Stundenpreis mal 730 mal Wechselkurs. Beispiel L4: 0,70 USD x 730 h = 511 USD, also rund 470 € im Monat. Das Muster dahinter ist wichtiger als die Einzelwerte. Eine GPU, die 24/7 läuft, kostet auch dann, wenn nachts niemand fragt. Deshalb trennen wir GPU-Node-Pools per Taints und Tolerations und skalieren nach Bedarf. Wie die Control-Plane- und Node-Preise der Anbieter ohne GPU aussehen, steht im Managed-Kubernetes-Kostenvergleich.

Unsere ehrliche Einschätzung: Bei niedrigem oder sehr sprunghaftem Volumen ist eine API günstiger als eigene GPUs. Self-Hosting lohnt sich bei hoher, planbarer Last, wenn mehrere Teams sich einen vLLM-Pool teilen oder wenn Daten das eigene Cluster nicht verlassen dürfen.

MIG, Time-Slicing oder DRA: Wie teilen wir GPUs?

Für Produktion mit mehreren Teams nutzen wir MIG, weil es Speicher und Rechenleistung hart trennt. Time-Slicing setzen wir nur für Entwicklung und Tests ein, denn dort gibt es keine Speicher-Isolation. DRA ist seit Kubernetes v1.35 stabil, der NVIDIA-DRA-Pfad braucht aber bewusstes Versions-Management.

Verfahren	Einsatz bei uns	Isolation
Time-Slicing	Entwicklung, Tests	keine Speicher-Isolation, Absturz trifft Nachbarn
MIG	Produktion, mehrere Teams	Speicher und Compute getrennt, nur Datacenter-GPUs ab Ampere
MPS	viele kleine Prozesse	kein harter Schutz
DRA	nur mit bewusstem Versions-Management	ResourceClaims statt nvidia.com/gpu

MIG setzt laut NVIDIA-Dokumentation GPUs ab der Ampere-Architektur voraus, etwa die A100. Der MIG Manager verlangt, dass auf den betroffenen GPUs keine Workloads laufen; manche Profilwechsel brauchen einen Reboot. So installieren wir den GPU Operator (Version gepinnt, nie latest) und schalten eine MIG-Geometrie per Node-Label:

helm repo add nvidia https://helm.ngc.nvidia.com/nvidia && helm repo update
helm install --wait gpu-operator -n gpu-operator --create-namespace nvidia/gpu-operator --version=v26.7.1
kubectl label nodes gpu-node-1 nvidia.com/mig.config=all-1g.10gb --overwrite

Danach prüfen wir das Label nvidia.com/mig.config.state, das auf success wechseln muss. Zu DRA: Die Kubernetes-Dokumentation führt Dynamic Resource Allocation seit v1.35 als stabil mit der API resource.k8s.io/v1. Im GPU Operator schließen sich klassischer Device-Plugin-Pfad (ClusterPolicy) und DRA-Pfad aber gegenseitig aus. Beides in einem Cluster zu mischen führt dazu, dass nichts mehr zugewiesen wird. Für die meisten Mittelstands-Cluster bleiben wir deshalb beim klassischen Pfad.

Was geht beim ersten vLLM-Rollout schief?

Fast immer dieselben vier Punkte: zu wenig Shared Memory für Tensor Parallelism, kein persistenter Modell-Cache, zu knappe Probes beim Start und ein --tensor-parallel-size, der nicht zur GPU-Zahl im Pod passt. Keiner davon ist exotisch, aber jeder kostet im ersten Rollout Stunden, bis die Ursache klar ist.

Die vLLM-Dokumentation sagt es direkt: vLLM braucht Zugriff auf Shared Memory des Hosts für Tensor-Parallel-Inferenz. Ohne Volume auf /dev/shm bricht die Kommunikation zwischen GPUs ab. Ohne Persistent Volume für die Gewichte lädt jeder Neustart das Modell neu, was bei uns 5 bis 10 Minuten pro Restart kostet. Und wenn die Probes den Ladevorgang nicht abwarten, beendet Kubernetes den Container, bevor das Modell bereit ist. Das folgende Manifest folgt dem Beispiel aus der vLLM-Doku, ergänzt um eine Startup-Probe:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: mistral-7b
spec:
  replicas: 1
  selector:
    matchLabels:
      app: mistral-7b
  template:
    metadata:
      labels:
        app: mistral-7b
    spec:
      volumes:
      - name: cache-volume
        persistentVolumeClaim:
          claimName: mistral-7b
      - name: shm
        emptyDir:
          medium: Memory
          sizeLimit: "2Gi"
      containers:
      - name: mistral-7b
        image: vllm/vllm-openai:latest
        command: ["/bin/sh", "-c"]
        args: ["vllm serve mistralai/Mistral-7B-Instruct-v0.3 --gpu-memory-utilization 0.90"]
        ports:
        - containerPort: 8000
        resources:
          limits:
            nvidia.com/gpu: "1"
        volumeMounts:
        - mountPath: /root/.cache/huggingface
          name: cache-volume
        - name: shm
          mountPath: /dev/shm
        startupProbe:
          httpGet:
            path: /health
            port: 8000
          periodSeconds: 10
          failureThreshold: 60
        readinessProbe:
          httpGet:
            path: /health
            port: 8000
          periodSeconds: 5

Zwei Anmerkungen aus dem Betrieb. Erstens: In Produktion pinnen wir das Image auf eine feste Version statt latest. Zweitens: --gpu-memory-utilization steht laut vLLM Engine Arguments per Default auf 0,92. Wir senken den Wert, wenn Sidecars oder andere Prozesse auf derselben GPU Speicher brauchen. Für Multi-GPU-Modelle mit 4 GPUs pro Pod setzen wir mehr Shared Memory an; in unserem vLLM-Leitfaden empfehlen wir dafür mindestens 32 GB. Ab mehreren Modellen und Scale-to-Zero setzen wir KServe als Schicht über vLLM, statt jedes Manifest selbst zu bauen.

Warum gehört ein Gateway vor jedes Modell?

Weil sonst Provider-Keys in CI-Pipelines, Notebooks und privaten Repos landen und niemand sagen kann, welches Team welche Tokens verbraucht hat. LiteLLM gibt jedem Team einen Virtual Key mit Modell-Freigabe, Rate Limit und Budget. Die echten Provider-Secrets sieht keine Anwendung mehr.

Die typische Lücke zwischen Demo und Produktion: Der Proof of Concept läuft, aber Budgets, Key-Owner und ein exportierbarer Audit-Trail fehlen. Virtual Keys brauchen laut LiteLLM-Dokumentation eine PostgreSQL-Datenbank über DATABASE_URL und einen Master Key, der mit sk- beginnt. Ohne persistentes Postgres überleben Keys und Spend keinen Pod-Neustart. So legen wir einen Team-Key mit Budget an:

curl 'http://0.0.0.0:4000/key/generate' -H 'Authorization: Bearer <your-master-key>' -H 'Content-Type: application/json' -d '{"models": ["mistral-7b"], "max_budget": 100, "budget_duration": "10d"}'

Der Spend wird pro Key automatisch erfasst und ist über /key/info und /team/info abrufbar. Das Gateway ersetzt kein SIEM, liefert aber die LLM-spezifischen Nachweise, die eine Provider-Rechnung nicht hergibt: Zeitstempel, Modell, Tokens, Key-Owner, Team und Status. Den Zugang beschränken wir auf Firmennetz oder VPN, nie öffentlich.

Was kostet KI auf Kubernetes mit Pexon und wie lange dauert es?

Wir arbeiten in drei Modulen: AI-Readiness-Scan für 990 €, Aufbau für 35.000 bis 60.000 € einmalig und Betrieb für 5.000 bis 10.000 € im Monat. GPU- und Compute-Kosten zahlen Sie direkt an Ihren Cloud-Anbieter, ohne Aufschlag von uns. Vom Scan bis Go-live rechnen wir mit 6 bis 10 Wochen.

Alle Preise stammen von unserer Seite KI-Plattform-Betrieb, Stand 28.09.2026, netto. Der Ablauf:

1. Tag 1, AI-Readiness-Scan: Clusteranalyse, 5-seitiger Bericht, Abschlussgespräch. Hier klären wir, ob dauerhaft laufende GPU-Nodes überhaupt gerechtfertigt sind.
2. Woche 1 bis 2: Assessment und Zielarchitektur, Node-Pool-Design für GPUs.
3. Woche 2 bis 5: Landing Zone und GitOps-Setup, GPU Operator mit gepinnten Versionen.
4. Woche 5 bis 8: vLLM und LiteLLM produktiv, Budgets und Keys pro Team.
5. Ab Woche 8: 30 Tage Hypercare, danach Betrieb Montag bis Freitag, 08:00 bis 18:00 Uhr MEZ.

Ein Beispiel, das wir veröffentlichen dürfen, allerdings anonymisiert: Ein SaaS-Anbieter aus dem DACH-Raum betreibt seine KI-Plattform seit 12 Monaten mit uns für 6.000 € im Monat, ohne eigenes internes Plattform-Team. Das trägt, weil ein Senior Engineer bei uns über GitOps 30 bis 50 Cluster betreut.

Unser zweiter Schwerpunkt neben KI auf Kubernetes ist Managed Kubernetes in Bankenqualität: Nachweise für DORA und NIS2 aus dem laufenden Betrieb, also Konfigurationsberichte gegen CIS Benchmark, Change-Historie, Zugriffslogs und Protokolle von Recovery-Übungen. Ein Beispiel ist eine Genossenschaftsbank auf Azure AKS mit einem Projektvolumen von 102.700 €. Details stehen auf unserer Seite zu Kubernetes Compliance. Für KI-Plattformen ist das relevant, weil der GitOps-Trail derselbe Nachweis ist, den Prüfer bei regulierten Kunden sehen wollen.

Die 7 Lehren im Überblick

Zusammengefasst: Kosten entstehen durch Leerlauf, Stabilität durch gepinnte Versionen und Isolation durch MIG statt Time-Slicing. Ohne Gateway gibt es keine Kostenkontrolle, ohne Modell-Cache keine schnellen Neustarts. Und nicht jedes Unternehmen braucht eigene GPUs. Diese sieben Punkte prüfen wir in jedem Projekt zuerst.

1. Leerlauf ist der Kostentreiber. GPU-Pools nach Bedarf skalieren, nicht nach Spitzenlast.
2. Quantisierung vor Hardware. Eine Klasse kleinere GPU spart mehr als jede Rabattverhandlung.
3. Nie latest. Chart, Treiber und Images in Git pinnen, sonst laufen nach einer Node-Rotation unterschiedliche Treiber.
4. MIG für Produktion. Time-Slicing nur in Dev, weil ein Absturz Nachbar-Workloads trifft.
5. Modell-Cache und Probes zuerst. Persistent Volume, Shared Memory und großzügige Startup-Probe gehören ins erste Manifest.
6. Ein Gateway, viele Teams. Virtual Keys mit Budget statt geteilter Provider-Secrets.
7. Monitoring über DCGM. Temperatur, XID-Fehler und Auslastung alarmieren, sonst fliegt man blind.

FAQ

Was kostet es, KI auf Kubernetes von Pexon betreiben zu lassen?

Der AI-Readiness-Scan kostet 990 €, der Aufbau 35.000 bis 60.000 € einmalig und der laufende Betrieb 5.000 bis 10.000 € im Monat, jeweils netto, Stand 28.09.2026. Hardware und Compute rechnet der Cloud-Anbieter direkt mit Ihnen ab, ohne Aufschlag.

MIG vs. Time-Slicing: Was ist für Produktion besser?

MIG, sobald mehrere Teams oder Mandanten eine GPU teilen. MIG trennt Speicher und Rechenleistung hart, setzt aber Datacenter-GPUs ab Ampere voraus. Time-Slicing hat keine Speicher-Isolation, ein Absturz trifft die Nachbarn. Für Entwicklung und Tests reicht es.

Wie viel GPU braucht ein 70B-Modell?

In FP16 rund 140 GB VRAM, also zwei A100 mit 80 GB oder mehr. Quantisiert auf INT4 sinkt der Bedarf auf etwa 35 bis 40 GB, dann reicht eine A100 mit 80 GB. Für gute Latenz rechnen wir bei 70B mit etwa vier modernen GPUs.

Brauche ich Dynamic Resource Allocation für GPUs?

Meist noch nicht. DRA ist seit Kubernetes v1.35 stabil, im NVIDIA GPU Operator schließen sich DRA-Pfad und klassisches Device Plugin aber aus, und Teile wie dynamisches MIG über DRA sind noch Alpha. Für die meisten Cluster bleiben wir beim Device Plugin.

Wann lohnt sich Self-Hosting gegenüber einer LLM-API?

Bei hoher, planbarer Last, wenn mehrere Teams sich einen vLLM-Pool teilen oder Daten das eigene Cluster nicht verlassen dürfen. Bei geringem oder sprunghaftem Volumen ist eine API günstiger, weil eine 24/7 laufende GPU auch im Leerlauf kostet.

Wie lange dauert der Aufbau einer KI-Plattform auf Kubernetes?

Vom Scan bis Go-live rechnen wir mit 6 bis 10 Wochen: zwei Wochen Architektur, drei Wochen Landing Zone und GitOps, drei Wochen vLLM und LiteLLM, danach 30 Tage Hypercare.

Quellen

1. Pexon: KI-Workloads auf Kubernetes betreiben (abgerufen 28. September 2026)
2. Pexon: GPU-Cluster auf Kubernetes (abgerufen 28. September 2026)
3. Pexon: Kubernetes für AI/ML und GPU-Workloads (abgerufen 28. September 2026)
4. Pexon Blog: vLLM auf Kubernetes deployen (abgerufen 28. September 2026)
5. Pexon Blog: GPU Operator, MIG und DRA (abgerufen 28. September 2026)
6. Pexon Blog: GPU-Sizing und Monatsrechnung (abgerufen 28. September 2026)
7. Pexon Blog: LiteLLM als Gateway für Budgets und Audit (abgerufen 28. September 2026)
8. Pexon: Kubernetes Compliance (abgerufen 28. September 2026)
9. vLLM Docs: Deployment auf Kubernetes (abgerufen 28. September 2026)
10. vLLM Docs: Engine Arguments (abgerufen 28. September 2026)
11. NVIDIA GPU Operator: Getting Started (abgerufen 28. September 2026)
12. NVIDIA GPU Operator: MIG Support (abgerufen 28. September 2026)
13. Kubernetes Docs: Dynamic Resource Allocation (abgerufen 28. September 2026)
14. LiteLLM Docs: Virtual Keys (abgerufen 28. September 2026)