MiniCPM-V 4.7 1B 对比 UI-Venus 2 9B：一个能装进口袋，另一个则需要机架

MiniCPM-V 4.7 1B 与 UI-Venus 2 9B 之间的对比差距悬殊，而这正是它的有用之处。MiniCPM-V 4.7 1B 是 OpenBMB 推出的 15.5 亿参数通用视觉语言模型，上传于 2026 年 10 月 6 日，厂商发布说明中标注的日期为 10 月 12 日，采用 Apache 2.0 许可，小到足以在手机应用内运行。UI-Venus 2 9B 是 inclusionAI 推出的 94.1 亿参数 GUI 智能体，于 2026 年 8 月 26 日发布，专门训练用于查看屏幕并决定在哪里点击、输入或滑动，并且它需要一台配有前置 vLLM 服务器的 GPU。此类发布背后的已记录 AI 故障与智能体事件，均收录于OrcaRouter AI Incident Archive，其中每条记录都带有自己的来源、严重程度、置信等级和争议标记。

把它们放在同一句话里，会引出错误的问题——哪个更好——而正确的问题是它们各自用途为何。一个能装入 1.8 GB 量化内存的通用视觉模型，和一个在 ScreenSpot-Pro 上得分 73.0 的屏幕智能体，并不是彼此的替代品。它们是移动自动化技术栈中两个不同的层，而有趣之处在于这两层之间的边界究竟落在哪里。

两份从远处看很相似的工作

两个模型都能接收屏幕截图并返回相关文本。相似之处也仅限于此。

MiniCPM-V 4.7 1B 可读取图像并进行描述、转录、提取或回答。你可以问它收据总额是多少、表单字段包含什么、图表是否呈上升趋势，或 PDF 的某一页写了什么，它都会给出答案。它具备针对高分辨率图像的切片控制、可切换的 4×/16× 视觉 token 压缩比，以及视频的帧采样参数。其文档涵盖单图对话、多图对话、视频、OCR、PDF 解析和视觉定位——一种文档与屏幕阅读的工作负载。

UI-Venus 2 9B 读取屏幕并输出动作。它的卡片描述了一个闭环：观察界面、推理任务状态、执行动作，并将环境的反馈纳入下一次决策。输出是点和动作序列，而非散文。围绕它，inclusionAI 提供了参考提示词、动作解析器以及可运行示例，覆盖移动端、计算机、浏览器、grounding 和 CAPTCHA 任务。模型是一种策略，而围绕它的框架构成了产品的一半。

这一区别在参考任何基准测试之前就决定了架构。需要读取收据的手机应用采用第一种。需要在应用内完成任务的系统——点击完成结账、填写表单、解决滑块验证码——采用第二种，而且无论其 OCR 多好，都不能用第一种替代。

许可证是第一道筛选，而不是基准。

UI-Venus 2 9B 的模型卡片中有一个发布状态部分，大多数报道都略过了它。在“模型权重”一项下，它写明权重已包含在内；在“许可证”一项下，它写明模型权重许可证尚待最终确认，并将在公开发布前补充；同时还说明，之所以有意未沿用 Apache-2.0 声明，是因为上游材料中存在相互冲突的许可证声明。

把这段话读两遍。权重可下载，基准测试已公布，技术报告在 arXiv 上，许可证却仍未解决。对研究团队来说这没问题。对一家计划在商业产品中发布屏幕智能体的公司来说，这意味着法务审查无法收尾。该模型最终可能会采用 Apache 2.0，也可能不会，而仅凭今天可获得的材料无从得知。

MiniCPM-V 4.7 1B 以 Apache 2.0 许可发布，不存在这种歧义。仅凭这一句话，就在一大类商业工作中直接排除了两个模型中的一个；原因并非它更差，而是悬而未决的许可证是一种没人会为其做预算的进度风险。

硬件算术，在产生任何评分之前

• 权重 — 1.55B 稠密模型，BF16 下约 3.1 GB，Q4_K_M 下 0.67 GB，外加 0.90–1.11 GB 视觉投影器；对比 9.41B，BF16 下约 18.8 GB，分布于四个 safetensors 分片 • 运行位置 — iOS、Android 和 HarmonyOS 应用；Rockchip、Houmo、Intel、AMD 和 Arm 的 day-0 芯片支持；对比 GPU 服务路径，已用 vLLM 以 --max-model-len 262144 和 --reasoning-parser q​wen3 记录 • 上下文 — 纸面上 262,144 个 token，全长度下 KV 缓存开销超过权重；对比 262,144 个 token，继承自 Qwen3.5-9B 基础模型 • 视觉栈 — 980 像素图块上的 27 层、1152 隐藏维度编码器，具备编码器内 token 压缩；对比 Qwen3.5-9B 视觉塔，沿用自基础模型 • 许可证 — Apache 2.0；对比待确认，且明确未提供 Apache-2.0 声明 • 评估风格 — 五个文字描述的数值加仅图表对比；对比覆盖移动端、计算机、网页、grounding、CAPTCHA 和安全的完整数值附录 • 独立评估 — 截至本文撰写时两个模型均无；对比无，尽管 arXiv 2609.00028 的技术报告是可供第三方核查的实质性产物

这里的差距在内存上大约是一个数量级：量化后为 1.8 GB，而 BF16 下为 18.8 GB；如果做 4-bit 量化，则约为 5 GB。这也就是应用与服务之间的差别。这也是为什么这两个模型通常会在不同文章中讨论——一个是边缘部署问题，另一个是推理成本问题。

9B 如何凭实力证明自己配得上这个体量

