机器人接入 GPT-6 Astra 后，延迟为什么变成产品指标
先给答案：因为延迟不是「慢一点」，是这个循环合不上。一次 30 秒的动作，要 250 次模型调用、每次平均 39.86 秒，推理期间物理引擎还得暂停——250 × 39.86 ≈ 9,965 秒，约 2 小时 46 分，等于 332 倍实时。
只要端到端延迟超过动作周期，产品就只剩三选一：实时闭环、分段执行加暂停、离线规划。成功率再高，也改不了这道选择题。
能压延迟的是调用次数，不是模型大小。同一个规划器，只把调用方式改成批量检查、重试，调用次数少 49%、输入 token 少 65%，成功率还从 63.1% 涨到 71.7%。
把「延迟」拆成三个能算的量
工程上谈延迟，谈的是一个闭环的响应时间。模型接进机器人以后，这个闭环变成：模型想一步 → 动作执行 → 观察回来 → 模型再想一步。所以端到端延迟不是一个数，是三项相乘相加的结果。
| 量 | 论文给的值 | 谁决定 | 能压多少 |
|---|---|---|---|
| 调用次数 | 一次 30 秒运动跑，250 次模型调用 | 外层框架怎么组织调用 | 改成批量检查与重试后，调用次数少 49%（规划器没换） |
| 单次推理时长 | 均值 39.86 秒 | 输出长度、推理档位、工具往返次数 | 论文只给了均值，没拆构成，这一项没有可引用的分解 |
| 动作周期 | 30 秒（运动跑）；接触类任务是毫秒级 | 任务本身，跟模型无关 | 压不了，只能被适配 |
三项里，动作周期是物理给的硬约束，单次推理时长受输出和档位影响，只有调用次数是工程上真正能大幅撬动的那一项。这也解释了为什么「换个更小的模型」常常不管用：模型小一点，单次时长降一些，但调用两百多次这件事没变，总时间还是压在周期上面。
比「慢」更麻烦的是「停」
论文里有一句容易被跳过的话：推理期间，物理引擎是暂停的。也就是说，这 2 小时 46 分不是机器人在慢慢动，而是机器人根本没在动，仿真在等模型算完。
真机上没人能按这个键。物理世界不会因为模型在思考就暂停重力、暂停传送带、暂停对面走过来的人。所以延迟超标时，产品上的表现不是「动作卡顿」，而是三种更难处理的症状：
- 要么等。把动作切成小段，每段算完再执行，等于把连续任务做成批处理。
- 要么抢。模型还没算完，外挂控制器先按上一版计划执行，等新计划回来再改——这时候模型已经不是控制器，只是顾问。
- 要么兜。失败时人接手。这一条直接决定产品的运营成本，不是技术成本。
这就是「延迟变成产品指标」的意思：它不再是一个可以写在规格表里、允许被平均掉的工程参数，而是直接决定这个产品长什么样、谁来兜底、能不能无人值守。
延迟一旦超标，产品只剩三种形态
| 形态 | 成立条件 | Astra 在里面干什么 | 代价 |
|---|---|---|---|
| 实时闭环 | 端到端延迟远小于动作周期 | 只出高层目标与改目标，动作交给外挂控制器 | 必须另配控制器和安全层，模型只占一环 |
| 分段执行 + 暂停 | 延迟远大于动作周期 | 每段算完再动，仿真里就是论文那种跑法 | 时间放大到几百倍，环境一变就得重算 |
| 离线规划 + 人审 | 计划可以事先算完 | 先把整条计划算出来，执行时不再调模型 | 计划一旦作废，整段重来 |
这三种形态不是三档性能，是三种产品。选错形态，成功率再漂亮也没用：48%、50%、38.7% 这三个数全是「混合控制」的成绩，也就是模型只出高层、动作交给 π0.5 或预训练全身控制器——它本来就没在闭环里当控制器。这一层结构在 高层规划与低层控制那篇 里拆得更细，包括六类任务的分差和「规划强、控制弱」的原始说法。
一条能照做的降档规则
规则：先算延迟预算，再决定模型待在哪一层。
延迟预算 = 动作周期 × 允许暂停次数 × 单次可接受等待。
举例：一个动作周期 2 秒的抓取任务，最多允许暂停 1 次，人最多愿意等 3 秒，预算就是 6 秒。任何超过 6 秒的方案，都不属于「实时闭环」，只能往下面两档走。
三个触发条件，按顺序判：
- 单次推理时长 > 动作周期：别做闭环，直接按离线规划做，模型只负责出计划。
- 调用次数 × 单次时长 > 延迟预算：先改调用框架——本地循环批量检查、只回传需要的观察、失败在本地重试。同一个规划器，这条路能把调用次数砍掉近一半。
- 改完框架仍然超预算：把控制权交给外挂控制器，Astra 只保留两件事——出计划、失败后改目标。
这条规则是我按论文两个公开数字推出来的工程判断，不是论文结论。论文只报了 250 次调用、39.86 秒均值和「推理期间物理引擎暂停」，没有给出延迟预算这种算法。
延迟和钱是同一个源头
同一篇论文还报了 token：50 个 RoboDojo 实例、每种条件各测一遍，策略辅助的控制烧掉 6.248 亿 token，直接控制烧掉 11.32 亿。摊到单个实例，直接控制约 2,264 万 token，按官方 $10/百万输入 token 粗算，一次试验的账面成本约 226 美元——这还是把所有 token 都按输入价算的下限。
延迟和成本不是两个问题：它们都来自调用次数。所以「压延迟」和「省钱」在大多数情况下是同一个动作——减少调用、减少冗余观察，而不是换模型。把调用量折成账单的算法、三个算例和一张记账表在 一次任务多少钱那篇 里，按 token 记，不按感觉记。
边界
332 倍是换算，不是论文结论。论文给的是 250 次调用和 39.86 秒均值，以及「推理期间物理引擎暂停」；倍率是我按定义相乘得来的，任何人拿这两个数都能算出来。
39.86 秒是均值。论文没有按任务类型、输出长度或推理档位拆分这一项，所以「哪种调用最慢」在这篇里给不出可引用的答案。
48%、50%、38.7%、92%、82% 都是特定评测集上的成绩（RoboDojo 子集、RoboCasa365、RxR、HM3D），不是产品现场指标。
这一页没有一个我自己测出来的数字。凡是数字，要么来自论文原文，要么是标注过的换算。
两个最常被问的问题
问：为什么延迟会变成产品指标，而不是一个工程参数？
答：因为一旦端到端延迟超过动作周期，产品形态就被迫改变——实时闭环做不了，只能改成「分段执行加暂停」或者「离线规划加人审」。这三种形态对应三种产品、三种兜底方式，不是调参能解决的。工程参数可以平均掉，产品形态不能。
问：换个更小的模型能把延迟压下来吗？
答：这条线上收益有限。单次推理时长会降一些，但一次任务两百多次调用这件事没变。论文里真正把数字拉起来的是改调用方式：规划器不变，调用次数少 49%、输入 token 少 65%，模拟成功率从 63.1% 涨到 71.7%。先改框架，再谈换模型。
来源
具身策略系统评测（48%/50%/38.7%/92%/82%、250 次调用与 39.86 秒、6.248 亿与 11.32 亿 token、推理期间物理引擎暂停）· 少 token 高成功率（63.1%→71.7%、调用 -49%、token -65%、RoboDojo 51.6% / Score 58.2）· RoboDojo（语义任务与精密操作的分差）· 具身智能落地报告（成本与执行时间缺口）· OpenAI 价格表（$10/百万输入 token）。核对日期：2026-10-22。