LingBot-VLA 2.0 documents Python 3.12 while its packaging metadata claims 3.8

The environment script pins one flash-attn wheel, and the sample name is x86_64 Linux

Setup starts from a clone and a shell script:

git clone https://github.com/Robbyant/lingbot-vla-v2.git
cd lingbot-vla-v2

bash tools/create_train_env.sh

The stated requirements are Miniconda or Anaconda, Python 3.12, and PyTorch 2.8.0, and the script expects Conda to be initialized in your shell so that conda activate works.

By default the script installs flash-attn==2.8.3 from pip. A local wheel can be passed instead:

bash tools/create_train_env.sh \
  --flash-attn-wheel /path/to/flash_attn-2.8.3+cu12torch2.8cxx11abiTRUE-cp312-cp312-linux_x86_64.whl

That filename is worth reading before you hunt for a wheel. It encodes CUDA 12, torch 2.8, the cxx11 ABI flag, cp312 for Python 3.12, and linux_x86_64. Every one of those has to line up, which means a Mac, an arm64 box, or a different Python minor version falls back to a source build of flash-attn. The script also takes --env-name and --recreate, so the environment name and a forced rebuild are both flags rather than edits to a file.

The released weights are one model in a five checkpoint stack

LingBot-VLA 2.0 is released as a native-depth model, published as lingbot-vla-v2-6b on both Hugging Face and ModelScope. Fetching it is one command:

python3 scripts/download_hf_model.py --repo_id robbyant/lingbot-vla-v2-6b --local_dir lingbot-vla

That is enough to run the model. It is not enough to train it. To train with this codebase you also need the Qwen3-VL-4B-Instruct weights, MoGe-2-vitb-normal, the LingBot-Depth teacher, and the DINO-Video teacher checkpoint and config. Four more downloads, named individually in the training section, with a pointer to configs/vla/Training_Config.md for how they are combined.

The design text explains why the extra pieces exist. Predictive dynamics modeling uses future prediction as a proxy task, with DINO-Video providing semantic temporal priors and LingBot-Depth providing geometric cues, and the dual-query distillation step appends current and future perceptual queries to the visual and text tokens.

So the published artifact is the assembled result, while the reproducible setup is the assembly. Budget the disk and the download list for five checkpoints, not one.

Four of the 55 action dimensions are reserved and left undefined

Heterogeneous embodiments are mapped into a 55 dimensional canonical state and action vector. The breakdown is 14 dimensions for arm joint position, 14 for end-effector pose, 2 for gripper position, 12 for hand joint position, 4 for waist position, 2 for head position, and 3 for mobility signal. That sums to 51.

The remaining 4 are reserved dimensions. Nothing in the vector breakdown says what they carry, whether a specific robot config is expected to fill them, or what happens to a downstream head that expects a different layout. If you are writing your own feature mapping in configs/robot_configs, four slots are deliberately unnamed, and the mapping file is where you decide their fate.

This is also the mechanism behind the expanded action space claim against version 1.0. Instead of only standard dual-arm manipulation, the single representation has to absorb arms, end-effectors, grippers, dexterous hands, waist, head, and mobile base signals. The cost of that unification is a vector that carries room for configurations nobody has described yet.

The Makefile targets point at directories that are not in the tree

The repository ships a Makefile with build, commit, quality, style, and test targets. Two of them take paths that do not appear among the top level entries.

The shared variable is check_dirs := tasks tests veomni docs setup.py, and both quality and style run ruff over it. There is no veomni directory in the repository root, and no tests directory either, while the test target runs pytest tests/. Both tasks, files, and tools exist, as do docs, so the check list reads as if it was written for a tree that includes a bundled veomni training framework and a test suite, and neither is in the checkout you clone.

The build target also predates the modern path: it runs python3 setup.py sdist bdist_wheel, even though a pyproject.toml with a setuptools build backend is present.

Treat the lint and test targets as scaffolding to repair on your own fork. Before trusting a clean ruff run, confirm which of the five paths actually exists on your machine.

Packaging claims Python 3.8 while the documented install needs 3.12

The installation section names Python 3.12 and PyTorch 2.8.0 as requirements. The packaging metadata says something different.

pyproject.toml sets requires-python to 3.8 or newer, and the same file sets the ruff target-version to py38. setup.py passes python_requires of 3.8.0 or newer. So an installer reading the metadata will believe the package supports interpreters the documented environment never uses, and the lint rules are configured for a Python three minor versions older than the training stack.

