LFM3-VL-2B 对比 WeVisOne-VL-4B：2.5 倍参数究竟能换来什么

腾讯自己的基准测试表并不支持这一显而易见的购买选择。WeVisOne-VL-4B是微信视觉团队于2026年10月22日发布的两个感知模型中较大的一个，但在框提示 alpha 抠图任务上，它却不如自家的 2B 版本：在 P3M-500-NP 上平均绝对差为 7.3，而 2B 版本为 6.6，数值越低越好。不过，大多数买家真正会拿来与它比较的，并不是它的同门兄弟，而是LFM3-VL-2B——Liquid AI 的 1.92B 端侧视觉模型，其权重于10月19日上线，并于10月27日随 LFM3 系列其他成员一同公布。

把这两个模型并排放在一起，有趣的问题就不是哪个更聪明，而是 2.5 倍的参数能换来什么，又要付出什么代价。简短答案来自厂商自己的表格：它们换来了密集检测、指代准确率，以及当目标不存在时高得多的拒答率。它们换不来通用模型，换不来视频能力，也换不来一个能装进手机的模型。下面所有内容都来自这两张已公布的表格，且保留了拼接处的痕迹——尚无独立评测框架复现过任一模型的数字。

每一个实际上是什么

LFM3-VL-2B拥有19.2亿稠密参数：17.3亿参数的语言主干、1.64亿参数的自研视觉编码器和2500万参数的投影器。主干采用 Liquid 的三重混合堆栈——24层划分为13层门控短卷积、5层窗口大小为256个 token 的滑动窗口注意力层，以及6层全局注意力层。它以原生分辨率接收文本、图像和视频，以每秒2帧对视频采样，支持128K token 上下文，覆盖16种语言，并具有可选的思考模式，可在给出答案前先进行一轮推理。其输出为散文。

WeVisOne-VL-4B构建于 Qwen3-VL 主干之上，命名为 4B，尽管 Hugging Face 元数据将其四舍五入为 5B，第三方文章给出的实际数量接近 4.83B。它与其说用散文作答，不如说直接输出几何信息：框和点以 0 到 1000 的归一化坐标 token 表示，每个预测框后跟一个 OBJ 标记（token id 152678），当目标不存在时则输出字面字符串 None。掩码和 alpha matte 需要第二个产物 mask_decoder.pt，这是一个 9.6M 参数的像素解码器，它接收每个 OBJ token 的隐藏状态和预测框，并以 stride 1 返回全分辨率 alpha。它是单轮且仅支持图像，并直接生成结构化输出，没有思维链。

单次对比：

• 规模 — LFM3-VL-2B 是 1.92B 的稠密模型，而 WeVisOne-VL-4B 约为 4.83B，另外还有一个 9.6M 的解码器，它是掩码所必需的

• 输入 — 文本、图像和 2 fps 的视频，对比文本和单张图像

• 输出——自然语言散文和一轮思考过程，对比坐标 token、框、掩码、遮罩，或显式的 None

• 上下文——128K tokens，而模型卡上未公布推理限制；论文描述的是在 4,096 和 8,192 tokens 下进行训练

• 语言覆盖范围 — 标明支持 16 种语言 vs 未标明任何语言

• 许可 — LFM Open License v1.0，年收入低于 1000 万美元可免费商用；由 Tencent 编写的代码则采用 Apache 2.0

• 运行时 — GGUF/llama.cpp、MLX 4-bit、ONNX，以及通过 Transformers、vLLM 或 SGLang 进行的 BF16 与 BF16 对比

升级并不均衡，而论文指出了问题所在

WeVisOne-VL-2B 和 WeVisOne-VL-4B 是同一架构在两个规模上的版本，二者都在相同的约 1 亿张图像上、通过相同的三阶段课程进行训练，并在同一张评测表上评估。这使得这对同源模型的比较成为目前关于额外参数究竟起什么作用的最清晰证据——而结果并非朝单一方向发展。

