AesCode-8B 对比 MathForm-8B：二者均为 8B 微调模型，其输出可由机器检查

AesCode-8B和MathForm-8B在八周内相继发布，二者都源自代码仓库而非新闻稿，而这种巧合比乍看之下更有意思。两者都从 Qwen3 系列检查点出发。两者都把全部训练预算花在一种狭窄的输出形态上。而且两者都是围绕一个检查器构建的：MathForm-8B 依据 Lean 4 编译器的判定进行训练，而 AesCode-8B 的评分方式是在沙箱浏览器中渲染每个候选页面，并回读 DOM、计算样式和截图。二者都不是聊天机器人，也都不试图成为聊天机器人。它们的区别在于机器能验证什么、不能验证什么——而就两者中较新的那个而言，区别还在于当一半分数来自一个无人指名的评判者时会发生什么。

发布记录并不对称。MathForm-8B 来自 OpenBMB，其模型卡上标注的发布日期为 2026-08-14；它构建于 Qwen3-8B 之上，并在 FormalVerse 上训练——这是一个约含 367,000 条经核验的 Lean 4 样本的语料库，训练流程为先进行监督微调，随后进行强化学习，其奖励信号来自 Lean 编译与语义一致性检查。AesCode-8B 的文件中任何地方都没有标注发布日期。微软于 2026-09-29 创建了该 Hugging Face 仓库，于 2026-10-07 03:35 UTC 以“Release AesCode-8B”为提交信息提交了权重，并于 2026-10-08 在 GitHub 上发布了训练代码。这两件事都没有伴随任何公告，模型卡的引用信息写着“Under review, 2027”，而截至本文撰写时，该仓库显示有两次下载量。它微调自 Qwen3-VL-8B-Instruct，这一点值得特别指出，正因为它与 MathForm-8B 并非同一个祖先。

血统解释了大部分的分歧

Qwen3-8B 和 Qwen3-VL-8B-Instruct 同属一代、共享家族名，但任务不同。Qwen3-8B 是纯文本通用模型：总参数量约 82 亿，其中约 70 亿为非嵌入参数，采用分组查询注意力，原生上下文为 32K token，可通过 YaRN 扩展至 131K，并接受了 119 种语言和方言的训练。Qwen3-VL-8B-Instruct 是视觉语言同门模型，也是 AesCode-8B 的起点检查点——公开的 AesCode 配置完全是一份直接照搬 Qwen3-VL 的配方：36 个隐藏层、隐藏维度 4,096、32 个注意力头（含 8 个键值头）以及 151,936 token 的词表。

那个分叉在两位专家模型训练之前就决定了它们的输入侧。MathForm-8B 接收文本，并以形式化语法输出文本。AesCode-8B 接收文本以及可选的参考图像，并输出结果。

• Base——MathForm-8B：Qwen3-8B，纯文本。AesCode-8B：Qwen3-VL-8B-Instruct，支持图像与文本输入。

• 参数量 — MathForm-8B：约 8.2B。AesCode-8B：bf16 下约 8.8B，分为四个分片，Hugging Face 将其取整为 9B。

• 训练数据 — MathForm-8B：FormalVerse，约 36.7 万个经过验证的 Lean 4 示例。AesCode-8B：3,000 条冷启动示范，随后在 7,408 条提示上进行 GDPO 强化学习，共 400 步。

• 输出由什么检查——MathForm-8B：一个 Lean 4 编译器，外加针对原始问题的语义一致性检查。AesCode-8B：沙盒化的 Playwright 渲染，带有六个确定性验证器和一个由模型评分的评分标准。

• 许可证 — 二者均为 Apache 2.0，均无门槛限制，均继承自 Qwen3 系列主干。

• 可在任何地方托管——据我们所知，两者都不是。

“verifiable”的两种不同含义

这是一个值得慢慢辨析的区别，因为“机器可检查”被用于两者，而它并不意味着同一件事。

