LFM3-läcka: Liquid AI:s nästa familj är fyra små omnimodeller

En pull request som öppnades på GitHub den 27 oktober 2026 vill lära SGLang att servera en modellfamilj som inte finns offentligt. Den namnger fyra checkpoints – LFM3-1.7B, LFM3-VL-2B, LFM3-Audio-2B och LFM3-Omni-2B – och framstår, läst mot de levererade LFM2.5-2.6B och LFM2.5-24B-A2B, som en ritning för vad Liquid AI bygger härnäst. PR:en är inte mergad. Alla tre av dess CI-kontroller misslyckas. Liquid AI har inte tillkännagivit något av det. Den där icke-mergade diffen är i dag hela den offentliga dokumentationen om LFM3, och den är mer informativ än de flesta lanseringsinlägg – förutsatt att man läser den för vad den är.

Låt oss vara noggranna med bevisen, för de är tunna i en riktning och ovanligt detaljerade i en annan. Inget här är ett releasedatum, ett pris, ett licensvillkor eller ett benchmarkpoäng. Det finns inget LFM3-modellkort, inget Hugging Face-repository, inget blogginlägg, ingen API-listning. Det som finns är ett bidrag från tugot17 — Piotr Mazurek, som under de senaste två månaderna har landat LFM-runtime-stöd i SGLang, llama.cpp och mlx-vlm — plus Liquids egna publicerade material om LFM2.5-generationen som den snart ska ersätta. Allt nedan är märkt därefter.

Vad pull requesten faktiskt lägger på bordet

PR-rubriken är [Feat] lfm3: Add text, vision, audio and Omni support, och den har två etiketter som talar om vilken typ av ändring det är: jit-kernel och Multi-modal. Den lägger till inbyggd textgenerering för en familj på fyra, var och en med sin egen checkpoint-sökväg:

• LFM3-1.7B – text in, text ut, den rena språkmodellen som utgör familjens bas

• LFM3-VL-2B — text, bilder och video in, text ut

• LFM3-Audio-2B — text och ljud in, text ut, och även kopplad till {{1}}/v1/audio/transcriptions{{/1}}-endpointen

• LFM3-Omni-2B — text, bilder, ljud och video som indata, inklusive videons eget ljudspår, text som utdata

En detalj i den listan är värd att stanna upp vid. Varje variant ger text som utdata. Det finns ingen väg för ljudutdata någonstans i PR:en, och ljudmodellens yta utanför chatten är transkription – tal in, text ut. Det är snävare än Liquids nuvarande ljudserie, där LFM2.5-Audio-1.5B dokumenteras hantera ASR, TTS och interleaved röstchatt i en och samma modell. Antingen omfattar den första SGLang-versionen bara den textgenererande halvan av LFM3-Audio, eller så släpper omni-familjen verkligen talsyntesen. PR:en kan inte avgöra vilket, och den som säger att den kan det gissar. Betrakta ”LFM3 talar” som obevisat.

Resten av diffen är implementeringsdetaljer som ändå daterar arbetet. Vision- och ljudkodare med sina projektorer, en delad stomme, hybridcacheintegration, CuTe DSL-konvolutionskärnor med en PyTorch-fallback, och en notering om att FlashInfer som standard använder paged prefill så att sliding-window-attention beter sig korrekt. Valideringen kördes på H100:or i FP16 med hjälp av vad beskrivningen kallar utvecklingscheckpoints – fyra ord som spelar roll senare.

Arkitektursatsen, och siffran som folk kommer att läsa fel

PR:en beskriver LFM3 som en gemensam ryggrad av gated kortkonvolutioner med full attention och sliding-window-attention. Det är LFM2-linjen som fortsätter, inte ersätts: LFM2.5-24B-A2B dokumenteras som en hybrid av gated kortkonvolutioner och grouped-query attention över 40 lager. Det som verkar nytt i läckan är den explicita sliding-window-komponenten som finns vid sidan av full attention.

Valideringsanteckningarna nämner en prompt som går bortom ett glidande fönster på 256 token, och det är siffran som kommer att citeras ur sitt sammanhang hela veckan. Det är inte LFM3:s kontextlängd. I en hybriddesign behöver uppmärksamhetslagren bara se lokalt eftersom konvolutionslagren bär den långväga signalen – det är hela premissen för arkitekturen, och det är därför familjen kan hålla 131 072 token i kontext på LFM2.5-24B-A2B medan de flesta av dess lager inte utför kvadratisk uppmärksamhet alls. Ett uppmärksamhetsfönster på 256 token är ett uttalande om var modellen tittar inom ett lager, inte hur mycket text den kan ta emot. PR:en anger inte LFM3:s totala kontext, och ingen utanför Liquid vet den ännu.

