d1-2B vs Liquid AI d1-3B: The Smaller Model Wins the Board and Loses the Deployment

Four questions decide this matchup, and not one of them is "which model is better." Does the state include video? Does it exceed 32K tokens? Do you need to run it under llama.cpp? Can you afford to be the first person to test it? d1-2B is Liquid AI's 1.92B decision model, built on LFM3-VL-2B and scored 51.1 on the vendor's Decision Index table. Liquid AI d1-3B is the 3.12B model released on 7 October, built on LFM2.5-VL-3B and scored 49.0 on that same table. The newer, smaller model leads on average. It still loses three of the rows a deployment actually turns on, and it is the one of the two that has no llama.cpp path and no independent test result. This page is organised around those four questions rather than around the leaderboard, because the leaderboard answers none of them.

The short answer, by workload

• Text-only triage at volume — d1-2B, on the strength of 1,132 decisions per second for 64 batched states and 3.84GB of weights. The 3B's advantage on Typed Decisions is irrelevant when the output is a label.

• Diagram and chart reading — Liquid AI d1-3B. It wins AI2D 79.9 to 76.7, and it is the model with an independent run behind it.

• Long documents, long forms, long call transcripts — d1-2B. Its window is 128K tokens against 32,768, and the card is honest that reliability falls off past about 64K, which still leaves twice the 3B's total capacity.

• Edge boxes running llama.cpp — Liquid AI d1-3B, by default rather than by merit. It has a GGUF repository and a quantized weight-activation build; d1-2B has neither.

• Anything where a wrong call is expensive and untested — neither, until you have run both on your own data. Only one of them has even been run by a third party.

Same family, one generation apart

The two models are not siblings in the way the names suggest. Liquid AI d1-3B descends from LFM2.5-VL-3B, which derives from LFM2.5-2.6B-Base, and carries a 400M SigLIP2 NaFlex vision encoder. d1-2B descends from LFM3-VL-2B, the next family, on a backbone of 24 layers split between 13 gated short convolutions, 5 sliding-window attention layers and 6 global attention layers. That generational gap is where the benchmark inversion comes from: the newer architecture does more per parameter, so the smaller checkpoint can outscore the larger one on most rows.

• Parameters — 1.92B for d1-2B vs 3.12B for Liquid AI d1-3B.

• Download — 3.84GB vs 6.25GB of BF16 safetensors, both single-file.

• Context — 128K tokens vs 32,768.

• Vocabulary — 128,000 tokens vs the LFM2.5 vocabulary.

• Inputs — text or JSON, images or video, plus named questions, for d1-2B; text or JSON plus images for the 3B. Video is the cleanest capability difference between them.

• Languages — sixteen each, the same set.

• License — LFM Open License v1.0 for both, with commercial use conditioned on staying under $10,000,000 of annual revenue. There is no licensing reason to prefer either.

• Release — d1-3B's weights went up on 5 October and were announced on 7 October. d1-2B's repository was created on 24 October and has never had a post of its own; the only vendor sentence naming it is in the 27 October LFM3 launch.

One documentation detail is worth reading as a signal rather than a fact: Liquid AI's decision-model docs page now lists d1-2B, d1-omni-2B, d1-omni-600M, d1.1 and d1-ultra. It no longer lists d1-3B. The 3B has not been retired — its repo, GGUF and MLX builds are all live — but the vendor's own index has moved the open-weights slot to the 2B.

The scoreboard, read row by row

All of the figures below come from the benchmark table on d1-2B's model card, which scores four open d1 models on the same items with the same scorer. That matters because Liquid AI d1-3B's own card reports 48.57 on Decision Index 0.2.1 while this table reports 49.0 on version 0.3; the gap is the index edition, not a model change, and the card says so in a note. Comparing the two cards directly — 48.57 against 51.1 — would be subtracting across two different tests. Comparing inside this table is legitimate, and it is what the rest of this section does.

• Decision Index public suite v0.3 — 51.1 vs 49.0.

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

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

• JevBench v1.4.1 — 77.9 vs 76.2.

• ImajevBench v2.0-lite — 75.5 vs 64.0, the largest decision-side gap.

• WorkflowEvals — 81.6 vs 74.4.

• Liquid AI's internal board — 63.2 vs 58.8.

• Vision average — 70.2 vs 65.4 across eighteen benchmarks.

Every named decision suite in that table goes to the 2B, which is what the LFM3 launch post means when it calls d1-2B a replacement for d1-3B "with a third fewer parameters" and higher scores "on all four decision suites." The claim is accurate as written — and narrower than "beats the 3B," which is why the next paragraph exists. Then the three rows that go the other way. Fast Decisions is 58.8 for d1-2B against 59.3 for the 3B. Typed Decisions is 61.3 against 65.0. AI2D is 76.7 against 79.9. None of those gaps is large, and two of the three are inside a point, but they are the rows where the extra 1.2B parameters still buy something measurable: speed-oriented decisions, typed extraction, and diagram reading. If your pipeline's jobs are typed extraction from forms, the 3B is not the obsolete option the docs page implies.

