Plánovanie úloh pre klastre umelej inteligencie: SLURM, Kubernetes, Ray a vedieť, kedy nič z toho nepotrebujete

Plánovač rozhoduje o tom, ktorá úloha sa spustí na ktorých GPU, kedy a na čí úkor. Bez neho sa zdieľaný klaster zvrhne na ľudí, ktorí si navzájom pingujú na Slacku, aby sa opýtali, či niekto používa uzol 3. S nesprávnym plánovačom strávite viac hodín inžinierstva na YAML ako na práci na modeli.

Tento článok porovnáva plánovače, ktoré si ľudia v skutočnosti vyberajú – SLURM, Kubernetes (s Kueue alebo Volcano), Ray a KubeRay a komerčné možnosti Run:ai a Determined – a je úprimný v prípade, keď je správna odpoveď „nič, len SSH“. Publikum si prečítalo K01, K02a K03 a teraz sa rozhoduje, čo umiestniť na klaster s 1–32 uzlami.

Čo vlastne plánovač robí

Tri úlohy, zhruba zoradené podľa náročnosti: umiestniť prácu na voľné zdroje, zaradiť do fronty prácu, ktorá sa ešte nezmestí, a koordinovať úlohy s viacerými uzlami – distribuované trénovanie vyžaduje, aby všetkých N úrovní začalo naraz (plánovanie gangov), pretože PyTorch dist.barrier() blokuje na neurčito, ak sa jedna hodnosť nikdy neobjaví (pozri K06).

