Liquid LFM3 asks a better local-AI question: which small model does the job?

A local assistant that reads a receipt does not necessarily need the same model as one that answers a spoken question. A program choosing among three allowed actions has a different job again. Treating them as one task can make a small application unnecessarily complicated.

Liquid AI announced LFM3 on October 27, 2026: six roughly 2B-class models branching from a shared 1.7B foundation, covering text, vision, audio, omni and two decision variants. The company provides open weights, a Playground and API access. LFM3 announcement.

The interesting decision is which role belongs in your application. This guide explains the family through practical choices, separates a compact weight file from a working memory budget, and offers a first evaluation that can reveal whether a specialist is useful on your own hardware.

Raspberry Pi 5 hardware; illustrative edge-computing context, not our LFM3 test. Image: RetroEditor, CC BY 4.0; resized with margins. Image source · License and image notes. Official product reference.

A family of specialists starts with the output you need

The fastest way to choose badly is to start with the largest list of supported inputs. Begin with the output your application must produce. A paragraph, a transcript, a structured field and a choice among allowed actions are different contracts, even if the same source material could help produce all four.

Liquid's October 27 announcement identifies four modality branches and two decision branches: LFM3-1.7B, LFM3-VL-2B, LFM3-Audio-2B, LFM3-Omni-2B, d1-2B and d1-Omni-2B. The following table translates those roles into application-selection questions. It is a guide to fit, rather than an independent quality ranking. Family description.

Our take: the useful unit of local AI is the smallest complete job. A model should have enough capability to meet a clear application contract, together with a way to handle uncertainty. Everything beyond that has a runtime, testing and integration cost that needs to earn its place.

Think of the family as a tool roll. Carrying every tool is sensible for some jobs; for a repeated adjustment, choosing the right tool can be simpler. The analogy is about application design, not a claim that one model always beats another.

Original explanatory diagram of the roles named in Liquid AI's LFM3 announcement. It groups application choices and omits internal implementation detail.

Open weights give you deployment choices, with a license to read

Downloading weights gives a developer something concrete to package, evaluate and adapt. It can support a local deployment where the application's data path stays under the developer's control. That is useful, but the presence of a downloadable file does not settle its commercial terms.

Liquid's model catalog, checked November 2, describes free commercial use until a company passes $10 million in annual revenue. The LFM3-1.7B model card identifies the LFM Open License v1.0. Read the license attached to the exact checkpoint and the current licensing page for the intended deployment, distribution and revenue situation.

This is a practical procurement step. A small internal prototype, a downloadable consumer app and a service supplied to other businesses can raise different questions about distribution and obligations. Record the model identifier, revision and license alongside the application so the decision remains traceable when the project grows.

Runtime software and model weights also have separate versions. A model can be available while the runtime on your device still lacks compatible support. Check the documented combination instead of assuming that every application capable of loading an earlier family can load the new one correctly.

For a team, this record should include the prompt or template expected by the checkpoint. A compatible loader can still produce poor behavior if the input is formatted incorrectly. Reproducibility begins with knowing what was actually loaded and how the application spoke to it.

About 1 GB of weights is the beginning of a memory budget

Liquid describes the text model's 4-bit footprint as about 1 GB in its October 27 launch material. The text model card specifies 1.73 billion parameters and a 256K-token input-plus-output context. Those are model specifications; your application's peak memory depends on the workload and runtime as well.

A weight file is only one part of a running process. The runtime needs working memory; context processing needs state; multimedia inputs can require additional buffers and encoders. Other programs on the device compete for the same resources. A weight-size headline cannot tell you whether the whole application will remain comfortable under load.

An illustrative budget should therefore start with a measured process footprint. Record the application's idle state, the peak while it processes a representative request, and the state after repeated requests. Test the context length and input sizes that users will actually supply rather than a tiny prompt selected because it fits easily.

The same discipline applies to time. Startup, prompt processing and response generation are separate waits. A model that produces tokens quickly after a long delay may feel slow in an interactive application; a batch task may care more about completed items per hour. Choose the measure that matches the interaction.

For an audio feature, include the whole path from input to usable result. For an image feature, include image handling. For a decision feature, include validation and the action handoff. These are evaluation requirements you define, rather than performance figures supplied by the release.

Original memory-budget diagram. Segment widths are illustrative and carry no measured proportions; the approximately 1 GB figure refers to Liquid's published 4-bit text-model footprint, not total application memory. Source.

Three illustrative applications expose different tradeoffs

A document helper can separate reading from deciding

Imagine a small business application that receives photographed receipts. One job is to read the visible merchant, date and amount. Another is to decide whether the document is complete enough for a person to review. Those outputs deserve separate validation even if one model contributes to both.

A vision-language path could support questions about the image; a decision path could be evaluated for a bounded completeness check. The application should retain the source image and distinguish extracted fields from accepted bookkeeping data. A missing date should remain missing until someone resolves it.

Build an illustrative evaluation set with clear images, blurred images, unusual layouts and receipts in the actual working languages. Measure field-level mistakes and review workload. A high overall success rate can hide a recurring error in the field that matters most to the business.

