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, at 230 and 350 million parameters, both handling an 8,192-token context. The number attached to the release is a roughly 3.7x speedup over ModernBERT-base on CPU at long context. At the top of that range, the 230M model 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. It is also a number with a crossover point, and locating yours is most of the work.

What was built

Both models began as LFM2 decoders and were converted into bidirectional encoders: the attention masks were made bidirectional, the convolution padding was made symmetric, and the models were retrained with masked language modeling at a 30% masking rate. This is a conversion of an existing decoder line rather than a fresh pretraining run, which mostly explains why two sizes arrived at once.

On quality, the release reports 17 tasks spanning GLUE, SuperGLUE, and multilingual classification. The 350M model places fourth among the 14 models evaluated. The 230M model comes in ahead of ModernBERT-base and ahead of every EuroBERT model in the comparison. The release does not claim a leaderboard win, and publishing a mid-table placing alongside the speed numbers is more useful than one would have been: it tells you the speedup is not being paid for out of accuracy.

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 is ahead below roughly 1K tokens, with the LFM2.5 encoders taking the lead from about 2K tokens onward. On CPU the 230M model is reported as fastest at every sequence length tested, including short inputs, where it edges out the smaller ModernBERT-base.

So the accurate version of the claim is narrower than the headline. On CPU the win looks broad. On GPU it is a long-sequence win with a crossover somewhere between 1K and 2K tokens.

That distinction is what decides whether this release is interesting to you. A retrieval pipeline chunking documents into 400-token passages sits well below the crossover. A contract-analysis or log-triage system feeding 4K-token windows sits above it. Same models, same benchmark, opposite conclusions — and the only way to know which case you are in is to look at the token-length distribution of your own traffic rather than the shape of the published chart.

What the release does not tell you

Several things a deployment decision needs are absent. The GPU results are attributed to Apple hardware, but no specific chip is named, and the CPU behind the 28-second figure is not identified at all — so there is nothing there you could match against your own machines. Batch size is not given either. The models are described as open-weight, but no license is named — the single detail most likely to stall an enterprise rollout, and it is not on the page.

There are also no retrieval numbers. These encoders are presented as separate from the LFM2.5-Retrievers line, and the evaluation shown is classification. If you were hoping to drop them into an embedding pipeline, this release does not measure that case.

None of this makes the results wrong. It makes them incomplete for the purpose of a migration decision, which is a different problem than an inflated claim and needs a different response. The pattern is the one described in why enterprise AI doesn't ship: the model is rarely the thing that blocks you, and an unnamed license will hold up a rollout long after the benchmark argument is settled.

What to do about it

If you run encoder inference on CPU today, this warrants a measurement rather than a migration. Take a week of production inputs, plot the token-length distribution, and check where the mass sits relative to that 1K-2K crossover. If most of your traffic is short, the release changes little for you and you can stop there. If you have a long-document tail driving your compute bill, benchmark the 230M model on your own hardware at your own sequence lengths, because the published numbers do not name the machine that produced them.

Then find the license before spending engineering time on either path. What you are permitted to deploy is the same question that governs every buy, build, or fine-tune decision, and it is considerably cheaper to answer first.