MiniCPM5-1B-Agentic-Tooluse
LoRA adapter for
openbmb/MiniCPM5-1B, fine-tuned on
ToolACE for single-turn function calling : given a conversation and a set of tool schemas, emit the first tool call
with the correct name and correct argument values.
Trained on a single Kaggle T4 with Unsloth + TRL SFT.
Results
Evaluated on a held-out 300-example test slice drawn from a seeded shuffle of ToolACE (see Split integrity ).
The base-model column is the same model with the same prompt and no adapter.
The published weights are SFT + GRPO (see GRPO / RLVR ). The SFT column is kept because every
negative result below is measured against it.
metric v2 (previous release) SFT retrain (pre-GRPO) v3 = SFT + GRPO (published) parseable — output is a well-formed call0.9933 1.0000 1.0000 valid_name — name exists among the offered tools0.9700 0.9867 0.9867 expected_name — name matches gold0.9067 0.9567 0.9533 args_exact — every argument value matches gold0.6133 0.7367 0.7467 arg_key_overlap — F1 over argument keys0.8757 0.9422 0.9388 mean of 5 0.8718 0.9245 0.9251
v2 (previous release) = the previously published SFT adapter. An earlier draft of this card
mislabeled this column "base model (untrained)" -- that was wrong; it is NOT the raw base model.
The real untrained openbmb/MiniCPM5-1B, measured on this same test slice, scores parseable
0.9333, valid_name 0.9133, expected_name 0.8867, args_exact 0.6300, arg_key_overlap 0.8920.
SFT retrain = a fresh SFT pass from v2, prior to GRPO. v3 = what this repo currently serves.
Every "did it improve?" decision in this card is judged against v2 , not against the untrained
base model — beating an untrained model is not evidence of anything.
GRPO buys +0.0100 on args_exact, the metric that matters here, and gives back 0.0034 (one test example
each) on expected_name and arg_key_overlap. That trade is reported rather than hidden: the mean moves
only +0.0006, so this is a targeted gain on the hardest metric, not a broad improvement.
Four of the five metrics are above 0.80. args_exact is not, and the next section explains how much of it is
actually reachable.
Reproducibility
Two independent training runs were performed. They converged to identical args_exact (0.7367) despite
different data ordering, and one differing in data composition.
metric run 1 run 2 (composite-oversampled) parseable1.0000 1.0000 valid_name0.9900 0.9867 expected_name0.9567 0.9567 args_exact0.7367 0.7367 arg_key_overlap0.9388 0.9422
The weights published here are run 2.
Honest limits of args_exact
args_exact is strict and all-or-nothing over every argument value. Its measured ceiling on this test slice is
not 1.0 :
9.33% of test cases are unwinnable. 28 of 300 gold calls contain a date that appears nowhere in the
prompt. There is no anchor "today" to resolve them against — the gold dates span 1990–2027 across 75 distinct
values, so no single assumed current date recovers them. This caps args_exact at 0.9067 .
The dominant remaining error class is composite JSON arguments (~14–20% of argument values are nested
objects or arrays), where the model must reproduce an entire nested structure exactly.
So 0.7367 sits against a practical ceiling of 0.9067, closing about 42% of the base-model-to-ceiling gap
(0.6133 → 0.7367, out of a possible 0.6133 → 0.9067).
The grader was deliberately not loosened. It does normalize formatting-only differences (key order,
whitespace, 70 vs 70.0) and is guarded at runtime by assertions in both directions: 10 must-differ pairs must
be rejected and 5 formatting-only pairs must be accepted. Relaxing date comparison, or dropping the unwinnable
cases from the denominator, would have raised the headline number without improving the model.
What did not work
Measured negative and null results, recorded so they need not be re-tried:
Oversampling composite-JSON examples — no effect on args_exact (0.7367 in both runs).
Thinking mode on — clearly harmful: validation args_exact fell 0.7367 → 0.5267. Consistent with
TAFC (arXiv:2601.18282) , which notes over-reasoning degrades simple
single-parameter function calls.
Longer training — validation plateaued (run 1 at step 600, run 2 at step 750).
Self-consistency / majority voting — not used.
ToolPRM (arXiv:2510.14703) measures majority voting degrading argument F1 on function calling (Hammer2.1-3B: 62.83 → 58.27), because
structured output cannot recover from an early error, so non-greedy sampling ruins whole trajectories.
Decoding here is greedy .
GRPO / RLVR — partial result
Because SFT was demonstrably saturated (two runs, identical args_exact, val plateaued), the next lever tried was
RL with a verifiable reward: GRPO where the reward is this repo's own grader, so reward and reported metric
cannot drift apart. Reward design followed
ToolRL (arXiv:2504.13958) —
fine-grained decomposition (parseable / tool name / argument keys / argument values) rather than all-or-nothing,
correctness weighted 0.90 against format 0.10, and no length reward.
It works, and the published weights include it. With a validation ratchet that only keeps a checkpoint
beating the previous best, across several short sessions:
[ratchet] step 150 val args_exact 0.7467 (SFT 0.7367) <-- kept
[ratchet] step 40 val args_exact 0.7533 (best 0.7467) <-- kept (higher-exploration config)
[ratchet] step 80 val args_exact 0.7500 (best 0.7533) <-- rejected
The step-40 checkpoint was then measured once on the held-out test slice: args_exact 0.7367 → 0.7467 .
Why GRPO stalls here, measured
The first configuration (4 generations, temperature 1.0) gained zero test examples over 100 steps. The cause
was instrumented rather than guessed — the fraction of prompt groups whose samples all receive identical
reward:
[collapse] 18/25 groups (72%) had identical rewards -> zero advantage -> no gradient
[collapse] 37/50 groups (74%) ...
[collapse] 55/75 groups (73%) ...
GRPO's advantage is reward minus the group mean, so a group where every sample scores the same contributes
exactly nothing. ~73% of the compute produced no gradient at all. This is the within-group reward collapse
described by
RC-GRPO (arXiv:2602.03025) , and it is a direct
consequence of the SFT model already being good: most prompts come back all-right (or all-wrong) across the
whole group.
The DPO run independently measured the same thing from a different angle — 289 of 400 prompts (72%) were
already correct and yielded no preference pair. Two unrelated experiments, the same ~72%.
Two consequences worth carrying forward:
Raising exploration helps. Going to 8 generations at temperature 1.15 lifted the observed rate from
+0.0033 to roughly +0.0165 per 100 steps. Sampling is raised for training only ; evaluation and the
shipped model remain strictly greedy, so this changes learning rather than the reported metric.
Step count is a poor proxy for progress. Only ~27% of steps do anything, so "N steps" should be read
as "~0.27N effective steps" when planning a budget.
DPO — also tried, also did not beat SFT
TinyLLM (arXiv:2511.22138) benchmarks sub-3B models on exactly this task
family and recommends preference optimization over RL for compute-constrained settings ("SFT offers limited
gains"; PPO is "computationally demanding — less ideal for edge deployment"). So DPO was tried, with preference
pairs built free from the model's own errors (chosen = gold call, rejected = what the model emitted).
Measured: val args_exact 0.7367 → 0.7333 . Not an improvement, so no test pass was spent and nothing
was published.
Two findings worth recording, both of which make DPO less attractive here than the literature implies:
Pair generation dominates the cost. 400 prompts took 21.5 min of generation on a T4; DPO training
itself then took 6.9 min. DPO needs no generation during training, but building the dataset is expensive.
Yield is low precisely because the SFT model is good. 289 of 400 training prompts (72%) were *already
correct* and produce no pair. Only 111 usable pairs came out — far too few to move a 1B model. Collecting
thousands of pairs means an hour or more of generation before a single training step.
Summary of every method tried
method val args_exact outcome v2 (previous release) — test 0.6133 base model (no adapter, untrained) — test 0.6300 v2 = SFT (2 independent runs)0.7367 superseded by v3 SFT + composite oversampling 0.7367 no change thinking-on 0.6167 / 0.5267 clearly worse GRPO, lr 2e-5 / β 0.01 0.6867 worse — too aggressive GRPO, lr 5e-6 / β 0.04, 4 gen @ T=1.0 0.7467 better, then stalled (73% dead groups) GRPO, lr 5e-6 / β 0.04, 8 gen @ T=1.15 0.7533 published (test 0.7467)DPO, 111 pairs 0.7333 worse constrained / grammar-guided decoding not run ruled out on evidence — see below self-consistency / majority voting not run ruled out by ToolPRM
Constrained decoding was considered and rejected before spending GPU time on it. Grammar-constrained
decoding improves function calling mainly by eliminating malformed calls, but this model is already at
parseable 1.0000 and valid_name 0.9867 — there are essentially none left to eliminate. Its failures are
semantic (wrong argument values ), which schema constraints do not fix. Two 2026 results also warn it can
output constraints suppress tool calling, and
The Format Tax (arXiv:2604.03616) finds format constraints degrade the reasoning the model would otherwise do.
The remaining gap to 0.80 is 0.0533 (16 test examples) against a hard ceiling of 0.9067. GRPO is the only lever
that has moved it, and its effective rate depends far more on how many groups produce a non-zero advantage than
on raw step count.
A bug worth knowing about
The first long GRPO attempt died ~2.9h in inside the reward function:
schema_literal_fix → if v.lower() == ev.lower()
AttributeError: 'int' object has no attribute 'lower'
Tool schemas may declare non-string enums ("enum": [1, 2, 3]); the value was type-guarded but the enum
member was not. The 300-row eval slices contain no integer enum, so this never surfaced in any evaluation — it
took a 3000-row training pool to hit it. Fixed by comparing against str(ev) (for string enums str(ev) is ev,
so no previously measured number changes), with a regression assert that now fails in seconds on CPU rather than
hours into a GPU run.
Split integrity
ToolACE's data.json is grouped, not shuffled — contiguous slices land on very different distributions, so a
naive select(range(...)) split yields train/test sets that are not comparable. The dataset is therefore shuffled
with a fixed seed (SPLIT_SEED = 3407) and filtered to usable rows before slicing into test / validation / train.
Checkpoints were selected on validation only ; the test slice was evaluated once, at the end.
Training configuration
base openbmb/MiniCPM5-1B, 4-bitLoRA r=32, alpha=64, dropout=0.05 target modules q, k, v, o, gate, up, down epochs 3 learning rate 1e-4, cosine, warmup ratio 0.1 batch size 16 max seq len 4096 (prompt cap 1536) train / val / test 9000 / 300 / 300 hardware 1× Kaggle T4
Usage
1
2 from peft import PeftModel
3
4 from transformers import AutoModelForCausalLM , AutoTokenizer
5
6 base = "openbmb/MiniCPM5-1B"
7
8 tok = AutoTokenizer . from_pretrained ( base , trust_remote_code = True )
9
10 model = AutoModelForCausalLM . from_pretrained ( base , trust_remote_code = True , device_map = "auto" )
11
12 model = PeftModel . from_pretrained ( model , "ewinregirgojr/MiniCPM5-1B-Agentic-Tooluse" )
13
14 prompt = tok . apply_chat_template (
15
16 messages , tools = tools , add_generation_prompt = True ,
17
18 enable_thinking = False , # thinking OFF — see "What did not work"
19
20 tokenize = False ,
21
22 )
23
24 inputs = tok ( prompt , return_tensors = "pt" ) . to ( model . device )
25
26 out = model . generate ( ** inputs , max_new_tokens = 256 , do_sample = False ) # greedy
27
enable_thinking=False and greedy decoding are both load-bearing for the numbers above.
Framework versions
PEFT 0.19.1
transformers 4.57.3
torch 2.8.0
TRL 0.24.x, Unsloth
Base model architecture
MiniCPM5-1B uses a standard LlamaForCausalLM architecture:
Property Value Parameters (total) 1,080,632,832 Parameters (non-embedding) 679,552,512 Architecture LlamaForCausalLMLayers 24 Attention heads (GQA) 16 Q / 2 KV Context length 131,072 tokens Training SFT → RL (GRPO) fine-tune on openbmb/MiniCPM5-1B
Limitations
ModelScope
The base model is also available on ModelScope (for users in China and East Asia):
(The fine-tuned adapter/GGUF builds are currently HuggingFace-only.)
Citation
If you use this model, please cite the base model paper:
1 @article{minicpm4,
2 title = {MiniCPM4: Ultra-Efficient LLMs on End Devices},
3 author = {MiniCPM Team},
4 journal = {arXiv preprint arXiv:2506.07900},
5 year = {2025}
6 }
And the ToolACE dataset used for fine-tuning:
1 @article{toolace,
2 title = {ToolACE: Winning the Points of LLM Function Calling},
3 author = {Liu, Ying and others},
4 journal = {arXiv preprint arXiv:2409.00920},
5 year = {2024}
6 }
