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

【VLA工程】7—— 边缘侧推理延迟与控制周期对齐文章目录【VLA工程】7—— 边缘侧推理延迟与控制周期对齐1. 延迟与控制周期先分别说明2. 周期内链路与预算2.1 控制周期选型的起步对照3. 观测时刻与动作生效要对齐4. 超限时的三种处理5. 日志字段与入库6. 测量顺序与常见归因错误7. 与限幅、会话、评测的衔接8. 脚本示意汇总一回合延迟9. 周报中的延迟验收条目10. 适用边界11. 小结摘要VLAVision-Language-Action视觉–语言–动作在边缘板上能输出动作还不等于跟得上机械臂的控制周期。本篇把推理延迟从观测采集到命令下发的耗时与控制周期记作长度T写成可测量、可验收的一对指标约定超限时的保持、丢帧与安全停策略并给出日志字段与周报验收条目。贯穿示例仍是桌面摆放把红色方块放到蓝色托盘。适合已能在受控窗口跑真机小清单、准备把策略接到固定控制频率的工程师。读完可以落地一套「预算、测量、超限处理」的延迟验收约定。前文见 【VLA工程】6—— 真机受控试用的排期与值班记录 与 【VLA工程】3—— 运行时的动作限幅与安全停。第 6 篇保证真机数字有会话来源第 3 篇保证越限与急停有独立结果码。本篇补充第三件事边缘推理如果经常跑不完一个控制周期限幅与会话再完整桌面上仍会表现为抓空、抖停或莫名超时。1. 延迟与控制周期先分别说明控制周期记作长度T单位毫秒指控制循环希望每隔多久给出一次新的action_cmd。桌面臂常见起步档是每隔 2050 ms 给出一次命令约 5020 Hz具体以控制器与驱动约定为准。端到端延迟记作latency_ms指本轮观测采集完成时刻t_capture到命令实际下发时刻t_cmd的差。它包含采集收尾、预处理、模型推理、限幅与通信发送不只是「模型 forward 那一行」。概念回答的问题典型字段控制周期T希望多快给出一次命令control_period_ms延迟latency_ms本轮实际花了多久t_cmd - t_capture超限延迟是否大于Toverruntrue演示里常只报「推理 30 ms」。工程上要同时报控制周期是多少、延迟的中位数与p95第 95 百分位表示大约 95% 的样本不超过该值、超限比例。只有平均值、没有超限比例无法判断是否会在关键抓取瞬间跟不上控制周期。2. 周期内链路与预算固定控制周期后建议把一个控制周期拆成五段预算总和小于T留出抖动余量。桌面摆放起步示例T 50 ms数字仅供格式段预算ms常见膨胀点采集收尾8相机驱动排队、拷贝到 CPU预处理6缩放、归一化、多相机拼接推理28权重太大、精度过高、冷启动限幅4逆解或碰撞检查过重下发4总线忙、用户态切换五段相加 50 ms 等于把预算加满实际抖动会立刻超限。更稳的写法是名义预算加总到0.8 × T0.9 × T其余留给日志与偶发毛刺。若推理段长期占用大半预算优先动作是先测量清楚 p95再决定降低输入分辨率、换更小权重、或把控制周期从 50 ms 放宽到 100 ms。不要在未测量前同时改三处否则无法归因。2.1 控制周期选型的起步对照任务阶段建议起步T说明空中搬运50100 ms位置变化相对慢可以略放宽接近与抓取2050 ms接触前更怕过时观测放置微调2050 ms与抓取同档便于统一配置同一会话里不要中途改T。若实验目的就是对比两种控制周期应拆成两个窗口或两段会话并分别写入timing_ver。3. 观测时刻与动作生效要对齐第 2 篇要求轨迹步对齐观测与动作边缘侧还要对齐时钟语义模型推理用的那一帧对应桌面上的哪个瞬间。约定t_capture本轮采用的那一帧或一组同步帧采集完成时刻t_infer_start/t_infer_end进入与离开推理函数的时刻t_cmd限幅后的命令写入驱动或队列的时刻复盘抓空时若只看「日志打印时间」会把 Pythonprint延迟算进模型头上。应使用 monotonic 时钟单调时钟只保证间隔可靠记录上述字段并在会话 meta 里写清时钟源。多进程时优先在同一进程内打点跨机用硬件时间戳再另立标定。延迟过大时模型看到的是过时桌面红块已被人手或上一轮命令挪动当前轮仍按旧图抓失败码常是抓空而不是安全停。这类问题应先检查延迟与丢帧再检查权重。多相机时t_capture取本轮送进模型的那一组帧里最晚的一帧并在 meta 里写清同步策略软同步时间窗或硬件触发。只用「主相机时间」却把副相机旧帧拼进去延迟字段会偏乐观。4. 超限时的三种处理策略适用必须同时做的事保持上一轮action_cmd偶发短超限、任务变化慢记录hold_count连续保持超过阈值则升级处理丢弃本帧观测等下一帧相机频率高于推理能力记录drop_count禁止无限堆积队列转为safety_stop连续超限、接近托盘的关键段、通信已乱写入safety_reasonlatency_overrun禁止的默认行为推理线程卡住时仍按旧队列「补发」多轮动作或静默把控制周期改慢却不改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. 测量顺序与常见归因错误建议测量顺序空载基线预处理加上常数输出的占位动作确认采集与下发基线接入限幅仍不加载真模型确认限幅段预算接入真权重固定policy_id与输入分辨率跑不少于约定步数例如连续 2 分钟或一整份小清单只改一个因素分辨率或权重或T再跑同等步数对比常见归因错误现象优先检查不要优先做平均延迟低、偶发抓空p95 与超限是否集中在放置段立刻换更大模型仿真流畅、真机卡顿真机device_id、精度、是否与训练使用同一预处理只调仿真种子一开日志就超限同步写盘是否落在周期内关键路径上认定模型不行多相机拼接后延迟暴涨是否必须每个控制周期使用全分辨率先加 GPU日志建议异步落盘或按回合刷盘周期内路径只保留环形缓冲打点。第 2 篇的入库完整性和本篇的周期预算要同时成立完整可以在回合结束补齐不能每个控制周期阻塞推理。冷启动单独测量进程刚拉起的前 N 个控制周期例如 30 个往往偏慢报告里可标warmuptrue并默认不进 p95 分母或单独一行「含冷启动 / 不含冷启动」。把冷启动混进稳态 p95会误导控制周期选型。7. 与限幅、会话、评测的衔接层级来源本篇补充什么限幅与安全停第 3 篇延迟超限可以转为独立safety_reason版本对比第 4 篇对比表可以并列延迟 p95延迟变差不算任务成功真机会话第 6 篇会话汇总写入延迟统计本篇—T、预算、超限策略、timing_ver换权重后成功比例上升、但 p95 延迟明显变差受控试用结论应写「任务略优、周期变差」默认权重是否替换由项目策略决定但两行数字都要进入周报。只报成功、不报延迟边缘部署会在现场才暴露问题。量化示例候选相对基线成功比例提高 3 个百分点但 p95 从 42 ms 升到 58 msT50超限比例从 0.5% 升到 6%。周报应写「任务略优、周期未达标」默认策略下不替换权重直到延迟回到约定或项目显式接受更长控制周期并提升timing_ver。8. 脚本示意汇总一回合延迟下面片段从逐步 JSONL 计算延迟中位数、p95 与超限比例。真实系统把时间戳改成你们的字段名即可。#!/usr/bin/env python3Summarize per-step latency for one episode JSONL.importjsonimportstatisticsfrompathlibimportPathdefpercentile(sorted_vals,p):ifnotsorted_vals:returnNonek(len(sorted_vals)-1)*p/100.0fint(k)cmin(f1,len(sorted_vals)-1)iffc:returnsorted_vals[f]returnsorted_vals[f](sorted_vals[c]-sorted_vals[f])*(k-f)defload_steps(path):rows[]forlineinPath(path).read_text(encodingutf-8).splitlines():ifline.strip():rows.append(json.loads(line))returnrowsdefsummarize(steps,period_ms):lats[]overruns0forsinsteps:iflatency_msins:latfloat(s[latency_ms])else:lat(s[t_cmd_ns]-s[t_capture_ns])/1e6lats.append(lat)iflatperiod_msors.get(overrun):overruns1lats_sortedsorted(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__:reportsummarize(load_steps(episode_steps.jsonl),period_ms50)print(json.dumps(report,ensure_asciiFalse,indent2))验收时建议同时看latency_p95_ms T或小于约定上限以及overrun_rate低于约定比例例如 1%。只满足平均值不够。桌面摆放的起步阈值示例写入timing_ver可按项目修改p95 不超过0.95 × T超限比例不超过 1%连续超限不超过 3 个控制周期。放置段可另设更严的连续超限上限。改阈值必须提升timing_ver并在当周周报注明。9. 周报中的延迟验收条目真机周报在第 6 篇三项记录之外建议固定增加下列四项可以并成一小表条目示例周期与版本T50mstiming_vertiming_desk_v1device_idorin_desk_01延迟分布p5031 msp9547 ms本周 3 个已收尾会话合计超限情况超限比例 0.8%最长连续超限 2 个控制周期安全后果因latency_overrun触发的safety_stop1 条示例段落本周边缘侧T50mspolicy 候选p5031 ms、p9547 ms超限比例 0.8%。无因延迟导致的安全停。默认权重保持基线延迟达标本周不改timing_ver。有这四项记录审批者能把「模型好不好」和「跟不跟得上控制周期」分开讨论。10. 适用边界本篇适合已有受控窗口与会话日志准备固定控制频率边缘板如 Orin 类上跑 VLA需要延迟验收约定抓空与超时排查时怀疑「看的是旧图」暂不适合尚未有action_cmd与安全停先回到第 3 篇纯云端离线批推理、不接实时臂硬实时操作系统认证级材料本篇只给工程测量与值班约定11. 小结控制周期T与延迟latency_ms分列同时看 p95 与超限比例周期内五段预算不要加满推理段先测量再改模型或分辨率用t_capture/t_cmd对齐不要用打印时间冒充超限策略明确写入配置保持、丢帧或安全停并记录次数周报固定写出延迟验收条目周期版本、p50/p95、超限、延迟相关安全停若只能先做一件事在现有控制循环里为每一个控制周期记录t_capture与t_cmd跑满一个受控窗口算出 p50、p95 与超限比例。没有这两个时间戳任何「边缘侧优化」都难以验收。系列导航上一篇【VLA工程】6—— 真机受控试用的排期与值班记录下一篇【VLA工程】8—— 观测预处理与训练部署一致性