LFM3-1.7B vs Granite 4.2 30B: twee agentmodellen die het oordeel per as opsplitsen

Zet LFM3-1.7B en Granite 4.2 30B op dezelfde pagina en de geaggregeerde gemiddelden wijzen in tegengestelde richtingen, afhankelijk van welke rij je leest. Op Berkeley Function Calling Leaderboard V4 scoort het model van Liquid AI met 1,73 miljard parameters 71,39 tegen 61,39 van IBM — een winst van tien punten voor een model dat ongeveer zeventien keer kleiner is. Op SWE-bench Verified scoort Granite 57,00 tegen 43,40 van LFM3-1.7B, een winst van 13,6 punten in de andere richting. Routering voegt geen marge toe aan de lijstprijs van een aanbieder. Lijstprijzen van aanbieders worden doorgegeven tegen 0% opslag.

Beide modellen zijn gebouwd voor agents, beide zijn binnen twee maanden na elkaar uitgebracht in 2026, en beide leveranciers publiceren genoeg overlappende benchmarks om een echte vergelijking mogelijk te maken in plaats van een collage. Daardoor is dit de zeldzame confrontatie waarin de interessante vraag niet is welk model beter is, maar op welke dimensie je workload zich werkelijk bevindt. Zeer weinig taken vragen zowel een BFCL-score van 71 als een SWE-bench-score van 57, en de taken die dat wel doen, worden door geen van beide modellen afzonderlijk goed bediend.

De twee getallen die elkaar kruisen

Granite 4.2 30B verscheen op 25 augustus 2026 onder Apache 2.0: een dense model van ~30B, gebouwd op de Granite 4.1 30B-basis en getraind op ongeveer 15 biljoen tokens. IBM positioneert het voor ondernemingen: drie configureerbare denkmodi, native tool calling volgens het OpenAI-schema, twaalf geteste talen en een drietraps-trainingspipeline die eindigt in meerfasige GRPO-reinforcement learning.

LFM3-1.7B kwam twee maanden later uit, aangekondigd op 27 oktober 2026, specifiek nagetraind op agentic harnesses — Liquid noemt Hermes Agent, PI en OpenClaw in de modelkaart. Het is een dense model van 1,73B met een context van 256K, en het is expliciet gepositioneerd voor lokale agents en tool calling in plaats van algemeen redeneren.

De benchmarkkruising is geen toeval van één zwak getal. De volledige gepubliceerde tabel van LFM3-1.7B leunt sterk richting agentisch: 71,39 BFCL V4, 80,36 ToolSandbox, 68,01 τ³-bench, 45,60 LiveClaw, 38,42 WebArena-Verified. De tabel van Granite leunt richting engineering: 57,00 SWE-bench Verified, 33,29 SWE-bench Pro, 41,89 SWE-bench Multilingual, 38,76 SciCode, 29,24 op TerminalBench 2.1. Elke leverancier optimaliseerde voor een andere definitie van "agent", en de benchmarktabellen zijn eerlijk over welke.

τ³ op 68,01 tegen 68,05 is de echte headline.

Onder de twee dramatische verschillen schuilt een nek-aan-nekrace. Op τ³-bench, de tool-use-evaluatie die taakvoltooiing over meerdere rondes meet met gebruikerssimulators en domeinbeleid, scoort LFM3-1.7B 68.01 en Granite 4.2 30B 68.05 — een verschil van vierhonderdste punt, dat niet van ruis te onderscheiden is.

Dat is een interessanter resultaat dan elk van de grote verschillen, omdat τ³ de benchmark is die het dichtst in de buurt komt van wat de meeste agent-implementaties feitelijk doen: een gesprek voeren, een beleid volgen, de juiste functie aanroepen, herstellen van een fout. Als een 1,73B-model daar een 30B dense model evenaart, dan levert het aantal parameters iets anders op dan competente meerronde-toolgebruik.

