什么是 MathForm-8B？OpenBMB 的低调自动形式化发布将数学转化为 Lean 4

openbmb/MathForm-8B 是 OpenBMB 推出的一个新自动形式化模型，可将自然语言的数学陈述翻译成 Lean 4 代码，而它的发布几乎没有任何预告：权重、数据集和论文于同一天（2026-08-14）一并出现在 Hugging Face 和 arXiv 上，总标题为“MathForm: Scaling Mathematical Autoformalization with Knowledge Retrieval and Verification-Guided Refinement”。这次低调发布掩盖了一个不同寻常的结果——这个 8B 参数模型在六项基准测试中，语法检查下的平均 Pass@8 得分为 88.06%，在更严格的一致性检查下为 72.37%，论文声称其击败了多个专门的 32B 自动形式化模型。这是一篇“目前已知信息”性质的报道：下文所有标注为“来自仓库”的内容都直接取自模型卡、数据集卡和论文，任何尚未得到独立证实的内容都会相应注明。

关键要点

• MathForm-8B 是一个 8B 参数、Apache-2.0 许可的自动形式化模型：它读取非正式的数学问题，并写出带命名标题的 Lean 4 定理陈述，为后续证明做好准备。

• 它基于Qwen3-8B在FormalVerse上微调而来。FormalVerse是OpenBMB构建的约367,000个示例的已验证Lean 4数据集，通过知识检索和编译器校验进行精炼；随后使用Lean编译和语义一致性反馈的强化学习进行训练。

• 报告的数字（供应商报告，未复现）：语法检查下平均 Pass@8 为 88.06%，一致性检查下为 72.37%，超过了论文自身表格中 7B 至 32B 的专用自动形式化器。

• 它尚未公开，发布时未接入主流付费API，也尚未经过独立基准测试——这三个差距对生产环境采用至关重要。

• 服务为自托管：Transformers、vLLM 或 SGLang，均暴露与 OpenAI 兼容的端点。

该版本实际包含的内容

三个工件在2026-08-14的数分钟之内相继上线，这正是协调但未预告的发布该有的样子：

• 模型仓库 openbmb/MathForm-8B——一个采用BF16格式、带有聊天模板的8B因果语言模型，包含四个safetensors分片，采用Apache 2.0许可证。

• 数据集仓库 openbmb/FormalVerse — 一个包含约 367,000 个已验证示例的 Lean 4 自动形式化数据集，同样采用 Apache 2.0 许可。

• 论文 arXiv 2608.14221 — 25页，描述了数据构建流程、训练方案以及六个基准的评估。

README 中的 GitHub 代码链接在撰写本文时仍然是占位符，因此评估流水线和 Pass@k 脚本虽有承诺但尚未公开。README 确实说明编译检查需要运行中的 Kimina Lean Server，并且实验使用 Lean 4.21.0。

上面的仓库页面目前就是这次发布的全部公开内容：一个模型卡片、四个 safetensors 分片、一个聊天模板，以及一份兼作唯一文档的 README。撰写本文时，还没有任何公告博客文章。

MathForm-8B 能做什么——以及为什么它是一项窄范围的工作

自动形式化是定理证明之前的一步：给定一个用普通英语表述的数学问题（"证明对每个实数 x，x² 是非负的"），模型必须生成一个在 Lean 4 中形式正确的陈述——包括导入、类型和定理头——供人类或证明器随后进行证明。这是一项与数学本身截然不同的技能，因为模型必须将自然语言概念映射到 Mathlib 精确的定义和类型层次结构上。一个能通过类型检查却暗中削弱了原命题的陈述（例如用 "(2^5) ∣ (13^4 − 11^4)" 替代完整的整除性命题）是典型的失败模式，这正是论文区分语法检查（能否编译）与一致性检查（语义上是否为同一陈述）的原因。

模型卡展示了预期的使用方式：你向它提供一个包含非正式问题和所需定理名称的提示，它会返回一个 Lean 4 语句，其中带有 code>theorem my_favorite_theorem : ... := by sorry/code> —— 其中的 code>sorry/code> 使证明义务保持开放。这种分工很重要：MathForm-8B 是一个形式化器，而不是证明器。构建 Lean 工具的团队使用它将问题库转换为机器可检查的形式。

它是如何训练的

该论文的方法分为两个阶段。首先，OpenBMB 构建了 FormalVerse，其流水线为：（1）在生成之前从 Mathlib 中检索相关定义和现有形式化内容；（2）生成候选语句；（3）利用 Lean 编译器诊断信息和语义一致性反馈对其进行完善；（4）仅保留通过这两项检查的样本。随后，这个经过验证的语料库被用于监督微调，并配合来自 Lean 编译和语义一致性的奖励信号进行强化学习。

