Liquid AI releases LFM3: six 2B-class models share one backbone, with trade-offs for open-weight edge deployment
According to a Liquid AI blog post dated October 27, 2026, LFM3 unifies text, vision, audio, omni-modal and decision models on a shared 1.7B-class backbone, and the company claims all are open-weight and fine-tunable on a single GPU; developers must now weigh the omni-modal single-model route against specialized small models.
What changed
Liquid AI released the LFM3 family in an official blog post on October 27, 2026. According to the post, the family contains six 2B-class models: LFM3-1.7B (text), LFM3-VL-2B (text, image and video input), LFM3-Audio-2B (text and audio input, text and speech output), LFM3-Omni-2B (omni-modal input, text and speech output), plus decision models d1-2B and d1-omni-2B built on the vision and omni-modal branches; there is also LFM3-1.7B-Base for custom post-training. The vendor says all models branch from the same backbone, are available from Hugging Face and can be fine-tuned on a single GPU; the text model takes about 1 GB at 4-bit precision, and the backbone context window is extended to 256K tokens. The blog also gives several comparison numbers, such as LFM3-1.7B scoring 38.42 on WebArena-Verified versus 3.02 for the previous LFM2.5-2.6B; and LFM3-VL-2B's average across 62 vision benchmarks rising from 57.6 to 71.4. The vendor also claims that, per parameter, LFM3-1.7B matches LFM2-1.2B on short edge-device prompts and is about 25% faster when the context contains 8K tokens. All these figures are self-reported by the vendor and no third-party reproduction was provided.
What it means for developers
The core impact for developers is not simply another model, but a change in the granularity of model selection: running multimodality on-device used to mean chaining ASR, a vision-language model and TTS into a pipeline, and now the vendor offers an omni-modal single-model option; but it also keeps single-modality models, suggesting that merging modalities may not pay off in every scenario. Inference-side constraints also shift: the vision model requires transformers 5.21.0 or later, the audio and omni-modal models require 5.20.2 or later, d1 requires 5.19 or later, and most examples rely on trust_remote_code, so upgrading the framework and reviewing custom remote code become prerequisites for integration. On device memory, about 1 GB at 4-bit for the text model is a plannable figure, but the blog does not give VRAM or memory use for the vision or audio models, so the actual resource cost of video input and streaming speech output needs hands-on measurement. The blog emphasizes the efficiency of a new vision encoder and LiquidCodec, claiming audio time-to-first-token as low as 50 ms and speech synthesis at about 87x real time on a single CPU thread; such figures depend heavily on hardware and input length and should not be used directly for production capacity planning. The vendor also provides fine-tuning notebooks covering SFT, DPO, GRPO and continued pretraining, which for teams needing private terminology and tool calls is more worth getting working first than benchmark scores.
Integration and evaluation
Recommendation 1 (conditional analysis): if an on-device application must handle speech and imagery in the same request, first compare the omni-modal single model against a combination of an audio model plus a vision model. The trigger is that cross-modal association genuinely exists within a single request, for example asking a question by voice about a single frame; if audio and video are unrelated in the business context, specialized models are usually more controllable. Measurable criteria: compare time-to-first-token, end-to-end completion time and peak memory on the same batch of real samples, and check whether the omni-modal model shows clear degradation versus specialized models on pure-text or pure-speech subtasks. Recommendation 2 (conditional analysis): if you already run inference services based on the LFM2.5 family, do not switch directly on vendor numbers such as WebArena-Verified 38.42 versus 3.02; instead first run an A/B test with your own agent trajectories. The trigger is a workload dominated by long-context tool calling; the blog says the upgrade gains are mainly in agent tasks and long context, and the comparison on short prompts is per parameter, not an equivalence in absolute performance. Measurable criteria: on your own task set, record tool-call success rate, format-compliance rate and actual latency per thousand tokens, rather than looking only at public leaderboards. Recommendation 3 (conditional analysis): if structured judgments interest you more than text generation, evaluate whether d1-2B can replace a "small language model plus parsing post-processing" setup. The premise is that the business can accept calibrated probability outputs rather than natural language; if downstream needs explainable text, the d1 route is not suitable. Measurable criteria: use labeled historical tickets or invoices to compute calibration error per field, and compare the processing latency of a single forward pass with the existing pipeline.
Limits and open questions
The source is a vendor blog; benchmark scores, speed and memory figures are all self-reported, with no independent reproduction or full evaluation methodology, and the blog's internal comparison baselines (for example, some encoder comparisons using a uniform LFM2.5-230M language backbone) need to be checked yourself. The blog says all LFM3 models are open-weight, but the main text does not state specific license terms; open weights are not the same as an open-source license, and rights to commercial use, redistribution and publishing fine-tuned versions must be based on the model card and license text, not inferred from "the weights can be downloaded." The LFM3 models currently have no corresponding entries in the live KimiSeek catalog, and this version is not currently available on KimiSeek; the blog also offers no hosted API, so the stated availability refers to weight downloads on Hugging Face and local running. If hosted services or separate pricing appear later, the official pages should govern. In addition, the examples rely on trust_remote_code, so production environments need to audit the remote code themselves; the actual quality and resource use of video input, speech streaming, multilingual speech translation and similar capabilities are illustrated by only a few examples in the blog and need independent verification.
Illustrations from the original report
