What LFM2.5's 2.45B active parameters mean for local agents

Liquid AI released LFM2.5-24B-A2B on October 13 as a reasoning model for agents that run on local hardware. The name contains the first useful clue about how it works: the checkpoint has 24 billion parameters, while roughly 2.45 billion are active for each token.

That split is the attraction. A mixture-of-experts model can keep many specialized parameter groups available, then route each token through only a small subset. Liquid says this design lets LFM2.5-24B-A2B decode at 184 tokens per second on an Apple M5 Max and 114 tokens per second on an AMD Ryzen AI Max+ 395. Those are vendor measurements using a particular quantization, runtime, prompt length, and device setup, not a speed guarantee for every local agent.

The same split can also create the wrong mental model. Activating 2.45 billion parameters does not turn the checkpoint into a 2.45B deployment. The complete 24B model still has to be available somewhere, and the serving stack still has to move a token through its router, selected experts, attention layers, cache, and agent harness.

The practical question is therefore not whether 2.45B sounds small enough. It is whether the complete model fits the intended memory hierarchy and produces accepted agent work within the latency, privacy, licensing, and reliability boundaries of the service.

Active parameters reduce compute, not the whole checkpoint

The model card describes 64 experts in each mixture-of-experts block with top-four routing. For a given token, the router selects four experts rather than executing every expert. That can reduce per-token computation substantially compared with a dense 24B model.

Routing does not erase the inactive weights. The serving system needs the full checkpoint available in RAM, unified memory, VRAM, storage, or a slower tier it can page from. Quantization can shrink that footprint, and CPU or disk offload can make a model runnable on hardware that cannot hold every weight in fast memory. Those choices change cold-start time, memory pressure, and the chance that an expert route waits on data movement.

LFM2.5 also carries a 131,072-token context window. A large advertised context does not mean every deployment should fill it. Long prompts increase prefill work and key-value cache pressure, while an always-reasoning model can generate additional tokens before the final answer. The route is sparse, but the complete request still consumes memory, time, and energy.

The benchmark table shows where the model needs testing

Liquid reports strong results on several tool-use evaluations. LFM2.5-24B-A2B leads the compared models on AutomationBench, matches Qwen3.6-35B-A3B on BFCLv4, and leads it on ToolSandbox and LiveClaw. The same table shows Qwen ahead on WebArena Verified, GPQA Diamond, SWE-Bench Verified, and SciCode.

That variation is more useful than a single average. It suggests a model tuned for agent harnesses and tool dispatch can be excellent at some parts of an agent workflow while trailing on browser navigation, knowledge-heavy reasoning, or coding tasks. Liquid explicitly recommends retrieval or web search for knowledge-heavy work.

A benchmark result belongs to the setup that produced it: the model, the harness, their configuration, and the conditions of the run. Use the published results to narrow the candidate set, then keep the actual harness, tools, prompts, acceptance checks, and hardware fixed while comparing representative work. This avoids giving the model credit for a forgiving harness or blaming it for a tool schema that another system happened to handle differently.

A local-agent trial needs two separate capacity tests

Consider a hypothetical incident-triage agent running on a workstation with unified memory. It reads a sanitized alert, retrieves a runbook, queries a read-only diagnostic tool, and proposes the next check. The trial should separate model placement from task execution because a fast warm request can hide a slow startup or unstable memory boundary.

Test	Keep fixed	Measure	What it reveals
Cold load	Checkpoint format and host state	Load time, peak memory, page-ins, failures	Whether the full model fits the planned memory path
Warm tool loop	Harness, tools, prompt and acceptance rubric	Time to first token, dispatch latency, retries, accepted tasks	Whether sparse execution improves the actual workflow
Long-context replay	Document set and arrival pattern	Prefill time, cache growth, throughput, latency percentiles	Whether the 131K context is usable at the target objective
Failure recovery	Injected timeout and malformed tool result	Repeated actions, bounded failures, destination state	Whether the agent remains safe when a tool outcome is uncertain

Count accepted outcomes rather than attractive transcripts. A response can look correct while choosing the wrong tool, repeating a completed action, or omitting the evidence the operator needs. The site's inference compatibility suite covers the protocol layer, while the benchmark and harness analysis explains why the complete setup must travel with the result.

On-device privacy still has a service boundary

Running the weights locally can remove a cloud model API from the request path, but it does not make the complete agent private by itself. Retrieval services, web search, telemetry exporters, package downloads, and the agent's own tools can still send data outside the device. The deployment review should trace the whole task path, not stop at the inference endpoint.

The license also belongs in that review. Liquid distributes the model under its LFM Open License v1.0. The current license page says free commercial use is conditioned on the legal entity remaining below $10 million in annual revenue; larger entities need a separate commercial license. Open weights are not the same as unrestricted enterprise use.

Finally, local ownership moves operational work onto the team. Model files need integrity checks and controlled updates. The runtime needs capacity limits. The agent needs traces that connect its model calls and tools to an accepted result. A failed local endpoint, a paging storm, or a corrupt cache is now part of the service rather than somebody else's API incident.

What the release changes

LFM2.5-24B-A2B is available now in native, FP8, GGUF, ONNX, and MLX forms, with documented support for Transformers, vLLM, SGLang, llama.cpp, and several agent harnesses. That breadth makes it unusually easy to put the same model idea into very different serving conditions.

The October 13 release is meaningful because it combines a modest active path with a much larger expert pool, long context, tool-use training, and day-one local runtimes. It gives teams a credible candidate for private agent loops without pretending every workload is a good fit. The benchmark table itself shows the boundary: the model wins some agent tests and loses others.

LFM2.5-24B-A2B is a strong local-agent candidate, not a 2.45B deployment shortcut. Its sparse route reduces per-token compute, while the full checkpoint, harness behavior, license, and representative task results still determine whether it fits.