LiquidAI d1-omni-600M takes text, images and speech, and by design it can't write a single sentence back. It returns typed answers (yes/no, a pick from named options, a score) read straight off the model's probability distribution, with "output_tokens": 0 in every response.
If you've been looking for a multimodal model small enough for a Raspberry Pi or a phone, keep that in mind before you get excited. Think of it as a flexible classifier you program with plain-English questions, at 670 MB in Q8_0 GGUF with llama.cpp support already merged, so on a Pi 5 it comes down to one llama-server command and the right batch flags (both below). For a lot of edge projects (moderation, intent routing, "is someone at the door") that's more useful than a tiny chatbot would be.
What d1-omni-600M actually is
Liquid AI released it on October 7, 2026 alongside the bigger d1-3B, calling the 600M an "experimental checkpoint" in the launch post. From the model card:
- 587M parameters total: a 381M shared trunk plus decision head, a 94M SigLIP2 vision encoder (taken from LFM2.5-VL-450M), and a 112M 17-layer FastConformer audio encoder
- Built on LFM2.5-Encoder-350M, a bidirectional encoder, so this isn't a decoder with a classifier bolted on
- 16,384-token context across text, image and audio positions
- 15 languages tagged, from English and German to Arabic, Hindi, Japanese and Chinese
You pass a "state" (a string, any JSON value, or None if the media is the whole input) plus a dict of named questions. Three question types exist: noul (yes/no), choice and score (2 to 10 ordered levels). All questions over one state get answered in a single forward pass, and the media is encoded once for all of them.
What "omni" means here, and where it stops
The modalities are real, but every one of them comes with a footnote:
- Images: several per request, tiled for large frames. When images are attached, the state and question text get cut to 896 tokens, because that's how it was trained.
- Audio: one 16 kHz mono clip, max 30 seconds. The card warns that audio training used requests between an English speaker and an assistant. Don't expect it to classify a German voice memo well.
- Not both: a request can carry images or audio, never both. Passing both raises a
ValueError.
So a "doorbell camera plus what the visitor said" decision in one call doesn't work. You'd need two calls.
The benchmarks: ignore the headline number, read the table
On Liquid's own Decision Index 0.2.1, d1-omni-600M scores 15.95. d1-3B gets 48.57 and Decider 2B gets 28.97. The Knowledge sub-score is 8.3. Read literally, that looks bad, and for anything that needs world knowledge or multi-step judgment, it is bad.
On narrow classification tasks it does a lot better (model card, Liquid's internal evals):
| Benchmark | d1-omni-600M | d1-3B | Decider 4B | Decider 2B |
|---|---|---|---|---|
| Civil Comments | 95.8 | 93.0 | 92.8 | 93.6 |
| MASSIVE intent | 86.1 | 87.3 | 88.3 | 81.1 |
| PAWS-X | 79.5 | 76.9 | 69.8 | 59.5 |
| BoolQ | 77.7 | 86.7 | 89.0 | 87.3 |
| SQuAD 2.0 | 74.0 | 85.3 | 76.0 | 67.7 |
| XNLI | 74.7 | 85.0 | 88.6 | 85.0 |
| PubMedQA | 61.3 | 66.0 | 63.3 | 65.7 |
| Mean | 78.4 | 82.9 | 81.1 | 77.1 |
It has the best moderation score in the table and beats Decider 2B on the mean, while being about a quarter of its size. My read: use it for routing, moderation, intent detection and "is there a person in this frame" checks. Don't ask it questions where the answer depends on knowing things.
Two caveats. All of these numbers come from the vendor, and there's no independent eval yet. Liquid also publishes zero speed numbers for this model: "We don't report inference numbers for d1-omni-600M as it is an early research release." The sub-50 ms latency claims in the blog post are for d1-3B only.
How much RAM it needs at each quantization
Nobody has published measured RAM figures for d1-omni-600M, Liquid included. What exists is file sizes, and for a model this small, weight size is most of the story. Treat these as a lower bound and leave headroom for activations, especially with tiled images.
| Format | Files | Size on disk |
|---|---|---|
| Original F32 safetensors | model.safetensors |
2.35 GB |
| GGUF F16 | model 764 MB + mmproj 441 MB | ~1.2 GB |
| GGUF Q8_0 | model 407 MB + mmproj 263 MB | ~670 MB |
| ONNX q8, text only | model_quantized.onnx |
0.41 GB |
| ONNX q4, text only | model_q4.onnx |
0.24 GB |
| ONNX voice stack | q8 decision + q8 audio + fp16 embeddings | 0.67 GB |
Sources: official repo, official GGUF, onnx-community port.
The trap is the reference PyTorch snippet. It loads float32 whenever the device is CPU, which means 2.35 GB of weights before you've done anything. On a 2 GB Pi that's not happening, and on a 4 GB board it's tight. Use the Q8_0 GGUF instead.
Be careful with lower quants. The ONNX maintainers measured that 4-bit decision weights moved voice answers by up to 0.52 in probability, and they kept the vision encoder at fp16 because 8-bit changed answers. Liquid's own card says to avoid bfloat16 on GPU, which flipped the top answer on 0.8% of text and 1.7% of audio rows. For a classifier, a flipped top answer is the entire output, so I'd stay at Q8.
Running it: llama.cpp, transformers, or the browser
llama.cpp got support in PR #30114, merged October 8, 2026, so you need a build newer than that. The answers come from a dedicated /v1/systemone endpoint (added in #29818), not chat completions:
llama-server -hf LiquidAI/d1-omni-600M-GGUF:Q8_0 -b 4096 -ub 4096
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?"},
"urgency": {"type": "score", "instructions": "How urgent is this?",
"criteria": ["Can wait", "Today", "Blocking the customer now"]}
}
}'
Don't skip the -b/-ub flags: the whole question gets read in one batch, so the batch has to hold it. 4096 covers any image, and you can go up to 16384 for long states. Also keep an eye on #30261, still open as of writing: it changes how llama.cpp rounds when it picks the image tile grid for LFM2-family models (d1-omni included) so it matches the Python reference. Until it lands, some image sizes can get a different token count than in transformers.
With transformers you need transformers>=5.15 and trust_remote_code=True, then model.system_one(state, questions, images=..., audio=...). It's fine on a desktop and too heavy for small boards, for the RAM reasons above.
For the browser, the onnx-community port runs through transformers.js and the open-jev library on WebGPU. It reports about 60 ms per question on an M3 Pro in Chrome, and 130 to 230 ms per question on a laptop CPU. That laptop-CPU figure is the closest public proxy for ARM boards I could find. Community Core ML, MLX and LiteRT conversions are also on the Hub.
So, Raspberry Pi: yes or no?
Nobody has posted Pi benchmarks, so anyone giving you a tokens-per-second number is guessing. Tokens per second doesn't even apply here. Each call is one forward pass with no generation loop, which is exactly the workload where a weak CPU has the least to lose.
Going by the numbers above, here's where I land:
- Pi 5 with 4 GB or more, Q8_0 GGUF, text or audio decisions: worth trying today. The memory fits with room to spare.
- Large images on a Pi: expect tiling to push the token count, and with it the latency, up. Downscale before you send.
- Anything needing facts or reasoning: wrong model. That 15.95 Decision Index and the 8.3 Knowledge score are telling you exactly that.
The license fine print
The blog says "without restrictions." The actual LICENSE is the LFM Open License v1.0, and section 5 says commercial use is only licensed if your organization stays under $10,000,000 in annual revenue. Hobby projects and most startups are fine. If you work at a bigger company, talk to legal before you ship it in a product.
My take: d1-omni-600M is the most interesting small model I've seen this year, because it gives up on generation and does one job well. English-only 30-second audio and vendor-only benchmarks keep it in "experiment" territory for now.
What's the smallest model you've gotten to do something actually useful? I'd like to hear about sub-1B models doing real work on a Pi or a phone, and especially from anyone who thinks a decision model like this is a dead end compared to just prompting a small LLM for JSON.
Top comments (0)