# VLA-Adapter: tiny-scale vision-language-action training from 10GB to 80GB

> The official code for a tiny-scale vision-language-action model, with training configurations for GPUs from 10GB to 80GB of VRAM, four LIBERO checkpoints on Hugging Face and an ALOHA path verified on the Cobot Magic platform. The dependency file disagrees with its own install instructions about Flash Attention and the transformers fork, which is where a first run can go wrong.

**OpenHelix-Team/VLA-Adapter** — VLA-Adapter: An Effective Paradigm for Tiny-Scale Vision-Language-Action Model

- Repository: https://github.com/OpenHelix-Team/VLA-Adapter
- Website: https://vla-adapter.github.io/
- Stars: 2,334 · Forks: 213
- Language: Python
- License: MIT
- Published: 2026-10-13 · Updated: 2026-10-13 · Language: en
- Canonical page: https://hysenlabs.com/projects/openhelix-team-vla-adapter

## A tiny-scale VLA paradigm for GPUs under 80GB

This repository holds the official code for a vision-language-action model that its authors describe as tiny-scale rather than large. In pyproject.toml the package description reads "VLA-Adapter: An Effective Paradigm for Tiny-Scale Vision-Language-Action Model", the paper sits at arxiv 2509.09372, and the project page is vla-adapter.github.io. Its reader is a robotic learning researcher who owns a workstation GPU and cannot rent a cluster. The table of contents makes that concrete by promising training configurations for GPUs ranging from 10GB to 80GB of VRAM, and the repository topics are embodied-ai, robotics and vision-language-action-model. Nothing in the entry surface asks for a build system or a container; the whole installation path is conda plus pip.

## The VRAM ladder spans five tiers of GPU

Every tier in the README table of contents links to its own training file, so this is a set of configurations rather than one default script. At the bottom, a 10GB to 12GB card covers the NVIDIA GeForce RTX 2080Ti, 3060, 3080, 4070, 4080 and 5070. A 24GB card is named as the GeForce RTX 3090 and 4090 tier, a 32GB consumer card as the GeForce RTX 5090, and a 40GB to 48GB professional tier lists the A100-40GB, A800-40GB, L20 and RTX A6000. Cards at 80GB and above form a single group: the A100-80GB, A800-80GB, H100, H800, H20-NVLink and GB200. Nothing in that ladder changes the dataset or the evaluation, only how much memory a run is allowed to use, which is the whole difference between a 3060 in a lab and an H100 in a cluster.

## Conda env 3.10.16, editable install, flash-attn 2.5.5

Four steps set up the environment, and each one checks something. Start by pinning the interpreter, because the Flash Attention wheel quoted later in the README is a cp310 build:

```bash
# Create and activate conda environment
conda create -n vla-adapter python=3.10.16 -y
conda activate vla-adapter
```

Then install the exact PyTorch triple the package pins, clone the repository and put the package on the path in editable mode:

```bash
# Install PyTorch
# Use a command specific to your machine: https://pytorch.org/get-started/locally/
pip install torch==2.2.0 torchvision==0.17.0 torchaudio==2.2.0
```

```bash
git clone https://github.com/OpenHelix-Team/VLA-Adapter.git
cd VLA-Adapter
pip install -e .
```

Before any training code runs, confirm Ninja is usable, since Flash Attention compiles against it. That check prints a version number and an exit status, and the README says the status should be 0:

```bash
pip install packaging ninja
ninja --version; echo $?  # Verify Ninja --> should return exit code "0"
```

Flash Attention comes last, after the editable install, and no build isolation:

```bash
pip install "flash-attn==2.5.5" --no-build-isolation
```

The wheel the README names for that version is `flash_attn-2.5.5+cu122torch2.2cxx11abiFALSE-cp310-cp310-linux_x86_64.whl`, which narrows the supported setup to one CUDA build, one torch build and one Python minor version. On any other combination the recipe falls back to compiling from source, and the README's own advice is to clear the pip cache first.

## pyproject.toml comments out flash_attn and the transformers fork

Two contradictions sit inside the dependency file, and both matter. Timing is the first: flash_attn sits commented out with an inline note that it must be installed after the editable install, which is exactly why the README pushes that pip line to the end of the sequence. A second one concerns the library itself. An inline note on the transformers pin is marked IMPORTANT and points at a fork for bidirectional attn used by parallel decoding, while the fork reference is commented out on the same line:

```toml
# "flash_attn==2.5.5",      # Here for documentation -- install *AFTER* editable install (follow README)
"transformers==4.40.1",#"transformers @ git+https://github.com/moojink/transformers-openvla-oft.git",  # IMPORTANT: Use this fork for bidirectional attn (for parallel decoding)
```

So a plain `pip install -e .` hands you stock transformers 4.40.1 while the same file insists on the fork. Anyone depending on parallel decoding has to swap that dependency by hand before touching the model code. Looser still is the interpreter floor: `requires-python = ">=3.8"` and the classifiers list 3.8, 3.9 and 3.10, yet the environment pins `python=3.10.16` and the wheel is cp310. Declared support for 3.8 and 3.9 is paper rather than an exercised path.

## Four LIBERO checkpoints on Hugging Face, CALVIN only in the index

