Post-training case study

Nemotron 3.5 Super on Era

How Nemotron did on Era's agentic benchmarks, how it compares with frontier models, where it fell short, and what post-training changed.

Era

Era builds complete simulated companies for agents to work in. Each one is a single business with the same customers, deals and employees across cloud databases, object storage, Salesforce, HubSpot, Zendesk, Jira, Gong, Slack and a document store. Agents reach it through MCP servers and vendor-compatible APIs. It is built by the Eon engineers who back up exabytes of enterprise cloud data, so the data has a realistic size and shape.

Nemotron 3.5 Super

NVIDIA's open 120B mixture-of-experts model, with about 12B parameters active per token. It mixes 40 Mamba-2 blocks, 40 MoE blocks (512 routed experts, 22 active plus one shared) and 8 attention layers, and has a 262K context and a built-in reasoning mode. It ships as a NIM container and runs on your own GPUs behind an OpenAI-compatible API.

What we did

We ran it on Era's Query and Compute tasks, hard board and tool-call board from one self-hosted 8×H100 node. Then we picked one weakness, abstaining when the data has no answer, and trained it with LoRA-SFT: run the base model on eight Era companies, keep the episodes Era's grader marked correct, train a rank-32 adapter on them, merge it, and measure again on a company the model had never seen.

The benchmark

Query and Compute tasks

The Query and Compute tasks are 33 factual questions about one simulated fintech. The only way to answer them is through the company's tools: REST and MCP calls to Salesforce, HubSpot, Zendesk, Jira, Gong, Slack and S3. A model has to find the right records across systems, read every page, join, group and aggregate them, and get the arithmetic right: counts, sums, medians, "which account had the most". Two questions have no answer in the data, and the right response is to say so. Each question has one exact key, computed from the same records the tools serve. Every model answers each question several times, and the score is the share of runs that were correct.

How a question is run and graded. The generator decides the answer first and plants the records that produce it. The model sees only what the tools return. Code compares the submitted value with the key; no model does the judging.

89.9%of Query and Compute runs correct, base Nemotron (89 of 99)
$0.068per correct answer, self-hosted 8×H100 at Spot prices
Results

How it compares

Nemotron scored 89.9%, the highest of the ten models we have run on these questions. Claude Opus 4.8 is next at 76.8%. With 33 questions the intervals still overlap, so the exact order is not settled, but Nemotron is clearly in the top group. It also never refused a question that had an answer; every other model did so between 3 and 17 times.

The other nine rows are the published Query and Compute board. Nemotron's row is a clean re-run after we fixed how Era decodes the NIM's tool-call arguments, on a later build of the same company. On the published build, with that decoding error corrected, it scored 88.9%.

Accuracy against cost per correct answer. API models are priced at their list price. Nemotron is priced at the Spot cost of the GPU node for the time the runs took; at on-demand prices it would be $0.36. It costs about a twelfth of Claude Opus 4.8 per correct answer. GPT-5.6-luna is cheaper, and scores 33 points lower.

Compared with Claude Opus 4.8 it did better on counting, pagination, joins, grouped and aggregate questions, cross-system joins, superlatives, multi-hop chains and time-based questions. Its weak spots are the one distribution question (0 of 3), time-based questions (half right) and the Gong call questions. Outside these 33 questions it also missed every document-store question and the Slack and Jira counts.

Accuracy by question type and system. Each cell is the share of correct runs on the questions with that tag. Nemotron is the outlined column.

Tokens per question. Nemotron reasons at length: about 470K tokens per question, almost four times Claude Opus 4.8. On 4 of its 99 runs the reasoning used the whole 16K output budget and no answer came back. Cheap tokens make this affordable, but it is the first thing to tune.

Results

The hard board: where the obvious reading is wrong

