LFM3-1.7B vs Gemma 4 26B A4B: twee recepten voor een goedkope token, en alleen één ervan past op een telefoon

Op papier hanteren deze twee modellen dezelfde aanpak voor hetzelfde probleem. LFM3-1.7B, op 27 oktober 2026 aangekondigd door Liquid AI, en Gemma 4 26B A4B, op 2 april 2026 uitgebracht door Google DeepMind, bestaan beide om één vraag te beantwoorden: hoe krijg je een capabel model binnen een klein geheugenbudget? Ze geven tegenovergestelde antwoorden. Liquid verkleinde het model. Google hield het model groot en betaalt per token slechts voor een deel ervan. De gewichten zijn gratis, dus de rekening is wat de goedkoopste competente host vraagt. We geven de lijstprijzen van providers door met 0% opslag.

Het onderscheid klinkt als architectuurtrivia totdat je de kosten van een deployment doorrekent, en op dat moment is het het enige dat ertoe doet. Gemma 4 26B A4B activeert 3,8 miljard parameters per token, maar je moet er nog steeds 25,2 miljard ergens onderbrengen. LFM3-1.7B activeert alle 1,73 miljard van zijn parameters en slaat er precies zoveel op. De ene is goedkoop om te berekenen. De andere is goedkoop om te bezitten.

Twee recepten voor een goedkope token

Gemma 4 26B A4B is een mixture-of-expertsmodel: 128 gerouteerde experts plus één gedeelde expert, 30 lagen, waarbij per token ongeveer acht experts actief zijn. Dat geeft het de kenniscapaciteit van een dense model van 25,2B en de rekenkosten van iets dat dichter bij een 4B ligt. Zoals Google het zelf formuleert, haalt het ongeveer 97% van de MMLU-Pro-score van het dense Gemma 4 31B-model bij ongeveer 12% van de FLOPs.

LFM3-1.7B slaat een andere weg in. Het model is volledig dense — elke parameter draait op elk token — en de besparingen komen uit een herontworpen architectuur in plaats van uit sparsity. De tri-hybride stack van Liquid bestaat uit 24 lagen: 13 gegate korte convoluties, vijf sliding-window-attentielagen en zes full-attentielagen. Het grootste deel van de sequentiemodellering wordt gedaan door convoluties, die goedkoop zijn, en full attention komt slechts zes keer voor. Zo kan een model van 1,73B een context van 262.144 tokens en een vocabulaire van 128.000 tokens aan zonder dat de KV-cache de machine opvreet.

• Totaal aantal parameters — 1,73B voor LFM3-1,7B; 25,2B voor Gemma 4 26B A4B.

• Actief per token — 1,73 mld. tegen ongeveer 3,8 mld. Dit is de enige rij waarin de twee in dezelfde orde van grootte liggen.

• Geheugen op 4-bit — ruwweg 1 GB tegenover ruwweg 18 GB. Dit is de rij die de uitrol bepaalt.

• Context — 262.144 tokens aan beide zijden, opnieuw een echte gelijkspel.

• Modaliteit — alleen tekst versus tekst- en afbeeldingsinvoer, met native function calling en een configureerbare denkmodus.

• Licentie — LFM Open License v1.0, gratis bij een jaarlijkse omzet van minder dan $10 miljoen; Apache 2.0 zonder drempel voor Gemma 4 26B A4B.

Waarom 3,8B actief niet 3,8B aan geheugen betekent

Dit is de meest voorkomende fout bij het lezen van een specificatieblad van een mixture-of-experts-model, dus het loont om duidelijk te zijn. Actieve parameters bepalen de rekenkracht en, in ruime zin, de snelheid. Ze bepalen niet de grootte van het bestand dat je downloadt of de VRAM die je reserveert. Gemma 4 26B A4B moet al zijn 25,2 miljard parameters resident hebben om tussen experts te routeren; bij 4-bit komt dat uit op ongeveer 18 GB. Je kunt het op één enkele kaart van 24 GB draaien, en Google levert FP8- en NVFP4-builds om dat praktisch te maken, maar je kunt het niet op een telefoon zetten.

LFM3-1.7B is ongeveer 1 GB bij 4-bit — volgens de kaart van Liquid past het op een telefoon of een laptop, en bij die omvang is die claim geloofwaardig in plaats van marketing. Het houdt ook een KV-cache van 1,6 GB bij 128K tokens aan, en dat is het getal dat daadwerkelijk bepaalt hoeveel gelijktijdige verzoeken met een lange context je kunt vasthouden.

De praktische consequentie: een implementatie van 26B-A4B is een beslissing over een inferentieserver, en een implementatie van 1.7B is een beslissing over het uitbrengen van een applicatie. Dat zijn verschillende projecten met verschillende teams en verschillende kostenstructuren, en geen enkele benchmark overbrugt de kloof daartussen.

Wat elke leverancier heeft gepubliceerd, en wat dat je vertelt

Google heeft een uitgebreide tabel voor Gemma 4 26B A4B gepubliceerd: 82,6 op MMLU-Pro, 82,3 op GPQA Diamond, 88,3 op AIME 2026 zonder hulpmiddelen, 77,1 op LiveCodeBench v6, een Codeforces-Elo van 1718, 73,8 op MMMU-Pro en 44,1 op MRCR v2 bij 128K met acht needles. Allemaal door de leverancier gerapporteerd, geen enkele onafhankelijk gereproduceerd. Tracking door derden plaatst zijn LMArena-Elo rond 1438.

