LFM3-1.7B-Base 与 MiniCPM5 2B：两家厂商，两张记分牌，一个诚实的答案

Liquid AI 于 2026 年 10 月 26 日在 Hugging Face 上创建了 LFM3-1.7B-Base 仓库，并于次日发布了 LFM3 系列公告——而该公告的基准测试表做了一件异常有用的事：它将后训练后的 LFM3-1.7B 直接与 MiniCPM5-2B 对比，后者是 OpenBMB 自其权重于 9 月发布以来一直称为 2B 级开源最先进水平的 2.5B 模型。在 Liquid 自己的 27 项测试套件中，LFM3-1.7B 在 23 行中胜出，而 MiniCPM5-2B 在四行中胜出。不过，本文标题中的检查点并不是该表中的那个，而且它不附带任何形式的基准测试数字。这一差距正是故事所在。

在每一次小模型对比中，都有三件事被混为一谈，所以值得事先把它们区分开：Liquid 测了什么，OpenBMB 测了什么，以及两家厂商都未公布的、关于人们实际微调所使用的基础检查点的信息。只有第三类才称得上本页这两个名字之间的一场公平较量。

Liquid 发布的表格，以及它所描述的模型

LFM3-1.7B 模型卡包含 27 行，分布在七个类别中——智能体、工具使用、智能体编程、编程、指令遵循、知识和长上下文——列包括 LFM2.5-2.6B、MiniCPM5 2B、Gemma 4 E4B、Qwen3.5 4B 和 Qwen3.5 9B。Liquid 自家模型在其中除四项外全部胜出，而且智能体相关行上的领先幅度并不小：LiveClaw 45.60 对 30.37，WebArena-Verified 38.42 对 9.11，AutomationBench 41.29 对 4.71，BrowseComp-Plus 37.00 对 16.83。同样的模式也体现在工具使用（BFCL V4 71.39 对 62.65，ToolSandbox 80.36 对 68.16）和长上下文方面，其中 RULER 128K 为 65.56，而 MiniCPM5-2B 为 37.96。

MiniCPM5-2B 的四项胜出全都属于知识或多轮鲁棒性方面：τ³-bench 为 69.44 对 68.01，GPQA Diamond 为 65.15 对 63.37，无工具条件下的 Humanity's Last Exam 为 8.20 对 7.17，AA-Omniscience 准确率为 9.13 对 7.07。这些都是在零点几分往往只是噪声的基准上取得的微弱优势。而智能体能力上的差距则并非如此。

那段文字里的每个数字都是厂商自行上报的。Liquid 运行了自己的测试框架，选定了自己的对比集合，却没有在产品卡上公布逐项测试方法。截至 2026 年 10 月 28 日，我们在 Artificial Analysis 上找不到任何 LFM3 条目，因此没有独立复现结果可与之对照。应把 23–4 这一分项结果视为 Liquid 的论点，而不是行业结果。

基础检查点实际上是什么

去掉后训练部分，剩下的就是一个拥有 24 层的 1.73B 纯文本模型：13 个门控短卷积、五个窗口大小为 256 个 token 的滑动窗口注意力层，以及六个全局注意力层。256K 上下文这个数字是真实的——已发布配置中的 max_position_embeddings 写的是 262,144——而不是早期报道将其混淆的那个 256 token 窗口。词表包含 128,000 个 token，模型卡列出了 16 种语言，许可证为 LFM Open License v1.0；对于年收入达到或超过1000万美元的法律实体，其商业授权不再适用。

训练方案的记录比大多数基础版本发布都更详细：总共 22 万亿个 token，其中最后 3.5 万亿用于经过整理的中期训练数据，这些数据包含智能体轨迹和工具调用，另外还有 128K 和 256K 上下文扩展。在 4 位精度下，该检查点据称占用约 1 GB；如果目标设备是手机或笔记本电脑而不是服务器，这个数字才是关键。

模型卡没有提供的，是对基座模型本身的任何评估。Liquid 公布的分数属于 LFM3-1.7B 在经历 SFT、混合 RL、多域同策略蒸馏和智能体 RL 之后的版本。仅凭公开材料，无法区分 49.37 的平均分中有多少来自 22 万亿预训练 token，又有多少来自后训练流程。这并不是针对 Liquid 的批评——几乎没有人公布基座模型评估——但这确实意味着本文标题中的这个名字并没有属于自己的成绩单。

OpenBMB 的计数器记分板

