LFM2.5-24B-A2B Local Deployment: 2B Active Parameters Still Need 14.5GB of Memory

Liquid AI's LFM2.5-24B-A2B is a Mixture-of-Experts model with 24B total parameters but only 2.45B activated per token. The official claim is 184 tokens/s decoding speed on an Apple M5 Max, but you still need to fit all 24B weights into memory—the Q4_K_M quantized file alone is 14.5 GB. This speed-versus-memory trade-off is worth calculating clearly before you download.

LFM2.5-24B-A2B local run guide source screenshot

What Exactly Is LFM2.5-24B-A2B

Liquid released this model on October 13, 2026, calling it the largest and final member of the LFM2.5 series. According to the model card, the core specs are:

24.0B total parameters, 2.45B activated parameters
40 layers: 30 dual-gated short convolution blocks + 10 GQA attention layers
64 experts per MoE block, top-4 routing
131,072 token context, 128K vocabulary
~33T pretraining tokens, followed by 2T tokens of 32K context mid-training and 300B tokens of 131K long-context training
Text-only model, and a reasoning model that always begins with a <think> block

The text-only nature has already sparked considerable discussion. Someone in the GGUF repo complained, "Great model, but without mmproj it's useless to me." The problem is there's no mmproj to release—this model has no vision tower. If you need image capabilities, the LFM2.5 VL series only goes up to LFM2.5-VL-3B.

Mixture-of-Experts (MoE) and activated parameters: MoE architecture splits the feed-forward layers into multiple parallel "experts," routing each token to only a few of them, thereby decoupling total parameters from per-token computation. LFM2.5-24B-A2B has 64 experts per MoE block with top-4 routing, meaning each token invokes only 4 experts, giving a theoretical activation ratio of about 1/16, which after accounting for shared layers and attention layers becomes an actual 2.45B activated. This explains its biggest cognitive trap: activated parameters determine compute and speed, total parameters determine memory. All weights must reside in memory to be ready for any token's routing hit, so 2B of activation doesn't make the 14.5 GB Q4_K_M file any smaller.

Dual-gated short convolution + GQA hybrid: Of the 40 layers, 30 are dual-gated short convolution blocks, and only 10 are grouped query attention (GQA). Short convolutions excel at capturing local sequence patterns with extremely low complexity, while the attention layers handle global information exchange. This sparse attention layout is exactly why KV cache growth is slow later on—the cache only serves 10 layers rather than all 40, making long-context memory overhead significantly lower than a pure Transformer of the same depth.

What Changed Compared to the Previous Generation LFM2-24B-A2B

If you've used the previous generation LFM2-24B-A2B (lfm2:24b in Ollama), the architecture hasn't actually changed: still 40 layers, 64 experts, top-4, convolution/GQA hybrid. The main upgrades are in training scale and reasoning capability:

Item	LFM2-24B-A2B	LFM2.5-24B-A2B
Context	32,768	131,072
Vocabulary	65K	128K
Pretraining tokens	17T	33T
Reasoning capability	None	Always on (chain-of-thought)
Post-training	Not compared	5 stages, ending with agentic RL

The other members of the LFM2.5 text series are all small: 230M, 350M, 1.2B (including Instruct, Thinking, JP versions), 2.6B, and the 128K context LFM2.5-8B-A1B MoE. This 24B is the only one attempting to enter the 30B-class MoE arena.

Benchmarks: What It Wins and What It Doesn't

Liquid benchmarks it against Qwen3.6-35B-A3B, Gemma-4-26B-A4B-it, and Nemotron-3.5-Lightning (30B-A3B). Key data excerpted from the model card:

Benchmark	LFM2.5-24B-A2B	Qwen3.6-35B-A3B	Gemma-4-26B-A4B	Nemotron-3.5 30B-A3B
AutomationBench	27.69	8.72	5.46	2.61
BFCLv4	65.01	65.00	57.09	53.78
ToolSandbox	80.71	75.02	72.09	75.13
IFBench	74.69	64.21	47.44	71.67
GPQA Diamond	74.42	83.69	74.90	72.42
AA-Omniscience	-24.90	-24.35	-59.39	-3.58
SWE-Bench Verified	51.00	66.20	25.80	53.40
SciCode	32.71	37.35	35.42	27.78

The conclusion is fairly clear: this is a tool-calling and instruction-following model. It wins all three instruction-following benchmarks (IFEval 96.75, IFBench, Multi-IF) and five of the seven agentic benchmarks, including LiveClaw 48.09 vs Qwen's 38.19. But it loses to Qwen on PinchBench and WebArena Verified. BFCLv4's 65.01 vs 65.00 is more of a tie than a victory.

