LiquidAI d1-3B Local Deployment: The Vision Decision Model That Can't Chat

On Hugging Face, LiquidAI/d1-3B has accumulated 10,843 downloads since its release. But many people discover something unusual after loading it: you can't get it to generate a single description, there's no text output whatsoever, and every request returns "output_tokens": 0 in the usage field.

Liquid AI calls d1-3B a "decision model." It reads text, JSON, and images, then directly answers questions you've predefined (yes/no, multiple choice, scale ratings) in a single forward pass. It doesn't write sentences. If what you want is a Qwen-VL or Gemma that can auto-caption your photo album, this model isn't for you; but if you've ever burned through a massive number of tokens on a 7B chat model just to answer a yes/no question, it might be exactly what you need.

What Kind of Model Is It, Really

Liquid AI's Open d1 series includes two models: d1-3B (text + images) and d1-omni-600M (text + images or text + audio, labeled as experimental).

D1-3B's specs are roughly as follows: 3.12B parameters, visual encoder is a shape-optimized version of SigLIP2 NaFlex (400M), context length 32,768 tokens, vocabulary 128,000, weight format Safetensors / BF16, base model is LFM2.5-VL-3B (text backbone weight-averaged with LFM2.5-2.6B), license is lfm1.0 (LFM Open License).

Architecturally it follows LFM2.5-VL-3B; what Liquid did is mainly at the weight level: averaging the weights of LFM2.5-2.6B with the VL model's text backbone, fine-tuning multiple checkpoints with different random seeds and data ratios, then merging them. The conclusion in Liquid's official blog is quite modest—long input training, shuffling option order, and fixing data shortcuts matter more than any fancy technique.

SigLIP2 NaFlex is a series of visual encoders proposed by Google. SigLIP stands for "Sigmoid Loss for Language-Image Pre-training," which replaces CLIP's softmax contrastive loss with sigmoid loss, eliminating the need for global normalization within a batch and making small-batch training more stable. NaFlex (Native Flexible Resolution) means the model can process images at their native aspect ratio and variable resolution, rather than forcing them into a fixed 224×224 or 384×384 stretch. This is especially important for decision-type tasks: when you're judging whether a web page screenshot contains an error popup, preserving native resolution and aspect ratio retains fine UI text and layout information, avoiding the loss of critical visual cues from scaling.

Weight averaging refers to linearly combining the parameters of two or more trained models into a new model by weight, for example mixing LFM2.5-2.6B's weights into the VL model's text backbone at a certain ratio. This approach is common in model merging and can transfer a pure text model's language capabilities to a multimodal model without retraining, at a cost far lower than pretraining from scratch. The downside is that the merged model may exhibit capability shifts, requiring checkpoint merging across multiple random seeds and data ratios to select a more balanced result—this is also the primary engineering approach Liquid adopted for d1-3B.

Three Question Types, Zero Output Tokens

D1-3B's invocation method is completely different from chat models. You need to define questions first, each with a type:

• noul: returns P(yes), the probability of "yes"
• choice: returns the selected option, confidence, and probability of each option
• score: returns expected level, confidence, and probability distribution on a 2–10 level ordinal scale

Multiple named questions can share the same "state" (such as a ticket, a document, an image) and be answered together in the same forward pass. The return structure is roughly {"answers": {...}, "usage": {"input_tokens": n, "output_tokens": 0}}.

For scenarios like routing, content moderation filters, or agent guardrails, this is actually a more practical API shape. You get probabilities, and you don't need to parse the malformed JSON that chat models occasionally spit out, like "Sure! Here's your answer:". The model card claims these answers are "calibrated," but whether calibration is good is another matter: Liquid hasn't published d1's calibration error data, and an OrcaRouter review also lists calibration error as the most obvious unresolved issue—you'll have to test it yourself.

