GPUs in Kubernetes: AI-ready ohne Bankrott

TL;DR

AI-Modelle laufen auf GPUs — und Kubernetes verwaltet sie. Der Unterschied zu klassischen Workloads: Es geht nicht um CPU und Memory, sondern um Anzahl und Art der GPUs, exklusiv oder geteilt. Drei Schritte machen einen Cluster AI-ready: GPU-Node-Pool, Device-Plugins, Pods mit nvidia.com/gpu und Tolerations. Der Kostenhebel ist Partitionierung — mehrere Modelle auf einer teuren GPU statt eine GPU pro Modell.

Drei Schritte zur AI-Readiness

1. GPU-Node-Pool anlegen

Ein normaler Cluster hat zunächst keine GPU-Nodes. Sie legen einen Node-Pool mit Accelerator an — etwa NVIDIA A100, L40S oder was der Cloud-Provider anbietet. Jeder Provider hat eigene Accelerator-Typen; die Verfügbarkeit vorher prüfen.

2. Device-Plugins

Ohne Device-Plugin sind GPU-Nodes nutzlos — Pods bekommen keinen Zugriff auf die Hardware. Bei Managed Kubernetes (GKE, AKS, EKS) werden Plugins meist automatisch mit dem GPU-Pool installiert. Bei Eigenbetrieb muss der Stack manuell (oder per GPU Operator) aufgesetzt werden.

3. Pods die GPU zuweisen

Drei Manifest-Elemente entscheiden:

resources:
  limits:
    nvidia.com/gpu: "1"
tolerations:
  - key: nvidia.com/gpu
    operator: Exists
env:
  - name: NVIDIA_DRIVER_CAPABILITIES
    value: compute,utility

GPU-Nodes tragen typischerweise einen NoSchedule-Taint. Nur Pods mit passender Toleration landen dort — CPU-Workloads bleiben von teuren Nodes fern.

Das Praxisproblem: Das zweite Modell bleibt pending

Ein Ollama- oder vLLM-Deployment mit einer GPU läuft schnell. Das zweite Modell mit derselben Anforderung bleibt pending: „no available GPUs". Der Node hat nur eine GPU, beide Pods verlangen je eine.

Zwei Auswege:

Partitionierung: der Kosten-Booster

Statt für jedes Modell eine eigene GPU zu kaufen, teilen Sie eine GPU in kleinere Einheiten — z. B. 1G.5GB (1/7 der Streaming-Multiprozessoren + 5 GB Memory). Eine A100 kann so in bis zu sieben Partitionen zerlegt werden: sieben Pods bzw. Modelle auf einer Karte.

Die ehrliche Warnung aus der Praxis: Partitionierungs-Größen sind provider- und GPU-spezifisch. Nicht auf Intuition verlassen — die Dokumentation des Providers lesen. Vertiefung zu MIG und Hardware-Sharing: GPU in Containern — CDI und DRA.

Weitere Kostenhebel

• Serverless (z. B. Knative): unbenutzte Modell-Pods auf 0 skalieren, bei Bedarf hochfahren
• Right-Sizing: genau die nötige Partition wählen, nicht „volle GPU aus Gewohnheit"
• Taints durchsetzen: sonst landen Web-Pods auf GPU-Nodes und verbrennen Budget

Die ehrliche Einordnung:

1. GPU-Mangel ist real — ohne Sharing blockiert das zweite Modell.
2. Partitionierung ist provider-spezifisch — keine Universalformel.
3. Taints/Tolerations nicht vergessen — sonst falsche Placement-Kosten.
4. Leerlauf ist teuer — Scaling und Monitoring einplanen.
5. VRAM prüfen — nicht jedes Modell passt auf eine Partition; siehe VRAM-Rechner.

Häufige Fragen

Was ist ein Device-Plugin?

Es gibt Pods Zugriff auf Spezial-Hardware (GPUs). Bei Managed Kubernetes meist automatisch mit dem GPU-Pool.

Warum bleibt mein zweites Modell pending?

Weil nur eine volle GPU verfügbar ist und beide Pods je eine verlangen. Lösung: zweite Node oder Partitionierung.

Reicht das für Produktion?

Für den Einstieg ja. Für flexible Constraints, Multi-GPU-Typen und PCIe-Alignment brauchen Sie CDI und DRA.

Fazit

GPU-Management in Kubernetes ist der Hebel für bezahlbare AI im Betrieb: Nodes richtig anlegen, Plugins nutzen, Placement steuern — und teilen statt kaufen. Wer weiter skalieren will, kombiniert das mit AI at Scale (DRA, Inference Gateway) und der richtigen GPU-Server-Familie.

Wir beraten die passende GPU- und Partitionierungs-Strategie und betreiben den Cluster mit Auslastungs-Monitoring und Kostenkontrolle.