Latency: the two headline numbers are not comparable

Liquid AI quotes 5.7 ms per decision for d1-2B and 8 ms for Liquid AI d1-3B, and those are not the same measurement. The 2B figure is on an H100 PCIe; the 3B figure is on an RTX 4090. A 2.3 ms gap between two different GPUs tells you nothing about which model is faster on your hardware, and repeating it as a comparison would be exactly the kind of number-laundering this blog exists to avoid.

There is one machine both cards report. On an Apple M5 Pro, d1-2B takes 18.6 ms per question and the 3B takes 30 ms — a 38% reduction on identical silicon. That is the honest speed comparison, and it points the same way as the size difference suggests. On batching, d1-2B handles 1,132 decisions per second on an H100 PCIe and 1,699 per second on an MI325X with 64 states in one call; the 3B's card reports 475 per second on an RTX 4090 and 1,106 per second on an MI325X. The MI325X row is the one both cards share, and there the 2B is ahead by roughly 54%.

The only independent test in existence ran the 3B

In mid-October, Efraín Garay ran eight decision models against Decision Index 0.3 and three real-data tasks, and published the results with code. Two findings bear on this comparison.

The first is reassuring for the scoreboard. He rebuilt the public suite from its kit, checked that the downloaded files matched the official ones, sampled 6,000 requests, and scored Liquid AI d1-3B at 49.11 — against Liquid's own 49.04 on the same rows and 48.99 on the full suite. That is the strongest evidence available that the v0.3 numbers in the table above are being computed correctly. It is evidence about the 3B, not about d1-2B, which he did not test.

The second is a warning about what an index measures. On a synthetic card-fraud bank of 10,000 payments, Liquid AI d1-3B scored an AUC of 0.314 — below chance, ranking anomalies as less suspicious than normal payments, because bursts of back-to-back payments landed at a median probability of 0.41 against 0.56 for a normal payment. The model was second on the public index and last on that task. The lesson transfers directly: d1-2B's 51.1 is a score on a general decision suite, and nobody has shown it predicts performance on your specific decision. The vendor says as much in its own card, in the instruction to calibrate thresholds on your own data.

What you can actually run today

This is where the matchup stops being close. Liquid AI d1-3B has had a GGUF repository since 6 October, an 8-bit weight-activation build since 7 October, and four MLX variants since 12 October. d1-2B got three MLX builds and an ONNX export on 27 October, and nothing else. There is no d1-2B GGUF, no quantization beyond MLX's 4-bit and 8-bit, and therefore no published llama.cpp path for the decision head — even though the base model, LFM3-VL-2B, has had its own GGUF since 19 October.

For a Transformers deployment the difference disappears: both load with trust_remote_code=True and expose the same system_one and system_one_batch calls. For an edge deployment it does not. If your stack is llama.cpp on a Jetson or a phone, the 3B is the only one of the two you can run without writing a runtime integration, and its published edge figures — 16 ms on Jetson AGX Thor, 26 ms on AGX Orin 64GB, 50 ms on Orin Nano — are the ones you can plan against.

Neither model is served by OrcaRouter, so choosing between them is a self-hosting decision either way. Where a router earns its place is one layer out: decision models rarely run alone, and the generative step that acts on a routing label usually comes from a hosted model. One OpenAI-compatible key for 200-plus models, a routing DSL that lets you compose those steps into one call, and automatic failover keep that half of the pipeline from becoming a second integration project while the decision node stays on your own hardware.

If you are migrating, three things change

The API surface is close enough that a port looks trivial and is not. First, the input contract: d1-3B takes images; d1-2B takes a media list that can include video, and its card describes the media as encoded once for all questions in a call. Code that passes a single image will run, but it will not use what the model was built for.

Second, the threshold. Both models return probabilities, and both need a decision threshold fitted on your data. A threshold tuned on d1-3B's calibration does not transfer — the calibration tables ship inside each repo, separately fitted — so a migration that keeps the old cutoff will produce a different operating point and, in a moderation or fraud path, a different error profile.

Third, the reliability cliff. The 128K window is the headline; the card says answers get less reliable past about 64K tokens of state. On the 3B the ceiling is 32,768, so a migration to d1-2B will usually be a straight capacity gain — but a pipeline that starts feeding 100K-token states because it now can is testing the part of the range the vendor has flagged as weaker.

The verdict is less symmetrical than the scoreboard. For a new build in Transformers, on text or images or video, with states that can run long, d1-2B is the better default and the cheaper one to run. For an edge deployment under llama.cpp, for typed extraction, or for diagram-heavy vision, Liquid AI d1-3B is still the model to pick — and it is the only one of the pair with any outside evidence behind it. The one thing not to do is choose on the 51.1-versus-49.0 line alone. Two points on a vendor's index, between two models nobody has run on your task, is not a decision; it is a tiebreak.