Ray-Cluster für KI: Architektur für verteiltes Rechnen

Aktualisiert am 11. Dezember 2025

Update Dezember 2025: OpenAI nutzt Ray zur Koordination des ChatGPT-Trainings. Rays Beitritt zur PyTorch Foundation bestätigt die Akzeptanz im Enterprise-Bereich. Das Framework skaliert vom Laptop bis zu Tausenden von GPUs. Es erreicht Millionen von Tasks pro Sekunde mit Sub-Millisekunden-Latenz – eine Größenordnung schneller als Spark für KI-Muster. Native heterogene Compute-Unterstützung ermöglicht die Mischung von CPU/GPU-Workloads.

OpenAI nutzt Ray zur Koordination des Trainings von ChatGPT und anderen Modellen.¹ Das Framework skaliert vom Laptop bis zu Clustern mit Tausenden von GPUs und bewältigt die Komplexität des verteilten Rechnens, die sonst für jedes Projekt eine eigene Infrastruktur erfordern würde. Rays Verbreitung explodierte im Jahr 2025, bestätigt durch den Beitritt des Frameworks zur PyTorch Foundation und Anyscales Kapitalaufnahme zur Unterstützung von Enterprise-Deployments.² Das Verständnis von Rays Architektur und Deployment-Mustern hilft Organisationen beim Aufbau einer verteilten KI-Infrastruktur, die vom Experimentieren bis zur Produktion skaliert.

Ray bietet ein einheitliches Framework für verteilte KI-Workloads – Training, Tuning, Inferenz und Datenverarbeitung – das die Komplexität des Cluster-Managements abstrahiert und gleichzeitig feingranulare Kontrolle über die Ressourcenzuweisung erhält. Für Organisationen, die über Single-GPU-Experimente hinaus zu Multi-Node-Produktionssystemen übergehen, bietet Ray den direktesten Weg zu einer skalierbaren KI-Infrastruktur.

Warum Ray für KI-Infrastruktur

Ray entstand aus dem RISELab der UC Berkeley, um die spezifischen Herausforderungen verteilter KI-Workloads zu bewältigen, die traditionelle Frameworks wie Apache Spark schlecht handhaben:

Anforderungen an KI-Workloads

Heterogenes Computing: KI-Pipelines mischen CPU-intensive Datenverarbeitung mit GPU-beschleunigtem Training und Inferenz. Ray unterstützt nativ heterogene Ressourcenzuweisung und plant Tasks je nach Workload-Anforderungen über CPUs und GPUs hinweg.³

Feingranulare Parallelität: Deep-Learning-Training erfordert die Koordination von Gradienten über Worker hinweg, das Management von Modellzuständen und den eleganten Umgang mit Ausfällen. Rays Task- und Actor-Abstraktionen bieten die Primitive, die für diese Muster benötigt werden.

Zustandsbehaftete Berechnung: Im Gegensatz zu MapReduce-artigen Frameworks halten KI-Workloads oft Zustände über Iterationen hinweg. Ray-Actors persistieren Zustände zwischen Aufrufen und unterstützen Muster wie Parameter-Server und Reinforcement-Learning-Agenten.

Niedrige Latenz: Echtzeit-Inferenz und Hyperparameter-Suche erfordern Task-Scheduling im Mikrosekundenbereich. Ray erreicht Millionen von Tasks pro Sekunde mit Sub-Millisekunden-Latenz – eine Größenordnung schneller als Spark für diese Muster.⁴

Vergleich mit Alternativen

Apache Spark: Optimiert für Batch-Datenverarbeitung mit SQL und DataFrames. Excelliert bei ETL, Feature Engineering und Analytik auf strukturierten Daten. Weniger geeignet für GPU-Workloads, zustandsbehaftete Berechnungen und Anforderungen an niedrige Latenz.⁵

Dask: Python-natives verteiltes Computing mit DataFrame- und Array-APIs. Leichtgewichtiger als Spark, aber ohne Rays Actor-Modell und ML-spezifische Bibliotheken.

Horovod: Speziell auf verteiltes Deep-Learning-Training fokussiert. Weniger flexibel als Ray für diverse KI-Workloads, aber einfacher für reine Trainingsszenarien.

Rays Vorteil: Ein einzelnes Framework bewältigt Datenverarbeitung, Training, Hyperparameter-Tuning und Inference-Serving. Teams vermeiden die Verwaltung mehrerer Systeme und die Integrationskomplexität zwischen ihnen.

Produktionseinsatz

Große Organisationen betreiben Ray in der Produktion:⁶

• OpenAI: ChatGPT-Trainingskoordination
• Uber: Verteilte ML-Plattform
• Instacart: ML-Infrastruktur-Backbone
• Shopify: Produktions-ML-Workloads
• Ant Group: Groß angelegtes Finanz-ML

