PursuitOfDataScience/NVIDIA-Nemotron-3.5-Lightning-30B-A3B-ToolCall-LoRA

NVIDIA-Nemotron-3.5-Lightning-30B-A3B — agentic tool-calling LoRA

A LoRA adapter that makes NVIDIA-Nemotron-3.5-Lightning-30B-A3B substantially better at picking the right tool, filling its arguments correctly, and staying quiet when no tool applies.

Why this finetune exists

Nemotron-3.5-Lightning is built for long-running autonomous agents, and it is already willing to call tools — probed on held-out agentic trajectories it emits a well-formed call 97.7% of the time when one is needed. The problem is which call. It picks the correct function only 77.3% of the time, gets the full argument set exactly right 54.5% of the time, and fires a tool at an irrelevant request 18.5% of the time.

For an agent loop those three numbers are the ones that matter: a confidently malformed call costs a wasted turn, and a call made when none was warranted costs a wrong action. This adapter targets exactly those, trained on real multi-turn tool trajectories.

Results

Held-out Toucan-1.5M trajectories, n=200, greedy decoding, both arms measured at the same 1536-token generation budget. The validation split is deduplicated against training by normalised opening prompt.

metric	base	+ adapter	change
tool-name accuracy	77.3%	92.4%	↑ +15.2pp better
argument exact match	54.5%	72.7%	↑ +18.2pp better
schema valid (name exists, required args present)	81.1%	94.7%	↑ +13.6pp better
abstained when no tool applies	81.5%	92.6%	↑ +11.1pp better
named the right tool anywhere in its output	78.0%	92.4%	↑ +14.4pp better
emitted a well-formed call when one was needed	97.7%	94.7%	↓ -3.0pp worse
hit the generation ceiling mid-answer	2.3%	0.0%	↓ -2.3pp better

The one regression is honest and small: the adapter emits a call slightly less often (−3.0pp). It became more selective, and the selectivity is what buys the +18.2pp on argument exact-match and +11.1pp on abstention. Every call it does make is far likelier to be the right one, correctly parameterised.

Does it break anything?

A tool-calling finetune damages a general model in one characteristic way: it starts emitting call syntax when no tools were offered at all. That is invisible to every metric above, so it is measured directly — GSM8K prompts with no tools in the context, counting any tool-call markup in the output.

metric	base	+ adapter	change
GSM8K accuracy (no tools in context)	75.3%	78.7%	↑ +3.3pp better (n.s.)
tool-syntax intrusion	0.0%	0.0%	— +0.0pp

Paired significance on the GSM8K delta — McNemar: 9 fixed by the adapter, 4 broken by it, exact two-sided p = 0.2668 -- NOT significant at 0.05. The reasoning change is not significant; it is reported so the absence of damage is visible, not as an improvement.

Usage

This adapter targets the bf16 weights, not the NVFP4 checkpoint as shipped. quant_method: "modelopt" has no loader in transformers 5.6 or 5.15, so the published checkpoint cannot be loaded into a trainable — or adaptable — model at all. dequantize_nemotron_nvfp4.py in this repository rebuilds it:

# ~10 min on CPU, ~20 GiB RAM, produces ~61 GiB
python dequantize_nemotron_nvfp4.py     --src /path/to/NVIDIA-Nemotron-3.5-Lightning-30B-A3B-NVFP4     --dst /path/to/nemotron-3.5-lightning-bf16

Compare the dequant_manifest.json it writes against the one in this repository to confirm you rebuilt the same tensors. The nibble unpacking is bit-exact against compressed-tensors' reference implementation.

from transformers import AutoModelForCausalLM, AutoTokenizer
from peft import PeftModel

base = AutoModelForCausalLM.from_pretrained(
    "/path/to/nemotron-3.5-lightning-bf16", dtype="bfloat16", device_map="auto")
model = PeftModel.from_pretrained(base, "PursuitOfDataScience/NVIDIA-Nemotron-3.5-Lightning-30B-A3B-ToolCall-LoRA")
tok = AutoTokenizer.from_pretrained("/path/to/nemotron-3.5-lightning-bf16")

msgs = [{"role": "user", "content": "What's the weather in Chicago?"}]
tools = [{"type": "function", "function": {
    "name": "get_weather",
    "description": "Current weather for a city.",
    "parameters": {"type": "object",
                   "properties": {"city": {"type": "string"}},
                   "required": ["city"]}}}]
ids = tok.apply_chat_template(msgs, tools=tools, add_generation_prompt=True,
                              return_tensors="pt").to(model.device)
print(tok.decode(model.generate(ids, max_new_tokens=512)[0, ids.shape[1]:]))

The model answers in its native ChatML <tool_call><function=…> syntax. The adapter does not change the interface, only the reliability of using it.

Training

Data	3,200 Toucan-1.5M trajectories (400 steps x 8 examples)
Hardware	1x H200 141GB, 149 minutes
LoRA	r=16, alpha=32, dropout=0.05, 13.9M trainable (0.044%)
Targets	mamba in_proj/out_proj, the 6 attention blocks, and the shared expert
LR	1e-4 cosine to 1e-5, warmup 20, grad-clip 1.0
Sequence	max 4096 tokens, micro-batches capped by padded token count
Loss	assistant spans only

The 23x128 routed experts are deliberately not adapted — they hold 29 of the 30B parameters, and adapting them would defeat the point of a light adapter on a 3B-active model. Validation loss fell 0.5341 → 0.4965 over the run.

Data preparation

Three defects in the raw corpus are filtered, because each teaches the opposite of the goal:

• 7.4% of records leak the corpus generator's own <tool_call>{...}</tool_call> JSON into assistant prose — a third syntax this model's template never uses. Lifted into structured calls.
• 4.2% of gold calls name a tool that was never offered; 114 are literally named unknown. Dropped — supervising those teaches exactly the hallucination this adapter is meant to remove.
• The reasoning traces interleave the agent's planning with blocks where the data generator invents tool results. Only the agent's own passes are kept; an agent must never be trained to hallucinate observations.

Validation is deduplicated against training by normalised opening prompt. Toucan's subsets overlap by construction, so distinct ids are not distinct problems, and a naive split leaks 4.6% of validation.

Provenance and licensing

• Base model NVIDIA-Nemotron-3.5-Lightning-30B-A3B, OpenMDW-1.1. That licence requires any redistribution to retain a copy of it and all origin notices.
• Training data Toucan-1.5M, Apache-2.0.
• Toucan is synthetic: every trajectory used here was generated by MiniMax-M2.5. The behaviour this adapter installs is distilled from that model's outputs and inherits its conventions.

Limitations

• Trained on 3,200 examples for 400 steps. Validation loss was still falling, so this is a bounded run, not a converged finetune.
• The evaluation scores the first tool call of a trajectory. It does not measure multi-turn task completion.
• Measured only on Toucan-derived data. Gains against a corpus generated by MiniMax-M2.5 are partly gains at matching that model's conventions; this adapter has not been evaluated on an independent tool-calling benchmark.
• Single seed. Sampling error is roughly ±6.9 points per cell at n=200.
• The MTP (multi-token-prediction) head survives dequantisation but is not exercised by this recipe; speculative decoding was not re-measured.