MiniCPM5-2B and MiniCPM5-1B: what OpenBMB's on-device models actually ship with

What MiniCPM5 is for, and what it is not

MiniCPM is a family of dense Transformer language models from OpenBMB, released in successive series: MiniCPM, MiniCPM3, MiniCPM4, MiniCPM4.1, MiniCPM-SALA, and now MiniCPM5. The README describes the current release as MiniCPM5-2B, "a dense 2B Transformer that scales up the same training recipe," following MiniCPM5-1B. Both are positioned for on-device, local deployment and resource-constrained scenarios.

The intended user is someone who wants a language model on hardware they control, or on hardware where a 7B or 8B model will not fit. The 1B and 2B sizes are the point: they are small enough to be a realistic local target. OpenBMB claims 2B-class open-source SOTA for MiniCPM5-2B within its comparison set, and says it remains competitive with 4B-class models overall while showing advantages over comparable-size models in coding, mathematics, long-context understanding, tool use and agentic tasks. Those are the project's own claims, illustrated by a radar chart in the repository assets; treat the chart as marketing until you reproduce it on your own workload.

What MiniCPM is not, in this repository, is a multimodal model. The README links out to a separate MiniCPM-V repository for that, and the older MiniCPM-V inference dependencies (Pillow, timm, sentencepiece) sit in requirements.txt rather than in anything the 5-series uses. If you arrived looking for image input, this is the wrong repository.

How the 5-series is packaged and what the repository actually contains

The weights are not in the Git repository. Model Downloads lists MiniCPM5-2B and MiniCPM5-1B as available in BF16, GGUF and MLX on both HuggingFace and ModelScope, and the 2B line has five published variants: MiniCPM5-2B, MiniCPM5-2B-SFT, MiniCPM5-2B-Midtrain, MiniCPM5-2B-Base, MiniCPM5-2B-GGUF and MiniCPM5-2B-MLX. That spread matters when you pick a download: Base and Midtrain are training-stage checkpoints, not the instruction-tuned artifact most people want.

The repository itself is a hub rather than a single runnable package. Top-level entries include docs/, finetune/, quantize/, skills/, tool_parsers/, demo/, minicpm_sala/ and a requirements.txt. The layout tells you where things live: deployment and fine-tuning instructions are split by engine under docs/deployment/ and docs/finetune/, and skills/ holds what the changelog calls "deployment / fine-tuning Agent Skills" shipped alongside each 5-series release.

That split is the central design decision, and it has a cost. Because vLLM, SGLang, transformers, llama.cpp, MLX, Ollama and LM Studio each support a different version range, the project refuses to pin one stack for the 5-series. The README does not document a single canonical install path, and requirements.txt says so explicitly in its own comments. You get accuracy per engine and no single command that works everywhere.

Installing MiniCPM5-1B: what the repository does and does not give you

There is no top-level install command for the 5-series. The repository's requirements.txt opens with a comment stating that for MiniCPM5-1B the install commands live with each backend and framework cookbook under docs/deployment/ and docs/finetune/, and that the file "pins the legacy stack that still works for the older MiniCPM 1B / 2B series." Installing from requirements.txt is therefore a step backwards, not a first step.

What the file does contain is the legacy inference stack. If you are working with the older MiniCPM-2B models, the documented path is:

pip install -r requirements.txt

That pulls torch>=2.0.0, transformers>=4.36.2 and gradio>=4.26.0 for HuggingFace inference, plus openai>=1.17.1, tiktoken and loguru for the OpenAI-compatible API path. vLLM is present only as a commented line, vllm>=0.4.0.post1, which tells you the pin is optional and version-sensitive rather than enforced.

For the 5-series, the honest first step is to open the cookbook for your chosen engine under docs/deployment/ and follow it there, then download the matching weights from HuggingFace or ModelScope. The README gives the model names but not the commands. If you want a first real use, the repository's demo/ directory holds per-generation demos (demo/minicpm/, demo/minicpm3/, demo/minicpm4/), but the README does not state that a MiniCPM5 demo directory exists, so do not assume one.

A practical consequence: the first thing to check before committing to MiniCPM5 is whether your engine appears in the cookbook list. If it does not, you are on your own with the raw weights.

The maintenance picture and the upgrade path you will not find documented

The repository is not archived, and the last push was on 2026-09-10. The changelog shows a steady cadence: MiniCPM5-2B on 2026.09.07, MiniCPM5-1B on 2026.05.19, MiniCPM-SALA on 2026.02.11, MiniCPM4.1 on 2025.09.05, MiniCPM4 on 2025.06.06. Releases exist for 5.0 (MiniCPM5-1B) and 2.4.2, the latter labelled in the release list as the first release version. This is a project that ships often.

