I’ve been following the evolution of open-weight models closely, and LFM2.5-24B-A2B caught my attention for a reason that’s increasingly rare in AI: it’s genuinely smaller while being demonstrably better at specific things that matter.
Let’s be direct about what’s happening here. Language For Machines (LFM) took their previous 24B MoE architecture, kept what worked, and invested heavily in the right places. They scaled pre-training from 17T to 33T tokens, then layered in 2.3T tokens of mid-training with explicit focus on reasoning, math, code, and tool use. The result is a model that’s competitive with competitors carrying 35B to 50B+ parameters, and in several cases, it leaves them behind entirely.
Why Tool Use Matters More Than You Think
The benchmark results tell a story worth paying attention to. On AutomationBench, LFM2.5-24B scores more than 3x higher than the next competitor. That’s not margin of error territory. That’s the difference between a model that can actually orchestrate tool calls reliably and one that sounds like it can but fumbles in practice.
I’m not exaggerating when I say this is the single most important metric for anyone building production agents. Reasoning through a problem is useful. Calling the right tool at the right time with the right arguments is what actually makes things work. LFM2.5-24B leads or matches on five of eight tool-use benchmarks, including ToolSandbox and LiveClaw, both designed to test real-world complexity.
Instruction following is similarly strong across all three relevant benchmarks. For developers building agent systems, this means fewer prompt engineering headaches and more predictable behavior out of the box.
The Knowledge Trade-off Is Honest
The model doesn’t pretend to be something it isn’t. On knowledge-heavy benchmarks like GPQA Diamond and AA-Omniscience, larger models keep the edge. On coding problems that require deep domain knowledge (SWE-Bench Verified, SciCode), they also pull ahead.
This is actually healthy. It tells me LFM2.5-24B’s training was ruthlessly prioritized toward what it’s best at, not diluted by chasing every benchmark. For agents that need broad knowledge, pair this with retrieval augmented generation or web search. That’s not a limitation; it’s an architectural pattern that scales better anyway.
The Hardware Story Changes Everything
Where LFM2.5-24B really flexes is efficiency. On an M5 Max, it decodes at 184 tokens/second. On a Ryzen AI Max+ 395, it hits 114 tokens/second. That’s 1.7x faster than competitors while using less memory.
For GPU inference, it reaches over 21K output tokens/second at high concurrency on a single B300. That’s not just fast; that’s practically useful for serving multiple concurrent requests without industrial-scale infrastructure.
I want to be clear about why this matters. Most discussions about model performance focus on accuracy metrics. But inference speed and memory footprint determine whether your system can actually run on consumer hardware, whether you can afford to serve it, and whether users see results in reasonable time. LFM2.5-24B wins on all three counts.
The Architecture Underneath
The technical choices are elegant. 40 layers with 64 experts per MoE block and top-4 routing keeps the active parameter count lean while maintaining model capacity. Gated short convolutions paired with grouped-query attention provide both efficiency and quality. The context window expansion from 32K to 131K tokens is substantial without becoming unwieldy.
The in-place tokenizer expansion from 65K to 128K vocabulary directly addresses a real problem: non-Latin text tokenizes inefficiently in most English-first models. This isn’t flashy, but it’s the kind of thoughtful engineering that makes a model work better in practice.
Deployment Just Got Simpler
Day-one support across llama.cpp, MLX, vLLM, SGLang, and ONNX means you can run this virtually anywhere. No waiting for community implementations. No begging for CUDA kernels. Both the instruction-tuned version and base model are open-weight on Hugging Face.
For anyone building local AI systems, this removes friction. Serve it behind any OpenAI-compatible backend, point your agent harness at it, and iterate.
The broader implication here is that we’re entering a phase where 24B MoE models can meaningfully compete with 35B+ dense or mixture-of-experts alternatives. That changes the calculation for edge deployment, privacy-sensitive applications, and cost-conscious scaling.
LFM2.5-24B-A2B is worth your attention if you’re building agents that need to reason through problems, call tools reliably, and run on modest hardware without sacrificing performance or breaking your infrastructure budget.