WeVisOne-VL-4B 与 MiniCPM-V 4.7 1B：关于视觉 token 用途的两种截然相反的押注

MiniCPM-V 4.7 1B 在 OCRBench 上得分 86.1。WeVisOne-VL-4B 在 TotalText 上得分 52.0。把这两个数字并排放在一起，这个 1B 模型似乎在阅读文本方面比 4B 模型高出三十四分——这会是一个非凡的结果，同时也是一种范畴错误。OCRBench 衡量的是模型能否转写图像中的字符。而按腾讯报告的口径，TotalText 衡量的是在 0.5 到 0.95 的 IoU 阈值下对每个文本实例进行定位的 F1。一个是识别，另一个是几何。MiniCPM-V 4.7 1B 和 WeVisOne-VL-4B 于 2026 年 10 月相隔九天发布，均来自中国实验室，均采用 Apache 2.0，但它们在视觉 token 的用途上存在根本分歧：一个将其压缩掉，另一个将其用于精度。

这一分歧就是整个比较的全部。其余的一切——参数数量、内存、基准测试的各项数据——都由它而来。

压缩与精度

MiniCPM-V 4.7 1B 继承了 LLaVA-UHD v4 的 ViT 内部早期压缩方案，并将其作为运行时开关暴露出来，可在 4× 和 16× 视觉 token 压缩之间切换。重点是在固定预算内塞进更多图像和更多视频：模型卡声称支持 262,144 token 上下文、默认 128 视频帧，以及切片数量可配置的 448×448 分块方案。尽早压缩、保持序列简短，1B 模型就能在手机上处理长视频。

WeVisOne-VL-4B 做出了相反的权衡。它的评估在每张图像最多 1,960 个视觉 token 下运行，其像素解码器基于合并前的 ViT 特征运行，刻意保留早期压缩所丢弃的高分辨率细节。这就是为什么它能在步长 1 下生成全分辨率 alpha matte，也是为什么它完全无法处理视频网格：解码器会拒绝它。精度以 token 为代价，而 token 又以延迟为代价。

两种押注都没有错。它们回答的是不同的问题。MiniCPM 问的是“在手机上我一次能看多少？”WeVisOne 问的是“我能多精确地描述一件东西在哪里？”

关于规模的说法，比 1B 与 4B 的对比还要离奇。

• 参数 — WeVisOne-VL-4B 4.83B 稠密模型 vs MiniCPM-V 4.7 1B 标称为 1B，尽管其仓库元数据在 BF16 下列为 2B

• 权重格式——F32 safetensors 约为 19 GB，而 BF16 约为 3.1 GB，或 Q4_K_M 下为 0.67 GB，另加 0.90–1.11 GB 的视觉投影器

• 上下文 — WeVisOne-VL-4B 未公布，而 MiniCPM-V 4.7 1B 纸面标称为 262,144 个 token

• 视频 — 被像素解码器拒绝，而默认情况下为 128 帧

• 多模态输入 — 每轮单张图像 vs 图像和视频

• 量化 — 厂商未提供任何量化版本，对比 int4、AWQ、GPTQ、GGUF 和 FP8 变体

• 设备端运行时——无 vs iOS、Android、HarmonyOS，以及 llama.cpp 和 Ollama

• 许可证 — 腾讯编写的代码采用 Apache 2.0，与 Apache 2.0 对比

内存这一行才是重新定义比较的关键。一个 1B 模型采用四位精度时，在不算视觉投影器的情况下占用不到 1GB；而一个 4.83B 模型采用 F32 精度则需要大约 19GB。它们并不是争夺同一位置的竞争对手。一个是你在应用内部交付的组件；另一个是你在 GPU 上运行的服务。

不自欺地解读基准测试行

两家厂商都发布了表格，而且两份表格都是自行挑选的。MiniCPM-V 4.7 1B 报告 OCRBench 86.1、MathVista 74.3、CharXiv Reasoning 48.8、LongVideoBench 53.4 和 MotionBench 54.55。WeVisOne-VL-4B 报告 LVIS F1 均值 55.3、RefCOCOg test 81.8、PixMo-Count test 89.6、TotalText F1 均值 52.0、ReasonSeg val gIoU 71.2 和 P3M-500-NP MAD 7.3。两份列表中没有一项基准同时出现。根据这些文档，没有任何站得住脚的方法可以计算出赢家，任何这样做的文章都是在编造结果。

