Vi introducerar LFM3: sex 2B-modeller, ett backbone och ett 256-tokenfönster som inte är kontext

Liquid AIs LFM3-familj lanserades den 27 oktober 2026 som sex checkpoints i 2B-klassen i stället för en enda flaggskeppsmodell: LFM3-1.7B för text, LFM3-VL-2B för bild, LFM3-Audio-2B för tal, LFM3-Omni-2B för allt på en gång, plus två beslutsmodeller, d1-2B och d1-omni-2B. Alla sex härstammar från en enda förtränad basmodell, LFM3-1.7B-Base, som Liquid också släppte. Företagets positionering är "specialiserad intelligens" – en medveten vägran att lansera en liten generalist och konkurrera på fel axel.

Inom ett dygn efter tillkännagivandet hade ett nummer i den tekniska beskrivningen redan missförståtts. LFM3:s arkitektur listar lager med sliding-window-attention och ett fönster på 256 token. Det är attentiongeometrin per lager, inte modellens kontextlängd. Textmodellen tar 256K token i kontext. Läsare som skummade lagertabellen och drog slutsatsen att Liquid hade släppt en 2026-modell med ett minne på 256 token har fel modell i huvudet, och det är värt att rätta till innan något annat i den här texten går att förstå.

Vad tri-hybridarkitekturen faktiskt är

LFM3 ersätter LFM2:s tvåvägsmix med tre lagertyper staplade i en stomme med 24 lager. Tretton lager är gattade korta faltningar, fem är sliding-window-attention med ett fönster på 256 tokens och sex är fullständig global attention. Faltningskärnan breddas från 3 till 7. Tre mindre ändringar följer med: en sigmoidgrind som skalar utdata från varje attention-head oberoende av varandra, partiella rotary-embeddings i de globala lagren som endast roterar den högstfrekventa halvan av varje head, och en sandwich-normalisering som betingar både indata och utdata för varje block.

Satsningen bygger på att korta faltningar billigt bär det mesta av den lokala strukturen, att gles uppmärksamhet hanterar medelavståndet och att en tunn del global uppmärksamhet syr ihop hela 256K-fönstret. Det är därför KV-cachen hålls tillräckligt liten för att spela roll – Liquid rapporterar en fullständig cache på 128K token vid 1,6 GB, jämfört med 4,3 GB för Qwen3.5-4B och 5,6 GB för MiniCPM5-2B i samma mätning. Själva textmodellen får plats i cirka 1 GB vid 4-bitars precision.

Träningen genomfördes i fyra steg: 22 biljoner förträningstokens, en mellanträningsfas på 3,5 biljoner tokens med mycket agentiska spår och verktygsanrop som också utökade kontexten till 256K, övervakad finjustering på 1,75 biljoner tokens och sedan blandad förstärkningsinlärning kombinerad med flerdomäns on-policy-distillation från sex specialiserade lärarmodeller. Ordförrådet är på 128K tokens, delas med LFM2.5-8B-A1B och är byggt för att tokenisera icke-latinska skriftsystem effektivare än sin föregångare.

De sex modellerna, och var deras kontext hamnar

Liquid är tydliga med att dessa är syskon, inte nivåer. Var och en utgår från samma stomme och är eftertränad för en annan utdataform.

• LFM3-1.7B — tät text- och agentmodell, 1,73B parametrar, 256K kontext, inbyggt verktygsanrop och strukturerad utdata.

• LFM3-VL-2B – vision-språk, 1,9 miljarder parametrar, med en egenutvecklad visionskodare som Liquid säger behöver ungefär en tredjedel av SigLIP2:s beräkningskraft.

• LFM3-Audio-2B — ASR, TTS, talöversättning och ljudförståelse, med en egenutvecklad encoder plus LiquidCodec.

• LFM3-Omni-2B — Liquids första omnimodell: text, bild, video och ljud in, text eller tal ut.

