NVIDIA Alpamayo 1: a 10B reasoning VLA model for autonomous driving

What Alpamayo 1 is, and the problem it addresses

End-to-end driving models typically output a trajectory and nothing else. That is enough to steer a car in the common case and useless when the car has to explain why it slowed down, why it chose a lane, or why it hesitated at an intersection. Alpamayo 1 is built around the claim that the reasoning should be produced by the same model that produces the path. The README describes it as an open 10B reasoning vision-language-action model that pairs driving trajectories with Chain-of-Causation reasoning, and the paper it implements is titled "Alpamayo-R1: Bridging Reasoning and Action Prediction for Generalizable Autonomous Driving in the Long Tail". The long tail is the target: rare situations where a purely reactive policy has no precedent to lean on. The audience is researchers and engineers working on autonomous driving and physical AI who want to inspect the reasoning trace alongside the predicted path, and who have the hardware to run a 10B model locally.

How the model is put together: Cosmos-Reason backbone plus an action expert

The architecture is a hybrid. A Cosmos-Reason backbone handles the vision and language side, and a separate action expert produces the trajectory. The README's comparison table lists the vision-language-action architecture as "Cosmos-Reason backbone + action expert", and the trajectory prediction spec is 6.4 seconds of horizon with 64 waypoints at 10 Hz. The reasoning output is trained through what the README calls hybrid auto-labeling with a human in the loop for reasoning traces, which is the honest way to say the Chain-of-Causation text is partly machine-generated and partly curated. That matters when you read a trace: it is a learned artefact, not a verified causal account of the scene. The action expert is a diffusion model, which is why the optional CUDA graph path exists at all. Repeated inference with a diffusion expert pays a fixed launch cost per denoising step, and capturing the expert in a CUDA graph is a way to cut that overhead when input shapes repeat.

Installing Alpamayo 1 and running the first inference

The repository expects uv for environment management and pins Python to 3.12.x in pyproject.toml. Install uv first, then create the virtual environment and sync dependencies from the lockfile.

curl -LsSf https://astral.sh/uv/install.sh | sh
export PATH="$HOME/.local/bin:$PATH"
uv venv ar1_venv
source ar1_venv/bin/activate
uv sync --active

The sync pulls torch 2.8.0, transformers 4.57.1 and flash-attn, which is why pyproject.toml sets no-build-isolation-package for flash-attn. Expect the build step to take a while.

Both the weights and the dataset are gated, so authentication is not optional. Request access to the Physical AI AV Dataset and to the Alpamayo-R1-10B weights on HuggingFace, then log in from the CLI.

pip install -U huggingface_hub
hf auth login

The test script downloads example data and the model weights, which the README states are 22 GB. On a 100 MB/s wired connection it notes that this takes around 2.5 minutes.

python src/alpamayo_r1/test_inference.py

What you should see is a predicted trajectory together with a reasoning trace. To get more of them, the README says to raise the num_traj_samples=1 argument on line 60. There is also a notebook at notebook/inference.ipynb with similar code if you prefer to step through it interactively.

If you plan to run the same shapes repeatedly, the README documents an optional CUDA graph path for the diffusion expert. Call it after moving the model to CUDA and calling eval().

model.eval()
model.enable_diffusion_expert_cuda_graph(
    max_batch_size=16,
    max_graphs=4,
)

Set max_batch_size to at least batch_size * num_traj_samples * num_traj_sets. The first supported shape is captured lazily, up to max_graphs signatures are retained, and anything beyond that falls back to eager execution. Captured graphs hold static CUDA buffers, so this trades GPU memory for lower launch overhead. The stats attribute model.diffusion_expert_cuda_graph_stats reports capture, replay and fallback counts, which is the only way to know whether the graphs are actually being used.

The 24 GB VRAM floor and the Linux-only assumption

