Evidence at a glance
One Shared Backbone, Not One Universal Model
Liquid AI announced LFM3 on October 27, 2026, describing it as a new family of models for specialized intelligence across text, vision, audio, omni, and decision tasks. The goal is not to keep enlarging one general-purpose model, but to make smaller models fit particular inputs, data, and deployment environments.
That distinction shapes the family. Liquid AI says its first six models all derive from LFM3-1.7B-Base, then branch into text, vision, audio, omni, and decision uses. “Shared” refers chiefly to the training backbone and model lineage. It does not mean a single deployed model handles every workload. For engineering teams, choosing a branch is itself an architecture decision, and specialization remains work to be done rather than a capability guaranteed by the family name.
Speed Comes from Layer Roles and Hardware Search
LFM3-1.7B-Base has 24 layers: 13 gated short-convolution layers, five sliding-window attention layers, and six global-attention layers. Short convolutions handle local patterns, sliding-window attention limits interaction to a 256-token window, and global attention preserves the ability to connect more distant positions. Rather than replacing attention wholesale with a cheaper operation, the design assigns different sequence-processing roles to different layers.
Other changes target efficiency and stable inference. The short-convolution kernel grows from 3 in LFM2 to 7. Attention-head gates can suppress outputs that add little, partial RoPE is applied to the higher-frequency half of each head in global-attention layers, and Sandwich Norm normalizes both the input and output of each block. Liquid AI also says its hardware-in-the-loop architecture search spans 14 device and backend combinations, from phones and Raspberry Pi 5 to cloud hardware and the Qualcomm Hexagon NPU. The company reports that LFM3-1.7B matches LFM2-1.2B per parameter on short prompts and is about 25% faster with an 8K-token context. These figures indicate the design target and optimization direction, not a universal speed guarantee independent of hardware, quantization, or workload.
Modality-Specific Encoders Do the Multimodal Work
A shared language backbone does not erase the differences between vision and audio processing. LFM3's vision and audio branches add in-house Liquid encoders, while audio generation also uses LiquidCodec. The family is unified at the backbone level, not through one identical front end for every modality. Teams still need to choose a branch based on input type, latency requirements, and target hardware rather than parameter count alone.
The published design details show how this division affects sequence processing. The vision encoder combines convolution and attention. Liquid AI says it uses three times less compute than the SigLIP2 encoder in its previous LFM vision models. For video, it combines each pair of frames into one temporal slice to shorten the sequence. The audio encoder is causal, allowing the model to prefill while a user speaks, with a reported time to first token as low as about 50 milliseconds. LiquidCodec is reported to decode speech at roughly 87 times real time on a single CPU thread on an Apple M4 Max, with streaming support. These mechanisms target visual compute, video sequence length, and speech response latency respectively, but the company's reported results still need validation on the inputs and devices of the intended application.
Local Deployment Is More Than a One-Gigabyte Model
LFM3 links edge deployment with specialization. Liquid AI says the 4-bit text model occupies about 1 GB, its text context window reaches 256K tokens, and each model can be fine-tuned on a single GPU. For teams considering local tool use or long-context workloads, these are useful screening criteria. They also make “choose a branch, then adapt it with your data” a plausible engineering path.
But the 1 GB figure describes the text model at a particular quantization level, not the total memory required for an application that also includes vision or audio branches, caches, and its runtime environment. A 256K context window does not provide persistent memory or reliable tool execution by itself. The model still depends on surrounding systems for tool calls, context management, and orchestration. The single-GPU fine-tuning claim also lacks a common specification for memory, training time, and quality targets. Technical leads should treat these claims as constraints to verify for each branch, inference backend, quantization method, and training task, not as ready-made deployment guarantees.
Test Performance Claims Against the Actual Workload
LFM3-1.7B was pretrained on 22 trillion tokens. Liquid AI says roughly the final 3.5 trillion tokens were used for a curated-data mid-training stage that also extended the context window. The company further claims that the model outperforms LFM2.5-2.6B while using 35% fewer parameters. Such comparisons reveal the problem the company is trying to solve, but the published speed, capability, and fine-tuning claims are primarily vendor-reported, not independently reproduced findings.
A sound evaluation starts with the application's real inputs and target device, then measures end-to-end latency, memory use, task success, and the effect of fine-tuning on relevant data. For multimodal systems, include the encoders, decoders, and chosen model branch in the test rather than using the text model's footprint as the budget for the whole application. LFM3's main value is a testable engineering path: reuse a shared backbone, then seek a better fit through branches and hardware adaptation. If a team cannot verify that those adaptations improve its actual workload, the family's parameter-efficiency and long-context figures remain selection clues, not deployment evidence.