TurboVLA runs a robot policy at 32 Hz on a single RTX 4090

Most vision-language-action (VLA) robot controllers have a problem: they ask a 7 billion parameter language model to do a job an action head could do, and then they bill you 200 milliseconds of latency per decision step. A paper out this week on arxiv, TurboVLA, takes the language model out of the control loop and posts numbers that make the larger systems look embarrassing. On an RTX 4090 you can buy today, the full policy runs at 31.2 ms end to end, occupies 0.9 GB of VRAM, and scores 97.7 percent average success on the LIBERO benchmark.

That is enough to push 32 action-chunk predictions per second through a single consumer GPU. The whole model is 0.2 billion parameters, about 6 percent of what Physical Intelligence's pi-0.5 uses for the same job.

The paper is from a group at Huazhong University of Science and Technology, and the code is on GitHub. I have spent the morning reading it, and the architecture choice is more interesting than the headline numbers suggest.

Where the time went

VLA models are supposed to take a camera image plus a natural language instruction ("move the red block to the bowl") and produce the joint velocities that make a robot arm do that. The dominant design, exemplified by OpenVLA and RT-2, treats this like a language task: the visual features get projected into the language model's embedding space, the LLM processes the combined stream, and actions come out as tokens, generated one at a time the way words are.

This is a bad fit for closed-loop control. Autoregressive decoding is sequential by construction, so a 7B parameter backbone that runs text generation fine on a chat interface becomes a wall in front of a robot that wants to react in tens of milliseconds. Two years of "make VLA faster" work has tried to fix this in different ways: parallel action heads, dedicated action experts, continuous action tokenizers, quantization, token pruning, speculative decoding. TurboVLA's argument is that all of those still route the perception through a multi-billion parameter language model before any action is predicted. The big rock in the pipeline is still there.

What TurboVLA actually changes

The shift is architectural. TurboVLA drops the LLM as the central hub and splits the work into three pieces that never pass through a generative language backbone.

First, vision and language get encoded separately. Visual observations go through a DINOv3 backbone (ViT-B for the single arm runs, ViT-L for the bimanual tasks). Instructions go through plain BERT, the kind of encoder that has been sitting in NLP textbooks since 2019. The authors make the point that execution-level robot instructions are short and structured ("pick up the roller," "press the stapler"). They name objects, attributes, and spatial relations. They do not require open-ended prose generation or multi-step planning. A tiny encoder handles that fine.

Second, the two streams are fused through six bidirectional cross-attention layers initialized from Grounding DINO pretrained weights. This is the same kind of cross-modal grounding that powers open-vocabulary object detection. The ablations in the paper are unambiguous here: removing language entirely tanks average success from 97.7 percent to 70.8 percent, with LIBERO-Goal falling to 11.6 percent, but a learned task-ID embedding gets 95.4 percent and natural-language instructions only beat that by another 2.3 points. So the language channel carries real semantic content, not just identity, but it does not need a generative model to extract it.

Third, an ACT-style transformer decoder predicts twelve continuous 7-DoF actions in a single forward pass. No action tokens, no sequential decoding, no language modeling objective at all. Training is behavior cloning with an L1 loss on expert chunks.

The numbers, sourced from the paper

All efficiency numbers below are from the TurboVLA paper's Table 1, measured by the authors on a single RTX 4090 at batch size one. Latency covers the full multimodal input to producing one action chunk (or the equivalent number of autoregressive tokens for the comparison systems). VRAM is the peak resident memory of the complete online policy. I am reproducing these because the paper measures everyone on the same hardware, which is rare and worth crediting.

The contrast with OpenVLA is stark. Same benchmark, same hardware. TurboVLA uses 6.5 minutes as much VRAM, runs in a fifth the wall clock time, and clears it by 21 success points. That is not a small win. It is the difference between a policy that can run on an Jetson Orin Nano and one that needs a desktop card.

The more interesting comparison is OpenVLA-OFT, which is the recent tuned version of OpenVLA with a faster action head. OpenVLA-OFT already matches TurboVLA on accuracy, 97.1 versus 97.7 percent, but needs 16 GB of VRAM and runs at 112 ms instead of 31 ms. So the accuracy gap has closed. What has not closed is the cost gap. The LLM is still in there, still pinning 7.7B of parameters to the policy, still bounding latency at the speed a 7B transformer can run a forward pass. TurboVLA's main claim is that you do not need the LLM there at all for execution-level control, and once you remove it, the latency collapses by a factor that no action-head optimization is ever going to recover.

Does it transfer out of sim

This is the question that always matters for a sim-only robotics paper. The authors deploy on a real AgileX Piper arm across four tasks: grabbing a roller, moving a playing card, pressing a stapler, and stacking three bowls. They fine-tune from the LIBERO checkpoint on 65 teleoperated demonstrations per task. Reported success rates are 92.5, 80, 90, and 87.5 percent over 40 trials each, all beating pi-0.5 under the same protocol.

