d1-2B vs Liquid AI d1-omni-600M: When the Deciding Input Is Sound

Put a voice note and a photographed invoice in front of these two models and only one of them can answer, and it is not the one with the better score. d1-2B reads text, JSON, pictures and video, and cannot accept audio at all. Liquid AI d1-omni-600M reads text with images or text with up to 30 seconds of speech, and cannot accept audio and images in the same request. That single asymmetry decides most real deployments before either benchmark is consulted. What follows is the honest version of the comparison anyway: where the 587M model is genuinely competitive, where the 1.92B model is not close to being replaceable, and the one pipeline pattern that uses both without pretending they are alternatives.

The decision is a modality question, not a score question

A decision model takes a state and a set of named questions and returns a probability per answer, with no generated tokens. The state is the whole input, and the state's type is the binding constraint. d1-2B's card lists text, JSON, pictures and video. Liquid AI d1-omni-600M's card lists text with images, or text with audio — and the code enforces the exclusion: passing both an image and an audio clip to system_one raises a ValueError.

So the first question is not which model scores higher. It is whether the thing you need to judge arrives as pixels, as text, or as a waveform. If it arrives as a waveform, there is one answer in this pair, and the rest of this page is about how much accuracy you give up to get it.

What 587M actually buys

The 600M is not a small version of d1-2B. It is a different construction, and the budget is worth seeing itemised because it explains both its strengths and its ceiling.

• Parameters — 587M total: a 381M shared trunk and decision head, a 94M vision encoder, and a 112M audio encoder. Every modality runs through the same trunk weights.

• Base — LFM2.5-Encoder-350M, a bidirectional encoder, with a SigLIP2 vision tower borrowed from LFM2.5-VL-450M and a 17-layer FastConformer for audio.

• Context — 16,384 tokens across text, image and audio positions together, and a 65,536-token vocabulary. d1-2B's window is 128K.

• Audio — up to 30 seconds of 16 kHz mono speech per request. The card is explicit that the audio side was trained on requests between an English speaker and an assistant, which is a narrow distribution for a model people will point at call recordings.

• Media rule — images or audio, never both. The card documents the ValueError rather than leaving you to discover it.

• License — LFM Open License v1.0, the same threshold structure as d1-2B: commercial use under $10,000,000 of annual revenue.

• Speed — not published. The card reports no latency figures, calling the model an early research release under active development. d1-2B publishes 5.7 ms on an H100 PCIe, 3.8 ms on an MI325X and 18.6 ms on an M5 Pro.

The same-run table, and the rows where the gap is small

Both models appear in the benchmark table on d1-2B's card, which scores four open d1 models on identical items with an identical scorer. That makes the comparison cleaner than most cross-card comparisons, with one caveat: d1-omni-600M's own card reports 15.95 on Decision Index 0.2.1, while this table reports 18.3 on version 0.3. The difference is the index edition, and both numbers are correct for their own test.

• Decision Index public suite v0.3 — 51.1 for d1-2B vs 18.3 for Liquid AI d1-omni-600M.

• DecisionBench (Hanno Labs) v1 — 77.1 vs 58.7.

• Decision Bench (decisionbench.ai) v4 — 85.2 vs 57.9.

• ImajevBench v2.0-lite — 75.5 vs 21.7, the widest decision-side gap between the two.

• WorkflowEvals — 81.6 vs 48.8.

• Vision average, 18 benchmarks — 70.2 vs 42.8.

• VisualWebBench — 96.2 vs 14.9, which is less a comparison than a statement about how much a 94M vision encoder can carry.

Then the rows that argue for restraint. Typed Decisions is 61.3 against 57.5 — a 3.8-point gap for a model with a third of the parameters. POPE, the object-hallucination benchmark, is 88.7 against 82.7. JevBench is 77.9 against 58.0, a wide gap, but DecisionBench v4 is 85.2 against 57.9, and the two together say the 600M is uneven rather than uniformly weak. Liquid AI's own launch post puts its seven-benchmark mean at 78.4, which is high for 587M; d1-2B's card does not publish an equivalent mean, so the two figures should not be set side by side.

