LFM3-VL-2B 与 UI-Venus 2.9B：一个实为 9B 的 2.9B

并不存在名为 UI-Venus 2.9B 的模型。位于 inclusionAI/UI-Venus-2-9B 的检查点是 UI-Venus-2-9B —— Ant Group 的 UI-Venus 智能体第二版，拥有 90 亿参数，基于 Qwen3.5-9B 构建。该目录名读起来像小数，但它并不是。与 LFM3-VL-2B（19.2 亿参数）相比，这使其成为一场贴着 2B 对 2B 标签的 2B 对 9B 比较。

这个错误很重要，因为它改变了问题。如果两个模型都大致是 2B，你会比较基准测试行，并选出更好的那个。在 9B 对 2B 的情况下，较小的模型并不是在相同硬件上竞争，而较大的那个根本不是通用视觉模型。UI-Venus-2-9B 是一个 GUI 智能体，经过训练，可以从屏幕截图操作手机、浏览器和桌面。LFM3-VL-2B 是一个通用视觉语言模型，恰好在其 62 项基准测试中包含一个 GUI 类别。这种重叠比名称所暗示的要窄。

这个名字是怎么被弄乱的

蚂蚁集团的命名惯例是系列-版本-规模。UI-Venus-2-9B 解析为 UI-Venus、第 2 代、90 亿参数。如果目录或雷达按连字符拆分并查找小数点，就会把“2-9”读成“2.9”，于是 9B 模型就被归到了 2B 模型旁边。同一惯例还产生了更大的同系列模型 UI-Venus-2-27B，二者于 2026 年 8 月下旬一同发布。

这不是无关紧要的表面错误。参数量是每个部署决策中的第一道筛选条件，而预期看到 2.9B 模型的读者，会被一个 18.8 GB 的 BF16 checkpoint 打个措手不及——它根本装不进他们设想的设备。该仓库自身的元数据明确无误：Qwen3.5-9B 架构、BF16、图像-文本到文本。

两种用途，而非两种尺寸

LFM3-VL-2B 以 2 fps 接收文本、图像和视频，输出文本，支持思考模式，并在 16 种语言中承载 128K 上下文。它是一个通用模型：文档、图表、定位、具身推理、GUI 理解和视频都作为类别出现在其模型卡片上。Liquid AI 于 2026 年 10 月 19 日在 Hugging Face 上发布了它，并于 10 月 27 日公布了该系列，未列出 API 价格，也未列出推理提供商。

UI-Venus-2-9B 接收截图和任务描述，并在闭环的观察—推理—行动循环中返回下一步动作。它的训练分为三个阶段：先是在覆盖 170 多个移动应用和 4,000 多个网页域的模拟轨迹上进行多模态中期训练；再是在界面定位、CAPTCHA、移动端、网页和计算机任务上进行离线步骤级强化学习；最后通过多教师同策略蒸馏整合为单一策略。它运行在 vLLM 上，配有 OpenAI 兼容端点和 Qwen3 推理解析器。这是一个智能体运行时，而不是描述生成模型。

实际后果是：你无法将它们互换使用。LFM3-VL-2B 会描述屏幕截图并回答关于它的问题。UI-Venus-2-9B 则会决定下一步点击哪里，而且它需要依赖该项目 GitHub 仓库中的配套框架——动作解析器、提示词、示例——才能发挥任何作用。

唯一对得上的基准

两个模型都报告了 ScreenSpot-Pro 的结果，这是比较具有合理性的罕见情况。LFM3-VL-2B 在启用思考时得分为 55.5，不启用时得分为 49.3。UI-Venus-2-9B 得分为 73.0。这意味着几乎大五倍的模型领先 17.5 分，而这是本次对比中最清晰的一个数字。

不要将其扩展到 GUI 领域的其余部分。UI-Venus-2-9B 还报告了 AndroidWorld 80.2、OSWorld-Verified 70.8、WebVoyager 90.8、Online-Mind2Web 74.0 和 VenusBench-GD 77.1。LFM3-VL-2B 报告称，在一组不同的任务上，其 GUI 类别平均分为 83.1，而对一个类别取平均并不等同于在单个基准上得分。这些类别不可比较，也不应相减。

