Liquid AI LFM2.5-24B: 2B Active MoE on Apple M5 Max

Liquid AI’s LFM2.5-24B-A2B claims 184 tokens per second on an Apple Silicon M5 Max by routing only 2.45 billion active parameters per token, outscoring larger models on synthetic agent benchmarks like LiveClaw (48.09) and AutomationBench (27.69). Yet behind the headline decode speed lies a strict hardware barrier: sparse activation does not reduce unified memory residency [Announcement].

On October 13, 2026, Liquid AI unveiled LFM2.5-24B-A2B [Announcement], positioning the release as the ceiling model of its second-generation Liquid Foundation Model architecture. Spanning two orders of magnitude from a 230-million parameter edge probe to this 24-billion parameter Mixture-of-Experts (MoE) system, the company framed the model around a single, highly seductive proposition: delivering frontier agentic responsiveness on consumer laptops by activating only two billion parameters during any given inference step. The base and post-trained weights were released under open-weights access on Hugging Face.

For homelab operators and local LLM practitioners, the pitch sounds like the holy grail of local inference. Running a model with the broad semantic knowledge base of a 24B checkpoint while paying the computational compute penalty of an ultra-lightweight 2B model theoretically unlocks blistering generation speeds on battery power. Liquid AI backed this claim with official Pipette benchmark telemetry: a prefill speed of 4,318 tokens per second and a sustained autoregressive decode throughput of 184 tokens per second on Apple’s flagship M5 Max SoC [Tested result].

However, the laws of silicon memory architecture cannot be negotiated away by clever sparse routing. While the computational execution engine inside Apple’s Metal Performance Shaders only calculates matrix multiplications for 2.45 billion weights per forward pass, every single byte of the entire 24-billion parameter network must remain permanently resident in physical system DRAM.

In the real world of local deployment, the central question for any practitioner is never what a model scores on an unconstrained test bench, but whether the reader can actually execute this workload on the physical hardware sitting on their desk. When evaluated through that pragmatic lens, LFM2.5-24B-A2B exposes a sharp divide between synthetic micro-benchmarks and local workstation reality.

Benchmark Divergence: Tool Velocity vs. Repo-Level Coding

Liquid AI’s official evaluation dossier presents an extraordinary set of synthetic benchmark victories against its direct open-weights competition: Alibaba’s Qwen3.6-35B-A3B, Google’s Gemma-4-26B-A4B-it, and NVIDIA’s Nemotron-3.5-Lightning (30B-A3B).

On tasks measuring isolated deterministic tool-calling, API invocation, and single-turn structured output, LFM2.5-24B-A2B posts staggering margins:

• AutomationBench: LFM2.5-24B-A2B scores 27.69, more than tripling Qwen3.6-35B-A3B’s 8.72 (+217% advantage), while outperforming Gemma-4-26B-A4B-it (5.46) and Nemotron-3.5-Lightning (2.61) [Tested result].
• LiveClaw: Liquid AI records 48.09, comfortably besting Qwen3.6-35B-A3B at 38.19 (+26% lead), Gemma-4 at 41.25, and Nemotron at 37.72 [Tested result].
• ToolSandbox: LFM2.5 achieves 80.71, outperforming Qwen’s 75.02 and Gemma’s 72.09 [Tested result].
• IFEval & IFBench: In instruction-following fidelity, LFM2.5 posts 96.75 on IFEval and 74.69 on IFBench, outperforming Qwen3.6 (93.06 and 64.21 respectively) [Tested result].

These figures explain why social feeds and developer chat channels erupted with excitement upon release. If an agent’s workload consists of parsing incoming webhooks, formatting clean JSON schemas, and routing deterministic API calls across local services, LFM2.5-24B-A2B operates with razor-sharp precision and minimal latency.

