MiniCPM-V 4.7 对比 WeVisOne-VL-4B：一段文字还是一个多边形

在 MiniCPM-V 4.7 和 WeVisOne-VL-4B 之间做选择，最快的方法是看它们各自输出什么。WeVisOne-VL-4B 返回坐标：归一化到千点网格的边界框、点、实例掩码，以及由外挂在 Qwen3-VL 主干上的 960 万参数解码器生成的全分辨率 alpha 遮罩。MiniCPM-V 4.7 返回句子，成页的句子，上下文窗口为 262,144 个 token，足以容纳一段视频。其中一个是接入流水线的感知组件，另一个是你向它提问的阅读器。两者都是 Apache-2.0 许可，都来自中国实验室，都于 2026 年 10 月发布，几乎未获英文行业媒体报道，而且它们几乎不属于同一产品类别。

两者的登场方式截然不同。腾讯微信视觉团队于2026年10月22日在Hugging Face和GitHub上发布了WeVisOne-VL-4B，同时附上一篇arXiv论文和一个2B的兄弟模型，既没有博客文章，也没有新闻稿。OpenBMB于10月6日和7日上传了MiniCPM-V 4.7，在其代码库中将发布日期标注为10月12日，并于10月15日通过英文PR Newswire新闻稿对外公布，但由此产生的英文行业报道少得惊人。一个以代码库的形式登场；另一个则是代码库加一份通讯社稿件。大多数对二者的比较，在把数字搞错之前，就已经把类别搞错了。

同一个问题的两个答案

WeVisOne-VL-4B 是 Qwen3-VL 的微调版本，以 token 形式输出几何信息。框和点被编码为 0 到 1000 的十进制 token，并按图像归一化；每预测一个框后，模型会输出一个特殊 token，其隐藏状态会输入一个单独的掩码解码器：一个视觉特征适配器、六个可变形交叉注意力模块，以及一个级联头，在步长四、二和一上逐级细化。最终得到实例掩码；对于抠图任务，还会得到全分辨率 alpha 通道。整个流程中没有第二个模型，也不调用 SAM；附着在语言模型上的整个像素路径参数量不足一千万。该模型为 bfloat16 精度下的 48.3 亿参数，模型卡将其四舍五入为 5B；它每轮接受一张图像——视频网格会被像素解码器直接拒绝。

MiniCPM-V 4.7 是一款提供两种尺寸的通用模型。35B-A3B 在 256 个专家中存储了 352 亿参数，每个 token 路由 8 个专家，激活参数约为 30 亿，并支持 262,144 token 的上下文，可接受单图、多图和视频输入。1B 则是一个 15.5 亿参数的稠密模型，上下文长度相同，BF16 检查点为 3.1 GB。两者共享一个 27 层的 SigLIP2 视觉塔，采用 4× 与 16× 混合视觉 token 压缩，正是这一机制让 25 万 token 的上下文得以保持可负担。两者都不具备指向、检测或分割原语。你可以问其中任何一个猫在哪里，得到的会是对猫所在位置的描述。

这种差异并非表面功夫。它决定了你的下游代码解析的是 JSON 还是散文，决定了一个糟糕的答案是会大声报错还是悄无声息地失败，也决定了这个模型能否与任何其他组件组合使用，而无需再引入第二个模型来修正它的输出。

数字，以及潜伏其中的范畴错误

以下所有数据均为厂商自报。腾讯的数据来自论文和 README，对比集由作者选定，且没有第三方复现。OpenBMB 的数据来自厂商模型页面，以文字说明和图表图片而非数值表格的形式发布。两家实验室都没有在共享测试框架上为这些模型提供独立评分。

• 检测，LVIS F1 —— WeVisOne-VL-4B 为 55.3，而作者列出的最佳基线为 50.7。MiniCPM-V 4.7 未公布检测数值。

• 密集检测，Dense200 F1——WeVisOne 为 71.3，最佳基线为 58.7，未修改的 Qwen3-VL-4B 为 15.2。最后一行是论文中最有意思的部分：正是微调将一个通用模型变成了定位器。

• 引用指代，RefCOCOg 测试 F1——WeVisOne-VL-4B 为 81.8，而作者列出的最强基线为 77.6。你首先应该关注的是它在目标缺失查询上的拒绝率：RefCOCOg-Rej 上为 67.4%，内部 WeRef-Bench 上为 96.4%，PR-Bench 上为 52.6%。同一个模型，三个不同的答案，因为数据分布不同。

• 计数，PixMo-Count——89.6 对 82.8。分割，ReasonSeg val gIoU——71.2 对 65.0。

• 抠图方面，P3M-500-NP 的平均绝对差为 7.3 对 15.4，数值越低越好，这大约相当于作者所对比的最佳专用抠图基线误差的一半。

• 阅读、OCRBench——MiniCPM-V 4.7 35B-A3B 为 91.2，1B 版本为 86.1，而 WeVisOne-VL-4B 的 TotalText F1 为 52.0。

