企业官网建设流程全解析

【VLA工程】（7）—— 边缘侧推理延迟与控制周期对齐

摘要：VLA（Vision-Language-Action，视觉–语言–动作）在边缘板上能输出动作，还不等于跟得上机械臂的控制周期。本篇把推理延迟（从观测采集到命令下发的耗时）与控制周期（记作长度T）写成可测量、可验收的一对指标，约定超限时的保持、丢帧与安全停策略，并给出日志字段与周报验收条目。贯穿示例仍是桌面摆放：把红色方块放到蓝色托盘。适合已能在受控窗口跑真机小清单、准备把策略接到固定控制频率的工程师。读完可以落地一套「预算、测量、超限处理」的延迟验收约定。

前文见 【VLA工程】（6）—— 真机受控试用的排期与值班记录 与 【VLA工程】（3）—— 运行时的动作限幅与安全停。第 6 篇保证真机数字有会话来源；第 3 篇保证越限与急停有独立结果码。本篇补充第三件事：边缘推理如果经常跑不完一个控制周期，限幅与会话再完整，桌面上仍会表现为抓空、抖停或莫名超时。

1. 延迟与控制周期先分别说明

控制周期（记作长度T，单位毫秒）指：控制循环希望每隔多久给出一次新的action_cmd。桌面臂常见起步档是每隔 20～50 ms 给出一次命令（约 50～20 Hz），具体以控制器与驱动约定为准。

端到端延迟（记作latency_ms）指：本轮观测采集完成时刻t_capture，到命令实际下发时刻t_cmd的差。它包含采集收尾、预处理、模型推理、限幅与通信发送，不只是「模型 forward 那一行」。

演示里常只报「推理 30 ms」。工程上要同时报：控制周期是多少、延迟的中位数与p95（第 95 百分位，表示大约 95% 的样本不超过该值）、超限比例。只有平均值、没有超限比例，无法判断是否会在关键抓取瞬间跟不上控制周期。

2. 周期内链路与预算

固定控制周期后，建议把一个控制周期拆成五段预算，总和小于T，留出抖动余量。

桌面摆放起步示例（T = 50 ms，数字仅供格式）：

五段相加 50 ms 等于把预算加满，实际抖动会立刻超限。更稳的写法是：名义预算加总到0.8 × T～0.9 × T，其余留给日志与偶发毛刺。

若推理段长期占用大半预算，优先动作是：先测量清楚 p95，再决定降低输入分辨率、换更小权重、或把控制周期从 50 ms 放宽到 100 ms。不要在未测量前同时改三处，否则无法归因。

2.1 控制周期选型的起步对照

同一会话里不要中途改T。若实验目的就是对比两种控制周期，应拆成两个窗口或两段会话，并分别写入timing_ver。

3. 观测时刻与动作生效要对齐

第 2 篇要求轨迹步对齐观测与动作；边缘侧还要对齐时钟语义：模型推理用的那一帧，对应桌面上的哪个瞬间。

约定：

• t_capture：本轮采用的那一帧（或一组同步帧）采集完成时刻
• t_infer_start/t_infer_end：进入与离开推理函数的时刻
• t_cmd：限幅后的命令写入驱动或队列的时刻

复盘抓空时，若只看「日志打印时间」，会把 Pythonprint延迟算进模型头上。应使用 monotonic 时钟（单调时钟，只保证间隔可靠）记录上述字段，并在会话 meta 里写清时钟源。多进程时，优先在同一进程内打点，跨机用硬件时间戳再另立标定。

延迟过大时，模型看到的是过时桌面：红块已被人手或上一轮命令挪动，当前轮仍按旧图抓，失败码常是抓空而不是安全停。这类问题应先检查延迟与丢帧，再检查权重。

多相机时，t_capture取本轮送进模型的那一组帧里最晚的一帧，并在 meta 里写清同步策略（软同步时间窗或硬件触发）。只用「主相机时间」却把副相机旧帧拼进去，延迟字段会偏乐观。

4. 超限时的三种处理

禁止的默认行为：推理线程卡住时仍按旧队列「补发」多轮动作，或静默把控制周期改慢却不改control_period_ms字段。控制周期变了必须提升配置版本，并在当周会话里注明。

桌面摆放示例：接近托盘的最后几厘米，建议把「连续超限」阈值收紧（例如连续 2 个控制周期超限即安全停），因为此时保持上一轮命令可能把夹爪顶进桌面；空中搬运段可以稍松。阈值写入limits_ver或并列的timing_ver，不要只留在聊天记录里。

5. 日志字段与入库

每个控制周期（或每条轨迹步）建议至少包含：

{"episode_id":"ep_20260924_003","step":42,"t_capture_ns":1727140001000,"t_infer_start_ns":1727140001012,"t_infer_end_ns":1727140001045,"t_cmd_ns":1727140001049,"latency_ms":49.0,"control_period_ms":50,"overrun":false,"hold_count":0,"drop_count":0,"policy_id":"vla_candidate_20260920","device_id":"orin_desk_01","timing_ver":"timing_desk_v1"}

会话层（第 6 篇）可以增加汇总：本会话latency_p50、latency_p95、overrun_rate、因延迟导致的safety_stop条数。没有这些字段，周报里的「边缘侧有点卡」无法复核。

device_id建议包含机型与关键软件栈版本缩写，例如orin_jp6_desk01。换 JetPack 或驱动后应视作新设备档，旧延迟基线不要横向对比。否则「优化有效」可能只是换了驱动。