The cracks appear the moment the workload shifts from narrow, structured tool execution to substantive software engineering. On SWE-bench Verified—evaluated under the OpenCode agent harness—LFM2.5-24B-A2B registers a sharp drop, hitting 51.00 [Tested result]. Meanwhile, Qwen3.6-35B-A3B posts a dominant 66.20, establishing a massive 15.20 percentage point gap.

A similar weakness surfaces in complex environmental navigation and multi-hop scientific reasoning. On WebArena Verified, LFM2.5 manages only 26.75 compared to Qwen’s 37.62 [Tested result]. On GPQA Diamond, LFM2.5’s 74.42 falls nearly ten points behind Qwen’s 83.69 [Tested result].

To understand why this performance bifurcation occurs, one must inspect Liquid AI’s post-training pipeline.

As illustrated in Figure 3, Liquid AI trains a generalist base checkpoint through Supervised Fine-Tuning (SFT), then branches into an ensemble of domain-specific teacher models. These specialist networks undergo targeted reinforcement learning before distilling their knowledge back into the student network via Multi-Objective Policy Distillation (MOPD). The pipeline separates non-agentic knowledge transfer from agentic tool interaction, terminating in an intensive Agentic Reinforcement Learning stage.

This training regimen heavily optimizes the model for shallow, high-reward terminal actions: selecting the correct tool from a list, populating schema arguments, and emitting structured output tokens. However, software engineering across production codebases demands deep, non-local context retention, syntactic dependency tracking across hundreds of files, and holistic code refactoring. When forced to reason through complex Abstract Syntax Trees (AST) and maintain repo-wide mental models, the sparse 2.45B active pathway simply lacks the parameter capacity to sustain the reasoning depth of Qwen3.6’s 3-billion active, 35-billion total parameter dense-sparse hybrid.

The DRAM Residency Trap: Why 2B Active Needs 15GB of Physical RAM

The most dangerous misconception circulating in developer communities is the assumption that because LFM2.5-24B-A2B computes only 2.45 billion active parameters per token, it can run comfortably on base-tier 16GB laptops.

In computer architecture, parametric sparsity does not equal memory sparsity.

To understand why, examine the internal structural layout of the model:

• Layers 1 through 30: A hybrid stack combining short-convolution operators with sparse Mixture-of-Experts routing. Each token dynamically selects 4 active experts out of 64 total experts per layer.
• Layers 31 through 40: Ten dense Grouped-Query Attention (GQA) layers designed to handle full 131,072-token context windows and long-horizon autoregressive reasoning.

While any single token only excites 4 experts per layer, the gating router evaluates token representations at microsecond intervals. Token N might activate experts 2, 5, 11, and 16. Token N+1 might activate experts 1, 9, 34, and 61. Because the routing decisions are stochastic and input-dependent, the operating system cannot predict which experts will be queried in the next clock cycle.

Consequently, every single one of the 64 experts across all 30 layers must be permanently pinned in physical DRAM.

When quantized to standard production formats, the physical memory footprint of this 24-billion parameter model is uncompromising:

• 16-bit Unquantized (BF16/FP16): 24.0 × 2 bytes = 48.0 GB VRAM.
• 8-bit Precision (Q8_0): ~25.5 GB VRAM.
• 4-bit Production Medium (Q4_K_M): ~14.8 GB VRAM.

Now, consider the physical reality of running this checkpoint on a standard 16GB machine—whether an M4/M5 MacBook Pro, a Mac mini, or an AMD Ryzen AI laptop:

• Base operating system and background applications consume 4.0 to 4.5 GB of RAM.
• The quantized LFM2.5-24B-A2B model weights consume 14.8 GB of RAM.
• Total memory requested before processing a single context token: 18.8 to 19.3 GB [Calculation].

On a 16GB unified memory architecture, this allocation triggers a catastrophic memory trap. By default, macOS reserves 4.0 to 4.5 GB for core system tasks and caps wired Metal allocations at roughly 75% of total physical RAM (~12.0 GB). Attempting to load 14.8 GB of weights creates an immediate 2.8 GB physical deficit beyond total machine capacity, and a 4.8 GB operational deficit against usable graphics memory (as shown in Figure 4). The operating system’s virtual memory manager instantly panics, compressing inactive pages and aggressively evicting active model tensors to SSD swap.

