LFM2.5-VL-3B-DSpark：Liquid AI 的 279.5M 草稿模型在任何人宣布之前六天发布

有一个版本的故事里，LFM2.5-VL-3B-DSpark 是一款新模型。事实并非如此。它是一个 2.795 亿参数的推测解码草稿模型，存在的目的只有一个——让 Liquid AI 自家的视觉语言模型 LFM2.5-VL-3B 解码得更快——而且它无法自行生成可用的答案。尽管如此，它仍值得一读的原因在于时间线：其权重于 2026 年 9 月 18 日登陆 Hugging Face，未附带任何公告，在那里沉寂了六天，直到 9 月 24 日才等来一篇厂商博客文章。Radar 在这个空档期捕捉到了该仓库。

这个空白也是当前可知范围的边界。仓库里的一切——参数拆解、块大小、框架集成、许可证——都是你或我可以在磁盘上打开的文件。每一个加速比数字都由厂商测量，来自 Liquid 自己的基准测试工具，公司之外没有人发布过复现结果。本文有意将这两类内容分开。

仓库实际包含的内容

打开模型卡，整体情况就一目了然。LFM2.5-VL-3B-DSpark 是一个草稿模型，其目标模型已固定在其元数据中：base_model: LiquidAI/LFM2.5-VL-3B。你不能将它指向另一个模型，也不能单独部署它。

• 草稿参数总计 — 279.5M，BF16，其中 193.0M 是 4 层解码器堆栈，65.5M 是马尔可夫头，21.0M 是隐状态投影，6.4k 是归一化层加上一个置信度头

• 骨干网络 —— 4 个全注意力层，隐藏维度 2,048，中间维度 6,144，采用 SiLU/SwiGLU，分组查询注意力，32 个注意力头和 8 个键值头，头维度 64

• 额外的头——一个秩为 256 的马尔可夫头和一个置信度头，这正是 DSpark 草拟与普通并行起草器的区别所在

• 块大小 — 训练时为 9；推理时为 8 或 9，具体取决于硬件，而在 Apple silicon 上则 specifically 为 8

• 词汇量 — 128,000，与目标绑定，而非由草稿承载

• 部署堆栈中的权重——Liquid 表示，草稿模型使部署的参数量增加了 8.9%

8.9% 这个数字要记住。这类模型的卖点从来不是“更快的推理是免费的”；而是“更快的推理会占用你大约十分之一个模型大小的内存”。在一个 3.1B 的目标模型之上增加 279.5M 额外参数时，这笔代价比仅 drafter 本身的规模所暗示的要小，因为嵌入层和 LM head 都与目标模型绑定，而没有被复制。

DSpark 首先是一项 DeepSeek 技术，其次才是一个 Liquid 模型

这个命名容易让人混淆，因此值得精确说明。DSpark 并不是 Liquid AI 的发明，也不是一个模型系列。它来自另一条研究路线的推测解码框架，在一篇 2026 年 7 月的论文中被描述为带置信度调度的推测解码与半自回归生成。它包含三个想法：一个并行主干，在一次前向传播中草拟整个块；一个轻量级顺序模块，恢复相邻草拟 token 之间的某种依赖关系，以免接受率在块末尾崩塌；以及一个验证器，当草稿自身的置信度表明尾部会被拒绝时，按请求缩短验证窗口。

Liquid 所做的，就是把那套方法应用到视觉语言模型上，并发布了一个检查点。模型卡坦承，这种迁移并没有听起来那么引人注目：从草稿模型的角度来看，模态无关紧要，因为当 token 到达隐藏层时，图像 patch 和文本 token 都只是张量。这就是为什么一项在文本模型上开发的技术可以移植到 VLM 而无需重新发明——也是为什么草稿模型不能作为一项新能力来宣传。

Liquid 此前已经发布了文本 DSpark 起草模型——2.6B、8B-A1B 和 1.2B-Instruct 配套模型于 2026 年 8 月上线，GGUF 导出随后于 8 月 19 日发布。视觉起草模型是将同样的思路扩展到多模态分支，它是该产品线中的第四或第五个条目，而非首次亮相。

加速比数据，以及是谁测量的

下面的每一个数字都出自 Liquid 自己，采集自 Liquid 的基准测试基础设施，且没有任何一项经过独立复现。你要把它们当作厂商给出的上限，而非预期结果。这张卡片把解码加速与端到端加速分开呈现，这一点比标题数字更重要。

• 最佳解码加速 — 在 COCO 上达到 3.13×，使用 MLX-VLM 在 Apple M5 Max 上测得，块大小为 8、FP16、批大小为 1、温度为 0

• 最佳 GPU 解码加速 — 在 COCO 上达到 2.66 倍，单张 H100 80GB 上运行 SGLang，BF16，块大小 9

• llama.cpp 最佳解码加速 — 在 COCO 上达 2.14×，Apple M3 Ultra，块大小 8

• H100 在六个视觉任务中的解码范围为 2.04× 到 2.66×，端到端为 1.64× 到 2.27×

• M5 Max 解码范围 — 2.30× 到 3.13×，端到端 1.56× 到 2.62×

• M3 Ultra 解码范围 — 1.57× 到 2.14×，端到端 1.30× 到 1.77×

• 草稿接受——在全部三个技术栈上，每次目标验证通过大约接受 3.2 至 4.5 个 token

