MiniCPM-V 4.7 与 LFM3-VL-2B：基准分数更高，却选错了传感器

Liquid AI 将 MiniCPM-V 4.7 1B 放进了自己的对比表，然后击败了它。在 Liquid 运行的 62 项基准测试套件中，LFM3-VL-2B 在启用推理时平均得分 71.4，不启用时平均得分 62.1；MiniCPM-V 4.7 1B 平均得分 57.5。这是小模型层级中 13.9 分的差距，也是大多数对比文章到此为止会引用的数字。它也是决策中最没用的数字，因为这两个模型并不是在争夺同一个位置。一个是 19.2 亿参数的稠密模型，生来就是要成为完整答案。另一个是双模型系统里便宜的那一半，而它昂贵的那一半是 350 亿参数的专家混合模型。

The version of this matchup that matters depends on which MiniCPM-V 4.7 you mean. The 1B is a 1.55-billion-parameter dense model that fits in a 672 MB Q4_K_M file — 641 MiB, which is where the 641 MB on the cards comes from. The 35B-A3B is 35.2 billion stored parameters with roughly 3 billion active per token, and it is not in Liquid's table at all. LFM3-VL-2B sits between them and is, on Liquid's own numbers, a better general vision model than the small MiniCPM and a much weaker one than the large MiniCPM. Everything below is about which of those facts should decide your architecture.

三层档位假装成两个模型

LFM3-VL-2B 是一个成品。它拥有 19.2 亿参数，由 1.73B 的语言主干、164M 的自研视觉编码器和 25M 的投影器组成，上下文长度为 128K token，视频按每秒两帧采样，且仅用一套权重就能完成检测、OCR、图表理解与描述。Liquid 于 2026 年 10 月 27 日发布了 LFM3 系列；LFM3-VL-2B 的代码仓库则于 10 月 19 日上线。

MiniCPM-V 4.7 是两个共享同一视觉塔的制品。1B 版本采用稠密的 qwen3_5_text 骨干，具有 24 层、262,144 token 的上下文，并且每层全注意力对应三层线性注意力。35B-A3B 是一个 256 专家稀疏模型，每个 token 路由八个专家，保持相同的 262,144 token 上下文；它之所以存在，是因为 OpenBMB 想要一个能够从存储中流式加载专家、而不是将专家常驻内存的大模型。两者均采用 Apache-2.0 许可。权重于 2026 年 10 月 6 日和 7 日发布，模型卡随后于 10 月 12 日发布，ModelBest 于 10 月 15 日发布了英文新闻稿。

所以，诚实的说法不是“2B 对 1B”，而是“一个必须包揽一切的模型”对“一个由你决定每个问题值得用多少模型的家族”。如果你的流水线每张图像只问一个问题，LFM3-VL-2B 这种形态更简单，而且在小型端更强。如果你的流水线要问一万个廉价问题和一个昂贵问题，MiniCPM 这种形态在结构上就更便宜。

Liquid 自己的表格是怎么说的，以及读懂它需要付出什么代价

62 项基准测试套件出自 Liquid 之手，在 vLLM 0.27.1 上运行，统一归一化到 0–100 分制，除标注为“其他情况”的行之外，所有模型均启用了推理模式。厂商对竞争对手做基准测试是常态，也值得一读，但测试框架是厂商的，提示集是厂商的，聚合结果也是厂商的。这些行应当被视为厂商的主张。

• MMMU — LFM3-VL-2B 55.7 with thinking and 48.6 without, against 51.0 for MiniCPM-V 4.7 1B in the same column set. OpenBMB's own page reports no MMMU for the 1B, so this row exists only in Liquid's run.

• OCRBench v1 — LFM3-VL-2B 86.3 against 82.1 for MiniCPM-V 4.7 1B inside Liquid's table. OpenBMB reports 86.1 for its own 1B, which is a 4-point spread on the same named benchmark and a fair illustration of what a different harness does to a number.

• MathVista (mini) — 84.2 with thinking and 68.5 without for LFM3-VL-2B, against 71.2 for MiniCPM-V 4.7 1B in the same table. OpenBMB's page says 74.3 for that model.

• CharXiv reasoning — 70.2 for LFM3-VL-2B against 44.5 for MiniCPM-V 4.7 1B. OpenBMB's page claims 48.8 for the same model, so even the direction of the gap is harness-dependent.

• LongVideoBench — 53.4 for MiniCPM-V 4.7 1B on OpenBMB's page. Liquid's table carries no LongVideoBench row at all, so there is nothing to compare it with.

这一规律是一致的：开启推理时，2B 稠密模型在多步视觉推理和图表解读上更强，而在纯 OCR 任务上大致持平。关闭推理时，差距缩小到约 4.6 个百分点，这说明大部分优势是靠测试时 token 换来的，而不是靠参数换来的。这对延迟的影响大于对质量的影响，而延迟恰恰是这类比较通常忽略的维度。

逆转排名的独立测试

