d1-omni vs Liquid AI D1 Omni 600M: Two Names, One Checkpoint, and a Context Number Nobody Can Source

Liquid AI D1 Omni 600M and d1-omni are not two models, and they are not two checkpoints of the same model either. They are one set of weights — Liquid AI's 587M-parameter multimodal decision model, built on Liquid AI LFM2.5-Encoder-350M and published on Hugging Face on 5 October 2026 under the repo name LiquidAI/d1-omni-600M — carrying two different filenames in two different catalogues. One of those catalogues, the vendor's, tells you what the model is. The other, Ollama's, tells you what someone packaged it into, and prints three numbers on the card that the vendor's documentation does not support. That gap is the whole reason this comparison is worth reading, because for a model this small the packaging is not a footnote — it is the difference between a text-and-image model and the model the card says you downloaded.

The vendor has not announced anything about the Ollama entry, and there is no maintainer note, no changelog entry and no readme on the Ollama page to explain any of it. So the honest frame for everything below is this: the weights are public and inspectable, the packaging is public and inspectable, and the reading of the packaging offered here is ours, not Liquid AI's. Where a number cannot be traced to a source, this piece says so rather than repeating it.

What the two names actually are

Liquid AI published the model on Hugging Face with a creation timestamp of 5 October 2026, two days before it appeared in the vendor's own blog post "Open d1: Edge decision models for text, vision, and audio" on 7 October. The weights are licensed under Liquid's own LFM 1.0 terms, tagged d1_omni, system-one, multimodal, vision, audio and decision-model, and have drawn roughly 13,900 downloads and 135 likes at the time of writing. Quantised variants followed on their own schedule: a GGUF repository on 6 October, MLX builds for Apple Silicon on 12 October.

The Ollama entry is not any of those repositories. It is an Ollama library page named d1-omni that carries the badge "vision 600m", shows four tags, and had been updated minutes before this was written — which is why the radar surfaced it at all. Nothing in it names Liquid AI, LFM2.5-Encoder-350M, or the Hugging Face repository the bytes came from.

So the practical difference is a filename and a distribution path, not a model. What differs, and what matters, is the metadata wrapped around the bytes.

The three numbers on the Ollama card, checked one at a time

Ollama's page prints a size, a context window and an input list for every tag. All three deserve a second look, because on this model two of them do not survive contact with the source.

• Context window — 125K on the card, 16,384 in every vendor source. Liquid AI's model card states a 16,384-token ceiling covering text, image and audio positions together, and the vendor's own documentation page for d1-omni-600M says "16K tokens". The string 125K appears in neither. It may be an artefact of the underlying LFM2.5-Encoder architecture's positional configuration or of how Ollama reports a cache limit, but it is not a figure Liquid AI published and it is not one this article can attribute to anyone. What makes the discrepancy more than pedantic is the next number down.

• The state you can actually pass is capped at 896 tokens on the image path. Liquid's card says that when images are present, "the state and question text is cut to 896 tokens, as trained". So a decision request that carries a photo has a text budget roughly the size of this sentence, no matter what context figure is printed on a pull page. If you were sizing a triage prompt against 125K and expecting to pay for a long state, you would be sizing against a number that does not describe the runtime. The 16,384 figure is the real ceiling; the 896 figure is the real working limit for the multimodal path; the 125K is a number without a paper trail.

• Size — 850MB on the card, two files in the registry. The Ollama tag d1-omni:latest resolves to a 407MB quantised weights file designated Q8_0 plus a 442MB projector file designated BF16, and 407 + 442 = 849, which the page rounds to 850MB. Both are listed honestly; the arithmetic is just the sum of a mixed-precision pairing rather than one file. The d1-omni:600m-bf16 tag is the cleaner one: 764MB of BF16 weights plus the same 442MB projector, 1.2GB on disk, and the projector is byte-identical between the two tags. Worth noticing for the next section, because a projector that carries its own weights can move the effective parameter count.

One more detail worth recording rather than explaining: the runtime parameter blob inside Ollama's d1-omni package is byte-for-byte the same length — 18 bytes — as the one inside Ollama's separate d1 package, which ships Liquid AI d1-3B at 2.87GB of Q8_0 weights and a 855MB projector. Two architectures, two parameter counts, two decades of parameter scale between them, and the same 18-byte runtime config. That is a packaging constant, not a claim about either model.

What the weights themselves say

