Une carte-titre générée indiquant « Ember-1 vs MathForm-8B », avec le sous-titre « Deux modèles construits en restreignant une base empruntée », au-dessus de deux cartes : Ember-1 — « longueur de raisonnement restreinte » et « capacité générale conservée » ; MathForm-8B — « fine-tuning de Qwen3-8B » et « produit des énoncés Lean 4 ».
Guides & Insights

Ember-1 vs MathForm-8B : deux modèles construits en restreignant une base empruntée

Auteur

Elias Hawthorne

Date de publication

Derniers modèles · 20Voir tous les modèles
Benchmarks : Artificial Analysis · mis à jour quotidiennement
Retour à tous les articles

Ember-1 et MathForm-8B partagent une stratégie qu'aucun des deux laboratoires ne présente comme telle : tous deux sont des restrictions d'un modèle entraîné par quelqu'un d'autre. Ember-1 est un dérivé spécialisé de Kimi K3 de Moonshot AI, par Fireworks Research, publié le 23 septembre 2026, réentraîné pour atteindre la précision de K3 avec environ 40 % de tokens en moins. MathForm-8B est le modèle d'autoformalisation 8B d'OpenBMB, publié discrètement le 14 août 2026 sous forme de fine-tune Apache-2.0 de Qwen3-8B d'Alibaba, qui transforme des mathématiques informelles en énoncés de théorèmes Lean 4 qu'un compilateur peut vérifier. Une restriction a supprimé la délibération superflue et préservé intacte la capacité générale. L'autre a supprimé presque toute la capacité générale et a acheté la vérifiabilité à la place. Les mettre côte à côte est la manière la plus limpide de voir ce que coûte réellement une spécialisation, car les deux modèles ont dépensé leurs budgets d'entraînement des côtés opposés de ce bilan.

Deux types de rétrécissement

L'intervention de Fireworks Research est comportementale. Ember-1 conserve l'architecture de Kimi K3 et son étendue — mathématiques, codage, suivi d'instructions, conversation, recherche, utilisation d'outils et ingénierie logicielle figurent tous dans le mélange d'entraînement — et ne change que la durée pendant laquelle le modèle délibère avant de répondre. Le résultat rapporté est que la longueur du raisonnement a chuté de 35 à 50 % sans perte de précision sur sept benchmarks et deux tests A/B en production chez des clients, une charge de travail de codage en production passant de 49,3 K à 29,9 K jetons de sortie tandis que son score se maintenait à 0,753 contre 0,751. Chaque chiffre est rapporté par le fournisseur et non reproduit.

L'intervention d'OpenBMB est contractuelle. MathForm-8B prend Qwen3-8B et oriente l'intégralité du budget d'entraînement vers une seule forme de sortie : un énoncé Lean 4 avec un en-tête d'imports et un théorème nommé. Le pipeline consiste en un affinage supervisé sur FormalVerse — un corpus d'environ 367 000 exemples Lean 4 vérifiés qu'OpenBMB a construit et publié avec le modèle — suivi d'un apprentissage par renforcement qui utilise la compilation Lean et un retour de cohérence sémantique comme signal de récompense. Le modèle ne résout pas les preuves. Il écrit l'énoncé qu'un prouveur terminera, et le cadrage de l'article lui-même décrit l'évaluation sur six benchmarks comme le but de l'exercice.

A two-column scoreboard titled "Ember-1 vs MathForm-8B — the scoreboard" comparing six dimensions. Ember-1: base model Kimi K3; narrowed how long the model reasons; output is text and tool calls with general capability kept; no published weights; headline figure 82.0% on Terminal Bench 2.1; no independent evaluation yet. MathForm-8B: base model Qwen3-8B; narrowed what the model outputs; output is a Lean 4 theorem statement with a named header; Apache 2.0 weights; headline figure 88.06% average Pass@8 under syntax check; no independent evaluation yet.

Ce que chacun a abandonné

Ember-1 a concédé très peu sur le papier, et c’est là toute l’affirmation. Sa fiche publiée montre une victoire sur Terminal Bench 2.1 à 82,0 % face aux 80,9 % de Kimi K3 Max et sur DeepSWE 1.1 à 75,2 % contre 66,4 %, ainsi que des défaites serrées sur SWE-bench Verified à 92,2 % contre 93,2 % et sur SWE-Interact à 20,0 % contre 21,3 %. Ce sont des chiffres du fournisseur sur des ensembles choisis par le fournisseur, mais la tendance est cohérente : un modèle qui n’a pas tant perdu en capacité qu’il a réorienté l’endroit où il dépense ses efforts. Les économies de tokens, toutefois, vont de 51,9 % sur Terminal Bench jusqu’à 5,9 % sur τ-2 Bench Airline, donc « environ 40 % » est une moyenne sur une dispersion très large.

