Liquid AI built LFM2.5-24B-A2B for agents on your own hardware. It has 24.0B parameters in total, the learned numbers that make up the model. Only 2.45B of them work on each token, the word piece a model reads and writes. Liquid ships an official FP8 checkpoint, a copy that stores most weights in 8-bit numbers, of 24.8 GB. The context, meaning the longest input plus output it accepts, is 131,072 tokens. On paper that fits one 48 GB card with room to spare. Three settings and one assumption decide whether the paper holds.
A plain limit first: our planned test on a rented 48 GB GPU never ran, so we have no numbers of our own. Benchmarks and throughput below are Liquid's, and memory figures are arithmetic on the config file. Our notes on LFM2.5-24B-A2B, its memory math and its license keep measured and computed apart.
The license comes before the GPU
The LFM Open License v1.0 sets a ceiling of 10 million US dollars of annual revenue for free commercial use. Parents, subsidiaries and sister companies under the same control all add to the count. A small team inside a large group is measured by the group, and indirect advantage counts, so even internal tooling can qualify. Settle that with your lawyer before you write serving config.
Why long contexts stay cheap
Mixture of experts (MoE) explains the A2B in the name. Each MoE block holds 64 experts, smaller sub-networks, and a router sends each token to 4 of them while the rest stay idle. Idle experts still occupy VRAM, the GPU's own memory, which is why the file weighs 24.8 GB even though about a tenth of the model works on each token.
While generating, a model stores keys and values for every past token so it never recomputes them. That store, the KV cache, grows with the conversation. Here only 10 of the 40 layers are attention layers that need one. The remaining 30 are short convolution blocks with a small state that does not grow. The article computes about 2.7 GB of cache for one conversation at the full 131,072 tokens. With every layer attending, you would pay four times as much. That assumes a head size of 64 (2048 divided by 32 heads), since the config omits it.
That leaves about 23 GB free after the weights. What vLLM, the serving engine, reserves for itself, plus CUDA context and activations, was never estimated, so "several long conversations at once" is a hypothesis to check.
Three settings that will bite you
The chat template opens every assistant turn with <think>, so the model always reasons first, and it writes tool calls as Pythonic lists between its own special tokens. vLLM runs it natively from 0.23.0, but needs telling how to split that output:
vllm serve LiquidAI/LFM2.5-24B-A2B-FP8 \
--reasoning-parser qwen3 \
--enable-auto-tool-choice --tool-call-parser lfm2
- Version. Anything older than vLLM 0.23.0 does not know LFM2.5. Our platform defaults to 0.20.0, so the plan pinned a newer release for this workload.
- Parsers. The reasoning parser is what separates the thinking from the final reply. The tool parser is what turns those Pythonic lists into tool calls your agent loop can act on.
-
max_tokens. Liquid advises leaving it unset unless you want a hard ceiling. Reasoning spends the same budget, so a tight limit can stop the model mid-thought.
Sampling needs no work: temperature 0.1, top_k 50 and repetition_penalty 1.05 ship in generation_config.json, which vLLM applies by default. Overrides for top_k, min_p and repetition_penalty go in extra_body.
The 2B saving is per token, not per server
Producing each new token, a step called decode, mostly means reading weights from GPU memory. A single user reads 4 experts per block per step, and the saving is real. A server batches many requests into each step, and each token in the batch may want a different set of 4. Read enough distinct experts and the step costs what a dense 24B model would, one where every parameter works on every token. That is reasoning, not measurement. It is also why Liquid's over 21,000 output tokens per second on one NVIDIA B300 under heavy concurrency is a total across requests, not one user's speed.
For a single user, Liquid reports an Apple M5 Max writing 184 tokens per second and an AMD Ryzen AI Max+ 395 writing 114, both in llama.cpp with a 4-bit GGUF file. Those rates include hidden reasoning that precedes the first visible word.
What I would measure first
On Liquid's benchmarks the model leads on agent workflows, tool use and instruction following. It ties Qwen3.6-35B-A3B on BFCLv4, 65.01 to 65.00, and trails it on SWE-Bench Verified, 51.00 to 66.20. Every rival is another MoE model, and no dense baseline is published.
The planned LFM2.5-24B-A2B benchmark on a 48 GB card is a script, bench.py. It covers streamed reasoning, code and Spanish prompts, a full tool-call round trip, checks that a fact buried at 8K, 32K and 100K tokens is found, and 4 and 8 parallel requests. The parallel runs decide whether the model behaves like 2B or like 24B. I would watch time to the first visible token as closely as tokens per second.
For a MoE model we did run, the Flint research post shows a coding agent measured on one RTX 4090 and one RTX 5090.
Credit
Liquid AI built the model on a 36T token training budget and refined it with reinforcement learning inside OpenClaw, Hermes Agent, Pi and OpenCode. It shipped with day-one support in llama.cpp, MLX, vLLM, SGLang and ONNX. The vLLM project maintains the recipe with the parser flags. AI Search's news roundup put the release in front of us. Our part was checking the files, doing the memory arithmetic and writing the test plan.
Checkpoint hashes, the full config.json architecture, quantization details, planned GPUs and the whole benchmark table are in the LFM2.5-24B-A2B article on inferencekey.com.
Top comments (0)