Job-Scheduling für KI-Cluster: SLURM, Kubernetes, Ray – und wann Sie nichts davon brauchen

Ein Scheduler entscheidet, welcher Job auf welchen GPUs läuft, wann und auf wessen Kosten. Ohne Scheduler verkommt ein geteilter Cluster zu Leuten, die sich gegenseitig auf Slack anschreiben, ob gerade jemand Knoten 3 benutzt. Mit dem falschen Scheduler stecken Sie mehr Entwicklerstunden in YAML als in Modellarbeit.

Dieser Artikel vergleicht die Scheduler, die tatsächlich gewählt werden — SLURM, Kubernetes (mit Kueue oder Volcano), Ray und KubeRay sowie die kommerziellen Optionen Run:ai und Determined — und ist ehrlich in dem Fall, in dem die richtige Antwort „gar keiner, einfach SSH“ lautet. Die Zielgruppe hat K01, K02, und K03 gelesen und entscheidet nun, was auf einem Cluster mit 1–32 Knoten laufen soll.

Was ein Scheduler tatsächlich tut

Drei Aufgaben, grob nach Schwierigkeit sortiert: Arbeit auf freien Ressourcen platzieren, Arbeit einreihen, die noch nicht passt, und Jobs über mehrere Knoten koordinieren — verteiltes Training braucht alle N Ranks gleichzeitig (Gang Scheduling), denn ein PyTorch- dist.barrier() blockiert unbegrenzt, wenn ein Rank nie erscheint (siehe K06).

Alles jenseits eines Ein-Team-Clusters braucht zusätzlich mandantenfähige Quoten mit Leihmöglichkeit, Fair-Share-Abklingen über Teams hinweg, Preemption und eine saubere GPU-Buchhaltung (damit der Job CUDA_VISIBLE_DEVICES korrekt gesetzt sieht). Jeder Scheduler unten erledigt die ersten drei Punkte. Unterschiede gibt es bei der zweiten Liste und darin, welche Art von Arbeit sie voraussetzen.

Die große Trennlinie: Batch-Jobs gegen Dauerdienste

Das ist die mit Abstand wichtigste Einordnung. Batch-Jobs trainieren acht Stunden und beenden sich, fahren einen Hyperparameter-Sweep aus 200 kurzen Jobs oder verarbeiten über Nacht einen Datensatz — Start, Ende, Ergebnis, nichts beantwortet HTTP. Dauerdienste sind ein vLLM-Endpunkt, der rund um die Uhr Inferenz liefert, eine Scene-Memory-Datenbank, ein Monitoring-Stack — sie sollen für immer laufen und nach einem Absturz neu starten.

SLURM wurde für Batch gebaut. Kubernetes wurde für Dauerdienste gebaut. Alles andere ist eine der beiden Welten, gedehnt, um die jeweils andere Hälfte mitzumachen.

Macht Ihr Cluster nur eines dieser Dinge, ist die Wahl einfach. Macht er beides — was zunehmend normal ist —, lautet die Frage, bei welchem Scheduler Sie bereit sind, die Betriebssteuer zu zahlen.

SLURM — der HPC-Standard, der für reines Training weiterhin gewinnt

SLURM betreibt mehr als 65 % der TOP500-Supercomputer und die meisten veröffentlichten Frontier-Trainingsläufe. Für Workloads nach dem Muster „Trainingsjob absenden, Ergebnis abwarten, Checkpoint abholen“ ist es seit zwanzig Jahren die richtige Antwort.

Das gedankliche Modell ist simpel: Eine Partition ist ein benannter Pool von Knoten (gpu-5090, cpu-only, bigmem); ein Job ist ein Shell-Skript mit #SBATCH -Direktiven, abgeschickt mit sbatch; GRES (Generic RESources) verwaltet GPUs — --gres=gpu:rtxpro6000:2 fordert zwei bestimmte Karten an; Gang Scheduling ist eingebaut.

Eine minimale slurm.conf für einen Cluster mit vier Knoten und 8× RTX Pro 6000 Blackwell pro Knoten:

ClusterName=kentino-lab
SlurmctldHost=head01

SchedulerType=sched/backfill
SelectType=select/cons_tres
SelectTypeParameters=CR_Core_Memory
GresTypes=gpu

# GPU-Accounting — ohne diese beiden Zeilen läuft Fair-Share auf CPU-Sekunden und ist sinnlos
AccountingStorageType=accounting_storage/slurmdbd
AccountingStorageTRES=gres/gpu
PriorityType=priority/multifactor
PriorityDecayHalfLife=7-0
PriorityWeightFairshare=10000
PriorityWeightAge=1000

