Introducing LFM3: Six 2B Models, One Backbone, and a 256-Token Window That Isn't Context

Liquid AI's LFM3 family landed on 27 October 2026 as six 2B-class checkpoints rather than one flagship: LFM3-1.7B for text, LFM3-VL-2B for vision, LFM3-Audio-2B for speech, LFM3-Omni-2B for everything at once, plus two decision models, d1-2B and d1-omni-2B. All six branch from a single pre-trained backbone, LFM3-1.7B-Base, which Liquid also released. The company's framing is "specialized intelligence" — a deliberate refusal to ship a small generalist and compete on the wrong axis.

Within a day of the announcement, one number from the technical write-up was already being misread. LFM3's architecture lists sliding-window-attention layers with a 256-token window. That is the attention geometry per layer, not the model's context length. The text model takes 256K tokens of context. Readers who skimmed the layer table and concluded Liquid had shipped a 2026 model with a 256-token memory have the wrong model in their head, and it is worth correcting before anything else in this piece makes sense.

What the tri-hybrid architecture actually is

LFM3 replaces LFM2's two-way mix with three layer types stacked in a 24-layer body. Thirteen layers are gated short convolutions, five are sliding-window attention with a 256-token window, and six are full global attention. The convolution kernel widens from 3 to 7. Three smaller changes ride along: a sigmoid gate that scales each attention head's output independently, partial rotary embeddings in the global layers that rotate only the highest-frequency half of each head, and a sandwich normalisation that conditions both the input and the output of every block.

The bet is that short convolutions carry most of the local structure cheaply, sparse attention handles the middle distance, and a thin slice of global attention stitches the whole 256K window together. That is why the KV cache stays small enough to matter — Liquid reports a full 128K-token cache at 1.6 GB, against 4.3 GB for Qwen3.5-4B and 5.6 GB for MiniCPM5-2B on the same measurement. The text model itself fits in about 1 GB at 4-bit precision.

Training ran in four stages: 22 trillion pre-training tokens, a 3.5-trillion-token mid-training phase heavy on agentic traces and tool calls that also stretched context to 256K, supervised fine-tuning on 1.75 trillion tokens, then mixed reinforcement learning combined with multi-domain on-policy distillation from six specialist teachers. The vocabulary is 128K tokens, shared with LFM2.5-8B-A1B and built to tokenise non-Latin scripts more efficiently than its predecessor.

The six models, and where their context goes

Liquid is explicit that these are siblings, not tiers. Each takes the same backbone and is post-trained for a different output shape.

• LFM3-1.7B — dense text and agent model, 1.73B parameters, 256K context, native tool calling and structured output.

• LFM3-VL-2B — vision-language, 1.9B parameters, with an in-house vision encoder Liquid says needs roughly a third of SigLIP2's compute.

• LFM3-Audio-2B — ASR, TTS, speech translation and audio understanding, using an in-house encoder plus LiquidCodec.

• LFM3-Omni-2B — Liquid's first omni model: text, image, video and audio in, text or speech out.

• d1-2B — a decision model built from the vision branch that answers structured questions in a single forward pass with calibrated probabilities rather than free-form prose.

• d1-omni-2B — the same decision interface on the omni branch.

The context windows are not uniform, and this is the detail most launch coverage dropped. Liquid publishes a window for the text model and the base model — 256K, input and output combined — and for none of the other four. Neither the announcement nor the model documentation states a context length for LFM3-VL-2B, LFM3-Audio-2B, LFM3-Omni-2B or either decision model. Third-party write-ups have circulated 128K for the vision model and 32K for the omni model, and those figures may well be right, but as of 28 October they are not on Liquid's own pages. If you are planning an agent that reads long documents and also looks at screenshots, you currently cannot size the omni model's context from first-party documentation at all. That is a gap worth naming rather than filling in from a blog that filled it in from somewhere else.

The benchmark table, read honestly

Every performance number below is Liquid's own, produced on Liquid's own harness, and none of it has been independently reproduced. As of 28 October 2026 there is no LFM3 entry on Artificial Analysis — no Intelligence Index, no speed or latency measurement from a neutral party. That matters more than usual here because the comparison the launch leans on is a same-harness comparison, which flatters whichever model the harness was tuned for.

LFM3-1.7B scores 49.37 on Liquid's 27-benchmark average. The company's own LFM2.5-2.6B scores 31.55 on the same set, which is where the "35% fewer parameters" claim comes from. The interesting rows are not the average:

