Nemotron 3.5 Super on Ollama: a 120B Vision Model You Could Run Before NVIDIA Announced It

For about twenty hours, the local path to NVIDIA Nemotron 3.5 Super existed before the announcement that it existed. Ollama published the checkpoint to its library on 14 October 2026 in release v0.40.5, pulling in a llama.cpp update that added Nemotron 3.5 support and pushing nine tags of a 120-billion-parameter vision-language model — ollama run nemotron-3.5-super and you are running it. NVIDIA's own newsroom post for the same weights, published under the fuller name NVIDIA Nemotron 3.5 Super VL, went live the following afternoon, 15 October, at 15:00 UTC. The weights themselves had been sitting on Hugging Face since 12 October, in a repository named NVIDIA-Nemotron-3.5-Super-VL-120B-A12B-BF16, where the model card's own release-date field already read 10/15/2026.

None of that is a scandal. It is the normal shape of an open-weight release now: the artifact lands, the frameworks race to support it, and the marketing catches up. But it changes what the Ollama listing is worth reading for. What arrived on 14 October is not a product announcement with a runtime attached — it is a runtime with a product attached, and the two documents disagree about several things that matter if you are about to spend 90 GB of disk on it.

What v0.40.5 actually shipped

The Ollama release note is unusually specific, which is convenient. It describes Nemotron 3.5 Super as a vision-language model for coding, reasoning, tool use and document understanding, built on a hybrid Mamba-2/Transformer mixture-of-experts backbone with 12B active parameters per token out of 120B total, paired with a C-RADIO vision encoder. It advertises tool calling, an on/off thinking mode, and context up to 1M tokens. The two lines that matter most for anyone already running Ollama are buried lower: Updated llama.cpp (adding Nemotron 3.5 support) and MLX.

That single line is the whole reason the pull works. Ollama routes this checkpoint through its llamacpp runner in GGUF format — the registry manifest says so explicitly — so "Ollama supports Nemotron 3.5 Super" and "llama.cpp supports Nemotron 3.5 Super" are the same sentence. If you are on any Ollama older than 0.40.5, you are not. The model's config blob carries "requires":"0.40.5", so the version gate is enforced rather than merely advised.

The same release note also names a sibling, Nemotron 3.5 Bolt, which distils Super down to 74B parameters with 9B active and, per the note, is tuned to fit a 24 GB NVIDIA GPU with speculative decoding via an included drafter. That one is a different pull and a different tier of hardware; keep it separate in your head, because the naming invites confusion.

The nine artifacts, and what each one actually weighs

The library page shows a size ladder. The registry manifest behind it shows real byte counts, and the two do not round the same way, so here are the numbers from the manifests themselves rather than the rounded badges:

• q4_K_M — 88,419,818,592 bytes, or 82.3 GiB (the library page prints 80GB–90GB). Tag names :latest, :120b, :120b-a12b and :120b-a12b-q4_K_M all resolve to this same layer, so four of the nine entries are one artifact wearing four names.

• q8_0 — 131,601,243,232 bytes, 122.6 GiB, printed as 133GB.

• bf16 — 247,403,355,232 bytes, 230.4 GiB, printed as 249GB. This is the full-precision checkpoint in GGUF clothing, and it is the only tag here that lives nowhere near consumer hardware.

• MLX nvfp4 — 79.56 GB total, the smallest of the set, and NVFP4 is the format NVIDIA's own card ships as a first-class checkpoint rather than an aftermarket quantisation.

• MLX mxfp8 — 129.60 GB total, the MLX counterpart at roughly q8_0's footprint.

• MLX bf16 — 248.92 GB total, marginally larger than the GGUF bf16 because MLX stores tensors differently.

• The projector — every tag, without exception, carries a 1,733,696,896-byte mmproj-bf16.gguf media layer. That is 1.61 GiB of vision encoder riding along on every download, including the smallest one. The image path is not optional and not a separate pull.

Three of the nine entries — the MLX ones — are tagged for Apple silicon rather than CUDA, and each is labelled simply "MLX" on the library page. If you are choosing a tag on a Mac, nvfp4 at 79.56 GB is the one that fits a 96 GB or 128 GB unified-memory machine with room to spare, and mxfp8 at 129.60 GB does not fit a 128 GB box at all once you account for KV cache.

