Liquid AI LFM2.5: Small Local Models for Edge Tasks and Search
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 decode speeds of 213 tokens per second on a Galaxy S25 Ultra and 42 tokens per second on a Raspberry Pi 5. Those are the vendor's figures on the vendor's hardware, and we have not reproduced them. They are also the most interesting numbers in the release, because a model that does useful structured extraction at 42 tokens per second on a Pi opens a category of project that was not previously open.
Runtime support is unusually broad at launch: llama.cpp, MLX, vLLM, SGLang, ONNX, and NexaSDK, with GGUF builds published.
One caveat. The repository carries the custom LFM Open License v1.0. Its commercial-use grant applies below a $10 million annual-revenue threshold; entities at or above that threshold are not licensed for commercial use under that agreement. Read the actual license before building a product on the model.
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. Fastest search, smallest index. Pick it when index size and speed matter most.
LFM2.5-ColBERT-350M keeps per-token vectors and matches queries word by word using MaxSim late interaction. Higher accuracy and better generalisation, at the cost of a larger index. Pick it when accuracy matters more than storage.
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, which is what makes those laptop numbers reachable.
Why this matters more than the trillion-parameter news
A local document search stack has two halves, and the retrieval half has historically been the awkward one. The good multilingual retrievers were either large, English-centric, or both, and the small ones degraded sharply outside English.
A 350 million parameter model that runs on CPU at single-digit millisecond query latency, holds up across 11 languages, and ships as GGUF is a component you can actually build on. Paired with a small generation model, the whole pipeline fits on hardware people own.
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.
Related reading
*Model details and benchmark figures verified against Liquid AI's published announcements on 9 August 2026. All performance figures are vendor-reported and have not been reproduced by LocalLLMGuide.com. License terms were checked against the license file in the official model repository.*