Developers trying Liquid AI's new LFM2.5-24B-A2B need to budget for reasoning before they get an answer. Its published chat template starts each fresh assistant response with a reasoning marker. That makes time to a useful tool call a more revealing test than token speed alone.
Liquid AI released the model on October 13, with downloadable base and post-trained weights. The company trained the latter inside agent software including Hermes and OpenCode. For developers building local assistants, the immediate question is whether faster generation compensates for the work the model does before answering.
What the 184-token figure measures
Liquid reports 184 generated tokens per second on an Apple M5 Max and 114 on an AMD Ryzen AI Max+ 395. The model card's measurement notes specify llama.cpp, Q4_K_M quantization and a 4K-token input. These are vendor measurements under stated conditions. They don't establish the same speed across the model's full 131,072-token context window.
The same card reports more than 21,000 output tokens per second on one NVIDIA B300. That experiment used BF16 weights, SGLang 0.5.22, 1,024 input tokens and up to 256 output tokens, with requests continuously replenished to maintain concurrency. It's aggregate server throughput. A person waiting for one local agent action shouldn't read it as the speed of their individual response. Liquid's test description makes that distinction possible.
The shipped template adds another variable: reasoning text precedes the answer. As an illustration, 1,000 generated reasoning tokens would take about 5.4 seconds at a steady 184 tokens per second, before counting prompt processing or tool execution. That is arithmetic, not an observed task result. A useful evaluation should record how much the model generates before its first valid action, then how long the entire job takes.
Two billion active parameters still means a larger download
The A2B label is rounded. Liquid's detailed specifications list 24.0 billion total parameters and 2.45 billion active ones. They also identify this as a text-only model. For a local assistant that needs to inspect screenshots, the release doesn't supply that capability on its own.
The model configuration lists 64 experts and selects four per token, across a 40-layer architecture that mixes convolution and attention. This is a mixture-of-experts design: generation uses a selection of the available expert weights at each step. The active count describes computation for that step. It doesn't mean the remaining weights disappear from the deployment.
You can see the difference in the official GGUF file listing: the Q4_K_M file is 14,526,258,464 bytes, about 14.5GB in decimal units. That is the model file, before runtime allocations and the operating system. Treating the A2B name as a promise that this fits wherever a small dense model fits would lead to a bad hardware estimate.
The configuration also sets the maximum context at 131,072 tokens. That is a capacity limit, separate from the 4K input used in the speed test. For a local-agent trial, choose a context length that reflects the task you actually need to run. A short request and an accumulated session full of tool results are different workloads, even when both use the same checkpoint configuration.
Tool scores don't settle the coding question
Liquid's published comparison gives LFM2.5-24B-A2B 27.69 on AutomationBench against Qwen3.6-35B-A3B's 8.72, and 48.09 on LiveClaw against 38.19. The ordering reverses on WebArena Verified: Liquid scores 26.75 against 37.62. On SWE-Bench Verified using OpenCode, it reports 51.00 against Qwen's 66.20.
Those results support trying the model on tool workflows while keeping coding expectations specific. They don't support treating every kind of agent task as one capability. For a repository assistant, the OpenCode result is directly relevant evidence to weigh alongside the faster generation claim. These are Liquid's evaluations, not a MrKeyoor reproduction. A local comparison should use the same task and acceptance checks for each model.
A tool call still needs application code
Liquid's tool-use documentation describes a loop in which the model emits a function call, the application executes it, and the result returns as a tool message. The model then generates again. By default, calls use a Python-like representation between special tokens. The documentation also describes requesting JSON output through the system prompt.
This division matters when measuring a complete agent. Generating a valid call, executing the function and interpreting its result consume separate parts of the wait. The documented loop gives developers concrete places to add timestamps. It also makes clear where execution happens: application code receives the model's proposed call. Running inference locally doesn't remove that responsibility from the software around it. The execution example shows the handoff explicitly.
Tool definitions themselves consume context because they're inserted as text. Liquid recommends including only tools relevant to the request, especially when a list grows large. That gives a developer another useful test condition: keep the exposed tool set consistent when comparing models. Otherwise, a change in prompt size or available functions can muddy the result. The advice comes from the same tool-use guide.
Connecting the model is only part of the trial
Prompt formatting needs to survive the connection, too. Liquid's chat-format documentation defines separate system, user, assistant and tool roles, separated by special tokens. It points developers to each checkpoint's own template and recommends applying that template through the tokenizer. If you're writing an integration directly, use the supplied formatting rather than flattening a conversation into an improvised text prompt.
Liquid's local-agent guide connects agent software to an OpenAI-compatible local endpoint. Its examples mainly use the smaller LFM2.5-2.6B, while explicitly allowing substitution of the 24B model ID. Copying the default example unchanged would therefore test a different model. Check the requested model name and the server's actual port before comparing results.
The guide also requires tool calling to be enabled and gives backend-specific configuration. For Hermes, it calls out tool-use enforcement because the model can otherwise describe actions instead of invoking tools. That is a practical reason to inspect the interaction trace during a trial: a fluent explanation of an intended action doesn't show that the action ran. Liquid's Hermes instructions identify the setting.
For llama.cpp deployments, the backend documentation exposes context length and GPU offloading as explicit controls. Record those settings with the quantization you chose. If you change them between trials, you'll have changed the deployment as well as the model. The published speed figure is most useful when you can compare it with a clearly described setup of your own.
Downloadable weights have commercial conditions
Liquid distributes the model under its LFM Open License v1.0, which includes a commercial revenue threshold of $10 million. Companies above that threshold need a separate commercial license to continue commercial use. The terms also require retaining license and attribution notices on redistribution. Download access alone doesn't settle the terms for shipping a product.
The license FAQ says fine-tuned versions can remain proprietary, without a requirement to release modifications. It also says derivatives remain subject to the license. That distinction matters if your plan involves adapting the model to internal tools: changing the weights doesn't remove the commercial condition.
The next evidence worth watching is task-level measurement with the downloadable weights: elapsed time to a valid action, followed by whether the requested work passes its checks. Liquid's template already establishes that reasoning belongs in that timing. For a developer deciding whether to switch a local agent, the useful result is a completed job with a measured wait.