NVIDIA Nemotron 3 Ultra and Super: Open Models Built for Long-Running Agents

NVIDIA Nemotron 3 is not just another open-weight model drop. It is NVIDIA's clearest move into models built specifically for agent infrastructure: planning, tool use, code, research, long context, and long-running loops where cost and throughput matter as much as raw benchmark scores.

The important distinction is this: Nemotron 3 Ultra is the 550B reasoning and orchestration model. Nemotron 3 Super is the 120B efficient workhorse. For builders, the interesting question is not which one is "best." It is how to route work between them.

Source Note

This post uses NVIDIA's official Developer Blog, NIM model cards, Hugging Face model cards, Linux Foundation OpenMDW material, and the NVIDIA Nemotron research page as the factual spine. The two additional videos are treated as commentary and hands-on experiments.

"Open" is used here in NVIDIA's model-distribution sense: open weights, open data, open recipes, and specific model licenses. That is not a substitute for reading the license before deployment, redistribution, fine-tuning, or commercial use.

Link Map

The Main Takeaway

Nemotron 3 is built around a practical agent problem: long workflows get expensive. Agents plan, call tools, delegate, read results, validate, recover, and keep passing context forward. That creates more tokens, more latency, more cost, and more drift.

NVIDIA's answer is not one model for everything. It is a family:

• Ultra: expensive, strong, open frontier reasoning for orchestration and difficult decisions.
• Super: efficient 120B/12B-active model for high-volume agent work, tool calls, coding, RAG, and local or hosted experiments.
• Nano: smaller model for lower-latency and lower-cost tasks.

In a real agent stack, that means routing. Do not send every call to the biggest model. Send hard calls to Ultra, repeated execution to Super or Nano, and keep the human in the loop where failure costs matter.

Nemotron 3 Ultra vs Nemotron 3 Super

NVIDIA's Ultra model card lists minimum requirements like multi-GPU GB200/B200/GB300/B300, H100, or H200 class infrastructure for full official deployment. Super's NIM card lists 8x H100-80GB as the official minimum. That is the serious deployment reality.

The local experiments are different. They rely on quantization, RAM-heavy systems, partial GPU offload, and lower throughput. Useful? Yes. Comfortable production guidance? Not by itself.

Why The Architecture Matters

The architecture matters because Nemotron is optimized for agent loops, not just chat.

• Mixture-of-Experts: only a subset of parameters activates for each token, which improves efficiency.
• LatentMoE: tokens are compressed before expert routing, letting the model consult more experts at similar cost.
• Hybrid Mamba-Transformer: Mamba layers improve long-context sequence efficiency, while attention layers help preserve precise recall.
• Multi-token prediction: the model predicts multiple future tokens in one forward pass, improving long-output and multi-turn throughput.
• NVFP4: NVIDIA's precision format targets efficient training and inference on NVIDIA platforms.

In normal language: Nemotron is trying to make agent loops cheaper and faster without giving up too much reasoning quality.

What "Open" Actually Means Here

NVIDIA and Hugging Face describe Nemotron 3 as a family with open weights, training data, and recipes. Ultra is governed by the Linux Foundation's OpenMDW 1.1 license, a framework intended for model, data, and weights distributions.

This matters for enterprises because open models are not just cheaper API substitutes. They support:

• self-hosting for data-control requirements;
• fine-tuning for domain-specific workflows;
• deployment across cloud, on-prem, and edge environments;
• model inspection and reproducibility work that closed APIs do not allow.

The caveat: open does not mean frictionless. You still need infrastructure, license review, safety evaluation, monitoring, and a deployment owner.

How Builders Should Deploy It

For most teams, I would test in this order:

1. NVIDIA NIM / build.nvidia.com: fastest way to understand model behavior without building serving infrastructure.
2. OpenRouter or hosted providers: useful for routing experiments and comparing cost per completed task.
3. Hugging Face / dedicated cloud GPU: useful when you need weights, fine-tuning, and deployment control.
4. Local LM Studio / llama.cpp / Unsloth-style runs: useful for learning, privacy experiments, and prototyping, but hardware matters.
5. On-prem cluster: only when there is a repeated business reason: private code, regulated data, heavy daily agent usage, or domain fine-tuning.

The metric to track is not tokens per second alone. Track cost per completed task: how many model calls, tool calls, retries, human interventions, and verification steps were needed to finish the workflow correctly.

What The Local Nemotron 3 Super Test Shows

The local LM Studio video is useful because it makes the hardware tradeoff real. The creator tests an 83GB-plus Nemotron 3 Super build on a desktop with 128GB RAM and a 16GB VRAM NVIDIA GPU. It does not load at first. The working setup comes after reducing active experts and GPU offload until the model fits.

The interesting part is not "everyone can now run 120B on a normal GPU." The more honest lesson is:

• system RAM matters as much as VRAM for huge local models;
• quantized builds make experiments possible;
• partial GPU offload can work, but speed is limited;
• LM Studio's local server can turn a desktop into a LAN model box;
• production reliability still wants proper GPU infrastructure.

If you want a local sidecar for agents, Super is more realistic than Ultra. But even Super is still a large-model experiment unless you have a serious workstation.

JQ AI SYSTEMS Builder Checklist

If you want to test Nemotron for agent systems, use this checklist:

1. Pick one long-running workflow. Code review, research synthesis, IT ticket handling, financial document review, or RAG over long context.
2. Measure task completion, not vibes. Track success rate, tokens, wall-clock time, retries, and human review effort.
3. Route by difficulty. Ultra for orchestration and hard reasoning; Super for repeated tool calls and execution.
4. Test context honestly. 1M context is only useful if retrieval, citations, and instruction hierarchy remain stable.
5. Review licenses before shipping. OpenMDW and NVIDIA model licenses are part of the deployment, not paperwork after the fact.
6. Keep safety gates. Logs, sandboxing, approval queues, and rollback are still required for agents that touch code, money, data, or customers.
7. Do a local experiment only after a hosted baseline. Know the model is worth using before buying hardware or spending a weekend on quantization.

Sources

• NVIDIA Developer: Introducing NVIDIA Nemotron 3 Ultra
• Commentary: NVIDIA's NEW Nemotron 3 Super in 6 Minutes
• Local experiment: Nemotron 3 Super in LM Studio
• NVIDIA Developer Blog: Nemotron 3 Ultra
• NVIDIA Developer Blog: Nemotron 3 Super
• NVIDIA Nemotron 3 family page
• NVIDIA NIM model card: Nemotron 3 Ultra
• NVIDIA NIM model card: Nemotron 3 Super
• Hugging Face: Nemotron 3 Ultra BF16
• Hugging Face: Nemotron 3 Super FP8
• Hugging Face: NVIDIA Nemotron v3 collection
• Linux Foundation: OpenMDW 1.1 and NVIDIA adoption
• OpenMDW
• LM Studio: Nemotron 3 Super
• Unsloth: Nemotron 3 Super guide
• Unsloth: Nemotron 3 Ultra guide
• OpenRouter: Nemotron 3 Super
• OpenRouter: Nemotron 3 Ultra