WeVisOne-VL-2B 对比 UI-Venus-2-9B：名称所掩盖的规模差距

这场对比的名称里写的并不是 90 亿参数。按照大多数人习惯的写法——WeVisOne-VL-2B vs UI-Venus 2.9B——这组对比看起来像是两个参数量大致相同的小型视觉模型之间的公平较量：一方是腾讯微信视觉团队推出的全新 2B checkpoint，另一方是蚂蚁集团旗下 inclusionAI 稍大一些的模型。这个假设的后半部分并不成立。UI-Venus-2-9B 是拥有 90 亿参数的 UI-Venus 2，基于 Qwen3.5-9B 初始化；其中的“2”表示代际，而非规模。WeVisOne-VL-2B 于 2026 年 10 月 22 日发布到 Hugging Face，是基于 Qwen3-VL 骨干网络的 20 亿参数模型。因此，真正的对比是：一个参数量仅为前者约 1/4.5、基于更老一代骨干网络的模型，给出的却是完全不同类型的答案。

它同样是在没有发布活动的情况下问世的。只有一个 Hugging Face 仓库、一个仅包含单个初始提交的 GitHub 仓库、一篇 arXiv 论文和一个研究项目页面——没有厂商公告、没有博客文章，也没有将它们关联起来的定价页面。这决定了本文能够如实做到什么。权重、架构、许可证文本以及论文中的表格如今都可核查。独立评估、吞吐量、延迟和价格则不可核查，因为这些都还不存在。腾讯的模型卡完全没有公布基准测试数字；下文归因于 WeVisOne-VL-2B 的每一项得分都来自其作者自己的七张任务表，并已如此标注。UI-Venus-2-9B 更早且文档更完善，但其数字同样完全为自报。

这两个名称实际上描述的是什么

WeVisOne-VL-2B 是一个感知模型。给它一张图像和一个短语，它便返回几何结果：一个边界框、一个点、一个计数、一个二值掩码，或一个连续的 alpha 蒙版。其语言侧将坐标作为专用 token 输出，范围从 <0> 到 <1000>，按图像归一化，并在密集任务中用位于 id 152,678 的特殊 <OBJ> token 闭合每个框。在 mask_decoder.pt 读取它们背后的隐藏状态之前，这些 token 只是标记——这是一个必需的、含 9,511,460 个参数的产物，作为第二个文件交付，模型卡将其描述为“必需的核心组件，而非可选的附加项”。没有它，你得到的是框。有了它，你得到掩码和步长为 1 的 alpha 蒙版。

UI-Venus-2-9B 是一个智能体。把截图和任务交给它，它会返回一个动作：下一次轻点、点击或按键，以及生成该动作的推理 token，整个过程处于闭环的“观察—推理—行动”循环中。它仅基于截图交互进行训练，涵盖元素定位、CAPTCHA、移动端、Web 和计算机使用；其已发布的 vLLM 配方将 262,144 的最大模型长度与 Qwen3 推理解析器配对，因为推理轨迹会先于每个动作输出。

把两者并排放在一起，不匹配之处立刻显而易见：

• 返回的内容——来自 WeVisOne-VL-2B 的框、点、计数、OCR 文本段、掩码和 alpha 遮罩；来自 UI-Venus-2-9B 的一个屏幕操作及其推理轨迹。

• 参数——WeVisOne-VL-2B 为 2B，外加独立的 9.5M 解码器；UI-Venus-2-9B 为 9B 稠密模型，权重量约是其 4.5 倍。

• 骨干——WeVisOne-VL-2B 采用 Qwen3-VL，包含 28 个文本层，隐藏大小为 2,048；UI-Venus-2-9B 采用 Qwen3.5-9B。代际不同，文本栈也不同。

• 磁盘上的权重——两者均为 bfloat16，但 2B 约为 4GB，而 9B 则是四个 BF16 分片，总计约 18.8GB。

• 上下文上限——每个模型均为 262,144 个位置，这些分别是从 WeVisOne-VL-2B 的配置和 UI-Venus-2-9B 的服务命令中读取的。两家厂商均未展示过使用类似能力。

公开证据——腾讯的论文中有七张任务表，而模型卡上没有任何任务表；inclusionAI 的模型卡上有一长串厂商基准测试列表，而论文中没有任何任务表。

• 许可证——腾讯编写的代码采用 Apache 2.0；UI-Venus-2-9B 权重“待最终确认”。

