Stop Training 2B Models as Shrunken Generalists: What Liquid AI's LFM3 Teaches Us About Shared-Trunk Specialization

Most people who tinker with local LLMs have been through the same cycle: you install one or two lightweight 2-billion-parameter (2B) models on your laptop. At first, pulling the weights in Ollama and watching the terminal stream over a hundred tokens per second feels great. After a few minutes of real use, though, the cracks show. Ask about slightly niche domain knowledge and it hallucinates; feed it a multi-thousand-word project document and it misses key figures; ask it to call a few external APIs in a strict schema and it drops required arguments or mangles brackets. Once the ten-minute novelty wears off, those weights end up gathering dust on your drive.

Small edge models keep turning into toys because frontier cloud models with hundreds of billions of parameters have warped the industry’s expectations. We instinctively assume every language model should do everything, trying to cram a cloud-scale generalist chatbot—one that memorizes encyclopedias, digests hundreds of thousands of words, and processes both images and audio—into a 2-billion-parameter (2B) shell. After two years of repeated failures in production, frontline engineering teams are coming to the same realization: chasing single-model omniscience at tiny edge scales is a dead end.

On October 27, Liquid AI released its open-weight LFM3 family, shipping six 2-billion-parameter (2B) class models at once. What makes this release stand out is a complete shift in edge survival strategy. At the bottom layer, the team pushed reuse to the limit: every model shares the exact same pretraining corpus, training pipeline, and 1.73-billion-parameter base weights. At the top layer, they abandoned the single-model generalist fantasy and made three deliberate engineering trade-offs, branching that single trunk into six specialized components with distinct jobs.

How Do You Reuse One Training Trunk to Build Both a Talking Hand and a Silent Eye?

When a model team gives up on an all-in-one generalist to build specialized parts, the first wall they hit is R&D cost. If you curate separate datasets, build separate pipelines, and train independent base models from scratch for tool coding, vision, audio, and fast classification, the compute and maintenance math simply does not work. LFM3 solves this by pouring over ninety percent of the heavy lifting into a single shared trunk and branching only at the final step.

Looking at the LFM3 collection on Hugging Face, all six launch models descend from the same 1.73-billion-parameter model, LFM3-1.7B-Base. It first builds a foundation on 18.5 trillion tokens of web text, code, and scientific literature, then dedicates its final 3.5 trillion tokens of mid-training to high-density agent trajectories and diverse tool-use data. Even the raw base model configuration, prior to any instruction tuning, comes pre-populated with a <think> reasoning template. Every downstream vision, audio, and decision model branches off this expensive tool-calling foundation.

That shared trunk splits upward into two distinct species. Many developers looking at the six model names for the first time get confused about whether LFM3 is a standard autoregressive generator that writes code token by token, or a decision model that scores candidate options. In fact, the team shipped both paradigms side by side, split into a left branch and a right branch.

The left branch consists of four standard generative models: text-only LFM3-1.7B, LFM3-VL-2B with a vision encoder, LFM3-Audio-2B with an audio encoder and custom audio tokenizer, and the all-modality LFM3-Omni-2B combining vision and audio. Like familiar open-weight LLMs, they emit text token by token or stream audio frames, built to serve as an agent’s execution hands—reading the current state and writing a <tool_call> to invoke an API or click a button.

The right branch starts from VL-2B and Omni-2B and applies reinforcement learning to produce two decision models, d1-2B and d1-Omni-2B. The team stripped away their ability to generate natural language token by token; every call emits exactly zero output tokens. You feed a long document or screenshot along with your query into the input, and the model runs a single forward pass—taking just 5.7 milliseconds on an H100 or 18.6 milliseconds on an Apple M5 Pro laptop chip—to read four types of structured outputs directly from the final network layer. It can select among candidate branches with calibrated probabilities, mark the exact start and end character offsets of key fields in the source text, estimate the median and 80% confidence interval for an unknown continuous number, or draw bounding boxes around target objects in an image and count them. Without training a separate backbone from scratch, attaching reinforcement-learned decision heads to the multimodal trunk yields a millisecond-level, zero-output-token discriminative eye that never corrupts bracket formatting.

