MiniCPM5-2B: a 2B open model that runs on-device and beats bigger ones

What MiniCPM5-2B actually is

MiniCPM5-2B is the second model in the MiniCPM5 line from OpenBMB (the open-model group also known as ModelBest), released around September 6-7, 2026, following MiniCPM5-1B in May. The pitch is narrow and clear: a small dense model that is good enough at reasoning, coding, and tool use to be useful, and small enough to run where the data already lives.

That "where the data lives" part is the interesting bit. Most of the models you read about this year are cloud-hosted APIs you rent by the token. MiniCPM5-2B goes the other way: you download the weights and run them on a laptop, a phone, or a Rockchip board on a factory floor. The HuggingFace model card describes it as a dense 2B model "built for on-device, local deployment, and resource-constrained scenarios," aimed at "local assistants, coding agents, tool-use workflows, and reasoning scenarios where a compact model is preferred."

Here is the model's own page, which is where you would actually start if you wanted to pull it.

One honest limitation to set expectations: this is a text-only model. There is no vision or audio in this checkpoint, and community testers note it handles English and Chinese only. If you need multimodal, OpenBMB keeps that in the separate MiniCPM-V line, and the "no vision here" reaction was one of the loudest notes at launch (more on that below).

The specs that matter

For a 2B model, the spec sheet is where the surprises are. It runs a plain LlamaForCausalLM architecture, carries a full 128K context, and ships under a genuinely permissive license.

Every number there comes from the model card's "Model Information" block. Two of them do more work than the rest.

The first is that standard architecture. OpenBMB made a point of building MiniCPM5-2B on plain LlamaForCausalLM so that, in their words, "mainstream inference engines can load it directly: no custom kernels, no model-code fork." That sounds like a footnote, but it is why the day-0 runtime support (below) is as broad as it is. A model that needs a bespoke kernel ships to two runtimes on launch day; a standard-arch model shows up everywhere at once.

The second is the Apache-2.0 license on both the repo and the weights. Commercial use is permitted, and there is no separate community license gating it, which is not something every "open" release can say. If you are building a product on top, that matters more than a benchmark point or two.

It also has a proper deep-reasoning mode: the transformers example passes enable_thinking=True, and OpenBMB frames a task's token budget as roughly 21K tokens (14K thinking plus 7K answer), with recommended sampling of temperature=1.0, top_p=0.95.

How it scores

Here is the headline that got MiniCPM5-2B noticed: on OpenBMB's evaluation, it averages 53.9 across 34 benchmarks, which they present as 2B-class open-source state of the art and, in their comparison set, ahead of the top 4B-class model Qwen3.5-4B at 51.1. A 2B model edging out a 4B one is the kind of claim that earns a second look.

The radar shows where the size-to-score story holds and where it does not. MiniCPM5-2B leads on agentic and search tasks and stays competitive on math and long context, while the 4B Qwen model still wins on raw coding-agent work. It is a spiky profile, not a uniform lead, which is the honest way to read it.

The full table is worth a slow look, because "average 53.9" hides some genuinely large individual numbers:

The standouts, all from that table: MATH-500 at 94.6, AIME 2026 at 86.5, LiveCodeBench v6 at 69.1, SWE-bench Verified at 46.4, τ²-Bench Telecom at 97.1, and GAIA Text-103 at 88.7. On general knowledge it posts MMLU-Pro 70.8. For a model you can run on a laptop, those coding and tool-use figures are the ones that make builders sit up.

Two caveats keep this honest. First, these are OpenBMB's own reported numbers (some rows are reproduced internally, some pulled from the official Artificial Analysis release), so treat them as a strong starting point and test on your own tasks rather than as an independent verdict. Second, one headline figure disagrees with itself across sources: the r/LocalLLaMA release thread and dataconomy both report an Artificial Analysis Intelligence Index of 15, "the highest of any open weights model at 4B parameters or below," while OpenBMB's own launch post claims a score of 23 plus a 20 on the Agentic Index. I cannot reconcile those two, so both are on the record here. And note what is missing: OpenBMB does not publish classic MMLU, GSM8K, or HumanEval for this model, so if you were hoping to line it up against older leaderboards, those numbers do not exist in the official sources.

How OpenBMB trained it

The other reason MiniCPM5-2B is interesting is that OpenBMB open-sourced most of the recipe, not just the weights. If you care about how a small model gets this capable, the pipeline is the answer.

It runs in three stages, described on the model card. Base training uses OpenBMB's Ultra-FineWeb and related UltraData datasets. Mid-training adapts the model to its target capabilities. Then post-training does the heavy lifting: 400B tokens of deep-thinking SFT, reinforcement learning with specialized teachers for math, code, agentic, and writing tasks (using the critic-based JustRL II algorithm), and finally On-Policy Distillation that merges 16 expert models into the single release checkpoint.

