WeVisOne-VL-2B vs LFM2.5-VL-3B：面具制造者对阵屏幕阅读器

给两个模型同一张照片和同一句话——“左边的那只狗”——返回的却是两种不同的东西。LFM2.5-VL-3B 会给出一个位置；如果你要求，还会给出描述：一个边界框、一个点，或一句关于它找到了什么的简短说明。WeVisOne-VL-2B 也会给出一个边界框，然后一个小型解码器会把该框变成边缘柔和的 alpha 蒙版，你可以把它合成到新背景上，而毛发周围不会出现光晕。一个模型是为读取界面并作出回复而构建的。另一个模型则是为把像素交到你手上而构建的。

这一差异构成了整个对比的全部，而且它在两家厂商各自公布的每一张基准测试表中都依然成立。这也解释了为什么这两个模型很少被放在一起评估：Liquid AI 的模型卡没有提到 WeVisOne，腾讯的论文没有提到 Liquid，也没有第三方将它们并排运行过。下面要说的是，每次发布实际记录在案的内容有哪些，其中哪些数字可以相互并列比较，哪些不能。

两次发布，证据数量却截然不同

LFM2.5-VL-3B 由 Liquid AI 于 2026 年 8 月 11 日发布：先发布权重，次日发布公告；同时附有一张数值基准测试表，表中每一行都标明了具名基线，还有一个在具名硬件上测速的速度部分。它是一个 31.2 亿参数的稠密模型：语言主干为 LFM2.5-2.6B，视觉编码器为 SigLIP2 NaFlex 400M，上下文长度为 32,768 个 token，词表大小为 128,000 个 token，并涵盖十六种具名语言。其许可证是 Liquid 自家的 LFM Open License v1.0；该许可证在收入低于某一门槛时可免费商用，并非无条件免费。

WeVisOne-VL-2B 由腾讯微信视觉团队于 2026 年 10 月 22 日发布，其模型卡中完全没有基准测试表——没有分数、没有上下文长度、没有吞吐量数据、也没有硬件要求。这些数字确实存在，但它们位于随附论文中，该论文在作者所称的三十多个基准测试上报告了七张任务表。因此，这两个发布不只是不同的模型；它们是不同类型的文档。Liquid 发布了一份产品规格。腾讯发布了一项研究成果，却把规格表基本留空。

当你阅读像这样的对比时，这种不对称性很重要。Liquid 的数据是围绕其自身基线来整理的。腾讯的数据则是为了在学术表格中取胜而整理的。两家厂商在选择数字时都没有考虑对方模型，这正是这些数字对不上的原因。

那个看似可比、实则不可比的数字

两个模型都公布了 RefCOCO 分数，把它们并排放到一起，就会得出一个看起来干净利落的标题式结论：LFM2.5-VL-3B 为 87.9，而 WeVisOne-VL-2B 为 79.7。这种比较毫无意义，值得详细说明原因，因为现在电子表格里正在犯同样的错误。

• Liquid 报告了 RefCOCO precision@1在各分割上取平均值。这是一个检测统计量：排名最高的预测框是否与真实标注框充分重叠，从而可以计为正确。

• Tencent 的 79.7 出现在一张分割表中，并且论文明确指出，其中的 RefCOCO 系列数值是累积 IoU——整个评估集上的总交集除以总并集。

• 腾讯的指代检测表格完全没有报告 RefCOCO。它报告的是 RefCOCOg，其中 2B 的平均 F1 得分为 77.1。

所以，87.9 和 79.7 在两个不同任务中衡量的是三件不同的事情。一个与目标仅勉强重叠的框，可能在 precision@1 上得分很高，但在 cIoU 上得分很差；一个能很好地覆盖大物体的掩码，可能在 cIoU 上得分很高，而它的边界框却很粗糙。没有任何算术能把它们调和起来。

同样的陷阱也存在于 OCR 中。Liquid 发布的 OCRBench v1 得分是 84.2，OCRBench v2 英文得分是 47.5——这些是转写基准。腾讯发布的是 OCR 作为定位任务在 0.5 IoU 阈值下的 F1：SROIE 上 62.1，ICDAR2015 上 42.6，TotalText 上 42.5，HierText 上 30.5。这些衡量的是模型是否找到并用框标出了文本，而不是它是否正确地读取了文本。引用“84.2 对 62.1”就是在拿阅读测试和指认测试作比较。

什么才是真正公平的比较？

剔除分数后，这两个模型就会在无需测试框架的各个维度上对齐：

• 规模 — LFM2.5-VL-3B 约有 31.2 亿稠密参数，而 WeVisOne-VL-2B 约有 20 亿，另有一个 950 万参数的解码器，必须单独下载，并且是稠密输出所必需的。

• 基础版——Liquid 自有的 LFM2.5-2.6B 混合骨干网络 对比 Qwen3-VL。

• 上下文——卡片上标注为已发布 32,768 个 token，而对方完全没有公布上下文长度。WeVisOne 论文的训练阶段分别在 4,096 和 8,192 个 token 下运行，推理时每张图像上限为 1,960 个视觉 token，但这些都不是部署窗口。

• 输出类型——框、点和文本 vs 框、点、二值掩码和连续 alpha 遮罩。