实际后果是，你不能把两者互换；任何给你一个赢家的文章，都是在回答一个你根本没问的问题。一个能返回完美蒙版的感知模型，仍然按不了按钮。一个能完美导航应用的智能体，仍然无法交出你为产品拍摄想要的那张抠图。

支持较小模型的理由，比 2B 与 9B 的对比所显示的更有力。

看到 2B 与 9B 并列时，本能反应是小的那个是预算上的妥协。在它受训的任务上，腾讯的论文却持相反观点，而且其自身的一项结果也反驳了自家规模更大的发布版本。这里所有数字都出自作者本人、由作者运行，无人复现。

• 零样本检测——在 COCO 上平均 F1 为 55.2，在 LVIS 上为 53.3，在 Dense200 上为 61.4，在 VisDrone 上为 40.4。Qwen3-VL-2B 基线在同一张表上的得分分别为 45.2、40.8、10.0 和 23.1。尤其值得注意的是 Dense200 上的差距：在拥挤场景中，它是基础模型的六倍。

• 计数——在 PixMo-Count 的两个划分上，精确匹配分别为 90.9 和 88.1，但在 CLOC 上为 27.5 和 26.9，在 KubriCount 上为 29.5 和 32.4，在 CountQA 上为 47.9。计数并不是单一技能，而这种差异是论文中最诚实的部分。

• OCR 定位——在 0.5 IoU 阈值下，HierText 上的平均 F1 为 30.5，ICDAR2015 上为 42.6，TotalText 上为 42.5，SROIE 上为 62.1。这些是附带坐标的定位得分，而非转录准确率，因此不能与消费级 VLM 通常引用的 OCRBench 数值相提并论。

• 指代分割——在 RefCOCO 验证集上累计 IoU 达 79.7，在 RefCOCO+ 上达 73.1，在 RefCOCOg 上达 74.4，在 ReasonSeg 上 gIoU 达 60.9。

• 可提示抠图——在 P3M-500-NP 上使用框提示时，平均绝对差为 6.6，而 SAM2-Matting 为 15.4；在 AM-2K 上为 5.7，而 SAM2-Matting 为 12.1；在更难的 WeRefMat referring 划分上，为 15.8，而 Qwen3-VL-8B 加 SAM2-Matting 流水线为 23.0。全程数值越低越好。

抠图结果正是规模论证发生反转的地方。在同一项 P3M-500-NP 框提示测试中，2B 得分 6.6，而腾讯自家的 4B 同门得分 7.3。两者之中，较小的模型反而是更好的那个；腾讯没有解释原因，论文却照样把它印了出来。如果你的工作是从图像中抠出对象，那么这个系列里最便宜的版本并不是降级——它目前是实测最佳的选择。

论文没有展示的内容同样值得了解。七张表格中完全没有 MMMU、MMBench、DocVQA，也没有任何图像描述基准；局限性部分承认，有限的通用训练数据“可能相对于基础模型损害通用能力”。使其擅长感知的微调，可能也让它成为更差的通用助手，而发布内容中没有任何东西对此进行测试。同样，也没有任何思维链输出、多轮记忆或视频支持——像素解码器会直接拒绝视频网格。

那个能一锤定音的基准并不存在

把这两套评测套件并排放在一起，不可比性就不再只是技术细节了。UI-Venus-2-9B 的主要结果是在某一环境中的终态成功率：在卡片默认步数预算下，AndroidWorld 为 80.2，OSWorld-Verified 为 70.8，WebVoyager 为 90.8，Online-Mind2Web 为 74.0，MobileWorld 为 65.8；而在 100 步时，MobileWorld 为 75.2。这些指标衡量的是任务是否完成，并把感知、规划、记忆和错误恢复都合并成一个数字。

最接近的共同轴心是 GUI grounding——在高分辨率截图中定位一个细小的界面元素。UI-Venus-2-9B 在 ScreenSpot-Pro 上取得 73.0 的成绩。WeVisOne-VL-2B 无论是在其模型卡、论文还是项目页面上，都没有报告 ScreenSpot-Pro 结果，也没有报告 ScreenSpot-V2 结果，更没有任何类型的 GUI 基准测试结果。反过来说，WeVisOne-VL-2B 报告了 OCR 定位和稠密指向（dense pointing），而 UI-Venus-2-9B 两者均未报告。

