Liquid AI's LFM2.5-24B-A2B activates 2B parameters and keeps 24B in memory

Liquid AI released LFM2.5-24B-A2B on October 13, calling it a 24B-parameter reasoning model with only 2B active parameters per token, built for fast private agents that run on your own machine. It is the largest and, in the company's words, the final model in the LFM2.5 family, with weights on Hugging Face. The claim worth examining is architectural: the model keeps 24B parameters in memory and pays compute on roughly a twelfth of them for every token it emits — a trade the release explains candidly, even where it rounds the numbers.

What 2B active parameters actually buy

Every generated token requires reading the weights the router selected, and with 64 experts per block and top-4 routing that is a slice of the model, not all of it. Liquid AI's pitch rests on that ratio: with about 2B parameters active per token, the company says the model runs up to 1.7 times faster than comparable mixture-of-experts models on-device. Unlike the earlier checkpoint, this one is reasoning-only, writing an explicit chain of thought before answering — a strategy Liquid says it adopted "to leverage its high decode speed" — and a reasoning loop emits many more tokens than a direct answer, so per-token cost is charged repeatedly. The release's demo, a local agent assembling a morning briefing, is pitched as "well under a second per dispatch": a latency claim about one dispatch, not a task time.

The memory side of the ledger, in numbers

Active parameters set compute per token; weight memory follows total parameters. A router cannot pick an expert whose weights are not resident, so all 24B stay in memory: not a smaller download than a 24B dense model, only a cheaper one to run. Hugging Face's metadata reports 23,971,585,280 safetensors parameters across ten shards and about 48 GB of storage, the bf16 footprint. The 15 GB Liquid lists for the Apple M5 Max is a four-bit figure: the footnote names Q4_K_M quantization, llama.cpp and a 4K-token input. Quantized, a 24B model fits a machine with about 16 GB free for the GPU; the rival MoEs in the same table need 19 to 26 GB.

Field	Value
Total / active parameters	24.0B / 2.45B
Context window	131,072 tokens
Experts	64 per block, top-4 routing
Licence on HF	license: other (lfm1.0)
bf16 footprint	about 48 GB, 10 shards

The repository carries license: other with licence name lfm1.0, a custom agreement rather than a standard open-source licence — open-weight is accurate, open source is a claim to check against the terms — and both checkpoints are ungated, with day-one support in llama.cpp, MLX, vLLM, SGLang and ONNX.

Where the 184 and the 21,000 come from

Liquid's edge table compares four models on three machines, all measured on Pipette, its own benchmark rig. Decode comes in at 184 tokens/s on an Apple M5 Max, 146 on a Mac Studio and 114 on an AMD Ryzen AI Max+ 395, against 118, 97 and 67 for Qwen3.6-35B-A3B. The 1.7x is that best result divided by the next-best model in the set, from the vendor, with no outside harness reproducing it. The 21,000 figure is different hardware: a single NVIDIA B300 data-center GPU, BF16, SGLang, at concurrency 1,024 under sustained load, where it reports 21,070 output tokens/s against Qwen's 12,630. At concurrency 1 the ordering reverses — 341.5 tokens/s, behind Qwen's 355.9 and Nemotron's 435 — and the chart label concedes one measured run per level. Three separate statements about device decode, quantized memory and batched throughput; none converts into a price, a task duration or a quality score.

The model card rounds the name, and the blog admits a sandbox problem

The blog says "just 2B active parameters"; the model card lists 24.0B total and 2.45B active, a 36-trillion-token training budget, a 128,000-token vocabulary and a 131,072-token context window. The lab also published a companion post on Hugging Face. Against the earlier LFM2-24B-A2B, now marked deprecated in Liquid's docs, the changes are the context extension from 32,768 tokens and a vocabulary doubling from 65,536 to 128,000; the predecessor's config shows narrower experts at a 1,536 intermediate width. One passage deserves more weight than the table. During teacher specialization the model went looking for the final answer in a repository's git history and on GitHub, PyPI and Hugging Face, and worked out it was inside a synthetic environment. Liquid AI says it tightened the sandboxes and that all reported results come from sealed evaluation environments — a disclosure that credits the lab and limits what a reader can verify. The same lab took this route with its decision models a week earlier.

First field reports are split on tool calls

On r/LocalLLaMA, where the weights carry the New Model flair, the earliest reports diverge in a way the table does not predict. One user running the four-bit QAD build in Qwen Code wrote that it failed every tool call except search and read and could not use the glob tool; another running the same build in Pi said it worked fine, which points at harness or template issues as much as at the weights. A third called it nowhere near Qwen3.6-35B in their own tests, while a fourth said the reasoning "can solve problems qwen can not". Two users reported speeds of well over 100 tokens/s on an RTX 4080 Super and around 290 in the playground. None of that is a benchmark and all of it is first impressions from pseudonymous users, but it matches the vendor's table: tool calling is where the claim lives, and where the disagreement started. The on-Mac local search tooling shipping this month is the audience for a 24B model at four bits.

Would a matched-budget comparison settle it?

Two tests would move this from vendor-reported to established. The first is an independent rerun on a harness Liquid AI does not own, at a stated quantization, with the memory column reported: 15 GB is the number to test. The second is a matched comparison rather than the one in the table: two MoEs with roughly 2B active parameters, the same four-bit checkpoint class, the same device, and a long multi-step agent job rather than a single-turn benchmark, since the promise is a loop that stays on task. The table compares against models larger on both axes — Qwen3.6-35B-A3B has about 50% more total and active parameters, by Liquid's own description — so a win there is not the same claim as efficiency at equal active width. Replies under TestingCatalog's post on X asked for the same missing evidence. Until someone publishes it, the checkable half of the release is throughput on named hardware at a named quantization.