VLA · Phase 6 · Modern VLA Models
6.4 — SmolVLA
A compact VLA designed to be accessible with modest compute.
Not everyone has a server rack. SmolVLA aims at a VLA that trains on one GPU and runs on consumer hardware. This lesson covers the motivation and the asynchronous-inference idea.
Claims about papers, models and textbooks carry numbered references, listed with what each one is cited for in the References. Code marked “Toy model” is our own illustration, not the cited system.
Learning objectives
After this lesson, you should be able to:
- State the motivation for a compact VLA.
- Estimate weight memory for a model size.
- Explain asynchronous inference and its trade-off.
- Explain why community data needs care.
- A compact VLA with modest memory needs
- Perception and action prediction run on one track
- Action execution runs on another
- Chunks are generated while the previous chunk executes
- Higher control rates with chunked generation
The one-sentence idea
Make the VLA small enough to run, and stop waiting for it.
Small models and asynchronous execution make VLAs practical on modest hardware.
Why a small VLA
Existing VLAs are typically very large, often billions of parameters, which leads to high training costs and limited real-world deployability, and they rely on academic and industrial datasets while overlooking the growing amount of community-collected data from affordable robot platforms. That is the motivation stated by the SmolVLA authors.[1] Their answer is a small, efficient, community-driven VLA that reduces training and inference costs while retaining competitive performance, designed so that it can be trained on a single GPU and deployed on consumer-grade GPUs or even CPUs.[1] For a guided tour of the paper itself, with its experiments, a re-check of its tables and a critical review, see the SmolVLA paper guide.
The paper’s own parameter count is not quoted here because I could not confirm it from the abstract-level sources; check the paper for it. The lesson is about the design goals and the one technique the abstract names.
What size means for hardware
The memory arithmetic from lesson 6.1 shows why “billions of parameters” and “consumer hardware” pull in opposite directions. For any model size, here is what holding the weights takes at 16 bits:
for billions in (0.5, 1, 3, 7, 55):
gb = billions * 1e9 * 2 / 1e9 # 2 bytes per 16-bit weight
print(f"{billions:>5} billion parameters -> {gb:6.1f} GB for the weights at 16 bits")Output:
0.5 billion parameters -> 1.0 GB for the weights at 16 bits
1 billion parameters -> 2.0 GB for the weights at 16 bits
3 billion parameters -> 6.0 GB for the weights at 16 bits
7 billion parameters -> 14.0 GB for the weights at 16 bits
55 billion parameters -> 110.0 GB for the weights at 16 bitsToy model. Generic arithmetic for any model, not the size of SmolVLA. Real use also needs memory for activations and caches.
A 55B model (the size of the RT-2-X mentioned in lesson 6.1) needs 110 GB for weights alone, a multi-GPU server. A model under a few billion fits in a gaming GPU’s memory. Small size is what makes single-GPU training and CPU deployment conceivable.
The technique: asynchronous inference
SmolVLA introduces an asynchronous inference stack that decouples perception and action prediction from action execution, allowing higher control rates with chunked action generation.[1] Here is why that matters. A robot with a chunk of actions has two ways to proceed. Synchronous: execute the whole chunk, stop, think about the next one, repeat. Asynchronous: start thinking about the next chunk while the current one is still running, so the robot never waits. A small time-line simulation, with assumed timings:
chunk_len = 20 # control steps per chunk
step_ms = 20 # each control step lasts 20 ms (50 Hz), so executing a chunk takes 400 ms
think_ms = 300 # assumed time for the model to produce the next chunk
execute_ms = chunk_len * step_ms
n_chunks = 10
sync_total = n_chunks * (execute_ms + think_ms) # execute, then wait for the next chunk
async_total = think_ms + n_chunks * execute_ms # next chunk is computed while this one executes (if think <= execute)
print("time to run", n_chunks, "chunks, synchronous: ", sync_total, "ms")
print("time to run", n_chunks, "chunks, asynchronous:", async_total, "ms")
print("idle time per chunk, synchronous: ", think_ms, "ms")
print("idle time per chunk, asynchronous:", max(0, think_ms - execute_ms), "ms")Output:
time to run 10 chunks, synchronous: 7000 ms time to run 10 chunks, asynchronous: 4300 ms idle time per chunk, synchronous: 300 ms idle time per chunk, asynchronous: 0 ms
Toy model. Assumed timings in a simple model. Asynchronous execution only works without pauses when the next chunk is ready before the current one ends; a real system must also handle chunk overlap and a changed scene.
With these numbers the asynchronous version avoids 300 ms of waiting per chunk. But it has a price: the robot is acting on an observation that was taken while the previous chunk was running, so it is slightly stale. That is the trade-off between responsiveness and smooth motion that lesson 1.5 introduced.
Community data
SmolVLA is also built on the observation that community-collected data from affordable platforms is growing but overlooked.[1] Such data is often recorded on different robots with different cameras and by people with different habits, so the harmonising issues of lesson 5.3 and the splitting rule of lesson 3.2 (hold out whole episodes) apply with extra force.
Common misconceptions
Misconception 1 “Small means weak.”
Correction The authors report competitive performance; check the paper for the exact comparisons.
Misconception 2 “Asynchronous inference is free.”
Correction Actions are computed from a slightly older observation.
Misconception 3 “Community data can be used as-is.”
Correction Different robots and habits require harmonising and careful splits.
Engineering takeaways
- Billions of parameters limit deployment.
- Weights alone: 2 bytes per parameter at 16 bits.
- Async removes waiting but uses older observations.
- Community data needs care.
Make it small, and keep the robot moving.
Knowledge check
Try each question first, then reveal the explanation.
Question 1
How much memory for the weights of a 3-billion-parameter model at 16 bits?
Explanation
6 GB.
Question 2
What does asynchronous inference decouple?
Explanation
Perception and action prediction from action execution.
Question 3
What is the price of asynchronous execution?
Explanation
The robot acts on a slightly older observation.
References
Numbered notes in the text, like [1], point here. Each entry says what it is cited for and how that was checked. Papers and books can be revised or misread, so follow the links before relying on a detail. Code marked “Toy model” is our own illustration of an idea, not the code of the cited system.
(2025). SmolVLA: A vision-language-action model for affordable and efficient robotics. arXiv. arXiv:2506.01844
Cited for:
- Existing VLAs are typically very large, often billions of parameters, leading to high training costs and limited real-world deployability; they also rely on academic and industrial datasets and overlook community-collected data from affordable robotic platforms. Checked against the paper’s abstract.
- A small, efficient, community-driven VLA that reduces training and inference costs while retaining competitive performance, designed to be trained on a single GPU and deployed on consumer-grade GPUs or even CPUs. Checked against the paper’s abstract.
- Introduces an asynchronous inference stack that decouples perception and action prediction from action execution, allowing higher control rates with chunked action generation. Checked against the paper’s abstract.
What’s next
Next: RDT-1B, a diffusion foundation model for two-arm manipulation.