LBS-27B vs LFM2.5 24B A2B: The Active-Parameter Question

The most important number in LFM2.5 24B A2B is not 24. It is 2.45 — the billions of parameters the model actually reads for each token. That is why Liquid AI can claim 184 output tokens per second on an Apple M5 Max while the model holds 24 billion parameters of knowledge, and why the company positions it as an on-device agent rather than a data-centre workhorse. The same number is missing from LBS-27B, and its absence is the reason this comparison cannot yet be settled: without an active-parameter count, there is no way to place inclusionAI's model on the efficiency curve that LFM2.5 defines.

LFM2.5 24B A2B has been downloadable since 13 October 2026, with a model card, sixteen benchmark rows and a licence that most enterprises will need to read carefully. LBS-27B is a repository created on 26 October 2026 that contains a standard .gitattributes file and a 28-byte README declaring Apache-2.0. No weights, no config, no card, no announcement. What follows is therefore a comparison between a fully specified efficiency play and a name that has not yet said what kind of model it is.

What Liquid is optimising for

LFM2.5 24B A2B is a mixture-of-experts decoder with 64 experts and top-4 routing, 40 layers, a hidden size of 2,048 and a vocabulary of 128,000 tokens. The active count is 2.45 billion. It accepts 131,072 tokens of context, up from 32K in the previous generation, and it was pretrained on 33 trillion tokens, roughly double the 17 trillion used for LFM2.

The vocabulary change is a detail worth noticing. Moving from 65K to 128K tokens is expensive — it means retraining the embedding and output layers — and the usual reason to do it is non-Latin text. The card lists sixteen languages: English, Arabic, Chinese, French, German, Italian, Japanese, Korean, Portuguese, Spanish, Vietnamese, Thai, Indonesian, Hindi, Russian and Polish. A larger vocabulary makes those languages cheaper per word and usually better at the tail.

It is also a reasoning-only model. Liquid's post-training pipeline runs supervised fine-tuning, teacher specialisation, non-agentic and agentic distillation, then agentic reinforcement learning inside harnesses such as OpenClaw, Hermes Agent, Pi and OpenCode. The model produces a chain of thought before answering; there is no separate "fast, no-thinking" mode documented on the card.

A deliberately spiky benchmark profile

Liquid's own numbers, unreproduced by us, describe a model that is excellent at the things an on-device agent does and poor at the things a knowledge worker needs. That shape is not an accident; it is the design.

• Instruction following — IFEval 96.75, IFBench 74.69, Multi-IF 84.38. This is the strongest cluster on the card and the one that matters most for an agent that has to obey a tool schema.

• Tool use — ToolSandbox 80.71, PinchBench 83.18, BFCL v4 65.01, AutomationBench 27.69. Good, but uneven across harnesses.

• Agentic browsing and computer use — LiveClaw 48.09, WebArena Verified 26.75, tau3-Bench Banking 8.04. The banking result is the outlier: a single-digit score on a task suite that other agentic models handle far better. It is a reminder that "agentic" is not one capability.

• Software engineering — SWE-Bench Verified 51.00 under OpenCode, SciCode 32.71. Mid-pack.

• Mathematics — MATH-500 96.04. Strong for the size.

• Knowledge — GPQA Diamond 74.42, HLE 7.40, AA-Omniscience −24.90. The negative Omniscience score is the honest signal here: on a benchmark that penalises confident wrong answers, the model loses more than it gains. Liquid's own positioning acknowledges this — the model is meant to be paired with retrieval, not trusted as an encyclopedia.

Read together, those rows say the model is a competent instruction-follower and tool-caller with a thin knowledge base. For a local agent that reads your files and calls your APIs, that is the right trade. For a research assistant, it is the wrong one.

The efficiency claim, with its caveats

Liquid reports 184 tokens per second on an Apple M5 Max using about 15GB of memory, and 114 tokens per second on a Ryzen AI Max+ 395. Those are vendor figures on specific hardware, not a general benchmark, and they will move with quantisation and batch size. The direction is still meaningful: a 24B model with 2.45B active can run on a laptop in a way that a dense 24B cannot.

The trade is memory bandwidth. Sparse models still have to hold all 24 billion parameters in memory — the saving is compute per token, not storage. That is why the 15GB figure matters as much as the throughput: it is roughly a 4-bit quantisation of the full weight set, and it sets the hardware floor.

Where LBS-27B would have to sit

Everything about this matchup depends on two fields that do not exist yet in the LBS-27B repository: the expert count and the active-parameter count.

