Running Jobs¶
DC Suite clusters run the SLURM workload manager, so you submit and track batch jobs the way you would on any HPC cluster — from the login node, or through the DC Suite API.
From the login node¶
SSH to the cluster (Access & Networking) and use the standard SLURM commands:
sinfo # partitions and node states
sbatch train.sbatch # submit a batch job
squeue # your queued/running jobs
scancel <jobid> # cancel a job
sacct -j <jobid> # accounting for a finished job
A minimal batch script:
#!/bin/bash
#SBATCH --job-name=train
#SBATCH --gpus=1
#SBATCH --time=01:00:00
#SBATCH --output=train-%j.out
srun python train.py
Through the API¶
You can submit and track jobs without SSH:
| Action | Endpoint |
|---|---|
| Submit a job to a cluster | POST /v1/clusters/{id}/jobs |
| List a cluster's jobs | GET /v1/clusters/{id}/jobs |
| Get one job | GET /v1/clusters/{id}/jobs/{jobID} |
| Cancel a job | DELETE /v1/clusters/{id}/jobs/{jobID} |
curl -sS -X POST https://your-dc-suite.example.com/v1/clusters/$CLUSTER/jobs \
-H "Authorization: Bearer $DCS_TOKEN" \
-H "Content-Type: application/json" \
-d '{ "script": "#!/bin/bash\n#SBATCH --gpus=1\nsrun python train.py\n" }'
The response carries the SLURM job id; poll the get endpoint (or squeue) for
state.
Common SLURM flags¶
| Flag | Meaning |
|---|---|
--job-name=NAME |
Label shown in squeue/sacct. |
--gpus=N / --gpus-per-node=N |
GPUs total / per node. |
--nodes=N |
Number of nodes. |
--ntasks=N / --ntasks-per-node=N |
MPI ranks total / per node. |
--cpus-per-task=N |
CPU cores per task (dataloader workers). |
--time=HH:MM:SS |
Wall-clock limit (jobs are killed at the limit). |
--partition=NAME |
Target a specific partition/queue. |
--output=FILE / --error=FILE |
Redirect stdout/stderr (%j = job id, %x = job name). |
--dependency=afterok:JOBID |
Start only after another job succeeds. |
Multi-node distributed training¶
For multi-node GPU jobs, launch one task per GPU and let your framework read the rendezvous info SLURM provides:
#!/bin/bash
#SBATCH --job-name=ddp
#SBATCH --nodes=2
#SBATCH --gpus-per-node=8
#SBATCH --ntasks-per-node=8
#SBATCH --cpus-per-task=8
#SBATCH --time=04:00:00
#SBATCH --output=ddp-%x-%j.out
export MASTER_ADDR=$(scontrol show hostnames "$SLURM_JOB_NODELIST" | head -n1)
export MASTER_PORT=29500
srun python -m torch.distributed.run \
--nnodes="$SLURM_NNODES" \
--nproc_per_node=8 \
--rdzv_backend=c10d \
--rdzv_endpoint="$MASTER_ADDR:$MASTER_PORT" \
train.py
On profiles with high-bandwidth interconnect (NVLink/InfiniBand), NCCL uses it
automatically. If you need to confirm the fabric, set NCCL_DEBUG=INFO and
check the log for the transport in use.
Array jobs (sweeps)¶
Run the same script over many inputs with one submission:
#!/bin/bash
#SBATCH --job-name=sweep
#SBATCH --array=0-9%4 # 10 tasks, at most 4 running at once
#SBATCH --gpus=1
#SBATCH --time=00:30:00
#SBATCH --output=sweep-%A_%a.out
srun python train.py --config "configs/run_${SLURM_ARRAY_TASK_ID}.yaml"
%A is the array job id, %a the task index.
Interactive sessions¶
For debugging, grab an interactive allocation instead of a batch script:
srun --gpus=1 --time=01:00:00 --pty bash # interactive shell on a GPU node
# ... or a quick one-off:
srun --gpus=1 nvidia-smi
GPU visibility¶
SLURM sets CUDA_VISIBLE_DEVICES to the GPUs your job was granted — don't
override it, or you may step on another job's GPUs. Check what you got with
nvidia-smi inside the allocation.
Tips¶
- Right-size the cluster. Match your
--gpus/--nodesrequests to the cluster's node groups. A job asking for more GPUs than the cluster has will sit pending forever with reasonResourcesinsqueue. - Use shared storage for inputs and outputs so results survive a single node, and copy final artifacts off before deleting the cluster (see Storage & Data).
- Checkpoint often and write checkpoints to shared storage so a preemption or node failure doesn't cost the whole run.
- Watch it live. The Observability page shows SLURM node/job counts and GPU utilization while your job runs.
- Why is my job pending?
squeue --startestimates a start time;scontrol show job <id>shows the reason (Resources,Priority,QOSMaxGRES, …).
Next: Templates — turn a bare cluster into a ready environment.