Liquid AI's six new open-weight models reuse a 1.7B-parameter backbone across modalities, with practical local deployment paths and a consequential commercial license limit.
Building a small language model for one task is no longer especially unusual. Building several useful models for different kinds of input, while keeping their language core small enough to customize on one GPU, is a more interesting design problem. Liquid AI's LFM3 release on October 27 takes that route. It introduces six roughly two-billion-parameter models for text, vision, audio, combined audio-visual interaction, and structured decisions, all derived from one 1.7B-parameter base.
The checkpoints are available on Hugging Face. That makes this more than a preview announcement: developers can inspect the model cards, download weights, and use the published inference examples. The release is best described as open-weight, however, not unconditionally open source. Its model license has a commercial revenue restriction that matters to downstream adopters.
The core LFM3-1.7B model card describes a 24-layer architecture with 13 gated short-convolution layers, five sliding-window attention layers, and six global attention layers. The sliding-window layers attend within 256 tokens; the global layers provide access to more distant context. Liquid also adds head-wise gating, partial rotary position embeddings in global attention, and normalization around each block.
This mix is meant to reduce the cost of processing long sequences without giving up global access entirely. Convolutional layers can handle local patterns without maintaining a full attention cache for every token. Global attention still has a cost, so the design is not equivalent to constant-memory inference, but using fewer global layers changes the balance between memory traffic and expressive capacity.
Liquid reports 22 trillion pretraining tokens for the base model, with the final 3.5 trillion emphasizing curated material and agentic traces while extending the context window to 256K tokens. The company says its architecture search considered 14 hardware and backend combinations, including phones, laptops, CPUs, GPUs, and edge accelerators. Those are details of the team's reported training process, not a publicly reproduced training run.
The more distinctive decision comes after pretraining. Instead of releasing unrelated text, speech, and vision foundations, Liquid adapts the same language backbone with modality-specific components. The vision model adds a visual encoder and accepts images and video. The audio model adds a causal audio encoder, decoder, and speech codec. The omni model combines these paths to accept text, images, video, and sound, producing text or spoken replies. Two decision models are trained to answer specified questions as structured outputs rather than generate a long conversational response.
Shared ancestry does not mean a single checkpoint dynamically becomes all six models. The published variants have separate weights, components, and task interfaces. It does mean the project can reuse a common architectural and training foundation across applications that would otherwise require different model families.
The release includes more than a model diagram. The text checkpoint's file tree contains safetensors weights, configuration, tokenizer, chat template, and Python implementation files. Its model card documents Transformers, vLLM, SGLang, GGUF for llama.cpp and related local runtimes, MLX for Apple Silicon, and ONNX variants. The text model's BF16 repository is about 3.5 GB; Liquid estimates roughly 1 GB for a 4-bit version. That smaller figure concerns quantized model storage, not the total memory required for every runtime and context length.
The text model also supports deferred tool definitions: a host application can search a tool catalog and insert selected schemas into the prompt later, instead of putting every available function in context at once. The model emits calls, but the application must parse, authorize, and execute them. This distinction matters when the model is described as agent-ready. A trained tool-call format is not an autonomous or secure execution environment.
The omni card is similarly specific. It describes 16 kHz audio input, 24 kHz speech output, video sampled at two frames per second, and a 32K-token context window. Its example for video with sound requires explicit flags to extract the audio track and interleave it with frames. Without those flags, the video path sees images but not the soundtrack. The card provides both Transformers and GGUF/llama.cpp paths, although supported output modes differ by runtime.
Fine-tuning is part of the release's argument. Liquid provides task-specific notebooks for supervised fine-tuning, preference optimization, reinforcement-learning-based tool use, and multimodal adaptation. A separate Liquid Finetune source repository exposes real training orchestration, evaluation, and export code under MIT, but its current README still describes LFM2 and uses LFM2 in its quickstart. It should not be taken as proof that every LFM3 training recipe has been integrated into that standalone tool. The release notebooks and individual model cards are the more direct LFM3 instructions.
Liquid's text model card reports 38.42 on WebArena-Verified against 3.02 for LFM2.5-2.6B, and 71.39 on BFCL V4 against 55.89 for its predecessor. It also reports a 65.56 score on RULER at 128K context. The same table shows Qwen3.5-9B ahead on some long-context and coding tests, including RULER 128K and SWE-bench Verified. LFM3 is not uniformly stronger than larger alternatives.
Importantly, the card describes much of the evaluation setup: vLLM serving in BF16, specified context limits, default sampling parameters, and task-specific step or token budgets. That is more useful than a bare leaderboard, but the numbers remain vendor-run evaluations. No independent benchmark or model execution was performed for this article.
For edge inference, Liquid compares Q4_0 GGUF checkpoints in llama.cpp at 32,768 tokens of context, batch size one, and 100 generated tokens, on an AMD Ryzen AI Max+ 395, Apple M5 Max, and iPhone 17 Pro. The company reports at least 2.5 times the prefill throughput and 1.8 times the decode throughput of the compared models on those devices. The LFM3 run used a build with LFM3 support while competitors used a specified llama.cpp release. Hardware, runtime version, quantization, and prompt length all affect whether those gains transfer to another setup.
There is a separate reproducibility boundary around the original training. The release provides weights, architecture implementation, inference instructions, model cards, and adaptation examples. Those artifacts let developers test the checkpoints and reproduce particular deployment experiments. They do not, on their own, establish that an outsider can recreate the 22-trillion-token pretraining run or the entire post-training pipeline from raw data.
The word open needs qualification here. The model cards identify the LFM Open License v1.0, a custom license based on Apache 2.0 but with an additional commercial-use condition. Under its terms, an entity with $10 million or more in annual revenue is not granted commercial-use rights by the free model license and must arrange separate terms with Liquid AI. The threshold concerns the legal entity's revenue, not revenue earned specifically from an LFM-based product. The license includes provisions for qualifying nonprofits engaged in noncommercial or research use, and it does not require public release of fine-tuned derivatives.
That is a meaningful restriction on use, so the weights should not be described as Apache-licensed or as open source under the usual unrestricted-use definition. The accompanying software can have a different license: for example, the Liquid Finetune code repository is MIT-licensed. Software license and model-weight license must be evaluated separately.
For an individual developer or small organization, LFM3 offers an inspectable collection of compact models with concrete local inference and customization routes. For larger commercial organizations, the licensing decision comes before deployment. For everyone, the next useful evidence is independent testing: the same models, on named devices and workloads, against appropriate baselines, with output quality measured alongside latency and memory. LFM3's practical contribution is a coherent small-model family spanning modalities; the published artifacts make that proposition testable without making its performance claims automatically settled.
