Pi API：机器人基础模型的托管服务，护城河是把失败变成新数据的速度

Pi API 被普遍当成「机器人领域的 OpenAI API」来理解，这层理解漏掉了它真正在卖的东西。Physical Intelligence 官方描述自己的工作流时，重心落在 failures 上：采集示范、训练模型、放到机器人上测试，再用失败来决定下一批该采什么数据Pi API。接口能复制的是权重和调用方式，复制不了的是每台机器人在自己场景里攒出来的失败分布，所以机器人性能的第一变量不是模型多强，而是失败被多快补成新训练数据。

一、开放模型接口只能提供起点，机器人性能由失败分布决定

Pi API 卖的不是一个能驱动多种机器人的模型接口，而是把「失败变成下一批训练数据」这段回路托管起来的能力。一个模型同时驱动多种形态的机器人，这件事确实成立，但同一套权重落到具体一台机器人上只是起点，它在这一台上能不能干活，取决于这一台在自己的场景里积累了多少失败样本。

这段回路无法用接口替代，原因在两者的输出性质不同。LLM 调一次接口，返回的文本就是终点；机器人策略发出的是一串动作，动手之后环境会变，下一次它看到的状态也跟着变，策略的输出于是改写了自己未来的输入。接口再顺滑也管不住策略把场景推到自己没见过的地方去，这就决定了接口本身给不出「机器人能干好活」的保证，只有把策略自己走出来的那些状态采回来、补进训练数据，模型接到机器人上才真正开始变得有用。

π0 的模型基线说明的正是通用这一半已经成立，也因此把价值逼回到失败闭环上。π0 是一个视觉语言动作模型（VLA，vision-language-action model），做法是把一个 Internet 规模预训练过的视觉语言模型（VLM）当主干，再挂一个专门输出连续动作的 action expert 分支，两个分支各有一套权重，只在 attention 层交换信息。它在超过 10,000 小时的机器人数据、7 种机器人构型、68 个任务上预训练，之后同一套权重可以直接驱动动作空间各不相同的多种机器人。通用既然已经可达，模型层面的差距就不再是决定性的那一段，剩下的变量只有每台机器人自己的失败分布。

图注：π0 的框架总览。左侧是它的预训练数据混合，既包含团队自采的操作数据，也包含开源的 OXE / Bridge / DROID；中间是模型本体，一个 PaliGemma 主干与一个体量小得多的 action expert 并排，后者负责用 flow matching 生成动作块；右侧是同一个模型被用于控制的多种机器人构型。这张图回答的是「通用基础模型到底长什么样」，不是某种算法的性能对比。π0

这正是 Pi API 卖的那一段：一个模型对所有本体都只给一个起点，它在每一台上都还欠一段针对性调整，而这段调整的依据只能来自这台机器人自己跑出来的失败。通用先验解决的是「从零到能用」，不是「从能用到好用」。于是官方那句原话的后半截就成了产品的重心：失败，才是下一轮数据从哪里来的依据。

二、Pi API 真正产品化的是一条「采集—微调—真机测试—按失败补采」的闭环

Pi API 卖的不是把模型接到机器人上，而是把「跑失败、补数据、再微调」这条回路托管化，闭环的快慢才是它对外承诺的东西。

官方对这套流程的描述是：你上传数据，在它管理的算力与基础设施上启动微调，再通过托管网关访问微调后的模型来跑推理Pi API。官方流程图画得比这段话更清楚：数据进入 Ingestion，经过被高亮标注的 Fine-Tuning，再由云端推理送到机器人上。

图注：官方画的 API 工作流。信息沿着你的数据、数据接入、托管微调、云端推理、机器人这条线向右走，但真正值得盯的是绕回来的那一支：在机器人上评估、按评估结果采集数据、重复。图上被高亮的是微调，绕回来的箭头才是产品本体，它让每一次推理都变成下一轮训练的输入。Pi API

这条回路跑得快不快，有公开的锚点。Almond 做的是双机械臂机器人 Axol，它给自己加工的零件去毛刺，用的模型是团队用 Pi API 迭代四天拿到的Pi API。

图注：Almond 的 Axol 双机械臂正在给自己装配用的垫片去毛刺，红砖墙背景，右侧能看到线缆与办公椅一角。它对应的不是演示视频里的一场展示，而是一次迭代周期用时的实物证据：这台机器人手上跑的是四天迭代出来的模型。Pi API

