Moondream 3.1 9B A2B 与 UI-Venus 2 9B：一个已公布价格，一个待定许可

M​oondream 3.1 9B A2B和UI-Venus 2 9B大小相同，模态相同，返回的也是同一种基础原语——一个坐标。但只有其中一个公布了按 token 计的价格，而价格属于那个其托管端点即将被关闭的一方。M​oondream 3.1 9B A2B 在 M​oondream Cloud 上的售价为每百万输入 token 0.30 美元、每百万输出 token 1.00 美元。2026 年 11 月 13 日，也就是从今天起四周后，M​oondream Cloud——推理与 Lens 微调产品一并——将关停；这条消息于 10 月 14 日传来，同时还有 M​oondream 公司已被 Prime Intellect 收购的消息。UI-Venus 2 9B 根本没有第一方端点，因此也没有价目表。而那份能告诉你是否可以将其用于商业发布的许可证，用其自家模型卡的话说，仍在等待最终确认。

Neither of these models is new, and nothing here is a launch. M​oondream 3.1 9B A2B shipped on 7 July 2026 under the M​oondream Model License 1.0. UI-Venus 2 9B went up on Hugging Face on 26 August 2026 from inclusionAI, the Venus Team's repository at Ant Group, with its technical report following on 27 August. What actually moved inside the last seven days is on the M​oondream side: the acquisition, dated 14 October on M​oondream's own blog and a day earlier on Prime Intellect's, and the thirty-day wind-down of the hosted service that came attached to it. That is the reason this pairing is worth reading now rather than in a launch round-up. One of these two models just had its distribution channel put on a countdown; the other never had one.

今天你可以拨打什么，以及可以拨打至何时

M​oondream 3.1 9B A2B 有三种获取方式，其中一种正在倒计时。

该厂商的云服务按 token 计费：实时延迟下每百万输入 token 收费 0.30 美元、每百万输出 token 收费 1.00 美元，而在批量 API 上分别为 0.15 美元和 0.50 美元，即在标价基础上保持 50% 的折扣。微调产品 Lens 的定价为每百万训练 token 0.60 美元。访问权限是按并发数限流，而非按量计量——该厂商的速率限制页面写明，任何 API 密钥每秒可发 2 次请求，账户余额达到 10 美元后升至每秒 10 次请求。然后是截止日期：2026 年 11 月 13 日，云端推理端点和 Lens 都将关闭，未使用的已购额度将予以退还，客户则被告知将协助其迁移。

与此同时，权重哪儿也不会去。Moondream 模型许可证 1.0 允许商业自托管、微调、量化与再分发，而 Photon——厂商自家的推理引擎——可在 NVIDIA Ampere 或更新硬件以及 Apple Silicon 上本地免费运行该检查点。因此，这个截止日期划分得清清楚楚。如果你的代码向厂商的托管端点发送请求，你面前就有一项迁移工作，大约有四周时间来完成。如果你的代码加载的是你自己拥有的检查点，那么这项公告没有改变任何你需要采取行动的事情。

UI-Venus 2 9B 从来无法以那种方式调用。它是一个稠密 9B 模型的全参数权重，基于 Qwen3.5-9B 初始化，拆分在四个 BF16 safetensors 分片中，而预期的使用路径是你自行搭建的 vLLM 服务器，以 262,144 token 的最大模型长度启动，并使用 Qwen3 reasoning parser。模型卡对该方案的局限性表述得异常直白：该服务配置“并未作为本次模型卡更新的一部分经过线上金丝雀验证，因此在部署前请锁定并验证适用于 Qwen3.5 的 vLLM 版本。”

把这两段并排放在一起看，买家眼中的差别就成了一条明细账目，而不是一个基准测试。其中一个模型是按 token 计费的账单，你可以把它填进电子表格里，一直到 11 月中旬都成立。另一个则是一块 GPU——你得自己去找、自己定规格、还得让它一直保持着热机状态——而发布该权重的厂商从未替你验证过服务器配置。