The moment an MoE model begins swapping over PCIe or Apple’s internal flash storage, performance falls off a cliff. While Apple Silicon unified memory delivers between 150 GB/s and 614 GB/s of direct memory bandwidth, PCIe Gen 4 NVMe swap operates at only 5 to 7 GB/s. Autoregressive decode speeds collapse from a theoretical 184 tokens per second to less than 3 to 4 tokens per second. The laptop’s fans spin up, thermal throttling engages, and the user interface stutters uncontrollably.

More critically, this 18.8 GB baseline leaves exactly zero bytes of physical headroom for the Key-Value (KV) cache.

While architectural innovations like multi-head latent attention drastically compress memory overhead, as documented in our forensic analysis of DeepSeek MLA architecture and KV cache math, LFM2.5’s ten Grouped-Query Attention layers still require substantial memory at scale. Storing the full 131,072-token KV context cache in 16-bit precision requires an additional 12.0 GB of RAM. Even under aggressive 4-bit KV cache quantization, maintaining a 32,000-token working window demands another 1.8 to 2.5 GB of dedicated memory.

Homelab builders have attempted various workarounds, including predictive disk offloading. But as proven when analyzing running 125B MoE on a 12GB GPU via Strata predictive offloading, streaming dynamically routed weights over an expansion bus introduces catastrophic latency bubbles whenever routing prediction accuracy drops below 95%.

For LFM2.5-24B-A2B, 16GB machines are an absolute dead end.

Community Telemetry: Reasoning Runaway and the Ollama Prefill Tax

As developers began pulling LFM2.5-24B-A2B into production environments, community telemetry across Hacker News thread #50097369 and developer repositories on GitHub revealed two acute operational failure modes: Reasoning Runaway and Prefix Caching Invalidation.

The first issue centers on test-time compute over-allocation. Because Liquid AI’s post-training recipe aggressively enforces Chain-of-Thought (CoT) reasoning paths, the model frequently struggles to calibrate its thinking budget against the complexity of the prompt.

In a benchmark test shared by developer isomorphic, LFM2.5-24B-A2B was evaluated on an M4 Pro Mac mini (64GB unified memory) using Simon Willison’s classic prompt: “Generate an SVG of a pelican riding a bicycle.”

The model demonstrated exceptional physical inference speed, recording an initial Time-to-First-Token (TTFT) of just 0.37 seconds and maintaining an autoregressive decode throughput of 94.74 tokens per second. However, instead of outputting the requested vector code, the model engaged in an unconstrained internal reasoning loop that persisted for 40.75 seconds [Observation]. When it finally emitted the SVG syntax, the resulting illustration was visually disjointed and rudimentary.

As practitioner serf noted in the same thread, high token throughput becomes irrelevant if the model insists on generating 4,000 reasoning tokens before answering a basic inquiry:

“This model gets a lot of tok/s but reasoning is forced on; the time-to-answer is really a combination of things like ‘how much does this thing want to over-reason’ and ‘how much does this thing like tool use?’ … The results I’ve gotten so far have been a little braindead though. Still playing around. Bad luck with traversing filesystems remotely so far. It seems to want to make concluding decisions very fast regardless of reasoning levels.”

The second failure mode emerges from runtime software friction inside Ollama and standard local model runners.

In an agentic loop, execution is inherently iterative. A controller agent inspects a repository, executes a tool, receives terminal output, and passes the updated conversation history back to the model. In an optimized inference engine, prompt prefixes (the static system prompt, tool definitions, and historical conversation turns) are cached in the KV buffer. The engine only processes newly appended tokens during prefill.

However, as reported by user 1ba9115454 running on an AMD Ryzen 7 8745HS with Radeon 780M graphics (27GB RAM allocated), Ollama’s Vulkan and GGUF backend frequently invalidates prompt prefix states when handling hybrid convolution-MoE architectures.