The dependency pins make the same point from the other direction. requirements.txt holds exact versions throughout: torch 2.8.0, torchvision 0.23.0, torchaudio 2.8.0, torchdata 0.11.0, torchcodec 0.6.0, transformers 4.57.3, tokenizers 0.22.2, datasets 3.6.0, huggingface-hub 0.34.3, and numpy 1.26.4.

A floor of 3.8 with an exact torch pin describes a package that would install on an old interpreter and fail at the first import. If you script an environment from the metadata alone, you will get the floor and not the pins.

setup.py reads the version from a regex while pyproject hardcodes 0.0.1

Two version sources exist in the same repository.

setup.py opens lingbotvla/__init__.py, searches it with a pattern built from __version__, and passes the extracted string to setup(). That file ships setup.py twice over in a sense: it defines helpers named _is_package_available, _is_torch_available, _is_torch_npu_available, and _is_torch_cuda_available, and the last one imports torch and calls torch.cuda.is_available(), yet none of them is referenced when setup() is called. The comment above the call says it will update install_requires and extras_require. install_requires is updated; extras_require is never passed.

pyproject.toml, meanwhile, declares version 0.0.1 as a literal, with dependencies and optional-dependencies marked dynamic. The declared version and the version setup.py computes are unrelated numbers.

One more detail worth knowing before you package: install_requires is built as list(set(BASE_REQUIRE + get_requires())), with BASE_REQUIRE empty. Passing requirement lines through a set means the order of install_requires is not the order in requirements.txt, and the comment lines and blank lines get_requires() filters out are dropped. And include_package_data is False while find_packages excludes scripts, tasks, and tests, which puts tasks/vla/train_lingbotvla.py, the file the documented training command invokes, outside the built distribution.

The runtime requirement list is fully pinned and carries debugging tools

requirements.txt is a frozen manifest rather than a range manifest. Every entry uses an exact version, including the surrounding toolchain: blobfile 3.2.0, wandb 0.21.0, tensorboard 2.16.2, sentencepiece 0.2.0, protobuf 3.20.3, packaging 25.0, ninja 1.11.1.4, triton 3.4.0, h5py 3.14.0, jsonlines 4.0.0, zstandard 0.23.0, fsspec 2024.6.1, aiohttp 3.12.15, psutil 7.0.0, rich 14.1.0, matplotlib 3.10.3, seaborn 0.13.2, omegaconf 2.3.0, msgpack 1.1.1, and websockets 15.0.1.

Two of those are development instruments rather than runtime libraries. ipdb 0.13.13 is a debugger, and it sits beside wandb and tensorboard in a list that setup.py turns into install_requires, so anyone who installs the package gets the debugger.

The freezing is deliberate and defensible for reproducible training runs, and it has a cost: the list cannot share a torch install with any other project on the same machine, and there is a separate requirements-depth.txt for the depth side, so an environment assembled by hand has two manifests to reconcile. A resolved environment is the only one the pins describe.

No releases are tagged, and the single speed number is scoped to one H20

The repository has no GitHub releases. Version information lives in the model names instead, lingbot-vla-v2-6b for the native-depth release and lingbot-vla-v2-6b-robotwin for the RoboTwin post-training weights, and the news entries are dated rather than tagged.

That news list has three entries. On 2026-07-08 the technical report and pre-trained weights were prepared. On 2026-07-25 the RoboTwin post-training weights were added. On 2026-09-22 Distributed Muon was added to improve training efficiency, and this is the entry with a number in it: single-node H20 post-training speed improves 37.6 percent over Muon. One accelerator model, one training phase, one baseline. There is no table of configurations, no batch size, no sequence length, and no second hardware point in the repository to widen that into a general claim.

The last push to the repository is dated 2026-09-22, the same day as that entry. If you pin your work to a commit, the weights on the model hubs are the artifact that carries a version, and they are not released in step with the code.

Editorial conclusion

LingBot-VLA 2.0 is worth reading if you already run PyTorch training on Linux x86_64 hardware and want the model design details, the RoboTwin example and the post-training loss settings in one repository. Verify four things before you start: that your machine matches the wheel the install script expects, that the four teacher checkpoints are reachable, that the Makefile targets you plan to use point at directories that exist in your checkout, and that a pre-existing Python 3.8 style environment is not what you are building against. Anyone wanting tagged releases, a permissive Python floor, or a dependency set that tolerates an existing PyTorch install should hold off.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. Robbyant/lingbot-vla-v2 on GitHub