参数数量相同，token 账单却截然不同

9B 这个标签是这两者共同点中最没用的。真正在经济性上区分它们的是每任务轮次。

Moondream 3.1 9B A2B 没有第二步。一次调用就是输入一张图像、输出一段简短的答案——通过 detect 得到边界框，通过 point 得到中心坐标，生成一段说明文字，或通过 query 得到一段文字回答。它有一个可选的推理模式，而厂商文档对其代价直言不讳：启用该模式会在给出答案前先生成一段显式的分析，并且可能“显著增加延迟和生成的 token 数”。其输出刻意保持精简，而这个模型的全部卖点就在于：它虽然小巧，却依然实用。

UI-Venus 2 9B 是一个闭环。每一步都会获取当前屏幕，携带该回合的截图历史，输出推理轨迹，然后输出动作，而下一张截图会作为输入返回。已发布的评估显示了这在轮数上的代价：模型卡报告了 MobileWorld 在 50 步预算和 100 步预算下的结果，以及 OSWorld 2.0 在 150 步预算下的结果。在这种设计中，上下文并不是文档的容量——而是智能体还能记住多少个屏幕状态。

算术随之而来，而且这是我们的算术，不是供应商的。如果一条 caption 或一个检测答案是 50 到 100 个输出 token，那么一百万个输出 token 就相当于一美元能买到一万到两万次 Moondream 调用。你无法为 UI-Venus 2 9B 写出对等的句子，因为没有一个价格可供相除——你付的是这个循环占用 GPU 的小时数，而不是它产出的 token；而每完成一个任务需要多少 token，取决于你允许它走多少步。参数量相同，9B 这个名头也相同，但两张账单根本不在同一个计量单位上。

还有一个值得在生产计划被它坑到之前就了解的不对称之处。Moondream 在单块 H100 SXM5 上、批大小为 16 时，自测其引擎达到每秒 34.2 次请求——这是厂商给出的数字，跑在厂商自己的硬件上，由 Photon 提供服务。而托管 API 对已充值账户的上限是每秒 10 次请求。这就是模型在你可控的硬件上能做到的事，与端点允许你做的事之间三倍的差距，而这类问题，流水线往往是在生产环境里才发现的，而不是在评估阶段。

并排，逐维度

• 任务 — M​oondream 3.1 9B A2B：单张图像上的感知。UI-Venus 2 9B：在循环中对屏幕进行自主操作。

• 参数 — 总计 9B，每个 token 激活 2B，采用稀疏混合专家架构。UI-Venus 2 9B：9B 稠密模型，从 Qwen3.5-9B 初始化。

• 输出——边界框、中心坐标、图像描述、文字答案和分割路径。UI-Venus 2 9B：一个动作、一个点击坐标，以及生成它们的推理轨迹。

• 上下文 — 32K token。UI-Venus 2 9B：262,144 个最大位置嵌入，配置为情节记忆，而非文档上下文。

• 公布价格 — 实时每百万 token 输入 $0.30、输出 $1.00，批量为 $0.15 和 $0.50，位于一个将于 2026 年 11 月 13 日关闭的端点上。UI-Venus 2 9B：无，因为不存在第一方端点。你要么自行托管它，要么就别用它。

• 已发布基准测试——COCO 81.46 F1@0.5、ODinW-13 93.94、RefCOCO-M 87.1、CountBench 90.35、ChartQA 86.01、DocVQA 88.6，以及 77.9 的套件平均值。UI-Venus 2 9B：AndroidWorld 80.2、WebVoyager 90.8、OSWorld-Verified 70.8、ScreenSpot-Pro 73.0、VenusBench-CAPTCHA 78.1，以及 OSHarm 攻击成功率为 11.3%，而其基础模型为 25.3%。上述每一项数字都来自厂商自身。

• 许可证 — M​oondream Model License 1.0：开放权重，允许商业自托管，允许再分发，有一项限制。UI-Venus 2 9B：待最终确认，仓库中没有许可证文件。

