你有没有想过，一个机器人从"看到"桌上的衣服到"伸手去抓"之间，到底隔了多久？
答案可能会让你吃惊。不是零点几秒的感觉上的瞬间，而是实实在在的一百多毫秒的技术链条，这中间塞满了摄像头曝光、数据传输、神经网络计算、再到机械臂真正开始运动的层层延迟。这篇来自Magiclab机器人团队的论文,把这条链条一节一节地拆开来称重,然后发现了一个有意思的事实:大家平时拼命优化的"模型推理速度",其实只是这条延迟链条里的一环,而且还不是唯一的大头。
**VLA**
视觉-语言-动作模型(Vision-Language-Action),一种能同时理解图像、听懂语言指令、并直接输出机器人动作的AI模型。
这类模型现在是机器人智能化的主流路线,但它们有个先天的别扭:模型"思考"一次要花几十毫秒甚至更久,可机械臂的电机控制却要求每隔几毫秒就要收到一条新指令,不然就会卡顿或者抖动。这就好比你让一个人一边慢悠悠地想下一步棋,一边要求他的手指每秒钟都得精确地移动若干次,想和动完全不是一个节奏。
这篇论文做了两件事。第一件是把"模型为什么慢"这件事彻底讲清楚,顺带发明了一种新的去噪方法,把生成动作所需的计算步骤从10步砍到2步。第二件是搭了一整套分布式的机器人控制系统,把六种业内现有的"实时执行"方案拉到同一个擂台上,用真实的叠衣服任务见了真章。
延迟去哪儿了:一场摄像头和机械臂的联合破案
先说一个容易被忽略的事实:哪怕你把AI模型优化到瞬间出结果,机器人也不会立刻动起来。
研究团队做了一套挺讲究的标定装置。机械臂带着一个显示屏做周期性的小幅摆动,屏幕上显示着时间码和相位条,一台RealSense相机同时拍摄这个时间码和机械臂末端贴的ArUco标记点。
**ArUco标记**
一种黑白方块组成的视觉标签,类似简化版二维码,常用于让摄像头精确识别物体的位置和姿态。
通过比较相机记录下的时间和实际物理动作发生的时间,团队把整条感知-决策-执行链路的延迟挖了个底朝天。结果列在一张表里:主摄像头的时间戳偏移是17.7毫秒,图像从采集到被主机收到又要32.8毫秒,机器人自身状态反馈回来要26.4毫秒,而指令发出后机械臂真正开始动,还要再等15.3毫秒。
这几个数字加起来,还没算上模型推理本身的时间,就已经逼近一百毫秒。
如果只盯着模型推理速度优化,会发生什么?答案是,哪怕你把模型做到零延迟,这条链路里剩下的九十多毫秒依然原封不动地躺在那里。这就像是你拼命把泡面的烹煮时间从3分钟压缩到1分钟,却忘了从超市买泡面回家的路上要堵车20分钟,优化泡面的意义被路上的堵车吃掉了大半。这个发现直接决定了论文接下来的思路:既要修模型,也要修整条链路,两件事缺一不可。
Flow Matching的"偷懒"哲学:不是所有去噪步骤都一样重要
现在说说模型内部到底在忙活什么。
**Flow Matching**
一种生成式AI的采样方法,通过多次迭代把一团随机噪声逐步"引导"成目标结果(这里是机器人动作),类似扩散模型的近亲。
π0.5这类VLA模型生成一组动作,通常需要10次这样的迭代计算,每一次都要完整跑一遍神经网络。研究团队测出来,标准的10步流程平均要花61.557毫秒。
关键问题来了(这里用大白话讲):这10步里,是不是每一步都同样重要?
团队做了个挺巧妙的实验。他们固定模型参数、固定初始的随机噪声,然后把10步迭代里每一步产生的"速度场"(可以理解成每一步该往哪个方向、以多大幅度调整动作)记录下来,画出两条曲线:一条看速度场的整体强度变化,一条看相邻两步之间方向转了多大的角。
结果非常清晰。在前面大部分步骤里,这两条曲线都相当平稳,说明模型在这个阶段基本是沿着差不多的方向匀速前进。但是到了最后一两步,情况突变:速度场的强度明显跳动,方向转角也陡然增大。
这个发现意味着什么?意味着前面的步骤其实是在"打草稿",大致框定一个动作方向就够了,真正需要精雕细琢的,是最后临门一脚的修正。
这就像你写一篇文章,前面几稿都是在搭框架、定主题,用不着逐字斟酌;但是定稿前的最后一遍校对,每一个字都得抠。如果你把"逐字斟酌"的精力平均分摊到每一稿里,结果就是前面几稿浪费了大量不必要的精力,而最后一稿反而没有特别照顾到。
基于这个发现,团队设计了一套两阶段的非均匀去噪方案。第一阶段用一大步跨过大部分的"草稿"区间,第二阶段专门针对最后那一小段做精细修正,这个精细修正环节借用了一种叫做SnapFlow的技术。
**SnapFlow**
一种让模型学会直接预测"跨越一大段时间的平均速度"而不是一步步算的技术,核心思路源自更早的Shortcut Models研究,这里被限定只用在最后的精修阶段。
训练的时候,模型会随机选择标准的逐步训练方式,或者这套两阶段训练方式,各占一半概率,这样模型既保留了对单步速度的理解,又学会了跨段预测的能力。推理部署的时候,只需要调用两次网络计算,整个流程从10步压缩到2步,平均耗时从61.557毫秒降到21.956毫秒,快了2.804倍,时间砍掉了64.33%。
有意思的是,这种压缩并没有让动作质量崩掉。团队在离线数据上比对了关节误差和机械臂末端的位置误差,两种方法的误差数值基本在同一个量级,谁也没有碾压式地压倒谁。这说明"抓大放小"这个策略站得住脚:省下来的计算资源,没有换来肉眼可见的精度损失。
异步执行的三种姿势:停顿、断层还是内部矛盾
模型快了,接下来要解决的是另一个问题:机器人在等新动作的时候,到底该怎么办。
最直接的办法是同步执行,机器人老老实实等模型算完一批新动作再继续走,但这样会造成明显的卡顿,机械臂走走停停,一点都不优雅。
于是业界普遍转向异步执行:机器人一边执行手头已有的这批动作,后台一边悄悄地让模型去算下一批。这解决了卡顿的问题,却引出了两个新麻烦。
第一个麻烦叫做"块间断层"。新算出来的那批动作,是基于模型开始计算那一刻的观测生成的,可是等这批动作真正要接上去执行时,机器人的实际状态早就往前走了一段,新旧两批动作衔接处很可能对不上,出现一个跳变。
第二个麻烦叫做"块内不一致"。模型算新动作那段时间里,机械臂还在执行旧动作,这意味着当前正在执行的动作,其实是基于一个已经过时的观测生成的,跟当下真实的环境状态已经脱节。
论文里统一测试了六种业内用来解决这两个麻烦的方案,分别叫做朴素异步执行、时序平滑、推理时RTC、训练时RTC、Legato和VLASH。
**RTC**
Real-Time Chunking的缩写,核心思路是把正在执行、还没来得及改变的那部分动作当成"既定事实"固定住,只让模型重新生成这部分之后的内容,减少新旧动作打架的概率。
这几种方法分别从不同的系统层面下手。时序平滑是在动作缓冲区里做文章,把旧批次的尾巴和新批次的开头做一个加权融合,让衔接处看起来不那么突兀。推理时RTC和训练时RTC则是从生成约束和训练方式上入手,一个是推理阶段锁定已执行的前缀,一个是训练阶段就模拟各种延迟情况,让模型自己学会怎么顺畅地续写动作。Legato走得更远,直接在训练目标里就让模型学会"自然地续写"这件事,而不是靠外部规则强行缝合。VLASH换了个角度,它去预测机械臂在新动作真正生效那一刻会处于什么状态,然后让模型基于这个"未来状态"去生成,而不是基于当下已经过时的状态。
真刀真枪的叠衣服考验
光说方法论不够,团队搭了一个真实的双臂机器人平台,用两只Agilex Piper机械臂,配上一个俯视摄像头和两个手腕摄像头,专门做一件事:把皱巴巴的T恤抓起来、铺平、放好,再连续叠三折。
这个任务选得挺有心思。它足够长程(从抓取到完成要经过六个步骤),又涉及软体物体(衣服形变复杂,不像抓一个刚性的盒子那么好预测),对实时性的要求非常真实。团队用了三件不同大小、不同颜色的T恤,每种方法在每件衣服上各跑十次,一共180次真实的物理实验。
结果显示出明显的分化。Legato拿到了全场最高分,96.7%的成功率,平均每次73.56秒完成,换算成"每小时能成功叠多少件"的吞吐量是47.31件。VLASH紧随其后,93.3%的成功率,43.22件每小时。
在不需要额外训练的方法里,时序平滑表现最好,76.7%的成功率,29.38件每小时。而训练时RTC、朴素异步执行、推理时RTC这三种方法的成功率都没超过63.3%,平均完成时间都超过了120秒。
这里有个挺反直觉的细节。推理时RTC的推理频率是每秒3次,是所有方法里最高的,理论上应该反应最灵敏,结果它的成功率反而是垫底的60%。这说明光靠"算得勤"并不能保证表现好,动作衔接的平滑程度、状态预测的准确性,这些因素同样重要,甚至更重要。
团队还专门挑了一个关节(左臂第三关节)做了细致的连续性分析。朴素异步执行在某次实验里,这个关节的角度在不到一秒内从负1.0弧度猛跳到负1.8弧度,瞬时加速度飙到744.1弧度每平方秒,这个数值大概相当于机械臂被猛地一拽的感觉。相比之下,Legato把同一个关节的速度基本控制在正负1弧度每秒的范围内,最大加速度只有46.6弧度每平方秒。
这组对比让我想起一件事。如果你开车时导航突然重新规划路线,方向盘被瞬间拧了一个大角度,你会本能地觉得不舒服、不安全,哪怕最终目的地是对的。机器人的动作衔接也是一样的道理,哪怕两段动作各自看起来都合理,衔接处的剧烈跳变依然会让整个系统显得不可靠,甚至可能造成实际的机械损伤或者任务失败。如果不做任何平滑处理,这种硬拼接带来的后果就是实验里看到的744.1这个数字,一个足以让人捏把汗的加速度峰值。
两种优化撞在一起会怎样
论文还做了一件挺实在的事:把前面提到的两步去噪和这几种实时执行方法直接组合起来试试看。
把两步去噪塞进Legato和时序平滑各自的流程里,推理时间统一降到了21.956毫秒,分别带来了1.676倍和2.804倍的加速。但是代价也摆在那里,Legato的成功率从96.7%掉到了86.7%,时序平滑从76.7%掉到了70.0%,完成时间也都略微变长,动作连续性的几项指标普遍上升了大约20%。
这个结果挺诚实的,没有回避代价。它说明压缩计算步骤和保持动作质量之间存在真实的权衡,不是免费的午餐。但从另一个角度看,用牺牲10个百分点左右的成功率换来接近3倍的推理加速,对于很多实际场景来说,这笔账可能是划算的,具体怎么选,还是要看应用场景对速度和精度的真实权衡。
写在后面
读完这篇论文,我印象最深的其实不是那个把10步压缩到2步的去噪技巧,而是团队一开始花大力气去标定那些非模型的延迟,摄像头曝光、图像传输、状态反馈、指令响应,这些平时不太会被单独拎出来讨论的环节。
这让我意识到一个容易被忽略的事实:很多时候我们在优化一个系统时,习惯性地把注意力集中在"最显眼"的那个部件上,比如这里的AI模型推理速度,却忽略了整条链路上其他同样占用时间的环节。这篇论文用具体的毫秒数字证明了,机器人响应慢不全是模型的锅,摄像头和通信链路同样要背一部分责任。
还有一个细节值得单独说一下:推理频率最高的那个方法反而表现最差。这打破了一个直觉上的默认假设,很多人会觉得"算得越勤快,反应就该越灵敏",但这篇论文用真实数据证明了,衔接方式的设计可能比刷新频率更关键。
这篇论文没有解决的问题是,整个方案还是针对一个特定任务(叠衣服)和一个特定底层模型(π0.5)来验证的,换一个任务场景,比如需要更精细力控的装配任务,这套结论是否还成立,值得继续追问。
Q&A
Q1：两阶段非均匀去噪是什么？
A：这是论文提出的一种让机器人动作生成更快的方法,利用Flow Matching去噪过程中前期步骤稳定、后期步骤才需要精细修正的特点,把原本10步的计算压缩成2步,推理时间从61.557毫秒降到21.956毫秒,速度提升约2.8倍。
Q2：为什么机器人反应慢不能只怪AI模型算得慢？
A：论文实测发现,除了模型推理耗时,摄像头图像传输要32.8毫秒,机器人状态反馈要26.4毫秒,指令到实际动作响应还要15.3毫秒,这些非模型延迟加起来已经逼近百毫秒,单独优化模型速度解决不了整体响应慢的问题。
Q3：哪种实时执行方法在叠衣服实验里表现最好？
A：Legato在需要训练的方法里表现最好,成功率达96.7%;时序平滑在不需要额外训练的方法里表现最好,成功率为76.7%。两者在动作连续性和完成时间上也都优于其他对比方法。
