Liquid AI LFM2.5-VL-3B-DSpark 加速视觉解码，但 3.13 倍的标题数字只说明了一半事实

Liquid AI 发布了 LFM2.5-VL-3B-DSpark，并宣称其紧凑型视觉语言模型的解码速度最高可提升 3.13 倍。这项改进针对的是 token 生成，而非理解图像并生成答案的完整过程。

这一差异决定了 Liquid AI LFM2.5-VL-3B-DSpark 的意义。实验性草稿模型表明，推测解码可在数据中心硬件和消费级硬件上应用于视觉及文本任务。不过，Liquid AI 自己公布的结果显示，最佳端到端提升为 2.62 倍，低于峰值解码数字。

此次发布促使开发者重新思考如何优化本地视觉语言应用。模型压缩和更小的架构不再是降低延迟的唯一途径。独立的草稿模型可以在保持既定解码设置下输出行为不变的同时，加速现有目标模型。

因此，这并不是 Liquid AI 与某一个竞争模型之间的比较，而是推测解码与传统做法之间的比较：后者通过让主视觉语言模型更小、更简单或准确性更低来换取速度。

Liquid AI LFM2.5-VL-3B-DSpark 增加了专用草稿模型

此次发布将答案质量与延迟问题中的一个重要环节分离开来。

Liquid AI LFM2.5-VL-3B-DSpark 是一款专为 LFM2.5-VL-3B 构建的 2.795 亿参数草稿模型。它不会取代拥有 30 亿参数的目标模型，也不会独立回答请求。相反，它会先提出多个可能的 token，再由更大的模型一并验证。

这一过程称为推测解码：一种利用较小预测器为目标模型起草 token、再由目标模型并行验证的方法。被接受的 token 能减少生成答案所需的昂贵目标模型推理次数；被拒绝的提议则由目标模型修正。

Liquid AI 表示，该草稿模型包含四个全注意力层、一个 Markov head 和一个 confidence head。其训练块包含九个候选 token。部署时则会根据硬件和推理框架使用八或九个 token 的块。

该公司通过其模型仓库发布了 Safetensors 和 GGUF 格式的模型。它支持 Nvidia GPU 上的 SGLang、Apple silicon 上的 MLX-VLM，以及通过 GGUF checkpoint 使用的 llama.cpp。

这种框架覆盖很重要，因为推理加速往往仍局限于论文或定制化研究实现中。在这里，Liquid AI 已将其草稿模型接入三条已经用于服务器、Mac 和本地量化模型的部署路径。

已发布配置要求 SGLang 版本为 0.5.19 或更高。MLX-VLM 要求 0.7.2 或更高版本，目前以贪婪采样方式运行这一 DSpark 实现。Liquid AI 指示 MLX 用户将 temperature 设为零。

目标模型早于草稿模型发布。Liquid AI 于 2026 年 8 月推出 LFM2.5-VL-3B，这是一款面向边缘部署的开放权重视觉语言模型。该模型将语言骨干网络与视觉编码器结合，用于图像、文档、定位、光学字符识别和视觉工具调用。

Liquid AI 此前宣称，该目标模型在 M5 Max 上的解码速度可达每秒 228 个 token。该公司还报告称，Ryzen AI Max+ 395 的速度为每秒 116 个 token，Galaxy S26 Ultra 则为每秒 20 个。这些较早的数据来自该公司的自主测试。

DSpark 的发布改变的是部署套件，而不是底层模型已学习到的能力。开发者在推理期间接入草稿模型，而 LFM2.5-VL-3B 仍负责批准每一个生成的 token。

在贪婪解码下，目标模型只有在草稿 token 与其自身本会选择的 token 一致时才会接受它。因此，生成的答案应当与普通贪婪生成一致。在非零 temperature 下，匹配采样可以保留目标模型的输出分布，而非某一条确定性的序列。

这一特性使推测解码与量化或蒸馏具备不同的价值主张。这些技术可能改变数值精度、模型规模或学习到的行为；DSpark 则试图缩短模型得出目标模型原始决策所需的时间。

