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

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

作者丨邓哲敏

编辑丨齐铖湧

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

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

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

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

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

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

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

01

新模型请先登记

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

对具身智能来说，模型是迭代最快的。今天使用一种 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 上跑评测。

MiniMax-M3.1-Flash以纯 API 方式接入评测的 LIBERO 仿真演示 rollout

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

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

02

三步上真机

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

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

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

人形机器人的控制回路需要高频率的动作指令，但大型 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让新动作序列与正在执行的动作自然衔接，轨迹后处理让最终发出的指令符合机器人的物理约束。三步合起来，把模型预测到真机执行之间常被一笔带过的工程落差，拆成了可定位、可分别解决的环节。

03

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

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

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

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 上的成功率从峰值略有回落。

这组实验还验证了一个重要方向：当策略交互、数据采集和训练优化能够在工程上形成闭环，真实执行过程中获得的经验就有机会被用于后续模型改进，而不只是停留在一次测试结果中。对于整个行业而言，这意味着研发流程可以从单向的“收集示教—训练—测试”，进一步向“执行—采集经验—优化策略—再次执行”扩展。

04

覆盖度才是硬指标

一套工程体系能否发挥价值，还需要看它在多大范围内经过了验证。

如果只支持少数几种模型，或只能在单一机器人上运行，那么它的复用能力仍然有限。反过来，如果多种异构策略能够进入同一套评测体系，并在不同机器人平台上完成相应的测试，就更有机会证明这套工程框架具备一定的通用性。FluxVLA技术报告中的评测结果，提供了几个值得观察的切面。

仿真侧，第一部分已经说过，内部结构差异极大的策略，能共用同一套数据管线和评测器。放到具体数字上，技术报告在 LIBERO 一共集成了 14 个策略，13 个本地 checkpoint 里 11 个平均成功率超过 95%。有两个细节此前没展开。

一是难度分层。 LIBERO 测的是桌面级的短任务，高分有一部分原因来自基准本身的任务特点。同样的策略，换到更接近真实居家操作、难度更高的 RoboCasa GR-1，平均成功率掉到 8.75% 到 57.25% 之间。需要说明的是，这个落差来自任务难度的差异，而不是评测口径的问题。报告也明确标注，两组结果来自不同的模型架构、数据预算和训练流程，不构成受控比较。

把策略放到不同难度的任务中验证，不只是为了得到一个成功率数字，更在于帮助开发者判断模型当前能完成什么、在哪些任务上仍有提升空间。FluxVLA 提供的统一评测流程，让这类能力验证能够在相应的基准上持续开展。

二是泛化。RoboDojo 的 42 个任务、每个模型 2100 次试验，大多数模型能完成任务的一部分，但能从头到尾全部完成的比例低得多；当任务布局从固定改成随机，排名最靠前的 π0.5 成功率从 16% 跌到 2.33%，其余七个模型最高只有 0.67%。通过这组数字，不难看出当前所有主流策略在没见过的场景面前的共同窘境。

真机侧，平台扩展到了四个：ALOHA 双臂系统（6 个任务、7 种策略配置）、逐际动力自研的全尺寸人形机器人 Oli、Rebot，以及双臂 Franka。在仿真里训练、验证过的策略，通过同一套部署路径，直接上了形态各异的四个平台，并且都完成了闭环测试。

很有意思的是 Oli 上的一组细节：四阶段箱子搬运里，GR00T N1.5 和 π0.5 前三阶段完成率几乎相同（60% 对 61.67%），全程完成率却只有 6.7% 和 33.33%。长程任务的成功率是乘法不是加法，前几段积累的微小偏差会在后期被逐级放大。我们在和业内人士的交流中曾多次听说这个问题，但也只能停留在理解和想象，这次 FluxVLA 分阶段记录完成情况的评测设计让我们清晰地看到了这一点。

最能体现闭环价值的，是用 ALOHA 叠毛巾的数据。先用传统的行为克隆训练，也就是让模型照搬人类示教的动作，成功率只有 62.1%。换了个思路，先训练一个奖励模型，让系统学会判断每个动作做得如何，再用这个判断反过来指导策略训练，成功率上升到 99.4%。从真机采集数据、训练奖励模型，到重训策略，再部署回真机，整个过程都在 FluxVLA Engine 一套底座上完成。

综合来看，FluxVLA 的评测结果提供了两类不同的证据。一类是工程能力： 多种异构策略被纳入统一评测体系，多个真机平台完成了相应的闭环验证，说明它已经展示出跨模型、跨平台组织研发流程的能力。另一类是模型能力的可验证性： 不同基准下的表现差异、随机布局带来的成功率变化，以及长程任务中的阶段性损耗，都让模型的能力边界有了更具体的观察依据。工程底座并不替代模型本身的优化，也不意味着所有策略都能自动获得出色的泛化能力；它所提供的，是一套相对统一的验证路径，让开发者能够更可靠地评估现有能力、发现问题，并在后续研发中持续改进。

05

军无辎重则亡

2026 年具身智能竞争的焦点，从谁的模型更牛，逐渐移到了谁的数据更多更泛、谁的本体更扛用、谁的商业化路径更明确。前线拼火力，后方拼粮草，完整的工程生态就像靠谱的补给线，越到战线后期，越能体现出价值。

FluxVLA 的价值并不在于解决具身智能的所有工程难题，而在于试图将其中一部分反复出现的问题，变成可复用的工程机制。模型注册与统一配置，减少了重复搭建研发流程的需要；推理优化、RTC 与轨迹后处理，将部分真机执行障碍拆分为可处理的环节；在线 RL 对接，为交互数据进入策略优化提供了工程接口；跨模型和跨平台评测，则让不同策略能够在相应条件下得到验证。

这些能力共同指向一个目标：让研发团队能够把更多精力放在模型、数据与任务本身，而不是在每次实验中重复处理相同的基础工程问题。更重要的是，工程流程的统一不仅服务于研发效率，也让模型能力的验证与迭代有了更稳定的依托。开发者可以在相对一致的流程中比较不同方案，观察策略在不同任务和平台上的表现，再将发现的问题带回数据、训练与部署环节。

此外，FluxVLA 有一个容易被忽视、但在我们看来却很关键的选择：不追求让所有组件无条件兼容。不同模型、数据集、机器人本体之间，数据结构、动作语义、接口的差异客观存在，谁也抹不掉。FluxVLA 用标准接口和模块化设计，把这些差异集中到可检查、可适配的环节——组合出问题的时候，能让人知道具体出在哪里。在工程可靠性上，这种让问题暴露出来的姿态，比假装一切都兼容更有价值。

作为一家具身智能主机厂，逐际动力在本体、算法研发和真机运行中踩过的坑、验证过的流程，本可以当作护城河，服务于自身产品，但他们选择将一线经验转化为开放的标准化工程底座，以企业级资源为外部开发者、算法团队和其他机器人平台提供了使用与协作的更多可能性。当然，这并不意味着开源项目已经自然形成了成熟的行业生态。真正的生态还需要外部团队持续使用、贡献适配、反馈问题，并在不同场景中验证其价值。但开放的接口与可复用的工具，至少为这样的协作提供了基础。

FluxVLA Engine 代码仓库：https://github.com/FluxVLA/FluxVLA

技术报告：https://arxiv.org/abs/2609.17210

Hugging Face： https://huggingface.co/limxdynamics/FluxVLAEngine

未经「AI科技评论」授权，严禁以任何方式在网页、论坛、社区进行转载！

公众号转载请先在「AI科技评论」后台留言取得授权，转载时需标注来源并插入本公众号名片。