🤖 machine learning

Efficient Vision-Language-Action Management and Serving for Robot Factories

本文介绍了 Robion，这是一种用于边缘服务器上多机器人、多模型视觉-语言-动作（VLA）工作负载的新型服务与管理系统，它通过采用 GPU 内阶段解耦（intra-GPU stage disaggregation）和智能流量控制，在严格遵守毫秒级安全服务水平目标（SLO）的同时，最大化机器人负载。

原作者： Dionysios Adamopoulos, Nattapol Chanpaisit, Basel Fakhri, Christina Giannoula

发布于 2026-09-14

📖 1 分钟阅读☕ 轻松阅读

CC BY 4.0

原作者： Dionysios Adamopoulos, Nattapol Chanpaisit, Basel Fakhri, Christina Giannoula

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

想象一下这样一个工厂车间：机器不再仅仅遵循僵化的、预设的指令，而是能够观察世界，理解自然语言给出的指令，并决定如何移动自己的手臂来抓取零件或组装组件。这就是物理人工智能（physical artificial intelligence）所承诺的前景，在这个领域中，机器人配备了“视觉-语言-动作”模型。这些系统充当机器人的大脑，接收摄像头的图像和像“拿起红色的盒子”这样的文本提示，然后计算出完成任务所需的精确物理动作。为了让这些机器人安全且高效地工作，它们必须在眨眼之间做出反应。如果大脑思考时间过长，机器人可能会猛烈甩动手臂、掉落物体，甚至导致整条装配线停工，从而造成昂贵的延误或安全隐患。

挑战在于，那些足以运行这些思考模型的计算机过于沉重、昂贵且耗电，无法直接绑在机器人身上。因此，工程师们提出将机器人的思维发送到附近的本地服务器——一种数字大脑中心——由其承担繁重的计算任务，并将答案传回。然而，这种设置产生了一个新问题：如何管理一个必须同时为数十个机器人提供服务的单一服务器，确保每一个请求都能得到足够快速的响应，以保持工厂顺畅运行？一种名为 Robion 的新系统被设计出来，正是为了解决这个难题，它允许单个服务器在不间断的情况下同时处理许多不同的机器人任务。

Robion 背后的研究人员发现，这些机器人大脑的工作方式与用于聊天机器人的大型语言模型或用于艺术创作的大型图像生成器有着本质的区别。虽然那些系统的运行时间通常为数百毫秒甚至数秒，但机器人的思考过程仅发生在毫秒之间。这是一个两步走的过程：首先，系统观察图像并阅读指令以理解现状；其次，它计算出执行动作所需的具体物理运动。由于这两个步骤速度极快且需求不同——一个需要重度计算，而另一个需要快速的内存访问——试图在服务器上将它们作为一个单一、连续的流水线来运行是低效的。这就像是试图同时跑一场马拉松和一场短跑；缓慢、沉重的跑者会拖慢轻快、灵敏的跑者。

为了解决这个问题，团队构建了 Robion，将这两个步骤拆分开，并在同一块计算机芯片上并排运行，但采用了精心控制的方式。他们在服务器的处理器上创建了两条不同的交通车道。一条车道处理沉重的思考，另一条车道处理快速的运动计算。至关重要的是，他们设计了一个交通控制器，确保重型车道不会完全阻塞轻型车道。他们通过为快速车道保留特定数量的计算能力来实现这一点，保证即使在进行重度思考时，它也始终有空间运行。这使得服务器可以同时处理多个机器人的请求，将一个机器人的思考过程与另一个机器人的运动计算过程进行重叠。

此外，研究人员意识到，单个服务器可以处理许多不同类型的机器人，每种机器人都有其特定的工作和特定版本的“大脑”。有些机器人可能在打包箱子，而另一些则在组装汽车零件。Robion 允许这些不同的机器人大脑生活在同一个服务器上，共享相同的计算车道。该系统充当一个智能调度员，不断检查哪个机器人最接近错过其安全截止时间。如果一个机器人即将耗尽完成任务的时间，系统会立即优先处理其请求，确保最紧急的任务得到完成。这防止了因为某个机器人等待答案过久而导致整个工厂陷入停滞。

团队在一个模拟工厂环境中测试了这个系统，该环境配备了多达四块强大的图形显卡（即驱动这些 AI 模型的引擎）。他们将 Robion 与现有方法进行了对比，现有方法要么将机器人大脑作为一个单一、不间断的链条运行，要么将步骤拆分到不同的计算机上。结果显示，Robion 可以支持比其他方法多得多的机器人，同时仍能满足严格的时间要求。在一次大规模测试中，运行 Robion 的单个服务器成功管理了八种不同的机器人模型，同时为多达 64 个机器人提供服务，成功率高达 98%。这意味着对于几乎每一个请求，机器人都能及时收到答案，从而安全地继续移动。