• d1-2B — en beslutsmodell byggd från visionsgrenen som besvarar strukturerade frågor i ett enda framåtpass med kalibrerade sannolikheter i stället för fri prosa.

• d1-omni-2B — samma beslutsgränssnitt på omni-grenen.

Kontextfönstren är inte enhetliga, och det är detaljen som de flesta artiklar om lanseringen utelämnade. Liquid publicerar ett fönster för textmodellen och basmodellen – 256K, indata och utdata tillsammans – och för ingen av de övriga fyra. Varken tillkännagivandet eller modelldokumentationen anger en kontextlängd för LFM3-VL-2B, LFM3-Audio-2B, LFM3-Omni-2B eller någon av beslutsmodellerna. I tredjepartstexter har det cirkulerat 128K för visionsmodellen och 32K för omnimodellen, och de siffrorna kan mycket väl stämma, men den 28 oktober finns de inte på Liquids egna sidor. Om du planerar en agent som läser långa dokument och även tittar på skärmbilder kan du för närvarande inte alls avgöra omnimodellens kontext utifrån förstapartsdokumentation. Det är en lucka värd att lyfta fram i stället för att fylla i från en blogg som har fyllt i den från någon annanstans.

Benchmark-tabellen, ärligt läst

Alla prestandasiffror nedan är Liquids egna, framtagna med Liquids eget testramverk, och inget av det har replikerats oberoende. Per den 28 oktober 2026 finns det ingen LFM3-post på Artificial Analysis – inget Intelligence Index, ingen hastighets- eller latensmätning från en neutral part. Det spelar större roll här än vanligt, eftersom jämförelsen som lanseringen lutar sig mot är en jämförelse i samma testramverk, vilket smickrar den modell som testramverket har anpassats för.

LFM3-1.7B får 49,37 i Liquid's genomsnitt över 27 benchmarker. Företagets egen LFM2.5-2.6B får 31,55 på samma uppsättning, och det är därifrån påståendet om "35 % färre parametrar" kommer. De intressanta raderna är inte genomsnittet:

• Verktygsanvändning — BFCL V4 71.39, ToolSandbox 80.36, τ³-bench 68.01, MCP-Atlas 32.57.

• Agentisk webb — WebArena-Verified 38,42, AutomationBench 41,29, BrowseComp-Plus 37,00, LiveClaw 45,60.

• Agentisk kodning — SWE-bench Verified 43,40, SWE-bench Multilingual 23,00, Terminal-Bench 2.1 på 12,92.

• Instruktionsföljning — IFEval 96.66, IFStruct 93.72, IFBench 73.03, Multi-IF 89.10.

• Kunskap — GPQA Diamond 63,37, HLE 7,17 utan verktyg och 13,90 med dem.

• Lång kontext — RULER 128K 65,56, AA-LCR 52,83.

Läst som en form snarare än en totalsumma är profilen sammanhängande: mycket stark instruktionsföljsamhet, respektabel verktygsanropning i enstaka tur och ett brant fall när en uppgift kräver många sekventiella steg. Terminal-Bench 2.1 på 12,92 och SWE-bench Multilingual på 23,00 är inte siffror man bygger en autonom kodningsagent på. Liquid döljer inte detta – modellkortet styr användare bort från komplext resonemang och kodning i flera steg, vilket är en ovanligt direkt positionering från en leverantör på lanseringsdagen.

Effektivitets påståendena är den andra halvan av pitchen. Vid Q4_0 och 32K kontext säger Liquid att LFM3-1.7B var den snabbaste modellen på alla tre testenheterna, 1,8× till 2,8× snabbare än nästa konkurrent med lägst minnesavtryck. På en enda NVIDIA B300 med SGLang i BF16 betjänade den 3,6 miljarder token per dag vid 1 024 samtidiga förfrågningar. Företaget körde också mer än 300 000 LFM3-1.7B-agenter parallellt över Enron-e-postarkivet som en stresstestdemonstration. Det är leverantörssiffror, ej granskade, men det är den typen av siffror som är svåra att tyst överdriva.

