WeVisOne-VL-4B：腾讯未发任何发布公告就悄然推出的4B视觉模型

在 P3M-500-NP 这一从图像中提取软边缘的标准基准上，腾讯能找到用于对比的最佳 alpha matte 的平均绝对差为 15.4。WeVisOne-VL-4B 得分为 7.3。这大约是一个专用抠图流水线误差的一半，而它由一个 40 亿参数的视觉语言模型生成；该模型还用同一套权重执行检测、计数、OCR 和分割。WeVisOne-VL-4B 是微信视觉团队的一次尝试，旨在把一堆感知专家模型压缩成一个下一词元预测器，这确实是一项有趣的工作。但它目前还不是产品：本站找不到腾讯的博客文章、新闻稿、托管端点，也没有任何形式的公告。权重于 2026 年 10 月 22 日上传到 Hugging Face，此后该模型一直公开，但悄无声息。

本文是对这些代码仓库实际包含内容的解读，并区分了两件容易被混淆的事：哪些是你可以通过下载模型来验证的，哪些只是腾讯自己的论文所声称的。两者都重要。但只有其中一个是证据。

发布的是什么，以及何时发布

这份记录异常干净，因为一切都带有时间戳。Hugging Face 仓库 tencent/WeVisOne-VL-4B创建于 2026 年 10 月 22 日 09:48 UTC；GitHub 仓库 Tencent/WeVisOne-VL创建于五十分钟前，即当天上午 08:58 UTC；arXiv 论文 2610.31329 的提交日期为 10 月 22 日。一个 2B 的同系列版本 tencent/WeVisOne-VL-2B也一同出现。

到写这篇文章时，4B 仓库在第二天早上又被修改过一次，并积累了几个点赞，却没有有意义的下载量。这些计数只是一个快照，不是定论，但它们确实告诉了你一些论文无法告诉你的东西：几乎还没有人拉取过这个模型。该 GitHub 仓库有 46 个星标和少量 fork，其 README 的 TODO 列表本身就是一份状态报告——推理包、cookbooks 和评估流水线已勾选；Gradio 演示和微调代码则没有。

所以，准确的描述既不是“泄露”，也不是“发布”。它是一次官方开源投放，具备一次正式发布所需的全部配套骨架——论文、权重、代码、基准测试流水线——却唯独没有任何营销。之后是否会发布公告尚不可知。任何称腾讯“揭幕”或“发布”了该模型的人，都是在描述一件尚未发生的事。

一个主干，七种输出类型

该架构并不像基准表听起来那么奇特。WeVisOne-VL-4B 是一个 Qwen3-VL 模型——仓库元数据将 Qwen3VLForConditionalGeneration 列为架构，并以 F32 列出 48.3 亿个参数——在模型卡上四舍五入为 5B——经过微调以输出结构化坐标 token 而非散文。边界框和点被编码为从 <0> 到 <1000> 的 token，并归一化到图像，这就是语言模型最终进行几何运算而不是描述的方式。

像素级的那一半才是值得理解的部分。模型在每预测出一个框后，都会发出一个特殊 token，<OBJ>，其隐藏状态会被送入一个单独的 960 万参数解码器，该解码器以 mask_decoder.pt 的形式提供。那个解码器——一个视觉特征适配器、六个可变形交叉注意力块，以及一个在步幅 4、2 和 1 上细化的级联头——会把框变成实例掩码，再变成全分辨率 alpha 蒙版。它不是一次 SAM 调用。循环中没有第二个模型，没有提示编码器，也没有外部分割器。整个像素路径就是外挂到语言模型上的 960 万参数。

这一设计选择解释了该基准上的表现。由于掩码和蒙版都以模型刚刚预测出的同一个边界框为条件，模型无需人工提供的边界框即可进行分割；可以要求它分割“拿着伞的人”，并返回恰好该实例的蒙版。代价是，像素解码器从不会从掩码级奖励中学习——论文的强化学习阶段会对边界框、指向和 OCR 转写进行评分，但完全不使用掩码或 alpha 奖励。稠密输出仅通过监督损失进行训练。

数字，以及这些数字属于谁

下文中的每一个数字都来自 Tencent 的论文或项目 README。没有任何一个数字由第三方复现过，而且对比集合是由作者选定的。对于一篇才发布两天的论文来说，这很正常；而这也正是厂商表格容易自我美化的情形，所以请把这些领先幅度当作声明，而不是测量结果。