有一个细节让标题中的这组对比显得更加奇怪。inclusionAI 已经推出了一款基于 Qwen3-VL 的 2B 模型——UI-Venus-1.5-2B——其模型卡在 ScreenSpot-Pro 上报告 57.7，而其 8B 同系列型号为 68.4，30B-A3B 为 69.6。这才是 WeVisOne-VL-2B 真正在规模上对应的同类模型，基于同一骨干系列，并且在两条产品线都关心的同一个基准上测量。只是它并不是这次对比中被点名的模型。

诚实的立场其实很有限。没有任何已发表的数据在任何任务上比较过 WeVisOne-VL-2B 与 UI-Venus-2-9B，也没有人在 GUI grounding 数据集上运行过这个 2B 感知模型。在这项比较中，在 ScreenSpot-Pro 上运行 WeVisOne-VL-2B 是最有用的缺失测量：它能告诉你，一个 2B 感知专用模型在查找界面元素方面比一个 9B 智能体更好还是更差；而在有人实际运行之前，任何就“查找元素”对这两者进行排名的人，都只是在根据架构做外推。

当对象不在时，每一个会做什么

缺物行为正是感知模型悄然失效之处。在一个根本没有灭火器的房间里让它去找灭火器，一个总是会给出答案的模型便会自信满满地把暖气片框出来——而在自动化流水线中，这就变成了资产库里的一个幻觉对象，或是智能体循环中的一次误触。

WeVisOne-VL-2B 反而回答 None，论文将拒答作为与准确率并列的独立指标来报告。在 RefCOCOg 上，它报告对缺失对象查询的拒答率为 50.2，而同一张表中 Rex-Omni-3B 为 0.5，LocateAnything-3B 为 0.6。这与最大化召回率是不同的设计目标，而正是这个数字让一个小模型可作为组件使用：一个会说“不存在”的几何分支可以安全地送入规划器，而一个会凭空编造边界框的分支则会悄无声息地破坏它。

UI-Venus-2-9B 从动作侧切入同一问题，继承了 UI-Venus 系列的拒绝感知定位能力——它经过训练，当请求的元素不在屏幕上时会拒绝，而不是猜测一个看似合理的坐标。其安全表显示了它所声称的效果：在 OSHarm 上的攻击成功率为 11.3%，而 Qwen3.5-9B 基座为 25.3%；在 OSBlind 上为 48.8%，而 Qwen3.5-9B 基座为 79.4%。模型卡还明确指出，这并不能消除有害动作风险，并建议进行人工确认以及应用层防护措施。两个团队都选择弃权而非覆盖率；但这一选择尚未得到独立测量。

让 2B 与 9B 并排运行

这两个模型之间的真实关系不是竞争，而是先后衔接。一个返回几何信息，另一个据此采取行动。如果你正在构建屏幕自动化系统，一种合理的架构是让 WeVisOne-VL-2B 在前，作为报告什么在哪里的组件——边界框、OCR 文本片段、掩码——并让 UI-Venus-2-9B 在后，作为决定要做什么的组件。这是组合，不是竞争，而且这是这种配对在运行层面唯一说得通的框架。

显存让这种组合在一台机器上成本很低。在 bfloat16 下，2B 主干在解码器之前大约有 4GB 权重，而 9B 分四个分片总计约 18.8GB。两者都能放进单张 24GB 显卡，并为上下文留出空间；仅 2B 就能放进 8GB 显卡，这才是更有意思的事实。上下文上限都一致为 262,144 个位置，但含义不同：智能体把长上下文当作回合记忆，保存截图历史；而感知模型已发表的评估大约以每张图像 1,960 个视觉 token 运行。对于单轮纯图像模型而言，256K 窗口是一个上限，而非已证明的能力。

成本正是两者形态分化之处。两家厂商都不公布每 token 的价格，因此对二者而言，真实成本都是在自租或自有的硬件上消耗的 GPU 小时数。智能体在每一步都要为一次 9B 前向传播加上推理 token 付费，而一个回合包含许多步——这个数字你无法从规格卡上预测。感知模型则为每张图像支付一次 2B 前向传播加一次解码器前向，一张图像就是一次调用。十万张产品照片是按图像可预测的算术；而一个浏览器任务则不然。

