The 8 GB Lab Book · Chapter 27
The Nano-legal VLA menu
- Board
- Jetson Orin Nano Super
- Mode
- 15W
- Summary
- Two tests, a named board and a GB that fits, left two names on the menu, NanoVLA and a planner. SmolVLA stays on it because I ran it, not because anyone named this board: 1,602 to 1,744 MiB as a process and 1,265 ms per 50-action chunk at 15W, 7.6x the SwiftVLA authors' Orin time. Beside the full brain it did not fit: the stacked run stopped at 326 MiB available, and two reruns on 2026-10-04 stopped at 422 and 363. SmolVLA plus the house SLM is the pair that fits, 6,853 of 7,620.
What I expected
My prior for the menu was that it would be long, because each VLAVision-language-action model: a vision-language model extended to output robot actions, often as a short chunk of future commands. paper says 'edge' somewhere. I expected to use the day to select from five or six runnable models. I expected to select by Hz.
For SmolVLA I had one number, 450 M x 2 bytes = 0.9 GB of FP1616-bit floating point (half precision): half the bytes of FP32, and tensor cores run it at much higher throughput than FP32. weights. I had no number for time here. The SwiftVLA authors measured 0.166 s per chunk on a Jetson Orin. I assumed that this time would increase by a factor of two or three on a smaller GPU at 15W.
The theory
Fit is an inequality, and a chunk is not a decode
The fit rule (arithmetic)
alone with the floor: 7,620 - 1,498 = 6,122 beside the Day 25 pile: 7,620 - 5,178 = 2,442 SmolVLA on paper: 2,442 - 1,124 = 1,318 MiB left SmolVLA as a process: 1,602 to 1,744 MiB; brain first, the load stopped at 326 available; 422 and 363 in the two reruns of 2026-10-04 GR00T 6,000 + a runtime > 6,122: out alone = OpenVLA 7B x 2 bytes = 14 GB (arith.), pi0 16.2 GB: out twice over
Smolvla here (measured + arithmetic)
prior: 450 M x 2 bytes = 0.9 GB 1,124 MiB read after the libraries loaded; 1,602 and 1,744 from before the process existed 1,265 ms per chunk of 50 alone, 1,264 beside the SLM: 25 ms of compute per action (not latency) SwiftVLA authors' Orin, same model: 166 ms per chunk, 7.6x faster = 0.8 Hz per chunk at 15W
The memory bandwidthHow many bytes per second the memory system can deliver; on a shared-memory board the CPU, GPU and video engines all draw from the same supply. floor for one forward over 0.9 GB of weights is 0.9 / 68 = 13 ms. It is 32 ms at the 28 GB/s that a decodeThe phase after prefill where a language model generates one token at a time and re-reads its weights for each one; it is usually limited by memory bandwidth. really uses (Chapter 2). 1,265 ms is 40x that floor, so this chunk is not a bandwidth-bound decode. My guess is several passes of the action head for each chunk, with a Python runtime and no TensorRT engineThe compiled, GPU-specific plan TensorRT produces from a network; it has to be rebuilt for a different GPU or TensorRT version. below it.
The two tests, applied (arithmetic on paper numbers, one measured)
- named this board by its authors or NVIDIA
- 2 of 7
- measured here
- 1 of 7
- fits beside the full brain
- 0 of 1 tried
The setup
python3 ~/day27_smolvla.py
cat ~/day27/results.json# a row needs: the paper or NVIDIA naming 'Orin Nano' or 'Jetson Orin' + a stated GB or a measured GB on that device
# no device name -> no row. No exceptions for famous models."model": "lerobot/smolvla_base" "params_claimed": "~450M (SmolVLA paper)" "steps": [ ... ] "load_s": 54.689 "ram_delta_mb": 1124 "torch_alloc_mb": 926.234 "chunk_infer_ms_median": 1265.32 "chunk_infer_ms_p99": 1287.661 "hz_per_chunk": 0.79 "n_action_steps": 50
The measurement
| What | Expected | Measured | Note |
|---|---|---|---|
| SmolVLA (HF, 450M) | 0.9 GB fp16 weights | 1,602 / 1,744 MiB as a process (1,124 read after libraries), 1,265 ms per chunk (0.8 Hz), chunk 50 | 'consumer-grade hardware' (SmolVLA paper); the Orin chunk time is from the SwiftVLA authors |
| VLM-as-planner: Qwen2.5-VL-3B (NVIDIA blog) | weights about 1.5 GB (estimate) | board peak 5,255 MiB alone (Day 19) | NVIDIA names it for Orin Nano 8GB; not a VLA; a planner for the intent layer; not fit-tested beside the pile |
The menu in GB, one dashed line at 7,620
Line at usable 7,620
| candidate | GB | time per chunk | source |
|---|---|---|---|
| SmolVLA 450M | 1,602 to 1,744 MiB | 1,265 ms, chunk 50, 0.8 Hz | this GPU, 15W |
| SmolVLA + house SLM, stacked | 6,853 MiB, 767 left | chunk 1,264 ms; SLM tool call 1,285 ms beside the waiting VLA | stacked run 2026-09-27, pair log |
| brain first, then SmolVLA, rerun 2026-10-04, n=2 | pile 5,174 / 5,017 MiB before the VLA | guard fired at 422 / 363 MiB available | did not fit either time |
| SwiftVLA ~450M | 1.4 GB | 0.167 s on an unnamed Orin | paper; the Orin variant is unnamed, so it fails the naming test |
| NanoVLA | not stated | not stated, '52x faster' | abstract |
| pi0 3.3B | 16.2 GB as run | 2.966 s on Orin | SwiftVLA paper |
| OpenVLA-7B | 14 GB fp16 (7B x 2 B, arith.) | about 2 Hz on AGX Orin | reports; GB is arithmetic |
| GR00T N1.5 ~3B | 6 GB + runtime | - | NVIDIA: Thor |
| Qwen2.5-VL-3B | peak 5,255 MiB alone; weights ~1.5 GB (est.) | planner, not a VLA | Day 19 / 26 |
Where it broke
The menu became empty when I wrote the rule as two tests. Did the authors or NVIDIA write the name of this class of board? Does the GB fit beside what is already resident? 'edge' failed the first test. 14 and 16 GB failed the second test without one run.
The fit rule failed on the board. 2,442 - 1,124 = 1,318 MiB vs MBA mebibyte (MiB) is 2^20 bytes and a megabyte (MB) is 10^6 bytes; some tools label MiB as "MB", so check which one a tool actually counts. left was arithmetic on a number read after the Python and CUDA libraries were already in. Counted from before the process exists, SmolVLA is 1,602 and 1,744 MiB in two runs. With the brain resident first, 5,191 MiB, the load took MemAvailable to 326 MiB and my guard killed every resident. VLA first, the brain's STT took it to 393. The pair SmolVLA + house SLMSmall language model: a language model small enough, usually after quantization, to run on edge hardware instead of a data-center GPU. fits: 6,853 of 7,620 MiB, 767 left, chunk 1,264 ms beside the SLM and 1,265 alone. Two reruns on 2026-10-04 did the same: the brain at 5,174 and 5,017 MiB, then the VLA load took MemAvailable to 422 and 363 and the guard fired.
The time increase was 7.6x, not two or three. It is hardware and runtime together. The SwiftVLA Orin is unnamed. If it is an AGX, it has more SMs and a higher clock than a Nano capped at 612 MHz in its 15W mode (Chapter 4). The rest is runtime, and I have not split the two. The guess and the measurement sit on this page under different labels for that reason.
For most of an afternoon, I read 'edge' as 'Nano'. The rule that corrected this is two lines long. The correct time to write it was before I opened the first paper.
Summary
- "Runs on Jetson" without the model name of the Jetson fails the first test. AGX Orin has 64 GB. This board has 7.6 GB.
- The 450M class is the full Nano-legal VLA space that I found. The SwiftVLA authors report both entries at approximately 6 Hz per chunk on an Orin. SmolVLA ran here at 0.8 Hz per chunk, at 15W.
- SmolVLA fits beside the house SLM alone, 6,853 of 7,620 MiB, and not beside the full brain: the stacked run stopped at 326 and 393 MiB available in the two load orders. Two reruns on 2026-10-04 stopped at 422 and 363 MiB with the brain first.
Sources
These sources are not mine. Measured numbers came off my own board; specs, estimates and paper figures are labeled as such.
- NanoVLA paper (Orin Nano 8GB + LeRobot)
- SmolVLA paper
- NVIDIA Gemma 4 VLA demo on Nano Super
- Jetson AI Lab VLA page (Thor targets)
- LiteVLA-Edge / related Orin writeups
- day27/rerun-2026-10-04/summary.json: day27_stacked.sh residents_first twice on 2026-10-04 (pile txt, ram csv, tegrastats)