如果你跟我一样这两年几乎被“具身智能”“端到端机器人”这类词反复刷屏却一直没真正动手跑过一个VLA模型那这篇文章大概就是写给你的。我最近用一周多时间把这条链路从论文到Demo完整“速过”了一遍内部代号就叫π05——π代表策略05是我对这个规格的粗率称呼代表一个接近5B参数的轻量级视觉-语言-动作模型Vision-Language-Action Model。所谓“速过”不是看完两篇博客就算完而是把环境搭建、权重加载、推理验证、数据后训练、评估闭环全部手动走通一遍并把踩过的坑按排查顺序记录下来。这篇笔记适合三类人想弄明白VLA到底在做什么的算法入门者、正准备在单卡机器上跑起VLA推理的工程同学、以及在做技术选型时纠结“要不要上VLA”的项目负责人。我会按照实际动手顺序来讲尽量把每一步为什么这么做也交代清楚。1. VLA模型是什么视觉、语言、动作三条线如何捏成一个策略经常有人把VLA说得很玄其实剥开之后就是一套很直接的架构输入一段自然语言指令和一帧或多帧图像输出一串机器人可以执行的动作。它跟传统“视觉伺服”或“单任务模仿学习”最大的区别在于动作不是靠一套固定的规则映射出来的而是由大语言模型在理解当前场景和指令之后以自回归方式“生成”出来的。1.1 一个句子讲清VLA你可以把VLA想象成一个特别擅长“看图说话做动作”的模型。左边接收摄像头画面右边接收类似“把红色方块放到蓝色托盘里”这样的文本指令中间经过一个巨大的语言模型做语义融合最后吐出一连串关节角度或末端位姿增量。整个过程读起来像在写文章但每个“词”其实代表机器人某一时刻的目标动作。这里的动作一般有两种表达方式一种是连续向量比如七自由度机械臂的七个关节角度加上夹爪开合量组成一个八维向量另一种是离散化动作把连续空间切分成若干bin用token ID来表示。采用哪种方式直接决定后面动作头怎么设计也会影响推理时的解码方式。我在π05里用的是连续向量加动作增量也就是模型预测的不是绝对角度而是下一步相对当前状态的偏移这样对小幅度调整更友好也不容易因为初始位姿变化导致整个轨迹失效。1.2 三个组件与一条自回归链路VLA内部通常可以拆成三块。视觉编码器负责把图像变成视觉token常见做法是用类似ViT的patch embedding把一张分辨率336×336的图切成14×14的patch每个patch变成一个token整套token序列再经过一个投影层映射到语言模型的嵌入空间。语言模型是中间的大脑它接收“图像token 指令token 动作历史token”拼接起来的完整序列用自回归方式逐个预测后续动作token。动作头则把语言模型最后输出的隐状态映射到具体的动作空间可能是一个简单的MLP也可能是带归一化层的残差结构。这三个组件串联起来的链路用一句话概括感知由视觉编码器完成语义推理由LLM完成动作用独立的输出头完成。有意思的是VLA虽然结构上接近多模态大模型但它跟“看图聊天”的模型有本质差异后者把动作当作文本输出比如让机器人“告诉你该怎么做”而VLA把动作当作真正的控制信号允许一个7自由度机械臂直接执行这组数字。1.3 为什么把它叫π而不是模型如果你翻机器人学或者强化学习的书会经常看到字母π它代表策略policy也就是“给定某个状态s选择某个动作a”的映射关系。VLA本质上就是一个从“观测指令”到“动作序列”的策略函数所以很多研究组和开源项目都习惯用π来命名比如π0、π05这类代号。我沿用这个习惯把内部速通实验叫π05纯粹是为了沟通方便不是说它对应某个公开模型的准确名称。理解这一点还有个实际价值当你把VLA放进控制系统时需要把它当作一个策略组件来考虑而不是当一个可以随时对话的“大脑”。它的输出频率、动作范围、安全约束都要在设计控制循环时一并规划。很多项目失败不是因为模型不好而是把策略直接裸接在机器人上缺少一层动作校验和轨迹平滑导致实测时机械臂要么抖得厉害要么直接撞到限位。2. π05的规格说明我为什么要卡在5B参数这条线真正动手前最需要回答的问题不是“哪个VLA最强”而是“我手头的硬件和项目周期适合哪个规格”。我最后把实验版本卡在5B参数附近完全是基于一张主流单卡显存反推出来的结果。2.1 π05代号怎么来的代号里的05有两层意思。第一层是规模模型主体落在5B参数上下比双位数B的旗舰模型轻很多但又比几百M的玩具Demo更能体现VLA的跨任务语义泛化能力。第二层是“0.5版本”它不是一个完整产品而是用于验证数据格式、推理链路、动作接口的半成品配置。我建议第一次接触VLA的人都这么做——先用一个自己能完全掌控的小规格把整条管线跑通再根据结果决定要不要上更大的模型。参数规模选5B而不是更大有个现实原因。5B模型以bf16精度加载光权重就占10GB左右加上ViT视觉编码器、动作头、中间激活和KV cache单样本推理的峰值显存可以压在16GB到20GB之间。这个区间正好是一张24GB显卡能吃下的范围还能顺便做LoRA微调。如果直接上70B级别的VLA光是加载权重就需要140GB只能走多卡或CPU offload项目复杂度瞬间翻倍。2.2 输入输出规格与动作表达我用的π05规格可以简单归纳成下面这张表组件典型配置说明视觉输入1~4帧图像分辨率336×336多帧用于提供时序信息单帧适合静态抓取任务指令输入自然语言通常限制在256 token以内过长指令会挤压视觉token空间影响注意力分配动作输出未来32步动作序列每步8维采用动作chunking一次性预测一小段轨迹关节维度7个旋转关节1个夹爪不同机器人需要重新映射动作维度精度bf16推理LoRA微调视觉编码器冻结语言模型部分参数参与训练动作chunking是这里很关键的一个设计。如果模型每一步只预测一个动作向量控制频率稍微一高就会频繁调度且单步预测对噪声极其敏感。实际操作中做法是让模型一次性生成未来N步动作比如32步再按时间戳逐帧下发这样既降低推理频率又让轨迹更加平滑。这个trick是从VLA的实践里普遍沿用的不是某个框架独有的。2.3 算力和显存预算清单跑通一次完整推理的显存占用可以大致估算5B模型bf16权重约10GB视觉编码器在推理时约占1到2GBKV cache根据生成长度不同在1到4GB之间动作头几乎可以忽略。峰值16GB到20GB是一个比较贴合实际的范围这也解释了为什么配置建议里24GB显存是“舒服线”16GB则需要靠FP16/量化或限制帧数来硬撑。训练或微调又是另一回事。全参数微调5B模型至少需要48GB以上的显存即便用ZeRO也会对显存带宽提出很高要求。我的建议是如果在单卡上做后训练优先考虑LoRA等参数高效方法可训练参数量压到全部参数的2%到5%24GB照样能跑。实测下来LoRA对VLA动作空间的拟合能力是够用的尤其是任务数据和预训练数据分布比较接近时。3. 速通推理环境从空机器到模型吐出第一组动作这一节是整个速通过程里最琐碎但也最影响心情的部分。很多新手把模型下载好之后卡在依赖报错上一卡就是一两天。我尽量按我实际操作的顺序来写。3.1 环境依赖与编译陷阱新机器上我的习惯是先装CUDA 12.1及以上版本然后用conda单独建一个Python 3.10的虚拟环境避免把系统Python环境搞乱。PyTorch建议直接用2.x系列因为VLA模型加载时很多底层算子依赖新版自动微分机制。接着安装模型加载相关的框架比如社区里常见的基于Transformers风格接口的加载库以及处理图像的那套预处理工具包。最容易踩的坑是FlashAttention编译。很多VLA代码里都有attn_implementationflash_attention_2这类设置一旦机器上的CUDA版本和PyTorch编译版本对不上编译过程会卡十几分钟甚至直接报错。我的做法是第一步先禁用FlashAttention用原生的SDPA或eager attention先把链路跑通确认模型逻辑没问题再回来开加速。不要一上来追求全加速你的目标首先是看到模型输出动作而不是把推理压到20毫秒。3.2 模型权重加载与接口差异VLA领域至今没有统一的接口标准每个开源项目的代码风格都不同有的把视觉编码器包在LLM里有的则拆成独立模块。速过的第一个动作我建议直接跑该项目官方给的demo脚本而不是自己从零写加载逻辑。把demo跑通之后再把它替换成你自己的测试图像和指令文本。加载权重时有一个经验关注配置里的torch_dtype务必统一成bfloat16。fp16在部分VLA模型上会出现溢出尤其在动作头的loss计算时梯度容易变NaN。同样重要的是关闭任何默认的编译优化比如torch.compile因为很多开源VLA代码还没在新PyTorch版本上完全兼容你看到的报错可能跟模型完全无关纯粹是编译器和动态shape不匹配。3.3 最小推理脚本图像、指令到动作整个推理过程抽象之后非常简洁我用示意代码来描述import torch # 伪代码示意接口名来自某个通用VLA推理入口 policy VLAPolicy.from_pretrained( model_path.../pi05, torch_dtypetorch.bfloat16, devicecuda ) image load_image(test_scene.png) instruction 把红色方块放到左侧托盘 # 返回的动作形状是 [1, action_horizon, action_dim] actions policy.predict( images[image], instructioninstruction, action_horizon32, ) # 输出为关节角度增量需叠加到当前关节状态后下发 current_joint_state robot.get_joint_state() for i in range(actions.shape[1]): target_joint current_joint_state actions[0, i] robot.move_joint(target_joint) time.sleep(dt)这份代码看起来简单但里面有个非常容易忽略的细节动作是“增量”还是“绝对位置”。不同的VLA实现了不同的输出语义有些模型输出绝对关节角有些输出相对位移你在下发前必须跟机器人驱动对齐。我的建议是一开始把模型输出的动作直接打印出来人工检查数值范围如果数值在±0.1附近大概率是增量如果在几弧度级别大概率是绝对角度。这一步可以帮你避免第一次运行就把机械臂打到限位。3.4 把输出的动作接到真实机器人前的最后一步如果没有真实机器人可以用仿真环境代替大多数开源VLA项目都提供了仿真接口。但无论真机还是仿真最后一步都要加限位检查和幅度限制。模型输出的动作可能存在跳跃或超限实操中我会写一个简单的高速滤波器把每一步的动作变化限制在安全范围内。这不是防御性编程而是VLA这类自回归策略输出本身存在偶发异常值的概率安全冗余必须做在驱动层之前。4. 最容易卡住的三个错误信号实测踩坑与完整排查链路速过过程中遇到的报错未必多但有几个“看着像玄学”的问题特别消耗时间。我把它们按排查链路完整记录下来你遇到类似情况可以直接按顺序试。4.1 图像预处理与token长度错位第一个坑来自图像resize。VLA的视觉编码器对输入尺寸有严格约定一般来说是336×336或者224×224且必须和预训练时的patch大小对齐。你把图像任意裁剪或resize之后再传进模型轻则输出异常重则报维度不匹配的错误。一旦看到类似“expected sequence length to be 576 but got 729”的报错优先检查图像预处理函数而不是怀疑模型文件损坏。排查链路是先看配置里的image_size和patch_size算出预期的token数量比如336/1424一行24个patch共576个token再看实际传给模型的张量维度是否一致最后看是否有多余的归一化步骤。很多项目在预处理里默认加了ImageNet的均值和方差归一化如果你的测试图像域差别较大会影响效果但一般不会导致运行报错。4.2 动作归一化方向反了第二个坑在动作统计数据上。训练VLA时绝大多数项目都会对动作样本做归一化比如计算每个关节角度的均值和标准差把原始动作变成标准分数。推理时如果只调用了模型没有把输出反归一化回真实单位那么你下发给机器人的动作全是“缩放过”的数字表现就是机械臂几乎不动或者动作极其微弱。我排查这个问题时的方法是把模型预测的一串动作和输入图像对应的真实动作日志做分布对比绘制直方图。如果模型输出全部集中在零附近而且方差远小于训练日志中的动作方差十有八九是没有做反归一化。处理办法是找到训练阶段保存的mean和std参数在模型输出之后执行raw_action predicted_action * std mean。这一步看起来不起眼但它直接影响VLA能否在真机上完成任务。4.3 语言模板不一致导致性能骤降第三个坑是最隐蔽的。VLA训练时指令文本会按照一种固定的模板包装比如“指令{text}请执行操作”之类。推理时如果说话方式跟模板差异太大比如加了个“请你现在帮我”的客套前缀模型虽然不至于报错但性能会明显下降。原因在于自回归模型对前缀敏感模板偏移会让token分布偏离训练分布。我在速通过程里吃了一次这个亏换了一台机器跑同样的模型效果突然变差后来发现是推理代码里套了一层额外的系统prompt。把prompt改成和官方demo完全一致的格式之后性能立刻恢复。如果你也遇到“模型之前明明可以现在不行”的情况先对比prompt模板这是成本最低的排查点。4.4 一次典型的“输出全是NaN”排查过程NaN问题也值得单独记录。有次我在微调后的模型上做推理输出全是NaN整个排查链路是这样的第一步检查输入图像确认没有全黑或包含inf像素第二步检查加载权重时的dtype发现模型权重被转成了fp16而不是bf16第三步把dtype改成bf16后仍然复现再查发现动作头部分有自定义LayerNorm在fp16下溢出最后把动作头的LayerNorm强制改为float32计算问题解决。这个案例说明VLA里的NaN不一定来自模型主体动作头或归一化层也经常是重灾区。排查时不要一上来就怀疑数据先固定dtype、固定输入再用二分法屏蔽模块能快速缩小范围。5. 从“能跑通”到“真能用”后训练数据与评估细节模型能吐出动作只代表Demo通了。真要在某个具体任务上工作通常需要一个后训练阶段。这里的坑跟纯语言模型微调很不一样我重点说三个容易被忽略的点。5.1 数据收集的配比与失败样本价值VLA后训练的数据格式通常是“图像序列 指令文本 动作序列”三元组。建议每条样本的指令不要只写一种固定说法同一任务至少换5种以上表达方式比如“把红色方块放到托盘里”“捡起红色方块并放在左边的托盘”。这能帮助模型把语义理解和动作策略解耦。更重要的一个反直觉经验是训练集里要保留一定比例的失败演示。我一开始只录成功轨迹结果模型在接近目标但位姿略有偏差时完全不会修正因为它没被训练过“从错误里恢复”。后来在数据里混入少量带纠偏动作的片段模型的鲁棒性明显提升。成功示例提供动作范式失败或纠偏示例提供误差修正的反馈信号二者都很重要。数据配比上我个人倾向大约七成成功、三成含纠偏过程。5.2 微调范围选择哪些层该冻、哪些层该动VLA有三个可微调的部分但最优策略不是全部都动。视觉编码器在大多数情况下可以直接冻结因为图像特征本身具有很强的通用性尤其当你用的不是合成图而是真实相机图像时冻结视觉塔能有效防止灾难性遗忘。语言模型主体使用LoRA只更新一小部分参数这样既能适配新指令风格又不会破坏预训练得到的语义能力。动作头建议全量微调因为它是直接决定模型能否在该机器人上输出有效动作的部分。我在项目里实测对比过冻结视觉编码器加LoRA微调LLM加全量微调动作头比全参数微调在目标任务上只低了不到4%的绝对成功率但显存占用和训练时间都大幅下降。如果你的任务数据不到几千条这个配置几乎是性价比最高的起点。5.3 评估指标与对照实验设计评估VLA不能只看“任务成功率”一个数字。成功率能反映最终结果但看不出策略的稳定性和安全性。我会同时记录平均完成时间、接近目标时的修正次数以及是否触发过限位或碰撞检测。这些指标放在一起才能判断一个策略是真正学会了动作还是靠蛮力恰好撞进了目标区域。做对照实验时还要固定随机种子和初始机器人位姿。VLA本身是有随机性的即使同一权重同一图像多次推理的动作序列也可能有微小差异。如果每次测试的初始姿态都不一样成功率波动会大到你没法判断一个改动是好是坏。我的做法是把评估集固定为50条带固定初始状态的任务每次跑三个种子取平均任何一个改动都拿这个基准说话。6. 速过之后继续深挖的三个方向如果你顺利走到这里说明已经具备“把VLA从权重变成机器人动作”的完整能力了。接下来有几个方向值得继续花时间。6.1 推理加速三板斧与量化风险第一板斧是开FlashAttention并保证CUDA版本匹配这一步通常能把注意力计算速度提升两倍以上。第二板斧是用KV cache生成长动作序列时避免重复计算历史token在长指令和多帧图像输入的情况下特别明显。第三板斧是动作chunking如果你一次生成32步动作推理频率可以从30Hz减到1Hz左右控制系统压力瞬间降下来。量化则需要谨慎。语言模型常见的int8量化在VLA上并不会完全失效但动作头往往对数值精度更敏感。我实测过用int8量化整个模型推理显存下降很明显但动作输出偶尔会出现明显抖动。如果一定要量化建议只量化视觉编码器和LLM的部分线性层动作头保持bf16。6.2 显存紧张时的替代架构当硬件条件有限时另一个思路是把VLA拆成两个模块感知理解由视觉语言模型负责动作生成由一个小规模策略网络负责。这种架构有点像“先用大脑做任务规划再用小脑做运动控制”虽然端到端程度降低但显存占用和部署灵活度会好很多。代价是感知结果到动作策略之间的信息传递可能丢失细节对于需要精细操作的任务端到端VLA仍是更好的方案。6.3 什么时候不该用VLA最后必须泼一盆冷水。VLA不是万能的如果你面对的是固定节拍、固定轨迹、高频控制的生产线任务传统运动规划加上视觉引导往往更稳定、更容易过安全认证。VLA适合的是多任务、语义复杂、环境变化频繁的场景它的优势是泛化性劣势是输出可解释性差、推理延迟高、安全验证困难。做技术选型时先问自己“这个任务的指令会变吗、物体位置会变吗、需要频繁切换技能吗”如果三个答案都是否那VLA大概率不是最优解。我自己的体会是π05这类速通项目最有价值的产出不是那个模型权重而是让你把“模型—数据—机器人”这条完整链路亲手走了一遍。链路里每个环节看似都能从文档里找到答案但只有真正跑过一遍你才会理解为什么动作归一化、模板一致性、视觉token对齐会在实际项目中变成比模型结构更重要的细节。如果你也想速过一遍我建议第一天集中精力跑通官方Demo第二天就开始换自己的任务数据后面所有时间都花在动作接口和评估脚本上。模型可以先用小规格链路必须完整。