Start with base OpenVLA when your project can provide a workspace image and an English task instruction, and can translate the model’s decoded action into the robot’s control convention. You also need the checkpoint’s matching action statistics and enough compute for the inference or adaptation you plan. Downloading openvla/openvla-7b does not make an unfamiliar robot ready to follow instructions.
This guide concerns the base OpenVLA 7B checkpoint, whose model card describes seven-dimensional end-effector actions and limits zero-shot use to represented robot/domain combinations. It is separate from the OFT adaptation recipe. Official sources were checked on October 14, 2026; no model inference, fine-tuning or robot test was run for this guide.
Decide what you are trying to reproduce
The first choice is whether you want to inspect the model, reproduce a documented setup, or adapt it to your robot. Those goals require different amounts of equipment and work.
| Your situation | A sensible first action |
|---|---|
| You want to understand the checkpoint on a laptop | Inspect its configuration and action statistics without downloading weights |
| You have a represented setup, such as the documented BridgeV2/WidowX domain | Compare your camera, controller and action conventions with the authors’ evaluation setup |
| Your robot, camera view or task domain differs | Plan demonstrations and adaptation; do not assume zero-shot compatibility |
| You need several cameras, proprioception or fast bimanual control | Compare a policy designed for those inputs, including the separate OFT route |
The model card’s out-of-scope statement explicitly excludes zero-shot generalization to unseen robot embodiments or unrepresented setups. Similar-looking arms are not enough to establish a match.
The output is a motion vector, not seven joint targets
The base model accepts one camera image of the workspace and a task instruction. The authors’ evaluation utility converts an image to RGB and applies the checkpoint’s processor. For a task such as picking up a red cube, the base prompt follows this form:
In: What action should the robot take to pick up the red cube?
Out:
The seven action components described in the model card are changes in end-effector position and orientation, followed by a gripper command: (x, y, z, roll, pitch, yaw, gripper). They are not the seven joint angles of a seven-joint arm. A controller expecting absolute joint positions cannot consume that vector merely because its input also has seven values.
Inside the checkpoint, action tokens are decoded to normalized values. The official predict_action implementation then uses the selected dataset’s statistics to unnormalize them. It applies the stored first/99th-percentile bounds to dimensions selected by the statistics mask. The returned predict_action vector is already unnormalized for the selected key; applying that conversion again would change its scale.
Before forwarding any output, write down your controller’s expected coordinate frame, translation and rotation units, delta-versus-absolute convention, gripper encoding and command timing. Match each against the dataset and robot adapter. A plausible vector is evidence of a computed output, not evidence that the robot will move in the intended direction.
Inspect the statistics before loading the weights
The base checkpoint contains multiple datasets’ normalization records. unnorm_key="bridge_orig" in the authors’ example selects BridgeData V2 statistics; it is not a generic setting for every robot.
You can inspect the checked configuration with Python’s standard library. Save this as inspect_openvla.py and run python inspect_openvla.py. It fetches JSON at the fixed checkpoint revision and does not load weights or execute the checkpoint’s custom Python code.
import json
from urllib.request import urlopen
revision = "47a0ec7fc4ec123775a391911046cf33cf9ed83f"
url = f"https://huggingface.co/openvla/openvla-7b/resolve/{revision}/config.json"
with urlopen(url, timeout=30) as response:
config = json.load(response)
statistics = config["norm_stats"]
print("Available statistics:", sorted(statistics))
bridge_action = statistics["bridge_orig"]["action"]
print("Action dimensions:", len(bridge_action["q01"]))
print("Unnormalization mask:", bridge_action["mask"])
In that configuration, bridge_orig has seven action dimensions and a mask whose final entry is false. Inspecting it shows which conversion the decoder will apply. It does not identify your robot’s coordinate frame or prove that those statistics suit a new dataset. For an adapted checkpoint, preserve the statistics produced for its own training data rather than borrowing a convenient key from the base model.
For an actual inference environment, start from the authors’ minimal requirements file. It pins transformers==4.40.1, tokenizers==0.19.1 and timm==0.9.10; its PyTorch requirement is >=2.2.0. These are the project’s documented dependencies, not a promise that arbitrary newer combinations work. Record the code and model revisions you use. The model-loading example uses trust_remote_code=True, so inspect and pin the custom code as well as the weights before enabling that option.
Attach a workload to every GPU memory number
A metadata check can run on a CPU laptop. Loading a large checkpoint, predicting actions and training adapters are different workloads. Budget host memory, download/cache space and dataset storage alongside GPU memory, and measure latency with the camera and controller path included.
| Workload | What the authors report | How to use the evidence |
|---|---|---|
| bfloat16 inference | 16.8 GB VRAM in paper Table 2 | A reported experiment, not a guaranteed minimum for the current checkpoint |
| 4-bit inference | 7.0 GB VRAM in the same table | A quantized configuration to reproduce and measure; fitting weights does not establish control performance |
| Base OpenVLA LoRA fine-tuning | The repository says roughly 27 GB can work with a reduced batch; its batch-16 example needs roughly 72 GB | Check the exact training configuration before reserving a GPU |
The paper’s Sections 5.3–5.4 and Table 2 need to be read together. Footnote 4 states that those adaptation and quantization experiments used a slightly smaller model with a single SigLIP vision backbone. The flagship checkpoint uses fused DINOv2 and SigLIP features. The figures therefore should not be advertised as measured memory requirements for every base OpenVLA load.
The repository’s LoRA instructions give the separate training example. Reducing batch size changes memory use; gradient accumulation changes the effective batch. Neither produces a universal training-time guarantee. Full fine-tuning is a further resource commitment, so confirm that adapter training is inadequate before choosing it.
For remote inference, also measure image transfer, request latency and action delivery. A model server that responds eventually can still be too slow for the control cadence represented in your demonstrations.
Bring demonstrations from the robot you will control
For a new setup, collect examples pairing the workspace image and task instruction with the intended action at the relevant time. Keep the camera view, action convention and command cadence documented. Fine-tuning cannot repair an action label that means something different from the value your controller later receives.
The authors’ dataset registration configuration and dataset transforms show where a dataset’s observation fields and actions enter the pipeline. The repository recommends converting custom data to RLDS for its existing fine-tuning path; a custom PyTorch dataset wrapper is another supported route. Saving demonstrations in a readable file format is only the beginning: the loader and transform still have to supply the model’s expected inputs and action labels.
Keep a held-out evaluation set and define task completion before adapting the model. After training, check the saved statistics, replay the data through your adapter, and evaluate the checkpoint on controlled trials. An offline token or action score does not replace robot task evaluation.
Read the inherited model terms alongside MIT
The OpenVLA code license is MIT, and the Hugging Face model card also labels the checkpoint MIT. However, the repository’s model-licensing note explicitly says the pretrained models derive from Llama 2 and are subject to its Community License. Keep both statements in your use review.
The Llama 2 agreement includes redistribution and attribution obligations, restrictions on using its materials or outputs to improve other large language models, and additional commercial terms. It incorporates an acceptable-use policy, which specifically addresses activities involving critical infrastructure, transportation technologies and heavy machinery among its prohibited-use provisions. Check the intended application against those terms, particularly for industrial deployment. The MIT label alone does not settle that question.
Also check the rights and access conditions of the demonstration data you use. A model license does not grant permission to redistribute a separately licensed dataset or recordings containing someone else’s material.
When another policy is a better first project
Choose base OpenVLA for a question it can answer: whether image-and-language conditioning helps your manipulation tasks under a compatible action contract. For a narrow task where motion precision dominates and language variation adds little, compare a task-specific imitation policy; the authors’ project results found Diffusion Policy stronger on narrower, more precise tasks in their experiments. That result is a comparison to test on your setup, not a ranking for every robot.
If compute access is your immediate constraint, the SmolVLA with LeRobot guide offers a different adaptation path to examine. If your requirements include multiple images or action chunks, use the separate OpenVLA-OFT guide to assess that recipe’s input and execution contract.
Before renting compute or connecting an arm, finish one small decision: identify the checkpoint, its statistics key, the matching controller convention and the workload you need to run. If any of those remains unknown, resolve it with a configuration inspection or data check first.