In partnership with
SnackOnAI Engineering | Senior AI Systems Researcher | Technical Deep Dive | October 29, 2026
The promise: by the end of this issue you will know how LFM3's convolution and attention layers divide up the work, why its memory footprint is so small, where its benchmark wins are real, and where a phone deployment will actually hit its limits.
The fence: we cover the October 27, 2026 release: the LFM3 collection, the LFM3-1.7B model card, Liquid's announcement and Hugging Face guide, the Liquid4All cookbook (fine-tuning notebooks, a wind turbine case study, a d1 demo), and the LFM2 Technical Report. Every benchmark, speed and memory figure is Liquid-reported; nobody has independently evaluated them yet. We did not run the weights. Our analysis computes what Liquid's published numbers imply.
What It Actually Does
LFM3 is six open-weight models built on one 1.73B-parameter backbone, each specialized for a different input or output type:
Model | Size | What it does | Notable reported number |
|---|---|---|---|
LFM3-1.7B | 1.73B | Text, tool calling, agents, 256K context | BFCL V4 71.39, IFEval 96.66 |
LFM3-1.7B-Base | 1.73B | Pre-trained base for your own fine-tunes | 22T training tokens |
LFM3-VL-2B | 1.9B | Images and video; new 164M-parameter vision encoder | 71.4 average over 62 evals vs 64.0 for Qwen3.5-2B |
LFM3-Audio-2B | ~2B | Speech recognition, speech synthesis, translation, 18 languages | English WER 6.2%, first token as low as 50 ms |
LFM3-Omni-2B | ~2.2B | Text, image, video and audio in; text or speech out | Interleaved text and speech replies |
d1-2B, d1-Omni-2B | ~2B | Typed decisions with calibrated probabilities, one forward pass | 63.2 on a 117-benchmark index vs 58.8 for the older d1-3B |
Distribution: weights ship in BF16, FP8, NVFP4, GGUF, MLX and ONNX, with day-one support in Transformers, vLLM, SGLang, llama.cpp, MLX, Ollama and LM Studio.
License: LFM Open License v1.0, which makes commercial use royalty-free below $10M in annual revenue. Above that you need a separate agreement.
Hosted pricing: the text model costs $0.08 per million input tokens and $0.20 per million output tokens.
The thesis is specialization over scale. Instead of one big generalist, you get small siblings that share a backbone, each cheap enough to fine-tune on a single GPU and small enough to fit on a phone.
The Architecture, Unpacked
Caption: Eighteen of the twenty-four layers keep a fixed-size memory. Only the six global attention layers grow with context, which is why a quarter million tokens fit in a few gigabytes.
Four design decisions do the work.
Mostly convolution. A gated short convolution mixes each token with its six predecessors. It is cheap, fully parallel during prefill, and keeps a tiny fixed state during decode. LFM2 settled on 10 convolution and 6 attention blocks in its 1.2B model. LFM3 keeps convolution as the majority operator and widens the kernel from 3 to 7.
A third layer type. LFM3 adds sliding-window attention with a 256-token window: mid-range lookback with a constant cost. That is the "tri" in tri-hybrid.
Few global layers. Only six layers attend over the whole context. Partial rotary embeddings in those layers help long-context extrapolation, and a sigmoid gate on each head's output also tames the activation outliers that break 4-bit quantization.
Search, not taste. As with LFM2, the layout came out of an automated search over 14 device and backend combinations, scored on real latency and memory rather than parameter count.
The Code, Annotated
First, the operator that makes up most of the network. This is our minimal PyTorch reconstruction of a gated short convolution, following LFM2's open implementation with LFM3's kernel of 7. The cookbook's LoRA config, the third snippet below, targets the same in_proj and out_proj names. We checked that changing one token alters exactly that output and the six after it.
import torch.nn as nn
class GatedShortConv(nn.Module):
def __init__(self, d, kernel=7): # LFM2 used 3; LFM3 widens to 7
super().__init__()
self.in_proj = nn.Linear(d, 3 * d, bias=False) # one matmul makes two gates + values
self.conv = nn.Conv1d(d, d, kernel, groups=d, # depthwise: one tiny filter per channel
padding=kernel - 1, bias=False)
self.out_proj = nn.Linear(d, d, bias=False)
def forward(self, x): # x: (batch, seq, d)
B, C, h = self.in_proj(x).transpose(1, 2).chunk(3, dim=1)
y = self.conv(B * h)[..., : x.shape[1]] # ← THIS is the trick: causal, 7-token reach
return self.out_proj((C * y).transpose(1, 2)) # input-dependent gates do what attention would
Caption: During decoding, this layer only needs its last six inputs per channel. Thirteen of these layers add almost nothing to memory however long the context gets.
Second, the d1 interface, verbatim from the cookbook's road-decider demo. It calls the hosted d1 API two to five times a second inside a game loop.
const QUESTION = {
lane: {
type: "choice", // the answer is ALWAYS one of the criteria keys: no parsing, no hallucinated labels
instructions:
"Pick the safest lane. Row 1 is most urgent. Prefer the current lane when options are equally safe.",
criteria: { left: "Left lane", center: "Center lane", right: "Right lane" },
},
};
// response: one forward pass, no generated text
// { "answers": { "lane": { "type": "choice", "choice": "center",
// "probabilities": { "left": 0.03, "center": 0.93, "right": 0.04 }, // ← calibrated scores you can threshold
// "confidence": 0.93 } } }
Caption: A decision model replaces "generate JSON, then parse and validate it" with "score a closed set of options". The probabilities let you route low-confidence cases to a bigger model or a human.
Third, what you actually fine-tune, verbatim from the cookbook's LFM3 SFT notebook.
peft_config = LoraConfig(
r=16, lora_alpha=32, lora_dropout=0.05,
target_modules=[
"q_proj", "k_proj", "v_proj", "o_proj", # attention, used in only 11 of 24 layers
"in_proj", "out_proj", # ← the conv blocks' projections: the majority operator
"w1", "w2", "w3", # feed-forward
# "gate_proj", # optional: LFM3's per-head attention gate
],
task_type="CAUSAL_LM",
)
Caption: Adapters written for standard transformers miss most of LFM3. Target only q, k, v and o and you skip the convolution blocks entirely.
Fourth, our math on Liquid's published numbers.
# KV per token per global layer: 1.6 GB / (131,072 tokens x 6 layers) = ~2.0 KB
# all-global 24-layer equivalent at 128K: 6.4 GB -> tri-hybrid keeps 25%
# sliding-window caches: 2.6 MB total, fixed at any context
# KV at 32K / 128K / 256K: 0.40 / 1.60 / 3.20 GB vs ~1 GB of 4-bit weights
# 32K prompt prefill (Q4_0): iPhone 17 Pro 30.9 s · Ryzen AI Max+ 8.7 s · M5 Max 4.1 s
# 256K prompt on iPhone at the 32K rate (optimistic): ~4.1 minutes
# B300 throughput: 3.6B tokens/day = ~41.7K tokens/s across 1,024 requests (~41 per request)
Caption: Memory is solved. At a quarter million tokens the KV cache still outweighs the 4-bit weights three times over, and prefill speed, not storage, limits how much context a phone can use.
It In Action
Input: a local email triage agent on an iPhone 17 Pro. The prompt is a 32K-token context: a system prompt, tool schemas and a few dozen emails. The model is LFM3-1.7B in Q4_0 via llama.cpp, Liquid's reported setup.
Step one, load. Liquid reports 1.90 GB of resident memory at 32K. That fits our breakdown: about 1 GB of weights, about 0.4 GB of KV cache for the six global layers, plus runtime overhead.
Step two, prefill. At the reported 1,061 tokens per second, reading 32,768 tokens takes 30.9 s before the first output token. The 13 convolution layers process the whole sequence in parallel, so prefill is the fast phase. It is still the long pole.
Step three, decode. A 500-token answer with a tool call, at 43.6 tokens per second, takes 11.5 s.
Step four, decide differently. If the task is really "label each email urgent, normal or spam", the same job maps to d1: a choice question per email, answered in one forward pass with per-option probabilities and no generated tokens at all.
Output: about 42 s end to end on the phone for the generative path. The same request takes roughly 6 s on an M5 Max.
Device (Q4_0, 32K input) | Prefill tok/s | Decode tok/s | Memory | 32K prefill | 500 tokens out |
|---|---|---|---|---|---|
iPhone 17 Pro | 1,061 | 43.6 | 1.90 GB | 30.9 s | 11.5 s |
AMD Ryzen AI Max+ 395 | 3,771 | 129.6 | 2.75 GB | 8.7 s | 3.9 s |
Apple M5 Max | 8,028 | 237.1 | 2.25 GB | 4.1 s | 2.1 s |
Caption: Liquid's figures, our arithmetic. On phones, keep prompts short or cache them; long context is a laptop and server feature.
Why This Design Works, and What It Trades Away
Why it works. Most of what a language model mixes is local: syntax, phrases, the last few tokens. Short convolutions do that at a fraction of attention's cost, sliding windows cover paragraph-scale structure, and six global layers do the long-range retrieval. Splitting the job by distance gives near-transformer quality at a quarter of the KV memory, and quantization holds up because the head gates suppress outliers. Sharing one backbone across six products also amortizes 22T tokens of pre-training across text, vision, audio and decisions.
What it trades away.
Long-context quality. RULER at 128K is 65.56 for LFM3-1.7B vs 87.11 for Qwen3.5-9B. Six global layers can hold 256K tokens; they do not retrieve from it as reliably.
Knowledge and coding. GPQA Diamond scores 63.37 vs 80.40, and SWE-bench Verified 43.40 vs 51.20. Liquid's own card says the model is "not recommended for agentic coding or complex multi-step reasoning."
Reasoning control. Thinking is on by default, and the card warns that
enable_thinking=Falsecan behave inconsistently, which adds output tokens on exactly the devices where decode is slowest.Context on the API. The weights support 256K; the hosted API lists 128K.
Speed comparisons. Liquid's server benchmarks ran its own serving stack against vLLM for competitors, so they do not isolate the architecture.
Technical Moats
Hardware in the loop. An architecture search scored on 14 real device and backend targets. That is an expensive capability most labs do not have, and why the layout looks unusual.
One backbone, six products. New encoders (164M vision, causal audio), a codec that emits 12 tokens per 80 ms in parallel and decodes about 87x faster than real time on one CPU thread, and a decision head, all on shared weights.
Post-training depth for a 2B. Pre-training ran 22T tokens, with 3.5T of agent-heavy mid-training at up to 256K context. SFT added 1.75T tokens, followed by on-policy distillation from six specialist teachers and a final agentic RL stage. Few teams spend this much compute on a model this small.
Distribution on day one. Seven runtimes and six weight formats at launch, plus a cookbook of working fine-tuning notebooks for every modality.
Insights
Insight One: "it replaces 9B models" is true for tool calls, not for thinking or long context. Against Qwen3.5-9B, which has 5.2x more parameters, LFM3-1.7B wins WebArena-Verified (38.42 vs 28.94), AutomationBench (41.29 vs 15.10), BFCL V4 (71.39 vs 62.83) and LiveClaw (45.60 vs 35.77). It loses MCP-Atlas (32.57 vs 42.67), SWE-bench Verified, GPQA Diamond, RULER 128K and EnterpriseOps-Gym. The pattern is clear: post-training made it excellent at formatting and sequencing tool calls, the skill 3.5T tokens of agent traces teach. It did not buy the knowledge or long-range retrieval that parameters and global attention provide. Use it for narrow agents with well-defined tools; route open-ended reasoning elsewhere.
Insight Two: the "beats a frontier model" fine-tuning story is a 0.106 F1. The cookbook's wind turbine study fine-tunes LFM3-VL-2B on about 3,000 photos in a few hours on one A100. It reports beating GPT-6 Luna by 11x on typed detection F1, 0.106 vs 0.010. Both numbers are near zero: the fine-tuned model finds about 9% of annotated defects. GRPO's gain over SFT came mostly from fewer false boxes (1,103 to 710 on validation, 36% fewer) while recall stayed flat, and training past step 400 made it worse. The real lesson is narrower and more useful. Fine-tuning a small model for a single domain beats prompting a frontier model, and image-type classification jumped from under 10% to 67%. Detection is not solved.
Surprising Takeaway
At LFM3's full 256K context, the KV cache for just six layers (about 3.2 GB by our extrapolation of Liquid's 1.6 GB at 128K) outweighs the entire 4-bit model three times over, even though the other eighteen layers hold only about 2.6 MB of state between them. On a phone, though, neither number matters first: at Liquid's own iPhone prefill rate, reading 256K tokens would take over four minutes. The architecture solved long-context memory; the compute to fill that context is still what limits on-device agents.
TL;DR For Engineers
LFM3 is six models on one 1.73B backbone: 13 gated short convolutions, 5 sliding-window attention layers (256 tokens) and 6 global attention layers.
KV cache is 1.6 GB at 128K, a quarter of an all-attention equivalent. The text model fits in about 1 GB at 4-bit.
It wins tool calling and web agent benchmarks against a 9B model, and loses knowledge, coding and long-context retrieval (RULER 128K 65.6 vs 87.1).
On an iPhone 17 Pro, a 32K prompt needs about 31 s of prefill. Cache your system prompt and tool schemas, and keep contexts short.
For classification and routing, use d1: typed answers with probabilities in one forward pass. When fine-tuning, include
in_projandout_projin LoRA targets.
Explain It Like I'm New
Most AI assistants live in giant data centers. Every request leaves your device, costs money, and depends on a network connection. A lot of everyday tasks, like sorting email, reading a receipt or understanding a voice command, do not need a giant model. They need a fast, private one that fits in your pocket.
Liquid AI's answer is a family of small models built from the same core, like one engine fitted into a sedan, a truck and a motorbike. One version reads text and uses tools, another sees images and video, another listens and speaks, and a fourth kind simply makes decisions: pick one of these options, and say how sure you are.
The clever part is how the core reads. A standard model compares every word with every other word, which gets expensive as text grows. LFM3 mostly looks at nearby words, like reading with a magnifying glass, and only a few of its layers step back to see the whole page. That keeps memory small enough for a phone.
There is a catch. Holding a long document in memory is not the same as reading it quickly or understanding it well, and small models still know less than big ones.
The bigger shift is that AI is splitting into many small specialists that run where the data lives.
See It In Action
Road Decider: real-time decisions with d1, Liquid AI cookbook. GitHub example. A pixel-art racer where d1 picks a lane several times per second, which shows calibrated probabilities driving a live control loop.
Wind turbine blade inspection with LFM3-VL, Liquid AI cookbook. GitHub example. An end-to-end SFT plus GRPO pipeline with honest scorecards, bootstrap confidence intervals and a frontier model baseline.
LFM3-Omni capabilities notebook, Liquid AI. Colab-ready notebook. Speech synthesis, recognition, translation, image and video questions, tool calling, and interleaved text and speech from one 2B model.
Liquid Playground, Liquid AI. playground.liquid.ai. Try the hosted models in a browser before downloading weights.
Community Conversation
VentureBeat, LFM3 analysis. The most skeptical coverage. It notes the 256K weights vs 128K API gap, the competitor speed tests run on vLLM against Liquid's own stack, and that Mercedes-Benz and Shopify were pre-release testers, not confirmed deployments.
OrcaRouter, LFM3 family explained. Clarifies that the 256-token window is per-layer attention geometry, not context length, and flags that no independent evaluation exists yet, including no Artificial Analysis entry.
AlphaSignal, LFM3 breakdown. Details the encoders, LiquidCodec, d1's Point, Read, Estimate and Pick operations, and the weaker spots: agentic vision at 42.5 and general audio understanding (MMAR 50.6 vs 62.3 for MiMo-Audio-7B).
Maxime Labonne (Liquid AI), Hugging Face post on local agents. Written for LFM2.5. It argues that zero marginal cost per token changes agent design toward massive parallel background work, which the LFM3 launch echoes with its 300,000-agent stress test.
Small Models Win at Doing, Not Yet at Knowing
LFM3 is the most complete small-model release of the year: one well-engineered backbone, four modalities, a decision head that skips text generation entirely, and memory efficiency that makes 256K tokens physically possible on consumer hardware. Its wins are concentrated where post-training pays off: tool calls, structured output and instruction following. Its losses sit where parameters and global attention matter: knowledge, coding and long-context retrieval. Build narrow, tool-driven agents on it, use d1 for anything that is really a classification, keep phone prompts short, and do not mistake a context window for comprehension.
References
LFM2 Technical Report, Liquid AI. Hardware-in-the-loop architecture search, the gated convolution plus attention hybrid, and the training recipe LFM3 builds on.
RULER: What's the Real Context Size of Your Long-Context Language Models?, Hsieh et al. The benchmark behind the gap between a 256K window and usable long-context retrieval.
Hungry Hungry Hippos: Towards Language Modeling with State Space Models, Fu et al. Early evidence that short convolutions with multiplicative gating recover much of attention's quality.
LongMemEval: Benchmarking Chat Assistants on Long-Term Interactive Memory, Wu et al. How to test whether long-lived agents actually use what they keep in context.
LFM3 is six open-weight models on one 1.73B tri-hybrid backbone of short convolutions, sliding-window and global attention, which cuts KV memory to a quarter and fits a phone. It beats a 9B model on tool calling and web agents but trails on knowledge, coding and long-context retrieval, and on-device prefill, not memory, is its real limit.
Sponsored Ad If you enjoy practical AI insights, check out SnackOnAI and support the newsletter by subscribing, sharing, and exploring our sponsored ad—it helps us keep building and delivering value 🚀
The AI notetaker that gets the hard words right
Your AI is only as good as what you feed it. Feed it a transcript with your product names, acronyms, and numbers spelled wrong, and you spend the afternoon hand-fixing the output.
Wispr Flow Notetaker uses your dictionary and calendar, so product names, acronyms, numbers, and uncommon names come out spelled right. It pops up when your meeting starts and captures Zoom, Google Meet, Teams, and Slack huddles with one click, no bot joining the call.
Then your meetings show up inside Claude or ChatGPT through the built-in connector. No copy paste. Try Notetaker free on Mac and Windows.