Nemotron 3.5 Super VL vs Nemotron 3.5 Super VL 120B: One Model, Five Files, Three Different Behaviours

This comparison exists because a search box made it. NVIDIA Nemotron 3.5 Super VL and NVIDIA Nemotron 3.5 Super VL 120B are not two models. They are one checkpoint written down two ways, and no benchmark separates them because there is nothing to separate: the 120B is the parameter count of the Super VL, and the shorter string is what the marketing page calls the file whose full repository name is nvidia/NVIDIA-Nemotron-3.5-Super-VL-120B-A12B-BF16. The naming confusion around this checkpoint is the kind of thing that ends up in a postmortem, and the recorded incidents are catalogued in the OrcaRouter AI Incident Archive where each entry carries its own sources, severity, confidence grade and disputed flag.

So a head-to-head is the wrong article. The useful version is the one that follows from the same confusion: if both names point at the same model, why does downloading "Nemotron 3.5 Super VL" give you five different repositories, three different download sizes and two different architectures, and which one are you actually getting?

The naming, untangled

NVIDIA uses three overlapping labels for one release, and they nest rather than conflict.

• Nemotron 3.5 Super VL — the product name. What the blog post, the panel and every news article calls it.

• Nemotron 3.5 Super VL 120B — the same name with the parameter count appended. Common in comparison tables and catalogue listings, including the ones that generated this page.

• NVIDIA-Nemotron-3.5-Super-VL-120B-A12B — the repository stem, which adds the active-parameter count. Every downloadable artefact hangs off this: BF16, NVFP4, Base, and an NVFP4 LiLiCorr drafter.

None of those three is a different model. The genuinely different things live one level down, in the precision and post-training suffixes, and that is where a real decision sits.

Five files, and what each one actually is

All five appeared within about four days of each other, and their creation timestamps are the most reliable release evidence available — more reliable than the announcement date, which came after all of them.

• ...-120B-A12B-Base-BF16 — created 2026-10-12T15:31:49Z. The pre-post-training checkpoint. No instruction tuning, no tool-use training, no reasoning mode. This is the one to start from if you intend to do your own post-training, and it is useless to you if you do not.

• ...-120B-A12B-BF16 — created 15:32:06Z, seventeen seconds later. The finished instruct model, full precision, roughly 249 GB across 63 shards. NVIDIA's serving recipe is tensor parallelism 4 on H100s, or 2 on GB200.

• ...-120B-A12B-NVFP4 — created 15:32:30Z. The same post-trained weights, quantised to 4-bit during training rather than after it, about 75 GB. This is the file most people will actually serve, and it runs on one H200, two H100s, one GB200, or a single DGX Spark.

• ...-120B-A12B-NVFP4-LiLiCorr — created 2026-10-11T20:20:59Z, a day before the others and before any announcement existed. Not a model in the ordinary sense: a speculative-decoding drafter, which NVIDIA's blog later named the recommended one for low-latency inference on DGX Spark.

• The GGUF and community quantisations — derived, not published by NVIDIA, and outside the scope of anything the vendor reports.

If you came here looking for "which of these two is better", the answer is that two of the five are not alternatives to each other at all: the base checkpoint and the instruct checkpoint are different stages of the same training run, and the drafter is not a model you would ever call directly.

What changes between the full-precision and 4-bit builds

This is the only comparison in the naming tangle with real consequences, and it is also the one with the least independent evidence.

• Disk and memory — 248.94 GB for BF16, 75.06 GB for NVFP4. A 174 GB difference, which is the difference between four H100s and two.

• Numerics — NVFP4 runs W4A4 on Blackwell and W4A16 on older hardware. The quantisation is applied during training with distillation, which NVIDIA says closes the accuracy gap that post-hoc quantisation opens.

• Accuracy claim — NVIDIA reports 99.62% median accuracy recovery against the BF16 reference. That is a vendor figure on a vendor harness, and it is the single most load-bearing unverified number in the whole release.

