10. RTC 实时执行与系统交付
先修建议
- 已理解 action chunking 的基本执行方式（每次推理输出一段动作序列）
- 已了解 flow matching 的迭代去噪生成形式
- 具备基本实时系统概念（采样周期、时延、线程同步）
本节目标
- 建立 RTC 的问题定义与符号系统（
） - 理解同步/朴素异步为何在高延迟下失效
- 对齐论文原式理解 Guided Inference 与 soft masking
- 明确“论文结论”和“工程扩展建议”的边界
RTC 是什么，何时使用 RTC（Real-Time Chunking）关注的核心问题不是“把 VLA 推理加速到每个控制周期以内”，而是：当一次推理已经明显慢于控制周期时，系统还能不能持续输出动作，并且不在 chunk 接缝处突然跳变。
它是一种推理时方法，不改变原模型的训练配方，也不要求重新收集数据。RTC 的做法可以概括为两步：一边执行当前 chunk，一边生成下一段 chunk；生成下一段时，先保住已经承诺会执行的动作，再让模型补全后面的未来动作。
通常更适合 RTC 的场景：
- 使用 diffusion/flow 类 action chunking 策略
- 控制频率较高，且推理或网络延迟不可忽略
- 任务对轨迹连续性敏感（如高动态、强闭环操作）
与常见替代路线的关系：
- 与“只做模型加速”（量化、蒸馏、并行解码）相比，RTC 重点解决的是高延迟下的调度与接缝稳定性
- 与 Temporal Ensembling 等后处理相比，RTC 直接把“下一段生成”写成受约束的条件生成，通常更容易保持策略一致性
- 与重新训练一个更快的小模型相比，RTC 更像部署层补丁：基础策略仍然是原来的 diffusion/flow action chunking policy
从 action chunking 策略开始：
其中：
是 prediction horizon（每次预测的动作长度） 是控制时刻 的观测 - 每个 chunk 通常只执行前
步（execution horizon），且一般
可以把 action chunking 理解成“每次给未来写一小段动作计划”。这样做的收益是时序一致性，代价是反应性下降。
下图展示的是高延迟条件下的实际效果：即使额外注入 200ms 延迟，RTC 仍能让策略持续完成点火柴、点蜡烛这类需要快速闭环修正的动作。
1. 时间约束
1.1 时间变量
设控制器采样周期为
例如控制频率为 50Hz 时，
若希望系统始终有动作可发，必须满足“下一段 chunk 到达前，当前段尚未耗尽”，常用可行区间写法为：
这个条件只保证“不断供”，不保证“接得顺”。即使新 chunk 能及时到达，它也可能和旧 chunk 选择了完全不同的动作模式。
1.2 数值背景
论文给出的实时压力示例：
- 目标控制频率 50Hz，即
ms - 3B 规模策略仅 KV prefill 就可能在 46ms 量级
- 远程推理还会叠加网络时延（论文示例给出有线低时延条件约 13ms）
- 7B OpenVLA 的加速实现仍可见 321ms 级时延
因此“单次完整推理
1.3 失效模式
| 模式 | 表现 | 问题 |
|---|---|---|
| 同步阻塞推理 | 执行完一段 chunk 后停下来等下一次推理 | 轨迹出现 pause，机器人动力学被打断，部署分布偏离训练分布 |
| 朴素异步切换 | 后台提前推理，新 chunk 到达后立刻切过去 | 动作不断流，但接缝可能突然换方向，速度或加速度出现尖峰 |
第二类问题更隐蔽。系统看起来没有卡住，但新旧 chunk 可能来自动作分布中的不同模式：上一段计划从障碍物上方绕过去，下一段却从下方绕过去。两个计划单独看都合理，硬拼在一起就可能变成不可执行轨迹。
下图把这个矛盾拆成两个线程：控制线程要按固定周期持续发动作，推理线程要在后台生成下一段 chunk。真正困难的地方在于，两条线程并行之后，新旧 chunk 仍必须平滑衔接。
2. 接缝 Inpainting
chunk 接缝抖动本质是“两个独立采样轨迹在边界硬拼接”。前一时刻执行的是
下面这张图可以按时间顺序读：
- 黑色轨迹
是旧 chunk。后台推理开始时，控制线程还会继续执行旧 chunk 中的若干动作。 - 括号里的 inference delay
表示新 chunk 还没算完的这段时间。系统没有停下，而是继续沿黑色轨迹往前走。 - 推理结束后，朴素异步方法直接切到红色新 chunk
。如果新 chunk 选择了另一条绕障路径，就会从黑色轨迹末端突然跳到红色轨迹起点。 - 灰色上方轨迹表示旧 chunk 原本延伸下去的方向，红色下方轨迹表示新 chunk 选择的另一种合理模式。二者单独看都可以，但硬接在一起会产生很大的速度或加速度变化。
- 棕色 temporal ensemble 试图把两条轨迹平均起来。在单峰轨迹上这能降抖，但在“上绕 / 下绕”这种多模态场景里，均值轨迹可能直接穿过障碍物。
因此，这张图想说明的不是“新 chunk 错了”，而是：新旧 chunk 分别合理时，接缝仍可能不合理。RTC 的 inpainting 约束就是为了解决这个接缝问题，让新 chunk 的前段先贴住旧 chunk 已经承诺的剩余动作，再补全后面的未来动作。
常见补救方案及其局限：
| 方法 | 优点 | 主要失效点 |
|---|---|---|
| 朴素异步 | 不会在 chunk 边界停顿 | 不看上一段剩余动作，接缝容易跳变 |
| Temporal Ensembling（重叠平均） | 实现简单，可一定程度降抖 | 多模态下“均值动作”可能不可执行 |
| hard masking / 硬约束 | 能把一部分前缀拉向旧 chunk | 约束区域太短时，新 chunk 仍可能换策略 |
| BID（Bidirectional Decoding） | 可通过采样筛选提高连续性 | 需要额外采样批次，计算代价更高 |
RTC 的核心做法是把“下一 chunk 生成”重写为 inpainting 问题：已知并且必然会执行的动作相当于“图像里不能改的区域”，后续动作相当于“需要补出来的区域”。生成时既要接上旧 chunk，又要根据最新观测修正未来。
这也是 RTC 与普通异步执行的根本区别：普通异步只解决“推理和执行并行”，RTC 还解决“并行之后如何平滑接上”。
3. Guided Inference
3.1 Flow matching 基础更新
普通 flow matching 从纯噪声动作块开始，反复沿着模型预测的速度场往“干净动作 chunk”移动。它只关心当前观测下动作是否合理，并不知道上一段 chunk 正在执行到哪里。
对带噪动作 chunk
其中
3.2 PiGDM 修正
PiGDM 可以理解为给普通 flow matching 速度场加上一项“接缝引导”。普通速度场只关心当前观测下怎样生成一段合理动作；接缝引导额外要求新 chunk 的前段尽量接住旧 chunk 已经承诺的剩余动作。
先看两个对象：
是对齐参考，来自上一段 chunk 尚未执行完的剩余动作，并补齐到长度 。 是逐位置权重，用来控制接缝附近强约束、远离接缝处弱约束或不约束。
用论文记号，修正后的速度场写为：
这组式子可以这样读：
等于原始速度场 加上一项接缝修正。 是从当前带噪动作块外推得到的“最终动作块”估计。 表示当前估计与旧 chunk 参考之间还差多少。 把这种差距按时间位置重新加权，接缝附近影响最大。 - 最后的雅可比项把“最终动作块上的差距”传回当前带噪动作块，因此实现上就是一次 vector-Jacobian product（VJP）。
是引导强度上限，避免低步数去噪时修正过猛。
3.3 soft masking
如果只对前
论文的 soft masking 权重为：
物理意义：
：这些动作在推理完成前一定会被执行，必须强对齐 ：有重叠但不一定执行，允许“受约束地修正” ：无重叠，完全由新观测主导生成
直观上，越靠近当前时刻的旧动作越像“已经承诺的合同”，越往未来越像“可参考但允许修改的草稿”。论文附录还比较了不同衰减形式，指数衰减整体最好，线性衰减也接近。
这张图更适合用来观察跨 chunk 的策略连续性，而不只是比较曲线是否更平滑。soft masking 的目标是让新 chunk 在接缝附近沿着旧 chunk 的剩余意图继续走，再逐步交还给新观测主导。
3.4
论文附录消融显示，在低去噪步（如
4. 异步执行算法
4.1 线程角色
- 控制线程（消费者）：每
调用 GetAction消费下一动作 - 推理线程（生产者）：后台持续运行
InferenceLoop - 共享状态：
A_cur（当前 chunk）、t（已消费步数）、o_cur（最新观测）、Q（延迟缓冲） - 同步原语：互斥锁
与条件变量
算法可以理解成一个生产者-消费者系统。控制线程只做一件事：按固定周期取走下一步动作。推理线程在后台等到已经执行了足够多动作后，读取最新观测和上一段剩余动作，在锁外完成较慢的 Guided Inference，最后一次性替换当前 chunk。
4.2 核心伪代码
GetAction(o_next):
lock M
t = t + 1
o_cur = o_next
notify C
return A_cur[t - 1]
unlock M
InferenceLoop:
Q = Queue([d_init], maxlen=b)
while True:
lock M
wait C until t >= s_min
s = t
A_prev = A_cur[s:]
o = o_cur
d = max(Q) # 保守估计下一轮延迟
unlock M
A_new = GuidedInference(π, o, A_prev, d, s)
lock M
A_cur = A_new # 整体替换，避免读半更新状态
t = t - s # 让 t 重新对齐新 chunk
Q.push(d_obs) # 观测到的延迟步数（实现上可由 wall-clock 或消费步统计）
unlock M
GuidedInference(π, o, A_prev, d, s):
compute W with Eq.(weights)
right-pad A_prev to H
A^0 ~ N(0, I)
for τ in {0, 1/n, ..., (n-1)/n}:
f_hat(A') = A' + (1-τ) * v_π(A', o, τ)
e = (A_prev - f_hat(A^τ))^T * diag(W)
g = e * ∂f_hat/∂A' |_{A'=A^τ} # VJP
A^{τ+1/n} = A^τ + (1/n) * (v_π(A^τ,o,τ) + min(β,(1-τ)/(τ*r_τ^2))*g)
return A^1
4.3 算法实现要点
- 推理必须在锁外执行，避免控制线程被长时间前向阻塞。
- chunk 切换应为整体替换，不应原地部分写入。
用于控制最小执行长度；论文描述中实际执行长度会受延迟估计影响（常见实现取 ）。 是保守延迟估计，用过去一小段延迟的最大值抵抗网络和系统调度的尾部抖动。
5. 实验结论
论文实验主要回答三个问题：RTC 是否比已有执行策略更抗延迟；soft masking 是否真的有必要；真机上是否同时改善速度和完成质量。
5.1 配置对照
| 配置项 | 仿真 | 真机 |
|---|---|---|
| 任务集 | 12 个 Kinetix 高动态任务 | 6 个双臂任务（含移动任务） |
| 8 | 50 | |
| 5 | 5 | |
| 按环境设定 | 20ms（50Hz） | |
| 不需要（固定延迟实验） | 25 | |
| 5 | 5 | |
| 不需要 | 10 |
仿真基准不是常见的准静态桌面操作，而是 Kinetix 中的动态任务。环境使用 force-based control，任务包含投掷、接住、平衡等动作；论文还加入动作高斯噪声，使闭环修正变得重要。每个数据点用 2048 次 rollout 统计二值成功率，因此曲线主要反映延迟和执行策略对动态任务稳定性的影响。
5.2 真机延迟
- 同一模型下：vanilla 约 76ms，RTC 约 97ms（GPU 推理部分）
- 远程部署再叠加 LAN 开销（论文示例 10-20ms）
- 注入 +100ms / +200ms 延迟后，推理延迟步数会明显上升（论文报告约
）
真机评测使用
| 任务 | 子步骤数 / 时间上限 | 评估重点 |
|---|---|---|
| Light candle | 5 步 / 40s | 高精度、不可重试，能直接暴露接缝抖动 |
| Plug ethernet | 6 步 / 120s | 细长物体重定位与插入 |
| Make bed, mobile | 3 步 / 200s | 移动操作与大物体整理 |
| Shirt folding | 1 步 / 300s | 长时序布料操作 |
| Batch folding | 4 步 / 300s | 从杂乱衣物到展开、折叠、堆放 |
| Dishes in sink, mobile | 8 步 / 300s | 移动操作、多物体搬运 |
5.3 结果归纳
- 仿真基准中，RTC 对推理延迟更稳健，且相对 BID/TE 有优势。
- soft masking 相比 hard masking 在低延迟或较短执行步时更优。
- 真机评测中，RTC 的 throughput（完成比例 / episode 时长）在所有延迟设置下最好，且在 +100ms / +200ms 注入延迟下优势更明显。
- RTC 的收益不只是省掉同步等待时间。论文还比较了去掉 pause 后的 controller steps，RTC 仍然更早完成许多子步骤，说明它减少了接缝抖动带来的错误和重试。
- 高频动态任务中，TE 在高延迟下可能诱发强振荡并触发保护停机（按论文评估设置）。
观察仿真结果时，可以先看左侧的 execution horizon，再看右侧的 inference delay。RTC 的主要趋势是：执行步长变短时，它能利用更多闭环修正；推理延迟变大时，它的性能退化也更慢。
真实机器人曲线衡量的是 throughput，也就是完成进度与 episode 时长的联合结果。它不只是单次任务是否成功，还反映了接缝抖动、等待和重试对整体执行效率的影响。
动作轨迹需要把位置、速度和加速度放在一起看。若接缝处仍有明显跳变，速度或加速度曲线会先暴露出来；RTC 的优势正体现在这些尖峰被压低。
6. 部署边界
6.1 论文边界
- 适用范围：RTC 针对 diffusion/flow 类 action chunking policy。
- 计算代价：引导项需要反向计算，带来额外推理开销。
- 任务外推：真实实验虽覆盖多类双臂任务，但仍不能代表全部动态控制场景。论文特别提到，腿足 locomotion 这类更动态的场景只在仿真中出现，尚未在真机实验里验证。
6.2 工程扩展
以下建议在工程中较常见，但不属于论文直接结论，落地时需要结合具体平台验证：
- 线程调度：推理线程提高调度优先级，降低抖动。
- 内存与 I/O：减少运行期分页和突发 I/O 对延迟尾部的影响。
- GPU 资源隔离：避免日志/诊断任务与主推理争抢队列。
- 监控指标：动作年龄、延迟分位、freeze 占比三项长期跟踪。
可操作的监控表：
| 指标 | 含义 | 风险信号 |
|---|---|---|
| 动作年龄 | 当前 chunk 已消费步数 | 反复逼近 |
| 延迟分位（如 P99/P50） | 延迟尾部压力 | 比值持续升高常指向系统抖动 |
| freeze 占比 | 受硬约束区间比例 | 持续过高会压缩闭环修正空间 |
6.3 异常兜底
可作为部署侧安全网的策略：
- deadline miss handler：当新 chunk 未及时到达时，进入受控降级动作而非卡死。
- 数值异常恢复：出现 NaN/发散时保守回退并扩大后续 freeze。
- 频率降级策略：当
长期逼近 时触发降频/告警。
7. 总结与过渡
RTC 解决的是“慢推理模型如何保持实时执行正确性”，而不是“把模型本身直接加速到控制周期内”。
可以把 RTC 的贡献压缩为三点：
- 系统层：通过异步生产者-消费者结构保证动作不断流。
- 算法层：通过 Guided Inference + soft masking，把下一段生成变成带约束的 inpainting。
- 实验层：在高延迟注入下仍保持较强的吞吐与稳定性。
模型加速路线（量化、蒸馏、并行解码）与 RTC 调度路线是正交关系。真实部署通常需要两条线并行推进：一条降单次推理时延，另一条提升高延迟下的控制鲁棒性。