AesCode-8B vs MathForm-8B: Beide zijn 8B-fine-tunes waarvan een machine de output kan controleren

AesCode-8B en MathForm-8B verschenen binnen acht weken van elkaar, beide uit repositories in plaats van persberichten, en het toeval is interessanter dan het op het eerste gezicht lijkt. Beide starten vanaf een Qwen3-familie checkpoint. Beide besteden hun volledige trainingsbudget aan een nauwe outputvorm. En beide zijn gebouwd rond een checker: MathForm-8B wordt getraind tegen het oordeel van een Lean 4-compiler, en AesCode-8B wordt beoordeeld door elke kandidaatpagina in een sandboxbrowser te renderen en de DOM, de berekende stijlen en een screenshot terug te lezen. Geen van beide is een chatbot en geen van beide probeert er een te worden. Wat hen onderscheidt is wat een machine kan verifiëren en wat niet — en, in het geval van de nieuwere van de twee, wat er gebeurt wanneer de helft van de score afkomstig is van een beoordelaar die niemand heeft genoemd.

De publicatiegegevens zijn niet symmetrisch. MathForm-8B is afkomstig van OpenBMB en de modelkaart dateert de release op 2026-08-14; het is gebouwd op Qwen3-8B en getraind op FormalVerse, een corpus van ongeveer 367.000 geverifieerde Lean 4-voorbeelden, met supervised fine-tuning gevolgd door reinforcement learning die Lean-compilatie en semantische consistentiecontroles als beloningssignaal gebruikt. AesCode-8B bevat nergens in zijn bestanden een releasedatum. Microsoft heeft de Hugging Face-repository op 2026-09-29 aangemaakt, de gewichten op 2026-10-07 om 03:35 UTC vastgelegd met het bericht "Release AesCode-8B", en de trainingscode op 2026-10-08 op GitHub gepubliceerd. Geen van beide gebeurtenissen ging gepaard met een aankondiging, de citatie op de modelkaart luidt "Under review, 2027", en de repository vertoonde op het moment van schrijven twee downloads. Het is fine-tuned op basis van Qwen3-VL-8B-Instruct, wat juist het vermelden waard is omdat het niet dezelfde voorouder is als die van MathForm-8B.

De afkomst verklaart het grootste deel van de splitsing

Qwen3-8B en Qwen3-VL-8B-Instruct delen een generatie en een familienaam, maar niet een functie. Qwen3-8B is een tekstgerichte generalist: ongeveer 8,2 miljard totale parameters, waarvan ongeveer 7 miljard niet-embedding, gegroepeerde-query-aandacht, een native context van 32K tokens die via YaRN uitbreidbaar is tot 131K, en training over 119 talen en dialecten. Qwen3-VL-8B-Instruct is het visie-taal-zustermodel, en het is het checkpoint waar AesCode-8B vanaf start — de gepubliceerde AesCode-configuratie is een rechtstreeks Qwen3-VL-recept met 36 verborgen lagen, verborgen grootte 4.096, 32 aandachtshoofden met 8 sleutel-waarde-hoofden en een vocabulaire van 151.936 tokens.

Die fork bepaalt de invoerzijde van beide specialisten voordat een van beide was getraind. MathForm-8B neemt tekst en geeft tekst uit in een formele syntaxis. AesCode-8B neemt tekst plus een optionele referentieafbeelding en geeft een document uit.

• Base — MathForm-8B: Qwen3-8B, alleen tekst. AesCode-8B: Qwen3-VL-8B-Instruct, afbeelding en tekst als invoer.

• Parameters — MathForm-8B: ongeveer 8,2B. AesCode-8B: ongeveer 8,8B in bf16 verdeeld over vier shards, wat Hugging Face afrondt naar 9B.

• Trainingsgegevens — MathForm-8B: FormalVerse, ongeveer 367K geverifieerde Lean 4-voorbeelden. AesCode-8B: 3.000 cold-startdemonstraties, daarna GDPO reinforcement learning op 7.408 prompts gedurende 400 stappen.

• Wat controleert de uitvoer — MathForm-8B: een Lean 4-compiler, plus een semantische-consistentiecontrole tegen het oorspronkelijke probleem. AesCode-8B: een in een sandbox uitgevoerde Playwright-rendering met zes deterministische verifieerders en één door het model beoordeelde rubric.

• Licentie — beide Apache 2.0, beide vrij toegankelijk, beide voortkomend uit de backbone van de Qwen3-familie.

• Overal gehost — geen van beide, voor zover wij kunnen nagaan.

Twee verschillende betekenissen van "verifieerbaar"

Dit is het onderscheid waar het de moeite loont om even bij stil te staan, want "machine-checkbaar" wordt voor beide gebruikt en het betekent niet hetzelfde.

