Practices
Exercises for building intuition about VLA models: reading, running released code, and mapping ideas onto our SO-100 results.
What is and is not here
BotManifold has no driving simulator, so none of these exercises run a driving policy inside Studio. They are reading and analysis exercises, plus one optional run of the released model on your own GPU, plus experiments we have already run on the SO-100 arm.
1. Reading questions (no hardware)
Read the Alpamayo-R1 paper and answer in your own words. Write the answers down; the point is to find where you cannot.
- What does the model output besides a trajectory, and which reward term ties that output to the trajectory?
- Why predict acceleration and curvature instead of positions? What would break otherwise?
- The training decoder and the inference decoder differ. What does each buy?
- Which evaluation in the paper is open loop and which is closed loop? Which claim would you trust more for deployment, and why?
- Where could the Chain of Causation labels be wrong, and how would that show up in behaviour?
- Pick one limitation the authors state. Design an experiment that would measure it.
2. Run the released model (optional, needs a GPU)
The repository's README states these requirements:
- A GPU with at least 24 GB of memory (it names RTX 3090, RTX 4090, A5000, A100 and H100; 16 GB GPUs are expected to run out of memory)
- Python 3.12 on Linux
- Hugging Face access approved for both the gated weights and the gated Physical AI AV dataset
Steps follow the README: create a virtual environment with uv, run uv sync, log in with
hf auth login, then run python src/alpamayo_r1/test_inference.py. The script downloads example
data and the weights (about 22 GB). Raising num_traj_samples gives several trajectories and
reasoning traces for the same scene.
This practice is inference only. Training or RL post-training of a 10B model needs a
multi-GPU cluster and is out of scope on our hardware. The README says the fine-tuning scripts
have moved to alpamayo-recipes; we have not checked whether fine-tuning fits on one card.
The weights are about 22 GB, so a 24 GB card has very little headroom. One trajectory sample
should fit; more samples (num_traj_samples), the CUDA-graph option or other GPU processes may
run out of memory, and the README suggests lowering num_traj_samples if so. The tower's RTX 3090
meets the stated minimum, but we have not run this ourselves yet. Treat it as untested until a
run is recorded here. Things to look at once it runs:
- Read the reasoning trace, then the trajectory. Does the text describe what the path does?
- Sample several trajectories for one scene. How different are they, and does the reasoning differ when the path differs?
- Use the README's note that the released model was not RL post-trained, and compare behaviour with what the paper reports for the RL stage.
Licence: inference code is Apache 2.0, the weights are under a separate licence (OpenMDW-1.1 per the model card). Read the model card before any use beyond research.
3. The same ideas on a robot arm
We ran the driving ideas on a simulated SO-100 arm. The arm experiments are not part of the course materials, but the results are a second, independent check of the lessons:
| Idea from driving | Experiment | What we measured |
|---|---|---|
| Horizon length matters | The same policy with different chunk lengths | Chunk length accounted for about half of the failure of a reach policy |
| Clean demonstrations hide recovery | Demonstrations with and without injected disturbance | Pick-and-place went from 0 percent to 94 percent with disturbed demonstrations and a suitable chunk length |
| Vision instead of privileged state | Policies that see only the camera | 90 to 92 percent from the camera alone |
| Language conditioning | A language-conditioned policy that must pick a named colour | SmolVLA reached 8 to 13 percent frozen and 3 to 7 percent fully fine-tuned; the cause is open |
For each row, ask what the closed-loop success rate showed that the training loss did not, and which line of the Alpamayo-R1 paper's limitations it mirrors.
4. Predict, then run: small experiments on a CPU
The tutorial's reference code runs on a laptop CPU, most of it in seconds and the largest in a few minutes. For each row, write your prediction
down first, then run the command and compare. A wrong prediction is the useful outcome: it marks
what the module has not yet made intuitive. Commands run from the repository root with the tutorial
dependency group (uv run --group tutorial python -m libs.tutorial.<module>).
| Module | Predict first | Then check |
|---|---|---|
imitation | Behaviour cloning on clean expert data, in a lane with stronger disturbances than in training: how often does it leave the lane? And DART, DAgger? | We got 29 percent for behaviour cloning and 0 for DART and DAgger. See Imitation learning |
action_heads | An instruction says "either": demonstrations go to one of two squares at random. Which of a regression, a binned and a flow-matching head ends on a valid square? | We got 31, 74 and 88 percent. See VLA models |
label_quality | Mining rare scenes with k = 10, 25 and 50: which finds the rare clusters? | 5, 24 and 40 percent of the top scenes are rare. See Driving data |
multi_agent | A marginal and a joint predictor are trained on the same crossing demonstrations. Which samples colliding futures, and which is better for each car alone? | Only the marginal one collides (11 percent of conflict scenes); per car they are about equal. See Predicting other drivers |
route_conditioning | At a fork, which of four learners takes the branch you ask for? | Only the one given the route (100 percent against 50 percent). See Route conditioning |
planning | How much does a car that follows a path with a kinematic model deviate at a tight curve? | See Planning and vehicle models |
Then change one thing and predict again: halve the training steps in action_heads, give
mining_study a different rare_share, or widen the disturbance in imitation.evaluate. If you can
say which way the number will move and roughly why, the module has done its job.
5. Worked skeleton for the reading questions
For question 3 of section 1 (training and inference decoders differ), a good answer has three parts. Fill in each from the paper, in your own words:
- The training objective. What loss trains the trajectory tokens, and what does it need at training time that is not available at drive time?
- The inference path. What produces the waypoints, and what does it read from the backbone?
- The cost of the gap. Latency is quantified in the paper's table. Work out the totals by hand (the concepts page shows how) and say what extra cost the token route would have.
Use the same three-part shape for the other questions: what is claimed, what evidence supports it, what would change your mind.
Reporting back
This section is meant to be reviewed. Note what was unclear, what was wrong, and what you could not run. Those notes decide what is added next.