Liquid AI d1 vs Liquid AI d1-3B: What the Ollama Library Calls One Model and the Vendor Calls Two

There are two ways to name the same set of weights, and Liquid AI d1 and Liquid AI d1-3B illustrate the difference better than any comparison of parameters would. Subtract one hyphen and a size suffix from the second name and you get the first, so it is tempting to treat the shorter string as a nickname. The two catalogues that actually list these models do not agree with that reading. Liquid AI's own documentation index keeps d1 in its own row with the letters "API" where the download links go, and keeps d1-3B and d1-omni-600M in a separate pair of rows with working Hugging Face and GGUF links and a "No" in the trainable column. Ollama, whose library entry is the reason this pair is worth writing about at all, collapses all of it into one page called d1, describes it in a single line as "a 3B decision model from Liquid AI, built on LFM2.5-VL-3B," and offers precisely three tags underneath. Comparing Liquid AI d1 against Liquid AI d1-3B is therefore not a comparison between a hosted endpoint and an open checkpoint, and it is not a comparison between two checkpoints either. It is a comparison between a hosted endpoint and the open checkpoint that the local runtime ecosystem has decided is d1 when you say the word without qualification. Most of what follows is about which of those readings your deployment actually depends on.

A note on how the figures below are sourced, since the honesty matters more than the formatting of it. Everything numeric here is Liquid AI's own reporting, on the model cards or in the 7 October release post. The Decision Index rows were scored by the vendor with the official scorer rather than submitted for public ranking, and no third party has independently reproduced any d1 result that we could find. Where a number is arithmetic on a published figure rather than a measurement, it says so.

Where the two names come from

The shorter name is older. Liquid AI's 5 October post introduced the model as Liquid AI d1 — "our first decision model," multimodal in that release, answering typed questions over a state of text, images, or both, in one forward pass with zero output tokens. That post quotes a hosted price of $0.04 per million input tokens, bills input tokens only, and notes that images are charged like text at 1.5 tokens per 32×32 patch, so a 1024×1024 image costs 1,536 tokens. It also gives the text decision latency as 200–300 ms. Those are hosted-service numbers, and the post is explicit that the runtime behind them is the vendor's own decision endpoint at api.liquid.ai/decisions/v1/systemone.

The longer name appears in the 7 October post and on Hugging Face, and it is the one carrying the reproducible detail: 3.12B parameters, a 32,768-token context, a 128,000-token vocabulary, sixteen documented languages, a SigLIP2 NaFlex shape-optimized 400M vision encoder, and the base chain LFM2.5-2.6B-Base → LFM2.5-VL-3B → d1-3B. That card also states plainly that the model is not a chat model and does not write text. This is the checkpoint the whole local ecosystem is built on: the GGUF repository carries Q4_K_M at 1.67 GB, Q8_0 at 2.87 GB, and F16 and BF16 at 5.4 GB each.

What no vendor document says out loud is that Liquid AI d1 and Liquid AI d1-3B are the same weights. The documentation index assigns them separate rows. The release post calls d1 a family, not a checkpoint. Third-party write-ups have noticed the gap and noted that the vendor has not confirmed the identification. So the honest statement is a short one: the numbers the two names are published with do not conflict anywhere we can find, the family release and the served endpoint were announced two days apart with a compatible description, and the vendor has not said they are the same model. Treat the equivalence as a reasonable working assumption and not as a fact the vendor has put its name to.

What the local build actually changes

Ollama's entry is not a re-release and not a new checkpoint. It is a packaging decision, and the packaging imposes three constraints that the vendor's own documentation does not mention at all. The first is the tag list: d1:latest, d1:3b and d1:3b-q8_0, three tags naming one quantisation. The GGUF repository Liquid publishes carries four precisions, and the 1.67 GB Q4_K_M — the one most people would reach for on a laptop — is not among the Ollama tags. What you can pull is the 2.87 GB Q8_0 and whatever it expands to in the local store; the library page reports the download at 3.7 GB.

The second is the request contract. Ollama answers these models on /v1/systemone, takes a state plus a questions object, and returns typed answers with output_tokens: 0. That is the same shape the vendor's hosted endpoint uses, which is what makes the switch between local and hosted a configuration change rather than a rewrite. The third constraint sits in Ollama's endpoint documentation rather than on the model page, and it is tighter than a generative model's: requests must fit within 64 KiB without images and 32 MiB with them, streaming is not supported, cloud-hosted models are rejected, and images must be base64 PNG, JPEG or WebP in the request body — remote URLs are refused. Images are shared by every question in a request, so a picture you want only one answer to consider needs its own call. Input is never truncated, which means an oversized state returns an error instead of being silently clipped. That is the better failure mode, and it is still a failure mode your client has to handle.

Two documentation details remain unresolved and are worth knowing before you file a bug. Ollama's endpoint reference describes the choice question type as accepting 2 to 255 option keys while its decision-models capability page says 2 to 26; one of the two is stale. And the capability page lists its supported models as Nimble, Tev1, Clef, and Clef Flash, with no mention of d1 — even though the d1 package's own readme documents /v1/systemone and --ask support, and the package requires Ollama 0.40.4 while the endpoint's own documented floor is 0.35.0. Read the version requirement on the package, not the one in the guide.

The numbers, and which name they were published under

This is the part of the pairing that is easiest to get wrong, because both names are published with performance figures and the figures are not organised the way you would expect.