在腾讯的数据上，4B 明显胜出的地方：

• Dense200 检测——平均 F1 为 71.3，对比 61.4，是单项最大提升

• LVIS — 55.3 对 53.3，小幅提升 2 个百分点

• RefCOCOg 指称检测 — 测试 81.8 对比 78.2

• RefCOCO 指代分割 — testA 上 84.5 cIoU，对比 82.9

• ReasonSeg — 在验证集上达到 71.2 cIoU，相比 60.9，在推理分割上提升了 10 个百分点

• PointBench 指向 — 71.9 对比 62.9

• WeRefMat 指代抠图——在指代划分上的平均绝对差为 9.8，对比 15.8，误差降低 38%

不适用的情况：

• P3M-500-NP 箱式抠图 — 7.3 对 2B 的 6.6，更差

• PPM-100 盒装消光 — 6.1 对 5.3，更差

• Ref-ZOM cIoU — 测试 72.2 对 73.4，2B 再次领先

这种规律清晰可辨，即使原因尚未公开：4B 在困难且受语言条件驱动的任务上领先——指代分割、推理分割、真实场景上的指代抠图——而在更简单的框提示抠图数据集上毫无优势，因为两个模型都已接近上限，9.6M 解码器可能承担了大部分工作。三个框提示抠图基准中有两个朝错误方向变化。如果你唯一的任务是基于给定框进行 alpha 抠图，那么 4B 并不是升级；它只是以更高成本得到相同答案，而且略差。

缺失对象：有所改善，但仍未解决

论文里最有用的那一列，恰恰是几乎没有哪个视觉模型卡会公布的。RefCOCOg-Rej 是一个变体，其中每一条表述都被改写，使得没有任何匹配的对象出现在图像中。不会说“不”的模型会凭空编出一个框，而下游的每一次裁剪、计数和掩膜都会继承这份捏造。

WeVisOne-VL-4B 的正确拒绝率为 67.4%，而 2B 为 50.2%。这是真实且显著的提升——17 个百分点的增益将流水线的故障模式从“掷硬币”变为“三局两胜”。这也意味着，对于大约每三个缺失目标的查询，4B 仍会返回一个自信的框。在腾讯自建的 WeRef-Bench 上，拒绝率显示为 96.4%，但该基准是实验室自己构建的 2,880 条中英文查询，因此它衡量的是比公开基准更友好的分布。诚实的总结是：该模型具备可用的弃权行为，但并未解决问题；如果你的应用无法容忍幻觉区域，那么无论选择哪个模型，都需要在其之上加一个阈值或二次检查。

那个看似可比、实则并非如此的数字

把 LFM3-VL-2B 的 90.5 RefCOCO-avg 与 WeVisOne-VL-4B 的 81.8 RefCOCOg 并排放在一起，然后宣布较小的模型赢了 8.7 个百分点，这很诱人。但不要这么做。它们是不同的数据划分和不同的指标：Liquid 报告的是 RefCOCO 系列上的平均值，Tencent 报告的是指代检测的 RefCOCOg 测试 F1。把两者相减，得到的数字没有对应的指称对象。

同样的陷阱也存在于 OCR 中。LFM3-VL-2B 在 OCRBench v1 上得分 86.3，该基准是文本识别、文本定位和推理的综合评测；WeVisOne-VL-4B 在 TotalText 上取得 52.0 的平均 F1 分数，这是一个场景文本定位基准。一个是覆盖面广的考试，另一个是密集预测任务。它们并不是同一项技能被测量了两次。

因此，这两张供应商表格并没有在一个真正同口径的数字上重合。能够诚实比较的是能力和成本，这也是为什么接下来的比较关注的是适配度而非排名。任何根据这两张表格发布赢家的人，都是在凭空捏造一个赢家。

内存才是真正的代价

