Open-Source-AI-Stack auf Kubernetes: Ray, PyTorch und vLLM

TL;DR

• Der Open-Source-AI-Stack beantwortet: Wie betreibt ein Unternehmen KI, ohne sich an einen Anbieter zu binden?
• Vier Schichten: Kubernetes (Produktion) → Ray (verteiltes Compute) → PyTorch (Training/Inference) → vLLM (LLM-Serving).
• Ray und Kubernetes arbeiten auf unterschiedlicher Granularität — Container vs. Prozesse im Workload. Zusammen sind sie stark.
• Workloads haben sich verändert: multimodale Daten, Reinforcement Learning, große Modelle und Multi-Agent-Systeme.
• Self-Hosting ist günstiger als APIs — nur mit Auslastung und Autoscaling, sonst verbrennen GPUs Budget.

Die Architektur in einem Bild

Kubernetes (Container, Multi-Tenancy, Produktion)
  └── Ray (distributed Compute — orchestriert Prozesse)
        ├── PyTorch (Training / Framework auf der GPU)
        └── vLLM (Inference-Engine für LLMs)

Jede Schicht löst ein eigenes Problem. Zusammen entsteht eine unabhängige, firmeneigene KI-Architektur: Daten, Modelle und Kosten bleiben kontrollierbar.

Warum sich AI-Workloads verändert haben

Drei Treiber:

1. Daten: Von Tabellen/SQL auf CPUs hin zu multimodalen Daten (Video, PDFs, Audio) — Inference auf GPUs plus klassische Verarbeitung auf CPUs.
2. Training: Von reinem Supervised Training hin zu Reinforcement Learning — Modell interagiert mit Umgebung, erzeugt Daten, verbessert sich. Systemisch deutlich komplexer.
3. Serving: Von einzelnen Modellen hin zu sehr großen Modellen und Multi-Agent-Systemen.

Ein einzelnes Helm-Chart für „das Modell" trägt das nicht. Es braucht einen Stack, dessen Schichten koevolvieren.

Die Schichten im Detail

Warum Ray als „Klebstoff"

Ray entstand aus RL-Forschung in Berkeley — Spark und klassisches HPC passten nicht zu großen AI-Workloads. Die Actor-Abstraktion macht aus einer Python-Klasse einen verteilten Prozess: skaliert von 1 bis zehntausende, spricht mit anderen Actors.

Anders als reine Data-, Serving- oder Trainings-Systeme kann Ray Daten, Training, Serving und RL in einem System tragen. Viele neue Open-Source-RL-Frameworks setzen darauf — wegen Prozess-Koordination und Datentransfer, inzwischen auch mit direktem GPU-zu-GPU-Pfad (RDMA) statt Umweg über CPU.

Warum Kubernetes trotzdem bleibt

# vLLM als Serving-Schicht — Ray orchestriert darüber bei Bedarf
apiVersion: apps/v1
kind: Deployment
metadata:
  name: vllm
spec:
  replicas: 2
  selector:
    matchLabels:
      app: vllm
  template:
    metadata:
      labels:
        app: vllm
    spec:
      containers:
        - name: engine
          image: vllm/vllm-openai:latest
          args: ['--model', 'your-org/model']
          resources:
            limits:
              nvidia.com/gpu: 1

Kubernetes denkt in Jobs und Containern: Fehlerbehandlung auf Container-Ebene, Provisioning, Multi-Tenancy. Ray denkt innerhalb des Workloads: Scheduling einzelner Functions, Koordination, workload-bewusstes Autoscaling.

Die Magie der Kombination:

• K8s entfernt kaputte GPUs und provisioniert Compute — Ray arbeitet mit dem Bestand.
• GPUs zwischen Training und Inference verschieben, statt statisch zu partitionieren.
• Bei Riesen-Jobs: K8s restartet Container; Ray weiß, was im Workload neu laufen muss.

Details zu Ray: Ray auf Kubernetes. Details zu Inference-Verteilung: LLM-D.

Ray + vLLM: Ko-Evolution

LLM-Inference ist komplex: Prefill/Decode-Disaggregation, Expert-Parallelität, KV-Cache-aware Routing. Ray- und vLLM-Communities arbeiten an feingranularer Platzierung von Workern — genau dafür.

Ray liegt bei der PyTorch/Linux Foundation — der natürliche Ort für fundamentale Infrastruktur. KubeRay ist der weit verbreitete Operator.

Unabhängigkeit als Architektur-Entscheidung

apiVersion: ray.io/v1
kind: RayJob
metadata:
  name: batch-infer
spec:
  entrypoint: python batch_infer.py
  rayClusterSpec:
    headGroupSpec:
      template:
        spec:
          containers:
            - name: ray-head
              image: rayproject/ray:2.34.0
    workerGroupSpecs:
      - groupName: gpu
        replicas: 4
        template:
          spec:
            containers:
              - name: ray-worker
                image: rayproject/ray:2.34.0-gpu
                resources:
                  limits:
                    nvidia.com/gpu: 1

Wer KI „besitzen" will, braucht keine Vendor-API als einzige Option — sondern eine offene Plattform:

• kein Lock-in auf eine Inference-API
• volle Kontrolle über Daten und Modelle
• Kostenmodell steuerbar (z. B. Frontier-Modell für 10 %, günstige Modelle für 90 %)

Wann der volle Stack — und wann nicht

Komplexität ist real. Kleine Workloads ohne Ray betreiben — die Schichten erst einschalten, wenn Skalierung und Koordination wehtun.

Lessons Learned

1. Rollen klar trennen: Wer Ray und K8s für „dasselbe" hält, baut fragile Systeme.
2. Ökosystem wechselt Logos — kontinuierlich evaluieren.
3. Selbst-Hosting lohnt mit Betrieb — ohne Auslastung kein Kostenvorteil.
4. Foundation-Home zählt für langfristige Standards (vgl. Kubernetes, Linux, PyTorch).

Fazit

Der Open-Source-AI-Stack auf Kubernetes ist die Architektur für Unternehmen, die KI unabhängig betreiben wollen: Kubernetes als Produktionsbasis, Ray als Compute-Klebstoff, PyTorch und vLLM auf der GPU. Unabhängigkeit ist keine Folie — sie ist eine bewusste Schichtentscheidung.

FAQ

Machen Ray und Kubernetes dasselbe? Nein — unterschiedliche Granularität. Zusammen orchestrieren sie Container und Prozesse im Workload.

Brauche ich Ray für jede KI? Nein. Erst ab Skalierung, RL oder komplexer Workload-Koordination.

Ist Open Source wirklich günstiger? Gegenüber Cloud-APIs oft ja — wenn GPUs ausgelastet sind und Autoscaling greift.

Verwandte Artikel

• Ray auf Kubernetes: Distributed OS for AI
• Llama Stack: Enterprise-KI-Plattform
• LLM-D: Verteilte Inference
• Kubernetes AI at Scale
• Agentic AI auf Kubernetes