The hard board has eight questions where the convenient reading of the data gives the wrong answer. A rule is mentioned once on a sales call and has to be applied to the records, or two systems disagree and only one of them is current. Nemotron sits in the middle here. With the LangGraph harness it solved 2 of 24 runs, the same as GPT-5.6-sol, and without a harness it solved none. Claude Fable 5.1 and GPT-6 Astra solve half or more.

Two hard-board questions. The top lane is the reading that looks right; the bottom lane is what the key is built from. With LangGraph, Nemotron found and applied the rule for K2 in two of three runs. It missed S1 in all three.

Hard-board weighted score by model and harness. Harder questions count up to three times as much. The hard board page also folds in an easier set; it is left out here so every model is compared on the same eight questions.

Results

Where it went wrong: abstention

Some questions can't be answered from the connected systems: an account's credit rating, its current MRR, where an analyst firm placed the company. The right move is to abstain: abstain: true plus a note on what was searched. On 90 held-out runs of such questions Nemotron got 64 right. In most of the other 26 it searched well and then turned "nothing found" into an answer: an empty field became "MRR is 0", or the note said nothing exists while the answer field still held the string "None".

One held-out episode, base model An unanswerable question, answered The agent is asked for a company's current MRR, calls HubSpot and S3, finds the field null and no billing document, and submits the number 0 with abstain set to false. The key expected answer null with abstain true. QUESTIONAGENTCONNECTED SYSTEMS What is the current monthly recurring revenue billed to Malachite Partners? no system in this estate records MRR think → search → decide hubspot.companies.search hubspot.companies.get s3.list_objects billing/ HubSpot1 company · id 4417 · Malachite Partners HubSpotproperties.mrr: null · annualrevenue: null S312 invoices · no MRR line item submit {"answer": "0", "abstain": false} ✗ graded 0 "nothing found" was turned into a number. The field is empty, the fact is unknown, and the model said 0. ✓ key {"answer": null, "abstain": true, "note": "no connected system records MRR for this account"}

The step that goes wrong. Every tool call is reasonable and the search is thorough. The mistake is the last step: "I found nothing" becomes a number instead of an abstention.

Post-training

Post-training and alignment, quickly

Post-training starts from a finished model and changes its behaviour with a small amount of targeted data. Alignment is post-training aimed at how the model behaves, rather than what it knows. Supervised fine-tuning (SFT) is the simplest form: show the model examples of the behaviour you want and train it to reproduce them.

The training loop is the easy part of SFT; the data is the hard part. You need many examples in the format the model works in (tool calls, tool results, the final structured answer), and you need to know each one is right. Era gives you that for free, because the grader is the label.

LoRA-SFT on Era rollouts LoRA-SFT on Era rollouts Left: Era generates a company, the base model rolls out on its tasks, the grader keeps only correct traces. Right: the frozen 121B weights get two small low-rank matrices A and B per target layer; only those train, then W plus BA is merged and served. 1 · DATA FROM ERA2 · LOW-RANK UPDATE Era generates a company 8 training estates · 1 held out Base model rolls out 589 episodes · tools + reasoning Grader keeps the correct 186 abstain + 180 answer = 366 Loss on the final turn the submit call only 218 wrong answers discarded 366 graded traces W frozen · 121B params bf16 · 243 GB Mamba-2 · MoE · attn no grads, no optimizer B (d × r) A (r × d) r = 32 · trainable 59.7M params · 240 MB 152 tensors: attn, Mamba in_proj, shared expert + W′ = W + B·A → merged shards, served by vLLM

Era generates the companies and grades the episodes, and only the correct traces become training data. The base weights stay frozen; two small matrices per target layer carry the whole update.

The run

Running it on 8×H100

