PhyAI:边缘实时物理AI推理引擎

PhyAI:边缘实时物理 AI,云端可扩展 Rollout

论文:PhyAI: Real-Time Physical AI at the Edge, Scalable Rollouts in the Cloud
作者:Chenghua Wang、Daliang Xu、Mengwei Xu、Xuanzhe Liu、Yuan Yao 等 22 人(北京邮电大学、南京大学、北京大学、清华大学、明提科技、面壁智能)
arXiv:2608.03682(cs.AI / cs.RO)· 2026-08-04 · 25 页 9 图
代码:github.com/mingti-org/phyai(已开源,含基准测试套件)

一句话总结

PhyAI 是一个面向物理 AI 策略的统一推理运行时:把架构相关的条件注入、求解器、缓存与输出逻辑封装在模型适配器里,把图执行、算子、内存管理与并行服务做成共享底座,让 π0、π0.5、GR00T N1.7、Cosmos3、MiniCPM-Robot 等 VLA 与世界动作模型用同一套代码覆盖机载、边缘与云端三种部署,对官方实现取得 1.40×–4.65× 加速,并提出"控制时间 Roofline"来判断一个控制回路到底是推理受限还是环境受限。

一、研究背景与动机

物理 AI 策略的推理需求贯穿整个生命周期:离线模型评估、云端强化学习 rollout、边缘 GPU 服务、机载部署。这四种场景使用同一个 checkpoint、同一套动作语义,但现实中几乎总是由四套互不相干的推理程序分别承担。每条路径都要独立优化、独立验证,在某个场景里建立的行为结论无法自动迁移到另一个场景——这正是本文要解决的核心矛盾。

统一的推理路径之所以难做,是因为具身模型在执行结构和部署需求两个维度上都高度分化。执行结构上,π 系列 VLA 是"视觉-语言骨干 + 迭代动作专家"的两段式结构,而 Cosmos3 这类世界动作模型(WAM)要让视频潜变量与动作潜变量协同演化;部署需求上,机载执行看重单请求延迟,共享边缘服务要在延迟与吞吐之间权衡,云端 rollout 则使用大 batch 与分布式执行。同一个策略接口之下,不同工作负载需要截然不同的调度与并行策略。

现有系统只覆盖了这个问题的一部分。FlashRT、vla.cpp、realtime-vla、Embodied.cpp 针对特定模型或设备做优化;LeRobot 覆盖数据采集、训练、评估与通用异步策略推理栈,但不提供 PhyAI 所针对的核内级(kernel-level)、多架构执行引擎;vLLM 与 SGLang 提供成熟的面向 token 的 LLM 服务,但其执行模型无法直接表达可复用的多模态条件、迭代动作求解器、演化的世界潜变量或 classifier-free guidance 分支。

作者由此给出问题定义:缺的不是又一个加速器,而是一个能保留模型语义、同时允许每种架构与部署场景自选执行策略的推理运行时。PhyAI 就是这个运行时的工程实现,并用 MiniCPM-Robot 发布当天即通过适配器接口接入,验证了架构的扩展性。

二、预备知识:动作块、RTC 与 Roofline

具身策略普遍采用动作块(action chunking):策略一次输出未来 H 个动作,控制器按块执行。扩散与 flow 策略还会对动作潜变量做多步迭代精化,因此单次推理延迟天然包含"条件编码 + 多步生成 + 输出解码"三段。实时分块(RTC)进一步改变调度:在当前块被执行的同时生成下一个块,让推理时间隐藏进执行窗口,代价是下一块依赖更旧的观测。

Roofline 模型原本用于 HPC 领域,用算术强度把算子划分为"算力受限"与"带宽受限"两个区域。本文把同样的二分区思想移植到控制时间域:横轴是环境执行速率与推理速率之比,纵轴是控制速率相对环境极限的达成度,从而把"推理慢"与"环境慢"两类瓶颈在一个坐标系里分开。

三、方法详解

