TurboVLA: A 0.2B Vision-Language-Action Policy That Runs at 32 Hz on an RTX 4090

The LLM bottleneck TurboVLA is built to remove

Most vision-language-action models route perception through a language model. An image is encoded, projected into the token space of a large LLM, and the LLM's hidden states are decoded into robot actions. The README calls this the V to L to A pathway and notes that it "incurs substantial computation and memory overhead at every policy invocation." That framing matters because a manipulation policy is invoked continuously, not once per task. Latency compounds across a control loop, and VRAM consumed by a language backbone is VRAM unavailable to batch size, image resolution or a second camera.

TurboVLA targets that specific cost. It is for robotics groups and evaluation engineers who want a manipulation policy that fits on one consumer GPU and can be called at control-loop rates. The abstract states the model has 0.2B parameters, 31.2 ms inference latency and 0.9 GB inference VRAM on an RTX 4090, with 97.7% average success on LIBERO. Those are the project's reported numbers, not independently reproduced here. The intended user is someone benchmarking on LIBERO or RoboTwin 2.0, not someone deploying to a factory floor today.

Direct V + L to A mapping and bidirectional vision-language interaction

The architecture drops the language model as the central interface. Visual observations and language instructions are encoded independently, then exchange information through what the README describes as lightweight bidirectional vision-language interaction. A compact decoder turns the resulting task-conditioned representation into continuous action chunks.

The encoder choices are visible in the asset table. DINOv3 ViT-B is used for LIBERO, DINOv3 ViT-L for RoboTwin, BERT base uncased for both, and GroundingDINO Swin-T OGC for both. That means the model is not self-contained at inference: BERT runs online during training and evaluation, and the README states this explicitly. GroundingDINO is a detector, so the pipeline depends on object-level grounding in addition to the vision backbone. Three pretrained external models plus the TurboVLA checkpoint is a larger dependency surface than the 0.2B parameter count suggests.

Predicting action chunks rather than single actions is the other half of the latency story. A chunk amortizes one forward pass across several control steps, which is how a 31.2 ms invocation can support a 32 Hz policy. The README does not document the chunk length or the action space, so treat that as something to read from the configs in experiments/ rather than from the documentation.

Installing TurboVLA for LIBERO or RoboTwin

The repository ships a pyproject.toml with two optional dependency groups, libero and robotwin, and the README recommends separate Python 3.10 environments because the two use different simulator and data stacks. Start by cloning and creating the LIBERO environment. The README instructs you to install a CUDA-compatible PyTorch build before the project dependencies.

git clone https://github.com/H-EmbodVis/TurboVLA.git
cd TurboVLA
conda create -n turbovla-libero python=3.10 -y
conda activate turbovla-libero
pip install torch==2.3.1 torchvision==0.18.1 --index-url https://download.pytorch.org/whl/cu121
pip install -e ".[libero]"

After that, LIBERO itself is installed separately into the same environment, following its own repository. The libero extra pulls robosuite 1.4.1, tensorflow and tensorflow-datasets, which is why the environment is heavy despite the small model.

The RoboTwin path differs in two ways: it adds flash-attn with an explicit pin, and it does not list a PyTorch version in the README snippet, only the instruction to install a CUDA-compatible build first.

conda create -n turbovla-robotwin python=3.10 -y
conda activate turbovla-robotwin
pip install -e ".[robotwin]"
pip install flash-attn==2.7.4.post1 --no-build-isolation

The --no-build-isolation flag matters: flash-attn compiles against the installed PyTorch, so the order in the README is not decorative. For the first real use, pull the checkpoint and inspect the expected data layout. Model weights and normalization metadata come from Hugging Face, not from the repository.

pip install -U huggingface_hub
hf download H-EmbodVis/TurboVLA --local-dir pretrained/TurboVLA

LIBERO evaluation expects four modified no-noops suites in TFDS/RLDS format under data/libero/, named libero_10_no_noops, libero_goal_no_noops, libero_object_no_noops and libero_spatial_no_noops, each under a 1.0.0 directory. If your data is the stock LIBERO release, the repository provides a regeneration script, and running it with --help prints the available flags rather than executing anything.

Training and evaluation entry points

Four console scripts are declared in pyproject.toml, and they are the honest map of what the repository supports. turbovla-libero-train maps to turbovla.training.train_mixed, turbovla-libero-eval maps to vla_adapter.rollout, turbovla-robotwin-train maps to experiments.robotwin.train, and turbovla-robotwin-eval maps to experiments.robotwin.evaluate. Two benchmarks, two commands each.

