MiniCPM5-2B

MiniCPM5-2B is a dense 2.52B parameter text model from OpenBMB, the second release in the MiniCPM5 series after MiniCPM5-1B. It is a LlamaForCausalLM architecture with 42 layers, a 131,072 token context window, and an Apache-2.0 license. No gated access, no commercial restrictions, no per-token billing.

The model's reason for existing is straightforward: it targets the 2B parameter class, where memory footprint and inference cost matter more than raw capability ceiling. OpenBMB scaled up the training recipe from MiniCPM5-1B and reports 2B-class open-source SOTA, with the model remaining competitive against 4B-class alternatives. Artificial Analysis measured it at 15 on the Intelligence Index v4.2, the highest score recorded for any open-weights model under 4B total parameters at release, four points clear of Granite 4.2 3B and level with Qwen3.5 9B (Reasoning).

The practical implication is that MiniCPM5-2B occupies a narrow but useful slot: small enough to run on a laptop or a single consumer GPU with room to spare, capable enough for tool-calling loops, code completion, and long-document reasoning. It is not a replacement for a 30B model on hard reasoning tasks. It is a model you can run continuously in the background of a development machine without noticing it.

MiniCPM5-2B is fully dense, every one of the 2.52B parameters is active on every forward pass. There is no mixture-of-experts routing, no sparse activation, and therefore no variance in compute per token. For local deployment this is a feature, not a limitation: dense models have predictable VRAM usage and predictable latency, and they avoid the expert-loading behavior that makes MoE models awkward on memory-constrained hardware.

The tradeoff is that dense models spend more compute per token than an equivalently-sized MoE. At 2.52B parameters that cost is small enough that it rarely matters on modern hardware.

The 131,072 token context window is the headline spec. It is roughly 100,000 words of English, or a mid-sized codebase, or several hours of transcript. Long-context support at this size is unusual, most 2B-class models ship with 8K to 32K windows. Note that the KV cache, not the weights, becomes the dominant memory consumer at long context. If you plan to actually use 131K tokens, budget for KV cache quantization and verify your runtime supports it.

OpenBMB publishes the model in several formats beyond BF16 weights: GGUF for llama.cpp, Ollama and LM Studio; MLX 4-bit for Apple Silicon; GPTQ 4-bit; and LiteRT. There is also a DSpark draft model for speculative decoding, plus intermediate checkpoints (Base, Midtrain, SFT) if you intend to fine-tune.

Training data comes from OpenBMB's UltraData family, including UltraData-Code with L0–L3 tiered code data management, UltraData-SFT-Agent-2609 (500K agent samples), and UltraData-RL-2609 (80K+ RL samples). The model is trained on English and Chinese.

The capability set is broad for the size: chat, code, reasoning, function-calling, math, and instruction-following. The areas where it measurably separates from same-size peers are coding, mathematics, long-context understanding, and agentic tool use.

Agentic tool calling. This is where the model is strongest relative to its class. It scores an Elo of 831 on GDPval-AA v2, leading all sub-4B models, and ties Ling 3.0 Tiny at 21% on τ³-Banking, versus 8% for the next best model in that comparison. Concrete use: a local agent that reads files, calls shell commands, and queries APIs in a loop, running on the same machine as your editor.

Code. The UltraData-Code pipeline is visible in the output. It handles completion, refactoring, test generation, and explanation tasks in Python, JavaScript, and other mainstream languages. It is not a substitute for a frontier coding model on large multi-file architectural changes, but it is fast enough to run inline as you type.

Long-context document work. Summarization, extraction, and Q&A over long PDFs, logs, or transcripts. The 131K window means you can often skip chunking and retrieval entirely for single-document tasks.

Math and structured reasoning. Step-by-step arithmetic, word problems, and structured extraction. Reliable for routine work; expect degradation on competition-level problems.

Bilingual chat. English and Chinese are both first-class.

Approximate weight memory, excluding KV cache:

• BF16~5.0 GB
• Q8_0~2.7 GB
• Q5_K_M~1.9 GB
• Q4_K_M~1.6 GB
• Q3_K_M~1.3 GB

Add KV cache on top. At short contexts (4K–8K) that is a few hundred MB. At 131K it is the larger number, which is why KV cache quantization matters if you intend to use the full window.

• 8 GB GPU (RTX 4060, RTX 3070)comfortable at Q4_K_M with 32K context.
• 12–16 GB GPU (RTX 4070, RTX 4080)Q8_0 or BF16 with long context.
• 24 GB GPU (RTX 4090, RTX 3090)BF16 at full 131K context, or heavy batching.
• Apple Silicon (M4 Max, M3 Pro, M2 with 16 GB+)use the MLX 4-bit build; unified memory makes long context cheap.
• CPU-onlyviable at Q3/Q4 on modern desktop CPUs, but slow. Older dual-core laptop chips will run it, just not at conversational speed.

Q4_K_M is the right default for most users, roughly 1.6 GB of weights with minimal quality loss on chat, code, and tool-calling tasks. Step up to Q5_K_M or Q8_0 if you have headroom and are doing math or long-context work where small degradations compound. Q3 is a last resort for 4 GB devices.

At Q4_K_M: roughly 150–250 tokens/sec on an RTX 4090, 80–150 tokens/sec on an M4 Max via MLX, 40–80 tokens/sec on an RTX 4060, and single-digit to low-double-digit tokens/sec on CPU-only inference. Prompt processing at long context is the bottleneck, not generation.

The GGUF build targets llama.cpp, Ollama, and LM Studio. Ollama is the fastest path: import the GGUF via a Modelfile or pull it from the Ollama library if available, then ollama run. For Apple Silicon, the MLX 4-bit build is meaningfully faster than GGUF through llama.cpp. For vLLM or TGI deployments, use the GPTQ 4-bit weights.

vs. MiniCPM5-1B (1B, same family). The 1B is smaller and faster but weaker across the board, particularly on agentic tasks and long context. Choose the 2B unless you are on a genuinely constrained device.

vs. Qwen3.5 4B (Reasoning). Qwen3.5 4B scores an estimated 14 on the Intelligence Index, one point below MiniCPM5-2B despite 44% more parameters. MiniCPM5-2B wins on memory footprint and on agentic benchmarks. Qwen3.5 4B has a larger ecosystem of fine-tunes and broader tooling support. If you are already invested in the Qwen toolchain, the migration cost may not be worth one index point.

vs. Granite 4.2 3B. Granite 4.2 3B scores 11, four points behind. MiniCPM5-2B is the stronger model on reasoning, code, and tool use, and it is smaller. Granite's advantage is IBM's enterprise support and compliance documentation, which matters in regulated deployments.

vs. Ling 3.0 Tiny. Ling 3.0 Tiny scores 16 but carries roughly 3x the parameters. It is the better model if you have the memory. MiniCPM5-2B is the better choice when 2.5B is your ceiling.