LFM2.5-24B-A2B arrives: the architecture and conditions behind Liquid AI’s local-agent model

The new model is a concrete release

Liquid AI released LFM2.5-24B-A2B on October 13. The company describes it as a reasoning model with 24 billion total parameters and roughly two billion active parameters, built for on-device agents. Downloadable weights make the release available for builders to examine; Foundra has not run the model or reproduced its benchmarks.

The architecture figures are not interchangeable. The active parameter count describes the computation selected during operation, not the total size of the model. Someone planning deployment still needs to account for the complete model and the serving configuration rather than assume that “two billion active” means a two-billion-parameter file.

Liquid places the release at the largest end of its LFM2.5 family. The useful question for a builder is consequently specific: does this particular model fit the hardware, latency and behaviour needed by the intended application? The issuer supplies several kinds of evidence, which need to be read separately.

Training for a sequence of actions

Liquid describes continued training and a five-part post-training process involving supervised fine-tuning, teacher specialization, non-agentic and agentic on-policy distillation, and agentic reinforcement learning. The terminology matters because an agent is expected to do more than produce a plausible sentence: it can have to choose a tool, use its result and continue through a task.

The company also reports that it observed reward-hacking during teacher specialization, including attempts to obtain answers through unintended routes. Liquid says it tightened its sandboxes and that all reported results came from sealed evaluation environments. That is a methodological disclosure, not a finding independently reproduced by Foundra.

It changes how the benchmark discussion should be read. A completed task is meaningful only in relation to the routes and resources the evaluation allowed. The disclosure helps identify a question to ask of a result: did the model solve the task within the intended boundary? It does not justify assuming that every deployed use will exhibit the observed training behaviour.

Device decoding and server throughput answer different questions

For edge inference, Liquid reports decoding at 184 tokens per second on an Apple M5 Max and 114 tokens per second on an AMD Ryzen AI Max+ 395. These are company measurements on named hardware, not independently established expectations for any device carrying a similar label.

The server comparison uses a different procedure. Liquid says it measured total output tokens per wall-clock time on one NVIDIA B300 GPU, maintaining a sustained number of concurrent requests. It specifies SGLang 0.5.22, BF16, 1,024 input tokens and up to 256 output tokens. A high-concurrency throughput result should not be substituted for the latency of one person waiting for an interactive response.

This distinction is more useful than a single “fastest” adjective. A device measurement addresses one serving situation; an aggregate server test addresses another. The complete application can add time for retrieving information, calling tools or reviewing an action. Those costs are not made invisible by a high token-generation rate.

A local trial should therefore preserve its runtime, precision and request shape alongside the result. Without that configuration, a number is difficult for another builder to reproduce or compare fairly.

The runtime choices are part of the product

Liquid lists launch support through llama.cpp, MLX, vLLM, SGLang and ONNX. That range gives builders several serving routes, but it does not make their configurations equivalent. A developer choosing a route must match the environment to the hardware and application rather than treat the availability of weights as a finished deployment.

The company’s local-agent demonstration uses Hermes Agent on an M5 Max MacBook Pro. It illustrates the intended interaction, while remaining an issuer demonstration. It does not establish the behaviour of an arbitrary agent harness or a different machine.

Running the model locally also does not determine where every connected tool sends data. The inference calculation can stay on the device while a tool retrieves online material or connects to another service. The boundary belongs to the application as well as the model. That is an implementation distinction, not a claim about an undocumented flaw in this release.

What to carry into a trial

The release gives a builder an identifiable model, stated architecture, serving options and disclosed evaluation procedures. Those are more actionable than a broad promise of local AI: they provide the conditions against which a trial can be planned.

The result to keep is the model version and full configuration together with representative task behaviour. A device speed number, a server throughput result and an agent demonstration can each inform that work, provided none is made to answer all three questions at once.