DL0118 VLA vs VLM

What is a VLA model and how does it differ from a VLM?

Answer

A VLA (Vision-Language-Action) model is a policy that maps camera images plus a natural-language instruction directly to robot actions, typically a short sequence of end-effector or joint deltas plus a gripper command, emitted at a fixed control rate. A VLM (Vision-Language Model) maps the same image-plus-text input to text tokens. Architecturally the two are close relatives: almost every modern VLA (RT-2, OpenVLA, \pi_0) starts from a pretrained VLM backbone and is fine-tuned on teleoperated demonstration trajectories, either by discretizing each action dimension into vocabulary tokens or by attaching a continuous action expert head. The real difference is not the encoder, it is everything downstream of it: the output lives in a continuous, embodiment-specific action space, the model runs inside a closed feedback loop where its own outputs change the next observation, and errors therefore compound over the rollout instead of being independent per query. That single fact drives the different data (robot demos, not web image-text pairs), the different latency budget (tens of milliseconds, not seconds), and the different metric (physical task success rate, not benchmark accuracy).

(1) Output Space: a VLM produces a distribution over a discrete text vocabulary; a VLA produces a vector in \mathbb{R}^{d} per timestep, usually predicted as an action chunk covering the next H control steps.
(2) Closed Loop Versus Open Loop: a VLA’s action changes the world and therefore its own next input, so covariate shift makes behavior-cloning error grow roughly with the square of the horizon; a VLM answer is scored once and never fed back through a robot.
(3) Training Data: web-scale image-caption and VQA corpora for the VLM, versus expensive teleoperated trajectories (Open X-Embodiment aggregates roughly one million episodes) with synchronized proprioception for the VLA.
(4) Action Representation Is A Design Choice: RT-2 and OpenVLA quantize each dimension into 256 bins and reuse rarely-used text tokens; \pi_0 instead trains a flow-matching action expert that emits continuous chunks at 50 Hz.
(5) Latency Is A Correctness Constraint: a 2 s VLM response is fine, but a controller starved of fresh actions produces jerky or unsafe motion, so chunk horizon and inference time must be budgeted together.
(6) Embodiment Coupling: VLM weights transfer across any image; VLA action heads are tied to a specific DoF count, camera mount, and control convention, which is why cross-embodiment training is an active research problem.

Diagram showing a shared ViT plus LLM backbone taking an RGB observation and a language instruction, branching into a text decoder head producing answer tokens for a VLM and an action expert head producing a 50 by 7 action chunk executed by a robot at 50 Hz, with a feedback arrow returning the new observation to the encoder

Figure 1: Both models share the same perception stack; the VLA replaces or augments the text head with an action head and runs inside the loop observe → predict chunk → execute → observe, so its own predictions determine the next input distribution.

The token-budget arithmetic explains why action chunking is universal. A 7-DoF arm predicted one step at a time at 50 Hz would need a full autoregressive forward pass every 20 ms, which no 3B-parameter backbone can sustain. Predicting a chunk of H = 50 actions amortizes one forward pass across a full second of motion, at the price of running open loop within the chunk. Shorter chunks mean tighter feedback and better disturbance rejection but more compute and more jitter at chunk boundaries; longer chunks are smoother but blind to anything that happens mid-chunk. Naive autoregressive decoding of 350 discrete action tokens is also slow, which is exactly the bottleneck that continuous action experts and frequency-domain tokenizers were built to remove.

Mathematical Formulation:
p_\theta(y_{1:T} \mid I, \ell) = \prod_{t=1}^{T} p_\theta(y_t \mid y_{1:t-1}, I, \ell)
a_{t:t+H-1} \sim \pi_\theta(\cdot \mid o_t, s_t, \ell)
k_j = \mathrm{round}\left(\frac{a_j - a_{\min}}{a_{\max} - a_{\min}}(B-1)\right)
N_{tok} = H \cdot d = 50 \cdot 7 = 350
t_{infer} \leq H / f_{ctrl}
50 / 50\ \text{Hz} = 1\ \text{s}
J(\pi_\theta) - J(\pi^{*}) = O(\epsilon T^{2})

Where:

  • y_{1:T} are the text tokens a VLM emits for image I and instruction \ell; the factorization is the only thing the VLA keeps unchanged.
  • a_{t:t+H-1} \in \mathbb{R}^{H \times d} is the action chunk, o_t the current camera observation, and s_t the proprioceptive state that a VLM never receives.
  • d is the action dimension (7 for a 6-DoF pose delta plus gripper) and H the chunk horizon in control steps.
  • k_j \in \{0, \ldots, B-1\} is the discrete bin for dimension j, with B = 256 and [a_{\min}, a_{\max}] set from per-dimension training quantiles so outliers do not collapse the resolution.
  • f_{ctrl} is the control frequency and t_{infer} the policy latency; the required deployment condition is that a new chunk arrives before the previous one is exhausted.
  • \epsilon is the per-step imitation error, T the rollout length, and J the task cost; the quadratic bound is the classical behavior-cloning compounding result.
Log-scale chart of accumulated error against rollout length, comparing a linear curve for independent per-query error and a quadratic curve for closed-loop behavior cloning, with the quadratic curve 400 times higher at 400 steps

Figure 2: A VLM’s mistakes are independent per query and accumulate linearly; a VLA’s mistakes move the robot off the demonstration distribution, so the worst-case cost grows as O(\epsilon T^{2}) and a 1% per-step error is fatal over a 400-step manipulation.

PropertyVLA (Vision-Language-Action)VLM (Vision-Language Model)
OutputContinuous action chunk, typically 50 steps by 7 dimensions, as bin tokens or a flow-matching headText tokens from a fixed vocabulary of roughly 32k to 256k entries
Extra inputsProprioception, gripper state, often multiple synchronized camera viewsImages and text only
Training dataTeleoperated demonstrations (Open X-Embodiment scale is about 1M episodes), usually co-trained with web data to keep semanticsBillions of web image-text pairs plus instruction tuning
Latency budgetChunk must arrive before the previous one runs out, so tens to a few hundred millisecondsSeconds; streaming hides most of it from the user
EvaluationPhysical or simulated rollout success rate over many trials, with high variance and slow iterationStatic benchmark accuracy or preference scores, reproducible offline
Dominant failure modeCompounding covariate shift, unrecoverable states, embodiment mismatch, control jitterHallucination and grounding errors, recoverable by re-prompting

Login to view more content


Log in to track your progress

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *