要点
- 2026 年 11 月 10 日，NVIDIA 发表技术博客《Start and Restore GPU Workloads in Seconds with NVIDIA Snapshot》，署名为 Ron Kahn、Dan Feigin、Oz Bar-Shalom、Ekin Karabulut 和 Schwinn Saereesitthipitak。文章把 Snapshot 写成 NVIDIA DSX AI Factory Platform 的开源组件，代码在 https://github.com/ai-dynamo/snapshot。
- 在所有受测配置里，恢复用了 3.6 到 42.7 秒，比可能长达数分钟的冷启动快 8 到 36 倍。文章表 1 中各引擎的区间是：vLLM 为 4.7 到 39.6 秒，SGLang 为 3.6 到 42.7 秒，TensorRT-LLM 为 7.79 到 33.55 秒。多 GPU 检查点最高约 1 TB，分布在 8 块 GPU 上。
- 制作检查点用了 15 秒到 5.5 分钟，取决于模型大小。在所有受测配置里，制作检查点的时间加上恢复时间，都短于一次冷启动。在 NVIDIA B200 加 VAST NFS 存储上，恢复 GPU 状态在大规模恢复中占主要部分，为 18 到 29 秒；基于 CRIU 的 CPU 进程恢复为 4.2 到 10.8 秒。
- 冷启动的计时，从进程启动到引擎初始化返回、开始推理之前为止，分成四个阶段：启动、加载权重、初始化，以及编译和 CUDA graph 捕获。Snapshot 的计时，从发出恢复请求到工作负载重新开始服务为止。机器开通和容器镜像加载，都不在这两段测量之内。
- 恢复只适用于兼容的基础设施，也就是相同的 GPU 型号和驱动。NVIDIA 的文章称，Crusoe 在 NVIDIA HGX B300 上把 GLM-5.3 的 Pod 就绪时间从大约 8 分钟降到 31 秒，Saturn Cloud 在 HGX B300 上把 vLLM 启动从 2 到 8.5 分钟降到 6 到 34 秒。Crusoe 自己同日发表的文章确认了 31 秒这个数字，并补充说该结果是在本地 NVMe 上存放检查点时测得的。
2026 年 11 月 10 日，NVIDIA 发表技术博客，介绍 NVIDIA Snapshot，这是一套面向 Kubernetes 上 GPU 工作负载的开源检查点与恢复系统。由 Ron Kahn、Dan Feigin、Oz Bar-Shalom、Ekin Karabulut 和 Schwinn Saereesitthipitak 署名的文章称，Snapshot 会捕获已完全初始化的 CPU 和 GPU 内存，并把推理副本从数分钟级拉回到数秒级。可核对的主张，并不是稀缺的 GPU 从此不再构成问题。它是：当机群扩容或发生故障时，真正的约束是冷启动，也就是加载权重、编译内核和捕获 CUDA graph 所花费的那些分钟；Snapshot 能在 3.6 到 42.7 秒内恢复这份已初始化的状态，相当于冷启动的 8 到 36 倍，前提是下一台节点具有相同的 GPU 型号和驱动，并且计时被允许忽略机器开通和镜像拉取。
[1]Snapshot 实际测量的是什么
在这篇文章里，冷启动指的是：GPU 已经分配好之后，从新启动的推理进程，把引擎做到可以开始服务、但尚未处理第一个请求。作者把这项工作分成四个阶段：启动进程并导入库，加载模型权重，初始化缓存和运行时缓冲区，以及编译内核、自动调参并捕获 CUDA graph。文章的图 1 还画出更早的两步，也就是开通机器和加载容器镜像，并写明这两步仍在被测量的恢复路径之外。
Snapshot 最初是为 NVIDIA Dynamo 的推理 worker 开发的，其他引擎也可以接入。工作负载完全初始化之后，一次检查点会把它的 CPU 和 GPU 内存捕获成可迁移的产物。一次恢复则从该产物启动一个新的 Kubernetes Pod，也就是一组被调度的容器。工作负载只需要一个很小的握手：检查点前暂停，恢复后再继续。仓库里有面向 vLLM 0.31.0、SGLang 0.5.21 和 TensorRT-LLM 1.3.0 的现成示例，这也是基准测试使用的引擎版本。系统可以把同一节点上的多 GPU 工作负载打成一份检查点，覆盖张量并行、数据与专家并行，以及解码上下文并行。
恢复的计时，从 Snapshot 被要求恢复开始，到工作负载重新开始服务为止。这段时间本身又分成四个阶段：节点上的 agent 定位产物并准备好 Pod 和 GPU；CRIU，也就是 Checkpoint/Restore in Userspace，一种标准的 Linux 进程检查点工具，把 CPU 进程镜像读进主机内存；CUDA 状态被拷回 GPU 内存；进程再适配到新节点并被唤醒。每次检查点前都会释放键值缓存，因此它不是存储产物的一部分。
[1][2]恢复时间与合作方核对
NVIDIA 的数字是在 NVIDIA B200 GPU、驱动 615.71.09、VAST NFS 存储上采集的。在所有受测配置里，Snapshot 在 3.6 到 42.7 秒内恢复副本，比冷启动快 8 到 36 倍。文章称，最大的混合专家模型，检查点约 600 GB 到 1 TB、跨 8 块 GPU，恢复仍在 43 秒以内，而冷启动需要 6 到 19 分钟。按引擎看，区间分别是 vLLM 的 4.7 到 39.6 秒、SGLang 的 3.6 到 42.7 秒，以及 TensorRT-LLM 的 7.79 到 33.55 秒。表中的模型包括 Qwen3-0.6B、Qwen3-14B、gpt-oss-120b、GLM-5.3-NVFP4、DeepSeek-V4.1-Flash，以及 TEP8 设置下的 DeepSeek-V4-Pro-NVFP4，也就是跨 8 块 GPU 的张量并行与专家并行。TensorRT-LLM 没有报告那两个 DeepSeek 配置。
制作检查点用了 15 秒到 5.5 分钟，这是每个模型和配置的一次性成本。在所有受测配置里，这段制作时间再加上随后的恢复，仍然短于一次冷启动。对于 8 卡混合专家配置，恢复 GPU 状态用了 18 到 29 秒，在大规模恢复中占主要部分；基于 CRIU 的 CPU 恢复则为 4.2 到 10.8 秒。
设计合作方也做了自己的检查。NVIDIA 的文章称，作为上游贡献者的 Crusoe，在 NVIDIA HGX B300 上把 GLM-5.3 的 Pod 就绪时间从大约 8 分钟降到 31 秒。Crusoe 自己同日发表的文章确认了这一 15 倍对比，并补充了 NVIDIA 文章没有强调的存储细节：把约 594 GB 的检查点放在本地 NVMe 而不是 NFS 上时，GPU 状态恢复从 33.3 秒降到 15.0 秒，Pod 从创建到 Ready 从 50 秒降到 31 秒。因此，头条里的 31 秒，是本地 NVMe 上的数字。NVIDIA 的文章还称，Saturn Cloud 在 HGX B300 上把 vLLM 启动从 2 到 8.5 分钟降到 6 到 34 秒。我们打开了 Saturn 的文章，区间是吻合的，但除了以 Crusoe 作为来源的那些句子外，这里仍按 NVIDIA 的转述来引用这些数字。
[1][2]计时没有计入什么
冷启动的计时和 Snapshot 的计时，都不包括获得一台机器、以及拉取容器镜像的时间。如果需求突然上升，却还没有已经在跑的节点，或镜像还不在节点上，用户等待的时间就会长于 3.6 到 42.7 秒的恢复。Crusoe 的分解用另一种方式说明了同一点：即使在 agent 完成恢复之后，仍有若干秒的 Pod 启动处在 GPU 状态拷贝之外，而存储选择会把总时间移动数十秒。
冷启动各阶段也说明了加速为什么可以这么大。在一些最大的配置里，编译、自动调参和 CUDA graph 捕获占去了那些分钟的大部分。Snapshot 通过恢复一个已经初始化的引擎，跳过这些重复步骤。当副本宕掉或服务扩容时，这是真实的运维收益。也正因为如此，只有当两边都从一台已经在、镜像也已经在的机器上的进程启动算起，这种比较才公平。
[1][2]相同的 GPU、相同的驱动，以及其他限定
恢复受限于兼容的基础设施：相同的 GPU 型号，相同的驱动。就这篇文章提供的证据而言，在 B200 上制作的检查点，不会在不同的 GPU 或不同的驱动上起来。文章还要求工作负载满足一份已公布的兼容性约定，而且多 GPU 路径针对的是同一节点上的 GPU。检查点产物很大，测试中最高约 1 TB，因此存储带宽会进入恢复时间，Crusoe 对 NFS 和 NVMe 的对比也说明了这一点。
这些是 NVIDIA 及其合作方的测量，不是对正在运行的生产机群的第三方审计。我们打开的 Saturn 文章写得很谨慎：其数字是在已经运行的节点上，从 worker Pod 到第一次成功响应的测量，来自少量成对运行，而不是还必须开通 GPU 节点时用户要等的全部时间。这一限定，同样适用于 NVIDIA 的表格。
[1][2]更公允的读法
更公允的读法是：当需求突然上升或副本宕掉时，跳过加载权重、编译和捕获 graph 的那些分钟，是真实的运维收益，而且合作方的时间指向同一方向。在 NVIDIA 测试的每一种配置里，即便把一次性写入检查点的成本加上一次恢复，墙上时钟也仍短于从零开始一次。对那些已经让兼容节点保持就绪，或能把产物放在快速本地存储上的运营方来说，31 秒和 45 秒以内的数字，才是正确的比较口径。
诚实的界限就在这项发现旁边。头条加速并不包括把机器和容器镜像准备好，如果下一台节点的 GPU 或驱动不同，它也帮不上忙。存储后端和缓存是否预热，同样会移动结果，Crusoe 把同一份 594 GB 产物分别放在 NFS 和 NVMe 上，就已经说明了这一点。Snapshot 改变的是一个已初始化引擎的再启动。它本身并不改变获得 GPU 的时间。
[1][2]谁该在意，接下来看什么
在 Kubernetes 上运行 vLLM、SGLang 或 TensorRT-LLM 的平台团队应当关心，那些因为冷启动太慢而不得不预热多余副本的运营方也应当关心。代码已在 NVIDIA Snapshot 仓库开放，文章也称其他引擎可以接入。未来六个月里，真正的检验是：恢复在驱动升级和新的 GPU 型号上是否仍然成立；除了已点名的三个引擎示例之外，是否还有引擎提供受支持的集成；以及运营方是否公布把节点开通和镜像拉取计算在内、而不是排除在外的生产级从零扩容时间。
[1][2]收束
Snapshot 让一个已初始化的 GPU worker 可以被再次使用，测得的恢复时间也短到足以在副本故障或流量上升时起作用。这种比较只在相同的 GPU 和驱动上成立，而且只在机器和镜像都已经就位之后成立。机群若开始依赖这些"数秒"，就需要把这些条件一直附在数字旁边。
[1]