Ray-Cluster unterstützen offiziell bis zu 2.000 Nodes und ermöglichen die Skalierung, die für das Training von Frontier-Modellen und hochvolumige Inferenz erforderlich ist.

Ray-Architektur

Kern-Abstraktionen

Ray bietet zwei fundamentale Abstraktionen für verteilte Berechnung:

Tasks: Zustandslose Funktionen, die remote ausgeführt werden. Ray plant Tasks automatisch über verfügbare Worker, behandelt Ausfälle und gibt Ergebnisse zurück.

import ray

ray.init()

@ray.remote
def process_batch(data):
    # Läuft auf jedem verfügbaren Worker
    return transform(data)

# Parallel ausführen
futures = [process_batch.remote(batch) for batch in batches]
results = ray.get(futures)

Actors: Zustandsbehaftete Objekte, die über den Cluster verteilt sind. Jeder Actor hält den Zustand zwischen Methodenaufrufen und ermöglicht Muster wie Model-Serving, Parameter-Server und Spielumgebungen.

@ray.remote
class ModelServer:
    def __init__(self, model_path):
        self.model = load_model(model_path)

    def predict(self, input_data):
        return self.model(input_data)

# Actor-Instanz erstellen
server = ModelServer.remote("model.pt")
# Methoden remote aufrufen
prediction = ray.get(server.predict.remote(data))

Cluster-Architektur

Ray-Cluster bestehen aus einem Head-Node und Worker-Nodes:

Head-Node: Führt den Global Control Store (GCS) aus, der den Cluster-Zustand verwaltet, das Object Directory zur Verfolgung von Datenstandorten und den Scheduler zur Koordination der Task-Platzierung.

Worker-Nodes: Führen Tasks und Actors aus. Jeder Worker führt einen Raylet-Daemon aus, der lokales Scheduling und Object-Management übernimmt.

Object Store: Verteilter Shared Memory, der Zero-Copy-Datenweitergabe zwischen Tasks auf demselben Node und effiziente Serialisierung über Nodes hinweg ermöglicht.

Ressourcenmanagement

Ray verwaltet heterogene Ressourcen explizit:

@ray.remote(num_cpus=4, num_gpus=1)
def train_step(model, data):
    # Garantiert 4 CPUs und 1 GPU
    return model.train(data)

Benutzerdefinierte Ressourcen ermöglichen feingranulares Scheduling:

# Spezifische Hardware anfordern
@ray.remote(resources={"TPU": 1})
def tpu_inference(data):
    return run_on_tpu(data)

Ray-KI-Bibliotheken

Ray enthält speziell entwickelte Bibliotheken für gängige KI-Workloads:

Ray Train

Abstraktion für verteiltes Training mit Unterstützung für PyTorch, TensorFlow und andere Frameworks:

from ray.train.torch import TorchTrainer
from ray.train import ScalingConfig

def train_func():
    # Standard-PyTorch-Trainingscode
    model = MyModel()
    for epoch in range(10):
        train_epoch(model)

trainer = TorchTrainer(
    train_loop_per_worker=train_func,
    scaling_config=ScalingConfig(
        num_workers=8,
        use_gpu=True
    ),
)
result = trainer.fit()

Wichtige Funktionen:⁷ - Skalierung von Single-GPU zu Multi-Node-Clustern mit 2 Zeilen Codeänderung - Automatisches verteiltes Datenladen und Gradienten-Synchronisation - Checkpoint-Management und Fehlerwiederherstellung - Integration mit PyTorch Lightning, Hugging Face Transformers und DeepSpeed

Ray Tune

Verteilte Hyperparameter-Optimierung:

from ray import tune
from ray.tune.schedulers import ASHAScheduler

def training_function(config):
    model = build_model(config["learning_rate"], config["batch_size"])
    for epoch in range(100):
        loss = train_epoch(model)
        tune.report(loss=loss)

analysis = tune.run(
    training_function,
    config={
        "learning_rate": tune.loguniform(1e-4, 1e-1),
        "batch_size": tune.choice([32, 64, 128])
    },
    scheduler=ASHAScheduler(metric="loss", mode="min"),
    num_samples=100,
)

Ray Tune bietet: - Parallele Trial-Ausführung über den Cluster - Early Stopping mit ASHA, Population-Based Training und anderen Schedulern - Integration mit Optuna, HyperOpt und anderen Optimierungsbibliotheken - Checkpointing und Wiederaufnahme

Ray Serve

Produktions-Model-Serving mit Autoscaling:

from ray import serve

@serve.deployment(num_replicas=2, ray_actor_options={"num_gpus": 1})
class LLMDeployment:
    def __init__(self):
        self.model = load_llm()

    async def __call__(self, request):
        prompt = await request.json()
        return self.model.generate(prompt["text"])

serve.run(LLMDeployment.bind())

