NVIDIA Agent Substrate：Kubernetes 如何回收智能体的空闲资源

从常驻会话转向共享执行池

NVIDIA 在此次技术文章中介绍，Agent Substrate 把大量有状态会话映射到较小的预热 Kubernetes worker Pod 池。会话对应的 Actor 空闲时保存内存和文件系统，下次调用时恢复到可用 worker。对编码助手平台，直接变化是：仓库、进程和工作目录的延续，不再要求每个会话持续占住专属 Pod。集群保留一组执行资源，会话状态则可以在不占用活跃 worker 的情况下保存。NVIDIA Technical Blog

作者判断，这种设计最可能帮助等待时间长、实际动作短的负载，例如智能体修改代码后等待模型响应或人工审阅。持续编译、长时间仿真等始终活跃的任务，可释放的空闲资源较少。原文声称相对标准容器可实现十倍密度，但没有给出足以复现该结果的负载结构、基线配置和完整测量方法。这应作为待验证的厂商主张，不能直接换算成成本下降幅度或响应提速。

快照缩短创建路径，恢复仍有成本

Agent Substrate 让 Kubernetes 管理预热 Pod 池，再由独立控制面把 Actor 分配给 worker。Actor 从 gVisor 或 microVM 沙箱中保存状态，恢复时使用已有 worker，因此无需为每次唤醒重新经过 Pod 创建所涉及的 API server、调度器和 kubelet 路径。作者推论，收益来自避开反复创建环境的开销；快照写入、状态读取和内存恢复仍然需要时间。内存占用大、文件变化频繁的会话，可能把瓶颈转移到存储或数据搬运。

worker 全忙时，原文介绍的 request parking 会暂存请求并重试恢复，同时限制等待时间和排队数量；后续工作还针对已运行 Actor 的请求绕过等待队列。这把部分即时失败转成有界等待，却不会增加实际执行容量，仍需观察突发流量下的超时与公平性。microVM 的容器级 CPU、内存限额则缩小资源争抢的影响范围，内存超限时仅停止对应容器。这些机制解决不同层面的问题，不能用平均密度指标代替排队和隔离验证。NVIDIA Technical Blog

Dynamo 让等待时间成为调度信号

原文描述的协同机制是：Agent Substrate 管理执行环境，Dynamo 管理 GPU 推理。路由器结合会话身份、工具调用边界与 KV 缓存位置，把相关模型请求送往已有可复用上下文的推理 worker，并兼顾负载，避免形成热点。执行侧 Actor 快照与推理侧 KV 缓存分别保存不同状态，需要各自管理。作者判断，会话标识只能提供关联线索，实际复用仍要核对输入前缀、模型配置和缓存有效性，不能仅凭属于同一会话就认定缓存命中。

Dynamo 还可反馈预计首 token 时间、完成时间、请求进度及 GPU 池饱和度，帮助运行时决定保持 Actor 常驻、在长等待期间挂起，或提前恢复。对需要完整模型输出才能执行工具的任务，预计完成时间更直接。待验证假设是：预测足够准确，且等待长度足以摊薄快照与恢复开销。预测偏差可能导致反复挂起，或让工具执行等待恢复。原文明确承认部分集成仍属实验性质，因此控制策略及收益不能视为已经稳定验证。NVIDIA Technical Blog

GPU 恢复仍受设备兼容性约束

GPU 沙箱面临额外状态：智能体等待审阅时，即使文件和进程已保存，要释放 GPU 后延续执行，还须保存并恢复设备状态。原文提出基于 Kubernetes Dynamic Resource Allocation（DRA）的设计，由设备厂商描述安全暂停方式和快照依赖的设备属性，恢复时匹配设备。GPU 快照通常要求相同型号，有时还要求相同驱动版本；没有匹配设备时回退到干净的冷启动。NVIDIA GPU 是首个目标，相关支持正在重建，不能据此宣称 GPU 状态可任意迁移。NVIDIA Technical Blog

作者判断，这意味着可用 GPU 总量之外，还要考虑符合恢复条件的设备是否空闲，以及冷启动能否重建任务所需状态。另一层调度由 KAI Scheduler 承担：它放置普通 worker Pod、训练器和推理服务；Actor 的频繁挂起恢复由 Substrate 管理。worker 池扩缩容与 KAI 队列、公平份额进一步联动，仍是原文提出的发展方向。项目归属也需分清：Dynamo 和 KAI 属于 DSX OS，Agent Substrate 则是与其互操作的独立 CNCF Sandbox 项目。

用真实会话验证资源收益与状态连续性

评估云端智能体时，可固定模型、智能体框架、任务集、隔离方式与资源上限，对比专属常驻 Pod、按需创建 Pod 和预热 worker 池。编码助手应覆盖短等待、长等待及持续构建，记录端到端交互延迟、恢复时间、排队尾延迟、CPU 和内存占用、快照体积及错误。RL 环境还应观察批次完成时间与训练器等待：慢环境仍可能拖住整批任务。研究型 GPU 沙箱则应加入设备等待和恢复失败场景，避免把资源占用改善当成任务吞吐改善。

状态正确性需要单独验收：挂起前后核对进程、文件和工作目录，并检查外部连接、凭证刷新、取消重试、节点故障及重复工具副作用。内存和文件快照并不自动证明外部服务连接也能连续恢复。GPU 场景要分别验证匹配设备上的恢复与不匹配时的冷启动回退；队列、容器限额和租户隔离也需承压检查。所给原文仍含部署指南链接占位，API 又在变化，验收应固定具体版本。以上均为建议验证方法，本文未执行性能或兼容性测试。