• 独立评分——无。两个模型在任何一个中立排行榜上都没有记录，而两家厂商也没有发布任何共同的基准测试，因此上述两栏中的任何内容都无法进行横向比较。

许可证正是两者不再彼此相似的地方。

M​oondream 的许可证简短而具体，供应商针对此版本重写了它，因为上一版难以阅读。商业使用、自托管、微调、量化以及再分发均被允许，且不附带任何附加条件。唯一的限制是，你不能反过来将通用的 M​oondream 推理或微调作为托管服务提供给他人；基于该模型构建的狭窄且特定领域的应用则明确没有问题。对于一个要交付一款恰好会“看”图像的产品团队来说，这是一份带有竞争对手条款的宽松许可证，而该条款并不会影响他们。

UI-Venus 2 9B 的立场并非同一类表述，值得直接引用而非转述。模型卡片的“发布状态”部分称，模型权重的许可协议“有待最终确认，并将在公开发布前补充”，同时解释了为何没有采纳那个显而易见的选择：“Apache-2.0 声明之所以有意未予沿用，是因为当前上游材料中载有相互冲突的许可声明。”仓库中没有许可协议文件。权重于 2026 年 8 月 26 日发布，仓库最后一次改动是在 9 月 2 日。

实际解读并不是该模型不可用，而是：未解决的许可证问题是必须有人正式记录在案的商业决策，而不是你通过下载检查点就默认继承的东西。风险并不在于研究、评估和内部原型开发。把它摆到付费客户面前才是风险所在，而上文部分中的任何基准分数都无法改变这一点。这张模型卡还带有第二个条件，任何人在围绕它进行构建之前都值得一读：CAPTCHA 破解能力“应仅在经授权的环境中使用”——这是对用例的约束，而不是关于它的建议。

两家供应商都让你核对号码，只是方向各不相同。

大多数模型发布都只公布一张表格，然后就此打住。而这两个模型都公布了各自的注意事项，而这些注意事项分属不同的类别。

Moondream 的发布博文附有一份方法论脚注，锁定了硬件和评测框架：单张 H100 SXM5、批次大小为 16、每个模型都采用最高的准确率和推理设置，Moondream 本身使用 Photon，Qwen3.5 和 Gemma 4 基线使用 vLLM，SAM 3 使用 Hugging Face Transformers，而 LocateAnything 则在慢速模式下评估，以最大化其准确率。它还主动披露了一件厂商本无义务披露的事：这些分数是这样取得的——把每个基准都当作客户任务，通过客户所用的同一款微调产品为每个任务训练一个 LoRA，然后用同策略蒸馏将这些 LoRA 折回基础权重。仔细读这一点，它会改变那张表所描述的含义——你下载的检查点，是其自身任务专家模型蒸馏出来的学生模型，而不是一个碰巧在没人针对其训练过的任务上泛化得如此好的模型。

UI-Venus 2 技术报告，arXiv 2609.00028，于 2026 年 8 月 27 日提交，做的是另一种披露。用星号标记的基线是由作者按照他们自己声明的协议进行评估或复现的，而不是从别处引用。短横线表示未报告，而作者把短横线保留在文中。MobileWorld 列出了两次，分别在 50 步预算和 100 步预算下，这样你就能看到额外步骤换来了什么。OSWorld-Verified 附有一则警告：比较“可能会使用模型特定的动作脚手架，因此应将其解释为基准层面的参考，而不是受控消融。”VenusBench-CAPTCHA 是对 219 个固定样本的微平均；MCA-Bench 的数值则使用了 1,000 个抽样样本。其中有一句话指出，实时环境结果可能会随评估日期和环境状态而变化。

这一切都不能让两组数字中的任何一组在你的数据上可复现，而且两家供应商都没有可援引的独立结果。但它确实意味着，他们两家都告诉了你他们的数字价值几何——这比一个漂亮的分数更罕见，对买家也更有用。

哪一个，按约束条件

