Ember-1 vs LFM2.5 2.6B Base: un comportamento finito contro un substrato grezzo

Né Ember-1 né LFM2.5 2.6B Base è un modello che puoi prendere e usare, e sono inutilizzabili per ragioni opposte. Ember-1, pubblicato da Fireworks Research il 23 settembre 2026, è un derivato specializzato del Kimi K3 di Moonshot AI che il laboratorio ha riaddestrato per raggiungere l'accuratezza di K3 con circa il 40% in meno di token — un comportamento compiuto, disponibile solo come anteprima di ricerca sulla piattaforma serverless del fornitore stesso, senza pesi e senza prezzo pubblicato. LFM2.5 2.6B Base, pubblicato da Liquid AI il 4 agosto 2026, è un checkpoint preaddestrato da 2,69 miliardi di parametri sotto la LFM Open License v1.0 che non è stato affatto ottimizzato per le istruzioni e continuerà il tuo testo invece di rispondere alla tua domanda — un substrato grezzo, scaricabile oggi, volutamente incompiuto. Leggerli fianco a fianco è un buon modo per vedere le due argomentazioni che vengono avanzate circa da dove provengano ora i guadagni di efficienza.

La domanda a cui stanno rispondendo entrambi i modelli

Entrambe le release partono dalla stessa premessa: che i guadagni facili derivanti dal rendere più grande un modello sono in gran parte già stati incassati, e che il lavoro interessante si è spostato su come un modello spende ciò che già ha. I due laboratori rispondono in modo diverso. Fireworks Research ha preso un modello di frontiera esistente e ne ha cambiato il comportamento. Liquid AI ha costruito un modello piccolo da zero e ha cambiato la scala. Nessuna delle due è una storia di nuova architettura, e nessuna delle due cerca di conquistare la vetta di una classifica.

La risposta di Ember-1: mantenere il modello, riaddestrare il comportamento

Ember-1 lascia intatta l'architettura di Kimi K3 e attacca una specifica inefficienza. I modelli di ragionamento possono bruciare più del 90% dei token generati in deliberazione interna, e in un ciclo di agenti multi-turno quelle tracce vengono riprodotte e riaddebitate a ogni turno successivo — Fireworks Research descrive la conseguente crescita del contesto come approssimativamente quadratica nel numero di turni. L'affermazione del laboratorio è che il ragionamento di K3 è più lungo di quanto richieda il compito e che l'eccesso può essere rimosso senza cambiare le risposte. Riferisce di aver eseguito più di 50 esperimenti di addestramento e oltre 200 valutazioni sulla propria stack di addestramento serverless, e afferma che la lunghezza del ragionamento è diminuita del 35–50% senza perdita di accuratezza su sette benchmark e due set di traffico di produzione dei clienti. Tutto ciò è riportato dal fornitore e non riprodotto.

I risultati sono disomogenei in un modo che il numero di testa nasconde. Le riduzioni di token di Ember-1 vanno dal 51,9% su Terminal Bench 2.1 al 5,9% su τ-2 Bench Airline. Nell'A/B di coding in produzione di un cliente, i token di output sono scesi da 49,3K a 29,9K mentre il punteggio si è mantenuto a 0,753 contro 0,751 — una riduzione del 71,3% dei token di ragionamento. Si tratta di un effetto ampio su una forma di carico di lavoro e quasi invisibile su un'altra, esattamente ciò che ci si aspetterebbe da un modello addestrato a smettere di pensare troppo anziché a pensare di meno.

La risposta di LFM2.5 2.6B Base: cambia la scala, mantieni la ricetta

LFM2.5 2.6B Base è un tipo diverso di scommessa. È l'architettura ibrida di Liquid AI su piccola scala: 30 livelli, di cui 22 sono blocchi a convoluzione corta con doppio gate e 8 sono livelli di grouped-query attention, addestrata su circa 34 trilioni di token in 16 lingue, con una finestra di contesto di 131.072 token. L'intero checkpoint è di 2,69 miliardi di parametri densi — abbastanza piccolo che la conversazione sui costi smette di riguardare i token e inizia a riguardare quale singola GPU hai a disposizione.

Ciò che lo rende insolito è ciò che deliberatamente non fa. Non c'è alcun instruction tuning, che è proprio il senso del suffisso "Base": dagli una domanda e continuerà il testo nello stile della domanda invece di rispondere. La model card di Liquid AI stessa lo raccomanda per attività che richiedono un fine-tuning intenso. Inoltre, non ne esiste alcuna valutazione pubblicata, e non è una svista — valutare un checkpoint base su benchmark di instruction-following non misurerebbe nulla, perché il comportamento che si sta misurando non è ancora stato addestrato.

Il contrasto, una riga per dimensione

• Cos'è — Ember-1: un derivato riaddestrato di Kimi K3 con ragionamento abbreviato. LFM2.5 2.6B Base: un checkpoint preaddestrato da zero senza addestramento con istruzioni.

• Parametri — Ember-1: non divulgati; ereditati da Kimi K3. LFM2.5 2.6B Base: 2,69B denso.

• Pesi — Ember-1: nessuno pubblicato. LFM2.5 2.6B Base: disponibile con la LFM Open License v1.0.