官方公布的早期客户跨了好几个行业：自行式重型机械的装载作业、农业机器人、餐饮自动化、乳制品、制造业输送带与服装处理。行业跨度说明的是这条闭环不是某个场景的特例，而是一套能反复套用的流程。

同一个模型栈还有第二种用法。官方在介绍 π0 与 π0.5 时，把托管 API 与开源仓库 openpi 放在同一段里同时点名Pi API。也就是说，托管与自托管不是两条路线之争，而是同一套预训练权重的两种交付方式，「便利对数据控制权」的取舍留到最后一章再谈。

闭环跨行业跑得通，但它跑在云上。官方对早期部署的措辞相当克制：多数案例走云端推理，早期部署暴露了一批需要改进的地方，其中包括部分客户遇到的网络连接问题。这里的措辞是「for some」，指一部分而非普遍。这个问题有多硬，需要第三方数据来量化，那是第五章的事。

三、策略走进示范未覆盖的状态时，离线模仿会误差复合：真机 rollout 是这类风险的出路

当策略会进入专家示范没有覆盖的状态时，单靠离线模仿会发生误差复合。这里的前提是「策略自己会走进陌生状态」，而不是说所有离线模仿都注定失败：只要策略的运行分布偏离示范分布，离线损失的数值再低，也补不上那些它自己会走进去、示范里从没教过的状态。真机 rollout 是应对这一类风险的路径，让策略真的跑起来，把它自己走进的状态采回来，再交给专家打标。失败驱动的数据迭代不是收集癖，而是这类场景下的学理必修课。

这件事最早是被一个自动驾驶的悖论讲清楚的。1989 年 Pomerleau 训练 ALVINN 时发现，一个称职的驾驶员从不演示「怎么从路边开回路中央」，因为正常驾驶里根本不出现这种场面。于是训练数据里几乎没有脱困动作，朴素监督学习出来的网络一旦跑偏，就只会越偏越远SMILe。

原因在于序列决策破坏了监督学习最依赖的那个假设。统计学上的 i.i.d. 假设要求样本独立同分布，但机器人的下一步观测恰恰由它上一步的动作决定：策略一旦偏离专家走过的路，就会进入专家示范里从未覆盖的状态，接下来每一步都从这些陌生状态出发，错误沿着时间步不断复合。Ross 与 Bagnell 在 2010 年把这个现象写成了定理，传统监督式模仿学习的性能下界是二次增长的SMILe：

$$J(\hat{\pi}) \le J(\pi^*) + T^2 \varepsilon$$

这里的 $T$ 是任务的时间步数，$\varepsilon$ 是策略在专家状态分布下的单步出错概率。关键在平方：单步错误率不变，任务越长代价涨得越快，而原因不是模型不行，是它自己把自己带到了训练集没教过的地方。

DAgger 给出的回答是别再用离线数据硬拟合，让策略跑起来，再把它自己跑出来的状态交给专家打标DAgger。

这个循环最反直觉的一点是它采的不是「更难的任务」，而是「当前策略自己会犯错的地方」。第一轮让专家示范，之后逐渐减少专家参与、改由策略自己跑，再用专家在它走过的那些状态上打标。于是训练分布被主动撑到运行分布上去，误差增长从二次被压到随时间线性增长。真正决定成败的不是数据集有多大，而是新采集的数据是否覆盖了策略自己去过的地方。

Pi API 的按失败补采，就是把这套直觉做成了基础设施。它没有提出新的学习方法，只是把「让策略真的跑、把失败采回来、重训、再部署」这条本来要靠研究团队手工搭的回路，做成了客户可以自己转动的托管服务。需要说清的是，DAgger 的实验是 2011 年在赛车游戏与 OCR 基准上做的，不是机器人真机实验；它提供的是为什么必须这么做的理由，而不是「照搬这个算法就能落地」的保证。

四、通用先验能压低冷启动，因为跨本体数据学的是可迁移的物性与语义

通用先验确实把冷启动成本压下来了，但它压的是「从零到能用」，压不掉「从能用到好用」。跨本体数据提供的是可迁移的物性与语义，剩下的现场适配仍要回到上一章那条失败闭环。