Why Split Into Six Models and Push Closed-Book Knowledge Accuracy Down to 7%?

Once you understand the shared-trunk branching structure, the next question naturally follows: if the family already includes all-in-one multimodal models like LFM3-Omni-2B and d1-Omni-2B that can see images, hear audio, and read text, why go to the trouble of splitting the lineup into six separate models?

In the Hacker News launch thread, Liquid AI engineer samstevens laid out the reality plainly. In practice, expecting different modalities to mutually reinforce each other is wishful thinking, especially in small models. Within a tight 2-billion-parameter (2B) budget, every additional modality you pack in squeezes the capacity available to existing ones. The team’s own benchmark tables prove the point: on pure text and tool calling, the dedicated text model clearly beats the vision-language model, which in turn beats the all-modality Omni-2B—and the latter even had to drop the <think> reasoning block entirely. On image understanding and speech transcription, the omni model similarly loses to its dedicated single-modality siblings. On the decision branch, d1-2B scores a 70.2 average, outperforming the all-modality d1-Omni-2B at 67.7. Candidly admitting that 2 billion parameters (2B) cannot sustain a unified omni-model is the first trade-off that makes LFM3 practical.

Even more radical than splitting modalities is the surgery performed on knowledge memorization versus execution training. Look at LFM3-1.7B’s benchmarks: on browser automation (AutomationBench), it scores 41.29, blowing past Qwen3.5-9B—a model five times its size—at 15.10. Yet when tested on closed-book scientific trivia, it unsurprisingly trails larger models by a wide margin.

The clearest illustration comes from the AA-Omniscience hallucination benchmark, where LFM3-1.7B achieves the only positive overall score in the field at +0.50, while Qwen3.5-4B lands at -57.17. Inspecting the sub-metrics reveals that LFM3-1.7B’s closed-book accuracy on obscure facts is actually just 7.07%, the lowest in the table. It earns a positive overall score entirely by keeping its mouth shut when it does not know the answer, posting a 92.93% abstention rate on unknown facts. By contrast, Qwen3.5-4B abstains only 13.64% of the time, spending over eighty percent of its remaining turns guessing and hallucinating.

This is the core trick for turning a tiny model into a dependable engineering component. Instead of expecting a small model to memorize an encyclopedia, the team used reinforcement learning to heavily penalize blind guessing, forcing it to either abstain or call an external search tool whenever it lacks certainty. They then distilled six specialized reinforcement-learning teacher models—covering code, math, tool use, and more—back into the single backbone, and built an on-demand tool-loading switch (defer_loading=True) directly into the chat template. Even if hundreds of tools are registered in the backend, none of their schemas clutter the initial prompt; only after a search retrieves a specific tool name is its definition dynamically injected into an <additional_tools> block, preserving the model’s attention budget for the immediate action.

Of course, this trade-off introduces two noticeable side effects. First, it instills a compulsive tool-calling habit. Engineer liquid_richie confirmed that if a local runtime leaves default built-in tool schemas attached, asking a casual question like “What animal lays the biggest egg?” without any system prompt will cause the model to hallucinate a rule inside its <think> block claiming it is required to use available tools—and forcibly invoke one. Second, the vision branch relies heavily on its reasoning block. As an independent verification report noted, VL-2B’s headline 71.4 average score—matching a 12B model—requires keeping enable_thinking=True turned on by default. Turn off the thinking block for lower latency, and its average score drops immediately to 62.1, with math and logical reasoning plunging from 68.8 down to 41.0.

What Do You Gain—and Lose—by Cutting Three-Quarters of Global Attention?

Beyond lacking the capacity to memorize trivia, small models running multi-turn agent loops on phones and thin laptops hit another bottleneck. Long logs returned by every tool call accumulate in the conversation KV cache, quickly exhausting mobile RAM and slowing prompt prefill to a crawl.

