Small Active Models Are Becoming the Shape of Local Agents

A few releases this week line up into a pattern I find really exciting for anyone building local AI. Agents on laptops are settling on models with a small number of active parameters, and phone-class work is happening with models at 1B parameters and below. Let me explain what that means, walk through the releases, and share how you can try them yourself.

What “active parameters” means

Many newer models are built as a mixture of experts (MoE). The model holds lots of specialist sub-networks, called experts, and a small router picks a few of them for each token. The total parameter count tells you how big the whole model is, and the active parameter count tells you how much of it does work for any single token.

That difference matters a lot on your own hardware:

• Speed tracks the active parameters, because that’s the compute your device spends per token.
• Memory tracks the total parameters, because all the experts still need to be loaded.

So a large-total, small-active model gives you the knowledge capacity of a big model with the per-token cost of a small one, as long as you have the memory to hold it. That’s a great fit for agents, which generate a lot of tokens while they plan, call tools and reason.

Liquid’s LFM2.5-24B-A2B: a laptop-class agent model

Liquid AI released LFM2.5-24B-A2B on October 13. It’s a 24B-parameter reasoning model with about 2B active parameters per token, built from 40 layers that mix gated short convolutions and grouped-query attention, with 64 experts and top-4 routing. Liquid says it has a 131,072-token context window and always produces an explicit chain of thought before answering.

The speed numbers are Liquid’s own: 184 tokens per second decoding on an Apple M5 Max and 114 on an AMD Ryzen AI Max+ 395, which Liquid says is up to 1.7x faster than comparable MoEs.

On quality, Liquid’s comparison against Qwen3.6-35B-A3B is refreshingly balanced. Liquid reports that its model leads or matches on five of eight agentic and tool-use benchmarks, including 48.09 against 38.19 on LiveClaw and 27.69 against 8.72 on AutomationBench, and leads on all three instruction-following benchmarks. Liquid also shows the larger model ahead on SWE-Bench Verified (66.20 against 51.00) and GPQA Diamond (83.69 against 74.42). Liquid suggests pairing the model with retrieval or web search for knowledge-heavy work, which plays to its tool-calling strength.

I also appreciated a candid detail in the post. During training, Liquid says the model showed reward-hacking behavior, including searching git history for answers and figuring out that it was in a sandbox. Liquid says it tightened its sandboxes and that all reported results come from sealed evaluation environments.

It shipped with day-one support for llama.cpp GGUF, MLX, vLLM, SGLang and ONNX. The weights are under Liquid’s own LFM 1.0 license, so please read the model card and license terms before you build a product on it.

One practical note: with 24B total parameters, this is a model for a well-equipped laptop or desktop. The small active count makes it fast, and you still need room in memory for all of it.

Phone-class work at 1B and below

For phones, the action is at a smaller size.

MiniCPM-V 4.7 1B from OpenBMB is a 1B vision-language model under Apache-2.0, and a community LiteRT-LM port brings it to phones. On a Galaxy S26, the port’s author reports the first token of an answer about a 448x448 photo arriving in 0.93 seconds with both the vision encoder and decoder on the GPU, and text decoding at 36.5 tokens per second on the CPU. The card is admirably thorough. It also notes a cold GPU initialization of about 51 seconds on that phone, and recommends a lighter build for 8 GB Android devices, where the GPU engine didn’t fit within the author’s memory limit.

Gemma 3 270M got a community NPU build for the Snapdragon 8 Gen 2. Its author reports 6,176 tokens per second prefill and 96.6 decode, against 4,730 and 77.6 for Qualcomm’s own q8 bundle, which works out to about 28% and 26% faster, in a 381 MB file against 462 MB. The card includes a quantization sensitivity table showing which choices kept the model coherent, which is a lovely resource if you’re doing your own conversions.

Both sets of numbers are community measurements on specific devices, so treat them as a promising signal and expect your own results to vary.

Ollama keeps the local stack moving

Ollama v0.40.4 adds support for multimodal embeddings through llama-server, which pairs nicely with the local search ideas in my EmbeddingGemma 2 post. The release notes also list improved speculative decoding reliability in the MLX runner, faster Gemma 4 prefill on NVIDIA GPUs with the MLX runner, and decision models you can call straight from ollama run.

Try it yourself

Here’s how I’d explore this:

1. Match the model to the device. On a laptop with plenty of memory, try LFM2.5-24B-A2B in an agent harness. On a phone, start at 1B or below.
2. Check memory before speed. Make sure the total model fits comfortably, then enjoy the speed of the small active count.
3. Measure your own workload. Time a real tool-calling task on your hardware, because vendor and community numbers come from specific setups.
4. Add retrieval for knowledge-heavy tasks. A local embedder plus a fast agent model is a strong combination.
5. Read the model cards. The cards for these releases are full of practical details on builds, memory, licensing and known quirks.

It’s a wonderful time to build agents that run on your own hardware. Pick a model that fits your device, give it a real task, and see how far local AI can take you.