AWS p5.48xlarge8× H100 80 GBNIM, 2× TP4 replicastransformers + peftvLLM
  1. 01 · DATASplit the companies

    Eight Era-generated companies for training, one held out for measuring. No company is in both.

    8 train · 1 held out
  2. 02 · ROLLOUTRun the base model

    The 30-question abstain suite plus the answerable Query and Compute tasks on every training company, so it sees both sides of the decision.

    589 episodes
  3. 03 · GRADELet the grader pick

    Keep only what Era graded correct, with answers and abstentions balanced so the model doesn't learn to refuse everything. Wrong answers are dropped.

    186 abstain + 180 answer
  4. 04 · SHAPEFormat the traces

    Tool results cut to 1,500 characters, and loss on the final submit turn only.

    366 samples
  5. 05 · TRAINLoRA-SFT

    Rank 32 on attention, Mamba in_proj and shared-expert projections. Base weights frozen.

    59.7M params · 92 steps · 103 min
  6. 06 · MERGEFold it back

    W' = W + B·A merged into the checkpoint and served with vLLM. Inference cost stays the same.

    152 tensors · 0 mismatches
  7. 07 · MEASURERe-run on the held-out company

    Same 30 abstention questions and 33 Query and Compute tasks, same harness, same grader, no hints.

    90 + 99 runs
What changed

It abstains in the right shape, and stops sooner

64 → 69correct abstentions out of 90 held-out runs, before → after
5 → 0malformed abstentions
52 → 37tool calls per abstention episode
2.2×fewer tokens per abstention episode

Every held-out abstention run, before and after. The malformed abstentions and context overflows are gone. The number of confident answers did not drop: 17 of 90 after tuning, 15 before.

After tuning, every abstention has the right shape, answer: null, abstain: true, and no run overflows the context window. It searches, decides and stops. Two cases that flipped:

Outside-estate fact

In which quadrant of this year's industry analyst report is Malachite Partners placed?

before
{"answer": "None", "abstain": true,
 "note": "No connected system contains any
  information about an industry analyst
  report ..."}
→ graded 0: "None" is a value
after LoRA-SFT
{"answer": null, "abstain": true,
 "note": "No connected system ... contains an
  industry analyst report or any quadrant
  placement for Malachite Partners. This is
  external market-intelligence data."}
→ graded 1 (3 of 3 runs)
Absent system

How many on-call pages were triggered for Malachite Partners last quarter?

before
{"answer": "0", "abstain": false, "note": ""}
→ graded 0: no paging system is connected,
  so the count is unknown, not zero
after LoRA-SFT
{"answer": null, "abstain": true,
 "note": "No connected system stores on-call
  paging data ... This metric would live in
  an incident management system (e.g.
  PagerDuty) which is not connected."}
→ graded 1 (3 of 3 runs)
Next. It still answers confidently when a field exists but is empty (credit_rating: null). Fixing that needs contrast pairs in the training data.
Why it matters

Alignment is the lever

A targeted behaviour in a 121B model changed with 366 examples and 60M trainable parameters, and labelling the examples cost nothing. Frontier models get their behaviour from post-training too, at a scale few teams can afford. A model with Nemotron's cost that you can align to your own data and failure modes closes much of the gap to models that cost five to twenty times more per correct answer. How much of the gap it closes is an empirical question, and Era is how you measure it.

Why Era

An environment where the grader is the label

Most agent fine-tuning data is either written by people (small and expensive) or judged by another model (only as good as the judge). Era works differently. Generation starts from the question: the generator picks the answer, plants the records that produce it across the connected systems, and gives the grader the key. Code checks every submission. A question is unanswerable because the fact was never placed anywhere. The systems speak vendor-faithful REST and MCP, so a training trace looks exactly like what the model will see in production. Generate as many companies as you need, hold some out, and your evaluation stays clean. See how Era post-trains agents.

Why Nemotron

Built for long, tool-heavy episodes

Post-training pays off most in rich interactive environments, and most models are too expensive to use there. An Era episode is tens to hundreds of tool calls and hundreds of thousands of tokens. Nemotron's hybrid Mamba-2/MoE design suits that: 12B active parameters, a per-token state that barely grows with context, and a 262K window it can actually use. It is efficient to serve and the weights are open, so you can run the whole loop yourself: measure, train on graded rollouts, merge, and measure again, all against a company that doesn't exist.