当你在机器人项目里部署视觉-语言-动作模型Vision-Language-Action简称 VLA时最常见的困境往往不是模型不够聪明而是“模型太大带不动”。7B 级别的 VLA 在论文评测里表现好看但一旦放到机械臂控制器或移动机器人上立刻会遇到推理延迟高、显存不足、训练成本昂贵这几个现实问题。杨立昆团队近期公开的轻量 VLA 方案恰好切中这个痛点。从项目发布信息看有四个数字非常吸引人只用总参数中约 0.7% 的可训练参数就能让模型在评测任务上的表现相对提升约 40%整个训练过程只要 6.5 小时一次动作推理只需要 11 毫秒并且在多个基准任务上可以超越 7B 级别的公开 VLA 模型。这不是一篇单纯吹捧“小模型战胜大模型”的文章。我要做的是把这套方案里的工程思路拆开为什么只更新 0.7% 的参数效果反而能提升滑动窗口注意力在其中到底起了什么作用训练 6.5 小时、推理 11 毫秒这种数据对真正做机器人落地的工程师意味着什么这篇文章会从 VLA 的基础概念讲起逐步拆解参数效率、训练成本、推理延迟和工程选型。即使你不从事具身智能方向只看它如何用极小训练成本和极低推理成本撬动模型能力也值得认真了解一下。1. 为什么关注这项研究VLA 不是越大越好在 2024 年到 2025 年之间具身智能赛道经历了明显的“扩规模”趋势。OpenVLA、PaliGemma、LLaMA-Rider 这类模型普遍采用 7B 甚至更大的语言模型作为主干再接入视觉编码器和动作预测头。原因是 7B 模型拥有更强的世界常识、指令理解能力和多任务泛化能力在标准机器人操作评测集上确实能拿到比较高的分数。但这里有一个容易被忽略的问题机器人不是跑在大规模数据中心里的服务而是跑在机械臂控制器、移动底盘、边缘工控机上的物理系统。它需要实时闭环通常控制频率要求 10Hz 甚至更高它受限于成本和功耗不可能随时挂一张 A100它的动作数据收集成本极高不可能像互联网文本那样轻易获得海量样本。所以VLA 领域的核心矛盾不是“模型还能不能更大”而是“在算力有限、数据有限、实时性要求高的条件下模型还能不能足够好用”。这也是为什么杨立昆团队的这项研究会引起关注——它选择了一条完全不同的优化目标用最小可训练参数、最短训练时间、最低推理延迟去逼近甚至超过大模型的可用性能。如果你正在做以下事情这篇文章对你有实际参考价值机器人操作策略选型希望判断轻量级 VLA 是否够用。具身智能入门想弄明白 VLA 的常用架构和关键设计。边缘部署工程师关注模型推理延迟、内存占用和训练成本。研究参数高效微调方向希望对比不同微调策略的效果。换句话说这篇文章的读者不一定是算法研究员更多是那些需要在真实项目中把模型跑起来的人。2. VLA 基础概念视觉-语言-动作模型到底在做什么VLA 是一个典型的“多模态进、动作出”模型。它的输入通常是视觉信息机械臂第一视角或第三人称相机采集的图像。语言指令例如“把红色方块放到左边盒子里”。可选的机器人状态关节角度、夹爪开合状态、位姿信息等。输出则是机器人的动作。动作可以是连续参数比如末端执行器的位置增量、关节角速度也可以是离散 token比如“抬高手臂”“抓取物体”“向右移动 2 厘米”。从架构上看VLA 一般由三部分组成视觉编码器把图像转换为视觉特征向量常见的是 ViT 或 SigLIP 这类预训练视觉模型。语言模型主干把文本指令和视觉特征一起处理承担推理和决策工作。动作解码头把语言模型的输出映射为具体动作可以是一个 MLP 回归层也可以是离散动作 token 的分类层。理解这一点后你就能发现 VLA 和多模态大模型的核心区别多模态大模型最终生成的是自然语言回复而 VLA 最终生成的是可执行的动作指令。语言模型在这里被当成“动作推理器”使用既要理解场景又要根据指令输出行动。这也是 VLA 为什么依赖大语言模型的原因。真实世界中的操作任务往往需要常识推理比如“拿起杯子之前应该先确认杯子是空的”“螺丝刀要握住手柄而不是金属杆”。这些知识来自大规模文本预训练很难完全靠机器人操作数据习得。因此直接砍掉大模型主干、只留一个小网络并不现实。但问题也随之而来大模型主干带来了性能和推理能力也带来了推理延迟和训练成本。如何把这两者解耦就是这项研究最值得关注的地方。3. 从 7B 到轻量方案0.7% 参数和 40% 性能提升是怎么来的先把这个标题里最抓眼球的两个数字拆开看。第一0.7% 参数。这里说的不是把模型总参数压缩到原来的 0.7%而是指在训练过程中只有约 0.7% 的参数参与梯度更新。根据项目公开信息这套方案在预训练语言模型主干的 embedding 层和 LayerNorm 层上做自适应调整其他参数全部冻结。为什么选择 embedding 层和 LayerNorm 层从工程角度理解embedding 层是文本、图像、动作三种信息进入模型后的第一个交汇点。调整这个层相当于为当前机器人任务定制一个“语义映射器”让模型能更好对齐视觉指令、语言指令和动作空间。LayerNorm 层控制特征分布。每一层 LayerNorm 的缩放和偏移参数都能对整体特征流产生全局影响。微调这些参数相当于在全模型范围内做了一次轻量级的“分布适配”。这种做法的好处很明显主干模型的参数完全冻结训练时不需要为主干保存梯度显存占用大幅下降同时主干模型原本具备的世界常识和语言表达能力被完整保留不会因为微调数据量少而“灾难性遗忘”。第二40% 性能提升。需要说明的是这里的 40% 是相对提升不是绝对成功率提升。假设某个任务原来的基础成功率约 50%相对提升 40% 后大约到 70%如果基础成功率本身就低于 10%相对提升 40% 后的绝对数字依然不高。从公开消息看该方案在 MMBT、LIBERO 这类机器人操作基准上相比同参数规模的其他轻量模型取得了更明显优势并且在部分任务上超过了 7B 级 VLA。这里真正值得关注的不是“超越 7B”这个结论而是它证明了“参数效率”和“能力上限”并不冲突。微调少量参数不一定就代表能力弱关键看微调的是哪些参数、数据组织是否合理、注意力机制是否高效。很多人会拿它和 LoRA 做对比。LoRA 的思路也是冻结主干、训练低秩矩阵同样属于参数高效微调而这套方案更进一步不引入额外低秩矩阵直接调整原生网络中本来就存在的 embedding 和 LayerNorm 参数。从模型部署角度看少了一组额外矩阵推理时不需要额外合并权重维护成本更低。4. 架构设计拆解滑动窗口注意力与轻量自适应从公开资料看这套方案的核心设计有两个轻量自适应层和滑动窗口注意力。先说滑动窗口注意力。传统自回归语言模型在生成动作 token 时一般会处理整段上下文包括所有历史输入。这在长对话任务中没问题但在机器人任务中会造成严重浪费一个机械臂连续执行 10 分钟任务如果每预测一步动作都要重新处理过去几分钟的图像和历史动作 token计算量会随任务时间线性增长延迟也会不可控地拉高。滑动窗口注意力的思路是当前动作的预测只依赖最近一段窗口内的视觉信息、文本指令和过去若干步动作。窗口之外的旧信息在注意力计算中不再参与。这样每一步前向计算的长度被限定在固定大小以内不会因任务执行时间变长而退化。这种做法还带来了一个额外收益限制上下文长度实际上也限制了模型对历史错误的依赖。如果模型在第 20 步动作执行失误传统注意力机制在后续预测中仍然要“盯着”这个错误历史而滑动窗口机制会在窗口滚动后逐渐丢掉旧信息相当于给了模型一定的“自我纠错”空间。再说轻量自适应。它体现在两个层面参数层面前面说过只有 embedding 层和 LayerNorm 层可训练数量占比约 0.7%。激活层面根据项目描述并不是所有主干参数都需要为当前动作预测参与计算。它通过设计让部分与当前动作无关的 token 不进入完整的注意力计算流程实际参与计算和存储的参数约为总量的 70%。这个“参数使用率”概念非常值得留意。传统 7B 模型跑一次推理无论输入多短基本都要加载全部 7B 参数到显存计算所有层的完整矩阵乘。而这套方案通过动态裁剪输入 token 和注意力计算范围让实际计算量远低于“全参数全上下文”的理论值。这也是 11 毫秒推理能实现的重要前提。当然这种设计不是没有代价。滑动窗口注意力要求开发者对“窗口长度”有合理设置。窗口太短模型看不到足够的历史上下文容易动作不连贯窗口太长计算量增加延迟上升。落地时通常需要针对具体任务做一次窗口长度调优。5. 训练过程与数据6.5 小时背后的关键设计训练时间是很多团队最敏感的工程指标。项目描述里“6.5 小时完成训练”这个数字放在 VLA 领域确实相当激进。常规做法是拿 7B 模型做全量微调至少需要在 8 卡 A100 上训练数天即使用 LoRA也需要几十个小时。这套方案能把训练压到 6.5 小时核心原因是训练过程中要更新梯度的参数太少。模型的 embedding 层和 LayerNorm 层参数量占比很小训练时不需要对主干全量参数计算梯度反向传播的计算量和显存占用都大幅下降。与此同时由于参与梯度更新的参数少优化器状态占用的显存也少训练时可以使用更大的 batch size 和更长的训练步数在同样时间内看到更多样本。在数据层面VLA 训练通常包含两类监督信号一类是视觉语言任务监督让模型理解图像和指令的含义另一类是动作监督让模型学会把语义理解转化为具体动作。公开材料里提到这套方案在机器人操作数据集上做了多任务训练同时对动作 token 做了类似“动作-属性映射”的时间步聚合处理让离散的动作 token 能更好对齐到当前任务进度上。这里我更想强调的是工程层面的启发训练成本不只是算力成本更是迭代成本。6.5 小时和 6.5 天差别不只是电费和 GPU 占用而是团队每天的迭代次数。一个实验跑 6.5 小时意味着当天就能看到结果、调整数据、继续下一轮实验一个实验跑 6.5 天意味着每周只能做少量实验试错空间大大缩小。对研究团队和创业团队来说这种成本差异可以直接决定项目推进速度。下面用一个最小示例演示“冻结主干、只训练少量层”的训练代码结构。这里以 Hugging Face Transformers 框架为例演示如何筛选出可训练参数这也是理解该方案训练成本的关键。# 文件路径train_fast_style_vla.py # 演示一个典型的“只更新 embedding 层与 LayerNorm 层”训练参数设置 import torch from transformers import AutoModelForCausalLM # 这里替换为你实际使用的 VLM 基座模型路径 model AutoModelForCausalLM.from_pretrained( your_base_vlm_path, torch_dtypetorch.bfloat16, ) # 冻结所有参数然后只放开 embedding 和 LayerNorm for name, param in model.named_parameters(): is_embedding embed_tokens in name or embedding in name is_layer_norm layer_norm in name or layernorm in name or ln_ in name if is_embedding or is_layer_norm: param.requires_grad True else: param.requires_grad False # 查看可训练参数比例 total_params sum(p.numel() for p in model.parameters()) trainable_params sum(p.numel() for p in model.parameters() if p.requires_grad) print(ftotal params: {total_params / 1e6:.2f}M) print(ftrainable params: {trainable_params / 1e6:.2f}M) print(ftrainable ratio: {trainable_params / total_params * 100:.3f}%)这段代码的关键逻辑是遍历模型所有参数根据参数名判断它是否属于 embedding 或 LayerNorm然后设置requires_grad。训练时优化器只接收requires_gradTrue的参数因此反向传播不会为主干参数计算梯度。实际项目中这个筛选逻辑要结合具体模型的参数命名规则来调整。不同模型的 embedding 层命名可能不同比如model.embed_tokens、model.vision_embed_tokens、model.language_model.embed_tokens等。建议在写训练脚本前先打印一遍model.named_parameters()确认命名规则再写过滤条件。训练完成后保存模型时也应只保存可训练参数避免保存数十 GB 的全量主干预训练权重。推理平台加载冻结主干的预训练权重后再叠加你训练出来的少量参数即可。6. 推理性能分析11 毫秒意味着什么在机器人控制场景中模型单次推理延迟直接决定了控制闭环能否跑起来。11 毫秒这个数字换算成频率大约是 90Hz。对机械臂力控、移动机器人避障这类典型任务来说这个控制频率已经进入了“可用”区间甚至超出部分传统视觉伺服方案的水平。作为对比主流 7B VLA 在单张云端加速卡上做单次动作预测延迟通常在数百毫秒到一秒级别。这个延迟如果直接放在真机闭环里机器人实际反应速度会明显滞后只能用于“感知 - 规划 - 执行”的慢速任务很难支撑精细操作。为什么 11 毫秒有可能实现结合前面几章的拆解主要有三个原因序列缩短滑动窗口注意力限制了每一步输入的序列长度前向计算不再是全上下文扫描。计算裁剪与当前动作无关的 token 不参与完整注意力计算实际参与计算的参数被控制在约 70%。动作解码轻量化语言模型主干生成的 token 数量很少不需要像通用对话模型那样生成长篇回复。另外要提醒的是11 毫秒是一个在特定测试环境下得到的数字通常对应单张云端加速卡、batch size 为 1 的推理条件。真实机器人上还会受到图像采集、预处理、系统调度、模型编译方式的影响。实际部署时应该把整个“摄像头采集 - 图像预处理 - 模型推理 - 动作解析 - 控制指令下发”的链路延迟一起测量而不是只测模型前向时间。下面给出一个典型的模型推理测时脚本帮助你评估自己的 VLA 模型在目标硬件上的真实延迟。# 文件路径benchmark_inference.py # 演示用 CUDA Event 统计模型前向推理平均耗时 import torch def benchmark_step(model, inputs, warmup5, repeat50): model.eval() # 先跑几轮 warmup避免显存分配和算子预热影响计时 for _ in range(warmup): with torch.no_grad(): _ model(**inputs) start_events [torch.cuda.Event(enable_timingTrue) for _ in range(repeat)] end_events [torch.cuda.Event(enable_timingTrue) for _ in range(repeat)] with torch.no_grad(): for i in range(repeat): start_events[i].record() _ model(**inputs) end_events[i].record() torch.cuda.synchronize() times [s.elapsed_time(e) for s, e in zip(start_events, end_events)] avg_ms sum(times) / len(times) print(faverage inference time: {avg_ms:.2f} ms)测时的时候有几个容易踩坑的点必须做 warmup。第一次调用模型会触发 CUDA kernel 加载和显存分配不含 warmup 的测时数据会失真。GPU 计时必须同步。如果不调用torch.cuda.synchronize()拿到的只是任务提交时间不是实际完成时间。要监控显存占用。VLA 推理不仅关心延迟还关心是否放得下。可以用torch.cuda.max_memory_allocated()统计峰值显存。7. 与主流 VLA 方案的对比与选型建议为了把轻量 VLA 的定位讲清楚这里给出一个与主流方案的对比。需要说明的是具体参数、训练时间和延迟会随版本、硬件和实现方式变化表中的数字主要反映常见公开测试状态实际以官方发布为准。方案主干规模微调方式训练成本推理延迟典型适用场景OpenVLA约 7B全量/部分微调多卡数天数百毫秒级对成功率要求高、不要求高实时性的研究PaliGemma 系列约 3B-7B全量/全参数微调多卡数天数百毫秒级通用视觉语言任务可改造为动作任务LLaMA-Rider约 7BSFT / RL多卡数天数百毫秒级游戏环境、具身智能研究本文讨论的轻量 VLA约 1-4B 级主干仅训练少量层单卡数小时10ms 级别实时性要求高的机器人部署这个表格不是直接比较“谁更强”而是想说明选型时必须考虑的维度第一训练成本。如果你所在的团队没有多卡训练条件比如只有一两张消费级或单卡云端 GPU那么尝试全量微调 7B 模型会非常吃力而单卡数小时这种训练成本意味着个人开发者和中小团队也具备实验条件。第二推理延迟。如果目标是部署在实体机械臂上且要求 20Hz 以上的控制频率那么数百毫秒延迟的 7B 方案几乎不可用。轻量模型虽然不是所有任务都能赢过 7B但在实时闭环这一项上有决定性优势。第三任务复杂度。如果任务是长时程、多阶段、强常识推理的移动操作任务7B 模型的语义理解能力仍然有价值。轻量 VLA 更适合任务边界较清晰、控制频率要求高、场景相对固定的场景。我的选型建议是不要先看模型发布会而是先回答三个问题——你的机器人平台允许的最大推理延迟是多少你的训练资源能支撑多少天一轮实验你的任务中语义推理占比高还是实时控制占比高答案会直接把你推向大模型路线或轻量路线。8. 落地实践快速评估与最小闭环示例如果你看完前面几章想知道“我能不能快速跑通这套思路”这里给出一个最小闭环路径。第一步准备数据。VLA 训练需要至少包含图像、指令文本、动作标签的数据集。可以先用公开机器人操作数据集验证流程比如 LIBERO 或 MMBT 的子集再逐步替换成自己采集的真机数据。第二步确定基座模型。选择一个支持视觉语言输入的开源基座模型比如某些多模态 LLaVA 风格的模型或者以语言模型为主干、额外接入视觉编码器。尽量选择已发布权重、社区资料较多的模型这样调试更容易。第三步冻结主干只训练 embedding 和 LayerNorm。这一步对应前面第 5 章的代码示例。第四步在仿真环境中验证。先在仿真器里跑通回合制评估统计成功率确认模型确实从“随机水平”提升到“策略水平”。仿真环境能节省大量真机调试时间。第五步真机小规模验证。先把动作频率和限制器跑起来再逐步放开控制权限。真机环境务必加装安全限位和急停逻辑不能让模型未经验证就直接控制机械臂。下面是一个简化版 VLA 推理函数的示例展示“图像 指令 - 动作文本”的基本流程。# 文件路径vla_inference.py # 演示VLA 推理中的基础预处理与动作解析流程 import torch def predict_action(model, processor, image, instruction, max_new_tokens16): model.eval() # 将指令文本和图像统一编码为模型输入 inputs processor( textinstruction, imagesimage, return_tensorspt, paddingTrue, ).to(model.device) # 控制生成长度VLA 只需要生成动作 token不需要长文本 with torch.no_grad(): output_ids model.generate( **inputs, max_new_tokensmax_new_tokens, do_sampleFalse, ) action_text processor.decode(output_ids[0], skip_special_tokensTrue) return parse_action(action_text)这里有个工程细节值得注意max_new_tokens不要设置太大。VLA 不需要模型生成完整自然语言说明只需要输出动作参数。如果生成长度过长既浪费推理时间又容易在连续动作输出中混入无关文本导致动作解析异常。动作解析函数parse_action需要结合你的动作空间来写。连续动作可以解析为浮点数列表离散动作可以解析为预定义动作原语的索引。解析逻辑必须在训练和推理阶段保持一致否则模型输出的动作文本无法正确落到控制层。9. 常见问题与排查思路下面这组问题是我结合 VLA 项目落地中比较常见的问题整理的适用于大多数轻量 VLA 工程。问题现象可能原因排查方式解决方案微调后效果还不如不微调动作空间与模型 token 映射不一致数据集标签错误打印推理输出检查动作 token 与标签对齐情况统一动作空间编码清洗数据集推理延迟远高于 11ms输入序列过长视觉编码器成为瓶颈未使用推理优化打印各模块耗时检查输入 token 长度缩短窗口长度对视觉编码器做量化或裁剪训练显存仍然不足基座模型加载占用高优化器状态过多未开启梯度检查点监控显存峰值检查参与梯度更新的参数数量开启 gradient checkpointing使用 bf16只保存可训练参数模型动作输出不稳定动作 token 生成长度过长解码策略使用采样检查生成参数查看完整输出文本设置较短 max_new_tokens使用贪心解码仿真成功率高但真机失败sim-to-real gap视觉域差异控制频率不足对比仿真与真机图像分布记录真机实际延迟使用域随机化提高推理吞吐增加视觉数据增强模型在长任务后期行为异常滑动窗口长度设计不合理因果上下文丢失分析任务中期输出检查窗口覆盖范围调大窗口长度或增加关键状态记忆机制这里要重点说下“训练显存仍然不足”的问题。很多人以为只训练 0.7% 参数显存需求就会非常小。实际上模型加载后主干权重本身就占据大量显存即使冻结参数不需要保存梯度前向计算的过程激活值仍然存在。因此真正落地时仍然建议使用 bf16、梯度检查点并选择尽可能小的基座模型。另外在真机部署前一定要记录模型版本、训练数据版本、关键超参和推理延迟指标。机器人项目出问题时最让人头疼的往往不是模型本身而是无法判断现场表现对应的是哪一版模型、哪一批数据。把这些运行信息固化下来排障效率会高很多。10. 最佳实践与工程建议这里给出几条对实际项目更有帮助的工程建议。第一动作空间设计要尽量统一。VLA 模型对动作 token 的语义非常敏感。如果你今天用关节角度表示动作明天换成末端执行器位姿模型需要重新学习一套映射关系。建议在项目开始前就确定动作空间并在所有数据集中保持统一。第二窗口长度应该作为关键超参来调。滑动窗口注意力虽然高效但窗口长度直接决定模型能看多远的“过去”。建议在验证集上做一次窗口长度扫描观察成功率随窗口长度的变化曲线找到性能与延迟的平衡点。第三训练过程和推理过程要使用同一套预处理。包括图像尺寸、归一化方式、指令模板、动作文本格式。预处理不一致是最容易被忽视的部署事故来源。第四部署时加入动作限制器。VLA 模型的输出可能出现越界值或不合理动作。在控制层必须加物理限位比如关节角度范围、末端速度上限、夹爪力矩限制。不要直接信任神经网络输出这是机器人安全的基本底线。第五建立从仿真到真机的渐进式验证流程。不要跳过仿真直接上真机也不要在仿真里反复过拟合。推荐的顺序是仿真小任务验证 - 仿真多任务泛化 - 真机单任务验证 - 真机多任务验证。每一步都设定明确的成功率门槛下一个阶段只在前一个阶段通过后启动。第六关注失效模式而不是平均成功率。机器人在真实场景中平均成功率不是唯一指标。某个托盘操作任务的平均成功率是 80%但如果失败模式集中在“夹爪过度用力压碎目标物体”这个风险在工业生产中就是不可接受的。建议额外统计失败类型的分布针对性补充数据或增加后处理规则。11. 总结与后续学习方向杨立昆团队的这项轻量 VLA 方案本质上是在回答一个问题在真实物理条件下我们需要多大的模型才够用它的答案是不一定需要 7B更关键的是“在合适的位置做精准调整”。0.7% 的可训练参数、6.5 小时的训练时间、11 毫秒的推理延迟这三个数字互相配合把 VLA 从“实验室研究品”往“可实际部署产品”的方向推进了一大步。对开发者的启发是参数高效微调不只是为了省算力更是一种系统设计思路。它意味着你可以更快地试错更快地收集数据反馈更快地把模型部署到边缘设备上。这种迭代速度在具身智能这种“数据贵、实验贵、试错成本高”的领域里价值可能比单点精度提升更大。这篇文章从 VLA 基础概念、参数机制、滑动窗口注意力、训练成本、推理性能到工程选型做了比较完整的拆解。如果你想继续深入下一步可以从这几个方向展开一是阅读该方案的完整论文和公开代码理解滑动窗口注意力与动作 token 的具体实现二是尝试在 LIBERO 或 MMBT 这类公开数据集上复现一个轻量训练流程三是研究 LoRA、层归一化微调、提示微调等方法在机器人任务上的横向对比。最后提醒一点尽量用低成本手段先验证“任务是否适合 VLA”再考虑扩大模型规模。对一个控制频率要求高的固定场景任务轻量模型往往是更稳妥的起点对一个需要丰富常识推理的开放世界任务再考虑回到 7B 级方案。工程选型不是比谁参数多而是比谁更适合自己的约束条件。 
长河君 · 2026/8/29 3:56:19 · 阅读 1.2k 轻量VLA：0.7%参数训练、11毫秒推理的机器人部署新方案
当你在机器人项目里部署视觉-语言-动作模型Vision-Language-Action简称 VLA时最常见的困境往往不是模型不够聪明而是“模型太大带不动”。7B 级别的 VLA 在论文评测里表现好看但一旦放到机械臂控制器或移动机器人上立刻会遇到推理延迟高、显存不足、训练成本昂贵这几个现实问题。杨立昆团队近期公开的轻量 VLA 方案恰好切中这个痛点。从项目发布信息看有四个数字非常吸引人只用总参数中约 0.7% 的可训练参数就能让模型在评测任务上的表现相对提升约 40%整个训练过程只要 6.5 小时一次动作推理只需要 11 毫秒并且在多个基准任务上可以超越 7B 级别的公开 VLA 模型。这不是一篇单纯吹捧“小模型战胜大模型”的文章。我要做的是把这套方案里的工程思路拆开为什么只更新 0.7% 的参数效果反而能提升滑动窗口注意力在其中到底起了什么作用训练 6.5 小时、推理 11 毫秒这种数据对真正做机器人落地的工程师意味着什么这篇文章会从 VLA 的基础概念讲起逐步拆解参数效率、训练成本、推理延迟和工程选型。即使你不从事具身智能方向只看它如何用极小训练成本和极低推理成本撬动模型能力也值得认真了解一下。1. 为什么关注这项研究VLA 不是越大越好在 2024 年到 2025 年之间具身智能赛道经历了明显的“扩规模”趋势。OpenVLA、PaliGemma、LLaMA-Rider 这类模型普遍采用 7B 甚至更大的语言模型作为主干再接入视觉编码器和动作预测头。原因是 7B 模型拥有更强的世界常识、指令理解能力和多任务泛化能力在标准机器人操作评测集上确实能拿到比较高的分数。但这里有一个容易被忽略的问题机器人不是跑在大规模数据中心里的服务而是跑在机械臂控制器、移动底盘、边缘工控机上的物理系统。它需要实时闭环通常控制频率要求 10Hz 甚至更高它受限于成本和功耗不可能随时挂一张 A100它的动作数据收集成本极高不可能像互联网文本那样轻易获得海量样本。所以VLA 领域的核心矛盾不是“模型还能不能更大”而是“在算力有限、数据有限、实时性要求高的条件下模型还能不能足够好用”。这也是为什么杨立昆团队的这项研究会引起关注——它选择了一条完全不同的优化目标用最小可训练参数、最短训练时间、最低推理延迟去逼近甚至超过大模型的可用性能。如果你正在做以下事情这篇文章对你有实际参考价值机器人操作策略选型希望判断轻量级 VLA 是否够用。具身智能入门想弄明白 VLA 的常用架构和关键设计。边缘部署工程师关注模型推理延迟、内存占用和训练成本。研究参数高效微调方向希望对比不同微调策略的效果。换句话说这篇文章的读者不一定是算法研究员更多是那些需要在真实项目中把模型跑起来的人。2. VLA 基础概念视觉-语言-动作模型到底在做什么VLA 是一个典型的“多模态进、动作出”模型。它的输入通常是视觉信息机械臂第一视角或第三人称相机采集的图像。语言指令例如“把红色方块放到左边盒子里”。可选的机器人状态关节角度、夹爪开合状态、位姿信息等。输出则是机器人的动作。动作可以是连续参数比如末端执行器的位置增量、关节角速度也可以是离散 token比如“抬高手臂”“抓取物体”“向右移动 2 厘米”。从架构上看VLA 一般由三部分组成视觉编码器把图像转换为视觉特征向量常见的是 ViT 或 SigLIP 这类预训练视觉模型。语言模型主干把文本指令和视觉特征一起处理承担推理和决策工作。动作解码头把语言模型的输出映射为具体动作可以是一个 MLP 回归层也可以是离散动作 token 的分类层。理解这一点后你就能发现 VLA 和多模态大模型的核心区别多模态大模型最终生成的是自然语言回复而 VLA 最终生成的是可执行的动作指令。语言模型在这里被当成“动作推理器”使用既要理解场景又要根据指令输出行动。这也是 VLA 为什么依赖大语言模型的原因。真实世界中的操作任务往往需要常识推理比如“拿起杯子之前应该先确认杯子是空的”“螺丝刀要握住手柄而不是金属杆”。这些知识来自大规模文本预训练很难完全靠机器人操作数据习得。因此直接砍掉大模型主干、只留一个小网络并不现实。但问题也随之而来大模型主干带来了性能和推理能力也带来了推理延迟和训练成本。如何把这两者解耦就是这项研究最值得关注的地方。3. 从 7B 到轻量方案0.7% 参数和 40% 性能提升是怎么来的先把这个标题里最抓眼球的两个数字拆开看。第一0.7% 参数。这里说的不是把模型总参数压缩到原来的 0.7%而是指在训练过程中只有约 0.7% 的参数参与梯度更新。根据项目公开信息这套方案在预训练语言模型主干的 embedding 层和 LayerNorm 层上做自适应调整其他参数全部冻结。为什么选择 embedding 层和 LayerNorm 层从工程角度理解embedding 层是文本、图像、动作三种信息进入模型后的第一个交汇点。调整这个层相当于为当前机器人任务定制一个“语义映射器”让模型能更好对齐视觉指令、语言指令和动作空间。LayerNorm 层控制特征分布。每一层 LayerNorm 的缩放和偏移参数都能对整体特征流产生全局影响。微调这些参数相当于在全模型范围内做了一次轻量级的“分布适配”。这种做法的好处很明显主干模型的参数完全冻结训练时不需要为主干保存梯度显存占用大幅下降同时主干模型原本具备的世界常识和语言表达能力被完整保留不会因为微调数据量少而“灾难性遗忘”。第二40% 性能提升。需要说明的是这里的 40% 是相对提升不是绝对成功率提升。假设某个任务原来的基础成功率约 50%相对提升 40% 后大约到 70%如果基础成功率本身就低于 10%相对提升 40% 后的绝对数字依然不高。从公开消息看该方案在 MMBT、LIBERO 这类机器人操作基准上相比同参数规模的其他轻量模型取得了更明显优势并且在部分任务上超过了 7B 级 VLA。这里真正值得关注的不是“超越 7B”这个结论而是它证明了“参数效率”和“能力上限”并不冲突。微调少量参数不一定就代表能力弱关键看微调的是哪些参数、数据组织是否合理、注意力机制是否高效。很多人会拿它和 LoRA 做对比。LoRA 的思路也是冻结主干、训练低秩矩阵同样属于参数高效微调而这套方案更进一步不引入额外低秩矩阵直接调整原生网络中本来就存在的 embedding 和 LayerNorm 参数。从模型部署角度看少了一组额外矩阵推理时不需要额外合并权重维护成本更低。4. 架构设计拆解滑动窗口注意力与轻量自适应从公开资料看这套方案的核心设计有两个轻量自适应层和滑动窗口注意力。先说滑动窗口注意力。传统自回归语言模型在生成动作 token 时一般会处理整段上下文包括所有历史输入。这在长对话任务中没问题但在机器人任务中会造成严重浪费一个机械臂连续执行 10 分钟任务如果每预测一步动作都要重新处理过去几分钟的图像和历史动作 token计算量会随任务时间线性增长延迟也会不可控地拉高。滑动窗口注意力的思路是当前动作的预测只依赖最近一段窗口内的视觉信息、文本指令和过去若干步动作。窗口之外的旧信息在注意力计算中不再参与。这样每一步前向计算的长度被限定在固定大小以内不会因任务执行时间变长而退化。这种做法还带来了一个额外收益限制上下文长度实际上也限制了模型对历史错误的依赖。如果模型在第 20 步动作执行失误传统注意力机制在后续预测中仍然要“盯着”这个错误历史而滑动窗口机制会在窗口滚动后逐渐丢掉旧信息相当于给了模型一定的“自我纠错”空间。再说轻量自适应。它体现在两个层面参数层面前面说过只有 embedding 层和 LayerNorm 层可训练数量占比约 0.7%。激活层面根据项目描述并不是所有主干参数都需要为当前动作预测参与计算。它通过设计让部分与当前动作无关的 token 不进入完整的注意力计算流程实际参与计算和存储的参数约为总量的 70%。这个“参数使用率”概念非常值得留意。传统 7B 模型跑一次推理无论输入多短基本都要加载全部 7B 参数到显存计算所有层的完整矩阵乘。而这套方案通过动态裁剪输入 token 和注意力计算范围让实际计算量远低于“全参数全上下文”的理论值。这也是 11 毫秒推理能实现的重要前提。当然这种设计不是没有代价。滑动窗口注意力要求开发者对“窗口长度”有合理设置。窗口太短模型看不到足够的历史上下文容易动作不连贯窗口太长计算量增加延迟上升。落地时通常需要针对具体任务做一次窗口长度调优。5. 训练过程与数据6.5 小时背后的关键设计训练时间是很多团队最敏感的工程指标。项目描述里“6.5 小时完成训练”这个数字放在 VLA 领域确实相当激进。常规做法是拿 7B 模型做全量微调至少需要在 8 卡 A100 上训练数天即使用 LoRA也需要几十个小时。这套方案能把训练压到 6.5 小时核心原因是训练过程中要更新梯度的参数太少。模型的 embedding 层和 LayerNorm 层参数量占比很小训练时不需要对主干全量参数计算梯度反向传播的计算量和显存占用都大幅下降。与此同时由于参与梯度更新的参数少优化器状态占用的显存也少训练时可以使用更大的 batch size 和更长的训练步数在同样时间内看到更多样本。在数据层面VLA 训练通常包含两类监督信号一类是视觉语言任务监督让模型理解图像和指令的含义另一类是动作监督让模型学会把语义理解转化为具体动作。公开材料里提到这套方案在机器人操作数据集上做了多任务训练同时对动作 token 做了类似“动作-属性映射”的时间步聚合处理让离散的动作 token 能更好对齐到当前任务进度上。这里我更想强调的是工程层面的启发训练成本不只是算力成本更是迭代成本。6.5 小时和 6.5 天差别不只是电费和 GPU 占用而是团队每天的迭代次数。一个实验跑 6.5 小时意味着当天就能看到结果、调整数据、继续下一轮实验一个实验跑 6.5 天意味着每周只能做少量实验试错空间大大缩小。对研究团队和创业团队来说这种成本差异可以直接决定项目推进速度。下面用一个最小示例演示“冻结主干、只训练少量层”的训练代码结构。这里以 Hugging Face Transformers 框架为例演示如何筛选出可训练参数这也是理解该方案训练成本的关键。# 文件路径train_fast_style_vla.py # 演示一个典型的“只更新 embedding 层与 LayerNorm 层”训练参数设置 import torch from transformers import AutoModelForCausalLM # 这里替换为你实际使用的 VLM 基座模型路径 model AutoModelForCausalLM.from_pretrained( your_base_vlm_path, torch_dtypetorch.bfloat16, ) # 冻结所有参数然后只放开 embedding 和 LayerNorm for name, param in model.named_parameters(): is_embedding embed_tokens in name or embedding in name is_layer_norm layer_norm in name or layernorm in name or ln_ in name if is_embedding or is_layer_norm: param.requires_grad True else: param.requires_grad False # 查看可训练参数比例 total_params sum(p.numel() for p in model.parameters()) trainable_params sum(p.numel() for p in model.parameters() if p.requires_grad) print(ftotal params: {total_params / 1e6:.2f}M) print(ftrainable params: {trainable_params / 1e6:.2f}M) print(ftrainable ratio: {trainable_params / total_params * 100:.3f}%)这段代码的关键逻辑是遍历模型所有参数根据参数名判断它是否属于 embedding 或 LayerNorm然后设置requires_grad。训练时优化器只接收requires_gradTrue的参数因此反向传播不会为主干参数计算梯度。实际项目中这个筛选逻辑要结合具体模型的参数命名规则来调整。不同模型的 embedding 层命名可能不同比如model.embed_tokens、model.vision_embed_tokens、model.language_model.embed_tokens等。建议在写训练脚本前先打印一遍model.named_parameters()确认命名规则再写过滤条件。训练完成后保存模型时也应只保存可训练参数避免保存数十 GB 的全量主干预训练权重。推理平台加载冻结主干的预训练权重后再叠加你训练出来的少量参数即可。6. 推理性能分析11 毫秒意味着什么在机器人控制场景中模型单次推理延迟直接决定了控制闭环能否跑起来。11 毫秒这个数字换算成频率大约是 90Hz。对机械臂力控、移动机器人避障这类典型任务来说这个控制频率已经进入了“可用”区间甚至超出部分传统视觉伺服方案的水平。作为对比主流 7B VLA 在单张云端加速卡上做单次动作预测延迟通常在数百毫秒到一秒级别。这个延迟如果直接放在真机闭环里机器人实际反应速度会明显滞后只能用于“感知 - 规划 - 执行”的慢速任务很难支撑精细操作。为什么 11 毫秒有可能实现结合前面几章的拆解主要有三个原因序列缩短滑动窗口注意力限制了每一步输入的序列长度前向计算不再是全上下文扫描。计算裁剪与当前动作无关的 token 不参与完整注意力计算实际参与计算的参数被控制在约 70%。动作解码轻量化语言模型主干生成的 token 数量很少不需要像通用对话模型那样生成长篇回复。另外要提醒的是11 毫秒是一个在特定测试环境下得到的数字通常对应单张云端加速卡、batch size 为 1 的推理条件。真实机器人上还会受到图像采集、预处理、系统调度、模型编译方式的影响。实际部署时应该把整个“摄像头采集 - 图像预处理 - 模型推理 - 动作解析 - 控制指令下发”的链路延迟一起测量而不是只测模型前向时间。下面给出一个典型的模型推理测时脚本帮助你评估自己的 VLA 模型在目标硬件上的真实延迟。# 文件路径benchmark_inference.py # 演示用 CUDA Event 统计模型前向推理平均耗时 import torch def benchmark_step(model, inputs, warmup5, repeat50): model.eval() # 先跑几轮 warmup避免显存分配和算子预热影响计时 for _ in range(warmup): with torch.no_grad(): _ model(**inputs) start_events [torch.cuda.Event(enable_timingTrue) for _ in range(repeat)] end_events [torch.cuda.Event(enable_timingTrue) for _ in range(repeat)] with torch.no_grad(): for i in range(repeat): start_events[i].record() _ model(**inputs) end_events[i].record() torch.cuda.synchronize() times [s.elapsed_time(e) for s, e in zip(start_events, end_events)] avg_ms sum(times) / len(times) print(faverage inference time: {avg_ms:.2f} ms)测时的时候有几个容易踩坑的点必须做 warmup。第一次调用模型会触发 CUDA kernel 加载和显存分配不含 warmup 的测时数据会失真。GPU 计时必须同步。如果不调用torch.cuda.synchronize()拿到的只是任务提交时间不是实际完成时间。要监控显存占用。VLA 推理不仅关心延迟还关心是否放得下。可以用torch.cuda.max_memory_allocated()统计峰值显存。7. 与主流 VLA 方案的对比与选型建议为了把轻量 VLA 的定位讲清楚这里给出一个与主流方案的对比。需要说明的是具体参数、训练时间和延迟会随版本、硬件和实现方式变化表中的数字主要反映常见公开测试状态实际以官方发布为准。方案主干规模微调方式训练成本推理延迟典型适用场景OpenVLA约 7B全量/部分微调多卡数天数百毫秒级对成功率要求高、不要求高实时性的研究PaliGemma 系列约 3B-7B全量/全参数微调多卡数天数百毫秒级通用视觉语言任务可改造为动作任务LLaMA-Rider约 7BSFT / RL多卡数天数百毫秒级游戏环境、具身智能研究本文讨论的轻量 VLA约 1-4B 级主干仅训练少量层单卡数小时10ms 级别实时性要求高的机器人部署这个表格不是直接比较“谁更强”而是想说明选型时必须考虑的维度第一训练成本。如果你所在的团队没有多卡训练条件比如只有一两张消费级或单卡云端 GPU那么尝试全量微调 7B 模型会非常吃力而单卡数小时这种训练成本意味着个人开发者和中小团队也具备实验条件。第二推理延迟。如果目标是部署在实体机械臂上且要求 20Hz 以上的控制频率那么数百毫秒延迟的 7B 方案几乎不可用。轻量模型虽然不是所有任务都能赢过 7B但在实时闭环这一项上有决定性优势。第三任务复杂度。如果任务是长时程、多阶段、强常识推理的移动操作任务7B 模型的语义理解能力仍然有价值。轻量 VLA 更适合任务边界较清晰、控制频率要求高、场景相对固定的场景。我的选型建议是不要先看模型发布会而是先回答三个问题——你的机器人平台允许的最大推理延迟是多少你的训练资源能支撑多少天一轮实验你的任务中语义推理占比高还是实时控制占比高答案会直接把你推向大模型路线或轻量路线。8. 落地实践快速评估与最小闭环示例如果你看完前面几章想知道“我能不能快速跑通这套思路”这里给出一个最小闭环路径。第一步准备数据。VLA 训练需要至少包含图像、指令文本、动作标签的数据集。可以先用公开机器人操作数据集验证流程比如 LIBERO 或 MMBT 的子集再逐步替换成自己采集的真机数据。第二步确定基座模型。选择一个支持视觉语言输入的开源基座模型比如某些多模态 LLaVA 风格的模型或者以语言模型为主干、额外接入视觉编码器。尽量选择已发布权重、社区资料较多的模型这样调试更容易。第三步冻结主干只训练 embedding 和 LayerNorm。这一步对应前面第 5 章的代码示例。第四步在仿真环境中验证。先在仿真器里跑通回合制评估统计成功率确认模型确实从“随机水平”提升到“策略水平”。仿真环境能节省大量真机调试时间。第五步真机小规模验证。先把动作频率和限制器跑起来再逐步放开控制权限。真机环境务必加装安全限位和急停逻辑不能让模型未经验证就直接控制机械臂。下面是一个简化版 VLA 推理函数的示例展示“图像 指令 - 动作文本”的基本流程。# 文件路径vla_inference.py # 演示VLA 推理中的基础预处理与动作解析流程 import torch def predict_action(model, processor, image, instruction, max_new_tokens16): model.eval() # 将指令文本和图像统一编码为模型输入 inputs processor( textinstruction, imagesimage, return_tensorspt, paddingTrue, ).to(model.device) # 控制生成长度VLA 只需要生成动作 token不需要长文本 with torch.no_grad(): output_ids model.generate( **inputs, max_new_tokensmax_new_tokens, do_sampleFalse, ) action_text processor.decode(output_ids[0], skip_special_tokensTrue) return parse_action(action_text)这里有个工程细节值得注意max_new_tokens不要设置太大。VLA 不需要模型生成完整自然语言说明只需要输出动作参数。如果生成长度过长既浪费推理时间又容易在连续动作输出中混入无关文本导致动作解析异常。动作解析函数parse_action需要结合你的动作空间来写。连续动作可以解析为浮点数列表离散动作可以解析为预定义动作原语的索引。解析逻辑必须在训练和推理阶段保持一致否则模型输出的动作文本无法正确落到控制层。9. 常见问题与排查思路下面这组问题是我结合 VLA 项目落地中比较常见的问题整理的适用于大多数轻量 VLA 工程。问题现象可能原因排查方式解决方案微调后效果还不如不微调动作空间与模型 token 映射不一致数据集标签错误打印推理输出检查动作 token 与标签对齐情况统一动作空间编码清洗数据集推理延迟远高于 11ms输入序列过长视觉编码器成为瓶颈未使用推理优化打印各模块耗时检查输入 token 长度缩短窗口长度对视觉编码器做量化或裁剪训练显存仍然不足基座模型加载占用高优化器状态过多未开启梯度检查点监控显存峰值检查参与梯度更新的参数数量开启 gradient checkpointing使用 bf16只保存可训练参数模型动作输出不稳定动作 token 生成长度过长解码策略使用采样检查生成参数查看完整输出文本设置较短 max_new_tokens使用贪心解码仿真成功率高但真机失败sim-to-real gap视觉域差异控制频率不足对比仿真与真机图像分布记录真机实际延迟使用域随机化提高推理吞吐增加视觉数据增强模型在长任务后期行为异常滑动窗口长度设计不合理因果上下文丢失分析任务中期输出检查窗口覆盖范围调大窗口长度或增加关键状态记忆机制这里要重点说下“训练显存仍然不足”的问题。很多人以为只训练 0.7% 参数显存需求就会非常小。实际上模型加载后主干权重本身就占据大量显存即使冻结参数不需要保存梯度前向计算的过程激活值仍然存在。因此真正落地时仍然建议使用 bf16、梯度检查点并选择尽可能小的基座模型。另外在真机部署前一定要记录模型版本、训练数据版本、关键超参和推理延迟指标。机器人项目出问题时最让人头疼的往往不是模型本身而是无法判断现场表现对应的是哪一版模型、哪一批数据。把这些运行信息固化下来排障效率会高很多。10. 最佳实践与工程建议这里给出几条对实际项目更有帮助的工程建议。第一动作空间设计要尽量统一。VLA 模型对动作 token 的语义非常敏感。如果你今天用关节角度表示动作明天换成末端执行器位姿模型需要重新学习一套映射关系。建议在项目开始前就确定动作空间并在所有数据集中保持统一。第二窗口长度应该作为关键超参来调。滑动窗口注意力虽然高效但窗口长度直接决定模型能看多远的“过去”。建议在验证集上做一次窗口长度扫描观察成功率随窗口长度的变化曲线找到性能与延迟的平衡点。第三训练过程和推理过程要使用同一套预处理。包括图像尺寸、归一化方式、指令模板、动作文本格式。预处理不一致是最容易被忽视的部署事故来源。第四部署时加入动作限制器。VLA 模型的输出可能出现越界值或不合理动作。在控制层必须加物理限位比如关节角度范围、末端速度上限、夹爪力矩限制。不要直接信任神经网络输出这是机器人安全的基本底线。第五建立从仿真到真机的渐进式验证流程。不要跳过仿真直接上真机也不要在仿真里反复过拟合。推荐的顺序是仿真小任务验证 - 仿真多任务泛化 - 真机单任务验证 - 真机多任务验证。每一步都设定明确的成功率门槛下一个阶段只在前一个阶段通过后启动。第六关注失效模式而不是平均成功率。机器人在真实场景中平均成功率不是唯一指标。某个托盘操作任务的平均成功率是 80%但如果失败模式集中在“夹爪过度用力压碎目标物体”这个风险在工业生产中就是不可接受的。建议额外统计失败类型的分布针对性补充数据或增加后处理规则。11. 总结与后续学习方向杨立昆团队的这项轻量 VLA 方案本质上是在回答一个问题在真实物理条件下我们需要多大的模型才够用它的答案是不一定需要 7B更关键的是“在合适的位置做精准调整”。0.7% 的可训练参数、6.5 小时的训练时间、11 毫秒的推理延迟这三个数字互相配合把 VLA 从“实验室研究品”往“可实际部署产品”的方向推进了一大步。对开发者的启发是参数高效微调不只是为了省算力更是一种系统设计思路。它意味着你可以更快地试错更快地收集数据反馈更快地把模型部署到边缘设备上。这种迭代速度在具身智能这种“数据贵、实验贵、试错成本高”的领域里价值可能比单点精度提升更大。这篇文章从 VLA 基础概念、参数机制、滑动窗口注意力、训练成本、推理性能到工程选型做了比较完整的拆解。如果你想继续深入下一步可以从这几个方向展开一是阅读该方案的完整论文和公开代码理解滑动窗口注意力与动作 token 的具体实现二是尝试在 LIBERO 或 MMBT 这类公开数据集上复现一个轻量训练流程三是研究 LoRA、层归一化微调、提示微调等方法在机器人任务上的横向对比。最后提醒一点尽量用低成本手段先验证“任务是否适合 VLA”再考虑扩大模型规模。对一个控制频率要求高的固定场景任务轻量模型往往是更稳妥的起点对一个需要丰富常识推理的开放世界任务再考虑回到 7B 级方案。工程选型不是比谁参数多而是比谁更适合自己的约束条件。