WeVisOne-VL-4B 对比 UI-Venus-2-9B：一个返回掩码，另一个返回点击

把同一张结算页面截图分别交给 WeVisOne-VL-4B 和 UI-Venus-2-9B，你会得到两类不同的答案。前者给你几何信息：购物车图标周围的边界框、优惠字段周围的分割掩码、将商品图从背景中抠出的 alpha 蒙版。后者给你一个动作：下一次点击的坐标，以及产生该点击的推理过程。腾讯微信视觉团队在未发布公告的情况下将 WeVisOne-VL-4B 发布到了 Hugging Face，并将其技术论文的日期标注为 2026 年 10 月 23 日；inclusionAI 的 UI-Venus-2-9B 自 2026 年 8 月 26 日起即可下载。它们被归入相同的模态标签之下，但彼此不能替代。

这使得其核心成为一个带有不寻常问题的比较：两个模型没有共同的基准。两张模型卡上没有任何一个分数同时出现。二者都没有经过独立评估，都没有由推理服务提供商部署，也都没有公布价格。能够诚实比较的是：每个模型输出什么、各自被训练成如何拒绝、运行成本是多少，以及你将依据哪种许可证发布——所以本文正是这样做的，并且每当出现供应商报告的数字时，都会将其标记为供应商报告。

这两个模型回答的不是同一个问题。

WeVisOne-VL-4B 是一个感知模型。它构建在 Qwen3-VL 主干之上，并增加了一个必需的 960 万参数像素解码器——mask_decoder.pt，作为第二个产物发布——该解码器将语言模型的框预测转换为实例掩码，再转换为步幅为 1 的 alpha 蒙版。坐标以专用 token 形式输出，取值范围从 <0> 到 <1000>，并相对于图像归一化；在密集任务中，一个特殊的 <OBJ> token（id 152,678）会闭合每个框。论文的任务列表是一组几何任务：开放词汇检测、指代定位、计数、指向、OCR 定位、指代分割和可提示 alpha 抠图。

UI-Venus-2-9B 是一个智能体。它基于 Qwen3.5-9B 初始化，并通过中期训练、离线步级强化学习和多教师同策略蒸馏，在仅基于截图的交互上针对五类任务进行了训练——定位、CAPTCHA、移动端、网页端和计算机端。其输出是“观察—推理—行动”闭环中的一个动作；其 vLLM 配置将 --max-model-len 262144 与 --reasoning-parser qwen3 搭配使用，因为它在每次行动前都会生成推理 token。

把规格参数并排放在一起，差异立刻显现：

• 输出内容——来自 WeVisOne-VL-4B 的边界框、点、掩码和 alpha 蒙版；来自 UI-Venus-2-9B 的一个动作及其推理轨迹。

• 骨干网络 — WeVisOne-VL-4B 使用 Qwen3-VL；UI-Venus-2-9B 使用 Qwen3.5-9B。文本栈分属不同代际、不同家族。

• 规模 — 尽管名称中带有“4B”，仓库中列出的却是 5B 参数，另有一个单独的 9.6M 参数解码器；UI-Venus-2-9B 的 9B 稠密模型分为四个 BF16 分片，约 18.8 GB。

• 权重格式 — {{2}}WeVisOne-VL-4B{{/2}} 模型卡使用 {{1}}F32 safetensors{{/1}}，这在这个规模下并不常见，并且使得下载体积大于参数数量所暗示的大小；{{4}}UI-Venus-2-9B{{/4}} 使用 {{3}}BF16{{/3}}。

• 许可证 — WeVisOne-VL-4B 采用 Apache 2.0；UI-Venus-2-9B“尚待最终确认”。

实际后果是：你不能用一个替代另一个；任何给出“赢家”的文章，回答的都是你并没有问的问题。一个能返回完美掩码的感知模型，仍然无法完成点击。一个能完美点击的智能体，也仍然无法交给你产品拍摄所需的遮罩。

在它们真正重合的地方：两个团队都教会了自己的模型说“不”

这是两个版本都做出的同一个设计决策，也是这对组合中最有意思的地方。开放词汇定位模型会以一种特定且代价高昂的方式失败：在一个根本没有灭火器的房间里要求它找出灭火器，而一个总是会给出答案的模型就会自信地把暖气片框出来。到了下游，这要么是你资产管线中的一个幻觉物体，要么是你自动化循环中的一次误触。

