LFM2.5-VL-3B-DSpark vs LFM2.5-VL-3B：不是二选一，而是挂载一个

把人们带到这里的那次搜索是一次对比，但诚实的答案是，LFM2.5-VL-3B-DSpark 和 LFM2.5-VL-3B 并不是你要在两者之间二选一的东西。后者是一个 3.1B 的视觉语言模型，你可以下载并部署服务。前者是一个 279.5M 参数的草稿模型，它存在的唯一目的就是坐在后者前面，让它解码得更快。把草稿模型从整个栈里拿掉，它就什么也产出不了；你没法单独对它做基准测试，因为“单独”并不是它支持的一种配置。真正该做的对比，是 LFM2.5-VL-3B 单独运行，对比同一个模型挂上草稿模型后运行。

这样看，决定就归结为一个问题：额外的内存和额外的运行时复杂度，能否为你换来足够的延迟收益，从而对你的工作负载真正重要？Liquid AI 自己的数据表明，对于解码密集型工作，答案是肯定的；而当预填充占主导时，则明确表示否定。而这正反两方面的结论，都尚未在公司外部得到复现。

两个复选框并排显示

它们之间的差异才是关键所在，所以在开始争论速度之前，值得把这两个仓库摆在一起比较。

• 角色 — LFM2.5-VL-3B 生成文本并回答关于图像的问题；LFM2.5-VL-3B-DSpark 为其提出待验证的 token，自身无法生成任何可用内容

• 参数 — 目标模型为 3.1B，草稿模型为 279.5M BF16，Liquid 认为这使部署的参数量增加了 8.9%

• 架构 — 目标模型是一个混合模型，基于 LFM2.5-2.6B 主干网络，并配备 SigLIP2 NaFlex 视觉编码器；草稿模型为 4 层全注意力层，隐藏维度为 2,048，采用分组查询注意力，外加一个马尔可夫头和一个置信度头

• 上下文窗口 — 目标模型为 32,768 个 token；起草器自身不携带上下文，而是继承目标模型的上下文

• 视觉编码器 —— 目标模型上使用 SigLIP2 NaFlex 400M；草稿模型没有该组件，也从不直接接触图像

• 词表——128,000，且草稿模型的嵌入与 LM 头与目标模型绑定，而非复制，因此内存开销比 279.5M 参数所暗示的要小

• 许可证 — 两者均依据 Liquid 的 LFM1.0 许可证发布，该许可证在 Hugging Face 上属于“其他”，而非 OSI 许可证，因此在进行商业部署前请阅读条款

• 格式 — 目标模型以 safetensors、GGUF、ONNX 和 MLX 量化格式发布；草稿模型以 safetensors 格式以及一个约 567 MB 的单一 F16 GGUF 发布

那份列表中的一行值得强调，因为它是这种搭配之所以能够成立的机制性原因：草稿模型并不是一个小型视觉模型。它没有视觉编码器，也从不接触图像。当 token 到达它据以起草的隐藏层时，图像 patch 和文本 token 都只是张量，因此模态对草稿计算来说是不可见的。正因如此，Liquid 才能把一项为文本模型开发的技术移植到 VLM 上，而无需重新设计它。

它改动了什么，又留下了什么

目标模型不会改变。这不是营销话术——这是投机解码的正确性属性。在贪心解码下，每个草稿 token 都会由目标模型验证，因此输出与目标模型单独生成的结果完全一致。在非零温度下采用匹配的采样设置时，输出分布与目标模型的分布一致。草稿模型用内存换时间，不影响其他任何东西。

这意味着你能找到的 LFM2.5-VL-3B 的每一项质量数值，都原封不动地适用于成对配置。在 Liquid 自家的评测中，目标模型在 ScreenSpot-v2 上得分为 80.7，在 BLINK 上为 61.5，在 MuirBench 上为 58.3，在 MME 上为 73.1，在 MMStar 上为 63.3，在 ChartQA 上为 81.3，在 POPE 上为 88.7——全部由厂商自行报告，无一经过独立复现，而且无论是否挂上草稿模型，这些数值都同样成立。这里不存在需要权衡的质量与速度取舍，任何呈现这种取舍的对比页面都误读了该模型。

真正变化的是单个 token 的挂钟时间成本。Liquid 测得：在单张 H100 上使用 BF16、通过 SGLang、块大小为 9 时，解码加速比为 2.04× 到 2.66×；在 Apple M5 Max 上通过 MLX-VLM、块大小为 8 时，为 2.30× 到 3.13×；在 M3 Ultra 上通过 llama.cpp 时，为 1.57× 到 2.14×。端到端来看，同样的运行分别达到 1.64×–2.27×、1.56×–2.62× 和 1.30×–1.77×。这些成对数字就是完整的论据：解码的提升幅度大约是端到端的两倍，而这一差距正是草稿模型无法触及的那部分工作负载。

