LFM3-VL-2B vs WeVisOne-VL-2B：相隔三天，押注相反

LFM3-VL-2B于2026年10月19日出现在 Hugging Face 上。WeVisOne-VL-2B则于10月22日亮相。两个模型，参数量都在二十亿左右，都是开放权重，都出自知名实验室，发布时间相隔不到72小时。你大概会以为它们几乎是彼此的替代品。可实际上，它们更像是对“视觉”意味着什么所下的两个相反赌注：一个回答关于它所看到之物的问题，另一个则返回它所看到之物的精确形状。

这种区别在规格表上很容易被忽略，因为两种卡都列出了边界框，也都列出了 OCR。差异在于输出格式和训练目标，而这决定了你是否能把任一模型直接放进流水线中、无需额外的解析层。它也决定了在通用模型变得更强之后，哪一个还有存在的理由。

关于“看”的两种定义

LFM3-VL-2B 是 Liquid AI 的通用模型。它以 2 fps 接收文本、图像和视频，输出文本，支持逐步思考，具备 128K 上下文，覆盖 16 种语言。其架构为密集 1.92B 模型——包含 1.73B 语言主干、164M 自研视觉编码器和 25M 投影器——并已发布 BF16、GGUF、MLX 4-bit 和 ONNX 构建版本。Liquid 的家族发布文章将其定位为一款能够“观察、推理并理解物理世界”的模型，而视频路径对该家族而言确实是全新的。

WeVisOne-VL-2B 是腾讯的微信视觉模型。它基于 Qwen3-VL 主干构建，参数量约为 2.4B，采用 Apache 2.0 许可，其目标是实现统一感知：开放词汇检测、指代定位、计数、指向、OCR 定位、指代分割以及可提示的 alpha 抠图。它通过专用 token 返回归一化坐标，并通过一个独立的 9.6M 参数像素解码器返回掩码，该解码器必须与语言模型一同加载。

一个模型是阅读者，另一个是测量仪器。它们基准测试表中的重叠是真实存在的，但那是两个不同产品测量同一场景所产生的重叠。

输出格式就是产品

WeVisOne-VL-2B 将坐标编码为从 <0> 到 <1000> 的 token，用 <OBJ> token 标记每个实例，并在请求的目标不存在时返回 None。最后这个细节正是从业者会注意到的：模型卡报告其在 RefCOCOg 上的拒识率为 50.2，而 Rex-Omni 和 LocateAnything 约为 0.5。它被训练成说“不在这里”，而不是凭空编造一个边界框。

像素解码器不是可选项。分割和 alpha 抠图都需要 mask_decoder.pt，这是一个由对象 token 触发的 9.6M 参数模块。如果只加载语言模型，你得到的是坐标，而不是掩码。GitHub 仓库提供了将两者连接起来的推理包，而且该模型在设计上仅支持单轮对话和图像输入——像素解码器会拒绝视频网格。

LFM3-VL-2B 没有等效的契约。它会用散文描述一个区域、清点物体，或对场景进行推理，而其定位行（RefCOCO-avg 90.5）表明它擅长定位。但输出是文本。对于需要掩码的流水线来说，90.5 与可解析多边形之间的差距，就是演示与产品之间的差距。

无法相减的接地数字

这两张卡片都报告了 RefCOCO 系列结果，但它们并不是同一种测量。LFM3-VL-2B 报告 RefCOCO-avg 90.5，这是对指代表达各划分取平均。WeVisOne-VL-2B 报告指代检测的 RefCOCOg 77.1 mean F1，以及指代分割的 RefCOCO testA 82.9 cIoU。RefCOCOg 是另一个划分，包含更长、更口语化的表达；cIoU 是与 F1 不同的指标。

从90.5中减去77.1得到的数字毫无意义。诚实的解读是：两个模型在各自测试框架上的指称定位都很强，两个测试框架均未被独立复现，而且指标定义差异足够大，以致排名仍无法确定。同样的谨慎也适用于OCR：LFM3-VL-2B报告OCRBench v1为86.3，而WeVisOne-VL-2B报告OCR HierText为30.5，后者是在更难数据集上的另一个基准。

在比较条件清晰的情况下，这有利于专才在其自身领域：WeVisOne-VL-2B 报告的 COCO 检测 F1 为 55.2、LVIS 为 53.3、Dense200 为 61.4，而另一个模型根本没有公布检测 F1。这并非默认的胜利。它提醒我们，通用模型并未被训练成按那种方式接受评分。

哑光就是护城河

