LFM3-lek: Liquid AI's volgende familie bestaat uit vier kleine omni-modellen

Een pull request die op 27 oktober 2026 op GitHub werd geopend, wil SGLang leren hoe het een modelfamilie moet serveren die niet openbaar bestaat. Hij noemt vier checkpoints — LFM3-1.7B, LFM3-VL-2B, LFM3-Audio-2B en LFM3-Omni-2B — en leest naast de uitgebrachte LFM2.5-2.6B en LFM2.5-24B-A2B als een blauwdruk voor wat Liquid AI hierna bouwt. De PR is niet samengevoegd. Alle drie de CI-checks ervan falen. Liquid AI heeft er niets van aangekondigd. Die niet-samengevoegde diff is op dit moment het volledige openbare record van LFM3, en hij is informatiever dan de meeste lanceerposts — mits je hem leest voor wat hij is.

Laten we dus precies zijn over het bewijsmateriaal, want dat is mager in de ene richting en ongewoon gedetailleerd in de andere. Niets hier is een releasedatum, een prijs, een licentievoorwaarde of een benchmarkscore. Er is geen LFM3-modelkaart, geen Hugging Face-repository, geen blogpost, geen API-vermelding. Wat er wel is, is een bijdrage van tugot17 — Piotr Mazurek, die de afgelopen twee maanden LFM-runtimeondersteuning heeft toegevoegd aan SGLang, llama.cpp en mlx-vlm — plus het eigen gepubliceerde materiaal van Liquid over de LFM2.5-generatie die op het punt staat te worden vervangen. Alles hieronder is dienovereenkomstig gelabeld.

Wat de pull request daadwerkelijk op tafel legt

De titel van de PR is [Feat] lfm3: tekst-, vision-, audio- en Omni-ondersteuning toevoegen, en de PR heeft twee labels die aangeven wat voor soort wijziging het is: jit-kernel en Multi-modal. De PR voegt native tekstgeneratie toe voor een familie van vier, elk met een eigen checkpointpad:

• LFM3-1.7B — tekst in, tekst uit, het gewone taalmodel aan de basis van de familie

• LFM3-VL-2B — tekst, afbeeldingen en video in, tekst uit

• LFM3-Audio-2B — tekst en audio als invoer, tekst als uitvoer, en ook gekoppeld aan het /v1/audio/transcriptions-endpoint

• LFM3-Omni-2B — tekst, afbeeldingen, audio en video als invoer, inclusief de eigen soundtrack van een video, tekst als uitvoer

Eén detail in die lijst is het waard om even bij stil te staan. Elke variant levert tekst op. Er is nergens in de PR een pad voor audio-uitvoer, en het niet-chat-oppervlak van het audiomodel is transcriptie — spraak erin, tekst eruit. Dat is beperkter dan Liquid's huidige audiolijn, waarvan LFM2.5-Audio-1.5B gedocumenteerd is als het aankunnen van ASR, TTS en interleaved voicechat in één model. Ofwel de eerste SGLang-versie dekt alleen de tekstgenererende helft van LFM3-Audio, ofwel de omni-familie laat spraaksynthese echt vallen. De PR kan niet beslechten welke van de twee het is, en iedereen die je vertelt dat het wel zo is, gokt. Beschouw "LFM3 speaks" als onbewezen.

De rest van de diff is implementatiedetail dat niettemin verraadt hoe oud het werk is. Vision- en audio-encoders met hun projectoren, een gedeelde backbone, hybride cache-integratie, CuTe DSL-convolutiekernels met een PyTorch-fallback, en een opmerking dat FlashInfer standaard paged prefill gebruikt zodat sliding-window attention zich gedraagt. Validatie draaide op H100's in FP16 met wat de beschrijving development checkpoints noemt — vier woorden die later van belang zijn.

De zin over de architectuur, en het getal dat mensen verkeerd zullen lezen

De PR beschrijft LFM3 als een gedeelde backbone van gated korte convoluties met volledige en sliding-window-attention. Dat is de voortzetting van de LFM2-lijn, niet een vervanging: LFM2.5-24B-A2B wordt gedocumenteerd als een hybride van gated korte convoluties en grouped-query-attention over 40 lagen. Wat nieuw lijkt in de leak is de expliciete sliding-window-component naast volledige attention.

De validatienotities vermelden een prompt die buiten een schuifvenster van 256 tokens loopt, en dat is het getal dat de hele week uit zijn verband zal worden geciteerd. Het is niet de contextlengte van LFM3. In een hybride ontwerp hoeven de attentielagen alleen lokaal te kijken, omdat de convolutielagen het signaal over lange afstand dragen — dat is het hele uitgangspunt van de architectuur, en dat is waarom de familie op LFM2.5-24B-A2B 131.072 tokens context kan bevatten terwijl de meeste van zijn lagen helemaal geen kwadratische attention doen. Een attentionvenster van 256 tokens zegt iets over waar het model binnen één laag kijkt, niet over hoeveel tekst het kan accepteren. De PR vermeldt de totale context van LFM3 niet, en niemand buiten Liquid weet die nog.

