MiniCPM-V 4.7 1B 对比 LFM2.5-VL 3B：OpenBMB 称其 1B 击败了 3B。这一说法掩盖了什么

MiniCPM-V 4.7 1B 和 LFM2.5-VL 3B 都是面向手机和小型计算机打造的开放权重视觉语言模型，二者发布时间相隔不到三周。MiniCPM-V 4.7 1B 由 OpenBMB 于 2026 年 10 月 6 日上传，并在厂商发布说明中标注为 10 月 12 日。LFM2.5-VL 3B 由 Liquid AI 于 2026 年 8 月 11 日发布。一个是 15.5 亿参数，采用 Apache 2.0。另一个是 31.2 亿参数，采用 LFM Open License v1.0。而 OpenBMB 自己的产品页面提出了一个足以让任何只按规模选购的人停下来的说法：其 1B 模型超越 LFM2.5-VL 3B 在 OCR、图表推理和视频理解方面。像此次发布背后有记录的 AI 故障和智能体事件都收录在 the OrcaRouter AI Incident Archive其中每条记录都带有各自的来源、严重程度、置信度等级和争议标记。

这句话承担了相当多的分量。而且，就任何人所能核查的范围而言，数字也并未与之矛盾——这一点比它真被数字反驳还要耐人寻味。本文逐一梳理各家厂商实际发布的内容、哪些地方的比较是真正成立的，以及该说法悄然转移话题的两处地方。

用供应商自己的话来说，这一宣称

OpenBMB 的 1B 页面称，该模型“是对 MiniCPM-V 4.6-1.3B 的全面升级，并超越了 Qwen3.5-0.8B 和 LFM2.5-VL-3B，在 OCR、图表推理和视频理解方面领先于其尺寸级别”。真正重要的是“领先于其尺寸级别”这个分句。与 LFM2.5-VL 3B 的比较被用作能力密度的证据；紧随其后的句子将这一说法限定在 LFM 并不属于的尺寸级别内。

Liquid AI 的对比卡片并没有给予对等回应。它完全没提到 MiniCPM，而是将自家模型与 G​emma4 E2B 和 E4B、InternVL 3.5 2B 和 4B，以及 Qwen3.5-2B 和 4B 进行了基准测试。因此，这是一场单方面的比较：一家厂商拿自己与另一家作对比，而另一方从未承认过这场较量。在阅读任何正面对比——包括本文——之前，首先需要了解的就是这种不对称性。

每家供应商公开表态的内容

Liquid AI 发布了一张数值表。LFM2.5-VL-3B 报告 MathVista 68.5、MMMU Pro 30.5、ChartQA 81.3 和 OCRBenchv2 47.5（仅英文子集），并在同一行中列出了同系列模型的得分。这些是厂商数据，由厂商自己运行，没有独立方必须认同它们——但它们是可证伪的，而这正是其有用之处。如果你在 MathVista 上复现出 55，你就知道你的设置中有某处不同。

OpenBMB 以文字形式发布数值摘要，并在其下方提供完整图表。对于 1B，页面列出 OCRBench 86.1、MathVista 74.3、CharXiv Reasoning 48.8、LongVideoBench 53.4 和 MotionBench 54.55，并将其余对比以带有 4× 和 16× 列的图片呈现。模型卡本身完全没有基准测试表格。

在两者都明确提到的那个基准上比较二者。MathVista：MiniCPM-V 4.7 1B 为 74.3，LFM2.5-VL 3B 为 68.5。按照厂商自己的报告，1B 领先 5.8 分。在 OCR 方面，两者使用了不同的评测工具——OCRBench 对 OCRBenchv2 的英文子集——因此这些数字不可比较，而这恰恰是一句“超越”会略过的那类细节。

在可进行对等比较的情况下

• 参数 — 1.55B 稠密、BF16、磁盘占用 3.1 GB，对比 3.12B 稠密、BF16；LFM 约为该模型的两倍

• 视觉编码器——SigLIP2 风格塔式结构，27 层，隐藏维度 1152，980 像素图块，对比 SigLIP2 NaFlex 400M，512×512 不重叠补丁外加一张缩放缩略图