这些区间里的规律才是诚实之处。端到端收益始终是每一对中较小的那一半，因为草稿模型只加速解码，别的什么都不加速。还要注意，同一个草稿模型在相同块大小下，在一个技术栈上能达到 3.13×，在另一个上却只有 1.57×——接受率是草稿模型与工作负载的属性，而墙钟收益则是硬件与运行时开销的属性。一个不附任何技术栈的“快 2.66×”的说法，不是一个你能据以行动的说法。

卡片中的两个正确性要点值得直白地说明，因为正是它们才使草稿模型在生产环境中真正可用。在贪婪解码下，投机解码是精确的：目标模型会验证每一个被提议的 token，因此生成的文本与目标模型单独生成时完全一致。在非零温度下采用匹配的采样设置时，它能保持目标模型的输出分布。Liquid 的说法——你得到的是加速，而不是一个不同的模型——就其所述范围而言是准确的，而卡片也诚实地指出，提高温度会降低接受率，从而削弱吞吐量的收益。

Liquid 自己的帖子承认了什么

9月24日的博客文章比模型卡更有用，原因只有一个：它点明了限制所在。视觉语言推理需要付出文本推理所没有的预填充成本——图像必须先经过视觉编码器，然后语言主干网络还要处理该编码器产生的数百个视觉token。在设备上，这种预填充主导了端到端延迟。投机解码只能加速解码阶段。视觉编码和预填充并未受到影响。Liquid援引阿姆达尔定律来审视自家产品，并指出，当预填充在挂钟时间中占很大比例时，大幅提升解码速度只能带来有限的端到端改进。

这是购买决策中的一项实际约束，也解释了为什么首 token 延迟并不在这款草稿模型所改进的事项之列。它还意味着，受益最大的工作负载是那些从一张中等规模的图像生成大量输出的场景——例如生成一条说明文字、一段较长的 OCR 转录、围绕一张持续携带的图像进行多轮对话——而不是针对一张大图回答一个简短问题的工作负载。

这篇文章又补充了两项范围限制。所有数值在视觉编码器和语言主干上都采用 16 位处理，并且本次发布不涵盖量化模型的加速。鉴于 3B 边缘 VLM 的全部卖点就在于能在几 GB 内存中运行，“加速是在 FP16 下测得的”对任何计划将其与 4 位导出搭配使用的人来说都是一个值得注意的限制。Liquid 还指出，草稿模型完全是在 AMD 硬件上训练的。

运行它

首日支持是实打实的，覆盖了三种运行时，这比大多数 drafter 能获得的待遇都要好。NVIDIA 上的 SGLang 需要 v0.5.19 或更高版本，并通过 --speculative-algorithm DSPARK 来接收 drafter，同时指定 draft path，块大小为 9。Apple 芯片上的 MLX-VLM 需要 v0.7.2 或更高版本，当通过 --draft-model 传入时会自动识别该 drafter；有一个棘手之处——MLX-VLM 中的 DSpark 解码目前使用贪心采样，因此 temperature 必须设为 0。对于 llama.cpp，有一个独立的 GGUF 仓库，其中只有一个约 567 MB 的 F16 导出，而且模型卡片明确指出，应将量化后的 drafter 与量化后的目标模型搭配使用，而不是与原始的 safetensors 检查点搭配。

路由层在这里体现价值的地方，并不在这个模型上——OrcaRouter 不会路由 LFM2.5-VL-3B-DSpark 或 LFM2.5-VL-3B，而这是一个你自行下载并自行提供服务的自托管草稿模型配对。它的价值体现在围绕该模型的其余技术栈上。同一个在设备端运行小型开放权重视觉模型的应用程序，通常会为小型模型无法处理的查询提供一条回退路径，并将这条路径指向一个覆盖 200+ 个模型的单一端点——按各提供商的标价计费，不添加任何加价，并在提供商服务降级时自动故障转移——比搭建第二份供应商合同所需的集成工作更小。草稿模型改进的是该架构中的一条分支；而路由器则能让另一条分支不至于变成第二个项目。

尚未知晓的是什么

在撰写本文时，该仓库有 37 次下载和 6 个点赞。这个草稿模型在任何公共基准测试聚合平台上都没有条目，没有任何第三方复现其任一加速范围，也没有在 Liquid 未测试的硬件上对其接受率进行独立测量。出于显而易见的原因，模型卡上也没有质量基准测试——该草稿模型从构造上就是保持输出不变的，因此质量数据属于 LFM2.5-VL-3B，模型卡指向该模型的基准测试，而不是自行编造。

元数据中的一个细节多少透露了它有多新：这个模型带有 SGLang 的库标签，以及一个专门用于调用它的 SGLang 算法标志。框架支持必须先于公告落地，这与代码仓库和博客文章之间相隔六天的情况相符。

所以：一项真实、有用、范围狭窄的工程成果，在发布一周后才被宣布，其全部价值主张不过是厂商在你可能并不拥有的硬件上测出的一个数字。如果你在 H100 或 M 系列 Mac 上部署 LFM2.5-VL-3B，且你的工作负载以解码为主，那么内存开销是 8.9%，而弊端几乎为零，因为输出可证明就是目标模型的输出。如果你的延迟主要由预填充主导，或者你指望着那个 4-bit 导出，Liquid 自己的博文会告诉你它帮不上忙。复现结果一旦出现，才是值得等待的东西。

OrcaRouter 将 200 多个模型置于单一密钥之后，按提供商标价、0% 加价提供，并把回退路径表达为一个路由层，而不是应用代码。无论哪种方式，drafter 都是自托管的——正是路由器让你的小模型所交接的那一段不至于变成第二个项目。