• Decision Index 0.2.1 — 48.57, published under Liquid AI d1-3B. Liquid describes it as the best score for a decision model under 10B parameters and puts it ahead of a 35B-A3B model at 47.11. • Text decision latency — 200–300 ms, published under Liquid AI d1 in the hosted-API post. There is no equivalent figure attached to the open checkpoint's own name. • Single-question latency on local hardware — 8 ms on an RTX 4090, 16 ms on a Jetson AGX Thor, 26 ms on a Jetson AGX Orin 64 GB, 50 ms on an Orin Nano, 30 ms on an Apple M5 Pro. Published under Liquid AI d1-3B. • Throughput — 475 decisions per second on the RTX 4090 and 1,106 per second on an AMD MI325X with questions packed into batches. Published under Liquid AI d1-3B. • Vision — a mean of 74.1 across eleven public image benchmarks, against 73.9 for the LFM2.5-VL-3B base it was built from. Published under Liquid AI d1-3B. • Image ablation — the same question set answered with images removed scores 45.1, which is the vendor's own measure of what the vision path contributes. Published under Liquid AI d1-3B.

Two problems fall out of that list and neither of them is fatal, which is exactly why they get overlooked. The hosted figure and the local figure are 25 to 37 times apart — 200–300 ms against 8 ms — and they were measured on things the vendor does not describe in comparable terms. Reading the gap as "local is faster" is not supported, because the hosted number is end-to-end through an API and the 8 ms is a forward pass on a named GPU. They are not the same measurement, and the vendor never claims they are.

The second problem is the vision row. A 0.2-point improvement over the base model across eleven image benchmarks sits inside the noise of most benchmark reporting, so whatever the decision head buys you, it is not a materially better image encoder. The ablation row looks far more impressive in the other direction — a roughly 29-point swing when images are added — but it compares two different question sets rather than two versions of one, which Liquid states in the post itself. Both rows are useful. Neither supports a strong claim about visual decision quality, and no third party has run either one.

Where the two names diverge in practice

For a buyer, the distinction comes down to four questions, and the answers do not all point the same way.

• Cost shape — Liquid AI d1 is billed per input token, at the vendor's published rate, with no output tokens to pay for. Liquid AI d1-3B is a 2.87 GB download in Ollama's packaging or a 1.67 GB one from the vendor's GGUF repo, with no per-call meter at all. • Latency, measurable — the hosted route quotes 200–300 ms per text decision. The local route's published 8 ms is a forward pass on an RTX 4090 with a warm model, which is a real number and not a request round trip. • Data path — the hosted route sends the state to the vendor. The local route keeps it on the machine, which for a support ticket, a medical note or a photograph is usually the argument that ends the discussion. • Version pinning — Liquid AI d1 behind an endpoint is whatever the vendor is serving today. Liquid AI d1-3B in Ollama is a fixed package you control, and the trade is that you own the upgrades.

The awkward reality underneath all four is that the open checkpoint is a sibling of the hosted model rather than a substitute for it, and the vendor has not said otherwise. The model card for the open checkpoint recommends it for routing and triage, moderation, intent classification, extraction checks, reranking, LLM-as-a-judge, and guardrails, and describes it as post-trained on LFM2.5-VL-3B for single-pass calibrated decisions. The hosted post describes the same set of tasks in different words and quotes the hosted price. If those are one model, the local build is a free copy of a hosted product, which would be an unusual thing for a lab to ship without saying so. If they are two fine-tunes of a common base, the published figures should not be assumed to transfer in either direction. The second explanation requires less of the vendor and fits the evidence we have.

Running both halves of the decision without running two stacks

Whichever name you settle on, the pipeline around it tends to look the same. A support queue gets a choice question over a destination team, a noul question for whether a refund is being requested, and a score question for urgency — one state, three answers, one pass. Where the two names genuinely diverge is at the point the decision gates a call to a generative model you rent rather than run. That call is a different problem with a different failure profile, and it is the part of the pipeline where d1 being right matters least: a 0.98-probability routing answer followed by a 502 from the model you routed to is a failed request either way.

We do not host any Liquid AI model — we checked our own catalogue before writing this — so nothing here is a claim about calling these weights through us. What we do is the layer on the other side of the decision: one OpenAI-compatible key for the models a triaged request fans out to, at each provider's list price passed through with 0% markup, so a vendor price cut reaches you the day it lands rather than at contract renewal, with automatic failover across providers so a triaged request survives the model you routed it to going dark. If you are wiring a decision model into a pipeline for the first time, that is the half worth making boring.

Which name to use, by situation

If you want to try the model this week with no Python environment worth maintaining, use the name the local runtime uses. Pull Liquid AI d1 from the library, accept Q8_0 and 3.7 GB, and take the 64 KiB request ceiling and the no-streaming rule as design constraints rather than nuisances. You get a real endpoint, real typed answers and no per-call meter on day one.

If you need a smaller footprint than Q8_0, the name to use is Liquid AI d1-3B, because the 1.67 GB Q4_K_M build lives in the vendor's GGUF repository and not in the library entry. That single fact is the most practical difference between the two names today, and it is the one most likely to be missed by anyone who reads the library page and stops there.

If you are putting this in front of paying users and need accuracy evidence first, neither name helps you yet. There is no independent evaluation of any d1 model that we could find, the Decision Index rows were self-scored, and the vendor has not published an audio decision benchmark at all. What you can do is instrument the confidence value the model already returns — 0 to 1, reflecting how strongly the probabilities favour one answer rather than how likely that answer is to be right — and find out on your own traffic where the thing is unsure. That measurement is worth more than any of the slides above, and it takes a day.

The decision model is the cheap half of the pipeline. The generative model it routes to is the half that needs a contract — one OpenAI-compatible key carries the models a triaged request fans out to, each at its provider's list price passed through with 0% markup.

Sizing a distilled checkpoint down against its own full release is also a good moment to check the record: the documented AI incidents and agent failures around small Liquid models are collected in the OrcaRouter AI Incident Archive, where each entry carries its own sources, severity, confidence grade and disputed flag.