NVIDIA-Nemotron-3-Ultra-550B-A55B

Nemotron 3 Ultra 550B-A55B

550 billion parameters, 55 active, 262,144 tokens of context — and NVIDIA published the reward model they used to train it.

They Released the Judge

The most unusual thing about this model is not in the model.

Nemotron-3-Ultra-550B-A55B-GenRM is a Generative Reward Model, fine-tuned from this model's own foundation, and used in the reinforcement learning from human feedback that produced this release.

What it does: given a conversation history, a new user request, and two candidate assistant responses, it produces an individual helpfulness score for each and a ranking score between them.

And it accepts user-specified principles — supply your own criteria and it judges against those rather than against its defaults.

Why publishing it matters. A reward model is the standard a trained model was optimised toward. Every preference it encodes shapes the resulting behaviour, and it is normally the least visible part of a release — you get the model and no way to examine what "better" meant during its training.

Here you can read the judge. For alignment research, for auditing, and for anyone who needs to answer what a model was trained to prefer, that is a different level of access from open weights alone.

And it is reusable. A reward model that scores two candidate responses against stated principles is a component you can put in your own pipeline — evaluating outputs, ranking alternatives, or training something of your own.

Architecture

Three mechanisms interleaved, each placed where it costs least.

Mamba-2 carries sequence state through a recurrent update at constant cost — no key-value cache growing with the input. That is what makes a million-token window affordable at this scale.

MoE layers provide capacity without paying for it on every token.

Select attention layers give exact retrieval where recurrent state compresses too far. A few attention layers among many recurrent ones buys precision where the model needs to look something up rather than remember it approximately.

Ten percent activation — 55 billion of 550. Higher than the sparser models elsewhere in this catalogue, and a deliberate position: more compute per token, more capability per token.

LatentMoE and NVFP4

Two refinements shared with the Super model in this family, and both are about efficiency per unit of data rather than per parameter.

LatentMoE projects tokens into a smaller latent dimension for expert routing and computation. The stated benefit: improving accuracy per byte.

Per byte, not per parameter. It is a claim about the information density of the representation — routing decisions and expert computation happen on a compressed form, reducing what moves through the expert layers without reducing what the model can express.

NVFP4 pre-training rather than post-training quantisation. The model learned at the precision it ships in, which means what was evaluated and what you download are the same configuration.

Most models are trained at full precision and quantised afterwards, leaving the cost of that conversion undocumented.

Two Cutoffs, Both Recent

They describe different things. Pre-training is where world knowledge comes from. Post-training is where instruction-following conventions, tool-calling format, and reasoning behaviour were shaped.

A model can know nothing about an event from October 2025 while following a convention established in 2026. Worth remembering when a factual answer disappoints — the question may be whether it was ever taught, not whether it reasoned correctly.

Both cutoffs are more recent than the Super model in this family — three months on pre-training, three on post-training.

Specifications

Languages: English, French, Spanish, Italian, German, Japanese, Hindi, Korean, Brazilian Portuguese, and Chinese.

Published precisions: BF16 and NVFP4 from NVIDIA directly, plus community GGUF builds. NVFP4 is the smaller-footprint path and NVIDIA point to it explicitly for constrained deployment.

Capabilities

Reasoning Is a Template Flag

The model responds by first generating a reasoning trace and then concluding with a final response, and that behaviour is configured through a flag in the chat template rather than through a request parameter.

Enable it for multi-step analysis, code, mathematics, and anything with a decision in it.

Leave it off for classification, routing, extraction, and formatting — deliberation adds latency and nothing else on work with one correct answer.

Through an API the flag is handled for you. It matters when self-hosting.

Evaluation You Can Reproduce

Uncommon enough to be a feature.

All evaluation results were collected via the Nemo Evaluator SDK and NVIDIA's open-source container of LM Evaluation Harness. Evaluation settings are documented in the SDK's examples folder, and a reproducibility tutorial exists specifically for this model.

What that means. Most published benchmark figures cannot be checked — the harness, the prompts, the sampling settings, and the scoring are all unstated. Here the container, the settings, and a tutorial are all published.

