WeVisOne-VL-2B：Tencent 发布了一款感知模型，却没有告诉任何人

WeVisOne-VL-2B 模型卡片里最关键的一句话，说的并不是这个模型本身，而是一个名为 mask_decoder.pt 的文件：9,511,460 个参数，却只用一句平铺直叙的话描述为“必需的核心组件，而非可选附加项”。腾讯这款新感知模型的一切行为——你拿到的是一个框、一个点、一张二值掩码，还是一张连续的 alpha 遮罩——都要经由这个解码器。而它所归属的模型，几乎是在毫无仪式感的情况下登场的：WeVisOne-VL-2B 的权重于 2026 年 10 月 22 日 09:47 UTC 上传到 Hugging Face，一个 GitHub 仓库在五十分钟前才刚出现，同日还发布了一篇论文，而腾讯既没有发布上线博文，也没有配任何公告。

这对读者而言意义有限但有用。这不是一个可以注册使用的产品，而是一个可下载的研究发布版本，附带一篇论文，其中报告了模型卡未重复给出的数字，以及一组模型卡比多数厂商表述得更直白的限制。以下是可从代码库核实的内容、论文中声称的内容，以及尚无人验证的内容。

落地了什么，以及那些显示其多么悄无声息的时间戳

这里的每个日期都来自公开时间戳，而不是来自新闻稿，因为根本没有新闻稿：

• Hugging Face — tencent/WeVisOne-VL-2B 创建于 2026-10-22 09:47:50 UTC。其 4B 同级模型在二十四秒后创建，这正是组织一次性批量推送文件进行上传时的样子。

• GitHub — Tencent/WeVisOne-VL于当天上午 08:58:16 UTC 创建。截至本文撰写时，它仅有一个提交“Initial public release of WeVisOne-VL”，时间戳为 2026-10-23 08:14 UTC，并获得 46 个星标。

• 论文 — arXiv 2610.31329，《WeVisOne-VL：从物体到像素的统一视觉感知》，v1 于 2026 年 10 月 22 日提交，作者为 Tianming Liang、Junyi Pan、Yuxi Li、Canmiao Fu、Zhipeng Huang、Chong Sun、Chen Li 和 Jing Lyu，均来自腾讯公司微信视觉团队。

• 项目页面 — tencent.github.io/WeVisOne-VL已上线，包含演示、方法部分和结果表格。这是一个研究页面，不是产品页面：没有定价、没有 API、也没有注册入口。

查看时，卡片本身显示有 3 个赞，而 4B 上只有 1 个赞。下载计数器显示为零，这主要说明计数器存在延迟；老实说，实验室之外几乎还没有人碰过它，本周发表的任何文章——包括这篇——依据的都是论文和代码仓库，而不是实际结果。

有一个细节值得提出来，因为采购环节会遇到：模型卡为“本仓库中由 Tencent 编写的代码”授予 Apache 2.0 许可。GitHub API 报告的仓库许可证为“Other”，且没有 SPDX 标识符。这两种说法未必冲突——第三方组件保留自己的条款，模型卡也说明了这一点——但这意味着，在它被用于任何产品之前，值得先读一读许可证文件。

该架构押注的是 token，而非更大的模型

WeVisOne-VL-2B 基于 Qwen3-VL 构建，拥有约 20 亿参数，并且做了一件对视觉语言模型来说略显不同寻常的事：它将 查找与绘图。

语言侧负责查找。它拥有专用的坐标 token，<0> 到 <1000>，用于编码归一化的框和点，因此一次检测实际上就是模型与其文本在同一流中输出的一串 token。当查询的目标不存在时，它会返回 None，而不是凭空编造一个框。对于密集任务，它还会多输出一个特殊 token，<OBJ>，位于 token ID 152678，紧接在每个预测框之后——这个标记表示“该实例在下方继续”。

像素侧负责绘制。mask_decoder.pt在每个<OBJ>处读取隐藏状态，将其与傅里叶编码的框先验结合，并生成实际的掩码。它包含三个阶段：一个作用于多级 Qwen3-VL 合并前 ViT 特征的视觉特征适配器；一个带有六个可变形交叉注意力块的框引导查询解码器；以及一个密集预测头，围绕腾讯所称的 FullCanvasAlphaCascadeHead 构建，该头在 S/4、S/2 和 S/1 上细化，以步幅 1 输出全分辨率连续 alpha 遮罩。

真正重要的设计选择是最后一个。大多数具备定位能力的 VLM 会返回二值掩码或多边形。Alpha 蒙版是一张边缘柔和、逐像素的不透明度图——正是将人物合成到新背景、又不在头发周围产生光晕时所需的东西。这是一种与分割不同的输出类型，也正是该模型作为单独版本发布、而不是作为通用 VLM 的微调版本存在的原因。

论文所声称的，以及卡片不会告诉你的事

模型卡中没有基准测试表。没有上下文长度，没有吞吐量数据，没有训练 token 数，没有硬件要求，也没有价格。模型卡提供的是接口、架构、预期用途和局限性。

数字都在论文里，分布在七张任务表中，以及 Tencent 所称的三十多个基准测试中。以下所有结果都是作者自己的结果，由作者运行，且未经任何独立方复现：

• 检测——在 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 的差距最为惊人：在一个以拥挤场景为主题的基准上，达到了基线的六倍。

• 拒识——在 RefCOCOg 上，该 2B 模型对缺失目标查询报告的拒识率为 50.2。同一张表中两个专用定位模型 Rex-Omni-3B 和 LocateAnything-3B 分别报告 0.5 和 0.6。能说出“不在那里”，正是感知系统与演示样机之间的主要区别。

