LFM3-Omni-2B 对比 MiniCPM-V 4.7 35B-A3B：新秀与卫冕者

两个数字都属实，但如果把它们当作结论来读，两者都会造成误导：MiniCPM-V 4.7 35B-A3B的下载量约为 289,000 次，而LFM3-Omni-2B的下载量为 83 次。这个差距看起来像是一场碾压，实际上却是一张日历。OpenBMB 的权重于 2026 年 10 月 6 日上线；Liquid AI 的权重于 10 月 21 日上线，并于 10 月 27 日发布——就在这些数字被读取的前一天。一个只存在了一周的模型不可能有下载历史，而一个领先六周、且已有 MiniCPM 受众基础的模型，无论它是否配得上，都会有下载历史。

所以，真正有意思的对比并不是受欢迎程度，而是一个为设备选择小型多模态模型的团队实际应该权衡的东西：它是否需要能听，是否需要以六种方式量化，以及在产品已经有收入时，哪种许可证仍然让人放心。

每个模型是什么

MiniCPM-V 4.7 35B-A3B 是 OpenBMB 首个混合专家视觉语言模型：存储参数为 352 亿，每个 token 从 256 个专家中路由 8 个，约 30 亿活跃参数，文本部分有 40 层，前置一个隐藏维度为 1,152 的 27 层视觉塔，该视觉塔接入文本堆栈的第 6 层。它能读取图像、多图集合、视频和文本，并以文本作答。在 70.4 GB 的权重中没有任何音频通路。这张模型卡的首要卖点不是准确率，而是可行性：在 iPhone 17 Pro Max 上使用约 3 GB 内存即可达到每秒超过 13 个 token，这得益于 Lookahead Expert Scheduling 技巧——它预测下一层的专家，并在当前层计算时预取这些专家。

LFM3-Omni-2B 是 Liquid AI 在 LFM3 系列中的全模态（omni）入门模型：它基于 LFM3-1.7B 主干，拥有 217 亿稠密参数，并配备 LFM3 视觉编码器和 LFM3 因果音频编码器，二者共同接入一个 128,000 token 词表。它可以读取文本、图像、带声音或不带声音的视频，以及 16 kHz 音频，并能输出文本或 24 kHz 语音，包括在单次响应中交错输出文本和语音。它按设计就是非推理模型——模型卡指出不支持 enable_thinking=True——其定位面向手机、笔记本电脑和边缘硬件。

两者都能适配手机。只有一个是围绕这一点设计的。

很容易把两者都归入“设备上的小模型”然后就此了事。但其底层的工程实现恰恰相反。

OpenBMB 的问题在于手机上的内存带宽，因此该模型采用稀疏设计，以减少每个 token 需要读取的内容：存储 35.2B，实际触及 3B。Lookahead Expert Scheduling 就是明证——只有当瓶颈在于搬运权重而非进行乘法运算时，你才会构建专家预取。LFM3-Omni-2B 通过真正做小来解决同一个问题：2.17B 稠密参数，完全不做路由，全部采用 16 位，仍然只有几 GB。

这种取舍体现在量化上。MiniCPM-V 4.7 提供 GGUF、AWQ、GPTQ、FP8、INT4 和 BitsAndBytes 构建版本，以及用于推测解码的 DSpark 草稿检查点——无论你最终落在哪种加速器上，都有完整的选择。LFM3-Omni-2B 在 Hugging Face 上有 BF16 权重，并且有一个在流通的 Ollama 构建版本，而该 Ollama 条目标称 125K 上下文，模型卡中则是 32K。截至撰写本文时，这究竟是打包错误还是未记录的能力，尚无定论。如果你需要在 Rockchip NPU 或 Intel 笔记本电脑上运行，拥有六种量化格式的厂商在上手首日是更稳妥的选择。

决定大多数部署的那一行

MiniCPM-V 4.7 35B-A3B 听不见。没有音频塔，没有 ASR 路径，没有语音头。LFM3-Omni-2B 能听，也能出声回答，支持 19 种语音区域和 16 种文本语言。

对于文档、图表、截图或视频帧这类工作负载，这一差异无关紧要，而 MiniCPM 在几乎所有其他维度上都是更强的选择——规模更大、测试更广泛、工具支持更完善。而对于任何涉及麦克风的场景，比较就此立刻结束。你无法在不额外添加一个独立的 ASR 模型、再加一个 TTS 模型的情况下，给 MiniCPM-V 4.7 装上“听觉”——而到了那一步，你就是在用三个模型去做一个 2.17B 检查点原生就能完成的事。

