d1-Omni-2B vs MiniCPM5-2B: A Decision Model Is Not a Small Chat Model

Both are open-weight, both sit near two billion parameters, and both are pitched at hardware that lives on a desk rather than in a rack. That is where the resemblance ends. d1-Omni-2B takes a state — text, JSON, images, video frames, audio — plus a set of named questions, and returns typed answers with calibrated probabilities in a single forward pass. MiniCPM5-2B takes text and writes more text, reasoning its way to an answer one token at a time. Swapping one for the other is not a model upgrade or a model downgrade; it is a rewrite of whatever consumes the response. The comparison worth making, then, is not which one scores higher. It is which contract your pipeline can actually accept, and what each one costs you in licences, latency and deployment work to honour it.

What actually comes back from a call

A d1 call looks like a schema, not a conversation. You pass system_one a state and a dictionary of questions, each with a type — yes/no, single choice, multi-choice, ordered scores, text span, number, date, one bounding box or several — and you get back a value per question with a probability attached. The model card's own example routes a support ticket: a refund flag, a team assignment drawn from two named criteria, and a confidence on each. No prose, no transcript, no tokens emitted. The card states this plainly: it is not a chat model.

That design is the whole product. Because nothing is decoded, there is no parse step, no JSON repair, no retry loop for the model that wrapped its answer in an apology. A value comes back at a threshold you chose, with an abstain path when nothing in the option set applies — Liquid reports 78.5 on that abstain test written and 75.8 spoken. If your downstream code needs a queue assignment and a number, this is the shape you want.

MiniCPM5-2B returns the opposite shape. It is a standard Llama-architecture decoder that thinks before it answers, built on a 400-billion-token deep-thinking SFT stage, domain RL and an on-policy distillation step that folds sixteen specialist teachers into one dense checkpoint. You can absolutely get structured output from it — its function-calling scores are respectable, and OpenBMB ships a tool parser for vLLM — but you are getting it by asking, in a prompt, and trusting the decoder to comply. The reasoning is the feature. It is also what you are paying for on every call.

The head-to-head that does not exist

There is no benchmark on which these two models have both been run. That is not a gap in the reporting; it is a consequence of the split above. d1-Omni-2B appears only in Liquid's decision suites — DecisionBench v1 at 76.4, decisionbench.ai v4 at 84.7, Decision Index public suite v0.3 at 49.0, ImajevBench v2.0-lite at 72.3, an unweighted vision average of 67.7 across eighteen benchmarks. MiniCPM5-2B appears only in OpenBMB's reasoning and agentic suite: an average of 53.9 across 34 tests, LiveCodeBench v6 at 69.1, AIME 2025 at 86.5, SWE-bench Verified at 46.4, BFCL v4 at 66.6, and a much humbler 8.9 on Humanity's Last Exam. Not one of those numbers is measured on the same items, by the same scorer, as any number in the first list.

Anyone showing you a two-column table of these scores side by side is stitching, and the stitching is worse than it looks. Every d1-Omni-2B figure is vendor-run and, as of publication, independently unreproduced. OpenBMB's headline average is also vendor-run — the company released its training corpora and RL framework, which is more than most labs do, but that is reproducibility of method, not of scores.

The independent numbers that do exist are worth reading carefully because they disagree with each other across index versions. Artificial Analysis scored MiniCPM5-2B at 15 on its v4.2 Intelligence Index when it covered the launch on 7 September; the live page now reads 12; OpenBMB's own claim of 23 was made on v4.1.1. Those three digits are not a decline and not a dispute — the index changed underneath them, and scores from different versions are not comparable. Take the direction and ignore the digit. Artificial Analysis has no page at all for d1-Omni-2B or its sibling d1-2B, so the decision model has no independent measurement of any kind yet.

One number that looks transferable and is not: Liquid ran a 27-test comparison of its chat model LFM3-1.7B against MiniCPM5-2B and won 23 to 4. That result says a Liquid post-trained decoder beats OpenBMB's on those tests. It says nothing about the decision head, which was never in that run, and it should not be borrowed to settle this pairing.

Where the specs actually separate

