Ember-1 vs MathForm-8B: Dwa modele zbudowane przez zawężenie zapożyczonej podstawy

Ember-1 i MathForm-8B łączy strategia, której żadne z laboratoriów nie reklamuje jako takiej: oba są zawężeniami modelu wytrenowanego przez kogoś innego. Ember-1 to wyspecjalizowana pochodna Kimi K3 od Moonshot AI, opublikowana przez Fireworks Research 23 września 2026 r., ponownie wytrenowana tak, by osiągać dokładność K3 przy mniej więcej 40% mniejszej liczbie tokenów. MathForm-8B to 8B model do autoformalizacji od OpenBMB, po cichu wydany 14 sierpnia 2026 r. jako dostrojony na licencji Apache-2.0 model na bazie Qwen3-8B firmy Alibaba, który zamienia nieformalną matematykę w twierdzenia Lean 4, które kompilator może sprawdzić. Jedno zawężenie usunęło zbędne deliberacje i zachowało ogólne zdolności. Drugie usunęło niemal wszystkie ogólne zdolności i w zamian kupiło weryfikowalność. Zestawienie ich razem to najczystszy sposób, by zobaczyć, ile faktycznie kosztuje specjalizacja, ponieważ oba modele wydały swoje budżety szkoleniowe po przeciwnych stronach tego bilansu.

Dwa rodzaje zawężenia

Interwencja Fireworks Research ma charakter behawioralny. Ember-1 zachowuje architekturę Kimi K3 i jej szeroki zakres — matematyka, programowanie, podążanie za instrukcjami, konwersacja, wyszukiwanie, korzystanie z narzędzi i inżynieria oprogramowania — a zmienia tylko to, jak długo model deliberuje przed odpowiedzią. Zgłoszony wynik jest taki, że długość rozumowania spadła o 35–50% bez utraty dokładności w siedmiu benchmarkach i dwóch produkcyjnych testach A/B u klientów, przy czym jedno produkcyjne obciążenie związane z programowaniem spadło z 49,3 tys. do 29,9 tys. tokenów wyjściowych, a jego wynik utrzymał się na poziomie 0,753 wobec 0,751. Wszystkie liczby są raportowane przez dostawcę i nie zostały odtworzone.

Interwencja OpenBMB ma charakter kontraktowy. MathForm-8B bierze Qwen3-8B i kieruje cały budżet szkoleniowy na jeden format wyjściowy: sformułowanie w Lean 4 z nagłówkiem imports i nazwanym twierdzeniem. Proces polega na nadzorowanym dostrajaniu na FormalVerse — korpusie około 367 000 zweryfikowanych przykładów Lean 4, który OpenBMB zbudował i udostępnił wraz z modelem — a następnie na uczeniu ze wzmocnieniem, w którym kompilacja Lean i informacja zwrotna o spójności semantycznej służą jako sygnał nagrody. Model nie rozwiązuje dowodów. Pisze sformułowanie, które dokończy dowodzący, a sam sposób przedstawienia tego w artykule opisuje ocenę na sześciu benchmarkach jako sedno tego przedsięwzięcia.

Co każde z nich poświęciło

Ember-1 na papierze ustąpił bardzo niewiele i na tym polega cała teza. Jego opublikowany arkusz wyników pokazuje zwycięstwo w Terminal Bench 2.1 przy 82,0% wobec 80,9% Kimi K3 Max oraz w DeepSWE 1.1 przy 75,2% wobec 66,4%, a także niewielkie porażki w SWE-bench Verified przy 92,2% wobec 93,2% i w SWE-Interact przy 20,0% wobec 21,3%. To liczby dostawcy na zestawach wybranych przez dostawcę, ale kształt jest spójny: model, który nie tyle utracił zdolności, ile przekierował to, na co zużywa wysiłek. Oszczędności tokenów wahają się jednak od 51,9% w Terminal Bench do 5,9% w τ-2 Bench Airline, więc „około 40%” to średnia z bardzo szerokiego rozrzutu.