MathForm-8B a renoncé à la majeure partie de ce qui fait la réputation de Qwen3-8B. Il ne tient pas de conversation générale, ne couvre pas les 119 langues et dialectes sur lesquels Qwen3-8B a été entraîné, et n’accepte ni les images ni l’audio. Son budget de génération est dimensionné pour une sortie Lean, et non pour un raisonnement mixte étendu. Ce qu’il a conservé, c’est une licence permissive et une empreinte réduite : quatre fragments safetensors en BF16, fonctionnant sous Transformers, vLLM ou SGLang derrière un point de terminaison compatible OpenAI, avec un chemin de compilation qui nécessite un Kimina Lean Server sur Lean 4.21.0.

Les chiffres mesurent des choses différentes, et l'écart est l'essentiel

Le chiffre phare d’Ember-1 est un pourcentage de tâches accomplies correctement par un agent — Terminal Bench 2.1, 89 échantillons, 82,0 %. Les chiffres phares de MathForm-8B sont des scores Pass@8 moyens sur six benchmarks d’autoformalisation : 88,06 % selon un contrôle syntaxique et 72,37 % selon un contrôle de cohérence plus strict. Ces mesures ne se situent pas sur le même axe. L’une mesure si un agent a terminé une tâche dans un terminal ; l’autre mesure si un énoncé de théorème généré est syntaxiquement valide et s’il signifie la même chose que le problème informel dont il provient.

L'écart de 88,06 contre 72,37 au sein des propres résultats de MathForm est le chiffre le plus instructif. L'écart entre « ceci compile » et « ceci compile et dit ce que je voulais dire » est d'environ seize points, et c'est le mode de défaillance qui rend l'autoformalisation difficile : un énoncé qui passe le contrôle de types tout en affaiblissant discrètement l'affirmation d'origine est pire qu'une erreur évidente, car rien en aval ne le signale. Sur les ensembles les plus difficiles, le contrôle de cohérence tombe à 63 % sur FATE-H et à 37 % sur FATE-X, tandis que des ensembles faciles comme FormalIMATH se situent à 95,06 % et ProverBench à 94,83 %. C'est un spécialiste qui fait preuve d'honnêteté sur les faiblesses d'un spécialiste, et c'est plus utile qu'une moyenne unique.

Le contraste, dimension par dimension

• Modèle de base — Ember-1 : Kimi K3. MathForm-8B : Qwen3-8B.

• Ce que l’entraînement a changé — Ember-1 : la durée pendant laquelle le modèle raisonne, à capacité constante. MathForm-8B : ce que le modèle produit, la généralité étant en grande partie abandonnée.

• Paramètres — Ember-1 : non divulgués. MathForm-8B : ~8B, dense, BF16.

• Contrat de sortie — Ember-1 : texte ordinaire et appels d’outils, avec une qualité de niveau K3. MathForm-8B : un énoncé Lean 4 avec un en-tête et un théorème nommé.

• Licence et poids — Ember-1 : aucun n’est publié ; aperçu de recherche via la plateforme du fournisseur lui-même. MathForm-8B : Apache 2.0, les poids et le jeu de données sont tous deux téléchargeables.

• Titre rapporté — Ember-1 : 82,0 % sur Terminal Bench 2.1 avec 51,9 % de tokens en moins. MathForm-8B : 88,06 % de moyenne de Pass@8 sous contrôle syntaxique, 72,37 % sous contrôle de cohérence.

• Vérification indépendante — ni l’un ni l’autre ; les deux sont déclarés par le fournisseur et non reproduits.

A screenshot of the Hugging Face model card for openbmb/MathForm-8B, showing the paper title "MathForm: Scaling Mathematical Autoformalization with Knowledge Retrieval and Verification-Guided Refinement", an 8B safetensors model in BF16 with a chat template under Apache 2.0, a five-stage pipeline diagram running Formalization Generation, Verification, Refinement, Trajectory Reconstruction and Training, and a model tree showing it fine-tuned from Qwen/Qwen3-8B-Base and trained on the openbmb/FormalVerse dataset of 367,000 examples.

La ligne de licence est plus décisive que les benchmarks.

