LFM3-1.7B vs Gemma 4 26B A4B: Två recept för en billig token, och bara en får plats i en telefon

På papperet tar dessa två modeller samma tillvägagångssätt på samma problem. LFM3-1.7B, som annonserades av Liquid AI den 27 oktober 2026, och Gemma 4 26B A4B, som släpptes av Google DeepMind den 2 april 2026, finns båda för att besvara en fråga: hur får man in en kapabel modell i en liten minnesbudget? De ger motsatta svar. Liquid krympte modellen. Google behöll modellen stor och betalar bara för en del av den per token. Vikterna är gratis, så räkningen blir vad den billigaste kompetenta värdleverantören tar ut. Vi för vidare leverantörernas listpriser med 0 % påslag.

Distinktionen låter som arkitekturkuriosa tills man räknar på kostnaden för en driftsättning, och då är den det enda som spelar någon roll. Gemma 4 26B A4B aktiverar 3,8 miljarder parametrar per token, men du måste fortfarande förvara 25,2 miljarder av dem någonstans. LFM3-1.7B aktiverar alla sina 1,73 miljarder parametrar och lagrar exakt lika många. Den ena är billig att beräkna. Den andra är billig att äga.

Två recept på en billig token

Gemma 4 26B A4B är en mixture-of-experts-modell: 128 routade experter plus en delad expert, 30 lager, med ungefär åtta experter som aktiveras per token. Det ger den kunskapskapaciteten hos en dense-modell på 25,2B och beräkningskostnaden för något som ligger närmare 4B. Googles egen formulering är att den når cirka 97 % av MMLU-Pro-poängen för den dense Gemma 4 31B vid ungefär 12 % av FLOPs.

LFM3-1.7B tar den andra vägen. Den är helt tät — varje parameter körs på varje token — och besparingarna kommer från en omdesignad arkitektur snarare än från gleshet. Liquids trihybridstack har 24 lager: 13 gated korta konvolutioner, fem attentionlager med glidande fönster, sex full-attention-lager. Det mesta av sekvensmodelleringen görs av konvolutioner, som är billiga, och full attention förekommer bara sex gånger. Det är så en 1,73B-modell kan hantera en kontext på 262 144 token och en vokabulär på 128 000 token utan att KV-cachen slukar maskinen.

• Totalt antal parametrar — 1,73B för LFM3-1.7B; 25,2B för Gemma 4 26B A4B.

• Aktiva per token — 1,73B mot cirka 3,8B. Detta är den enda raden där de två ligger i samma liga.

• Minne vid 4-bit — ungefär 1 GB mot ungefär 18 GB. Det här är raden som avgör utrullningen.

• Kontext — 262 144 tokens på båda, återigen ett genuint oavgjort resultat.

• Modalitet — endast text jämfört med text- och bildinmatning, med inbyggt funktionsanrop och ett konfigurerbart tankeläge.

• Licens — LFM Open License v1.0, kostnadsfri under 10 miljoner USD i årlig omsättning; Apache 2.0 utan tröskel för Gemma 4 26B A4B.

Varför 3,8B aktiva inte betyder 3,8B minne

Detta är det vanligaste felet när man läser ett datablad för mixture-of-experts, så det är värt att vara tydlig. Aktiva parametrar styr beräkningskostnaden och, löst räknat, hastigheten. De styr inte storleken på filen du laddar ner eller den VRAM du reserverar. Gemma 4 26B A4B behöver alla sina 25,2 miljarder parametrar residenta för att kunna routa mellan experter; i 4-bit hamnar det nära 18 GB. Du kan köra det på ett enda 24 GB-kort, och Google tillhandahåller FP8- och NVFP4-byggen för att göra det praktiskt, men du kan inte lägga det på en telefon.

LFM3-1.7B är cirka 1 GB vid 4-bit – Liquid:s produktkort säger att den får plats i en telefon eller på en laptop, och i den storleken är påståendet trovärdigt snarare än marknadsföring. Den har också en KV-cache på 1,6 GB vid 128K tokens, vilket är siffran som faktiskt avgör hur många samtidiga förfrågningar med lång kontext du kan hålla.

Den praktiska konsekvensen: en driftsättning av 26B-A4B är ett beslut om inferensserver, och en driftsättning av 1.7B är ett beslut om att leverera en applikation. Det är olika projekt med olika team och olika kostnadsstrukturer, och ingen benchmark stänger gapet mellan dem.

Vad varje leverantör publicerade, och vad det säger dig

Google publicerade en omfattande tabell för Gemma 4 26B A4B: 82,6 på MMLU-Pro, 82,3 på GPQA Diamond, 88,3 på AIME 2026 utan verktyg, 77,1 på LiveCodeBench v6, en Codeforces-Elo på 1718, 73,8 på MMMU-Pro och 44,1 på MRCR v2 vid 128K med åtta nålar. Allt är leverantörsrapporterat, inget har reproducerats oberoende. Tredjepartsspårning placerar dess LMArena-Elo nära 1438.

