GPUs zwischen Teams teilen: MIG, Time-Slicing, Quotas

Device Plugins, GPU Operator, MIG und Time-Slicing: der vollständige Leitfaden

Die GPU-Verwaltung in Kubernetes ist eine grosse technische Herausforderung für Organisationen, die KI-Workloads im grossen Massstab betreiben. Laut Collabnix führen 48 % der Organisationen ihre AI/ML-Workloads inzwischen auf Kubernetes aus, bei einem Anstieg der Suchanfragen zu «Kubernetes AI» um 300 % im Jahr 2025. Diese Verbreitung setzt Infrastrukturteams unter Druck: Wie orchestriert man GPU-Ressourcen, die 2 bis 10 CHF pro Stunde kosten, und maximiert dabei die Auslastung bei garantierter Isolation zwischen Tenants?

Kubernetes behandelt GPUs nicht von Haus aus als erstklassige Ressourcen. Der Standard-Scheduler sieht GPUs als binäre Zähler (0 oder 1) und ignoriert ihre Eigenschaften: Modell, VRAM, Netzwerktopologie. Dieser vereinfachte Ansatz erzeugt Verschwendung: Pods, die 10 % einer GPU nutzen und die übrigen 90 % blockieren, heterogene Cluster, in denen H100 Lasten bedienen, für die eine T4 genügen würde. Dieser Beitrag beschreibt die drei kritischen Komponenten der GPU-Verwaltung in Kubernetes, Device Plugin, GPU Operator und spezialisierte Scheduler, stellt die Strategien zum GPU-Sharing dar (MIG, Time-Slicing) und schlägt ein schrittweises, in Produktion erprobtes Vorgehen vor.

Der Blickwinkel dieses Artikels: mehrere Teams auf denselben Karten unterbringen, MIG, Time-Slicing, Quoten und Gang Scheduling. Es geht ums Teilen, nicht um die Kosten: die Kosten je Job stehen in GPU-FinOps.

Die drei Schlüsselkomponenten von Kubernetes-GPU

Die GPU-Orchestrierung in Kubernetes ruht auf drei sich ergänzenden Softwareschichten, die Hardwarebeschleuniger in planbare Ressourcen verwandeln.

Device Plugin, GPUs dem Scheduler sichtbar machen

Das Device-Plugin-Framework ist der Mechanismus, mit dem Kubernetes spezialisierte Hardwareressourcen erkennt und zuteilt. Jedes Device Plugin läuft als DaemonSet auf den GPU-Knoten, kommuniziert über gRPC mit dem Kubelet und stellt Extended Resources bereit, die der Scheduler sieht. Für NVIDIA stellt das offizielle k8s-device-plugin die Ressource nvidia.com/gpu bereit.

Die Architektur ist einfach: Das Device Plugin fragt den NVIDIA-Treiber periodisch nach den auf dem Knoten verfügbaren GPUs und meldet diese Ressourcen dem Kubelet über die ListAndWatch-API. Fordert ein Pod nvidia.com/gpu: 1 an, reserviert das Kubelet eine GPU und konfiguriert die Container-Runtime (containerd oder CRI-O) so, dass das GPU-Device über das NVIDIA Container Toolkit im Container sichtbar wird.

Architektur Device Plugin:

Knoten mit 4× A100 80GB

Device Plugin (DaemonSet)
↓ gRPC ListAndWatch
Kubelet
↓ stellt Ressourcen bereit
Kubernetes-Scheduler
↓ Platzierungsentscheid
Pod mit nvidia.com/gpu, 2
↓ Runtime-Konfiguration
Container mit Zugriff auf 2× GPU

Das Standard-Device-Plugin hat zwei wesentliche Grenzen. Erstens behandelt es alle GPUs als gleichartig: Eine H100 lässt sich nicht gezielt statt einer A100 anfordern, der Scheduler platziert den Pod auf dem ersten Knoten mit freien GPUs, ohne das Modell zu beachten. Zweitens ist die Zuteilung alles oder nichts: Ein Pod, der eine GPU anfordert, erhält exklusiven Vollzugriff, auch wenn er nur 15 % der Kapazität nutzt.

GPU Operator, Automatisierung des Lebenszyklus

