TurboVLA: A 0.2B-Parameter VLA That Runs at 32 Hz on a Single RTX 4090

I went looking for a quiet-day post on Tuesday morning and found a paper that had dropped on July 30 and hadn’t been picked up anywhere yet. The numbers on the front page of the README are the kind that make you close the laptop and think for a minute: 97.7% on LIBERO with 0.2B parameters, 31.2 ms inference latency, 0.9 GB VRAM on a consumer RTX 4090. I keep a mental list of “this should not be possible” results and TurboVLA is now on it. The technical story behind the numbers — the reason a 200-million-parameter model can stand next to seven-billion-parameter VLAs and win — is the actual post.

The problem TurboVLA is solving

Every serious Vision-Language-Action model I have read about in the last two years — OpenVLA, RT-2, π0, StarVLA, the various Hugging Face ports of OpenVLA-OFT — uses the same shape: V → L → A. Visual observations are projected into the embedding space of a pretrained large language model, the language model “thinks” about the scene and the instruction, and a downstream head decodes continuous action chunks from the LLM’s hidden states. It is the architecture you get if you treat a robot policy as a fine-tuned chatbot that outputs joint torques instead of tokens. It works. It is also expensive.

The bill is paid three ways. First, the LLM backbone is large — even a “small” 7B parameter base dominates the parameter count, the VRAM, and the FLOPs of the policy. Second, the bottleneck is wide — every frame of every episode has to traverse the LLM’s full hidden dimension, even when most of the perception is redundant across timesteps. Third, the LLM was pretrained on text, not on spatial or temporal sensor data, so we are forcing a transformer that learned “the cat sat on the mat” to also learn “the end-effector needs to rotate twelve degrees clockwise about the wrist.” Fine-tuning partly closes that gap but the cost shape is inherited from day one.

TurboVLA’s argument is that the LLM is the wrong abstraction at the action-decoding stage. You do not need a model that can write a sonnet to predict a six-DoF twist. You need a model that can fuse a visual embedding with a short language string and regress continuous controls.

What the paper actually proposes

The architectural reformulation is one line. TurboVLA replaces the V → L → A pathway with a V + L → A mapping. Visual features and language features are encoded independently and fused through a lightweight bidirectional vision-language interaction module borrowed from GroundingDINO — not through the depth of an LLM stack. A compact decoder then predicts 12-step action chunks (the LIBERO recipe) or 50-step chunks (the RoboTwin recipe) directly from the fused representation.

Three concrete choices fall out of that:

1. The visual encoder is DINOv3 — facebookresearch/dinov3 ViT-B for LIBERO, ViT-L for RoboTwin. No quantization, no extra projection; the DINOv3 token stream goes straight into the fusion module. This matters: DINOv3 was trained on a much larger and more diverse visual corpus than the typical CLIP-style backbone used in older VLAs, and the dense features carry spatial information that the LLM middle layer would normally have to recover.

2. The text encoder is BERT base uncased. That is it. No 7B Llama, no Qwen, no Gemma. The language input is short — a task description and a couple of object references — and a 110M-parameter bidirectional encoder is sufficient and is what the fusion module is designed to consume.

3. The fusion module is bidirectional. This is the part that is easy to miss. Older VLA variants either concatenated a CLIP text embedding to the visual tokens (unidirectional flow, vision-attends-to-text only) or pushed everything through a frozen LLM (effectively the same problem at higher cost). TurboVLA lets both streams cross-attend into each other: visual tokens attend to language tokens and language tokens attend to visual tokens through a small GroundingDINO-style adapter. The adapter is initialized from GroundingDINO Swin-T OGC weights, which gives a strong grounding prior for free.

The action head is small and chunk-based — a 12-step chunk for LIBERO, a 50-step ACT-style head for RoboTwin. The 0.2B parameter count refers to the full policy, including the DINOv3-B encoder, the BERT encoder, the fusion module, and the action head. The LLM-shaped part of the parameter budget simply does not exist.

The numbers, with the actual experimental setup

On LIBERO, TurboVLA reports 97.7% average success across the four no-noops suites at 31.2 ms per inference call. The LIBERO recipe uses two camera views, a 7-D action representation, a 12-step chunk, 80,000 optimizer steps with 10k warmup, and a global batch size of 256 on four GPUs. That is the training compute — the inference story is what makes the result usable. On a single RTX 4090, peak inference VRAM is 0.9 GB. Throughput is 32 Hz. For comparison, the OpenVLA-7B reference inference on the same 4090 sits around 4-6 Hz at roughly 16 GB VRAM. A π0 baseline pushes VRAM into the 20+ GB range for the same policy class.