Liquid har publicerat en snävare tabell för LFM3-1.7B, och den är inriktad mot agentiskt arbete: 71,39 på BFCL V4, 80,36 på ToolSandbox, 68,01 på τ³-bench, 45,60 på LiveClaw, 38,42 på WebArena-Verified. Den rapporterar också 96,66 på IFEval, 73,03 på IFBench, 63,37 på GPQA Diamond, 73,46 på LiveCodeBench v6 och 65,56 på RULER vid 128K. Liquid publicerar ingen MMLU-Pro-siffra för LFM3-1.7B, och frånvaron är inte en nolla – den är helt enkelt inte uppmätt.

Endast LiveCodeBench v6 och GPQA Diamond överlappar rent. Gemma 4 26B A4B vinner båda, med 3,6 respektive 18,9 poäng. Där Liquids svit blir agentisk finns det inget Gemma-tal att jämföra med – Google rapporterar τ²-bench på 68,2, och τ² är inte τ³, så att placera 68,01 bredvid det skulle vara en fabricerad jämförelse utklädd till en noggrann sådan.

Där 1.7B stannar kvar i konversationen

En skillnad på 3,6 punkter i LiveCodeBench är mindre än vad parameterförhållandet 14 mot 1 skulle förutsäga, och orsaken är arkitektonisk. Tävlingsprogrammering belönar förmågan att hålla kvar ett mönster och producera en korrekt funktion – en färdighet som drar mer nytta av en ren träningssignal än av rå kapacitet. Om kodningsfrågor vore hela uppgiften skulle 26B vinna och det här avsnittet vara kort.

Det som faktiskt gör LFM3-1.7B relevant är kombinationen av en kontext på 262 144 token och ett minnesavtryck på 1 GB. En modell som kan hålla ett stort dokument och köras på enheten som läser det är en annan produkt än en som kan hålla samma dokument på en server. Liquid rapporterar 65,56 på RULER vid 128K, vilket inte är en spektakulär långkontextpoäng — Gemma 4 26B A4B rapporterar 81,4 i samma benchmarkfamilj — men den mäts överhuvudtaget, på enheten, vid en gigabyte.

Och när det gäller instruktionsföljning gör den lilla modellen inte bort sig: 96,66 på IFEval och 73,03 på IFBench är starka siffror för den här storleksklassen, båda rapporterade av leverantören. För en arbetsbelastning med verktygsanrop eller strukturerad utdata är det närmare det mått som spelar roll än vad GPQA Diamond är.

Vad routningslagret faktiskt ändrar

Gemma 4 26B A4B finns i OrcaRouter-katalogen — en och samma API-nyckel når den tillsammans med fler än 200 andra modeller, med leverantörernas listpriser förda vidare utan påslag (0 %), så en leverantörs prisändring slår igenom samma dag i stället för att vänta på en omprissättningscykel. Det spelar större roll här än det vanligtvis skulle, eftersom detta är en modell vars ekonomi helt och hållet handlar om leverantörsprissättning: vikterna är gratis, så räkningen blir vad den billigaste kompetenta värden tar ut, och den siffran förändras.

Automatisk failover är den andra halvan. En 26B mixture-of-experts-modell med 256K kontext är precis den typ av arbetsbelastning som slår i kapacitetstak vid toppbelastning, och routning mellan leverantörer innebär att en enskild värds dåliga eftermiddag inte är ditt avbrott. LFM3-1.7B behöver inget av detta, eftersom den körs på hårdvara du kontrollerar och inte har någon leverantör att växla över från. Det är inte ett argument för eller emot den — det är en följd av att välja det andra receptet.

En ärlig formulering av vår roll: vi dirigerar den stora glesa modellen, vi betjänar inte den lilla täta, och beslutet mellan dem är inte något som en router kan fatta åt dig.

Fatta beslut i ett svep

Om driftsättningsmålet har mindre än 20 GB minne – en telefon, en bärbar dator, en Jetson, en AI-dator – är Gemma 4 26B A4B inte en kandidat och jämförelsen är avgjord. Välj LFM3-1.7B, planera retrieval kring det kunskapsgap som Liquid själva påpekar och använd den för verktygsanrop och strukturerad extraktion där dess siffror är genuint konkurrenskraftiga.

Om du kör på en GPU och arbetsbelastningen är kunskapsintensiv, multimodal eller kräver resonemang i klass med 82.3 på GPQA Diamond och 82.6 på MMLU-Pro, är Gemma 4 26B A4B den bättre modellen och 18 GB är inträdesbiljetten. Apache 2.0 tar bort licensdiskussionen helt, vilket för en stor organisation är värt mer än några benchmarkpoäng.

Om du bygger en produkt som levereras i båda formerna — en assistent på enheten som eskalerar svåra frågor till en server — är de två inte konkurrenter alls. De är de två nivåerna i en och samma arkitektur, och den intressanta ingenjörsfrågan är var du drar eskaleringsgränsen, inte vilken modell som vinner en tabell.

Den öppna frågan är inte förmågan, som är avgjord till Googles fördel, utan huruvida en 1 GB-modell med 256K-kontext är tillräckligt bra för de smala agentiska uppgifter som de flesta produkter på enheten faktiskt behöver. Liquids eget modellkort är ovanligt uppriktigt om att det inte är en resonemangsmodell. Den uppriktigheten är värd mer än LiveCodeBench-gapet, eftersom den talar om vilken hälft av din arbetsbelastning som ska skickas vart.