AREX Feed Article
英伟达在 KubeCon 开源 DSX AI Factory 组件：Snapshot 秒级恢复检查点推理副本，OpenShell 捐入 CNCF Sandbox
2026 年 11 月 10 日，，为 KubeCon + CloudNativeCon North America 2026 开源 的一组组件。其中面向推理扩容的新组件是 （仓库 ai-dynamo/snapshot）：一个模块化组件，服务 Kubernetes 上的推理与 agentic 负载，在推理需求激增或副本故障时，不重新加载模型、无需预热，直接从检查点把推理副本在数秒内恢复上线。公告援引的设计伙伴自报测量显示，Crusoe 在 Crusoe Cloud 上测试 GLM-5.3，负载就绪时间从约 8 分钟缩短到 31 秒。
同一份公告还带来三件事：（NVKE）与 （NVKR）进入公开预览；管控自主 agent 的开源运行时 捐入云原生计算基金会（CNCF）Sandbox；Google 发起的 Agent Substrate 已被 CNCF Sandbox 接纳，英伟达在向上游贡献它与 NVIDIA Dynamo、KAI Scheduler 的集成。公告写明，Crusoe 与 Saturn Cloud 的提速数字是两家设计伙伴在 上的自报结果。
Checkpoint、Restore 两个动作：把初始化完成的 GPU 工作负载整个存下来
解释了 Snapshot 的来路：它最初为 NVIDIA Dynamo 的推理 worker 开发，针对的是 LLM 工作负载的冷启动——拉起一个副本要依次完成容器启动、加载模型权重、分配 KV cache（键值缓存）、torch.compile 编译和 CUDA graph 捕获，可能耗时数分钟；GPU 明明空闲，服务能力却要等。
Snapshot 只提供两个操作。Checkpoint 把一个已完成初始化的工作负载连同 CPU 与 GPU 内存整体捕获成可移植的检查点产物；Restore 则在另一台兼容节点上从检查点启动新 Pod，进程从检查点处继续，权重加载、编译、图捕获全部跳过。操作走 Kubernetes 自定义资源：对运行中的 Pod 建 PodSnapshot，或在 Pod 模板上建 SnapshotJob 让副本就绪即被检查点；恢复时在新 Pod 上加注解 nvidia.com/restore-from 并指明来源。底层由节点上运行的特权 agent 完成：它调用 CRIU（Checkpoint/Restore In Userspace，Linux 用户态检查点恢复工具）和 NVIDIA 的 cuda-checkpoint 工具，对运行中的进程执行检查点与恢复，工作负载本身只需在检查点前后做一次小的暂停与恢复握手（）。仓库已备好 vLLM、SGLang、TensorRT-LLM 的现成示例，也支持单节点多 GPU：一份跨 rank 的检查点产物覆盖张量并行、数据与专家并行（DEP）、解码上下文并行（DCP），支撑大型 MoE（mixture-of-experts，混合专家）模型的快速启动。
英伟达自己发布的基准跑在 B200 上（VAST NFS 存储，vLLM 0.31.0、SGLang 0.5.21、TensorRT-LLM 1.3.0）：从 6 亿参数的小模型到 8 GPU、检查点约 600 GB～1 TB 的 MoE 模型，所有受测配置的恢复时间在 3.6～42.7 秒之间，比冷启动快 8～36 倍；最大的几个 MoE 配置冷启动要 6～19 分钟，恢复在 43 秒内完成。检查点创建是一次性成本，耗时 15 秒～5.5 分钟，而每一个测试配置里「建检查点加恢复」都短于一次冷启动。恢复阶段的大头是把 GPU 状态搬回显存：8 GPU MoE 配置占 18～29 秒，CRIU 进程恢复只占 4.2～10.8 秒——存储是关键变量。这些测量排除了容器镜像拉取与容器运行时准备；KV cache 在检查点前释放，不进入产物。
Crusoe：594 GB GPU 状态 15 秒搬完，恢复时间的大头在存储
Crusoe 是 Snapshot 的上游贡献者，测试用 release v0.2.0-rc.2 加上自家已并入的 PR #602 代码，在 Crusoe Cloud 的 NVIDIA HGX B300 上对 GLM-5.3 计时，口径从 Pod 创建到 Ready：恢复路径比冷启动快约 15.5 倍。
拆开看，31 秒里最大的份额是 594 GB GPU 状态的搬运。检查点放在本地 NVMe 上时，这一步只花 15.0 秒，吞吐约 40 GB/s；换到 NFS 则要 33.3 秒、约 18 GB/s——NVMe 把这一步的时间砍掉 55%。换用 NVMe 后，agent 总恢复时间从 41.4 秒降到 22.9 秒，Pod 从创建到 Ready 也从 50 秒压到 31 秒，而 CRIU 的进程恢复在两种存储后端上都稳定在 5 秒左右。Crusoe 的结论是：恢复的主要杠杆在存储，存储不再是瓶颈后，剩下的只有几秒 CRIU 和 Pod 生命周期开销。
上游协作也有具体产出。Crusoe 测试中遇到一次恢复失败，界面报 binfmt_misc: Operation not permitted，看着像权限问题；追到 CRIU 的 restore.log 末尾才发现真正的死因——恢复 Pod 缺少源 Pod 的 /cache/vllm 挂载，CRIU 无法重建挂载命名空间。NVIDIA 把问题开成 issue #310，Crusoe 提交的修复 PR #532 已并入 main：CRIU 启动前比对挂载、缺失时直接报出路径、读日志时报最后的致命错误而非早期警告。Crusoe 还提到，NVIDIA 的 Snapshot 工程团队从首轮测试陪跑到性能调优，直到 Crusoe 集群上 GLM-5.3 的启动时间对齐英伟达的内部基准。
Saturn Cloud：从权重到首次回复，1 分 51 秒～8 分 29 秒对 6～34 秒
公告里的另一组数字来自 ，一家帮 AI 云运营商把 GPU 基础设施变成面向客户的品牌化推理服务的 token factory（令牌工厂）平台。它的基准文章发布于 2026 年 11 月 2 日，比 KubeCon 公告早八天，测的是 scale-from-zero（从零扩容）推理。
测试在一台已运行的 Nebius 节点上进行，配八张 B300 SXM6 PC GPU，六块 3.84 TB 本地 NVMe 组成 RAID0，软件为 vLLM 0.31.0 加 Snapshot 0.2.0-rc.3。Qwen3-14B、Qwen3-32B、GPT-OSS-120B 各占一张 GPU，GLM 5.3 NVFP4 用 tensor 加 expert 并行占满八张。计时口径是服务 Pod 创建到对同一短请求返回首次成功回复，权重已下载、镜像已缓存，节点开通、镜像拉取、模型下载和 Snapshot 创建都不计入。结果：Qwen3-14B 从 1 分 51 秒到 6 秒（18.5 倍），Qwen3-32B 从 2 分 11 秒到 8 秒（16.4 倍），GPT-OSS-120B 从 2 分 44 秒到 9 秒（18.2 倍），GLM 5.3 从 8 分 22 秒～8 分 29 秒到 33～34 秒（15.0～15.2 倍）。四份检查点占 34～564 GiB，创建耗时 4～41 秒。
两个口径并不完全一致：英伟达公告把这次评估概括为「vLLM 启动从 2～8.5 分钟缩短到 6～34 秒」，并把它与 Crusoe 一起归在 HGX B300 系统下；Saturn Cloud 自己的博文写的是 Nebius 节点上的 B300 SXM6 PC GPU。这些是自报的初始结果，每个 Qwen 和 GPT-OSS 模型只跑了一组配对实验、GLM 两组，Saturn 在文中明确标注不是平均值。
NVKE 与 NVKR 公开预览：把托管 Kubernetes 做成开源积木
DSX 平台这次开源的另两块是 NVIDIA Kubernetes Engine（NVKE）和 NVIDIA Kubernetes Recipes（NVKR），均已进入公开预览。按公告的定位，它们是在 GPU 基础设施上交付托管 Kubernetes 服务的开源构件：自动化集群生命周期管理，并提供签名、锁定版本的镜像。
公告同时列出了一批计划集成的厂商：Mirantis、Netris、OpenNebula Systems、Rafay、Spectro Cloud、vCluster，以及 Firmus 和 SK Telecom，均与英伟达就把 NVKE、NVKR 能力纳入自家产品达成了集成计划。
OpenShell 捐入 CNCF Sandbox，Agent Substrate 接上 Dynamo 与 KAI Scheduler
OpenShell 是英伟达开源的 agent 安全运行时：agent 调用工具、访问推理服务、执行负载时，它施加确定性控制，让团队按策略管住每一步。其架构可扩展，能接入组织自己的计算资源、推理提供方、凭据存储和监控工具，让治理跨部署环境生效。英伟达在公告中称，上线不到一年，已有数百家组织在使用 OpenShell，项目收到数万次贡献。
CNCF 是 Linux Foundation 旗下非营利组织，也是 KubeCon 的主办方。捐赠落地后，GitHub 上已建好 ai-openshell 组织，组织主页注明 OpenShell「已是 CNCF 的一部分」，但代码、issue 和 PR 暂时仍在 ，迁移尚未完成。Linux Foundation CEO Jim Zemlin 在公告中表示：「云原生社区面临一个新的基础设施挑战：给 agent 安全的运行环境。英伟达把 OpenShell 捐给 CNCF，给了开发者一个可以共同构建的基础，也给了社区塑造 agent 安全如何演进的机会。」
Agent Substrate 则是 Google 发起的 CNCF Sandbox 项目，英伟达在向上游贡献；写明，它是独立的开源运行时，不在 DSX OS 组件清单里，但与 DSX OS 组件发展互操作。它解决的问题与 Snapshot 相邻：agent 大部分时间在等待——等用户输入、等工具返回、等模型回复；为每个会话常驻一个 Pod 是浪费，每次响应都重建 Pod 又要付几秒冷启动，还丢状态。Agent Substrate 的做法是把大量 agent 会话复用到一小池常驻 worker Pod 上：会话空闲时连内存和文件系统一起做检查点、被快照出沙箱（gVisor 或 microVM），worker 随即释放；下一个请求到来时恢复到任一空闲 worker，不重新经过 API server 和调度器。英伟达称其密度可达标准容器的 10 倍。
这次公告把三层接到了一起：Agent Substrate 管 agent 环境的挂起与恢复， 负责推理， 负责共享集群资源分配。英伟达开发者博客描述了集成细节：Dynamo 把推理侧信号——预计首 token 时间、队列压力、KV cache 就绪情况——回传给 Agent Substrate，帮它决定一个 agent 该保持驻留、挂起还是恢复。英伟达与 Google 还在合作 OpenShell 与 Agent Substrate 的集成，让企业能跨云与本地系统统一管控 agent。
边界：同型号 GPU、同驱动，镜像拉取不在秒表之内
这些数字各有边界：Snapshot 的恢复要求目标节点 GPU 型号与驱动一致；检查点按模型与配置一次性创建；NVKE 与 NVKR 目前只是公开预览，OpenShell 向 CNCF 组织的迁移也还没走完。
秒级恢复说的是检查点已就绪、节点已就位之后的路径；客户端从零等到首次回复的完整等待，还要另算节点开通与镜像拉取。落地方面，Crusoe 的博文给出了具体入口：客户现在就可以在 Crusoe Cloud 上对任何 NVIDIA GPU 类型部署 Snapshot，基准工具与复现说明放在 ai-dynamo/snapshot 仓库里。