LFM3 Models: A Practical Guide to the 2B AI Family
Explore LFM3’s text, vision, audio, omni and decision models, their on-device strengths, benchmark trade-offs and practical ways to evaluate them.
LFM3: What the New 2B Model Family Means for AI Teams
Small models are getting better, but "works in a demo" doesn't automatically translate to "works in your product." You still have to figure out what the model can actually perceive, how reliably it uses tools, what hardware it runs on (and how fast), and whether your team can adapt it for a specific job. Liquid AI's LFM3 family is trying to solve that practical problem: a set of compact, open-weight models for text, vision, audio, multimodal interaction, and structured decisions.
The first release focuses on the 2B-parameter class. Liquid builds these models from a shared backbone and positions them for fine-tuning and deployment both on devices and in the cloud. Liquid reports improvements in agent tasks, multimodal benchmarks, and inference efficiency - but like with any benchmark, the numbers only matter in context. Performance depends on the workload, runtime, quantization, and evaluation method. This guide walks through what's in LFM3, how the architecture and model choices fit together, what the reported results do (and don't) show, and how to decide whether LFM3 belongs in your stack.
What is LFM3 and why does its architecture matter
LFM3 is Liquid AI's open-weight model family for specialized applications. The first release includes six models branching from the LFM3-1.7B-Base backbone: text, vision, audio, omni, plus two decision models. The point isn't to make one catch-all model and force everything through it. Instead, you pick the model that matches what your product needs to take in and what it needs to output, then adapt and deploy it where the application runs.
Liquid says the base model was pretrained on 22 trillion tokens. The training mix adds scientific content, repository-level code, broader knowledge sources, and more mathematics than Liquid's LFM2 generation. Then there's a 3.5 trillion-token mid-training stage using curated data, more agent traces and tool calls, and an extended context window to 256K tokens. Context length only helps if your serving stack can actually process long inputs within your memory, latency, and cost limits.
A hybrid design aimed at long-context efficiency
LFM3 uses three sequence-processing approaches across 24 layers: 13 gated short-convolution layers, five sliding-window attention layers with a 256-token window, and six global-attention layers. Compared with LFM2, the convolution kernel size increases to seven from three. The idea is straightforward: keep efficient local processing, then add attention where broader context should improve quality.
Liquid reports that LFM3-1.7B matches LFM2-1.2B on short prompts per parameter on tested edge devices and is about 25% faster at an 8K-token context. Those are company-reported results, not a universal guarantee. What you see will depend on your runtime support, memory bandwidth, quantization, and the shape of your prompts.
Other architectural details include a gate on each attention head, partial rotary position encoding in global-attention layers, and normalization at both the input and output of each block. These changes are meant to improve stability and practical capacity without turning inference into a speed nightmare. It's not that any single mechanism automatically makes the model better in production - the broader point is that the family is built around an efficiency target, not just raw capability.
One backbone, different post-training
Sharing a base doesn't mean the six models behave the same way. Each specialized model gets adapted for different input types or output needs. Text models are post-trained for agent workflows and tool use; the vision model is trained to reason over images and video; audio models handle speech input and output; and the decision models produce structured judgments instead of free-form prose.
This split can make product design easier. If you're doing document processing, you often need image input plus typed fields. A voice assistant needs streaming audio and spoken responses. In practice, choosing a model around those requirements tends to be more reliable than trying to make one general model handle everything equally well.
Which LFM3 model fits which workload
The question isn't "which LFM3 is best overall?" It's "which LFM3 matches the inputs, outputs, and operating profile your application actually needs?" The lineup is organized around those differences.
Text: local agents and specialized language tasks
LFM3-1.7B is the text model for local agents, tool use, and domain-specific language tasks. It has a reported 256K-token context window and was post-trained via supervised fine-tuning, mixed reinforcement learning, multi-domain on-policy distillation, and agentic reinforcement learning. Liquid says the training covers chat, reasoning, coding, structured output, tool calls, browsing, and office-style workflows.
That makes it a fit for inbox triage, calendar operations, research assistance, and internal workflow automation - assuming your application provides tools, permissions, and safeguards. The model doesn't magically access an email account or a company system on its own. That comes from the agent harness and its integration with your services. The model's job is to interpret the instructions and choose actions; your system has to validate and execute them safely.
Vision: images, video and spatial understanding
LFM3-VL-2B takes visual inputs, including video, and targets questions involving documents, charts, math, object localization, and spatial relationships. Liquid reports an average score of 71.4 across 62 vision evaluations, compared with 64.0 for Qwen 3.5 2B and 71.7 for Gemma 4 12B. The breakdown matters: Liquid reports stronger results on document and chart tasks, visual grounding, and GUI understanding than on agentic-style tasks.
There's also an in-house vision encoder. Liquid says its 164-million-parameter encoder matches the vision encoder of Qwen 3.5 2B at 55.9% average accuracy across 13 vision-language benchmarks, while requiring 2.2 times fewer FLOPs. That's relevant when compute is tight, but you'll still want to measure the whole pipeline: image resizing, video sampling, and preprocessing, not just the model's headline numbers.
Audio and omni: speech alone or audio plus vision
LFM3-Audio-2B can take text or audio input and respond with text, speech, or both. Liquid lists capabilities including transcription, multilingual speech generation, audio understanding, and tool calling across 18 languages. Reported numbers include a 50-millisecond time to first token in one streaming setup and speech decoding at about 87 times real time on a single Apple M4 Max CPU thread. Those figures are tied to specific implementation conditions - end-to-end conversational latency will also include audio capture, network or local processing, and playback.
LFM3-Omni-2B combines vision, audio, and language. It's positioned for spoken questions about images and video understanding with synchronized sound, plus tool calls informed by both visual context and voice instructions. A tablet assistant that reads a worksheet while answering spoken questions is one example; an in-car assistant that combines what the camera sees with what the driver says is another. Whether those use cases make sense depends on privacy, safety, and what it costs when mistakes happen - not just on what the model can technically do.
Decision models: structured output instead of a paragraph
d1-2B handles text and images, and d1-Omni-2B also accepts audio. Instead of generating a free-form response, these models answer sets of questions in a single forward pass using structured values and calibrated probabilities. Supported answer types include yes/no, choices, scores, object localization, extraction of text spans, numeric estimates, and multi-select answers.
That approach is useful for classification, routing, document extraction, and visual inspection - basically anywhere downstream systems need fields they can validate. It can be operationally easier than asking a chat model to explain a decision and then trying to parse the explanation. Still, probabilities aren't a drop-in replacement for validation. Teams need to calibrate confidence on their own data and define what happens when evidence is missing or confidence is low.
How strong are the reported LFM3 results
Liquid's benchmark results look encouraging for a model in this parameter range, but benchmarks are evidence about selected tasks - not a universal ranking. For the text model, Liquid reports an average of 49.37 across a set of agent, coding, instruction-following, knowledge, and long-context evaluations. It does well on tool-use and instruction-following tests, while larger models outperform on some knowledge and agentic coding benchmarks.
That pattern is believable. Tool calling, concise instruction following, and workflow control often benefit from post-training and a solid harness. Broader knowledge and harder coding tasks usually want more capacity, better retrieval, or additional inference-time work. Liquid also reports that using search nearly doubles LFM3-1.7B's score on Humanity's Last Exam. The takeaway is practical: retrieval and tools can help a compact model, but they also bring latency, system complexity, and extra failure modes.
Read benchmark tables as workload clues
For vision, Liquid reports a 71.4 average across 62 evaluations for LFM3-VL-2B - close to 71.7 for Gemma 4 12B and ahead of several smaller comparison models. The category scores aren't uniform. Agentic performance is lower than document, OCR, and chart performance. If your product focuses on visual document intake, the overall score is less helpful than testing with the exact document types, languages, and image conditions you'll see in production.
For audio, the reported evaluations span speech recognition, synthesis, voice interaction, tool calling, and audio understanding. LFM3-Audio performs strongly on some measures (including the listed English speech quality metric), but it doesn't lead every audio-understanding comparison. For omni tasks, the results similarly vary across audio-video understanding, image-audio reasoning, and spoken visual question answering. The honest conclusion: a model can be a great fit for one cross-modal interaction and a poor fit for another.
Performance claims need test conditions
Liquid reports that LFM3-1.7B is the fastest among the compared models on three tested devices using llama.cpp at Q4_0 with a 32K context. It reports 1.8 to 2.8 times faster decoding than the next model. At 128K context, it reports a 1.6GB KV cache versus 4.3GB for Qwen 3.5 4B and 5.6GB for MiniCPM5-2B. These details are useful for memory planning, but quantization quality and hardware specifics can shift results.
Liquid also reports high throughput on an NVIDIA B300 and low-latency serving under random traffic using its own inference pipeline. Server benchmarks won't automatically predict how it behaves on a laptop, phone, or a customer-managed cloud. Before you choose a model, reproduce the workload you care about: prompt lengths, concurrency, quantization, runtime, hardware, and what "success" means. Measure task completion and error cost, not tokens per second alone.
What changes when you run AI on-device
On-device inference changes more than hosting costs. It can keep sensitive inputs on the client, reduce reliance on a network connection, and make interactive features feel more responsive. It also shifts responsibility for memory usage, model updates, compatibility, and device variability closer to your product team.
Liquid says LFM3 is designed to run across different deployment environments, including support reported for llama.cpp, MLX, vLLM, SGLang, AMD, NVIDIA, Qualcomm, and Apple systems. But support isn't identical across every combination. Some paths may use optimized kernels or vendor acceleration; others may lean on a more general runtime. Test the exact path you plan to ship rather than assuming an open-weight model runs efficiently everywhere.
Privacy is an architectural benefit, not a complete policy
Running locally can reduce how much data you send to a cloud provider, which helps for private notes, workplace documents, and voice interactions. But local inference doesn't automatically make a product "privacy safe." Applications can still collect telemetry, sync histories, or expose data through logs, backups, and connected tools. If you operate under GDPR or similar regimes, you still need to understand what personal data gets processed, where it's stored, and how users can exercise their rights.
Local models also don't remove safety concerns. A model that can trigger tools, classify cases, or interpret camera input can still make consequential mistakes without a cloud round trip. Use scoped permissions, confirmation for high-impact actions, audit logs where appropriate, and a fallback for uncertain outputs. The right safeguards depend on the impact of an incorrect action.
The economics depend on the whole system
A compact model can lower per-request compute and make continuous background agents more practical. Liquid reports that LFM3-1.7B used 58% fewer tokens per task than Qwen 3.5-2B in a test of 65 everyday macOS agent tasks, with higher task success in that evaluation. That's a useful reminder that "efficiency" should be measured as cost per completed task, not cost per generated token.
But local deployment shifts costs rather than eliminating them. You may need to package model weights, support multiple hardware tiers, manage updates, and optimize quantized variants. If only a small slice of users need a feature, a server-side model may be simpler. If the feature must work offline, respond quickly, or keep data on-device, local inference can justify the engineering effort. Hybrid routing is also a reasonable strategy: handle routine or sensitive tasks locally and escalate harder cases when policy and connectivity allow.
How should teams evaluate and specialize LFM3
A model launch should be treated as the start of evaluation - not a reason to rip out a working system. Start by defining the task in operational terms: what input arrives, what output format counts as acceptable, what failure costs look like, and how often a human needs to step in. Then pick the narrowest LFM3 model that matches the modality and output format you require.
A practical evaluation sequence
- Build a representative test set. Include normal cases, edge cases, poor-quality inputs, relevant languages, and examples where the right answer is to abstain. Synthetic demos are fine for early exploration, but production-like examples reveal dataset gaps.
- Measure task outcomes. Track exact-match or extraction accuracy when it matters. Also measure completion rate, incorrect actions, retries, latency, and human review time. For agents, test the whole tool loop instead of the model response in isolation.
- Test the deployment path. Use the target runtime, device, context lengths, and quantization. Record peak memory, cold start time, sustained throughput, and response latency under realistic concurrency.
- Set acceptance thresholds. Decide which errors can slip through and which require a human check. Decide when the system should refuse or route to a more capable model. Do this before production, not after an incident.
- Compare against a baseline. Your baseline might be a larger hosted model, a rules-based workflow, or your existing human process. Include integration and maintenance costs.
Fine-tuning works best when the gap is specific
Liquid's examples show what specialization is supposed to look like. In a wind-turbine blade inspection demonstration, Liquid fine-tuned LFM3-VL-2B on about 3,000 public images using supervised fine-tuning and GRPO for a few hours on one A100. Liquid reports classification accuracy rising to 67% on roughly 1,400 held-out images, while detection F1 increased from 0.003 to 0.11. Those numbers show a meaningful improvement over the base model for that task, but detection F1 of 0.11 also signals that useful production performance likely needs more work and validation.
The general rule is simple: fine-tune when you have a repeatable, measurable gap and training examples that represent your target domain. Fine-tuning can help with domain labels, output formats, and recurring task behavior. It doesn't reliably fix missing facts, garbage inputs, or weak tool integration. Start with a baseline, keep a held-out evaluation set separate from training data, and monitor performance after deployment as inputs and operating conditions change - especially for sensitive or regulated decisions where human review needs to be part of the system.
LFM3's robotics demonstrations point in the same direction: tool orchestration, navigation, and manipulation as part of a larger system. They show that a compact multimodal model can be adapted as one component in a tool-using stack. They don't show that a model is ready to control physical equipment by itself. In real deployments, you still want a safety controller, independent monitoring, and staged testing. The model shouldn't be the only line of defense against dangerous actions.
Conclusion
LFM3 is less about any single benchmark number and more about the combination it's aiming for: compact models, multiple modalities, agent-oriented training, and deployment on both devices and servers. That combination can make local AI feel more practical for focused workflows. It also doesn't remove the need to test reliability, total cost, privacy controls, and failure handling.
Start with the task and its constraints. Choose the model that matches the inputs and outputs you need, then evaluate on your own data and hardware. If it meets your quality and operational thresholds, specialize it where there's a measurable gap. That's usually a more dependable path than choosing a model just because its launch benchmarks look good.