# cgroups isolieren die GPUs, die ein Job sehen darf
ProctrackType=proctrack/cgroup

NodeName=node[01-04] CPUs=128 RealMemory=1024000 Sockets=2 \
    CoresPerSocket=64 ThreadsPerCore=1 Gres=gpu:rtxpro6000:8 State=UNKNOWN

PartitionName=train Nodes=node[01-03] Default=YES MaxTime=48:00:00 State=UP
PartitionName=interactive Nodes=node04 MaxTime=04:00:00 \
    PriorityTier=10 State=UP

Die passende gres.conf auf jedem Knoten:

AutoDetect=nvml
NodeName=node[01-04] Name=gpu Type=rtxpro6000 File=/dev/nvidia[0-7]

AutoDetect=nvml fragt die NVIDIA Management Library direkt ab, erkennt MIG-Slices automatisch und erspart Ihnen das Zusammensuchen von Gerätedateipfaden.

Ein Nutzer schickt ab:

#!/bin/bash
#SBATCH --job-name=qwen-finetune
#SBATCH --partition=train
#SBATCH --nodes=2
#SBATCH --ntasks-per-node=8
#SBATCH --gres=gpu:rtxpro6000:8
#SBATCH --time=12:00:00
#SBATCH --output=logs/%j.out

srun python -m torch.distributed.run \
    --nnodes=2 --nproc-per-node=8 \
    --rdzv-backend=c10d \
    --rdzv-endpoint=$(scontrol show hostnames | head -1):29500 \
    train.py --config configs/qwen72b.yaml

PyTorch Elastic und SLURM greifen sauber ineinander: SLURM besitzt die Allokation, srun startet einen Prozess pro Task, torch.distributed.run plus Rendezvous-Backend übernimmt die Rang-Zuteilung. Fällt ein Knoten aus, sorgen --max-restarts an torchrun plus --requeue an #SBATCH für die Wiederaufnahme ab dem letzten Checkpoint. So macht es jeder.

Was Sie kostenlos bekommen: Gang Scheduling, Fair-Share-Abklingen, Backfill, Accounting (jede GPU-Sekunde landet in sacct) und einfache Semantik — keine CRDs, kein Controller, kein YAML-Objektgraph. Was Sie nicht bekommen: Dauerdienste mit automatischem Neustart, HTTP-Ingress, Rolling Updates, Sidecar-Container, deklarativen Zustand. SLURM ist ein Batch-Scheduler. Es wie Kubernetes zu behandeln, tut weh.

SLURM ist richtig, wenn: Sie Training, Batch-Inferenz oder Simulation fahren; Nutzer Shell-Skripte schreiben; ein Teilzeit-SRE den Betrieb übernehmen kann.

Wo SLURM an seine Grenzen stößt

An drei Stellen. Webartige Dienste — es gibt kein Konzept für „läuft dauerhaft, startet nach dem Tod neu, öffnet Port 8000“. Sie können vLLM in einen langlaufenden SLURM-Job pressen, aber Health-Checks, Rolling Updates und Lastverteilung werden dann Ihr Problem. Heterogene Workloads — SLURM geht von einem einzigen Ressourcenpool aus; ein Cluster mit Training + Inferenz + Jupyter + Monitoring + Datenaufbereitung will feinere Steuerung. Strikte Mandantentrennung — cgroups isolieren CPU und Arbeitsspeicher; die GPU-Isolation verlässt sich auf CUDA_VISIBLE_DEVICES und darauf, dass der Code des Nutzers sich daran hält. Keine Namespaces, keine Netzwerkrichtlinie pro Job, keine Mandantenfähigkeit auf Container-Niveau. In Ordnung für Labore; nicht in Ordnung für einen gehosteten Mehrkundendienst.

Wenn einer dieser Punkte zutrifft, ist der richtige Schritt meist eine zweite Ebene — Kubernetes für die Dienste — statt SLURM zu überdehnen. CoreWeaves SUNK und die Managed-Angebote von 2026 betreiben SLURM auf Kubernetes, damit derselbe Cluster beides kann. In Kentinos Größenordnung sind zwei getrennte kleine Cluster oft einfacher.

Kubernetes für KI: der Cloud-native Weg