Licens och vad det kostar att driva

Vikterna finns på Hugging Face i BF16-, FP8-, NVFP4-, GGUF-, MLX- och ONNX-versioner, med stöd från dag ett i vLLM, SGLang, Transformers, llama.cpp, MLX, ONNX Runtime, Ollama och LM Studio. Licensen är LFM Open License v1.0: royaltyfri kommersiell användning under 10 miljoner USD i årliga intäkter, med ett separat avtal över det. Det tröskelvärdet, inte parameterantalet, är gränsen som avgör om LFM3 är gratis för ett givet företag.

Liquid driver också ett hostat API, och där är den offentliga informationen mindre omfattande än lanseringen antyder. Dokumentationen listar modell-ID:t och en gräns på 256K för input plus output, men ingen prislista. Tredjepartsrapportering anger att den hostade taxan för LFM3-1.7B ligger på ungefär 0,08 USD per miljon inputtokens och 0,20 USD per miljon outputtokens, medan varianterna vision, audio, omni och decision är dyrare; Liquid har inte publicerat dessa siffror på sina egna sidor, så betrakta dem som rapporterade snarare än bekräftade. Självhosting har däremot inget pris per token alls – kostnaden är maskinen, och i 4-bit kan den maskinen vara en telefon.

Där OrcaRouter passar – och där det inte passar

LFM3 finns inte i OrcaRouter-katalogen, och vi tänker inte låtsas något annat. Det är programvara med öppna vikter som du kör själv eller anropar via Liquids eget API. Det routern är bra på är lagret runt omkring. En specialist på 1,7B är sällan den enda modellen i en pipeline: den hanterar verktygsanropet, klassificeringen eller extraheringen, och något större hanterar den tur som kräver omdöme. OrcaRouter sätter de hostade modellerna bakom en nyckel med 0 % påslag – leverantörens listpris går rakt igenom – så eskaleringsvägen från LFM3 till en frontier-modell blir en routingregel i stället för ett andra avtal. Dess automatiska failover är som viktigast just för den arbetsbelastning som LFM3 riktar sig mot, där en enda liten modell är det enda som står mellan en förfrågan och ett fel.

Routing-DSL:en är den mer intressanta passningen. Att kombinera en specialist med en generalist i ett enda anrop – LFM3-format arbete som dirigeras till en liten modell, allt annat som faller igenom till en hostad sådan – är det driftsmönster som den här familjen byggdes för. Liquid:s hela argument är att en 2B-modell slår en frontier-modell på en smal uppgift till en bråkdel av kostnaden. En router är hur du fångar den besparingen utan att satsa hela pipelinen på den.

Vad du ska titta på

Den öppna frågan är inte huruvida LFM3 är bra på det den påstår. Det är huruvida påståendena överlever en testrigg som Liquid inte skrev. Familjens agentiska siffror är de som först bör testas igen, eftersom WebArena-Verified på 38,42 och AutomationBench på 41,29 ligger långt över vad en 1,7B-modell historiskt har klarat, och agentiska benchmarkar är mest känsliga för prompt-scaffolding och återförsökspolicy. En oberoende körning som hamnar inom några punkter från Liquids tabell skulle göra LFM3 till standardvalet för verktygsanrop på enheten. En körning som hamnar tio punkter lägre skulle göra den till en bra instruktionsföljare med en överdriven agentberättelse.

Tills den körningen finns är den ärliga sammanfattningen denna: LFM3 är en välkonstruerad, ovanligt frispråkig liten modellfamilj med en genuint nydanande lagerblandning, en verklig minnesfördel, publicerade vikter vid en användbar licensnivå och ingen oberoende verifiering av något av huvudbenchmarkarna. Fönstret på 256 token i arkitekturtabellen är inte kontextlängden. Allt annat i lanseringen är värt att ta för gott tills någon bevisar motsatsen – och värt att mäta själv innan du sätter det framför användare.