数据中心 / 云 Agent Substrate：推进 Kubernetes 以支持大规模智能体

开源 Agent Substrate 与 NVIDIA Dynamo 和 KAI Scheduler 在 NVIDIA DSX AI 工厂平台中配合，以协调智能体执行、推理和共享集群资源。

2026年11月10日 作者 Ekin Karabulut 和 Omer Yahud 讨论 (0)

AI 生成的摘要

  • Agent Substrate 通过少量热 Kubernetes worker Pod 复用大量智能体会话，将空闲会话连同完整内存和文件系统状态一起 checkpoint，并恢复到任意空闲 worker 上。
  • 该运行时面向三类工作负载：在 LLM 调用与代码仓库操作之间交替的编码助手、具有突发性 CPU 密集型环境的强化学习后训练，以及用于研究编译和基准测试的短时 GPU 沙箱。
  • 上游贡献包括：在路由器中实现请求停放，以便在所有 worker 都繁忙时对轮次进行排队；为 microVM 沙箱提供按容器资源限制；以及使用 Kubernetes 动态资源分配实现与厂商无关的 GPU 状态暂停与恢复设计。
  • NVIDIA Dynamo 在 GPU worker 之间协调推理，而 Agent Substrate 管理智能体环境；Dynamo 的路由器利用会话身份、KV 缓存位置和工具调用边界，将相关的模型调用保持在已持有可复用上下文的 worker 上。
  • Dynamo 将预计首 token 时间、GPU 池饱和度等推理信号回传给 Agent Substrate，后者据此决定是让 actor 保持驻留、在长时间推理等待期间将其挂起，还是在模型响应接近完成时将其恢复。
  • KAI Scheduler 将 Substrate worker Pod 与 GPU 训练器和推理服务器一同放置，整个组合栈运行在 NVIDIA DSX AI Factory Platform 上，Substrate 作为独立的 CNCF Sandbox 项目与 DSX OS 组件集成。

后续步骤

由 NVIDIA Nemotron 提供支持。AI 生成的内容可能不完整地概括信息。请核实重要信息。 了解更多

AI 智能体大部分时间都处于空闲状态，等待人类提示、工具结果或模型响应。Kubernetes 并非为此而构建。每个会话运行一个 Pod 会为无所事事的会话占用内存，而在轮次之间删除 Pod 每次都要付出数秒的冷启动代价，并丢失智能体的状态。强化学习后训练也撞上了同一堵墙。

Agent Substrate 现已捐赠给云原生计算基金会（CNCF）Sandbox，是一个开源、安全加固、零信任的沙箱化智能体运行时，专为安全运行数百万个智能体和工具而设计，密度比标准容器高 10 倍。它将大量会话复用到一小池 worker Pod 上。空闲会话会被 checkpoint，包括内存和文件系统，并在下一个请求到达时恢复到任意空闲的 worker 上。随着智能体基础设施碎片化为绕过 Kubernetes 的专有运行时，NVIDIA 正在向上游贡献，以保持这项工作开放。

本文介绍哪些工作负载适合 Agent Substrate、上游正在构建什么，以及该项目如何与 KAI Scheduler 和 NVIDIA Dynamo 组件在 DSX AI Factory Platform 中协同工作.

智能体工作负载的形态

传统 Web 服务以相对少量长期存活的实例运行。 智能体 遵循另一种模式：它们醒来后执行一步操作，运行一条 shell 命令、编辑一个文件、调用一个测试套件或调用一个 LLM。然后它们等待，有时等待几毫秒，有时等待几分钟，再进行下一步。智能体的状态（其文件系统、进程、工作目录）必须在各步骤之间延续。

Kubernetes 之所以吃力，是因为为智能体启动一个计算 Pod 意味着要经过 API server、准入控制、etcd、调度器、kubelet、镜像拉取和网络配置。这需要数秒时间，对于一个运行数周的服务来说没问题。但对于一个必须出现、运行一条 10 毫秒的 bash 命令然后让路的沙箱来说，这实在太慢了，而这样的操作每秒要发生数百次。

这让平台团队只剩下两个次优选择：要么为每个智能体保持一个 Pod 常驻，为几乎始终空闲的计算付费；要么按需创建 Pod，并在每一步都付出冷启动的代价。

Agent Substrate 如何工作