Kubernetes wurde gebaut, um zustandslose Webdienste am Laufen zu halten. Für KI-Cluster wird „alles andere“ drangeschraubt. Der Stack 2026: NVIDIA GPU Operator (Treiber, CUDA, NCCL, DCGM, Device-Plugin, MIG-Konfiguration), Kueue (Warteschlange, Quote, Admission), Volcano (Batch-fähiger Scheduler), Kubeflow Trainer (PyTorchJob-, TFJob-, MPIJob-CRDs), KubeRay (Ray auf K8s) und Karpenter oder Cluster Autoscaler für die Knotenbereitstellung.

Warum naives Kubernetes für KI falsch ist: Der Standard-kube-scheduler arbeitet FIFO ohne Gang-Semantik. Er startet bereitwillig 7 von 8 Pods eines verteilten Trainingsjobs und lässt den achten auf Pending stehen, während die sieben laufenden GPUs blockieren. Das ist nicht theoretisch — es ist der häufigste Fehler, wenn Teams Training auf einem Cluster fahren wollen, den sie für Inferenz gebaut haben. Die Abhilfe heißt Kueue (Admission auf Job-Ebene) und Volcano (Gang-Platzierung auf Pod-Ebene). Heute gilt beides zusammen als Best Practice: Kueue oben, Volcano darunter.

Volcano

Volcano ist ein CNCF-Batch-Scheduler, der neben oder anstelle des kube-scheduler installiert wird. Er bringt echtes Gang Scheduling mit minAvailable -Semantik (null oder N zulassen, nie teilweise), Warteschlangenprioritäten und Preemption, Fair-Share-, Binpack- und topologiebewusste Strategien sowie erstklassige Unterstützung für PyTorchJob, TFJob, MPIJob, RayJob und SparkApplication.

Eine minimale Queue plus ein gang-geplanter PyTorch-Trainingsjob:

apiVersion: scheduling.volcano.sh/v1beta1
kind: Queue
metadata:
  name: training
spec:
  weight: 4
  capability:
    nvidia.com/gpu: 32
---
apiVersion: batch.volcano.sh/v1alpha1
kind: Job
metadata:
  name: qwen-finetune
spec:
  schedulerName: volcano
  minAvailable: 16          # Gang: alle 16 Ranks oder keiner
  queue: training
  policies:
    - event: PodEvicted
      action: RestartJob
  tasks:
    - replicas: 16
      name: worker
      template:
        spec:
          containers:
            - name: pytorch
              image: kentino/pytorch:2.5-cuda13
              resources:
                limits:
                  nvidia.com/gpu: 1
              command: ["torchrun", "--nnodes=16", "--nproc-per-node=1", "train.py"]

Wann Sie Volcano nicht brauchen: bei einem reinen Inferenzcluster mit unabhängigen vLLM-Deployments. Jeder Pod besitzt seine GPUs, keine Koordination zwischen Pods, der Standard-kube-scheduler reicht. Volcano rechnet sich in dem Moment, in dem verteiltes Training dazukommt.

Kueue und geliehene Quoten

Kueue deckt eine Ebene ab, die Volcano nicht abdeckt: wer wie viel vom Cluster verbrauchen darf und was passiert, wenn ein Team untätig ist.

apiVersion: kueue.x-k8s.io/v1beta1
kind: ResourceFlavor
metadata:
  name: rtxpro6000
spec:
  nodeLabels:
    nvidia.com/gpu.product: "RTX-PRO-6000-Blackwell"
---
apiVersion: kueue.x-k8s.io/v1beta1
kind: ClusterQueue
metadata:
  name: team-research
spec:
  cohort: "shared-gpu"
  resourceGroups:
    - coveredResources: ["nvidia.com/gpu"]
      flavors:
        - name: rtxpro6000
          resources:
            - name: "nvidia.com/gpu"
              nominalQuota: 16
              borrowingLimit: 8

Beide Teams in der Kohorte bekommen 16 GPUs garantiert und können bis zu 8 aus dem ungenutzten Pool des anderen leihen. Arbeit mit hoher Priorität verdrängt geliehene Kapazität. Die Kueue-Roadmap 2026 setzt auf MultiKueue (Verteilung über mehrere Cluster) und kooperative Preemption — einem Job mit Checkpointing kann man sagen „sichere den Zustand und gib in 60 Sekunden ab“, statt ihn hart zu beenden.

MIG und GPU-Sharing

Das NVIDIA-Device-Plugin vergibt standardmäßig ganze GPUs. Für Training und große Inferenz ist das korrekt; für kleine Inferenz, Notebooks oder Entwicklungsarbeit ist es Verschwendung. Drei Sharing-Modi: MIG (Hardware-Isolation von Speicher und Fehlern, produktive mandantenfähige Inferenz), MPS (kooperativ, keine Isolation), Time-Slicing (keine Isolation, nur für Entwicklung).