• Independent evaluation — none. Artificial Analysis scores the model at 26.49 on its Intelligence Index, non-estimated, but does not publish a separate row for the NVFP4 build. Every third-party number you have seen for this model is a full-precision or provider-default measurement.

• Performance overhead — NVIDIA states there is none, because the quantisation happens during training rather than as a runtime step.

Read the 99.62% carefully before planning around it. "Median accuracy recovery" across an unnamed set of evaluations is not the same claim as "loses 0.38% of capability." A median can sit at 99.62% while individual benchmarks move by several points in either direction, and without the per-benchmark spread the number tells you less than it appears to. If your workload is sensitive to a specific capability — long-document OCR, chart extraction, video grounding — the only sound approach is to run both builds on your own data, because NVIDIA has not published the row you would need.

The base checkpoint is the one nobody benchmarks

Of the five files, the base build is the least discussed and the most interesting if you have post-training plans. It carries the same 120B total and 12B active structure, the same hybrid backbone and the same vision encoder, and it stops before the six-stage post-training pipeline that produced the instruct model — the pipeline whose SFT and RL datasets NVIDIA also published, eleven of them, all within a 61-hour window in the same week.

What it does not carry is a usable benchmark table. Its card runs MMLU and MMLU-Pro; the post-trained card drops MMLU entirely in favour of MMLU-ProX and adds the agentic and harness-level suites. The two sets do not overlap enough to answer "how much did post-training add", which means the only way to price that question is to run both yourself. Open weights make that possible. They do not make it free.

Why the duplicate names exist at all

Three artefacts, three audiences, one release. The blog post needs a product name short enough for a headline: Nemotron 3.5 Super VL. A catalogue or comparison table needs something sortable and unambiguous across a family that also contains Bolt 74B, Bolt E4B and Lightning 30B: appending 120B does that. The Hub needs a repository name that encodes precision and active parameters so that a script can pick a file without a human reading a description.

The cost of that layering is search. Two strings that mean the same thing compete for the same query, and a reader who types one of them lands on a comparison page asking which is better. The useful answer to that query is the one above: they are the same file, here are the five things the name can actually refer to, and here is how to tell which one you have.

What this means if you are calling it rather than downloading it

Through an API the naming problem mostly disappears, because the provider has already picked a build for you — and that is exactly where the remaining ambiguity moves. The independent panel tracks seven servers for this checkpoint, and their published rates for the same weights run from $0.10 to $0.20 per million input tokens and $0.40 to $0.50 per million output. Two of those listings are explicitly NVFP4 builds; the rest do not say, and a rate without a precision is a rate you cannot compare to another rate.

That is the practical version of the question this page started with. The model name resolves to one architecture and five files; the price does not tell you which file you are paying for. Asking a provider which build they serve, and whether their throughput figure was measured on BF16 or FP4, is a more useful question than any head-to-head between two spellings of the same checkpoint.

On our side the honest note is short: this checkpoint is not on the OrcaRouter catalogue. The model list runs to a little over 200 IDs and carries no NVIDIA entry today, so nothing here is an offer to serve it. What the platform does offer that is relevant to a name this ambiguous is a routing layer that keeps the model string in one place: when a variant does land, the call site does not change, traffic can be split between two providers of the same checkpoint to compare them on your own workload, and automatic failover covers the case where one of them degrades. Provider list price passes through at 0% markup, which matters here specifically because the spread on this model is 2x and you would rather see it than have it absorbed into a margin.

The short answer, for the reader who searched the long name

Nemotron 3.5 Super VL and Nemotron 3.5 Super VL 120B are the same model, released as weights on 12 October 2026 and announced on 15 October 2026, with 120 billion total parameters, 12 billion active, a 1M-token context, text, image and video input, and an OpenMDW-1.1 licence. If you are choosing between things, the choice is not between those two names. It is between BF16 and NVFP4, between the base checkpoint and the instruct one, and between the servers whose prices and precisions are not stated in the same units. Those are three real decisions. The name is not one of them.