They also evaluate bimanual tasks on RoboTwin 2.0, 50 tasks requiring two coordinated arms, and TurboVLA scores 60.2 percent average at 43.4 ms latency, beating pi-0.5 at 57.0 percent and 95.6 ms. That is a 7.1 percent accuracy bump on a benchmark with 50 distinct tasks at lower compute.

I am genuinely impressed that the cable stayed intact through a sim-to-real transfer with only 65 demos of fine-tuning. The numbers are not the marketing kind. They are honest enough that you can see the weakest task, the playing card at 80 percent, and ask what makes it hard. That is the texture of a paper written by people who ran the thing.

What it does not claim to do

TurboVLA is explicit about its limits. It targets execution-level control: "pick up the roller," "press the stapler." It is not a task planner. It cannot reason about a long-horizon goal like "first gather the ingredients, then chop them, then assemble the salad." For that you would want an LLM planner upstream of a controller like this, and the paper says so plainly.

This is the part I find most defensible about the work. There has been a two-year pattern of VLA papers that lean on the language model for everything from perception to action to high-level reasoning, get a flexibility win on benchmarks that reward natural language generalization, and quietly absorb a 200 ms latency tax the entire time. TurboVLA separates the concerns. Use the LLM for the things LLMs are good at. Use a small grounding-and-decoding model for the part that needs to be fast. The fact that the result is faster, smaller, and equally accurate on the execution benchmark is a strong case that a lot of the LLM was dead weight for control.

Why a consumer 4090 matters here

The 4090 is not a server part. It is the GPU in a high-end gaming desktop, retailing around $1,600. The thing getting the 32 Hz policy is sitting in someone's office, not in a rack in a datacenter.

That matters because robotics has a deployment problem. The models that hit the top of the LIBERO leaderboard a year ago needed A100 or H100 class hardware, 40 to 80 GB of VRAM, and inference stacks tuned by infrastructure teams. A research lab with one or two 4090s could not even reproduce the benchmark, let alone ship a real robot on the same model. TurboVLA changes the floor. A 0.9 GB inference footprint leaves 22 GB of headroom on the same card, which is enough for a vision stack, the robot drivers, a logging buffer, and a second smaller policy for something else.

The cost math also bends. If a policy can run at interactive rate on a $1,600 card, then a fleet of research arms does not need a shared GPU cluster. Each arm gets its own box. The bottleneck moves off the GPU wall and back onto data collection and embodiment design, which is where the actual hard problems in robotics live.

The honest caveats

A few things the paper does not overclaim and that I want to flag while reading it.

LIBERO is still a simulation benchmark, and simulation benchmarks reward models that use sim priors. The 97.7 percent number is not the real-world number; the real-world tasks are the four I listed, and even those are the ones the authors chose, on a platform they tuned. Take the 80 to 92.5 percent real-world numbers as the realistic ceiling for this architecture on real hardware with a small fine-tuning budget.

The cross-modal interaction layers are initialized from Grounding DINO pretrained weights, so the model is not trained from scratch. That is fine and reasonable, but it means the "0.2B parameter" headline is the inference size, not the total training story. The visual and linguistic priors being imported here are real and large.

The action chunk horizon is tuned. The paper explicitly ablates the action horizon H and reports 96.4 percent at H equals 8, 97.7 percent at H equals 12, and 95.6 percent at H equals 15. The depth of the bidirectional interaction layers follows the same pattern, peaking at N equals 6 and degrading at N equals 8. So the configuration is sweet-spotted, not principled. That is normal for a methods paper, but the 12 step chunk and 6 layer depth are not free choices you can move around without cost.

And OpenVLA-OFT being competitive on accuracy is not nothing. Anyone who already has an OpenVLA-OFT deployment is not going to gain accuracy by switching to TurboVLA. What they gain is the 16 GB of VRAM back and the 3x latency improvement. Whether that is worth ripping out your action head and the surrounding training pipeline depends on what you are doing with the rest of the system. If you are running a closed-loop reactive task, the latency is the product. If you are running a high-step planning loop where decisions happen every few seconds, the 112 ms of OpenVLA-OFT is already fine.

What I take from this

The pattern I keep noticing across robotics, audio, and vision research in 2026 is the same one this paper embodies: the generative LLM was the bootstrap that made multimodal policies feasible at all, and now people are quietly removing it piece by piece as they figure out which parts of the task actually needed it. We saw this with speech models ditching the autoregressive language head for streaming inference, and we are seeing it with VLA models ditching the LLM core for execution control.

TurboVLA is a clean demonstration that for execution-level robot manipulation, the answer to "do we need a 7B LLM in the control loop" is no. You need a visual encoder, a text encoder, a grounding interaction, and an action decoder, and you can run the whole thing on a gaming GPU at the cadence a human cares about. The 32 Hz number is not the part that will stick with me. The part that will stick is that this is the second major control domain in six months where the small specialized architecture beat the large general one at its own task.

If you have a consumer GPU and an interest in robotics, the code is open and the checkpoints are referenced in the repo. The training recipe is in the paper, down to the learning rate and warmup. Reproducing LIBERO is a weekend project at this point. The harder question, what happens when you put it on a new embodiment with messier data, is where the next few months of work will go.