Loading stories…

LFM3 vs Small Qwen Models for Local AI Agents | Humans to Know

LFM3 vs small Qwen models: choosing a model for 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.

Akshay Apsingi

28 October 202611 min read

Updated 28 October 2026

Two compact stacks of paper cards, with text on one side and text plus an image on the other, connect to a checked task. — Choose the model around the input and the task. Editorial illustration created with Higgsfield.

On this page

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.

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 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.

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	Text	1.73B parameters	On
Qwen3.5-0.8B	Text and images	0.8B language model, plus vision encoder	Off
Qwen3.5-2B	Text and images	2B language model, plus vision encoder	Off
Qwen3.5-4B	Text and images	4B language model, plus vision encoder	On
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. 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, with commercial-use conditions to check for your deployment.

What Liquid’s published benchmarks actually tell us

Liquid’s evaluation table 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 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:

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 describes how schemas and tool results enter the conversation. Its harness examples 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 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.

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

TL;DR

Which LFM3 and Qwen models are we comparing?

How their architectures change the local inference problem

What Liquid’s published benchmarks actually tell us

A tool call is one step in the invoice workflow

Reasoning mode is part of the configuration

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

Specialize the job before adding more agent machinery

Choose the candidate around the work you can inspect

Written by Akshay Apsingi