NVIDIA将Agent Substrate捐入CNCF沙箱：为智能体工作负载改进Kubernetes
NVIDIA技术博客宣布，开源运行时Agent Substrate已捐赠给CNCF Sandbox。它把大量智能体会话复用在一小池worker Pod上，空闲会话被检查点保存后可恢复到任一空闲worker，NVIDIA称其智能体部署密度比标准容器高 10 倍。
AI解读：要弄清的问题是：Agent Substrate解决的是哪一类Kubernetes不擅长的负载。按NVIDIA博客的描述，智能体的典型模式是执行一步操作（跑shell命令、改文件、调模型）后进入等待，状态（文件系统、进程、工作目录）需在两次请求之间保留；若为每个会话保留一个Pod，大量内存被闲置会话占用；若每次按需创建Pod，则要经过API server、调度、kubelet、镜像拉取等步骤，付出数秒冷启动并丢失状态。
它的做法是把Kubernetes限定为“提供一池就绪Pod”：另建控制平面，把大量Actor（智能体和其环境）映射到这池较小的worker上；Actor空闲时从gVisor或microVM沙箱中快照出去并释放worker，再次被调用时恢复到任一空闲worker，内存和文件系统状态保持，唤醒不再走API server、调度器和kubelet。worker Pod仍是普通Kubernetes Pod，集群调度、配额和放置策略继续适用。
适用范围据文中列举有三类：编码助手与智能体服务，数千会话不能各配一个常驻热沙箱；带可验证奖励的强化学习后训练，环境需求随rollout批量突发，可从早期数百个扩到生产数十万个，最慢环境会让GPU空等；研究用GPU沙箱，如编译CUDA代码、跑内核基准，需要大量短生命周期、隔离且快速启动的GPU沙箱。
NVIDIA在文中列出的上游进展包括：路由层请求排队（#221），worker全忙时不再立即报错，而是有界等待并限制排队数量，后续 #1229 保证对已运行Actor的请求不被卡住；基于Kubernetes DRA的设备可插拔（#752），每个容器只申请所需设备，gVisor与microVM均适用，NVIDIA GPU为首个支持设备；microVM沙箱的按容器CPU/内存限制（#859），超限容器单独停止而不影响沙箱其余部分。
与NVIDIA Dynamo的集成被描述为让推理路由感知智能体：Dynamo暴露预计首token时间、预计完成时间、请求进度、缓存就绪度和GPU池饱和度等信号，Agent Substrate据此决定让Actor常驻、在较长推理等待中挂起、或在回复临近完成时恢复。恢复GPU检查点通常要求同一GPU型号、有时还要求同一驱动版本，文中提出由设备厂商描述可安全暂停方式与快照依赖属性，匹配不到则回退为冷启动。
成熟度方面，NVIDIA自述Agent Substrate的API仍在变化，GPU支持正基于DRA重建，Dynamo智能体集成部分为实验性。文中说明它是独立的CNCF Sandbox开源项目，不属于DSX OS的命名组件，NVIDIA正在上游贡献并开发与DSX OS组件的互操作。10 倍密度为NVIDIA的说法。
NVIDIA技术博客发文称，Agent Substrate已捐赠给云原生计算基金会（CNCF）Sandbox。该项目被描述为面向沙箱化智能体的开源、安全加固、零信任运行时，目标是安全运行数百万个智能体与工具，密度比标准容器高 10 倍。
文章称Kubernetes并非为智能体负载设计：为每个会话保留一个Pod，会让闲置会话占用内存；在轮次之间删除Pod，则每次付出数秒冷启动并丢失智能体状态。Agent Substrate让多个会话复用一小池worker Pod，空闲会话连同内存和文件系统被检查点保存，下个请求到来时恢复到任一空闲worker。
适用负载与运行方式
文章把智能体负载与长驻Web服务对照：智能体醒来执行一步，如运行shell命令、编辑文件、调用测试套件或调用大模型，然后等待，可能几毫秒也可能几分钟，下一步仍要延续之前的文件系统、进程和工作目录。创建Pod要经过API server、准入、etcd、调度器、kubelet、镜像拉取和网络配置，耗时数秒，对每周运行的服务可以接受，但不适合每秒数百次出现、跑 10 毫秒bash命令即退出的沙箱。
Agent Substrate让Kubernetes负责运行一池就绪Pod，另建控制平面把大量Actor映射到较小的worker池。Actor空闲时从gVisor或microVM沙箱快照出去并释放worker；再次调用时恢复到任一空闲worker，内存和文件系统状态保持，唤醒不需重新经过API server、调度器或kubelet。worker Pod仍是普通Kubernetes Pod，集群调度、配额和放置策略继续适用。
三类需求场景
文章列举三类推动该项目的负载。
编码助手与智能体服务：编码智能体在大模型调用与自身环境操作之间交替，如克隆仓库、编辑文件、运行构建和测试；用户期望环境跨轮次保留并即时响应，服务数千会话的平台无法为每个会话配一个常驻热沙箱。
强化学习后训练：带可验证奖励的强化学习同时运行GPU训练器和生成服务器，以及大量CPU密集环境（代码沙箱、编译器、浏览器、模拟器）；沙箱需求随rollout批量突发，训练可从早期数百个沙箱扩到生产数十万个；最慢的环境决定训练器何时拿到下一批，这条路径上的冷启动会让GPU空等。
研究用GPU沙箱：研究者的编码智能体需要GPU来编译CUDA代码、跑内核基准或做数值计算；在共享集群上启动GPU沙箱、运行任务、再删除，需要组织内大量短生命周期、隔离、快速启动并公平共享有限GPU的沙箱。
已提交的上游改动
文章称以下工作均在Agent Substrate公共仓库中，且各自源于上述用例。
请求排队：在过载系统中，用户下一轮请求可能在所有worker忙时到达，Agent Substrate过去会立即返回错误；#221 让路由器保留请求并重试恢复，直到有worker空闲，等待有上限且并发排队数量受限；#1229 确保对已运行Actor的请求不会卡在该队列中。
沙箱内提供GPU：面向研究用GPU沙箱和GPU支持的强化学习环境，NVIDIA正在做基于Kubernetes动态资源分配（DRA）的设备可插拔，设备厂商通过profile接入，沙箱内每个容器只申请所需设备（#752），同一模型适用于gVisor和microVM沙箱，NVIDIA GPU将首个支持。
容器间资源隔离：智能体沙箱常在智能体工作负载旁运行日志、代理或指标等辅助容器，其中可能有不可信者；#859 为microVM沙箱增加按容器CPU和内存限制，超过内存限制的容器单独停止，沙箱其余部分继续运行。
GPU沙箱的挂起与恢复：智能体暂停等待人工审核时，沙箱应释放GPU，之后恢复时编译产物和已加载数据仍在；这需要同时保存和恢复智能体状态与GPU状态。文章称GPU检查点通常只能恢复到同一GPU型号，有时还要求同一驱动版本；其设计让设备厂商描述如何安全暂停设备及快照依赖哪些设备属性，Agent Substrate记录这些属性并在匹配设备上恢复，无匹配设备则回退为冷启动。该设计厂商中立、基于DRA，NVIDIA GPU为首个目标。
与Dynamo的分工和当前状态
文章把Agent Substrate与NVIDIA Dynamo的关系描述为：前者管理智能体在哪里执行，后者管理推理在哪里进行。Dynamo路由能看到可复用KV缓存所在位置、哪些worker正忙于prefill或decode、GPU集群负载分布；Agent Substrate和智能体框架补充会话身份、请求优先级、预期输出长度、工具调用边界和生命周期事件等信号，供Dynamo把相关模型调用留在已有KV缓存的worker上、在推理池紧张时优先交互轮次、在工具调用间隙保留系统提示和对话历史，并优先丢弃已终止子智能体或已关闭推理分支的缓存状态。
反向的信号流被文章称为集成的关键：Dynamo向Agent Substrate暴露预计首token时间、预计完成时间、请求进度、缓存就绪度和GPU池饱和度等，Agent Substrate据此决定让Actor常驻、在较长推理等待中挂起、或在模型回复临近完成时恢复；在集群规模上还可用于调整热worker容量和限制智能体及其子智能体的扇出。
成熟度上，NVIDIA自述Agent Substrate API仍在变化，GPU支持正基于新的DRA基础重建，Dynamo智能体集成部分为实验性。文章说明Agent Substrate是独立的CNCF Sandbox开源项目，不是DSX OS的命名组件，NVIDIA正在上游贡献并开发与DSX OS组件的互操作；KAI Scheduler可在今天把Substrate worker Pod与GPU训练器、推理服务器一同放置。