LFM2.5 encoders ask a simple question: do you need prose?

Many text workflows ask a generative model to write an answer that downstream code immediately reduces to one label, text span, route, or score. Liquid AI’s July 28 release of LFM2.5-Encoder-230M and LFM2.5-Encoder-350M gives teams two new text encoders to test for those bounded text-understanding tasks. The practical question is whether one existing stage needs generation at all.

Output shape changes the model class worth testing, but a smaller model does not establish an operating advantage by itself. This article explains how these encoders work, what Liquid AI released, what a team must still build, and how to compare one current stage without assuming gains in quality, cost, throughput, latency, or privacy.

The retained output should determine the first model class you test

Start with what the next system actually consumes. A label assigns an input to a defined class, such as a support queue. A span identifies an exact section of the source text, a route selects the next destination, and a score places the input on a defined scale. These outputs have bounded forms even when the source document is long.

A workflow needs generation when its useful product is an explanation, synthesis, draft, or answer whose content changes with the case. Open-ended instructions, outside knowledge, or judgment can also require generation. A JSON response does not make the decision bounded if its label set or reasoning requirements keep changing.

The distinction becomes useful when the workflow discards the prose. If an application prompts for a justification, parses the response, and retains only billing, technical, or account, the justification has no downstream value unless a reviewer uses it. The label set, its boundary cases, and the cost of a wrong route should define the comparison.

Output shape alone does not select a winner. Local examples may be sparse, labels may be inconsistent, or rare errors may require broader context and instruction following. It does keep a team from treating every text problem as generation before testing a more direct model class.

A bidirectional encoder turns context into a task-specific prediction

A token is a word or word part that the model processes. During training, a bidirectional masked-language encoder hides some tokens and predicts them from the tokens on both sides. This objective produces contextual representations for each token and the whole input. A generative model usually predicts the next token from the sequence before it and repeats that step to produce new text.

The encoder representation is an intermediate result. A task-specific head is a learned output layer attached to the encoder for one job. A classification head converts a document representation into probabilities over known classes; a token-classification head assigns labels to tokens for span extraction; a regression head produces a score.

Fine-tuning trains that head and usually updates the encoder with labeled examples from the intended task. The head gives the model an output shape, while the examples teach the local meaning of each output. A base masked-language encoder therefore does not become a production router, policy checker, personally identifiable information detector, extractor, or classifier merely because those uses appear in demonstrations.

This mechanism changes what the team owns. A prompt can describe a new category at runtime, while a fine-tuned head learns a fixed output definition. A change to a class or its boundary can require revised label definitions and labeled examples. Support for another language can require labeled examples in that language. Both changes can require another training run and evaluation.

Liquid AI released two 8,192-token base encoders

In its release article, Liquid AI presents LFM2.5-Encoder-230M and LFM2.5-Encoder-350M as general-purpose bidirectional masked-language encoders. The exact LFM2.5-Encoder-230M model page reports about 229.7 million parameters, and the exact LFM2.5-Encoder-350M page reports about 354.5 million. Both model cards state an 8,192-token context and name 15 languages.

The loading examples on those two pages use Liquid AI’s custom model classes with trust_remote_code=True. This setting permits model-repository Python code to run locally. Teams must review and pin that dependency.

Liquid AI reports that the 350M encoder ranks fourth among 14 evaluated models across 17 GLUE, SuperGLUE, and multilingual tasks. It also reports that the 230M model beats ModernBERT-base and the evaluated EuroBERT models under its evaluation setup. These are Liquid AI results, not independent production measurements.

The latency claim needs the same boundary. At 8,192 tokens, Liquid AI reports an approximately 28-second CPU forward pass for its 230M encoder and more than 90 seconds for ModernBERT-base, which it describes as about 3.7 times faster. The rendered release does not name the CPU, and no independent production benchmark was found for these models.

Liquid AI published an Apache-2.0 evaluation harness with task and fine-tuning code. The repository intentionally omits the reported result artifacts, so it does not make the ranking independently reproducible. A separate fine-tuned PII demonstration describes 16 languages; that demo claim does not change the 15 languages on the base model cards.