WeVisOne-VL-4B 通过返回 None 来处理，论文将拒绝率作为独立指标与准确率并列报告。在 RefCOCOg 上，4B 模型的拒绝率达到 67.4，而其 Qwen3-VL-4B 基座为 18.8。在微信内部的 WeRef-Bench 上，它报告的拒绝率为 96.4，基座模型为 61.9；在 Ref-ZOM 上为 86.0，UniPixel-7B 为 0.3。这些数据来自今日发表的一篇论文，且为作者自报；拒绝基准也 largely 是作者自建的——可将方向视为可信，但具体差距未经验证。

UI-Venus-2-9B 从智能体侧切入同一问题，继承了 UI-Venus 系列的拒绝感知定位能力：模型经过训练，当所请求的元素不在屏幕上时会拒绝，而不是猜测一个看似合理的位置。其定位数值——ScreenSpot-Pro 73.0、VenusBench-GD 77.1、OSWorld-G-R 78.5——由厂商报告，且模型卡明确表示，这并不能消除有害操作风险，并建议进行人工确认以及采取应用层防护措施。其安全表显示了它确实声称的效果：在 OSHarm 上攻击成功率为 11.3%，而 Qwen3.5-9B 基座为 25.3%；在 OSBlind 上为 48.8%，而后者为 79.4%。

因此，这两个模型都是由曾目睹本地化人员撒谎的团队构建的，而且二者都选择弃权而非覆盖。如果你的应用的失败模式是“自信地犯错”，那么这一共同优先级比参数数量更重要。

腾讯模型卡未展示的数字

迄今为止，关于 WeVisOne-VL-4B 的每一篇报道都正确地指出了同一件事：模型卡没有公布任何基准测试结果。技术论文公布了，而且论文于 2026 年 10 月 23 日发布，这使得它成为这件事中尚未流传开的部分。所有这些结果均由作者自行报告，尚无任何一项被独立复现，而且该模型才发布一天——因此请把这些视为有具体轮廓的说法，而不是已有定论的结果。

与其自身的 Qwen3-VL-4B 基座相比，这些差距足够大，即便大幅打折后也仍然值得关注：

• 检测，COCO 零样本平均 F1——WeVisOne-VL-4B 为 57.1，Qwen3-VL-4B 为 48.7；在 LVIS 上分别为 55.3 和 44.0。

• 检测，Dense200 平均 F1 — 71.3 对 15.2。这不是论文表格里的笔误；密集小目标场景正是基础模型崩溃的地方。

• 指代检测，RefCOCOg 验证集——80.8 对 74.1，拒绝率为 67.4 对 18.8。

• 计数任务，PixMo-Count 验证集精确匹配 — 93.7 对 69.6；在 MixCount 验证集上，42.0 对 3.5。

• 指向，PointBench F1 — 71.9 对 57.1。

• OCR 定位，SROIE 平均 F1 —— 68.1 对 40.4，并领先于 PP-OCRv5 的 58.6。

• 指代分割，ReasonSeg 验证集 gIoU — 71.2，而 LISA-13B 为 65.0。

• 可提示抠图，AM-2K 框提示 MAD —— 5.0，而 SAM2-Matting 为 12.1；在 WeRefMat 指称提示上，为 9.8，而后者为 51.9。

抠图结果是最值得停下来细看的一项，因为这是这一价位段里其他任何东西都无法通过提示词提供的能力。向视觉语言模型要求“那个人，作为 alpha matte”，并得到步长为 1、在 MAD 上胜过 SAM2 抠图流水线的输出，这与附带掩码的检测头是不同产品。这也正是论文对自家 4B 最不留情面的地方：在 P3M-500-NP 框提示上，2B 模型得 6.6 MAD，而 4B 为 7.3，所以更大的变体并非全面更好，作者也把这一点白纸黑字写了出来。

UI-Venus-2-9B 的数值衡量的是什么，以及它们为何无法迁移

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