MathForm-8B 的检查器是一个证明助手。Lean 4 要么接受一个陈述，要么不接受，而裁决并非取决于意见、评分标准或评审的品味。训练循环指向那个信号：在 FormalVerse 上的 SFT 阶段教导从非正式问题到带有 imports 头和命名定理的形式化定理陈述的映射，而 RL 阶段则通过编译加上一致性检查来精炼它，该检查询问形式化是否仍然表达了原始问题的含义。编译是非此即彼的，并且任何拥有相同 Lean 版本的人都可以复现它。一致性检查是较软的那一半，也正是报告数字变得薄弱的那一半——这恰恰是已发表结果所显示的。

AesCode-8B 的检查器是一个渲染器。候选输出会在一个沙箱化的 Playwright 浏览器中渲染，外部请求被屏蔽，随后测试框架会回读 DOM、计算样式、边界框、控制台状态和一张截图。六个确定性通道对可解析的内容评分——执行、精确文本、边界行为、表格与图表数据、语义布局、空白——第七个通道「视觉图评分表」（Visual Graph Rubric）则通过绑定图形的「是/否」问题来评估几何与位置。表格必须是真正的 HTML 表格，图表必须是 ECharts 规范，这一约束实实在在地发挥着作用：它把输出逼成验证器可以解析的形态。确定性那一半是真正可复现的。视觉那一半由一个视觉语言模型评判，而文档并未指明其身份，这意味着实验室之外的任何人都无法复现它。

所以，诚实的比较并不是“一个经过验证，一个没有”。而是：MathForm-8B 的主要信号是编译器，次要信号是一致性检查；而 AesCode-8B 的主要信号是一组确定性的 DOM 断言，次要信号是模型的意见——二者被打包在同一个总分里。

每一个都报告了什么，以及这有什么价值

MathForm-8B 在六项基准上报告，语法检查下的平均 Pass@8 为 88.06%，一致性检查下为 72.37%。各基准之间的差异才是有趣的部分：FormalIMATH 上的一致性为 95.06%，ProverBench 上为 94.83%，而 FATE-H 上为 63%，FATE-X 上为 37%。后两者是困难且贴近现实的陈述，而从九十几分中段跌到三十几分中段，才是这项能力真实的样貌。所有这些数字均为厂商报告且未经复现，而且基准组合也偏向更容易的集合。

AesCode-8B 在微软 300 样本信息图评分标准上报告总体得分为 82.94——文本 94.06、边界 88.36、图表 87.79、规则 90.07、内容 86.41、布局 87.80、风格 53.21、视觉 75.80——每个提示生成三次且不做筛选。微软还报告称，在同一评分标准上，它击败了参考条件化的 GPT-5.5（81.28）和 Claude Opus 4.8（80.39）；在 300 个样本中，有 4.3% 反复出现严重的画布溢出故障；且 32B 配套模型与其自身骨干模型之间存在 22.4 个视觉分差。每一个数字都出自厂商，基于厂商的任务，对照厂商自行设计的评分维度打分。

这两组数字完全无法相互比较。它们没有共同的任务、没有共同的指标，也没有共同的评判者。把 88.06% 放在 82.94 旁边，就等于拿 Lean 形式化通过率去和信息图总体得分作比较，而这两个模型都从未在对方所做的事情上接受过评估。

有一种不对称值得点明，因为它对较新的模型不利。MathForm-8B 的核心指标内置了一个外部裁判：任何人都可以安装 Lean、加载相同的基准测试，并检查这些命题是否能编译通过。AesCode-8B 的核心指标则没有——确定性的验证器可以被执着的局外人重新运行，但分数中视觉的那一半取决于一个论文未指明的评判者。一个未复现的编译器通过率，是比基准测试表更弱的主张，但仍比一个内含匿名评分者的未复现评分标准得分更强。

运行它们与这两个分数中的任何一个都是不同的问题。

