Plánování úloh pro AI clustery: SLURM, Kubernetes, Ray a vědět, kdy žádný z nich nepotřebujete

Plánovač rozhoduje o tom, která úloha běží na kterých GPU, kdy a na čí náklady. Bez něj se sdílený cluster zvrhne na lidi, kteří si navzájem pingují na Slacku a ptají se, zda někdo používá uzel č. 3. S nesprávným plánovačem strávíte více inženýrských hodin na YAML než na práci s modelem.

Tento článek porovnává plánovače, které si lidé skutečně vybírají – SLURM, Kubernetes (s Kueue nebo Volcano), Ray a KubeRay a komerční možnosti Run:ai a Determined – a upřímně hovoří o případě, kdy správná odpověď zní „nic, jen SSH“. Publikum četlo K01, K02, a K03 a nyní se rozhoduje, co umístit na cluster s 1–32 uzly.

Co vlastně plánovač dělá

Tři úkoly, zhruba seřazené podle obtížnosti: umístění práce na volné zdroje, zařazení práce do fronty, která se ještě nevejde, a koordinace úloh s více uzly – distribuované trénování vyžaduje, aby všech N úrovní začalo najednou (plánování gangů), protože PyTorch dist.barrier() blokuje na dobu neurčitou, pokud se jedna hodnost nikdy neobjeví (viz K06).

