WeVisOne-VL-2B 对比 Moondream 3：许可证与截止期限

2026年11月13日，为 Moondream 3 Preview 提供服务的托管端点将停止响应。真正让这一比较变得紧迫的是这个日期，而不是任何基准测试：基于 Moondream 云构建的团队从停服通知起大约有三周时间来决定用什么替代它，而他们可能退而依赖的权重所附带的许可证，大多数人从未仔细读过。WeVisOne-VL-2B 显然是应当与之并列比较的对象——这是腾讯微信视觉团队推出的 2B 感知模型，于 2026 年 10 月 22 日以 Apache 2.0 发布，执行同样的 grounded 工作：边界框、点、计数和掩码。

这两个模型是这一系列中最接近的一对。两者都围绕指向目标而非描述目标来构建。两者都输出掩码。两者都被训练为在目标不存在时说出“不在那里”。然而，两家厂商发布的内容几乎无法相互做差比较，因为它们在不同的时间、不同的测试框架上测量了不同的东西。可以比较的是许可证、输出格式和部署路径——而在这三项上，答案并不接近。

为什么这两个会在同一个对话里

Moondream 3 Preview 于 2025 年 9 月 18 日发布，它证明了小型模型能够原生完成有依据的感知：检测、指向、计数、分割和回答，全都来自同一个检查点，而无需协调单独的检测器和单独的推理模型。它是一个稀疏混合专家模型，总参数为 90 亿，激活参数为 20 亿——共 24 层，前四层为稠密层，其余层每层包含 64 个专家，每个 token 激活其中 8 个——具有 32,768 个 token 的上下文、自定义 SuperBPE 分词器以及基于 SigLIP 的视觉编码器。

WeVisOne-VL-2B 晚一年推出，提出了同一论点的更窄版本。它基于 Qwen3-VL 构建，拥有 2B 参数，并将工作拆分为两部分：语言模型通过专用 token 输出坐标，而一个独立的 950 万参数解码器将每个标记实例转换为掩码或连续的 alpha 蒙版。腾讯并未试图打造通用助手。它试图打造感知引擎，并在局限性部分明确说明了这一点。

这种家族相似性真实存在，正因如此，这些差异才比不相关型号之间的差异更为重要。

能力映射，并排对比

• 参数 — Moondream 3 Preview 总参数为 9B、激活参数为 2B，而 WeVisOne-VL-2B 约为 2B 稠密参数，另需一个 9.5M 参数的解码器。

• 掩码输出——在 Moondream 上为 SVG 路径字符串外加一个边界框，其文档将其描述为原生矢量掩码；在 WeVisOne 上为步长为 1 的全分辨率栅格 alpha 蒙版，包括针对毛发和毛皮的柔和透明度。

• 推理——Moondream 3 具备可选的思维链模式，通过指向图像中的具体区域来进行推理；WeVisOne 则完全不使用思维链，直接生成结构化输出，这是腾讯为提升推理效率而做出的选择。

• 上下文 — Moondream 模型卡上公布了 32,768 个 token，而 WeVisOne 未公布上下文长度；其论文描述训练时使用 4,096 和 8,192 个 token，推理时每张图像最多使用 1,960 个视觉 token。

• 输入——两者都支持图像，但 Moondream 提供有文档记录的云端 API，可流式返回部分结果；WeVisOne 的像素解码器会拒绝视频网格，并且按设计仅支持单轮。

• 许可证 — Moondream 采用 Business Source License 1.1 并附附加使用授权，WeVisOne 采用 Apache 2.0。

• 发布日期——2025年9月18日 vs 2026年10月22日，相隔十三个月。

• 托管 — 在 2026 年 11 月 13 日之前使用 Moondream Cloud，之后仅限自托管；Tencent 或任何我们能验证的提供商均未提供 WeVisOne 的托管端点。

这些数字，连同其附带的工具

这时，比较就变成了一项阅读脚注的练习。下面的每个数字都是厂商报告的；在 Artificial Analysis 或我们能找到的任何其他地方，这两个模型都没有独立评估。

• RefCOCO — Moondream 的发布图表列出了 91.1，同时在 RefCOCOg 上为 88.6、在 RefCOCO+ 上为 81.8。这些是检测式准确率数字，而 Moondream 自己也称该图表并非公平比较：前沿基线模型是通过模板查询的，因为它们没有原生定位能力，且若干预览分数来自 100 题样本，而非完整评测集。

• WeVisOne 上的 RefCOCO —— 腾讯未公布 RefCOCO 的检测数值。其指代检测表报告 2B 模型在 RefCOCOg 上的平均 F1 为 77.1，其分割表报告 RefCOCO 验证集的 cIoU 为 79.7。任务不同、统计指标不同、数据划分也不同。

• 分割——Moondream 在 2026 年 3 月的分割更新中报告称，在 RefCOCO 验证集上 mIoU 为 83.2，在 RefCOCO+ 上为 79.1，在 RefCOCOg 上为 80.7，并在高保真 RefCOCO-M 上另有 88.2。WeVisOne 在同样三个划分上报告 79.7、73.1 和 74.4——但采用的是 cIoU，论文对此有明确说明。Mean IoU 与 cumulative IoU 对图像的加权方式不同，因此这里的差距只能说是提示性的，而非实际测量所得。

