LFM3-Omni-2B 对比 MiniCPM-V 4.7 1B：较小模型何时读得更好

从纸面上看，这不是一场公平的较量。LFM3-Omni-2B拥有 21.7 亿个参数；MiniCPM-V 4.7 1B则被宣传为 1B 模型。更大的模型本应在视觉基准测试中胜出。但事实并非如此。MiniCPM 在 OCRBench 上得 86.1，而对方为 80.6；在 MMStar 上得 69.5，而对方为 55.67；在 MMMU 上得 56.9，而对方为 42.44；在 MathVista 上得 74.3，而对方为 62.5。这两份模型卡共有的每一项视觉基准测试都更青睐名称更小的模型，而且通常优势明显；MiniCPM 还拥有八倍的上下文窗口。Fusion 每次调用的成本高于路由到单一模型。它按 提供商标价计费，不添加任何加价。

有三件事可以解释这一点，而它们都不是任一模型的缺陷。MiniCPM-V 4.7 1B 是一个专家模型，把全部参数预算都花在了“看”上。LFM3-Omni-2B 是一个通用模型，把预算花在了看、听和说上。而最重要的 MiniCPM 数字——OCRBench 上的 86.1——是在其 4× 视觉 token 设置下测得的，这种设置用算力换取细节，是每张图像 2,048 个 token 的上限无法做到的。理解这种取舍才是整个决策的关键。

为什么较小的模型读起来更好

MiniCPM-V 4.7 1B 围绕一个核心理念构建：尽早压缩视觉 token，并让用户选择压缩力度。模型在视觉编码器内部应用 4× 或 16× 的 token 压缩，之后语言模型才会看到任何内容。在 16× 下，它成本低、速度快，适合图像描述和场景说明。在 4× 下，它保留四倍的 token 数量，这正是文档 OCR 和密集图表读取所需要的。OpenBMB 公布的核心数据均基于 4× 设置。

LFM3-Omni-2B 走的是相反的路线。它按原生分辨率处理图像，但将视觉预算限制为每张图像 2,048 个 token，而这个上限还要与一个音频编码器、一条视频路径和一个语音解码器共享，它们都位于一个 2.17B 的稠密网络中。对于一个必须与其他三种模态一起塞进手机里的模型来说，2,048 token 的上限是一个合理的选择。这也是一个硬性上限，决定了有多少页面细节能够进入语言模型；DocVQA 92.47 表明该模型从中榨取了不少性能——但 OCRBench 80.6 说明，这还不足以击败一个能在同一页面上花费 4 倍 token 的专用模型。

还有第二个更不显眼的因素。MiniCPM 的上下文窗口为 262,144 个 token。LFM3-Omni-2B 的上下文窗口为 32,768 个 token。对于单张截图来说，两者都无关紧要。但对于一份 40 页的 PDF、一段长视频，或一场多轮文档对话，这一差异并不是基准测试表格中的一行数字——它决定的是任务究竟能否完成。

规格参数，不含营销式的四舍五入

在进行任何比较之前，有一个数字需要更正。MiniCPM-V 4.7 1B 被称为 1B 模型，其密集参数量大约在 13 亿到 15.5 亿之间，具体取决于如何计算视觉塔。Hugging Face 的侧边栏将其四舍五入为“2B params”，这就是为什么一个 1B 模型在目录中看起来像 2B 模型。文件大小才是诚实的参考：BF16 下约为 3.1 GB，而 LFM3-Omni-2B 为 4.3 GB。

• 参数 — LFM3-Omni-2B 为 2.17B 稠密参数，而 MiniCPM-V 4.7 1B 约为 1.3B 至 1.55B 稠密参数。

• 输入——文本、图像、带音频的视频、16 kHz 音频，对比文本、图像、多图像和视频。

• 输出 — 文本和 24 kHz 语音，对比仅文本。

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

• 视觉 token — 每张图像上限为 2,048，而编码器内部可选择 4× 或 16× 压缩。

• 许可证 — LFM Open License v1.0 对比 Apache-2.0。

• 发布 — 2026年10月27日 对比 2026年10月12日。

• 内存占用 — 约 4.3 GB BF16 对比约 3.1 GB BF16，运行约需 5 GB 显存。

两张卡片共有的每一行

对于一张跨实验室的对比表来说，这次比较显得异常干净，因为两家厂商报告的是同样的四个视觉数据集，而且两者都是非推理模型、均以 instruct 模式进行评估。但这仍然只是两份厂商评估，且都尚未经过独立复现。

• OCRBench——LFM3-Omni-2B 为 80.6（1,000 题中 806 题），而 MiniCPM-V 4.7 1B 为 86.1。文档文本识别方面相差 5.5 个百分点。

• MMStar — 55.67 对 69.5。13.8 分的差距，是该组中最大的。

• MMMU 验证 — 42.44 对 56.9。在大学水平的多模态推理上存在 14.5 分的差距。

• MathVista mini — 62.50 对 74.3。在视觉数学方面存在 11.8 个百分点的差距。

