For research computing

More science from the GPUs
you already paid for.

A maintenance window or a failed node sends a week-long run back to the start, and the cluster sits at 30-40% utilization. Cedana checkpoints every GPU job continuously, so an outage costs a minute and the same hardware does far more science. No change to any researcher's workflow.
effective utilization
30-40% 80%
on a shared research GPU cluster
work lost
0
when a node fails or drains
time to deploy
<30min
to install above your scheduler
code changes
0
for any researcher
The science · what runs on your cluster

Your code already checkpoints. Just not when it matters.

Every one of these codes writes a restart file. The catch is granularity and timing: too coarse, too rare, or only at the very end. Ordered by how much of a research cluster each field actually runs.

VASP · Quantum ESPRESSO · CP2K · ABINIT · BerkeleyGW

DFT & Ab Initio

The workhorse of materials science and chemistry on every campus cluster. The plane-wave wavefunction and charge density live in GPU memory across the SCF loop.

at riskA relaxation or AIMD run spans hours to days. A drain mid-SCF throws away the self-consistency cycle, and a killed relaxation can drop back to the last ionic step or to zero.
with cedana
  • Snapshot the live wavefunction and charge density mid-SCF, which VASP writes to WAVECAR only after the loop converges
  • A maintenance drain becomes checkpoint-and-resume, not a restart from the last completed ionic step
  • For multi-node HSE and GW jobs, coordinated checkpoint captures every MPI rank and its in-flight CUDA-aware MPI transfers consistently
scf · crystal latticerunning…
bcc unit cell · charge density
VASP · plane-wavesave · resume
gpu · 4× H100SXM5 · NVLink
util█████████████░░░82%
vram█████████████░░░66/80GB
The problem · why the GPU goes away

Six ways a shared cluster loses the work.

The restart file is only half the story. The cluster takes the GPU between writes, and device memory was never in it.

01
DRAIN.WINDOW

A drain takes the node mid-run

Maintenance reserves the node and kills every job on it. A VASP relaxation mid-SCF drops to its last ionic step, or to zero. Researchers stop submitting days ahead to dodge the window.

02
NODE.FAIL

One bad GPU takes the whole job down

Every rank syncs behind each collective, so one bad GPU, NVLink, or NIC kills the whole job. Meta's Llama 3 405B run logged 419 unexpected interruptions over 54 days on 16,384 H100s, about one every three hours.

03
ALLOC.HOARD

Packed scheduler, idle silicon

To insure against interruption, researchers oversize walltime and hoard spare GPUs. Slurm shows a full cluster while nvidia-smi reads 30-40% SM utilization.

04
FRAG.QUEUE

Topology strands whole GPUs

Jobs want contiguous ranks in one NVLink domain, but odd shapes never fit the free 8-GPU islands. The scheduler idles nodes to assemble a slot, stranding 21-42% of the fleet.

05
CONDO.PREEMPT

Preempted with 80 GB still on the device

An owning lab's job lands: SIGTERM, about 30 seconds, then SIGKILL. A full dump of 80 GB of HBM to shared storage rarely finishes in that window, so the borrowed run dies instead of pausing. Owners stop lending.

06
BURST.STRAND

A spot reclaim wipes the in-flight run

Spot and cloud-burst run up to 90% cheaper, but a reclaim takes the GPU mid-step on the same brief grace window. One eviction erases a multi-day run, so real science stays on-prem.

Why cedana · what a shared cluster recovers

Six ways a shared cluster wins the work back.

Each gain closes one of the six losses above — earned by a specific capability, not a slogan, and nothing for researchers to change.

run to the last minute · rolling drain · resume after

Maintenance windows stop killing jobs

cluster util · maintenance weekwithout
maintenanceD-2D-1D0D+1D+2
only the window dipsruns to the last minute
continuous full-state capture · auto-resume on a healthy node

A failed node costs a minute, not days

long run · node faultsrunning…
H100-class GPUs fail ~9%/yrfaults survived: 0 · run intactdone
auto-resume, healthy nodea fault costs a minute
jobs survive interruption · padded allocations reclaimed

No reason left to over-request “insurance” GPUs