The useful product result is a shorter, clearer review queue. Whether a model produces an elegant explanation matters less than whether the reviewer can inspect the source and correct the fields. That priority helps choose between open-ended language output and a more constrained decision interface.

A spoken interface can begin with a narrow set of permitted actions

Consider an illustrative hands-free assistant for a local application. The user can ask to find an item, read its status or prepare a draft action. Audio capability becomes useful when speaking is easier than typing, but the application still needs to know what a request is allowed to change.

Start with a small action vocabulary and a visible confirmation path. For example, a request to locate a record can run immediately within authorized data, while a request that would change the record can present a proposed action for review. The policy belongs to the application, rather than to whatever wording the model happens to produce.

Test the actual acoustic conditions. Background conversation, short utterances and similar names can create different failure patterns from a clean recorded sentence. Include cases where the correct outcome is to ask the user again. A fluent spoken answer is less useful than a correct, recoverable interaction.

An omni candidate becomes relevant when the request depends on what is visible as well as what is said. If every task uses only speech, adding visual processing needs a reason. This is where the family approach can help keep the feature proportional to the job.

A local support tool can route work while preserving an escape path

An illustrative support application might choose between three queues using a ticket and an attached screenshot. A bounded decision output can fit that task more directly than a long answer that the application must interpret. The useful question is whether the chosen route is dependable enough at an acceptable review rate.

Keep an explicit “needs review” outcome. Test tickets that match none of the allowed queues, contradictory screenshots and cases with insufficient context. The application should not make the model invent a valid route simply because the schema demands one.

Compare the model with a simple baseline, such as existing rules and human routing. If the baseline already handles a category reliably, the model needs to improve a different part of the workflow. Novelty is not an acceptance criterion.

For each mistake, retain enough authorized context to understand why it happened. Separate input problems, ambiguous categories and model errors. That distinction tells you whether to improve the model, change the queue definitions or ask for better source material.

Benchmark tables are a starting point for your own workload

The official LFM3-1.7B model card, checked November 2, recommends retrieval or search for knowledge-heavy work and cautions against agentic coding and complex multi-step reasoning at this size. That is useful guidance for placing the model inside a larger system, even when vendor benchmark tables show progress.

A benchmark result answers a specific question under a particular setup. Your application adds its own data, tools, language distribution and failure costs. A model can improve on a public aggregate while still needing careful work on the handful of categories your users encounter every day.

Separate three comparisons in a pilot. First, compare task quality against the current workflow. Second, compare the complete resource cost on the intended device. Third, compare the work required to recover from a failure. Those comparisons can lead to different winners.

A cloud generalist, for example, may be useful as an escalation path when a local specialist declines. That arrangement needs an explicit data policy and user experience. Local operation is a deployment choice you verify across the whole application, including logging and fallback requests.

Fine-tuning should follow a demonstrated gap. If failures come from missing source material or unclear output definitions, more training may reinforce the wrong task. Define the contract and inspect errors before deciding that customization is the next useful step.

A first pilot should fit on one page of decisions

The official text-model card links checkpoint formats and runtime instructions. Begin there for the exact model/runtime combination; use the official Playground for an initial interaction check if that suits your data policy. Neither route substitutes for testing the deployment you plan to ship.

1. Write the input and output contract. State the allowed material, expected result and explicit review outcome. Choose one task rather than a general assistant persona.
2. Choose the candidate and revision. Match modality and output role, then record the checkpoint, license and compatible runtime. Read the model-specific limitations.
3. Create a representative evaluation set. Include ordinary cases, difficult cases, unsupported requests and examples in the actual user languages. Keep held-out material separate from customization data.
4. Run the documented quick start in an isolated environment. Follow the model card's current dependency and formatting instructions. Confirm the returned model identity before comparing outputs.
5. Measure the complete application path. Capture correctness, review rate, latency and peak memory for realistic input sizes. Record hardware and runtime settings alongside the numbers.
6. Exercise the uncertainty path. Confirm that missing information, invalid output and runtime failure lead to an understandable review or retry state.
7. Decide what to specialize next. Use recurring error categories to choose between better input, clearer rules, retrieval, fine-tuning or a different model.

For the first pass, the written decision can be simple: this candidate is useful for this task on this device, with these review conditions. A narrow, reproducible conclusion is more valuable than a general claim that local AI is ready for everything.

A small model earns its place by completing a defined job

LFM3 broadens the menu for developers who want text, sight, sound or bounded decisions near the application. Its practical significance comes from being able to choose among those roles and evaluate them as parts of a product.

The next step is to make one job precise enough that quality, memory and recovery can all be measured. A specialist becomes useful when the entire application can rely on its contract and knows what to do when it cannot answer.

Sources

• Liquid AI: Introducing LFM3, October 27, 2026; checked November 2, 2026.
• Liquid AI model catalog and pricing and licensing, checked November 2, 2026.
• Official LFM3-1.7B model card, checked November 2, 2026.
• Official d1-2B model card, checked November 2, 2026.

Preserve the material behind a decision

Telli.sh is one option for keeping authorized source material alongside the notes you have reviewed. Create a note workspace.