If a number matters to your decision, verify it rather than accept it. That option is not available on most models, and it costs an afternoon rather than a rewrite.

Using Nemotron 3 Ultra on DEVUP AI

Base URL: https://api.devupai.com/v1 · Model ID: nvidia/NVIDIA-Nemotron-3-Ultra-550B-A55B

Python

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["DEVUP_API_KEY"],
    base_url="https://api.devupai.com/v1",
)

response = client.chat.completions.create(
    model="nvidia/NVIDIA-Nemotron-3-Ultra-550B-A55B",
    messages=[
        {"role": "user", "content": "Hello world!"}
    ],
    max_tokens=1024,
)

print(response.choices[0].message.content)

Node.js

import DevupAI from "devupai";

const client = new DevupAI({
  apiKey: process.env.DEVUP_API_KEY,
});

async function main() {
  const response = await client.chat.completions.create({
    model: "nvidia/NVIDIA-Nemotron-3-Ultra-550B-A55B",
    messages: [{ role: "user", content: "Hello world!" }],
    max_tokens: 1024,
  });

  console.log(response.choices[0].message.content);
}

main();

cURL

curl -X POST "https://api.devupai.com/v1/chat/completions" \
  -H "Authorization: Bearer $DEVUP_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "nvidia/NVIDIA-Nemotron-3-Ultra-550B-A55B",
    "messages": [
      { "role": "user", "content": "Hello world!" }
    ],
    "max_tokens": 1024
  }'

Reasoning Over a Very Large Codebase

Named directly in the model's intended use, and where the Mamba-2 layers pay for themselves.

from pathlib import Path

REPO = Path("src")

sources = "\n\n".join(
    f"=== {path.relative_to(REPO.parent)} ===\n{path.read_text(encoding='utf-8')}"
    for path in sorted(REPO.rglob("*.py"))
)

response = client.chat.completions.create(
    model="nvidia/NVIDIA-Nemotron-3-Ultra-550B-A55B",
    messages=[
        {
            "role": "system",
            "content": (
                "You are auditing a codebase. Identify every path where a database write can occur "
                "without a surrounding transaction. Cite the file and function for each finding, "
                "and name the call chain that reaches it. Report nothing you cannot trace."
            ),
        },
        {"role": "user", "content": sources},
    ],
    max_tokens=32768,
)

print(f"input: {response.usage.prompt_tokens:,}")
print(response.choices[0].message.content)

Asking for the call chain rather than the line is what uses a 262,144-token window rather than a grep. A write outside a transaction is easy to find; the path that reaches it from three modules away is the finding that required the whole repository in one context.

A Multi-Step Agent

The stated design target: complex multi-step agents and high-stakes analytical workloads.

import json
import time

TOOLS = [
    {
        "type": "function",
        "function": {
            "name": "query_metrics",
            "description": "Return time-series metrics for a service over a window.",
            "parameters": {
                "type": "object",
                "properties": {
                    "service": {"type": "string"},
                    "metric": {"type": "string"},
                    "window": {"type": "string", "description": "e.g. 1h, 24h, 7d"},
                },
                "required": ["service", "metric", "window"],
            },
        },
    },
    {
        "type": "function",
        "function": {
            "name": "read_logs",
            "description": "Return log lines for a service within a time range, optionally filtered.",
            "parameters": {
                "type": "object",
                "properties": {
                    "service": {"type": "string"},
                    "since": {"type": "string"},
                    "filter": {"type": ["string", "null"]},
                },
                "required": ["service", "since"],
            },
        },
    },
]


def query_metrics(service: str, metric: str, window: str) -> dict:
    """Replace with your real observability backend."""
    raise NotImplementedError


def read_logs(service: str, since: str, filter: str | None = None) -> dict:
    """Replace with your real log store."""
    raise NotImplementedError


HANDLERS = {"query_metrics": query_metrics, "read_logs": read_logs}

session = [
    {
        "role": "system",
        "content": (
            "You are investigating a production incident. Establish what happened before proposing "
            "why. Distinguish what the data shows from what you are inferring, and say which is "
            "which."
        ),
    },
    {"role": "user", "content": "Checkout latency doubled at 14:00 yesterday and recovered by 15:20. Find the cause."},
]

