NVIDIA unveiled Alpamayo 2 Edge, an in-vehicle reasoning model for autonomous driving developers. It generates driving rationales and future trajectories from surrounding camera views and navigation inputs. In routine situations, it reduces reasoning to lower the computational load on the vehicle computer. Developers can use closed-loop learning and deployment tools together to test onboard models.

1. Reduce reasoning and retrain on driving outcomes

Built on NVIDIA Cosmos 3 Edge, this 2-billion-parameter model connects visual and language interpretation to driving actions. It takes multi-view camera footage, past motion, and navigation inputs to generate driving rationales and future trajectories.

In routine driving situations, it emits a <NOMINAL> token instead of generating lengthy rationales. This adaptive approach generates reasoning when needed, reducing unnecessary tokens and saving reasoning computation.

Training starts with distillation of reasoning from Alpamayo 2 Super into the smaller model, followed by closed-loop reinforcement learning in AlpaGym simulations. Distillation transfers knowledge from a larger model to a smaller one. Closed-loop reinforcement learning lets the model experience the outcomes of its actions and improve through rewards.

Post-training further adjusts performance after pretraining. NVIDIA reports that this closed-loop reinforcement learning improved closed-loop driving performance by 48.9% over the best model without the same reinforcement learning.

2. Simulation comparisons and onboard latency

AlpaSim's closed-loop evaluation incorporates the model's actions into the simulation to examine driving outcomes.

NVIDIA reported the following distances between at-fault collisions for Alpamayo 2 Edge(2B) and Qwen-Drive-1.0(4B). NVIDIA described the difference as about 40x.

It also presented minimum average displacement error from open-loop evaluation, which predicts future trajectories from recorded driving data. This metric measures predicted trajectory error, with lower values being better.

Table: Driving evaluation comparison of the two models

Conditions: NVIDIA's comparison of Alpamayo 2 Edge(2B) and Qwen-Drive-1.0(4B). Closed-loop and open-loop tests are separate evaluations, with the two models compared for each metric.

Units: km for distance between at-fault collisions; m for minimum average displacement error

Simulation comparisons and onboard latency
Evaluation methodMetricAlpamayo 2 Edge(2B)Qwen-Drive-1.0(4B)Preferred direction
AlpaSim closed-loopDistance between at-fault collisions (km)9.870.25Higher is better
Open-loopMinimum average displacement error (m)0.531.68Lower is better

Chart: Distance between at-fault collisions. Conditions: AlpaSim closed-loop evaluation in the table above. Higher is better; bar lengths are proportional to values. Unit: km

Alpamayo 2 Edge(2B)  ███████████████████▊  9.87
Qwen-Drive-1.0(4B)   ▌                    0.25

Chart: Minimum average displacement error. Conditions: Open-loop evaluation in the table above. Lower is better; bar lengths are proportional to values. It does not share an axis with the distance chart. Unit: m

Alpamayo 2 Edge(2B)  █████▎             0.53
Qwen-Drive-1.0(4B)   ████████████████▊  1.68

Onboard performance was measured in a separate configuration. NVIDIA reports that the model optimized with TensorRT 11.3.1.9 on DRIVE AGX Thor-X took 160~190ms from image input to trajectory output, depending on reasoning volume. The measurements used DRIVE OS 7.2.7.0 and CUDA 13.4.

Embedl co-founder and CEO Hans Salomonsson said the team achieved 10 driving plans per second on AGX Thor within 48 hours.

3. Vehicle optimization is a separate deployment step

Model weights downloaded from Hugging Face are stored in the BF16 numerical precision format by default and can run as a PyTorch model on supported NVIDIA GPUs. Real-time use in a vehicle requires additional optimization.

The deployment recipe starts with preparing a DFlash2 draft model and FP8 calibration. This uses an auxiliary model to accelerate reasoning generation and calibrates for lower-precision computation.

It then exports an ONNX graph, a model representation converted for deployment tools, builds a TensorRT execution engine, and runs the deployment program.

The deployment recipe also compares output quality before and after optimization using the same inputs and identically initialized action noise.

The original command for running the deployment bundle is as follows.

python -m alpamayo2edge_edgellm.runtime.run \
  --engines "$WORK/engines" \
  --model "$MODEL" \
  --reference "$INPUTS" \
  --dflash2 \
  --rolling \
  --warmup 1 \
  --repeat 5 \
  --output "$WORK/results.json"

4. Linking reasoning quality to training data and rewards

NVIDIA's AlpaJudge is an evaluation and reward model aligned with human judgment that assesses explanation quality separately from trajectory error. Its reference-based mode compares questions, reference answers, and candidate answers. Its reference-free mode uses front wide-angle and telephoto frames, past and future action context, and candidate reasoning to produce per-criterion and overall scores.

These scores also feed into data selection and post-training. NVIDIA reports that score-based filtering increased the share of mid-scoring samples useful for training from 27% to 81%.

The released reinforcement learning recipe evaluates reasoning and trajectories, combining reasoning scores with trajectory error and ride comfort metrics into one reward. NVIDIA reports reasoning quality gains of 10.2% by evaluator scoring and 11.4% by human evaluation over the pre-reinforcement-learning model based on Alpamayo 2 Super.

Reducing reasoning and obtaining trajectories quickly onboard adds precision calibration, execution engine building, and output quality comparisons to developers' work. Optimization costs sit between downloading the model and running it in real time in a vehicle.

AlpaJudge scores indicate whether explanations meet evaluation criteria, so they should be examined alongside driving metrics such as collisions and road departures. High scores may mark cases the model already explains well, leaving little to learn. Low scores can include rare failures as well as mislabeled data, so removing them all may discard needed training examples. Mid-scoring cases often offer useful material for further training, making them valuable to select.

The key is to focus reasoning on moments that need it and connect vehicle deployment, evaluation, and retraining in one development workflow.