The real challenge isn’t Slurm vs. Kubernetes
Ask most infrastructure teams about HPC and AI convergence and the conversation turns into a scheduler debate. That framing misses the point. In practice, the choice was made years ago by the users.
Simulation teams built their workflows on Slurm because it delivers what tightly coupled computing demands: deterministic scheduling, MPI-aware job launch, topology-aware placement, and accounting that stands up to chargeback. AI teams standardized on Kubernetes because their world is containers Jupyter, Kubeflow, PyTorch images, CI/CD pipelines. Neither group is wrong, and neither is going to migrate to the other’s stack.
The cost lands on the infrastructure team: two GPU estates, two identity systems, two storage layouts, two monitoring stacks and GPUs sitting idle in one silo while jobs queue in the other. Historically, HPC clusters and AI clusters evolved independently, one optimized for simulation, the other for machine learning. As GPU demand climbs, that duplication gets harder to justify: why maintain two GPU clusters, two storage systems, two user-management stacks, two monitoring tools?
This is the problem Slinky attacks at the scheduling layer.
Why Slurm and Kubernetes don’t just merge on their own
Slurm and Kubernetes were built for different workloads. Slurm is designed for deterministic, tightly coupled HPC jobs with shared parallel storage and standardized software environments, while Kubernetes is optimized for elastic, containerized AI workloads that evolve rapidly. Although unifying them enables better GPU utilization and simpler infrastructure management, it requires bridging fundamental differences in scheduling, storage, and software ecosystems not just replacing one scheduler with another.
What Slinky actually is
Slinky is an open-source (Apache 2.0) toolkit, originally developed by SchedMD the creators of Slurm and now maintained by NVIDIA following its acquisition of SchedMD in 2025. Rather than replacing Slurm, Slinky enables Slurm and Kubernetes to work together, allowing HPC and AI workloads to share the same GPU infrastructure while preserving existing Slurm workflows. It isn’t a single product, but a set of interoperable projects, container images, and Helm charts designed to bridge the two ecosystems.
slurm-operator: run Slurm inside Kubernetes
The slurm-operator deploys a complete Slurm cluster as Kubernetes pods slurmctld, slurmdbd, slurmrestd, and slurmd workers managed through custom resources. Compute capacity is defined as NodeSets, which the operator can scale in response to Slurm queue load. Everything HPC users expect from Slurm partitions, QOS, accounting, preemption, job dependencies, MPI launch works exactly as it does on bare metal, because it is real Slurm, running on Kubernetes. Installation is a pair of Helm charts from the SlinkyProject registry.
This is the deployment model for organizations standardizing on Kubernetes as their infrastructure substrate while still needing to offer a genuine Slurm environment.
slurm-bridge: let Slurm schedule Kubernetes workloads
slurm-bridge is the inverse. It plugs into the Kubernetes scheduling framework and delegates placement decisions for selected workloads to an existing Slurm controller, so Kubernetes pods and Slurm jobs can share the same nodes without stepping on each other. If you already run a production Slurm cluster and want to admit containerized AI workloads without standing up a second silo, this is the component you care about.
Hybrid clusters: the realistic migration path
Since the 1.0 release, Slinky supports hybrid topologies: one or more Slurm components can live outside Kubernetes and still join the same cluster. Your existing controller and accounting database can stay on the VMs where they run today while compute capacity moves into Kubernetes NodeSets one Slurm cluster, migrated incrementally. For most enterprises, this not a greenfield rebuild is the adoption path that actually works.
Slinky at scale: NVIDIA’s own production numbers
The best evidence that this holds up isn’t a spec sheet it’s NVIDIA running it internally. In an April 9, 2026 NVIDIA Technical Blog post, engineers on the Slinky team detailed lessons from running slurm-operator in production across multiple internal clusters, some scaling to over 1,000 GPU worker nodes and 8,000+ GPUs, handling large-scale LLM training and multinode inference daily.
A few results worth noting:
- Performance parity. GPU communication benchmarks (NCCL all-reduce and all-gather) matched noncontainerized Slurm deployments, with no measurable overhead from running on Kubernetes.
- Fast provisioning. New clusters go from zero to running jobs in hours using Helm charts and declarative config — no manual node-by-node setup.
- Unified monitoring. Prometheus scrapes both Slurm metrics (jobs, nodes, partitions, scheduler latency) and standard Kubernetes metrics into shared Grafana dashboards, eliminating a separate HPC monitoring stack.
- Nondisruptive rolling updates. PodDisruptionBudgets protect running jobs during worker image updates, so Slurm version bumps and OS patches roll out without interrupting active training runs.
- Automated remediation. Node health issues sync from Kubernetes to Slurm automatically — Slurm drains the node, jobs reschedule to healthy hardware, and teams stop hand-coordinating between the two systems.
The same post flags one concrete constraint: slurm-operator currently assumes one worker pod per node, which over-provisions if your workloads are exclusively single-node jobs — in that case, slurm-bridge is the better fit. It also details the v1.1.0 additions (dynamic topology support, DaemonSet-style worker scaling, and automatic remediation of unregistered worker pods) that closed several production gaps since 1.0.
What Slinky doesn’t do
Slinky focuses on the scheduling layer, not the entire platform. While it helps unify Slurm and Kubernetes scheduling, organizations should still expect container image compatibility work, careful upgrade management, and responsibility for user onboarding, GPU access, application publishing, storage, and governance. A successful converged environment depends on these platform services—not just the scheduler.
From converged scheduling to converged operations: where SyncHPC fits
Slinky provides the foundation for converging HPC and AI workloads. SyncHPC extends that foundation by delivering the operational layer needed to run these environments efficiently at scale for Slinky-based clusters, traditional Slurm/PBS clusters, or the hybrid clusters in between.
Rather than asking users and administrators to interact with Slurm and Kubernetes directly, SyncHPC operates both through one platform, answering the operational questions Slinky leaves open:
– How are users onboarded?
– Who gets GPU access?
– How are applications published?
– How are quotas enforced?
– How do researchers launch jobs without learning Kubernetes?
– How is storage managed across users?
– How do administrators monitor infrastructure from one interface?
Concretely, SyncHPC delivers:
Unified access: Researchers, engineers, and AI developers reach HPC and AI applications through a single web interface instead of managing separate environments for Slurm and Kubernetes.
Centralized resource management: SyncHPC manages users, projects, GPU allocation, storage, and quotas from one platform while integrating with existing Slurm and Kubernetes deployments underneath.
AI and HPC in one platform: Traditional HPC applications and modern AI environments including Jupyter Notebook, VS Code Server, and containerized AI frameworks coexist on the same infrastructure without separate management workflows.
Efficient GPU utilization: By integrating scheduling, monitoring, and resource governance, SyncHPC helps organizations maximize GPU utilization across simulation, AI training, inference, and interactive development workloads.
Simplified administration: Rather than stitching together separate tools for authentication, application deployment, monitoring, and storage management, administrators manage the complete environment through a single interface.
Where this is heading
Slinky signals the direction of modern HPC infrastructure clearly: Kubernetes as the common substrate, Slurm continuing to deliver the scheduling guarantees HPC users trust one GPU estate instead of two. But a converged scheduler is not the same thing as a converged operation.
The organizations that get real value from this architecture will be the ones that pair it with an operational layer their researchers and administrators can actually live in. Success depends not just on integrating Slurm with Kubernetes, but on simplifying day-to-day operations on top of it. That’s what SyncHPC is built for turning a converged architecture into a usable, scalable, production-ready environment.
blog.syncious.com 
Leave a comment