Ray auf Kubernetes: Distributed OS for AI

TL;DR

• Kubernetes + Ray bilden zusammen das „Distributed OS for AI": K8s härtet Produktion, Ray skaliert Python-Workloads über viele GPUs.
• Self-Hosting von LLMs ist oft günstiger als APIs — aber unterausgelastete GPUs vernichten den Vorteil.
• Ray ist die Unified Compute Engine für Training, Data, Batch-/Online-Inference und Post-Training — Python-nativ mit Actors und Tasks.
• KubeRay bringt Ray als Operator auf den Cluster: deklarativ, mandantenfähig, mit Rollouts.
• Ray lohnt sich ab Skalierung — einfache Workloads brauchen ihn nicht.

Warum Kubernetes allein nicht reicht

Kubernetes ist der Open-Source-Standard für Plattform-Builder: Container, Multi-Tenancy, deklarative Infrastruktur, Rollouts. Ray ist der Standard für AI/ML-Practitioner: ein Workload auf hunderte oder tausende Acceleratoren skalieren, heterogen, mit dynamischem Autoscaling.

Gemeinsam: härtend und zuverlässig (K8s) plus performant und skalierbar (Ray).

Das Kosten-Problem: Hardware, die brennt

Self-Hosting von LLMs ist gegenüber Cloud-APIs oft klar günstiger. In der Praxis unterauslasten viele Organisationen ihre GPUs — bei den Preisen heißt das: Geld verbrennen.

AI ist kein Use Case in einer Box. Es näht Data-ETL, Curation, Online-/Offline-Inference und Post-Training über Teams mit unterschiedlicher Expertise zusammen. Ohne Compute-Engine, die Auslastung und Elastizität versteht, bleibt teure Hardware idle.

Ray als Unified AI Compute Engine

• Ray Core: Verteilt Python-Code (Tasks, Actors, Futures, Ressourcen-Anforderungen).
• Ray Libraries: Training, Data, Batch-/Online-Inference, Reinforcement Learning, Post-Training.
• Python-nativ: Normaler Code plus Dekorator → verteilter Actor.
• Ein Tooling-Erlebnis über den ML-Lebenszyklus statt fünf getrennte Orchestrierer.

# Konzept: Actor statt manueller Prozess-Orchestrierung
import ray

@ray.remote(num_gpus=1)
class InferenceWorker:
    def __init__(self, model_id: str):
        self.model = load_model(model_id)

    def generate(self, prompt: str) -> str:
        return self.model.generate(prompt)

workers = [InferenceWorker.remote('org/model') for _ in range(4)]
refs = [w.generate.remote(p) for w, p in zip(workers, prompts)]
results = ray.get(refs)

Kunden-Beispiel aus dem Ökosystem: Modell-Entwicklung von einer Woche auf einen Tag verkürzt — durch Vereinheitlichung auf Ray (nicht durch „mehr YAML").

KubeRay: Ray auf dem Cluster betreiben

apiVersion: ray.io/v1
kind: RayCluster
metadata:
  name: ai-compute
spec:
  rayVersion: '2.34.0'
  headGroupSpec:
    serviceType: ClusterIP
    rayStartParams:
      dashboard-host: '0.0.0.0'
    template:
      spec:
        containers:
          - name: ray-head
            image: rayproject/ray:2.34.0-gpu
            resources:
              limits:
                cpu: '4'
                memory: 16Gi
  workerGroupSpecs:
    - groupName: gpu-workers
      replicas: 2
      minReplicas: 0
      maxReplicas: 8
      template:
        spec:
          containers:
            - name: ray-worker
              image: rayproject/ray:2.34.0-gpu
              resources:
                limits:
                  nvidia.com/gpu: 1

Kubernetes entfernt kaputte Nodes und provisioniert Compute. Ray arbeitet workload-bewusst mit dem, was da ist — inklusive Autoscaling nach App-Bedarf statt nur nach CPU-Metriken.

Messbare Hebel (Orientierungswerte)

Berichte zu optimierten Ray-Runtimes (je nach Vendor/Setup) nennen unter anderem:

Zahlen sind setup-abhängig. Das Muster zählt: Elastizität und Auslastung schlagen blindes „mehr GPUs".

Managed-Plattformen ergänzen das oft mit Image Streaming, Secondary Boot Disks und GPU-Fallback-Klassen — Open Source bleibt die portable Basis.

Wann Ray — und wann nicht

Mehr zum Gesamtstack: Open-Source-AI-Stack auf Kubernetes. Mehr zu Accelerator-Features: Kubernetes AI at Scale.

Lessons Learned

1. Unterauslastung ist der stille Kostenfresser — Self-Hosting ohne Autoscaling lohnt selten.
2. Die Tool-Landschaft wechselt schnell — kontinuierlich evaluieren, nicht einmalig festnageln.
3. Organisation zählt: Data, ML und Platform müssen denselben Compute-Pfad teilen.
4. Accelerator-Verfügbarkeit ist real — Fallback-Strategien (andere GPU-Klasse) einplanen.
5. Ray ist kein Default für jeden PoC — Komplexität erst ab Skalierung rechtfertigen.

Fazit

Ray auf Kubernetes ist die unabhängige Basis für produktive AI-Workloads: Produktion und Isolation von K8s, Python-Skalierung und Auslastung von Ray. Wer GPUs besitzt, braucht beides — sonst arbeitet die Hardware nicht, sie brennt Budget.

FAQ

Machen Ray und Kubernetes dasselbe? Nein. K8s orchestriert Container und Jobs; Ray orchestriert Prozesse innerhalb des Workloads.

Brauche ich Ray Turbo / Vendor-Runtime? Open-Source-Ray reicht zum Start. Vendor-Optimierungen können Batch und Spot weiter drücken — optional, nicht Pflicht für Architektur.

Was ist KubeRay? Der Kubernetes-Operator, der RayCluster und RayJobs deklarativ betreibt.

Verwandte Artikel

• Open-Source-AI-Stack: Ray, PyTorch und vLLM
• Kubernetes AI at Scale: DRA und Inference
• LLM-D: Verteilte Inference
• GPU Workloads auf Kubernetes
• AI auf Kubernetes starten