LiquidAI Open-D1 Answers In 16ms On Jetson Thor

LiquidAI Open d1 Decision Models for Edge Explained

By Indie Kings | October 13, 2026

Updated October 13, 2026: Liquid AI has released two open decision models called d1-3B and d1-omni-600M that answer classification style questions in a single forward pass with no token generation, per the Hugging Face team article Multimodal open d1 decision models for the edge by the LiquidAI team, Oct 7 2026.

Open d1 decision models header

Image: Open d1 header. Credit: Hugging Face blog, LiquidAI.

What open d1 decision models are

Open d1 is a pair of open decision models from Liquid AI described on Hugging Face. The core idea is simple to state and important for edge hardware. These models do not generate tokens one by one. They read the input and return an answer in a single forward pass. That design fits classification, intent detection, safety labels, question answering selections, and other choice tasks where the output is a decision rather than a paragraph.

Per the Hugging Face team article Multimodal open d1 decision models for the edge by the LiquidAI team, Oct 7 2026, the release includes d1-3B and d1-omni-600M, with d1-omni-600M labeled as experimental. Both models follow the same high level pattern. A user supplies text plus an optional image or audio input depending on the model, plus a list of candidate answers or labels. The model scores those options directly. There is no streaming text, no stop token handling, and no parsing of free form output to extract a label.

This matters for products that need fast and repeatable choices. A single forward pass answer is easier to time, easier to batch, and easier to test than open ended generation. It also reduces work on small devices because the model does a fixed amount of scoring instead of an unknown number of decode steps. For gamers and hardware readers, the useful comparison is menu logic, moderation filters, voice intent routing, and in game help systems where latency matters more than long prose.

The article frames these models as decision models rather than chat models. Chat models can answer anything but need token generation and output parsing to turn words into a choice. Decision models skip that step. They output the choice itself. That choice can be which answer is correct, which intent matches, which comment label applies, or which medical answer option fits. The same pattern covers many benchmarks at once, which is why the announcement reports both a Decision Index score and a seven dataset mean.

It helps to be clear about what multimodal means here. For d1-3B, multimodal means text plus images. For d1-omni-600M, multimodal means text plus image or text plus audio. The text input carries the question, the instruction, and the candidate labels. The image or audio input adds context that text alone cannot carry. The model then selects among the supplied options in one pass. This is different from captioning or transcription because the goal is selection, not generation.

Edge deployment is the other half of the story. The announcement reports timing on NVIDIA edge boards and desktop and data center GPUs, with NVIDIA named for the edge and desktop results. It also names AMD for data center timing. Hugging Face hosts the article, the model pages, and the demo pattern, while Liquid AI supplies the model weights and the System One interface. Readers who track edge AI should note that balance. The models are open, the interface is code based, and the speed claims focus on practical latency for one question, three questions, images, and packed states.

This site previously covered decision models in llama.cpp, which gives useful context for readers who follow local inference.

Model lineup and inputs

The lineup has two entries with different sizes, bases, and input types. The larger model targets best accuracy under 10B parameters. The smaller model targets research into very small multimodal decisions with audio support. Both use the System One naming for inference, with a single item call and a batch call.

d1-3B is built from LFM2.5-VL-3B, described as a decoder only vision language model. It handles text plus images. That makes it the pick when an image helps decide the answer, such as visual question answering, image grounded classification, or UI understanding where the screenshot matters. The parameter scale is 3B, which fits the under 10B group used for the Decision Index comparison.

d1-omni-600M is experimental and built from LFM2.5-Encoder-350M, described as a bidirectional encoder, plus vision and audio encoders. It handles text plus image or text plus audio. That makes it the research option for voice intent and sound aware choices as well as image aware choices. The parameter scale is 600M, which is much smaller than the 3B model and much smaller than the 2B baseline it is compared against in the seven dataset mean.

The distinction between decoder only and bidirectional encoder matters for readers who follow model design. A decoder only vision language model processes inputs in order and is familiar from recent vision language releases. A bidirectional encoder can read text in both directions, which can help classification style scoring. The announcement does not ask readers to pick based on theory. It asks readers to pick based on inputs and maturity. Use d1-3B for text plus image decisions today. Treat d1-omni-600M as early research for text plus image or text plus audio decisions.

Input format is consistent across the family. The caller provides the state, meaning the question plus context, and the candidate choices. The model returns scores or a selection through System One calls named model.system_one and system_one_batch in the announcement. This keeps application code simple. There is no prompt template for parsing letters, no JSON repair step, and no retry loop because the model rambled. The app sends options and gets a decision.

Open d1 models. Standing Per HF/LiquidAI.
ModelBase reportedInputs reportedStatus reported
d1-3BLFM2.5-VL-3B decoder only VLMText plus imagesOpen decision model
d1-omni-600MLFM2.5-Encoder-350M bidirectional encoder plus vision and audio encodersText plus image or text plus audioExperimental