十月下旬，WebBrain 发布了一项包含 100 个用例的浏览器截图基准测试，该测试完全离线运行于双 RTX 5060 Ti 显卡上的 Q4_K_M GGUF，使用一组固定的截图、一个生产提示词和一个确定性评分标准。MiniCPM-V 4.7 1B 在每张截图 1.30 秒的速度下，取得 100 次中 37 次严格通过以及 68.2% 的平均评分标准得分。LFM3-VLD-2B——Liquid 模型的同系变体，并非确切的 LFM3-VL-2B 检查点——取得 4 次严格通过和 44.7% 的得分，速度为每张截图 2.20 秒。

这个注意事项很重要，而且两边都适用。在严格的编号标题正则下，MiniCPM 的通过数为零，因为它把章节标题写成了文本标签，而不是数字。37 次通过这个数字，是按章节名称重新评分同一批输出得到的。这是真实的格式失败；如果你的下游解析器期望的是编号标题，那就是不合格的。但内容得分差距并不小：68.2 对 44.7，而延迟只有 60%，且任务——读取密集的浏览器视口——比图表基准更接近生产环境。

这是这一层级中两个模型各自所拥有的唯一一项独立评测；它是在一对 GPU 上运行的一个测试框架，而且它测试的 Liquid 模型是 VLD 变体。它仍然比 62 项基准的汇总结果更有信息量，因为它衡量的是你用小型视觉模型实际会做的事情：看屏幕并快速回答一个固定问题。

许可证是无声的决定因素

MiniCPM-V 4.7 以 Apache-2.0 许可发布，没有收入条件。LFM3-VL-2B 以 LFM Open License v1.0 许可发布，Liquid 将其描述为年收入低于 1000 万美元时可免费用于商业用途。超过这一门槛后，条款会发生变化，你需要仔细阅读这些条款。

对于业余项目而言，这种差别只是理论上的。对于产品而言，这却是律师首先会追问的问题，也是任何对比表格中没有任何基准测试能够推翻的那一行。一个在图表推理上高出四个百分点、却附带营收触发条件的模型，并不自动就是更好的依赖项。这也正是 MiniCPM-V 4.7 两个尺寸都采用 Apache-2.0 比基准数字更起作用的地方：它省去了一场对话。

Cadence：两个表格均未报告的数字

esp32-eye 猫咪监控器是说明 MiniCPM 1B 实际如何被使用的最清晰公开案例。它在 MacBook 上以 Q4_K_M GGUF 的形式运行在 llama-server 后面，最多每 1.5 秒被调用一次，并由背景差异检查进行门控，因此大多数帧根本不会到达它。同一构建发现，1B 在区分四只相似的猫时并不可靠，于是将身份识别转移到 35B，而不是上线一个猜测结果。

这就是基准测试表未能体现的部署概况。一个每 1.5 秒调用一次的模型，需要小到足以常驻，快到答案能在下一帧到来之前返回，并且许可足够宽松，让你可以发布它。1B 模型同时满足这三点。LFM3-VL-2B 在 Q4 下为 1.25 GB，在独立测试中每张截图耗时 2.2 秒；对于逐图像流水线来说这没问题，但在同一硬件上用于 1.5 秒的闸门就太慢了。

如果你想要的是托管端点而不是本地文件，那么目前这两个模型都不在 OrcaRouter 的目录中，所以诚实的答案是：1B 运行在你部署它的地方，35B 运行在 OpenBMB 自己的 API 上。路由器真正能提供的是周边架构：一个密钥即可访问 200 多个模型，按提供商标价 0% 加价，以及自动故障转移——当昂贵的那一段是单一外部端点时，这正是让双模型流水线保持运行的方式。它并不能让一个未托管的模型变成托管模型，这一点值得直说。

该选哪一个

如果你要搭建一条单模型的图像流水线，并且想要在两个实验室各自公布的基准测试上最强的 2B 级通用模型，那么 LFM3-VL-2B 是站得住脚的选择，前提是把许可证方面的注意事项写清楚。如果你要构建一个循环查看屏幕的智能体，那么独立的浏览器测试显示 MiniCPM 1B 在得分和延迟两方面都更胜一筹；而它的格式规范性问题，应该在解析器里解决，而不是在模型里解决。

如果你需要一个能读取 262,144 token 文档、观看视频，并在 MMMU 上不落下风的模型，那么两个小模型都不是答案：那属于 35B-A3B 这一档，OpenBMB 报告其在 MMMU 上为 80.2、OCRBench 上为 91.2、LongVideoBench 上为 68.9，这些均为厂商报告，且无一经过独立复现。真正的决策不是哪个 2B 模型胜出，而是你的流水线是否能承受以低成本提出小问题、并很少提出难题——如果可以，双模型设计会比任何试图同时擅长两者的单一模型都更便宜。

最后一次校准。Liquid 公布的 13.9 个百分点差距在 Liquid 的测试套件上是真实的，WebBrain 公布的 23.5 个百分点差距在 WebBrain 的测试套件上也是真实的；它们指向相反方向，因为它们衡量的是不同任务。任何只引用其中一个而不引用另一个的人，都是在向你推销一个结论。有用的问题不是哪个模型更好；而是你每天需要问多少次，以及你愿意为答案付多少钱。