LFM3-VL-2B 对比 MiniCPM-V 4.7 35B-A3B：并非模型的那一列

打开LFM3-VL-2B 的基准测试表，你就会看到一列 MiniCPM。它标注为 MiniCPM-V 4.7 1B。那是它的小兄弟。大多数人说到 MiniCPM-V 4.7 时，指的是 OpenBMB 的 MiniCPM-V 4.7 35B-A3B，也就是 MiniCPM-V 系列中第一个混合专家（MoE）检查点——它根本不在 Liquid AI 的表中，而且在两家实验室各自公布的基准测试上，它和 1B 相差甚远。所以，人们实际在权衡的对决——LFM3-VL-2B 对 MiniCPM-V 4.7 35B-A3B——只能从两张共享基准名称、但评估框架不同的厂商表格中手工拼装出来。下面就是这次拼装，接缝保留可见。

规模差异是第二重意外。一个模型拥有 19.2 亿稠密参数，只需几 GB 就能装下。另一个模型存储 352.1 亿参数，但每个 token 只触达其中约 30 亿。若只看规格表，这根本算不上对等较量；但若把它看作对同一个问题的两种回答——你能在无法控制的设备上运行什么——那它就是一场关于如何实现目标的、真正有趣的分歧。

两个模型，一个名字

命名冲突正在严重损害人们对这项对比的解读。Liquid AI 的模型卡对此十分严谨：列中写的是 1B，而这个 1B 对于 1.92B 模型来说是合理的同级比较对象。但搜索结果、聚合器和随意提及都把“MiniCPM-V 4.7”归为同一个东西，而 35B-A3B 才是真正拥有受众的变体——截至 2026 年 10 月 28 日，它在 Hugging Face 上有 289,535 次下载和 1,095 个赞，相比之下，同系列 1B 版本只有 155,428 次下载和几百个赞。

日期能解释这一差距的一部分，却不能解释其余部分。OpenBMB 的 35B-A3B 仓库创建于 2026 年 10 月 7 日，而项目自身材料中标注的发布日期为 10 月 12 日。Liquid AI 的 LFM3-VL-2B 仓库于 10 月 19 日上线，LFM3 系列于 10 月 27 日发布。LFM3-VL-2B 公开上线仅九天，因此其 255 次下载是日历上的事实，而非定论。更值得关注的是点赞比例：LFM3-VL-2B 为 45，MiniCPM 为 1,095。下载后者的人喜欢它，并且愿意说出来。

每一个实际上是什么

• 参数 — LFM3-VL-2B 为 1.92B 稠密模型：包含 1.73B 语言主干、164M 自研视觉编码器和 25M 投影器。MiniCPM-V 4.7 35B-A3B 在 256 个专家中存储 35.21B 参数，每个 token 路由其中 8 个专家，约 3B 激活参数。

• 主干 — 24 层 LFM3，拆分为 13 个门控短卷积、5 个滑动窗口注意力层和 6 个全局注意力层，相比之下，隐藏大小为 2,048 的 Transformer 层有 40 层。

• 视觉路径——一个 14 层编码器，由 8 个门控逐通道二维卷积和 6 个双向注意力层组成，作用于 16×16 图块并采用二维旋转嵌入；相比之下，一个隐藏维度为 1,152 的 27 层塔被插入文本栈的第 6 层，编码器内部进行早期 token 压缩，并支持可切换的 4× 或 16× 视觉下采样。

• 上下文——在 LFM3-VL-2B 上为 128K 个 token，在 MiniCPM 上为 256K 个 token，两者均包含输入和输出。

• 输入——Liquid 模型支持文本、图像以及每秒 2 帧的视频；OpenBMB 模型支持文本、图像和视频。两者都不支持音频，无论输入还是输出。

• 磁盘上的权重——在 BF16 下约为 3.8 GB，而在 BF16 下约为 65.6 GiB。