先看现象层的数字。π0.5 论文报告，提供给模型的第一阶段训练样本里，97.6% 并不来自执行家务的移动机械臂，而是来自其他机器人或网络数据π0.5。这个比例只适用于第一阶段，第二阶段的配比并不相同。

那 97.6% 具体是什么，论文给了清单。

图注：论文六类训练数据的真实样本拼贴（MM/ME/CE/HL/WD 用于第一阶段，VI 在第二阶段才加入，CE 在第二阶段被剔除）。MM 是移动机械臂在约 100 个家庭里采集的家务数据，是与评估任务最直接相关的那一片；ME 是固定机械臂在众多不同家庭里采的数据，本体与目标机器人不同；CE 是实验室条件下多种构型机器人采的数据，包含开源数据集；HL 是高层子任务预测；WD 是网络图文数据；VI 是专家用语言逐步指挥机器人的样本。一眼能看出绝大多数样本不是目标机器人的家务数据。π0.5

这六类数据不是添头。论文做了配比消融，把 ME 或 CE 任一来源移除，模型在测试任务上的表现都会明显退化，两者同时移除更差π0.5。

图注：五组训练配比消融的对比，分别是完整配方、去掉网络数据、去掉跨本体多环境数据、去掉实验室跨本体数据、以及两项跨本体数据都去掉。要读的不是某根柱子高出多少，而是方向：跨本体数据一旦缺失，整体表现就往下走。网络数据在这一组测试里差异不显著，影响主要体现在未见物体的识别上。π0.5

现象层到这里还差一步：训练样本里绝大多数不是目标机器人的数据，为什么没有把控制精度带坏？π0.5 论文没有为这个问题指定某个专门的机制设计，那 97.6% 是数据配比层面的现象，不是某项训练技巧的效果归因。要看清「通用语义与连续控制可以怎样分工」，可以借另一项工作的机制方案：Physical Intelligence 的 Knowledge Insulation（知识绝缘，KI）。KI 是对 π0.5 做法的形式化与单阶段化，给出的是一个可借鉴的做法，让三件事同时发生：VLM 主干继续用离散化的动作 token 加通用 VLM 数据做 next-token prediction，action expert 用 flow matching 输出连续动作，而 action expert 到主干的反向梯度被 stop-gradient 切断。

图注：知识绝缘版本的架构示意，不是 π0.5 的整体架构。左边是 VLM 主干分支，接收图像编码与提示，输出语言预测与离散动作 token；右边是 action expert 分支，从噪声出发用 flow matching 输出连续动作；中间红框的 Stop Gradient 切断了 action expert 反向传到主干的那条梯度，让主干的语言与物体语义不会被动作学习污染。跨本体数据因此贡献的是可迁移知识，而不是把控制精度带偏。KI

这套机制报告过约 7.5 倍的训练步数节省，但只在 bussing 任务的 generalist 设置下报告，跨任务是否成立论文未给出。它说明的是通用语义与连续控制可以分工的一种可能做法，而不是那 97.6% 结果的成因，把它当成「通用先验为什么能压低冷启动」的可借鉴方案即可。把四章串起来看，通用先验的定位就清楚了：它让一个新本体不必从零开始，把冷启动的时间压下来；它压缩不了的是从能用到好用这一段，因为那一段的瓶颈不是先验不够广，而是这一台机器人在这个场景里的失败还没被采回来。

五、云端推理有一道硬墙：RTC 能吸收延迟，吸收不掉断网与安全认证

软件层的补丁能把几十毫秒级的推理延迟与网络抖动吸收掉，让精细任务在云上仍然干得成；但断网、功能安全认证与确定性控制这类问题，补丁救不了。

先把问题说准。VLA 模型按动作块（action chunk）的方式工作，一次推理生成未来若干步的动作，机器人执行完再请求下一块。模型在远端意味着生成一块动作需要真实的墙钟时间，这个延迟换算成控制器步数记作 $d$：新动作块生成出来时，旧块的前 $d$ 步已经被执行掉了。如果让推理同步等待，块与块之间就出现肉眼可见的停顿，机器人动力学随之改变，训练与部署之间出现分布错位；而如果粗暴地直接切换新旧两块，两块策略在交界处不一致，会产生异常大的加速度。

