LFM3-1.7B vs Granite 4.2 30B: due modelli agentici che dividono il verdetto per asse

Metti LFM3-1.7B e Granite 4.2 30Bsulla stessa pagina e le medie aggregate puntano in direzioni opposte a seconda della riga che si legge. Sul Berkeley Function Calling Leaderboard V4, il modello da 1,73 miliardi di parametri di Liquid AI segna 71,39 contro 61,39 di IBM — una vittoria di dieci punti per un modello circa diciassette volte più piccolo. Su SWE-bench Verified, Granite segna 57,00 contro 43,40 di LFM3-1.7B, una vittoria di 13,6 punti nella direzione opposta. Il routing non aggiunge un margine al prezzo di listino di un fornitore. I prezzi di listino dei fornitori vengono trasferiti con 0% di ricarico.

Entrambi i modelli sono progettati per gli agenti, entrambi sono stati rilasciati a due mesi di distanza l'uno dall'altro nel 2026, ed entrambi i fornitori pubblicano abbastanza benchmark sovrapposti da rendere possibile un confronto reale anziché un collage. Questo rende la sfida una delle rare occasioni in cui la domanda interessante non è quale modello sia migliore, ma su quale asse viva effettivamente il tuo carico di lavoro. Pochissime attività richiedono sia un punteggio BFCL di 71 sia un punteggio SWE-bench di 57, e quelle che lo richiedono non vengono servite bene da nessuno dei due modelli da solo.

I due numeri che si incrociano

Granite 4.2 30B è stato rilasciato il 25 agosto 2026 con licenza Apache 2.0: un modello dense da ~30B parametri costruito sulla base Granite 4.1 30B e addestrato su circa 15 trilioni di token. Il posizionamento di IBM è enterprise: tre modalità di ragionamento configurabili, tool calling nativo conforme allo schema OpenAI, dodici lingue testate e una pipeline di addestramento in tre fasi che si conclude con apprendimento per rinforzo GRPO multifase.

LFM3-1.7B è arrivato due mesi dopo, annunciato il 27 ottobre 2026, con post-training specificamente su harness agentici — Liquid cita Hermes Agent, PI e OpenClaw nella model card. È un modello dense da 1,73B con una context window da 256K, ed è esplicitamente posizionato per agenti locali e tool calling anziché per il ragionamento generale.

Il sorpasso nei benchmark non è un caso dovuto a un unico numero debole. L'intera tabella pubblicata di LFM3-1.7B è orientata all'agentico: 71,39 BFCL V4, 80,36 ToolSandbox, 68,01 τ³-bench, 45,60 LiveClaw, 38,42 WebArena-Verified. La tabella di Granite è orientata all'ingegneria: 57,00 SWE-bench Verified, 33,29 SWE-bench Pro, 41,89 SWE-bench Multilingual, 38,76 SciCode, 29,24 su TerminalBench 2.1. Ogni fornitore ha ottimizzato per una definizione diversa di "agent", e le tabelle dei benchmark sono oneste su quale.

τ³ a 68,01 contro 68,05 è la vera notizia.

Nascosta sotto i due drammatici divari c'è una parità assoluta. Su τ³-bench, la valutazione dell'uso degli strumenti che misura il completamento di attività multi-turno con simulatori utente e policy di dominio, LFM3-1.7B segna 68,01 e Granite 4.2 30B segna 68,05 — una differenza di quattro centesimi di punto, indistinguibile dal rumore.

Questo è un risultato più interessante di entrambi i grandi divari, perché τ³ è il benchmark più vicino a ciò che fanno realmente la maggior parte delle implementazioni di agenti: portare avanti una conversazione, seguire una policy, chiamare la funzione giusta, riprendersi da un errore. Se un modello da 1,73B è alla pari con un modello dense da 30B su questo, il numero di parametri sta comprando qualcos'altro rispetto a un uso competente degli strumenti multi-turn.