数据集卡能让人具体感受到数据的风格：每条记录将一个非正式陈述与一个经过验证的正式陈述配对，并标注来源（例如，AceReason-Math）和主题标签（如数论等）。由于每条示例在进入训练前都通过了真实的编译器检查，模型学习到的是已知正确的陈述，而非模型自身的原始输出。

如实标注的基准表

本节中的所有数字均由供应商根据论文（arXiv 2608.14221）报告，未经独立复现。Pass@8 表示模型每个问题有八次尝试机会，只要其中任意一次通过，该次运行即视为成功；这比 pass@1 更宽松，应理解为“在给定预算下，模型能够生成正确表述的频率”。

• MathForm-8B 平均成绩 — 语法检查 88.06%，一致性检查 72.37%。

• 按基准测试，SC 后接 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.

• 困难的集合才是诚实的：FATE-H CC 63% 和 FATE-X CC 37% 显示了模型在最难子集上的上限，而在较容易的 FormalIMATH 和 ProverBench 上 CC 可达 95% 以上。

• 论文列出的最佳 8B 基线模型——ReForm-8B 81.76 / 66.21、Goedel-Formalizer-V2-8B 78.24 / 60.08——以及最佳 32B 基线模型——ReForm-32B 81.61 / 68.41、Goedel-Formalizer-V2-32B 78.28 / 63.74、StepFun-Formalizer-32B 63.65 / 44.47——都落后于 MathForm-8B 的 88.06 / 72.37。

• 仅SFT检查点（在RL阶段之前）的得分为84.38 / 66.53，因此强化学习过程平均约带来+3.7 SC和+5.8 CC的提升，其中在困难集合上的提升最大。

最值得怀疑的论断是：FormalIMATH 和 ProverBench 上 100.00 的 SC 分数（在简单集上 100% 编译通过是一个危险信号，表明这些集已经收敛），以及与未在相同条件下重新运行的 32B 模型的比较。FATE-H 和 FATE-X 上的一致性检查数字最有可能经得起独立测试的检验。

什么尚未确认

• 不存在独立的评估。截至撰写本文时，还没有第三方通过公开的测试工具运行过 MathForm-8B，评估代码也尚未发布。

• 没有发布服务公告。OpenBMB 尚未发布上线博客、定价页面或 API 端点。“悄然上线”的说法是字面意义上的。

• 强化学习奖励权重、训练预算和硬件不在模型卡中；它们只存在于论文中。

• 8B模型是否能够泛化到Lean 4.21.1+或非Mathlib导入尚未经过测试。

如何运行它

自托管是目前唯一的途径。README 记录了三种路径，均提供 OpenAI 兼容的聊天端点，位于 code>localhost:8000/v1/chat/completions/code>：

• Transformers — code>AutoModelForCausalLM.from_pretrained("openbmb/MathForm-8B", torch_dtype=torch.bfloat16)/code>，然后使用聊天模板进行生成。

• 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>.

README 建议使用温度 0.6、top_p 0.95，以及最多 16384 个新 token——形式化语句往往很长，因此宽裕的生成窗口才是实际需要规划的系统需求。

为什么“8B胜过32B”这部分很重要

如果这些数字站得住脚，MathForm-8B就是迄今为止最有力的证据，表明自动形式化的瓶颈在于数据质量和验证，而非原始参数数量。论文自带的表格显示，32B专用模型（ReForm-32B、Goedel-Formalizer-V2-32B、StepFun-Formalizer-32B）都排在基于编译器校验语料训练的8B模型之下。对于目前运行32B形式化模型的团队来说，这是一次实质性的成本变化——BF16精度下的8B模型可以放进单个GPU，而大多数32B模型做不到这一点，同时它的每token推理速度也更快。

它还提出了模型生态中其余部分持续呈现的那个诚实选择：一个能出色完成单一已验证任务的窄域专家，与一个能尝试众多任务却无验证保障的通用模型。具体到形式化而言，专家型模型正是那个有编译器检查其输出的模型——这恰恰是让带自动故障转移的路由器能安心置于其前的特性。像 OrcaRouter 这样的路由层在 200+ 个模型上运行，按提供商列表价透传，让你可以把测试路径指向一个发布仅数日的开放权重模型，并在它一卡顿时回退到久经考验的模型——你可以采用一次静默发布，而不必把生产路径押在它上面；即便提供商日后上架该模型，token 价格也不会有任何加成。

接下来看什么

能将这个项目从“有趣的仓库”转变为“可信赖工具”的三件事：GitHub 评估代码真正出现；首次以 pass@1（而非 pass@8）对 FATE-H 和 FATE-X 进行独立评估；以及 OpenBMB 发布任何增加托管路线或带消融数据的论文 v2 的公告。在上述至少一项落地之前，请将头条分数视为方向性参考——架构和训练数据思路才是持久新闻，而非确切的百分比。