• Prezzo — Ember-1: nessun prezzo pubblicato; i valori in dollari dei benchmark si basano sul listino prezzi di Kimi K3. LFM2.5 2.6B Base: download gratuito; l'hardware è a tuo carico.

• Contesto — Ember-1: non pubblicato per l'anteprima. LFM2.5 2.6B Base: 131.072 token.

• Valutazione pubblicata — Ember-1: sette benchmark e due test A/B, tutti eseguiti dal fornitore. LFM2.5 2.6B Base: nessuna, per scelta progettuale.

• Cosa ottieni alla fine — Ember-1: un endpoint che produce un ragionamento più breve con un'accuratezza di livello K3. LFM2.5 2.6B Base: un punto di partenza il cui comportamento è esattamente ciò che gli fai apprendere con l'addestramento.

Due diversi tipi di mancanza

I gap in queste due release sembrano simmetrici e non lo sono. La valutazione mancante di LFM2.5 2.6B Base è una proprietà dell'artefatto: un checkpoint base non ha un comportamento da valutare, e l'instruction tuning mancante è una caratteristica documentata, non una lacuna. L'assenza non crea incertezza commerciale, perché ciò che si acquista è un file con una licenza allegata, e il deliverable è completo nel momento in cui il download termina.

I pezzi mancanti di Ember-1 sono davvero irrisolti. Non c'è un prezzo pubblicato, quindi l'affermazione sui costi è un calcolo aritmetico sul listino di Kimi K3, non una tariffa sulla quale impostare un budget. Non c'è un rilascio dei pesi, quindi il modello non può sopravvivere alla decisione del fornitore di continuare a erogarlo. E la finestra di accesso è descritta come temporanea: Fireworks Research presenta i suoi rilasci di ricerca come finestre serverless di due settimane la cui permanenza dipende dalla domanda della comunità. Un'anteprima che potrebbe non esistere il mese prossimo è tutt'altra cosa rispetto a un'anteprima che è solo non provata, e il secondo test A/B sui clienti nell'annuncio — circa il 35% in meno di token per attività — ti dice ciò che il laboratorio si aspetta, non ciò che sarà ancora raggiungibile a novembre.

Quell'asimmetria è la risposta onesta a «quale di questi è più pronto». Nessuno dei due è pronto nel senso di essere una dipendenza di produzione pronta all'uso. LFM2.5 2.6B Base è completo come materia prima e incompleto come modello. Ember-1 è completo come modello e incompleto come servizio.

Cosa fare con ciascuno questo trimestre

Se disponi di una pipeline di fine-tuning e di un compito ristretto con etichette pulite, LFM2.5 2.6B Base è il più prevedibile dei due. Il checkpoint è piccolo, la licenza è permissiva, l'architettura è progettata per essere efficiente in inferenza, e il lavoro di trasformarlo in qualcosa di utile — fine-tuning supervisionato, un set di valutazione, uno stack di serving — è un lavoro che già gestisci dall'inizio alla fine. In ogni caso eseguirai le tue valutazioni, perché Liquid AI non ne ha pubblicate.

Se hai un carico di lavoro di agenti ospitati la cui bolletta è dominata dai token di ragionamento, Ember-1 affronta un termine reale nella tua equazione dei costi, e vale le due settimane. Il test giusto è il traffico shadow verso il tuo fornitore attuale: invia una quota di richieste reali a entrambi, confronta gli output, lascia stare i risultati in produzione. È anche il consiglio che la copertura critica indipendente del rilascio ha dato, insieme a un avvertimento onesto — comprimere la deliberazione rischia di far perdere un passaggio di cui il modello aveva bisogno, e in un agente questo si manifesta più tardi come una chiamata a uno strumento sbagliata anziché come una frase sbagliata.

Nessuno dei due modelli è su OrcaRouter. Se vuoi testare il pattern anziché questi due artefatti — un piccolo modello fine-tunabile e un grande modello di ragionamento ospitato, in un'unica pipeline — è esattamente a questo che serve il DSL di routing: comporre più modelli in un'unica chiamata e lasciare che ciascuno gestisca la parte in cui è bravo, dietro una sola chiave e una sola fattura. Il confronto qui vale la pena farlo a livello architetturale, anche se entrambi gli endpoint specifici restano fuori portata.

Lo scambio, detto una volta

Ember-1 vende certezza del comportamento e incertezza della disponibilità: un modello la cui qualità è argomentata con cura e la cui disponibilità è esplicitamente condizionata. LFM2.5 2.6B Base vende certezza della disponibilità e incertezza del comportamento: un file che avrai sempre e la cui competenza è interamente funzione dell'addestramento che ci metti. I team con un problema di serving e nessuna capacità di addestramento dovrebbero guardare l'anteprima e sperare che diventi permanente. I team con capacità di addestramento e un compito ristretto dovrebbero scaricare la base e smettere di aspettare la roadmap di chiunque.

Quello che l'abbinamento mostra davvero è che "efficienza" ha smesso di significare una sola cosa. Per Ember-1 significa meno token alla stessa qualità sull'hardware di qualcun altro. Per LFM2.5 2.6B Base significa un modello abbastanza piccolo che l'hardware smette del tutto di essere di qualcun altro. Sono entrambe buone risposte e non sono intercambiabili.