LFM3-1.7B vs Granite 4.2 30B: Två agentmodeller som delar domen per axel

Sätt LFM3-1.7B och Granite 4.2 30B på samma sida och de aggregerade medelvärdena pekar i motsatta riktningar beroende på vilken rad du läser. På Berkeley Function Calling Leaderboard V4 får Liquid AIs modell med 1,73 miljarder parametrar 71,39 mot IBMs 61,39 – en tiopunktsvinst för en modell som är ungefär sjutton gånger mindre. På SWE-bench Verified får Granite 57,00 mot LFM3-1.7B:s 43,40, en vinst på 13,6 punkter i den andra riktningen. Routing lägger inte till någon marginal på en leverantörs listpris. Leverantörers listpriser går igenom med 0 % påslag.

Båda modellerna är byggda för agenter, båda släpptes inom två månader från varandra under 2026, och båda leverantörerna publicerar tillräckligt många överlappande benchmarks för att en riktig jämförelse ska vara möjlig snarare än ett collage. Det gör detta till en av de sällsynta matchningarna där den intressanta frågan inte är vilken modell som är bättre utan vilken axel din arbetsbelastning faktiskt ligger på. Väldigt få uppgifter kräver både ett {{1}}BFCL-poäng på 71{{/1}} och ett {{2}}SWE-bench-poäng på 57{{/2}}, och de som gör det får inte bra stöd av någon av modellerna ensam.

De två talen som korsar varandra

Granite 4.2 30B lanserades den 25 augusti 2026 under Apache 2.0, en dense modell på cirka 30B byggd på basen Granite 4.1 30B och tränad på ungefär 15 biljoner tokens. IBMs inramning är företagsinriktad: tre konfigurerbara tankelägen, inbyggt verktygsanrop mot OpenAI-schemat, tolv testade språk och en träningspipeline i tre steg som avslutas med GRPO-förstärkningsinlärning i flera faser.

LFM3-1.7B kom två månader senare, tillkännagavs den 27 oktober 2026 och eftertränades specifikt på agentiska harnesses – Liquid nämner Hermes Agent, PI och OpenClaw i modellkortet. Det är en tät modell på 1,73B med 256K kontext, och den positioneras uttryckligen för lokala agenter och verktygsanrop snarare än allmän resonemangsförmåga.

Benchmark-korsningen är inte en slump av en enda svag siffra. LFM3-1.7B:s hela publicerade tabell lutar åt det agentiska hållet: 71,39 BFCL V4, 80,36 ToolSandbox, 68,01 τ³-bench, 45,60 LiveClaw, 38,42 WebArena-Verified. Granites tabell lutar åt ingenjörshållet: 57,00 SWE-bench Verified, 33,29 SWE-bench Pro, 41,89 SWE-bench Multilingual, 38,76 SciCode, 29,24 på TerminalBench 2.1. Varje leverantör har optimerat för en annan definition av "agent", och benchmarktabellerna är ärliga om vilken.

τ³ på 68,01 mot 68,05 är den egentliga rubriken

Under de två dramatiska gapen döljer sig ett dött lopp. I τ³-bench, utvärderingen av verktygsanvändning som mäter slutförande av flerrundsuppgifter med användarsimulatorer och domänpolicyer, får LFM3-1.7B 68,01 och Granite 4.2 30B 68,05 – en skillnad på fyra hundradels poäng, vilket inte går att skilja från brus.

Det är ett mer intressant resultat än någon av de stora gapen, eftersom τ³ är det benchmark som ligger närmast det som de flesta agentdriftsättningar faktiskt gör: hålla en konversation, följa en policy, anropa rätt funktion, återhämta sig från ett misstag. Om en modell med 1,73B parametrar ligger jämsides med en tät 30B-modell där, köper parametrantalet något annat än kompetent verktygsanvändning i flera turer.

Vad det ger syns i BFCL och SWE-bench, som mäter olika saker. BFCL V4 testar korrektheten i funktionsanrop för en enskild tur mot ett schema – LFM3-1.7B:s 71,39 tyder på att Liquids efterträning på riktiga agentramverk gav direkt utdelning. SWE-bench Verified testar att åtgärda ett verkligt GitHub-ärende från början till slut, vilket kräver att hålla ett kodförråd i kontexten, planera över filer och ta fram en patch som klarar testerna – Granites 57,00 återspeglar en modell med förmågan att göra det och ett träningsset byggt för det.

Så uppdelningen är tydlig. Liten modell, vältränad på verktygsscheman: vinner funktionsanropstestet. Stor modell, tränad på kodreparation: vinner repository-testet. Oavgjort på multi-turn-mellanläget där båda var specifikt tränade.

Kontext är där specifikationerna divergerar kraftigast

• Kontext — 262 144 tokens för LFM3-1.7B; 128K inbyggt för Granite 4.2 30B, utbyggbart till 512K. Utbyggnaden är inte gratis, och IBM är ärliga med att det är en utbyggnad snarare än ett inbyggt fönster.

• Bevarande av lång kontext — 65,56 på RULER vid 128K för LFM3-1.7B mot 81,4 för Granite 4.2 30B i samma benchmarkfamilj. Den större modellen behåller mer av ett långt dokument, vilket är motsatsen till vad rubrikens kontextsiffror antyder.

• Footprint — cirka 1 GB i 4-bit mot ungefär 30B BF16-vikter, med officiella FP8-, NVFP4- och MXFP4-byggen. Det här är en modell för ett enda grafikkort, inte en laptopmodell.

