RTC 一类的实时策略技巧

旧计划committed prefix

→

并行推理condition on prefix + stale age

→

新计划compatible continuation

→

接管continuous handoff

1. 同步执行为什么会停顿

同步：observe → inference (robot waits) → execute chunk → observe ...
异步：execute old chunk ────────────────────────────→
          observe → infer next chunk → handoff

同步最简单，但 VLA 若需 200 ms，机器人每次重规划都停一下。异步消除等待，却产生两个 mismatch：

• action compatibility：新 chunk 开头可能与旧 chunk 尚未执行的尾部跳变。
• state staleness：模型用 inference 开始时的观测，输出在未来才接管，此时机器人状态已改变。

2. 几类 chunk 交接方法

方法	做法	主要取舍
Stop-and-go	等新 chunk 完成再动	一致但不连续，吞吐低
直接替换	新 chunk 到达立刻接管	反应快但可能跳变
Temporal ensemble	对多个重叠预测加权平均	平滑，可能平均掉多峰意图
RTC inpainting	把已承诺的动作前缀作为硬/软条件，补全后续	兼容旧轨迹，增加推理 guidance 成本
Training-time prefix	训练时随机模拟 delay 并条件化 committed prefix	推理便宜，需专门后训练且防 copy shortcut
Future-state conditioning	预测接管时 state 或给执行进度	修 stale observation，依赖状态/延迟估计

3. RTC 的核心直觉

当前 chunk 的一部分已经发给控制器，不能再更改；下一次 flow/diffusion generation 因此像 action inpainting：固定与 committed tail 对齐的前缀，只生成其后的自由部分。这样新 chunk 从机器人真实将要到达的轨迹继续，而不是从旧观测重新起步。

RTC 是 inference-time 方法，可用于已有 flow/diffusion VLA。它不等同于 RL 或 SFT；但为了去掉 guidance 开销，可以在后训练时直接教模型读取 action prefix。

4. Training-time RTC 学什么

训练时随机采样 simulated inference delay d
condition = observation at t + committed actions [a_t ... a_{t+d-1}]
target    = compatible continuation [a_{t+d} ...]

推理时把旧 chunk 未完成部分硬塞为 prefix，一次正常采样即可。必须随机化 delay、prefix 长度与 chunk phase，否则模型可能只学复制 prefix，不再看新视觉；对突然障碍或抓取失败的反事实测试能暴露这种 shortcut。

5. 同一家族的其他技巧

• Latency augmentation：训练随机 observation/action delay，让策略显式鲁棒。
• Chunk dropout / variable horizon：适应不同接管点与剩余 buffer。
• Consistency/shortcut distillation：把多步 flow/diffusion 蒸馏成 1–2 步。
• KV cache / static-prefix cache：多次动作去噪复用图像、文本和 state 的 K/V。
• Adaptive replanning：稳定阶段执行更长，接触/不确定阶段高频重规划。
• Residual correction head：小模型读取最新观测，实时修正较慢 base chunk。

6. 时间预算要端到端算

camera exposure + transport + preprocessing
+ policy queue + model inference + postprocess
+ network RPC + controller buffer + actuator response
= observation-to-actuation latency

RTC 只处理其中的策略生成与交接。若相机或 RPC 的 P95 jitter 很大，固定 delay training 仍会失败；部署应报告 latency 分布而非平均值，并把实际 delay/queue depth 喂给策略或 scheduler。

7. 评测不只看 success

• 成功率 vs 人工添加 latency/jitter 曲线。
• handoff 时 position/velocity/acceleration discontinuity。
• 最新观测到已执行动作的 age。
• 遇到新障碍、滑落、抓空时的 reaction time。
• 吞吐、GPU 利用率、buffer underflow 和 safety intervention。

8. 四个实时计算

自测

1. RTC 主要解决哪一种不一致？

新 chunk 与已 committed/正在执行的旧 chunk 之间的动作兼容性。

2. Training-time RTC 为什么可能形成 shortcut？

模型可能只复制给定动作前缀，弱化对最新视觉和状态的注意。

3. 为什么 temporal ensemble 可能伤害多峰策略？

两个各自有效但不同的动作模式被平均后，可能变成无效中间动作。