d1-2B: Liquid AI Shipped a 1.9B Decision Model Without a Post to Announce It

The Hugging Face repository for LiquidAI/d1-2B was created at 19:30 UTC on 24 October 2026. Its sibling, d1-Omni-2B, appeared twenty-four seconds later. By the end of that evening both repos were complete — 3.84GB of BF16 safetensors, forty-odd files of custom Transformers code, a calibration table, a typed-question API — and nothing Liquid AI published said either model existed. The first vendor sentence that names d1-2B arrived on 27 October, inside the LFM3 family launch — the same post published on liquid.ai and on Hugging Face's own blog — as one clause in a paragraph about two decision models. There has been no dedicated post since. So this is not a launch story, and treating it as one would invent a marketing moment that never happened. It is a story about a complete model artifact with an incomplete announcement, and about the two things a reader can still do with that: read the repo, and hold the vendor's numbers at arm's length until somebody outside the lab runs them.

The five days between the weights and the sentence

The d1 family has been released twice, and neither release looked like this one. On 7 October Liquid AI published "Open d1: Edge decision models for text, vision, and audio," which introduced d1-3B at 3.12B parameters and d1-omni-600M at 587M, with a headline claim, a benchmark table, latency numbers and a blog post that has stayed live ever since. That post contains no 2B model.

The 2B line moved on a different schedule. The base checkpoint LFM3-Omni-2B appeared on 21 October. On 24 October, at 19:30 and 19:30:24 UTC, Liquid AI created the d1-2B and d1-Omni-2B repositories. Then, on 27 October, the LFM3 launch post named the pair as "decision models specialized from the vision and omni models" — a description, not an announcement. The same day, four derivative repos for d1-2B went up: MLX builds at fp16, 8-bit and 4-bit, plus an ONNX export. Nobody wrote a post about those either.

This matters for a practical reason. An announcement is where a vendor commits to positioning: what the model is for, what it costs, which runtime it targets, what it does not do. The card does some of that work, and does it unusually well. But the gaps left by the missing post are real and specific, and they are listed at the bottom of this piece rather than papered over.

What the repository will actually tell you

Strip the framing and the checkpoint is a small, densely specified multimodal classifier that refuses to generate text. Every call returns typed answers with probabilities attached and output_tokens: 0. The card says it outright: d1-2B "is not a chat model."

• Parameters — 1.92B, shipped as a single 3.84GB BF16 safetensors file.

• Base — LFM3-VL-2B, on the LFM3 backbone: 24 layers, of which 13 are gated short convolutions, 5 are sliding-window attention, and 6 are global attention.

• Context — 128K tokens and a 128,000-token vocabulary, four times the window of d1-3B's 32,768.

• Input — a state that can be text or any JSON value, pictures or a video, and any number of named questions, all in one media list. Video is the capability d1-3B does not list.

• Output — yes/no, a choice among named options, an ordered score, a value or date read from a document with its span, a number with a p10–p90 interval, a bounding box, or every instance of an object with a count. Each carries a probability.

• Languages — sixteen: English, Arabic, Chinese, French, German, Italian, Japanese, Korean, Portuguese, Spanish, Vietnamese, Thai, Indonesian, Hindi, Russian, Polish.

• License — LFM Open License v1.0. Commercial use is granted below $10,000,000 of annual revenue; the license text defines that figure as a threshold, and rights for commercial use above it are conditioned on not exceeding it.

• Speed — 5.7 ms for a single decision on an H100 PCIe and 3.8 ms on an AMD MI325X, with 1,132 and 1,699 decisions per second respectively when 64 states are batched into one call. On an Apple M5 Pro the single-question figure is 18.6 ms.

The claim worth arguing about: it beats the model it replaced

Liquid AI's card makes one comparative claim without hedging: d1-2B "leads the open d1 models on average and on our board of over a hundred decision benchmarks, ahead of d1-3B at under two thirds of its size." That is a strong statement from a 1.92B model about a 3.12B one, and it is checkable, because the card prints all four open d1 models in a single table scored on the same items with the same scorer.

The top-line number is 51.1 against 49.0 on the Decision Index public suite, version 0.3 — a 2.1-point lead. Before anyone reads that as a clean win, two caveats belong next to it. First, d1-3B's own card reports 48.57 on Decision Index 0.2.1, and the difference between 48.57 and 49.0 is the index version, not an improvement in the model; the d1-2B card states that all four models were re-scored on the same items and that a few of d1-3B's numbers therefore differ from its own card. Second, the public suite is a fraction of what orders the public leaderboard: the independent evaluator who rebuilt it describes 37 public benchmarks weighted at 20% of the score, with the rest coming from private tests only the maintainers run.

