VLA视觉-语言-动作模型的效率问题最近又有一条值得关注的信息杨立昆团队用极小的参数规模在机器人操作任务上取得了对比 7B 级 VLA 模型更快的推理和更低的训练成本。按标题给出的口径参数只有对比模型的 0.7%性能提升 40%推理耗时约 11 毫秒训练只要 6.5 小时。这条信息最值得看的不是又有一个大模型而是小参数模型开始挑战大模型。机器人领域里VLA 的核心问题一直是实时性和可用性。7B 级模型即使效果不错放到机械臂或者移动机器人上推理延迟和显存占用很容易变成瓶颈。如果小参数方案能在多个任务上稳定复现对端侧部署、实时控制和成本控制都有直接参考价值。不过先提醒一句0.7% 参数、40% 提升、11 毫秒、6.5 小时这些数字都是有前提的。它们来自特定任务集、特定硬件、特定评测协议。我们看这类工作要先搞清楚它省在哪、赢在哪、以及能不能在你自己环境里复现。下面按背景 - 可能的实现路线 - 评测方法 - 落地取舍 - 复现步骤 - 排错的顺序拆一遍。1. VLA 模型的效率问题为什么值得认真关注1.1 VLA 是什么7B 级模型卡在哪里VLA 的全称是 Vision-Language-Action Model输入端是图像或视频和语言指令输出端是机器人动作。它把视觉理解、语义理解和动作生成放在同一个模型里。比如你给机器人一张桌面图片告诉它把红色方块放到蓝色区域VLA 需要自己理解物体位置、指令含义再输出一个可执行的动作。这类模型早期思路是把视觉编码器和语言模型拼接起来再用大量操作数据微调。OpenVLA 这类常见工作的主干规模在 7B 参数级别原因是它直接借用通用 LLM 的语言理解能力。这个思路效果不差但到了真实设备上会碰到几个硬问题显存占用高消费级显卡甚至边缘设备装不下推理延迟大机械臂需要 10 到 30Hz 的实时控制7B 级模型很难稳定满足训练成本高全量微调需要多卡和大量数据。所以在机器人项目里VLA 的能不能用往往不只看效果还要看延迟、显存、功耗和部署难度。这就是小参数 VLA 工作引起关注的原因它试图把模型压到能上设备、能实时跑、能快速重新训练的水平。1.2 小参数方案动了哪些大头一个典型 VLA 的参数量主要分布在三块视觉编码器、语言或序列骨干、动作输出头。7B 模型里语言骨干通常占大部分参数。小参数方案如果想省参数量通常会在三块里做文章。第一种做法是砍掉通用语言骨干改用更小的 Transformer 或直接用视觉 token 到动作 token 的映射结构。第二种做法是保留一个小型语言模型但冻结大部分参数只训练动作头和少量适配层。第三种做法是走蒸馏路线让大模型在数据上生成动作标签或中间特征再训练一个很小的学生模型。这些做法并不互斥实际项目里经常组合使用。比如冻结预训练视觉编码器用小 Transformer 做序列建模动作头用连续回归而不是逐 token 生成这样参数总量就明显下降。1.3 0.7% 参数这个口径应该怎么理解0.7% 是一个需要先定义清楚的口径。它可能指相比 7B 模型新模型总参数只占 0.7%即大约 49M 参数也可能指只训练了 0.7% 的参数其余冻结例如在 7B 模型上做 LoRA。这两种含义差别很大。如果它是总参数占比那这个模型规模大约在几千万参数的量级确实属于小模型。如果它是可训练参数占比那模型本身可能还是 7B只是微调成本低推理成本不一定低。所以在看这条信息时不能只记住 0.7% 这个数字还要回去查原文的参数到底指什么。否则你很容易产生小模型一定低延迟的误解最后部署时发现显存和速度并不符合预期。2. 从大 VLA 到小 VLA可能的压缩路线拆解2.1 知识蒸馏让小模型学大模型的决策分布第一条常见路线是知识蒸馏。做法是先有一个大 VLA 作为教师模型在大量操作轨迹上生成动作分布、中间特征或伪标签然后让一个小模型去拟合这些输出。这里的关键不是让学生模型背答案而是学习教师模型的决策倾向。很多机器人动作任务里同一个场景有多个合法动作直接拿人工标注的单一动作做监督小模型很难学出泛化能力。用教师模型输出分布做软标签小模型更容易学到任务层面的偏好。蒸馏的难点在于数据生成。你需要先保证教师模型的输出质量足够高否则学生模型只会学到错误行为。同时要考虑动作空间的分布是否连续。如果是连续动作软标签可以用高斯分布的均值和方差来表达但落到部署代码时要小心维度不匹配。2.2 冻结主干、只训练动作头省参数最直接的方式第二种路线是参数冻结。视觉编码器和小语言骨干直接用开源预训练权重不更新只训练一个从中间特征到动作空间的映射头。这样一来可训练参数占比会非常小训练时间和显存占用也会明显下降。这个方案的好处是复现快训练 6.5 小时这个量级很可能是冻结主干 小动作头或LoRA 小动作头的配置。坏处是性能上限受预训练特征制约。如果预训练主干没有见过机器人第一视角图像或者语言指令风格差异大可能效果不稳定。所以冻结方案通常要配一部分机器人数据做适配或者注入少量可训练 adapter。2.3 低秩适配与紧凑 Transformer常见但要看实现LoRA 这类低秩适配方法在 LLM 微调里已经很常见VLA 上也可以做。它在冻结权重旁边插入低秩矩阵训练时只更新插入部分。相比全量微调显存和训练时间大幅下降但推理时通常需要把低秩矩阵合并回原权重最终推理参数量还是原来的规模延迟并不会因为训练参数少而下降。如果换用紧凑 Transformer 或专门设计的动作 Transformer情况就不一样。它不用承载 7B 级语言的庞大参数可以把序列长度缩短、隐藏层减少、注意力头减少。这样总参数和推理延迟都可能真正降下来。不过这种结构需要更多前期设计不是随便把 LLM 换成小 Transformer 就能保证效果。我建议在看这类工作时先确认0.7%是训练参数还是总参数再确认11 毫秒是压缩后模型跑的延迟还是压缩前大模型在某种配置下的延迟。这两点不区分开很容易高估或低估方案价值。2.4 不能只看参数百分比还要看任务集和动作空间参数少说明不了所有问题。一个在单臂桌面操作任务上表现好的小 VLA放到双机械臂、移动操作、长程多步任务里可能完全不同。判断这类方案强弱要重点看三个维度任务集是否多样动作空间是离散还是连续评测环境是真实设备还是仿真。如果只在单一仿真任务上提升 40%代入真实场景之前要打很大折扣。如果动作空间是离散按键而不是连续六自由度位姿工程上也不能直接迁移。所以我在博客里看到这类标题一般会先往下翻实验设置。没有明确任务集和基线定义的性能提升只能当作参考信号不能当作可复现结论。3. 11 毫秒推理和 6.5 小时训练这些数字怎么验证3.1 先确认推理耗时的测量边界11 毫秒这个数如果不定义清楚几乎没法对比。它到底是从摄像头拿到图像开始算还是从模型拿到预处理好的张量开始算是单步动作解码时间还是包含多步自回归是 BF16 还是 INT8是在 A100、H100、L4、4090 还是边缘设备上测的正确的测量方式应该是先拆链路图像采集、图像预处理、token 化、模型前向、动作解析、指令发送到执行器。每一段单独计时再算端到端耗时。我一般在真实项目里会测五个数值单次前向 p50、单次前向 p95、端到端 p50、端到端 p95、稳定运行时的峰值显存。下面是一个通用的测量伪流程不是某个框架的真代码但实现时要按这个思路去走。import time # 假设已有模型对象 model数据预处理函数 preprocess动作解析函数 postprocess # 先预热模型加载、显存分配、算子编译都需要时间 warm_up 10 runs 30 for i in range(warm_up runs): # 每次都用新的输入数据避免缓存影响 obs get_observation() # 获取当前图像/指令 tensor preprocess(obs) # 缩放、归一化、token化 if i warm_up: start time.perf_counter() action model.predict(tensor) # 模型前向推理 if i warm_up: end time.perf_counter() record_time((end - start) * 1000) parsed_action postprocess(action)注意两件事。第一要等模型真正完成预热再开始计时否则第一次调用会把算子编译和显存分配时间算进去第二不能只用一次测量机器人输入是连续流抖动比平均延迟更影响控制。至少统计 20 次以上取 p50 和 p95。3.2 6.5 小时训练需要什么硬件和数据规模训练时间同样需要问清楚用了多少张卡是 A100、H100、L40S 还是消费级显卡数据量是多少条轨迹序列长度多长是否冻结主干从6.5 小时这个量级推断它大概率不是从零预训练一个全新 VLA而是在已有视觉模型或语言模型主干上做适配。比如冻结视觉编码器用几天数据训练一个小 Transformer单卡或双卡确实可能跑完。但如果你要复现训练时间直接受 GPU 型号和数据量影响不能拿6.5 小时当绝对标准。更合理的评估方式是把训练成本换算成 GPU·小时。6.5 小时在 1 张卡上是 6.5 GPU·小时在 8 张卡上是 52 GPU·小时两者成本差别很大。如果原始材料没有提供硬件型号我会先按单卡高端训练卡来估算然后根据你的设备重新规划。注意训练时间至少要结合 GPU 卡型、卡数、batch size 和数据量一起看。单卡 6.5 小时和八卡 6.5 小时是完全不同的成本。3.3 复现时要对比的指标不止准确率如果想把这类方案用在自己的机器人任务上不能只对比一个成功率。建议至少建立四类指标任务成功率、端到端延迟、训练显存峰值、部署显存峰值。有条件再加一个换场景泛化率比如换背景、换光照、换物体位置后成功率下降多少。指标测量口径重点关注任务成功率同一任务集多轮取平均单轮成功不算稳定端到端延迟图像采集到动作输出包含预处理和后处理推理延迟模型前向单次耗时预热后取 p50/p95训练显存峰值训练脚本中的显存最大值冻结主干与全量微调差异很大部署显存峰值推理脚本中的显存最大值和模型文件大小不是一回事泛化率换背景、光照、物体位置小模型对分布变化更敏感只有这组指标都记录完整才能判断小参数方案是不是真的适合你。否则会出现一种情况成功率提升了但延迟不稳定或者训练很快但推理显存仍然超限。3.4 一套可操作的小规模验证流程我建议用三轮测试来验证不要一步到位。第一轮单条任务冒烟测试。加载模型运行一次推理确认能输出合法动作观察显存和耗时。第二轮小批量离线测试。准备 50 条带标签轨迹跑一遍成功率顺便统计 p50/p95 延迟。第三轮真实设备或仿真闭环测试。把模型接入控制器跑连续多轮任务关注失败重试、长程一致性和稳定性。这三轮通过后再考虑并发、批处理、量化、多进程部署。按这个顺序走能少踩很多在看起来能跑和真正能用之间的坑。4. 从研究结果到落地部署资源、并发和稳定性怎么取舍4.1 显存和内存小参数不等于低占用很多人看到0.7% 参数就觉得显存一定很低这个想法要修正。显存占用不仅和参数有关还和推理时的激活值、中间缓存、图像 token 数量有关。一个 50M 参数的模型如果输入分辨率很高图像 patch 数很大或者序列长度很长显存峰值同样可能到几 GB只是比 7B 小很多。部署时要测的是峰值显存而不是模型文件大小。我一般在固定 batch size 下跑一次批量推理再监控 nvidia-smi 里的 max 值。如果峰值超过目标设备容量优先降低分辨率或缩短序列长度而不是急着换更小的模型。4.2 吞吐量与并发11 毫秒单次和连续执行是两回事11 毫秒如果是单次前向延迟那它只说明单帧动作很快。但机器人任务往往需要连续决策一秒钟可能需要 10 到 30 次推理。如果每次都要单独传输图像、单独跑预处理CPU 侧开销可能比 GPU 前向时间还高。所以真正要关注的是稳态吞吐。测试时应该连续运行数十秒甚至几分钟观察每秒能完成多少次有效推理以及延迟是否稳定。不能从一次 11 毫秒推导出一秒能跑 90 次因为中间还有数据采集、线程调度、同步锁、显存分配等开销。4.3 批量任务、长序列和失败重试如果你要做批量离线推理比如给一批历史轨迹重新标注动作要额外考虑三件事输入队列怎么组织输出文件怎么命名失败任务怎么重试。批量任务不建议用循环串行跑因为一旦某个样本卡住后面全部受影响。我会先把所有输入路径读进一个队列每个任务单独写日志超时或者异常的任务标记为 failed最后统一重跑。输出命名要包含任务 ID 和时间戳避免覆盖。这个思路和小模型本身没有直接关系但部署后很容易成为效率瓶颈。4.4 传感器输入和输出执行器的兼容性VLA 不是独立软件它要接真实传感器和执行器。图像分辨率、相机内参、机械臂自由度、动作范围这些外部条件都会影响模型能不能复现论文结果。小参数模型对输入分布更敏感因为它的容量有限没有大模型那种强行记住各种分布的余量。如果你的相机视角和训练数据差别大或者动作空间归一化方式不同成功率很可能会下降。项目落地前要专门留一部分真实数据做适配甚至做增量训练而不是直接加载权重就上机械臂。4.5 量化与部署框架的选择如果目标设备不是数据中心显卡而是 Jetson、工控机或者机器人控制器量化通常是绕不开的一步。小参数模型量化比大模型更容易因为权重本身少INT8 量化对精度的损失更可控。但要注意量化后的算子不一定都能跑到加速硬件的满速要先在目标设备上重新测延迟和显存。我通常不建议一开始就量化。先把未量化模型放上目标设备测出真实瓶颈再用量化解决显存或带宽问题。直接跳到量化会引入新的排查变量一旦效果变差你很难判断是模型容量问题还是量化误差问题。5. 如果你的机器人项目要试这条路线建议从哪几步开始5.1 第一步固定任务集和评测基线先不问模型多强先问评测怎么做。建议把任务定义成输入图像 指令 - 输出动作序列并固定评测环境。我一般会先选一两个简单任务做基线比如把物体推到目标位置和抓取指定物体。记录人工规则或大模型在相同任务上的成功率、平均耗时和失败类型。没有基线任何提升 40%都无从比较。5.2 第二步先跑通一个最小样例在拿到开源模型或者论文代码后先不要改任何论文超参数用最小输入跑一次前向。最小样例的目标不是效果好而是确认环境依赖、权重加载、图像预处理、动作输出格式都没问题。这一步最容易出现的问题是依赖版本冲突。Transformer 版本、torch 版本、tokenizer 版本不同哪怕模型权重不变输出也可能有细微差异。我会用固定版本号和 requirements 文件把环境锁死。5.3 第三步先调数据质量再调模型结构很多项目上来就想改模型结构、加注意力模块我建议反过来。先用默认结构把训练数据质量提上去。检查图像裁剪是否把目标物体截掉了指令文本是否统一动作标签是否对齐到每一帧有没有异常抖动或静默段。数据干净以后再决定要不要改模型。对于小参数 VLA数据质量对最终效果的影响通常大于结构改动。因为模型容量有限它没有能力把错误标签自动纠正过来。5.4 第四步把日志、输出目录和版本固定下来训练和推理都需要完整记录数据集版本、预训练权重版本、模型配置、超参数、GPU 型号、依赖版本、评测脚本版本、评测时间戳。不要用final_model.pth这种命名容易覆盖。我见过很多复现失败最后发现不是模型问题而是训练时用的数据目录已经更新过。版本管理在 VLA 这类项目里不是可选项而是第一优先级。5.5 如何判断该继续调参还是换基线如果做了两轮数据清洗和参数调整成功率仍然明显低于大模型或人工规则问题可能出在模型容量和任务复杂度上。这时候不要无限调参建议回到任务拆分把任务拆成感知定位 - 运动规划 - 动作执行三部分分别看小模型在哪一步丢失信息。如果丢在感知考虑换更强的视觉编码器或者提高图像分辨率如果丢在动作映射考虑换动作头结构或增加训练数据如果丢在长程规划再强的小模型也难单靠参数量解决要考虑外挂规划器或状态机。6. 这类小参数调优最容易踩的坑和排查顺序6.1 先别急着怪模型检查输入和预处理复现结果异常时我排查顺序固定是输入 - 环境 - 参数 - 模型。输入里最容易出问题的是三处图像尺寸是不是被强制 resize 到不符合模型预期的值图像归一化参数是不是和训练时一致语言指令是不是被 tokenizer 切出多余字符。这三处任何一个不一致成功率都会明显下降而且不报错。6.2 训练不掉点/不收敛时先看数据还是先看超参数如果训练 loss 不降先看数据本身。检查 label 是不是有大量 NaN动作值是否超出预设范围正负样本是否严重失衡。数据没问题再去看学习率、batch size、梯度裁剪和混合精度。小参数模型尤其容易遇到模型容量不够导致 loss 卡住的现象这不一定是超参数问题。如果训练集很大但模型很小loss 收敛到某个平台后不再变化优先增加数据多样性比加参数更有效。6.3 推理速度慢逐层测别只看总耗时推理慢要先拆时间。图像解码和 resize 通常在 CPU 上进行可能比 GPU 前向还慢。token 化、模型前向、动作后处理、机械臂驱动每个环节都要单独计时。最后往往发现瓶颈在数据预处理或通信而不是模型本身。可以用 profiling 工具或者手动打点。如果真是模型前向慢再考虑降低输入分辨率、缩短序列长度、量化、批量处理。6.4 一些更偏部署的边界提醒我最后压几条边界提醒。第一论文里的 11 毫秒可能是模型前向的纯 GPU 时间不包含通信和预处理部署时端到端延迟可能翻几倍。第二训练 6.5 小时看的是训练成本不代表你推理时能一直维持这个速度。第三小参数模型的泛化边界比大模型更明显换一个环境往往需要增量训练。第四评测成功率时要多跑几轮单次成功不能代表稳定。注意如果你准备在真实机械臂上复现一定不要把仿真结果直接当作真实结果。仿真环境中的观测干净、动作误差小真实场景的摩擦力、相机噪声和延迟都会让成功率明显下降。这些提醒不是否定小参数 VLA 的价值而是希望你在转述和复现时先把口径和条件对齐。0.7% 参数、40% 提升、11 毫秒推理、6.5 小时训练如果每一项都有清晰定义这套方案在机器人项目里就很有吸引力。如果没有定义清楚那就先按我上面的流程做一轮小规模验证再下结论。