# LFM3 vs small Qwen models: choosing a model for local agents

Source: https://www.humanstoknow.com/blog/lfm3-vs-qwen-local-agents

Liquid’s new LFM3 text model targets specialized local agents. Small Qwen3.5 checkpoints add several sizes and built-in visual input. The useful comparison starts with the work you need either model to finish.

Author: Akshay Apsingi
Published: 2026-10-28T00:21:42.719Z
Updated: 2026-10-28T00:21:42.719Z

## TL;DR

- LFM3-1.7B is a text model worth evaluating for bounded tool workflows. Small Qwen3.5 checkpoints add visual input and a choice of capacity.
- Liquid’s published results favor LFM3 on selected tool benchmarks and Qwen3.5-9B on selected coding and knowledge tests. Those BF16 results are separate from its local 4-bit speed measurements.
- A model file fitting on your device is the first check. The useful result is a completed task, with valid tool arguments, handled failures and acceptable memory and response time.

![Two compact stacks of paper cards, with text on one side and text plus an image on the other, connect to a checked task.](https://www.humanstoknow.com/api/media/file/sha256-b96a5049f77a9d431d78c6cee030c11c7bd09f3c310ca235a339873a100d2261.jpg)

Choose the model around the input and the task. Editorial illustration created with Higgsfield.

An invoice arrives in your downloads folder. You want an agent to find the supplier, extract the total, check it against a purchase order and prepare the right filename. The documents stay on your machine. You approve the change before anything moves.

This sounds modest next to a demo of an agent building an application. It still asks a model to do several different things: read evidence, choose a tool, supply valid arguments, interpret the result and know when it has enough information. A small model can be quick at one step and unreliable at the next.

Liquid AI’s [LFM3 release on 27 October 2026](https://www.liquid.ai/blog/lfm3) makes these bounded local workflows especially interesting. Its compact text model targets agent tools and specialization. The small Qwen3.5 models offer another route, with visual input and several sizes to choose from.

Start by shortlisting LFM3 for a bounded text-and-tool workflow, and small Qwen when the input includes images. For sustained coding or complex reasoning, consider a wider range of models. These are starting points for evaluation, grounded in the differences below.

This comparison uses the original model cards, documentation and published evaluations, checked on 28 October. We have not run a head-to-head benchmark; the invoice workflow below is an illustrative design, with outcomes to verify.

## Which LFM3 and Qwen models are we comparing?

LFM3 is a family. Its text, vision, audio and decision checkpoints serve different purposes. Here, the main comparison is **LFM3-1.7B**, the text checkpoint, against **Qwen3.5-0.8B, 2B, 4B and 9B**.

| Checkpoint | Input | Published size | Default reasoning |
| --- | --- | --- | --- |
| [LFM3-1.7B](https://huggingface.co/LiquidAI/LFM3-1.7B) | Text | 1.73B parameters | On |
| [Qwen3.5-0.8B](https://huggingface.co/Qwen/Qwen3.5-0.8B) | Text and images | 0.8B language model, plus vision encoder | Off |
| [Qwen3.5-2B](https://huggingface.co/Qwen/Qwen3.5-2B) | Text and images | 2B language model, plus vision encoder | Off |
| [Qwen3.5-4B](https://huggingface.co/Qwen/Qwen3.5-4B) | Text and images | 4B language model, plus vision encoder | On |
| [Qwen3.5-9B](https://huggingface.co/Qwen/Qwen3.5-9B) | Text and images | 9B language model, plus vision encoder | On |

All five document a native context around 262,144 tokens, with Liquid describing this as 256K. That is a model limit, not a promise that the maximum context will be comfortable on your device.

These small Qwen checkpoints [arrived on 2 March](https://github.com/QwenLM/Qwen3.8). The newer Qwen3.8-27B belongs in a different memory class. Comparing it with LFM3 can be useful on a larger desktop, but it does not answer what to run on a constrained laptop or phone.

Licensing also differs: the linked Qwen checkpoints use Apache-2.0, while LFM3 uses the [LFM Open License](https://huggingface.co/LiquidAI/LFM3-1.7B/blob/main/LICENSE), with commercial-use conditions to check for your deployment.

## How their architectures change the local inference problem

A language model has to retain useful information from the input while it produces an answer. Full attention lets a layer refer back to earlier tokens, but retaining and processing that history has a cost. Both families combine different mechanisms instead of using the same full-attention operation throughout.

Liquid’s [architecture explanation](https://www.liquid.ai/blog/lfm3) describes a mix of gated short convolutions, sliding-window attention and global attention. A convolution combines nearby information. Sliding-window attention consults a bounded stretch of context. Global attention supplies access across the wider sequence. LFM3 distributes those jobs across its layers.

The small Qwen3.5 models interleave **Gated DeltaNet** with gated attention. DeltaNet maintains and updates a recurrent state: a compact working representation of what came before. Attention layers provide another route for relating tokens across the input. The [4B card’s layer specification](https://huggingface.co/Qwen/Qwen3.5-4B) makes that combination concrete. These small variants are dense models; the mixture-of-experts descriptions elsewhere in the wider Qwen family should not be applied to them.

For our invoice workflow, the consequence is practical. Reusing the instructions, reading a long purchase-order file and continuing after a tool response put different demands on the runtime. Two checkpoints with similar parameter counts can spend memory and time differently as the conversation grows.

Architecture helps explain those differences. It cannot tell us which complete setup will be faster on an untested machine. The engine still needs to implement the model’s operations and manage its state efficiently. Our [explanation of token generation and the KV cache](https://www.humanstoknow.com/blog/next-concept-modeling-ncm-explained) supplies useful background for separating prompt processing from answer generation.

## What Liquid’s published benchmarks actually tell us

Liquid’s [evaluation table](https://huggingface.co/LiquidAI/LFM3-1.7B#performance) presents a useful tension. LFM3 does well on selected tool-use tests; the larger Qwen model has stronger results on selected coding and knowledge tests.

| Benchmark, as reported by Liquid | LFM3-1.7B | Qwen3.5-4B | Qwen3.5-9B |
| --- | ---: | ---: | ---: |
| Berkeley Function Calling Leaderboard (BFCL V4) | 71.39 | 55.12 | 62.83 |
| ToolSandbox | 80.36 | 75.40 | 76.41 |
| SWE-bench Verified, OpenCode harness | 43.40 | 41.20 | 51.20 |
| GPQA Diamond | 63.37 | 75.76 | 80.40 |

These are Liquid’s reported scores, not measurements made for this article. Its quality evaluations use **BF16**, a 16-bit numerical representation, through the **vLLM** inference engine. The separate device-speed experiment uses compressed **4-bit weights in GGUF**, a model-file format, through the **llama.cpp** engine. Carrying a quality score from the first setup onto a speed figure from the second would imply a configuration that the table did not test.

The tests also ask different questions. Function-calling performance is relevant to choosing an invoice lookup tool and forming its arguments. A repository repair task needs sustained reasoning over code, edits and execution feedback. Knowledge questions probe a different weakness again.

Even a benchmark’s name leaves out consequential details. Liquid’s SWE-bench run uses an OpenCode agent harness with up to 250 turns. The score describes a model operating inside that process. It is not the probability that your shorter script will solve a bug.

Liquid explicitly cautions against using LFM3-1.7B for agentic coding or complex multi-step reasoning. Preserve that guidance when reading its coding score. For repository work, our [coding-agent guide](https://www.humanstoknow.com/blog/best-ai-coding-agents) explains why the environment, tests and review effort matter alongside the model.

## A tool call is one step in the invoice workflow

Suppose the invoice has already been converted into text. Give the agent two narrow tools: one retrieves a purchase order by its identifier; the other creates a proposed rename for a local file. Actual renaming remains behind the user’s approval.

An illustrative request might be:

> Read this invoice, check its total against purchase order PO-1042, and propose a filename containing the supplier and invoice date. If the evidence is incomplete or the totals differ, explain the problem instead of proposing the change.

The model should select the purchase-order tool and provide the identifier. Application code validates the requested tool and arguments, performs the lookup, and checks required fields, currency and totals deterministically. Compare amounts in the currency’s smallest units, with explicit handling for taxes or rounding rules. The model interprets the returned evidence and explains the next step; exact arithmetic belongs in code.

A successful path could look like this. It is an illustrative trace, not output from a test run:

```text
Extracted invoice: supplier=Acme, date=2026-10-15, PO=PO-1042, AUD 240.00
Requested tool: lookup_purchase_order(id="PO-1042")
Lookup result: one record, expected currency=AUD, total_minor_units=24000
Code validation: required fields present; currency and amount match
Proposed filename: Acme_2026-10-15.pdf; awaiting approval
```

Imagine the lookup returns two records with the same identifier. The useful behavior is to expose that ambiguity. Guessing a record and producing a beautifully formatted filename would make the task look complete while losing the check that justified it.

This is where the surrounding agent software matters. Liquid’s [tool-use documentation](https://docs.liquid.ai/lfm/key-concepts/tool-use) describes how schemas and tool results enter the conversation. Its [harness examples](https://docs.liquid.ai/examples/agent-harnesses) show the application layer around the model. A generated call is a request for that layer to execute something; it does not establish that execution succeeded. LFM3’s template also expects the assistant’s content and reasoning from the current tool-use turn to survive while tool results are added. Removing that state indiscriminately can change the conversation the model receives.

[Qwen-Agent](https://github.com/QwenLM/Qwen-Agent) provides Qwen’s corresponding framework for tools and integrations. Its parser, message history and execution loop are part of the configuration you are comparing. Replacing the model name while retaining an incompatible chat template can turn a model comparison into a formatting failure.

For this workflow, the first useful evidence is small and inspectable: the selected tool, its arguments, the returned purchase order and the final proposed filename. Test an exact match, a missing identifier and a mismatched total. Those cases reveal whether the agent follows the task’s contract before you give it a larger folder of documents.

If the source is a scanned invoice, another decision appears earlier. Qwen’s visual input can be a candidate for reading the image; the text-only LFM3 checkpoint needs an extraction stage or a different vision-capable model. A comparison should make that additional component visible.

## Reasoning mode is part of the configuration

“Turn thinking on” is not a neutral setting shared by every small model. It changes the output the model generates, the time it spends and sometimes whether it finishes.

The [Qwen3.5-2B documentation](https://huggingface.co/Qwen/Qwen3.5-2B) defaults to non-thinking mode and warns that enabling thinking can produce loops that fail to terminate. The 0.8B checkpoint carries the same warning. The [9B checkpoint](https://huggingface.co/Qwen/Qwen3.5-9B), like 4B, defaults to thinking. Qwen3.5 also uses supported API/template settings rather than Qwen3’s older textual thinking switches.

LFM3’s card defaults to thinking and notes that disabling it can be inconsistent. Treat the recorded reasoning setting as part of the model configuration, rather than describing every result under one model name.

The invoice example illustrates why this matters. Extracting a date and selecting a known lookup tool may not benefit from a long reasoning trace. A difficult discrepancy might need more capacity, a different tool or human input. Giving a small model more room to continue is not evidence that it will reach the correct answer.

Set a practical stopping condition in the application and inspect incomplete runs. Otherwise an apparently cheap local call can consume substantial time while the user waits for a task that never resolves.

## What fits in a download is different from what fits in memory

The official [LFM3 GGUF repository](https://huggingface.co/LiquidAI/LFM3-1.7B-GGUF/tree/main) lists `LFM3-1.7B-Q4_K_M.gguf` at approximately **1.10 GB**, compared with roughly **3.47 GB** for the BF16 GGUF. That makes the small download tangible. It is not a measurement of the complete agent’s working memory.

Loaded weights are one part of that memory. The runtime also stores context-related state and temporary buffers. An invoice application may additionally hold an image model, document parser, embeddings or several active conversations. The operating system needs room too.

Liquid’s device experiment fixes context at 32,768 tokens, batch size at one and output at 100 tokens, with GPU offload. The machines include an AMD Ryzen AI Max+ 395 system, an Apple M5 Max and an iPhone 17 Pro. Its [published methodology](https://huggingface.co/LiquidAI/LFM3-1.7B#performance) is evidence about those settings; it does not establish full-context performance on every consumer device.

For a useful comparison on your machine, keep the workload visible. Does the model load? Can it read the documents without exhausting memory? Does the next turn remain responsive after the conversation grows? Does the tool workflow finish correctly? These are related questions, but a successful download answers none of the later ones.

Likewise, compare quantized artifacts at meaningful settings. A 4-bit LFM file beside an unquantized Qwen checkpoint demonstrates a difference in representation as well as model size. It cannot, by itself, establish an efficiency advantage between the families.

## Specialize the job before adding more agent machinery

The most promising small-model application often has a recognizable input and a narrow output. That gives you a way to collect examples, describe failure and decide whether specialization helps.

Liquid’s [Hugging Face walkthrough](https://huggingface.co/blog/LiquidAI/lfm3) links notebooks for document extraction, answering or declining questions from retrieved documents, and selecting tools in a phone application. These are useful starting artifacts because they expose concrete tasks. Adapting a recipe still requires examples representative of your own inputs and a separate set on which to check the result.

Sometimes the bounded step does not need a conversational model at all. Liquid’s separate [d1-2B checkpoint](https://huggingface.co/LiquidAI/d1-2B) returns typed decisions and probabilities without generating an answer token by token. Classifying an unfamiliar document as an invoice, purchase order or unrelated correspondence is a candidate for that approach. Exact amount checks still belong in deterministic code; a learned decision is useful only when the step requires judgment.

That connects to our [Jev explainer](https://www.humanstoknow.com/blog/jev-ai-model-built-for-decisions) and [Laya vs Jev comparison](https://www.humanstoknow.com/blog/laya-vs-jev-agent-routing-open-models). The common question is which part of the workflow deserves its own decision model. A probability still needs checking against real errors before it controls an unattended action.

Keep the tool set equally focused. Our [article on agent skill bloat](https://www.humanstoknow.com/blog/ai-agent-skill-bloat) explains why catalogs and instructions can themselves become work for an agent. Its evidence does not establish an effect size for these local models, but the design question carries over: what information and choices does this particular task require?

## Choose the candidate around the work you can inspect

For a text workflow with a few well-defined tools, **LFM3-1.7B deserves an early trial**. Its release targets that use, and the published tool results justify investigating it. Use the actual runtime and template you plan to keep.

For image-bearing documents, **small Qwen3.5 models offer a relevant visual path**. The 0.8B and 2B versions provide constrained starting points for prototyping or specialization. A 4B or 9B checkpoint is worth considering when the smaller candidate misses distinctions the task requires and the machine has room for it. More parameters remain a cost to justify with better outcomes.

For coding or long chains of reasoning, widen the comparison. The needs of that work go beyond a fast tool call, and LFM3’s own guidance sets a clear limit on its intended use.

Start with the invoice you can check. Follow it from evidence to lookup to proposed action. Keep the cases where the model hesitates, invents an argument or accepts a mismatch. The useful local agent is the one whose result saves you work after that inspection—and whose limits are clear enough that you know when to take over.