• 你需要能在图像上给出边界框、中心点或计数，而且价格可预测——M​oondream 3.1 9B A2B，但有个前提：只有在 11 月 13 日之后自托管，或迁移端点，这一预测才成立。一份带有关停日期的按 token 计费账单，是一份会过期的预测，而不是成本模型。

• 你需要一个能读取屏幕并据此操作的东西——UI-Venus 2 9B，而许可证问题要优先于基准测试表。先把它用于内部自动化，等许可证落地后再重新考虑，而不是在采购过程中才发现问题。

• 你将模型部署到你已经拥有的硬件上——M​oondream 3.1 9B A2B。Photon 是免费的，可运行在 Ampere 或更新一代的 N​VIDIA 芯片以及 Apple Silicon 上，并让你在开发和生产环境中使用同一个模型，而不是两个在负载下表现各异的不同端点。

• 你希望规格表上给出更长的上下文——UI-Venus 2 9B 的 262,144 个 token 在配置中是实打实的，但它预期处理的是截图历史，而不是 PDF。Moondream 的 32K 只有它的四分之一，而且其供应商从未声称它需要容纳智能体的一次完整执行过程，所以这两个数字都不能算作直接胜出。

• CAPTCHA 处理已经在你的清单上了——先看看卡片上的限制说明。能力就在那儿,挡在它前面的,正是许可。

如果诚实的答案是两者都需要，只是承担不同的任务——摄取路径上的感知，以及行动路径上的智能体——那这就是常见的形态，而且它首先是双契约问题，其次才是模型问题。

模型背后的模型，以及由谁来路由它

这两个检查点都不经由 OrcaRouter 提供服务，所以这里并不是在推销通过我们来调用它们。真正需要路由的，是位于它们背后的那一层。

检测结果需要分诊，智能体提出的操作需要得到评判，记录也需要被写入。这些都是文本类工作，按 token 计费属于更昂贵的那一半，而正是在这里，一个兼容 OpenAI 的单一密钥即可覆盖 200 多个模型——按供应商标价 0% 加价透传，并跨供应商自动故障转移——从流水线中省去一份合同和一条代码路径。当你已经清楚自己想要的推理形态时，路由 DSL 可以把多个模型组合成一次调用，模型融合则让一组模型在同一输入上并行运行。这两种方式都能在不改动与摄像头通信的那部分代码的前提下，替换固定视觉模型背后的那一层。

在这种特定比较中，定价机制比平时更重要。因为 标价是直接传导的，而不是被加价，供应商的价格变动当天就会在我们这边生效。对于托管价格中写明了关停日期的模型来说，这是唯一值得据此构建预测的定价安排。

什么会改变这个答案

三件事，而且这三件事都是可核查的。

第一件事是 UI-Venus 2 9B 的许可证问题得到解决。如果最终落到宽松许可，那么对于任何想要这个 agent、却无法为法律风险敞口给出正当理由的人来说，权衡会立刻改变，而上文关于将其保留在内部使用的建议会在事情发生的那一周就变得过时。第二件事是 Moondream 3.1 9B A2B 的第一方端点在云服务关停后重新出现，这将恢复本文只能做一半的价格比较。第三件事，也是最有价值的一件，是有人让这两个模型跑在同一批图像上。两家厂商都没有独立结果，而且这两个基准测试集并不相交，因此第一个用自己的数据给这两个模型评分的人，将产生唯一能解决 grounding 问题的比较——而这只是一下午的工作量，不是一个研究项目。

在此之前，能站得住脚的总结是刻意收窄的。这是两个 9B 视觉模型，它们有着相同的参数量、相同的模态标签，以及返回坐标的习惯，但在几乎所有决定部署的事项上都毫无共识：一次调用要花多少钱、一次调用是否才是合适的单位，以及你是否被允许交付输出。

这一切都并非假设：像本次这样的发布背后那些有据可查的 AI 故障与智能体事件，均收录于 OrcaRouter AI 事件档案库中，其中每条记录都附有自己的来源、严重程度、置信度评级和存疑标记。