Ray Serve Funktionen:⁸ - Autoscaling basierend auf Request-Rate - Zero-Downtime-Deployments - Multi-Model-Komposition und Request-Routing - OpenAI-kompatible API für LLM-Serving - 60% Reduktion der Time-to-First-Token mit Prefix-Aware-Routing⁹

Ray Data

Verteiltes Datenladen und Preprocessing:

import ray

ds = ray.data.read_parquet("s3://bucket/data/")
ds = ds.map(preprocess)
ds = ds.filter(lambda x: x["label"] > 0)

# In PyTorch DataLoader konvertieren
train_loader = ds.iter_torch_batches(batch_size=32)

Ray Data bietet: - Streaming-Ausführung für große Datasets - GPU-beschleunigtes Preprocessing - Integration mit Ray Train für verteiltes Training - Native Unterstützung für Bild-, Text- und tabellarische Daten

Kubernetes-Deployment mit KubeRay

Produktions-Ray-Deployments laufen typischerweise auf Kubernetes mit KubeRay, dem offiziellen Kubernetes-Operator:¹⁰

KubeRay-Komponenten

RayCluster CRD: Definiert die Cluster-Konfiguration einschließlich Head- und Worker-Node-Spezifikationen, Autoscaling-Richtlinien und Ressourcenanforderungen.

apiVersion: ray.io/v1
kind: RayCluster
metadata:
  name: ml-cluster
spec:
  headGroupSpec:
    rayStartParams:
      dashboard-host: '0.0.0.0'
    template:
      spec:
        containers:
        - name: ray-head
          image: rayproject/ray:2.52.0-py310-gpu
          resources:
            limits:
              nvidia.com/gpu: 1
  workerGroupSpecs:
  - replicas: 4
    minReplicas: 2
    maxReplicas: 10
    groupName: gpu-workers
    rayStartParams: {}
    template:
      spec:
        containers:
        - name: ray-worker
          image: rayproject/ray:2.52.0-py310-gpu
          resources:
            limits:
              nvidia.com/gpu: 1

RayJob CRD: Übermittelt Jobs an automatisch bereitgestellte Cluster. KubeRay erstellt den Cluster, führt den Job aus und löscht optional den Cluster nach Abschluss.

RayService CRD: Verwaltete Ray-Serve-Deployments mit Zero-Downtime-Upgrades und Health-Checking.

Best Practices für die Produktion

Container-Images: Abhängigkeiten in veröffentlichte Docker-Images einbacken, anstatt sie zur Laufzeit zu installieren. Dies gewährleistet Reproduzierbarkeit und schnelleren Start.¹¹

Autoscaling: Sowohl Ray-Autoscaling (Skalierung von Workern innerhalb eines Clusters) als auch Kubernetes-Autoscaling (Skalierung von Cluster-Nodes) aktivieren:

spec:
  enableInTreeAutoscaling: true
  autoscalerOptions:
    upscalingMode: Default
    idleTimeoutSeconds: 60

Storage: Persistent Volumes für Checkpoints und Shared Storage für große Datasets verwenden:

volumes:
- name: shared-storage
  persistentVolumeClaim:
    claimName: ml-data-pvc

Monitoring: Integration mit Prometheus und Grafana für Observability:

metadata:
  annotations:
    prometheus.io/scrape: "true"
    prometheus.io/port: "8080"

Cloud-spezifische Deployments

GKE: Ray on GKE Add-on bietet verwaltete Ray-Cluster mit automatischer Bereitstellung und Integration mit Google Cloud Services.¹²

EKS: KubeRay mit Cluster Autoscaler oder Karpenter für Node-Skalierung deployen. Integration mit FSx for Lustre bietet hochleistungsfähigen Shared Storage.

AKS: Microsoft und Anyscale bieten Anyscale on Azure als First-Party-Service an, zugänglich über das Azure Portal.¹³

Anyscale Managed Ray

Anyscale, das von Rays Entwicklern gegründete Unternehmen, bietet verwaltete Ray-Deployments:

Anyscale Platform

Verwaltete Cluster: Produktionstaugliche Ray-Cluster mit automatischer Skalierung, Fehlertoleranz und Monitoring ohne Infrastrukturmanagement.

RayTurbo Runtime: Proprietäre Performance-Verbesserungen, die höhere Resilienz, schnellere Performance und geringere Kosten im Vergleich zu Open-Source Ray liefern.¹⁴

Enterprise-Features: Rollenbasierte Zugriffskontrolle, Audit-Logging, VPC-Peering und Compliance-Zertifizierungen.

Cloud-Partnerschaften

CoreWeave: Anyscale BYOC (Bring Your Own Cloud) deployt direkt in CoreWeave-Kundenkonten über CoreWeave Kubernetes Service.¹⁵

Azure: First-Party Anyscale-Service im Azure Portal mit nativer Integration verfügbar.

AWS: Anyscale betreibt auf AWS mit Integration in bestehende AWS-Services.

Wann Anyscale verwenden

**Anyscale in Betracht ziehen