De checker van MathForm-8B is een bewijsassistent. Lean 4 accepteert een stelling of niet, en de uitspraak is geen kwestie van mening, een beoordelingsschema of de smaak van een beoordelaar. De trainingslus is op dat signaal gericht: de SFT-fase op FormalVerse leert de mapping van een informeel probleem naar een formele stelling met een imports-header en een benoemde stelling, en de RL-fase scherpt die aan met compilatie plus een consistentiecontrole die vraagt of de formalisering nog steeds zegt wat het oorspronkelijke probleem zei. Compilatie is binair en reproduceerbaar door iedereen met dezelfde Lean-versie. Consistentiecontrole is de zachtere helft, en het is de helft waar de gerapporteerde cijfers zwak worden — precies wat de gepubliceerde resultaten laten zien.

De checker van AesCode-8B is een renderer. Kandidaten worden gerenderd in een sandboxed Playwright-browser met externe verzoeken geblokkeerd, en het harnas leest de DOM, berekende stijlen, bounding boxes, consolestatus en een screenshot terug. Zes deterministische kanalen scoren de parseerbare zaken — uitvoering, exacte tekst, grensgedrag, tabel- en grafiekgegevens, semantische lay-out, witruimte — en een zevende, de Visual Graph Rubric, scoort geometrie en plaatsing via aan grafieken gebonden ja/nee-vragen. Tabellen moeten echte HTML-tabellen zijn en grafieken moeten ECharts-specificaties zijn, wat een beperking is die echt werk verricht: het dwingt de uitvoer in een vorm die een verificateur kan parsen. De deterministische helft is echt reproduceerbaar. De visuele helft wordt beoordeeld door een vision-languagemodel waarvan de documentatie de identiteit niet noemt, wat betekent dat niemand buiten het lab het kan reproduceren.

Dus de eerlijke vergelijking is niet "de een is geverifieerd en de ander niet." Het is dat het primaire signaal van MathForm-8B een compiler is en het secundaire signaal een consistentiecontrole, terwijl het primaire signaal van AesCode-8B een reeks deterministische DOM-asserties is en het secundaire signaal de mening van een model, verpakt in dezelfde totaalscore.

Wat elk van hen rapporteert, en wat dat waard is

MathForm-8B rapporteert een gemiddelde Pass@8 van 88,06% onder de syntaxcontrole en 72,37% onder de consistentiecontrole over zes benchmarks. De spreiding per benchmark is het interessante deel: 95,06% consistentie op FormalIMATH en 94,83% op ProverBench, dan 63% op FATE-H en 37% op FATE-X. Die laatste twee zijn de moeilijke, realistische uitspraken, en de terugval van midden negentig naar midden dertig procent is de eerlijke vorm van het vermogen. Al deze cijfers zijn door de leverancier gerapporteerd en niet gereproduceerd, en de benchmarkmix is gewogen naar de gemakkelijkere sets.

AesCode-8B rapporteert 82,94 Totaal op de infographic-rubric van Microsoft met 300 steekproeven — Tekst 94,06, Grens 88,36, Grafiek 87,79, Regel 90,41, Inhoud 86,41, Lay-out 87,80, Stijl 53,21, Visueel 75,80 — met generaties per prompt en zonder selectie. Microsoft rapporteert ook dat het de referentiegeconditioneerde GPT-5.5 met 81,28 en Claude Opus 4.8 met 81,28 verslaat, dat een canvas-overflow-fout zich bij 4,3% van de 300 steekproeven herhaalt, en dat 22,4 punten voor Visueel de 32B-companion scheiden van zijn eigen backbone. Elk cijfer is van de leverancier, op de taak van de leverancier, gescoord tegen kanalen die de leverancier heeft gekozen.

De twee reeksen getallen kunnen helemaal niet met elkaar worden vergeleken. Er is geen gedeelde taak, geen gedeelde maatstaf en geen gedeelde beoordelaar. Als je 88,06% naast 82,94% zet, vergelijk je een slagingspercentage voor Lean-formalisering met een totaalscore voor een infographic, en geen van beide modellen is ooit geëvalueerd op wat het andere doet.

Eén asymmetrie is het waard om te benoemen, omdat ze tegen het nieuwere model indruist. De hoofdmetriek van MathForm-8B heeft een ingebouwde externe scheidsrechter: iedereen kan Lean installeren, dezelfde benchmarks laden en controleren of de statements compileren. Die van AesCode-8B niet — de deterministische verificatoren zouden door een vastberaden buitenstaander opnieuw kunnen worden uitgevoerd, maar de visuele helft van de score hangt af van een beoordelaar die de paper niet heeft geïdentificeerd. Een niet-gereproduceerd percentage geslaagde compilaties is een zwakkere bewering dan een benchmarktabel, en toch een sterkere dan een niet-gereproduceerde rubricscore met daarin een anonieme beoordelaar.

Ze uitvoeren is een andere kwestie dan elk van beide scores.

