What Liquid AI just shipped
Liquid AI released two new encoder models today: LFM2.5-Encoder-230M and LFM2.5-Encoder-350M. These aren't decoder LLMs—they're bidirectional encoders in the BERT tradition, designed for classification, extraction, routing, and other high-volume understanding tasks that run all day on CPU.
The headline: they match or beat larger encoders on standard benchmarks while staying fast as context grows. At 8,192 tokens, LFM2.5-Encoder-230M runs about 3.7× faster than ModernBERT-base on CPU. That's the difference between 90 seconds and 28 seconds for a single forward pass on a contract-length document.
This matters because most production NLP isn't generative chat. It's intent routing, PII detection, policy linting, and classification jobs that need to run cheaply, constantly, and on hardware you already have. Encoders are the workhorses here, and making them fast at long context unlocks a new class of deployments.
Why general-purpose encoders still matter
Liquid released LFM2.5-Retrievers last month, optimized for multilingual search. These new encoders come from the same model family but serve a broader purpose: they're pre-trained with a masked-language modeling objective, so you can fine-tune them for classification, token-level tasks, and retrieval alike.
BERT established this architecture class in 2018. ModernBERT pushed accuracy, speed, and context length further in late 2024. LFM2.5-Encoders take the next step by building on the LFM2 backbone, where computational cost grows sub-quadratically as inputs lengthen.
The use cases are everywhere: safety filters that scan every message, intent routers that decide which agent handles a request, compliance scanners that check contracts token by token. These jobs don't need generation—they need fast, cheap understanding at scale.
Architecture: turning a causal decoder bidirectional
Liquid initialized the encoders from their respective LFM2.5-230M and LFM2.5-350M decoder backbones, then converted each causal model into a bidirectional encoder:
- Bidirectional attention mask: each token now sees tokens on both sides, not just the preceding context.
- Non-causal short convolutions: symmetric padding so each token's convolution mixes neighbors from both directions.
- Masked language modeling: 30% of tokens are masked during training.
Training happened in two stages. First, a short-context (1,024 tokens) masked-language objective on a large web corpus to build general competence. Then, context extension to 8,192 tokens on a full data mix with factual, legal, and multilingual content.
This two-stage approach is now standard for long-context models, but the LFM2 backbone's architecture—designed for sub-quadratic scaling—is what enables the CPU speed gains downstream.
Benchmark results: competitive with much larger models
Liquid fine-tuned both encoders fully on 17 tasks from GLUE, SuperGLUE, and multilingual classification benchmarks. They report mean scores across five held-out seeds, so the numbers are stable.
LFM2.5-Encoder-350M ranked fourth out of 14 models tested. The three ahead of it are all larger—including a 3.5B model nearly 10× its size. LFM2.5-Encoder-230M beats ModernBERT-base and every EuroBERT model tested, despite being smaller than most.
Both encoders also score well above Liquid's own LFM2.5-Retrievers on these tasks, which makes sense: the retrievers are specialized for search, while the encoders are general-purpose.
The takeaway: you're not sacrificing accuracy to get speed. These models hold their own against larger, slower alternatives.
CPU inference speed: where the advantage shows up
The CPU comparison is where things get interesting. Since both LFM2.5-Encoders and ModernBERT support 8,192-token context, Liquid measured throughput across the full range.
LFM2.5-Encoder-230M is the fastest at every sequence length on CPU—even faster than the smaller ModernBERT-base at short inputs. As input length increases, ModernBERT's throughput drops sharply, while the Liquid encoders rise into the mid-range before tapering.
At 8,192 tokens, ModernBERT-base takes over 90 seconds per forward pass versus about 28 seconds for LFM2.5-Encoder-230M. That 3.7× speedup means you can scan a full contract, transcript, or support thread in under 30 seconds on a laptop CPU.
On GPU, a similar pattern holds with a smaller margin. ModernBERT leads below roughly 1,000 tokens on Apple silicon. The Liquid encoders take over from about 2,000 tokens onward. For long inputs, they're the faster choice; on CPU, dramatically so.
Live demos running on CPU-only Hugging Face spaces
Liquid built five demos from fine-tuned encoders, all running in CPU-only Hugging Face Spaces:
- Zero-shot prompt routing: define routing lanes as free text; the model scores the prompt against every lane in one pass.
- Zero-shot policy linting: check text against company rules, also written as free text, scoring every token against every rule.
- Spell checking: correct misspellings token by token.
- PII detection: spot and remove 40 kinds of personal information across 16 languages.
- Masked-diffusion text generation (bonus): run the encoder as a chatbot that generates text by iteratively unmasking instead of left-to-right.
The policy linting demo is the one I'd pay for. Right now there's nowhere good to put a guardrail that runs on CPU inside the same sandbox as an agent—it either goes out to an API or doesn't happen. A fast, local encoder that can score every token against a ruleset changes that.
How to use and fine-tune
Reach for an LFM2.5-Encoder when you have a high-volume understanding task that runs constantly and needs to stay cheap and fast: classification, routing, extraction, scoring. For these jobs, a fine-tuned encoder is smaller, faster, and far cheaper to run than a generative LLM.
Between the two sizes:
LFM2.5-Encoder-350M: choose it when accuracy matters most.LFM2.5-Encoder-230M: choose it for tighter hardware or higher throughput.
Loading and running is standard transformers:
from transformers import AutoModelForMaskedLM, AutoTokenizer
import torch
model_id = "LiquidAI/LFM2.5-Encoder-230M"
tok = AutoTokenizer.from_pretrained(model_id, trust_remote_code=True)
mlm = AutoModelForMaskedLM.from_pretrained(model_id, trust_remote_code=True)
text = f"The capital of France is {tok.mask_token}."
enc = tok(text, return_tensors="pt")
with torch.no_grad():
logits = mlm(**enc).logits
pos = (enc["input_ids"][0] == tok.mask_token_id).nonzero()[0].item()
print([tok.decode([t]).strip() for t in logits[0, pos].topk(5).indices.tolist()])
# -> ['Paris', 'Strasbourg', 'Paris', 'Lyon', 'Versailles']
For downstream tasks, load the encoder body and attach your own head. Liquid provides a fine-tuning tutorial that walks through adapting the model for long legal documents at 8k context.
Open questions and what's missing
The CPU benchmarks don't specify which CPU was used. Was the 28-second figure at 8k tokens a single sequence on Apple silicon, or a many-core x86 server? That matters for the "scan a contract" use case, because in practice you're scanning forty thousand of them.
trust_remote_code=True is the other thing. There's no ONNX Runtime or OpenVINO path yet, so anyone following this post is on PyTorch eager mode on CPU. A decent chunk of that 28 seconds is probably eager overhead rather than the architecture itself. Plans for int8 quantization or ONNX exports would be worth knowing—that's what people serving these all day are going to need.
One commenter on the blog offered to run the latency sweep on bare-metal EPYC at 16, 64, and 128 vCPU to clarify whether "the hardware you already have" means a laptop or a server. That's the kind of detail that matters for production planning.
Why this matters
Encoders are having a quiet moment. Everyone's talking about frontier LLMs, but most production NLP is still high-volume classification, routing, and extraction. These jobs run constantly, need to stay cheap, and increasingly operate on longer inputs—support threads, contracts, transcripts, policy documents.
Liquid's contribution here is making long-context encoders fast enough to run on CPU without sacrificing accuracy. The LFM2 backbone's sub-quadratic scaling is doing real work. If you're building intent routers, compliance scanners, or safety filters that need to run all day on the hardware you already have, these models are worth a look.
Both models are open-weight and available on Hugging Face today: LFM2.5-Encoder-230M and LFM2.5-Encoder-350M. The demos run in your browser, no setup needed. The fine-tuning tutorial is up. Now go ship something.