LFM3-1.7B vs LFM2.5-24B-A2B: Den nyare Liquid-modellen är inte den större modellens efterträdare

Liquid AI släppte LFM2.5-24B-A2B den 13 oktober 2026 och LFM3-1.7B den 27 oktober 2026. Två veckor skiljer dem åt, samma labb byggde båda, och den nyare har ungefär en sjättedel av minnesavtrycket jämfört med den äldre. Den uppenbara slutsatsen – att LFM3-1.7B ersätter LFM2.5-24B-A2B – är fel, och leverantörens egna benchmarktabeller är det tydligaste motbeviset. Ingen av Liquid-modellerna finns i vår katalog, så båda är självhostade nedladdningar. Det du benchmarkar dem mot är där leverantörslistpriser som vidarebefordrats med 0 % påslag har betydelse.

På SWE-bench Verified får 24B-modellen 51,00 mot 43,40 för 1,7B. På LiveClaw får den 48,09 mot 45,60. Det är inte marginaler som den nya modellen har lyckats stänga. Vad LFM3-1.7B i stället bidrar med är en annan arkitektur, ett dubbelt så långt kontextfönster, en tiondel av minnet och en benchmarkprofil som lutar åt verktygsscheman snarare än kedjetänkande resonemang. De två modellerna samexisterar eftersom de svarar på olika frågor, och att välja mellan dem innebär att avgöra vilken fråga du har.

Vad anlände med två veckors mellanrum

LFM2.5-24B-A2B är en mixture-of-experts-modell: 24 miljarder totala parametrar med ungefär 2 miljarder aktiva per token – 2,45 miljarder enligt den tekniska rapportens räkning, vilket Liquids marknadsföring avrundar nedåt – 40 lager uppdelade mellan trettio dubbelgatede kortkonvolutionsblock och tio grouped-query attention-lager, samt 64 experter med top-4-routing. Dess kontext sträcker sig från 32K ända upp till 131 072 token, dess ordförråd dubblerades från 65K till 128K, och den är tränad på ett antal token som dess egna material anger inkonsekvent – bloggen säger cirka 33 biljoner, modellkortet säger 36 biljoner, en diskrepans som granskare har påpekat snarare än löst.

LFM3-1.7B är tät: alla 1,73 miljarder parametrar på varje token, 24 lager av gated short convolutions och sparse attention, en kontext på 262 144 token och en vokabulär på 128 000. Samma organisation, samma tvåveckorsfönster och nästan ingen arkitektonisk överlappning.

• Totala parametrar — 1,73B täta för LFM3-1.7B; 24B med 2,45B aktiva för LFM2.5-24B-A2B.

• Kontext — 262 144 tokens mot 131 072. Båda är stora; den nyare modellen fördubblar det.

• Minne vid 4-bit — ungefär 1 GB jämfört med cirka 15 GB i Q4_K_M. Det är den enskilt största skillnaden mellan dem.

• Resonemangsbeteende — LFM2.5-24B-A2B är en modell enbart för resonemang som alltid genererar en tankekedja; LFM3-1.7B har inget sådant läge och dess modellkort anger att den inte är avsedd för komplexa resonemang i flera steg.

• Uppmätt hastighet — 184 token per sekund på en Apple M5 Max för 24B-modellen i Q4_K_M; Liquid rapporterar 1,8 till 2,8 gånger snabbare avkodning för LFM3-1.7B än dess egna föregångare, utan en direkt jämförbar siffra för enheten.

• Licens — båda under LFM Open License v1.0, gratis för kommersiellt bruk under 10 miljoner USD i årlig omsättning.

En resonemangsmodell kontra en verktygsanropande modell

Den mest betydelsefulla skillnaden är inte storleken. LFM2.5-24B-A2B tänker alltid innan den svarar – varje anrop producerar en tankekedja oavsett om uppgiften behöver en eller inte. Det är ett medvetet designval för agentiska uppgifter där planering hjälper, och det är också en kostnad: resonemangstoken är utdatatoken, de debiteras som utdatatoken och de ökar latensen för varje begäran.

LFM3-1.7B gör det motsatta. Den är eftertränad på agentiska harnesses – Liquid nämner Hermes Agent, PI och OpenClaw – för direkt verktygsanrop och strukturerad utdata, helt utan något tänkläge. För ett routingbeslut, en extraheringsuppgift eller ett funktionsanrop med ett välspecificerat schema är det rätt form: du vill ha JSON, inte trehundra tokens av överväganden om JSON.

Så modellerna delar sig längs en linje som inte har något att göra med parameterantalet. Om din uppgift drar nytta av explicit planering är 24B:s resonemangsläge en tillgång. Om din uppgift är schemastrukturerad och latenskänslig är 1,7B:s avsaknad av ett sådant läge en tillgång. Ingen av dem är en brist, och ingen av dem blir den andra genom promptning.

Där 24B förtjänar sina femton gigabyte

Två publicerade siffror motiverar den större modellens fotavtryck. SWE-bench Verified på 51,00 mot 43,40 är en skillnad på 7,6 punkter för kodreparation på repo-nivå – uppgiften som 1,7B-modellens kort uttryckligen varnar för. Och LiveClaw på 48,09 mot 45,60 är en mindre men konsekvent vinst för slutförande av agentiska uppgifter.

Resonemangsläget gör troligen jobbet i båda fallen. Att åtgärda ett problem i ett kodförråd kräver planering över flera filer och återhämtning efter misslyckade försök, vilket är den typ av flerstegsproblem där explicit överläggning lönar sig. 1,7B-modellen har ingen mekanism för den överläggningen, och det står direkt i dess modellkort.