• 文本主干——一种由 Qwen3.5 衍生的配置，具有 24 层、1024 隐藏维度、相较 LFM2.5-2.6B 的 3:1 线性注意力与全注意力模式，以及 Liquid AI 自主设计的混合架构

• 上下文 — 262,144 个 token 对比 32,768 个 token

• 视觉 token 预算——每次请求可切换 4× 或 16× 压缩，而 NaFlex 的补丁预算则由分辨率固定设定

• 许可 — Apache 2.0 与 LFM Open License v1.0 的对比：后者附带商业条款，而非单纯的宽松许可

• 提及的语言 — 卡片示例中的英语和中文，对比明确列出的 16 种语言（从阿拉伯语到越南语）

• 已发表的评估——五个以文字叙述给出的数值，外加在四个基准和六个同系列模型上仅以图表形式与数值表格进行的比较

• 独立评估——截至本文撰写时，二者均无 Artificial Analysis 条目 vs 二者也均无 Artificial Analysis 条目

• 厂商报告的速度——1B 模型在任何设备上均无每秒 token 数数据，相比之下 Apple M5 Max 为 228 tok/s、AMD Ryzen AI Max+ 395 为 116 tok/s、Galaxy S26 Ultra 为 20 tok/s

• 内存 — BF16 约 3.1 GB；Q4 GGUF 为 0.67 GB，另加 0.90–1.11 GB 的视觉投影器，而官方公布为低于 3.3 GB，并提供 GGUF、ONNX 和 MLX 构建版本

• 列出的服务路径——Transformers、SGLang、vLLM、llama.cpp、Ollama、OpenVINO、DSpark 推测解码与 Transformers、vLLM、SGLang、llama.cpp 的对比，以及 GGUF、ONNX 和 MLX 导出

• 端侧方案——iOS、Android、HarmonyOS 应用，以及 Rockchip、Houmo、Intel、AMD 和 Arm 的首日支持，并通过 iPhone 17 Pro Max 与 Galaxy S26 Ultra 的解码数据对比，以及面向 Apple Silicon 的 MLX 构建来演示

有两行值得再看一眼。上下文窗口方面存在八倍差距，且对 MiniCPM 有利；这种数字看似具有决定性，直到你想起：一个 1B 模型承载 262k token 时，其 KV 缓存比自身权重还大。实际上，在手机上，两个模型都不会运行到接近其上限。而许可证那一行，比任何基准测试都更常决定商业采用：Apache 2.0 无需与律师沟通，LFM Open License 则需要。

该主张转移话题所涉及的部分

OpenBMB 拿自己的模型与一个规模是其两倍的竞品作比较，用的是它自己选定的基准，并以文字叙述的方式报告结果。这并非不诚实——数字已公布，比较也明确说明。但它回答的并不是任何实际部署模型的人真正会问的问题。没人会在 1B 和 3B 之间做选择，是因为希望较小的那个更好；他们做选择，是因为其中一个能适配自己的设备而另一个不能，或是因为其中一个具备自己需要的语言覆盖，或是因为其中一个的许可证能通过法律审查。

就第一点而言，诚实的解读是：两者都装得下。LFM2.5-VL-3B 的规格页声称低于 3.3 GB，并展示了在 Galaxy S26 Ultra 上每秒 20 个 token。MiniCPM-V 4.7 1B 在 Q4 下连同其投影器约为 1.8 GB。因此，1B 的真正优势不是“它能跑在手机上，而另一个不能”——而是余量：大约少 1.5 GB 内存，这在中端 Android 设备上，就是应用能存活与被系统杀掉之间的差别。

在第二点上，比较结果正好相反。LFM2.5-VL-3B 在其模型卡中列出了 16 种语言，并且除 GGUF 外还提供 ONNX 和 MLX 构建版本。MiniCPM-V 4.7 1B 的文档主要围绕英文和中文示例，其端侧方案也主要围绕 iOS、Android 和 HarmonyOS 的芯片支持，而不是语言覆盖范围。如果你的产品面向土耳其语、波兰语或越南语用户发布，那么拥有公开支持声明的是那个更大、许可证限制更严的模型。

在第三点上，Apache 2.0 完胜，没什么可讨论的。

各自真正更擅长什么

