WeVisOne-VL-4B 对决 LFM2.5-VL-3B：抠图专家对阵边缘速度型选手

Liquid AI 公布了 LFM2.5-VL-3B 的速度数据，而腾讯没有公布 WeVisOne-VL-4B 的任何速度数据。这种不对称——胜过任何一行基准测试数据——才是这场对决的关键。LFM2.5-VL-3B 是一个 3.1B 参数的边缘模型，经过调校可一次性完成回答：在 Apple M5 Max 上每秒 228 个 token，在 Galaxy S26 Ultra 上每秒 20 个 token，内存占用低于 3.3 GB，支持十六种语言。WeVisOne-VL-4B 是一个 4.83B 参数的感知模型，最多会消耗 1,960 个视觉 token，并使用一个 9.6M 参数的解码器，为你输出全分辨率 alpha 蒙版。一个被打造得足够快，可以嵌入手机 UI；另一个则是为输出像素而打造。它们只在“vision”这个词上重叠，几乎再无其他交集。

这就使得这场比较值得认真去做，因为最显而易见的那种做法——把基准测试表格并排摆开，然后宣布谁胜出——会以一种具体而有启发性的方式出错。

基准表之间无法相互通信

两个模型都公布了指代表达（referring-expression）的数值，而且两个数值看起来相当。其实并非如此。LFM2.5-VL-3B 报告的 RefCOCO-avg P@1 为 87.9。WeVisOne-VL-4B 报告的 RefCOCOg test F1 mean 为 81.8。数据集划分不同、指标不同、失败模型也不同：P@1 问的是排名最高的框是否正确，F1 mean 则是对从 0.5 到 0.95 的各个 IoU 阈值上的精确率和召回率取平均。一个模型可以在其中一个指标上胜出，却在另一个指标上大幅落后，而这两种结果都不令人意外。

同样的陷阱存在于其他每一行中。Liquid 在 ScreenSpot-v2 上的 80.7 衡量的是 UI 元素定位；腾讯没有 ScreenSpot 数值。腾讯在 WeRef-Bench 上 96.4% 的拒答率衡量的是当目标不存在时模型是否会拒绝回答；Liquid 则完全没有公布拒答指标。两家厂商都没有评估对方的模型，因此两张表中的任何一行都不是直接对比。

可以坦诚地说，这些结论具有方向性。LFM2.5-VL-3B 在其规模上是一个强大的通用模型——按 Liquid 自己的统计，在 28 个视觉基准上平均得分 69.4，与 Qwen3.5-4B 相差 0.7 分以内——而且它的 ScreenSpot-v2 从前一代接近零跃升至 80.7，是其表格中单项最大提升。WeVisOne-VL-4B 并不在这一维度上竞争。它最强的宣称在于密集小目标检测、拒识和像素级输出，而这些 LFM2.5-VL-3B 都未尝试。

每个模型在物理上是什么

• 参数 — WeVisOne-VL-4B 4.83B 稠密（F32 检查点）对比 LFM2.5-VL-3B 3.12B 稠密（BF16）

• 视觉路径——Qwen3-VL 主干加 9.6M 像素解码器，对比 LFM2.5-2.6B 混合卷积-注意力文本基座加 SigLIP2 NaFlex 400M 编码器

• 内存 — F32 4B 检查点在磁盘上约占用 19 GB，而 3B 的总占用空间不到 3.3 GB

• 背景——对于 WeVisOne-VL-4B 与 LFM2.5-VL-3B 的 32,768 个 token 的对比，尚无已发布的数据

• 语言 — WeVisOne-VL-4B 未说明，而 LFM2.5-VL-3B 为 16 种，并配有专为非拉丁文字构建的 128K 词表

• 输出类型——边界框、点、掩码和 alpha 遮罩，对比仅边界框和文本

• 许可证 — 腾讯编写的代码采用 Apache 2.0，而 LFM Open License v1.0 则不同

• 速度 — 未公布成绩 vs 在 M5 Max 上 228 tok/s、在 Ryzen AI Max+ 395 上 116 tok/s、在 Galaxy S26 Ultra 上 20 tok/s

真正起决定作用的能力差距

