做机器人操作模型的团队这两年大概都绕不开同一个词VLA也就是 Vision-Language-Action Model。我自己的项目 nextVLA 也在这个赛道上折腾了大半年从最初的调研、拆解公开方案到确定自己的骨干网络中间踩了不少坑。这个系列我打算开一篇架构设计的博文第一篇就先聚焦在最核心的部分——VLA 骨干的拆解与选型。这篇内容适合两类人看一类是刚入门、想搞清楚 VLA 内部到底怎么工作的同学另一类是已经在做机器人学习、正纠结怎么设计自己的骨干网络的工程师。我会把 nextVLA 在架构层面的取舍、具体实现和踩坑经验全部展开来讲不会只停留在概念层面。VLA 这个概念本身不算复杂把视觉、语言、动作三部分塞进一个大模型里输入是图像和指令输出是动作。但复杂全藏在骨干网络的设计里。视觉信息怎么编码语言指令怎么和视觉特征对齐动作又该怎么从模型里吐出来每一步都是选择题。而我做 nextVLA 的第一原则是不要为了追新而追新每一个设计都要能在实验里说清楚收益。这篇文章就是围绕这个原则展开的。1. VLA骨干到底在拆什么先看清整体架构很多刚接触 VLA 的人会把它想象成一个黑盒输图进指令咔嚓一下出来动作。但真到自己搭建的时候才发现这个黑盒的内部结构决定了一切。先放下具体模块我们从整体上把 VLA 骨干拆成三段看。1.1 从三段式机器人系统到端到端 VLA 的演变传统机器人操作系统是典型的感知-规划-控制三段式感知模块输出物体位姿规划模块算轨迹控制模块做跟踪。这套架构最大的问题是每一段都要单独设计和调参而且感知误差会一级一级传下去到控制层已经被放得很大。VLA 的思路是把这三段压缩成一个模型。模型的输入是相机图像和自然语言指令输出直接是动作序列。这样做的好处很明显中间没有显式的状态估计模块模型通过海量数据自己学到什么样的视觉特征组合对应什么样的动作。但压缩不等于消失。我拆 nextVLA 的时候还是会把骨干分成三块来审视视觉编码器负责把图像变成特征LLM 主干负责做多模态推理动作头负责把推理结果变成可执行的动作。分块审视不是要回到三段式而是为了在调试的时候能定位问题——比如模型能听懂指令但动作乱大概率问题出在动作头而不是 LLM 主干。1.2 两条技术路线自回归动作token与连续动作回归现在公开的 VLA 骨干基本可以归成两条路线。第一条是自回归的路线。代表工作是像 RT-2 那一派把动作也变成离散 token让模型像生成文本一样逐个生成动作 token。这个路线的好处是训练非常稳定因为整体就是一个标准的 causal LM 训练框架loss 就是下一个 token 预测的交叉熵。但缺点也很明显动作是连续量离散化之后精度受限尤其在做精细插孔、装配这类任务时256 个 bin 的粗糙程度会直接反映在成功率上。第二条是连续动作回归。模型在 LLM 的 backbone 之上接一个回归头直接输出连续的动作值或者动作 chunk。OpenVLA 早期走的是动作 token 化但后来很多工作都在往连续回归转。再往后业界把 diffusion policy 和 flow matching 引入动作头动作输出从直接回归一个点变成了回归一个动作分布采样。我在 nextVLA 里最终选择了连续动作路线动作头用流匹配来做这个后面详细展开。1.3 nextVLA 架构层面最初的取舍项目刚起步时我做了一张表来对比不同骨干方案的组合核心考量是三个维度训练稳定性、动作精度、推理速度。方案组合训练稳定性动作精度推理速度适合场景全自回归 token 化动作高中低慢通用 VLA 研究粗糙操作自回归语义 连续动作头中高中高中大多数桌面操作任务自回归语义 流匹配动作专家中高高中nextVLA 的选择精细操作最终选的是第三种组合视觉编码器 LLM 主干负责语义理解与任务推理动作部分单独用一个流匹配专家模块而不是让 LLM 一个词一个词地挤动作。这样设计的主要原因后面会讲简单说是为了在动作精度和训练稳定性之间找到平衡。2. 骨干每一段都是关键视觉编码器、LLM主干与动作头整体框架定下来之后接下来就是逐段拆解。这三段里每一段单独拎出来都有很多可以展开的设计细节而它们之间的接口设计往往比模块本身更容易翻车。2.1 视觉编码器怎么选从能看懂到看得准VLA 的视觉编码器承担的任务比纯 VLM 更重。VLM 只需要理解图像内容然后生成文本描述而 VLA 需要从图像里提取出与动作强相关的空间信息——物体在哪里、朝向如何、抓手离目标还有多远。这就要求视觉特征保留足够的空间分辨率。我第一次做 nextVLA 原型时直接用了一个现成的 CLIP 视觉塔特征直接送进 LLM。结果在仿真任务里效果还行但换到真实世界就露馅了模型经常认得出物体是什么却抓不准物体在哪。问题就出在 CLIP 的特征更偏向语义空间定位信息不够细致。后来我改成 SigLIP 这类视觉编码器并且加了中间层的特征融合情况才好转。现在很多公开 VLA 工作也都在用 SigLIP 作为默认视觉塔不是没有原因的。另外还有一个关键选择视觉编码器要不要冻结。如果项目数据量不大我建议微调但要用小学习率。数据集够大的话视觉塔微调带来的收益会很明显尤其当你的任务分布和预训练数据差异较大时。我实测下来在单个任务上微调视觉塔能带来 5-10 个百分点的成功率提升。2.2 LLM 主干尺寸、上下文与指令注入方式LLM 主干是整个 VLA 的大脑。它要同时干两件事理解语言指令结合视觉特征做任务推理。骨干选多大直接决定显存占用和训练成本。nextVLA 目前用的是 7B 级别的视觉语言模型作为主干。这个体量是我反复权衡后的结果再小一些比如 1-3B推理能力和指令跟随能力明显下降复杂指令经常执行错再大一些比如 13B、34B性能提升是有的但训练和推理成本飙升对机器人侧的实时性不友好。7B 在目前来看是性价比最高的区间。指令注入方式也值得注意。最常见的做法是把指令文本和图像 token 拼成一个序列送进 LLM。这里有个隐含问题图像 token 数量越多指令文本在注意力中的相对权重就越低。所以早期我试过在指令后面重复指令文本、或者加特殊的指令 token来强化指令的引导作用。这些 trick 单个看提升不大但叠加起来对长程任务的稳定性有帮助。2.3 动作头从分类到回归再到流匹配动作头是我在 nextVLA 里改动最多的部分。动作头解决的根本问题是如何把 LLM 最后一层的隐藏状态映射成机器人能够执行的关节位置或末端位姿。最早我尝试了离散动作 token原因很直接和 LLM 的预训练目标对齐训练稳定。但我立刻碰到了精度天花板。在仿真里做抓取这类大动作没问题换到插孔这类需要毫米级精度的任务就崩了。离散化本质上是给动作加了噪声且这个噪声不可控。后来我切换到连续回归输出动作 chunk也就是一次性预测未来几十步的动作轨迹。相比自回归一个 token 一个 token 地挤动作 chunk 有两个好处一是避免了误差累积二是给底层控制器更长的前瞻窗口。但连续回归也有自己的毛病多峰问题。同样的场景下机器人的最优动作可能有多种直接回归一个均值会把多峰分布平滑掉了动作看起来犹豫且抖动。最后的解决方案是流匹配动作专家。流匹配的思路很简洁不直接回归动作点而是学习从噪声分布到动作分布的映射推理时从噪声采样并在几步内去噪得到动作。这个方案在动作多样性和稳定性之间取得了很好的平衡。我测试下来在精细操作任务上对比连续回归成功率有明显提升。3. 数据与训练nextVLA 的骨干如何真正跑起来架构设计得再好训练跑不起来或者效果不稳都是白搭。VLA 和普通语言模型最大的不同在于训练数据的组织方式——你需要同时管理图像、语言、动作三条流且三条流在时序上要严格对齐。3.1 训练数据从哪来真实数据、仿真数据和开源数据nextVLA 的训练数据来自三个渠道各自承担不同角色。第一个渠道是真实遥操作数据。这是最重要的数据来源。我们用主从遥操作设备采集真实操作数据包含多种工具、多种物体、多种桌面布局。真实数据的优势是域内分布准确模型学到的策略直接可用缺点是采集成本高一个熟练的操作员一天能采集的有效轨迹也就几百条。第二个渠道是仿真数据。仿真用来做规模化扩充我用仿真环境批量生成任务场景自动标注成功/失败再导出轨迹。仿真的优势是便宜和量大但存在 sim-to-real gap。我的经验是仿真数据占比不要超过 30%否则模型会学到很多仿真特有的视觉假象。第三个渠道是开源数据集。像 Open X-Embodiment 这类跨机构数据集可以直接拿来做预训练。开源数据的好处是覆盖面广能提升模型的泛化能力缺点是数据质量参差不齐、动作空间不一致。我通常只拿它做骨干的冷启动预训练然后用自采数据微调。3.2 训练阶段设计先对齐、再预训练、最后微调VLA 的训练不是一次到位而是分阶段进行。我在 nextVLA 里分了三步走。第一步多模态对齐预训练。用大规模图文数据和开源机器人数据把视觉编码器、LLM 主干和动作头初步对齐。这一阶段的目的是让模型先学会看图说话建立起视觉与语言之间的基本映射。第二步动作预训练。结合动作数据让模型学会从指令和图像预测动作。这一阶段重点是让 LLM 主干去适应动作任务本身。和纯文本预训练不同VLA 的动作目标函数和文本目标函数存在冲突因此要在 loss 上做权重平衡。我的经验是动作 loss 权重需要从 0.1 开始缓慢爬坡快速拉高会导致语言能力退化。第三步策略微调。用目标任务域的精细数据做微调把模型收敛到具体任务上。这一步学习率要比预训练低一个数量级而且要加入早停策略防止过拟合。实测下来分阶段训练比直接端到端混合训练收敛速度快了将近一倍最终效果也更稳定。3.3 显存、吞吐与训练稳定性VLA 骨干训练最现实的痛点是显存。7B 模型微调加上视觉分支和动作分支单卡很容易 OOM。我的做法是三个并行策略gradient checkpointing、LoRA 微调、混合精度训练。Gradient checkpointing 用计算换显存是默认开启的。LoRA 微调只更新低秩适配器能省掉大量优化器状态。实测下来4 张 80G 的卡可以比较流畅地跑 7B 骨干加流匹配动作头的训练。吞吐量方面一个经常被忽视的瓶颈是图像预处理的 CPU 瓶颈。图像解码、resize、normalize 如果放在主进程里做GPU 会一直等着吃数据。我后来把数据管线改成异步预取并把图像预处理放到独立的进程池里吞吐提升了将近 60%。训练稳定性还有一个隐性杀手数据时序错位。图像、指令、动作在时间戳上差一帧loss 可能没什么明显变化但策略效果会稀碎。我在 pipeline 里加了对齐校验训练前会检查每条轨迹的图像时间戳和动作时间戳是否严格单调对齐这个问题排查起来极其痛苦建议从一开始就做好。4. 评测与迭代从 LIBERO 基准到真实任务的验证闭环架构建好、训练跑通之后紧接着的问题就是怎么知道骨干行不行我在 nextVLA 里建立了一个两级评测体系先在轻量级仿真基准上快速迭代再在真实场景中做最终验证。4.1 用 LIBERO 基准快速验证骨干能力LIBERO 是机器人操作领域一个被广泛使用的仿真评测基准。我把 LIBERO 当作日常迭代的验证工具因为它跑得快、成本低适合测不同骨干变体的效果差异。它把任务分成了几个套件比如空间泛化、物体泛化、目标泛化、知识迁移、时序组合每个套件专门测试模型的一项能力。这个设计我非常喜欢它能告诉你模型的短板到底在哪个维度而不是只给一个平均成功率。我在 LIBERO 上做 A/B 测试时有个固定流程固定数据、固定训练轮数、固定随机种子只改一个变量然后对比成功率。曾经有一次我和同事争论视觉编码器应该选 A 还是 B争论了三天。最后在 LIBERO 的物体泛化套件上跑了一轮对比方案 B 比方案 A 高了接近 15 个点争论立刻结束。没有这种快速评测回路架构迭代基本靠拍脑袋。4.2 真实环境的评测指标与细节LIBERO 表现好不代表真实场景没问题。仿真环境的状态是精确的、光照是固定的、物体形状是不变的到了真实环境这些条件全都会变化。我见过太多在仿真里 90% 成功率、真实场景直接腰斩的案例。真实环境评测我设计了三个指标单次任务成功率、10 次重复实验的稳定性、以及失败模式分类。成功率自然不用多说但稳定性更重要——一个模型偶尔成功一次和连续 10 次稳定成功可信度是完全不一样的。失败模式分类则用来指导下一步迭代方向模型是抓不住物体、还是抓到了放不对、还是动作执行到一半卡住每种失败背后的原因可能完全不同。另外真实评测的时间成本和精力成本都很高。每次重新摆场、复位物体、重置位姿都要花时间。我建议每次真实评测的任务数量控制在 3 到 5 个每个任务做 10 次实验。这样既能保证统计可信度又不会把整个团队拖垮在评测上。4.3 骨干改造的迭代闭环VLA 骨干的开发不是一次性的而是一个持续的迭代闭环。我的节奏是每周在 LIBERO 上跑一轮骨架对比实验每两周做一次真实环境评测。每次改动只动一个变量并且记录完整的实验 log。迭代过程中我发现最有价值的改进往往来自对失败案例的分析而不是对成功案例的复盘。有一次我在 LIBERO 的 Transfer 套件上发现模型在某个未见过的桌子颜色上全军覆没。排查后发现问题出在图像增强策略上——训练时没有加入色彩扰动导致模型过拟合了训练场景的色调。加上 color jitter 之后这个套件的成功率提升了将近 20 个点。这类问题不深入拆失败案例是根本发现不了的。5. 骨干落地过程中的坑排查记录与避坑建议最后这部分我梳理一下 nextVLA 骨干开发过程中实际遇到的典型问题。这些问题在论文里通常不会写但每一个都真实地浪费过我几天时间。5.1 训练不收敛或者动作抖动我在早期测试流匹配动作头时经常遇到 loss 在不断下降、但动作输出一颤一颤的情况。后来发现原因不是模型结构不对而是动作归一化没做好。不同关节的运动范围差异很大如果直接拿原始关节角度训练数值范围大的关节会主导梯度更新。解决方法是按关节分别做标准化让每个关节的数值范围都落到接近零均值单位方差的区间。另外动作抖动还有一个常见来源是预测频率太高。模型每个控制周期都重新推理一次上个周期的动作还没执行完新动作就来了两个动作之间的不一致就表现为抖动。我调整了动作推理的触发策略只按固定频率推理并且做动作平滑抖动问题明显改善。5.2 评测结果忽高忽低难以判断改动是否有效这是做 VLA 最让人头疼的问题。同一份代码、同一个模型在 LIBERO 上跑三次结果可能波动 10 个点以上。我开始的时候经常被这种随机性误导把噪声当成改进。后来我摸索出一个比较可靠的流程固定随机种子每个实验跑至少 5 个 seed取平均和方差。改动带来提升的标准是平均成功率提升要超过方差。如果模型 A 平均 70%模型 B 平均 72%但各自方差都有 3-4 个点那这种差距在实际意义上并不显著。另外评测时初始场景的随机化程度也要统一否则场景差异会占掉很大一部分随机性。5.3 推理速度和显存问题VLA 落地到真实机器人上推理速度是硬指标。7B 模型在 GPU 上推理一次可能只要几百毫秒但机器人控制周期要求可能只有几十毫秒这里面的差距需要想办法弥补。我在推理侧做了三件事。第一图像 token 会被压缩而不是把所有视觉 token 都灌进 LLM这样能显著降低序列长度。第二LLM 的 KV cache 缓存复用对历史上下文不做重复计算。第三动作头和 LLM 解耦LLM 只需要在指令或状态发生显著变化时推理一次动作生成的循环只跑轻量级的流匹配去噪不经过 LLM。这套组合拳下来端到端的推理延迟从最初的接近 2 秒降到了 300 毫秒左右达到了真实场景可用的程度。最后再分享一个我个人非常坚持的习惯每次改骨干结构都先写一页纸的改动说明写清楚改了什么、为什么改、预期带来什么收益。这个习惯帮我避免了很多次改了不如不改但不改回去又不甘心的内耗。架构设计这件事最怕的不是踩坑而是踩了坑还不记得为什么踩、怎么爬出来的。把这些记录在案下一代 VLA 迭代的时候你会有一种站在自己肩膀上的感觉。