OpenBMB reports that the RL-plus-OPD stage alone added 10.96 points on reasoning and general benchmarks and 6.96 points on agentic tasks. Whether or not you reproduce those gains, publishing the datasets and the RL framework is the kind of move that makes the open-model community pay attention, because it is repeatable rather than a black box.

Running it on the edge

The whole reason a 2B model exists is to run somewhere a 200B model cannot. So the question for MiniCPM5-2B is less "how smart is it" and more "what does running it locally actually buy you."

The trade is real in both directions. Run it on-device and your data never leaves the machine, it works with no connectivity, and there is no per-token bill: for privacy-sensitive or offline work, that combination is hard to beat. Give up the cloud and you also give up the raw capability ceiling of a frontier model. MiniCPM5-2B is betting that for a growing set of tasks, a small local model that is "good enough" and private beats a huge remote one you have to trust with your data.

The practical side holds up. A community listing puts the GGUF build at about 1.6 GB (a third-party figure, not an official one), and OpenBMB reshared a demo of it running on a 16 GB MacBook doing on-device web search. It was also day-0 adapted for Intel Core Ultra with OpenVINO, Arm v9 with SME2 (where it reports roughly 1.7x higher prefill and 1.2x higher decode), and Rockchip's RK3588 and RK1828 boards.

That standard-architecture decision from earlier pays off here. The same checkpoint loads into a wide spread of runtimes on launch day, rather than trickling out to one or two.

Per the model card's deployment table, it runs on transformers, vLLM, SGLang, llama.cpp, Ollama, LM Studio, MLX for Apple Silicon, and FlagOS, which adapts it to nine different AI chips. For tool calling, SGLang is the recommended backend: the model emits XML-style tool calls and SGLang's built-in minicpm5 parser converts them into OpenAI-compatible tool_calls. There is even a DSpark draft model for speculative decoding if you want to squeeze more speed out without changing outputs.

What the community is saying

Reactions at launch clustered into two camps, and both are useful signal.

The first is straightforward enthusiasm about the size-to-capability ratio. The official launch post cleared 2,200 likes in a day, and one tester reported running 32 concurrent subagents on a single DGX Spark at 931 tokens per second average, peaking at 1,364. For a locally-hosted 2B model, that throughput is the kind of thing that makes people want to build with it.

The second camp is more skeptical, and worth listening to precisely because it is not the marketing. The loudest recurring complaint was the missing vision support:

"Sad that there is no vision though."

r/LocalLLaMA, MiniCPM5-2B Release Day

And some developers pushed back on whether the benchmark scores translate to real work, especially in coding harnesses:

"you get some likes here, but useful code? I don't think so"

michabbb, X

That gap, between a strong benchmark row and behaving well inside a real agent loop, is exactly the thing you cannot read off a spec sheet. It is also the thing that matters most the moment you try to put any model to work on real tasks.

An open model is an engine, not an employee

Here is the reframe worth leaving with, and it is the part builders and buyers most often skip. MiniCPM5-2B is a great engine. It is not, by itself, a worker. Downloading a strong open-weight model is the start of a project, not the end of one, and the gap between the two is bigger than the model.

I work on eesel's AI, and this is the distinction we live in every day. We have spent years putting AI agents on live support queues, and the recurring lesson is that raw model quality is rarely the thing that decides whether a rollout succeeds. What decides it is everything wrapped around the model.

Take customer support as the concrete case. To turn a model like MiniCPM5-2B into something that can answer a real ticket, you have to feed it your company's actual knowledge, wire it into the helpdesk and the tools it needs to act, add guardrails so it escalates instead of guessing, and test it against real past conversations before it ever touches a live customer. That last part is where we have watched confident-sounding bots quietly give wrong answers, which is why we now simulate every rollout against historical tickets before it goes live. The model is maybe 20% of that. The other 80% is the boring, essential scaffolding, and it does not come in the download.

That is not an argument against open models. It is an argument for being clear about what you are holding. MiniCPM5-2B is a genuinely good compact engine to build with. If the thing you are trying to build is a support agent, though, you can either assemble that whole 80% yourself or hire it ready-made.

Try eesel

If your actual goal is to answer customer questions rather than to run a model, that is exactly the problem eesel exists to solve. eesel hires a ready-to-work AI helpdesk teammate onto your existing queue: it learns from your past tickets and help center, plugs into tools like Zendesk, Freshdesk, and Slack in minutes, and, crucially, simulates against your real historical tickets so you can see how it will behave before it answers anyone live.

And if you like operating close to the metal, the way you would with a local model, eesel has a public CLI plus an MCP server, so the same teammate you configure in the dashboard can be driven from a terminal, automated in scripts, or handed to a coding agent like Claude Code or Cursor. You get the ready-made worker and the programmable surface, without having to build the 80% yourself. It is free to try.