Explanation
warmctl and the alternatives
Several tools shorten a vLLM cold start. They differ in what they keep: the weights, the processes, or the whole warmed-up engine, and in where a restore can run. This page compares them from each project's own documentation, checked on 31 October 2026.
What each one restores
| Tool | What comes back | GPUs per engine | Restore on another host | Needs Kubernetes | License |
|---|---|---|---|---|---|
| warmctl | The engine's processes (CRIU), each GPU's state with compiled kernels and CUDA graphs, and the processed weights | 1 to 8 on one node, tensor and expert parallel | Yes, in any cluster, cloud or data center with the same GPU model and count, driver branch and CPU features; pulled from any OCI registry or mirror | No; Kubernetes and KServe are supported | Apache-2.0 |
| NVIDIA Dynamo Snapshot | A fully initialized GPU pod (CRIU and cuda-checkpoint); vLLM, SGLang and TensorRT-LLM | 1 to 8 on one node; several nodes on its roadmap | Yes, on a node of the same installation with the same GPU and driver, from the cluster's checkpoint store | Yes: an operator, a privileged agent on every GPU node, the GPU Operator and a ReadWriteMany volume; not yet for production-critical workloads | Apache-2.0 |
| vLLM initialized snapshots | The engine process after initialization | One (tensor parallel size 1) | No: same machine, "not a portable model artifact" | No | Apache-2.0 |
| vLLM Preload | Processed weights, held in GPU memory by a daemon on the node | Tensor, expert and data parallel | No: the daemon lives on the node | No | Apache-2.0 |
| Modal GPU memory snapshots | A container's CPU and GPU memory | "Generally incompatible with multi-GPU code" | Within Modal's platform | Hosted service | Commercial |
| Cedana | Processes and GPU memory; also live migration | Several GPUs on one node; several nodes in design partnership | With matching versions (compatibility) | Kubernetes or SLURM | Commercial; daemon AGPL-3.0 |
| Weight loaders: Run:ai Model Streamer, fastsafetensors, Tensorizer | Faster reads of the weights only; the engine still compiles, autotunes and captures CUDA graphs | Any | Yes: they read checkpoints from storage | No | Open source |
Restore times are not compared here: each project measures on different GPUs, models and storage. warmctl's own numbers, with the setup behind each, are in the catalog and the blog.
warmctl and Dynamo Snapshot
Both checkpoint a warmed-up engine with CRIU and cuda-checkpoint and restore it on a node with the same GPUs and driver. They differ in what you run and in where a snapshot can go.
| warmctl | Dynamo Snapshot | |
|---|---|---|
| What you install | One static binary on a GPU host with Docker; in Kubernetes, the same binary in a privileged pod | A per-cluster Helm release: a control-plane operator and a privileged node agent with a PageBroker sidecar on every GPU node, plus the GPU Operator 26.3 or newer and a ReadWriteMany storage class |
| Snapshot format | An OCI 1.1 artifact: content-addressed blobs and an image index with one entry per GPU platform | CRIU image files under artifacts/<id>/containers/<name>/ in the cluster's checkpoint store |
| Where snapshots live | Any OCI registry: GHCR, ECR, Harbor, Docker Hub, registry.warmctl.io; a mirror next to the GPUs; or a shared file system | One store per installation: a shared ReadWriteMany volume, or an S3-compatible bucket (experimental), tracked by the cluster's PodSnapshotContent objects |
| Across clusters and clouds | Push once and pull wherever the GPUs and driver branch match: another cluster, another cloud, on premises. warmctl mirror copies models between registries | Restores within the installation that took the checkpoint; the docs do not describe moving checkpoints to another cluster |
| Prebuilt snapshots | A public catalog of popular models with measured restore times | None; you checkpoint your own pods |
| Engines | vLLM | vLLM, SGLang, TensorRT-LLM |
| Status | Beta (Status and limits) | Not yet recommended for production-critical workloads |
Sources for Dynamo Snapshot: its README, Storage, S3 storage contract and Limitations, as of v0.2.0.
When to pick something else
- You serve with SGLang or TensorRT-LLM. Dynamo Snapshot supports both; warmctl restores only vLLM for now.
- Your GPUs are in one Kubernetes cluster that already runs Dynamo, the GPU Operator and fast ReadWriteMany storage. Dynamo Snapshot fits into that stack.
- Your engine fits one GPU and restarts on the same machine. vLLM's initialized snapshots are built in.
- You keep a process on each node anyway and only want the weights back fast. vLLM Preload does that without snapshots.
- You deploy on Modal. Its GPU memory snapshots need nothing of your own to run.
- You want a commercial product with support, or checkpoints under SLURM. Cedana.
- Most of your start is downloading weights. A fast loader may be enough; it leaves compilation, autotuning and graph capture in every start.
When warmctl fits
- A vLLM engine of up to eight GPUs on one node, including large MoE models in tensor or expert parallel.
- Snapshots that move like container images: push to and pull from any OCI registry, mirror them near the GPUs, or keep them on a shared file system.
- Fewer moving parts: one binary on the GPU host instead of an operator, node agents and a shared volume. Kubernetes and KServe are options, not requirements.
- One snapshot for several clusters or clouds: push it to a registry once and pull it wherever the GPUs and driver branch match.
- Prebuilt snapshots of popular models in the public catalog, with measured restore times.
What none of them does yet
None of these restores an engine that spans several nodes, and none restores onto another GPU model or driver branch: GPU state is only valid where it was taken (why). What warmctl does not support yet is listed in Status and limits.