InternVLA-A1.5 trains one policy to understand, imagine and act

Three tasks in one policy, and the table that follows

InternVLA-A1.5 unifies vision-language understanding, visual foresight, and action generation in one policy, and that is the whole thesis.

The three words are three different research programmes. Understanding is reading the scene: what objects are there, what state are they in, what is the instruction asking for. Foresight is predicting what the scene will look like next, which is a video prediction problem. Action is producing the robot's movements, which is a control problem.

Until recently these were separate models with separate training, and a robot policy that could do all three was a research curiosity rather than a product. The claim here is that putting them in one model gives compositional generalisation, since a task that combines understanding a scene with acting on it does not require two models to agree.

The benchmark table is the evidence. The results across RoboTwin 2.0, LIBERO, LIBERO-Plus, SimplerEnv, DOMINO and EBench are 93.2, 98.9, 84.8, 80.8, 27.7 and 35.2 respectively.

The spread is informative. The simulation benchmarks are strong, with LIBERO at 98.9 and RoboTwin 2.0 at 93.2. The harder numbers are DOMINO at 27.7 and EBench at 35.2, which are the more realistic manipulation settings, and the gap between 98.9 and 27.7 is the honest measure of how far this is from solved.

So the right way to read this project is as a promising research result with a large gap still open on realistic manipulation, not as a deployment-ready policy. The paper is on arXiv, the project page is linked, and the weights are on HuggingFace and ModelScope for a base model, a RoboTwin fine-tune, a LIBERO fine-tune and a DOMINO fine-tune.

The project is Python, and the licence is CC BY-NC-SA 4.0, which is the first thing to check if you have any commercial intention.

The architecture is a shared trunk with one branch thrown away

The three highlight bullets describe the architecture precisely enough to be worth reading closely.

The core attaches a lightweight unified action expert to a native Qwen3.5-2B VLM backbone through shared full-attention layers, while preserving modality-specific Gated DeltaNet processing.

So the backbone is a Qwen3.5-2B vision-language model, which is small for a VLM, and the action expert is a separate lightweight module. The two are joined through shared full-attention layers, which means they attend over a common sequence. The Gated DeltaNet part is the fast path for the language and vision modalities, and it stays modality-specific so the VLM's own processing is not degraded by the action branch.

The foresight bullet is the interesting one. It uses learnable foresight tokens to query task-relevant future dynamics from the shared multimodal context, supervised by a frozen WAN2.2-5B video generation model during training.

That is a teacher-student arrangement inside one model. The foresight tokens are extra tokens in the sequence whose job is to carry a question about the future, and a frozen video generation model provides the training signal. The word frozen matters, because it means the 5B video model is only ever a teacher: it is not trained, and it is not needed afterwards.

The output bullet explains why that works out for deployment. It discards the video branch at inference and predicts continuous action chunks through flow matching, keeping deployment latency practical.

So the training-time architecture is bigger than the deployment-time architecture, and the difference is the branch that gets dropped. That is a common and sensible pattern in this area, and it is why a policy that was trained with a 5B video model can still run with practical latency.

Flow matching is the other detail there. Predicting continuous action chunks through flow matching rather than by discretising actions into tokens is the other big decision in modern VLA work, and it matches the FAST action tokens mentioned elsewhere in the documentation as a separate option for the pre-training configuration.

The training entry points and what the flags mean

The repository gives you two ways in, a playground example and the real training pipelines.

The playground is a one-line command:

bash launch/internvla_a15_finetune.sh lerobot/pusht abs false

And the two positional arguments are explained in the documentation. The first, abs, indicates using absolute actions, and the second, false, means that the training script will use the statistics file, stats.json, provided by lerobot/pusht itself.

That is a well-designed example, because the two flags are the two decisions every user has to make and the alternative is a wall of configuration. Absolute versus relative actions is a property of your dataset and your robot, and the statistics file determines how the actions get normalised, so taking the dataset's own statistics is the safe default.

The pre-training entry is described in the same level of detail. It uses launch/internvla_a15_pretrain.sh, discovers LeRobot-format datasets under data/a1, applies configs/weight_rules_pretrain.yaml, and trains the internvla_a1_5 policy with Qwen3.5-2B, FAST action tokens, and the WAN video auxiliary branch.

So pre-training is a three-part configuration: the backbone model, the action representation, and the auxiliary video branch. The weight rules file is where you would weight the loss terms between those parts, which is the sort of thing that needs a YAML file rather than a command line.

The pre-training dataset is InternData-A1, and the fine-tuning path for real data goes through the LeRobot V2.1 format, with the tutorial walking through the complete pipeline: download the dataset, convert it to LeRobot V3.0 format, compute the delta-action statistics, then fine-tune.