最接近共同比较轴的是 GUI grounding。UI-Venus-2-9B 在 ScreenSpot-Pro 上得分 73.0，该基准用于在高分辨率截图中定位小型界面元素——而 WeVisOne-VL-4B 未报告这一结果。WeVisOne-VL-4B 报告了 OCR 定位和 dense pointing（密集指向）结果，而 UI-Venus-2-9B 未报告这些。因此，诚实的立场是：这项比较中最有用的那个数字目前还不存在：让 WeVisOne-VL-4B 跑 ScreenSpot-Pro，才能看出一个 5B 的感知专家模型是否在寻找按钮这件事上胜过 9B 的智能体；在有人实际跑出结果之前，任何按 grounding 给这两者排名的人都是在猜。

该智能体自带的测试套件也将其弱点公之于众。在 OSWorld 2.0 上，9B 模型得分为 7.5 部分得分和 0.0 二值得分；27B 同级模型则达到 13.2 部分得分和 2.8 二值得分。在这个规模上，长时程桌面工作尚未解决，模型卡也如实说明了这一点。

在服务它们方面的差距比基准差距更大。

对于一个正在决定下周要运行什么的团队来说，运营层面的差异会比任何分数都更重要。UI-Venus-2-9B 是单一模型，只需一条 vLLM 命令即可启动，并暴露一个 OpenAI 兼容端点，张量并行度为 1。WeVisOne-VL-4B 需要从 GitHub 获取其推理包，外加单独的解码器产物，并且要通过自己的 WeVisOneVL(...) 包装器并传入任务参数来调用——predict(image, task="matting", query="person", temperature=0.0)。模型卡记录了 Transformers、vLLM 和 SGLang 路径，但像素解码器不是可选的：仅靠语言模型无法生成掩码。

显存占用比参数数量所暗示的更接近。在 bf16 下，5B 主干在解码器之前约为 10 GB，而 UI-Venus-2-9B 的四个分片约为 18.8 GB。就权重而言，两者都能装进单张 24 GB 显卡；不同之处在于还剩多少空间留给上下文。

在上下文方面，这两个配置呈现出一种容易被人过度解读的一致性。WeVisOne-VL-4B 的配置提供 max_position_embeddings 为 262,144——与 UI-Venus-2-9B 凭借其 262,144 最大模型长度所达到的上限相同。但它们将其用于不同目的：智能体将长上下文视为情节记忆，用来保存任务的截图历史，而感知模型公布的评估则以每张图像 1,960 个视觉 token 运行。对于单轮、仅图像模型而言，256K 窗口是一个上限，而非已证明的能力，并且模型卡将视频网格列为被像素解码器直接拒绝。

许可证：其中一项已确定，另一项尚未确定

{{1}}WeVisOne-VL-4B{{/1}} 采用 Apache 2.0 许可，其中由腾讯编写的代码也遵循相同条款。你可以阅读它、分叉它、将它发布到产品中，而无需就此咨询律师。

UI-Venus-2-9B 的模型卡片上写明，模型权重许可证仍待最终确认，并将在公开发布前补充；并且此前 Apache-2.0 的声明是有意不沿用，因为上游材料包含相互冲突的许可声明。这句话自八月起就一直在卡片上，至今未变。它不会妨碍你评估该模型，也不会妨碍大多数组织内部使用——但这确实意味着，基于这些权重构建的外部产品是建立在一个未解决的问题之上，再高的基准分数也无法弥补。如果你要在两者之间为打算发布的产品做选择，许可证那一列比准确率那一列更快决定结果。

既然两者都没有标价，每一个分别要花多少钱

这两个模型都没有厂商设定的按 token 价格。WeVisOne-VL-4B 的页面称，它没有由任何推理服务商部署；UI-Venus-2-9B 没有第一方端点，inclusionAI 也没有公布价目表，因此第三方托管商对它收取的任何费用都是该托管商的价格，而不是团队的价格。对两者而言，成本都是在你自己租用或拥有的硬件上消耗的 GPU 小时数，这意味着比较的不是“输入价格 vs 输出价格”，而是“我需要多少张卡，以及它每秒能处理多少张图像”。