The requirements table is blunt: Python 3.12.x, an NVIDIA GPU with at least 24 GB of VRAM such as an RTX 3090, RTX 4090, A5000 or H100, and Linux as the tested operating system with other platforms unverified. The README adds that GPUs below 24 GB will likely hit CUDA out-of-memory errors. That is a hard floor for a 10B model plus a diffusion action expert, and the optional CUDA graph path makes it worse, since captured graphs keep static buffers allocated. If you are already near the limit, enabling graphs is the wrong first move; get a single inference working in eager mode before you spend memory on launch overhead. The unverified-platform note is also worth taking literally. Nothing in the README claims macOS or Windows support, and flash-attn plus a pinned torch build make a non-Linux setup a research project of its own.

Where Alpamayo 1 is the wrong tool

The most important limitation is not technical. The README carries a notice at the top stating that the repository is no longer under active development and will receive only limited maintenance updates, and that future model releases, features, documentation and community support are focused on newer Alpamayo versions hosted in the alpamayo-recipes hub. The updates list confirms the direction: Alpamayo 1.5 was released in March 2026, and in May 2026 the fine-tuning and post-training scripts moved out to Alpamayo Recipes, with pointers to the SFT and RL recipes there. So the SFT and RL material that once lived here is no longer the maintained copy. If your plan is to fine-tune on your own fleet data and keep doing so for years, this repository is the wrong starting point; the README tells you to migrate. The second limitation is scope. This is a research model with a trajectory head, not a driving stack. It produces a 6.4 second, 64 waypoint, 10 Hz trajectory and a reasoning trace. It does not ship planning, control, sensor drivers or safety validation, and the README does not document rollback, guardrails or any runtime safety mechanism. Treating the output as a control signal without your own verification layer is outside what the repository describes.

How it differs from a plain trajectory-prediction model

The obvious comparison is a conventional trajectory prediction model, the kind that takes perception output and regresses waypoints. The difference is that Alpamayo 1 emits a Chain-of-Causation trace from the same forward pass that emits the trajectory, using a Cosmos-Reason backbone for the language side and a separate diffusion action expert for the path. A waypoint regressor gives you a number to check against ground truth. Alpamayo 1 gives you a number plus a sentence about why, and the sentence is the part you can read when the number is wrong. That is a real debugging affordance and also a new failure surface, because a fluent reasoning trace can be wrong in ways a numeric error cannot be. The trade-off is compute and complexity: a 10B model with a diffusion expert needs 24 GB of VRAM, where a smaller predictor would not. If you only need waypoints and never intend to inspect reasoning, you are paying a large hardware and dependency cost for an output you will ignore.

Licence, maintenance and what upgrading costs you

The code is Apache-2.0, per the LICENSE file and the badge in the README. That covers the repository. It does not automatically cover the model weights or the dataset, which are gated behind HuggingFace access requests and carry their own terms; the README points at the HuggingFace Model Card for licensing details on the model itself, so read that before you plan anything commercial. The maintenance picture is the deciding factor for most teams. The last push to this repository was on 2026-09-09, which is recent, but the README's own notice says the project is no longer under active development and will receive only limited maintenance updates. Recent commits and active development are not the same thing here, and the project says so itself. The upgrade path is a migration rather than a version bump: Alpamayo 1.5 exists as a separate repository, and the fine-tuning and post-training scripts now live in Alpamayo Recipes. If you build against Alpamayo 1, budget for the move. Support channels are split accordingly, with usage questions directed to the Alpamayo NV Developer Forum, code and documentation issues to GitHub issue templates, and security reports to NVIDIA's Vulnerability Disclosure Program rather than public issues.

Editorial conclusion

Adopt Alpamayo 1 if you have a 24 GB NVIDIA GPU, Linux, and a reason to study how trajectory prediction and textual reasoning sit in one model, and if you accept that the README now directs new work to newer Alpamayo versions. Do not adopt it as the base for a production driving stack or for a long-lived fine-tuning programme, because the repository states it is no longer under active development and that fine-tuning scripts have moved to Alpamayo Recipes. Before you commit, verify three things: that your HuggingFace account has been granted access to both the Physical AI AV Dataset and the Alpamayo-R1-10B weights, that your GPU has at least 24 GB of VRAM, and that your Python is exactly 3.12.x as pyproject.toml pins it. Then run the test script once and read the reasoning trace it prints next to the trajectory, because that pairing is the whole point of the model.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. NVlabs/alpamayo on GitHub
4. README