Ember-1 vs MathForm-8B: Twee modellen gebouwd door het vernauwen van een geleende basis

Ember-1 en MathForm-8B delen een strategie die geen van beide labs als zodanig adverteert: beide zijn vernauwingen van een model dat iemand anders heeft getraind. Ember-1 is Fireworks Research' gespecialiseerde afgeleide van Moonshot AI's Kimi K3, gepubliceerd op 23 september 2026, opnieuw getraind zodat het de nauwkeurigheid van K3 bereikt met ongeveer 40% minder tokens. MathForm-8B is OpenBMB's 8B-autoformaliseringsmodel, op 14 augustus 2026 geruisloos uitgebracht als een Apache-2.0-finetune van Alibaba's Qwen3-8B die informele wiskunde omzet in Lean 4-stellingen die een compiler kan controleren. De ene vernauwing verwijderde verspilde deliberatie en hield de algemene capaciteit intact. De andere verwijderde bijna alle algemene capaciteit en kocht daarvoor verifieerbaarheid. Ze samen bekijken is de zuiverste manier om te zien wat een specialisatie werkelijk kost, omdat de twee modellen hun trainingsbudgetten aan tegenovergestelde zijden van dat grootboek hebben besteed.

Twee soorten vernauwing

De interventie van Fireworks Research is gedragsmatig. Ember-1 behoudt de architectuur van Kimi K3 en de breedte ervan — wiskunde, programmeren, het volgen van instructies, gesprek, zoeken, toolgebruik en software-engineering komen allemaal voor in de trainingsmix — en verandert alleen hoe lang het model nadenkt voordat het antwoordt. Het gerapporteerde resultaat is dat de redeneerlengte met 35–50% daalde zonder verlies van nauwkeurigheid over zeven benchmarks en twee productie-A/B-tests bij klanten, waarbij één productieworkload voor programmeren daalde van 49,3K naar 29,9K uitvoertokens, terwijl de score op 0,753 bleef tegenover 0,751. Elk cijfer is door de leverancier gerapporteerd en niet gereproduceerd.

OpenBMB's interventie is contractueel. MathForm-8B neemt Qwen3-8B en richt het volledige trainingsbudget op één outputvorm: een Lean 4-statement met een imports-header en een benoemde stelling. De pijplijn bestaat uit supervised fine-tuning op FormalVerse — een corpus van ongeveer 367.000 geverifieerde Lean 4-voorbeelden dat OpenBMB bouwde en samen met het model uitbracht — gevolgd door reinforcement learning die Lean-compilatie en feedback over semantische consistentie als beloningssignaal gebruikt. Het model lost geen bewijzen op. Het schrijft de stelling die een bewijzer zal afmaken, en de eigen framing van het paper beschrijft de evaluatie op zes benchmarks als het doel van de exercitie.

Wat ieder opgaf

Ember-1 gaf op papier maar heel weinig prijs, en dat is precies de hele claim. De gepubliceerde cijfers laten een overwinning zien op Terminal Bench 2.1 met 82,0% tegen 80,9% van Kimi K3 Max en op DeepSWE 1.1 met 75,2% tegen 66,4%, en nipte nederlagen op SWE-bench Verified met 92,2% tegen 93,2% en SWE-Interact met 20,0% tegen 21,3%. Dat zijn leverancierscijfers op door de leverancier gekozen sets, maar de vorm is consistent: een model dat niet zozeer vermogen heeft verloren, maar eerder heeft verlegd waar het inspanning aan besteedt. De tokenbesparingen lopen echter uiteen van 51,9% op Terminal Bench tot 5,9% op τ-2 Bench Airline, dus "ongeveer 40%" is een gemiddelde over een zeer brede spreiding.

MathForm-8B heeft het grootste deel opgegeven van waar Qwen3-8B bekend om staat. Het voert geen algemeen gesprek, bestrijkt niet de 119 talen en dialecten waarop Qwen3-8B is getraind, en accepteert geen afbeeldingen of audio. Het generatiebudget is afgestemd op Lean-uitvoer, niet op uitgebreide gemengde redenering. Wat het behield, is een permissieve licentie en een kleine voetafdruk: vier safetensors-shards in BF16, draaiend onder Transformers, vLLM of SGLang achter een OpenAI-compatibel endpoint, met een compilatiepad dat een Kimina Lean Server op Lean 4.21.0 verwacht.

De cijfers meten verschillende dingen, en dat verschil is juist het punt.

Het kerncijfer van Ember-1 is een percentage van taken dat een agent correct heeft voltooid — Terminal Bench 2.1, 89 samples, 82,0%. De kerncijfers van MathForm-8B zijn gemiddelde Pass@8-scores over zes autoformaliseringsbenchmarks: 88,06% onder een syntaxiscontrole en 72,37% onder een strengere consistentiecontrole. Die liggen niet op dezelfde as. De een meet of een agent een klus in een terminal heeft afgerond; de ander meet of een gegenereerde stelling parseert en of die hetzelfde betekent als het informele probleem waaruit die voortkwam.

De spreiding van 88,06 tegen 72,37 binnen de eigen resultaten van MathForm is het leerzamere getal. Het gat tussen 'dit compileert' en 'dit compileert en zegt wat ik bedoelde' is ongeveer zestien punten, en het is de faalmodus die autoformalization moeilijk maakt: een uitspraak die typecheckt terwijl ze de oorspronkelijke bewering stilletjes afzwakt, is erger dan een duidelijke fout, omdat niets verderop in de pijplijn het signaleert. Op de moeilijkste sets zakt de consistentiecontrole naar 63% op FATE-H en 37% op FATE-X, terwijl makkelijke sets zoals FormalIMATH op 95,06% uitkomen en ProverBench op 94,83%. Dat is een specialist die eerlijk is over waar een specialist zwak is, en het is nuttiger dan één enkel gemiddelde.

