Clusters

Lightning AI offers frontier-grade clusters with high-performance networking, storage and your choice of orchestrator.

To set up a cluster, contact our team.

Index

• Kubernetes
• SLURM
• Networking
• Storage

Orchestrator comparison

SLURM and Kubernetes each take a different approach to orchestrating compute. SLURM excels in high-performance batch workloads, and Kubernetes brings container-based flexibility and control. Each has its strengths and trade-offs.

Here's a comparison that highlights them at a glance.

Concept	Kubernetes	SLURM
Reserved machines	Node	Partition / Node
On-demand machines	Cluster resizing (manual, brittle)	Not native (requires schedulers & plugins)
Task type	Pod	Job script (sbatch, srun)
Single node training	Pod for training (YAML, schedulers)	srun / sbatch job
Multi-node training	Pod for training (YAML, schedulers)	srun / sbatch job (needs MPI plugin)
Inference	Pod for inference (stateless)	Not designed for inference
Development (IDE)	Pod for dev (ephemeral, YAML)	Interactive sessions
Data processing	Pod for data prep	Batch jobs (manual scripting)
Pipelines	DIY (Argo, Airflow, K8s operators)	DAGs with sbatch dependencies
Run PyTorch	Special operators or plugins.	srun + python script
File system	DIY (NFS, CSI drivers, config-heavy)	Shared FS (e.g., Lustre, GPFS)
Multi-cloud?	Single-cloud only	Single cluster only
Can be all on-demand?	No (requires reserved capacity)	No (requires partitions/nodes)
Can be all reserved?	Yes	Yes
User interface	YAML, kubectl CLI	CLI (srun, sbatch)
Workload abstraction	Pod	Job / Task
Scheduler model	K8s default scheduler (for stateless pods)	SLURM scheduler (optimized for batch jobs)
Who it serves best	DevOps (infra control, utilization focus)	HPC admins (batch workloads, MPI training)
Limitations	Hard to make stateful ML workloads work well	Brittle for ML, not elastic, HPC-centric