NVIDIA 将 OpenShell 捐赠给 CNCF，并新增开源 AI 工厂工具

NVIDIA 于2026年11月10日在 KubeCon + CloudNativeCon 上宣布，将其 OpenShell 智能体安全运行时捐赠给 Cloud Native Computing Foundation (CNCF) Sandbox，并为其 DSX AI Factory Platform 发布三个开源组件。

这些公告将智能体治理与高效运行智能体所需的基础设施联系起来。NVIDIA还将参与由 Google 发起的 Agent Substrate 项目，并为 DSX 增添 Kubernetes Engine、Kubernetes Recipes 和 Snapshot，涵盖会话执行、集群管理和推理恢复。

OpenShell 迈向社区治理

自主智能体使用工具、访问推理服务并执行工作负载时，OpenShell 会实施确定性控制。它在内核隔离的沙箱中运行智能体，并通过声明式 YAML 策略管理文件系统、网络、进程和服务提供商凭据的访问权限。凭据只会注入发往获准端点的请求；在批准前，形式化验证会检查拟议的策略变更是否会授予新的高风险访问权限。

该运行时采用 Apache 2.0 许可证。NVIDIA 表示，已有数百家机构使用该运行时；在不到一年的时间里，项目收到了数万项贡献；参与 Sandbox 治理的机构将包括那些把它集成到产品中的组织。迁移工作仍在进行：一份项目公告称，开发工作正转移至 ai-openshell 组织；迁移期间，代码、问题和拉取请求仍保留在 NVIDIA/OpenShell。

Agent Substrate 着眼于闲置计算资源

Agent Substrate 旨在降低维持智能体会话运行的成本。智能体经常需要等待提示、工具结果或模型响应；专用的预热 Kubernetes Pod 会在这些间隔期间持续占用资源，而重新创建 Pod 则会丢失状态，并再次经历冷启动。NVIDIA 和 Google 还在合作开发 OpenShell 集成，以支持在云端和本地系统中运行的智能体。

Agent Substrate 的设计将大量有状态会话映射到规模更小的预热工作节点池。它会为闲置会话创建检查点，包括内存和文件系统状态，释放其占用的工作节点，再将会话恢复到可用节点上，而无需重新走常规的 Kubernetes Pod 创建流程。这些工作节点仍是普通 Kubernetes Pod，因此集群调度、配额和放置策略仍然适用。目标工作负载包括编程助手、强化学习环境和短期 GPU 研究沙箱。

NVIDIA 正在开发与 Dynamo 的互操作能力，以支持推理；同时也在开发与 KAI Scheduler 的互操作能力，以管理共享集群资源。Dynamo 可提供预计首个令牌生成时间和 GPU 池饱和度，供 Agent Substrate 据此决定让智能体继续驻留、暂停还是恢复。Dynamo 的 API 仍在变化，GPU 支持正围绕 Kubernetes 动态资源分配进行重构，且 Dynamo 集成的部分功能仍处于实验阶段。

DSX 新增集群管理功能并加快恢复速度

NVIDIA Kubernetes Engine 和 NVIDIA Kubernetes Recipes（NVKE 和 NVKR）已在 Apache 2.0 许可下开放公开预览。NVIDIA 表示，这些项目的 API、配置和行为可能发生变化，目前尚不建议将其用于生产工作负载。NVKR 使用固定版本的源构建可复现的节点映像、容器映像、二进制文件和 Helm chart，并记录所用输入。NVKE 则利用这些制品，通过 REST API 和控制器来配置和运维集群，不过两个项目也可以单独采用。

NVKE 创建客户工作负载集群，每个集群都配备独立的 Kubernetes 控制平面、etcd 实例和节点池。它通过 NVIDIA Infra Controller 及其 Cluster API 提供程序 CAPNICo 获取裸金属容量；节点必须先出示经过证明的 SPIFFE 身份，才能获得加入集群所需的凭据。Firmus 和 SK Telecom 正在将这些项目集成到各自的 AI 工厂中；Mirantis、Netris、OpenNebula Systems、Rafay、Spectro Cloud 和 vCluster 则计划将其集成到各自的基础设施平台、托管 Kubernetes 服务或网络自动化方案中。

NVIDIA Snapshot通过为完全初始化的工作负载创建 CPU 和 GPU 内存检查点，来应对推理冷启动问题。恢复时必须使用相同型号的 GPU 和相同的驱动程序，而且无需重复加载权重、编译或捕获 CUDA 图。

NVIDIA 表示，在使用 VAST NFS 存储的 B200 GPU 上，vLLM、SGLang 和 TensorRT LLM 配置下的恢复时间为 3.6 至 42.7 秒，相比冷启动提速 8 倍至 36 倍。测试涵盖了从一个 6 亿参数模型到使用 8 块 GPU、检查点接近 1 TB 的配置。创建检查点耗时为 15 秒至 5.5 分钟；在所有受测配置中，创建检查点加恢复的总时间都短于一次冷启动。

这些数据并不代表整台机器的启动时间：基础设施配置和容器映像加载均不在计时的恢复流程之内。此外，每次创建检查点前都会释放键值缓存，而不是将其保留在制品中；因此，这些结果反映的是在兼容基础设施上恢复已初始化的工作负载。

Crusoe 在 NVIDIA HGX B300 上进行的自有 GLM-5.3 测试使用了包含 594 GB GPU 状态的检查点。Crusoe 测得，从本地 NVMe 恢复 GPU 状态需要 15.0 秒，而从 NFS 恢复则需要 33.3 秒。将制品存放在 NVMe 上时，从创建 Pod 到就绪耗时 31 秒；相比之下，冷启动大约需要 8 分钟，这表明存储是影响恢复性能的重要因素。Crusoe 还向上游贡献了性能优化和诊断方面的改进。

综合来看，这些项目将 AI 工厂控制平面和恢复流程的更多部分纳入开放代码仓库，但成熟度各不相同：OpenShell 的治理转型尚未完成，Agent Substrate 仍在演进，NVKE 和 NVKR 则仍处于预览阶段。Snapshot 的基准测试展现了最明确、经实测验证的运维收益；与此同时，其兼容性要求以及 Crusoe 的存储测试结果表明，更快的恢复既取决于可复用的工作负载状态，也取决于周边基础设施。