Skip to content
Spike Documentation

From Slurm to Run:ai

Spike is not a Slurm cluster. Commands such as sbatch, srun, squeue, and module load do not control Run:ai. Reuse the scientific application and its resource reasoning, then translate the scheduler-specific parts.

If the application fundamentally depends on Slurm, environment modules, or a large CPU-oriented MPI workflow, Snellius may be the better platform. See the broader TU/e Supercomputing umbrella before porting the workflow.

Concept mapping

Section titled “Concept mapping”
Slurm concept Spike / Run:ai equivalent
--account or project allocation Run:ai project assigned during onboarding
Partition and --gres=gpu:... Approved compute-resource preset
--nodes Distributed workload pods and worker count
--gpus-per-node GPU devices requested per pod
--ntasks or tasks per node Processes started by torchrun, Accelerate, or MPI
module load Versioned software installed in the container image
Shared filesystem path Run:ai data source or PVC mounted into the container
$SLURM_TMPDIR Ephemeral container or volume storage
#SBATCH --output Application output on persistent storage plus short-lived Run:ai logs
squeue / sacct Run:ai portal or CLI workload list and describe commands
scancel Suspend or delete the Run:ai workload
Job array A bounded set of workloads or approved sweep controller

The Slurm sbatch reference and srun reference remain useful for understanding the original script, but their flags cannot be pasted into Run:ai.

Translate a simple batch script

Section titled “Translate a simple batch script”

A Slurm script may look like this:

#!/bin/bash
#SBATCH --job-name=train
#SBATCH --gres=gpu:1
#SBATCH --output=logs/%x-%j.out


module load Python CUDA
srun python train.py --epochs 10

On Spike:

  1. Put Python, CUDA-compatible libraries, and the application in a versioned image.

  2. Replace the Slurm allocation flags with the project and compute-resource preset approved by your SCC AI Engineer.

  3. Attach project data and output storage as Run:ai data sources.

  4. Launch the application as a standard training workload:

    Terminal window
    runai training standard submit train \
      --project PROJECT_NAME \
      --environment ENVIRONMENT_NAME \
      --compute COMPUTE_RESOURCE_NAME \
      --command -- python /workspace/train.py --epochs 10

  5. Follow the workload through the Run:ai portal or CLI and save logs before they disappear after completion or failure.

Use Launch workloads with the Run:ai CLI for a complete submission and cleanup workflow.

Translate multi-node jobs carefully

Section titled “Translate multi-node jobs carefully”

Do not translate --nodes, --ntasks-per-node, and --gpus-per-node independently. Together they describe a process topology:

  • Run:ai must create the agreed number of participating pods.
  • Each pod must request the agreed GPUs.
  • The launcher must start the matching local processes.
  • Every process needs a unique rank and the same world size.
  • Data and checkpoints must be reachable from every pod.

Use Multi-GPU and multi-node training and NVIDIA’s distributed PyTorch tutorial for Run:ai. Do not copy NCCL_SOCKET_IFNAME, hostnames, rendezvous addresses, or fabric settings from Snellius; those values are cluster-specific.

Translate arrays and sweeps

Section titled “Translate arrays and sweeps”

A Slurm array controls parallelism at the scheduler. A W&B sweep or Python launcher controls experiments, but every concurrent trial still consumes a Run:ai workload and project capacity. Agree on the maximum parallel trials and compute resource with your SCC AI Engineer. Start with two short trials and confirm that failures, checkpoints, and run IDs remain separate.