Many model announcements emphasize scale. Liquid AI's June releases went in the other direction: small, task-focused models intended to run on consumer and edge hardware.
LFM2.5-230M
Released 25 June 2026. Liquid AI's smallest model to date: 230 million parameters, text only, open-weight, with both a base checkpoint for fine-tuning and an instruction-tuned version.
The pitch is deliberately narrow, and Liquid says so. This is not a general reasoning model. It is built for tool use and data extraction on edge hardware, and the framing is a feature rather than a hedge.
Architecturally it is built on LFM2, a hybrid that interleaves gated short-range convolution blocks with grouped-query attention. Context runs to 32,768 tokens. Liquid reports pre-training on 19 trillion tokens including a 32K context extension phase, with post-training in three stages: supervised fine-tuning distilled from the larger LFM2.5-350M, direct preference optimisation, and multi-domain reinforcement learning.
Liquid reports 213 decoded tokens per second on a Galaxy S25 Ultra and 42 on a Raspberry Pi 5, using 4-bit CPU inference with a 2K input. Its Flash Attention setting differs by device. These measurements describe the vendor's selected setup; they do not establish speed or extraction accuracy for a different computer and task.
Runtime support is unusually broad at launch: llama.cpp, MLX, vLLM, SGLang, ONNX, and NexaSDK, with GGUF builds published.
The repository carries the custom LFM Open License v1.0. It defines a $10 million annual-revenue threshold and limits its commercial-use grant by that threshold. Review its definitions and commercial-use section for the entity using the model; a GGUF conversion does not remove those conditions.
The retrievers
Released a week earlier, on 18 June 2026, and more directly relevant if you run local document search: LFM2.5-Embedding-350M and LFM2.5-ColBERT-350M.
Both are 350 million parameters, both built from LFM2.5-350M-Base, and both are the first bidirectional members of the LFM family. Liquid adapted the causal decoder into a bidirectional encoder with a small set of architectural patches: replacing the causal attention mask with a bidirectional one, and making the short convolutions non-causal so they mix local information symmetrically around each token rather than only from the past.
From that shared backbone the two models differ only in how they represent text.
LFM2.5-Embedding-350M pools each document into a single vector. This is a candidate when index size and query cost matter; measure retrieval quality on your documents.
LFM2.5-ColBERT-350M keeps per-token vectors and matches queries using MaxSim late interaction. That creates a larger index. Liquid reports higher scores on its selected retrieval evaluations; compare relevant known-answer searches before choosing it for your collection.
Both cover 11 languages: Arabic, German, English, Spanish, French, Italian, Japanese, Korean, Norwegian, Portuguese, and Swedish. Liquid positions them for short-context search specifically, naming product catalogs, FAQ knowledge bases, and support documentation as the target.
The numbers
All vendor-reported, from Liquid's own evaluation.
On NanoBEIR Multilingual Extended, averaged across the 11 languages at NDCG@10, ColBERT scores 0.605 and Embedding 0.577. The nearest comparison in Liquid's table is Qwen3-Embedding-0.6B at 0.556, and Liquid's own previous LFM2-ColBERT-350M at 0.540.
On MKQA-11 at Recall@20, the two land nearly together, at 0.694 and 0.691.
The latency figures are the ones worth internalising for local use. Running under llama.cpp on a MacBook M4 Max at FP16, with a 32-token query and 256-token documents: query embedding at 7.3 milliseconds median for the embedding model, and 8.2 milliseconds median for ColBERT query embedding plus MaxSim with documents cached. Uncached, ColBERT rises to 34.3 milliseconds.
GGUF builds are published for both. The tested package, precision, device, document length, and cache state still matter when comparing your latency.
Where these models can help
A document-search workflow needs a model to retrieve relevant passages as well as a model to answer from them. These compact retrievers are candidates for that first step. A published MacBook latency does not establish CPU speed on another machine, and the combined memory budget still includes the chat model, document index, and app.
Before changing an embedding model, create a separate test index or rebuild the collection through the app's supported path. Vectors from different embedding models are not interchangeable. Try several questions with known source passages and inspect which passages are retrieved before judging the generated answer.
Liquid has also published LFM2.5-Encoder-230M and LFM2.5-Encoder-350M. Their official model cards describe bidirectional masked-language-model encoders with 8,192-token context, support across 15 languages, and on-device use including CPU and WebGPU paths. These are foundations for classifiers, routers, entity extraction, retrieval, and similar task-specific systems, not ready-made chat models.