Calibration is an important property of classification models, referring to whether the model's output probabilities match the actual accuracy rate. If a model gives a 0.9 probability of "yes" for 100 samples, a well-calibrated model should have roughly 90 that are actually "yes." A common metric is ECE (Expected Calibration Error), which buckets predicted probabilities, compares the difference between each bucket's average confidence and actual accuracy, then takes a weighted average. The model card says answers are "calibrated" but doesn't provide ECE or reliability diagrams, so this claim can't be verified. For scenarios like routing, moderation, and agent guardrails that use probabilities for threshold decisions, calibration error is often more critical than accuracy: a model with high accuracy but overconfidence will cause frequent misjudgments when you set a 0.9 threshold. Before deploying, it's advisable to plot a reliability diagram with your own data.

Benchmark Performance: Where Are Qwen-VL and Gemma

If you want to know how d1-3B compares to same-sized Qwen2.5-VL-3B or Gemma, the answer is: Liquid hasn't published such comparisons. It only compares d1-3B with other decision models and its own backbone model.

On Decision Index v0.2.1 (public split), d1-3B scores 48.57, the best result under 10B in Liquid's table, behind Winnow-12B (50.02) and ahead of Decider 35B-A3B (47.11). Note that other rows come from public leaderboards, while the d1-3B row is Liquid's own run using the official scorer rather than a leaderboard submission, so interpretation should leave some room.

For text tasks, d1-3B scores 85.3 on SQuAD 2.0 (Decider 4B is 76.0), Civil Comments 93.0, MASSIVE intent 87.3, PubMedQA 66.0, BoolQ 86.7, XNLI 85.0, PAWS-X 76.9, seven-item average 82.9. Decider 4B wins on BoolQ, XNLI, and MASSIVE. The model card version also includes HelpSteer2 (d1-3B 36.7 vs Decider 4B 42.0), and after inclusion the two averages narrow to 77.1 vs 76.2, which can only be called a narrow lead. Decision Index's Knowledge category is only 23.8, so don't expect it to have factual knowledge—its job is to judge the content you hand it.

Visual metrics are somewhat nuanced. On 11 image benchmarks, the model card reports d1-3B averaging 74.1 vs LFM2.5-VL-3B at 73.9, meaning converting it into a decision engine barely changed average visual quality. But item by item the differences are clear: on VL-RewardBench d1-3B scores 65.0, far exceeding LFM2.5-VL-3B's 50.9 (+14.1); MMVP 77.0 vs 73.7; but CV-Bench 82.1 vs 87.6, VisualWebBench 71.4 vs 78.3, POPE 88.5 vs 90.1. It's stronger as a visual "judge," but its spatial reasoning and ability to read web screenshots have clearly declined. If your plan is to "judge whether this UI screenshot has an error popup," the 6.9-point gap on VisualWebBench is worth hesitating over.

Liquid not including Qwen-VL and Gemma comparisons is less deliberate avoidance and more because comparing generative models with decision models isn't quite apples-to-apples anyway. But it does leave the question to users: is a 3B classifier really better than the VLM prompt you're already running? Before switching, build an evaluation set of around 200 items with your own data.

The License Says "Open," But Read the Fine Print

Liquid's blog says you can download, fine-tune, and deploy "without restrictions." The tag on Hugging Face is lfm1.0, i.e., LFM Open License v1.0. It's based on Apache 2.0, but with one key change: once a company's annual revenue exceeds $10 million, commercial rights terminate, and a paid license must be purchased from Liquid thereafter. This restriction also applies to fine-tuned derivative models. The license has no copyleft clause, so your fine-tuned results can remain closed-source.

For independent developers and most startups this isn't a problem. But for companies of a certain scale, the phrase "without restrictions" isn't accurate, and Liquid could have avoided using it.

GGUF Sizes and Latency: 4090, M5 Pro, Jetson

Liquid hasn't published memory or VRAM usage figures, but the official GGUF repository provides file sizes that serve as a good lower bound: Q4_K_M is 1.67 GB, Q8_0 is 2.87 GB, BF16/F16 is 5.4 GB. Q4_K_M is more than enough on a laptop, and on paper fits into recent phones—but Liquid's own speed table doesn't include phones.

