NVIDIA Snapshot 是 NVIDIA 于 2026 年 11 月 10 日在官方技术博客介绍的开源组件，作用是把已经完成初始化的 GPU 推理负载保存为检查点，并在兼容节点上于数秒内恢复，跳过权重加载、编译和 CUDA 图捕获等重复步骤。它适合在 Kubernetes 上运行 vLLM、SGLang 或 TensorRT LLM 的团队，尤其是需要频繁扩容和故障重建的推理服务。普通 VPS 或未提供 GPU 实例与 Kubernetes 的环境无法直接使用。

NVIDIA Snapshot 解决的是哪一段等待

大模型推理副本从启动到可以对外服务，通常要经历启动进程、加载模型权重、初始化 KV 缓存和运行时缓冲、编译与自动调优内核、捕获 CUDA 图等阶段。NVIDIA 把这一过程称为冷启动，耗时从几十秒到十几分钟不等。当流量突增或某个副本失败时，GPU 虽然空闲，服务能力却不能立刻补上。

Snapshot 的思路是：在负载已经完整初始化后，把 CPU 与 GPU 内存状态一起保存成可移植的检查点产物；之后新建 Pod 时，从该产物恢复，进程从检查点位置继续运行。这样，权重加载、编译和 CUDA 图捕获都不需要重复执行。

需要区分的是，Snapshot 并不负责创建机器和拉取容器镜像。NVIDIA 的基准测试也明确把镜像拉取和容器运行时准备排除在测量之外。因此它缩短的是“负载初始化”这一段，而不是从零开通一台云主机的全部时间。

它如何接入 Kubernetes

Snapshot 通过 Kubernetes 自定义资源工作，主要操作有两个：

• 检查点：对一个已运行的 Pod 创建 PodSnapshot，捕获其 CPU 和 GPU 内存状态；如果希望 Pod 就绪后立即保存，可以使用 SnapshotJob。
• 恢复：在新 Pod 上添加注解 nvidia.com/restore-from，指向已有的 PodSnapshot。

工作负载需要在检查点前暂停、恢复后继续，完成一次握手。官方仓库提供了 vLLM、SGLang 和 NVIDIA TensorRT LLM 的现成示例，适合先在小模型上验证流程。

恢复的硬性条件是目标节点使用相同 GPU 型号和驱动。跨不同 GPU 型号或驱动版本恢复，不在官方给出的兼容范围内。对于单节点多 GPU 的张量并行、数据与专家并行、解码上下文并行，Snapshot 可以把多个 rank 作为单个检查点产物处理，官方给出的上限约为 1 TB 检查点、跨 8 块 GPU。

官方基准数据怎么读

NVIDIA 公布的测试环境为 NVIDIA B200 GPU、驱动 615.71.09、VAST（NFS）存储，推理引擎版本为 vLLM 0.31.0、SGLang 0.5.21、TensorRT LLM 1.3.0。测试覆盖从 6 亿参数小模型到检查点约 1 TB 的 MoE 模型。

核心结果可以概括为三点：

• 所有测试配置下，恢复时间为 3.6 至 42.7 秒，相比冷启动提速 8 至 36 倍。
• 检查点创建耗时 15 秒至 5.5 分钟，属于每个模型与配置的一次性成本；在所有测试配置中，检查点加恢复的总时间仍短于一次冷启动。
• 大模型恢复时，把 GPU 状态写回显存占主要时间，8 卡 MoE 配置下为 18 至 29 秒；CRIU 恢复 CPU 进程状态为 4.2 至 10.8 秒。

这些数字的适用范围需要说清楚：它们来自特定 GPU、特定驱动和特定 NFS 存储后端，不能直接套用到其他机房、其他存储类型或其他 GPU 型号。存储读取速度会影响 CRIU 恢复阶段，GPU 型号和驱动会影响 CUDA 恢复的兼容性与表现。若你的环境与测试条件差异较大，应以自己集群上的验证结果为准。

NVIDIA 还引用了合作方的数据：Crusoe 报告在 HGX B300 上把 GLM-5.3 的 Pod 就绪时间从约 8 分钟降到 31 秒；Saturn Cloud 报告在 HGX B300 上把 vLLM 启动从 2 至 8.5 分钟降到 6 至 34 秒。这些属于合作方自述，测试条件和统计口径与 NVIDIA 主基准不完全相同，阅读时应分开看待。

