Open up a vision-language-action model as if it were an office building: a mailroom that cuts photos into cards, a tower whose floors read them, a filing cabinet, and a drafting room that writes the work order ten times over. SmolVLA is the worked example and π0 the comparison; every card and every FLOP is counted by the page, from the published shapes. About 45 minutes of play.
Demos to Deployment timed the drafting desk from outside: a big policy thinks for d ticks, then hands over a chunk of 50 actions. This lab opens the desk up. Picture the model as an office building. Photos from the robot's three cameras, a written request ("put the cube in the box") and a slip with the arm's joint readings arrive at the mailroom. Nothing upstairs reads photos or slips: everything travels on cards, all the same size. The cards go up a tower of floors, the tower files its notes in a cabinet, and a smaller drafting room next door writes the work order. Every term with a wavy red underline is tappable.
Covers SmolVLA §3.1: "a pixel shuffle operation, limiting the visual tokens to 64 per frame"; states "projected into a single token"; images resized to 512×512 (§4.3) · SmolVLM §2.2: pixel shuffle cuts tokens by r², r = 4 for small models · PaliGemma §3.2: 224 px gives 256 image tokens · π0 §IV: 2 or 3 images per robot
SmolVLA's photo desk is SigLIP-B/16 at 512 px (16-pixel tiles); π0's is SigLIP-So400m/14 at 224 px (14-pixel tiles), with no bundling. Both pad the request to 48 word cards: LeRobot's π0 always does, and the released smolvla_base config does too. π0 sends its joint card to the drafting room instead of the tower, so its tower prefix has no joint card.
On every floor, two things happen to the cards. Each card visits every desk on the floor: every weight is one multiply and one add per card, so the staff work is 2 × (weights on the floor) × (cards). Then the floor meeting: each card is compared with every other card and takes notes from the relevant ones, which costs 4 × (meeting width) × cards², because the number of pairs grows with the square. Count it in FLOPs. The photo desk downstairs works the same way, on the tiles of each frame, before they are bundled.
Covers SmolVLA §3.1: visual-token reduction "to obtain a faster inference time" · SmolVLM §2.2: smaller VLMs benefit from r = 4 "as the reduced token count eases attention overhead" · shapes from the released SmolVLM2-500M and SigLIP-So400m configs and π0 appendix A-B
SmolVLM2's tower has 32 floors. SmolVLA closes the top 16: the cards stop at floor 16, and the drafting room reads its notes from there. That is layer skipping, N = L/2. The drafting room is built with one floor for each floor of the tower it reads (LeRobot's default), so closing tower floors also shortens the drafting room. The paper says it "effectively halv[es] the LLM and action expert's computational cost". How much of the whole chunk is that?
Covers SmolVLA §3.1: "setting N to half the total layers (N = L/2) offers a good tradeoff between speed and performance" · §4.3: "We use only the first 16 layers" · Table 8: LIBERO success by N · LeRobot num_vlm_layers = 16, num_expert_layers = -1 (same as the VLM)
The work order is written next door by the action expert: 50 blank lines, one card each, sent through a narrower building (SmolVLA's is 0.75× the tower's width, ~100M weights). It doesn't write the order once. It starts from scribble and redrafts the whole order ten times, each draft a full pass through the drafting room; the tenth goes to the robot. Why drafts, and why scribble, is Fork in the Road's subject (its step 7 is flow matching); here only the cost matters. The trick is that the photos and the request don't change between drafts, so the tower reads them once and files its notes in the filing cabinet (KV caching in general, for serving language models, is Inference Kitchen's subject). SmolVLA's drafting floors alternate: on one kind the drafters read only the cabinet (cross-attention); on the other they read the cabinet and the lines already written above theirs, never below (self-attention with a causal mask, as LeRobot's code runs it). π0's drafters read the cabinet and the whole order, above and below, on every floor.
Covers SmolVLA §3.1: interleaved cross- and causal self-attention, expert width 0.75 × d · §4.3: n = 50, 10 flow-matching steps, ~100M of 450M parameters in the expert · Tables 6–7 · π0 §IV: "caching the attention keys and values for the prefix and only recomputing the suffix … for each integration step" · π0 appendix A-B: expert width 1024, ~300M · LeRobot sample_actions: prefix once with use_cache, then denoise_step × num_steps
FLOPs aren't time. Each stage of the office takes as long as the slower of two things: doing the arithmetic, at the computer's rate F, or walking every weight in from memory once, at bandwidth B. Big piles keep the staff busy (compute-bound); a draft of 50 cards barely uses each weight before the next is needed, so it waits on memory (memory-bound). This lab's computers are made up, round numbers on purpose (toy computers); the shape of the answer is what transfers. Then compare the total with the robot's tick: the number of ticks that pass while the office works is the inference delay d that Demos to Deployment hides with asynchronous inference and Real-Time Chunking.
Covers SmolVLA §3.3: "a real-world frame-rate of 30 frames per second, Δt = 33ms"; the queue never runs dry when g ≥ (E[ℓ_S]/Δt)/n · π0: 50 Hz robots, "inference every 0.5 seconds (after executing 25 actions)", timed on an RTX 4090 with 3 cameras · RTC §2: π0 "spends 46ms on the KV cache prefill alone", d := ⌊δ/Δt⌋
The two offices, in the papers' words and in this lab's count. Paper figures are marked with their source; the FLOPs and toy milliseconds are this page's arithmetic on the published shapes. The papers report task success, not speed side by side: SmolVLA reports no inference time in milliseconds, and the one π0 timing this lab could check is the 46 ms prefill.
Covers SmolVLA §4.3–4.5, Tables 2–3: 450M vs 3.3B, LIBERO and SO100 results, "around 40% faster to train and consumes 6× less memory" · π0 §IV, appendix A-B · RTC §2: the 46 ms prefill
Each is solved when the builder above meets it. There's more than one way to meet each; the note says which levers you pulled.
Eight questions. Answer each by operating the widget in the step named, not from memory. Seven or more earns the check.
smolvla_base config pads to as well); the shapes (SmolVLM2-500M's SigLIP-B/16 and 32-layer, 960-wide decoder, of which SmolVLA keeps 16; an expert 0.75× as wide with interleaved cross- and causal self-attention; PaliGemma's SigLIP-So400m/14 and Gemma-2B; π0's 1024-wide expert); n = 50 and 10 flow-matching steps for both; the order of work (encode, prefill once and cache, then one expert pass per step). The weight counts follow from the shapes: 98M for SmolVLA's expert and 311M for π0's, against the papers' "~100M" and "~300M"; SigLIP-B/16 is 93M in the SmolVLM paper and 86M here, because the count has only the matrix weights, not the pooling head, biases and norms.Sources (exact quotes and sections in SOURCES.md): Shukor et al., SmolVLA (2025) · Black et al., π0 (2024) · Marafioti et al., SmolVLM (2025) · Beyer et al., PaliGemma (2024) · Black, Galliker & Levine, Real-Time Execution of Action Chunking Flow Policies (2025) · the LeRobot SmolVLA and π0 code and the released model configs.
Part of a series of hands-on labs: Inference Kitchen (serving) · Finishing School (post-training) · Arm Playground (kinematics and control) · Policy Pond (reinforcement learning) · Reward Arcade (environments and evals) · Fork in the Road (diffusion policies) · Duck's-Eye View (robot vision) · Demos to Deployment (imitation learning and real-time execution) · Eye Exam (camera calibration) · Dual Controls (real-world RL with a human in the loop) · Inside a VLA (VLA anatomy and compute)