LFM3 Leak: Liquid AI's Next Family Is Four Small Omni Models

A pull request opened on GitHub on 27 October 2026 wants to teach SGLang how to serve a model family that does not exist in public. It names four checkpoints — LFM3-1.7B, LFM3-VL-2B, LFM3-Audio-2B and LFM3-Omni-2B — and reads against the shipped LFM2.5-2.6B and LFM2.5-24B-A2B like a blueprint for what Liquid AI builds next. The PR is unmerged. All three of its CI checks are failing. Liquid AI has announced none of it. That unmerged diff is the entire public record of LFM3 as of today, and it is more informative than most launch posts — provided you read it for what it is.

So let us be precise about the evidence, because it is thin in one direction and unusually detailed in another. Nothing here is a release date, a price, a licence term or a benchmark score. There is no LFM3 model card, no Hugging Face repository, no blog post, no API listing. What exists is a contribution from tugot17 — Piotr Mazurek, who over the past two months has landed LFM runtime support in SGLang, llama.cpp and mlx-vlm — plus Liquid's own published material on the LFM2.5 generation it is about to supersede. Everything below is labelled accordingly.

What the pull request actually puts on the table

The PR title is [Feat] lfm3: Add text, vision, audio and Omni support, and it carries two labels that tell you what kind of change it is: jit-kernel and Multi-modal. It adds native text generation for a family of four, each with its own checkpoint path:

• LFM3-1.7B — text in, text out, the plain language model at the base of the family

• LFM3-VL-2B — text, images and video in, text out

• LFM3-Audio-2B — text and audio in, text out, and also wired to the /v1/audio/transcriptions endpoint

• LFM3-Omni-2B — text, images, audio and video in, including a video's own soundtrack, text out

One detail in that list is worth pausing on. Every variant outputs text. There is no audio-out path anywhere in the PR, and the audio model's non-chat surface is transcription — speech in, text out. That is narrower than Liquid's current audio line, where LFM2.5-Audio-1.5B is documented as handling ASR, TTS and interleaved voice chat in a single model. Either the first SGLang cut only covers the text-generating half of LFM3-Audio, or the omni family genuinely drops speech synthesis. The PR cannot settle which, and anyone telling you it does is guessing. Treat "LFM3 speaks" as unproven.

The rest of the diff is implementation detail that nonetheless dates the work. Vision and audio encoders with their projectors, a shared backbone, hybrid cache integration, CuTe DSL convolution kernels with a PyTorch fallback, and a note that FlashInfer defaults to paged prefill so sliding-window attention behaves. Validation ran on H100s in FP16 using what the description calls development checkpoints — four words that matter later.

The architecture sentence, and the number people will misread

The PR describes LFM3 as a shared backbone of gated short convolutions with full and sliding-window attention. That is the LFM2 lineage continued, not replaced: LFM2.5-24B-A2B is documented as a hybrid of gated short convolutions and grouped-query attention across 40 layers. What looks new in the leak is the explicit sliding-window component sitting alongside full attention.

The validation notes mention a prompt running beyond a 256-token sliding window, and this is the figure that will get quoted out of context all week. It is not LFM3's context length. In a hybrid design the attention layers only need to see locally because the convolution layers carry the long-range signal — that is the entire premise of the architecture, and it is why the family can hold 131,072 tokens of context on LFM2.5-24B-A2B while most of its layers are not doing quadratic attention at all. A 256-token attention window is a statement about where the model looks inside one layer, not how much text it can accept. The PR does not state LFM3's total context, and no one outside Liquid knows it yet.

Why a runtime pull request is the signal, not noise

It is reasonable to be suspicious of reading product strategy off an infrastructure diff. In this specific case the pattern is too consistent to ignore, because Liquid ships engine support with the weights rather than after them. LFM2.5-2.6B lists llama.cpp, MLX, vLLM, SGLang, ONNX and Transformers 5.0+ as day-one targets. LFM2.5-24B-A2B was supported in llama.cpp, MLX, vLLM, SGLang and ONNX at launch. A family that arrives with five runtimes ready has to have its kernels written before the announcement, which means the PRs land first and the blog post follows.

The author fits that chronology exactly. Mazurek's public history is a run of LFM integration work: DSpark speculative decoding for LFM2-VL in SGLang in September, LFM2.5-VL-3B and DSpark draft-model fixes in llama.cpp the same month, speculative decoding inherited from the text model in mlx-vlm, and an LFM2-MoE configuration reuse in SGLang on 13 October. LFM3 is the next entry in that sequence, filed the weekend the family changed names.

Two absences are as telling as the presence. There is no matching pull request in Hugging Face Transformers for LFM3 — a search of that repository returns nothing — and the SGLang PR loads its checkpoints through stock Transformers 5.19.0 with --trust-remote-code, which is what you do when the architecture is not yet native to the library. There is also a commit explicitly rejecting speculative decoding for LFM3, so the DSpark work that shipped for the 2.5 generation is not carried over yet. Early, and incomplete by design.

The size question nobody has answered

Here the leak and the stated ambition pull in opposite directions, and the tension is the most interesting thing in the document.

