MiniCPM-V 4.7 对比 LFM2.5-VL 3B：一个 70 GB 的谜团，对阵一个能在笔记本上落地的 3B 模型

MiniCPM-V 4.7 和 LFM2.5-VL 3B 被宣传成同一类东西——你自己运行的紧凑型视觉语言模型——但在实践中，两者几乎天差地别。LFM2.5-VL 3B 是一个成品：来自 Liquid AI 的一个有文档记录的 31 亿参数检查点，有许可证、有模型卡、有已在社区流传的 GGUF 量化版本，而且不直接把它下载下来试试的好理由正越来越少。MiniCPM-V 4.7 则是一个 352 亿参数的稀疏混合专家检查点，由 OpenBMB 于 2026 年 10 月 6 日上传到 Hugging Face，没有模型卡、没有许可证，也完全没有任何基准测试结果。比较它们并不是在比较两个模型，而是在把一个模型与一个很可能最终会成为模型的产物进行比较。

这场对阵，开门见山地说

本页可以让你完整了解 LFM2.5-VL 3B，因为 Liquid AI 发布了完整资料。它也能让你完整了解 MiniCPM-V 4.7 的形态，而对其行为则一无所知，因为 OpenBMB 只发布了一份config.json便就此止步。下文关于 MiniCPM 一侧的所有内容，均读取自那份配置文件和权重索引；关于 Liquid 一侧的所有内容，则来自模型卡，而模型卡自身的性能声明属厂商自报，并已照此标注。当某个数字只存在于其中一个模型而另一个没有时，诚实的做法是让这一空白保持可见，而不是把它掩盖过去。

每一个是什么

LFM2.5-VL-3B 于 2026 年 8 月 11 日发布。它是 LFM2.5 家族的多模态变体，专为端侧部署打造，而且并非从零开始：它采用 LFM2.5-2.6B 语言主干，并搭配 SigLIP2 NaFlex 视觉编码器。NaFlex 对文档工作至关重要——它保留原生宽高比和分辨率，而不是把每张图像都强行变成固定方形，因此模型卡中突出的改进是基于自然语言查询的定位，以及带版面标注的全页 OCR。它基于 LFM Open License v1.0 发布，覆盖十六种语言，包括英语、中文、日语、韩语、阿拉伯语、印地语、法语、德语、西班牙语、葡萄牙语、意大利语、波兰语、俄语、泰语、越南语和印尼语。由于它是 3B 模型，GGUF 构建版本在发布后一天内就出现了，随后 9 月又推出了 DSpark 变体，因此围绕它的生态是真实存在的：你今天就能拉取一个量化版本，在笔记本电脑上运行。

MiniCPM-V 4.7 是一个拥有 35,212,875,824 个参数的 BF16 检查点，跨十六个分片共计 70.4 GB，类别为 MiniCPMV4_7ForConditionalGeneration，上传至 openbmb/MiniCPM-V-4.7-35B-A3B，时间为 2026 年 10 月 6 日。

其语言主干被标记为qwen3_5_moe_text——一种源自 Qwen3.5 的稀疏 MoE，拥有 256 个专家且每个 token 选择 8 个——其 40 层运行固定的三线性对一全注意力模式，因此 40 层中有 30 层使用 Mamba 风格的线性路径，而非传统注意力。上下文长度为 256K。视觉塔是 MiniCPM-V 系列自有的，形状与 MiniCPM-V 4.6 所用的大致相同。仓库中没有 README，这在 Hugging Face 上意味着没有许可证。

实际可行的比较

六个维度、双方，以及每一项关于该数字权重的说明。

• 总参数量——LFM2.5-VL 3B：3.12B，每个 token 全部激活。MiniCPM-V 4.7：总计 35.2B，稀疏，每个 token 激活 256 个专家中的 8 个。MiniCPM 的这一数字无法与稠密参数量相提并论，且实际激活参数量预算并未公布；应将“A3B”视为一个名称，而非一种测量结果。

• 磁盘上的有效大小 — LFM2.5-VL 3B：一个约 6 GB 的 BF16 safetensors 文件，或作为 GGUF 仅为其一小部分。MiniCPM-V 4.7：70.4 GB 分布于十六个分片，仅限 BF16。

• 许可证 —— LFM2.5-VL 3B：LFM Open License v1.0，已在模型卡上发布并提供链接。MiniCPM-V 4.7：未作声明。在缺少license:标签的情况下，默认立场为保留所有权利，因此这是一个阻碍项，而非脚注。

• 视觉方案 — LFM2.5-VL 3B：SigLIP2 NaFlex，原生分辨率并保持宽高比，卡片声称可实现带布局标注的全页 OCR。MiniCPM-V 4.7：自定义 minicpmv4_7_vision 视觉塔，搭配 downsample_mode: "16x" 和 max_slice_nums: 9。