3.1 从观测到动作的五段延迟分解。控制步 t 上,策略接收相机观测、语言指令与机器人状态,输出 H 个动作:

$$x_{t}=(o_{t},\ell,s_{t}),\qquad a_{t:t+H-1}=\pi_{\theta}(x_{t})$$

论文把观测到控制器的完整路径拆成五段:观测采集 L_observe、传输 L_transfer、排队 L_queue、推理 L_inference、执行交接 L_actuate,关键路径为

$$L_{\mathrm{critical}}=L_{\mathrm{observe}}+L_{\mathrm{transfer}}+L_{\mathrm{queue}}+L_{\mathrm{inference}}+L_{\mathrm{actuate}}$$

这个分解的意义在于划清运行时的责任边界:L_critical 终止于控制器交接,不含动作的物理执行;机载推理消除的是网络传输分量,但传感器与设备拷贝仍在;共享边缘/云服务则额外引入网络与排队。推理再快,观测与执行两段也不会消失。

3.2 控制时间 Roofline。把模型之外的时间归并为 L_noninf,设允许的控制预算为 B_ctrl,则时间裕量为

$$M_{\mathrm{ctrl}}=B_{\mathrm{ctrl}}-\left(L_{\mathrm{inference}}+L_{\mathrm{noninf}}\right)$$

作者强调部署方应关心裕量的分布而非均值,例如要求 P(M_ctrl ≥ 0) ≥ 1−ε。在理想重叠调度下控制周期为 max(L_inference, L_env),顺序执行则为两者之和。用 L_env 归一化后得到两条解析曲线:

$$X=\frac{L_{\mathrm{env}}}{L_{\mathrm{inference}}},\qquad Y=\frac{L_{\mathrm{env}}}{L_{\mathrm{control}}}$$

$$Y_{\mathrm{seq}}=\frac{X}{1+X},\qquad Y_{\mathrm{roof}}=\min(X,1)$$

X < 1 为推理受限区,降低推理延迟直接提高控制率;X > 1 为环境受限区,继续加速只产生时间裕量——裕量可以用来吸收 p99 抖动、换更便宜的设备、或承载更大的模型。实测四个 LIBERO 套件上的 π0.5 都落在环境受限区,而 Cosmos3 的生成路径仍在推理受限区,这一张图直接回答了"哪些模型还值得继续压延迟"。

图 1:控制时间 Roofline(四个 LIBERO 套件上 OpenPI 与 PhyAI 的平均控制率)与同步服务 vs RTC 的时序示意。

3.3 边缘与云端的批处理口径。对 B 个请求的同步 batch,论文统一报告吞吐与摊薄成本两个量:

$$Q(B)=\frac{B}{T_{\mathrm{sync}}(B)},\qquad T_{\mathrm{amort}}(B)=\frac{T_{\mathrm{sync}}(B)}{B}=\frac{1}{Q(B)}$$

并特别提醒 T_amort 不是请求延迟:每个请求仍要等满 T_sync(B),机器人等的是整个 batch 完成,平均值掩盖了等待。这个口径贯穿后文全部 batch 实验。

3.4 架构:模型语义与执行策略的分界线。PhyAI 的核心设计是一条所有权边界:模型适配器拥有定义策略语义的操作——预处理、阶段顺序、求解器更新、缓存有效性、动作转换;运行时负责调度、内存、并行执行与算子选择。边界之下是四层所有权结构:调度器管理多个模型运行器(model runner),配置 DP/TP/CFG 并行度并决定请求去向,但不持有任何模型张量;每个运行器持有请求的可变状态——中间缓冲、KV 缓存、CUDA Graph 桶及其内存生命周期,并推进求解器循环、组装动作块;建模模块无状态,实现架构特定计算(多模态前缀编码、动作专家、视频-动作耦合生成);Layers 接口提供融合与分布式算子,内嵌算子选择器。

图 2:PhyAI 分层架构与组件所有权(调度器 → 模型运行器 → 无状态建模模块 → Layers → 算子选择器)。