Agent Substrate 使用 Kubernetes 来运行一个就绪 Pod 池。它创建一个独立的控制平面，将大量 actor（智能体及其环境）映射到那个较小的 worker 池上。当某个 actor 空闲时，它会被从其沙箱（gVisor 或 microVM）中快照出来，其 worker 被释放。当该 actor 再次被调用时，它会被恢复到任意空闲的 worker 上，其内存和文件系统状态保持完整。

唤醒一个 actor 不需要重新经过 API server、调度器或 kubelet。Agent Substrate 会将 actor 恢复到现有的 worker 上。worker Pod 仍然是普通的 Kubernetes Pod，因此集群调度、配额和放置策略仍然适用，正如我们稍后所述。

我们看到有三类工作负载推动了对 Agent Substrate 的需求：

我们看到有三类工作负载推动了对 Agent Substrate 的需求：

  • 编码助手与智能体服务： 编码智能体在 LLM 调用与自身环境中的工作之间交替进行：克隆仓库、编辑文件、运行构建和测试。用户期望环境在轮次之间保持持久并能立即响应。一个承载数千个此类会话的平台无法为每个会话都配备一个专用的热沙箱。
  • 使用智能体环境进行强化学习（RL）后训练： 使用可验证奖励的强化学习在运行 GPU 训练器和生成服务器的同时，还要运行大量 CPU 密集型环境（代码沙箱、编译器、浏览器、模拟器），这些环境负责执行动作并检查结果。随着 rollout 批次分发动作，沙箱需求会呈突发式增长。一次训练运行可以从早期实验中的几百个沙箱增长到生产环境中的数十万个。最慢的环境决定了训练器何时能拿到下一批数据，因此这条路径上的冷启动会让 GPU 处于空闲状态。
  • 用于研究的 GPU 沙箱： 研究人员的编码智能体需要 GPU，不是用来服务模型，而是用来编译 CUDA 代码、对内核进行基准测试或运行数值计算。它会在共享集群上启动一个 GPU 沙箱，运行作业，然后删除该沙箱。要在整个组织范围内支持这一点，就需要许多短生命周期、相互隔离的 GPU 沙箱，它们能快速启动，并公平地共享有限的 GPU 池。

上游工作：已经落地的内容和下一步

下面的每一项贡献都始于上述用例之一。所有这些工作都已公开在Agent Substrate 仓库:

  • 当所有 worker 都忙碌时，下一个请求会等待而不是失败： 在一个超订系统中，例如编码助手平台在高峰期或强化学习 rollout 突发时，用户的下一个轮次可能在所有 worker 都忙碌时到达。Agent Substrate 过去会立即返回错误，尽管通常片刻之后就会有另一个 actor 释放出一个 worker。

在 Agent Substrate 路由器中请求停车（#221）会保留该请求，并重试恢复操作，直到有 worker 空闲出来，同时设有有界等待时间和可同时等待的请求数量上限。后续一项（#1229）确保对已在运行的 actor 的请求永远不会卡在那条队列中。

  • 在沙箱内为智能体提供 GPU： 上文所述的研究用 GPU 沙箱，以及由 GPU 支持的强化学习环境（例如模拟器）。

我们正在开发设备可插拔性，为 Kubernetes 增加设备支持 动态资源分配 （DRA）。设备供应商通过一个 profile 接入其设备，沙箱中的每个容器只请求它所需的设备（#752），并且同一模型同时适用于 gVisor 和 microVM 沙箱。NVIDIA GPU 将成为首个受支持的设备。

  • 一个容器无法饿死或杀死它的邻居： 智能体沙箱通常会将智能体的工作负载与用于日志记录、代理或指标采集的辅助容器一起运行。其中一些辅助容器可能不可信。一个失控的容器不应耗尽整个沙箱的内存，并把智能体一并拖垮。

microVM 沙箱的每容器 CPU 和内存限制（#859）解决了这个问题。超过内存限制的容器会被单独停止，沙箱的其余部分则继续运行。

在挂起和恢复之间保留 GPU 沙箱

当智能体暂停以等待人工审核时，其沙箱应释放 GPU，并在之后恢复时仍保留其编译产物和已加载的数据。要支持这一点，需要同时保存和恢复智能体状态与 GPU 状态。

