AesCode-8B vs MathForm-8B: entrambi sono fine-tune da 8B il cui output può essere verificato da una macchina

AesCode-8B e MathForm-8B sono arrivati a otto settimane di distanza l'uno dall'altro, entrambi da repository anziché da comunicati stampa, e la coincidenza è più interessante di quanto non sembri a prima vista. Entrambi partono da un checkpoint della famiglia Qwen3. Entrambi spendono l'intero budget di addestramento su una forma di output ristretta. Ed entrambi sono stati costruiti attorno a un verificatore: MathForm-8B è addestrato contro il verdetto di un compilatore Lean 4, e AesCode-8B viene valutato renderizzando ogni pagina candidata in un browser in sandbox e rileggendo il DOM, gli stili calcolati e uno screenshot. Nessuno dei due è un chatbot e nessuno dei due cerca di diventarlo. Ciò che li distingue è cosa una macchina può verificare e cosa non può — e, nel caso del più recente dei due, cosa succede quando metà del punteggio arriva da un giudice che nessuno ha nominato.

I documenti di pubblicazione non sono simmetrici. MathForm-8B proviene da OpenBMB e la sua model card data il rilascio al 2026-08-14; è costruito su Qwen3-8B e addestrato su FormalVerse, un corpus di circa 367.000 esempi Lean 4 verificati, con fine-tuning supervisionato seguito da apprendimento per rinforzo che usa la compilazione Lean e i controlli di coerenza semantica come segnale di ricompensa. AesCode-8B non riporta alcuna data di rilascio in nessuno dei suoi file. Microsoft ha creato il repository Hugging Face il 2026-09-29, ha sottoposto i pesi a commit alle 03:35 UTC del 2026-10-07 con il messaggio "Release AesCode-8B" e ha pubblicato il codice di addestramento su GitHub il 2026-10-08. Nessun annuncio ha accompagnato nessuno dei due eventi, la citazione della model card recita "Under review, 2027" e il repository mostrava due download al momento della stesura. È stato sottoposto a fine-tuning a partire da Qwen3-VL-8B-Instruct, il che vale la pena notare proprio perché non è lo stesso progenitore di quello di MathForm-8B.

L'ascendenza spiega la maggior parte della divisione

Qwen3-8B e Qwen3-VL-8B-Instruct condividono una generazione e un nome di famiglia, ma non un compito. Qwen3-8B è un generalista solo testo: circa 8,2 miliardi di parametri totali, circa 7 miliardi dei quali non di embedding, attenzione con query raggruppate, una finestra di contesto nativa di 32K token estendibile a 131K tramite YaRN, e addestramento su 119 lingue e dialetti. Qwen3-VL-8B-Instruct è il fratello visione-linguaggio, ed è il checkpoint da cui parte AesCode-8B — la configurazione pubblicata di AesCode è una ricetta Qwen3-VL pura con 36 livelli nascosti, dimensione nascosta 4.096, 32 teste di attenzione con 8 teste chiave-valore e un vocabolario di 151.936 token.

Quella diramazione decide il lato di input di entrambi gli specialisti prima che l'uno o l'altro fosse addestrato. MathForm-8B prende testo ed emette testo in una sintassi formale. AesCode-8B prende testo più un'immagine di riferimento opzionale ed emette un documento.

• Base — MathForm-8B: Qwen3-8B, solo testo. AesCode-8B: Qwen3-VL-8B-Instruct, immagini e testo in input.

• Parametri — MathForm-8B: circa 8,2B. AesCode-8B: circa 8,8B in bf16 su quattro shard, che Hugging Face arrotonda a 9B.

• Dati di addestramento — MathForm-8B: FormalVerse, circa 367K esempi Lean 4 verificati. AesCode-8B: 3.000 dimostrazioni di avvio a freddo, poi apprendimento per rinforzo GDPO su 7.408 prompt per 400 passi.

• Cosa verifica l'output — MathForm-8B: un compilatore Lean 4, più un controllo di coerenza semantica rispetto al problema originale. AesCode-8B: un rendering Playwright in sandbox con sei verificatori deterministici e una rubrica valutata dal modello.

• Licenza — entrambi Apache 2.0, entrambi senza restrizioni, entrambi derivanti dal backbone della famiglia Qwen3.

• Ospitato ovunque — nessuno dei due, per quanto ci risulta.

Due diversi significati di "verificabile"

Questa è la distinzione su cui vale la pena soffermarsi con calma, perché "verificabile dalla macchina" viene usato per entrambe e non significa la stessa cosa.

