Eslam Hamed
Technical Lead & AI Solutions Architect
Building enterprise AI systems, cloud platforms, and production-ready software
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
| Specification | LFM2.5-2.6B |
|---|---|
| Parameters in the checkpoint | 2,697,198,592 |
| Layers | 30: 22 convolution and 8 GQA |
| Context | 131,072 tokens |
| Vocabulary | 128,000 |
| Training budget | 34 trillion tokens |
| Licence | LFM 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?
| Hardware | Decode speed reported by Liquid AI |
|---|---|
| Apple M5 Max | 220 tokens per second |
| AMD Ryzen AI Max+ 395 | 113 tokens per second |
| Unnamed phone | 30 tokens per second |
| NVIDIA H100 SXM5 | Almost 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.
| Benchmark | LFM2.5-2.6B | Qwen3.5-9B |
|---|---|---|
| ToolSandbox | 77.83 | 76.44 |
| BFCLv4 | 56.88 | 60.13 |
| IFBench | 59.17 | 56.47 |
| Multi-IF | 80.07 | 62.55 |
| AIME25 | 51.87 | 56.07 |
| LiveCodeBench v6 | 59.41 | 69.86 |
| Claw-Eval (EN) | 62.85 | 66.53 |
| AA-Omni-Public accuracy | 8.13 | 21.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
- Liquid AI, Deploy local agents everywhere with LFM2.5-2.6B, August 4, 2026
- LFM2.5-2.6B model card
- LFM2.5-2.6B GGUF files
- LFM Open License v1.0
Written by Eslam Hamed, a Technical Lead and AI Solutions Architect working on enterprise RAG, agentic AI, and AI SaaS products.