LingBot-VLA 2.0: What the Robbyant VLA Foundation Model Actually Ships

The gap LingBot-VLA 2.0 is aimed at

Vision-Language-Action models are usually published as a pretraining result. The repository description puts the intent plainly: "From Foundation to Application." LingBot-VLA 2.0 is presented as the step after the foundation model, aimed at teams who want to post-train on their own robot rather than reproduce a benchmark. The audience is a robotics or embodied-AI group with a manipulation dataset and GPU capacity. It is not aimed at someone who wants to call an API and get actions back. The README frames the work as a practical foundation model, and the release notes describe a 6B native-depth checkpoint plus a RoboTwin post-training recipe rather than a service. That distinction matters more than any capability list: everything in the repository assumes you will run training or fine-tuning locally.

A 55-dimensional action vector across 20 robot configurations

The mechanism that makes cross-embodiment training possible is a canonical state and action vector of 55 dimensions. The README breaks it down exactly: 14 dimensions for arm joint position, 14 for end-effector pose, 2 for gripper position, 12 for hand joint position, 4 for waist, 2 for head, 3 for mobility signal, and 4 reserved. Each robot's raw signals are mapped into that space through a per-robot config file. This is why the post-training flow requires a YAML under configs/robot_configs/ before anything else can run. The design covers dexterous hands, torso and a mobile base, which is broader than the dual-arm-only convention many VLA codebases assume. The trade-off is that a robot whose joints do not map cleanly onto those slots needs a mapping decision, and the reserved dimensions are the only slack. On the training side, the action expert uses sparse MoE layers with fine-grained expert segmentation and shared expert isolation, so universal priors and embodiment-specific patterns share one active compute budget. The pretraining corpus is described as roughly 60,000 hours: 50,000 hours of robot trajectories across 20 configurations and 10,000 hours of egocentric human video. None of that data ships with the repository.

Installing LingBot-VLA 2.0 and downloading the checkpoint

The README lists three requirements: Miniconda or Anaconda, Python 3.12, and PyTorch 2.8.0. It also states that Conda must be initialized in your shell so that conda activate works before you run the setup script. Clone the repository and run the training environment script:

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

bash tools/create_train_env.sh

By default that script installs flash-attn==2.8.3 from pip. If you already have a matching local wheel, the README shows passing it explicitly, which avoids a long source build:

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

The same script accepts --env-name and --recreate, so you can name the environment or force a rebuild. Once the environment exists, fetch the released weights. The README gives this command for the 6B native-depth checkpoint:

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

The checkpoint is also mirrored on ModelScope. For training rather than inference, the README states that Qwen3-VL-4B-Instruct, MoGe-2-vitb-normal, the LingBot-Depth teacher checkpoint and the DINO-VIDEO teacher checkpoint and config are additionally required, with configs/vla/Training_Config.md as the reference. A first real use is post-training on RoboTwin 2.0: download and prepare the dataset as described in experiment/robotwin/README.md, take the feature mapping from configs/robot_configs/robotwin.yaml, and use the precomputed normalization statistics at assets/norm_stats/robotwin.json. If you change the task subset, the README points to the Custom Data Guide to recompute those statistics.

The three preparation steps nobody can skip

Post-training is gated on three artifacts, and the README is explicit that all three are required. First, a LeRobot dataset directory in v2.1 or v3.0 format. Second, a robot config YAML that defines the feature mapping from your raw states, actions and images into the unified feature space, stored at configs/robot_configs/<data_name>.yaml. Third, normalization statistics computed over your dataset and written to assets/norm_stats/<name>.json. The RoboTwin example supplies all three so the path can be walked end to end, but the moment you use your own robot, you own the mapping and the statistics. This is the real cost of the project. It is not the install, which is a script, and it is not the weights, which are a download. It is the YAML that decides how your hardware's signals land in those 55 slots, and the statistics that decide whether the model sees your data at a sane scale. A wrong mapping produces silent degradation rather than an error.

