一台服务器，怎样同时指挥一群机器人？
想象一条装配线上，几十台机器人不断把摄像头画面发给同一台服务器：有的要抓取零件，有的要装箱，有的要完成组装。服务器不仅要给出正确动作，还必须及时回复。排队稍长，机器人就可能动作卡顿，甚至错过任务要求的时限。
这正是论文《Efficient Vision-Language-Action Management and Serving for Robot Factories》试图解决的问题。研究团队提出 Robion，把 VLA 模型做成一套面向多机器人、多模型和多 GPU 的推理服务系统。VLA，即 Vision-Language-Action，会把摄像头画面和文字任务转换成机器人动作。Robion关注的不是如何训练出更聪明的机器人，而是模型进入产线后，怎样让有限的 GPU 按时服务更多机器人。
这里的“按时”由 SLO（服务等级目标）衡量，也就是系统承诺达到的性能门槛，例如绝大多数请求必须在规定时间内完成。本文所有性能数字均来自研究团队自己的实验，尚无独立复现。
两道工序，不能只按先来后到
论文讨论的 VLA 采用两阶段结构。第一阶段是 VLM（Vision-Language Model，视觉语言模型），负责理解画面和任务；第二阶段是 ADiT（Action Diffusion Transformer，动作扩散 Transformer），从带噪的动作表示开始，经过多轮去噪，逐渐生成连贯的动作轨迹。可以把它理解成先看懂“要做什么”，再把模糊的动作草稿修成可执行方案。
两阶段对 GPU 的需求并不一样。论文称，VLM 更偏计算密集，主要做大型矩阵运算；ADiT 更偏内存密集，包含较小的矩阵和逐元素操作。以论文给出的一项配置为例，在 RTX 6000 Pro、批量大小为 4 时，VLM 与 ADiT 的平均 Tensor Core 利用率分别为 52% 和 15%。如果各占一张 GPU，两边都可能有不少资源闲置。
现有多阶段推理系统通常还会持续检查：有没有新请求完成上一阶段，可以塞进正在运行的批次。这种“连续批处理”适合每个阶段运行数百毫秒的大模型，却未必适合 VLA。论文称，VLA 的两个阶段通常只有几毫秒，ADiT 的单次扩散步骤约为 1—2 毫秒；在其测试中，vLLM-Omni 的阶段间缓冲区检查占到 VLA 总推理延迟的 30%—35%。工序太短，检查和重新打包本身反而成了显著负担。
给“看懂”和“行动”各开一条车道
Robion的第一步，是在同一张 GPU 内建立两条 CUDA stream——可以把 stream 理解为提交 GPU 工作的独立队列。一条运行 VLM，另一条运行 ADiT。不同请求的两个阶段由此可以重叠执行：这批请求正在生成动作时，下一批请求已经开始理解画面。
它没有在 ADiT 运行途中不断插入新请求，而是在每个阶段开始时确定批次，运行期间不再改变。这样牺牲了一部分随到随拼的灵活性，却省掉了频繁检查和打包的成本。Robion还预先录制 CUDA Graph，把一串 GPU 操作保存下来反复执行，以减少每次由 CPU 发起计算的开销。
不过，两条队列不等于真正并行。VLM 的大型计算任务可能占满全部 SM。SM（Streaming Multiprocessor，流式多处理器）可以粗略理解为 GPU 内实际执行工作的计算单元；一旦 VLM 把它们全占住，ADiT 仍然只能等。
Robion的关键处理是主动限制 VLM 能使用的 SM 数量，给 ADiT 留出固定空间。系统把执行划分成一个个 lockstep：每轮恰好安排一个 VLM 批次和一个 ADiT 批次并行，等二者都完成后再进入下一轮。它在初始化阶段测试不同批量组合与 SM 配额，把最快的配置记录在查找表里；运行时根据本轮组合直接套用，不必在中途暂停 VLM 并重新分配资源。
这像是在厨房里给切配和出餐划定操作台。切配即使任务多，也不能占满整张台面，否则出餐环节只能干等。这里的重点不是让某一道工序独占更多资源，而是缩短两道工序共同完成一轮所需的时间。
多个模型共享，先救快到期的请求
真实产线不会只有一种任务。同一张 GPU 上可能放着多个 VLA 模型，或者同一架构针对不同任务微调出的版本。Robion让这些模型共享一条 VLM stream 和一条 ADiT stream，因此一轮中可以同时运行模型 A 的视觉语言阶段与模型 B 的动作阶段。
调度时，它查看各模型队首请求距离 SLO 截止时间还剩多久，优先处理剩余时间最少的请求。这里不是简单选择最早到达者，而是先照顾最接近超时者。
到了多 GPU 层面，问题又变成请求该发往哪里。若把同一模型的机器人平均拆到许多 GPU，每处收到的请求都可能太零散，难以凑出有效批次；若全部集中到一张 GPU，又可能造成排队和超时。Robion用一个整数规划形式的流量控制器，尽量把同一模型的请求集中到一个模型副本，同时限制每张 GPU 的总负载。模型可以共置、复制，也可以把 GPU 分成互不重叠的组，分别服务不同架构的微调版本。
数字说明了什么？
据论文团队报告，在单模型实验中，以 98% 的请求达到 SLO 为约束，Robion平均可承载的机器人负载是 vLLM-Omni 的 6.7 倍、Monolithic方案的 1.5 倍。后者把 VLM 和 ADiT 当作一条不可拆分的流水线运行。
在多个模型共置、最多服务 18 台机器人的实验中，Robion的 SLO 未达标比例平均比 Monolithic 低 2.1 倍；论文称 vLLM-Omni 在该实验中完全饱和，未达标比例为 100%。更大规模的测试在一台 4-GPU 服务器上部署了 8 个不同模型，Robion在 98% SLO 达标率下最多服务 64台机器人。
这些数字衡量的是特定达标率约束下能承载多少机器人，不能理解成模型精度提高了 6.7 倍，也不是所有场景下单次推理都会快 6.7 倍。真正值得关注的是问题重心的变化：当 VLA 从单机演示进入共享产线，模型能力之外，还要有人负责排队、拼批、资源隔离、截止时间和跨 GPU 分流。机器人模型开始面对一套独立的“推理服务工程”。
局限与未知
- 论文把 Robion称为首个满足这些条件的系统，也称 vLLM-Omni 是使用最广泛的多阶段推理系统，但两项定位都缺少独立证据，适合视为作者表述。
- 论文给出了 6.7 倍、1.5 倍和 64 台机器人等结果，但现有材料未完整披露对应实验的具体 SLO 时限、全部 GPU 配置、模型清单、请求负载定义与统计波动，不能直接外推到其他工厂。
- Robion依赖初始化阶段的离线 profiling（性能测量）来选择 SM 配额。材料展示了它在测试配置中的效果，但没有说明面对未见过的负载变化时，需要多频繁重新测量或调整。