这也是此次发布在两条优化路线之间形成实质性较量的原因。开发者可以减少主模型要完成的工作，也可以预测更多主模型的工作内容，并高效验证这些预测。

3.13 倍的结果取决于硬件、工作负载和测量方式

Liquid AI 的最高数字描述的是一次解码结果，并非通用的应用加速幅度。

Liquid AI 在 MMSpec 的六类任务中评估了这款草稿模型：通用视觉问答、文本识别、图像描述、图表分析、复杂推理和多轮对话。该公司在 Apple 硬件和一块 H100 GPU 上测试了 batch size 为一的表现。

在使用 MLX-VLM 的 M5 Max 上，Liquid AI 报告的解码提升范围为 2.30 倍至 3.13 倍，端到端提升范围为 1.56 倍至 2.62 倍。3.13 倍的峰值出现在 COCO 图像描述工作负载中。

该公司还利用 llama.cpp 测试了 M3 Ultra。报告显示，解码速度提升为 1.57 倍至 2.14 倍，端到端性能提升为 1.30 倍至 1.77 倍。

在搭载 SGLang 的单块 H100 80GB GPU 上，Liquid AI 测得解码提升介于 2.04 倍至 2.66 倍之间，端到端提升介于 1.64 倍至 2.27 倍之间。该公司详细的基准测试披露提供了配置和任务级结果。

这些测试对视觉编码器和语言骨干网络均采用 16 位处理。H100 配置使用 BF16、九个 token 的草稿块、batch size 为一以及 temperature 为零。Apple 测试使用 FP16、八个 token 的块，以及最多 2,048 个生成 token。

Apple 评估中的答案长度中位数为 90 个 token。这一细节很重要，因为输出长度会改变请求中用于解码的时间占比。生成长描述的系统，能让草稿模型有更多时间弥补其初始化开销。

短答案的平衡则更不利。如果应用只返回标签、坐标或一句话，图像编码和提示词处理可能占据主导。此时，更快的生成只会影响总等待时间中较小的一部分。

草稿接受率有助于解释报告中的加速效果。Liquid AI 在 Apple 技术栈中测得，每次验证约有 3.2 至 4.5 个 token 被接受。其 H100 结果则为 3.46 至 4.57 个被接受 token。

更高的接受长度意味着目标模型每次推理会验证更多有用输出。不过，接受率并不会直接转化为等比例的速度提升。草稿模型执行、同步、内存访问和框架开销仍会消耗时间。

结果也因任务而异。图像描述带来了 MLX 上的峰值解码提升，而多轮对话记录为 2.30 倍。两者的端到端提升分别为 2.59 倍和 1.91 倍。

这种差异意味着，不能负责任地将“最高 3.13 倍”理解为每个视觉助手都能获得的预期结果。它是在一项已公布设置中观察到的上限。应用的实际结果将取决于硬件、提示词长度、输出长度、采样设置和视觉工作负载。

Liquid AI 表示，在其 H100 测试中，DSpark 在更高并发下仍保有优势。不过，随着并发增加，差距会缩小。这表明，当 GPU 从受内存限制的解码转向受计算限制的执行时，草稿模型的相对收益会发生变化。

对产品团队而言，实际问题并不是峰值数字在 Liquid AI 的测试中是否真实，而是其延迟特征是否类似于产生该数字的测试。要回答这个问题，需要测量推理的每一个阶段，而不是将标题中的倍数直接复制进容量规划。

Liquid AI 推测解码如何保留目标模型的输出

DSpark 试图更早地进行草稿预测，同时不让预测错误进入最终输出。

标准自回归生成会逐个生成 token。每个新 token 都需要再次运行目标模型，即便后续内容高度可预测也是如此。这种串行结构可能使硬件在受内存限制的解码期间得不到充分利用。

推测解码将较小模型插入这一循环。草稿模型提出一组未来 token，目标模型则一并评估这些位置。当多个提议通过验证时，就节省了计算工作。

