Skip to content

Getting started

Log in

SSH to the cluster's public IP. This lands you in the Slurm login pod as ubuntu, with the Slurm CLI ready to use:

ssh ubuntu@<cluster-ip>

The login pod has no sudo, and anything installed outside /home is lost when the pod restarts, so keep environments (venv, uv, conda) under /home. For admin work (sudo, kubectl, adding users), SSH to the login node itself on port 2222:

ssh -p 2222 ubuntu@<cluster-ip>

Additional users are provisioned with slinky-user-add and log in on port 22 the same way, as themselves, so their jobs run under their own identity. srun id shows which identity a shell submits as.

Info

Clusters deployed before October 2026 use the opposite layout: port 22 is the login node and port 2222 is the login pod (off by default). See How users log in.

Check the cluster

sinfo

Worker nodes appear as slinky-0, slinky-1, ... in the all partition and should be idle (or mix/alloc when busy).

Run your first job

Each worker has 8 GPUs, so a 16-GPU job spans two nodes:

srun --gpus=16 nvidia-smi -L

Warning

Steps only see the GPUs they request. With no --gpus (or --gres=gpu:N), nvidia-smi reports No devices found. inside the step. See Shared jail.

Batch jobs

Write the script under /home (it is shared with the workers) and submit from there:

cat > /home/ubuntu/hello.sbatch <<'EOF'
#!/bin/bash
#SBATCH --job-name=hello
#SBATCH --nodes=2
#SBATCH --gres=gpu:8
#SBATCH --time=00:05:00
srun hostname
srun nvidia-smi -L
EOF

sbatch /home/ubuntu/hello.sbatch

Output lands in slurm-<jobid>.out next to where you submitted. Use squeue for active jobs, sacct for finished ones. The full command reference is in the Slurm documentation, which applies to Slinky unchanged.

Interactive sessions

srun --nodes=1 --gres=gpu:1 --time=00:15:00 --pty bash

drops you into a shell on a worker with one GPU bound. For multi-node interactive work, hold an allocation with salloc and run srun inside it.

Where to put things

  • /home is shared everywhere: Python environments (python3 -m venv), job scripts, container images (SIF files). Build once, use from every job.
  • /shared is a world-writable dataset area on the same shared filesystem: one stable path for team data, identical on the login pod and inside every job.
  • /local inside a step is the worker's local NVMe: a per-node cache for datasets and checkpoints. It persists across jobs and node restarts, so a re-run landing on the same node finds its data already there.
  • /tmp inside a step is private to the job, also on the NVMe: use it for heavy temporary I/O. It is emptied when the job ends; keep anything valuable on /local or /home.
  • HPC-X modules are available inside steps from /opt/hpcx: srun bash -lc 'module load hpcx && ...'.

Next steps