Der NVIDIA GPU Operator löst das Problem der Verwaltung des GPU-Software-Stacks auf jedem Knoten. Vor dem GPU Operator mussten Administratoren auf jedem Knoten manuell installieren: NVIDIA-Treiber, NVIDIA Container Toolkit, Device Plugin, DCGM für Monitoring, GPU Feature Discovery für das Labeling. Dieses manuelle Vorgehen erzeugte Versionsinkonsistenzen, Konfigurationsfehler und Deployment-Zeiten von Tagen.

Der GPU Operator setzt das Kubernetes-Operator-Muster um: Eine Custom Resource Definition (ClusterPolicy) beschreibt den gewünschten Zustand des GPU-Clusters, und der Operator führt den Ist-Zustand automatisch dorthin. Beim Deployment installiert der GPU Operator über DaemonSets auf den GPU-Knoten: NVIDIA-Treiber (oder erkennt vorinstallierte Treiber), NVIDIA Container Toolkit, k8s-device-plugin, DCGM Exporter, GPU Feature Discovery, Node Status Exporter.

Installation GPU Operator (Helm):

# NVIDIA-Helm-Repo hinzufügen
helm repo add nvidia https://helm.ngc.nvidia.com/nvidia
helm repo update

# GPU Operator installieren
helm install gpu-operator nvidia/gpu-operator \
 --namespace gpu-operator \
 --create-namespace \
 --version v24.9.0 \
 --set driver.enabled=true

# Deployment prüfen
kubectl get pods -n gpu-operator
kubectl get nodes -o json | jq '.items[].status.allocatable'

GPU Feature Discovery (GFD), eine Komponente des GPU Operators, versieht die Knoten automatisch mit Labels zu ihren GPUs, nvidia.com/gpu.product (Handelsname wie A100-SXM4-80GB), nvidia.com/gpu.memory (VRAM in Bytes), nvidia.com/gpu.count (Anzahl GPUs), nvidia.com/cuda.driver.major und minor (Treiberversion), nvidia.com/gpu.family (Architektur, ampere, hopper). Diese Labels erlauben präzise nodeSelector und Affinitäten in den Pod-Specs.

Spezialisierte Scheduler: über den Standard hinaus

Der Standard-Scheduler von Kubernetes nutzt Prädikate (Filter) und Prioritäten (Scores), um Pods zu platzieren. Bei GPUs werden seine Grenzen kritisch: kein Gang Scheduling (alle Pods eines Multi-GPU-Jobs oder keiner), keine Quoten pro Tenant oder Queue, keine intelligente Preemption nach fachlicher Priorität, Netzwerktopologie (NVLink, InfiniBand) bei der Platzierung ignoriert.

Spezialisierte Scheduler schliessen diese Lücken. Der NVIDIA KAI Scheduler, im Januar 2025 quelloffen gestellt, bringt: fraktionierte GPU-Anforderungen (nvidia.com/gpu, 0.5), natives Gang Scheduling über PodGroups, hierarchische Queues mit Quoten, topologiebewusstes Scheduling für verteilte Lasten und nach Priorität und Fairness konfigurierbare Preemption.

Kueue, von einer Kubernetes-SIG entwickelt, arbeitet als Admission-Control-Schicht vor dem Scheduling, Workloads (Jobs, PyTorchJobs, RayJobs) werden in LocalQueues eingereiht, die an ClusterQueues mit konfigurierten Quoten gebunden sind. Kueue simuliert das Scheduling auf dem Cluster und lässt den Workload atomar zu oder hält ihn zurück. Cohorts erlauben mehreren Queues, ungenutzte Quoten mit gewichteter Fairness zu teilen.

Volcano, ein CNCF-Projekt, setzt striktes Gang Scheduling und optimiertes Bin-Packing um: Alle Pods einer PodGroup werden gleichzeitig geplant oder keiner, was Deadlocks vermeidet. Volcano unterstützt mehrere Scheduling-Algorithmen: proportion (Fair-Share), gang (Atomarität), DRF (Dominant Resource Fairness), binpack (Fragmentierung minimieren).

Strategien für GPU-Sharing, MIG gegen Time-Slicing

Eine GPU zwischen mehreren Pods zu teilen verbessert die Auslastung und senkt die Kosten. Zwei Ansätze dominieren: Multi-Instance GPU (MIG) mit Hardware-Isolation und Time-Slicing in Software.

