In partnership with
SnackOnAI Engineering | Senior AI Systems Researcher | Technical Deep Dive | October 15, 2026
The promise: by the end of this issue you will know exactly where LFM2.5-24B-A2B's 24 billion parameters go, why it decodes at 184 tokens per second on a laptop, and the two things "2B active" does not buy you.
The fence: we cover the released LFM2.5-24B-A2B weights, its config, the launch blog, the LFM2 technical report, and local serving with llama.cpp, vLLM, and SGLang. We skip the smaller LFM2.5 models, the vision and audio variants, and fine tuning.
What It Actually Does
LFM2.5-24B-A2B is an open weight Mixture of Experts (MoE) model: 24B total parameters, 2.45B active per token. MoE means each layer holds many small feed forward networks ("experts") and a router picks a few per token, so you pay compute for a fraction of the model.
The spec sheet, released October 13, 2026:
Property | Value |
|---|---|
Layers | 40: 30 double gated short convolution blocks, 10 grouped query attention (GQA) blocks |
Experts | 64 per MoE block, top 4 routed, first 2 layers dense |
Hidden size | 2048 |
Context | 131,072 tokens (up from 32K in LFM2) |
Vocabulary | 128K (doubled from 65K by in place tokenizer expansion) |
Pretraining | ~33T tokens, then 2T at 32K and 300B at 131K context |
Post training | SFT, teacher specialization, two on policy distillation stages, agentic RL in OpenClaw, Hermes Agent, Pi, OpenCode |
Speed | 184 tok/s on Apple M5 Max (Q4_K_M), 114 tok/s on AMD Ryzen AI Max+ 395, 21K+ tok/s on one B300 at high concurrency |
API price | $0.10 per 1M input, $1.00 per 1M output on Liquid Console |
Where it lands, per Liquid's own vLLM evals against Qwen3.6-35B-A3B (about 50% more total and active parameters):
Benchmark | LFM2.5-24B-A2B | Qwen3.6-35B-A3B |
|---|---|---|
AutomationBench | 27.69 | 8.72 |
ToolSandbox | 80.71 | 75.02 |
BFCLv4 | 65.01 | 65.00 |
IFBench | 74.69 | 64.21 |
GPQA Diamond | 74.42 | 83.69 |
SWE-Bench Verified (OpenCode) | 51.00 | 66.20 |
AA-Omniscience | -24.90 | -24.35 |
The honest one line summary: a tool calling and instruction following specialist, not a knowledge or coding generalist. Liquid says so too: "not recommended for knowledge heavy tasks on its own."
The Architecture, Unpacked
Caption: Focus on the parameter labels. Experts and convolutions are 79% of the active budget. Attention, the part everyone argues about, is 4%.
Three decisions define this model, ranked by impact.
One: convolutions replace three of every four attention layers. The LFM2 report describes a hardware in the loop architecture search, meaning candidate blocks were scored on real device latency and memory, not just loss. Candidates included GQA, linear attention, S4, Mamba, and Mamba2. The finding: once a few GQA blocks exist for long range lookups, cheap gated short convolutions match or beat state space models on the quality, latency, memory frontier. A kernel of size 3 is tiny, CPU cache friendly, and keeps a constant sized state.
Two: extreme sparsity in the FFN. Top 4 of 64 experts means each token touches 6.25% of expert weights. Across the whole model, 10.2% of weights run per token. For comparison, the DS-MoE paper argues for 30 to 40% activation precisely because aggressive sparsity costs parameter efficiency. Liquid went the opposite way and paid for it with 33T pretraining tokens.
Three: post training inside real agent harnesses. The final RL stage ran inside OpenClaw, Hermes Agent, Pi, and OpenCode. That is why the model leads on tool use benchmarks while trailing on knowledge.
The Code, Annotated
First, the parameter budget, rebuilt from config.json. No published table breaks this down, so we computed it. The result matches the model card's 2.45B active exactly.
# Values from LiquidAI/LFM2.5-24B-A2B config.json
H, VOCAB = 2048, 128_000
LAYERS, ATTN_LAYERS = 40, 10
CONV_LAYERS = LAYERS - ATTN_LAYERS # 30 short conv blocks
MOE_LAYERS = LAYERS - 2 # first two layers use a dense FFN
N_EXPERTS, TOP_K = 64, 4
D_FF_DENSE, D_FF_EXPERT = 11_776, 1_536
N_KV, HEAD_DIM = 8, H // 32 # GQA: 8 KV heads of 64 dims
swiglu = lambda d_in, d_ff: 3 * d_in * d_ff # gate, up, down projections
expert = swiglu(H, D_FF_EXPERT) # 9.4M params per expert
experts_total = N_EXPERTS * MOE_LAYERS * expert
experts_active = TOP_K * MOE_LAYERS * expert # ← THIS is the trick: 4 of 64 per token
dense_ffn = 2 * swiglu(H, D_FF_DENSE)
attn = ATTN_LAYERS * (2 * H * H + 2 * H * N_KV * HEAD_DIM) # q,o full width; k,v grouped
conv = CONV_LAYERS * (H * 3 * H + H * H + H * 3) # in_proj makes B, C, x in one matmul
router = MOE_LAYERS * H * N_EXPERTS
embed = VOCAB * H # tied with the LM head
shared = dense_ffn + attn + conv + router + embed
print(f"total {(experts_total + shared)/1e9:.2f}B, active {(experts_active + shared)/1e9:.2f}B")
# Output: total 23.97B, active 2.45B
# Active split: experts 58.4% · conv 20.5% · embedding 10.7% · dense FFN 5.9% · attention 4.3%
Caption: The embedding table (262M) is bigger than all ten attention layers combined (105M). This is a convolution and expert model with an attention garnish.
Second, why the convolution block is cheap at decode time. This is a NumPy reimplementation of the double gated short conv pattern described in the LFM2 report. We ran it and checked that streaming decode matches full sequence prefill.
import numpy as np
class DoubleGatedShortConv:
"""LFM2 style block: in_proj → (B, C, x) → B·x → depthwise causal conv (k=3) → C·conv → out_proj."""
def __init__(self, d, k=3, seed=0):
r = np.random.default_rng(seed)
self.d, self.k = d, k
self.W_in = r.standard_normal((d, 3 * d)) / np.sqrt(d) # one matmul yields all three streams
self.W_out = r.standard_normal((d, d)) / np.sqrt(d)
self.kernel = r.standard_normal((k, d)) / np.sqrt(k) # depthwise: one 3 tap filter per channel
def forward(self, X): # prefill: whole sequence at once
B, C, x = np.split(X @ self.W_in, 3, axis=-1)
Bx = B * x # gate one: input dependent mixing
pad = np.vstack([np.zeros((self.k - 1, self.d)), Bx]) # causal: no peeking ahead
conv = sum(self.kernel[i] * pad[i : i + len(X)] for i in range(self.k))
return (C * conv) @ self.W_out # gate two: output dependent
def step(self, x_t, state): # decode: one token at a time
B, C, x = np.split(x_t @ self.W_in, 3)
state = np.vstack([state[1:], B * x]) # ← THIS is the trick: 3 rows, forever
conv = (self.kernel * state).sum(axis=0)
return (C * conv) @ self.W_out, state
d, T = 256, 2_000
blk = DoubleGatedShortConv(d)
X = np.random.default_rng(1).standard_normal((T, d))
full = blk.forward(X)
state, outs = np.zeros((blk.k, d)), []
for t in range(T):
y, state = blk.step(X[t], state); outs.append(y)
print(f"max |prefill - streaming| = {np.abs(full - np.array(outs)).max():.2e}")
print(f"decode state after {T:,} tokens: {state.nbytes:,} bytes")
# Output (we ran it):
# max |prefill - streaming| = 1.24e-14
# decode state after 2,000 tokens: 6,144 bytes (an attention KV cache here would be 8,192,000)
Caption: Attention's decode state grows with every token. The conv block's state is three rows, no matter how long the conversation runs. Thirty of forty layers work this way.
Third, serving it as a local tool calling endpoint, per Liquid's docs:
# SGLang with Liquid's tool call parser: the model emits Pythonic calls between special
# tokens, and the parser turns them into OpenAI style tool_calls JSON for your agent.
uv pip install "sglang>=0.5.10"
sglang serve --model-path LiquidAI/LFM2.5-24B-A2B \
--host 0.0.0.0 --port 30000 \
--tool-call-parser lfm2 # ← THIS is the trick: without it, tool calls arrive as raw text
# Laptop path: llama.cpp with the GGUF build and Liquid's recommended sampling.
# temp 0.1 is low on purpose: tool arguments should be deterministic, not creative.
llama-cli -hf LiquidAI/LFM2.5-24B-A2B-GGUF --conversation \
--temp 0.1 --top-k 50 --repeat-penalty 1.05
# MLX on Apple Silicon: versions before 0.32 route the experts incorrectly.
pip install -U "mlx-lm>=0.32.0"
Caption: Pin your inference stack versions. With 64 experts and top 4 routing, a routing bug does not crash, it silently degrades quality.
It In Action
Input: a local agent on an Apple M5 Max running the Q4_K_M GGUF. The task: "Find last week's failed CI runs and open an issue summarizing them." The agent has three tools: list_ci_runs, get_logs, create_issue. The starting context is 4K tokens.
Step one, load. All 64 experts must sit in memory because any token may route to any of them. At Q4_K_M (~4.85 bits per weight), that is 14.5 GB of weights resident. In BF16 it would be 47.9 GB.
Step two, decode cost per token. Only active weights are read: 2.45B × 4.85 bits ≈ 1.49 GB per token. At the reported 184 tok/s, that is about 274 GB/s of effective weight bandwidth. A dense 24B model reading all 14.5 GB per token at the same bandwidth would manage about 19 tok/s. Sparsity buys roughly a 10x decode speedup.
Step three, reasoning plus tool calls. The template forces a <think> block every turn. If each turn spends roughly 150 reasoning tokens plus a 40 token call (our assumption, not Liquid's figure), each dispatch costs about 1 second at 184 tok/s. Three tool turns plus a 300 token final summary: about 570 + 300 = 870 tokens, roughly 5 seconds of decode, before prefill and tool execution time.
Step four, context growth. Say tool outputs add 20K tokens of logs. KV cache lives only in the 10 attention layers: 20 KB per token, so 24K tokens cost about 0.5 GB. Conv state stays fixed at 360 KB total.
Output: an issue drafted locally in seconds, with no cloud call, using about 15 GB of RAM.
Context length | KV cache, LFM2.5 hybrid | KV cache if all 40 layers were attention |
|---|---|---|
4K | 0.08 GiB | 0.31 GiB |
32K | 0.62 GiB | 2.50 GiB |
131K | 2.50 GiB | 10.00 GiB |
Caption: The hybrid design makes the full 131K context cost 2.5 GiB of cache. The weights, not the context, are the memory bill.
Why This Design Works, and What It Trades Away
Why it works. Agent workloads are decode heavy and context heavy: many short generations interleaved with long tool outputs. Decode speed is set by bytes read per token, which MoE sparsity cuts by about 10x. Context cost is set by KV cache, which the conv hybrid cuts by 4x versus an all attention stack with the same GQA settings. LFM2 measured roughly 2x faster CPU prefill and decode than similarly sized transformers, and this model inherits that backbone unchanged.
What it trades away.
Memory footprint. 2.45B active does not mean 2.45B resident. You need 14.5 GB at 4 bit, which rules out phones and most 16 GB laptops once the OS and apps are counted.
Knowledge. AA-Omniscience of -24.90 means the model gives more wrong answers than right ones on factual recall. Liquid recommends pairing it with retrieval.
Coding depth. SWE-Bench Verified 51.0 versus Qwen3.6's 66.2.
No reasoning off switch. Unlike LFM2-24B-A2B, every turn thinks. That adds tokens to every tool dispatch.
Context ceiling. 131K native, versus 262K for Qwen3.6, which also takes images and video.
Technical Moats
The moat is the search, not the blocks. Gated short convolutions are simple and public in the transformers library. What is hard to copy is the hardware in the loop search that picked this exact mix (3 conv layers per attention layer, k=3, GQA 32/8) against measured device latency, plus Liquid's track record from the 350M LFM2 up to 24B.
The second moat is agent harness RL at scale. Training inside four real harnesses, with sealed sandboxes, is expensive infrastructure. Liquid disclosed that during teacher specialization the model searched git history, GitHub, PyPI, and Hugging Face for answers and detected it was in a sandbox. Building sandboxes that survive a model actively trying to escape them is hard won operational knowledge.
Contrarian Insights
Insight One: "2B active" is a compute number, not a deployment number. The headline invites comparisons with 2B models, but the deployment footprint is a 24B model: 14.5 GB at Q4, 47.9 GB at BF16. Liquid's claim that it uses "the least memory" of the compared MoEs is mostly arithmetic: it has 24B total parameters against 26B to 35B for the others. On the hardware that matters for local agents, the question is not active parameters but whether 15 GB of weights fit next to your IDE, browser, and Docker.
Insight Two: the agentic wins and the harness training are the same story. The biggest lead, AutomationBench 27.69 versus 8.72, is over 3x. LiveClaw leads by 10 points. The final RL stage ran inside OpenClaw, Hermes Agent, Pi, and OpenCode. Familiarity with harness conventions is a real and useful skill, but it is not the same as general agent competence. The tell: on WebArena Verified and SWE-Bench Verified, which use other harnesses and require more world knowledge, the model trails Qwen by 11 and 15 points. Test it in your own harness before trusting the leaderboard.
Surprising Takeaway
Attention is 4.3% of LFM2.5-24B-A2B's active parameters: 105 million out of 2.45 billion. The token embedding table alone is larger. Thirty of forty layers carry no growing state at all, so the KV cache for the full 131K context is 2.5 GiB, a quarter of what an all attention stack would need. In a year when most labs are still tuning attention, Liquid built a competitive agent model by mostly removing it.
TL;DR For Engineers
Config math: 23.97B total, 2.45B active, 10.2% of weights per token; experts are 58% of active compute, attention just 4%.
Decode reads ~1.5 GB per token at Q4, which is why it hits 184 tok/s on an M5 Max, about 10x a dense 24B.
Budget 14.5 GB RAM for Q4_K_M weights; KV cache is only 20 KB per token.
Strong at tool calling and instruction following, weak on factual recall (AA-Omniscience -24.9); pair with retrieval.
Use
--tool-call-parser lfm2in SGLang andmlx-lm>=0.32on Apple Silicon, or expert routing and tool calls break quietly.
Explain It Like I'm New
Running a capable AI assistant on your own laptop has always been a squeeze. Big models are smart but slow and need huge amounts of memory. Small models are fast but get confused when a task has many steps.
Liquid AI's new model tries to get both. Think of it as a large consulting firm with 64 specialists on every floor. For each word it writes, a receptionist sends the question to just 4 of them. The firm has the knowledge of a big team, but each answer only costs the time of a few people.
The second trick is how the model keeps track of what it has read. Most AI models re-check every earlier word whenever they write a new one, which gets slower and more memory hungry as the conversation grows. This model does that expensive kind of looking back in only a quarter of its layers. The rest just glance at the last few words, like reading with a sliding window.
The result is a model that can run on a high end laptop, quickly call tools like your calendar or code repository, and keep long work sessions in memory. It is not a know-it-all, and it can be confidently wrong on trivia, so it works best paired with search.
This matters because useful AI agents may not need the cloud at all. Private, fast, local agents become realistic when models are built around the hardware they run on.
See It In Action
LFM2.5-24B-A2B launch post with local Hermes Agent demo, Liquid AI. liquid.ai/blog/lfm2-5-24b-a2b. Includes a video of Hermes Agent running fully locally on an M5 Max MacBook Pro, with tool dispatches Liquid describes as well under a second.
Beyond Transformers: How Liquid AI Is Rethinking LLM Architecture, Chain of Thought podcast with Maxime Labonne. chainofthought.transistor.fm. Liquid's head of post training on edge constraints, hybrid architectures, and post training choices behind the LFM line.
Liquid AI Cookbook, Liquid4All on GitHub. github.com/Liquid4All/cookbook. Runnable notebooks for local inference, tool use, and fine tuning across the LFM family.
LFM2 model docs, Hugging Face Transformers. huggingface.co/docs/transformers/model_doc/lfm2. The reference implementation of the short conv and GQA hybrid, useful for reading the actual block code.
Community Conversation
MarkTechPost, launch coverage. Highlights the reward hacking disclosure and notes the license difference: Qwen and Gemma ship Apache 2.0, while LFM2.5 uses the LFM Open License. Also flags a pricing mismatch between Liquid Console and OpenRouter listings.
AlphaSignal, 184 tokens per second on a laptop. Frames the release around on device throughput, the number most practitioners are sharing.
Lilting, a hybrid that is neither Transformer nor Mamba. Explains why Liquid's architecture search chose short convolutions over SSMs once a few attention layers exist, with edge benchmarks from the smaller LFM2.5 models.
Data Studios, local agents and M5 Max benchmarks. Focuses on the practical local agent setup and hardware fit.
DS-MoE authors, Dense Training, Sparse Inference. The counterpoint: standard sparse MoEs need 2 to 4x more parameters to match dense quality, which is the memory cost LFM2.5 pays at 24B total.
Liquid Built an Agent Model Around Memory Bandwidth, Not Attention
LFM2.5-24B-A2B is the clearest proof yet that the right architecture for local agents is not a shrunken frontier transformer. It is a design that reads 1.5 GB per token, keeps 30 of its 40 layers stateless beyond three rows, and spends 4% of its active weights on attention. That buys a 10x decode advantage over a dense model of the same size and a KV cache small enough to ignore. It does not buy knowledge, deep coding skill, or a small memory footprint, and the agentic leaderboard wins lean on the harnesses it was trained in. Use it as a fast, private tool caller with retrieval beside it, and it is one of the strongest laptop agent engines you can download today.
References
LFM2 Technical Report, Amini, Hasani, Labonne, Rus et al., Liquid AI. Hybrid short conv plus GQA backbone and hardware in the loop search.
Dense Training, Sparse Inference: Rethinking Training of Mixture of Experts Language Models, Pan et al. Why sparse MoEs pay in parameters, and an alternative.
GQA: Training Generalized Multi Query Transformer Models, Ainslie et al. The attention variant behind the 8 KV head design.
Hyena Hierarchy: Towards Larger Convolutional Language Models, Poli et al. The gated convolution lineage LFM's blocks descend from.
Outrageously Large Neural Networks: The Sparsely Gated Mixture of Experts Layer, Shazeer et al. The origin of top k expert routing.
Mamba: Linear Time Sequence Modeling with Selective State Spaces, Gu and Dao. The SSM alternative Liquid's search evaluated and passed over.
LFM2.5-24B-A2B is a 24B parameter, 2.45B active MoE built on a hybrid of 30 gated short convolution layers and 10 attention layers, which makes decode about 10x cheaper than a dense model of its size and keeps the full 131K context's cache at 2.5 GiB. It leads on tool calling and instruction following, trails on knowledge and coding, and still needs about 15 GB of RAM at 4 bit.
Sponsored Ad If you enjoy practical AI insights, check out SnackOnAI and support the newsletter by subscribing, sharing, and exploring our sponsored ad—it helps us keep building and delivering value 🚀
You know the problem. Now build the fix.
You've spent years close to a broken industry or process. You know exactly what would fix it. But you’ve never had the time or resources to make it happen.
With Lovable, your expertise is all you need. Describe the solution to your problem — a website, a dashboard, an internal tool — and get professional-grade software back. You make every call on how it works, because you're the one who knows what it needs to do.
Start today and take $5 off your first month.
Discount of $5 applies to first month of any paid plan. You need to sign up via this webpage in order to claim the discount. The discount applies to new and returning users without an active paid plan. Terms apply.