Think of the table above as the buying guide. If the task includes images and needs the strongest reported accuracy, d1-3B is the listed answer. If the task includes audio or must fit a very small budget and can accept experimental status, d1-omni-600M is the research answer. Both avoid token generation. Both use a single forward pass. The difference is base architecture, input coverage, size, and maturity.

For developers, the practical takeaway is that one interface covers both models. Learn model.system_one for one state and system_one_batch for many states, then swap model IDs as needed. The announcement also points to a System One Arcade Space demo, which is useful for trying the choice style interaction before writing integration code. That demo pattern shows the same idea as the code path. Provide context, provide options, read back the selected option.

Decision Index scores

Decision Index 0.2.1 is the headline benchmark in the announcement. Per HF/LiquidAI, d1-3B scores 48.57 and is the best model under 10B on that index. The same comparison puts Decider 35B-A3B at 47.11, which means the 3B decision model scores ahead of a much larger 35B class model on this specific decision focused index. The article also says d1-3B sits ahead of 4B and 9B models, which reinforces the claim that size alone does not win this test.

Readers should treat Decision Index as a decision skill test, not a chat quality test. A higher score means better selection across the tasks in that index version. Version numbering matters here. The reported version is 0.2.1, so future versions can change tasks and weights. For recency, the article date is Oct 7 2026 and this summary was updated Oct 13 2026. Any comparison should cite version 0.2.1 when repeating the 48.57 number.

The 48.57 versus 47.11 gap is narrow in absolute points but notable because of the size gap. A 3B model beating a 35B class model on a decision index suggests that direct scoring can be more efficient than generation plus parsing for choice tasks. It does not mean the smaller model knows more facts about the world. It means it selects better among given options under this test. That is exactly what edge products need when the options are known in advance, such as intent labels, safety categories, or answer choices.

For hardware context, under 10B is a useful cutoff. Models under 10B are far more likely to fit on high end edge boards and consumer GPUs with usable speed. A best under 10B claim therefore speaks directly to builders who cannot ship a 35B model to a small device. Pair that claim with the latency table later in this article. Accuracy without speed does not ship on the edge. Here the announcement gives both: a leading under 10B score plus millisecond scale timings on NVIDIA edge hardware and GPUs.

It is also worth noting what is not claimed. The article does not claim d1-3B is the best model at every size or on every academic leaderboard. It claims best under 10B on Decision Index 0.2.1. Keep that scope when citing the number. The seven dataset mean in the next section is a separate check with its own scope and its own baselines.

Seven dataset means

The second accuracy check is a seven dataset mean. Per HF/LiquidAI, d1-3B averages 82.9 and ranks top among the listed models, while d1-omni-600M averages 78.4 and beats Decider 2B at 77.1. Those three numbers are the citable means. They summarize performance across SQuAD2.0, Civil Comments, MASSIVE intent, PubMedQA, BoolQ, XNLI, and PAWS-X as listed in the announcement table. The dataset mix covers reading comprehension style selection, toxicity style labeling, intent detection, medical question answering selection, yes no questions, cross lingual inference, and paraphrase detection.

Each dataset tests a different kind of choice. SQuAD2.0 tests whether the model can select answers and handle unanswerable cases in the decision framing. Civil Comments tests comment labeling where consistent choices matter for moderation. MASSIVE intent tests voice assistant style intent routing, which is directly relevant to edge devices with microphones. PubMedQA tests biomedical yes no maybe style selection. BoolQ tests yes no questions from real queries. XNLI tests inference across languages. PAWS-X tests paraphrase choices across languages. A mean across all seven rewards models that are steady rather than spiky.

The d1-omni-600M result deserves attention because of size. At 600M it beats a 2B baseline on the mean, 78.4 versus 77.1. That is the kind of efficiency result that matters for always on or battery sensitive use. It does not make the small model stronger than d1-3B, since 78.4 trails 82.9 by a clear margin. It does suggest that the encoder plus audio and vision design can deliver solid choice accuracy at very small scale. Remember its experimental label before planning a product around it.

Seven dataset mean and Decision Index. Standing Per HF/LiquidAI.
ModelSeven dataset mean reportedDecision Index 0.2.1 reported
d1-3B82.9, top among listed models48.57, best under 10B
d1-omni-600M experimental78.4, ahead of Decider 2B 77.1Not listed in announcement
Decider 2B baseline77.1Not listed in announcement
Decider 35B-A3B baselineNot listed in announcement47.11