• 许可证 — LFM Open License v1.0，Liquid 将其描述为年收入低于 1000 万美元可免费商用，而 Apache 2.0 则没有收入条件。

架构上的分歧才是关键所在。Liquid 押注：小型稠密模型加上专用视觉编码器，在每图像计算量上胜过 SigLIP 风格的塔式结构，并发布了一张类别表来证明这一点。OpenBMB 押注：可以让 35B 模型的能力保持不变，同时通过让昂贵的部分以流式方式运行而不是常驻，仍能在手机上运行。两者都是关于内存的押注，只是方向相反。

差距确实存在，而且比这种说法所暗示的要小。

把对应的行并排放在一起时，两张厂商表格是这么说的。所有内容都由实验室自行报告，测试框架的注意事项在后面。

• MMMU — LFM3-VL-2B 开启思考时 55.7，关闭时 48.6；MiniCPM-V 4.7 35B-A3B 在 4× 视觉压缩下为 80.22，在 16× 下为 80.00。

• MMStar — 74.4，对比 4× 时的 80.67 和 16× 时的 80.13。

• OCRBench v1 — 86.3，而 4× 时为 91.20，16× 时为 90.40。

• MathVista — 启用思考时为 84.2，未启用时为 68.5，相比之下 4× 时为 88.00，16× 时为 87.30。

• CharXiv 推理 — 4× 下为 70.2，对比 75.60；16× 下为 69.20。

MMMU 正是 35B 彰显其规模价值的地方：相比思考模式配置高出 24.5 个百分点，相比非思考模式配置高出 31.6 个百分点。这是大学水平的多模态推理基准，而这一差距足够大，足以经受住任何关于评测框架差异的合理质疑。

其他所有项目的差距都比这种叙事框架所暗示的更小。OCRBench 相差 4.9 分。LFM3-VL-2B 在思考时，MathVista 相差 3.8 分。在 CharXiv 推理上，Liquid 模型在思考模式下落后 5.4 分——还以 1 分优势超过了 35B 的 16× 数字。一个 2B 模型在文档 OCR 和图表上距 35B 不到五分，这一发现应比 MMMU 头条获得更多关注。

不过，注意事项也很重要，因为它们确实有影响。Liquid 的数据来自在 vLLM 0.27.1 上对 62 个基准的一次单次运行，并归一化到 0–100；除另有标注的配置外，所有模型都启用了推理模式。OpenBMB 的五个数字是以图表图片而非数值表格的形式发布的，这里是根据第三方聚合器对这些图表的解读转写而来的，因此请将这些小数视为近似值。两家实验室在视觉 token 预算、提示词或解码设置上并不一致，而 OpenBMB 一侧的 4× 与 16× 划分本身就会使其分数变化最多达六分。这只是两组主张并列放在一起，并非受控实验。

在小模型有数据的地方，大模型并不公布。

Liquid 公布了 62 行。OpenBMB 公布了 5 行。这种不对称是本次对比中最少被提及的事实，而且它偏向有利于较小模型的方向。

• 视觉定位——LFM3-VL-2B 的 RefCOCO-avg 为 90.5、RefCOCO-M 为 95.2、Point-Bench 为 73.8、RefSpatial-Bench 为 49.8。MiniCPM-V 4.7 35B-A3B 已发布的评测中没有出现对应的行。

• GUI 理解 — ScreenSpot-Pro 55.5，ScreenSpot-v2 在桌面端为 94.6、移动端为 92.2、网页端为 89.9。同样，OpenBMB 方面没有发布任何内容。

• 具身推理——EmbSpatial-Bench 82.9、RoboSpatial-Home 63.4、Where2Place 44.9。同样缺失。

• 视频——Video-MME 62.8（无字幕）、MVBench 69.4、MLVU 71.3、ActivityNet-QA 71.2。MiniCPM-V 4.7 支持视频，卡片也对其进行了详细讨论，但数值表中没有可供我们核实的视频行。