The original version went out on 2025/09/12 for four LIBERO models through the Hugging Face collection linked in the README, one day after the paper appeared on ArXiv, and a Pro version followed on 2025/09/22 with the note that it conforms to the paper's pipeline but is optimized in implementation. The repository itself has no GitHub releases. Data preparation is marked optional: the README points at the LIBERO repository to clone and install, and its table of contents carries a separate CALVIN benchmark section plus a benchmark location section. No CALVIN checkpoint is named anywhere, so the four published models are the LIBERO set. Where the code sits at the top level is short enough to read off:

```bash
experiments/
vla-scripts/
prismatic/
pretrained_models/
eval_logs/
our_envs.txt
```

`pretrained_models/` is the only top level entry that names weights, and `eval_logs/` the only one that names output. Real-world work lives under `experiments/robot/aloha/`.

## ALOHA on Cobot Magic splits training from inference

One news entry, dated 2026/03/16, is the part of this project that leaves simulation: real-world ALOHA deployment support was added and verified on the Cobot Magic platform, and the README credits three pieces of work, training, server-client inference and evaluation, with details under `experiments/robot/aloha/`. That path carries its own constraints. A server and a client are two machines, and the wheel named in the install recipe pins one CUDA build (cu122), torch 2.2 and Python 3.10, so both ends have to agree before anything connects. Other hardware targets are still open: Franka, UR-5 and AGILE Piper are named in the TODO list as real-world systems to be added, next to the paper's own configuration, and that checkbox is unticked.

## Alpha packaging and an unfinished TODO list

Three facts bound what a checkout gives you. Package version 0.0.1 comes with classifiers that read Development Status :: 3 - Alpha, an early label for research code rather than a stable library. The repository is not archived and the last push was on 2026-03-19, and the code sits under the MIT licence, the usual choice for academic code that other labs are meant to build on. Third comes the TODO list, where VLA-Adapter++ and its technical report, updates to diffusion transformer and flow matching policy networks, expanded generalization, reinforcement learning post-training and dual-system compatibility are all unticked. Read that list as the honest roadmap: the fine-tuning path, the four LIBERO checkpoints and the ALOHA deployment are the finished part, and foundation model support such as VPP at arxiv 2412.14803 is not in the tree yet.

## Where the adapter route and full fine-tuning diverge

Fine-tuning the whole vision-language-action model end to end, with a trainable backbone, is the alternative approach. This repository's answer shows up in three places. Pinned dependencies include peft==0.11.1, a parameter-efficient fine-tuning library, so adapters rather than full weight updates are the intended path. Training configurations in the table of contents go down to 10GB to 12GB of VRAM, and no full fine-tuning configuration is listed at any tier, including the 80GB group. An unchecked TODO line still asks for more experiments on the Frozen backbone, so the comparison between frozen and tuned backbones is unfinished here and the paper's own numbers are the only source for it. On benchmarks the split is equally sharp: LIBERO is what the four published checkpoints target, while CALVIN exists as a data preparation section, which makes LIBERO the realistic first evaluation and CALVIN the one to check yourself before relying on it.

## Conclusion

Adopt this repository if you want the reference implementation behind a tiny-scale vision-language-action model and you have a GPU between 10GB and 80GB of VRAM. Leave it alone if you need VLA-Adapter++, the foundation model support still listed as unticked, or a package that installs without swapping the transformers fork line in pyproject.toml. Before anything else, match your torch, CUDA and Python combination against the flash-attn wheel named in the install recipe, and check whether the four LIBERO checkpoints cover the task you plan to evaluate.

## FAQ

### What GPU do I need to train VLA-Adapter?

The README offers training configurations for five VRAM tiers, from 10GB to 12GB cards such as the GeForce RTX 2080Ti, 3060, 3080, 4070, 4080 and 5070, through 24GB, 32GB and 40GB to 48GB tiers, up to professional cards at 80GB and above such as the A100-80GB, H100, H800, H20-NVLink and GB200.

### Which Python version does VLA-Adapter need?

The environment recipe pins `python=3.10.16`, and the Flash Attention wheel quoted in the README is a cp310 build, while pyproject.toml only states `requires-python = ">=3.8"` and lists 3.8, 3.9 and 3.10 in its classifiers. Follow the 3.10.16 recipe rather than the declared floor.

### Does the transformers dependency need a fork in VLA-Adapter?

Yes, for bidirectional attention and parallel decoding: the pinned `transformers==4.40.1` line in pyproject.toml carries an inline note pointing at the moojink/transformers-openvla-oft fork, and that fork reference is commented out. A plain `pip install -e .` does not install it.

### Can VLA-Adapter run on a real robot?

The news entry dated 2026/03/16 says real-world ALOHA deployment support was added and verified on Cobot Magic, covering training, server-client inference and evaluation, with details in `experiments/robot/aloha/`. Franka, UR-5 and AGILE Piper are still unticked items in the TODO list.

### Which foundation models will VLA-Adapter support?

None of them yet in this tree. The TODO list names VPP at arxiv 2412.14803 among the foundation models the code will be made compatible with, and leaves that item unticked alongside real-world systems such as Franka, UR-5 and AGILE Piper.

## Sources

- [Issues](https://github.com/OpenHelix-Team/VLA-Adapter/issues)
- [License: MIT](https://github.com/OpenHelix-Team/VLA-Adapter/blob/main/LICENSE)
- [OpenHelix-Team/VLA-Adapter on GitHub](https://github.com/OpenHelix-Team/VLA-Adapter)
- [Project website](https://vla-adapter.github.io/)
- [README](https://github.com/OpenHelix-Team/VLA-Adapter/blob/main/README.md)

---

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