Il verificatore di MathForm-8B è un assistente di prova. Lean 4 o accetta un enunciato o non lo accetta, e il verdetto non è questione di opinione, di una griglia di valutazione o del gusto di un giudice. Il ciclo di addestramento è puntato su quel segnale: la fase SFT su FormalVerse insegna la mappatura da un problema informale a un enunciato formale di teorema con un'intestazione imports e un teorema con nome, e la fase RL lo affina usando la compilazione più un controllo di coerenza che chiede se la formalizzazione dice ancora ciò che diceva il problema originale. La compilazione è binaria e riproducibile da chiunque abbia la stessa versione di Lean. Il controllo di coerenza è la metà più morbida, ed è la metà in cui i numeri riportati si indeboliscono — che è esattamente ciò che mostrano i risultati pubblicati.

Il checker di AesCode-8B è un renderer. I candidati vengono renderizzati in un browser Playwright in sandbox con richieste esterne bloccate, e l'harness rilegge il DOM, gli stili calcolati, i bounding box, lo stato della console e uno screenshot. Sei canali deterministici valutano le cose analizzabili — esecuzione, testo esatto, comportamento ai limiti, dati di tabelle e grafici, layout semantico, spazi bianchi — e un settimo, il Visual Graph Rubric, valuta geometria e posizionamento tramite domande sì/no basate su grafi. Le tabelle devono essere vere tabelle HTML e i grafici devono essere specifiche ECharts, il che è un vincolo che fa un lavoro reale: forza l'output in una forma che un verificatore può analizzare. La metà deterministica è genuinamente riproducibile. La metà visiva è giudicata da un modello visione-linguaggio la cui identità non è nominata dalla documentazione, il che significa che nessuno al di fuori del laboratorio può riprodurla.

Quindi il confronto onesto non è "uno è verificato e uno no". È che il segnale primario di MathForm-8B è un compilatore e il suo segnale secondario è un controllo di coerenza, mentre il segnale primario di AesCode-8B è un insieme di asserzioni DOM deterministiche e il suo segnale secondario è l'opinione di un modello, inserita all'interno dello stesso punteggio complessivo.

Cosa riporta ciascuno, e quanto vale

MathForm-8B riporta un Pass@8 dell'88,06% con il controllo della sintassi e del 72,37% con il controllo di coerenza su sei benchmark. La distribuzione per benchmark è la parte interessante: 95,06% di coerenza su FormalIMATH e 94,83% su ProverBench, poi 63% su FATE-H e 37% su FATE-X. Questi ultimi due sono gli enunciati difficili e realistici, e il calo da percentuali intorno al 95% a percentuali intorno al 35% è la forma onesta della capacità. Tutti questi valori sono dichiarati dal fornitore e non riprodotti, e la composizione dei benchmark è sbilanciata verso i set più facili.

AesCode-8B riporta 82,94 come punteggio complessivo sulla rubrica per infografiche da 300 campioni di Microsoft — Testo 94,06, Confini 88,36, Grafico 87,79, Regola 90,07, Contenuto 86,41, Layout 87,80, Stile 53,21, Visuale 75,80 — con tre generazioni per prompt e nessuna selezione. Microsoft riporta inoltre che supera GPT-5.5 con condizionamento al riferimento, a 81,28, e Claude Opus 4.8, a 80,39, sulla stessa rubrica, che un grave errore di overflow del canvas si ripresenta nel 4,3% dei 300 campioni e che 22,4 punti Visuale separano il companion da 32B dal suo stesso backbone. Ogni numero è del fornitore, su un task del fornitore, valutato rispetto a canali progettati dal fornitore.

I due insiemi di numeri non possono essere confrontati tra loro in alcun modo. Non c'è un compito condiviso, né una metrica condivisa, né un giudice condiviso. Mettere 88,06% accanto a 82,94% significherebbe confrontare un tasso di successo di formalizzazione Lean con un punteggio complessivo di un'infografica, e nessuno dei due modelli è mai stato valutato su ciò che fa l'altro.

Un'asimmetria merita di essere menzionata perché va contro il modello più recente. La metrica principale di MathForm-8B include un arbitro esterno: chiunque può installare Lean, caricare gli stessi benchmark e verificare se gli enunciati compilano. La metrica principale di AesCode-8B non ne ha uno — i verificatori deterministici potrebbero essere rieseguiti da un esterno determinato, ma la metà visiva del punteggio dipende da un giudice che l'articolo non ha identificato. Un tasso di superamento del compilatore non riprodotto è un'affermazione più debole di una tabella di benchmark, e comunque più forte di un punteggio di rubrica non riprodotto con un valutatore anonimo al suo interno.

Eseguirli è una questione diversa da entrambi i punteggi

