Backend.AI Slurm Frontend lets an HPC site move its workloads onto Backend.AI without asking anyone to give up Slurm. Researchers keep typing sbatch, srun and squeue; behind those commands, every job runs as an isolated container on Backend.AI's GPU platform.

Two platforms, two strengths

Slurm is the open-source workload manager behind a large share of the world's supercomputers. A central controller queues jobs and schedules them onto compute nodes grouped into partitions; a daemon on every node launches the work; an accounting service keeps job history. Its strengths are batch throughput at very large scale, a rich policy model (accounts, quality of service, fair-share) and, above all, a command-line interface that the whole HPC world knows.

Backend.AI is Lablup's open-source, container-based platform for AI and HPC. Every workload is a session: one or more containers launched from an image and scheduled onto GPU nodes by Backend.AI's orchestrator, Sokovan. It supports a wide range of accelerators (NVIDIA and AMD GPUs, Intel Gaudi, Google TPU and several NPUs), fractional GPU sharing, managed storage folders with quotas, multi-tenant projects and policies, interactive tools such as Jupyter, VS Code and SSH, and a web console for users and administrators.

The problem: Slurm is everywhere, including in your pipelines

Many HPC and AI infrastructure teams would like what modern container platforms offer: isolated software environments per user, GPU sharing, self-service storage and a clear view of who is using what. Very few can simply switch.

The reason is rarely the scheduler itself. It is everything built on top of it. Years of job scripts, submission wrappers, workflow engines, MPI launch scripts, accounting reports and monitoring hooks assume that sbatch, srun, squeue and sacct exist and behave exactly as they always have. Every one of those dependencies must be found, rewritten and re-validated before the old cluster can be retired. For most sites, that migration is the most expensive and riskiest part of any platform change, and it is why Slurm stays long after the team has outgrown it.

The idea: keep the interface, replace what is behind it

Slurm Frontend is a service that takes the place of Slurm's central servers, the job controller and the accounting service. To every Slurm command on a login node it looks exactly like a Slurm cluster: it speaks Slurm's own network protocol and answers in Slurm's own formats. But it runs no Slurm scheduler and no Slurm compute daemons. Each request is translated into the equivalent Backend.AI operation, and Backend.AI does the scheduling, isolation, storage and accounting.

Three principles follow from that design:

1. Nothing changes on the login nodes. Users keep their stock, distribution-packaged Slurm clients. The only thing that changes is which server those clients talk to: Slurm Frontend instead of a Slurm controller.
2. Backend.AI is the single source of truth. Slurm Frontend keeps only the bookkeeping Slurm users expect and Backend.AI does not model, such as Slurm's small integer job IDs. Scheduling decisions, resources and job state all live in Backend.AI.
3. Honest compatibility. Where a Slurm feature has a Backend.AI equivalent, it is translated faithfully. Where it does not, the job is refused up front with a proper Slurm error instead of being silently accepted with different semantics.

Architecture

The top layer does not move: the same login nodes, the same Slurm commands, the same Slurm protocol. Slurm Frontend replaces the controller and accounting service in the middle, and Backend.AI replaces the compute layer underneath.

A request travels through three layers:

1. The Slurm protocol layer receives each command from a login node, verifies who sent it using the site's existing Munge authentication, and decodes it exactly as a Slurm controller would. It supports the protocol of several Slurm releases at once, replying to each client in its own version.
2. The translation layer maps the request onto Backend.AI concepts: a job becomes a session, a partition becomes a resource group, a Unix user becomes that user's Backend.AI account. It also keeps the small amount of state Slurm users rely on, such as the mapping between Slurm job IDs and Backend.AI sessions, and keeps it in sync with Backend.AI in the background.
3. Backend.AI schedules the work, starts containers on GPU nodes, mounts storage and records usage. The answer flows back up and is rendered in exactly the format the Slurm command expects. Interactive work gets the same treatment. srun and srun --pty bash connect the user's terminal to a real shell inside the job's container, with input, output, window resizing and exit codes behaving as they would on a Slurm cluster.

Key deliverables

The everyday Slurm workflow, unchanged.

Batch submission with sbatch (including job arrays, dependencies, deferred starts and held jobs), interactive allocations with salloc, interactive shells and commands with srun, queue and cluster views with squeue, sinfo and scontrol, cancellation with scancel, and job history with sacct. Multi-node and MPI jobs run as multi-node Backend.AI sessions.

Partitions.

Backend.AI resource groups appear as Slurm partitions. Administrators can also define partitions that pair a team's project with a pool of nodes, including several partitions over the same hardware, just as Slurm sites are used to.

Preemption.