• Output contract — typed values with probabilities and zero output tokens versus generated text with an implicit reasoning trace. Everything else on this list is downstream of that.

• Size — 2.17B parameters in a 4.33GB BF16 checkpoint, against 2.52B total and 1.98B non-embedding, roughly 5GB in BF16. Close enough that neither wins on footprint alone.

• Inputs — text or JSON state, images, video frames and audio, mixable in one request, versus text only. MiniCPM5-2B has no vision encoder and no audio path; if the state contains a waveform, this comparison ends here. If you want OpenBMB's multimodal line, that is MiniCPM-V 4.7, a different family with a different trade-off.

• Context — 128,000 tokens against 131,072. This is the same number stated two ways, and it is not a reason to choose either model. It matters only in that both can hold a long document; d1-Omni-2B's constraint is that long spoken passages degrade its accuracy well before the window fills, and the card says so.

• Licence — LFM Open License v1.0 with a $10,000,000 annual-revenue threshold, against Apache-2.0 with no condition at all. This is the largest single difference in the table and it has nothing to do with model quality.

• Runtime — custom modelling code behind trust_remote_code, Transformers 5.19 or newer, BF16 only, no vendor GGUF and no documented vLLM or SGLang path, against unmodified Llama tooling: vLLM, SGLang, llama.cpp, MLX, GPTQ, an official GGUF in the repo and quantised builds already circulating.

• Adoption — 36 downloads and 10 likes four days after the repository appeared on 24 October, against 1,216,145 downloads and 1,823 likes since 6 September. Asterisk: the MiniCPM figure has had seven weeks and a launch post, the d1 figure has had neither, so read it as a maturity signal rather than a verdict.

Five milliseconds against a thought

Liquid publishes warm-call latency for d1-Omni-2B, measured after compile() in BF16 as the median of twenty calls. On an H100 PCIe a single question costs 5.8ms, three questions 7.7ms, a 5,000-token state 52ms, a 384-pixel image 12.1ms and ten seconds of audio 12.4ms. Batched at 64 states per call it runs 1,154 states a second, and an MI325X is faster still at 3.7ms and 1,697 states a second. An M5 Pro does 21.1ms on one question and 110 states a second — slow next to a datacentre card, and still fast enough to feel instant inside a desktop app.

None of this is a fair race, because the other side does not publish a time. What can be said structurally is that a decoder's latency scales with how much it thinks, and MiniCPM5-2B is a model built to think. On a routing or triage call — where the correct answer is one of four queue names — you are paying for a rationale nobody asked for, and paying per token for it. Artificial Analysis puts a number on this: across its Intelligence Index run the model emitted 74 million output tokens, against a median of 67 million for comparable models, which its summary calls "somewhat verbose." That is not an argument against the model; it is an argument against using it in the role d1-Omni-2B was built for.

Treat the d1 numbers with the usual caution. They are vendor measurements, taken on specific hardware with a compile step, and an independent run will almost certainly land somewhere else. The order of magnitude — single-digit milliseconds per decision — is the part that survives.

The licence clause that outranks the scoreboard

MiniCPM5-2B ships under Apache-2.0. You can use it commercially, fork it, redistribute it, embed it in a product, and never speak to a lawyer about it. d1-Omni-2B ships under the LFM Open License v1.0, which grants commercial use only while your organisation stays under $10,000,000 in annual revenue. At or above that threshold, the licence states that commercial use "is not licensed under this Agreement" — meaning you need a separate arrangement with Liquid AI, or you do not ship the model.

Redistribution is permitted on both, with conditions on the LFM side: pass the licence along, mark modified files, keep the notices. There is no rebranding requirement. For a research team, a prototype, or a company comfortably under the line, that clause is a formality. For a product team at a company that might cross the threshold during the model's useful life, it is a procurement question that arrives before the first benchmark does — and it is the kind of thing that gets discovered late, by legal, after the architecture is set.

The asymmetry is stark enough that it should be stated without hedging: on licence alone, MiniCPM5-2B is the safer bet for any commercial deployment, and d1-Omni-2B's licence is a real cost of choosing it, not a footnote.