这也正是路由层真正体现价值、而不只是口号的地方。今天这两个模型都不在 OrcaRouter 上——我们核对了包含 209 个模型的实时目录，而 WeVisOne-VL-2B 的模型卡明确说明它根本未被任何推理服务提供商部署。对于我们所服务的模型，有用的特性是一个 OpenAI 兼容端点，0% 加价，提供商标价原样透传，一个路由 DSL，可将多个模型调用组合到单一接口之后，以及自动故障转移。对于像上述这样的两段式架构，DSL 正是组合逻辑所在之处，也是任一段都能在不重写调用方的情况下被替换的地方。等这两个模型中的任何一个接入某家提供商，那将是判断它是否该进入你的技术栈的最便宜方式。

许可证、价格，以及无人证实的内容

WeVisOne-VL-2B 的模型卡为“本仓库中由腾讯编写的代码”授予 Apache 2.0 许可，这是大多数团队想要的宽松答案。有一个细节让情况变得复杂：GitHub API 将该仓库的许可证报告为“Other”，且没有 SPDX 标识符。这些说法不一定相互冲突——第三方组件会保留自己的条款——但这意味着在将其用于产品之前，值得阅读许可证文件，而不是只看许可徽章的表面信息。

UI-Venus-2-9B 的模型卡是尚未解决的那一项。其中写明，模型权重许可证有待最终确认，并将在公开发布前补充；早先的 Apache-2.0 声明是有意未沿用，因为上游材料包含相互矛盾的许可证声明。这句话自八月起就一直留在模型卡上，且从未更改。它不会阻止评估或大多数内部使用，但基于这些权重构建的外部产品建立在一个悬而未决的问题之上，而没有任何基准测试分数能解决它。

两个模型都没有厂商设定的价格。WeVisOne-VL-2B 没有推理服务提供商，也没有价目表。UI-Venus-2-9B 没有第一方端点，inclusionAI 也没有公布定价，因此第三方托管方收取的任何费用都是该托管方的报价，而不是该团队的定价。

该选哪一个

这个决定是一份职位描述，而不是一个排名。

• 如果你需要的是几何信息——将边界框送入标注流水线、为编辑工具生成掩码、为产品图像生成 alpha 遮罩、在密集画面中计数，或需要附带坐标的 OCR——那就选择 WeVisOne-VL-2B，尤其是在你需要它在小型硬件上运行时。它是这里唯一能根据文本提示返回遮罩的模型，在抠图方面胜过自家更大的同系列模型，而且其许可证是已经确定的那一个。

如果你需要的答案是已完成的任务——填好的表单、已完成导航的应用、解出的验证码、执行完的桌面工作流——那就选 UI-Venus-2-9B。你买的是一个智能体循环，而且事先就该知道：许可证尚未确定，长时程桌面工作在这个规模上尚未解决——该卡自身的 OSWorld 2.0 数据是 7.5 部分完成、0.0 二元完成。

• 如果你真正想要的是一个小型 GUI 定位模型，那就改选 UI-Venus-1.5-2B。它是 inclusionAI 产品线中基于 Qwen3-VL 的 2B 模型，在 ScreenSpot-Pro 上得分为 57.7，而且它正是这场对比的名称所暗示、却并未点名的同尺寸对比模型。

• 如果你要构建需要精确观察然后再执行操作的屏幕自动化，请按顺序运行两者——先运行几何分支，再运行智能体分支，使用一块 GPU。

• 等等，如果你的决定取决于 WeVisOne-VL-2B 的某个 GUI grounding 数字。这个数字目前还不存在，而根据参数量来猜测它并不是一种方法。

什么会改变这个答案

四件事，按有用程度排序。在 ScreenSpot-Pro 或 ScreenSpot-V2 上跑一次 WeVisOne-VL-2B，就能把本文的核心空白转化为一项对比；鉴于该模型才发布一天且采用 Apache 2.0，对任何有 GPU 和评测框架的人来说，这不过是周末的工作量。解决 UI-Venus-2-9B 的许可证问题，将消除一个任何准确率数字都无法辩驳的障碍。推理服务商上架其中任一模型，就能用实际价格取代 GPU 小时数的估算。而一项 4B 到 2B 的对比，若能解释较小模型为何表现更好，就会告诉买家这一系列的命名到底有没有意义。

在那之前，看待这两者的有用方式，不是把它们当作排行榜上的对手，而是当作不同的工具：一个衡量图像，一个在屏幕上行动。这个对决的名称暗示你是在两个实力相近的小模型之间做选择。你其实是在一个 2B 专家模型和一个 9B 智能体之间做选择，而它们唯一真正共有的，就是爱说“不”的习惯。