MiniCPM5-2B 的模型卡在不同维度上给出了不同的说法。其能力雷达图对九个维度打分，并报告平均分为 53.9，而 Qwen3.5-4B 为 51.1，granite-4.2-3B 为 42.7，LFM2.5-2.6B 为 33.2。在该榜单上，该模型是 2B 级别的当前最优，并且可与 4B 级模型竞争。它没有纳入 LFM3-1.7B，因为该模型在模型卡撰写时尚未存在。

这两个排行榜不能相互相减。它们使用的测试不同、归一化方式不同、比较集也不同——而唯一重叠的基准 τ³-bench，恰恰正是 OpenBMB 的模型在 Liquid 的表格中略微领先的地方。如果你把 53.9 和 49.37 放在一起，就得出 MiniCPM5-2B 是更强模型的结论，那你就是把一个九轴厂商平均值和一个 27 项测试的厂商平均值拿来比较，什么也说明不了。

硬件方面的事实则没那么含糊。MiniCPM5-2B 是一个原装的 LlamaForCausalLM，总参数量为 2,516,756,480，其中非嵌入参数为 1,981,982,720，共 42 层，采用分组查询注意力，拥有 16 个查询头和 2 个 KV 头，并且在出厂配置下具有 131,072 个 token 的上下文。它采用 Apache 2.0 许可，以 GGUF、MLX、GPTQ 和 LiteRT 构建形式发布，同时还附带一个用于投机解码的草稿模型，OpenBMB 也随之一并发布了训练语料。这是一个连工厂一起交付的成品。

只有基准对基准，才是唯一干净的比较。

两个系列都发布了预训练检查点，这使得首次进行同类比较成为可能。MiniCPM5-2B-Base 创建于 2026 年 8 月 27 日，采用 Apache 2.0 许可，其存在原因与 LFM3-1.7B-Base 相同：被后训练成其他模型。两个基础模型卡均未发布评估表。因此，决定必须基于规格、许可证和生态系统，而不是基于分数。

这种重新界定很重要，因为这对模型最常见的错误，是下载 Liquid 基座模型，像对话模型那样提示它，然后得出结论说它比 MiniCPM5-2B 差。它确实会差。LFM3-1.7B-Base 是带有聊天模板和思考模式的中间训练产物，不是助手；Liquid 自己的模型卡也说明，聊天、工具调用和智能体场景应使用 LFM3-1.7B。OpenBMB 的完成版检查点才是与 LFM3-1.7B 对比的正确对象，而这种对比已经存在于 Liquid 的表格中。基座对基座的比较，是给打算自己进行训练的人看的。

规格表，逐项解读

• 参数 — LFM3-1.7B-Base：1.73B，共 24 层。MiniCPM5-2B：总计 2.52B，非嵌入参数 1.98B，共 42 层。

• 上下文——LFM3-1.7B-Base：256K 个 token，输入加输出。MiniCPM5-2B：出厂配置中为 131,072 个 token。

• 架构 — LFM3-1.7B-Base：采用门控短卷积以及滑动窗口注意力和全局注意力的三混合架构，并通过 trust_remote_code 加载。MiniCPM5-2B：一个可在未经修改的工具链上运行的标准 Llama 解码器。

• 许可证 — LFM3-1.7B-Base：LFM Open License v1.0，商业使用以年收入低于 1000 万美元为条件。MiniCPM5-2B：Apache 2.0，无收入条件。

• 已发布格式 — LFM3-1.7B-Base：基础模型卡上仅提供 BF16 权重；经后训练的同类模型提供 GGUF、MLX、ONNX、FP8 和 NVFP4 构建版本。MiniCPM5-2B：BF16、GGUF、MLX、GPTQ 和 LiteRT，另有 SFT 与中期训练检查点以及一个 DSpark 草稿模型。

• 占用 — LFM3-1.7B-Base：据 Liquid，4 位量化下约为 1 GB。MiniCPM5-2B：一个 2.5B 稠密模型，模型卡上未公布 4 位占用；预计是常见的 2.5B 级别内存开销，而非 1 GB。

• 语言——LFM3-1.7B-Base：16 种具名语言，包括阿拉伯语、印地语、泰语和越南语。MiniCPM5-2B：一张以英语和中文为中心的模型卡，背后有已发布的数据支持。

• 训练数据 —— LFM3-1.7B-Base：22T tokens，训练配方已有描述，但数据未发布。MiniCPM5-2B：UltraData 语料库随权重一同发布。

仓库能告诉你关于部署的哪些信息

MiniCPM5-2B 是目前更容易部署到设备上的模型。它的架构是标准的，因此 llama.cpp、Ollama 和 LM Studio 的支持只需使用已发布的 GGUF，而不必等待内核支持。Apple Silicon 有 MLX 构建版本，Android 有 LiteRT 路径，而 DSpark 草稿模型的存在正是为了在受限硬件上加快解码速度。

