LFM3-1.7B vs Gemma 4 26B A4B: due ricette per un token economico, e solo una sta su un telefono

Sulla carta, questi due modelli adottano lo stesso approccio allo stesso problema. LFM3-1.7B, annunciato da Liquid AI il 27 ottobre 2026, e Gemma 4 26B A4B, rilasciato da Google DeepMind il 2 aprile 2026, esistono entrambi per rispondere a una domanda: come si fa a far entrare un modello capace in un budget di memoria ridotto? Danno risposte opposte. Liquid ha ridotto il modello. Google ha mantenuto il modello grande e paga solo una porzione di esso per token. I pesi sono gratuiti, quindi il conto è quello che addebita l'host competente più economico. Applichiamo ai prezzi di listino dei fornitori un ricarico dello 0%.

La distinzione sembra una curiosità architettonica finché non si calcola il costo di un deployment, e a quel punto è l'unica cosa che conta. Gemma 4 26B A4B attiva 3,8 miliardi di parametri per token, ma bisogna comunque tenerne 25,2 miliardi da qualche parte. LFM3-1.7B attiva tutti i suoi 1,73 miliardi di parametri e ne conserva esattamente altrettanti. Uno è economico da calcolare. L'altro è conveniente da possedere.

Due ricette per un token economico

Gemma 4 26B A4B è un modello mixture-of-experts: 128 esperti instradati più un esperto condiviso, 30 livelli, con circa otto esperti attivati per token. Questo gli conferisce la capacità di conoscenza di un modello denso da 25.2B e un costo aritmetico più vicino a quello di un 4B. La stessa formulazione di Google è che raggiunge circa il 97% del punteggio MMLU-Pro del modello denso Gemma 4 31B con circa il 12% dei FLOP.

LFM3-1.7B prende l'altra strada. È completamente denso — ogni parametro viene eseguito su ogni token — e i risparmi derivano da un'architettura riprogettata anziché dalla sparsità. Lo stack tri-ibrido di Liquid è composto da 24 livelli: 13 convoluzioni corte con gating, cinque livelli di attenzione a finestra scorrevole, sei livelli di attenzione completa. La maggior parte della modellazione della sequenza è affidata alle convoluzioni, che costano poco, e l'attenzione completa compare solo sei volte. È così che un modello da 1,73 miliardi di parametri gestisce un contesto di 262.144 token e un vocabolario di 128.000 token senza che la cache KV divori la macchina.

• Parametri totali — 1,73B per LFM3-1.7B; 25,2B per Gemma 4 26B A4B.

• Attivi per token — 1,73 miliardi contro circa 3,8 miliardi. È l'unica riga in cui i due sono sullo stesso piano.

• Memoria a 4 bit — circa 1 GB contro circa 18 GB. Questa è la riga che decide il deployment.

• Contesto — 262.144 token su entrambi, ancora una volta un vero pareggio.

• Modalità — solo testo rispetto a input testuali e di immagini, con chiamata di funzioni nativa e una modalità di pensiero configurabile.

• Licenza — LFM Open License v1.0, gratuita sotto i 10 milioni di dollari di ricavi annuali; Apache 2.0 senza soglia per Gemma 4 26B A4B.

Perché 3,8B attivi non significa 3,8B di memoria

Questo è l'errore più comune quando si legge la scheda tecnica di un modello mixture-of-experts, quindi vale la pena essere espliciti. I parametri attivi governano il calcolo e, in linea di massima, la velocità. Non governano la dimensione del file che scarichi né la VRAM che riservi. Gemma 4 26B A4B richiede che tutti i suoi 25,2 miliardi di parametri restino residenti per effettuare il routing tra esperti; a 4 bit si arriva vicino a 18 GB. Puoi servirlo su una singola scheda da 24 GB, e Google distribuisce build FP8 e NVFP4 per renderlo praticabile, ma non puoi metterlo su un telefono.

LFM3-1.7B occupa circa 1 GB a 4 bit — la scheda di Liquid dice che sta su un telefono o un laptop, e a quella dimensione l'affermazione è credibile, non puro marketing. Mantiene anche una cache KV da 1,6 GB a 128K token, ed è questo il numero che determina davvero quante richieste concorrenti con contesto lungo puoi gestire.

La conseguenza pratica: un deployment 26B-A4B è una decisione che riguarda un server di inferenza, mentre un deployment 1.7B è una decisione che riguarda il rilascio di un'applicazione. Sono progetti diversi, con team diversi e strutture di costo diverse, e nessun benchmark colma il divario tra loro.

Che cosa ha pubblicato ciascun fornitore e che cosa questo ti dice

Google ha pubblicato una tabella completa per Gemma 4 26B A4B: 82,6 su MMLU-Pro, 82,3 su GPQA Diamond, 88,3 su AIME 2026 senza strumenti, 77,1 su LiveCodeBench v6, un Elo Codeforces di 1718, 73,8 su MMMU-Pro e 44,1 su MRCR v2 a 128K con otto aghi. Tutti dichiarati dal fornitore, nessuno riprodotto in modo indipendente. Le rilevazioni di terze parti collocano il suo Elo LMArena vicino a 1438.