To hit high speeds on edge silicon, the team ran hardware-in-the-loop architecture search across 14 real hardware targets, including Raspberry Pi 5, Samsung phones, iPhone 17 Pro, Apple M4/M5 Max, and Qualcomm NPUs. Inspecting the underlying network configuration of LFM3-1.7B-Base shows a sweeping redesign across all 24 layers. They stripped out 18 layers of global attention, leaving just 6 layers to attend across the full sequence, while replacing 13 layers with gated short convolutions that only track the last 7 tokens and 5 layers with sliding-window attention limited to the most recent 256 tokens. Finally, they used a larger teacher model to run quantization-aware distillation, producing a 4-bit compressed weight package of just 1.05 GB.

This structural surgery pays immediate dividends in memory footprint and speed: because three-quarters of the network layers do not grow their cache as text lengthens, the conversation cache at a 128K context length takes just 1.6 GB of memory—less than forty percent of Qwen3.5-4B’s 4.3 GB. When processing 32K-token inputs on an Apple M5 Max or iPhone 17 Pro, its prompt prefill speed is more than 2.5 times faster than competing models.

Yet cutting three-quarters of global attention—and spending only the final 50 billion tokens, or 0.23% of total training compute, extending the context window to 256K—comes with an unspoken cost. The advertised 256K context window is what fits in memory, not what the model can reliably retrieve across. On the RULER 128K needle-in-a-haystack retrieval benchmark, LFM3-1.7B scores just 65.56, trailing Qwen3.5-4B’s 84.63 by nearly 20 points. Liquid AI’s own cloud API caps the text model at 128K and the multimodal models at 32K, while the d1-2B documentation explicitly warns that state tracking becomes less reliable past roughly 64K tokens. Trading away long-range retrieval beyond 64K in exchange for tiny memory overhead and sub-second responsiveness on short, fast tasks is a calculated structural bargain.

Beyond LFM3 Itself, What Does This Specialization Mindset Teach Us About Training and Using Models?

Truthfully, the LFM3 models themselves may not become ubiquitous defaults on every developer’s machine—and even if we never deploy a single weight from this release, the engineering philosophy they validate is well worth borrowing. In the past, many teams fine-tuning open-weight models—whether 2-billion-parameter (2B) edge models or multi-ten-billion-parameter server models—fell into generalist anxiety: they wanted high scores on their vertical task, but feared losing leaderboard points on casual chat, closed-book trivia, or ultra-long reading comprehension, ending up with a mediocre model that excelled at nothing. LFM3 offers a refreshingly decisive blueprint: do the R&D math upfront by reusing your data, training pipeline, and base weights to the absolute limit at the bottom layer; then, at the task-facing layer, drop the burden of trying to do everything and embrace deliberate specialization.

It does not matter whether a cat is black or white, as long as it catches mice cheaply and reliably for your production workflow. If a model’s only job in your system is writing API calls, use reinforcement learning to punish guessing—even if closed-book trivia accuracy drops to 7.07%—so long as it stays quiet when unsure and formats external tool arguments cleanly. If a pipeline node only needs to sit at the front door triaging tickets, extracting character spans from source text, or boxing UI buttons on screen, strip away token-by-token natural language generation altogether and turn it into a single-forward-pass discriminative head that finishes in tens of milliseconds. And if the inputs it handles in production never exceed a few tens of thousands of words, keep only a handful of global attention layers, trading degradation past 64K for a tiny memory footprint and instant response times in everyday use.

The same principle applies to designing everyday agent and automation pipelines. Rather than waiting for a mythical model that is simultaneously tiny, fast, and omniscient, decompose your workflow across specialized components: put a zero-output-token decision model at the front gate for millisecond routing and span extraction, pair a high-abstention lightweight model with external search databases as a pure tool executor, route pure speech transcription to a smaller and more accurate 800-million-parameter specialist like Whisper-large-v3-turbo, and reserve true open-ended reasoning over broad world knowledge and massive contexts for frontier cloud models. Respecting a model’s physical capacity limits—and daring to trade away non-core capabilities for high reliability on the actions that matter—is where practical model fine-tuning and edge agent engineering truly begin.