MathForm-8B zrezygnował z większości tego, z czego znany jest Qwen3-8B. Nie prowadzi ogólnej rozmowy, nie obejmuje 119 języków i dialektów, na których trenowano Qwen3-8B, i nie przyjmuje obrazów ani dźwięku. Jego budżet generowania jest dostosowany do wyników Lean, a nie do rozszerzonego mieszanego rozumowania. Zachował permisywną licencję i niewielki rozmiar: cztery shardy safetensors w BF16, działające w Transformers, vLLM lub SGLang za endpointem zgodnym z OpenAI, ze ścieżką kompilacji, która wymaga Kimina Lean Server na Lean 4.21.0.

Liczby mierzą różne rzeczy, a sedno tkwi w luce.

Głównym wynikiem Ember-1 jest odsetek zadań poprawnie ukończonych przez agenta — Terminal Bench 2.1, 89 próbek, 82,0%. Głównymi wynikami MathForm-8B są średnie wyniki Pass@8 w sześciu benchmarkach autoformalizacji: 88,06% przy sprawdzeniu składni i 72,37% przy bardziej rygorystycznym sprawdzeniu spójności. Te wielkości nie są na tej samej osi. Jedna mierzy, czy agent ukończył zadanie w terminalu; druga mierzy, czy wygenerowane sformułowanie twierdzenia daje się sparsować i czy znaczy to samo, co nieformalny problem, z którego powstało.

Rozrzut 88,06 wobec 72,37 w wynikach samego MathForm jest bardziej pouczającą liczbą. Luka między „to się kompiluje” a „to się kompiluje i mówi to, co miałem na myśli” wynosi około szesnastu punktów i to jest ten tryb awarii, który sprawia, że autoformalizacja jest trudna: stwierdzenie, które przechodzi kontrolę typów, a jednocześnie po cichu osłabia pierwotne twierdzenie, jest gorsze niż oczywisty błąd, ponieważ nic na dalszym etapie tego nie sygnalizuje. W najtrudniejszych zestawach kontrola spójności spada do 63% w przypadku FATE-H i 37% w przypadku FATE-X, podczas gdy łatwe zestawy, takie jak FormalIMATH, osiągają 95,06%, a ProverBench 94,83%. To specjalista, który uczciwie mówi, gdzie specjalista jest słaby, i jest to bardziej przydatne niż pojedyncza średnia.

Kontrast, wymiar po wymiarze

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

• Co zmieniło szkolenie — Ember-1: jak długo model rozumuje, przy niezmienionej zdolności. MathForm-8B: co model generuje, w dużej mierze rezygnując z ogólności.

• Parametry — Ember-1: nieujawnione. MathForm-8B: ~8B, gęsty, BF16.

• Kontrakt wyjściowy — Ember-1: zwykły tekst i wywołania narzędzi, o jakości na poziomie K3. MathForm-8B: sformułowanie w Lean 4 z nagłówkiem i nazwanym twierdzeniem.

• Licencja i wagi — Ember-1: nie opublikowano żadnej licencji ani wag; podgląd badawczy przez własną platformę dostawcy. MathForm-8B: Apache 2.0, zarówno wagi, jak i zbiór danych można pobrać.

• Raportowany nagłówek — Ember-1: 82,0% w Terminal Bench 2.1, zużywając o 51,9% mniej tokenów. MathForm-8B: średni wynik Pass@8 88,06% przy sprawdzaniu składni, 72,37% przy sprawdzaniu spójności.

• Niezależna weryfikacja — żadna z nich; oba pochodzą od dostawcy i nie zostały odtworzone.

Zapis licencyjny decyduje o więcej niż benchmarki

Mimo wszystkich różnic liczbowych praktyczna różnica między tymi dwoma wydaniami sprowadza się do dystrybucji. MathForm-8B to plik. OpenBMB opublikował wagi, zbiór danych FormalVerse i artykuł tego samego dnia, na licencji Apache 2.0, bez ogłoszenia i bez hostowanego API — karta modelu jest premierą. Możesz go pobrać dziś po południu i uruchomić na jednym GPU, a nikt nie może ci tego odebrać. Ember-1 to usługa. Nie ma wag, nie ma opublikowanej ceny, a okno dostępu jest opisywane jako dwutygodniowy okres serverless, którego kontynuacja zależy od popytu. Możesz je wywołać dziś, ale nie możesz mieć pewności, że wywołasz je w listopadzie.