The gaps in weaker areas are not small: Qwen3.6-35B-A3B leads by 15 points on SWE-Bench Verified and 9 points on GPQA Diamond. AA-Omniscience score of -24.90 (a benchmark that penalizes confident wrong answers) is roughly on par with Qwen but far behind Nemotron's -3.58. If you're expecting "2B speed wrapped around mid-tier knowledge," the lab's own table shows knowledge is precisely the weak point. Using it to follow schemas and call functions is the correct approach.

Note that these are all lab-released numbers with per-benchmark configurations (mostly temperature 0.6, vLLM, specific turn limits), and no independent reproduction has been seen yet.

Memory Requirements by Quantization Level

This is the community's biggest concern, and there's already a dedicated VRAM discussion thread in the GGUF repo. Here are the file sizes by quantization (from the GGUF repo); actual use requires additional headroom for KV cache, OS, and other programs:

Quantization	File Size	Realistic Target Device
Q4_0 (QAD)	13.6 GB	16 GB tight; 24 GB Mac or 16 GB GPU + system memory more comfortable
Q4_K_M	14.5 GB	Same as above
Q5_K_M	17 GB	24 GB devices
Q6_K	19.7 GB	24 GB tight, 32 GB suitable
Q8_0	25.5 GB	32 GB+
BF16 / F16	48 GB	64 GB Mac or workstation

The "Target Device" column is a rough judgment based on file size, not an official Liquid release. The official blog only claims it has the "smallest memory footprint" among comparable edge-hardware MoEs, without giving specific GB figures.

On the KV cache front there's one favorable point: only 10 of the 40 layers are attention layers, so the cache grows with context far more slowly than a pure Transformer of the same depth, making long-context costs lower than expected. But setting a 131K context on a 16 GB laptop is still unrealistic.

About the Q4_0 file: this is a quantization-aware distillation (QAD) checkpoint, which the repo says was trained "to recover the accuracy lost to Q4_0 quantization." The idea is good, but there's already a discussion thread requesting actual accuracy data, and Liquid hasn't published it yet. Until then, it's recommended to use Q4_K_M as the default choice and reserve the QAD file for A/B testing.

GGUF and quantization naming: GGUF is the model file format of the llama.cpp ecosystem, packaging weights, vocabulary, and metadata into a single file. Quantization represents each weight with fewer bits, thereby compressing size and reducing memory bandwidth pressure. Among common suffixes, Q4_0 and Q8_0 are earlier uniform quantization schemes, while K_M (such as Q4_K_M, Q5_K_M) uses mixed-precision block quantization, allocating more bits to sensitive weights for typically better accuracy at the same size. This is why Q4_K_M (14.5 GB) is slightly larger than Q4_0 (13.6 GB) yet more often recommended as the default choice.

Quantization-Aware Distillation (QAD): Ordinary quantization is post-training compression with irreversible accuracy loss; QAD lets the model "perceive" during training that it will be compressed to Q4_0, using distillation to adapt weights to this low-precision representation in an attempt to recover the loss. The cost is that it's customized for a specific quantization format, can't be freely converted to other quantization levels, and its actual accuracy gain needs evaluation data to support—which is why the community is pressing Liquid to publish QAD comparison numbers.

KV cache: During autoregressive generation, the Key/Value tensors of already-generated tokens are cached and reused to avoid redundant computation. Cache size is proportional to the number of layers, context length, and number of KV heads, so at long contexts it can be on the same order as the weight file—a second memory cost that can't be ignored when evaluating "can it run 131K context."

How to Run with llama.cpp, Ollama, or LM Studio

The following commands come from the GGUF README and standard Hugging Face snippets.

llama.cpp OpenAI-compatible server:

llama-server -hf LiquidAI/LFM2.5-24B-A2B-GGUF:Q4_K_M

llama.cpp terminal inference:

llama-cli -hf LiquidAI/LFM2.5-24B-A2B-GGUF \
    --temp 0.1 --top-k 50 --repeat-penalty 1.05

Append :Q4_K_M (or another quantization tag) after the repo name to specify the file.

Ollama:

ollama run hf.co/LiquidAI/LFM2.5-24B-A2B-GGUF:Q4_K_M

LM Studio: Open lmstudio://open_from_hf?model=LiquidAI/LFM2.5-24B-A2B-GGUF or search for the repo name in the model browser.

For full weights on a GPU machine: vllm serve "LiquidAI/LFM2.5-24B-A2B", with the endpoint at http://localhost:8000/v1/chat/completions. Transformers requires transformers>=5.0.0.

Before blaming the model, check two settings:

Sampling parameters. The model card recommends temperature 0.1, top_k 50, repetition_penalty 1.05. GGUF stores these as general.sampling.* metadata, and llama.cpp applies them automatically. But many frontends override the defaults with their own sampling parameters. If output looks chaotic, check here first.
Update your runtime. The architecture (lfm2moe) has been supported since LFM2-24B-A2B, but the vocabulary doubled to 128K. Old versions predating this release may not handle it correctly. No reports of this yet, but updating llama.cpp or Ollama takes only two minutes.