Which one you can actually run today

MiniCPM5-2B is boring to deploy, which is the highest compliment available to a model at this size. It is a stock decoder, so vLLM and SGLang support it without a patch, llama.cpp and LM Studio read the GGUF, MLX covers Apple silicon, and a Q4_K_M build is about 1.45GB. The one trap is tool calling: the model emits XML-style calls, so vLLM needs the minicpm5 tool-call parser enabled or your function calls arrive as prose.

d1-Omni-2B is not yet boring. Loading it means a recent Transformers with trust_remote_code=True, plus torch, torchvision and Pillow; the repository ships BF16 safetensors and nothing else. There is no vendor GGUF, no merged vLLM recipe in the card, and Hugging Face lists no inference provider for it — so there is no hosted endpoint to test against, which is also why no hosted price exists to quote. The practical path most people will take is the Ollama tag d1-omni:2b, a 4.4GB community packaging that wraps the same weights. That works. It is also the only reason a developer can try this model in an afternoon, and it is a third party's work, not Liquid's.

Neither model has a published per-token price, because neither is sold per token. Any per-million figure you find for either is derived from GPU rental maths rather than quoted by a vendor. If you are comparing them on cost, compare them on what one decision costs in seconds of GPU time — and remember that the decision model's answer is finished when the call returns, while the chat model's is finished when it stops thinking.

The pattern that uses both

The honest conclusion of this comparison is that they are not competitors, and the useful architecture treats them that way. d1-Omni-2B handles the cheap, high-volume, latency-sensitive judgement: which queue, which team, is this the same invoice, how urgent, which of these twelve boxes. It runs locally, it returns a number you can threshold, and it abstains when it does not know.

MiniCPM5-2B handles the part that needs language: explaining the decision to a customer, drafting the reply, writing the fix, calling the next tool in the chain. It is worse at the first job and better at the second, and the split costs you nothing but a function call between them — a route that only escalates to the expensive model when the cheap one's confidence falls below your threshold. That escalation layer is exactly the kind of thing a routing platform is for: one API key across 200+ models with 0% markup on provider list price, automatic failover when a provider hiccups, and a routing DSL that lets you compose several models behind a single call. Neither d1-Omni-2B nor MiniCPM5-2B is in OrcaRouter's catalogue today, so the decision half of this pattern stays self-hosted for now — but the generative half, the one you will want to swap as better small models land, is precisely the half worth routing rather than hard-coding.

Who should pick which

Take d1-Omni-2B when the state contains audio or video, when you need a probability rather than a sentence, when the answer has to be a bounding box or a span or a number with a range, and when the call sits in a loop where 6ms and 78ms are different products. Take it knowing the licence threshold applies to you, that deployment is custom-code territory, and that no independent evaluation exists yet — Liquid's own card points people without audio at d1-2B, which is a more honest piece of guidance than most vendors volunteer.

Take MiniCPM5-2B when the input is text, when the output has to be read by a human or fed to a tool that wants prose, when you need reasoning across a long document, and when Apache-2.0 and a stock Llama deployment path remove two categories of risk before you write a line of code. Take it knowing the vendor's 53.9 average is unreproduced, that its independent score is 12 on the current index — well above the median of 5 for models in its size class, and not comparable to the 15 or 23 recorded on earlier versions — and that its weakest published results, Terminal-Bench at 8.6 and SWE-bench Pro at 14.4, are the ones closest to agentic work, which is where it is most heavily marketed.

And take neither if what you actually wanted was a small chat model that can see. MiniCPM5-2B cannot, d1-Omni-2B does not chat, and the model people usually mean when they type either name into a search box is a different one in the same families. The thing to watch is the first independent audio evaluation of d1-Omni-2B. Its spoken-language results — 92.5 on FLEURS across 43 languages, but 42.0 written collapsing to 22.8 heard on short states, and 83.6 to 41.8 on multilingual passages — describe a model that is excellent at identifying a language and fragile at understanding a paragraph read aloud. Until someone outside Liquid measures that gap, the voice-input case is a promise with a number attached, not a result.