Oggi entrambe sono decisioni di self-hosting. MathForm-8B è quella più economica di gran lunga: un checkpoint solo testo da circa 8,2B con un budget di generazione intorno ai 16K token di output Lean, che si quantizza su una singola scheda di fascia media. AesCode-8B è un modello visione-linguaggio da 8,8B il cui percorso di serving trasporta immagini oltre al testo; il comando proprio della scheda è vllm serve microsoft/AesCode-8B --limit-mm-per-prompt image=2 --max-model-len 24576, e 17,5 GB di pesi bf16 più una KV cache per 24.576 token e due immagini significa che una scheda da 24 GB è al limite e che 40-48 GB sono il minimo realistico. Metti in conto anche uno stack di rendering se vuoi valutare i tuoi output, perché è così che è stata formulata ogni affermazione sulla qualità del modello.

Il costo nascosto più grande è che entrambi i modelli sono specialisti che adotteresti in modo permanente. Un team che ha bisogno di formalizzazione e generazione di documenti ora gestisce due percorsi di serving da 8B, due set di formati di prompt, due profili di errore, e nessuno dei due modelli può assorbire il lavoro dell'altro. È il caso per cui esiste un livello di routing: mantenere gli specialisti dove l'economia e la gestione dei dati giustificano possedere una GPU, e inviare il traffico generale a qualcosa ospitato dietro lo stesso endpoint. Concretamente, i fratelli generalisti di queste due basi sono richiamabili — Qwen3-VL-8B-Instruct a 0,18 $ per milione di token in input e 0,70 $ per milione in output su un contesto di 131.072 token, insieme alla famiglia Qwen 3.8 e ad altri checkpoint aperti — il tutto tramite l'unica API di OrcaRouter che copre oltre 200 modelli, con il prezzo di listino del provider passato attraverso a markup 0% e failover automatico tra provider. Nessuno dei due specialisti è instradabile qui o in qualsiasi altro posto in cui riusciamo a trovarlo; ciò che è instradabile è il generalista su cui ricadi quando il lavoro di nicchia è finito, che è la differenza tra provare un checkpoint di ricerca e renderlo una dipendenza portante.

Scegliere tra loro, se proprio devi

Scegli MathForm-8B quando l'artefatto deve compilare. Conversione di banche di problemi, corpora formali per un dimostratore, preformattazione di enunciati per strumenti basati su Lean — questa è l'intera descrizione del lavoro, ed è l'unico dei due a essere stato addestrato per farlo. Prendi sul serio i numeri FATE quando definisci l'ambito: sugli enunciati realistici più difficili, circa un terzo risulta coerente, e dovrai comunque costruire una fase di revisione umana.

Scegli AesCode-8B quando l'artefatto deve essere renderizzato. Entra un brief, esce un documento HTML modificabile, le tabelle sono tabelle e i grafici sono specifiche di grafico, e il tutto fa diff in Git. Accetta il tetto Style — 53.21, una dimensione definita come quella che non richiede ulteriori revisioni visive prima della consegna — come la misura onesta di quanto editing rimanga, e accetta che il contesto da 24.576 token sia stato validato solo su singole pagine infografiche anziché sulle presentazioni multi-slide che le persone desiderano davvero.

La scelta che la maggior parte dei team si troverà davvero ad affrontare, però, non è nessuna delle due. È se uno di questi specialisti di nicchia valga affatto un deployment, oppure se il generalista che gli sta dietro, chiamato tramite un'API, sia abbastanza vicino per il volume che hai. Si tratta di un pomeriggio di test sui prompt, non dell'acquisto di una GPU, e i numeri stessi di entrambe le schede ti danno la ragione per farlo: la consistenza hard-set di MathForm-8B si attesta al 37%, e il punteggio Style di AesCode-8B si attesta al 53%, quindi nessuno dei due è un modello che metteresti in una pipeline senza supervisione.

Cosa ti dicono entrambe le release su come i modelli vengono rilasciati oggi

Due fine-tune da 8B, a otto settimane di distanza, provenienti da due laboratori diversi, rilasciati senza alcun annuncio, senza pagina di prodotto e senza valutazione indipendente, entrambi costruiti attorno a un ciclo di verifica, entrambi Apache 2.0, nessuno dei due servito da alcuno. È quel pattern la storia, più di quanto lo sia ciascuno dei due modelli. Il metodo di ricerca si è spostato nella funzione di ricompensa — il segnale del compilatore di OpenBMB, i canali cross-modali disaccoppiati di Microsoft — e gli artefatti pubblicati sono diventati la ricetta di addestramento più i pesi, con il paper che arriva più tardi, sempre che arrivi.

Ciò che questo significa per chiunque legga un confronto come questo è che per un po' gli unici numeri che ottieni sono quelli del fornitore stesso, e la domanda utile non è quanto siano alti, ma quanto siano verificabili. Il tasso di overflow di AesCode-8B e il suo tetto Style sono affermazioni verificabili travestite da fallimenti. Lo stesso vale per il dato di coerenza FATE-X di MathForm-8B. Questi sono i numeri da leggere, e quelli su cui tornare a rieseguire da soli non appena i verificatori saranno riproducibili end-to-end.