alpamayo declares itself unmaintained, and its April fine-tuning links point at files that moved

The first thing the page says is that it is finished

An IMPORTANT callout sits above the title, and it is a status announcement rather than a feature:

> This repository is no longer under active development and will receive only limited maintenance updates. Future model releases, features, documentation, and community support will be focused on newer Alpamayo versions.

It then points at a new hub, the Alpamayo Recipes repository, as the place to find the latest models, technical reports, tutorials, benchmarks and ecosystem updates, and encourages users to migrate for the current state of the art in physical AI.

Set against that, the repository has no GitHub releases at all, and the last commit on the default branch is dated 2026-09-09. So the branch is still receiving something while the page tells you not to expect features from it.

The naming history explains why there is a successor. In January 2026 Alpamayo-R1 was released at CES 2026 and renamed to Alpamayo 1. In March 2026 Alpamayo 1.5 was released into its own repository, and the update log recommends that version instead. In May 2026 the fine-tuning and post-training scripts were moved to the recipes repository. Three names in five months, and the page you are reading is the oldest of them.

The April fine-tuning entry links at files that have left

The update timeline is a short list, and reading it in order changes what the rest of the page claims.

April 2026: the fine-tuning scripts were released here, with supervised fine-tuning in `docs/FINETUNE_SFT.md` and reinforcement learning post-training in `finetune/rl/README.md`. May 2026: fine-tuning and post-training scripts moved to Alpamayo Recipes, with SFT and RL recipes living in that repository instead.

The tree at the top of the repository lists `.github/`, `.gitignore`, `CONTRIBUTING.md`, `LICENSE`, `README.md`, `SECURITY.md`, `notebooks/`, `pyproject.toml`, `src/`, `tests/` and `uv.lock`. There is no `docs/` directory and no `finetune/` directory.

So the April entry advertises two paths that the May entry says were moved, and neither path resolves in the current tree. The paper-features table compounds it, listing supervised fine-tuning code and reinforcement learning post-training as included in this release.

That is a normal consequence of moving code, and the May entry is the honest record of it. What it leaves behind is a page whose headline feature table and whose timeline disagree about where the training code lives, which is exactly the kind of thing an evaluator should confirm rather than assume.

Four version labels for one set of weights

The model has more names than any of these sources agree on.

The repository title is Alpamayo 1. The weights are published as Alpamayo-R1-10B on Hugging Face. The January 2026 entry says Alpamayo-R1 was renamed to Alpamayo 1. The repository description names an Alpamayo 1 Nano, a name the README never uses. The paper-features table labels this release v1.0. And `pyproject.toml` says `version = "0.1.0"`.

There is also no tag to arbitrate. The repository has no GitHub releases, so nothing on the releases page corresponds to any of those numbers.

The manifest is the most authoritative of them, and it is the one that says 0.1.0, which is a pre one version for a model the table calls v1.0. A reader pinning a dependency or writing a results section has to pick a label and state it, because the repository offers five and checks none of them against each other.

The paper is arXiv 2511.00088, titled Alpamayo-R1: Bridging Reasoning and Action Prediction for Generalizable Autonomous Driving in the Long Tail, so even the citation keeps the old name.

The 22 GB download and the 2.5 minute figure do not reconcile

The test script section carries a timing reference and a size, and the two do not match at the bandwidth given. The script downloads example data, described as relatively small, and the model weights, given as 22 GB. Then: for reference, it takes around 2.5 minutes on a 100 MB/s wired connection.

Twenty-two gigabytes at 100 MB per second is a little over three and a half minutes of transfer before any hashing, and the figure given is two and a half. The direction of the discrepancy suggests the number came from a faster link than the one described, or that the size is measured in different units than the bandwidth.

Either way, budget from the size rather than the time. 22 GB is also the reason the authentication step exists: the model requires access to gated resources, and two of them have to be requested, the Physical AI Autonomous Vehicles dataset and the Alpamayo model weights, before `hf auth login` will do anything.

The hardware floor is stated just as bluntly. An NVIDIA GPU with at least 24 GB of VRAM is required, with an RTX 3090, an RTX 4090, an A5000 and an H100 given as examples, and GPUs below 24 GB are expected to hit CUDA out of memory errors. Linux is tested and other platforms are unverified, and Python is pinned to the 3.12 series.

The CUDA graph path caches shapes and falls back to eager