这是证据缺失，而非默认胜出。如果你正在构建机器人或屏幕智能体流水线，诚实的判断是：35B 在这些任务上的能力是未知的，而不是弱。但“未知”本身就是一个采购难题：你无法围绕一个没人公布过的数字来规划部署，而 LFM3-VL-2B 是两者中唯一一个能在下载前就了解其 grounding 和 GUI 性能的模型。

记忆论证是一把双刃剑。

选择 2B 而不是 35B 的常见理由是，2B 能装得下。LFM3-VL-2B 确实能装得下，而且完整、可预测：在 BF16 下约 3.8 GB，常驻内存，无需分页，设备处于负载状态时也不会有意外。对于要交付到无法控制的硬件上的产品来说，这是一个真正强大的特性。

MiniCPM-V 4.7 35B-A3B 高达 65.6 GiB，根本不可能装进手机，OpenBMB 的整套设计正源于此。Lookahead Expert Scheduling 会预测下一层的路由，并预取它预计会用到的专家；细粒度逐层量化会缩小这些专家，使它们移动得更快；DSpark 推测采样则弥补了解码停滞。厂商宣称，在 iPhone 17 Pro Max 上使用约 3 GB 内存时可达每秒 13 个以上 token，而在配备 16 GB 内存的 iPad Pro M4 上可达每秒 17 个以上。

所以，端侧主张并不是“35B 很小”，而是“35B 能以流式方式运行，而且流式运行足够流畅、可用”。这是两种不同的押注，失败模式也不同。一个常驻的 3.8 GB 模型会优雅降级——它要么已加载，要么未加载。一个流式运行的 65.6 GiB 模型则会因闪存带宽、热节流和冷启动延迟而性能下降，而这些都会因设备而异，单台 iPhone 上的基准测试无法捕捉。

实际的分界线在于：如果你既无法控制存储速度，也无法控制散热余量，那么常驻方案就是风险更低的路径。如果你面向的是近期的旗舰硬件，并且想要那份额外的精度，那么 OpenBMB 的做法已不再是理论——它已经是一个发布了的模型，背后还有一个可用的 fork。

首日工具并非平局。

LFM3-VL-2B 提供需要 transformers 5.21 或更新版本的 BF16 权重，以及 GGUF（其中包含一个量化感知蒸馏的 Q4_0 检查点）、一个 MLX 4 位构建和一个 ONNX 导出。服务器支持尚未完成：vLLM 被描述为正在进行中，SGLang 在拉取请求 46858 中处于审核状态，llama.cpp 在拉取请求 31252 中处于审核状态，并明确注明尚不支持视频输入。模型卡还建议为 vLLM 和 SGLang 使用 qwen3 推理解析器和 qwen3_coder 工具调用解析器，这一细节表明它是最近才接入的。

MiniCPM-V 4.7 35B-A3B 支持 SGLang、vLLM、llama.cpp 和 Ollama，并可通过 SWIFT 和 LLaMA-Factory 进行微调，提供 GGUF、BitsAndBytes、AWQ、GPTQ、FP8 和 int4 构建版本，还对来自 Rockchip、Houmo、Intel、AMD 和 Arm 的芯片平台提供零日支持，覆盖 iOS、Android 和 HarmonyOS。端侧路径通过 OpenBMB 自有的 llama.cpp-omni 分支运行，而非上游 llama.cpp。

对于本月就要上线的生产部署来说，这根本无需纠结。对于探索性研究、笔记本演示，或者你打算自己维护的微调，LFM3-VL-2B 现在就能通过 transformers 使用，而且你不会在构建标志上耗掉一周。

更多团队会栽在这条许可条款上

Apache 2.0 与 LFM Open License v1.0 之间的差异，在实际层面比 MMMU 的差距更大，因为它适用于每一次部署，而不只是那些困难情形。Apache 2.0 不附带收入条件，没有使用领域限制，也不存在量化或蒸馏衍生作品是否继承条款的模糊之处。按 Liquid 自己的说法，LFM Open License v1.0 对年收入低于 1000 万美元的商业使用免费，这意味着超过该门槛的公司在发布前就要进行许可沟通，而不是发布后才谈。

