四张 RTX 6000 Pro、八个机器人模型、64 个请求源，98% 的请求在时限内返回——Robion 论文给出的最大规模结果，很容易被转述成“一台服务器同时控制 64 台机器人”。实验实际上没有接入 64 台机器人：相机图像和文字指令来自离线机器人学习基准 LIBERO，“机器人”由请求发生器模拟，默认每秒发出两次请求。
这个区别不削弱 Robion 的系统价值，却改变了它证明的事情。研究团队解决的是一个服务器容量问题：当多台机器人共享 GPU 时，怎样把视觉语言理解与动作生成两段不同的负载叠在一起，在既定网络延迟和响应时限下接住更多请求。它给出了建设机器人边缘算力池的一种方法，还没有证明这套算力池能在真实工厂的无线抖动、传感器延迟和控制风险中维持同样容量。
每台机器人配一张卡，浪费发生在算力和显存两处
论文评测的 π0、SmolVLA、GR00T N1.5 和 Xiaomi-Robotics-0 都把推理分成两段：视觉语言模型（VLM）先读取相机画面与任务指令，生成中间表示；动作扩散 Transformer（ADiT）再经过多轮去噪，输出一段未来动作。一次调用通常只持续数十毫秒，机器人执行动作片段时，GPU 会出现空档。
两段负载对 GPU 的要求也错开了。VLM 主要执行大规模矩阵乘法，偏计算密集；ADiT 由较小矩阵和逐元素运算主导，偏显存带宽密集。论文在 RTX 6000 Pro、批量为 4 的 π0 上测得，VLM 的平均 Tensor Core 利用率为 52%，ADiT 只有 15%。把两段各放一张卡会同时留下大量闲置算力。
显存同样没有被吃满。四种 VLA 大致处在 4.5 亿到 47 亿参数范围，论文估算单个模型连同推理张量约占 10GB；RTX 6000 Pro 有 96GB 显存。Robion 因而没有把 GPU 与机器人一一绑定，而是让多个模型和多个请求共享同一张卡。
Robion 用两条执行流补齐彼此的空档
通用多阶段推理框架 vLLM-Omni 的目标是把文本、图像、音频、视频等模型拆成可独立扩缩的阶段。这种设计适合持续数百毫秒的重阶段，也允许分别调度和批处理。Robion 论文指出，把它直接用于只有几毫秒一段的 VLA 时，每个扩散步都检查新请求、拼接中间张量的开销会占总推理延迟的 30%—35%。在作者的四模型实验里，连不拆阶段的单体流水线都比这套基线能承受更多请求。
Robion 保留“分阶段”的思路，但把两段留在同一张 GPU、同一个进程的两条 CUDA 执行流上。它只在一段开始时组成固定批次，不在执行中持续插入新请求；每个同步轮次并行跑一批 VLM 和一批 ADiT。为了避免计算密集的 VLM 抢满 GPU 的流式多处理器（SM），系统会根据两边的批量组合，从预先测得的配置中选择 VLM 可占用的 SM 数量，给 ADiT 留出并行空间。
静态平分不是等价替代。论文把 VLM 固定限制在 RTX 6000 Pro 的 188 个 SM 中的 96 个时，四个模型在 98% 时限达标率下可承受的机器人负载平均下降约 18%。动态限制的意义，是承认不同模型、不同批量下两段执行时间并不固定；系统需要每轮改变边界，而不是永久切走一半 GPU。
多模型共卡后，Robion 再按“距离时限还剩多少时间”选择下一条队列。这个策略在模型架构和时限相同的场景里相对轮询优势很小；当两者开始分化时才显出作用。论文全部配置的平均结果中，它比轮询和最大队列优先的时限达标率分别高 6% 和 7%。这里的主要增益仍来自两段并行与资源限制，队列策略负责处理异构请求，而不是凭调度算法单独创造数量级提升。
64 个请求源成立，前提写在实验设置里
作者用四张 96GB RTX 6000 Pro 测试八个模型：四个 π0 微调版本和四个 Xiaomi-Robotics-0 微调版本。图像与指令取自 LIBERO；每个模拟机器人先随机选择一个起始偏移，随后按固定频率发请求，实验用五组不同偏移取平均。默认频率是 2Hz，单次响应时限则设为各模型在 70W Jetson AGX Thor 上的推理延迟：四种架构分别为 156、117、50 和 53 毫秒。端到端延迟由实测服务器推理时间加上预设网络时间组成。
64 个请求源也不是任意模型放置都能接住。最后一组负载包含 48 个 π0 请求源和 16 个 Xiaomi 请求源。把两种架构混在每张 GPU 上时，时限达标率只有 74.2%；将 GPU 分成架构互不混用的两组，并选择 3:1 的卡数分配后，达标率升至 99.4%。原因是两种架构的阶段时长不同，混放会让较短任务在同步轮次里等待较长任务。论文摘要中的“最多 64 台、98% 达标”依赖这次分组放置，而不只是执行流优化。
这也解释了 Robion 的管理层为什么先用约一小时逐个测出“单张 GPU 能服务多少请求源”，再用整数规划分配流量。容量不是从参数量或峰值算力直接推出来的常数；模型组合、请求频率和放置方式一变，就要重新找上限。
硬件账能省多少，取决于把哪些成本排除在外
论文按约 5500 美元一块 Jetson AGX Thor、约 1.6 万美元一张 RTX 6000 Pro 的设备价格估算：单卡平均服务 20 个请求源时，相比给每台机器人各配一块 Thor，GPU 硬件成本约低 6.8 倍。套到 64 个请求源的四卡结果，四张服务器 GPU 约 6.4 万美元，64 块 Thor 约 35.2 万美元，硬件标价差约 5.5 倍。
这两组倍数不能当成工厂总拥有成本。服务器机身、网络设备、供电散热、运维、冗余以及机器人端仍需保留的安全控制算力都没有进入比较；64 台实验也没有测量能耗、任务成功率或停机代价。作者另外发现，在每种模型 24 个请求源的高负载下，远程云部署的达标率比本地边缘服务器低 18.4—23.6 个百分点，说明把 GPU 账算便宜之后，网络仍可能先耗掉时限预算。
Robion 沿用了 VLA-Perf 的网络配置，其中 WiFi 7 被设为上行 2Gbps、下行 3Gbps、基础延迟 2.5 毫秒。这是明确、可复算的工程假设，不是对某座工厂无线环境的测量。NIST 对工厂无线系统的研究把低延迟、可靠性和有界抖动同时列为闭环控制要求，并指出任务关键控制还要处理安全与故障保护消息。平均带宽足够，并不自动带来可预测的最坏情况延迟。
下一步不是再加请求，而是把请求接回物理闭环
这项研究已经证明，在作者的四种 VLA、两类服务器 GPU 和给定网络模型下，共享 GPU 不必沿用大模型服务系统的默认拆分方式。把计算密集和带宽密集阶段在卡内错峰，再把模型放置与流量分配一起求解，确实能把同一批硬件的请求容量推高。
真实部署的下一项关键变量不是“能否从 64 增到 72”，而是请求晚到或丢失时机器人会怎样动作。需要接入真实相机上传、无线拥塞、传感器与执行器延迟，记录尾延迟对应的动作陈旧程度、任务成功率和安全降级；还要在单卡或网络故障时验证冗余路径。论文没有给出 Robion 的公开代码链接，第三方暂时无法重跑它的执行流与调度实现。只有这些环节补齐，64 才能从服务器容量数字，变成可以写进机器人车间设计书的并发规模。
