Liquid d1 Decision Models: Edge Setup, Inputs and Evaluation Guide

Liquid d1 models make typed decisions rather than writing conversational answers. They can help an application choose a route, classify an input or estimate a score before another component performs the work. The practical question is whether the selected checkpoint handles your input mode accurately enough on the device where it will run.

Liquid's open d1 announcement introduces two checkpoints with different backbones and input capabilities. This guide uses that announcement and the official model cards; it does not claim an edge-device benchmark of our own.

Liquid d1 checkpoints and input modes

Choose by the required modality first. The two checkpoints share a decision-oriented interface, but their size and input paths differ.

The omni checkpoint is described as experimental. Its audio path accepts a speech clip of up to 30 seconds in the documented format. Do not infer support for an arbitrary combination of simultaneous image, audio and text streams from the word “omni.” Follow the checkpoint's actual input contract.

Both models return decisions without generating output tokens. That removes a text-generation step, but it does not remove preprocessing, model loading or computation. A zero-output-token field should not be read as a zero-resource request.

Load d1-3B with its decision interface

The d1-3B card specifies Transformers 5.14 or later and supplies custom model code. Install the documented dependencies in an isolated environment:

pip install "transformers>=5.14" torch torchvision pillow

This example pins the reviewed revision and uses an original routing question:

import torch
from transformers import AutoModel

device = "cuda" if torch.cuda.is_available() else "cpu"
dtype = torch.bfloat16 if device == "cuda" else torch.float32
model = AutoModel.from_pretrained(
    "LiquidAI/d1-3B",
    revision="051bcc464b01b9f92942b364d9586b0ef5912432",
    trust_remote_code=True,
    dtype=dtype,
).to(device)
questions = {
    "route": {
        "type": "choice",
        "instructions": "Choose the service that can handle this request.",
        "criteria": {
            "documents": "Find or explain information in supplied documents",
            "coding": "Inspect or change a software repository",
        },
    }
}
print(model.system_one("Summarize the attached installation notes.", questions))

Review the repository code before enabling trust_remote_code. Pinning identifies the artifact; it does not substitute for that review. Inspect the returned answer fields before wiring them into an application's routing logic.

The d1-3B card documents choice, yes/no and score questions. A choice returns the selected option and its probabilities. Your application decides what action follows; the model's output should not itself become permission to execute a privileged operation.

Evaluate probabilities on your own labels

Prepare examples from the traffic the router will receive. Label the correct destination, including ambiguous requests and cases no destination can handle. If Chinese and English are both part of the product, evaluate both rather than relying on a single-language test.

Compare the selected choice with the label, then look at the confidence distribution for correct and incorrect decisions. The publisher describes calibrated outputs, but calibration on your domain still needs examination. A high score on an unfamiliar category can be wrong.

Define a fallback for uncertainty. For example, an application could ask for a missing document or use a capable default service when the decision is unclear. Choose the threshold from observed errors and their consequences; there is no universal value that makes every router reliable.

Keep the question criteria under version control alongside the model revision. Changing a description from “explain code” to “modify code” can alter routes even when the checkpoint stays the same. That is an application change worth evaluating.

Treat audio and image tasks as separate tests

An image classifier's result depends on the preprocessing and visible content, while an audio decision depends on the recording and audio format. Add one modality at a time to the text baseline.

For images, test the subject and details the workflow needs, including unclear or low-quality examples. For audio, include realistic noise and variation in speakers. Measure what happens when the necessary evidence is absent, rather than testing only clean demonstrations.

The omni card provides its own precision guidance and warns against treating every GPU dtype as equivalent. In particular, its recommended GPU path differs from d1-3B's baseline. Keep those recommendations attached to the specific checkpoint instead of sharing one loader indiscriminately.

If your application currently uses a Qwen-derived classifier, our Decision 2.0 guide provides a comparison route. Use common labels and input cases while preserving each model's documented interface.

Plan an edge deployment and check the license

Measure cold loading, warm inference and preprocessing separately. Published warm-call latency does not include every cost of starting an application or reading a camera frame. Test at the intended input size and concurrency, with other device workloads present if that reflects deployment.

Memory capacity, power use and recovery after an interrupted request also affect suitability. An edge device that handles a clean demo may behave differently after prolonged use or when another process consumes memory. Keep a simple fallback while evaluating the local path.

The reviewed cards label the license as the custom LFM1.0 license, rather than Apache-2.0. Read the exact license files and dependency terms before redistribution or a commercial deployment. “Open-weight” describes access to weights; it does not by itself specify every permitted use.

Conclusion: use Liquid d1 for a defined decision job

Liquid d1 is worth evaluating when a pipeline needs a bounded choice or score, particularly where local inputs and edge execution matter. Select the input mode, establish a text baseline, then measure decision errors and resource use. Keep the model's probabilities separate from your application's authority to act.

Frequently asked questions

Can Liquid d1 write a final chat response?

Its documented role is typed decisions without generated output tokens. A separate component writes an answer when the application needs one.

Does d1-omni accept any multimodal combination?

Follow its documented text-plus-image or text-plus-audio paths. The checkpoint name does not establish arbitrary simultaneous input support.

Are these checkpoints licensed under Apache-2.0?

The reviewed cards identify the custom LFM1.0 license. Check those terms for the intended deployment rather than assuming a standard permissive license.