Ciò che offre si vede in BFCL e SWE-bench, che misurano cose diverse. BFCL V4 verifica la correttezza delle chiamate di funzione a turno singolo rispetto a uno schema — il 71,39 di LFM3-1.7B suggerisce che il post-training di Liquid su harness per agenti reali ha dato frutti diretti. SWE-bench Verified verifica la riparazione end-to-end di un problema reale di GitHub, il che richiede di mantenere un repository nel contesto, pianificare tra più file e produrre una patch che superi i test — il 57,00 di Granite riflette un modello con la capacità di farlo e un set di addestramento costruito per questo.

Quindi la suddivisione è leggibile. Modello piccolo, ben addestrato sugli schemi degli strumenti: vince il test di chiamata di funzione. Modello grande, addestrato sulla riparazione del codice: vince il test del repository. In parità sul terreno intermedio multi-turno, dove entrambi erano stati specificamente addestrati.

Il contesto è dove le specifiche divergono maggiormente.

• Contesto — 262.144 token per LFM3-1.7B; 128K nativi per Granite 4.2 30B, estendibili a 512K. L'estensione non è gratuita e IBM ammette onestamente che si tratta di un'estensione anziché di una finestra nativa.

• Ritenzione sul contesto lungo — 65,56 su RULER a 128K per LFM3-1.7B contro 81,4 per Granite 4.2 30B sulla stessa famiglia di benchmark. Il modello più grande trattiene una porzione maggiore di un documento lungo, il che è l'opposto di quanto suggeriscono i numeri di contesto pubblicizzati.

• Ingombro — circa 1 GB a 4 bit rispetto a circa 30B di pesi BF16, con build ufficiali FP8, NVFP4 e MXFP4. Questo è un modello per singola GPU, non un modello per laptop.

• Lingue — sedici per LFM3-1.7B contro dodici testate per Granite, con una sovrapposizione diversa. Le dodici di Granite includono ceco e olandese; quelle di Liquid includono thai, vietnamita e indonesiano.

• Modalità di pensiero — Granite 4.2 30B offre modalità complete, a basso sforzo e senza pensiero. LFM3-1.7B non presenta nulla di simile, e la sua scheda dichiara che non è pensato per il ragionamento complesso a più passaggi fin dall'inizio.

• Licenza — Apache 2.0 per Granite rispetto alla LFM Open License v1.0, che è gratuita al di sotto dei 10 milioni di dollari di fatturato annuo e richiede una licenza commerciale al di sopra di tale soglia.

Quali costi ha un 30B dense che un 1.73B non ha?

Granite 4.2 30B è un modello dense, il che significa che tutti e trenta i miliardi di parametri vengono eseguiti su ogni token. Qui non c'è alcuno sconto sui parametri attivi: il costo computazionale per token è circa diciassette volte quello del modello piccolo, e il costo in memoria è l'intero file dei pesi. IBM distribuisce quantizzazioni per renderlo gestibile, ma non esiste una configurazione in cui possa girare su un telefono.

Il vantaggio di LFM3-1.7B non risiede principalmente nella velocità. Consiste nel fatto che il modello rientra nello stesso budget di memoria del resto dell'applicazione. Un modello da 1 GB lascia spazio per un archivio documenti, una cache e un secondo modello sullo stesso dispositivo — ed è ciò che rende possibile un agente locale anziché solo teoricamente locale. Liquid riporta una decodifica da 1,8 a 2,8 volte più veloce rispetto ai suoi predecessori sull'hardware testato e una KV cache da 1,6 GB a 128K, entrambi aspetti importanti per un agente su dispositivo che sostiene una lunga conversazione.

Il contrappeso è che la capacità 30B di Granite sta facendo un lavoro concreto nei numeri di SWE-bench. Se il compito del tuo agente è modificare codice in un repository, il divario di 13,6 punti non è qualcosa che un modello più piccolo recupera tramite prompting, e il risparmio di calcolo ti fa ottenere un risultato peggiore.

Licenze, firma e la questione degli appalti

