GPU Workloads auf Kubernetes: Was Ihre Plattform wirklich braucht

Jeden zweiten Monat stellt uns ein Kunde die gleiche Frage: "Wir müssen AI-Workloads betreiben. Sollen wir eine separate Infrastruktur dafür aufsetzen?"

Die Antwort ist fast immer nein. Wenn Sie bereits eine Managed-Kubernetes-Plattform haben, haben Sie 90% von dem, was Sie brauchen. Die restlichen 10% sind GPU Node Pools, die richtige Scheduling-Konfiguration und Observability, die GPU-Metriken versteht. Darum geht es in diesem Beitrag.

Wir betreiben GPU-Workloads auf unseren Managed Clustern seit 2024, für Anwendungsfälle von LLM-Inferenz und RAG-Pipelines bis zu Batch-Embedding-Generierung und Model Fine-Tuning. Die Workloads laufen auf der gleichen Plattform, mit den gleichen GitOps-Workflows, dem gleichen Observability-Stack und den gleichen SLA-Garantien wie jeder andere Workload.

GPU Node Pools: bewusst getrennt

Das Erste, was Sie brauchen, ist ein dedizierter Node Pool für GPU-Workloads. Sie wollen nicht, dass GPU-Nodes Ihren Ingress Controller oder Prometheus betreiben. GPUs sind teuer, und jede Minute, die eine GPU im Leerlauf Platform Services ausführt, ist verschwendetes Geld.

Wir nutzen Kubernetes Taints und Tolerations, um diese Trennung durchzusetzen. GPU-Nodes bekommen einen Taint (nvidia.com/gpu=present:NoSchedule), der verhindert, dass ein Pod auf ihnen gescheduled wird, ausser er toleriert den Taint explizit. Nur Pods, die GPU-Ressourcen anfordern (nvidia.com/gpu: 1), bekommen die Toleration.

Das bedeutet:

• Reguläre Workloads landen nie auf GPU-Nodes (keine versehentlichen Kosten)
• GPU-Workloads konkurrieren nie mit CPU-Workloads ums Scheduling
• Sie können GPU- und CPU-Node-Pools unabhängig skalieren
• Der Cluster Autoscaler kann GPU-Nodes basierend auf tatsächlichem GPU-Bedarf hinzufügen/entfernen

Auf Natron Cloud und Flex Stack provisionieren wir GPU-Nodes mit NVIDIA A100 oder H100 Karten, je nach Workload-Anforderungen. Auf BYOC mit Azure konfigurieren wir AKS Node Pools mit NC-Series oder ND-Series VMs. Der Platform Stack darauf ist identisch, unabhängig davon, wo die GPU-Hardware lebt.

Was passiert, wenn ein GPU-Pod gescheduled wird

Der Scheduling-Flow für GPU-Workloads hat ein paar mehr Schritte als reguläre Pods, und jeder kann still fehlschlagen, wenn er nicht korrekt konfiguriert ist.

Die kritische Komponente hier ist das NVIDIA Device Plugin. Es läuft als DaemonSet auf jedem GPU-Node und exponiert die GPUs als schedulbare Ressourcen für die Kubernetes-API. Ohne es weiss der Scheduler nicht, dass GPUs existieren. Wir deployen und managen das als Teil unseres Platform Stacks via FluxCD, damit Kunden nicht daran denken müssen.

Model Weights sind typischerweise gross (7B-Parameter-Modelle sind 14 GB, 70B-Modelle sind 140 GB). Sie müssen aus dem Object Storage (unser Ceph S3 oder Azure Blob) in den GPU-Speicher gezogen werden, bevor das Modell Anfragen bedienen kann. Diese Startup-Zeit ist relevant. Wir konfigurieren Readiness Probes, die das Model Loading berücksichtigen, damit der Ingress keinen Traffic an einen Pod routet, der noch Weights lädt.

Der AI/ML-Stack auf Kubernetes

Sie brauchen keine spezialisierte AI-Plattform. Sie brauchen die richtigen Komponenten, deployed als reguläre Kubernetes-Workloads:

Model Serving ist der häufigste GPU-Workload, den wir betreiben. vLLM ist unsere Standard-Empfehlung für LLM-Inferenz. Es handhabt Batching, Paged Attention und Multi-GPU Tensor Parallelism out of the box. Für Kunden, die Open-Source-Modelle lokal betreiben wollen (Llama, Mistral, Qwen), ist vLLM als Kubernetes Deployment mit GPU Requests der einfachste Weg. Ollama funktioniert für leichtere Workloads und lokale Entwicklungsmuster.

Vector-Datenbanken für RAG-Pipelines laufen auf regulären CPU-Node-Pools. pgvector (PostgreSQL-Extension) ist unser Standard, weil die meisten Kunden bereits PostgreSQL auf der Plattform haben. Für grösseren Vector-Search deployen wir Qdrant oder Milvus.

Model Weight Storage nutzt unseren bestehenden Ceph S3 (auf Natron Cloud / Flex Stack) oder den Cloud Object Storage des Kunden (Azure Blob / GCS). Modelle werden beim Pod-Start gezogen. Für häufig genutzte Modelle verwenden wir PersistentVolumes mit ReadWriteMany, um Weights über Replicas zu teilen, ohne erneut herunterzuladen.

