LFM3-1.7B vs Gemma 4 26B A4B: Two Recipes for a Cheap Token, and Only One Fits on a Phone

On paper these two models take the same approach to the same problem. LFM3-1.7B, announced by Liquid AI on October 27, 2026, and Gemma 4 26B A4B, released by Google DeepMind on April 2, 2026, both exist to answer one question: how do you get a capable model into a small memory budget? They give opposite answers. Liquid shrank the model. Google kept the model large and only pays for a slice of it per token. The weights are free, so the bill is whatever the cheapest competent host charges. We pass provider list prices through at 0% markup.

The distinction sounds like architecture trivia until you price out a deployment, at which point it is the only thing that matters. Gemma 4 26B A4B activates 3.8 billion parameters per token, but you still have to hold 25.2 billion of them somewhere. LFM3-1.7B activates all 1.73 billion of its parameters and stores exactly that many. One is cheap to compute. The other is cheap to own.

Two recipes for a cheap token

Gemma 4 26B A4B is a mixture-of-experts model: 128 routed experts plus one shared expert, 30 layers, with roughly eight experts firing per token. That gives it the knowledge capacity of a 25.2B dense model and the arithmetic cost of something closer to a 4B. Google's own framing is that it reaches about 97% of the dense Gemma 4 31B's MMLU-Pro score at roughly 12% of the FLOPs.

LFM3-1.7B takes the other road. It is fully dense — every parameter runs on every token — and the savings come from a redesigned architecture rather than from sparsity. Liquid's tri-hybrid stack is 24 layers: 13 gated short convolutions, five sliding-window attention layers, six full-attention layers. Most of the sequence modelling is done by convolutions, which are cheap, and full attention appears only six times. That is how a 1.73B model carries a 262,144-token context and a 128,000-token vocabulary without the KV cache eating the machine.

• Total parameters — 1.73B for LFM3-1.7B; 25.2B for Gemma 4 26B A4B.

• Active per token — 1.73B against about 3.8B. This is the only row where the two are in the same league.

• Memory at 4-bit — roughly 1 GB against roughly 18 GB. This is the row that decides the deployment.

• Context — 262,144 tokens on both, again a genuine tie.

• Modality — text only against text and image input, with native function calling and a configurable thinking mode.

• License — LFM Open License v1.0, free below $10 million in annual revenue; Apache 2.0 with no threshold for Gemma 4 26B A4B.

Why 3.8B active does not mean 3.8B of memory

This is the most common error in reading a mixture-of-experts spec sheet, so it is worth being blunt. Active parameters govern compute and, loosely, speed. They do not govern the size of the file you download or the VRAM you reserve. Gemma 4 26B A4B needs its full 25.2 billion parameters resident to route between experts; at 4-bit that lands near 18 GB. You can serve it on a single 24 GB card, and Google ships FP8 and NVFP4 builds to make that practical, but you cannot put it on a phone.

LFM3-1.7B is about 1 GB at 4-bit — Liquid's card says it fits on a phone or a laptop, and at that size the claim is credible rather than marketing. It also keeps a 1.6 GB KV cache at 128K tokens, which is the number that actually determines how many concurrent long-context requests you can hold.

The practical consequence: a 26B-A4B deployment is an inference-server decision, and a 1.7B deployment is an application-shipping decision. Those are different projects with different teams and different cost structures, and no benchmark closes the gap between them.

What each vendor published, and what that tells you

Google published a wide table for Gemma 4 26B A4B: 82.6 on MMLU-Pro, 82.3 on GPQA Diamond, 88.3 on AIME 2026 without tools, 77.1 on LiveCodeBench v6, a Codeforces Elo of 1718, 73.8 on MMMU-Pro, and 44.1 on MRCR v2 at 128K with eight needles. All vendor-reported, none independently reproduced. Third-party tracking puts its LMArena Elo near 1438.