挑战在于，草稿模型必须足够快、也足够准确，才能证明额外引入一个模型是值得的。弱草稿模型会产生被拒绝的 token；过于庞重的草稿模型预测得更准，却要花费太多时间生成候选块。

DSpark 将并行生成与轻量级串行组件结合。其 Markov head 在候选位置间引入有限依赖，而 confidence head 则估计后续候选是否应被验证。这一设计旨在保持候选块的一致性，同时避免让草稿生成完全自回归化。

底层的DSpark 研究将这一方法描述为采用半自回归生成的置信度调度推测解码。其核心权衡涉及候选质量、草稿延迟，以及送去验证的 token 数量。

纯并行草稿可以快速生成一个块，但距离块末端越远，token 的准确性往往越低。每个位置都依赖于包含先前猜测的上下文，因此错误可能在候选中不断累积。

完全自回归的草稿模型能保持更强的依赖关系，但也重建了部分串行瓶颈。DSpark 的混合结构试图处于两者之间：它在并行草稿操作后增加了一个小型串行 head。

置信度机制解决了另一种浪费来源。当草稿模型预计后续 token 会失败时，验证整个固定块没有太大意义。调度器可在低置信度位置消耗目标模型容量之前，缩短提交的前缀。

已发布的 LFM2.5-VL-3B-DSpark 配置使用 rank-256 Markov head 和独立的 confidence head。其词表包含 128,000 个 token。该架构仍与指定目标模型绑定，不能作为适用于所有 VLM 的通用即插即用草稿模型。

这种模型专属关系既是优势也是限制。针对单一目标模型训练可以提升候选对齐度；但切换到另一款目标模型的团队，则需要兼容的 checkpoint、训练流程和运行时集成。

“无损”这一描述也需要准确理解。在 temperature 为零的贪婪解码下，验证会保留目标模型单独运行时本会作出的精确 token 选择。草稿模型无权用一个仅仅看似合理的替代方案取而代之。

在非零 temperature 下，目标从复现单一序列转变为保留目标分布。根据基础性的采样研究，在匹配的设置下，正确的推测采样可以实现这一点。速度仍取决于草稿模型与目标模型分布的匹配频率。

Liquid AI 报告称，在其实验中提高 temperature 会降低接受率。概率会更多地分散到排名较低的 token 上，从而增加草稿模型与目标模型产生分歧的机会。因此，创造性采样带来的增益可能低于确定性生成。

这对应用设计至关重要。文档提取、视觉定位、图表读取和受约束响应通常使用较低温度。开放式图像对话则可能采用更多采样，使已公布的贪婪解码结果代表性较弱。

因此，Liquid AI 的推测解码尤其适合可预测的输出。为标准化产品图片生成说明、读取收据、描述界面截图以及提取结构化事实，都是合理的应用场景。但实际收益仍需在本地测量验证。

更快的解码无法消除视觉语言瓶颈

核心不确定性在于：真实请求中有多少工作仍处于加速解码阶段之外。

视觉语言请求包含的不只是文本生成。系统还必须编码图像，将其转换为视觉表征，将这些视觉 token 与提示词一同处理，然后再解码答案。

DSpark 只加速最后一个阶段。它不会让图像编码更快，也不会改变预填充过程；这意味着目标模型在生成第一个答案 token 之前，仍要处理提示词和视觉 token 上下文。

这一边界解释了解码结果与端到端结果之间的差距。Liquid AI 报告称，在 M5 Max 上解码速度最高提升 3.13 倍，但总延迟的最高改善为 2.62 倍。其他任务的差异更大。

在 TextVQA 上，该公司测得 M5 Max 的解码性能提升 2.69 倍，而端到端收益仅为 1.56 倍。这一结果表明，图像处理和预填充占据了原始请求时间的很大一部分。

这一限制遵循阿姆达尔定律：当工作负载的一部分保持不变时，整体加速存在上限。如果解码占基线延迟的一半，即使解码器无限快，整个请求的提升也不会超过 2 倍。

