Evidence at a glance
The mechanism in one line
Compress the visual or contextual input before the main reasoning path.
Route or verify the expensive step instead of repeating the full path.
Translate the mechanism into a bounded deployment or evaluation check.
Six Models for Different Jobs
On October 27, 2026, Liquid AI released LFM3, a family of six open-weight models branching from a shared base and aimed at text, vision, audio, omni, and decision tasks. The lineup includes the LFM3-1.7B text model, LFM3-VL-2B for vision, LFM3-Audio-2B, LFM3-Omni-2B, and two decision models, d1-2B and d1-Omni-2B. These are not one model under six names: members add vision or audio components as needed, while the decision models are specialized from the vision and omni models respectively.
The shift worth noting is that the small-model contest is moving beyond parameter count toward whether a model can do a particular job on a constrained device. Liquid AI says the models can be fine-tuned on a single GPU and deployed to phones, laptops, private servers, or the cloud. That describes a range of deployment paths, not a guarantee that every model runs equally well on every device. The text model targets local agents, the vision model accepts video, the omni model can answer in text or speech, and the decision models aim to handle multiple questions in one forward pass. Selection should therefore start with the inputs, outputs, and task, not the parameter count in a family name.
A Hybrid Backbone Allocates Compute Rather Than Eliminating Attention
The LFM3-1.7B text backbone has 24 layers, but they do not all perform the same attention computation. Thirteen use gated short convolutions, five use 256-token sliding-window attention, and six use global attention. The convolution kernels grew from three to seven; attention heads gained sigmoid gates; global layers use partial RoPE; and the model uses sandwich normalization. In broad terms, short convolutions and local attention handle nearby information, while a smaller number of global layers preserve routes for longer-range interaction. This is an allocation of computation, not proof that long context comes for free.
Liquid AI says it chose the mix through hardware-in-the-loop architecture search. LFM2 was tuned on one phone and one laptop, while LFM3 was tuned across 14 device and backend combinations, including a Raspberry Pi 5 and Qualcomm Hexagon NPU. That points to a design objective broader than abstract model scores: how operators behave on actual hardware. But the public material does not provide a consistent set of latency, throughput, or power results for every device, so the breadth of the search alone cannot establish that a particular deployment will be faster or more efficient. The engineering value is in including hardware constraints early, rather than looking for runtime workarounds after training.
A Small Weight File Does Not Remove the Cache Cost
The LFM3-1.7B has a 256K-token context window, and Liquid AI says its four-bit weights occupy about one gigabyte. That figure is easy to misread: it describes quantized weights, not total runtime memory. Liquid AI gives a separate cost for the text model: its KV cache requires 1.6 GB at a full 128K context. Weights and cache are distinct parts of the budget, and actual runtime use also depends on the software stack, input length, and device.
Context specifications also vary across the family. The published model cards give LFM3-VL-2B a 128K window and LFM3-Audio-2B a 32K window, so the text model's 256K figure should not be applied to every member. The release includes GGUF, MLX, ONNX, FP8, and NVFP4 formats, widening the available runtime paths without promising equal capabilities on every piece of hardware. For an edge deployment, measuring peak memory on the target device, with the intended quantization format and context length, is more reliable than putting “one gigabyte” directly into a resource budget.
The Benchmarks Show Trade-Offs, Not a Clean Sweep
Liquid AI reports a 49.37 average for the LFM3-1.7B across 29 benchmarks and says this exceeds the Qwen3.5-9B score of 47.24. These are the publisher's own evaluation results, not an independent replication. Looking at individual tasks better explains the model's positioning: it scores 38.42 on WebArena-Verified against 28.94 for Qwen3.5-9B, and 71.39 on BFCL V4 against 62.83. But the same pattern does not hold for knowledge and coding: it scores 63.37 on GPQA Diamond against 80.40, and 43.40 on SWE-bench Verified against 51.20. An average compresses different capabilities into one number; deployment decisions should not.
The long-context results are another reason not to equate window size with effective retrieval. LFM3-1.7B scores 65.56 on RULER 128K, below the 87.11 listed for Qwen3.5-9B. On Humanity's Last Exam, it scores 7.17 without tools and 13.90 with search. That improvement suggests tools can compensate for some limitations, but they do not turn the underlying model into a stronger knowledge reasoner. Applications that depend on long-document retrieval, complex coding, or difficult knowledge questions should measure retrieval, tool use, and model answers separately rather than deciding from a 256K context window or a 29-benchmark average.
Deployment Also Depends on Training and License Terms
Liquid AI says the LFM3-1.7B base model was trained on 22 trillion tokens, with the final 3.5 trillion focused on agent traces and tool-use data while extending context. The public materials differ in how they account for training stages: figures in a model-card diagram add up to about 21.55 trillion, while the accompanying text gives 22 trillion and a final 3.5 trillion. The difference may reflect rounding or different stage definitions, but the available material does not explain it. For technical leads, the more direct question is whether those training priorities match their task distribution, not the token total alone.
“Open-weight” also does not settle whether commercial deployment is permitted. The release lists the LFM Open License v1.0, and the source summary mentions a connection to a ten-million-dollar revenue threshold; the license text is needed to determine the precise restrictions and conditions. LFM3 is best treated as a local-model option worth testing against specific tasks and devices: account for weights, cache, and runtime, rerun the important evaluations, and review the license before product integration. It offers architectural and deployment choices, not a guarantee of edge performance already achieved.