Evidence at a glance
The Local-Agent Tension: A Large Model with a Lighter Step
Liquid AI has released LFM2.5-24B-A2B on Hugging Face, a 24B-parameter reasoning model aimed at local agents. The goal is not simply to let a chat model answer questions on a device. It is to have the model reason, call tools, and keep a multi-turn task moving while reducing the cost of running an agent continuously. The A2B in the name points to roughly 2B parameters activated for each token, which is the source of the efficiency claim.
Those numbers create a tension that is easy to misread. The 24B figure describes the model's total scale, while 2B describes how many parameters are active in a token's computation. They are not interchangeable measures of hardware requirements. Sparse activation can reduce computation at each step, but it does not mean the model only needs storage for 2B parameters. Liquid AI says it uses the least memory among the compared models, but the release gives no absolute memory footprint, quantization configuration, or minimum device specification. Whether it fits a particular local setup still has to be established on that hardware.
The Model Has Not Become Small; Computation Is Distributed Differently
LFM2.5 keeps the main architecture of LFM2-24B-A2B: 40 layers, 64 experts in each MoE block with top-4 routing, and a combination of gated short convolutions and grouped-query attention. In other words, it is not a dense 2B model created by cutting a 24B model down to size. It retains a larger pool of experts while routing each token through only part of that pool. This helps explain how model scale and inference speed can tell different stories, but it does not remove practical constraints from loading weights, caching context, or choosing an inference backend.
The update also broadens the range of inputs the model is trained to handle. Its context window grows from 32K to 131K tokens, and its vocabulary expands from 65K to 128K, which Liquid AI says helps with tokenization for non-Latin text. Pretraining increases from about 17T to about 33T tokens. The next stage adds 2T tokens at 32K context, weighted toward reasoning, math, code, instruction following, and multilingual content, followed by 300B tokens at 131K context, weighted toward long-context data. These changes expand training coverage, but the release does not specify the memory cost of long-context use on different devices.
Training Shifts from Answering Questions to Working Through Tools
One key difference from its predecessor is that LFM2.5 is described as a reasoning-only model, producing an explicit reasoning trace before its final answer. Training also includes tool calls and multi-turn interaction trajectories, while post-training combines multi-domain on-policy distillation, a second distillation stage focused on agent tasks, and reinforcement learning inside agent harnesses. Liquid AI names OpenClaw, Hermes Agent, Pi, and OpenCode among those environments. The design suggests that the target is not merely plausible text generation, but continuing to act after receiving feedback from tools.
For engineering teams, this changes how the relevant workload should be evaluated. A model must follow instructions, select tools, and handle the information returned across multiple interactions. A single-turn knowledge score cannot predict all of that. Liquid AI evaluates the model on 16 benchmarks spanning tool use and agent workflows, knowledge, instruction following, math, and coding. It says LFM2.5 leads or matches on five of eight tool-use and agentic benchmarks, and leads on all three instruction-following benchmarks. However, the release does not provide task-by-task failure cases or an analysis of stability across harnesses. The training objective cannot substitute for testing against a team's own tool definitions.
The Benchmark Edge Centers on Tools, and Speed Figures Have Conditions
Specific scores are more useful for model selection than a general claim of strong agent ability. On LiveClaw, LFM2.5 scores 48.09, compared with 38.19 for Qwen3.6-35B-A3B, which has roughly 50% more total and active parameters. Liquid AI also says LFM2.5 scores more than three times the next-best model on AutomationBench. At the same time, larger models retain an edge on knowledge-heavy benchmarks such as GPQA Diamond, HLE, and AA-Omniscience, as well as coding benchmarks including SWE-Bench Verified and SciCode. The pattern points to a specific trade-off: tool execution and instruction following are the more persuasive entry points. It does not show that the model outperforms larger alternatives on every task.
Speed figures also need to be read with their hardware and workload attached. Liquid AI reports 184 tokens per second on an Apple M5 Max and 114 tokens per second on a Ryzen AI Max+ 395, making it the fastest among the compared MoEs and up to 1.7 times faster than the next-best model. The figure of over 21K output tokens per second on a single NVIDIA B300 is reported at high concurrency. It is not a measure of device-side response speed for one user interaction. The evaluations use vLLM and each benchmark's recommended generation parameters, so they offer a basis for comparison, not a guarantee of latency on another backend, concurrency pattern, or application stack.
Deployment Paths Are Available, but Privacy and Fit Still Need Validation
At release, Liquid AI lists support for llama.cpp, MLX, vLLM, SGLang, and ONNX, and provides a Transformers loading entry point requiring a compatible version of Transformers 5.0.0 or later. Agent-training environments and inference backends are not the same thing, and support for a backend does not guarantee that a team's tools, model format, and hardware combination will work seamlessly. Technical leads should treat these entry points as lowering the cost of a trial, not as a promise that integration checks can be skipped. The release does not compare accuracy, memory use, or speed across these deployment paths, so a compatibility list alone cannot determine the production setup.
“Local” and “private” also need to be assessed by tracing data flows. Local inference may reduce the need to send prompts to a remote model service, but if an agent calls web search or another networked tool, requests and returned content may still leave the device. Given the benchmark profile, a sensible starting point is to test tool use, instruction following, and multi-turn tasks on the target hardware, then add retrieval or web search for knowledge-heavy requests and review tool data flows separately. If a team's primary workload is complex code repair or broad knowledge queries, larger models should remain in the comparison set. LFM2.5 makes local agents more practical to investigate. It does not make hardware constraints, task boundaries, or governance concerns disappear.