边缘硬件使这一约束尤其重要。消费级设备为视觉编码和长上下文预填充提供的算力低于数据中心 GPU。大图像或多图提示词可能在推测解码开始产生帮助前，就延迟首个 token 的生成。

独立的 MMSpec benchmark 进一步说明了谨慎解读的必要性。其作者评估了六类任务中的 600 个样本，以及十种推测解码方法。他们发现，仅凭吞吐量加速并不能可靠反映延迟表现。

MMSpec 还发现，为纯文本语言模型设计的技术在多模态场景下可能性能下降。跨模态依赖会改变哪些提议更可能被接受。随着批处理规模增加，视觉感知变得更为重要。

Liquid AI 采用了 MMSpec 的任务类别，从而提高了其内部评估的覆盖广度。不过，DSpark 性能测试由 Liquid AI 自行完成并发布。针对常见设备和生产提示词的独立复现仍然有限。

比较基线同样值得关注。已公布的倍数是在指定框架下，对同一个 LFM2.5-VL-3B 目标模型启用和不启用 drafter 时的比较。它们并不能证明该组合系统优于所有竞争性 VLM。

这些结果也没有与替代性延迟策略进行比较。开发者可以对目标模型进行量化、降低图像分辨率、缓存视觉嵌入、缩短提示词、批量处理请求，或选择更小的模型。这些改变会影响延迟预算的不同部分。

内存是另一项运营考量。与 30 亿参数目标模型相比，drafter 很小，但并非没有成本。其权重、缓存、运行时状态和集成都要占用容量，而这在资源受限设备上十分关键。

兼容性会带来进一步摩擦。SGLang、MLX-VLM 和 llama.cpp 现已提供公开路径，但使用其他服务系统的团队不能假定可立即获得支持。生产部署需要稳定的加载能力、可观测性、批处理行为和故障处理机制。

MLX-VLM 当前仅支持贪婪生成的 DSpark 路径，限制了其立即可用的场景。依赖采样生成的应用需要采用另一套受支持的技术栈，或等待更广泛的采样支持。即便如此，更高温度也可能降低草稿接受率。

因此，这次发布应被视为具有明确边界、可信的系统优化。它并不意味着视觉推理在每一种有意义的衡量标准上都变快了 3.13 倍。

真正的竞争：更好的预测，还是更少的模型工作

DSpark 强化了一条路径：开发者保留目标模型不变，并优化其必须运行的频率。

边缘 AI 对延迟的标准应对方式，一直是减少目标模型的工作负载。团队会采用更少参数、更低精度、更短提示词、更小图像或面向任务的蒸馏。每种技术都能改善响应速度，但也都可能带来质量或灵活性上的权衡。

Liquid AI LFM2.5-VL-3B-DSpark 提出了另一条路径：保留现有目标模型，并利用专门的伴随模型预测未来的多个步骤。让目标模型验证这些猜测，同时不放弃对最终输出的控制。

当团队已经认可目标模型的能力时，这一路径就很有吸引力。替换模型将需要新的评估、提示词调整、安全检查和产品调优。接入 drafter 可以保留更多既有投入。

这一方法也适用于本地部署，因为内存带宽常常限制 token 生成。验证一个块可能比为单个 token 反复加载模型状态更高效地利用硬件。Liquid AI 在 Apple 平台上的结果使这一可能性更具体。

但更小的模型仍保有优势。它们简化封装、降低总内存占用，并加速仅优化解码器无法触及的阶段。紧凑的视觉编码器可以改善首个 token 的生成时间，而 DSpark 无法做到这一点。

量化也可以与推测解码结合，而非只能与之竞争。Liquid AI 提供了与其 GGUF 目标模型匹配的 GGUF drafter。因此，只要运行时能够正确支持这一组合，本地技术栈便可同时降低精度并引入草稿预测。

这种组合将工程问题从“选择一种技术”转变为“为每种技术分配正确的瓶颈”。量化降低权重大小和算术成本。图像预处理改变视觉成本。推测解码则针对自回归生成。