Maxime Labonne, Liquid's Head of Pretraining, has described LFM3's goal as testing whether the short-convolution approach that works at the 350M-to-1.2B scale can hold up beyond 10B parameters — the regime where attention architectures have historically had the advantage. That is a scaling question, and it implies a large model.

The leaked checkpoints are 1.7B and three at 2B. Not one of them is above the threshold that question is about.

Two readings survive. The first is that these are the compact first wave — an omni family for phones and cars before a large sibling arrives, which matches how Liquid has always led with small models and how the PR describes them as development checkpoints rather than final releases. The second is that 1.7B and 2B are simply the sizes that were convenient to validate kernels against, and tell us nothing about what ships. The honest position is that the leak proves the family exists and proves its shape; it does not prove its ceiling. If you are waiting for a >10B Liquid model, this PR neither promises one nor rules one out.

What LFM3 inherits, for better and worse

The baseline it has to beat is recent and well documented. LFM2.5-24B-A2B shipped on 13 October 2026 at 24B total parameters with 2B active, 40 layers, 64 experts and top-4 routing, a 131,072-token context, a 128K vocabulary and 33T pretraining tokens. LFM2.5-2.6B, from early August, fits in under 2.5GB with a 128K context. LFM2.5-VL-3B pairs the 2.6B base with a SigLIP2 vision encoder.

Worth stating plainly: every benchmark Liquid publishes for these is vendor-run on Liquid's own harnesses, with no independent evaluation attached. LFM2.5-24B-A2B's headline numbers — AutomationBench 27.69, BFCLv4 65.01, ToolSandbox 80.71, IFEval 96.75 — are Liquid's figures, and the same table shows it losing to Qwen3.6-35B-A3B on WebArena Verified (26.75 against 37.62), GPQA Diamond and SWE-Bench Verified. Vendor tables that include losses are more credible than ones that do not, but credible is not the same as verified. No LFM3 number of any kind exists, so there is nothing yet to compare.

Licensing will also carry forward. Liquid's recent LFM checkpoints on Hugging Face are each tagged license: other — a bespoke LFM licence, not Apache-2.0 or MIT. Whatever LFM3 ships under, assume the same custom terms until a model card says otherwise, and read them before you build a product on the weights.

When it might actually land

Nobody has a date, including the people guessing professionally. A Manifold Markets question on when LiquidAI LFM3 will be released puts Q4 2026 at 40%, Q1 2027 at 21%, Q2 2027 at 21%, Q3 2026 at 11% and Q2 2026 at 7% — on total volume of roughly Ṁ160, which is small enough that the percentages reflect a handful of traders rather than a consensus. Read it as "sometime in the next two quarters, probably", and no more precisely than that.

The mechanics argue for sooner rather than later. Kernel work landing in a major runtime is late-stage, not early-stage, engineering — you do not write CuTe convolution kernels and wire hybrid cache for a model that is a year out. The family name has stabilised to LFM3 across four variants and four checkpoint paths. But the PR is unmerged with all three checks red, needs an approving review it does not have, and 2 of 22 omni validation checks and 2 of 16 vision checks still fail their ROUGE comparison. That is a branch mid-flight, not a release candidate.

What this means if you are choosing a model this week

Nothing about LFM3 should change a decision you make today. It is not available, not priced, not benchmarked and not licensed in public. If you need a small multimodal model now, the LFM2.5 generation is the real answer, and its constraints — vendor-reported scores, custom licence, and a coding profile that both Liquid's own tables and outside coverage mark as the weak spot — are the things to weigh.

What the leak is genuinely useful for is planning. It tells you a compact omni family is coming, that it will likely arrive across several runtimes at once, and that its audio variant may not synthesise speech. If your roadmap assumed Liquid's next move was a bigger text model, the evidence so far does not support that assumption.

The runtime fragmentation is the practical problem this family will create. Liquid's habit of shipping into llama.cpp, MLX, vLLM, SGLang and ONNX simultaneously is good for portability and awkward for anyone who wants one endpoint: five engines means five deployment shapes, five sets of preprocessing quirks, and five different dates on which a fix lands. OrcaRouter's catalogue of more than 200 models does not include a single LFM checkpoint today, so there is no way to call LFM3 through it and nothing here should be read as a promise that there will be. What a routing layer is actually for in this situation is the seam between an unproven model and a production path — sending a slice of traffic to something new while a known model stays behind it, with failover catching the gap, is how you evaluate an unreleased family's successor without betting a customer-facing feature on a 40% prediction market.

The open questions worth watching

Four things will resolve this faster than any further speculation. Whether the four checkpoint paths become real, downloadable Hugging Face repositories — right now a search of the LiquidAI organisation returns nothing under LFM3, and the repositories named in the PR are not publicly resolvable. Whether a Transformers PR appears, which would signal the architecture is being upstreamed properly rather than run through remote code. Whether the failing validation checks close, since 2 of 22 omni failures is the difference between a demo and a merge. And whether a >10B member of the family shows up, which is the question Labonne said LFM3 exists to answer.

Until then, the most accurate sentence anyone can write about LFM3 is the one this article opened with: a pull request exists, it is unmerged, and it names four small omni models Liquid AI has not announced. That is a real signal — just an early one, and early signals deserve to be read as exactly that.