LFM2.5-24B-A2B: A Fast Model Built for On-Device Agents

Liquid AI launches LFM2.5-24B-A2B, an MoE model built for on-device agents, with 24B total parameters and only about 2B activated.
Liquid AI has released LFM2.5-24B-A2B, a Mixture-of-Experts model optimized for on-device agents. With 24B total parameters and only about 2B activated, it decouples knowledge capacity from per-pass computation, allowing it to run on consumer hardware. The article notes that on-device agents prioritize low-latency multi-turn tool calling over single-response quality. MoE's cost on the edge is that all 24B weights must still be loaded into memory, and the router adds overhead. Its value lies in local privacy, low-latency function calling, and offline use, but 2B-level activation limits complex reasoning.
What Is LFM2.5-24B-A2B
LFM2.5-24B-A2B, released by Liquid AI, is a Mixture-of-Experts (MoE) architecture model optimized for on-device agent scenarios. The naming convention reveals the key details: 24B total parameters, with only A2B (roughly 2B-level) activated parameters, meaning the model only needs to invoke a tiny fraction of its parameters to complete a computation during inference.

This design approach speaks directly to the core tension in on-device AI today: users want local devices to have sufficiently strong language understanding and tool-calling capabilities, but phones, laptops, and edge devices have severely limited compute and memory. The 24B total capacity guarantees the knowledge reserve, while the 2B-level activation keeps the computational cost of each inference pass within an acceptable range.
Mixture of Experts (MoE) is a class of sparsely activated neural network architectures. Its core idea is to split the feed-forward layers into multiple parallel "expert" sub-networks and additionally train a lightweight "router" (router/gating network). During each forward pass, the router selects only a few experts to participate in the computation based on the current token's representation, leaving the rest idle. This way, the model's total parameter count can be very large (to store knowledge), but the actual computation per token depends only on the number of activated experts, thereby decoupling inference cost from model capacity. This stands in sharp contrast to the linear relationship in dense models, where "more parameters means more computation per pass," and it is a key reason MoE is widely used in ultra-large-scale models.
Activated Parameters refer to the scale of parameters that actually participate in floating-point operations when the model processes a single token, typically equal to the parameters of the selected experts plus the parameters of the shared layers and attention components. It is a different concept from "total parameters": MoE models such as DeepSeekAd and Mixtral all adopt the "large total, small activation" naming convention, for example denoting a model with 24B total parameters and about 2B activated as 24B-A2B. Activated parameters directly determine the computational load (FLOPs) and theoretical latency during inference, while total parameters determine VRAM/memory footprint. Understanding this distinction is key to judging whether an on-device model can actually be deployed—it determines what constrains the model's ability to "run" versus its ability to "fit."
Why On-Device Agents Need Purpose-Built Models
Agents and ordinary chat models have different requirements for the inference engine. A typical on-device agent needs to execute frequent multi-turn loops: parsing user intent, selecting tools, generating structured parameters, reading returned results, and continuing to make decisions. In this process, low latency matters more than single-response quality—users will not accept waiting several seconds for every tool call.
The reason LFM2.5-24B-A2B sparked discussion on Hacker News is precisely this: what it tries to solve is not "what the model can do," but "how fast the model can do it, and on how small a device." For locally running automation assistants, document processing in privacy-sensitive scenarios, and tool-calling workflows that need to be available offline, this class of model offers a more pragmatic option.
Trade-offs of MoE Architecture on the Edge
MoE architecture is not a new concept, but using it on the edge involves unique engineering trade-offs.
Advantage: Decoupling Capacity from Speed
To improve capability, traditional dense models must increase inference cost in lockstep. MoE separates "how much it remembers" from "how much it computes each time": 24B parameters are distributed across multiple experts, and the router dynamically selects activation paths based on the input. According to analysis in the HN discussion, the A2B-level activation volume makes it possible for the model to run on consumer-grade hardware without relying on data center GPUs.
Challenge: Memory Footprint and Routing Overhead
The costs of MoE are equally obvious. Although the activated parameter count is small, all 24B weights still need to be loaded into memory, which is relatively friendly to devices with a unified memory architecture (such as Apple Silicon chips) but creates pressure on devices with limited discrete VRAM. In addition, the router's scheduling logic itself introduces extra latency, and on-device deployment requires quantization and operator optimization tailored to specific hardware.
Unified Memory Architecture (UMA) refers to a design in which the CPU, GPU, and other accelerators share the same physical memory pool, with Apple's M-series chips being a typical example. In traditional discrete GPU setups, model weights need to reside in VRAM, and VRAM capacity is usually far smaller than system memory; once model weights exceed the VRAM limit, they must rely on CPU offloading or paging in and out, causing a sharp drop in speed. Under a UMA design, the GPU can directly access all system memory, so a model with a large total parameter count like 24B can also be loaded in full on a MacBook. This is also why the article emphasizes that it is "relatively friendly to devices with a unified memory architecture but creates pressure on devices with limited discrete VRAM"—differences in memory bandwidth and capacity often determine the practical usability of on-device MoE models more than raw compute does.
The Real Application Boundaries of On-Device Agents
Based on the direction of the discussion in the HN comments, the practical value of this class of model centers on a few scenarios:
Local privacy-first automation—data never leaves the device, and the agent completes tasks such as email classification, calendar organization, and document summarization locally.
Low-latency tool calling—compared with round trips to cloud APIs, local models can achieve near-instant function-call responses, making them suitable for interface operations that require high-frequency interaction.
Offline availability—in environments with unstable networks or complete isolation, on-device models are the only viable option.
It is important to recognize clearly that a 2B-level activation volume means its capabilities in complex reasoning and long-chain planning cannot compete head-on with large cloud models. Its positioning is a "good-enough local agent," not an "all-purpose assistant."
What It Actually Means for Developers
The emergence of LFM2.5-24B-A2B reflects a trend that is taking shape: model vendors are beginning to optimize specifically for the niche of "on-device agents," rather than simply shrinking large models. For developers, this means that when choosing a local inference solution, in addition to looking at parameter count and benchmarks, they also need to pay attention to activated parameters, memory footprint, and whether the model has been optimized for tool-calling format and latency.
Competition in on-device AI is shifting from "can it run" to "does it run well and fast."
One-line Summary
Liquid AI launches LFM2.5-24B-A2B, an MoE model purpose-built for on-device agents, with 24B total parameters but only about 2B activated.
Paragraph Summary
Liquid AI has released LFM2.5-24B-A2B, a Mixture-of-Experts model optimized for on-device agents. With 24B total parameters and only about 2B activated, it uses MoE architecture to decouple "knowledge capacity" from "per-pass computation," enabling it to run on consumer-grade hardware. The article notes that on-device agents have different demands from ordinary chat models, prioritizing low-latency multi-turn tool calling over single-response quality. The cost of MoE on the edge is that all 24B weights still need to be loaded into memory—friendly to unified-memory devices, but a strain on those with discrete VRAM—and the router itself adds overhead. Its value centers on local privacy automation, low-latency function calling, and offline availability, but 2B-level activation limits complex reasoning, positioning it as a "good-enough local agent."
Related articles

Chain of Thought Isn't Just for AI: How Humans Can Use CoT to Improve Thinking Quality
Chain of Thought isn't just a prompt trick for large models. Starting from a Hacker News discussion, this article analyzes why CoT works for human thinking too, breaks down actionable ways to transfer it, and highlights the key differences between human CoT and machine CoT.
Cloudflare Teams Up with OpenAI: Closi…
Cloudflare Teams Up with OpenAI: Closing the Loop from Vulnerability Discovery to Defense with AI
Cloudflare uses OpenAI Daybreak to investigate security vulnerabilities and generate reviewable remediation plans, while developers use Codex to boost coding efficiency and quality.

Orca Multi-Agent Orchestration in Practice: A Guide to Parallel Collaboration with Claude and Codex
Orca is Stable AI's free open-source agent workbench supporting 34 agents like Claude Code and Codex in parallel. Learn its Git worktree isolation, multi-model orchestration, and mobile management.