PhyAI：一套运行时打通物理 AI 的边缘实时推理与云端规模化部署

背景

物理 AI 策略在其整个生命周期中都需要推理能力：开发阶段的模型评测、云端强化学习回滚（rollout）、边缘 GPU 服务，以及最终的机载部署。虽然这些场景消费的是同一个检查点、同样的动作语义，但它们通常依赖各自独立的推理程序，图执行、算子选择与内存管理被反复重复实现。这种碎片化迫使团队维护多条代码路径，也很难在整条技术栈上一致地分析实时性表现。

核心创新

PhyAI 提供一个统一运行时：把架构相关的逻辑（条件计算、求解器、缓存与输出处理）放进模型适配器，而图执行、算子、内存管理与并行服务在所有部署目标之间共享。同一套代码库可以在机载、边缘、云端的单卡或多卡环境下运行 VLA 模型与世界动作模型。适配器接口被刻意设计得很轻——作者在 MiniCPM-Robot 发布当天就完成了接入。论文还提出”控制时 Roofline”这一分析概念，用于区分推理受限与环境受限的控制回路，为团队判断优化资源该投向何处提供了原则性依据。

实验结果

在官方实现对比中，PhyAI 对 pi0、pi0.5、GR00T N1.7 与 MiniCPM-Robot 取得 1.40–4.65 倍加速；在 Cosmos3-Nano-Policy-DROID 上，八卡 H20（CFG=2，TP=4）的延迟从 2.46 秒降至 1.18 秒，加速 2.08 倍。细粒度剖析解释了不同模型为何需要不同的执行策略：在 Hopper 系列 GPU 上、batch size 为 1 时，pi0.5 的动作专家仅占 8.8% 的 FLOPs，却贡献了 57.2% 的延迟；batch size 提升到 32 后，其占比降至 13.5%，吞吐达到约 100 samples/s。Cosmos3 仍然以生成阶段为主导，batch size 从 1 增至 16 时吞吐仅提升 14.3%。按控制时 Roofline 实测，pi0.5 在四个 LIBERO 套件上属于环境受限，而 Cosmos3 属于推理受限。

局限性

作者明确承认，在若干配置下专用运行时仍然更快；其目标是一个延迟具有竞争力的统一运行时，而非在每种情况下都做到最快。基准评测集中于一组特定的开源模型，随着新的 VLA/WAM 架构出现，绝对数字可能发生变化。实时性结论基于 GPU 部署的剖析数据，机载受限硬件上的表现刻画不如云端与边缘场景充分。

行业影响

机器人公司目前为仿真回滚、边缘服务器与机载计算机分别维护推理栈，这种重复建设拖慢了迭代速度，也让延迟保证变得复杂。一个带可插拔适配器的统一运行时直接击中这一成本点：新模型发布可在数天内完成接入，同一套代码既能跑在八卡云端集群也能跑在机载计算机上，控制时 Roofline 则为团队诊断”机器人是算力受限还是环境受限”提供了共同语言。随着开源 VLA 与世界动作模型不断涌现，一个开源的、基于适配器的推理引擎有望成为物理 AI 技术栈的默认服务层。