# FluxVLA Engine: one repository for training and deploying vision-language-action models

> FluxVLA Engine is a full-stack platform for embodied AI that pairs several VLA model families with a shared configuration and deployment layer, plus a CUDA extension built at install time. The README's Libero table is the project's own reporting, and the platform is at version 0.1.5.

**FluxVLA/FluxVLA** — An all-in-one VLA engineering platform for embodied AI — from data to real-robot deployment.

- Repository: https://github.com/FluxVLA/FluxVLA
- Website: https://fluxvla.limxdynamics.com
- Stars: 756 · Forks: 82
- Language: Python
- License: Apache-2.0
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/fluxvla-fluxvla

## The pitch is a complete loop from data to a real device

FluxVLA Engine is described in the README as a full-stack, end-to-end engineering platform for deploying embodied intelligence applications, built around four stated design principles: unified configuration, standardized interfaces, module decoupling, and deployability. The goal is a complete engineering loop from data to real-device deployment, with the stated aim of providing a standardized industry, academia and research foundation. The real-robot demonstration in the README covers mobile manipulation, tabletop tidying, bimanual cloth folding, and retrieving an object from a bag, which shows the range of tasks the platform is aimed at. This is not a single model release. It is a container for a family of models plus the training, evaluation and deployment machinery around them, and the versioning makes that clear, since the release notes for 0.1.3, 0.1.4 and 0.1.5 describe new model families and new robot support rather than model weights alone.

## One platform over several VLA backends, with the weights on Hugging Face

The performance table in the README lists six configurations of the platform across four Libero suites: spatial, object, goal and long. FluxVLA with SmolVLA, with Cosmos3-Edge, with GR00T N1.5, with GR00T N1.7, with a Qwen3VL 0.6B front end on GR00T N1.5, and with DreamZero. Each row links to a Hugging Face model tree under limxdynamics/FluxVLAEngine, so the checkpoints and the platform are published separately. The averages the table reports run from 84.7 for the SmolVLA row to 96.20 for the Qwen3VL 0.6B row, with GR00T N1.7 at 95.93 and GR00T N1.5 at 95.3. These are the project's own reported figures and each links out to the corresponding checkpoint, so treat them as claims to reproduce rather than independent measurements. The spread between the weakest and strongest row is large enough to suggest that the choice of backbone matters more than the platform wrapper for a given suite.

## Dependencies are split into base, simulation and real robot sets

The requirements files show how the project separates concerns. requirements.txt pulls in the other three with -r, and the comment at the top says the full FluxVLA dependency set is installed this way, with the note that CUDA PyTorch should be installed first or the environment script used, and that TorchCodec is optional and installed version-aware by the environment scripts. The separate requirements-base.txt, requirements-sim.txt and requirements-real.txt files mean a simulation-only user does not need the hardware-side packages, and a user about to touch a physical robot can add the real-world set without changing the base. The repository root reinforces this structure with dedicated directories for checkpoints, configs, datasets, docs, tools, tests and the fluxvla package itself, plus a pytest.ini for the test suite and a setup.cfg. The top-level requirements file pulls in the three sets with -r directives, and its comments say to install CUDA PyTorch first or use scripts/install_env.sh, and that TorchCodec is optional and installed version-aware by the environment scripts.

## A torch CUDA extension is compiled at install time

The setup.py is the most revealing file in the repository for anyone planning an install. It imports torch and the CppExtension, CUDAExtension and BuildExtension helpers from torch.utils.cpp_extension, then defines a make_cuda_ext function that picks the extension type at build time. If torch.cuda.is_available() returns true, or the environment variable FORCE_CUDA is set to 1, the build defines a WITH_CUDA macro, selects CUDAExtension, and passes nvcc flags that disable half-precision operators, conversions and half2 intrinsics, then adds the CUDA sources. Otherwise the script prints a message that it is compiling without CUDA and falls back to a plain CppExtension. The repository also carries .clang-format, .clang-tidy and .cpplint configuration files and a pre-commit configuration, which tells you the native extension is expected to be edited by contributors. The practical consequence is that installation needs a working CUDA toolchain for the accelerated path. The decision point in setup.py looks like this.