The model download leaves the team with the implementation bill

The first cost is labeled data with stable definitions. Examples must include difficult boundaries and cases that should go to a person. If reviewers cannot apply the label definitions consistently, a fine-tuned model will learn that uncertainty.

Error policy comes next. For each class, a false positive assigns that class to an input that does not belong there; a false negative misses an input that does. In single-label routing, one wrong route is a false positive for the selected queue and a false negative for the correct queue. Because these errors can have different consequences, do not rely on one accuracy number when a missed urgent ticket and an unnecessary urgent escalation affect staffing, response time, or customers differently.

Fine-tuning needs a task head, training code, held-out data, and a pinned model artifact. Our review of targeted open-model training economics explains why training can be only part of the expense. Labeling, review, integration, retraining, and ownership remain.

Deployment adds more work. The team must review and pin the custom code, maintain the runtime and serving process, measure the actual hardware, and handle timeouts or outages. An 8,192-token context window states an input limit; it does not guarantee acceptable memory use, latency, throughput, or quality.

Monitoring must stay attached to the task. Owners need per-class error rates, score or probability drift, input changes, escalation volume, and samples of accepted and rejected results. They must decide when a new category or error pattern requires relabeling and retraining.

The evaluation harness is Apache-2.0, while the model uses LFM Open License v1.0. Its commercial-use terms include a $10 million annual-revenue boundary. An affected team should send the intended use through legal or procurement review; the harness license does not change the model license.

A local comparison should price the result the workflow accepts

Choose one repeated stage with an observable final output. Freeze representative local inputs, including common cases, ambiguous boundaries, minority classes, long documents, and manual-review cases. Run both candidates against the same inputs and acceptance rules. Use the same hardware when both run locally; otherwise, record each complete deployment path.

Judge each candidate by the retained output. For each class, precision is the share of inputs assigned to that class that belong there, and recall is the share of inputs in that class that the system finds. Span extraction needs exact-match or overlap measures tied to the fields the application uses. For a continuous score, measure prediction error in the units the workflow uses. If a probability score drives an action, calibration checks whether predicted probabilities match observed rates; error costs help set the decision threshold, which is the cutoff that turns the score into an action. A generative explanation gets no extra credit when nobody reads it.

Convert mistakes into workflow consequences before comparing efficiency. Count false positives that cause review or wrong routing, false negatives that miss action, and the correction work each path creates. Measure end-to-end latency from input arrival to the accepted result or final fallback decision; report the median as p50 and the 95th percentile as p95. Report sustained throughput as completed inputs per unit of time under representative load. Calculate total cost per accepted result by dividing all costs assigned to the comparison period by the number of results that meet the acceptance rules. Separate observed infrastructure, review, and correction costs from estimates for training, deployment, and maintenance, and state each amortization assumption.

Thresholds exchange one kind of error for another. Test the proposed threshold on held-out data, separate from the training examples. Keep a manual or existing-model path for uncertain cases, and measure its use instead of treating fallback as free capacity.

This is a production decision, not an attempt to reproduce a vendor chart. The method in our production AI model evaluation guide applies here: define what must remain true, keep the input and acceptance criteria stable, and compare the full path that produces an accepted result.

Choose an encoder only when the output and ownership can stay bounded

Test an encoder when the stage ends in a stable label, span, route, or score; representative labeled examples exist; error costs can be measured; and an owner can maintain it. If the team cannot state the output classes, error costs, and owner, it should define the stage before changing models. Adopt the encoder only if local results preserve task quality and improve the operating measures that justified the test. Liquid AI’s specifications do not settle that decision.

Keep generation when the useful output is prose, synthesis, explanation, or adaptive judgment, or when the label set changes too quickly to retrain. A hybrid path can reserve generation or human review for ambiguous cases, but the handoff needs its own measurements. Our earlier article on Liquid AI’s generative tool-selection model covers that different job; generative tool choice is distinct from a fixed head on a text encoder.