这一条款让许多买家的比较格局重新洗牌。低于门槛的初创公司不花一分钱，就能得到一个更小、更快、在 grounding 方面文档更完善的模型。超过门槛的公司得到的模型则需要签字——这时，35B 的 Apache 2.0 就成了你会开始留意的一项特性。

两家厂商都不会告诉你的事

没有独立的正面直接对比。没有任何第三方实验室在同一套评测框架上运行过这两个模型，而最接近中立排行榜的东西——Liquid 自己的表格——比较的是 LFM3-VL-2B 与 1B，而不是 35B。本文中的每一个数字都来自构建其所描述模型的那家实验室。

还有两个缺口值得指出。两个模型都没有我们能核实的按 token 计价的价格，因此在这里做成本比较只能是凭空编造。而且截至 2026 年 10 月 28 日，两者都不在OrcaRouter 目录中——搜索 minicpm 不会返回任何匹配的模型，LFM3-VL-2B 也未被列出。这使得如今这是一个自托管或使用供应商 API 的决定，而不是路由决策。

该选哪一个

• 文档、图表、密集文本和困难的多模态推理，搭配一套由你掌控的服务栈——MiniCPM-V 4.7 35B-A3B。MMMU 上的领先幅度是唯一大到足以经受评测框架种种保留条件的结果，而 Apache 2.0 则彻底消除了许可问题。

• 一台你无法控制的设备，内存预算固定，且无法容忍流式传输延迟——LFM3-VL-2B。常驻占用 3.8 GB，并且是两者中唯一具备已公布的 grounding、GUI 和具身数据可供规划参考的模型。

• 屏幕代理、机器人和空间任务——默认使用 LFM3-VL-2B，因为它是唯一有已发表证据支持的一方。在这些任务上，应将 35B 视为尚未得到验证，而不是能力不足。

本月即可投入生产，集成工作量极小——MiniCPM-V 4.7 35B-A3B。支持 SGLang、vLLM、llama.cpp 和 Ollama，对应三条“审核中”或“进行中”的备注。

• 年营收超过 1000 万美元的公司——MiniCPM-V 4.7 35B-A3B，除非端侧限制足够严苛，足以成为进行授权洽谈的理由。

说实话，OrcaRouter 到底适合放在哪里

这还不合适，而如果反过来说，那正是会让一篇博客文章被无视的做法。目前这两个模型都不在 OrcaRouter 的目录中，所以既没有可交给你的密钥，也没有可报的价格。

真正重要的是，当视觉模型真的接入那里时会发生什么：一个兼容 OpenAI 的端点覆盖 200 多个模型，供应商标价以 0% 加价透传，因此厂商调价当天即可生效；并具备自动故障转移，所以单一供应商宕机不会让你的路由中断。对于这样的比较——两个模型在记忆方面各执一词，又没有独立基准测试来定论——有用的做法是把两者放在同一个端点后面运行，并用自己的图像进行测量，而不是争论谁家的图表是对的。

看什么

有四件事会改变这篇文章。拉取请求 31252 合并并加入视频支持，这会让 LFM3-VL-2B 的视频路径进入标准 llama.cpp。vLLM 支持不再处于“进行中”，这会使其成为严肃的模型服务选项，而非演示。用同一套测试框架对两个模型进行独立评估——这是本对比中最有价值的缺失材料。以及 Liquid AI 将 35B 加入其自己的对比表，这会告诉你该实验室认为它才是真正的同级对手。

在这些中的任何一项落地之前，站得住脚的总结比两家厂商的任何一种说法都更狭窄：35B 赢下真正重要的推理基准，在 OCR 上毫无损失；2B 赢在 grounding 证据与可预测性上；而许可证比基准决定更多部署。