Fortgeschrittene GPU-Strategien für effiziente KI-Cluster

Wer heute eine NVIDIA H100 oder A100 in seinen Cluster integriert, stellt schnell fest: Die klassische 1-zu-1-Zuweisung (ein Pod reserviert eine ganze GPU) ist im produktiven Alltag oft eine massive Kapitalverschwendung. Während das Training von LLMs die Hardware voll ausreizt, langweilen sich GPUs beim Inferenz-Betrieb oder in Entwicklungs-Umgebungen oft bei 10 % Auslastung.

Um die TCO (Total Cost of Ownership) Ihrer KI-Infrastruktur zu senken, müssen wir uns von der einfachen Zuweisung verabschieden und tief in das Resource-Management eintauchen.

1. Fractional GPUs: Drei Wege zur Hardware-Teilung

Damit sich mehrere Pods eine physische GPU teilen können, ohne sich gegenseitig in die Quere zu kommen, gibt es heute drei etablierte technische Ansätze:

A. NVIDIA Multi-Instance GPU (MIG) – Die harte Trennung

MIG erlaubt es, eine GPU auf Hardware-Ebene in bis zu sieben unabhängige Instanzen zu unterteilen.

• Vorteil: Jede Instanz hat eigenen dedizierten Speicher und Cache. Ein Absturz in Instanz A beeinflusst Instanz B nicht.
• Einsatz: Ideal für Multi-Tenant-Umgebungen im Mittelstand, wo verschiedene Abteilungen garantierte Performance benötigen.

B. Time-Slicing – Der pragmatische Ansatz

Hierbei nutzt Kubernetes den klassischen Scheduler-Ansatz: Mehrere Prozesse nutzen die GPU nacheinander in extrem kurzen Zeitintervallen.

• Vorteil: Funktioniert auch mit älteren oder kleineren GPUs (z. B. T4 oder L40S), die kein MIG unterstützen.
• Einsatz: Perfekt für Entwicklungs-Cluster oder einfache Inferenz-Workloads (z. B. Bildklassifizierung), die keine harten Latenz-Garantien brauchen.

C. GPU Oversubscription mit CUDA MPS

Multi-Process Service (MPS) erlaubt es, dass mehrere Prozesse gleichzeitig Kernel auf der GPU ausführen.

• Vorteil: Höhere Durchsatzraten als beim Time-Slicing, da die Recheneinheiten besser ausgelastet werden.
• Nachteil: Geringere Isolation. Ein Speicherfehler eines Pods kann alle anderen Prozesse auf der GPU mitreißen.

2. Der Wechsel zu Dynamic Resource Allocation (DRA)

Ein technisches Nadelöhr in Kubernetes war lange Zeit das Device Plugin Framework. Es behandelte GPUs wie „Zähleinheiten" (Ganzzahlen). Mit der Einführung von Dynamic Resource Allocation (DRA) in neueren K8s-Versionen ändert sich das Spiel fundamental.

DRA ermöglicht es uns, Ressourcen viel flexibler zu definieren. Anstatt nur zu sagen „Ich brauche eine GPU", können wir komplexe Anforderungen stellen: „Ich brauche eine GPU mit mindestens 40GB VRAM und NVLink-Anbindung zum Nachbar-Node". Dies ist die Voraussetzung für moderne AI-Supercluster, in denen die Netzwerklatenz zwischen den GPUs (RDMA/RoCE) genauso wichtig ist wie die Rechenpower selbst.

3. Scheduling-Intelligenz mit Kueue und Karpenter

Hardware-Teilung ist nur die halbe Miete. Die andere Hälfte ist das Queue-Management.

Wenn drei Teams gleichzeitig ein Modell trainieren wollen, aber nur zwei GPUs verfügbar sind, darf der Cluster nicht einfach „Out of Memory" laufen. Wir setzen hier auf Kueue. Es fungiert als Job-Queue-Manager oberhalb von Kubernetes und entscheidet basierend auf Prioritäten und Budgets, welcher Workload wann auf die teure Hardware darf.

In Kombination mit Karpenter (statt des Standard Cluster Autoscalers) können wir zudem sicherstellen, dass wir exakt die Node-Typen nachprovisionieren, die für den spezifischen Job am günstigsten sind – zum Beispiel Spot-Instanzen für unkritische Batch-Jobs.

Fazit: Effizienz ist kein Zufall

KI-Infrastruktur im Mittelstand bedeutet heute: Maximum aus dem Investment herausholen. Wer GPUs nur einfach „durchreicht", zahlt zu viel. Erst durch die Kombination aus Hardware-Partitionierung (MIG), modernem Resource-Scheduling (DRA) und intelligenter Warteschlangen-Verwaltung wird Ihr Cluster zu einer echten KI-Fabrik.

Technical FAQ: Deep Dive GPU-Orchestrierung

Was ist der Unterschied zwischen MIG und vGPU? NVIDIA vGPU ist eine softwarebasierte Lösung, die oft in Virtualisierungsumgebungen (VDI) genutzt wird und Lizenzen pro Nutzer erfordert. MIG ist eine Hardware-Funktion neuerer Tensor-Core-GPUs (Ampere-Architektur und neuer), die direkt im Chip partitioniert und keine zusätzlichen Lizenzgebühren innerhalb von Kubernetes verursacht.

Wann sollte ich auf GPU-Sharing verzichten? Beim Large-Model-Training (z.B. Fine-Tuning eines Llama-3-70B). Hier benötigen Sie die volle Speicherbandbreite und den gesamten VRAM einer oder mehrerer GPUs. Jede Teilung würde hier den Prozess massiv ausbremsen oder zum Absturz führen.

Wie überwache ich die tatsächliche GPU-Auslastung? Verlassen Sie sich nicht auf die Standard-K8s-Metriken. Sie benötigen den NVIDIA DCGM Exporter, der Metriken wie „GPU Utilization", „FB Memory Usage" und sogar die Temperatur direkt in Ihr Prometheus/VictoriaMetrics-Setup liefert.

Wird Ihre GPU-Hardware optimal ausgenutzt? Die Architektur entscheidet über Ihre Cloud-Rechnung. Wir bei ayedo analysieren Ihre Workloads und implementieren die passenden Sharing- und Scheduling-Strategien, um Ihre Performance zu maximieren und Kosten zu minimieren.