• 计数——在 PixMo-Count 验证集和测试集上分别取得 90.9 和 88.1 的精确匹配，但在 CLOC 上仅为 27.5 和 26.9，在 KubriCount 上为 29.5 和 32.4，在 CountQA 上为 47.9。计数数据集之间的这种差异是论文中最诚实的部分：计数不是单一技能，而这个模型擅长其中一些。

• OCR — 在 HierText 上平均 F1 为 30.5，在 ICDAR2015 上为 42.6，在 TotalText 上为 42.5，在 SROIE 上为 62.1。这些是在 0.5 IoU 阈值下具有定位感知的 F1 分数，而非转录准确率，因此不能与你看到的针对消费级 VLM 引用的 OCRBench 数值相提并论。

• 分割——在 RefCOCO 验证集上累积 IoU 为 79.7，RefCOCO+ 验证集上为 73.1，RefCOCOg 验证集上为 74.4，ReasonSeg 验证集上为 60.9。论文明确指出，RefCOCO 系列的数字是 cIoU，ReasonSeg 的数字是 gIoU。

• 抠图——在 P3M-500-NP 上使用框提示时，平均绝对差值为 6.6，而 SAM2-Matting 为 15.4。在 AM-2K 上，为 5.7，而后者为 12.1。在更难的 WeRefMat 指代分割划分上，为 15.8，而 Qwen3-VL-8B 加 SAM2-Matting 流水线为 23.0。以上所有指标均为越低越好。

在引用 4B 之前，有一处内部不一致值得了解：在 P3M-500-NP 抠图任务上，较小的模型实际上胜过了较大的模型，MAD 为 6.6 对 7.3。Tencent 没有解释原因，这也提醒我们：这些是单次运行的表格，而非已有定论的排名。

在证据薄弱之处

论文自己的局限性部分异常直白，而这应当影响你如何理解上文的一切。它说，有限的通用训练数据“可能会削弱相对于基模型的通用能力”。换句话说：让它在感知方面表现出色的微调，可能反而损害了它作为通用助手的能力。论文中没有任何内容测试这一点——在七张表格中，任何地方都没有 MMMU、MMBench、DocVQA 或图像描述基准。

另外三项限制属于架构层面的问题，无法通过提示词修复。为提升推理效率，该模型在不使用思维链的情况下生成结构化输出；它是单轮的；并且像素解码器不接受视频网格。腾讯还指出，基准测试的提示词“清晰、格式良好且无歧义”，而真实用户指令往往含糊不清——这等于坦率承认，评估设置抬高了模型的表现。

工程师最先遇到的正是这些实际缺口。论文没有公布上下文长度。论文的训练阶段使用了 4,096 和 8,192 个 token，推理时采用贪心解码，并将每张图像的视觉 token 上限设为 1,960 个，但这些都是明确说明的部署上下文窗口。没有 GGUF，没有量化版本，没有 ONNX 导出，也没有提及 Apple Silicon。腾讯没有提供托管端点，也没有推理提供商在提供该模型的服务。

如果你想的话，那就跑吧

受支持的路径是腾讯自己的软件包。从 GitHub 仓库安装它，然后按名称加载检查点，并调用 predict，传入图像、任务、查询和温度。卡片还展示了通过图像-文本到文本管线的 Transformers 路径，并将 vLLM、SGLang、Docker、Colab 和 Kaggle 列为部署途径。

任何走马观花的人都会踩到两个坑。第一，mask_decoder.pt 不是可选项——必须把它连同权重一起下载，否则密集任务就没有可运行的东西。第二，默认是在温度为零下进行贪心解码，模型卡也建议保持这一设置；这个模型输出的是结构化坐标，采样对它没有任何好处。

这也正是路由层真正派上用场的地方，而值得在这里把这意味着什么说清楚。OrcaRouter 并不提供 WeVisOne-VL-2B——它不在我们的产品目录中，我们也不会假装它在。路由器能帮上忙的，是围绕它进行的比较：如果你正在评估一个自托管的感知模型与托管式通用视觉模型，那么这些托管模型都只需一个 API 密钥，即可按提供商标价且无加价使用，因此搭建评测框架并不意味着要签三份合同。自动故障转移可在你的 GPU 机器繁忙时保持该框架的托管侧持续运行，而路由 DSL 让你能将自托管调用和托管调用放在同一个端点之后，同时由你决定哪一个能在生产环境中赢得一席之地。

怎样才能让它从一个存储库变成一个故事？

三件事，目前都还不存在。独立运行是最重要的一项：上面每个数字都来自腾讯，跑在腾讯自己的评测框架上，而拒识率和抠图差值恰恰是那种换别人来跑就会变动的说法。公告是第二项——仓库、论文和项目页都是官方一方发布的，但都不是正式发布，而一篇像样的文章很可能包含论文中压缩掉的训练细节。框架支持是第三项：模型卡列出了 vLLM 和 SGLang，但合并进上游的内核或官方检查点转换，与部署表里的一行相比，是不同级别的承诺。

在其中某一项落地之前，对 WeVisOne-VL-2B 的准确描述是这样的。它是一个带有巧妙接口的 2B 感知模型——坐标作为 token、实例作为标记、像素交给独立解码器——它在检测、拒识和抠图方面相较自身基座模型报告了大幅提升，却完全没有公布通用能力数字，而且任何人都无法通过 API 调用它。如果你需要从照片中抠出一个人并保留其头发，这种组合足够有趣，值得下载。如果你需要一个能回答图片问题的视觉助手，这不是你要找的文件，论文也坦率地说明了这一点。