allocation · GPUsover-requested
requestedusedinsurance paddingshared pool
jobs survive interruptionpadding reclaimed
migrate jobs to idle nodes · compact for multi-node openings

Defragment the queue, shrink the wait

scheduler map · 8-GPU jobqueued · waiting
8-GPUwaiting21-42% stranded by fragmentation
migrate to idle nodesqueue compacts
a preempted borrower resumes elsewhere · owner reclaimed cleanly

Condo sharing becomes policy, not politics

condo GPUs · borrow & returnLab B borrowing
Lab A · ownerBshared pool
borrower resumes elsewhereowner clean
a reclaim becomes a resume · same checkpoint, either side

Spot & cloud-burst safe for week-long runs

spot pool · reclaim-saferunning on spot
spot · up to 90% cheaperspot 1spot 2spot 3spot 4reclaim → resume · never restarts
checkpoint in grace windowresume next instance
How it works · save → migrate → resume

Your run survives the GPU underneath it.

Cedana runs at the OS and kernel level and works transparently with Slurm or Kubernetes, keeping every run moving across the GPUs underneath it.

gpu-partition · slurm6 working · 6 free · 12 GPU nodesnode010%○ freenode0279%● job 8471node030%○ freenode0493%● runningnode050%○ freenode0685%● runningnode0792%● runningnode080%○ freenode0984%● runningnode100%○ freenode110%○ freenode1283%● runningworking · fans spinningfree · idledraining↳ drain-safe migrate · the scheduler slot is never lost, the run lands on a healthy node
01

Running

A run lives in GPU memory for days.

02

Save

Cedana snapshots full GPU state, below the app.

03

Migrate

A fault or drain triggers a live migration.

04

Resume

It resumes at the same step. Nothing lost.

vMotion for GPU workloads. Researchers never touch it; their runs just stop dying.

Runs on your stack · any cloud, any scheduler

Runs everywhere your GPUs already live.

SLURMKubernetesKueueRayArmadaNVIDIAAWSGoogle CloudSLURMKubernetesKueueRayArmadaNVIDIAAWSGoogle Cloud
FAQ · what research-computing teams ask

Questions we hear first.

01Will our admins have to run something they didn't write inside SLURM?
No. Cedana does not fork or replace SLURM and does not change the interface; sbatch, srun, and squeue stay exactly as they are. It installs as a bootstrap script plus a plugin, typically in under an hour, transparent at the OS and kernel level. See the installation instructions →
02Our researchers aren't asking for checkpointing. Why deploy it?
The pitch is to the operations team, not the researchers. The gain lands on effective utilization, uptime, and cost per researcher served. Researchers benefit downstream without doing anything: their jobs survive interruptions and they stop over-allocating to hedge.
03We run a condo model and the lab politics are the hard part. Does this help?
Yes. The politics exist because preemption destroys work. Cedana lets a borrowed job checkpoint and resume elsewhere when the owner reclaims, with no progress lost, so sharing becomes a scheduling policy instead of a standing fight.
04We have air-gapped and classified workloads. Can it run without calling home?
Yes. Cedana supports on-premise and fully air-gapped deployment with no runtime dependency. To be precise, it is not FedRAMP authorized today, which is on the roadmap; what it provides now is system-level provable recovery entirely inside your boundary.
05Most of our science is multi-node distributed. Can you checkpoint that?
Yes, that is the case Cedana is built for. It takes a coordinated snapshot across the job, accounting for in-flight MPI and NCCL collectives, RDMA, and OS and network state, which single-GPU primitives like the NVIDIA driver checkpoint do not do.
06What does it cost in steady-state performance?
Low single digits in percent. Snapshots are taken on a roughly 60-90 second interval, and we measure the exact overhead against your workload mix in a PoC rather than quote a universal number.
~ / cedana / deploy ready

Command your
compute.

Your compute, liquid — checkpoint, migrate, and resume live GPU jobs across the fleet.

deployK8s helm chart · SLURM plug-in
first migration<30 min
code changes0
workloadstraining · inference · HPC
01
AWS
02
Google Cloud
03
NVIDIA
04
K8s
05
SLURM
06
Nvidia Dynamo