alpamayo-2-super-article-svg-preview

HFVwr/alpamayo-2-super-article-svg-preview

alpamayo-2-super-article-svg-preview is a machine learning model from HFVwr. Use it for the machine learning task on the model card, and read the license before you ship it in a product.

Alpamayo 2 Super quadruples its reasoning backbone to 32B and keeps the action expert at 2.3B. That ratio is the most interesting number in the release.

Downloads · 30 days

Access

Public

Updated Aug 6, 2026

Repo size

6.1 MB

Likes

Public

Hugging Face

Repo makeup

Click a slice to open those files.

.gif6.1 MB · 78%

At a glance

Access: Public
Created: Aug 6, 2026
Updated: Aug 6, 2026
SHA: d5d4a0fa

Model card

From the Hugging Face model README

Alpamayo 2 Super: The expert that didn't grow

Alpamayo 2 Super quadruples its reasoning backbone to 32B and keeps the action expert at 2.3B. That ratio is the most interesting number in the release.

By Jonna Matthiesen, Devdatt Dubashi, and Hannes von Essen · Embedl · August 2026

This is the Hugging Face edition of our original interactive hfviewer article. The hfviewer version opens with a synchronized architecture diff between Alpamayo 1.5 and Alpamayo 2 Super. You can expand changed blocks, inspect the precise dimensional deltas, and jump from architecture mentions in the article directly to the relevant nodes.

The level-zero unified architecture diff from the original hfviewer article. The pointer reveals three representative groups of changes. Click the figure to open the fully interactive comparison.

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 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.

Figure 1. Alpamayo2-Super system overview. A Qwen3-VL-32B vision-language backbone (64 layers) consumes multi-camera video, ego-motion history, and a text prompt, and produces the language-space outputs: causal reasoning, VQA responses, 2D grounding, meta-actions, and auto-labels. A 2.3B flow-matching action expert attends to the backbone's KV cache and decodes the driving trajectory, so trajectory generation reuses the backbone's scene encoding rather than re-encoding the inputs. A coarse discrete-token trajectory is also available from the backbone alone. Layout after the overview diagram in NVlabs/alpamayo2.

The backbone change is visible directly in the interactive hfviewer comparison at the top of the original 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 Alpamayo 1.5 model uses the same block at ×36, hidden 4096. Each 2 Super layer has grouped-query, QK-normalized attention with 64 query heads over 8 KV heads, and the model has 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 4,000-token trajectory vocabulary, which begins in the base vocabulary'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%

Figure 2. Alpamayo-1.5-10B and Alpamayo2-Super architecture comparison. Both generations drawn on the same scale: width ∝ hidden size, height ∝ layer count. The backbone quadruples; the expert follows it to 64 blocks but slims from 2048 to 1536 hidden, holding ~2.3B parameters. Note the dashed overhang on the right expert: its attention (16 × 128 = 2048) is now wider than the block itself. Click the figure to open the interactive diff.

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. On the Alpamayo 2 Super model page, this is a 1536 → 2048 q_proj projection where the backbone's equivalent maps 5120 → 8192, and it 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 released Alpamayo 2 Super model, 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.

Figure 3. Flow matching in the unicycle action space. Six independently sampled trajectories evolve from noise onto the maneuver distribution over the expert's 10 Euler integration steps. Dashed line: ground-truth future trajectory. All samples are produced by real inference on a PhysicalAI-AV validation clip.

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: OpenPIE-0.6, an open implementation of π0.6, reflects an architecture in which the action expert grew substantially over π0.5, while GR00T N1.6 doubled its action-head DiT from 16 to 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 4×-larger reasoning backbone addresses, and the reported benchmarks are consistent with this. Figure 4 shows the pattern across a real sequence of inferences.

Figure 4. Reasoning and control across time. Thirty-three consecutive inferences on a PhysicalAI-AV validation clip (reference PyTorch implementation, bf16, 10 denoising steps, seed 42), advancing the query time in 0.25 s increments. The backbone's Chain-of-Causation output tracks the evolving scene, while the expert's trajectory remains a smooth, well-conditioned arc throughout.

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.

Figure 5. Reported benchmark comparison between Alpamayo generations. Alpamayo2-Super improves language-grounded driving QA (LingoQA, Lingo-Judge score, 74.2 → 79.2), closed-loop driving performance (AlpaSim score, 0.81 → 1.50), and open-loop trajectory accuracy (minADE₆ at 6.4 s, 1.11 m → 0.911 m). Note that the minADE₆ figures are computed on different evaluation sets (937 vs. 1,434 clips) and are therefore not directly comparable. Numbers as reported by NVIDIA.

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 and further reading

Original interactive article and architecture diff on hfviewer
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 whose configuration the released model matches field for field
π0 by Physical Intelligence, which introduced the parallel action-expert design
OpenPIE-0.6 on Hugging Face, an open implementation of π0.6
π0.6 model card, the source for the original action-expert comparison
nvidia/GR00T-N1.6-3B on Hugging Face, the model whose action-head DiT doubled
NVIDIA's Alpamayo Open Platform overview

Created: Aug 6, 2026
Updated: Aug 6, 2026