MIG, Hardware-Isolation durch Partitionierung

Multi-Instance GPU (MIG), eingeführt mit der Ampere-Architektur (A100, A30), partitioniert eine GPU physisch in bis zu sieben unabhängige Instanzen. Jede MIG-Instanz erhält eigene Ressourcen: Streaming Multiprocessors (SM), VRAM, Speichercontroller, L2-Cache. Die Isolation ist in Hardware garantiert: Ein Absturz in einer MIG-Instanz betrifft die anderen nicht, und die Speicherbandbreite wird durch Hardware-QoS garantiert.

Eine A100 80GB unterstützt mehrere MIG-Profile, 1g.10gb (1/7 der GPU, 10 GB VRAM), 2g.20gb (2/7, 20 GB), 3g.40gb (3/7, 40 GB), 7g.80gb (ganze GPU). Eine H100 80GB bietet: 1g.10gb, 2g.20gb, 3g.40gb, 4g.40gb, 7g.80gb. Die Profile bestimmen die möglichen Kombinationen: Eine A100 kann gleichzeitig 7× 1g.10gb tragen oder 2× 3g.40gb plus 1× 1g.10gb, je nach Bedarf.

MIG-Konfiguration in Kubernetes:

# MIG auf der GPU aktivieren (Reboot nötig)
nvidia-smi -i 0 -mig 1

# MIG-Instanzen anlegen (Beispiel: 2× 3g.40gb + 1× 1g.10gb)
nvidia-smi mig -cgi 3g.40gb -C
nvidia-smi mig -cgi 3g.40gb -C
nvidia-smi mig -cgi 1g.10gb -C

# ConfigMap des GPU Operators für MIG
apiVersion: v1
kind: ConfigMap
metadata:
  name: gpu-operator-config
data:
  migStrategy: mixed  # single, mixed oder none

Der Modus mixed stellt sowohl ganze GPUs (nvidia.com/gpu) als auch MIG-Instanzen (nvidia.com/mig-3g.40gb) bereit. Pods können entweder eine ganze GPU oder eine bestimmte MIG-Instanz anfordern. Der Modus single stellt nur MIG-Instanzen bereit und zwingt alle Lasten zu MIG.

Zu den Grenzen von MIG zählen: statische Konfigurationen, deren Änderung einen GPU-Reset verlangt, maximal sieben Instanzen pro GPU als Granularitätsgrenze, Verwaltungsaufwand bei kleinen Clustern (unter 10 GPUs) und die Beschränkung auf Ampere- und Hopper-GPUs (A100, A30, H100, H200).

Time-Slicing, Softwareseitiges Teilen durch Multiplexing

Time-Slicing erlaubt mehreren Containern, eine GPU über CUDA-Time-Slicing zu teilen, Der GPU-Treiber wechselt den Kontext schnell zwischen Prozessen und gibt jedem eine Zeitscheibe. Anders als bei MIG gibt es weder Speicherisolation noch Bandbreitengarantie. Ein Noisy-Neighbour-Pod kann den VRAM erschöpfen und in den anderen Pods derselben GPU CUDA-OOM-Fehler auslösen.

Time-Slicing ist ideal für Entwicklungsumgebungen und interaktive Notebooks, leichte Inferenz (Chatbots, APIs) mit toleranter Latenz, ältere GPUs ohne MIG-Unterstützung (T4, V100, P100) und sehr feingranulares Teilen (16+ Lasten pro GPU). Umgekehrt eignet sich Time-Slicing nicht für Lasten, die planbare und garantierte Leistung, strikte Speicherisolation, sehr niedrige Latenz (unter 50 ms) oder intensives Training mit exklusiver GPU verlangen.

Time-Slicing-Konfiguration (ConfigMap):

apiVersion: v1
kind: ConfigMap
metadata:
  name: device-plugin-config
  namespace: gpu-operator
data:
  A100-SXM4-80GB: |-
    version: v1
    sharing:
      timeSlicing:
        resources:
          - name: nvidia.com/gpu
            replicas: 4  # 1 physische GPU → 4 logische GPUs
  Tesla-T4: |-
    version: v1
    sharing:
      timeSlicing:
        resources:
          - name: nvidia.com/gpu
            replicas: 8  # 1 T4 → 8 Replicas

