Field noteOct 30, 20265 min read1 source

llama.cpp merges support for Liquid AI's d1-2B and d1-omni-2B decision models

In one minute

llama.cpp merged support for Liquid AI’s d1-2B and d1-omni-2B decision models on October 27, 2026. The change gives local-runtime users another way to evaluate these models, but support is explicitly partial: bounding boxes and video input remain future work.

What changed: llama.cpp has now merged support for Liquid AI’s d1-2B and d1-omni-2B decision models, adding a concrete inference-runtime integration to the recently released LFM3 family.

What happened

A pull request titled “model : add LiquidAI/d1-2B and LiquidAI/d1-omni-2B” was merged into the master branch of ggml-org/llama.cpp on October 27, 2026. The change adds support for two models described in the pull request as decision models from Liquid AI’s LFM3 family: LiquidAI/d1-2B-GGUF and LiquidAI/d1-omni-2B-GGUF.

This is a runtime-compatibility change, not a new model release or a benchmark claim. llama.cpp is the project receiving the implementation, and the practical consequence is that developers using its local inference stack can test these two named GGUF models through that stack once they use code containing the merged change. The pull request says the implementation was verified for correctness and conformance against the reference Hugging Face implementations.

The support is not complete. The author calls it “partial” and says that more features, including bounding boxes, will arrive in a follow-up pull request. Video input is also explicitly deferred. Those boundaries matter: the presence of an omni model name does not establish that every modality or interface exposed by a reference implementation is already available in llama.cpp.

The pull request records smoke tests for F32, Q8_0, and Q4_0 quantizations on Mac and CUDA. It also includes a change to keep speech task templates out of the d1 GGUF files, plus a small refactoring labelled no_batching. The source does not provide speed, memory, quality, context-length, hardware-requirement, or pricing measurements. It reports a merged implementation and limited test coverage, rather than a performance comparison.

What the archive adds

This is a new fact on a known local-inference story. A prior note covered a separate llama.cpp change that reduced Qwen3.8-Flash-Next compute-buffer memory by 2–4 GB, depending on ubatch size: llama.cpp merges a qwen4exp change that cuts Qwen3.8-Flash-Next compute-buffer memory by 2-4 GB. That earlier item concerned memory behavior; this one expands model compatibility.

Trend signal

This modestly supports Harness architecture outlives model choice. A runtime gains value when teams can hold their local serving and evaluation harness steady while trying another model family. The merge is only compatibility work, not proof of production interchangeability, but it makes that option more concrete.

Why now

The timing is explained by the pull request itself: the implementation was merged after review on October 27, 2026, and the author explicitly scoped further modality work to later pull requests. The immediate news is therefore upstream availability in master, while complete feature parity remains a separate milestone.

Connections to other events

Liquid AI had recently published GGUF variants of LFM2.5-24B-A2B and showed commands for running them through llama.cpp. This change concerns different, smaller d1 models in the LFM3 family, and it shifts the relevant question from whether a GGUF artifact exists to whether the runtime has explicit support for the model’s decision-oriented behavior and modalities.

Why it matters

For teams evaluating local models, runtime support is a prerequisite that is easy to overlook. A model file may be available, yet the chosen runtime can still lack conversion rules, architecture handling, task templates, or tested quantization paths. This merge removes part of that uncertainty for d1-2B and d1-omni-2B in llama.cpp.

It does not remove the need for a workload-specific test. Teams should treat the merge as permission to begin evaluation, not as evidence that the models meet latency, memory, reliability, or multimodal requirements. In particular, workflows requiring video input or bounding-box output should not assume those capabilities are present. The useful comparison is the completed task under the team’s own hardware and harness, with the missing features made explicit.

What happens next

  • A follow-up change adds at least one deferred capability, such as bounding boxes or video input. (6 months, 60%). Watch for: a linked or follow-up llama.cpp pull request.
  • More users test d1 quantizations beyond the reported smoke tests on Mac and CUDA. (3 months, 65%). Watch for: reproducible reports of quality, memory, or throughput.

Limits and uncertainty

The source is a merged pull request, not a release announcement, benchmark report, or deployment guide. It does not state which tagged llama.cpp version first contains the change, nor does it establish support in downstream applications that embed or package llama.cpp. “Correctness and conformance” is reported against reference Hugging Face implementations, but the source does not publish test cases or outcomes beyond the listed smoke-tested quantizations and platforms.

There is also no evidence here about model quality, reasoning performance, licensing, model availability, context length, batch behavior, or real-world multimodal reliability. Partial support and deferred video input are material caveats.

Skill to build now

Add a runtime-compatibility gate to local-model evaluation. Before scoring a candidate model, record the exact runtime revision, model artifact, quantization, platform, and required modalities; then run one representative task end to end. For these d1 models, make video input and bounding boxes explicit acceptance checks rather than assumptions. This separates a successful load test from evidence that a workload is actually supported.

Reader takeaway

llama.cpp can now support Liquid AI’s d1-2B and d1-omni-2B decision models through a merged upstream change, giving local teams a path to evaluate them. Treat it as an early compatibility milestone: the source reports partial support, smoke tests on selected quantizations, and future work for bounding boxes and video.

Open question

Which llama.cpp release and downstream distributions will first expose this merge, and which deferred modality features will arrive with tested end-to-end behavior?

Evidence / sources

  1. 1github.com/ggml-org/llama.cpp/pull/31275
All Field Notes

Next reads

Read next

Open the graph
  1. 01topicHarness EngineeringExplore the harness-engineering topic hub.
  2. 02topicAgent RuntimeExplore the agent-runtime topic hub.
  3. 03archiveField NotesOpen the latest editorial analysis.
  4. 04source ledgerSource LedgerInspect the public source evidence graph.
Who read this page?Machine requests, hidden until opened

Loading the privacy-safe route aggregate...

Open the JSON contract