Liquid AI LFM3: Why A 1.7B Model Is Now A Business Option

Last Updated: 28 October 2026

On 27 October 2026, Liquid AI announced LFM3, its third generation of Liquid Foundation Models. The launch post drew 1.46 million views and 7,426 likes in its first day, which is a lot of attention for a family of 2 billion parameter models. That attention is the story. For the past three years the industry has competed on size, and the assumption for most business owners has been that the best AI is the biggest AI you can afford to rent.

LFM3 is a direct challenge to that assumption. Six models, all around 2B parameters, all branched from one backbone, covering text, vision, audio, omni and decision work. The claim Liquid makes is not that these models beat the frontier. It is that for a narrow, high-volume, well-defined job, a small model you own will beat a large model you rent, on cost, latency, privacy and reliability at the same time.

That claim matters to business owners because it changes who can afford to run AI, where the data sits, and what an AI feature costs per transaction rather than per month.

What is LFM3?

LFM3 is Liquid AI's third generation of open-weight foundation models, released on 27 October 2026 as a family of six 2B-class models built on one shared backbone called LFM3-1.7B-Base. The text model has 1.73 billion parameters and a 256K token context window, and runs in about 1 GB of memory at 4-bit precision. The other five models add vision, audio, omni-modal input or decision-making on top of the same base, and all of them can be fine-tuned on a single GPU.

The family is deliberately narrow per model rather than general per model. Instead of renting one large generalist and hoping it behaves on your task, you pick the modality you need, fine-tune it on your own examples, and run it where your application already lives.

Model	What it does	Size
LFM3-1.7B	Text and tool calling for local agents, 256K context, post-trained for harnesses such as Hermes Agent, Pi and OpenClaw	1.73B
LFM3-VL-2B	Vision and language, including video input at 2 frames per second, spatial and embodied reasoning	1.9B
LFM3-Audio-2B	Speech in and out across 18 languages, audio understanding and tool calling	2B
LFM3-Omni-2B	Vision, audio and language in one model, answering in text or speech	2.2B
d1-2B	Decision model over text and images, typed answers with calibrated probabilities in one forward pass	2B
d1-Omni-2B	The same decision model with audio input	2B

Why does smaller matter for a business owner?

Smaller matters because it moves three costs that used to be unavoidable. The first is the per-token bill: a model on your own hardware has no marginal cost per request, and Liquid's decision API prices input at $0.02 per million tokens with no output charge. The second is the privacy question: when the model runs on the device or the server holding the data, there is no cross-border disclosure to assess. The third is behaviour: a 2B model fine-tuned on 3,000 of your own examples can outperform a frontier model on your specific task, because it has been taught your task rather than the whole internet.

Liquid's own numbers illustrate the trade. LFM3-1.7B beats the previous LFM2.5-2.6B on capability while using 35% fewer parameters, and on Liquid's 29-benchmark average it scores 49.37 against 47.24 for Qwen3.5-9B. On agent tasks the gap widens: 38.42 versus 28.94 on WebArena-Verified and 41.29 versus 15.10 on AutomationBench. Those are vendor results, and they should be read as vendor results, but the direction is consistent across every benchmark Liquid published.

The most useful number for a business owner is not a benchmark score. It is the MacPaw test. Ivan Petrukha, Staff AI Engineer and LLM Efficiency Lead at MacPaw, ran LFM3-1.7B against Qwen3.5-2B on 65 everyday agent tasks in real macOS environments. The smaller model won with 64% task success against 48%, used 58% fewer tokens per task, and got stuck in under 1% of attempts against 15%. "'LFM3 is the first sub-2B model we've tested that is ready for real agent work on a Mac,' says Petrukha. 'It beat a larger model on task success while using 58% fewer tokens and almost never getting stuck.'"

How does the tri-hybrid architecture make a small model fast?

LFM3 uses a tri-hybrid architecture that mixes three sequence operators across 24 layers: 13 gated short convolutions, 5 sliding-window attention layers with a 256-token window, and 6 global attention layers. The convolutions do most of the cheap local work, the sliding window handles nearby context without quadratic cost, and the global layers carry long-range information. The result is a model that stays fast at long context, which is where small models usually fall apart.

Liquid found this mix with a hardware-in-the-loop architecture search. For LFM2 the search ran against one phone and one laptop. For LFM3 it ran across 14 device and backend combinations, including a Samsung Galaxy S26 Ultra, a OnePlus 15, a Raspberry Pi 5, an Apple M4 Max, AMD Ryzen AI hardware, Arm and x86 cloud CPUs, GPUs and the Qualcomm Hexagon NPU. The architecture was tuned for the hardware rather than ported to it afterwards, which is why Liquid claims 14 processor classes from a single model family.