对云上 AI 推理部署的实际影响

扩容与故障恢复

如果推理服务采用按流量弹性伸缩，或某个副本异常后需要快速补位，Snapshot 的收益会随恢复次数放大。恢复从分钟级降到秒级，意味着在流量高峰到来时，新增副本能更快进入服务状态。

按需算力的成本口径

按小时或按秒计费的 GPU 实例，在副本初始化期间通常已经在计费，但没有产生有效推理吞吐。缩短初始化时间，理论上可以减少这部分空转。不过是否真正省钱，要看三点：快照产物的存储费用、恢复时读取快照的存储带宽，以及实例本身的最小计费周期。官方基准没有给出成本测算，快照体积从数 GB 到约 1 TB 不等，需要结合自己的存储方案单独估算。

普通云服务器与 VPS 读者

Snapshot 要求 Kubernetes 环境、NVIDIA GPU、相同型号与驱动，普通海外 VPS 或没有 GPU 的云服务器无法使用。对关注香港、日本、新加坡、美国等地区云服务器的读者，更现实的问题是：所选服务商是否提供 GPU 实例、是否支持自带 Kubernetes、快照产物放在哪里。这些信息应以对应服务商的官方产品页为准，本文不替任何服务商给出承诺。

在自有 GPU 环境评估 Snapshot 的步骤

以下步骤用于验证可行性，不构成生产上线方案。执行前应确认集群有可用的 NVIDIA GPU、已安装对应驱动，并具备创建 Kubernetes 自定义资源的权限。

1. 在测试集群中准备一个可运行的 vLLM 或 SGLang 推理 Pod，先用小模型跑通基础推理。
2. 按官方仓库说明安装 Snapshot 组件，确认自定义资源可以被创建。
3. 对已初始化的 Pod 创建 PodSnapshot，记录检查点耗时和产物大小。
4. 新建一个带 nvidia.com/restore-from 注解的 Pod，确认它能在相同 GPU 型号和驱动的节点上恢复并继续服务。
5. 分别记录冷启动耗时、检查点耗时、恢复耗时和端到端从创建 Pod 到可服务的时间，注意把镜像拉取时间单独统计。
6. 评估快照产物的存放位置、容量占用和读取带宽，再决定是否把它纳入扩容流程。

操作提醒：检查点产物可能包含模型运行时的内存状态，应按内部数据资产管理，限制访问权限；删除旧检查点前确认没有 Pod 仍引用它，避免恢复失败。

哪些团队值得跟进

推理副本需要频繁弹性伸缩、对故障恢复时间敏感、已经在 Kubernetes 上运行 vLLM 或 SGLang 的团队，可以优先做小规模验证。模型较大、冷启动时间达到数分钟的场景，收益通常更明显。

单副本长期常驻、流量平稳、没有 Kubernetes 运维能力的团队，短期内收益有限，不必为了跟进而改造现有架构。使用普通 VPS 或非 GPU 云服务器的读者，可以先关注服务商的 GPU 产品与 Kubernetes 支持情况，再判断是否有必要进一步评估。

Snapshot 是开源组件，具体安装方式、兼容性要求和后续更新以 NVIDIA 官方仓库与文档为准；涉及云主机规格、GPU 型号、计费方式时，以对应服务商官方页面为准。

常见问题

NVIDIA Snapshot 能用在普通 VPS 上吗？

不能直接使用。它面向 Kubernetes 上的 NVIDIA GPU 工作负载，要求相同 GPU 型号和驱动，普通 VPS 通常不具备这些条件。

恢复时间是否一定在几十秒内？

官方在 B200、特定驱动和 VAST NFS 存储下测得 3.6 至 42.7 秒。换用其他 GPU、驱动或存储后端，结果可能不同，需要自行验证。

快照会占用多少存储？

官方测试中检查点产物从约 8 GB 到约 1 TB 不等，取决于模型规模和并行配置。实际容量应在自己的环境中测量。

检查点需要每次启动都创建吗？

不需要。检查点是每个模型与配置的一次性成本，之后可以复用；模型、引擎版本或并行配置变化后，应重新创建。

它会影响正在处理的请求吗？

检查点前工作负载需要暂停并完成握手，KV 缓存在检查点前释放，不计入产物。生产环境应安排在不影响服务的时间窗口或独立副本上操作。