NVIDIA released Alpamayo 2 Super on August 4th: a 34B vision-language-action (VLA) model for L4 autonomous driving, with weights under the OpenMDW-1.1 license. We loaded it into hfviewer next to its predecessor, Alpamayo-1.5-10B, to see what a generation of progress looks like at the level of the architecture. A generational release invites the expectation of uniform scaling; this one departs from it. The vision-language backbone grows from 8B to 32B parameters, while the action expert that converts the backbone's understanding into a driving trajectory retains its predecessor's parameter count of 2.3B. This post examines that ratio and what it indicates about where the capability bottleneck in autonomous driving and deployment currently lies.
A note on scope: Alpamayo 2 Super is a multi-task model. Besides trajectory generation it performs visual question answering, 2D grounding, meta-action prediction, and structured auto-labeling, and all of those run through the backbone alone. This post concentrates on the trajectory-generation path, the only task that exercises the action expert.
One recipe, two generations
Both Alpamayos follow the recipe introduced by π0 and since adopted across much of the VLA field: a VLM backbone reads six-camera video, ego-motion history, and a language prompt; a small diffusion action expert runs beside it, layer for layer, attending into the backbone's KV cache with non-causal attention, and denoises a 6.4-second trajectory. Reasoning and language live in the backbone. Driving lives in the expert.
In inference terms, one prediction is a prefill phase, where the backbone processes the cameras, the motion history, and the prompt once, followed by a denoise phase, where the small expert runs repeatedly against the backbone's cached keys and values. The distinction matters because it restates the scaling decision in inference terms: this generation makes the prefill four times larger and leaves the denoise untouched. Figure 1 summarizes the resulting task routing.
The backbone change is visible directly in the hfviewer comparison at the top of this article, while Figure 2 makes the difference in scale explicit. The 2 Super backbone is identifiable as an unmodified Qwen3-VL-32B: a stack of Qwen3VLTextDecoderLayer ×64 at hidden size 5120 (the 1.5 graph shows the same block at ×36, hidden 4096), each with grouped-query, QK-normalized attention (64 query heads over 8 KV heads), and a 27-block vision tower. DeepStack taps merge features from vision blocks 8, 16, and 24 into the language stream. The Alpamayo-specific parts sit at the edges of the graph: the embed_tokens matrix is widened to 155,776 rows (3,840 extra slots accommodating the 4000-token trajectory vocabulary, which begins in the base vocab's unused tail), and the input pipeline gains the trajectory tokenizers described below. The backbone is, in effect, a standard 32B VLM at four times the previous scale.
The two generations, drawn to scale
| Alpamayo-1.5-10B | Alpamayo2-Super | |
|---|---|---|
| Backbone | 36 layers × 4096 (8B) | 64 layers × 5120 (32B) |
| Action expert | 36 blocks × 2048 (2.3B) | 64 blocks × 1536 (2.3B) |
| Expert attention | 16 × 128 = 2048 = hidden | 16 × 128 = 2048 ≠ hidden |
| Expert / backbone width | 50% | 30% |
Because the expert shadows the backbone block for block, its depth is not a free parameter: when the backbone moved from 36 to 64 layers, the expert followed by construction. Width is the free parameter, and it was reduced, from 2048 to 1536, which holds the expert at approximately 2.3B despite the added depth. Scaling the expert with the backbone was an available option; instead, the entire parameter growth of the generation went to the backbone. We read this as a deliberate statement about where the returns are.
The width reduction has a visible consequence in the configuration. In 1.5 the expert's attention dimension matched its hidden size: 16 heads × 128 = 2048. In 2 Super the hidden width is 1536, but the query projection remains 2048 wide. It has 16 query heads × 128, grouped over 8 KV heads × 128. The expert is therefore narrower than its own query projection: reduced in its MLPs, full-width where it interfaces with the backbone's cache. It is visible on the expert's q_proj node in the hfviewer graph, a 1536 → 2048 projection where the backbone's equivalent maps 5120 → 8192, and appears as the dashed overhang in Figure 2.
What the action expert computes
The decision to keep the expert small is easier to interpret in light of what it computes. The expert does not generate the trajectory as 64 XY positions directly. It generates the driving commands that produce the trajectory: one acceleration and one curvature value per 0.1-second step, clipped to hard bounds of ±9.8 m/s² and ±0.33 1/m. A minimal vehicle model (the unicycle: position, heading, speed) then integrates these commands step by step, and the positions it traces out are the 64 waypoints. Denoising therefore happens in command space; XY positions are only ever computed from commands. In the hfviewer graph, the noisy command samples enter the expert through PerWaypointActionInProjV2 (a FourierEncoderV2 followed by two MLPEncoder blocks). Ego-motion history is discretized by DeltaTrajectoryTokenizer into a 1,000-token history vocabulary, while future trajectories use the separate DiscreteTrajectoryTokenizer with 3,000 bins. Together they form the 4,000-token trajectory vocabulary mapped into the widened embedding matrix above. The bounds are physical constants, not learned quantities, and together with the integration they guarantee that every sample is a path a car could physically follow: the action space cannot express discontinuous paths, turns tighter than a 3-meter radius, or accelerations beyond ±1g. Figure 3 animates the denoising process in this action space.
The generative mechanism is flow matching with Euler integration, 10 steps in the default profile. The expert's size also carries a different cost than the backbone's: the backbone is prefilled once per planning cycle, while the expert runs a full forward pass in each of the 10 denoise steps. An expert that scaled with the backbone would have made every trajectory sample roughly four times more expensive.
Interpreting the asymmetry
We found the allocation surprising at first: the trajectory is the safety-critical output, which suggests the planner should receive the additional capacity. Examining what the expert computes, and what it learns from, changed our assessment. The choice also runs counter to the prevailing trend in the wider VLA field, where the action side has been growing between generations: π0.6 nearly tripled π0.5's action expert (300M → 860M) on a Gemma 3 4B backbone, and GR00T N1.6 doubled its action-head DiT (16 → 32 layers). NVIDIA held theirs constant.
Our reading is that the binding constraint in this class of system is scene understanding, not control. Control under a unicycle model with bounded acceleration and curvature is a low-dimensional, well-conditioned problem, and a 2.3B conditional denoiser appears sufficient for it. The difficult residual in long-tail driving is semantic: telling a plastic bag from a rock, or reading whether a pedestrian is about to step into the road. That is what a 4x-larger reasoning backbone addresses, and the reported benchmarks are consistent with this. Figure 4 shows the pattern across a real sequence of inferences.
The benchmark deltas separate along the same line (Figure 5). LingoQA improves from 74.2 to 79.2, and the closed-loop AlpaSim score rises from 0.81 ± 0.01 to 1.50 ± 0.13 on the same 910 scenarios (higher is better; the cards do not document the score's scale, so we report the values without interpreting the ratio). Both benchmarks are dominated by scene understanding and decision quality. Open-loop trajectory error, the metric closest to raw control, is evaluated on different sample sets in the two cards (937 versus 1,434), so it does not support a cross-generation comparison; Figure 5 includes it for completeness only. On the two comparable benchmarks, the pattern is consistent with the planner not being the limiting component; its conditioning was.
One caveat applies to this whole reading: the two generations differ in training data (roughly 80,000 → 115,000 hours), camera count (4 → 6), and recipe as well as backbone scale, so the benchmark deltas are an uncontrolled comparison and cannot be attributed to any single change.
Beyond the bottleneck argument, two further considerations point the same way. First, returns on parameters are task-shaped: the backbone serves every task in the model while the expert serves exactly one (Figure 1), so a parameter added to the backbone pays out across the entire task surface. Second, the action supervision may not support a larger expert. The backbone benefits from web-scale vision-language pretraining; the expert learns from roughly 115,000 hours of driving trajectories in a bounded, low-dimensional control space whose distribution is dominated by lane keeping. There is likely not enough information in that signal to justify more capacity, and a larger expert would be expected to saturate or overfit rather than generalize. This also reconciles the field trend cited above: manipulation experts such as π0.6's decode high-dimensional joint-space actions across many embodiments, where added action capacity has room to pay off, while a unicycle-constrained driving expert emits two bounded controls per step. The returns on action-side capacity are domain-dependent.
A more speculative possibility is that the small expert acts as a forcing function. Because the expert reads the backbone's KV cache, a sufficiently large expert could in principle learn visual shortcuts and bypass the backbone's reasoning; a deliberately small one keeps the semantic burden, and with it the Chain-of-Causation traces, load-bearing. No published ablation supports or refutes this, but it would align the capacity allocation with the model's stated goals of steerability and interpretable reasoning.
Deployment implications
What we like to look at most in every new model release in the sub-50B range is deployment, and here the proportions have a practical corollary. Alpamayo 1.5 ran on a 24GB GPU; 2 Super's measured profile requires ~72GB on an H100. That footprint is not deployable in a vehicle, and NVIDIA's model card is explicit about the intended placement: the model "can be integrated into autonomous driving software in the cloud for advanced end-to-end perception, reasoning, and motion planning" (emphasis ours). To become relevant on automotive edge hardware, latency and power must fit a closed-loop planning budget. That points towards a smaller distilled backbone, lower precision, and hardware-aware optimization. Consistent with that, NVIDIA positions the model largely as a teacher, run offline in the data center to auto-label fleet data and supervise compact student policies.
The asymmetry of keeping the expert's size nearly unchanged while quadrupling the backbone may also be deliberate from a distillation standpoint. When a teacher of this design is compressed into a student, the component that is adapted or pruned is typically the backbone; the expert, already small, carries over. How cheaply it carries over depends on the coupling described above: because the expert shadows the backbone layer for layer and is sized to its KV geometry, it survives width pruning of the backbone unchanged (hidden size, FFN, and query heads can shrink while layer count and KV layout are preserved, the mainstream structured-pruning recipe), whereas depth pruning breaks the layer-for-layer interface and forces expert retraining. The two generations themselves demonstrate the relevant invariance: the expert design transferred across an 8B → 32B backbone swap, and the same invariance is what a down-scaled student would exploit. A small expert whose interface survives the standard compression path is exactly what one would choose if the model's primary role is to be distilled.
Closing remark
- Backbone: 8B → 32B, an unmodified Qwen3-VL-32B inherited through Cosmos 3 Super
- Action expert: 2.3B → 2.3B, deeper and narrower, its attention pinned to the backbone's KV geometry
- Understanding benchmarks moved most: AlpaSim 0.81 → 1.50, LingoQA 74.2 → 79.2
- Positioned for the cloud by NVIDIA's own model card, and shaped like a teacher for distillation
Driving foundation models are growing faster than automotive compute, and we do not expect that to reverse. NVIDIA's capacity allocation reads as an acknowledgment of the same trend: every new parameter went to the half that stays in the data center, and none to the half that would have to run in the vehicle. Distilling that student half onto automotive silicon is the problem we spend most of our time on, and a topic for a separate post. The next generation will show whether the ratio holds. We expect the expert to stay small.
Sources & further reading
- Alpamayo2-Super in hfviewer and Alpamayo-1.5-10B in hfviewer, the interactive graphs behind every figure in this post
- nvidia/Alpamayo2-Super and nvidia/Alpamayo-1.5-10B model cards on Hugging Face
- NVlabs/alpamayo2, the inference code and the overview diagram Figure 1 is drawn after
- Qwen/Qwen3-VL-32B-Instruct, the backbone the backbone configuration matches field for field
- π0 by Physical Intelligence, which introduced the parallel action-expert design
- π0.6 model card (Physical Intelligence), the source for the 860M action-expert figure
- GR00T N1.6 (NVIDIA GEAR), the source for the doubled action-head DiT
- NVIDIA's Alpamayo Open Platform overview