Čokoľvek nad rámec klastra s jedným tímom vyžaduje aj kvóty pre viacerých nájomcov s požičiavaním, spravodlivým rozdeľovaním medzi tímami, preempciou a správnym účtovaním GPU (aby úloha videla CUDA_VISIBLE_DEVICES (nastavené správne). Každý plánovač nižšie vykonáva prvé tri. Rozdiel je v druhom zozname a v tom, aký druh práce predpokladajú, že spúšťate.

Veľký rozkol: dávkové úlohy verzus dlhodobo spúšťané služby

Toto je najdôležitejšie rámovanie. Dávkové úlohy trénovať 8 hodín a ukončiť, alebo spustiť hyperparam sweep 200 krátkych úloh, alebo spracovať dataset cez noc — začiatok, koniec, výsledok, nič neodpovedá HTTP. Dlhodobo prevádzkované služby sú koncový bod vLLM obsluhujúci inferenciu 24 hodín denne, 7 dní v týždni, databáza scénickej pamäte, monitorovací zásobník – ktorý má zostať v prevádzke navždy a reštartovať sa pri havárii.

SLURM bol vytvorený pre dávkové riešenia. Kubernetes bol vytvorený pre dlhodobé služby. Všetko ostatné je len jedna z dvoch možností, ktoré sa rozširujú, aby robili druhú polovicu.

Ak váš klaster robí iba jednu z týchto vecí, voľba je jednoduchá. Ak robí obe – čo je čoraz bežnejšie – otázkou je, za ktorý plánovač ste ochotní platiť prevádzkovú daň.

SLURM — predvolená HPC konfigurácia, ktorá stále vyhráva pri čistom tréningu

SLURM prevádzkuje viac ako 65 % superpočítačov z TOP 500 a väčšinu publikovaných hraničných tréningových behov. Pre úlohy, ktoré vyzerajú ako „odoslať tréningovú úlohu, počkať na výsledky, získať kontrolný bod“, je to už dvadsať rokov správna odpoveď.

Mentálny model je jednoduchý: a rozdelenie je pomenovaný fond uzlov (gpu-5090, cpu-only, bigmem); do zamestnania je shellový skript s #SBATCH smernice, predložené s sbatch; GRES (Generic RESources) sleduje GPU — --gres=gpu:rtxpro6000:2 žiada dve konkrétne karty; plánovanie gangov je zabudovaný.

Minimálny slurm.conf pre 4-uzlový klaster s 8× RTX Pro 6000 Blackwell na uzol:

ClusterName=kentino-lab
SlurmctldHost=head01

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

# GPU accounting — without these two lines, fair-share runs on CPU-seconds and is meaningless
AccountingStorageType=accounting_storage/slurmdbd
AccountingStorageTRES=gres/gpu
PriorityType=priority/multifactor
PriorityDecayHalfLife=7-0
PriorityWeightFairshare=10000
PriorityWeightAge=1000

# cgroups isolate the GPUs a job is allowed to see
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

Zhoda gres.conf na každom uzle:

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

AutoDetect=nvml priamo dotazuje knižnicu NVIDIA Management Library, automaticky načítava segmenty MIG a ušetrí vám ručné nastavovanie ciest k súborom zariadení.

Používateľ odošle:

#!/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 a SLURM sa skladajú čisto: SLURM vlastní alokáciu, srun spustí jeden proces na úlohu, torch.distributed.run plus backend stretnutia spracováva priradenie poradia. Pri odstraňovaní uzla, --max-restarts on torchrun plus --requeue on #SBATCH zotaví sa z posledného kontrolného bodu. Každý to takto beží.

Čo získate zadarmo: plánovanie gangov, spravodlivé zdieľanie, dopĺňanie, účtovníctvo (každá sekunda GPU zaznamenaná do sacct) a jednoduchá sémantika – žiadne CRD, žiadny kontrolér, žiadny graf objektov YAML. Čo nezískate: dlhodobo bežiace služby s automatickým reštartom, HTTP ingress, priebežné aktualizácie, sidecar kontajnery, deklaratívny stav. SLURM je dávkový plánovač. Zaobchádzanie s ním ako s Kubernetes bude škodlivé.

SLURM má pravdu, keď: spúšťate tréning, dávkovú inferenciu alebo simuláciu; používatelia píšu shell skripty; môže ho obsluhovať jeden SRE na čiastočný úväzok.

Kde SLURM dosiahne svoj vrchol

Tri miesta. Služby v webovom štýle — žiadny koncept „spustiť navždy, reštartovať po smrti, sprístupniť port 8000“. Môžete vtesnať vLLM do dlhotrvajúcej úlohy SLURM, ale kontrola stavu, priebežné aktualizácie a vyvažovanie záťaže sa stanú vaším problémom. Heterogénne pracovné zaťaženia — SLURM predpokladá jeden fond zdrojov; klaster s trénovaním + inferenciou + Jupyter + monitorovaním + prípravou dát vyžaduje jemnejšie odstupňované kontroly. Prísna izolácia viacerých nájomníkov — cgroups izolujú CPU a pamäť; izolácia GPU závisí od CUDA_VISIBLE_DEVICES a kód používateľa ho rešpektuje. Žiadne menné priestory, žiadna sieťová politika pre jednotlivé úlohy, žiadna kontajnerová tenancia. Vhodné pre laboratóriá; nie vhodné pre hosťovanú službu pre viacerých zákazníkov.

Keď narazíte na niektorú z nich, správnym krokom je zvyčajne pridanie druhej vrstvy – Kubernetes pre služby – namiesto mučenia SLURM. Spravované ponuky SUNK a 2026 od CoreWeave používajú SLURM. on Kubernetes, takže ten istý klaster robí oboje. V mierke Kentino sú dva samostatné malé klastre často jednoduchšie.

Kubernetes pre AI: cloudovo natívna cesta

Kubernetes bol vytvorený tak, aby udržiaval prevádzku webových služieb bez štátnej príslušnosti. Pre klastre AI je „všetko ostatné“ integrované. Stack 2026: Operátor grafického procesora NVIDIA (ovládače, CUDA, NCCL, DCGM, plugin zariadenia, konfigurácia MIG), Kueue (rad, kvóta, vstupné), Sopka (dávkovo riadený plánovač), Tréner Kubeflow (PyTorchJob, TFJob, MPIJob CRD), KubeRay (Ray na K8) a Karpenter alebo Automatické škálovanie klastra na poskytovanie uzlov.

Prečo je naivný Kubernetes pre AI nesprávny: predvolený kube-scheduler je FIFO bez sémantiky gangov. Rád spustí 7 z 8 podov distribuovanej tréningovej úlohy a ôsmy nechá čakajúci, zatiaľ čo bežiacich 7 drží GPU nečinné. Toto nie je teoretické – je to najčastejšia chyba, ktorú tímy robia, keď sa snažia spustiť tréning na klastri, ktorý vytvorili pre inferenciu. Opravy sú Kueue (prístup na úrovni úlohy) a Volcano (umiestnenie gangov na úrovni podu). Súčasná osvedčená prax je oboje: Kueue hore, Volcano pod ním.

Sopka

Volcano je dávkový plánovač CNCF, ktorý sa inštaluje spolu s kube-schedulerom alebo namiesto neho. Pridáva skutočné skupinové plánovanie s minAvailable sémantika (pripustenie nuly alebo N, nikdy nie čiastočné), priority a preempcia frontu, stratégie spravodlivého zdieľania / binpack / topológie a prvotriedna podpora pre PyTorchJob, TFJob, MPIJob, RayJob a SparkApplication.

Minimálny front plus skupinovo naplánovaná tréningová úloha PyTorch:

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: all 16 ranks or zero
  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"]

Keď to urobíte nie Potrebujem Volcano: čisto inferenčný klaster s nezávislými nasadeniami vLLM. Každý pod vlastní svoje GPU, žiadna koordinácia medzi podmi, predvolený kube-scheduler je v poriadku. Volcano si zaslúži svoje miesto v momente, keď do klastra primiešate distribuované trénovanie.

Kueue a pôžičky z kvót

Kueue spracováva vrstvu, ktorú Volcano nie: kto môže spotrebovať akú časť klastra a čo sa stane, keď je jeden tím nečinný.

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

Oba tímy v kohorte majú garantovaných 16 GPU a môžu si požičať až 8 z nečinného fondu toho druhého. Práca s vysokou prioritou predchádza požičanej kapacite. Plán Kueue do roku 2026 sa zameriava na MultiKueue (dispečing viacerých klastrov) a kooperatívnu preempciu – úlohe kontrolného bodu možno povedať „uložiť stav a spustiť do 60 sekúnd“, namiesto toho, aby bola priamo ukončená.

Zdieľanie MIG a GPU

Plugin pre zariadenia NVIDIA predvolene alokuje celý grafický procesor. Pre trénovanie a rozsiahle inferencie je to správne; pre malé inferencie, notebooky alebo vývojovú prácu je to nehospodárne. Tri režimy zdieľania: MIG (izolácia hardvérovej pamäte a porúch, inferencia pre viacerých nájomcov v produkcii), MPS (kooperatívne, bez izolácie), časové rozdelenie (bez izolácie, iba pre vývojárov).

MIG existuje na H100/H200, A100 a B200 – nie na žiadnej GPU v rade Kentino. RTX 5090, RTX 4090, RTX Pro 6000 Blackwell, L40, L4 nepodporujú MIG. Ak váš návrh vyžaduje hardvérovo izolované GPU partície, obmedzí to váš hardvér na SXM/dátové centrá. Kentino nezostavuje. Časové delenie inzeruje N virtuálnych GPU na fyzickú GPU a plánovač nemá tušenie, že sú preplnené – použite ho iba pre vývojárov.

V čom je Kubernetes dobrý: dlhodobé inferenčné služby (nasadenia vLLM škálované pomocou HPA na základe hĺbky frontu, priebežné aktualizácie, kontroly stavu – SLURM nemá nič porovnateľné), heterogénne pracovné záťaže na jednom klastri, ekosystém (Prometheus, Grafana, Argo). Za čo platíte: funkčný K8s + GPU Operator + Kueue + Volcano + Kubeflow stack pozostáva z minimálne 20 komponentov. Realistický odhad: Kubernetes je 5–10× prevádzkové zaťaženie SLURM pre čisto dávkové trénovanie.

Kubernetes je tou správnou voľbou, keď: Klaster prevádzkuje inferenčné služby popri školení, máte platformový tím, deklaratívne je všetko dôležité alebo potrebujete prenositeľnosť viacerých klastrov.

Ray a KubeRay — distribuované výpočty natívne v Pythone

Ray je iná vec. Nie je to v skutočnosti plánovač klastrov v zmysle SLURM/K8s – je to distribuované behové prostredie Pythonu, ktoré sa dodáva s plánovačom, úložiskom objektov a automatickým škálovaním. Python píšete s... @ray.remote dekoratérov a Ray zisťuje, kde spustiť každú úlohu.

Kam sa Ray hodí: ladenie hyperparametrov (Ray Tune – stovky paralelných pokusov, včasné odstránenie zlých; prípad použitia, pre ktorý bol Ray vytvorený a stále najlepší vo svojej triede), posilňovanie učenia (RLlib — prostredia a študenti ako aktéri, ktoré sa jasne mapujú na Ray a zle na dávkové úlohy SLURM), distribuované školenie (Ray Train, obalujúci PyTorch DDP / FSDP / DeepSpeed), zobrazovanie modelu (Ray Serve, natívne pre Python, vlastné viacmodelové pipeline) a predspracovanie údajov (Ray Data). Čo Ray nie je: dávkový plánovač pre viacero nájomcov pre zdieľaný klaster. Ray predpokladá, že klaster vlastní jedna aplikácia.

KubeRay je operátor, ktorý prevádzkuje Ray na Kubernetes. Tri CRD: RayCluster (dlhoveký), RayJob (jednorazový), RayService (Ray Serve, priebežné aktualizácie). Minimálny 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 automaticky škáluje skupinu pracovníkov medzi minReplicas a maxReplicas na základe Rayovho pohľadu na čakajúce úlohy. V kombinácii s Kueue (plánovanie skupín RayJob + Kueue je zdokumentované a funguje) získate viacnájomnícky Ray na viacnájomníckom klastri K8s – produkčné nastavenie, ktoré väčšina „Ray shopov“ skutočne prevádzkuje.

Keď má Ray samostatný systém (bez K8s) pravdu: malé výskumné laboratórium, kde jedna osoba vlastní klaster, dynamika je dôležitejšia ako viacnásobné prenájmy, pracovná záťaž je vysoká v oblasti RL alebo vyhľadávania hyperparametrov. Hybrid, na ktorom sa väčšina tímov zhoduje: SLURM alebo K8s ako základná vrstva, ktorá vlastní uzly a viacero prenajímateľov; Ray spustený v rámci úlohy SLURM alebo menného priestoru K8s počas trvania pracovnej záťaže jedného používateľa. Neinštalujte Ray ako plánovač najvyššej úrovne.

Run:ai a Determined – komerčná úroveň

Dve platené ponuky sa objavujú dostatočne často na to, aby sa nimi zaoberali. Obe sa zameriavajú na rovnaký problém: K8s + Volcano + Kueue + GPU Operator je veľa YAML a niektoré organizácie radšej kupujú, ako stavajú.

NVIDIA Spustiť:ai (získané v roku 2024, premenované na 2025) je plánovač GPU natívny pre K8s. Frakcionovanie GPU rozdeľuje jednu GPU medzi pracovné zaťaženia na úrovni pamäte – 0.5 GPU požiadavky, dynamická zmena veľkosti, balenie do priečinkov. Run:ai si zaslúži svoju cenu v podnikových prostrediach s viac ako 10 tímami ML, ktoré súťažia o zdieľané GPU. Pod tým pokrýva Kueue + GPU Operator väčšinu rovnakej oblasti zadarmo.

Determined.AI (HPE, 2021) je platforma pre spravované školenia – sledovanie experimentov, vyhľadávanie hyperparametrov, správa kontrolných bodov, distribuované školenia v jednom produkte. Najlepšie sa hodí pre výskumné tímy, ktoré chcú prepracovaný dashboard bez toho, aby museli integrovať päť nástrojov.

Problém s interaktívnym notebookom

Vzor, ktorý sa prejavuje takmer v každom zdieľanom klastri GPU: výskumníci chcú, aby JupyterHub mal prístup k GPU pre vývoj a to musí koexistovať s dlhodobými tréningovými úlohami, ktoré obsahujú celé uzly. Naivná odpoveď – jedna vyhradená GPU na notebook – premárni 80 % klastra. Striktná odpoveď – nechať výskumníkov... sbatch všetko – presúva ich na notebooky s hračkárskymi modelmi.

Tri funkčné vzory: Slurm salloc + Jupyter o alokácii (salloc --gres=gpu:1 --time=4:00:00, spustite server Jupyter na alokovanom uzle, tunelujte; fixný časový limit, správne započítaná GPU – najčistejšia odpoveď pre klaster SLURM), Kubernetes + JupyterHub + Kueue (pody notebookov cez front s nízkou prioritou, tréningové úlohy prepínajú nečinné notebooky) alebo Spustiť:ai s frakcionovaním na GPU (notebooky dostanú 0.25 / 0.5 GPU). Nech si vyberiete čokoľvek, nastaviť časový limit pre interaktívne stretnutia — notebook bez časového limitu je grafická karta trvalo vyradená z klastra.

Realita úprimného malého tímu

Väčšina online obsahu o plánovačoch predpokladá klaster s 256 GPU a tím platformy. Realistický zákazník Kentina sa bližšie blíži k 1–4 uzlom, 4–32 GPU celkovo, 2–6 používateľom, ktorí sa navzájom poznajú a koordinovanému používaniu Slack. Pre toto nastavenie, nepotrebujete plánovač.

# user 1
ssh node01
tmux new -s my-training
CUDA_VISIBLE_DEVICES=0,1,2,3 python train.py
# Ctrl-B D to detach

# user 2 — coordinates on Slack first
ssh node01
nvidia-smi                              # which GPUs are free?
tmux new -s other-training
CUDA_VISIBLE_DEVICES=4,5,6,7 python train.py

To je celý systém plánovania úloh. SLURM sa začína vyplácať pri približne 16 GPU alebo 8 používateľoch, podľa toho, čo nastane skôr. Pod touto hranicou prevádzkové náklady prevyšujú hodnotu. Nainštalujte plánovač, keď zlyháva ľudská koordinácia, nie skôr.

Kedy sa každý nástroj hodí – zhrnutie

---

Toto je súčasť Kentino Wiki, referenčnej série o umelej inteligencii, robotike a systémoch, ktoré ich spájajú. Komentáre a opravy sú vítané na info@kentino.com.