LFM2.5-VL-3B 能告诉你图像中人的位置。WeVisOne-VL-4B 能告诉你人的位置，返回该实例的二值掩码，并以全分辨率返回具有柔和边缘的连续 alpha 蒙版——头发、毛发、薄纱织物、运动模糊——。这是类别上的差异，而不是质量上的差异。如果你的产品需要将主体合成到新背景上、抠出产品照片，或支持视频通话的背景替换，那么 LFM2.5-VL-3B 无法为你提供任何帮助，再多的提示工程也无法改变这一点。

反过来做同样的比较，结果还是一样。如果你的产品需要在 40 毫秒内在手机屏幕上找到一个按钮，那么 WeVisOne-VL-4B 的形态就完全不对：它是一个 4.83B 的模型，没有公布延迟数据，没有量化边缘版本，而且其解码器假定每轮只处理一张图像。Liquid 提供 GGUF、MLX、ONNX 和原生构建，还具备 32K 上下文和工具调用基准。腾讯则提供一个研究用推理包以及 vLLM/SGLang 服务。

拒绝是被低估的那个专栏

腾讯表格中的一项能力值得关注，即使你从不接触抠图。在 WeRef-Bench 上，WeVisOne-VL-4B 对图像中不存在的对象的查询正确拒绝率为 96.4%，而作者列出的最佳基线为 73.0%；在 PR-Bench 上，拒绝率为 52.6%，而 Qwen3-VL-4B 为 10.8%。该模型会返回 None，而不是编造一个框。会产生幻觉的检测器比没有检测器更糟，因为这种失败是静默的，而下游代码却信任它。

LFM2.5-VL-3B 的文档没有报告拒绝率数据，因此没有可对比的对象——而这本身就是重点。没有证据并不等于失败，但如果你正在构建一个需要判断是否点击某个东西的智能体，那么存在经过测量的拒绝率，确实是优先考虑腾讯模型的实打实理由。

许可是一种低调的差异化因素

这正是两者出现分歧的地方，而这一分歧对任何进行商业交付的人都至关重要。WeVisOne-VL-4B 的权重采用 Apache 2.0 许可，适用于腾讯编写的代码，第三方组件则保留其自身条款。LFM2.5-VL-3B 以 LFM Open License v1.0 发布，在收入门槛以下可免费商用，超过该门槛则需签订商业协议。如果你是一个小团队，这种差异只是理论上的。如果你不是，那么其中一个意味着一次法律审查，另一个则只是依赖文件中的一行。

这两份许可证都没有授予你托管服务。WeVisOne-VL-4B 根本没有 API；LFM2.5-VL-3B 是一次权重发布，任何第三方托管都属于另行安排。把这一点直白地说清楚，比以往更重要，因为一个没有端点的模型，意味着你要承诺自行掌控推理栈。

OrcaRouter 适合用在何处，又不适合用在何处

这两款模型目前都不在 OrcaRouter 的目录中，因此这里并没有任何可以调用它们的途径。该平台真正提供的，是围绕这一决策的支撑。大多数评估 3B 边缘 VLM 的团队，并不是要用一个模型替换另一个模型，而是在已经投入生产的通用模型旁边再添加一个模型；而第二份供应商合同、第二把密钥和第二种故障模式所带来的运营成本，往往会在模型本身导致实验失败之前，就先让实验夭折。

将两种意图都通过一个端点进行路由，并且一个密钥背后有 200 多个模型，按提供商标价 0% 加价，这意味着感知模型可以成为一项路由决策，而不是一个集成项目。如果边缘模型不可用，自动故障转移会将请求发送到其他地方，而不是返回 503。这正是 OrcaRouter 在这里真正解决的部分；权重和 GPU 仍然归你所有。

该选哪一个

如果任务对延迟敏感且以文本为主——屏幕理解、UI 智能体、带版面布局的文档 OCR、端侧翻译、工具调用——请选择 LFM2.5-VL-3B。在其规模下，它几乎比任何同类模型都快；它能在手机的内存预算内运行；而且 Liquid 已公布足够多的数据，让你能对照自己的工作负载核验这些说法。

如果任务最终落在像素层面，就选 WeVisOne-VL-4B。分割、抠图、小目标密集检测，或任何需要把“模型说没有”当作可靠答案的流程，都适合。请接受你将是一名早期采用者：尚无独立基准测试运行，尚无托管端点，微调代码仍在待办清单上，而且论文才发布两天。

唯一不该做的，就是根据单一基准分数在两者之间做选择。没有人用同一份数据、在相同条件下对它们进行过相互对比测量。