---
title: "Slurm Cluster"
description: >-
  TIR Slurm Cluster is a managed Slurm scheduler on Kubernetes (Slinky) for distributed GPU training — with an editable slurm.conf, custom partitions, prolog and epilog scripts, and container jobs via Enroot and Pyxis.
displayed_sidebar: tirSideBar
---

import { SlurmClusterBadges, SlurmClusterQuickStart, SlurmClusterCapabilities, SlurmClusterAPIDoc, SlurmClusterBilling } from './slurmClusterCards'

# Slurm Cluster

A **Slurm Cluster** is the current generation of TIR Training Cluster: a real, managed
[Slurm](https://slurm.schedmd.com/) scheduler running on Kubernetes through the
[Slinky](https://github.com/SlinkyProject) operator. You get a login node to submit from, a
controller that schedules, and GPU worker nodes that run the work — with the parts of Slurm that
actually matter to a training team exposed in the TIR console.

<SlurmClusterBadges />

What sets it apart from a plain managed scheduler:

- **Any container image, inside any job.** `srun --container-image=...` runs your Docker or OCI image
  on the allocated GPUs through Enroot and Pyxis. No cluster rebuild, no Docker daemon.
- **`slurm.conf` is yours to extend.** Append your own directives from the console; the platform keeps
  only the keys that wire the cluster together.
- **Partitions you define.** Carve the node pool into named queues with their own limits and
  membership.
- **Prolog and epilog scripts.** Run your own shell code around every job, on the workers and on the
  controller.

:::info The console calls this "Training Cluster"
In the TIR portal the product is still labelled **Training Cluster** — that is the sidebar item, the
list page, and the create button. These docs call it a **Slurm Cluster** to describe what it actually
is. They are the same product.
:::

## Quick Start

<SlurmClusterQuickStart />

## Explore Slurm Cluster

<SlurmClusterCapabilities />

## API Reference

<SlurmClusterAPIDoc />

## Billing & Plans

<SlurmClusterBilling />