研究还探讨了是将机器人大脑的不同部分放在不同的计算机上更好，还是将它们放在一起更好。他们发现，将思考阶段和运动阶段拆分到不同的计算机上实际上会让事情变得更慢、效率更低，因为数据必须来回传输，浪费了宝贵的时间。通过将所有内容保留在一个强大的服务器上并仔细管理内部交通，Robically 实现了更好的性能。研究人员还考察了成本，指出使用单个强大的服务器来运行许多机器人，比尝试在每个机器人上都配备昂贵的高性能计算机要便宜得多。这种方法可以让大型公司的先进自主工厂成为现实，允许他们部署能够高效协作的智能机器人集群，而不会造成计算资源的过载。

最终，Robion 表明，运行一个智能机器人工厂的关键不仅在于拥有强大的计算机，还在于拥有一个能够以极高精度管理这些计算机的系统。通过理解机器人决策过程那种分秒必争的特性，并设计出一个尊重这些紧迫截止时间的服务器，研究人员为扩展物理人工智能规模创造了一个蓝图。该系统确保了随着工厂变得更大、更复杂，机器人仍能实时进行观察、思考和行动，保持生产线的平稳运行和安全。

技术摘要：面向机器人工厂的高效视觉-语言-动作（VLA）管理与服务

问题陈述

视觉-语言-动作（VLA）模型正成为机器人工厂物理 AI 的基础，使机器人能够感知环境、进行任务推理并执行操作动作。然而，VLA 推理本质上是延迟敏感型的；错过严格的服务水平目标（SLO）会导致任务失败、安全导航问题或装配线停顿。

部署 VLA 模型面临着一个根本性的冲突：

延迟需求： 为了满足安全和任务期限，需要高端 GPU（如 RTX 6000 Pro、H100），它们提供的推理延迟显著低于嵌入式机器人 GPU（如 Jetson AGX Thor）。
硬件约束： 高端 GPU 由于重量、成本、功耗和散热限制，无法直接集成到机器人上。在机器人端使用嵌入式 GPU 进行推理也会大幅降低电池寿命（高达 45%）。
现有解决方案： 目前主流的方法是将推理卸载到本地边缘服务器。然而，现有的服务系统并不适用于这种场景：
- 吞吐量 vs. 延迟： 现有的多阶段服务系统（如 vLLM-Omni）针对吞吐量和大规模模型进行了优化，其各阶段运行时间长达数百毫秒。这些系统依赖于进程间通信和缓冲区检查，这在 VLA 各阶段仅为毫秒级的执行时间内会产生主导性的开销。
- 资源利用率不足： VLA 架构由两个截然不同的阶段组成：计算密集型的视觉语言模型（VLM）和内存密集型的动作扩散 Transformer（ADiT）。将这些阶段拆分到不同的 GPU 上会导致显著的计算资源闲置，特别是对于受限于内存带宽的 ADiT 阶段。
- 单一模型关注点： 当前系统通常不支持在单个 GPU 上并发执行多个 VLA 模型（包括微调变体），同时还要遵守每个请求的 SLO。

方法论：Robion

作者提出了 Robion，这是首个专为多机器人、多模型请求设计的、在多 GPU 边缘服务器上严格遵守 SLO 的 VLA 服务与管理系统。Robion 由一个**服务引擎（Serving Engine）和一个管理引擎（Management Engine）**组成。

1. Robion 服务引擎

服务引擎专注于通过三种核心技术实现 GPU 利用率最大化和延迟最小化：

固定批次的 GPU 内阶段解耦（Fixed-Batch Intra-GPU Stage Disaggregation）：
- Robion 不会在不同的 GPU 或进程之间分离阶段，而是在单个 GPU 内部使用两个异步 CUDA 流来解耦 VLM 和 ADiT 阶段。
- 它采用固定大小的批处理而非连续批处理（continuous batching）。请求仅在阶段执行开始时才被准入。这消除了像 vLLM-Omni 那样在每个扩散步中进行缓冲区检查的开销，而这种开销对于 VLA 毫秒级的步骤来说是极其昂贵的。
- 使用 CUDA Graphs 来消除重复内核执行时的 CPU 启动开销。
锁步执行下的受保护与动态空间 SM 分区（Guarded & Dynamic Spatial SM Partitioning on Locksteps）：
- 为了确保内存密集的 ADiT 阶段不会在 VLM 阶段饱和 GPU 流式多处理器（SM）时被饿死，Robion 强制执行锁步执行（lockstep execution）。在每个锁步中，恰好有一个 VLM 批次和一个 ADiT 批次并发运行。
- 动态 SM 限制： 系统会对 VLM 流可以占用的 SM 数量进行限制，以保证有足够的 SM 留给 ADiT 流。
- 辅助分析选择： 由于最优的 SM 分割取决于协同运行阶段的具体批次大小，Robion 在初始化期间进行离线分析。它穷举搜索所有 2 的幂次方的批次大小组合下的 SM 限制，并将最优配置存储在查找表中。在运行时，系统应用预计算的限制而不进行抢占，从而确保不会丢失执行进度。
面向 SLO 的双流多模型服务：
- Robion 支持模型共存（model co-location），即在单个 GPU 上让多个 VLA 模型（包括微调变体）共享相同的 VLM 和 ADiT 流。
- 它实现了**最早 SLO 优先（Earliest-SLO-First, ESF）**调度策略。在每个锁步开始时，系统会计算每个模型队列中头请求距离 SLO 截止时间的剩余时间，并优先处理剩余时间最短的请求。这确保了在异构机器人群体中严格遵守 SLO。