截至 2026 年 10 月 28 日，这两个模型都没有公布按 token 计费的价格。Liquid 的模型卡提供了通过其控制台访问 API 和 Playground 的链接，但未发布 LFM3-VL-2B 的费率卡；列出 Liquid 文本模型费率的第三方追踪器并不覆盖该视觉模型。腾讯则根本没有托管端点。因此，这一比较是自托管比较，账单以内存为计价单位。

• LFM3-VL-2B — 根据参数量按算术估算，BF16 下约为 3.84 GB，并同时发布了 4 位 MLX、GGUF 和 ONNX 构建版本

• WeVisOne-VL-4B — 据第三方估算，BF16 精度下约为 9.7 GB，F32 精度下约为 19 GB，另需加上必需的 mask_decoder.pt

那 2.5× 的差距不只是 GPU 更大。它属于完全不同类别的设备。LFM3-VL-2B 的模型卡明确说明，该模型专为端侧工作而构建——包括视频、文档、图表和应用屏幕相关的问题，寻找物体，以及为机器人做空间推理——而 MLX 4-bit 和 GGUF 构建版本正是兑现这一承诺的方式：一台笔记本电脑、一部手机、一个机器人底盘。WeVisOne-VL-4B 文档中给出的路径是在 BF16 上使用 Transformers、vLLM 和 SGLang，没有官方量化构建，也没有端侧运行时。它需要服务器 GPU。

与其只看表格，不如结合你自己的实际路径来核对框架支持。以 2 fps 处理视频是 LFM3-VL-2B 的一项模型能力，但某个运行时是否接受视频网格则是另一个问题，而且模型卡、移植版本和上游 PR 对此并不总是保持一致。请测试你打算发布的那个确切组合。

OrcaRouter 不托管这两个模型。这一点已在 2026 年 10 月 28 日对照目录核实，而非假设——Liquid 的 LFM3 系列和 Tencent 的 WeVisOne 均未出现在模型列表中——因此这里的任何内容都不应被理解为通往其中任一模型的途径。而OrcaRouter 模型目录确实提供的是Qwen3-VL-8B，包括 instruct 和 thinking 变体；如果你实际需要的是今天已有公布价格的托管视觉模型，而不是自托管检查点，那么这就是务实的选择。一个密钥即可按提供商标价访问全部内容，且无加价；如果你正在用未经证实的开放权重模型做原型验证，通过带故障转移的路由器来运行它，胜过将生产路径接到一个尚未经过独立评估的检查点上。

该选哪一个

• 当交付物是静态图像上的几何结果——掩码、alpha 遮罩、密集框、计数、指向——当查询由语言条件驱动而非框提示驱动时，以及当你有富余 GPU 时，选择 WeVisOne-VL-4B

• 当你的任务是在普通场景中进行基于边界框提示的抠图时，选择 WeVisOne-VL-2B 而不是 4B；根据已公布的数据，较小模型在该任务上表现更好，且内存占用不到一半。

• 当输入包含视频、文档较长、答案需要是句子而非多边形，或设备不是服务器时，选择 LFM3-VL-2B

• 如果你本周需要一个已公布每 token 价格的托管端点，那就两家都别选——两家供应商都不提供这样的端点，而且无论做多少基准测试都无法弥合这一差距

• 只有当你接受两套输出架构和两条集成路径时，才两者都选；共用的“约 2B 至 5B”参数区间掩盖了两款不同的产品

什么会改变这一点

三件事。一个独立的测试框架，让两个模型在相同图像、相同提示词下运行——在此之前，上面的一切都只是一张仔细读过的厂商表格，这比粗心读过的厂商表格要好，但并不是质量证据。一个量化版 WeVisOne 构建，或一个端侧运行时，这会把内存方面的论据从决定性的变为可商榷的。以及任意一方公布的每 token 价格，用一个人可以据此做预算的数字取代关于千兆字节的算术。

三者中最不可能发生的那个，恰恰对这对特定组合最为关键：WeVisOne 的像素解码器对视频的支持。目前，2B 通用模型能接收视频，而 4B 仪器模型不能；再多的参数量也无法弥补一个从未训练过的模态。