Where LingBot-VLA 2.0 is the wrong tool

The dependency list is the first constraint. requirements.txt pins torch==2.8.0, torchvision==0.23.0, triton==3.4.0 and flash-attn 2.8.3 through the setup script. That combination is not a CPU-only stack, and there is no documented inference path that avoids it. If your deployment target is an edge device without a recent CUDA toolchain, this repository does not describe how to get there. The second constraint is data format. Post-training assumes LeRobot v2.1 or v3.0. A dataset in an in-house format needs conversion before step one, and the README does not document a converter. The third is embodiment coverage. The released weights are the 6B native-depth model and a RoboTwin post-training checkpoint; the README does not claim a general-purpose checkpoint for arbitrary hardware. The fourth is that the pretraining corpus is described but not distributed. If your interest is in the data pipeline itself, you get the filtering description (misalignment, blur and occlusion, abnormal velocity, acceleration and jerk, static episodes on the robot side; manipulation-centric selection and hand-trajectory reconstruction on the egocentric side) rather than the data.

How it differs from OpenVLA and LeRobot

OpenVLA is the obvious comparison point for a VLA foundation model, and the difference in approach is the action interface. OpenVLA's published action space is built around a 7-dimensional end-effector control convention, which keeps the interface small and the training target simple. LingBot-VLA 2.0 goes the other way with a 55-dimensional canonical vector that includes 12 hand joints, 4 waist, 2 head and 3 mobility dimensions, and it uses a per-robot YAML to map into that space. The wider interface is what allows one model to cover humanoids and dexterous hands, and it is also what forces the mapping work onto the adopter. The second difference is the predictive dynamics component. The README describes dual-query distillation, where current and future perceptual queries are appended to the visual and text tokens and distilled from LingBot-Depth for geometry and DINO-Video for temporal priors. That is a training-time mechanism, not an inference-time feature, and it is why the teacher checkpoints are listed as training requirements. LeRobot sits at a different layer: it is the dataset format that LingBot-VLA 2.0 consumes, so the two are complements rather than alternatives. If your data is already in LeRobot format, that step is done.

Licence, maintenance and what an upgrade costs

The repository is Apache-2.0, declared in both the LICENSE file and pyproject.toml, with license-files = ["LICENSE"]. That is a permissive licence, and it matters here because the project expects you to fine-tune and redistribute weights. Apache-2.0 also carries an explicit patent grant, which some other permissive licences do not. It does not settle the terms of the separately hosted teacher checkpoints and base models (Qwen3-VL-4B-Instruct, MoGe-2-vitb-normal, LingBot-Depth, DINO-VIDEO), which are downloaded from Hugging Face under their own terms. Check those before you ship anything derived from them. On maintenance: the repository is not archived, and the last push was on 2026-09-13. The release history is thin. The README lists two news entries, a RoboTwin post-training checkpoint on 2026-07-25 and the technical report and pretrained weights on 2026-07-08, and no releases were retrieved. The version in pyproject.toml is 0.0.1, which tells you the Python package is early even though the model is at 2.0. Upgrading is not a pip operation. Because requirements.txt pins exact versions of torch, transformers and triton, moving to a newer PyTorch means rebuilding the environment and re-resolving the flash-attn wheel for the new CUDA and ABI combination. Budget for that as a rebuild, not an upgrade.

Editorial conclusion

Adopt LingBot-VLA 2.0 if you already have a LeRobot-format dataset and a machine with a recent CUDA toolchain, and you want a 55-dimensional action interface that covers hands, waist, head and a mobile base rather than arms alone. Do not adopt it if you need a CPU-only inference path, a hosted API, or pretrained weights for an embodiment outside the released set; the README documents neither. Before committing, confirm three things: that your dataset is LeRobot v2.1 or v3.0, that you can supply a robot config YAML under configs/robot_configs/, and that your driver and CUDA version can build flash-attn 2.8.3, since that wheel is the one hard dependency the setup script will otherwise fetch from pip.

Frequently asked questions

Official sources

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