A Comprehensive Breakdown of the Technical Report on FluxVLA Engine, an Open-Source Engineering Foundation. Author |Deng Zemin
Editor |Qi Chengyong
How far is it from a model achieving strong results in a paper to actually driving a robot to complete tasks? Whether a model can integrate with existing data and training workflows, whether its inference speed can keep pace with a robot’s control cadence, whether the motions it generates can be executed continuously and reliably, and whether its experimental results can be validated on different robots—these problems cannot necessarily be solved by raising the model’s success rate by another few percentage points.Over the past six months, AI Tech Review (Leiphone (official WeChat account: Leiphone)) found in conversations with industry professionals that several recurring engineering problems were consuming substantial R&D resources: data formats across different models are difficult to unify, training and evaluation workflows are siloed, and results obtained in simulation may not hold up on real robots; after finally getting one workflow to run, switching to a different model, dataset, or robot may require readapting it all over again.Models are constantly iterating, yet the engineering work they produce does not necessarily accumulate and endure.This brought to mind for Leiphone the development of deep learning. In 2017, PyTorch was officially open-sourced. From then on, the framework, toolchain, and developer community continued to mature, enabling researchers to conduct experiments on more mature infrastructure without having to rebuild their environments from the ground up every time. Although embodied intelligence today faces different technical challenges, it likewise needs to solve a problem: how to make existing R&D achievements easier to reuse and allow different technical approaches to collaborate within a unified engineering framework.FluxVLA Engine, open-sourced by LimX Dynamics, seeks to address this problem at the engineering level.It is not yet another VLA model competing for the top spot in model-performance rankings, but an engineering foundation for embodied AI R&D that connects data, training, evaluation, inference, and deployment on real robots. On October 22, FluxVLA Engine completed a major update. We dissected its latest technical report and focused on four questions: Can models with different architectures be integrated into the same R&D system? What engineering hurdles must models overcome to move from simulation to real robots? How can real-world interaction experience be fed back into model optimization at low cost? What capabilities does it demonstrate when the same workflow covers more models and robots?
01
Register new models first
Whether an engineering foundation is genuinely useful depends first on whether it can accommodate different models. In embodied AI, models iterate the fastest. A team may use one VLA architecture today and try a different approach to action generation tomorrow; the same team may also be researching multiple policy models simultaneously. If every model change requires reorganizing data, writing evaluation code, and modifying deployment interfaces, the engineering experience accumulated over time will struggle to retain its value. Models may change constantly, but the engineering capabilities built around data, evaluation, and deployment should not have to start from scratch every time. FluxVLA Engine takes a different approach: through unified configuration and component registration mechanisms, it consolidates as much as possible the differences that need to be handled when integrating different models into the R&D workflow into clearly defined interfaces. Think of it as a unified experiment checklist plus a catalog of callable components. The configuration file declares which model an experiment should use, how the data should be processed, how the evaluation should be conducted, and which interface should be used for deployment. The registration mechanism separately organizes components such as visual backbones, action heads, training runners, and robot-operation components. Developers can combine already-adapted components as needed, without having to rebuild the entire engineering workflow for every model. This does not mean that any model can run directly without adaptation. Different architectures may still require their own adapters, action-space conversions, and normalization handling. The real value lies in: placing unavoidable differences in a manageable component layer, allowing shared workflows that have already been connected to remain reusable . According to the technical report, FluxVLA has incorporated policies with substantially different architectures into a single R&D and evaluation system, including OpenVLA, which follows an autoregressive approach; π0.5, which follows a flow-matching approach; and models based on different technical paths, such as DiT4DiT and GR00T. This means that a unified engineering framework need not come at the cost of model diversity. FluxVLA’s model integration is not limited to open-weight models. GPT-6 Astra was previously integrated through an API-only approach, running the same closed-loop evaluation without providing weights or participating in training; the evaluator still completed the workflow and preserved the evidence. Just two days after the latest technical report was published, MiniMax-M3.1-Flash became the second checkpoint-free, API-only inference policy after GPT-6 Astra, ready to run evaluations on LIBERO and RoboCasa GR1 out of the box. The data layer follows the same logic. Trajectory data generated by different robots and in different simulation environments can be converted into a standard format and then trained on together within the same pipeline, or kept in separate groups while retaining their respective normalization conventions. A dataset curated for a particular model today can still be used with a different model tomorrow. Accumulated engineering work does not reset when the technical approach changes—this is what enables the industry’s R&D results to build continuously on one another instead of canceling each other out.Ultimately, data is the most expensive asset in embodied intelligence. Making this asset depreciate less and be reused more is itself an industry-level cost reduction.
02
Three Steps to Deploying on Real Hardware
In the end, a policy still has to land in the physical world. A model may achieve a high success rate in simulation, but once deployed on real hardware, its performance may drop sharply. This may not be a problem with the model itself; rather, there is a systemic engineering gap between model inference and robot execution.This gap is the result of three layers of overlapping issues. None can be solved by a better model alone; each requires a mechanism, and the three mechanisms must collaborate in sequence to address the respective layer.First, model inference is too slow to keep up with the robot's control cadence.The control loop of a humanoid robot requires high-frequency action commands, but inference with large VLA models is often far too slow—the model is still computing the next step while the robot has already completed the current action and is left waiting. The time difference between the two directly causes sluggish robot motion or loss of synchronization.FluxVLA's solution is to use a more efficient execution graph for the same set of learned parameters. Specifically, for the two mainstream routes, GR00T and π0.5, the system improves execution efficiency by pre-recording computational steps that are executed repeatedly into a fixed execution graph (CUDA Graph), together with optimizations such as low-level operator fusion.This step leaves the model weights untouched—numerical alignment tests for the GR00T action head show that the cosine similarity between the output actions before and after acceleration exceeds 0.99999.One set of figures from our measurements left us impressed. On NVIDIA's AGX Orin 64GB edge chip (the “onboard brain” of many humanoid robots), GR00T's inference frequency increased from 3.2 Hz to 7.4 Hz, while π0.5's increased from 1.4 Hz to 4.4 Hz.On the same chip and with the same model, optimization boosted model inference throughputtwo- to threefold
.Second, there is a temporal misalignment between prediction and execution.VLA models typically predict a chunk of the action sequence at a time, allowing the robot to execute one chunk while predicting the next, thereby reducing the query frequency. But when the computation of a new prediction is complete, the moment corresponding to its beginning has often already passed, and the robot has already progressed beyond that point in the sequence. Directly stitching the new action sequence onto the previous one causes obvious jumps, manifesting as jitter and discontinuity at the joints.FluxVLA chose to use RTC (Real-Time Chunking) to solve this temporal misalignment problem,treating the portion of the previous action sequence that has not yet been executed as the condition for the next prediction.When generating a new sequence, the model already knows what the robot will do next, so the new action naturally continues from that state.The technical report provides two implementation approaches: one adds latency-conditioned simulation during training and uses prefix conditioning at inference; the other leaves the training process unchanged and can be applied directly to existing models.The third layer: the action sequence may not be physically executable.Even after temporal alignment has been resolved, one final hurdle remains. The action sequence output by the model may not, at the physical level, conform to the robot’s motion limits. After normalized predictions are converted back into actual joint angles and velocities, a sequence may imply excessive acceleration or local oscillations. Put simply, the motions may be too aggressive or may switch abruptly between fast and slow, exceeding the envelope within which the robot can execute them smoothly.What trajectory post-processing does is perform a kinematics-constrained optimization before the action sequence is actually sent to the robot,constraining velocity, acceleration, and their rates of change to ranges in which they can be executed safely.FluxVLA provides two backends: one performs more refined solving, with a processing latency of about 4.9 milliseconds; the other is about four times faster, with latency of only 1.17 milliseconds, at the cost of slightly lower tracking fidelity and a degree of reference lag. Each is suited to different scenarios, and either can be freely selected in the configuration.The most elegant aspect of these three mechanisms is their sequential cooperation.Inference acceleration makes the model fast enough to keep up with the control loop; RTC lets new action sequences connect naturally with the action currently being executed; and trajectory post-processing ensures that the final commands issued satisfy the robot’s physical constraints. Together, these three stepsbreak the engineering gap between model prediction and execution on a real robot—often glossed over—into stages that can be pinpointed and addressed independently.
TAG290@@03
Bringing real-world interaction experience into the training loop
Once the model is deployed on a real robot, what comes next?In the mainstream development paradigm for embodied intelligence, the usual workflow is: collect human demonstration data, train the model, test it, collect data again, and repeat. This approach has already driven advances in many robotic manipulation capabilities, but the range of situations covered by demonstration data is ultimately limited. Factors such as object position, lighting, and the robot’s initial state in real environments constantly change, so the model may encounter situations that are not sufficiently covered in the training data. If every discovered problem can only be addressed by manually supplementing the demonstration data, the pace of model improvement will be constrained by the data collection and training process.FluxVLA, inthis update, introduced online reinforcement-learning post-training, directly addressing this problem.From an engineering design perspective, this approach is quite restrained in scope. FluxVLA did not choose to implement RL itself, but instead connected with RLinf, a system specializing in large-scale RL training, allowing each to do what it does best: FluxVLA retains model construction, observation processing, and action conversion, while RLinf is responsible for rollout collection, optimization algorithms, and weight synchronization. The two connect through an interface; the same model requires no changes, and once the RLinf front end is connected, it can enter the online RL training loop. This division of labor leaves the existing supervised training workflow entirely unaffected. RL is an optional incremental capability, rather than a replacement for the existing workflow.In open-source projects, taking on everything is the norm, while handing off areas one is not good at is rare. By leaving interfaces at its boundaries and collaborating with external systems, FluxVLA shows that it has a clear understanding of its positioning and is not trying to become an all-in-one toolkit.That said, online reinforcement learning does not mean robots can automatically understand every failure, nor does it guarantee that longer training will necessarily produce a stronger model. What it provides is a path for optimizing policies using interaction data; the final results still depend on reward design, training setup, and task conditions.The technical report presents a set of paired experimental results: on LIBERO-10, SmolVLA’s success rate rose from a baseline of 66.2% to 76.2%, an increase of 10 percentage points; on 10 tasks in the RoboTwin Clean setting, it rose from 45.9% to 61.3%, an increase of 15.4 percentage points. The RoboTwin experiments also recorded 231 previously failed episodes that became successful after training, but 77 previously successful episodes that regressed. This means that although overall policy performance improved, optimization was not achieved across all cases simultaneously. The report also notes that, as training continued, the success rate on LIBERO-10 declined slightly from its peak.
These experiments also validated an important direction:when policy interaction, data collection, and training optimization can form an engineering closed loop, experience gained during real-world execution can be used to improve subsequent modelsinstead of remaining confined to the results of a single test. For the industry as a whole, this means the R&D process can expand from the one-way flow of “collect demonstrations—train—test” to “execute—collect experience—optimize the policy—execute again.”
04
Breadth of coverage is the hard metric
Whether an engineering system can deliver value also depends on the scope over which it has been validated.If it supports only a handful of models or can run only on a single robot, its reusability remains limited. Conversely, if multiple heterogeneous policies can enter the same evaluation framework and complete the relevant tests on different robot platforms, it is more likely to demonstrate that the engineering framework has a degree of generality. The evaluation results in the FluxVLA technical report provide several aspects worth examining.
On the simulation side, as mentioned in the first section, policies with vastly different internal structures can share the same data pipeline and evaluator. In concrete numbers, the technical report integrated 14 policies into LIBERO, and 11 of the 13 local checkpoints achieved average success rates above 95%. Two details were not explored previously.First,difficulty stratification.LIBERO tests short tabletop tasks, and some of the high scores are attributable to the task characteristics of the benchmark itself. When the same policies were moved to the more challenging RoboCasa GR-1, which is closer to real-world home manipulation, their average success rates fell to between 8.75% and 57.25%. It is important to note that this gap stems from differences in task difficulty, not from an issue with the evaluation criteria. The report also explicitly states that the two sets of results came from different model architectures, data budgets, and training pipelines and therefore do not constitute a controlled comparison.Validating policies on tasks of varying difficulty is not merely about obtaining a success-rate figure; more importantly, it helps developers determine what the model can currently accomplish and which tasks still have room for improvement. The unified evaluation pipeline provided by FluxVLA enables this type of capability validation to be conducted continuously on the corresponding benchmarks. Second is generalization. RoboDojo’s 42 tasks and 2,100 trials per model show that most models can complete some portion of a task, but far fewer can complete the entire task from start to finish. When task layouts change from fixed to randomized, the success rate of the highest-ranked model, π0.5, drops from 16% to 2.33%, while the other seven models peak at just 0.67%. These figures make it easy to see the shared predicament of all mainstream policies when confronted with previously unseen scenarios. On the real-robot side, coverage has expanded to four platforms: the ALOHA bimanual system (6 tasks and 7 policy configurations), Oli, LimX Dynamics’ in-house full-size humanoid robot, Rebot, and the bimanual Franka. Policies trained and validated in simulation were deployed directly through the same deployment pipeline to four platforms with widely varying morphologies, and all completed closed-loop testing. One interesting set of details on Oli is the four-stage box-moving task: GR00T N1.5 and π0.5 have nearly identical completion rates through the first three stages (60% versus 61.67%), but their end-to-end completion rates are only 6.7% and 33.33%. Success in long-horizon tasks is multiplicative, not additive; small deviations accumulated in the earlier stages are amplified stage by stage later on. We had heard this issue many times in conversations with industry practitioners, but could only understand and imagine it. This time, FluxVLA’s evaluation design, which records completion stage by stage, allowed us to see the phenomenon clearly. The data from folding towels with ALOHA best demonstrate the value of closed-loop evaluation. With traditional behavior cloning—simply having the model reproduce actions demonstrated by humans—the success rate was only 62.1%. A different approach was to first train a reward model that enables the system to assess how well each action is performed, then use that assessment in turn to guide policy training. The success rate rose to 99.4%. The entire process, from collecting data on real robots and training the reward model to retraining the policy and deploying it back onto the real robot, was completed on a single FluxVLA Engine foundation. Overall, FluxVLA’s evaluation results provide two distinct forms of evidence. One is engineering capability: a diverse range of heterogeneous policies has been incorporated into a unified evaluation system, and multiple real-robot platforms have completed the corresponding closed-loop validation, demonstrating its ability to organize R&D workflows across models and platforms. The other is the verifiability of model capabilities: differences in performance across benchmarks, changes in success rates caused by randomized layouts, and stage-by-stage degradation in long-horizon tasks have all provided more concrete observational evidence for the boundaries of model capabilities. An engineering foundation does not replace optimization of the models themselves, nor does it mean that every policy will automatically acquire strong generalization capabilities. What it provides is a relatively unified validation path that enables developers to assess existing capabilities more reliably, identify problems, and continue making improvements in subsequent R&D. 
05
An Army Without Provisions Perishes
The focus of embodied intelligence competition in 2026 is gradually shifting from whose model performs better to who has more and broader data, whose robot platform is more durable and reliable, and whose path to commercialization is clearer. The front lines compete on firepower, while the rear competes on supplies. A complete engineering ecosystem is like a dependable supply line: the later the stage of the campaign, the more valuable it becomes.The value of FluxVLA does not lie in solving all the engineering challenges of embodied intelligence, but in attempting to turn some of the recurring ones into reusable engineering mechanisms. Model registration and unified configuration reduce the need to repeatedly build R&D workflows; inference optimization, RTC, and trajectory post-processing break some barriers to real-robot execution into manageable stages; integration with online RL provides an engineering interface for interaction data to enter policy optimization; and cross-model and cross-platform evaluation allows different policies to be validated under the relevant conditions.
Together, these capabilities point toward a single goal: enabling R&D teams to devote more energy to the models, data, and tasks themselves, rather than repeatedly dealing with the same foundational engineering problems in every experiment. More importantly, unifying engineering workflows not only improves R&D efficiency, but also provides a more stable foundation for validating and iterating on model capabilities. Developers can compare different approaches within relatively consistent workflows, observe how policies perform across different tasks and platforms, and then feed the problems they uncover back into the data, training, and deployment stages.
In addition, FluxVLA makes an easily overlooked but, in our view, critical choice: it does not seek to make every component unconditionally compatible. The differences in data structures, action semantics, and interfaces across different models, datasets, and robot embodiments objectively exist, and no one can eliminate them. FluxVLA uses standard interfaces and modular design to concentrate these differences in inspectable and adaptable stages, so that when something goes wrong in a combination, people can identify exactly where the problem lies. In terms of engineering reliability, this willingness to expose problems is more valuable than pretending that everything is compatible.
As an embodied intelligence hardware OEM, LimX Dynamics could have turned the pitfalls it encountered and the processes it validated in robot embodiment development, algorithm R&D, and real-robot operation into a moat serving its own products. Instead, it chose to translate frontline experience into an open, standardized engineering foundation, using enterprise-level resources to provide external developers, algorithm teams, and other robot platforms with more opportunities to use and collaborate with the technology. Of course, this does not mean that the open-source project has naturally developed into a mature industry ecosystem. A genuine ecosystem still requires external teams to use it continuously, contribute adaptations, report issues, and validate its value in different scenarios. Open interfaces and reusable tools, however, at least provide the foundation for such collaboration.
FluxVLA Engine code repository: https://github.com/FluxVLA/FluxVLA
Technical report: https://arxiv.org/abs/2609.17210Hugging Face: https://huggingface.co/limxdynamics/FluxVLAEngine
Original Leiphone article. Unauthorized reproduction is prohibited. See the Reposting Notice for details.
