Liquid Open d1: Zero Output Tokens, Named Jetson Latencies, and What a Decision Model Actually Is

On October 7, Liquid AI open-weighted two models in its d1 family: d1-3B and experimental d1-omni-600M. Neither is a chat model. You hand them a state (text, JSON, images — and for the small one, audio) plus a set of named questions, and they return calibrated, typed answers in one forward pass. Every response reports output_tokens: 0.

I read this the same way I read JEV-27B: agents burn most of their wall-clock on small typed decisions — which queue owns the ticket, is this phishing, how urgent is this on a 0–5 scale — not on another thousand-token reasoning essay. The useful release is not “a smaller LLM.” It is a serving contract with named milliseconds on Jetson and RTX, plus an honest split between a quality 3B and a footprint 600M.

What a decision model returns

Liquid’s Decision Index schema has three question types:

Several questions share one state in a single call. The API surface is system_one(state, questions, …) and a packed system_one_batch. That is the whole point: no JSON scrape, no stop-sequence lottery, no “please answer only with …” prompt tax.

Recommended uses on the cards: routing and triage, moderation, intent/topic classification, reranking, LLM-as-a-judge scoring, agent guardrails, visual inspection, and (for omni) voice-command routing. If you need prose, you are in the wrong family.

Two backbones, two jobs

d1-3B starts from LFM2.5-VL-3B, a decoder-only vision-language model. Liquid averaged LFM2.5-2.6B with that model’s text backbone, fine-tuned several seeds/mixtures, and merged again. Specs that matter for deployment:

• 3.12B total parameters
• SigLIP2 NaFlex 400M vision encoder
• 32,768-token context
• Vocabulary 128,000

d1-omni-600M starts from LFM2.5-Encoder-350M, a bidirectional encoder, then adds modalities in stages. Specs:

• 587M total (card breakdown: ~381M shared trunk + decision head, ~94M vision, ~112M audio)
• Vision tower from LFM2.5-VL-450M
• Audio: 17-layer FastConformer
• Context 16,384 tokens (text + image + audio positions); with images, state+question text is cut to 896 tokens as trained
• Vocabulary 65,536
• One request carries images or audio, never both (both raises ValueError)
• Audio clips capped at 30 seconds; audio training is English speaker↔assistant requests only

Liquid is explicit that omni is an early research release with no published latency. That honesty is useful: treat omni as “does the modality path exist,” not as a Jetson BOM row.

License for both is LFM Open License v1.0: free commercial use below $10M annual revenue, not Apache. If your legal stack assumes Apache-by-default for every HF card, read the LICENSE file before you ship.

Decision Index and the text table

Liquid scored d1-3B with the official Decision Index v0.2.1 scorer (not a leaderboard submission) at 48.57. That is the best under 10B in their table, ahead of Decider 35B-A3B at 47.11, and behind only Winnow-12B at 50.02. Category split for d1-3B: Tools 74.5, Arts 36.3, Language 56.4, Retrieval 52.8, Knowledge 23.8. Knowledge is the soft spot — same pattern I flagged on JEV when the head is narrow.

On seven public text benches (SQuAD 2.0, Civil Comments, MASSIVE intent, PubMedQA, BoolQ, XNLI, PAWS-X), Liquid’s card mean is 82.9 for d1-3B and 78.4 for d1-omni-600M, versus Decider 4B 81.1 and Decider 2B 77.1. Omni leads Civil Comments (95.8) and PAWS-X (79.5) in that table — small model, strong toxicity/paraphrase rows.

Vision: d1-3B averages 74.1 on 11 public image benchmarks against 73.9 for its LFM2.5-VL-3B base. Liquid does not publish Decision Index vision or audio decision benches here; they call dedicated audio decision benchmarks an open problem. Believe the Jetson demos for visual loop latency, not an audio Decision Index you do not have.

The latency table I would actually use

Warm calls, one request at a time. Columns: one question; three questions over one state; a 3.4K-token state; a 384px image; throughput with 64 states packed.

Edge

GPU (bf16, median of 20)

Asterisks that matter for operators: the RTX 8 ms row uses model.compile(mode="reduce-overhead") (CUDA graphs). Without it, one question is 16 ms. First call of a new shape pays compile/kernel selection — warm the shapes you serve. For omni on GPU, Liquid recommends float16; they say bf16 changed the top answer on 0.8% of text and 1.7% of audio rows in their checks.

Three questions on AGX Thor take 20 ms versus 16 ms for one — about 1.3×, not 3×. That is the batching property you want when a ticket needs refund / team / urgency in one pass.

How I would wire it vs JEV

JEV-27B is a frozen Qwen3.8-27B student for System 1 decisions with a published 137 ms on one B200 in AutoTrust’s harness. d1-3B is a different bet: ~10× fewer parameters, native vision in the same pass, and edge numbers that fit a Jetson loop. I would not rematch their Decision Index rows as if they shared a harness — Liquid scored itself; AutoTrust scored itself. The operational question is which latency class your agent budget allows.

For a cluster that already runs generative serving (see vLLM 0.31 and the Vera Rubin day-zero notes), I would put d1-3B on a small GPU or Jetson as a side car: triage and guardrails at milliseconds, generative model only when the decision head says the ticket needs prose or tool use. Omni is the experiment for voice-in routing once you accept the English-clip and no-latency-card caveats.

How I would use this

1. Prototype with system_one on three named questions over real tickets before you touch a generative judge.
2. Measure your shapes with and without compile(reduce-overhead) on the GPU you will ship.
3. Keep omni off the critical path until Liquid publishes latency — or until you own the numbers.
4. Read LFM Open v1.0 before commercial deploy; the $10M ARR line is not decorative.

Primary sources: Liquid open d1 blog, Hugging Face open-d1 post, d1-3B card, d1-omni-600M card. Related on this site: JEV-27B, Holo4.

Related: Vera Rubin Day Zero: What SGLang Changed in the Kernels, and What vLLM Measured on AgentX · RTX Spark N1X: The Windows Numbers That Matter Are TDP, Memory Ceiling, and Prefill · Claude Haiku 5.5: The Price Cut Is Real, but Read the 100K Tier, the Tokenizer, and the Output Bill.

Anpoo Sivanadi, Staff Software Engineer