Waarom een runtime pull request het signaal is, niet ruis

Het is begrijpelijk om sceptisch te zijn over het afleiden van productstrategie uit een infrastructuur-diff. In dit specifieke geval is het patroon te consistent om te negeren, omdat Liquid engine-ondersteuning met de gewichten levert in plaats van erna. LFM2.5-2.6B noemt llama.cpp, MLX, vLLM, SGLang, ONNX en Transformers 5.0+ als doelen vanaf dag één. LFM2.5-24B-A2B werd bij de lancering ondersteund in llama.cpp, MLX, vLLM, SGLang en ONNX. Een familie die met vijf kant-en-klare runtimes arriveert, moet zijn kernels vóór de aankondiging geschreven hebben, wat betekent dat de PR's eerst landen en de blogpost volgt.

De auteur past exact in die chronologie. Mazureks openbare geschiedenis is een reeks LFM-integratiewerkzaamheden: DSpark speculatieve decoding voor LFM2-VL in SGLang in september, LFM2.5-VL-3B en DSpark-fixes voor draftmodellen in llama.cpp diezelfde maand, speculatieve decoding overgenomen van het tekstmodel in mlx-vlm, en hergebruik van een LFM2-MoE-configuratie in SGLang op 13 oktober. LFM3 is de volgende vermelding in die reeks, ingediend in het weekend dat de familie van naam veranderde.

Twee afwezigheden zijn net zo veelzeggend als de aanwezigheid. Er is geen overeenkomend pull request in Hugging Face Transformers voor LFM3 — een zoekopdracht in die repository levert niets op — en de SGLang-PR laadt zijn checkpoints via standaard Transformers 5.19.0 met --trust-remote-code, wat je doet wanneer de architectuur nog niet native is voor de bibliotheek. Er is ook een commit die speculatieve decoding voor LFM3 expliciet afwijst, dus het DSpark-werk dat voor de 2.5-generatie is uitgebracht, is nog niet overgenomen. Vroeg, en bewust incompleet.

De vraag over grootte die niemand heeft beantwoord

Hier trekken het lek en de geformuleerde ambitie in tegengestelde richtingen, en die spanning is het meest interessante in het document.

Maxime Labonne, hoofd pretraining bij Liquid, heeft het doel van LFM3 beschreven als het testen of de aanpak met korte convoluties die op de schaal van 350M tot 1,2B werkt, standhoudt voorbij 10B parameters — het regime waarin attention-architecturen historisch gezien het voordeel hebben. Dat is een schaalvraagstuk, en het impliceert een groot model.

De uitgelekte checkpoints zijn 1,7B en drie van 2B. Geen enkele ervan ligt boven de drempel waar die vraag over gaat.

Er blijven twee interpretaties over. De eerste is dat dit de compacte eerste golf is — een omni-familie voor telefoons en auto's voordat er een grote broer arriveert, wat past bij hoe Liquid altijd vooroploopt met kleine modellen en hoe de PR ze beschrijft als ontwikkelcheckpoints in plaats van definitieve releases. De tweede is dat 1.7B en 2B simpelweg de maten zijn die handig waren om kernels tegen te valideren, en ons niets zeggen over wat er uiteindelijk uitkomt. Het eerlijke standpunt is dat de leak bewijst dat de familie bestaat en bewijst wat haar vorm is; het bewijst niet haar plafond. Als je wacht op een Liquid-model van >10B, belooft deze PR er niet een en sluit hij er ook geen uit.

Wat LFM3 erft, ten goede en ten kwade

De baseline die het moet verslaan, is recent en goed gedocumenteerd. LFM2.5-24B-A2B verscheen op 13 oktober 2026 met 24B totale parameters en 2B actief, 40 lagen, 64 experts en top-4-routering, een context van 131.072 tokens, een vocabulaire van 128K en 33T pretrainingstokens. LFM2.5-2.6B, van begin augustus, past in minder dan 2.5GB met een context van 128K. LFM2.5-VL-3B combineert de 2.6B-basis met een SigLIP2-visionencoder.

Om het maar ronduit te zeggen: elke benchmark die Liquid hiervoor publiceert, is door de leverancier uitgevoerd op Liquids eigen harnesses, zonder onafhankelijke evaluatie. De kerncijfers van LFM2.5-24B-A2B — AutomationBench 27.69, BFCLv4 65.01, ToolSandbox 80.71, IFEval 96.75 — zijn cijfers van Liquid, en dezelfde tabel laat zien dat het verliest van Qwen3.6-35B-A3B op WebArena Verified (26.75 tegen 37.62), GPQA Diamond en SWE-Bench Verified. Leverancierstabellen die verliezen vermelden, zijn geloofwaardiger dan tabellen die dat niet doen, maar geloofwaardig is niet hetzelfde als geverifieerd. Er bestaat nog geen enkel LFM3-cijfer, dus er valt nog niets te vergelijken.