• 上下文 — LFM2.5-VL 3B：与长上下文设计相比，该模型卡中的服务示例较为有限，且该系列面向端侧内存预算。MiniCPM-V 4.7： max_position_embeddings: 262144，分词器的 model_max_length也一致为 256K。

• 质量证据——LFM2.5-VL 3B：一份已发布的模型卡，其中列出了厂商自报的相较 LFM2-VL-3B 的改进、第三方量化版本，以及在 Hugging Face 上约 25,900 次下载的历史记录。MiniCPM-V 4.7：零下载、三个点赞、没有模型卡、没有基准测试、没有独立评估。无从引用。

• 工具链 — LFM2.5-VL 3B：第三方提供的 GGUF 和 MLX 构建，外加一个 DSpark 变体。MiniCPM-V 4.7：无。目前尚不存在任何形式的量化。

这一页缺失的三分之二

这个领域的每一篇对比文章都会附带一段基准测试说明。这一篇却做不到。MiniCPM-V 4.7 没有 MMMU，没有 OCRBench，没有 DocVQA，没有 grounding 数值，没有延迟测量，也没有 VRAM 数据——不是因为查起来不方便，而是因为仓库里没有任何东西包含这些，也没有任何第三方产出过它们。从评估的角度看，一个上传时没有模型卡的模型就是未被测量的。任何对你说不是这样的人，都是在根据家族名称或参数量进行推断，而这两者都是多模态质量的不良预测指标。

一个更微妙的问题也是如此：稀疏 MoE 是否真的有用。35B-A3B 设计是以总内存换取单 token 计算量，而稀疏模型的指令遵循质量完全取决于路由器的训练效果。配置显示路由辅助损失系数为 0.001，并且在 256 个路由专家之外还有一个共享专家，这是常规设置——但常规设置并不能证明路由效果良好。

在 Liquid 这一侧，缺失的环节有所不同：这款卡的质量说法出自厂商自己。

OCR 和 grounding 的改进是由训练该模型的人描述的；虽然第三方量化版本和下载量表明，社区觉得它足够有用，因而会将其转换，但这属于采用证据，而不是质量证据。还没有人发布过独立的直接对比。

你实际会选哪一个

这里的决策树异常清晰，因为这两个模型并不是在争夺同一个任务。

如果你需要一个能在笔记本电脑、手机、Jetson 或单块普通 GPU 上运行的视觉语言模型，LFM2.5-VL 3B 是两者中唯一能回答这个问题的。它小到足以量化，其许可证允许这项工作，而且已经有人替你完成了转换工作。对于在适合边缘预算的尺寸和语言占用范围内进行文档版面分析、截图解析和基于定位的物体描述，模型卡中所述的强项与部署目标相符。

MiniCPM-V 4.7 不是那份工作的候选者：在 BF16 下它要占 70 GB。它适合的是相反的工作：在服务器硬件上、在那些以 256K 窗口和线性注意力 KV 缓存节省为核心的负载中，充当长上下文、高吞吐的多模态模型。它能否把这份工作做好尚不可知；而在任何商业场景中让它真正承担这份工作之前，许可证问题必须先有答案。

还有第三种值得点明的选择，那就是你或许并不需要做选择。如果架构是“由一个小型本地模型处理大部分流量，把困难的情况交给托管服务”，那么其中本地那一半是你今天就能做出的决定，而托管那一半则是一个路由决策。OrcaRouter 以一个密钥覆盖数百个托管模型，按各服务商的标价计费、不额外加价，并在某个服务商性能下降时进行故障转移——但要说清楚它不是什么：LFM2.5-VL 3B 和 MiniCPM-V 4.7 都不是该路由器上的托管模型。两者都是你自己部署的权重。路由器是位于它们背后的那一层。

目前状况如何，以及需要刷新什么

Liquid AI 发布了一个已完成的小模型。OpenBMB 发布了一个尚未完成的大模型。读者想要的那种对比——准确率对延迟，OCR 对 OCR——在 MiniCPM 这一侧目前还写不出来，而用参数量算术来填满篇幅，才是真正不诚实的做法。请留意该仓库的 README。它出现的那一天，就会带上许可证和第一批真实数据；到那一天，这就变成一场真正的正面对决，而不是一份规格表配一个产品。

该模式中托管的那一半是一个路由决策，而非第二份合约。各提供商自身的标价，我们不额外加价LFM2.5-VL 3B 和 MiniCPM-V 4.7 都不是 OrcaRouter 上的托管模型——两者都是需要你自己部署的权重。