The library page and the manifest disagree about context length

The GGUF tags advertise a 1M-token context window. The three MLX tags advertise none — the column reads "- context window" where the others read "1M". Either the MLX path has not been wired for the long-context configuration or the page simply was not filled in, but from the outside those are indistinguishable, and the honest position is that the long-context claim is verified for the GGUF tags and unverified for the MLX ones.

There is a second gap in the same direction. The config blob for the default tag declares "model_type":"123.6B" while every piece of human-facing naming says 120B. That is not a discrepancy in the weights; it is a discrepancy in how the parameter count is being rounded between the two systems, and it is worth knowing which number a given tool is quoting at you.

And a third, which is the one most likely to bite: the params blob ships {"draft_num_predict":3,"temperature":1,"top_p":0.95}. Those sampling values are the model card's recommended settings — for text. The card recommends a different pair for vision work, temperature 0.6 against top_p 0.95. So the Ollama default is tuned for the text half of a model Ollama is advertising as a vision model. If your first experience with it on charts or scanned pages is disappointing, that is the first knob to turn, before you conclude anything about the checkpoint.

The draft_num_predict: 3 field is worth one line of its own. It is a speculative-decoding parameter, and the manifest carries no separate draft-model layer — just the model GGUF and the projector. So whatever speculation the runtime is doing is riding the model's built-in multi-token-prediction head rather than the standalone LiLiCorr drafter NVIDIA's card mentions shipping alongside the BF16 and NVFP4 checkpoints. That is a reasonable engineering choice and it also means the Ollama path is not the exact configuration the vendor's throughput numbers describe.

What the config blob quietly tells you

Four fields in the manifest config are more informative than their size suggests.

• model_family: nemotron_h_moe — the family string is not simply nemotron. Anything in your stack that switches on model family to pick a chat template or a tokenizer will not match on a naive prefix.

• renderer: nemotron-3.5-super — a dedicated renderer, so the chat template is genuinely this model's and not an inherited default.

• parser: nemotron-3-nano — and here the parser is borrowed from the smaller Nano sibling. The thinking-mode and tool-call output format was evidently stable enough across the family that it did not need a new parser. It also means if you have already built tool-call handling for Nemotron 3 Nano, it will likely work unchanged here.

• file_type: Q4_K_M — the default tag is a 4-bit quantisation, and that is the configuration most people will judge this model by.

The licence layer is a 2,618-byte blob carrying the OpenMDW License Agreement version 1.1, which is the same licence the Hugging Face card names as openmdw-1.1. Permissive, commercial use permitted, and worth reading before you assume it is Apache-2.0 because the surrounding Ollama ecosystem mostly is.

Benchmarks: one set is the vendor's, the other is not

NVIDIA's own published table is extensive and entirely self-reported. On it, the model posts 89.52 on GPQA-Diamond, 31.79 on Humanity's Last Exam text-only, 76.91 on MMLU-ProX, 88.22 on LiveCodeBench v6, 71.10 on SWE-bench Verified, 67.72 on SWE-bench Multilingual, 51.78 on SWE-bench Pro, 66.70 on Terminal-Bench 2.1, 70.86 on IFBench, 62.82 on MMLongBench-Doc, 78.16 on MathVision and 68.12 on OCRBench v2 English against 59.15 Chinese. The agentic rows are strong: 69.24 retail, 76.50 airline and 73.19 telecom on tau2-bench. The company also claims that on the Artificial Analysis Intelligence Index leaderboard the model achieves up to 5x faster throughput than others in its class, and that running it on NVIDIA Dynamo lets organisations serve up to 8x more users at 85% lower latency. Those are vendor figures, produced by the vendor, on the vendor's infrastructure — treat them as a specification, not an audit.