Varför en runtime-pull request är signalen, inte bruset

Det är rimligt att vara misstänksam mot att läsa ut produktstrategi ur en infrastrukturdiff. I just det här fallet är mönstret för konsekvent för att ignorera, eftersom Liquid levererar motorstöd med vikterna snarare än efter dem. LFM2.5-2.6B listar llama.cpp, MLX, vLLM, SGLang, ONNX och Transformers 5.0+ som mål från första dagen. LFM2.5-24B-A2B hade stöd i llama.cpp, MLX, vLLM, SGLang och ONNX vid lanseringen. En familj som anländer med fem körtidsmiljöer redo måste ha sina kärnor skrivna före tillkännagivandet, vilket innebär att PR:erna landar först och blogginlägget följer.

Författaren passar exakt in i den kronologin. {{1}}Mazureks offentliga historia är en rad LFM-integrationsarbeten: DSpark spekulativ avkodning för LFM2-VL i SGLang i september, LFM2.5-VL-3B och DSpark-rättelser av draft-modeller i llama.cpp samma månad, spekulativ avkodning ärvd från textmodellen i mlx-vlm, och en återanvändning av LFM2-MoE-konfiguration i SGLang den 13 oktober.{{/1}} LFM3 är nästa post i den sekvensen, inlämnad helgen då familjen bytte namn.

Två avsaknader är lika talande som närvaron. Det finns ingen matchande pull request i Hugging Face Transformers för LFM3 – en sökning i det repot ger ingenting – och SGLang-PR:en laddar sina checkpoints via standard-Transformers 5.19.0 med --trust-remote-code, vilket är vad man gör när arkitekturen ännu inte är inbyggd i biblioteket. Det finns också en commit som uttryckligen avvisar spekulativ avkodning för LFM3, så DSpark-arbetet som levererades för 2.5-generationen har ännu inte förts över. Tidigt och avsiktligt ofullständigt.

Storleksfrågan som ingen har besvarat

Här drar läckan och den uttalade ambitionen i motsatta riktningar, och spänningen är det mest intressanta i dokumentet.

Maxime Labonne, Liquids chef för förträning, har beskrivit LFM3:s mål som att testa huruvida den kortkonvolutionsmetod som fungerar i skalan 350M–1,2B kan stå sig bortom 10B parametrar — det område där uppmärksamhetsarkitekturer historiskt har haft fördelen. Det är en skalningsfråga, och det innebär en stor modell.

De läckta checkpointarna är 1,7B och tre på 2B. Ingen av dem ligger över tröskelvärdet som frågan handlar om.

Två tolkningar håller. Den första är att dessa är den kompakta första vågen – en omni-familj för telefoner och bilar innan ett stort syskon anländer, vilket stämmer med hur Liquid alltid har inlett med små modeller och hur PR:en beskriver dem som utvecklingscheckpoints snarare än slutliga versioner. Den andra är att 1,7B och 2B helt enkelt är de storlekar som var praktiska att validera kärnor mot, och att de inte säger något om vad som faktiskt släpps. Den ärliga hållningen är att läckan bevisar att familjen finns och bevisar dess form; den bevisar inte dess tak. Om du väntar på en Liquid-modell på >10B lovar den här PR:en varken en sådan eller utesluter en.

Vad LFM3 ärver, på gott och ont

Baslinjen den måste slå är färsk och väl dokumenterad. LFM2.5-24B-A2B lanserades den 13 oktober 2026 med 24B totala parametrar med 2B aktiva, 40 lager, 64 experter och top-4-routing, en kontext på 131 072 token, en vokabulär på 128K och 33T förtränings-token. LFM2.5-2.6B från början av augusti får plats på under 2,5 GB med en kontext på 128K. LFM2.5-VL-3B kombinerar 2,6B-basen med en SigLIP2-visionencoder.

Det är värt att säga rakt ut: varje benchmark som Liquid publicerar för dessa körs av leverantören i Liquids egna testramverk, utan någon oberoende utvärdering bifogad. Huvudsiffrorna för LFM2.5-24B-A2B – AutomationBench 27,69, BFCLv4 65,01, ToolSandbox 80,71, IFEval 96,75 – är Liquids siffror, och samma tabell visar att den förlorar mot Qwen3.6-35B-A3B på WebArena Verified (26,75 mot 37,62), GPQA Diamond och SWE-Bench Verified. Leverantörstabeller som redovisar förluster är mer trovärdiga än de som inte gör det, men trovärdig är inte samma sak som verifierad. Det finns inga LFM3-siffror av något slag, så det finns ännu inget att jämföra med.

