AlpaSim: NVIDIA's closed-loop simulator for end-to-end AV policies
AlpaSim is an open-source autonomous vehicle simulation platform designed for development and testing of end-to-end AV policies
At a glance
- What is it?
- AlpaSim is a Python and gRPC research simulator that runs driving policies against NuRec-rendered sensor data, with Docker Compose for local runs and SLURM tooling for clusters. It is built for policy validation, not for production autonomy.
- Who is it for?
- Adopt AlpaSim if you are validating or regressing an end-to-end driving policy and can supply a CUDA GPU plus the NuRec sample dataset. Do not adopt it if you need a mature, widely deployed AV stack or a simulator that runs comfortably on CPU only; the README points to Docker Compose, a SLURM tool, and a Hugging Face dataset, and the tutorial path assumes NuRec.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap AlpaSim fills: closed-loop testing for learned driving policies
Most driving-policy repositories ship a checkpoint and an evaluation script that scores one frame at a time. That tells you how a model behaves on a fixed dataset. It does not tell you what happens when the model's own output steers the car into a situation the dataset never contained. AlpaSim is aimed squarely at that second question. The README describes it as a platform for testing end-to-end AV policies in a closed-loop setting, simulating sensor data, vehicle dynamics, and traffic scenarios in one testbed.
The stated use cases are telling: algorithm validation, safety analysis on edge cases, benchmarking and regression testing across models and configurations, and debugging. Every one of those is a research or engineering-loop activity rather than a deployment activity. Nothing in the README claims production use, and the word research appears in both the title and the description.
Who is it for, concretely? A team that already has a policy and wants to know how it degrades under closed-loop feedback. The README lists four supported driver policies: Alpamayo-R1, Alpamayo 1.5, VaVAM, and Latent TransFuser v6. If your model is not one of those and not shaped like them, you are writing an integration, not running a test.
How AlpaSim is put together: microservices, gRPC, and a pluggable renderer
The architecture is microservices with gRPC as the connective tissue. The README states that a modular gRPC interface lets researchers swap out components with custom implementations, and that the microservices layout supports distributed computing and multi-node deployments. The repository layout backs this up: src/grpc holds the API definitions, and pyproject.toml declares a uv workspace whose members include src/controller, src/runtime, src/driver, src/trafficsim, src/physics, src/eval, src/wizard, and src/utils, plus a Rust crate at src/utils_rs.
That split matters more than it first appears. Each workspace member is installable as its own extra, so a driver-only install does not drag in the traffic simulator. The Dockerfile compiles protos in /repo/src/grpc as a build step, which confirms that the gRPC surface is generated at image build time rather than shipped pre-built.
Rendering is the other half. The renderer is pluggable, with NuRec as the default and OmniDreams video-model rendering available through FlashDreams. The README claims stateful video-model rendering gives stronger dynamic-object and non-rigid visual fidelity, and that camera feeds are configurable by field of view, resolution, and frame rate. The trade-off is implicit but real: a video-model renderer is a learned component sitting between the scene and the policy, so any artifact it introduces is part of what your policy sees.
Installing AlpaSim and running a first simulation with Docker Compose
The README does not give a bare pip install as the entry point. It points to docs/TUTORIAL.md for local runs on a single machine via Docker Compose, and the Dockerfile shows what the image is built from. The build command is documented at the top of the Dockerfile itself, run from the repository root.
docker build -t alpasim-base .The Dockerfile selects a base image by architecture: nvidia/cuda:12.4.1-cudnn-devel-ubuntu22.04 for x86_64 and nvcr.io/nvidia/pytorch:25.08-py3 for aarch64. If your dependencies are private, the build accepts a netrc secret.
docker build --secret id=netrc,src=$HOME/.netrc -t alpasim-base .After the image exists, follow docs/TUTORIAL.md. The README says the default tutorial path uses NuRec; the OmniDreams backend is documented separately in docs/VIDEO_MODEL.md. Scene data comes from outside the repository: the README recommends the PhysicalAI-Autonomous-Vehicles-NuRec 26.01 sample set on Hugging Face for new runs, with release selection and legacy dataset commands in data/scenes/README.md. Sample artifacts are tracked in the repo through Git LFS.
For cluster deployment the README names src/tools/run-on-slurm rather than describing the workflow inline. Expect the tutorial, not this page, to be the authoritative sequence.
Where AlpaSim will not help you
The first constraint is hardware. The Dockerfile builds from CUDA base images and installs datacenter-gpu-manager-4-cuda12 plus dcgm-exporter, and the aarch64 path falls back to an NGC PyTorch image because, as the Dockerfile comment puts it, that is the only CUDA-enabled PyTorch source on ARM. There is no documented CPU-only path. If your team does policy work on laptops without NVIDIA GPUs, this is the wrong tool.
The second is data dependency. The README does not describe a synthetic scene generator that produces scenarios from nothing. It points at a Hugging Face dataset and at data/scenes/README.md for release selection. New runs are recommended against the 26.01 sample set. That means your test coverage is bounded by what ships in that dataset, and reproducing a specific regression depends on the scene being present.
The third is maturity of the policy list. Transfuser is marked provisional in the README, and the closing line of that section reads "Stay tuned for additional model support." If your policy is not among the four, you are on the plugin path described in docs/PLUGIN_SYSTEM.md, which is real work rather than configuration.
Finally, the README does not document rollback or version pinning for the simulator itself. Releases exist (v2026.5 on 2026-06-04, v2026.4 on 2026-04-24), and CHANGELOG.md is described as carrying "major updates and migration notes," but the README itself is silent on how to return to a prior release once you have moved forward.
AlpaSim against CARLA-style simulators and dataset-only evaluation
The obvious comparison is CARLA, the long-standing open-source driving simulator. The difference is in where the pixels come from. A classic engine-based simulator renders geometry and materials through a graphics pipeline, so scenes are authored assets and the visual domain is synthetic by construction. AlpaSim defaults to NuRec, a neural reconstruction renderer, with OmniDreams available as a video-model backend. The scenes are reconstructed from real driving data rather than modeled by hand.
That choice buys photorealism and sensor statistics closer to the source data. It costs you editability. In an engine-based simulator you can place a pedestrian anywhere and rerun. With a reconstruction-based renderer, the scene is what was recorded, which is why the sample dataset and the scene release selection in data/scenes/README.md carry so much weight. The README's safety-analysis use case, evaluating behavior in edge cases, sits awkwardly against that constraint unless the edge cases are already in the data.
The second alternative is not a simulator at all: open-loop evaluation on a logged dataset, which is what most policy repositories do. It is far cheaper and needs no renderer. It also cannot answer the question AlpaSim exists to answer, because the policy's own errors never feed back into what it sees next. If your evaluation already closes that loop some other way, AlpaSim adds a renderer and a service mesh you may not need.
Maintenance, licensing, and what a fork costs
The repository is not archived, and the last push was on 2026-09-15. Two releases landed in 2026: v2026.5 on 2026-06-04 and v2026.4 on 2026-04-24. The README lists a named project lead and tech leads, and MAINTAINERS.md exists at the top level, so ownership is not anonymous. It also lists an NV Developer Forum for usage questions and a GitHub issue flow with auto-assigned responders, which suggests questions get routed rather than dropped.
Upgrade cost is the part to think about before you commit. This is a uv workspace with eleven members, a Rust crate, a compiled gRPC layer, a CUDA base image, and a scene dataset with its own release cadence. Moving from one simulator release to the next means rebuilding the image and re-checking that your dataset release still matches; the README directs you to CHANGELOG.md for migration notes, which implies migrations happen. Pin your dataset release and your image tag together.
On licensing: the project is Apache-2.0, stated in the README and present as LICENSE. Apache-2.0 is permissive and includes an explicit patent grant, which is friendlier than MIT for a project that may touch patented techniques. That is a description of the licence text, not advice. Two things sit outside it and deserve a look before you ship anything: the NuRec, OmniDreams, and FlashDreams components are separately hosted projects with their own terms, and the recommended scene dataset is published on Hugging Face under its own terms. The Apache-2.0 grant on this repository does not automatically extend to either.
Editorial conclusion
Adopt AlpaSim if you are validating or regressing an end-to-end driving policy and can supply a CUDA GPU plus the NuRec sample dataset. Do not adopt it if you need a mature, widely deployed AV stack or a simulator that runs comfortably on CPU only; the README points to Docker Compose, a SLURM tool, and a Hugging Face dataset, and the tutorial path assumes NuRec. Verify first that your machine satisfies the Dockerfile's CUDA base image and that you can pull the PhysicalAI-Autonomous-Vehicles-NuRec 26.01 sample set, because no run happens without scene data and a renderer backend.
Frequently asked questions
Is there any open-source autonomous driving software available?
AlpaSim is one example: NVIDIA publishes it under Apache-2.0 for research and development of end-to-end AV policies. It is a simulator rather than a complete vehicle stack, and the README lists four supported driving policies including Alpamayo-R1 and VaVAM.
What algorithms are used in autonomous vehicles?
AlpaSim does not answer this directly, but its supported policies show the shape of current research: Alpamayo-R1 is described as a VLA driving policy with chain-of-causation reasoning, VaVAM is an autoregressive video-action policy, and Transfuser is a latent policy developed for NAVSIM.
What kind of software is used in autonomous vehicles?
AlpaSim itself is Python with a gRPC microservices architecture, a uv workspace, and a Rust component at src/utils_rs. The Dockerfile builds on CUDA base images and installs Prometheus and DCGM exporters for telemetry.
What is an autonomous driving system?
The README does not define the term. What it shows is one research view of the problem: AlpaSim tests end-to-end AV policies in a closed loop by simulating sensor data, vehicle dynamics, and traffic scenarios together, and it supports policies such as Alpamayo-R1 and VaVAM.
Community notes