Qu'est-ce que MathForm-8B ? La sortie discrète d'autoformalisation d'OpenBMB transforme les mathématiques en Lean 4

openbmb/MathForm-8B est un nouveau modèle d'autoformalisation d'OpenBMB qui traduit des énoncés mathématiques en langage naturel vers Lean 4, et il a été publié presque sans annonce : les poids, le jeu de données et l'article sont tous apparus sur Hugging Face et arXiv le même jour, le 14 août 2026, sous le titre générique « MathForm: Scaling Mathematical Autoformalization with Knowledge Retrieval and Verification-Guided Refinement ». Ce lancement discret cache un résultat inhabituel — un modèle de 8 milliards de paramètres qui rapporte des scores moyens Pass@8 de 88,06 % lors d'une vérification syntaxique et de 72,37 % lors d'une vérification de cohérence plus stricte sur six benchmarks, et dont l'article affirme qu'il surpasse plusieurs autoformaliseurs spécialisés de 32 milliards de paramètres. Ce texte fait le point sur ce que nous savons à ce jour : tout ce qui suit, marqué « from the repo », provient directement de la fiche du modèle, de la fiche du jeu de données et de l'article, et tout ce qui n'est pas encore confirmé de manière indépendante est signalé comme tel.

Points clés

• MathForm-8B est un modèle d'autoformalisation de 8B, sous licence Apache-2.0 : il lit un problème mathématique informel et rédige un énoncé de théorème Lean 4 avec un en-tête nommé, prêt pour une preuve ultérieure.

• Il est affiné à partir de Qwen3-8B sur FormalVerse, un ensemble de données Lean 4 vérifié d'environ 367 000 exemples qu'OpenBMB a construit avec récupération de connaissances et raffinement vérifié par compilateur, puis entraîné par apprentissage par renforcement en utilisant la compilation Lean et une rétroaction de cohérence sémantique.

• Chiffres rapportés (rapportés par le fournisseur, non reproduits) : 88,06 % de moyenne Pass@8 en vérification de syntaxe, 72,37 % en vérification de cohérence, dépassant les autoformaliseurs spécialisés de 7B à 32B dans le tableau même de l'article.

• Ce n'est pas annoncé, pas sur une API payante majeure au lancement, et pas encore évalué indépendamment — trois lacunes qui comptent pour l'adoption en production.

• Le service d'inférence est auto-hébergé : Transformers, vLLM ou SGLang, exposant tous un endpoint compatible OpenAI.

Ce que la version contient réellement

Trois artefacts ont été mis en ligne à quelques minutes d'intervalle le 2026-08-14, ce qui ressemble à une sortie coordonnée mais non annoncée :

• Le dépôt de modèle openbmb/MathForm-8B — un LM causal de 8B en BF16 avec un template de chat, quatre fragments safetensors, licence Apache 2.0.

• Le dépôt de données, openbmb/FormalVerse — un jeu de données d'autoformalisation Lean 4 d'environ 367 000 exemples vérifiés, également sous licence Apache 2.0.

• L'article, arXiv 2608.14221 — 25 pages décrivant le pipeline de construction des données, la recette d'entraînement et l'évaluation sur six benchmarks.

Le lien vers le code GitHub dans le README est encore un espace réservé au moment de la rédaction, donc le pipeline d'évaluation et les scripts Pass@k sont promis mais pas encore publics. Le README précise toutefois que les vérifications de compilation nécessitent un serveur Kimina Lean en cours d'exécution et que les expériences utilisent Lean 4.21.0.

La page du dépôt ci-dessus est actuellement toute la surface publique de la version : une model card, quatre shards safetensors, un chat template et un README qui fait également office de seule documentation. Aucun billet de blog d'annonce n'existe au moment de la rédaction.

Ce que fait MathForm-8B — et pourquoi c'est une tâche étroite.