可提示的 alpha 抠图是 LFM3-VL-2B 及其同尺寸级别的大多数模型都不具备的功能。WeVisOne-VL-2B 在 P3M-500-NP 上针对软边缘 matte 报告的平均绝对差值为 6.6——软边缘 matte 指头发、玻璃和毛皮周围的半透明边界，而二值分割掩码会将其变成硬切边。该卡片坦承了其局限：精细的 alpha 边界在遮挡、低分辨率和透明条件下会退化。但对于产品抠图、合成和背景替换而言，matte 才是流水线真正需要的输出。

这是该模型存在的最有力论据。一个 2B 的通用模型可以描述图像；但它无法交给你一个软 alpha 通道。腾讯围绕像素解码器构建了一个小模型，因为从大型通用模型获取这种输出的成本很高；而 4B 的同系列模型则是为需要在同一任务上获得更高精度的团队而存在。

视频和思考是另一条护城河

LFM3-VL-2B 的差异点则相反。它以 2 fps 接收视频，并在无字幕的情况下报告 Video-MME 62.8、MVBench 69.4 和 MMMB 85.2。WeVisOne-VL-2B 是单轮且仅支持图像的；其像素解码器会拒绝视频网格。如果你的输入是一段视频片段，那么比较在基准表开始之前就已经结束了。

思考模式又添了一道差距。LFM3-VL-2B 报告称，开启思考时 MathVista 为 84.2，不开启时为 68.5；MMMU 则为 55.7 对 48.6。WeVisOne-VL-2B 出于效率考虑，在设计上就没有思维链。对于感知组件而言，这是合理的工程选择；但对于一个你想要用来推理图表的模型来说，这是硬性限制。

记忆、许可与入场代价

• 参数 — LFM3-VL-2B 1.92B 稠密模型 vs WeVisOne-VL-2B 约 2.4B，外加一个 9.6M 像素解码器。

• 内存 — 按计算，LFM3-VL-2B 约为 3.84 GB BF16，并有 4-bit MLX 构建；WeVisOne-VL-2B 的权重在 F32 下约为 9.1 GB，在 BF16 下估计为 4.9 GB，依据是第三方部署说明而非模型卡。

• 输入 — 文本、图像和视频（2 fps）对比仅图像和文本，单轮。

• 输出 — 散文式文本，可选包含推理内容与文本、归一化坐标、掩码和 alpha 蒙版。

• 上下文 — 128K，而未说明为文档级窗口；像素解码器是限制因素。

• 许可证 — LFM Open License v1.0，年收入低于 1000 万美元可商业使用；Apache 2.0 则不限规模。

• 已发布 — 存储库 2026年10月19日，家庭公告 10月27日，对比存储库 2026年10月22日。

许可证这一行的情况与通常的叙事相反。腾讯的模型采用宽松许可证；Liquid 的模型则有营收上限。对于一家打造商业化感知产品的公司来说，Apache 2.0 消除了 LFM 许可证带来的一项尽职调查事项。这并不意味着这些模型可以互换，但它确实意味着更小、更通用的模型承载着更大的法律约束。

两个模型都没有托管价格

两张模型卡都发布了权重，但都没有公布每 token 的 API 费率。Hugging Face 没有为 LFM3-VL-2B 列出任何推理提供商；WeVisOne-VL-2B 的模型卡同样没有托管端点，不过已有面向 LiteRT、Core AI、GGUF 和 Android 的社区移植版本。这就是当前 2B 视觉层级的格局：权重免费，服务自建，真正的成本在于 GPU 和集成工作。

如果你更愿意租用该档位而不是自己拥有，OrcaRouter 会通过一个 API 路由托管视觉模型——其中包括 Qwen3-VL-8B——并按提供商标价以 0% 加价原样透传，还提供模型融合：如果你想让一个感知模型和一个推理模型作为小组共同作答。在此对比中，我们并不提供这两个检查点中的任何一个，这里也没有任何内容暗示我们会提供。相关的要点是：当两个开放权重模型都没有随附端点时，租用一个稍大的托管模型是合理的第三种选择。

如何选择

• 选择 WeVisOne-VL-2B，如果输出是几何信息：边界框、掩码、alpha matte、计数，或“不存在”信号。如果 Apache 2.0 不可妥协，或者你正在构建抠图、合成或机器人感知流水线，也请选择它。

• 选择 LFM3-VL-2B，如果输入包含视频、需要跨图表或表单进行推理，或者希望用一个小模型回答一般性问题而不是测量形状。

• 两者都采用仅当你准备运行两条流水线时才这样做。它们共享一个参数类，除此之外几乎别无共同之处；而假装并非如此所产生的集成成本，要高于第二个模型的成本。

两个仓库之间相隔三天，这只是巧合。但它们所返回内容的差异并非巧合。两个实验室面对同样的 2B 预算，却把它花在了不同的产出上——真正该问的不是哪个更好，而是你的下一个流水线步骤实际能消费哪种输出。