做机器人策略模型的人大概都经历过这种尴尬。模型在仿真里表现不错一旦搬到真实机械臂上一个动作预测要几百毫秒控制频率上不去机械臂开始抖、漂移任务只能一遍遍重跑。最近杨立昆团队公开的一项 VLA 研究很多群里都在讨论0.7% 的参数40% 的性能提升推理只需要 11 毫秒训练 6.5 小时就能完成而且对标的是 7B 级 VLA 模型。如果只看这些数字这几乎是把机器人学习从“重型工业”变成了“轻量研发”。但作为长期看模型落地的人我第一反应不是欢呼而是想把这几个数字拆开。因为它们越漂亮越需要问清楚参数说的是总参数量还是可训练参数量性能是在哪个任务、哪个评测集、哪台机器上测的6.5 小时是单卡还是多卡11 毫秒是经过 TensorRT 优化后的数字还是原生 PyTorch 的推理速度这些差异会让同一句话得出完全不同的结论。我更倾向于把这项工作的核心价值理解为让 VLA 模型从一个“昂贵的实验结果”变成一个“可以快速迭代的工程方案”。这比标题里的“碾压”重要得多。1. 先别急着看“碾压”VLA 模型的痛点到底在哪1.1 VLA 不是加了一个视觉编码器这么简单VLA 全称 Vision-Language-Action Model输入是视觉画面和语言指令输出是机器人动作。它把感知、理解、规划、动作生成压到同一个网络里不再像传统流程那样需要单独做目标检测、状态估计、运动规划。这个思路看起来很直接如果大模型能看懂图片、理解指令为什么不让它直接预测机械臂的关节角度或者末端位姿但实际落地没那么轻松。视觉输入往往是连续多帧图像语言指令可能是“把红色杯子放到托盘里”输出则是高维动作向量。模型要把视觉 token、语言 token、动作 token 融合在一起还要满足机器人控制的高频要求。这让 VLA 的模型结构比纯文本 LLM 复杂得多训练数据也不是随便拿一批图文对就行而是需要真实的机器人操作轨迹。这也是为什么 VLA 研究过去几年一直停留在“大模型 大算力 大实验”的模式里。不是大家不想做小模型而是小模型往往学不到足够强的视觉语义理解一旦换环境就失效。1.2 为什么大 VLA 模型很难真正用起来7B 级 VLA 模型不是不能用而是让它在真实机器人上跑起来成本很高。首先参数量大单次前向计算就可能达到几十甚至几百毫秒一般只能用于离线轨迹生成或者慢速控制。机器人控制回路对延迟极其敏感控制频率一低任务就很难稳定末端稍微偏移一点整个动作就废了。其次训练成本更现实。7B 级模型哪怕只做微调也需要多卡并行数据清洗、损失分析、调参周期以天为单位。一个策略实验如果训练要一两天一个星期五次实验都是奢望。更麻烦的是大模型参数多一旦效果崩了你很难判断是数据问题、学习率问题、动作头问题还是预训练权重本身的问题。所以行业里真正需要的不是“又一个更大的 VLA”而是“能不能用更少资源把已有大模型变成可用策略”。这也是“0.7% 参数”这类思路吸引人的原因。维度传统 7B 级 VLA 部署常见状态高效小参数量方案想解决的问题参数量全量权重参与训练/推理冻结大部分参数只更新少量模块推理延迟高频控制场景较困难目标降到几十毫秒甚至更低训练成本多卡、长周期单卡或低资源、数小时级别迭代频率以周为单位以天为单位失败排查参数多定位难变更范围小更容易归因这不是说大模型方案已经过时而是说明不同目标应该匹配不同策略。如果你要做一个复杂的长程操作任务7B 级模型仍然有价值如果你要快速验证一个新任务、一个新数据集或者部署到一台边缘设备上小参数量更新的方案性价比高很多。2. 0.7% 参数、40% 提升、11 毫秒、6.5 小时每个数字都要拆开看2.1 0.7% 参数是“被更新参数”不是“模型总参数”这个数字很容易被误读。很多人看到“0.7% 参数”会以为团队训练了一个很小的模型实际上它更可能的意思是底座仍然是一个 7B 级预训练模型训练时冻结了绝大部分权重只更新很少一部分参数。0.7% 乘以 7B大约是 5000 万参数正好是 LoRA、Adapter 这类轻量适配模块的常见量级。为什么要强调这一点因为它直接决定了你对方法的理解。这项工作的核心不是“小模型打败大模型”而是“大模型的大部分知识已经够用机器人任务只需要在很小的参数空间内做对齐”。这就像你雇了一个懂很多知识的人来做一份新工作不需要重新教他所有知识只需要告诉他新岗位的流程和按钮在哪里。更新成本小改动范围小出问题也容易回滚。2.2 40% 性能提升怎么测、在什么任务上测比数字本身更重要“性能提升 40%”是整条标题里最需要打问号的地方。这个指标是任务成功率、平均完成距离、还是某个子任务得分基线用的是哪个版本的 7B 模型同一个任务在仿真和真机上结果可能差异巨大。测试时有没有固定随机种子重复跑了几次评估集和训练集是否重叠这些细节不明确的时候40% 只能当作“有条件的相对提升”不能当作“绝对性能”。我见过太多项目把一个论文里的成功率搬到自己环境里复现最后发现完全不是一回事。原因往往不是论文造假而是任务定义、机械臂型号、相机高度、光照条件、动作空间表示不一样哪怕差一点结果都会变。所以看到这种数字时更要看论文里的实验设置。如果实验设置公开完整你才有机会判断它是否适合你的场景如果只有一个结论没有细节那它更适合当作方向性参考而不是直接照搬。2.3 11 毫秒推理和 6.5 小时训练这两个数字放在一起意义更大单独看 11 毫秒只是一个“很快”的数字。单独看 6.5 小时也只是一个“不算久”的训练时间。但它们组合在一起意味着机器人学习的工作流发生了本质变化。11 毫秒大约对应 90Hz 左右的推理频率已经可以支持大部分机械臂的实时控制。6.5 小时训练意味着如果数据量不大单卡甚至中高端消费级显卡都有可能完成。一天之内你可以训练、评估、部署、实机测试晚上再根据结果调整数据第二天再来一轮。这种迭代速度以前需要一周现在可以压缩到一天。对一个做机器人项目的团队来说最贵的往往不是 GPU而是试错周期。周期越长你越不敢做激进尝试越容易停留在安全但平庸的方案上。训练时间缩短之后你才敢同时试多种数据增强、多种动作头结构、多种语言指令模板然后让数据告诉你哪种更好。3. 这类高效训练思路的“底层逻辑”3.1 冻结主干 轻量适配把预训练知识当成基础设施这种思路并不神秘。预训练视觉语言模型已经学了海量图像和文本对“什么是杯子”“什么是桌面”“什么是移动”有基本理解。机器人动作学习很多时候不是从零学起而是把已有的语义理解翻译成动作坐标。翻译过程只需要在输出端加一个动作头或者在下游加一个适配器。所以冻结主干、只训练少量参数不是偷懒而是对信息密度的判断主干里已有的通用特征足够强继续更新它边际收益很低还可能破坏已有能力。真正需要学的是“图像里这个目标在机器人坐标系中的位置以及怎么让它动起来”。这个逻辑在自然语言处理领域已经被验证过无数次。LoRA、Adapter 都是这个思路。机器人领域的 VLA 模型只是在输出空间上更特殊、实时要求更高。3.2 小参数量为什么能在大模型身上起作用低维更新空间能起作用的根本原因是预训练权重已经处在一个比较好的“特征盆地”附近。新任务只需要在当前权重附近做一个小的偏移而不是重新找一个权重点。更新参数少意味着对预训练特征的扰动小不容易灾难性遗忘同时在数据量不够大的机器人任务里小参数量也能降低过拟合风险。但这有一个前置条件底座模型的视觉语言能力要足够强。如果底座本身对“杯子”“抽屉”这些概念都理解不好那么即使只更新 0.7% 的参数也很难补救。换句话说这个方法的收益上限很大程度取决于底座模型的质量。3.3 训练时间短不等于训练简单6.5 小时是 GPU 计算时间。数据采集、清洗、动作对齐、超参数选择、仿真验证这些都不在 6.5 小时里。机器人数据尤其贵10 条有效轨迹可能比 100 条噪声数据更值钱。如果你手里的数据本身质量很差训练再快也只能快速得到一个不太能用的模型。所以不要把“训练时间短”等同于“整体开发成本低”。真正省下来的是算力和迭代等待时间但数据工程、任务设计、部署验证仍然要花心思。这也是为什么我建议不要一开始就急着冲批量数和并发数而要先建立一个小而干净的评测闭环。4. 如果你想复现类似流程从最小闭环开始4.1 环境准备与数据检查如果你也想在机器人任务里尝试“冻结大模型 只更新少量参数”的方案可以先从现有开源 VLA 或视觉语言底座开始。数据格式至少需要包含图像序列、语言指令、动作真值关节角度或末端位姿。开始训练前先检查三个最容易出问题的地方图像和指令是否在时间上对齐有没有某一帧指令和画面不对应动作单位是否统一有些数据是弧度有些是角度混在一起模型会学得很混乱指令文本是否覆盖你真正要部署的任务如果指令词汇和评测时差异太大效果很难稳定。数据检查这一步我一般建议单独写一个可视化脚本把图像、指令、动作同时打印出来看几段。不要只看数据统计要“人肉”确认数据是合理的。4.2 冻结大部分参数只训练动作头或适配器训练脚本的核心就是控制 requires_grad。你可以先用一个最小示例跑通流程# 示意结构冻结主干只更新动作头或适配器 for name, param in policy_model.named_parameters(): if action_head not in name and adapter not in name: param.requires_grad False optimizer torch.optim.AdamW( filter(lambda p: p.requires_grad, policy_model.parameters()), lr1e-4 )这只是一个通用示范。实际用哪个库、哪些层需要冻结取决于你选择的模型结构。重点是冻结范围不用一步到位可以先冻结全部只开一个动作头看看效果如果效果不理想再放开部分层。4.3 先小样本验证再扩大数据我不建议你第一次就跑完整实验。可以用 10 到 20 条轨迹先跑通整个训练流程观察 loss 是否下降、动作输出是否在合理范围、推理能不能跑起来。这个阶段不是为了拿到好效果而是为了确认流程没有断。一旦小样本流程稳定再逐步扩大到 50、100、200 条数据。每扩大一次都记录一组评测结果。这样如果中间出现效果下降你能快速定位是数据规模带来变化还是模型过拟合而不是一头雾水。不要一上来就把批量数和并发数拉满。先用一条样例确认输入、输出和日志都正常再慢慢加量。4.4 推理与部署检查如果你要复现“11 毫秒级”的推理就需要认真检查推理链路。通常这个级别的延迟依赖半精度、TensorRT、模型编译、固定输入分辨率等优化。原生 PyTorch 跑一个 7B 级模型很难达到这个速度。你需要确认模型权重是否转换为了半精度或 INT8是否使用了推理框架或模型编译器输入图像分辨率是否固定是否在预处理阶段耗时过多GPU 是否被其他任务占用有没有内存交换是否支持动态 batch还是固定 batch1 更稳。如果这些没确认直接把公开数字套到自己环境里很容易出现“说好的 11 毫秒实际跑了 200 毫秒”的差异。5. 最容易踩的坑别把论文数字当成你自己项目的效果5.1 数字适用的边界任何论文里的数字都是在一个具体环境中得出的。机器人领域尤其如此同一个模型换一个机械臂型号换一个相机高度换一个光照条件效果都可能完全不同。更常见的是那个 40% 的提升只在一个特定任务上成立换一个任务可能就没有优势甚至更差。所以更合适的做法是把公开工作当作“候选方案”而不是“必然结果”。你需要先在自己的小数据集上做一个快速验证确认它是否适合你的任务再决定要不要投入更多资源。5.2 排查链路训练、推理、部署分别查什么如果你的复现过程出现了问题不要只盯着模型参数调来调去。先按顺序排查效率会高很多现象优先排查项训练 loss 不降数据标签和图像是否对齐、学习率是否异常、动作范围是否归一化推理速度慢是否开启半精度/编译、输入分辨率是否过大、模型是否还在 CPU/GPU 间频繁拷贝动作输出异常数据坐标系是否统一、指令中是否有模型未见过词汇、是否过拟合训练集部署后实机抖动控制频率是否足够、输出动作是否经过平滑处理、是否超出机械臂限位训练快但评测差训练集和评测集是否同分布、随机种子是否固定、评测指标是否稳定这里最关键的是先确定“问题到底在哪一层”。数据层的问题再怎么调模型参数也没用推理层的问题再怎么换数据也解决不了。5.3 长期维护固定随机种子、记录实验版本、保留回滚能力机器人实验特别依赖可复现性。如果每次训练都随机抽样不固定 seed效果浮动会非常大你很难判断改动是变好了还是噪声。建议每个实验都记录数据集版本、随机种子、可训练参数范围、学习率、训练步数、评测脚本版本、硬件环境。这个习惯本质上是在给自己留后路。训练快是优势但没有版本管理的快只会让你更快地制造混乱。6. 这件事真正提醒我们的是什么这项研究值得关注的不是“0.7% 碾压 7B”这个传播叙事而是它展示了一个工作流用大模型做底座用小量可训练参数做任务对齐把训练和推理都压缩到能快速迭代的范围内。这套思路可以迁移到很多机器人操作和具身智能项目里。如果你正在做 VLA 相关项目第一步不是去找更大的模型而是先建立一个 10 条数据的评测小闭环。跑通之后再逐步加数据、调模块、做部署优化。先跑通再扩展最后再谈工程化。技术文章里的数字总会被传播简化。真正能留在手里的不是那串结果而是一套让自己快速试错、快速判断的方法。