The optional acceleration is a method call on the model, and it only takes effect after the model is on CUDA and in eval mode:

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

The README is unusually precise about what that does, and the precision is the point. Repeated trajectory inference can replay the diffusion expert with exact-shape CUDA graphs. `max_batch_size` has to be at least `batch_size * num_traj_samples * num_traj_sets`, so the buffer is sized for the largest combination of arguments you will use rather than for one call.

The cache is lazy and bounded. The first supported input shape is captured on demand, up to `max_graphs` exact shape signatures are retained, and any additional signature falls back to eager execution. So the graph path is not all or nothing: a shape you have not seen before still runs, just without the acceleration.

The cost is stated in the same paragraph. Captured graphs hold static CUDA buffers, so the option trades additional GPU memory for lower diffusion-expert launch overhead. That trade lands on a model that already needs 24 GB of VRAM, which is why it is optional and why the configuration is exposed rather than defaulted. A stats attribute, `diffusion_expert_cuda_graph_stats`, reports capture, replay and fallback counts, so you can see how often the fast path is actually taken.

A notebook path, a script path and an exact-pinned torch

Two small path details. The README says a notebook with similar inference code is provided at `notebook/inference.ipynb`, while the tree has a `notebooks/` directory, so the singular path in the text and the plural directory in the tree are not the same string.

The script path does line up: `python src/alpamayo_r1/test_inference.py`, and the wheel packages `src/alpamayo_r1`, so the entry point and the distribution agree. The way to get more trajectories is to change the `num_traj_samples=1` argument at line 60, which is the same parameter the CUDA graph sizing formula multiplies in.

The dependency list explains a lot about what runs this. Two of the ten runtime dependencies are pinned exactly, `torch==2.8.0` and `transformers==4.57.1`, while the rest carry lower bounds, including `transformers`' companion `torchvision>=0.23.0`, `physical_ai_av>=0.2.0` for the dataset, `flash-attn>=2.8.3`, and the usual `einops`, `hydra-core`, `pillow`, `colorlog` and `scipy`.

`flash-attn` gets special handling: the uv configuration sets `no-build-isolation-package = ["flash-attn"]`, so it is built against the environment rather than in an isolated one, which is what a package compiling kernels against the local CUDA has to do. Ruff is configured with a line length of 100, and the source distribution includes only `/pyproject.toml` and `/src`, so the notebooks and tests are not in the sdist even though both are in the repository.

Support splits three ways, and security goes to another inbox

Three channels, each with a rule attached.

Usage questions and discussion go to the Alpamayo forum on the NVIDIA Developer Forums. Code level bugs, documentation issues and feature requests go to GitHub issues, using one of three templates, Bug report, Documentation request or Feature request, and the relevant NVIDIA responder is assigned automatically through the `assignees:` field on the template.

Security vulnerabilities go somewhere else entirely: NVIDIA's Vulnerability Disclosure Programme, hosted on Intigriti, with the instruction not to file security issues publicly here. The root carries both `SECURITY.md` and `CONTRIBUTING.md`, and the licence is Apache-2.0 with a `LICENSE` file.

The paper is worth reading alongside the code, because the table that maps it is specific. Chain-of-Causation reasoning is described in the paper as hybrid auto-labelling with a human in the loop for reasoning traces. The vision-language-action architecture is a Cosmos-Reason backbone plus an action expert. Trajectory prediction is a 6.4 second horizon with 64 waypoints at 10 Hz.

The repository itself points readers at the Hugging Face model card first, saying it holds the details on architecture, inputs and outputs, licensing and tested hardware, while this page covers setup, usage and questions. That is a reasonable division, and it is also a reminder that the model card is where the authoritative numbers live, not the README.

Editorial conclusion

Read Alpamayo 1 as a research release to study, not as a dependency to build on, because the repository itself routes all future work to a newer hub and the training recipes have already been moved out of it. If you want the model, the gated Hugging Face weights and the 24 GB VRAM floor are the real constraints, and the CUDA graph option is the one piece with a documented memory cost you should decide about deliberately. Before you start, check which of the linked fine-tuning files still resolve, since the April 2026 entries point at paths the tree no longer has, and expect the name to have changed more than once, since the same weights are called Alpamayo-R1, Alpamayo 1 and something else again in the repository description.

Frequently asked questions

Official sources

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