WeVisOne-VL-2B 与 MiniCPM-V 4.7 1B：相差 0.45B，各司其职

名字暗示着二比一的差距，检查点却并非如此。MiniCPM-V 4.7 1B 以 bfloat16 精度发布，包含 1,554,476,272 个参数，WeVisOne-VL-2B 则约为 20 亿——因此两者之间的真实距离大约是 4.5 亿个参数，而非 10 亿。把它们放在同一块磁盘上，占用的空间不相上下。把它们放到同一个任务上，二者就彻底分道扬镳了，因为 MiniCPM-V 4.7 1B 是为阅读文档、观看视频并围绕其展开对话而打造的，而 WeVisOne-VL-2B 则是为找到某个物体并回传一张掩码而打造的。

两者均采用 Apache 2.0 许可。两者都足够小，能引起在单块 GPU 上构建之人的兴趣。两者都是近期发布的——MiniCPM-V 4.7 1B 于 2026 年 10 月 6 日上传，并在 OpenBMB 的发布说明中标注为 10 月 12 日；WeVisOne-VL-2B 则是在 10 月 22 日。正是这种相似与差异的结合，让这一对模型值得单独写一页：几乎所有核心规格都很接近，而几乎每一个实际用途却并非如此。

首先，名称已更正

OpenBMB 的命名相当随意，已在对比表中造成混淆。名为 1B 的模型根据其自带的 safetensors 元数据拥有 15.5 亿参数；厂商材料在不同地方分别引用过 1.3B 和 1.38B。262,144 token 的上下文是真实的，并已在模型配置中设定。其架构是一个 24 层、隐藏维度为 1024 的文本主干，源自 Qwen3.5，采用线性注意力与全注意力 3:1 的模式，并搭配一个 27 层、SigLIP2 风格的视觉塔，工作在 980 像素的图块上；此外还有可选的 4× 或 16× 视觉 token 压缩模式，以细节换取单次请求成本。

腾讯的命名更为严谨。WeVisOne-VL-2B 是一个基于 Qwen3-VL 构建的 20 亿参数模型，另配一个独立的 9,511,460 参数像素解码器，模型卡片称其为"必需的核心组件，而非可选附加项"。在部署层面，这个解码器绝不是可以忽略的零头：没有它，模型只能输出边界框和点，掩码或抠像（matte）输出则一概不存在。

所以正确的表述框架不是小与大，而是 1.55B 与 2B——权重相差 29%——且两者的输出契约完全不同。

两套永不相交的基准词汇表

这是大多数对比容易出错的地方，因此在任何数字出现之前都值得先说明。OpenBMB 在通用多模态基准上评估了 MiniCPM-V 4.7 1B：OCRBench 86.1、MMMU 56.89、MathVista 74.30、MMBench 83.17、MMStar 69.53、MMMU-Pro 38.03、MathVerse 60.41、CharXiv Reasoning 48.8、LongVideoBench 53.4 和 MotionBench 54.55。这些是厂商自行运行得出的数据，大多以图表而非包含评测框架细节的表格形式呈现，且尚无独立机构复现这些结果。

腾讯在感知基准上评估了 WeVisOne-VL-2B，却完全没有报告任何通用多模态分数。在它的七张表格中，任何地方都没有 MMMU、没有 MMBench、没有 MathVista、没有 DocVQA，也没有 captioning 结果。它转而报告的是任务特定指标：检测 F1、计数精确匹配、指向 F1、OCR 定位 F1、分割 cIoU 和抠图误差。

这种冲突在 OCR 上最为尖锐，因为两个模型都声称具备这项能力。MiniCPM 的 86.1 是 OCRBench——一个转录分数，考察的是模型是否把字符读对了。WeVisOne 的 OCR 数字则是 0.5 IoU 阈值下的定位 F1：在 SROIE 上为 62.1，在 ICDAR2015 上为 42.6，在 TotalText 上为 42.5，在 HierText 上为 30.5，衡量的是模型是否在文本周围画出了正确的框。一个模型可以在一项上表现出色，在另一项上却表现平平。打印出“86.1 对 62.1”，就像拿拼写测试和指认测试作比较。

没有任何一个基准测试能让这两个模型都报告一个以相同方式计算出的数字。这不是修辞上的夸张——这是本次比较的核心发现，这意味着你看到的这两个模型的任何排名，都是由不可通约的部分拼凑而成的。

262,144 个 token 能换来什么，以及 WeVisOne 不会说的事

MiniCPM-V 4.7 1B 发布了 262,144 个 token 的上下文，以及一条默认最多接受 128 帧的视频路径，每帧一个切片。这是一台文档与视频处理机器：长 PDF、多页扫描件、一分钟的影像。4× 和 16× 压缩切换之所以存在，正是因为保留那么多视觉细节代价高昂，而 OpenBMB 让你可以按每次请求选择要保留多少细节。