Malgré tout l'écart numérique, la différence pratique entre ces deux versions tient à la distribution. MathForm-8B est un fichier. OpenBMB a publié les poids, le jeu de données FormalVerse et l'article le même jour, sous Apache 2.0, sans annonce ni API hébergée — la fiche du modèle fait office de lancement. Vous pouvez le télécharger cet après-midi et l'exécuter sur un seul GPU, et personne ne peut vous le retirer. Ember-1 est un service. Il n'y a pas de poids, pas de prix publié, et la fenêtre d'accès est décrite comme une période serverless de deux semaines dont la prolongation dépend de la demande. Vous pouvez l'appeler aujourd'hui, mais vous ne pouvez pas être certain de pouvoir l'appeler en novembre.

Cette différence détermine aussi à quoi chaque modèle peut servir. Un composant de formalisation a sa place dans un pipeline que vous contrôlez, épinglé à une version, avec la chaîne d’outils Lean sur la même machine — c’est pourquoi un checkpoint Apache-2.0 non restreint est la forme qui convient au travail de MathForm-8B, et pourquoi le lien de code GitHub manquant sur son README (encore un placeholder au moment de la rédaction) est une lacune plus agaçante que n’importe quel chiffre de benchmark. Un modèle de coût de raisonnement a sa place derrière une API, où la facture de tokens est ce qui est optimisé, et où les fournisseurs rivalisent sur le prix et la latence. La forme d’Ember-1 convient aussi à son travail ; cela signifie simplement que la dépendance est commerciale plutôt que technique.

Là où un pipeline utiliserait les deux

Ces deux modèles sont complémentaires plutôt que concurrents, et leur composition est facile à décrire : un spécialiste de la formalisation convertit un problème en un énoncé vérifiable, et un modèle de raisonnement travaille sur l'énoncé ou sur l'ingénierie qui l'entoure. Aucun des deux n'est sur OrcaRouter — MathForm-8B n'est disponible qu'en auto-hébergement, et Ember-1 est dans la préversion propre au fournisseur — mais la composition elle-même est un schéma pour lequel notre DSL de routage a été conçu. La composition de plusieurs modèles en un seul appel est la manière dont un pipeline obtient un spécialiste et un généraliste sans maintenir deux chemins d'intégration et deux contrats, et la fusion de modèles va un cran plus loin en permettant à un panel de modèles de répondre ensemble lorsque le mode de défaillance d'un seul modèle s'avère coûteux.

Pour une pile de formalisation en particulier, l’argument en faveur de la composition est plus fort que d’ordinaire. Le mode de défaillance visible est un énoncé qui se compile et signifie quelque chose de légèrement différent, et la défense la moins coûteuse contre une erreur silencieuse est un second modèle qui lit le même problème — ce qui relève d’une décision de routage, et non d’une décision d’entraînement.

Quel est le meilleur achat ?

Si vous avez besoin de mathématiques vérifiables par machine, MathForm-8B est le seul des deux à en produire, et son principal coût est la généralité que vous n'alliez de toute façon pas utiliser pour cette tâche. Téléchargez-le, prévoyez un budget pour le serveur Lean et réalisez votre propre évaluation — l'article d'OpenBMB ne vous dira pas comment il se comporte sur votre distribution.

Si vous avez besoin d’un raisonneur généraliste avec une facture de tokens moins élevée, Ember-1 s’adresse à vous, et la bonne prochaine étape est d’envoyer du trafic fantôme vers ce que vous exécutez aujourd’hui plutôt que de faire une comparaison de benchmarks. Son risque est la disponibilité, pas la capacité, et c’est un risque que vous pouvez couvrir en conservant la couche de routage entre votre application et le modèle.

La conclusion inconfortable pour quiconque espère que l’un de ces modèles tranche la question est qu’aucun des deux n’a été évalué de manière indépendante. MathForm-8B est public depuis six semaines et aucun tiers n’a publié de reproduction ; Ember-1 est public depuis un jour. Tous deux vous demandent d’être l’évaluateur, ce qui est la condition normale lorsqu’on choisit un modèle spécialisé en 2026.

A screenshot of OrcaRouter's model catalogue headed "Models — 203 models · 15 providers · one API, one bill", with filter panels for input modalities, context length and input price, and model cards showing per-million-token base rates for GPT-6 Luna, GPT-6 Sol, Claude Opus 5 and Grok 4.7.

Ce qu'ils prouvent, c'est que la stratégie de resserrement fonctionne dans les deux sens. Un modèle de pointe peut être rendu moins coûteux sans être moins performant, et un petit modèle de base peut être rendu rigoureux en orientant son entraînement vers un compilateur. La question intéressante n'est pas de savoir laquelle de ces deux approches l'emporte, mais combien de temps encore l'une ou l'autre reste nécessaire une fois que les techniques qu'elles contiennent deviennent la pratique courante.