Three smaller changes matter for anyone who plans to quantise the model for edge deployment. Head-wise sigmoid gating lets a head switch itself off when it has nothing to add, which suppresses activation outliers that damage 4-bit quantisation. Partial RoPE rotates only the highest-frequency half of each head on the global layers, so the low-frequency dimensions match on content regardless of distance. Sandwich norm normalises both the input and the output of each block. Pre-training used 22 trillion tokens, and the final 3.5 trillion were a mid-training stage heavy on agentic traces and tool calls, which also extended the context window to 256K.

The payoff shows up in two places. Per parameter, LFM3-1.7B matches LFM2-1.2B on short prompts across edge devices, and with 8K tokens in context it is about 25% faster. At 128K tokens the KV cache is 1.6 GB, against 4.3 GB for Qwen3.5-4B and 5.6 GB for MiniCPM5-2B. That is the difference between a long-context feature that fits on a laptop and one that does not.

What can a 2B model do well, and what should stay on a bigger model?

A 2B model is excellent at narrow, repeated work with a clear definition of done: triage and routing, extraction from documents and forms, moderation and guardrails, intent classification, voice interfaces, visual inspection and tool calling inside a known application. It is a poor choice for agentic coding, open-ended multi-step reasoning and knowledge-heavy questions, and Liquid says so directly in the LFM3-1.7B model card, which states the model is not recommended for agentic coding or complex multi-step reasoning because of its size.

The benchmark split confirms that honesty. LFM3-1.7B scores 63.37 on GPQA Diamond against 80.40 for Qwen3.5-9B, 43.40 on SWE-bench Verified against 51.20, and 7.17 on Humanity's Last Exam without tools, rising to 13.90 with search. On RULER at 128K it scores 65.56 against 87.11. Where size genuinely matters, size still wins.

One result deserves more attention than it usually gets. On AA-Omniscience, LFM3-1.7B has an accuracy of 7.07 and a non-hallucination score of 92.93, while Qwen3.5-9B has higher accuracy at 13.17 and a non-hallucination score of 52.59. Read together, that means the small model knows less but admits it far more often. For a business workflow where a wrong answer costs money and "I do not know" costs nothing, that trade is often the right one.

Workload	Small model first	Keep on a frontier model
Email and ticket triage	Yes, with confidence scores and escalation	Only the escalated tail
Invoice and form extraction	Yes, with span-level output and "not found"	Ambiguous or handwritten edge cases
Moderation and guardrails	Yes, and it leaves headroom on shared hardware	Policy interpretation and appeals
Voice chat and transcription	Yes, 18 languages, first token from 50 ms	Accented or noisy audio at scale
Visual inspection and QA	Yes, after a short fine-tune on your images	Novel defects outside the training set
Agentic coding	No	Yes
Open-ended strategy and research	No	Yes

Cloud versus on-device: what changes for an Australian business?

Cloud versus on-device is not a religious argument, it is a custody argument. With a hosted API, your prompts and documents leave your environment and are processed on someone else's servers, usually overseas. With a small open-weight model on your own hardware, the data stays where it already is. Under the Privacy Act 1988, Australian Privacy Principle 8 requires an organisation to take reasonable steps before disclosing personal information to an overseas recipient, and the discloser remains accountable for how that recipient handles it. If the model never leaves the building, that disclosure question does not arise.

The cost line is different too, and it is worth doing the arithmetic honestly. A hosted subscription or per-token API bills every request. On-device inference bills nothing per request, but you pay for hardware, power and the engineering time to run it. On a small business workload, the hardware rarely pays for itself on token savings alone. It pays when several staff share the same model, when request volume is high enough that per-token pricing hurts, when the data cannot leave your control, or when the work is not permitted on a hosted plan. Those four conditions are the honest test.

We ran our own test rather than repeat vendor numbers. On a 4 vCPU x86 virtual private server with 7.9 GB of RAM and no GPU, using llama.cpp build b11954 and the 1.02 GiB Q4_K_M quantisation of LFM3-1.7B, the model pre-filled at 4.10 tokens per second and decoded at 0.72 tokens per second. That is not a usable deployment, and it is worth saying plainly: the box was already running 4.7 GB of other services, so the model was competing for memory and swap. A CPU-only shared server is the wrong home for this model. The vendor's speed claims are measured on phones, NPUs and GPUs with GPU offload, where LFM3-1.7B prefills at least 2.5 times faster and decodes at least 1.8 times faster than every model it was compared against. Smaller is not the same as free. The hardware class still decides whether the experience is good.

For comparison, on our dual DGX Spark setup running DeepSeek V4.1 Flash, we measure about 35 tokens per second on a single stream and about 62 tokens per second at four concurrent requests. That is the class of hardware where local inference becomes a real product rather than a demo, and it is also the class of hardware where the economics start to work for a business that would otherwise pay per token all day.