• Tool use — BFCL V4 71.39, ToolSandbox 80.36, τ³-bench 68.01, MCP-Atlas 32.57.

• Agentic web — WebArena-Verified 38.42, AutomationBench 41.29, BrowseComp-Plus 37.00, LiveClaw 45.60.

• Agentic coding — SWE-bench Verified 43.40, SWE-bench Multilingual 23.00, Terminal-Bench 2.1 at 12.92.

• Instruction following — IFEval 96.66, IFStruct 93.72, IFBench 73.03, Multi-IF 89.10.

• Knowledge — GPQA Diamond 63.37, HLE 7.17 without tools and 13.90 with them.

• Long context — RULER 128K 65.56, AA-LCR 52.83.

Read as a shape rather than a total, the profile is coherent: very strong instruction adherence, respectable single-turn tool calling, and a steep drop once a task requires many sequential steps. Terminal-Bench 2.1 at 12.92 and SWE-bench Multilingual at 23.00 are not numbers you build an autonomous coding agent on. Liquid does not hide this — the model card steers users away from complex reasoning and multi-step coding, which is an unusually direct piece of positioning from a vendor on launch day.

The efficiency claims are the other half of the pitch. At Q4_0 and 32K context, Liquid says LFM3-1.7B was the fastest model on all three test devices, 1.8× to 2.8× quicker than the next contender with the lowest memory footprint. On a single NVIDIA B300 with SGLang in BF16 it served 3.6 billion tokens per day at 1,024 concurrent requests. The company also ran more than 300,000 LFM3-1.7B agents in parallel over the Enron email archive as a stress demonstration. Those are vendor figures, unaudited, but they are the kind of figure that is hard to inflate quietly.

Licence and what it costs to run

Weights are on Hugging Face in BF16, FP8, NVFP4, GGUF, MLX and ONNX builds, with day-one support across vLLM, SGLang, Transformers, llama.cpp, MLX, ONNX Runtime, Ollama and LM Studio. The licence is the LFM Open License v1.0: royalty-free commercial use below $10 million in annual revenue, with a separate agreement above it. That threshold, not the parameter count, is the line that decides whether LFM3 is free for a given company.

Liquid also runs a hosted API, and there the public record is thinner than the launch suggests. The documentation lists the model ID and a 256K input-plus-output limit but no rate card. Third-party reporting puts the hosted rate for LFM3-1.7B at roughly $0.08 per million input tokens and $0.20 per million output, with the vision, audio, omni and decision variants priced higher; Liquid has not published those figures on its own pages, so treat them as reported rather than confirmed. Self-hosting, by contrast, has no per-token price at all — the cost is the machine, and at 4-bit that machine can be a phone.

Where OrcaRouter fits — and where it doesn't

LFM3 is not in the OrcaRouter catalogue, and we are not going to pretend otherwise. It is open-weight software you run yourself or call through Liquid's own API. What the router is good for is the layer around it. A 1.7B specialist is rarely the only model in a pipeline: it handles the tool call, the classification or the extraction, and something larger handles the turn that needs judgement. OrcaRouter puts those hosted models behind one key with 0% markup — provider list price passed straight through — so the escalation path from LFM3 to a frontier model is a routing rule rather than a second contract. Its automatic failover matters most for exactly the workload LFM3 targets, where a single small model is the only thing standing between a request and an error.

The routing DSL is the more interesting fit. Composing a specialist with a generalist in one call — LFM3-shaped work routed to a small model, everything else falling through to a hosted one — is the deployment pattern this family was built for. Liquid's whole argument is that a 2B model beats a frontier model on a narrow task at a fraction of the cost. A router is how you capture that saving without betting the pipeline on it.

What to watch

The open question is not whether LFM3 is good at what it claims. It is whether the claims survive a harness that Liquid did not write. The family's agentic numbers are the ones to re-test first, because WebArena-Verified at 38.42 and AutomationBench at 41.29 sit far above what a 1.7B model has historically managed, and agentic benchmarks are the most sensitive to prompt scaffolding and retry policy. An independent run that lands within a few points of Liquid's table would make LFM3 the default choice for on-device tool calling. A run that lands ten points lower would make it a good instruction follower with an overstated agent story.

Until that run exists, the honest summary is this: LFM3 is a well-engineered, unusually candid small-model family with a genuinely novel layer mix, a real memory advantage, published weights at a workable licence threshold, and no independent verification of any headline benchmark. The 256-token window in the architecture table is not the context length. Everything else in the launch is worth taking at face value until someone proves otherwise — and worth measuring yourself before you put it in front of users.