The RoboTwin numbers are the harder test. RoboTwin 2.0 is a 50-task dexterous manipulation benchmark with 14-D absolute joint-position actions. TurboVLA uses DINOv3-L here (the larger vision tower), three camera views, a 50-step ACT head, 55,000 optimizer steps, and a global batch size of 192 on four GPUs. The published numbers on RoboTwin are competitive with substantially larger policies, but the more interesting result is the deployment shape — the policy server and the simulator are decoupled and run in separate Python environments, which makes iteration on the deployment side practical instead of a tar-pit of CUDA conflicts.

Why this matters for someone building physical AI

I think the architectural argument is more durable than the benchmark number. Three points I keep coming back to:

First, the inference economics change. A robot policy that runs at 32 Hz on a consumer GPU is no longer a research artifact — it is a deployable system. The 32 Hz number is the threshold where a closed-loop controller can be sampled synchronously with the action chunk horizon, which means you can stop doing open-loop rollouts of multi-second chunks and start treating the policy as a real-time function of perception. That is a different engineering regime.

Second, the parameter-to-skill ratio points at something the LLM-centric VLA camp has been papering over. A 7B parameter VLA is essentially a fine-tuned chatbot wearing an action decoder as a costume. The 7B parameters are not buying you manipulation skill; they are buying you the LLM’s pretrained world knowledge, most of which a robot policy does not need. TurboVLA’s 0.2B is closer to a lower bound on what manipulation skill actually requires, given a strong visual encoder and a grounded language stream. The 35x parameter reduction is not the headline — the why of the reduction is.

Third, the fusion module is the actually interesting piece. A bidirectional cross-attention adapter initialized from a grounding model is doing real work here, and I expect this to be the design pattern that gets copied over the next six months. The 2024-era VLAs pushed everything through an LLM because it was the only well-tooled cross-modal fusion stack available. Once you accept that the LLM is not the bottleneck you need to optimize against, the whole “use an LLM” assumption collapses and a much smaller, grounded fusion module becomes both sufficient and architecturally honest.

What is missing or worth watching

Three things I would want to see before fully buying in:

1. Real-robot numbers, not just simulation. LIBERO and RoboTwin are simulators. Both are good, both have known sim-to-real gaps, and the visual diversity of a real kitchen or warehouse is a different distribution than the rendered backgrounds in either benchmark. The repo has a real-world tasks GIF on the README but no public real-robot success-rate table yet.

2. Comparison to π0 and the OpenVLA-OFT family on identical eval protocol. TurboVLA’s headline is “match or outperform substantially larger VLA policies” — that claim is true within the comparison table the authors provide, but the protocol differences between LIBERO no-noops and the OpenVLA evaluation script have bitten the field before. A clean apples-to-apples on a held-out task suite would settle it.

3. Failure-mode analysis at the edge of the action chunk horizon. A 12-step chunk at 32 Hz gives you 375 ms of open-loop behavior before the next perception refresh. That is fine for slow manipulation; it is a tight budget for contact-rich tasks. I would want to see a paper on what fails first when you push the chunk size up.

The first checkpoint release on Hugging Face landed July 31 — 24 hours after the paper, which is fast — and the model card documents the eval protocol in enough detail that you can reproduce the LIBERO numbers on a single 4090. The training code is also released, which I appreciate: there is no shortage of papers in this space that publish weights but withhold the training script.

How I would use it

If I were shipping a robot policy today, this is the architecture I would copy, not the specific model. The recipe generalizes: DINOv3 for vision, a small bidirectional encoder for language, a grounded fusion module initialized from a pretrained grounding model, and a chunked action decoder. The 0.2B parameter count and 0.9 GB VRAM are useful for any deployment where you cannot put a 16 GB inference box on the robot — and that is most deployments.

The interesting version of the paper, to me, is the one that drops the LLM at the action head and replaces it with a grounded fusion module that is exactly as wide as it needs to be, and not one transformer block wider. The benchmark result is the way the paper convinces you that the architectural argument is right. The architectural argument is what survives the benchmark.

Paper: arXiv:2607.27205. Code: github.com/H-EmbodVis/TurboVLA. Checkpoints: huggingface.co/H-EmbodVis/TurboVLA.