两篇论文都没有公布吞吐量或延迟，因此对两者来说，第二个数字都未知。可知的是成本结构：UI-Venus-2-9B 在回合的每一步都要承担一次 9B 前向传播加上推理 token 的开销，而智能体回合包含许多步骤。WeVisOne-VL-4B 每张图像都要承担一次 5B 前向传播加上一次解码器前向传播的开销，而一张图像就是一次调用。如果你的工作负载是十万张产品照片，感知模型的成本是按图像计算的，且可预测；如果是浏览器任务，智能体的成本会随任务需要执行多少动作而扩展，而这个数字恰恰是你无法从规格表上预测的。

这也正是路由层真正体现价值、而非沦为口号的地方。今天这两个模型都不在 OrcaRouter 上，本文也不会假装不是这样——WeVisOne-VL-4B 完全没有推理服务提供商，UI-Venus-2-9B 则由第三方托管提供服务，而非来自我们自己的目录。对于它确实服务的模型，OrcaRouter 提供的是一个兼容 OpenAI 的端点，覆盖200+个此类模型，0% 加价，供应商标价原样透传，因此厂商降价在发生当天就能传导到你这里，而不必等到下一次合同续约。对于按顺序调用感知模型和智能体模型的架构，路由 DSL 正是这种组合逻辑所在之处——两次模型调用，一处即可替换任一侧——而自动故障转移则能在其背后的模型于任务中途降级时，让智能体循环继续存活。一旦这两个模型中的任何一个登陆某家提供商，那就是判断它是否属于你的技术栈的最便宜方式。

该选哪一个

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

• 如果你需要的输出是几何信息——将边界框送入标注流程、为编辑工具生成掩码、为产品图像生成 alpha matte、统计密集航拍画面中的物体数量，或带坐标的 OCR——那就选 WeVisOne-VL-4B。在开放的 5B 级别中，没有其他模型能根据文本提示返回 matte，而论文中与 SAM2 流程对比的抠图指标是本次发布中最有力的主张。

• 如果你需要的是完成后的任务——表单已填写、应用已导航、验证码已解决、桌面工作流已通过截图驱动——请选择 UI-Venus-2-9B。它以一个 vLLM 命令交付，并附带 OpenAI 兼容端点，这只需一天而非一周的工作量；其 AndroidWorld 和 WebVoyager 结果是你需要对照自身环境核验的数值。

• 如果你需要独立证据、已公布的价格，或用于可交付产品的明确许可，那么目前两者都别选。对于 UI-Venus-2-9B 的许可，以及两个模型的基准测试而言，这三者都缺失。

• 如果你要构建的智能体需要操控图像，而不仅仅是点击浏览各个界面，那就两者都用上。真正有意思的是这种组合：UI-Venus-2-9B 决定在哪里执行操作，WeVisOne-VL-4B 则生成该操作所指向的像素级精确产物。代价是每一步需要调用两次模型，换来的是任何单一模型都不具备的精确度。

什么会改变这个答案

四件事，按它们能对其产生多大推动作用的顺序排列。

WeVisOne-VL-4B 的一次 ScreenSpot-Pro 运行。这是双方都可能合理采用的唯一基准，也能判定一个规模只有一半的感知专家是否能在定位上胜过专门构建的 UI 智能体。任何有 GPU 和一个下午的人都能跑出这个结果，却没有人做。

对任一模型的独立评估。本文中的每一个数字都可追溯到模型卡，或由构建该模型的团队撰写的论文。这在发布当天很正常，但这仍然是一种缺失。

UI-Venus-2-9B 的许可证问题已得到解决。卡片上已经挂了八周的“待最终确认”。如果最终确定为宽松许可证，这个智能体就明显更容易被推荐用于商业用途；如果不是，那这个问题就从相反方向得到了回答。

为任一方提供第一方端点。目前两家厂商都不托管自家模型，这使目标受众局限于愿意运行服务栈的团队，而在 WeVisOne-VL-4B 方面，则局限于愿意维护自定义推理包的团队。厂商公布费率后，成本比较就不再是算术题，而会变成账单上的一项明细。

在此之前，公允的总结是这样的：腾讯推出了一套感知工具包，做到了此前任何小型开源模型都未曾做到的事，而且低调到它自家的基准测试表格至今尚未被人细读；蚂蚁集团则早了一个半月推出了一个智能体，它更易于运行，却更难获得许可。二者并非竞争对手。真正的错误在于，仅仅因为其中一个在两者并不共用的基准测试上得分更高，就选择了它。