Apache 2.0 è il motivo per cui una grande organizzazione può adottare Granite 4.2 30B senza una revisione legale. Non c'è alcuna soglia di ricavi, alcun trigger commerciale, alcuna negoziazione. IBM firma anche crittograficamente i modelli Granite rilasciati da aprile 2026, il che sembra un dettaglio finché non sei tu la persona che deve dimostrare che i pesi in produzione sono i pesi che sono stati sottoposti a verifica.

La LFM Open License v1.0 di Liquid è davvero permissiva su scala di startup — gratuita per uso commerciale sotto i 10 milioni di dollari di fatturato annuo — ma oltre quella soglia richiede una licenza commerciale a pagamento. Per uno sviluppatore individuale o un piccolo team, la questione non si pone. Per un'unità aziendale all'interno di una grande impresa, è una conversazione che inizia prima del primo deployment e che potrebbe non concludersi in fretta. Questa asimmetria non trova riscontro in alcun benchmark e spesso decide la questione da sola.

Eseguire entrambi senza scommettere su nessuno dei due

Lo schema pratico per un team che valuta questi due non è sceglierne uno per primo. Entrambi sono a pesi aperti ed entrambi non sono stati dimostrati da valutatori indipendenti, il che significa che l'unico benchmark che conta è il vostro. Instradate i modelli candidati attraverso un unico endpoint, eseguite le stesse tracce dell'agente su entrambi e confrontate sul vostro task anziché su BFCL o SWE-bench.

OrcaRouter qui è utile meno come host che come superficie di controllo: una sola chiave e una sola fattura per oltre 200 modelli, prezzi di listino dei provider trasferiti con un ricarico dello 0%, e failover automatico affinché un'esecuzione di valutazione non muoia perché un provider ha avuto un'ora storta. Né LFM3-1.7B né Granite 4.2 30B sono oggi nel nostro catalogo — entrambi sono download open-weight, e il self-hosting è la strada per ciascuno. È lo stack circostante il punto in cui il routing si guadagna il suo posto: il modello frontier a cui il tuo agente passa in escalation, o il secondo parere con cui ti confronti quando la patch del modello locale non supera i test.

Chi dovrebbe prendere quale

Scegli LFM3-1.7B se l'agente viene eseguito sul dispositivo dell'utente, se il lavoro consiste in chiamate a strumenti ed estrazione strutturata tramite un'API e se un contesto da 256K con un'impronta di 1 GB è ciò che rende possibile il prodotto. Accetta l'avvertimento dello stesso fornitore secondo cui non è pensato per la programmazione agentica, e tieni un modello più grande alle spalle per i casi che ne hanno bisogno.

Scegli Granite 4.2 30B se l'agente interagisce con una base di codice, se hai bisogno di Apache 2.0 e di pesi firmati per l'approvvigionamento, se il carico di lavoro trae vantaggio da uno sforzo di ragionamento configurabile e se disponi di una GPU da cui servirlo. Il deficit BFCL è reale ma limitato: misura la correttezza dello schema su una singola chiamata, e un modello da 30B con uno schema di strumenti ben progettato colma gran parte di questo divario nella pratica.

Scegli la divisione se stai costruendo la cosa a cui puntano entrambi i fornitori — un agente locale che gestisce le chiamate di strumenti di routine in un gigabyte e delega il lavoro su scala di repository a un server. Quell'architettura usa ciascun modello dove la sua stessa tabella di benchmark dice che è forte, ed è l'unica configurazione in cui gli assi incrociati smettono di essere un problema.

La domanda da tenere d'occhio è se la ricetta di post-addestramento agentico di Liquid si trasferisca a un checkpoint più grande. Se un futuro modello LFM mantiene il comportamento BFCL di classe 71.39 e aggiunge capacità per il lavoro sui repository, la separazione per assi crolla e questo confronto diventa una semplice decisione sulla dimensione. Fino ad allora, i due modelli non competono per lo stesso lavoro — sono le due metà di uno solo.