LFM2.5-VL-3B-DSpark 对比 UI-Venus 2.9B：速度倍增器对决 GUI 智能体

LFM2.5-VL-3B-DSpark 和 UI-Venus 2.9B 被归在同一个模糊的类别下——小型视觉模型——然后被拿来相互比较，这是一种范畴错误，值得在它让某人付出整整一周集成时间之前加以纠正。LFM2.5-VL-3B-DSpark 是一个 279.5M 参数的草稿模型，用于加速 Liquid AI 的 LFM2.5-VL-3B。UI-Venus 2.9B 来自蚂蚁集团的 inclusionAI 实验室，是一个 9B 的 GUI 智能体，它能读取屏幕截图、决定动作，并在移动端、Web 和桌面环境中执行该动作。一个让现有模型变得更快。另一个才是真正在做事的那个。如果你需要的是一个 GUI 智能体，那么草稿模型并不是更便宜的选择——它根本就算不上一个选择。

有用的比较不在于哪个更好，而在于各自解决了什么问题，以及在此过程中各自会让你付出什么代价。两者也都是新近出现的事物，更广泛的生态系统尚未跟上；而且，它们的代码仓库所宣称的内容与其他人所验证的结果之间的差距，其中一个比另一个更大。

每一个分别是什么，确切地说

从形状开始，因为它们解释了其余的大部分。

• 它是什么——LFM2.5-VL-3B-DSpark 是一个投机解码草稿模型；UI-Venus 2.9B 是一个通用 GUI 智能体策略

• 参数量 — 草稿模型为 279.5M BF16，相比之下，从 Qwen3.5-9B 初始化的 U-Venus 2.9B 为 9B

• 独立能力——草稿模型单独运行时无法生成任何可用内容，也无法孤立地进行基准测试；UI-Venus 2.9B 作为完整智能体运行

• 输入 — 草稿模型从不直接看到图像本身，只能看到目标模型的隐藏状态；UI-Venus 2.9B 则直接处理截图，并且完全围绕截图构建

• 输出——草稿模型提出待验证的 token；UI-Venus 2.9B 针对实时界面输出带有边界框的有依据动作

• 基础 — 草稿模型在其自身元数据中绑定至 LiquidAI/LFM2.5-VL-3B；UI-Venus 2.9B 基于 Qwen3.5-9B

• 上下文——草稿模型会继承目标模型所提供的任何内容；在供应商自有的 vLLM 配方中，UI-Venus 2.9B 以 262,144 个 token 为上限提供服务

• 许可 — 两者均以不同方式悬而未决；Liquid 以 LFM1.0 许可证发布，而 UI-Venus 2.9B 的卡片直接声明其权重许可尚待最终确认

最后那条要点才是需要放慢节奏仔细看的地方。我们自己在8月下旬对 UI-Venus-2-9B 的报道将此次发布描述为 Apache-2.0，因为当时项目材料上就是这么写的。而如今的模型卡给出了不同且更为明确的说法：模型权重许可证尚待最终确认，并将在公开发布前补充；并且，之所以有意没有沿用 Apache-2.0 声明，是因为当前上游材料中包含相互冲突的许可证声明。如果你正计划对 UI-Venus 2.9B 进行商业部署，那么许可证问题按供应商自己的承认仍未确定，这是实质性风险，而不是一个脚注。

双方实际公布的数字

这两个仓库衡量的是不同的东西，而这正是关键所在。Liquid 公布的是吞吐量；蚂蚁集团公布的是任务成功率。

对于草稿模型，根据 Liquid 自家测试框架：在单张 H100 80GB 上以 BF16 精度通过 SGLang 运行时，解码最高加速 2.66×；在 Apple M5 Max 上使用 MLX-VLM 时最高加速 3.13×；在 M3 Ultra 上使用 llama.cpp 时最高加速 2.14×。端到端来看，同样的这些运行结果介于 1.30× 到 2.62× 之间，具体取决于技术栈和任务。草稿接受量约为每轮验证 3.2 到 4.5 个 token。以上每一项均由厂商自行测量，没有外部复现。

对于 UI-Venus 2.9B，其模型卡自身的表格报告了以下结果：AndroidWorld 上为 80.2，MobileWorld 上在 50 步预算下为 65.8，OSWorld-Verified 上为 70.8，DeskCraft 上为 48.0，在刷新后的 595 项任务划分上 WebVoyager 上为 90.8，Online-Mind2Web 上为 74.0，ScreenSpot-Pro 上为 73.0，VenusBench-GD 上为 77.1。在 CAPTCHA 上，它报告 VenusBench-CAPTCHA 上为 78.1，MCA-Bench 上为 75.7。在安全方面，它报告在 OSHarm 上的攻击成功率为 11.3%，而其基座 Qwen3.5-9B 为 25.3%。所有这些结果均为厂商报告，部分基线带有星号，表示 UI-Venus 的作者按所述协议对其进行了评估，而且模型卡本身也警告称，OSWorld-Verified 的对比使用了针对具体模型的行动脚手架，应被理解为基准层面的参考，而非受控消融实验。