For agent frameworks (Hermes, OpenClaw^Ad, Pi), the example configurations in the model card point to the local endpoint http://localhost:8080/v1, with Hermes and OpenClaw configs setting context length to 131,072.

The Details Behind 184 tokens/s

The model card states the edge speed data was measured with llama.cpp, Q4_K_M, and a 4K token input context. It's 184 tokens/s on M5 Max and 114 tokens/s on AMD Ryzen AI Max+ 395. Both are high-end devices with large unified memory bandwidth. A 16 GB laptop spilling weights to slow memory is a different story.

The bigger issue is that this is a pure reasoning model. Every response begins with a chain of thought. A 2B-activated MoE writing 600 thinking tokens before answering "yes" can feel slower end-to-end than an 8B dense model that answers directly. Liquid lists the DSpark draft model as "coming soon" for speculative decoding, and the community is already asking about it in the discussion forum.

Unified memory and memory bandwidth: Apple M5 Max and AMD Ryzen AI Max+ 395 both use unified memory architecture, where CPU and GPU share the same high-bandwidth memory pool, allowing model weights to be read directly by the accelerator without copying between devices. Large model inference at batch size 1 is typically memory bandwidth-bound rather than compute-bound—each generated token requires reading the activated weights from memory once. So the advantage of such devices isn't floating-point compute but the high bandwidth from a 256-bit or wider memory bus. Once a 16 GB laptop's weights spill to SSD or slow memory, bandwidth plummets and decode speed drops from triple digits to single digits.

Speculative decoding: A tiny "draft" model quickly guesses several tokens, which the main model then verifies in parallel all at once, accepting the correct ones directly to amortize the main model's forward passes. It doesn't change the output distribution, only accelerating when the draft hit rate is high. The DSpark draft model Liquid lists serves exactly this purpose, especially attractive for the "pure reasoning model writing hundreds of thinking tokens first" scenario.

The cost of a pure reasoning model: Always outputting a <think> block means every response pays a fixed-length thinking token cost upfront. End-to-end latency = (chain-of-thought length + answer length) / decode speed, so 184 tokens/s peak throughput doesn't equal equivalent subjective response speed.

LFM Open License and the $10M Revenue Threshold

The model uses the LFM Open License v1.0. Commercial use is limited to entities with annual revenue below the "threshold" (i.e., $10 million). "Legal entity" includes affiliates that control you, are controlled by you, or are under common control with you—a big company's small subsidiary can't count only its own revenue. Above the threshold, commercial use is simply outside the license scope, requiring separate negotiation with Liquid.

For independent developers and most startups this isn't a problem. But for practitioners at mid-sized companies, it means it's not Apache 2.0, and it can't be treated like Qwen when legal asks.

Should You Replace Your 8B Model with It

If your daily driver is an 8B dense model for tool calling, JSON extraction, or agent loops, LFM2.5-24B-A2B is worth a weekend try. Instruction following and tool use data are the strongest parts of the model card, with fewer than a third of the activated parameters you're currently running. But if you mainly use it for coding or knowledge questions, Liquid's own table suggests Qwen3.6-35B-A3B is the better choice, and the 8B won't embarrass itself too much.

Two questions worth pondering: can a 2B-activated MoE requiring 14.5 GB of memory really replace your 8B dense daily driver? Or is the memory cost simply an insurmountable barrier? If you've already loaded the GGUF, what hardware, what quantization, and how many tokens/s did you get? That 184 needs someone to verify it.

References

One-line Summary

LFM2.5-24B-A2B trades 2.45B activation for speed, but 24B weights still need 14.5 GB of memory—strong at tool calling, weak at knowledge and coding.

Paragraph Summary

Liquid AI's LFM2.5-24B-A2B is a Mixture-of-Experts reasoning model with 24B total parameters and only 2.45B activated per token. It's officially claimed to hit 184 tokens/s on Apple M5 Max, yet the Q4_K_M quantized file still occupies 14.5 GB—2B activation saves compute, not memory. Compared to the previous generation, context expanded from 32K to 128K, vocabulary doubled, pretraining reached 33T tokens, and an always-on chain of thought was added. Benchmarks show it leads Qwen3.6-35B-A3B and other rivals in instruction following and agentic tool calling, but trails by 15 points on SWE-Bench Verified and 9 points on GPQA Diamond—knowledge is a clear weakness. It runs with one command on llama.cpp, Ollama, LM Studio, and vLLM, with 24 GB+ memory recommended; it uses the LFM Open License with a $10M annual revenue threshold, not Apache 2.0.