公允的解读更狭窄，但仍然有用。MiniCPM-V 4.7 1B 在其尺寸级别上对图像进行推理的能力异常强——一个能装进手机的模型在 MathVista 上拿到 74.3，这是其作者最引以为豪的数字，而它是厂商报告的、尚未被复现。WeVisOne-VL-4B 在生成几何信息方面异常强——掩码、蒙版、边界框，以及在物体不存在时于 WeRef-Bench 上测得 96.4% 的拒识率。MiniCPM 的模型卡没有公布拒绝指标，WeVisOne 的模型卡没有公布推理基准。每个模型恰好在另一个模型高声量之处保持沉默。

每一项不能做什么

WeVisOne-VL-4B 无法观看视频，无法围绕一张图像进行多轮对话，也无法在手机上运行。它没有公布每秒 token 数，也没有量化构建版本，这意味着任何部署它的人都必须使用 GPU，并自行对吞吐量进行基准测试。微调代码仍然是该项目 TODO 列表上一个未勾选的复选框。

MiniCPM-V 4.7 1B 无法返回掩码或 alpha matte。它会告诉你图像中有一张人脸以及大致位置；但它不会给你一个边缘柔和的抠图。它还带有全新模型家族的常见风险：Transformers 中的新 model_type、最低版本要求 5.18.0，以及早期有报告称在某些 CUDA 与 torchcodec 组合下视频解码会出现故障。其 262K 上下文只是纸面数字——后训练尚未被证明能充分利用这一上下文。

第二次通话的费用

在实践中，这两个模型并非彼此的替代品，而有趣的架构会同时使用两者：用一个小而便宜的模型来描述图像并进行推理，再用一个感知模型返回几何信息。这会把一次推理调用变成两次，而成本正是在这里不再是一个无足轻重的脚注。

OrcaRouter 对那种形态的贡献，是那种无聊却关键的部分——一个密钥即可通行 200 多个模型，供应商标价按 0% 加价率透传，并在上游端点降级时自动故障转移。通用模型一侧的厂商降价当天就会落到我们这边，因为没有需要更新的加价层。WeVisOne-VL-4B 和 MiniCPM-V 4.7 1B 目前都不在该目录中，因此流水线中负责感知的那一半仍需你自行托管。你避免的是为已由目录覆盖的那一半再签一份合同、再准备一套凭据。

你会如何运行其中任何一个

WeVisOne-VL-4B 的安装要求更高。模型卡记录了 Transformers、vLLM、SGLang 和 Docker Model Runner，但 mask_decoder.pt 是必需组件：如果加载检查点时没有使用项目的推理包，你只会得到框和文本，而不会得到掩码。解码采用贪心策略，每张图像最多 1,960 个视觉 token，且没有公布吞吐量数据，所以你在自己的硬件上要做的第一件事就是测量它。

MiniCPM-V 4.7 1B 是更省心的那个。它需要 Transformers 5.18.0 或更新版本，而生态也随之到位——llama.cpp、Ollama、SGLang 和 vLLM 的构建版本，外加 int4、AWQ、GPTQ 和 FP8 量化，以及一个独立的 213M 参数 DSpark 草稿模型用于投机解码。如果你的目标是手机、Intel 小主机或瑞芯微开发板，那这就是一条已经铺好路的选择。

该下哪个注

如果受限于设备，就选 MiniCPM-V 4.7 1B。WeVisOne-VL-4B 没有任何地方是为手机设计的，而 MiniCPM 这边的量化、运行时支持和视频处理，都出自一个已经推出过几代端侧模型的实验室。

如果约束在输出端——你需要掩码、遮罩、密集小目标框，或一个可靠的“不存在”答案——那就选 WeVisOne-VL-4B，并把 GPU 预算算进去。要明白，你依据的是一篇发布仅两天、尚无独立评估的论文，而且抠图指标是腾讯自家的。

如果你两者都需要，就需要两个模型。这是诚实的结论，也是两家厂商自己的基准测试表都支持的结论：它们针对不同的目标进行了优化，而且谁也没有试图击败对方。