GPU clusters

• Kubernetes or Slurm: Every cluster runs on Kubernetes. Work with kubectl and standard Kubernetes tooling directly, or create a Slurm cluster to run HPC-style batch workflows with sbatch and srun.
• Capacity type: Reserve capacity upfront for 3 to 180 days at discounted rates, pay hourly for on-demand capacity with no commitment, or draw from a project capacity pool for a scheduled window. You can mix reserved and on-demand capacity in the same cluster.

​

Get started

# create a cluster (an interactive prompt walks through the options)
tg clusters create

# check the status until the cluster is ready
tg clusters get <CLUSTER_ID>

# write a kubeconfig for kubectl access and switch to its context
tg clusters get-credentials <CLUSTER_ID> --set-default-context

​

How clusters work

• Hardware: GPU worker nodes connected by high-speed InfiniBand, each with fast local NVMe storage, plus a persistent shared volume mounted on every node.
• Kubernetes: A control plane managed by Together tracks cluster state and schedules workloads onto the worker nodes. You reach it with kubectl and standard Kubernetes tooling.
• Slurm (optional): On Slurm clusters, the Slurm scheduler runs on top of the same Kubernetes stack through Slinky, an integration layer that bridges HPC scheduling with cloud-native infrastructure. You SSH into a login node and submit jobs with sbatch and srun.

​

Choosing Kubernetes or Slurm

• Choose a Kubernetes cluster if your workloads are containerized and you want to work with kubectl and the Kubernetes ecosystem directly. You can use schedulers like Kueue and Volcano, or orchestrators like SkyPilot. See Kubernetes workloads.
• Choose a Slurm cluster if your team works with HPC-style batch workflows, such as sbatch scripts, job arrays, partitions, and a shared job queue with priorities. Slurm comes preconfigured for distributed training, so you can submit jobs without writing any Kubernetes manifests. See Slurm workloads.

​

Available hardware

​

Capacity types

​

Choosing a capacity type

• Choose reserved if you know how long your workload will run, such as a multi-day training run or a planned experiment, and you can commit to that period in exchange for discounted rates.
• Choose on-demand if your resource needs are unpredictable, you’re running short experiments, or you’re still developing and testing and want maximum flexibility.
• Mix reserved and on-demand if you have a predictable baseline with occasional bursts. For example, reserve capacity for your baseline workload, then scale up with on-demand capacity during peak periods and back down when the burst ends. Usage beyond your reserved capacity is automatically billed at on-demand rates.
• Choose scheduled capacity if your project has a capacity pool and your workload fits a planned window. The create form shows this option only when your project has a pool. For a cluster that starts now, you can combine capacity pool GPUs with prepaid reserved GPUs from outside the pool.

​

Storage

• Shared volumes: Persistent. High-throughput file systems that survive pod restarts, node reboots, and, by default, cluster deletion.
• Local NVMe: Ephemeral. Fast local disks on each node. Data can be lost during reboots, migrations, or cluster operations.
• /home directory: Persistent on Slurm clusters, where it lives on the shared volume. Ephemeral on Kubernetes clusters, where it’s local to each node.