Nach Anwendung dieser Konfiguration meldet ein Knoten mit 1× A100 80GB nvidia.com/gpu, 4 statt nvidia.com/gpu, 1. Vier Pods können je nvidia.com/gpu: 1 anfordern und gleichzeitig auf derselben physischen GPU laufen. GPU Feature Discovery fügt das Label nvidia.com/gpu.product: A100-SXM4-80GB-SHARED hinzu, um time-sliced GPUs zu unterscheiden.

Schritt für Schritt: ein Kubernetes-GPU-Cluster

Der Aufbau eines GPU-Kubernetes-Clusters für KI-Lasten folgt einer methodischen Abfolge in fünf Schritten, jeder vor dem nächsten validiert.

Schritt 1, Infrastruktur vorbereiten (1-2 Tage)

GPU-Knoten brauchen bestimmte Systemvoraussetzungen. Ein aktueller Linux-Kernel (5.15+) mit aktivierten NVIDIA-Modulen, deaktivierter Secure Boot (unverträglich mit proprietären Treibern), installierte Basispakete: build-essential, gcc, make, linux-headers-$(uname -r). Für Cloud-Deployments (AWS, Azure, GCP) dedizierte GPU-Instanztypen nutzen: AWS p4d.24xlarge (8× A100), Azure NC A100 v4, GCP a2-highgpu-8g.

On-Premise die BIOS-Einstellungen prüfen, IOMMU für GPU-Passthrough aktiviert, PCIe ASPM deaktiviert (kann Instabilität verursachen), Above 4G Decoding aktiviert für GPUs ab 80GB. GPU-Sichtbarkeit über lspci | grep -i nvidia bestätigen. Kompatible Container-Runtime installieren: containerd 1.7+ oder CRI-O 1.28+ mit CDI-Unterstützung (Container Device Interface).

Schritt 2, GPU Operator ausrollen (3-4 Stunden)

Der GPU Operator wird über das offizielle Helm-Chart installiert. Die ClusterPolicy-Konfiguration bestimmt, welche Komponenten ausgerollt werden. Für Produktion aktivieren: NVIDIA-Treiber (ausser sie sind auf den Knoten vorinstalliert), Device Plugin, DCGM Exporter für Monitoring, GPU Feature Discovery, Toolkit und Validierung.

Vollständige Installation des GPU Operators:

# Namespace anlegen
kubectl create namespace gpu-operator

# Über Helm mit Produktionsparametern installieren
helm install gpu-operator nvidia/gpu-operator \
 -n gpu-operator \
 --set driver.enabled=true \
 --set driver.version="550.90.07" \
 --set toolkit.version="1.16.2" \
 --set devicePlugin.version="v0.16.2" \
 --set dcgmExporter.enabled=true \
 --set gfd.enabled=true \
 --set operator.defaultRuntime=containerd

# Validierung
kubectl wait --for=condition=ready pod -l app=gpu-operator -n gpu-operator --timeout=600s
kubectl get nodes -o json | jq '.items[].status.allocatable | select(.["nvidia.com/gpu"] != null)'

Die Validierung bestätigt, dass die Knoten die Ressource nvidia.com/gpu bereitstellen und die GFD-Labels gesetzt sind. Ein einfacher CUDA-Pod prüft die Funktion von Ende zu Ende.

Schritt 3: GPU-Sharing konfigurieren (4-6 Stunden)

Die Sharing-Strategie nach Anwendungsfall festlegen, MIG für Multi-Tenant-Produktion mit SLA, Time-Slicing für Dev/Test und leichte Inferenz, exklusive GPUs für intensives Training. Strategien lassen sich über Node Pools mischen: ein Pool «Produktion» mit MIG, ein Pool «Dev» mit Time-Slicing, ein Pool «Training» mit exklusiven GPUs.

Für MIG die Profile auf jeder GPU konfigurieren und die ClusterPolicy auf die MIG-Strategie umstellen. Für Time-Slicing eine ConfigMap mit Konfigurationen je GPU-Modell anlegen und die ClusterPolicy darauf verweisen lassen. Knoten für die genaue Auswahl labeln: kubectl label nodes gpu-node-1 gpu-sharing=mig, kubectl label nodes gpu-node-2 gpu-sharing=time-sliced.

Schritt 4, Monitoring und Observability (2-3 Stunden)

