MiniCPM4

What it is

MiniCPM4 is a language model designed explicitly for end-side devices rather than servers^[1]. End-side means the hardware a person actually holds or sits next to — a phone, a laptop, a small board — as opposed to a machine in a data centre reached over a network. That constraint pushes on everything else: memory, bandwidth, latency and the length of context the model can handle are all tighter than they are on a server.

The variant described in an open model card is MiniCPM4-8B; the card on Hugging Face was created on 5 June 2025 under the Apache-2.0 licence^[2].

Where it comes from

The team published the MiniCPM4 technical report on 9 June 2025^[1]. The report is the main public description of what went into the model: a new attention mechanism, two data recipes, a search tool for pre-training configurations, changes to post-training, a ternary-weight method and an inference system.

Attention and long context

Ordinary attention lets every token look at every other token in the sequence, so its cost grows with the square of the sequence length; that is the main reason long inputs are expensive. MiniCPM4 introduces InfLLM v2, described as a trainable sparse attention mechanism that speeds up both prefill and decode when processing long contexts^[1]. Sparse attention means each token consults only a subset of the others rather than all of them. Calling it trainable means the selection is learned together with the rest of the model, instead of being fixed by hand in advance. Prefill is the pass over the prompt; decode is the token-by-token generation that follows it, and the two have different bottlenecks, which is why the report treats them separately.

Data

Pre-training uses UltraClean, a filtering and generation strategy for pre-training data, while supervised fine-tuning uses UltraChat v2^[1]. The team says these datasets reach satisfactory performance with just 8 trillion training tokens^[1] — a claim about data efficiency rather than about scale, and one that matters when the training budget is a practical constraint.

Searching pre-training setups

ModelTunnel v2 is introduced for efficient search over pre-training strategies^[1]. Training runs are expensive, so comparing many configurations by running each of them in full is impractical; a search tool lets the team compare strategies at lower cost before committing to one.

Post-training

Post-training adds chunk-wise rollout to keep reinforcement learning load-balanced^[1]. Reinforcement learning on generated text first produces answers and then updates on them; when a batch contains answers of very different lengths, hardware sits idle once the short ones finish. Splitting generation into chunks evens out the work.

The same work introduces BitCPM, a data-efficient ternary LLM method^[1]. A ternary model stores weights at three levels instead of the usual large set of floating-point values, which reduces memory and bandwidth; BitCPM's focus is on reaching that point without demanding extra training data.

Inference

The inference system combines sparse attention, model quantization and speculative sampling to speed up prefill^[1]. Quantization stores weights at lower precision, which saves memory and bandwidth. Speculative sampling uses a cheap draft to propose several tokens that the main model then checks in one pass. Together with the sparse attention, these are three separate levers applied to the same stage.

Where it sits

MiniCPM4 is best read as a statement about where the difficulty lies for models that run on a device: not raw capability alone, but the joint budget of memory, latency, data and context length. The report bundles changes at every layer of the stack — attention, data, pre-training search, post-training and inference — rather than a single trick, and the Apache-2.0 model card makes the weights available for others to run and inspect^[2].