KI-Workloads auf Kubernetes 2026: Der Produktions-Stack (Kueue, KServe, vLLM, KubeRay)

Vor zwei Jahren war die Frage, ob Kubernetes der richtige Ort für KI-Workloads ist, noch offen. 2026 ist sie beantwortet: Der Produktions-Stack für KI/ML auf Kubernetes hat sich konsolidiert, die CNCF hat zentrale Projekte graduiert, und die Tooling-Landschaft ist erwachsen geworden. GPU-Cluster unter Kubernetes gehören heute zum Standard-Repertoire von Platform-Engineering-Teams – egal ob für LLM-Inferenz, verteiltes Training oder Multi-Tenant-Umgebungen mit mehreren Teams.

Die Reference Architecture 2026

Ein typischer Produktions-Stack für KI auf Kubernetes besteht aus mehreren Schichten, die nahtlos ineinandergreifen. Die GPU-Infrastruktur-Ebene wird durch den NVIDIA GPU Operator (aktuell v26.3.3) gebildet, der Treiber, Container Runtime, Device Plugin und DCGM-Monitoring mit einem einzigen Helm-Chart installiert und MIG-Partitionierung sowie Time-Slicing ermöglicht. Darüber liegt die Scheduling-Ebene, in der Kueue (CNCF, Kubernetes-SIG-Projekt) die Admission Control und Quota-Verwaltung übernimmt – entscheidend für Multi-Tenant-Cluster, in denen mehrere Teams um GPUs konkurrieren. Für verteiltes Training mit Gang Scheduling (bei dem alle Pods eines Jobs nur gemeinsam starten) kommt Volcano (CNCF Graduated) oder der quelloffene KAI Scheduler zum Einsatz. Oft laufen Kueue und Volcano als geschichtetes System: Kueue hält Jobs zurück, wenn das Quota erschöpft ist, während Volcano die atomare Platzierung sicherstellt.

Für die Inferenz hat sich vLLM als Standard-Inference-Engine durchgesetzt – mit PagedAttention, Continuous Batching und einer OpenAI-kompatiblen API. Darum herum legt KServe (CNCF Incubating) eine Kubernetes-native Serving-Schicht mit Autoscaling (inkl. Scale-to-Zero), Canary-Deployments und Traffic-Splitting. Für Modelle jenseits der 70B-Parameter (Llama 4 405B, DeepSeek V3) kommt zunehmend llm-d zum Einsatz, ein verteiltes Inference-Framework mit disaggregiertem Serving, das Prefill und Decode trennt und KV-Caches node-übergreifend verteilt.

Trainings-Workloads laufen typischerweise über Ray mit dem KubeRay-Operator, der RayCluster, RayJob und RayService als native Kubernetes-CRDs bereitstellt. KubeRay v1.7 (August 2026) brachte einen History Server (Beta), automatische mTLS-Zertifikatsverwaltung, NetworkPolicy-Unterstützung und Kubernetes-RBAC-basierte Authentifizierung – ein deutlicher Sprung in der Production-Readiness.

GPU-Scheduling: Der Engpass, den niemand ignorieren kann

Der grösste Unterschied zwischen klassischen Microservices und KI-Workloads auf Kubernetes ist der Umgang mit GPUs. Der Standard-Scheduler platziert Pods einzeln – ein verteilter Trainingsjob, bei dem sieben von acht Worker-Pods starten, der achte aber auf eine GPU wartet, blockiert die anderen sieben GPUs bei nahezu null Auslastung. Genau hier greifen Gang Scheduling (Volcano, KAI Scheduler) und Quota-Queues (Kueue): Kueue hebelt die GPU-Auslastung von 25–35 % auf 60–85 %, indem es Fair-Share-Queues über Teams hinweg durchsetzt und Preemption für prioritäre Workloads ermöglicht. Die Kombination aus Admission Control und Gang Scheduling ist inzwischen der Produktionsstandard für Multi-Tenant-GPU-Cluster.

Auch Topology-Aware-Scheduling spielt eine wachsende Rolle: Pods, die auf Nodes mit gemeinsamem NVLink platziert werden, erreichen eine drei- bis fünfmal niedrigere Inter-GPU-Latenz als Pods über separate Netzwerk-Switches hinweg.

Multi-Tenancy und Kostenkontrolle

Shared GPU-Infrastruktur ist teuer – eine ungedrosselte Research-Workload kann die Latenz von Produktions-Inferenz-Endpoints spürbar beeinträchtigen. Die Praxis hat sich auf Namespaces + RBAC + ResourceQuotas als logische Partitionierung, PriorityClasses für Preemption und Kueue-ClusterQueues für teamübergreifende Fair-Share-Policies eingependelt.

Auf der Kostenseite sorgt Karpenter für dynamische Node-Provisions: Wenn ein Training-Job ansteht, provisioniert Karpenter passgenaue Spot- oder On-Demand-Instanzen und skaliert sie wieder herunter, sobald die Arbeit erledigt ist. Für GPU-Workloads, die Interruption tolerieren (Training mit Checkpointing), sind Spot-Instanzen ein massiver Kostenhebel – die Cloud-Anbieter bewerben bis zu 90 % Rabatt gegenüber On-Demand-Preisen.

Fazit

Der KI/ML-Stack auf Kubernetes ist 2026 produktionsreif und standardisiert. Die Kernkomponenten – NVIDIA GPU Operator, Kueue, KServe, vLLM, Ray mit KubeRay – sind CNCF-graduiert oder auf dem Weg dorthin und werden von einer grossen Community getragen. Platform-Teams, die heute in diesen Stack investieren, profitieren von Portabilität über Cloud-Anbieter und On-Premises-Umgebungen hinweg, von fairer GPU-Verteilung zwischen Teams und von einem Ökosystem, das sich rasant weiterentwickelt – KubeRay v1.7, KServes CNCF-Inkubation und die wachsende Verbreitung von llm-d zeigen, dass die Richtung klar ist. Wer KI-Workloads ernsthaft betreiben will, kommt an Kubernetes als Orchestrierungsebene 2026 nicht mehr vorbei.

Quellen

• AI/ML on Kubernetes 2026: Production Stack Guide (vLLM, Kueue, KServe, Ray) — KubernetesGuru (Juli 2026)
• Kubernetes AI Infrastructure in 2026: GPU Scheduling & Production Realities — CloudOptimo (Mai 2026)
• Introducing KubeRay v1.6 and v1.7 — Anyscale (August 2026)
• Best Kubernetes Setup for Production AI Workloads (2026) — Markaicode (August 2026)
• Kubernetes and AI Workloads: Best Practices for 2026 — CloudStrata (März 2026)