MIG gibt es auf H100/H200, A100 und B200 — auf keiner GPU im Kentino-Portfolio. RTX 5090, RTX 4090, RTX Pro 6000 Blackwell, L40 und L4 unterstützen kein MIG. Wenn Ihr Design hardwareisolierte GPU-Partitionen verlangt, schränkt das die Hardware auf SXM-/Rechenzentrumskarten ein, die Kentino nicht baut. Time-Slicing meldet N virtuelle GPUs pro physischer GPU, und der Scheduler weiß nicht, dass sie überbucht sind — nutzen Sie es nur für Entwicklung.

Worin Kubernetes gut ist: langlaufende Inferenzdienste (vLLM-Deployments, per HPA nach Warteschlangentiefe skaliert, Rolling Updates, Health-Checks — dafür hat SLURM nichts Vergleichbares), heterogene Workloads auf einem Cluster, Ökosystem (Prometheus, Grafana, Argo). Was Sie zahlen: Ein funktionierender Stack aus K8s + GPU Operator + Kueue + Volcano + Kubeflow besteht aus mindestens 20 Komponenten. Realistische Schätzung: Kubernetes bedeutet die 5- bis 10-fache Betriebslast von SLURM für reines Batch-Training.

Kubernetes ist die richtige Wahl, wenn: der Cluster Inferenzdienste neben dem Training betreibt, Sie ein Plattformteam haben, alles deklarativ sein soll oder Sie Portabilität über mehrere Cluster brauchen.

Ray und KubeRay — verteiltes Rechnen nativ in Python

Ray ist ein anderes Kaliber. Es ist eigentlich kein Cluster-Scheduler im Sinne von SLURM oder K8s — es ist eine verteilte Python-Laufzeitumgebung, die einen Scheduler, einen Object Store und einen Autoscaler mitbringt. Sie schreiben Python mit @ray.remote -Dekoratoren, und Ray entscheidet, wo jede Aufgabe läuft.

Wo Ray passt: Hyperparameter-Tuning (Ray Tune — hunderte Versuche parallel, schlechte früh abbrechen; der Anwendungsfall, für den Ray gebaut wurde, und bis heute Klassenbester), Reinforcement Learning (RLlib — Umgebungen und Learner als Actors, was sauber auf Ray abbildet und schlecht auf SLURM-Batch-Jobs), verteiltes Training (Ray Train, als Hülle um PyTorch DDP / FSDP / DeepSpeed), Model Serving (Ray Serve, Python-nativ, eigene Multi-Modell-Pipelines) und Datenvorverarbeitung (Ray Data). Was Ray nicht ist: ein mandantenfähiger Batch-Scheduler für einen geteilten Cluster. Ray geht davon aus, dass eine Anwendung den Cluster besitzt.

KubeRay ist der Operator, der Ray auf Kubernetes betreibt. Drei CRDs: RayCluster (langlebig), RayJob (einmalig), RayService (Ray Serve, Rolling Updates). Ein minimaler RayCluster:

apiVersion: ray.io/v1
kind: RayCluster
metadata:
  name: rl-cluster
spec:
  rayVersion: '2.55.0'
  headGroupSpec:
    rayStartParams: { dashboard-host: '0.0.0.0' }
    template:
      spec:
        containers:
          - name: ray-head
            image: rayproject/ray:2.55.0-py311-cu125
            resources:
              limits: { cpu: 8, memory: 32Gi }
  workerGroupSpecs:
    - groupName: gpu-workers
      replicas: 4
      minReplicas: 0
      maxReplicas: 8
      rayStartParams: {}
      template:
        spec:
          containers:
            - name: ray-worker
              image: rayproject/ray:2.55.0-py311-cu125
              resources:
                limits:
                  cpu: 16
                  memory: 128Gi
                  nvidia.com/gpu: 4

KubeRay skaliert die Worker-Gruppe zwischen minReplicas und maxReplicas anhand von Rays Sicht auf die offenen Aufgaben. In Kombination mit Kueue (RayJob + Kueue-Gang-Scheduling ist dokumentiert und funktioniert) bekommen Sie mandantenfähiges Ray auf einem mandantenfähigen K8s-Cluster — genau das Produktionssetup, das die meisten „Ray-Shops“ tatsächlich fahren.