```python
    if torch.cuda.is_available() or os.getenv('FORCE_CUDA', '0') == '1':
        define_macros += [('WITH_CUDA', None)]
        extension = CUDAExtension
        extra_compile_args['nvcc'] = extra_args + [
            '-D__CUDA_NO_HALF_OPERATORS__',
```

So a machine without a visible GPU still installs, just without the CUDA path, and FORCE_CUDA is the switch that forces the accelerated build when the detection is wrong.

## Release notes describe hardware and model support arriving in steps

The three most recent tags read like a roadmap. v0.1.3, released 2026-06-18, added ARM reward modeling, GR00T RoboCasa, a unified data pipeline, and Pi0.5-RTC acceleration. v0.1.4, released 2026-07-13, added Franka and Oli support, GR00T-RTC acceleration, and what the notes call scalable evaluation. v0.1.5, released 2026-09-11, added new model families, GR00T N1.7, and Jetson Orin deployment. Two patterns stand out. Acceleration work arrives repeatedly, in the form of RTC acceleration for different backbones, which suggests inference latency was the practical bottleneck. And device support arrives one robot at a time, Franka and Oli and then Jetson Orin, which tells you the deployment story is hardware-specific rather than general. The repository is not archived and the last push was on 2026-10-19, so this is moving quickly in a young release line.

## Publishing, citation and the boundaries of the documentation

The project takes its academic packaging seriously. The README links an arXiv entry with the identifier 2609.17210, the repository contains a CITATION.cff file and a technical report PDF, and there is a CHANGELOG.md alongside English, Simplified Chinese and Japanese READMEs. Documentation is hosted at fluxvla.limxdynamics.com with a separate Chinese version at a /zh/ path, and a Hugging Face organisation publishes the engine under the name FluxVLAEngine. The licence is Apache-2.0, which is the permissive variant with an explicit patent grant, and the LICENSE file at the root is the version to read before you build on it. The main gap is depth. The README excerpt that describes the framework and the benchmark table does not walk through a training script, an evaluation command or a deployment configuration, so a reader is told the platform covers the whole loop without being shown the commands. The docs site is where that detail has to live, and the README does not summarise it.

## Conclusion

FluxVLA Engine suits robotics teams that want one repository covering data, training, evaluation and on-device deployment across several VLA model families instead of a single model script. It is a poor fit for a group without CUDA hardware or a robot, since the setup compiles a torch CUDA extension and the real-world requirements are installed separately from the simulation ones. Verify first which model family matches your task, read the Libero table in the README as the project's own reported numbers rather than an independent benchmark, and check that scripts/install_env.sh completes on your machine before planning a training run around it.

## FAQ

### What is FluxVLA Engine used for?

The README describes it as a full-stack, end-to-end engineering platform for deploying embodied intelligence applications, creating an engineering loop from data to real-device deployment. It covers training, evaluation and deployment for vision-language-action models.

### Which VLA model families does FluxVLA Engine support?

The README performance table lists configurations built on SmolVLA, Cosmos3-Edge, GR00T N1.5, GR00T N1.7, a Qwen3VL 0.6B front end with GR00T N1.5, and DreamZero, with each row linking to a checkpoint on Hugging Face.

### How do I install FluxVLA Engine?

The requirements file states that the full dependency set is assembled from requirements-base.txt, requirements-sim.txt and requirements-real.txt, and that CUDA PyTorch should be installed first or the environment script scripts/install_env.sh used. The setup.py compiles a torch CUDA extension, choosing the CUDA path when a GPU is available or FORCE_CUDA is set to 1.

### What licence does FluxVLA Engine use?

The repository is licensed under Apache License 2.0, and the setup.py header carries the Apache 2.0 notice. The LICENSE file at the repository root holds the full terms.

## Sources

- [FluxVLA/FluxVLA on GitHub](https://github.com/FluxVLA/FluxVLA)
- [License: Apache-2.0](https://github.com/FluxVLA/FluxVLA/blob/main/LICENSE)
- [Project website](https://fluxvla.limxdynamics.com)
- [README](https://github.com/FluxVLA/FluxVLA/blob/main/README.md)
- [Releases](https://github.com/FluxVLA/FluxVLA/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/fluxvla-fluxvla