恢复 GPU 状态会引入硬件兼容性约束。GPU checkpoint 通常只能恢复到相同的 GPU 型号上，有时还要求驱动版本相同。Agent Substrate 提出了一种设计来解决这一问题。

设备供应商描述如何安全地暂停其设备，以及快照依赖哪些设备属性。Agent Substrate 会在每个快照中记录这些属性，并在匹配的设备上恢复沙箱；如果没有可用设备，则回退到干净的冷启动。该设计不依赖特定供应商，并构建在 DRA 之上。NVIDIA GPU 是首个目标；该设计可以扩展到其他硬件类型。

NVIDIA Dynamo：将智能体循环连接到推理循环

Agent Substrate 管理智能体在何处执行操作；推理运行时管理它们在何处进行思考。两者都面临类似的效率挑战：让空闲沙箱保持热状态会浪费 CPU 和内存，而在重复的模型调用中重建模型上下文则会浪费 GPU 周期。独立扩展每一层可以提高利用率。协调两者还可以降低延迟，并在智能体于工具执行和模型调用之间切换时保留可复用的上下文。

NVIDIA Dynamo，这个开源分布式推理框架，提供了这种协调能力。Agent Substrate 在一池热沙箱 worker 上激活、挂起和恢复有状态智能体环境。Dynamo 在 GPU worker 之间编排推理。Dynamo 路由器位于两者之间，将智能体正在做的事情与 GPU 上正在发生的事情连接起来。

让推理具备智能体感知能力

传统推理路由将每次模型调用视为独立请求。而在智能体中，每个请求都是更长循环中的一个步骤，连续请求往往复用相同的系统提示、工具定义、对话历史和先前的观察结果。

Dynamo 的路由器会查看可复用的键值（KV）缓存位于何处、哪些 worker 正忙于 prefill 或 decode，以及负载如何在 GPU 集群中分布。Agent Substrate 和智能体 harness 会补充会话身份、请求优先级、预期输出长度、工具调用边界和生命周期事件等信号。

借助这两者，Dynamo 可以：

  • 将相关的模型调用保留在已持有可复用 KV 缓存的工作节点上，同时避免造成 GPU 热点过载
  • 当推理池面临压力时，优先处理交互式轮次，而非后台智能体工作
  • 在工具调用间隙期间，保持系统提示、工具定义和对话历史可用
  • 优先从已终止的子智能体、已关闭的推理分支或已摘要的上下文中丢弃缓存状态
  • 在工具调用即将完成时准备可能的上下文

将 GPU 智能反馈给 Agent Substrate

集成的关键在于 Dynamo 向 Agent Substrate 暴露推理信号，帮助其决定何时让智能体继续运行、挂起或恢复。

Dynamo 比智能体运行时更接近 GPU 执行层。它能洞察缓存就绪状态、队列压力、活跃的 prefill 与 decode 工作，以及一个 LLM 请求可能耗时多久。这些信息可以同时为推理路由和 Agent Substrate 调度智能体沙箱的方式提供依据。

Dynamo 可以返回诸如预计首 token 时间、预计完成时间、请求进度、缓存就绪状态以及 GPU 池饱和度等信号。Agent Substrate 可以利用这些反馈来决定是让 Actor 保持驻留、在较长的推理等待期间将其挂起，还是在模型响应接近完成时将其恢复。

在大规模集群场景下，同样的反馈可以帮助调整热 worker 容量、调节 agent 与 subagent 的扇出，并避免激活那些本会因 GPU 队列饱和而闲置的 CPU 沙箱。

这种集成建立了一种简单的职责分工。Agent Substrate 管理智能体环境的高频生命周期。Dynamo 管理推理的高性能生命周期。Dynamo 围绕定义智能体计算的循环将两者连接起来：模型调用、工具调用、观察，然后再次模型调用。

开始使用：使用 Dynamo 和 Agent Substrate 的编码助手

本 指南 提供了在 Dynamo 和 Agent Substrate 上部署编码助手的逐步说明。

你将学到如何：

指南链接占位符——提供后添加

  • 将 Pi 编码智能体作为 Substrate Actor 运行：为每个智能体提供隔离的、有状态的环境，用于检查代码仓库、编辑代码和运行测试。
  • 将智能体连接到通过 NVIDIA Dynamo 提供的 GLM-5.3-Flash：在 Substrate 管理的沙箱中完成模型推理与工具执行之间的闭环。
  • 使用 Harbor 在 SWE-bench Verified 上编排评估：针对软件问题运行智能体并收集结果，以评估它们的更改是否解决了任务。