Wann eigenständiges Ray (ohne K8s) richtig ist: in einem kleinen Forschungslabor, in dem eine Person den Cluster besitzt, Dynamik wichtiger ist als Mandantenfähigkeit und der Workload stark auf RL oder Hyperparametersuche liegt. Der Hybrid, auf den die meisten Teams zulaufen: SLURM oder K8s als Basisebene, die Knoten und Mandantenfähigkeit besitzt; Ray gestartet innerhalb eines SLURM-Jobs oder eines K8s-Namespace für die Dauer des Workloads eines Nutzers. Installieren Sie Ray nicht als obersten Scheduler.

Run:ai und Determined — die kommerzielle Klasse

Zwei kostenpflichtige Angebote kommen oft genug zur Sprache, um sie zu behandeln. Beide zielen auf denselben Schmerzpunkt: K8s + Volcano + Kueue + GPU Operator ist eine Menge YAML, und manche Organisationen kaufen lieber, als zu bauen.

NVIDIA Run:ai (2024 übernommen, 2025 umbenannt) ist ein K8s-nativer GPU-Scheduler. GPU-Fractioning teilt eine einzelne GPU auf Speicherebene zwischen Workloads auf — 0.5 GPU -Anforderungen, dynamische Größenänderung, Bin-Packing. Run:ai rechnet sich in Unternehmensumgebungen mit mehr als 10 ML-Teams, die sich geteilte GPUs streitig machen. Darunter deckt Kueue + GPU Operator das meiste davon kostenlos ab.

Determined.AI (HPE, 2021) ist eine verwaltete Trainingsplattform — Experiment-Tracking, Hyperparametersuche, Checkpoint-Verwaltung und verteiltes Training in einem Produkt. Am besten geeignet für Forschungsteams, die ein poliertes Dashboard wollen, ohne selbst fünf Werkzeuge zu integrieren.

Das Problem mit interaktiven Notebooks

Ein Muster, das fast jeden geteilten GPU-Cluster erwischt: Forschende wollen JupyterHub-Zugang zu GPUs für die Entwicklung, und das muss mit langlaufenden Trainingsjobs koexistieren, die ganze Knoten belegen. Die naive Antwort — eine dedizierte GPU pro Notebook — verschwendet 80 % des Clusters. Die strenge Antwort — Forschende sollen alles per sbatch einreichen — treibt sie auf Laptops mit Spielzeugmodellen.

Drei praktikable Muster: SLURM salloc + Jupyter auf der Allokation (salloc --gres=gpu:1 --time=4:00:00, einen Jupyter-Server auf dem zugewiesenen Knoten starten, per Tunnel verbinden; hartes Zeitlimit, GPU sauber verbucht — die sauberste Antwort für einen SLURM-Cluster), Kubernetes + JupyterHub + Kueue (Notebook-Pods über eine Warteschlange niedriger Priorität, Trainingsjobs verdrängen untätige Notebooks) oder Run:ai mit GPU-Fractioning (Notebooks bekommen je 0.25 / 0.5 GPU). Wofür Sie sich auch entscheiden: Setzen Sie ein Zeitlimit für interaktive Sitzungen — ein Notebook ohne Timeout ist eine GPU, die dauerhaft aus dem Cluster ausscheidet.

Die ehrliche Realität kleiner Teams

Die meisten Scheduler-Texte im Netz setzen einen Cluster mit 256 GPUs und ein Plattformteam voraus. Der realistische Kentino-Kunde liegt eher bei 1–4 Knoten, 4–32 GPUs insgesamt und 2–6 Nutzern, die sich alle kennen und per Slack abstimmen. Für dieses Setup gilt: Sie brauchen keinen Scheduler.

# Nutzer 1
ssh node01
tmux new -s my-training
CUDA_VISIBLE_DEVICES=0,1,2,3 python train.py
# Strg-B D zum Abkoppeln

# Nutzer 2 — stimmt sich zuerst per Slack ab
ssh node01
nvidia-smi                              # welche GPUs sind frei?
tmux new -s other-training
CUDA_VISIBLE_DEVICES=4,5,6,7 python train.py

Das ist das gesamte Job-Scheduling-System. SLURM fängt bei etwa 16 GPUs oder 8 Nutzern an, sich zu rentieren — je nachdem, was zuerst eintritt. Darunter übersteigt der Betriebsaufwand den Nutzen. Installieren Sie einen Scheduler, wenn die menschliche Abstimmung versagt — nicht vorher.

Wofür sich welches Werkzeug eignet — die Übersicht

---

Dies ist Teil des Kentino Wiki, einer Referenzreihe über KI-Compute, Robotik und die Systeme, die sie verbinden. Kommentare und Korrekturen willkommen unter info@kentino.com.