Liquid ha pubblicato una tabella più ristretta per LFM3-1.7B, orientata verso il lavoro agentico: 71,39 su BFCL V4, 80,36 su ToolSandbox, 68,01 su τ³-bench, 45,60 su LiveClaw, 38,42 su WebArena-Verified. Riporta inoltre 96,66 su IFEval, 73,03 su IFBench, 63,37 su GPQA Diamond, 73,46 su LiveCodeBench v6 e 65,56 su RULER a 128K. Liquid non pubblica un valore MMLU-Pro per LFM3-1.7B, e l'assenza non è uno zero: semplicemente non è misurato.

Solo LiveCodeBench v6 e GPQA Diamond si sovrappongono in modo pulito. Gemma 4 26B A4B vince entrambi, rispettivamente di 3,6 e 18,9 punti. Dove la suite di Liquid diventa agentica, non c'è alcun valore di Gemma con cui confrontarsi — Google riporta τ²-bench a 68,2, e τ² non è τ³, quindi collocare 68,01 accanto ad esso sarebbe un confronto inventato mascherato da confronto accurato.

Dove il 1.7B resta nella conversazione

Un divario di 3,6 punti su LiveCodeBench è più piccolo di quanto lascerebbe prevedere il rapporto di parametri di 14 a 1, e la ragione è architetturale. La programmazione competitiva premia la capacità di mantenere un pattern e produrre una funzione corretta — un'abilità che trae più beneficio da un segnale di addestramento pulito che dalla capacità grezza. Se le domande di programmazione fossero l'intero compito, il 26B vincerebbe e questa sezione sarebbe breve.

Ciò che mantiene davvero {{1}}LFM3-1.7B{{/1}} rilevante è la combinazione di un {{2}}contesto di 262.144 token{{/2}} e di un {{3}}ingombro di 1 GB{{/3}}. Un modello che può contenere un documento di grandi dimensioni ed essere eseguito sul dispositivo che lo legge è un prodotto diverso da uno che può contenere lo stesso documento su un server. {{4}}Liquid{{/4}} riporta {{5}}65,56{{/5}} su {{6}}RULER{{/6}} a {{7}}128K{{/7}}, che non è un punteggio spettacolare per il contesto lungo — {{8}}Gemma 4 26B A4B{{/8}} riporta {{9}}81,4{{/9}} sulla stessa famiglia di benchmark — ma viene comunque misurato, su dispositivo, a un gigabyte.

E sull'instruction following il modello piccolo non sfigura: 96,66 su IFEval e 73,03 su IFBench sono numeri solidi per questa classe di dimensioni, entrambi dichiarati dal fornitore. Per un carico di lavoro di tool-calling o output strutturato, questa è più vicina alla metrica che conta rispetto a GPQA Diamond.

Cosa cambia davvero il livello di routing

Gemma 4 26B A4B è nel catalogo OrcaRouter — una sola chiave API consente di accedervi insieme a oltre 200 altri modelli, con i prezzi di listino dei provider trasferiti a un ricarico dello 0%, così una variazione di prezzo del fornitore si applica lo stesso giorno anziché attendere un ciclo di riprezzamento. Questo qui conta più di quanto accadrebbe di solito, perché questo è un modello la cui economia riguarda interamente il prezzo dei provider: i pesi sono gratuiti, quindi il conto è pari a quanto addebita l'host competente più economico, e quel numero si muove.

Il failover automatico è l'altra metà. Un modello mixture-of-experts da 26B con contesto da 256K è esattamente il tipo di carico di lavoro che tocca i limiti di capacità nei picchi, e il routing tra provider significa che un brutto pomeriggio di un singolo host non è un'interruzione per te. LFM3-1.7B non ha bisogno di nulla di tutto ciò, perché gira su hardware che controlli e non ha alcun provider da cui eseguire il failover. Non è un punto a suo favore né a suo sfavore — è una conseguenza della scelta dell'altra ricetta.

La formulazione onesta del nostro ruolo: instradiamo il modello grande sparso, non serviamo quello piccolo denso, e la decisione tra i due non è una che un router possa prendere per te.

Decidere in un'unica passata

Se il target di deployment dispone di meno di 20 GB di memoria — un telefono, un laptop, un Jetson, un AI PC — allora Gemma 4 26B A4B non è un candidato e il confronto è chiuso. Prendi LFM3-1.7B, pianifica il retrieval intorno al gap di conoscenza che Liquid stessa segnala e usalo per il tool calling e l'estrazione strutturata dove i suoi numeri sono davvero competitivi.

Se esegui l'inferenza da una GPU e il carico di lavoro è ad alta intensità di conoscenza, multimodale o richiede il livello di ragionamento della classe 82.3 GPQA Diamond e 82.6 MMLU-Pro, Gemma 4 26B A4B è il modello migliore e i 18 GB sono il prezzo d'ingresso. Apache 2.0 elimina del tutto la questione delle licenze, che per una grande organizzazione vale più di qualche punto di benchmark.

Se stai costruendo un prodotto che arriva su entrambi — un assistente on-device che inoltra le richieste difficili a un server — i due non sono affatto concorrenti. Sono i due livelli di un'unica architettura, e la domanda ingegneristica interessante è dove tracci la linea di escalation, non quale modello vince una tabella.

La questione aperta non è la capacità, che è già risolta a favore di Google, ma se un modello da 1 GB con una finestra di contesto da 256K sia sufficientemente buono per le attività agentiche ristrette di cui la maggior parte dei prodotti on-device ha effettivamente bisogno. La model card di Liquid stessa è insolitamente schietta nel dire che non è un modello di ragionamento. Quella schiettezza vale più del divario su LiveCodeBench, perché ti dice quale metà del tuo carico di lavoro inviare dove.