Liquid heeft een smallere tabel gepubliceerd voor LFM3-1.7B, en die is gericht op agentisch werk: 71,39 op BFCL V4, 80,36 op ToolSandbox, 68,01 op τ³-bench, 45,60 op LiveClaw, 38,42 op WebArena-Verified. Er worden ook 96,66 op IFEval, 73,03 op IFBench, 63,37 op GPQA Diamond, 73,46 op LiveCodeBench v6 en 65,56 op RULER bij 128K gerapporteerd. Liquid publiceert geen MMLU-Pro-cijfer voor LFM3-1.7B, en het ontbreken daarvan is geen nul — het is simpelweg niet gemeten.

Alleen LiveCodeBench v6 en GPQA Diamond overlappen elkaar zuiver. Gemma 4 26B A4B wint beide, met respectievelijk 3,6 en 18,9 punten. Waar de suite van Liquid agentisch wordt, is er geen Gemma-getal om mee te vergelijken — Google rapporteert τ²-bench op 68,2, en τ² is niet τ³, dus 68,01 ernaast plaatsen zou een verzonnen vergelijking zijn, vermomd als een zorgvuldige vergelijking.

Waar de 1.7B in het gesprek blijft

Een verschil van 3,6 punten op LiveCodeBench is kleiner dan de parameterverhouding van 14 tegen 1 zou voorspellen, en de reden daarvoor is architectonisch. Competitief programmeren beloont het vermogen om een patroon vast te houden en een correcte functie te produceren — een vaardigheid die meer baat heeft bij een zuiver trainingssignaal dan bij ruwe capaciteit. Als programmeervragen de hele taak waren, zou de 26B winnen en zou dit gedeelte kort zijn.

Wat LFM3-1.7B echt relevant houdt, is de combinatie van een context van 262.144 tokens en een voetafdruk van 1 GB. Een model dat een groot document kan bevatten en kan draaien op het apparaat dat het leest, is een ander product dan een model dat hetzelfde document op een server kan bevatten. Liquid rapporteert 65,56 op RULER bij 128K, wat geen spectaculaire long-contextscore is — Gemma 4 26B A4B rapporteert 81,4 op dezelfde benchmarkfamilie — maar het wordt tenminste gemeten, on-device, bij één gigabyte.

En qua het volgen van instructies hoeft het kleine model zich niet te schamen: 96.66 op IFEval en 73.03 op IFBench zijn sterke cijfers voor deze formaatklasse, beide door de leverancier gerapporteerd. Voor een workload met tool-calling of gestructureerde output ligt dat dichter bij de maatstaf die ertoe doet dan GPQA Diamond.

Wat de routeringslaag daadwerkelijk verandert

Gemma 4 26B A4B staat in de OrcaRouter-catalogus — met één API-sleutel bereik je het naast meer dan 200 andere modellen, waarbij de lijstprijzen van providers worden doorgegeven met 0% opslag, zodat een prijswijziging van een leverancier dezelfde dag doorwerkt in plaats van te wachten op een herprijzingscyclus. Dat is hier belangrijker dan het gewoonlijk zou zijn, want dit is een model waarvan de economie volledig draait om providerprijzen: de gewichten zijn gratis, dus de rekening is wat de goedkoopste competente host vraagt, en dat aantal beweegt.

Automatische failover is de andere helft. Een 26B mixture-of-experts-model met 256K context is precies het soort workload dat op piekmomenten tegen capaciteitsgrenzen aanloopt, en routering over providers betekent dat een slechte middag van één host niet jouw storing is. LFM3-1.7B heeft dit allemaal niet nodig, omdat het draait op hardware die je zelf beheert en er geen provider is om van te failoveren. Dat is geen punt in zijn voordeel of nadeel — het is een gevolg van het kiezen voor het andere recept.

De eerlijke formulering van onze rol: wij routeren het grote sparse model, wij serveren het kleine dense model niet, en de beslissing tussen die twee is niet iets wat een router voor jou kan maken.

In één keer beslissen

Als het implementatiedoel minder dan 20 GB geheugen heeft — een telefoon, een laptop, een Jetson, een AI-pc — dan is Gemma 4 26B A4B geen kandidaat en is de vergelijking voorbij. Neem LFM3-1.7B, plan retrieval rond de kennislacune die Liquid zelf signaleert, en gebruik het voor tool calling en gestructureerde extractie waar zijn cijfers echt concurrerend zijn.

Als je vanaf een GPU serveert en de workload kennisintensief of multimodaal is, of het niveau van redeneren van 82,3 GPQA Diamond en 82,6 MMLU-Pro vereist, is Gemma 4 26B A4B het betere model en zijn de 18 GB de toegangsprijs. Apache 2.0 haalt het licentiegesprek volledig weg, wat voor een grote organisatie meer waard is dan een paar benchmarkpunten.

Als je een product bouwt dat naar beide wordt uitgeleverd — een assistent op het toestel die moeilijke query's naar een server escaleert — dan zijn de twee helemaal geen concurrenten. Het zijn de twee niveaus van één architectuur, en de interessante engineeringvraag is waar je de escalatielijn trekt, niet welk model een tabel wint.

De open vraag is niet het vermogen, dat is in het voordeel van Google beslecht, maar of een model van 1 GB met een context van 256K goed genoeg is voor de smalle agentische taken die de meeste on-deviceproducten echt nodig hebben. Liquid's eigen modelkaart is ongewoon openhartig dat het geen reasoningmodel is. Die openhartigheid is meer waard dan de kloof in LiveCodeBench, omdat je eruit leert welke helft van je workload je waar naartoe moet sturen.