The datasets in the mean are SQuAD2.0, Civil Comments, MASSIVE intent, PubMedQA, BoolQ, XNLI, and PAWS-X. Readers who want to reproduce or cite details should use the full Hugging Face team article for per dataset rows and methods. This summary keeps only the means that are clearly stated in the supplied context: 82.9 for d1-3B, 78.4 for d1-omni-600M, and 77.1 for Decider 2B. Standing Per HF/LiquidAI applies to those orderings.

A practical reading is straightforward. If accuracy is the top goal and the inputs are text plus image, d1-3B leads. If size is the top goal and audio matters, test d1-omni-600M with the understanding that it is early research. If a team already uses Decider 2B, the 78.4 versus 77.1 comparison gives a reason to benchmark the 600M model on their own labels. Always retest on product data because public means do not guarantee results on private labels.

Speed on edge and GPU

Speed is reported for d1-3B with help from NVIDIA, plus one AMD data point. The announcement gives one question latency on several devices, a three question multiplier, image latency on two GPUs, and packed throughput for 64 states. These numbers describe decision latency, not token streaming speed, because there is no token generation. That makes the timings easier to plan around for real time features.

For one question, d1-3B is reported at 16ms on AGX Thor, 26ms on AGX Orin 64GB, 50ms on Orin Nano, 8ms on RTX 4090, and 9ms on AMD MI325X. Those five numbers cover a useful range from small edge to desktop to data center. AGX Thor leads the edge list, Orin 64GB sits in the middle, and Orin Nano is the slowest of the three but still at 50ms for one decision. The desktop and data center GPUs are in single digit milliseconds, which leaves headroom for app logic around the model call.

For three questions, the announcement says cost is 1.3 times one question. That sublinear scaling matters for batching. It means asking three choices together costs much less than asking three times in a row. Builders should use the batch call when possible. The same logic leads to the packed test with 64 states, reported at 475 states per second on RTX 4090 and 1106 states per second on AMD MI325X. Packed scoring is the path for logs, queues, and offline labeling where many decisions must clear quickly.

For images at 384px, the announcement says under 18ms on both GPUs. That further supports image aware decisions in interactive apps. A sub 18ms image plus text decision can fit inside a 60 frames per second budget with room to spare on the GPU side, before adding camera, UI, and network costs. On edge boards the image path will cost more than text only, so teams should measure their exact resolution and pipeline rather than assuming desktop numbers carry over.

List readers can use this short recap for planning. One question: 16ms AGX Thor, 26ms AGX Orin 64GB, 50ms Orin Nano, 8ms RTX 4090, 9ms AMD MI325X. Three questions: 1.3 times one question. Image at 384px: under 18ms on both GPUs. Packed 64 states: 475 per second on RTX 4090 and 1106 per second on AMD MI325X. All speed figures in this section are per HF/LiquidAI for d1-3B. Speed for d1-omni is not reported because it is early research.

  • One question d1-3B: 16ms AGX Thor, 26ms AGX Orin 64GB, 50ms Orin Nano, 8ms RTX 4090, 9ms AMD MI325X
  • Three questions d1-3B: 1.3 times the one question time
  • 384px image d1-3B: under 18ms on both GPUs
  • Packed 64 states d1-3B: 475 per second on RTX 4090, 1106 per second on AMD MI325X
  • d1-omni-600M speed: not reported, early research

The hardware names matter for shoppers. NVIDIA covers the edge boards and the RTX 4090 result, while AMD covers the MI325X result. Hugging Face is where the article and models live, and Liquid AI is the model supplier. None of these names imply endorsement of a specific board for every workload. They identify where each timed run happened. A team shipping on Orin Nano should budget around the 50ms figure plus image and app overhead, while a team shipping on AGX Thor can plan around 16ms for text style decisions.

How to use System One

Usage follows the standard Hugging Face pattern with a few required pieces. The announcement lists pip packages transformers at version 5.14 or newer plus torch, torchvision, and pillow. It also requires trust_remote_code, plus the System One calls model.system_one and system_one_batch. There is also a System One Arcade Space demo for interactive tries.

Start with an environment that has Python and GPU drivers working, then install the listed packages. The transformers floor matters, so confirm version 5.14 or newer before debugging model loading. Torch supplies compute, torchvision supplies image handling, and pillow supplies image loading. Those four pieces match the text plus image scope of d1-3B. Audio work with d1-omni-600M will need audio handling in app code, but the announcement does not list a separate audio package in the supplied context, so follow the model card for exact extras.

Loading uses trust_remote_code because System One adds custom code. Only enable that flag for model sources the team trusts, which here means the official Liquid AI release on Hugging Face. After loading, call model.system_one for a single state and system_one_batch for many states. A state includes the question and context, while the choices list carries the allowed answers. The return is a decision, not a paragraph, so app code can branch directly without parsing.

