Liquid AI released two open-weight encoder models on Hugging Face on July 28, 2026: LFM2.5-Encoder-230M and LFM2.5-Encoder-350M. Both support an 8,192-token context, and at that full length a single forward pass takes ModernBERT-base over a minute and a half while the 230M model finishes in about 28 seconds, roughly 3.7 times faster. Across 17 tasks drawn from GLUE, SuperGLUE and multilingual classification, evaluated over 14 models, LFM2.5-Encoder-350M ranks fourth, and all three models ahead of it are larger. ASAP works from Liquid AI's official release post as the primary source to explain which workloads this changes the cost structure for.

There is a class of work that wants an encoder, not a generator

The point of this release is the choice of target workload, not the leaderboard position. The uses Liquid AI names are intent routers, policy linters, PII detectors and text classifiers. What they share is that they run all day, on ever-longer inputs, usually on CPU. Liquid AI's argument is that for high-volume understanding tasks like these, a fine-tuned encoder is smaller, faster and far cheaper to run than a generative LLM, and it fits on the CPUs a team already owns.

This is precisely where practice has drifted over the past two years. Because classification, routing, extraction and scoring can each be expressed as a single prompt, pushing them into a generative model hardened into a default. But those tasks combine modest accuracy requirements with overwhelming call volume. A per-request cost gap that looks trivial becomes the monthly invoice once the component runs continuously. Encoders are drawing attention again not because they gained a new capability, but because agent architectures multiplied the number of thin decision layers every request has to pass through. Using a generative model as a gate does not survive scale.

Turning a decoder back into an encoder

Both models start from the corresponding LFM2 decoder backbones, LFM2.5-230M and LFM2.5-350M, and are converted with three changes: a bidirectional attention mask so each token sees both sides, symmetric padding on the non-causal short convolutions so each token's convolution mixes in neighbors on both sides, and masked language modeling with 30% of tokens masked during training. Training runs in two stages, first a short-context masked-language objective on a large web corpus at 1,024 tokens, then long-context adaptation to 8,192 tokens on the full data mix, strengthening factual, legal and multilingual competence.

Reusing existing decoder assets this way is worth reading as a cost decision. Rather than training an encoder from scratch, the team inherits representations from a same-family decoder and reorients them with a masking objective. The same passage explains why Liquid AI did not simply reuse LFM2.5-Retrievers, released a month earlier: the retrievers are specialized for multilingual search, while a general-purpose encoder pretrained with a masked-language objective can be fine-tuned for classification, token-level tasks and search alike. Search, in their framing, is only one of the things an encoder enables.

How to read the numbers

The firmest number is CPU latency. Because both encoders and ModernBERT support 8,192 tokens, the comparison runs across the full range, and at 8,192 tokens ModernBERT-base takes over a minute and a half per forward pass against about 28 seconds for LFM2.5-Encoder-230M. The 230M model is the fastest at every sequence length on CPU, including on short inputs where it beats the smaller ModernBERT-base. Liquid AI translates that into scanning or classifying a full contract, transcript or long support thread in under 30 seconds on a laptop CPU.

The quality numbers deserve more care. The 350M model places fourth among 14, with all three leaders larger, one of them a 3.5B model nearly ten times its size, and the 230M model beats ModernBERT-base and every EuroBERT model. Reporting the mean across five held-out seeds and open-sourcing the evaluation framework and raw results both raise confidence. But the ranking reflects scores obtained after fully fine-tuning each model on each task. The table describes the ceiling reachable with per-task fine-tuning, not out-of-the-box behavior, and adoption carries the separate cost of maintaining a fine-tuning pipeline per task.

Two more caveats. The GPU margin is much smaller: on the Apple GPU, ModernBERT-base leads below roughly 1K tokens and the LFM2.5 encoders take over from about 2K. The advantage is not "a fast encoder" in general but a narrow, well-defined claim about long inputs, especially on CPU. And the post does not name the processor used for the CPU latency measurements. The 3.7× ratio holds as a like-for-like comparison, but transferring the 28-second absolute figure to your own hardware has no basis in the published material.

What this looks like in practice

Two details matter for non-English deployments: multilingual tasks are part of the evaluation set, and the PII detection demo covers 40 kinds of personal information across 16 languages. The post does not break out per-language scores, so performance in any specific language cannot be confirmed from this document alone, and evaluating on your own data after fine-tuning is unavoidable.

Where the conditions do line up, the calculation is immediate. Document classification that cannot send data outside, support-log routing, internal policy checks: workloads that must run continuously on in-house CPU servers. These have often lost the automation queue to GPU budget or external API cost. Processing an 8K context on CPU in under 30 seconds changes that threshold.

The limits belong in the same paragraph. The post does not state a license name, and it does not cover ONNX or OpenVINO conversion paths that production serving usually depends on. The models are custom architectures loaded with trust_remote_code=True under PyTorch and transformers, which is a recurring blocker in internal deployment review. Check the license terms on the model card directly and test conversion into your target runtime before committing.

What to watch next

Whether this marks a genuine encoder revival turns on two things. One is fine-tuning cost: a base encoder yields general-purpose representations rather than task outputs, so how light that per-task step becomes will govern adoption speed. Publishing a fine-tuning tutorial on long legal documents at 8K context alongside the release suggests Liquid AI knows where the bottleneck is.

The other is the deployment path. An advantage measured on CPU is only realized inside the CPU runtime ecosystem, which is why the missing ONNX and OpenVINO paths drew immediate community comment. Whether these models land in real serving stacks over the coming weeks is a sharper test than their position in the benchmark table.

Source: ASAP analysis based on Liquid AI's official release post "LFM2.5-Encoders for Fast Long-Context Inference on CPU" (Hugging Face blog, July 28, 2026)