Partitions can carry priority tiers. When a high-priority job is waiting for capacity, Backend.AI's scheduler can stop lower-priority jobs on the same nodes to make room, and Slurm tools report those jobs as preempted.

Container isolation for every job.

Each job runs in its own container, under the submitting user's own Unix identity, with its own filesystem and processes. Users can pick a container image per job, so conflicting software stacks never collide. Backend.AI runs containers on Docker or Podman today, with support for additional runtimes such as containerd and Enroot in development.

Fractional GPU.

Slurm GPU requests are served from Backend.AI's GPU pool, including its fractional GPU allocator, so Slurm jobs and other Backend.AI workloads can share the same devices efficiently.

Performance-optimized containers, without compromise.

Isolation usually costs HPC users their fast paths; on Backend.AI it does not. Backend.AI's optimization layers deliver a bare-metal-like experience inside each containerized workspace: NUMA-aware placement keeps a job's CPU cores and accelerators close together, containers come prepared for high-performance I/O with RDMA devices exposed and pinned-memory limits lifted, and shared memory is sized to the job. Containers get direct access to the node's InfiniBand and RoCE adapters, so multi-node jobs exchange data GPU to GPU with GPUDirect RDMA, and GPUDirect Storage streams data from supported storage straight into GPU memory, all without giving up per-job isolation. Slurm jobs submitted through Slurm Frontend run in exactly these containers, so MPI and NCCL workloads run on the same hardware paths they would use on bare metal.

Heterogeneous accelerators behind one interface.

Backend.AI schedules NVIDIA and AMD GPUs, Intel Gaudi, Google TPU, Graphcore IPU and AI accelerators from Rebellions, FuriosaAI, HyperAccel and Tenstorrent through one pluggable resource model. With Slurm Frontend, that whole range sits behind the same sbatch and srun commands: partitions map onto pools of different accelerators, and the Slurm interface stays the same whichever hardware the job lands on.

Identity and multi-tenancy that carry through.

Requests are authenticated with Slurm's standard Munge mechanism, and each Unix user is mapped to their own Backend.AI account. Jobs are owned by the right person, count against the right project, and respect Backend.AI's access rules and quotas.

Fair-share and accounting.

sshare shows fair-share data computed by Backend.AI's fair-share scheduler, and sacct keeps job history even after the underlying sessions have been cleaned up.

Storage that is simply there.

Shared areas such as scratch and dataset folders, and a persistent per-user home directory, can be mounted into every job automatically from Backend.AI's managed storage, and a job can ask for additional folders.

▲ Managed storage in the Backend.AI WebUI: every folder carries its owner, permissions and quota scope.

One console for everything.

Because every Slurm job is an ordinary Backend.AI session, it shows up in the Backend.AI web console next to all other workloads, with per-user and per-project resource and storage usage and cluster-wide monitoring.

▲ The Backend.AI dashboard: allocated and total resources per resource group, recent sessions and live agent utilization in one view.

How Slurm concepts map onto Backend.AI

The translation is mostly one-to-one, which is what makes a transparent front end possible:

What changes for whom

Researchers and developers

• Nothing to relearn. Existing job scripts, wrappers and pipelines keep working, and so does the muscle memory of typing squeue.

• A workspace of their own. Each job runs in its own container image, so one team's CUDA version, compiler or Python stack never breaks another's. People can install and experiment freely, and the same environment is a click away as an interactive notebook or IDE session in Backend.AI.

Infrastructure operators

• Migration without the rewrite. Pipeline migration, the hardest part of leaving Slurm, largely disappears: the interface stays, the platform underneath changes.

• Visibility Slurm never offered. Per-user and per-project compute and storage usage, quotas and cluster-wide monitoring come with a graphical console instead of a collection of report scripts.

• One platform for all workloads. Batch HPC jobs, interactive development and other AI workloads share the same nodes, the same GPU pool, the same scheduler policies and the same storage, instead of living in separate silos.

▲ Usage reports in Backend.AI: sessions, accelerator time and average utilization, aggregated by user or project and exportable as CSV.

Get the Slurm experience on Backend.AI today

Slurm Frontend is ready for any Backend.AI cluster running Backend.AI 26.8.1 or later, and it works with the standard Slurm clients your users already have, with Slurm 24.11 recommended. Every feature in this post, including priority-tiered partitions with preemption, is available from that release on.

Your researchers keep their scripts and their habits. Your operators get containers with GPUDirect RDMA and Storage, fractional GPUs, heterogeneous accelerators, managed storage and a single console for every workload. Nobody has to wait for a migration project to finish.

Ready to bring the Slurm experience to Backend.AI? Reach out to your Lablup partner or contact Lablup at contact@lablup.com to get on board.

Learn more

• Backend.AI on GitHub

• Slurm overview, SchedMD