这条边界直接对应开源代码的目录组织:phyai/src/phyai/models/ 下每个模型(pi0、pi05、gr00t_n17、cosmos3、minicpm_gr00t)都有自己的 model_runner 与 scheduler;runtime/model_runner.py 与 runtime/cuda_graph_manager.py 是共享执行底座;layers/ 提供 attention、linear、mlp、quant 等分布式算子;parallel/ 实现通信后端。新增 MiniCPM-Robot 只需在 models/ 下按同一接口写一个适配器,这正是论文宣称的"发布当天接入"。

3.5 核内融合。小 batch 下 kernel 启动开销与中间张量流量会主导短算子。PhyAI 实现了自定义 AdaRMSNorm 与"残差加 + RMSNorm"融合核;在 π0.5 中把 Q/K/V 投影合成一个 GEMM、MLP 的 gate/up 投影合成另一个 GEMM,并把 GeGLU/SwiGLU 激活与逐元素乘法融合。MiniCPM-Robot 的 Qwen3.5 混合骨干是另一个例子:一个 Triton 核做 RMSNorm+SiLU 门控,另一个核把深度因果 Conv1d、SiLU 与 Q/K/V 拆分串在一起,直接把 Q、K、V 写到三段连续输出,避免物化再重读合并后的激活张量。在 H20 BF16 上,仅加入这两个核就让 CUDA Graph 路径吞吐从 33.28 Hz 提升到 36.77 Hz(+10.5%),且两个核都对照 PyTorch 的 FP32/BF16 参考实现做过数值校验。

3.6 图重放与状态复用。迭代策略往往重复同样的形状与控制流,只有少量状态在变。PhyAI 让每条模型路径声明可复用状态的有效性范围,由运行器持有对应张量与内存。以 π0.5 标准配置为例:视觉-语言前缀在 10 步 Euler 求解中保持不变,于是只计算一次并保留其 KV 张量、attention 元数据、索引数组与固定缓冲;正弦时间步表与每层 AdaRMS 调制表在去噪前预构建;缓冲与控制流稳定后,整个循环被捕获进匹配的 CUDA Graph 桶;新观测到来时前缀状态被显式失效。对应源码中,CudaGraphRegistry 是一个按形状键索引的图桶字典,运行器在 forward 时按键取图、把真实输入拷入静态缓冲、replay 执行,输出张量是捕获区内分配的静态存储、每次 replay 原地刷新——这套约定让 flashinfer 这类外部库也能进入捕获区,前提是其元数据缓冲一次性预分配并原地更新。

3.7 基于 profiling 的算子选择。PhyAI 不把 Layer 绑死到单一 kernel 实现:最快选择取决于张量形状、数据类型、加速器与执行配置。算子选择器对这些输入应用规则,分派到 phyai-kernel、框架算子或外部库。论文给出的实例是 π0.5 动作专家:50 个查询 token 对长前缀、头维 256,profile 显示 FlashInfer 的 FA2 prefill 比自动选择的 FA3 更快,于是把 FA2 记录进硬件 profile;运行器在 setup 时分配 workspace,每个动作块刷新一次 attention plan,然后进入图重放。换一块加速器可以选择完全不同的实现而不改建模代码。源码中 layers/linear/dispatch.py 的 select() 与 registry.py 的候选打分逻辑即此机制的落点。

3.8 量化与并行执行。量化走离线 RTN(phyai-model-optimizer),执行时用 FlashInfer 与 Humming 的高性能算子,支持 W4A16/W8A16/W8A8/W4A8;本文的延迟与 batch 测量均用 BF16,因此加速数字与量化路径无关。并行执行方面,DP/TP/CFG 三个自由度写进每个模型的执行配置,调度器据此构建设备组。DP 下每个运行器独立持有缓冲、缓存与求解器状态、互不通信——π0.5 因此直接复用单 GPU 路径,加副本不需要第二条分布式模型路径。Cosmos3-Nano-Policy-DROID 则同时用 TP 与 CFG 并行:GEN transformer 联合更新视频与动作 token,TP 在每个分支内部切分这份计算;条件分支与无条件分支在 guidance 合并之前相互独立,调度器把二者放进两个独立 TP 组,rank 构成 2×N_TP 网格,坐标 (c,t) 标识 CFG 分支 c 与 TP 分片 t。每个 TP 组内 QKV 与 MLP gate/up 列并行、注意力头按 rank 切分,attention 输出与 MLP down 行并行并由 all-reduce 合并。

