Liquid AI LFM2.5-2.6B: What a 2.7B-Parameter Agent Model Can Really Do on a Device

Most AI news this summer has concerned very large models and what happens when they get loose. Liquid AI's release on August 4 points the other way: LFM2.5-2.6B is a small model built to run agents on your own hardware, including a phone.

The pitch is simple. Tool calling, data extraction, document handling and background tasks, locally, at speeds that feel usable, in under 2.5 GB of memory.

After the Grok Build upload story, a model that sends nothing anywhere has obvious appeal. So I went through the published numbers to see what they support. Everything below is reported by Liquid AI unless I say otherwise. I found no independent evaluation as of today, and I have not run the model.

LFM2.5-2.6B specifications

SpecificationLFM2.5-2.6B
Parameters in the checkpoint2,697,198,592
Layers30: 22 convolution and 8 GQA
Context131,072 tokens
Vocabulary128,000
Training budget34 trillion tokens
LicenceLFM Open License v1.0

Source: model card.

A small note on the name: at nearly 2.7 billion parameters in the safetensors file, it is larger than "2.6B" suggests. It does not change anything in practice, but I prefer the exact count.

The architecture is the interesting part. Most of the layers are convolutional rather than attention. That is a different design from the transformers dominating the rest of the field, and it may be part of how Liquid gets this speed from so few parameters.

How fast is LFM2.5-2.6B?

HardwareDecode speed reported by Liquid AI
Apple M5 Max220 tokens per second
AMD Ryzen AI Max+ 395113 tokens per second
Unnamed phone30 tokens per second
NVIDIA H100 SXM5Almost 15,000 output tokens per second

Those are good figures, and they arrive with gaps. Liquid names no quantisation, runtime, thread count or prompt length for the device numbers, and it does not say which phone. The figure of under 2.5 GB is attached to the M5 Max and Ryzen results.

One thing can be worked out. The GGUF files range from 1.59 GB at Q4_0 to 2.88 GB at Q8_0. A 2.88 GB file cannot fit in under 2.5 GB of memory, so that claim implies Q6_K at 2.22 GB or smaller, before any context cache. This is my inference, not a statement from Liquid, and it matters because quality and speed both move with quantisation.

Phones need extra care. Thirty tokens per second reads well, but we know nothing about sustained speed once a device warms up, battery use, or time to first token. An agent does not make one request. It makes ten in a row, and a phone throttles. That number needs to be measured on the handsets your users own.

The H100 figure is the one I did not expect to care about. About 1.3 billion tokens a day on one GPU makes this interesting as a cheap server model as well, for bulk extraction jobs where a frontier model would be overkill.

LFM2.5-2.6B benchmarks: where it leads and where it trails

Liquid compares the model with several small models. The comparison with Qwen3.5-9B, more than three times its size, shows the trade-offs most clearly.

BenchmarkLFM2.5-2.6BQwen3.5-9B
ToolSandbox77.8376.44
BFCLv456.8860.13
IFBench59.1756.47
Multi-IF80.0762.55
AIME2551.8756.07
LiveCodeBench v659.4169.86
Claw-Eval (EN)62.8566.53
AA-Omni-Public accuracy8.1321.30

Source: Liquid AI, August 4, 2026. Vendor-run results.

I read this table as an honest picture of a specialised model.

It is very strong on following instructions, with a large lead on Multi-IF. That suits structured work. On tool calling the result is mixed: a 1.39-point lead on ToolSandbox, which may or may not sit outside repeat-run noise, and a deficit on BFCLv4.

It is weak where you would expect. The drop on LiveCodeBench and on closed-book knowledge is large, and the 8.13 on AA-Omni-Public is low in absolute terms. Liquid's own card agrees: "It is not recommended for agentic coding and knowledge-heavy tasks."

Credit to Liquid for saying that plainly. Many vendors would not.

A small model should not be asked to remember

That low knowledge score matters less than it first appears, in one common case. A closed-book accuracy test measures what a model knows unaided. In a retrieval system, the facts arrive with the request, and the model's job is to read, extract and format.

So a model like this could do well on tasks that are mostly reading and acting, as long as your application supplies the knowledge. That is my reasoning, not a tested result. I would verify it on your own documents, with attention to whether it invents details when the retrieved context does not contain the answer.

Where a model like this fits in an agent

I would not build a whole agent on LFM2.5-2.6B. I would give it the cheap steps.

Career Rafeeq, the AI SaaS product I built, uses a deterministic pipeline of eight fixed phases instead of an agentic loop. Its refinement phase only fires below a confidence threshold, so the expensive path runs only when the cheap one is unsure. That shape suits a tiered model strategy well: validation, routing, extraction and tool-argument formatting can go to something small, and only the difficult judgement goes to something large.

For on-device products, the same split decides what leaves the machine. A local model can read sensitive content, pull out what is needed, and pass only a minimal request upward, or nothing at all.

Read the licence before you ship

LFM2.5-2.6B is open in the sense that you can download it, and the licence still has a limit that matters to businesses.

  • Under the LFM Open License v1.0, unlicensed commercial use stops at $10 million in annual revenue.
  • Affiliates count through the definition of "Legal Entity", so a small subsidiary of a large group may not qualify.
  • Qualified non-profits are exempt for research.
  • "Revenue" is undefined, and the document says "or more" in one place and "exceeding" in another, which leaves the exact threshold ambiguous.

Startups and individual developers are fine. Larger companies need a conversation with Liquid before shipping this.

What I would test before adopting it

  • Your own tool schemas. Measure argument correctness across multi-step sequences, not single calls.
  • Sustained device speed. Run ten consecutive tool calls on a mid-range phone and watch for throttling.
  • Memory at full context. Find out which quantisation stays within budget with a full 131,072-token cache.
  • Failure behaviour. What does it do when a tool returns an error, or when the answer is not in the context?
  • Quantisation against quality. Re-run your evaluation at the size you intend to ship. The benchmark table does not say what it used.

LFM2.5-2.6B is a good example of a model that knows what it is. It does not claim to replace a frontier system. For the routine steps inside an agent, I think it could be very useful, once someone other than the vendor has measured it.

There is something refreshing about a month's most interesting agent model being one that cannot reach anything you did not hand it.


Sources

Written by Eslam Hamed, a Technical Lead and AI Solutions Architect working on enterprise RAG, agentic AI, and AI SaaS products.

Back to all posts

More posts