Skip to main content
Change your GPU cluster’s Slurm configuration to tune scheduling, resource allocation, and job management. How you make and apply a change depends on the cluster’s Slinky version.

Requirements

  • The kubectl CLI installed and configured.
  • Your cluster’s kubeconfig, downloaded with tg clusters get-credentials. Only project admins can download it.
  • Access to your cluster’s slurm namespace.

Slinky v1.0 clusters

New Slurm clusters run Slinky v1.0. Clusters created or booked as scheduled capacity before September 2026 can still run Slinky v0.1, which ignores startup scripts. To move a v0.1 cluster to v1.0, contact your account team. To check your cluster’s Slinky version, run sinfo on the login node. On Slinky v1.0 clusters, it lists nodes named slinky-0, slinky-1, and so on, in a partition named slinky. Other Slurm clusters run Slinky v0.1. To change slurm.conf on a Slinky v1.0 cluster, add your settings in Extra slurm.conf:
  1. On the cluster details page in the Together AI console, select Edit Configuration.
  2. Add your lines to Extra slurm.conf, and then select Save.
The Slinky operator appends your lines to the default slurm.conf, so a setting you repeat overrides the default. The change takes effect through a live scontrol reconfigure, without a restart. To confirm it, run scontrol show config on the login node. Don’t edit the slurm-config ConfigMap directly. The operator generates slurm.conf into it and overwrites any edit you make there.

Slinky v0.1 clusters

On Slinky v0.1 clusters, edit the slurm ConfigMap with kubectl, then restart the Slurm components to apply the change.

View the configuration

The slurm ConfigMap in the slurm namespace holds your cluster’s Slurm configuration in four main files: View a file’s current contents before you change it:

Edit the configuration

Back up the ConfigMap before you change it, and keep the backup in version control. Make one change at a time, so any problem traces back to a single edit. When you can, test changes on a non-production cluster first.
To edit the ConfigMap in place, open it in your default editor:
Make your changes, then save and close the editor. To edit a local copy instead, export the ConfigMap, edit the file, and apply it back:

Restart components

Whichever file you changed, restart the controller first:
Compute nodes don’t read the ConfigMap. They fetch every file from the controller through Slurm’s configless mechanism, so they get your change only after the controller reloads it. Then restart the compute nodes, which run as pods (not daemonsets). Kubernetes recreates each deleted pod with the new configuration.
Deleting a compute node pod ends any job running on it. Drain the nodes first, and delete their pods after the running jobs finish.
If your cluster runs the accounting daemon, restart it the same way as the controller:

Verify changes

Confirm that the restart finished and the new configuration is live:
Then monitor your jobs to confirm scheduling still behaves as expected.

Configuration examples

Put slurm.conf lines in Extra slurm.conf on Slinky v1.0 clusters, or in the slurm ConfigMap on Slinky v0.1 clusters.

Configure GPU resources

The gres.conf file declares each node’s GPUs. If you edit it, keep the default type and device range, which match each node’s Gres=gpu:8 definition:

Modify partitions

Add a partition in slurm.conf:
Nodes=ALL includes every compute node. To limit a partition to specific nodes, set Nodes to the node names that sinfo lists.

Tune the scheduler

Adjust scheduler parameters in slurm.conf:

Update resource allocation

Slinky v1.0 clusters set DefMemPerNode=0, so a job that doesn’t set --mem has no default memory limit. To change that default, set a new DefMemPerNode value in megabytes:
Don’t use DefMemPerCPU for this, because it’s mutually exclusive with DefMemPerNode.

Enable cgroup limits

Slinky v1.0 clusters already confine jobs with cgroups (ProctrackType=proctrack/cgroup and TaskPlugin=task/cgroup,task/affinity). On Slinky v0.1 clusters, edit cgroup.conf to choose which limits to enforce:
Then enable the cgroup plugins in slurm.conf:

Troubleshooting

  • Configuration not applied: On Slinky v1.0 clusters, check that scontrol show config lists your setting. On Slinky v0.1 clusters, confirm the ConfigMap holds your edit with kubectl get configmap slurm -n slurm -o yaml, and check that the pod ages reset after the restart with kubectl get pods -n slurm. Then view the controller logs with kubectl logs slurm-controller-0 -n slurm.
  • Syntax errors: Search the controller logs for errors with kubectl logs slurm-controller-0 -n slurm | grep -i error, and view recent events with kubectl get events -n slurm --sort-by='.lastTimestamp'.
  • Pods not restarting: Check the controller’s rollout status with kubectl rollout status statefulset slurm-controller -n slurm, then delete the controller pod with kubectl delete pod slurm-controller-0 -n slurm to force Kubernetes to recreate it.
  • Jobs failing after changes: Check node status with kubectl exec -it slurm-controller-0 -n slurm -- sinfo. Then, with the same kubectl exec prefix, inspect a node with scontrol show node <NODE_NAME> and view job errors with scontrol show job <JOB_ID>.

Additional resources