LFM3-1.7B 与 MiniCPM5-2B：测试 Liquid 的 23 比 4 记分板

2026年10月27日，Liquid AI 发布了一张27行的基准测试表，将 LFM3-1.7B 与 MiniCPM5-2B 进行对比。Liquid 的模型在其中23行获胜。MiniCPM5 赢了四行。这个计数迅速流传开来，而这本身是个问题，因为在一张由某一家厂商挑选基准、编写测试框架并运行两个模型的表格里，胜场数是你所能提取出的信息量最少的东西。本文要检验的正是这个23–4究竟能告诉你什么——而它首先得承认一件事：Liquid 悄然回应的那篇对比文章，早一天就发表在本博客上，而它当时没有提出这个确切的论点。那篇文章比较了两个基础检查点，并得出结论：两者都没有可用的评估结果。下面是双方都换成后训练权重后的版本。

MiniCPM5-2B 是 OpenBMB 的 2.52B 稠密推理模型，于 2026 年 9 月上旬以 Apache 2.0 许可发布。LFM3-1.7B 是 Liquid AI 的 1.73B 文本与智能体模型，于 2026 年 10 月 27 日以 LFM Open License v1.0 发布。二者处于同一参数量级，争夺同一个端侧部署位置，却是为明显不同的任务而打造。

两家供应商，两套线束，一张表

23–4 这个计数之所以存在，只是因为 Liquid 重新跑了一遍其竞争对手。对于一次产品发布来说，这是合理且异常严谨的做法——大多数厂商会拿公开排行榜上的数字来比较，而把背后的测试脚手架略去不提。但在你自己的测试框架上重跑竞争对手，并不会得出中立的结果，而破绽就藏在同一项基准测试同时出现在两家厂商规格卡上的那些行里。

以 BFCL V4 为例。Liquid 测得 MiniCPM5-2B 为 62.65。OpenBMB 自己的模型卡报告为 66.6。以 Humanity's Last Exam 为例：Liquid 给 MiniCPM5 的分数是 8.20，OpenBMB 声称是 8.9。这些差距很小——在 0–100 的量表上不超过四点——表明在标准化基准上，评测框架的差异并不大。再看 SWE-bench Verified：OpenBMB 报告 MiniCPM5-2B 为 46.4，Liquid 报告 LFM3-1.7B 为 43.40。把这两个数字并排放在一起，MiniCPM5 胜出。把 Liquid 自己报告中的 MiniCPM5 那一行与 Liquid 自己报告中的 LFM3 那一行并排放在一起，LFM3 胜出。同一基准、同样的两个模型，却得出相反的答案，因为这些数字来自不同的评测框架。

一个例子就说明了整个问题。两家供应商都没有公布测试框架配置、重试策略或提示词脚手架。除非有人让两个模型都在他们无法控制的同一个测试框架中运行，否则这项比较中每一行跨供应商的数据都只是披着测量外衣的抛硬币。

当差距过大、不可能是测试线束噪声所致时

有些数据行无法被解释搪塞过去。智能体网页导航是最明显的例子：

• WebArena-Verified — LFM3-1.7B 在 Liquid 的测试框架上为 38.42，MiniCPM5-2B 为 9.11。

• AutomationBench — 41.29 对比 4.71。

• RULER 128K — 65.56 对比 37.96。

• BFCL V4 — 71.39 对比 62.65。

四分差距只是脚手架。WebArena-Verified 上的二十九分差距，或 AutomationBench 上的三十七分差距，则不是。这些差距在于模型究竟能否把多步计划连贯地维持住，而且它们与两家厂商各自对自己的说法一致：Liquid 围绕基于工具调用轨迹的智能体中训来构建 LFM3，而 OpenBMB 自己的文档则指出 MiniCPM5 在长多步任务上较弱，且容易重复。对同一弱点的两种独立描述，从相反方向得出，是整个对比中最有力的证据。

长上下文这一行值得单独关注，因为它是人们最容易误读的一项。MiniCPM5 在 RULER 128K 上的 37.96 是 128K 长度下的检索得分，并不意味着该模型的上限就是 128K——MiniCPM5-2B 官方支持 131,072 个 token。它说明的是：在该长度下，MiniCPM5 能找到的你所要求的内容更少。LFM3 在相同长度下的得分为 65.56。如果你的工作负载是"检索长文档并作答"，那么这一差距就是全部的决策依据。

MiniCPM5 胜出的四行——以及它们为何重要

Liquid 的表格让 MiniCPM5-2B 赢得四项胜利：τ³-bench 以 69.44 对 68.01，GPQA Diamond 以 65.15 对 63.37，HLE 以 8.20 对 7.17，AA-Omniscience 以 9.13 对 7.07。四项中有三项是知识基准。差距为一到两个百分点，处于大多数评测套件的噪声底限之内。

但这种模式与 MiniCPM5 的设计是一致的。OpenBMB 将其训练为一个具有显式思考模式的推理模型，训练链路先在 4000 亿 token 上运行深度思考 SFT，然后使用专家教师进行强化学习，随后再通过同策略蒸馏整合到单个稠密检查点中。这是一种旨在让每个参数从已存储知识中榨取更多价值的配方。LFM3 的训练则针对工具调用和指令遵循。GPQA Diamond 上 MiniCPM5 以 1.8 分胜出并不令人意外；这正是两种训练理念在你预料之处显现出来。

