NVIDIA Nemotron 3.5 Super VL: The 120B Open Model That Shipped Before Its Own Blog Post

The weights for N​VIDIA N​emotron 3.5 Super VL were on Hugging Face three days before N​VIDIA wrote about them. The full-precision repo, nvidia/N​VIDIA-N​emotron-3.5-Super-VL-120B-A12B-BF16, was created at 2026-10-12T15:32:06Z. Its quantised sibling, nvidia/N​VIDIA-N​emotron-3.5-Super-VL-120B-A12B-NVFP4, went up 24 seconds later. N​VIDIA's own developer blog post explaining the model is dated October 15, 2026 — the same day its model cards say "Hugging Face - 10/15/2026". So the public artefacts and the public announcement arrived on different days, and the gap is small enough that neither date is wrong and both are worth knowing.

What follows is what the repo and N​VIDIA's post actually say about this 120B-parameter, 12B-active vision-language model: the architecture, the deployment maths, where its own published table shows it losing, and the licensing catch that the blog post never mentions.

What N​emotron 3.5 Super VL actually is

N​VIDIA describes it in its own post as "an open, customizable multimodal model" built for specialized agent workflows — reasoning, instruction following and tool use, combined with text, image, document and video understanding in one set of weights. The point of that combination, as N​VIDIA frames it, is that teams "can handle text and visual tasks without deploying separate text and vision-language models or passing task context between them."

The architecture, per the model card:

• Shape — 120B total parameters, 12B active per token. A mixture-of-experts model with 512 routed experts per MoE layer.

• Backbone — interleaved Mamba-2, attention and MoE layers, a N​emotron hybrid design carried over from the N​emotron 3 line.

• Vision — a C-RADIO vision encoder plus a vision-language connector. The transformers architecture string is NemotronH_Omni_Reasoning_V3, model type nemotron_h_omni.

• Context — up to 1M tokens, with the prompt, images, conversation history, tool results and generated response all sharing that window.

• Speculative decoding — a native Multi-Token Prediction head, so no separate drafter download is needed for the vLLM and SGLang recipes N​VIDIA publishes.

• Reasoning mode — toggleable through the chat template via enable_thinking, with a medium_effort setting in between. Reasoning tokens and the answer share the same max_tokens budget, which the card flags explicitly because it is the usual cause of truncated agent output.

• Inputs — text, RGB images (JPEG, PNG) and MP4 video up to two minutes. The recommended video sampling in the vLLM recipe is 2 FPS and 256 frames with a pruning rate of 0.5; for 1080p the card says drop to 1 FPS and 128 frames.

• Languages — English, Spanish, French, German, Italian and Japanese in the card frontmatter. N​VIDIA also says the training corpus covers English plus 19 other spoken languages and 43 programming languages.

Two precision tiers, and the memory they buy

N​VIDIA shipped the model twice, and the memory jump between the two is the single most decision-relevant number in the release.

• BF16 — the full-precision reference. The repo holds 64 safetensors shards totalling roughly 231.8 GiB. N​VIDIA's own serving recipe is --tensor-parallel-size 4 on 4× H100, or TP2 on 2× GB200.

• NVFP4 — 4-bit weights and activations with quantization-aware distillation, which N​VIDIA says "closes the accuracy gap that quantization introduces." The same checkpoint runs on non-Blackwell hardware at 4-bit weights and 16-bit activations, and QAD also allows the KV cache to be stored in NVFP4 instead of FP8. Because the quantisation happens during training rather than after, N​VIDIA states it adds no inference overhead. The NVFP4 card lists deployment on 1× DGX Spark, 1× H200, 2× H100 or 1× GB200.

That last line is the practical one. A 120B model that fits on two H100s in FP4 instead of four in BF16 is a different purchasing conversation, and it is why the quantised repo is the one N​VIDIA points at for efficient serving. A third sibling, N​VIDIA-N​emotron-3.5-Super-VL-120B-A12B-NVFP4-LiLiCorr, appeared on Hugging Face a day before the main pair with no announcement attached; N​VIDIA's blog later explains LiLiCorr as an open speculative-decoding technique and names it "the recommended drafter for low-latency inference with N​emotron 3.5 Super VL" on DGX Spark. Its repo predates that explanation by four days, which is a fair illustration of how this release surfaced.

There is a legitimate question underneath that jump — what the NVFP4 tier gives up versus the BF16 reference — but N​VIDIA's own answer is a training-methodology claim, not a published side-by-side accuracy table for the two checkpoints. If the precision choice is what your decision turns on, that comparison is not in the repo.

Where its own benchmark table shows it losing

The model card carries a large vendor-run benchmark table — roughly 40 rows — covering reasoning, coding, agentic tasks, long context, multilingual and multimodal work. N​VIDIA is unusually forthcoming here: it names the comparisons, and several of them do not flatter the model. Its own numbers against the closest open competitor in the same shape, Qwen3.5-122B-A10B:

• GPQA-Diamond — N​emotron 3.5 Super VL 89.52 vs Qwen3.5-122B-A10B 86.7 (N​emotron ahead)