Agent Substrate 仍在演进中。其 API 仍在变化，GPU 支持正在基于新的 DRA 基础重建，Dynamo 智能体集成的部分内容仍处于实验阶段。现在是参与贡献并帮助塑造核心设计的好时机。

使用 KAI Scheduler 和 Dynamo 运行 Agent Substrate

Agent Substrate 运行在 Kubernetes 之上，并与用于提供模型服务和放置工作负载的 NVIDIA 软件协同工作。Substrate 管理有状态的智能体环境， KAI Scheduler 负责放置 Kubernetes 工作负载，而 Dynamo 负责提供模型服务，并与智能体运行时交换推理状态信号。

它们共同协调 CPU 侧的工具执行与 GPU 侧的推理，从而更高效地利用共享集群容量。

下表展示了每个组件所处的位置。Dynamo、KAI Scheduler 和 Kubernetes 基础组件都是 NVIDIA DSX OS 的一部分。

Agent Substrate 是一个独立的开源 CNCF Sandbox 项目，并非 DSX OS 的具名组件，不过 NVIDIA 正在向上游贡献代码，并开发与 DSX OS 组件的互操作性。

架构层技术角色DSX 关系
智能体与强化学习框架NeMo RL、NeMo Gym、你的智能体执行框架智能体循环、rollout 编排与环境请求DSX OS 之上的应用层
智能体执行Agent Substrate跨热工作节点复用的有状态隔离沙箱与 DSX OS 组件集成的外部开源运行时
模型服务NVIDIA Dynamo（ThunderAgent、Grove、ModelExpress）KV 感知、智能体感知的路由；预填充/解码协调；推理 Pod 的拓扑感知放置DSX OS 模型服务
工作负载编排KAI Scheduler放置、队列、Gang 调度、拓扑感知和公平份额DSX OS 工作负载与 GPU 编排
Kubernetes 基础组件AI 集群运行时、GPU Operator、Network Operator、Topograph经过验证的运行时，以及 GPU、网络和拓扑管理DSX OS 加速的 Kubernetes 基础

表 1. Agent Substrate 在 Kubernetes 上运行 AI 智能体和强化学习环境的栈中所处的位置：每一层的技术、作用及其与 NVIDIA DSX OS 的关系。

KAI Scheduler 与 Agent Substrate 在不同的调度层级上运行： Substrate worker Pod 就是普通的 Kubernetes Pod。KAI Scheduler 如今可以将它们与所支持的 GPU 训练器和推理服务器一同放置。将 worker 池自动扩缩容与 KAI 的队列和公平份额策略协调起来，可以把跨租户的资源共享扩展到环境层。

与我们一起在 KubeCon 上构建智能体基础设施

更进一步

如果你正在 Kubernetes 上构建智能体平台、编码助手或强化学习环境，我们很想了解你的工作负载。欢迎在活动现场找到我们，查阅 Dynamo 指南，或提交 issue agent-substrate/substrate 或 ai-dynamo/dynamo。加入 社区会议 并参与接下来的工作。

讨论（0）

标签

智能体 AI / 生成式 AI | 数据中心 / 云 | 开发者工具与技术 | 通用 | Dynamo | Dynamo | 中级技术 | 深入探讨 | 云网络 | KubeCon | Kubernetes | 开源 | 软件定义数据中心

关于作者

Avatar photo 关于 Ekin Karabulut
Ekin Karabulut 是一名数据科学家兼开发者关系倡导者，曾任职于 Run:ai，现就职于 NVIDIA，探索在不同生产场景中高效使用大型模型。此前，她研究联邦学习的隐私影响，专注于分布式训练技术，并对研究和工业环境中 GPU 使用效率低下的问题产生了浓厚兴趣。她创立了 AI Infrastructure Club，现居德国慕尼黑。 查看 Ekin Karabulut 的所有文章 Avatar photo 关于 Omer Yahud
Omer Yahud 是 NVIDIA 的软件工程架构师，目前专注于 Kubernetes 中的 AI 智能体支持。 查看 Omer Yahud 的所有文章

评论