What happened
NVIDIA's November 10, 2026 technical blog introduces Snapshot as an open-source component of the NVIDIA DSX AI Factory Platform. Originally developed for NVIDIA Dynamo inference workers, it is designed to provide checkpoint and restore capabilities that other inference engines, schedulers, controllers, and platforms can integrate. A checkpoint captures a fully initialized workload's CPU and GPU memory as an artifact. A restore starts a new Kubernetes Pod from that artifact on a node with the same GPU model and driver. The workload resumes from its saved state, skipping weight loading, compilation, and CUDA graph capture.
The workflow uses Kubernetes custom resources. Teams can create a PodSnapshot for an already-running Pod, or a SnapshotJob to start a Pod from a template and checkpoint it once ready. A new Pod is restored by adding the nvidia.com/restore-from annotation naming the checkpoint. The workload needs a small handshake to pause before checkpointing and resume after restoration. NVIDIA lists ready-made examples for vLLM, SGLang, and TensorRT LLM. Snapshot can also checkpoint compatible multi-GPU workloads on a single node as one artifact across ranks, including configurations using tensor parallelism, data and expert parallelism, and decode context parallelism.
NVIDIA benchmarked vLLM 0.31.0, SGLang 0.5.21, and TensorRT LLM 1.3.0 on NVIDIA B200 GPUs, using VAST NFS storage, across one to eight GPUs. The tested models ranged from Qwen3-0.6B to mixture-of-experts models with checkpoints approaching 1 TB. Across configurations, restore times were 3.6 to 42.7 seconds, or 8 to 36 times faster than cold starts. The largest listed checkpoints, about 600 GB to 1 TB over eight GPUs, restored in under 43 seconds; cold starts took 6 to 19 minutes. NVIDIA says checkpoint creation took 15 seconds to 5.5 minutes and that checkpoint-plus-restore was faster than one cold start in every tested configuration.
Those measurements have a defined boundary: both cold-start and restore timings exclude container image pulls and container-runtime setup. NVIDIA's method measures cold start from process launch until engine initialization returns, and restore from the restore request until the workload is serving. For large eight-GPU MoE restores, moving GPU state took 18 to 29 seconds; restoring CPU process state with CRIU took 4.2 to 10.8 seconds. NVIDIA says the repository includes benchmarking tools and reproduction instructions.
What the archive adds
New Runtime's earlier coverage described NVIDIA's Run:ai platform becoming free and open source on October 18, 2026 (earlier coverage), and its local inference server Flare on October 22, 2026 (earlier coverage). Snapshot is a new event on the same broad infrastructure thread: this release focuses specifically on preserving and restoring initialized GPU workload state, rather than GPU sharing or local serving.
Trend signal
This supports the pattern that agent and inference infrastructure is increasingly shaped by the runtime and orchestration layer, not only by model choice. Snapshot's value is in restoring a workload's initialized state within Kubernetes, with explicit compatibility conditions and a workload handshake. It is a concrete but vendor-benchmarked example of the broader harness architecture outlives model choice pattern.
Why it matters
For teams serving large models, cold starts are not just a deployment inconvenience: they delay scale-out when demand rises and prolong recovery when a replica fails. Reusing an initialized state could make GPU capacity available faster without paying the repeated cost of loading weights and preparing kernels. The reported effect is substantial in NVIDIA's tests, especially for multi-GPU MoE configurations, where cold starts reach minutes.
The operational trade-off is that checkpointing introduces an artifact lifecycle and a compatibility contract. Teams need to provision storage for checkpoint files, manage when snapshots are created and reused, and ensure the target node has the required GPU and driver. The measurements also do not include image pulls or runtime setup, so they should not be read as end-to-end time from an autoscaling decision to a fully available service. Snapshot is most relevant where initialization dominates the recovery path and the infrastructure can preserve compatible placement.
What happens next
- Integrations beyond NVIDIA's listed examples will appear in the project repository. (6 months, 60%). Watch for: documented integrations or tested configurations for additional inference engines and Kubernetes platforms.
Limits and uncertainty
The published benchmarks are NVIDIA's own tests on B200 GPUs with VAST NFS storage; they do not establish results for other GPU models, storage systems, cluster configurations, or workloads. Restore requires the same GPU model and driver, and the source says compatible workloads must meet Snapshot's checkpoint/restore and runtime requirements. The figures exclude image pulls and container-runtime setup, so real-world scale-out latency can be longer. NVIDIA does not report independent replication of the results or production adoption rates. Although the repository includes reproduction instructions, the published results remain vendor benchmarks rather than an independently verified comparison.
Skill to build now
If your team runs Kubernetes inference on vLLM, SGLang, or TensorRT LLM, map the current cold-start path before trying Snapshot: separate image pull and runtime setup from engine startup, weight loading, initialization, and compilation. That gives you a fair baseline against the restore measurement and helps identify whether initialization is actually your bottleneck. Then test one representative workload with the repository's example configuration and verify GPU/driver compatibility before making an autoscaling or recovery plan depend on it.
Reader takeaway
Snapshot targets a specific expensive part of inference operations: repeating initialization every time a GPU replica starts. NVIDIA reports restoring tested workloads in seconds, including very large multi-GPU models, but the result depends on compatible hardware and does not include container setup. Treat it as a promising Kubernetes recovery and scaling tool to benchmark against your own end-to-end path, not a guarantee of sub-minute readiness in every deployment.