• 推理——LFM2.5-VL-3B 刻意采用非推理模式，直接作答以保持低延迟；WeVisOne 同样是非推理模式，但原因不同：为了提升推理效率，它生成结构化输出，而不进行思维链推理。两个模型在作答前都不“思考”，两家厂商也都没有假装并非如此。

• 工具调用——LFM 支持并已进行基准测试（ToolSandbox 59.5、BFCL v4 32.5），而 WeVisOne 未声明具备该能力。

• 语言 — LFM 卡片上列出了十六种，而 WeVisOne 卡片上未注明。

• 许可证 — LFM Open License v1.0，设有收入门槛；而腾讯编写的代码采用 Apache 2.0。

• 量化构建——Liquid 提供 GGUF、ONNX 和 MLX 导出，而腾讯未宣布任何此类导出。

• 独立评估——截至本文撰写时，这两个模型在 Artificial Analysis 上均无条目。本文中来自两家厂商的每一个数字均为厂商报告。

部署差距比参数差距更大

LFM2.5-VL-3B 的设计目标是能在手机上运行，而这张卡用数字证明了这一点：内存占用低于 3.3GB，在 Galaxy S26 Ultra 上每秒 20 个 token，在 Apple M5 Max 上每秒 228 个 token，在 AMD Ryzen AI Max+ 395 上为 116 个，在单块 H100 上高并发时输出速度约为每秒 11,000 个 token。它以消费级运行时确实能够加载的格式发布。

WeVisOne-VL-2B 并未公布其中任何一项。而它实际公布的内容，则指向另一份账单。解码器的最后一级会生成步长为 1 的全分辨率 alpha 遮罩，这意味着其稠密输出的尺寸与输入图像相同，而非固定大小的向量——这项开销随分辨率增长，而非随参数数量增长。对于现代 GPU 上的 2B 模型而言，这尚可应付。对于手机而言，这显然完全谈不上可应付，而腾讯也从未声称它可以。

实际后果是，这两个模型不会争夺同一个部署位置。一个是你可以打包进应用里发布的组件，另一个则是你会运行在服务器或工作站上、与其它需要做掩码处理的任务并行的组件。

按输出类型选择，而不是按分数选择

如果任务就是读取屏幕——解析结账流程、找到标有“Continue”的按钮、从拍摄的文档中提取表格——那么 LFM2.5-VL-3B 显然是候选。它的 ScreenSpot-v2 得分为 80.7，DocVQA 为 91.1，ChartQA 为 81.3，ToolSandbox 得分则表明它能基于所见内容采取行动，而不只是描述所见内容。它还有一项 28 个基准的平均分 69.4，这是 Liquid 针对具名同类模型公布的，至少能让你知道厂商认为自身所处的水平区间是什么样。

如果任务是把某个对象孤立出来——产品抠图、从杂乱背景中分离出人物、带有飞散发丝或透明边缘的前景——LFM2.5-VL-3B 不会产生这种输出，再怎么提示也无法让它做到。WeVisOne-VL-2B 可以做到，而且在抠图基准表上的差距很大：在 P3M-500-NP 上，平均绝对差为 6.6，而 SAM2-Matting 为 15.4；在带语言提示的 WeRefMat 划分上，为 15.8，而 Qwen3-VL-8B 加 SAM2 的流水线为 23.0。

还有一个情况，WeVisOne 提出了一个值得注意的主张：目标缺失。腾讯在 RefCOCOg 上报告称，对于目标不在图像中的查询，拒识率为 50.2，而同一张表上两个专门的定位模型分别为 0.5 和 0.6。如果你的流水线要处理成千上万个裁剪图，而其中大多数都不包含你关心的内容，那么一个能可靠地说“不在那里”的模型可以为你省去一个下游分类器。LFM2.5-VL-3B 的模型卡没有报告可比的拒识数字，因此没有可与之并列的数据——这是证据上的空白，而不是损失。

这一切都不是二选一、淘汰另一个的理由，也值得坦诚说明路由器适合放在哪里。OrcaRouter 不提供这两个模型中的任何一个；两者都不在我们的目录中，而且就 WeVisOne 而言，我们也没有任何可核实的地点托管其中任何一个。我们提供的是周边技术栈：如果你的流水线用托管视觉模型完成读取部分、用自托管模型完成掩码部分，那么托管调用会通过一个 API 密钥按提供商标价进行，且无加价；当某个提供商性能下降时，故障转移会把它们转到另一个提供商；路由 DSL 让你能把两部分放在同一个端点后面，这样你的应用就永远不知道是哪一个在应答。

究竟什么才能真正了结此事

一个独立的测试框架，由不属于任何一方厂商的人运行，在同一批图像上，为两个模型同时报告检测统计量和分割统计量。这样的东西并不存在。在它出现之前，站得住脚的立场是那个乏味的立场：这些模型回答的是不同的问题，它们公布的数字是用不同的工具测出来的，而它们之间的选择取决于你的下游代码期望收到什么——一句话，还是一张掩码。

如果你从这次对比中只带走一件事，那就带走证据的形态。Liquid AI 给了你一张可以被证伪的表格。腾讯给了你一篇可以阅读的论文，以及一张坦率告诉你该模型不会做什么的卡片。两家都没有给你一个可以相互比较的数字，而任何把 87.9 和 79.7 并排列出却不加这一说明的文章，都是在向你兜售一个并不存在的排名。