If LBS-27B is sparse with something like 2B to 4B active, it lands directly on LFM2.5's territory — a 27B-class knowledge base at small-model compute — and the comparison becomes a straight contest of quality per active parameter. If it is dense, it is a different product entirely: a server-side model with predictable compute and a memory footprint that rules out most laptops. If it is sparse with a large active count, it sits between the two and competes on quality rather than efficiency.

There is no way to infer which from the repository. The name says 27B, the README says Apache-2.0, and the file tree says nothing else. inclusionAI has not published a card, a blog post or a paper that we could find.

The comparison, as far as it can be made

• Total parameters — 24.0B for LFM2.5 24B A2B; an unverified 27B for LBS-27B.

• Active parameters — 2.45B for LFM2.5; unknown for LBS-27B, and this is the decisive unknown.

• Architecture — 64 experts with top-4 routing and 40 layers for LFM2.5; unknown for LBS-27B.

• Context — 131,072 tokens for LFM2.5; unknown for LBS-27B.

• Modality — text only for LFM2.5; unknown for LBS-27B.

• Languages — sixteen listed for LFM2.5; unknown for LBS-27B.

• Reasoning — chain of thought by default, with no documented no-thinking mode, for LFM2.5; unknown for LBS-27B.

• Licence — the LFM 1.0 licence, with a commercial-licence requirement above $10 million in annual revenue, for LFM2.5; Apache-2.0 declared for LBS-27B.

• Published evaluations — sixteen vendor-reported rows for LFM2.5; none for LBS-27B.

The licence is a procurement question, not a footnote

This is the one dimension where the empty repository already gives LBS-27B an advantage. The LFM 1.0 licence is not open source in the OSI sense: companies with more than $10 million in annual revenue need a separate commercial licence before deploying it. For an individual developer or a startup below the threshold, that is a non-issue. For a mid-size company, it is a legal review, a negotiation and a line item.

LBS-27B declares Apache-2.0 in its README. That is a permissive licence with an explicit patent grant and no revenue threshold, and if it survives to the weight release it removes an entire procurement step. It is the only concrete advantage LBS-27B currently holds in this comparison, and it is worth stating clearly because it is real — a licence declaration made at repository creation is weak evidence, but it is not nothing.

On-device versus API: two different products

LFM2.5 24B A2B is built to run where the data is. The pitch is privacy and latency: a model on a laptop or a workstation that never sends a request to a third party, with tool-calling good enough to drive local automation. The 4-bit memory footprint and the 131K context are sized for that job.

LBS-27B has not said what it is for. If inclusionAI ships a model designed for server-side serving, the on-device argument does not transfer and the two models are complements rather than substitutes. If it ships a small-active MoE with a local deployment story, the comparison is direct and Liquid's two-generation head start in on-device tooling — llama.cpp, MLX, ONNX and vLLM support, plus a documented agent harness — becomes the tiebreaker.

Framework support is an underrated part of this. A model that is not in llama.cpp or MLX on day one is not an on-device model in practice, regardless of its active-parameter count.

Testing an unproven model without betting on it

Neither LBS-27B nor LFM2.5 24B A2B is on OrcaRouter today, so there is no hosted endpoint for either and we will not suggest otherwise. The reason to mention the platform here is the evaluation problem that follows: if you want to know whether a new small-active model can replace your current one, you need to run both on your own traffic, not on a leaderboard.

OrcaRouter's routing DSL lets you send a percentage of requests to a candidate model while keeping the incumbent as the default, and automatic failover means a candidate that times out or errors degrades to the known model instead of failing the request. For the hard cases where one model is not enough, model fusion lets a panel of models answer together and returns a combined result — useful when the task is knowledge-heavy and the cheap model's weak spot is exactly what you are testing. The 200-plus model catalogue and 0% markup matter less here than the ability to compare on your own inputs without a second integration.

That is a way to generate the evidence this page is missing. It is not a substitute for the model existing.

Three readers, three answers

If you are building an on-device agent and you need something that runs on a laptop today, LFM2.5 24B A2B is a serious candidate: strong instruction following, good tool-calling on several harnesses, 131K context and a documented path into the usual local runtimes. Check the licence threshold first, and do not expect it to know facts without retrieval.

If you are choosing a server-side 27B and you need a permissive licence, LBS-27B is worth watching precisely because Apache-2.0 is already declared. But there is nothing to evaluate, and a licence declaration is not a model.

If you are an enterprise with more than $10 million in revenue and a strict procurement process, the licence difference may matter more than any benchmark row in this article. LFM2.5's custom licence is a real cost; LBS-27B's Apache-2.0 is a real advantage, contingent on it surviving to release.

The number that would change all three answers is the active-parameter count. Until it exists, the honest position is that one model has an efficiency story and the other has a repository.