反过来也成立。LFM3-Omni-2B 能读取图像，但它是一个 2.17B 模型在读取：其卡片报告 OCRBench 806、DocVQA 92.47 和 MMMU 42.44，而 MMMU-Pro 低至 27.28。对于这个规模来说，这些数字相当可观，但在困难的文档版式上无法与 35B 模型竞争。如果任务是密集表格和扫描表单，那么即使不考虑使其运行成本低廉的 8-of-256 路由，更大的模型也会在这项任务上胜出。

在数字耗尽之处

令人不安的是：并不存在一份可靠的直接对比表，因为 OpenBMB 是以图表图片而非数值表格的形式发布 MiniCPM-V 4.7 的结果。35B-A3B 的模型卡中没有 MMStar、MMMU 或 OCRBench 的数据可供引用。任何在该列中填入数字的内容，要么来自 1B 的同系列模型——一个架构不同的不同模型——要么是编造的。

相比之下，LFM3-Omni-2B 的卡片则是一张完整的表格：MMStar 55.67、MMMU 42.44、MMMU-Pro 27.28、MMBench 73.68、SEEDBench 75.07、RealWorldQA 66.54、MathVista 62.50、POPE 89.34、DocVQA 92.47、InfoVQA 64.08、OCRBench 806、MVBench 58.03、Video-MME 57.70，另有一列语音指标，从英语 ASR 的 6.36 词错误率到 TTS 的 UTMOSv2 3.80。所有这些均由 Liquid AI 测量，使用每个对比模型自己的聊天模板和贪心解码，且其中没有任何一项被复现。

供应商对比表优于供应商对比图，但它并不等同于独立评测。这两个模型都没有独立评测。这就是目前整个小型全模态（small-omni）品类的现状，也正是为什么部署约束最终比 MMMU 上的一个百分点更重要。

许可证，请在原型交付前阅读

MiniCPM-V 4.7 采用 Apache 2.0 许可。没有营收门槛测试，没有使用领域条款，也无需谈判。LFM3-Omni-2B 采用 LFM Open License v1.0，也就是 Liquid 在整个 LFM3 系列上适用的营收阈值许可。对于业余项目或早期初创公司来说，两者在实践中并无差别。而对于已经越过该阈值的公司，其中一个需要与律师谈一谈，另一个则不需要——而这场谈话，现在进行要比模型已经进了产品之后再谈便宜得多。

这是比较中最不起眼的一个维度，也是最有可能在实际企业中起决定性作用的一个维度。

这两者如何融入同一架构

对大多数团队来说，现实的答案并不是“只选一个”。而是：常见情况用端侧模型，端侧模型处理不好的请求交给托管模型。让后一半保持可移植，才是设备模型更换后仍能存活下来的部分：OrcaRouter 提供一套 API，覆盖 200+ 托管模型，按提供商标价 0% 加价，提供商掉线时自动故障转移，还有一个路由 DSL，无需改代码就能把请求转到其他模型。LFM3-Omni-2B 和 MiniCPM-V 4.7 都不在该目录中——两者都是权重下载，本文也并非在暗示相反的情况。关键在于，回退层不应每次设备层变化时都重建；而设备层每隔几周仍在变化，所以它必然会变。

要把哪一个放到设备上

如果你需要视觉质量、一种真正可部署的量化格式、Apache 2.0，以及一个已有六周实地报告积累的生态系统，就选择 MiniCPM-V 4.7 35B-A3B。它的下载量并不是质量信号，但伴随 289,000 次下载而来的 bug 报告，是 LFM3-Omni-2B 目前尚不具备的一种测试形式。

如果产品需要语音功能，如果设备内存受限到连 3 GB 的活跃权重都仍然太多，或者如果你想要一个检查点而不是 ASR + LLM + TTS 技术栈，就选择 LFM3-Omni-2B。接受较小模型的视觉评分、营收门槛许可证，以及你是该模型发布仅一天后的早期采用者这一事实。

能定论的是单次独立运行——同一套测试框架、两个模型、OCRBench 和 MMMU，以及一个语音任务。还没人做过。在有人做之前，诚实的排名是：MiniCPM 擅长看，LFM3-Omni 擅长说，其他一切都交给电子表格。