注意两份清单中都缺少了什么：任何由第三方测量的东西。对草稿模型而言，原因在于该检查点已是数天前的版本。对 UI-Venus 2.9B 而言，原因则在于 GUI-agent 基准测试复现成本高昂，而且实时环境中的结果会随评估当日环境的状态而变化——这张模型卡主动交代了这一注意事项。

两者真正交汇之处

确实存在真实的重叠，而且它比这个类别标签所暗示的更窄。如果你正在构建端侧或边缘视觉智能体，那么两者都相关，而且两者都关注让像素通过模型所需的成本。它们从相反的两端来攻克这个问题。

UI-Venus 2.9B 通过训练来攻克它：一条三阶段流水线——在模拟的移动端、Web 和 OS 环境中进行多模态中期训练，按领域进行离线 RL，然后通过多教师在线策略蒸馏汇入单一策略。所发布的能力便是这一结果。该模型为 9B，对 GUI 智能体而言偏小，对边缘设备而言偏大，而该卡片预期的服务配置是 vLLM 部署——同一份文档指出，该配置并未作为卡片更新的一部分进行实时金丝雀验证，并提示你在部署前锁定并核实用于 Qwen3.5 的 vLLM 版本。

LFM2.5-VL-3B-DSpark 用运行时来攻克它：它不改动目标模型的权重，而是通过草拟并验证 token 来换取速度。在手机级设备上，这笔权衡完全偏向草拟方，因为输出可证明来自目标模型，而额外内存不到一个模型的十分之一。

对任何选择者而言，其后果是：智能体循环会让每个任务产生多次模型调用，而每次调用都要为新截图支付预填充成本。视觉编码和预填充恰恰是投机解码无法加速的阶段——Liquid 自己的发布公告就提出了这一论点，反对对其头条数字作无限解读。因此，草稿模型的优势在 UI-Venus 2.9B 所身处的那种工作负载中恰恰会缩水。反过来，UI-Venus 2.9B 的优势——真正完成任务——并不是草稿模型无论多快就能提供的东西。

运行这两个

在 OrcaRouter 上，两者都不是托管端点。LFM2.5-VL-3B-DSpark 和 UI-Venus 2.9B 都要求你自行拉取权重并自行部署服务，而它们的部署方案也因各自截然不同的角色而各有特点。草稿模型需要 SGLang v0.5.19 或更高版本，并启用 DSPARK 投机算法标志和 9 的块大小；或者需要 MLX-VLM v0.7.2 或更高版本，将草稿模型作为 draft model 传入并将 temperature 强制设为 0；或者使用 llama.cpp，配一个 567 MB 的 F16 GGUF 与一个量化后的目标模型搭配。UI-Venus 2.9B 则需要一个足够大的 vLLM 服务器来承载 9B 模型、最大长度 262,144 token，还需要来自该项目代码仓库的参考提示词和动作解析器——模型卡明确指出，仅启动服务器并不能让你得到一个可用的闭环 GUI 智能体。

两者也都会在各自能力边界处留下同样的缺口。小型视觉语言模型搭配草拟器，仍然会遇到无法处理的屏幕和任务；而 GUI 智能体也仍然会在其训练分布之外的环境中失败。那些漏网的查询总得落到某处，而在大多数生产设计中，这个去处就是规模更大的通用模型。将这些查询路由经由一个单一端点，按各提供商标价覆盖 200 多个模型，并在某提供商性能下降时自动故障转移，就能让回退路径不必进入关键集成清单，而不是把它变成又一个自带密钥和合同的独立部署项目。

如何在一分钟内做出决定

如果你需要一款能操作用户界面的软件——点击、输入、在它从未见过的应用中导航——那么你买的其实是一个策略，而那就是 UI-Venus 2.9B。按 9B 的 vLLM 部署来做预算，在投入商用前先了解悬而未决的许可问题，并把厂商的基准测试表当作一个有力的起始假设，而不是既定结果，尤其是模型卡本身标注为依赖 scaffold 的 OSWorld-Verified 对比。

如果你已经在运行 LFM2.5-VL-3B，并希望它在你自己拥有的硬件上更快，那么你购买的就是一种运行时优化，那就是 LFM2.5-VL-3B-DSpark。先检查三件事：你的工作负载是解码密集型而非预填充密集型，你是在以 16 位而非 4 位导出进行服务，以及你的运行时满足最低版本要求。如果这三项都成立，内存开销为 8.9%，并且输出在构造上保持不变。

一旦接触其中任何一个代码库，唯一站不住脚的做法，就是把它们当作彼此的替代品。它们一个是速度倍增器，一个是智能体；而它们唯一会相互竞争的场合，就是你已经决定了要构建什么，却在寻找一个转而构建更便宜东西的理由。

OrcaRouter 通过一个密钥即可访问 200+ 个模型，按供应商标价计费、0% 加价，并为那些不应由边缘模型或智能体承接的查询提供路由策略与自动故障转移。为回退路径提供统一 API本页介绍的两个模型都不托管在那里——两者均由你自己的权重提供服务——但回退路径正是你不必自己构建的那部分。