2. Robion 管理引擎

管理引擎负责在多 GPU 服务器上进行模型的放置以及机器人流量的分配。

灵活的模型放置： 程序员可以配置模型的放置方式：在同一 GPU 上共存不同的架构、在不同 GPU 间复制模型，或者将 GPU 划分为专门用于特定模型架构的独立组。
自适应流量控制器：
- 系统将“机器人到 GPU”的分配建模为一个整数规划问题。
- 目标： 最大化单模型批处理效率（通过将特定模型的请求集中到单个 GPU 上），同时遵守每个 GPU 可承受的最大机器人负载，且不违反 SLO。
- 约束条件： 分配给某个模型的机器人总数必须符合工厂需求，且任何 GPU 上的归一化负载之和不得超过 1.0。
- 这种方法避免了“均匀拆分”（这会降低批处理效率）和“每 GPU 单模型”（这可能导致高机器人计数模型造成过载）的缺陷。

关键结果

作者在两个硬件平台（4x RTX 6000 Pro 和 4x H100）上对四个 VLA 模型（ $\pi_0$ 、SmolVLA、GR00T N1.5、Xiaomi-Robotics-0）评估了 Robion，并将其与单体（Monolithic）基准和 vLLM-Omni 进行了对比。

单模型性能：
- 在保持 98% SLO 达成率的情况下，Robion 服务的机器人负载比 vLLM-Omni 高 6.7 倍，比单体系统高 1.5 倍。
- 运行 Robion 的单个高端 GPU 可以服务平均 20 台机器人并保持 98% 的 SLO 达成率，这优于在嵌入式 GPU 上的机器人端推理，并且与为每台机器人配备高端 SoC 相比，显著降低了成本（约 6.8 倍）。
- 仅“受保护的 SM 分区”这一技术就显著提高了 SLO 达成率，证明了动态 SM 限制的必要性。
多模型共存：
- 当在单个 GPU 上共存多个模型（包括变体和不同架构）时，Robion 的 SLO 错过率比单体方法低 2.1 倍。
- 在这些多模型场景下，vLLM-Omni 处于完全饱和状态（100% 错过率）。
- ESF 队列选择策略表现稳健，优于轮询（Round-Robin）和最大队列优先（Largest-Queue-First）策略，尤其是在模型具有不同 SLO 截止时间的情况下。
多 GPU 扩展性：
- 在一个 4-GPU 服务器上服务 8 个不同模型的规模化实验中，Robion 成功在 98% 的 SLO 达成率内服务了高达 64 台机器人。
- Robion 的 GPU 内解耦显著优于 GPU 间解耦方案（即将 VLM 或 ADiT 分配给单独 GPU 的方案），因为后者会导致受限于内存带宽的 ADiT 阶段出现严重的资源利用不足。
云端 vs. 边缘：
- 研究证实，由于网络延迟问题，边缘部署（通过 WiFi 7 连接的本地服务器）优于云端部署，因为云端场景会显著降低 SLO 达成率。

重要性与声明

本文声称是第一项：

研究 VLA 模型在机器人工厂中高效服务的特定设计考量，并强调了现有多阶段服务系统与 VLA 推理的毫秒级、延迟敏感特性之间的不匹配。
提出 Robion，该系统能够在多 GPU 边缘服务器上实现 面向 SLO 的、多模型服务。

作者强调，Robion 弥合了 VLA 模型的高计算需求与机器人工厂严格约束之间的鸿沟。通过使高端 GPU 能够以严格的延迟保证同时为许多机器人提供服务，Robion 使在机器人工厂部署本地边缘服务器成为一种切实可行且具有成本效益的现实。该系统表明，通过适当的阶段解耦、动态资源分区和智能流量控制，单个边缘服务器可以取代在每台机器人上都需要高端计算的需求，从而显著降低大规模物理 AI 部署的门槛。