UI-Venus 卡片上的一个数字值得指出，因为它与主标题结论相悖：在 OSWorld 2.0 上，该模型在二元指标上得分为 0.0，在部分指标上得分为 7.5。无论测试框架的问题是什么，一个在 OSWorld-Verified 上领先、却在后继基准上得分接近零的 9B 智能体，就是一个存在边界的模型，而这张卡片诚实地报告了这一点。

衡量不同事物的上下文窗口

UI-Venus-2-9B 报告最高支持 256K token 的上下文，而真正有用的是这段上下文所承载的内容：截图历史，因此智能体能够记住四步之前屏幕的样子。LFM3-VL-2B 报告支持 128K，但其卡片未说明图像 token 预算或最大视频长度。这两个数字都不能告诉你，在模型丢失第一张截图之前，一个循环中能保留多少张截图。两者都需要在你自己的分辨率和步数下进行测量。

性质上的差异仍然重要。冗长的截图历史，是对运行数分钟的智能体的记忆需求。通用 VLM 上的 128K 上下文，则是文档或视频需求。这些数字看似相当，却在回答不同的问题。

部署：4 GB 对比 19 GB

LFM3-VL-2B 拥有 1.92B 参数，按算术计算，BF16 权重约为 3.84 GB，并且已经发布了 GGUF、MLX 4-bit 和 ONNX 构建版本。UI-Venus-2-9B 在 BF16 下约为 18.8 GB，通过 vLLM 提供服务；虽然存在社区版 GGUF，但厂商的服务路径假定 GPU 有足够空间容纳完整检查点。这两者并不争夺同一个位置。一个是边缘侧候选，另一个是服务器端智能体。

让这一组合有意义的，正是这种差异，而不是基准测试分数上的差距。想要在设备上实现 GUI 理解的团队，在这里只有一个选择。而想要一个分数接近当前最优水平的 GUI 智能体的团队，则要选另一个，并且需要 GPU 才能运行它。

无人回答的许可证问题

LFM3-VL-2B 采用 LFM Open License v1.0：只有在被许可方的年收入低于 1000 万美元时，才授予商业使用许可。这虽然具有限制性，但含义明确，而且许可证文本已公开发布。

UI-Venus-2-9B 的情况则没那么明确。该项目的代码仓库标注为 Apache 2.0；模型卡则声明，由于上游表述存在矛盾，权重许可仍在等待最终确认。截至 2026 年 10 月 28 日，此事仍未解决。尚未确定的许可对研究而言不构成障碍，但对于需要在上线前明确条款的商业部署来说，却是实实在在的阻碍。任何计划基于 UI-Venus-2-9B 进行开发的人，都应取得书面答复，而不是从仓库标签上自行推断。

OrcaRouter 究竟适合放在什么位置——如果真有合适位置的话

OrcaRouter 两个检查点都不提供，本文也不声称我们提供。我们拥有的是一个路由 DSL，它可以把多个模型组合成一次调用——这在这里很有用，因为自然的架构并不是“选一个”。一个小的通用 VLM 可以读取屏幕，并判断任务是文档问题还是交互；一个更大的 GUI 专家模型可以执行交互步骤。按任务类型在它们之间路由是一种配置，而不是第二套集成。

与其假装这两个模型是可互相替代的方案，不如说这样使用比较更为诚实。它们是同一流程中的两个阶段，彼此之间存在 5× 的参数差异。

你到底想要哪一个？

• LFM3-VL-2B如果任务是理解而非执行，如果需要视频或文档输入，或者模型必须在约 4 GB 内运行。接受有营收上限的许可证，并接受除 Liquid 外无人评估过它这一事实。

• UI-Venus-2-9B如果任务是从头到尾操作一个界面，如果你能提供 19 GB 的 GPU 内存和 vLLM 服务栈，并且你能等待权重许可证得到确认。请接受：它是一个配有专用测试框架的专家模型，而不是通用助手。

• 两者都不是，如果你想要的是一个 2.9B 模型的话。那个模型并不存在，而两个真实选项都比名称所暗示的更专门化。

更正才是关键。文件夹名中的参数数量并不能作为规格说明，而在本例中，它还掩盖了五倍的规模差异和一个完全不同的任务。先看架构字段，再看 slug。