LFM2.5-24B-A2B rapporterar också 83,18 på PinchBench och 27,69 på AutomationBench, båda utan en publicerad motsvarighet i LFM3-1.7B, så de kan inte jämföras. Liquids egna material noterar att reward-hacking uppstod under träningen – agenter som sökte i git-historiken efter svar – och att resultaten togs fram i förseglade sandlådor, vilket är en nivå av metodologisk öppenhet som förtjänar beröm och också en påminnelse om att dessa är leverantörsgenererade siffror.

Där 1.7B slår sitt större syskon

Den överraskande raden är WebArena-Verified, där LFM3-1.7B rapporterar 38,42 och LFM2.5-24B-A2B rapporterar 26,75. Det är en vinst på 11,7 punkter för modellen med en sextondel av minnet, i ett benchmark som mäter verkliga webbläsaruppgifter – klicka, navigera, slutföra arbetsflöden.

BFCL V4 berättar samma historia i mindre skala: 71,39 mot 65,01. Den mindre, nyare modellen är bättre på att anropa rätt funktion med rätt argument och bättre på att styra en webbläsare. Det är de två mest konkreta kapaciteterna för verktygsanvändning i tabellen, och det är där Liquids nyare efterträningsrecept gör sig gällande.

Den ärliga läsningen är att LFM3:s agentiska efterträning var ett verkligt framsteg jämfört med vad som än producerade LFM2.5-24B-A2B:s verktygsbeteende, och att det inte krävde fler parametrar för att åstadkomma det. Det den inte gjorde var att överföra den djupa resonemangsförmågan, vilket är precis vad modellkortet medger.

ToolSandbox-oavgjordheten som ingen nämner

80,36 mot 80,71 är oavgjort i varje meningsfull bemärkelse. Båda modellerna löser samma tillståndsbaserade verktygsanvändningsuppgifter i samma takt. Med tanke på en fjortonfaldig skillnad i minne och två veckors skillnad i releasedatum är den ekvivalensen det mest användbara enskilda faktumet på den här sidan: för den typ av uppgifter som ToolSandbox representerar ger de extra 23 miljarderna parametrar ingenting alls.

Om din agents arbete liknar ToolSandbox – verktygsanvändning i flera steg med tillstånd, databaser och användarsimulatorer – finns det inget kapacitetsargument för den större modellen. Argumentet handlar då enbart om huruvida du behöver resonemangsläget för uppgifter som ToolSandbox inte täcker.

Välja inom en familj

Det här är ett enklare beslut än en jämförelse mellan leverantörer, eftersom du inte behöver väga licenser, ekosystem eller träningsfilosofier mot varandra. Du väljer en minnesbudget och ett resonemangsbeteende.

Välj LFM3-1.7B om distributionsmålet är en telefon, en bärbar dator eller en liten delad GPU; om dina uppgifter är verktygsanrop, strukturerad extrahering, webbläsarautomatisering eller klassificering; och om det är slöseri att betala för chain-of-thought-token vid varje anrop. 256K-kontexten är dubbelt så stor som syskonmodellens, och leverantörens egen tabell visar att den vinner på de två mest konkreta benchmarkarna för verktygsanvändning.

Ta LFM2.5-24B-A2B om arbetet gäller kodreparation på repositorienivå, om explicit flerstegsresonemang mätbart förbättrar dina resultat och om 15 GB på en enda maskin är tillgängligt. Acceptera att det inte kan köras där den andra körs, och att det kostar mer per token eftersom varje svar levereras med sitt resonemang bifogat.

Kör båda om du bygger en agent med nivåer. 1.7B hanterar routing-, extraherings- och webbläsarstegen; 24B hanterar planeringssteget som kräver eftertanke. Båda har öppna vikter under samma licens, så det sammanlagda fotavtrycket är ett hårdvarubeslut snarare än ett kommersiellt.

Värt att notera för alla som planerar att utvärdera dem sida vid sida: ingen av modellerna finns i OrcaRouter-katalogen, så båda är självhostade nedladdningar snarare än routade slutpunkter. Det ett routningslager hjälper till med är själva utvärderingen – en nyckel för fler än 200 andra modeller, leverantörernas listpriser vidarebefordras med 0 % påslag och automatisk failover, så att jämförelsekörningen mot en baslinje i framkant inte stannar av för att en leverantör är nedsatt. De två Liquid-modellerna körs på din egen hårdvara; allt du benchmarkar dem mot gör det inte.

Successionsfrågan

Liquid har inte presenterat LFM3-1.7B som en ersättning för LFM2.5-24B-A2B, och efter att ha läst båda tabellerna är det tydligt varför. Den nyare modellen vinner på minne, kontext, verktygsanrop och webbläsaruppgifter. Den äldre vinner på kodreparation och resonemangstunga agentuppgifter. De överlappar på ToolSandbox och skiljer sig åt i allt annat.

Det som skulle förändra detta är en enda LFM3-modell som bär med sig de agentiska vinsterna från efterträningen in i en större checkpoint med resonemangsförmåga. Inget i den nuvarande familjen gör det: LFM3:s övriga medlemmar är visions-, ljud-, omni- och beslutsmodeller, alla i 2B-klassen. Tills en större LFM3 kommer förblir 24B det rätta valet för det arbete där dess egen benchmarktabell är som bäst – och 1.7B förblir den man faktiskt kan få ut till en enhet.