That four-step list is worth noting. The conversion from V2.1 to V3.0 is a separate step, and the delta-action statistics have to be computed before training, which is the same statistics file the playground example takes from the dataset.

For RoboTwin 2.0 there is a separate fine-tuning tutorial and a separate evaluation tutorial, so the benchmark workflows are documented separately from the training workflows.

Evaluation is five separate harnesses, and real-robot inference has a switch

The evaluation section points at a separate README for each benchmark, and the list is RoboTwin, LIBERO, LIBERO-Plus, DOMINO and SimplerEnv.

Five separate evaluation directories rather than one unified runner is a sign of how much the benchmarks differ in their setup. SimplerEnv alone has a nested path with an eval_simplerenv directory inside it, which is the kind of shape a benchmark with its own harness produces.

For open-loop action prediction on LeRobot-format data there is a single script, tests/openloop_internvla_a1_5.py, which is the quick way to check that a model does something sensible without setting up a simulator.

The real-robot section is the one with a concrete instruction. For real-robot deployment, the recommendation is to use the optimized action-only inference backend, and after loading the InternVLA-A1.5 config and before constructing the policy you add:

config.inference_backend, config.action_loss_only = "optimized", True

And the reason is given. This skips WAN video-branch loading and uses the low-latency optimized backend for action prediction, and you keep the standard backend only when you need future-video visualization or WAN-related inference outputs.

That is the foresight branch from the architecture section meeting the deployment reality. On a robot, the latency of loading a 5B video model is not a background cost, it is time the robot spends not moving, and the branch that is useful for research visualisation is exactly the branch you cannot afford on hardware. Turning it off is one line, and it is documented as a supported path rather than a hack.

One configuration line is doing two things there, setting the backend and the action loss only flag in a single assignment, which is a slightly unusual style but perfectly readable.

The repository state, the licences and the missing pieces

A few practical details are worth pulling out before you start.

The code has moved. There is a note that the InternVLA-A1 code has moved to the InternVLA-A1 branch, and the default branch is master, which is A1.5. So if you want the earlier model you have to switch branches, and the two have different architectures.

The environment is pinned tightly. The repository has been tested on Python 3.11, CUDA 12.8 and PyTorch 2.10.0, and conda is recommended for an isolated environment. The installation tutorial covers preparing the environment, installing dependencies, and patching the required HuggingFace Transformers modules for Qwen3.5 and the robot-learning policies.

Those patches are worth understanding rather than treating as boilerplate. The model uses a native Qwen3.5 backbone and FAST action tokens, and the Transformers library in the environment has to be taught how to handle both. A patch requirement is a sign that the model uses features the framework has not yet absorbed, and it is a maintenance cost that comes with working at the edge of what a framework supports.

The TODO list shows what is done and what is not. Done: the training and evaluation code for A1.5, the pre-training and fine-tuning tutorials, and the simulation evaluation entries for RoboTwin, LIBERO, LIBERO-Plus, DOMINO and SimplerEnv. Not done: combining InternVLA-A1, InternVLA-A1.5 and more VLAs and world action models in the repository, and releasing the example visual question answering data and training tutorials.

The licences are split and that matters. The model weights are released under CC BY-NC-SA 4.0, which is a non-commercial share-alike licence, and the licence field in the package file says the same for the code. A License classifier says Free for non-commercial use. So the whole project, code and weights, is usable for research and not for commercial deployment without a separate arrangement.

The package metadata names the project internvla-a1-5 at version 1.0.0 with a development status of 3 - Alpha, and the authors are Shanghai AI Laboratory and InternRobotics. The dependency list is a normal research stack with tight upper bounds on most packages: datasets, diffusers, huggingface-hub with transfer and CLI extras, accelerate, einops, opencv-python-headless, av, jsonlines, msgpack, torch and torchvision, plus draccus and omegaconf for configuration and loguru for logging.

Editorial conclusion

Adopt InternVLA-A1.5 if you are doing robot manipulation research and want a single policy with published weights, training code and evaluation harnesses for five benchmarks rather than assembling a VLA pipeline yourself. Skip it if you are deploying commercially, because the weights are CC BY-NC-SA 4.0, and if your hardware is not a CUDA 12.8 machine, since that is what the repository was tested on. Verify first which branch you want, since the A1 code has moved to its own branch and the master branch is A1.5, and that you apply the HuggingFace Transformers patches the installation tutorial requires for Qwen3.5.

Frequently asked questions

Official sources

1. InternRobotics/InternVLA-A-series on GitHub
2. Issues
3. README