CEILING = 60
start = time.monotonic()

for step in range(CEILING):
    response = client.chat.completions.create(
        model="nvidia/NVIDIA-Nemotron-3-Ultra-550B-A55B",
        messages=session,
        tools=TOOLS,
        max_tokens=32768,
    )

    message = response.choices[0].message
    session.append(message)

    if not message.tool_calls:
        print(message.content)
        break

    for call in message.tool_calls:
        handler = HANDLERS.get(call.function.name)
        if handler is None:
            outcome = {"error": "unknown tool", "name": call.function.name}
        else:
            try:
                outcome = handler(**json.loads(call.function.arguments or "{}"))
            except Exception as exc:
                outcome = {"error": type(exc).__name__, "detail": str(exc)}

        session.append({"role": "tool", "tool_call_id": call.id, "content": json.dumps(outcome)})
else:
    print(f"Stopped at the {CEILING}-step ceiling after {(time.monotonic() - start) / 60:.1f} min.")

The instruction to separate observation from inference is the one that makes an incident investigation usable. A model that presents both in the same voice produces a narrative; one that marks the difference produces something an engineer can check.

Choosing Within the Family

Three tiers, and the differences are real rather than incremental.

MTP is absent from Nano and present on the two larger models — a stated distinction rather than an implementation detail.

Super is the volume tier. Twelve billion active parameters, positioned for high-throughput automation like ticket triage. Ultra is the capability tier — four and a half times the active compute, aimed at work where getting it right matters more than getting it cheap.

Pick by what fails. If a task fails on Super because the reasoning was not deep enough, Ultra is the answer. If it fails because the throughput was not there, Ultra is the wrong direction.

Self-Hosting

Two official precisions. BF16 for maximum fidelity; NVFP4 for a smaller footprint, which NVIDIA point to directly for constrained deployment. Community GGUF builds exist alongside.

The training recipe is published, which matters if you intend to continue training rather than only run inference.

Evaluation is reproducible through the Nemo Evaluator SDK, with a tutorial specific to this model.

Read the suffix carefully. Every official checkpoint carries a precision suffix, and separate -Base and -GenRM variants exist — the first does not follow instructions, the second is a scoring model rather than a chat model.

Where It Fits

Complex multi-step agents, named first in the intended use.

Long-context reasoning over very large documents and codebases — 262,144 tokens, at a recurrent model's cost profile.

High-stakes analytical work over code, mathematics, and science, where accuracy outranks cost.

Retrieval-augmented systems and complex instruction-following.

Regulated and audited environments, where published data, a published recipe, a reproducible evaluation path, and a published reward model together answer questions most models leave open.

Alignment and preference research, where the GenRM is the artefact that makes this family different.

Not for vision. Text only.

Not for high-volume automation. Fifty-five billion active parameters is the capability tier; the Super model in this family is the throughput one.

Practical Notes

Turn reasoning off for mechanical work; leave it on for analysis.

Ask for call chains and traceable findings on large-codebase work — that is what the window buys over a search.

Instruct the model to separate observation from inference on investigative tasks.

Verify a benchmark figure through the published evaluator rather than accepting it, if the number decides something.

Read the checkpoint suffix — precision, -Base, and -GenRM are all distinct.

Use NVFP4 where the footprint matters; it is the path NVIDIA point to.

Consider the GenRM as a component in your own evaluation pipeline, not only as documentation.

Limitations

Text only. No image, audio, or video input, and no image generation.

Fifty-five billion active parameters is the compute per token — high for a sparse model, and the reason this tier costs more than the one below it.

550 billion parameters must be loaded even though 55 run per token. The MoE saving is in compute, not memory, and serving this model requires serious hardware.

Two different cutoffs. World knowledge ends September 2025; instruction behaviour was shaped through May 2026.

Ten documented languages. Others are outside the stated support.

Reasoning is a template flag, not a request parameter. Relevant when self-hosting.

A base variant and a reward-model variant share almost the same name. Neither is a drop-in replacement for this one.

Published training data is "major portions", not the complete corpus. More transparency than most, and not total.

Reasoning traces are working notes. Treat the final response as the output and the trace as debugging material.