L'autoformalisation est l'étape préalable à la démonstration de théorèmes : à partir d'un problème mathématique en anglais simple (« Montrer que pour tout nombre réel x, x² est non négatif »), le modèle doit produire un énoncé formellement correct en Lean 4 — imports, types et en-tête de théorème — qu'un humain ou un prouveur peut ensuite attaquer. C'est une compétence véritablement différente de celle qui consiste à faire les mathématiques, car le modèle doit faire correspondre les concepts du langage naturel à la hiérarchie exacte des définitions et des types de Mathlib. Un énoncé qui passe la vérification de types mais affaiblit silencieusement l'énoncé original (« (2^5) ∣ (13^4 − 11^4) » au lieu de l'affirmation complète de divisibilité) est le mode d'échec classique, et c'est pourquoi l'article distingue la vérification de syntaxe (est-ce que cela compile ?) de la vérification de cohérence (est-ce que c'est sémantiquement le même énoncé ?).

La fiche du modèle montre le schéma d'utilisation prévu : vous lui fournissez un prompt avec le problème informel et un nom de théorème souhaité, et il renvoie un énoncé Lean 4 avec code>theorem my_favorite_theorem : ... := by sorry/code> — le code>sorry/code> laisse l'obligation de preuve ouverte. Cette division du travail compte : MathForm-8B est un formaliseur, pas un prouveur. Les équipes qui développent des outils Lean l'utilisent pour convertir des banques de problèmes en une forme vérifiable par machine.

Comment il a été entraîné

La recette décrite dans l'article comporte deux étapes. Tout d'abord, OpenBMB a construit FormalVerse avec un pipeline qui (1) {{1}}extrait les définitions pertinentes et les formalisations existantes de Mathlib avant la génération{{/1}}, (2) {{2}}génère des énoncés candidats{{/2}}, (3) {{3}}les affine à l'aide des diagnostics du compilateur Lean et de retours sur la cohérence sémantique{{/3}}, et (4) {{4}}ne conserve que les échantillons qui réussissent les deux vérifications{{/4}}. Ce corpus validé est ensuite utilisé pour un fine-tuning supervisé, {{5}}suivi d'un apprentissage par renforcement{{/5}} avec des signaux de récompense provenant de la compilation Lean et de la cohérence sémantique.

La fiche de jeu de données donne un aperçu concret des données : chaque entrée associe un énoncé informel à un énoncé formel vérifié, étiqueté par source (par ex., AceReason-Math) et par libellé de sujet (théorie des nombres, etc.). Comme chaque exemple a réussi un véritable contrôle du compilateur avant d'entrer dans l'entraînement, le modèle apprend à partir d'énoncés dont la qualité est éprouvée plutôt qu'à partir de la sortie brute d'un modèle.

Le tableau comparatif, honnêtement étiqueté.

Tous les chiffres de cette section sont rapportés par le fournisseur dans l'article (arXiv 2608.14221) et n'ont pas été reproduits de manière indépendante. Pass@8 signifie que le modèle dispose de huit tentatives par problème et que l'essai est compté si l'une d'elles réussit ; c'est une métrique plus indulgente que pass@1 et doit être lue comme « à quelle fréquence le modèle peut produire une affirmation correcte avec un budget donné ».

• Moyennes de MathForm-8B — Vérification de syntaxe 88.06 %, Vérification de cohérence 72.37 %.

Par benchmark, SC puis CC : FormalIMATH 100.00 / 95.06, ProverBench 100.00 / 94.83, CombiBench 93.00 / 47.00, FATE-M 99.33 / 97.33, FATE-H 82.00 / 63.00, FATE-X 54.00 / 37.00.

• Les ensembles difficiles sont les plus honnêtes : FATE-H CC 63 % et FATE-X CC 37 % montrent le plafond du modèle sur les sous-ensembles les plus difficiles, contre plus de 95 % de CC sur les plus faciles FormalIMATH et ProverBench.

• Les meilleurs modèles de référence 8B que l'article mentionne — ReForm-8B 81.76 / 66.21, Goedel-Formalizer-V2-8B 78.24 / 60.08 — et les meilleurs modèles de référence 32B — ReForm-32B 81.61 / 68.41, Goedel-Formalizer-V2-32B 78.28 / 63.74, StepFun-Formalizer-32B 63.65 / 44.47 — sont tous inférieurs à ceux de MathForm-8B, soit 88.06 / 72.37.

Le checkpoint SFT uniquement (avant l'étape de RL) atteint 84,38 / 66,53, donc le passage d'apprentissage par renforcement vaut environ +3,7 SC et +5,8 CC en moyenne, avec les plus gros gains sur les jeux de données difficiles.

Les affirmations les plus fortes à considérer avec scepticisme : les scores SC de 100,00 sur FormalIMATH et ProverBench (un taux de compilation de 100 % sur les ensembles faciles est un signal d’alarme indiquant que ces ensembles ont convergé), et la comparaison avec des modèles 32B qui n’ont pas été relancés dans des conditions identiques. Les chiffres du Consistency Check sur FATE-H et FATE-X sont les plus susceptibles de résister à des tests indépendants.

Qu'est-ce qui n'est pas confirmé ?

• Aucune évaluation indépendante n'existe. Aucun tiers n'a exécuté MathForm-8B dans un banc d'essai public à ce jour, et le code d'évaluation n'a pas été publié.

• Aucune annonce de mise en service. OpenBMB n'a publié ni blog de lancement, ni page de tarification, ni endpoint API. La formulation « lancé en silence » est littérale.

Les poids de récompense RL, le budget d'entraînement et le matériel ne figurent pas dans la carte du modèle ; ils ne se trouvent que dans l'article.

• Le fait que le modèle 8B se généralise à Lean 4.21.1+ ou aux importations non-Mathlib n'est pas testé.

Comment l'exécuter

L'auto-hébergement est la seule voie aujourd'hui. Le README documente trois chemins, tous avec un point de terminaison de chat compatible OpenAI à code>localhost:8000/v1/chat/completions/code>:

• Transformers — code>AutoModelForCausalLM.from_pretrained("openbmb/MathForm-8B", torch_dtype=torch.bfloat16)/code>, puis générez avec le modèle de conversation.

• vLLM — code>vllm serve openbmb/MathForm-8B --served-model-name MathForm-8B --dtype bfloat16 --max-model-len 16384/code>.

• SGLang — code>python -m sglang.launch_server --model-path openbmb/MathForm-8B --served-model-name MathForm-8B --dtype bfloat16 --context-length 16384/code>.

Le README recommande une température de 0,6, un top_p de 0,95 et jusqu'à 16384 nouveaux jetons — les énoncés formels sont longs, donc la généreuse fenêtre de génération constitue la véritable exigence système à prévoir.

Pourquoi la partie « 8B bat 32B » compte

Si les chiffres tiennent, MathForm-8B est l'argument le plus fort à ce jour que le goulot d'étranglement de l'autoformalisation est la qualité des données et la vérification, et non le nombre brut de paramètres. Le tableau de l'article lui-même montre des modèles spécialisés de 32B (ReForm-32B, Goedel-Formalizer-V2-32B, StepFun-Formalizer-32B) se situant en dessous d'un modèle de 8B entraîné sur un corpus vérifié par compilateur. Pour les équipes qui utilisent actuellement un formaliseur de 32B, cela représente un changement de coût significatif — un modèle de 8B en BF16 tient dans un seul GPU, ce que la plupart des modèles de 32B ne peuvent pas faire, et il sert plus rapidement par jeton.

Cela établit également le choix honnête que le reste du paysage des modèles ne cesse de produire : un spécialiste étroit qui accomplit très bien une seule tâche vérifiée, contre un modèle général capable de tenter de nombreuses tâches sans garantie de vérification. Pour la formalisation en particulier, le spécialiste est celui dont la sortie est vérifiée par un compilateur — ce qui est précisément la propriété qui rend confortable de placer devant lui un routeur à basculement automatique. Une couche de routage comme celle qu'OrcaRouter exploite sur plus de 200 modèles, avec répercussion des prix catalogue des fournisseurs, vous permet de diriger un chemin de test vers un modèle open-weights vieux de quelques jours comme celui-ci et de rebasculer vers un modèle éprouvé dès qu'il cale — vous pouvez adopter une sortie discrète sans engager votre chemin de production, et aucune marge n'est appliquée sur le prix du token si un fournisseur le référence plus tard.

Que regarder ensuite

Les trois éléments qui feraient passer ce projet de « dépôt intéressant » à « outil de confiance » : l'apparition effective du code d'évaluation GitHub ; un premier passage indépendant sur FATE-H et FATE-X sous pass@1 au lieu de pass@8 ; et toute annonce d'OpenBMB ajoutant une route hébergée ou une version 2 de l'article avec des chiffres d'ablation. Tant qu'au moins un de ces éléments n'est pas en place, considérez les scores principaux comme indicatifs — l'architecture et l'idée des données d'entraînement constituent l'information durable, pas le pourcentage exact.