For published latency (single request): RTX 4090 (bf16) 8 ms per question, 17 ms for 384px images, batched throughput 475 states/s; Apple M5 Pro (MPS) 30 ms / 62 ms / 78 states/s; Jetson AGX Orin 64GB 26 ms / 83 ms / 110 states/s; Jetson Orin Nano 50 ms / 202 ms / 38 states/s. The 4090's 8 ms depends on model.compile(mode="reduce-overhead"); without it, it's 16 ms. A 3.4k token state takes 640 ms on M5 Pro and 1640 ms on Orin Nano—long documents are a real time cost even without decoding.

GGUF is the model file format used by llama.cpp, replacing the earlier GGML. It packs weights, vocabulary, quantization metadata, and prompt templates into a single file, supports mmap loading, and can run on CPU, Metal, CUDA, ROCm, and other backends. Q4_K_M, Q8_0 in filenames are quantization schemes: Q8_0 is 8 bits per weight, nearly lossless; Q4_K_M is 4-bit quantization using k-quant grouping and mixing tensors of different precisions (M indicates medium quality tier), about a quarter of BF16's size, with accuracy loss acceptable for most classification tasks. Additionally, state in the d1 context refers to the context object a request needs to judge (a piece of text, a JSON, one or more images); multiple questions sharing the same state is what allows reusing the KV cache in a single forward pass, which is precisely why it saves more compute than calling a chat model per question.

How to Run d1-3B Locally

Transformers

Requires version 5.14 or newer, with trust_remote_code=True enabled:

pip install "transformers>=5.14" torch torchvision pillow

import torch
from transformers import AutoModel

device = "cuda" if torch.cuda.is_available() else "mps" if torch.backends.mps.is_available() else "cpu"
dtype = torch.float32 if device == "cpu" else torch.bfloat16

model = AutoModel.from_pretrained("LiquidAI/d1-3B", trust_remote_code=True, dtype=dtype).to(device)
# then: model.system_one(state, questions, images=None)
# or:   model.system_one_batch([(state, questions[, images]), ...])

llama.cpp

Liquid claims day-one support. The GGUF model card's quick start pulls the Q8_0 file; for the 1.67 GB version, just change the tag to Q4_K_M:

llama-server -hf LiquidAI/d1-3B-GGUF:Q8_0

Then send a POST request to /v1/systemone with a body containing state (or null for image-only), optional base64 images, and a questions object.

curl http://127.0.0.1:8080/v1/systemone -H "Content-Type: application/json" -d '{
  "state": "I was charged twice this month, please refund one of them.",
  "questions": {
    "refund":  {"type": "noul", "instructions": "Is the customer asking for a refund?"},
    "team":    {"type": "choice", "instructions": "Which team should handle this?",
                "criteria": {"billing": "Charges, refunds, invoices", "technical": "App or site faults",
                             "fraud": "Suspected unauthorised use"}},
    "urgency": {"type": "score", "instructions": "How urgent is this?",
                "criteria": ["Can wait", "Today", "Blocking the customer now"]}
  }
}'

This isn't /v1/chat/completions, so your existing OpenAI client code won't work directly. The GGUF page doesn't specify which llama.cpp version is required, so it's best to update to the latest first.

vLLM, SGLang, Docker

The Hugging Face "Use this model" panel generates snippets for vLLM, SGLang, and docker model run hf.co/LiquidAI/d1-3B, but these are auto-generated by the Hub. The model card and blog don't mention them, and given that d1 uses a custom system_one API, it's advisable to test before trusting.

MLX

The model card, GGUF card, and blog don't mention MLX. Currently on Mac, your options are PyTorch on MPS (the source of Liquid's M5 Pro data) or llama.cpp with Metal.

Who Should Download It

If you're working on routers, content filters, agent guardrails, rerankers, or camera pipelines that need yes/no judgments on every frame, download it. If you need captions, OCR output, or any generated content to show users as text, skip it—generative VLMs remain the more appropriate tool, and none of Liquid's published data suggests d1-3B can compete there.

"A visual model that doesn't talk" may be the most practical thing Liquid has released this year, because most production VLM calls I've seen are essentially classifiers disguised as chat. A 3B visual model that runs fully offline and only answers the questions you specify—what would you use it for? Before calibrating it yourself, would you trust the confidence scores it gives?