GPU unter der Haube: CDI, Sharing und DRA

TL;DR

GPUs in Containern und Kubernetes funktionieren — aber effizientes Teilen und Zuweisen braucht Verständnis unter der Haube. Drei Schichten: CDI macht komplexe Geräte in Containern verfügbar, Sharing (Time-Slicing, MPS, MIG) bestimmt Auslastung vs. Isolation, DRA ersetzt starre Device-Plugins durch flexible Ressourcen-Claims. Ab Kubernetes 1.32 deckt DRA fast alle GPU-Use-Cases ab.

Das Treiber-Problem in Containern

Früher: GPU kaufen, Treiber installieren, App verlinken. Mit Containern muss der NVIDIA-Treiber (Kernel + User-Space) exakt zur Host-Version passen — schon ein Patch-Unterschied bricht den Container.

Die Lösung ist Runtime-Injection: Host-Treiber-Bibliotheken werden zur Laufzeit eingehängt, statt sie im Image zu bündeln. So bleiben Images über Maschinen mit verschiedenen Treiber-Versionen portabel.

CDI — der moderne Standard

CDI (Container Device Interface) ist der CNCF-Standard für komplexe Geräte in Containern. Die Spec definiert deklarativ Device-Nodes, Library-Mounts, Sockets, Env-Vars und Hooks. Hersteller (NVIDIA, Intel) erzeugen CDI-Specs; CDI-fähige Runtimes machen Geräte verfügbar.

Syntax-Beispiel: nvidia.com/gpu=<name> — ab Docker 25 direkt nutzbar. nvidia-ctk generiert Specs; Runtimes konsumieren sie. Das alte NVIDIA-Docker-Modell wird damit abgelöst.

Auf Kubernetes-Ebene kommen zwei Komponenten dazu:

Der GPU Operator erkennt GPU-Nodes, installiert den Software-Stack und bewirbt Ressourcen — ohne manuelles Infra-Basteln pro Node.

Drei Sharing-Strategien

Wichtig: Time-Slicing begrenzt den Speicher zwischen CUDA-Kontexten nicht — ein Prozess kann den VRAM fressen. MPS und MIG setzen Grenzen. Praxis-Einstieg zum Teilen: GPUs in Kubernetes.

Grenzen des Device-Plugin-Modells

nvidia.com/gpu: 2 wirkt simpel — und stößt schnell an Grenzen:

• kein Multi-GPU-Typ pro Node
• keine komplexen Constraints („mindestens 80 GB")
• keine Kontrolle über Oversubscription
• keine dynamische MIG-Provisionierung
• kein PCIe-Alignment (GPU + NIC auf demselben Pfad)

DRA: die flexible Zukunft

Dynamic Resource Allocation orientiert sich am Persistent-Volume-API: Device-Class + Resource-Claim statt flachem Zählen. Unter der Haube nutzt DRA CDI für die Geräte-Injektion.

Bausteine:

• Resource-Slice: Nodes bewerben reiche Objekte (z. B. „GH200, 90 GB") statt flacher Strings
• Device-Class: CEL-Expression, welche Geräte aus welchem Driver kommen
• Resource-Claim: Anfrage mit Constraints
• Scheduler: bindet passende Geräte

Damit werden möglich: kontrolliertes Sharing, GPU-Auswahl nach Memory, mehrere GPU-Typen pro Node, dynamisches Time-Slicing/MPS, PCIe-Alignment für schnelle Kommunikation — kritisch für verteiltes Training und Inference.

Reifegrad (Orientierung aus dem Talk): Kubernetes 1.30 deckte 6/12 GPU-Use-Cases, 1.31 etwa 8/12, 1.32 zielt auf 11/12.

Die ehrliche Einordnung:

1. CDI ist Pflichtwissen — ohne saubere Geräte-Injektion keine portablen GPU-Container.
2. Sharing-Strategie folgt dem Workload — Batch ≠ Latenz ≠ Isolation.
3. Device-Plugins reichen für einfache Fälle — bei Constraints und Multi-Tenant stößt man an.
4. DRA reift schnell — Upgrades und Driver-Reife mitplanen.
5. PCIe/NUMA sind keine Details — falsche Topologie kostet Throughput; siehe auch KubeVirt und Multi-Tenant-GPUs.

Häufige Fragen

CDI oder NVIDIA-Docker?

CDI ist der Standardweg. NVIDIA-Docker ist Legacy; neue Setups sollten CDI nutzen.

Time-Slicing oder MIG?

Time-Slicing für Batch und einfache Dichte. MIG, wenn Isolation und Memory-Garantien Pflicht sind.

Brauche ich DRA sofort?

Für einfache nvidia.com/gpu: 1-Deployments nein. Sobald Sie Constraints, Sharing-Policies oder PCIe-Alignment brauchen: ja — und mit AI at Scale zusammen planen.

Fazit

GPU-Management wandert von „statisch und rigide" zu „dynamisch und flexibel" — über CDI und DRA. Wer die drei Sharing-Strategien und die Device-Plugin-Grenzen kennt, trifft bessere Kosten- und Performance-Entscheidungen.

Einstieg über GPUs in Kubernetes, Vertiefung über LLM Self-Hosting. Wir beraten die passende Sharing- und DRA-Strategie und betreiben den GPU-Stack produktionsreif.