Ember-1 vs MathForm-8B：两个通过收窄借来的基座构建的模型

Ember-1 和 MathForm-8B 共享一种两个实验室都没有公开宣传为同一种策略的策略：两者都是对别人训练过的模型所做的窄化。Ember-1 是 Fireworks Research 对 Moonshot AI 的 Kimi K3 的专门衍生模型，于 2026 年 9 月 23 日发布，经过重新训练，在 token 数量大约减少 40% 的情况下达到 K3 的准确率。MathForm-8B 是 OpenBMB 的 8B 自动形式化模型，于 2026 年 8 月 14 日悄然发布，作为 Alibaba 的 Qwen3-8B 的 Apache-2.0 微调版本，可将非正式数学转化为编译器可检查的 Lean 4 定理陈述。一种窄化消除了浪费的推敲，并保持通用能力完好。另一种则移除了几乎所有通用能力，转而换取可验证性。把两者放在一起，是看清专门化实际代价的最清晰方式，因为这两个模型把训练预算花在了这份账本的两端。

两种收窄

Fireworks Research 的干预是行为层面的。Ember-1 保留了 Kimi K3 的架构及其广度——数学、编程、指令遵循、对话、搜索、工具使用和软件工程都出现在训练数据组合中——只改变了模型在作答前思考的时长。据报告，在七项基准测试和两次客户生产环境 A/B 测试中，推理长度下降了 35–50%，且准确率没有损失；其中一个生产环境编程工作负载的输出 token 数从 49.3K 降至 29.9K，其得分则保持在 0.753，对比 0.751。所有数字均由厂商报告，且未被复现。

OpenBMB 的介入是契约性的。MathForm-8B 以 Qwen3-8B 为基础，把全部训练预算集中在一个输出形态上：一个带有 imports 头和一个具名定理的 Lean 4 陈述。其流程是在 FormalVerse 上进行监督微调——这是一个约 367,000 条已验证 Lean 4 示例的语料库，由 OpenBMB 构建并与该模型一同发布——随后进行强化学习，使用 Lean 编译和语义一致性反馈作为奖励信号。该模型并不求解证明。它写出证明器将完成的陈述，而论文自身的表述将六基准评估描述为这项工作的目的所在。

各自放弃了什么

Ember-1 在纸面上几乎没有什么让步，而这正是其全部主张。其公布的数据表显示：它在 Terminal Bench 2.1 上以 82.0% 对 Kimi K3 Max 的 80.9% 取胜，在 DeepSWE 1.1 上以 75.2% 对 66.4% 取胜；而在 SWE-bench Verified 上以 92.2% 对 93.2%、在 SWE-Interact 上以 20.0% 对 21.3% 小幅落后。这些是厂商在自选基准集上给出的数字，但整体形态是一致的：这个模型与其说丧失了能力，不如说重新分配了用力的方向。不过，token 节省幅度从 Terminal Bench 上的 51.9% 一路降至 τ-2 Bench Airline 上的 5.9%，所以“约 40%”是一个覆盖极大跨度区间的平均值。

MathForm-8B 舍弃了 Qwen3-8B 为人熟知的大部分能力。它不能进行通用对话，不覆盖 Qwen3-8B 训练时所涉及的 119 种语言和方言，也不接受图像或音频输入。它的生成预算按 Lean 输出的规模设定，而非为长篇混合推理而设。它保留下来的，是宽松的许可证和轻量的体积：BF16 格式的四个 safetensors 分片，可在 Transformers、vLLM 或 SGLang 下运行，并置于兼容 OpenAI 的端点之后，其编译路径要求在 Lean 4.21.0 上运行 Kimina Lean Server。

这些数字衡量的是不同的东西，而差距才是关键所在

Ember-1 的主要数据是由智能体正确完成的任务所占百分比——Terminal Bench 2.1，89 个样本，82.0%。MathForm-8B 的主要数据是六个自动形式化基准测试上的平均 Pass@8 得分：语法检查下为 88.06%，更严格的一致性检查下为 72.37%。这两者不在同一坐标轴上。一个衡量的是智能体是否在终端中完成了一项任务；另一个衡量的是生成的定理陈述是否能够解析，以及它是否与其来源的非形式化问题含义相同。

MathForm 自身结果中 88.06 对 72.37 的落差，是更具启发性的数字。“能编译”与“能编译并表达出我的本意”之间的差距约为十六个百分点，而这正是让自动形式化变得困难的失效模式：一个通过了类型检查、却悄悄弱化了原始命题的陈述，比一个显而易见的错误更糟，因为下游没有任何环节会把它标记出来。在最难的集合上，一致性检查在 FATE-H 上降至 63%，在 FATE-X 上降至 37%，而 FormalIMATH 这类简单集合则保持在 95.06%，ProverBench 为 94.83%。这是一个专才坦诚面对自身弱项所在，比单一的平均值更有用。