How do you start with a small model in your business?

Start with one narrow, high-volume task that already has a measurable cost and a clear right answer. Run the base model first with no fine-tuning, so you learn where it fails before you spend money on training. Then fine-tune on a few hundred to a few thousand labelled examples, measure the error rate against your current process, and keep a frontier model for the cases the small model flags as uncertain. The point is not to replace your AI stack. It is to stop paying frontier prices for work that a 2B model can do reliably.

1. Pick one task with a measurable baseline. Ticket routing, invoice extraction, first-line support or photo-based inspection all qualify, because you already know the volume, the cost per item and the current error rate.
2. Run the base model before you train anything. Liquid publishes GGUF, MLX, ONNX, FP8 and NVFP4 checkpoints, so a llama.cpp or Ollama test on a laptop takes an afternoon and costs nothing.
3. Fine-tune on your own examples. Liquid's wind turbine demonstration used about 3,000 public blade photos with supervised fine-tuning and GRPO for a few hours on a single A100, and raised classification accuracy to 67% from under 10% out of the box. A rank-32 LoRA adapter for robot tool use trained on roughly 40,000 samples in about six GPU-hours on one AMD MI325X with no architectural change.
4. Add confidence-based escalation. The d1 models return calibrated probabilities and typed answers, so low-confidence cases can be routed to a larger model automatically instead of being guessed at.
5. Measure cost per resolved item, not cost per token. Include hardware, power, engineering time and the escalated share. That number is the one that decides whether the cascade is worth running.

What are the honest limits of this release?

The limits are real and Liquid documents most of them. The benchmark table is vendor-run, so every peer number comes from Liquid's own harness. The model card states the text model is not recommended for agentic coding or complex multi-step reasoning. Long-context retrieval at 128K still trails larger models, 65.56 against 87.11 on RULER. And early users have found rough edges: one Hacker News commenter reported that LFM3-1.7B answered "what does a cow say?" with "Oink" on the Liquid playground, while the vision model answered "moo", and noted that Q8 quantised builds through llama.cpp got it right, which points at a low-precision artefact rather than the architecture.

The licence also has a threshold that business owners need to read carefully. The LFM Open License v1.0 grants free commercial use to any legal entity below US$10 million in annual revenue, with fine-tunes staying private and no copyleft. Above that threshold, commercial use is not licensed under the agreement and requires an enterprise licence from Liquid. Research, education and non-profit use is free with no revenue limit. If you are a larger business, budget for the licence conversation before you build a product on these weights.

None of that undermines the argument for smaller models. It sharpens it. A small model is a tool with a defined job, and the businesses that get value from LFM3 will be the ones that define the job narrowly, measure the result and keep a bigger model for everything else.

Frequently asked questions

What is LFM3?

LFM3 is Liquid AI's third generation of Liquid Foundation Models, announced on 27 October 2026. It is a family of six open-weight models around 2 billion parameters each, all built on one shared backbone, covering text, vision, audio, omni-modal input and decision-making. The text model has a 256K token context window and runs in about 1 GB of memory at 4-bit precision.

Is LFM3 free for commercial use?

Yes, for businesses with less than US$10 million in annual revenue. The LFM Open License v1.0 allows free commercial use, modification and distribution below that threshold, and fine-tunes remain private with no copyleft. Above US$10 million in annual revenue, commercial use requires a paid enterprise licence from Liquid AI. Research, education and non-profit use is free regardless of revenue.

Can a 1.7B model replace ChatGPT for my business?

Not entirely, and it is not meant to. A 1.7B model is strong at narrow, repeated tasks such as triage, extraction, classification, moderation and tool calling, and weak at agentic coding, open-ended reasoning and broad world knowledge. The practical pattern is a cascade, where the small model handles routine volume and low-confidence cases escalate to a frontier model.

What hardware do I need to run LFM3 on-premises?

Less than you would expect for the text model: about 1 GB of memory at 4-bit precision, which fits on a phone, a laptop or an AI PC. Liquid tuned the architecture across 14 processor classes including Arm and x86 CPUs, GPUs, NPUs, a Raspberry Pi 5 and Apple silicon. Our own test on a 4 vCPU server with no GPU produced 0.72 tokens per second, which is not usable, so plan for a device with an NPU or GPU rather than a shared CPU-only server.

Why are small AI models better for privacy?

Because the data does not have to leave your environment. When a model runs on your own device or server, prompts, documents and customer records are not disclosed to an overseas provider, so the cross-border disclosure obligations under Australian Privacy Principle 8 do not arise. For work involving personal information, health records or client documents, that is often the deciding factor rather than the cost saving.