先看证据
把机制串起来
自回归模型通常每次前向只生成一个Token，解码因此被串行步骤卡住。推测解码让小模型先猜一段，再由大模型一次性验证；验证通过的Token直接保留，不通过的部分仍由大模型接管，因此可以保持目标模型的输出分布。对视觉语言模型而言，图像编码、Prefill和文本Decode是不同阶段，推测解码主要加速最后一个阶段。
DSpark Draft读取目标模型多个层的隐藏状态，用4层注意力模块和两个小头预测未来Token，推理时建议块长为8或9。Embedding和LM Head与3B目标模型共享，因此新增参数约279.5M，而不是完整复制一个小语言模型。目标模型随后把整段候选放进一次前向中验证，连续接受的Token越多，目标模型前向次数就越少；接受率越低，Draft开销和验证浪费就越明显。视觉输入在进入隐藏层后也表现为张量序列，所以Draft本身不必显式区分文字和图像Patch。代价是显存和计
['优先用于长文本输出、接受率高且Decode占比大的VLM任务', '图像编码或Prefill占比高时，端到端收益会被Amdahl定律压低', 'Apple硅建议块长8，其他硬件可尝试8或9', '商业部署前核对LFM Open License的营收门槛']
一个 3B 模型为什么还要带上 280M 参数
Liquid AI 发布的 LFM2.5-VL-3B-DSpark，是面向 LFM2.5-VL-3B 视觉语言模型的实验性推测解码草稿模型。它不是一个独立的视觉模型，也不是把目标模型重新训练成更小的版本，而是增加一个约 279.5M 参数的协作组件，让原本一次只生成一个 token 的目标模型，能够一次核验一组候选 token。Liquid AI 报告称，在 Apple M5 Max 上最高可获得 3.13 倍解码加速，在 NVIDIA H100 上最高为 2.66 倍，并且在贪心解码下输出保持一致。
这项发布值得技术负责人注意，是因为它处理的是视觉语言推理里一个容易被忽略的矛盾。图像让模型的输入路径更复杂，但输出阶段仍然是逐 token 生成。于是，加速的关键不一定是重新设计视觉编码器，而可能是找到一种方式，让已经进入语言模型隐藏层的多模态信息继续沿用成熟的文本推理优化。DSpark 的设计正是在验证这个判断，而不是简单展示一个更小的模型。
图像信息没有改变隐藏层之后的推理接口
标准推测解码的逻辑并不复杂。小型草稿模型先向前猜测若干 token，较大的目标模型再用一次前向计算检查整个候选块，只保留目标模型原本也会生成的部分。若草稿模型猜得准，目标模型就少做许多逐 token 的前向计算。若猜测经常被拒绝，草稿计算和核验计算仍然发生，收益自然会下降。
DSpark 的关键实现是让草稿模型读取目标模型多个层的隐藏状态，并预测接下来的 k 个 token。材料强调，在这些隐藏层中，文本 token 和图像 patch 已经都表现为张量，因此草稿模型不需要因为输入来源不同而采用另一套推理算法。它是一个简化的、仅包含注意力层的结构。消融实验选择了 4 个层和长度为 9 的预测块，推理时 Liquid AI 建议根据硬件使用 8 或 9 的 block size，Apple silicon 推荐使用 8。
这套结构还通过共享组件控制了额外成本。草稿模型与目标模型共享 embedding 和 language-model head，新增的主要部分是四个注意力层和两个小型 head。Liquid AI 表示，部署参数量因此增加约 8.9%，而不是再完整复制一个语言模型。这个数字并不等于额外运行成本只有 8.9%，因为草稿本身仍然需要计算，但它说明 DSpark 的取舍是用有限的模型和内存增量换取更少的目标模型解码轮次。
3.13 倍是解码数字，不是请求延迟承诺
DSpark 的性能数字必须拆成两层看。Liquid AI 的材料区分了解码加速和端到端加速，前者只衡量生成阶段，后者还包括视觉编码和 prefill。材料给出的可视化说明也明确指出，视觉编码与 prefill 的速度没有因为接入草稿模型而改变，因此它们会限制完整请求的收益。这是典型的 Amdahl 定律问题，能被加速的部分占比越低，整体提升就越接近固定成本所允许的上限。
材料中的任务差异说明了这一点。在 M5 Max 上，3.13 倍的解码数字来自 COCO 图像描述，而 2.62 倍的端到端数字来自 MMMU-Pro。另一个给出的端到端例子是 TextVQA 的 1.56 倍。也就是说，“最高 3.13 倍”和“用户一次请求快多少”并不是同一个指标，甚至不一定来自同一任务。技术负责人如果只引用前者，很容易把生成阶段的局部改善误写成产品级延迟保证。
接受率是另一条决定收益的路径。材料提到，测试中的 Apple 平台接受率处于相近范围，Liquid AI 因此倾向于认为接受率更多取决于草稿模型和工作负载，而不是运行时本身。报告还给出了大约 3.2 到 4.6 个草稿 token 的接受范围用于模拟和展示。这个区间不能直接转换成所有业务的预测值，但它提醒部署团队要记录每次核验平均接受多少 token，而不只是记录最终吞吐。
运行时支持降低了接入门槛，却没有消除工程代价
LFM2.5-VL-3B-DSpark 的交付形态已经接近可接入组件。权重发布在 Hugging Face，同时提供 Safetensors 和 GGUF 格式，并在发布时获得 SGLang、MLX-VLM 与 llama.cpp 的支持。对使用 Apple silicon、NVIDIA GPU 或现有开源推理栈的团队来说，这比只有论文或研究代码更容易进入实际评估流程。材料还说明，训练和消融实验全部在 AMD 硬件上完成，数据则通过 Liquid AI 的公开设备基准设施 Pipette 收集。
但运行时入口并不意味着生产环境可以无条件打开开关。推测解码增加了草稿计算、额外内存和调度路径。目标模型需要在一次前向过程中核验候选块，运行时还要处理接受与拒绝的分支。如果业务请求的输出很短，或者主要时间消耗在图像编码和 prefill，这些新增成本可能无法被减少的目标模型轮次抵消。部署时至少要把首 token 延迟、生成速度、端到端延迟、峰值内存和接受率放在同一组测试里。
评估覆盖面也需要被正确理解。Liquid AI 按 MMSpec 的六类任务进行评测，包括 General VQA、Text VQA、Image Captioning、Chart VQA、Complex Reasoning 和 Multi-turn Conversation。所有运行使用 batch size 1、temperature 0，视觉编码器和 backbone 使用 16-bit 权重。这样的设置有助于比较推测解码本身，但并不代表每个团队的并发、量化、批处理和流式输出条件。它证明了方案在给定测试边界内可行，不能替代对真实请求分布的压测。
真正的部署门槛还包括许可证和工作负载边界
这次发布还有一个不能被性能数字掩盖的约束。LFM Open License v1.0 允许商业免费使用，但材料明确给出的条件是，企业年收入需要低于 1000 万美元。对于超过这一门槛的公司，不能因为权重公开、格式开放或运行时已经支持，就推断可以直接用于商业服务。许可证审查不是上线后的补充流程，而应当与模型评估同时进行。
从工程角度看，DSpark 最适合被当作一个有边界的推理组件，而不是普遍适用的加速按钮。它的价值在于把多个候选 token 的验证合并到目标模型的一次计算里。只有当草稿预测与目标模型足够一致，且解码在完整请求中占据足够大的时间比例时，这个机制才会把额外的草稿成本转化为可见收益。长输出、稳定任务分布和充足内存会提高采用理由，短回答、复杂视觉预处理或接受率波动则会削弱采用理由。
因此，接入前应先建立一张按任务划分的测量表。每类任务都应记录输入图像特征、输出长度、解码占比、平均接受 token 数、解码与端到端速度、峰值内存和错误或输出一致性约束。然后再比较不使用草稿模型、使用不同 block size 以及不同硬件栈的结果。若收益只在单一任务的局部指标中出现，或者许可证条件无法满足，就不应把“最高 3.13 倍”写进产品承诺。DSpark 证明的是一种可复用的架构方向，最终是否值得部署，仍取决于工作负载和治理边界。