最后一条才是陷阱。OCRBench 衡量的是文本识别；TotalText F1 衡量的是文本定位。把 86.1 和 52.0 放在一起，并宣称领先 34 分，这是范畴错误，而且这种错误会从一篇对比文章被照搬到下一篇。诚实的说法是，这两个模型并未在同一任务上接受测试，这些数字唯一能证明的是：MiniCPM 是为转写而构建的，WeVisOne 是为定位而构建的。

内存才是真正的代价

WeVisOne-VL-4B 是一个 9.66 GB 的 bfloat16 检查点（不含其掩码解码器），腾讯并未提供量化版本。对比卡片上的 19 GB 数字是同一检查点转换为 F32 后的结果，体积因此翻倍；无论哪种情况，你仍然需要自定义推理代码：mask_decoder.pt 是必需组件，而非可选附加项，用原生 Transformers 加载只能得到边界框和文本，得不到掩码。文档给出的部署路径包括项目自带的推理包（封装了 Transformers 后端或 vLLM 后端）以及一个 Gradio 演示；评估设置采用贪心解码，每张图像最多 1,960 个视觉 token。这是一个 GPU 服务。

MiniCPM-V 4.7 35B-A3B 的 BF16 权重约为 70 GB，分布在十六个分片中；这在纸面上更差，但在实际中更好，因为每个 token 只有约 30 亿参数处于激活状态。OpenBMB 的整套卖点在于，未激活的专家可以从存储中流式加载，而不必常驻内存；它使用 Lookahead Expert Scheduling 预取下一层可能需要的专家，再加上逐层量化和 DSpark 推测解码。厂商声称，在 iPhone 17 Pro Max 上使用约 3 GB 内存时，速度可达每秒 13 个或更多 token。目前还没有独立第三方复现这一结果，而且该声称依赖于这三种技术协同工作，而非其中任何一种单独生效。

1B 完全改变了经济性：BF16 下为 3.1 GB，Q4_K_M GGUF 下约为 0.67 GB，这正是 esp32-eye 猫咪监控器能在 MacBook 上运行它、并作为最多每 1.5 秒触发一次的门控的原因。同一构建还发现，1B 在区分四只相似猫咪时并不可靠，因此它更像是一个存在检测器，而不是细粒度识别器——对于任何打算把它当作廉价分类器使用的人来说，这是一个有用的边界。

直白地说：WeVisOne 用 9.66 GB 加一块 GPU 换来几何能力。MiniCPM 则用 70 GB 或 3 GB（取决于你选哪个尺寸）换来阅读能力，而且如果 OpenBMB 的调度说法成立，还能在手机级运行时上跑起来。

生产环境中会出现什么故障

WeVisOne 的失效模式已有文档记录且具体明确。Alpha 在精细边界、严重遮挡和真正透明的材质上质量会下降。该模型对提示词措辞敏感，因此“the woman's hair”和“her hair”不保证返回相同的蒙版。它无法处理视频，也没有思维链，因此无法让它先对模糊查询进行推理再确定边界框；而其拒识行为存在一个薄弱点，被论文的头条数字掩盖了：在 WeRef-Bench 上为 96.4%，但在 PR-Bench 上约为 52.6%。一个在大多数情况下能拒绝缺失目标的组件是有用的；但在另一种分布上只有一半时间能拒绝的组件则需要加一道防护。

MiniCPM-V 4.7 的失效模式是通用模型式的：无论描述是否有依据，它都会流畅地描述一张图像，而且完全没有拒答通道。卡片中没有任何内容能告诉你模型何时不知道。对读者来说这尚可接受——人读的是段落。对需要输出边界框的流水线来说，这是不合格的，因为那意味着你要把散文解析成坐标，然后寄希望于运气。

如果你本周需要的是托管的通用视觉模型，而不是自托管的专用模型，那么这两者都不在 OrcaRouter 的目录中，在推介之前值得说明这一点：实际可行的路线是使用一个托管的通用模型，通过一个密钥即可调用 200 多个模型，按提供商标价 0% 加价，并在上游端点不稳定时自动故障转移。这样你能得到一条可用的流水线；但它不会给你 alpha 遮罩，而且它与本页所讲的两个模型中的任何一个都是不同的产品。

在两者之间选择

如果你的输出是几何信息——统计零售货架上的物体数量、从照片中抠出商品、为用户高亮某个区域，或者在目标不存在时拒绝——那就选 WeVisOne-VL-4B。它的抠图数值确实不寻常，拒绝通道是真正的工程特性，而 9.66 GB 则是这个能返回程序可用结果的组件的代价。

如果你的输出是理解：一份长 PDF、一个仪表盘、一段视频、一页图文混排的内容，那就选 MiniCPM-V 4.7 35B-A3B。如果你需要在更昂贵的模型前面加一道廉价的闸门，那就选 1B，但别指望它分辨两只相似的猫。

真正能解决这个问题的对比目前还不存在：一个独立的评测框架，在相同的检测和 OCR 数据集上、以相同的图像预算运行这两个模型。在有人发布这样的结果之前，站得住脚的立场就是那个最不起眼的立场——这些模型做的是不同的工作，厂商的表格并不重叠，而唯一应该影响你决策的数字，是你必须部署的那个东西的大小。