There is no inference-only script, no ONNX export, no TensorRT path and no ROS node in the declared entry points. The pyproject packages include a deployment wildcard in the setuptools find configuration, but the README does not document what lives under it. If your goal is to run this on a physical arm, the repository gives you a policy and an evaluation harness, not a deployment guide. That gap is the single largest thing to resolve before treating TurboVLA as production infrastructure.

Released normalization statistics live at experiments/libero/configs/libero_all4_stats.json, and the README notes that the Hugging Face release includes normalization metadata. Mixing statistics from one suite with data from another is a plausible silent failure, since the config is named for all four LIBERO suites together. The repository also provides scripts/libero/compute_mixed_stats.py for recomputing them, which is the right tool if you change the data mixture.

Where TurboVLA is the wrong choice

The TODO list has one unchecked item: support Huawei Ascend NPUs. The paper is a collaboration with Huawei, so NPU support is presumably intended, but the README does not describe a working path today. If your target hardware is Ascend, this repository does not currently serve you.

The second limitation is the dependency weight. A 0.2B policy that needs DINOv3 ViT-B or ViT-L, BERT base uncased and GroundingDINO Swin-T OGC at inference is not a small deployment even if the action head is. Each of those assets has its own licence, and the README does not enumerate them. The Apache-2.0 badge on this repository covers this repository.

Third, the RoboTwin extra pins a long list of exact versions, including accelerate 1.5.2, deepspeed 0.16.9, pyarrow 14.0.1 and torchvision 0.21.0. The README does not state which torchvision version pairs with the torch 2.3.1 used on the LIBERO side, and the two environments are separate precisely because they diverge. Expect the RoboTwin environment to be the harder of the two to reproduce.

Finally, the README does not document rollback, checkpoint compatibility between releases, or how to resume training. There are no retrieved releases, so version-to-version upgrade behavior is unknown.

How TurboVLA differs from LLM-centric VLA policies

The natural comparison is with VLA models that keep a language model in the loop, such as OpenVLA-style architectures. The difference is structural rather than a matter of tuning. An LLM-centric policy pays for language-model capacity on every invocation, which is where its generality and instruction-following range come from. TurboVLA trades that capacity for independent encoders and a small decoder, which is where its latency and memory numbers come from.

The trade-off is real. A 0.2B model with a fixed vision backbone and a BERT text encoder has less room to absorb unusual phrasing, long-horizon reasoning or open-ended instructions than a multi-billion-parameter backbone. The reported 97.7% is an average over LIBERO suites, a benchmark with a bounded instruction distribution. That number says the compact design is sufficient for those suites. It does not say the design generalizes the way a large language backbone does.

If your task distribution is closed and your constraint is a single GPU, the direct mapping is the better fit. If your requirement is broad instruction generalization and you can afford the hardware, the LLM-centric route is still the one with more headroom. TurboVLA's contribution is showing that the second option is not always necessary.

Licence, maintenance and what the repository does not tell you

TurboVLA is Apache-2.0, and the pyproject declares license = {file = "LICENSE"}. That is a permissive licence for the code in this repository. It does not extend to the external assets the model depends on. DINOv3, BERT, GroundingDINO and the LIBERO and RoboTwin simulators each carry their own terms, and the README lists their source repositories without stating their licences. Anyone shipping a product built on this stack needs to check those separately. Nothing here is legal advice.

The last push to the default branch was on 2026-09-02, and the repository is not archived. The news entries record the model checkpoints and the training and evaluation code being released on 2026-07-31 and 2026-07-30 respectively. There are no retrieved releases, so there is no tagged version to pin and no changelog to read. Upgrading means tracking main.

Upgrade cost is dominated by the environment, not the code. The libero and robotwin extras pin different simulator stacks, and the RoboTwin extra pins exact versions across a dozen packages. A Python or CUDA bump on your machine will likely require re-resolving those pins, and flash-attn will need to recompile. Budget for that before you plan a version upgrade, and read experiments/libero/configs/libero_all4_stats.json alongside any checkpoint you download, because the README ties normalization metadata to the release rather than to the code.

Editorial conclusion

Adopt TurboVLA if you have a single consumer GPU, a LIBERO or RoboTwin 2.0 evaluation target, and the patience to assemble DINOv3, BERT and GroundingDINO checkpoints plus RLDS-format data before anything runs. Do not adopt it if you need a documented deployment path to real hardware, Ascend NPU support, or a camera-to-actuator pipeline you can read in the repository. Before committing, verify three things: that the Hugging Face release contains the normalization metadata your suite needs, that your LIBERO data is in the four no-noops suites the loader expects, and that flash-attn 2.7.4.post1 builds against your CUDA and PyTorch combination, because the RoboTwin extra pins it and the README does not describe a fallback.

Frequently asked questions

Official sources

1. H-EmbodVis/TurboVLA on GitHub
2. Issues
3. License: Apache-2.0
4. README