Nemotron 3.5 Super vs Claude Opus 5.5: 12 billion active parameters against a meter

Here is the number that decides this comparison, and it is not on either benchmark table. N​VIDIA N​emotron 3.5 Super — published by N​VIDIA under the fuller name N​VIDIA N​emotron 3.5 Super VL, and listed in the Ollama library as nemotron-3.5-super/ — activates about 12 billion of its 120 billion parameters for each token it generates. Claude Opus 5.5 publishes no parameter count at all and charges $4 per million input tokens and $20 per million output tokens. One of these models therefore has a marginal cost per token that is a function of electricity, and the other has a marginal cost per token that is a line item. Both numbers are real. Neither one tells you which model is cheaper to operate, because they are priced in different currencies.

The reason this is worth writing about now: the N​VIDIA weights went up on Hugging Face on 12 October 2026, quietly, in a repository named N​VIDIA-N​emotron-3.5-Super-VL-120B-A12B-BF16, three days before N​VIDIA's own newsroom post on 15 October made it official. Before that announcement the only public confirmation that N​emotron 3.5 Super existed as a runnable thing was a set of registry artefacts — and the fact that some of the specification on those artefacts does not match the specification on the vendor's card. What is knowable from the repository is a real amount: byte counts, quantisation formats, a version gate, a licence. What is not knowable from any repository is how it behaves against a hosted frontier model on your workload. That gap is what this page is about.

What the repository actually contains, before anything else

Three usable checkpoints landed within sixty seconds of each other on 12 October: the BF16 reference weights, a Base variant, and an NVFP4 build. A separate LiLiCorr drafter repository had gone up a day earlier, on 11 October, which is the earliest public footprint of the tier. The card describes a hybrid Mamba-2 and Transformer mixture of experts with 512 routed experts per MoE layer, a C-RADIO vision encoder and a vision-language connector, 120 billion total parameters with 12 billion active, context up to 1 million tokens, text, image and video in with text out, and native speculative decoding through a Multi-Token Prediction head. The licence is OpenMDW-1.1, which permits commercial use. Deployment is specified as four H100s or two GB200s for BF16.

The Ollama listing is the version most people will meet first, and it is where the specification starts to drift. It exposes nine tags. Four of them — :latest/, :120b/, :120b-a12b/ and :120b-a12b-q4_K_M/ — resolve to the same q4_K_M layer, so the default pull is a 4-bit quantisation and the "120b" name is not the file you get. Every tag, including the smallest, carries a 1.6 GiB vision projector, because the image path is not optional. The shipped default sampling is temperature 1.0 with top_p 0.95, which is the card's text recommendation — the card's vision setting is temperature 0.6. And the runtime gate is enforced: the config declares requires: 0.40.5/, so on an older Ollama the pull does not work at all.

None of that is a defect. It is the ordinary gap between a vendor's release notes and a community packaging of them, and it is the reason to read both documents rather than one.

The honest arithmetic of 12B active

Sparse activation is the whole commercial argument for this model, and it is worth being precise about what it does and does not buy.

What it buys: at inference, a token touches roughly a tenth of the network. Throughput on fixed hardware is therefore much closer to a 12B dense model than to a 120B one, and the memory footprint is the only place the full 120 billion parameters show up. N​VIDIA's own card claims up to 5x faster throughput than others in its class and, served on the vendor's Dynamo stack, up to 8x more concurrent users at 85% lower latency. Those are vendor figures produced on vendor hardware and they are a specification, not an audit — but the direction of the claim is the direct consequence of the architecture, which is at least a coherent story.

What it does not buy: the weights still have to be resident in full. The BF16 GGUF layer is 230.4 GiB. The q4_K_M default is 82.3 GiB plus the projector. Neither number shrinks because only 12 billion parameters fire per token. So the hardware floor is set by memory, while the throughput is set by activation — which is why a single 96 GB card can hold the 4-bit model comfortably and still produce tokens at a rate that would embarrass a dense model of the same total size, and also why the same card cannot hold the full-precision model at all.

Now put O​pus 5.5 next to that. A​nthropic's model is 1 million tokens of context, 128,000 tokens of maximum output, accepts text, image and file input, and lists at $4/$20 with cache reads at $0.20 per million. There is no download, no quantisation decision, no sampling default to fix, and no version to pin. It is also a well-audited model: it sits at the top of the third-party panel that most people use to compare these things, a long way above this N​emotron tier.

So the comparison is not "which is better". On measured general capability the hosted flagship wins, and pretending otherwise would be a disservice to a reader who is about to make a purchasing decision. The comparison is where the two cost curves cross.

Where the 120-billion-parameter open model earns its place

Three places, and they are specific.

• Volume with a fixed bill. A self-hosted checkpoint converts marginal cost into a fixed one. At low traffic the meter wins outright — four H100s cost more per month than most teams spend on tokens. At high, steady traffic the fixed cost amortises and the meter does not. The crossover point is the only calculation that matters here, and it is a function of your token volume, not of either model's quality.

• Vision work where the page count is the cost driver. N​VIDIA's card reports 62.82 on MMLongBench-Doc, 78.16 on MathVision, 80.82 on CharXiv reasoning and 68.12 on OCRBench v2 English against 59.15 Chinese, all vendor-reported. On O​pus 5.5 those same inputs are billed by the token, and a page of a scanned report is a lot of tokens. If your workload is thousands of document pages a day, the arithmetic changes faster than any quality difference does.