What makes the 49.0 credible as a number — even though d1-2B itself has no outside check — is that somebody has already reproduced the 3B on this exact version. Efraín Garay ran d1-3B on a 6,000-request stratified sample of Decision Index 0.3 in mid-October and got 49.11, against Liquid's own 49.04 on the same rows and 48.99 on the full suite. That is a reproduction within a tenth of a point. It does not validate d1-2B's 51.1, which no third party has run, but it does validate the scoring method behind the table in which 51.1 sits.

Where the smaller model is not ahead

"Leads on most single benchmarks" is doing quiet work in that sentence. On the same-run table, d1-3B still wins three of the twenty-odd rows that matter to a deployment decision:

• Fast Decisions — 59.3 for the 3B against 58.8, the one speed-oriented decision benchmark where the larger model edges ahead.

• Typed Decisions — 65.0 against 61.3, a 3.7-point gap and the clearest single argument for the older model when the output has to be a typed value rather than a label.

• AI2D — 79.9 against 76.7, the diagram-reading benchmark, where a bigger vision tower still buys accuracy.

Everywhere else the ordering flips, sometimes sharply. VisualWebBench is 96.2 for d1-2B against 71.4 for d1-3B. ImajevBench v2.0-lite is 75.5 against 64.0. MMMU-Pro is 26.4 against 18.5 — both low enough that neither model should be trusted with hard multimodal reasoning, which is worth saying plainly rather than presenting the 7.9-point gap as a win. The vision averages are 70.2 and 65.4.

Three absences the card cannot fill

The missing announcement shows up as missing artifacts. None of these is a defect in the model; each is a reason the model is harder to adopt today than its benchmark line suggests.

• No GGUF. d1-3B and d1-omni-600M both got GGUF repositories on 6 October, a day after their weights went up, and d1-3B followed with an 8-bit weight-activation build and four MLX variants. d1-2B has MLX and ONNX builds as of 27 October, but no GGUF — so there is no llama.cpp path published for the decision head, even though the base model LFM3-VL-2B got its own GGUF on 19 October. If your edge stack is llama.cpp, this is the whole story.

• No price and no endpoint. The card lists no hosted API, no per-token price, and no inference provider. That is not unusual for an open-weights release, but it means the only way to use d1-2B is to run it, and the card's deployment section stops at a Transformers snippet.

• No independent benchmark. As of 28 October the repo shows 44 downloads and 13 likes. The independent decision-model evaluation that exists covers d1-3B and d1-omni-600M, not this model. Every performance figure above is Liquid AI's own.

There is also a limit the card states about itself: answers "get less reliable past about 64K tokens of state," half the advertised 128K window, and estimates are reliable on counts and scores but less so on free quantities. A model whose own card tells you where it degrades is more useful than one that does not, but the 128K headline should be read as a capacity figure, not a working range.

What a first deployment actually looks like

The practical path is Transformers 5.19 or newer with trust_remote_code=True, bf16 on GPU, and the system_one or system_one_batch call. There are no sampling parameters because there is no sampling. The one tuning knob that matters is set_size, which defaults to the trained size of 16; raising it buys speed and costs text accuracy.

The card's own recommendation is the step most teams skip: calibrate your decision threshold on data from your own use. A probability of 0.62 means nothing in isolation. If you are routing support tickets or flagging documents, the threshold that separates "escalate" from "auto-handle" has to be fitted on your own labelled sample, because the vendor's calibration was fitted on theirs.

The shape this fits is a pipeline step, not an assistant: triage, moderation, intent classification, extraction from forms, reranking, visual inspection. Those are exactly the places where a pipeline already calls several models, and where the generative steps around the decision usually come from a hosted API. OrcaRouter does not serve any Liquid AI model today — this one included — so running d1-2B means running it yourself. What a router is useful for is the rest of the chain: one OpenAI-compatible key for 200-plus hosted models, a routing DSL that composes steps into a single call, and automatic failover when a provider drops, so the decision node on your GPU is not held hostage to the generative node next to it.

What would change this story

Four things, in descending order of how much they would matter. A GGUF would put d1-2B on the same runtime footing as its siblings and make the edge pitch real. A dedicated post would tell buyers what Liquid AI thinks the model is for, beyond the card's list of pipeline steps. An independent run — ideally the same 6,000-row sample that reproduced d1-3B — would turn 51.1 from a vendor claim into a measurement. And a hosted price would make the build-versus-buy question answerable at all.

Until then the honest summary is narrow and useful: a 1.92B decision model exists, its repository is complete enough to evaluate, its benchmark lead over the 3B is real on the vendor's own same-run table and unverified everywhere else, and the missing announcement has left it without the packaging — runtime, endpoint, price — that most teams need before they will put a model in a pipeline. If you already run Transformers and want a 128K-window classifier with video input, it is worth an afternoon. If you need llama.cpp or a managed endpoint, wait.