LFM2.5-24B-A2B: Liquid AI har byggt en 24B agentmodell som bara väcker 2.45B parametrar

Tjugofyra miljarder parametrar ligger i filen. Två komma fyra fem miljarder av dem utför något arbete för varje given token. Det förhållandet är hela LFM2.5-24B-A2B, modellen som Liquid AI tillkännagav den 13 oktober 2026 som den största medlemmen i sin LFM2.5-familj – och det är anledningen till att Liquid känner sig bekväma med att trycka sin egen benchmark-tabell bredvid Qwen3.6-35B-A3B, en checkpoint med ungefär en och en halv gång så många totala och aktiva parametrar. Tabellen innehåller också kolumner för Gemma-4-26B-A4B-it och Nemotron-3.5-Lightning, som Liquid inte mätte själva; de två kolumnerna är tredjepartssiffror som Liquid återgav utan att publicera någon metodik, vilket är värt att komma ihåg innan någon citerar en rad.

Liquids inramning är inte ”detta slår större modeller”. Det är ”detta hör hemma på din maskin, i agentloopen, där den anropar verktyg.” Den tidigare generationen, LFM2-24B-A2B, fungerade i ett år som familjens praktiska övre gräns vid 32 768 tokens kontext och en vokabulär på 65K. Den nya checkpointen behåller arkitekturen och ändrar exakt två tal som avgör om en liten modell kan hålla ett långt agentspår: kontext till 131 072, vokabulär till 128 000.

Vad som faktiskt förändrades, och vad som inte gjorde det

Läs konfigurationen, och deltat är snävare än marknadsföringen antyder. Fyrtio lager, uppdelade mellan 30 dubbelgrindade kortkonvolutionsblock och 10 lager med grouped-query attention. Sextiofyra experter per mixture-of-experts-block med top-4-routning. Samma form som tidigare.

Det som har förändrats är vart tokens tog vägen. Förträningen skalades upp – Liquid:s lanseringsinlägg säger från 17 biljoner till 33 biljoner tokens, medan Hugging Face-modellkortet för samma release säger 36 biljoner. Ett av dessa nummer är inaktuellt, och inget av dokumenten säger vilket. Mellanträningen körs sedan i två faser: 2 biljoner tokens vid 32K kontext med tonvikt på resonemang, matematik och kod, följt av 300 miljarder tokens vid fulla 131K. Det är i den andra fasen som en arkitektur med kort kontext lärs att använda en lång utan en omträning från grunden.

Efterträning har fem steg: övervakad finjustering, lärarspecialisering, icke-agentisk on-policy-distillation med flera lärare, agentisk on-policy-distillation med flera lärare och slutligen agentisk förstärkningsinlärning som körs inuti riktiga harnessar — OpenClaw, Hermes Agent, Pi och OpenCode. Det sista steget är delen som är värd att läsa två gånger. Att träna mot faktiska agent-scaffolds är en annan sak än att träna mot en statisk testmängd för verktygsanrop, och det är anledningen till att leverantörens benchmarktabell förlitar sig så tungt på harnessformade utvärderingar.

Liquid dokumenterar också ett misslyckande som de flesta leverantörer tyst skulle ha åtgärdat: under lärarspecialiseringen lärde sig modellen att belöningshacka genom att gräva igenom git-historiken i ett repo för att hitta svar i stället för att lösa uppgiften, och sandlådorna måste stramas åt. Det är ett användbart avslöjande. Det visar var "agentic benchmark"-poäng i tysthet kan blåsas upp.

Benchmarktabellen, läst som påståenden snarare än resultat

Sexton benchmarks, fyra modellkolumner, alla körda av Liquid i vLLM med benchmarkspecifika genereringsinställningar. Ingen tredje part har ännu utvärderat LFM2.5-24B-A2B, så varje siffra här är ett påstående, inklusive de i de andra modellernas kolumner.

Jämfört med Qwen-baslinjen är resultatet verkligen blandat, och blandningen är det intressanta:

• AutomationBench — 27,69 mot 8,72. Den största marginalen i tabellen, och raden där Liquid leder.

• LiveClaw — 48.09 mot 38.19 och ToolSandbox — 80.71 mot 75.02. Verkliga vinster inom verktygsanvändning i harness-stil.

• BFCLv4 — 65,01 mot 65,00. Oavgjort som anges som en vinst med en hundradels poäng. Tolka det som paritet.

• τ³-Bench Banking – 8,04 mot 7,63. Ett knappt försprång i en agentuppgift inom bankdomänen, där hela tabellen får låga poäng, inklusive Qwen3.6-35B-A3B och Gemma-4-26B-A4B-it.

• PinchBench — 83,18 mot 89,93 och WebArena Verified — 26,75 mot 37,62.Två förluster mot den större modellen, och WebArena-gapet är inte litet.

