Physical AI迎来首个端边云统一推理运行时：北邮、北大、清华、明体科技等联合推出PhyAI
核心结论：来自北京邮电大学、北京大学、清华大学、南京大学、明体科技及面壁智能的联合团队推出了 PhyAI，这是首个面向 Physical AI 的端边云统一推理运行时。针对当前具身智能在离线评测、云端强化学习 Rollout、端侧实时控制、工厂服务等四类场景中需维护四套代码、迁移成本高及效率参差不齐的问题，PhyAI 实现了单套代码的全场景无缝迁移。其核心架构包含 Model Adapter 和 Scheduler，统一管理调度、算子融合与多卡并行。在 Benchmark 评估中，PhyAI 相对官方实现产生了 1.40 倍至 4.65 倍的显著加速，例如将 MiniCPM-Robot 在 H100 上的推理延迟从 105.38ms 骤降至 22.64ms；在多机器人真机并行场景中，延迟最高降低 2.3 倍并消除了卡顿。文章提出了关键分析模型“Control-Time Roofline”，指出在算力过剩的 GPU 上，物理环境响应已成为新瓶颈，单纯降低模型推理延迟无法线性提升机器人的整体控制频率，这为具身智能算法与硬件的协同设计提供了全新的量化依据。
- PhyAI 实现端边云四类场景（离线评测、云端 RL Rollout、端侧实时、工厂 MaaS 边缘服务）的统一推理，相对官方实现提供 1.4x 至 4.65x 的加速。
- 在 H100 上，PhyAI 将 MiniCPM-Robot 推理延迟从 105.38ms 降至 22.64ms；在 真机多机器人并行场景中，延迟最多降低 2.3 倍且无卡顿。
- 提出 Control-Time Roofline 分析模型，指出硬件加速带来的推理延迟降低并非总能线性提升控制频率，需与环境瓶颈协同设计。
- PhyAI 采用 Model Adapter 封装语义，底层调度、缓存与算子融合由 Scheduler 统一管理，实现一套代码在多卡分布式与单卡场景间复用。
- 在 PI0.5 模型的云端 GRPO 强化学习训练中，应用 PhyAI 框架后推理时间减少约 9.7%，预估降低了整体 RL 训练耗时的比例。
这是一篇能直接改写我们“重复造轮子”现状的文章。当行业还习惯于分离的“端-边-云”三套代码时，来自北邮、北大、清华等团队的 PhyAI 首次提出了面向 Physical AI 的统一推理运行时。编辑最看重的是它解决了从原型验证到离线评测、再到强化学习 Rollout 及云端并发服务场景中代码互不通用的迁移痛点。文章里对 MiniCPM-Robot 实机部署中时延降低 2.3 倍的数据，以及“Control-Time Roofline”这一将物理环境瓶颈纳入硬件加速收益评估的分析工具，非常适合推荐给每一位从事具身智能推理工程化的前线部署工程师（FDE）和架构师阅读。
PhyAI 实现端边云四类场景（离线评测、云端 RL Rollout、端侧实时、工厂 MaaS 边缘服务）的统一推理，相对官方实现提供 1.4x 至 4.65x 的加速。
—— 络石智能编辑部 · 编辑推荐Physical AI迎来首个端边云统一推理运行时：北邮、北大、清华、明体科技等联合推出PhyAI
Physical AI迎来首个端边云统一推理运行时：北邮、北大、清华、明体科技等联合推出PhyAI
Physical AI迎来首个端边云统一推理运行时：北邮、北大、清华、明体科技等联合推出PhyAI
机器之心Pro
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
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，以进行算法和硬件的协同设计。
标签
相关主题
专家点评
本文由编辑团队收录整理，内容来源于公开信息，仅供参考。