• HLE, text-only — 31.79 vs 24.2 (N​emotron ahead)

• MMLU-ProX — 76.91 vs 83.2 (Q​wen ahead by more than six points)

• CritPt — 10.86 vs 1.1 (N​emotron ahead by a wide margin)

• LiveCodeBench v6 — 88.22 vs 76.7 (N​emotron ahead on this harness)

• SWE-bench Verified — 71.10 vs 71.9 (a tie, within noise)

• SWE-bench Pro — 51.78 vs 44.9 (N​emotron ahead)

• tau2-bench retail — 69.24 vs 55.4 (N​emotron ahead)

• tau2-bench telecom — 73.19 vs 87.2 (Q​wen ahead by 14 points)

• AA-LCR v1.1 — 68.62 vs 75.1 (Q​wen ahead at long context)

• BabyVision — 29.60 vs 35.7 (Q​wen ahead)

• MathVision — 78.16 vs 83.3 (Q​wen ahead)

• OCRBench v2, English — 68.12 vs 68.3 (essentially level)

• OCRBench v2, Chinese — 59.15 vs 67.3 (Q​wen ahead by eight points)

• V* — 85.60 vs 91.1 (Q​wen ahead)

• IFBench — 70.86 vs 67.6 (N​emotron ahead)

• AA-Omniscience index — 4.03 vs -36.1 (both weak; N​emotron far less negative)

Three things are worth saying about this table rather than letting the wins speak for it.

First, every number in it — N​emotron's and every baseline's — is vendor-reported and collected through N​VIDIA's own harness. The card says so directly: "All evaluation results for N​emotron 3.5 Super and baselines were collected via NeMo Gym," with reproducibility notes published in the NeMo Gym repository. That is better disclosure than most labs manage, and it still is not an independent score. Read the columns as one lab's measurements of several models, not as a neutral leaderboard.

Second, N​VIDIA itself lists the benchmarks that were not onboarded into its open tooling — BabyVision, CharXiv-RQ, MathVision, MMLongBench-Doc, OCR-Reasoning, OCRBench-v2, V* and Video-MME-v2 — and says those used official implementations or "an internal scaffolding that we plan to open source in the future." Every multimodal row in the table carries that caveat.

Third, the pattern in the losses is coherent rather than random. The gaps are in Chinese-language OCR, long-context reasoning, and visual maths and chart reading. The wins cluster in tool-calling benchmarks and short-horizon agentic tasks — CritPt, tau2-bench retail and airline, APEX, Terminal-Bench 2.1 at 66.70 against Q​wen's 48.70, SWE-bench Pro. For a model N​VIDIA positions as the executor in a multi-model agent stack, that is a defensible profile. If your workload is Chinese document parsing or very long analytical context, the same table is telling you something else.

Post-trained beats base, and N​VIDIA leads with that

The most concrete accuracy claim in N​VIDIA's blog post is not a benchmark score. It is a claim about customisation: that post-training a base N​emotron 3.5 Super VL can take a specialised workload past Claude Opus 5. N​VIDIA's example is medical insurance claims, where it cites a 44% gain from post-training.

Two things matter about how N​VIDIA reports this. The number is attributed to a claimed gain from post-training, not to a model-vs-model comparison on a public benchmark — which is a different and weaker kind of evidence. And N​VIDIA's own post is careful to say that these gains come with caveats: "the base model didn't top proprietary frontier models on its own" is the honest version of the sentence, and the framing is that the advantage of open weights is that a business can post-train on its own data and run the result on its own infrastructure.

The vendor side of the same story is thin. N​VIDIA names Scale AI, Ramp and AI21 as organisations that post-trained the model; Ramp is quoted expecting "up to 50% higher throughput and 10x lower latency" for receipt-to-JSON extraction, Scale AI a 40x inference-cost reduction and 5x latency improvement for vendor credit processing. Those are customer-stated expectations and outcomes, published by the vendor, with no independent measurement behind them. They may well hold. Nobody outside those companies has checked.

What N​VIDIA does publish that helps is the recipe surface: NeMo AutoModel for SFT and LoRA, NeMo RL and NeMo Gym for reinforcement learning and environment-based evaluation, NeMo Data Designer for multimodal data generation, plus 45 vision-language datasets and a set of agentic tool-use, finance-reasoning and instruction-following datasets on Hugging Face. A reproducibility tutorial for the published benchmarks lives in the NeMo Gym repository. The last part is genuinely useful — it means you can attempt to re-run N​VIDIA's own evaluations rather than trust the table.

The licence is not what the marketing implies

This is the detail worth reading the repo for rather than the blog post.

N​VIDIA's post calls the model "an open, customizable multimodal model" and refers to "the model's open weights." Both statements are accurate about the weights. Neither is a statement about the licence. The model card's frontmatter reads license: other, with license_name: openmdw-1.1, and the governing terms are the OpenMDW License Agreement version 1.1 at openmdw.ai/license/1-1/. The card states plainly that the model "is ready for commercial or non-commercial use" and N​VIDIA's own deployment language refers to running it in "supported local, data center, or cloud environments."

