GLM-5.2 is live. #1 throughput on OpenRouter, pay-per-token on FriendliAI. Try it today ➜
ewinregirgojr
Available on FriendliAI
Run this model inference on single tenant GPU with unmatched speed and reliability at scale.
Run this model inference with full control and performance in your environment.
Model Details
Model Provider
ewinregirgojr
Model Tree
openbmb/MiniCPM5-1B
Input Modalities
Output Modalities
Supported Functionality
Tiny footprint, real accuracy. 1B parameters total, LoRA adapter itself is under 100MB — deployable anywhere a 7B+ model can't go: mobile apps, browser extensions, IoT/embedded agents, offline assistants, cost-sensitive high-throughput API backends.
Purpose-built for agentic tool use. Trained specifically to parse a tool/function schema plus a natural-language user request and emit a correctly-named, correctly-structured, correctly-valued function call — the core skill every LLM agent framework (LangChain, LlamaIndex, AutoGen, CrewAI, custom ReAct loops, MCP servers) depends on.
Two-stage training pipeline: QLoRA SFT + GRPO reinforcement learning. Most open tool-calling fine-tunes stop at supervised fine-tuning. This adapter goes a step further with GRPO (Group Relative Policy Optimization) reinforcement learning on top of the SFT checkpoint, specifically rewarding exact function-name selection and exact argument-value correctness — the two hardest, most failure-prone parts of tool calling for small models.
Honestly measured, not marketing numbers. Every metric below comes from one single evaluation harness run end-to-end on a locked, held-out 300-example test split — same parser, same grader, same slice, for the base model, the SFT model, and this GRPO-refined v3 model. No cherry-picked runs, no mixed benchmarks.
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 call | 0.9933 | 1.0000 | 1.0000 |
valid_name — name exists among the offered tools | 0.9700 | 0.9867 | 0.9867 |
expected_name — name matches gold | 0.9067 | 0.9567 |
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.
This table mirrors the evaluation format from v2 and shows Base, v2, and v3 side-by-side across all 8 metrics using a single consistent harness and held-out test slice:
| Metric | Base MiniCPM5-1B | v2 (previous release) | v3 (this model) | Delta (v2 → v3) |
|---|---|---|---|---|
| parseable_rate | 0.0133 | 0.9933 | 1.0000 | +0.0067 |
| valid_name_rate | 0.0133 | 0.9700 | 0.9867 | +0.0167 |
| expected_name_rate | 0.0133 | 0.9267 | 0.9533 | +0.0267 |
What the additional metrics mean:
no_schema_copy_rate — the model did not copy the tool schema's own field description
verbatim into an argument value.no_repetition_rate — the completion did not contain a duplicated function-call block or
degenerate repeated-phrase loop. This model has a known weakness here: it often continues
generating filler content after the tool call completes. Use a parser that extracts the first
completed <function>...</function> block.stopped_cleanly_rate — the model naturally stopped immediately after the completed
</function> tag with no trailing tokens. Use a parser that treats the first completed
<function>...</function> block as the action boundary — do not rely on natural end-of-generation.Base model: openbmb/MiniCPM5-1B — a compact, efficient, Llama-architecture 1B-parameter language model from OpenBMB, ideal for resource-constrained inference, edge computing, and low-latency serving.
Adapter type: LoRA (Low-Rank Adaptation) via PEFT, rank r=32, alpha=64, dropout=0.05
Target modules: q_proj, k_proj, v_proj, o_proj, gate_proj, up_proj, down_proj (full attention + MLP coverage)
python
from transformers import AutoModelForCausalLM, AutoTokenizerfrom peft import PeftModelbase = AutoModelForCausalLM.from_pretrained("openbmb/MiniCPM5-1B")tok = AutoTokenizer.from_pretrained("openbmb/MiniCPM5-1B")model = PeftModel.from_pretrained(base, "ewinregirgojr/MiniCPM5-1B-Agentic-Tooluse-QLoRA-v3")# Use tok.apply_chat_template(..., tools=[...]) with your function/tool schema,# then generate as usual — the model emits a structured function call.
Prefer not to deal with adapter loading, or want a single-file local build? See the related repos below for a merged full-weight checkpoint and quantized GGUF files for llama.cpp / Ollama / LM Studio.
Local, private, offline AI agents that need to call tools/APIs without sending data to a cloud LLM provider
Home automation and smart-home assistants (small enough to run on a Raspberry Pi-class device or a home server)
Mobile and embedded applications where a 7B+ model is impractical
High-throughput, cost-sensitive backend services orchestrating many tool calls per request
Any LangChain / LlamaIndex / AutoGen / MCP-based agent that needs a cheap, fast, locally-hostable function-calling backbone
Research and experimentation on small-model reasoning, LoRA fine-tuning, and RL-based (GRPO) post-training for structured generation
MiniCPM5-1B uses a standard LlamaForCausalLM architecture:
| Property | Value |
|---|---|
| Parameters (total) | 1,080,632,832 |
| Parameters (non-embedding) | 679,552,512 |
| Architecture | LlamaForCausalLM |
| Layers | 24 |
| Attention heads (GQA) | 16 Q / 2 KV |
| Context length | 131,072 tokens |
| Training | SFT → RL (GRPO) fine-tune on openbmb/MiniCPM5-1B |
MiniCPM5-1B has a built-in <think>...</think> chat template. The same checkpoint can act as a fast assistant or a deliberate chain-of-thought reasoner — controlled by a single flag:
python
# Fast mode — recommended for tool calling (thinking OFF)prompt = tokenizer.apply_chat_template(messages, tools=tools, add_generation_prompt=True,enable_thinking=False,tokenize=False,)# Reasoning mode (thinking ON — NOT recommended for tool calling)prompt = tokenizer.apply_chat_template(messages, tools=tools, add_generation_prompt=True,enable_thinking=True,tokenize=False,)
Important: always use
enable_thinking=Falsefor tool/function calling. With thinking ON the model spends its token budget inside<think>...</think>and may not reach a completed function call. All benchmark numbers in this card use thinking OFF.
If you use this model, please cite the base model paper:
bibtex
@article{minicpm4,title = {MiniCPM4: Ultra-Efficient LLMs on End Devices},author = {MiniCPM Team},journal = {arXiv preprint arXiv:2506.07900},year = {2025}}
And the ToolACE dataset used for fine-tuning:
bibtex
@article{toolace,title = {ToolACE: Winning the Points of LLM Function Calling},author = {Liu, Ying and others},journal = {arXiv preprint arXiv:2409.00920},year = {2024}}
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.)
| Format | Repository |
|---|---|
| LoRA adapter (PEFT, smallest download, fine-tune further) | MiniCPM5-1B-Agentic-Tooluse-QLoRA-v3 |
| Merged full-weight FP16 (transformers / vLLM / SGLang serving) | MiniCPM5-1B-Agentic-Tooluse-v3-Merged-FP16 |
| GGUF quantizations (llama.cpp / Ollama / LM Studio, CPU-friendly) | MiniCPM5-1B-Agentic-Tooluse-v3-GGUF |
| Format | Repository |
|---|---|
| v2 LoRA adapter | MiniCPM5-1B-Agentic-Tooluse-QLoRA-v2 |
| v2 Merged FP16 | MiniCPM5-1B-Agentic-Tooluse-Merged-FP16 |
| v2 GGUF | MiniCPM5-1B-Agentic-Tooluse-GGUF |
Is this a full model or an adapter? This repo is a LoRA adapter — small, fast to download, must be loaded on top of the base MiniCPM5-1B model via PEFT. If you want a single ready-to-serve checkpoint, use the Merged-FP16 or GGUF repos linked above instead.
Can I run this on CPU / a laptop / a phone? Yes — the whole point of a 1B-parameter model is that it's small enough for CPU inference, laptops, and (via the GGUF quantized builds) even lower-power edge devices.
How does this compare to using GPT-4o / Claude for function calling? This model trades some absolute accuracy for massive gains in cost, latency, privacy, and deployability — you get a locally-hostable, fine-tunable, fully open-weight alternative for agentic tool-use workloads where sending every request to a large hosted API isn't practical or affordable.
What license is this under? Apache 2.0, matching the base model.
Built on MiniCPM5-1B by OpenBMB.
| 0.9533 |
args_exact — every argument value matches gold | 0.6133 | 0.7367 | 0.7467 |
arg_key_overlap — F1 over argument keys | 0.8757 | 0.9422 | 0.9388 |
| mean of 5 | 0.8718 | 0.9245 | 0.9251 |
| args_exact_rate | 0.1500 | 0.6533 | 0.7467 | +0.0934 |
| arg_key_overlap | 0.0033 | 0.7517 | 0.9388 | +0.1871 |
| no_schema_copy_rate | 1.0000 | 1.0000 | 0.9967 | -0.0033 |
| no_repetition_rate | 0.9967 | 1.0000 | 0.3400 | -0.6600 |
| stopped_cleanly_rate | 0.0000 | 0.1500 | 0.0000 | -0.1500 |
Training pipeline: QLoRA supervised fine-tuning on tool-calling / function-calling trajectories → GRPO reinforcement-learning refinement optimizing for exact argument correctness
Format: safetensors, peft library compatible