The independent picture is thinner but more useful, precisely because it is thinner. Artificial Analysis currently places this checkpoint at an Intelligence Index of 26, which it describes as well above the median of 8 for open-weight models of similar size — a real gap, and a meaningful one if you have been assuming a 120B open model from a hardware vendor lands somewhere near the middle of the field. The same page records 170M output tokens consumed running the Index against a median of 100M, which it reads as "somewhat verbose": this is a reasoning model with an extended thinking mode, and verbosity is a cost line, not a footnote. It confirms the 1.0M context, the 120B total with 12B active, image input with text output, and the OpenMDW-1.1 licence.

The one thing that page cannot tell you is what it costs per token, because there is no hosted price to quote. Artificial Analysis's own answer to whether the model is available via API is that it is an open-weights model that can be self-hosted. That is the whole economic story in one sentence: your marginal cost is electricity and a GPU hour, and your fixed cost is the download.

What it takes to actually run it

The model card recommends four H100s or two GB200s for the released checkpoint, with a vLLM recipe specifying tensor parallelism of 4 and a speculative config of method mtp. That is the datacentre answer and it is aimed at BF16. The interesting question for anyone reading an Ollama listing is the other end of the ladder.

At q4_K_M, 82.3 GiB of weights plus 1.61 GiB of projector puts the model inside a single 96 GB card or a 128 GB unified-memory Mac, with KV cache headroom that shrinks fast as you raise the context. At the advertised 1M tokens the cache is not going to fit alongside the weights on that class of hardware, whatever the badge says — long context on a single machine means trading concurrency, not unlocking it for free. Plan for a working context well below the ceiling and treat the 1M figure as the architecture's limit rather than your deployment's.

The MLX nvfp4 tag at 79.56 GB is the pragmatic Apple-silicon choice, and it is also the format the vendor ships natively, which makes it the least likely of the small tags to surprise you on quality.

Where this fits if you are routing rather than self-hosting

NVIDIA Nemotron 3.5 Super is available through the vendor's own build and distribution channels and through the Ollama pull described above. It is not on OrcaRouter — we route a bit over 200 models and this is not one of them — so if you specifically need this checkpoint, the local pull is your route and nothing in this article is a suggestion that you can call it on our key.

What the platform is genuinely for here is the decision around it. Evaluating a model like this one has a fixed cost that no benchmark table removes: a 90 GB download, an evening of configuration, and a set of your own prompts before you know anything. The cheaper first move is to run your actual workload against the hosted models you can already reach — one API across 200+ models, with provider list price passed through at no per-token markup, so a vendor cutting prices is live on our side the same day — and let that tell you whether the workload is one a 120B reasoning model improves at all. Then spend the download on the cases that survived.

And if you do put a newly released open model into a production path before you trust it, the automatic failover matters more than the price. A model that shipped on 14 October has had two days of the world's attention; routing it behind a fallback is how you get its upside without betting the request path on it.

The honest summary of what is and is not confirmed

Confirmed, from the registry and the release notes directly: the tags, their digests, their byte counts, the 0.40.5 minimum version, the GGUF format through the llamacpp runner, the shared vision projector, the model family string, the renderer, the inherited Nano parser and the OpenMDW-1.1 licence. Confirmed from NVIDIA's own newsroom and model card: the architecture, the parameter split, the licence, the recommended sampling settings, the training scale — roughly 26 trillion tokens across pretraining and continued pretraining, then post-training on about 3.8 million samples with reinforcement learning across dozens of environments — and the language coverage of English, Spanish, French, German, Italian and Japanese.

Not confirmed: every benchmark number, which is vendor-reported, with Artificial Analysis's Index of 26 and 170M-token verbosity read the only independent measurements in this piece. Not confirmed: that the MLX tags support the advertised context length, since the library page does not claim it for them. Not confirmed: that the vision path is tuned out of the box, because the shipped sampling defaults are the text ones. And not confirmed: how the 4-bit quantisation moves the published scores, which is the number most readers of an Ollama listing actually care about and the one nobody has published.

If you have a 96 GB card, a reason to want an open vision-language model with a genuine 120B backbone, and no objection to a first-week dependency, this is the strongest thing in its weight class to appear this month and the pull is trivial. If you need the exact configuration NVIDIA benchmarked, or you need vision to work on the first try, or you cannot afford to spend an evening discovering which of those two documents is authoritative — wait for the quantisation evals and the community reports. The weights are four days old and the runtime support is two.