• Pinning. A checkpoint on a disk you control does not change under you. That is worth real money in a regulated pipeline, and it is a property the hosted model cannot offer at any price.

Two places it does not earn its place, and both are worth saying out loud. The first is long-horizon agentic work: N​VIDIA's card reports 66.70 on Terminal-Bench 2.1, 71.10 on SWE-bench Verified and 51.78 on SWE-bench Pro — respectable, unreproduced, and behind the hosted frontier. The second is anything where a failed request is expensive, because a model whose weights are four days old has four days of the world's attention behind it and no operational history at all.

The numbers you should not trust yet, and why

The whole published benchmark table for N​emotron 3.5 Super is the vendor's own, collected through N​VIDIA's NeMo Gym harness. GPQA-Diamond 89.52. Humanity's Last Exam text-only 31.79. LiveCodeBench v6 88.22. IFBench 70.86. tau2-bench 69.24 retail, 76.50 airline, 73.19 telecom. BrowseComp 78. LMArena v3 proxy 52.67. Every one of those is a vendor claim with a reproducible recipe attached, which is better than a bare claim, and still not an independent measurement.

The independent picture is much thinner, and that is itself the most useful fact on this page. The third-party panel that scores these models places this checkpoint at an Intelligence Index in the mid-twenties — around 26 — against roughly 58 for O​pus 5.5. That panel also records unusually high output-token consumption for the index run, which it reads as verbosity, and verbosity is a cost line rather than a footnote in any deployment where you pay per token or wait per token. One independent data point is not a verdict, but it is the only one that has not been produced by the company selling the model.

What nobody has published: how the 4-bit quantisation moves those scores. The default Ollama tag is q4_K_M. Every published figure is for BF16 or NVFP4. The number most people will actually experience is therefore unmeasured, and it is the one to watch for over the next few weeks.

What you can and cannot call today

Worth stating flatly, because it is the most common misunderstanding on pages like this. N​emotron 3.5 Super is not on OrcaRouter. We route a little over two hundred models and there is no N​VIDIA N​emotron entry among them, so if you need this specific checkpoint, your routes are the vendor's own build and distribution channels and the local runtime pull — not us.

O​pus 5.5, by contrast, is on our key, at the provider's list price passed through with no per-token markup, which means a vendor price change is live on our side the same day rather than at the next contract renewal. That asymmetry is genuinely useful for the decision in front of you: the cheap first move is to take the workload you were going to run on four H100s and run it against the hosted model first, on one API, without procurement. If the hosted model does the job at a tolerable price, you have saved yourself the cluster. If it does not — and misreading a dense technical document at scale is a plausible way for it not to — you now have evidence rather than a benchmark table, and you can spend the download on the cases that survived.

What the deployment recipe costs, concretely

The card's own vLLM recipe is worth reading as a budget document. Tensor parallelism of 4, GPU memory utilisation 0.85, a maximum of 32 concurrent sequences, one image and one video per prompt, video pruning at 0.5, and speculative decoding through the MTP head with three speculative tokens. Four H100s at 0.85 utilisation with a 32-sequence cap is not a large service — it is a serious single-node deployment, and the concurrency ceiling tells you what the vendor expects a single replica to handle.

Two details in that recipe matter more than they look. The video configuration accepts one video per prompt with pruning at half rate, which is a strong hint about where the vision budget goes on long inputs. And the reasoning parser is named nemotron_v3/ while the tool-call parser is qwen3_coder/ — the vendor is reusing a tool-call format it did not invent, which is good news for anyone with existing tool-calling code and worth knowing before you write new parsing logic.

Against that, the hosted model's operational surface is an API key. The comparison between "four H100s and a vLLM recipe" and "a key and a meter" is not close on effort. It is only close on cost, and only at volume.

One more thing that is knowable from a repository and easy to miss: the recommended sampling differs by modality. Text wants temperature 1.0 with top_p 0.95; vision wants 0.6 with 0.95. A deployment that sets one pair globally and then processes charts and scanned pages is running the vision half of a vision model on the text half's settings. If your first impression of this model on documents is poor, that is the first knob to check — before you conclude anything about the checkpoint.

So which one

If your work is long-horizon agentic coding, or anything where the reasoning has to be frontier-grade on the first attempt, Claude Opus 5.5 is the answer and the N​emotron tier is not a substitute for it. That is not a close call, and the vendor's own published agentic rows do not claim otherwise.

If your work is high-volume document and image understanding where the cost driver is the number of pages rather than the difficulty of the reasoning, this is one of the more interesting open checkpoints to appear this year: 120 billion parameters at 12 billion active, a permissive licence, a vision path that is genuinely present rather than bolted on, and a 4-bit default that fits on a single 96 GB card. The catch is that the version everyone will actually run — the q4_K_M default — has no published evaluation anywhere, the model is four days old, and the specification published by the runtime does not entirely match the specification published by the vendor.

Both of those are reasons to try it, not reasons to trust it. Put the workload on the hosted model first to find out whether the workload is one that a frontier model solves and a mid-tier one does not. Then decide whether the surviving cases are worth a cluster, a download, or an evening of configuration. And if you do put a four-day-old checkpoint into a request path, route it behind a fallback, because the cheapest insurance against a model with no operational history is a second model behind the same call.

What the numbers cannot tell you is whether any of it has gone wrong in the field: the documented AI incidents and agent failures 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.