具身智能军备竞赛，胜负手在工程生态

开源工程底座 FluxVLA Engine 技术报告全解读。

作者丨邓哲敏

编辑丨齐铖湧

一个模型在论文中取得好成绩，距离它真正驱动机器人完成任务，还有多远？

模型能否接入现有的数据与训练流程，推理速度能否跟上机器人的控制节奏，生成的动作能否连续、稳定地执行，实验结果又能否在不同机器人上得到验证——这些问题，未必能靠再提升几个百分点的模型成功率来解决。

过去半年，AI科技评论（雷峰网）在与业内人士交流时发现，一些反复出现的工程问题正在消耗大量研发资源：不同模型的数据格式难以统一，训练和评测流程各自为政，仿真中的结果到了真机上未必成立；好不容易跑通一套流程，换个模型、换份数据或换台机器人，又可能需要重新适配。

模型在不断迭代，工程积累却未必能随之沉淀。

这让雷峰网想起深度学习的发展历程。2017 年，PyTorch 正式开源，此后，框架、工具链与开发者社区不断完善，研究者得以在更成熟的基础设施上开展实验，而不必每次从底层重新搭建环境。今天的具身智能虽然面临不同的技术挑战，但同样需要解决一个问题：如何让已有的研发成果更容易复用，让不同技术路线能够在统一的工程框架下协作。

逐际动力开源的 FluxVLA Engine，试图从工程层面回应这一问题。它并非又一个争夺模型性能排名的 VLA 模型，而是一套面向具身智能研发的工程底座，贯通数据、训练、评测、推理与真机部署。

10 月 22 日，FluxVLA Engine 完成重要更新。我们拆解了它的最新技术报告，并重点关注四个问题：不同架构的模型能否接入同一套研发体系？模型从仿真走向真机，需要跨过哪些工程障碍？真实交互经验如何低成本地回流到模型优化中？当同一套流程覆盖更多模型与机器人时，它究竟展示出了怎样的能力？

新模型请先登记

一套工程底座是否真正有用，首先要看它能否接纳不同的模型。

对具身智能来说，模型是迭代最快的。今天使用一种 VLA 架构，明天可能尝试另一种动作生成方式；同一团队也可能同时研究多个策略模型。如果每换一次模型，就要重新整理数据、编写评测代码、改造部署接口，那么此前积累的工程经验很难持续发挥价值。

模型可以不断更换，但围绕数据、评测和部署建立起来的工程能力，不应该每次都从头再来。

FluxVLA Engine 的做法，是通过统一配置与组件注册机制，把不同模型接入研发流程时需要处理的差异，尽可能收敛到明确的接口中。可以理解为一份统一的实验清单，加上一套可供调用的组件目录。

配置文件负责声明一次实验需要使用什么模型、如何处理数据、怎样开展评测，以及通过什么接口进行部署。注册机制则将视觉骨干、动作头、训练运行器和机器人相关操作组件等分别组织起来。开发者可以按需组合已经适配的组件，而不必为每一种模型重新搭建整套工程流程。

这并不意味着任何模型都能在不做适配的情况下直接运行。不同架构仍然可能需要各自的适配器、动作空间转换和归一化处理。真正的价值在于：把不可避免的差异放到可管理的组件层，让已经打通的公共流程能够继续复用。

从技术报告来看，FluxVLA 已经将多种架构差异明显的策略纳入同一套研发与评测体系，包括采用自回归路线的 OpenVLA、采用 flow-matching 路线的 π0.5，以及 DiT4DiT、GR00T 等不同技术路线的模型。这意味着，统一工程框架不必以牺牲模型多样性为代价。

FluxVLA 的模型接入并不局限于开放权重的模型。GPT-6 Astra 此前就以纯 API 的方式接入，同一套闭环评测，不提供权重、不参与训练，评测器照常跑完流程、留好证据。就在最新技术报告发布后两天，MiniMax-M3.1-Flash 成为继 GPT-6 Astra 之后第二个 checkpoint-free 的纯 API 推理策略，开箱即可在 LIBERO 与 RoboCasa GR1 上跑评测。

数据层面也遵循同一套逻辑。不同机器人、不同仿真环境产生的轨迹数据，统一转成标准格式后，可以在同一套管线里混合训练，也可以分组保留各自的归一化约定。今天为某个模型整理好的数据集，明天换个模型照样能用。工程积累不随技术路线切换而清零——这才是让行业研发成果能够持续叠加、而不是互相抵消的前提。

说到底，数据是具身智能最贵的资产，能让这份资产少贬值、多复用，本身就是一种行业级的降本。

三步上真机

一个策略的最终归宿，还是得落到物理世界。模型在仿真里跑出了很高的成功率，上了真机，性能可能大幅下滑。这不一定是模型本身的问题，而是模型推理和机器人执行之间存在一道系统性的工程鸿沟。

这道鸿沟由三层问题叠加而成，每一层都不是单靠更好的模型能解决的，需要三个依次协作的机制来分别处理。

第一层，模型推理太慢，跟不上机器人的控制节奏。

人形机器人的控制回路需要高频率的动作指令，但大型 VLA 模型的推理速度往往远不够快——模型还在计算下一步，机器人已经完成当前动作在干等了。两者之间的时间差，直接造成机器人动作迟钝或失步。