Cokoli nad rámec clusteru s jedním týmem vyžaduje také kvóty pro více klientů s možností výpůjček, spravedlivého rozdělení mezi týmy, preempce a správného účtování GPU (aby úloha viděla CUDA_VISIBLE_DEVICES (nastaveno správně). Každý níže uvedený plánovač provádí první tři. Rozdíl je v druhém seznamu a v tom, jaký druh práce předpokládají, že ji spouštíte.

Velký rozkol: dávkové úlohy vs. dlouhodobě běžící služby

Toto je nejdůležitější rámování. Dávkové úlohy trénovat 8 hodin a ukončit, nebo spustit hyperparam sweep 200 krátkých úloh, nebo zpracovat datovou sadu přes noc — začátek, konec, výsledek, nic neodpovídá HTTP. Dlouhodobě fungující služby jsou koncový bod vLLM obsluhující inferenci 24 hodin denně, 7 dní v týdnu, databáze scénické paměti a monitorovací zásobník – který má zůstat v provozu navždy a při havárii se restartovat.

SLURM byl vytvořen pro dávkové služby. Kubernetes byl vytvořen pro dlouhodobé služby. Všechno ostatní je jen jedna z těch dvou, které se natahují, aby dělaly tu druhou polovinu.

Pokud váš cluster dělá pouze jednu z těchto věcí, je volba snadná. Pokud dělá obě – což je stále běžnější – otázkou je, za který plánovač jste ochotni platit provozní daň.

SLURM — výchozí HPC, který stále vítězí v oblasti čistého tréninku

SLURM provozuje více než 65 % superpočítačů z TOP 500 a většinu publikovaných hraničních trénovacích běhů. Pro úlohy, které vypadají jako „odeslat tréninkovou úlohu, počkat na výsledky, získat kontrolní bod“, je to už dvacet let správná odpověď.

Mentální model je jednoduchý: a rozdělení je pojmenovaný fond uzlů (gpu-5090, cpu-only, bigmem); A práce je shellový skript s #SBATCH směrnice, předložené s sbatch; GRES (Generic RESources) sleduje GPU — --gres=gpu:rtxpro6000:2 požaduje dvě konkrétní karty; plánování gangů je zabudovaný.

Minimální slurm.conf pro cluster se 4 uzly s 8× RTX Pro 6000 Blackwell na uzel:

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

Shoda gres.conf na každém uzlu:

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

AutoDetect=nvml přímo dotazuje knihovnu NVIDIA Management Library, automaticky načítá řezy MIG a ušetří vám ruční nastavování cest k souborům zařízení.

Uživatel odeš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 se čistě komponují: SLURM vlastní alokaci, srun spustí jeden proces na úlohu, torch.distributed.run plus backend pro setkání zpracovává přiřazení pořadí. Při odebrání uzlu, --max-restarts on torchrun Plus --requeue on #SBATCH zotavuje se z posledního kontrolního bodu. Všichni to takhle běží.

Co získáte zdarma: plánování skupin, spravedlivé rozdělení, doplňování, účtování (každá sekunda GPU zaznamenaná do sacct) a jednoduchou sémantiku – žádné CRD, žádný kontrolery, žádný graf objektů YAML. Co nezískáte: dlouhodobě běžící služby s automatickým restartem, HTTP ingress, průběžné aktualizace, sidecar kontejnery, deklarativní stav. SLURM je dávkový plánovač. Zacházet s ním jako s Kubernetes bude škodlivé.

SLURM má pravdu, když: Spouštíte trénování, dávkovou inferenci nebo simulaci; uživatelé píší shellové skripty; může to obsluhovat jeden SRE na částečný úvazek.

Kde SLURM dosáhne svého stropu

Tři místa. Služby ve webovém stylu — žádný koncept „běžet navždy, restartovat po smrti, zpřístupnit port 8000“. Můžete vLLM nacpat do dlouhodobě běžící úlohy SLURM, ale kontrola stavu, průběžné aktualizace a vyvažování zátěže se stanou vaším problémem. Heterogenní pracovní zátěže — SLURM předpokládá jeden fond zdrojů; cluster s trénováním + inferencí + Jupyterem + monitorováním + přípravou dat vyžaduje jemněji odstupňované kontroly. Přísná izolace pro více klientů — cgroups izolují CPU a paměť; izolace GPU závisí na CUDA_VISIBLE_DEVICES a uživatelský kód, který jej respektuje. Žádné jmenné prostory, žádná síťová politika pro jednotlivé úlohy, žádný tenancy na úrovni kontejneru. Vhodné pro laboratoře; ne vhodné pro hostovanou službu pro více zákazníků.

Když narazíte na některou z nich, správným krokem je obvykle přidání druhé vrstvy – Kubernetes pro služby – spíše než mučení SLURM. Spravované nabídky SUNK a 2026 od CoreWeave běží na SLURM. on Kubernetes, takže stejný cluster dělá obojí. V měřítku Kentina jsou dva oddělené malé clustery často jednodušší.

Kubernetes pro AI: cesta do cloudu

Kubernetes byl vytvořen tak, aby umožňoval běh webových služeb bez stavové definice. Pro clustery s umělou inteligencí je „všechno ostatní“ integrováno. Stack 2026: Operátor grafického procesoru NVIDIA (ovladače, CUDA, NCCL, DCGM, plugin zařízení, konfigurace MIG), Kueue (fronta, kvóta, vstupné), Sopka (dávkově řízený plánovač), Trenér Kubeflow (PyTorchJob, TFJob, MPIJob CRD), KubeRay (Ray na K8) a Karpenter nebo Automatické škálování clusteru pro zřizování uzlů.

Proč se naivní Kubernetes pro AI mýlí: výchozí kube-scheduler je FIFO bez sémantiky gangů. Rád spustí 7 z 8 podů distribuované trénovací úlohy a osmý nechá čekající, zatímco běžících 7 drží GPU nečinné. Nejde o teorii – je to nejčastější chyba, které se týmy dopouštějí, když se snaží spustit trénování na clusteru, který vytvořily pro inferenci. Opravy jsou Kueue (přístup na úrovni úlohy) a Volcano (umístění gangů na úrovni podu). Aktuální osvědčená praxe je obojí: Kueue nahoře, Volcano dole.

Sopka

Volcano je dávkový plánovač CNCF, který se instaluje společně s kube-schedulerem nebo místo něj. Přidává skutečné skupinové plánování s... minAvailable sémantika (přiznává nulu nebo N, nikdy částečné), priority front a preempce, strategie fair-share / binpack / s ohledem na topologii a prvotřídní podpora pro PyTorchJob, TFJob, MPIJob, RayJob a SparkApplication.

Minimální fronta plus skupinově naplánovaná školicí ú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"]

Když to uděláte ne Potřebuji Volcano: čistě inferenční cluster s nezávislými nasazeními vLLM. Každý pod vlastní své GPU, žádná koordinace mezi pody, výchozí kube-scheduler je v pořádku. Volcano si své místo vyslouží v okamžiku, kdy do clusteru přimícháte distribuované školení.

Kueue a půjčky z kvót

Kueue zpracovává vrstvu, kterou Volcano ne: kdo smí spotřebovat kolik clusteru a co se stane, když 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 kohortě mají garantovaných 16 GPU a mohou si půjčit až 8 z nečinného poolu druhého týmu. Práce s vysokou prioritou předchází vypůjčené kapacitě. Plán Kueue pro rok 2026 se zaměřuje na MultiKueue (dispečink z více clusterů) a kooperativní preempci – úloha kontrolního bodu může být instruována „uložit stav a vrátit se za 60 sekund“, místo aby byla rovnou ukončena.

Sdílení MIG a GPU

Plugin pro zařízení NVIDIA standardně alokuje celou grafickou kartu. Pro trénování a rozsáhlou inferenci je to správné; pro malou inferenci, poznámkové bloky nebo vývojářskou práci je to zbytečné. Tři režimy sdílení: MIG (izolace hardwarové paměti a chyb, inference pro vícenájemce v produkčním prostředí), MPS (družstevní, bez izolace), časové krájení (bez izolace, pouze pro vývojáře).

MIG existuje na H100/H200, A100 a B200 – nikoli na žádném GPU z řady Kentino. RTX 5090, RTX 4090, RTX Pro 6000 Blackwell, L40, L4 nepodporují MIG. Pokud váš návrh vyžaduje hardwarově izolované oddíly GPU, omezí to váš hardware na části SXM/datová centra. Kentino nesestavuje. Časové rozdělení inzeruje N virtuálních GPU na fyzickou GPU a plánovač netuší, že jsou přeplněné – používejte ho pouze pro vývoj.

V čem je Kubernetes dobrý: dlouhodobé inferenční služby (vLLM Deployments škálované HPA na hloubce fronty, průběžné aktualizace, kontroly stavu – SLURM nemá nic srovnatelného), heterogenní úlohy na jednom clusteru, ekosystém (Prometheus, Grafana, Argo). Za co platíte: funkční K8s + GPU Operator + Kueue + Volcano + Kubeflow stack s minimálně 20 komponentami. Realistický odhad: Kubernetes je 5–10× provozní zátěž SLURM pro čistě dávkové trénování.

Kubernetes je správná volba, když: Cluster provozuje inferenční služby spolu se školením, máte platformní tým, deklarativní princip „všechno je důležité“ nebo potřebujete přenositelnost mezi více clustery.

Ray a KubeRay — distribuované výpočty nativní pro Python

Ray je jiná věc. Není to ve skutečnosti plánovač clusterů ve smyslu SLURM/K8s – je to distribuovaný běhový modul Pythonu, který je dodáván s plánovačem, úložištěm objektů a automatickým škálováním. Python píšete s… @ray.remote dekoratéři a Ray vymýšlí, kde spustit každý úkol.

Kam se Ray hodí: ladění hyperparametrů (Ray Tune – stovky paralelních pokusů, odstraňování těch špatných včas; případ použití, pro který byl Ray stvořen, a stále nejlepší ve své třídě), posilování učení (RLlib — prostředí a studenti jako aktéři, což se jasně mapuje na Ray a špatně na dávkové úlohy SLURM), distribuované školení (Ray Train, obalující PyTorch DDP / FSDP / DeepSpeed), modelové obsluhování (Ray Serve, nativní Python, vlastní vícemodelové kanály) a předzpracování dat (Ray Data). Co Ray není: dávkový plánovač pro sdílený cluster s více klienty. Ray předpokládá, že cluster vlastní jedna aplikace.

KubeRay je operátor, který provozuje Ray na Kubernetes. Tři CRD: RayCluster (dlouhověký), RayJob (jednorázový), RayService (Ray Serve, průběžné aktualizace). Minimální 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íků mezi minReplicas a maxReplicas na základě Rayova pohledu na čekající úkoly. V kombinaci s Kueue (skupinové plánování RayJob + Kueue je zdokumentováno a funguje) získáte víceklientský Ray na víceklientském clusteru K8s – produkční nastavení, které většina „Rayových dílen“ skutečně provozuje.

Když má Ray samostatný systém (bez K8s) pravdu: malá výzkumná laboratoř, kde jeden člověk vlastní cluster, dynamika je důležitější než multitenancy, pracovní zátěž je vysoká v oblasti RL nebo vyhledávání hyperparametrů. Hybridní systém, na kterém se většina týmů shoduje: SLURM nebo K8s jako základní vrstva, která vlastní uzly a multitenancy; Ray spouštěný uvnitř úlohy SLURM nebo jmenného prostoru K8s po dobu trvání pracovní zátěže jednoho uživatele. Neinstalujte Ray jako plánovač nejvyšší úrovně.

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

Dost často se objevují dvě placené nabídky, které je třeba řešit. Obě se zaměřují na stejný problém: K8s + Volcano + Kueue + GPU Operator je spousta YAML a některé organizace raději kupují, než aby je stavěly.

NVIDIA Run:ai (získáno v roce 2024, přejmenováno v roce 2025) je plánovač GPU s nativním rozhraním K8s. Frakcionace GPU rozděluje jednu GPU mezi úlohy na úrovni paměti – 0.5 GPU požadavky, dynamická změna velikosti, balení do bin. Run:ai si svou cenu vyslouží v podnikových prostředích, kde o sdílené GPU soupeří více než 10 týmů ML. Pod touto úrovní Kueue + GPU Operator pokrývá většinu stejné oblasti zdarma.

Determined.AI (HPE, 2021) je platforma pro spravované školení – sledování experimentů, vyhledávání hyperparametrů, správa kontrolních bodů, distribuované školení v jednom produktu. Nejvhodnější pro výzkumné týmy, které chtějí propracovaný dashboard bez nutnosti integrace pěti nástrojů.

Problém interaktivního notebooku

Vzor, který se vyskytuje téměř v každém sdíleném clusteru GPU: výzkumníci chtějí, aby JupyterHub měl přístup k GPU pro vývoj, a to musí koexistovat s dlouhodobými trénovacími úlohami, které obsahují celé uzly. Naivní odpověď – jedna dedikovaná GPU na notebook – plýtvá 80 % clusteru. Striktní odpověď – nutí výzkumníky... sbatch všechno – přenáší je na notebooky s hračkami.

Tři funkční vzory: SLURM salloc + Jupyter na alokaci (salloc --gres=gpu:1 --time=4:00:00, spusťte server Jupyter na alokovaném uzlu, tunelujte; pevný časový limit, správně započítána GPU – nejčistší řešení pro cluster SLURM), Kubernetes + JupyterHub + Kueue (pody poznámkových bloků procházejí frontou s nízkou prioritou, školicí úlohy předcházejí nečinným poznámkovým blokům) nebo Run:ai s frakcionací na GPU (notebooky dostanou 0.25 / 0.5 GPU). Ať už si vyberete cokoli, nastavit časový limit pro interaktivní relace — notebook bez časového limitu je grafická karta trvale vyřazená z clusteru.

Realita poctivých malých týmů

Většina online obsahu o plánovačích předpokládá cluster s 256 GPU a tým platformy. Realistický zákazník Kentina se blíží 1–4 uzlům, celkem 4–32 GPU, 2–6 uživatelům, kteří se všichni navzájem znají, a Slack-Coordinate. Pro toto nastavení, nepotřebujete 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ánování úloh. SLURM se začíná zaplácet s přibližně 16 GPU nebo 8 uživateli, podle toho, co nastane dříve. Pod touto hodnotou provozní režie převyšuje hodnotu. Nainstalujte plánovač, když selhává lidská koordinace, ne dříve.

Kdy se který nástroj hodí – shrnutí

---

Toto je součást Kentino Wiki, referenční série o výpočetní technologii s využitím umělé inteligence, robotice a systémech, které je propojují. Komentáře a opravy jsou vítány na adrese info@kentino.com.