LFM3-1.7B-Base 对运行时提出了更高要求。它需要自定义建模代码，而且基础检查点仅以 BF16 发布。同系列其他模型得到了更好的支持：Liquid 列出了 vLLM、SGLang 和 Transformers 对 BF16 的支持，SGLang 对 FP8 和 NVFP4 的支持，llama.cpp 和 Ollama 对 GGUF 的支持，MLX 对 Apple Silicon 的支持，以及 ONNX Runtime 用于跨平台工作。问题在于，这些构建属于 LFM3-1.7B，而不属于基础检查点。添加 LFM3 支持的 SGLang 拉取请求 #46858 在撰写本文时仍处于打开状态；配套的 cookbook 拉取请求已合并。

如果问题是本周要把哪个模型放在某个端点后面，请注意，MiniCPM5-2B和LFM3-1.7B-Base目前都不在 OrcaRouter 的目录中。两者目前都只能下载后自托管。这正是路由层会在后期而非早期体现价值的场景：一个兼容 OpenAI 的密钥即可访问 200+ 个模型，0% 加价并透传提供商标价，而且当自托管机器或单个上游宕机时可自动故障转移。在笔记本上运行 1 GB 模型并不需要这些；当小模型成为生产路径的一环、而必须有东西来兜住故障时，你才需要它。

什么是尚不可知的

这份诚实的清单简短而具体。我们找不到任何针对 LFM3 模型的独立基准测试，因此关于该系列的所有能力主张都出自 Liquid 自己。LFM3-1.7B-Base 没有已发布的评测，所以没人能说这个原始检查点在后训练之前究竟有多好。LFM3 在托管 API 上没有按 token 计价的价格，这使得与 MiniCPM5-2B（在大多数部署中同样是自托管）的成本比较变成了一场硬件与电力的计算，而不是价目表上的对比。而且目前还没有证据——无论是独立的还是其他来源的——能说明 256 token 的滑动窗口是否会在检索密集型的长上下文任务中让模型付出代价；Liquid 自己报告的 RULER 128K 得分 65.56 远低于其为 Qwen3.5 9B 报告的 87.11，这是一个值得关注的信号，而非定论。

在下载其中任何一个之前，有三个值得回答的问题

你想要一个模型，还是一个起点？

如果你想要一个能回答问题、调用工具，并且能撑过周一演示的东西，MiniCPM5-2B 是成熟成品，而 LFM3-1.7B-Base 不是。如果你有领域语料、后训练流水线，并且有理由说明现成模型不够用，那么基础检查点就是正确的购买选择——而且 Liquid 提供的用于 SFT、DPO、GRPO 和持续预训练的 TRL notebooks，比大多数厂商提供的指导更多。

您的组织年收入有可能超过1000万美元吗？

LFM Open License v1.0 仅在低于该门槛时授予商业权利。高于该门槛时，该作品完全不在该协议的许可范围内，你需要与 Liquid 另行达成安排。Apache 2.0 没有这种断崖式条款。对于业余项目或早期初创公司而言，这一差异只是理论上的；对于成熟公司而言，它会在运行任何基准测试之前就决定其候选名单。

256K 上下文是否值得采用定制架构？

LFM3-1.7B-Base 以更小的参数量提供了 MiniCPM5-2B 两倍的上下文，这是支持它的最强技术论据。代价是，它是一个需要远程代码的非标准模型，基础检查点上现成的构建版本更少，而且运行时集成仍在落地中。如果你的工作负载在 131K 以内，你就是在为用不到的余量支付这个代价。

该选哪一个

对于大多数在这两个名字之间做比较的团队来说，答案都是 MiniCPM5-2B——不是因为它能在基准测试竞赛中胜出，而是因为它是一个完整的 Apache-2.0 产品，拥有量化版本、已公开的训练数据，且没有许可上限。要把一个能力足够的 2.5B 模型部署到设备上，这是风险更低的方式。

LFM3-1.7B-Base 对更小众的受众来说是一个更有趣的押注：这些团队想要一个具有 256K 上下文、16 种语言和非标准架构的 1.73B 检查点，能够在一张 GPU 上继续训练，并且可以接受 LFM 许可证和较为薄弱的基础模型生态。Liquid 为这类受众提供了一个真正的起点和一份异常详细的训练配方。它尚未给任何人一个理由去相信该基础检查点优于 OpenBMB 的成品检查点，而供应商自己的表格也没有试图声称这一点。

真正值得关注的数字不是 23–4 这个分差，而是任何 LFM3 模型首次接受独立评估——从这一刻起，Liquid 的记分板将不再是唯一的记分板。