Liquid AI d1 vs Liquid AI d1-omni-600M: The Open Decision Model That Can Hear You

Search for the name Liquid AI d1 and you will land on a three-billion-parameter model that reads text and images. The other open checkpoint in the same family is a fifth of the size, considers up to thirty seconds of speech, and is the only one of the two that can decide anything at all about a voice. It is called Liquid AI d1-omni-600M, and if you found the family through a local runtime library rather than through the vendor's own documentation, there is a decent chance you have never seen its name. That is the situation this comparison exists to fix, because the two models are not competing answers to the same question. They are answers to two different questions, and only one of them involves listening.

Every figure below comes from Liquid AI's own material: the LiquidAI/d1-omni-600M model card, the companion d1-omni-600M-GGUF repository, and the 7 October release post that announced both open checkpoints at once. The performance rows were scored by the vendor on an index it maintains rather than submitted for public ranking, and the post says outright that dedicated audio decision benchmarks are an open problem. Nothing here has been reproduced by anyone outside the lab.

What 587 million parameters are made of

The headline number hides an unusual split. Total parameters come to 587M, and they are not one stack: a 381M shared trunk with the decision head attached, a 94M vision encoder, and a 112M audio encoder. Every modality runs through the same trunk weights, which is the design decision that keeps the whole thing small — the model is not three models wearing a trench coat, it is one deciding trunk with two ways to feed it.

The pieces come from different places in Liquid's catalogue. The trunk descends from LFM2.5-Encoder-350M, a bidirectional encoder, rather than from the decoder-only line that the larger sibling came from. The vision tower is a SigLIP2 lifted from LFM2.5-VL-450M with an adapter and LoRA updates applied to the backbone. The audio path is a 17-layer FastConformer encoder with its own adapter, fine-tuned against a frozen text backbone. The card reports a 16,384-token context shared across text, image and audio positions together, with text trimmed to 896 tokens when images are present, and a 65,536-token vocabulary — half the 128,000 of its bigger sibling. That last figure is worth noticing if you work in a language the family only partly covers.

Bidirectional versus decoder-only is the reason the two models feel different to anyone who has run both. The encoder-shaped trunk reads the whole state at once, in both directions, before producing anything. The decoder-shaped one reads forward the way a language model does. Both are trained to report answers off a distribution with zero output tokens, so neither writes text — but the machinery underneath is a different class of model, and the accuracy gap discussed below is the visible cost of the smaller, encoder-shaped design.

Thirty seconds of speech, and nothing to score it with

Audio is the reason this checkpoint exists. It accepts a single clip of up to 30 seconds, 16 kHz mono, in the same forward pass that produces the answer, and it is the only open-weight member of the family that can do so. For on-device work that is not a marginal feature. A camera that flags a defect on a production line is a vision problem the larger sibling already handles; a device that routes a spoken request, classifies an utterance, or decides whether a caller is asking for a refund is a problem only this one can be pointed at.

Two constraints sit on top of that capability and both are documented, which means there is no excuse for tripping over them in production. First, one request carries images or audio, never both — passing both raises a ValueError rather than quietly dropping one, so the failure is loud and cheap to find in testing. Second, the audio path was trained on exchanges between an English speaker and an assistant, with the clips cut at 30 seconds. That is one speaker geometry, one turn structure, and one accent distribution. Pointing it at call-centre recordings or field audio is asking for behaviour the card does not claim, and it is exactly the kind of gap that a benchmark would surface if one existed.

None exists. The release post calls dedicated audio decision benchmarks "currently an open problem" and invites the community to build one, which is a candid thing for a lab to write and a real constraint for anyone evaluating the model. Liquid AI d1-omni-600M is being asked to justify itself on the strength of a capability that nobody can measure yet. The vendor also withheld inference numbers entirely, on the stated grounds that the model is an early research release under active development. So there is no latency figure for the 600M at all — not for text, not for vision, and not for the audio path that is the whole point.

What can be said without inventing anything is arithmetic on the published parameter count: at the float16 precision the card recommends for GPUs, 587M parameters is on the order of 1.2 GB of weights before activations, against roughly 6.2 GB for the 3.12B sibling at the same precision. The card also carries a precision warning that is easy to skim past and should not be: the model was trained in float32, float16 is recommended on GPUs, and bfloat16 changed the top answer on some rows during testing. If your serving stack defaults to bfloat16, this is a model where that default is not safe.

Why the family's smaller half is easy to miss

The reason a reader arrives at the 3B and stops is structural rather than accidental. Liquid AI's documentation index lists three rows under decision models and they do not read the same: d1-3B and d1-omni-600M carry Hugging Face and GGUF links with a "No" in the trainable column, while d1 sits in its own row with the bare letters "API" where every other model's download links would be. The release post calls d1 a family name and never distinguishes the served endpoint from the open checkpoint. Local runtime libraries then take the 3B, because it is the one whose size and modality count match the entry they want to publish, and the 600M does not appear in the same listing at all.

