开源工程底座 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 上的成功率从峰值略有回落。这组实验还验证了一个重要方向：当策略交互、数据采集和训练优化能够在工程上形成闭环，真实执行过程中获得的经验就有机会被用于后续模型改进，而不只是停留在一次测试结果中。对于整个行业而言，这意味着研发流程可以从单向的“收集示教—训练—测试”，进一步向“执行—采集经验—优化策略—再次执行”扩展。一套工程体系能否发挥价值，还需要看它在多大范围内经过了验证。如果只支持少数几种模型，或只能在单一机器人上运行，那么它的复用能力仍然有限。反过来，如果多种异构策略能够进入同一套评测体系，并在不同机器人平台上完成相应的测试，就更有机会证明这套工程框架具备一定的通用性。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 的评测结果提供了两类不同的证据。一类是工程能力：多种异构策略被纳入统一评测体系，多个真机平台完成了相应的闭环验证，说明它已经展示出跨模型、跨平台组织研发流程的能力。另一类是模型能力的可验证性：不同基准下的表现差异、随机布局带来的成功率变化，以及长程任务中的阶段性损耗，都让模型的能力边界有了更具体的观察依据。工程底座并不替代模型本身的优化，也不意味着所有策略都能自动获得出色的泛化能力；它所提供的，是一套相对统一的验证路径，让开发者能够更可靠地评估现有能力、发现问题，并在后续研发中持续改进。2026 年具身智能竞争的焦点，从谁的模型更牛，逐渐移到了谁的数据更多更泛、谁的本体更扛用、谁的商业化路径更明确。前线拼火力，后方拼粮草，完整的工程生态就像靠谱的补给线，越到战线后期，越能体现出价值。FluxVLA 的价值并不在于解决具身智能的所有工程难题，而在于试图将其中一部分反复出现的问题，变成可复用的工程机制。模型注册与统一配置，减少了重复搭建研发流程的需要；推理优化、RTC 与轨迹后处理，将部分真机执行障碍拆分为可处理的环节；在线 RL 对接，为交互数据进入策略优化提供了工程接口；跨模型和跨平台评测，则让不同策略能够在相应条件下得到验证。这些能力共同指向一个目标：让研发团队能够把更多精力放在模型、数据与任务本身，而不是在每次实验中重复处理相同的基础工程问题。更重要的是，工程流程的统一不仅服务于研发效率，也让模型能力的验证与迭代有了更稳定的依托。开发者可以在相对一致的流程中比较不同方案，观察策略在不同任务和平台上的表现，再将发现的问题带回数据、训练与部署环节。此外，FluxVLA 有一个容易被忽视、但在我们看来却很关键的选择：不追求让所有组件无条件兼容。不同模型、数据集、机器人本体之间，数据结构、动作语义、接口的差异客观存在，谁也抹不掉。FluxVLA 用标准接口和模块化设计，把这些差异集中到可检查、可适配的环节——组合出问题的时候，能让人知道具体出在哪里。在工程可靠性上，这种让问题暴露出来的姿态，比假装一切都兼容更有价值。作为一家具身智能主机厂，逐际动力在本体、算法研发和真机运行中踩过的坑、验证过的流程，本可以当作护城河，服务于自身产品，但他们选择将一线经验转化为开放的标准化工程底座，以企业级资源为外部开发者、算法团队和其他机器人平台提供了使用与协作的更多可能性。当然，这并不意味着开源项目已经自然形成了成熟的行业生态。真正的生态还需要外部团队持续使用、贡献适配、反馈问题，并在不同场景中验证其价值。但开放的接口与可复用的工具，至少为这样的协作提供了基础。FluxVLA Engine 代码仓库：https://github.com/FluxVLA/FluxVLA
技术报告：https://arxiv.org/abs/2609.17210Hugging Face：https://huggingface.co/limxdynamics/FluxVLAEngine
雷峰网原创文章，未经授权禁止转载。详情见转载须知。
本文由 AI宝库自动抓取并翻译，版权归原作者所有；如需查看原文请点下方链接。
The FluxVLA Engineering Technical Report is read in its entirety.
Mr. Dang Chul-min.
Edit Queue
How far away is a model going to lead a real robot to its mission? The ability of models to access existing data and training processes, the speed of reasoning to keep pace with robotic control, the continuity and stability of the actions generated, and the validation of the results of experiments on different robots — problems that may not necessarily be solved by a model success rate, which raises a few additional percentage points. Over the past six months, the AI Science and Technology Review (Ray Peak Network) has found that some of the recurrent engineering problems are draining considerable research and development resources: data formats for different models are difficult to harmonize, training and evaluation processes are fragmented, and simulations do not necessarily work on real-time; it is difficult to run a process of changing models, data or robots, and may require readaptation. This reminds me of the development of deep learning. Following the official opening of PyTorch in 2017, the framework, the tool chain and the developers ' community continued to improve, and researchers were able to experiment with more mature infrastructure without having to re-establish the environment from the bottom every time. Today ' s smartness, while facing different technical challenges, also needs to be addressed: How to make existing R & D results more accessible and to allow different technology routes to collaborate within a unified engineering framework. FluxVLA Engineering, an introspective open source, attempts to respond to this problem at the engineering level. It is not yet another VLA model that competes for model performance, but rather a set of engineering substrates that are oriented towards the development of intelligence, and that communicate data, training, evaluation, reasoning and real-life deployment. On October 22, FluxVLA Engineering completed a major update. We dismantled its latest technical report and focused on four issues: can models of different structures be connected to the same R & D system? What kind of engineering barriers do models need to cross from simulation to reality? How can real interactive experience flow back to model optimization at low cost? When the same process covers more models and robots, what does it show? The real usefulness of a set of engineering floors depends first on its ability to accommodate different models. Models are the fastest in terms of intelligence. Using a VLA structure today, there may be another way to generate action tomorrow; the same team may also be working on multiple strategy models at the same time. It would be difficult to sustain the value of the engineering experience previously accumulated if each model was changed to re-collating data, developing assessment codes and adapting the deployment interface. The model could be replaced on an ongoing basis, but the engineering capacity built around data, assessments and deployments should not be repeated from scratch. FluxVLA Engineering uses a uniform configuration and component registration mechanism to integrate different models into the R & D process and to minimize the differences that need to be addressed in a clear interface. It can be understood as a unified list of experiments, with a catalogue of components available for call. The configuration document is responsible for stating what model will be used for an experiment, how the data will be handled, how the assessment will be conducted, and what interface will be deployed. The registration mechanism organizes the visual backbone, the action head, the training operator and the robot-related operating components. The developers can group the components that are already fit on demand without having to re-engineer the entire project process for each model. This does not mean that any model can run directly without matching. Different structures may still require individual adapters, operational space conversions and regularization. The real value lies in placing inevitable differences in manageable components so that the public processes that have been reached can continue to be reused. According to the technical report, FluxVLA already has multiple shelves. The differentiated strategies are integrated into the same R & D and evaluation system, including models of the OpenVLA, the Flow-Matching, and the DiT4DiT and GR00T technology routes. This means that a unified engineering framework need not be at the expense of model diversity. FluxVLA model access is not limited to open weight models. GPT-6 Astra had previously been accessed in a pure API, with the same set of closed-ring assessments, which did not provide weights, did not participate in training, and the evaluator ran through the process and kept evidence. Just two days after the latest technical report publish, MiniMax-M3.1-Flash became the second pure API reasoning after GPT-6 Astra, and open the box to run on LIBERO and RoboCasa GR1. The same logic is followed at the data level. The trajectories generated by different robotics, different imitation environments can be combined in the same set of piped trainings, or can be retained in groups with their respective integration protocols, following a uniform transition to a standard format. Today's data set for a model can be used tomorrow. The build-up of the project will not be eliminated by a technical course — This is a prerequisite for the sustainability of industry R & D results, rather than for each other. In the end, the data are the smartest asset, allowing the asset to be less depreciated and more reused, and is itself an industry-class downfall. The ultimate end of a strategy is the physical world. The model runs out of a very high success rate in a simulation, into a real machine, and the performance could decline significantly. This is not necessarily a problem of the model itself, but rather a systemic engineering gap between model reasoning and robotic implementation. This divide is conflated by three layers of problems, each of which is not solved by better models alone and requires three sequential mechanisms for collaboration. The control circuits of human robots require high-frequency action instructions, but the large VLA model tends to be deduced not fast enough — the model is still calculating next step, and the robot has completed the current operation waiting to dry. The time difference between the two directly results in the robots being slow or lost. FluxVLA was decomposition to change a more efficient implementation map for the same group of studied parameters. Specifically, with respect to the two main routes of GR00T and thorium 0.5, the system improves the efficiency of implementation by pre-recordeding the calculated steps of repeated execution into a fixed implementation chart (CUDA Graph) with optimization, such as the integration of lower-level algorithms. This step does not touch the model weight - the numerical alignment test for the GR00T action head shows that the cosine similarity of the acceleration output action exceeds 0.999999. We're impressed with a set of numbers in the data. On the edge chip of the AGX Orin 64GB (which is used by a large number of man-shaped robots' “on-board brains”), GR00T's reasoning frequency increased from 3.2Hz to 7.4Hz and thallium 0.5 from 1.4Hz to 4.4Hz. The same chip, the same model, optimized the model's reasoning rate by two or three times. VLA models typically predict a sequence of actions at a time, allowing robots to execute side by side and predict the next segment, thereby reducing the frequency of queries. But when the new predictions are completed, the time at which it begins is often over, and the robots are now behind that time sequence. Directly reconnecting new sequences of actions can produce significant jumps in the form of joint shaking and discontinuity. FluxVL A Selects the RTC (Real-Time Chunking) to address this time-series error by using the parts of the previous action sequence that have not been implemented as a prerequisite for the next projection. When the new sequence is created, the model already knows what the robot will do first, and the new action naturally continues from that state. The technical report provides two paths of realization, one using prefixing conditions for the inclusion of delayed conditions in the training phase, and the other not changing the training process, which is suitable for direct use in existing models. The time series was resolved, and there was the last one. Model output action sequences do not necessarily match robotic mobility boundaries at the physical level. Reverts the normalized projection to a real joint angle, velocity, and may imply too much acceleration or local oscillation in a sequence. In short, the movement may be too strong or too slow to go beyond robotics to implement it smoothly. What is done in the back-tracking process is to do an optimisation exercise before the action sequence is actually sent to the robot, and to limit the speed, acceleration and speed of their change to safe implementation. FluxVLA provides two backends, one to solve more finely and to process the delay of about 4.9 milliseconds; the other is about 4 times the delay of 1.17 milliseconds, at the cost of a slightly lower retention rate and some reference lag. Each has a suitable scenario and is free to choose in its configuration. The three mechanisms are most elegantly designed in sequence. The reasoning accelerates the model fast enough to keep up with the control loop, the RTC allows the sequence of new actions to be naturally linked to the action being carried out, and the back-tracking process allows the final command to fit the robot ' s physical constraints. A three-step combination of the often-tangible gap between the prediction of the model and the implementation of the real machine has been broken down into a locationable and separately solventable link. In the dominant development paradigm with intelligence, the processes are usually: collection of human teaching data, training models, testing, recollection and so on. This approach has contributed to the development of many robotic operational capabilities, but in the end, the coverage of teaching data is limited, the physical position of the real environment, the light, the initial state of robotics, etc., are constantly changing, and models may be exposed to inadequate coverage in training data. If, each time a problem is identified, only manual supplementation of teaching data is relied upon, the pace of improvement of the model is limited by data collection and training processes. FluxVLA introduced online intensive post-learning training to respond positively to this issue. In terms of engineering design, the package is quite restrained. FluxVLA does not choose to do RL on its own, but rather connects to RLInf systems that specialize in large-scale RL training, each doing its best: FluxVLA retains the layer of model construction, observation processing, action conversion, RLinf is responsible for rollout collection, optimization of algorithms and weight synchronization. The two are interfaced and the same set of models do not need to be changed to the front end of RLinf to enter the online RL closed loop. This division of labour design leaves the existing oversight training process entirely unaffected, and RL is an optional incremental capacity rather than a replacement for workflow. In open-source projects, the whole package is normal and handing out what is not good is scarce. FluxVLA ' s willingness to leave an interface at the border and to collaborate with the external system suggests that it is conscious of its position and does not want to do a full-scale family barrel. However, intensive online learning does not mean that robots can automatically understand each failure, nor does it guarantee that the longer the training, the stronger the model. It provides a path for optimizing the strategy using interactive data, with the ultimate effect. The outcome continues to depend on incentives for design, training and mission conditions. The technical report gave a set of test pairing results: SmolVLA on LIBERO-10, success rate rose from a baseline of 66.2 per cent to 76.2 per cent, an increase of 10 percentage points; and from 45.9 per cent to 61.3 per cent, an increase of 15.4 percentage points, on the 10 tasks set by Robotwin Clean. RoboTwin also recorded that, after training, 231 previously failed episodes turned into success, but there were 77 otherwise successful episodes. This means that while the overall performance of the strategy has improved, it has not been synchronized in all cases. At the same time, the report notes that as training continued, success rate on LIBERO-10 fell slightly from its peak. The experiment also confirmed an important direction: When strategic interaction, data collection and training optimization can create a closed engineering loop, the experience gained in real implementation has the opportunity to be used for subsequent model improvements, not just in a single test. For the industry as a whole, this means that the R & D process can be further expanded from a one-way “collect teaching-training-testing” to “implement-collect experience-optimizing strategy-re-exercise”. The value of an engineering system also depends on the extent to which it has been validated. If only a few models are supported or can only operate on a single robot, its reuse capacity remains limited. In turn, if multiple isomer strategies are able to enter the same assessment system and the corresponding tests are completed on different robotic platforms, there is a greater opportunity to demonstrate that the engineering framework has some commonality. The results of the FluxVLA technical report provide several observations. On the simulation side, as already stated in the first part, a very different strategy of internal structures can be shared with the same set of data lines and evaluators. In concrete numbers, the technical report has 14 strategies in LIBERO, and 11 of 13 local checkpoints have an average of over 95% success rate. Two details were not previously developed. One is the difficulty layer. LIBERO measures a short task at the desktop level, which is partly due to the task characteristics of the benchmark itself. The same strategy, which is closer to real-home operations, is more difficult for RoboCasa GR-1, with an average of success rate falling between 875% and 57.25%. It should be noted that this gap arises from differences in the difficulty of the task rather than from the problem of calibration. The report also clearly indicates that the two sets of results are derived from different model structures, data budgets and training processes and do not constitute controlled comparisons. It is not just to get a success rate number, but to help developers judge what the model is capable of doing and where there is room for improvement. FluxVLA provides a uniform assessment process that allows such capacity validation to be carried out on an ongoing basis on the corresponding benchmarks. Two is generalization. RoboDojo's 42 missions, each of the 2100 experiments, most of the models were able to complete a part of the mission, but the percentage of complete completion from beginning to end was much lower; when the task layout was changed from fixed to random, the top ranking of the thorium 0.5 success rate fell from 16 per cent to 2.33 per cent, with the remaining seven models having a maximum of 0.67 per cent. Through this set of figures, it is not difficult to see the common dilemma of all the current mainstream strategies in the face of an unprecedented scene. Real side, the platform has been extended to four: ALOHA, arms. Systems (6 missions, 7 policy configurations), full-size human robots, IND, Oli, Rebot, and arms Franka. The strategies trained and validated in the simulation, through the same deployment path, went directly to four platforms of varying shapes and all completed closed-ring tests. Interestingly, there is a set of details on Oli: GR00T N1.5 and thorium 0.5 for the first three stages in the four-stage suitcases, with an almost identical completion rate (60 per cent for 61.67 per cent) and a full completion rate of 6.7 per cent and 33.33 per cent. The success rate for a long-range mission is a multiplication, not an addition, and the small deviations accumulated in the previous paragraphs will be magnified by post-production. We've heard about this many times in our exchanges with people in the industry, but we have to stop with understanding and imagination, and this time FluxVLA's structifying design to record completion in stages shows us clearly. Most of the value of a closed ring is the data of the ALOHA folding towel. Training in traditional behaviour cloning, i.e., to allow models to reproduce human teachings, success rate had only 62.1 per cent. In a different way, the system learns to judge how each move is done, and success rate, which in turn guides strategy training, rises to 99.4 per cent. The process of collecting data from real machines, training incentive models, and retrainer strategies, and re-deploying retreaders, was completed in the FluxVLA Engineering base. Taken together, FluxVLA results provide two different types of evidence. One category is engineering capacity: multiple isomeric strategies are integrated into the unified assessment system, and multiple real-time platforms have completed the corresponding closed-ring validation, demonstrating that they have demonstrated the ability to develop processes across models and platforms. Another category is the validation of model capabilities: differences in performance under different benchmarks, changes in success rate as a result of random layouts, and phased losses in long-range missions, all provide a more specific observational basis for model capabilities. The project base does not replace the optimization of the model itself, nor does it mean that all strategies automatically acquire excellent panorama capabilities; it provides a relatively uniform path of validation that allows developers to assess existing capabilities more reliably, identify problems and continue to improve in subsequent research and development. In 2026, the focus of smart competition was to move from a model to one whose data was more general, whose body was more inclusive and whose commercial path was clearer. Front-line firepower, rear graft, complete engineering ecology, like a scalable supply line, is more valuable than the front line post-production. The value of FluxVLA is not to solve all the engineering challenges of being smart, but to try to turn some of these recurring problems into reusable engineering mechanisms. Model registration and uniform configuration reduce the need for duplicated R & D processes; reasoning optimization, RTC and trajectories reprocessing, with some of the real-time implementation barriers split as a manageable link; online RL interface, which provides an engineering interface for the optimization of interactive data entry strategies; and cross-models and cross-platform assessments, which allow different strategies to be validated under corresponding conditions. Together, these capabilities point to a goal: to allow the R & D team to focus more on models, data and the mission itself than to repeat the same underlying engineering issues in each experiment. More importantly, the harmonization of engineering processes not only serves R & D efficiency, but also provides a more stable basis for validation and iterative model capabilities. Developers can compare different programmes in relatively consistent processes, observe the performance of strategies on different missions and platforms, and then bring back the problems identified to data, training and deployment. Besides, FluxVL A has an easy-to-neglected but, in our view, critical choice: not to seek unconditional compatibility of all components. Differences in data structure, action semantics, interfaces between models, data sets and robotics are objective and cannot be erased. FluxVLA is designed with a standard interface and modularization, so that these differences can be grouped into a searchable and symmetrical link — when there is a problem in combining them, one can know exactly where. In terms of the reliability of the project, this attitude that exposes the problem is more valuable than pretending that everything is compatible. As a furniture-body-smart mainframe, an inter-drive powered pit, validated process that could have served itself as a moat, but they chose to convert a line of experience into an open, standardized engineering base, with enterprise-level resources providing more possibilities for use and collaboration with outside developers, algorithm teams and other robotic platforms. Of course, this does not mean that open-source projects have naturally developed mature industrial ecology. True ecology also requires the continued use, matching of contributions, feedback of external teams and the validation of their value in different scenarios. However, open interfaces and reusable tools provide at least the basis for such collaboration. FluxVA Engineering Code Repository: https://github.com/FluxVLA/FluxVLA
Technical report: https://arxiv.org/abs/2609.17210Hugging Face: https://huggingface.co/limxdynamics/FluxVLAEngine
Original Ray Peak article, unauthorized reproduction. For further information, see the information below.
Auto-fetched and translated by AI Gem Box. All rights belong to the original author.