四行，四负，差距在 5 到 15 个百分点之间。没有一行是 omni 模型获胜的，这比 LFM3 与 LFM2.5 对比所得出的结果更干脆，也更难辩解过去。最站得住脚的解释是：一个拥有 256K 上下文和 4× token 预算的 1.4B 专用模型，就是比一个拥有 32K 上下文和 2,048 token 图像上限的 2.17B 通用模型更擅长阅读。在这个规模上，把容量投入单一模态胜过把容量分散到四种模态。

有两点需要一并说明，因为两张模型卡都没有主动提及。MiniCPM 的 86.1 是在 4× 压缩下测得的，而同一模型在默认的 16× 设置下得分会更低、运行成本也更低——模型卡并未公布这一数字。而 OpenBMB 的模型卡则完全没有基准测试表；这些数据以文字说明和图表图片的形式出现在产品页面上，相比带有方法说明的表格，这是一种更弱的发布形式。这两组数字都来自厂商声明。差距的方向足够一致，或许能经受独立测试；但具体差距大小大概经不起。

上下文是决定真实工作负载的那一行

32K 上下文对于单张图像来说很宽裕，对于文档来说却捉襟见肘。按每张图像约 2,048 个视觉 token 计算，LFM3-Omni-2B 的窗口大约能容纳十几张完整图像，之后对话历史就会开始争夺空间。MiniCPM-V 4.7 1B 的 262,144 个 token 并非小幅提升，而是另一类工作负载。长 PDF、多页表单、长达一小时的视频摘要，以及在上下文中持续保留截图的智能体循环，在 256K 下都可行，在 32K 下都受到限制。

这是两个模型之间最少被讨论、却影响最大的差异。基准测试表格奖励的是单张图像的准确率；而生产环境的文档流水线往往在第十四页上失败。如果你的使用场景中每次对话涉及的图像超过寥寥几张，那么 32K 窗口会比上述四项基准差距中的任何一项都构成更严峻的限制。

MiniCPM 不能做什么

它听不见。它没有音频输入通路，没有语音输出，也不处理视频音轨。如果应用场景是一个人对着设备谈论摄像头所看到的内容，那么 MiniCPM-V 4.7 1B 只是整条流水线中的一个组件，这条流水线至少还需要另外两个模型——一个 ASR 系统和一个 TTS 系统——再加上在两者之间传递文本的衔接层。

LFM3-Omni-2B 把那条流水线压缩进了一个 4.3 GB 的检查点。与专用语音模型相比，它的音频指标平平无奇——英语 ASR 词错误率 6.36、VoiceBench 64.73——但这些能力与视觉路径存在于同一次前向传播之中，这意味着模型可以回答针对图像的口头提问，而全程无需写出任何转写文本。对于免提现场工具或自助终端来说，这正是它的核心价值。而对于文档流水线而言，它只是参数预算里的累赘。

OrcaRouter 的 模型融合是同时获得这两种行为的另一种方式：一个面板，让文档专家模型和全模态模型回答同一个提示词，并由两者共同组成回复。这是一种产品能力，而不是关于这两个检查点的声明——今天它们都不在我们的目录中——但它是对这样一种对局的架构级回答：每个模型显然更擅长这项工作的不同一半。融合每次调用比路由到单个模型成本更高，而当错误答案的代价高于 token 成本时，它恰恰值得。

决定

如果任务是阅读——OCR、发票、表单、图表、截图、长篇 PDF、密集的 UI——那么 MiniCPM-V 4.7 1B 在每一项公开指标上都是更好的模型：它的上下文长度是前者的八倍，采用 Apache-2.0 许可证，而不是带有收入门槛的自定义许可证，并且它在磁盘上占用的空间更小。这不是一场势均力敌的较量，而它被称为 1B 模型这一事实也不应掩盖这一点。

如果任务是与具备摄像头和麦克风的设备进行对话，LFM3-Omni-2B 是两者中唯一能参与的那个。它读得没那么好，保留的上下文更少，并且以更严格的条款发布，而如果替代方案需要三个模型和一条流水线，这些都不重要。

还有一种值得命名的第三种情况：一个产品同时需要两者，而文档路径和语音路径是彼此独立的功能。此时正确的架构不是用一个模型，而是用两个模型，并按请求类型来路由——文档交给 reader，语音交给 omni 模型——唯一的问题是，你是想同时运行两者，还是让单一端点来决定。这正是这一批对比反复落到的问题，而且它问得对。这些模型在体量上足够接近，同时运行两者是切实可行的选择；它们在能力上又相距足够远，无论选哪个，只运行一个都是一种妥协。

能改变结论的，是对任一模型的独立评估，尤其是以 MiniCPM 默认的 16× 压缩而非其宣传数字所用的 4× 设置来测试它的评估。这一个数字可能缩小大部分差距——也可能扩大差距。在有人公布它之前，我们只能依赖厂商的表格，而这些表格指向同一个方向。