While the system achieved a healthy 45 tokens per second in generation and 680 tokens per second in raw prefill, the lack of prefix caching forced the runtime to re-ingest the entire 15,000-token agent context from scratch on every single turn. In a multi-step workflow, the cumulative prefill latency completely overwhelmed the decode speed, stalling the agent for 20 to 30 seconds between tool calls [Observation].

Only when deployed under native llama.cpp builds with explicit slot management—where developer serf verified throughput between 200 and 320 tokens per second on an RTX 5070 Ti with full 131k context [Observation]—does the architecture operate without software-induced bottlenecks.

Hardware Arithmetic: The Unified Memory Bandwidth Equation

To understand why Apple Silicon dominates on-device MoE inference, one must examine the governing physics of autoregressive decoding.

In modern deep learning, the computational bottleneck shifts dramatically between inference phases:

• Prefill Phase: Compute-bound. The engine processes prompt tokens concurrently, saturating the GPU’s matrix multiplication cores (Tensor Cores or Apple Neural Engine).
• Decode Phase: Memory bandwidth-bound. The engine emits tokens sequentially, one by one. For each generated token, the hardware must stream model weights from system DRAM into active cache lines to compute a single matrix-vector dot product.

For a standard dense transformer, the memory bandwidth required to achieve a target decode speed is given by the total model parameter count multiplied by the byte-precision.

For a Mixture-of-Experts model, however, the decode arithmetic changes. Because only a subset of experts is active per token, the memory bus only needs to stream the active parameters for that specific forward step.

This mathematical derivation explains the hardware throughput numbers captured in Liquid AI’s official edge inference telemetry [Calculation].

Apple’s M5 Max features a 512-bit unified memory bus delivering 614 GB/s of theoretical bandwidth. Streaming 225.4 GB/s of active weights consumes only 36.7% of the chip’s total memory bus, leaving ample bandwidth for display engines, Metal kernel synchronization, and Grouped-Query Attention KV cache lookups. This headroom allows the M5 Max to achieve 4,318 tokens per second during prefill and sustain 184 tokens per second during decode.

Now compare that performance against alternative hardware platforms:

• Mac Studio (M-Series Max tier): Featuring a 400 GB/s unified memory bus, the Studio records 2,451 tokens per second prefill and 146 tokens per second decode [Tested result]. The 20.6% drop in decode speed directly mirrors the narrower memory bus.
• AMD Ryzen AI Max+ 395: AMD’s premier unified APU features a 256-bit LPDDR5X-8533 memory subsystem delivering roughly 273 GB/s of theoretical bandwidth. Under real-world memory controller efficiency, sustainable bandwidth hovers around 180 to 200 GB/s. Because the required 225.4 GB/s exceeds sustainable single-socket APU bandwidth, decode speed drops to 114 tokens per second, with prefill settling at 1,641 tokens per second [Tested result].
• Dual-Channel Desktop PC (DDR5-6000): A standard gaming PC operating two channels of DDR5-6000 memory possesses a meager 96 GB/s of bandwidth. Attempting to run LFM2.5-24B across system CPU memory caps decode speeds at roughly 35 to 40 tokens per second [Calculation].

This memory bus hierarchy confirms our previous findings in M5 Max and Ultra versus Ryzen AI Max 395 running Qwen 3.8 and 120B MoE models, where memory channel width proved to be the single most decisive factor in local LLM viability.

At the extreme enterprise end of the spectrum, dedicated accelerator hardware operates entirely unconstrained by edge bandwidth limits.

As shown in Figure 8, deploying LFM2.5-24B-A2B on a single NVIDIA Blackwell Ultra B300 GPU—equipped with 288GB of HBM3e memory delivering 8.0 TB/s of bandwidth—allows serving throughput to scale to 21,085 output tokens per second at 1024 concurrent requests under SGLang 0.5.22 [Tested result]. In high-concurrency enterprise clusters, the small 2.45B active footprint allows massive batch multiplexing, easily outpacing Qwen3.6-35B-A3B (~12,500 tok/s) and Nemotron-3.5-Lightning (~11,300 tok/s).

