Liquid AI just shipped an open-weight model that makes a concrete infrastructure promise: LFM2.5-24B-A2B is a 24-billion-parameter model that only activates 2 billion parameters per token and — critically — launches with first-class support for llama.cpp, MLX, vLLM, SGLang and ONNX.
That opening sentence is the important part. Models that advertise enormous total parameter counts but relatively small active parameter footprints are only useful if you can actually run them where you need to: on-device, on CPU, or on lower-cost GPUs. Liquid AI's release pairs the architectural trade (24B total / 2B active) with the pragmatic stuff platform teams care about: multiple runtimes and export paths from day one.
Why 2B active params matters
Two billion active parameters is a meaningful operating point: it can fit into aggressively quantized, CPU-bound inference and into small GPU instances, while still enabling useful capabilities for private agents and offline work. Active-parameter size drives working memory, latency, and power. Total-parameter count becomes a marketing metric unless the runtime ecosystem makes that working set accessible.
Liquid AI's move to ship with llama.cpp and ONNX support is the pragmatic half of the announcement. llama.cpp gives you reasonable local CPU performance and a path to low-bit quantized execution (ggml-backed 8-bit and common 4-bit formats); ONNX unlocks vendor-agnostic toolchains and conversion paths into backends such as NVIDIA TensorRT and ONNX Runtime, and it integrates with mainstream quantization and pruning toolkits. vLLM and other server-focused runtimes cover the other end: efficient batching/serving and platform-optimized backends. In other words, they've built the full-stack ingress points a platform team needs to actually run these models beyond a benchmark blog post.
This is the right call
Open-weight models without runnable export targets are academic. Liquid AI chose the right trade: ship the model and ship working integrations. That will matter more for engineering teams in 2026 than whether a model's total parameter count is 24B or 30B. If you run private agents or care about running inference on-device for privacy or cost reasons, you should be more excited about the runtimes than the headline parameter number.
But there's a catch: active-param models shift complexity to runtime and routing. MoE-style dispatching, memory management for sparse activations, and quantization artifacts are now your operational problems. Expect new failure modes: cross-device routing hot spots, quantization-induced hallucinations, and subtle latency cliffs when the active set grows under certain prompts.
Context: big MoE and the ecosystem
This release isn't happening in isolation. Research groups and hyperscalers continue to explore sparsely activated (MoE) designs at very large scale — models with hundreds of billions of parameters and large active-parameter footprints exist in research — but those require specialized infrastructure you won't have in a single rack. That trend is worth watching, but it's orthogonal to the immediate value for platform teams: you can run LFM2.5 locally or on modest instances; you can't reasonably run the largest research MoE models without specialized hardware. For a comparison of the platform implications of recent MoE work, see our coverage of Beam 1.0 and its design: /article/beam-1-0-501b-23b-active-1m-context/.
Operational checklist (short)
- Benchmark the active-parameter working set across quantization modes (fp16, int8-style ggml formats, common 4-bit variants) before you standardize on a runtime.
- Validate your routing and batching strategy under realistic agent workloads — synthetic load tests undercount rare-token routing hot-spikes.
- Treat ONNX as the interoperability surface: build conversion tests into your CI to avoid “it ran in research” surprises in production.
Final take
Liquid AI's LFM2.5 release is a small, correct step for model engineering — not because it invents a new architecture, but because it connects an active-parameter design to the real-world runtimes engineers actually use. Expect more vendors to follow: the next wave of meaningful model releases will be judged by their export stories and runtime cost, not just their total parameter count. Platform teams who still size capacity by headline parameters will be surprised when the working set — not the marketing number — determines latency, cost, and reliability.