The one number that does not flatter either model is the independent one. Efraín Garay ran Liquid AI d1-omni-600M on a 6,000-request sample of Decision Index 0.3 and got 14.0, against the vendor's own 14.17 on the same sample — a close reproduction. He also found that 1,758 requests exceeded the model's instruction-and-option budget and were refused, counted as wrong, which is a real cost of a 16K window on a suite built for longer states.

Where the 600M is the only option

Audio routing is the case the model was built for, and the card's examples are concrete: call and voice-message routing, sound events, spoken instructions over a written state. None of that is available from d1-2B at any accuracy, because it has no audio encoder and no audio positions in its input schema.

Two independent data points should temper the pitch. The first is the evaluation above, where the 600M scored a shots-detection AUC of 0.580 and a rain-forecast AUC of 0.593 on real-data tasks — barely above chance, and behind every larger model tested. The second is a hands-on review that measured under 2GB of VRAM in use and found the model classifying delivery and tone in audio far more reliably than semantic meaning, with inference-style questions close to a coin flip. Both point the same way: this is a screening model. It is good at "what kind of thing is this," and it is not a substitute for a model that understands what was said.

That is not a criticism of a 587M checkpoint. It is what 587M buys when 381M of it is shared trunk. The reason to use it is cost and footprint — under 2GB of VRAM, a GGUF repository since 6 October, MLX builds since 12 October, and a decision in one forward pass — not fidelity.

A cascade that uses both

The mistake is treating these as competitors. They are two stages of the same filter, and the natural pipeline runs the cheap model first.

Stage one: Liquid AI d1-omni-600M takes the inbound item — a voice note, a support call, a written complaint with an attachment — and answers coarse questions. Is this a billing issue or a technical one? Is the caller angry? Does this message contain a request at all? At under 2GB and one pass, that is cheap enough to run on every item.

Stage two: anything the 600M puts near the middle of its scale, or anything that arrives with an image that needs reading, escalates to d1-2B. The 2B gets a 128K window, video input, and roughly triple the vision average, and it only sees the fraction of traffic that the first stage could not settle.

The thresholds are the work. Both cards return probabilities, and both tell you to calibrate on your own data — d1-2B's card in as many words. A cascade with an uncalibrated middle band either escalates everything, in which case the 600M was decoration, or escalates nothing, in which case the 2B never corrects the stage that cannot read.

There is a third stage in most real systems: the model that writes the reply. That is where a hosted API enters, and where OrcaRouter is relevant. Neither Liquid AI model is served by us, so the decision nodes stay on your own GPU; the generative step that consumes their labels can come from one OpenAI-compatible key covering 200-plus models, with 0% markup on provider list prices and automatic failover if a provider drops mid-traffic. The routing DSL is also the honest way to express the cascade itself — the two decision models as GPU-side steps, the reply generation as a hosted one, composed rather than glued together in application code.

What neither model does, and the third option

Neither writes text. Both return typed answers and probabilities with zero output tokens; if the next step needs prose, that is a different model. Neither handles video with audio: d1-2B takes video frames but no sound, the 600M takes sound but not alongside images, and the 30-second audio ceiling is a hard limit rather than a recommendation.

If the requirement is genuinely "audio and images in the same request," the answer is neither of these — it is d1-Omni-2B, the 2.17B sibling that Liquid AI created twenty-four seconds after d1-2B and which accepts text, pictures, video frames and audio clips in one media list. Its Decision Index score is 49.0 on the same v0.3 table, its vision average is 67.7, and it has the same absence of independent testing as d1-2B. It costs roughly four times the parameters of the 600M, which is the price of not choosing between modalities.

So the rule is short. If the state contains speech and nothing else needs seeing, Liquid AI d1-omni-600M is the only member of this pair that can run, and it should be treated as a screen. If the state is text, images or video and the answer has to hold up, d1-2B is the model — and it is the one with a published latency figure, a 128K window and a benchmark lead that survives being read row by row. If the state has both, neither is the answer, and the 2.17B omni model is.