该标题所声称的结果，是相对于作者为每项任务列出的最强开源基线而言的：

• 检测，LVIS F1 均值 — WeVisOne-VL-4B 为 55.3，最佳基线为 50.7

• 密集检测，Dense200 F1 均值 — 71.3 对 58.7

• 指代任务 RefCOCOg 测试 F1 均值 — 81.8 对比 77.6

• 拒答，WeRef-Bench — 对目标缺失查询的正确拒答率为 96.4%，相比之下为 73.0%

• 计数、PixMo-Count 测试准确率——89.6 对 82.8

• OCR、TotalText F1 均值 — 52.0 对比 43.3

• 指代分割，ReasonSeg 验证集 gIoU — 71.2 对比 65.0

• 箱体抠图，P3M-500-NP MAD — 7.3 对 15.4，数值越低越好

信息量最大的那一行并不在那个列表里。与 Qwen3-VL-4B——相同的主干网络，未经修改——相比，在 Dense200 上的差距是 71.3 对 15.2，在 VisDrone 上是 44.7 对 31.0。基础视觉语言模型在密集小目标检测上几乎毫无用处，而微调将它带入专家级领域。这比任何与前沿模型的比较都更站得住脚：作者展示了 4B 的通用模型可以在不增大模型规模的情况下被转化为一个合格的目标定位器。

它在哪里失效

这些局限已在模型卡中写明，而且绝非无关紧要的装饰性条款。模型每轮只处理单张图像——视频帧网格会被像素解码器直接拒绝，因此它不是视频分割工具，也并未假装自己是。它直接生成结构化输出，没有思维链，这意味着无法让它先对模糊查询进行推理、再确定边界框。Alpha 质量在精细边界、严重遮挡以及真正透明的材质上会下降，而且它对提示词的措辞很敏感——“那个女人的头发”和“她的头发”并不保证返回相同的蒙版。

拒绝行为是最容易被低估的特性。None对不存在的目标返回该值听起来微不足道，直到你在视频流上跑检测器，亲眼看着它在空无一车的停车场里凭空"幻觉"出一个行人。在 WeRef-Bench 上 96.4% 的拒绝率，对比最佳基线的 73.0%，正是"可以直接放进流水线的组件"与"必须再拿第二个模型看守的组件"之间的差别。

你实际会怎么运行它。

模型卡记录了四条服务路径：项目自带的推理包、一个 Transformers image-text-to-text 流水线、vLLM 以及 SGLang，另有一行 Docker Model Runner 命令。解码采用贪心策略，每张图像最多 1,960 个视觉 token。在 F32 下，4.83B 参数的检查点磁盘占用约为 19 GB，这还不包括 960 万参数的解码器；以 bfloat16 加载可将该体积减半。无论如何你都需要自定义推理代码——mask_decoder.pt 是必需组件，而非可选附加项，并且用原版 Transformers 加载只能得到边界框和文本，得不到掩码。

目前没有托管 API，也没有公布价格，所以诚实的说法是：WeVisOne-VL-4B 如今是一个需要自行托管的选择。如果你真正想要的是本周就把 Qwen3-VL 感知流水线投入生产，而又不想为昨天才发布的权重去准备 GPU，那么Qwen3-VL-8B instruct 版本可通过 OrcaRouter 使用——一个密钥即可覆盖 200 多个模型，按供应商列表价零加价透传，且上游端点不稳定时会自动故障转移。那是骨干模型家族，不是微调版本。它会给你边界框和描述；它不会给你 alpha 蒙版。

看什么好

有三件事能让它从“有趣的论文”变成“你应该评估的模型”。第一是独立基准测试运行——任何人在留出集上复现抠图数值，都能解决最大的悬而未决问题。第二是托管端点，来自 Tencent 或任何其他方，这会告诉你推理路径是否足够稳健、可以提供服务。第三是微调代码仍列在 README 的 TODO 清单上、尚未被核查；没有它，把抠图头适配到特定产品目录就只能靠猜。

在此之前，公允的总结是这样的：腾讯发布了一个小模型，它做了一件确实不寻常的事——从语言模型直接输出全分辨率 alpha 蒙版，整个流程里没有 SAM——而且它做这件事时并没有大张旗鼓地博取关注。权重对腾讯编写的代码采用 Apache 2.0 许可。这些说法来自作者本人。这两点事实都是可以核实的，在围绕它们做规划之前，你应该先去核实。