RTC 的做法是把块与块的交界当成一次 inpainting 来解：新块的前 $d$ 步必须忠于旧块即将执行的值，直接冻结；中间一段用指数衰减的权重做过渡，越靠近分界约束越强；旧块结束之后的最后若干步则完全重新生成。

图注：RTC 把异步推理的块交界变成一次 inpainting 的几何关系。横轴是动作时间步，纵轴是引导权重。最前一段的旧动作被完全冻结，权重为 1；中间段的权重从 1 指数衰减到 0，形成一段连续的过渡带；最后一段完全没有旧动作可参照，必须重新生成。三段之分解释了为什么存在较大延迟时动作还能接得上。RTC

效果有实机数据支撑。论文在 6 个双臂任务、480 个 episode、28 小时真机执行上做了对比，并在网络延迟之外人为注入 +100 毫秒和 +200 毫秒。结果是 RTC 的综合指标在所有延迟下都最好，对注入延迟几乎不退化；同步推理随延迟线性变差；两种 temporal ensembling 变体在 +100 毫秒时就已经因为振荡过大触发机器人的保护性停机，根本跑不完实验。论文还把划火柴作为代表任务单独提出来，那是唯一不允许重试的精准动作，RTC 在这项上的最终得分明显领先RTC。这些数字有前提：它们出自 π0.5 基座加注入延迟的实验设置，不代表任意部署条件下都成立。

代价也要说清。RTC 在每个去噪步都要做一次反向传播，单个去噪步的算力约为原来的 2.5 倍，整体推理耗时从 76 毫秒涨到 97 毫秒；而且它只适用于 diffusion 与 flow 类策略，自回归离散 token 的模型要先做转换。后续工作从另一个方向处理同一问题：把延迟直接模拟进训练，让动作前缀在训练阶段就进入条件分布，推理时不再需要 inpainting。这条路径在 π*0.6 上把端到端平均延迟从推理时版本的 135 毫秒降到 108 毫秒Training-time RTC。它的限制是必须先估好部署时的延迟分布再离线训练，对客户网络条件不确定的托管平台并不天然友好。

再往下就是软件补丁抹不平的部分。微软研究院的一份测量研究把同一模型放到端、边、云三档算力上测了推理时间。

图注：π0.5 与 DreamZero 在不同算力平台上的单次推理时间。同一模型在 A100 上约 63 毫秒，在机器人常配的 Orin AGX 上约 440 毫秒，差了近一个数量级；较重的模型在 Orin 上直接因为显存不足没有测出来。这说明把最重的模型塞进机器人身上的端侧路线在当下不成立，算力只能往边和云放。要注意这只说明推理时间差几倍，不能直接外推成失败率也差几倍。MSR-Offload

网络这一侧的数字更能说明问题。同一模型在网络理想、A100 基线下任务准确率是 80%；换成边缘设备并加上均值 10 毫秒、标准差 15 毫秒的单向抖动，准确率掉到 70%；把视频流压到 6.5 Mbps 的压缩档，只剩 60%。

图注：π0.5 在不同延迟与带宽条件下的任务准确率，基线是 A100 加理想网络与 100 Mbps 无损视频流。理想条件下 80%；加十几毫秒单向抖动掉到 70%；视频压缩到 12 Mbps 是 75%、压到 6.5 Mbps 只剩 60%；换回 A100 又能回到 80%。要读的是这组数字有前提，它指出的是延迟与压缩是必须算清的工程参数，并不等于「不该用云」。MSR-Offload

这组测量恰好把官方那句克制的「部分客户遇到网络连接问题」量化了。而端侧还有一笔电池账：机器人身上装大算力板的续航代价相当可观，测量研究在 Stretch 3 这类平台上报告了 160% 量级的续航差距。

把这些放在一起，云端推理的边界就分层了。延迟与抖动这一层，RTC 这类补丁能吸收，精细任务在云上仍能干成，这是这一章反复讲的「软边界」。断网、功能安全认证、需要确定性时延的控制回路属于另一层，推理时补丁与训练时补丁都够不着，只能靠架构上把关键回路留在本地或边缘来回答。这不是说云端路线走不通，而是说这条闭环的部署端有一道软件改不动的约束，任何关于迭代速度的承诺都要先扣掉它。

六、护城河从模型榜单转到单位成功任务成本、失败修复周转时间与部署可靠性