Liquid published a narrower table for LFM3-1.7B, and it is tilted toward agentic work: 71.39 on BFCL V4, 80.36 on ToolSandbox, 68.01 on τ³-bench, 45.60 on LiveClaw, 38.42 on WebArena-Verified. It also reports 96.66 on IFEval, 73.03 on IFBench, 63.37 on GPQA Diamond, 73.46 on LiveCodeBench v6, and 65.56 on RULER at 128K. Liquid does not publish an MMLU-Pro figure for LFM3-1.7B, and the absence is not a zero — it is simply not measured.

Only LiveCodeBench v6 and GPQA Diamond overlap cleanly. Gemma 4 26B A4B wins both, by 3.6 and 18.9 points respectively. Where Liquid's suite turns agentic, there is no Gemma number to compare against — Google reports τ²-bench at 68.2, and τ² is not τ³, so placing 68.01 beside it would be a fabricated comparison dressed as a careful one.

Where the 1.7B stays in the conversation

A 3.6-point LiveCodeBench gap is smaller than the 14-to-1 parameter ratio would predict, and the reason is architectural. Competitive programming rewards the ability to hold a pattern and emit a correct function — a skill that benefits from a clean training signal more than from raw capacity. If coding questions were the whole job, the 26B would win and this section would be short.

What actually keeps LFM3-1.7B relevant is the combination of a 262,144-token context and a 1 GB footprint. A model that can hold a large document and run on the device reading it is a different product from one that can hold the same document on a server. Liquid reports 65.56 on RULER at 128K, which is not a spectacular long-context score — Gemma 4 26B A4B reports 81.4 on the same benchmark family — but it is measured at all, on-device, at a gigabyte.

And on instruction following the small model is not embarrassed: 96.66 on IFEval and 73.03 on IFBench are strong numbers for this size class, both vendor-reported. For a tool-calling or structured-output workload, that is closer to the metric that matters than GPQA Diamond is.

What the routing layer actually changes

Gemma 4 26B A4B is on the OrcaRouter catalogue — one API key reaches it alongside more than 200 other models, with provider list prices passed through at 0% markup, so a vendor price change lands the same day rather than waiting for a repricing cycle. That matters here more than it usually would, because this is a model whose economics are entirely about provider pricing: the weights are free, so the bill is whatever the cheapest competent host charges, and that number moves.

Automatic failover is the other half. A 26B mixture-of-experts model with 256K context is exactly the kind of workload that hits capacity walls at peak, and routing across providers means a single host's bad afternoon is not your outage. LFM3-1.7B does not need any of this, because it runs on hardware you control and has no provider to fail over from. That is not a point in its favour or against it — it is a consequence of choosing the other recipe.

The honest framing of our role: we route the large sparse model, we do not serve the small dense one, and the decision between them is not one a router can make for you.

Deciding in one pass

If the deployment target has less than 20 GB of memory — a phone, a laptop, a Jetson, an AI PC — then Gemma 4 26B A4B is not a candidate and the comparison is over. Take LFM3-1.7B, plan retrieval around the knowledge gap Liquid itself flags, and use it for tool calling and structured extraction where its numbers are genuinely competitive.

If you are serving from a GPU and the workload is knowledge-heavy, multimodal, or needs the 82.3 GPQA Diamond and 82.6 MMLU-Pro class of reasoning, Gemma 4 26B A4B is the better model and the 18 GB is the price of admission. Apache 2.0 removes the licensing conversation entirely, which for a large organisation is worth more than a few benchmark points.

If you are building a product that ships to both — an on-device assistant that escalates hard queries to a server — the two are not competitors at all. They are the two tiers of one architecture, and the interesting engineering question is where you draw the escalation line, not which model wins a table.

The open question is not capability, which is settled in Google's favour, but whether a 1 GB model with a 256K context is good enough for the narrow agentic tasks most on-device products actually need. Liquid's own model card is unusually candid that it is not a reasoning model. That candour is worth more than the LiveCodeBench gap, because it tells you which half of your workload to send where.