Ta różnica określa też, do czego można użyć każdego z modeli. Komponent do formalizacji należy umieścić w potoku, który kontrolujesz, przypiętym do wersji, z toolchainem Lean na tej samej maszynie — dlatego właśnie checkpoint Apache-2.0 bez ograniczeń dostępu jest właściwym kształtem dla zadania MathForm-8B i dlatego brakujący w jego README link do kodu na GitHubie (wciąż placeholder w chwili pisania) jest bardziej irytującą luką niż jakikolwiek wynik benchmarku. Model rozliczany za rozumowanie należy umieścić za API, gdzie optymalizuje się rachunek za tokeny i gdzie dostawcy konkurują ceną i opóźnieniem. Kształt Ember-1 również pasuje do jego zadania; oznacza to tylko, że zależność jest komercyjna, a nie techniczna.

Tam, gdzie potok użyłby obu

Te dwa modele są komplementarne, a nie konkurencyjne, a sposób ich złożenia łatwo opisać: specjalista od formalizacji przekształca problem w sprawdzalne stwierdzenie, a model rozumujący pracuje nad tym stwierdzeniem lub nad otaczającą go inżynierią. Żaden z nich nie znajduje się na OrcaRouter — MathForm-8B jest dostępny wyłącznie jako self-hosted, a Ember-1 jest w własnej wersji zapoznawczej dostawcy — ale samo złożenie to wzorzec, dla którego istnieje nasz routing DSL.Łączenie kilku modeli w jedno wywołanie to sposób, w jaki pipeline zyskuje specjalistę i generalistę bez utrzymywania dwóch ścieżek integracji i dwóch kontraktów, a fuzja modeli idzie o krok dalej, pozwalając panelowi modeli odpowiadać razem gdy tryb awarii pojedynczego modelu jest kosztowny.

Konkretnie w przypadku stosu formalizacyjnego argument za kompozycją jest silniejszy niż zwykle. Widocznym trybem awarii jest instrukcja, która się kompiluje i znaczy coś nieco innego, a najtańszą obroną przed cichym błędem jest drugi model czytający ten sam problem — co jest decyzją routingową, a nie treningową.

Który jest lepszym zakupem

Jeśli potrzebujesz matematyki możliwej do sprawdzenia maszynowo, MathForm-8B jest jedynym z tych dwóch, który w ogóle ją generuje, a jego głównym kosztem jest ogólność, której i tak nie zamierzałeś użyć w tym zadaniu. Pobierz go, zaplanuj budżet na serwer Lean i zbuduj własną ewaluację — artykuł OpenBMB nie powie ci, jak radzi sobie z twoim rozkładem.

Jeśli potrzebujesz uniwersalnego modelu rozumującego przy niższym koszcie tokenów, Ember-1 jest dla ciebie, a właściwym następnym krokiem jest ruch w trybie shadow względem tego, co uruchamiasz obecnie, a nie porównanie benchmarków. Jego ryzykiem jest dostępność, a nie zdolności, i to ryzyko możesz zabezpieczyć, utrzymując warstwę routingu między swoją aplikacją a modelem.

Niewygodny wniosek dla każdego, kto liczył, że któryś z nich rozstrzygnie tę kwestię, jest taki, że żaden nie został niezależnie oceniony. MathForm-8B jest publicznie dostępny od sześciu tygodni i żadna strona trzecia nie opublikowała odtworzenia; Ember-1 jest publicznie dostępny od jednego dnia. Oba proszą, byś to ty był oceniającym, co jest normalną sytuacją przy wyborze modelu specjalistycznego w 2026 roku.

To, co jednak udowadniają, to że strategia zawężania działa w obu kierunkach. Model czołowy można uczynić tańszym bez pogarszania go, a mały model bazowy można uczynić rygorystycznym, kierując jego trening na kompilator. Interesujące pytanie nie brzmi, które z tych dwóch podejść zwycięży, lecz jak długo którekolwiek z nich pozostanie konieczne, gdy stosowane w nich techniki staną się standardową praktyką.