WeVisOne-VL-2B 未公布上下文长度。模型卡对此只字未提；论文中的训练阶段分别在 4,096 和 8,192 个 token 下运行，推理时采用贪心解码，每张图像上限为 1,960 个视觉 token。这些都不是部署窗口，腾讯也没有假装其中任何一个是。它还直接拒绝视频网格——像素解码器仅支持图像、单轮，且不支持思维链。

这种不对称说明了每家厂商各自优化的是什么。OpenBMB 优化的是一个模型能吞下多少输入。腾讯优化的则是一个模型能多精确地指向它所吞下的内容，然后围绕输入类型划出一条硬性边界，以保持解码器简单。

每一项实际运行的位置

MiniCPM-V 4.7 1B 的部署覆盖面明显更广，优势相当大：支持 Transformers 5.18 及更高版本、vLLM、SGLang、llama.cpp 和 Ollama，并提供 GGUF、AWQ、GPTQ、FP8、bitsandbytes 和 OpenVINO 构建版本，此外还支持 iOS、Android 和 HarmonyOS，并在首发当天就获得 Rockchip、Arm 和 Apple 等厂商的芯片支持。OpenBMB 还单独发布了一款 2.13 亿参数的 DSpark 草稿模型，用于投机解码。

WeVisOne-VL-2B 有自己的 GitHub 包、Transformers 路径，并在模型卡上列出了 vLLM 和 SGLang。没有 GGUF，没有量化构建，没有 ONNX，也没有移动端方案。而且其密集输出是步幅为 1 的全分辨率 alpha 蒙版，这意味着内存随图像而非参数数量扩展——一个 2B 模型持有成本低，但在 4K 下运行未必便宜。

如果你的目标是手机，那么这一节就结束了比较。MiniCPM 正是为这一限制而构建的，并在其格式列表中明确说明了这一点。WeVisOne 则不是，也没有声称自己是。

它们唯一打成平手的地方：许可证

两者均采用 Apache 2.0。没有收入门槛，没有使用领域限制，也没有单独的商业协议。在一个 Liquid AI 使用其自有收入上限许可证、Moondream 使用带有不授予第三方服务权限条款的源码可用许可证的类别中，这个规模的两个 Apache 2.0 视觉模型值得注意——这意味着许可证并不是这里的决定变量，而这已经足够不寻常，值得明确说出来。

这种持平也消除了团队选择较小模型的最常见理由。如果两者都通过了法律审查，那么你就是在根据能力和部署来做选择，而不是根据条款。

在两者之间选择

先问清楚输出要供给什么。如果它要供给文档存储、聊天窗口、视频索引或下游语言模型，那么 MiniCPM-V 4.7 1B 正是你想要的形态：它能生成长文本，能容纳长输入，并且以可在消费级硬件上运行的格式提供。

如果它要接入合成管线、图像编辑器、目录清理任务或感兴趣区域裁剪，WeVisOne-VL-2B 正是你想要的形态：框、点、二值掩码和连续 alpha 蒙版，外加一种比任何基准测试都更重要的拒绝行为。腾讯报告称，在 RefCOCOg 上针对缺失对象查询的拒绝率为 50.2，而同一表格中两个专用定位模型的拒绝率分别为 0.5 和 0.6。如果你的大多数图像并不包含你要找的东西，那么那个数字才是真正帮你省钱的那个。

还有第三种情况：它们不是相互竞争，而是相互组合——在一条文档流水线中，MiniCPM 读取页面，WeVisOne 找出读取步骤需要隔离的区域——签名、印章、产品照片。与其说这是路由问题，不如说是流水线设计问题，这也正是 OrcaRouter 产品真正有用、而非生硬附加的地方。这两个模型都不在我们的目录中；两者均为自托管，我们不会暗示并非如此。我们提供的是托管的那一半：超过 200 个模型，只需一个 API 密钥即可调用，按提供商标价且无加价，在提供商服务降级时自动故障转移，以及模型融合——它让一组模型共同回答同一个问题，当一条转录即将进入数据库、而你想在入库前再听取一个意见时，这很有用。

要记住的数字

不是 1B 和 2B——而是 1.55B 和 2B。命名让它们看起来像不同量级，检查点又让它们看起来像近邻，而这两种印象都具有误导性。将 MiniCPM-V 4.7 1B 与 WeVisOne-VL-2B 区分开的，不是规模、许可，甚至也不是新旧程度。而是一个返回文字，另一个返回像素；并且，任何一家厂商发布的基准测试都无法与另一家的相减，从而判断哪一个更胜任你实际需要的任务。