Ember-1 vs MathForm-8B: Due modelli creati restringendo una base presa in prestito

Ember-1 e MathForm-8B condividono una strategia che nessuno dei due laboratori pubblicizza come tale: entrambi sono riduzioni di un modello addestrato da qualcun altro. Ember-1 è il derivato specializzato di Fireworks Research del Kimi K3 di Moonshot AI, pubblicato il 23 settembre 2026, riaddestrato in modo da raggiungere l'accuratezza di K3 con circa il 40% in meno di token. MathForm-8B è il modello di autoformalizzazione da 8B di OpenBMB, rilasciato in sordina il 14 agosto 2026 come fine-tune Apache-2.0 del Qwen3-8B di Alibaba che trasforma la matematica informale in enunciati di teoremi Lean 4 che un compilatore può verificare. Una riduzione ha eliminato la deliberazione sprecata e mantenuto intatta la capacità generale. L'altra ha eliminato quasi tutta la capacità generale e ha comprato la verificabilità. Metterli insieme è il modo più chiaro per vedere quanto costa effettivamente una specializzazione, perché i due modelli hanno speso i loro budget di addestramento su lati opposti di quel bilancio.

Due tipi di restringimento

L'intervento di Fireworks Research è comportamentale. Ember-1 mantiene l'architettura di Kimi K3 e la sua ampiezza — matematica, programmazione, aderenza alle istruzioni, conversazione, ricerca, uso di strumenti e ingegneria del software sono tutti presenti nel mix di addestramento — e cambia solo quanto a lungo il modello riflette prima di rispondere. Il risultato riportato è che la lunghezza del ragionamento è diminuita del 35–50% senza perdita di accuratezza su sette benchmark e due test A/B di produzione dei clienti, con un carico di lavoro di programmazione in produzione sceso da 49,3K a 29,9K token di output mentre il suo punteggio si è mantenuto a 0,753 contro 0,751. Ogni cifra è riportata dal fornitore e non riprodotta.

L'intervento di OpenBMB è contrattuale. MathForm-8B prende Qwen3-8B e indirizza l'intero budget di addestramento verso un'unica forma di output: un enunciato Lean 4 con un header imports e un teorema con nome. La pipeline consiste in un fine-tuning supervisionato su FormalVerse — un corpus di circa 367.000 esempi Lean 4 verificati che OpenBMB ha costruito e rilasciato insieme al modello — seguito da apprendimento per rinforzo che usa la compilazione Lean e il feedback di coerenza semantica come segnale di ricompensa. Il modello non risolve dimostrazioni. Scrive l'enunciato che un dimostratore completerà, e la stessa impostazione dell'articolo descrive la valutazione su sei benchmark come il punto dell'esercizio.

A cosa ha rinunciato ciascuno

Ember-1 ha rinunciato a molto poco sulla carta, che è l'intero punto. La sua scheda pubblicata mostra una vittoria su Terminal Bench 2.1 all'82,0% contro l'80,9% di Kimi K3 Max e su DeepSWE 1.1 al 75,2% contro il 66,4%, e sconfitte di misura su SWE-bench Verified al 92,2% contro il 93,2% e su SWE-Interact al 20,0% contro il 21,3%. Quelli sono numeri del fornitore su set scelti dal fornitore, ma la forma è coerente: un modello che non ha tanto perso capacità quanto reindirizzato dove spende lo sforzo. I risparmi di token, però, vanno dal 51,9% su Terminal Bench fino al 5,9% su τ-2 Bench Airline, quindi "circa 40%" è una media su una gamma molto ampia.

MathForm-8B ha rinunciato alla maggior parte di ciò per cui Qwen3-8B è noto. Non sostiene una conversazione generale, non copre le 119 lingue e i dialetti su cui Qwen3-8B è stato addestrato e non accetta immagini o audio. Il suo budget di generazione è calibrato per l'output di Lean, non per un ragionamento misto esteso. Ciò che ha mantenuto è una licenza permissiva e un footprint ridotto: quattro shard safetensors in BF16, in esecuzione con Transformers, vLLM o SGLang dietro un endpoint compatibile con OpenAI, con un percorso di compilazione che richiede un Kimina Lean Server su Lean 4.21.0.

I numeri misurano cose diverse, e il divario è il punto

Il dato principale di Ember-1 è una percentuale di attività completate correttamente da un agente: Terminal Bench 2.1, 89 campioni, 82,0%. I dati principali di MathForm-8B sono punteggi medi Pass@8 su sei benchmark di autoformalizzazione: 88,06% con un controllo sintattico e 72,37% con un controllo di coerenza più rigoroso. Non sono sullo stesso asse. Uno misura se un agente ha portato a termine un lavoro in un terminale; l'altro misura se un enunciato di teorema generato viene analizzato sintatticamente e se significa la stessa cosa del problema informale da cui proviene.

Lo scarto di 88,06 rispetto a 72,37 all'interno dei risultati di MathForm è il numero più istruttivo. Il divario tra "questo compila" e "questo compila e dice ciò che intendevo" è di circa sedici punti, ed è la modalità di errore che rende difficile l'autoformalizzazione: un'affermazione che supera il controllo dei tipi mentre indebolisce silenziosamente l'asserzione originale è peggio di un errore evidente, perché nulla a valle lo segnala. Sui set più difficili il controllo di coerenza scende al 63% su FATE-H e al 37% su FATE-X, mentre set facili come FormalIMATH si attestano al 95,06% e ProverBench al 94,83%. Questo è uno specialista che è onesto su dove uno specialista è debole, ed è più utile di una singola media.