每个去噪步结束后,配对的 TP rank 执行 CFG all-gather 拿到条件与无条件速度,每个 rank 本地执行引导合成:

$$v_{\mathrm{guided}}=v_{\mathrm{uncond}}+\gamma\left(v_{\mathrm{cond}}-v_{\mathrm{uncond}}\right)$$

γ 为引导尺度,与 CFG 并行度无关。8 GPU 配置下 rank 0–3 组成条件 TP4 组,rank 4–7 组成无条件组,all-gather 配对为 (0,4)、(1,5)、(2,6)、(3,7)。源码 scheduler_wn_cosmos3.py 中可以直接读到这段实现:v_pair = P.all_gather(v_local.unsqueeze(0), axis="cfg", dim=0) 后执行 v_vel = v_pair[1] + guidance_scale × (v_pair[0] − v_pair[1]),随后交给 UniPC 求解器推进。若请求还要视频解码,调度器复用 8 个 rank 做空间分块 VAE:权重复制,每 rank 解码 2×4 行主序网格中的一块,运行时收集拼接。

图 3:八卡 Cosmos3 执行拓扑——两个 CFG 分支、每分支内 TP4、可选的分块视频解码。

flowchart TB
    REQ["Policy Request
observation + language + state"] --> SCH["Scheduler
DP / TP / CFG device groups"]
    SCH --> R1["Model Runner rank 0-3
conditional branch TP4"]
    SCH --> R2["Model Runner rank 4-7
unconditional branch TP4"]
    R1 --> MM["Stateless Modeling Modules
prefix encoding / GEN transformer"]
    R2 --> MM
    MM --> LY["Layers Interface
fused + distributed operators"]
    LY --> SEL["Operator Selector
shape x dtype x accelerator rules"]
    SEL --> K1["phyai-kernel"]
    SEL --> K2["framework ops"]
    SEL --> K3["library kernels"]
    MM --> CG["CUDA Graph Buckets
state reuse + graph replay"]
    R1 --> AG["CFG all-gather
v_pair = [cond, uncond]"]
    R2 --> AG
    AG --> GD["Guided Velocity
v = v_uncond + gamma * (v_cond - v_uncond)"]
    GD --> UP["UniPC Solver Step
video + action latents"]
    UP --> AG

PhyAI 的 Cosmos3 执行流程:调度器把两个 CFG 分支分到 2×N_TP 网格,每分支内做 TP4;每个去噪步后按 cfg 轴 all-gather 两个分支速度,所有 rank 计算相同的引导合并与 UniPC 步进,再进入下一步。

四、实验结果

4.1 单请求延迟:11 对全胜。测量口径是模型运行器产出一个完整动作块的时间,即 L_inference 的代理,不含观测、传输、排队与执行交接。结果如下表:

模型	设备	官方实现	PhyAI	加速比
π0	Thor	321.03 ms	121.50 ms	2.64×
π0	RTX 5090	127.48 ms	31.48 ms	4.05×
π0.5	Thor	179.50 ms	107.70 ms	1.67×
π0.5	RTX 5090	52.08 ms	28.61 ms	1.82×
GR00T N1.7	Thor	133.47 ms	95.37 ms	1.40×
GR00T N1.7	RTX 5090	46.96 ms	20.62 ms	2.28×
GR00T N1.7	A40	199.70 ms	46.35 ms	4.31×
MiniCPM-Robot	Thor	156.21 ms	56.27 ms	2.78×
MiniCPM-Robot	RTX 5090	47.20 ms	23.33 ms	2.02×
MiniCPM-Robot	H100	105.38 ms	22.64 ms	4.65×
Cosmos3-Nano-Policy-DROID	H20×8	2460 ms	1180 ms	2.08×

表 1:单请求延迟对比(越低越好),对应论文 Table 5。

但与专用运行时的对比结果更复杂:FlashRT 的两个 π0 数据点是 FP8(Thor 49.5 ms、RTX 5090 19.7 ms),与 PhyAI 精度不匹配;在 RTX 5090 上 realtime-vla、FlashRT 与 PhyAI 跑 π0.5 分别为 27.5、28.5、28.6 ms,几乎打平;FlashRT 在 Thor、RTX 5090、A40 上的 GR00T 也快于 PhyAI。作者因此把主张收敛为"对官方路径全面更快",而非"每个配置下最快"。

图 4:六个具身策略的单请求延迟全景(方括号为 PhyAI 相对官方路径的加速比,斜纹柱为 FP8 结果)。

4.2 批扩展与阶段剖析:三种不同的 regime。π0.5 在 Hopper 级 GPU 上 batch=1 时 22.59 ms、44.26 samples/s,batch=32 时吞吐升至 100.02 samples/s,但同步 batch 要 319.94 ms 才完成,摊薄成本 10.00 ms/sample——rollout worker 用的是 100 samples/s 的容量,机器人等的却是 320 ms 的整批。Thor 更早进入平台期(7.43 → 16.25 @ b16 → 15.89 @ b32)。GR00T 在 RTX 5090 上从 b1 的 20.49 ms 涨到 b32 的 230.50 ms,吞吐 48.8 → 138.8 samples/s,batch=8 即达到 b32 吞吐的 92.2%,继续加大 batch 主要是加大同步等待;阶段占比随之翻转:b1 时 Action Head 占 59.2%、Backbone 占 40.7%,b4 起 Backbone 反超,b32 时达 69.7%;Backbone MFU 从 33.0% 升到 b8 的 56.9%,Action Head MFU 从 13.2% 升到 73.1%。

Cosmos3 是第三种 regime:33 帧 480×832、32 个动作、4 步去噪、CFG 3.0、eager 执行(未启用 CUDA Graph),Hopper 上 b1 就要 1.132 s、0.883 chunks/s,b16 整批 15.85 s、1.010 chunks/s,吞吐只多 14.3%;Thor 上甚至从 0.123 微降到 0.119 chunks/s。

图 5:π0.5 BF16 批扩展(CUDA Graphs)——吞吐、整批延迟与阶段 GPU 时间占比。

阶段级 Roofline 解释了这些差异。论文定义相吞吐与逻辑算术强度:

$$P_{i}(B)=\frac{BF_{i}}{T_{i}(B)},\qquad I_{i}^{(\mathrm{logical})}(B)=\frac{BF_{i}}{Q_{i}(B)}$$

其中逻辑张量流量 Q_i(B) 含权重、激活、KV 缓存与边界 I/O 四项,并用本机 8192×8192 BF16 GEMM 测算力顶 P_peak、4 GiB 设备拷贝测带宽顶 B_memory,构造设备参考包络:

$$P_{i}^{(\mathrm{ref})}(B)=\min\!\left(P_{\mathrm{peak}},I_{i}^{(\mathrm{logical})}(B)B_{\mathrm{memory}}\right)$$

在 Hopper 级 GPU、batch=1 时,π0.5 动作专家只占估计 FLOPs 的 8.8%,却占 profile 延迟的 57.2%:它的小 GEMM 循环只做到 28.1 TFLOPS、逻辑算术强度 50.8 FLOP/byte,远在实测脊线 184.8 FLOP/byte 左侧——低吞吐加大时间占比,锁定动作循环为小 batch 瓶颈。batch=32 时专家跨过脊线、做到 271.3 TFLOPS(算力顶 791.3 TFLOPS),时间占比降到 13.5%,语言与视觉分别占 51.4% 与 35.1%,瓶颈转移。相反,Cosmos3 生成阶段 b1 的逻辑算术强度已达 926.2 FLOP/byte,落在两条脊线右侧,做到 585.5 TFLOPS(Hopper)/75.0 TFLOPS(Thor),MFU 分别为 68.5%–73.9% 与 61.0%–65.8%,显存占用始终低于 44%——它从 batch=1 起就是算力受限,加 batch 换不来多少吞吐,要降延迟只能靠请求内并行(TP/CFG)。

4.3 云端 RL rollout 与功能验证。论文把 PhyAI 接到 RLinf 的推理后端边界上,在 4×A800 80GB(无 NVLink)单节点 profile π0.5 的 GRPO 训练(LIBERO-10,32 环境、480 步/rollout epoch、8 epoch、每次策略查询执行 10 个动作、4 步 flow 去噪):稳态 RL 步长 955.8 s,其中权重同步 2.836 s、rollout 与轨迹收集 521.5 s、actor 训练 431.4 s;各 rank 累计 predict 时间 151.5–152.4 s,最慢的 rank 2 占整步 15.9%、占 rollout 阶段 29.2%。PhyAI 对 RLinf 默认后端的 predict 时间实测加速 2.55×;用理想化 Amdahl 模型(非推理部分不变、加速调用仍在关键路径)外推,步时间从 955.8 s 降到 863.2 s,即 −9.7%、端到端 1.11×。作者观察到两类配置会把 predict 占比推到 40%–50%(增加 flow 去噪步数、减少 actor 更新轮数),届时同样外推给出 −24.3% 至 −30.4% 步时间、1.32×–1.44× 端到端加速。论文另模拟了 8×A100、batch 40、每 RL 步 41 次策略调用的集成 rollout:推理占比从 53.1% 降到 36.2%,对应 rollout 步延迟 −26.5%、训练吞吐约 1.36×。

项目	数值
RL 步总时长(稳态)	955.8 s
权重同步	2.836 s
Rollout + 轨迹收集	521.5 s
Actor 训练	431.4 s
单 rank 最大 predict 时间	152.4 s(占整步 15.9%、占 rollout 阶段 29.2%)
PhyAI 对 RLinf 的 predict 加速(实测)	2.55×
Amdahl 外推整步时间	955.8 s → 863.2 s(−9.7%,端到端 1.11×)
predict 占比 40%–50% 时外推	−24.3%~−30.4% 步时间,1.32×–1.44×

表 2:π0.5 GRPO on LIBERO-10(4×A800 80GB,无 NVLink)的稳态 RL 步剖析与 PhyAI 收益外推。

图 6:四张 A800 上一个稳态 RL 步的时间线(predict 占用示意)。

加速是否损害动作质量?附录给出匹配条件下的功能验证:GR00T N1.7 在 LIBERO-10 上,官方 Isaac-GR00T 与 PhyAI 使用同一 checkpoint、同一组 500 个初始状态、同一任务顺序与仿真参数,成功率分别为 91.2%(456/500)与 91.8%(459/500);π0.5 在四个 LIBERO 套件共 2000 个 episode 上成功 1949 个,合计 97.45%,四个套件的平均推理时间稳定在 36.10–36.33 ms(libero_spatial 97.8%、libero_object 99.8%、libero_goal 98.0%、libero_10 94.2%)。这说明加速来自执行策略而非改变模型计算。

五、局限性与作者自述的边界

这篇论文的坦诚程度在系统类论文中少见，作者主动划定了结论的适用边界。

其一，与专用运行时的对比并不占优。作者明确承认 FlashRT 在多个配置下比 PhyAI 更快（GR00T 在 Thor、RTX 5090、A40 上均如此），realtime-vla 的 PI0.5 也略快（27.5 vs 28.6 ms）。PhyAI 的加速声明只相对官方实现成立，而且与 FlashRT 的对比并非精度对齐（对方用 FP8）。作者的取舍是：追求"一套运行时、有竞争力的延迟"，而不是"每个配置都最快"。

其二，测量只覆盖推理器内部时间。所有延迟数字都是 $L_{\mathrm{inference}}$ 的代理，不含观测采集、网络传输、请求排队、执行器交接，也不含尾延迟与闭环任务质量。作者强调这些数据用于刻画运行时性能，"不能用来声称机器人成功率或安全性的端到端提升"。

其三，RL rollout 的端到端收益是投影而非实测。A800 上 2.55 倍 predict 加速是实测，但 1.11 倍的整步加速来自 Amdahl 定律的理想化外推（假设非推理部分不变、加速调用始终在关键路径、无集成开销）。40%–50% predict 占比下的 1.32–1.44 倍更是基于改变配置后的假设场景。

其四，Thor 平台的优化深度不足。作者自述 Thor 上架构专用 kernel 很少，大量常见形状只能回退到框架或库实现，这正是 PI0.5 在 Thor 上批处理扩展不如 Hopper 的原因（vision 与 expert 始终位于脊点左侧）。此外 Cosmos3 的单卡剖析不含 TP/CFG 扩展性测量，逻辑算术强度也不等于真实 DRAM 流量。

其五（我的观察）：统一运行时的维护面很宽——每新增一个模型家族都要写 adapter、scheduler、solver 状态管理，而模型迭代速度极快（MiniCPM-Robot 式的 day-0 支持会反复发生）；adapter 接口的稳定性将决定这个项目的长期可扩展性，目前只有 6 个模型的样本量，接口是否经得起 20+ 模型的考验尚待观察。

六、总结与展望

PhyAI 回答了一个被 LLM 推理社区早已回答、却第一次被系统性搬到具身智能领域的问题：谁来为物理 AI 策略提供统一的推理运行时？它的答案是把"模型语义"与"执行策略"切成两层——adapter 拥有条件、求解器、缓存与动作转换，运行时拥有图回放、kernel、内存与并行。这一刀切下去，π0.5 的单卡路径可以零改动变成 8 卡 DP 服务，Cosmos3 的双分支 CFG 可以自然映射到 2×4 的 GPU 网格，新模型可以 day-0 接入。

配套的控制时间 Roofline 把"推理该加速到什么程度"从直觉变成了可计算的判据：π0.5 在 LIBERO 上已经 environment bound，继续压延迟只能换来时间余量；Cosmos3 仍然 inference bound，值得投入请求内并行。这个工具对部署决策的价值可能超过加速数字本身。

作者的路线图同样清晰：Mega Kernel 把 π0.5 的 action expert 十步循环编译成单一持久化内核；用 AutoKernel/AVO 式的 kernel agent 自动攀爬 Thor 的性能山；把 PhyAI 做成 RLinf 的正式 rollout backend 并实测端到端；支持小米、灵波、华为系等新模型与昇腾、昆仑芯、AMD 等新硬件；最终定义一套机器人 MaaS 的生产级服务协议——观测是带时间戳的有状态流，动作会过期，新状态可以取代在途计算，协议要像视频编码一样利用时间冗余。若这些落地，"一个运行时跟随模型去任何需要运行的地方"将从愿景变为具身智能的标准基础设施。

七、金句

"更好的基础设施让算法研究者有余裕提出更大胆的问题。执行中省下的时间，可以兑换成更快的控制，也可以投入到更强的模型与更丰富的观测中。"

"模型语义归 adapter，执行策略归运行时——同一个模型路径应该在机器人 MaaS、云端 RL rollout、边缘云与纯机载执行中一路跟随，而不必被强行塞进同一种执行策略。"

"控制时间 Roofline 给运行时优化划定了一个实际的终点：一旦推理装进了动作窗口，控制器在理想重叠下就不会再变快。"

本文基于 arXiv:2608.03682v1 全文精读撰写；图片来自论文 HTML 版本的原始矢量图；代码引自 github.com/mingti-org/phyai 仓库。