1. 先分清三件事WM、WAM、VLA各自的定位这两年机器人圈子里WM、WAM、VLA这几个缩写出现的频率越来越高。很多人一看到就头大以为是三个差不多的东西实际上它们处在完全不同的“岗位”上。我见过不少团队在技术选型时把VLA和WAM混着聊最后方案做了大半年才发现从一开始就走错了方向。所以这篇先把概念摆清楚再往下拆。先说VLA全称是Vision-Language-Action Model视觉-语言-动作模型。它做的事情很简单你给我一张图或者一段视频再给我一句自然语言指令我直接输出机器人的动作。这个“动作”可以是机械臂关节角度、末端位姿增量也可以是底盘的速度指令。VLA的核心特征是“跨模态对齐”——把视觉信息、语言指令和动作空间压进同一个网络里。再说WMWorld Model世界模型。它不直接输出动作它输出的是“对环境未来状态的预测”。给一段当前观测模型推演接下来几秒环境会怎么变。世界模型最大的价值在于“想象”——机器人还没实际动手先在内部模拟一下“如果我这样动环境会变成什么样”。这个能力在规划里特别值钱因为真实世界试错成本太高了。最后是WAMWorld Action Model或者按一些论文里的叫法World and Action Model。它更像是WM和VLA中间的那一层既建模环境动态也输出动作。但WAM通常不会像VLA那样接受复杂的语言指令它更专注在“状态-动作对”的联合建模上。你可以把WAM理解成“一个有世界模型能力的动作预测器”。我个人的分类习惯是这样的VLA解决“我该做什么”WM解决“环境会变成什么样”WAM则试图同时回答“环境会怎么变 我该怎么做”。要注意WAM不是VLA的超集也不是WM的附庸它在架构设计和训练目标上都有自己的一套逻辑后面专门开一节细说。2. “看”的层次从感知到世界模型2.1 世界模型真正在预测什么很多人以为世界模型就是“视频预测”——输入几帧图像输出未来几帧。这个理解太窄了。确实早期像SVG、VideoGPT这类工作是在做像素级别的预测但现在的世界模型普遍在** latent space隐空间**里做预测而不是在像素空间。为什么因为像素级预测有两个难以回避的问题。第一是计算量爆炸一张512x512的RGB图就是将近80万个数值预测未来10帧就是在预测近千万个数值训练和推理都扛不住。第二是像素级损失函数会把模型的容量浪费在纹理细节上比如预测树叶怎么摇、水面怎么反光但这些跟机器人决策其实没什么关系。真正有用的世界模型预测的是**“跟决策相关的状态变化”**。比如一个抓取任务中模型需要预测的是“物体被夹爪碰触之后会不会滑动”“夹爪合拢到多少距离会接触表面”而不是“背景墙的光影怎么变化”。所以现在的主流做法是把观测编码成语义特征在特征空间里做动态预测再解码回策略需要的状态表示。2.2 世界模型在机器人侧和自动驾驶侧为什么长得不一样同一个“世界模型”的概念在自动驾驶和具身智能里演化出了两种风格很多人没意识到这一点。自动驾驶那边世界模型更强调**“场景演化”**。像Wayve的GAIA、特斯拉的占用网络核心目标是预测道路上其他交通参与者的未来轨迹——旁边那辆车会不会变道、行人会不会横穿。这类世界模型是“以自我为中心”的模型自己被固定在车里环境在变。机器人操作这边世界模型更强调**“交互结果”**。机器人手臂一动物体状态就会跟着变模型需要搞清楚的正是“动作-状态”之间的因果链条。所以机器人侧的世界模型通常会和动作空间强耦合甚至直接预测“执行了某个动作之后状态向量会怎么变”。这个差异直接影响模型的输入端设计。自动驾驶的世界模型输入是历史帧序列加自车状态机器人世界模型则一定要把动作也喂进去否则模型无法建立“我做了什么世界随之改变了什么”的因果映射。如果你在搭机器人的世界模型时忽略了动作输入那你的模型本质上只是个“视频预测器”没法serve决策。2.3 世界模型在“看到想做到”链条里的真实位置回到标题里“看”这个字。大多数人觉得“看”就是感知接一个目标检测模型就完事了。但如果你的系统里有世界模型“看”的含义就不一样了——“看”不再只是“识别出这是什么”而是“理解当前状态并且推断出接下来会怎样”。我自己做一个分拣项目时体会特别深。纯感知方案是把识别和动作割裂的相机识别出零件位置和姿态规划模块根据当前位姿规划轨迹。这听起来没问题但一旦零件在抓取过程中发生滑动或者被夹爪碰动整个规划就失效了。加了世界模型之后系统会预测“夹爪接近到某个高度时零件会不会跟着移动”从而提前调整下爪策略。这种“预判性”正是从“看到”到“想到”的关键跳跃。3. “想”的层次VLA如何把语言推理转成动作3.1 一个VLA模型的典型推理链路VLA的推理链路拆开来看其实没有想象中那么玄。以目前最常见的架构比如RT-2、OpenVLA、π VLA这类为例整条链路是这样的首先是视觉编码器。输入图像或视频流通过CLIP或SigLIP这类预训练视觉编码器转成视觉token。这里有一个很关键的工程细节视觉token的数量直接决定后续Transformer的计算量。一张224x224的图像切成patch可能产生256个token而机器人场景往往需要多视角输入比如腕部相机加外部固定相机这就意味着每次推理要处理512甚至上千个视觉token。然后是语言指令编码。指令文本通过tokenizer切成token序列跟视觉token拼在一起送入大语言模型LLM的主干网络。这里体现VLA和传统机器人pipeline的本质区别语言指令不只是一个“意图标签”它和视觉信息在同一个语义空间里被联合编码模型可以理解“把红色杯子放到蓝色托盘上”和“把蓝色托盘上的红色杯子拿起来”这两句话在动作语义上的差别。接着是动作解码。这是VLA和普通多模态大模型最大的不同点。动作信息不能像文本一样切成离散token因为机械臂的关节角度是连续值。常见的做法有几种一是把动作空间离散化比如把每个关节的角度范围切成256个bin然后当成token去预测二是直接用回归头输出连续值三是离散和连续混合。RT-2用的是离散化OpenVLA在微调时也用了离散化方案但实际部署时很多人会换成连续回归头因为离散化会带来不可避免的量化误差。最后是动作序列长度。最早的VLA一次只预测一个动作然后重新推理一次频率低得可怜。现在的VLA普遍支持预测一段动作轨迹action chunk比如一次预测未来16步或者32步的关节位置序列然后周期性滚动执行。action chunk的引入对成功率提升非常明显因为单步预测很容易陷入“抖动循环”——模型在每一步都在修正上一步的偏差反而把轨迹搞得很不稳定。3.2 训练VLA不是“堆图文对”就行VLA训练这个话题在网上讨论特别多全年都有人问“VLA是怎么训练的”。我简单梳理一下它会经历两个阶段这也决定了它和单纯的多模态大模型训练有本质区别。第一阶段是视觉-语言预训练这个阶段其实和训练一个多模态大模型没什么区别用的也是海量的图文对数据目标是让模型建立“看到东西能用语言表达出来”的能力。这个阶段VLA并不学动作学的是通识语义。第二阶段才是VLA的关键动作学习。这个阶段的训练数据是“视觉观测 指令 机器人动作轨迹”的三元组。动作轨迹从哪来目前主要靠遥操作采集human teleoperation少量靠仿真环境自动生成极少数靠强化学习在线收集。数据里最难的瓶颈就在于轨迹质量——不是所有轨迹都能用来训练的有些动作轨迹虽然完成了任务但路径绕了远路、姿态走得很难看这类轨迹教会模型的不是“最优行为”而是“某种行为”。我在实际项目里发现VLA微调阶段数据清洗的优先级甚至高于数据扩充。你宁可用2000条高质量、风格一致的轨迹也别用1万条从多个操作员手里攒出来的、风格各异的轨迹。模型会把“操作员的个人习惯”学进去比如有的人喜欢先捏一下物体再抓有的人喜欢直接怼上去抓混合数据会让模型的策略变得“精神分裂”。3.3 微调VLA的核心分歧全参微调、LoRA、还是蒸馏这算是目前VLA落地时最有争议的工程决策之一尤其是大家手里普遍只有一块或者几块消费级显卡时。全参微调full fine-tuning效果是最好的因为模型的所有权重都能针对你的机器人形态做调整。但代价极其昂贵——以7B规模的VLA为例全参微调至少需要数百GB的显存一般团队根本跑不动。而且全参微调有灾难性遗忘的风险微调之后模型对通用指令的理解能力会明显退化。LoRALow-Rank Adaptation是大多数中小团队的选择。它的核心思路是冻结原有模型权重只训练注入的低秩矩阵。最直观的优势是显存占用大幅下降7B模型用LoRA微调只需要不到20GB显存。但LoRA有它的局限低秩假设在动作空间这种高精度场景下不一定成立。动作预测需要很高的精度如果低秩矩阵容量不够模型的策略表达能力会受限。我们测试下来的经验是LoRA的秩设置在64到128之间比较稳妥太低容易欠拟合太高又失去了省显存的意义。蒸馏是另一种思路。用一个大的、能力强的VLA模型比如70B级别的当teacher让一个小模型比如2B或者3B去模仿它的行为。蒸馏出来的小模型推理速度快适合部署在真实机器人上。但蒸馏的前提是你手里已经有一个好的teacher模型这本身就是一个高门槛。从社区现状来看π VLA项目里的“zero-shot跨具身”思路就是典型的teacher能力外溢——用大规模预训练模型的能力直接服务下游任务不在每个机器人都重新微调一遍。3.4 为什么VLA会让“想”变得更自然VLA和传统“感知-规划-控制”pipeline的最大区别在于它把“理解任务”和“生成动作”捏在了一起。传统方案里“任务理解”靠人为写规则或者状态机“动作生成”靠路径规划算法这中间需要大量的人工接口设计——你得定义什么叫“放好”、什么叫“对齐”、什么叫“旁边”。VLA不用。你直接说“把红色杯子放到蓝色托盘上”模型自己就能把这句话跟图像里的语义对应起来并转化为末端执行器的运动轨迹。这个“语言到动作”的直通能力是VLA最值钱的部分。在真实产线上这意味着一套拣选逻辑只靠改prompt就能切换任务不用重新写规则、不用重新标数据、不用重新调规划参数。4. “做”的层次WAM在动作生成上的独特价值4.1 为什么WAM不能简单理解为“VLA去掉语言”很多人第一次看到WAM时直觉反应是“这不就是VLA不加语言指令吗”。这个理解是有偏差的。VLA去掉语言之后剩下的是一个“图像输入、动作输出”的映射网络它并不建模环境动态。也就是说VLA本质上是一个行为克隆模型——它在模仿数据里出现过的最优行为但对“如果动作执行出错环境会变成什么样”没有建模能力。WAM不一样。WAM的训练目标里明确包含了对环境状态的预测。它不仅要学会“给定当前观测输出动作”还要学会“给定当前观测和动作输出下一时刻的状态”。这种“动作状态联合建模”的能力让WAM在做闭环控制时更有优势。举一个具体的例子。在零件装配场景中VLA模型看到“轴已经插入孔的一半”这个状态时可能因为训练数据里没见过“插歪了”的中间状态就直接给出错误动作——因为行为克隆假设“当前状态在数据分布内”。而WAM因为训练时见过“轴插歪之后孔壁会施加反作用力导致轴偏转”这类状态转移所以它能预判“如果我继续往下压轴会卡住”从而提前调整施力方向。4.2 WAM的典型网络形态和训练策略WAM的典型架构和VLA大体类似也是视觉编码器加Transformer主干加动作解码头区别主要在训练目标上。一个标准的WAM训练loss通常包含两个部分动作预测loss和状态预测loss。动作预测loss和VLA一样关注“动作跟数据里的行为是否一致”状态预测loss则关注“在当前动作下下一时刻的隐状态是否被正确预测”。这两个loss并不总是相辅相成的。我自己的经验是它们的权重比需要仔细调。动作loss权重太高状态预测就变成可有可无的附属任务WAM退化成普通的行为克隆模型状态预测权重太高动作预测会比较保守模型倾向于输出“稳妥但不够高效”的动作。我在一个夹取项目上试过从4:1到1:4的多个比例最终在2:1左右效果比较好——动作为主状态为辅。训练WAM的数据要求也比VLA更严格。VLA只需要“观测-指令-动作”三元组WAM还需要同一时间序列上的后续状态这意味着采集数据时必须有高频的状态记录比如关节角度、物体位姿、接触力传感器读数。如果你的数据采集系统只记录了图像和动作没有同步记录状态变化那WAM会很难训。这一点在数据采集方案设计阶段就要想清楚不然后期补数据的成本极高。4.3 从“我想”到“我能做对”WAM时的闭环反馈闭环能力是WAM在实用中比VLA更“稳”的核心原因。VLA在真实机器人上最典型的翻车方式是这样的模型预测了下一步动作执行之后状态出现偏差——比如物体滑动了一点点或者夹爪没完全闭合——但VLA没有意识到这个偏差它继续按照“原本以为是理想状态”的方式输出动作。因为VLA的每个决策都基于当前观测重新生成理论上它应该能感知到偏差但问题在于行为克隆模型对“分布外状态”非常脆弱当观测偏离训练数据分布时VLA输出的动作会变得不可预测。WAM则多了一层“自我校验”模型在输出动作之前会先用世界模型部分推演一遍“这个动作会导致什么状态”用推演结果跟当前实际状态做比对再决定是否采用这个动作。这个机制相当于给机器人的每个动作加了一道内部保险虽然增加了推理耗时但显著降低了执行风险。在精度要求高的场景里这个代价通常是值得的。5. 从开源VLA系统看技术走向π VLA与NVIDIA Alpamayo5.1 π VLA跨具身预训练如何降低落地门槛π VLA大概是目前具身智能社区里讨论度最高的开源VLA框架之一。它背后的核心思路是“在不同机器人平台之间共享一个预训练模型”。简单说用A机器人的数据训练的模型在B机器人上也能直接工作不用重新微调或者只要极少量的适配。这个思路对行业的价值非常大。因为VLA落地最大的瓶颈在于数据——每家公司的机器人形态不同、相机安装位置不同、动作空间不同导致数据不能互通。如果每个新机器人平台训练VLA都得从零开始那这个领域永远走不出实验室。π VLA做的事情本质上是在模型层面找到了不同机器人平台的**“公共语义空间”**把不同机器人的动作表示统一到同一个抽象层级让模型学到的是“任务层面的意图”而不是“特定机器人关节角度的映射”。我看了π VLA发布的技术报告和demo演示它在ALOHA、Google Robot、以及一些自建机器人平台上都做了跨具身泛化测试。最让我觉得有价值的是他们的工作证明了零样本迁移在具备物理常识级别的任务上是可行的——比如“拿起物体再放到另一边”这种基础操作。但在精细任务上比如插入、装配、叠放等对力控和精度要求高的任务跨具身仍然需要少量目标平台数据做适配。所以我认为π VLA现阶段最适合当作“预训练底座”想直接零样本上产线还不现实但它的确把从零训练VLA的门槛大幅拉低了。5.2 NVIDIA Alpamayo辅助驾驶场景的VLA推理模型Alpamayo是NVIDIA在辅助驾驶领域新近开源的VLA推理模型。它跟具身智能那边的VLA有个显著区别Alpamayo面对的感知环境不是桌面、机械臂和零件而是行车路上的动态交通场景。它需要处理的信息类型更多样——车道线、信号灯、行人、其他车辆、路面标识——而且必须在极低的延迟内完成推理因为辅助驾驶的安全决策等不起几百毫秒。但从模型架构来看Alpamayo跟桌面VLA又有很多共性也是“视觉编码器 语言指令 动作/规划输出”的范式只是“动作”变成了车辆的横向或者纵向控制指令。这让我意识到一个趋势VLA正在成为机器人领域的“通用控制接口”无论是机械臂还是车辆只要输入的是多模态观测和自然语言指令输出的是连续控制量都可以套进这个范式。NVIDIA把Alpamayo开源出来对行业最直接的意义是辅助驾驶场景里VLA的推理优化经验可以被复用。车端的算力约束比实验室里的GPU服务器严苛得多需要在嵌入式平台比如Orin系列上跑通完整的VLA推理链路——量化和剪枝几乎是标配。这些在边缘侧部署VLA的经验对未来的具身智能机器人落地同样很有参考价值因为机器人本体上能带的计算设备同样不是满血服务器。5.3 从这些实例中能提炼出什么共性把π VLA和Alpamayo放在一起看能明显感受到几个技术趋势。第一“同一个模型结构吃多个机器人平台”这条路是通的。两个系统都证明只要数据组织方式对视觉-语言-动作这个范式本身就有跨平台泛化的潜力不需要为每个机器人重新发明一套模型。第二数据比模型更值钱。π VLA跨具身零样本迁移的边界基本就是数据覆盖度的边界Alpamayo面对的真实交通场景核心成本也全在数据标注和场景覆盖上。模型架构层面的创新已经趋缓下一步的竞争焦点正在转向“谁能更高效地造出高质量训练数据”。第三VLA的部署瓶颈已经从“能不能训出来”变成了“能不能跑得动”。π VLA和Alpamayo都在强调推理效率优化说明大家的共识是VLA要真正成为机器人的大脑光有大的模型不够必须解决在受限设备上的实时性问题。6. 回到工程决策什么时候该用哪一类模型6.1 做选型前先问自己三个问题我在给团队做技术咨询时遇到最多的问题就是“我们应该上VLA吗”。每次我都先反问三个问题。第一个问题任务是语言可描述的还是本质上是几何操作的如果你做的是“把A类零件放到B号料盘”这种可以通过语言清晰描述的任务VLA的语义理解能力有直接价值。但如果你做的是“高精度轴孔装配”这种靠手感、靠力觉反馈才能完成的任务——语言几乎给不了有效信息——那VLA的优势就不明显传统的力控方案或者强化学习方案可能更合适。第二个问题你有多少数据以及数据能不能持续积累VLA不是“拿少量数据训一下就能上线”的模型至少需要几千条高质量轨迹起步而且模型上线之后还需要不断用新数据做迭代。如果你的项目是一次性交付没有持续数据回流机制VLA的投资回报率会很低。第三个问题你的场景允许“模型犯错”吗VLA目前的成功率不是100%即使微调充分的任务真实场景里也会出现意外失误。如果应用场景完全不允许失败——比如医疗手术、航空航天——那VLA更适合做辅助决策而不是直接控制末端执行器。反之如果场景是仓储分拣这种“出错可以重来”的任务VLA的高效性就非常受用。6.2 算力和实时性的现实账本很多团队在选择VLA时严重低估了一步——推理延迟的真实代价。一个7B参数量级别的VLA模型在单张A100上做一次推理大约需要150到300毫秒这还只是模型前向计算时间没算图像编码和token化开销。如果一次预测16步action chunk模型推理一次能支撑几十秒的执行那这个延迟是可以接受的。但如果你的控制频率要求高于5HzVLA的推理延迟就直接吃掉了控制节拍——这时候你得考虑蒸馏小模型、量化、TensorRT加速或者干脆换用传统方案。在真机部署时还有一个很容易忽略的问题视觉token数量与控制延迟的关系。多视角输入会线性增加token数量推理时间随之上涨。如果控制精度要求高需要高分辨率图像又与延迟需求冲突。这是一个典型的工程权衡问题。我的建议是在满足任务需求的前提下尽量减小图像分辨率、降低相机路数优先保住控制频率精度问题留给模型的泛化能力去解决。6.3 我踩过的一些坑与建议最后分享几个实践中的具体经验。第一个坑是把VLA的输入图像分辨率降得太低。一开始为了推理速度我把输入从640x480缩到了224x224。结果机械臂对小物体的抓取成功率直接掉了一大截——因为目标在低分辨率图像里就是十几个像素的小块视觉特征几乎全是噪声。后来用320x240加ROI裁剪在不明显增加延迟的情况下恢复了大半成功率。视觉输入的细节保留比模型本身的容量更敏感。第二个坑是action chunk长度不是越长越好。网络上很多研究说长chunk能提升稳定性但我实测发现超过32步之后模型预测的末段轨迹会明显漂移。因为模型在预测未来较远的动作时不确定性变大末段动作质量下降。把chunk设成16、然后每8步重新计划一次replan兼顾了轨迹稳定性和实时反馈。第三个坑是强行在CPU上跑VLA推理。我见过有人为了省GPU成本用CPU跑一个小蒸馏VLA推理一次800毫秒以上机器人动作卡顿到没法看。如果确实没有GPU资源不如用经典控制方案VLA模型至少需要一个像样的推理加速卡才能发挥价值硬件成本在这件事上省不得。第四个建议是数据闭环一定要老板亲自抓。VLA项目的成败七成在数据三成在模型。很多项目死在“训练效果差→怀疑模型→调结构→发现还是数据不够→再攒数据→之前调的结构又推倒重来”这个循环里。建议项目初期就固定好数据采集格式、标注规范和评估基准数据积累从第一天就开始不要等模型训不动了才回头补数据。回到最开始的问题——WM、WAM和VLA怎么选。我的看法是如果你要做的是任务理解层次复杂、控制精度要求中等的操作VLA是当前最合适的起点如果你的系统对闭环鲁棒性要求高、但任务语义相对固定WAM的“状态预测动作生成”联合建模会更稳如果你需要做长时序规划、或者想提升强化学习的数据效率世界模型WM是值得投入的方向。三者不是非此即彼的关系在成熟的机器人系统里它们未来很可能以“VLA做顶层意图理解WM做方案推演WAM做底层动作执行”的形态共存。这篇写到这里差不多把我这一年多在VLA和世界模型项目里积累的经验都倒出来了。最后再提一句最想说的模型选型固然重要但真正决定项目成败的往往不是模型本身而是你对自己任务的理解深度和数据工程的细致程度。希望这篇能帮你少走一些弯路。