Licensiering kommer också att föras vidare. Liquids senaste LFM-checkpoints på Hugging Face är var och en taggade license: other – en skräddarsydd LFM-licens, inte Apache-2.0 eller MIT. Oavsett vad LFM3 släpps under, utgå från samma anpassade villkor tills ett modellkort säger annat, och läs dem innan du bygger en produkt på vikterna.

När det faktiskt kan landa

Ingen har ett datum, inte ens de som gissar professionellt. En fråga på Manifold Markets om när LiquidAI LFM3 släpps anger Q4 2026 till 40 %, Q1 2027 till 21 %, Q2 2027 till 21 %, Q3 2026 till 11 % och Q2 2026 till 7 % – på en total volym på ungefär Ṁ160, vilket är tillräckligt litet för att procenttalen ska återspegla en handfull handlare snarare än en konsensus. Tolka det som "någon gång under de kommande två kvartalen, förmodligen", och inte mer exakt än så.

Mekaniken talar för snarare än senare. Kernelarbete som landar i en stor runtime är senfas-, inte tidigfas-, ingenjörskonst — man skriver inte CuTe-konvolutionskernels och kopplar in hybridcache för en modell som ligger ett år bort. Familjenamnet har stabiliserats till LFM3 över fyra varianter och fyra checkpoint-sökvägar. Men PR:en är omergead med alla tre kontrollerna röda, behöver en godkännande granskning som den inte har, och 2 av 22 omni-valideringskontroller och 2 av 16 visionskontroller klarar fortfarande inte sin ROUGE-jämförelse. Det är en branch mitt i flygningen, inte en releasekandidat.

Vad detta innebär om du väljer en modell den här veckan

Ingenting om LFM3 bör ändra ett beslut du fattar i dag. Det är inte tillgängligt, inte prissatt, inte benchmarkat och inte licensierat offentligt. Om du behöver en liten multimodell nu är LFM2.5-generationen det verkliga svaret, och dess begränsningar – leverantörsrapporterade resultat, anpassad licens och en kodningsprofil som både Liquids egna tabeller och extern rapportering pekar ut som svagheten – är det du bör väga in.

Det som läckan verkligen är användbar för är planering. Den berättar att en kompakt omni-familj är på väg, att den sannolikt kommer att dyka upp i flera körtidsmiljöer samtidigt, och att dess ljudvariant kanske inte syntetiserar tal. Om din färdplan utgick från att Liquids nästa drag var en större textmodell, stöder bevisen hittills inte det antagandet.

Körtidsfragmenteringen är det praktiska problem som den här familjen kommer att skapa. Liquids vana att samtidigt släppa till llama.cpp, MLX, vLLM, SGLang och ONNX är bra för portabilitet och besvärlig för alla som vill ha en enda slutpunkt: fem motorer innebär fem distributionsformer, fem uppsättningar egenheter i förbearbetningen och fem olika datum då en rättelse landar. OrcaRouters katalog över fler än 200 modeller innehåller i dag inte en enda LFM-checkpoint, så det finns inget sätt att anropa LFM3 via den, och inget här bör läsas som ett löfte om att det kommer att finnas. Vad ett routingskikt faktiskt är till för i den här situationen är sömmen mellan en obeprövad modell och en produktionsväg – att skicka en del av trafiken till något nytt medan en känd modell står kvar bakom, med failover som fångar gapet, är hur man utvärderar en ännu inte släppt familjs efterträdare utan att satsa en kundvänd funktion på en prediktionsmarknad på 40 %.

De öppna frågorna som är värda att bevaka

Fyra saker kommer att lösa detta snabbare än någon ytterligare spekulation. Huruvida de fyra checkpoint-sökvägarna blir riktiga, nedladdningsbara Hugging Face-repositorier – just nu ger en sökning i LiquidAI-organisationen ingenting under LFM3, och repositorierna som namnges i PR:en går inte att hitta offentligt. Huruvida en Transformers-PR dyker upp, vilket skulle signalera att arkitekturen förs uppströms på rätt sätt i stället för att köras via fjärrkod. Huruvida de misslyckade valideringskontrollerna stängs, eftersom 2 av 22 omni-misslyckanden är skillnaden mellan en demo och en merge. Och huruvida en medlem av familjen med >10B dyker upp, vilket är frågan som Labonne sade att LFM3 finns för att besvara.

Fram till dess är den mest korrekta meningen någon kan skriva om LFM3 den som den här artikeln inleddes med: en pull request finns, den har inte slagits samman, och den namnger fyra små omni-modeller som Liquid AI inte har tillkännagivit. Det är en riktig signal – bara en tidig sådan, och tidiga signaler förtjänar att läsas som just det.