供应商陈述的预填充问题

Liquid 自己公告中最有用的一句，是反对对其标题作无限解读的那句。视觉语言推理要付出文本推理所没有的预填充成本：图像先经过视觉编码器，随后语言主干再处理该编码器输出的数百个视觉 token。在边缘设备上，预填充占端到端延迟的很大一部分。投机解码只加速解码——视觉编码和预填充不变。在预填充占主导时，3× 的解码加速只会转化为小得多的端到端收益。

这是厂商把阿姆达尔定律用在自家产品上的结果，它应当决定谁会读这一页。对单张扫描页面的长篇转写、一条图注、一段逐轮携带同一张图片的多轮对话——解码密集，此时草稿模型对得起它那 2.795 亿参数。针对一张大型高分辨率图片提出的简短问题——预填充密集，它就不划算了。把同样的目标放到高并发的服务器上，情况又会改变：Liquid 衡量的是吞吐量与交互性之间的前沿，而非单一数字，并报告称 DSpark 在测试过的每一个并发级别上都保持优势，只是随着并发升高，差距逐渐收窄。

来自同一来源的两条较小的范围说明。所有测量中，视觉编码器和语言主干均使用 16 位处理，量化模型的加速不在本次发布的范围之内。如果你的计划是将 4 位目标导出与草稿模型搭配使用，因为 3B VLM 的全部吸引力就在于能塞进几 GB 内存，那么这一组合并非实际测量的对象。

附加它实际上会让你付出什么代价

内存是看得见的成本，而卡片把它量化了出来：部署栈中的参数多了 8.9%。运行时复杂度则是看不见的那一项。SGLang 需要 v0.5.19 或更新版本，并且启动命令行中要带上 --speculative-algorithm DSPARK、草稿模型路径和块大小；卡片自带的示例还禁用了 radix 缓存，并锁定了一个静态内存占比，这些都是你现在必须自己斟酌的服务决策。MLX-VLM 需要 v0.7.2 或更新版本，草稿模型通过 --draft-model 传入，但那里的 DSpark 解码目前采用贪心采样，所以温度必须强制设为 0 —— 如果你的应用依赖采样多样性，这就是一个实打实的约束。llama.cpp 则是让 GGUF 草稿模型与 GGUF 目标模型配合工作，而不是与原始的 safetensors 检查点配合。

还有一项成本会在生产环境而非基准测试中显现：起草模型和目标模型必须同行。它们之间的版本偏差是一种在单模型部署中不存在的故障模式，而如今独立滚动发布其中任何一个都成了一个双制品问题。

这是一种自托管配对方案。OrcaRouter 并不路由 LFM2.5-VL-3B 或其草稿模型——两者都由你自己下载并自行提供服务——因此这里所说的路由问题，涉及的是这个小模型交接出去的一切。大多数把 3B 边缘 VLM 与草稿模型配对的部署，仍然会遇到小模型不该回答的查询，而把这些查询交给 一个覆盖 200 多个模型的单一端点，按各提供商的标价计费，并在提供商服务降级时自动故障转移，只需做一次集成，而不必为每家供应商各做一次。这也意味着，一旦某家提供商降价，你的费率当天就会随之调整，而不用等到下一次合同续签。

要下载哪一个

如果你的工作负载是解码密集型的，并且你的硬件是 Liquid 测试过的三款之一，那就接上草稿模型——下行风险是有限的，因为输出可证明就是目标模型的输出，而内存成本不到一个模型的十分之一。如果你的延迟由预填充主导，或者你运行的是量化目标模型，或者你依赖非贪婪采样，而所用运行时尚未解除该限制，那就单独运行 LFM2.5-VL-3B。它自身就很快：在 M5 Max 上每秒 228 个 token，在 AMD Ryzen AI Max+ 395 上为 116 个，在 Galaxy S26 Ultra 上为 20 个，均为厂商数据，占用约 3 GB 内存。

目前还没有人能告诉你的是，Liquid 的那些数字在你的硬件上是否成立。撰写本文时，这个 drafter 在 Hugging Face 上有 37 次下载，而其表格中的任何数字都没有经过独立复现。其工程实现是可靠的，正确性论证是证明而非断言，但数值大小只是一项测量结果——而来自一个实验室、一组机器的测量结果，正是那种在写进容量规划之前需要你自己核实的数字。

OrcaRouter 通过一个密钥即可触达 200+ 个模型，各家供应商的目录价均以 0% 加价率直接透传，并在供应商之间自动故障转移。供应商目录价以 0% 加价率透传本页介绍的这一组合无论如何都是自托管部署——路由器负责承接小模型移交出去的一切任务，这也意味着供应商一旦降价，当天就会体现在你的费率上。