Liquid AI put six small multimodal models on one backbone. Test the edge claim

THE SIGNAL IN ONE SENTENCE

One backbone can start six models. It cannot make six deployment problems disappear. Liquid AI has released LFM3, a family of small open-weight models built from the same 1.7-billion-parameter base. The first release covers text, vision, audio, an omni model and two decision models, all in roughly the two-billion-parameter class. That is a genuinely useful shape. A product team does not always need one giant generalist waiting in a data center. A camera can use a vision model. A voice interface can use an audio model. A support router can use a decision model that returns probabilities instead of composing a paragraph. A device that must see, hear and speak can use the omni branch. The common base may simplify training, tooling and specialization across those jobs. It does not mean the jobs have identical memory use, latency, context, quality or failure modes. Liquid says the LFM3 base was pretrained on 22 trillion tokens. Its final 3.5 trillion tokens formed a curated mid-training stage with more agent traces and tool calls. The company describes a tri-hybrid architecture with 24 layers: 13 gated short-convolution layers, five sliding-window attention layers and six global-attention layers. The architecture search covered 14 combinations of devices and inference backends, from phones and a Raspberry Pi 5 to laptops, cloud processors, graphics processors and a Qualcomm neural-processing unit. That is more hardware awareness than a model release usually volunteers. The text model, LFM3-1.7B, has a 256,000-token context window. Liquid says a four-bit version occupies about one gigabyte of memory. Its model card lists formats for llama.cpp, MLX, ONNX Runtime, vLLM, SGLang and several lower-precision GPU paths. The vision model, LFM3-VL-2B, accepts text, images and video. The audio model, LFM3-Audio-2B, accepts text or audio and can return text, speech or both. Liquid says it supports speech tasks across 18 languages and can use spoken requests to generate tool calls. LFM3-Omni-2B combines text, images, video and audio and returns text or speech. Liquid presents it as one local model that can replace a chain containing speech recognition, a vision-language model, a language model and text-to-speech. The last two models are different animals. d1-2B and d1-Omni-2B are decision models. They receive a state and a list of questions, then return typed answers with probabilities in one forward pass. They can classify, select options, extract values, estimate ranges or point to objects. The omni version adds audio. That gives the family six released models: Text. Vision. Audio. Omni. Visual decision. Audiovisual decision. Liquid calls this every modality on one backbone. Read that as a lineage, not a universal binary. The text model has a 256K context window. The omni model card specifies 32K and describes it as non-reasoning. The d1 model card specifies 128K but warns that answers become less reliable beyond roughly 64K of state. Vision and audio encoders add their own memory, preprocessing and timing. A shared base does not make those differences footnotes. Those differences are the deployment. The same goes for the one-gigabyte claim. That figure applies to the quantized text model, not the entire family running every modality. It also describes model memory, not the full footprint of an application. A shipping product needs room for the runtime, key-value cache, tokenizer, modality encoders, audio codec, image buffers, operating system, application code and any tool state. A long prompt can change the memory picture dramatically. A phone can load a model and still become too hot, slow or battery-hungry to use. So build an edge acceptance test before celebrating the edge label. Start with the exact artifact. Record the model repository, revision, file hash, quantization, tokenizer, prompt template and any custom code. Open weights are inspectable and portable, but only if the deployed file can be traced to the tested file. Then lock the runtime. Name the framework and version, compiler flags, operator kernels, thread count, accelerator delegate and memory settings. A GGUF file in llama.cpp is not the same deployment as an MLX package on Apple silicon or an ONNX graph on a mobile neural-processing unit. Measure the whole application. Report cold-start time, warm-start time, peak resident memory, steady memory, first-token latency, tokens or decisions per second, battery drain, power draw and surface temperature. For audio, include time to first audible response. For vision, include image preparation. For video, include sampling, decoding and sustained frame handling. Do not average away the pauses. An assistant that responds quickly nine times and freezes on the tenth is not a fast assistant. Publish median, tail latency and failure rate across repeated runs. Test after the device has warmed up, after the battery drops and while the rest of the application is doing ordinary work. Next, test quality after compression. Four-bit quantization can make a model small enough to fit. It can also change output quality unevenly. Run the same acceptance set against the higher-precision checkpoint and every candidate quantization. Score the tasks the product actually performs, not one convenient benchmark average. Each modality needs its own failure book. For text, test instruction following, retrieval, structured output, tool selection and long-context degradation. Liquid's own card says the small text model is not recommended for agentic coding or complex multi-step reasoning and advises retrieval or search for knowledge-heavy work. For vision, vary lighting, camera angle, blur, text size, occlusion and objects absent from training examples. For audio, vary accents, languages, distance, background noise, overlapping speakers and non-speech sounds. Measure transcription separately from reasoning and speech generation. For omni, create cases where the audio and picture disagree. A model that sees one instruction and hears another needs a defined conflict rule, not vibes. For decision models, test calibration. A probability is useful only when it corresponds to reality. Group predictions by confidence and compare them with observed accuracy. Check abstention, class imbalance, missing fields and unfamiliar inputs. Liquid says d1 estimates are more dependable for counts and scores than for unconstrained quantities. Put that boundary into the product. Fine-tuning needs a receipt too. Liquid says each model can be adapted on a single graphics processor. Record the training data license, consent, exclusions, split, optimizer, random seed, base revision and evaluation set. Compare the specialized model with the untouched base on both the target task and a regression suite. Specialization that fixes one workflow and quietly breaks another is still a broken release. The local label needs a privacy test. Running model inference on a device can reduce the amount of raw data sent to a cloud service. It does not prove that the application stays offline. Check telemetry, crash reporting, update services, remote tools, speech services, analytics and fallback routes with network traffic observed. Then test the disconnected path deliberately. Remove the network. Restart the product. Run the full task. Confirm what works, what degrades and whether the interface explains the difference. Tool calling needs an authorization boundary. A local model can still delete a file, send a message or operate equipment if the surrounding software grants the action. Keep proposed tool calls separate from executed actions, validate arguments and require confirmation for consequential steps. Local inference changes where reasoning occurs. It does not make the reasoning trustworthy. Finally, review the license before the prototype becomes a product. The LFM3 weights use Liquid's LFM Open License v1.0. It is based on Apache 2.0, but it is not the standard Apache license. Liquid permits broad use, modification and distribution and does not require users to publish private fine-tunes. For commercial use, the free rights end when the legal entity reaches at least 10 million dollars in annual revenue. Larger businesses need a separate commercial license. That threshold belongs in the deployment checklist. Open-weight is a useful technical description. It is not a complete security review, a quality certificate or a promise of free commercial use at every company size. LFM3 is interesting because the family makes a practical wager. Instead of sending every sensory task to one enormous model, start with a compact common base, choose the branch that fits and specialize it close to the work. That could reduce cloud dependence, lower latency, preserve more data on the device and make custom models affordable for smaller teams. But the edge is where clean benchmark stories meet messy batteries, unusual microphones, budget cameras, thermal limits, old operating systems and humans who refuse to hold the phone at the approved angle. The edge claim becomes real only when the exact model survives the exact device. Bring a stopwatch, a power meter and a failure log. The backbone has already done its part.