Der vom GPU Operator ausgerollte DCGM Exporter stellt GPU-Metriken im Prometheus-Format bereit. Kritische Metriken: DCGM_FI_DEV_GPU_UTIL (Auslastung in %), DCGM_FI_DEV_FB_USED und DCGM_FI_DEV_FB_FREE (VRAM), DCGM_FI_DEV_POWER_USAGE (Verbrauch in W), DCGM_FI_DEV_GPU_TEMP (Temperatur), DCGM_FI_DEV_SM_CLOCK (GPU-Takt).

Prometheus so konfigurieren, dass es den DCGM Exporter auf Port 9400 scrapt. Das vorkonfigurierte Grafana-Dashboard importieren (ID 12239): GPU-Auslastung je Knoten, VRAM-Nutzung mit Schwellen, Temperatur und Throttling, gesamte Leistungsaufnahme des Clusters. Alerts definieren: GPU-Auslastung unter 30 % während einer Stunde (Unternutzung), VRAM über 90 % (OOM-Risiko), Temperatur über 85 °C (Throttling steht bevor).

Schritt 5, Quoten und Richtlinien (1-2 Tage)

Kubernetes-ResourceQuotas begrenzen den GPU-Verbrauch je Namespace. Eine typische Quote: requests.nvidia.com/gpu, "8" begrenzt einen Namespace auf 8 gleichzeitige GPUs. LimitRanges definieren Minimum und Maximum je Pod: Pods verhindern, die 0 GPUs oder mehr als 4 anfordern.

Für weitergehende Steuerung Kueue oder Volcano einsetzen. Kueue setzt Queues mit Quoten um: Team A mit 16 GPUs, Team B mit 8, mit einem Cohort, das das Ausleihen ungenutzter Quoten erlaubt. Volcano setzt Prioritäten und Preemption um: Pods hoher Priorität können Pods niedriger Priorität verdrängen, um GPUs freizugeben.

Die fünf Fehler, welche die GPU-Effizienz mindern

1. Node-Labels und Affinity nicht nutzen

Symptom: Pods ohne nodeSelector oder Affinity ausrollen und den Scheduler die Lasten auf beliebigen freien GPU-Knoten platzieren lassen, ohne das Modell zu beachten.

Auswirkung: leichte Inferenzlasten auf teuren H100 (7 CHF/h), obwohl eine T4 (1,20 CHF/h) genügen würde. Modelle ab 70B auf A100-40GB-Knoten geplant, was sofort OOM auslöst, statt A100 80GB anzusteuern. GPU-Fragmentierung: ein Cluster, in dem 50 % der H100 ungenutzt sind, während Jobs auf durchweg belegte A100 warten. Geschätzte Verschwendung: 30 bis 50 % des GPU-Budgets bei heterogenen Clustern.

Lösung: Knoten nach GPU-Modell und Fähigkeiten labeln. nodeSelector für einfache Lasten nutzen: nodeSelector, nvidia.com/gpu.product, Tesla-T4. Node Affinity für komplexe Logik: H100 bevorzugen, A100 akzeptieren, wenn nicht verfügbar. Dedizierte Node Pools anlegen: Pool «inference» mit T4/L40S, Pool «training» mit A100/H100. Über Admission Controller automatisieren, die prüfen, dass jeder GPU-Pod einen passenden nodeSelector angibt.

2. Resource Limits ignorieren

Symptom: nur requests.nvidia.com/gpu ohne Limits definieren, oder umgekehrt.

Auswirkung: Bei GPUs müssen Requests und Limits identisch sein, weil sich eine GPU nicht wie eine CPU durch Throttling teilen lässt. Ein Pod mit requests: 1, limits, 2 erhält eine GPU, reserviert aber zwei Slots, was Verschwendung erzeugt. Ein Pod ohne Limits ist auf GPU-Seite nicht OOM-killable (das Kubelet kann die Freigabe der GPU nicht erzwingen). Namespace-Quoten lassen sich umgehen, wenn nur Requests quotiert sind. Ergebnis: Ressourcenfragmentierung, wirkungslose Quoten, ungenaues Billing.

