[KongchangAI]
· 2 min read· 1,059 words

LFM2.5-24B-A2B vs Qwen3.6: Local Agent or Coding Powerhouse?

LFM2.5-24B-A2B vs Qwen3.6: Local Agent or Coding Powerhouse?

LFM2.5 vs Qwen3.6: one wins on speed, the other on code.

This article compares Liquid AI's LFM2.5-24B-A2B and Qwen3.6-35B-A3B, two open-source MoE models. LFM2.5 achieves 184 tokens/s on M5 Max with 24B total/2B active parameters, leading on tool-calling benchmarks and ideal for multi-turn local Agents. Qwen3.6, with 35B total parameters, strikes back on SWE-Bench Verified with stronger code understanding. There's no absolute winner—choice depends on your workflow. The pragmatic approach: deploy both.

Liquid AI released LFM2.5-24B-A2B on October 13, a 24B-parameter MoE model with only 2B active parameters that hits 184 tokens/s inference speed on an M5 Max. The choice between it and Qwen3.6-35B-A3B essentially comes down to one question: do you need a fast-responding local Agent, or a coding assistant with stronger programming capabilities?

LFM2.5-24B-A2B vs Qwen3.6-35B-A3B comparison

Positioning Differences Between the Two MoE Models

Both LFM2.5-24B-A2B and Qwen3.6-35B-A3B adopt MoE (Mixture of Experts) architecture, but their design philosophies are entirely different. LFM2.5 has 24B total parameters with 2B active, while Qwen3.6 has 35B total parameters with roughly 3B active. Liquid AI has clearly bet on inference efficiency—184 tokens/s local throughput means it can drive Agent loops at near real-time speed.

Qwen3.6-35B-A3B continues the Qwen series' longstanding advantage in code tasks. The larger total parameter count gives it broader knowledge coverage, and on SWE-Bench Verified—the benchmark that evaluates real GitHub issue-fixing capability—Qwen3.6 takes the lead.

The core idea of MoE (Mixture of Experts) architecture is to split a single dense feed-forward network into multiple parallel "expert" sub-networks, then use a routing network to decide which few of them to activate based on each token's semantics. This way, the model's total parameter count can be very large (carrying broader knowledge), but the parameters actually involved in computation during each forward pass are few, greatly reducing compute and memory bandwidth overhead. The recurring "24B-A2B" and "35B-A3B" notation reflects exactly this logic: the first number is total parameters, the second is the average active parameters per token. Note that fewer active parameters doesn't mean linearly reduced capability—the larger the expert pool and the more precise the routing, the more knowledge the model can mobilize on complex tasks. This is also why Qwen3.6, with roughly 3B active, can maintain its advantage on code tasks.

Tool Calling: LFM2.5's Home Turf

Data published by Liquid AI shows that LFM2.5-24B-A2B beats Qwen3.6-35B-A3B on tool-use benchmarks. This result isn't surprising—fewer active parameters and faster inference are exactly what Agent scenarios need most.

The core bottleneck in Agent workflows often isn't the intelligence ceiling of a single inference, but the accumulated latency across multiple rounds of tool calls. Each function call, result parsing, and next-step decision requires a complete forward pass. The 184 tokens/s speed gives LFM2.5 a natural advantage in such loops. For local Agent tasks that require frequent API calls, filesystem operations, and shell command execution, response speed directly determines how smooth the user experience feels.

LFM2.5 reaching 184 tokens/s on M5 Max means it can run smoothly on consumer-grade hardware. For developers who want to deploy Agents locally to avoid cloud calling costs and privacy risks, this is an attractive option.

Coding Capability: Qwen3.6's Moat

But on SWE-Bench Verified, Qwen3.6-35B-A3B strikes back. This benchmark evaluates the model's ability to solve real open-source project issues, requiring it to understand codebase context, locate bugs, and generate correct patches. Such tasks demand deep code comprehension and long reasoning chains.

The Qwen series' accumulated expertise in code generation and software engineering tasks shows in this comparison. Although only about 3B parameters are active out of 35B total, the larger expert pool allows it to mobilize more knowledge when handling complex code logic. For scenarios requiring deep understanding of codebases, multi-file refactoring, or solving tricky bugs, Qwen3.6's advantage is structural.

SWE-Bench Verified is a key benchmark for evaluating code model capabilities. It draws merged GitHub issues and their accompanying tests from real open-source projects (such as Django, sympy, etc.), requiring the model to autonomously locate problems, modify source code, and make originally failing tests pass given the codebase context. Unlike HumanEval, which only tests function-level completion, it's closer to real software engineering: the model must understand cross-file call relationships, follow existing project style, and generate patches acceptable to the repository. The "Verified" subset of this benchmark is manually curated, removing samples with ambiguous descriptions or unreliable tests, making scores more reference-worthy and better at distinguishing a model's practical utility in real development assistance scenarios.

How to Choose: It Depends on Your Workflow

There's no absolute winner in this comparison; the choice depends on your specific scenario. If your daily work involves building and running local Agents—such as automated script orchestration, browser operations, file management—LFM2.5-24B-A2B's speed advantage will make the entire experience much smoother. 184 tokens/s throughput on M5 Max is already near the threshold of interactive response.

If your core need is code assistance—writing new features, fixing bugs, understanding legacy code—Qwen3.6-35B-A3B's performance on SWE-Bench Verified shows it's better suited for such tasks. Spending a bit more inference time for higher code accuracy is worthwhile for programming scenarios.

A pragmatic approach is to deploy both: use LFM2.5 to drive daily Agent tasks and switch to Qwen3.6 when handling complex code problems. Both models are open-source, locally deployable MoE architectures with hardware requirements within the range of high-end consumer devices.

The Tipping Point for Local Agents

LFM2.5-24B-A2B's release sends a signal: MoE models with small active parameters are making local Agents practical. The 24B total parameters, 2B active configuration keeps reasonable knowledge capacity while pushing inference costs down to what consumer-grade hardware can handle. 184 tokens/s isn't a lab number—it's a measured result on M5 Max.

When Agent response speed approaches human reading speed, the local deployment experience starts to pull ahead of cloud APIs—no network latency, no psychological burden of per-token billing, no data-export compliance concerns. LFM2.5 takes a substantial step in this direction, while Qwen3.6 proves that code capability still requires a larger expert pool to support. The two serve different needs and together push local AI workflows toward maturity.

tokens/s (tokens generated per second) is a core metric for measuring inference throughput, directly determining the user-perceived response speed. For reference, human reading speed is about 4–8 English words per second (roughly equivalent to 5–10 tokens), so when a model's generation speed approaches or exceeds this order of magnitude, the interaction experience shifts from "waiting for results" to "real-time conversation." 184 tokens/s means generating a ~300-token reply takes less than two seconds. Moreover, the bottleneck in agent scenarios isn't single-generation speed but the accumulated latency across multiple rounds of tool calls—each round of "think—call—parse—think again" requires a complete forward pass. The higher the throughput, the lower the cumulative latency of the entire loop. This is precisely where low-active MoE models derive their value in local Agents.

#LFM2.5#Qwen3.6#MoE models#local Agent#SWE-Bench
Share:

Related articles