Strip the packaging and the model is unusually well documented. Liquid AI D1 Omni 600M totals 587M parameters split three ways: a 381M shared trunk and decision head, a 94M vision encoder and a 112M audio encoder. The trunk is bidirectional — this is an encoder, not a decoder — and it is the same trunk for every modality, with modality-specific towers bolted on.

• Vision comes from a SigLIP2 tower inherited from Liquid AI LFM2.5-VL-450M, with an adapter and LoRA updates that were active only for image inputs while the encoder itself stayed frozen.

• Audio comes from a 17-layer FastConformer with its own adapter, fine-tuned in a stage where the text backbone was frozen, then the whole stack was fine-tuned, the LoRA was merged, and the weights were averaged back against the previous checkpoint.

• Vocabulary is 65,536 tokens across 15 languages: English, German, Spanish, French, Italian, Dutch, Polish, Portuguese, Arabic, Hindi, Japanese, Russian, Turkish, Vietnamese and Chinese.

• Modalities cannot be mixed. A single request takes text plus images, or text plus up to 30 seconds of speech — not both. Audio is expected at 16kHz mono, between 0.5 and 30 seconds, and was trained on exchanges between an English speaker and an assistant, which is a real constraint on anything multilingual or noisy.

None of that appears on the Ollama page, and the omission has a consequence you can see directly in the usage examples. Ollama's snippets are chat calls — a model string, a messages array, the word "Hello!" — and the underlying checkpoint cannot answer them. It is not a chat model and does not write text. It returns typed answers: a yes/no probability, a label with a probability per label, or a position on an ordered scale, all read directly from the output distribution with zero output tokens generated. The published interfaces reflect that: system_one and probabilities through Transformers, or a /v1/systemone endpoint through llama.cpp 0.7.0 and later. A chat-shaped call against a decision model is the error this naming gap invites.

Two caveats travel with every one of those figures

First, Liquid scored its own rows with the official scorer rather than submitting them for public ranking, and no third party has reproduced any d1-omni-600M result — the vendor states plainly on the model card that it does not report inference numbers for this checkpoint because it is an early research release under active development. Second, the two headline numbers disagree with each other: the 32-point index gap and the 4.5-point benchmark-mean gap describe the same model, which is why the sub-scores, not the totals, are the useful reading. Retrieval at 35.0 and Tools at 15.1 versus Arts at 6.8 tells you which jobs this checkpoint is and is not ready for. Audio has no benchmark column at all; Liquid calls dedicated audio decision benchmarks an open problem.

Liquid AI D1 Omni 600M also leads its own family on two of the seven: Civil Comments at 95.8 and PAWS-X at 79.5. Those are the two rows where a 587M encoder beats the 3B decoder outright, and both are text-classification shaped rather than reasoning shaped — which fits the architecture rather than contradicting it.

Pick by what you want. If you want it running locally under Ollama, d1-omni is the name that works — 850MB for the Q8_0 build, 1.2GB for BF16, the same image path Liquid documents, and neither tag carrying an audio projector. If you want the model the vendor describes, Liquid AI D1 Omni 600M is the name to search, and the Transformers route through the Hugging Face repository is the one whose context length, modality list and parameter count match the documentation.

Either way, this is the cheap half of a pipeline. The decision model classifies; something else has to act on the classification. That is the boundary OrcaRouter sits on and the one worth stating precisely: no Liquid AI model is in our catalogue, so the d1-omni call itself goes wherever you already run it — these weights on your own hardware, or the vendor's own API and third-party platforms for the hosted siblings. What the 200+ models behind one OpenAI-compatible key are for is everything downstream, at each provider's list price passed through with 0% markup, with automatic failover across providers when a triaged request fans out to a model that is having a bad day.

What would settle the open question

Three things would close this out, and none of them needs a vendor announcement. Someone comparing the 850MB Ollama tag's output against the Hugging Face checkpoint on the same inputs would tell us whether the packaging changed the answers. A llama.cpp commit or Ollama changelog entry explaining the context figure would tell us whether 125K is a mistake or a capability the model card has not caught up with. And a published audio result — any audio result — would move this checkpoint out of the category it currently occupies, which is a well-documented model with an undocumented packaging layer and a scoreboard that is entirely the vendor's own.

The documented AI failures and agent incidents behind releases like this one are collected in the OrcaRouter AI Incident Archive, where each entry carries its own sources, severity, confidence grade and disputed flag.