Lösung: Requests und Limits für GPUs stets identisch setzen, resources, limits, nvidia.com/gpu, "2" requests, nvidia.com/gpu, "2". Über eine LimitRange diese Gleichheit auf Namespace-Ebene erzwingen. Pods mit abweichenden Requests und Limits über eine Policy Engine (OPA, Kyverno) überwachen und automatisch ablehnen. Für fraktionierte GPUs (KAI Scheduler) dasselbe Prinzip mit Bruchwerten anwenden: nvidia.com/gpu, "0.5" bei Requests und Limits.

3. Die Netzwerkkonfiguration für Multi-GPU unterschätzen

Symptom: verteiltes Multi-GPU-/Multi-Node-Training ausrollen, ohne RDMA, GPUDirect oder NVLink-Topologie zu konfigurieren.

Auswirkung: Ein PyTorch-DistributedDataParallel-Training auf 32 GPUs (4 Knoten × 8 GPUs) kommuniziert über Standard-Ethernet (25 Gbps) statt über RDMA InfiniBand (200 Gbps). Die Gradientensynchronisation steigt von 150 ms (InfiniBand) auf 1200 ms (Ethernet) und verfünffacht die Iterationszeit. Über ein Training mit 1000 Epochen summiert sich der Netzwerk-Overhead auf mehrere Tage. Verschwendete GPU-Kosten: 60-70 % der Zeit im Warten auf das Netz. Auf 4 H100-Knoten zu zusammen 56 CHF/h sind das 35 CHF/h, die im Leerlauf am Netz verbrennen.

Lösung: RDMA auf den GPU-Knoten konfigurieren, InfiniBand- oder RoCEv2-Treiber installieren, GPUDirect RDMA im GPU Operator aktivieren (--set rdma.enabled=true). On-Premise ein InfiniBand-HDR-Netz mit mindestens 200 Gbps aufbauen. In der Cloud Instanztypen mit optimiertem Netz nutzen: AWS p4d (400 Gbps EFA), Azure ND A100 v4 (200 Gbps InfiniBand). Topologiebewusstes Scheduling einsetzen (KAI Scheduler, Volcano), um Pods desselben Jobs auf topologisch nahe Knoten zu legen. Die GPU-zu-GPU-Bandbreite vor Produktion mit NCCL-Benchmarks prüfen.

4. MIG und Time-Slicing ohne klare Strategie mischen

Symptom: MIG auf einigen GPUs und Time-Slicing auf anderen im selben Node Pool aktivieren, ohne Dokumentation und ohne klare Labels.

Auswirkung: Verwirrung bei den Nutzenden, Manche Pods fordern nvidia.com/gpu, 1 und erhalten eine ganze GPU, andere eine MIG-Instanz, wieder andere eine Zeitscheibe, je nachdem, welchen Knoten der Scheduler gewählt hat. Unvorhersehbare Leistung: derselbe Pod verhält sich je nach Platzierung anders. Aufwendiges Debugging: Um zu erkennen, welchen GPU-Typ ein Pod erhalten hat, müssen Node-Labels, die Device-Plugin-ConfigMap und die MIG-Konfiguration geprüft werden. Verlorene DevOps-Zeit: 2-3 Stunden je Vorfall.

Lösung: je Node Pool eine klare Strategie festlegen, Pool A exklusive ganze GPUs, Pool B nur MIG, Pool C nur Time-Slicing. Ausdrücklich labeln: gpu-mode, exclusive, gpu-mode, mig, gpu-mode, time-sliced. Nutzende über eine Admission Policy zwingen, den gewünschten GPU-Modus per nodeSelector anzugeben. Im internen Wiki dokumentieren, welcher Pool für welchen Anwendungsfall gilt. Für Fachleute ist ein Mischbetrieb möglich, verlangt aber Sorgfalt: MIG und Zeitscheibe als unterschiedliche Ressourcen bereitstellen (nvidia.com/mig-3g.40gb gegenüber nvidia.com/gpu.shared), nie als mehrdeutiges nvidia.com/gpu.

5. Kein Gang Scheduling für verteiltes Training

Symptom: verteilte Trainingsjobs (PyTorchJob, MPIJob) auf einem Standard-Kubernetes-Cluster ohne Gang Scheduling starten und hoffen, dass alle Pods geplant werden.