Wat het oplevert, blijkt uit BFCL en SWE-bench, die verschillende dingen meten. BFCL V4 test de correctheid van single-turn-functieaanroepen tegen een schema — de 71,39 van LFM3-1.7B suggereert dat Liquids post-training op echte agent-harnassen zich direct heeft uitbetaald. SWE-bench Verified test het end-to-end repareren van een echte GitHub-issue, waarvoor je een repository in context moet houden, over bestanden heen moet plannen en een patch moet produceren die de tests doorstaat — Granites 57,00 weerspiegelt een model met het vermogen om dat te doen en een trainingsset die daarvoor is gebouwd.

Dus de splitsing is leesbaar. Klein model, goed getraind op tool-schema's: wint de functieaanroepstest. Groot model, getraind op codereparatie: wint de repositorytest. Gelijkspel op het meerronde-tussengebied waar beide specifiek op waren getraind.

Context is waar de specificaties het sterkst uiteenlopen

• Context — 262.144 tokens voor LFM3-1.7B; 128K native voor Granite 4.2 30B, uitbreidbaar tot 512K. De uitbreiding is niet gratis, en IBM is eerlijk dat het een uitbreiding is en geen native venster.

• Behoud van lange context — 65,56 op RULER bij 128K voor LFM3-1.7B tegenover 81,4 voor Granite 4.2 30B in dezelfde benchmarkfamilie. Het grotere model houdt meer van een lang document vast, wat het tegenovergestelde is van wat de contextcijfers in de kop suggereren.

• Footprint — ongeveer 1 GB bij 4-bit tegenover ruwweg 30B aan BF16-gewichten, met officiële FP8-, NVFP4- en MXFP4-builds. Dit is een single-GPU-model, geen laptopmodel.

• Talen — zestien voor LFM3-1.7B tegenover twaalf die voor Granite zijn getest, met een andere overlap. De twaalf van Granite omvatten Tsjechisch en Nederlands; die van Liquid omvatten Thai, Vietnamees en Indonesisch.

• Denkmodi — Granite 4.2 30B wordt geleverd met volledige, low-effort- en no-thinking-modi. LFM3-1.7B heeft een dergelijke functionaliteit niet, en de modelkaart zegt dat het sowieso niet bedoeld is voor complexe redeneringen in meerdere stappen.

• Licentie — Apache 2.0 voor Granite tegenover de LFM Open License v1.0, die gratis is onder $10 miljoen jaaromzet en daarboven een commerciële licentie vereist.

Wat kost 30B dense dat 1.73B niet kost?

Granite 4.2 30B is dense, wat betekent dat alle dertig miljard parameters bij elk token worden uitgevoerd. Er is hier geen korting op actieve parameters: de rekencost per token is ongeveer zeventien keer die van het kleine model, en de geheugenkost is het volledige gewichtsbestand. IBM levert kwantisaties om dat beheersbaar te maken, maar er is geen configuratie waarin het op een telefoon draait.

Het voordeel van LFM3-1.7B is niet in de eerste plaats snelheid. Het is dat het model binnen hetzelfde geheugenbudget past als de rest van je applicatie. Een model van 1 GB laat ruimte voor een documentopslag, een cache en een tweede model op hetzelfde apparaat — wat een lokale agent mogelijk maakt in plaats van slechts theoretisch lokaal. Liquid meldt op geteste hardware 1,8 tot 2,8 keer snellere decodering dan zijn voorgangers en een KV-cache van 1,6 GB bij 128K, die beide van belang zijn voor een agent op het apparaat die een lang gesprek voert.

Het tegenwicht is dat de 30B-capaciteit van Granite echt werk verricht in de SWE-bench-cijfers. Als het de taak van je agent is om code in een repository te wijzigen, is het gat van 13,6 punten niet iets wat een kleiner model via prompting goedmaakt, en de besparing op rekenkracht levert je een slechter resultaat op.

Licentiëring, ondertekening en het inkoopvraagstuk