Beide zijn tegenwoordig selfhostbeslissingen. MathForm-8B is met een ruime marge de goedkoopste: een checkpoint van ongeveer 8,2B dat alleen tekst ondersteunt, met een generatiebudget van ongeveer 16K tokens Lean-output, dat na quantisatie op één middenklassekaart past. AesCode-8B is een vision-language-model van 8,8B waarvan het serveerpad zowel afbeeldingen als tekst meeneemt; het eigen commando van de kaart is vllm serve microsoft/AesCode-8B --limit-mm-per-prompt image=2 --max-model-len 24576, en 17,5 GB aan bf16-gewichten plus een KV-cache voor 24.576 tokens en twee afbeeldingen betekent dat een kaart van 24 GB krap is en 40-48 GB de realistische ondergrens. Reken ook op een renderingstack als je je eigen outputs wilt beoordelen, want zo is elke kwaliteitsclaim over het model tot stand gekomen.

De grotere verborgen kosten zijn dat beide modellen specialisten zijn die je permanent zou adopteren. Een team dat formalisering en documentgeneratie nodig heeft, draait nu twee 8B-servingpaden, twee sets promptformaten, twee storingsprofielen, en geen van beide modellen kan het werk van het andere opvangen. Dat is precies waarvoor een routeringslaag bestaat: houd de specialisten daar waar de economie en de gegevensverwerking het rechtvaardigen om een GPU in eigen beheer te hebben, en stuur het algemene verkeer naar iets dat achter hetzelfde endpoint wordt gehost. Concreet zijn de generalistische tegenhangers van deze twee basismodellen aanroepbaar — Qwen3-VL-8B-Instruct voor $0,18 per miljoen inputtokens en $0,70 per miljoen outputtokens bij een context van 131.072 tokens, naast de Qwen 3.8-familie en andere open checkpoints — allemaal via de ene API van OrcaRouter voor meer dan 200 modellen, waarbij de lijstprijs van de provider met 0% markup wordt doorgegeven en er automatische failover tussen providers is. Geen van beide specialisten is hier routeerbaar, of op enige andere plek die we kunnen vinden; wat routeerbaar is, is de generalist waarop je terugvalt wanneer de smalle taak is afgerond, en dat is het verschil tussen het uitproberen van een onderzoekscheckpoint en er een dragende afhankelijkheid van maken.

Kiezen tussen hen, als je echt moet

Kies MathForm-8B wanneer het artefact gecompileerd moet worden. Conversie van probleembanken, formele corpora voor een bewijzer, het voorformatteren van beweringen voor tooling op Lean-basis — dat is de hele taakomschrijving, en het is de enige van de twee die daarvoor is getraind. Neem de FATE-cijfers serieus bij het bepalen van de scope: bij de moeilijkste realistische beweringen blijkt ongeveer een derde consistent te zijn, en je zult hoe dan ook een stap voor menselijke beoordeling inbouwen.

Kies AesCode-8B wanneer het artefact gerenderd moet worden. Er gaat een briefing in, er komt een bewerkbaar HTML-document uit, tabellen zijn tabellen en grafieken zijn grafiekspecificaties, en het geheel is te diffen in Git. Accepteer het Style-plafond — 53,21, een dimensie die inhoudt dat er vóór oplevering geen verdere visuele revisie nodig is — als de eerlijke maatstaf voor hoeveel bewerking er nog rest, en accepteer dat de context van 24.576 tokens alleen is gevalideerd op afzonderlijke infographicpagina's en niet op de decks met meerdere slides die mensen echt willen.

De keuze waarvoor de meeste teams in de praktijk komen te staan, is echter geen van beide. Het is de vraag of een van deze smalle specialisten überhaupt een deployment waard is, of dat de generalist erachter, aangeroepen via een API, goed genoeg is voor het volume dat je hebt. Dat is een middag prompttesten in plaats van een GPU-aankoop, en de eigen cijfers van beide kaarten geven je de reden om het te doen: de consistentie van MathForm-8B op de harde set ligt op 37%, en de Style-score van AesCode-8B ligt op 53%, dus geen van beide is een model dat je zonder toezicht in een pipeline zou zetten.

Wat beide releases gemeen hebben over hoe modellen nu worden uitgebracht

Twee 8B-finetunes, acht weken na elkaar, van twee verschillende labs, uitgebracht zonder aankondiging, zonder productpagina en zonder onafhankelijke evaluatie, beide gebouwd rond een verificatielus, beide Apache 2.0, geen van beide door wie dan ook geserveerd. Dat patroon is meer het verhaal dan welk van beide modellen dan ook. De onderzoeksmethode is verschoven naar de beloningsfunctie — het compiler-signaal van OpenBMB, Microsofts ontkoppelde crossmodale kanalen — en de gepubliceerde artefacten zijn het trainingsrecept plus de gewichten geworden, waarbij de paper later komt, als die al komt.

Wat dat betekent voor iedereen die een vergelijking als deze leest, is dat de eigen cijfers van de leverancier voorlopig alles zijn wat je krijgt, en de nuttige vraag is niet hoe hoog ze zijn, maar hoe controleerbaar ze zijn. Het overflowpercentage van AesCode-8B en zijn Style ceiling zijn controleerbare claims die als mislukkingen worden gepresenteerd. Het FATE-X-consistentiecijfer van MathForm-8B is hetzelfde. Dat zijn de cijfers die je moet lezen, en de cijfers die je zelf opnieuw moet uitvoeren zodra de checkers end-to-end reproduceerbaar zijn.