FluxVLA 的解法是为同一组已学参数换一张更高效的执行图。具体来说，针对 GR00T 和 π0.5 两条主流路线，系统通过把反复执行的计算步骤预先“录制”成固定执行图（CUDA Graph），配合底层算子融合等优化，提高执行效率。这一步不碰模型权重——针对 GR00T 动作头的数值对齐测试显示，加速前后输出动作的余弦相似度超过0.99999。

实测数据里有一组数字，让我们印象深刻。在英伟达 AGX Orin 64GB 这块边缘芯片上（大量人形机器人的“机载大脑”用的正是它），GR00T 的推理频率从 3.2Hz 提升到了 7.4Hz，π0.5 从 1.4Hz 提升到 4.4Hz。同一块芯片，同一个模型，优化之后，模型推理速率提升了两三倍。

第二层，预测和执行之间存在时序错位。

VLA 模型通常一次预测一段动作序列，让机器人边执行、边预测下一段，以此降低查询频率。但当新的预测结果计算完成时，它开头部分对应的时刻往往已经过去，机器人已经走到那段时序之后了。直接把新的动作序列接上去，会产生明显的跳变，表现为关节处的抖动和不连续。

FluxVLA 选择用 RTC（Real-Time Chunking）来解决这个时序错位问题，把上一段动作序列里还没执行完的部分，当作下一次预测的前提。生成新序列时，模型已经知道机器人接下来会先做什么，新动作从那个状态自然地延续下去。

技术报告提供了两种实现路线，一种在训练阶段就加入延迟条件模拟、推理时使用前缀条件；另一种不改变训练过程，适合直接用在已有模型上。

第三层，动作序列在物理上不一定能执行。

解决了时序衔接，还有最后一道关。模型输出的动作序列，在物理层面未必符合机器人的运动能力边界。把归一化的预测值还原成真实的关节角度、速度之后，一段序列里可能隐含过大的加速度或局部振荡。简单来说，动作可能太猛，或忽快忽慢，超出机器人能平稳执行的包络。

轨迹后处理做的事，是在动作序列真正发送给机器人之前，先做一次运动学约束优化，把速度、加速度以及它们的变化快慢都限制在可安全执行的范围内。FluxVLA 提供两种后端，一种求解更精细，处理延迟约 4.9 毫秒；另一种快约 4 倍、延迟只有 1.17 毫秒，代价是跟踪保真率略低、存在一定参考滞后。二者各有适用场景，可以在配置里自由选择。

这三个机制最优雅的设计，在于顺序协作。推理加速让模型快到足以跟上控制回路，RTC让新动作序列与正在执行的动作自然衔接，轨迹后处理让最终发出的指令符合机器人的物理约束。三步合起来，把模型预测到真机执行之间常被一笔带过的工程落差，拆成了可定位、可分别解决的环节。

让真实交互经验进入训练闭环

把模型送上真机，然后呢？

在具身智能的主流开发范式里，通常流程是：收集人类示教数据，训练模型，测试，再收集，如此循环。这套方法已经推动了许多机器人操作能力的发展，但示教数据能够覆盖的情况终究有限，真实环境中的物体位置、光照、机器人初始状态等因素不断变化，模型可能遇到训练数据中没有充分覆盖的情况。如果每次发现问题，都只能依赖人工补充示教数据，模型改进的速度就会受到数据采集和训练流程的限制。

FluxVLA 在这次更新中引入了在线强化学习后训练，正面回应这个问题。

从工程设计上来看，这套方案相当克制。FluxVLA 没有选择自己把 RL 做一遍，而是和专门做大规模 RL 训练的 RLinf 系统对接，各做各最擅长的事：FluxVLA 保留模型构建、观测处理、动作转换这一层，RLinf 负责 rollout 采集、优化算法和权重同步。两者靠接口衔接，同一套模型不需要改动，接上 RLinf 前端就能进入在线 RL 的训练闭环。这个分工设计让现有的监督训练流程完全不受影响，RL 是可选的增量能力，而不是对已有工作流的替换。

在开源项目里，全部包揽是常态，把不擅长的交出去反而是稀缺的。FluxVLA 愿意在边界上留出接口、与外部系统协作，说明它对自己的定位是很清醒的，没想着去做面面俱到的全家桶。

不过，在线强化学习并不意味着机器人可以自动理解每一次失败，也不保证训练时间越长、模型就一定越强。它提供的是一条利用交互数据优化策略的路径，最终效果仍然取决于奖励设计、训练设置和任务条件。

技术报告给出了一组配对实验结果：SmolVLA 在 LIBERO-10 上，成功率从基线 66.2% 提升到 76.2%，提高 10 个百分点；在 RoboTwin Clean 设置的 10 个任务上，从 45.9% 提升到 61.3%，提高 15.4 个百分点。RoboTwin 实验还记录到，经过训练后，有 231 个此前失败的 episode 转为成功，但也有 77 个原本成功的 episode 出现退步。这意味着，策略的整体表现虽然有所改善，却不是对所有情况都实现了同步优化。报告同时指出，随着训练继续进行，LIBERO-10 上的成功率从峰值略有回落。