NVIDIA Snapshot：缩短 GPU 恢复时间，复用初始化状态

1. 复用准备就绪的运行状态

Snapshot 是 NVIDIA DSX AI Factory Platform 的一部分，用于保存并恢复准备就绪时的运行状态。它将 CPU 和 GPU 内存保存为可迁移的文件集合，即制品，并在新任务中恢复，从而避免重复加载模型权重和优化执行等准备步骤。

它最初为 NVIDIA Dynamo 推理工作进程开发，但也可与其他推理引擎、决定任务部署位置的调度器、按期望状态进行调整的控制器及平台集成。

对于在同一节点上同时使用多个 GPU 的兼容工作负载，它也会将其保存为单个制品。这也适用于通过并行化将计算分配到多个 GPU 的大型模型。

2. 创建请求对象来保存和恢复

保存运行状态的检查点操作和恢复操作，通过在 Kubernetes 中创建独立的请求对象来执行。要保存运行中的任务，可创建 PodSnapshot；要从模板启动并在准备就绪后立即保存，则使用 SnapshotJob。

恢复时，在新 Pod 上添加 nvidia.com/restore-from 注解，指定所用的检查点。

工作负载需要做好集成，以便在创建检查点前短暂停止，并在恢复后继续运行。NVIDIA 代码仓库提供了 vLLM、SGLang 和 TensorRT LLM 的集成示例，平台团队可据此适配现有推理环境。

3. B200 测试中的恢复时间为 3.6~42.7秒

据公司公布，测试在 NVIDIA B200 GPU、615.71.09 驱动和 VAST(NFS) 存储上进行。以下是在单个 GPU 上运行同一模型的结果，对比了各引擎从零启动的冷启动与已保存状态的恢复。

冷启动即从头初始化运行环境，计时范围为进程启动至引擎初始化完成；恢复则从发出请求计时至服务恢复。

表：Qwen3-0.6B 的冷启动与 Snapshot 恢复

条件：NVIDIA B200，驱动 615.71.09，VAST (NFS)，Qwen3-0.6B，TP1(1 GPU)

单位：时间为秒，提速为倍

在上述使用 B200 和 VAST 存储的结果中，三个引擎的恢复时间都短于冷启动。据公司公布，全部测试配置的恢复时间为 3.6~42.7秒，比冷启动快 8~36倍。使用 8个 GPU 的大型模型在 43秒内恢复了约 600GB~1TB 的检查点，而对应配置的冷启动耗时为 6~19分钟。

设计合作伙伴 Crusoe 表示，在 NVIDIA HGX B300 上，GLM-5.3 Pod 的就绪时间从约 8分钟缩短至 31秒。Saturn Cloud 也宣布，在 NVIDIA HGX B300 上，vLLM 启动时间从 2~8.5分钟缩短至 6~34秒。

4. 大型模型的恢复时间取决于 GPU 状态迁移

冷启动依次经历引擎启动、权重加载、内存准备，以及内核编译、自动调优和图捕获。据公司公布，DeepSeek-V4.1-Flash 的 vLLM 配置中，最后的编译、调优和捕获阶段耗时 784.54秒，总启动时间为 1,110.65秒。Snapshot 保存已完成的初始化状态，从而跳过这部分重复开销。

恢复过程依次为查找制品、还原 CPU 进程状态和 GPU 内存，然后继续执行。CPU 状态通过 Linux 进程保存与恢复工具 CRIU 读取。

据公司公布，使用 8个 GPU 的大型模型在恢复时，GPU 状态迁移耗时 18~29秒，CPU 状态恢复耗时 4.2~10.8秒。要缩短大型模型的恢复时间，需要关注将数据传回 GPU 的环节。

5. 缩短启动时间的代价是保存操作和存储空间

据公司公布，检查点生成耗时因配置而异，为 15秒~5.5分钟，制品大小为 8.04GB~1,039.09GB。生成时间是每种模型和配置的一次性成本；所有受测配置中，保存与首次恢复的总耗时均短于一次冷启动。在减少重复初始化的同时，也必须将保存操作和大容量制品纳入运维考量。

测量时间不包含容器镜像下载和容器运行时准备。恢复需要相同的 GPU 型号和驱动，并满足运行兼容性要求；用于临时保存对话上下文的 KV 缓存在保存前会被清空，不包含在制品中。

Snapshot 通过复用 GPU 工作负载的初始化状态来缩短启动时间，而要获得这一效果，就必须将检查点耗时和存储空间纳入运维设计。