HPC, Slurm, and Kubernetes together
Slurm still rules tightly-coupled HPC/MPI; Kubernetes rules services and AI. You can run both — and increasingly bridge them.
HPC workloads — CFD, molecular dynamics, weather, genomics — are tightly-coupled MPI jobs that care about FP64 throughput and low-latency interconnect (InfiniBand, often with SHARP in-network reduction). Slurm's gang/backfill scheduling and partitions map naturally onto GPU node pools, which is why it remains the HPC standard.
Kubernetes, meanwhile, owns services, inference, and MLOps. Rather than pick one, many sites run both: a Slurm partition for batch HPC and a Kubernetes cluster for everything else, sometimes sharing the same GPU nodes. Projects like Slinky and the Slurm operator bridge them — running Slurm inside Kubernetes, or letting Slurm burst into K8s node pools — so one GPU fleet serves both scheduling models.
On the Kubernetes side, MPI jobs run via the MPI Operator, and gang scheduling (Volcano/Kueue) provides the all-or-nothing semantics HPC needs. For FP64-heavy codes, parts like the AMD MI250X/MI300A and NVIDIA H100/GH200 lead; see the catalog's FP64 figures. The HPC workload pattern has a sample sbatch script.