Licenties worden ook doorgezet. Liquid's recente LFM-checkpoints op Hugging Face zijn elk getagd met license: other — een op maat gemaakte LFM-licentie, niet Apache-2.0 of MIT. Onder welke licentie LFM3 ook wordt uitgebracht, ga uit van dezelfde aangepaste voorwaarden totdat een modelkaart anders aangeeft, en lees ze voordat je een product op de gewichten bouwt.

Wanneer het daadwerkelijk zou kunnen landen

Niemand heeft een datum, ook de mensen die beroepshalve gokken niet. Een vraag op Manifold Markets over wanneer LiquidAI LFM3 wordt uitgebracht, zet Q4 2026 op 40%, Q1 2027 op 21%, Q2 2027 op 21%, Q3 2026 op 11% en Q2 2026 op 7% — op een totale omzet van ongeveer Ṁ160, wat klein genoeg is dat de percentages een handjevol handelaren weerspiegelen in plaats van een consensus. Lees het als "waarschijnlijk ergens in de komende twee kwartalen", en niet preciezer dan dat.

De technische details pleiten voor eerder dan later. Kernelwerk dat in een grote runtime terechtkomt, is laatfase-engineering, niet vroegfase-engineering — je schrijft geen CuTe-convolutiekernels en sluit geen hybride cache aan voor een model dat nog een jaar weg is. De familienaam is gestabiliseerd naar LFM3 over vier varianten en vier checkpointpaden. Maar de PR is niet gemerged, met alle drie de checks rood, heeft een goedkeurende review nodig die er niet is, en 2 van de 22 omni-validatiechecks en 2 van de 16 vision-checks falen nog steeds hun ROUGE-vergelijking. Dat is een branch midden in de ontwikkeling, geen release candidate.

Wat dit betekent als je deze week een model kiest

Niets aan LFM3 zou een beslissing die je vandaag neemt moeten veranderen. Het is niet beschikbaar, niet geprijsd, niet gebenchmarkt en niet openbaar gelicentieerd. Als je nu een klein multimodaal model nodig hebt, is de LFM2.5-generatie het echte antwoord, en de beperkingen ervan — door de leverancier gerapporteerde scores, een aangepaste licentie en een coderingsprofiel dat zowel de eigen tabellen van Liquid als externe berichtgeving als het zwakke punt bestempelen — zijn de dingen die je moet afwegen.

Waar de leak echt nuttig voor is, is planning. Die vertelt je dat er een compacte omni-familie aankomt, dat die waarschijnlijk in meerdere runtimes tegelijk zal verschijnen, en dat de audiovariant ervan mogelijk geen spraak synthetiseert. Als je roadmap ervan uitging dat Liquid's volgende zet een groter tekstmodel was, ondersteunt het bewijs tot nu toe die aanname niet.

De runtime-fragmentatie is het praktische probleem dat deze familie zal creëren. Liquid's gewoonte om tegelijkertijd naar llama.cpp, MLX, vLLM, SGLang en ONNX te leveren is goed voor de portabiliteit en onhandig voor iedereen die één endpoint wil: vijf engines betekent vijf implementatievormen, vijf sets preprocessing-eigenaardigheden en vijf verschillende data waarop een fix landt. OrcaRouter's catalogus van meer dan 200 modellen bevat vandaag geen enkel LFM-checkpoint, dus er is geen manier om LFM3 er via aan te roepen en niets hier mag worden gelezen als een belofte dat dat wel zal kunnen. Waar een routeringslaag in deze situatie feitelijk voor dient, is de naad tussen een onbewezen model en een productiepad — een deel van het verkeer naar iets nieuws sturen terwijl een bekend model erachter blijft, met failover die de kloof opvangt, is hoe je de opvolger van een niet-uitgebrachte familie evalueert zonder een klantgerichte functie te verwedden op een voorspellingsmarkt van 40%.

De openstaande vragen om in de gaten te houden

Vier dingen zullen dit sneller oplossen dan elke verdere speculatie. Of de vier checkpointpaden echte, downloadbare Hugging Face-repositories worden — op dit moment levert een zoekopdracht in de LiquidAI-organisatie niets op onder LFM3, en de repositories die in de PR worden genoemd, zijn niet openbaar resolveerbaar. Of er een Transformers-PR verschijnt, wat erop zou wijzen dat de architectuur op de juiste manier upstream wordt gebracht in plaats van via remote code te draaien. Of de falende validatiechecks worden gesloten, aangezien 2 van de 22 omni-fouten het verschil vormen tussen een demo en een merge. En of er een >10B-lid van de familie opduikt, de vraag die LFM3 volgens Labonne moet beantwoorden.

Tot die tijd is de meest accurate zin die iemand over LFM3 kan schrijven, de zin waarmee dit artikel begon: er bestaat een pull request, het is niet samengevoegd, en het noemt vier kleine omni-modellen die Liquid AI niet heeft aangekondigd. Dat is een echt signaal — zij het een vroeg signaal, en vroege signalen verdienen het precies zo te worden gelezen.