The Homelab Hardware Matrix: Buying Guide and Deployment Reality

For the homelab builder, indie developer, or enterprise engineer looking to deploy local models, hardware procurement decisions must be guided by arithmetic rather than vendor marketing.

Evaluating Apple Silicon investments requires a clear-eyed assessment of system economics, as detailed in our analysis of M5 Max versus M5 Ultra 512GB unified memory economics. To determine where LFM2.5-24B-A2B actually fits, use this verified hardware tiering matrix:

16GB Unified RAM: The Non-Starter

• Target Hardware: Base M4/M5 MacBook Air, MacBook Pro 14" (16GB), base AMD APU laptops.
• Operational Reality: FAILED DEPLOYMENT. The 14.8 GB model weights combined with macOS baseline usage (4.0 GB) guarantees instant memory exhaustion. Swap thrashing degrades generation to 2–4 tok/s, with severe UI lockups.
• Verdict: Do not attempt. Stick to 3B to 8B dense models (such as Llama 3.2 3B or Gemma 2 9B in Q4).

24GB Unified RAM: The Tight Squeeze

• Target Hardware: M4 Pro Mac mini (24GB), AMD Strix Point laptops configured with 32GB system RAM (24GB assigned to VRAM).
• Operational Reality: MARGINAL / RESTRICTED. The model fits with approximately 4.2 GB of free headroom. This supports small working contexts (up to 8,000–16,000 tokens). However, expanding context toward 32k or executing long agentic loops will push allocations into swap.
• Verdict: Usable for isolated, single-turn tool calls. Inadequate for deep repository analysis or agentic loops.

48GB to 64GB Unified RAM: The Homelab Sweet Spot

• Target Hardware: M4/M5 Max MacBook Pro (48GB/64GB), M4 Pro Mac mini (64GB), desktop PC with dual 24GB GPUs (e.g., dual RTX 3090 / 4090).
• Operational Reality: OPTIMAL PRODUCTION. The 14.8 GB model weights and full 12.0 GB 131k KV cache occupy roughly 26.8 GB. With operating system overhead, total memory consumption hovers around 31.5 GB, leaving 16 to 32 GB of unconstrained RAM for developer tooling, IDEs, and local databases.
• Verdict: Sustained 140 to 184 tokens per second decode, zero swap paging, and flawless multi-turn agentic stability.

128GB+ Workstation Tier: The Heavy Fleet

• Target Hardware: Mac Studio M4/M5 Max (128GB), Mac Pro, multi-GPU workstation clusters.
• Operational Reality: ENTERPRISE RUNTIME. Allows co-locating LFM2.5-24B-A2B alongside embedding models, vector databases, and multi-agent supervisory harnesses simultaneously.
• Verdict: Total deployment flexibility with room for unquantized FP16 weights.

Strategic Decision Matrix: LFM2.5-24B vs. Qwen3.6-35B-A3B

When choosing between local open-weight MoE champions, align model architecture with workflow intent:

Deploy Liquid AI LFM2.5-24B-A2B if your architecture demands raw generation velocity for deterministic automation, single-turn function calling, and structured data extraction, provided your host possesses at least 32GB of unified memory.

Deploy Alibaba Qwen3.6-35B-A3B if your agent lives inside a software repository, debugs complex codebases, or executes multi-file patches where SWE-bench Verified accuracy (66.20 vs 51.00) is the difference between a merged pull request and a broken build.

Liquid AI has engineered an impressive demonstration of hybrid convolution and sparse MoE efficiency. But in the local homelab, silicon physics always triumphs over marketing claims. Two billion active parameters will give you 184 tokens per second, but 24 billion weights will always demand 15 gigabytes of physical RAM. Check your system specs before you run ollama pull.