UI-Venus 2 9B 的各项数据均来自其产品卡和技术报告中的厂商报告，使其位居 10B 以下 GUI 类别的前列。在衡量高分辨率专业软件上元素定位能力的 ScreenSpot-Pro 上，其报告值为 73.0。在 VenusBench-GD 上为 77.1。在 OSWorld-G-R 上为 78.5。在 AndroidWorld 上为 80.2。在 WebVoyager 更新后的 595 项任务划分上为 90.8。在 OSWorld-Verified 上为 70.8。在其自家的 VenusBench-CAPTCHA 上，在八种交互类型中达到 78.1 pass@1。

这些数字不是一个 1B 通用模型会产出的，也并非意在如此。让它们可信而非装饰的，是训练描述：一个包含 170 多个多语言应用的移动端池，一个覆盖 19 个类别的 4,000 多个域名的网页端池，三个训练阶段（多模态中期训练、跨五个任务族的离线 RL、多教师同策略蒸馏），以及一套基于任务相关视觉关键点、采用多模型投票而非单个评判模型查看最终屏幕的验证方案。该模型卡还报告了安全结果——在 OSHarm 上的攻击成功率为 11.3%，在 OSBlind 上为 48.8%，而 Qwen3.5-9B 基座为 25.3% 和 79.4%——并将其定位为与该基座的比较，而非绝对的鲁棒性声明，这是正确的定位方式。

这些都无法迁移到 1B 模型上。GUI 智能体的能动性是训练出来的，而非从通用视觉能力中自发涌现；再高的 OCR 准确率也替代不了一个知道“下一页”按钮有何作用的策略。

1B 仍然能胜出的地方

三个名次，而且它们可不是安慰奖。

延迟与可用性。本地 1B 模型没有网络往返、没有排队、没有服务商故障，也没有按请求计费。对于一个每天使用五十次的扫描功能而言，这就是整个产品体验。部署在 vLLM 服务器后面的 9B 模型确实很快——但它的快与任何托管模型的快并无二致，而一旦连接中断，它就不再快了。

隐私源于架构设计。收据、身份证件、医疗表单或私人对话截图都可以留在设备上。这不是营销话术；它决定了一项功能是能在受监管行业中交付，还是不能。UI-Venus 2 9B 自身的安全评估针对的是模型在服务器端行为不当的问题。而 1B 的隐私特性在于图像始终不会离开手机。

边际成本。用托管的 9B 模型读一张截图，每次请求都要花钱，每一次请求，永远如此。用本地 1B 模型读，代价是电量。低用量时托管方案更便宜；高用量时——现场应用里的扫描器、无障碍工具、一万张收据的批处理——本地模型是唯一边际成本趋近于零的选择。

大多数团队最终实际会构建的技术栈

不是在两者之间做选择。而是它们的叠加。

端侧 1B 模型负责感知：读取屏幕、提取文本、找到字段，并描述其中的内容。大多数情况下这就足够了，请求始终不会离开手机。当任务需要执行操作——点这里、滑那里、完成整个流程——时，这项工作就交给智能体，而智能体需要一个具备动作词汇的更大模型。

这种交接正是路由层体现价值的地方，值得精确说明它做什么、不做什么。OrcaRouter 提供200 多个托管模型，通过一个兼容 OpenAI 的端点、以 0% 加价原样传递各提供商的标价，并具备自动故障转移和一种路由 DSL，后者可以在一次调用中同时保留主选和后备。这种模式带来的做法并不光鲜，却很有用：手机先尝试本地的 1B 模型，应用把困难情况升级到托管视觉模型，使用的仍是它处理其他一切事务的同一个密钥；而某家提供商下午状态不佳时，就变成一次故障转移事件，而不是一次服务中断。MiniCPM-V 4.7 1B 和 UI-Venus 2 9B 都不在该目录中——两者都是你自己运行的检查点——所以路由器是技术栈外围的那一层，而不是调用其中任一模型的方式。

值得预先规划的两种故障模式

第一个是 1B 通用模型，被用作智能体。它能正确读取屏幕，却完全不知道该怎么处理。如果你的产品需要完成一个流程，而不是描述一个流程，那 1B 就是错误的工具，任何提示词都补救不了。

第二个是一个 9B agent，其发布取决于模型卡上的许可状态。UI-Venus 2 9B 的模型卡显示许可仍在待定，并且有意暂不声明 Apache-2.0。在该问题解决之前，无论 ScreenSpot-Pro 的数字多好，该模型在商业用途上都只是一个研究产物。那些按“它很可能会是 Apache 2.0”来做规划的团队，正在承担一项他们尚未计入成本的进度风险。

这个选择实际上归结为什么

如果问题在于“我能不能在手机上、离线、免费地读取这张截图，并且使用一个我可以随产品发布的许可证”——MiniCPM-V 4.7 1B 的答案是肯定的：量化后约 1.8 GB，采用 Apache 2.0 许可，你唯一需要核实的就是你自己设备的内存余量。

如果问题是“这个模型能否操作界面，而不只是描述界面”——UI-Venus 2 9B 正是那个具备训练、基准测试和测试框架的模型，而且在它需要其他任何东西之前，它首先需要一块 GPU 和一项许可决定。

如果答案是“两者都要，放在同一个产品里”——那么你就是在构建一个双层系统：1B 模型在设备端负责感知，智能体在服务器端负责执行，而工程工作的重点在于两者之间的交接，而不是在两者之间做取舍。

这种比较看起来不对等，因为它本来就不对等。一个 1B 的通用模型和一个 9B 的 GUI 专用模型，不在同一个量级，不属于同一个部署类别，也不处于同一个许可定位。错误在于把它理解成“其中一个更好”。它们回答的是不同的问题，而最快的选择方式，就是写下你实际在问的是哪个问题。