Physical AI 模型的部署边界不止于原型验证，还包括离线评测、云端强化学习 Rollout、端侧实时控制，也可能以工厂 MaaS 的形式，由本地边缘服务器或者云端服务器为多台机器人提供服务。这些场景对延迟、吞吐和多卡通信的要求不同，现有工作通常会针对不同需求编写多套代码，存在迁移成本高、工程开发重复工作多、不同场景推理效率参差不齐等问题。
论文提出 PhyAI，一个面向 Physical AI 的统一推理运行时。它把模型语义放在 Model Adapter 中，把调度、缓存、算子、图执行和并行交给运行时。本文围绕四类部署场景展开，并将 Control-Time Roofline 作为连接推理性能与控制周期的主要分析工具。
这项工作由北京邮电大学牵头，北京大学、清华大学、南京大学、明体科技和面壁智能共同完成。
- 论文标题：PhyAI: Real-Time Physical AI at the Edge, Scalable Rollouts in the Cloud
- 论文地址：https://arxiv.org/abs/2608.03682
- GitHub 地址：https://github.com/mingti-org/phyai
- AtomGit 地址：https://atomgit.com/mingti-org/phyai
视频链接：https://mp.weixin.qq.com/s/A5XZbSn4AYWoOqNB3R7DPg
PhyAI和官方框架真机部署MiniCPM-Robot的Demo视频，三台机器人并行推理场景，PhyAI时延最多降低2.3倍，无卡顿完成任务（官方框架三台机器人并行推理时出现由于卡顿无法完成任务的情况）
01 部署场景与问题定义
当前典型的具身智能推理场景主要包括四类：benchmark 评测场景，关注复现的准确性；云端 RL 后训练 rollout 场景，用于提升模型长程任务能力，关注多 batch 的吞吐和多 GPU 利用率；端侧部署场景，主要关注模型的推理时延；边缘或工厂 MaaS 场景，由厂区共享 GPU 服务多台机器人，主要关注多请求吞吐效率，网络、排队和批处理都会影响时延。
这四类典型场景的 Batch 大小、模型精度和执行设备存在变化，但图像预处理、模型推理逻辑、缓存和动作输出可以复用，且必须保持一致。
然而，现有工作针对这四类场景往往维护四套模型代码，存在迁移成本高、工程开发重复工作多、不同场景推理效率参差不齐等问题。
02 统一推理运行时设计
本文提出 PhyAI，一个端边云一体的推理框架。它仅使用一套模型运行代码，即可在 Physical AI 典型的四个场景中无缝迁移与使用。
PhyAI 主要包括两个关键组件：Model Runner 保存视觉语言条件、action expert 或视频动作生成、solver、状态复用与动作转换；Scheduler 选择 DP、TP、CFG 及设备组；Runner 管理 KV cache、buffer、CUDA Graph 和请求状态；Layers 按 shape、dtype 与硬件选择融合或分布式算子。
同一模型路径可运行在单卡、边缘和云端多卡环境中。
PhyAI 框架结构
03 推理瓶颈与 Control-Time Roofline
本文对不同模型的不同模块进行了性能测量，并提出了 Control-Time Roofline。
本文的分模块测量首先给出模型侧的瓶颈。其中，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%，已接近计算受限。
PI0.5 和 Cosmos3 在不同硬件上各模块的 Roofline
但是，由于存在 RTC（Real-Time Chunking）、网络时延、图像前后处理延迟，模型侧 Roofline 仍不能直接给出机器人控制速率。
本文提出 Control-Time Roofline，用于衡量当前机器人控制的瓶颈究竟来自模型推理还是物理环境等因素。本文对 PI0.5 在不同设备上进行了测试，发现 AGX Orin 上的主要瓶颈是推理，而 RTX Pro 6000 上的主要瓶颈则是物理环境。
这个看似直接的结论指出：在算力充足的设备上，继续降低延迟并不会按比例提高理想控制频率。算法、硬件、infra 需要协同设计，框架优化节省出的时间应该用于支持更大模型、较慢设备或更多并发。
Control-Time Roofline Model
04 Benchmark 与 RL Rollout
在 11 组同模型、同设备的单请求对比中，本文相对官方实现加速 1.40x 至 4.65x。MiniCPM-Robot 在 H100 上由 105.38 ms 降至 22.64 ms；Cosmos3-Nano-Policy-DROID 在 8 张 H20、CFG=2、TP=4 上由 2.46 s 降至 1.18 s。
推理速度的提升还能给云端 RL Rollout 带来收益。RLinf 的 PI0.5 GRPO 使用 4 张 A800 和 32 个环境，推理时间为 955.8 s，占 RL 总时间的 15.9%。本文将推理速度提升 2.55x；保持其他工作不变，估算 RL 中的推理时间为 863.2 s，减少 9.7%。
05 总结
本文将 benchmark、云端 RL rollout、端侧部署和工厂 MaaS 等场景的推理需求接入同一套推理运行时，模型适配、算子优化和多卡支持不再沿四条路径重复实现，为具身智能推理构建了一套统一的推理栈。
本文提出的 Control-Time Roofline 则限定了加速的实际收益。机器人的运行不仅受到推理速度的制约，也受到环境因素的制约，二者的瓶颈会随着设备计算能力和模型大小的变化而变化。
本文指出，需要关注 Control-Time Roofline，以进行算法和硬件的协同设计。