更值得玩味的比较，是 Liquid 的表格无法做出的那种。MiniCPM5-2B 的 Artificial Analysis Intelligence Index 为 12。截至 2026 年 10 月 28 日，LFM3-1.7B 在 Artificial Analysis 上完全没有条目——没有指数、没有独立测得的运行速度、也没有中立的延迟数据。于是，在 27 行中输掉 23 行的模型，反而是拥有独立数据点的那个；而赢下这些行的模型，却是那个要求人们凭信任接受它的模型。这种不对称性，应该比胜出的行数更有分量。

真正能清晰对比的规格

在两家厂商都没有运行对方基准测试的情况下，这些数字乏味但可靠：

• 参数 — LFM3-1.7B 1.73B 稠密 对比 MiniCPM5-2B 总计 2.52B，非嵌入 1.98B。

• 层 — 24 个混合层（13 个卷积、5 个滑动窗口、6 个全局），对比 42 个标准 Transformer 层，采用分组查询注意力，具有 16 个查询头和 2 个 KV 头。

• 上下文 — 256K 对比 131,072。

• 128K 下的 KV 缓存 —— 按 Liquid 对两者的实测，为 1.6 GB 对 5.6 GB。

• 4 位下的占用——实测报告约为 1 GB，对比约为 1.1 GB。

• 词汇量 — 128K 对比 130,560。

• 许可证 — LFM Open License v1.0，收入低于 1000 万美元免费；相比之下，Apache 2.0 无门槛。

KV-cache 那一行才是决定硬件配置的关键。在相同上下文长度下，3.5 倍的差距，意味着长上下文智能体能否装进一台手机里。它也解释了为什么 LFM3 能提供 256K，而 MiniCPM5 只能提供 131K：三混合层组合让每个上下文 token 的开销更低，而这正是构建它的全部意义所在。

对某些团队来说，许可证差异比内存差异更重要。Apache 2.0 没有收入门槛，无需协商商业协议，再分发也没有歧义。LFM Open License 在年收入低于 1000 万美元时免费，超过这一门槛则需要进行沟通。低于该门槛的初创公司可以免费获得两者。超过该门槛的公司可以免费获得其中一个，而另一个则需打个电话沟通后才能获得；无论哪个模型得分更高，这都是实实在在的采购成本。

生态系统支持是 MiniCPM5 仍然领先之处

两个系列在发布首日都提供了广泛的运行时支持，因此这一差距比一年前更小了。LFM3 列出了 vLLM、SGLang、Transformers、llama.cpp、MLX、ONNX、Ollama 和 LM Studio，并提供 BF16、FP8、NVFP4、GGUF、MLX 和 ONNX 构建版本。MiniCPM5-2B 列出了相同的运行时，外加 GPTQ 和 DSpark——后者是一个推测解码草稿模型，可与主检查点配合使用。

实际差别在于成熟度，而不是可用性。MiniCPM5-2B 从九月初就可以下载，这意味着它已经积累了七周的社区缺陷报告、量化实验和框架补丁，而 LFM3 还没有。昨天刚发布的模型，在其 GGUF 转换和 Ollama 打包方面难免会有粗糙之处。这并不是在批评 Liquid；这就是发布首日的常态。如果你本周就需要把模型投入生产，那么别人先踩了七周的坑，是有价值的。

如何做决定，以及路由器在哪些地方能体现其价值

这两个模型都不在 OrcaRouter 目录中——两者都是自行运行的开放权重模型，我们宁愿直说这一点，也不愿暗示并非如此。路由器在边界处很重要。诚实地开展这项评估的方式，是把两个模型都放在同一个端点后面，并向它们发送真实流量；而无论将哪一个投入生产，诚实的做法都是不让一个 2B 模型成为唯一能作答的模型。

这正是自动故障转移的用途。将请求路由到 LFM3-1.7B，让它处理其受训执行的工具调用或信息抽取；当任务所需步骤超出 2B 模型所能承载的范围时，再回退到托管模型。由于 OrcaRouter 以 0% 加价按提供商标价原样传递，昂贵路径只在实际使用时才产生提供商收取的费用——路由到小型本地模型带来的节省不会被路由器吃掉。路由 DSL让你可以把它表达为规则，而不是重写：专家模型优先，失败或低于置信度阈值时再走通用模型。

模型融合是这里尚未被充分利用的选项。当两个 2B 模型对某个分类结果不一致时，让两者都给出答案并进行协调，通常比升级到 27B 模型更便宜；而分歧率本身也是一个有用信号，能说明哪些输入较难。当你的流水线一侧存在未经验证的模型时，这种交叉校验比信任供应商表格更便宜。

什么才能了结此事

三十天后，应该有人通过同一套评测框架发布 LFM3-1.7B 和 MiniCPM5-2B，并把配置与结果一并提交。如果 LFM3 在 WebArena-Verified 上能保持在接近 38 的水平、在 RULER 128K 上接近 65，那么 23–4 的胜负记录就是结论大致正确、但理由错了，而智能体能力差距确实存在。如果它下滑到接近 MiniCPM5 的数值，那么发布时的对比表所衡量的其实是脚手架。

在此之前，可辩护的立场比两家厂商的宣传都要狭窄。如果你的工作负载是多步骤、工具调用或长文档，LFM3-1.7B 是更稳妥的选择，而内存优势使它成为两者中唯一能在资源受限的硬件上留有余量运行的模型。如果你的工作负载是知识检索、单轮推理，或者需要明确的许可证以及附带独立评分的模型，MiniCPM5-2B 是更保险的选择，而它胜出的那四行恰恰指向这个方向。23 比 4 这个计数与其说是错的，不如说是名不副实——而发布表格中的模型数量，并不等同于结果。