• Språk — sexton för LFM3-1.7B mot tolv testade för Granite, med en annan överlappning. Granites tolv inkluderar tjeckiska och nederländska; Liquids inkluderar thailändska, vietnamesiska och indonesiska.

• Tankelägen — Granite 4.2 30B levereras med fullt läge, lågarbetsläge och icke-tänkande läge. LFM3-1.7B har ingen sådan yta, och dess kort anger att den inte är avsedd för komplex flerstegsresonemang från första början.

• Licens — Apache 2.0 för Granite kontra LFM Open License v1.0, som är gratis under 10 miljoner USD i årlig intäkt och kräver en kommersiell licens över det.

Vad 30B dense kostar som 1.73B inte gör

Granite 4.2 30B är dense, vilket innebär att alla trettio miljarder parametrar körs för varje token. Här finns ingen rabatt för aktiva parametrar: beräkningskostnaden per token är ungefär sjutton gånger den för den lilla modellen, och minneskostnaden är hela viktfilen. IBM tillhandahåller kvantiseringar för att göra det hanterbart, men det finns ingen konfiguration där den körs på en telefon.

LFM3-1.7B:s fördel är inte i första hand hastighet. Det är att modellen ryms inom samma minnesbudget som resten av din applikation. En modell på 1 GB lämnar plats för ett dokumentlager, en cache och en andra modell på samma enhet – vilket är det som gör en lokal agent möjlig i stället för bara teoretiskt lokal. Liquid rapporterar 1,8 till 2,8 gånger snabbare avkodning än sina föregångare på testad hårdvara och en KV-cache på 1,6 GB vid 128K, vilket båda spelar roll för en agent på enheten som för en lång konversation.

Motvikten är att Granites 30B-kapacitet gör verklig nytta i SWE-bench-siffrorna. Om din agents uppgift är att ändra kod i ett helt kodförråd, är gapet på 13,6 punkter inte något som en mindre modell tar igen genom promptning, och besparingarna i beräkningskraft ger dig ett sämre utfall.

Licensiering, signering och upphandlingsfrågan

Apache 2.0 är anledningen till att en stor organisation kan införa Granite 4.2 30B utan en juridisk granskning. Det finns ingen intäktsgräns, ingen kommersiell utlösare, ingen förhandling. IBM har också kryptografiskt signerat släppta Granite-modeller sedan april 2026, vilket låter som en detalj tills man är personen som måste bevisa att vikterna i produktion är de vikter som granskats.

Liquid's LFM Open License v1.0 är genuint tillåtande i startup-skala – gratis för kommersiellt bruk under 10 miljoner dollar i årlig omsättning – men över den gränsen krävs en betald kommersiell licens. För en enskild utvecklare eller ett litet team är detta en icke-fråga. För en affärsenhet inom ett större företag är det en diskussion som börjar före den första driftsättningen och kanske inte avslutas snabbt. Den asymmetrin återspeglas inte i något benchmark och avgör ofta frågan på egen hand.

Att köra båda utan att satsa på endera

Det praktiska tillvägagångssättet för ett team som utvärderar dessa två är inte att välja en först. Båda har öppna vikter och båda är obevisade av oberoende utvärderare, vilket innebär att det enda benchmark som spelar roll är ert eget. Dirigera kandidatmodellerna genom en enda slutpunkt, kör samma agentspår genom båda och jämför utifrån er uppgift i stället för utifrån BFCL eller SWE-bench.

OrcaRouter är här mindre användbart som värd än som en kontrollsyta: en nyckel och en faktura för fler än 200 modeller, leverantörernas listpriser förs vidare med 0 % påslag, och automatisk failover så att en utvärderingskörning inte dör för att en leverantör hade en dålig timme. Varken LFM3-1.7B eller Granite 4.2 30B finns i vår katalog i dag – båda är nedladdningar med öppna vikter, och självhosting är vägen för var och en. Det är i den omgivande stacken som routning förtjänar sin plats: den frontier-modell som din agent eskalerar till, eller den andra åsikten du jämför mot när den lokala modellens patch inte klarar sina tester.

Vem ska ta vilken

Välj LFM3-1.7B om agenten körs på användarens enhet, om arbetet består av verktygsanrop och strukturerad extrahering mot ett API, och om ett 256K-kontext med ett 1 GB-fotavtryck är det som gör produkten möjlig. Acceptera leverantörens egen varning att den inte är avsedd för agentisk kodning, och behåll en större modell bakom den för de fall som behöver en.

Välj Granite 4.2 30B om agenten rör en kodbas, om du behöver Apache 2.0 och signerade vikter för upphandling, om arbetsbelastningen drar nytta av konfigurerbar tankeansträngning, och om du har en GPU att servera den på. BFCL-underskottet är verkligt men smalt: det mäter schemakorrekthet vid ett enskilt anrop, och en 30B-modell med ett välkonstruerat verktygsschema täcker i praktiken en stor del av gapet.

Välj uppdelningen om du bygger det som båda leverantörerna siktar på – en lokal agent som hanterar rutinmässiga verktygsanrop inom en gigabyte och eskalerar arbete i reposkala till en server. Den arkitekturen använder varje modell där dess egen benchmarktabell säger att den är stark, och det är det enda arrangemanget där de korsade axlarna slutar vara ett problem.

Frågan som är värd att följa är om Liquids agentiska efterträningsrecept överförs till en större checkpoint. Om en framtida LFM-modell behåller BFCL-beteendet i 71,39-klassen och lägger till kapacitet för arbete med repositorier, kollapsar axeluppdelningen och den här jämförelsen blir ett enkelt storleksbeslut. Fram till dess konkurrerar de två modellerna inte om samma jobb – de är de två halvorna av en helhet.