PhyAI: Real-Time Physical AI at the Edge, Scalable Rollouts in the Cloud
Chenghua Wang, Daliang Xu, Dongqi Cai, Duojin Sun, Hao Zhang, Haoze Qian, Huaiyuan Zhang, Jinshuo Cui, Junbo Cui, Kezhao Zhao, Longxi Gao, Mengwei Xu, Rongjie Yi, Tam Sikyuen, Tianyue Zhang, Weikai Xie, Xuanzhe Liu, Yingying Qin, Yiwen Lu, Yuan Yao, Yuezhi Zu, Yunhan Guo, Yuxin Zheng, Ziqi Guo
cs.AI, cs.RO
2026-08-04
北邮团队做的统一推理引擎 PhyAI,让 π0、π0.5、GR00T N1.7、MiniCPM-Robot 用同一套代码跑,比官方实现最高提速 4.65 倍,发布当天就接入了新模型。
具身智能(Physical AI)的一个策略模型,在真实使用中要经历好几种完全不同的推理场景:线下评测、云端强化学习 rollout、边缘 GPU 共享服务、机器人本体上的实时推理。这些场景用的是同一个 checkpoint、同一套动作语义,但工程上往往各写一套推理程序,一个团队可能同时维护线下评测脚本、云端 batch 推理服务、边缘部署代码。每套单独优化、单独验证,一个场景里验证过的性能和行为不会自动带到另一个场景。北京邮电大学等团队(合作方包括南京大学、北京大学、清华大学、ModelBest 等)做的 PhyAI,目的是用一套运行时把这几种场景都覆盖掉。
PhyAI 的核心设计是把架构相关的逻辑和通用执行服务拆开。每个模型架构,比如 VLA 模型 π0、π0.5、GR00T,或者 world-action 模型 Cosmos3,通过一个模型适配器(model adapter)保留自己特有的条件编码、求解器状态、缓存策略、输出转换逻辑;而计算图执行、算子内核、显存与缓存管理、并行调度这些通用部分,由运行时统一提供,不用每个模型重写一遍。这样一套代码就能同时跑 VLA 和 world-action 模型,在单卡或多卡上,覆盖本体、边缘、云端三种部署形态。团队验证这套适配器接口的方式很直接:MiniCPM-Robot 发布当天就被接进了 PhyAI。
具体优化手段包括核融合(比如把 π0.5 里 Q/K/V 投影合并成一次 GEMM,把 MLP 的 gate 和 up 投影合并)、CUDA Graph 图重放(把 π0.5 十步 Euler 迭代里重复的控制流和张量状态固定下来一次性捕获重放)、按张量形状与精度与硬件动态选择最优算子内核,以及离线量化(支持 W4A16、W8A16、W8A8、W4A8)。团队还提出了一个叫 control-time Roofline 的分析框架,用来判断一次具身控制循环到底是被推理速度卡住(inference-bound),还是被环境执行速度卡住(environment-bound)。如果环境本身就比推理慢,继续优化推理速度就没有意义,省下来的时间可以换成用更大的模型或更便宜的硬件。
在 π0、π0.5、GR00T N1.7、MiniCPM-Robot 四个模型上,PhyAI 相比各自官方实现有 1.40 倍到 4.65 倍的加速。这个对比不是完全同精度的公平对比,部分配置下专门针对单一模型优化的运行时(比如 FlashRT、vla.cpp)仍然更快,PhyAI 的目标是一套运行时有竞争力的延迟,不是每个场景都最快。
在 Cosmos3-Nano-Policy-DROID 上,8 张 H20 GPU、CFG=2、TP=4 的配置下,PhyAI 把延迟从 2.46 秒降到 1.18 秒,提速 2.08 倍。细粒度 profiling 还揭示了不同模型需要不同的执行策略:在 Hopper 系列 GPU 上,batch size 为 1 时,π0.5 的动作专家(action expert)只占估算 FLOPs 的 8.8%,却占了实测延迟的 57.2%,原因是它的十步迭代循环会启动大量小内核;batch size 提到 32 时,这个占比降到 13.5%,吞吐能到约 100 样本/秒。Cosmos3 则始终是生成主导型,batch size 从 1 提到 16,吞吐只涨了 14.3%。用 control-time Roofline 分析四个 LIBERO 测试套件发现,π0.5 的推理已经比模拟器的环境执行更快,属于环境瓶颈;Cosmos3 仍然是推理瓶颈。这意味着继续压 π0.5 的推理速度收益有限,而 Cosmos3 还有明显的优化空间。
具身智能团队现在普遍面临的问题是:一个策略要同时给评测脚本、云端 RL 训练、边缘服务、机器人本体用,四套代码路径各自优化、各自出 bug,维护成本很高。PhyAI 证明这四种场景可以共享同一套运行时,只靠模型适配器接入新架构。发布当天接入 MiniCPM-Robot 这个案例,说明适配一个新模型的工程成本可以压得很低。control-time Roofline 这个分析工具本身也有独立价值:它给出了一个判断还要不要继续优化推理速度的量化标准,而不是凭经验猜测瓶颈在哪。对正在做具身智能基础设施的团队,这提供了一条不必为每个模型、每个部署场景重新造轮子的路径。
论文自己承认,PhyAI 在多个配置下不是最快的,专门为单一模型和硬件深度定制的运行时(FlashRT、vla.cpp 等)仍有优势,PhyAI 追求的是通用性和有竞争力的延迟,不是极限性能。论文报告的这些延迟数字只覆盖 GPU 执行时间和静态 batch,不包含观测采集、网络传输、请求排队、执行器交接、尾延迟、真实闭环 RL rollout 或机器人任务成功率,论文明确说这些结果只能用来刻画运行时性能,不能当作端到端的机器人成功率或安全性提升的证据。另外,倍速对比的精度设置没有完全对齐(部分结果用了显式 FP8),团队也在未来工作部分承认 Thor 芯片上专用内核覆盖还不够,很多常见算子形状仍要退回到框架默认实现。