目前这两者都属于自托管决策。MathForm-8B 是明显更便宜的那个：一个约 8.2B 的纯文本检查点，生成预算大约为 16K token 的 Lean 输出，量化后可放进单张中端显卡。AesCode-8B 是一个 8.8B 的视觉语言模型，其服务路径既要处理图像也要处理文本；它所对应的命令是 vllm serve microsoft/AesCode-8B --limit-mm-per-prompt image=2 --max-model-len 24576，而 17.5 GB 的 bf16 权重，再加上面向 24,576 token 和两张图像的 KV 缓存，意味着 24 GB 显卡会很紧张，40–48 GB 才是现实的下限。如果你想给自己的输出打分，还要把渲染栈也计入预算，因为关于该模型的每一项质量结论都是这样得出的。

更大的隐性成本在于，这两个模型都是专用模型，你一旦采用就得永久维护。一个需要形式化处理和文档生成的团队，如今要运行两条 8B 服务路径、两套提示词格式、两套故障特征，而且两个模型都无法承接对方的工作。这正是路由层存在的意义：把专用模型留在经济性和数据处理足以证明自建 GPU 合理的地方，而把通用流量发往同一端点背后托管的服务。具体来说，这两个基座的通用版本是可直接调用的——Qwen3-VL-8B-Instruct，每百万输入 token 0.18 美元、每百万输出 token 0.70 美元，上下文长度为 131,072 token，以及 Qwen 3.8 系列和其他开放检查点——全都通过 OrcaRouter 的一个 API 覆盖 200 多个模型，服务商标价以 0% 加价原样透传，并支持服务商之间的自动故障转移。这两个专用模型在这里，或者在我们能找到的任何其他地方，都无法被路由；能被路由的是当窄任务完成后你所回退到的通用模型，而这正是试用一个研究检查点与把它变成承载关键依赖之间的区别。

如果实在要选的话，就在它们之间选吧

当产物必须能编译时，选择 MathForm-8B。题库转换、为证明器准备的形式化语料、为基于 Lean 的工具链预格式化命题——这就是它的全部职责，而且它是这两者中唯一为此接受过训练的。在规划范围时，请认真对待 FATE 的数字：在最困难的真实命题上，大约三分之一能输出一致的结果，而无论如何你都得构建一个人工审核步骤。

当产物必须渲染时，就选 AesCode-8B。输入一份简报，输出一份可编辑的 HTML 文档，表格就是表格，图表就是图表规格，而且整个东西能在 Git 里做 diff。要接受 Style 上限——53.21，一个被定义为交付前无需再做视觉修改的维度——把它当作衡量还剩多少编辑工作的诚实标尺，也要接受：24,576 token 的上下文仅在单张信息图页面上得到过验证，而不是人们真正想要的多幻灯片演示文稿。

不过，大多数团队实际会面临的选择并不是这两种。问题是，这些狭窄领域的专家模型之一是否值得部署，还是它背后的通用模型——通过 API 调用——对你现有的规模来说已经足够接近。那不过是花一个下午测试提示词，而不是买一块 GPU，而且这两张卡自身的数字就给了你运行它的理由：MathForm-8B 在困难集上的一致性为 37%，AesCode-8B 的风格得分为 53%，所以这两个都不是你会不加监督就放进流水线的模型。

这两次发布揭示了如今模型是如何交付的

两个 8B 微调模型，相隔八周，来自两个不同的实验室，发布时没有公告、没有产品页面，也没有独立评估，两者都围绕一个验证循环构建，都是 Apache 2.0，且都无人提供服务。这个模式本身比其中任何一个模型都更像是故事。研究方法已经移入奖励函数——OpenBMB 的编译器信号、Microsoft 的解耦跨模态通道——而已发布的产物已经变成训练配方加上权重，论文则随后才到，甚至根本不会出现。

对任何阅读像这样一份对比的人来说，这意味着有一阵子你能拿到的只有厂商自己给出的数字，而有用的问题不在于它们有多高，而在于它们有多可核查。AesCode-8B 的溢出率及其 Style 上限，是披着失败外衣的可核查主张。MathForm-8B 的 FATE-X 一致性数字也是同一回事。这些才是该读的数字，也是等检查器能够端到端复现时，你该自己回头重新跑一遍的那些数字。