pip install transformers>=5.14 torch torchvision pillow
from transformers import AutoModel
model = AutoModel.from_pretrained("LiquidAI/d1-3B", trust_remote_code=True)
result = model.system_one(state="Is this comment toxic?", choices=["yes", "no"])
batch = model.system_one_batch(states=[state1, state2, state3], choices=choices)

The snippet above is a shape guide, not a copy paste guarantee. Model IDs, class names, and argument names should be taken from the official model card linked from the Hugging Face article. The key facts to preserve are the package floor of transformers 5.14 or newer, the torch plus torchvision plus pillow set, trust_remote_code, and the two call names model.system_one and system_one_batch. Keep those exact when adapting the sample to a real repo.

The System One Arcade Space demo is the fastest way to build intuition. It shows the same select among options flow without local setup. Try a toxicity label, an intent label, and a yes no question to see how strict the option list must be. Then move to code once the labels feel stable. For edge teams, test the same labels on device with the batch path, since three questions cost only 1.3 times one question and packed runs clear far more states per second.

Limits and what is next

Several limits are stated clearly and should stay in any fair summary. Speed for d1-omni-600M is not reported because the model is early research. Teams should not assume it matches d1-3B latency or throughput. Vision and audio benchmarks are described as an open problem, which means image and sound aware decision quality needs more public tests. Decision Index v0.3 is noted with a private vision split, which signals that the next index version will probe vision decisions more directly but keeps that split private for now.

Those limits shape how to adopt the models. Use d1-3B where text plus image decisions need measured accuracy and measured speed today. Pilot d1-omni-600M where tiny size or audio input is the point, and budget time for custom evaluation. Do not present experimental results as production guarantees. The 78.4 mean is promising against Decider 2B at 77.1, but product labels, languages, and audio conditions can shift results.

Another limit is scope. Decision models excel when options are known. They do not replace chat models for open ended writing, brainstorming, or long explanations. A good system pairs them: a decision model routes, filters, or selects, then a generator speaks only when needed. That pattern saves time on the edge because most inputs need only a choice. Reserve generation for the few cases where words must be shown to the user.

For next steps, watch Decision Index v0.3 and its private vision split. A private split reduces leakage from training into testing, which can make vision scores more trustworthy. Also watch for more d1-omni timing and for vision plus audio benchmark releases that address the open problem note. Until then, cite version numbers with every score: Decision Index 0.2.1 for the 48.57 claim and the seven dataset mean for the 82.9 and 78.4 claims, all Per HF/LiquidAI.

FAQ

What are Liquid AI open d1 models?

They are two open decision models, d1-3B and experimental d1-omni-600M, that return answers in a single forward pass with no token generation, per the Hugging Face team article Multimodal open d1 decision models for the edge by the LiquidAI team, Oct 7 2026.

What inputs do d1-3B and d1-omni-600M accept?

d1-3B accepts text plus images from its LFM2.5-VL-3B decoder only base, while d1-omni-600M accepts text plus image or text plus audio from its LFM2.5-Encoder-350M bidirectional encoder plus vision and audio encoders.

How accurate are they on public checks?

Per HF/LiquidAI, d1-3B scores 48.57 on Decision Index 0.2.1 for best under 10B and averages 82.9 across seven datasets, while d1-omni-600M averages 78.4 and beats Decider 2B at 77.1.

How fast is d1-3B on edge and GPU hardware?

Per HF/LiquidAI, one question takes 16ms on AGX Thor, 26ms on AGX Orin 64GB, 50ms on Orin Nano, 8ms on RTX 4090, and 9ms on AMD MI325X, with three questions at 1.3 times one and packed 64 states at 475 per second on RTX 4090 and 1106 per second on AMD MI325X.

How do developers call these models in code?

Install transformers 5.14 or newer plus torch, torchvision, and pillow, load with trust_remote_code, then use model.system_one for one state and system_one_batch for batches, with a System One Arcade Space demo for trials.

What remains unproven or next?

Speed for d1-omni-600M is not reported as early research, vision and audio benchmarks remain an open problem, and Decision Index v0.3 adds a private vision split to watch.

Bottom Line

Liquid AI open d1 gives edge builders a focused tool: single forward pass decisions with no token generation. d1-3B leads the cited accuracy checks at 48.57 on Decision Index 0.2.1 and 82.9 across seven datasets, with millisecond scale timing from Orin Nano to AGX Thor to RTX 4090 and AMD MI325X. d1-omni-600M is the experimental small bet for text plus image or text plus audio at 78.4, ahead of Decider 2B at 77.1. Standing Per HF/LiquidAI on all scores. Start with the System One Arcade Space demo, then integrate model.system_one and system_one_batch where choices must be fast and repeatable.

Sources

Primary source with methods, tables, and demo links:

Share