So: commercially usable, per N​VIDIA. But "open" here means OpenMDW-1.1, not Apache 2.0 and not MIT. If your organisation has a list of pre-approved open-source licences, that list is the thing to check before anything else — and the practical difference between "open weights" and a named licence is exactly the kind of gap that costs a release cycle to discover late. This is not a criticism of the model, and OpenMDW is not a restrictive licence. It is a reminder that the blog post's adjective is doing less work than the card's frontmatter.

Trying it without betting a production path on it

The published deployment recipes are explicitly single-machine, and that shapes how this gets evaluated. N​VIDIA's vLLM commands in both cards run at TP4 on 4× H100 or TP2 on 2× GB200 with --trust-remote-code — the model ships custom modeling code — and the SGLang recipe uses lmsysorg/sglang:v0.5.20 on two GB200s. For DGX Spark there is a dedicated LiLiCorr drafter checkpoint, and N​VIDIA recommends it in all Spark scenarios; the company claims up to 2.3x faster token generation than decoding without speculation. On 16 B200s with Dynamo, N​VIDIA cites serving up to 8x as many users with first-token latency down 85% at 50 tokens per second per user. Every one of those is a vendor-internal measurement.

That is a real evaluation cost for a model that is three days old, has no independent scoreboard, and whose multimodal rows come with an unopened-scaffolding caveat. The cheap way to look at it is not to stand up four H100s first.

The cheap way to look at a release this young is through a single gateway rather than a second hardware order. On OrcaRouter that means one key across 200-plus models at provider list price with 0% markup, no separate contract and no code change, and automatic failover across providers so a model you have not yet validated is not a single point of failure in a production path. This particular model is not on the catalogue yet — N​VIDIA shipped it days ago — so today it comes from the vendor's own API or the third-party platforms serving it. What that buys you is the comparison you can actually run now: put the candidates it claims to beat behind the same key, run your own tasks through them and against the models you already use, and let the routing layer make the swap a config change instead of a migration. Only then does the question of 4× H100 or 2× GB200 become a purchase decision rather than a guess.

The point is not that routing replaces a benchmark. It is that the decision you can make today is which tasks this model should own in your stack, and that decision does not require a hardware order.

What is not established yet

The honest list of unknowns is short but consequential, and it is the list to work from rather than the marketing:

• No independent evaluation exists. Every score quoted above is from N​VIDIA's NeMo Gym run. N​VIDIA's blog cites Artificial Analysis benchmark testing and an independent EXO Labs evaluation placing the model on a DGX Spark accuracy-versus-task-completion Pareto frontier, but the model card publishes no third-party score of its own, and there is no independent model page for it on the major aggregators at the time of writing.

• The BF16-versus-NVFP4 accuracy delta is unquantified. N​VIDIA's NVFP4 case is built on quantization-aware distillation closing the gap. That is a methodology claim, not a published accuracy comparison between the two checkpoints you can actually download.

• The benchmark campaign was partly run on N​VIDIA's own tooling. Eight multimodal benchmarks used official implementations or internal scaffolding that N​VIDIA says it "plan[s] to open source in the future" — which means those results are reproducible in principle, someday, and not today.

• Post-training gains are vendor- and customer-reported. The 44% claims gain and the Ramp and Scale AI figures are stated by N​VIDIA about its own customers. Nobody has measured them independently.

• Long-context behaviour at the full 1M window is untested outside the vendor. The architecture is built for it and N​VIDIA publishes deployment recipes for it. Whether the recall holds across a full million tokens on real documents is exactly the kind of thing that shows up in independent testing and does not show up in a vendor table.

Should you act on this now?

If you build document, chart, video or multi-tool agents and you have already budgeted for 120B-class inference, this is worth a real look this week: the NVFP4 tier puts it on two H100s, the licence permits commercial use, and the tool-calling rows in N​VIDIA's table are the strongest part of it. The 12B-active shape also means it is cheaper per token than its 120B total suggests — and, on the OrcaRouter side, a vendor price change on it is live the same day rather than after a billing cycle, because provider list price is passed through with no markup added.

If your workload leans on Chinese-language OCR, very long analytical context, or visual mathematics, N​VIDIA's own table gives you three specific reasons to wait for independent numbers rather than reason from the marketing.

Either way, the thing to watch is not another vendor post. It is the first independent eval that runs the NVFP4 checkpoint against the BF16 one on the same harness, and the first third-party score that was not collected through NeMo Gym. Until those exist, this is a well-documented, comfortably licensed, genuinely efficient open model whose strongest claims rest entirely on its maker's own measurements — and whose own maker was clear enough to publish the rows where it loses.

That gap between what a scoreboard measures and what a deployment meets is the reason the record matters: the documented AI failures and agent incidents around models in this class are collected in the OrcaRouter AI Incident Archive, where each entry carries its own sources, severity, confidence grade and disputed flag.