Downloads · 30 days
20
23% of all-time downloads
PursuitOfDataScience/NVIDIA-Nemotron-3.5-Lightning-30B-A3B-ToolCall-LoRA
NVIDIA-Nemotron-3.5-Lightning-30B-A3B-ToolCall-LoRA is a text generation model from PursuitOfDataScience. Use it when you need the model to write or continue text. It is set up for peft. The card lists the license as openmdw-1.1.
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.
Downloads · 30 days
20
23% of all-time downloads
All-time downloads
86
Public
Repo size
55.5 MB
Likes
0
Public
Click a slice to open those files.
.safetensors55.5 MB · 100%
From the Hugging Face model README
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.
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.
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.
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.
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.
| 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.
Three defects in the raw corpus are filtered, because each teaches the opposite of the goal:
<tool_call>{...}</tool_call>
JSON into assistant prose — a third syntax this model's template never uses.
Lifted into structured calls.unknown. Dropped — supervising those teaches exactly the hallucination
this adapter is meant to remove.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.