Shipping often is also the upgrade problem. The changelog carries a long tail of older entries behind a collapsed section, and the README routes legacy material to a separate docs/README-legacy.md covering BitCPM4 quantization and MiniCPM4 applications. Series names change meaning across releases: MiniCPM4 was described as an end-side model with generation acceleration on edge chips, MiniCPM4.1 as a sparse-attention model with hybrid reasoning, MiniCPM-SALA as a sparse-and-linear hybrid attention model for million-token context. MiniCPM5 is dense. If you built on the sparse line, MiniCPM5 is not a drop-in successor.

The README does not document a migration or rollback procedure between series. There is no stated deprecation policy for older checkpoints. Anyone pinning a MiniCPM model in production should pin the exact model identifier and the engine version together, because the cookbook split exists precisely because those version ranges move independently.

Where MiniCPM5 is the wrong choice

The clearest failure mode is expecting this repository to be a turnkey runtime. It is a collection of models, cookbooks and skills. There is no CLI in the top-level layout, no server entry point described in the README, and no single dependency set for the current generation. If your team's adoption criterion is "one install command, one supported serving stack," MiniCPM5 does not meet it today.

Second, the size claim needs reading carefully. The README says MiniCPM5-2B is competitive with 4B-class models overall. That is a claim about aggregate benchmark position, not a guarantee on your task. Coding, mathematics, long-context and agentic tasks are named as areas of relative advantage; nothing in the README claims the model matches larger models on general knowledge breadth, and a 2B dense model has a hard capacity ceiling regardless of training recipe.

Third, the data release does not transfer automatically. UltraX, UltraData-Code, UltraData-SFT-Agent-2609 and UltraData-RL-2609 are published as datasets, not as a fine-tuning pipeline. Using them means building your own training loop, and the README does not describe one for them.

Finally, if you need vision or omni-modal input, this is the wrong repository by design. The README points to MiniCPM-V, and the MiniCPM-V dependencies in requirements.txt belong to that separate line.

MiniCPM5-2B against Qwen and Gemma at the same size

The natural comparison is with other small dense open models, and the search data around this project is full of it. The difference that matters is not benchmark position, which the README asserts and you should verify yourself, but packaging and deployment surface.

Qwen and Gemma both ship small dense models with their own official inference paths and their own quantisation releases. MiniCPM5's distinguishing choice is the cookbook split: instead of one blessed stack, it documents vLLM, SGLang, transformers, llama.cpp, MLX, Ollama and LM Studio separately, each with its own supported version range, and publishes GGUF and MLX builds alongside BF16. If you are targeting Apple silicon, the MLX build is a first-class artifact here rather than an afterthought. If you are targeting a llama.cpp-based local runner, the GGUF build is published on both HuggingFace and ModelScope, which matters if you are working from a network where ModelScope is the reachable mirror.

The trade is support surface. A model with one official path gives you one thing to debug; MiniCPM5 gives you seven documented paths and no stated preference among them. That is good for reach and bad for anyone who wants the project to make the decision. Note also that the README does not document which quantisation levels exist in the GGUF or MLX repositories; you have to check the model card for that.

Licence and what Apache-2.0 does and does not settle

The repository is licensed Apache-2.0. That covers the code, the cookbooks, the skills and the tool parsers in this repository. It does not by itself tell you the terms attached to each weight file, because the weights live on HuggingFace and ModelScope under their own model cards, and the README does not restate those terms. The distinction matters: you can vendor the repository's Apache-2.0 code without ambiguity, but you should read the licence field on the specific checkpoint you download before shipping it.

The training datasets are a third case again. UltraX, UltraData-Code, UltraData-SFT-Agent-2609 and UltraData-RL-2609 are separate published artifacts with their own terms, and the README does not describe them here. None of this is legal advice; it is the set of places where you need to look before you assume Apache-2.0 travels with everything carrying the MiniCPM name.

Editorial conclusion

Adopt MiniCPM5 if you need a small dense model you can run locally and you are willing to assemble the install yourself from the per-engine cookbooks under docs/deployment/ and docs/finetune/; the repository's requirements.txt pins the older MiniCPM 1B / 2B stack and will not set up the 5-series for you. Skip it if you need a single supported inference path, a documented upgrade procedure, or a vision model, since this repository points to MiniCPM-V for that. Verify first that the specific backend you plan to use appears in the cookbook list, and check the model card for the variant you download, because the README does not state which quantisation levels exist for each format.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. OpenBMB/MiniCPM on GitHub
4. README
5. Releases