Il contrasto, dimensione per dimensione

• Modello base — Ember-1: Kimi K3. MathForm-8B: Qwen3-8B.

• Che cosa ha cambiato l’addestramento — Ember-1: per quanto tempo ragiona il modello, a parità di capacità. MathForm-8B: che cosa restituisce il modello, con la generalità in gran parte sacrificata.

• Parametri — Ember-1: non divulgati. MathForm-8B: ~8B, denso, BF16.

• Contratto di output — Ember-1: testo ordinario e chiamate di strumenti, con qualità di livello K3. MathForm-8B: un enunciato Lean 4 con un'intestazione e un teorema denominato.

• Licenza e pesi — Ember-1: nessuno dei due pubblicato; anteprima di ricerca tramite la piattaforma proprietaria del fornitore. MathForm-8B: Apache 2.0, pesi e dataset entrambi scaricabili.

• Titolo riportato — Ember-1: 82,0% su Terminal Bench 2.1 con il 51,9% di token in meno. MathForm-8B: 88,06% di Pass@8 medio con verifica sintattica, 72,37% con verifica di coerenza.

• Verifica indipendente — nessuna delle due; entrambe sono dichiarate dal fornitore e non riprodotte.

La questione della licenza conta più dei benchmark

Nonostante tutta la differenza numerica, la differenza pratica tra questi due rilasci è la distribuzione. MathForm-8B è un file. OpenBMB ha pubblicato i pesi, il dataset FormalVerse e il paper lo stesso giorno, sotto Apache 2.0, senza alcun annuncio e senza API ospitata — la model card è il lancio. Puoi scaricarlo questo pomeriggio e farlo girare su una singola GPU, e nessuno può riprenderselo. Ember-1 è un servizio. Non ci sono pesi, nessun prezzo pubblicato, e la finestra di accesso è descritta come un periodo serverless di due settimane la cui continuazione dipende dalla domanda. Puoi chiamarlo oggi e non puoi essere certo di poterlo chiamare a novembre.

Quella differenza determina anche per cosa può essere usato ciascun modello. Un componente di formalizzazione appartiene a una pipeline che controlli tu, bloccata a una versione, con la toolchain Lean sulla stessa macchina — ecco perché un checkpoint Apache-2.0 senza gating è la forma giusta per il lavoro di MathForm-8B, e perché il link al codice GitHub mancante nel suo README (ancora un segnaposto al momento della scrittura) è una lacuna più fastidiosa di qualsiasi numero di benchmark. Un modello a costo di ragionamento appartiene dietro un'API, dove il conto dei token è la cosa da ottimizzare, e dove i fornitori competono su prezzo e latenza. Anche la forma di Ember-1 si adatta al suo lavoro; significa solo che la dipendenza è commerciale anziché tecnica.

Dove una pipeline userebbe entrambi

Questi due modelli sono complementari anziché concorrenti, e la composizione è facile da descrivere: uno specialista di formalizzazione converte un problema in un'affermazione verificabile, e un modello di ragionamento lavora sull'affermazione o sull'ingegneria circostante. Nessuno dei due è su OrcaRouter — MathForm-8B è solo self-hosted, ed Ember-1 è sull'anteprima del fornitore — ma la composizione stessa è un pattern per cui esiste il nostro DSL di routing. Comporre diversi modelli in un'unica chiamata è il modo in cui una pipeline ottiene uno specialista e un generalista senza mantenere due percorsi di integrazione e due contratti, e la fusione di modelli va un passo oltre consentendo a un gruppo di modelli di rispondere insieme quando la modalità di fallimento di un singolo modello è costosa.

Per uno stack di formalizzazione nello specifico, l'argomento a favore della composizione è più forte del solito. La modalità di errore visibile è un enunciato che compila e significa qualcosa di leggermente diverso, e la difesa più economica contro un errore silenzioso è un secondo modello che legge lo stesso problema — il che è una decisione di routing, non una decisione di addestramento.

Qual è l'acquisto migliore?

Se ti serve matematica verificabile automaticamente, MathForm-8B è l'unico dei due che ne produca, e il suo costo principale è la generalità che non avresti comunque usato per questo compito. Scaricalo, prevedi un budget per il server Lean e costruisci la tua valutazione: l'articolo di OpenBMB non ti dirà come si comporta sulla tua distribuzione.

Se hai bisogno di un ragionatore generale con una spesa in token inferiore, Ember-1 è pensato per te, e il prossimo passo giusto è lo shadow traffic verso qualunque cosa esegui oggi, piuttosto che un confronto di benchmark. Il suo rischio è la disponibilità, non la capacità, e questo è un rischio che puoi coprire mantenendo il livello di routing tra la tua applicazione e il modello.

La conclusione scomoda per chiunque speri che uno di questi risolva la questione è che nessuno dei due è stato valutato in modo indipendente. MathForm-8B è pubblico da sei settimane e nessuna terza parte ha pubblicato una riproduzione; Ember-1 è pubblico da un giorno. Entrambi chiedono che sia tu il valutatore, che è la condizione normale quando si sceglie un modello specializzato nel 2026.

Ciò che dimostrano è che la strategia di restringimento funziona in entrambe le direzioni. Un modello di frontiera può essere reso più economico senza essere reso peggiore, e un piccolo modello di base può essere reso rigoroso orientando il suo addestramento verso un compilatore. La domanda interessante non è quale di questi due approcci prevalga, ma per quanto tempo ancora l'uno o l'altro resti necessario una volta che le tecniche in essi contenute diventino prassi standard.