Field note · No. 014 · October 29, 2026
A 2B model that fits in 1 GB moves the router onto the device
Liquid AI's LFM3 family reportedly ships six small open-weight models with on-device formats on day one. The benchmark average is the least interesting part; the deployment story is what changes agent design.
What changed
According to a MarkTechPost article dated 27 October 2026, Liquid AI released LFM3, a new generation of its Liquid Foundation Models. It is a family of six open-weight 2B-class models built on one shared backbone, covering text, vision, audio, omni and decision tasks. Every model in the family can be fine-tuned on a single GPU.
The reported sizes: - LFM3-1.7B: 1.73B parameters, 256K context window - LFM3-VL-2B: 1.92B parameters, 128K context window - LFM3-Omni-2B: 2.2B parameters
At 4-bit the models reportedly run in about 1 GB of memory, which puts them on phones and laptops. GGUF, MLX, ONNX, FP8 and NVFP4 checkpoints are included in the release.
Liquid AI reports that LFM3-1.7B averages 49.37 across 29 benchmarks, above the 47.24 of Qwen3.5-9B. That figure is vendor-reported and has not been independently checked. Everything here comes from a single news write-up, not the model cards, so I would read the cards before relying on any of it.
Why it matters for builders
The useful part is the launch-day formats. GGUF runs under llama.cpp, MLX targets Apple hardware, ONNX covers a wide set of runtimes. That means a team can test on-device inference the same week, without waiting for community conversions or trusting a third-party quantization they cannot audit.
A lot of the work inside an agent loop is small: choosing a tool, extracting arguments, classifying an input, compressing a tool result before it goes back to a larger model. My reading, not a vendor claim, is that a model at this size is a candidate for exactly that layer, running locally where latency and data residency matter.
The shared backbone also matters operationally. One fine-tuning pipeline and one evaluation harness can cover text, vision and audio variants, instead of a separate stack per modality.
The failure modes deserve as much attention as the fit. A small router that picks the wrong tool fails quietly, and the downstream model often makes the wrong choice look reasonable. A 256K context window on paper is also not a promise of reliable long-context behaviour on a phone, and the cache for a long context adds memory well beyond the weights.
What I would do with it
I would start with one narrow decision in an existing agent, not a whole sub-agent.
- Pick a single step, such as tool selection, and record real inputs alongside the choices the current large model makes. That becomes the labelled set.
- Run the GGUF or MLX checkpoint of
LFM3-1.7Bagainst that set locally. Measure agreement, but look harder at the disagreements: a plausible wrong tool is worse than a refusal. - Constrain the output to a schema of valid tool names and arguments, and fall back to the larger model whenever validation fails.
- Only after a baseline exists, try a single-GPU fine-tune on the recorded traffic and compare against the same set.
The benchmark average is a reason to run this experiment, not a reason to ship. The labelled set and the fallback path are what make the decision defensible, and both stay useful whichever small model wins next month.
Move an agent decision to a small local model only after you have a labelled set of real traffic and a validated fallback for when it is wrong.