6. 测量顺序与常见归因错误

建议测量顺序：

1. 空载基线：预处理加上常数输出的占位动作，确认采集与下发基线
2. 接入限幅，仍不加载真模型，确认限幅段预算
3. 接入真权重，固定policy_id与输入分辨率，跑不少于约定步数（例如连续 2 分钟或一整份小清单）
4. 只改一个因素（分辨率或权重或T），再跑同等步数对比

常见归因错误：

日志建议异步落盘或按回合刷盘；周期内路径只保留环形缓冲打点。第 2 篇的入库完整性和本篇的周期预算要同时成立：完整可以在回合结束补齐，不能每个控制周期阻塞推理。

冷启动单独测量：进程刚拉起的前 N 个控制周期（例如 30 个）往往偏慢，报告里可标warmup=true并默认不进 p95 分母，或单独一行「含冷启动 / 不含冷启动」。把冷启动混进稳态 p95，会误导控制周期选型。

7. 与限幅、会话、评测的衔接

换权重后成功比例上升、但 p95 延迟明显变差，受控试用结论应写「任务略优、周期变差」，默认权重是否替换由项目策略决定，但两行数字都要进入周报。只报成功、不报延迟，边缘部署会在现场才暴露问题。

量化示例：候选相对基线成功比例提高 3 个百分点，但 p95 从 42 ms 升到 58 ms（T=50），超限比例从 0.5% 升到 6%。周报应写「任务略优、周期未达标」，默认策略下不替换权重，直到延迟回到约定，或项目显式接受更长控制周期并提升timing_ver。

8. 脚本示意：汇总一回合延迟

下面片段从逐步 JSONL 计算延迟中位数、p95 与超限比例。真实系统把时间戳改成你们的字段名即可。

#!/usr/bin/env python3"""Summarize per-step latency for one episode JSONL."""importjsonimportstatisticsfrompathlibimportPathdefpercentile(sorted_vals,p):ifnotsorted_vals:returnNonek=(len(sorted_vals)-1)*p/100.0f=int(k)c=min(f+1,len(sorted_vals)-1)iff==c:returnsorted_vals[f]returnsorted_vals[f]+(sorted_vals[c]-sorted_vals[f])*(k-f)defload_steps(path):rows=[]forlineinPath(path).read_text(encoding="utf-8").splitlines():ifline.strip():rows.append(json.loads(line))returnrowsdefsummarize(steps,period_ms):lats=[]overruns=0forsinsteps:if"latency_ms"ins:lat=float(s["latency_ms"])else:lat=(s["t_cmd_ns"]-s["t_capture_ns"])/1e6lats.append(lat)iflat>period_msors.get("overrun"):overruns+=1lats_sorted=sorted(lats)return{"n":len(lats),"control_period_ms":period_ms,"latency_p50_ms":statistics.median(lats)iflatselseNone,"latency_p95_ms":percentile(lats_sorted,95),"overrun_rate":overruns/len(lats)iflatselseNone,}if__name__=="__main__":report=summarize(load_steps("episode_steps.jsonl"),period_ms=50)print(json.dumps(report,ensure_ascii=False,indent=2))

验收时建议同时看：latency_p95_ms < T（或小于约定上限），以及overrun_rate低于约定比例（例如 1%）。只满足平均值不够。

桌面摆放的起步阈值示例（写入timing_ver，可按项目修改）：p95 不超过0.95 × T，超限比例不超过 1%，连续超限不超过 3 个控制周期。放置段可另设更严的连续超限上限。改阈值必须提升timing_ver，并在当周周报注明。

9. 周报中的延迟验收条目

真机周报在第 6 篇三项记录之外，建议固定增加下列四项（可以并成一小表）：

示例段落：

本周边缘侧：T=50ms，policy 候选，p50=31 ms、p95=47 ms，超限比例 0.8%。无因延迟导致的安全停。默认权重：保持基线；延迟达标，本周不改timing_ver。

有这四项记录，审批者能把「模型好不好」和「跟不跟得上控制周期」分开讨论。

10. 适用边界

本篇适合：

• 已有受控窗口与会话日志，准备固定控制频率
• 边缘板（如 Orin 类）上跑 VLA，需要延迟验收约定
• 抓空与超时排查时怀疑「看的是旧图」

暂不适合：

• 尚未有action_cmd与安全停（先回到第 3 篇）
• 纯云端离线批推理、不接实时臂
• 硬实时操作系统认证级材料（本篇只给工程测量与值班约定）

11. 小结

1. 控制周期T与延迟latency_ms分列，同时看 p95 与超限比例
2. 周期内五段预算不要加满，推理段先测量再改模型或分辨率
3. 用t_capture/t_cmd对齐，不要用打印时间冒充
4. 超限策略明确写入配置：保持、丢帧或安全停，并记录次数
5. 周报固定写出延迟验收条目：周期版本、p50/p95、超限、延迟相关安全停

若只能先做一件事：在现有控制循环里为每一个控制周期记录t_capture与t_cmd，跑满一个受控窗口，算出 p50、p95 与超限比例。没有这两个时间戳，任何「边缘侧优化」都难以验收。

系列导航：

• 上一篇：【VLA工程】（6）—— 真机受控试用的排期与值班记录
• 下一篇：【VLA工程】（8）—— 观测预处理与训练部署一致性