Auswirkung: Ein PyTorchJob braucht 16 Pods (16 GPUs). Der Scheduler platziert 12 sofort, 4 bleiben Pending, weil im Cluster nicht genug GPUs frei sind. Die 12 gestarteten Pods warten unbegrenzt auf die fehlenden 4 (DistributedDataParallel blockiert am Rendezvous). Die GPUs dieser 12 Pods liegen bis zum Timeout brach (oft 30-60 Minuten). Bei 3,20 CHF/h pro A100 sind das 38 CHF je fehlgeschlagenem Job. In Produktion scheitern ohne Gang Scheduling 20-40 % der Trainingsjobs auf diese Weise, gemäss den Uber-Benchmarks der KubeCon 2024.

Lösung: einen Scheduler mit Gang Scheduling einsetzen, Volcano (hohe Reife, CNCF), Kueue (native Kubernetes-Integration) oder KAI Scheduler (fortgeschrittene NVIDIA-Funktionen). Bei Volcano den Job in eine PodGroup fassen, deren minMember der Gesamtzahl der Pods entspricht: alle gleichzeitig geplant oder keiner. Ein vernünftiges Timeout setzen: 10-15 Minuten für Jobs mit 8-16 GPUs, 30 Minuten für Jobs ab 32 GPUs. Gang-Scheduling-Metriken überwachen: Anteil der beim ersten Versuch zugelassenen Jobs, mittlere Wartezeit in der Queue, Anteil vermiedener Deadlocks. Sofortiger ROI: 20-30 % Ersparnis beim Trainingsbudget durch den Wegfall von Teilfehlschlägen.

Illustratives Szenario, Multi-Tenant-Cluster für ML-Teams

Dieses Szenario ist eine Illustration, die das Vorgehen zeigt, kein Hikube-Kunde und kein von Hikube gemessenes Deployment. Es läuft auf einem On-premise-Cluster; die Zahlen beschreiben diesen Fall und sind kein Ergebnis, das die Plattform reproduziert.

Der Fall: ein KI-Start-up mit drei Teams (Research, Production, Data Science), GPU-Budget 25 000 CHF/Monat, heterogene Anforderungen. Infrastruktur: ein On-Premise-Kubernetes-Cluster mit drei Node Pools, 4× H100-80GB-Knoten (intensives Training), 8× A100-80GB-Knoten (Produktionsinferenz und Fine-Tuning), 6× L40S-48GB-Knoten (Dev/Test und leichte Inferenz).

Ausgerollte Konfiguration:

• Pool Training (H100): exklusive GPUs, Volcano Gang Scheduling, Quoten je Team, Research 50 % (2 Knoten), Production 30 %, Data Science 20 %
• Pool Produktion (A100): MIG 2× 3g.40gb plus 1× 1g.10gb je GPU, Kueue mit strikten Quoten, Latenz-SLA unter 200 ms
• Pool Dev (L40S): Time-Slicing mit 8 Replicas je GPU, kein Gang Scheduling, Best-Effort-QoS

Umgesetzte Kueue-Quoten:

ClusterQueue «production»:
 - Flavors: A100-MIG-3g40gb, A100-MIG-1g10gb
 - Nominalquote: 12× 3g.40gb, 4× 1g.10gb
 - Max. je Workload: 4× 3g.40gb

ClusterQueue «research»:
 - Flavors: H100-full
 - Nominalquote: 16 ganze H100
 - Max. je Workload: 8 H100 (Gang Scheduling)
 - Borrowing: kann von «production» leihen, wenn dort ungenutzt

ClusterQueue «dev»:
 - Flavors: L40S-shared
 - Nominalquote: 48 Replicas (6 GPUs × 8 Replicas)
 - Max. je Workload: 2 Replicas
 - Preemption: kann von prioritären Queues verdrängt werden

Nach drei Monaten gemessene Ergebnisse:

• Gesamte GPU-Auslastung, 35 % (Ausgangswert) → 72 % (+106 %)
• Anteil beim ersten Versuch erfolgreicher Trainingsjobs, 62 % → 94 % (Gang Scheduling)
• Kosten je Inferenz, 0,12 CHF → 0,05 CHF (-58 % durch MIG und Batching)
• Time-to-first-GPU für Dev, 15 min → 30 s (Time-Slicing beseitigt die Wartezeit)
• Monatliche Ersparnis, 9200 CHF (37 % des Anfangsbudgets)

