A Faster Encoder, If Your Inputs Are Long Enough

Liquid AI published two encoder models on Hugging Face today: LFM2.5-Encoder-230M and LFM2.5-Encoder-350M, roughly 229.7M and 354.5M parameters, both handling an 8,192-token context. The headline is a roughly 3.7x speedup over ModernBERT-base on CPU at long context: the 230M gets through 8,192 tokens in about 28 seconds where ModernBERT-base needs more than a minute and a half.

For teams running classification, routing, or PII detection over long documents without a GPU, that is a real cost line moving — assuming the license lets you get that far, which above $10M in group revenue it does not.

What was built

Both models began as LFM2 decoders converted into bidirectional encoders: bidirectional attention masks, symmetrically padded short convolutions, and retraining with masked language modeling at a 30% masking rate. Converting an existing decoder line rather than pretraining fresh explains why two sizes arrived at once.

On quality, the release reports 17 tasks from GLUE, SuperGLUE, and multilingual classification across 14 models. The 350M places fourth at 81.02, behind ModernBERT-large at 81.68; the 230M places sixth at 79.29, ahead of ModernBERT-base at 78.19 and every EuroBERT in the comparison. A mid-table placing published alongside the speed numbers is more useful than a leaderboard win: the speedup is not being paid for out of accuracy.

Hold the sizes against those scores. ModernBERT-base is 149M parameters, published in December 2024 with a native 8,192-token sequence length; the LFM2.5 model that beats it carries 229.7M, and ModernBERT-large at 395M still leads the 354.5M. Quality tracks parameter count here. What is new is throughput, not score.

Where the speedup lives

The 3.7x figure describes long context specifically, and the release is direct about what happens elsewhere. On an Apple GPU, ModernBERT-base leads below roughly 1K tokens and the LFM2.5 encoders take over from about 2K. On CPU the 230M is reported fastest at every length tested, including short inputs. So the accurate version is narrower than the headline: broad on CPU, and on GPU a long-sequence win with a crossover between 1K and 2K tokens.

The multiple is not stable across Liquid AI's own pages either. The launch post says about 3.7x, which is what 28 seconds against more than a minute and a half gets you; both model cards say 3.3x at 8K on CPU. The gap is small and neither figure is wrong on its face, but a headline number that changes with the page you opened is not the number to plan around.

The crossover is, and that is this post's claim: for any team that clears the license and runs on GPU, where inputs sit relative to 1K-2K decides whether this release matters, not the multiple. On CPU there is no line, only a margin that varies with length. On GPU a pipeline chunking documents into 400-token passages stays behind ModernBERT-base; a log-triage system on 4K windows clears the crossover. What would show the claim wrong is a GPU deployment above 2K where swapping in the 230M changes nothing measurable, because encoder throughput was never the binding constraint: the queue behind it was.

The license, and the number in it

The launch post calls both encoders open-weight and names no license. The model repositories name one: the LFM Open License v1.0, recorded in the repository metadata as lfm1.0. That is one fetch past the announcement, and it is the most consequential thing in this release.

Open the text and it is Apache 2.0's skeleton — same definitions, same redistribution and liability sections — with one clause inserted. Section 5 conditions commercial use on the licensee not exceeding a Threshold, defined as annual revenue of 10 million United States dollars or more. Commercial use above that line is not licensed. Legal Entity sweeps in parents, subsidiaries, and anything under common control, so the test is group revenue, not the revenue of the team doing the deploying. Both the copyright grant in Section 2 and the patent grant in Section 3 are explicitly subject to that limitation.

Under $10M this is effectively Apache 2.0. Above it, the benchmark discussion is moot: the models are not licensed for your commercial use at all. The text names no route out — no contact address, no mechanism for separate terms — and whether Liquid AI sells commercial terms is a question for Liquid AI. Open-weight is not open-source. This license is short and mostly familiar, which makes the review fast; it does not make the answer yes.

What the release still does not tell you

No specific chip is named on either side — Apple hardware for the GPU results, a laptop CPU for the rest — so there is nothing to match against your own machines. No batch size either.

The retrieval situation is more interesting, and it is not an omission. Both model cards list retrieval and reranking among the intended downstream applications, dense and ColBERT-style setups included; the evaluation published with the release is classification. The gap is between stated intent and published evidence, not a missing use case. The incumbent has no such gap: the ModernBERT-base card publishes BEIR and MLDR results alongside CodeSearchNet and StackQA. One side has measurements, the other an intent list.

The pattern is the one described in why enterprise AI doesn't ship: the model is rarely the thing that blocks you. Here the fastest number in the release is the least decisive one, and a revenue clause in a text file nobody opened settles more than the benchmark does.

What to do about it

Open the LICENSE file in the model repository and put your group's annual revenue against the $10M line. Above it, stop — there is nothing to evaluate until someone at Liquid AI says otherwise in writing. Below it, or as a 501(c)(3) using these for research, carry on.

Then measure rather than migrate. Take a week of production inputs, plot the token-length distribution, and check where the mass sits against the 1K-2K crossover. On GPU, short traffic means the release changes little; on CPU the win shrinks but survives. If a long-document tail is driving your compute bill, benchmark the 230M on your own hardware at your own sequence lengths, because the published numbers name no machine. If your case is retrieval, run your own evaluation on your own corpus — an intended-use list is not a measurement.

What you are permitted to deploy and what has actually been measured are the two questions behind every buy, build, or fine-tune decision, and both are cheaper to answer before the engineering than after.