这正是阶段级性能分析变得不可或缺的原因。分析高分辨率页面的文档助手，可能把大部分时间花在解码之前。生成详细描述的视觉聊天工具，则可能把更多时间用于输出生成。

同样的区别也适用于用户体验。首个 token 的生成时间决定应用刚开始时是否显得响应迅速；每秒 token 数则决定生成开始后长答案是否流畅。

DSpark 直接改善后一个指标。当解码在请求中占据足够比例时，它也会改善总延迟。但它并不保证首个 token 的生成时间获得相应幅度的改善。

开发者还应区分单用户速度与整体吞吐量。Liquid AI 在测得的各个 H100 并发级别上观察到了优势，但差距在更高负载下缩小。生产环境的经济性取决于请求组合、批处理和服务等级目标。

因此，这次发布最具影响力的方面在于架构。Liquid AI 将推测解码打包为可部署视觉模型系列的一部分，而不是仅将其作为研究成果展示。

如果这种模式普及，模型发布可能会越来越多地包含目标模型、多种量化版本，以及面向特定硬件的 drafter。推理优化将成为模型制品的一部分，而不再是后续的服务决策。

这一方向会给其他开放权重模型开发者带来压力。仅发布 checkpoint 会将加速责任留给下游团队。提供匹配的 drafter 则能讲述更完整的延迟故事，即使实测收益仍取决于工作负载。

三个信号将表明这种加速在实践中是否重要

独立测试、更广泛的采样支持，以及真实应用的性能画像，将决定 DSpark 是否会成为可重复的部署模式。

第一个信号是可访问硬件上的独立复现。开发者应关注在 M 系列 Mac、消费级 GPU 和边缘系统上，使用相同提示词、分别启用和不启用 drafter 的测试。

有价值的报告必须披露图像尺寸、提示词长度、输出长度、温度、量化方式和运行时版本。单一的每秒 token 数无法说明应用的完整响应是否真正显著加快。

若复现结果接近 Liquid AI 报告的范围，将强化该公司的论点。若收益更小或不稳定，则可能表明公布的工作负载比日常应用更有利于 drafter。

第二个信号是更广泛的运行时和采样支持。MLX-VLM 目前将已公布的 DSpark 路径限制为贪婪生成，而 SGLang 面向 Nvidia 部署，llama.cpp 则服务于 GGUF 使用场景。

在更多推理引擎中获得支持将降低集成成本。稳定的非零温度采样，也会让该方法更适用于视觉聊天和创意描述工具。

开发者应审视采样变化时的接受率。Liquid AI 表示，在其实验中，更高温度降低了接受率和吞吐量。生产测试应揭示，这些下降对于对话型产品而言是否仍可接受。

第三个信号是团队是否报告了真实应用的阶段级收益。决定性指标包括首个 token 的生成时间、解码速率、端到端延迟、峰值内存，以及预期并发下的吞吐量。

长篇视觉助手可能会显著受益，因为生成主导了其会话。仅返回少数字段的 OCR 工作流则可能收益小得多，因为视觉编码和预填充占据了请求的大部分时间。

评估 Liquid AI LFM2.5-VL-3B-DSpark 的团队应从追踪数据开始，而不是从宣传倍数开始。测量图像编码、预填充和解码在基线中各自占据的比例。然后接入 drafter，重复相同工作负载。

在贪婪解码下检查输出等价性，并在受支持的采样下检查分布行为。分别测量热启动和冷启动。在测试笔记本电脑或移动级系统时，也应将内存压力和持续散热表现纳入考量。

这次发布提供了足够的实现细节，使这些评估成为可能。它也给开发者提供了一个有用提醒：模型能力与推理行为是两个独立的工程问题。

Liquid AI 的 3.13 倍数字，最适合被理解为：匹配的 drafter 能够实质性加速本地多模态推理的一个阶段。端到端数据同时展现了这一论断的价值与限制。

匹配的草稿模型会成为开放权重 VLM 的标准伴随组件，还是仍将是面向长输出工作负载的专用优化？答案将来自可复现的应用追踪数据，而不是单个峰值基准测试。