Die wesentlichen Erkenntnisse, Gang Scheduling beseitigt 90 % der Fehlschläge bei verteiltem Training, MIG in der Produktion halbiert die Inferenzkosten gegenüber exklusiven GPUs, Time-Slicing verändert die Entwicklererfahrung (keine Wartezeit mehr), und Kueue-Quoten vermeiden Konflikte zwischen Teams und erlauben intelligentes Ausleihen.

Zusammengefasst, drei Kernpunkte

GPU-Orchestrierung braucht spezialisierte Komponenten jenseits von Standard-Kubernetes

Kubernetes behandelt GPUs nicht von Haus aus als erstklassige Ressourcen. Die vollständige Architektur verbindet drei wesentliche Schichten: Device Plugin (stellt GPUs dem Scheduler bereit), GPU Operator (automatisiert den NVIDIA-Software-Lebenszyklus) und spezialisierte Scheduler (KAI, Kueue, Volcano für Gang Scheduling, Quoten, Topologie). Der Standard-Scheduler ignoriert GPU-Modell, VRAM und Netzwerktopologie und erzeugt so suboptimale Platzierung und Verschwendung. Der GPU Operator senkt die Einrichtungszeit von mehreren Tagen (manuelle Installation je Knoten) auf wenige Stunden (automatisiertes Helm-Deployment). Fortgeschrittene Scheduler bringen kritische Fähigkeiten, die dem Standard fehlen: Gang Scheduling beseitigt 90 % der Fehlschläge bei verteiltem Training, hierarchische Quoten mit Borrowing ermöglichen wirksame Mandantenfähigkeit, und topologiebewusste Platzierung senkt die Netzlatenz bei Multi-Node-Lasten um 70-80 %.

MIG und Time-Slicing decken unterschiedliche Bedürfnisse ab und sind nicht austauschbar

MIG liefert Hardware-Isolation (eigener VRAM, SM, Cache) und damit planbare Leistung und QoS, ideal für Multi-Tenant-Produktion unter strikten SLAs. Time-Slicing multiplext in Software ohne Speicherisolation und nimmt Contention und Leistungsschwankungen in Kauf, im Tausch gegen feinere Granularität (16+ Replicas gegenüber maximal 7 MIG-Instanzen) und universelle Kompatibilität (alle NVIDIA-GPUs gegenüber nur Ampere und Hopper). Die Praxisfälle zeigen eine klare Trennung: Produktionsinferenz unter SLA nutzt MIG (Kosten 50-60 % tiefer als bei exklusiver GPU), Dev/Test nutzt Time-Slicing (keine GPU-Wartezeit, Entwicklererfahrung zehnfach besser), intensives Training bleibt bei exklusiven GPUs (maximale Leistung). Beides im selben Node Pool ohne dokumentierte Strategie zu mischen erzeugt Verwirrung und operativen Aufwand. Der richtige Entscheid: dedizierte Node Pools mit klarer Strategie festlegen und die Nutzenden zwingen, per nodeSelector ausdrücklich zu wählen.

Gang Scheduling und intelligente Quoten verändern die Cluster-Effizienz

Gang Scheduling garantiert Atomarität, Alle Pods eines verteilten Jobs werden gleichzeitig geplant oder keiner, womit Deadlocks entfallen, bei denen ein Teil der Pods GPUs hält und unbegrenzt auf die fehlenden wartet. Ohne Gang Scheduling scheitern 20-40 % der Trainingsjobs und verschwenden dabei GPUs (Uber-Benchmarks). Kueue und Volcano setzen Gang Scheduling über PodGroups um, mit je Team konfigurierbaren Quoten und Borrowing zwischen Queues: eine garantierte Nominalquote und die Möglichkeit, ungenutzte Quoten anderer Teams gemäss konfigurierten Policies auszuleihen. Das illustrative Szenario weiter unten beziffert die Wirkung: GPU-Auslastung +106 % (35 % auf 72 %), Erfolgsquote der Jobs +52 % (62 % auf 94 %), Inferenzkosten -58 %, ROI in drei Monaten. Die Anfangsinvestition (1-2 Wochen Engineering, um Kueue oder Volcano auszurollen, Quoten zu konfigurieren und zu dokumentieren) amortisiert sich in weniger als zwei Monaten über GPU-Ersparnis und weniger Reibung zwischen Teams.