北邮、北大、清华等联合推出PhyAI：首个端边云统一推理运行时

具身智能的部署远不止原型验证。论文指出，典型场景包括benchmark评测、云端RL后训练rollout、端侧实时控制、以及工厂MaaS（由厂区共享GPU服务多台机器人）。这些场景对延迟、吞吐、多卡通信的要求各不相同，现有工作往往为每类场景维护一套模型代码，导致迁移成本高、重复开发多、推理效率参差不齐。

然而，四类场景虽在Batch大小、模型精度、执行设备上存在变化，但图像预处理、模型推理逻辑、缓存和动作输出可以复用且必须保持一致。这正是PhyAI试图解决的痛点：用一套代码覆盖所有场景。

PhyAI的核心思路是将模型语义放在Model Adapter中，把调度、缓存、算子、图执行和并行交给运行时。具体组件包括：Model Runner保存视觉语言条件、action expert、视频动作生成、solver等；Scheduler负责选择DP、TP、CFG及设备组；Runner管理KV cache、buffer、CUDA Graph和请求状态；Layers按shape、dtype与硬件选择融合或分布式算子。

这种设计使得同一模型路径可运行在单卡、边缘和云端多卡环境，无需为不同场景重写代码。

论文通过分模块测量揭示模型侧瓶颈：PI0.5在batch=1时，action expert仅占估算FLOPs的8.8%，却占latency的57.2%；batch=32后降至13.5%，吞吐约100 samples/s。Cosmos3的batch从1增至16，吞吐仅提高14.3%，接近计算受限。

但模型侧Roofline不足以直接给出控制速率，因为存在RTC、网络时延、图像前后处理延迟。为此，论文提出Control-Time Roofline，衡量瓶颈来自模型推理还是物理环境。测试发现，AGX Orin上主要瓶颈是推理，而RTX Pro 6000上则是物理环境。

这一结论意味着：在算力充足的设备上，继续降低延迟不会按比例提高理想控制频率。算法、硬件、infra需协同设计，框架优化节省的时间应支持更大模型、较慢设备或更多并发。

在11组同模型、同设备的单请求对比中，PhyAI相对官方实现加速1.40x至4.65x。具体案例：MiniCPM-Robot在H100上由105.38ms降至22.64ms；Cosmos3-Nano-Policy-DROID在8张H20、CFG=2、TP=4上由2.46s降至1.18s。

推理加速也惠及云端RL Rollout。以RLinf的PI0.5 GRPO为例，使用4张A800和32个环境，推理时间955.8s，占RL总时间15.9%。PhyAI将推理速度提升2.55x，保持其他工作不变，估算推理时间降至863.2s，RL总时间减少9.7%。

此外，官方Demo显示，三台机器人并行推理时，PhyAI时延最多降低2.3倍，无卡顿完成任务，而官方框架出现卡顿。

PhyAI将四类场景的推理需求接入同一套运行时，模型适配、算子优化和多卡支持不再重复实现，为具身智能构建统一推理栈。但Control-Time Roofline也限定了加速的实际收益：机器人运行受推理和环境双重制约，瓶颈随设备算力和模型大小变化。

因此，论文强调需关注Control-Time Roofline，进行算法和硬件协同设计。这提示我们，框架优化并非万能，需结合具体硬件和物理环境。