GPU Observability: DCGM Exporter + unser bestehender Stack

Hier scheitern die meisten selbstverwalteten Setups. Standard-Prometheus-Metriken enthalten keine GPU-Auslastung, -Speicher, -Temperatur oder -Leistungsaufnahme. Sie brauchen den NVIDIA DCGM Exporter, der GPU-Metriken als Prometheus-kompatible Endpoints exponiert.

Wir deployen den DCGM Exporter als DaemonSet auf jedem GPU-Node, neben unserem Standard Node Exporter. Die Metriken fliessen in die gleiche Prometheus-Instanz, die den Rest des Clusters überwacht. Wir haben vorgebaute Grafana-Dashboards, die zeigen:

Die Alerting Rules sind GPU-aware:

• GPU-Auslastung unter 10% für 30 Minuten: Sie zahlen für eine GPU, die nicht genutzt wird. Runterskalieren oder Spot-Instanzen in Betracht ziehen.
• GPU-Speicher über 95%: Das Modell ist nahe am OOM. Der nächste Request Batch könnte fehlschlagen.
• Inference-Latenz p99 über Schwellwert: Das Modell wird zum Bottleneck. Replicas hinzufügen oder auf eine grössere GPU wechseln.
• GPU-Temperatur über 85°C: Thermal Throttling steht bevor. Kühlung prüfen oder Batch-Grössen reduzieren.

Das ist der gleiche Ansatz, den wir bei jeder Plattform-Komponente verfolgen: installieren, sinnvolle Defaults konfigurieren, Dashboards bauen, Alert Rules schreiben und als Teil der Plattform managen. Der Kunde sieht GPU-Metriken in seinem Grafana-Dashboard neben seinen Applikations-Metriken.

Skalierungsmuster

GPU-Workloads skalieren anders als CPU-Workloads. Man kann nicht einfach Replicas hinzufügen wie bei einem Web Service, weil jedes Replica eine dedizierte GPU braucht, und GPUs sind knapp und teuer.

Horizontale Skalierung funktioniert für Inference-Workloads. Wenn Sie mehr Durchsatz brauchen, fügen Sie mehr Replicas hinzu (jedes mit einer GPU). Der Cluster Autoscaler provisioniert neue GPU-Nodes nach Bedarf. Wir konfigurieren Scale-Up-Schwellwerte basierend auf Inference Queue Depth, nicht CPU-Auslastung.

Vertikale Skalierung funktioniert für Model-Grösse. Wenn Sie ein grösseres Modell betreiben müssen, brauchen Sie eine grössere GPU (oder mehrere GPUs pro Pod mit Tensor Parallelism). Das ist eine Konfigurationsänderung in der Pod Spec, kein Scaling Event.

Batch Scheduling funktioniert für Fine-Tuning und Embedding-Generierung. Diese sind nicht latenz-sensitiv. Wir nutzen Kubernetes Jobs mit GPU Requests, gescheduled in Off-Peak-Zeiten, wenn GPU-Nodes freie Kapazität haben. Das maximiert die GPU-Auslastung, ohne mit Echtzeit-Inferenz zu konkurrieren.

Was gleich bleibt

Der gesamte Platform Stack, den wir in unserem Managed-Kubernetes-Beitrag beschreiben, funktioniert unverändert für GPU-Workloads:

• Cilium handhabt Networking für GPU-Pods gleich wie für CPU-Pods. Network Policies gelten identisch.
• cert-manager terminiert TLS für Ihre Model-Serving-Endpoints. Ihre vLLM-API bekommt automatisch HTTPS.
• ArgoCD deployt Ihre Model-Serving-Konfiguration aus Git. Neue Model-Version? Image Tag aktualisieren, pushen, ArgoCD synct.
• Kyverno erzwingt Policies auf GPU-Pods. Resource Requests required, Image Registries restricted, Privileged Containers blocked.
• Velero sichert die Konfiguration (nicht die Model Weights, die leben im Object Storage).
• Loki sammelt Logs von GPU-Pods. Wenn Inference fehlschlägt, suchen Sie Logs gleich wie bei jedem anderen Workload.

Das ist der Punkt: GPU-Workloads sind einfach Workloads. Sie brauchen eine GPU-Ressource, eine Toleration und vernünftige Observability. Alles andere, das Networking, die Security, das GitOps, das Backup, das Monitoring, ist die gleiche Plattform, die Ihre anderen Workloads bereits nutzen.

Loslegen

Wenn Ihr Team AI-Workloads erforscht und Sie bereits auf unserer Managed-Kubernetes-Plattform sind, sind GPU Node Pools ein Add-on, keine neue Plattform. Wir konfigurieren die Hardware, deployen die NVIDIA-Toolchain, richten die Observability ein, und Ihr Team deployt Modelle über den gleichen ArgoCD-Workflow, den sie für alles andere nutzen.

Wenn Sie Optionen evaluieren, vereinbaren Sie einen Termin. Wir schauen uns Ihre Workload-Anforderungen an (Model-Grösse, Latenz-Ziele, Durchsatz-Bedarf) und designen eine GPU-Node-Pool-Konfiguration, die passt.