推理速度飙升3倍：Liquid AI的DSpark如何让大模型“边想边验证”？

起因：为什么推理速度依然是瓶颈？

大模型能力越来越强，但“用起来慢”的问题始终困扰着开发者。尤其是在部署到手机、笔记本等端侧设备，或者需要实时交互的Agent场景时，模型生成一个字一个字“吐出来”的延迟，直接影响用户体验。传统的自回归解码过程是“内存带宽瓶颈”——大部分时间花在把模型权重从内存（DRAM）搬运到计算单元（SRAM）上，而不是真正的计算。Liquid AI这次发布的DSpark，正是瞄准这个核心痛点，用一种巧妙的“先猜后验”机制来提速。

拆解：DSpark到底怎么“猜”和“验”？

你可以把DSpark想象成一个高效的“打草稿”流程。它包含三个关键部分：

1. 并行草稿骨干：基于目标模型当前的上下文信息，一次性并行生成多个候选词元（token）的隐藏状态。这就像根据前面的对话，快速构思出几个可能的下一句话。
2. 轻量级序列头：这部分像一个“连贯性检查员”，它以马尔可夫链的方式建模相邻词元之间的依赖关系，确保草稿的后续部分在逻辑上是连贯的，从而提高被目标模型接受的概率。
3. 置信度调度验证器：这是最聪明的部分。它会预测每个草稿词元的“存活概率”。如果发现某个词元的置信度很低，验证它可能得不偿失（验证成本高于节省的时间），就会提前“剪掉”这个低质量的草稿分支，避免浪费计算资源。

最终，目标模型会对整个草稿序列进行一次前向传播验证。只有完全匹配的草稿才会被接受，否则就回退到目标模型自己的生成。关键在于，这个过程在数学上保证了输出结果与原始模型完全一致，没有任何质量损失。

趋势洞察：从“更大”到“更快更省”的范式转移

DSpark的发布揭示了一个清晰的趋势：AI竞赛的焦点正从单纯追求模型参数规模，转向推理效率的工程优化。当模型能力达到一定阈值后，如何低成本、低延迟地将其部署到真实场景中，成为商业落地的关键。推测解码（Speculative Decoding）技术，特别是像DSpark这样经过精心设计和工程优化的方案，正在成为行业标准工具箱的一部分。它让中小参数模型（如LFM2.5-2.6B）在端侧设备上也能获得流畅的交互体验，这直接拓宽了AI应用的边界，比如更实时的代码补全、更自然的语音助手、更敏捷的Agent工具调用。

实用价值：开发者现在能做什么？

对于开发者而言，这件事最直接的价值在于 “即插即用”。DSpark已经获得了llama.cpp和SGLang两大主流推理框架的首日支持并开源。这意味着：

• 如果你正在用llama.cpp在本地或边缘设备部署LFM2.5模型，现在可以通过加载配套的DSpark草稿模型，轻松获得近3倍的速度提升。
• 如果你在云端使用SGLang服务，同样可以无缝集成，降低服务成本和响应延迟。
• 对于关注Agent应用的开发者，文中特别提到DSpark能将函数调用（function-calling）的延迟平均降低57%，这对于构建需要频繁调用外部工具的复杂Agent至关重要。

反常识/意外：小模型的大能量

一个可能被忽略的点是，DSpark带来的加速效果在较小的模型（如2.6B）和端侧设备上反而更显著。文章数据显示，LFM2.5-2.6B在M4 Max MacBook上的加速比（2.87x）甚至高于在H100 GPU上的表现。这说明，对于资源受限的端侧部署场景，推测解码技术的边际收益更高。它让“够用”的小模型变得“好用”，这可能会改变很多应用选择模型时的权衡——不一定非要上最大的模型，一个经过加速的中等模型可能是更优解。

原文地址: Up to 3.2x Faster Inference with LFM2.5-DSpark