The result is a family whose published access story, read quickly, looks like one model and one API row. What is actually on offer is two open checkpoints with different trunks, different modalities and a 32-point gap between their scores on the vendor's own index, plus a hosted endpoint whose relationship to either checkpoint the vendor has never confirmed. The 600M is not hidden behind anything. It simply has no name that a search for d1 will surface, and it is the only one of the two that hears.

The scores that exist, and the one column worth reading

On Decision Index 0.2.1 the vendor reports 15.95 for Liquid AI d1-omni-600M against 48.57 for its larger sibling — a gap large enough that the total is close to useless as a basis for choosing. The sub-scores are more informative than the sum, and one of them is genuinely surprising.

• Knowledge — 8.3 against 23.8

• Language — 12.9 against 56.4

• Retrieval — 35.0 against 52.8

• Tools — 15.1 against 74.5

• Arts — 6.8 against 36.3

Retrieval is where the small model holds its ground, losing under a third of the larger model's score where the other four columns it loses 60 to 80 percent. That pattern matches what a trained encoder should be good at: matching a state against content is close to what the trunk was built for, and it is much less dependent on the layered language capability the decoder-shaped sibling inherited from far more pretraining. The Tools column is the opposite story, and a 59-point gap there is the number to stare at if your workload is routing a request to the right function.

On seven public text benchmarks the picture softens. The vendor reports a mean of 78.4 for the 600M against 82.9 for the 3B, with the small model losing narrowly on SQuAD 2.0 (74.0 against 85.3), PubMedQA (61.3 against 66.0), BoolQ (77.7 against 86.7) and XNLI (74.7 against 85.0), while winning on Civil Comments toxicity detection (95.8 against 93.0) and PAWS-X paraphrase identification (79.5 against 76.9). Liquid's own framing is that the 600M beats a 2B decision model's 77.1 mean at a quarter of the parameters. Two benchmark suites give two different apparent verdicts, both self-reported, and the honest reading is that neither settles anything about the audio path, because the audio path is not in either suite.

Where the two actually meet

For all the divergence, the programming model is identical, and that is what makes them interchangeable in one specific sense. Both answer noul, choice and score questions over a state, both return the chosen answer with a probability map and a confidence value between 0 and 1, and both report output_tokens: 0. The confidence field is the one people misread: it measures how strongly the probabilities favour one answer, not the odds that the answer is correct. A 0.96 on a badly posed question is a confident wrong answer, and the field will not warn you.

Where they meet in practice is a cascade. Screen with Liquid AI d1-omni-600M — cheaply, locally, and including the audio cases no text-only scorer can touch — then escalate the items it places near the middle of its scale to the larger checkpoint for a sharper call. The escalation rules are the confidence and the distribution the 600M already returns, so the routing logic needs no extra model, and on a workload with a strong majority of easy items most of the traffic never reaches the second stage. That composition works because both models return the same kind of object. Two arbitrary models would not.

If that cascade ever gates a call to a generative model you rent rather than run, the layer underneath is where the plumbing gets interesting, and it is also where we come in. Routing a decision through a chain of models is exactly the shape of problem a routing rule is for: OrcaRouter composes several models behind one OpenAI-compatible endpoint, each at its provider's list price passed through with 0% markup, with automatic failover across providers so an escalation that fails at the provider layer retries on a fallback instead of failing the request. We do not host any Liquid AI model — we checked before writing this — so nothing above is a claim about calling these weights through us. The point is that the decision model is the cheap part of the pipeline and the borrowed model on the other side is the part that goes down.

Where the file comes from, if you want to run it today

For local deployment the vendor's own GGUF repository for the 600M ships Q8_0 at 407 MB and F16 and BF16 at 764 MB each, with no 4-bit build listed — so the smallest official download is roughly seven times smaller than the corresponding build of the larger model and roughly the same size as a mid-resolution photograph. The card's own example starts a llama.cpp server with batch flags of 4096 and suggests raising them to 16384 for longer states, then queries the same /v1/systemone endpoint the larger sibling uses.

The one thing the local route does not give you is the audio path's numbers, because they do not exist. If you intend to run speech through this in front of real users, the evaluation is yours to build: a labelled set of clips, the same three question types, and a measured answer rate per class. That is not a dismissal of the model — a 587M checkpoint that decides over a voice clip in one pass is a genuinely different tool from a text classifier bolted to a transcription step, and it deserves a real test rather than a vibes-based one.

If that cascade ever gates a call to a generative model you rent rather than run, OrcaRouter composes several models behind one OpenAI-compatible endpoint , each at its provider's list price passed through with 0% markup.

Choosing an omni checkpoint over the text-only one is also a good time to look at what has already gone wrong in this class: the documented AI incidents and agent failures involving small multimodal models are collected in the OrcaRouter AI Incident Archive, where each entry carries its own sources, severity, confidence grade and disputed flag.