LFM2.5-VL-3B 围绕一组特定任务构建，其模型卡片也明确说明了这一点：单轮、高吞吐、低延迟的工作，例如汽车场景中的近实时目标检测、带版式标注的扫描文档批量 OCR，以及菜单和路牌的设备端翻译。卡片还指出了该模型不适用的场景——长上下文和推理密集型任务、视觉网页设计、关于蓝图的技术问题。这种负面说明很罕见，比正面宣传更值得信任。

MiniCPM-V 4.7 1B 围绕尺寸区间底端的能力密度构建。混合的 4×/16× token 压缩是这一理念最清晰的体现：同一个检查点既能服务精细的文档阅读，也能应付廉价的缩略图处理，按请求选择。切片控制（图像 36 片、视频 1 片）、视频的帧采样参数，以及各自独立的 PDF 解析与 grounding cookbook 条目，都指向文档与屏幕类工作负载，而非检测类工作负载。它还以独立的 213M 参数产物形式提供 DSpark 推测解码头——如果你的运行时支持它，这就是实打实的吞吐杠杆；若不支持，则是纯粹的负担。

实际的区分在于：如果你是在摄像头画面中检测物体，或以每秒 20 帧的速度翻译标牌，那么 LFM 的延迟数据和语言覆盖范围就是它的优势。如果你是在把截图、收据和页面图像转换成结构化文本，并且 token 预算由你控制，那么 MiniCPM 的压缩开关就是它的优势。

买方应计入定价的差距

LFM2.5-VL-3B 自 2026 年 8 月 11 日发布以来——截至本文撰写时已有十周——就开放权重而言，这段时间足以让量化生态趋于稳定。GGUF、ONNX 和 MLX 构建版本均由厂商自行提供。你大概率会用到的任何运行时都有可行的支持路径。

MiniCPM-V 4.7 1B 发布至今才三周，它的模型卡一开头就提醒：CUDA 版本不匹配会通过 torchcodec 导致视频解码失效，并附有两种已有文档记录的变通方案。它的架构是全新的——一个一个月前还不存在的 model_type——而最低 Transformers 版本要求是 5.18.0。这些都不是缺陷。这是采用一款发布首月模型所要缴纳的标准税费，也正是为什么一次低调的发布、配上基于图表的评测，很适合做并排对比测试，而在第一周就把它当作生产路径则值得怀疑。

进行这项测试的低成本方法，是在评估新模型的同时让现有模型继续提供服务；这属于路由问题，而不是建模问题。OrcaRouter 运行 200 多个托管模型，将它们置于一个 OpenAI 兼容端点之后，且加价为 0%，将各提供商的标价原样传递，因此供应商降价当天就会体现在你的账单上，而不是等到下一个重新定价周期。它的路由 DSL 能在单次调用中同时容纳主用和备用路由，而自动故障转移会在提供商短暂故障时让路径保持可用——当你试用的模型是本地 1B 检查点，而生产中的模型是你付费使用的模型时，这正是你想要的。本文中的两个模型都不在该目录中：两者都是你自己运行的检查点，而路由器是围绕它们存在的，并不提供调用它们的方式。

索赔已了结

MiniCPM-V 4.7 1B 能击败 LFM2.5-VL 3B 吗？在 MathVista 上，按两家厂商各自报告的结果，领先 5.8 分。在 OCR 上，两者发布的评测工具不同，无法进行比较。在图表推理和视频理解方面，OpenBMB 宣称获胜并以图表形式发布，而 Liquid AI 从未回应。唯一可完全核查的那项比较支持这一说法；其余则是厂商以难以引用的格式给自己批改作业。

该说法经不起推敲的地方在于，它被解读为“更小的模型就是更好”。LFM2.5-VL-3B 提供十六种语言、导出的 ONNX 与 MLX 构建、在一部已上市 Android 手机上测得的书面速度数据，以及一张明确告诉你哪些场景不宜使用的说明卡。MiniCPM-V 4.7 1B 则提供可切换的 token 预算、262k 上下文窗口、Apache 2.0 许可，以及约 1.8 GB 的量化内存占用。这些本是不同的产品，却被套进了同一行基准测试数据里；正确的答案取决于上述哪一份清单更契合你的部署需求——而不是哪个数字更大。

用你自己的图像、按你自己的量化设置把两者都测一遍。权重是免费的，唯一的代价就是一个下午的时间。