Het contrast, dimensie voor dimensie

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

• Wat de training veranderde — Ember-1: hoe lang het model redeneert, met gelijkblijvend vermogen. MathForm-8B: wat het model uitvoert, waarbij de algemeenheid grotendeels is prijsgegeven.

• Parameters — Ember-1: niet bekendgemaakt. MathForm-8B: ~8B, dense, BF16.

• Uitvoercontract — Ember-1: gewone tekst en aanroepen van tools, van K3-niveau kwaliteit. MathForm-8B: een Lean 4-statement met een header en een benoemde stelling.

• Licentie en gewichten — Ember-1: niets gepubliceerd; onderzoekspreview via het eigen platform van de leverancier. MathForm-8B: Apache 2.0, zowel de gewichten als de dataset zijn downloadbaar.

• Gerapporteerde kop — Ember-1: 82,0% Terminal Bench 2.1 met 51,9% minder tokens. MathForm-8B: 88,06% gemiddelde Pass@8 onder syntaxiscontrole, 72,37% onder consistentiecontrole.

• Onafhankelijke verificatie — geen van beide; beide zijn door de leverancier gerapporteerd en niet gereproduceerd.

De licentieregel weegt zwaarder dan de benchmarks

Ondanks alle numerieke verschillen is het praktische verschil tussen deze twee releases de distributie. MathForm-8B is een bestand. OpenBMB publiceerde de gewichten, de FormalVerse-dataset en de paper op dezelfde dag, onder Apache 2.0, zonder aankondiging en zonder gehoste API — de model card is de lancering. Je kunt het vanmiddag downloaden en op één GPU draaien, en niemand kan het terugpakken. Ember-1 is een dienst. Er zijn geen gewichten, geen gepubliceerde prijs, en het toegangsvenster wordt beschreven als een serverloze periode van twee weken waarvan de voortzetting afhangt van de vraag. Je kunt het vandaag aanroepen en je kunt er niet zeker van zijn dat je het in november kunt aanroepen.

Dat verschil bepaalt ook waarvoor elk model kan worden gebruikt. Een formalisatiecomponent hoort in een pipeline die je zelf beheert, vastgezet op een versie, met de Lean-toolchain op dezelfde machine — daarom is een niet-gated Apache-2.0-checkpoint de juiste vorm voor de taak van MathForm-8B, en daarom is de ontbrekende GitHub-codelink in de README (op het moment van schrijven nog steeds een placeholder) een vervelender gat dan welk benchmarkgetal dan ook. Een redeneerkostenmodel hoort achter een API, waar de tokenrekening het ding is dat wordt geoptimaliseerd, en waar leveranciers concurreren op prijs en latentie. De vorm van Ember-1 past ook bij zijn taak; het betekent alleen dat de afhankelijkheid commercieel is in plaats van technisch.

Waar een pijplijn beide zou gebruiken

Deze twee modellen zijn complementair in plaats van concurrerend, en de compositie is eenvoudig te beschrijven: een specialist in formalisering zet een probleem om in een controleerbare bewering, en een redeneermodel werkt aan de bewering of de omliggende engineering. Geen van beide staat op OrcaRouter — MathForm-8B is alleen zelfgehost, en Ember-1 staat in de eigen preview van de leverancier — maar de compositie zelf is een patroon waarvoor onze routing-DSL bestaat. Meerdere modellen samenvoegen tot één aanroep is hoe een pipeline een specialist en een generalist krijgt zonder twee integratiepaden en twee contracten te onderhouden, en modelfusie gaat nog een stap verder door een panel van modellen samen te laten antwoorden wanneer de faalmodus van een enkel model duur is.

Voor een formalisatiestack in het bijzonder is het argument voor compositie sterker dan gebruikelijk. De zichtbare faalmodus is een bewering die compileert en net iets anders betekent, en de goedkoopste verdediging tegen een stille fout is een tweede model dat hetzelfde probleem leest — wat een routeringsbeslissing is, geen trainingsbeslissing.

Wat is de betere koop

Als je machinaal controleerbare wiskunde nodig hebt, is MathForm-8B de enige van de twee die zoiets überhaupt produceert, en de voornaamste kostenpost is de algemeenheid die je voor deze taak toch niet van plan was te gebruiken. Download het, reserveer budget voor de Lean-server en bouw je eigen evaluatie — de paper van OpenBMB zal je niet vertellen hoe het presteert op jouw distributie.

Als je een generalistisch redeneermodel nodig hebt met een kleinere tokenrekening, is Ember-1 voor jou bedoeld, en de juiste volgende stap is schaduwverkeer tegen wat je vandaag draait in plaats van een benchmarkvergelijking. Het risico betreft de beschikbaarheid, niet het vermogen, en dat is een risico dat je kunt afdekken door de routeringslaag tussen je applicatie en het model te houden.

De ongemakkelijke conclusie voor iedereen die hoopt dat een van deze de kwestie beslecht, is dat geen van beide onafhankelijk is geëvalueerd. MathForm-8B is al zes weken openbaar en geen enkele derde partij heeft een reproductie gepubliceerd; Ember-1 is pas een dag openbaar. Beide vragen van jou dat je de evaluator bent, wat de normale omstandigheid is bij het kiezen van een gespecialiseerd model in 2026.

Wat ze wel bewijzen, is dat de vernauwingsstrategie in beide richtingen werkt. Een frontiermodel kan goedkoper worden gemaakt zonder slechter te worden, en een klein basismodel kan rigoureus worden gemaakt door zijn training op een compiler te richten. De interessante vraag is niet welke van deze twee benaderingen wint, maar hoeveel langer elk van beide nodig blijft zodra de technieken daarin standaardpraktijk worden.