逐维度对比

• 基础模型 — Ember-1：Kimi K3。MathForm-8B：Qwen3-8B。

• 训练改变了什么——Ember-1：在能力保持不变的情况下，模型推理多久。MathForm-8B：在基本放弃泛化性的情况下，模型输出什么。

• 参数 — Ember-1：未披露。MathForm-8B：约8B，稠密，BF16。

• 输出契约 — Ember-1：普通文本和工具调用，达到 K3 级质量。MathForm-8B：一个带有标头和命名定理的 Lean 4 陈述。

• 许可证与权重 — Ember-1：未公开任何内容；通过供应商自家平台提供研究预览版。MathForm-8B：Apache 2.0，权重与数据集均可下载。

• 报告头条 — Ember-1：82.0% Terminal Bench 2.1，token 用量减少 51.9%。MathForm-8B：语法检查下平均 Pass@8 为 88.06%，一致性检查下为 72.37%。

• 独立验证——两者皆无；均为供应商自报且未经复现。

许可证条款比基准测试更能决定一切

尽管存在种种数值差异，这两个版本的实际区别在于分发方式。MathForm-8B 是一个文件。OpenBMB 在同一天根据 Apache 2.0 许可发布了权重、FormalVerse 数据集和论文，没有公告，也没有托管 API——模型卡就是发布本身。你今天下午就能下载它，并在单块 GPU 上运行，没人能把它收回。Ember-1 是一项服务。没有权重，没有公布价格，访问窗口被描述为为期两周的无服务器期，是否延续取决于需求。你今天可以调用它，却无法确定十一月是否还能调用。

这种差异也决定了每个模型可以用于什么。形式化组件应放在你控制的流水线中，固定到某个版本，并将 Lean 工具链部署在同一台机器上——这正是为什么无门控的 Apache-2.0 检查点适合 MathForm-8B 的任务，也是为什么其 README 上缺失的 GitHub 代码链接（在撰写本文时仍为占位符）比任何基准测试数字都更令人恼火。推理成本模型则应置于 API 背后，在那里，token 账单才是被优化的对象，供应商也在价格和延迟上竞争。Ember-1 的形态同样契合其任务；只不过这意味着依赖是商业性的，而非技术性的。

在流水线会同时使用两者的地方

这两个模型是互补而非竞争的，而且组合方式很容易描述：形式化专家将问题转换为可检验的陈述，推理模型则针对该陈述或周边工程展开工作。二者都不在 OrcaRouter 上——MathForm-8B 仅限自托管，Ember-1 则在厂商自己的预览环境中——但这种组合本身就是我们的路由 DSL 为之存在的模式。将多个模型组合成一次调用是流水线同时获得专家和通才的方式，而无需维护两条集成路径和两份契约，而模型融合更进一步，让一组模型共同作答，当单个模型的失败模式代价高昂时。

对于形式化技术栈而言，组合的理由比通常更充分。显见的失败模式是：一条语句能编译通过，但含义略有不同；而防范静默错误最廉价的手段，是让第二个模型来读同一个问题——这是一个路由决策，而不是训练决策。

哪个更值得买

如果你需要机器可检验的数学，MathForm-8B 是两者中唯一能产出这种结果的，而它的主要代价是你本来就不会在这个任务中用到的通用性。下载它，为 Lean 服务器预留预算，并构建你自己的评估——OpenBMB 的论文不会告诉你它在你的数据分布上表现如何。

如果你需要一个 token 成本更低的通用推理模型，Ember-1 正是为你而设，而正确的下一步是对照你当前运行的方案做影子流量测试，而不是进行基准对比。它的风险在于可用性，而非能力，而你可以通过在应用与模型之间保留路由层来对冲这一风险。

对于任何希望其中某一个能一锤定音的人来说，令人不安的结论是：两者都没有经过独立评估。MathForm-8B 已公开六周，却没有任何第三方发布复现结果；Ember-1 才公开一天。两者都要求你自己当评估者，而这正是 2026 年挑选专用模型的常态。

它们确实证明的一点是，收窄策略在两个方向上都能奏效。前沿模型可以在不变得更差的情况下变得更便宜，而小型基础模型可以通过让其训练面向编译器而变得严谨。有趣的问题不在于这两种方法中哪一种会胜出，而在于一旦其中的技术成为标准做法，这两种方法各自还能在多长时间内保持必要。