• 计数——Moondream 报告 CountBenchQA 为 93.2。WeVisOne 报告 CountQA 的精确匹配为 47.9，PixMo-Count 为 90.9 和 88.1，CLOC 为 27.5 和 26.9。CountBenchQA 与 CountQA 并非同一数据集，而且计数集上的精确匹配比多选题集上的准确率要严苛得多。WeVisOne 自身计数行内部的差距——在一个数据集上为 90.9，在另一个数据集上为 27.5——比任何跨厂商比较都更能警示计数基准的问题。

• 检测 — Moondream 列出的 COCO 检测指标为 51.2。WeVisOne 列出的 COCO 平均 F1 在不同 IoU 阈值下为 55.2。双方都未说明这些是否为同一统计量，而这正是问题所在。

浮现出来的并不是一个赢家，而是两个都声称具备强大且扎实的感知能力的模型；衡量它们的工具从未彼此校准过，其中一个还被发布在一张其作者本人称为不公平的图表上。

许可证才是真正的岔路口

Moondream 3 Preview 的权重依据 Business Source License 1.1 发布，并附带一项 Additional Use Grant，其简称是“No Third-Party Service”。该授权涵盖个人项目、研究、基准测试、微调、合并、量化以及权重增量。它不涵盖的是搭建一项让第三方能够使用该模型的服务——而这正是大多数公司真正想要构建的东西。

这是一个实质性约束，也是比较中唯一有明确答案的地方。WeVisOne-VL-2B 的模型卡对腾讯编写的代码授予 Apache 2.0 许可，第三方组件则保留其自身条款。没有收入门槛，没有使用领域排除条款，也不需要与律师讨论你的产品是否算作第三方服务。

如果你要在这两者之间做选择来构建商业产品，那么许可证对结果的决定作用比上一节中的任何基准测试都大。一个你无法合法提供服务的模型并不是更便宜的选择；它是另一种产品。

如果你现在正在使用 Moondream Cloud

关闭通知与关闭原因一同发布。Moondream 及其继任者 Moondream 3.1 现已成为 Prime Intellect 的一部分；后者于 2026 年 10 月 13 日宣布了这项收购，创始人 Vik Korrapati 和 Jay Allen 将加入并领导推理业务。Moondream 自己的帖子日期为 10 月 14 日。通知只有一行：2026 年 11 月 13 日，也就是三十天后，Moondream Cloud 将关闭，未使用的已购积分将予以退还。

有两件事值得区分开来。模型并没有被撤回——权重仍留在原处，许可证也没有变化。真正结束的是托管路径，也就是大多数团队实际会调用的那条路径。Photon 是 Moondream 的推理引擎，它属于 Prime Intellect 收购的一部分，其卖点是吞吐量：Moondream 3.1 每秒 34 个请求，单块 H100 上每秒超过 60 次推理。这些是 Prime 公布的数据，而现在 Prime 正是出售它们的一方。

对任何要迁移的人来说，诚实的选择有三个。自己托管你已有的 Moondream 权重，并接受 BSL 条款。转向一个不会下线的托管模型，同时接受其中大多数不输出掩码。或者转向一个 Apache-2.0 开放权重模型并自行掌控部署——WeVisOne-VL-2B 正是在这里登场，但需要注意，它并非可直接替换的方案，而且其证据也更为单薄。

它不能直接替换，原因有三个具体方面。输出格式不同：SVG 路径与栅格 alpha 蒙版不同，这会改变你的下游合成代码。没有思维链模式，因此任何依赖 Moondream 有依据推理轨迹的流水线都会失去这些轨迹。而且没有公布上下文长度，所以向 Moondream 输入长篇多图像提示的工作流没有明确的上限可供设计参考。

这也正是路由层能够真正发挥作用的地方，而它究竟能做什么、不能做什么，值得说清楚。OrcaRouter 并不提供 Moondream 3 或 WeVisOne-VL-2B；这两者都不在我们的目录中，我们也不会把一次迁移说成只是改个 URL。我们能做的，是让你技术栈中托管的那一侧保持可移植：一个 API 密钥即可按供应商目录价、零加价调用 200 多个模型，在供应商服务劣化时自动故障转移，以及一套路由 DSL，让你无需改动应用代码就能在托管模型之间迁移流量。如果 11 月 13 日的教训是：单一托管依赖就是单点故障，那么解决办法是抽象层，而不是换一个单一依赖。

11月13日之前需要决定什么

如果你只是通过云端 API 运行 Moondream 3 Preview、除此之外什么都不跑，那么这就不是在 Moondream 和 WeVisOne 之间做选择，而是你到底想不想自己掌控推理。自托管 Moondream 能保留你已经针对其调优过的行为，其许可证允许内部使用和研究用途，但不允许作为服务转售。自托管 WeVisOne 则能给你更清晰的条款和软 alpha 遮罩，代价是这个模型没有任何独立第三方测试过，而且它的解码器只能处理单张图像。

如果你是从零开始——没有现成的流水线、没有调校好的提示词、没有已投入的集成沉没成本——那么这笔账算起来更简单。WeVisOne-VL-2B 采用 Apache 2.0 许可证，参数量为 2B；Moondream 3 Preview 是源码可获取的，参数量为 9B，其中 2B 处于激活状态。两者都以一种看似便于比较的形式公布的唯一基准是分割，而在这个基准上，指标定义却悄然出现了分歧。先根据许可证和输出格式做选择，然后在你自己的图像上进行测量，因为两家厂商都没有给你一个能跨越这一差距而值得信赖的数字。