Pi API 争夺的不是单次推理的市场，而是机器人迭代闭环的控制层；团队做选型判断时该看的是三个可度量的指标，而不是演示里覆盖了多少种机器人。

第一个指标是单位成功任务的数据成本，也就是完成一个任务需要采多少条示范。通用先验影响这一项，跨本体预训练越强、冷启动所需的本体数据越少；补采效率也影响这一项，因为每轮迭代只采真正覆盖新失败的数据，重复采集的浪费就被省掉了。

第二个指标是失败到修复的周转时间，也就是从真机暴露一个失败，到修好的策略重新上线要多久。这是第二章那条闭环直接度量的东西，也是这套托管服务最该被追问的数字。

第三个指标是部署可靠性，也就是在延迟、抖动、断网这些现实条件下，系统还能不能用、能不能安全地用。它由第五章那些硬约束决定，而不是由模型榜单决定。

在这个口径下，托管 API 与自托管就不是孰优孰劣，而是一次取舍。选择自托管的团队要看的门槛是具体的：openpi 仓库以 Apache-2.0 开源了 π0、π0-FAST、π0.5 三个基座，它们共享同一批 10,000 小时以上的预训练权重；单卡条件下，推理需要 8 GB 以上显存，LoRA 微调需要 22.5 GB 以上，全量微调需要 70 GB 以上，仓库还内置了用 websocket 把动作从远程服务器流回机器人的推理链路openpi

图注：openpi 自托管栈的结构示意。上半部分是三个共享同一预训练底池的基座，下半部分对应推理、LoRA 微调、全量微调三档显存门槛与各自的适用场景，右侧是默认监听 8000 端口的远程推理服务。这张图是根据仓库 README 与远程推理文档中的结构化事实生成的示意图，仓库本身不带插图，所以它只用来对账各档门槛的对应关系，不当作外部权威来源。openpi

这条路径有两处必须如实说清的限制。三档显存门槛出自 JAX 分支，PyTorch 分支目前不支持 LoRA 微调，走 PyTorch 就只能做全量微调，门槛会更高。另外 PI 自己把这条自托管路线称作一次 experiment，明确表示这套代码是为自家机器人开发的，不期待每一次尝试都成功。

于是取舍的形状就清楚了。选择托管，换到的是前沿模型、托管微调与别人替你维护的迭代回路，付出的是把专有数据上传、持续付费，以及被调用接口绑定。选择自托管，换到的是数据不出门与对迭代节奏的完全掌控，付出的是显存门槛、工程自建，以及官方自己都保留余量的成功率。判断依据不在演示覆盖了多少种机器人，而在你自己的三个指标上哪一边的数字更好看。

回到主线：能通过接口复制的是权重和调用方式，复制不了的是每台机器人在自己场景里攒出来的失败分布。所以这条赛道的护城河不会停留在模型榜单上，而会落在单位成功任务的数据成本、失败到修复的周转时间和部署可靠性上。谁把这条迭代闭环做得最快、最稳，谁才可能占据跨本体智能的控制层。

参考文献

本专题引用的核心资料如下，建议深入学习时阅读原文：

1. Frontier Models for Every Robot: Announcing our API beta (Pi API beta 公告) — https://www.pi.website/blog/api-beta
2. π0.5: a Vision-Language-Action Model with Open-World Generalization — arXiv:2504.16054
3. π0: A Vision-Language-Action Flow Model for General Robot Control — arXiv:2410.24164
4. Real-Time Execution of Action Chunking Flow Policies — arXiv:2506.07339
5. Training-Time Action Conditioning for Efficient Real-Time Chunking — arXiv:2512.05964
6. A Reduction of Imitation Learning and Structured Prediction to No-Regret Online Learning (DAgger) — arXiv:1011.0686
7. Efficient Reductions for Imitation Learning (SMILe / Forward Training) — https://proceedings.mlr.press/v9/ross10a.html
8. Offload or Overload: A Platform Measurement Study of Mobile Robotic Manipulation Workloads — arXiv:2603.18284
9. Knowledge Insulating Vision-Language-Action Models (KI) — arXiv:2505.23705
10. Physical-Intelligence/openpi: π0 / π0-FAST / π0.5 开源仓库 — https://github.com/Physical-Intelligence/openpi