Apache 2.0 is de reden dat een grote organisatie Granite 4.2 30B kan adopteren zonder juridische toets. Er is geen omzetdrempel, geen commerciële trigger, geen onderhandeling. IBM voorziet sinds april 2026 ook de vrijgegeven Granite-modellen cryptografisch van een handtekening, wat als een detail klinkt tot je de persoon bent die moet bewijzen dat de gewichten in productie de gewichten zijn die zijn beoordeeld.

Liquid's LFM Open License v1.0 is op startup-schaal echt ruimhartig — gratis voor commercieel gebruik onder een jaarlijkse omzet van 10 miljoen dollar — maar boven die grens is een betaalde commerciële licentie vereist. Voor een individuele ontwikkelaar of een klein team is dat geen probleem. Voor een bedrijfsonderdeel binnen een groter bedrijf is het een gesprek dat vóór de eerste deployment begint en mogelijk niet snel is afgerond. Die asymmetrie komt in geen enkele benchmark tot uiting en is vaak op zichzelf al beslissend.

Beide draaien zonder op een van beide te wedden

De praktische aanpak voor een team dat deze twee evalueert, is niet om eerst één te kiezen. Beide zijn open-weight en beide zijn nog niet bewezen door onafhankelijke beoordelaars, wat betekent dat de enige benchmark die ertoe doet je eigen benchmark is. Leid de kandidaatmodellen via één endpoint, laat dezelfde agent-traces door beide lopen en vergelijk op jouw taak in plaats van op BFCL of SWE-bench.

OrcaRouter is hier minder nuttig als host dan als controlepaneel: één sleutel en één factuur voor meer dan 200 modellen, de lijstprijzen van providers doorgegeven zonder opslag, en automatische failover zodat een evaluatierun niet sterft omdat één provider een slecht uur had. Noch LFM3-1.7B noch Granite 4.2 30B staat vandaag in onze catalogus — beide zijn open-weight downloads, en self-hosting is voor elk de weg. Waar routing zijn plaats verdient, is de omliggende stack: het frontier-model waarnaar je agent escaleert, of de second opinion waarmee je vergelijkt wanneer de patch van het lokale model zijn tests niet haalt.

Wie moet welke nemen

Kies LFM3-1.7B als de agent op het apparaat van de gebruiker draait, als het werk tool calling en gestructureerde extractie tegen een API is, en als een context van 256K met een voetafdruk van 1 GB is wat het product mogelijk maakt. Accepteer de eigen waarschuwing van de leverancier dat het niet voor agentic coding is, en houd een groter model achter de hand voor de gevallen die er een nodig hebben.

Kies Granite 4.2 30B als de agent met een codebase werkt, als je Apache 2.0 en ondertekende gewichten nodig hebt voor inkoop, als de workload baat heeft bij een configureerbare hoeveelheid denkwerk, en als je een GPU hebt om het op te draaien. Het BFCL-tekort is reëel maar beperkt: het meet schemacorrectheid bij één enkele aanroep, en een 30B-model met een goed ontworpen toolschema dicht dat gat in de praktijk grotendeels.

Kies de opsplitsing als je bouwt aan het ding dat beide leveranciers beogen: een lokale agent die routinematige toolaanroepen in een gigabyte afhandelt en werk op repositoryschaal naar een server escaleert. Die architectuur gebruikt elk model waar zijn eigen benchmarktabel zegt dat het sterk is, en het is de enige opzet waarin de gekruiste assen ophouden een probleem te zijn.

De vraag die het volgen waard is, is of Liquids agentische post-trainingsrecept overdraagbaar is naar een groter checkpoint. Als een toekomstig LFM-model het BFCL-gedrag van de 71,39-klasse behoudt en capaciteit voor repositorywerk toevoegt, valt de splitsing langs de assen weg en wordt deze vergelijking een eenvoudige keuze op basis van omvang. Tot dan concurreren de twee modellen niet om dezelfde taak — het zijn de twee helften van één geheel.