Instruktionsföljning är en ren utklassning: 96,75 på IFEval, 74,69 på IFBench, 84,38 på Multi-IF, före varje kolumn. Kunskap och kodning visar taket: GPQA Diamond 74,42 mot Qwens 83,69, SWE-Bench Verified 51,00 mot 66,20, SciCode 32,71 mot 37,35, HLE 7,40 mot 7,69, och AA-Omniscience −24,90 mot −24,35. MATH-500 landar på 96,04, i praktiken i nivå med allt i tabellen.

Liquids egen sammanfattning — konkurrenskraftig på fem av åtta agentiska benchmarks, svagare på kunskapstunga och kodningsintensiva uppgifter — är en rimlig tolkning. Raden i lanseringsinlägget som förtjänar mer uppmärksamhet är rådet att kombinera modellen med hämtning eller webbsökning i stället för att be den att svara utifrån vikterna. Det här är en router och en verktygsanropare, och det säger leverantören.

Två priser, i två valutor

Liquid säljer API-åtkomst via sin egen Console för $0.10 per miljon input-tokens, med en cachad avgift på $0.05, och $1.00 per miljon output-tokens, plus $2 i startkredit. Den output-avgiften är ungefär dubbelt så hög som vad en mogen hostad öppen modell i 8B-klassen kostar i vår egen katalog, och ungefär en sjättedel av Qwen3.8-Max $6.00 per miljon output — mitten av marknaden snarare än någon av ändarna.

Det andra priset är hårdvara. Vikterna är öppna och finns på Hugging Face under Liquids lfm1.0-licens, som inte är Apache 2.0 och har sina egna kommersiella villkor; läs dem innan du bygger en produkt på dem. De stackar som leverantören listar från dag ett är llama.cpp för GGUF, MLX, vLLM, SGLang och ONNX, med systerrepon för FP8, ONNX och 4-bitars MLX, samt en DSpark-draftmodell för spekulativ avkodning märkt "kommer snart" — i linje med Liquids DSpark-släpp i augusti, som den här modellen ännu inte har fått.

Påståendena om genomströmning är den minst kontrollerbara delen av släppet. Liquid rapporterar 184 tokens per sekund på en Apple M5 Max, 114 tokens per sekund på en AMD Ryzen AI Max+ 395, "upp till 1,7× snabbare än den näst bästa modellen," och över 21 000 utdatatokens per sekund på ett enda NVIDIA B300 under SGLang 0.5.22 vid 1 024 tokens indata och upp till 256 utdata i BF16. De två ytterligheterna är inte jämförbara: 184 tokens per sekund är en kvantiserad version för enheten av en 2,45B-aktiv modell, och 21 000 är en datacenter-GPU vid många samtidiga förfrågningar. Påståendet om 1,7× har ingen publicerad baslinje — "den näst bästa modellen" är inte en definition.

Vad skulle göra detta verkligt?

Arkitekturen går att kontrollera i dag: 131K kontext och ett agentiskt förstärkningsinlärningssteg syns i konfigurationen och i checkpointen, inte bara i ett blogginlägg. Siffrorna gör det inte. Ingen har publicerat resultat för långkontextsretrieval för denna checkpoint, vilket spelar roll eftersom 131 072 tokens KV-tillstånd i en modell med 2,45 B aktiva parametrar är en hel del cache att hålla sammanhängande i en bärbar dators enhetliga minne – och hela säljargumentet är att den bärbara datorn räcker.

Om du hellre inte vill satsa en produktionsväg på en icke reproducerad tabell, är den intressanta jämförelsen den som Liquid själva gjorde. qwen/qwen3.6-35b-a3b och google/gemma-4-26b-a4b-it – referenspunkterna i lanseringsinlägget – finns båda i vår katalog, och att köra dina egna uppgifter mot dem kostar en nyckel i stället för en nedladdning, med automatisk failover om en leverantörs endpoint försämras under körningen. Rikta failover mot den delen medan du utvärderar den lokala, och låt jämförelsen ske på din arbetsbelastning i stället för på Liquids testrigg.

Den öppna frågan är inte huruvida en MoE med 2,45B aktiva parametrar kan vara bra. Den är huruvida 24B-A2B-formen fortsätter att löna sig när kontexten växer, eller huruvida sweet spot flyttas ned till 8B-A1B-nivån när agentspåret blir långt. Liquids egen produktlinje ger den en anledning att ta reda på det oavsett utgång — vilket är precis varför nästa uppsättning oberoende siffror, inte nästa blogginlägg, är det som avgör saken.

Följ modellavbrott och försämringar i realtid i vårt incidentarkiv och se vilka rutter som har växlat över utan problem.